WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

メッセージ・フローのエラー処理

ブローカーは、すべてのメッセージ・フローについて基本的なエラー処理を行います。 基本処理が十分でない場合や、特定のエラー条件やエラー状態に対して特定のアクションを実行したい場合には、メッセージ・フローを拡張して独自のエラー処理を実行することもできます。

例えば、特定のエラーを予期したメッセージ・フローを設計し、そのエラーを特定の方法で処理する場合や、 フローによってデータベースを更新し、その他の処理が正常に完了しなかったときにはその更新をロールバックしなければならない場合があります。

そのために使用できるオプションは、場合によっては非常に複雑になります。 特に MQInputおよび TimeoutNotification ノードのために用意されているオプションは多岐にわたります。それらのノードは、持続メッセージやトランザクションも対象にしているからです。 MQInput ノードは、WebSphere® MQ の構成オプションの影響も受けます。

どんなエラーについても処理の方法はいろいろあるので、決まった手順をここで取り上げることはできません。 ここでは、エラー処理の原則を示し、使用可能なオプションについて説明します。その詳細情報を参考にしながら、それぞれの状況で必要な選択肢を組み合わせて活用するようにしてください。

メッセージ・フローでのエラーの処理方法には、一般的に以下の 2 つの手法があります。
  • 失敗の検査

    ノード内で発生する可能性のあるエラーを明示的に検査するために、そのノードの Failure ターミナルを接続します。 エラーが発生した場合、例外リストが Failure ターミナルに伝搬されます。 未完了メッセージは、ノードの起動前と同じになります。

    ESQL を使用することで、ノードにおけるカスタマイズ可能な、特殊なエラー検査を導入できます。 例えば、これらのノード内で出口ハンドラーを作成できます。 ESQL を使って出口ハンドラーを作成する方法について、詳しくはDECLARE HANDLER ステートメントを参照してください。

  • 例外のキャッチ

    Failure ターミナルを接続しない場合、ノード内の失敗が例外に変換されて、それがノードからスローされます。 例外がスローされる前に未完了メッセージに対して行われた変更内容は、すべて元に戻されます。 例外が原因で、現在のトランザクションがロールバックされる可能性があります (つまり、トランザクション・リソースの更新内容がすべて元に戻されます)。

    メッセージ・フローに TryCatch ノードを含めると、トランザクションのロールバックを防ぎ、メッセージ変更内容がどの程度元に戻されるかを制御することができます。 TryCatch ノードの Try ターミナルを超えて例外がスローされた場合、ノードの Catch ターミナルに例外リストが伝搬されます。 未完了メッセージは、TryCatch ノードに到着する前の状態に戻ります。

    TryCatch ノードを除く他のノードには Catch ターミナルがあります。 通常、これらのノードはトランザクションの始め (つまりキャッチされていない例外がロールバックを発生させる可能性がある場所) に配置されます。 これらのノードでは、TryCatch ノードが Out ターミナルに直接接続されているかのように、Catch ターミナルが動作します。 メッセージ・フローでノードを超えてスローされる例外を処理するには、Catch ターミナルを使用してください。 ノード自体の中でエラーを処理するには、Failure ターミナルを接続します。

メッセージ・フロー内で、これらのオプションのうちの 1 つまたは複数を選択できます。

ユーザー定義のノードをメッセージ・フローに組み込む場合、そのノードに関するエラーを処理する方法を理解するには、そのノードに関して提供されている情報を参照する必要があります。 ここでは、組み込みノードだけを取り上げます。

エラー処理の方法を設計する場合、以下の要因について検討してください。

エラー処理の一般的な原則は以下のとおりです。
  • 入力ノードの Catch ターミナルに接続した場合、フローは out フロー内で生成されるすべての例外を処理します。 ブローカーは、catch フローで例外があった場合を除いて、ロールバックやアクションを実行しません。 例外が発生してキャッチされた後にロールバックを実行したい場合は、その動作を catch フロー内で用意する必要があります。
  • 入力ノードの Catch ターミナルに接続しない場合は、Failure ターミナルに接続し、そのノードによって生成された例外を処理するための fail フローを用意できます。 fail フローは、ノード内で例外が発生した時点でただちに開始されます。

    メッセージがトランザクションの一部になっている場合、例外が MQInput ノードの先 (out フローか catch フロー) で生成されて、メッセージが入力キューに戻ったときに、バックアウト・カウントがバックアウトしきい値に達すると、やはり fail フローが呼び出されます。

    HTTPInput ノードは、Catch ターミナルに接続していない状況で例外がそのノードの先で生成されたときに、メッセージを Failure ターミナルに伝搬しません。

  • ノードがメッセージを Catch フローに伝搬した後に、同じノードに制御を戻す別の例外が再度発生した場合、そのノードは catch ターミナルに接続していない場合と同じようにしてメッセージを処理します。
  • 入力ノードの Failure ターミナルにも Catch ターミナルにも接続しない場合、ブローカーはデフォルトの処理を行います (デフォルトの処理は、入力ノードのタイプによって異なります)。
  • エラーとリカバリーに関するさらに包括的な方法が必要な場合は、より局所的なエラー処理を行うための TryCatch ノードを 1 つ以上組み込んでください。
  • 特定のエラーを処理する共通のプロシージャーがある場合、必要なノード・シーケンスを組み込んだサブフローを作成するのが適している状況もあります。 そのアクションを実行しなければならない位置にそのサブフローを組み込んでください。

詳しくは、failure ターミナルの接続入力ノードにあるエラーの管理、およびTryCatch ノードにおける例外のキャッチを参照してください。

メッセージ・フローにデータベース更新が含まれている場合、データベースと対話するノードの構成方法によって、エラー処理が影響を受けることもあります。

整合されたデータベースの更新についての詳細は、メッセージ・フローのトランザクション特性の構成を参照してください。

集約用のメッセージ・フローには、このトピックでは取り上げていない追加の要因があります。 集約用のメッセージ・フローの詳細は、集約フローでの例外の処理を参照してください。

次のサンプルは、エラー処理ルーチンを使用してエラーについての情報をトラップし、その情報をデータベースに保管する方法を示しています。 エラー処理ルーチンは、メッセージ・フローに未変更のまま追加できるサブフローです。 このサンプルは、メッセージ・フローを構成してトランザクション特性を制御する方法をも示しています。特に、全体的なデータ保全性を確保するためにグローバルに整合されたトランザクションの使用法を示しています。

サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:19


タスク・トピックタスク・トピック | バージョン 8.0.0.5 | ac00410_