この章の内容は次のとおりです。
Oracle JDeveloperにおける相関セットの作成
相関セットは、Webサービスのレスポンスを適切なBPELプロセス・サービス・コンポーネント・インスタンスに戻すための方法を提供します。相関セットを使用すると、非同期メッセージを識別して、非同期コールバックが確実に適切なクライアントを特定できるようにすることができます。相関セットは、連携が単純なinvokeとreceiveアクティビティでない場合に定義します。
相関セットは、メッセージ本体の内容に基づいて非同期メッセージの相関を可能にするBPELメカニズムです。この方法を使用するには、BPELプロセスに相関セットを定義します。この方法は、WS-Addressingをサポートしないサービス用、または対話がA > B > A
ではなくA > B > C > A
という形式の場合など、一定の高度な対話パターン用に設計されています。
相関を使用すると、メッセージ本文の内容に基づいて非同期メッセージを関連付けることができます。すべてのビジネス・シナリオに相関が必要なわけではありません。
同期コールでは、会話のコンテキストがスタックまたはTCP接続にわたって保持されるため、相関は必要ありません。
通常、BPELプロセスに承諾することでメッセージが関連付けられ、WS-Addressingヘッダーを使用してWebアプリケーションでセッション・クッキーのように動作するトークンを渡します。詳細は、「非同期サービスでのWS-Addressingの使用」を参照してください。
相関は次のシナリオで必要です。次の各ケースでは、BPELプロセスはメッセージの内容の一部を表示するために構成する必要があり、これを使用してメッセージを受信するために適切なプロセス・インスタンスを選択します。
WS-Addressingをサポートしていない非同期サービスを使用している場合。
別のシステムから要求していないメッセージを受信する場合。
メッセージが複数のサービスを経由し、最初のサービスによって最後のサービスからレスポンスが直接要求された場合。
ファイルを介して通信している場合。
この項では、主要な相関セットの概念に関する概要を説明します。
相関セットを使用する適切なBPELインスタンスは、次のように取得されます。
BPELプロセスは、カスタム相関を許可するために、相関セットと呼ばれる構成を提供します。
相関セットは、メッセージを受信するための適切なプロセスを特定するためにBPELプロセス・サービス・エンジンが使用するプロパティの集合です。
相関セット内の各プロパティは、プロパティ・エイリアスを介して1つ以上のメッセージ・タイプの要素にマッピングできます。図9-1に概要を示します。
次の主な相関のガイドラインに注意してください。
メッセージを受信するプロセスのみが相関に関係します。以前のアクティビティと関連付けるために送信サービスに十分な情報がメッセージに含まれているかぎりは、相関が発生していることを送信者が認識する必要はありません。
相関プロパティは、それを設定するBPELプロセスが存続している間は一意である必要があります。
2つのプロセスが同じ相関トークンを使用していることを確認します。たとえば、プロセスで2つの異なるインスタンスを開始する場合、経費請求プロセスを関連付けるために社会保障番号を使用することは推奨されません。
プロパティは、値または注文書や発注番号などの実際のビジネス識別子から構成できます。文字列である必要はなく、任意の適当なXMLタイプを使用できます。
主な相関概念の属性は次のとおりです。相関ウィザードで相関セットを設計するときに、Oracle JDeveloperでこれらの属性を設定します。
initiate属性は次のように設定されます。
はい: 相関セットは、転送されるメッセージで使用可能なプロパティの値を使用して開始されます。
いいえ: 相関セットは、メッセージで使用可能なプロパティの値を検証します。
pattern属性は次のように設定されます。
イン (BPEL 1.1の場合)またはレスポンス (BPEL 2.0の場合): 相関プロパティは、受信メッセージ上で設定および検証されます。
アウト (BPEL 1.1の場合)またはリクエスト (BPEL 2.0の場合): 相関プロパティは、送信BPELメッセージ上で設定および検証されます。
アウト-イン (BPEL 1.1の場合)またはリクエスト/レスポンス (BPEL 2.0の場合): 相関プロパティは、受信と送信メッセージの両方で設定および検証されます。
プロパティ・エイリアスは、グローバル・プロパティを特定のメッセージ・パートのフィールドにマッピングします。このアクションにより、プロパティ名を、メッセージのパートと場所を表すエイリアスにできます。このエイリアスは、XPath式で使用できます。
表9-1に、相関セットの作成に必要な手順の概要を示します。これらの手順を実行する相関ウィザードのページへの参照および設定する値の例を説明します。
表9-1 相関セットの作成の概要
手順 | 相関ウィザードのページ | 例 |
---|---|---|
交換を関連付けるプロパティ名およびタイプを使用して相関セットを作成します。 |
この情報は、相関ウィザードの「相関セットの定義」ページで設定します。図9-2を参照してください。 |
次のプロパティ名およびタイプを使用してphonenumber相関セットを作成します。
|
会話を開始するinvokeアクティビティまたはreceiveアクティビティに相関を追加し、「開始」を「はい」に設定します。 |
相関ウィザードの「設定の開始」ページで、アクティビティを選択して「開始」属性を設定します。図9-3を参照してください。 |
「internalReceive」 receiveアクティビティを選択して、「開始」を「はい」に設定します。 |
プロパティ・エイリアスのマッピングを各メッセージの適切な要素に作成します。会話の両方のメッセージで同じ値を持つ必要があります。要素は、2つのメッセージで異なる名前および異なる構造にできますが、相関を機能させるには、メッセージに同じ値が含まれている必要があります。 |
この情報は、相関ウィザードの「プロパティ・エイリアス」ページで設定します。図9-7を参照してください。このページでは次の2つのエディタを使用でき、このエディタを使用してプロパティ・エイリアスのマッピングを作成できます。 |
相関セットのプロパティ値を実行時に移入するためにプロパティ・エイリアスを定義します。
|
そのプロパティを使用して同じ相関セットを追加のアクティビティに追加します。それらを「開始」に設定しないでください。BPELプロセスをこれを使用して適切なプロセス・インスタンスを選択します。パターンを適切に設定します。 |
アクティビティ相関エディタの「開始」タブで設定します。図9-10を参照してください。 |
「internalCallback」 invokeアクティビティを選択します。
|
相関セットを次のアクティビティとブランチで作成できます。
receiveアクティビティ
replyアクティビティ
invokeアクティビティ
onMessageブランチ
onEventブランチ
Oracle JDeveloperで相関セットを作成する方法は2種類あります。
アクティビティの相関ウィザードを使用した自動の方法
アクティビティの「相関」タブを使用した手動の方法
相関ウィザードで相関セットを作成する手順は、次のとおりです。
適切なアクティビティ(receiveアクティビティなど)を右クリックし、「相関の設定」を選択します。
相関ウィザードの「相関セットの定義」ページが表示されます。
環境に適したレスポンスを指定してから、「次へ」をクリックします。表9-2に詳細を示します。
表9-2 「相関ウィザード」の「相関セットの定義」ページ
フィールド | 説明 |
---|---|
相関セットの作成 |
選択すると新しい相関セットが作成されます。 |
既存の相関セットの選択 |
選択アクティビティを含ませるための既存相関セットを選択します。 |
名前 |
作成する相関セットの名前を入力します。 |
スコープ |
新しい相関セットを作成するスコープまたはプロセスが表示されます。 |
プロパティ |
|
完了すると、相関ウィザードの「相関セットの定義」ページは図9-2のようになります。
相関ウィザードの「設定の開始」ページが表示されます。
環境に適したレスポンスを指定してから、「次へ」をクリックします。表9-3に詳細を示します。
表9-3 「相関ウィザード」の「設定の開始」ページ
フィールド | 説明 |
---|---|
アクティビティ |
相関が設定されるアクティビティが表示されます。 |
開始 |
このアクティビティが相関セットでイニシエータであるかどうかを選択します。 「はい」に設定されると、相関セットは、送受信されるメッセージで発生するプロパティの値を使用して開始されます。 |
完了すると、相関ウィザードの「設定の開始」ページは図9-3のようになります。
相関ウィザードの「プロパティ・エイリアス」ページが、プロパティを値にマッピングするために表示されます。ウィザードの「相関セットの定義」ページで以前に定義されたプロパティが、「プロパティ・エイリアス」表に表示されます。
「プロパティ・エイリアス」により、変数の特定メッセージ・パートでプロパティをフィールドにマッピングできます。このアクションにより、プロパティをメッセージのパートと場所のエイリアスにできます。
プロパティを表でクリックし、変数のメッセージ・パートをプロパティにマッピングする方法を選択します。表9-4に詳細を示します。
「編集」(1番目)アイコンをクリックして、「エイリアス・エディタ」ダイアログを起動します。
変数を展開します。
プロパティを示すメッセージ・パートを選択して、「OK」をクリックします。図9-4に詳細を示します。
「エイリアス・ドラッグ・アンド・ドロップ・エディタ」(2番目)アイコンをクリックして、「エイリアス・ドラッグ・アンド・ドロップ・エディタ」ダイアログを起動します。
変数の特定メッセージ・パートをプロパティにマッピングするプロパティをさらに選択します。
完了すると、相関ウィザードの「プロパティ・エイリアス」ページは図9-7のようになります。図9-2で作成したプロパティが「プロパティ」列に表示されます。エイリアス・エディタ(図9-4)またはエイリアス・ドラッグ・アンド・ドロップ・エディタ(図9-5)を使用してプロパティがマッピングされたメッセージ要素が「問合せ」列に表示されます。
「次へ」をクリックします。
相関ウィザードの「相関されたアクティビティ」ページが表示されます。図9-8に詳細を示します。
「追加」アイコンをクリックし、さらにアクティビティを相関セットに追加します(複数のアクティビティをこの相関セットに関連付けることができます)。
「アクティビティ・ブラウザ」ダイアログが表示されます。
追加するアクティビティを選択して「OK」をクリックします。図9-9に詳細を示します。
相関ウィザードの「相関されたアクティビティ」ページの「相関アクティビティ」フィールドにこのアクティビティが追加されます。
「相関アクティビティ」フィールドで、アクティビティを選択し、「編集」をクリックして、「アクティビティ相関エディタ」ダイアログの「開始」タブを起動します。図9-10に詳細を示します。
「開始」リストおよび「パターン」リストから適切な値を選択します。この例では、次のように指定します。
「開始」リストから「いいえ」を選択します(相関セットがメッセージ内の使用可能なプロパティを検証するため)。
Patternリストから「リクエスト」を選択します(相関プロパティは、送信BPELメッセージ上で設定および検証されるため)。
BPEL 2.0では、相関がインバウンド・メッセージに適用される場合は「レスポンス」を、相関がアウトバウンド・メッセージに適用される場合は「リクエスト」を、または相関がアウトバウンド・メッセージとインバウンド・メッセージの両方に適用される場合は「リクエスト/レスポンス」を選択できます。
BPEL 1.1では、相関がインバウンド・メッセージ(レスポンス)に適用される場合は「イン」を、相関がアウトバウンド・メッセージ(リクエスト)に適用される場合は「アウト」を、または相関がアウトバウンド・メッセージとインバウンド・メッセージの両方(レスポンスとリクエスト)に適用される場合は「アウト-イン」を選択できます。
「エイリアス」タブをクリックします。
手順4から手順7まで繰り返して、変数のメッセージ・パートをプロパティにマッピングする方法とプロパティを選択します。
完了すると、「エイリアス」ダイアログは図9-11のようになります。
「OK」をクリックして、相関ウィザードの「相関されたアクティビティ」ページに戻ります(図9-12のように表示されます)。
図9-12 「相関ウィザード」の「相関されたアクティビティ」ページ(アクティビティが選択された状態)
「次へ」をクリックし、「アクティビティ」、「相関セット」および「エイリアス」のタブの詳細を確認します。
アクティビティ: 相関とロールに関連するアクティビティが表示されます(たとえば、receiveアクティビティはイニシエータで、invokeアクティビティは応答者)。
相関セット: 相関セットの名前が表示されます。
エイリアス: 相関セットでアクティビティ用に定義されたプロパティ・エイリアスが表示されます。
図9-13に詳細を示します。
「終了」をクリックします。
相関セットが作成されます。
「構造」ウィンドウに、相関ウィザードで定義した相関セット、プロパティおよびプロパティ・エイリアスを表示します。
Oracle BPELデザイナで、いずれかの参加アクティビティの「相関」タブをクリックし、定義した詳細を表示します(たとえば、receiveアクティビティ)。図9-14に詳細を示します。
相関セットで使用されるアクティビティを調べる場合、次の手順を実行します。
Oracle BPELデザイナの上にある「検索」アイコンをクリックして、「相関検索」を選択します。
「相関セット・チューザ」ダイアログが表示されます。
相関セットを選択して「OK」をクリックします。
「相関検索」で、「OK」をクリックします。
相関セットを使用するアクティビティが「ログ」ウィンドウに表示されます。
別のアクティビティを既存の相関セットに追加する場合、アクティビティを右クリックし、「相関の設定」を選択します。
相関ウィザードの「相関セットの定義」ページが表示されます。
「既存の相関セットの選択」を選択します。
「相関セット」リストで、相関セットを選択し、「OK」をクリックします。
相関ウィザードの各ページに従ってアクティビティを定義します。
この項では、非同期サービスで相関セットを手動で作成するための手順について説明します。この例では、invokeアクティビティが関連付けられていないreceiveアクティビティを3つ含むプロセスに相関セットを使用する方法を示します。
次に、SOAPサービスを使用する3つのパートナ・リンクを作成します。
この項の内容は次のとおりです。
融資申請読取り用のアダプタ・サービスを持つ最初のパートナ・リンクを作成します。
申請レスポンス読取り用のアダプタ・サービスを持つ2番目のパートナ・リンクを作成します。
顧客レスポンス読取り用のアダプタ・サービスを持つ3番目のパートナ・リンクを作成します。
次に、3つのreceiveアクティビティ(各パートナ・リンクにつき1つずつ)を作成します。receiveアクティビティでは、情報の送信元のパートナ・リンクを指定します。
次に、相関セットを作成します。相関トークンのセットは、相関グループのすべてのメッセージで共有されるプロパティのセットです。
最初の相関セットを作成する手順は、次のとおりです。
CorrelationSet1
と入力します。NameCorr
と入力します。2番目の相関セットを作成する手順は、次のとおりです。
CorrelationSet2
と入力します。IDCorr
と入力します。次に、相関セットをreceiveアクティビティと関連付けます。次の相関セットのタスクを実行します。
最初の相関グループで、最初と2番目のreceiveアクティビティをCorrelationSet1相関セットと関連付けます。
2番目の相関グループで、2番目と3番目のreceiveアクティビティをCorrelationSet2相関セットと関連付けます。
最初の相関セットをreceiveアクティビティに関連付ける手順は、次のとおりです。
プロパティ・エイリアスを使用すると、グローバル・プロパティを特定のメッセージ・パートのフィールドにマップできます。このアクションにより、プロパティ名を、メッセージのパートと場所を表すエイリアスにできます。このエイリアスは、XPath式で使用できます。
NameCorr相関セットに次の2つのプロパティ・エイリアスを作成します。
NameCorrをreceiveFirst receiveアクティビティのLoanApplメッセージ・タイプ・パートにマップします。このreceiveアクティビティをFirstReceiveパートナ・リンク(FirstReceive.wsdlファイルで定義)と関連付けます。
NameCorrをreceiveSecond receiveアクティビティの受信メッセージ・タイプ・パートLoanAppResponseにマップします。このreceiveアクティビティをSecondReceiveパートナ・リンク(SecondFileRead.wsdlファイルで定義)と関連付けます。
NameCorrのプロパティ・エイリアスを作成する手順は、次のとおりです。
IDCorr相関セットに次の2つのプロパティ・エイリアスを作成します。
IDCorrをreceiveSecond receiveアクティビティのLoanAppResponseメッセージ・タイプ・パートにマップします。このreceiveアクティビティをSecondReceiveパートナ・リンク(SecondFileRead.wsdlファイルで定義)と関連付けます。
IDCorrをreceiveThird receiveアクティビティのCustResponseメッセージ・タイプ・パートにマップします。このreceiveアクティビティをThirdReceiveパートナ・リンク(ThirdFileRead.wsdlファイルで定義)と関連付けます。
IDCorrのプロパティ・エイリアスを作成する手順は、次のとおりです。
SOAコンポジット・アプリケーションの違うリビジョンに同じ変換IDを使用しないでください。BPELプロセスで相関セットを使用する場合は、ユーザーが明示的に対話IDの値を管理します。対話IDの値の生成に関して、Oracle SOA Suiteによって妨害や制約が追加されることはありません。これは、Oracle SOA Suiteで違うリビジョンに対して同じ対話IDが生成されているように見えても、実際はユーザーがこの動作を管理するということを意味します。Oracle SOA Suiteでは、異なるリビジョンの別々のインスタンスに対して同じ対話IDを使用することに対する制限はありません。
相関セットを使用しない場合は、生成される対話IDはユーザーではなく、Oracle SOA Suiteによって決定されるため、生成される対話IDは一意になるので問題はありません。
Oracle SOA Suiteでは、コールバック・ルーティングでリビジョンのチェックは実行されません。コールバック・メッセージのルーティングは、次の情報にのみ基づきます。
対話ID: これは、入力値と相関セットに基づいて計算されます。プロセスの2つのリビジョンに同じ相関セットを使用し、インスタンスの作成時に同じ入力値を入力した場合は、両方のリビジョンとも同じ対話IDを使用してサブスクライブされます。この場合、あるリビジョンに対するコールバックが別のリビジョンに配信される場合に混乱が発生します。
操作名(両方のリビジョンで同じです)。
BPELサービス・コンポーネント名(これも、両方のリビジョンで同じです)。
リビジョン番号の概念は、Oracle SOAコンポジット・アプリケーションには適用可能ですが、BPEL仕様には含まれていません。このため、ルーティングを決定するための要素としては使用されません。
また、コールバックのルーティングの一部としてリビジョンを追加すると、別の問題を引き起こす原因となります。コールバックを送信する場合は、エンドポイントURLも指定します。エンドポイントURLにコンポジット・リビジョンが含まれていない場合(非常に可能性は高い)、メッセージのルーティング先はデフォルトのリビジョンであると判断されます。もしOracle SOA Suiteの実行時にコールバック・ルーティングの一部としてリビジョンのチェックを追加すると、デフォルト以外のリビジョンのインスタンスに対してはコールバックを送信できなくなります。
たとえば、次のBPELプロセスがあるとします。
receive_1という名前のreceiveアクティビティのエントリ(相関セットを使用)
Webサービスを起動するinvokeアクティビティ
receive_2という名前のreceiveアクティビティ
次の手順を実行すると仮定します。
BPELコンポーネントが含まれているcomposite_Aのリビジョン1.0をデプロイします。
相関セットを使用しているリビジョン1.0のインスタンスを作成し、値に123
と入力し、その結果conv_id = "123"
が生成されます。
このタイミングで、このプロセスは一方向のinvokeアクティビティを介してWebサービスを起動し、receive_2アクティビティでコールバックの着信を待機します。
composite_Aのリビジョン2.0をデプロイし、その結果、2.0がデフォルトのリビジョンになります。
Webサービスは、リビジョン1.0のインスタンスに対してコールバックを送信します。しかし、URLの中でリビジョン番号は指定されていません。通常、ユーザーは、URLにリビジョン番号を使用しないようにコールバックを作成しています。これは、Webサービスは外部のものであるため、継続的にリビジョン・タグを使用するようにWebサービスの設定を変更できないからです。なぜならば、リビジョン・タグはOracle SOA Suite内部の仕様で、外部では認識できない概念であるからです。
リビジョン番号が指定されていないため、SOAサーバーではリビジョン番号が2.0であるとみなされるので、もしコールバックのルーティングにリビジョン番号を考慮した場合は、1.0が宛先であるこのコールバックを正しいリビジョンの1.0に転送できません。かわりに、2.0のデフォルトのリビジョンにルーティングしようとしますが、コールバックを待機している2.0のインスタンスは存在しません。
ユーザーは、リビジョンに基づいてコールバック・メッセージをルーティングすることはできません。コールバック・メッセージのルーティングの基準に使用可能なオプションは、変換ID (相関セットを使用しない場合は、これも使用不可)、操作名およびコンポーネント名のみです。
このような理由から、異なるインスタンスには別々の対話IDを使用して(つまり、変換IDの作成のための入力値には異なる値を使用して)混乱を回避し、ルーティングが対話IDのみに基づいて行われるようにする必要があります。
次の使用例を考えてみます。
タイプが同じ複数のパートを持つWSDLメッセージ・タイプのBPEL 2.0プロセス
前述のパートの要素タイプに基づいて定義されているプロパティ・エイリアス
各パートに対して定義されたfromParts
を持つfromParts
要素を使用するインバウンド・メッセージ・アクティビティ(IMA) (receiveアクティビティ、scopeまたはpickアクティビティのonMessageブランチ、BPEL 2.0のscopeアクティビティのonEventブランチなど)を持つプロセスの場合、ランタイム環境でプロパティ・エイリアスが適用されるパートを判断できないため、相関を定義できません。
toParts
要素およびfromParts
要素を使用してWSDLメッセージ・パートをマッピングする方法の詳細は、「BPEL 2.0でのWSDLメッセージ・パートのマップ」を参照してください。
Oracle BPEL Process Managerでは、メッセージ集約機能がサポートされています。複数のメッセージが同じプロセス/パートナ・リンク/操作名にルーティングされる場合、最初のメッセージは新規インスタンスを作成するためにルーティングされ、後続のメッセージは中間プロセスのreceiveアクティビティを使用して作成されたインスタンスを続行するためにルーティングできます。
メッセージ集約を使用すると、同じ操作(またはイベント名)をreceiveアクティビティのエントリおよび中間プロセスのreceiveアクティビティで使用できます。
注意:
この機能では集約のみが実行され、再順序付けは行われません。この機能は、正しくない順序で受信されるメッセージを適切な順序の形式になるよう再順序付けを行いません。したがって、最初のメッセージとは、単に処理された最初のメッセージを意味します。これは、時間順での最初のメッセージとは異なる場合があります。
メッセージ集約機能を活用するには、相関セットを使用する必要があります。
あいまいなコール(最初のreceiveアクティビティと中間プロセスのreceiveアクティビティの両方における)としての同期操作がサポートされています。ただし、これはこの機能の推奨される用途ではないため、使用しないようにしてください。
reenableAggregationOnComplete
プロパティを使用して、メッセージをルーティングするために作成して使用するインスタンス数を制御できます。
BPELプロセス・インスタンス作成を構成する手順は、次のとおりです。
次の例に示すように、相関セットを作成するとします。Oracle BPEL Process Managerに対するすべてのメッセージは、同じ操作名にルーティングされます。メッセージの相関IDは同じとなります。インタフェースWSDLでは、アクティビティのエントリ(receiveInput
)と中間プロセスのreceiveアクティビティ(Continue_Receive
)が区別されません。すべてのメッセージはinitiate
操作を使用して処理されます。すべてのメッセージをルーティングするシングル・インスタンスが作成されます。
このことは、同じパートナ・リンクについて異なる操作名を定義する必要があった11g リリース1 11.1.1.6より前のリリースとは異なります。プロセスで2つの操作を公開する必要があり、コール元で適切な操作名を選択する必要がありました。
<receive name="receiveInput" partnerLink="client" portType="client:BPELProcess1" operation="initiate" variable="inputVariable" createInstance="yes"> <correlations> <correlation initiate="yes" set="CorrelationSet_1"/> </correlations> </receive> <!-- Asynchronous callback to the requester. (Note: the callback location and correlation id is transparently handled using WS-addressing.) --> <assign name="Assign_1"> <copy> <from variable="inputVariable" part="payload" query="/client:BPELProcess1ProcessRequest/client:input"/> <to variable="Invoke_1_initiate_InputVariable" part="payload" query="/ns1:BPELProcess2ProcessRequest/ns1:input"/> </copy> </assign> <receive name="Continue_Receive" partnerLink="client" portType="client:BPELProcess1" operation="initiate" variable="inputVariable" createInstance="no"> <correlations> <correlation initiate="no" set="CorrelationSet_1"/> </correlations> </receive>
イベント配信ネットワーク(EDN)のビジネス・イベントの場合、receiveアクティビティのエントリと中間プロセスのreceiveアクティビティの両方で、operation
属性をbpelx:eventName
に置換します。
bpelx:eventName="ns3:initiateEvent"/>
次の情報が、DLV_AGGREGATION
表に保持されます。
対話ID
ドメイン名
コンポーネント名とタイプ
コンポジット名、ラベルおよびリビジョン
状態
受信日
CIキー
主キー
この情報は、パージ・スクリプトを使用してこの表から、またはOracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページから削除できます。これらのオプションの両方の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。
相関セットを使用したBPELプロセスでは、適切なルーティングが実行されます。メッセージは次のいずれかとなる可能性があります。
新しいインスタンスを作成する起動メッセージ
既存のインスタンスを続行するコールバック・メッセージ
図9-19に、同じ操作(process
)を使用したreceiveアクティビティのエントリと中間プロセスのreceiveアクティビティを示します。
次の例に、同じ操作(process
)を使用したreceiveアクティビティのエントリと中間プロセスのreceiveアクティビティの例を示します。
<receive name="receiveInput" partnerLink="client" portType="client:BPELProcess1" operation="process" variable="inputVariable" createInstance="yes"> <correlations> <correlation initiate="yes" set="CorrelationSet_1"/> </correlations> </receive> <!-- some business logic --> <while name="While_1" condition=*loop for 3 iterations*> <sequence name="Sequence_1"> <receive name="Continue_Receive" partnerLink="client" portType="client:BPELProcess1" operation="process" variable="inputVariable" createInstance="no"> <correlations> <correlation initiate="no" set="CorrelationSet_1"/> </correlations> </receive> <!-- some business logic --> </sequence> </while>
前の例の初期のシナリオでは、次のアクションがBPELプロセスP1で発生します。
パートナによって、4つのメッセージ(メッセージ1、メッセージ2、メッセージ3およびメッセージ4)が同じパートナ(相関ID 101
)に対して提供されます。
メッセージ1によって、BPELプロセスP1の新しいインスタンスが作成されます。このメッセージは起動メッセージとしてマークされます。
メッセージ2、3および4は、Continue_Receive
アクティビティを使用して受信されます。これらのメッセージはコールバック・メッセージとしてマークされます。
while
ループが3回反復されることが想定されるため、インスタンスが閉じます。
ここで、追加メッセージがルーティングされ、これにより、競合状態が発生する可能性があると想定します。表9-13に詳細を示します。
表9-13 メッセージ配信シナリオ
シナリオ | 説明 | 起動メッセージとしてマーク | コールバック・メッセージとしてマーク |
---|---|---|---|
1 |
ここで、パートナによって、同じ相関ID ( |
|
|
2 |
メッセージ4と5が短い時間ウィンドウ内で受信される場合、メッセージ4によってインスタンスBPELプロセスP1が閉じ、メッセージ5がこのインスタンスへのコールバックとしてルーティングされる場合があります。このシナリオによって競合状態が発生する場合があります。次に例を示します。
|
|
|
3 |
これはシナリオ2に類似しています。ただし、この場合、メッセージ7、8および9は受信されません。次に例を示します。
メッセージ・リカバリにはいくつかのオプションがあります。
|
|
|