All QAnywhere messages support the same set of header fields. Header fields contain values that are used by both clients and providers to identify and route messages.
The following message headers are predefined. How you use them depends on the type of client application you have.
Message ID Read-only. The message ID of the new message. This header has a value only after the message is sent. See:
Message creation timestamp Read-only. The Timestamp header field contains the time a message was created. It is a coordinated universal time (UTC). It is not the time the message was actually transmitted, because the actual send may occur later due to transactions or other client-side queuing of messages. You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it. See:
Reply-to address Read-write. The reply address as VARCHAR(128) or null if it does not exist. You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it. See:
Message address Read-only. The QAnywhere message address as VARCHAR(128). QAnywhere message addresses take the form id\queue-name. You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it. See:
Redelivered state of message Read-only. The redelivered value as BIT. A value of 1 indicates that the message is being redelivered; 0 indicates that it is not being redelivered.
A message may be redelivered if it was previously received but not acknowledged. For example, the message was received but the application receiving the message did not complete processing the message content before it crashed. In these cases, QAnywhere marks the message as redelivered to alert the receiver that the message might be partly processed.
For example, assume that the receipt of a message occurs in three steps:
An application using a non-transactional QAnywhere manager receives the message.
The application writes the message content and message ID to a database table called T1, and commits the change.
The application acknowledges the message.
If the application fails between steps 1 and 2 or between steps 2 and 3, the message is redelivered when the application restarts.
If the failure occurs between steps 1 and 2, you should process the redelivered message by running steps 2 and 3. If the failure occurs between steps 2 and 3, then the message is already processed and you only need to acknowledge it.
To determine what happened when the application fails, you can have the application call ml_qa_getredelivered to check if the message has been previously redelivered. Only messages that are redelivered need to be looked up in table T1. This is more efficient than having the application access the received message's message ID to check whether the message is in the table T1, because application failures are rare.
You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it.
See:
Expiration of message Read-only except in the SQL API, where it is read-write. The expiration time as TIMESTAMP. Returns null if there is no expiration. A message expires if it is not received by the intended recipient in the specified time. The message may then be deleted using default QAnywhere delete rules. You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it. See:
Priority of message Read-write. The QAnywhere API defines ten levels of priority value, with 0 as the lowest priority and 9 as the highest. Clients should consider priorities 0-4 as gradations of normal priority and priorities 5-9 as gradations of expedited priority. You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it. See:
Message ID of a message for which this message is a reply Read-write. The in-reply-to ID as VARCHAR(128). A client can use the InReplyToID header field to link one message with another. A typical use is to link a response message with its request message. The in-reply-to ID is the ID of the message that this message is replying to. You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it. See:
Some message headers can be used in transmission rules. See Variables defined by the rule engine.
See also |
Discuter à propos de cette page dans DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |