Skip to Content
Technical Articles
Author's profile photo Helmut Skolaut

Create XSLT Mapping Collections in Cloud Integration

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

  1. Create a package where you store your XSLT artifacts
  2. Create an iFlow artifact for the XSLT Mapping – it will look like this:
  3. The ProcessDirect Adapter has a unique name that can be used in several Caller iFlows:
  4. Your XSLT Mapping can be parameterized with external parameter:
  5. 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

  1. In your existing iFlow you can call the externalized XSLT mapping iFlow like this:
  2. 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:
  3. Use the “Request-Reply” tool to call via ProcessDirect the other iFlow from Step 1

 

Other Solutions

There is also the possibility to store your centralized XSLT mapping into the Partner Directly – but right now, there is not yet a good User Interface – so you have to build your own UI or you have to do manual steps to use Tools like Postman to feed the XSLT into the partner Directory – that’s why i was searching for a more convenient way to centralize XSLT Mapping.

Not Tested

I have not tested yet, if this concept can be transferred to Graphical Mapping, etc.

Assigned tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Adam Kiwon
      Adam Kiwon

      Dear Helmut,

      Nice blog, I am also a big fan of centralization & standardization.

      Please keep in mind that splitting such tasks using another Integration Process (even within the same Integration Flow) will produce an additional message with each message processing.

      As SAP Cloud Integration is based on a message-based license model (charged in blocks of 10K messages), you will double your traffic with this approach, so I would try to limit this solution to low/medium traffic-intense interfaces.

      Best regards, Adam