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

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

このタスクの概要

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

そのために使用できるオプションは、場合によっては非常に複雑になります。 MQ 入力 および タイムアウト通知 ノードに用意されているオプションは、永続メッセージおよびトランザクションを扱うノードであるため、広範囲に及びます。 MQ 入力 ノードは、 WebSphere® MQの構成オプションの影響も受けます。

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

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

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

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

  • 例外のキャッチ

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

    メッセージ・フローに トリキャッチ ノードを組み込むことによって、トランザクションがロールバックされないようにしたり、メッセージ変更がどの程度反転されるかを制御したりすることができます。 トリキャッチ ノードの Try ターミナルを超えて例外がスローされると、例外リストがノードの Catch ターミナルに伝搬されます。 処理中のメッセージは、 トリキャッチ ノードに到達する前の状態に戻ります。

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

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

  • ノードの Failure ターミナルと、ノードの内部例外を処理するノード・シーケンス (fail フロー) を接続します。
  • ノードの Catch ターミナルと、それらのノードの先で生成される例外を処理するノード・シーケンス (catch フロー) を接続します。
  • 1 つ以上の トリキャッチ ノードをメッセージ・フロー内の特定のポイントに挿入して、Try ターミナルに接続されたフローによって生成された例外をキャッチして処理します。
  • 例外を生成するには、 スロー ノードを組み込むか、ESQL THROW ステートメントをコーディングします。
  • MQ 入力 ノードによって受信されたすべてのメッセージがトランザクションで処理されるか、またはトランザクションで処理されないことを確認してください。
  • MQ 入力 ノードによって受信されるすべてのメッセージが永続的であるか、または永続的でないことを確認してください。

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

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

  • 大半の組み込みノードには Failure ターミナルが含まれています。 例外は、 集計コントロール、 要求の集約、 入力、 表示名、 出力、 パススルー、 資料、 トレース、および トリキャッチ の各ノードです。

    例外がノード内で検出されると、メッセージと例外の情報がノードの Failure ターミナルに伝搬されます。 ノードに failure ターミナルが含まれていない場合や、ノードが Failure ターミナルに接続していない場合は、統合ノードが例外をスローし、その例外を処理できる直近のアップストリーム・ノードに制御を戻します。 このノードは、 トリキャッチ ノード、 応答の集約 ノード、または入力ノードのいずれかです。

    MQ 入力 ノードが内部エラーを検出した場合、その動作は若干異なります。 Failure ターミナルが接続されていない場合、 MQ 入力 ノードは、入力キューのバックアウト・キューにメッセージを書き込もうとします。このキューが定義されていない場合は、統合ノードに関連付けられているキュー・マネージャーの送達不能キューにメッセージを書き込もうとします。

    詳しくは、 MQInput ノードのエラーの処理を参照してください。

  • 多くの組み込みノードには、Catch ターミナルがあります。 通常、これらのノードはトランザクションの始めに配置されます。 以下に例を示します。
    • 入力ノード: ファイル入力、 HTTP 入力、 JMS 入力、 MQ 入力、 PeopleSoft 入力、 SAP 入力、 SCA 入力, ジーベル入力、 SOAP 入力、 TCPIPClientInput、 TCPIP サーバー入力
    • 出力ノードと応答ノード: SCAA同期応答, SOAPAsync応答
    • ルーティング・ノード: 応答の集約, コレクター, リシーケンス
    • 構築ノード: トリキャッチ
    • タイマー・ノード: タイムアウト通知

    メッセージが Catch ターミナルに伝搬されるのは、メッセージが最初にその種のノードの先 (Out ターミナルに接続しているノードなど) に伝搬された場合に限られます。

  • メッセージが Failure ターミナルまたは Catch ターミナルに伝搬されると、ノードは新規の例外リストを作成し、発生したエラーを表す例外がそのリストに取り込まれます。 例外リストはメッセージ・ツリーの一部として伝搬されます。 Out フローまたは Catch フローで発生した問題 (例えば、構文解析エラーの繰り返しによりバックアウトしきい値が満たされた場合) が原因でメッセージが Failure ターミナルに伝搬されると、元の構文解析エラーは例外リスト中に含まれません。例外リストには、バックアウトしきい値が満たされたことを示す例外が含まれます。
  • MQ 入力 および タイムアウト通知 ノードには、トランザクション・メッセージの追加処理があります (他の入力ノードはトランザクション・メッセージを処理しません)。

    詳しくは、 MQInput ノードのエラーの処理 および タイムアウト通知エラーの処理を参照してください。

  • 以下を指定する トレース ノードを組み込むとします。$RootOR$Body完全なメッセージが解析されます。 したがって、それ以外の場合には検出されないパーサー・エラーが生成される場合もあります。
