Challenge

Recently, SAP has launched Script Collections you can use to centralize your Groovy or Java Scripts. A good Blog is found here: https://blogs.sap.com/2021/06/07/script-reusable-artifact-in-sap-cloud-integration/

Unfortunately, an XSLT mapping cannot be centralized in this cool way.

While you are used to have centralized XSLT mappings in SAP PI/PO you are (re-)using in several Operational Mappings or Operational Mappings can be used in several Integrated Configuration, in Cloud Integration, an XSLT mapping needs to be deployed into each Integration Flow. So if you have many Integration Flows using same or very similar mapping, have have a version of the XSLT mapping stored per Artifact. Having now a small fix would lead into fixing it in all instances.

Solution

You can create an XSLT mapping as a separate Integration Flow that can be called from your main flow. You can even design your XSLT to have different flavors based on Parameters.

Step 1: Centralized XSLT iFlow

Create a package where you store your XSLT artifacts
Create an iFlow artifact for the XSLT Mapping – it will look like this:
The ProcessDirect Adapter has a unique name that can be used in several Caller iFlows:
Your XSLT Mapping can be parameterized with external parameter:
You have to allow that using ProcessDirect a header parameter can be inherited from the Calling iFlow:
Note: Only Headers can be inherited – Exchange Properties are not allowed

Step 2: Use in different Main iFlows

In your existing iFlow you can call the externalized XSLT mapping iFlow like this:
Set the Header Parameters for your Mapping parametrization. In my example, i have used a Content Modifier – but the Header can also be modified by a Groovy Script, out of another mapping or maybe retrieved using a value mapping:
Use the “Request-Reply” tool to call via ProcessDirect the other iFlow from Step 1