The new Roadmap for SAP PI/PO and SAP CPI Suite

At DSAG (German-speaking user Group) there was a roadmap session that we could see some points from. This is what happens after SAP updated their support for ECC/Business Suite to 2027 it and implications for other tools. 

I would assume that this is the current working model and we will see more updates on this later. There will come an official roadmap later, once everything has been cleared. 

I created a video with some more information.

Biggest takeaways were:

  • PI 7.5 will be the last release but support extended some years until 2027.   
  • So now a new version that we got the impression the last years. 
  • There will be an on-prem version of SAP CPI and API management you can run on your own hardware. With a monitor and development tool. 

I really love this. It will have a lot of benefits to SAP customers. 


Java 8 has been extended support for longer by oracle. So there is no reason to upgrade to Java 11 and create a new version of NetWeaver Java. It would be costly for SAP to upgrade and also for customers so it makes a lot of sense. It is both PI but also all the other applications on the suite.

It would also be a stretch to get customers to move to the next NetWeaver release within 2 years, now have customers that have not upgraded for 10 years. 

I don’t know what the investments will be into PI/PO with this extended support. I would assume they free some capital for not having to perform the upgrade. 


SAP CPI is the path forward and where customers should move. 

Removing PI from the Netweaver stack makes a lot of sense. It was probably 6 months behind cloud deployment and was costly to implement. I would assume there is quite a bit of work to port the framework to use the Netweaver stack compared to the cloud. 

That was the main reason we dropped running our Figaf tool on Netweaver stack. 

My assumptions of this: 

  • I would assume that you need to upgrade every 1-3 months to get support or even be able to use the tool. I expect that SAP does not want customers running 5-year-old versions of CPI. So you need to be able to test and upgrade much more often.
  • If SAP did not have the dependency for Netweaver then CPI can be upgraded to Java 11 and Camel 3.0. 
  • If SAP will allow users to have an on-prem version of the CPI then it means that there will not be a change to WebIDE to develop CPI.

Learn more

If you want to learn more about SAP CPI we have created a course that helps you understand how you can develop SAP CPI, so you can get started faster. On the side you can also find our free version of the course.

If you want to develop and manage SAP CPI better try the Figaf IRT. It enables you to manage, govern, test and document SAP CPI and API management much simpler.

Plan an SAP PI/PO patch or upgrade

How you plan an SAP PI/PO Upgrade or patch. This is what we try to discover in the article

The simplest project is an upgrade from single stack 7.31 or 7.4 to 7.5. The process is the same if you are applying patches or support packs. 

If you have a dual-stack and only using ICOs the projects are the same. You though need to consider the stack split and subsequent delete of the ABAP system. 

If you are using Seeburger BIC for your EDIFACT/X12 then you probably want to perform a migration project in some form. It can be on your current system and then upgrade afterward. 

We have been writing about SAP PI/PO migrations, which you want to move to a new version or if you have to redesign part of your integration. It will be a bigger project but may reduce the risk. 

I have created a video version of the document if you want some other perspective on the content.

Difference between upgrades and patches

In the SAP Java world SAP is delivering a set of Java Archives or compiled classes. In each patch, there is release all to the latest version of all code. The Java applications are delivered in Software Components that contain a set of code. SAP is releasing patches for each Software Component. In each patch, you will always find the latest version of all the code in one patch.

You do not have the option to apply a delta patch as you have in ABAP. It is a full Software Component each time. There is also a dependency between the software components so you often need to upgrade the full stack to the latest release. 

It is pretty difficult to know what the difference is between two patches. You cannot see the mapping engine has been changed in this way. 

The differences in a patch are smaller than the differences in a support pack and a release. But you are anyway getting a bunch of differences that you don’t really know how it will affect your landscape. 

The process should, therefore, be the same no matter what you are applying. 

How often to upgrade

Most companies try to have one patch upgrade every year to stay current on the SAP software.

SAP PI/PO will get 3 support packs in 2020, which is the same as in 2019. It may change. 

 It does depend on how much you need to leverage the new technology. If you are using SAP CPI flow on your PI system, then you probably need to upgrade 2 times a year because that platform is getting more functionality for each release. If you are just using plain old PI message processing, there is not a need for more than every 12 – 18 months, unless you plan to use one of the new innovations.  


Testing is one of the most important things in regards to an upgrade. That is the thing that needs to be a big part of your project. 

Should you be testing

