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 |
|
|
Majority | ||
| Graphical w/ Java UDFs | 4
|
Use Java where your canvas looks almost unreadable / difficult to maintain |
|
Majority | ||
| XSLT | 4 |
|
|
A few large sites | ||
| Java (not Java UDFs) | 1 | Anything can be done programmatically if you are a Java guru |
|
Few sites with small number of interfaces |
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.
Regards
Eng Swee
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.
Regards
Arijit