SpAggregateReply node


The SpAggregateReply node icon

This page contains information on:

The SpAggregateCreate and SpAggregateReply nodes are co-operating nodes that together are responsible for the processing of ‘fan-out’ requests and the aggregation of the replies from such requests. A valid aggregation message flow must consist of at least one SpAggregateCreate node and at most one SpAggregateReply node. SpAggregateCreate and SpAggregateReply nodes are deemed to be related to the same aggregate if they contain the same value in their AggregateName property.

The SpAggregateReply node has one input terminal called in and four output terminals, out, lateReplies, timedOut and failure. The SpAggregateReply node is responsible for identifying an input reply message and associating it with the original request messages and the aggregate instance to which it belongs. It does this by matching the reply message CorrelId to the request message generated by one of the SpAggregateCreate nodes. The node then decrements the aggregate’s count of outstanding reply messages and either

The SpAggregateReply node is also responsible for processing timer messages indicating that an aggregate instance has ‘timed out’, i.e. not all reply messages have been received within the time specified by the ReplyTimeoutSeconds property. In this case, a message is sent to the node’s timedOut terminal containing any reply messages already received.

If an error is encountered, the incoming reply message is sent without change through the fail terminal and a message logged to the MQSI V2 message log.

Node terminals

The SpAggregateReply node provides the following terminals:
 
 
 
 
in The input terminal that accepts a reply message for processing by the node.
out
The output terminal to which the aggregated message is propagated.
lateReplies The output terminal to which reply messages are sent if no matching aggregate instance is found. The aggregate instance is deleted when the time out value is exceeded without all reply messages having been received. Any subsequent messages for a timed out aggregate will therefore not find a matching aggregate and are therefore deemed to be late reply messages.
timedOut The output terminal to which an incomplete aggregate message is sent if the aggregate instance has timed out. Should a time out occur, all reply messages already received are built into a single message and propagated to the timedOut terminal.
failure The output terminal to which the message is propagated if an error is encountered while processing the reply message or propagating the aggregated reply message.

Configuring the SpAggregateReply node

When you have put an instance of the SpAggregateReply node into a message flow you can configure it. Right click on the node in the Message Flow Definition pane and select Properties. Click on the Basic tab and enter the name that you wish to give the Aggregate. The name must be the same as the name given to the SpAggregateCreate node(s) which form the deployed aggregate. A timeout value for the aggregate can also be entered (in seconds). This controls how long the SpAggregateReply node will wait for all the replies to be received before timing out the aggregate. The name of the queue to which the reply messages should be sent must also be specified. This should be unique for each deployed aggregate, i.e. the queue can not be shared between deployed aggregates.

Click on the Advanced tab. By setting the destination type for the aggregated reply, you can control the characteristics of the aggregated reply message. The permissible values are described in the table below. You can also specify a sequence of characters to be inserted between each of the individual replies in the aggregated reply message. This is useful in cases where the replies are variable length and must be treated as BLOB type messages.
 
 

SpAggregateReply node properties

Property Default Description
AggregateName   Identifier of the deployed aggregate. There must be one SpAggregateReply node within the same message flow with this identifier.
ReplyTimeoutSeconds  15 Indicates the order in which reply messages should be assembled into the aggregated reply message. Thus, a request message with SequenceNumber set to 25 will be appear before one with its SequenceNumber set to 30.
ReplyToQueue    The name of a local queue to which the reply messages are to be sent prior to being aggregated.
AggregatedReplyDestination  default  The value set for this property controls how the output message will be built. It can take 3 possible values 
  • default – the aggregated message is built without any special destination values. It is assumed that the developer will wire the out terminal to a suitable output queue. 
  • ReplyToQueue – the ReplyToQ and ReplyToQMgr values of the aggregated message are set to the values specified in the original request message. Furthermore, it is assumed that the aggregated message will be processed by an MQReply node or an MQOutput node with ‘Destination Mode’ set to ‘replyToQueue’. Since both of these destinations automatically swap the message CorrelId and MsgId values, the aggregated message is built with these values already reversed. As a result, the message emerging from the MQReply or MQOutput node will have its CorrelId correctly set to the MsgId of the original request message. 
  • DestinationList – the ReplyToQ and ReplyToQMgr values of the original request message are added to the aggregated message’s destination list. This can then be processed by an MQOutput node with its ‘Destination Mode’ set to ‘Destination List’. 
AggregatedReplyDataType BLOB The value set for this property controls how the aggregated reply message will be built.  It can take 2 possible values
  • BLOB - The aggregated reply message will be built as an XML message.
  • XML - The aggregated reply message will be built as an unformatted message.
If XML is the chosen format, then each of the the reply messages arriving at the SpAggregateReply node must contain valid XML.  
AggregatedReplyLabelName A character string which is to be used to build tag names for replies in an XML format aggregated reply.  The actual name used will be a combination of the string specified together with the sequence number of the reply.  For example, if AggregatedReplyLabelName='MyReply' and the reply has SequenceNumber=20, then the derived tag name will be 'MyReply20'.

The value is also used to create the top-level tag in the reply message, e.g.
Root.XML.MyReply.

This property is mandatory if AggregatedReplyDataType=XML.

SeparatorString    A sequence of characters which will be inserted between each of the individual reply messages in the aggregated reply.

This property is ignored if AggregatedReplyDataType=XML.

HexSeparatorString    A sequence of hexadecimal characters (0-9 a-f A-F) representing a character sequence to be inserted between each of the individual reply messages in the aggregated reply. This can be used to specify non-printable characters.

This property is ignored if AggregatedReplyDataType=XML.

Persistent  false   A boolean value that controls the persistence of the aggregate instances.  The default value of 'false' indicates that the aggregate data will be stored in memory only, and consequently, should the broker fail during the processing of an aggregate, any  aggregate data will be irretrievably lost. 

If the property is set to 'true', the aggregator will write recovery messages to a local queue when processing aggregate messages in the SpAggregateCreate and SpAggregateReply nodes.  The recovery queue is named SYSTEM.BROKER.AGGREGATOR.RECOVERY.QUEUE and must be defined as a local queue on the brokers queue manager. 

Recovery messages are written transactionally as part of the existing message flow transaction. You should therefore ensure that if this property is set to 'true', all input and output message operations in the message flow are defined to be transactional.  During the deployment of a message flow containing a recoverable aggregate configuration, the aggregator plug-in reads the recovery queue and any incomplete aggregates are reconstructed for subsequent processing by the aggregator.


© IBM Corporation 2001. All Rights Reserved