Nested aggregation
This scenario is based on a supermarket company, where each outlet sends multiple restocking orders to a central company-wide system that batches the requests into a single message. This single message is submitted to the mediation flow where, for each order and for each branch, a separate invocation to the order system should occur.
Design the aggregation
The ordering system only accepts a single record, whereas the input into the mediation module is a nested batch message. This introduces the need for aggregation, and in this case nested aggregation, because the batch request message is repeated on an outlet basis, and then repeated on an order basis. Orders are sent individually; the response from each order is stored into a single response message, which can be aggregated later. This single response message shows the status of all the elements in the batch request. To explore how this basic scenario is built, first examine the business objects used, as shown in Figure 1 .
Shared context
- Aggregate on an Outlet basis.
- Aggregate on an Order basis.
- Call the Order service.
- Store the current Order service within the current Outlet response.
- Repeat for each Order associated with the Outlet.
- Store the current Outlet in the company-wide aggregation store.
- Aggregate on an Order basis.
- Repeat for each Outlet.
- Convert all results into a response message.
The flow detail
Now look at the flow in detail. It is separated into three sections:- Company-wide scope
- Outlet or Store scope
- Order scope