Applying the pipeline concept for a multicast integration scenario

[alex_bundschuh]

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 generic use case with multiple receivers and receiver interfaces. In this blog post, I like to describe how to apply the pipeline concept on Cloud Integration for implementing a multicast integration scenario, i.e., the messages are distributed to multiple receivers, no xpath condition is defined. 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 blog post before proceeding.

Source Integrated Configuration Object in SAP Process Orchestration

The integrated configuration object example on SAP Process Orchestration describes a Recipient List pattern with no xpath condition, i.e., a multicast pattern. Here, the sender communication component equals RL_Sender_5 with sender interface si_item_async_ob. An incoming message is delivered to three receivers whereas if no receiver is found, the message is simply ignored, so no error is raised.

For each receiver, only one interface is defined with no xpath condition. For the first receiver, the incoming message is mapped to an order format.

For the second receiver, the incoming message is mapped to an order format as well.

For the third receiver, the incoming message is mapped to an item format.

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.

You need to create a scenario-specific integration flow for the inbound processing as copy of the templates provided. Here, we copied the template Pipeline Template Step01 - Inbound Processing At Least Once and maintained SAP_Sender and SAP_SenderInterface accordingly which are then passed to the next integration flows in the sequence of integration flows to read the Partner Directory information.

 

For each receiver/receiver interface, the scenario-specific outbound integration flows need to be created as copies from the provided templates. Below, the outbound processing integration flow for the first receiver is displayed. It’s based on the template Pipeline Template Step07 - Outbound Processing Point-to-Point, see Pipeline Step.

The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to RL_Sender_5~si_item_async_ob. The XSLT mapping to determine the list of receivers 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:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
      <ReceiverNotDetermined>
        <Type>Ignore</Type>
        <DefaultReceiver/>
      </ReceiverNotDetermined>
      <Receiver>
        <Service>RL_Receiver_1</Service>
      </Receiver>
      <Receiver>
        <Service>RL_Receiver_2</Service>
      </Receiver>
      <Receiver>
        <Service>RL_Receiver_3</Service>
      </Receiver>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

During message processing, the generic integration flow Pipeline Generic Step04 - Receiver Determination reads the XSLT from the Partner Directory and then runs it to determine the number of receivers the message should be sent to. Since there is no xpath condition, the resulting XML is always the same containing all three receivers.

For the first receiver, the partner ID to store the interface determination XSLT mapping in the Partner Directory equals RL_Sender_5~si_item_async_ob~RL_Receiver_1. The XSLT mapping to determine the interfaces 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/scenario2/rcvidx1/ifidx1</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

During message processing, the generic integration flow Pipeline Generic Step05 - Interface Determination reads the XSLT from the Partner Directory and then runs it to determine the receiver interface. Since there is no xpath condition defined to determine the receiver interface, the resulting XML is always the same containing the end point of the scenario-specific outbound processing flow for the first receiver.

The XSLT mappings for the other two receivers are similarly defined and hence not explicitly displayed here.

Next, we will cover a special use case, namely a point-to-point scenario, see this blog post.