Timeout request message

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:
  1. Create or select a message set project that contains the message set.
  2. Create a new message definition file (use the Message Definition File From... option).
  3. Select IBM supplied message and click Next.
  4. Expand the tree for Message Brokers IBM supplied Message Definitions.
  5. Select the entry for the timeout request message, which is shown in the form 6.0.0.1\ibm\nodes\timeout\timeoutrequest.xsd.
Related concepts
Configuring timeout flows
Related reference
TimeoutControl node
TimeoutNotification node
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Last updated : 2009-01-07 15:20:30

ac20815_