A common question for architects is. Do I need a 2 or 3-layer SAP Cloud Integration/CPI Landscape?
Normally we would say 3 in an SAP world because it is what we are used to. But if you want to cut costs, there are some options and not have a full landscape. We will cover in this blog.
System landscape
In the normal SAP world you have 3 or more tier systems. So you have one system for each of the following tasks:
- Development
- Test
- QA
- Pre prod
- Production
In an on-prem world, this makes a lot of sense because you need to perform the maintenance yourself and learn how you can apply patches and their effect before you apply them to production.
In a cloud environment, somebody else manages the system and ensures they are patched regularly. The SaaS provider has a good understanding of their landscape and impact of the upgrades. You, therefore, don’t need to have the same number of systems in your environment to test the upgrades.
SAP Integration Suite / Cloud Integration Landscape
With SAP Cloud Integration /CPI It is all a cloud-based solution. It is operated all by SAP so you don’t need to spend resources on upgrades and regression testing. Maybe it’s a good idea for you to do so because SAP can introduce changes that impact your integration. You have 1 week to perform regression tests in your landscape to ensure nothing breaks. You can see our tool around SAP CPI testing progress.
I ran a LinkedIn poll to understand the trend.
1 system – 11%
Some uses only have one SAP CPI system, where the productive system is used for both development and production. It is possible to run like this, but it should only be used initially and with few scenarios
2 systems – 48%
This is the most common setup. Was there one system for development and test and the second for production.
3 or more – 41%
Is the normal SAP landscape and the recommended setup for most cases because you got to separate all the data.
There are a lot more reasons for creating multiple landscapes. See the question and answers here.
Reusing a tenant for multiple environments
With SAP CPI, users have often copied the IFlows instead of performing the transports and then changed the name to QA_ to indicate it is the QA version of the package. This is working great to ensure everything is correct.
It has a few pitfalls:
- Developers need to copy the packages manually and to make sure the version is correct
- They may be prone to making last minute modifications direct in the QA/Prod system, so you need to remember to make the corrections again in development for next time
- Skip using Externalized properties and just modify the configuration directly.
- It is impossible to know what the differences are between the two versions and if developers have made modifications
- They will need to handle the configuration
- Once you want to extend, you need to remove all the Prefixes to ensure they are correct
- Developers have access to the full system
- Transporting to production can also be challenging to upload the correct
Automating reuse with Figaf
With Figaf you can automate this process with Figaf. In Figaf you can create a landscape that allows you to handle the modification of IFlow names. We have our virtual agent concept that allows you to create transport the normal way. Figaf will then automatically handle the renaming of objects in the transport process.
You will therefore have a fully functioned transport process that will allow you to
- Approve the transport
- Apply configurations in advance
- Test the transport
- Compare objects in the transport process
We have written much more about how it is possible to create and run transport in virtual environments in this blog post.
This way, you can save a system and still improve the governance of your landscape.
Protecting the virtual assets
Once you have used the tool to move items to the virtual QA, how do you ensure that nobody has access to it and make modifications to it. It is easy to ensure that the artifacts are protected with the access policies in SAP Cloud Integration.
You just create a new Policy with a name for the landscape. In our cloud trial, we are using sampleqa as the name of the IFlows once they are moved into the virtual landscape.
In our standard guide, you will see the following name mapping rules that you can easily change to your own set.
Then you just create a policy like the following where you list all the artifacts and have the pre or post fix configured.
Then once you try to edit with the policy, you will get the following.
To solve the problem, you will need to give the Figaf user the role of the artifact you have created. That way, it will be possible for the Figaf user to modify and create the artifacts for this to work.
To learn how to add this role to use see this please refer to Managing Access Policies, Neo Environment or Managing Access Policies, Cloud Foundry Environment for more details and links to the respective documentation.