この章では、相関セットを使用して、非同期コールバックが確実に適切なクライアントを特定できるようにする方法について説明します。また、集約パターンを使用して、同じインスタンスにメッセージをルーティングする方法についても説明します。
この章には次の項が含まれます:
相関セットは、Webサービスのレスポンスを適切なBPELプロセス・サービス・コンポーネント・インスタンスに戻すための別の方法を提供します。相関セットを使用すると、非同期メッセージを識別して、非同期コールバックが確実に適切なクライアントを特定できるようにすることができます。
相関セットは、メッセージ本体の内容に基づいて非同期メッセージの相関を可能にするBPELメカニズムです。この方法を使用するには、.bpel
ファイルに相関セットを定義します。この方法は、WS-Addressingをサポートしないサービス用、または対話がA > B > A
ではなくA > B > C > A
という形式の場合など、一定の高度な対話パターン用に設計されています。
この項では、Oracle JDeveloperを使用して非同期サービスで相関セットを使用する方法について説明します。相関セットでは、メッセージ本体の内容に基づいて非同期メッセージを関係付けることができます。相関セットは、連携が単純なinvokeとreceiveアクティビティでない場合に定義します。この例では、invokeアクティビティが関連付けられていないreceiveアクティビティを3つ含むプロセスに相関セットを使用する方法を示します。
この項では、非同期サービスで相関セットを使用するための手順について説明します。
プロジェクトを作成する手順は、次のとおりです。
Oracle JDeveloperを起動します。
「ファイル」メイン・メニューから「新規」→「アプリケーション」の順に選択します。
「SOAアプリケーション」を選択し、「OK」をクリックします。
SOAアプリケーションの作成ウィザードが表示されます。
「アプリケーション名」フィールドに、MyCorrelationSetApp
と入力します。
残りのすべての設定に対するデフォルト値をそのまま使用し、「次へ」をクリックします。
「プロジェクト名」フィールドに、MyCorrelationSetComposite
と入力します。
残りのすべての設定に対するデフォルト値をそのまま使用し、「次へ」をクリックします。
「コンポジット・テンプレート」セクションで、BPELプロセスを使用するコンポジットを選択し、「終了」をクリックします。
「BPELプロセスの作成」ダイアログが表示されます。
表9-1に示されている値を入力します。
残りのすべての設定に対するデフォルト値をそのまま使用し、「OK」をクリックします。
次に、SOAPサービスを使用する3つのパートナ・リンクを作成します。
この項では、次の内容を説明します。
融資申請読取り用のアダプタ・サービスを持つ最初のパートナ・リンクを作成します。
申請レスポンス読取り用のアダプタ・サービスを持つ2番目のパートナ・リンクを作成します。
顧客レスポンス読取り用のアダプタ・サービスを持つ3番目のパートナ・リンクを作成します。
最初のパートナ・リンクとファイル・アダプタ・サービスを作成する手順は、次のとおりです。
「MyCorrelationSet」 BPELプロセスをダブルクリックします。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
最初の「パートナ・リンク」アクティビティをデザイナの右スイムレーンにドラッグします。
最上部の3つ目のアイコン(「サービス・ウィザード」アイコン)をクリックします。図9-1に示すように、この操作でアダプタ構成ウィザードが起動します。
「サービスまたはアダプタの設定」ダイアログで「ファイル・アダプタ」を選択し、「OK」をクリックします。
「ようこそ」ダイアログで「次へ」をクリックします。
「サービス名」ダイアログの「サービス名」フィールドにFirstReceive
と入力し、「次へ」をクリックします。
「アダプタ・インタフェース」ダイアログで、デフォルト設定をそのまま使用し、「次へ」をクリックします。
「操作」ダイアログで「操作タイプ」として「Read File」を選択し、「次へ」をクリックします。「操作名」フィールドには、Readが自動的に入力されます。
「着信ファイル用のディレクトリ(物理パス)」フィールドの上で「参照」をクリックします。
ファイルの読取り元のディレクトリを選択します(この例ではC:\files\receiveprocess\FirstInputDirを選択します)。
「選択」をクリックします。
「次へ」をクリックします。
「ファイルのフィルタ処理」ダイアログで、適切なファイル・フィルタ・パラメータを入力します。
「次へ」をクリックします。
「ファイル・ポーリング」ダイアログで、適切なファイル・ポーリング・パラメータを入力します。
「次へ」をクリックします。
「メッセージ」ダイアログで「URL」フィールドの横にある「参照」をクリックして、「タイプ・チューザ」ダイアログを表示します。
適切なXSDスキーマ・ファイルを選択します。この例では、Book1_4.xsdはスキーマであり、スキーマ要素としてLoanApplが選択されています。
「OK」をクリックします。
「URL」フィールドと「スキーマ要素」フィールドに値が入力されます(この例ではそれぞれBook1_4.xsdとLoanAppl)。
「次へ」をクリックします。
「終了」をクリックします。
「パートナ・リンク」ダイアログが再び表示されます。その他すべてのフィールドには値が自動的に入力されます。ダイアログは表9-2のようになります。
「OK」をクリックします。
2番目のパートナ・リンクとファイル・アダプタ・サービスを作成する手順は、次のとおりです。
2番目の「パートナ・リンク」アクティビティを「FirstReceive」パートナ・リンク・アクティビティの下にドラッグします。
最上部の3つ目のアイコン(「サービス・ウィザード」アイコン)をクリックします。
「サービスまたはアダプタの設定」ダイアログで「ファイル・アダプタ」を選択し、「OK」をクリックします。
「ようこそ」ダイアログで「次へ」をクリックします。
「アダプタ・タイプ」ダイアログで「ファイル・アダプタ」を選択し、「次へ」をクリックします。
「サービス名」ダイアログの「サービス名」フィールドにSecondFileRead
と入力し、「次へ」をクリックします。この名前は、第9.1.1.2.1項「最初のパートナ・リンクとファイル・アダプタ・サービスの作成」のステップ7で入力した名前とは異なる必要があります。
「アダプタ・インタフェース」ダイアログで、デフォルト設定をそのまま使用し、「次へ」をクリックします。
「操作」ダイアログで「操作タイプ」として「Read File」を選択します。
「操作名」フィールドの名前をRead1
に変更します。
「次へ」をクリックします。
「物理パス」として「ディレクトリ名は次の方法で指定します」を選択します。
「着信ファイル用のディレクトリ(物理パス)」フィールドの上で「参照」をクリックします。
ファイルの読取り元のディレクトリを選択します(この例ではC:\files\receiveprocess\SecondInputDirと入力します)。
「選択」をクリックします。
「次へ」をクリックします。
「ファイルのフィルタ処理」ダイアログで、適切なファイル・フィルタ処理パラメータを入力します。
「次へ」をクリックします。
「ファイル・ポーリング」ダイアログで、適切なファイル・ポーリング・パラメータを入力します。
「次へ」をクリックします。
「メッセージ」ダイアログで「URL」フィールドの横にある「参照」をクリックして、「タイプ・チューザ」ダイアログを表示します。
適切なXSDスキーマ・ファイルを選択します。この例では、Book1_5.xsdはスキーマであり、スキーマ要素としてLoanAppResponseが選択されています。
「OK」をクリックします。
「URL」フィールドと「スキーマ要素」フィールドに値が入力されます(この例ではそれぞれBook1_5.xsdとLoanAppResponse)。
「次へ」をクリックします。
「終了」をクリックします。
「パートナ・リンク」ダイアログが再び表示されます。その他すべてのフィールドには値が自動的に入力されます。ダイアログは表9-3のようになります。
「OK」をクリックします。
3番目のパートナ・リンクとファイル・アダプタ・サービスを作成する手順は、次のとおりです。
3番目の「パートナ・リンク」アクティビティを「SecondReceive」パートナ・リンク・アクティビティの下にドラッグします。
最上部の3つ目のアイコン(「サービス・ウィザード」アイコン)をクリックします。
「サービスまたはアダプタの設定」ダイアログで「ファイル・アダプタ」を選択し、「OK」をクリックします。
「ようこそ」ダイアログで「次へ」をクリックします。
「アダプタ・タイプ」ダイアログで「ファイル・アダプタ」を選択し、「次へ」をクリックします。
「サービス名」ダイアログの「サービス名」フィールドにThirdFileRead
と入力し、「次へ」をクリックします。この名前は、第9.1.1.2.1項「最初のパートナ・リンクとファイル・アダプタ・サービスの作成」のステップ7および第9.1.1.2.2項「2番目のパートナ・リンクとファイル・アダプタ・サービスの作成」のステップ6で入力した名前とは異なる必要があります。
「アダプタ・インタフェース」ダイアログで、デフォルト設定をそのまま使用し、「次へ」をクリックします。
「操作」ダイアログで「操作タイプ」として「Read File」を選択します。
「操作名」フィールドの名前をRead2
に変更します。この名前は一意である必要があります。
「次へ」をクリックします。
「物理パス」として「ディレクトリ名は次の方法で指定します」を選択します。
「着信ファイル用のディレクトリ(物理パス)」フィールドの上で「参照」をクリックします。
ファイルの読取り元のディレクトリを選択します(この例ではC:\files\receiveprocess\ThirdInputDirと入力します)。
「選択」をクリックします。
「次へ」をクリックします。
「ファイルのフィルタ処理」ダイアログで、適切なファイル・フィルタ処理パラメータを入力します。
「次へ」をクリックします。
「ファイル・ポーリング」ダイアログで、適切なファイル・ポーリング・パラメータを入力します。
「次へ」をクリックします。
「メッセージ」ダイアログで「URL」フィールドの横にある「参照」をクリックして、「タイプ・チューザ」ダイアログを表示します。
適切なXSDスキーマ・ファイルを選択します。この例では、Book1_6.xsdはスキーマであり、スキーマ要素としてCustResponseが選択されています。
「OK」をクリックします。
「URL」フィールドと「スキーマ要素」フィールドに値が入力されます(この例ではそれぞれBook1_6.xsdとCustResponse)。
「次へ」をクリックします。
「終了」をクリックします。
「パートナ・リンク」ダイアログが再び表示されます。その他すべてのフィールドには値が自動的に入力されます。ダイアログは表9-4のようになります。
「OK」をクリックします。
次に、3つのreceiveアクティビティ(各パートナ・リンクにつき1つずつ)を作成します。receiveアクティビティでは、情報の送信元のパートナ・リンクを指定します。
最初のreceiveアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
デザイナの「receiveInput」receiveアクティビティの下に、「Receive」アクティビティをドラッグ・アンド・ドロップします。
「Receive」アイコンをダブルクリックし、「Receive」ダイアログを表示します。
表9-5に示す詳細を入力して、最初のパートナ・リンク(FirstReceive)を最初のreceiveアクティビティと関連付けます。
表9-5 「Receive」ダイアログのフィールドと値
フィールド | 値 |
---|---|
名前 |
|
パートナ・リンク |
FirstReceive |
インスタンスの作成 |
このチェック・ボックスを選択します。 |
「操作」(Read)フィールドは自動的に入力されます。
「変数」フィールドの右側にある最初のアイコンをクリックします。これは、変数を自動作成するアイコンです。
「変数の作成」ダイアログで「OK」をクリックします。
receiveFirst_Read_InputVariableという名前の変数が自動的に「変数」フィールドに作成されます。
ステップ4の説明にあるように「インスタンスの作成」チェック・ボックスが選択されていることを確認します。
「OK」をクリックします。
2番目のreceiveアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」から2番目のreceiveアクティビティを「receiveFirst」receiveアクティビティの下にドラッグします。
「Receive」アイコンをダブルクリックし、「Receive」ダイアログを表示します。
表9-6に示す詳細を入力して、2番目のパートナ・リンク(SecondReceive)を2番目のreceiveアクティビティと関連付けます。
表9-6 「Receive」ダイアログのフィールドと値
フィールド | 値 |
---|---|
名前 |
|
パートナ・リンク |
SecondFileRead |
インスタンスの作成 |
このチェック・ボックスは選択しないでください。 |
「操作」(Read1)フィールドは自動的に入力されます。
「変数」フィールドの右側にある最初のアイコンをクリックします。
「変数の作成」ダイアログで「OK」をクリックします。
receiveSecond_Read1_InputVariableという名前の変数が自動的に「変数」フィールドに作成されます。
「OK」をクリックします。
3番目のreceiveアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」から3番目のreceiveアクティビティを「receiveSecond」receiveアクティビティの下にドラッグします。
「Receive」アイコンをダブルクリックし、「Receive」ダイアログを表示します。
表9-7に示す詳細を入力して、3番目のパートナ・リンク(ThirdReceive)を3番目のreceiveアクティビティと関連付けます。
表9-7 「Receive」ダイアログのフィールドと値
フィールド | 値 |
---|---|
名前 |
|
パートナ・リンク |
ThirdFileRead |
インスタンスの作成 |
このチェック・ボックスは選択しないでください。 |
「操作」(Read2)フィールドは自動的に入力されます。
「変数」フィールドの右側にある最初のアイコンをクリックします。
「変数の作成」ダイアログで「OK」をクリックします。
receiveThird_Read2_InputVariableという名前の変数が自動的に「変数」フィールドに作成されます。
「OK」をクリックします。
各receiveアクティビティが、特定のパートナ・リンクに関連付けられました。
次に、相関セットを作成します。相関トークンのセットは、相関グループのすべてのメッセージで共有されるプロパティのセットです。
最初の相関セットを作成する手順は、次のとおりです。
Oracle JDeveloperの「構造」ウィンドウで「相関セット」を右クリックし、「すべての子ノードを開く」を選択します。
2番目の「相関セット」フォルダを右クリックして、「相関セットの作成」を選択します。
「相関セットの作成」ダイアログの「名前」フィールドでCorrelationSet1
と入力します。
「プロパティ」セクションで、「追加」アイコンをクリックして「プロパティ・チューザ」ダイアログを表示します。
「プロパティ」を選択し、「追加」アイコン(上の最初のアイコン)をクリックして「プロパティの作成」ダイアログを表示します。
「名前」フィールドに、NameCorr
と入力します。
「タイプ」フィールドの右側にある「参照」アイコンをクリックします。
「タイプ・チューザ」ダイアログで「string」を選択し、「OK」をクリックします。
「OK」をクリックして、「プロパティの作成」ダイアログ、「プロパティ・チューザ」ダイアログおよび「相関セットの作成」ダイアログを閉じます。
2番目の相関セットを作成する手順は、次のとおりです。
Oracle JDeveloperの「構造」ウィンドウの「相関セット」セクションに戻ります。
「相関セット」フォルダを右クリックして、「相関セットの作成」を選択します。
「相関セットの作成」ダイアログの「名前」フィールドでCorrelationSet2
と入力します。
「プロパティ」セクションで、「追加」アイコンをクリックして「プロパティ・チューザ」ダイアログを表示します。
「プロパティ」を選択し、「追加」アイコンをクリックして「プロパティの作成」ダイアログを表示します。
「名前」フィールドに、IDCorr
と入力します。
「タイプ」フィールドの右側にある「参照」アイコンをクリックします。
「タイプ・チューザ」ダイアログで「double」を選択し、「OK」をクリックします。
「OK」をクリックして、「プロパティの作成」ダイアログ、「プロパティ・チューザ」ダイアログおよび「相関セットの作成」ダイアログを閉じます。
次に、相関セットをreceiveアクティビティと関連付けます。次の相関セットのタスクを実行します。
最初の相関グループで、最初と2番目のreceiveアクティビティをCorrelationSet1相関セットと関連付けます。
2番目の相関グループで、2番目と3番目のreceiveアクティビティをCorrelationSet2相関セットと関連付けます。
2番目の相関セットをreceiveアクティビティに関連付ける手順は、次のとおりです。
「receiveSecond」receiveアクティビティをダブルクリックし、「Receive」ダイアログを表示します。
「追加」アイコンをクリックして、「相関セット」ドロップダウン・リストを表示します。
「CorrelationSet2」を選択し、次に「OK」をクリックします。
「開始」列をクリックしてドロップダウン・リストを表示し、「はい」に設定します。
「追加」を再度クリックし、「CorrelationSet1」を選択します。
「OK」をクリックします。
「開始」列をクリックしてドロップダウン・リストを表示し、「CorrelationSet1」で「いいえ」を選択します。
「OK」をクリックします。
これにより、最初と2番目のreceiveアクティビティが1つの相関グループにまとめられます。
プロパティ・エイリアスを使用すると、グローバル・プロパティを特定のメッセージ・パートのフィールドにマップできます。このアクションにより、プロパティ名を、メッセージのパートと場所を表すエイリアスにできます。このエイリアスは、XPath式で使用できます。
NameCorr相関セットに次の2つのプロパティ・エイリアスを作成します。
NameCorrをreceiveFirst receiveアクティビティのLoanApplメッセージ・タイプ・パートにマップします。このreceiveアクティビティをFirstReceiveパートナ・リンク(FirstReceive.wsdlファイルで定義)と関連付けます。
NameCorrをreceiveSecond receiveアクティビティの受信メッセージ・タイプ・パートLoanAppResponseにマップします。このreceiveアクティビティをSecondReceiveパートナ・リンク(SecondFileRead.wsdlファイルで定義)と関連付けます。
NameCorrのプロパティ・エイリアスを作成する手順は、次のとおりです。
Oracle JDeveloperの「構造」ウィンドウで、「プロパティ・エイリアス」を右クリックします。
「プロパティ・エイリアスの作成」を選択します。
「プロパティ」リストから「NameCorr」を選択します。
「メッセージ・タイプ」→「パートナ・リンク」→「FirstReceive」→「FirstReceive.wsdl」→「メッセージ・タイプ」→「LoanAppl_msg」→「Part - LoanAppl」の順に展開して選択します。
「問合せ」フィールドで[Ctrl]キーを押しながら[Space]キーを押して、次のXPath式を定義します。
/ns2:LoanAppl/ns2:Name
「OK」をクリックします。
「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「SecondFileRead.wsdl」→「メッセージ・タイプ」→「LoanAppResponse_msg」→「Part - LoanAppResponse」の順に展開して選択します。
「問合せ」フィールドで[Ctrl]キーを押しながら[Space]キーを押して、次のXPath式を定義します。
/ns4:LoanAppResponse/ns4:APR
「OK」をクリックします。
IDCorr相関セットに次の2つのプロパティ・エイリアスを作成します。
IDCorrをreceiveSecond receiveアクティビティのLoanAppResponseメッセージ・タイプ・パートにマップします。このreceiveアクティビティをSecondReceiveパートナ・リンク(SecondFileRead.wsdlファイルで定義)と関連付けます。
IDCorrをreceiveThird receiveアクティビティのCustResponseメッセージ・タイプ・パートにマップします。このreceiveアクティビティをThirdReceiveパートナ・リンク(ThirdFileRead.wsdlファイルで定義)と関連付けます。
IDCorrのプロパティ・エイリアスを作成する手順は、次のとおりです。
「構造」ウィンドウで、「プロパティ・エイリアス」を右クリックします。
「プロパティ・エイリアスの作成」を選択します。
「プロパティ」リストから「IDCorr」を選択します。
「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「SecondFileRead.wsdl」→「メッセージ・タイプ」→「LoanAppResponse_msg」→「Part - LoanAppResponse」の順に展開して選択します。
「問合せ」フィールドで[Ctrl]キーを押しながら[Space]キーを押して、次のXPath式を定義します。
/ns4:LoanAppResponse/ns4:APR
「OK」をクリックします。
「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「ThirdFileRead.wsdl」→「メッセージ・タイプ」→「CustResponse_msg」→「Part - CustResponse」の順に展開して選択します。
「問合せ」フィールドで[Ctrl]キーを押しながら[Space]キーを押して、次のXPath式を定義します。
/ns6:CustResponse/ns6:APR
これで、設計は完了します。
「OK」をクリックします。
WSDLファイルのコンテンツを確認する手順は、次のとおりです。
「アプリケーション・ナビゲータ」を更新する場合
相関セット・プロパティのNameCorr
とIDCorr
は、「アプリケーション・ナビゲータ」では、MyCorrelationSet_Properties.wsd
l
ファイルに定義されています。例9-1に例を示します。
例9-1 相関セット・プロパティ
<definitions name="properties" targetNamespace="http://xmlns.oracle.com/MyCorrelationSet/correlationset" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <bpws:property name="NameCorr" type="xsd:string"/> <bpws:property name="IDCorr" type="xsd:double"/> </definitions>
例9-2に示すように、プロパティ・エイリアスはMyCorrelationSet.wsdl
ファイルに定義されています。
例9-2 プロパティ・エイリアス
<bpws:propertyAlias propertyName="ns1:NameCorr" messageType="ns3:LoanAppl_msg" part="LoanAppl" query="/ns2:LoanAppl/ns2:Name"/> <bpws:propertyAlias propertyName="ns1:NameCorr" messageType="ns5:LoanAppResponse_msg" part="LoanAppResponse" query="/ns4:LoanAppResponse/ns4:APR"/> <bpws:propertyAlias propertyName="ns1:IDCorr" messageType="ns5:LoanAppResponse_msg" part="LoanAppResponse" query="/ns4:LoanAppResponse/ns4:APR"/> <bpws:propertyAlias propertyName="ns1:IDCorr" messageType="ns7:CustResponse_msg" part="CustResponse" query="/ns6:CustResponse/ns6:APR"/>
この例では、BPELプロセス・サービス・コンポーネントはWebサービス・プロバイダとしては作成されていないので、MyCorrelationSet.wsdl
ファイルはBPELプロセス・サービス・コンポーネントでは参照されません。このため、旧WSDLに定義されている相関セットを参照するには、MyCorrelationSet.wsdl
ファイルをFirstReceive.wsdl
ファイル内にインポートする必要があります。例9-3に例を示します。
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プロセス
前述のパートの要素タイプに基づいて定義されているプロパティ・エイリアス
各パートに対して定義されたfromPart
を持つfromParts
要素を使用するインバウンド・メッセージ・アクティビティ(IMA) (receiveアクティビティ、scopeまたはpickアクティビティのonMessageブランチ、BPEL 2.0のscopeアクティビティのonEventブランチなど)を持つプロセスの場合、ランタイム環境でプロパティ・エイリアスが適用されるパートを判断できないため、相関を定義できません。
toParts
要素およびfromParts
要素を使用してWSDLメッセージ・パートをマッピングする方法の詳細は、第6.17項「BPEL 2.0でのWSDLメッセージ・パートのマップ」を参照してください。
Oracle BPEL Process Managerでは、メッセージ集約機能がサポートされています。複数のメッセージが同じプロセス/パートナ・リンク/操作名にルーティングされる場合、最初のメッセージは新規インスタンスを作成するためにルーティングされ、後続のメッセージは中間プロセスのreceiveアクティビティを使用して作成されたインスタンスを続行するためにルーティングできます。
メッセージ集約を使用すると、同じ操作(またはイベント名)をreceiveアクティビティのエントリおよび中間プロセスのreceiveアクティビティで使用できます。
注意:
|
reenableAggregationOnComplete
プロパティを使用して、メッセージをルーティングするために作成して使用するインスタンス数を制御できます。
BPELプロセス・インスタンス作成を構成する手順は、次のとおりです。
SOAコンポジット・エディタで、図9-2に示すように、BPELプロセス・サービス・コンポーネントを選択します。
Oracle JDeveloperの右下の隅にある「プロパティ・インスペクタ」に移動します。「プロパティ・インスペクタ」が表示されない場合は、「表示」メイン・メニューから「プロパティ・インスペクタ」を選択します。
図9-3に示すように、「プロパティ」セクションで「追加」アイコンをクリックします。
「プロパティの作成」ダイアログが表示されます。
「名前」フィールドで、bpel.config.reenableAggregationOnComplete
デプロイメント・ディスクリプタのプロパティを入力します。このタイプのデプロイメント・ディスクリプタには、接頭辞bpel.config
が必要です。
「値」フィールドで、表9-8の説明に従ってtrue
と入力します。
表9-8 reenableAggregationOnCompleteプロパティ設定
値 | 説明 | 例 |
---|---|---|
|
メッセージを処理する新規インスタンスが作成されます。ただし、メッセージの受信からインスタンスの完了までの間に、1つのウィンドウが表示されます。これにより、メッセージが |
|
|
デフォルトの動作です。この設定により、集約機能が無効化されます。作成されるインスタンスは1つのみです。インスタンスによって処理されないメッセージは、 |
同じ相関セットを使用する複数のメッセージを1つのBPELインスタンスにルーティングしないようにしてください。 |
図9-4は、完成した「プロパティの作成」ダイアログを示しています。
「OK」をクリックします。
例9-4は、composite.xml
ファイルにおけるbpel.config
接頭辞を含むreenableAggregationOnComplete
プロパティを示しています。
例9-4 composite.xmlファイルのreenableAggregationOnCompleteプロパティ
<composite name="Aggregation" revision="1.0" label="2011-07-10_13-52-24_174" mode="active" state="on"> . . . . . . <component name="Aggregation" version="1.1"> <implementation.bpel src="Aggregation.bpel"/> <property name="bpel.config.reenableAggregationOnComplete" type="xs:string" many="false" override="may">true</property> </component> . . . . . . </composite>
例9-5に示すように、相関セットを作成します。Oracle BPEL Process Managerに対するすべてのメッセージは、同じ操作名にルーティングされます。メッセージの相関IDは同じとなります。インタフェースWSDLでは、アクティビティのエントリ(receiveInput
)と中間プロセスのreceiveアクティビティ(Continue_Receive
)が区別されません。すべてのメッセージはinitiate
操作を使用して処理されます。すべてのメッセージをルーティングするシングル・インスタンスが作成されます。
このことは、同じパートナ・リンクについて異なる操作名を定義する必要があった11g リリース1 11.1.1.6より前のリリースとは異なります。プロセスで2つの操作を公開する必要があり、コール元で適切な操作名を選択する必要がありました。
例9-5 receiveアクティビティのエントリと中間プロセスのreceiveアクティビティにおける同じ操作の相関
<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 Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
相関セットを使用したBPELプロセスでは、適切なルーティングが実行されます。メッセージは次のいずれかとなる可能性があります。
新しいインスタンスを作成する起動メッセージ
既存のインスタンスを続行するコールバック・メッセージ
図9-5に、同じ操作(process
)を使用したreceiveアクティビティのエントリと中間プロセスのreceiveアクティビティを示します。
例9-6に、同じ操作(process
)を使用したreceiveアクティビティのエントリと中間プロセスのreceiveアクティビティの例を示します。
例9-6 新規インスタンスまたは既存インスタンスへの新規メッセージのルーティング
<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>
例9-6の初期のシナリオでは、次のアクションがBPELプロセスP1で発生します。
パートナによって、4つのメッセージ(メッセージ1、メッセージ2、メッセージ3およびメッセージ4)が同じパートナ(相関ID 101
)に対して提供されます。
メッセージ1によって、BPELプロセスP1の新しいインスタンスが作成されます。このメッセージは起動メッセージとしてマークされます。
メッセージ2、3および4は、Continue_Receive
アクティビティを使用して受信されます。これらのメッセージはコールバック・メッセージとしてマークされます。
while
ループが3回反復されることが想定されるため、インスタンスが閉じます。
ここで、追加メッセージがルーティングされ、これにより、競合状態が発生する可能性があると想定します。表9-9に詳細を示します。
表9-9 メッセージ配信シナリオ