TimeoutControl node
Use the TimeoutControl node to process an input message that contains a timeout request.
Information about the state of in-flight messages is held on storage queues that are controlled by IBM® MQ. If you are using timeout flows 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 TimeoutControl node. The storage queues that hold the state information are owned by the queue manager that is associated with the integration node.
If you are using timeout flows 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.
For more information about the queues that are required by the TimeoutControl node, see Configuring the storage of events for timeout nodes.
This topic contains the following sections:
Purpose
The TimeoutControl node validates the timeout request message, stores the message, and propagates the message (unchanged) to the next node in the message flow. For more information, see Sending timeout request messages.
The TimeoutControl node is contained in the Timer drawer of the palette, and is represented in the IBM App Connect Enterprise Toolkit by the following icon:
Using this node in a message flow
Use a TimeoutControl node and a TimeoutNotification node together in a message flow for an application that requires events to occur at particular times, or at regular intervals.
- You need to run a batch job every day at midnight.
- You want information about currency exchange rates to be sent to banks at hourly intervals.
- You want to confirm that important transactions are processed within a certain time period and perform some other specified actions to warn when a transaction has not been processed in that time period.
You can use more than one TimeoutControl node with a TimeoutNotification node. Timeout requests that are initiated by those TimeoutControl nodes are all processed by the same TimeoutNotification node if the same Unique identifier is used for the TimeoutNotification node and each of the TimeoutControl nodes.
- The same Unique identifier is used for your TimeoutNotification node and each of your TimeoutControl nodes.
- The message flow that contains your TimeoutControl nodes and the message flow that contains your TimeoutNotification node are deployed to the same integration server.
Terminals and properties
When you have put an instance of the TimeoutControl 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 TimeoutControl node terminals are described in the following table.
| Terminal | Description |
|---|---|
| In | The input terminal that accepts a message tree for processing (which includes validating the timeout request that is specified in the message tree at Request location) and adds it to the control queue. |
| Failure | The output terminal to which the input message is propagated if a failure is detected during processing in this node. If this terminal is not connected to another node, error information is passed back to the previous node in the message flow. |
| Out | The output terminal to which incoming messages are propagated, unchanged, after successful timeout request processing. If this terminal is not connected to another node, no propagation occurs. If propagation of the message fails, the message is propagated to the Failure terminal. |
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 TimeoutControl node are described in the following table.
| Property | M | C | Default | Description |
|---|---|---|---|---|
| Node name | No | No | The node type, TimeoutControl | 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 Basic properties of the TimeoutControl node are described in the following table.
| Property | M | C | Default | Description | mqsiapplybaroverride command property |
|---|---|---|---|---|---|
| Unique identifier | Yes | Yes | None | This is the only mandatory property for the node. This property specifies a
value that is the same as the value that is specified in the Unique
Identifier for the TimeoutNotification node with
which it is paired. The maximum length of this identifier is 12 characters. This name is also
used to identify a Timer policy (if one exists) to be used by the node (see Timer policy). Specify the name of the policy project and the policy in the format
|
uniqueIdentifier |
| Request location | No | No | None | This property describes where to find the timeout request information in the incoming message. This value can be any valid location in the input message tree and is validated at run time. If you do not specify a request location, InputLocalEnvironment.TimeoutRequest is assumed. For more information about the timeout request message, see Sending timeout request messages. | |
| Request persistence | No | No | Automatic | This property controls whether an incoming timeout request survives a restart
of either the integration server or the message flow that contains the TimeoutNotification node that is paired with this TimeoutControl node. Select Yes if you want the incoming request to persist; select No if you do not. If you select Automatic (the default), the Persistence setting in the Properties folder of the incoming message is used. |
The Message properties of the TimeoutControl node are described in the following table.
The TimeoutControl node Message properties are described in the following table.
| Property | M | C | Default | Description |
|---|---|---|---|---|
| Stored message location | No | No | None | This property identifies the location of the part of the request message that you want to store for propagation by the TimeoutNotification node with which this node is paired. If you do not specify a value, the entire message is stored. You can specify any valid location in the message tree. If you choose to store the entire message, you do not need to specify any values in Message domain, Schema Location, or Document Root. |
| Message domain | No | No | BLOB | The domain that is used to parse the stored
timeout request message by the TimeoutNotification node. If you do not specify a value and the message location is
stored, the default value is BLOB. Select
the name of the parser that you are using. This value, and the three
corresponding values in Message set, Message type, and Message format, are used by the TimeoutNotification node with
which it is paired when it rebuilds the stored message for propagation.
If you have stored the entire request message (by leaving Stored message location blank),
do not specify any values here. If you choose to store part of the
request message, specify values here that reflect the stored request
message fragment as if it were the entire message, which is the case
when it is processed by the TimeoutNotification node. Choose
from the following parsers:
|
| Message model | No | No | None | The name or location of the message model in which the stored timeout request message is defined. |
| Message | No | No | None | The name or location of the global element that models your stored timeout request message, and is contained in your message model schema file. This list is populated with all available messages that are defined in the Message model that you have selected. |
| Physical Format | No | No | None | The name of the physical format of the stored timeout request message. If you are using the MRM parser, select the format of the message from the list in Message format. This list includes all the physical formats that you have defined for this Message set. |
| 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. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |