12 BPELプロセスでのフォルト処理の使用

この章では、BPELプロセスのフォルト処理について説明します。BPELプロセス・サービス・コンポーネントでは、フォルト処理を使用して、Webサービス外部から返されたエラー・メッセージやその他の例外を処理し、ビジネス・フォルトまたは実行時フォルトに応じてエラー・メッセージを生成できます。この章では、フォルト管理フレームワークを使用して、フォルトを捕捉したり、フォルト・ポリシー・ファイルに定義されているユーザー指定のアクションを実行する方法についても説明します。

この章の内容は次のとおりです。

• フォルト・ハンドラの概要

• BPEL標準フォルトの概要

• BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要

• フォルト管理フレームワークによるフォルト処理

• BPEL実行時フォルトの捕捉

• getFaultAsString XPath式関数によるフォルト詳細の取得

• throwアクティビティによる内部フォルトのスロー

• rethrowアクティビティによるフォルトの再スロー

• 外部フォルトを返す

• 「scopeアクティビティによるアクティビティ・グループの管理」

• replayアクティビティによるscopeアクティビティ内でのアクティビティの再実行

• 一連の操作を元に戻した後の補正の使用

• terminateアクティビティまたはexitアクティビティによるビジネス・プロセス・インスタンスの停止

• アサーション条件によるフォルトのスロー

• 再試行可能とのSOAPフォルトの分類

12.1 フォルト・ハンドラの概要

フォルト・ハンドラは、通常予想される以外のデータ(数値のかわりにエラー・メッセージなど)がターゲット・サービスから返されたときに、BPELプロセス・サービス・コンポーネントの対応方法を定義します。フォルト・ハンドラの例として、Webサービスで通常返される信用格付けの数値のかわりに、ネガティブ情報メッセージが返された場合を想定します。

図12-1は、フォルト・ハンドラが信用格付け変数を-1000に設定する方法の例を示しています。

図12-1 フォルト処理

「図12-1 フォルト処理」の説明

次の例のコード・セグメントは、この操作のフォルト・ハンドラをBPELファイルに定義します。

<faultHandlers>
     <catch faultName="services:NegativeCredit" faultVariable="crError">
      <assign name="crin">
         <copy>
           <from expression="-1000">
           </from>
           <to variable="input" part="payload"
               query="/autoloan:loanApplication/autoloan:creditRating"/>
         </copy>
       </assign>
     </catch>
</faultHandlers>

faultHandlersタグには、フォルト処理コードが入ります。フォルト・ハンドラ内のcatchアクティビティによって、フォルト名と変数、およびcreditRating変数を「-1000」に設定するコピー指示が定義されます。

BPELプロセス・サービス・コンポーネントに対してWebサービスを選択する際、返される可能性があるフォルトを特定し、それぞれに対してフォルト・ハンドラを設定します。

12.2 BPEL標準フォルトの概要

この項では、BPEL 1.1およびBPEL 2.0の標準フォルトを識別します。

12.2.1 BPEL 1.1の標準フォルト

この項では、BPEL 1.1の標準フォルトを識別します。特に指定がないかぎり、「Business Process Execution Language for Web Services Specification」はhttp://schemas.xmlsoap.org/ws/2003/03/business-process/のネームスペースで次の標準フォルトを定義します。

