Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

For information on migrating to InterSystems IRISOpens in a new tab, see Why Migrate to InterSystems IRIS?

中心概念

この章では、Ensemble の監視に関連した概念について説明します。この章は以下の節で構成されています。

プロダクション

Ensemble プロダクションは、複数の潜在的に異なるソフトウェア・システムを統合する、特化されたソフトウェアとドキュメントのパッケージです。プロダクションには、これらの外部システムと通信する要素だけでなく、プロダクション内部の処理を実行する要素も含まれます。

任意の時点で Ensemble から特定のネームスペース内での実行を許可されるプロダクションは 1 つだけです。

実行中のプロダクションは、管理ポータルが閉じられても実行を継続します。

プロダクションの状態

プロダクションの受け入れ可能な状態だけでなく、問題状態にも精通していることが重要です。以下の状態が管理ポータルに表示されます。

状態 意味
実行中 プロダクションが開始され、正常に動作している場合、そのステータスは [実行中] になります。これは正常な状態です。
停止 プロダクションは、シャットダウン・シーケンスの最後でプロダクションのキューのすべてに同期メッセージが存在しないと停止ステータスになります。これは正常な状態です。
一時停止

応答待ちの同期メッセージが残っているキューが存在する場合、シャットダウン・シーケンスの最後でプロダクションのステータスは中断中になります。プロダクションの設計によっては、このステータスが問題の発生を示していることがあります。問題が疑われる場合は、後述する “プロダクション問題状態の修正” を参照してください。

問題発生 Ensemble が停止しても、プロダクションが適切にシャットダウンしなかった場合に、そのプロダクションは [問題発生] ステータスになります。後述する “プロダクション問題状態の修正” を参照してください。

ビジネス・ホスト

1 つの Ensemble プロダクションには、相互に (および外部システムと) 通信する複数のビジネス・ホストが含まれています。ビジネス・ホストは一部の作業カテゴリに対して責任があります。

3 種類のビジネス・ホストが存在します。プロダクションを監視するために、特定のビジネス・ホストが特定のタイプとして実装された理由の詳細を知っている必要はありません。ただし、タイプがわかっていると便利です。

  • ビジネス・サービスは、インバウンド・アダプタなどを使用して、プロダクション外部から入力を受信します。

  • ビジネス・プロセスは、完全にプロダクション内部の通信とロジックに対して責任があります。

  • ビジネス・オペレーションは、通常、アウトバウンド・アダプタなどを使用して、プロダクションから出力を送信します。

    特定のプロダクション内部の通信とロジックに使用することもできます。

メッセージ

プロダクション内部では、すべての通信がビジネス・ホスト間のリクエスト・メッセージとレスポンス・メッセージを使用して実行されます。プロダクションを大まかに理解するには、メッセージがすべてのトラフィックを運ぶことと、プロダクションの作業がメッセージの処理だということを覚えておけば十分です。

Ensemble のメッセージ・ウェアハウスには例外なくすべてのメッセージが格納され、この情報は管理ポータルで参照できます。この節では、メッセージと参照可能なメッセージの情報について概説します。

メッセージの基本設定

各メッセージは 1 つの要求または 1 つの応答のいずれかです。対応する応答が定義されていない要求がある場合もありますが、理論的にはすべての応答は 1 つの要求とペアになっています。リクエストは、ビジネス・ホストの詳細によって、同期的 (応答を待つ) にも、非同期的 (応答を待たない) にもなります。これを構成することはできません。

各メッセージは、一意の識別番号または ID を保持します。これは、ページの場所に応じて、管理ポータルのさまざまな場所で [ID] または [<オブジェクトId>] のキャプションと共に表示されます。

メッセージにはヘッダがあり、この構造はすべてのメッセージで同じです。ヘッダには、システム内のメッセージをルーティングするのに役立つデータ・フィールドが含まれます。メッセージには本文も含まれています。この本文にはメッセージ・タイプに応じて異なるフィールドが提供されます。

generated description: message parts and ids

各メッセージは、プロダクション開発者が選択した、特定のメッセージ本文クラスを使用します。メッセージ・ボディ・クラスによって、メッセージがリクエストかレスポンスかが決定され、メッセージに含まれるフィールドが決定されます。プロダクションが完成した後で、この決定を構成することはできません。

電子文書交換 (EDI) フォーマットのために、Ensemble は、メッセージを仮想ドキュメントとして表現する特殊なメッセージ・ボディ・クラスを提供しています。この場合、メッセージ・ボディにはメッセージ内のデータを表すためのフィールドは含まれません。Ensemble はそのデータにアクセスするための代替メカニズムを提供しています。概要は、"Ensemble 仮想ドキュメント" を参照してください。

管理ポータルでは、メッセージの全内容が表示され、メッセージ・ヘッダとメッセージ・ボディが 1 つの単位として扱われます。メッセージ・ヘッダの ID がメッセージ全体の ID になります。場合によっては (メッセージ再送信など)、新しいヘッダが (新しい一意の ID と共に) 追加され、結果として、再送信のメッセージの ID が、元のメッセージの ID と相違することもあります。

セッション

メッセージはそれぞれ、特定のセッションに関連付けられています。セッションでは、Ensemble 外部からの第一要求メッセージによって指示されたすべてのアクティビティの最初と最後がマーキングされます。セッションを使用すると、関連するメッセージのセットを容易に参照できるようになるため有用です。管理ポータルにはメッセージを視覚的にトレースするオプションが用意されていて、この表示をセッションごとにフィルタリングできます。

各セッションは一意の数値であるセッション ID を保持しています。1 つのセッションに関連付けられているメッセージはすべて、同一のセッション ID を使用します。Ensemble は、これらのセッション ID を以下のように割り当てます。

  1. 基本要求メッセージがセッションを開始します。セッション ID は、基本要求メッセージの ID と同一です。

  2. このセッションの間にインスタンス化された別のメッセージもすべて基本要求と同じセッション ID を持ちますが、それぞれ一意となるメッセージ ID も保持します。

以下に例を示します。(この例とは違って)、複数のビジネス・ホストが含まれるプロダクションでは 1 つのセッション内のメッセージ ID が連続しない可能性があることに注意してください。新しいメッセージを作成するときは常に、Ensemble で次に空いている整数をメッセージ ID として使用します。

generated description: session and messages

メッセージ・ステータス

各メッセージにはステータスが変化するライフ・サイクルがあります。これらのステータスは、メッセージを表示するほとんどのページで確認できます。表示されるメッセージのステータスは、以下のいずれかです。

Created

メッセージは、送信元と該当キューの間を送信中です。これは、通常のメッセージ・ライフ・サイクルにおける 1 つ目の段階です。

Queued

メッセージはキューに入れられています。これは、通常のメッセージ・ライフ・サイクルにおける 2 つ目の段階です。

Delivered

指定された受信者がメッセージを受け取りました。これは、通常のメッセージ・ライフ・サイクルにおける 3 つ目の段階です。

Completed

指定された受信者がメッセージを受け取り、メッセージの処理を終了しました。これは、通常のメッセージ・ライフ・サイクルにおける 4 つ目の段階です。

Deferred

このステータスは、応答メッセージにのみ適用されます。

ビジネス・オペレーションによって、メッセージ応答を遅延させ、後で配信できます。プロダクション内のどのビジネス・ホストも、応答を判別して最初の要求元に送り返すことができます。ビジネス・オペレーションが応答を延期したときから、最終的に送信されるときまで、その応答メッセージのステータスは Deferred です。

元のメッセージの送信者は、メッセージが延期されたことを認識していません。元の呼び出しが同期であった場合、その応答が送信されるまでその呼び出しは送信元に返されません。

最終的に応答メッセージが送信されると、ステータスが Completed となります。

Discarded

応答メッセージは、対応する要求が期限切れになるタイムアウト期間の経過後に宛先に到達した場合、Discarded となります。

また、メッセージを Discarded とマーキングし、何らかの理由で配信できない一時停止メッセージのステータスを破棄とすることもできます。

Discarded とマーキングされたメッセージでも、ストアには永続的に格納されたままで、明示的に削除した場合しか削除されないことに注意してください。

Suspended

メッセージは、管理者によって手動で一時停止されたか、外部宛先に到達できなかった後にビジネス・オペレーションによって一時停止されました。一部のビジネス・オペレーションは、失敗したメッセージのステータスを Suspended に設定するよう設計されていることに注意してください。

いずれの場合も、このメッセージを管理ポータル内で参照し、失敗した理由を判断でき、必要に応じて再送信できます。 例えば、問題が通信の外側にある場合は、外部のシステムを修復してからメッセージを再送できます。また、破棄も削除も可能です。

Aborted

メッセージは管理者によって中止されました。

Error

メッセージにエラーが発生しました。

要求メッセージと応答メッセージのステータスは異なります。さまざまな理由により、要求と応答のペアを一緒に追跡することはできません。要求は正常に配信されるまでに数回繰り返されることがあること、一部の要求には、到達しない場合は応答を無視できるオプションがあること、一部の応答は、後で配信するために遅延させることができること、応答が設計されていない要求があることが理由として挙げられます。

メッセージの呼び出しスタイルおよびタイム・スタンプ

各メッセージは呼び出しスタイルを保持します。これにはメッセージがどのように送信されたかが示されています。メッセージを送信するビジネス・ホストが呼び出しスタイルを指定します。

  • Queue は、メッセージが 1 つのジョブで作成され、元のジョブが解放された段階でキューに入ることを意味します。その後、メッセージが処理された段階で別のジョブがそのタスクに割り当てられます。

  • InProc は、メッセージが作成されたのと同じジョブで生成、送信、および配信されることを意味します。このジョブは、メッセージがターゲットに配信されるまで、送信者のプール内で再び使用可能になることはありません。

各メッセージに対して、以下の 2 つのタイム・スタンプが記録されます。呼び出しスタイルによって、これらのタイム・スタンプの意味が異なることに注意してください。

  • メッセージによるタイム・スタンプの作成Queue のメッセージの場合は、これは、そのメッセージがキューに入れられた日時です。Inproc のメッセージの場合は、Send メソッドが呼び出された日時です。

  • メッセージ処理タイム・スタンプ。Ensemble は、メッセージがキューから取得されるときに TimeProcessed を設定しますが、このメッセージの処理中にこれを現在の時刻にリセットします。一般的に、完了したメッセージでは、これはメッセージ処理完了時刻を表します。

メッセージの優先度

管理ポータルのいくつかの場所に、メッセージの優先度が表示されます。メッセージの優先度によって、同じメッセージ・キューにある他のメッセージと比較した、そのメッセージの処理方法が決定されます。メッセージ・キューに関する情報は、“プロダクションの監視” の章を参照してください。

Ensemble のメッセージング・エンジンによって、以下に示すメッセージの優先度が決定されます。

  • HighSync (1) — 中断されたタスクの ACK メッセージとアラームに使用されます。

  • Sync (2) — 通常より高い優先度で処理される必要がある同期メッセージに使用されます。

  • Normal (3) — ほとんどの同期メッセージに使用されます。

  • SimSync (4) — BPL 同期の <call> に対して行う非同期呼び出しに使用されます。これにより、要求と応答が処理されたのを確認してから、非同期メッセージがキューに入れられます。

  • Async (6) — 非同期メッセージに使用されます。

ジョブとメッセージ・キュー

ビジネス・ホストはジョブを使用してメッセージを処理します。ジョブは、Ensemble プロダクションによって実行された作業をホストする CPU プロセスです。この用語は、CPU プロセス (“ジョブ”) とビジネス・プロセス (“プロセス”) の混同を避ける目的で使用しています。

一般的に、ジョブは実行中 (メッセージの処理中) か、実行していないかのどちらかです。低いレベルのシステムの視点から見ると、Ensemble プロダクションを構成するものの大部分は、処理を実行するために起動を待っているジョブです。

プールは 1 つ以上のジョブで構成されます。ビジネス・ホストごとに、割り当てられたジョブ専用のプライベート・プールを付与できます。このプールは固定サイズで拡張できません。

ビジネス・ホストがメッセージを受信すると、そのプールから作業をジョブに割り当てます。その後で、ジョブが作業を実行します。ジョブが使用できない場合は、ビジネス・ホストが、ジョブが使用可能になるまで待機します。ジョブが作業を完了すると、プールに返却するか、別のメッセージに対する作業を開始します。

具体的には、メッセージごとに、メッセージが受信順に処理される特定のメッセージ・キューが割り当てられます。キューごとに、1 つずつのプールが関連付けられます。逆もまた同じです。

他のタイプのビジネス・ホストと違って、ビジネス・プロセスは、パブリック・キュー (アクター・キューまたは Ens.ActorOpens in a new tab と呼ばれる) からメッセージを受信するパブリック・プール (アクター・プールと呼ばれる) を使用できます。このアクター・プールとアクター・キューは、プライベート・プールとプライベート・キューを使用しないすべてのビジネス・プロセスで共有されます。

詳細は、"Ensemble プロダクションの構成" の “プール・サイズとアクター・プール・サイズ” を参照してください。

FeedbackOpens in a new tab