As a vendor with a tool to automate SAP PI/PO testing my answer should by, yes. You need to buy our testing solution. 

I have seen customers upgrade their PI/PO from 7.31/7.4 to 7.5 with some minimal testing and without any problems. So you can upgrade without performing a lot of tests. 

You need to talk with the business about what they accept of risks. 
After an upgrade, there can be two types of errors.

  1. The errors that result in a mapping or processing error
  2. The error that is hidden, and it will not appear as a runtime error

I have seen some of type 1. In most cases, it is possible to find a fix for the problem and resent the message. It does though depend on the speed you can solve the issues. I have seen this some times, in places where we had complex message mapping and use exotic steps. 

We were able to fix it in some time. One of the cases required us to get a patch to fix the issue. 
If you get a message of type 2, it may take a long time before you are able to identify something is wrong and then it will be costly to find a fix for it. It could happen by changing the way of handling queues and could be something we value was placed at the wrong line. 

Identify Testing approach

You need to consider how you want to be testing this project. You have two options depending on how much risk you allow.

  1. Test manually
  2. Automation of tests

Automated testing will give you an ability to run the same test cases multiple times, so you can have them also when you perform an upgrade next time. You need to find a way that is easy to perform.

For the testing SAP PI/PO you can use for Record/Replay: 

  • Figaf IRT tool that we have created that contains a lot of functionality to speed up the testing of SAP PI/PO. You can create a lot of test cases really fast, without much work or knowledge about the content. We would obviously recommend this. 
  • SAP PIT (a Testing tool for SAP PI) It is a part of SAP PI 7.5 sp14.  
  • INT4 IFTT also has a tool that can test upgrades. 

Some are trying to use traditional script-based testing, it does take quite a long time to set something like this up. It will require you to have a business understanding of both sending and receiving applications. 
You may need to perform some manual testing if the approach you have selected is not covering adapters. Then you can write some test scripts on ie the REST adapter. It can be a place where the traditional tool can be used. 
In some cases, the business can accept the risk of the upgrade and then you can ignore the testing.  

What should else be tested

In this, we are mostly just concerned with the testing SAP PI/PO integrations. There is other areas that you should consider testing like BPMN, BRM or the UI Interfaces you are using. 
There are to my knowledge not any automation tool for testing other types of processes, so you have to find the best solution for it. 

Steps for the process

Identify the target release you want to move to

Some customers have an idea about moving to current release -1. I don’t think that it adds as much value in an SAP context because it will anyway contain the same fixes as before. You can just not use the new functionality. 

If you want to see which versions are published check out this guide.


You can of cause speed up the process depending on how much time you have and the urgency in the upgrade. In some cases, I have seen 3 months period for an upgrade if there is a lot of testing required. The bad things are once you have upgraded your development environment, you man cause problems once you are moving new interfaces into production. So that count for not having to spend 3 months on the process but rather 1-2 months. 


Create test cases as baselines on your development system. If you run them on the old system you know they will work on the system.

If you spend the time creating your test cases in your development system, you can easily run them manually after the upgrade. The more you can automate this testing the faster you can get the update tested and go to production.

One of our customers Anadarko Petroleum were able to use the Figaf Tools to create test cases for 300 interfaces in just 3 weeks. Then they could test everything in just 1 week.  


On your development landscape apply the upgrade. Remember to take the latest patches for the specific support pack you apply. You should save the packages that you are going to deploy, so you can apply the same again in the other landscapes.

Spend 1-2 weeks testing in Development. 


Apply the update to SAP QA or Test system. Remember to time the upgrade, so you have an idea about how long the time you need in production. 

Run your technical tests to see if everything stil is okay. 

Ask the business to perform some of the more critical tests. The part about getting business to test is probably the most difficult part. To get them to commit to testing in the timeframe, and if not then they approve the upgrade. 

Production Go live 

Depending on your setup you may need to plan for some downtime for the upgrade.

You can get NZD(Near Zero Downtime) on the system but if it is not required and you can afford some hours of downtime it is preferred. 

I would also recommend a full back up before the upgrade, then you can much easier rollback if something bad happens. 
Once you have applied the patch do check everything working as expected. There can be alerts, in that case, you need to be able to resolve them fast so it put the minimum impact of the company. In extreme case you may need to roll back but it will be rather costly. 

Automate more than just your Testing

Figaf IRT is able to help with more than just your test automation. It enables you to govern and manage your SAP PI/PO transports at a much more detailed speed. 

