The aggregation fan-out flow receives the initial input message and restructures it to present a number of requests to a number of target applications.
You can include the fan-out and fan-in flow in the same message flow. However, you might prefer to create two separate flows. For more information about the benefits of configuring separate message flows, see Associating fan-out and fan-in aggregation flows.
You can view information about samples only when you use the product documentation that is integrated with the IBM Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.
To create the fan-out flow:
However, if you do want a control message to be sent from the AggregateControl node to the AggregateReply node, you must connect the Control terminal to the corresponding AggregateReply node on the fan-in flow (either directly or indirectly, as described in Associating fan-out and fan-in aggregation flows). If you connect it indirectly to the AggregateReply node, for example through an MQOutput node, you must include a Compute node to add the appropriate headers to the message to ensure that it can be safely transmitted.
In addition, for the Control terminal and connections from 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, see Using control messages in aggregation flows.
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:
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;
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).
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).
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.