Posts

SAP PI/PO Migration

There many companies working on migration or planning a migration of their SAP XI/PI to SAP PI/PO 7.5 systems. Over the years I have created a number of resources that make a lot of sense if you are in the process of considering a migration. Here is one place that you can find all my favorite resources on the topic.

Timeline

One of the drivers for migration is that the support of everything but 7.5 will end in December 2020. That is currently in 20 months time. Not a long time if you need to plan a project, get funding and running the upgrade. I would assume that the minimum time for a migration is 6 months once you got people working on the project. If you need to get the funding you know your companies budget process, so you better get started.

As I read the note 1648480 extended support will not be possible for the Java stack.

Options for upgrading

There are a number of options that you can use when upgrading your landscape. Product manager of PI/PO Alexander Bundschuh has written a list of the different options (13) that you have depending on where you are at the moment. What options for Upgrading SAP PI/PO

My recommendation is to go for a single stack system because the dual stack is not developed anymore. It will also improve your next upgrade because of a simpler architecture. You will have to covert your ABAP Mappings.

Your different options

There is also the option to migrate to SAP CPI, which is the cloud based tool for Process Integration. It have some areas where it can replace a PI and BPM solution, but there are patterns that are not fully optimal yet. It will no doubt be the place where SAP is focusing their development, so you will se a number of improvments there.

If you are not planning to use PO functions like B2B Add-on, BPM/BRM then it is probably best to keep at current license but move to an AEX, Java only version of your system. The only reason they would be to run CPI content on your PO system. If you have a few ccBPM probably consider moving them to CPI or Cloud Workflow.

If you are using B2B Add-on or want to run CPI content locally the PO is the way to go.

There is the concept Stack split that I have heard some customers use. The idea is to upgrade your 7.31 dual stack system to 7.5 with dual stack. In 7.5 they cannot share a system ID so one of the systems will get a new System ID. You will then be able to delete the ABAP system. So you only have a single stack system. It does require that you are using ICO’s for all your integration. I’m not sure if this is a supported process and how it works. Maybe your consultants know how it works.

Outlook

SAP PI/PO 7.5 will be in maitance until 2024. SAP have annonced there will be a new version of SAP PI/PO in 2022. The goal of this version is to support a newer Java version and latest Databases. Release will depend on when they become avabile from vendors.

There is a roadmap for the SAP PI/PO you need to search for Process Orchestration and then login to see the roadmap.

From what I can see on the roadmap it does not look like BPM and BRM function will be improved. You probably need to find another solution for BPM process. It could be the SAP Cloud Platform Workflow or CPI that will allow you to run it. The place where you will see most development is on running CPI content on SAP PO.

Process

The process for migration is pretty simple. It is just something about planning what to do. It does make a lot of sense to get an understanding of how you want to migrate so you can get started and know how it will work. I think it will give you some information to start the migration from. It can be improved and need to be adapted to your model. There are two areas that you need to focus on.

  • Planning: In this, you try to understand what you should be doing with regards to migration. This is where you need to figure out how to upgrade certain elements. This should be considered before you scale up the team. In this phase, you will also be able to see how you automate the solution.
  • Execution: In this part is about making the migration as fast as possible and keep the risk low. Here is where you make a migration of a single interface, test it and then move it to production.

You can read the full post and see all slides and the replay at the link bellow.

Automization of the process

We have been making a lot of tools for the SAP Platform and they do make a lot of sense to apply in any migration project. The more you can automate the easier the process will be. Here are some of the things you can consider for your project.

Understanding your current integration

To understand what part of your current integration and message mappings, we have created a free tool that allows you to see what is going on. It can give you information about which message mappings you have used and how many times they have been executed in the last month. It can also give you information about which modules you have and how they are used. It is a free part of the Figaf IRT application so it is just to try it out, so you can plan your migration.

Seeburger Migration

If you have Seeburger and are considering what options you have for migration then we have a path for it. We have created an automated tool that can take your Seeburger Message mapping and convert it to a B2B Add-on mapping with a few click. You can then save many hours in the migration process. You just select which mapping you want to convert and which B2B structure you want to use. Then the application will take care of the rest. It will cost you a fixed fee per mapping.

You can read more on the application at Seeburger Migration tool or at how the seeburger migration works.

Testing your migration

If you are doing any upgrade or change of your landscape it is really useful to perform test to validate that it works correct. I have in some cases seen that after an upgrade somehting on the mappings had changed behavior. It is therefore a good idea to be able to test that nothing is affected.

