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