AggregateReply node
Use the AggregateReply node to mark the end of an aggregation fan-in. This node collects replies and combines them into a single compound message.
- Developer
- Application Integration Suite
- Standard
- Advanced
- Express
- Scale
Information about the state of in-flight messages is held on storage queues that are controlled by WebSphere® MQ, so you must install WebSphere MQ on the same computer as your integration node if you want to use the capabilities provided by the AggregateReply node. The storage queues that hold the state information are owned by the queue manager that is associated with the integration node, and you specify this queue manager by using the -q property of the mqsicreatebroker command. For more information about the queues that are required by the AggregateReply node, see Configuring the storage of events for aggregation nodes.
Purpose
Aggregation is an extension of the request/reply application model. It combines the generation and fan-out of a number of related requests with the fan-in of the corresponding replies, and compiles those replies into a single aggregated reply message.
The aggregation function is provided by the following three nodes:
- The AggregateControl node marks the beginning of a fan-out of requests that are part of an aggregation. It sends a control message that is used by the AggregateReply node to match the different requests that have been made. The information that is propagated from the Control terminal includes the integration node identifier, the aggregate name property, and the timeout property. The aggregation information that is added to the message Environment by the AggregateControl node must not be changed.
- The AggregateRequest node records the fact that the request messages have been sent. It also collects information that helps the AggregateReply node to construct the aggregated reply message. The information that is added to the message Environment by the AggregateRequest must be preserved, otherwise the aggregation fails.
- The AggregateReply node marks the end of an aggregation fan-in. It collects replies and combines them into a single aggregated reply message.
The AggregateReply node is contained in the Routing drawer of the palette, and is represented in the IBM® Integration Toolkit by the following icon:
When incoming messages are stored by the AggregateReply node before all responses for the aggregation are received, the persistence of the message determines whether the message is retained across a restart.
If, during an aggregation, one or more of the response messages are not received by the AggregateReply node, the normal timeout or unknown message processing deals with the responses that have been received already.
The MQMD.Expiry value of each AggregateReply message is set to -1 in the compound output message. This value is set because the MQMD.Expiry value has no meaning once the reply message is no longer on the WebSphere MQ Transport and has been stored by the integration node during the aggregation process.
Terminals and properties
When you have put an instance of the AggregateReply node into a message flow, you can configure it; see Configuring a message flow node. The properties of the node are displayed in the Properties view. All mandatory properties for which you must enter a value (those that do not have a default value defined) are marked with an asterisk.
The AggregateReply node terminals are described in the following table.
Terminal | Description |
---|---|
In | The input terminal that accepts a message for processing by the node. |
Failure | The output terminal to which the message is routed if a failure is detected during processing. |
Unknown | The output terminal to which messages are routed when they cannot be identified as valid reply messages. |
Out | The output terminal to which the compound message is routed when processing completes successfully. |
Timeout | The output terminal to which the incomplete compound message is routed when the timeout interval that is specified in the corresponding AggregateControl node has expired. |
Catch | The output terminal to which the message is routed if an exception is thrown downstream and then caught by this node. |
The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value when no default is defined); the column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).
The Description properties of the AggregateReply node are described in the following table.
Property | M | C | Default | Description |
---|---|---|---|---|
Node name | No | No | The node type (AggregateReply) | The name of the node. |
Short Description | No | No | A brief description of the node. | |
Long Description | No | No | Text that describes the purpose of the node in the message flow. |
The AggregateReply node Basic properties are described in the following table.
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
Aggregate Name | Yes | Yes | A name that is used to associate the fan-in
message flow with the fan-out message flow. This value must be contextually
unique within an integration node. This name is also used to identify an Aggregation configurable service (if one exists) to be used by the node. |
aggregateName | |
Unknown Message Timeout | No | No | 0 |
The amount of time, in seconds, for which messages
that cannot be identified as replies are held before they are propagated
to the Unknown terminal. The default value is zero; if you accept this default value, the timeout is disabled, and unknown messages are propagated to the Unknown terminal upon receipt. On z/OS®, if the Unknown Message Timeout property is not set to zero, set the queue manager parameter EXPRYINT to 5. |
|
Transaction Mode | Yes | No | Selected | This property defines the transactional characteristics
of this message:
|
Property | M | C | Default | Description |
---|---|---|---|---|
Events | No | No | None | Events that you have defined for the node are
displayed on this tab. By default, no monitoring events are defined
on any node in a message flow. Use Add, Edit,
and Delete to create, change or delete monitoring
events for the node; see Configuring monitoring event sources by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |