22 Oracle Mediatorエラー処理の使用
この章の内容は次のとおりです。
22.1 メディエータのエラー処理の概要
メディエータに用意されている高度なエラー処理機能を使用すると、エラーの発生とそれに対応する修正アクション用のメディエータ・サービス・コンポーネントを構成できます。エラー処理によって、メディエータはメッセージ処理中に発生するエラーや外部のWebサービスから戻される例外を処理できます。メディエータでは、ビジネス・フォルトとシステム・フォルトの両方を処理できます。
ビジネス・フォルトはアプリケーション固有のフォルトであり、サービスWSDLファイルで明示的に定義されます。設計時にOracle JDeveloperでフォルト・ハンドラを定義することでビジネス・フォルトを処理できます。システム・フォルトは、ネットワークが利用できないような基本システムにおける問題によって発生します。メディエータでは、システム・フォルト用のフォルト・ポリシーをベースとしたエラー処理を提供します。
フォルト・ポリシーにより、エラーを自動または管理者操作で処理できるようになります。メディエータのフォルト・ポリシーをベースとしたエラー処理は、次の3つのコンポーネントで構成されています。
-
フォルト・ポリシー
-
フォルト・バインディング
-
エラー・グループ
22.1.1 フォルト・ポリシー
フォルト・ポリシーは、エラー状態および対応するアクションを定義したものです。フォルト・ポリシーは、「fault-policies.xmlのスキーマ定義ファイル」に示すXMLスキーマに基づいて作成したfault-policies.xml
ファイルで定義します。
順次ルーティング・ルールのフォルト・ポリシーは、次に示すようにパラレルのルーティング・ルールの場合とは異なる方法で処理されます。
-
順次ルーティング・ルールがシングル・スレッド処理であるため、エラー処理に対して3つのアクション(中断、再スロー、およびJava)のみがサポートされており、指定されたアクションがコール元のスレッドでただちに実行されます。
-
メディエータ・メッセージは、順次ルーティングで保持されません。
-
非同期および一方向メディエータ・コンポーネントは、BPELビジネス・プロセスなど他のSOA Suiteコンポーネントからスローされるシステム・フォルトを処理できません。
使用可能なエラー処理アクションの詳細は、「アクション」を参照してください。
ノート:
次の場合は、フォルト・ポリシーはサポートされません。
-
コールバックの実行失敗
-
フォルト・ハンドラ・アクションの失敗
-
再シーケンサの失敗
フォルト・ポリシー・ファイルのサンプルを次に示します。
<?xml version="1.0" encoding="UTF-8"?> <faultPolicies> <faultPolicy version="2.0.1" id="CRM_ServiceFaults"> <Conditions> <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault"> <condition> <test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test> <action ref="ora-retry"/> </condition> </faultName> </Conditions> <Actions> <Action id="ora-retry"> <retry> <retryCount>3</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> <retryFailureAction ref="ora-java"/> <retrySuccessAction ref="ora-terminate"/> </retry> </Action> </Actions> </faultPolicy> </faultPolicies>
次の各項では、フォルト・ポリシーの2つのコンポーネント(条件とアクション)について説明します。
22.1.1.1 条件
条件によって、エラーまたはフォルト条件を識別し、特定のエラーやフォルト条件が発生した際に、実行するアクションを指定できます。たとえば、サービスを利用できないことで発生する特定のエラーに対しては、再試行などを実行できます。同様に、Schematron検証に失敗して発生するエラーに対しては、管理者操作のアクションを実行できます。このフォルトは、Oracle Enterprise Manager Fusion Middleware Controlを使用して、ペイロードを編集して再送信することによって手動でリカバリできます。
条件は、次の例に示すようにfault-policies.xml
ファイルに定義されます。
<Conditions> <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault"> <condition> <test>contains($fault.mediatorErrorCode,"TYPE_DATA_TRANSFORMATION")</test> <action ref="ora-java"/> </condition> </faultName> <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault"> <condition> <test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test> <action ref="ora-retry"/> </condition> </faultName> <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault"> <condition> <test>contains($fault.mediatorErrorCode,"TYPE_DATA_ASSIGN")</test> <action ref="ora-retry-crm-endpoint"/> </condition> </faultName> </Conditions>
条件を使用したフォルト・タイプの識別
条件を使用して取得可能なフォルトは、次のタイプに分類できます。
-
メディエータ固有のフォルト
すべてのメディエータ固有のフォルトに対して、メディエータ・サービス・エンジンは1つのフォルト(
{http://schemas.oracle.com/mediator/faults}mediatorFault
)のみをスローします。すべてのメディエータ・フォルトがこのフォルトにラップされています。メディエータによって生成されたエラーまたはフォルトは、次の例に示す形式を使用して取得できます。<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault"> <!-- mediatorFault is a bucket for all the mediator faults --> <condition> <test> contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH") </test> <!-- Captures TYPE_FATAL_MESH errors --> <action ref="ora-retry"/> </condition> </faultName>
-
ビジネス・フォルトおよびSOAPフォルト
エラーまたはフォルトは、フォルト・ペイロードに基づいたXPath条件を定義することで取得できます。次の例に詳細を示します。
<faultName xmlns:ns1="http://xmlns.oracle.com/Customer" name="ns1:InvalidCustomer"> <!-- Qname of Business/SOAP fault --> <condition> <test> contains($fault.<PART_NAME>/custid, 1011) </test> <!-- xpath condition based on fault payload --> <action ref="ora-retry"/> </condition> </faultName>
参照サービスがビジネス・フォルトを返した場合、そのフォルトはメディエータ・サービス・コンポーネントで処理できます。返されたフォルトは別のコンポーネントに転送したり、ファイル・アダプタなどのアダプタ・サービスにリダイレクトできます。また、イベントを発生させることもできます。ただし、ビジネス・フォルトに対してフォルト・ポリシーとフォルト・ハンドラの両方が定義されている場合は、フォルト・ポリシーがフォルト・ハンドラより優先されます。この場合、フォルト・ポリシーが正常に実行されると、メディエータ・サービス・コンポーネント内のフォルト・ハンドラは無視されます。
-
アダプタ固有のフォルト
アダプタによって生成されたエラーまたはフォルトは、次の例に示す形式を使用して取得できます。
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault"> <condition> <test>$fault.faultCode = "1"</test> <!-- unique constraint violation in DB adapter--> <action ref="ora-retry"/> </condition> </faultName>
22.1.1.2 アクション
アクションは、エラー発生時に実行するタスクを指定します。メディエータは、パラレルのルーティング・ルールに対する再試行、管理者操作、中断、Javaコードの各アクションをサポートしています。順次ルーティング・ルールの場合、フォルト・ポリシーに、中断、再スロー、およびJavaコードのアクションを含めることができます。
順次ルーティング・ルールで再試行または管理者操作アクションが選択されている場合、フォルトは直接コール元に戻され、ポリシーは適用されません。互換性がないアクションが選択されていた場合は、それがログに記録されます。これは、BPELフォルト・ポリシーの動作と一貫しています。フォルトの処理はコール元が担当します。コール元がアダプタの場合は、拒否ハンドラをインバウンド・アダプタに定義して、エラーになったメッセージ(拒否メッセージ)を処理できます。拒否ハンドラの詳細は、『テクノロジ・アダプタの理解』を参照してください。
フォルト・ポリシー・アクションについては、後続の各項で説明します。
22.1.1.2.1 再試行アクション
停止したJMSキューへのメッセージのエンキューや一意キー制約エラーがあるレコードの挿入などの再試行アクションを使用すると、エラーの原因となったタスクを再試行できます。新規スレッドが各再試行アクションとともに開始されます。したがって、各再試行アクションでは、新規トランザクションが開始されます。表22-1に、再試行アクションに使用可能なオプションを示します。再試行アクションの適用対象は、パラレルのルーティング・ルールのみです。
表22-1 再試行アクションのオプション
オプション | 説明 |
---|---|
再試行数 |
N回再試行します。 |
再試行間隔 |
再試行を秒単位で遅延します。 |
指数関数的バックオフ |
指数バックオフを使用して再試行間隔を増加します。 |
再試行失敗アクション |
N回の再試行に失敗した場合は、このアクションにチェーンします。 |
再試行成功アクション |
再試行に成功した場合は、このアクションにチェーンします。 |
ノート:
指数バックオフでは、次の再試行が2倍のdelayでスケジュールされます。ここでのdelayは、現在の再試行間隔です。たとえば、現在の再試行間隔が2
秒の場合、次の再試行間隔は4
秒にスケジュールされ、その次は8
秒、16
秒と、retryCount
値に達するまで増分されます。
次の例は、再試行アクションの指定方法を示しています。
<Action id="ora-retry"> <retry> <retryCount>3</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> <retryFailureAction ref="ora-java"/> <retrySuccessAction ref="ora-java"/> </retry> </Action>
フォルト・ポリシーの再試行間隔に30秒未満の期間を設定すると、指定した間隔内に再試行が実行されない場合があります。これは、org.quartz.scheduler.idleWaitTime
プロパティのデフォルト値が30秒であり、スケジューラがアイドル状態の場合でも、使用可能なトリガーを再試行するまでに30秒待機するためです。再試行間隔を30秒未満の値に設定した場合は、待機時間が発生する可能性があります。
30秒未満の再試行間隔を使用する場合は、fabric-config-core.xml
ファイルのセクション<property name="quartzProperties">
の下に次のプロパティを追加します。
org.quartz.scheduler.idleWaitTime=<value>
22.1.1.2.2 再スロー・アクション
再スローは、コール元のスレッドでフォルト・ポリシーを実行し、元の例外をユーザーに返します。
再スロー・アクションの例を次に示します。
<Action id="ora-rethrow-fault"><rethrowFault/></Action>
22.1.1.2.3 管理者操作アクション
管理者操作アクションによって、エラーを訂正し(たとえば、ペイロードを変更し)、手動でメッセージを再試行することでフォルトを手動でリカバリできます。このアクションは、パラレルのルーティング・ルールにのみ適用できます。
管理者操作アクションの例を、次に示します。
<Action id="ora-human-intervention"><humanIntervention/></Action>
22.1.1.2.4 中断アクション
中断アクションによって、メッセージ・フローを終了することができます。このアクションは、パラレルと順次の両方のルーティング・ルールに適用できます。
中断アクションを順次ルーティング・ルールに対して実行すると、例外FabricInvocationException
が、コール元にスローされ、メディエータ・コンポーネントの状態が終了に変わります。フォルト・ポリシーは、コール元のスレッド内で実行されます。
中断アクションの例を、次に示します。
<Action id="ora-terminate"><abort/></Action>
22.1.1.2.5 Javaコード・アクション
Javaコードアクションにより、oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass
インタフェースを実装するカスタマイズJavaクラスをコールできます。このアクションは、パラレルと順次の両方のルーティング・ルールに適用できます。次の例は、Javaコード・アクションの実装方法を示しています。
ノート:
実装済Javaクラスは、文字列を戻すメソッドを実装している必要があります。ポリシーは、戻された文字列に基づいて新しいアクションにチェーンできます。
Javaコード・アクションは、最初に、ドメイン・クラス・ライブラリ内の実装済クラスを検索します。そこでクラスが見つからない場合は、コンポジット・アプリケーションのクラス・ライブラリが検索されます。
<Action id="ora-java"> <javaAction className="mypackage.myClass" defaultAction="ora-terminate"> <returnValue value="ABORT" ref="ora-terminate"/> <returnValue value="RETRY" ref="ora-retry"/> <returnValue value="MANUAL" ref="ora-human-intervention"/> </javaAction> </Action>
順次ルーティング・ルール・フォルト・ポリシーの場合、returnValue
アクションは、中断、再スロー、またはJavaアクションの1つである必要があります。returnValue
が、これらの有効な値以外である場合、defaultAction
がチェックされます。defaultAction
も有効なアクション(中断、再スロー、またはJavaアクション)でない場合、デフォルトではアクションは実行されず、元のフォルトがコール元にスローされます。
oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass { public void handleRetrySuccess(IFaultRecoveryContext ctx); public String handleFault(IFaultRecoveryContext ctx); }
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 reference. */ public String getReferenceName(); /** * @return Port type of the faulted reference link. */ public QName getPortType(); }
メディエータ・サービス・エンジンの実装
次の例は、IFaultRecoveryContext
インタフェースのOracle Mediatorサービス・エンジンの実装を示しています。
package oracle.tip.mediator.common.error.recovery; public class MediatorRecoveryContext implements IFaultRecoveryContext{ ... }
次の例に示すメソッドを使用すると、MediatorRecoveryContext
クラスで使用可能なメディエータ固有の追加データを取得できます。
public CommonFault getACommonFault() public CalloutMediatorMessage getMediatorMessage()
次の例は、CalloutMediatorMessage
インタフェースを使用したデータの取得方法を示しています。
/** * Accessing Mediator Message properties by providing the property name * @param propertyName * @return * @throws MediatorException */ public Object getProperty(String propertyName); /** * Accessing Mediator Message properties * @return * @throws MediatorException */ public Map getProperties(); /** * Accessing instance id of the mediator message * This will be the mediator instance id created for that particular message * object * @return * @throws MediatorException */ public String getId() throws MediatorException; /** * Accessing payload of the mediator message * object * @return * @throws MediatorException */ public Map getPayload(); /** * Accessing header of the mediator message * object * @return * @throws MediatorException */ public List<Element> getHeaders(); /** * Accessing componentDN for mediator component * @return * @throws MediatorException */ public String getComponentDN( /** * Setting payload to the mediator message * @return * @throws MediatorCalloutException */ public void addPayload(String partName,Object payload) throws MediatorCalloutException; /** * Adding property to the mediator message * @return * @throws MediatorCalloutException */ public void addProperty(String name,Object value) throws MediatorCalloutException; /** * Adding header to the mediator message * @return * @throws MediatorCalloutException */ public void addHeader(Object header) throws MediatorCalloutException;
22.1.2 フォルト・バインディング
フォルト・バインディングは、フォルト・ポリシーをコンポジットまたはコンポーネントと関連付けるもので、fault-bindings.xml
ファイルで定義されています。fault-bindings.xml
ファイルは、「fault-bindings.xmlのスキーマ定義ファイル」で定義されているXMLスキーマに基づいて作成します。
フォルト・ポリシーは次のレベルで作成できます。
-
コンポジット: コンポジット内のすべてのメディエータ・コンポーネントに対してフォルト・ポリシーを1つ定義できます。このレベルは、次の方法で指定できます。
<composite faultPolicy="ConnectionFaults"/>
-
コンポーネント: メディエータ・サービス・コンポーネントに対するフォルト・ポリシーを排他的に定義できます。コンポーネント・レベルのフォルト・ポリシーは、コンポジット・レベルのフォルト・ポリシーをオーバーライドします。このレベルは、次の例に示すように、指定できます。
<component faultPolicy="ConnectionFaults"> <name>Component1</name> <name>Component2</name> </component>
-
参照: メディエータ・コンポーネントの参照に対するフォルト・ポリシーを定義できます。このレベルは、次の例に示すように、指定できます。
<reference faultPolicy="policy1"> <name>DBAdapter3</name> </reference>
ノート:
フォルト・ポリシーの優先順位のレベルは、参照、コンポーネント、コンポジットの順です。
ノート:
管理者操作は、フォルト・ポリシーが定義されていないエラーに対するデフォルト・アクションです。
次の例は、フォルト・バインディング・ファイルのサンプルを示しています。
<?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"/> </faultPolicyBindings>
22.1.3 メディエータのエラー・グループ
フォルト・ポリシーに条件を定義する一方で、エラー・タイプやエラー・グループにはアクションを指定できます。前述の例にあるmedns:mediatorFault
は、エラーがメディエータ・エラーであることを表しているのに対し、medns:TYPE_FATAL_MESH
は、エラー・グループを表しています。エラー・グループは、1つ以上の子エラー・タイプで構成されています。TYPE_ALL
は、すべてのメディエータ・エラーを含むエラー・グループです。
次のリストでは、TYPE_ALL
エラー・グループに含まれる様々なエラー・グループについて説明します。
-
TYPE_DATA
: データ処理に関するエラーが含まれます。-
TYPE_DATA_ASSIGN
: データの割当に関するエラーが含まれます。 -
TYPE_DATA_FILTERING
: データのフィルタ処理に関するエラーが含まれます。 -
TYPE_DATA_TRANSFORMATION
: トランスフォーメーション中に発生したエラーが含まれます。 -
TYPE_DATA_VALIDATION
: ペイロード検証中に発生したエラーが含まれます。
-
-
TYPE_METADATA
: メディエータのメタデータに関するエラーが含まれます。-
TYPE_METADATA_FILTERING
: フィルタ処理の条件の処理中に発生したエラーが含まれます。 -
TYPE_METADATA_TRANSFORMATION
: トランスフォーメーション用のメタデータの取得中に発生したエラーが含まれます。 -
TYPE_METADATA_VALIDATION
: メディエータ用のメタデータ(.mplan
ファイル)の検証中に発生したエラーが含まれます。 -
TYPE_METADATA_COMMON
: メタデータの処理中に発生したその他のエラーが含まれます。
-
-
TYPE_FATAL
: 容易にリカバリできない致命的なエラーが含まれます。-
TYPE_FATAL_DB
:Datasource not found
エラーなど、データベース関連の致命的なエラーが含まれます。 -
TYPE_FATAL_CACHE
: メディエータのキャッシュ関連の致命的なエラーが含まれます。 -
TYPE_FATAL_ERRORHANDLING
:Resubmission queues not available
など、エラー処理中に発生した致命的なエラーが含まれます。 -
TYPE_FATAL_MESH
:Invoke service not available
など、サービス・インフラストラクチャから発生した致命的なエラーが含まれます。 -
TYPE_FATAL_MESSAGING
: サービス・インフラストラクチャから発生した致命的なメッセージ・エラーが含まれます。 -
TYPE_FATAL_TRANSACTION
:Commit can't be called on a transaction which is marked for rollback
など、トランザクションに関する致命的なエラーが含まれます。 -
TYPE_FATAL_TRANSFORMATION
: トランスフォーメーション時に使用するXPath関数によって発生したエラーなど、致命的なトランスフォーメーション・エラーが含まれます。
-
-
TYPE_TRANSIENT
: 再試行でリカバリできる一時エラーが含まれます。-
TYPE_TRANSIENT_MESH
: サービス・インフラストラクチャに関するエラーが含まれます。 -
TYPE_TRANSIENT_MESSAGING
: エンキューやデキューなど、JMSに関するエラーが含まれます。
-
-
TYPE_INTERNAL
: 内部エラーが含まれます。
22.2 メディエータによるエラー処理の使用
Oracle Mediatorのエラー処理は、fault-policies.xml
およびfault-bindings.xml
ファイルを使用して有効にできます。
22.2.1 メディエータ・サービス・コンポーネントに対するエラー処理の使用方法
メディエータ・サービス・コンポーネントに対してエラー処理を使用するには:
- 「fault-policies.xmlのスキーマ定義ファイル」で定義されているスキーマに基づいて、
fault-policies.xml
ファイルを作成します。 - 「fault-bindings.xmlのスキーマ定義ファイル」で定義されているXMLスキーマに基づいて、
fault-bindings.xml
ファイルを作成します。 fault-policies.xml
およびfault-bindings.xml
ファイルをSOAコンポジット・アプリケーション・プロジェクトのディレクトリにコピーします。- SOAコンポジット・アプリケーション・プロジェクトをデプロイします。
22.2.2 実行時の処理内容
コンポジットに対するフォルト・ポリシーはすべて、最初のエラーが発生したときにロードされます。エラーが発生した場合、メディエータ・サービス・エンジンによってフォルト・ポリシー・ファイル(fault-policies.xml
およびfault-bindings.xml
)が存在しているかどうかがチェックされます。フォルト・ポリシー・バインディングがチェックされ、そのコンポーネントまたはコンポジットと関連付けられているフォルト・ポリシーが判別されます。フォルト・ポリシーがコンポーネントまたはコンポジットと関連付けられている場合、メディエータによって、そのフォルト条件に対応したフォルト・ポリシーで定義されているアクションが実行されます。コンポーネントまたはコンポジットに対してフォルト・ポリシー・バインディングが見つからない場合、アクションは実行されず、動作はフォルト・ポリシーが存在しない場合と同じになります。
定義されているフォルト・ポリシーがなく、ルーティング・ルールが平行して実行される場合、管理者操作のデフォルト・アクションが実行されます。定義されているフォルト・ポリシーがなく、ルーティング・ルールが順次実行される場合、コール元にエラーがスローされます。
ノート:
エラーが発生した順次ルーティング・トランザクションはすべて、フォルト・ポリシーがそのエラーの処理に使用された場合でも、ロールバックされます。
フォルト・ポリシーの処理方法の詳細は、「アクション」を参照してください。
22.3 Oracle Enterprise Manager Fusion Middleware Controlを使用したフォルト・リカバリ
フォルト・ポリシー・ファイルを使用するポリシーベースのリカバリとは別に、Oracle Enterprise Manager Fusion Middleware Controlでは、リカバリ可能として識別されたOracle Mediatorフォルトに対して、フォルト・リカバリ・アクションを実行することもできます。次のうちの任意の方法を使用して、フォルトをリカバリします。
-
Oracle Enterprise Manager Fusion Middleware Controlを使用してペイロードを変更する手動リカバリ
-
Oracle Enterprise Manager Fusion Middleware Controlを使用してペイロードを変更しないバルク・リカバリ
-
Oracle Enterprise Manager Fusion Middleware Controlを使用した、失敗したインスタンスの強制終了(インスタンスの処理を続行しない場合)。
Oracle Enterprise Manager Fusion Middleware Controlを使用してフォルトをリカバリする方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。
22.4 XMLスキーマ定義ファイルのエラー処理
この項では、fault-policies.xml
およびfault-bindings.xml
ファイルのスキーマ・ファイルについて説明します。
22.4.1 fault-policies.xmlのスキーマ定義ファイル
fault-policies.xml
ファイルは、次の例に示すように、XSDファイルに基づいている必要があります。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy" xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <!-- Conditions contain a list of fault names --> <xs:element name="Conditions"> <xs:complexType> <xs:sequence> <xs:element name="faultName" type="tns:faultNameType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <!-- action Ref must exist in the same file --> <xs:complexType name="actionRefType"> <xs:attribute name="ref" type="xs:string" use="required"/> </xs:complexType> <!-- one condition has a test and action, if test is missing, this is the catch all condition --> <xs:complexType name="conditionType"> <xs:all> <xs:element name="test" type="tns:idType" minOccurs="0"/> <xs:element name="action" type="tns:actionRefType"/> </xs:all> </xs:complexType> <!-- One fault name match contains several conditions --> <xs:complexType name="faultNameType"> <xs:sequence> <xs:element name="condition" type="tns:conditionType" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:QName"/> </xs:complexType> <xs:complexType name="ActionType"> <xs:choice> <xs:element name="retry" type="tns:RetryType"/> <xs:element ref="tns:rethrowFault"/> <xs:element ref="tns:humanIntervention"/> <xs:element ref="tns:abort"/> <xs:element ref="tns:replayScope"/> <xs:element name="javaAction" type="tns:JavaActionType"> <xs:key name="UniqueReturnValue"> <xs:selector xpath="tns:returnValue"/> <xs:field xpath="@value"/> </xs:key> </xs:element> </xs:choice> <xs:attribute name="id" type="tns:idType" use="required"/> </xs:complexType> <xs:element name="Actions"> <xs:annotation> <xs:documentation>Fault Recovery Actions</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Action" type="tns:ActionType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="JavaActionType"> <xs:annotation> <xs:documentation>This action invokes java code provided</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="returnValue" type="tns:ReturnValueType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="className" type="tns:idType" use="required"/> <xs:attribute name="defaultAction" type="tns:idType" use="required"/> <xs:attribute name="propertySet" type="tns:idType"/> </xs:complexType> <xs:complexType name="RetryType"> <xs:annotation> <xs:documentation>This action attempts retry of activity execution</xs:documentation> </xs:annotation> <xs:all> <xs:element ref="tns:retryCount"/> <xs:element ref="tns:retryInterval"/> <xs:element ref="tns:exponentialBackoff" minOccurs="0"/> <xs:element name="retryFailureAction" type="tns:retryFailureActionType" minOccurs="0"/> <xs:element name="retrySuccessAction" type="tns:retrySuccessActionType" minOccurs="0"/> </xs:all> </xs:complexType> <xs:simpleType name="idType"> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:complexType name="ReturnValueType"> <xs:annotation> <xs:documentation>Return value from java code can chain another action using return values</xs:documentation> </xs:annotation> <xs:attribute name="value" type="tns:idType" use="required"/> <xs:attribute name="ref" type="xs:string" use="required"/> </xs:complexType> <xs:element name="exponentialBackoff"> <xs:annotation> <xs:documentation>Setting this will cause retry attempts to use exponentialBackoff algorithm</xs:documentation> </xs:annotation> <xs:complexType/> </xs:element> <xs:element name="humanIntervention"> <xs:annotation> <xs:documentation>This action causes the activity to freeze</xs:documentation> </xs:annotation> <xs:complexType/> </xs:element> <xs:element name="replayScope"> <xs:annotation> <xs:documentation>This action replays the immediate enclosing scope</xs:documentation> </xs:annotation> <xs:complexType/> </xs:element> <xs:element name="rethrowFault"> <xs:annotation> <xs:documentation>This action will rethrow the fault</xs:documentation> </xs:annotation> <xs:complexType/> </xs:element> <xs:element name="retryCount" type="xs:positiveInteger"> <xs:annotation> <xs:documentation>This value is used to identify number of retries</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="retryFailureActionType"> <xs:annotation> <xs:documentation>This is the action to be chained if retry attempts fail</xs:documentation> </xs:annotation> <xs:attribute name="ref" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="retrySuccessActionType"> <xs:annotation> <xs:documentation>This is the action to be chained if retry attempts is successful</xs:documentation> </xs:annotation> <xs:attribute name="ref" type="xs:string" use="required"/> </xs:complexType> <xs:element name="retryInterval" type="xs:unsignedLong"> <xs:annotation> <xs:documentation>This is the delay in milliseconds of retry attempts</xs:documentation> </xs:annotation> </xs:element> <xs:element name="abort"> <xs:annotation> <xs:documentation>This action terminates the process</xs:documentation> </xs:annotation> <xs:complexType/> </xs:element> <xs:element name="Properties"> <xs:annotation> <xs:documentation>Properties that can be passes to a custom java class</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="propertySet" type="tns:PropertySetType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="PropertySetType"> <xs:sequence> <xs:element name="property" type="tns:PropertyValueType" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="tns:idType" use="required"/> </xs:complexType> <xs:complexType name="PropertyValueType"> <xs:simpleContent> <xs:extension base="tns:idType"> <xs:attribute name="name" type="tns:idType" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="faultPolicy"> <xs:complexType> <xs:sequence> <xs:element ref="tns:Conditions"/> <xs:element ref="tns:Actions"/> <xs:element ref="tns:Properties" minOccurs="0"/> <!--Every policy has on Conditions and and one Actions, however, Properties is optional --> </xs:sequence> <xs:attribute name="id" type="tns:idType" use="required"/> <xs:attribute name="version" type="xs:string" default="2.0.1"/> </xs:complexType> <xs:key name="UniqueActionId"> <xs:selector xpath="tns:Actions/tns:Action"/> <xs:field xpath="@id"/> </xs:key> <xs:key name="UniquePropertySetId"> <xs:selector xpath="tns:Properties/tns:property_set"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref name="RetryActionRef" refer="tns:UniqueActionId"> <xs:selector xpath="tns:Actions/tns:Action/tns:retry/tns:retryFailureAction"/> <xs:field xpath="@ref"/> </xs:keyref> <xs:keyref name="RetrySuccessActionRef" refer="tns:UniqueActionId"> <xs:selector xpath="tns:Actions/tns:Action/tns:retry/tns:retrySuccessAction"/> <xs:field xpath="@ref"/> </xs:keyref> <xs:keyref name="JavaActionRef" refer="tns:UniqueActionId"> <xs:selector xpath="tns:Actions/tns:Action/tns:javaAction/tns:returnValue"/> <xs:field xpath="@ref"/> </xs:keyref> <xs:keyref name="ConditionActionRef" refer="tns:UniqueActionId"> <xs:selector xpath="tns:Conditions/tns:faultName/tns:condition/tns:action"/> <xs:field xpath="@ref"/> </xs:keyref> <xs:keyref name="JavaDefaultActionRef" refer="tns:UniqueActionId"> <xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/> <xs:field xpath="@defaultAction"/> </xs:keyref> <xs:keyref name="JavaPropertySetRef" refer="tns:UniquePropertySetId"> <xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/> <xs:field xpath="@property_set"/> </xs:keyref> </xs:element> <xs:element name="faultPolicies"> <xs:complexType> <xs:sequence> <xs:element ref="tns:faultPolicy" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
22.4.2 fault-bindings.xmlのスキーマ定義ファイル
fault-bindings.xml
ファイルは、次の例に示すように、XSDファイルに基づいている必要があります。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy" xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="faultPolicyBindings"> <xs:annotation> <xs:documentation>Bindings to a specific fault policy </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="composite" type="tns:compositeType" minOccurs="0" maxOccurs="1"/> <xs:element name="component" type="tns:componentType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="reference" type="tns:referenceType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="version" type="xs:string" default="2.0.1"/> </xs:complexType> <xs:key name="UniquePartnerLinkName"> <xs:selector xpath="tns:reference/tns:name"/> <xs:field xpath="."/> </xs:key> <xs:key name="UniquePortType"> <xs:selector xpath="tns:reference/tns:portType"/> <xs:field xpath="."/> </xs:key> <xs:key name="UniquePolicyName"> <xs:selector xpath="tns:reference"/> <xs:field xpath="@faultPolicy"/> </xs:key> </xs:element> <xs:simpleType name="nameType"> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:complexType name="propertyType"> <xs:simpleContent> <xs:extension base="tns:nameType"> <xs:attribute name="name" type="xs:string" use="required" fixed="faultPolicy"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="referenceType"> <xs:annotation> <xs:documentation>Bindings for a partner link. Overrides composite level binding.</xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation>Specification at partner link name overrides specification for a port type</xs:documentation> </xs:annotation> <xs:element name="name" type="tns:nameType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="portType" type="xs:QName" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="faultPolicy" type="tns:nameType" use="required"/> </xs:complexType> <xs:complexType name="componentType"> <xs:annotation> <xs:documentation>Binding for a component </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="name" type="tns:nameType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="faultPolicy" type="tns:nameType" use="required"/> </xs:complexType> <xs:complexType name="compositeType"> <xs:annotation> <xs:documentation>Binding for the entire composite</xs:documentation> </xs:annotation> <xs:attribute name="faultPolicy" type="tns:nameType" use="required"/> </xs:complexType> </xs:schema>