Skip to Content
Author's profile photo Former Member

Using PI by not using PI

We have used SAP for over a decade at work. Recently we started to use SAP PI as our middleware platform. Like everyone else we started with a training course and came back into the company keen and motivated to use every aspect of PI.

What we found was that some aspects of PI are very good others less so. We found if we used the visual mapping tool it soon became a complex mess for anything other than the most simple of maps. Using Java was often no help and we were forced to make RFC calls back in the SAP system to resove mapping issues.

An example of complexity we encountered would be our first EDIFACT interface. We built an EDIFACT to IDoc interface using the Seeburger tool on one side and the SAP IDoc interface on the other. Alas the two documents structures are quite different and it took us over 2 weeks to map them and even then we were forced to make design comprimises and fudges.

We now have the experience of two EDIFACT  interfaces, the first “conventionally” designed, the second designed to  our new simple design. The simple design still used Seeburger as before  but instead of complex visual mapping, it mapped the EDIFACT order XML  doument to a simplified XML document of the same structure, which was  passed via a proxy into an ABAP class. Within the ABAP class, the fields  were then directly mapped into an IDoc in memory, which was then processed  as a normal IDoc by standard SAP functions. Total development time was a  few days. No comprimises were made and the logic is clear to any ABAP  developer.

It was a “nobrainer” decision when we started to design our new  warehouse interfaces, we could do complex mapping in PI and split our logic over PI and ABAP or do simple PI mapping and have all the logic in one place in ABAP: proxies and simple design wins every time.

We are now in the process of rolling out new interfaces this year. They do all the heavy lifting in the SAP system where we have full access to all the business data we need, and a rich programming language that the whole team can use and understand. We then push the data out to PI via a proxy where the simplist of possible maps push it on to the final destination.

We have all the strengths of SAP standard business processing and logic within SAP ERP, glued with our bespoke but clean and simple ABAP, to the monitoring and delivering abilities of SAP PI.

The result is a solution than any functional user can understand, any ABAPer can change and any PI administrator can monitor. We benefit from full data tracability within the IDoc system and PI and there are no hidden secrets lurking that can easily be missed on a later date.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sascha Wenninger
      Sascha Wenninger
      Hi Adam,

      some good thoughts here - I especially like that "no surprises" and consideration of the ease of support and later changes features prominently in your thinking during build time.

      It's no secret that XSLT is my favourite mapping technology in PI. Sure, it's a functional programming language so it will have a steep(ish) learning curve up front, but its advantage are that it's easy to develop and unit test outside PI (using any popular XML editor) and that it's very easy to document the program very well inside the code. No compiling, class paths, etc. either!

      Maybe that's something which you could consider as the next step in your PI roll-out? 🙂

      Good work on the blog - keep sharing your thoughts and experiences as you develop more interfaces!!


      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Personally I love XSLT, I came from one of the companies that helped to invent DOM and XSLT.

      The problem with mapping is that all too often it slips from pure-mapping to business logic mapping which means you are forced to make some kind of call back into a business system somewhere to qualify the mapping.

      Therefore our design goal was to pass the data structure from one side of PI to the other with the minimal changes, BUT presenting it to SAP as an ABAP native structure via the proxy interface. That way we get:

      1) Native SAP document to IDoc logic that we know and love
      2) Mapping inside the ERP (IDoc to proxy structure) with a full programming language and access to any business data not in the IDoc
      3) Simple and quick PI pass through with all the alerting and monitoring tools PI has built in
      4) Logic isn't scattered all over the place leaving nasty surprises for developers down the road

      If it helps you could still do an XSLT map from one XML structure to another, the key to the design is to keep the hard work in ABAP and make the map simple.

      Author's profile photo Former Member
      Former Member
      The design pattern you analyse in this weblog has several important advantages over other approaches, mainly for the following reasons:
      1) The concern about resource utilization when we employ RFC lookups in PI mappings
      2) The common lack of knowledge of Java and/or PI concepts of Contexts/Queues among the implementers of an ECC

      The development of a good PI graphical (or Java) mapping is a task that requires goods knowledge of the way the ESB tackles tree structures. In my experience, it is quite difficult to find PI developers that know these things. Usually you get ABAP developers with knowledge of interfaces and IDocs. Under these circumstances, of course, the described approach is almost perfect.

      All I would like to state is that, as PI developers, we should do our part of the job, which is a robust message transformation (XSLT, Java, graphical, whatever), handling exceptional cases, missing fields and segments, and all that stuff. Concerning the cost of resources for RFC lookups, there could be a logical threshold (e.g. why develop in ABAP for one single RFC call, once per hour?) but in any case, I rarely encounter interfaces, where this cost is a reason to implement otherwise.

      With the Proxy approach, you also lose the credibility of the excellent BD87 IDoc monitoring tool, and you indeed develop extra objects in ECC. If your project resources in PI and ABAP are both strong, then why not use them in a more balanced way?

      In conclusion, I believe all that matters is how your implementation team is structured. In most cases, your paradigm is very smoothly applicable. All I'm saying is that it's not SAP PI's fault that the Java approach looks less confident, and we should not put it that way.