(57)【要約】【課題】  従来、あるシステム（他システム）を監視する専用の装置（システム監視部）を設けて、これが監視機能を専用的に実行している。つまり、システム監視部と他システムが連携してある情報処理を実現することは開示されておらず、連携先のシステムの障害監視に関しては考慮されていない。このため、従来、監視や回復などの障害対策専用の装置を設ける必要があった。【解決手段】  本発明では、障害を検知した場合、連携先システムに対して障害が継続中かの確認処理を実行し、障害が回復したことを検知した場合、処理結果が不明の電文が存在するかを検知し、ある場合には当該電文に対して回復処理を不明の電文がなくなるまで繰り返す。【選択図】  図１
2008282292.tif 000002
【特許請求の範囲】
【請求項１】
第1のシステムから第2のシステムに処理要求を送信することで所定の情報処理を実行する連携システムにおける障害回復方法において、
前記第1のシステムが、
前記第2のシステムの障害を検知し、
前記障害を検知した場合、前記第2のシステムに対して障害が継続中かの確認処理を実行し、
前記障害が回復したことを検知した場合、処理結果が不明の電文が存在するかを検知し、
前記不明の電文の存在を検知した場合には当該電文に対して回復処理を不明の電文がなくなるまで繰り返すことを特徴とする障害回復方法。
【請求項２】
請求項１に記載の障害回復方法において、
前記第1のシステムは、
前記処理結果を格納するキューテーブルを有し、
前記キューテーブルで、前記処理結果が不明の電文のＩＤを計数し、
前記計数されたＩＤが1以上の場合、前記ＩＤの示す処理結果について、前記第２のシステムへ前記処理結果の回復確認電文を送信し、
前記第２のシステムから前記回復確認電文に応じた応答電文を受信して、受信された前記応答電文に応じて、前記キューテーブルのステータスを変更し、
前記回復確認電文の送信および前記ステータスの変更を、計数されたＩＤ数分繰り返すことで、前記回復処理を不明の電文までなくなることまで繰り返すことを実現する障害回復方法。
【請求項３】
請求項１または２のいずれかに記載の障害回復方法において、
前記第１のシステムは、
前記回復処理を不明の電文までなくなることまで繰り返した後で、業務アプリケーションを起動することで、前記所定の情報処理を再開することを特徴とする障害回復方法。
【請求項４】
第1のシステムから第2のシステムに処理要求を送信することで所定の情報処理を実行する連携システムにおいて、
前記第1のシステムが、
前記第2のシステムの障害を検知し、
前記障害を検知した場合、前記第2のシステムに対して障害が継続中かの確認処理を実行し、
前記障害が回復したことを検知した場合、処理結果が不明の電文が存在するかを検知し、
前記不明の電文の存在を検知した場合には当該電文に対して回復処理を不明の電文がなくなるまで繰り返すことを特徴とする連携システム。
【請求項５】
請求項４に記載の連携システムにおいて、
前記第1のシステムは、
前記処理結果を格納するキューテーブルを有し、
前記キューテーブルで、前記処理結果が不明の電文のＩＤを計数し、
前記計数されたＩＤが1以上の場合、前記ＩＤの示す処理結果について、前記第２のシステムへ前記処理結果の回復確認電文を送信し、
前記第２のシステムから前記回復確認電文に応じた応答電文を受信して、受信された前記応答電文に応じて、前記キューテーブルのステータスを変更し、
前記回復確認電文の送信および前記ステータスの変更を、計数されたＩＤ数分繰り返すことで、前記回復処理を不明の電文までなくなることまで繰り返すことを実現する連携システム。
【請求項６】
請求項４または５のいずれかに記載の連携システムにおいて、
前記第１のシステムは、
前記回復処理を不明の電文までなくなることまで繰り返した後で、業務アプリケーションを起動することで、前記所定の情報処理を再開することを特徴とする連携システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、いわゆるシステムに発生する障害に関する技術である。その中でも特に、あるシステムが連携して所定の処理を実行する場合、連携先のシステムで発生した障害の検知、その障害に対する回復（復旧）、回復後の処理に関する。
【背景技術】
【０００２】
システムの障害状況を収集するための技術として、特許文献１が存在する。特許文献１では、ユーザに迅速に障害の復旧方法を提示するために、障害状況を収集することが開示されている。より具体的には、障害が発生していないか監視を行い、障害が発生した場合には、その障害を記述する障害状況情報を受信し、蓄積された障害からの復旧方法を記述する復旧情報を検索し、得られた復旧情報を他システムに送信することにより障害復旧の援助を行う技術が記載されている。これにより、障害が発生した場合に障害の内容を記述した情報が得られ、なおかつ、その情報により復旧情報を検索し、他システムに送信されるので、障害発生時に迅速に復旧情報を提示することができることが記載されている。
【０００３】
【特許文献１】特開２００３−８５００３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献１においては、あるシステム（他システム）を監視する専用の装置（システム監視部）を設けて、これが監視機能を専用的に実行している。つまり、システム監視部と他システムが連携してある情報処理を実現することは開示されておらず、連携先のシステムの障害監視に関しては考慮されていない。このため、特許文献１では、監視や回復などの障害対策専用の装置を設ける必要がある。
【課題を解決するための手段】
【０００５】
そこで、本発明では、障害を検知した場合、連携先システムに対して障害が継続中かの確認処理を実行し、障害が回復したことを検知した場合、処理結果が不明の電文が存在するかを検知し、ある場合には当該電文に対して回復処理を不明の電文がなくなるまで繰り返す。
【発明の効果】
【０００６】
本発明によれば、複数のシステムが連携して所定の情報処理を実行する連携システムで、障害回復処理をより容易に実現することが可能になる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の実施の形態を詳細に説明する。図1は本発明を示す構成図であり、図2は処理手順の実施の形態を示すフローチャートである。図３は、このフローチャートでのステップ１１１〜１１３の詳細処理を示すフローチャートである。また、図４、５のそれぞれは、図1の各DBに含まれるデータテーブル図である。
【０００８】
まず、図1の構成図について説明する。自システム(APサーバ)上に存在するキュー監視用常駐アプリケーションから自システム(DBサーバ)側に保持されているキューを定期的に参照する。業務アプリケーション、相手先確認アプリケーション、処理結果回復アプリケーション、相手先ヘルスチェックアプリケーションはキュー監視用常駐アプリケーションの管理下にあり、必要に応じてキュー監視用常駐アプリケーションから起動される。業務アプリケーションは他システムへ業務電文を送信する処理を実施する。相手先確認アプリケーションは他システムでの障害発生時に、定期間隔で他システムの生死監視をアプリケーションレベルで実施する。処理結果回復アプリケーションは、障害回復時に処理結果が未解決の業務の結果を解決させる処理を実施する。相手先ヘルスチェックアプリケーションでは定期間隔で他システムに対して、ネットワークレベルでの疎通確認を実施する。このことにより他システム障害を迅速に検知することができる。
【０００９】
自システム(DBサーバ)側では、DBのテーブルとして制御テーブルとキューテーブルが存在する。制御テーブルでは各キューの動作状態(実行中、停止等)を保持している。キューテーブルはキュー単位で存在して、業務処理にて利用させる業務電文を保持している。
【００１０】
次に、図2および3のフローチャートにより、本実施形態の処理の流れを説明する。なお、本実施形態は、いわゆるプログラムに従って、自システム（図示しないプロセッサ等）によって実行される。
他システムで障害が発生して業務処理を継続できなくなった場合は、自システム側で障害発生を検知する(ステップ101)。
【００１１】
業務アプリケーションから他システムへの電文送信時に例外が発生した場合は、業務アプリケーションにて障害発生を検知する。他システムが障害と判定される条件は相手先送信処理がタイムアウトした場合とネットワーク障害のエラー応答時、応答電文のエラー内容に他システムオフラインを示す内容が含まれている場合である(ステップ102)。
【００１２】
相手先ヘルスチェックアプリケーションからは定期的に相手先システムに対してネットワークの疎通確認を実施するリクエストを送信している。リクエストの応答なし、またはエラー応答の場合に相手先が障害で業務処理不可能な状態と判断し、相手先ヘルスチェックアプリケーションで障害発生を検知する(ステップ103)。
【００１３】
ステップ102、103にてシステム_Aでの障害発生を検知した場合は、障害発生検知したアプリケーションから制御テーブルの該当するレコード(QUEUE_A)の動作モードのステータスを”実行中”⇒”閉塞中”に更新する(ステップ104)。
【００１４】
キュー監視用常駐アプリケーションでは、キューに新規の電文が到着していないか定期間隔（もしくは予め定められたタイミング）でチェック（確認）する。その際に、制御テーブルのステータスについてもチェックしており、”実行中”の場合は電文を取得、それ以外の場合は電文を取得しない制御を実施している。制御テーブルのキューのステータスが”閉塞中”の場合は、”閉塞中”に更新（ステータスを書き換え）後、次の電文チェックの際にこのステータスの内容に基づき”閉塞中”であることを検知する(ステップ105)。
【００１５】
システム_A障害時においては、システム_A回復時をなるべく早く検知して、業務処理を継続させたいとの要求がある。そこで、キュー監視用常駐アプリケーションから相手先回復アプリケーションを起動する(ステップ106)。
【００１６】
相手先確認アプリケーションは、定期間隔でシステム_Aに対して、ダミーの業務電文を送信してシステム_Aが業務処理可能か否かチェック（判断）する(ステップ107)。
【００１７】
相手先確認アプリケーションから送信したダミー電文に対するレスポンスが正常応答(電文の処理結果を示す内容(コード、文言)が正常の意味である場合は、正常応答と判断する)の場合、相手先は正常に業務処理が可能な状態に回復したと判断する。以降は回復処理のステップ110へ進む。なお障害時に処理結果不明となった業務処理の回復を待たずに後続の業務を再開したいケース(業務の順序性を保証しなくても良いケース)ではステップ110、114を平行して実施することもできる(ステップ108)。
【００１８】
相手先確認アプリケーションから送信したダミー電文に対するレスポンスがエラー応答、応答なしの場合は、相手先が回復していないと判断する。一定間隔経過したあとで再びステップ107の処理を実行する。これにより、相手先の回復のチェックを続けることが可能になる(ステップ109)。
【００１９】
ここで、相手先回復後に業務を再開する前に、相手先障害時にエラーまたは処理結果が不明となった業務処理の処理結果解決を実施する必要がある。キュー監視用常駐アプリケーションでは、相手先確認アプリケーションで相手先回復をした場合に、相手先確認の通知を受信する(スレッド間通信にて)。通知受信後、キュー監視用常駐アプリケーションから処理結果回復アプリケーションを起動する(ステップ110)。
【００２０】
次に、相手先システムに対して、処理結果照会電文を送信する。これにより、 処理結果回復アプリケーションでは処理結果が不明の電文(QUEUE_Aのキューテーブルの電文ID#100、#101)の処理結果を確認することが可能になる(ステップ111)。
【００２１】
処理結果回復処理(電文ID#100は不明⇒処理済、電文ID#101は不明⇒未処理)によって、処理結果不明の電文が存在しなくなった場合は、処理結果回復処理が終了したと判断する。その後、ステップ114へ進む(ステップ112)。
【００２２】
電文ID#100または#101の処理結果が不明のまま残存していた場合は、処理結果解決がされていないので、処理結果回復処理を継続する(ステップ113)。
【００２３】
次に、図３を用いて、ステップ111〜113の処理結果解決についての詳細なフローチャートについて説明する。
閉塞中のキューのキューテーブル(QUEUE_A)内でステータスが不明で処理結果が未解決のレコードの電文IDを検索して（例えば、一括検索）、処理結果不明のレコードの電文IDリストを取得する。処理結果解決処理を効率化する目的で、処理結果解決を実施する前に処理結果が不明なレコードを事前に一括して取得する。レコードに登録された電文を上から順番（ＩＤの昇順（もしくは降順）や登録された時間などでの順序）に取得して、処理結果が不明ならば解決処理を実施してそれ以外は次のレコードを取得する。この処理をレコードの件数分繰り返す制御を行ってもよいが、処理結果不明のレコードは処理結果が解決済みのレコードよりも少数であることが多いため、無駄な処理が多い（ステップ201）。
【００２４】
ステップ201で取得したリストの件数が0件の場合は、他システム障害によって処理結果が未決で残存した取引がないと判断する。つまり処理結果解決か完了したと判断してステップ114へ進む(ステップ202)。
【００２５】
ステップ201で取得したリストの件数が1件以上の場合は、他システム障害によって処理結果が未決の取引が存在する。以降のステップで処理結果を解決する処理を実施する(ステップ203)。
【００２６】
ステップ201で取得した不明レコードの電文ID一覧から1件ずつIDを取得して、各電文IDの業務に対する処理結果確認電文を送信する。なお、処理結果解決処理をより高速に実施するために、多重度複数で回復処理を実施することも可能である。マルチスレッドで処理可能として、各スレッドから電文IDを適宜取得して処理解決処理を実施する(ステップ205)。
【００２７】
ステップ206で、他システムへ送信した処理結果確認電文の応答結果に応じて、該当レコードのステータスを更新する。応答電文がなかった場合やエラーの場合は、ステータスの更新はせずに不明のままとする(ステップ206)。すなわち、書き換えを行わなくてよい。
【００２８】
ステップ205、206の処理結果解決処理はステップ201で取得したリストに含まれる電文IDすべてに対して実施する。電文ID一覧の解決処理が完了した場合に、再度処理結果不明のレコードが存在するか確認する。この結果、不明なレコードが残っていた場合には、ステップ203〜206を繰り返す。処理結果解決が不可能な場合については検討が必要である。処理結果解決処理を5回繰り返しても、決着できない場合は解決不能と判断して強制的に先進めする等の対応が必要となる。
【００２９】
処理結果回復アプリケーションにて処理結果回復が完了した場合は、業務処理を再開させるために制御テーブルQUEUE_Aのレコードのステータスを”閉塞中”⇒”開局中”へ更新する(ステップ114)。
【００３０】
キュー監視用常駐アプリケーション側でQUEUE_Aのステータスが”開局中”へ更新されたことを検知したら、業務処理を再開させるために業務アプリケーションを起動する。それにより、電文がキューに到着した場合は業務処理が再開可能な状態に復旧する(ステップ115)。
【図面の簡単な説明】
【００３１】
【図１】本実施の形態におけるシステム構成図
【図２】本実施の形態におけるフローチャート
【図３】図２のステップ１１１〜１１３の詳細を示すフローチャート
【図４】キュー制御テーブルを示す図
【図５】キューテーブルを示す図
【符号の説明】
【００３２】
１…制御テーブル、２…キューテーブル、３…キュー監視用常駐アプリケーション、４…業務アプリケーション、５…相手先確認アプリケーション、６…障害結果回復アプリケーション、７…相手先ヘルスチェックアプリケーション
【図１】
2008282292.tif 000003
【図２】
2008282292.tif 000004
【図３】
2008282292.tif 000005
【図４】
2008282292.tif 000006
【図５】
2008282292.tif 000007