| Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド 11g リリース1 (11.1.1.7) B56238-08 |
|
 前 |
 次 |
この章では、BPELプロセスのフォルト処理について説明します。BPELプロセス・サービス・コンポーネントでは、フォルト処理を使用して、Webサービス外部から返されたエラー・メッセージやその他の例外を処理し、ビジネス・フォルトまたは実行時フォルトに応じてエラー・メッセージを生成できます。この章では、フォルト管理フレームワークを使用して、フォルトを捕捉したり、フォルト・ポリシー・ファイルに定義されているユーザー指定のアクションを実行する方法についても説明します。
この章には次の項が含まれます:
SOAコンポジット・アプリケーションでのフォルト処理の作成方法の詳細は、第3章「SOAサンプル・アプリケーションの概要」で説明されているFusion Order Demoアプリケーションを参照してください。
フォルト・ハンドラは、通常予想される以外のデータ(数値のかわりにエラー・メッセージなど)がWebサービスから返されたときに、BPELプロセス・サービス・コンポーネントがどのように対応するかを定義します。フォルト・ハンドラの例として、Webサービスで通常返される信用格付けの数値のかわりに、ネガティブ情報メッセージが返された場合を想定します。
図12-1は、フォルト・ハンドラが信用格付け変数を-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サービスを選択する際、返される可能性があるフォルトを特定し、それぞれに対してフォルト・ハンドラを設定します。
この項では、BPEL 1.1およびBPEL 2.0の標準フォルトを識別します。
この項では、BPEL 1.1の標準フォルトを識別します。特に指定がないかぎり、「Business Process Execution Language for Web Services Specification Version 1.1」は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
標準フォルトの定義は、次のとおりです。
タイプなし。つまり、messageTypesは関連付けられていません。
Web Services Description Language(WSDL)メッセージには関連付けられていません。
次のようにフォルト変数なしで捕捉されます。
<catch faultName="bpws:selectionFailure">
次のリストは、WS-BPEL仕様内で定義されている標準フォルトを指定します。標準フォルト名はすべて、標準のWS-BPELネームスペースで修飾されます。
ambiguousReceive
completionConditionFailure
conflictingReceive
conflictingRequest
correlationViolation
invalidBranchCondition
invalidExpressionValue
invalidVariables
joinFailure
mismatchedAssignmentFailure
missingReply
missingRequest
scopeInitializationFailure
selectionFailure
subLanguageExecutionFault
uninitializedPartnerRole
uninitializedVariable
unsupportedReference
xsltInvalidSource
xsltStylesheetNotFound
BPEL 2.0の場合、関連するデータなしでスローされたフォルトを捕捉するための優先順位は次のとおりです。
一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。
catchAllアクティビティがある場合、フォルトはcatchAllフォルト・ハンドラに送信されます。
それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。
BPEL 2.0の場合、関連するデータとともにスローされたフォルトを捕捉するための優先順位は次のとおりです。
一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。
フォルト・データが、次のものを含むWSDLメッセージ・タイプの場合:
メッセージには、要素で定義された単一パーツが含まれます。
一致するfaultName値を持つcatchアクティビティが存在し、そのfaultName値にはfaultVariableがあります。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フォルト・ハンドラに送信されます。
それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。
BPELフォルトには、Qnameというフォルト名(ネームスペースで修飾された名前)と、可能性のあるmessageTypeがあります。BPELフォルトには次の2つのカテゴリがあります。
ビジネス・フォルト
実行時フォルト
ビジネス・フォルトはアプリケーション固有のフォルトであり、処理されている情報に問題がある場合(社会保障番号がデータベース内で見つからない場合など)に生成されます。ビジネス・フォルトは、アプリケーションがthrowアクティビティを実行したとき、またはinvokeアクティビティがレスポンスとしてフォルトを受け取った場合に発生します。ビジネス・フォルトのフォルト名はBPELプロセス・サービス・コンポーネントによって指定されます。該当する場合は、messageTypeが、WSDLファイルで定義されます。ビジネス・フォルトは、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は再試行できません。通常、このタイプのフォルトは管理者操作により修正する必要があります。
この項では、同期BPELプロセスでのフォルト処理の追加および伝播方法について説明します。設計中に、次のタスクを実行します。
既存のスキーマおよびWSDLファイルを変更し、フォルト要素、フォルト・メッセージおよびフォルト操作の詳細を含めます。
BPELプロセスにフォルト処理を追加します(具体的にはcatchアクティビティ)。
WSDLファイルに指定したフォルト・メッセージ・タイプでフォルト変数を作成します。
assignおよびreplyアクティビティを、追加のフォルト処理詳細とともに追加します。
スキーマおよびWSDLファイルを編集する手順は、次のとおりです。
「BPELプロセスの作成」ダイアログでデフォルト設定を使用して同期BPELプロセス(この例では、TestProcessという名前)を作成します。
アプリケーション・ナビゲータのxsdフォルダで、TestProcess.xsdファイルをダブルクリックします。
「ソース」ビューをクリックし、processFaultという新しい要素を追加します。
<element name="processFault">
<complexType>
<sequence>
<element name="result" type="string"/>
</sequence>
</complexType>
</element>
アプリケーション・ナビゲータで、TestProcess.wsdlファイルをダブルクリックします。
「ソース」ビューをクリックし、TestProcessFaultMessageという新しいメッセージ・タイプを追加します。
<wsdl:message name="TestProcessFaultMessage">
<wsdl:part name="payload" element="client:processFault"/>
</wsdl:message>
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>
「File」メニューから、「Save」を選択します。
フォルト・ハンドラを追加する手順は、次のとおりです。
アプリケーション・ナビゲータで、TestProcess.bpelをダブルクリックします。
BPELプロセスで「Catchの追加」アイコンをクリックし、そのBPELプロセスのフォルト・ハンドラとしてcatchアクティビティを追加します。CatchAllアクティビティを使用することもできます。図12-2に詳細を示します。
catchアクティビティをダブルクリックし、システム・フォルトを指定します。図12-3に詳細を示します。
このシステム・フォルトをトリガーするassertアクティビティはありません。それを追加して入力フィールドをアサートできます。
「ネームスペースURI」フィールドで、「参照」アイコンをクリックします。
「フォルト・チューザ」ダイアログが表示されます。
システム・フォルト(この例では、assertFailure)を選択し、「OK」をクリックします。選択可能なシステム・フォルトが他にも多数あります。図12-4に詳細を示します。
catchの編集ダイアログに戻ります。
「フォルト変数」フィールドで、 「変数の作成」アイコンをクリックします。
「変数の作成」ダイアログが表示されます。
FaultVarの名前およびRuntimeFaultMessageタイプの変数が作成されます。図12-5に詳細を示します。
RuntimeFault.wsdlファイルを「SOAコンテンツ」フォルダにコピーします。これは、BPELプロセスWSDLファイルと同じ場所です。
「OK」をクリックし、catchの編集ダイアログで「OK」をクリックします。
フォルト・レスポンス変数を作成する手順は、次のとおりです。
「構造」ウィンドウで、「変数」フォルダを右クリックし、「変数の作成」を選択します。
「名前」フィールドで、Faultresponseと入力します。
「メッセージ・タイプ」を選択します。
「メッセージ・タイプ」フィールドの「参照」アイコンをクリックします。
「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「TestProcess.wsdl」→「メッセージ・タイプ」→「TestProcessFaultMessage」の順に開き、「OK」をクリックします。図12-6に詳細を示します。
「変数の作成」ダイアログで「OK」をクリックします。
Catch Activityブランチにassignアクティビティを追加する手順は、次のとおりです。
assignアクティビティを、catchアクティビティ・ブロックにドラッグします。
assignアクティビティをダブルクリックします。
FaultVar変数のcode、summaryおよびdetailの各フィールドをFaultResponse変数に連結し、「OK」をクリックします。図12-7に詳細を示します。
「一般」タブの「名前」フィールドで、名前(この例では、FaultDataForClient)を入力します。
Catch Activityブランチにreplyアクティビティを追加する手順は、次のとおりです。
catchアクティビティ・ブロック内のAssignアクティビティの下にあるReplyアクティビティをドラッグします。
replyアクティビティをダブルクリックします。
「ネームスペースURI」フィールドで、「参照」アイコンをクリックします。
「フォルト・チューザ」ダイアログが表示されます。
「プロジェクトのWSDLファイル」→「TestProcess.wsdl」を開き、FaultResponseという名前のフォルトを選択します。図12-8に詳細を示します。
「名前」フィールドに、名前を入力します(この例ではReplyWithFault)。
「パートナ・リンク」フィールドで、「参照」アイコンをクリックします。
「パートナ・リンク・チューザ」ダイアログが表示されます。
replyOutput replyアクティビティが接続されている同じパートナ・リンクを選択し、「OK」をクリックします。
「変数」フィールドの「参照」アイコンをクリックします。
「変数チューザ」ダイアログが表示されます。
FaultResponse変数を選択し、「OK」をクリックします。図12-9に詳細を示します。
replyの編集ダイアログで、「OK」をクリックします。
BPELプロセスは図12-10のようになります。両方のreplyアクティビティが、同じパートナ・リンクに接続されます。
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つのプロパティの詳細を示します。この例では、フォルト・ポリシー・ファイルが、Oracle Metadata Services (MDS)リポジトリの共有領域のSOA部分に配置されます。
Oracle Mediatorのフォルト処理機能の詳細は、第22章「Oracle Mediatorエラー処理の使用」を参照してください。
Oracle Business Process Management (BPM) Suiteでのフォルト・ポリシーの作成の詳細は、『Oracle Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド』の「BPMでのフォルト処理の使用方法」の章を参照してください。
この項では、フォルト・ポリシーの設計方法について説明します。
|
注意: Facade APIを使用すると、中断、再試行(成功時アクションを含む)、続行、再スローおよび再生回復の各オプションをプログラムによって実行できます。詳細は、Oracle Fusion MiddlewareのOracle SOA Suite Infrastructure Management Java 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プロパティを定義します。
<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>
フォルト・ポリシー・ファイルの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> |
|
注意: あらかじめシードされているリカバリ・アクションのタグ名( |
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)を作成します。このファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを、使用しているフォルト・ポリシー・バインディング(SOAコンポジット・アプリケーションまたはコンポーネント(参照バインディング・コンポーネントまたはBPELプロセス/Oracle Mediatorのサービス・コンポーネント)のいずれか)のレベルに関連付けます。
第12.4.1.2項「自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの作成」のステップ2に示すように、composite.xmlファイルと同じディレクトリにファイルを置くか、ファイルをリモートの場所に置いてoracle.composite.faultBindingFileプロパティを定義します。
このフォルト・ポリシー・バインディング・ファイルによって、fault-policies.xmlファイルに定義されているフォルト・ポリシーがFusionMidFaults SOAコンポジット・アプリケーションに関連付けられます。
<?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にfault-policies.xmlファイルの内容を示します。
例12-4 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>
<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">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-5に、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>
拒否メッセージのアクション・ハンドラを使用するフォルト・ポリシーを設計する際は、実行できる書込みアクションが1つのみであることに注意してください。例12-6に示すように、複数の拒否ハンドラを定義している場合も、複数の書込みアクションは実行できません。この場合、定義されている最初の拒否ハンドラ(この例ではora-queue)のみが実行されます。
例12-6 複数の拒否ハンドラがあるフォルト・ポリシー
<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 Business Process Management Suite管理者ガイド』を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlでのフォルト・ポリシーの実行に関する説明
管理者操作を使用するフォルト・ポリシーの定義のユースケース
Javaアクション・フォルト・ポリシーを使用する際は、次の点に注意してください。
用意されているJavaクラスは、特定のインタフェースに従っています。このインタフェースは文字列を戻します。実行後に取得する出力とフォルト・ポリシーには、複数の値を指定できます。
実装されているメソッドの出力値(戻り値)からフォルト・ポリシーへのマッピングを指定することで、追加のフォルト・ポリシーを実行できます。
ReturnValueが指定されていない場合は、例12-7に示すように、デフォルトのフォルト・ポリシーが実行されます。
例12-7 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インタフェースを実装しているクラスを指定できます。IFaultRecoveryJavaClassは、fabric-runtime.jarファイルにあります。パッケージ名は、oracle.integration.platform.faultpolicyです。
例12-8に示すように、IFaultRecoveryJavaClassインタフェースには2つのメソッドがあります。
例12-8 IFaultRecoveryJavaClassの実装
public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess( IFaultRecoveryContext ctx );
public String handleFault( IFaultRecoveryContext ctx );
}
次の点に注意してください。
handleRetrySuccessは、再試行に成功した場合に起動されます。再試行ポリシーは、retrySuccessActionのJavaアクションにチェーンします。
handleFaultは、javaActionタイプのポリシーを実行する際に起動されます。
例12-9にIFaultRecoveryContextで使用可能なデータを示します。
例12-9 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-10に詳細を示します。
例12-10 IFaultRecoveryContextのサービス・エンジン実装
public class BPELFaultRecoveryContextImpl extends BPELXExecLetUtil implements
IBPELFaultRecoveryContext, IFaultRecoveryContext{
...
}
例12-11に示すように、Oracle BPEL Process Manager固有のデータは、IBPELFaultRecoveryContextを使用して入手できます。
例12-11 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-12に、javaActionの実装例を示します。
例12-12 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());
...
}
Oracle BPM Suiteに対してフォルト・ポリシーを設計し、実行できます。詳細は、『Oracle Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド』の「BPMでのフォルト処理の使用方法」の章を参照してください。
インスタンスをリカバリするフォルト・ポリシーを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としてマークされたままになり、リカバリはインスタンスの処理を試行します。
たとえば、例12-13に示すフォルト・ポリシー・ファイルでは、ora-retryの後にアクションが定義されていません。
例12-13 アクションの定義がない例
<Action id="ora-retry">
<retry>
<retryCount>2</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
</retry>
</Action>
この場合は、次のアクションが実行されます。
(前述のフォルト・ポリシー・コードを使用してフォルトを処理する)invokeアクティビティが試行されます。
間隔を増やして2回の再試行(2秒後、次に4秒後)が実行されます。
すべての再試行に失敗した場合は、次のアクションが実行されます。
詳細なフォルト・エラー・メッセージが監査証跡に記録されます。
インスタンスがopen.faulted(進行中)としてマークされます。
インスタンスが選択され、invokeアクティビティが再試行されます。
リカバリにも失敗する場合があります。その場合は、invokeアクティビティが再実行されます。追加の監査メッセージが記録されます。
フォルト・ポリシーの再試行アクションは、同じフロー内の複数のフォルトで実行できない可能性があります。これは、以前のフォルトの再試行回数に到達している可能性があるためです。
たとえば、fault1とfault2の2つのフォルト条件でフォルト・ポリシーを定義すると仮定します。どちらのフォルト条件にも、再試行回数が3の再試行アクションが指定されます。fault1が発生し、再試行アクションが3回実行されるとします。ペイロードを変更することでfault1の問題を解決しますが、インスタンスが再発行されるとfault2が発生します。その後、Oracle Enterprise Manager Fusion Middleware Controlを使用して、フォルトが発生したインスタンスを再発行します。2番目のフォルト条件fault2は、フォルト・ポリシーの仕様に従って3回再試行されると予想できます。しかし、前のfault1フォルト条件で再試行の最大数が実行されたため、この2番目のフォルト条件は発生しません。
アウトバウンド方向のJCAレベルの再試行とフォルト・ポリシー・ファイル内の再試行アクションの両方を備えたアダプタで、アウトバウンド障害に対する再試行アクションをテストしている場合は、そのJCAレベル(またはバインディング・レベル)再試行がフォルト・ポリシー再試行の中で実行されます。たとえば、図12-11に示すアプリケーションを設計したとします。
composite.xmlファイルには、例12-14に示す再試行パラメータを指定します。
例12-14 再試行パラメータ
<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参照バインディング・コンポーネントのフォルト・ポリシー・ファイルには、例12-15に示すアクションを指定します。
アウトバウンド障害が発生する場合は、フォルト・ポリシー再試行中に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秒間隔)
定義されたフォルト・ポリシー/バインディングを使用してSOAコンポジット・アプリケーションを起動し、Oracle Enterprise Manager Fusion Middleware Controlでリカバリ可能なフォルトを表示するとします。フォルト・リカバリの再試行が正常に行われた後、process_nameページのインスタンスの「フォルト」タブの「再試行成功後」リストには、デフォルトでは選択可能なora-javaオプションがありません。
これは予想された動作です。ora-javaオプションを表示するには、設計時にfault-policies.xmlファイルで明示的に定義する必要があります。たとえば、次の手順を実行します。
ora-javaオプションを定義する手順は、次のとおりです。
fault-policies.xmlファイルにretrySuccessAction ref="ora-java"/>を明示的に追加するfault-policies.xmlファイルを作成します。
<Action id="ora-retry">
<Retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="ora-java"/>
<retrySuccessAction ref="ora-java"/>
</Retry>
</Action>
コンポジットをデプロイしてインスタンスを作成します。
コンポジット・インスタンスをクリックして、コンポジットのインスタンス・トレースを起動します。リカバリ可能なフォルトがあるコンポーネント(Oracle BPEL Process Manager、Oracle Mediator、Oracle BPMなど)をクリックします。「フォルト」タブに移動します。
フォルトを正常に再試行するには、「再試行」オプションを選択します。
フォルト・リカバリに成功した場合は、「再試行成功後」リストが表示されます。
リストを選択すると、今度はora-javaオプションがリストされています。
Oracle Enterprise Manager Fusion Middleware Controlでのフォルトからのリカバリの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
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拡張関数を使用します。
例12-16は、この関数の使用方法を示しています。
例12-16 getFaultAsString() XPath拡張関数
<catchAll>
<sequence>
<assign>
<from expression="bpelx:getFaultAsString()"/>
<to variable="faultVar" part="message"/>
</assign>
<reply faultName="ns1:myFault" variable="faultVar" .../>
</sequence>
</catchAll>
詳細は、第B.2.29項「getFaultAsString」を参照してください。
BPELアプリケーションでは、フォルト・メッセージの生成および受取りができます。throwアクティビティには3つの要素(それ自体の名前、フォルトの名前およびフォルト変数)があります。throwアクティビティによってスローされるフォルトはBPEL内部のフォルトです。throwアクティビティは、クライアントと通信する非同期プロセスには使用できません。throwアクティビティの構文には、スロー名、フォルト名およびフォルト変数を指定します。
<throw name="delay" faultName="nsPrefix:fault-1" faultVariable="fVar"/>
throwアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
throwアクティビティをデザイナにドラッグします。
throwアクティビティをダブルクリックして定義します。
名前を入力するか、デフォルト値をそのまま使用します。
「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、監視するフォルトを選択します。
「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。
選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。
図12-12に、完成した「Throw」ダイアログの例を示します。この例では、Fusion Order Demoアプリケーションの「Scope_AuthorizeCreditCard」scopeアクティビティの「Throw_Fault_CC_Denied」throwアクティビティが表示されています。このアクティビティは、承認されない注文に対してフォルトをスローします。
「適用」→「OK」の順にクリックします。
例12-17に、設計完了後の.bpelファイルのthrowアクティビティを示します。このthrowアクティビティの実行後にOrderProcessorプロセスが終了します。
rethrowアクティビティは、すぐ外側を囲んでいるフォルト・ハンドラによって最初に捕捉されたフォルトを再スローします。フォルト・ハンドラ内(catchアクティビティ、catchAllアクティビティ内など)では、rethrowアクティビティのみ使用します。rethrowアクティビティは、捕捉されたフォルト(元のフォルトのフォルト名およびフォルト・データ(存在する場合))を再スローするために、フォルト・ハンドラで使用されます。rethrowアクティビティは、フォルト・データに対する変更を無視する必要があります。例:
フォルト・ハンドラがフォルト・データを変更した後、rethrowアクティビティをコールした場合、元のフォルト・データが再スローされ、変更されたフォルト・データは再スローされません。
要素を使用して1つのパーツが定義されたメッセージ・タイプ・フォルトが、同じ要素タイプを検索しているフォルト・ハンドラによって捕捉されるようにする機能を使用してフォルトが捕捉された場合、rethrowアクティビティは元のメッセージ・タイプ・データを再スローします。
|
注意: このアクティビティは、BPELバージョン2.0プロジェクトでサポートされています。 |
例12-18に、rethrowアクティビティの設計が完了した後の.bpelファイルを示します。rethrowアクティビティはフォルト・ハンドラ(catchアクティビティ)の内側にあります。
例12-18 rethrowアクティビティ
<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>
BPELプロセス・サービス・コンポーネントは、内部フォルトのスローとは対照的に、別のアプリケーションにフォルトを送信して問題を提示できます。同期操作では、replyアクティビティがフォルトを返すことができます。非同期操作では、invokeアクティビティがこの機能を実行します。
例12-19に、同期相互作用でフォルトを返すreplyアクティビティの構文を示します。
例12-19 replyアクティビティ
<reply partnerlinke="partner-link-name" portType="port-type-name" operation="operation-name" variable="variable-name" (optional) faultName="fault-name"> </reply>
同期リクエストに対して常にフォルトを返すことはあまり有効ではありません。それよりも、アクティビティを条件分岐に組み込み、リクエストされたデータを使用できる場合に最初のブランチが実行されるようにするほうが効果的です。リクエストされたデータを使用できない場合、BPELプロセス・サービス・コンポーネントはそのことを示すフォルトを返します。
詳細は、次の章を参照してください。
同期相互作用については、第7章「BPELプロセスからの同期Webサービスの起動」を参照してください。
条件構造の設定については、第11章「BPELプロセスでの条件分岐の使用」を参照してください。
非同期相互作用では、クライアントはリプライを待機しません。このため、フォルトを返すためにreplyアクティビティが使用されることはありません。かわりに、BPELプロセス・サービス・コンポーネントは通常はリクエストされた情報を受け取る同じポート・タイプのコールバック操作を使用して、invokeアクティビティによってフォルトを返します。
非同期相互作用の詳細は、第8章「BPELプロセスからの非同期Webサービスの起動」を参照してください。
scopeアクティビティは、他のアクティビティに対してコンテナおよびコンテキストを提供します。scopeは、フォルト、イベント、補正、データ変数および相関セットに対するハンドラを提供します。scopeアクティビティを使用すると、機能構造をグループ化することでBPELフローが単純化されます。このグループ化により、Oracle BPELデザイナでは機能構造を閉じて1つの要素として表示できます。
例12-20に、WebLogic Fusion Order DemoアプリケーションのScope_FulfillOrderという名前のscopeを示します。このscopeは、注文品の出荷方法を判断するFulfillOrder Oracle Mediatorコンポーネントを起動します。
例12-20 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アクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
scopeアクティビティをデザイナにドラッグします。
Scopeアクティビティをダブルクリックするか、「拡張」記号を1回クリックして、アクティビティを開きます。
「コンポーネント・パレット」から各アクティビティをドラッグして定義し、スコープ内に機能を作成します。図12-15に詳細を示します。
「OK」をクリックします。
完了後、scopeアクティビティの設計は図12-16のようになります。この例では、Fusion Order Demoアプリケーションの「Scope_AuthorizeCreditCard」scopeアクティビティが表示されています。
scopeアクティビティには、スコープの機能に関する簡単な説明を提供する説明ノートを追加できます。スコープのグラフィック・イメージを変更することもできます。説明ノートおよびイメージは、Oracle BPELデザイナに表示されます。これらの表示により、スコープをより簡単に理解できるようになります。
説明ノートおよびイメージをscopeアクティビティに追加する手順は、次のとおりです。
次のいずれかの手順を実行します。
スコープを右クリックし、「ユーザー・ドキュメント」を選択します。
スコープをダブルクリックし、「ユーザー・ドキュメント」タブを選択します。
「ドキュメント」ダイアログが表示されます。
「コメント」フィールドに、スコープの機能に関する簡単な説明を入力します。
「イメージ」フィールドで、必要に応じて「検索」アイコンをクリックし、スコープのグラフィック・イメージを変更します。
「OK」をクリックします。
図12-17に示すように、変更した結果がOracle BPELデザイナに表示されます。
説明ノートを編集する場合は、説明ノートをダブルクリックします。
例12-21に、設計完了後の.bpelファイルのscopeアクティビティを示します。Scope_AuthorizeCreditCard scopeアクティビティは、次のアクションを実行する各アクティビティで構成されています。
クレジット・カード番号がない、またはクレジット・タイプが有効でないためにフォルトになった注文を捕捉するcatchアクティビティ。
承認されない注文に対してフォルトをスローするthrowアクティビティ。
クレジット・カード・タイプ、クレジット・カード番号および購入金額を取得し、この情報をCreditCardAuthorizationServiceサービスの入力変数に割り当てるassignアクティビティ。
CreditCardAuthorizationServiceサービスをコールして顧客情報を取得するinvokeアクティビティ。
クレジット・カード検証の結果を確認するswitchアクティビティ。
例12-21 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-22に、catchおよびcatchAllアクティビティの構文を示します。x:fooという名前のフォルトがスローされたとします。フォルトがフォルト・データを渡さない場合は、最初のcatchが選択されます。フォルトに関連付けられたフォルト・データがある場合、フォルトのデータ・タイプが変数barタイプに一致すると、3番目のcatchが選択されます。一致しない場合は、デフォルトのcatchAllハンドラが選択されます。最後に、タイプがbarのタイプに一致し、名前がx:fooでないフォルト変数を持つフォルトは2番目のcatchで処理されます。その他のすべてのフォルトはデフォルトのcatchAllハンドラによって処理されます。
composite.xmlファイルでidempotentデプロイメント・ディスクリプタのプロパティがfalseに設定されている場合、パートナ・リンクの起動が失敗しても、invokeアクティビティからリカバリは開始されません。invokeアクティビティの再試行をidempotentプロパティに依存することはお薦めいたしません。かわりに、BPELプロセス内に設計したフォルト処理(catchAllアクティビティの場合など)によって、リカバリを試みます。ベスト・プラクティスとして、かわりにフォルト・ポリシーを使用してinvokeアクティビティを再試行することをお薦めします。
表12-4は、idempotentプロパティがfalseに設定されていて、パートナ・リンクの起動が成功した場合と失敗した場合の動作を示しています。
表12-4 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-18に詳細を示します。
詳細は、第8.4項「パートナ・リンク操作レベルでの冪等性の管理」を参照してください。
scopeアクティビティのcatchAllアクティビティ・エラー・ハンドラによってフォルトが捕捉され、ロールバック・フォルトがスローされます。
パートナ・リンクに対するinvokeアクティビティによる起動が失敗した場合、リカバリはcatchAllアクティビティ・エラー・ハンドラから開始され、invokeアクティビティからは開始されません。Oracle Enterprise Manager Fusion Middleware ControlのBPELプロセスのflowアクティビティで、catchAllアクティビティからのリカバリを監視できます。
これは設計によります。idempotentプロパティの設定は、invokeアクティビティの実行の後に確認されます。実行に失敗し、例外が発生した場合、idempotentプロパティの設定には到達しません。BPELプロセス・サービス・エンジンによって、catchAllアクティビティを開いた直後のインスタンスが保存されます。idempotentプロパティがfalseに設定されているため、このインスタンスを保存する必要があります。これが、リカバリがcatchAllアクティビティで再開される理由です。
かわりに、失敗したinvokeアクティビティをフォルト・ポリシーでリカバリすることをお薦めします。フォルト・ポリシーの作成の詳細は、第12.4項「フォルト管理フレームワークでのフォルトの処理」を参照してください。
idempotentプロパティの詳細は、第C.1項「デプロイメント・ディスクリプタのプロパティの概要」を参照してください。
スコープでcatchアクティビティを作成する手順は、次のとおりです。
開いた状態のscopeアクティビティで、「Catchの追加」をクリックします。図12-19に詳細を示します。
これにより、scopeアクティビティの右側にcatchアクティビティが作成されます。
catchアクティビティをダブルクリックします。
必要に応じて名前を入力します。
「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、フォルトを選択します。
「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。
選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。
図12-20に、「Catch」ダイアログの例を示します。この例では、Fusion Order Demoアプリケーションの「Scope_AuthorizeCreditCard」scopeアクティビティの「selectionFailure」catchアクティビティが表示されています。このcatchアクティビティは、クレジット・カード番号がない注文を捕捉します。
追加のフォルト処理機能を設計します。
「OK」をクリックします。
図12-21に、「Scope_AuthorizeCreditCard」scopeアクティビティに2つのcatchアクティビティがある例を示します。2番目のcatchアクティビティは、有効でないクレジット・タイプを捕捉します。
例12-23に、設計完了後の.bpelファイルのcatchアクティビティを示します。selectionFailure catchアクティビティはクレジット・カード番号がない注文を捕捉し、InvalidCredit catchアクティビティは有効でないクレジット・タイプを捕捉します。
例12-23 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アクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
emptyアクティビティをデザイナにドラッグします。
emptyアクティビティをダブルクリックします。
図12-22に示すように、「Empty」ダイアログが表示されます。
必要に応じて名前を入力します。
「OK」をクリックします。
例12-24に、emptyアクティビティの構文を示します。
catchまたはcatchAllアクティビティが選択されていない場合、フォルトが現在のスコープによって捕捉されず、すぐ外側を囲んでいるスコープにスローされます。グローバル・プロセス・スコープでフォルトが発生し(またはグローバル・プロセス・スコープに再スローされ)、グローバル・レベルでフォルトに適合するフォルト・ハンドラがない場合、プロセスが異常終了します。これは、terminateアクティビティ(第12.13.1項「BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止」で説明)が実行されたような状況になります。
scopeアクティビティ内にreplayを作成すると、スコープ内のすべてのアクティビティを再実行できます。
例12-25に、BPELバージョン2.0をサポートするBPELプロジェクトのreplayアクティビティの設計が完了した後の、.bpelファイルを示します。BPEL 2.0では、replayアクティビティはextensionActivity要素にラップされます。
例12-25 replayアクティビティ
<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"/>
補正は、BPELプロセス・サービス・コンポーネントが一部の操作を完了した後で一連の操作を完了できず、引き返して前に完了したトランザクションを取り消す必要がある場合に発生します。たとえば、レンタカー、ホテルおよび航空券を予約するようにBPELプロセス・サービス・コンポーネントが設計されている場合、車とホテルは予約でき、その日付の航空券を予約できない場合があります。この場合、BPELフローは戻って車とホテルをキャンセルすることによって、補正を実行します。
scopeアクティビティでは、補正ハンドラは以前に完了した処理ステップをリバースできます。補正ハンドラは、次のいずれかのアクティビティを使用して関連するスコープが正常に完了した後に呼び出すことができます。
compensateアクティビティ(BPELバージョン1.1および2.0プロジェクト)
このアクティビティにより、正常に完了したすべての子スコープ、およびまだ補正されていない子スコープの補正ハンドラが、デフォルトの順序で実行されます。
compensateScopeアクティビティ(BPELバージョン2.0プロジェクト)
このアクティビティにより、正常に完了した特定のスコープの補正ハンドラが実行されます。
補正ハンドラは、compensateアクティビティを使用することによって起動でき、補正が実行されるスコープ(補正ハンドラが起動されるスコープ)を指定します。スコープの補正ハンドラは、スコープが正常に完了した場合にのみ起動できます。インストールされていない補正ハンドラを起動することは、emptyアクティビティ(操作なし)を使用することと同じです。これにより、フォルト・ハンドラは、ネストされたどのスコープが正常に完了したかを判断するために、状態を使用しなくても済むようになります。インストールされた補正ハンドラが複数回起動されているプロセスのセマンティクスは定義されていません。
compensateアクティビティを明示的に呼び出す機能は、「Business Process Execution Language for Web Services Specification Version 1.1」のアプリケーションで制御されたエラー処理フレームワークの基礎となります。このアクティビティは、ビジネス・プロセスの次の部分でのみ使用できます。
補正が実行されるスコープのすぐ外側を囲んでいるスコープのフォルト・ハンドラ内。
補正が実行されるスコープのすぐ外側を囲んでいるスコープの補正ハンドラ内。
例:
<compensate scope="RecordPayment"/>
名前によって補正されているスコープがループでネストされている場合、BPELプロセス・サービス・コンポーネントは一連の反復内で補正ハンドラ・インスタンスを逆の順序で起動します。
スコープの補正ハンドラがない場合、デフォルトの補正ハンドラは、すぐ内側に囲まれているスコープの補正ハンドラを、これらのスコープの完了と逆の順序で起動します。
補正フォームでcompensateアクティビティのスコープ名が省略されると、このデフォルトの動作が明示的に起動されます。これは、囲んでいるフォルトまたは補正ハンドラで追加の作業(変数の更新や外部通知の送信、および内側のスコープに対するデフォルト補正の実行など)を実行する必要がある場合に便利です。外側のスコープに付加されたフォルトまたは補正ハンドラのcompensateアクティビティにより、そのスコープ内に直接ネストされた完了スコープに対する補正ハンドラがデフォルトの順序で起動されます。このアクティビティは、外側のスコープ内にネストされたスコープの明示的な起動を除く、その他のユーザー指定の動作と一緒に使用できます。外側のスコープ内にネストされたこのスコープの補正を明示的に起動すると、デフォルトの順序の補正は、適切に機能しません。
compensateアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
compensateアクティビティをデザイナにドラッグします。
compensateアクティビティをダブルクリックします。
図12-25に示すように、補正ハンドラを起動するscopeアクティビティを選択します。
「適用」→「OK」の順にクリックします。
invokeアクティビティにインラインで定義された補正ハンドラがある場合、アクティビティの名前はcompensateアクティビティに使用されるスコープの名前です。例12-26に構文を示します。
compensateScopeアクティビティは、すでに正常に完了している特定の内側のスコープで補正を開始するために使用されます。このアクティビティは、フォルト・ハンドラ、別の補正ハンドラまたは終了ハンドラ内からのみ使用します。
compensateScopeアクティビティを作成する場合、すぐ内側に囲まれているスコープを参照する必要があるターゲットを選択します。スコープにはフォルト・ハンドラまたは補正ハンドラを含める必要があります。
|
注意: このアクティビティは、BPEL 2.0プロジェクトでサポートされています。 |
compensateScopeアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
CompensateScopeアクティビティをデザイナにドラッグします。
CompensateScopeアクティビティをダブルクリックします。
補正ハンドラを起動する特定のscopeアクティビティを選択します。図12-26に詳細を示します。
「適用」→「OK」の順にクリックします。
例12-27に、compensateScopeアクティビティの設計が完了した後の.bpelファイルを示します。compensateScopeアクティビティは、catchallフォルト・ハンドラで定義されます。補正ハンドラを起動するスコープが定義されます。
例12-27 compensateScopeアクティビティ
<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>
次のいずれかのアクティビティを使用して、ビジネス・プロセス・インスタンスを停止できます。
terminateアクティビティ(BPELバージョン1.1プロジェクト)
exitアクティビティ(BPELバージョン2.0プロジェクト)
terminateアクティビティは、そのterminateアクティビティが実行されるビジネス・プロセス・インスタンスの動作をただちに終了します。現在実行中のすべてのアクティビティは、フォルト処理または補正動作を実行せずにできるだけ早く終了する必要があります。terminateアクティビティは、BPELプロセス・サービス・コンポーネントのステータスの通知を送信しません。terminateアクティビティを使用する場合は、先に関係ユーザーに通知するようにプログラムしてください。
terminateアクティビティを作成する手順は、次のとおりです。
Oracle JDeveloperの「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
terminateアクティビティをデザイナにドラッグします。図12-27に例を示します。
terminateアクティビティをダブルクリックします。
必要に応じて名前を入力します。
「OK」をクリックします。
例12-28に、terminateアクティビティの構文を示します。このアクティビティによってビジネス・プロセス・インスタンスが停止します。
exitアクティビティを使用すると、終了処理、フォルト処理または補正処理メカニズムを起動しなくても、すべてのパラレル・ブランチで現在実行中のすべてのアクティビティをただちに終了できます。このアクティビティは、予期しない重大な障害を処理するための適切な理由がない環境で使用すると便利です。
|
注意: 未処理の対話もexitアクティビティの影響を受けます。たとえば、プロセスと対話している他のパートナは、到着することのないレスポンスを待機する可能性があります。 |
例12-29に、exitアクティビティの設計が完了した後の.bpelファイルを示します。
例12-29 exitアクティビティ
<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>
リクエスト/レスポンス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-30に、BPEL 1.1におけるアサート後条件のスキーマ定義を示します。
例12-30 BPEL 1.1におけるアサート後条件のスキーマ定義
<invoke | receive | onMessage>
standard-elements
<bpelx:postAssert name="ncname" expression="boolean-expr" faultName="QName"+
message="generic-expr"+/>
</invoke | receive | onMessage>
例12-31に、BPEL 1.1におけるアサート後条件の構文を示します。
例12-31 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"/>
例12-32に、BPEL 2.0におけるアサート後条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。
例12-32 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>
例12-33に、BPEL 2.0におけるアサート後条件の構文を示します。
例12-33 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>
例12-34に、BPEL 1.1におけるアサート前条件のスキーマ定義を示します。
例12-34 BPEL 1.1におけるアサート前条件のスキーマ定義
<invoke | reply>
standard-elements
<bpelx:preAssert name="NCName" expression="string" message="string"
faultName="QName"/>
</invoke | reply>
例12-35に、BPEL 1.1におけるアサート前条件の構文を示します。
例12-35 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"/>
例12-36に、BPEL 2.0におけるアサート前条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。
例12-36 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>
例12-37に、BPEL 2.0におけるアサート前条件の構文を示します。
例12-37 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>
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と評価される必要があります。そうでない場合は、指定のフォルトがスローされます。
たとえば、例12-38に示すBPEL 1.1のinvokeアクティビティでは、アサーション条件に指定したXPath式でfalseが返されると、NegativeCreditフォルトがスローされます。
例12-38 BPEL 1.1のinvokeアクティビティ
<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ファイル内のアサーション要素の行番号が使用されます。
この項では、主要なアサーション条件の概念について説明します。
アクティビティに応じて、条件を実行するタイミングを指定するには、invokeアクティビティ、receiveアクティビティ、replyアクティビティ、およびpickアクティビティとscopeアクティビティのonMessageブランチの「アサーション」タブで「追加」アイコンをクリックし、「アサート前」または「アサート後」を選択します。選択内容に基づいて、次のbpelx拡張要素が使用されます。
bpelx:preAssert: 「アサート前」を選択すると、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に条件が実行されます。
bpelx:postAssert: 「アサート後」を選択すると、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に条件が実行されます。
例12-39に、BPEL 1.1におけるreceiveアクティビティ内の複数のbpelx:postAssert拡張要素を示します。
例12-39 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>
例12-40に、BPEL 1.1におけるinvokeアクティビティ内の複数のbpelx:preAssert拡張要素を示します。
例12-40 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.2項「アサーション条件の作成方法」を参照してください。
BPEL 1.1では、例12-41のスキーマ定義に示すように、bpelx:postAssert要素のfaultName属性とmessage属性を指定できます。
例12-41 BPEL 1.1におけるfaultName属性とmessage属性のスキーマ定義
<invoke | receive | onMessage>
standard-elements
<bpelx:postAssert name="ncname"? expression="boolean-expr" faultName="QName"+
message="generic-expr"+/> *
</invoke | receive | onMessage>
例12-42に、faultname属性とmessage属性の構文を示します。
例12-42 BPEL 1.1における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)に評価できる一般的な式です。文字列でない値が返された場合は、値の文字列評価が使用されます。
receiveアクティビティ、invokeアクティビティ、またはpickアクティビティとscopeアクティビティのonMessageブランチでは、複数のアサーションをネストできます。アサーションの評価は、式がfalseと評価されるまでアサーションの宣言順に続行されます。例12-43に詳細を示します。
例12-43 BPEL 1.1における複数のアサーションのネスト
<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-43では、レスポンスの信用格付けがゼロより大きいことを確認する式のアサーションが最初に評価されます。表12-5に、このアサーションの動作を示します。
表12-5 アサーションの動作
| 返されたレスポンスの信用格付け | 動作 |
|---|---|
|
ゼロ未満 |
|
|
ゼロ以上 |
アサーションが正しいため、2番目のアサーションが評価されます。 |
|
600未満 |
|
|
600以上 |
アサーションが正しいため、invokeアクティビティからフォルトはスローされません。 |
アサーションは、いくつでもネストできます。アクティビティからフォルトがスローされないためには、指定したすべてのアサーションがtrueと評価される必要があります。
このコンストラクトを使用して、Javaのif...else if...else文と同様に、着信ペイロードに対して様々なレベルの検証を適用できます。
検証ロジックに関係なく、フォルトが常にスローされるようにするには、false()のアサーション式を指定します。これは、Javaのelseコンストラクトと同じです。
アサーション条件には、組込みおよびカスタムのXPath関数と$variable参照も使用できます。例12-44に、いくつかの例を示します。
例12-44 BPEL 1.1における組込みおよびカスタムのXPath関数
<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のフォルト管理フレームワークによって捕捉および処理されます。詳細は、第12.4項「フォルト管理フレームワークでのフォルトの処理」を参照してください。
BPELプロセス・フロー内で捕捉および処理されないフォルトは、操作に対するフォルトがコンポーネントWSDLで宣言されている場合は、BPELコンポーネントからスローされます。操作に対するフォルトが宣言されていない場合、フォルトはFabricInvocationException(実行時フォルト)に変換されます。このフォルトは、いずれかのコール元コンポーネント(BPELコンポーネントを含む)によって捕捉されますが、フォルトのタイプは、当初スローされたタイプではなくなります(ただし、フォルト・メッセージ文字列については、当初のフォルト・メッセージのトレースが保持されます)。
実行時フォルトの詳細は、第12.3項「BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要」を参照してください。
フォルト・ポリシーの詳細は、第12.4項「フォルト管理フレームワークでのフォルトの処理」を参照してください。
評価される各アサーション条件によって、イベントがインスタンス監査証跡に記録されます。イベントは、アサーションが無事通過したか、失敗したのかを示します(失敗の場合は、フォルト名とメッセージが出力されます)。イベントには、アサーション要素に指定されているname属性も挿入されます。name属性の指定がない場合は、BPELプロセス・フローのアサーション要素の行番号が使用されます。監査イベントで出力されるアサーション条件は、アサーションを識別するのに便利で、フローをより円滑にデバッグできるようになります。
アサーション条件XPath式がXMLスキーマ・ブール値タイプに評価されない場合は、アクティビティからbpelx:postAssertFailureフォルトがスローされます。エラーを示すインスタンス監査証跡のイベントも記録されます。例12-45に詳細を示します。
例12-45 BPEL 1.1における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関数では、このタイプの分析は実行されません。
BPELプロセス・サービス・コンポーネントのスタンドアロンassertアクティビティで、アサーション条件を作成することもできます。アサーションは、falseと評価された場合に、アクティビティからBPELフォルトがスローされるXPath式を指定します。
bpelx:assert拡張要素は、スタンドアロンassertアクティビティでアサーションを実装します。
<bpelx:assert name="Assert1" expression="string" message="string"/>
スタンドアロンassertアクティビティの使用については、第12.14.2項「アサーション条件の作成方法」を参照してください。
次のアクティビティでアサーション条件を作成できます。
invokeアクティビティ、receiveアクティビティ、replyアクティビティ、OnMessageブランチなどのメッセージ交換アクティビティ
XPath式を指定するためのスタンドアロンassertアクティビティ
invokeアクティビティ、receiveアクティビティ、replyアクティビティおよびOnMessageブランチでアサート条件を作成する手順は、次のとおりです。
SOAコンポジット・エディタで、BPELプロセス・サービス・コンポーネントをダブルクリックします。
「コンポーネント・パレット」で、「BPELコンストラクト」を展開します。
receiveアクティビティ、invokeアクティビティ、pickアクティビティまたはor scopeアクティビティをデザイナにドラッグします。
receiveアクティビティ、invokeアクティビティ、またはpickアクティビティまたはscopeアクティビティのonMessageブランチを開きます。
「アサーション」タブをクリックします。
BPEL 1.1プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。それ以外の場合は、手順7に進みます。
BPEL 2.0プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。
「Assert」ダイアログが表示されます。
図12-32に示すように、アサーション条件に値を指定します。この例では、BPEL 1.1プロジェクトのreceiveアクティビティのアサーション条件に「アサート後」が選択されています。
「検索」アイコンをクリックして「フォルト・チューザ」ダイアログから既存のフォルトを選択し、スローする「フォルトQName」を選択します。フォルトの「ネームスペースURI」および「ローカル・パート」フィールドに、独自の値を指定することもできます。「フォルトQName」の指定を省略した場合は、bpelx:assertFailureフォルトがスローされます。
完了後に「OK」をクリックして、アクティビティの「アサーション」タブに戻ります。図12-33に示すように、完成したアサーション条件が表示されます。
「適用」→「OK」の順にクリックします。
スタンドアロンassertアクティビティのアサート条件を作成する手順は、次のとおりです。
アサーションは、次のいずれかの方法で無効にできます。
Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで、プロパティDisableAssertsをtrueに設定する方法。
例12-46に示すように、SOAコンポジット・アプリケーションのcomposite.xmlファイルで、bpel.config.disableAssertsをtrueに設定する方法。
システムMBeanブラウザのプロパティの設定の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
.bpelファイルのコード・セグメントは、特定の操作に対する設計完了後の定義を示しています。
例12-47では、invokeアクティビティのbpelx:assert条件がfalseと評価された場合(たとえば、0の信用格付けが発行された場合)は、Negative Creditメッセージが返されます。条件がtrueと評価された場合は、invokeアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。
例12-47 BPEL 1.1におけるinvokeアクティビティのアサーション条件
<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>
例12-48では、スタンドアロンassertアクティビティのbpelx:assert条件がfalseと評価された場合は、次のメッセージが返されます。
got assertion failure on true expression
条件がtrueと評価された場合は、assertアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。
