About this task
Information about the state of in-flight messages is held on storage queues that are
controlled by IBM® MQ, so you must install it on the same computer as
your integration server if you want to use the capabilities that are provided by the TimeoutControl and TimeoutNotification nodes. The storage queues that hold the state
information are owned by the queue manager that is associated with the integration server.
If the integration server has the necessary permissions to create the default
system queues, they are created automatically when a flow containing TimeoutControl or TimeoutNotification nodes is deployed. If the default queues are
not created automatically, you can create them manually; see Creating the default system queues on a WebSphere MQ queue manager.
By default, the storage queue used by all timeout nodes is the SYSTEM.BROKER.TIMEOUT.QUEUE.
However, you can control the queues that are used by different timeout nodes by creating alternative
queues that contain a QueuePrefix variable, and by using a Timer policy to
specify the names of those queues for storing events.
Follow these steps to specify
the queue that is used to store event states:
- Create the storage queue to be used by the timeout nodes. The following queue is required:
- SYSTEM.BROKER.TIMEOUT.QueuePrefix.QUEUE
The QueuePrefix variable can contain any
characters that are valid in a WebSphere® 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 queue, IBM App Connect
Enterprise creates the queue when the
node is deployed; this queue is based on the default queue. If the
queue cannot be created, the message flow is not deployed.
- Create a Timer policy (see Creating policies with the IBM App Connect Enterprise Toolkit).
You can create a policy to be used with either specific timeout requests or with all timeout
requests in an integration server. If the policy is to be used with specific timeout requests,
create the policy with the same name as the Unique
identifier property on the TimeoutNotification and
TimeoutControl nodes. If the policy is to be used with all
timeout requests in an integration server, create the policy with the same name as the integration
server. However, the name of a policy cannot start with a digit; if
the name of the policy is to be the same as that of the integration server, ensure that the name of
the integration server does not start with a digit.
If you delete the Timer policy, the storage queue is not deleted automatically when the policy is
deleted, so you must delete it separately.
- Set the Queue prefix property to the required value (see Timer policy).
- In the TimeoutNotification and TimeoutControl nodes, ensure that the name of the Timer policy is
the same as the name specified in the Unique Identifier
property on the Basic tab; for example, myTimer.
Specify the name of the policy project and the policy on the message flow node in the format
{policyProjectName}:PolicyName. If no Timer
policy exists with the same name as the Unique Identifier,
and if a policy does exist with the same name as the integration server, that 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.