The aggregation fan-in flow receives the responses to the request messages sent out by the fan-out flow and constructs a combined response message containing all the responses received.
Before you start:
To complete this task, you must have completed the following task:
Depending on the timeout values that you have specified, the combined response message might be generated before all the replies have been received by the fan-in flow.
To review an example of a fan-in flow, see the Airline sample that is supplied with WebSphere Business Integration Message Broker.
To create the fan-in flow:
This must be an input node that supports the request/reply model. You can use the built-in nodes MQeInput and MQInput, or a user-defined input node that supports request/reply, or a mixture of these nodes (depending on the requirements of the applications that send these responses). The response received by each input node must be sent across the same protocol as the request to which it corresponds (for example, if you include an MQOutput node in the fan-out flow, the response to that request must be received by an MQInput node in this flow).
This represents the simplest configuration; if appropriate, you can include other nodes between the input node and the AggregateReply node. For example, you might want to store the replies for audit purposes (in a Warehouse node).
When all the replies for a particular group of aggregation requests have been collected, the AggregateReply node creates an aggregated reply message and propagates this through the out terminal.
The AggregateReply node also receives on its control terminal the control message that was sent by the corresponding AggregateControl node on the fan-out flow (either directly or indirectly, as described in Associating fan-out and fan-in aggregation flows). Do not make modify the content of this control message.
The structure of the aggregated reply message that is propagated through the out terminal, and information on how you can access its contents, are provided in Accessing the combined message contents.
The AggregateReply node creates a folder in the combined message tree below Root, called ComIbmAggregateReplyBody. Below this, it creates a number of folders using the folder names that you set in the AggregateRequest nodes. The associated reply messages are put beneath them.
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:
You can use 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
Related concepts
Message flows
Message flow aggregation
User-defined Input nodes
User-defined output nodes
Related tasks
Configuring aggregation flows
Creating the aggregation fan-out flow
Associating fan-out and fan-in aggregation flows
Setting timeouts for aggregation
Using multiple AggregateControl nodes
Handling exceptions and database deadlocks in aggregation flows
Designing a message flow
Creating a message flow
Defining message flow content
Developing user-defined extensions
Related reference
AggregateControl node
AggregateReply node
AggregateRequest node
Compute node
MQeInput node
MQeOutput node
MQInput node
MQOutput node
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac12300_ |