Skip to Content

Hello Integrators!

 

What is the Multicast Pattern?

 

The Multicast pattern allows to route the same message to a number of endpoints and process them in a different way.

 

Through the use of multicast, a single message sent on the integration pipeline can be received by multiple branches and receivers. Once the message is sent, each branch can filter out the data that is not relevant or apply specification transformation rules.

 

How to Use the Multicast Pattern in SAP Cloud Platform Integration ?

 

The Multicast is represented as a decision icon, or more accurately called as the parallel gateway in BPMN lingo. You can insert the flowstep as shown below:

Multicast_Icon.png

There are two variants of the Multicast:

 

  1. Parallel Gateway: All branches of the gateway are executed in parallel.
  2. Sequence Gateway: Branches are executed in the order specified in the Properties tab.

 

You can change between the two variants using the context menu of the multicast flow-step (for right-handers, it appears on right-click of the mouse).

Switch_Multicast.png

An example Integration Flow

 

To understand the multicast pattern better, I shall take the example an Integration Flow and insert a Content Modifier step with a sample XML Payload in its body (shown below). In addition, I shall use a simple mapping step that converts the price and currency from Dollars to Euros.

Multicast_Content_Modifier.JPG.png

 

What ways can I use the Multicast pattern?

 

In Integration projects so far, we have seen its usage in the following two ways:

 

Use case 1: Send the message to multiple receivers. A simplified integration flow is shown below.

 

Multicast_Integration_Flow.JPG

The input and output are demonstrated below. The input comes from the Content Modifier step. The first branch modifies the payload based on the mapping rules and the second one receive

Multicast_Result.JPG.png

 

Use case 2: Multiple branches of the integration flow requires the same message contents

 

There are cases when you require the same message in different branches of the integration flow. This is a pattern also observed in the SuccessFactors scenario integration with 3rd party systems. In this case, you have to use the Join and Gather step. This shall collect all messages from different branches into one message.Example below:

 

Multicast_Gather_Flow.JPG

Note: You have to use the Join + Gather step together. A Gather step alone shall not work.

 

Join+Gather Icon.JPG

Gather flowstep has quite a few options:

 

The Gather step enables you to merge messages from more than one route in an integration process. You define conditions based on the type of messages that you are gathering using the Gather step. You can choose to gather:

 

  1. XML messages of different format
  2. XML messages of the same format
  3. Plain text messages

 

Based on this, you choose the strategy to combine the two messages:

 

  1. XML messages of the same format, you can combine or specify the XPath to the node at which the messages have to be combined.
  2. XML messages of different formats, you can only combine the messages
  3. Plain text messages, you can only specify concatenation as the combine strategy

 

I take the example of XML messages of the same format. For the same payload that I described above, this is the option that I have chosen:Multicast_Gather_Xpath_Options.JPG

 

So, here I want to combine all the “<part>”nodes and group it under the main “Mobile_menu” node.

Understanding the aggregation strategy can get a little tricky. I would recommend playing around it with different values to get a hand on it.

 

Multicast_Gather_Output.JPG

What happens in case of Error?

 

The quality of service applied by default is “Stop on Exception”. In the Message Monitoring, it always shows as a Failed message. Few combinations exist:

 

  • If you have a Join+Gather step and one of the incoming branches (parallel or sequential) fails, then the processing is stopped.
  • When the multicast is connected to multiple receivers, then the successful branches shall receive the message correctly. However, the overall message in the monitoring shall still be shown as Failed.
  • In a sequential multicast, if a branch fails to execute a message – then the processing is stopped with an exception thrown.

 

That is it for this blog. So, try out the multicast pattern and use it in your scenarios!

 

Best Regards,

Sujit

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Rajesh pasupula

    NIce Feature and good to know about the capabilities of Join + gather using your informative blog..

    one question on the join+ for combining all nodes…is there any time limit on the join+ operation..e.g. if I have multiple branches and one of the branches takes long time to execute due to volume/message transformation operations ( like e.g. waiting for response from some other target system)..will join+ timesout or join+ expects some status message to react ?

    Thanks

    Rajesh

    (0) 
    1. Sujit Hemachandran Post author

      Hi Rajesh,

      Good to know that you find it informative ­čÖé

      On your query, in the implementation as of January 2015, we have not included a timeout parameter. So, the integration pipeline waits for all the branches to be complete and received by the join+gather.

      Best Regards,

      Sujit

      (0) 
  2. diptee s

    Hello Sujit,

    Thanks for putting Multicast, Join and Gather together.

    I could understand the usecases for Multicast well; however, why do we have Join and Gather as 2 different steps? As we know, Gather cannot work without a Join and having a Join without a Gather doesnt make much sense either (correct me if I am wrong here), so why dont we have one single step which can function as one unit?

    Regards,

    Diptee

    (0) 
  3. Andreea Mutascu

    Hello Sujit,

    Thanks for the blog, it is very useful.

    My question would be if there is any way, using the sequential multicast to ensure succesfull processing of the message in order, not only sucessful initiation. I want to build an integration flow which will post different Odata entities, but which are mandatory to be imported in order and to be ensured somehow that the first branch finished the execution successfully before the second starts. Is this scenario possible in HCI-PI?
    Many thanks in advance for your response.
    Best regards,
    Andreea

    (0) 
  4. Hari Sonnenahalli

    Sujit-

    I have a question. I am trying to use verify step in┬ámy iflow to verify the incoming message using vendor public key.I can’t pass inbound message directly to verify step before mapping so need to use a┬ácontent modifier step but if I use a content modifier step I just need to pass the incoming payload it self so that mapping can be executed. I am not sure what parameters should I set in a┬ábody of content modifier to pass the incoming payload.

    Please let me know.

    Thanks

    HS

     

     

     

    (0) 

Leave a Reply