Considerations on the System Landscape for Integration when On-boarding into SAP Cloud Integration
How many tenants did I license? Do I need to run a two-tier or three-tier system landscape? What is an account? Can I re-purpose my tenant? These are common questions a customer is expected to answer when on-boarding into SAP Cloud Integration. Purpose of this blog is to share relevant information enabling customers to answer these questions for their specific situation. To be as tangible as possible the blog is written along a concrete customer case.
The Customer Case
ACME, an international company in the manufacturing industry, run their human resources processes using SAP SuccessFactors Employee Central. SAP Cloud Integration is used as integration hub to exchange employee, organization, time, and cost center data with their on-premises ERP system. Subsidiaries in different regions are responsible to manage their respective local workforce. Due to compliance reasons data access must be segregated along the subsidiary accounts. One subsidiary is not allowed to access the data of the other subsidiaries.
Getting on Overview on the Licensed Tenants
In ACME the corporate IT department owns the purchasing process of software products across all regions. Although the subsidiaries in the regions can purchase software products for local usage, corporate compliance requires to centrally control which software products have been purchased for the company. Today the corporate IT department in ACME relies on the SAP ONE Support Launchpad to get an overview of the SAP products which have been licensed. The launchpad provides ACME with access to support resources like information about licensed SAP products, browsing SAP’s knowledge base for answers to known software issues, and many more. In the “System Data” tile in the “System Operations and Maintenance” section of the SAP ONE Support Launchpad ACME can see that currently three tenants for SAP Cloud Integration have been provisioned to them. Two tenants have been installed for ACME under the SAP SuccessFactors Employee Central license, one of them being classified as test tenant. A third tenant has been provided to the customer with the enterprise edition license of SAP Cloud Integration.
Recently ACME started to explore SAP for Me for getting license information about purchased SAP products. SAP for Me, a free-of-charge tool offered by SAP, intends to become the gateway for all digital touchpoints between SAP and its customers, with a focus on the usual post-sales phases. The scope of SAP for Me spans across various areas of customer interests including increased insight for customers into their software portfolio across all product categories (e.g. systems, licenses, orders, availability). SAP for Me is currently in public beta.
Call for Actions:
- Use SAP ONE Support Launchpad to find out which SAP products have been licensed.
- Start exploring SAP for Me (public beta).
System Landscape for Integration
Criteria to segregate the purpose of a tenant in SAP Cloud Integration can be of legal or organizational nature:
Legally the SAP terms and conditions mandate a certain usage of the purchased SAP cloud product. For example, in case SAP Cloud Integration is purchased as part of an SAP cloud application package such as SAP SuccessFactors Employee Central its usage is restricted to the context of that specific SAP cloud application. ACME is adhering to the SAP terms and conditions since they currently use their tenants only in the context of SAP SuccessFactors Employee Central.
One of the most crucial organizational criteria to be considered when setting up the system landscape is about the quality assurance processes a company is following. ACME is relying on pre-packaged integration content (“configure only”) delivered by SAP to run their core human resources processes. Since all SAP delivered content already underwent a quality assurance process before release to customer ACME decided to run a two-tier system landscape only. One tenant (t2) is used to preview new versions of the pre-packaged integration content before they are deployed to the productive tenant (t3). The content packages in the preview tenant are subscribed to the SAP API Business Hub to ensure that new versions of the content are copied automatically to it once available. The content packages in the productive tenant are not subscribed to the SAP API Business Hub to prevent that SAP enforces an update of the pre-packaged integration content in the productive tenant. Instead ACME copies the configured integration content from the preview to the productive tenant using the transport management system. With that ACME has full control on when to update the pre-packaged integration content in the productive tenant. To extend their human resources processes into third party application for recruiting contingency workers in some of the subsidiaries ACME has developed custom integration content. For custom integration content ACME is running a three-tier system landscape. The content is built in a development tenant (t1), quality-assured in a test tenant (t2) and deployed on the productive tenant (t3) once released. Figure 1 gives a schematic representation of the system landscape.
Companies using SAP Cloud Integration as strategic integration hub might have the need to segregate the tenants along the business scenarios which are run with SAP Cloud Integration (e.g. human resources, sales, procurement, finance). ACME currently uses SAP Cloud Integration to integrate their human resources processes. Recently they started to explore SAP S/4HANA Cloud to move their manufacturing, finance and accounting processes into the cloud. When introducing SAP S/4HANA Cloud they plan to use dedicated tenants for SAP Cloud Integration. This will help them to organizationally decouple the tenants along the business processes they are used for.
A company’s data segregation policies is another organizational criteria to segregate the tenant’s purpose. In ACME one subsidiary is not allowed to view the data of the other subsidiaries. Today the only option to physically isolate data access in SAP Cloud Integration is to segregate the data into different tenants. Going forward as outlined in the roadmap SAP plans to offer a capability which allows to authorize data access within a single tenant. This will allow customers to isolate data access according to their specific organizational needs. For now, ACME decided to manage data access by internal governance processes. For tracking compliance to the processes they use the audit log exposed in the Web application of SAP Cloud Integration. Isolating data access into different tenants is not an option for ACME due to the additional complexity.
Depending on the specific customer situation there can be more criteria which need to be considered to decide on the system landscape setup for SAP Cloud Integration. For example, some customers are using a dedicated preview tenant for SAP Cloud Integration where they explore new integration scenarios before deciding on whether to productize them.
Call for Actions:
- Carefully plan your system landscape for integration. Consider legal and organizational criteria to segregate the tenant’s purpose.
- Apply a staged two-tier system landscape for SAP Cloud Integration at minimum.
- In case of extensive development of custom integration content consider to extend into a three-tier system landscape with a dedicated development tenant.
- Subscribe to the roadmap of SAP Cloud Integration to learn about planned future product capabilities.
Accounts in SAP Cloud Integration
SAP Cloud Integration follows the subscription model offered by SAP Cloud as illustrated in figure 2.
Each tenant is provisioned in a separate sub-account from where it is subscribed to the respective SAP Cloud Integration application. All sub-accounts are unified in an enterprise global account owned by the customer. Accounts for SAP Cloud Integration can be accessed via the Cockpit.
Since SAP Cloud Integration is a SAP managed cloud application ACME is not very familiar with the account model of SAP Business Technology Platform. The company mainly uses the sub-accounts for SAP Cloud Integration to perform user access management for their tenants.
Call for Actions:
- Familiarize yourself with the account model of the SAP Business Technology Platform.
- Use the Cockpit to perform user access management for your tenants.
Change the Purpose of a Tenant
Companies might have the requirement to re-purpose a tenant for SAP Cloud Integration. As their system landscape for integration evolves it might be required to adapt the way how a certain tenant for SAP Cloud Integration is used. A tenant used to explore new integration scenarios might be re-purposed into a development tenant for one specific business scenario. A tenant might have to be moved to a data center in another region closer to the main user base.
SAP does not mandate how to use an SAP Cloud Integration tenant as long as its usage is in line with the applicable SAP terms and conditions.
Re-purposing a tenant for SAP Cloud Integration requires manual effort. New integration content needs to be deployed, existing content needs to be adapted, security material needs to be installed, and many more.
To reduce the effort in re-purposing a tenant ACME makes use of the custom domain capability offered by SAP Business Technology Platform. By default, all tenants are accessed on the hana.ondemand.com domain. ACME changed the default URL by configuring domains different from the default one. They use the cpi.acme.com domain to access a tenant for SAP Cloud Integration. Using a custom URL provides the flexibility to change the purpose of a tenant without having to change the URL to access it. Depending on the company’s system landscape setup this will reduce the effort when re-purposing a tenant since the URL configured in the application systems which are sending data to the tenant do not have to be adapted.
Call for Actions:
- Plan how to evolve your integration system landscape in line with your company’s IT strategy.
- Consider using custom domains to reduce the effort to re-purpose a tenant for SAP Cloud Integration.
I hope you enjoyed reading the blog. In case of questions or feedback please feel free to comment on this blog.
Thanks for sharing about this.
I would like to get further clarification on the following statement:-
Based on https://blogs.sap.com/2017/04/14/sap-cloud-platform-integration-standard-content-update-goverenance/, my understanding is that updates are based on subscriptions created when a package is copied from Discover view to Design view. Are you refering to the same thing with “connected to the SAP API Business Hub”? I’m not aware of tenant-wide setting where it indicates if a tenant is connected to the API Business Hub or not.
For Configure-only prepackaged integration content, it is also possible that the package is directly copied from the Discover to Design view in productive tenant, instead of being transported from the test tenant. How would updates behave in this case? Is there a recommendation to not adopt such approach?
Thank you for your comment!
Yes I am referring to the subscriptions created when a package is copied from Discover to Design. I changed the language in my blog accordingly.
Technically it is possible to directly copy content packages from Discover to Design for any tenant. Whether this option is used depends on the specific customer needs. Many customers prefer to control the point in time when the updated integration flows will be deployed in their productive tenant. For content packages flagged for automatic update SAP is determining the update schedule. Customers cannot control when the changes are applied in their productive tenant.