SAP XI/PI dualstack to SAP PO/PI single stack migration


Migration from a dual stack SAP PI to a single stack SAP PI/PO system is a big task.

Many organization is at the moment is in the process of migrating It is away to stay agile and be able to use the newest releases and solve the issues the business requires.

There is also some performance reasons to move to a new SAP PO system because it optimized for faster processing of messages and easier maintenance. PO will also allow your users to interact with processes across the platform.

There are two approaches to it.

1) Upgrade the dual stack system to 7.5.
2) Fresh installation of 7.5 single stack

1) Upgrade to 7.5

With 7.5 the ABAP stack is separated out to a new system id. This feature enables you to delete the ABAP stack and giving you a regular 7.5 system.

There is also the option to upgrade and keep the system as a dual stack system. I don’t think it is a good idea because you are stuck with the same infrastructure and have to get away from the dual stack at some point.

The benefits are:

  • That you don’t have to configure a lot of things again.

The challenges are:

  • It will be a big bang implementation, and everything is moved at once. You better hope it will work after you have tested
  • There is a requirement that you only have configured everything with ICO so it is a java only installation.
  • You don’t have any ccBPM or that you can easily convert the processes in the upgrade.
  • It is not a supported upgrade from SAP, but some partners can do with success.
  • Long downtime while the update takes place
  • You have to be migrating from a 7.31 or 7.4 system for this to be an option.
  • It is difficult to perform any support while the operation takes place.

2) Fresh installation of PO

It gives you a fresh start on your development so you can configure the interfaces with the newest approach.
There is migration tool on SAP PO, which will allow you to migrate dual stack flow to ICOs. The tool has some limitations and will not be able to migrate everything.

The benefits are:

  • You can migrate one interface at the time or in batches. So you will not have any downtime and can verify that the new system works.
  • You can check the new adapters work if you are moving from a Seeburger AS2 to SAPs AS2 adapter.
  • You can use the BPMN modeling tool from the beginning of the project.
  • New platform running on newer hardware and operating system.

The downsides are:

  • It takes a lot of time to move everything gradually.
  • There needs to be coordination with partners to make sure that the messages work correctly.
  • You will have two landscapes for a period that you will have to maintain.

Steps in the migration

A migration should consist of the following moving of objects.

1) Perform a proof of concept test to determine if the new system is working as expected. My experience has shown that there are non-critical messages with low volume that can be switched over to see if those work correctly, without risking the test on critical messages. If something is wrong with the process it is possible to do later.
2) Migrate the high-volume elements and continue to monitor how the migration is working. You want to be sure that your new system can handle the workload; although hopefully, it should be easier to get the same number of messages processed.
3) Move on to the critical interfaces. Now you have a proven system and you can move critical interfaces and make them run better on the new system.
4) Migrate the remaining interfaces. This is the part that can take a long time, especially if you have interfaces that run once a month or less.
5) If the business has requested any change to their existing interface, now is a good time to migrate those interfaces as well, since it will need to be done at some point anyhow. This also makes for a cleaner migration because you will have only one place where development needs to be done. If it involves three parties that will need to make changes, then it is best to migrate it all at the same time.

 

Testing

For both points, there are some challenges with the testing. You don’t want to test too much with the business. Business people often don’t care about such migration because it will not give them new ways to reach out to their customers.

There have been reported some changes in how adapters or message mappings work. They are not a big difference but if your application is using some of the features affect it can have a serious impact on your business.

You will need to ensure that messages processed will not be any different once they are processed on the new system. It can take some time but if you can perform it automatically, then you are far ahead.
There is the Integration Regression Tool from Figaf that allows you to easily test SAP PI/PO integrations. It does take some effort in getting up an run, but it will enable you to test better and with a lot more documents. It will also allow you to install patches more often and ensure your system is on the latest release.

Seeburger to B2B add-on

I wanted to have a full section on seeburger. Because it is one of the technologies that are going away. If you are using it it does have an enormous impact on your business.

If you are using Seeburger EDI converter or tools there may be quite a bit of extra work you will need to migrate.
Last time I checked Seeburger does not support on 7.5, so you will have to migrate all your Seeburger tools to SAP B2B add-on in the process. Even if Seeburger supported 7.5 it would still make sense to migrate because B2B Add-on has more features and can simplify your landscape.

The adapters are configured differently, so you will have to learn how to use the B2B Add-on adapters instead of the Seeburger version. There are some differences, so it is not possible to do an automated conversion of them. For instance is AS2 Partner number on the B2B Add-on adapter where seeburger is using the attribute from the parties selected.

For EDI handling there is also some differences.
For the EDIFACT, X12 messages the XSD structures is a little different, because some elements have been renamed and changed position. Users will, therefore, have to remap the two structures. This change can be done in different ways:

  • Create a XSL(T)/Message mapping that can convert between the seeburger and b2b addon message. That way you can continue using your existing mappings. It will cost some runtime performance to do the conversion between the formats.
  • Remap the message mapping to follow the new format. Repository helps with this. It will experience say it takes around 1 hour pr message.
  • Remap using a tool like SMT from figaf. This does the smae as you would do in the repository but just automated. For more information see https://figaf.com/tools/seeburger-migration-tool/

The inbound processing of the EDI document is also different. You can use one connection for all inbound document because you can use the Trading Partner Management (TPM) to customize each partner.

