Why SAP PI is ideal for business integration

At Figaf we use most of the time developing interfaces using SAP PI (Previous Exchange Infrastructure XI). The biggest reason to use SAP Process Integration (PI) anywhere is that it is rather quick to develop and get an interface up and run. This makes it quite ideal for prototyping. Within a day it is possible to have an interface running and start to test the flow. Sure it may take longer time to get everything up and running but overall it is quite easy to make it work for the first iteration. It is possible to get to try out some of the interface soon and you will then be able to test your ideas.

Another great advantage of SAP PI is designed for business integration. All the different components necessary for integrations is there, and there is not a need for a high level developer education. The focus is on the business process and not on how to create code. The mapping is the only place where you need to write code, but most of the mappings is can be done using the drag and drop mappings. Then the focus is on which business values is mapped between the two systems, and it can be done by business process experts (BPX).

In some cases you will need to work on areas where you will have to write code. If it is something you only need to do it some time you can outsource this code development or get some coaching on how to write the specific code.

The focus for the whole development process is therefore on how to get most business value added in the shortest amount of time.

Sign up to our newsletter to get to know more tips on how to improve your business using SAP PI.

New Gartner report on SAP Process Integration

Last year Gartner did not believe that SAP Process Integration, was a product to use. There was not enough use case and focus on PI as an Enterprise Service Bus. There was a lot of talk from SAP stating that the conclusion of from Gartner was wrong. There was no way to change the rapport.

Now according to SearchSap.com there is good news from Gartner. They do like the new 7.3 version of SAP PI and that their concerns has been minimize.

One of the big differences it the total cost of ownership is much smaller because of the easier architecture, as a part of the Java stack only (Singlestack) and other improvements.

The other things are that SAP has a roadmap for where PI will develop in the coming years.

It is nice to be focusing on a product, which is seen as a product with a future. It will make it much easier for organizations to continue to invest time and money into SAP PI.

Required knowledge to support a SAP PI by support staff

I’m just writing some documentation for my current project. I have done a lot of work on documenting the way that I, as a developer would like to see.

One large issue is how much information should be given to the support people in the documentation.

SAP PI/XI is a lot different than monitoring an ERP system that a regular basis consultant does.

  • There are multiply areas where a message can fail Adapter Engine, Integration Engine and ccBPMs, all of these areas need. The support personal need to know how all areas work and how to find areas in each tool.
  • PI is interfacing up against a lot of different systems, an all of those systems and also be a reason for the error.

To monitor the Process Integration system you need some basic knowledge on how it works and which components it contain. For trouble shooting you will need knowledge on how to browse the Enterprise Service Builder and the Directory. If the support does not know this they will need an extensive amount of documentation of the configuration and used objects. If they know how to browse the ESR and Directory you can use much less information and the document is not as intensive.

I would argue that to monitor a SAP PI system you will need a good understanding on how the PI works and how to browse the objects. That will also make the solving of problems much easier.

It is fairly simple to find all the messages that fail in the integration engine or another place. It is just to search for failed messages. A much more difficult task is to find why an order was not delivered or mapped correctly. First you need to find the time the order idoc/proxy was created, and then find the message in the adapter monitor. This can be a bit difficult and require opening a lot messages to find the correct file. Next step is to validate the mapping of the message and learn that one of the fields in the order idoc was not filled out. This step probably requires a developer there is probably a step in between this two functions where the task needs to be handed over from support to developers. Though it all depend on the organizations size and how it functions.

I will be talking at SAP Teched session PMC233 in Las Vegas
about how to documentation.

I have also created a survey of how people use SAP PI for documentation. The survey is free.

Documentation is a part of everybody’s life not just SAP professions.

I was waiting in the lobby of a hospital. One of the things I noticed was there was as lot of posters on how to work on documentation. It made me think that documentation is a universal issue that every profession has or at least most profession experiences.

I was thinking of areas where they do not document. I was thinking of childcare or housepainters. I guess that in the first instance it would make sense to document the child’s progress. The house painter could probably document what he has done, in order to avoid other problems in a later stage and easy paint the same color for the client again.

Sorry the poster was in Danish, but I’ll try to give must best summery of them.

One of the things I noticed about the posters is that they focus a lot of the process on creating documentation. The first poster present a process that a unit has been thru to learn what and how to make sure the documentation was in order.

The main principle that they are proposing is to du an audit, where a large part of the staff is working together to review the documentation already created. They use a list of 28 questions from the hospital to make sure the documentation is up to the state the hospital requires. Then they implement changes to improve the documentation for later patients.

The other poster wrote about a process for a creating for an entire hospital and how to make sure that everybody know how to document. A part of the process is also the test everybody’s knowledge according to some guidelines. That should also be an idea that we should start to implement.

It claims that documentation is a process that can be improved all the time, and effort needs to be created to work on this.

This is also something that I see as possible in the perspective of SAP documentation. It is not enough just to use the same templates or process that we used 10 years ago. We need to update our knowledge to make sure that we use the best procedures.

I’ll be talking about documentation in SAP PI at SAP Teched in Las Vegas. I hope that my presentation there will inspire you go learn more about your own documentation process and make sure you create better documentation.

I have also created a survey of how people use SAP PI for documentation. The survey is free.

Announcing the SAP Process Integration survey 2010

During the last month I have been working on creating the SAP PI documentation survey. It is finally done.

Thanks for all the user data provided. It was real interesting to get all the information and be able to compile it together. Now I have a much better insight in how other developers use documentation in the PI. I’m happy to be able to share it with you.

The survey can be downloaded for free on the website http://figaf.com/services/pi-documentation-survey.html

I do look forward to present the content at the SAP Teched session PMC233 in Las Vegas. I’ll come with more information later regarding the presentation.


Figaf has performed a survey regarding how people document their SAP Process Integration (PI) or Exchange Infrastructure (XI) interfaces. Sixty people were surveyed with an average of 4.5 years of experience.

The good news is that 49% found that the process of creating documentation made them learn something new. Also, 92% found that the documentation was valuable. Documentation is either based on an interface or a scenario. There was approximately 50% for each type.

Documentation is mostly used by developers and supporters, but it also used by many other types of users. The documentation is most often used for learning about the interface and to signal changes in the project phase.

It was suggested that people needed a new template for creating templates. Also a large number requested an automatic tool for documenting SAP PI.