Since we can use Message Mappings and Groovy Scripts (via Script Collections) as reusable tranformation objects, also the need for reusing XSLT mappings comes up.
In the past we were able to call a central mapping via ProcessDirect in a separate Integration Flow, but this results in additional messages which does not help to monitor the system well.
With the Partner Directory we can upload and use XSLTs since many years already, but until late 2024 this was only accessible via API. Now we have the option in the UI of the monitoring section:
This leads to a new approach which is easier to handle from Monitoring perspective:
All you need to do is to upload the XSLT into the Partner Directory:
Now you can consume the XSLT mapping in your Integration Flow: The access is done by setting the message header to a value of the following syntax:
pd:<Partner ID>:<Parameter ID>:Binary
In our case this would be pd:WHINT_Mappings:XSLT_ADAM_BLOG:Binary
The execution of the mapping is done by selecting Source = Header and providing the header name.
To showcase it, we have prepared a working example with a few steps using a generic XSLT mapping to add a SOAP envelope:
- Content Modifier: Setting a source payload (body) and the header “PD_Mapping” (can be any name of course)
- XSLT Mapping execution (using the header “PD_Mapping”)
- Logging the target (mapped) payload in the MPL
The monitoring result looks like this:
There are not only advantages using this approach compared to the “old” approach (using a central iFlow).
Transport and Version Management are less easy to handle as you can not jump back to a previous artifact version and also partner directory content is not a subject to transports, so handle this part of your integrations with care…