You have the following options to Test SAP PI.

  • Manual testing requires a lot of resources
  • SAP PIT a free tool from SAP to test from 7.5 sp14.
  • Figaf IRT a tool build to make it a lot easier to test SAP PI/PO. Is our tool designed to make upgrade testing faster
  • INT4 Iftt a ABAP tool made for testing interfaces. It is good for testing result in the ABAP tables

Comparison the two testing tools, I would recommend the Figaf tool because it makes the testing a lot faster to create and allow you to test your first upgrade. It also contains more patterns for testing and is able to test modules which is important with B2B Add-on.

Automation of the migration process

SAP have a tool that allows you to migrate channels and ICOs. It is a part of the PI system and you just link the two systems together and can then migrate scenarios or channels.

If you find that it lacks some part for processing and want a faster way to do the migration. We have a good understanding of the SAP PI Directory and Repository data model, so we will be able to create an automation for your. Reach our to info@figaf.com, to book a meeting on how we can help.

Anything missing

Is there something missing let me know.

If you any questions on your migration, sent a email to info@figaf.com.

Run Figaf IRT in your own Cloud

We have added the Figaf Cloud. as a way to allow users to run our tool to manage the SAP CPI and API management. It is a great way to scale and deploy your application.

We have it hosted in Google Cloud Platform in a Kubernetes cluster. It i pretty easy to do in GCP and it allow scaling of the application pretty easy. It did take some time to understand how to build the app and secure the application.

For customers, it is a really good way to get started using Figaf IRT because they don’t even need to install anything. And all their partners can get access to the network and run applications. So a customer can run all the application to perform DevOps on the SAP CPI and API management systems. The DevOps include

  • Monitoring and alerting
  • Change Tracking or Versioning, so you can link business requirement with a change
  • Documentation
  • Testing
  • Transport of CPI/API flows

With all the focus on data protection, it may prove to be difficult to control all your data that exists in the Figaf IRT solution. You want to have control of where it is located.

We have an ompremish installation of the Figaf IRT tool and it contains the same features as the cloud, though there can be a bit of delay with it because of the release cycles of the applications. One problem that we often hear is so where should we install the IRT application. It can sometime be deficult to find a database and a Virtual server where the Java application can run.

Cloud

For some customers it is much easier to go buy/start a server in the cloud from GCP, AWS or Azure. You can have a direct connection from the cloud enviorment to your on-premish system and thereby get access. The integration department can then get the server self and run it there.

Our installation is pretty simple you can basicly just start the application with the click of a button. It does require a bit more effort if you want to run it with specific databases and setup SSL. It take 30 minutes to install IRT if you have installed the database. The good thing about the cloud enviorments is they all have the PostgreSQL server that we use as a managed. It will then eliminate some of the Normal DB operations that you are doing and just handle it with a few click in the web configuration.

It will also be possible to provide upgrades fairly simple. We have made a docker image that you can use.

We have added a Docker image to DockerHub, so you can run IRT pretty simple to get started with using it. You will need to make a few configurations to get it running. We have a guide on running it on Azure with the hosted database.

The container for running IRT on a Docker image in one of the places starts at 200 USD a month, depending on how you want to scale and have it to perform.

Try it

You can also try Figaf IRT out on your own laptop fast.

Comparing Figaf IRT with SAP PIT

SAP has recently published SAP PIT, which is a testing tool for SAP PI/PO. Costumers have asked me about the difference between SAP PIT and Figaf IRT. Does it actually matter which tool you use? The answer is: Yes, it does matter. In this blog post, I will give you an overview to help you to understand the differences.

The Figaf tool is a lot faster to use for creating and running test cases on. It also have a lot better integration with a DevOps/Continues Delivery process so you can deliver your integrations lot faster.

Figaf  IRTSAP PIT
Test the followingSender Modules, Routing, Mappings, Receiver ModuleRouting, Mappings
Test case creationAutomatic process multiple recordings at one timeSetup one recording of time
System requirement recordingAll 7.31, 7.4 and 7.5 add a FigafModule or use SAP logging no patches required7.31, 7.4,7.5 patched after February 2019.Fetch data from dual-stack systems.
PI version to run test onAll7.5 SP14
Location of testing application or dataSeparate java server and databaseSAP PI system
Can test your upgrade to sp14YesNo
Running test casesRun full test suites automatedRun one interface at the time
ComparisonXML, JSON, Text, Edifact, X12, BinaryXML, Text
Patterns supportedAsync, Sync, EDISeperator, Bridges: sync-async, async-syncAsync, Sync
Visual display of differenceYesYes (with SP15)
Data anonymizationYes No
Export of test data to PITYesNo
Integrated with Release management and change management toolYesNo
Mapping of business systemsAutomaticManual
Add test cases from failed messagesYesNo
Manual test case creationYesNo
Releases per year123-4 per year
Price10.000+ EUR/year Included in your license

