12 BPELプロセスでのフォルト処理の使用
この章の内容は次のとおりです。
12.1 フォルト・ハンドラの概要
フォルト・ハンドラは、通常予想される以外のデータ(数値のかわりにエラー・メッセージなど)がターゲット・サービスから返されたときに、BPELプロセス・サービス・コンポーネントの対応方法を定義します。フォルト・ハンドラの例として、Webサービスで通常返される信用格付けの数値のかわりに、ネガティブ情報メッセージが返された場合を想定します。
図12-1は、フォルト・ハンドラが信用格付け変数を-1000
に設定する方法の例を示しています。
次の例のコード・セグメントは、この操作のフォルト・ハンドラをBPELファイルに定義します。
<faultHandlers> <catch faultName="services:NegativeCredit" faultVariable="crError"> <assign name="crin"> <copy> <from expression="-1000"> </from> <to variable="input" part="payload" query="/autoloan:loanApplication/autoloan:creditRating"/> </copy> </assign> </catch> </faultHandlers>
faultHandlers
タグには、フォルト処理コードが入ります。フォルト・ハンドラ内のcatchアクティビティによって、フォルト名と変数、およびcreditRating
変数を「-1000
」に設定するコピー指示が定義されます。
BPELプロセス・サービス・コンポーネントに対してWebサービスを選択する際、返される可能性があるフォルトを特定し、それぞれに対してフォルト・ハンドラを設定します。
12.2 BPEL標準フォルトの概要
この項では、BPEL 1.1およびBPEL 2.0の標準フォルトを識別します。
12.2.1 BPEL 1.1の標準フォルト
この項では、BPEL 1.1の標準フォルトを識別します。特に指定がないかぎり、「Business Process Execution Language for Web Services Specification」はhttp://schemas.xmlsoap.org/ws/2003/03/business-process/
のネームスペースで次の標準フォルトを定義します。
-
bindingFault
(http://schemas.oracle.com/bpel/extension
で定義されているBPEL拡張フォルト) -
conflictingReceive
-
conflictingRequest
-
correlationViolation
-
forcedTermination
-
invalidReply
-
joinFailure
-
mismatchedAssignmentFailure
-
remoteFault
(http://schemas.oracle.com/bpel/extension
で定義されているBPEL拡張フォルト) -
repeatedCompensation
-
selectionFailure
-
uninitializedVariable
-
assertFailure
-
coordinationFault
-
entityInternalNestedError
-
maxLoopCountExceeded
-
owsmPolicyFault
-
rollback
-
timeout
標準フォルトの定義は、次のとおりです。
-
タイプなし。つまり、
messageTypes
は関連付けられていません。 -
Web Services Description Language (WSDL)メッセージには関連付けられていません。
-
次のようにフォルト変数なしで捕捉されます。
<catch faultName="bpws:selectionFailure">
12.2.2 BPEL 2.0の標準フォルト
次のリストは、WS-BPEL仕様内で定義されている標準フォルトを指定します。標準フォルト名はすべて、標準のWS-BPELネームスペースで修飾されます。
-
ambiguousReceive
-
completionConditionFailure
-
conflictingReceive
-
conflictingRequest
-
correlationViolation
-
invalidBranchCondition
-
invalidExpressionValue
-
invalidVariables
-
joinFailure
-
mismatchedAssignmentFailure
-
missingReply
-
missingRequest
-
scopeInitializationFailure
-
selectionFailure
-
subLanguageExecutionFault
-
uninitializedPartnerRole
-
uninitializedVariable
-
unsupportedReference
-
xsltInvalidSource
-
xsltStylesheetNotFound
12.2.2.1 BPEL 2.0でのフォルト処理の優先順位
BPEL 2.0の場合、関連するデータなしでスローされたフォルトを捕捉するための優先順位は次のとおりです。
-
一致する
faultName
値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable
属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。 -
catchAllアクティビティがある場合、フォルトはcatchAllフォルト・ハンドラに送信されます。
-
それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。
BPEL 2.0の場合、関連するデータとともにスローされたフォルトを捕捉するための優先順位は次のとおりです。
-
一致する
faultName
値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable
属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。 -
フォルト・データが、次のものを含むWSDLメッセージ・タイプの場合:
-
メッセージには、要素で定義された単一パーツが含まれます。
-
一致する
faultName
値を持つcatchアクティビティであり、その値にはfaultVariable
があり、これに関連付けられているfaultElement
QNameは、単一のWSDLメッセージ・パーツの実行時要素データのQNameと一致します。
その後フォルトは、単一パーツの要素の値に初期化された
faultVariable
を持つ、識別されたcatchアクティビティに送信されます。 -
-
一致する
faultName
値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable
属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。この場合、フォルト値はフォルト・ハンドラ内からは使用できませんが、rethrowアクティビティで使用できます。 -
faultName
属性がないcatchコンストラクトがあり、そのfaultName属性に、タイプが実行時フォルト・データのタイプと一致するfaultVariable
がある場合、フォルトは識別されたcatchアクティビティに送信されます。 -
フォルト・データが、メッセージに要素で定義された単一パーツが含まれるWSDLメッセージ・タイプで、
faultVariable
を持つfaultName
属性がないcatchアクティビティが存在し、そのfaultVariableの関連するfaultElement
のQNameが単一のWSDLメッセージ・パーツの実行時要素データのQNameと一致する場合、フォルトは、単一パーツの要素の値に初期化されたfaultVariable
を持つ、識別されたcatchアクティビティに送信されます。 -
catchAllアクティビティがある場合、フォルトはcatchAllフォルト・ハンドラに送信されます。
-
それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。
12.3 BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要
BPELフォルトには、Qname
というフォルト名(ネームスペースで修飾された名前)と、可能性のあるmessageType
があります。BPELフォルトには次の2つのカテゴリがあります。
-
ビジネス・フォルト
-
実行時フォルト
12.3.1 ビジネス・フォルト
ビジネス・フォルトはアプリケーション固有のフォルトであり、処理されている情報に問題がある場合(社会保障番号がデータベース内で見つからない場合など)に生成されます。ビジネス・フォルトは、アプリケーションがthrowアクティビティを実行したとき、またはinvokeアクティビティがレスポンスとしてフォルトを受け取った場合に発生します。ビジネス・フォルトのフォルト名はBPELプロセス・サービス・コンポーネントによって指定されます。該当する場合は、messageType
が、WSDLファイルで定義されます。ビジネス・フォルトは、faultName
およびfaultVariable
を使用してfaultHandler
で捕捉できます。
<catch faultName="ns1:faultName" faultVariable="varName">
12.3.2 実行時フォルト
実行時フォルトは、BPELプロセス・サービス・コンポーネントまたはWebサービスの実行中に問題(変数名が正しくないためにデータを正しくコピーできないなど)が発生した結果です。この種のフォルトはユーザー定義ではなく、システムによりスローされます。それらは、次に示すような様々な理由で生成されます。
-
プロセスによって、値の不適切な使用が試行される。
-
論理エラーが発生する(無限ループなど)。
-
SOAPコールでSimple Object Access Protocol (SOAP)フォルトが発生する。
-
サーバーによって例外がスローされる。
様々な実行時フォルトが自動的に提供されています。これらのフォルトは、http://schemas.oracle.com/bpel/extension
ネームスペースにあります。また、messageType
RuntimeFaultMessage
に関連付けられています。次の例に示すように、messageType
はWSDLファイルに定義されます。
<?xml version="1.0" encoding="UTF-8" ?> <definitions name="RuntimeFault" targetNamespace="http://schemas.oracle.com/bpel/extension" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/"> <message name="RuntimeFaultMessage"> <part name="code" type="xsd:string" /> <part name="summary" type="xsd:string" /> <part name="detail" type="xsd:string" /> </message> </definitions>
フォルトの捕捉時に(messageType
RuntimeFaultMessage
の)faultVariable
が使用される場合は、faultVariable
からフォルト・サマリーおよび詳細とともにフォルト・コードを問合せできます。
12.3.2.1 bindingFault
bindingFault
は、起動準備に失敗した場合にアクティビティ内でスローされます。たとえば、プロセスのWSDLのロードに失敗した場合などです。bindingFault
は再試行不可です。通常、このタイプのフォルトは管理者操作により修正する必要があります。
12.4 フォルト管理フレームワークを使用したフォルトの処理
Oracle SOA Suiteには、BPELプロセスのフォルトを処理するために一般的なフォルト管理フレームワークが用意されています。プロセスでinvokeアクティビティの実行時にフォルトが発生すると、そのフォルトはフレームワークによって捕捉され、フォルト・ポリシー・ファイルでそのコンポジットまたはコンポーネントに関連付けられているユーザー指定のアクションが実行されます。フォルト・ポリシーは、invokeアクティビティの結果であるフォルトに適用できます。フォルトは、ターゲット・サービスでのアサート前、アサート後、起動または実際のビジネスでの障害で発生する可能性があります。
管理者操作が規定のアクションである状況でフォルトが発生した場合は、Oracle Enterprise Manager Fusion Middleware Controlからリカバリ・アクションを実行します。フォルト管理フレームワークによって、scopeアクティビティのcatchアクティビティを使用してBPELプロセスを設計するための代替手段が提供されます。
この項では、フォルト管理フレームワークを構成する複数のコンポーネントの概要について説明します。
-
フォルト管理フレームワークでは、invokeアクティビティのすべてのフォルト(ビジネスおよび実行時)が捕捉されます。
-
フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。フォルト・ポリシー・ファイルでは一連のアクションがIDで識別されます。
-
一連の条件によってアクションが起動されます(フォルト・ポリシーとも呼ばれます)。
-
電子メールまたはJMSにより、条件に関連付けられているエラーをユーザーに通知します。
-
フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを次のものに関連付けます。
-
SOAコンポジット・アプリケーション
-
BPELプロセスとOracle Mediatorのサービス・コンポーネント
-
BPELプロセスとOracle Mediatorのサービス・コンポーネントの参照バインディング・コンポーネント
フォルト管理フレームワークでは、SOAコンポジット・アプリケーションの
composite.xml
ファイルと同じディレクトリ、または設定した2つのプロパティで識別されるリモートの場所で、フォルト・ポリシー・バインディングを検索します。リモートの場所はMDSリポジトリ内です。ノート:
フォルト管理フレームワークで構成されるフォルト・ポリシーは、BPELプロセスのscopeアクティビティのcatchアクティビティに定義されるフォルト処理よりも優先されます。フォルト管理フレームワークは、フォルト処理をcatchアクティビティに再スローするように構成できます。
-
-
フォルト・ポリシー・ファイル(
fault-policies.xml
)およびフォルト・ポリシー・バインディング・ファイル(fault-bindings.xml
)は、次のいずれかの場所に格納されます。-
SOAコンポジット・アプリケーションの
composite.xml
ファイルと同じディレクトリ。 -
composite.xml
ファイルに追加した2つのプロパティで指定された別の場所。このオプションは、1つのフォルト・ポリシーを複数のSOAコンポジット・アプリケーションで使用する必要がある場合に便利です。このオプションは、composite.xml
ファイルと同じディレクトリに格納されているフォルト・ポリシー・ファイルよりも優先されます。次の例は、この2つのプロパティの詳細を示しています。この例では、フォルト・ポリシー・ファイルが、Oracle Metadata Services (MDS)リポジトリの共有領域のSOA部分に配置されます。<property name="oracle.composite.faultPolicyFile">oramds:/apps/faultpolicyfiles/ fault-policies.xml </property> <property name="oracle.composite.faultBindingFile">oramds:/apps/faultpolicyfiles/ fault-bindings.xml </property>
-
Oracle Mediatorのフォルト処理機能の詳細は、「エラー処理の使用」を参照してください。
Oracle Business Process Management (BPM) Suiteによるフォルト・ポリシーの作成の詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発の「BPMでのフォルト処理の使用」を参照してください。
12.4.1 フォルト・ポリシー・バインディングによる解決方法の理解
フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーをSOAコンポジット・アプリケーションまたはコンポーネント(サービス・コンポーネントまたは参照バインディング・コンポーネント)に関連付けます。フォルト管理フレームワークでは、次の順序でフォルト・ポリシー・バインディングの識別が試みられます。
-
composite.xml
ファイルに定義されている参照バインディング・コンポーネント。 -
composite.xml
ファイルに定義されているBPELプロセスまたはOracle Mediatorのサービス・コンポーネント。 -
composite.xml
ファイルに定義されているSOAコンポジット・アプリケーション。
解決する過程で条件に適したアクションが見つからない場合、フォルト管理フレームワークでは、その解決は失敗とみなされ、次の解決レベルに移動します。
たとえば、invokeアクティビティがfaultname="abc"
で失敗となった場合を考えてみます。fault-bindings.xml
ファイルには、次のポリシー・バインディングが指定されているとします。
-
policy-id-1
へのSOAコンポジット・アプリケーションのバインド -
policy-id-2
へのBPELプロセス/Oracle Mediatorサービス・コンポジットまたは参照バインディング・コンポーネントのバインド
また、fault-bindings.xml
ファイルには、次のバインディングも指定されているとします。
-
policy-id-3
へのSOAコンポジット・アプリケーションのバインド -
policy-id-4
への参照バインディング・コンポーネントまたはサービス・コンポーネントのバインド
フォルト管理フレームワークは、次のように動作します。
-
最初に、解決バインディング(この場合は
policy-id-4
)と照合します。 -
フォルトの解決に失敗した場合は、可能な次の照合(
policy-id-2
との照合)に進みます。 -
フォルトの解決に失敗した場合は、可能な次の照合(
policy-id-3
との照合)に進みます。 -
フォルトの解決に失敗した場合は、可能な次の照合(この場合は
policy-id-1
との照合)に進みます。 -
フォルトが解決していない場合、そのフォルトはBPELフォルトcatchアクティビティに送信されます。
12.4.2 自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法
フォルト・ポリシーをフォルト・ポリシー・ウィザードで設計し、フォルト・ポリシーをフォルト・ポリシー・バインディング・ファイルに関連付けることができます。
自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計するには:
12.4.2.1 ステップ1: プロパティ・セットの定義
最初に、プロパティ・セットを定義して「ステップ2: アラートの定義」で定義されるJMSアラートと関連付けます。JMS宛先やコネクション・ファクトリなどのプロパティ・セットの構成詳細を複数のJMSアラートと関連付けることができます。たとえば、JMSアラートの場合、宛先、キュー情報およびコネクション・ファクトリは、フォルト・ポリシーに構成された追加のJMSアラートによる参照が可能です。
ノート:
このリリースでは、電子メールアラートに対してプロパティ・セットを作成できません。
-
「プロパティ」タブをクリックします。表12-1に使用可能なフィールドの詳細を示します。
表12-1 プロパティ・セットの選択
説明 結果 電子メール・アラート
電子メール・アラートでは、このリリースのプロパティ・セットはサポートされていません。
JMSキュー・アラート
-
「追加」をクリックして、JMSアラートに対するプロパティおよび値を指定します。次のプロパティおよび関連付けられた値は必須です。
-
jmsDestination: 構成されたキューまたはトピックのJNDI名で、ここでアラートがキューまたはパブリッシュされます。
-
connectionFactory: 使用する構成済コネクション・ファクトリのJNDI名。
図12-12に、JMS宛先およびコネクション・ファクトリ値で構成されたプロパティ・セットを示します。
定義済
JMS
propertySet
セクションを含む、完全に定義されたフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」のステップ4を参照してください。 -
12.4.2.2 ステップ2: アラートの定義
-
「アラート」タブをクリックします。次の2種類の通知アラートがサポートされています。
-
電子メール: 電子メール受信者を構成して、フォルト発生時にアラートを受信できます。また、同じ電子メール受信者をOracle Enterprise Manager Fusion Middleware Controlの「ワークフロー通知プロパティ」ページの「メーラー」タブに構成する必要があります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフロー通知プロパティの構成に関する項を参照してください。
-
JMS: フォルトをJMSキューにエンキューするか、JMSトピックにパブリッシュできます。JMSヘッダー値も指定できます。JMS通知は、フォルトを処理するためにサードパーティの解決システムと統合できます。サードパーティの解決システムは、ターゲットのキューおよびトピックにデキューおよびサブスクライブします。ヘッダーのプロパティ値に基づいて利用することで、より詳細にメッセージを利用できます。JMSメッセージのペイロード・タイプは、XMLフォーマットのテキスト・メッセージです。さらに、JMSキューとトピックおよびコネクション・ファクトリをOracle WebLogic Server管理コンソールで構成する必要があります。詳細は、『Oracle WebLogic Server JMSリソースの管理』の基本JMSシステム・リソースの構成に関する項を参照してください。
-
-
「追加」アイコンをクリックします。表12-2に詳細を示します。
表12-2 アラートの選択
選択 結果 電子メール
フォルト発生時に電子メール・アラートを受信する受信者を指定できます。
-
「ID」フィールドで、IDを指定するか、デフォルト値をそのまま使用します。
-
「宛先」および「Cc」フィールドで、電子メール受信者を指定します。
ノート: 「プロパティ・セット」リストからプロパティ・セットを選択しないでください。電子メール・アラートでは、このリリースのプロパティ・セットはサポートされていません。
-
完了後に、「OK」をクリックします。
JMS
フォルト発生時にJMSアラートを受信するキューを指定できます。
JMSアラートの構成には次の2つのプロパティが必要です。
-
jmsDestination: 構成されたキューまたはトピックのJNDI名で、ここでアラートがキューおよびパブリッシュされます。
-
connectionFactory: 使用する構成済コネクション・ファクトリのJNDI名。
-
「ID」フィールドで、IDを指定するか、デフォルト値をそのまま使用します。
-
「プロパティ・セット」リストで、「ステップ1: プロパティ・セットの定義」で作成した既存のプロパティ・セットを選択するか、「必須プロパティの作成」をクリックして、jmsDestinationおよびconnectionFactoryに定義されている値を使用して新しいプロパティ・セットを作成します。
-
「ヘッダー」表で、必要に応じてJMSヘッダー値を指定して、詳細なフォルト利用を実現します。標準およびカスタムの外部システムはどちらも、構成されたヘッダー・プロパティに基づいて、サブスクリプションをフィルタできます。
-
完了後に、「OK」をクリックします。
図12-13に、「電子メールのプロパティ」ダイアログでの電子メール・アラートの構成を示します。
図12-14に、「JMSのプロパティ」ダイアログでのJMSアラートの構成を示します。この例では、プロパティ・セット(「必須プロパティの作成」をクリックすることで起動される「プロパティ・セット」ダイアログで定義)とヘッダーの両方が定義されています。
定義済
「アラート」
セクションを含む、完全に定義されたフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」のステップ4を参照してください。 -
12.4.2.4 ステップ4: フォルト名およびポリシーの定義
-
フォルト・ポリシー・エディタの上部セクションで、フォルト・ポリシーのフォルト名、説明およびデフォルト・アクションを定義します。表12-4に詳細を示します。
表12-4 フォルト・ポリシー・エディタ - 上部のセクション
要素 説明 「フォルト・ポリシーの追加」アイコン(左上隅)
また、さらに別のフォルト・ポリシーを構成用に単一ポリシー・ドキュメントに追加できます。
「追加」アイコンを左上隅でクリックし、さらに別のフォルト・ポリシーを追加します。フォルト・ポリシー・エディタの左端にある列にすべてのポリシーが表示されます。定義するポリシーをクリックできます。
フォルト・ポリシーの削除
選択したフォルト・ポリシーを削除します。
フォルト・ポリシー
フォルト・ポリシーの名前を入力するか、
policy
number
のデフォルト名をそのまま使用します。「フォルトの追加」アイコン(右上隅)
クリックしてフォルトを追加します。
フォルトの削除
クリックしてフォルトを削除します。
フォルト名
捕捉するフォルトの標準タイプを選択します。このリストには、選択可能なシステム・フォルト(バインディング、Oracle Mediatorまたはリモート)またはサービス(ビジネス)・フォルトが表示されます。
説明
説明を入力します(オプション)。説明は実行時に監査証跡に維持されます。
デフォルト・アクション
このセクションでは、次のタスクを実行します。
-
リストから、このフォルト発生時に実行するデフォルト・アクション(たとえば、中断、再スロー、再試行など)を選択します。選択可能なアクションは、「ステップ3: アクションの定義」で保持または削除したアクションに基づいています。
または
-
「追加」アイコンをクリックし、if-then条件をフォルト・ポリシーに追加します。この選択では「If」、「Then」および「Default」のフィールドが表示されます。
たとえば、条件を「If」フィールド(デフォルトは「true」)を指定すると、起動するアクション(たとえば、管理者操作)を「Then」フィールドで選択できます。条件が「true」でない場合、発生するデフォルト・アクション(たとえば、「中断」)を「Default」フィールドで選択できます。
-
「If」フィールドで、条件を入力するか、「式ビルダー」アイコンをクリックしてXPath式条件を構築します。
-
「Then」フィールドで、「If」フィールドの条件がtrueに評価される場合に起動される条件を指定します。
-
「デフォルト」フィールドで、「If」フィールドの条件がfalseに評価される場合に起動される条件を指定します。
-
「追加」アイコンの左にある「アラート」アイコンをクリックし、条件発生時に送信するアラートのタイプを選択します。選択可能なアラート・タイプが、このダイアログの「アラート」タブに表示されます。複数のアラートを条件で指定できます。
完了すると、フォルト・ポリシー・エディタは図12-16のようになります。
図12-16 フォルト名、説明およびデフォルト・アクションが定義されたフォルト・ポリシー・エディタ
「図12-16 フォルト名、説明およびデフォルト・アクションが定義されたフォルト・ポリシー・エディタ」の説明 -
-
SOAコンポジット・エディタの上で、フォルト・ポリシーのファイルを閉じ、変更の保存を促すプロンプトが表示された際、「はい」をクリックします。図12-17に詳細を示します。
これでポリシー構成が完了しました。フォルト・ポリシー・バインディングにフォルト・ポリシーを関連付ける準備ができています。
12.4.3 自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法
この項では、フォルト・ポリシーを手動で設計する方法について説明します。「自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法」で説明されているように、フォルト・ポリシーをフォルト・ポリシー・ウィザードで設計することが推奨アプローチです。
12.4.3.1 自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成
自動フォルト・リカバリに対するフォルト・ポリシー・ファイルを手動で作成するには:
ノート:
あらかじめシードされているリカバリ・アクションのタグ名(ora-retry
、ora-human-intervention
、ora-terminate
など)は、単なるサンプルです。これらの名前は各自の環境に適した名前に置換できます。
condition
、action
およびalert
のセクションが完全に定義されているフォルト・ポリシー・ファイルは、次のようになります。
ノート:
-
フォルト・ポリシー・ファイルの名前は、単一の固有名に限定されているわけではありません。ただし、これらの名前は、
fault-policy.xsd
スキーマ・ファイルに準拠している必要があります。 -
このフォルト・ポリシー・ファイルは、フォルト名に基づいてフォルトを捕捉する例を示しています。フォルトは、メッセージ・タイプまたはフォルト名(あるいはその両方)に基づいて捕捉することもできます。
<faultName name="myfault" type="fault:faultType">
<?xml version="1.0" encoding="UTF-8"?> <faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <faultPolicy version="2.0.1" id="ModifyAndRecover" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Conditions> <!-- Handle remoteFault system exceptions --> <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault"> <condition> <!--<test>$fault.code="1"</test>--> <alert ref = "ora-jms"/> <alert ref = "ora-email"/> <action ref="default-human-intervention"/> </condition> </faultName> <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault"> <condition> <action ref="default-human-intervention"/> </condition> </faultName> </Conditions> <Alerts> <Alert id="ora-email"> <email> <To>joe.smith@example.com</To> <CC>joe.smith@example.com</CC> </email> </Alert> <Alert id="ora-jms"> <JMS propertySet="jms-props"> <Headers> <property name="correlationId">myvalue</property> <property name="correlationId1">myvalue1</property> </Headers> </JMS> </Alert> </Alerts> <Actions> <!-- Generics --> <Action id="default-terminate"> <abort/> </Action> <Action id="default-replay-scope"> <replayScope/> </Action> <Action id="default-rethrow-fault"> <rethrowFault/> </Action> <Action id="default-human-intervention"> <humanIntervention/> </Action> <Action id="ora-retry-with-human-intervention"> <retry> <retryCount>1</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> <retryFailureAction ref="default-terminate"/> </retry> </Action> </Actions> <Properties> <propertySet name="jms-props"> <property name="jmsDestination">MyQueue</property> <property name="connectionFactory">jms/fabric/ehconnectionfactory</property> </propertySet> </Properties> </faultPolicy> </faultPolicies>
12.4.3.2 フォルト・ポリシー・バインディングへのフォルト・ポリシーの関連付け
ノート:
フォルト・ポリシー・バインディング・ファイルは、fault-bindings.xml
という名前にする必要があります。これは、fault-bindings.xsd
スキーマ・ファイルに準拠しています。
フォルト・ポリシー・バインディングにフォルト・ポリシーを関連付けるには:
12.4.3.3 その他のフォルト・ポリシーおよびフォルト・ポリシー・バインディング・ファイルのサンプル
この項では、フォルト・ポリシーとフォルト・ポリシー・バインディング・ファイルのその他のサンプルを示します。次の例にfault-policies.xml
ファイルの内容を示します。
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
id="CRM_ServiceFaults"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<!-- Fault if wsdlRuntimeLocation is not reachable -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:remoteFault">
<condition>
<test>$fault.code="WSDLReadingError"</test>
<action ref="ora-terminate"/>
</condition>
<condition>
<action ref="ora-java"/>
</condition>
</faultName>
<!-- Fault if location port is not reachable-->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:bindingFault">
<!--ORA-00001: unique constraint violated on insert-->
<condition>
<test>$fault.code="1"</test>
<action ref="ora-java"/>
</condition>
<!--ORA-01400: cannot insert NULL -->
<condition>
<test xmlns:test="http://test">$fault.code="1400"</test>
<action ref="ora-terminate"/>
</condition>
<!--ORA-03220: required parameter is NULL or missing -->
<condition>
<test>$fault.code="3220"</test>
<action ref="ora-terminate"/>
</condition>
<condition>
<action ref="ora-retry-crm-endpoint"/>
</condition>
</faultName>
<!-- Business faults -->
<!-- Fault comes with a payload of error, make sure the name space is
provided here or at root level -->
<faultName xmlns:credit="http://services.otn.com"
name="credit:NegativeCredit">
<!-- you get this fault when SSN starts with 0-->
<condition>
<test>$fault.payload="Bankruptcy Report"</test>
<alert ref = "ora-email"/>
<action ref="ora-human-intervention"/>
<!--action ref="ora-retry"/-->
</condition>
<!-- you get this fault when SSN starts with 1-->
<condition>
<test>$fault.payload="Bankruptcy Report-abort"</test>
<action ref="ora-terminate"/>
</condition>
<!-- you get this fault when SSN starts with 2-->
<condition>
<test>$fault.payload="Bankruptcy Report-rethrow"</test>
<action ref="ora-rethrow-fault"/>
</condition>
<!-- you get this fault when SSN starts with 3-->
<condition>
<test>$fault.payload="Bankruptcy Report-replay"</test>
<action ref="ora-replay-scope"/>
</condition>
<!-- you get this fault when SSN starts with 4-->
<condition>
<test
xmlns:myError="http://services.otn.com">$fault.payload="Bankruptcy
Report-human"</test>
<action ref="ora-human-intervention"/>
</condition>
<!-- you get this fault when SSN starts with 5-->
<condition>
<test>$fault.payload="Bankruptcy Report-java"</test>
<action ref="ora-java"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="ora-java"/>
<retrySuccessAction ref="ora-java"/>
</retry>
</Action>
<Action id="ora-retry-crm-endpoint">
<retry>
<retryCount>5</retryCount>
<retryFailureAction ref="ora-java"/>
<retryInterval>5</retryInterval>
<retrySuccessAction ref="ora-java"/>
</retry>
</Action>
<Action id="ora-replay-scope">
<replayScope/>
</Action>
<Action id="ora-rethrow-fault">
<rethrowFault/>
</Action>
<Action id="ora-human-intervention">
<humanIntervention/>
</Action>
<Action id="ora-terminate">
<abort/>
</Action>
<Action id="ora-java">
<!-- this is user provided class-->
<javaAction
className="com.oracle.bpel.client.config.faultpolicy.TestJavaAction"
defaultAction="ora-terminate" propertySet="prop-for-billing">
<returnValue value="REPLAY" ref="ora-terminate"/>
<returnValue value="RETRHOW" ref="ora-rethrow-fault"/>
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>
</Actions>
<Properties>
<propertySet name="prop-for-billing">
<property name="user_email_recipient">bpeladmin</property>
<property name="email_recipient">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>
次の例に、fault-policies.xml
に定義されているフォルト・ポリシーを関連付けるfault-bindings.xml
ファイルを示します。
<?xml version="1.0" encoding="UTF-8"?> <faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <composite faultPolicy="ConnectionFaults"/> <component faultPolicy="ServiceFaults"> <name>Component1</name> <name>Component2</name> </component> <!-- Below listed component names use polic CRM_SeriveFaults --> <component faultPolicy="CRM_ServiceFaults"> <name>HelloWorld</name> <name>ShippingComponent</name> <name>AnotherComponent"</name> </component> <!-- Below listed reference names and port types use polic CRM_ServiceFaults --> <reference faultPolicy="CRM_ServiceFaults"> <name>creditRatingService</name> <name>anotherReference</name> <portType xmlns:credit="http://services.otn.com">credit:CreditRatingService</portType> <portType xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/insert/">db:insert_ plt</portType> </reference> <reference faultPolicy="test1"> <name>CreditRating3</name> </reference> </faultPolicyBindings>
12.4.3.4 複数の拒否ハンドラがあるフォルト・ポリシーの設計
拒否メッセージのアクション・ハンドラを使用するフォルト・ポリシーを設計する際は、実行できる書込みアクションが1つのみであることに注意してください。次の例に示すように、複数の拒否ハンドラを定義している場合も、複数の書込みアクションは実行できません。この場合、定義されている最初の拒否ハンドラ(この例ではora-queue
)のみが実行されます。
<faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages" name="rjm:FileIn"> <condition> <action ref="ora-queue"/> </condition> </faultName> <faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages" name="rjm:FileIn"> <condition> <action ref="ora-file"/> </condition> </faultName>
12.4.4 フォルト・ポリシーの実行方法
フォルト・ポリシーは、SOAコンポジット・アプリケーションの一部としてデプロイします。デプロイメント後は、フォルト・リカバリ・アクションをOracle Enterprise Manager Fusion Middleware Controlから実行できます。終了、再試行、再スロー、Javaなどのアクションは、コンポジットの実行の一部として再試行されます。ユーザーが明示的に実行する必要ありません。管理者操作アクションはOracle Enterprise Manager Fusion Middleware Controlから手動で実行できます。
-
アクティビティの再試行
-
変数の変更(フォルトが発生したアクティビティに使用可能)
-
インスタンスの続行(アクティビティを成功としてマーク)
-
例外の再スロー
-
インスタンスの中断
-
スコープの再実行例外のスロー
詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。
12.4.5 Javaアクション・フォルト・ポリシーの使用方法
Javaアクション・フォルト・ポリシーを使用する際は、次の点に注意してください。
-
用意されているJavaクラスは、特定のインタフェースに従っています。このインタフェースは文字列を戻します。実行後に取得する出力およびフォルト・ポリシーには、複数の値を指定できます。
-
実装されているメソッドの出力値(戻り値)からフォルト・ポリシーへのマッピングを指定することで、追加のフォルト・ポリシーを実行できます。
-
ReturnValue
が指定されていない場合は、次の例に示すように、デフォルトのフォルト・ポリシーが実行されます。
<Action id="ora-java"> <javaAction className="mypackage.myclass" defaultAction="ora-human-intervention" propertySet="prop-for-billing"> <!--defaultAction is a required attribute, but propertySet is optional--> <!-- attribute--> <ReturnValue value="RETRY" ref="ora-retry"/> <!--value is not nilable attribute & cannot be empty--> <ReturnValue value="RETRHOW" ref="ora-rethrow-fault"/> </javaAction> </Action>
表12-7に、ReturnValue
の使用例を示します。
表12-7 システムによるJavaアクション・フォルト・ポリシーの解釈
コード | 説明 |
---|---|
<ReturnValue value="RETRY" ref="ora-retry"/> |
メソッドから |
<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
です。
次の例に示すように、IFaultRecoveryJavaClass
インタフェースには2つのメソッドがあります。
public interface IFaultRecoveryJavaClass { public void handleRetrySuccess( IFaultRecoveryContext ctx ); public String handleFault( IFaultRecoveryContext ctx ); }
次の詳細に注意してください。
-
handleRetrySuccess
は、再試行に成功した場合に起動されます。再試行ポリシーは、retrySuccessAction
のJavaアクションにチェーンします。 -
handleFault
は、javaAction
タイプのポリシーを実行する際に起動されます。 -
フォルト・ポリシー・クラスは、次の2つのいずれかの方法でパッケージ化およびデプロイされます。
-
SOAコンポジット・アプリケーションを使用してJavaクラスをパッケージ化します。
-
Javaクラスを複数のSOAコンポジット・アプリケーションで共有する必要がある場合は、共有場所(
$MW_HOME/soa/soa/ modules/oracle.soa.ext_11.1.1
など)に置きます。共有場所には、クラス・パスで使用できるようにするためのJavaクラスの配置方法を説明するreadme
ファイルが含まれています。
-
次の例にIFaultRecoveryContext
で使用可能なデータを示します。
public interface IFaultRecoveryContext { /** * Gets implementation type of the fault. * @return */ public String getType(); /** * @return Get property set of the fault policy action being executed. */ public Map getProperties(); /** * @return Get fault policy id of the fault policy being executed. */ public String getPolicyId(); /** * @return Name of the faulted partner link. */ public String getReferenceName(); /** * @return Port type of the faulted reference . */ public QName getPortType(); }
このインタフェースのサービス・エンジン実装では、さらに詳細な情報が提供されます(たとえば、Oracle BPEL Process Manager)。次の例に詳細を示します。
public class BPELFaultRecoveryContextImpl extends BPELXExecLetUtil implements IBPELFaultRecoveryContext, IFaultRecoveryContext{ ... }
次の例に示すように、Oracle BPEL Process Manager固有のデータは、IBPELFaultRecoveryContext
を使用して入手できます。
public interface IBPELFaultRecoveryContext { public void addAuditTrailEntry(String message); public void addAuditTrailEntry(String message, Object detail); public void addAuditTrailEntry(Throwable t); /** * @return Get action id of the fault policy action being executed. */ public String getActionId(); /** * @return Type of the faulted activity. */ public String getActivityId(); /** * @return Name of the faulted activity. */ public String getActivityName(); /** * @return Type of the faulted activity. */ public String getActivityType(); /** * @return Correleation id of the faulted activity. */ public String getCorrelationId(); /** * @return BPEL fault that caused the invoke to fault. */ public BPELFault getFault(); /** * @return Get index value of the instance */ public String getIndex(int i); /** * @return get Instance Id of the current process instance of the faulted * activity. */ public long getInstanceId(); /** * @return Get priority of the current process instance of the faulted * activity. */ public int getPriority(); /** * @return Process DN. */ public ComponentDN getProcessDN(); /** * @return Get status of the current process instance of the faulted * activity. */ public String getStatus(); /** * @return Get title of the current process instance of the faulted * activity. */ public String getTitle(); public Object getVariableData(String name) throws BPELFault; public Object getVariableData(String name, String partOrQuery) throws BPELFault; public Object getVariableData(String name, String part, String query) throws BPELFault; /** * @param priority * Set priority of the current process instance of the faulted * activity. * @return */ public void setPriority(int priority); /** * @param status * Set status of the current process instance of the faulted * activity. */ public void setStatus(String status); /** * @param title * Set title of the current process instance of the faulted * activity. * @return */ public String setTitle(String title); public void setVariableData(String name, Object value) throws BPELFault; public void setVariableData(String name, String partOrQuery, Object value) throws BPELFault; public void setVariableData(String name, String part, String query, Object value) throws BPELFault; }
次の例は、javaAction
の実装例を示しています。
public class TestJavaAction implements IFaultRecoveryJavaClass { public void handleRetrySuccess(IFaultRecoveryContext ctx) { System.out.println("This is for retry success"); handleFault(ctx); } public String handleFault(IFaultRecoveryContext ctx) { System.out.println("-----Inside handleFault-----\n" + ctx.toString()); dumpProperties(ctx.getProperties()); /* Get BPEL specific context here */ BPELFaultRecoveryContextImpl bpelCtx = (BPELFaultRecoveryContextImpl) ctx; bpelCtx.addAuditTrailEntry("hi there"); System.out.println("Policy Id" + ctx.getPolicyId()); ... }
12.4.6 Oracle BPM Suiteに対してフォルト・ポリシーを設計する方法
Oracle BPM Suiteに対してフォルト・ポリシーを設計し、実行できます。詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発の「BPMでのフォルト処理の使用」を参照してください。
12.4.7 フォルト・ポリシーを同期BPELプロセスで設計する方法に関する必知事項
フォルト・ポリシーを同期プロセスで設計する際、次のアクションを指定しないでください。これらのアクションによりデハイドレーションが同期プロセスで発生し、タイムアウトになります。
-
再試行
-
管理者操作
-
Terminate
12.4.8 インスタンス再試行回数を超過した場合のフォルト管理動作に関する必知事項
インスタンスをリカバリするフォルト・ポリシーをora-retry
アクションで構成し、指定したインスタンス再試行回数を超過すると、そのインスタンスはopen.faulted
(進行中)としてマークされます。このインスタンスは引き続きアクティブです。
インスタンスをopen.faulted
としてマークすることで、そのインスタンスの消失が防止されます。フォルト・ポリシー・ファイルのora-retry
アクションの後には、次のような別のフォルト処理アクションを構成できます。
-
ora-human-intervention
アクションを構成して、インスタンスのリカバリをOracle Enterprise Manager Fusion Middleware Controlから手動で実行します。 -
ora-terminate
アクションを構成し、インスタンスをクローズ(closed.faulted
としてマーク)して再試行されないようにします。
ただし、フォルト・ポリシー・ファイルでora-retry
アクションの後に実行されるアクションを設定していない場合に、インスタンス再試行回数を超過すると、インスタンスはopen.faulted
としてマークされたままになり、リカバリはインスタンスの処理を試行します。
たとえば、次のコードに示すフォルト・ポリシー・ファイルでは、ora-retry
の後にアクションが定義されていません。
<Action id="ora-retry"> <retry> <retryCount>2</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> </retry> </Action>
この場合は、次のアクションが実行されます。
-
(前述のフォルト・ポリシー・コードを使用してフォルトを処理する)invokeアクティビティが試行されます。
-
間隔を増やして2回の再試行(2秒後、次に4秒後)が実行されます。
-
すべての再試行に失敗した場合は、次のアクションが実行されます。
-
詳細なフォルト・エラー・メッセージが監査証跡に記録されます。
-
インスタンスが
open.faulted
(進行中)としてマークされます。 -
インスタンスが選択され、invokeアクティビティが再試行されます。
-
-
リカバリにも失敗する場合があります。その場合は、invokeアクティビティが再実行されます。追加の監査メッセージが記録されます。
12.4.9 フォルト・ポリシー再試行中のバインディング・レベル再試行に関する必知事項
アウトバウンド方向のJCAレベルの再試行とフォルト・ポリシー・ファイル内の再試行アクションの両方を備えたアダプタで、アウトバウンド障害に対する再試行アクションをテストしている場合は、そのJCAレベル(またはバインディング・レベル)再試行がフォルト・ポリシー再試行の中で実行されます。たとえば、図12-22に示すアプリケーションを設計したとします。
composite.xml
ファイルでは、次に示す再試行パラメータを指定します。
<property name="jca.retry.count" type="xs:int" many="false" override="may">2</property> <property name="jca.retry.interval" type="xs:int" many="false" override="may">2</property> <property name="jca.retry.backoff" type="xs:int" many="false" override="may">2</property>
アウトバウンド方向のEQ参照バインディング・コンポーネントのフォルト・ポリシー・ファイルでは、次のコードに示すアクションを指定します。
<retryCount>3</retryCount> <retryInterval>3</retryInterval>
アウトバウンド障害が発生する場合は、フォルト・ポリシー再試行中にJCA再試行が実行されることが想定されます。フォルト・ポリシーの1回目の再試行時に、JCA再試行がコールされます。この例では、フォルト・ポリシーの再試行ごとに、間隔が2
秒で指数バックオフが2
のJCA再試行が2
回実行されます。
-
フォルト・ポリシー再試行1:
-
JCA再試行1 (
2
秒間隔) -
JCA再試行2 (
4
秒間隔)
-
-
フォルト・ポリシー再試行2:
-
JCA再試行1 (
2
秒間隔) -
JCA再試行2 (
4
秒間隔)
-
-
フォルト・ポリシー再試行3:
-
JCA再試行1 (
2
秒間隔) -
JCA再試行2 (
4
秒間隔)
-
12.5 BPEL実行時フォルトの捕捉
BPEL実行時フォルトは、名前付きのBPELフォルトとして捕捉できます。bindingFault
およびremoteFault
はメッセージに関連付けることができます。このアクションにより、faultHandler
でフォルトの詳細を取得できます。
12.6 getFaultAsString XPath式関数によるフォルト詳細の取得
可能なフォルトを捕捉できるようにcatchAllアクティビティが用意されています。ただし、BPELには、取得されたフォルトの詳細情報を取得するためのメソッドが用意されていません。詳細情報を取得するにはgetFaultAsString()
XPath拡張関数を使用します。
12.6.1 getFaultAsString XPath拡張関数によるフォルト詳細の取得方法
次の例は、この関数の使用方法を示しています。
<catchAll>
<sequence>
<assign>
<from expression="bpelx:getFaultAsString()"/>
<to variable="faultVar" part="message"/>
</assign>
<reply faultName="ns1:myFault" variable="faultVar" .../>
</sequence>
</catchAll>
詳細は、「getFaultAsString」を参照してください。
12.7 throwアクティビティによる内部フォルトのスロー
BPELアプリケーションでは、フォルト・メッセージの生成および受取りができます。throwアクティビティには3つの要素(それ自体の名前、フォルトの名前およびフォルト変数)があります。throwアクティビティによってスローされるフォルトはBPEL内部のフォルトです。throwアクティビティは、クライアントと通信する非同期プロセスには使用できません。throwアクティビティの構文には、スロー名、フォルト名およびフォルト変数を指定します。
<throw name="delay" faultName="nsPrefix:fault-1" faultVariable="fVar"/>
12.8 rethrowアクティビティによるフォルトの再スロー
rethrowアクティビティは、すぐ外側を囲んでいるフォルト・ハンドラによって最初に捕捉されたフォルトを再スローします。フォルト・ハンドラ内(catchアクティビティ、catchAllアクティビティ内など)では、rethrowアクティビティのみ使用します。rethrowアクティビティは、捕捉されたフォルト(元のフォルトのフォルト名およびフォルト・データ(存在する場合))を再スローするために、フォルト・ハンドラで使用されます。rethrowアクティビティは、フォルト・データに対する変更を無視する必要があります。たとえば:
-
フォルト・ハンドラがフォルト・データを変更した後、rethrowアクティビティをコールした場合、元のフォルト・データが再スローされ、変更されたフォルト・データは再スローされません。
-
要素を使用して1つのパーツが定義されたメッセージ・タイプ・フォルトが、同じ要素タイプを検索しているフォルト・ハンドラによって捕捉されるようにする機能を使用してフォルトが捕捉された場合、rethrowアクティビティは元のメッセージ・タイプ・データを再スローします。
ノート:
このアクティビティは、BPELバージョン2.0プロジェクトでサポートされています。
12.8.2 フォルト再スロー時の処理内容
次の例に、rethrowアクティビティの設計が完了した後の.bpel
ファイルを示します。rethrowアクティビティはフォルト・ハンドラ(catchアクティビティ)の内側にあります。
<scope name="scope1"> <faultHandlers> <catch faultName="tns:error" faultVariable="tmpVar" faultElement="tns:fault"> <sequence> <assign> <copy> <from>concat('caught fault: ', $tmpVar)</from> <to>$output.payload</to> </copy> </assign> <rethrow name="Rethrow_1"/> </sequence> </catch> </faultHandlers> <throw faultName="tns:error" faultVariable="fault"/> </scope>
12.9 外部フォルトを返す
BPELプロセス・サービス・コンポーネントは、内部フォルトのスローとは対照的に、別のアプリケーションにフォルトを送信して問題を提示できます。同期操作では、replyアクティビティがフォルトを返すことができます。非同期操作では、invokeアクティビティがこの機能を実行します。
12.9.1 同期相互作用でフォルトを返す方法
次の例に、同期相互作用でフォルトを返すreplyアクティビティの構文を示します。
<reply partnerlinke="partner-link-name
" portType="port-type-name
" operation="operation-name
" variable="variable-name
" (optional) faultName="fault-name
"> </reply>
同期リクエストに対して常にフォルトを返すことはあまり有効ではありません。それよりも、アクティビティを条件分岐に組み込み、リクエストされたデータを使用できる場合に最初のブランチが実行されるようにする方が効果的です。リクエストされたデータを使用できない場合、BPELプロセス・サービス・コンポーネントはそのことを示すフォルトを返します。
詳細は、次の章を参照してください。
-
同期相互作用については、「BPELプロセスからの同期Webサービスの起動」を参照してください
-
条件構造の設定については、「BPELプロセスでの条件分岐の使用」を参照してください
12.9.2 非同期相互作用でフォルトを返す方法
非同期相互作用では、クライアントはリプライを待機しません。このため、フォルトを返すためにreplyアクティビティが使用されることはありません。かわりに、BPELプロセス・サービス・コンポーネントは通常はリクエストされた情報を受け取る同じポート・タイプのコールバック操作を使用して、invokeアクティビティによってフォルトを返します。
非同期相互作用の詳細は、「BPELプロセスからの非同期Webサービスの起動」を参照してください。
12.10 scopeアクティビティによるアクティビティ・グループの管理
scopeアクティビティは、他のアクティビティに対してコンテナおよびコンテキストを提供します。scopeは、フォルト、イベント、補正、データ変数および相関セットに対するハンドラを提供します。scopeアクティビティを使用すると、機能構造をグループ化することでBPELフローが単純化されます。このグループ化により、Oracle BPELデザイナでは機能構造を閉じて1つの要素として表示できます。
次の例は、名前がScope_FulfillOrder
であるscopeを示します。このscopeは、注文品の出荷方法を判断するFulfillOrder
Oracle Mediatorコンポーネントを起動します。
<scope name="Scope_FulfillOrder"> <variables> <variable name="lFulfillOrder_InputVariable" messageType="ns17:requestMessage"/> </variables> <sequence> <assign name="Assign_OrderData"> <copy> <from variable="gOrderInfoVariable" query="/ns4:orderInfoVOSDO"/> <to variable="lFulfillOrder_InputVariable" part="request" query="/ns4:orderInfoVOSDO"/> </copy> </assign> <invoke name="Invoke_FulfillOrder" inputVariable="lFulfillOrder_InputVariable" partnerLink="FulfillOrder.FulfillOrder" portType="ns17:execute_ptt" operation="execute"/> </sequence> </scope>
12.10.2 scopeアクティビティへの説明ノートおよびイメージの追加方法
scopeアクティビティには、スコープの機能に関する簡単な説明を提供する説明ノートを追加できます。スコープのグラフィック・イメージを変更することもできます。説明ノートおよびイメージは、Oracle BPELデザイナに表示されます。これらの表示により、スコープをより簡単に理解できるようになります。
説明ノートおよびイメージをscopeアクティビティに追加するには:
12.10.3 scopeアクティビティ作成後の処理内容
次の例に、設計完了後の.bpel
ファイルのscopeアクティビティを示します。Scope_AuthorizeCreditCard
scopeアクティビティは、次のアクションを実行する各アクティビティで構成されています。
-
クレジット・カード番号がない、またはクレジット・タイプが有効でないためにフォルトになった注文を捕捉するcatchアクティビティ。
-
承認されない注文に対してフォルトをスローするthrowアクティビティ。
-
クレジット・カード・タイプ、クレジット・カード番号および購入金額を取得し、この情報を
CreditCardAuthorizationService
サービスの入力変数に割り当てるassignアクティビティ。 -
CreditCardAuthorizationService
サービスをコールして顧客情報を取得するinvokeアクティビティ。 -
クレジット・カード検証の結果を確認するswitchアクティビティ。
<scope name="Scope_AuthorizeCreditCard"> <variables> <variable name="lCreditCardInput" messageType="ns2:CreditAuthorizationRequestMessage"/> <variable name="lCreditCardOutput" messageType="ns2:CreditAuthorizationResponseMessage"/> </variables> <faultHandlers> <catch faultName="bpws:selectionFailure"> <sequence> <assign name="Assign_noCCNumber"> <copy> <from expression="string('CreditCardCheck - NO CreditCard')"/> <to variable="gOrderProcessorFaultVariable" part="code"/> </copy> </assign> <throw name ="Throw_NoCreditCard" faultVariable="gOrderProcessorFaultVariable" faultName="ns9:OrderProcessingFault"/> </sequence> </catch> <catch faultName="ns2:InvalidCredit"> <sequence> <assign name="Assign_InvalidCreditFault"> <copy> <from expression="concat(bpws:getVariableData ('gOrderInfoVariable','/ns4:orderInfoVOSDO/ ns4:CardTypeCode'), ' is not a valid creditcard type')"/> <to variable="gOrderProcessorFaultVariable" part="summary"/> </copy> <copy> <from expression="string('CreditCardCheck - NOT VALID')"/> <to variable="gOrderProcessorFaultVariable" part="code"/> </copy> </assign> <throw name="Throw_OrderProcessingFault" faultName="ns9:OrderProcessingFault" faultVariable="gOrderProcessorFaultVariable"/> </sequence> </catch> </faultHandlers> <sequence> <assign name="Assign_CreditCheckInput"> <copy> <from variable="gOrderInfoVariable" query="/ns4:orderInfoVOSDO/ns4:OrderTotal"/> <to variable="lCreditCardInput" part="Authorization" query="/ns8:AuthInformation/ns8:PurchaseAmount"/> </copy> <copy> <from variable="gOrderInfoVariable" query="/ns4:orderInfoVOSDO/ns4:CardTypeCode"/> <to variable="lCreditCardInput" part="Authorization" query="/ns8:AuthInformation/ns8:CCType"/> </copy> <copy> <from variable="gOrderInfoVariable" query="/ns4:orderInfoVOSDO/ns4:AccountNumber"/> <to variable="lCreditCardInput" part="Authorization" query="/ns8:AuthInformation/ns8:CCNumber"/> </copy> </assign> <invoke name="InvokeCheckCreditCard" inputVariable="lCreditCardInput" outputVariable="lCreditCardOutput" partnerLink="CreditCardAuthorizationService" portType="ns2:CreditAuthorizationPort" operation="AuthorizeCredit"/> <switch name="Switch_EvaluateCCResult"> <case condition="bpws:getVariableData('lCreditCardOutput','status',' /ns8:status') != 'APPROVED'"> <bpelx:annotation> <bpelx:pattern>status <> approved</bpelx:pattern> </bpelx:annotation> <throw name="Throw_Fault_CC_Denied" faultName="client:OrderProcessorFault"/> </case> /switch> </sequence> </scope>
12.10.4 スコープに関する必知事項
スコープは、CPU能力とメモリーを大量に使用する可能性があるため、過度の使用は避けてください。sequenceアクティビティを使用することで、CPUとメモリーの使用量を抑制し、大きいBPELフローを見やすくできます。
12.10.5 スコープ内のフォルト・ハンドラの使用方法
フォルトが処理されていない場合、フォルト状態が作成されてアプリケーション全体に移行し、プロセス全体がフォルト状態になることがあります。これを防ぐには、フォルトを受け取る可能性があるプロセスの一部をスコープ内に配置します。scopeアクティビティには、次のフォルト処理機能が含まれています。
-
スコープ内ではcatchアクティビティが動作し、プロセス全体がフォルト状態になる前に、フォルトおよび例外を捕捉します。catchアクティビティで特定のフォルト名を使用し、個々のフォルトに特定の方法で対応できます。
-
catchAllアクティビティは、名前が指定されたcatchアクティビティでは処理されないフォルトを捕捉します。
次の例に、catchおよびcatchAllアクティビティの構文を示します。x:foo
という名前のフォルトがスローされたとします。フォルトがフォルト・データを渡さない場合は、最初のcatchが選択されます。フォルトに関連付けられたフォルト・データがある場合、フォルトのデータ・タイプが変数bar
タイプに一致すると、3番目のcatchが選択されます。そうでない場合、デフォルトのcatchAllハンドラが選択されます。最後に、タイプがbar
のタイプに一致し、名前がx:foo
でないフォルト変数を持つフォルトは2番目のcatchで処理されます。その他のすべてのフォルトはデフォルトのcatchAllハンドラによって処理されます。
<faulthandlers> <catch faultName="x:foo"> <empty/> </catch> <catch faultVariable="bar"> <empty/> </catch> <catch faultName="x:foo" faultVariable="bar"> <empty/> </catch> <catchAll> <empty/> </catchAll> </faulthandlers>
12.10.6 idempotentプロパティとフォルト処理に関する必知事項
composite.xml
ファイルでidempotent
デプロイメント・ディスクリプタのプロパティがfalse
に設定されている場合、パートナ・リンクの起動が失敗しても、invokeアクティビティからリカバリは開始されません。invokeアクティビティの再試行をidempotent
プロパティに依存することはお薦めいたしません。かわりに、BPELプロセス内に設計したフォルト処理(catchAllアクティビティの場合など)によって、リカバリを試みます。ベスト・プラクティスとして、かわりにフォルト・ポリシーを使用してinvokeアクティビティを再試行することをお薦めします。
表12-8は、idempotent
プロパティがfalse
に設定されていて、パートナ・リンクの起動が成功した場合と失敗した場合の動作を示しています。
表12-8 idempotentプロパティがfalseに設定されている場合のリカバリ動作
パートナ・リンクの起動 | 結果 |
---|---|
成功 |
invokeアクティビティは実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。 |
不成功、かつBPELプロセスにcatchAllアクティビティなどのフォルト処理が含まれている |
リカバリはcatchAllアクティビティから開始され、invokeアクティビティからは開始されません。 |
不成功、かつBPELプロセスにフォルト・ポリシーが含まれている |
フォルト・ポリシーが使用されて、invokeアクティビティのリカバリが試みられます。これは、推奨アプローチです。 |
たとえば、BPELプロセスに次の設計が含まれているとします。
-
invokeアクティビティによってパートナ・リンク(この例では、
myPartnerLink
という名前です)が起動されます。 -
composite.xml
ファイルで、idempotent
デプロイメント・ディスクリプタのプロパティがfalse
に設定されています。<property name="bpel.partnerLink.myPartnerLink.idempotent">false</property>
この設定により、BPELプロセスはこのアクティビティの実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。
このプロパティは、「パートナ・リンクの編集」ダイアログで
false
に設定することもできます。図12-29に詳細を示します。詳細は、「パートナ・リンク操作レベルでの冪等性の管理」を参照してください。
-
scopeアクティビティのcatchAllアクティビティ・エラー・ハンドラによってフォルトが捕捉され、ロールバック・フォルトがスローされます。
パートナ・リンクに対するinvokeアクティビティによる起動が失敗した場合、リカバリはcatchAllアクティビティ・エラー・ハンドラから開始され、invokeアクティビティからは開始されません。Oracle Enterprise Manager Fusion Middleware ControlのBPELプロセスのflowアクティビティで、catchAllアクティビティからのリカバリを監視できます。
これは設計によります。idempotent
プロパティの設定は、invokeアクティビティの実行の後に確認されます。実行に失敗し、例外が発生した場合、idempotent
プロパティの設定には到達しません。BPELプロセス・サービス・エンジンによって、catchAllアクティビティを開いた直後のインスタンスが保存されます。idempotent
プロパティがfalse
に設定されているため、このインスタンスを保存する必要があります。これが、リカバリがcatchAllアクティビティで再開される理由です。
かわりに、失敗したinvokeアクティビティをフォルト・ポリシーでリカバリすることをお薦めします。フォルト・ポリシーの作成の詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。
idempotent
プロパティの詳細は、「デプロイメント・ディスクリプタのプロパティの概要」を参照してください。
12.10.8 スコープでのcatchアクティビティ作成時の処理内容
次の例に、設計完了後の.bpel
ファイルのcatchアクティビティを示します。selectionFailure
catchアクティビティはクレジット・カード番号がない注文を捕捉し、InvalidCredit
catchアクティビティは有効でないクレジット・タイプを捕捉します。
<faultHandlers> <catch faultName="bpws:selectionFailure"> <sequence> <assign name="Assign_noCCNumber"> <copy> <from expression="string('CreditCardCheck - NO CreditCard')"/> <to variable="gOrderProcessorFaultVariable" part="code"/> </copy> </assign> <throw name ="Throw_NoCreditCard" faultVariable="gOrderProcessorFaultVariable" faultName="ns9:OrderProcessingFault"/> </sequence> </catch> <catch faultName="ns2:InvalidCredit"> <sequence> <assign name="Assign_InvalidCreditFault"> <copy> <from expression="concat(bpws:getVariableData ('gOrderInfoVariable','/ns4:orderInfoVOSDO/ns4:CardTypeCode'), ' is not a valid creditcard type')"/> <to variable="gOrderProcessorFaultVariable" part="summary"/> </copy> <copy> <from expression="string('CreditCardCheck - NOT VALID')"/> <to variable="gOrderProcessorFaultVariable" part="code"/> </copy> </assign> <throw name="Throw_OrderProcessingFault" faultName="ns9:OrderProcessingFault" faultVariable="gOrderProcessorFaultVariable"/> </sequence> </catch> </faultHandlers>
catchまたはcatchAllアクティビティが選択されていない場合、フォルトが現在のスコープによって捕捉されず、すぐ外側を囲んでいるスコープにスローされます。グローバル・プロセス・スコープでフォルトが発生し(またはグローバル・プロセス・スコープに再スローされ)、グローバル・レベルでフォルトに適合するフォルト・ハンドラがない場合、プロセスが異常終了します。これは、terminateアクティビティ(「BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止」で説明)が実行されたような状況になります。
12.10.9 emptyアクティビティによる操作なしの命令のビジネス・プロセスへの挿入方法
何もしないアクティビティが必要になることがよくあります。たとえば、フォルトを捕捉して抑制する必要がある場合などです。この場合、emptyアクティビティを使用すると、操作なしの命令をビジネス・プロセスに挿入できます。
emptyアクティビティを作成するには:
12.11 replayアクティビティによるscopeアクティビティ内でのアクティビティの再実行
scopeアクティビティ内にreplayを作成すると、スコープ内のすべてのアクティビティを再実行できます。
12.11.2 replayアクティビティ作成時の処理内容
次の例は、BPELバージョン2.0をサポートするBPELプロジェクトのreplayアクティビティの設計が完了した後の、.bpel
ファイルを示しています。BPEL 2.0では、replayアクティビティはextensionActivity
要素にラップされます。
<scope name="scope2"> <sequence> <assign> <copy> <from>$counter2 + 1</from> <to>$counter2</to> </copy> </assign> <scope name="scope3"> <sequence> <assign> <copy> <from>$counter + 1</from> <to>$counter</to> </copy> </assign> <if> <condition>$counter = 3</condition> <empty/> <else> <extensionActivity> <bpelx:replay name="ReplayScope" scope="Scope_RetrieveOrder"/> </extensionActivity> </else> </if> </sequence> </scope> </sequence> </scope>
BPEL 1.1では、replayアクティビティはbpelx
拡張要素としてコード化されます。
<bpelx:replay name="ReplayScope" scope="Scope2"/>
12.12 一連の操作を元に戻した後の補正の使用
補正は、BPELプロセス・サービス・コンポーネントが一部の操作を完了した後で一連の操作を完了できず、引き返して前に完了したトランザクションを取り消す必要がある場合に発生します。たとえば、レンタカー、ホテルおよび航空券を予約するようにBPELプロセス・サービス・コンポーネントが設計されている場合、車とホテルは予約でき、その日付の航空券を予約できない場合があります。この場合、BPELフローは戻って車とホテルをキャンセルすることによって、補正を実行します。
scopeアクティビティでは、補正ハンドラは以前に完了した処理ステップをリバースできます。補正ハンドラは、次のいずれかのアクティビティを使用して関連するスコープが正常に完了した後に呼び出すことができます。
-
compensateアクティビティ(BPELバージョン1.1および2.0プロジェクト)
このアクティビティにより、正常に完了したすべての子スコープ、およびまだ補正されていない子スコープの補正ハンドラが、デフォルトの順序で実行されます。
-
compensateScopeアクティビティ(BPELバージョン2.0プロジェクト)
このアクティビティにより、正常に完了した特定のスコープの補正ハンドラが実行されます。
12.12.1 compensateアクティビティの使用
補正ハンドラは、compensateアクティビティを使用することによって起動でき、補正が実行されるスコープ(補正ハンドラが起動されるスコープ)を指定します。スコープの補正ハンドラは、スコープが正常に完了した場合にのみ起動できます。インストールされていない補正ハンドラを起動することは、emptyアクティビティ(操作なし)を使用することと同じです。これにより、フォルト・ハンドラは、ネストされたどのスコープが正常に完了したかを判断するために、状態を使用しなくても済むようになります。インストールされた補正ハンドラが複数回起動されているプロセスのセマンティクスは定義されていません。
compensateアクティビティを明示的に呼び出す機能は、「Business Process Execution Language for Web Services Specification」のアプリケーションで制御されたエラー処理フレームワークの基礎となります。このアクティビティは、ビジネス・プロセスの次の部分でのみ使用できます。
-
補正が実行されるスコープのすぐ外側を囲んでいるスコープのフォルト・ハンドラ内。
-
補正が実行されるスコープのすぐ外側を囲んでいるスコープの補正ハンドラ内。
たとえば:
<compensate scope="RecordPayment"/>
名前によって補正されているスコープがループでネストされている場合、BPELプロセス・サービス・コンポーネントは一連の反復内で補正ハンドラ・インスタンスを逆の順序で起動します。
スコープの補正ハンドラがない場合、デフォルトの補正ハンドラは、すぐ内側に囲まれているスコープの補正ハンドラを、これらのスコープの完了と逆の順序で起動します。
補正フォームでcompensateアクティビティのスコープ名が省略されると、このデフォルトの動作が明示的に起動されます。これは、囲んでいるフォルトまたは補正ハンドラで追加の作業(変数の更新や外部通知の送信、および内側のスコープに対するデフォルト補正の実行など)を実行する必要がある場合に便利です。外側のスコープに付加されたフォルトまたは補正ハンドラのcompensateアクティビティにより、そのスコープ内に直接ネストされた完了スコープに対する補正ハンドラがデフォルトの順序で起動されます。このアクティビティは、外側のスコープ内にネストされたスコープの明示的な起動を除く、その他のユーザー指定の動作と一緒に使用できます。外側のスコープ内にネストされたこのスコープの補正を明示的に起動すると、デフォルトの順序の補正は、適切に機能しません。
12.12.3 compensateアクティビティ作成時の処理内容
scopeアクティビティにインラインで定義された補正ハンドラがある場合、アクティビティの名前はcompensateアクティビティに使用されるスコープの名前です。構文を次の例に示します。
<compensate scope="ncname"? standard-attributes> standard-elements </compensate>
12.12.4 BPEL 2.0のcompensateScopeアクティビティの使用
compensateScopeアクティビティは、すでに正常に完了している特定の内側のスコープで補正を開始するために使用されます。このアクティビティは、フォルト・ハンドラ、別の補正ハンドラまたは終了ハンドラ内からのみ使用します。
compensateScopeアクティビティを作成する場合、すぐ内側に囲まれているスコープを参照する必要があるターゲットを選択します。スコープにはフォルト・ハンドラまたは補正ハンドラを含める必要があります。
12.12.5 compensateScopeアクティビティの作成方法
ノート:
このアクティビティは、BPEL 2.0プロジェクトでサポートされています。
compensateScopeアクティビティを作成するには:
12.12.6 compensateScopeアクティビティ作成時の処理内容
次の例に、compensateScopeアクティビティの設計が完了した後の.bpel
ファイルを示します。compensateScopeアクティビティは、catchallフォルト・ハンドラで定義されます。補正ハンドラを起動するスコープが定義されます。
<scope name="ScopeAssignCreditRating">
<faultHandlers>
<catchAll>
<compensateScope target="ScopeAssignScreditRating2" />
</catchAll>
</faultHandlers>
<sequence>
<scope name="ScopeAssignScreditRating2">
<compensationHandler>
<!-- undo work -->
</compensationHandler>
<!-- do some work -->
</scope>
<!-- do more work -->
<!-- a fault is thrown here; results of ScopeAssignScreditRating2 must be undone -->
</sequence>
</scope>
12.13 terminateアクティビティまたはexitアクティビティによるビジネス・プロセス・インスタンスの停止
次のいずれかのアクティビティを使用して、ビジネス・プロセス・インスタンスを停止できます。
-
exitアクティビティ(BPELバージョン2.0プロジェクト)
-
terminateアクティビティ(BPELバージョン1.1プロジェクト)
12.13.1 BPEL 2.0のexitアクティビティによるビジネス・プロセス・インスタンスの即時終了
exitアクティビティを使用すると、終了処理、フォルト処理または補正処理メカニズムを起動しなくても、すべてのパラレル・ブランチで現在実行中のすべてのアクティビティをただちに終了できます。このアクティビティは、予期しない重大な障害を処理するための適切な理由がない環境で使用すると便利です。
ノート:
未処理の対話もexitアクティビティの影響を受けます。たとえば、プロセスと対話している他のパートナは、到着することのないレスポンスを待機する可能性があります。
12.13.1.2 exitアクティビティ作成時の処理内容
次の例に、exitアクティビティの設計が完了した後の.bpel
ファイルを示します。
<sequence>
<!-- receive input from requester -->
<receive name="receiveInput" partnerLink="client" portType="tns:Test"
operation="process" variable="input" createInstance="yes"/>
<assign>
<copy>
<from>$input.payload</from>
<to>$output.payload</to>
</copy>
</assign>
<!-- respond output to requester -->
<reply name="replyOutput" partnerLink="client"
portType="tns:Test" operation="process" variable="output"/>
<exit/>
</sequence>
12.14 アサーション条件によるフォルトのスロー
リクエスト/レスポンスinvokeアクティビティ、receiveアクティビティ、replyアクティビティ、およびpickアクティビティとscopeアクティビティのonMessageブランチで、コールバック・メッセージの受信時に実行されるBPELバージョン1.1および2.0でのアサーション条件を指定できます。アサーションは、falseと評価された場合に、アクティビティからBPELフォルトがスローされるXPath式を指定します。この条件は、パートナ・コールバック後に多数のswitch、assignおよびthrowアクティビティを作成する可能性がある場合の代替手段として提供されています。
条件を実行するタイミングを次の中から選択できます。
-
Preassert: この条件は、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に実行されます。
-
Postassert: この条件は、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に実行されます。
12.14.1 アサーション条件の作成方法
次のアクティビティでアサーション条件を作成できます。
-
invokeアクティビティ、receiveアクティビティ、replyアクティビティ、OnMessageブランチなどのメッセージ交換アクティビティ
-
XPath式を指定するためのスタンドアロンassertアクティビティ
12.14.1.1 invokeアクティビティ、receiveアクティビティ、replyアクティビティおよびOnMessageブランチでアサート条件を作成する手順:
-
SOAコンポジット・エディタで、BPELプロセス・サービス・コンポーネントをダブルクリックします。
-
「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。
-
receiveアクティビティ、invokeアクティビティ、pickアクティビティまたはor scopeアクティビティをデザイナにドラッグします。
-
receiveアクティビティ、invokeアクティビティ、またはpickアクティビティまたはscopeアクティビティのonMessageブランチを開きます。
-
「アサーション」タブをクリックします。
-
BPEL 2.0プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。それ以外の場合は、ステップ6に進みます。
-
条件を実行するタイミングを選択します。表12-9に詳細を示します。
表12-9 アサーション条件のタブ
作成対象 選択対象 アサート前条件
「アサート前」タブ
アサート後条件
「アサート後」タブ
-
図12-41に示すように、「追加」アイコンをクリックします。
「Assert」ダイアログが表示されます。
-
-
BPEL 1.1プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。
-
図12-42に示すように、「追加」アイコンをクリックします。
-
条件を実行するタイミングを選択します。表12-10に詳細を示します。
表12-10 条件実行のオプション
要素 説明 アサート前
選択すると、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に条件が実行されます。
ノート: フォルト・ポリシーではpreAssert条件からスローされたフォルトは処理されません。postAssert条件からスローされたフォルトのみがサポートされています。フォルト・ポリシーの詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。
アサート後
選択すると、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に条件が実行されます。
選択内容に基づいて、「アサート前」または「アサート後」ダイアログが表示されます。
-
-
図12-43に示すように、アサーション条件に値を指定します。この例では、BPEL 2.0プロジェクトのreceiveアクティビティのアサーション条件に「アサート後」が選択されています。
-
「検索」アイコンをクリックして「フォルト・チューザ」ダイアログから既存のフォルトを選択し、スローする「フォルトQName」を選択します。フォルトの「ネームスペースURI」および「ローカル・パート」フィールドに、独自の値を指定することもできます。「フォルトQName」の指定を省略した場合は、
bpelx:assertFailure
フォルトがスローされます。
-
-
完了後に「OK」をクリックして、アクティビティの「アサーション」タブに戻ります。図12-44に示すように、完成したアサーション条件が表示されます。
-
「適用」をクリックし、「OK」をクリックします。
12.14.2 アサーションを無効にする方法
アサーションは、次のいずれかの方法で無効にできます。
-
Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザ・プロパティDisableAssertsをtrueに設定する方法。
-
次の例に示すように、SOAコンポジット・アプリケーションの
composite.xml
ファイルで、bpel.config.disableAsserts
をtrue
に設定する方法。<component name="AsyncBPELClient"> <implementation.bpel src="AsyncBPELClient.bpel"/> <property name="bpel.config.disableAsserts">true</property> </component>
システムMBeanブラウザ・プロパティを設定する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。
12.14.3 アサーション条件作成時の処理内容
.bpel
ファイルのコード・セグメントは、特定の操作に対する設計完了後の定義を示しています。
次のBPEL1.1の例では、invokeアクティビティのbpelx:assert
条件がfalseと評価された場合(たとえば、0
の信用格付けが発行された場合)は、Negative
Credit
メッセージが返されます。条件がtrueと評価された場合は、invokeアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。
<invoke name="callbackClient" partnerLink="internalwarehouseservice_client" portType="client:InternalWarehouseServiceCallback" operation="processResponse" inputVariable="outputVariable"> <bpelx:assert name="negativeCredit" expression="$crOutput.payload/tns:rating > 0" message="Negative Credit"/> </invoke>
次のBPEL 1.1の例では、スタンドアロンassertアクティビティのbpelx:assert
条件がfalseと評価された場合は、次のメッセージが返されます。
got assertion failure on true expression
条件がtrueと評価された場合は、assertアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。
<bpelx:assert expression="true()bpws:getLinkStatus()" message="'got assertion failure on true expression'"
12.14.4 アサーション条件に関する必知事項
この項では、主要なアサーション条件の概念について説明します。
12.14.4.1 bpelx:postAssertおよびbpelx:preAssert拡張要素
アクティビティに応じて、条件を実行するタイミングを指定するには、invokeアクティビティ、receiveアクティビティ、replyアクティビティ、およびpickアクティビティとscopeアクティビティのonMessageブランチの「アサーション」タブで「追加」アイコンをクリックし、「アサート前」または「アサート後」を選択します。選択内容に基づいて、次のbpelx
拡張要素が使用されます。
-
bpelx:preAssert
: 「アサート前」を選択すると、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に条件が実行されます。 -
bpelx:postAssert
: 「アサート後」を選択すると、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に条件が実行されます。
次の例は、BPEL 1.1におけるreceiveアクティビティ内の複数のbpelx:postAssert
拡張要素を示しています。
<receive name="Receive_1" createInstance="no" variable="Receive_1_processResponse_InputVariable" partnerLink="AsyncBPELService" portType="ns1:AsyncBPELServiceCallback" bpelx:for="'PT10S'" operation="processResponse"> <bpelx:postAssert name="assert1" expression="true()" message="'assert true failed'" faultName="client:fault1"/> <bpelx:postAssert name="assert2" expression="false()" message="'assert false failed'" faultName="client:fault2"/> </receive>
次の例に、BPEL 1.1におけるinvokeアクティビティ内の複数のbpelx:preAssert
拡張要素を示します。
<invoke name="Invoke_1" inputVariable="Invoke_1_process_InputVariable" outputVariable="Receive_1_processResponse_InputVariable" partnerLink="SyncBPELService" portType="ns1:SyncBPELService" operation="process"> <bpelx:preAssert name="assert1" expression="true()" message="'assert true failed'"/> <bpelx:preAssert name="assert2" expression="bpws:getVariableData('counter') = 3" message="concat('The value of counter is ', $counter)"/>
「アサーション」タブの使用の詳細は、「アサーション条件の作成方法」を参照してください。
12.14.4.2 faultName属性とmessage属性の使用
BPEL 1.1では、次の例のスキーマ定義に示すように、bpelx:postAssert
要素のfaultName
属性およびmessage
属性を指定できます。
<invoke | receive | onMessage> standard-elements <bpelx:postAssert name="ncname"? expression="boolean-expr" faultName="QName"+ message="generic-expr"+/> * </invoke | receive | onMessage>
次の例に、faultname
属性とmessage
属性の構文を示します。
<bpelx:postAssert name="Assert_2" message='multiple post assert Greater value fired' faultName="ns2:GreaterValue" expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') < 500"/>
faultName
属性の指定がない場合、フォルトはbpelx:postAssertFailure
にデフォルト設定されます。message
属性の指定がない場合、メッセージ値はアクティビティの名前にデフォルト設定されます。
<bpelx:postAssert expression="boolean-expr" />
アサーション条件がfalseと評価されるたびに、指定のフォルトがスローされます。分析は、パートナWSDL portType
に定義されているフォルトに正しく変換できるように、faultName
QName
に対して実行されます。メッセージ式は、任意のXPath値のタイプ(string、numberまたはboolean)に評価できる一般的な式です。文字列でない値が返された場合は、値の文字列評価が使用されます。
12.14.4.3 複数のアサーション
receiveアクティビティ、invokeアクティビティ、またはpickアクティビティとscopeアクティビティのonMessageブランチでは、複数のアサーションをネストできます。アサーションの評価は、式がfalseと評価されるまでアサーションの宣言順に続行されます。次の例に詳細を示します。
<invoke name="invokeCR" partnerLink="creditRatingService" portType="services:CreditRatingService" operation="process" inputVariable="crInput" outputVariable="crOutput"> <bpelx:postAssert name="negativeCredit" expression="$crOutput.payload/tns:rating > 0" faultName="services:NegativeCredit" message="'Negative Credit'" /> <bpelx:postAssert name="insufficientCredit" expression="$crOutput.payload/tns:rating > 600" faultName="services:InsufficientCredit" message="'Insufficient Credit'" /> </invoke>
前の例では、レスポンスの信用格付けがゼロより大きいことを確認する式のアサーションが最初に評価されます。表12-11に、このアサーションの動作を示します。
表12-11 アサーションの動作
返されたレスポンスの信用格付け | 結果 |
---|---|
ゼロ未満 |
|
ゼロ以上 |
アサーションが正しいため、2番目のアサーションが評価されます。 |
600未満 |
|
600以上 |
アサーションが正しいため、invokeアクティビティからフォルトはスローされません。 |
アサーションは、いくつでもネストできます。アクティビティからフォルトがスローされないためには、指定したすべてのアサーションがtrueと評価される必要があります。
このコンストラクトを使用して、Javaのif...else
if...else
文と同様に、着信ペイロードに対して様々なレベルの検証を適用できます。
検証ロジックに関係なく、フォルトが常にスローされるようにするには、false()
のアサーション式を指定します。これは、Javaのelse
コンストラクトと同じです。
12.14.4.4 組込みおよびカスタムのXPath関数と$variable参照の使用
アサーション条件には、組込みおよびカスタムのXPath関数と$variable
参照も使用できます。次のコードは、いくつかの例を示しています。
<bpelx:postAssert expression="bpws:getVariableData( 'crOutput', 'payload', '/tns:rating' ) > 0" ... /> <bpelx:postAssert expression="custom:validateRating()" ... /> <bpelx:postAssert xmlns:fn='http://www.w3.org/2005/xpath-functions' expression="fn:false()" ... />
XPath式の評価でエラーがスローされると、そのエラーはBPELフォルトにラップされて、アクティビティからスローされます。
アサーションの評価の失敗に起因して、リクエスト/レスポンスinvokeアクティビティ、receiveアクティビティ、またはpickアクティビティやscopeアクティビティのonMessageブランチからスローされるフォルトは、BPELのフォルト管理フレームワークによって捕捉および処理されます。詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。
BPELプロセス・フロー内で捕捉および処理されないフォルトは、操作に対するフォルトがコンポーネントWSDLで宣言されている場合は、BPELコンポーネントからスローされます。操作に対するフォルトが宣言されていない場合、フォルトはFabricInvocationException
(実行時フォルト)に変換されます。このフォルトは、いずれかのコール元コンポーネント(BPELコンポーネントを含む)によって捕捉されますが、フォルトのタイプは、当初スローされたタイプではなくなります(ただし、フォルト・メッセージ文字列については、当初のフォルト・メッセージのトレースが保持されます)。
実行時フォルトの詳細は、「BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要」を参照してください。
フォルト・ポリシーの詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。
12.14.4.5 インスタンス監査証跡に対するイベントのアサーション条件評価ロギング
評価される各アサーション条件によって、イベントがインスタンス監査証跡に記録されます。イベントは、アサーションが無事通過したか、失敗したのかを示します(失敗の場合は、フォルト名とメッセージが出力されます)。イベントも、アサーション要素で指定されたname
属性を含みます。name
属性が指定されていない場合、BPELプロセス・フローのアサーション要素の行番号が使用されます。監査イベントで出力されるアサーション条件は、アサーションを識別するのに便利で、フローをより円滑にデバッグできるようになります。
12.14.4.6 XMLスキーマ・ブール値タイプに評価されない式によるフォルトのスロー
アサーション条件XPath式がXMLスキーマ・ブール値タイプに評価されない場合は、アクティビティからbpelx:postAssertFailure
フォルトがスローされます。エラーを示すインスタンス監査証跡のイベントも記録されます。次の例に詳細を示します。
<bpelx:postAssert expression="bpws:getVariableData( 'crOutput', 'payload', '/tns:rating' ) > 0" ... /> <bpelx:postAssert expression="custom:validateRating()" ... /> <bpelx:postAssert xmlns:fn='http://www.w3.org/2005/xpath-functions' expression="fn:false()" ... />
アサーション式の分析は、BPELコンパイラによって実行され、式がXMLスキーマ・ブール・タイプに評価されない場合は、エラーが報告されます。カスタムXPath関数では、このタイプの分析は実行されません。
12.14.4.7 スタンドアロンassertアクティビティのアサーション条件
BPELプロセス・サービス・コンポーネントのスタンドアロンassertアクティビティで、アサーション条件を作成することもできます。アサーションは、falseと評価された場合に、アクティビティからBPELフォルトがスローされるXPath式を指定します。
bpelx:assert
拡張要素は、スタンドアロンassertアクティビティでアサーションを実装します。
<bpelx:assert name="Assert1" expression="string" message="string"/>
スタンドアロンassertアクティビティの使用方法の詳細は、「アサーション条件の作成方法」を参照してください。
12.14.5 アサート後およびアサート前条件のスキーマおよび構文に関する必知事項
アサーション条件は、ネストされた拡張要素として指定されます。次の例に、BPEL 2.0におけるアサート後条件のスキーマ定義を示します。
<invoke | receive | onMessage> standard-elements <bpelx:postAsserts> <bpelx:postAssert faultName="QName"> <bpelx:expression expressionLanguage="anyURI"?>expression </bpelx:expression> <bpelx:message expressionLanguage="anyURI"?>expression</bpelx:message> </bpelx:postAssert> </bpelx:postAsserts> </invoke | receive | onMessage>
次の例に、BPEL 2.0におけるアサート後条件の構文を示します。
<bpelx:postAsserts> <bpelx:postAssert faultName="ns2:InvalidInput"> <bpelx:expression>number(concat($inputVariable.payload/client:input,'2')) < 500</bpelx:expression> <bpelx:message>"AssertXpathPostInvoke_20 assert fired"</bpelx:message> </bpelx:postAssert> </bpelx:postAsserts>
次の例に、BPEL 1.1におけるアサート後条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。
<invoke | receive | onMessage> standard-elements <bpelx:postAssert name="ncname" expression="boolean-expr" faultName="QName"+ message="generic-expr"+/> </invoke | receive | onMessage>
次の例に、BPEL 1.1におけるアサート後条件の構文を示します。
<bpelx:postAssert name="Assert_1" message='Post Invoke Multiple assert value fired' faultName="ns2:NegativeValue" expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') > 0"/>
次の例に、BPEL 2.0におけるアサート前条件のスキーマ定義を示します。
<invoke | reply> standard-elements <bpelx:preAsserts> <bpelx:preAssert faultName="QName"> <bpelx:expression expressionLanguage="anyURI"?>expression</bpelx:expression> <bpelx:message expressionLanguage="anyURI"?>expression</bpelx:message> </bpelx:preAssert> </bpelx:preAsserts> </invoke | reply>
次の例に、BPEL 2.0におけるアサート前条件の構文を示します。
<bpelx:preAsserts> <bpelx:preAssert faultName="ns1:InvalidInput"> <bpelx:expression>concat($inputVariable.payload/client:input,'2') > $inputVariable.payload/client:input</bpelx:expression> <bpelx:message>"AssertXpathPreInvoke_20 Assert test"</bpelx:message> </bpelx:preAssert> </bpelx:preAsserts>
次の例に、BPEL 1.1におけるアサート前条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。
<invoke | reply> standard-elements <bpelx:preAssert name="NCName" expression="string" message="string" faultName="QName"/> </invoke | reply>
次の例に、BPEL 1.1におけるアサート前条件の構文を示します。
<bpelx:preAssert name="Assert_1" expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') > 0" message='pre invoke assert NegativeInput fired' faultName="ns4:NegativeInput"/>
bpelx:postAssert
拡張要素には、パートナからのコールバック・メッセージの受信時に評価するXPath式を指定します。アサーション式でfalseのブール値が返された場合は、指定のフォルトがアクティビティからスローされます。アサーション式でtrueのブール値が返された場合、フォルトはスローされず、通常のBPELプロセス・フローの場合と同様に、invokeアクティビティ、receiveアクティビティ、またはpickアクティビティとscopeアクティビティのonMessageブランチに続くアクティビティが実行されます。
bpelx:preAssert
またはbpelx:postAssert
拡張要素は、Javaのassert
文と同じです。Javaでは、assert
式がtrueと評価されない場合は、JVMによってエラーが報告されます。同様に、bpelx:preAssert
またはbpelx:postAssert
拡張要素の式もtrueと評価される必要があります。そうでない場合は、指定のフォルトがスローされます。
たとえば、次の例に示すBPEL 1.1のinvokeアクティビティでは、アサーション条件に指定したXPath式でfalseが返されると、NegativeCredit
フォルトがスローされます。
<scope> <faultHandlers> <catch faultName="services:NegativeCredit" faultVariable="crError"> <empty/> </catch> </faultHandlers> <sequence> <invoke name="invokeCR" partnerLink="creditRatingService" portType="services:CreditRatingService" operation="process" inputVariable="crInput" outputVariable="crOutput"> <bpelx:postAssert name="negativeCredit" expression="$crOutput.payload/tns:rating > 0" faultName="services:NegativeCredit" message="'Negative Credit'" /> </invoke> </sequence> </scope>
bpelx:preAssert
またはbpelx:postAssert
のオプションのname
属性は、監査証跡イベント・メッセージの作成時に使用されます。このインスタンスの名前を使用すると、複数のアサーションが指定されている場合にアサーション要素を識別できます。name
属性の指定がない場合は、BPELファイル内のアサーション要素の行番号が使用されます。
12.15 再試行可能とのSOAPフォルトの分類
12c以降、外部サービスから返されたフォルト・コードに基づいて、すべてのWebサービスSOAPフォルトは自動的に再試行されません。フォルト・コードがサーバー関連(受信者関連とも呼ばれます)と分類された場合のみ、SOAPフォルトは再試行されます。クライアント関連と分類されたフォルト・コードでは、再試行が行われません。これは11gリリース1 (11.1.1.x)と異なります。そのリリースのOracle SOA Suiteではフォルト・コードに関係なくすべてのSOAPフォルトが再試行されました(返されるフォルトのすべてがbpelx:remoteFault
にBPELで変換され、再試行可能でした)。
12cでは、参照バインディング・コンポーネントでフォルトが発生すると、フォルト・コードがBPELプロセスに返されます。フォルト・コードの設定に基づいてフォルトが再試行されます。フォルトを特定の状況(システム停止時間問題など)でのみ再試行する場合があるので、これはメリットがあります。他のすべてのフォルト発生(正しくない入力など)では、再試行を行わない場合があります。実際、すべてのSOAPフォルトにおける再試行では、正当なメッセージの処理を遅らせることができます。
Simple Object Access Protocol (SOAP) 1.1仕様(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383510
)に記載されているように、フォルトにはサーバー(受信者とも呼ばれます)またはクライアントのコードを持たせることができます。フォルトの分類により、フォルトが再試行できるかどうかが判別されます。
-
サーバー
メッセージの処理ではなくメッセージの内容に直接関連していない理由により、メッセージを処理できないことをサーバーのエラーが示します。たとえば、応答しなかったサーバーとの通信を処理に含めることができます。メッセージは後で成功する場合があります。これは再試行可能フォルトと定義されます。
-
クライアント
メッセージが適切に形成されていなかったり、成功するために適切な情報が格納されていなかったことをクライアントのエラーが示します。たとえば、メッセージに適切な認証や支払い情報が欠落している場合があります。これは一般的に、メッセージ再送前に最初に変更する必要があることを示します。これは再試行不能フォルトと定義されます。
このフォルト分類情報は、FabricInvocationException
エラーに伝播されます。クライアント関連と分類されたフォルト・コードでは、この例外内のretryType
フラグがNO_RETRY
に設定されます。
必要に応じて、再試行をすべてのフォルトで起動できます。composite.xml
ファイルでbinding.ws
プロパティのoracle.soa.always.retry.on.fault
をtrue
に設定します。これによって、フォルト・コードに関係なく、Oracle SOA SuiteではSOAPフォルトで必ず再試行できます。
<reference name="myreference" . . . <binding.ws port=". . . ." location=". . ." <property name="oracle.soa.always.retry.on.fault">true</property> </binding.ws>
composite.xml
の次のコード・スニペットを使用して、SOAで定義されたカスタム・ヘッダーを有効にしてOSB Webサービスにアクセスします。
<reference name="RecHttpOSB" ...> ... <binding.ws ... soapVersion="1.1"> <property name="oracle.webservices.http.headers">OSBCustomHttp</property> </binding.ws> </reference>