エラー処理の一般的な原則は以下のとおりです。
  • 入力ノードの Catch ターミナルに接続した場合、フローは out フロー内で生成されるすべての例外を処理します。 catch フローで例外がない限り、統合ノードはトランザクションをロールバックしません。 catch フローが正常に完了すると、メッセージがコミットされます。 例外が発生してキャッチされた後にロールバックを実行したい場合は、その動作を catch フロー内で用意する必要があります。
  • 入力ノードの Catch ターミナルに接続しない場合は、Failure ターミナルに接続し、そのノードによって生成された例外を処理するための fail フローを用意できます。 fail フローは、ノード内で例外が発生した時点でただちに開始されます。

    例外がノードを超えて生成され、Catch ターミナルに接続していない場合、 HTTP 入力 ノードはメッセージを Failure ターミナルに伝搬しません。

  • ノードがメッセージを Catch フローに伝搬した後に、同じメッセージ・フロー・ノードに制御を戻す別の例外が再度発生した場合、そのノードは catch ターミナルに接続していない場合と同じようにしてメッセージを処理します。
  • 入力ノードの Failure ターミナルにも Catch ターミナルにも接続しない場合、統合ノードはデフォルトの処理を行います (デフォルトの処理は、入力ノードのタイプによって異なります)。
  • より包括的なエラーおよびリカバリー・アプローチが必要な場合は、1 つ以上の トリキャッチ ノードを組み込んで、よりローカライズされたエラー処理領域を提供します。
  • 特定のエラーを処理する共通のプロシージャーがある場合、必要なノード・シーケンスを組み込んだサブフローを作成するのが適している状況もあります。 そのアクションを実行しなければならない位置にそのサブフローを組み込んでください。
  • 入力ノードにセキュリティー処理を設定していて、セキュリティー例外がスローされた場合、 メッセージはメッセージ・フローに伝搬されません。 メッセージがバックアウトされるか、エラーが返されます。 詳しくは、 セキュリティー例外処理を参照してください。
  • 構文解析の例外は、Failure ターミナルに直接渡されます。 Failure ターミナルが接続されていない場合や、fail フローで例外が発生した場合は、メッセージはバックアウトされます。 fail フロー内のバックアウトは、バックアウトしきい値を、以前のように 2 回ではなく、1 回超えるまで続行されます。

詳しくは、 Failure ターミナルの接続、および TryCatch ノードでの例外のキャッチを参照してください。

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

  • 更新をコミットするのか、ロールバックするのかを指定できます。 ノード・プロパティー「トランザクション」を設定して、メッセージ・フローによってデータベース更新をコミットまたはロールバックするか (オプション「自動」)、ノードの終了時にコミットまたはロールバックするか (オプション「コミット」) を指定できます。 これらのプロパティー設定とメッセージ・フローのエラー処理の組み合わせによって、正しい結果が得られるかどうかを確かめる必要があります。
  • データベース・エラーの処理方法を指定できます。 プロパティー「警告をエラーとして扱う」および「データベース・エラーで例外をスローする」を設定して、データベース・エラー処理のデフォルト動作を変更します。

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

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