Posts

How to start from scratch for using SAP PI/PO

If you just purchased SAP PI/PO there is a lot of things to consider. This post will help you in the process of figuring out what is interesting.

The thing is you don’t know too much but it will have the greatest impact on what is set up. So it would be a good idea to have an architecture workshop where you will get all the insight into how you can create a solution that matches what you want to achieve. So it is an ideal time to get help.

I have created a mindmap video where I cover some of the most important things about the process. Watch the video below.

Architeture

A big thing is to get the architecture to match what you want in your organization. There a lot of things to consider like naming conventions and how to create interfaces. This should you would hopefully get a few sample interfaces that show how the things would look and how to monitor them. You should also consider how to make documents required for it both mapping documents if required and documentation.

It may be a good idea to have a secondary consultant to help you in the process that is on your side because you don’t know as much about what you can expect.

 

Testing

Testing is one of the important things in the process. If you “just” replace middle where you have the ability to get input and output document. If you use the Figaf IRT for SAP PI/PO testing then you will be able to perform the tests to verify that messages look identical. This way you can save some time for testing the application together with business experts.

If are doing a greenfield implementation of SAP S/4 ERP then you will have to change the interfaces on both sides. You will still have to setup testing so you can ensure that the process works correctly even when you have to apply support packs.

Migration

A good place to start is also my migration guide. It is much the same things, except that you have more free hands with what you want to do and the changes that you must make.

There are some of the things here that can be applied to the list of attributes to collect from each interface. You can find it in the slides. If you can get the information it may be a lot easier for a partner to do a good estimation of the project. You may add data like a number of fields in each interface to give better information about required mapping size maybe group it in to bucket like 1-20 , 20-100, 100+ fields that need to be mapped.

Cloud world

In this blog, we have not been covering any of the SAP platforms that may be interesting and save some time on integration. There is the SAP Cloud Platform Integration (CPI aka HCI) which is a solution that is quite simply to PI but cloud-based and more flexible. It contains a lot of prebuild content that will speed up and integration, so it may be used in some scenarios. You may also be able to run this type of interfaces on your new SAP PO system. For some integrations, it may be beneficial to use because of the flexibility and the availability of adapters.

Other advice:

I ask the question what people would like to have known before they started on the SAP PI/PO project a long time ago and I did get some interesting answers that may be quite in line with what you are looking for. There was a lot of ideas about making better guides for what should be implemented. You can read all suggestion here.

 

Good luck on your new platform. I promise it will be an adventure. 

How the Seeburger Migration Tool Works

 

I can understand that there is a bit of confusion about how our Seeburger Migration Tool works for converting from Seebuger BIC to the B2B Add-on.

I hope this post will make things clearer.

The big problem is that Seeburger’s XML representation of the EDIFACT/XML formats is different from the ones that form the SAP B2B Add-on. The root node is different, and there is a difference in how Groups and some fields names are made. It is therefore a bit of a challenge to move from one format to the other. Below you can see what the SOT tool does.

I have tried to illustrate the process in the following diagram:
How SOT functions

SOT is a small, self-contained web application that runs locally on your own PC. Once installed, you are able to configure which PI system it should use.

The process is the following:

  1. The user selects a Message Mapping from a drop-down list and which External Definition to use for the mapping.
  2. User Presses Fetch and Update.
    1. This will download the Metadata from the mapping.
    2. Find the Seeburger XSD contained in the mapping.
    3. Compare the existing Seeburger format with the B2B Add-on format. It will then know that it needs to convert from /LIST/S_UNB/S_UNH/G_SSG25/S_LIN/D_1082 to /INVOIC96A/M_INVOIC/G_SG25/S_LIN/D_1082. It is using an algorithm for the comparison, so nothing special is required for the different message types and versions.
    4. Go through the mapping metadata and convert all occurrences of the first Xpath to the second.
    5. Alert if there is a difference in the structure that is not accounted for, or if there are other errors.
  3. The user can then select Update. This will upload the new message data to the server, and the mapping will use the new definition.
  4. You will have to open the mapping and save it to make sure it compiles the mapping files.

You will still be able to use the same original mapping; it will just work on the B2B format.

The functions that you use will still be in the mapping, since we are only changing the use of XSD.

If you want to see more, I suggest that you check out the tool page for SOT.