QAnywhere のすべてのメッセージで、同じヘッダーフィールドセットがサポートされます。ヘッダーフィールドには、メッセージを識別してルートを指定するために、クライアントとプロバイダーの両方で使用される値が設定されます。
次のメッセージヘッダーが事前に定義されています。メッセージヘッダーの使い方は、使用するクライアントアプリケーションの種類によって変わります。
メッセージ ID 読み込み専用。新規メッセージのメッセージ ID。このヘッダーの値は、メッセージの送信後にのみ設定されます。 次の項を参照してください。
メッセージの作成時刻のタイムスタンプ 読み込み専用。メッセージの Timestamp ヘッダーフィールドには、メッセージが作成された時刻が格納されます。これは、協定世界時 (UTC: Coordinated Universal Time) です。この時刻は、メッセージが実際に送信された時刻ではないので注意してください。メッセージの実際の送信時刻は、トランザクションの進行状況やクライアント側のキューに登録されているその他のメッセージの影響で、作成時刻よりも遅れる可能性があります。このヘッダーは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。 次の項を参照してください。
返信先アドレス 読み込み／書き込み。VARCHAR(128) 型の返信アドレス。返信アドレスが存在しない場合は NULL。このヘッダーは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。 次の項を参照してください。
メッセージアドレス 読み込み専用。VARCHAR(128) 型の QAnywhere のメッセージアドレス。QAnywhere のメッセージアドレスは id\queue-name の形式を取ります。このヘッダーは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。 次の項を参照してください。
メッセージの再配信のステータス 読み込み専用。再配信のステータスを示す BIT 型の値。1 はメッセージが再配信中であることを示し、0 は再配信中ではないことを示します。
受信されたが受信確認されていないメッセージは、再配信される場合があります。たとえば、メッセージは受信されたものの、メッセージを受信したアプリケーションがメッセージの内容の処理を完了する前にクラッシュした場合などです。このような場合には、メッセージは再配信とマーク付けされて、メッセージの処理が完了していない可能性があることを示す警告が受信側に送信されます。
たとえば、次のような手順を経てメッセージが受信されるとします。
非トランザクション指向の QAnywhere Manager を使用するアプリケーションがメッセージを受信します。
このアプリケーションは、T1 というデータベーステーブルにメッセージの内容とメッセージ ID を書き込み、変更をコミットします。
アプリケーションがメッセージの受信を確認します。
手順 1 と 2、または手順 2 と 3 の間でアプリケーションに障害が発生した場合は、アプリケーションの再起動時にメッセージが再配信されます。
手順 1 と 2 の間で障害が発生した場合は、手順 2 と 3 を実行してメッセージを再配信してください。手順 2 と 3 の間で障害が発生した場合は、メッセージはすでに処理されているので、メッセージの確認のみ必要です。
アプリケーションの障害時に何が起きたかを特定するには、アプリケーションで ml_qa_getredelivered を呼び出して、メッセージがすでに再配信されていたかどうかをチェックします。テーブル T1 で検索する必要があるのは、再配信されるメッセージだけです。アプリケーションで障害が発生することはほとんどないので、この方法は、受信したメッセージのメッセージ ID にアプリケーションからアクセスして、メッセージがテーブル T1 に格納されているかどうかをチェックするよりも効率的です。
このヘッダーは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。
次の項を参照してください。
メッセージの有効期限 読み取り専用。ただし SQL API の場合は読み取り／書き込み。TIMESTAMP 型の有効期限。有効期限がない場合は NULL が返されます。メッセージは、対象となる受信者によって指定の時間内に受信されないと期限切れになります。期限切れになったメッセージは、QAnywhere のデフォルトの削除ルールを使って削除できます。このヘッダーは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。 次の項を参照してください。
メッセージの優先度 読み込み／書き込み。QAnywhere API では、10 レベルの優先度が定義されています。0 が最低の優先度、9 が最高の優先度を表します。クライアントは、優先度 0 ～ 4 を通常のメッセージ、優先度 5 ～ 9 を緊急度の高いメッセージとみなす必要があります。このヘッダーは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。 次の項を参照してください。
どのメッセージへの返信であるかを示すメッセージ ID 読み込み／書き込み。VARCHAR(128) 型の in-reply-to ID。クライアントは、In-Reply-To ID ヘッダーフィールドを使用してメッセージ間リンクを設定できます。これは、応答メッセージをそれに対応する要求メッセージとリンクさせる場合によく使用されます。in-reply-to ID は、返信対象メッセージの ID です。このヘッダーは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。 次の項を参照してください。
一部のメッセージヘッダーは転送ルールで使用できます。 ルールエンジンで定義される変数を参照してください。
参照 |
DocCommentXchange で意見交換できます
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |