| Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド 11gリリース1 (11.1.1.7) B56238-10 |
|
 前 |
 次 |
この章では、Oracle Mediatorのエラー処理機能について説明し、ビジネス・フォルトとシステム・フォルトの両方のエラー処理を定義する手順を示します。
この章では、次の項目について説明します。
メディエータに用意されている高度なエラー処理機能を使用すると、エラーの発生とそれに対応する修正アクション用のメディエータ・サービス・コンポーネントを構成できます。エラー処理によって、メディエータはメッセージ処理中に発生するエラーや外部のWebサービスから戻される例外を処理できます。メディエータでは、ビジネス・フォルトとシステム・フォルトの両方を処理できます。
ビジネス・フォルトはアプリケーション固有のフォルトであり、サービスWSDLファイルで明示的に定義されます。設計時にOracle JDeveloperでフォルト・ハンドラを定義することでビジネス・フォルトを処理できます。システム・フォルトは、ネットワークが利用できないような基本システムにおける問題によって発生します。メディエータでは、システム・フォルト用のフォルト・ポリシーをベースとしたエラー処理を提供します。
フォルト・ポリシーにより、エラーを自動または管理者操作で処理できるようになります。メディエータのフォルト・ポリシーをベースとしたエラー処理は、次の3つのコンポーネントで構成されています。
フォルト・ポリシー
フォルト・バインディング
エラー・グループ
フォルト・ポリシーは、エラー状態および対応するアクションを定義したものです。フォルト・ポリシーは、第22.4.1項「fault-policies.xmlのスキーマ定義ファイル」に示すXMLスキーマに基づいて作成したfault-policies.xmlファイルで定義します。
順次ルーティング・ルールのフォルト・ポリシーは、次に示すようにパラレルのルーティング・ルールの場合とは異なる方法で処理されます。
順次ルーティング・ルールがシングル・スレッド処理であるため、エラー処理に対して3つのアクション(中断、再スロー、およびJava)のみがサポートされており、指定されたアクションがコール元のスレッドでただちに実行されます。
メディエータ・メッセージは、順次ルーティングで保持されません。
非同期および一方向メディエータ・コンポーネントは、BPELビジネス・プロセスなど他のSOA Suiteコンポーネントからスローされるシステム・フォルトを処理できません。
使用可能なエラー処理アクションの詳細は、第22.1.1.2項「アクション」を参照してください。
例22-1に、フォルト・ポリシー・ファイルのサンプルを示します。
例22-1 フォルト・ポリシー・ファイルのサンプル
<?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つのコンポーネント(条件とアクション)について説明します。
条件によって、エラーまたはフォルト条件を識別し、特定のエラーやフォルト条件が発生した際に、実行するアクションを指定できます。たとえば、サービスを利用できないことで発生する特定のエラーに対しては、再試行などを実行できます。同様に、Schematron検証に失敗して発生するエラーに対しては、管理者操作のアクションを実行できます。このフォルトは、Oracle Enterprise Manager Fusion Middleware Controlを使用して、ペイロードを編集して再送信することによって手動でリカバリできます。
条件は、例22-2に示すようにfault-policies.xmlファイルに定義されます。
例22-2 条件
<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)のみをスローします。すべてのメディエータ・フォルトがこのフォルトにラップされています。メディエータによって生成されたエラーまたはフォルトは、例22-3に示す形式を使用して取得できます。
例22-3 Oracle Mediator固有のフォルト
<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条件を定義することで取得できます。例22-4に詳細を示します。
例22-4 ビジネス・フォルトおよびSOAPフォルト
<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>
参照サービスがビジネス・フォルトを返した場合、そのフォルトはメディエータ・サービス・コンポーネントで処理できます。返されたフォルトは別のコンポーネントに転送したり、ファイル・アダプタなどのアダプタ・サービスにリダイレクトできます。また、イベントを発生させることもできます。ただし、ビジネス・フォルトに対してフォルト・ポリシーとフォルト・ハンドラの両方が定義されている場合は、フォルト・ポリシーがフォルト・ハンドラより優先されます。この場合、フォルト・ポリシーが正常に実行されると、メディエータ・サービス・コンポーネント内のフォルト・ハンドラは無視されます。
アダプタ固有のフォルト
アダプタによって生成されたエラーまたはフォルトは、例22-5に示す形式を使用して取得できます。
アクションは、エラー発生時に実行するタスクを指定します。メディエータは、パラレルのルーティング・ルールに対する再試行、管理者操作、中断、Javaコードの各アクションをサポートしています。順次ルーティング・ルールの場合、フォルト・ポリシーに、中断、再スロー、およびJavaコードのアクションを含めることができます。
順次ルーティング・ルールで再試行または管理者操作アクションが選択されている場合、フォルトは直接コール元に戻され、ポリシーは適用されません。互換性がないアクションが選択されていた場合は、それがログに記録されます。これは、BPELフォルト・ポリシーの動作と一貫しています。フォルトの処理はコール元が担当します。コール元がアダプタの場合は、拒否ハンドラをインバウンド・アダプタに定義して、エラーになったメッセージ(拒否メッセージ)を処理できます。拒否ハンドラの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。
フォルト・ポリシー・アクションについては、後続の各項で説明します。
停止したJMSキューへのメッセージのエンキューや一意キー制約エラーがあるレコードの挿入などの再試行アクションを使用すると、エラーの原因となったタスクを再試行できます。新規スレッドが各再試行アクションとともに開始されます。したがって、各再試行アクションでは、新規トランザクションが開始されます。表22-1に、再試行アクションに使用可能なオプションを示します。再試行アクションの適用対象は、パラレルのルーティング・ルールのみです。
表22-1 再試行アクションのオプション
| オプション | 説明 |
|---|---|
|
再試行数 |
N回再試行します。 |
|
再試行間隔 |
再試行を秒単位で遅延します。 |
|
指数バックオフ |
指数バックオフを使用して再試行間隔を増加します。 |
|
再試行失敗時アクション |
N回の再試行に失敗した場合は、このアクションにチェーンします。 |
|
再試行成功時アクション |
再試行に成功した場合は、このアクションにチェーンします。 |
|
注意: 指数バックオフでは、次の再試行が2倍のdelayでスケジュールされます。ここでのdelayは、現在の再試行間隔です。たとえば、現在の再試行間隔が |
例22-6に、再試行アクションの指定方法を示します。
例22-6 再試行アクション
<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>
再スローは、コール元のスレッドでフォルト・ポリシーを実行し、元の例外をユーザーに返します。
再スロー・アクションの例を次に示します。
<Action id="ora-rethrow-fault"><rethrowFault/></Action>
管理者操作アクションによって、エラーを訂正し(たとえば、ペイロードを変更し)、手動でメッセージを再試行することでフォルトを手動でリカバリできます。このアクションは、パラレルのルーティング・ルールにのみ適用できます。
管理者操作アクションの例を、次に示します。
<Action id="ora-human-intervention"><humanIntervention/></Action>
中断アクションによって、メッセージ・フローを終了することができます。このアクションは、パラレルと順次の両方のルーティング・ルールに適用できます。
中断アクションを順次ルーティング・ルールに対して実行すると、例外FabricInvocationExceptionが、コール元にスローされ、メディエータ・コンポーネントの状態が終了に変わります。フォルト・ポリシーは、コール元のスレッド内で実行されます。
中断アクションの例を、次に示します。
<Action id="ora-terminate"><abort/></Action>
Javaコードアクションにより、oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClassインタフェースを実装するカスタマイズJavaクラスをコールできます。このアクションは、パラレルと順次の両方のルーティング・ルールに適用できます。例22-7は、Javaコード・アクションの実装方法を示しています。
|
注意: 実装済Javaクラスは、文字列を戻すメソッドを実装している必要があります。ポリシーは、戻された文字列に基づいて新しいアクションにチェーンできます。 Javaコード・アクションは、最初に、ドメイン・クラス・ライブラリ内の実装済クラスを検索します。そこでクラスが見つからない場合は、コンポジット・アプリケーションのクラス・ライブラリが検索されます。 |
例22-7 カスタマイズ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アクション)でない場合、デフォルトではアクションは実行されず、元のフォルトがコール元にスローされます。
例22-8 oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClassインタフェース
oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass {
public void handleRetrySuccess(IFaultRecoveryContext ctx);
public String handleFault(IFaultRecoveryContext ctx);
}
例22-9 oracle.integration.platform.faultpolicy.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 reference.
*/
public String getReferenceName();
/**
* @return Port type of the faulted reference link.
*/
public QName getPortType();
}
メディエータ・サービス・エンジンの実装
例22-10に、IFaultRecoveryContextインタフェースのOracle Mediatorサービス・エンジンの実装を示します。
例22-10 IFaultRecoveryContextインタフェースの実装
package oracle.tip.mediator.common.error.recovery;
public class MediatorRecoveryContext implements IFaultRecoveryContext{
...
}
例22-11に示すメソッドを使用すると、MediatorRecoveryContextクラスで使用可能なメディエータ固有の追加データを取得できます。
例22-12に、CalloutMediatorMessageインタフェースを使用したデータの取得方法を示します。
例22-12 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;
フォルト・バインディングは、フォルト・ポリシーをコンポジットまたはコンポーネントと関連付けるもので、fault-bindings.xmlファイルで定義されています。fault-bindings.xmlファイルは、第22.4.2項「fault-bindings.xmlのスキーマ定義ファイル」で定義されているXMLスキーマに基づいて作成します。
コンポジット: コンポジット内のすべてのメディエータ・コンポーネントに対してフォルト・ポリシーを1つ定義できます。このレベルは、次の方法で指定できます。
<composite faultPolicy="ConnectionFaults"/>
コンポーネント: メディエータ・サービス・コンポーネントに対するフォルト・ポリシーを排他的に定義できます。コンポーネント・レベルのフォルト・ポリシーは、コンポジット・レベルのフォルト・ポリシーをオーバーライドします。このレベルは、例22-13に示すように、指定できます。
参照: メディエータ・コンポーネントの参照に対するフォルト・ポリシーを定義できます。このレベルは、例22-14に示すように、指定できます。
|
注意: 管理者操作は、フォルト・ポリシーが定義されていないエラーに対するデフォルト・アクションです。 |
例22-15に、フォルト・バインディング・ファイルのサンプルを示します。
フォルト・ポリシーに条件を定義する一方で、エラー・タイプやエラー・グループにはアクションを指定できます。前述の例にある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: 内部エラーが含まれます。
Oracle Mediatorのエラー処理は、fault-policies.xmlおよびfault-bindings.xmlファイルを使用して有効にできます。
メディエータ・サービス・コンポーネントに対してエラー処理を使用する手順は、次のとおりです。
第22.4.1項「fault-policies.xmlのスキーマ定義ファイル」で定義されているスキーマに基づいて、fault-policies.xmlファイルを作成します。
第22.4.2項「fault-bindings.xmlのスキーマ定義ファイル」で定義されているXMLスキーマに基づいて、fault-bindings.xmlファイルを作成します。
fault-policies.xmlおよびfault-bindings.xmlファイルをSOAコンポジット・アプリケーション・プロジェクトのディレクトリにコピーします。
SOAコンポジット・アプリケーション・プロジェクトをデプロイします。
コンポジットに対するフォルト・ポリシーはすべて、最初のエラーが発生したときにロードされます。エラーが発生した場合、メディエータ・サービス・エンジンによってフォルト・ポリシー・ファイル(fault-policies.xmlおよびfault-bindings.xml)が存在しているかどうかがチェックされます。フォルト・ポリシー・バインディングがチェックされ、そのコンポーネントまたはコンポジットと関連付けられているフォルト・ポリシーが判別されます。フォルト・ポリシーがコンポーネントまたはコンポジットと関連付けられている場合、メディエータによって、そのフォルト条件に対応したフォルト・ポリシーで定義されているアクションが実行されます。コンポーネントまたはコンポジットに対してフォルト・ポリシー・バインディングが見つからない場合、アクションは実行されず、動作はフォルト・ポリシーが存在しない場合と同じになります。
定義されているフォルト・ポリシーがなく、ルーティング・ルールが平行して実行される場合、管理者操作のデフォルト・アクションが実行されます。定義されているフォルト・ポリシーがなく、ルーティング・ルールが順次実行される場合、コール元にエラーがスローされます。
|
注意: エラーが発生した順次ルーティング・トランザクションはすべて、フォルト・ポリシーがそのエラーの処理に使用された場合でも、ロールバックされます。 |
フォルト・ポリシーの処理方法の詳細は、第22.1.1.2項「アクション」を参照してください。
フォルト・ポリシー・ファイルを使用するポリシーベースのリカバリとは別に、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 Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
この項では、fault-policies.xmlおよびfault-bindings.xmlファイルのスキーマ・ファイルについて説明します。
fault-policies.xmlファイルは、例22-16に示すように、XSDファイルに基づいている必要があります。
例22-16 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:attribute name="type" 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="fileAction" type="tns:FileActionType"/>
<xs:element name="invokeWS" type="tns:InvokeWSType"/>
<xs:element name="enqueue" type="tns:EnqueueType"/>
<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 Recvorey 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:complexType name="FileActionType">
<xs:annotation>
<xs:documentation>This action stores the rejected message on the file
system.</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element ref="tns:location"/>
<xs:element ref="tns:fileName"/>
</xs:all>
</xs:complexType>
<xs:element name="location" type="xs:string">
<xs:annotation>
<xs:documentation>This value indicates the location of directory which
will be used to store the rejected messages.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="fileName" type="xs:string">
<xs:annotation>
<xs:documentation>This value indicates the filename or the pattern for
the filenames which will be used to store the rejected
messages.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:simpleType name="idType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="InvokeWSType">
<xs:annotation>
<xs:documentation>The Webservice to handle the rejcted
messages.</xs:documentation>
</xs:annotation>
<xs:attribute name="uri" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="EnqueueType">
<xs:annotation>
<xs:documentation>Rejected message will be enqueued to a queue as a
JMS message with the proper context and payload.</xs:documentation>
</xs:annotation>
<xs:attribute name="uri" type="xs:string" use="required"/>
</xs:complexType>
<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 will replay the immidiate 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="faultPolicies">
<xs:annotation>
<xs:documentation>Fault Policies</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:faultPolicy" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<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:schema>
fault-bindings.xmlファイルは、例22-17に示すように、XSDファイルに基づいている必要があります。
例22-17 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>
