| Oracle Fusion Middleware Oracle SOA Suite開発者ガイド 11g リリース1（11.1.1） B56238-01 |
|
 戻る |
 次へ |
この章では、BPELプロセスのフォルト処理について説明します。 BPELプロセス・サービス・コンポーネントでは、フォルト処理を使用して、Webサービス外部から返されたエラー・メッセージやその他の例外を処理し、ビジネス・フォルトまたは実行時フォルトに応じてエラー・メッセージを生成できます。フォルト管理フレームワークを定義して、フォルトを捕捉したり、フォルト・ポリシー・ファイルに定義されているユーザー指定アクションを実行することもできます。
項目は次のとおりです。
SOAコンポジット・アプリケーションでのフォルト処理の作成方法の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteアプリケーションの作成および実行のためのチュートリアル』を参照してください。
フォルト・ハンドラは、通常予想される以外のデータ（数値のかわりにエラー・メッセージなど）がWebサービスから返されたときに、BPELプロセス・サービス・コンポーネントがどのように対応するかを定義します。フォルト・ハンドラの例として、Webサービスで通常返される信用格付けの数値のかわりに、ネガティブ情報メッセージが返された場合を想定します。
次の図は、フォルト・ハンドラが信用格付け変数を-1000に設定する方法の例を示しています。
例12-1のコード・セグメントは、この操作のフォルト・ハンドラをBPELファイルに定義します。
例12-1 フォルト・ハンドラの定義
<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サービスを選択する際、返される可能性があるフォルトを特定し、それぞれに対してフォルト・ハンドラを設定します。
「Business Process Execution Language for Web Services Specification」では、http://schemas.xmlsoap.org/ws/2003/03/business-process/のネームスペースに次の標準フォルトが定義されています。
bindingFault
conflictingReceive
conflictingRequest
correlationViolation
forcedTermination
invalidReply
joinFailure
mismatchedAssignmentFailure
remoteFault
repeatedCompensation
selectionFailure
uninitializedVariable
標準フォルトの定義は、次のとおりです。
タイプなし。つまり、messageTypesは関連付けられていません。
Web Services Description Language（WSDL）)メッセージには関連付けられていません。
次のようにフォルト変数なしで捕捉されます。
<catch faultName="bpws:selectionFailure">
BPELフォルトには、Qnameというフォルト名（ネームスペースで修飾された名前）と、可能性のあるmessageTypeがあります。BPELフォルトには次の2つのカテゴリがあります。
ビジネス・フォルト
実行時フォルト
ビジネス・フォルトはアプリケーション固有のフォルトであり、処理されている情報に問題がある場合（社会保障番号がデータベース内で見つからない場合など）に生成されます。ビジネス・フォルトは、アプリケーションがthrowアクティビティを実行したとき、またはinvokeアクティビティがレスポンスとしてフォルトを受け取った場合に発生します。ビジネス・フォルトのフォルト名はBPELプロセス・サービス・コンポーネントによって指定されます。このような場合、WSDLファイルにmessageTypeが定義されます。ビジネス・フォルトは、faultNameおよびfaultVariableを使用してfaultHandlerで捕捉できます。
<catch faultName="ns1:faultName" faultVariable="varName">
実行時フォルトは、BPELプロセス・サービス・コンポーネントまたはWebサービスの実行中に問題（変数名が正しくないためにデータを正しくコピーできないなど）が発生した結果です。この種のフォルトはユーザー定義ではなく、システムによりスローされます。 プロセスによる値の使用に誤りがある場合、論理エラーが発生する場合（無限ループなど）、SOAPコールでSimple Object Access Protocol（SOAP）フォルトが発生する場合、サーバーにより例外がスローされる場合などに生成されます。
様々な実行時フォルトが自動的に提供されています。これらのフォルトは、http://schemas.oracle.com/bpel/extensionネームスペースにあります。また、messageType RuntimeFaultMessageに関連付けられています。 例12-2に示すように、messageTypeはWSDLファイルに定義されます。
例12-2 messageType定義
<?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からフォルト・サマリーおよび詳細とともにフォルト・コードを問合せできます。
bindingFaultは、起動準備に失敗した場合にアクティビティ内でスローされます。たとえば、プロセスのWSDLのロードに失敗した場合などです。bindingFaultは再試行できません。通常、このタイプのフォルトは管理者操作により修正する必要があります。
Oracle SOA Suiteには、BPELプロセスのフォルトを処理するために一般的なフォルト管理フレームワークが用意されています。プロセスでinvokeアクティビティの実行時にフォルトが発生すると、そのフォルトはフレームワークによって捕捉され、フォルト・ポリシー・ファイルでそのアクティビティに関連付けられているユーザー指定のアクションが実行されます。 管理者操作が規定のアクションである状況でフォルトが発生した場合は、Oracle Enterprise Manager Fusion Middleware Controlコンソールからリカバリ・アクションを実行します。 フォルト管理フレームワークによって、scopeアクティビティのcatchアクティビティを使用してBPELプロセスを設計するための代替手段が提供されます。
この項では、フォルト管理フレームワークを構成する複数のコンポーネントの概要について説明します。
フォルト管理フレームワークでは、invokeアクティビティのすべてのフォルト（ビジネスおよび実行時）が捕捉されます。
フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。フォルト・ポリシー・ファイルでは一連のアクションがIDで識別されます。
一連の条件によってアクションが起動されます（フォルト・ポリシーとも呼ばれます）。
フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを次のものに関連付けます。
SOAコンポジット・アプリケーション
BPELプロセスとOracle Mediatorのサービス・コンポーネント
BPELプロセスとOracle Mediatorのサービス・コンポーネントの参照バインディング・コンポーネント
フォルト管理フレームワークでは、SOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリ、または設定した2つのプロパティで識別されるリモートの場所で、フォルト・ポリシー・バインディングを検索します。
|
注意: フォルト管理フレームワークで構成されるフォルト・ポリシーは、BPELプロセスのscopeアクティビティのcatchアクティビティに定義されるフォルト処理よりも優先されます。 フォルト管理フレームワークは、フォルト処理をcatchアクティビティに再スローするように構成できます。 |
フォルト・ポリシー・ファイル（fault-policies.xml）およびフォルト・ポリシー・バインディング・ファイル（fault-bindings.xml）は、次のいずれかの場所に格納されます。
SOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリ。
composite.xmlファイルに追加した2つのプロパティで指定された別の場所。このオプションは、1つのフォルト・ポリシーを複数のSOAコンポジット・アプリケーションで使用する必要がある場合に便利です。このオプションは、composite.xmlファイルと同じディレクトリに格納されているフォルト・ポリシー・ファイルよりも優先されます。 例12-3に、この2つのプロパティの詳細を示します。 この例では、フォルト・ポリシー・ファイルはSOAメタデータ・サービス（MDS）共有領域に配置されています。
Oracle Mediatorフォルト処理機能の詳細は、第20章「メディエータ・エラー処理の使用」を参照してください。
この項では、フォルト・ポリシーの設計方法について説明します。
|
注意: Facades APIを使用すると、強制終了、再試行（および成功時アクション）、続行、再スローおよび再実行の各リカバリ・オプションをプログラムによって実行できます。 |
フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーをSOAコンポジット・アプリケーションまたはコンポーネント（サービス・コンポーネントまたは参照バインディング・コンポーネント）に関連付けます。フォルト管理フレームワークでは、次の順序でフォルト・ポリシー・バインディングの識別が試みられます。
composite.xmlファイルに定義されている参照バインディング・コンポーネント。
composite.xmlファイルに定義されているBPELプロセスまたはOracle Mediatorのサービス・コンポーネント。
composite.xmlファイルに定義されているSOAコンポジット・アプリケーション。
解決する過程で条件に適したアクションが見つからない場合、フォルト管理フレームワークでは、その解決は失敗とみなされ、次の解決レベルに移動します。
たとえば、invokeアクティビティがfaultname="abc"で失敗となった場合を考えてみます。 fault-binding.xmlファイルには、次のポリシー・バインディングが指定されているとします。
policy-id-1へのSOAコンポジット・アプリケーションのバインド
policy-id-2へのBPELプロセス/Oracle Mediatorサービス・コンポジットまたは参照バインディング・コンポーネントのバインド
また、fault-bindings.xmlファイルには、次のバインディングも指定されているとします。
policy-id-3へのSOAコンポジット・アプリケーションのバインド
policy-id-4への参照バインディング・コンポーネントまたはサービス・コンポーネントのバインド
フォルト管理フレームワークは、次のように動作します。
最初に、解決バインディング（この場合はpolicy-id-2）と照合します。
フォルトの解決に失敗した場合は、可能な次の照合（policy-id-4との照合）に進みます。
フォルトの解決に失敗した場合は、可能な次の照合（policy-id-3との照合）に進みます。
フォルトの解決に失敗した場合は、可能な次の照合（この場合はpolicy-id-1との照合）に進みます。
フォルトが解決していない場合、そのフォルトはBPELフォルトcatchアクティビティに送信されます。
フォルト・ポリシー・ファイルを（たとえば、fault-policies.xmlなどの名前で）作成します。このファイルには、特定のタスクを実行するためのconditionセクションとactionセクションを挿入します。
このファイルをcomposite.xmlファイルと同じディレクトリまたは別の場所に格納してoracle.composite.faultPolicyFileプロパティを定義します。 例12-4に詳細を示します。
フォルト・ポリシー・ファイルのconditionセクションを定義します。
このconditionセクションについては、次の点に注意してください。
このセクションには、faultNameに基づいて条件を指定します。
faultNameには、複数の条件を構成できます。
各条件には、1つのtestセクション（XPath式）と1つのactionセクションがあります。
testセクション（XPath式）は、フォルト時に使用可能なフォルト変数に対して評価されます。
actionセクションには、同じファイルに定義されているアクションへの参照があります。
問い合せることができるのは、フォルト時に使用可能なフォルト変数のみです。
条件の評価順序は、ドキュメントに記載されている順序によって決まります。
表12-1に、フォルト・ポリシー・ファイルで使用するconditionセクションの例を示します。conditionセクションで定義される全アクションは、actionセクションにおけるアクションに関連付けられる必要があります。
表12-1 フォルト・ポリシー・ファイルでのconditionセクションの使用
| 条件の例 | フォルト・ポリシー・ファイルの構文 |
|---|---|
|
この条件は、
|
<condition> <test>$fault.code="WSDLReading Error" </test> <action ref="ora-terminate"/> </condition> |
|
|
<condition> <action ref="ora-rethrow"/> </condition> |
|
|
<faultName > . . . </faultName> |
フォルト・ポリシー・ファイルのactionセクションを定義します。フォルト・ポリシー・ファイルの検証は、デプロイメント時に実施されます。フォルト・ポリシーを変更する場合は、フォルト・ポリシーが含まれているSOAコンポジット・アプリケーションを再デプロイする必要があります。
表12-2に、フォルト・ポリシー・ファイルで使用するactionセクションの例を示します。一部のフォルトには、自動リカバリ・アクションを指定できます。再試行と管理者操作を除くすべてのリカバリ・アクションでは、複数のアクションが同時に実行されます。
表12-2 フォルト・ポリシー・ファイルでのactionセクションの使用
| リカバリ・アクション | フォルト・ポリシー・ファイルの構文 |
|---|---|
|
再試行: アクティビティを再試行するために、次のアクションが用意されています。
注意: 指数バックオフでは、次の再試行が |
<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クラスを実行できます。
詳細は、第12.4.3項「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など）は、単なるサンプルです。これらの名前は各自の環境に適した名前に置換できます。 |
例12-5に、conditionセクションとactionセクションが完全に定義されているフォルト・ポリシー・ファイルを示します。
|
注意:
|
<?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="0.0.1" id="FusionMidFaults"
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 xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<action ref="MediatorJavaAction"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:remoteFault">
<condition>
<action ref="BPELJavaAction"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:bindingFault">
<condition>
<action ref="BPELJavaAction"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:runtimeFault">
<condition>
<action ref="BPELJavaAction"/>
</condition>
</faultName>
</Conditions>
<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="MediatorJavaAction">
<!-- this is user provided class-->
<javaAction className="MediatorJavaAction.myClass"
defaultAction="default-terminate">
<returnValue value="MANUAL" ref="default-human-intervention"/>
</javaAction>
</Action>
<Action id="BPELJavaAction">
<!-- this is user provided class-->
<javaAction className="BPELJavaAction.myAnotherClass"
defaultAction="default-terminate">
<returnValue value="MANUAL" ref="default-human-intervention"/>
</javaAction>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>
|
注意: フォルト・ポリシー・ファイルのバインディング・ファイルには、fault-bindings.xmlという名前が必要です。これは、fault-bindings.xsdスキーマ・ファイルに準拠しています。 |
フォルト・ポリシー・バインディング・ファイル（fault-bindings.xml）を作成します。このファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを、使用しているフォルト・ポリシー・バインディング（SOAコンポジット・アプリケーションまたはコンポーネント（参照バインディング・コンポーネントまたはBPELプロセス/Oracle Mediatorのサービス・コンポーネント）のいずれか）のレベルに関連付けます。
前の項の手順2で示したように、ファイルをcomposite.xmlファイルと同じディレクトリまたは別の場所に格納してoracle.composite.faultBindingFileプロパティを定義します。
例12-6に、fault-policies.xmlファイルに定義されているフォルト・ポリシーをFusionMidFaults SOAコンポジット・アプリケーションに関連付けるフォルト・ポリシー・バインディング・ファイルを示します。
例12-6 fault-buildings.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-7にfault-policies.xmlファイルの内容を示します。
例12-7 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">
<!-- we get this fault when SSN starts with 0-->
<condition>
<test>$fault.payload="Bankruptcy Report"</test>
<action ref="ora-human-intervention"/>
<!--action ref="ora-retry"/-->
</condition>
<!-- we get this fault when SSN starts with 1-->
<condition>
<test>$fault.payload="Bankruptcy Report-abort"</test>
<action ref="ora-terminate"/>
</condition>
<!-- we get this fault when SSN starts with 2-->
<condition>
<test>$fault.payload="Bankruptcy Report-rethrow"</test>
<action ref="ora-rethrow-fault"/>
</condition>
<!-- we get this fault when SSN starts with 3-->
<condition>
<test>$fault.payload="Bankruptcy Report-replay"</test>
<action ref="ora-replay-scope"/>
</condition>
<!-- we 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>
<!-- we 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">joe@abc.com</property>
<property name="email_recipient">mike@xyz.com</property>
<property name="email_threshold">10</property>
<property name="sms_recipient">+429876547</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">john@abc.com</property>
<property name="email_recipient">jill@xyz.com</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>
例12-8に、fault-policies.xmlに定義されているフォルト・ポリシーを関連付けるfault-buildings.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>
拒否メッセージのアクション・ハンドラを使用するフォルト・ポリシーを設計する際は、実行できる書込みアクションが1つのみであることに注意してください。 例12-9に示すように、複数の拒否ハンドラを定義している場合も、複数の書込みアクションは実行できません。 この場合、定義されている最初の拒否ハンドラ（この例ではora-queue）のみが実行されます。
例12-9 複数の拒否ハンドラがあるフォルト・ポリシー
<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>
フォルト・ポリシーは、SOAコンポジット・アプリケーションの一部としてデプロイします。 デプロイメント後は、次のフォルト・リカバリ・アクションをOracle Enterprise Manager Fusion Middleware Controlコンソールから実行できます。
アクティビティの再試行
変数の変更（フォルトが発生したアクティビティに使用可能）
インスタンスの続行（アクティビティを成功としてマーク）
例外の再スロー
インスタンスの強制終了
スコープの再実行例外のスロー
次の情報の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlコンソールでのフォルト・ポリシーの実行に関する説明
管理者操作を使用するフォルト・ポリシーの定義のユースケース
Javaアクション・フォルト・ポリシーを使用する際は、次の点に注意してください。
用意されているJavaクラスは、特定のインタフェースに従っています。このインタフェースは文字列を戻します。実行後に取得する出力とフォルト・ポリシーには、複数の値を指定できます。
実装されているメソッドの出力値（戻り値）からフォルト・ポリシーへのマッピングを指定することで、追加のフォルト・ポリシーを実行できます。
ReturnValueが指定されていない場合は、例12-10に示すように、デフォルトのフォルト・ポリシーが実行されます。
例12-10 Javaアクション・フォルト・ポリシー
<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-3に、ReturnValueの使用例を示します。
表12-3 システムによるJavaアクション・フォルト・ポリシーの解釈
| コード | 説明 |
|---|---|
<ReturnValue value="RETRY" ref="ora-retry"/> |
メソッドから |
<ReturnValue value="” ref=”ora-rethrow”/> |
検証は失敗です。 |
<JavaAction ClassName="mypackage.myclass" defaultAction="ora-human-intervention"> |
Javaコード実行後に |
<ReturnValue value="RETRY" ref="ora-retry"/> <ReturnValue value="” ref=””/> |
検証は失敗です。 |
<JavaAction ClassName="mypackage.myclass" defaultAction=" ora-human-intervention"> <ReturnValue></ReturnValue> |
検証は失敗です。 |
Javaクラスを起動するには、IFaultRecoveryJavaClassインタフェースを実装しているクラスを指定できます。 例12-11に示すように、このインタフェースには2つのメソッドがあります。
例12-11 IFaultRecoveryJavaClassの実装
public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess( IFaultRecoveryContext ctx );
public String handleFault( IFaultRecoveryContext ctx );
}
次の点に注意してください。
handleRetrySuccessは、再試行に成功した場合に起動されます。再試行ポリシーは、retrySuccessActionのJavaアクションにチェーンします。
handleFaultは、javaActionタイプのポリシーを実行する際に起動されます。
例12-12にIFaultRecoveryContextで使用可能なデータを示します。
例12-12 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）。 例12-13に詳細を示します。
例12-13 IFaultRecoveryContextのサービス・エンジン実装
public class BPELFaultRecoveryContextImpl extends BPELXExecLetUtil implements
IBPELFaultRecoveryContext, IFaultRecoveryContext{
...
}
例12-14に示すように、Oracle BPEL Process Manager固有のデータは、IBPELFaultRecoveryContextを使用して入手できます。
例12-14 Oracle BPEL Process Manager固有のデータ
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;
}
例12-15に、javaActionの実装例を示します。
例12-15 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());
...
}
インスタンスをリカバリするフォルト・ポリシーを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アクティビティが再実行されます。追加の監査メッセージが記録されます。
アウトバウンド方向のJCAレベルの再試行とフォルト・ポリシー・ファイル内の再試行アクションの両方を備えたアダプタで、アウトバウンド障害に対する再試行アクションをテストしている場合は、そのJCAレベル（またはバインディング・レベル）再試行がフォルト・ポリシー再試行の中で実行されます。 たとえば、図12-2に示すアプリケーションを設計したとします。
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秒間隔）
BPEL実行時フォルトは、名前付きのBPELフォルトとして捕捉できます。bindingFaultおよびremoteFaultはメッセージに関連付けることができます。 このアクションにより、faultHandlerでフォルトの詳細を取得できます。
次の手順は、与えられた例を使用して、フォルトを生成し、それを捕捉するためのフォルト・ハンドラを定義する方法を示します。ここでは、WSDLファイルを変更してフォルトを生成し、捕捉するためのcatch属性を作成します。
BPEL実行時フォルトを捕捉する手順は、次のとおりです。
RuntimeFault.wsdlをプロセスWSDLにインポートします。 RuntimeFault.wsdlは、そのデプロイメント時にsoa-infra-wls.ear内のsoa.marからMDSにシードされます。Oracle WebLogic ServerドメインにデプロイされたSOAインフラストラクチャには、RuntimeFault.wsdlが格納されているJAR/ZIPファイルsoa.marのコピーが表示されます。
messageType "bpelx:RuntimeFaultMessage"を使用して変数を宣言します。
次の構文を使用して捕捉します。
<catch faultName="bpelx:remoteFault" | "bpelx:bindingFault" faultName="varName">
可能なフォルトを捕捉できるようにcatchAllアクティビティが用意されています。ただし、BPELには、取得されたフォルトの詳細情報を取得するためのメソッドが用意されていません。詳細情報を取得するにはgetFaultAsString() XPath拡張関数を使用します。
BPELアプリケーションでは、フォルト・メッセージの生成および受取りができます。 throwアクティビティには3つの要素（それ自体の名前、フォルトの名前およびフォルト変数）があります。 throwアクティビティをBPELプロセス・サービス・コンポーネントに追加した場合、フォルト名とタイプを出力ペイロードにコピーするコピー・ルールが自動的に挿入されます。throwアクティビティによってスローされるフォルトはBPEL内部のフォルトです。throwアクティビティは、クライアントと通信する非同期プロセスには使用できません。
throwアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」から、デザイナにthrowアクティビティをドラッグします。
throwアクティビティをダブルクリックして定義します。
名前を入力するか、デフォルト値をそのまま使用します。
「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、監視するフォルトを選択します。
「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。
選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。 選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。
図12-3に、完成した「Throw」ダイアログの例を示します。 この例では、WebLogic Fusion Order Demoアプリケーションの「Scope_AuthorizeCreditCard」scopeアクティビティの「Throw_Fault_CC_Denied」throwアクティビティが表示されています。 このアクティビティは、承認されない注文に対してフォルトをスローします。
「OK」をクリックします。
例12-17に、設計完了後の.bpelファイルのthrowアクティビティを示します。 このthrowアクティビティの実行後にOrderProcessorプロセスが終了します。
BPELプロセス・サービス・コンポーネントは、内部フォルトのスローとは対照的に、別のアプリケーションにフォルトを送信して問題を提示できます。同期操作では、replyアクティビティがフォルトを返すことができます。非同期操作では、invokeアクティビティがこの機能を実行します。
例12-18に、同期相互作用でフォルトを返すreplyアクティビティの構文を示します。
例12-18 replyアクティビティ
<reply partnerlinke="partner-link-name" portType="port-type-name" operation="operation-name" variable="variable-name" (optional) faultName="fault-name"> </reply>
同期リクエストに対して常にフォルトを返すことはあまり有効ではありません。それよりも、アクティビティを条件分岐に組み込み、リクエストされたデータを使用できる場合に最初のブランチが実行されるようにするほうが効果的です。リクエストされたデータを使用できない場合、BPELプロセス・サービス・コンポーンネントはそのことを示すフォルトを返します。
詳細は、次の章を参照してください。
条件構造の設定については、第11章「BPELプロセスでの条件分岐の使用」を参照してください。
同期相互作用については、第8章「BPELプロセスからの同期Webサービスの起動」を参照してください。
非同期相互作用では、クライアントはリプライを待機しません。このため、フォルトを返すためにreplyアクティビティが使用されることはありません。かわりに、BPELプロセス・サービス・コンポーネントは通常はリクエストされた情報を受け取る同じポート・タイプのコールバック操作を使用して、invokeアクティビティによってフォルトを返します。
非同期相互作用の詳細は、第9章「BPELプロセスからの非同期Webサービスの起動」を参照してください。
scopeアクティビティは、他のアクティビティに対してコンテナおよびコンテキストを提供します。scopeは、フォルト、イベント、補正、データ変数および相関セットに対するハンドラを提供します。 scopeアクティビティを使用すると、機能構造をグループ化することでBPELフローが単純化されます。 このグループ化により、Oracle BPELデザイナでは機能構造を閉じて1つの要素として表示できます。
例12-19に、WebLogic Fusion Order DemoアプリケーションのScope_FulfillOrderという名前のscopeを示します。 このscopeは、注文品の出荷方法を判断するFulfillOrderメディエータ・コンポーネントを起動します。
例12-19 scopeアクティビティ
<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>
scopeアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」から、デザイナにscopeアクティビティをドラッグします。
scopeアクティビティをダブルクリックするか、「拡張」記号を1回クリックして、アクティビティを開きます。
「コンポーネント・パレット」から各アクティビティをドラッグして定義し、スコープ内に機能を作成します。
「OK」をクリックします。
完了すると、scopeアクティビティの設計は次のようになります。 この例では、WebLogic Fusion Order Demoアプリケーションの「Scope_AuthorizeCreditCard」scopeアクティビティが表示されています。
例12-20に、設計完了後の.bpelファイルのthrowアクティビティを示します。 Scope_AuthorizeCreditCard scopeアクティビティは、次のアクションを実行する各アクティビティで構成されています。
クレジット・カード番号がない、またはクレジット・タイプが有効でないためにフォルトになった注文を捕捉するcatchアクティビティ。
承認されない注文に対してフォルトをスローするthrowアクティビティ。
クレジット・カード・タイプ、クレジット・カード番号および購入金額を取得し、それらをCreditCardAuthorizationServiceサービスの入力変数に割り当てるassignアクティビティ。
CreditCardAuthorizationServiceサービスをコールして顧客情報を取得するinvokeアクティビティ。
クレジット・カード検証の結果を確認するswitchアクティビティ。
例12-20 scopeアクティビティ
<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 <> approved</bpelx:pattern>
</bpelx:annotation>
<throw name="Throw_Fault_CC_Denied"
faultName="client:OrderProcessorFault"/>
</case>
/switch>
</sequence>
</scope>
スコープは、CPU能力とメモリーを大量に使用する可能性があるため、過度の使用は避けてください。 sequenceアクティビティを使用することで、CPUとメモリーの使用量を抑制し、大きいBPELフローを見やすくできます。
フォルトが処理されていない場合、フォルト状態が作成されてアプリケーション全体に移行し、プロセス全体がフォルト状態になることがあります。これを防ぐには、フォルトを受け取る可能性があるプロセスの一部をスコープ内に含めます。 scopeアクティビティには、次のフォルト処理機能が含まれています。
スコープ内ではcatchアクティビティが動作し、プロセス全体がフォルト状態になる前に、フォルトおよび例外を捕捉します。catchアクティビティで特定のフォルト名を使用し、個々のフォルトに特定の方法で対応できます。
catchAllアクティビティは、名前が指定されたcatchアクティビティでは処理されないフォルトを捕捉します。
例12-21に、catchおよびcatchAllアクティビティの構文を示します。x:fooという名前のフォルトがスローされたとします。フォルトがフォルト・データを渡さない場合は、最初のcatchが選択されます。フォルトに関連付けられたフォルト・データがある場合、フォルトのデータ・タイプが変数barのタイプに一致すると、3番目のcatchが選択されます。一致しない場合は、デフォルトのcatchAllハンドラが選択されます。最後に、タイプがbarのタイプに一致し、名前がx:fooでないフォルト変数を持つフォルトは2番目のcatchで処理されます。その他のすべてのフォルトはデフォルトのcatchAllハンドラによって処理されます。
catchアクティビティを作成する手順は、次のとおりです。
開いたscopeアクティビティで、「Catchブランチの追加」をクリックします。
これにより、scopeアクティビティの右側にcatchアクティビティが作成されます。
catchアクティビティをダブルクリックします。
必要に応じて名前を入力します。
「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、フォルトを選択します。
「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。
選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。 選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。
図12-7に、「Catch」ダイアログの例を示します。 この例では、WebLogic Fusion Order Demoアプリケーションの「Scope_AuthorizeCreditCard」scopeアクティビティの「selectionFailure」catchアクティビティが表示されています。 このcatchアクティビティは、クレジット・カード番号がない注文を捕捉します。
追加のフォルト処理機能を設計します。
「OK」をクリックします。
図12-8に、「Scope_AuthorizeCreditCard」scopeアクティビティに2つのcatchアクティビティがある例を示します。 2番目のcatchアクティビティは、有効でないクレジット・タイプを捕捉します。
例12-8に、設計完了後の.bpelファイルのcatchアクティビティを示します。 selectionFailure catchアクティビティはクレジット・カード番号がない注文を捕捉し、InvalidCredit catchアクティビティは有効でないクレジット・タイプを捕捉します。
例12-22 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>
何もしないアクティビティが必要になることがよくあります。たとえば、フォルトを捕捉して抑制する必要がある場合などです。 この場合、emptyアクティビティを使用すると、操作なしの命令をビジネス・プロセスに挿入できます。
emptyアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」から、デザイナにemptyアクティビティをドラッグします。
emptyアクティビティをダブルクリックします。
図12-9に示すように、「Empty」ダイアログが表示されます。
必要に応じて名前を入力します。
「OK」をクリックします。
例12-23に、emptyアクティビティの構文を示します。
catchまたはcatchAllが選択されていない場合、フォルトが現在のスコープによって捕捉されず、すぐ外側を囲んでいるスコープにスローされます。グローバル・プロセス・スコープでフォルトが発生し（またはグローバル・プロセス・スコープに再スローされ）、グローバル・レベルでフォルトに適合するフォルト・ハンドラがない場合、プロセスが異常終了します。 これは、terminateアクティビティ（第12.11項「terminateアクティビティによるビジネス・プロセス・インスタンスの停止」で説明）が実行されたような状況になります。
補正は、BPELプロセス・サービス・コンポーネントが一部の操作を完了した後で一連の操作を完了できず、引き返して前に完了したトランザクションを取り消す必要がある場合に発生します。たとえば、レンタカー、ホテルおよび航空券を予約するようにBPELプロセス・サービス・コンポーネントが設計されている場合、車とホテルは予約でき、その日付の航空券を予約できない場合があります。この場合、BPELフローは戻って車とホテルをキャンセルすることによって、補正を実行します。
補正ハンドラは、compensateアクティビティを使用することによって起動でき、補正が実行されるスコープ（補正ハンドラが起動されるスコープ）を指定します。スコープの補正ハンドラは、スコープが正常に完了した場合にのみ起動できます。インストールされていない補正ハンドラを起動することは、emptyアクティビティ（操作なし）を使用することと同じです。これにより、フォルト・ハンドラは、ネストされたどのスコープが正常に完了したかを判断するために、状態を使用しなくても済むようになります。 インストールされた補正ハンドラが複数回起動されているプロセスのセマンティクスは定義されていません。
明示的にcompensateアクティビティを起動する機能は、アプリケーション制御のエラー・ハンドリング・フレームワークであるBusiness Process Execution Language for Web Services Specificationの基礎となる機能です。このアクティビティは、ビジネス・プロセスの次の部分でのみ使用できます。
スコープのすぐ外側を囲んでいるスコープのフォルト・ハンドラでは、補正が実行されます。
スコープのすぐ外側を囲んでいるスコープの補正ハンドラでは、補正が実行されます。
次に例を示します。
<compensate scope="RecordPayment"/>
名前によって補正されているスコープがループでネストされている場合、BPELプロセス・サービス・コンポーネントは一連の反復内で補正ハンドラ・インスタンスを逆の順序で起動します。
スコープの補正ハンドラがない場合、デフォルトの補正ハンドラは、すぐ内側に囲まれているスコープの補正ハンドラを、これらのスコープの完了と逆の順序で起動します。
補正フォームでcompensateアクティビティのスコープ名が省略されると、このデフォルトの動作が明示的に起動されます。これは、囲んでいるフォルトまたは補正ハンドラで追加の作業（変数の更新や外部通知の送信、および内側のスコープに対するデフォルト補正の実行など）を実行する必要がある場合に便利です。外側のスコープに付加されたフォルトまたは補正ハンドラのcompensateアクティビティにより、そのスコープ内に直接ネストされた完了スコープに対する補正ハンドラがデフォルトの順序で起動されます。このアクティビティは、外側のスコープ内にネストされたスコープの明示的な起動を除く、その他のユーザー指定の動作と一緒に使用できます。外側のスコープ内にネストされたこのスコープの補正を明示的に起動すると、デフォルトの順序の補正は、適切に機能しません。
compensateアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」から、デザイナにcompensateアクティビティをドラッグします。
compensateアクティビティをダブルクリックします。
補正ハンドラを起動するscopeアクティビティを選択します。
「OK」をクリックします。
invokeアクティビティにインラインで定義された補正ハンドラがある場合、アクティビティの名前はcompensateアクティビティに使用されるスコープの名前です。 例12-24に構文を示します。
terminateアクティビティは、そのterminateアクティビティが実行されるビジネス・プロセス・インスタンスの動作をただちに終了します。現在実行中のすべてのアクティビティは、フォルト処理または補正動作を実行せずにできるだけ早く終了する必要があります。terminateアクティビティは、BPELプロセス・サービス・コンポーネントのステータスの通知を送信しません。terminateアクティビティを使用する場合は、先に関係ユーザーに通知するようにプログラムしてください。
terminateアクティビティを作成する手順は、次のとおりです。
Oracle JDeveloperの「コンポーネント・パレット」から、デザイナにterminateアクティビティをドラッグします。図12-11に例を示します。
terminateアクティビティをダブルクリックします。
必要に応じて名前を入力します。
「OK」をクリックします。
例12-25に、terminateアクティビティの構文を示します。 このアクティビティによってビジネス・プロセス・インスタンスが停止します。
