In this blog series, I describe how I handle the challenges of system landscapes with multiple environments.
In the first part of the blog series, I gave you an introduction to the challenges in multi-stage environments. I concluded the first part with different solutions, how you can handle these challenges with different approaches. In this part of the blog series, I describe how I handle the challenge in my current engagement. The third part of the blog series will conclude with a lesson learned and possible improvements.
As described in part 1 of this blog series there are multiple ways to set up your system landscape with multiple environments. In my example we talk about a system landscape with six environments as maximum (see below)
The landscape consists of two development systems. One is used for maintenance activities while the other one is used for the development of bigger projects. For SAP systems the retrofit functionality of Solution Manager (see Dual Landscape Synchronization (Retrofit) - SAP Help Portal) is used to synchronize developments between project and maintenance landscape. In the project landscape, two test environments are in place.
SAP CPI landscape has a traditional structure with three environments (see below). So, I faced the challenge to connect five backend systems with two SAP CPI Tenants (production environment should be clear how it is connected).
As already mentioned in the first part of this blog series, I tried a few approaches to handle the transports without the support of Figaf Tool. However, I found that this is not the best approach for my requirements and had the following findings:
Virtual tenant
As a reminder, the approach of a virtual tenant means, that you connect one tenant to multiple backend systems. In order to achieve this, you copy your design objects, so that you have every object twice on one tenant (you need to find a logic for naming as the name of an object must be unique on a tenant). See Part 1 of this blog series for details.
As I was investigating Figaf for Test automation during this time, I spoke to Daniel Graversen about our challenges in our landscape and he gave us the opportunity to test the transport handling with Figaf. In addition, he gave us some valuable advice on how to improve the handling and so I decided to implement Figaf for transport handling and replace the CTS+ based transport handling in SAP CPI.
Together with daniel.graversen and colleagues, I made some brainstorming sessions to find the best solution for my case. Basically, I had the following requirements:
In addition, we came to the following assumptions:
Finally, we found the following setup of the landscape as our best fit.
Please be aware that all design decisions have been done with older releases of Figaf and SAP CPI. With newer releases, other designs could be more valuable (I come to this in part 3 of this blog series)
We decided to implement two transport landscapes in Figaf:
The reason is the separation between maintenance and project landscape (see requirement 5 above). For a development object that has been changed for a project and could be in Test 1 or Test 2 now, I wanted to have the possibility to do a maintenance change in the meantime without influencing the test in the project environment.
In addition, I described a process how to use the landscapes for my developers to ensure they pick the right transport landscape and handle changes properly:
What do I have to do…?
…when I implement a new interface?
Develop it in the correct package in the development tenant. Afterward use CPI Standard Transport to transport the interface into a virtual tenant, test tenant, and production tenant.
….when do I need to change an existing interface for a project?
…when I need to perform a bugfix or need to change an existing interface for maintenance purpose?
Check if the interface version in the development tenant is the same as in the production tenant. This can be performed via the Figaf Tool.
Versions are the same in both systems
Good, there is no ongoing change for the interface in a project. Make your adjustment in the existing interface in the development tenant and transport it via CPI Standard Transport into the virtual tenant, test tenant, and production tenant.
A version in development tenant is higher than in production tenant
Make sure you have enough time to finish the maintenance change before project go live. If you have doubts, contact your colleague who is working on the project.
You have enough time left. Good, now the magic begins:
The implementation of this design in Figaf is simple.
In the first step, you need to create three agents for your three CPI tenants. In the simplest configuration, you just need the URL of your tenant and an S-User account (with password) on the tenant. Of course, there are a lot more settings, that can be configured if wanted (e.g., GIT Integration, Polling and synchronization job settings, …)
In the second step, you need to configure the transport landscape. We have defined them as followed:
As already described, I use the virtual tenant in my CPI Standard Transport lane. In addition, I have also activated approval functionality to ensure no developers or external vendors can transport into the production system on their own. Every transport must be approved by a change board and this approval step is documented in Figaf via the approval functionality of the transport lane.
Now you are ready to transport development objects.
In Figaf you cannot create a transport directly, but only via ticket. I decided to use one ticket per development object, instead of one ticket per change.
There a several Pros and Cons for both approaches but let me try to show why I think it is best to have one ticket per object. The main benefit to have one ticket per change is that you can move several objects in a single transport. However, if you need to re-transport only part of the objects for this change again, then this is not easy to handle (especially with a high number of objects in the transport). In addition, you cannot really see that an object is already in a transport for another ticket and you get only a message during import when it comes to a version mismatch.
When you use one ticket per object, then you can use this object perfectly to see the complete transport history of this object. Additionally, you can always see in the ticket status if the object is already in transport. In case you trigger a new transport, the old one gets inactive and cannot be used anymore. The downside of this approach is, that you have several tickets and transports for one logical change (e.g., for a bigger project release I had around 60 transports).
One of the features that I really like in Figaf DevOps is the transport configuration. In SAP CPI you have the possibility to externalize parameters that can be configured in all CPI tenants. I assume most of the companies using SAP CPI also leverage this feature. However, in my opinion, this can give you the chance to change the behavior of your iFlow via this configuration. And this change is not really documented (only that you see who deployed an iFlow last and when). With the transport configuration functionality, you can define the parameters during or upfront of the transport itself. That reduces the amount of rework after the transport itself and in most cases, you simply can deploy your development object (btw. you can also let Figaf do the deployment). Since version 2103, you can define parameters that should be replaced by Figaf automatically (no need to change them manually in transport configuration). I use this feature for hostnames & ports as well as the name of user credentials. This reduces the number of parameters that must be configured significantly. Another new function is to transport the configuration only. So instead of changing the parameters directly in the SAP CPI tenant, you can change them in Figaf and only transport the configuration without the iFlow itself.
In this part of the blog series, I gave you more insights into the handling of transports with Figaf DevOps. I described our requirements and how we came to the design of the transport landscape and finally showed you the implementation in Figaf itself. In the final part of this blog series, I will give you insights into lessons learned and possible improvements from my perspective.
Stay tuned.
Blog Series SAP CPI setup in a multi-stage system landscape using Figaf DevOps
Figaf transport system for SAP PI/PO, CPI and API mgt
How Figaf can help manage SAP CPI | SAP Blogs
Content Transport - SAP Help Portal
CTS+ based Transport in Cloud Platform Integration | SAP Blogs
In the first part of the blog series, I gave you an introduction to the challenges in multi-stage environments. I concluded the first part with different solutions, how you can handle these challenges with different approaches. In this part of the blog series, I describe how I handle the challenge in my current engagement. The third part of the blog series will conclude with a lesson learned and possible improvements.
Multi-stage environments in SAP landscapes
As described in part 1 of this blog series there are multiple ways to set up your system landscape with multiple environments. In my example we talk about a system landscape with six environments as maximum (see below)
Backend Landscape with multiple environments
The landscape consists of two development systems. One is used for maintenance activities while the other one is used for the development of bigger projects. For SAP systems the retrofit functionality of Solution Manager (see Dual Landscape Synchronization (Retrofit) - SAP Help Portal) is used to synchronize developments between project and maintenance landscape. In the project landscape, two test environments are in place.
SAP CPI landscape has a traditional structure with three environments (see below). So, I faced the challenge to connect five backend systems with two SAP CPI Tenants (production environment should be clear how it is connected).
SAP CPI Tenant Landscape
Handling without Figaf
As already mentioned in the first part of this blog series, I tried a few approaches to handle the transports without the support of Figaf Tool. However, I found that this is not the best approach for my requirements and had the following findings:
- Backend Teams do not really use Development environments for End-2-End Testing
- Nobody was aware which environment is connected where and why
- Integration team often must change connections for interfaces which is time-consuming
- With CTS+ doing transports based on packages is not a good approach and can lead to a mess in production design time when you use bigger packages (this is fixed, you can now transport single objects with CTS+ as well)
- Handling virtual tenants manually is time-consuming and error-prone
- Some resources must be increased on your tenant that hosts the virtual tenant (e.g., number of JMS queues, …) – depends on the type of contract
Virtual tenant
As a reminder, the approach of a virtual tenant means, that you connect one tenant to multiple backend systems. In order to achieve this, you copy your design objects, so that you have every object twice on one tenant (you need to find a logic for naming as the name of an object must be unique on a tenant). See Part 1 of this blog series for details.
Handling with Figaf
As I was investigating Figaf for Test automation during this time, I spoke to Daniel Graversen about our challenges in our landscape and he gave us the opportunity to test the transport handling with Figaf. In addition, he gave us some valuable advice on how to improve the handling and so I decided to implement Figaf for transport handling and replace the CTS+ based transport handling in SAP CPI.
Requirements for the landscape
Together with daniel.graversen and colleagues, I made some brainstorming sessions to find the best solution for my case. Basically, I had the following requirements:
- All three test environments should be permanently connected to SAP CPI
- A clear approach to which tenant we connect which test environment without exceptions
- Optimize the landscape to reduce rework after system copy of backend systems
- Development objects that are tested with maintenance test environment and in Test 2 of project landscape must have original object names (the same name like in production) due to regulatory requirements
- Defined process to handle changes on the same development object in project and maintenance environment at the same time
- Reduce manual effort for virtual tenant
In addition, we came to the following assumptions:
- There is no need to connect development environments for backend systems
- Maintenance changes or bugfixes are done in a short timeframe, while project changes can take up to six month
- The probability to change one object for maintenance and project at the same time is low
- Version management is crucial for the success of the approach and developers need to follow them strictly
Finally, we found the following setup of the landscape as our best fit.
Please be aware that all design decisions have been done with older releases of Figaf and SAP CPI. With newer releases, other designs could be more valuable (I come to this in part 3 of this blog series)
Concept of the landscape
We decided to implement two transport landscapes in Figaf:
- CPI Standard Transport
- CPI Fast Transport Lane
Implemented Transport Landscape with Figaf
The reason is the separation between maintenance and project landscape (see requirement 5 above). For a development object that has been changed for a project and could be in Test 1 or Test 2 now, I wanted to have the possibility to do a maintenance change in the meantime without influencing the test in the project environment.
In addition, I described a process how to use the landscapes for my developers to ensure they pick the right transport landscape and handle changes properly:
What do I have to do…?
…when I implement a new interface?
Develop it in the correct package in the development tenant. Afterward use CPI Standard Transport to transport the interface into a virtual tenant, test tenant, and production tenant.
….when do I need to change an existing interface for a project?
- Develop the change in the existing interface in the development tenant.
- Afterward, use CPI Standard Transport for transport
- Import interface into virtual tenant and connect it against Test 1 environment
- Import interface into test tenant and connect it against Test 2 environment
- With the project go-live import the interface into the production tenant and connect it against the production environment
…when I need to perform a bugfix or need to change an existing interface for maintenance purpose?
Check if the interface version in the development tenant is the same as in the production tenant. This can be performed via the Figaf Tool.
Versions are the same in both systems
Good, there is no ongoing change for the interface in a project. Make your adjustment in the existing interface in the development tenant and transport it via CPI Standard Transport into the virtual tenant, test tenant, and production tenant.
A version in development tenant is higher than in production tenant
Make sure you have enough time to finish the maintenance change before project go live. If you have doubts, contact your colleague who is working on the project.
You have enough time left. Good, now the magic begins:
- Go to the development tenant and revert to the version that is available in the production tenant
- Make your change (save as new version) and let business test in test maintenance environment and the interface running in development tenant
- Business test was successful. Great prepare a transport via the fast lane. Get approval from the change board and let the change being imported into production tenant.
- After import into production tenant make sure your bugfix is implemented in project version of the interface as well. To do so, you must merge your new version with the version which is available in virtual tenant. Unfortunately, this is a manual task. Make sure you create a new version for this merge as well.
Implementation in Figaf
The implementation of this design in Figaf is simple.
In the first step, you need to create three agents for your three CPI tenants. In the simplest configuration, you just need the URL of your tenant and an S-User account (with password) on the tenant. Of course, there are a lot more settings, that can be configured if wanted (e.g., GIT Integration, Polling and synchronization job settings, …)
In the second step, you need to configure the transport landscape. We have defined them as followed:
| CPI Standard Transport | |||||
| Order | System ID | Virtual | Dev | Approval | Connected System |
| 1 | Development | X | Test (Maintenance) | ||
| 2 | Development | X | Test 1 (Project) | ||
| 3 | Test | Test 2 (Project) | |||
| 4 | Production | X | Production | ||
| CPI Fast Transport Lane | |||||
| Order | System ID | Virtual | Dev | Approval | Connected System |
| 1 | Development | X | Test (Maintenance) | ||
| 2 | Production | X | Production | ||
As already described, I use the virtual tenant in my CPI Standard Transport lane. In addition, I have also activated approval functionality to ensure no developers or external vendors can transport into the production system on their own. Every transport must be approved by a change board and this approval step is documented in Figaf via the approval functionality of the transport lane.
Now you are ready to transport development objects.
Use of tickets
In Figaf you cannot create a transport directly, but only via ticket. I decided to use one ticket per development object, instead of one ticket per change.
There a several Pros and Cons for both approaches but let me try to show why I think it is best to have one ticket per object. The main benefit to have one ticket per change is that you can move several objects in a single transport. However, if you need to re-transport only part of the objects for this change again, then this is not easy to handle (especially with a high number of objects in the transport). In addition, you cannot really see that an object is already in a transport for another ticket and you get only a message during import when it comes to a version mismatch.
When you use one ticket per object, then you can use this object perfectly to see the complete transport history of this object. Additionally, you can always see in the ticket status if the object is already in transport. In case you trigger a new transport, the old one gets inactive and cannot be used anymore. The downside of this approach is, that you have several tickets and transports for one logical change (e.g., for a bigger project release I had around 60 transports).
Use of transport configuration
One of the features that I really like in Figaf DevOps is the transport configuration. In SAP CPI you have the possibility to externalize parameters that can be configured in all CPI tenants. I assume most of the companies using SAP CPI also leverage this feature. However, in my opinion, this can give you the chance to change the behavior of your iFlow via this configuration. And this change is not really documented (only that you see who deployed an iFlow last and when). With the transport configuration functionality, you can define the parameters during or upfront of the transport itself. That reduces the amount of rework after the transport itself and in most cases, you simply can deploy your development object (btw. you can also let Figaf do the deployment). Since version 2103, you can define parameters that should be replaced by Figaf automatically (no need to change them manually in transport configuration). I use this feature for hostnames & ports as well as the name of user credentials. This reduces the number of parameters that must be configured significantly. Another new function is to transport the configuration only. So instead of changing the parameters directly in the SAP CPI tenant, you can change them in Figaf and only transport the configuration without the iFlow itself.
Example for configuration of replacement strategy
Summary
In this part of the blog series, I gave you more insights into the handling of transports with Figaf DevOps. I described our requirements and how we came to the design of the transport landscape and finally showed you the implementation in Figaf itself. In the final part of this blog series, I will give you insights into lessons learned and possible improvements from my perspective.
Stay tuned.
Blog Series
Blog Series SAP CPI setup in a multi-stage system landscape using Figaf DevOps
Further information
Figaf transport system for SAP PI/PO, CPI and API mgt
How Figaf can help manage SAP CPI | SAP Blogs
Content Transport - SAP Help Portal
CTS+ based Transport in Cloud Platform Integration | SAP Blogs
- SAP Managed Tags:
1 Comment
