長期実行プロセスは、複数のトランザクションにわたっています。Business Flow Manager には、 インフラストラクチャー障害が原因でトランザクションが失敗した場合に、 それらの障害から自動的に回復するための機能が用意されています。
長期実行プロセスの場合、Business Flow Manager は、 後続のナビゲーションを起動する要求メッセージを Business Flow Manager 自身に 送信します。要求メッセージが着信するごとに、 新しいトランザクションが開始され、要求メッセージが Business Flow Manager に 渡されて処理されます。それぞれのトランザクションは、以下のアクションで構成されています。
原因 | 応答 |
---|---|
インフラストラクチャーが使用不可 | 通常の処理モードでは、インフラストラクチャーが 再度作動可能になるまで、指定した期間にわたってすべてのメッセージが 有効な状態が維持されます。例えばこの問題は、データベース障害によって発生している場合があります。 |
メッセージの破損 | 指定した回数の試行後、メッセージは保留キューに書き込まれます。保留キューから入力キューに戻して、トランザクションを再試行することもできます。 |
インフラストラクチャーが使用不可であり、かつ保存キューがいっぱいである場合は、 メッセージ処理が通常の処理から静止モード に切り替わります。 静止モードでは、インフラストラクチャーが再度使用可能になるまで、 メッセージの処理速度が低下します。インフラストラクチャーが使用可能になると、 メッセージ処理が通常モードに戻ります。
通常の処理では、 以下のようにメッセージが処理されます。
静止モードでは、 メッセージの処理が定期的に試行されます。処理に失敗したメッセージは、配信回数や保存キューの巡回数を増加させることなく、入力キューに書き戻されます。メッセージを正常に処理できるようになると、 ただちにメッセージ処理が通常のモードに戻ります。
再試行限度は、保留キューに書き込まれる前に保存キューへメッセージを転送できる最大回数を定義しています。
保存キューに書き込まれるには、メッセージの処理が 3 回失敗する必要があります。
例えば、再試行限度が 5 である場合は、メッセージが保存キューに 5 回書き込まれると (3 * 5 = 15 回失敗すると) 最後の再試行が開始されます。 最後の再試行でさらに 2 回失敗すると、メッセージは保留キューに入れられます。 つまり、メッセージは、(3 * RetryLimit) + 2 回失敗すると保留キューに入れられます。
信頼できるインフラストラクチャーで実行中の パフォーマンス重視のアプリケーションでは、再試行限度を少なく、例えば 1 または 2 にしておく必要があります。再試行限度をゼロに設定すると、失敗を繰り返しているメッセージが 3 回まで再試行され、その後ただちに保留キューに移動します。
この Business Flow Manager プロパティーは管理コンソールで指定されます。「構成」タブの「ビジネス・インテグレーション」の下で、 をクリックします。
をクリックするか、または Business Process Choreographer がクラスター上で構成されている場合は、 をクリックします。保存キュー・メッセージ限度は、保存キューに入れることができるメッセージの最大数を定義します。保存キューがオーバーフローすると、システムは静止モードに入ります。 メッセージが失敗したら即時にシステムが静止モードに入るようにするには、値をゼロに設定します。Business Flow Manager のインフラストラクチャー障害に対する耐性を強化するには、値を増やします。
このプロパティーは管理コンソールで指定されます。「構成」タブの「ビジネス・インテグレーション」の下で、 をクリックします。
をクリックするか、または Business Process Choreographer がクラスター上で構成されている場合は、 をクリックします。管理者は、保留キューまたは保存キューから内部キューへメッセージを戻すことができます。 この操作は、管理コンソール、管理スクリプト、または Failed Event Manager を使用して実行できます。