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

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.

Timeline

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. 

Preparation

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.  

Development

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. 

Testing

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.