Landscape recommendation 2 or 3 Integration Suite Tenants?

[gregorw]

Hello SAP Integration Suite Experts, udo.paltzer, daniel.graversen, 7a519509aed84a2c9e6f627841825b5a,

I have the following challenge:

Currently we're using CPI on BTP Neo to integrate from our on Premise ERP Systems (one for Logistics, one for HR) to external Systems like SalesForce and Government entities. From SalesForece there is also a integration back to the Logistics ERP. The ERP Systems are setup in a 3-System Landscape (Dev, QA, Production). But the Dev system does not contain useful test data. So for CPI currently only two tenants are in place. One connected to QA and one to Production.

With the S/4HANA implementation project the S/4 development system should now also be setup to contain useful test data and allow fully integrated development tests. So for CPI we have now two options:

1. Stay with the current 2-Tenant CPI Landscape but duplicate the Integrations in the QA system to have separate endpoints for the S/4HANA Dev and QA
2. Setup a 3rd CPI Tenant defined as the Development tenant

As the price point for the Integration Suite (Standard Edition) according to the SAP Discovery Center is 4.000 Euro / Month I need to collect pros and cons for it. Here is the collection I currently came up with:

Pros for the 3rd Tenant (Option 2):

• Clear System separation
• No adjustments needed when transporting integrations

Cons against 3rd Tenant (Option 2):

• Developments for the ERP Systems need always be transported to QA to be tested
• If Developments for ERP Systems are done in the QA Tenant we might have the risk that transported objects are accidentally changed

Looking forward for your input.

Best Regards
Gregor

[gregorw]

Thank you daniel.graversen, sunny.kapoor2, martin.pankraz, apalagin, vadim.klimov and ryan.crosby2 for your helpful answers.

[vadimklimov]

Hi Gregor,

A two-tenant model for CPI may be acceptable and convenient if a majority of other systems in the landscape also share the same principle and approach. For example, if the landscape is predominantly formed of SaaS services where two-tenant model is widely used, this approach will extend to CPI nicely.

On the other hand, if applications' landscapes mostly consist of three (or more) systems, and their environments (including a development environment) need to be end-to-end integrated, such an approach is likely to introduce risks and challenges - such as:

• Environment and configuration parity between QA and production environments.
• Execution of performance tests - especially stress tests - and obtaining representative and trustworthy results may become a challenge as QA workloads may clash with (and may get impacted by) concurrently generated development workloads, leading to inaccurate measurements and conclusions. Even though workloads in a development environment shall not normally be extremely high, still we cannot factor out this risk, especially in shared environments and tenants.
• Deployment testing becomes hardly possible - meaning, the first time the deployment process of artifacts and dependencies will get thoroughly tested, will be when deploying them to a production tenant.
• Some aspects of security in CPI are tenant-wide. Some scenarios may rely on usage of tenant-wide certificates for client certificate authentication, treating the entire tenant as a subject for identity (for example, sap_cloudintegrationcertificate). In case security of those is compromised, it will be both development and QA environments that will get affected.
• Another security / maintenance concern relates to some security artifacts that are maintained centrally in the tenant (for example, PGP keyrings and SSH known hosts). The more people have access to those artifacts, the higher a chance that somebody may accidentally overwrite or delete entries in those artifacts, is. Given that in a development environment, it is quite common that access to those artifacts is granted to a broader audience of developers than it shall be in QA, this is an added risk when the same tenant is used for both development and QA environments.
• On a more general note, tightening access and locking configuration of artifacts (both integration and security) that are associated with a QA environment, from accidental changes becomes a more complex task. As a result, in a QA environment, those artifacts may become prone to manual changes done directly in a QA environment, rather than being initiated and transported from a development environment.
• Quite a lot of pre-packaged content in CPI (for example, iFlows and value mappings) is not tailored for multi-environment usage within the single tenant. Modification of such iFlows or copying them to custom packages will introduce additional maintenance effort.

Most of the above mentioned risks may not be significant and material for a small fleet of integration scenarios in the tenant (moreover, some of them may be not relevant to deployed integration scenarios at all), but are likely to expose you to additional maintenance efforts, complications and possible inconsistencies when ramping up usage of a CPI tenant.

