Configuring the storage of events for aggregation nodes

You can use an Aggregation policy to control the storage of events for AggregateControl and AggregateReply nodes.

About this task

Information about the state of in-flight messages is held on storage queues that are controlled by IBM® MQ. The storage queues that hold the state information are owned by the queue manager that is associated with the integration server.

If you are using aggregation on an integration server that is managed by an integration node, you must install IBM MQ on the same computer as your integration node in order to use the capabilities that are provided by the aggregation nodes. 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 more 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.

If the integration server has the necessary permissions to create the default system queues, they are created automatically when a flow containing aggregation nodes is deployed. If the default queues are not created automatically, you can create them manually by running the iib_createqueues command, as described in Creating the default system queues on an IBM MQ queue manager.

By default, the storage queues used by all aggregation nodes are:
  • SYSTEM.BROKER.AGGR.CONTROL
  • SYSTEM.BROKER.AGGR.REPLY
  • SYSTEM.BROKER.AGGR.REQUEST
  • SYSTEM.BROKER.AGGR.UNKNOWN
  • SYSTEM.BROKER.AGGR.TIMEOUT

However, you can control the queues that are used by different aggregation nodes by creating alternative queues containing a QueuePrefix, and using an Aggregation policy to specify the names of those queues for storing events.

Follow these steps to specify the queues that are used to store event states, and to set the expiry time of an aggregation:

Procedure

  1. Create the storage queues to be used by the aggregation nodes.
    The following queues are required:
    • SYSTEM.BROKER.AGGR.QueuePrefix.CONTROL
    • SYSTEM.BROKER.AGGR.QueuePrefix.REPLY
    • SYSTEM.BROKER.AGGR.QueuePrefix.REQUEST
    • SYSTEM.BROKER.AGGR.QueuePrefix.UNKNOWN
    • SYSTEM.BROKER.AGGR.QueuePrefix.TIMEOUT

    The QueuePrefix variable can contain any characters that are valid in an IBM MQ queue name, but must be no longer than eight characters and must not begin or end with a period (.). For example, SET1 and SET.1 are valid queue prefixes, but .SET1 and SET1. are invalid.

    If you do not create the storage queues, IBM App Connect Enterprise creates the set of queues when the node is deployed; these queues are based on the default queues. If the queues cannot be created, the message flow is not deployed.

  2. Create an Aggregation policy (see Creating policies with the IBM App Connect Enterprise Toolkit).
    1. You can create a policy to be used with either a specific aggregation or with all aggregations in an integration server. If the policy is to be used with a specific aggregation, create the policy with the same name as the name that you specify in the Aggregate name property on the AggregateControl and AggregateReply nodes.

      To specify a default Aggregation policy for all message flows that are deployed to an integration server, set the Aggregation property in the server.conf.yaml file to the name of an Aggregation policy. For information about setting properties in the server.conf.yaml file, see Configuring an integration server by modifying the server.conf.yaml file. If the default policy is in the default policy project, you do not need to specify the name of the policy project. If the default policy is in a non-default policy project, qualify the name of the policy with the name of the policy project in the format {policyProjectName}:PolicyName

    2. Set the Queue prefix property of the Aggregation policy to the required value (see Aggregation policy).
    3. Optional: Set the Timeout property of the Aggregation policy to control the expiry time of an aggregation.

    If you delete the Aggregation policy, the storage queues are not deleted automatically when the policy is deleted, so you must delete them separately.

  3. In the AggregateControl and AggregateReply nodes, ensure that the name of the Aggregation policy is the same as the name that is specified in the Aggregate name property on the Basic tab; for example, myAggregation.
    If there is no Aggregation policy with the same name as the Aggregate name node property value, and if there is a default Aggregation policy specified in the server.conf.yaml file, that Aggregation policy is used instead.

What to do next

The properties for the policy are not used by the integration server until you restart or redeploy the message flow, or restart the integration server.