プロセス マネージャーでの注文の流れ
このセクションでは、Southridge Video 注文プロセス マネージャーである OrderManager オーケストレーションが注文を処理する方法について説明します。 順を追って、新しい注文のオーケストレーションでの処理過程を見ていきます。 また、オーケストレーションによって注文の更新がどのように処理されるかについても説明します。
Note
ビジネス プロセス マネージャ ソリューションは、複数の種類のマネージャを使用できるように記述されていますが、実際に使用されているのは 1 つのプロセス マネージャのみです。
OrderManager オーケストレーションは、注文を処理するビジネス プロセスを実装する下位オーケストレーションを調整します。 OrderManager は 2 つのステージを通じて注文を送信します。このステージを組み合わせて、注文を検証し、施設グループに情報を送信し、リモート処理コンポーネントを通じて注文を注文システムに送信し、注文履歴を更新します。 OrderManager を変更しなくても、これらのステージを追加、削除、または変更できます。
Note
OrderManager オーケストレーションのサイズとスコープが原因で、Microsoft Visual Studio でオーケストレーションを開いた状態でこのセクションを読む必要がある場合があります。
注文マネージャの構造
OrderManager オーケストレーションは、オーケストレーションをアクティブにする受信図形で始まります。 次の図は、 OrderManager オーケストレーションの一般的な構造を示しています。
のブロック図
最初の受信図形から 2 つの主要分岐が出ています。 右側の分岐は新しい注文を処理します。 左側の分岐は注文のキャンセルを処理します。 ユーザー入力を受け入れるため、注文が既に完了した後に OrderManager で注文の取り消しを受け取ることができます。 そのようなケースを扱うのが左側の主分岐です。 左側の分岐では、処理中止のフラグを設定し、イベント ログに警告を追加して、これらのキャンセルを処理します。 右側の分岐で注文が処理されている間に到着した注文のキャンセルも、このオーケストレーションで処理されます。
注文処理の分岐は初期化の後に、入れ子構造になった 2 つのループに入ります。 外側のループは、注文処理の各ステージで 1 回実行されます。 内側のループはステージが処理される間、実行されています。 内側のループの中で、注文マネージャは注文の更新に対しても待機します。 ループが終了すると、注文マネージャは完了メッセージを送信します。
注文処理ステージでは、動的な自己相関ポートを使用して OrderManager オーケストレーションに通信します。 これにより、 OrderManager とステージ インスタンスの関連付けが簡略化されます。これは、関連付けセットを使用する必要がないためです。 自己相関ポートの詳細については、「 ポート バインド」を参照してください。
注文の受信
OrderManager は、FromBrokerPort ポートを介して OrderBroker オーケストレーションから注文メッセージを受信します。 このポートは直接メッセージ ボックス データベースにバインドされています。 オーケストレーションには、新しい注文用と更新された注文用の 2 つの 受信 図形がポートに接続されています。
OrderManger は、フィルター式に基づいて処理するメッセージを決定します。 フィルター式は、メッセージの状態フィールドと注文マネージャーの種類フィールド OrderMgrType の値をテストします。 状況フィールドが ACCEPTED と等しく、 OrderMgrType が CABLEORDER の場合、注文は新規であり、このプロセス・マネージャーを対象としています。
新しい注文が到着すると、このオーケストレーションの新しいインスタンスがアクティブになります。 OrderManager は次に、Decision 図形の要求の種類を確認します。 種類が TERMINATE の場合は、オーケストレーションは左側の分岐を実行して注文を終了します。 それ以外の場合は、オーケストレーションは注文の処理を進めます。 これには、この注文に関連する後続メッセージの待機も含まれることに注意してください。
新しい注文の初期化
OrderManager オーケストレーションは、最初のメッセージを受信し、メイン右側のブランチを開始すると、SSOConfigStore から構成情報を取得します。 これは、 Utilities アセンブリで定義されているシングルトン オブジェクトを介して行われます。 構成値はこのオブジェクトのプロパティです。 このオブジェクトは、構成値のローカル キャッシュをサービス指向のアーキテクチャ ソリューションと同様の方法で管理します。 シングルトン オブジェクトの詳細については、「 Business Process Management Solution での SSO の効率的な使用」を参照してください。
サービス指向ソリューションと同様、ビジネス プロセス管理ソリューションでも、シークレット ストアが使用されます。シークレット ストアは、BizTalk がインストールされていれば常に存在するものであり、SSO は値をすぐに使用できるように構成情報をキャッシュできます。さらに、データベース接続文字列やパスワードなどの情報の保護も可能になります。 これらの理由により、シングル サインオン (SSO) がバックエンド アプリケーションの接続管理に使用されていなくても、シークレット ストアは構成情報を保存する場所として適しています。
Note
オーケストレーションは処理を開始する前に構成情報を取得します。 これによって、オーケストレーションが退避されて後で復元するときも同じ構成の使用が可能になります。 脱水の詳細については、「 オーケストレーションの脱水とリハイドレート」を参照してください。
注文マネージャーは、構成データから 1 つの値を使用します。 TotalStages は、注文処理プロセスのステージの合計数です。 マネージャーは、この値をローカル変数 numStages に割り当てます。 また、外側のループ、 ステージ 、 および停止に接続された 2 つの変数も設定します。 ステージは現在のステージを示し、外側のループのカウンターです。停止値を停止します。
最後に、マネージャーは orderStatus 変数を STARTED に設定し、外側の処理ループに入ります。
新しい注文の処理ループ
ステージ 変数の 値が numStages 変数の値より小さい限り、外側のループは実行されます。 つまり各ステージの処理は、外側のループによって進行されます。 内側のループはステージが処理されている限り実行され、 注文の変更があった場合にも備えて待機します。
外側のループ
オーケストレーションは、受信したメッセージ (NewOrderMgrMsg) を変数 OrderMgrMsg に割り当てることで、外部ループを開始 します。 次にメッセージのルーティングの部分にステージと状態がコピーされます。 オーケストレーションでは、メッセージ内の戻りアドレスも StageCompletionPort のアドレスに設定されます。
OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =
StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);
その後、オーケストレーションによって、要求応答ポートである StagePort に注文が送信されます。 注文の処理が開始されたこと示す、ステージからの確認メッセージを待ちます。 ステージは、注文の処理を開始すると OrderAck メッセージを送信します。
Note
OrderAck メッセージは、スキーマではなく .NET クラスによって定義されたソリューション内のいくつかのメッセージの 1 つです。 .NET クラスを使用してメッセージを定義する方法の詳細については、「 ユーザー コードでのメッセージの構築」を参照してください。
オーケストレーションは、受信確認を受信すると、 currentStage 変数にステージを割り当て、内部ループに入ります。
内側のループ
内部ループは、 currentStage 変数が ステージ 変数と等しい限り実行されます。つまり、現在のステージが処理されている限り。 ループの本体は、3 つの Receive 図形を持つ Listen 図形です。 オーケストレーションの左端の図形である Order Request は、次のセクションで説明する注文更新メカニズムの一部です。
注文処理ステージが完了すると、OrderManager オーケストレーションの StageCompletion ポートにメッセージが送信されます。 エラーが原因でステージが突然終了すると、 TerminateedMessage が送信されます。 この場合、 OrderManager は 例外をスローします。 最も外側の例外ハンドラーは例外をキャッチし、エラー メッセージを OperatorPort に送信します。
ステージが OrderMgrMsg を送信すると、OrderManager によってステージ変数がインクリメントされます。 ステージが多い (ステージが numStages 以下) 場合、オーケストレーションは OrderMgrMsg の順序の状態を STAGE_n_COMPLETEDに設定します。ここで、n は現在のステージの数です。 処理するステージがなくなると、注文の状態を COMPLETED に設定して両方のループから出ます。
注文更新
OrderManager オーケストレーションは、内部処理ループ内で注文の更新をリッスンします。 これに使用する Receive 図形 OrderRequest でも FromBrokerPort が使用されていることに注意してください。 ループ内の同じポートで、関連付けセットと組み合わせて受信図形をもう 1 つ使用することにより、BizTalk Server 共通パターンであるコンボイ パターンが形成されます。 コンボイ パターンを使用して、オーケストレーションの同じインスタンスが、特定の操作に接続された最初のメッセージと後続のメッセージを確実に処理するようにします。
注文マネージャが注文に接続されている最初のメッセージを受け取ると、2 つの関連付けセットが初期化されます。 1 つ目の OrderCorrelation では、顧客 ID (CustID) と注文 ID (OrderID) が使用されます。 注文マネージャはこの関連付けを注文処理ステージと共有します。 2 番目の相関関係は、顧客 ID と注文 ID に加えて注文状態 (状態) を使用する、コンボイの相関関係である OrderConvoyCorrelation です。 OrderRequestReceive 図形では、次の関連付けセットとして OrderConvoyCorrelation が使用されます。 関連付けセットをこのように設定することによって、注文に変更があれば、その注文を処理している注文マネージャのインスタンスが変更内容を受信できるようになります。
Note
関連付けセットは、個々のメッセージがオーケストレーションのどのインスタンスに所属するかを決定するために使用するメッセージ プロパティをグループ化したものであることに注意してください。 詳細については、「 オーケストレーションでの関連付けの使用」を参照してください。
OrderManager は、注文の後続のメッセージを受信すると、最初に要求の種類をテストします。 要求の種類が TERMINATE の場合は、決定図形が終了分岐を実行します。 それ以外の場合、オーケストレーションは新しいメッセージが更新に関するものかどうかをテストします。 更新メッセージのシーケンス番号 (SeqNum) は、元の要求よりも大きくなります。 新しいメッセージのシーケンス番号が大きければ、オーケストレーションはそのメッセージで注文処理をやり直します。 更新メッセージのシーケンス番号が元のメッセージのものより大きくない場合は、シーケンス エラーが生じます。 シーケンス番号が等しい場合は、重複注文なので重複エラーのフラグが付きます。
SeqNum の詳細については、「キー メッセージとフィールド」を参照してください。
最終ステップ
ループを終了すると、注文マネージャーは応答アドレスを動的ポート CSRCompletionPort に割り当てます。 次に、完了状態メッセージを作成して送信し、エラーがなかったかどうかをテストします。 エラーがあった場合は、オーケストレーションが終了図形を実行します。それ以外の場合は処理が完了します。
ステージとの調整
OrderBroker オーケストレーションと 2 番目の処理ステージ オーケストレーション (CableOrder2) の両方が履歴データベースにエントリを作成します。 CableOrder2 オーケストレーションは、 OrderBroker オーケストレーションによって入力された履歴情報を更新します。 更新するエントリがデータベースに存在することを確認するために、 OrderBroker は、データベースに使用するポートで配信通知を使用します。
構成では、履歴データベースの OrderBroker 送信ポートを、2 つのポートを含む送信ポート グループにマップします。1 つはテスト構成用のポート (HistoryInsert-Test-SP)、1 つは通常の構成 (HistoryInsert-SP) 用です。 グループの両方のポートをアクティブにしておいた場合は、両方にメッセージが送信されます。 したがって、2 つの配信通知が要求されますが、処理されるのは 1 つだけです。
この状況を回避するには、テスト ポート (HistoryInsert-Test-SP) の登録を解除するか、アプリケーションのテスト バージョンを停止します。 配信通知の詳細については、「 受信確認の使用」を参照してください。
エラーとルーティング修復されたメッセージ - 設計上の選択
注文処理ステージで使用される例外ハンドラー オーケストレーションとオーケストレーションは、エラー処理オーケストレーション (ErrorHandlerOrch) を使用して、修復のために不適切な注文をルーティングします。 このデザインでは、必要とされているフォームで注文を訂正する部署またはグループがあることが前提となっています。 修復された注文は、注文ブローカー オーケストレーション (OrderBroker) を介して再送信されません。 注文は正規化されたフォームで修復されます。 ソリューションの現在のデザインでは、処理オーケストレーションが元の注文の送信元へエラー メッセージを回送します。 ただし、修復された注文は、エラー処理オーケストレーションの MSMQ ポートに回送される必要があります (ソリューションのテスト バージョンでは、ファイル フォルダーが使用されます)。エラー ハンドラーは、修復されたメッセージを呼び出し元のオーケストレーションに返します。
このようなデザインが使用されている理由は、注文ブローカが注文メッセージの検証と正規化を行う重要な役割を担っているからです。 修復を必要とする注文メッセージも正規化されたフォームです。 メッセージの正規化されたフォームを維持することによって、メッセージの送信フォームと正規化フォームの違いに煩わされずに済みます。