While most customers choose to activate and run SAP Joule in a single-system S/4HANA Private Cloud landscape, I had the opportunity to implement it across a complete three-system landscape—DEV, QAS, and PRD. This approach brought additional complexity in terms of transport, configuration consistency, and cross-system validation, but it also ensured a more robust, production-ready deployment. Successfully enabling Joule in a full landscape setup is not just a technical task; it reflects a deeper understanding of SAP architecture, governance, and best practices. Delivering this implementation end-to-end has been a noteworthy achievement in my SAP journey.
Sharing this experience is important because a three-system setup brings its own challenges, and I hope this blog will make the process clearer and easier for anyone working in a similar landscape.
The steps for implementing Joule remain the same across landscapes, but there are several important considerations that need to be planned in advance before starting the implementation in a customer environment.
Let’s get started.
Architecture diagram
1. BTP subaccounts and Cloud identity service
For non-production systems (development and quality systems), we need to create two different subaccounts for each to enable the required Joule and Work Zone subscriptions and services. This separation helps maintain a clear landscape structure aligned with the backend systems. However, it is recommended to use a common subaccount for the Cloud Identity Services (CIS) tenant, as it has only one connectivity service, and identity management should remain centralized for consistent user provisioning and authentication across both environments, and we are using non prod IAS tenants for both.
Tip: We can also integrate Joule without creating a separate subaccount for CIS by including CIS in the individual DEV and QA subaccounts, but in that case we need to create the RFC for the identity service from the DEV subaccount for the QA system by pointing this RFC to the QA system used when configuring the source system in IAS.
2. SAP roles assignment to users
Since Joule-specific capabilities are embedded within certain standard SAP roles, it’s important to ensure that end users who will be accessing Joule have these roles assigned. Without the required role assignments, users will not be able to utilize Joule’s features fully. For most customers, users already have their standard Fiori roles assigned based on their functional area—for example, a finance user typically has all the roles required for their day-to-day activities.
Tip: Get a list of all the roles from the customer security team and make sure these roles are exposed to BTP in all three systems. It’s better to involve the security team here to get this step done.
3. Technical and business catalog creation
This step must be carried out in the development system. The technical and business catalogs required for the QA and PRD systems will also be created in DEV and then transported to the respective systems as part of the normal transport process. During production cutover activities make sure the transports for catalogs are moved to production systems.
Tip: If we are configuring Joule in unit test clients other than the DEV client, create catalogs and roles in the development client and then create a client copy transport to the Joule configuration client in the development system. The same applies for any other developments as well.
4. Joule plugin role
It is recommended to create three separate single roles for Joule when working in a three-system landscape. The business catalog created in the development system should be included in the DEV-specific role, and the corresponding catalogs for QA and PRD should be added to their respective roles and transported through the landscape. Assigning users the appropriate role for each system ensures that they can see the Joule icon upon logging into the Fiori Launchpad. This approach is essential to ensure that Joule correctly points to the intended BTP subaccount and retrieves data from the corresponding S/4HANA system.
5. OData services activation
Based on the required capabilities, identify the corresponding OData services that need to be activated in the system. Activate these services first in the development system, capture them in a transport request, and move the transport to the QA and PRD systems. In some cases, even after the transport is imported, the related ICF services may not be automatically activated in QA or PRD. In such situations, you must manually activate the ICF services. Ensure that the necessary authorizations are available for performing this activation.
6. Cloud connector principal propagation
Principal propagations set up in cloud connectors are an important step in Joule configuration. Make sure this is done in Non-Prod and Prod cloud connector. During production cutover, we must obtain the required access to the production system to check the related parameters, CERTURLE, and certificates in the system. We must ensure access for this and get the fire fighter user if the normal user does not have the required authorization. For most production environments, there will be web dispatchers, and in such cases, we need to import the Cloud Connector certificates into the web dispatchers as well
7. SSO for Joule
In most production landscapes, customers expect Single Sign-On (SSO) to be enabled for Joule. If an S/4HANA system is already configured for SSO using Microsoft Entra ID, you can extend the same setup to Joule by configuring Microsoft Entra ID as the corporate identity provider in SAP IAS and setting it as the default identity provider. Once this is done, SSO for Joule is automatically enabled. Users do not need to exist in the IAS user store for Joule to function, as authentication flows directly through Microsoft Entra ID.
By taking care of all these steps, you can ensure a smooth and successful Joule implementation across a three-system landscape.
While most customers choose to activate and run SAP Joule in a single-system S/4HANA Private Cloud landscape, I had the opportunity to implement it across a complete three-system landscape—DEV, QAS, and PRD. This approach brought additional complexity in terms of transport, configuration consistency, and cross-system validation, but it also ensured a more robust, production-ready deployment. Successfully enabling Joule in a full landscape setup is not just a technical task; it reflects a deeper understanding of SAP architecture, governance, and best practices. Delivering this implementation end-to-end has been a noteworthy achievement in my SAP journey. Sharing this experience is important because a three-system setup brings its own challenges, and I hope this blog will make the process clearer and easier for anyone working in a similar landscape. The steps for implementing Joule remain the same across landscapes, but there are several important considerations that need to be planned in advance before starting the implementation in a customer environment. Let’s get started. Architecture diagram 1. BTP subaccounts and Cloud identity service For non-production systems (development and quality systems), we need to create two different subaccounts for each to enable the required Joule and Work Zone subscriptions and services. This separation helps maintain a clear landscape structure aligned with the backend systems. However, it is recommended to use a common subaccount for the Cloud Identity Services (CIS) tenant, as it has only one connectivity service, and identity management should remain centralized for consistent user provisioning and authentication across both environments, and we are using non prod IAS tenants for both. Tip: We can also integrate Joule without creating a separate subaccount for CIS by including CIS in the individual DEV and QA subaccounts, but in that case we need to create the RFC for the identity service from the DEV subaccount for the QA system by pointing this RFC to the QA system used when configuring the source system in IAS. 2. SAP roles assignment to users Since Joule-specific capabilities are embedded within certain standard SAP roles, it’s important to ensure that end users who will be accessing Joule have these roles assigned. Without the required role assignments, users will not be able to utilize Joule’s features fully. For most customers, users already have their standard Fiori roles assigned based on their functional area—for example, a finance user typically has all the roles required for their day-to-day activities. Tip: Get a list of all the roles from the customer security team and make sure these roles are exposed to BTP in all three systems. It’s better to involve the security team here to get this step done. 3. Technical and business catalog creation This step must be carried out in the development system. The technical and business catalogs required for the QA and PRD systems will also be created in DEV and then transported to the respective systems as part of the normal transport process. During production cutover activities make sure the transports for catalogs are moved to production systems. Tip: If we are configuring Joule in unit test clients other than the DEV client, create catalogs and roles in the development client and then create a client copy transport to the Joule configuration client in the development system. The same applies for any other developments as well. 4. Joule plugin role It is recommended to create three separate single roles for Joule when working in a three-system landscape. The business catalog created in the development system should be included in the DEV-specific role, and the corresponding catalogs for QA and PRD should be added to their respective roles and transported through the landscape. Assigning users the appropriate role for each system ensures that they can see the Joule icon upon logging into the Fiori Launchpad. This approach is essential to ensure that Joule correctly points to the intended BTP subaccount and retrieves data from the corresponding S/4HANA system. 5. OData services activation Based on the required capabilities, identify the corresponding OData services that need to be activated in the system. Activate these services first in the development system, capture them in a transport request, and move the transport to the QA and PRD systems. In some cases, even after the transport is imported, the related ICF services may not be automatically activated in QA or PRD. In such situations, you must manually activate the ICF services. Ensure that the necessary authorizations are available for performing this activation. 6. Cloud connector principal propagation Principal propagations set up in cloud connectors are an important step in Joule configuration. Make sure this is done in Non-Prod and Prod cloud connector. During production cutover, we must obtain the required access to the production system to check the related parameters, CERTURLE, and certificates in the system. We must ensure access for this and get the fire fighter user if the normal user does not have the required authorization. For most production environments, there will be web dispatchers, and in such cases, we need to import the Cloud Connector certificates into the web dispatchers as well 7. SSO for Joule In most production landscapes, customers expect Single Sign-On (SSO) to be enabled for Joule. If an S/4HANA system is already configured for SSO using Microsoft Entra ID, you can extend the same setup to Joule by configuring Microsoft Entra ID as the corporate identity provider in SAP IAS and setting it as the default identity provider. Once this is done, SSO for Joule is automatically enabled. Users do not need to exist in the IAS user store for Joule to function, as authentication flows directly through Microsoft Entra ID. By taking care of all these steps, you can ensure a smooth and successful Joule implementation across a three-system landscape. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
