- SAP Managed Tags:
The current blog is part of a blog series where I describe how to implement different asynchronous integration scenarios using the pipeline concept on Cloud Integration. In the previous blog post, I described a point-to-point scenario. In this blog post, I like to describe how to apply the pipeline concept on Cloud Integration for implementing an integration scenario with interface split whereas all split messages are of same message type.
The scenario is like the point-to-point scenario except that the operation mapping splits the message into multiple messages. Here, we have an incoming message with an order and multiple items whereas each item should be sent to one and the same receiver individually. I will first show you how the scenario is configured in SAP Process Orchestration, and then go through the main implementation steps to get the scenario run on Cloud Integration leveraging the pipeline concept.
For an introduction to the pipeline concept, see this intro blog post . If you haven't gone through the basics of the pipeline concept, I strongly recommend to first read the introduction blog post before proceeding
Source Integrated Configuration Object in SAP Process Orchestration
The integrated configuration object example on SAP Process Orchestration has one single receiver with no condition defined.
On the Receiver Interfaces tab, an interface with a one-to-many operation mapping and no xpath condition is defined.
Target implementation in Cloud Integration
We would like to model and run the scenario on Cloud Integration applying the pipeline concept. Prerequisite is that you have deployed all generic integration flows as well as the script collection from the integration package provided.
To set up the scenario using the pipeline, the Partner Directory entries need to be created as well as the scenario-specific integration flows. In our case, we assume that no inbound conversion is needed. So, we need to create the scenario-specific inbound processing and outbound processing integration flows as copies from the provided templates.
Like for the point-to-point scenario described in the previous blog post, the XSLT mappings for the receiver determination as well as for the interface determination result into fixed XMLs.
The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to IFSplit_Sender_7~si_order_async_ob.
The XSLT mapping to determine the list of receivers is defined as follows. In this case, no xpath condition is carried out, as said the resulting XML is then fixed.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
<ReceiverNotDetermined>
<Type>Ignore</Type>
<DefaultReceiver/>
</ReceiverNotDetermined>
<Receiver>
<Service>RL_Receiver_1</Service>
</Receiver>
<Receiver>
</ns0:Receivers>
</xsl:template>
</xsl:stylesheet>
For the interface determination XSLT mapping, the partner ID equals IFSplit_Sender_7~si_order_async_ob with id interfaceDetermination_RL_Receiver_1.
Note: With version 1.0.6 of the provided package Process Integration Pipeline - Generic Integration Flows & Templates we had to do an incompatible change of how the partner id is defined to retrieve the interface determination XSLT. This is due to the lengths restriction of the partner id of 60 characters. Before, the partner id was IFSplit_Sender_7~si_order_async_ob ~RL_Receiver_1, now it's IFSplit_Sender_7~si_order_async_ob and we concatenated the receiver name to the end of the id, see above. By the way, we now also support alternative partner which is even a better approach, here you can define a scenario name and map the sender and the interface to this very scenario name. See New Pipeline Concept features: new partner id definition, alternative partner, bypass option. You may also check out this github repository where I describe how to setup the Pipeline for Cloud Integration for a couple of sample scenarios using alternative partner.
The XSLT mapping to determine the interfaces is fixed as well. It is defined as follows:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
<Interface>
<Index>1</Index>
<Service>/pip/07/scenario4</Service>
</Interface>
</ns0:Interfaces>
</xsl:template>
</xsl:stylesheet>
The scenario-specific inbound integration flow looks as follows. It’s a copy of the template Pipeline Template Step01 - Inbound Processing At Least Once, see Pipeline Steps.
The scenario-specific outbound integration flow needs to be modelled as follows. It’s a copy of the template Pipeline Template Step07 - Outbound Processing One-to-Many with One Message Type, see Pipeline Steps.
In an XML Modifier step, you need to remove the XML declaration from the message body.
In a content modifier step, you need to wrap the body with the nodes required when running multi-mappings.
In a message mapping step, you run the multi-mapping that you can reuse from the SAP Process Orchestration system.
The mapped message needs to be split using an iterating splitter with expression type XPath and an xpath to split the message on Item level. By intention, we unselect the Parallel Processing flag, see below.
To ensure Exactly Once delivery, we need to assign each split message a unique ID, hence we concatenate the unique ID that we received from the generic parent flow with the Camel split index and store the value into the exchange property SplitMessageID. Since the split was done sequentially, each item always gets its same split index assigned in case that the message is retried.
In an idempotent process call, the actual receiver is called. The beforehand created SplitMessageID property is used to identify duplicates. If the idempotent process was successfully carried out before, a retry with the same ID will be skipped.
Next, we will cover another interface split scenario, this time with multiple receiver message types, see next blog post.
