Here comes another Enterprise Integration Pattern as part of my blog series. This time, I show you how to model the Content-Based Router pattern on both SAP Process Orchestration and SAP Cloud Integration. If you like to find out more about the motivation and use cases for the patterns blog series, start with the Enterprise Integration Patterns at SAP Cloud Integration: Scatter-Gather blog. Also, check out the Integration Flow Design Guidelines for SAP Cloud Integration blog referring to integration flow design guidelines and patterns for SAP Cloud Integration that SAP has recently published on the SAP Help Portal.
The Content-Based Router pattern is used to route a message to the correct recipient based on its content. Note, that the message is routed to exactly one channel.
Content-Based Router on SAP Process Orchestration
In the Integration Flow, you can add a Recipient List and maintain a list of potential receivers. Here, you have the possibility to select either of the following routing techniques: dynamic (via message mapping), static (an xpath condition either based on the payload data or the message header), and receiver rules (re-usable routing conditions).
SAP Process Orchestration actually does not distinguish between the Content-based Router and the Recipient List patterns. Whereas for former the message is routed to exactly one receiver, latter may broadcast the message to multiple receivers. However, if your routing conditions are disjoint, each message will be routed to exactly one receiver strictly following the definition of the Content-based Router.
In the example below, we use the static routing condition. In a separate blog we will describe the Recipient List pattern using dynamic message routing in combination with the receiver wildcard.
Let’s focus here on the Receiver Not Found configuration options. During message processing, the condition is evaluated, and if met, the message is routed to the respective receiver. If no receiver could be determined, you have various options to proceed: raise an error, send to a default receiver or ignore the message. In our example, we have chosen the latter option, i.e., the message is discarded without raising an error if neither condition is met.
For more details, check out the Content-based Router chapter in the Stateless Enterprise Integration Patterns on SAP Process Orchestration paper.
Content-Based Router on SAP Cloud Integration
The Content-based Router pattern is modeled using a router flow step. Like for SAP Process Orchestration, the xpath condition can be either based on the payload data or the message header. For each of the Receiver Not Found options described above, we have shipped an integration flow variant. For a detailed description of all three variants of the Content-based Router pattern on SAP Cloud Integration, please check out the SAP Help Portal. The figure below shows the variant where the message should be discarded if neither condition is met. For all variants, it is recommended to store the xpath expression as an Exchange property which is then used in the particular routing conditions. This way, you can better trace the value of the xpath condition in case of errors. Furthermore, a better runtime behavior can be expected since the message needs to be parsed only once. For each receiver, the routing condition is configured accordingly. In addition, we define a default route that points to an End event.
On the SAP API Business Hub, you find the Integration Flow Design Guidelines – Enterprise Integration Patterns package. There you can access all three variants of the Content-Based Router pattern integration flow to gather more details about its configuration. You can test the pattern either on your SAP Cloud Integration tenant or on the cloud integration runtime of your SAP Process Orchestration 7.5 system.
Eager to learn about the other patterns? Those are the patterns published so far: