メッセージ
プロダクション内部では、すべての通信がビジネス・ホスト間のリクエスト・メッセージとレスポンス・メッセージを使用して実行されます。プロダクションを大まかに理解するには、メッセージがすべてのトラフィックを運ぶことと、プロダクションの作業がメッセージの処理だということを覚えておけば十分です。
プロダクションのメッセージ・ウェアハウスには例外なくすべてのメッセージが格納され、この情報は管理ポータルで参照できます。この節では、メッセージと参照可能なメッセージの情報について概説します。
メッセージの基本設定
各メッセージは 1 つの要求または 1 つの応答のいずれかです。対応する応答が定義されていない要求がある場合もありますが、理論的にはすべての応答は 1 つの要求とペアになっています。リクエストは、ビジネス・ホストの詳細によって、同期的 (応答を待つ) にも、非同期的 (応答を待たない) にもなります。これを構成することはできません。
各メッセージは、一意の識別番号または ID を保持します。これは、ページの場所に応じて、管理ポータルのさまざまな場所で [ID] または [<オブジェクトId>] のキャプションと共に表示されます。
メッセージにはヘッダがあり、この構造はすべてのメッセージで同じです。ヘッダには、システム内のメッセージをルーティングするのに役立つデータ・フィールドが含まれます。メッセージには本文も含まれています。この本文にはメッセージ・タイプに応じて異なるフィールドが提供されます。
各メッセージは、プロダクション開発者が選択した、特定のメッセージ本文クラスを使用します。メッセージ・ボディ・クラスによって、メッセージがリクエストかレスポンスかが決定され、メッセージに含まれるフィールドが決定されます。プロダクションが完成した後で、この決定を構成することはできません。
電子文書交換 (EDI) フォーマットのために、InterSystems IRIS は、メッセージを仮想ドキュメントとして表現する特殊なメッセージ・ボディ・クラスを提供しています。この場合、メッセージ・ボディにはメッセージ内のデータを表すためのフィールドは含まれません。InterSystems IRIS はそのデータにアクセスするための代替メカニズムを提供しています。概要は、"プロダクション内での仮想ドキュメントの使用法" を参照してください。
管理ポータルでは、メッセージの全内容が表示され、メッセージ・ヘッダとメッセージ・ボディが 1 つの単位として扱われます。メッセージ・ヘッダの ID がメッセージ全体の ID になります。場合によっては (メッセージ再送信など)、新しいヘッダが (新しい一意の ID と共に) 追加され、結果として、再送信のメッセージの ID が、元のメッセージの ID と相違することもあります。
セッション
メッセージはそれぞれ、特定のセッションに関連付けられています。セッションでは、InterSystems IRIS 外部からの第一要求メッセージによって指示されたすべてのアクティビティの最初と最後がマーキングされます。セッションを使用すると、関連するメッセージのセットを容易に参照できるようになるため有用です。管理ポータルにはメッセージを視覚的にトレースするオプションが用意されていて、この表示をセッションごとにフィルタリングできます。
各セッションは一意の数値であるセッション ID を保持しています。1 つのセッションに関連付けられているメッセージはすべて、同一のセッション ID を使用します。InterSystems IRIS は、これらのセッション ID を以下のように割り当てます。
-
基本要求メッセージがセッションを開始します。セッション ID は、基本要求メッセージの ID と同一です。
-
このセッションの間にインスタンス化された別のメッセージもすべて基本要求と同じセッション ID を持ちますが、それぞれ一意となるメッセージ ID も保持します。
以下に例を示します。(この例とは違って)、複数のビジネス・ホストが含まれるプロダクションでは 1 つのセッション内のメッセージ ID が連続しない可能性があることに注意してください。新しいメッセージを作成するときは常に、InterSystems IRIS で次に空いている整数をメッセージ ID として使用します。
メッセージ・ステータス
各メッセージにはステータスが変化するライフ・サイクルがあります。これらのステータスは、メッセージを表示するほとんどのページで確認できます。表示されるメッセージのステータスは、以下のいずれかです。
Created
メッセージは、送信元と該当キューの間を送信中です。これは、通常のメッセージ・ライフ・サイクルにおける 1 つ目の段階です。
Queued
メッセージはキューに入れられています。これは、通常のメッセージ・ライフ・サイクルにおける 2 つ目の段階です。
Delivered
指定された受信者がメッセージを受け取りました。これは、通常のメッセージ・ライフ・サイクルにおける 3 つ目の段階です。
Completed
指定された受信者がメッセージを受け取り、メッセージの処理を終了しました。これは、通常のメッセージ・ライフ・サイクルにおける 4 つ目の段階です。
Deferred
このステータスは、応答メッセージにのみ適用されます。
ビジネス・オペレーションによって、メッセージ応答を遅延させ、後で配信できます。プロダクション内のどのビジネス・ホストも、応答を判別して最初の要求元に送り返すことができます。ビジネス・オペレーションが応答を延期したときから、最終的に送信されるときまで、その応答メッセージのステータスは Deferred です。
元のメッセージの送信者は、メッセージが延期されたことを認識していません。元の呼び出しが同期であった場合、その応答が送信されるまでその呼び出しは送信元に返されません。
最終的に応答メッセージが送信されると、ステータスが Completed となります。
Discarded
応答メッセージは、対応する要求が期限切れになるタイムアウト期間の経過後に宛先に到達した場合、Discarded となります。
また、メッセージを Discarded とマーキングし、何らかの理由で配信できない一時停止メッセージのステータスを破棄とすることもできます。
Discarded とマーキングされたメッセージでも、ストアには永続的に格納されたままで、明示的に削除した場合しか削除されないことに注意してください。
Suspended
メッセージは、管理者によって手動で一時停止されたか、外部宛先に到達できなかった後にビジネス・オペレーションによって一時停止されました。一部のビジネス・オペレーションは、失敗したメッセージのステータスを Suspended に設定するよう設計されていることに注意してください。
いずれの場合も、このメッセージを管理ポータル内で参照し、失敗した理由を判断でき、必要に応じて再送信できます。 例えば、問題が通信の外側にある場合は、外部のシステムを修復してからメッセージを再送できます。また、破棄も削除も可能です。
要求メッセージと応答メッセージのステータスは異なります。さまざまな理由により、要求と応答のペアを一緒に追跡することはできません。要求は正常に配信されるまでに数回繰り返されることがあること、一部の要求には、到達しない場合は応答を無視できるオプションがあること、一部の応答は、後で配信するために遅延させることができること、応答が設計されていない要求があることが理由として挙げられます。
メッセージの呼び出しスタイルおよびタイム・スタンプ
各メッセージは呼び出しスタイルを保持します。これにはメッセージがどのように送信されたかが示されています。メッセージを送信するビジネス・ホストが呼び出しスタイルを指定します。
-
Queue は、メッセージが 1 つのジョブで作成され、元のジョブが解放された段階でキューに入ることを意味します。その後、メッセージが処理された段階で別のジョブがそのタスクに割り当てられます。
-
InProc は、メッセージが作成されたのと同じジョブで生成、送信、および配信されることを意味します。このジョブは、メッセージがターゲットに配信されるまで、送信者のプール内で再び使用可能になることはありません。
各メッセージに対して、以下の 2 つのタイム・スタンプが記録されます。呼び出しスタイルによって、これらのタイム・スタンプの意味が異なることに注意してください。
-
メッセージによるタイム・スタンプの作成。Queue のメッセージの場合は、これは、そのメッセージがキューに入れられた日時です。Inproc のメッセージの場合は、Send メソッドが呼び出された日時です。
-
メッセージ処理タイム・スタンプ。InterSystems IRIS は、メッセージがキューから取得されるときに TimeProcessed を設定しますが、このメッセージの処理中にこれを現在の時刻にリセットします。一般的に、完了したメッセージでは、これはメッセージ処理完了時刻を表します。
メッセージの優先度
管理ポータルのいくつかの場所に、メッセージの優先度が表示されます。メッセージの優先度によって、同じメッセージ・キューにある他のメッセージと比較した、そのメッセージの処理方法が決定されます。メッセージ・キューに関する情報は、“プロダクションの監視” の章を参照してください。
InterSystems IRIS のメッセージング・エンジンによって、以下に示すメッセージの優先度が決定されます。
-
HighSync (1) — 中断されたタスクの ACK メッセージとアラームに使用されます。
-
Sync (2) — 同期メッセージに使用されます。
-
SimSync (4) — BPL 同期の <call> に対して行う非同期呼び出しに使用されます。これにより、要求と応答が処理されたのを確認してから、非同期メッセージがキューに入れられます。
-
Async (6) — その他の非同期メッセージに使用されます。
ジョブとメッセージ・キュー
ビジネス・ホストはジョブを使用してメッセージを処理します。ジョブは、プロダクションによって実行された作業をホストする CPU プロセスです。この用語は、CPU プロセス (“ジョブ”) とビジネス・プロセス (“プロセス”) の混同を避ける目的で使用しています。
一般的に、ジョブは実行中 (メッセージの処理中) か、実行していないかのどちらかです。低いレベルのシステムの視点から見ると、プロダクションを構成するものの大部分は、処理を実行するために起動を待っているジョブです。
プールは 1 つ以上のジョブで構成されます。ビジネス・ホストごとに、割り当てられたジョブ専用のプライベート・プールを付与できます。このプールは固定サイズで拡張できません。
ビジネス・ホストがメッセージを受信すると、そのプールから作業をジョブに割り当てます。その後で、ジョブが作業を実行します。ジョブが使用できない場合は、ビジネス・ホストが、ジョブが使用可能になるまで待機します。ジョブが作業を完了すると、プールに返却するか、別のメッセージに対する作業を開始します。
具体的には、メッセージごとに、メッセージが受信順に処理される特定のメッセージ・キューが割り当てられます。キューごとに、1 つずつのプールが関連付けられます。逆もまた同じです。
他のタイプのビジネス・ホストと違って、ビジネス・プロセスは、パブリック・キュー (アクター・キューまたは Ens.ActorOpens in a new tab と呼ばれる) からメッセージを受信するパブリック・プール (アクター・プールと呼ばれる) を使用できます。このアクター・プールとアクター・キューは、プライベート・プールとプライベート・キューを使用しないすべてのビジネス・プロセスで共有されます。
詳細は、"プロダクションの構成" の “プール・サイズとアクター・プール・サイズ” を参照してください。