Signup now.

You can get started and create your first test in 1 hour. 

Secure your SAP PI/PO and CPI test cases

Testing is important for your interfaces. For migration and bug fixes it is important to be able to perform regression tests.

The place you can create the best test data from is from your productive systems, where customers are creating orders with 100 lines with 10 different product types. It is not only from the clinical approach from a user test. You need both.

The bad thing about the production data is, it often contains confidential data. Social security number, payroll data or customer information. It can, therefore, lead to problems if you want to test with it. You may often have externals working on your systems and don’t give them access to confidential data.

Scrambled comparison, user can see there is something wrong but not content

We had to solve this problem with the new innovation. You simply select any of your SAP PI/CPI systems you have connected to and specify that they are confidential. Then all test cases created from that system will be marked as confidential. Then it will only be possible for users with the role IRTSensitivePayloadViewer, to view the original data. Otherwise, you can only see the scrambled version as seen in the image.

It is only possible to run the test on the system marked as secured. With secured systems is meant that it is systems is configured so users cannot view the payloads being processed. We are working on ways to block confidential messages only. It will be a component to filter out the messages and using the web dispatcher.

You can see a video about the testing functionality here.

Over the next patches, we will enable some more functionality like

  • Blocking viewing messages of SAP PI, so you can view your normal test messages
  • Testing SAP CPI with the same approach, where you have a lot of SuccessFactors integration
  • Testing synchronize messages, where the Figaf Tool will work as a proxy to give the results back

This function is really useful for SAP PI/PO migrations where you just want to get a lot of messages from your productive system and let contractors handle the configuration. With this approach, they can test all interfaces.

Try it for your self

You can signup for Figaf IRT and get a free trial. You can get started in 20 minutes.

Webinar: Automate your SAP PI/PO, CPI, and API management

On January 30 I hosted two webinars on the topic of how you can speed you your SAP PI and SAP CPI development processes.

From my conversations with people there seems to be a lot of new integration projects going on. And most integration developers have a way to much work they need to work on. We also see trends towards Agile or DevOps where users need to be able to release code much easier, this is what the webinar is about.

That is why I think automation is the way to go. There is a lot of places where it is possible to automate your SAP Integration processes. I normally see the following 5 areas where it makes sense to automate as much as possible.

  • Development
  • Testing
  • Governance
  • Monitoring/Support
  • Migration  (in another replay see video)

In my webinar, I covered the 3 middle parts where the Figaf tool can help you automate the process.

See how to get started

I want to demystify how difficult it is to get started. So in 15 minutes, I’m able to install and connect to both a PI and a CPI system and setup testing on them. You can see this part after 1:07 hour. 

You can get started at 

SAP PI/PO B2B Add-on alternative

We will in the next period of time see a large number of users that will be performing migrations of their SAP PI/PO platfrom to 7.5. I have created a number of resources on SAP PI/PO Migration. One of the big thing in this migration is the migration from Seeburger to B2B Add-on. We do have a tool that allow you to automate the migration from Seeburger to B2B Add-on message mappings.

B2B Add-on from SAP does work and can give you a way to manage your EDI messages. There are still some gaps in the B2B Add-on solution that could be greatly improved and where i see that an alterntaive solution could be better. It is in the area of:

  • Logging and archiving of messages sent.
  • Partner management and settings usability
  • Configuration of partner connections via AS2, VANS or SFTP.

I had a webinar with Paw Pedersen from BizBrains that created a product called Link. Link is a tool build to manage your EDI solution. It is currently being used to manage B2B for Biztalk, but the same system can be used also for SAP PI/PO. They have been running it for a number of customers from small companies wanting to run EDI to big banks. You will learn about what the solution can help with. You can see the replay here.

They have a number of different configuration options and security settings that are required for banks. They also have large customers with many partners, so they know how to make the application scale.

One of the reasons I think it could be useful for you is that you can switch to their platform and then there is no need to upgrade to the PO license and can stay on the PI License. It can save you a great deal of money and speed up your migration process.

There is a number of different ways the Link solution can tie into your SAP PI/PO solution from

  • Just as an Archive of messages
  • Partner configuration
  • Partner configuration that updates your mappings
  • Using it also for SAP CPI.

If you find the product interesting write to, and get a trial of what the solution can do.

I will be a part of designing a good solution that will make your migration as simple as possible.