パブリッシュ/サブスクライブ アーキテクチャ

  • [アーティクル]

パブリッシュ/サブスクライブ型の設計の場合、その構成要素は次の 3 つです。

  • ディストリビューターのプロパティ

  • [サブスクライバー]

  • イベント

    パブリッシャーには、受信場所で受信するメッセージを公開する受信ポート、メッセージを送信する際または別のオーケストレーションを非同期的に開始する際にメッセージを公開するオーケストレーション、および対象アプリケーションまたはトランスポートから応答を受け取る際にメッセージを公開する送信請求 - 応答の送信ポートが含まれます。

    BizTalk Server には、主要なサブスクリプションが 2 つあります。アクティベーションとインスタンスです。 アクティブ化サブスクリプションとは、サブスクリプションを満たすメッセージが受信されたときにサブスクライバーの新しいインスタンスをアクティブ化または作成することを指定するサブスクリプションです。 アクティベーションのサブスクリプションを作成する例としては、フィルター処理を行う送信ポートやオーケストレーションにバインドされている送信ポート、"アクティブ化" プロパティが True に設定されているオーケストレーションの受信図形などがあります。 インスタンス サブスクリプションは、サブスクリプションを満たすメッセージをサブスクライバーの既に実行されているインスタンスにルーティングする必要があることを示します。 インスタンスのサブスクリプションを作成する例としては、関連付けられた受信を行い、BizTalk Server からの応答を待つ要求/応答形式の受信ポートを使用するオーケストレーションがあります。

    2 種類のサブスクリプションの情報レベルでの違いは、インスタンスのサブスクリプションでは一意のインスタンス ID が使用されることです。インスタンス ID はマスターのメッセージ ボックス データベースのサブスクリプション テーブルに保存されます。 オーケストレーション インスタンスまたは受信ポートの処理が終了すると、インスタンスのサブスクリプションは、メッセージ ボックス データベースから削除されます。アクティベーションのサブスクリプションは、オーケストレーションまたは送信ポートが参加している限り、アクティブのままです。

サブスクリプションの作成

サブスクリプションは、BizTalk Server 管理データベースの adm_ServiceClass テーブルに表示される BizTalk Server のサービス クラスで作成されます。 これらのサービスには、キャッシュ サービス、エンドポイント マネージャーでホストされるインプロセスおよび分離メッセージング、および XLANG サブサービスでホストされるオーケストレーション/XLANG が含まれます。 これらの各サービス クラスで、サブスクリプションの作成および公開されたメッセージの受信を行うことができます。

サブスクリプションは、比較ステートメント (述語と呼ばれる) を集めたもので、メッセージ コンテキスト プロパティとサブスクリプションに固有の値が使用されます。 たとえば、多くのサブスクリプションでは、メッセージ コンテキスト プロパティである "メッセージの種類" を使用して、メッセージの種類を指定します。 サブスクリプションの一般的な情報は、メッセージ エージェントによってサブスクリプション テーブルに挿入されます。また、サブスクリプションに指定された操作の種類に応じて、次の述語テーブルのいずれかに特定の述語が格納されます。

  • BitwiseANDPredicates

  • EqualsPredicates

  • EqualsPredicates2ndPass

  • ExistsPredicates

  • FirstPassPredicates

  • GreaterThanOrEqualsPredicates

  • GreaterThanPredicates

  • LessThenOrEqualsPredicates

  • LessThenPredicates

  • NotEqualsPredicates

    これはすべて、MessageBox データベースで Bts_CreateSubscription_<アプリケーション名> とBts_InsertPredicate_<アプリケーション名> ストアド プロシージャを呼び出すことによって実現されます。ここで <、アプリケーション名> はサブスクリプションを作成している BizTalk ホストの名前です。

    送信ポートを参加させる場合、ポートは、少なくともコンテキストの送信ポートのトランスポート ID を持つメッセージのサブスクリプションを作成します。 これにより、送信ポートは、専用のメッセージを常に受信できます。 オーケストレーション ポートが特定の送信ポートにバインドされる場合、バインドに関する情報は、BizTalk 管理データベースに保存されます。 物理送信ポートにバインドされているポートを通じて、メッセージがオーケストレーションから送信される場合、メッセージを送信ポートにルーティングできるように、トランスポート ID がコンテキストに格納されます。 ただし、この送信ポートがオーケストレーションから送信されるメッセージを受信できる唯一の送信ポートではないことに注意してください。 オーケストレーションでメッセージを送信すると、そのメッセージは、関連するすべての昇格させたプロパティと一緒にメッセージ ボックス データベースに公開されます。 バインド済みの送信ポートは、トランスポート ID がコンテキストに含まれるので、メッセージのコピーを受信できます。ただし、他の送信ポート (つまり、オーケストレーション) は、メッセージ プロパティも一致するサブスクリプションを使用できます。 メッセージを直接メッセージ ボックス データベースに公開する場合はいつでも、一致するサブスクリプションを持つすべてのサブスクライバーがメッセージのコピーを受け取ることを理解しておく必要があります。

公開とルーティング

