Creating the aggregation fan-in flow

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:

You are also advised to read the overview about Message flow aggregation, before completing this task.

Depending on whether the fan-out flow is transactional and, if not, 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. See, Creating the aggregation fan-out flow for more information on this topic.

It is possible to include the fan-out and fan-in flow within the same message flow. However it is advisable to create two separate flows. Do not deploy multiple copies of the same fan-in flow either in the same or different execution groups. For more information about the benefits of configuring separate message flows, see Associating fan-out and fan-in aggregation flows.

To review an example of a fan-in flow, see the Airline Reservations sample that is supplied with WebSphere Message Broker.

To create the fan-in flow:

  1. Switch to the Broker Application Development perspective.
  2. Create a message flow to provide the fan-in processing.
  3. Add the following nodes in the editor view and configure and connect them as described:
    Input node
    The input node receives the responses to the multiple request messages generated from the fan-out flow.

    This must be an input node that supports the request/reply model, such as an MQInput node, 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).

    1. Right-click the input node and click Properties.
    2. Specify the source of input messages for this node. For example, specify the name of a WebSphere MQ queue in the Basic property Queue Name from which the MQInput node retrieves messages.
    3. Optional: specify values for any other properties that you want to configure for this node.
    4. Connect the input node's out terminal to the in terminal of an AggregateReply node.

      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).

    Note: It is advisable to have one input node which receives all of the aggregation response messages at the beginnings of the fan-in flow as described above. Using one instead of multiple nodes ensures that no specific reply input node thread always gets to complete the aggregation and execution of the message flow, whilst the others send their response messages to the Aggregate Reply, which subsequently become eligible to timeout. Using one single input node creates a more sequential processing of the replies for each aggregation which can be successfully scaled by using additional instances to provide more processing power.
    AggregateReply node
    The AggregateReply node receives the inbound responses from the input node through its in terminal. Each reply message received by the AggregateReply node is stored persistently in the broker database.

    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.

    1. Right-click the AggregateReply node and click Properties.
    2. Set the Aggregate Name property of the AggregateReply to identify this aggregation. Set this value to be the same value that you set for the Aggregate Name property in the corresponding AggregateControl node in the fan-out flow.
    3. Optional: set a value for the Unknown Message Timeout if you want to retain an unrecognized message before propagating it to the unknown terminal. If you are using separate fan-out and fan-in flows, you might want to set this value to a non-zero number in case there are delays in the arrival of the control message.
    4. Optional: connect the unknown terminal to another node or sequence of nodes if you want to explicitly handle unrecognized messages. If you do not connect this terminal to another node in the message flow, messages propagated through this terminal are discarded.
    5. Optional: if you have specified a timeout value for this aggregation in the AggregateControl node, connect the timeout terminal to another node or sequence of nodes if you want to explicitly handle timeouts that expire before all replies are received. Partially complete aggregated replies are sent to the timeout terminal if the timer expires. If you do not connect this terminal to another node in the message flow, messages propagated through this terminal are discarded.
    6. Optional: specify values for any other properties that you want to configure for this node.
    7. Connect the out terminal of the AggregateReply node to the in terminal of a Compute node.
    Note: The Control terminal of the AggregateReply node has been deprecated at Version 6.0 and by default any connections to this terminal (either direct or indirect), will be ignored. This is to maximize the efficiency of aggregation flows and does not damage the reliability of aggregations. This is the optimum configuration.

    However, if you do want the AggregateReply node to receive the control message on its control terminal that was sent by the corresponding AggregateControl node on the fan-out flow, you must make the necessary connections as described in Creating the aggregation fan-out flow. It is recommended that the path from the AggregateReply node to the output node is as direct as possible. Keeping the fan-in flow short, will benefit the performance of aggregations. Do not modify the content of this control message.

    In addition, for the Control terminal and connections to it to be recognized, you must enable the environment variable MQSI_AGGR_COMPAT_MODE. However, choosing this option has implications regarding the performance and behavior of message aggregations. For a full description of these implications and the environment variable, seeUsing control messages in aggregation flows.

    Compute node
    The Compute node receives the message that contains the combined responses. It is unlikely that this combined message is in a format that is valid for output, because the aggregated reply message has an unusual structure and cannot be turned into the bitstream required by some nodes, for example the MQOutput node. The out and timeout terminals always output an aggregated reply message, so always require further processing before an MQOutput node. Therefore you must include a compute node and configure this node to create a valid output message.
    1. Right-click the Compute node and click Properties.
    2. Specify the name of the ESQL module that customizes the function of this node in the Basic property ESQL Module.
    3. Right-click the node and click Open ESQL to open the ESQL file that contains the module for this node. The module is highlighted in the ESQL editor view.
    4. Code the ESQL to create a single output message from the aggregated replies in the input 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.

    5. Optional: specify values for any other properties that you want to configure for this node.
    6. Connect the out terminal of the Compute node to the in terminal of the output node that represents the destination of the single response message.
    Output node
    Include an output node for your fan-in flow. This can be any of the built-in nodes, or a user-defined output node.
    1. Right-click the output node and click Properties.
    2. Specify the destination for the output message for this node. For example, specify the name of a WebSphere MQ queue in the Basic property Queue Name to which the MQOutput node sends messages.
    3. Optional: specify values for any other properties that you want to configure for this node.
  4. Press Ctrl-S to save the message flow and validate its configuration.

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:

  • TAXI
  • HOTEL

The resulting aggregated reply message created by the AggregateReply node might have a structure similar to that shown below:


This is a diagram of the tree for the aggregated message content created under element ComIbmAggregateReplyBody under Root. Its contents are described in the surrounding text.

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