12 エラー処理

この章では、エラー状態を解釈し、Oracle Enterprise Service Busで処理する方法について説明します。Oracle ESB Controlの「インスタンス」ビューを使用すると、Enterprise Service Bus内で発生したエラー状態を表示および管理できます。

項目は次のとおりです。

エラー処理の概要
エラー状態の管理
ESBエラー処理の機能強化

エラー状態の詳細は、Oracle Enterprise Managerでログ・ファイルを表示して確認することもできます。「ログ・ファイルの確認」を参照してください。

エラー処理の概要

Oracle Enterprise Service Busでの処理中に発生したエラーは、Oracle ESB Controlでは、アイコンや色の変化などの視覚的な方法で表現されます。図10-4、図10-5および図10-6を参照してください。電子メール、FAXまたは電話によるエラーの発生通知を設定することもできます。「通知チャネルの設定」を参照してください。

Oracle Enterprise Service Busでのエラー処理は、トランザクション処理で発生する可能性があるいくつかのタイプのエラーに関連しています。

アプリケーション・フォルトまたはビジネス・フォルト
再試行可能な例外: 通常は比較的短時間で解決するが、メッセージのルーティングに影響を与える一時的なサービスの損失
致命的な例外: 使用不可もしくは削除されたサービスやシステム、メモリー不足の状態、またはシステム管理者による手当てを必要とする重大なエラーの原因となるその他の深刻な問題

エラー処理では、ルーティング・サービスに指定した実行が非同期か、同期かによって処理方法が異なります。同期実行で発生したエラーはロールバックされ、Oracle ESB Controlでは再試行できません。一方、非同期実行で発生したエラーは再送信できます。非同期および同期での実行の詳細は、「同期または非同期実行の指定」を参照してください。

同期実行の場合は、トランザクションがロールバックされ、エラー通知はその処理を開始したアダプタに戻されます。エラーおよび再送信を処理するには、呼出しアダプタが必要です。「インバウンド・アダプタのエラー処理」を参照してください。
非同期実行の場合、ユーザーは、エラー状態の解決後にトランザクションを再送信できます。「ユーザーによるエラー処理」を参照してください。

エラー状態の管理

この項では、Oracle Enterprise Service Busで発生したエラー状態を管理する方法について説明します。

項目は次のとおりです。

インバウンド・アダプタのエラー処理
ユーザーによるエラー処理
エラーに関するメッセージの再送信

インバウンド・アダプタのエラー処理

インバウンド・アダプタでは、アダプタのデフォルトのエラー処理プロセスを使用して例外およびフォルトを処理します。

デフォルトでは、アダプタは、1つのエラー状態について、3回のメッセージを5秒間隔で再試行します。再試行の回数と間隔は、アダプタ・サービスのエンドポイント・プロパティで指定できます。エンドポイント・プロパティについては、「エンドポイント・プロパティの使用」を参照してください。
インバウンド・アダプタが、ある特定期間の間に連続してルーティング・サービスの呼出しに失敗した場合は、そのインバウンド・アダプタ自体に破損というマークが付けられて無効となります。Oracle ESB Controlでは、このイベント・ソースが使用不可の状態であることを視覚的に表すために、特別なアイコンが表示されます。このアダプタ・サービスは有効にできます。
インバウンド・アダプタが呼び出す次のサービスが、削除または無効のために存在しない場合、インバウンド・アダプタ・プロセッサは自身を無効にして破損のマークを付けます。
サブスクリプションがある特定期間の間に連続して失敗した場合、サービスは、そのサブスクリプションに破損状態のマークを付けるようにリポジトリに通知します。ディスパッチャは、この破損のマークが付けられた後のサブスクリプションをディスパッチしません。

無効なサービスはすべて管理者に通知されます。

エラー管理の説明も含めたアダプタの詳細は、『Oracle Application Server Adapter概要』を参照してください。

ユーザーによるエラー処理

メッセージ・インスタンスの処理中に発生したエラーは、Oracle ESB Controlの「インスタンス」ビューにある「トラッキング」タブに、赤色のサービス・アイコンで示されます。

「トラッキング」タブのエラー状態は、図12-1のように表示されます。

図12-1 「インスタンス」ビュー – 「トラッキング」タブ

「図12-1 「インスタンス」ビュー – 「トラッキング」タブ」の説明

図12-3に示すように、「エラー」タブの「メッセージ」列にあるエラーの詳細アイコンをクリックすると、エラー・メッセージ、トレース、ペイロードの詳細を表示できます。

図12-2は、「エラーの詳細」ダイアログの例です。

図12-2 「エラーの詳細」ダイアログ

「図12-2 「エラーの詳細」ダイアログ」の説明

エラーの詳細を確認してエラー状態を修正した後は、このメッセージを呼出しサービスに再送信できます。

実行時におけるペイロードの検証の有効化については、「サービス定義の表示」の表3-6を参照してください。

エラーに関するメッセージの再送信

状況によっては、メッセージ・インスタンスの再送信が可能です。ルーティング・ルールが非同期実行に設定されている場合は、通常、エラー状態を修正した後で、メッセージ・インスタンスを再送信できます。

エラーに関するメッセージを再送信する手順は、次のとおりです。

メッセージ・インスタンス処理を表示するには、Oracle ESB Controlの上部の「インスタンス」アイコンをクリックします。
「インスタンス」ビューの「インスタンス」パネルで、エラーが発生したメッセージ・インスタンスをクリックします。
「エラー」タブをクリックして、エラー情報を表示します。
「メッセージ」列の下にある「エラーの詳細」アイコンをクリックし、「エラーの詳細」ダイアログに、エラー状態に関するエラー・メッセージ、トレースおよびペイロードの詳細を表示します。
エラー・メッセージの詳細を確認した後は、「OK」をクリックして「エラーの詳細」ダイアログを閉じます。
「エラー」タブで、エラー状態を修正して「再送信」をクリックします。

たとえば、メッセージ・ペイロードが不適切な場合は、「再送信ペイロード」ウィンドウでそのメッセージ・ペイロードを編集し、「再送信」をクリックします。

図12-3は、再送信されたメッセージ・インスタンスの例です。

図12-3 「インスタンス」ビュー - 「エラー」タブ

「図12-3 「インスタンス」ビュー - 「エラー」タブ」の説明

ESBエラー処理の機能強化

Oracle Application Serverリリース10.1.3.4では、ESBエラー処理のサポートが強化されています。ESBのエラー動作は次のようなシナリオで説明できます。

Third-party Adapter --> Routing Service --> AQ Outbound Adapter

リリース10.1.3.4では、ESBエラー処理が次のように機能強化されています。

サード・パーティ・アダプタ用カスタム拒否ハンドラ
インバウンド・アダプタの停止
ERROR_TOPICの情報の拡張
リバース制御
主キー
拒否時におけるキューからのメッセージの削除

サード・パーティ・アダプタ用カスタム拒否ハンドラ

SAPアダプタなどのサード・パーティ・アダプタは、カスタム拒否ハンドラをサポートしていません。しかし、リリース10.1.3.4では、ESBからカスタム拒否ハンドラを起動できます。SupportCustomRejectionForThirdPartyAdaptorエンドポイント・プロパティをtrueに設定する必要があります。ESBはこのプロパティをサード・パーティ・アダプタとして識別し、onReject関数をコールします。

この機能に使用されるプロパティ名と説明は次のとおりです。

プロパティ名: SupportCustomRejectionForThirdPartyAdaptor

説明: trueはサード・パーティ用カスタム拒否ハンドラの起動を示します。

インバウンド・アダプタの停止

ESBがERROR_TOPIC上にメッセージをポストできないときにはいつでも、インバウンド・アダプタを停止してエラー・メッセージがそれ以上失われないようにする必要があります。これはshutdownInboundAdaptorOnErrorエンドポイント・プロパティをtrueに設定することで実行できます。このプロパティは、同期ESBサービスに対して、ERROR_TOPIC AQJMSトピック上のメッセージがインバウンド・サービスからポストされる場合にのみ使用できます。デフォルトでは、ERROR_TOPIC AQJMSトピックのメッセージはエラーが発生したサービスでエンキューされます。ERROR_TOPICのメッセージがインバウンド・サービスからエンキューされるようにするには、ESB_config.iniファイル内でEnqueueErrorFromInboundをtrueに設定する必要があります。

表12-1は、この機能用に構成する必要のあるプロパティを要約しています。

表12-1 インバウンド・アダプタの停止用に設定するプロパティ

