オーケストレーション
オーケストレーション は、MessageBox データベースを介してメッセージをサブスクライブ (受信) および発行 (送信) できる実行可能なビジネス プロセスです。 また、オーケストレーションは新しいメッセージを構築することもできます。 メッセージは、「メッセージのライフサイクル」で説明されているサブスクリプションとルーティング インフラストラクチャを使用して受信 されます。 オーケストレーションに対応するサブスクリプションが到着すると、新しいインスタンスがアクティブ化され、メッセージが配信されます。インスタンス サブスクリプションの場合は、必要に応じてインスタンスが復元されてメッセージが配信されます。 オーケストレーションから送信されたメッセージは、受信場所に到着したメッセージと同じようにメッセージ ボックスに公開され、ルーティングで使用するための適切なプロパティがデータベースに挿入されます。
オーケストレーション内で構築されたメッセージは、メッセージ ボックス データベースに配置して、オーケストレーション インスタンスが参照できるようにする必要がありますが、まだ送信されていないので公開はしません。 XLANG/s サブサービスは、メッセージ エージェント API を呼び出してメッセージを直接挿入します。 これによって、オーケストレーション エンジンはメッセージ本文をメッセージ ボックスに挿入し、実行中のオーケストレーション インスタンスに直接関連付けることができます。 データベース操作の向上のために、オーケストレーション内の永続化ポイントによって、メッセージ ボックス データベース内の構築されたメッセージの永続性が確保されています。
公開の動作とサブスクライブの動作を区別して見せているのが、オーケストレーションに含まれているバインドという概念です。 オーケストレーションのポートは、対話処理を表す論理ポートです。 メッセージを配信するにはこれらの論理ポートを物理ポートにバインドする必要がありますが、このバインド プロセスで行うことは、メッセージのルーティング用にサブスクリプションを構成する操作のみです。
これらのポートをバインドするための基本オプションは次の 4 つです。
今指定する (オーケストレーション内でポートを直接指定します)。
後で指定する (展開時にポートを指定します)。
オーケストレーション コードでアドレスが設定されている動的送信ポートを使用する。
オーケストレーションからメッセージ ボックス データベースまたは他のオーケストレーションへの直接バインドを作成する。
オーケストレーションの展開
デザイン時にバインドが指定されると、オーケストレーション内で設定されたパラメーターに一致する物理ポートがオーケストレーションの展開時に作成されます。 展開時にバインドを構成した場合は、論理ポートの要件に一致するポートをオーケストレーション ポートにバインドできます。 動的バインドの場合は、[今指定する] オプションを指定した場合のように物理ポートが作成されますが、そのポートはアドレス情報が設定されていない動的送信ポートです。
混同されやすいのは、オーケストレーションの送信ポートを物理送信ポートにバインドしても、メッセージが他のサブスクライバーに配信されるのを防ぐことができないという概念です。 つまり、バインドしたポートに送信されるメッセージに対して、フィルターをとおしたサブスクリプションが別の送信ポートにもあれば、両方の送信ポートがこのメッセージを受信することになります。 バインドを行うと、オーケストレーションから送信されるメッセージが、バインドされている送信ポートの条件に常に一致するようなサブスクリプションが作成されます。 同様に、受信ポートにバインドされたオーケストレーション ポートでは、メッセージの種類と受信ポート ID に基づいて適切なサブスクリプションが作成されます。 サブスクリプションでは、オーケストレーションに出入りするメッセージがバインドされたポートに配信されることを保証しますが、メッセージは前に説明したのと同じ発行とサブスクライブのメカニズムを引き続き通過します。
誤解されやすく、誤って使用される場合や十分に利用されない場合のあるオプションは、直接バインド オプションです。 直接バインドを使用すると、受信場所がメッセージを公開する場合のように、さまざまなルーティング プロパティを使用してオーケストレーションがメッセージ ボックス データベースにメッセージを公開できます。 簡単な直接メッセージングでは、他のメッセージを公開して BizTalk Server で受信する場合と同様に、ルーティング用に昇格させたプロパティを使用してメッセージをメッセージ ボックスに公開します。 これによって、サブスクライバーがこのメッセージを受信できるようになります。ただし、少なくとも 1 つのサブスクライバーが存在する必要があり、存在しない場合はオーケストレーションはルーティング障害のエラーを受信します。
直接バインドには、自己関連付けを行うポートを使用する方法もあります。 自己関連付けを行うポートとは、一意の関連付けトークンを作成し、インスタンス間でメッセージを関連付けるときにそのトークンを単独で使用するポートです。 自己関連付けを行うポートの最も一般的な使用方法は、オーケストレーションを呼び出すか起動して、ポート パラメーターを渡すことです。 呼び出されたオーケストレーションでは、そのポートを使用してメッセージを送信できます。一方、呼び出し元のオーケストレーションでは、同じポートを使用してメッセージを受信できます。 ポートに一意の関連付けトークンがあるので、メッセージは呼び出し元のオーケストレーションにルーティングされます。 自己関連付けを行うポートは、オーケストレーション インスタンス間のプライベートな通信チャネルとして機能します。
最後の方法は、パートナー オーケストレーションを使用する方法です。この方法では、呼び出し元のオーケストレーションと呼び出されたオーケストレーションで、共有している同じポートの種類を使用してポートを構成します。ポート構成では同じポートを選択します。 たとえば、Orch1 および Orch2 で Orch2.MyDirectPort を選択します。 この種類のバインドでは、送信オーケストレーションの種類、ポート名、および操作名に基づいて受信オーケストレーションのサブスクリプションが設定されます。 この方法でも、メッセージが正しいインスタンスに配信されることが保証されます。
直接メッセージングのオプションはすべて、公開およびサブスクライブ モデルが基になっています。 これらのオプションの相違点は、サブスクリプションの作成およびルーティングに使用されるプロパティとその用途です。
オーケストレーション内で直接バインドされたポートを使用した場合に発生する一般的な問題の 1 つは、オーケストレーションが公開するメッセージに対してサブスクリプションが存在する可能性もあることです。 たとえば、オーケストレーションを PurchaseOrder メッセージによってアクティブ化されるように構成したとします。 このオーケストレーションは、直接ポートを使用して PurchaseOrder メッセージをメッセージ ボックスに公開します。 メッセージは予想どおりに受信されますが、オーケストレーションの別のインスタンスにも PurchaseOrder メッセージに対するサブスクリプションがあり、そのインスタンスが起動します。 この処理によって無限ループが生じ、開発者が事態を把握できるまでに時間がかかることがあります。
Correlation
オーケストレーションでの関連付けは、同じ実行中のオーケストレーション インスタンスに関連するメッセージを受信するためのメカニズムです。 オーケストレーション デザイナーで、開発者は次の一般的な手順に従って関連付けを使用します。
メッセージの関連付けに使用する昇格させたプロパティが含まれる関連付けの種類を定義します。
定義した関連付けの種類のインスタンスである関連付けセットを定義します。
送信ポートおよび受信ポートに対して、指定された関連付けセットを開始するかそれに従うかを指定します。
インスタンス サブスクリプションが動作するのは、関連付けセットが開始したとき、つまりこの関連付けセットに従うすべてのポートがメッセージを受信するためのサブスクリプションが作成されたときです。 関連付けに使用されるプロパティは関連付けの種類で定義されているので、オーケストレーション エンジンは開始アクションによって送信または受信されるメッセージからこれらのプロパティを抽出できます。 これらの値は、この関連付けセットに従うすべての他のアクションのサブスクリプションの定義に使用されます。
BizTalk Server が受信して関連付けに使用するメッセージでは、昇格させたプロパティが正しく定義されており、メッセージ コンテキストに昇格されていることが重要です。 大部分のプロパティは、メッセージの最初の受信時にパイプライン内の逆アセンブラー コンポーネントが値を抽出すると昇格されます。 このため、オーケストレーションの実行中のインスタンスに関連付ける必要のあるメッセージをパススルー受信パイプラインで受信することはできません。 この問題は、SOAP 受信アダプターを使用して、関連付けられたメッセージの受信する場合に発生します。これは、Web サービス公開ウィザードを使用した場合、受信パイプラインの既定値がパススルー パイプラインであるためです。