Time to upgrade: SAP PI 7.5 Vs CPI

Comparison between SAP PI 7.5 and CPI

At the end of 2020, SAP will finish the support of all SAP PI versions except of 7.5, so customers that are running 7.31 and 7.4 need to take a decision, should we go for SAP PI 7.5 or should we move into the cloud with SAP CPI.

Economical license analysis

Of course, behind this decision there is always an economic impact in the license price and the use of the middleware tool that the client is going to do.

In PO basically we had 3 types of licensing – By number of processors of the machine, number of transactions and (formerly) by number of users, this is complex in practice and often we do not have a clear picture on how much we will pay, how it will be charged, or which is the best option.

The license cost should not be very different from what you were paying for the SAP PI 7.31/7.4 and the possible increment cost could be if you decide to get SAP PI 7.5 license or SAP PO 7.5 license including BPM and BRM.

For SAP CPI, the licensing it easier to calculate and I think this is a great step for SAP towards being more transparent with their customers about the cost of their products.

Here we have a simulation that we did just with the Integration Suite package.

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

The migration to SAP PI/PO 7.5 is a pure technical project because we will barely face cases where we need to rebuild our interfaces due to incompatibilities with our actual interfaces in SAP PI 7.31 or 7.4.

One of the important remarks is that SAP PI/PO 7.5 only allows to have an installation of single Java Stack, if we want to keep an ABAP stack, we should install it separately.

The use of a single stack improves a lot the system’s resources consumption, we can do more with the same system or even we can resize the system to save some more resources. This improvement is quite noticeable and could save money for large SAP PI implementations.

The implication of not having a dual stack is that we need to convert our interfaces that are using ccBPM into a BPM solution or even for some cases we can use this exercise to check if really the ccBPM was needed and explore another possibility of implementation.

We need also to verify that none of our UDF, Java mappings or Adapter Modules we developed are impacted by the new Java 1.8 but in most cases we will be just replacing some deprecates sentences/APIs.

This will imply that we can have a project with a minimum participation from the functional consultant’s perspective, as the logic on the mappings will remain as it was. So only a full regression test should be required after verifying the proper connectivity of the different communication channels.

Under our perspective, this project should be a good middle step before moving into the cloud in the future, so we consider fundamental and we offer it to all our customers to transform all the Integration Builder configurations into Iflows, because this will simplify our future migration to the cloud. The easiest way will be ignoring it and just postpone the problem for another moment in the future, but then you will have to do a bigger step into the cloud, and we believe that it is better to just start walking into that direction with small steps, reducing the business impact.

Another reengineering process to consider in this migration is when the customer has some ABAP interfaces. In this case, we recommend transforming these integrations into Graphical Mappings/Java Mappings/XLST. The other option is installing an ABAP stack in a separate instance, but as we said before, we think it’s the time to take small steps into the future of integration in SAP and not just keep the old problems.

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 are not supported as we know them from SAP PI. There is a workaround were we can consume/publish the services from the SE80 but here we lose all the benefits of being able to generate the proxy in the SPROXY transaction and have the structures automatically created in the ABAP dictionary. Also, SAP expect to solve this at the end of 2021.
• Adapter modules: if we were using standard adapter modules from SAP or 3^rd parties/custom ones, they will not work. Of course depending on the functionality of the adapter, it can be replaced by other SAP CPI options, but we consider that this will not cover all the cases, and to achieve the same functionality we had in SAP PI, sometimes we will probably have to do the development of our own connectors.

Conclusion

We also recommend to not forget the possibility of having both systems in parallel. I think the best approach nowadays should be considering SAP CPI for new implementations, of course only when possible, and use the SAP PI for the custom integrations.

The CPI philosophy is definitely very interesting, and there are a lot of preconfigured content that can make integrations easier. The best example are the different integrations with the tax agencies, with Success Factors, Concur, Ariba… and every day there are more and more possibilities.

To be ready for the future of integration without placing a big risk, we recommend upgrading to SAP PI 7.5 and installing and start playing 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)