SAP PO to SAP CPI migration – lessons learned

[MichalKrawczyk]

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:

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

1. 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"


2. 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?

[JuanJanse]

Hi Michal,

Thanks for this valuable feedback.

 

regards

Juan

[former_member730579]

Great post with specific important aspects to have in mind for this kind of migration.

[NickSYYang]

Thanks Michael for this first hand experience sharing!

Regarding "3. Mappings – can be imported but with limitations"

Could you please explain what "import" means here?

Does it mean you have a copy of PO message mapping in CPI or the mapping step in CPI iFlow points to message mapping in on-premise PO system?

In this project, what reason makes customer moving away from PO into CPI?

Thanks.

[Bhargavakrishna]

Hi Michal,

Thanks for the informative blog. Good asset for SAP PO to SAP CPI migration.

Regards

Bhargava Krishna

[former_member733912]

Hi michal.krawczyk2

Thank you very much for your useful blog, its very good info for SAP PO To CPI Migrations.

 

Regards

Venkata Rao G

[Christopher]

Hi michal.krawczyk2

for 7. there might be a way for extended search with setting a Custom Header in MPL:

https://blogs.sap.com/2020/09/13/sap-cpi-a-guide-to-mpl-search/

 

[rafaelchagas]

Very nice post michal.krawczyk2

Thanks for sharing this experience.

[NareshDasika18]

Hello Nick,

It is possible to establish connection from SAP CPI to SAP PO to import message mappings present on SAP PO to SAP CPI. One limitation here is that, If the message mappings contains any reusable functional libraries then It wouldn't get imported into CPI. To Import these kind of mappings, the work around is remove such reusable FL's and Import.

Regards,

Naresh

[NareshDasika18]

One important feature that is missing on SAP CPI is "Retry" mechanism. In SAP PO, at least the channel would try to establish connection for 3 times. But in SAP CPI, there is no such mechanism. If ever the connection fails in the first try then it can't retry. Using JMS queue mechanism this can be avoided. But the customer should have CPI premium edition.

[former_member216956]

Hi michal.krawczyk2

Thank you for the detailed breakdown.
In your video ( SAP PO to SAP CPI migration lessons learned – video) about your CPI migration experiences, you talk about how UDFs in message mappings can be migrated, but can't be changed afterwards. What about function libraries in this context? Can these be migrated but also not allow modification afterwards, or are they excluded from migration?

Best regards

Christian

[MichalKrawczyk]

Hi Christian,

 

UDFs can be migrated but cannot be edited without PI (so makes no sense from my perspective to use them on CPI)

For libraries maybe have a look at the comments in here:

https://blogs.sap.com/2019/07/17/my-take-on-integration-content-advisor-ica-in-the-real-world/

 

Best Regards,

Michal Krawczyk

[Sven]

Hi, from the blog mentioned in the comments situation today is still the same or I'm doing something wrong 🙂 Integration Advisor Mapping Guidelines not getting useful proposals. Is there any good/complete example? Creating B2B mappings in CPI without B2B Add On including TPM looks quite hard. I hope gunther.stuhec and colleagues will help us here with the current open SAP course Integration Advisor Capability of SAP Integration Suite. Regards, Sven

[rohitpandey98]

Just a lame question, since I am new to this migration world. What about SLD's if they are involved they can't be migrated to CPI right, if not then why so?

[JuanJanse]

Hi Micheal,

thanks for the Insight.

Question : What are the alternatives?

Considering that

• Many say that CPI is not a replacement for onPrem PI/PO


• The migration path from PI/PO to CPI is tricky to say the least.


• CPI maturity still has some way to go before it has close to similar functionality coverage as PIPO

Thanks regards

Juan

[AleGuarneri]

Re point 5 (ABAP Proxies), wonderful solution using MDR and backend Proxy creation. Completely independent from ESR, you'll just change endpoints&co in SOAMANAGER from PO to CPI and you're done (a bit oversimplified but... SAP integration consultants should get it quick). A bit ow rework needed for sure, and for service provider (inbound) proxies you'll also find a way to easily reuse existing ABAP objects. I should do a real blog about this topic but time lacks.

Hope this helps, though.

https://blogs.sap.com/2012/05/14/mdr-defining-web-services-from-abap-without-requiring-pi/

https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP_752/684cffda9cbc4187ad7dad790b03b983/479bcd5b65a9484...

https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP_752/684cffda9cbc4187ad7dad790b03b983/30ded07dc55c4f0...

Cheers,

Alex