相関セット使用時の新規インスタンスまたは既存インスタンスへのメッセージのルーティング方法

相関セットを使用したBPELプロセスでは、適切なルーティングが実行されます。メッセージは次のいずれかとなる可能性があります。

• 新しいインスタンスを作成する起動メッセージ

• 既存のインスタンスを続行するコールバック・メッセージ

図9-19に、同じ操作(process)を使用したreceiveアクティビティのエントリと中間プロセスのreceiveアクティビティを示します。

図9-19 新規インスタンスまたは既存インスタンスへの新規メッセージのルーティング

「図9-19 新規インスタンスまたは既存インスタンスへの新規メッセージのルーティング」の説明

次の例に、同じ操作(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 (101)に対してメッセージ5が提供されると想定します。メッセージ5はBPELプロセスP1の新しいインスタンスを作成し、whileループ内のContinue_Receiveアクティビティで3つの追加メッセージ(6、7および8)を待機します。	メッセージ1 メッセージ5	メッセージ2 メッセージ3 メッセージ4 メッセージ6 メッセージ7 メッセージ8
2	メッセージ4と5が短い時間ウィンドウ内で受信される場合、メッセージ4によってインスタンスBPELプロセスP1が閉じ、メッセージ5がこのインスタンスへのコールバックとしてルーティングされる場合があります。このシナリオによって競合状態が発生する場合があります。例: メッセージ6が到着すると、新しいインスタンスのreceiveアクティビティのエントリにルーティングされます。 メッセージ7および8が、Continue_Receiveアクティビティにルーティングされます。 メッセージ5は、BPELプロセス・サービス・エンジンのリカバリ部分によってのみContinue_Receiveアクティビティにルーティングされます。これは、クローズされたインスタンスに最初にルーティングされ、処理できなかったためです。	メッセージ1 メッセージ6	メッセージ2 メッセージ3 メッセージ4 メッセージ5 メッセージ7 メッセージ8
3	これはシナリオ2に類似しています。ただし、この場合、メッセージ7、8および9は受信されません。例: メッセージ5は、サブスクライバを待機する、未処理のコールバック・メッセージとなります。 BPELプロセス・サービス・エンジンのリカバリにより、メッセージ5の処理が試行され、使用可能なサブスクライバが存在しないため失敗します。 メッセージ・リカバリにはいくつかのオプションがあります。 Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」プロパティmaxRecoverAttemptを使用したコールバック・メッセージのリカバリ制限。この数によって、起動メッセージやコールバック・メッセージをリカバリするための自動リカバリによる試行回数が指定されます。リカバリ試行回数がこの数を超えると、メッセージの状態は「消耗済」に変更されます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の起動メッセージおよびコールバック・メッセージに対する自動リカバリ試行の構成に関する項を参照してください。 カスタムSQLスクリプトを記述して、criteriaCallbackのstateが0に設定されていることを確認します。このコールバックの相関値は、クローズされた状態(state = 0)でCORRELATION_GROUPに存在します。これは、コールバック・メッセージにクローズされた集約インスタンスのマークが付けられていることを示しています。ビジネス・ロジックに基づいて、これらのインスタンスの取消しやパージを行うことができます。 ノート: BPELは、対話ベースのシステムとして設計されています。未承諾メッセージが処理されていないときは、アプリケーションでは、相関集約の一部として常に受信メッセージを考慮し、ビジネス・ニーズに応じて、メッセージをサブスクライブして処理するか、または無視するかを選択します。	メッセージ1 メッセージ6	メッセージ2 メッセージ3 メッセージ4 メッセージ5