Skip to Content

XSLT and PI – When you really should use it – ( Part 1 )

XSLT versus Graphical Mapping 

In our current PI-project, a big-bang public sector implementation of HCM, we have been faced with a lot of SAP Process Integration (PI) interfaces around HR-Master Data. At the core was a process for master data replication via ALE.


And one of the challenges was to create a hub where a daily run of changes via ALE-replication using  HRMD_A07 IDOC was consumed by six different target applications. All of them needed different data in different context but from one daily ALE change run.

The usual answer in Netweaver PI 7.1 is to use the graphical mapping. It is supposed to be faster and “better” than XSLT, the extended style sheet transformation. But we had a couple of issues with this approach and I think this is not so “black and white” 

Point One: Handling

Number one is handling issue: the customer was using Citrix terminal server, and the Solving ‘Out of Memory’ problem – Using JNLP, since the basic IDOC size is huge . (For the non-initiated non-HR-People: This IDOC has all 1000+ Infotypes as basic structure included) It means also 1000s of fields constantly in mapping and scrolling. There is a way for optimized handling for these kinds of big IDOCS  called “reduced IDOCS”  (refer to SAPnote #709400)

But even if this extreme example of terminal server and huge IDOC is not common, most IDOCs are large and have a lot of complex mapping issues. In opposite of simple XML-structure, IDOCs require a lot of work with contextual changes, that arel not easy to understand.

Point Two: Documentation 

Second issue was the “Hand Over” situation, common to most projects with consultants on customer sites. How will you as a consultant explain and document to customers all these different mappings and its handling? This would mean  100’s of screenshots and a lot of documentation.

I am a big fan of XSLT style sheet in this case. First, they are “common knowledge” and even the executable result underneath the graphical mapper is XSLT. XSLT has great tools (my personal favorite, Creating XSLT Mapping using STYLUS studio Editor together with PI) and it can be used as a collaborativ tool inside a greater, distributed group of project and people.  You can even use it with the PI-XSLT-processor

The usual reply is “XSLT is too slow”. I am not sure about this argument. I have not seen any number yet and if someone would like to comment on specific A/B tests with numbers, I am more than happy to discuss it in this blog.

Performance depends on use-cases 

But I think this is more a question of specific situation. For example, if you will only copy one HR IDOC infotype record if a specific value is present (i.e. HR personal number), this is much easier and faster in XSLT than in graphical mapping. In XSLT, this is a few lines of code, in graphical mapping, this would be a pain. At runtime, if the condition is done, there is no further parsing, next record is taken. So this “cut” logic works faster than the result from graphical mapping.

Probably, if you have a lot of simple, straight forward “here to there” mappings, than graphical mapping is easier and faster in handling and at runtime. On straightforward mapping requirements, documentation is also easier and can be maintained in a simple spreadsheet. This is a valuable solution. And if you only had one or two mappings, that is probably easier.

But for larger-scale mappings and organizational requirements in larger project contexts, XSLT can increase speed and quality.

This is no either-or decision. In PI-Projects, it also depends on time, skills and knowledge. XSLT has no easy learning curve at the beginning, but so does PI. It can fit well into bigger projects. And in smaller situations, that require quicker solutions, graphical mapping is much easier.

As usual in all SAP-projects – “IT ALL DEPENDS”….

Next Steps

Part II – Part IV will coming soon

Anatomy of an XSLT Style Sheet for IDOCS (Part II)

Part III Java rfc lookup in XSLT style sheets

Part IV Integration Builder Scenario with XSLT, RFC and IDOC

You must be Logged on to comment or reply to a post.
  • Hi,
    We had a similar situation where the idoc definition has too many unused infotypes. We used xsd editor to remove all the unused infotypes and imported the xsd as external definition.
    • Hi Naveen,
      this is actually a great idea. People here in the project liked it a lot – maybe we give it a try. It makes handling definitely easier.

      Thanks for pointing this out

  • Great blog Holger. I’ve always been a bigger fan of XSLT mapping than graphical but I’m just curious though…How do you document the XSLT field mapping (XPaths) for handover?

    With the graphical mapping one can use the PI Documenter tool & it generates some nice Excel documentation but that will also fall over on large structures.

    • Hi,
      thanks for the reply. Indeed, I was not aware of the Mmapper PI tools here on sdn.

      But I think the idea is also valid for XSLT: create an XSLT for documentation, to get the extract for excel.
      Or, you can also do inline comments for other programmers. Since working in a group, the detailed mapping is important for someone who will work next on the work you have done so far.

      I think it is easier to hand over a style sheet rather than elaborate on screenshots of mapping.

      But both ways are important tools in your PI arsenal.

      thanks for cheering in