Creating the aggregation fan-out flow

1. Select the input node to open the Properties view. The node properties are displayed.
2. Specify the source of input messages for this node. For example, specify the name of a WebSphere® MQ queue in the Queue name property. The MQInput node retrieves messages from this queue.
3. Optional: set values for any other properties that you want to configure for this node. For example, to ensure that aggregate request messages are put under sync point, set the Transaction mode property to Yes. This option avoids the situation where the AggregateReply node receives response messages before it has received the control message that informs it of the aggregation instance. Putting the fan-out flow under transactional control ensures that the fan-out flow completes before any response messages get to the AggregateReply.
4. Connect the input node's Out terminal to the In terminal of an AggregateControl node. This option represents the simplest configuration; if appropriate, you can include other nodes between the input node and the AggregateControl node. For example, store the request for audit purposes (in a Database node), or add a unique identifier to the message (in a Compute node).
5. Optional: if your fan-out and fan-in flows are combined in one message flow, modify the Order mode property on the Advanced tab. Select the By Queue Order option and ensure that the Logical Order property is also selected. These options force the input node to be single threaded to maintain the logical order of the messages that arrive on the queue. Any additional instance threads that you make available are then shared among only the fan-in input nodes to improve the performance of aggregation. If your fan-in and fan-out flows are in separate message flows this step is not required because you can make additional threads available specifically to the fan-in flow.

1. Select the AggregateControl node to open the Properties view. The node properties are displayed.
2. Set the Aggregate name property of the AggregateControl node to identify this particular aggregation. It is used later to associate this AggregateControl node with a specific AggregateReply node. The Aggregate name that you specify must be contextually unique in a broker.
3. Optional: set the Timeout property to specify how long the broker waits for replies to arrive before taking action (described in Setting timeout values for aggregation). If a timeout is not set on the AggregateControl node then aggregate requests stored internally will not be removed unless all aggregate reply messages return. This situation might lead to a gradual build-up of messages on the internal queues. To avoid this situation, set the timeout to a value other than zero (zero means that a timeout never occurs) so that when the timeout is reached the requests are removed and the queues do not fill up with redundant requests. Even if timeouts are not required or expected, it is good practice to set the timeout value to a large value; for example, 86400 seconds (24 hours) so that the queues occasionally get cleared of old aggregations.
4. Connect the Out terminal of the AggregateControl node to the In terminal of one or more Compute nodes that provide the analysis and breakdown of the request in the input message that is propagated on this terminal.

If the target applications that handle the subtask requests can extract the information that they require from the single input message, you do not need to include a Compute node to split the message. You can pass the whole input message to all target applications.

If your target applications expect to receive an individual request, not the whole input message, you must include a Compute node to generate each individual subtask output message from the input message. Configure each Compute node in the following way, copying the appropriate subset of the input message to each output message:

1. Select the Compute node to open the Properties view. The node properties are displayed.
2. Select a value for the Basic property Compute mode. This property specifies which sections of the message tree are modified by the node. The AggregateControl node inserts elements into the local environment tree in the input message that the AggregateRequest node reads when the message reaches it. Ensure that the local environment is copied from the input message to the output message in the Compute node. This configuration happens automatically unless you specify a value that includes local environment (one of All, LocalEnvironment, LocalEnvironment and Message, or Exception and LocalEnvironment).

   If you specify one of these values, the broker assumes that you are customizing the Compute node with ESQL that writes to local environment, and that you are copying any elements in that tree that are required in the output message.

   To modify the local environment, add the following statement to copy the required aggregate information from input message to output message:

   SET OutputLocalEnvironment.ComIbmAggregateControlNode = 
               InputLocalEnvironment.ComIbmAggregateControlNode;

3. Optional: set values for any other properties that you want to configure for this node.
4. Connect the Out terminal of each Compute node to the In terminal of the output node that represents the destination of the output request message that you have created from the input message in this node.

The output node must be an output node that supports the request/reply model, such as an MQOutput node, or a mixture of these nodes (depending on the requirements of the target applications).

1. Select the output node to open the Properties view. The node properties are displayed.
2. Specify the destination for the output messages for this node. For example, specify the name of a WebSphere MQ queue in the Queue name property to which the MQOutput node sends messages. The target application must process its request, and send the response to the reply destination indicated in its input message (for example the WebSphere MQ ReplyToQueue).
3. Click Request in the left view and set values for these properties to specify that replies are sent to the input queue of the fan-in flow.
4. Optional: set values for any other properties that you want to configure for this node.
5. Connect the Out terminal of the output node to the In terminal of an AggregateRequest node. When the message is propagated through the output node's Out terminal, the built-in output node updates the WrittenDestination folder in the associated local environment with additional information required by the AggregateRequest node.

   The information written by the built-in nodes is queue name, queue manager name, message ID, and correlation ID (from the MQMD), and message reply identifier (set to the same value as message ID).

1. Select the AggregateRequest node to open the Properties view. The node properties are displayed.
2. Set the Basic property Folder name to a value that identifies the type of request that has been sent out. This value is used by the AggregateReply node to match up with the reply message when it is received in the fan-in flow. The folder name that you specify for each request that the fan-out flow generates must be unique.

The AggregateRequest node writes a record in WebSphere MQ for each message that it processes. This record enables the AggregateReply node to identify which request each response is associated with. If your output nodes are non-transactional, the response message might arrive at the fan-in flow before this WebSphere MQ update is committed. For details on how you can use timeouts to avoid this situation, see Setting timeout values for aggregation.