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

SQL Anywhere 11.0.1 (日本語) » QAnywhere » QAnywhere リファレンス » メッセージ・ヘッダとメッセージ・プロパティ

 

メッセージ・ヘッダ

QAnywhere のすべてのメッセージで、同じヘッダ・フィールド・セットがサポートされます。ヘッダ・フィールドには、メッセージを識別してルートを指定するために、クライアントとプロバイダの両方で使用される値が設定されます。

次のメッセージ・ヘッダが事前に定義されています。メッセージ・ヘッダの使い方は、使用するクライアント・アプリケーションの種類によって変わります。

  • メッセージ ID   読み込み専用。新規メッセージのメッセージ ID。このヘッダの値は、メッセージの送信後にのみ設定されます。次の項を参照してください。

  • メッセージの作成時刻のタイムスタンプ   読み込み専用。メッセージの Timestamp ヘッダ・フィールドには、メッセージが作成された時刻が格納されます。これは、協定世界時 (UTC: Coordinated Universal Time) です。この時刻は、メッセージが実際に送信された時刻ではないので注意してください。メッセージの実際の送信時刻は、トランザクションの進行状況やクライアント側のキューに登録されているその他のメッセージの影響で、作成時刻よりも遅れる可能性があります。このヘッダは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。次の項を参照してください。

  • 返信先アドレス   読み込み/書き込み。VARCHAR(128) 型の返信アドレス。返信アドレスが存在しない場合は NULL。このヘッダは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。次の項を参照してください。

  • メッセージ・アドレス   読み込み専用。VARCHAR(128) 型の QAnywhere のメッセージ・アドレス。QAnywhere のメッセージ・アドレスは id\queue-name の形式を取ります。このヘッダは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。次の項を参照してください。

  • メッセージの再配信のステータス   読み込み専用。再配信のステータスを示す BIT 型の値。1 はメッセージが再配信中であることを示し、0 は再配信中ではないことを示します。

    受信されたが受信確認されていないメッセージは、再配信される場合があります。たとえば、メッセージは受信されたものの、メッセージを受信したアプリケーションがメッセージの内容の処理を完了する前にクラッシュした場合などです。このような場合には、メッセージは再配信とマーク付けされて、メッセージの処理が完了していない可能性があることを示す警告が受信側に送信されます。

    たとえば、次のような手順を経てメッセージが受信されるとします。

    1. 非トランザクション志向の QAnywhere Manager を使用するアプリケーションがメッセージを受信します。

    2. このアプリケーションは、T1 というデータベース・テーブルにメッセージの内容とメッセージ ID を書き込み、変更をコミットします。

    3. アプリケーションがメッセージの受信を確認します。

    手順 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 です。このヘッダは、メッセージの受信後からロールバックまたはコミットが行われるまでの間に読み込むことができます。ロールバックまたはコミットが行われた後で読み込むことはできません。次の項を参照してください。

一部のメッセージ・ヘッダは転送ルールで使用できます。ルール・エンジンで定義される変数を参照してください。

参照