This topic shows how to create a timeout
request message.
The format used here is XML, but you can use any format that is
supported by an installed parser.
<TimeoutRequest>
<Action>SET | CANCEL</Action>
<Identifier>String (any alphanumeric string)</Identifier>
<StartDate>String (TODAY | yyyy-mm-dd)</StartDate>
<StartTime>String (NOW | hh:mm:ss)</StartTime>
<Interval>Integer (seconds)</Interval>
<Count>Integer (greater than 0 or -1)</Count>
<IgnoreMissed>TRUE | FALSE</IgnoreMissed>
<AllowOverwrite>TRUE | FALSE</AllowOverwrite>
</TimeoutRequest>
- Action
- Set this element to either SET or CANCEL. An error is generated if you
omit this element or set it to a different value. If you set it to CANCEL,
the only other element that is required is the Identifier, which must match
the Identifier of the TimeoutRequest that is to be canceled.
- Identifier
- Enter an alphanumeric string. An error is generated if you omit this element.
- StartDate
- Set this element to TODAY or to a date specified in yyyy-mm-dd format.
The default value is TODAY.
- StartTime
- Set this element to NOW or to a time specified in hh:mm:ss format. The
default value is NOW. StartTime is assumed to be the broker's local time.
- Interval
- Set this element to an integer that specifies the number of seconds between
propagations of the message. The default value is 0.
- Count
- Set this element to an integer value that is either greater than 0 or
is -1 (which specifies a timeout request that never expires). The default
value is 1.
- IgnoreMissed
- Set this element to TRUE or FALSE to control whether timeouts, that occur
while either the broker or the timeout notification flow is stopped, are processed
the next time that the broker or timeout notification flow is started. The
default value is TRUE, which means that missed timeouts are ignored by the TimeoutNotification node when the broker
or message flow is started. If this value is set to FALSE, the missed timeouts
are all processed immediately by the TimeoutNotification node
when the flow is started.
You must set the Request
Persistence property of the TimeoutControl node
to Yes or Automatic (with
the originating request message being persistent) for the stored timeouts
to persist beyond the restart of the broker or the timeout notification flow.
- AllowOverwrite
- Set this element to TRUE or FALSE, to specify whether subsequent timeout
requests with a matching Identifier can
overwrite this timeout request. The default value is TRUE.
A predefined schema definition of the timeout request
message is provided in the
workbench. Take
the following steps to review the definition or to define it within a message
set:
- Create or select a message set project that contains the message set.
- Create a new message definition file (use the Message
Definition File From... option).
- Select IBM supplied message and click Next.
- Expand the tree for Message Brokers IBM supplied Message Definitions.
- Select the entry for the timeout request message, which
is shown in the form 6.0.0.1\ibm\nodes\timeout\timeoutrequest.xsd.