At Int4 we’ve recently just finished our first SAP PO to SAP CPI migration project (led by engswee.yeoh) and since many of our colleagues and friends have been asking us what we did learn, we’ve decided to describe a few lessons learned which may help some of you to make a decision if this type of migration is suitable for your landscape. Please keep in mind that this project was fairly small (less than 100 interfaces) and simple (standard adapters, not a lot of custom java coding).
Before you start we’d suggest to also check the "Ultimate Guide to SAP PI/PO to CPI Migration" where you can find our more details on the general concept of SAP this migration process.
Below you can find the most common challenges in the development area:
Each flow needs to be created from scratch in SAP CPI and you can only reuse some objects, like message mappings but also with some restrictions.
There’s no ESR in SAP CPI so you cannot create data types which can be reused by other iflows which means in case you need to update the same data type you may need to do it several times which in case of having tons of objects reusing data types might require some work.
Some of the mapping functions like parameterized values, all types of lookups cannot be used in SAP CPI in the same way so they need to be rebuilt.
Any types of enhanced receiver determinations need to be reimplemented in SAP CPI and similarly to the issues with mappings, you cannot reuse any lookups nor external parameters.
Without ESR, there are very limited options to enhance enterprise services (standard or custom) so if you didn’t listen to some SAP Mentors saying that you should continue using IDOCs instead of going all in into the SAP Enterprise Services you may need to consider other options. For existing proxies, you can use XI adapter but if you need to change something, you may need to change the proxy to the SOAP service and enhance the WSLD in a manual way. It’s also worth creating a single SAP CPI iflow which can manage all incoming proxy calls. Otherwise, you may need to create many URLs in the SAP backend system each pointing to a single SPA CPI iflow’s url.
SAP CPI does not log messages as SAP PO used to so keeping that in mind you may need to implement some custom payload logging yourself. You can either use the standard persistence step (but to view payload you need to use your own, custom build UI) or use a groovy script to log as an attachment to Message Processing Log (MPL), but need to be aware of the 1GB limit (generally not recommended, especially for large payloads).
Payload-based message search can only be used set on an application ID that limits the possibilities compared to SAP PO.
Cannot be done in bulks (like we’ve used to do in SAP PO) and instead, you need to undeploy the iflow so a completely different approach.
As it’s not possible to use tRFC protocol, you need to use the HTTP protocol to communicate with SAP CPI and any SAP backend system (like S/4HANA) but this means that in case IDOC fails you may not be able to reprocess it from SAP Backend as the system does not know where did the failure happen. Also, application acknowledgments (ALEAUD) are not supported by SAP CPI.
Many adapters are not available on SAP CPI – CIDX, RNIF, BC, File, and some like JMS don’t allow to work with external JMS servers.
All custom adapter modules need to be rewritten as the concept of adapter modules does not exist with SAP CPI.
Make sure you can automatically retest all of your SAP PO interfaces on the SAP CPI landscape. You can easily do that with the only SAP native tool which currently supports this type of migration testing – Int4 IFTT. You can learn how to do that in Unit 3: SAP PI/PO to SAP CPI Migrations of Week 2 of the free openSAP course: Virtualize and Automate Your SAP Testing Using Int4 IFTT
Question:
Would you have any other SAP PO to SAP CPI migration experience that you can share?
Before you start we’d suggest to also check the "Ultimate Guide to SAP PI/PO to CPI Migration" where you can find our more details on the general concept of SAP this migration process.
Below you can find the most common challenges in the development area:
1. No automated migration
Each flow needs to be created from scratch in SAP CPI and you can only reuse some objects, like message mappings but also with some restrictions.
2. No central repository for data types
There’s no ESR in SAP CPI so you cannot create data types which can be reused by other iflows which means in case you need to update the same data type you may need to do it several times which in case of having tons of objects reusing data types might require some work.
3. Mappings – can be imported but with limitations
Some of the mapping functions like parameterized values, all types of lookups cannot be used in SAP CPI in the same way so they need to be rebuilt.
4. Enhanced receiver determination
Any types of enhanced receiver determinations need to be reimplemented in SAP CPI and similarly to the issues with mappings, you cannot reuse any lookups nor external parameters.
5. ABAP Proxies – how to handle SXI_PROXY?
Without ESR, there are very limited options to enhance enterprise services (standard or custom) so if you didn’t listen to some SAP Mentors saying that you should continue using IDOCs instead of going all in into the SAP Enterprise Services you may need to consider other options. For existing proxies, you can use XI adapter but if you need to change something, you may need to change the proxy to the SOAP service and enhance the WSLD in a manual way. It’s also worth creating a single SAP CPI iflow which can manage all incoming proxy calls. Otherwise, you may need to create many URLs in the SAP backend system each pointing to a single SPA CPI iflow’s url.
6. Payload logging
SAP CPI does not log messages as SAP PO used to so keeping that in mind you may need to implement some custom payload logging yourself. You can either use the standard persistence step (but to view payload you need to use your own, custom build UI) or use a groovy script to log as an attachment to Message Processing Log (MPL), but need to be aware of the 1GB limit (generally not recommended, especially for large payloads).
7. Monitoring
Payload-based message search can only be used set on an application ID that limits the possibilities compared to SAP PO.
8. Starting and stopping the channels
Cannot be done in bulks (like we’ve used to do in SAP PO) and instead, you need to undeploy the iflow so a completely different approach.
9. IDOC handling
As it’s not possible to use tRFC protocol, you need to use the HTTP protocol to communicate with SAP CPI and any SAP backend system (like S/4HANA) but this means that in case IDOC fails you may not be able to reprocess it from SAP Backend as the system does not know where did the failure happen. Also, application acknowledgments (ALEAUD) are not supported by SAP CPI.
10. Lack of adapters
Many adapters are not available on SAP CPI – CIDX, RNIF, BC, File, and some like JMS don’t allow to work with external JMS servers.
11. Adapter modules
All custom adapter modules need to be rewritten as the concept of adapter modules does not exist with SAP CPI.
What to do next?
Make sure you can automatically retest all of your SAP PO interfaces on the SAP CPI landscape. You can easily do that with the only SAP native tool which currently supports this type of migration testing – Int4 IFTT. You can learn how to do that in Unit 3: SAP PI/PO to SAP CPI Migrations of Week 2 of the free openSAP course: Virtualize and Automate Your SAP Testing Using Int4 IFTT
Further references
- Once you finish checking the development changes, make sure you’re also ready from the operations perspective. More on this in the "Ultimate Guide to SAP PI/PO to CPI Migration"
- Webinar (video) on the same topic can be found here: SAP PO to SAP CPI migration lessons learned – video
Question:
Would you have any other SAP PO to SAP CPI migration experience that you can share?
- SAP Managed Tags:
15 Comments