The TPM many also enable you to restart all mapping all your messages so they follow the newest conversion. It is a big task but may simplify maintenance of your documents.

See also
https://blogs.sap.com/2016/04/06/b2b-addon-compared-with-seeburger/

Get more information about migration

Happy migration

 

Tool to get BPM context data from a SAP PO BPM

One of the benefits to having a team of developers at your disposal like I do to create my SAP PI/PO test tool is, the ability to create cool applications to solve problems. So I’m really happy that I can give a free tool away to the people that have the same challenge as I ran into.

I have a client where we were using BPM to have some user actions in. Sometimes they wanted to restart the BPM process with the same data or minor changes. I could see the payload in the BPM monitor as on below.

This did not give any information about how I could download the message. I know if the process is failed I’m able to edit the payload of a message, but this is obvious, not true if the process is completed.

There was no API for getting the data from my research at the point.

So we had to create our own tool to handle the queries.

We found the table in the database that housed the Context Data and then started understanding how it worked. The context data was encoded in an XML structure with base64. Then it was just to build a simple user interface on top of it.

It should be easy to find the correct document and so we added a function to make xpath in the data to get the correct data. So we ended up with the following UI.

 

If you want to get it. You can get it for free at http://figaf.com/tools/figaf-bpm-extractor/.

The build includes sources so you can optimize it your self.

 

 

 

 

Retiring the SAP PIDocumenter and Diff tools

I have retired my documentation tools.

The reason is that they used an old form for documentation and SAP PI/PO did no longer support the use of XIM files. It was therefore not as much the tool was used anymore.

I have created a short guide to how you can export your mappings to an Excel sheet with NWDS. I’m not to found of the layout of it but it does support standard and also export UDFs. So it is an easier way to make the documentation.

How to document SAP PI/PO Mappings using NWDS

SAP PRO Support tool update

I know that for a lot of you the support of the SAP PO systems can be a difficult task. If you are a developer, it can become something you dread talking about —  you would prefer spending your time creating new integrations. If you are an integration manager, you probably see that your developers are spending too much time on support and not enough on creating new developments.

The integration landscape is becoming more complex, more difficult to manage, and it also plays a more critical role. What happens if your interfaces are not running for 30 minutes? Will you be able to deliver the products to your customers? What will the impact be?

As a developer, I focused on creating a tool that would allow me spend time on the most critical support issues, and be able to get back to creating new integrations. It can sometimes be daunting to go through all the old issues to find what is going on.

I have created a short video on what Figaf POSupport is about.

I want to give my customers as good an experience as possible, so I am making an introductory offer that will last until December 31.

The price will be just 2500$ per productive system, a 500$ discount.

I’m introducing a Founders club for all the initial users of POSupport. We will have monthly web meetings where we will talk about support, and what best practices are. It will be a way for all members to learn how to make a better support setup.

For the first 5 that purchases, I’ll provide a 1-hour setting up session, where we will go through all the setup steps on your system.

I want to be able to support all new clients, so the deal will be limited to 20 participants only.

What Figaf POSupport can help with:

  • Automate error handling, like cancel, resend or notify business or the ERP system

  • Document error handling, so all developers/supporter workers can help solve issues

  • Give insight into what errors have occurred on your SAP PI/PO system
There is a free 30-day trial that you can install, and see for yourself what the tool can do.

To get started click here. 

new product, support helper to SAP PI/PO/PRO

I’m happy now.

The reason? I’m finally ready to share my newest creation with you! It is something that I have been spending some of my spare time on during the past few months.
Meet my POSupport tool

I have created Figaf POSupport because I saw that a lot of customers were not handling errors well in their SAP PI/PO systems. They had configured the Component-Based Message Alerting and were getting a lot of errors to their mailboxes, but they were not doing anything with them, because it was difficult to process the alerts, to figure out what the alerts were referring to, and to understand why they happened.

SAP Support Tool -POSupport

SAP Support Tool -POSupport

The POSupport tool can help you organize alerts, while assisting you in the processing phase. You can easily define rules with Xpath, which categorizes the alerts that occur. In the rule you have various options:
You can define an email concerning the solution to an issue, which should be sent to the support organization. This rule could be a great place to store your knowledge about the repeated errors that occur.
You can mark the message as canceled, so you don’t have to deal with it anymore
You can re-send messages that had problems caused by adapter errors; the messages will be re-sent every 30 minutes, until they can be processed when the system is up again

You also get a tracking function of the alerts that occur in your system; using the tracking function, you can update the status of the alerts, along with how they are handled.

There is a 30-day free trial that you can download, and get started with. My guess is that it will take you 1 hour to install and configure. It should make you see howPOSupport works.

This is the first version of the tool, so there are still more features that I would like to add. After trying it, you will probably have your own ideas on what it should contain. Please, let me know what you think: what could be improved? What should be added to it? I would like to add some reporting capabilities, so you can get an overview of how well you perform tasks.

I know that a big question you have is related to the cost of the tool. I wanted to keep the price low to get a higher user adoption rate, so the price will be 3000$/2500€. It is not a big investment – just think how many hours you could otherwise be spending on alerts.

I want to get a lot of customers to try this tool, so I can add more functionality. Until the 31st of October, POSupport will be sold at half price.

You can find out more about my POSupport tool, and see video presentations of it at