Applying the pipeline concept for a point-to-point 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 multicast scenario. In this blog post, I like to describe how to apply the pipeline concept on Cloud Integration for implementing a point-to-point integration scenario, i.e., one sender and one receiver with no condition at all. 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 has one single receiver with no condition defined.

On the Receiver Interfaces tab, an interface with an 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 as well as outbound processing integration flows as copies from the provided templates.

You have two options to implement the scenario in Cloud Integration, either running through all pipeline steps or bypassing most of the pipeline steps since receiver determination and interface determination are not needed anyway.

Option 1: Complete pipeline

In the first option, we run through all pipeline steps although most of the steps are not really needed. In this case, the XSLTs for the receiver determination and the interface determination always provide the same output with one and the same receiver and one and the same receiver interface, respectively, because no xpath conditions are carried out. You may opt for this option since those settings follow a common approach across all your integration scenarios

The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to PIMAS_Sender~SI_SalesOrder_Out.

The XSLT mapping to determine the list of receivers is defined as follows. In this case, no xpath condition is carried out, so the resulting XML is always 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>PIMAS_Receiver</Service>
      </Receiver>
      <Receiver>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

For the interface determination XSLT mapping, the partner ID equals PIMAS_Sender~SI_SalesOrder_Out with id interfaceDetermination_PIMAS_Receiver.

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 PIMAS_Sender~SI_SalesOrder_Out ~PIMAS_Receiver, now it's PIMAS_Sender~SI_SalesOrder_Out 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.

Like for the XSLT mapping to determine the receiver, the XSLT mapping to determine the interfaces results into a fixed XML 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/scenario3</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 looks as follows. It’s a copy of the template Pipeline Template Step07 - Outbound Processing Point-to-Point, see Pipeline Steps.

Option 2: Bypassing most of the pipeline steps

Note: With version 1.0.6 of the provided package, we now support a different bypass option which allows you to run inbound conversions as well if required, see New Pipeline Concept features: new partner id definition, alternative partner, bypass option.

In the second option, we can reduce the number of pipeline steps that are carried out to a minimum. We assume that no inbound conversion is needed, so we simply end up with three integration flows: the scenario-specific inbound flow, the generic outbound processing, and the scenario-specific outbound processing. In this case, the Partner Directory is not needed.

In the scenario-specific inbound flow, we configure the JMS receiver adapter pointing to the fourth and last queue so that most of the flows are bypassed. Since the Partner Directory is usually read in the generic flows that are bypassed, we need to ensure to maintain the headers which are needed to dispatch the message to the right outbound flow. So, in addition to the headers SAP_Sender and SAP_SenderInterface, the headers SAP_Receiver, maxJMSRetries, and SAP_OutboundProcessingEndpoint need to be maintained as well. In the header SAP_OutboundProcessingEndpoint enter the ProcessDirect end point of the scenario-specific outbound processing flow.

Since we entered here the fourth queue, the message is then picked up by the generic outbound processing and dispatched to the scenario-specific outbound processing flow.

Next, we will cover another special use case, namely an interface split scenario with one receiver message type, see blog post.