ブローカーは、すべてのメッセージ・フローについて基本的なエラー処理を行います。 基本処理が十分でない場合や、特定のエラー条件やエラー状態に対して特定のアクションを実行したい場合には、メッセージ・フローを拡張して独自のエラー処理を実行することもできます。
例えば、特定のエラーを予期したメッセージ・フローを設計し、そのエラーを特定の方法で処理する場合や、 フローによってデータベースを更新し、その他の処理が正常に完了しなかったときにはその更新をロールバックしなければならない場合があります。
そのために使用できるオプションは、場合によっては非常に複雑になります。 特に MQInputおよび TimeoutNotification ノードのために用意されているオプションは多岐にわたります。それらのノードは、持続メッセージやトランザクションも対象にしているからです。 MQInput ノードは、WebSphere® MQ の構成オプションの影響も受けます。
どんなエラーについても処理の方法はいろいろあるので、決まった手順をここで取り上げることはできません。 ここでは、エラー処理の原則を示し、使用可能なオプションについて説明します。その詳細情報を参考にしながら、それぞれの状況で必要な選択肢を組み合わせて活用するようにしてください。
ノード内で発生する可能性のあるエラーを明示的に検査するために、そのノードの Failure ターミナルを接続します。 エラーが発生した場合、例外リストが Failure ターミナルに伝搬されます。 未完了メッセージは、ノードの起動前と同じになります。
ESQL を使用することで、ノードにおけるカスタマイズ可能な、特殊なエラー検査を導入できます。 例えば、これらのノード内で出口ハンドラーを作成できます。 ESQL を使って出口ハンドラーを作成する方法について、詳しくはDECLARE HANDLER ステートメントを参照してください。
Failure ターミナルを接続しない場合、ノード内の失敗が例外に変換されて、それがノードからスローされます。 例外がスローされる前に未完了メッセージに対して行われた変更内容は、すべて元に戻されます。 例外が原因で、現在のトランザクションがロールバックされる可能性があります (つまり、トランザクション・リソースの更新内容がすべて元に戻されます)。
メッセージ・フローに TryCatch ノードを含めると、トランザクションのロールバックを防ぎ、メッセージ変更内容がどの程度元に戻されるかを制御することができます。 TryCatch ノードの Try ターミナルを超えて例外がスローされた場合、ノードの Catch ターミナルに例外リストが伝搬されます。 未完了メッセージは、TryCatch ノードに到着する前の状態に戻ります。
TryCatch ノードを除く他のノードには Catch ターミナルがあります。 通常、これらのノードはトランザクションの始め (つまりキャッチされていない例外がロールバックを発生させる可能性がある場所) に配置されます。 これらのノードでは、TryCatch ノードが Out ターミナルに直接接続されているかのように、Catch ターミナルが動作します。 メッセージ・フローでノードを超えてスローされる例外を処理するには、Catch ターミナルを使用してください。 ノード自体の中でエラーを処理するには、Failure ターミナルを接続します。
メッセージ・フロー内で、これらのオプションのうちの 1 つまたは複数を選択できます。
ユーザー定義のノードをメッセージ・フローに組み込む場合、そのノードに関するエラーを処理する方法を理解するには、そのノードに関して提供されている情報を参照する必要があります。 ここでは、組み込みノードだけを取り上げます。
エラー処理の方法を設計する場合、以下の要因について検討してください。
例外がノード内で検出されると、メッセージと例外の情報がノードの Failure ターミナルに伝搬されます。 ノードに failure ターミナルが含まれていない場合や、ノードが Failure ターミナルに接続していない場合は、ブローカーが例外をスローし、その例外を処理できる直近のアップストリーム・ノードに制御を戻します。 このノードは TryCatch ノード、AggregateReply ノード、または入力ノードのいずれかの可能性があります。
MQInput ノードが内部エラーを検出した場合の動作は多少異なります。Failure ターミナルに接続していない場合、それぞれのノードは、入力キューのバックアウト再キューイング・キューか、そのキューが定義されていない場合はブローカーのキュー・マネージャーの送達不能キューにメッセージを書き込もうとします。
詳しくは、MQInput エラーの処理を参照してください。
メッセージが Catch ターミナルに伝搬されるのは、メッセージが最初にその種のノードの先 (Out ターミナルに接続しているノードなど) に伝搬された場合に限られます。
詳しくは、MQInput エラーの処理およびタイムアウト通知エラーの処理を参照してください。
メッセージがトランザクションの一部になっている場合、例外が MQInput ノードの先 (out フローか catch フロー) で生成されて、メッセージが入力キューに戻ったときに、バックアウト・カウントがバックアウトしきい値に達すると、やはり fail フローが呼び出されます。
HTTPInput ノードは、Catch ターミナルに接続していない状況で例外がそのノードの先で生成されたときに、メッセージを Failure ターミナルに伝搬しません。
詳しくは、failure ターミナルの接続、入力ノードにあるエラーの管理、およびTryCatch ノードにおける例外のキャッチを参照してください。
メッセージ・フローにデータベース更新が含まれている場合、データベースと対話するノードの構成方法によって、エラー処理が影響を受けることもあります。
整合されたデータベースの更新についての詳細は、メッセージ・フローのトランザクション特性の構成を参照してください。
集約用のメッセージ・フローには、このトピックでは取り上げていない追加の要因があります。 集約用のメッセージ・フローの詳細は、集約フローでの例外の処理を参照してください。
サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。