iAnywhere.com - Message details requests

Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 10.0.1 » QAnywhere » Server management requests » Monitoring QAnywhere

Message details requests

To write a server management request for message details, use the <MessageDetailsRequest> tag.

A message details request contains one or more <request> tags containing all the necessary information to register the request. Specifying more than one <request> tag is equivalent to sending multiple separate message details requests.

Use the optional <replyAddr> tag to specify the return address for each report generated as a result of the request. If this tag is omitted, the default return address of reports is the reply address of the originating message.

Use a <requestId> tag to specify a unique identifier for the request that is included in each report generated as a result of this request. Using different values for this field allows more than one request to be active at the same time. Using the same request ID allows the client to override or delete active requests.

Specify a <condition> tag to determine which messages should be included in the report. See Condition tag.

You can also specify a list of details to determine what details of each message should be included in the report. You do this by including a set of empty detail element tags in the request.

You can use the <persistent> tag to specify that event details should be made persistent during any server downtime. This tag does not require any data and can be of the form <persistent/> or <persistent></persistent>.

You can use <schedule> to include all the necessary details needed to register a scheduled report. See Scheduling server management requests.

<MessageDetailsRequest> subtags	Description
<request>	Groups information about a particular request. Specifying more than one <request> tag is equivalent to sending multiple separate server managment requests for message information. See below.

Request tag

<Request> subtags	Description
<address>	Displays the address of each message.
<condition>	Groups conditions for including a message in the report. See Condition tag.
<contentSize>	Requests the content size of each message.
<customRule>	See Custom message requests.
<expires>	Requests the expiration time of each message.
<kind>	Requests whether the message is text or binary.
<messageId>	Requests the message ID of each message.
<originator>	Requests the originator of each message.
<persistent>	Including this tag indicates that the results of the request should be made persistent in the server database (so that the report is sent even if the server is restarted).
<priority>	Requests the priority of each message.
<property>	Requests a list of all message properties and values for each message.
<statusTime>	Requests the status time of each message.
<replyAddr>	Specifies the return address for each report generated as a result of this request. If this tag is omitted, the default return address of reports is the reply address of the originating message.
<requestId>	This value is a unique identifier for the request and is included in each report generated as a result of this request. Using different values for this field allows more than one request to be active at the same time. Using the same request id allows the client to override or delete active requests.
<schedule>	Including this tag indicates that the report should be generated on a schedule. Subtags of <schedule> identify the schedule on which the report runs. See Scheduling server management requests.
<status>	Requests the status of each message.
<transmissionStatus>	Requests the transmission status of each message.

MessageDetailsReport tag

Each Message Details Report is an XML message containing the <MessageDetailsReport> tag, and is composed of a report header followed by optional <message> tags. The header of each report consists of the following tags:

<MessageDetailsReport> subtags	Description
<message>	The body of the report consists of a list of <message> tags whose subtags display the specific details of each message that satisfied the selection criteria. If no messages were selected, or no detail elements were specified in the original request, then no <message> tags will be included in the report. Otherwise, each message will have its own <message> tag.
<messageCount>	The number of messages that satisfy the selection criteria of the request.
<requestId>	The ID of the request that generated the report.
<statusDescription>	A brief description of the reason why this report was generated.
<UTCDateline>	The time and date that this report was generated.

Message tag

<message> subtags	Description
<address>	The address of the message. For example, myclient\myqueue.
<contentSize>	The size of the message content. If the message is a text message, this is the number of characters. If the message is binary, this is the number of bytes.
<expires>	The date and time when the message will expire if it is not delivered.
<kind>	Indicates whether the message is binary (1) or text (2).
<messageId>	The message ID of the new message. See Message headers.
<originator>	The message store ID of the originator of the message.
<priority>	The priority of message: an integer between 0 and 9, where 0 indicates less priority and 9 indicates more priority.
<property>	Properties of the message. See Message properties.
<status>	The current status of the message. The status codes are defined in Pre-defined message properties.
<statusTime>	The time at which the message became its current status. This is the local time.
<transmissionStatus>	The synchronization status of the message. It can be one of: 0 - The message has not been transmitted to its intended recipient message store. 1 - The message has been transmitted to its intended recipient message store. 2 - The recipient and originating message stores are the same so no transmission is necessary. 3 - The message has been transmitted to its intended recipient, but that transmission has yet to be confirmed. There is a possibility that the message transmission was interrupted, and that QAnywhere may transmit the message again.

Examples

Following is an example of a message details report:

<?xml version="1.0" encoding="UTF-8"?>
<MessageDetailsReport>
 <requestId>testReport</requestId>
 <UTCDatetime>Mon Jan 16 15:03:04 EST 2006</UTCDatetime>
 <statusDescription>Scheduled report</statusDescription>
 <messageCount>1</messageCount>
 <message>
  <messageId>ID:26080b8927f83f9722357eab0a0628eb</messageId>
  <status>60</status>
  <property>
   <name>myPropName</name>
   <value>myPropVal</value>
  </property>
 </message>
</MessageDetailsReport>

The following condition selects messages following the search criteria: (msgId=ID:144... OR msgId=ID225... ) AND (status=pending) AND (kind=textmessage) AND (contains the property 'myProp' with value 'myVal' )

<condition>
 <messageId>ID:144d7e44dc2d7e1d</messageId>
 <messageId>ID:22578sd5dsd99s8e</messageId>
 <status>1</status>
 <kind>text</kind>
 <property>myProp=myVal</property>
</condition>

A one-time request is a request that has omitted the <schedule> tag. These requests are used to generate a single report and are deleted as soon as the report has been sent. This request generates a single report that displays the message id, status, and target address of all messages with priority 9 currently on the server.

<?xml version="1.0" encoding="UTF-8"?>
<actions>
 <MessageDetailsRequest>
  <request>
   <requestId>testRequest</client>
   <condition>
    <priority>9</priority>
   </condition>
   <messageId/>
   <status/>
   <address/>
  </request>
 </MessageDetailsRequest>
</actions>

The following sample message details request generates a report that includes the message ID and message status.

<?xml version="1.0" encoding="UTF-8"?>
<actions>
  <MessageDetailsRequest>
    <!-- ... -->
    <messageId />
    <status />
  </MessageDetailsRequest>
</actions>