Referring to the Integration Flow Design Guidelines for SAP Cloud Integration blog, SAP has recently published integration flow design guidelines and patterns for SAP Cloud Integration. The guidelines should help you to design the most common Enterprise Integration Patterns and to build enterprise-grade integration flows.
With the Enterprise Integration Patterns at SAP Cloud Integration: Scatter-Gather blog, I have started a blog series covering some of the patterns that we have published here. The intention is not only to show how those patterns can be implemented on SAP Cloud Integration but also to compare with how we modeled this on SAP Process Orchestration. If you haven't done yet, read about the motivation and use cases in my previous blog above.
This is the second blog in the blog series. This time, I cover the so called Composed Message Processor pattern. The pattern describes how to handle a message with multiple elements whereas each element requires different processing. You use a Composed Message Processor pattern to split the message into multiple sub messages, route the split messages to different destinations, and then re-aggregate the responses back into one single message.
In the following, I will briefly explain the process model of the Composed Message Processor pattern that we have implemented in SAP Process Orchestration. The process itself is modeled using Business Process Management (BPM), the message exchange with the various systems is done using the Process Integration runtime of SAP Process Orchestration. Here, I stick to the BPM process only. For a detailed description of the overall implementation, please refer to this blog.
The BPM process is modeled following the BPMN (Business Process Model & Notation) specification. The process model starts with a message start event receiving an order with multiple items. In a mapping, the order is split. For the mapping, looping is defined as par for each though the individual split messages actually run in sequence. For each item, a condition is carried out, and the processing is routed to either of the branches depending on the respective product category. A router condition checks if all items have been processed. If not, the processing is looped back, and the next item is processed. Otherwise, the aggregated message is returned.
For a detailed description of the Composed Message Processor pattern on SAP Cloud Integration, please check out the SAP Help Portal. In the following, I will only outline the rough model.
In the sample integration flow, we use a General Splitter to split an order into multiple individual messages according to the number of items. In the General Splitter property, the Parallel Processing check box is selected to ensure concurrent processing of the split messages. The Router forwards the items to different inventory systems depending on the product category where the items are enriched. Finally, the Gather step re-aggregates the multiple messages into a single message.
If you like to test the pattern on your SAP Cloud Integration tenant, access the Integration Flow Design Guidelines - Enterprise Integration Patterns package from the catalog linked to your tenant. You can find the package on the SAP API Business Hub. Optionally, if you run an SAP Process Orchestration 7.5 system, you can deploy the very same integration flow there as well. See, how this works here.
Hope this blog helped to implement the Composed Message Processor pattern on SAP Cloud Integration. Here, a list of the pattern blogs published so far:
With the Enterprise Integration Patterns at SAP Cloud Integration: Scatter-Gather blog, I have started a blog series covering some of the patterns that we have published here. The intention is not only to show how those patterns can be implemented on SAP Cloud Integration but also to compare with how we modeled this on SAP Process Orchestration. If you haven't done yet, read about the motivation and use cases in my previous blog above.
This is the second blog in the blog series. This time, I cover the so called Composed Message Processor pattern. The pattern describes how to handle a message with multiple elements whereas each element requires different processing. You use a Composed Message Processor pattern to split the message into multiple sub messages, route the split messages to different destinations, and then re-aggregate the responses back into one single message.
Composed Message Processor on SAP Process Orchestration
In the following, I will briefly explain the process model of the Composed Message Processor pattern that we have implemented in SAP Process Orchestration. The process itself is modeled using Business Process Management (BPM), the message exchange with the various systems is done using the Process Integration runtime of SAP Process Orchestration. Here, I stick to the BPM process only. For a detailed description of the overall implementation, please refer to this blog.
The BPM process is modeled following the BPMN (Business Process Model & Notation) specification. The process model starts with a message start event receiving an order with multiple items. In a mapping, the order is split. For the mapping, looping is defined as par for each though the individual split messages actually run in sequence. For each item, a condition is carried out, and the processing is routed to either of the branches depending on the respective product category. A router condition checks if all items have been processed. If not, the processing is looped back, and the next item is processed. Otherwise, the aggregated message is returned.
Composed Message Processor on SAP Cloud Integration
For a detailed description of the Composed Message Processor pattern on SAP Cloud Integration, please check out the SAP Help Portal. In the following, I will only outline the rough model.
In the sample integration flow, we use a General Splitter to split an order into multiple individual messages according to the number of items. In the General Splitter property, the Parallel Processing check box is selected to ensure concurrent processing of the split messages. The Router forwards the items to different inventory systems depending on the product category where the items are enriched. Finally, the Gather step re-aggregates the multiple messages into a single message.
If you like to test the pattern on your SAP Cloud Integration tenant, access the Integration Flow Design Guidelines - Enterprise Integration Patterns package from the catalog linked to your tenant. You can find the package on the SAP API Business Hub. Optionally, if you run an SAP Process Orchestration 7.5 system, you can deploy the very same integration flow there as well. See, how this works here.
Hope this blog helped to implement the Composed Message Processor pattern on SAP Cloud Integration. Here, a list of the pattern blogs published so far:
- Scatter-Gather
- Composed Message Processor (current blog)
- Aggregator
- Content-Based Router
- Recipient List
- Message Filter
- Content Filter
- Content Enricher
- Splitter
- SAP Managed Tags:
