Configuring aggregation flows

If you are using aggregation on an independent integration server, you can use a remote default queue manager to control the system queues, without the need to install IBM MQ on the same machine as the integration server. Interactions between an independent integration server and IBM MQ can use a client connection to a remote queue manager, by using a default policy setting. For information about using a remote default queue manager, see Using a remote default queue manager and Configuring an integration server to use a remote default queue manager.

As already stated, information about the state of in-flight aggregation messages is held on storage queues that are created in the default queue manager. If there are other nodes in the aggregation message flows that also use the IBM MQ transport but connect to non-default queue managers, it is possible that intermittent timeouts may occur if the back-end services being called respond extremely quickly. In such cases, it is important that state updates to the aggregation system queues are committed before updates to non-default queue managers are committed: intermittent aggregation timeouts can otherwise occur.

By default, the commit order for IBM MQ resources is the order in which the resources have been used by the message flow; for example, if an MQInput node is using a remote client connection to a non-default queue manager to drive the aggregation message flow, the MQInput node link is committed first, and the aggregation node's link to the default queue manager is committed second.

Consider the following example, which shows how the timeout can occur. There is a fan-in message flow at the bottom of the example diagram. This fan-in flow aggregates all the reply messages from the fan-out message flow at the top of the diagram.

In this example, the flow is triggered by a message arriving at the MQInToStartAggr input node, which is using a remote link. The message is propagated through the AggregateControl node to the MQOutput node, which normally sends the message to the back-end application but, in this case, is simply sending it to the fan-in message flow to demonstrate the timing issue. Because the MQOutput node is using the same MQ connection as the input node, the outgoing message is committed first, and the aggregation state message is committed second. Consequently, a message will arrive at the MQInForAggrReplies node before the aggregation state message is visible, and the message will incorrectly be marked as unknown.

ResourceManagers:
  MQConnectionManager:
    defaultQMCommitSequence: 59  # Determines the relative order of commit for default MQ links; set to 59 for commit before other queue managers, and 62 for after them.