- 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 this blog, I like to describe how to apply the pipeline concept for an integration scenario with interface split and multiple receiver message types. The scenario is like the previous interface split scenario except that the operation mapping not only splits the message into multiple messages but also different message types. Here, we have an incoming message with an order and multiple items whereas a header message with the order information and each item should be sent to one and the same receiver individually.
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, a one-to-many operation mapping and no xpath condition is defined. The one-to-many operation mapping splits the message into multiple message types.
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 or the split scenario described in the previous examples, the XSLT mappings for the receiver determination as well as for the interface determination result into fixed XMLs.
In our example, the partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to IFSplit_Sender_8~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 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_8~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_8~si_order_async_ob ~RL_Receiver_1, now it's IFSplit_Sender_8~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/scenario5</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 Multiple Message Types, see Pipeline Steps. You need to add as much branches as you have receiver message types, in our case two, one for the items and one for the header.
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 Messages 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.
After the mapping, you add a parallel multicast.
In the first branch of the parallel multicast, 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.
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 constant Branch1 for the first branch and 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 the second branch of the parallel multicast, the mapped message needs to be split using an iterating splitter with expression type XPath and an xpath to split the message on Order level. Since we only have one single Order node, we could have used a filter instead.
For the second branch, we concatenate the unique ID that we received from the generic parent flow with the constant Branch2 and the Camel split index and store the value into the exchange property SplitMessageID.
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 an interface split scenario with Maintain Order at Runtime flag set, see next blog post.