This is based on the 7.5 SP15. SAP has a roadmap to improve the tool but I do not know it.

The Figaf tool we are adding options to also work with creating Documentation of your scenarios, your changes and the test your are running. It also has a component that allows you to monitor the system for anomalies and report custom errors to users. Next release will also feature integration with CTS+ enabling you to run test and configuration on the objects that are changed. So it is much more than just a test suite.

Do you want to know more about Figaf IRT? Then visit www.figaf.com/irt.

What is the test coverage of your SAP PI message mappings

On a customer demo I got asked what is the test coverage of the tool. We do show in the UI how many ICO’s you have test for but how about message mappings and also modules used in your landscape and how many times they was run.

We already build a report that showed how many times a message mapping was run in a given period based on the data in the PI monitor. So it was just about combining the two sources to give users a good view of what is going on.

For each integration flow we added the number of test cases created with the IRT tool. Then number if then propaged down to each message mapping so we can show how many message mappings is tested and more important which is not.

We also added a tab with the modules used in your landscape and how they performed. Probably we also need to add the IRT test cases to this. But it also depend on how people want to with our with our our modules.

Check out the demo and then try it for free on your own system

You can try it out on your own system. Just download the Figaf IRT tool run it on your laptop and you will be able to see the data after the landscape have been downloaded.

Automated SAP PIT Test case creation

A month ago SAP released a testing tool for SAP PI/PO. One thing I have been contemplating a lot is how to test the first upgrade. One challenge with the SAP PIT testing tool is to be able to run a test on your first upgrade with the tool. I do see a problem with the first two upgrades. If you accept the premise that we need to test all upgrades for SAP PI/PO and therefore need a tool for it. Then it has some challenges for the beginning.

The first upgrade

The system needs you to implement OSS Note 2650265 which is an upgrade to MESSAGING SYSTEM SERVICE released February 2019 and applies to many services packs for 7.31 and above. If you want to implement this upgrade you will need to patch all components because they are linked in SAP Netweaver Java. This means that for this to work you need to implement quite a number of changes for it to work. I see the process as the following:

  1. Implement the patch according to the note on your development system.
  2. Since you don’t know if any thing is affected you will need to run a full test with your SAP PI
  3. Implement the note in production
  4. Once the note is in production you can upgrade your development system to 7.5 SP 14.
  5. Then you can start to create test cases on the 7.5 SP14 and validate that nothing has changed. You will then compare production data with data on SP14 so you cannot compare how the upgrade works.
  6. Once you are done with creating the test cases you can implement SP 14 in your landscape
  7. Next upgrade can be made a bit easier because you have the test data

For me it does sound like a lot of extra manual tests and changes to your landscape limiting how much you can do in the process.

Figaf IRT

The Figaf tools allow you to test all SAP PI 7.31, 7.4 and 7.5 system without installing new support packs. We have a number of options to record messages. Either as SAP is doing with looking in the log messages, except we can use a patch that is 2 years old to enrich your monitoring web services. Or we even have a web scraping option that is even older than it. But we do have a better solution which is to add a module to your processing chain. That way you can test much faster on your system with a lower impact on them.

Screenshot of the new button to export data to PIT

SAP Customers prefer to use standard tools, in the places where it makes sense and they can find enough value. We, therefore, are working on a way to enable you to export your Figaf IRT test cases to SAP PIT, so you can stop using the Figaf tools for testing. This way you can use Figaf to help test the first upgrades and then use SAP PIT for the future

We do hope that we are proving enough value together with ways to make your SAP testing better and faster, and also allow you tigth itnegration to test the interfaces that you are changing.

How how does the migration work

It is a pretty simple just process. Once you have a Testing Template in Figaf IRT and have run it you will see the Export to PIT button. The messages then exist on your SAP PI system. Figaf IRT will create a Test Suite in PIT with the same messages. IRT know which messages should be added to the test cases so it will request. Then it is just up to PIT to fetch the messages.

It is a licensed feature of the Figaf IRT so you will need to purchase a license, it can save you some time for your testing.

You can see a demo of it here.

There will be a few more changes to make for the process to work, like:

  • Set a name for the template
  • Send ignoring elements over to the test case
  • Update it the process if PITs API is changing since it is not published.

There may also come future development in the PIT tool, we can use to run this process better. Lets see in the next support packs. It is possible to add running of tests cases and integrate it with our DevOps appoach so you can test the interfaces that is changed by a mapping.

If you want to see how fast you can create test cases in Figaf and run your tests in it then download the tool for free and get started in an hour. We do also have many extra features that you will not find in SAP PIT.