1.8.9 障害時の動作
アプリケーション呼び出しの処理中に障害が発生した場合，呼び出しが成功するまでリトライします。アプリケーション呼び出しサービス自身に障害が発生した場合は，アプリケーション呼び出しサービスを多重化していれば，ほかのアプリケーション呼び出しサービスに処理が引き継がれます。
アプリケーション呼び出しサービスでは，大きく分けて次に示す障害の発生が考えられます。
-
アプリケーション呼び出し処理での障害
・アプリケーション呼び出し情報ファイルの設定不備
・呼び出し処理の失敗※
・呼び出し元作業の完了の失敗
-
アプリケーション呼び出しサービス自身の障害
J2EEサーバプロセスのダウン
- 注※
-
アプリケーション呼び出し処理に失敗するケースを次の表に示します。
表1‒22 アプリケーション呼び出し処理に失敗するケース BPMN要素
呼び出し処理に失敗するケース
サービスタスクおよびビジネスルールタスク
-
呼び出し先のRESTアプリケーションとの通信障害が発生した場合
-
呼び出し先のRESTアプリケーションが返却したステータスコードの判定結果が失敗であった場合
-
呼び出し先のJavaオブジェクトのインスタンス生成に失敗した場合
-
呼び出し先のJavaオブジェクトで例外が発生した場合
メッセージ
呼び出し処理（案件投入または遷移要求）に失敗した場合
エラー
呼び出し処理（遷移要求）に失敗した場合
タイマー
呼び出し処理（案件投入または遷移要求）に失敗した場合
-
次に，これらの障害時の動作について説明します。
アプリケーション呼び出し処理での障害
アプリケーション呼び出し処理で障害が発生すると，呼び出しが成功するまでリトライします。
リトライは呼び出しが失敗したあと，リトライ間隔後に行われます。
- メモ
-
実際にリトライする間隔は，リトライ間隔の設定値から最大で実行間隔分のずれが発生します。実行間隔を小さくするほど，リトライ間隔の設定値と実際に作業をリトライする間隔とのずれは小さくなります。ただし，呼び出し処理の頻度がその分増えるため，負荷が増加します。
リトライ間隔と実行間隔の関係を次の図に示します。
図の例では，アプリケーション呼び出しサービスは，実行間隔300秒ごとに呼び出し処理を行っています。1回目の実行間隔の途中で呼び出し障害が発生し，呼び出しが失敗した時刻が作業に設定されます。そして，2回目の実行間隔の最初でリトライ間隔の判定処理が行われます。しかし，判定のタイミングでは，リトライ間隔の300秒が経過していません。そのため，リトライによる呼び出しは3回目の実行間隔の間に行われ，リトライ間隔の設定値である300秒とのずれが発生します。
|
|
![[図データ]](GRAPHICS/F0000118.GIF)
なお，リトライした回数は，呼び出し元の作業の優先度に設定されます。アプリケーションの呼び出しに失敗した時刻は，呼び出し元の作業の処理期限に設定されます。アプリケーション呼び出しサービスは，設定したリトライ回数だけリトライします。設定した回数分リトライしても失敗した場合は，アプリケーション呼び出しサービスのメッセージファイルに，エラーメッセージを出力します。また，呼び出し元の作業の状態を「作業者実行」に，優先度を「0」に変更します。これ以降，該当する作業はリトライの対象から外れます。
- メモ
-
リトライ対象の作業がBPMN連携ライブラリのAPIやコマンドで「実行開始可能」状態に変更された場合，作業の優先度が「0」に変更されます。このとき，設定したリトライ回数よりも多くアプリケーション呼び出しのリトライが行われます。
リトライの対象から外れた作業を再び呼び出し対象とする場合は，障害の原因を取り除いたあとで，該当する作業の状態を「作業者実行」から「実行開始可能」に変更してください。作業の状態を「作業者実行」から「実行開始可能」に変更する方法については，「10.5 リトライの対象から外れた作業に関する運用」を参照してください。
リトライ回数とリトライ間隔は，ref識別子単位で設定できます。アプリケーション呼び出し制御情報の「リトライ回数（RetryCount）」および「リトライ間隔（RetryInterval）」に設定してください。アプリケーション呼び出し制御情報の詳細については，マニュアルuCosminexus Service Coordinator Interactive Workflow コマンドの「ciwmngap（アプリケーション呼び出し制御情報の管理）」を参照してください。
なお，リトライ回数およびリトライ間隔が有効になるかどうかは，BPMN要素によって異なります。
- リトライ回数およびリトライ間隔が有効になるBPMN要素
-
-
サービスタスク
-
ビジネスルールタスク
-
メッセージイベント
-
エラーイベント
-
- リトライ回数およびリトライ間隔が有効にならないBPMN要素
-
-
タイマーイベント
-
アプリケーション呼び出しサービス自身の障害
アプリケーション呼び出しサービス自身が障害になった場合，アプリケーション呼び出しサービスを多重化していれば，ほかのアプリケーション呼び出しサービスが代わりに呼び出し処理を継続できます。
なお，ほかのアプリケーション呼び出しサービスが代わりに呼び出し処理を行うタイミングは，障害復旧間隔が経過したあとになります。
障害復旧間隔はref識別子単位に設定できます。アプリケーション呼び出し制御情報の「障害復旧間隔（RecoveryTime）」に設定してください。アプリケーション呼び出し制御情報の詳細については，マニュアルuCosminexus Service Coordinator Interactive Workflow コマンドの「ciwmngap（アプリケーション呼び出し制御情報の管理）」を参照してください。
- 重要
-
呼び出し先の処理が長時間掛かると，次の図のように障害復旧間隔後にほかのアプリケーション呼び出しサービスが同じ作業の呼び出し処理を行ってしまいます。
このように，二重に作業が呼び出されてしまうおそれがあるため，呼び出し先のアプリケーションで長時間掛かる処理はしないようにしてください。
障害復旧間隔は，次の式で求められる値よりも大きくしてください。
(<呼び出し先のアプリケーションの処理時間> × <最大作業件数>) ÷ <WorkManagerのスレッド数>
また，アプリケーション呼び出しの実行中にJ2EEサーバを強制停止した場合，J2EEサーバの再開始後，障害復旧間隔が経過するまでアプリケーションの呼び出しが行われないおそれがあります。このため通常の運用ではJ2EEサーバを強制停止したり，障害復旧間隔を大きくし過ぎたりしないでください。
|
|
![[図データ]](GRAPHICS/F0000119.GIF)