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:
This is referred to as a direct connection between the two aggregation nodes.
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;
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:
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:
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
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac12310_ |