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, you must 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 1Figure 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 detailFigure 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.