このセクションでは、 OrderBroker オーケストレーションが注文を受け取り、プロセス マネージャーのためにそれらを準備する方法について説明します。 このセクションでは、オーケストレーションの一般的な動作について説明することから始めます。 次のパートでは、オーケストレーションがメッセージを処理する方法について説明します。 次に、オーケストレーションがアトミック トランザクションを使用してパフォーマンスを向上させる方法について説明します。
注
OrderBroker コードの長さが長いため、Microsoft® Visual Studio でオーケストレーションを開いた状態でこのセクションを読む必要がある場合があります。
注文ブローカーとは何か？
OrderBroker オーケストレーションの目的は、注文を前処理し、正しいプロセス マネージャーにルーティングすることです。 ここでの前処理は、履歴データベース、サービス システムの情報メッセージの生成、および注文の受信確認で構成されます。 OrderBroker では、顧客サービス要求から汎用注文メッセージも作成されます。 この注文の正規化により、ビジネス プロセスの要素による注文の一般的な消費が可能になります。
注文メッセージは、注文情報から分離されたルーティング情報を含むマルチパート メッセージです。 ルーティング情報も汎用であり、任意の注文マネージャーが使用するように設計されています。 これにより、ソリューションの拡張が容易になります。 マルチパート メッセージの詳細については、「マルチ パート メッセージの種類を使用する方法」を参照してください。
ブローカー関数を分離すると、別の BizTalk グループに移動することもできます。 OrderBroker はメッセージ ボックス データベース (つまり、直接バインド) に発行されるため、ブローカーを別のグループに配置することも容易になります。オーケストレーションを変更せずにブローカーを移動できます。 OrderBroker を別のグループに配置する方法の詳細については、「OrderBroker と OrderManager の間の通信」を参照してください。
注
OrderBroker オーケストレーションは、通信する OrderManager が 1 つしかないため、注文マネージャー メッセージの OrderMgrType フィールドに定数文字列を割り当てるだけです。 通常、複数の注文マネージャーが存在するアプリケーションでは、アプリケーションはビジネス ルール エンジンを使用して、このフィールドの適切な値と注文ルーティングを決定します。 ビジネス ルール エンジンの詳細については、「ビジネス ルール の作成と使用」を参照してください。
注文処理
OrderBroker オーケストレーションは、Listen 図形内の 2 つの受信図形で始まります。 1 つの受信図形は、カスタマー サポート システムからメッセージを 受け取 ります。もう 1 つのメッセージはベンダー システムからのメッセージです。 どちらのソースからのメッセージも同じスキーマを持ちます。
オーケストレーションはメッセージからリターン アドレスを抽出し、それを使用して動的ポート CSRPort のアドレスを設定します。 オーケストレーションでは、このポートを使用して受信確認メッセージとエラー メッセージを送信します。
OrderBroker オーケストレーションの次の手順では、履歴メッセージ、サービス メッセージ、確認メッセージ、および OrderManager オーケストレーションに送信する注文メッセージを作成します。 オーケストレーションでは、 InsertOrderBody ユーティリティ関数を使用して、履歴メッセージに注文メッセージを追加します。
注
場合によっては、ソリューションによって、配信されるが使用されないメッセージが生成される場合があります。 注文ブローカー オーケストレーションでは、送信ポートを使用して履歴データベースに情報を挿入します。 この送信ポートでは、配信通知が使用されます。 構成では、送信ポートを 2 つのポートを含む送信ポート グループにマップします。1 つはテスト構成用のポート (HistoryInsert-Test-SP) で、1 つは通常の構成 (HistoryInsert-SP) 用です。 両方のポートをグループ内で実行したままにすると、ソリューションは両方のポートでメッセージを送信します。 したがって、2 つの配信通知が要求されますが、処理されるのは 1 つだけです。
このような状況を回避するには、テスト ポート (HistoryInsert-Test-SP) の登録を解除するか、アプリケーションのテスト バージョン BTSScn.BPM.OrderBrokerApp.Test を停止します。 配信通知の詳細については、「 受信確認の使用」を参照してください。
OrderManager オーケストレーションに送信するメッセージを作成する場合、OrderBroker オーケストレーションは 2 つの部分を含むマルチパート メッセージを作成します。 1 つの部分にはルーティング情報が含まれています。もう一方の順序自体。 メッセージのルーティング部分 である OrderMgrMsg.Routing は、 SchemaClasses アセンブリ内の C# クラスによって定義されたスキーマを使用します。 ブローカーは、メッセージの順序部分をジェネリックまたは型に依存しない XML ドキュメント (System.Xml.XmlDocument) として扱い、 OrderMgrMsg.Order に割り当てます。
注文マネージャーにとって特に重要なルーティング情報には、 OrderMgrMsg.Routing.OrderMgrType と OrderMgrMsg.Routing.Status という 2 つのフィールドがあります。 ブローカーは 、OrderMgrType を注文を処理する注文マネージャーの型に設定します。 このソリューションでは、注文マネージャーが 1 つしか存在し、フィールドが CABLEORDER に設定されています。 ブローカーでは、 Status フィールドも ACCEPTED に設定されます。 これは、メッセージが新しい注文であることを注文マネージャーに伝える値です。 ソリューションの OrderManager オーケストレーションの注文マネージャーは、CABLEORDER と同じ注文の種類と ACCEPTED と等しい状態をフィルター処理する 受信 図形を使用します。
OrderBroker オーケストレーションの残りの手順では、さまざまなメッセージを適切なポートに送信します。
入れ子になったスコープを使用したパフォーマンスの向上
OrderBroker オーケストレーションに関する顕著な点の 1 つは、入れ子になったスコープの使用です。 入れ子になったスコープの一部は、永続化ポイントを制限することでパフォーマンスを向上させるためにあります。
オーケストレーション エンジンは、永続化ポイントと呼ばれる実行ポイントでオーケストレーション全体の状態を定期的に保存します。 オーケストレーション エンジンは、 送信 図形を含む複数のオーケストレーション図形を永続化ポイントとして自動的に処理します。 永続化ポイントの一覧とその詳細については、「 永続化とオーケストレーション エンジン」を参照してください。
送信 図形が 5 つあるため、OrderBroker オーケストレーションには 5 つの永続化ポイントが必要です。 ただし、アトミック トランザクション スコープ内で Send 図形をグループ化すると、エンジンはスコープに必要な永続化ポイントを 1 つだけ認識します。 OrderBroker オーケストレーションの 4 つの送信図形は例外ハンドラーの一部ではなく、送信後に何も行う必要がないため、アトミック トランザクション スコープ内に移動できます。 これにより、永続化ポイントの数が減ります。 アトミック トランザクションの詳細については、「 アトミック トランザクション」を参照してください。
さらに、オーケストレーション エンジンは、トランザクションがすべて同時に終了する場合、入れ子になったトランザクションに対して 1 つの永続化ポイントを使用します。 したがって、OrderBrokerオーケストレーションがトランザクションを入れ子にする方法は永続化ポイントをさらに減少させます。Scope図形を使用しているため、オーケストレーションには永続化ポイントが1つしかありません。
ヒント
オーケストレーション内の永続化ポイントの数を最小限に抑えることで、パフォーマンスを向上させることができます。 アトミック トランザクションで 送信 図形をグループ化して、すべての 送信 図形に対して 1 つの永続化ポイントを生成できます。 入れ子になったトランザクション スコープを同時に終了すると、トランザクションの永続化ポイントが 1 つ生成されます。
アトミック トランザクション スコープに例外ハンドラーを指定することはできません。 このため、オーケストレーションは実行時間の長いトランザクション内にアトミック スコープを入れ子にします。 この外部トランザクションには例外ハンドラーを含めることができます。これは 、Send 図形からの例外を処理するハンドラーです。
ヒント
実行時間が長いトランザクションの中にアトミックトランザクションをネストすることは、例外処理を可能にする一般的なパターンです。
こちらもご覧ください
ビジネス プロセス管理ソリューションでの処理
プロセス マネージャー ロジック
ビジネス プロセス管理ソリューションでの割り込み処理
ExceptionHandler オーケストレーション