Error Handler サンプルは、トランザクションの処理が関係する業務において、エラーを処理するためのルーチンを開発する場合のシナリオに基づいています。このサンプルは、WebSphere Message Broker に含まれるいくつかの機能の使い方を示すものです。
銀行などにおける業務の場合、トランザクションの処理が必ず 1 度限りであり、すべてのエラーの記録が残るようにします。Error Handler サンプルでは、メッセージ・フローを使用してスタッフ番号に関するメッセージを書き込みます。そのメッセージ・フローでは、この情報でデータベースが更新されます。無効なスタッフ番号でメッセージに書き込むと、エラー処理ルーチンが機能する方法を観察できます。
Error Handler サンプルでは、以下のタスクを示します。
このサンプルでは、サンプルのメイン・メッセージ・フローがスタッフ番号に関する情報でデータベースを更新します。エラー処理サブフローでは、処理エラーが生じたあらゆるメッセージがキューに出力されます。メイン・フローでのデータベース更新はトランザクションの制御下で実行されるため、エラーが発生して、メッセージがエラー処理サブフローで処理されると、スタッフ番号に関するデータベース更新はロールバックされ、コミットされません。エラー・ハンドラー・サブフローでのキューの更新はトランザクションの制御下では実行されず、エラーに関する情報がロールバックされないようになっています。これは、エラーの記録を提供するためにその情報をコミットする必要があるためです。
Error Handler サンプルを実行するために、次の 2 つの入力メッセージが用意されています。
有効スタッフ・メッセージを以下の XML コードに示します。
<Staff> <StaffNumber>1</StaffNumber> <NameInfo> <LastName>Smith</LastName> <FirstName>Jack</FirstName> </NameInfo> </Staff>
無効スタッフ・メッセージを以下の XML コードに示します。
<Staff> <StaffNumber>99</StaffNumber> <NameInfo> <LastName>Doe</LastName> <FirstName>Jane</FirstName> </NameInfo> </Staff>
次の図は、メイン・メッセージ・フローを示しています。
次の図は、エラー処理サブフローを示しています。
下の表では、Error Handler サンプルで使用されるノードのタイプをリストしています。 Subflow ノードは、技術的にはノードではなく、ノード・パレットで使用することはできません。 つまり、Subflow ノードは単に、サブフロー Error_Handler.msgflow がメイン・メッセージ・フロー内で呼び出される場所を 表しているにすぎません。
ノード・タイプ | ノード名 |
---|---|
MQInput | STAFF_IN |
MQOutput | STAFF_FAIL、STAFF_OUT、STAFF_UPDATE_ERROR |
Compute | Copy Message、Create Message for Output |
Filter | Check Valid Staff Number、Check Backout Count |
Throw | Throw、Throw to Complete Rollback |
TryCatch | TryCatch |
Subflow | Error_Handler |
詳しくは、WebSphere Message Broker の資料で、ビルトイン・ノードおよびサブフローの使用を参照してください。
有効スタッフ・メッセージを入力キューに入れる場合、メッセージはノードを経由します。いずれかのキューが使用不可になっている場合には、メッセージはこのパスを通ることはできません。
無効スタッフ・メッセージを入力キューに入れる場合、メッセージはこのセクションの後半に説明されているノードを経由します。いずれかのキューが使用不可になっている場合には、メッセージはこのパスを通ることはできません。各ノードの働きの詳細については、WebSphere Message Broker の資料で、ビルトイン・ノードを参照してください。
TryCatch ノードを使用する場合、またはノードを MQInput ノードの Catch ターミナルに接続する場合、ノードが適切に構成されているのであれば、Catch パスが起動している場合に Try パス上で生じたすべての処理はコミットされないと想定するかもしれません。この想定は正しくありません。たとえば、トランザクション制御下でデータベースを Try パス上で更新し、Catch パスが起動して通常通りに完了する場合、データベースの更新はその後もコミットされます。
このサンプルにおける要件は、メッセージを読み取り、データベースを更新し、別のキューにそのメッセージを書き込むことです。エラーが発生すると、データベース更新はロールバックされます。捕捉処理によって、エラーの詳細でエラー・データベースが更新され、元のメッセージは障害の発生したキューに書き込まれます。プログラミングでは、次の例のようになります。
BEGIN (Start 'outer' unit-of-work.) MQGET (Get message from the input queue.) TRY BEGIN (Start 'inner' unit-of-work.) Update database MQPUT (Put message onto the output queue.) IF ERROR ROLLBACK inner unit-of-work GO TO CATCH ELSE COMMIT inner and outer unit-of-work as one unit-of-work END IF CATCH Send message to STAFF_UPDATE_ERROR queue MQPUT (Put message onto the failure queue.) COMMIT outer unit-of-work
しかし、XA Transaction Manager および WebSphere MQ は、同一アプリケーションでの 2 つのレベルの作業単位は サポートしていません。 したがって、Error Handler サンプルでは次の構造を使用します。
詳しくは、WebSphere Message Broker 資料のメッセージ・フロー・トランザクションを参照してください。