Skip to Content
Author's profile photo Arijit Das

SAP PI / PO Mapping Technology Matrix

Many a times as an Integration Architect / Integration Consultant / Interface Designer we are faced with choices on which technology / tool to use. There are several ways to skin a cat. In tech speak that translates to how do we deliver an interface with the “right” mapping technology? That usually boils down to “Best Practice” (SAP recommended approach) or “Best Fit” (for the client). However, it is more often determined by available skill set and what the said resource is comfortable with.

So what is the “right” answer? Is there such a thing as a “right” answer? What works well for a particular client may not hold true for others. There is no “one size fits all”. Hence I will not attempt to answer this question. Instead I will provide my point of view drawn purely from personal experiences.

The below table is a summary of my experiences from several sites and projects over a period of close to 10 years. This is not a guide by any means; but a philosophical approach to the world of integration and associated mapping tools.

Mapping Technology
Rating (out of 5) Merits Limitations Sites
Graphical 5
  • SAP recommended
  • Preferred by most Consultants (new age)
  • Graphical representation
  • Easy to follow
  • No coding required
  • In built functions to do almost everything
  • Drag and drop mechanism
  • Widely used
  • Deeply nested structures can make the mapping complex
  • Need to resort to Java UDFs / XSLT for simplification
Graphical w/ Java UDFs 4

(best of both Graphical and Java worlds)
Use Java where your canvas looks almost unreadable / difficult to maintain
  • Not many (a complex schemas will always pose a challenge irrespective of technology)
  • Need very good Java skills
  • Gaining preference
  • Tool of choice for traditional middleware Consultants
  • It’s not coding but skilful manipulation of XML trees is a skill set that not all have
  • XSDs not required; hence no schema; and thus name value pairs would work
  • Lightweight
  • Perfect where your data model can be dynamic and hence there is no fixed schema (name / value pairs)
  • Very good understanding of XML
  • Needs a different skill set – XSLT and Xpath
  • Extra tools required for XSLT mapping
A few large sites
Java (not Java UDFs) 1 Anything can be done programmatically if you are a Java guru
  • Old school
  • Needs a highly skilled Java resource
Few sites with small number of interfaces

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Eng Swee Yeoh
      Eng Swee Yeoh

      Hi Arijit

      Thank you for sharing your experience on this.

      I would like to add a couple of things:-

      i) These type of comparisons are already covered in section 3 of the following official SAP document. Even though it is a little bit dated (from 2008), many of the points and considerations still hold true.

      SAP NetWeaver Process Integration Best Practices: Design

      ii) You might want to elaborate what you mean by "old school" for the Java mapping item. IMHO, Java skills are not "old school" but instead an essential skill for any developer who is serious in growing their PI/PO career. The roadmap for PI/PO is already heading towards Java only installation (although it still supports Dual SID in 7.5), and as integration challenges increases in complexity, there are requirements that can only be best fulfilled using Java mapping approaches.


      Eng Swee

      Author's profile photo Arijit Das
      Arijit Das
      Blog Post Author

      Hi Eng Swee

      First of all a big Thank You for your comments.

      Yes; I have referred to this document many times over the years when Graphical Mapping was the flavour of the season (and still is in many instances).

      However; as more and more enterprises are adopting a Common Information Model (CIM) where not all the elements are assigned an XML tag; the need to switch to name value pairs to support the CIM and hence the need for XSLT mapping is gaining momentum.

      Also XSLT being an open source offers advantages - any developer who knows XSLT can develop in PI (unlike graphical which has been SAP's domain).

      Many developers find graphical hard to read and confusing (if the canvas has far too many elements and node functions) and thus maintain, impossible to document, difficult to unit test, hard to automate testing, and hard to teach to people from non-SAP backgrounds.

      Maybe we should update this document based on current customer feedback?

      Regarding "Java being old school"; please let me clarify. Java skills are definitely not old school. They are very relevant; and any PI developer should be relatively well versed in Java. What I meant to say was those developers who prefer Java only mapping (not Java UDFs) may be old school.

      Having said that there are many organisations who have a few interfaces on Java only mapping. Java mapping was used to validate the incoming payload against the XSD before sending it to a JMS queue.