(57)【要約】【課題】上流システムから受信したファイルを用いて、下流システムにおいて、世代順を考慮したジョブの実行を支援するためのジョブ管理システム、ジョブ管理方法及びジョブ管理プログラムを提供する。【解決手段】第１サーバ１０から取得したファイルを用いて、第２サーバ２０のジョブ実行環境におけるジョブ実行を管理する制御部２１を備える。そして、制御部２１が、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブ、保留解除受付ジョブの実行に基づいて実行される業務処理ジョブ、業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブからなる一世代の復旧用ジョブネットを生成する。【選択図】図１
2019159789.tif 000002
【特許請求の範囲】
【請求項１】
上流システムから取得したファイルを用いて、下流システムのジョブ実行環境におけるジョブ実行を管理する制御部を備えたジョブ管理システムであって、
前記制御部が、
スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、
先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、
前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、
前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧用ジョブネットを生成することを特徴とするジョブ管理システム。
【請求項２】
前記上流システムから前記ファイルを受信していない場合、まだ実行されていない復旧用ジョブネットの世代数を算出し、前記世代数が上限数に達していないことを条件に、前記世代数に１を加算した復旧用ジョブネットを生成することを特徴とする請求項１に記載のジョブ管理システム。
【請求項３】
前記上流システムからファイルを受信した場合、前記ファイルに関連付けられた業務処理ジョブの実行条件を取得し、前記実行条件に基づいて、前記業務処理ジョブを含む復旧用ジョブネットを実行することを特徴とする請求項１又は２に記載のジョブ管理システム。
【請求項４】
前記上流システムからのファイルの受信スケジュールに対して、受信したファイルの遅延状況に基づいて、前記ファイルに関連付けられた業務処理ジョブを含む復旧用ジョブネットの実行要否を判定することを特徴とする請求項１〜３の何れか一項に記載のジョブ管理システム。
【請求項５】
前記保留解除ジョブの実行に基づいて実行可能となった復旧用ジョブネットを特定し、
ジョブ実行環境のリソースに空きがある場合に、前記復旧用ジョブネットの業務処理ジョブの優先順位に基づいて、前記復旧用ジョブネットの実行を指示することを特徴とする請求項１〜４の何れか一項に記載のジョブ管理システム。
【請求項６】
前記保留解除ジョブの実行に基づいて実行可能となった復旧用ジョブネットの実行状況を取得し、
復旧用ジョブネットの実行リソースの状況を取得し、
前記復旧用ジョブネットの業務処理ジョブの完了時限に応じて、リソース配分を変更することを特徴とする請求項１〜５の何れか一項に記載のジョブ管理システム。
【請求項７】
前記上流システムからの複数のファイルを受信した場合に、前記上流システムにおいて生成されるべきファイルの世代順に並び替えて、復旧用ジョブネットを実行することを特徴とする請求項１〜６の何れか一項に記載のジョブ管理システム。
【請求項８】
前記業務処理ジョブにおいて、障害の発生前に受信したファイルを用いて出力された第１の出力結果と、前記障害の復旧後に受信したファイルを用いて出力された第２の出力結果との差分を算出し、
前記障害の期間に応じた許容範囲を特定し、
前記差分と前記許容範囲とに基づいてアラームを出力することを特徴とする請求項１〜７の何れか一項に記載のジョブ管理システム。
【請求項９】
上流システムから取得したファイルを用いて、下流システムのジョブ実行環境におけるジョブ実行を管理する制御部を備えたジョブ管理システムを用いて、ジョブ実行を管理する方法であって、
前記制御部が、
スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、
先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、
前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、
前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧用ジョブネットを生成することを特徴とするジョブ管理方法。
【請求項１０】
上流システムから取得したファイルを用いて、下流システムのジョブ実行環境におけるジョブ実行を管理する制御部を備えたジョブ管理システムを用いて、ジョブ実行を管理するためのプログラムであって、
前記制御部を、
スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、
先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、
前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、
前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧用ジョブネットを生成する手段として機能させることを特徴とするジョブ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、上流システムからファイルを受信した下流システムにおいて、世代順を考慮したジョブの実行を支援するためのジョブ管理システム、ジョブ管理方法及びジョブ管理プログラムに関する。
【背景技術】
【０００２】
企業における業務管理のために複数のバッチジョブを連続して実行させる場合がある。この場合、各ジョブの先後関係を考慮する必要があり、このような先後関係を示したジョブネットワーク（ジョブネット）によりジョブの実行を管理している。このようなジョブネットにおいて障害が発生することもある。そこで、ジョブネットを使用したバッチ処理システムにおける障害復旧処理のための技術が検討されている（例えば、特許文献１を参照。）。この文献に記載された技術においては、必要な再実行ジョブを決定する再実行ジョブ決定手段、ジョブ再実行の為のジョブ再実行手段、実行ジョブ制御文が格納されている実行ＪＣＬライブラリ、ジョブ内で処理されたファイル情報を格納するアクセス履歴ファイル、再実行が必要なジョブ名が格納されている再実行ジョブ管理ファイルを設ける。
【０００３】
また、企業システムにおいては、複数のシステムを連携させて構築する場合がある。例えば、銀行においては、対顧客用の勘定系システムや市場系システム（上流システム）に対して、取引状況や企業状況を管理するための情報系システム（下流システム）を設ける場合がある。この場合には、下流システムは、上流システムから取引に関するファイル（上流ファイル）を取得し、このファイルを加工するための各種情報処理のためのジョブネットを実行する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−２２９０３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上流システムは、所定の処理サイクル（例えば、日次）で、下流システムに上流ファイルを提供する。この上流ファイルは、処理サイクルを実行した基準日（日付）毎に世代管理される。ここで、下流システムにおいては、基準日が遅い後続世代の上流ファイルを扱う後続ジョブが、基準日が早い先行世代（先行基準日）の上流ファイルを扱う先行ジョブを追い越して実行されないように世代順を考慮する必要がある。一方、障害発生により、上流ファイルの提供が予定時刻よりも遅延することがある。このような上流ファイルの遅延に対応して、下流システムにおいてジョブの復旧を行なったのでは、上流ファイルの受信タイミングを考慮する必要があり、復旧に手間がかかっていた。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、ジョブ管理システムは、上流システムから取得したファイルを用いて、下流システムのジョブ実行環境におけるジョブ実行を管理する制御部を備える。そして、前記制御部が、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧用ジョブネットを生成する。
【発明の効果】
【０００７】
本発明によれば、下流システムにおいて、上流システムから受信したファイルを用いて、世代順を考慮したジョブの実行を支援することができる。
【図面の簡単な説明】
【０００８】
【図１】本実施形態のシステム概略図。
【図２】本実施形態のルートジョブネットの説明図。
【図３】本実施形態の世代順を考慮したルートジョブネットの説明図。
【図４】本実施形態の処理手順の説明図であって、（ａ）はジョブ生成管理処理、（ｂ）はジョブ実行管理処理の説明図。
【図５】本実施形態のルートジョブネットの処理状態の説明図であって、（ａ）はｎ日、（ｂ）は（ｎ＋１）日、（ｃ）は（ｎ＋２）日、（ｄ）は（ｎ＋３）日、（ｅ）は（ｎ＋６）日の処理状態の説明図。
【図６】他の実施形態の処理手順の説明図であって、（ａ）はジョブ実行管理処理、（ｂ）はルートジョブネットの処理状態の説明図。
【図７】他の実施形態の処理手順の説明図。
【図８】他の実施形態の処理手順の説明図。
【図９】他の実施形態の処理手順の説明図。
【発明を実施するための形態】
【０００９】
以下、図１〜図５を用いて、ジョブ管理システムの一実施形態を説明する。
図１に示すように、本実施形態では、ネットワークを介して接続された第１サーバ１０及び第２サーバ２０を用いる。
【００１０】
この第２サーバ２０には、クライアント端末３０が接続される。クライアント端末３０は、第２サーバ２０を管理する担当者が用いるコンピュータ端末や、第２サーバ２０における業務処理結果を出力するコンピュータ端末である。クライアント端末３０は、ディスプレイ等の出力部、キーボード及びポインティングデバイス等の入力部を備えている。
【００１１】
第１サーバ１０は、上流システムであり、例えば、顧客の口座を管理する勘定系や、取引市場において顧客取引を管理する市場系等の対顧系システムを想定する。本実施形態では、勘定系や市場系の処理に基づいて生成された情報（上流ファイル）を第２サーバ２０に提供する。
【００１２】
第２サーバ２０は、第１サーバ１０の下流システムであり、第１サーバ１０から取得した上流ファイルに基づいて、会計処理や報告書の作成処理等の情報処理（業務処理）を行なう情報系（内部系）のコンピュータシステムである。この第２サーバ２０は、制御部２１、ジョブネット定義記憶部２２、ジョブ定義記憶部２３、スケジュール定義記憶部２４、ステータス情報記憶部２５を備えている。
【００１３】
制御部２１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（ジョブ生成段階、ジョブ管理段階、ジョブ実行段階等の各処理）を行なう。そのためのジョブ管理プログラムを実行することにより、制御部２１は、ジョブ生成部２１１、ジョブ管理部２１２、ジョブ実行部２１３として機能する。
【００１４】
ジョブ生成部２１１は、第２サーバ２０において実行されるジョブを生成する処理を実行する。本実施形態では、第１サーバ１０において障害が発生し、取引情報の提供が受信スケジュールよりも遅延した場合に、ジョブ生成部２１１は、この遅延に対応したジョブネットワーク（復旧用ジョブネット）を生成する。
【００１５】
ジョブ管理部２１２は、登録された各種ジョブ、ジョブネットの実行を管理する処理を実行する。
ジョブ実行部２１３は、ジョブ実行環境（リソース）において、ジョブ管理部２１２によって制御された各ジョブを実行する。このジョブ実行部２１３は、ジョブ識別子毎に登録されている。
【００１６】
ジョブネット定義記憶部２２には、ジョブネットを構成するジョブについてのジョブネット定義データが記録される。このジョブネット定義記憶部２２には、各ジョブネットを構成する先行ジョブ、後続ジョブを特定するためのデータが記録される。
【００１７】
図２に示すように、本実施形態では、第１サーバ１０（上流システム）に障害が発生し、第２サーバ２０（下流システム）において上流ファイルの受信が、受信スケジュールよりも遅延した場合、復旧のためのルートジョブネット５００（復旧用ジョブネット）を生成する。
【００１８】
このルートジョブネット５００は、第１ジョブネットＪ１〜第３ジョブネットＪ３により構成される。
第１ジョブネットＪ１は、保留解除を受け付ける保留解除受付用ネストジョブネットワークであり、第１サーバ１０からの基準日の上流ファイルの受信を待機する保留用ダミージョブＪ１１や、先行ジョブの実行完了を待機する保留用ダミージョブＪ１２を含む。保留用ダミージョブＪ１１は、第１サーバ１０から、所定のファイル識別子の上流ファイルを受信した場合に実行される。保留用ダミージョブＪ１２は、先行ジョブが実行完了した場合に実行される。
【００１９】
第２ジョブネットＪ２は、第１サーバ１０からの上流ファイルを用いた情報処理（例えば、会計処理や報告書の作成処理等の業務処理）を実行するジョブネットワークである。
保留解除用の第３ジョブネットＪ３は、後続のルートジョブネットの保留を解除させる多重起動管理用のネストジョブネットワークであり、保留解除ジョブＪ３１を含む。
【００２０】
図３に示すように、第１サーバ１０の障害発生時から、ジョブ実行スケジュールの周期に基づいて、上流ファイルが遅延した回数分のルートジョブネット５０１〜５０７が生成される。例えば、実行サイクルが１日毎（日次）の場合、障害発生日（ｎ日）から、順次、処理サイクルの世代毎に、ルートジョブネット５０１〜５０７が生成される。本実施形態では、最大７日（上限数）分のルートジョブネットを生成する場合を想定する。
【００２１】
図１に示すジョブ定義記憶部２３には、各ジョブの実行を管理するためのジョブ定義データが記録される。このジョブ定義データには、定義及び属性に関するデータが記録される。
定義データ領域には、ジョブ識別子、実行ファイル名、パラメータ、入力ファイル識別子等に関するデータが記録される。ジョブ識別子は、各ジョブを特定するための識別子である。実行ファイル名は、このジョブとして実行されるスクリプトファイルを特定するための識別子である。パラメータは、実行結果の出力先を特定するための識別子である。入力ファイル識別子は、このジョブにおいて入力されるファイルを特定するための識別子である。
【００２２】
属性データ領域には、保留要否を特定するためのフラグが含まれる。本実施形態では、第１ジョブネットＪ１の保留用ダミージョブＪ１１，Ｊ１２には「保留要」フラグが設定される。一方、第３ジョブネットＪ３の保留解除ジョブＪ３１には、「保留不要」フラグが設定される。
【００２３】
スケジュール定義記憶部２４には、ジョブを実行するスケジュールデータが記録される。スケジュールルールにより、ジョブネットの生成タイミングが決定される。このスケジュールルールデータには、ジョブ識別子、開始日、開始時刻、処理サイクルに関するデータが記録される。
【００２４】
ジョブ識別子データ領域には、ジョブ（ルートジョブネット、ネストジョブネットを含む）を特定するための識別子に関するデータが記録される。
開始日データ領域には、ジョブ実行のスケジュールを開始する年月日に関するデータが記録される。
【００２５】
開始時刻データ領域には、ジョブを実行する時刻に関するデータが記録される。この開始時刻により、上流ファイルの受信スケジュールが定められる。
処理サイクルデータ領域には、ジョブの実行について、サイクル実行の要否、周期、単位に関するデータが記録される。サイクル実行の要否は、周期的なジョブ実行の要否を特定するためのフラグである。周期は、ジョブを実行する間隔を特定するための数値である。例えば、最大７日の遅延に対応するために「１〜６日」を設定する。単位は、周期を構成する要素（例えば、暦日単位、運用日単位、休業日単位等）である。
【００２６】
ステータス情報記憶部２５には、ジョブの実行結果に関するステータスデータが記録される。このステータスデータには、ジョブ識別子、世代、状況、開始日時、終了日時に関するデータが記録される。
ジョブ識別子データ領域には、ジョブ（ルートジョブネット、ネストジョブネットを含む）を特定するための識別子に関するデータが記録される。
【００２７】
世代データ領域には、処理サイクルにおける世代（例えば、ｎ日分）を特定するための識別子に関するデータが記録される。
状況データ領域には、このジョブの実行状況を特定するための識別子に関するデータが記録される。
開始日時、終了日時の各データ領域には、このジョブの開始及び終了の年月日及び時刻に関するデータが記録される。
【００２８】
（ジョブ生成管理処理）
次に、図４（ａ）を用いて、ジョブ生成管理処理を説明する。ここでは、第１サーバ１０の障害等により、第２サーバ２０において、上流ファイルの受信が、受信スケジュールよりも遅延している場合を想定する。
【００２９】
まず、第２サーバ２０の制御部２１は、ジョブネット生成の要否判定処理を実行する（ステップＳ１−１）。具体的には、制御部２１のジョブ生成部２１１は、システムタイマから現在日時を取得し、スケジュール定義記憶部２４のスケジュールルールデータに記録された開始時刻を経過した業務処理用ジョブネットのジョブ識別子を特定する。ここで、業務処理用ジョブネットを実行するために必要な条件（上流ファイルの受信、先行ジョブネットの実行済み）を満足していない場合には、ジョブネット生成が必要と判定する。なお、ジョブネット生成が必要でないと判定した場合には、ジョブ生成管理処理を終了する。
【００３０】
ジョブネット生成が必要と判定した場合、第２サーバ２０の制御部２１は、上限日数分を生成済かどうかについての判定処理を実行する（ステップＳ１−２）。具体的には、制御部２１のジョブ生成部２１１は、ジョブ生成時期が到来したジョブ識別子が設定された過去世代のルートジョブネットを、ジョブネット定義記憶部２２において確認する。そして、上限日数（上限数）分の過去世代のルートジョブネット（復旧用ジョブネット）が登録されている場合には、上限日数分を生成済みと判定する。
【００３１】
上限日数分を生成済でないと判定した場合（ステップＳ１−２において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、先行ジョブに繋げたジョブ生成処理を実行する（ステップＳ１−３）。具体的には、制御部２１のジョブ生成部２１１は、受信していない基準日の上流ファイルを待機する保留用ダミージョブＪ１１を含めた第１ジョブネットＪ１を生成する。この第１ジョブネットＪ１には、先行世代（先行基準日）の先行ジョブの第３ジョブネットＪ３により多重起動管理される保留用ダミージョブＪ１２を含める。そして、第１ジョブネットＪ１に繋げた第２ジョブネットＪ２、第３ジョブネットＪ３からなるルートジョブネットを生成し、ジョブネット定義記憶部２２に登録する。
【００３２】
一方、上限日数分を生成済と判定した場合（ステップＳ１−２において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、先行ジョブに繋げたジョブ生成処理（ステップＳ１−３）をスキップして、ジョブ生成管理処理を終了する。
【００３３】
（ジョブ実行管理処理）
次に、図４（ｂ）を用いて、ジョブ実行管理処理を説明する。この処理は、ステータス情報記憶部２５のステータスデータが変更された場合に、ルートジョブネット５００について実行する。また、各ルートジョブネット５００について、定期的に実行するようにしてもよい。
ここでは、第２サーバ２０の制御部２１は、受信ファイル保留解除かどうかについての判定処理を実行する（ステップＳ２−１）。具体的には、第１サーバ１０から、所定基準日の上流ファイルを受信した場合、ジョブ実行部２１３は、ファイル識別子に対応した保留用ダミージョブＪ１１を実行し、ステータス情報記憶部２５において、ジョブ識別子に関連付けて、状況データ領域に実行済みフラグを記録する。この場合、制御部２１のジョブ管理部２１２は、ステータス情報記憶部２５において、保留用ダミージョブＪ１１の状況を確認する。保留用ダミージョブＪ１１の実行済みフラグが記録されている場合には、受信ファイル保留解除と判定する。
【００３４】
受信ファイル保留解除と判定した場合（ステップＳ２−１において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、多重起動保留解除かどうかについての判定処理を実行する（ステップＳ２−２）。具体的には、ジョブ実行部２１３は、保留解除ジョブＪ３１を実行した場合、多重起動管理の保留用ダミージョブＪ１２を実行し、ステータス情報記憶部２５において、ジョブ識別子に関連付けて、状況データ領域に実行済みフラグを記録する。この場合、制御部２１のジョブ管理部２１２は、ステータス情報記憶部２５において、保留用ダミージョブＪ１２が実行されているかどうかを確認する。多重起動管理用の保留用ダミージョブＪ１２が実行終了している場合には、多重起動保留解除と判定する。
【００３５】
多重起動保留解除と判定した場合（ステップＳ２−２において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、ジョブ実行処理を実行する（ステップＳ２−３）。具体的には、制御部２１のジョブ管理部２１２は、ジョブ定義記憶部２３に記録されたジョブのジョブ実行部２１３により、業務処理用の第２ジョブネットＪ２の実行を指示する。そして、第２ジョブネットＪ２の実行後に第３ジョブネットＪ３を実行する。そして、ジョブ実行部２１３は、第２ジョブネットＪ２によって生成された業務処理結果情報をクライアント端末３０に出力する。
【００３６】
受信ファイル保留解除でないと判定した場合、又は多重起動保留解除でないと判定した場合（ステップＳ２−１，Ｓ２−２において「ＮＯ」の場合）、サーバの制御部２１は、ジョブ実行処理（ステップＳ２−３）をスキップしてジョブ実行管理処理を終了する。
【００３７】
図５（ａ）に示すように、「ｎ日」に、第１サーバ１０に障害が発生し、上流ファイルを受信できない場合、ルートジョブネット５０１を生成する。
図５（ｂ）に示すように、「（ｎ＋１）日」においても復旧しない場合、ルートジョブネット５０１に繋げたルートジョブネット５０２を生成する。
【００３８】
そして、図５（ｃ）に示すように、「（ｎ＋２）日」に復旧した場合、順次、各基準日の上流ファイルを受信する。この場合、障害が発生したｎ日〜（ｎ＋２）日分の上流ファイルを順番に受信すると限らず、ｎ日分よりも（ｎ＋１）日分の上流ファイルを先に受信する場合もある。このため、世代順を維持するために、（ｎ＋２）日分のルートジョブネット５０３を生成する。
【００３９】
図５（ｄ）に示すように、「（ｎ＋３）日」において、（ｎ＋３）日分の上流ファイルを受信した場合にも、ｎ日分、（ｎ＋２）日分の上流ファイルを受信していない場合、（ｎ＋３）日分のルートジョブネット５０４を生成する。
【００４０】
図５（ｅ）に示すように、「（ｎ＋６）日」において、ｎ日分、（ｎ＋２）日分の上流ファイルを受信した場合、ルートジョブネット５０１〜５０４を順次、実行する。まだ、（ｎ＋４）日分のように、受信していない上流ファイルが残っている場合には、（ｎ＋５）日分のルートジョブネット５０６に繋げた基準日（ｎ＋６）日分のルートジョブネット５０７を生成する。
【００４１】
以上、本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態によれば、第１サーバ１０の障害等により、上流ファイルの受信が遅延している場合、先行のルートジョブネットに繋げたルートジョブネット５００を生成する。これにより、ジョブの追い越し実行を抑制し、世代順のジョブ実行を維持しながら、業務処理ジョブを実行することができる。
【００４２】
（２）本実施形態によれば、ルートジョブネット５００の第１ジョブネットＪ１は、第１サーバ１０からの上流ファイルの受信を待機する保留用ダミージョブＪ１１や、先行ジョブの実行完了を待機する保留用ダミージョブＪ１２を含む。これにより、障害復旧時に、複数世代の上流ファイルを受信したり、世代順では異なる順番で受信したりした場合にも、世代順を維持しながら、業務処理ジョブを実行し、第２サーバ２０のリカバリを行なうことができる。
【００４３】
本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、受信ファイル及び多重起動について保留解除されている場合には、業務処理用の第２ジョブネットＪ２を実行する。これに加えて、障害発生時に、ジョブ実行の要否を判定するようにしてもよい。この場合、ジョブネット定義記憶部２２に、ジョブ識別子に関連付けて、障害時実行条件を記録しておく。この障害時実行条件は、障害発生時にジョブの実行要否を判定する条件である。例えば、世代順に繋げた複数のルートジョブネットにおいて、最新世代のルートジョブネットを実行する場合には、過去世代のルートジョブネットは、実行せずに実行済扱いとする。
【００４４】
図６（ａ）を用いて、ジョブ実行管理処理を説明する。
第２サーバ２０の制御部２１は、ステップＳ２−１，Ｓ２−２と同様に、保留解除かどうかについての判定処理（ステップＳ３−１）、多重起動保留解除かどうかについての判定処理（ステップＳ３−２）を実行する。
【００４５】
ここで、受信ファイル保留解除でないと判定した場合、又は多重起動保留解除でないと判定した場合（ステップＳ３−１，Ｓ３−２において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、ジョブ実行管理処理を終了する。
一方、受信ファイル保留解除かつ多重起動保留解除と判定した場合（ステップＳ３−１，Ｓ３−２において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、実行対象かどうかについての判定処理を実行する（ステップＳ３−３）。具体的には、制御部２１のジョブ管理部２１２は、ジョブ定義記憶部２３において、実行条件を満たすかどうかを確認する。
【００４６】
実行条件に基づいて実行対象と判定した場合（ステップＳ３−３において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、ステップＳ２−３と同様に、ジョブ実行処理を実行する（ステップＳ３−４）。
【００４７】
一方、実行対象でないと判定した場合（ステップＳ３−３において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、実行済み登録処理を実行する（ステップＳ３−５）。具体的には、制御部２１のジョブ管理部２１２は、実行対象でないルートジョブネットについては、ジョブ実行することなく、ステータス情報記憶部２５に実行済みを記録する。
【００４８】
例えば、図６（ｂ）に示すように、基準日ｎ日〜（ｎ＋２）日分の上流ファイルを第１サーバ１０から同時期に取得した場合を想定する。この場合、ｎ日〜（ｎ＋２）日分のルートジョブネット５１１〜５１３が実行可能となる。ここで、実行条件として「最新世代のみ実行」が設定されている場合には、ｎ日、（ｎ＋１）日分のルートジョブネット５１１，５１２を実行済みに設定する。そして、（ｎ＋２）日のルートジョブネット５１３について保留解除されて、業務処理用の第２ジョブネットＪ２を実行する。
【００４９】
なお、実行条件は、「最新世代のみ実行」に限定されるものではない。例えば、遅延状況と実行時限との関係に基づいて、実行要否を判定するようにしてもよい。この場合には、ジョブネット定義記憶部２２の実行条件として、実行時限を設定しておく。そして、実行時限に達していないルートジョブネットについては実行し、実行時限を経過したルートジョブネットについては実行済みとして取り扱う。これにより、遅れが小さいジョブを実行し、遅れが大きいジョブの実行をスキップすることができる。
【００５０】
・上記実施形態では、受信ファイル及び多重起動について保留解除されている場合には、業務処理用の第２ジョブネットＪ２を実行する。これに代えて、他のルートジョブネットとの関係に基づいて、実行する第２ジョブネットＪ２を選択するようにしてもよい。この場合、ジョブネット定義記憶部２２のジョブネット定義データに、ジョブ識別子に関連付けて障害時優先順位を記録しておく。更に、ステータス情報記憶部２５において、保留解除されたジョブのジョブ識別子に関連付けてステータスデータの状況データ領域に実行可能フラグを記録する。
【００５１】
図７を用いて、ジョブ実行管理処理を説明する。
ここでも、第２サーバ２０の制御部２１は、ステップＳ２−１，Ｓ２−２と同様に、受信ファイル保留解除かどうかについての判定処理（ステップＳ４−１）、多重起動保留解除かどうかについての判定処理（ステップＳ４−２）を実行する。
【００５２】
ここで、受信ファイル保留解除でないと判定した場合、又は多重起動保留解除でないと判定した場合（ステップＳ４−１，Ｓ４−２において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、ジョブ実行管理処理を終了する。
一方、受信ファイル保留解除かつ多重起動保留解除と判定した場合（ステップＳ４−１，Ｓ４−２において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、実行可能ジョブの登録処理を実行する（ステップＳ４−３）。具体的には、制御部２１のジョブ管理部２１２は、ステータス情報記憶部２５に、ジョブ識別子に関連付けて、状況データ領域に実行可能フラグを記録する。
【００５３】
そして、リソース管理処理を実行する。
ここでは、第２サーバ２０の制御部２１は、リソース確認処理を実行する（ステップＳ５−１）。具体的には、制御部２１のジョブ管理部２１２は、ジョブ実行環境において使用可能なリソース状況を取得する。
【００５４】
次に、第２サーバ２０の制御部２１は、リソースに空きがあるかどうかについての判定処理を実行する（ステップＳ５−２）。具体的には、制御部２１のジョブ管理部２１２は、ジョブ実行環境において使用可能なリソースがある場合には、リソースに空きがあると判定する。
【００５５】
リソースに空きがあると判定した場合（ステップＳ５−２において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、実行待ちジョブ確認処理を実行する（ステップＳ５−３）。具体的には、制御部２１のジョブ管理部２１２は、ステータス情報記憶部２５において、実行可能フラグが記録されたジョブを検索する。
【００５６】
次に、第２サーバ２０の制御部２１は、実行待ちジョブがあるかどうかについての判定処理を実行する（ステップＳ５−４）。具体的には、制御部２１のジョブ管理部２１２は、ステータス情報記憶部２５において、実行可能フラグが記録されたジョブを特定した場合には、実行待ちジョブがあると判定する。
【００５７】
実行待ちジョブがあると判定した場合（ステップＳ５−４において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、最優先ジョブの特定処理を実行する（ステップＳ５−５）。具体的には、制御部２１のジョブ管理部２１２は、ジョブ定義記憶部２３から、実行待ちジョブの障害時優先順位を取得する。そして、ジョブ管理部２１２は、障害時優先順位が最も高いジョブを特定する。
【００５８】
次に、第２サーバ２０の制御部２１は、ジョブ実行処理を実行する（ステップＳ５−６）。具体的には、制御部２１のジョブ管理部２１２は、特定した障害時優先順位が最も高いジョブを実行する。そして、リソース確認処理（ステップＳ５−１）に戻る。
【００５９】
一方、リソースに空きがないと判定した場合や、実行待ちジョブがないと判定した場合（ステップＳ５−２，Ｓ５−４において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、リソース確認処理（ステップＳ５−１）に戻る。
これにより、ジョブの優先度を考慮して、ジョブを実行することができる。
【００６０】
・上記実施形態では、受信ファイル及び多重起動について保留解除されている場合には、業務処理用の第２ジョブネットＪ２を実行する。これに加えて、リソースを調整するようにしてもよい。この場合、ジョブ定義記憶部２３には、ジョブ識別子に関連付けて完了時限に関するデータを記録しておく。更に、ジョブ実行環境には、稼動系リソースと待機系リソースとを準備しておく。稼動系リソースは、ジョブ実行のために常時使用可能なリソースである。待機系リソースは、必要に応じてジョブ実行に割り当て可能な予備のリソースである。
【００６１】
図８を用いて、リソース監視処理を説明する。
ここでは、第２サーバ２０の制御部２１は、リソース状況確認処理を実行する（ステップＳ６−１）。具体的には、制御部２１のジョブ管理部２１２は、ジョブ実行環境において使用可能なリソース状況を取得する。
【００６２】
次に、第２サーバ２０の制御部２１は、完了時限に間に合うかどうかについての判定処理を実行する（ステップＳ６−２）。具体的には、制御部２１のジョブ管理部２１２は、リソース状況に基づいて、保留解除されたジョブの実行所要時間を算出する。例えば、単位リソース量において、単位データ量のジョブを実行した場合の単位所要時間を用いて、現在使用可能なリソース量、このジョブにおけるデータ量から実行所要時間を算出する。そして、ジョブ管理部２１２は、ジョブ定義記憶部２３から、保留解除された各ジョブの完了時限を特定する。現在時刻に実行所要時間を加算した時刻が完了時限よりも前の場合には、完了時限に間に合うと判定する。
【００６３】
完了時限に間に合うと判定した場合（ステップＳ６−２において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、追加リソースがあるかどうかについての判定処理を実行する（ステップＳ６−３）。具体的には、制御部２１のジョブ管理部２１２は、通常リソースに対して、追加された待機系リソースがある場合には追加リソースがあると判定する。
【００６４】
ここで、追加リソースがないと判定した場合（ステップＳ６−３において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、リソース状況確認処理（ステップＳ６−１）に戻る。
一方、追加リソースがあると判定した場合（ステップＳ６−３において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、不必要な追加分の排除処理を実行する（ステップＳ６−４）。具体的には、制御部２１のジョブ管理部２１２は、完了時限に間に合わせるための必要リソースを算出する。次に、ジョブ管理部２１２は、必要リソースを越えて追加された待機系リソースの割り当てを中止する。そして、リソース状況確認処理（ステップＳ６−１）に戻る。
【００６５】
完了時限に間に合わないと判定した場合（ステップＳ６−２において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、リソース必要量の算出処理を実行する（ステップＳ６−５）。具体的には、制御部２１のジョブ管理部２１２は、完了時限に間に合わせるための必要リソース量を算出する。
【００６６】
次に、第２サーバ２０の制御部２１は、不足分の追加処理を実行する（ステップＳ６−６）。具体的には、制御部２１のジョブ管理部２１２は、必要リソース量から、現在の割当リソースを差し引いて、不足分を算出する。次に、ジョブ管理部２１２は、不足分について、待機系リソースの割当を依頼する。そして、リソース状況確認処理（ステップＳ６−１）に戻る。
これにより、完了時限を考慮して、必要なリソースを割り当てることができる。また、不必要な過大なリソースの割当を抑制することができる。
【００６７】
・上記実施形態では、第２サーバ２０の制御部２１は、受信ファイル保留解除かどうかについての判定処理を実行する（ステップＳ２−１）。ここで、第１サーバ１０から、同時期に複数のファイルを受信した場合、上流ファイルの種類に応じて、ジョブ実行部２１３に提供するようにしてもよい。この場合には、ファイル識別子に基づいて、世代順にファイルを特定する。例えば、上流ファイルの基準日が古い順番に並べ替える。そして、ルートジョブネットの世代順に、受信した上流ファイルをジョブ実行部２１３に提供する。これにより、ジョブの実行順番を考慮して、効率的に上流ファイルを提供することができる。
【００６８】
・上記実施形態では、第２サーバ２０の制御部２１は、ジョブ実行処理を実行する（ステップＳ２−３）。この場合、ジョブ管理部２１２は、業務処理用の第２ジョブネットＪ２によって生成された業務処理結果情報をクライアント端末３０に出力する。ここで、出力された情報の確認処理を実行するようにしてもよい。この場合、第２サーバ２０に通常出力記憶部を設ける。この通常出力記憶部には、障害が発生していない通常時に、業務処理用の第２ジョブネットＪ２によって出力された業務処理結果情報をジョブ識別子に関連付けて記録しておく。
【００６９】
図９を用いて、出力確認処理を説明する。この処理は、復旧時に、第２ジョブネットＪ２の実行後に行なわれる。
ここでは、第２サーバ２０の制御部２１は、通常処理結果の取得処理を実行する（ステップＳ７−１）。具体的には、制御部２１のジョブ管理部２１２は、障害発生前の業務処理結果情報を、通常出力記憶部から取得する。
【００７０】
次に、第２サーバ２０の制御部２１は、復旧後処理結果の取得処理を実行する（ステップＳ７−２）。具体的には、制御部２１のジョブ管理部２１２は、業務処理用の第２ジョブネットＪ２によって生成された業務処理結果情報を取得する。
【００７１】
次に、第２サーバ２０の制御部２１は、比較して差分の算出処理を実行する（ステップＳ７−３）。具体的には、制御部２１のジョブ管理部２１２は、障害発生前の業務処理結果情報と、復旧後に取得した業務処理結果情報とを比較して、差分を算出する。
【００７２】
次に、第２サーバ２０の制御部２１は、遅延期間の変動幅の予測処理を実行する（ステップＳ７−４）。具体的には、制御部２１のジョブ管理部２１２は、障害による遅延期間の長さに応じて、業務処理結果情報の変動幅を算出する。ここでは、遅延期間が長い程、大きな変動幅を算出する変動幅算出情報（関数やテーブル）を用いる。
【００７３】
次に、第２サーバ２０の制御部２１は、許容範囲内かどうかについての判定処理を実行する（ステップＳ７−５）。具体的には、制御部２１のジョブ管理部２１２は、算出した差分と変動幅とを比較する。差分が変動幅内に含まれる場合には、許容範囲内と判定する。
【００７４】
許容範囲内でないと判定した場合（ステップＳ７−５において「ＮＯ」の場合）、第２サーバ２０の制御部２１は、アラーム処理を実行する（ステップＳ７−６）。具体的には、制御部２１のジョブ管理部２１２は、クライアント端末３０にアラームメッセージを出力する。この場合、担当者が、復旧後に取得した業務処理結果情報を確認し、必要に応じて業務処理結果情報の補正を行なう。
【００７５】
一方、許容範囲内と判定した場合（ステップＳ７−５において「ＹＥＳ」の場合）、第２サーバ２０の制御部２１は、アラーム処理（ステップＳ７−６）をスキップして出力確認処理を終了する。
【符号の説明】
【００７６】
１０…第１サーバ、２０…第２サーバ、２１…制御部、２１１…ジョブ生成部、２１２…ジョブ管理部、２１３…ジョブ実行部、２２…ジョブネット定義記憶部、２３…ジョブ定義記憶部、２４…スケジュール定義記憶部、２５…ステータス情報記憶部、３０…クライアント端末、５００〜５１３…ルートジョブネット、Ｊ１…第１ジョブネット、Ｊ１１，Ｊ１２…保留用ダミージョブ、Ｊ２…第２ジョブネット、Ｊ３…第３ジョブネット、Ｊ３１…保留解除ジョブ。
【図１】
2019159789.tif 000003
【図２】
2019159789.tif 000004
【図３】
2019159789.tif 000005
【図４】
2019159789.tif 000006
【図５】
2019159789.tif 000007
【図６】
2019159789.tif 000008
【図７】
2019159789.tif 000009
【図８】
2019159789.tif 000010
【図９】
2019159789.tif 000011