プロパティ名	説明
`shutdownInboundAdaptorOnError`	このプロパティの値が`true`の場合は、現行ノードのみでのアダプタの停止を示します。`EnqueueErrorFromInbound`が`false`の場合、アダプタは停止しません。
`EnqueueErrorFromInbound`	このプロパティの値が`true`の場合、エラーはインバウンド・サービスから`ERROR_TOPIC`上にエンキューされ、そのときにのみ`ERROR_TOPIC`に`INBOUND_ADAPTOR_ID`を設定できます。その結果、インバウンド・アダプタが停止します。

ERROR_TOPICの情報の拡張

ERROR_TOPIC AQJMSトピックには、インバウンド・アダプタID（INBOUND_ADAPTOR_ID）やアウトバウンド・アダプタID（OUTBOUND_ADAPTOR_ID）などの追加情報が含まれます。

リバース制御

リバース制御メカニズムは、クラスタ内のすべてのインバウンド・アダプタが停止し、また、ステータスがコンソール上で更新されるというシナリオで役立ちます。リバース制御メカニズムは、デザインタイムがランタイムによって通知される状況で使用できます。ランタイムはサービスのステータスを更新し、すべてのランタイム・サービスに状態の変更について通知します。それにより、すべてのランタイム・サービスがインバウンド・アダプタを停止します。この停止は、disable_service_on_all_nodesエンドポイント・プロパティがESB_config.iniファイル内でtrueに設定されている場合にのみ発生します。

リバース制御メカニズムは、shutdownInboundAdaptorOnErrorとともに使用します。つまり、ERROR_TOPICへのメッセージのポストが失敗するとインバウンド・アダプタは停止し、残りのノードを停止するようにシステムが構成されている場合にリバース制御が起動します。

プロパティ名: disable_service_on_all_nodes

説明: disable_service_on_all_nodes=trueの場合、前述の使用例がサポートされます。falseに設定されている場合、現行ノードのアダプタが停止するのみで、コンソール上のステータスは更新されません。

主キー

すべてのテクノロジ・アダプタは、メッセージを識別する一意キーを備えています。ESBではこの一意キーを主キーとして使用し、メッセージの拒否までに再試行された回数を判断します。サード・パーティ・アダプタではこの一意キーを備えていないため、メッセージは拒否されることがなく、常に再試行のためアダプタに送信されます。ESBにはPrimaryKeyエンドポイント・プロパティがありますが、これはペイロードからのXPATHです。これによりこのXPATHを使用してメッセージを関連付けでき、その後メッセージは再試行され最終的に拒否されます。

主キー定義のサンプルは次のとおりです。

ペイロードXMLサンプル:

<ns1:userDetail xmlns:ns1="http://www.example.org">
             <ns1:key>41</ns1:key>
             <ns1:value>11</ns1:value>
             </ns1:userDetail>
