The aggregation fan-in flow receives the responses to the request messages that are sent out by the fan-out flow, and constructs a combined response message containing all the responses received.
Before you start:
You can include the fan-out and fan-in flow within the same message flow. However, creating two separate flows is typically a better option; for further details, see Associating fan-out and fan-in aggregation flows. Do not deploy multiple copies of the same fan-in flow either in the same or different execution groups.
If the fan-out flow is not transactional, the timeout values that you have specified might result in the combined response message being generated before the fan-in flow has received all the replies. For more information, see Creating the aggregation fan-out flow.
To create the fan-in flow:
The AggregateReply node creates a folder in the combined message tree below Root, called ComIbmAggregateReplyBody. Below this, the node creates a number of subfolders using the names that you set in the AggregateRequest nodes. These subfolders are populated with the associated reply messages.
For example, the request messages might have folder names:
The resulting aggregated reply message created by the AggregateReply node might have a structure similar to that shown below:
Use ESQL within a Compute node to access the reply from the taxi company using the following correlation name:
InputRoot.ComIbmAggregateReplyBody.TAXI.xyz
The folder name does not have to be unique. If you have multiple requests with the folder name TAXI, you can access the separate replies using the array subscript notation, for example:
InputRoot.ComIbmAggregateReplyBody.TAXI[1].xyz InputRoot.ComIbmAggregateReplyBody.TAXI[2].xyz