Business Process Choreographer は、一時的なインフラストラクチャー障害を処理するための機能を提供します。
このセクションでは、失敗したメッセージをビジネス・プロセス・コンテナーによって処理する仕組みを説明します。この仕組みは、ヒューマン・タスクでの失敗したメッセージ処理で説明するヒューマン・タスク・コンテナーによって使用される簡略化された仕組みとは対照的です。
長期実行プロセスは、一連のトランザクションで構成されています。 トランザクションは、Java Message Service (JMS) メッセージによって分離されます。 サーバーは、メッセージ駆動型 Bean に送信します。 この Bean の処理は、着信メッセージをプロセス・サーバーに受け渡すことによって行います。 それぞれのトランザクションは、以下のアクションで構成されています。
サーバーは、以下の理由のいずれかで、メッセージ駆動型 Bean が受信したメッセージの処理に失敗することがあります。
これらの原因に対する対応は、以下のとおりです。
原因 | 応答 |
---|---|
インフラストラクチャーが使用不可 | メッセージ駆動型 Bean は、指定した期間、この状態からのリカバリーを試行します。 この Bean は、サーバーが再び作動可能になるまで、すべてのメッセージを使用可能な状態に保持するように試行します。 例えばこの問題は、データベース障害によって発生している場合があります。 |
メッセージの破損 | 指定した回数の試行後、メッセージは保留キューに書き込まれます。 この保留キューで、メッセージの操作および検討を行います。 保留キューから入力キューに戻して、トランザクションを再試行することもできます。 |
ビジネス・プロセス用のメッセージのインプリメンテーションは以下のとおりです。
メッセージ駆動型 Bean が静止モードで作動している場合、この Bean は、定期的にメッセージの処理を試行します。 処理に失敗したメッセージは、配信回数を増加させたり、保存キューの巡回数を増加させたりすることなく、保留キューに書き戻されます。メッセージの処理を正常に行うことが可能になったら、即時にメッセージ駆動型 Bean は標準処理モードにスイッチバックします。
この機能は、2 つの数値限度、2 つのキュー、静止モード、およびメッセージ再試行の動作から構成されています。
再試行限度は、 保留キューに書き込む前に保存キューでメッセージを転送できる最大回数を定義しています。
保存キューに書き込まれるには、メッセージの処理が 3 回失敗する必要があります。
例えば、再試行限度が 5 である場合は、メッセージが保存キューを 5 回通過してから (3 * 5 = 15 回失敗してから) 最後の再試行ループが開始されます。最後の再試行ループでさらに 2 回失敗すると、メッセージは保留キューに入れられます。 つまり、メッセージは、(3 * RetryLimit) + 2 回失敗してから保留キューに入れられます。
信頼できるインフラストラクチャーで実行中の、 パフォーマンスが重要なアプリケーションでは、 再試行限度を少なく、例えば 1 または 2 にしておく必要があります。
管理コンソールでこのパラメーターを見つけるには、「ビジネス・プロセス・コンテナー」をクリックします。
をクリックします。次に、「ビジネス・プロセス・コンテナー設定 (Business Process Container Settings)」見出しで、保存キュー・メッセージ限度は、保存キューに入れることができるメッセージの最大数を定義します。保存キューがオーバーフローすると、システムは静止モードに入ります。 1 つのメッセージが失敗したら即時にシステムが静止モードに入るようにするには、 値をゼロに設定します。 ビジネス・プロセス・コンテナーのインフラストラクチャー障害に対する耐性を強化するには、値を増やします。
管理コンソールでこのパラメーターを見つけるには、「ビジネス・プロセス・コンテナー」をクリックします。
をクリックします。次に、「ビジネス・プロセス・コンテナー設定 (Business Process Container Settings)」見出しで、保存キューは、障害を起こしたメッセージを保存します。 これらは、ビジネス・プロセス・コンテナーの内部作業キューへ戻すことによって再生されます。 メッセージは、3 回失敗したら保存キューに書き込まれます。 メッセージが (3 * RetryLimit) + 2 回失敗した場合は、保留キューに書き込まれます。 (再試行限度について詳しくは、再試行限度を参照してください。) 保存キューが保存キュー・メッセージ限度で定義された限度に達してから別のメッセージが失敗すると、キューはオーバーフローし、システムは静止モードに入ります。 管理者は、失敗したメッセージの照会と再生のタスクを実行して、 このキュー内のメッセージを内部キューに戻すことができます。
保留キューには、 (3 * RetryLimit) + 2 回失敗したメッセージが含まれます。 (再試行限度について詳しくは、再試行限度を参照してください。) 管理者は、失敗したメッセージの照会と再生のタスクを実行して、 このキュー内のメッセージを内部キューに戻すことができます。
管理者は、 保留キューまたは保存キューから内部キューへメッセージを戻すことができます。 この操作は、管理コンソールか管理コマンドを使用して実行できます。
保存キューがオーバーフローすると、 静止モードに入ります。これが起こると、場合によっては一時的だが重大なインフラストラクチャー障害が発生したと想定されます。静止モードの目的は、システムが多数のリソースを使用しないようにすることですが、インフラストラクチャー障害は、ほとんどのメッセージがいずれにせよ失敗する可能性があることを意味します。静止モードでは、次のメッセージの処理を試行する前に 、2 秒間のシステム・スリープがあります。 メッセージが正常に処理されると即時に、システムは標準メッセージ処理を再開します。
(c) Copyright IBM Corporation 2005, 2006. All rights reserved.
(c) Copyright IBM Japan 2006
このインフォメーション・センターでは、Eclipse テクノロジー (http://www.eclipse.org) が採用されています。