Navigating the Upgrade Decision: SAP PI vs CPI

SAP PI VS CPI
SAP PI VS CPI

With SAP ending support for most PI versions except 7.5 by the end of 2020, customers on versions 7.31 and 7.4 face a crucial choice. In the SAP PI vs CPI debate, deciding whether to upgrade to SAP PI 7.5 or transition to the cloud with SAP CPI involves considering the economic impact of licensing and usage. The licensing for SAP CPI tends to be more straightforward, making it a transparent choice for customers. Our simulation with the Integration Suite package offers a clearer idea of costs based on message blocks, aiding this critical decision-making process.

Economical license analysis

Economic considerations always underpin the decision between different middleware tools and licensing costs. Clients must evaluate the financial impact of their choices on middleware usage.

PO’s licensing system was complex, involving three metrics: processor numbers, transaction volumes, and previously, user counts. This complexity often obscures the total cost, how it’s charged, and the best licensing option.

Licensing costs for SAP PI 7.5 should align closely with previous versions, like 7.31/7.4. The cost might increase if opting for SAP PI 7.5 or SAP PO 7.5 licenses, which include BPM and BRM.

SAP CPI offers simpler licensing calculations, a significant move by SAP towards greater transparency about product costs with their customers. This step marks a clear shift in their approach.

In our analysis using the Integration Suite package, we conducted a simulation to provide a clearer cost understanding for SAP CPI licensing.

https://www.sap.com/products/cloud-platform/pricing/estimator-tool.html

The price of the block messages is decreasing depending on how many additional messages you are buying with a range between 7.00 EUR for the first 50 blocks (One block is 10K messages) and decreasing to 2.80 EUR for the blocks when you get more than 25000 blocks.

Of course, clients can get better price when they talk to their SAP reseller partners.

Implementation Cost/Effort

The implementation approach is completely different between continuing with SAP PI and deciding to innovate with the SAP Cloud Platform Integration.

If we decide to continuate with SAP PI 7.5 we will have enough time to migrate to the cloud in future releases when SAP CPI will support an easier way to migrate and will not require a reengineering process to transform our on-premise integrations into Cloud integrations.

Let us see what scenarios we can face in both upgrades:

To SAP PI/PO 7.5

Migrating to SAP PI/PO 7.5 primarily involves technical updates, with minimal need for interface rebuilding, despite the differences from earlier versions like 7.31 or 7.4.

SAP PI/PO 7.5 operates solely on a single Java Stack. To maintain an ABAP stack, separate installation becomes necessary.

Utilizing a single stack in SAP PI/PO 7.5 significantly lowers system resource usage, enabling enhanced performance or downsizing for cost savings, particularly in large implementations.

The shift away from a dual stack requires converting ccBPM-based interfaces into BPM solutions, presenting opportunities to reevaluate and potentially innovate implementation strategies.

It’s essential to ensure our UDFs, Java mappings, and adapter modules are compatible with Java 1.8, with most adaptations involving updates to deprecated components.

This project requires minimal functional consulting, as mapping logic remains unchanged. A thorough regression test post-connectivity verification is sufficient.

We view this migration as a strategic step towards cloud adoption, urging customers to convert Integration Builder configurations to Iflows for easier future cloud migration. Ignoring this step only delays inevitable cloud transition complexities.

For clients with ABAP interfaces, we suggest transitioning to Graphical Mappings, Java Mappings, or XSLT. Alternatively, installing a separate ABAP stack is an option, but we advocate for modernizing integration practices.

To SAP CPI

Nowadays the migration of existing interfaces in SAP PI to SAP CPI is possible but has a lot of limitations.

The first approach should be having Iflows to your SAP PI interfaces that most of the customers that are running 7.31 or 7.4 do not have, also unfortunately, there are a lot of customers that do not use Iflows in their 7.5. But this problem is easy to solve, as we can import the ESR objects and create the Iflows in SAP CPI.

The bigger problems are all the unsupported functionalities in SAP CPI. Lets analyze them, object by object:

  • Graphical Mapping: There is a huge limitation with the Java UDFs as they are not compatible with SAP CPI at this moment, so we will need to rebuild the mappings that contain UDFs into new ones using Groovy script.

We see this limitation as one of the main show stoppers in the full migration from SAP PI to CPI, but based on our conversations with SAP, full migration of Message Mappings with UDF will be available at the end of 2021.

  • Java Mapping: We need to embed the JM call into Groovy script, for that purpose we need to adjust the execution of the JM, changing the InputStream and OutputStream parameters into String type.

Here is an interesting blog about this. Link

Based on conversations we had with SAP, seems that at the end of 2021 CPI will have native Java Mappings.

  • XSL Transformations: No problem here, they work as they were in SAP PI

Additional problems we see:

  • ABAP Proxies, as used in SAP PI, aren’t supported in the same way in SAP CPI. A workaround exists where services are consumed or published via SE80. This method, however, forgoes benefits like automatic proxy generation in SPROXY and structure creation in the ABAP dictionary. SAP aims to address this limitation by the end of 2021.
  • Standard SAP adapter modules and those from third parties or custom ones are incompatible with SAP CPI. While some functionalities might find alternatives in SAP CPI, it won’t apply universally. In cases where SAP PI functionality must be replicated, developing custom connectors may become necessary.

Conclusion

We believe it’s premature for a cloud migration. We’re eager to see SAP’s CPI enhancements in 2021, aimed at simplifying migration projects.

Remember, running both systems concurrently is an option. For new projects, consider SAP CPI, and retain SAP PI for custom integrations.

CPI’s philosophy is intriguing, offering preconfigured content for simpler integrations. Examples include integrations with tax agencies and platforms like Success Factors, Concur, and Ariba, which are constantly expanding.

To prepare for future integrations without major risks, we advise upgrading to SAP PI 7.5 and beginning to experiment with SAP CPI.

If you need to Upgrade your SAP PI to SAP PI/PO 7.5 or want to start using SAP CPI do not hesitate to contact us (info@code10it.com)

Related Post
The mandatory KSeF e-invoicing implementation has been postponed
KSeF postponement post picture

Poland initially aimed to introduce mandatory e-invoicing on July 1, 2024. However, on January 19, Finance Minister Andrzej Domański declared Read more

The e-invoicing Roadmap: Your Pathway to Compliance with Code10
e-invoice roadmap post thumbnail

Delve into the E-Invoicing Roadmap with Code10. We guide you through the complexities of global e-invoicing compliance, offering tailored SAP Read more

Migration to Integration Suite – Regression testing for IDOC scenarios 
Big AI robot helping developers test and find issues in their code

Effective regression testing in PI/PO to Integration Suite migration: Learn how to optimize your project with quality test cases and Read more

SAP PI/PO to Integration Suite: Migration Assessment

This is the first blog of a series to check what SAP can offer to do a migration SAP PI/PO Read more

Categories:

No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *