Blog Series SAP CPI setup in a multi-stage system landscape using Figaf DevOps

Handling multiple stages (e.g. Development, Test and Production) within an integration architecture is an important and challenging task. From integration perspective you are in paradise, when all your connected systems have the same setup regarding environments (e.g. all systems have one development, one test and one productive system). However, I have rarely seen a company that has achieved this state.

In this blog series, I am going to show you how you can handle SAP integration for complex system landscapes with multi-stage environments. This first part describes the challenge and a set of possible solutions. The next part describes an implementation of a solution using the Figaf DevOps tool for SAP integration. The blog series will be concluded with a lesson learned and a preview to possible improvements.

Challenge about multi-environment system landscape

As already mentioned, the easiest way (or in my words the paradise) contains all systems in the same number of stages.

Integration Paradise – The ideal system landscape

There is no challenge to connect SAP CPI to these kinds of system landscape.

However, most companies have a different situation. As long as you have more SAP CPI environments than backend system environments, you are still good. But what happens when you have more backend system environments than SAP CPI environments? What kind of environments do you connect and how do you achieve a stable landscape?

More complex landscape with multiple test systems

I will use the above example to describe different possible solutions to handle this challenge. I distinguish between four solutions:

1. Get an additional SAP CPI tenant
2. Do not connection development system
3. Change the connection of your test tenant manually
4. Connect your test tenant to multiple systems

Let us have a close look to the possible solutions:

1. Get an additional SAP CPI tenant

You can get an additional SAP CPI tenant to be back in paradise. But often it is not possible (e.g. budget restrictions) are profitable to purchase a full-blown additional tenant which is just needed during test cycles

2. Do not connect development system

Have you ever asked yourself, why you are connecting development systems? I did, because in a lot of companies, I worked with, no real testing was done in development systems. Interfaces get transported early to test systems for end2end testing.

Complex landscape with disconnected development systems

I personally like this approach, because I am sure it works for a lot of companies. But what happens as soon as you get an additional test system or a training system that needs end2end connections? You are in the same situation as before. So please only consider this approach, when you are sure no additional environments will be necessary.

3. Change the connection of your test tenant manually

Based on the testing phase, connect your test tenant either to Test1 or Test2 system. I have done this with some companies, and it is a suitable approach in case you have:

• Only a small number of interfaces
• The chance to connect your complete test tenant to one of the test systems and you do not have to mix it up

I have seen companies that spent nearly one week to manually switch connections from one test system to another (in this case multiple backend systems are involved, and all connections are tested end2end by IT department).

4. Connect your test tenant to multiple systems

You can connect your test tenant to multiple systems.

Connect your test tenant to multiple backend systems

There are two different ways to achieve this:

• Create a routing in SAP CPI
• Copy the complete interface

You can route messages to the correct system within your iFlows. However, that approach requires you to have information for the routing in the message. In this example an Idoc is routed, which is easy because necessary information can be found in the control record of the Idoc.

Example for an iFlow with receiver in separate system stage

I am not a fan of this approach, because you put logic into your iFlow that is only necessary in the test stage, but not in your productive stage. In addition, you need to make sure you have relevant routing information in the message itself.

You can copy all interfaces and provide them twice on the same tenant. In this approach you just need to consider that you must change some parameters like endpoint URLs and you really have to be careful with changes to these artifacts.

Copy your CPI artifacts manually or via a tool

In a first approach, I have tried to copy all relevant CPI artifacts manually. However, this manual task is very time consuming and error prone. I think this approach is ok for a small number of artifacts and simple interfaces. However, in my current engagement we have complex interfaces that are separated into multiple iFlows and the handling of these artifacts is difficult. For this reason an automated approach is necessary. I started to investigate different ideas related to transport management. SAP offers three different approaches to transport objects between tenants:

• File based transport
• Transport via CTS+
• Transport via SAP Cloud Transport Management

None of the SAP solutions gave me the possibilitiy to copy development artefacts inside of one tenant. That is why, I investigated Figaf solution with the DevOps module and how this tool could manage this approach.

Figaf DevOps Tool covers the needs for the entire development process and is a (the only) software that allows you to automate the delivery of your SAP Integration. By using this software your developers can focus on what they are best at, development. No reason to waste their time on filling out paperwork that can be automated.

I finally introduced Figaf in order to set up a virtual SAP CPI tenant.  In the next part of this blog, I will show you how I set up Figaf and what kind of design decisions I made.

Stay tuned.

Further information

Content Transport – SAP Help Portal

CTS+ based Transport in Cloud Platform Integration | SAP Blogs

Introducing SAP Content Agent service: Enhanced Transport Capabilities for SAP Cloud Integration Content | SAP Blogs