• bindingFault (http://schemas.oracle.com/bpel/extensionで定義されているBPEL拡張フォルト)

• conflictingReceive

• conflictingRequest

• correlationViolation

• forcedTermination

• invalidReply

• joinFailure

• mismatchedAssignmentFailure

• remoteFault (http://schemas.oracle.com/bpel/extensionで定義されているBPEL拡張フォルト)

• repeatedCompensation

• selectionFailure

• uninitializedVariable

• assertFailure

• coordinationFault

• entityInternalNestedError

• maxLoopCountExceeded

• owsmPolicyFault

• rollback

• timeout

標準フォルトの定義は、次のとおりです。

• タイプなし。つまり、messageTypesは関連付けられていません。

• Web Services Description Language (WSDL)メッセージには関連付けられていません。

• 次のようにフォルト変数なしで捕捉されます。

  <catch faultName="bpws:selectionFailure">

12.2.2 BPEL 2.0の標準フォルト

次のリストは、WS-BPEL仕様内で定義されている標準フォルトを指定します。標準フォルト名はすべて、標準のWS-BPELネームスペースで修飾されます。

• ambiguousReceive

• completionConditionFailure

• conflictingReceive

• conflictingRequest

• correlationViolation

• invalidBranchCondition

• invalidExpressionValue

• invalidVariables

• joinFailure

• mismatchedAssignmentFailure

• missingReply

• missingRequest

• scopeInitializationFailure

• selectionFailure

• subLanguageExecutionFault

• uninitializedPartnerRole

• uninitializedVariable

• unsupportedReference

• xsltInvalidSource

• xsltStylesheetNotFound

12.2.2.1 BPEL 2.0でのフォルト処理の優先順位

BPEL 2.0の場合、関連するデータなしでスローされたフォルトを捕捉するための優先順位は次のとおりです。

• 一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。

• catchAllアクティビティがある場合、フォルトはcatchAllフォルト・ハンドラに送信されます。

• それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。

BPEL 2.0の場合、関連するデータとともにスローされたフォルトを捕捉するための優先順位は次のとおりです。

• 一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。

• フォルト・データが、次のものを含むWSDLメッセージ・タイプの場合:

  • メッセージには、要素で定義された単一パーツが含まれます。

  • 一致するfaultName値を持つcatchアクティビティであり、その値にはfaultVariableがあり、これに関連付けられているfaultElement QNameは、単一のWSDLメッセージ・パーツの実行時要素データのQNameと一致します。

  その後フォルトは、単一パーツの要素の値に初期化されたfaultVariableを持つ、識別されたcatchアクティビティに送信されます。

• 一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。この場合、フォルト値はフォルト・ハンドラ内からは使用できませんが、rethrowアクティビティで使用できます。

• faultName属性がないcatchコンストラクトがあり、そのfaultName属性に、タイプが実行時フォルト・データのタイプと一致するfaultVariableがある場合、フォルトは識別されたcatchアクティビティに送信されます。

• フォルト・データが、メッセージに要素で定義された単一パーツが含まれるWSDLメッセージ・タイプで、faultVariableを持つfaultName属性がないcatchアクティビティが存在し、そのfaultVariableの関連するfaultElementのQNameが単一のWSDLメッセージ・パーツの実行時要素データのQNameと一致する場合、フォルトは、単一パーツの要素の値に初期化されたfaultVariableを持つ、識別されたcatchアクティビティに送信されます。

• catchAllアクティビティがある場合、フォルトはcatchAllフォルト・ハンドラに送信されます。

• それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。

12.3 BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要

BPELフォルトには、Qnameというフォルト名(ネームスペースで修飾された名前)と、可能性のあるmessageTypeがあります。BPELフォルトには次の2つのカテゴリがあります。

• ビジネス・フォルト

• 実行時フォルト

12.3.1 ビジネス・フォルト

ビジネス・フォルトはアプリケーション固有のフォルトであり、処理されている情報に問題がある場合(社会保障番号がデータベース内で見つからない場合など)に生成されます。ビジネス・フォルトは、アプリケーションがthrowアクティビティを実行したとき、またはinvokeアクティビティがレスポンスとしてフォルトを受け取った場合に発生します。ビジネス・フォルトのフォルト名はBPELプロセス・サービス・コンポーネントによって指定されます。該当する場合は、messageTypeが、WSDLファイルで定義されます。ビジネス・フォルトは、faultNameおよびfaultVariableを使用してfaultHandlerで捕捉できます。

<catch faultName="ns1:faultName" faultVariable="varName">

12.3.2 実行時フォルト

実行時フォルトは、BPELプロセス・サービス・コンポーネントまたはWebサービスの実行中に問題(変数名が正しくないためにデータを正しくコピーできないなど)が発生した結果です。この種のフォルトはユーザー定義ではなく、システムによりスローされます。それらは、次に示すような様々な理由で生成されます。

• プロセスによって、値の不適切な使用が試行される。

• 論理エラーが発生する(無限ループなど)。

• SOAPコールでSimple Object Access Protocol (SOAP)フォルトが発生する。

• サーバーによって例外がスローされる。

様々な実行時フォルトが自動的に提供されています。これらのフォルトは、http://schemas.oracle.com/bpel/extensionネームスペースにあります。また、messageType RuntimeFaultMessageに関連付けられています。次の例に示すように、messageTypeはWSDLファイルに定義されます。

<?xml version="1.0" encoding="UTF-8" ?> 
<definitions name="RuntimeFault"
  targetNamespace="http://schemas.oracle.com/bpel/extension"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.xmlsoap.org/wsdl/">

  <message name="RuntimeFaultMessage">
   <part name="code" type="xsd:string" /> 
   <part name="summary" type="xsd:string" /> 
   <part name="detail" type="xsd:string" /> 
  </message>
</definitions>

フォルトの捕捉時に(messageType RuntimeFaultMessageの)faultVariableが使用される場合は、faultVariableからフォルト・サマリーおよび詳細とともにフォルト・コードを問合せできます。

12.3.2.1 bindingFault

bindingFaultは、起動準備に失敗した場合にアクティビティ内でスローされます。たとえば、プロセスのWSDLのロードに失敗した場合などです。bindingFaultは再試行不可です。通常、このタイプのフォルトは管理者操作により修正する必要があります。

12.3.2.2 remoteFault

remoteFaultもアクティビティ内でスローされます。スローの原因は、起動の失敗です。たとえば、リモート・サービスからSOAPフォルトが返されます。

12.3.2.3 replayFault

replayFaultは、スコープ内のアクティビティを再実行します。このフォルトは、スコープ内のいずれかの時点でスコープへと移行されます。このフォルトは共通フォルトには移入されませんが、BPELに対してスコープの再実行の指標になります。その後、サーバーによりスコープが最初から再実行されます。

12.3.3 同期BPELプロセスでのフォルト処理の追加および伝播方法

この項では、同期BPELプロセスでのフォルト処理の追加および伝播方法について説明します。設計中に、次のタスクを実行します。

• 既存のスキーマおよびWSDLファイルを変更し、フォルト要素、フォルト・メッセージおよびフォルト操作の詳細を含めます。

• BPELプロセスにフォルト処理を追加します(具体的にはcatchアクティビティ)。

• WSDLファイルに指定したフォルト・メッセージ・タイプでフォルト変数を作成します。

• assignおよびreplyアクティビティを、追加のフォルト処理詳細とともに追加します。

12.3.3.1 スキーマおよびWSDLファイルの編集

スキーマおよびWSDLファイルを編集するには:

1. 「BPELプロセスの作成」ダイアログでデフォルト設定を使用して同期BPELプロセス(この例では、TestProcessという名前)を作成します。
2. 「アプリケーション」ウィンドウの「スキーマ」フォルダで、「TestProcess.xsd」ファイルをダブルクリックします。
3. 「ソース」ビューをクリックし、processFaultという新しい要素を追加します。

   <element name="processFault">
        <complexType>
            <sequence>
                 <element name="result" type="string"/>
            </sequence>
        </complexType>
   </element>
   

4. 「アプリケーション」ウィンドウで、「WSDL」フォルダを開きます。
5. 「TestProcess.wsdl」ファイルをダブルクリックします。
6. 「ソース」ビューをクリックし、TestProcessFaultMessageという新しいメッセージ・タイプを追加します。

   <wsdl:message name="TestProcessFaultMessage">
        <wsdl:part name="payload" element="client:processFault"/>
   </wsdl:message>
   

7. WSDLファイルでoperation要素を編集し、フォルトを追加します。

   <wsdl:operation name="process">
         <wsdl:input  message="client:TestProcessRequestMessage" />
         <wsdl:output message="client:TestProcessResponseMessage"/>
         <wsdl:fault name="FaultResponse" message=" 
          client:TestProcessFaultMessage"/>
   </wsdl:operation>
   

8. 「File」メニューから、「Save」を選択します。

12.3.3.2 フォルト・ハンドラの追加

フォルト・ハンドラを追加するには:

1. 「アプリケーション」ウィンドウで、「SOA」→「BPEL」の順に開きます。
2. 「TestProcess.bpel」をダブルクリックします。
3. BPELプロセスで「Catchの追加」アイコンをクリックし、そのBPELプロセスのフォルト・ハンドラとしてcatchアクティビティを追加します。CatchAllアクティビティを使用することもできます。図12-2に詳細を示します。

   図12-2 「Catchの追加」アイコン

   
   「図12-2 「Catchの追加」アイコン」の説明
4. catchアクティビティをダブルクリックし、システム・フォルトを指定します。図12-3に詳細を示します。

   図12-3 catchアクティビティ

   
   「図12-3 catchアクティビティ」の説明

   このシステム・フォルトをトリガーするassertアクティビティはありません。このアクティビティを追加して、入力フィールドをアサートできます。

5. 「ネームスペースURI」フィールドで、「参照」アイコンをクリックします。

   「フォルト・チューザ」ダイアログが表示されます。

6. システム・フォルト(この例では、assertFailure)を選択し、「OK」をクリックします。選択可能なシステム・フォルトが他にも多数あります。図12-4に詳細を示します。

   図12-4 「フォルト・チューザ」ダイアログ

   
   「図12-4 「フォルト・チューザ」ダイアログ」の説明

   catchの編集ダイアログに戻ります。

7. 「フォルト変数」フィールドで、「変数の作成」アイコンをクリックします。

   「変数の作成」ダイアログが表示されます。

   FaultVarの名前およびRuntimeFaultMessageタイプの変数が作成されます。図12-5に詳細を示します。

   図12-5 「変数の作成」ダイアログ

   
   「図12-5 「変数の作成」ダイアログ」の説明
8. RuntimeFault.wsdlファイルを「SOA」→「WSDL」フォルダにコピーします。これは、BPELプロセスWSDLファイルと同じ場所です。
9. 「OK」をクリックし、「Catchの編集」ダイアログで「OK」をクリックします。

12.3.3.3 フォルト・レスポンス変数の作成

フォルト・レスポンス変数を作成するには:

1. 「構造」ウィンドウで、「変数」フォルダを右クリックし、「変数の作成」を選択します。
2. 「名前」フィールドで、Faultresponseと入力します。
3. 「メッセージ・タイプ」を選択します。
4. 「メッセージ・タイプ」フィールドの「参照」アイコンをクリックします。
5. 「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「TestProcess.wsdl」→「メッセージ・タイプ」→「TestProcessFaultMessage」の順に開き、「OK」をクリックします。図12-6に詳細を示します。

   図12-6「タイプ・チューザ」ダイアログ

   
   「図12-6 「タイプ・チューザ」ダイアログ」の説明
6. 「変数の作成」ダイアログで「OK」をクリックします。

12.3.3.4 Catch Activityブランチへのassignアクティビティの追加

Catch Activityブランチにassignアクティビティを追加するには:

1. assignアクティビティを、catchアクティビティ・ブロックにドラッグします。
2. assignアクティビティをダブルクリックします。
3. FaultVar変数のcode、summaryおよびdetailの各フィールドをFaultResponse変数に連結し、「OK」をクリックします。図12-7に詳細を示します。

   図12-7 assignの編集ダイアログ

   
   「図12-7 assignの編集ダイアログ」の説明
4. 「一般」タブの「名前」フィールドで、名前(この例では、FaultDataForClient)を入力します。

12.3.3.5 Catch Activityブランチへのreplyアクティビティの追加

Catch Activityブランチにreplyアクティビティを追加するには:

1. catchアクティビティ・ブロック内のAssignアクティビティの下にあるReplyアクティビティをドラッグします。
2. replyアクティビティをダブルクリックします。
3. 「ネームスペースURI」フィールドで、「参照」アイコンをクリックします。

   「フォルト・チューザ」ダイアログが表示されます。

4. 「プロジェクトのWSDLファイル」→「TestProcess.wsdl」を開き、FaultResponseという名前のフォルトを選択します。図12-8に詳細を示します。

   図12-8 「フォルト・チューザ」ダイアログ

   
   「図12-8 「フォルト・チューザ」ダイアログ」の説明
5. 「名前」フィールドに、名前を入力します(この例ではReplyWithFault)。
6. 「パートナ・リンク」フィールドで、「参照」アイコンをクリックします。

   「パートナ・リンク・チューザ」ダイアログが表示されます。

7. replyOutput replyアクティビティが接続されている同じパートナ・リンクを選択し、「OK」をクリックします。
8. 「変数」フィールドの「参照」アイコンをクリックします。

   「変数チューザ」ダイアログが表示されます。

9. FaultResponse変数を選択し、「OK」をクリックします。

   図12-9 「変数の選択」ダイアログ

   
   「図12-9 「変数の選択」ダイアログ」の説明
10. replyの編集ダイアログで、「OK」をクリックします。

    BPELプロセスは図12-10のようになります。両方のreplyアクティビティが、同じパートナ・リンクに接続されます。

    図12-10 BPELプロセスの設計

    
    「図12-10 BPEL プロセスの設計」の説明

12.4 フォルト管理フレームワークを使用したフォルトの処理

Oracle SOA Suiteには、BPELプロセスのフォルトを処理するために一般的なフォルト管理フレームワークが用意されています。プロセスでinvokeアクティビティの実行時にフォルトが発生すると、そのフォルトはフレームワークによって捕捉され、フォルト・ポリシー・ファイルでそのコンポジットまたはコンポーネントに関連付けられているユーザー指定のアクションが実行されます。フォルト・ポリシーは、invokeアクティビティの結果であるフォルトに適用できます。フォルトは、ターゲット・サービスでのアサート前、アサート後、起動または実際のビジネスでの障害で発生する可能性があります。

管理者操作が規定のアクションである状況でフォルトが発生した場合は、Oracle Enterprise Manager Fusion Middleware Controlからリカバリ・アクションを実行します。フォルト管理フレームワークによって、scopeアクティビティのcatchアクティビティを使用してBPELプロセスを設計するための代替手段が提供されます。

この項では、フォルト管理フレームワークを構成する複数のコンポーネントの概要について説明します。

• フォルト管理フレームワークでは、invokeアクティビティのすべてのフォルト(ビジネスおよび実行時)が捕捉されます。

• フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。フォルト・ポリシー・ファイルでは一連のアクションがIDで識別されます。

• 一連の条件によってアクションが起動されます(フォルト・ポリシーとも呼ばれます)。

• 電子メールまたはJMSにより、条件に関連付けられているエラーをユーザーに通知します。

• フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを次のものに関連付けます。

  • SOAコンポジット・アプリケーション

  • BPELプロセスとOracle Mediatorのサービス・コンポーネント

  • BPELプロセスとOracle Mediatorのサービス・コンポーネントの参照バインディング・コンポーネント

  フォルト管理フレームワークでは、SOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリ、または設定した2つのプロパティで識別されるリモートの場所で、フォルト・ポリシー・バインディングを検索します。リモートの場所はMDSリポジトリ内です。

  ノート:

  フォルト管理フレームワークで構成されるフォルト・ポリシーは、BPELプロセスのscopeアクティビティのcatchアクティビティに定義されるフォルト処理よりも優先されます。フォルト管理フレームワークは、フォルト処理をcatchアクティビティに再スローするように構成できます。

• フォルト・ポリシー・ファイル(fault-policies.xml)およびフォルト・ポリシー・バインディング・ファイル(fault-bindings.xml)は、次のいずれかの場所に格納されます。

  • SOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリ。

  • composite.xmlファイルに追加した2つのプロパティで指定された別の場所。このオプションは、1つのフォルト・ポリシーを複数のSOAコンポジット・アプリケーションで使用する必要がある場合に便利です。このオプションは、composite.xmlファイルと同じディレクトリに格納されているフォルト・ポリシー・ファイルよりも優先されます。次の例は、この2つのプロパティの詳細を示しています。この例では、フォルト・ポリシー・ファイルが、Oracle Metadata Services (MDS)リポジトリの共有領域のSOA部分に配置されます。

    <property
     name="oracle.composite.faultPolicyFile">oramds:/apps/faultpolicyfiles/
     fault-policies.xml
    </property>
    <property
     name="oracle.composite.faultBindingFile">oramds:/apps/faultpolicyfiles/
     fault-bindings.xml
    </property>
    

Oracle Mediatorのフォルト処理機能の詳細は、「エラー処理の使用」を参照してください。

Oracle Business Process Management (BPM) Suiteによるフォルト・ポリシーの作成の詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発の「BPMでのフォルト処理の使用」を参照してください。

12.4.1 フォルト・ポリシー・バインディングによる解決方法の理解

フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーをSOAコンポジット・アプリケーションまたはコンポーネント(サービス・コンポーネントまたは参照バインディング・コンポーネント)に関連付けます。フォルト管理フレームワークでは、次の順序でフォルト・ポリシー・バインディングの識別が試みられます。

• composite.xmlファイルに定義されている参照バインディング・コンポーネント。

• composite.xmlファイルに定義されているBPELプロセスまたはOracle Mediatorのサービス・コンポーネント。

• composite.xmlファイルに定義されているSOAコンポジット・アプリケーション。

解決する過程で条件に適したアクションが見つからない場合、フォルト管理フレームワークでは、その解決は失敗とみなされ、次の解決レベルに移動します。

たとえば、invokeアクティビティがfaultname="abc"で失敗となった場合を考えてみます。fault-bindings.xmlファイルには、次のポリシー・バインディングが指定されているとします。

• policy-id-1へのSOAコンポジット・アプリケーションのバインド

• policy-id-2へのBPELプロセス/Oracle Mediatorサービス・コンポジットまたは参照バインディング・コンポーネントのバインド

また、fault-bindings.xmlファイルには、次のバインディングも指定されているとします。

• policy-id-3へのSOAコンポジット・アプリケーションのバインド

• policy-id-4への参照バインディング・コンポーネントまたはサービス・コンポーネントのバインド

フォルト管理フレームワークは、次のように動作します。

• 最初に、解決バインディング(この場合はpolicy-id-4)と照合します。

• フォルトの解決に失敗した場合は、可能な次の照合(policy-id-2との照合)に進みます。

• フォルトの解決に失敗した場合は、可能な次の照合(policy-id-3との照合)に進みます。

• フォルトの解決に失敗した場合は、可能な次の照合(この場合はpolicy-id-1との照合)に進みます。

• フォルトが解決していない場合、そのフォルトはBPELフォルトcatchアクティビティに送信されます。

12.4.2 自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法

フォルト・ポリシーをフォルト・ポリシー・ウィザードで設計し、フォルト・ポリシーをフォルト・ポリシー・バインディング・ファイルに関連付けることができます。

自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計するには:

1. Oracle JDeveloperのメイン・メニューから、「ファイル」→「新規」→「ギャラリから」を選択します。
2. 「カテゴリ」リストで、「SOA層」→「フォルト」を選択します。
3. 「項目」リストで、「フォルト・ポリシー・ドキュメント」を選択します。

   表12-11に示すようなフォルト・ポリシー・エディタが表示されます。policy1の名前で単一のフォルト・ポリシーが、構成用に最初に表示されます。

   図12-11 初期表示のフォルト・ポリシー・エディタ

   
   「図12-11 初期表示のフォルト・ポリシー・エディタ」の説明

   フォルト・ポリシー・エディタには複数のセクションおよびタブがあります。フォルト・ポリシー・エディタは、次の順序で構成することをお薦めします。

   • 「プロパティ」タブ

   • 「アラート」タブ

   • 「アクション」タブ

   • フォルト・ポリシー名およびフォルト・ハンドラ

   • フォルト・ポリシー・バインディング・ファイルとの関連付け

12.4.2.1 ステップ1: プロパティ・セットの定義

最初に、プロパティ・セットを定義して「ステップ2: アラートの定義」で定義されるJMSアラートと関連付けます。JMS宛先やコネクション・ファクトリなどのプロパティ・セットの構成詳細を複数のJMSアラートと関連付けることができます。たとえば、JMSアラートの場合、宛先、キュー情報およびコネクション・ファクトリは、フォルト・ポリシーに構成された追加のJMSアラートによる参照が可能です。

ノート:

このリリースでは、電子メールアラートに対してプロパティ・セットを作成できません。

1. 「プロパティ」タブをクリックします。表12-1に使用可能なフィールドの詳細を示します。

   表12-1 プロパティ・セットの選択

   説明	結果
   電子メール・アラート	電子メール・アラートでは、このリリースのプロパティ・セットはサポートされていません。
   JMSキュー・アラート	「追加」をクリックして、JMSアラートに対するプロパティおよび値を指定します。次のプロパティおよび関連付けられた値は必須です。 jmsDestination: 構成されたキューまたはトピックのJNDI名で、ここでアラートがキューまたはパブリッシュされます。 connectionFactory: 使用する構成済コネクション・ファクトリのJNDI名。

   図12-12に、JMS宛先およびコネクション・ファクトリ値で構成されたプロパティ・セットを示します。

   図12-12 JMSプロパティ・セットの構成

   
   「図12-12 JMSプロパティ・セットの構成」の説明

   定義済JMS propertySetセクションを含む、完全に定義されたフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」のステップ4を参照してください。

12.4.2.2 ステップ2: アラートの定義

1. 「アラート」タブをクリックします。次の2種類の通知アラートがサポートされています。

   • 電子メール: 電子メール受信者を構成して、フォルト発生時にアラートを受信できます。また、同じ電子メール受信者をOracle Enterprise Manager Fusion Middleware Controlの「ワークフロー通知プロパティ」ページの「メーラー」タブに構成する必要があります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフロー通知プロパティの構成に関する項を参照してください。

   • JMS: フォルトをJMSキューにエンキューするか、JMSトピックにパブリッシュできます。JMSヘッダー値も指定できます。JMS通知は、フォルトを処理するためにサードパーティの解決システムと統合できます。サードパーティの解決システムは、ターゲットのキューおよびトピックにデキューおよびサブスクライブします。ヘッダーのプロパティ値に基づいて利用することで、より詳細にメッセージを利用できます。JMSメッセージのペイロード・タイプは、XMLフォーマットのテキスト・メッセージです。さらに、JMSキューとトピックおよびコネクション・ファクトリをOracle WebLogic Server管理コンソールで構成する必要があります。詳細は、『Oracle WebLogic Server JMSリソースの管理』の基本JMSシステム・リソースの構成に関する項を参照してください。

2. 「追加」アイコンをクリックします。表12-2に詳細を示します。

   表12-2 アラートの選択

   選択	結果
   電子メール	フォルト発生時に電子メール・アラートを受信する受信者を指定できます。 「ID」フィールドで、IDを指定するか、デフォルト値をそのまま使用します。 「宛先」および「Cc」フィールドで、電子メール受信者を指定します。 ノート: 「プロパティ・セット」リストからプロパティ・セットを選択しないでください。電子メール・アラートでは、このリリースのプロパティ・セットはサポートされていません。 完了後に、「OK」をクリックします。
   JMS	フォルト発生時にJMSアラートを受信するキューを指定できます。 JMSアラートの構成には次の2つのプロパティが必要です。 jmsDestination: 構成されたキューまたはトピックのJNDI名で、ここでアラートがキューおよびパブリッシュされます。 connectionFactory: 使用する構成済コネクション・ファクトリのJNDI名。 「ID」フィールドで、IDを指定するか、デフォルト値をそのまま使用します。 「プロパティ・セット」リストで、「ステップ1: プロパティ・セットの定義」で作成した既存のプロパティ・セットを選択するか、「必須プロパティの作成」をクリックして、jmsDestinationおよびconnectionFactoryに定義されている値を使用して新しいプロパティ・セットを作成します。 「ヘッダー」表で、必要に応じてJMSヘッダー値を指定して、詳細なフォルト利用を実現します。標準およびカスタムの外部システムはどちらも、構成されたヘッダー・プロパティに基づいて、サブスクリプションをフィルタできます。 完了後に、「OK」をクリックします。

   図12-13に、「電子メールのプロパティ」ダイアログでの電子メール・アラートの構成を示します。

   図12-13 電子メール・アラートの構成

   
   「図12-13 電子メール・アラートの構成」の説明

   図12-14に、「JMSのプロパティ」ダイアログでのJMSアラートの構成を示します。この例では、プロパティ・セット(「必須プロパティの作成」をクリックすることで起動される「プロパティ・セット」ダイアログで定義)とヘッダーの両方が定義されています。

   図12-14 JMSアラートの構成

   
   「図12-14 JMSアラートの構成」の説明

   定義済「アラート」セクションを含む、完全に定義されたフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」のステップ4を参照してください。

12.4.2.3 ステップ3: アクションの定義

1. 「アクション」タブをクリックします。デフォルトでは、アクションのすべてのタイプが自動的に選択されています。図12-15に詳細を示します。

   図12-15 フォルト・ポリシー・エディタの「アクション」セクション

   
   「図12-15 フォルト・ポリシー・エディタの「アクション」セクション」の説明

   表12-3に、使用可能なアクション・タイプを示します。

   表12-3 サポートされているアクション・タイプ

   アクション	説明
   中断	ビジネス・フロー全体を終了します。
   管理者操作	現在のアクティビティの処理が停止します。フォルトを処理するためには、Oracle Enterprise Manager Fusion Middleware Controlから管理者操作を行う必要があります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・フロー・インスタンスでのフォルトのリカバリに関する項を参照してください。
   Javaアクション:	外部Javaクラスを実行できます。詳細は、「Javaアクション・フォルト・ポリシーの使用方法」を参照してください。
   スコープの再実行	再実行フォルトが発生します。
   フォルトの再スロー	BPELフォルト・ハンドラ(scopeアクティビティ内のcatchアクティビティ)にフォルトが送信されます。使用可能なハンドラがない場合、そのフォルトは上部に報告されます。
   エンキュー	適切なコンテキストとペイロードとともに、JMSメッセージとしてJMSキューに拒否メッセージをエンキューします。構成の詳細は、『テクノロジ・アダプタの理解』のJMSキューに関する項を参照してください。
   WSの起動:	Webサービスを呼び出すことで、拒否メッセージを処理します。構成の詳細は、『テクノロジ・アダプタの理解』のWebサービス・ハンドラに関する項を参照してください。
   ファイル・アクション	拒否メッセージをファイルに格納することによって、メッセージのエラー・ハンドラを作成します。構成の詳細は、『テクノロジ・アダプタの理解』のファイルに関する項を参照してください。
   再試行	アクティビティを再試行するために、次のオプションが用意されています。 指定回数の再試行。 再試行から次の再試行までの遅延(秒単位)の指定。 指数バックオフによる再試行間隔の増加。 N回の再試行が失敗となった場合の再試行失敗時アクションへのチェーン。 再試行の詳細は、表12-6を参照してください。

   定義済「アクション」セクションでのフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」のステップ4を参照してください。

12.4.2.4 ステップ4: フォルト名およびポリシーの定義

1. フォルト・ポリシー・エディタの上部セクションで、フォルト・ポリシーのフォルト名、説明およびデフォルト・アクションを定義します。表12-4に詳細を示します。

   表12-4 フォルト・ポリシー・エディタ - 上部のセクション

   要素	説明
   「フォルト・ポリシーの追加」アイコン(左上隅)	また、さらに別のフォルト・ポリシーを構成用に単一ポリシー・ドキュメントに追加できます。 「追加」アイコンを左上隅でクリックし、さらに別のフォルト・ポリシーを追加します。フォルト・ポリシー・エディタの左端にある列にすべてのポリシーが表示されます。定義するポリシーをクリックできます。
   フォルト・ポリシーの削除	選択したフォルト・ポリシーを削除します。
   フォルト・ポリシー	フォルト・ポリシーの名前を入力するか、policynumberのデフォルト名をそのまま使用します。
   「フォルトの追加」アイコン(右上隅)	クリックしてフォルトを追加します。
   フォルトの削除	クリックしてフォルトを削除します。
   フォルト名	捕捉するフォルトの標準タイプを選択します。このリストには、選択可能なシステム・フォルト(バインディング、Oracle Mediatorまたはリモート)またはサービス(ビジネス)・フォルトが表示されます。
   説明	説明を入力します(オプション)。説明は実行時に監査証跡に維持されます。
   デフォルト・アクション	このセクションでは、次のタスクを実行します。 リストから、このフォルト発生時に実行するデフォルト・アクション(たとえば、中断、再スロー、再試行など)を選択します。選択可能なアクションは、「ステップ3: アクションの定義」で保持または削除したアクションに基づいています。 または 「追加」アイコンをクリックし、if-then条件をフォルト・ポリシーに追加します。この選択では「If」、「Then」および「Default」のフィールドが表示されます。 たとえば、条件を「If」フィールド(デフォルトは「true」)を指定すると、起動するアクション(たとえば、管理者操作)を「Then」フィールドで選択できます。条件が「true」でない場合、発生するデフォルト・アクション(たとえば、「中断」)を「Default」フィールドで選択できます。 「If」フィールドで、条件を入力するか、「式ビルダー」アイコンをクリックしてXPath式条件を構築します。 「Then」フィールドで、「If」フィールドの条件がtrueに評価される場合に起動される条件を指定します。 「デフォルト」フィールドで、「If」フィールドの条件がfalseに評価される場合に起動される条件を指定します。 「追加」アイコンの左にある「アラート」アイコンをクリックし、条件発生時に送信するアラートのタイプを選択します。選択可能なアラート・タイプが、このダイアログの「アラート」タブに表示されます。複数のアラートを条件で指定できます。

   完了すると、フォルト・ポリシー・エディタは図12-16のようになります。

   図12-16 フォルト名、説明およびデフォルト・アクションが定義されたフォルト・ポリシー・エディタ

   
   「図12-16 フォルト名、説明およびデフォルト・アクションが定義されたフォルト・ポリシー・エディタ」の説明

2. SOAコンポジット・エディタの上で、フォルト・ポリシーのファイルを閉じ、変更の保存を促すプロンプトが表示された際、「はい」をクリックします。図12-17に詳細を示します。

   図12-17 フォルト・ポリシー変更の保存

   
   「図12-17 フォルト・ポリシー変更の保存」の説明

   これでポリシー構成が完了しました。フォルト・ポリシー・バインディングにフォルト・ポリシーを関連付ける準備ができています。

12.4.2.5 ステップ5: フォルト・ポリシーに対するフォルト・ポリシー・バインディングの定義

フォルト・ポリシー・ウィザードでフォルト・ポリシーを設計した後に、フォルト・ポリシーをフォルト・ポリシー・バインディング・ファイルに関連付けます。フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されたポリシーを、SOAコンポジット・アプリケーションのサービス・コンポーネント、サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントに関連付けます。

1. SOAコンポジット・エディタを開きます。
2. SOAコンポジット・エディタ上部のアイコンをクリックして、このフォルト・ポリシーのフォルト・ポリシー・バインディングを定義します。図12-18に詳細を示します。

   図12-18 フォルト・ポリシーのバインディング・アイコン

   
   「図12-18 フォルト・ポリシーのバインディング・アイコン」の説明

   「コンポジット・フォルト・ポリシー」ダイアログが表示されます。

3. 異なるフォルト・ポリシー・ファイル(たとえば、ファイル・ディレクトリやMDSリポジトリで作成されたもの)を指定する場合、「フォルト・ポリシー・ファイル」フィールドの右側にある「参照」アイコンをクリックします。
4. SOAコンポジット・アプリケーション、サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントの「ポリシー」列で、添付するフォルト・ポリシーを選択します。図12-19に詳細を示します。

   図12-19 「コンポジット・フォルト・ポリシー」ダイアログ

   
   「図12-19 「コンポジット・フォルト・ポリシー」ダイアログ」の説明
5. 「アプリケーション」ウィンドウの「SOA」フォルダ、「fault-bindings.xml」ファイルを選択して、その内容を表示します。図12-20に詳細を示します。

   図12-20 fault-bindings.xmlファイルの選択

   
   「図12-20 fault-bindings.xmlファイルの選択」の説明

   ファイルは図12-21のようになります。

   図12-21 fault-bindings.xmlファイル

   
   「図12-21 fault-bindings.xmlファイル」の説明

12.4.3 自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法

この項では、フォルト・ポリシーを手動で設計する方法について説明します。「自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法」で説明されているように、フォルト・ポリシーをフォルト・ポリシー・ウィザードで設計することが推奨アプローチです。

12.4.3.1 自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成

自動フォルト・リカバリに対するフォルト・ポリシー・ファイルを手動で作成するには:

1. フォルト・ポリシー・ファイルを(たとえば、fault-policies.xmlなどの名前で)作成します。このファイルには、特定のタスクを実行するためのconditionセクションとactionセクションを挿入します。
2. このファイルをcomposite.xmlファイルと同じディレクトリまたは別の場所に格納してoracle.composite.faultPolicyFileプロパティを定義します。

   <property
    name="oracle.composite.faultPolicyFile">oramds:/apps/faultpolicyfiles/
    fault-policies.xml
   </property>
   <property
    name="oracle.composite.faultBindingFile">oramds:/apps/faultpolicyfiles/
    fault-bindings.xml
   </property>
   

   フォルト・ポリシー・ファイルがファイル・システム内に配置されている場合は、次の書式を使用します。

   <property
   name="oracle.composite.faultPolicyFile">file:/project/apps/fault-policies.xml
   </property>
   

3. フォルト・ポリシー・ファイルのconditionセクションを定義します。

   • このconditionセクションについては、次の点に注意してください。

     • このセクションには、faultNameに基づいて条件を指定します。

     • faultNameには、複数の条件を構成できます。

     • 各条件には、1つのtestセクション(XPath式)と1つのactionセクションがあります。

     • testセクション(XPath式)は、フォルト時に使用可能なフォルト変数に対して評価されます。

     • actionセクションには、同じファイルに定義されているアクションへの参照があります。

     • 問い合せることができるのは、フォルト時に使用可能なフォルト変数のみです。

     • 条件の評価順序は、ドキュメントに記載されている順序によって決まります。

     • 特定のエラー条件が発生した際に配信する条件(電子メール、JMSキューまたはログ・ファイル)と1つ以上のアラートを関連付けることができます。

     表12-5に、フォルト・ポリシー・ファイルのconditionセクションの例を示します。conditionセクションで定義される全アクションは、actionセクションにおけるアクションに関連付けられる必要があります。

     表12-5 フォルト・ポリシー・ファイルでのconditionセクションの使用

     条件の例	フォルト・ポリシー・ファイルの構文
     この条件は、code = "WSDLFailure"のフォルト変数をチェックします。 ora-terminateのactionが指定されています。	<condition> <test>$fault.code="WSDLReading Error" </test> <action ref="ora-terminate"/> </condition>
     test条件は指定されていません。これは、指定したfaultNameのcatchAll条件です。	<condition> <action ref="ora-rethrow"/> </condition>
     2つのユーザー通知アラートが条件で定義されています。フォルト発生時に作成するユーザー通知アラートのタイプ(たとえば、電子メール・アラート、JMSキュー・アラートまたはログ・ファイル・アラート)を選択します。	<condition> <alert ref = "ora-jms"/> <alert ref = "ora-email"/> <action ref="ora-rethrow"/> </condition>
     faultName名前属性がない場合は、任意のQNameのフォルトのcatchAllアクティビティを示します。	<faultName > . . . </faultName>

4. フォルト・ポリシー・ファイルのactionセクションを定義します。フォルト・ポリシー・ファイルの検証は、デプロイメント時に実施されます。フォルト・ポリシーを変更する場合は、フォルト・ポリシーが含まれているSOAコンポジット・アプリケーションを再デプロイする必要があります。

   表12-6に、フォルト・ポリシー・ファイルのactionセクションの例をいくつか示します。一部のフォルトには、自動リカバリ・アクションを指定できます。再試行と管理者操作を除くすべてのリカバリ・アクションでは、複数のアクションが同時に実行されます。

   表12-6 フォルト・ポリシー・ファイルでのactionセクションの使用

   リカバリ・アクション	フォルト・ポリシー・ファイルの構文
   再試行: アクティビティを再試行するために、次のアクションが用意されています。 指定回数の再試行。 再試行から次の再試行までの遅延(秒単位)の指定。 指数バックオフによる再試行間隔の増加。 N回の再試行が失敗となった場合の再試行失敗時アクションへのチェーン。 再試行が成功した場合の再試行成功時アクションへのチェーン。 ノート: 指数バックオフでは、次の再試行が2倍のdelayでスケジュールされいて、このdelayは、現在の再試行間隔を示します。たとえば、現在の再試行間隔が2秒の場合、次の再試行間隔は4秒にスケジュールされ、その次は8秒、16秒と、retryCount値に達するまで増分されます。	<Action id="ora-retry"> <Retry> <retryCount>3</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> <retryFailureAction ref="ora-java"/> <retrySuccessAction ref="ora-java"/> </Retry> </Action> 次の詳細に注意してください。 再試行に成功した場合、フォルト管理フレームワークは、再試行成功時アクションにチェーンされます。 すべての再試行に失敗した場合、フォルト管理フレームワークは、再試行失敗時アクションにチェーンされます。
   管理者操作: 現在のアクティビティの処理が停止します。この場合は、Oracle Enterprise Manager Fusion Middleware Controlに移動して、このインスタンスに対するリカバリ・アクションを手動で実行できます。	<Action id="ora-human-intervention"> <humanIntervention/></Action>
   プロセスの終了: プロセスを終了します。	<Action id="ora-terminate"><abort/></Action>
   Javaコード: 外部Javaクラスを実行できます。 returnValue: 実装されるJavaクラスは、文字列を戻すメソッドを実装している必要があります。ポリシーは、戻された文字列に基づいて新しいアクションにチェーンできます。 詳細は、「Javaアクション・フォルト・ポリシーの使用方法」を参照してください。	<Action id="ora-java"> <!-- this is user provided custom java class--> <javaAction className="mypackage.myClass" defaultAction="ora-terminate"> <returnValue value="REPLAY" ref="ora-terminate"/> <returnValue value="RETRHOW" ref="ora-rethrow-fault"/> <returnValue value="ABORT" ref="ora-terminate"/> <returnValue value="RETRY" ref="ora-retry"/> <returnValue value="MANUAL" ref="ora-human-intervention"/> </javaAction> </Action>
   フォルトの再スロー: フォルトは、BPELフォルト・ハンドラ(scopeアクティビティ内のcatchアクティビティ)に送信されます。使用可能なハンドラがない場合、そのフォルトは上部に報告されます。	<Action id="ora-rethrow-fault"><rethrowFault/></Action>
   スコープの再実行: 再実行フォルトが発生します。	<Action id="ora-replay-scope"><replayScope/></Action>

ノート:

あらかじめシードされているリカバリ・アクションのタグ名(ora-retry、ora-human-intervention、ora-terminateなど)は、単なるサンプルです。これらの名前は各自の環境に適した名前に置換できます。

condition、actionおよびalertのセクションが完全に定義されているフォルト・ポリシー・ファイルは、次のようになります。

ノート:

• フォルト・ポリシー・ファイルの名前は、単一の固有名に限定されているわけではありません。ただし、これらの名前は、fault-policy.xsdスキーマ・ファイルに準拠している必要があります。

• このフォルト・ポリシー・ファイルは、フォルト名に基づいてフォルトを捕捉する例を示しています。フォルトは、メッセージ・タイプまたはフォルト名(あるいはその両方)に基づいて捕捉することもできます。

  <faultName name="myfault" type="fault:faultType">

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <faultPolicy version="2.0.1" id="ModifyAndRecover"
               xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xs="http://www.w3.org/2001/XMLSchema"
               xmlns="http://schemas.oracle.com/bpel/faultpolicy"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Conditions>
      <!-- Handle remoteFault system exceptions -->
      <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
 name="bpelx:remoteFault">
        <condition>
        <!--<test>$fault.code="1"</test>-->
          <alert ref = "ora-jms"/> 
          <alert ref = "ora-email"/>
       <action ref="default-human-intervention"/>
        </condition>
      </faultName>
           <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
 name="bpelx:bindingFault">
        <condition>
          <action ref="default-human-intervention"/>
        </condition>
      </faultName>          </Conditions>
       <Alerts>
          <Alert id="ora-email">
           <email>
             <To>[e-mail]</To>
                 <CC>[e-mail]</CC>
           </email>
          </Alert>
          <Alert id="ora-jms">
        <JMS propertySet="jms-props">
          <Headers>
            <property name="correlationId">myvalue</property>
             <property name="correlationId1">myvalue1</property>
          </Headers>
        </JMS>
      </Alert>
    </Alerts>
    <Actions>
      <!-- Generics -->
      <Action id="default-terminate">
        <abort/>
      </Action>
      <Action id="default-replay-scope">
        <replayScope/>
      </Action>
      <Action id="default-rethrow-fault">
        <rethrowFault/>
      </Action>
      <Action id="default-human-intervention">
        <humanIntervention/>
      </Action>
      <Action id="ora-retry-with-human-intervention">
        <retry>
          <retryCount>1</retryCount>
          <retryInterval>2</retryInterval>
          <exponentialBackoff/>
          <retryFailureAction ref="default-terminate"/> 
        </retry>
      </Action>
      </Actions>
      <Properties>
       <propertySet name="jms-props">
         <property name="jmsDestination">MyQueue</property>
         <property
 name="connectionFactory">jms/fabric/ehconnectionfactory</property>
     </propertySet>
     </Properties>
  </faultPolicy>
</faultPolicies>

12.4.3.2 フォルト・ポリシー・バインディングへのフォルト・ポリシーの関連付け

ノート:

フォルト・ポリシー・バインディング・ファイルは、fault-bindings.xmlという名前にする必要があります。これは、fault-bindings.xsdスキーマ・ファイルに準拠しています。

フォルト・ポリシー・バインディングにフォルト・ポリシーを関連付けるには:

1. フォルト・ポリシー・バインディング・ファイル(fault-bindings.xml)を作成します。このファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを、使用しているフォルト・ポリシー・バインディング(SOAコンポジット・アプリケーションまたはコンポーネント(参照バインディング・コンポーネントまたはBPELプロセス/Oracle Mediatorのサービス・コンポーネント)のいずれか)のレベルに関連付けます。
2. 「自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成」のステップ2に示すように、composite.xmlファイルと同じディレクトリにファイルを置くか、ファイルをリモートの場所に置いてoracle.composite.faultBindingFileプロパティを定義します。

   フォルト・ポリシー・バインディング・ファイルは、fault-policies.xmlファイルに定義されているフォルト・ポリシーを関連付けます。

   <?xml version="1.0" encoding="UTF-8" ?>
   <faultPolicyBindings version="0.0.1"
    xmlns="http://schemas.oracle.com/bpel/faultpolicy"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <composite faultPolicy="FusionMidFaults"/>
       <!--<composite faultPolicy="ServiceExceptionFaults"/>-->
       <!--<composite faultPolicy="GenericSystemFaults"/>-->
   </faultPolicyBindings>

12.4.3.3 その他のフォルト・ポリシーおよびフォルト・ポリシー・バインディング・ファイルのサンプル

この項では、フォルト・ポリシーとフォルト・ポリシー・バインディング・ファイルのその他のサンプルを示します。次の例にfault-policies.xmlファイルの内容を示します。

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1" 
                   id="CRM_ServiceFaults" 
                   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
                   xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns="http://schemas.oracle.com/bpel/faultpolicy" 
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                       <Conditions>
        <!-- Fault if wsdlRuntimeLocation is not reachable -->
        <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
 name="bpelx:remoteFault">
            <condition>
                <test>$fault.code="WSDLReadingError"</test>
                <action ref="ora-terminate"/>
            </condition>
            <condition>
                <action ref="ora-java"/>
            </condition>
        </faultName>
        <!-- Fault if location port is not reachable-->
        <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
 name="bpelx:bindingFault">
            <!--ORA-00001: unique constraint violated on insert-->
            <condition>
                <test>$fault.code="1"</test>
                <action ref="ora-java"/>
            </condition>
            <!--ORA-01400: cannot insert NULL -->
            <condition>
                <test xmlns:test="http://test">$fault.code="1400"</test>
                <action ref="ora-terminate"/>
            </condition>
            <!--ORA-03220: required parameter is NULL or missing -->
            <condition>
                <test>$fault.code="3220"</test>
                <action ref="ora-terminate"/>
            </condition>
            <condition>
                <action ref="ora-retry-crm-endpoint"/>
            </condition>
        </faultName>
        <!-- Business faults -->
        <!-- Fault comes with a payload of error, make sure the name space is
 provided here or at root level -->
        <faultName xmlns:credit="http://services.otn.com"
 name="credit:NegativeCredit">
            <!-- you get this fault when SSN starts with 0-->
            <condition>
                <test>$fault.payload="Bankruptcy Report"</test>
                  <alert ref = "ora-email"/>
                <action ref="ora-human-intervention"/>
                <!--action ref="ora-retry"/-->
            </condition>
            <!-- you get this fault when SSN starts with 1-->
            <condition>
                <test>$fault.payload="Bankruptcy Report-abort"</test>
                <action ref="ora-terminate"/>
            </condition>
            <!-- you get this fault when SSN starts with 2-->
            <condition>
                <test>$fault.payload="Bankruptcy Report-rethrow"</test>
                <action ref="ora-rethrow-fault"/>
            </condition>
            <!-- you get this fault when SSN starts with 3-->
            <condition>
                <test>$fault.payload="Bankruptcy Report-replay"</test>
                <action ref="ora-replay-scope"/>
            </condition>
            <!-- you get this fault when SSN starts with 4-->
            <condition>
                <test
 xmlns:myError="http://services.otn.com">$fault.payload="Bankruptcy
 Report-human"</test>
                <action ref="ora-human-intervention"/>
            </condition>
            <!-- you get this fault when SSN starts with 5-->
            <condition>
                <test>$fault.payload="Bankruptcy Report-java"</test>
                <action ref="ora-java"/>
            </condition>
        </faultName>
           </Conditions>
              <Actions>
               <Action id="ora-retry">
            <retry>
                <retryCount>3</retryCount>
                <retryInterval>2</retryInterval>
                <exponentialBackoff/>
                <retryFailureAction ref="ora-java"/>
                <retrySuccessAction ref="ora-java"/>
            </retry>
        </Action>
        <Action id="ora-retry-crm-endpoint">
            <retry>
                <retryCount>5</retryCount>
                <retryFailureAction ref="ora-java"/>
                <retryInterval>5</retryInterval>
                <retrySuccessAction ref="ora-java"/>
            </retry>
        </Action>
        <Action id="ora-replay-scope">
            <replayScope/>
        </Action>
        <Action id="ora-rethrow-fault">
            <rethrowFault/>
        </Action>
        <Action id="ora-human-intervention">
            <humanIntervention/>
        </Action>
        <Action id="ora-terminate">
            <abort/>
        </Action>
        <Action id="ora-java">
            <!-- this is user provided class-->
            <javaAction
 className="com.oracle.bpel.client.config.faultpolicy.TestJavaAction"
 defaultAction="ora-terminate" propertySet="prop-for-billing">
                <returnValue value="REPLAY" ref="ora-terminate"/>
                <returnValue value="RETRHOW" ref="ora-rethrow-fault"/>
                <returnValue value="ABORT" ref="ora-terminate"/>
                <returnValue value="RETRY" ref="ora-retry"/>
                <returnValue value="MANUAL" ref="ora-human-intervention"/>
            </javaAction>
        </Action>
                       </Actions>
                   <Properties>
                           <propertySet name="prop-for-billing">
            <property name="user_email_recipient">bpeladmin</property>
            <property name="email_recipient">[e-mail]</property>
            <property name="email_recipient">[e-mail]</property>
            <property name="email_threshold">10</property>
            <property name="sms_recipient">[phone]</property>
            <property name="sms_recipient">+4212345</property>
            <property name="sms_threshold">20</property>
            <property name="user_email_recipient">john</property>
        </propertySet>
        <propertySet name="prop-for-order">
            <property name="email_recipient">[e-mail]</property>
            <property name="email_recipient">[e-mail]</property>
            <property name="email_threshold">10</property>
            <property name="sms_recipient">+42222</property>
            <property name="sms_recipient">+423335</property>
            <property name="sms_threshold">20</property>
        </propertySet>
                   </Properties>                   
</faultPolicy>
<faultPolicy version="2.0.1" 
                   id="Billing_ServiceFaults" 
                   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
                   xmlns:xs="http://www.w3.org/2001/XMLSchema"
        
                   xmlns="http://schemas.oracle.com/bpel/faultpolicy" 
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
    <faultName>
    <condition>
       <action ref="ora-manual"/>
    </condition>
    </faultName>
</Conditions>
<Actions>
        <Action id="ora-manual">
            <humanIntervention/>
        </Action>
</Actions>
</faultPolicy>
</faultPolicies>

次の例に、fault-policies.xmlに定義されているフォルト・ポリシーを関連付けるfault-bindings.xmlファイルを示します。

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1"
 xmlns="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <composite faultPolicy="ConnectionFaults"/>
    <component faultPolicy="ServiceFaults">
        <name>Component1</name>
        <name>Component2</name>
    </component>
    <!-- Below listed component names use polic CRM_SeriveFaults --> 
    <component faultPolicy="CRM_ServiceFaults">
        <name>HelloWorld</name>
        <name>ShippingComponent</name>
        <name>AnotherComponent"</name>
    </component>
    <!-- Below listed reference names and port types use polic CRM_ServiceFaults
 --> 
    <reference faultPolicy="CRM_ServiceFaults">
        <name>creditRatingService</name>
        <name>anotherReference</name>
        <portType
 xmlns:credit="http://services.otn.com">credit:CreditRatingService</portType>
        <portType
 xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/insert/">db:insert_
plt</portType>
    </reference>
    <reference faultPolicy="test1">
        <name>CreditRating3</name>
    </reference>
</faultPolicyBindings>

12.4.3.4 複数の拒否ハンドラがあるフォルト・ポリシーの設計

拒否メッセージのアクション・ハンドラを使用するフォルト・ポリシーを設計する際は、実行できる書込みアクションが1つのみであることに注意してください。次の例に示すように、複数の拒否ハンドラを定義している場合も、複数の書込みアクションは実行できません。この場合、定義されている最初の拒否ハンドラ(この例ではora-queue)のみが実行されます。

<faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages" 
name="rjm:FileIn"> 
        <condition> 
           <action ref="ora-queue"/> 
        </condition> 
       </faultName> 
        <faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages" 
name="rjm:FileIn"> 
        <condition> 
           <action ref="ora-file"/> 
        </condition> 
       </faultName>

12.4.4 フォルト・ポリシーの実行方法

フォルト・ポリシーは、SOAコンポジット・アプリケーションの一部としてデプロイします。デプロイメント後は、フォルト・リカバリ・アクションをOracle Enterprise Manager Fusion Middleware Controlから実行できます。終了、再試行、再スロー、Javaなどのアクションは、コンポジットの実行の一部として再試行されます。ユーザーが明示的に実行する必要ありません。管理者操作アクションはOracle Enterprise Manager Fusion Middleware Controlから手動で実行できます。

• アクティビティの再試行

• 変数の変更(フォルトが発生したアクティビティに使用可能)

• インスタンスの続行(アクティビティを成功としてマーク)

• 例外の再スロー

• インスタンスの中断

• スコープの再実行例外のスロー

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

12.4.5 Javaアクション・フォルト・ポリシーの使用方法

Javaアクション・フォルト・ポリシーを使用する際は、次の点に注意してください。

• 用意されているJavaクラスは、特定のインタフェースに従っています。このインタフェースは文字列を戻します。実行後に取得する出力およびフォルト・ポリシーには、複数の値を指定できます。

• 実装されているメソッドの出力値(戻り値)からフォルト・ポリシーへのマッピングを指定することで、追加のフォルト・ポリシーを実行できます。

• ReturnValueが指定されていない場合は、次の例に示すように、デフォルトのフォルト・ポリシーが実行されます。

<Action id="ora-java">
  <javaAction className="mypackage.myclass"
    defaultAction="ora-human-intervention" propertySet="prop-for-billing">
   <!--defaultAction is a required attribute, but propertySet is optional-->
   <!-- attribute-->
     <ReturnValue value="RETRY" ref="ora-retry"/>   
     <!--value is not nilable attribute & cannot be empty-->
     <ReturnValue value="RETRHOW" ref="ora-rethrow-fault"/>
  </javaAction>
</Action>

表12-7に、ReturnValueの使用例を示します。

表12-7 システムによるJavaアクション・フォルト・ポリシーの解釈

コード	説明
<ReturnValue value="RETRY" ref="ora-retry"/>	メソッドからRETRYという文字列が戻された場合にora-retryアクションを実行します。
<ReturnValue value="" ref="ora-rethrow"/>	検証は失敗です。
<javaAction className="mypackage.myclass" defaultAction="ora-human-intervention">	Javaコード実行後にora-human-interventionを実行します。この属性は、メソッドからの戻り値が指定のReturnValueと一致しない場合に使用されます。
<ReturnValue value="RETRY" ref="ora-retry"/> <ReturnValue value="" ref=""/>	検証は失敗です。
<javaAction className="mypackage.myclass" defaultAction=" ora-human-intervention"> <ReturnValue></ReturnValue>	検証は失敗です。

Javaクラスを起動するには、IFaultRecoveryJavaClassインタフェースを実装しているクラスを指定できます。IFaultRecoveryJavaClassは、fabric-runtime.jarファイルにあります。パッケージ名は、oracle.integration.platform.faultpolicyです。

次の例に示すように、IFaultRecoveryJavaClassインタフェースには2つのメソッドがあります。

public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess( IFaultRecoveryContext ctx );
public String handleFault( IFaultRecoveryContext ctx );
}

次の詳細に注意してください。

• handleRetrySuccessは、再試行に成功した場合に起動されます。再試行ポリシーは、retrySuccessActionのJavaアクションにチェーンします。

• handleFaultは、javaActionタイプのポリシーを実行する際に起動されます。

• フォルト・ポリシー・クラスは、次の2つのいずれかの方法でパッケージ化およびデプロイされます。

  • SOAコンポジット・アプリケーションを使用してJavaクラスをパッケージ化します。

  • Javaクラスを複数のSOAコンポジット・アプリケーションで共有する必要がある場合は、共有場所($MW_HOME/soa/soa/ modules/oracle.soa.ext_11.1.1など)に置きます。共有場所には、クラス・パスで使用できるようにするためのJavaクラスの配置方法を説明するreadmeファイルが含まれています。

次の例にIFaultRecoveryContextで使用可能なデータを示します。

public interface IFaultRecoveryContext {

/**
 * Gets implementation type of the fault.
 * @return
 */
public String getType();

/**
 * @return Get property set of the fault policy action being executed.
 */
public Map getProperties();

/**
 * @return Get fault policy id of the fault policy being executed.
 */
public String getPolicyId();

/**
 * @return Name of the faulted partner link.
 */
public String getReferenceName();

/**
 * @return Port type of the faulted reference .
 */
public QName getPortType();
}

このインタフェースのサービス・エンジン実装では、さらに詳細な情報が提供されます(たとえば、Oracle BPEL Process Manager)。次の例に詳細を示します。

public class BPELFaultRecoveryContextImpl extends BPELXExecLetUtil implements
IBPELFaultRecoveryContext,  IFaultRecoveryContext{
...
}

次の例に示すように、Oracle BPEL Process Manager固有のデータは、IBPELFaultRecoveryContextを使用して入手できます。

public interface IBPELFaultRecoveryContext {
public void addAuditTrailEntry(String message);

public void addAuditTrailEntry(String message, Object detail);

public void addAuditTrailEntry(Throwable t);
/**
 * @return Get action id of the fault policy action being executed.
 */
public String getActionId();

/**
 * @return Type of the faulted activity.
 */
public String getActivityId();

/**
 * @return Name of the faulted activity.
 */
public String getActivityName();

/**
 * @return Type of the faulted activity.
 */
public String getActivityType();

/**
 * @return Correleation id of the faulted activity.
 */
public String getCorrelationId();

/**
 * @return BPEL fault that caused the invoke to fault.
 */
public BPELFault getFault();

/**
 * @return Get index value of the instance
 */
public String getIndex(int i);

/**
 * @return get Instance Id of the current process instance of the faulted
 *         activity.
 */
public long getInstanceId();

/**
 * @return Get priority of the current process instance of the faulted
 *         activity.
 */
public int getPriority();

/**
 * @return Process DN.
 */
public ComponentDN getProcessDN();

/**
 * @return Get status of the current process instance of the faulted
 *         activity.
 */
public String getStatus();

/**
 * @return Get title of the current process instance of the faulted
 *         activity.
 */
public String getTitle();

public Object getVariableData(String name) throws BPELFault;

public Object getVariableData(String name, String partOrQuery)
throws BPELFault;

public Object getVariableData(String name, String part, String query)
throws BPELFault;

/**
 * @param priority
 *            Set priority of the current process instance of the faulted
 *            activity.
 * @return
 */
public void setPriority(int priority);

/**
 * @param status
 *            Set status of the current process instance of the faulted
 *            activity.
 */
public void setStatus(String status);

/**
 * @param title
 *            Set title of the current process instance of the faulted
 *            activity.
 * @return
 */
public String setTitle(String title);

public void setVariableData(String name, Object value) throws BPELFault;

public void setVariableData(String name, String partOrQuery, Object value)
throws BPELFault;

public void setVariableData(String name, String part, String query,
Object value) throws BPELFault;
}

次の例は、javaActionの実装例を示しています。

public class TestJavaAction implements IFaultRecoveryJavaClass {
public void handleRetrySuccess(IFaultRecoveryContext ctx) {
System.out.println("This is for retry success");
handleFault(ctx);
}
public String handleFault(IFaultRecoveryContext ctx) {		
System.out.println("-----Inside handleFault-----\n" + ctx.toString());

                dumpProperties(ctx.getProperties());
/* Get BPEL specific context here */
BPELFaultRecoveryContextImpl bpelCtx = (BPELFaultRecoveryContextImpl) ctx;
bpelCtx.addAuditTrailEntry("hi there");
System.out.println("Policy Id" + ctx.getPolicyId());
         ...
        }

12.4.6 Oracle BPM Suiteに対してフォルト・ポリシーを設計する方法

Oracle BPM Suiteに対してフォルト・ポリシーを設計し、実行できます。詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発の「BPMでのフォルト処理の使用」を参照してください。

12.4.7 フォルト・ポリシーを同期BPELプロセスで設計する方法に関する必知事項

フォルト・ポリシーを同期プロセスで設計する際、次のアクションを指定しないでください。これらのアクションによりデハイドレーションが同期プロセスで発生し、タイムアウトになります。

• 再試行

• 管理者操作

• Terminate

12.4.8 インスタンス再試行回数を超過した場合のフォルト管理動作に関する必知事項

インスタンスをリカバリするフォルト・ポリシーをora-retryアクションで構成し、指定したインスタンス再試行回数を超過すると、そのインスタンスはopen.faulted(進行中)としてマークされます。このインスタンスは引き続きアクティブです。

インスタンスをopen.faultedとしてマークすることで、そのインスタンスの消失が防止されます。フォルト・ポリシー・ファイルのora-retryアクションの後には、次のような別のフォルト処理アクションを構成できます。

• ora-human-interventionアクションを構成して、インスタンスのリカバリをOracle Enterprise Manager Fusion Middleware Controlから手動で実行します。

• ora-terminateアクションを構成し、インスタンスをクローズ(closed.faultedとしてマーク)して再試行されないようにします。

ただし、フォルト・ポリシー・ファイルでora-retryアクションの後に実行されるアクションを設定していない場合に、インスタンス再試行回数を超過すると、インスタンスはopen.faultedとしてマークされたままになり、リカバリはインスタンスの処理を試行します。

たとえば、次のコードに示すフォルト・ポリシー・ファイルでは、ora-retryの後にアクションが定義されていません。

<Action id="ora-retry">
       <retry>
          <retryCount>2</retryCount>
          <retryInterval>2</retryInterval>
          <exponentialBackoff/>
       </retry>
  </Action>

この場合は、次のアクションが実行されます。

• (前述のフォルト・ポリシー・コードを使用してフォルトを処理する)invokeアクティビティが試行されます。

• 間隔を増やして2回の再試行(2秒後、次に4秒後)が実行されます。

• すべての再試行に失敗した場合は、次のアクションが実行されます。

  • 詳細なフォルト・エラー・メッセージが監査証跡に記録されます。

  • インスタンスがopen.faulted(進行中)としてマークされます。

  • インスタンスが選択され、invokeアクティビティが再試行されます。

• リカバリにも失敗する場合があります。その場合は、invokeアクティビティが再実行されます。追加の監査メッセージが記録されます。

12.4.9 フォルト・ポリシー再試行中のバインディング・レベル再試行に関する必知事項

アウトバウンド方向のJCAレベルの再試行とフォルト・ポリシー・ファイル内の再試行アクションの両方を備えたアダプタで、アウトバウンド障害に対する再試行アクションをテストしている場合は、そのJCAレベル(またはバインディング・レベル)再試行がフォルト・ポリシー再試行の中で実行されます。たとえば、図12-22に示すアプリケーションを設計したとします。

図12-22 SOAコンポジット・アプリケーション

「図12-22 SOAコンポジット・アプリケーション」の説明

composite.xmlファイルでは、次に示す再試行パラメータを指定します。

<property name="jca.retry.count" type="xs:int" many="false"
  override="may">2</property>
<property name="jca.retry.interval" type="xs:int" many="false"
  override="may">2</property>
<property name="jca.retry.backoff" type="xs:int" many="false"
  override="may">2</property>

アウトバウンド方向のEQ参照バインディング・コンポーネントのフォルト・ポリシー・ファイルでは、次のコードに示すアクションを指定します。

<retryCount>3</retryCount>
<retryInterval>3</retryInterval>

アウトバウンド障害が発生する場合は、フォルト・ポリシー再試行中にJCA再試行が実行されることが想定されます。フォルト・ポリシーの1回目の再試行時に、JCA再試行がコールされます。この例では、フォルト・ポリシーの再試行ごとに、間隔が2秒で指数バックオフが2のJCA再試行が2回実行されます。

• フォルト・ポリシー再試行1:

  • JCA再試行1 (2秒間隔)

  • JCA再試行2 (4秒間隔)

• フォルト・ポリシー再試行2:

  • JCA再試行1 (2秒間隔)

  • JCA再試行2 (4秒間隔)

• フォルト・ポリシー再試行3:

  • JCA再試行1 (2秒間隔)

  • JCA再試行2 (4秒間隔)

12.5 BPEL実行時フォルトの捕捉

BPEL実行時フォルトは、名前付きのBPELフォルトとして捕捉できます。bindingFaultおよびremoteFaultはメッセージに関連付けることができます。このアクションにより、faultHandlerでフォルトの詳細を取得できます。

12.5.1 BPEL実行時フォルトの捕捉方法

次の手順は、与えられた例を使用して、フォルトを生成し、それを捕捉するためのフォルト・ハンドラを定義する方法を示します。ここでは、WSDLファイルを変更してフォルトを生成し、捕捉するためのcatch属性を作成します。

BPEL実行時フォルトを捕捉するには:

1. RuntimeFault.wsdlをプロセスWSDLにインポートします。RuntimeFault.wsdlは、そのデプロイメント時にsoa-infra-wls.ear内のsoa.marからMDSリポジトリにシードされます。

   Oracle WebLogic ServerドメインにデプロイされたSOAインフラストラクチャには、RuntimeFault.wsdlが格納されているJAR/ZIPファイルsoa.marのコピーが表示されます。

2. messageType bpelx:RuntimeFaultMessageを使用して変数を宣言します。
3. 次の構文を使用して捕捉します。

    <catch faultName="bpelx:remoteFault"  | "bpelx:bindingFault" faultName="varName">

12.6 getFaultAsString XPath式関数によるフォルト詳細の取得

可能なフォルトを捕捉できるようにcatchAllアクティビティが用意されています。ただし、BPELには、取得されたフォルトの詳細情報を取得するためのメソッドが用意されていません。詳細情報を取得するにはgetFaultAsString() XPath拡張関数を使用します。

12.6.1 getFaultAsString XPath拡張関数によるフォルト詳細の取得方法

次の例は、この関数の使用方法を示しています。

<catchAll>
   <sequence>
      <assign>
         <from expression="bpelx:getFaultAsString()"/>
         <to variable="faultVar" part="message"/>
      </assign>
      <reply faultName="ns1:myFault" variable="faultVar" .../>
   </sequence>
</catchAll>

詳細は、「getFaultAsString」を参照してください。

12.7 throwアクティビティによる内部フォルトのスロー

BPELアプリケーションでは、フォルト・メッセージの生成および受取りができます。throwアクティビティには3つの要素(それ自体の名前、フォルトの名前およびフォルト変数)があります。throwアクティビティによってスローされるフォルトはBPEL内部のフォルトです。throwアクティビティは、クライアントと通信する非同期プロセスには使用できません。throwアクティビティの構文には、スロー名、フォルト名およびフォルト変数を指定します。

<throw name="delay" faultName="nsPrefix:fault-1" faultVariable="fVar"/>

12.7.1 throwアクティビティの作成方法

throwアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. throwアクティビティをデザイナにドラッグします。
3. throwアクティビティをダブルクリックして定義します。
4. 名前を入力するか、デフォルト値をそのまま使用します。
5. 「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、監視するフォルトを選択します。
6. 「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。

   選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。

   図12-23に、完成した「Throw」ダイアログの例を示します。

   図12-23 「Throw」ダイアログ

   
   「図12-23 「Throw」ダイアログ」の説明
7. 「適用」をクリックし、「OK」をクリックします。

12.7.2 throwアクティビティ作成時の処理内容

次の例に、設計完了後の.bpelファイルのthrowアクティビティを示します。このthrowアクティビティの実行後にOrderProcessorプロセスが終了します。

<throw name="Throw_Fault_CC_Denied"
    faultName="client:OrderProcessorFault"/>

12.8 rethrowアクティビティによるフォルトの再スロー

rethrowアクティビティは、すぐ外側を囲んでいるフォルト・ハンドラによって最初に捕捉されたフォルトを再スローします。フォルト・ハンドラ内(catchアクティビティ、catchAllアクティビティ内など)では、rethrowアクティビティのみ使用します。rethrowアクティビティは、捕捉されたフォルト(元のフォルトのフォルト名およびフォルト・データ(存在する場合))を再スローするために、フォルト・ハンドラで使用されます。rethrowアクティビティは、フォルト・データに対する変更を無視する必要があります。たとえば:

• フォルト・ハンドラがフォルト・データを変更した後、rethrowアクティビティをコールした場合、元のフォルト・データが再スローされ、変更されたフォルト・データは再スローされません。

• 要素を使用して1つのパーツが定義されたメッセージ・タイプ・フォルトが、同じ要素タイプを検索しているフォルト・ハンドラによって捕捉されるようにする機能を使用してフォルトが捕捉された場合、rethrowアクティビティは元のメッセージ・タイプ・データを再スローします。

ノート:

このアクティビティは、BPELバージョン2.0プロジェクトでサポートされています。

12.8.1 rethrowアクティビティの作成方法

rethrowアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. rethrowアクティビティをデザイナにドラッグします。
3. rethrowアクティビティをダブルクリックして定義します。
4. 図12-24に示すように、必要に応じて名前を入力するか、デフォルト値をそのまま使用します。

   図12-24 「ReThrow」ダイアログ

   
   「図12-24 「Rethrow」ダイアログ」の説明
5. 「適用」をクリックし、「OK」をクリックします。

   完了後、設計は図12-25のようになります。

   図12-25 BPELプロセスのthrowアクティビティ

   
   「図12-25 BPELプロセスのthrowアクティビティ」の説明

12.8.2 フォルト再スロー時の処理内容

次の例に、rethrowアクティビティの設計が完了した後の.bpelファイルを示します。rethrowアクティビティはフォルト・ハンドラ(catchアクティビティ)の内側にあります。

<scope name="scope1">
  <faultHandlers>
    <catch faultName="tns:error" faultVariable="tmpVar"
 faultElement="tns:fault">
      <sequence>
        <assign>
          <copy>
            <from>concat('caught fault: ', $tmpVar)</from>
            <to>$output.payload</to>
          </copy>
        </assign>
        <rethrow name="Rethrow_1"/>
      </sequence>
    </catch>
  </faultHandlers>
  <throw faultName="tns:error" faultVariable="fault"/>
</scope>

12.9 外部フォルトを返す

BPELプロセス・サービス・コンポーネントは、内部フォルトのスローとは対照的に、別のアプリケーションにフォルトを送信して問題を提示できます。同期操作では、replyアクティビティがフォルトを返すことができます。非同期操作では、invokeアクティビティがこの機能を実行します。

12.9.1 同期相互作用でフォルトを返す方法

次の例に、同期相互作用でフォルトを返すreplyアクティビティの構文を示します。

<reply partnerlinke="partner-link-name"
       portType="port-type-name"
       operation="operation-name"
       variable="variable-name" (optional)
       faultName="fault-name">
</reply>

同期リクエストに対して常にフォルトを返すことはあまり有効ではありません。それよりも、アクティビティを条件分岐に組み込み、リクエストされたデータを使用できる場合に最初のブランチが実行されるようにする方が効果的です。リクエストされたデータを使用できない場合、BPELプロセス・サービス・コンポーネントはそのことを示すフォルトを返します。

詳細は、次の章を参照してください。

• 同期相互作用については、「BPELプロセスからの同期Webサービスの起動」を参照してください

• 条件構造の設定については、「BPELプロセスでの条件分岐の使用」を参照してください

12.9.2 非同期相互作用でフォルトを返す方法

非同期相互作用では、クライアントはリプライを待機しません。このため、フォルトを返すためにreplyアクティビティが使用されることはありません。かわりに、BPELプロセス・サービス・コンポーネントは通常はリクエストされた情報を受け取る同じポート・タイプのコールバック操作を使用して、invokeアクティビティによってフォルトを返します。

非同期相互作用の詳細は、「BPELプロセスからの非同期Webサービスの起動」を参照してください。

12.10 scopeアクティビティによるアクティビティ・グループの管理

scopeアクティビティは、他のアクティビティに対してコンテナおよびコンテキストを提供します。scopeは、フォルト、イベント、補正、データ変数および相関セットに対するハンドラを提供します。scopeアクティビティを使用すると、機能構造をグループ化することでBPELフローが単純化されます。このグループ化により、Oracle BPELデザイナでは機能構造を閉じて1つの要素として表示できます。

次の例は、名前がScope_FulfillOrderであるscopeを示します。このscopeは、注文品の出荷方法を判断するFulfillOrder Oracle Mediatorコンポーネントを起動します。

<scope name="Scope_FulfillOrder">
    <variables>
        <variable name="lFulfillOrder_InputVariable"
        messageType="ns17:requestMessage"/>
    </variables>
    <sequence>
        <assign name="Assign_OrderData">
            <copy>
                <from variable="gOrderInfoVariable"
                    query="/ns4:orderInfoVOSDO"/>
                <to variable="lFulfillOrder_InputVariable"
                    part="request" query="/ns4:orderInfoVOSDO"/>
            </copy>
        </assign>
        <invoke name="Invoke_FulfillOrder"
            inputVariable="lFulfillOrder_InputVariable"
            partnerLink="FulfillOrder.FulfillOrder"
            portType="ns17:execute_ptt" operation="execute"/>
    </sequence>
</scope>

12.10.1 scopeアクティビティの作成方法

scopeアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. scopeアクティビティをデザイナにドラッグします。
3. scopeアクティビティをダブルクリックするか、「拡張」アイコンをクリックして、アクティビティを開きます。
4. 「コンポーネント」ウィンドウからアクティビティをドラッグして定義し、scope内に機能を作成します。図12-26に詳細を示します。

   図12-26 開いた状態のscopeアクティビティ

   
   「図12-26 開いた状態のscopeアクティビティ」の説明
5. 「OK」をクリックします。

   完了後、scopeアクティビティの設計は図12-27のようになります。この例では、「Scope_AuthorizeCreditCard」scopeアクティビティが表示されています。

   図12-27 設計完了後のscopeアクティビティ

   
   「図12-27 設計完了後のscopeアクティビティ」の説明

12.10.2 scopeアクティビティへの説明ノートおよびイメージの追加方法

scopeアクティビティには、スコープの機能に関する簡単な説明を提供する説明ノートを追加できます。スコープのグラフィック・イメージを変更することもできます。説明ノートおよびイメージは、Oracle BPELデザイナに表示されます。これらの表示により、スコープをより簡単に理解できるようになります。

説明ノートおよびイメージをscopeアクティビティに追加するには:

1. 次のいずれかのステップを実行します。

   • スコープを右クリックし、「ユーザー・ドキュメント」を選択します。

   • スコープをダブルクリックし、「ユーザー・ドキュメント」タブを選択します。

   「ドキュメント」ダイアログが表示されます。

2. 「コメント」フィールドに、スコープの機能に関する簡単な説明を入力します。
3. 「イメージ」フィールドで、必要に応じて「検索」アイコンをクリックし、スコープのグラフィック・イメージを変更します。
4. 「OK」をクリックします。

   図12-28に示すように、変更した結果がOracle BPELデザイナに表示されます。

   図12-28 説明ノートが記載され、イメージが変更されたscope

   
   「図12-28 説明ノートが記載され、イメージが変更されたscope」の説明
5. 説明ノートを編集する場合は、説明ノートをダブルクリックします。

12.10.3 scopeアクティビティ作成後の処理内容

次の例に、設計完了後の.bpelファイルのscopeアクティビティを示します。Scope_AuthorizeCreditCard scopeアクティビティは、次のアクションを実行する各アクティビティで構成されています。

• クレジット・カード番号がない、またはクレジット・タイプが有効でないためにフォルトになった注文を捕捉するcatchアクティビティ。

• 承認されない注文に対してフォルトをスローするthrowアクティビティ。

• クレジット・カード・タイプ、クレジット・カード番号および購入金額を取得し、この情報をCreditCardAuthorizationServiceサービスの入力変数に割り当てるassignアクティビティ。

• CreditCardAuthorizationServiceサービスをコールして顧客情報を取得するinvokeアクティビティ。

• クレジット・カード検証の結果を確認するswitchアクティビティ。

<scope name="Scope_AuthorizeCreditCard">
    <variables>
        <variable name="lCreditCardInput"
            messageType="ns2:CreditAuthorizationRequestMessage"/>
        <variable name="lCreditCardOutput"
            messageType="ns2:CreditAuthorizationResponseMessage"/>
    </variables>
    <faultHandlers>
        <catch faultName="bpws:selectionFailure">
            <sequence>
                 <assign name="Assign_noCCNumber">
                     <copy>
                         <from expression="string('CreditCardCheck - NO
                             CreditCard')"/>
                         <to variable="gOrderProcessorFaultVariable"
                             part="code"/>
                     </copy>
                 </assign>
                 <throw name ="Throw_NoCreditCard"
                     faultVariable="gOrderProcessorFaultVariable"
                     faultName="ns9:OrderProcessingFault"/>
            </sequence>
        </catch>
        <catch faultName="ns2:InvalidCredit">
            <sequence>
                <assign name="Assign_InvalidCreditFault">
                    <copy>
                        <from expression="concat(bpws:getVariableData
                             ('gOrderInfoVariable','/ns4:orderInfoVOSDO/
                             ns4:CardTypeCode'), ' is not a valid 
                             creditcard type')"/>
                        <to variable="gOrderProcessorFaultVariable"
                            part="summary"/>
                    </copy>
                    <copy>
                        <from expression="string('CreditCardCheck - NOT VALID')"/>
                        <to variable="gOrderProcessorFaultVariable"
                            part="code"/>
                    </copy>
                </assign>
                <throw name="Throw_OrderProcessingFault"
                    faultName="ns9:OrderProcessingFault"
                    faultVariable="gOrderProcessorFaultVariable"/>
            </sequence>
        </catch>
    </faultHandlers>
    <sequence>
        <assign name="Assign_CreditCheckInput">
            <copy>
                <from variable="gOrderInfoVariable"
                    query="/ns4:orderInfoVOSDO/ns4:OrderTotal"/>
                <to variable="lCreditCardInput" part="Authorization"
                    query="/ns8:AuthInformation/ns8:PurchaseAmount"/>
            </copy>
            <copy>
                <from variable="gOrderInfoVariable"
                    query="/ns4:orderInfoVOSDO/ns4:CardTypeCode"/>
                        <to variable="lCreditCardInput" part="Authorization"
                             query="/ns8:AuthInformation/ns8:CCType"/>
            </copy>
            <copy>
                <from variable="gOrderInfoVariable"
                    query="/ns4:orderInfoVOSDO/ns4:AccountNumber"/>
                <to variable="lCreditCardInput" part="Authorization"
                    query="/ns8:AuthInformation/ns8:CCNumber"/>
                    </copy>
        </assign>
        <invoke name="InvokeCheckCreditCard"
            inputVariable="lCreditCardInput"
            outputVariable="lCreditCardOutput"
            partnerLink="CreditCardAuthorizationService"
            portType="ns2:CreditAuthorizationPort"
            operation="AuthorizeCredit"/>
        <switch name="Switch_EvaluateCCResult">
            <case condition="bpws:getVariableData('lCreditCardOutput','status','
                /ns8:status') != 'APPROVED'">
                <bpelx:annotation>
                    <bpelx:pattern>status &lt;&gt; approved</bpelx:pattern>
                </bpelx:annotation>
                <throw name="Throw_Fault_CC_Denied"
                    faultName="client:OrderProcessorFault"/>
            </case>
        /switch>
    </sequence>
</scope>

12.10.4 スコープに関する必知事項

スコープは、CPU能力とメモリーを大量に使用する可能性があるため、過度の使用は避けてください。sequenceアクティビティを使用することで、CPUとメモリーの使用量を抑制し、大きいBPELフローを見やすくできます。

12.10.5 スコープ内のフォルト・ハンドラの使用方法

フォルトが処理されていない場合、フォルト状態が作成されてアプリケーション全体に移行し、プロセス全体がフォルト状態になることがあります。これを防ぐには、フォルトを受け取る可能性があるプロセスの一部をスコープ内に配置します。scopeアクティビティには、次のフォルト処理機能が含まれています。

• スコープ内ではcatchアクティビティが動作し、プロセス全体がフォルト状態になる前に、フォルトおよび例外を捕捉します。catchアクティビティで特定のフォルト名を使用し、個々のフォルトに特定の方法で対応できます。

• catchAllアクティビティは、名前が指定されたcatchアクティビティでは処理されないフォルトを捕捉します。

次の例に、catchおよびcatchAllアクティビティの構文を示します。x:fooという名前のフォルトがスローされたとします。フォルトがフォルト・データを渡さない場合は、最初のcatchが選択されます。フォルトに関連付けられたフォルト・データがある場合、フォルトのデータ・タイプが変数barタイプに一致すると、3番目のcatchが選択されます。そうでない場合、デフォルトのcatchAllハンドラが選択されます。最後に、タイプがbarのタイプに一致し、名前がx:fooでないフォルト変数を持つフォルトは2番目のcatchで処理されます。その他のすべてのフォルトはデフォルトのcatchAllハンドラによって処理されます。

<faulthandlers>
   <catch faultName="x:foo">
         <empty/>
      </catch>
   <catch faultVariable="bar">
         <empty/>
      </catch>
   <catch faultName="x:foo" faultVariable="bar">
         <empty/>
      </catch>
   <catchAll>
         <empty/>
      </catchAll>
</faulthandlers>

12.10.6 idempotentプロパティとフォルト処理に関する必知事項

composite.xmlファイルでidempotentデプロイメント・ディスクリプタのプロパティがfalseに設定されている場合、パートナ・リンクの起動が失敗しても、invokeアクティビティからリカバリは開始されません。invokeアクティビティの再試行をidempotentプロパティに依存することはお薦めいたしません。かわりに、BPELプロセス内に設計したフォルト処理(catchAllアクティビティの場合など)によって、リカバリを試みます。ベスト・プラクティスとして、かわりにフォルト・ポリシーを使用してinvokeアクティビティを再試行することをお薦めします。

表12-8は、idempotentプロパティがfalseに設定されていて、パートナ・リンクの起動が成功した場合と失敗した場合の動作を示しています。

表12-8 idempotentプロパティがfalseに設定されている場合のリカバリ動作

パートナ・リンクの起動	結果
成功	invokeアクティビティは実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。
不成功、かつBPELプロセスにcatchAllアクティビティなどのフォルト処理が含まれている	リカバリはcatchAllアクティビティから開始され、invokeアクティビティからは開始されません。
不成功、かつBPELプロセスにフォルト・ポリシーが含まれている	フォルト・ポリシーが使用されて、invokeアクティビティのリカバリが試みられます。これは、推奨アプローチです。

たとえば、BPELプロセスに次の設計が含まれているとします。

• invokeアクティビティによってパートナ・リンク(この例では、myPartnerLinkという名前です)が起動されます。

• composite.xmlファイルで、idempotentデプロイメント・ディスクリプタのプロパティがfalseに設定されています。

  <property name="bpel.partnerLink.myPartnerLink.idempotent">false</property>
  

  この設定により、BPELプロセスはこのアクティビティの実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。

  このプロパティは、「パートナ・リンクの編集」ダイアログでfalseに設定することもできます。図12-29に詳細を示します。

  図12-29 「パートナ・リンクの編集」ダイアログの「冪等性」タブ

  
  「図12-29 「パートナ・リンクの編集」ダイアログの「冪等性」タブ」の説明

  詳細は、「パートナ・リンク操作レベルでの冪等性の管理」を参照してください。

• scopeアクティビティのcatchAllアクティビティ・エラー・ハンドラによってフォルトが捕捉され、ロールバック・フォルトがスローされます。

パートナ・リンクに対するinvokeアクティビティによる起動が失敗した場合、リカバリはcatchAllアクティビティ・エラー・ハンドラから開始され、invokeアクティビティからは開始されません。Oracle Enterprise Manager Fusion Middleware ControlのBPELプロセスのflowアクティビティで、catchAllアクティビティからのリカバリを監視できます。

これは設計によります。idempotentプロパティの設定は、invokeアクティビティの実行の後に確認されます。実行に失敗し、例外が発生した場合、idempotentプロパティの設定には到達しません。BPELプロセス・サービス・エンジンによって、catchAllアクティビティを開いた直後のインスタンスが保存されます。idempotentプロパティがfalseに設定されているため、このインスタンスを保存する必要があります。これが、リカバリがcatchAllアクティビティで再開される理由です。

かわりに、失敗したinvokeアクティビティをフォルト・ポリシーでリカバリすることをお薦めします。フォルト・ポリシーの作成の詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。

idempotentプロパティの詳細は、「デプロイメント・ディスクリプタのプロパティの概要」を参照してください。

12.10.7 スコープでのcatchアクティビティの作成方法

スコープでcatchアクティビティを作成するには:

1. 開いた状態のscopeアクティビティで、「Catchの追加」をクリックします。図12-30に詳細を示します。

   図12-30 Catchの追加

   
   「図12-30 Catchの追加」の説明

   これにより、scopeアクティビティの右側にcatchアクティビティが作成されます。

2. catchアクティビティをダブルクリックします。
3. 必要に応じて名前を入力します。
4. 「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、フォルトを選択します。
5. 「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。

   選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。

   図12-31に、「Catch」ダイアログの例を示します。この例では、「Scope_AuthorizeCreditCard」scopeアクティビティの「selectionFailure」catchアクティビティが表示されています。このcatchアクティビティは、クレジット・カード番号がない注文を捕捉します。

   図12-31 「Catch」ダイアログ

   
   「図12-31 「Catch」ダイアログ」の説明
6. 追加のフォルト処理機能を設計します。
7. 「OK」をクリックします。

   図12-32に、「Scope_AuthorizeCreditCard」scopeアクティビティに2つのcatchアクティビティがある例を示します。2番目のcatchアクティビティは、有効でないクレジット・タイプを捕捉します。

   図12-32 デザイナに表示されたcatchアクティビティ

   
   「図12-32 デザイナに表示されたcatchアクティビティ」の説明

12.10.8 スコープでのcatchアクティビティ作成時の処理内容

次の例に、設計完了後の.bpelファイルのcatchアクティビティを示します。selectionFailure catchアクティビティはクレジット・カード番号がない注文を捕捉し、InvalidCredit catchアクティビティは有効でないクレジット・タイプを捕捉します。

<faultHandlers>
    <catch faultName="bpws:selectionFailure">
        <sequence>
            <assign name="Assign_noCCNumber">
                <copy>
                    <from expression="string('CreditCardCheck - NO CreditCard')"/>
                    <to variable="gOrderProcessorFaultVariable"
                        part="code"/>
                </copy>
            </assign>
            <throw name ="Throw_NoCreditCard"
               faultVariable="gOrderProcessorFaultVariable"
               faultName="ns9:OrderProcessingFault"/>
    </sequence>
 </catch>
 <catch faultName="ns2:InvalidCredit">
    <sequence>
        <assign name="Assign_InvalidCreditFault">
           <copy>
              <from expression="concat(bpws:getVariableData
                 ('gOrderInfoVariable','/ns4:orderInfoVOSDO/ns4:CardTypeCode'), '
                 is not a valid creditcard type')"/>
              <to variable="gOrderProcessorFaultVariable"
                 part="summary"/>
           </copy>
           <copy>
               <from expression="string('CreditCardCheck - NOT VALID')"/>
               <to variable="gOrderProcessorFaultVariable"
                   part="code"/>
           </copy>
        </assign>
        <throw name="Throw_OrderProcessingFault"
           faultName="ns9:OrderProcessingFault"
           faultVariable="gOrderProcessorFaultVariable"/>
    </sequence>
  </catch>
</faultHandlers>

catchまたはcatchAllアクティビティが選択されていない場合、フォルトが現在のスコープによって捕捉されず、すぐ外側を囲んでいるスコープにスローされます。グローバル・プロセス・スコープでフォルトが発生し(またはグローバル・プロセス・スコープに再スローされ)、グローバル・レベルでフォルトに適合するフォルト・ハンドラがない場合、プロセスが異常終了します。これは、terminateアクティビティ(「BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止」で説明)が実行されたような状況になります。

12.10.9 emptyアクティビティによる操作なしの命令のビジネス・プロセスへの挿入方法

何もしないアクティビティが必要になることがよくあります。たとえば、フォルトを捕捉して抑制する必要がある場合などです。この場合、emptyアクティビティを使用すると、操作なしの命令をビジネス・プロセスに挿入できます。

emptyアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. emptyアクティビティをデザイナにドラッグします。
3. emptyアクティビティをダブルクリックします。

   図12-33に示すように、「Empty」ダイアログが表示されます。

   図12-33 emptyアクティビティ

   
   「図12-33 emptyアクティビティ」の説明
4. 必要に応じて名前を入力します。
5. 「OK」をクリックします。

12.10.10 emptyアクティビティ作成時の処理内容

次の例に、emptyアクティビティの構文を示します。

 <empty standard-attributes>
    standard-elements
  </empty>

12.11 replayアクティビティによるscopeアクティビティ内でのアクティビティの再実行

scopeアクティビティ内にreplayを作成すると、スコープ内のすべてのアクティビティを再実行できます。

12.11.1 replayアクティビティの作成方法

replayアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。
2. replayアクティビティをデザイナにドラッグします。
3. replayアクティビティをダブルクリックします。
4. オプション名を入力します。
5. 図12-34に示すように、再実行するスコープを選択します。

   図12-34 「Replay」ダイアログ

   
   「図12-34 「Replay」ダイアログ」の説明
6. 「適用」をクリックし、「OK」をクリックします。
7. scopeアクティビティの設計を続行します。

   完了後、scopeアクティビティの設計は図12-35のようになります。

   図12-35 scopeアクティビティ内のreplayアクティビティ

   
   「図12-35 scopeアクティビティ内のreplayアクティビティ」の説明

12.11.2 replayアクティビティ作成時の処理内容

次の例は、BPELバージョン2.0をサポートするBPELプロジェクトのreplayアクティビティの設計が完了した後の、.bpelファイルを示しています。BPEL 2.0では、replayアクティビティはextensionActivity要素にラップされます。

<scope name="scope2">
     <sequence>
       <assign>
         <copy>
           <from>$counter2 + 1</from>
           <to>$counter2</to>
         </copy>
       </assign>
       <scope name="scope3">
         <sequence>
           <assign>
             <copy>
               <from>$counter + 1</from>
               <to>$counter</to>
             </copy>
           </assign>
           <if>
             <condition>$counter = 3</condition>
             <empty/>
             <else>
               <extensionActivity>
                 <bpelx:replay name="ReplayScope" scope="Scope_RetrieveOrder"/>
               </extensionActivity>
             </else>
           </if>
         </sequence>
       </scope> 
     </sequence>
   </scope>

BPEL 1.1では、replayアクティビティはbpelx拡張要素としてコード化されます。

<bpelx:replay name="ReplayScope" scope="Scope2"/>

12.12 一連の操作を元に戻した後の補正の使用

補正は、BPELプロセス・サービス・コンポーネントが一部の操作を完了した後で一連の操作を完了できず、引き返して前に完了したトランザクションを取り消す必要がある場合に発生します。たとえば、レンタカー、ホテルおよび航空券を予約するようにBPELプロセス・サービス・コンポーネントが設計されている場合、車とホテルは予約でき、その日付の航空券を予約できない場合があります。この場合、BPELフローは戻って車とホテルをキャンセルすることによって、補正を実行します。

scopeアクティビティでは、補正ハンドラは以前に完了した処理ステップをリバースできます。補正ハンドラは、次のいずれかのアクティビティを使用して関連するスコープが正常に完了した後に呼び出すことができます。

• compensateアクティビティ(BPELバージョン1.1および2.0プロジェクト)

  このアクティビティにより、正常に完了したすべての子スコープ、およびまだ補正されていない子スコープの補正ハンドラが、デフォルトの順序で実行されます。

• compensateScopeアクティビティ(BPELバージョン2.0プロジェクト)

  このアクティビティにより、正常に完了した特定のスコープの補正ハンドラが実行されます。

12.12.1 compensateアクティビティの使用

補正ハンドラは、compensateアクティビティを使用することによって起動でき、補正が実行されるスコープ(補正ハンドラが起動されるスコープ)を指定します。スコープの補正ハンドラは、スコープが正常に完了した場合にのみ起動できます。インストールされていない補正ハンドラを起動することは、emptyアクティビティ(操作なし)を使用することと同じです。これにより、フォルト・ハンドラは、ネストされたどのスコープが正常に完了したかを判断するために、状態を使用しなくても済むようになります。インストールされた補正ハンドラが複数回起動されているプロセスのセマンティクスは定義されていません。

compensateアクティビティを明示的に呼び出す機能は、「Business Process Execution Language for Web Services Specification」のアプリケーションで制御されたエラー処理フレームワークの基礎となります。このアクティビティは、ビジネス・プロセスの次の部分でのみ使用できます。

• 補正が実行されるスコープのすぐ外側を囲んでいるスコープのフォルト・ハンドラ内。

• 補正が実行されるスコープのすぐ外側を囲んでいるスコープの補正ハンドラ内。

たとえば:

<compensate scope="RecordPayment"/>

名前によって補正されているスコープがループでネストされている場合、BPELプロセス・サービス・コンポーネントは一連の反復内で補正ハンドラ・インスタンスを逆の順序で起動します。

スコープの補正ハンドラがない場合、デフォルトの補正ハンドラは、すぐ内側に囲まれているスコープの補正ハンドラを、これらのスコープの完了と逆の順序で起動します。

補正フォームでcompensateアクティビティのスコープ名が省略されると、このデフォルトの動作が明示的に起動されます。これは、囲んでいるフォルトまたは補正ハンドラで追加の作業(変数の更新や外部通知の送信、および内側のスコープに対するデフォルト補正の実行など)を実行する必要がある場合に便利です。外側のスコープに付加されたフォルトまたは補正ハンドラのcompensateアクティビティにより、そのスコープ内に直接ネストされた完了スコープに対する補正ハンドラがデフォルトの順序で起動されます。このアクティビティは、外側のスコープ内にネストされたスコープの明示的な起動を除く、その他のユーザー指定の動作と一緒に使用できます。外側のスコープ内にネストされたこのスコープの補正を明示的に起動すると、デフォルトの順序の補正は、適切に機能しません。

12.12.2 compensateアクティビティの作成方法

compensateアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. compensateアクティビティをデザイナにドラッグします。
3. compensateアクティビティをダブルクリックします。
4. 図12-36に示すように、補正ハンドラを起動するscopeアクティビティを選択します。

   図12-36 compensateアクティビティ

   
   「図12-36 compensateアクティビティ」の説明
5. 「適用」をクリックし、「OK」をクリックします。

12.12.3 compensateアクティビティ作成時の処理内容

scopeアクティビティにインラインで定義された補正ハンドラがある場合、アクティビティの名前はcompensateアクティビティに使用されるスコープの名前です。構文を次の例に示します。

<compensate scope="ncname"? standard-attributes>
    standard-elements
  </compensate>

12.12.4 BPEL 2.0のcompensateScopeアクティビティの使用

compensateScopeアクティビティは、すでに正常に完了している特定の内側のスコープで補正を開始するために使用されます。このアクティビティは、フォルト・ハンドラ、別の補正ハンドラまたは終了ハンドラ内からのみ使用します。

compensateScopeアクティビティを作成する場合、すぐ内側に囲まれているスコープを参照する必要があるターゲットを選択します。スコープにはフォルト・ハンドラまたは補正ハンドラを含める必要があります。

12.12.5 compensateScopeアクティビティの作成方法

ノート:

このアクティビティは、BPEL 2.0プロジェクトでサポートされています。

compensateScopeアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. compensateScopeアクティビティをデザイナにドラッグします。
3. compensateScopeアクティビティをダブルクリックします。
4. 「ターゲット」リストで、補正ハンドラを起動する特定のscopeアクティビティを選択します。図12-37に詳細を示します。

   図12-37 compensateScopeアクティビティ

   
   「図12-37 CompensateScopeアクティビティ」の説明
5. 「適用」をクリックし、「OK」をクリックします。

12.12.6 compensateScopeアクティビティ作成時の処理内容

次の例に、compensateScopeアクティビティの設計が完了した後の.bpelファイルを示します。compensateScopeアクティビティは、catchallフォルト・ハンドラで定義されます。補正ハンドラを起動するスコープが定義されます。

<scope name="ScopeAssignCreditRating">
   <faultHandlers>
      <catchAll>
         <compensateScope target="ScopeAssignScreditRating2" />
      </catchAll>
   </faultHandlers>
   <sequence>
      <scope name="ScopeAssignScreditRating2">
         <compensationHandler>
            <!-- undo work -->
         </compensationHandler>
         <!-- do some work -->
      </scope>
      <!-- do more work -->
      <!-- a fault is thrown here; results of ScopeAssignScreditRating2 must be undone -->
   </sequence>
</scope>

12.13 terminateアクティビティまたはexitアクティビティによるビジネス・プロセス・インスタンスの停止

次のいずれかのアクティビティを使用して、ビジネス・プロセス・インスタンスを停止できます。

• exitアクティビティ(BPELバージョン2.0プロジェクト)

• terminateアクティビティ(BPELバージョン1.1プロジェクト)

12.13.1 BPEL 2.0のexitアクティビティによるビジネス・プロセス・インスタンスの即時終了

exitアクティビティを使用すると、終了処理、フォルト処理または補正処理メカニズムを起動しなくても、すべてのパラレル・ブランチで現在実行中のすべてのアクティビティをただちに終了できます。このアクティビティは、予期しない重大な障害を処理するための適切な理由がない環境で使用すると便利です。

ノート:

未処理の対話もexitアクティビティの影響を受けます。たとえば、プロセスと対話している他のパートナは、到着することのないレスポンスを待機する可能性があります。

12.13.1.1 exitアクティビティの作成方法

exitアクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. exitアクティビティを、exitアクティビティを実行するBPELプロセスのセクションにドラッグします。
3. 図12-38に示すように、exitアクティビティをダブルクリックします。

   図12-38 exitアクティビティ

   
   「図12-38 exitアクティビティ」の説明
4. 必要に応じて名前を入力します。
5. 「適用」をクリックし、「OK」をクリックします。

   完了後、BPELプロセス内のexitアクティビティは図12-39のようになります。

   図12-39 BPELプロセスのexitアクティビティ

   
   「図12-39 BPELプロセスのexitアクティビティ」の説明

12.13.1.2 exitアクティビティ作成時の処理内容

次の例に、exitアクティビティの設計が完了した後の.bpelファイルを示します。

<sequence>
    <!-- receive input from requester -->
    <receive name="receiveInput" partnerLink="client" portType="tns:Test"
        operation="process" variable="input" createInstance="yes"/>
    <assign>
      <copy>
        <from>$input.payload</from>
        <to>$output.payload</to>
      </copy>
    </assign>
    <!-- respond output to requester -->
    <reply name="replyOutput" partnerLink="client"
       portType="tns:Test" operation="process" variable="output"/>
    <exit/>
  </sequence>

12.13.2 BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止

terminateアクティビティは、そのterminateアクティビティが実行されるビジネス・プロセス・インスタンスの動作をただちに終了します。現在実行中のすべてのアクティビティは、フォルト処理または補正動作を実行せずにできるだけ早く終了する必要があります。terminateアクティビティは、BPELプロセス・サービス・コンポーネントのステータスの通知を送信しません。terminateアクティビティを使用する場合は、先に関係ユーザーに通知するようにプログラムしてください。

12.13.2.1 terminateアクティビティの作成方法

terminateアクティビティを作成するには:

1. Oracle JDeveloperの「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
2. terminateアクティビティをデザイナにドラッグします。図12-40に例を示します。

   図12-40 terminateアクティビティ

   
   「図12-40 terminateアクティビティ」の説明
3. terminateアクティビティをダブルクリックします。
4. 必要に応じて名前を入力します。
5. 「OK」をクリックします。

12.13.2.2 terminateアクティビティ作成時の処理内容

次の例に、terminateアクティビティの構文を示します。このアクティビティによってビジネス・プロセス・インスタンスが停止します。

<terminate standard-attributes>
    standard-elements
</terminate>

12.14 アサーション条件によるフォルトのスロー

リクエスト/レスポンスinvokeアクティビティ、receiveアクティビティ、replyアクティビティ、およびpickアクティビティとscopeアクティビティのonMessageブランチで、コールバック・メッセージの受信時に実行されるBPELバージョン1.1および2.0でのアサーション条件を指定できます。アサーションは、falseと評価された場合に、アクティビティからBPELフォルトがスローされるXPath式を指定します。この条件は、パートナ・コールバック後に多数のswitch、assignおよびthrowアクティビティを作成する可能性がある場合の代替手段として提供されています。

条件を実行するタイミングを次の中から選択できます。

• Preassert: この条件は、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に実行されます。

• Postassert: この条件は、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に実行されます。

12.14.1 アサーション条件の作成方法

次のアクティビティでアサーション条件を作成できます。

• invokeアクティビティ、receiveアクティビティ、replyアクティビティ、OnMessageブランチなどのメッセージ交換アクティビティ

• XPath式を指定するためのスタンドアロンassertアクティビティ

12.14.1.1 invokeアクティビティ、receiveアクティビティ、replyアクティビティおよびOnMessageブランチでアサート条件を作成する手順:

1. SOAコンポジット・エディタで、BPELプロセス・サービス・コンポーネントをダブルクリックします。

2. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

3. receiveアクティビティ、invokeアクティビティ、pickアクティビティまたはor scopeアクティビティをデザイナにドラッグします。

4. receiveアクティビティ、invokeアクティビティ、またはpickアクティビティまたはscopeアクティビティのonMessageブランチを開きます。

5. 「アサーション」タブをクリックします。

6. BPEL 2.0プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。それ以外の場合は、ステップ6に進みます。

   1. 条件を実行するタイミングを選択します。表12-9に詳細を示します。

      表12-9 アサーション条件のタブ

      作成対象	選択対象
      アサート前条件	「アサート前」タブ
      アサート後条件	「アサート後」タブ

   2. 図12-41に示すように、「追加」アイコンをクリックします。

      図12-41 BPEL 2.0における「アサーション」タブの「追加」アイコン

      
      「図12-41 BPEL 2.0における「アサーション」タブの「追加」アイコン」の説明

   「Assert」ダイアログが表示されます。

7. BPEL 1.1プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。

   1. 図12-42に示すように、「追加」アイコンをクリックします。

      図12-42 BPEL 1.1における「アサーション」タブの「追加」アイコン

      
      「図12-42 BPEL 1.1における「アサーション」タブの「追加」アイコン」の説明

   2. 条件を実行するタイミングを選択します。表12-10に詳細を示します。

      表12-10 条件実行のオプション

      要素	説明
      アサート前	選択すると、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に条件が実行されます。 ノート: フォルト・ポリシーではpreAssert条件からスローされたフォルトは処理されません。postAssert条件からスローされたフォルトのみがサポートされています。フォルト・ポリシーの詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。
      アサート後	選択すると、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に条件が実行されます。

      選択内容に基づいて、「アサート前」または「アサート後」ダイアログが表示されます。

8. 図12-43に示すように、アサーション条件に値を指定します。この例では、BPEL 2.0プロジェクトのreceiveアクティビティのアサーション条件に「アサート後」が選択されています。

   1. 「検索」アイコンをクリックして「フォルト・チューザ」ダイアログから既存のフォルトを選択し、スローする「フォルトQName」を選択します。フォルトの「ネームスペースURI」および「ローカル・パート」フィールドに、独自の値を指定することもできます。「フォルトQName」の指定を省略した場合は、bpelx:assertFailureフォルトがスローされます。

   図12-43 アサーション条件の値

   
   「図12-43 アサーション条件の値」の説明

9. 完了後に「OK」をクリックして、アクティビティの「アサーション」タブに戻ります。図12-44に示すように、完成したアサーション条件が表示されます。

   図12-44 「アサーション」タブとそのデータ

   
   「図12-44 「アサーション」タブとそのデータ」の説明

10. 「適用」をクリックし、「OK」をクリックします。

12.14.1.2 スタンドアロンassertアクティビティのアサーション条件を作成するには:

1. SOAコンポジット・エディタで、BPELプロセス・サービス・コンポーネントをダブルクリックします。

2. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

3. 図12-45に示すように、assertアクティビティをデザイナにドラッグします。

   図12-45 「コンポーネント」ウィンドウのAssertアクティビティ

   
   「図12-45 「コンポーネント」ウィンドウのAssertアクティビティ」の説明

4. assert アクティビティを開きます。

5. 「式」フィールドの右側にある「XPath式ビルダー」アイコンをクリックします。

6. 式を作成します。

7. 完了後に、「OK」をクリックします。

   「アサート」ダイアログは図12-46のようになります。

   図12-46 「アサート」ダイアログ

   
   「図12-46 「アサート」ダイアログ」の説明

8. 「適用」をクリックし、「OK」をクリックします。

12.14.2 アサーションを無効にする方法

アサーションは、次のいずれかの方法で無効にできます。

• Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザ・プロパティDisableAssertsをtrueに設定する方法。

• 次の例に示すように、SOAコンポジット・アプリケーションのcomposite.xmlファイルで、bpel.config.disableAssertsをtrueに設定する方法。

    <component name="AsyncBPELClient">
      <implementation.bpel src="AsyncBPELClient.bpel"/>
      <property name="bpel.config.disableAsserts">true</property>
    </component>
  

システムMBeanブラウザ・プロパティを設定する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

12.14.3 アサーション条件作成時の処理内容

.bpelファイルのコード・セグメントは、特定の操作に対する設計完了後の定義を示しています。

次のBPEL1.1の例では、invokeアクティビティのbpelx:assert条件がfalseと評価された場合(たとえば、0の信用格付けが発行された場合)は、Negative Creditメッセージが返されます。条件がtrueと評価された場合は、invokeアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。

<invoke name="callbackClient" partnerLink="internalwarehouseservice_client"
 portType="client:InternalWarehouseServiceCallback" operation="processResponse"
 inputVariable="outputVariable">
           <bpelx:assert name="negativeCredit"
                         expression="$crOutput.payload/tns:rating > 0"
                         message="Negative Credit"/>
</invoke>

次のBPEL 1.1の例では、スタンドアロンassertアクティビティのbpelx:assert条件がfalseと評価された場合は、次のメッセージが返されます。

got assertion failure on true expression

条件がtrueと評価された場合は、assertアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。

<bpelx:assert expression="true()bpws:getLinkStatus()" message="'got assertion
failure on true expression'" 

12.14.4 アサーション条件に関する必知事項

この項では、主要なアサーション条件の概念について説明します。

12.14.4.1 bpelx:postAssertおよびbpelx:preAssert拡張要素

アクティビティに応じて、条件を実行するタイミングを指定するには、invokeアクティビティ、receiveアクティビティ、replyアクティビティ、およびpickアクティビティとscopeアクティビティのonMessageブランチの「アサーション」タブで「追加」アイコンをクリックし、「アサート前」または「アサート後」を選択します。選択内容に基づいて、次のbpelx拡張要素が使用されます。

• bpelx:preAssert: 「アサート前」を選択すると、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に条件が実行されます。

• bpelx:postAssert: 「アサート後」を選択すると、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に条件が実行されます。

次の例は、BPEL 1.1におけるreceiveアクティビティ内の複数のbpelx:postAssert拡張要素を示しています。

       <receive name="Receive_1" createInstance="no"
            variable="Receive_1_processResponse_InputVariable"
            partnerLink="AsyncBPELService"
            portType="ns1:AsyncBPELServiceCallback"
            bpelx:for="'PT10S'"
            operation="processResponse">
         <bpelx:postAssert name="assert1" expression="true()" message="'assert
 true failed'" faultName="client:fault1"/>
         <bpelx:postAssert name="assert2" expression="false()" message="'assert
 false failed'" faultName="client:fault2"/>
       </receive> 

次の例に、BPEL 1.1におけるinvokeアクティビティ内の複数のbpelx:preAssert拡張要素を示します。

<invoke name="Invoke_1" inputVariable="Invoke_1_process_InputVariable"
           outputVariable="Receive_1_processResponse_InputVariable"
           partnerLink="SyncBPELService" portType="ns1:SyncBPELService"
           operation="process">
         <bpelx:preAssert name="assert1" expression="true()" message="'assert true
 failed'"/>
         <bpelx:preAssert name="assert2"
 expression="bpws:getVariableData('counter') = 3" message="concat('The value of
 counter is ', $counter)"/> 

「アサーション」タブの使用の詳細は、「アサーション条件の作成方法」を参照してください。

12.14.4.2 faultName属性とmessage属性の使用

BPEL 1.1では、次の例のスキーマ定義に示すように、bpelx:postAssert要素のfaultName属性およびmessage属性を指定できます。

<invoke | receive | onMessage>
    standard-elements
    <bpelx:postAssert name="ncname"? expression="boolean-expr" faultName="QName"+
 message="generic-expr"+/> *
</invoke | receive | onMessage>

次の例に、faultname属性とmessage属性の構文を示します。

<bpelx:postAssert name="Assert_2"
   message='multiple post assert Greater value fired'
   faultName="ns2:GreaterValue"
  expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') <
 500"/>

faultName属性の指定がない場合、フォルトはbpelx:postAssertFailureにデフォルト設定されます。message属性の指定がない場合、メッセージ値はアクティビティの名前にデフォルト設定されます。

<bpelx:postAssert expression="boolean-expr" />

アサーション条件がfalseと評価されるたびに、指定のフォルトがスローされます。分析は、パートナWSDL portTypeに定義されているフォルトに正しく変換できるように、faultName QNameに対して実行されます。メッセージ式は、任意のXPath値のタイプ(string、numberまたはboolean)に評価できる一般的な式です。文字列でない値が返された場合は、値の文字列評価が使用されます。

12.14.4.3 複数のアサーション

receiveアクティビティ、invokeアクティビティ、またはpickアクティビティとscopeアクティビティのonMessageブランチでは、複数のアサーションをネストできます。アサーションの評価は、式がfalseと評価されるまでアサーションの宣言順に続行されます。次の例に詳細を示します。

<invoke name="invokeCR" partnerLink="creditRatingService"
        portType="services:CreditRatingService" operation="process"
        inputVariable="crInput" outputVariable="crOutput">
    <bpelx:postAssert name="negativeCredit" expression="$crOutput.payload/tns:rating >
 0"
                  faultName="services:NegativeCredit" message="'Negative Credit'"
 />
    <bpelx:postAssert name="insufficientCredit"
 expression="$crOutput.payload/tns:rating > 600"
                  faultName="services:InsufficientCredit" message="'Insufficient
 Credit'" />
</invoke>

前の例では、レスポンスの信用格付けがゼロより大きいことを確認する式のアサーションが最初に評価されます。表12-11に、このアサーションの動作を示します。

表12-11 アサーションの動作

返されたレスポンスの信用格付け	結果
ゼロ未満	services:NegativeCreditフォルトがスローされます。
ゼロ以上	アサーションが正しいため、2番目のアサーションが評価されます。
600未満	services:InsufficientCreditフォルトがスローされます。
600以上	アサーションが正しいため、invokeアクティビティからフォルトはスローされません。

アサーションは、いくつでもネストできます。アクティビティからフォルトがスローされないためには、指定したすべてのアサーションがtrueと評価される必要があります。

このコンストラクトを使用して、Javaのif...else if...else文と同様に、着信ペイロードに対して様々なレベルの検証を適用できます。

検証ロジックに関係なく、フォルトが常にスローされるようにするには、false()のアサーション式を指定します。これは、Javaのelseコンストラクトと同じです。

12.14.4.4 組込みおよびカスタムのXPath関数と$variable参照の使用

アサーション条件には、組込みおよびカスタムのXPath関数と$variable参照も使用できます。次のコードは、いくつかの例を示しています。

<bpelx:postAssert expression="bpws:getVariableData( 'crOutput', 'payload',
 '/tns:rating' ) > 0" ... />

<bpelx:postAssert expression="custom:validateRating()" ... />

<bpelx:postAssert xmlns:fn='http://www.w3.org/2005/xpath-functions'
 expression="fn:false()" ... />

XPath式の評価でエラーがスローされると、そのエラーはBPELフォルトにラップされて、アクティビティからスローされます。

アサーションの評価の失敗に起因して、リクエスト/レスポンスinvokeアクティビティ、receiveアクティビティ、またはpickアクティビティやscopeアクティビティのonMessageブランチからスローされるフォルトは、BPELのフォルト管理フレームワークによって捕捉および処理されます。詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。

BPELプロセス・フロー内で捕捉および処理されないフォルトは、操作に対するフォルトがコンポーネントWSDLで宣言されている場合は、BPELコンポーネントからスローされます。操作に対するフォルトが宣言されていない場合、フォルトはFabricInvocationException(実行時フォルト)に変換されます。このフォルトは、いずれかのコール元コンポーネント(BPELコンポーネントを含む)によって捕捉されますが、フォルトのタイプは、当初スローされたタイプではなくなります(ただし、フォルト・メッセージ文字列については、当初のフォルト・メッセージのトレースが保持されます)。

実行時フォルトの詳細は、「BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要」を参照してください。

フォルト・ポリシーの詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。

12.14.4.5 インスタンス監査証跡に対するイベントのアサーション条件評価ロギング

評価される各アサーション条件によって、イベントがインスタンス監査証跡に記録されます。イベントは、アサーションが無事通過したか、失敗したのかを示します(失敗の場合は、フォルト名とメッセージが出力されます)。イベントも、アサーション要素で指定されたname属性を含みます。name属性が指定されていない場合、BPELプロセス・フローのアサーション要素の行番号が使用されます。監査イベントで出力されるアサーション条件は、アサーションを識別するのに便利で、フローをより円滑にデバッグできるようになります。

12.14.4.6 XMLスキーマ・ブール値タイプに評価されない式によるフォルトのスロー

アサーション条件XPath式がXMLスキーマ・ブール値タイプに評価されない場合は、アクティビティからbpelx:postAssertFailureフォルトがスローされます。エラーを示すインスタンス監査証跡のイベントも記録されます。次の例に詳細を示します。

<bpelx:postAssert expression="bpws:getVariableData( 'crOutput', 'payload',
 '/tns:rating' ) > 0" ... />

<bpelx:postAssert expression="custom:validateRating()" ... />

<bpelx:postAssert xmlns:fn='http://www.w3.org/2005/xpath-functions'
 expression="fn:false()" ... />

アサーション式の分析は、BPELコンパイラによって実行され、式がXMLスキーマ・ブール・タイプに評価されない場合は、エラーが報告されます。カスタムXPath関数では、このタイプの分析は実行されません。

12.14.4.7 スタンドアロンassertアクティビティのアサーション条件

BPELプロセス・サービス・コンポーネントのスタンドアロンassertアクティビティで、アサーション条件を作成することもできます。アサーションは、falseと評価された場合に、アクティビティからBPELフォルトがスローされるXPath式を指定します。

bpelx:assert拡張要素は、スタンドアロンassertアクティビティでアサーションを実装します。

<bpelx:assert name="Assert1" expression="string" message="string"/>

スタンドアロンassertアクティビティの使用方法の詳細は、「アサーション条件の作成方法」を参照してください。

12.14.5 アサート後およびアサート前条件のスキーマおよび構文に関する必知事項

アサーション条件は、ネストされた拡張要素として指定されます。次の例に、BPEL 2.0におけるアサート後条件のスキーマ定義を示します。

<invoke | receive | onMessage>
    standard-elements
    <bpelx:postAsserts> 
       <bpelx:postAssert faultName="QName">
         <bpelx:expression expressionLanguage="anyURI"?>expression
         </bpelx:expression>
         <bpelx:message expressionLanguage="anyURI"?>expression</bpelx:message>
       </bpelx:postAssert>
   </bpelx:postAsserts>
</invoke | receive | onMessage>

次の例に、BPEL 2.0におけるアサート後条件の構文を示します。

<bpelx:postAsserts>
   <bpelx:postAssert faultName="ns2:InvalidInput">
     <bpelx:expression>number(concat($inputVariable.payload/client:input,'2')) <  
      500</bpelx:expression>
      <bpelx:message>"AssertXpathPostInvoke_20 assert fired"</bpelx:message>
   </bpelx:postAssert>
</bpelx:postAsserts>

次の例に、BPEL 1.1におけるアサート後条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。

<invoke | receive | onMessage>
    standard-elements
    <bpelx:postAssert name="ncname" expression="boolean-expr" faultName="QName"+
 message="generic-expr"+/>
</invoke | receive | onMessage>

次の例に、BPEL 1.1におけるアサート後条件の構文を示します。

<bpelx:postAssert name="Assert_1"
   message='Post Invoke Multiple assert value fired'
   faultName="ns2:NegativeValue"
   expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') >
0"/>

次の例に、BPEL 2.0におけるアサート前条件のスキーマ定義を示します。

<invoke | reply>
   standard-elements
   <bpelx:preAsserts>
     <bpelx:preAssert faultName="QName">
      <bpelx:expression expressionLanguage="anyURI"?>expression</bpelx:expression>
      <bpelx:message expressionLanguage="anyURI"?>expression</bpelx:message>
     </bpelx:preAssert>
   </bpelx:preAsserts>
</invoke | reply>

次の例に、BPEL 2.0におけるアサート前条件の構文を示します。

<bpelx:preAsserts>
    <bpelx:preAssert faultName="ns1:InvalidInput">
       <bpelx:expression>concat($inputVariable.payload/client:input,'2') >
       $inputVariable.payload/client:input</bpelx:expression>
       <bpelx:message>"AssertXpathPreInvoke_20 Assert test"</bpelx:message>
    </bpelx:preAssert>
</bpelx:preAsserts>

次の例に、BPEL 1.1におけるアサート前条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。

<invoke | reply>
    standard-elements
    <bpelx:preAssert name="NCName" expression="string" message="string"
    faultName="QName"/>
</invoke | reply>

次の例に、BPEL 1.1におけるアサート前条件の構文を示します。

<bpelx:preAssert name="Assert_1"
   expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') > 
   0"
   message='pre invoke assert NegativeInput fired'
   faultName="ns4:NegativeInput"/>

bpelx:postAssert拡張要素には、パートナからのコールバック・メッセージの受信時に評価するXPath式を指定します。アサーション式でfalseのブール値が返された場合は、指定のフォルトがアクティビティからスローされます。アサーション式でtrueのブール値が返された場合、フォルトはスローされず、通常のBPELプロセス・フローの場合と同様に、invokeアクティビティ、receiveアクティビティ、またはpickアクティビティとscopeアクティビティのonMessageブランチに続くアクティビティが実行されます。

bpelx:preAssertまたはbpelx:postAssert拡張要素は、Javaのassert文と同じです。Javaでは、assert式がtrueと評価されない場合は、JVMによってエラーが報告されます。同様に、bpelx:preAssertまたはbpelx:postAssert拡張要素の式もtrueと評価される必要があります。そうでない場合は、指定のフォルトがスローされます。

たとえば、次の例に示すBPEL 1.1のinvokeアクティビティでは、アサーション条件に指定したXPath式でfalseが返されると、NegativeCreditフォルトがスローされます。

<scope>
    <faultHandlers>
        <catch faultName="services:NegativeCredit" faultVariable="crError">
            <empty/>
        </catch>
    </faultHandlers>
    <sequence>
        <invoke name="invokeCR" partnerLink="creditRatingService"
                portType="services:CreditRatingService" operation="process"
                inputVariable="crInput" outputVariable="crOutput">
            <bpelx:postAssert name="negativeCredit"
 expression="$crOutput.payload/tns:rating > 0"
                          faultName="services:NegativeCredit" message="'Negative
 Credit'" />
        </invoke>
    </sequence>
</scope>

bpelx:preAssertまたはbpelx:postAssertのオプションのname属性は、監査証跡イベント・メッセージの作成時に使用されます。このインスタンスの名前を使用すると、複数のアサーションが指定されている場合にアサーション要素を識別できます。name属性の指定がない場合は、BPELファイル内のアサーション要素の行番号が使用されます。

12.15 再試行可能とのSOAPフォルトの分類

12c以降、外部サービスから返されたフォルト・コードに基づいて、すべてのWebサービスSOAPフォルトは自動的に再試行されません。フォルト・コードがサーバー関連(受信者関連とも呼ばれます)と分類された場合のみ、SOAPフォルトは再試行されます。クライアント関連と分類されたフォルト・コードでは、再試行が行われません。これは11gリリース1 (11.1.1.x)と異なります。そのリリースのOracle SOA Suiteではフォルト・コードに関係なくすべてのSOAPフォルトが再試行されました(返されるフォルトのすべてがbpelx:remoteFaultにBPELで変換され、再試行可能でした)。

12cでは、参照バインディング・コンポーネントでフォルトが発生すると、フォルト・コードがBPELプロセスに返されます。フォルト・コードの設定に基づいてフォルトが再試行されます。フォルトを特定の状況(システム停止時間問題など)でのみ再試行する場合があるので、これはメリットがあります。他のすべてのフォルト発生(正しくない入力など)では、再試行を行わない場合があります。実際、すべてのSOAPフォルトにおける再試行では、正当なメッセージの処理を遅らせることができます。

Simple Object Access Protocol (SOAP) 1.1仕様(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383510)に記載されているように、フォルトにはサーバー(受信者とも呼ばれます)またはクライアントのコードを持たせることができます。フォルトの分類により、フォルトが再試行できるかどうかが判別されます。

• サーバー

  メッセージの処理ではなくメッセージの内容に直接関連していない理由により、メッセージを処理できないことをサーバーのエラーが示します。たとえば、応答しなかったサーバーとの通信を処理に含めることができます。メッセージは後で成功する場合があります。これは再試行可能フォルトと定義されます。

• クライアント

  メッセージが適切に形成されていなかったり、成功するために適切な情報が格納されていなかったことをクライアントのエラーが示します。たとえば、メッセージに適切な認証や支払い情報が欠落している場合があります。これは一般的に、メッセージ再送前に最初に変更する必要があることを示します。これは再試行不能フォルトと定義されます。

このフォルト分類情報は、FabricInvocationExceptionエラーに伝播されます。クライアント関連と分類されたフォルト・コードでは、この例外内のretryTypeフラグがNO_RETRYに設定されます。

必要に応じて、再試行をすべてのフォルトで起動できます。composite.xmlファイルでbinding.wsプロパティのoracle.soa.always.retry.on.faultをtrueに設定します。これによって、フォルト・コードに関係なく、Oracle SOA SuiteではSOAPフォルトで必ず再試行できます。

<reference name="myreference"
. . . 
<binding.ws port=". . . ."
location=". . ."
<property name="oracle.soa.always.retry.on.fault">true</property>
</binding.ws>

composite.xmlの次のコード・スニペットを使用して、SOAで定義されたカスタム・ヘッダーを有効にしてOSB Webサービスにアクセスします。

<reference name="RecHttpOSB" ...>
	...      
		<binding.ws ... soapVersion="1.1"> 
			<property name="oracle.webservices.http.headers">OSBCustomHttp</property>
		</binding.ws>
</reference>