例外が入力ノードに戻される前に、メッセージ・フローで例外をキャッチするための設計を行えます。 一連のノードのための Single Point of Failure 機能を備えるために、フローの中に 1 つ以上の TryCatch ノードを組み込むことができます。 この技法によって、非常に具体的なエラー処理とリカバリーが可能になります。
TryCatch ノードは、メッセージ・フローの中である種の判断を行うポイントになるだけで、実際のメッセージ処理は行いません。 TryCatch ノードはメッセージを受信すると、そのメッセージを Try ターミナルへ伝搬します。 ブローカーは、そのターミナルに接続している一連のノード (try フロー) に制御を渡します。
例外が try フローで生成されると、ブローカーは制御を TryCatch ノードに戻します。 このノードは、例外リスト・ツリーの現行内容をローカル・エラー・ログに書き込み、現行例外に関する情報を例外リスト・ツリーに書き込みます (保管されている情報に上書きします)。
このノードは、Catch ターミナルに接続している一連のノード (catch フロー) にそのメッセージを伝搬します。 ここで伝搬されるメッセージ・ツリーの内容は、Try ターミナルに伝搬された内容、つまり TryCatch ノードが最初に受け取った時のツリーの内容と同一です。 このノードは、例外リスト・ツリーに書き込んだ新しい例外情報でメッセージ・ツリーを更新します。 try フローにある各ノードがメッセージ・ツリーに対して行った変更や追加は、catch フローに伝搬されるメッセージ・ツリーには反映されません。
ただし、try フローが外部データベースの更新を含む処理を完了した場合、これらの更新は失われません。catch フローによってメッセージが処理されている間、更新はそのまま保持され、更新をコミットするかロールバックするかの決定が、メッセージ・フローの構成内容と、対象データベースと対話する個々のノードの構成内容に基づいて行われます。 設定した構成内容に基づいて更新がコミットされる場合は、行われた変更をロールバックするためのロジックを catch フロー内に組み込む必要があります。
構成オプションを確認するには、メッセージ・フローのトランザクション特性の構成を参照してください。
ブローカーがメッセージ・フロー内の次のキャッチ・ポイント (別の TryCatch ノードの場合もありますが、最後のノードの場合は常に入力ノードになります) に制御を戻すのは、以下のいずれかの条件が真の場合です。
以下の例では、入力ノードで例外をキャッチするためのフロー構成の方法を示します。 まず、MQInput ノードの Catch ターミナルを、エラーを記録するための Trace ノードに接続します。
以下の例では、メッセージ・フローの中に 2 つの処理フローがあります。 つまり、Filter ノードの True ターミナルに接続されている処理フローと、False ターミナルに接続されている処理フローです。 ここでは、メッセージの 2 つの経路にそれぞれ TryCatch ノードを組み込みます。 そして、両方の TryCatch ノードの Catch ターミナルを共通のエラー処理サブフローに接続します。
メッセージ・フロー内の入力ノードに Catch ターミナルがない場合に、そのフロー内でエラーを処理するには、TryCatch ノードを組み込む必要があります。