Regards,

Vadim

[Mandardesh01]

Thanks Vadim,

Very Good Explanation. Appreciate it.

Regards

Mandar

[DG]

Hi Gregor

There is a 800 EUR tenant version for some cases that is just the Cloud Integration, but there are some restrictions and use cases.

I was hearing about small customers that just went with one system for both Dev, QA and Production. Then they added Dev, QA, or PROD to the different objects which add a lot of confusion.

In the Figaf tool we have added the concept called virtual agents that will allow you to have transport from in the same system. Then the Figaf tool will handle adding/removing of pre and postfix for the objects. That way you will be able to handle transport, configuration and approval much easier.

Daniel

[Ryan-Crosby]

Hi Gregor,

Cost aside, because I would never measure needs based on that. I would agree with the general assessment of vadim.klimov and sunny.kapoor2 in favor of three environments (meaning I think their arguments are in favor of), and the inherent risks thereof as it pertains to only two environments. We have three CPI tenants in our landscape which correspond to three landscape levels for our S/4 environment, and as Vadim has noted it is far easier to segregate security material, certificates, etc. per landscape. We have a further split as we are bringing more legacy systems onto S/4 and require several clients for golden config, mock data loads, break-fix, etc. and this poses further challenges in a dual tenant only setup. On the topic of multiple clients - client copy is your friend and we have executed a little short of a dozen since our big go-live in March (very easy to get usable data in a development environment assuming skilled BASIS and the right data filters).

Regards,

Ryan Crosby

[Martin-Pankraz]

Hi gregorwolf,

judging from your writeup, you would basically want 2 CPI tenants if you can get the configuration right. How about sharing the iflow endpoint between dev and qa? And externalize the configuration of the target connector/system and dynamically pull it based on the sender information? This way you can ensure consistency and transportability to production.

As a result you avoid the redundancy you listed as primary con.

Cloud native concepts want you develop and test in production 😉 2 stages are acceptable but more than that in the BTP layer is replicating the on-premises staging mindest.

KR

Martin

[AlexeyP]

Hi Gregor,

We have decided to treat tenants as separate "environments" so we have Dev/Test/UAT/Prod. It makes the environments mapping much easier (there is a policy to have four environments for each system), makes for better separation of concerns and reduces confusion. Another benefit is that it is easier to manage and restrict access and authorisation depending on the tenant's "role". On the downside it comes with an additional cost.

Hope this helps.

Alexey

[sunny_kapoor]

Hi gregorwolf,

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.

For custom integration content, running a three-tier system landscape is recommended for better quality assurance. 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.

Another advantage of having a dedicated development tenant is that you can strictly control the access via roles in another two tenants so that no one can accidentaly edit or delete the artifact in other two quality or productive tenants.

You can get more insights from this blog post.

Regards,

Sunny

[LukaszS]

Hi sunny.kapoor2

As for restricting access, we can implement this at the level of selected artifacts. For this purpose we can use Access Policies. This is an additional work for managing the environment, but it can be implemented.

[AlexDong]

Hi gregorwolf，

I've already saw very good answers here. Let me add some points.

There are no strict rules on CPI mapping architecture as this is a SAAS. Here is some best practice maybe worthy referenced, if only two SAP Integration Suite tenants are there (even only one) while mapping to DEV, QA, PROD backend systems.

1. Create separate integration packages for DEV, QA, PROD
2. Strictly follow the naming conventions, e.g. path url or artifact ID follows "DEV_***, QA_***, PROD_***"
3. Make use of the access strategy on integration flow level to make sure different roles have different access
4. Configure integration flow rather than hard coded for environment related variables, e.g. the backend connection API path, the integration flow https path.
5. Copy and paste from DEV packages to QA instead of downloading and uploading
6. Leverage artifact version to make consistent between packages.

I believe there will be more from customers or partners as this is also pretty common scenario.

Welcome to add more.

But the best way will be always spending enough money to save effort on development, operation and maintenance.

Best regards,

Alex