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 an interface split scenario resulting in multiple messages which may have different message types. In this blog post, I describe another interface split scenario, however here the split messages should be processed in order. A use case might be to store a message on a file system and only if successfully written, we like to add a trigger file which would then trigger subsequent processing steps. For this, in the interface determination, the Maintain Order at Runtime flag is set.
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, two interfaces with no xpath condition are defined. The Maintain Order at Runtime flag is selected ensuring that the message of the second interface is processed only if the first message has been successfully processed.
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.
The XSLT mapping for the receiver determination results into a fixed XML with one receiver only. The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to IFSplit_Sender_6~si_item_async_ob.
<?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_6~si_item_async_ob ~RL_Receiver_1. Although we have two interfaces, the XSLT mapping to determine the interfaces contains one interface index only. Since the messages should be processed in order, we only need to call one single outbound processing integration flow.
<?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/scenario6</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 using a sequential multicast step. This way, you ensure that the messages are processed in sequence. It’s a copy of the template Pipeline Template Step07 - Outbound Processing Maintain Order At Runtime, see Pipeline Steps.
In the first branch of the sequential multicast, the message is mapped to the item format.
In the second branch of the sequential multicast, the message is mapped to the trigger file format.
Note: In Order using a Sequential Multicast is only supported if the receiver adapter doesn't persist and restart on its own. As an example, when using an XI receiver adapter with At Least Once or Exactly Once message delivery, the message is first persisted and then delivered. The moment the first branch successfully persists the message, the second branch will be processed even if the first branch hasn't successfully delivered the message. Especially in an error situation, i.e., if the first branch fails to deliver its message and the second branch successfully delivers its message, in order will be violated. But even if both branches run successfully, the second message may still overtake the first. So, if you like to implement In Order for the XI receiver adapter following the approach above, you need to switch to Best Effort message delivery.
This was the last blog in the blog series about the pipeline use cases. For a complete overview of all blogs, check out the intro blog post.
- SAP Managed Tags:
