ブローカーは、すべてのメッセージ・フローについて基本的なエラー処理を行います。 基本処理が十分でない場合や、特定のエラー条件やエラー状態に対して特定のアクションを実行したい場合には、メッセージ・フローを拡張して独自のエラー処理を実行することもできます。
そのために使用できるオプションは、場合によっては非常に複雑になります。 特に MQInput ノードのために用意されているオプションは多岐にわたります。それらのノードは、持続メッセージやトランザクションも対象にしているからです。MQInput は、WebSphere MQ の構成オプションの影響も受けます。
どんなエラーについても処理の方法はいろいろあるので、決まった手順をここで取り上げることはできません。 ここでは、エラー処理の原則を示し、使用可能なオプションについて説明します。その詳細情報を参考にしながら、それぞれの状況で必要な選択肢を組み合わせて活用するようにしてください。
メッセージ・フロー内で、これらのオプションのうちの 1 つまたは複数を選択できます。
ユーザー定義のノードをメッセージ・フローに組み込む場合、そのノードに関するエラーを処理する方法を理解するには、そのノードに関して提供されている情報を参照する必要があります。 ここでは、組み込みノードだけを取り上げます。
エラー処理の方法を設計する場合、以下の要因について検討してください。
例外がノード内で検出されると、メッセージと例外の情報がノードの failure ターミナルに伝搬されます。 ノードに failure ターミナルが含まれていない場合や、ノードが failure ターミナルに接続していない場合は、ブローカーが例外をスローし、その例外を処理できる入力ノードに制御を戻します。
MQinput ノードが内部エラーを検出した場合の動作は多少異なります。failure ターミナルに接続していない場合、それぞれのノードは、入力キューのバックアウト再キューイング・キューか、そのキューが定義されていない場合はブローカーのキュー・マネージャーの送達不能キューにメッセージを書き込もうとします。
メッセージが catch ターミナルに伝搬されるのは、メッセージが最初にその種のノードの先 (out ターミナルに接続しているノードなど) に伝搬された場合に限られます。
エラー処理の一般的な原則は以下のとおりです。
メッセージがトランザクションの一部になっている場合、例外が MQInput ノードまたは ノードの先 (out フローか catch フロー) で生成されて、メッセージが入力キューに戻ったときに、バックアウト・カウントがバックアウトしきい値に達すると、やはり fail フローが呼び出されます。
SCADAInput ノードは、catch ターミナルに接続していない状況で例外がそのノードの先で生成されたときに、メッセージを failure ターミナルに伝搬しません。
Error Handler サンプルは、エラー処理ルーチンを使用してエラーについての情報をトラップし、その情報をデータベースに保管する方法を示しています。エラー処理ルーチンは、任意のメッセージ・フローに未変更のまま追加できるサブフローです。このサンプルは、メッセージ・フローを構成してトランザクション特性を制御する方法をも示しています。特に、全体的なデータ保全性を確保するためにグローバルに整合されたトランザクションの使用法を示しています。