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
- SAP Managed Tags:
4 Comments
