OrderBroker オーケストレーションでの処理
このセクションでは、 OrderBroker オーケストレーションが注文を受け取り、プロセス マネージャーのためにそれらを準備する方法について説明します。 まず、オーケストレーションの一般的な動作について説明します。 次に、オーケストレーションがメッセージを処理する方法を説明します。 最後に、オーケストレーションがアトミック トランザクションを使用してパフォーマンスを向上させるしくみを明らかにします。
Note
OrderBroker コードの長さが長いため、Microsoft® Visual Studio でオーケストレーションを開いた状態でこのセクションを読む必要があります。
注文ブローカとは
OrderBroker オーケストレーションの目的は、注文を前処理し、正しいプロセス マネージャーにルーティングすることです。 この前処理は、履歴データベース、サービス提供システム、および受注確認のための情報メッセージの生成から成ります。 OrderBroker では、顧客サービス要求から汎用注文メッセージも作成されます。 この注文の正規化によって、ビジネスプロセスの要素による注文の汎用使用が可能になります。
注文メッセージはマルチパート メッセージであり、ルーティング情報と注文情報に分かれています。 ルーティング情報も汎用的で、どの注文マネージャでも使用できるように設計されています。 こうすることで、ソリューションを拡張しやすくなります。 マルチパート メッセージの詳細については、「マルチ パート メッセージの種類を使用する方法」を参照してください。
ブローカ機能を分離すると、それを別の BizTalk グループに移動することもできます。 OrderBroker は MessageBox データベースに発行します。つまり、直接バインドされているため、ブローカーを別のグループに配置する方が簡単です。オーケストレーションを変更せずにブローカーを移動することもできます。 OrderBroker を別のグループに配置する方法の詳細については、「OrderBroker と OrderManager の間の通信」を参照してください。
Note
OrderBroker オーケストレーションは、通信する OrderManager が 1 つしかないため、注文マネージャー メッセージの OrderMgrType フィールドに定数文字列を割り当てるだけです。 通常、複数の注文マネージャがあるアプリケーションでは、アプリケーションがビジネス ルール エンジンを使用して、このフィールドの値と正しい注文経路を決定します。 ビジネス ルール エンジンの詳細については、「ビジネス ルール の作成と使用」を参照してください。
注文処理
OrderBroker オーケストレーションは、Listen 図形内の 2 つの Receive 図形で始まります。 1 つの受信図形は、カスタマー サポート システムからメッセージを受 け取 ります。もう 1 つのベンダー システムからのメッセージ。 どちらのソースのメッセージも同じスキーマです。
オーケストレーションはメッセージからリターン アドレスを抽出し、それを使用して動的ポート CSRPort のアドレスを設定します。 オーケストレーションはこのポートを使用して受信確認やエラーメッセージを送信します。
OrderBroker オーケストレーションの次の手順では、履歴メッセージ、サービス メッセージ、確認メッセージ、および OrderManager オーケストレーションに送信する注文メッセージを作成します。 オーケストレーションでは、 InsertOrderBody ユーティリティ関数を使用して、履歴メッセージに注文メッセージを追加します。
Note
状況によっては、配信されても使用されないメッセージをソリューションが生成することがあります。 オーダー ブローカ オーケストレーションは送信ポートを使用して、履歴データベースに情報を挿入します。 この送信ポートは配信通知を使用します。 構成では、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 と等しい状態をフィルター処理する Receive 図形を使用します。
OrderBroker オーケストレーションの残りの手順では、さまざまなメッセージを適切なポートに送信します。
入れ子になったスコープのパフォーマンスの向上
OrderBroker オーケストレーションの顕著な点の 1 つは、入れ子になったスコープの使用です。 入れ子になったスコープが使用されている理由の 1 つは、永続化ポイントを制限してパフォーマンスを向上させることです。
オーケストレーション エンジンは、永続化ポイントと呼ばれる実行ポイントでオーケストレーション全体の状態を定期的に保存します。 オーケストレーション エンジンは、 送信 図形を含む複数のオーケストレーション図形を永続化ポイントとして自動的に処理します。 永続化ポイントの一覧とその詳細については、「 永続化とオーケストレーション エンジン」を参照してください。
5 つの Send 図形を使用する 場合、OrderBroker オーケストレーションには 5 つの永続化ポイントが必要です。 ただし、アトミック トランザクション スコープ内で Send 図形をグループ化すると、エンジンはスコープに 1 つの永続化ポイントしか必要としないと認識します。 OrderBroker オーケストレーション内の 4 つの Send 図形は例外ハンドラーの一部ではなく、送信後に何も行う必要がないため、アトミック トランザクション スコープ内に移動できます。 これによって永続化ポイントの数が減ります。 アトミック トランザクションの詳細については、「 Atomic Transactions」を参照してください。
また、トランザクションがすべて同時に終了する場合、入れ子になったトランザクションについて、オーケストレーションが使用する永続化ポイントは 1 つだけです。 したがって、 OrderBroker オーケストレーションがトランザクションを入れ子にする方法により、永続化ポイントがさらに減少します。 Scope 図形の使用により、オーケストレーションには 1 つの永続化ポイントがあります。
ヒント
オーケストレーションの永続化ポイントの数を最小限にすると、パフォーマンスを向上させることができます。 アトミック トランザクションで Send 図形をグループ化して、すべての Send 図形に対して 1 つの永続化ポイントを生成できます。 入れ子になったトランザクションのスコープをすべて同時に終了すると、生成されるトランザクションの永続化ポイントは 1 つだけになります。
アトミック トランザクションのスコープでは例外ハンドラを設定することができません。 このため、オーケストレーションは、長時間実行されるトランザクションの入れ子としてアトミック スコープを配置します。 この外部トランザクションには例外ハンドラーを含めることができます。これは、 Send 図形からの例外を処理するハンドラーです。
ヒント
アトミック トランザクションを長時間実行されるトランザクションの入れ子にする方法は、例外処理を可能にする一般的なパターンです。
参照
ビジネス プロセス管理ソリューションでの処理
プロセス マネージャーのロジック
ビジネス プロセス管理ソリューションの割り込み処理
ExceptionHandler オーケストレーション