サブスクリプションを作成して有効にした後、処理を行う前にメッセージを公開する必要があります。 前述のいずれかのサービスから BizTalk Server にメッセージが受信されると、メッセージは公開されます。 ここでのルーティングの説明では、アダプターを通じて BizTalk Server に受信されるメッセージに注目します。

メッセージの受信パイプライン処理が行われると、プロパティは、メッセージ コンテキストに昇格されます。 受信アダプターと受信パイプラインによってメッセージが処理された後にメッセージ ボックス データベースにメッセージを公開する準備が整った場合、最初に行われる処理は、メッセージ エージェントが昇格させたプロパティのプロパティ値とメッセージ コンテキストの述語の値をマスターのメッセージ ボックス SQL Server データベースに挿入することです。 データベースにこれらの値が格納されると、メッセージ エージェントは、ルーティングの決定を行うことができます。

次のステップで、メッセージ エージェントは、マスターのメッセージ ボックス データベースに問い合わせて、公開されるメッセージの現在のバッチのサブスクリプションを検索します。 メッセージがデータベースにまだ書き込まれていないことに注意してください。コンテキストのプロパティだけが書き込まれています。 MessageBox のbts_FindSubscriptions ストアド プロシージャは、上記で識別されたサブスクリプション テーブルと述語テーブルに対してクエリを実行し、それらをメッセージの現在のバッチに格納されているメッセージ プロパティにリンクします。

この情報を使用して、メッセージ エージェントは、bts_InsertMessage ストアド プロシージャを呼び出し、サブスクリプションのある各メッセージ ボックス データベースに 1 回メッセージを挿入します。 bts_InsertMessage ストアド プロシージャは、最初にサブスクリプション ID で呼び出されます。 この最初のパスでは、ストアド プロシージャは int_EvaluateSubscriptions ストアド プロシージャを呼び出します。このプロシージャは、サブスクリプションの詳細情報を検索し、メッセージ述語がホストのアプリケーション プロパティと一致することを確認し、状態に応じてアプリケーション固有のキューまたはアプリケーション固有の中断されたキューにメッセージへの参照を挿入することで、アプリケーションのセキュリティ要件を満たしていることを確認します。 メッセージ ID、サブスクリプション ID、サービス ID、および他のサブスクリプション情報は、このアプリケーションで見つかった各サブスクリプション用のアプリケーション固有のキューのテーブルに挿入されます。 メッセージが挿入されると、メッセージのプロパティ テーブルとメッセージの述語テーブルのバッチに関連した値が消去されます。

その後、メッセージの部分ごとに、bts_InsertMessage ストアド プロシージャが呼び出されます。 最初の呼び出しでは、メッセージ コンテキストが渡され、その後、パーツ数、本文パーツ名、ID などのメッセージに関するメタデータと共に SPOOL テーブルに挿入されます。 さらに、メッセージ本文パーツは、int_InsertPart ストアド プロシージャを使用して PARTS テーブルに挿入されます。 次に、bts_InsertMessage ストアド プロシージャが、int_InsertPart ストアド プロシージャに渡されて PARTS テーブルに保存される残りの各メッセージ部分に対して呼び出されます。

メッセージがルーティングされると、レコードを次のテーブルに挿入して、メッセージの特定のインスタンスとその部分を受信する各サービスに参照が追加されます。

  • MessageRefCountLog1

  • MessageRefCountLog2

  • PartRefCountLog1

  • PartRefCountLog2

    これらの参照を使用すると、システムで使用しなくなったメッセージのメッセージ データでメッセージ ボックス データベースがいっぱいにならないように定期的に実行されるクリーンアップ ジョブでメッセージと部分が削除されることを防止できます。 ロックの競合を減らすために、テーブルが 2 つ使用されます。

    メッセージが適切なキューにルーティングされ、スプール テーブルおよび Parts テーブルに格納され、アプリケーション固有のキューで参照されるため、アプリケーション インスタンスで、メッセージをキューから取り出す必要があります。 各ホスト インスタンスには、BizTalk 管理データベースの adm_ServiceClass テーブルで構成されている間隔で継続してデータベースをポーリングする、キューから取り出すスレッドの数が設定されます。 このテーブルには、キューから取り出すスレッドの使用数を示す列があります。 各スレッドは MessageBox データベースを呼び出し、実行中のホスト アプリケーションに適した<bts_DequeueMessages_アプリケーション名> ストアド プロシージャを呼び出します。 このストアド プロシージャでは、ロック セマンティクスを使用して、特定の時点でキュー内のメッセージを操作できるインスタンスとデキュー スレッドが 1 つだけであることを確認します。 ロックを設定するホスト インスタンスは、メッセージを取得し、メッセージを対象のサブサービスに渡します。

    メッセージを受信するサービスがエンドポイント マネージャーの場合、送信ポート (または要求/応答の受信ポートの応答部分) が呼び出されます。メッセージを受信するサービスが XLANG/s サブサービスの場合、サブスクリプションのインスタンス ID が存在するかどうかによって、オーケストレーションが作成されるか、オーケストレーションを検索してサブスクリプションを処理するかが決まります。 次に、このサービスは、他のサービスに参照がない場合にメッセージ データを削除できるように、メッセージおよびメッセージ部分への参照を解放します。

参照

メッセージング エンジン