Updated November 2020.
In this post we will cover how you can migrate your SAP PI/PO integration to run on SAP CPI.
Why perform the migration
SAP Cloud Integration Suite is the Swiss army knife of SAP Integration. It has many of the things that you need as a developer to make sure you are effective with your development.
The main part of the Cloud Platform Integration. Then you have
- API management for external access and security
- Open Connectors to easily connect with all types of platforms
- Enterprise Messaging so you can use messaging services
- Integration Content Advisor so you can perform mappings much faster based on the business context
Once you have migrated you would have a solid platform to handle all your integration with.
When is the correct time to migrate
It depends on your roadmap and your plans for the correct platform.
If you want more details about which platform to chose then check the post SAP PI/PO vs SAP CPI.
For a lot of scenarios, SAP CPI is a better option than SAP PI/PO.
- Cloud integration
- Technical bpm flows
The places where CPI currently is not as capable is
- On-prem to on-prem. There will be released an integration cell, that users will be able to run on a server in their own landscape. If the systems you are integrating with anyway are hosted in the cloud then it probably does not matter.
- B2B integration: The TPM and EDI support lags a bit. There is the Intelligent Content Advisor that enables you to perform the new B2B Mappinger faster. But it is missing features monitoring, archiving, and Partner configuration.
If you only have a low number of the last two types of interfaces, then it is not a big problem. If you are planning on moving 100s of EDI partners CPI is probably not the right platform at the moment.
If you have less than 50 interfaces it could be beneficial to perform the migration. Then you have one less platform to handle.
If you currently are on SAP PI/PO 7.5 there may not be a lot of value to force the migration thru, but it would make sense for you to perform the migration to see the benefit faster. Then you can learn if the platform is ready for your use.
Steps in a migration
As in any migration, there is a number of steps to perform to make sure you are performing the correct migration and are preparing correctly.
Mapping of used integration
You need to understand what interfaces you are currently using and what kind of patterns they follow. You need to have a good understanding of what is possible with the set of interfaces you are using.
You can start with the Message Monitor Overview and see what is used.
Then you would need to understand the pattern used for the exercise and then
Build PoC of the migration
You need to build a PoC of some of the different types of interfaces to make sure that you know how to handle each interface and then be able to migrate it.
- Make sure you test error handling processes.
- How do you use different types of modules and groovy scripts?
- Know how you will be testing the interfaces
- Create some templates that you want to be using from this.
- Understand how to support it in the future
SAP CPI is a new platform that gives new patterns for integration. In SAP PI/PO you sometimes had to develop flows that were not standards to support some business requirements. They can be designed to support the processes better.
- BPMs like ccBPM/BPMN where you used them to handle a technical process. That can mostly be condensed into just one iflow
- Lookup performed in mappings to get extra data or to set status.
- “Adapters” that can be replaced with Open Connectors
- Bridges or places where PI sends to PI.
- And other places where you have been bordering what the PI can do standard.
And there are probably other cases where you can improve the integration by looking at the process at a different level.
And then there are the places where it would make sense to deprecate the systems that are integrated with because it no longer makes sense. Then you don’t need to create that integration, but there may be a new one that that CPI could support.
Web dispatcher or reverse proxy
If you have SOAP or Rest interfaces that you want to move. Then you can make modifications to the Webdispatcher and instead of sending the data to SAP PI then forward it to the SAP CPI.
You will need to find a way to rewrite authentication.
The idea is to simplify the communication with partners so it becomes less of friction for them.
If you have other reverse proxies or API management in place you may also be able to use them.
Neo vs Cloud Foundry
Such a migration is going to be a huge job. CF is the platform for the future, so it is recommended to migrate directly to it, instead of having to migrate again in 1-2 years.
The only place Neo is better can be in terms of licensing for small installations.
Plan to learn
The migration is going to be a learning journey. You will need to know how the platform can support your integration needs and which part it does not support. Then you need to be able to solve those parts.
The way you run and monitor your integration is going to be different and it makes sense to spend the time on improving the process.
What are your releases?
You want to perform the migration in waves or releases. You should plan with a number of releases so you get to release content along the way.
First release: This should be a small one. Take some different interfaces that cover some different patterns.
It is better if it is internal systems, so you have easier access to switch back when something fails. And there will be things that are not working as expected.
Then create a release that makes sense in terms of risks and where your changes normally happen.
You will need to involve the outside world to ensure that the integration will continue to work. You will need to find system owners of the internal systems and also partners to deal with their integration.
Some of the information you will need are:
- IP Ranges for sending data
- Server IP and Credentials
- Change in performance
- Go live date
- Rollback procedure
Some partners may be more difficult to get access to, depending on your relationship.
Protection via API management
If you have any public-facing URLs it is highly recommended to use the API management in front to ensure that you can ensure the access and security correct. It will enable you to monitor your partner’s transactions and ensure they do not overload your integration systems. It will also give you easier access to switching between CPI platforms if they need to be changed.
You need to create a repository of all the artifacts that you want to reuse. It could be Groovy scripts or standard XSDs that are used in multiple places.
In the Figaf Tool, we have a concept called shared resources for SAP CPI. This will allow you to track all the places where an object is used, and if it is changed, then enable it to be update in the other platforms.
Process for migrating an interface
Create test data
It is vital to test each integration and make sure it works the same way before and after migration if it is a one to one migration.
With the Figaf Tool you can easily collect test data from your productive system and use them as test data. This makes the migration process much simpler. You can see the migration of SAP PI/PO to CPI test data in this blog.
If you are not using SAP PI/PO you still need to find a way to test the new integration works the same way. You have options to create test cases manually with the Figaf Tool.
Create iflow and migrate artifacts
Create new iflow. Preferably from a template, so the iFlow is not developed from scratch.
Then migrate the message mapping and other assets that are useful like WSDL and XSD.
SAP can handle the import of Operation Mappings and Message Mappings.
There can be limitations that are not supported by the platform like RFC lookups etc. So you will need to find a way to move this call out before the mapping.
In most cases, a one to one mapping between SAP PI ICO to CPI Iflow. If it is possible, do consider redesigning your integration. See Redesign iflows.
Testing is a large part of the migration. You need to run lots of tests to ensure that nothing has changed. There can be a difference in how the message mappings work, it is essential that your UDF still work and the logic in the mapping produces the same result.
If you know the differences/variances in input and rules you may be able to have fewer tests. For simple mappings the testing could be rather small, but if you are dealing with EDI structure or complex mappings, you must increase your testing amount.
At Figaf we have created an automated testing tool that allows you to fetch input and output messages from your SAP PI system. Then send it thru SAP CPI and see if everything gives the same result. It is a good way to be able to verify all your logic. Then testing with partners may be much lower.
Configure channels for the flow
You will need settings in the communication channels to ensure that the values are defined correctly.
Plane Go live
You must find a good time to go live on. Ideally sometime outside of peak hours, so you are able to see it performs well.
The time also depends on where you need to switch the action. If it is an SFTP file you can change it when you want.
If it involved multiply partners, then you can also switch partners one by one.
Before you Go-Live you must have a rollback plan. Who should be contacted or what should be done to switch the interface back to SAP PI. If you need to roll back then do it before the peak period.
Activate the interface in the SAP CPI and then disable those adapters in the old platform.
Perform monitoring to see if everything runs successfully.
Also, be involved with the business to see if they see everything as it is supposed to be.
You will need to learn how the interfaces work and what is required to automate the process, so you don’t need to perform the same steps again and again.
You can also look at the tooling required to see if there is room for implements.
Then go back and start with the next batch of interfaces.
What can the Figaf Tools help with
The migration process is a manual process that you need to be spending a lot of time figuring out how you can optimize.
At Figaf we have been building tools to simplify the process of delivering SAP Integration. We believe the standard way of delivering SAP CPI, can be improved dramatically. To ensure better visibility into change and also handling the change process.
The Figaf DevOps Tools have been designed to simplify the process of delivering SAP PI and CPI integration. It works like you are suppose to delivering SAP Integration in 2020.
It can perform testing. To see if the original output message is equal to the new output message. That can greatly simplify the delivery process. There is a need to understand what is being changed from the old to the new system.
It is also able to offer advanced versioning, transport, and documentation tools.
Automated Testing of the Migration
The testing tool can help you automate the testing process to ensure that there are no surprises in the process. It can take messages from your SAP PI/PO system and run them on the CPI system after the conversion. Then you can validate if the CPI behaves as SAP PI. If it does you can simplify your processing.
We are considering different options that will allow you to automate your SAP PI to CPI migration. We already have several different ideas on how we can help automate the process even more and not only the testing part.
The following could be option our platform can handle
- We do have the option to map out host ports etc and enable you to help out with the configuration in the new landscape.
- Copy of other artifacts like XSD, WSDLs
- Mapping of Adapter modules to Groovy scripts
- Other ideas that can help you with your migration
We will help build the tool so you and your developers can be more productive and deliver the integration much faster.
Use the contact us button to ask for our help.