PrimaryKey={/imp1:userDetail/imp1:key};{namespace imp1=http://www.example.org}

プロパティ名: PrimaryKey

説明: PrimaryKeyエンドポイント・プロパティがサード・パーティ・アダプタに設定されていない場合、常にRetriableExceptionエラーが発生し、アダプタに同じメッセージの再試行をリクエストします。このように、カスタム拒否ハンドラはコールされません。XPATHを持つ主キーがNULLを返す場合、メッセージは再試行されず、処理中の最初の失敗の後に拒否されます。

拒否時におけるキューからのメッセージの削除

テクノロジ・アダプタであるAQアダプタは、RejectionExceptionエラーを受信するとメッセージを主キューから削除し、独自のエラー・キューに配置します。このように、メッセージが再びESBに戻されることはありません。一方、SAPアダプタなどのサード・パーティ・アダプタには、この組込みメカニズムはありません。メッセージは永遠に主キューに残ります。また、SAPアダプタはグローバル・トランザクションに関係していません。NotifyThirdPartyAdaptorエンドポイント・プロパティをfalseに設定すると、ESBはローカル・トランザクションをロールバックし拒否ハンドラを起動しますが、SAPアダプタに例外を返しません。SAPアダプタはそのトランザクションをコミットし、メッセージはキューから削除されます。

プロパティ名: NotifyThirdPartyAdaptor

説明: False値は、サード・パーティ・アダプタに例外をバブル・バックしないことを表します。ESBはSAPアダプタに例外をスローせず、値をSAPアダプタから選択します。サード・パーティ・アダプタの場合、PrimaryKeyエンドポイント・アダプタを設定しないと、ESBが常にアダプタに再試行の通知を送信することになります。

表12-2は、プロパティの関連表と、表で示す順序でプロパティを設定した場合に発生するアクションの詳細な説明を示しています。

表12-2 プロパティの関連表

SL. 番号	Enqueue Error From Inbound	disable _service _on _all_ nodes	shutdown Inbound Adaptor On Error	Support Custom Rejection ForThird Party Adaptor	Notify Third Party Adaptor	Primary Key	説明
1.	true	true	true	true	false	XPATHがNOT NULL値	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンしている場合、インバウンド・アダプタはすべてのノードで無効となり、コンソール上でステータスを更新します。 3. その他の場合、パラメータ設定に基づいてインバウンドとアウトバウンドでメッセージを再試行します。 4. カスタム拒否ハンドラは、インバウンド再試行回数に達した後にコールされます。 5. SAPアダプタからメッセージを選択します。
2.	true	true	true	true	false	エンドポイント・プロパティは設定されているがXPATHはNULL値	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンの場合、インバウンド・アダプタはすべてのノードで無効となり、コンソール上でステータスを更新します。 3. その他の場合、インバウンド・サービス・レイヤーでメッセージを再試行せず、アウトバウンド・レイヤーでのみ`RetryCount`を検討します。 4. カスタム拒否ハンドラをコールします。 5. SAPアダプタからメッセージを選択します。
3.	true	true	true	true	false	エンドポイント・プロパティが未設定	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンしている場合、インバウンド・アダプタはすべてのノードで無効となり、コンソール上でステータスを更新します。 3. その他の場合、主キーが設定されておらずSAPアダプタに対してもNULLのため、ESBは再試行を繰り返します。 4. カスタム拒否ハンドラをコールしません。 5. SAPアダプタからメッセージを選択しません。
4.	false	true	true	true	false	XPATHがNOT NULL値	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンしている場合、インバウンド・アダプタは現行ノードで無効となりません。残りのノードも同様です。 3. その他の場合、パラメータ設定に基づいてインバウンドとアウトバウンドでメッセージを再試行します。 4. カスタム拒否ハンドラは、インバウンド再試行回数に達した後にコールされます。 5. SAPアダプタからメッセージを選択します。
5.	true	false	true	true	false	XPATHがNOT NULL値	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンしている場合、インバウンド・アダプタは現行ノードでのみ無効となり、残りの稼動ノードでは無効になりません。コンソール上でステータスを更新しません。 3. その他の場合、パラメータ設定に基づいてインバウンドとアウトバウンド上でメッセージを再試行します。 4. カスタム拒否ハンドラは、インバウンド再試行回数に達した後にコールされます。 5. SAPアダプタからメッセージを選択します。
6.	true	true	false	true	false	XPATHがNOT NULL値	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンしている場合、インバウンド・アダプタは現行ノードで無効となりません。残りのノードも同様です。 3. その他の場合、パラメータ設定に基づいてインバウンドとアウトバウンドでメッセージを再試行します。 4. カスタム拒否ハンドラは、インバウンド再試行回数に達した後にコールされます。 5. SAPアダプタからメッセージを選択します。
7.	true	true	true	false	false	XPATHがNOT NULL値	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンしている場合、インバウンド・アダプタはすべてのノードで無効となり、コンソール上でステータスを更新します。 3. その他の場合、パラメータ設定に基づいてインバウンドとアウトバウンドでメッセージを再試行します。 4. カスタム拒否ハンドラは、インバウンド再試行回数に達した後もサード・パーティ・アダプタ用にコールされません。 5. SAPアダプタからメッセージを選択します。
8.	true	true	true	true	true	XPATHがNOT NULL値	1. ESBインフラがアップしている場合は、ERROR_TOPICにインバウンド・アダプタIDを設定します。ERROR_TOPICにメッセージを配置します。 2. ESBインフラがダウンしている場合、インバウンド・アダプタはすべてのノードで無効となり、コンソール上でステータスを更新します。 3. その他の場合、パラメータ設定に基づいてインバウンドとアウトバウンドでメッセージを再試行します。 4. カスタム拒否ハンドラは、インバウンド再試行回数に達した後にコールされます。 5. 例外がアダプタにバブル・バックされるため、メッセージはSAPアダプタから選択されません。