IBM BPM, V8.0.1, All platforms > Programming IBM BPM > Enterprise Service Bus programming > Aggregation > Aggregation patterns
Batch processing with message enrichment
This scenario is based on a store ordering system, where a salesperson can submit a request for a number of orders and have them dispatched. The original message that comes into the mediation flow identifies the customer for each order through a customer ID. The order request message needs to be enriched with each customer's shipping details so that the dispatch step has all the information it needs to succeed. This enrichment is done within the request flow by calling out to a customer information system, implemented using a Service Invoke mediation primitive.
Design the aggregation
The ordering and dispatch systems in this scenario are batch systems, where multiple records arrive within the same request message. However, the customer information system is implemented to receive a single record. After the ESB receives the batch message, each of the occurrences of the repeating element in the request message is processed individually, and then a batch message appropriate to the dispatch system is created. Therefore, aggregation is needed.
To explore how this basic scenario is built, first examine the business objects used.
The inbound message into the ordering system from the sales person includes a batched array of SalesOrder objects tagged by a batchID, as shown in Figure 1
Figure 1. Batch
systems business objects
The customerID within each SalesOrder is submitted to the customer service, which provides the Customer business object, as in Figure 2.
Figure 2. The Customer business object
An enriched request, including the full customer details, is submitted to the BatchDispatch service with the request structure as shown in Figure 3.
Figure 3. Batch request
structure
Figure 4 then shows the request provides the following response structure that will be transformed into the sales response.
Figure 4. Batch response structure
Shared context
The structure of the Shared context is important in an aggregation design. The goal is to build an array of DispatchOrder objects so that a message can be created to send to the dispatch system. Each DispatchOrder is created from data in the original SalesOrder and is enhanced with further data from the customer information system. Next, an aggregated picture of all of these individual orders is built by moving the orders into an array of DispatchOrder objects as shown in Figure 5.
Figure 5. DispatchOrder
array
The current field is used in each iteration of the Fan Out mediation primitive to create the DispatchOrder for the customer in question. This is then appended to the aggregationStore, which can be seen as a running total of the aggregation so far.
The flow detail
Now take a look at the flow in detail, starting with the aggregation mediation primitives, Fan Out and Fan In. The Fan Out mediation primitive is set to Iterate mode for the repeating elements called SalesOrders, in the request message. The Fan In mediation primitive setting Fire output terminal when is set to the option the associated Fan Out primitive has iterated through all messages , which ensures the mediation primitive waits until all messages from the Fan Out mediation primitive have been processed. Figure 6.shows the flow and Figure 7 shows the Fan Out and Fan In mediation primitive properties.
Figure 6. Fan Out/Fan
In flow detail
Figure 7. Fan Out/Fan In properties view
A Message Element Setter mediation primitive called setBatchID is located after the Fan Out mediation primitive. This Message Element Setter mediation primitive is used to copy the batchID from the request message into the Shared context, as depicted in Figure 8 .
Figure 8. Message Element
Setter properties
Notice that in this example, the current iteration's output is built from the customer details returned from the service invocation. Additional information (itemID and the quantity) has been copied from the current element iteration's occurrence in the Fan Out context, as shown in Figure 9.
Figure 9. Transform
inline map
The complete results from the current aggregation iteration in the current object of Shared context now show. The next mediation primitive in the flow is a Message Element Setter mediation primitive called aggregateResult, which appends the current object into the aggregationStore in Shared context, as depicted in Figure 10.
Figure 10. Message Element Setter aggregateResult properties
The aggregation flow used for each element is now complete. The elements aggregationStore and batchID must be converted into the batchDispatchRequest needed for the Callout node, as shown in Figure 11.
Figure 11. SMO mapping
The key to a successful aggregation flow is to build up the required information in each iteration in a current object, and then to attach current objects into the running total aggregationStore in the Shared context.