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

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.


Featured in SAP BPX!

Daniel Graversen, CEO of FigAf, will be featured in the SAP BPX newsletter!

Daniel’s blog will tackle a lot about SAP community network (SDN) and on how Integration Expert in the Process Teams is managed.

This blog focuses on the importance of being a part of a system team and to get more knowledge from the whole process team itself. This is much in line with the vision of FigAf, to be much closer to what the process of integration solutions are being developed for.

And, as the CEO of FigAf, Daniel Graversen takes pride in developing user-friendly integration solutions which offer better and bolder application features that others do not have.

BPX Community Newsletter will be on August 24, 2010.

Caseish Launched!

After all the hard work,Caseish is finally launched at Google I/O 2010 in front of
various online application developers today.

Caseish is developed to serve as one great solution for every business challenge that may occur. It is a helpful management and collaboration tool which allows users to
easily manage difficult business processes in a shorter period of time. It makes everything simpler, faster and easier to handle.

Caseish also allows multi-collaborative works possible with the use of its equipped applications making communication instant and on a real time basis. Delays or anything similar is no longer a problem with Caseish.

With Caseish, every case management is guaranteed to be on the right track.

Subsequent to its release, it’s amazing how news about Caseish spread so fast. In fact, it has
tremendously received good reviews and news coverage.

Caseish has been
featured in one of’s post titled “Dansker promovere
Wave-baseret system,” and on another post in ReadWriteWeb
as one of the latest 5 Services that Leverage Google Wave.

We, behind Caseish,
look forward to seeing good stuffs like these and may it gain more popularity
in the coming days.

Read more