本章ではWebOTX Process Conductorの障害時の動作について説明します。
7.1. 動作概要
WebOTX Process Conductorは、登録されているプロセス定義にしたがってプロセスインスタンスを実行しま
す。
プロセスインスタンスの実行時には、特定のタイミングでプロセスインスタンスの状態をデータベースに記録し ながら実行を進めます。したがって、プロセスインスタンスの状態の変更をデータベースに記録しない限り、理 論的には同じポイントからプロセスインスタンスの実行を再開しても情報の不整合は発生しません。
したがって、プロセスインスタンスの実行中にマシン障害などが発生しアプリケーションサーバが終了しても、
マシンを復旧し、アプリケーションサーバを再起動することで、WebOTX Process Conductor は障害が発生 する前に最後に記録した状態にプロセスインスタンスを復元して処理を再開することが可能となります。
しかしながら、たとえば障害が発生する前に外部のWebサービスを呼び出した可能性がある場合、障害発生 前のプロセスインスタンスの状態から実行を再開してしまうと、外部のWeb サービスを二重に呼び出してしま うことになり、結果として情報の整合性を保つことができなくなってしまいます。
WebOTX Process Conductorは障害が発生した場合、障害が発生する前に最後に記録した状態にプロセス
インスタンスを復元したあと、そのまま処理を継続しても問題がないと判断した場合はプロセスインスタンスの 実行を継続します。
一方で、外部のWeb サービスを二重に呼び出してしまう可能性があるなどそのまま処理を継続することが困 難であると判断した場合には、WebOTX Process Conductor 固有のフォールトを利用して、復元したプロセ スインスタンスに対してそのままプロセスインスタンスの実行を継続することは困難であることを通知します。こ のフォールトはfaultHandlerで捕捉するすることが可能であるため、何らかの復旧処理を行って、プロセスイ ンスタンスの実行を継続したり、補償処理などの後処理を行ってプロセスインスタンスの実行を終了したりする ことができます。
7.2. WebOTX Process Conductor 固有のフォールト
障害の発生によりプロセスインスタンスの継続が困難である場合や、メッセージの送受信時に通信障害が発 生した場合には、プロセスエンジンがWebOTX Process Conductor固有のフォールトをプロセスインスタンス に通知します。
プロセスエンジンが通知するWebOTX Process Conductor固有のフォールトは以下のものです。
名前空間URI jp.co.nec.ebiz.bpel.internal フォールト名 communicationFailureFault
このフォールトは他のフォールトと同様に、フォールトハンドラで捕捉することができます。
7.3. 障害発生後に処理の継続が困難な状況
障害が発生した後、WebOTX Process Conductorがプロセスインスタンスの処理を継続することが困難であ ると判断する状況を以下に示します。
（１）プロセスインスタンスへのメッセージ送信処理中に障害が発生した場合
プロセスインスタンスへのメッセージ送信処理を呼び出し、その呼び出しから戻っていない状態で障害が発
フォールトを通知します。
このときログファイルには以下のメッセージのいずれかが出力されます。
<>ReceiveRequestHandler<>matchedRequestNonRetryFormal<>リトライされた受信通知と マッチしたため、受信要求(FORMAL)[messageId = ***** ]に対して通信障害フォールトを送信し ます.
<>ReceiveRequestHandler<>matchedRequestRetry<>受信要求(RETRY)にマッチした受信 通知[messageId = ***** ]に対して通信障害フォールトを送信します.
<>ReceiveRequestHandler<>matchedRequestRetry<> リ ト ラ イ さ れ た 受 信 要 求 (FORMAL)[messageId = ***** ]に対して通信障害フォールトを送信します.
なお、メッセージ送信先のプロセスインスタンスが Initialized 状態である場合、送信先のプロセスインスタ ンスにフォールトは通知されず、また送信したメッセージは到着しなかったものとして扱われます。
メッセージが到着しなかったものとして扱われる場合、ログファイルに以下のメッセージのいずれかが出力さ れます。
<>ReceiveNotificationHandler<>matchedRequest<>受信通知[messageId = *****]は'リトラ イメッセージ' かつ 'SEED' であるため破棄します．
<>ReceiveRequestHandler<>matchedRequestNonRetrySeed<>受 信 通 知[messageId =
*****]は'リトライメッセージ'であるため破棄します．
<>ReceiveRequestHandler<>matchedRequestRetry<>受信要求が'リトライメッセージ'であるた め受信通知[messageId = *****]を破棄します．
（２）外部のWebサービス呼び出し処理中に障害が発生した場合
プロセスインスタンスから外部の Webサービスの呼び出しを行う処理の過程で障害が発生すると、復旧後 プロセスエンジンは該当のプロセスインスタンスにWebOTX Process Conductorｌ固有のフォールトを通知 します。
このときログファイルには以下のメッセージが出力されます。
<>MessageSend<>send2<>リトライメッセージであるため、通信障害フォールトを送信します．
<>Message = [*****]
なお、外部の Web サービスの呼び出しを行い、その呼び出しに成功したことが記録されている場合、復旧 後はプロセスインスタンスの実行が継続されます。
7.4. 通信障害
WebOTX Process Conductor へのメッセージ送信、外部の Web サービスの呼び出し、または WebOTX
Process Conductorからの応答メッセージの送信を行うさいには、通信障害が発生する可能性があります。
プロセスエンジンは、これらの処理で通信障害が発生したことを認識すると、WebOTX Process Conductor 固有のフォールトをプロセスインスタンスに通知します。
以下に通信障害が発生した場合のプロセスエンジンの処理について説明します。
（１）プロセスインスタンスへのメッセージ送信処理中に通信障害が発生した場合
プロセスインスタンスへのメッセージ送信処理中に通信障害が発生するケースでは、プロセスエンジンまで メッセージが届いていない状態です。
したがって、プロセスインスタンスはメッセージの到着を待っている状態であり、メッセージ送信前から状態 は変更されていません。
通信障害の原因を究明し、復旧を行った後に、同じメッセージを送信することでプロセスインスタンスの実行 が継続できます。
（２）外部のWebサービス呼び出し処理中に通信障害が発生した場合
プロセスインスタンスから外部のWebサービスを呼び出すさいに、呼び出し先サーバがダウンしているなど の状況で通信処理に失敗した場合、プロセスエンジンは、WebOTX Process Conductor固有のフォールト をプロセスインスタンスに通知します。
このときログファイルには以下のメッセージが出力されます。
<>InvokeRequestHandler<>外部サービス呼び出し中に障害が発生したため、通信障害フォール トを送信します．[messageId = *****]
（３）プロセスエンジンからの応答メッセージの送信時に通信障害が発生した場合
プロセスエンジンがreplyアクティビティの実行により応答メッセージの送信処理を行うさいに、一定の時間 を経過しても応答メッセージの送信に成功したことが確認できない場合には、プロセスエンジンは、
WebOTX Process Conductor固有のフォールトをプロセスインスタンスに通知します。
このときログファイルには以下のメッセージが出力されます。
<>ReplyTimerActionimpl<>createFaultReplyResponse<>Replyタイマーが発火しました．メッ セージ[messageId = *****]に対して通信障害フォールトを送信します．
応答メッセージの送信を行うさいにメッセージの送信が正しく行えたことを確認するまでの待ち時間は、プロ パティファイルから設定することができます。
プロパティファイルに設定する内容を以下に示します。
プロパティ 意味
jp.co.nec.ebiz.bpel.receive.reply.timeout
プロセスエンジンが reply アクティビティの実行に より応答メッセージの送信処理を行うさいに、応 答メッセージの送信に成功したことを確認するま での待ち時間をミリ秒単位で指定します。指定し ない場合は、180000 ミリ秒(3 分)になります。
・ 設定例：
#---
# topic reception time-out time
#---
jp.co.nec.ebiz.bpel.receive.reply.timeout=180000