Associating fan-out and fan-in aggregation flows

Associate the fan-out message flow processing with its corresponding fan-in message flow processing by setting the Aggregate Name property of the AggregateControl and AggregateReply nodes in your aggregation flow to the same value.

Before you start:

To complete this task, you must have completed the following tasks:

The Aggregate Name must be contextually unique within a broker. In general, this means that there should only be one AggregateControl node and one AggregateReply node with a particular Aggregate Name, although it is possible to have more than one AggregateControl node with the same Aggregate Name, as described in Using multiple AggregateControl nodes.

You can either create the fan-out and fan-in flows in the same message flow, or in two different message flows. In either case, the two parts of the aggregation are linked when you connect the AggregateControl node of the fan-out flow to the AggregateReply node of the fan-in flow.

The way in which you configure your aggregation flow depends on a number of factors:

A single flow is easier to implement for a simple case, but there are some limitations to this approach, and, in most cases, you will find that the flexibility offered by two message flows is preferable. The Airline sample shows the use of two flows for aggregation.

To associate the fan-out flow with the fan-in flow:

  1. Switch to the Broker Application Development perspective.
  2. If you have created the fan-out and fan-in flows in a single message flow:
    1. Open the aggregation message flow.
    2. Connect the control terminal of the AggregateControl node to the control terminal of the AggregateReply node to make the association.

    This is referred to as a direct connection between the two aggregation nodes.

  3. If you have created separate fan-out and fan-in message flows:
    1. Open the fan-out message flow.
    2. Configure the AggregateControl node as described in Creating the aggregation fan-out flow.
    3. Configure an output node that represents the intermediate destination for the control message. For example, if you want to send the control message to an intermediate WebSphere MQ queue, include an MQOutput node and identify the target queue in the Basic properties Queue Manager Name and Queue Name.
    4. Optional: configure a Compute node that creates a valid output message containing the control message. For example, if you want to pass the control message to an MQOutput node, configure the Compute node to add an MQMD to the message and complete the required fields in that header.

      For example, you can code the following ESQL:

      SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
      SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
      SET OutputRoot.MQMD.Format = MQMD_STRING;
    5. Connect the control terminal of the AggregateControl node to the in terminal of the output node that represents the intermediate destination for the control message. If you have included a Compute node, connect the control terminal of the AggregateControl node to the in terminal of the Compute node, and the out terminal of the Compute node to the in terminal of the output node that represents the intermediate destination for the control message.
    6. Open the fan-in message flow.
    7. Configure at least one input node to receive the reply messages, as described in Creating the aggregation fan-in flow.
    8. Configure an input node to receive the control information from the AggregateControl node. For example, set the Basic property Queue Name of the MQInput node to receive the control message from an intermediate WebSphere MQ queue.
    9. Connect the out terminal of the input node that receives the control message to the control terminal of the AggregateReply node.

    This is referred to as an indirect connection between the two aggregation nodes.

The advantages of a single message flow that contains both fan-out and fan-in are:

The advantages of creating separate fan-out and fan-in flows are:

Maintaining message flows

You might find it necessary during the lifetime of a message flow to suspend its operation, change its design, and redeploy it. If a message flow involves aggregation, you might find it helpful to suspend operations in two stages:

  1. Suspend the fan-out stage to stop any more requests being sent, and wait for all the outstanding requests to be serviced by the fan-in stage.
  2. When there are no outstanding aggregations, suspend the fan-in stage.

Use this two-stage shutdown to ensure that timeouts behave in a predictable manner. If the fan-out and fan-in stages are in the same message flow, it can be difficult to shut down in this way. If WebSphere MQ is the underlying transport, this can be achieved, to a certain extent, by inhibiting get and put operations on the queues involved. Other transports might have a similar ability.

Related concepts
Message flows
Message flow aggregation

Related tasks
Configuring aggregation flows
Creating the aggregation fan-out flow
Creating the aggregation fan-in flow
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

Related reference
AggregateControl node
AggregateReply node
AggregateRequest node