Posts

New B2B Monitor for SAP PI/PO to handle EDI Files

EDI monitoring and archiving is an important part of your operations for EDIFACT/X12 and the corresponding XML documents. It should be fast to retrieve the documents by searching for partner, order number, and also to find all related documents. I’m looking for customers that want to help develop the product with me, so we can build it so it suits your requirements.

Many years ago I was creating a B2B Arching tool to make it easier to archive messages in a smart way. I ended up coding quite a bit of it my self, and was not able to sell it. Now it is time to try again because so much is changing in the integration world and I got a developer team that has built the Figaf IRT tool to test SAP PI/PO

I have been talking with some SAP customers and they are looking for a way to make it easier to archive their EDI (EDIFACT/X12) messages and use it as a tool to monitor what has been sent and received. The cool thing about EDI is that it is fairly simple to build a parser that allows you to parse the links and references between documents. That way you don’t need to make into a configuration for each mapping or scenario.

On the PI system the only thing you need to add is the SAP Archive Module and then the application can handle the rest. Then you can filter the documents based on partners or other information.

Short demo video of the User interface and how easy it is to browse the relations between documents.

 

Check out the full presentation of the project.

What is the best way to deploy this and where should the payload be saved. In a cloud system or some on a content server. I do have a lot of ideas on how to improve but think you will also have some ideas.

There is the part of the retention of data, how do we ensure that orders are saved 3 months in one country and invoices are saved 7 years in another country. We will need some configuration to specify how it will work and how to get data.

I’m looking for customers that would be interested in a solution and can help us with getting the correct requirements for it. We expect to be able to deliver a solution in 2-3 months depending on the requirements.

If you are interested send an email to info@figaf.com and let’s have a talk on your requirements. 

How to make a moderen EDI landscape with SAP S/4 HANA

I had a great talk with an old colleague this Friday. The topic was how to build a new EDI platform.  They did not have any EDI yet on the SAP platform since they used an old platform for it. So they had to start over with SAP as the backend.

I have been doing EDIFACT and X12 implement since I started with SAP XI using the Seeburger tool and lately seen on how to use the B2B Add-on from SAP to handle the EDI part on SAP PO. The tool has a difference in structure and how they work, but they work the same way. The can take some XML and convert it to the EDIFACT/X12 files and the other way. SAPs platform has been focused on how to make it native in SAP PI/PO, where SeeBurger was a new way of the building the platform.

I have created a video that shows some of my questions concerns on the topic of creating EDI with S/4 Hana.

I was starting to talk about the different IDOCs and which EDIFACT documents they referred to. Then we got a talk about they were doing a new S/4 HANA on-premise implementation. S/4 HANA cloud,  which is the premier SAP product, is where all development is going on. There is only a few whitelisted IDOC’s for some scearnios like syncronize data with your existing SAP ERP system and some warehouse. The EDI IDOCs is supposedly not available, so you cannot use them.

Since all development in on S/4 Cloud and the on-premise version will get the updates after a few months/years, there is not going to be any development going on the EDI Idocs. There has probably not been developed much on them over the last 10-15 years. SAP would like to move their customers to the cloud version to make it faster for them, and customers cannot live with out their flexibility. So we will have to see where it will end.

An option was to use the Enterprise Services (E-SOA) that also worked on the process. I have hear about a few organization using it, but it requires a strong leadership and some skills to go use them. Since Enterprise Services is a dead topic now, i guess it does not make sense to focus on it. It seems as it has been inpsiring the new SOAP APIs from SAP so it is not in vain, and you probalby have an easier option to migrate them.

API is a big focus area for SAP for some reasons.

  • In S/4 Cloud you cannot develop so you have to use APIs to extract and use data
  • It is easier to explain APIs to non SAP developers, because they have a common form of documenting
  • You can expose them online and secure them

All the APIs SAP has created is on api.sap.com, which is SAPs API portal.  On the portal, you can find all SAP apis on the different systems and you can easy try them out there. I did find an SOAP service for sending Purchase Orders from S4, but is currently not able to find it. One of the document you can find is the Scope Item 2EJ, which is covering the purchasing process on how to configure it and steps involved in configuration. So it is fairly easy to get started with.

So it is possible to use the APIs to expose the purchase process for EDI.

EDI from the new APIs

So it is possible to create an EDI solution based on the new APIs. Then what does it require.

A good place to start would be to use the Integration Content Advisor, which is SAP way to make the B2B Mapping faster based on Machine Learning. I have not seen or use the tool yet, but it the idea is pretty cool. It could speed up the mapping of data with the EDI formats. It requires you have the Enterprise Edition of SAP Cloud Platform Integration. You can though run the flow on your local PI. The alternative approve is to use the normal EDI Mapping on SAP PI/PO and use the B2B Add-on in connection with the Trading Partner Management (TPM).  If the Content Advisor works it is probably the fasts way to deal with things.

It still brings up the question about is the new APIs strong enough to be able to handle the processing. And how will the errors be resolved since they cannot be handled in BD87.  S/4 will come with AIF (SAP Application Interface Framework) for some scenarios, which is a tool that enable different kinds of error handling and mapping. It may be suited to some of the normal EDI error that you will see like customer try to send an invalid material number or delivery data. It will require some training to enable users to use it. AIF is more powerful soluction then BD87 since it allow you to add rules and validations.

My recommendation would be to give the new interfaces an attempt to get the process working on it. It would give freedom to upgrade to S4 Cloud and just have one interface for the integration process. I would also imagine that the new interfaces is easier to extent or you can make lookups to get information that is missing.

Have you tried the new S4 way of integration and does it work?

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.