複数の Continuation の使用
複数のアクティビティが存在する環境で追跡プロファイル エディター (TPE) を使用するには、受信ポート、オーケストレーション、および送信ポートを正しい順序でマップするために、アクティビティが追跡されるシナリオを理解する必要があります。
追跡プロファイルでは、TPE によってアクティビティの開始と終了が自動的に評価されます。 アクティビティの開始は最初のデータが収集されたときであり、終了は最後のデータが収集されたときです。
ほとんどの場合、2 つのオーケストレーション間の Continuation など、単一の Continuation を作成する手順は、開発者にとって難しいものではありません。 TPE が複雑になるのは、複数の Continuation の場合です。 複数継続シナリオでは、ビジネス アクティビティ監視 (BAM) アクティビティが複数の受信ポート、オーケストレーション、および送信ポートにまたがる場合です。 1 つのレコードに BAM データを収集するには、すべての BizTalk Server スケジュール間に Continuation を作成する必要があります。 このプロセスは、TPE ユーザー インターフェイス (UI) を使用して完了させる場合には、複雑になります。
このトピックでは、異なるシナリオで単一および複数の Continuation を作成する方法について説明します。
基本シナリオの説明 - 複数の受信ポート、オーケストレーション、および送信ポート
このシナリオは、複数の受信ポート (R)、オーケストレーション (O)、および送信ポート (S) を持つ BizTalk Server で構成されます。 Continuation をリンクするには、一般的な interchangeID コンテキスト プロパティが使用されます。 activityID や他の一意識別子など、任意のコンテキスト プロパティを使用できます。 特定のコンテンツの選択は、このシナリオの説明とは関係ありません。
このシナリオでは、これらのポートおよびオーケストレーションから追跡されるデータ項目、マイルストーン、およびコンテキストの各プロパティの値に関する情報は指定されていません。 マッピングのその部分は、ビジネス ロジックに固有です。 目標は、完了したアクティビティ テーブルの 1 行に、すべてのポートおよびオーケストレーションから全 BAM データを取得することです。 オーケストレーションでメッセージを受信および処理できるさまざまな方法によって、興味深い課題とソリューションを示します。
Note
1 つのポートまたは 1 つのオーケストレーションのシナリオは、複数のポートおよび複数のオーケストレーションのシナリオの特殊なケースと見なすことができます。
シナリオのソリューション 1 - 1 つの受信ポートと 1 つのオーケストレーション
このシナリオでは、メッセージは 1 つの受信ポート (R1) だけで受信され、1 つのオーケストレーション (O1) だけで処理されます。
Continuation の作成手順は次のとおりです。
追跡プロファイルのフォルダー アクティビティ ツリー ビューで Continuation を作成します。
[ イベント ソースの選択 ] ボタンをクリックし、[ コンテキスト プロパティの選択 ] メニュー項目をクリックして、コンテキスト プロパティ スキーマを選択します。
[コンテキスト プロパティ名] ボックスの一覧でインターチェンジ Id プロパティを見つけて、それを選択します。
プロパティ スキーマから、作成した Continuation フォルダーに interchangeID をマップします。
アクティビティ ツリーで新しく作成された interchangeID ノードを右クリックして、マップ元になるポートを選択します。
表示される [ ポートの選択 ] ダイアログ ボックスで、すべての N 個の受信ポートを選択します。
フォルダー アクティビティ ツリーで ContinuationID フォルダーを作成します。
[ イベント ソースの選択 ] ボタンをクリックし、[ オーケストレーション スケジュールの選択 ] メニュー項目をクリックして、各オーケストレーションを開きます。 各オーケストレーションから、オーケストレーションの図形を右クリックして、新しく作成された continuationID に interchangeID コンテキスト プロパティをマップします。
3 つのオーケストレーションによる展開では、追跡プロファイルは次のようになります。
シナリオのソリューション 2 - 1 つの受信ポートと複数のオーケストレーション
このシナリオでは、メッセージは 1 つの受信ポートだけで受信され、個別のオーケストレーションによって処理されます。 この状況は、メッセージが各オーケストレーションに同時に送信された場合に発生します。
この場合、オーケストレーションごとに Continuation と continuationID が必要になります。 継続を作成するプロセスは、シナリオ ソリューション 1 で説明されている手順に似ています。 3 つのオーケストレーション展開の場合、結果の追跡プロファイルは次のようになります。
シナリオのソリューション 3 - コンテンツ ベースのルーティング
このシナリオでは、コンテンツ ベースのルーティング (CBR) のソリューションを定義します。 メッセージは 1 つの受信ポートだけで受信され、1 つの送信ポートだけに送信されます。 このルーティングは、メッセージのコンテキスト プロパティの値に基づいて行われます。 この場合は、1 つの Continuation が必要です。 マッピングは次のようになります。
Note
上記のマッピングは、1 つの受信ポートだけで受信され、すべての送信ポートに送信されるメッセージでも有効です。
シナリオのソリューション 4 - 1 つのオーケストレーション、複数の送信ポート
このシナリオでは、複数の送信があります。 ポートなどです。 メッセージは、処理規則によって決定され、すべての送信ポートに送信されるオーケストレーションの 1 つだけによって処理されます。 この場合は、1 つの Continuation が必要です。 マッピングは次のようになります。
シナリオのソリューション 5 - 順次オーケストレーション
このシナリオでは、メッセージは各オーケストレーションで順に 1 つずつ処理され、Continuation を介して次のオーケストレーションに渡されます。 マッピングは次のようになります。
非同期環境でのデータの収集
Continuation を設定すると、BAM によって到着するデータが要求されます。 非同期環境では、応答をバックエンド プロセスから受信できません。
応答データが受信されないと、アクティビティ インスタンスは無限に待機します。 アクティビティは完了せず、レコードは BAM プライマリ インポート データベースのテーブルに残ります。 長時間実行されるトランザクションのケース、つまり残りのデータがいつ到着するかを確認する手段がない場合を考えてみます。 データの到着がビジネス ロジックまたはプロセスによって異なる場合は、アクティビティが完了としてマークされるタイムアウトが発生しません。 データは同日に到着したり、極端な場合には翌年に到着したりします。
これを解決するには、関連アクティビティを使用します。
アクティビティを 2 つのアクティビティに分割します。 2 つのアクティビティを関連付け、元のアクティビティに応答を関連付けます。
関連するアクティビティの詳細については、「 アクティビティリレーションシップ」を参照してください。