The risk pyramid and SAP PI/PRO projects

I took my car to the mechanic recently, and on the wall of the shop I saw a sign that said, ‘We can do two of three things!” On it, there was a graphic of a pyramid with three levels: ‘Low Price’, ‘Short Time’, and ‘Quality’. Then the message, ‘We can do two of these but not three’. Clearly, the idea was that you could have, for instance, a low price and a quick turnaround time, but not good quality.

Project perspective parameters

I think often it’s the same with Integration work. We have these same three parameters when we are working on a project, and we can adjust which parameter takes priority, depending on what our clients prefer to have. Of course, they want all three, but, like the mechanic told me they can’t have all three.

I was presenting Figaf’s integration regression testing tool (IRT) for SAP PI/PRO and one thing that came up was risk of the project.  The thing is, the mechanic’s pyramid is missing the ability to adjust for the very important element of risk. Risk is different from quality — quality is what you get after the project is complete, while risk is a factor you want to mitigate. When we are working on a project, we have risk we want to minimize. In an integration project a risk could be that our mappings will not work with the partners and we need to test more with them. Or that the new technology we try to use does not work. We ask ourselves questions like, how can we complete the project on time? Will it work when we go into production? How many variables are we testing?

I think that a lot of the time, as Integration professionals, we don’t put enough energy into minimizing risk. If you pick up any project management book, one of the big topics it covers is risk. The goal is to teach project managers to ask how they can mitigate and measure the risk they are taking with a given project. Measuring the risk gives the project manager lots of important information that will allow him to lower the risk so that it will be easier to include all the components of a project in less time, with fewer problems and higher quality.

Our SAP regression tool helps achieve all three of the factors in the pyramid by mitigating the risk. First, IRT enables you to set up a certain set of test cases. This reduces risk by ensuring that you’ve run the same test cases every time, and that they’ve passed without any problems. Second, better and more consistent testing raises the quality of the project overall, giving your client a better final product. Then of course, streamlining the testing process reduces the time spent, and allows delivery of the project to the client that much sooner. This is a big deal since most integration professionals work and bill on an hourly basis. And finally, of course, fewer billable hours means a reduced cost to the client.

So, I just wanted to remind you that whenever you are doing integration work, there is a tool that will help you mitigate the risk you’re taking with the project to help you deliver on time and within budget, while still meeting the requirements of your project.

You can check out the Figaf integration regression tool at:

P.s. We are now going to do a demo of the tool for the client, so they must have linked it.

SAP Integration Landscape and Emerging Complexity

The field of process integration is changing quickly, setting new challenges for Integration professionals, and I think a good understanding of the available tools is key.

When we talk about paradigms in process integration, there have been 3 major phases:

  • Mainframes: Back in the day, most companies had one mainframe or two. The good thing about the mainframe was that it was fairly simple to integrate what were essentially internal programs – even if you had to work across mainframe platforms.
  • Client-server: With the emergence of client-servers and SAP R/3, the number of application servers was growing quickly. Suddenly, as an Integration Department, you had to figure out how to integrate the applications in your landscape so that you could create a new interface. In SAP terms, it may have been a Business Connector or eXchange Infrastructure (XI). You only had one tool to use.
  • The Cloud: Today, cloud integration is the norm, and the goal is to be able to quickly and easily leverage new cloud capabilities from existing development. A couple of examples of existing cloud capabilities are Hybris Cloud for Customer (e-commerce solutions) and SuccessFactor (human capital management).  There are also a number of non-SAP cloud applications. In fact, you most likely have some of them in your landscape already. As the integration expert, your job requires you to make them all play together seamlessly. Some come with prebuild content others you have to create for yourself.

As I said earlier, it used to be that you had integration consolidation that mostly worked in XI/PI. Now, Integration departments are faced with a very different landscape, driven by the need for new integration capabilities, and need to be looking outside of their space at the tools that are already available in other areas of process development. If we understand what’s out there, we can choose the right tool for the job.

I’m talking about tools like the HANA Cloud Platform – integration services (HCP-IS)/HCI, Process Orchestration (PRO), API Management, and Data Services to do bigger data ETL. We’ve also got the Application Integration Framework Overview (AIF), for when you want to do any integration with backend services. There are also SAP Gateway solutions available for exposing OData. Those are the SAP integration technologies that I can think of off the top of my head, other vendors have similar offerings that may be relevant.

I did this exercise with a customer and we spend 6 hours on the different topics and when it did fit into their architecture.

The big problem for the integration manager/architect is that you need to know the tools, and know when it makes sense to use one and how to select one over another. You also need to be able to train your team to use them. As you learn more, you’ll find a lot of overlap between the capabilities of the various tools, and knowing what each one can do will allow you to streamline your process when you have complex situations.

The challenge with all these tools is that it is both labor-intensive and potentially expensive to try them out. Say you have a situation where you want to expose some data to the user. First, you will have to figure out the logic and the capabilities of the various tools to find the best one to combine the elements so your API management will call  PRO or Gateway — to get or expose some data. Then you’ll need to acquire the tools and start using them, in order to really understand where they fit and what you can do with them. Once you get that down, you will need to work out how to leverage the technology internally. So, a lot of work is involved whenever you introduce new technology like this. You also have to keep in mind that you will be paying for licensing to use the tool, even if you don’t end up implementing it.

So as integration experts and enterprise architects, working in a rapidly changing field, we want to do our homework and really understand any tool and how we can leverage it before we place it in our systems.

What is your strategy for landscape integration? How do you cope with training problems?

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.


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.