| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、Oracle BPELおよびMediatorプロセスのエラー処理およびAIAエラー・ハンドラ・フレームワークの概要を示し、フォルト処理用にAIAプロセスを使用可能にする方法、同期メッセージ交換パターンに対してエラー処理を実装する方法、保証付きメッセージ配信が確保されるように非同期メッセージ交換パターンに対してエラー処理およびリカバリを実装する方法、通知用にAIAサービスを構成する方法、FaultNotification要素の記述、フォルト・メッセージの拡張、エラー処理の拡張、およびトレース・ロギング用にOracle AIAプロセスを構成する方法について説明します。
この章の内容は次のとおりです。
Oracle AIA B2Bエラー処理の詳細は、「AIAを使用したB2B統合の概要」を参照してください。
この項には次のトピックが含まれます:
Oracle Application Integration Architecture (AIA)エラー処理フレームワークでは、BPELプロセスのエラーが次の2つのカテゴリに分類されています。
実行時フォルト
ビジネス・フォルト
実行時フォルト
実行時フォルトは、2つのシナリオのいずれかで発生する可能性があります。
パートナ・リンクの呼出しに失敗した。
パートナ・リンクが、実行時フォルトであることを示す名前付きフォルトを受信した。
この種のフォルトはユーザー定義ではなく、システムにより発行されます。BPELプロセスで実行時フォルトが発生する可能性がある状況には、次のものがあります。
プロセスによって、値の不適切な使用が試行される。
論理エラーが発生する。
SOAPコールでSOAPフォルトが発生する。
サーバーによって例外が発行されるなど。
BPELプロセスとして作成されたAIAサービスは、実行時フォルトを取得して処理するように有効化および構成される必要があります。
ビジネス・フォルト
ビジネス・フォルトは、2つのシナリオのいずれかで発生する可能性があります。
BPELプロセスが条件をフォルトとして評価してthrowアクティビティを実行した。
invokeアクティビティが、ビジネス・フォルトであることを示す名前付きフォルトを受信した。
ビジネス・フォルトはアプリケーション固有のフォルトであり、メッセージを処理する際にエラー状況が発生すると生成されます。これらのフォルトはBPELプロセス・コンポーネントによって指定され、WSDLで定義されます。
BPELプロセスとして作成されたAIAサービスは、実行時フォルトおよびビジネス・フォルトを取得して処理するように有効化および構成される必要があります。
メディエータ・コンポーネントでは、実行時フォルトとビジネス・フォルトの両方を処理できます。
実行時フォルト
これらは、ネットワークが使用可能でないなど、基本システムでの問題によって発生するフォルトです。
ビジネス・フォルト
これらはコールされたWebサービスが返す例外です。これらはアプリケーション固有であり、サービスのWSDLファイルで明示的に定義されます。
メディエータ・コンポーネントとして作成されたAIAサービスは、ビジネス・フォルトを取得して処理するように有効化および構成される必要があります。
ただし、フォルト・ポリシーの適用対象は、パラレルのルーティング・ルールのみです。順次ルーティング・ルールの場合、フォルトはコール元に返され、コール元がフォルトの処理を担当します。
順次ルーティング・ルールのみを使用することをお薦めします。
順次ルーティング・ルールを使用した同期呼出しから発生するビジネス・フォルトをメディエータで処理するように構成する方法は、「ビジネス・フォルトを処理するためのメディエータの構成に関するガイドライン」を参照してください。
エラー処理フレームワークおよびその機能の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のエラー処理の設定に関する項を参照してください。
この項には次のトピックが含まれます:
フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーをSOAコンポジット・アプリケーション(サービス・コンポーネントまたは参照バインディング・コンポーネント)に関連付けます。フォルト・ポリシー・バインディング・ファイルは、fault-bindings.xmlという名前にする必要があります。これは、fault-bindings.xsdスキーマ・ファイルに準拠しています。
フォルト・ポリシー・ファイルの名前は、単一の固有名に限定されているわけではありません。ただし、命名規則に従ったフォルト・ポリシー・ファイルにすることをお薦めします。すべてのフォルト・ポリシー・ファイルには、<ServiceName>FaultPolicy.xmlの規則を使用して名前を指定してください。これらはfault-policy.xsdスキーマ・ファイルに準拠する必要があります。
命名規則の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。
フォルト・ポリシー・バインディング・ファイルを定義して、フォルト・ポリシー・ファイルに定義されたポリシーをSOAコンポジット・アプリケーションに関連付けることをお薦めします。
SOAコア拡張機能には、Oracle Metadata Services (MDS)のAIAMetaData/faultPolicies/V1フォルダに格納されたデフォルトのフォルト・ポリシーが付属しています。デフォルトのフォルト・ポリシーを使用する場合は、例17-1に示した要素をcomposite.xmlファイルに追加してください。
カスタマイズしたサービス固有のフォルト・ポリシー・ファイルをAIAサービスに使用するように選択する場合は、フォルト・ポリシー・ファイルおよびフォルト・ポリシー・バインディング・ファイル(fault-bindings.xml)をSOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリに配置することをお薦めします。
相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のFault-policies.xmlのスキーマ定義ファイル操作に関する項およびFault-bindings.xmlのスキーマ定義ファイル操作に関する項を参照してください。
例17-1 composite.xmlに追加する要素
<property name="oracle.composite.faultPolicyFile">[pointer to the fault policy xml file in the MDS]</property> <property name="oracle.composite.faultBindingFile">[pointer to the fault policy bindings file fault-bindings.xml in the MDS]</property>
次の例は、サンプルのフォルト・ポリシー・ファイルに定義されたフォルト・ポリシーをフォルト・ポリシー・バインディング(.xml)ファイルに関連付ける方法を示しています。
例17-2に示すフォルト・ポリシーが定義されたサンプルのフォルト・ポリシー・ファイルSamplesQueryCustomerPartyPortalProvABCSImplFaultPolicy.xmlを検討します。
SOAコンポジット・アプリケーションまたはコンポーネント(BPELプロセスまたはOracle Mediatorサービス・コンポーネント)のいずれかを使用して、前述のフォルト・ポリシー・ファイルに定義されているポリシーをフォルト・ポリシー・バインディングのレベルに関連付けます。
fault-bindings.xmlファイルで、例17-3に示すように関連付けます。
注意:
この例では、関連付けはSOAコンポジット・アプリケーションのレベルで適用されます。
単一のコンポーネントを使用してコンポジットを作成する必要がある提示に準拠するように、フォルト・ポリシー・バインディング・レベルがデフォルトでSOAコンポジット・アプリケーションになるようにすることをお薦めします。
例17-2 フォルト・ポリシーが定義されたサンプルのフォルト・ポリシー・ファイル
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
id="SamplesQueryCustomerPartyPortalProvABCSImplFaultPolicy" . . . . . . .>
</faultPolicy>
</faultPolicies>
例17-3 fault-bindings.xmlでの関連付け
<faultPolicyBindings version="2.0.1"xmlns="http://schemas.oracle.com/bpel/
faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<compositefaultPolicy="SamplesQueryCustomerPartyPortalProvABCSImpl
FaultPolicy"/>
</faultPolicyBindings>
BPELプロセスでフォルト処理を実装する手順は、次のとおりです。
BPELプロセスでEBM HEADER変数を定義し、その変数を最初のステップとして入力します。
エラー処理フレームワークでは、この変数を使用してエンタープライズ・ビジネス・メッセージ(EBM)ヘッダーからフォルト・メッセージにコンテキスト詳細を入力します。BPELプロセスがアプリケーション・ビジネス・コネクタ・サービス(ABCS)である場合、入力はアプリケーション・ビジネス・メッセージ(ABM)であり、ABMがEBMに変換され次第、即時にEBM HEADER変数の値を入力する必要があります。このようにして、この変換ステップの後でパートナ・リンクでエラーが発生した場合は、エラー処理フレームワークがEBMヘッダー詳細にアクセスして情報を使用します。
BPELプロセスのフォルト・ポリシーを定義して、fault-bindings.xmlでこのポリシーをプロセスにバインドします。
サービス固有のフォルト・ポリシー・ファイルを使用している場合は、デフォルトのポリシーに指定されているCompositeJavaAction (oracle.apps.aia.core.eh.CompositeJavaAction)を常に使用します。エラー通知およびエラー・ロギングに対して、このCompositeJavaActionアカウントをインクルードします。
ビジネス・フォルトを処理するために、フォルト・ポリシーXMLファイルを定義する方法の詳細は、「ビジネス・フォルトの処理」を参照してください。
実行時フォルトを処理するために、同期メッセージ交換パターン(MEP)にフォルト・ポリシーXMLファイルを定義する方法の詳細は、「同期メッセージ変換パターンに対するエラー処理の実装」を参照してください。
実行時フォルトを処理するために、非同期MEPにフォルト・ポリシーXMLファイルを定義する方法の詳細は、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。
catchブロックを定義します。
CompositeJavaAction後のフォルト・ポリシーのデフォルトの動作は再スローの実行です。これによって、BPELプロセスに指定されたcatchまたはcatch-allブロックに対する実行制御が戻ります。
フォルト・ポリシーを使用したフォルトのインターセプトは、インターセプトしたフォルトと同じフォルトがCompositeJavaActionによって再スローされるため、ある意味では透過的です。したがってBPELでは、invokeアクティビティから発生する可能性があるバインディング・フォルトまたはリモート・フォルトなどのフォルトを捕捉する必要があります。
したがって、設計時に想定される各ビジネス・フォルトおよび各実行時フォルトに対してcatchブロックを定義します。
catch-allブロックを定義します。
これは、プロセスの実行中に発生する可能性がある予期しないエラーの捕捉に役立ちます。
同期リクエスト/レスポンスMEPに対するBPELのcatchおよびcatch-allブロックの定義の詳細は、「同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン」を参照してください。
非同期MEPに対するBPELのcatchおよびcatch-allブロックの定義の詳細は、「BPELのCatchおよびCatch-Allブロックに関するガイドライン」を参照してください。
この項には次のトピックが含まれます:
この項には次のトピックが含まれます:
次のコード・スニペットに記載されたガイドラインどおりにフォルト・ポリシーXMLファイルにフォルトを定義します。例17-4に示すように、フォルト・ポリシーのConditionsの下にセクションを定義します。
前述したように、リモート・フォルトおよびバインディング・フォルトはデフォルトで定義することをお薦めしますが、その他の実行時フォルトは、サービスの機能ごとに必要に応じて同様の方法で処理できます。
たとえば、subLanguageExecutionFaultフォルトを処理する必要がある場合は、例17-5に示すようなセクションを定義します。
ただし、フォルト・ポリシー・ファイルに定義されたすべての実行時フォルトを、BPELプロセスのフォルトに固有のcatchブロックで捕捉する必要があります。
同期リクエスト/レスポンスMEPに対するBPELのcatchおよびcatch-allブロックの定義の詳細は、「同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン」を参照してください。
例17-4 フォルト・ポリシーXMLファイルのフォルト定義
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"name="bpelx:
remoteFault">
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:
bindingFault">
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
例17-5 subLanguageExecutionFaultフォルト処理
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"name="bpelx:
subLanguageExecutionFault">
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
フォルト管理フレームワークを使用して、invokeアクティビティに対するビジネス・フォルトを処理します。つまり、invokeアクティビティを使用して呼び出された外部サービスおよびアプリケーションによってスローされたビジネス・フォルトのみが、フォルト・ポリシー・ファイルに指定された定義に従って、Oracle Fusion Middlewareフォルト管理フレームワークによってインターセプトされます。
BPEL内部のビジネス・フォルト(たとえば、throwアクティビティによってスローされたビジネス・フォルト)は、フォルト管理フレームワークではインターセプトされません。
Oracle AIAフォルトをインターセプトするためのフォルト・ポリシーを定義する手順は、次のとおりです。
各BPELプロセスには、リモート・フォルト、バインディング・フォルト、ビジネス・フォルト(Oracle AIAフォルト)および設計時にパートナ・リンクで予想されるその他のフォルトに対して明示的なcatchブロックがあります。次のガイドラインを使用して、これらのcatchブロックを定義します。
内部ビジネス・フォルトを処理する手順は、次のとおりです。
throwアクティビティを実行するBPELプロセスの場合は、例17-6に示すように、ビジネス・フォルト・メッセージ(Oracle AIAフォルト・メッセージ)を作成して、AIAフォルト・メッセージにECIDを入力します。
注意:
EBM_to_Fault.xslで、<corecom:ExecutionContextID/>要素が<corecom:FaultingService>要素の下に挿入されていることを確認します。
前述のフォルト・メッセージをcatchブロックで捕捉します。catchブロックで、次のことを実行します。
AIAフォルト・メッセージをリプライとして送信します。
このOracle AIAフォルト・メッセージを入力として使用してAIAAsyncErrorHandlingBPELProcessを呼び出します。
捕捉されたAIAフォルト・メッセージをスローします。この再スローによって、Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。
外部ビジネス・フォルトを処理する手順は、次のとおりです。
BPELのinvokeアクティビティの場合は、AIAフォルト・メッセージをレスポンスとして受信し、AIAフォルト・メッセージをcatchブロックで捕捉します。catchブロックで、次のことを実行します。
AIAフォルト・メッセージをリプライとして送信します。
捕捉されたAIAフォルト・メッセージをスローします。この再スローによって、Oracle Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。
注意:
この場合、ビジネス・フォルトは関連するフォルト・ポリシー・ファイルに定義されたフォルト・ポリシーに従ってOracle Fusion Middlewareのフォルト管理フレームワークで処理されるため、AIAではAIAAsyncErrorHandlingBPELProcessは呼び出されません。
例17-6 ビジネス・フォルト・メッセージ
<sequence name="SequenceBusinessFault">
<assign name="AssignBusinessFault">
<copy>
<from expression="ora:processXSLT('xsl/EBM_to_Fault.xsl',bpws:
getVariableData('EBM_HEADER'))"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault"/>
</copy>
<copy>
<from expression="'invalid account id'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Text"/>
</copy>
<copy>
<from expression="'invalid account id'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Stack"/>
</copy>
<copy>
<from expression="ora:getCompositeInstanceId()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:
Fault/corecom:FaultNotification/corecom:FaultingService/corecom:
InstanceID"/>
</copy>
<copy>
<from expression="'BPEL'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ImplementationCode"/>
</copy>
<copy>
<from expression="ora:getCompositeName()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:
Fault/corecom:FaultNotification/corecom:FaultingService/corecom:ID"/>
</copy>
<copy>
<from expression="ora:getECID()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ExecutionContextID"/>
</assign>
<throw name="Throw_custom_business_fault" faultName="client:fault"
faultVariable="AIAFaultMessage"/>
</sequence>
フォルト・ポリシーxmlファイルに定義された各実行時フォルトに対して、BPELには1つのcatchブロックがあります。
フォルト・ポリシー・ファイルに定義された実行時フォルトを処理する手順は、次のとおりです。
catchブロックで、Oracle AIAフォルト・メッセージを作成します。
このOracle AIAフォルト・メッセージをリプライとして送信します。
捕捉されたフォルトを再スローします。これによって、Oracle BPELコンソールにプロセスがフォルトとして表示されるようになります。
また、各BPELプロセスには、catchブロックでは捕捉されない、フォルト・ポリシー・ファイルに定義されていない実行時フォルトを処理する1つのcatch-allブロックがあります。
catch-allブロックを定義する手順は、次のとおりです。
フォルト管理フレームワークの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のフォルト管理フレームワークの使用に関する項を参照してください。
例17-7 Catch-Allブロックの作成
<sequence name="SequenceCatchAll">
<assign name="AssignFault">
<copy>
<from expression="ora:processXSLT('xsl/EBM_to_Fault.xsl',bpws:
getVariableData('EBM_HEADER'))"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault"/>
</copy>
<copy>
<from expression="ora:getFaultAsString()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Text"/>
</copy>
<copy>
<from expression="ora:getFaultAsString()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Stack"/>
</copy>
<copy>
<from expression="ora:getCompositeInstanceId()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
InstanceID"/>
</copy>
<copy>
<from expression="'BPEL'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ImplementationCode"/>
</copy>
<copy>
<from expression="ora:getCompositeName()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:ID"/>
</copy>
<copy>
<from expression="ora:getECID()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ExecutionContextID"/>
</assign>
</sequence>
Oracle Mediatorでは、ビジネス・フォルト用のフォルト・ポリシーをベースとしたエラー処理を提供します。ただし、フォルト・ポリシーの適用対象は、パラレルのルーティング・ルールのみです。順次ルーティング・ルールの場合、フォルトはコール元(メディエータの呼出し元)に返され、コール元がフォルトの処理を担当します。
順次ルーティング・ルールのみを使用することをお薦めします。
メディエータによって呼び出されたサービスがビジネス・フォルトをスローした場合は、メディエータを呼び出したサービスまで、このフォルトを伝播する必要があります。
この項では、メディエータが呼び出したサービスから返された例外を処理するように、メディエータを構成する方法について検討します。
いくつかの考慮事項があります。
メディエータがサービスを呼び出した場合は、呼び出されたサービスがWSDLに定義されているビジネス・フォルトをスローできます。
呼び出されたサービスによってスローされるフォルトはメディエータに伝播されます。
メディエータが呼び出したサービスから返された例外を処理するように、メディエータを構成する手順は、次のとおりです。
図17-1 メディエータでのフォルトの割当
この項には次のトピックが含まれます:
AIAにおける非同期MEPに対する保証付きメッセージ配信とは、送信者から開始されたメッセージが正常に配信されて受信者に確認(確認が必要な場合)されるまで、そのメッセージが保持されることを意味します。
送信側と受信側は必ずしも参加アプリケーションである必要はありません。むしろ、これらはOracle AIA統合フローの論理的なマイルストンになります。Oracle AIA統合シナリオには複数のマイルストンが存在する可能性があります。
非同期メッセージ・フローでハードウェアまたはソフトウェア・サービスが一時的に使用不可になっている場合もメッセージの消失や配信の失敗は発生しません。エラー処理フレームワークには、ハードウェアまたはソフトウェア・サービスが使用可能になるまでメッセージを保持する手段が用意されています。
エラー・コンソールでリソースを使用できないことが統合管理者に通知されると、管理者はリソースの問題に対応できます。統合管理者は、その後メッセージ再発行ユーティリティを使用して、統合シナリオに保持されているメッセージを適切なトランザクション・マイルストン・ポイントから再発行し、これによって、次のコンポーネントまたはマイルストンへの配信が可能になります。
メッセージ再発行ユーティリティの実行の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のメッセージ再発行ユーティリティの使用に関する項を参照してください。
次のポイントは、非同期MEPの保証付きメッセージ配信プログラミング・モデルの実装について主な側面を要約しています。
メッセージ永続性マイルストン
メッセージは永続性ストア(ソース)から選択されて処理され、次の永続性ストア(ターゲット)に格納されます。メッセージは、正常に処理されてターゲットに配信されるまで、ソースから削除されません。ソースおよびターゲットはアプリケーションです。各永続性ストアはマイルストンを表し、データベース、ファイル・システム、JMSキューまたはJMSトピックです。
マイルストンの構成の詳細は、「マイルストンの構成」を参照してください。
グローバル・トランザクション
次のタスクは、グローバル・トランザクションの一部として実行する必要があります。
ソースからメッセージを選択します。
1つ以上のサービスでメッセージを処理します。
メッセージをターゲットに配信します。
入力メッセージによるソースからのサービスの開始によってトランザクションが開始されます。ダウンストリームが呼び出されたすべてのサービスは、このグローバル・トランザクションに関与します。メッセージがターゲットに正常に配信され、ソースから削除されると、このグローバル・トランザクションは終了またはコミットされます。
エラーの場合は、例外が発生し、開始されたトランザクションはメッセージセーフでソースにロールバックされます。メッセージはソースまたはターゲットのいずれかに存在し、消失することはありません。
グローバル・トランザクションの構成の詳細は、「マイルストン間のサービスの構成」を参照してください。
エラー処理およびリカバリ
システムまたはビジネス・エラーに起因する例外は、先行するすべてのサービスのロールバックを生成し、単一のエラー通知を統合管理者にトリガーする必要があります。エラー状態が削除されるまでメッセージが処理されないように、ソースのメッセージをフォルトとしてマークする必要があります。
エラー・ロールバックの構成の詳細は、「未発行ロールバック・メッセージに対するフォルト・ポリシーの構成」を参照してください。
システム・エラーの場合は、例外状態が削除された後、ソース内にある失敗したメッセージをリセットする必要があります。これによって再発行できるようになります。メッセージ再発行ユーティリティを使用して、正しいソースで再処理するようにメッセージを再発行できます。
ビジネス・エラーの場合は、ソース内の失敗したメッセージを削除し、さらに処理するためにフォールアウト管理に送信する必要があります。フォールアウト管理は、ビジネス・エラーが発生したメッセージを分離して個別に処理するカスタム実装です。
たとえば、処理のために発行されたオーダーでビジネス・エラーが発生したとします。オーダー・フォールアウト管理の実装の一環として、エラー・メッセージを調査してエラーの説明および是正措置を提供するトラブル・チケットを発行するアプリケーションに、オーダー・メッセージおよびエラー・メッセージがルーティングされます。是正措置に対応した後、オーダーは再処理されます。
非同期MEPのエラー処理およびリカバリは、次のように実装され、保証付きメッセージ配信が確保されます。
各メッセージに一意のメッセージ識別子が割り当てられます。
EBMヘッダーにソース・マイルストン識別子が入力されます。
失敗したメッセージのメッセージ識別子とソース・マイルストン識別子がフォルト通知に確実に含まれるようにします。
メッセージ再発行ユーティリティを使用して、失敗したメッセージをリカバリし、再発行します。
これらの構成の実装方法の詳細は、「マイルストンの構成」および「マイルストン間のサービスの構成」を参照してください。
メッセージ再発行ユーティリティの使用の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド 11.1.1.9のメッセージ再発行ユーティリティの使用に関する項を参照してください。
メッセージ再発行ユーティリティAPIの詳細は、「メッセージ再発行ユーティリティAPIの使用」を参照してください。
この項には次のトピックが含まれます:
これらのアクティビティを完了すると、マイルストン間のサービスが構成され、保証付きメッセージ配信を確保するために非同期MEPのエラー処理およびリカバリが提供されます。
EBMヘッダーの次のパラメータは、JMSコンシューマ・サービス変換で値を入力する必要があります。
SenderResourceTypeCode
ロールバックされたメッセージを格納するリソースまたはシステムのタイプ(キューまたはトピック)を示します。
SenderResourceID
SenderResourceTypeCodeのタイプ(リソース/システム)の識別。
SenderMessageID
SenderResourceTypeCodeのタイプに関連付けられたリソース/システムに保持されるメッセージの識別。
シナリオ1
JMSキューまたはトピックのABMがJMSコンシューマ・サービスをトリガーしている場合は、ABMヘッダーの一部として前述の情報をリクエスタABCSに渡す必要があります。
詳細は、「JMSConsumerAdapterのメッセージ再発行値のABMへの入力」を参照してください。
JMSコンシューマ・サービスで、この情報をABMヘッダーに送信するように構成する必要があります。リクエスタABCSで、この情報がABMヘッダーから抽出され、変換でEBMヘッダーに送信されます。
詳細は、「リクエスタABCSの再発行値のEBMヘッダーへの入力」を参照してください。
シナリオ2
JMSキューまたはトピックのEBMがJMSコンシューマ・サービスをトリガーしている場合は、EBMからEBMへの変換を使用して、EBMメッセージの再発行値を入力(上書き)します。インバウンド・メッセージのEBMヘッダー・フィールドの次の値は、現在のマイルストンに関連するリソース・タイプ、リソース名およびJMSメッセージIDを新しい値で上書きする必要があります。
<corecom:SenderResourceTypeCode>
<corecom:SenderResourceID>
<corecom:SenderMessageID>
例17-8に、EBMからEBMへのXSLサンプル・コード・スニペットを示します。
例17-8 EBMからEBMへのXSLコードの例
<corecom:IntermediateMessageHop>
<corecom:SenderResourceTypeCode>
<xsl:value-of select="/custebo:CreateCustomerPartyListEBM/corecom:
EBMHeader/corecom:FaultNotification/corecom:FaultMessage/corecom:
IntermediateMessageHop/corecom:SenderResourceTypeCode"/>
</corecom:SenderResourceTypeCode>
<corecom:SenderResourceID>
<xsl:value-of select="/custebo:CreateCustomerPartyListEBM/corecom:
EBMHeader/corecom:FaultNotification/corecom:FaultMessage/corecom:
IntermediateMessageHop/corecom:SenderResourceID"/>
</corecom:SenderResourceID>
<corecom:SenderMessageID>
<xsl:value-of select='mhdr:getProperty("in.property.jca.jms.
JMSMessageID")'/>
</corecom:SenderMessageID>
</corecom:IntermediateMessageHop>
次の内容でABMがエンリッチされていることを確認します。
一意のメッセージID。JMSヘッダーのJMSMessageIDが値として使用されます。
リソース名。これはJMSキュー/トピック名です。この値は、JMSConsumerAdapterのcomposite.xmlの<svcdoc: ResourceName>と同じです。
リソースのタイプです。可能な値はQueueまたはTopicです。
この目的でABMに明確に指定されたフィールドを使用します。これらのフィールドは設計時に識別されます。
メディエータ・ベースのJMSConsumerAdapter内で、次のようにします。
メディエータ・ルーティング・ルールの変換ステップを使用します。
変換に使用されるXSLで、JMSメッセージID、リソース名およびリソース・タイプの値を、ABMの明確に指定されたフィールドに割り当てます。
例17-9に、JMSメッセージIDをABMに割り当てる方法を示します。
例17-9 ABMへのJMSメッセージIDの割当方法の例
<xsl:attribute name="MessageId">
<xsl:value-of select='mhdr:getProperty("in.property.jca.jms.JMSMessageID")'/>
</xsl:attribute>
この例では、ABMにJMSメッセージIDの割当先について固有の属性MessageIdがあることを前提としています。
場合によっては、指定された1つのフィールドのみがABMで使用できることがあります。このようなシナリオでは、JMSメッセージID、リソース名およびリソース・タイプの値を連結し、ABMの指定された特定のフィールドに値を割り当てます。これらの値を連結する際は、::をセパレータとして使用することをお薦めします。
たとえば、Siebel顧客ABMのListOfCmuAccsyncAccountIoについて検討します。このABMでは、設計時にJMSメッセージID、リソース名およびリソース・タイプに関する情報を保持するために、ListOfCmuAccsyncAccountIo要素のMessageId属性が指定されているとします。例17-10に、データを連結してABMに割り当てる方法を示します。
例17-10 データを連結してABMに割り当てる方法の例
<xsl:attribute name="MessageId">
<xsl:value-of select='concat(mhdr:getProperty("in.property.jca.jms.
JMSMessageID"),":: SampleQueue","::Queue")'/>
</xsl:attribute>
JMSメッセージID、リソース名およびリソース・タイプの値がABMの指定フィールドで使用可能になっているため、ABMがリクエスタABCSに達するときは、それらの値が含まれます。
ヒント:
ABMからEBMへの変換の際は、<corecom: FaultNotification/>要素がEBMヘッダーに挿入されることを確認してください。
これらの値をABMから抽出し、EBMヘッダーの次の要素を<corecom:IntermediateMessageHop>要素に入力します。
<corecom:SenderResourceTypeCode>: リソース・タイプの値を入力します。
<corecom:SenderResourceID>: リソース名の値を入力します。
<corecom:SenderMessageID>: JMSメッセージIDの値を入力します。
ABMからEBMへの変換を実行するXSLで、このタスクを実行する必要があります。例17-11に示すように、3つの再発行値を保持するために3つの異なるABMフィールドが指定されている場合、タスクは単純です。
例17-11 3つの再発行値の保持に使用される3つのABMフィールドを示す例
<corecom:IntermediateMessageHop>
<corecom:SenderResourceTypeCode>
<xsl:value-of select="[xpath to the ABM field holding the ResourceType]"/>
</corecom:SenderResourceTypeCode>
<corecom:SenderResourceID>
<xsl:value-of select="[xpath to the ABM field holding the
Resource Name]"/>
</corecom:SenderResourceID>
<corecom:SenderMessageID>
<xsl:value-of select="[xpath to the ABM field holding the Message Id]"/>
</corecom:SenderMessageID>
</corecom:IntermediateMessageHop>
次に、3つの再発行値が連結され、ABMの指定された単一のフィールドに割り当てられている場合に、ABMから再発行値を抽出し、EBMヘッダーに割り当てる方法について説明します。
たとえば、Siebel顧客ABMのListOfCmuAccsyncAccountIoについて検討します。このABMでは、JMSメッセージID、リソース名およびリソース・タイプに関する情報を保持するために、::をセパレータとして使用して、ListOfCmuAccsyncAccountIo要素のMessageId属性が指定されているとします。詳細は、前述の項を参照してください。
例17-12に、再発行値を抽出してEBMヘッダー要素に割り当てるコード・スニペットを示します。
例17-12 再発行値の抽出およびEBMヘッダー要素への割当に使用されるコード
<xsl:variable name="MsgId">
<xsl:value-of select="substring-after(/seblcustabo:ListOfCmuAccsyncAccountIo/
@MessageId,'::')"/>
</xsl:variable>
<corecom:IntermediateMessageHop>
<corecom:SenderResourceTypeCode>
<xsl:value-of select="substring-after($MsgId,'::')"/>
</corecom:SenderResourceTypeCode>
<corecom:SenderResourceID>
<xsl:value-of select="substring-before($MsgId,':: ')"/>
</corecom:SenderResourceID>
<corecom:SenderMessageID>
<xsl:value-of select="substring-before(/seblcustabo:ListOfCmuAccsync
AccountIo/@MessageId,'::')"/>
</corecom:SenderMessageID>
</corecom:IntermediateMessageHop>
ABMからEBMへの変換を実行するXSLで、このタスクを実行する必要があります。
メッセージ再発行の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのメッセージ再発行ユーティリティの使用に関する項を参照してください。
単一のグローバル・トランザクションは、次のように構成します。
コミット・ポイントが2つのマイルストン間にないこと。
2つのマイルストン間で行われる作業が、単一の論理単位の作業であること。
グローバル・トランザクションの構成の詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。
この項には次のトピックが含まれます:
フォルト・ポリシーxmlファイルに定義された各実行時フォルトに対して、BPELには1つのcatchブロックがあります。catchブロックで、捕捉したフォルトを再スローします。これによって、Oracle Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。
また、各BPELプロセスには、catchブロックでは捕捉されない、フォルト・ポリシー・ファイルに定義されていない実行時フォルトを処理する1つのcatch-allブロックがあります。
catch-allブロックを定義する手順は、次のとおりです。
Oracle AIAフォルト・メッセージを作成します。例17-13に示すように、AIAフォルト・メッセージにECIDを入力します。
このOracle AIAフォルト・メッセージを入力として使用してAIAAsyncErrorHandlingBPELProcessを呼び出します。
AIAフォルト・メッセージをスローします。これによって、Oracle Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。
これらのcatchおよびcatch-allブロックは最上位レベルのスコープに定義できるため、特に必要な場合を除いて、各パートナ・リンクのスコープに定義する必要はありません。
詳細は、『Oracle SOAスイートでのSOAアプリケーションの開発』を参照してください。
例17-13 ECIDが定義されているAIAフォルト・メッセージ
<copy>
<from expression="ora:getECID()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/corecom:
FaultNotification/corecom:FaultingService/corecom:ExecutionContextID"/>
</copy>
保証付きメッセージ配信プログラミング・モデルに従ってメッセージをグローバル・トランザクションのフローのサービスまたはコンポーネントに配信できない場合、そのメッセージは適切なソース・マイルストンにロールバックされます。このソース・マイルストンは、Oracleアドバンスト・キュー、JMSトピックまたはメディエータ・レスポンス・ストアに相当します。メッセージは、サービスまたはコンポーネントに配信するための再発行が可能になるまで、ここに保持されます。
トランザクション・ロールバック・パスに従って、BPELプロセスがフォルト・メッセージを発行しますが、その際、ロールバック・メッセージを発行しないように構成されている必要があります。ロールバック・パスのサービスが不要な通知を発行しないように、構成によってロールバック・トランザクションを解読します。
ロールバック・メッセージを抑制するこの構成がないと、これらのプロセスによって不要な通知が発行されます。たとえば、図17-4に示すトランザクション・ロールバック・フローでは、リクエスタABCSによって冗長なロールバック通知が送信されることに加え、単に1回発行する必要があるその通知がプロバイダABCSからも送信されることになります。
図17-4 トランザクション・ロールバック・フロー
ロールバック・トランザクションでの不要な通知を抑制する手順は、次のとおりです。
catchブロックでスローするかわりに、bpelx:rollbackを使用します(<throw name="ThrowEBSFault" faultName="bpelx:rollback"/>)。
例17-15に示すように、Javaスニペットを使用してOracle AIAエラー・ハンドラを呼び出します。
トランザクション・ロールバック・フローに沿って、メディエータおよびBPELプロセスのフォルト・ポリシーに空のno-opアクションを追加します。この空のno-opアクションはaia-no-actionです。
メディエータまたはBPELプロセスがロールバック・メッセージを受信すると、制御は、aia-no-actionアクションに対して実装されたoracle.apps.aia.core.eh.CompositeJavaNoActionというクラスに移動します。
oracle.apps.aia.core.eh.CompositeJavaNoActionクラスは空の操作で、何も実行せずにロールバック・フローの以降の通知を抑制することを意味します。
次のサンプルBPELおよびメディエータのフォルト・ポリシーは、これらの条件を影響を受けるフォルト・ポリシー・ファイルに定義する方法を示しています。
aia-no-actionフォルト・ポリシーにはフィルタ式があり、ロールバック・フォルトORABPEL-02180の場合は、アクションなしを実行します。例17-14に例を示します。
例17-14 Oracle AIAエラー・ハンドラを呼び出すJavaスニペット
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicy version="2.0.1" id="SamplesCreateCustomerPartyPortal
ProvABCSImplFaultPolicy" 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>
<faultNamexmlns:plmfault="http://xmlns.oracle.com/EnterpriseServices
/Core/CustomerParty/V2" name="plmfault:fault">
<condition>
<test>$fault.summary/summary[contains(., "ORABPEL-02180")]</test>
<action ref="aia-do-nothing"/>
</condition>
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
<faultName>
<condition>
<test>$fault.summary/summary[contains(., "ORABPEL-02180")]</test>
<action ref="aia-do-nothing"/>
</condition>
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
</Conditions>
<Actions>
<!-- This action will attempt 8 retries at increasing intervals of
2, 4, 8, 16, 32, 64, 128, and 256 seconds. -->
<Action id="aia-ora-retry">
<retry>
<retryCount>1</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="aia-ora-java"/>
<retrySuccessAction ref="aia-ora-java"/>
</retry>
</Action>
<!-- This is an action will cause a replay scope fault -->
<Action id="ora-replay-scope">
<replayScope/>
</Action>
<!-- This is an action will bubble up the fault -->
<Action id="ora-rethrow-fault">
<rethrowFault/>
</Action>
<!-- This is an action will mark the work item to be "pending recovery
from console" -->
<Action id="ora-human-intervention">
<humanIntervention/>
</Action>
<!-- This action will cause the instance to terminate -->
<Action id="ora-terminate">
<abort/>
</Action>
<Action id="aia-do-nothing">
<javaAction className="oracle.apps.aia.core.eh.CompositeJavaNo
Action" defaultAction="ora-rethrow-fault">
<returnValue value="REPLAY" ref="ora-terminate"/>
<returnValue value="RETRHOW" ref="ora-rethrow-fault"/>
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="aia-ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>
<Action id="aia-ora-java">
<javaAction className="oracle.apps.aia.core.eh.CompositeJava
Action" defaultAction="ora-rethrow-fault">
<returnValue value="REPLAY" ref="ora-terminate"/>
<returnValue value="RETRHOW" ref="ora-rethrow-fault"/>
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="aia-ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>
</Actions>
</faultPolicy>
例17-15 no-opアクションaia-no-actionを使用するサンプル・フォルト・ポリシー
<bpelx:exec name="Java_Embedding_1" language="java" version="1.5">
<![CDATA[ oracle.apps.aia.core.eh.InvokeBusinessErrorHandler.process
((oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable",
"FaultMessage","/ns1:Fault"));]]>
</bpelx:exec>
この項では、BPELフォルトを処理する際に実行する必要がある標準的な構成ステップについて説明します。
この項には次のトピックが含まれます:
通知ロールの定義方法の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のエラー処理の設定に関する項を参照してください。
カスタム・フォルトまたはビジネス・フォルト(throwアクティビティでスローされたビジネス・フォルト)の場合は、<MW_HOME>/soa/modules/oracle.soa.ext_11.1.1/classesフォルダにあるAIAMessages.propertiesファイルにコードを追加し、サーバーを再起動することで、修正処理コードを定義します。翻訳された文字列が、その言語が配置されている同じディレクトリの言語に適したプロパティ・ファイルに格納されていることを確認します。
このカスタムXPath関数を使用して、このリソース・バンドルから詳細をローカライズされた形式: Signature: aia:getCorrectiveAction (String key, String locale, String delimiter)で取得できます。
パラメータ詳細には、次の情報が含まれます。
Key
修正処理コード。
Locale
言語コード、国コードおよびバリアントの連結した文字列。例: en-US。
Delimiter
localeパラメータに使用するデリミタ(-など)。
カスタム・フォルトまたはビジネス・フォルト(throwアクティビティでスローされたビジネス・フォルト)の場合は、<MW_HOME>/soa/modules/oracle.soa.ext_11.1.1/classesフォルダにあるAIAMessages.propertiesファイルにコードを追加し、サーバーを再起動することで、修正処理コードを定義します。翻訳された文字列が、その言語が配置されている同じディレクトリの言語に適したプロパティ・ファイルに格納されていることを確認します。
このカスタムXPath関数を使用して、このリソース・バンドルから詳細をローカライズされた形式: Signature: aia:getErrorMessage (String key, String locale, String delimiter)で取得できます。
パラメータ詳細には、次の情報が含まれます。
Key
修正処理コード。
Locale
言語コード、国コードおよびバリアントの連結した文字列(例: en-US)。
Delimiter
localeパラメータに使用するデリミタ(-など)。
この項には次のトピックが含まれます:
このスキーマの最上位レベルの要素はFaultです。図17-5および図17-6に示すように、EBMReference、B2BMReferenceおよびFaultNotificationの3つの要素があります。Faultの要素は、表17-1で説明します。
図17-5 Fault要素とその子要素(1/2)
図17-6 Fault要素とその子要素(2/2)
表17-1 Faultの要素
| 名前 | 目的 | 詳細 |
|---|---|---|
EBMReference |
フォルト・インスタンスに関するコンテキスト情報を提供します。すべての値は、失敗したサービス・インスタンスのEBMのEBMヘッダーから取得されます。 |
詳細は、「EBMReference要素の説明」を参照してください。 |
B2BMReference |
Oracle AIAからのB2Bフローにエラーがある場合に、企業間(B2B)固有の詳細を提供します。 |
詳細は、「B2BMReference要素の説明」を参照してください。 |
FaultNotification |
フォルトの実際の詳細を提供します。 |
詳細は、「FaultNotification要素の説明」を参照してください。 |
この項では、図17-7に示すような、Oracle AIAフォルト・メッセージ・スキーマのEBMReference要素について詳細に説明します。EBM参照の要素は、表17-2で説明します。
図17-7 EBMReference要素とその子要素
表17-2 EBMReferenceの要素
| 名前 | 目的 |
|---|---|
EBMID |
メッセージのEBMIDを提供します。 |
EBMName |
メッセージのEBMNameを提供します。 |
EBOName |
メッセージのEBONameを提供します。 |
VerbCode |
メッセージのVerbCodeを提供します。 |
BusinessScopeReference |
メッセージのBusinessScopeReferenceを提供します。 失敗したサービス・インスタンスが関連していたエンドツーエンド・シナリオについて詳細を提供します。 これは、BusinessScopeTypeCodeとBusinessProcessが等しいBusinessScopeReferenceのインスタンスです。 |
SenderReference |
メッセージのSenderReferenceを提供します。 |
これらの要素の詳細は、「EBMヘッダー概念の概要」を参照してください。
この項では、図17-8に示すような、Oracle AIAフォルト・メッセージ・スキーマのB2BMReference要素について詳細に説明します。B2BM参照の要素は、表17-3で説明します。
図17-8 B2BMReference要素とその子要素
表17-3 B2BMReferenceの要素
| 名前 | 目的 | 詳細 |
|---|---|---|
B2BMID |
Oracle B2Bのトランザクションの識別に使用されるメッセージIDを提供します。 |
ユーザーはこのメッセージIDを使用して、Oracle B2Bで失敗したビジネス・メッセージを問い合せ、失敗したトランザクションを再試行できます。 「AIAを使用したB2B統合の概要」を参照してください。 |
CollaborationID |
同じビジネス・トランザクションに関連する複数のリクエスト/レスポンス・メッセージにわたって共通のコラボレーションIDを提供します。 |
「AIAを使用したB2B統合の概要」を参照してください。 |
ReplyToMessageID |
返信先メッセージのIDを提供します。 |
「AIAを使用したB2B統合の概要」を参照してください。 |
B2BDocumentType/TypeCode |
Oracle B2Bで失敗したトランザクションのドキュメント・タイプを提供します。 |
このフォルトからの情報を使用して、ドキュメント・タイプ固有のエラー処理を定義できます。たとえば、様々なドキュメント・タイプのエラー結果を解決するために異なるユーザーに割り当てることができます。 「AIAを使用したB2B統合の概要」を参照してください。 |
B2BDocumentType/Version |
Oracle B2Bで失敗したトランザクションのドキュメント・タイプ・バージョンを提供します。 |
「AIAを使用したB2B統合の概要」を参照してください。 |
SenderTradingPartner/TradingPartnerID |
B2Bフローの送信側取引パートナ名を提供します。 |
「AIAを使用したB2B統合の概要」を参照してください。 |
ReceiverTradingPartner/TradingPartnerID |
B2Bフローの受信側取引パートナ名を提供します。 |
「AIAを使用したB2B統合の概要」を参照してください。 |
GatewayID |
フローの開始に使用されたB2Bソフトウェアの名前を提供します(例: Oracle B2B)。 |
「AIAを使用したB2B統合の概要」を参照してください。 |
この項には次のトピックが含まれます:
この項では、図17-9に示すような、Oracle AIAフォルト・メッセージ・スキーマのFaultNotification要素について詳細に説明します。フォルト通知の要素は、表17-4で説明します。
図17-9 FaultNotification要素とその子要素
表17-4 FaultNotificationの要素
| 名前 | 目的 | 詳細 |
|---|---|---|
BusinessComponentID |
アプリケーションの一意キー。 |
オブジェクト・インスタンスの非依存の表現を提供します。 |
ReportingDateTime |
サービスが失敗となった日時を提供します。 |
サービスが失敗となった日時。 |
CorrectiveAction |
失敗に対して考えられる修正処理を提供します。 |
失敗に対する修正処理。 |
FaultMessage |
実際のフォルト・メッセージの詳細を提供します。 |
詳細は、「FaultMessage要素」を参照してください。 |
FaultingService |
フォルト処理サービスの詳細を提供します。 |
詳細は、「FaultMessage要素」を参照してください。 |
表17-5に、フォルト・メッセージの要素を示します。
表17-5 FaultMessageの要素
| 名前 | 目的 | 詳細 |
|---|---|---|
コード |
エラー・コードを提供します。 |
受信したフォルト・コードです。 |
Text |
エラーの詳細を提供します。 |
フォルトの詳細な記述です。 |
Severity |
エラーの重大度を提供します。 |
整数で表現したフォルトの重大度です。 |
Stack |
エラー・スタックを提供します。 |
完全なフォルト・スタックです。 |
ApplicationFaultData |
あらゆる種類のXML入力を受け入れるようにフォルト・メッセージを拡張可能にします。 |
実装シナリオで決定されたとおりに、あらゆる種類のXML入力を格納するようにフォルト・メッセージを拡張可能にします。 フォルト・メッセージの拡張の詳細は、「フォルト・メッセージの拡張」を参照してください。 |
IntermediateMessageHop |
マルチホップ・トランザクションのメッセージに固有のプロパティを取得します。 |
ここに取得されたプロパティを使用して、保証付きメッセージ配信およびメッセージ・リカバリを実装するユースケ－スをサポートできます。 保証付きメッセージ配信およびメッセージ・リカバリの実装の詳細は、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。 |
図17-10に、IntermediateMessageHopの要素を示します。中間メッセージ・ホップの要素は、表17-6で説明します。
図17-10 IntermediateMessageHopの要素
表17-6 IntermediateMessageHopの要素
| 名前 | 目的 | 詳細 |
|---|---|---|
SenderResourceTypeCode |
マルチホッピング・メッセージング・レイヤーで、このメッセージの送信者であるリソースまたはシステムのタイプを格納するために使用されます。 |
この要素の値の例として、Queue、Topic、Resequence Storeなどがあります。 |
SenderResourceID |
SenderResourceTypeCodeに関連付けられたリソースまたはシステムの識別を提供します。 |
SenderResourceTypeCodeに関連付けられたリソースまたはシステムの識別。 |
SenderMessageID |
SenderResourceTypeCodeに関連付けられたリソースまたはシステムに応じたメッセージ識別を提供します。 |
SenderResourceTypeCodeに関連付けられたリソースまたはシステムに応じたメッセージ識別。 |
表17-7に、FaultingService要素を示します。
表17-7 FaultingService要素
| 名前 | 目的 | 詳細 |
|---|---|---|
ID |
サービスが失敗となった日時を提供します。 |
フォルト処理サービスの名前です。 |
ImplementationCode |
失敗に対して考えられる修正処理を提供します。 |
失敗したサービスのタイプを説明する文字列です。可能な値は、BPEL、JAVAおよびOTHERです。 |
InstanceID |
実際のフォルト・メッセージの詳細を提供します。 |
失敗したサービスのインスタンスIDです。サービスがBPELプロセスの場合、これはBPELインスタンスIDです。 |
ExecutionContextID |
ECIDの値を提供します。 |
サービスの呼出し/実行のグループに対して生成されたIDです。 |
この項には次のトピックが含まれます:
統合フロー、メディエータ・サービスまたはBPELプロセス内でエラーが発生すると、エラー処理フレームワークによってフォルト・メッセージからエラーが取得されます。フォルト・メッセージは、Oracle BPM Worklist内のエラー詳細で使用可能になります。
フォルト・メッセージの内容は、Meta.xsd (\EnterpriseObjectLibrary\Infrastructure\V1\Meta.xsd)のFaultTypeメッセージ・スキーマ定義で定義されます。スキーマのデフォルトの要素ではフォルト・メッセージの要件を満たさない場合は、スキーマに格納されたApplicationFaultMessage要素を使用して、メッセージに取得されるフォルト詳細の範囲を拡張できます。
フォルト・メッセージ・スキーマの詳細は、「Oracle AIAフォルト・メッセージ・スキーマの説明」を参照してください。
フォルト詳細を拡張すると、統合フローのコンシューマがフォルトの状況についてさらに理解でき、より効果的なエラーの解決を導く上で役立つ機能的に豊富な情報をフォルト・メッセージに追加できるようになります。同様に、この追加のフォルト詳細を使用して、拡張されたエラー処理機能を使用可能にできます。
エラー処理の拡張の詳細は、「エラー処理の拡張」を参照してください。
たとえば、オーダー・フォールアウト管理アプリケーションでオーダー表を更新し、新規のサービス・リクエストを作成する拡張エラー処理タスクの実行に必要なオーダー番号と履行システムの値を使用してフォルト・メッセージをエンリッチできます。
フォルト・メッセージの拡張には、Meta.xsdのFaultTypeメッセージ・スキーマ定義にあるxsd:anyTypeタイプのApplicationFaultData要素(図17-11で強調表示)を使用します。
図17-11 Meta.xsdで強調表示されたApplicationFaultData要素
ApplicationFaultData要素は、BPELフォルトの場合にエラー処理フレームワークによって実行時に呼び出されるように構成したフォルト拡張ハンドラによって入力されます。
フォルト拡張ハンドラに対する入力は、デフォルトのフォルト・メッセージです。フォルト拡張ハンドラは、ApplicationFaultData要素に定義された追加の内容を使用してフォルト・メッセージをエンリッチします。エンリッチされたフォルト・メッセージの制御は、フォルト拡張ハンドラからエラー処理フレームワークに移動し、処理をさらに進行するために、フォルト・メッセージはOracle AIAの共通エラー・ハンドラに渡されます。
フォルト・メッセージを拡張する手順は、次のとおりです。
フォルト・メッセージをエンリッチする際に呼び出すフォルト拡張ハンドラを作成します。
「エラー通知」ページの「エラー拡張ハンドラ」フィールドに、フォルト・メッセージを拡張する際に呼び出すエラー拡張ハンドラの名前を入力します。たとえば、オーダー・フォールアウトのエラー拡張ハンドラにはORDERFOEH_EXTと入力します。
エラー処理フレームワークによって、エラー・コード、システム・コード、サービス名およびプロセス名パラメータの組合せに基づいて、エラー拡張ハンドラにデフォルトでないパラメータが定義されているかどうかが判断されます。
存在する場合は、AIAConfigurationProperties.xmlファイルのパラメータの完全なクラスパスが検索され、基本のフォルト・メッセージを入力として使用して、そのハンドラに対するコールアウトが作成されます。
このエラー拡張ハンドラで、フォルト・メッセージが特別な内容に対応するようにエンリッチされます。その後、処理をさらに進行するためにエラー処理フレームワークに返されます。
「エラー通知」ページの詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のAIAエラー処理構成詳細の設定方法に関する項を参照してください。
$AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configのAIAConfigurationProperties.xmlファイルにアクセスします。図17-12に示すように、ステップ2で定義したエラー拡張ハンドラ名と一致するプロパティ名を定義します。このプロパティの値は、ハンドラの完全修飾クラスパスです。
図17-12 AIAConfigurationProperties.xmlのエラー拡張ハンドラ・プロパティと値の例
このクラスを介して、Meta.xsdのApplicationFaultData要素のxsd:anyTypeを使用して拡張機能(たとえば、オーダー番号および履行システムの値)がフォルト・メッセージに追加されます。
AIAConfigurationProperties.xmlに登録されたエラー拡張ハンドラ・クラスにIAIAErrorHandlerExtensionインタフェースを実装します。次のメソッドを実装します。
BPELシステム・エラーに対するhandleCompositeSystemError
BPELカスタム・エラーに対するhandleBusinessError
例17-16および例17-17に、インタフェース構造を示します。
Oracle Enterprise Managerでアクセスされたエラー・ログに拡張フィールド値を表示できます。
適切に構成されている場合は、電子メール通知に表示することもできます。
例17-16 IAIAErrorHandlerインタフェース・クラス
public interface IAIAErrorHandler
{
/**
*
* @param ebmHeader
* @param faultMessage
*/
public void logErrorMessage(Element ebmHeader, String faultMessage);
/**
*
* @param XMLELfaultMessage
*/
public void logErrorMessage(XMLElement XMLELfaultMessage);
/**
*
* @param ebmHeader
* @param faultMessage
*/
public void logErrorMessage(Node ebmHeader, String faultMessage);
/**
* @since FP 2.3
* @param faultMessage
* @param jmsCorrelationID
*/
public void sendNotification(String faultMessage, String jmsCorrelationID,
HashMap compositeDetailsHM);
}
例17-17 IAIAErrorHandlerExtensionインタフェース・クラス
package oracle.apps.aia.core.eh;
public interface IAIAErrorHandlerExtension
{
/**
*
* @param iFaultRecoveryContext
* @param faultMessageConstructed
* @param componentType
* @return
*/
public String handleCompositeSystemError(IFaultRecoveryContext iFaultRecoveryContext,
String faultMessageConstructed,
String componentType);
/**
*
* @param faultMessageConstructed
* @return
*/
public String handleBusinessError(String faultMessageConstructed);
}
この項には次のトピックが含まれます:
この項では、エラー処理拡張機能の概要を示し、エラー処理拡張機能の実装方法について説明します。
BPELおよびメディエータのエラーに対するデフォルトのエラー処理動作では、フォルト・メッセージはOracle AIA共通のエラー・ハンドラにルーティングされ、このエラー・ハンドラがエラーをログに記録し、フォルト・メッセージをOracle AIAエラー・トピックに配信します。デフォルトのOracle AIAエラー・リスナーは、このOracle AIAエラー・トピックをサブスクライブし、フォルト・メッセージを選択してエラー通知プロセスをコールし、そのエラー通知プロセスがOracle BPM Worklistに通知を発行します(発行するように構成されている場合)。
エラー処理フレームワークを拡張して、そのデフォルトの動作を超えるアクションを実行できます。
たとえば、表の更新やアプリケーションでの新規リクエストの作成などの拡張されたエラー処理動作に加え、特定のエラーにはデフォルトのエラー処理動作をトリガーする必要があります。
エラー処理拡張機能を実装するには、フォルト・メッセージを拡張して追加の値を用意します。
フォルト・メッセージの拡張の詳細は、「フォルト・メッセージの拡張」を参照してください。
エラー処理の拡張機能を実装する手順は、次のとおりです。
「エラー通知」ページで、エラー・コード、システム・コード、プロセス名およびサービス名の値を組み合せて「エラー・タイプ」フィールドに値を入力します。
エラー処理フレームワークでは、「エラー・タイプ」の値を使用してJMSCorrelationID JMSヘッダーにスタンプを付けます。JMSCorrelationIDは、カスタム・エラー処理が必要なフォルト・メッセージを識別するためにカスタム・エラー・リスナーによって使用されます。
Oracle AIAエラー・トピックをサブスクライブするエラー拡張リスナーを実装します。
ステップ1で作成したエラー・タイプによって定義されたJMSヘッダーのJMSCorrelationID値に基づいて、フォルト・メッセージをフィルタ処理するエラー拡張リスナーを構成します。
たとえば、ORDER_FOというJMSCorrelationID値を使用してフォルト・メッセージを選択するオーダー・フォールアウト・エラー拡張リスナーを作成できます。この例では、ステップ1の「エラー通知」ページで定義した「エラー・タイプ」フィールドの値がORDER_FOです。
次に、オーダー・フォールアウト・エラー拡張リスナーは、たとえば、オーダー番号および履行システムの値が含まれるように拡張されたフォルト・メッセージから値を抽出できます。その後、エラー拡張リスナーは、たとえば、オーダー・フォールアウト管理アプリケーションにその値を渡し、アプリケーションがその値を使用してオーダー表を更新し、新規サービス・リクエストを作成できます。
図17-13に、拡張エラー処理フローを示します。
図17-13 拡張エラー処理フローとデフォルトのエラー処理フローのサンプル
この項には次のトピックが含まれます:
次のカスタムXPathトレース・ロギング関数は、Oracle AIAエコシステムで機能しているBPELおよびメディエータ・サービスの操作に使用できます。
aia:isTraceLoggingEnabled(String logLevel, String processName)
トレース・ロギングがサービスに対して有効か、システム・レベル全体で有効かを決定します。
aia:logTraceMessage(String level, Element ebmHeader, String message)
実際のトレース・ログを生成します。
BPELまたはメディエータ・プロセスの開発時には、常にaia:isTraceLoggingEnabled()関数を最初にコールします。trueの結果が返された場合に、aia:logTraceMessage()関数をコールします。
これらのログ・ファイルは、<aia.home>/logs/ディレクトリに保存されます。
アプリケーション開発者がトレース・メッセージをログに記録できるように、これらのカスタムXPath関数に加え、Java APIも使用できます。
トレース・ログの使用の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のトレースおよびエラー・ログの使用に関する項を参照してください。
isLoggingEnabledカスタムXPath関数は、ブール値の結果を返すユーティリティ関数です。関数シグネチャは、aia:isTraceLoggingEnabled (String logLevel, String processName)です。
パラメータの詳細を示します。
logLevel
可能な値は次のとおりです。
Severe
Warning
Info
Config
Fine
Finer
Finest
processName
この関数を使用するOracle AIAサービスの名前。
logTraceMessageカスタムXPath関数は、トレース・ログに含めるメッセージの詳細が格納されたトレース・メッセージを生成します。
この関数は、EBMヘッダーおよび冗長なロギング・メッセージをパラメータとして受け入れます。EBMヘッダーから様々な要素を使用してログ・メッセージに追加属性の値が入力されます。EBMヘッダーが渡されなかった場合、これらの追加属性は空の文字列として設定されます。
関数シグネチャはaia:logTraceMessage (String level, Element ebmHeader, String message)です。パラメータの詳細を示します。
level
可能な値は次のとおりです。
Severe
Warning
Info
Config
Fine
Finer
Finest
ebmHeader
EBMヘッダー。
message
ログに記録する冗長なテキスト・メッセージ。
アプリケーション開発者がトレース・メッセージをログに記録できるように、isTraceLoggingEnabledおよびlogTraceMessageカスタムXPath関数に加え、トレース・ロギングJava APIも使用できます。これらの関数は、トレース・ロギングJava APIを介して使用できます。
関数シグネチャの1つとして、AIALogger.isTraceLoggingEnabled (String logLevel, String processName)があります。この関数は、トレース・ロギングがサービスに対して有効か、システム・レベル全体で有効かを決定します。パラメータの詳細を示します。
logLevel
可能な値は次のとおりです。
Severe
Warning
Info
Config
Fine
Finer
Finest
processName
この関数を使用するOracle AIAサービスの名前。
もう1つの関数シグネチャは、AIALogger.logTraceMessage (String level, Element ebmHeader, String message)です。この関数は実際のトレース・ログを生成します。パラメータの詳細を示します。
level
可能な値は次のとおりです。
Severe
Warning
Info
Config
Fine
Finer
Finest
ebmHeader
EBMヘッダー。
message
ログに記録する冗長なテキスト・メッセージ。
