(57)【要約】【課題】  従来のタスク処理システムにおいては、システムのバージョンアップやメンテナンスなどで、バッチ処理を行うサーバが停止し、スケジューリングされていた複数のタスクの処理が遅れるケースについて十分に考慮されていない。【解決手段】  上記課題を解決するために、本発明である管理システムは、ジョブフロー定義ファイルで定義される特定のジョブの実行に際して、その前工程のジョブの完了を待たずに特定のジョブを実行指示すべき２種類の開始時刻（第１の開始時刻と第２の開始時刻）を定義する。【選択図】  図５
2016004305.tif 000002
【特許請求の範囲】
【請求項１】
複数のジョブの実行を制御する管理システムであって、
第１の定義ファイルで定義される特定のジョブの実行を指示する際に、当該第１の定義ファイルで定義される前工程ジョブが完了しているか否かを判定する第１の判定手段と、
前記第１の判定手段により前記前工程ジョブが完了していると判定された場合に、前記特定のジョブの実行を指示する実行手段と、
現在時刻が、前記第１の定義ファイルで定義される第１の開始時刻を過ぎているかを判定する第２の判定手段と、
前記第１の判定手段により前記前工程ジョブが完了していないと判定された場合に、現在時刻が、前記第１の定義ファイルで定義される第２の開始時刻を過ぎているかを判定する第３の判定手段と、
前記第３の判定手段により現在時刻が前記第２の開始時刻を過ぎていたと判定された場合に、前記前工程ジョブのステータスに対応する待機時間に基づき、前記特定のジョブを実行すべきかを判定する第４の判定手段と、を有し、
前記実行手段は、前記第２の判定手段により現在時刻が前記第１の開始時刻を過ぎていたと判定された場合に、前記第１の判定手段による判定を行うことなく、前記特定のジョブの実行を指示し、
前記実行手段は、さらに、前記第４の判定手段により前記特定のジョブを実行すべきであると判定された場合に、前記特定のジョブの実行を指示することを特徴とする管理システム。
【請求項２】
前記第１の定義ファイルにおいて、前記第２の開始時刻は、前記第１の開始時刻よりも前の時刻が指定されることを特徴とする請求項１に記載の管理システム。
【請求項３】
前記第４の判定手段は、前記第１の定義ファイルで定義される特定の種別の前工程ジョブについてのみ、当該前工程ジョブのステータスに対応する待機時間に基づき、前記特定のジョブを実行すべきかを判定することを特徴とする請求項１または２に記載の管理システム。
【請求項４】
前記第４の判定手段は、現在時刻が、前記前工程ジョブが現在のステータスとなった時刻から前記待機時間だけ経過した時刻を過ぎていた場合に、前記特定のジョブを実行すべきであると判定することを特徴とする請求項１乃至３のいずれか１項に記載の管理システム。
【請求項５】
完了していない前記前工程ジョブのステータスが開始待ちであった際には、
前記第４の判定手段は、現在時刻が、前記前工程ジョブの実行指示時刻から前記第１の定義ファイルで定義される第１の待機時間だけ経過した時刻を過ぎていた場合に、前記特定のジョブを実行すべきであると判定することを特徴とする請求項４に記載の管理システム。
【請求項６】
完了していない前記前工程ジョブのステータスが処理中であった際には、
前記第４の判定手段は、現在時刻が、前記前工程ジョブの処理開始時刻から前記第１の定義ファイルで定義される第２の待機時間だけ経過した時刻を過ぎていた場合に、前記特定のジョブを実行すべきであると判定することを特徴とする請求項４または５に記載の管理システム。
【請求項７】
完了していない前記前工程ジョブのステータスが実行未指示であった際には、
前記第４の判定手段は、前記前工程ジョブを定義する第２の定義ファイルにおける更なる前工程ジョブのステータスを判別し、
さらに、現在時刻が、当該更なる前工程ジョブが現在のステータスとなった時刻から少なくとも前記待機時間だけ経過した時刻を過ぎていた場合に、前記特定のジョブを実行すべきであると判定することを特徴とする請求項１乃至６のいずれか１項に記載の管理システム。
【請求項８】
前記実行手段は、前記第１の判定手段により前記前工程ジョブが完了していると判定された際に、さらに、現在時刻が、前記第１の定義ファイルで定義される第３の開始時刻、及び、前記前工程ジョブの終了時刻から所定時間だけ経過した時刻をともに過ぎていた場合に、前記特定のジョブの実行を指示することを特徴とする請求項１乃至７のいずれか１項に記載の管理システム。
【請求項９】
前記複数のジョブは、機器から収集したデータを取得するジョブ、機器から収集したデータを集計するジョブ、及び集計されたデータを用いたレポートを行うためのジョブの少なくとも何れかを含むことを特徴とする請求項１乃至８のいずれか１項に記載の管理システム。
【請求項１０】
複数のジョブの実行を制御する管理システムにおける制御方法であって、
第１の定義ファイルで定義される特定のジョブの実行を指示する際に、当該第１の定義ファイルで定義される前工程ジョブが完了しているか否かを判定する第１の判定ステップと、
前記前工程ジョブが完了していると判定された場合に、前記特定のジョブの実行を指示する実行ステップと、
現在時刻が、前記第１の定義ファイルで定義される第１の開始時刻を過ぎているかを判定する第２の判定ステップと、
前記前工程ジョブが完了していないと判定された場合に、現在時刻が、前記第１の定義ファイルで定義される第２の開始時刻を過ぎているかを判定する第３の判定ステップと、
現在時刻が前記第２の開始時刻を過ぎていたと判定された場合に、前記前工程ジョブのステータスに対応する待機時間に基づき、前記特定のジョブを実行すべきかを判定する第４の判定ステップと、を有し、
前記実行ステップでは、現在時刻が前記第１の開始時刻を過ぎていたと判定された場合に、前記第１の判定ステップでの判定を行うことなく、前記特定のジョブの実行が指示され、
前記実行ステップでは、さらに、前記第４の判定ステップで前記特定のジョブを実行すべきであると判定された場合に、前記特定のジョブの実行が指示されることを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
クラウドシステムなどを利用して提供されるサービスの実行単位となるジョブの実行制御などの技術に関する。
【背景技術】
【０００２】
近年、クラウドシステムを利用したサービスとして、様々な機器から収集した各種情報を集計し、レポーティングして、それら情報の活用を促すサービスが存在する。収集される情報の例としては、ネットワーク機器の機能などの利用回数を示すカウンタ情報や、利用履歴を示すログ情報、各種センサ情報などがある。
従来から、各種情報の集計のためのバッチ処理のために、必要な処理を、複数のタスクに分割して、順次、または並行に処理する技術が存在する。（例えば、特許文献１）
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−１８６３９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
システムのバージョンアップやメンテナンスなどで、バッチ処理を行うサーバが停止し、スケジューリングされていた複数のタスク（ジョブ）の処理が遅れるケースがある。従来技術は、このようなケースについて、特に考慮していない。
【０００５】
上記ケースにおいて、サーバが復旧したタイミングでスケジューリングされていた複数のタスクを、一気に並行処理してしまうと、処理負荷が高いばかりか、想定した結果も得られないかもしれない。しかしながら、安全性を重視して、オペレータが、再スケジューリングするなどしていると、例えば、当初の期限内に収集した情報の集計が完了しないことも想定される。
【０００６】
従って、上記のようなケースも想定した上で、適切なジョブのスケジューリング、例外処理を含む実行制御が必要である。そこで、本発明の目的は、上記課題を解決し得る手法を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の一例である、複数のジョブの実行を制御する管理システムは、第１の定義ファイルで定義される特定のジョブの実行を指示する際に、当該第１の定義ファイルで定義される前工程ジョブが完了しているか否かを判定する第１の判定手段と、前記第１の判定手段により前記前工程ジョブが完了していると判定された場合に、前記特定のジョブの実行を指示する実行手段と、現在時刻が、前記第１の定義ファイルで定義される第１の開始時刻を過ぎているかを判定する第２の判定手段と、前記第１の判定手段により前記前工程ジョブが完了していないと判定された場合に、現在時刻が、前記第１の定義ファイルで定義される第２の開始時刻を過ぎているかを判定する第３の判定手段と、前記第３の判定手段により現在時刻が前記第２の開始時刻を過ぎていたと判定された場合に、前記前工程ジョブのステータスに対応する待機時間に基づき、前記特定のジョブを実行すべきかを判定する第４の判定手段と、を有し、前記実行手段は、前記第２の判定手段により現在時刻が前記第１の開始時刻を過ぎていたと判定された場合に、前記第１の判定手段による判定を行うことなく、前記特定のジョブの実行を指示し、前記実行手段は、さらに、前記第４の判定手段により前記特定のジョブを実行すべきであると判定された場合に、前記特定のジョブの実行を指示することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、上述した従来技術に比べて、ジョブの実行タイミングの制御がより柔軟に行えるようになる。
【図面の簡単な説明】
【０００９】
【図１】本発明における管理システムの構成を示す
【図２】管理サーバ１０１におけるジョブの実行スケジュールの制御処理を説明するためのフローチャート
【図３】管理サーバ１０１におけるジョブの実行指示の際の処理を説明するためのフローチャート
【図４】ジョブ実行サーバ１０２におけるジョブ実行に係る処理を説明するためのフローチャート
【図５】ジョブフローの実行制御に係る処理を説明するためのフローチャート
【図６】ジョブフローの概念図
【図７】ハードウェアの構成例を示す
【図８】テナント管理テーブルの構成例を示す
【図９】テナント別ジョブ設定テーブルの構成例を示す
【図１０】スケジュール定義ファイルの例を示す
【図１１】ジョブフロー定義ファイルの例を示す
【図１２】バッチジョブ管理テーブルの構成例を示す
【図１３】スケジュールジョブ管理テーブルの構成例を示す
【図１４】キュー管理テーブルの構成例を示す
【発明を実施するための形態】
【００１０】
（実施例１）
［システムの全体構成］
図１はネットワークシステムの例を示し、本発明が適用可能な管理システム１００が含まれている。管理システム１００には、構成する管理サーバ１０１と、ジョブ実行サーバ１０２と、データベース（ＤＢ）サーバ１０３と、が含まれる。また、管理サーバ１０１、ジョブ実行サーバ１０２、及びＤＢサーバ１０３は、ネットワーク１０４を介して通信可能に接続されている。ネットワーク１０４は、インターネット等の既知の技術により実現される。また、管理サーバ１０１、ジョブ実行サーバ１０２は、ネットワーク１０４を介して、ネットワークシステムに存在する外部システム（不図示）とも接続可能である。
【００１１】
管理サーバ１０１は、管理システム１００が提供するサービスの実行単位となるジョブのスケジュール管理、ジョブフロー制御を主に行う。ジョブ実行サーバ１０２は、管理サーバ１０１の指示のもとで、実際のジョブ処理を実行する。ここで管理システム１００が提供するサービスの例としては、外部システムからのデータ取得や集計処理、集計結果に従うレポート作成などが含まれる。それぞれのサービスは、スケジュールに従いジョブが実行されることで実現されることになる。また、外部システムからのデータとしては、管理対象となるネットワーク機器から収集された各種カウンタ情報やログ情報、センサ情報など、様々なデータが含まれる。
【００１２】
ＤＢサーバ１０３は、管理サーバ１０１、ジョブ実行サーバ１０２で使用される管理・設定・状態情報などを格納するサーバである。図示しないが、ジョブ実行サーバ１０２で実行されジョブの入力情報や出力情報もＤＢサーバ１０３に格納することができる。
【００１３】
［管理サーバ１０１、ジョブ実行サーバ１０２、ＤＢサーバ１０３のハードウェア構成］
図７は、管理サーバ１０１、ジョブ実行サーバ１０２、ＤＢサーバ１０３などの情報処理装置のハードウェア構成を示す。ＣＰＵ７０１は、ＲＯＭ７０２、又は大規模記憶装置であるハードディスク（ＨＤＤ）７０６に記憶されたソフトウェアを実行する。後述される管理システム内における各装置による処理は、本発明に特有なソフトウェア（プログラム）をＣＰＵ７０１が実行することで実現されることになる。また、ＣＰＵ７０１は、システムバス７０４に接続される各デバイスを総括的に制御する。ＲＡＭ７０３は、ＣＰＵ７０１の主メモリ、ワークエリア等として機能する。ディスクコントローラ（ＤＩＳＫ）７０５は、ハードディスク７０６を制御する。ネットワークインターフェースカード（ＮＩＣ）７０７は、ネットワーク１０４を介して、他のノードと双方向にデータをやりとりする。
【００１４】
［管理システムにおけるソフトウェアのモジュール構成の例］
図１を用いて、管理システム内のソフトウェアのモジュール構成の例について説明する。
【００１５】
まず、管理サーバ１０１は、起動制御部１１１、ユーザーインタフェース（ＵＩ）制御部１１２、スケジュール管理部１１３、ジョブフロー制御部１１４、テナント管理部１１５、指示部１１６を備える。
【００１６】
起動制御部１１１は、スケジュール管理部１１３、ジョブフロー制御部１１４を定期的に起動する。ＵＩ制御部１１２は、図示しない端末上のＷｅｂブラウザに対して、ネットワーク１０４、ＮＩＣ７０７を経由したＵＩを提供する。具体的には、ＨＴＴＰまたはＨＴＴＰＳのリクエストに対して、ＵＩ制御部１１２が応答（ＨＴＭＬデータ）を返すことにより、Ｗｅｂ上のＵＩを提供する。
【００１７】
スケジュール管理部１１３は、スケジュール定義ファイル１４１と、テナント管理部１１５が管理するテナント情報とを参照し、ジョブのスケジュールに従い、指示部１１６に実行指示を要求する。ここでの実行指示の履歴を、ＤＢサーバ１０３のスケジュールジョブ管理テーブル１３４を用いて、管理する。
【００１８】
図１０は、スケジュール定義ファイル１４１の例を示す。なお、左端の数字は、説明のために付加した行番号である。
【００１９】
スケジュール定義ファイルには、複数のジョブのスケジュールが定義されている。図１０の例では、０２〜０９行目、１０〜１８行目、１９〜２６行目までの３つのジョブのスケジュールが定義されている。スケジュール定義ファイルでは、各ジョブの属性の定義として、ジョブ名、テナントＩＤ、起動周期、起動日、起動時刻、実行ファイル、実行時引数が設定される。属性の定義が無い場合には、スケジュール管理部１１３は当該属性に対応する設定なしとして扱う。
【００２０】
各属性を以下に説明する。
・ジョブ名（０３、１１、２０行目）は、ジョブを識別するため名前を示す。
・テナントＩＤ（０４、１２、２１行目）は、本スケジュールの適用対象となるテナントを識別するＩＤである。「＊」が記載されている場合にはすべてのテナントが適用対象となる。
・起動周期（０５、１３、２２行目）は、ジョブの起動周期を示す。例えば、「ＤＡＩＬＹ」は毎日起動、「ＭＯＮＴＨＬＹ」は毎月１回起動を示す。
・起動日（１４行目）は、起動周期が「ＭＯＮＴＨＬＹ」の場合に、ジョブを起動すべき日程を指定する。
・起動時刻（０６、１５、２３行目）は、ジョブの実行時刻を示す。
・実行ファイル（０７、１６、２４行目）は、ジョブの実行時に処理対象となるファイル名を示す。
・実行時引数（０８、１７、２５行目）は、ジョブの実行時に必要となる引数を示す。図１０の例では、「｛ＴＩＤ｝｛ＴＺ｝」となっており、ＴＩＤ（テナントＩＤ）と、ＴＺ（処理対象となる日付）を指定すること意味する。
【００２１】
ジョブフロー制御部１１４は、ジョブフロー定義ファイル１４２と、ＤＢサーバ１０３のバッチジョブ管理テーブル１３３とを参照し、ジョブフローの制御を行う。ここで、ジョブフローは、順序をもつ複数のジョブから構成される。複数のジョブを所定の順序で、連続して実行したい場合などに、ジョブフロー定義ファイル１４２で、ジョブフローが定義されることになる。
【００２２】
図１１を用いて、ジョブフロー定義ファイル１４２について説明する。なお、図１１で示す左端の数字は、説明のために付加した行番号である。ジョブフロー定義ファイル１４２には、複数のジョブフローの定義が含まれる。図１１の例では、０２〜１５行目、１６〜２９行目、３０〜４１行目までの３つのジョブフローが定義されている。
【００２３】
ジョブフロー定義ファイル１４２では、ジョブフローの属性の定義として、ジョブ名、開始条件、実行ファイル、及び実行時引数が設定される。属性の定義がない場合には、ジョブフロー制御部１１４は、当該属性に対応する設定なしとして扱う。
【００２４】
各属性を、以下に説明する。
・ジョブ名（０３、１７、３１行目）は、ジョブの種別を識別する名前である。
・開示条件（０４、１８、３２行目）には、さらに以下の（イ）〜（ト）で示す詳細設定が含まれる。
【００２５】
（イ）前工程ジョブ名（０５、１９、３３行目）には、属性「ジョブ名」で指定されたジョブよりも先に実行すべきジョブの名前のリストが指定される。ここで指定されたジョブの処理ステータスが、属性「ジョブ名」で指定されたジョブの開始判定で参照されることになる。
【００２６】
（ロ）第１の開始時刻（０９、２３、３６行目）には、前工程ジョブ名で指定されたジョブの実行が完了していなくても、属性「ジョブ名」で指定されたジョブを即座に実行指示すべき時刻が指定される。
【００２７】
（ハ）第２の開始時刻（１０、２４、３７行目）には、所定の開始条件を満たした場合に限り、前工程ジョブ名で指定されたジョブが完了していなくても、属性「ジョブ名」で指定されたジョブを実行指示すべき時刻が指定される。この時刻指定は、本発明において特徴的な例外条件の指定であり、第１の開始時刻で指定される時刻よりも前の時刻が指定される。ここで、所定の開始条件とは、後述する第１の待機時間または第２の待機時間に基づく条件であり、端的には前工程ジョブ名で指定されたジョブのステータスを考慮するための条件である。
【００２８】
（ニ）第３の開始時刻（１１、２５行目）には、前工程ジョブ名で指定されたジョブが完了していても、属性「ジョブ名」で指定されたジョブの実行を待機させる場合に参照される時刻が指定される。属性「ジョブ名」で指定されたジョブは、前工程ジョブ名で指定されたジョブの完了後に、この第３の開始時刻に従い、実行指示されることになる。
【００２９】
（ホ）第１の待機時間（０６、２０、３４行目）には、現在時刻が第２の開始時刻で指定される時刻を過ぎており、かつ、前工程ジョブ名で指定されたジョブが開始指示はされていたが処理中でない場合に考慮すべき条件となる時間が指定される。
【００３０】
（へ）第２の待機時間（０７、２１、３３５行目）には、現在時刻が第２の開始時刻で指定される時刻を過ぎており、かつ、前工程ジョブ名で指定されたジョブが処理中であった場合に考慮すべき条件となる時間が指定される。
【００３１】
（ト）第３の待機時間（０８、２２行目）には、前工程ジョブ名で指定されたジョブが完了していても、属性「ジョブ名」で指定されたジョブの実行指示を待機すべき時間が指定される。
・実行ファイル（１３、２７、３９行目）は、ジョブ実行の対象となるファイル名を示す。
・実行時引数（１４、２８、４０行目）は、ジョブ実行時に引数として与える情報を指定する。図１１の例では、｛ＴＩＤ｝｛ＴＺ｝となっている。ＴＩＤはテナントＩＤ、ＴＺは処理対象となる日付を意味する。
【００３２】
図６は、図１１で例示したジョブフロー定義を、概念図で示したものである。
【００３３】
図６では、［カウンタ集計］ジョブ６０４の前工程ジョブとして、［Ａカウンタ取得］ジョブ６０１と［Ｂカウンタ取得］ジョブ６０２が設定されている。［ログ情報の集計］ジョブ６０５の前工程が［ログ情報取得］ジョブ６０３である。また、［レポート作成］ジョブ６０６の前工程が［カウンタ集計］ジョブ６０４と、［ログ情報の集計］ジョブ６０５である。
【００３４】
ここで、［Ａカウンタ取得］ジョブ６０１、［Ｂカウンタ取得］ジョブ６０２、［ログ情報取得］ジョブ６０３などは、図２に示す処理に従い、通常は、事前に設定されたスケジュールに従い実行される。システムのバージョンアップやメンテナンスなどにより、ジョブ実行サーバ１０２などが停止した場合には、これらジョブの開始や完了が遅延する場合がある。
【００３５】
ここで、［カウンタ集計］ジョブ６０４は、図１１で例示したジョブフロー定義においては、前工程となる２つのジョブ処理が完了した後に、その結果を用いて実行されるべきジョブであることがわかる。しかしながら、このフロー定義は、上記した第１の開始時刻または第２の開始時刻に従い、例外的に前工程となる２つのジョブの完了を待たずに［カウンタ集計］ジョブ６０４が実行される場合についても考慮されている。この処理については、図５を用いて、詳細に後述する。
【００３６】
テナント管理部１１５は、管理サーバ１０１に登録されているテナントに関するテナント情報を管理する。テナント管理部１１５が管理するテナント情報は、ＤＢサーバ１０３のテナント管理テーブル１３１、テナント別ジョブ設定テーブル１３２に格納される。
【００３７】
指示部１１６は、スケジュール管理部１１３、及びジョブフロー制御部１１４により指示されたジョブの実行指示の要求を受け付け、テナント別ジョブ設定テーブル１３２を参照した上で、ジョブを実行指示するか否かを判定する。ここで、実行すべきと判定した場合には、ＤＢサーバ１０３のキュー管理テーブル１３５にメッセージを登録することで、ジョブ実行サーバ１０２に対してジョブの実行指示を行う。
【００３８】
ジョブ実行サーバ１０２は、ジョブ制御部１２１、１つ以上のジョブ実行部を備える。図１では、複数のジョブ実行部１２２、１２３が存在している場合の例を示している。
【００３９】
また、管理システム内に、複数のジョブ実行サーバ１０２を用意して、管理サーバ１０１から指示されるジョブを分散して処理することも可能である。また、処理負荷、つまり実行待ちのジョブ数に応じて、ジョブ実行サーバ１０２の起動数を動的に増減させることも可能である。この場合は、実行待ちのジョブ数が多い場合には、２以上のジョブ実行サーバ１０２を起動して、実行待ちのジョブの分散処理を行うことになる。ジョブ実行サーバ１０２の起動は、管理サーバ１０１により制御しても良いし、管理サーバ１０１以外のサーバにより、実行待ちのジョブ数を監視することにより制御してもよい。
【００４０】
ジョブ制御部１２１は、定期的に１つ以上のジョブ実行部の起動および停止を行う。起動されるジョブ実行部１２２、１２３は、キュー管理テーブル１３５を監視し、待機中のメッセージがあれば、そのメッセージに対応するジョブを実行する。
【００４１】
ＤＢサーバ１０３は、テナント管理テーブル１３１、テナント別ジョブ設定テーブル１３２、バッチジョブ管理テーブル１３３、スケジュールジョブ管理テーブル１３４、キュー管理テーブル１３５などのテーブルを備える。
【００４２】
図８は、テナント管理テーブル１３１の例を示す。テナント管理テーブル１３１は、管理サーバ１０１に、テナントとして登録されている顧客の情報を管理するためのテーブルである。ここで、テナントとして管理される顧客とは、ジョブに関連する機器などを利用、管理する顧客である。
【００４３】
テナントＩＤ８０１は、システム内でテナントを識別するため一意の識別情報（ＩＤ）である。タイムゾーン８０２は、テナントに設定された時差情報であり、各テナントに関連して実行するジョブのスケジュール制御の時に、参照される。サービス種別８０３には、テナントに提供されているサービスの種別が設定される。サービス種別８０３を参照することで、テナントに関連してどのジョブを実行するかを判定できる。
【００４４】
例えば、行８１１は、テナントＩＤが“１２３ＡＡ”であり、タイムゾーンが“ＧＭＴ＋０９：００”であり、提供すべきサービスが“カウンタ（サービス）”と“ログ情報（サービス）”であるテナントを示す。ここで、カウンタサービスとは、テナントとして登録された顧客のネットワーク機器から収集されたカウンタ情報を取得して、集計して、顧客にレポートするといったサービスである。同様に、ログ情報サービスとは、テナントとして登録された顧客のネットワーク機器から収集された各種ログ情報を取得して、集計して、顧客にレポートするといったサービスである。
【００４５】
図９は、テナント別ジョブ設定テーブル１３２の例を示す。テナント別ジョブ設定テーブル１３２は、各テナントに対して、どのジョブを実行するかの設定を管理するテーブルである。
【００４６】
テナントＩＤ９０１は、システム内でテナントを識別するため一意のＩＤである。ジョブ名９０２は、ジョブの種別を識別できるジョブの名前である。実行設定９０３は、各テナントで各ジョブを実行する否かの設定を格納する。
【００４７】
例えば、行９１１〜９１３は、テナントＩＤが“１２３ＡＡ”について、「Ａカウンタ取得」で示すジョブを実行する設定であり、「Ｂカウンタ取得」で示すジョブを実行する設定であり、かつ、「ログ情報取得」で示すジョブを実行する設定であることを示す。
【００４８】
テナント管理テーブル１３１で管理する情報、およびテナント別ジョブ設定テーブル１３２で管理する設定情報は、ＵＩ制御部１１２により提供されるＵＩを用いて、管理システムを利用するユーザにより登録、編集が可能である。
【００４９】
図１２は、バッチジョブ管理テーブル１３３の例を示す。
【００５０】
テナントＩＤ１２０１は、システム内でテナントを識別するため一意のＩＤである。ジョブ名１２０２は、ジョブの種別を識別できるジョブの名前である。
【００５１】
対象日付１２０３は、ジョブの実行すべき年月日を示す。この年月日は、後述する図２のＳ２０７、またはＳ２０８の処理で求められる次回の実行日時を示す変数ＮＴの値から、時刻情報を示す一部の情報を削除した値である。
【００５２】
実行指示日時１２０４は、ジョブの実行指示が行われた日時を示し、後述する図３のＳ３０３、またはＳ３０４の処理が実行された日時が設定される。処理開始日時１２０５には、ジョブ実行部１２２、１２３により、該当ジョブの処理が開始された日時が設定される。初期状態は空である。完了日時１２０６には、ジョブ実行部１２２、１２３でジョブ処理が完了した日時が設定される。なお、後述する図３のＳ３０２の判定を受けて該当ジョブが処理されない場合には、Ｓ３０３の処理が実行された日時が設定される。ステータス１２０７は、該当ジョブの状態を、開始待ち、処理中、正常終了、異常終了のいずれかで示す。
【００５３】
図１４は、キュー管理テーブル１３５の例を示す。このテーブルにより、ジョブ実行サーバ１０２の処理対象となったジョブに対応するメッセージが管理される。
【００５４】
メッセージＩＤ１４０１は、キューに登録されたメッセージを一意に識別するための識別情報である。メッセージの配信先１４０２は、メッセージを処理すべきジョブ実行部を特定するための情報を示す。例えば、本例では、ジョブの種別ごとにジョブ実行部を用意することを想定している。従って、メッセージの配信先１４０２には、ジョブの種別を識別できるジョブ名が設定されている。メッセージ状態１４０３は、本テーブルに登録されたメッセージのステータスを示す。ステータスとしては、「開始待ち」、「処理中」、「完了」がある。「開始待ち」とは、メッセージがキュー管理テーブル１３５に登録され、ジョブ実行部により取得されていない間の状態を示す。「処理中」とは、ジョブ実行部がメッセージを取得し、ジョブを処理している間の状態を示す。「完了」とは、ジョブ実行部がジョブの処理を完了した状態を示す。メッセージ内容１４０４には、当該メッセージに対応するジョブに関する情報が設定される。その設定内容には、少なくとも、図示されるように、テナントＩＤと処理日に係る情報が含まれる。
【００５５】
［ジョブの実行制御の詳細］
図２は、管理サーバ１０１のスケジュール管理部１１３によるジョブの実行スケジュールの制御に関する処理を説明するためのフローチャートを示す。起動制御部１１１がスケジュール管理部１１３を起動することにより、本処理は開始される。
【００５６】
Ｓ２０２において、スケジュール管理部１１３は、スケジュール定義ファイル１４１を参照し、スケジュールされたジョブの一覧を取得する。スケジュール管理部１１３は、スケジュール定義ファイル１４１に定義されたジョブを、スケジュールジョブの一覧として取得する。
【００５７】
Ｓ２０３において、スケジュール管理部１１３は、テナント管理テーブル１３１よりテナント情報に関する一覧を取得する。次に、Ｓ２０４〜Ｓ２１４について、Ｓ２０２で取得した一覧に含まれるスケジュールジョブごとに以下の処理を繰り返す。さらに、Ｓ２０５〜Ｓ２１３について、Ｓ２０３で取得した一覧に含まれるテナント情報ごとに以下の処理を繰り返す。
【００５８】
Ｓ２０６で、スケジュール管理部１１３は、処理対象となるスケジュールジョブの「起動周期」属性を判別する。図１０の例では、「ＤＡＩＬＹ」であればＳ２０７へ進み、「ＭＯＮＴＨＬＹ」であればＳ２０８に進む。ここで、Ｓ２０７及びＳ２０８では、テナント毎に各スケジュールジョブの次回実行すべき日時を示す変数ＮＴ（次回の実行日時）を計算する。
【００５９】
Ｓ２０７では、スケジュール管理部１１３は、変数ＮＴに対して、（現在年月日＋起動時刻）を設定する。起動時刻は、処理対象のスケジュールジョブの「起動時刻」属性の値である。これは、スケジュールジョブの次回実行すべき日時として、現在の年月日の「起動時刻」属性で示す時刻が指定されたことを示す。また、この指定は、処理対象テナントのタイムゾーンにて指定される。Ｓ２０８では、スケジュール管理部１１３は、変数ＮＴに対して、（現在年月＋起動日＋起動時刻）を設定する。起動日、起動時刻は、それぞれ処理対象のスケジュールジョブの「起動日」、「起動時刻」属性の値である。
【００６０】
Ｓ２０９で、スケジュール管理部１１３は、現在日時、既定時間、及び変数ＮＴの値（次回の実行日時）を用いた比較処理を行う。具体的には、現在日時が、変数ＮＴで示す日時を過ぎており、かつ、変数ＮＴで示す日時から既定時間を経過していないかを判定する。ここで、現在日時が、変数ＮＴで示す日時を過ぎており、かつ、変数ＮＴで示す日時から既定時間を経過していないと判定された場合にはＳ２１０に進み、それ以外はＳ２１３に進む。ここで、Ｓ２１０に進む場合には、処理対象となっているスケジュールジョブが、現在日時において実行指示の候補となることを意味する。
【００６１】
Ｓ２１０では、スケジュール管理部１１３は、ジョブの重複実行を避けるため、処理対象のスケジュールジョブが実行指示されているか否かを判定する。ここでは、処理対象のテナントのテナントＩＤと、処理対象のスケジュールジョブとジョブ名と、変数ＮＴの値と、スケジュールジョブ管理テーブル１３４の内容と、を参照して、判定する。
【００６２】
図１３は、スケジュールジョブ管理テーブル１３４の構成の例を示す。このテーブルでは、各テナント、各ジョブの最終実行履歴が記録、管理されている。
【００６３】
テナントＩＤ１３０１は、テナントを識別する識別情報を示す。ジョブ名１３０２は、ジョブを識別する名前を示す。最終の実行指示日時１３０３は、テナントＩＤ１３０１でジョブ名１３０２のジョブが実行指示された日時が設定される。例えば、行１３１１は、テナントＩＤ「１２３ＡＡ」について、ジョブ「Ａカウンタ取得」が、「２０１４−０４−０６  ００：３０」に実行指示されたことを示す。
【００６４】
Ｓ２１０では、処理対象のテナントＩＤ、ジョブ名がともに一致するレコードをスケジュールジョブ管理テーブル１３４から特定する。特定できた場合に、最終の実行指示日時１３０３の値と変数ＮＴの値とから、既に実行指示済みであるかを判定する。ここで、既に実行指示されていたと判定された場合にはＳ２１３に進み、まだ実行指示されていないと判定された場合にはＳ２１１に進む。
【００６５】
Ｓ２１１で、スケジュール管理部１１３は、スケジュールジョブの実行指示の処理（図３）を呼び出す。続いて、Ｓ２１２において、スケジュール管理部１１３は、スケジュールジョブ管理テーブル１３４に対して、処理対象のテナントＩＤ、ジョブ名、実行指示した現在日時を用いて、最終実行履歴を追加もしくは更新する。
【００６６】
全てのテナント、スケジュールジョブについて本処理を適用した後に、Ｓ２１３及びＳ２１４を抜けて、本処理を終了する。
【００６７】
続いて、図３のフローチャートを用いて、ジョブの実行指示のための処理を説明する。本処理は、前述のＳ２１１で呼び出され、指示部１１６により実行される。
【００６８】
Ｓ３０２において、指示部１１６は、テナント別ジョブ設定テーブル１３２を参照して、処理対象のテナントが、処理対象のジョブの実行対象となるかを判定する。テナント別ジョブ設定テーブル１３２から、処理対象のテナントと、処理対象のジョブとに対応するレコードを特定し、実行設定９０３が「実行する」に設定されている場合には、実行対象となると判定して、Ｓ３０４に進む。そうでない場合にはＳ３０３に進む。
【００６９】
Ｓ３０３では、指示部１１６は、処理対象のジョブに関するジョブ情報を、バッチジョブ管理テーブル１３３に記録する。ここでは、処理対象のジョブを実行しない設定であったため、バッチジョブ管理テーブル１３３には、ステータス「正常終了」であるジョブ情報を示すレコードが追加される。処理対象のジョブの完了を待って開始されるようスケジュールされたジョブがあった場合に、この後続のジョブを開始してよいことを明示的に示すために、Ｓ３０３でレコードが追加される。
【００７０】
Ｓ３０４では、指示部１１６は、処理対象のジョブに関するジョブ情報を、バッチジョブ管理テーブル１３３に記録する。ここでは、ステータス「実行待ち」でありジョブ情報を示すレコードを追加する。同レコードの実行指示日時１２０４には、現在日時を設定し、処理開始日時１２０５、完了日時１２０６は未設定とする。
【００７１】
Ｓ３０５で、指示部１１６は、ジョブの実行を指示するために、キュー管理テーブル１３５にメッセージを登録する。キュー管理テーブル１３５にメッセージが登録された場合に、ジョブ実行部１２２などにより、当該メッセージに対応するジョブが実行されることになる。ここでは、例えば、図１４の行１４１１に示す情報が、メッセージとして登録される。具体的には、メッセージの配信先１４０２としてジョブ名：「Ａカウンタ集計」、メッセージ内容としてテナントＩＤ：「１２３ＡＡ」、処理日：「２０１４−０４−０６（現在の年月日）」といった内容のメッセージが登録されている。なお、メッセージＩＤとメッセージ状態については、システム側で自動設定されるものとする。
【００７２】
その後、Ｓ３０６で、本処理を終了して、図２の処理に戻る。
【００７３】
図４のフローチャートを用いて、ジョブ実行サーバ１０２のジョブ実行部１２２、１２３などで実行されるジョブの実行処理について説明する。ジョブ制御部１２１が、定期的に、ジョブ実行部１２２、１２３のいずれか、または両方を起動することにより、起動されたジョブ実行部が、以下で説明する処理を開始する。
【００７４】
Ｓ４０２において、ジョブ実行部が、ジョブ実行の停止命令があるかを判定する。この停止命令は、ジョブ制御部１２１からジョブ実行部に送信される。たとえば、バージョンアップやメンテナンスなどを目的に、ジョブ実行サーバ１０２自体を停止する場合に、ジョブ処理の開始を強制的に停止するために、この停止命令が送信される。ここで、ジョブ実行部は、停止命令が無ければＳ４０３に進み、停止命令があれば本処理を終了する。ジョブ制御部１２１は、ジョブ実行サーバ１０２自体の安全な停止のために、起動した全てのジョブ実行部による処理が停止されたことを確認する。この確認が行われた後に、ジョブ実行サーバ１０２の停止処理が実行されることになる。
【００７５】
Ｓ４０３では、ジョブ実行部が、キュー管理テーブル１３５よりメッセージを取得する。取得対象のメッセージは、メッセージ状態１４０３が「開始待ち」のメッセージである。さらに、ジョブ実行部に実行対象とするジョブの種別を割り当てられている場合には、該当する情報がメッセージの配信先１４０２に設定されているメッセージを取得対象とする。
【００７６】
Ｓ４０４では、ジョブ実行部が、Ｓ４０３でメッセージが取得されたか否かを判定する。取得された場合にはＳ４０６に進み、取得されなかった場合にはＳ４０５に進む。Ｓ４０５では既定の時間待機したのち、Ｓ４０２に戻る。
【００７７】
Ｓ４０６で、ジョブ実行部が、バッチジョブ管理テーブル１３３において、取得されたメッセージに対応するジョブのステータス１２０７を「処理中」に変更する。ここでは、ジョブの属性情報（ジョブ種別、テナントＩＤなど）が一致するレコードのステータスが変更される。続いて、Ｓ４０７で、キュー管理テーブル１３５において、取得されたメッセージに関する状態１４０３を「処理中」に変更する。
【００７８】
Ｓ４０８で、ジョブ実行部が、取得されたメッセージに対応するジョブを実行する。ジョブ実行部は、不図示のジョブ処理モジュールを呼び出し、ジョブを実行する。
【００７９】
なお、ジョブ実行部１２２、１２３が、Ｓ４０３の処理の際に、ジョブ種別に関わらず順番にメッセージを取得して、対応するジョブを処理するように設計することもできる。この場合、Ｓ４０８では、ジョブ実行部が、取得メッセージのジョブ種別を特定し、そのジョブ種別用のジョブ処理モジュールを動的に呼び出すことにより、ジョブを実行することになる。
【００８０】
Ｓ４０９で、ジョブ実行部が、ジョブ処理が終了すると、ジョブ処理が成功したか否か判定する。成功していた場合にはＳ４１０に進み、失敗していた場合にはＳ４１１に進む。Ｓ４１０で、ジョブ実行部が、バッチジョブ管理テーブル１３３の該当するジョブ情報のステータス１２０７を「正常終了」に変更する。Ｓ４１１で、ジョブ実行部は、バッチジョブ管理テーブル１３３の該当するジョブ情報のステータス１２０７を「異常終了」に変更する。
【００８１】
Ｓ４１２で、ジョブ実行部が、キュー管理テーブル１３５から取得したメッセージを削除する。キューの管理方法によるが、ここでメッセージの状態１４０３を「終了」に変更するようにすることもできる。その後、処理はＳ４０２に戻る。
【００８２】
なお、キュー管理テーブル１３５で処理開始時間をさらに記録し、管理するようにしてもよい。この場合には、Ｓ４０７で、ジョブ実行部が、処理開始時間を現在時刻として設定する。そして、その後にジョブ実行部がＳ４０３に至った場合に、処理開始時間から所定の時間を過ぎても、その処理が終了しない場合には、そのメッセージを再取得するようにしてもよい。これにより、ジョブ処理が異常停止してしまった場合であっても、例外的に、そのジョブに対応するメッセージを処理対象とすることができる。
【００８３】
以上までが、スケジュール定義ファイル１４１に定義されたスケジュールに従う、ジョブの実行制御の詳細処理の説明である。
【００８４】
［ジョブのフロー制御］
図５のフローチャートを用いて、管理サーバ１０１のジョブフロー制御部１１４で実行されるジョブフローの制御に関する処理を説明する。本処理は、起動制御部１１１より定期的にジョブフロー制御部１１４が起動されることにより、開始される。
【００８５】
Ｓ５０２では、ジョブフロー制御部１１４は、ジョブフロー定義ファイル１４２を読み込み、ジョブフローの一覧を取得する。図１１の例では、前述の通り３つのジョブフローの定義があり、ここでは３つのジョブフローを含む一覧が取得されることになる。続いて、Ｓ５０３で、ジョブフロー制御部１１４は、テナント管理テーブル１３１よりテナント情報に関する一覧を取得する。テナント情報には、テナントＩＤ８０１とタイムゾーン８０２が含まれている。以下で説明する判定処理で用いる時刻については、このテナント毎のタイムゾーンに従うものとする。
【００８６】
次に、Ｓ５０４〜Ｓ５２３について、Ｓ５０２で取得した一覧に含まれるジョブフローごとに以下の処理を繰り返す。繰り返し処理では、ジョブフローの定義の中で、より前工程となるジョブから順に処理する。たとえば図６で示したように、［レポート作成］６０６ジョブは、前工程として［カウンタ集計］６０４、［ログ情報集計］６０５をもっている。このような場合には、［レポート作成］６０６ジョブよりも［カウンタ集計］６０４、［ログ情報集計］６０５が先に実行されるようにリスト内での処理順を制御し、その処理順に応じて繰り返し処理を行うことにより［レポート作成］６０６の処理を後に行うことができる。さらに、Ｓ５０５〜Ｓ２２２について、Ｓ５０３で取得した一覧に含まれるテナント情報ごとに以下の処理を繰り返す。
【００８７】
Ｓ５０６で、ジョブフロー制御部１１４は、現在時刻が、処理対象のジョブフローの第１の開始時刻を経過しているかを判定する。第１の開始時刻を経過していると判定された場合にはＳ５０７に進み、そうでない場合にはＳ５０８に進む。ここでの判定によりＳ５０７に進む場合には、前工程として定義されているジョブのステータスなどを考慮せずに、その後工程として定義されるジョブが強制的に実行されることになる。
【００８８】
Ｓ５０７では、ジョブフロー制御部１１４は、処理対象のジョブフローに定義される属性「ジョブ名」で指定されたジョブの実行を要求する。ここでは、指示部１１６を呼び出すことにより、図３で示したジョブの実行指示の処理が行われる。
【００８９】
Ｓ５０８では、ジョブフロー制御部１１４は、バッチジョブ管理テーブル１３３から、前工程として定義されているジョブのジョブ情報を取得する。ジョブ情報にはジョブの進捗を示すステータス情報も含まれている。ここで処理対象のジョブフローが、例えば、図１１の０２〜１５行目で定義されたジョブフローであれば、前工程ジョブは、０５行目に設定されている［Ａカウンタ取得］ジョブと［Ｂカウンタ取得］ジョブである。本繰り返し処理での処理対象であるテナント情報と、バッチジョブ管理テーブル１３３のテナントＩＤ１２０１が一致しているレコードの中から、対象日付１２０３、ジョブ名１２０２により、取得すべきジョブ情報が特定できる。例えば、前工程ジョブの［Ａカウンタ取得］ジョブと［Ｂカウンタ取得］ジョブについて、図１２で示すバッチジョブ管理テーブル１３３の、行１２１１および行１２１２の２つの情報が取得されることになる。
【００９０】
このＳ５０８に至る時刻までに前工程ジョブが実行指示されていない場合、バッチジョブ管理テーブル１３３にはその前工程ジョブのレコードは登録されていない。そのような場合には、ジョブフロー制御部１１４は、その前工程ジョブのステータス「実行未指示」として扱う。
【００９１】
Ｓ５０９では、ジョブフロー制御部１１４は、前工程ジョブの全てが完了しているかを判定する。ここで完了を示すステータスは、正常終了または異常終了である。前工程ジョブの全てが完了していればＳ５１０へ進み、未完了であればＳ５１４に進む。
【００９２】
Ｓ５１０では、ジョブフロー制御部１１４は、現在時刻が、処理対象のジョブフローの第３の開始時刻を経過しているかを判定する。また、ジョブフロー制御部１１４は、現在時刻が、前工程ジョブの終了時刻からさらに処理対象のジョブフローの第３の待機時間を考慮した時刻を経過しているかを判定する。この両方の条件について、経過していると判定された場合には、Ｓ５０７に進み、
処理対象のジョブフローのジョブ名で設定されるジョブ（後工程のジョブ）が実行されることになる。Ｓ５１０でいずれかの条件を満たさない場合にはＳ５２２に進む。
【００９３】
なお、処理対象のジョブフローに第３の開始時刻の設定が無い場合は、Ｓ５１０での第３の開始時刻を用いた判定は無視され、もう一方の判定条件のみが考慮される。また、第３の待機時間が設定されていない場合には、Ｓ５１０では第３の待機時間を０時間として扱うものとする。また、前工程ジョブが複数ある場合には、すべての前工程ジョブ、またはもっとも最後に処理が完了したジョブの終了時刻と、第３の待機時間とを用いて判定を行うものとする。
【００９４】
Ｓ５１４では、ジョブフロー制御部１１４は、現在時刻が、処理対象のジョブフローの第２の開始時刻を過ぎているかを判定する。第２の開始時刻を経過していると判定された場合にはＳ５１５に進み、そうでない場合にはＳ５２２に進む。
【００９５】
Ｓ５１５〜Ｓ５２０については、前工程ジョブの中で未完了のジョブについて、以下の処理を繰り返し行う。
【００９６】
Ｓ５１６では、ジョブフロー制御部１１４は、処理対象である前工程のジョブのステータスを判別する。ここでは、Ｓ５０８で取得されたジョブ情報を参照する。ステータスが「実行未指示」であればＳ５１７へ、「開始待ち」であればＳ５１８へ、「処理中」であればＳ５１９に進む。
【００９７】
Ｓ５１７では、ジョブフロー制御部１１４は、開始時刻リストに、処理対象のジョブフローに属性として設定されている「第２の開始時刻」を追加する。
【００９８】
Ｓ５１８では、ジョブフロー制御部１１４は、開始時刻リストに、処理対象である前工程のジョブのジョブ情報で示す実行指示日時１２０４に、処理対象のジョブフローに属性として設定されている「第１の待機時間」をさらに考慮した時刻を追加する。
【００９９】
Ｓ５１９では、ジョブフロー制御部１１４は、開始時刻リストに、処理対象である前工程のジョブのジョブ情報で示す処理開始日時１２０５に、処理対象のジョブフローに属性として設定されている「第２の待機時間」をさらに考慮した時刻を追加する。
【０１００】
Ｓ５２０で、前工程ジョブの中で未完了のジョブの全てに対して処理が終了すると、Ｓ５２１に進む。Ｓ５２１では、ジョブフロー制御部１１４は、現在時刻が、開始時刻リストに追加されたいずれかの時刻を過ぎているか判定する。ジョブフロー制御部１１４により、開始時刻リストに追加されたいずれかの時刻を過ぎていると判定された場合にはＳ５０７に進み、過ぎていないと判定された場合にはＳ５２２に進む。
【０１０１】
Ｓ５１５〜Ｓ５２１までの処理により、前工程の未完了ジョブについて、全く実行指示がおこなわれていない場合には、それらジョブの処理を一切待機せずに、その後工程となるジョブが実行されることになる。一方で、前工程の未完了ジョブが既に開始待ちや処理中のステータスであった場合には、ジョブフロー定義ファイル１４２に含まれるジョブフローの属性で設定される待機時間に従い、その後工程となるジョブの実行が待機されることになる。
【０１０２】
Ｓ５２２で全てのテナントに対して繰り返し処理が終了していた場合にはＳ５２３に進む。Ｓ５２３で全てのジョブフローに対して繰り返し処理が終了していた場合には本処理を終了する。
【０１０３】
ここで、具体例を挙げて説明を行う。
【０１０４】
まず、現在時刻が２０１４−０４−０６：０６：４０とする。［カウンタ集計］ジョブについて、ジョブフローの定義としての第１の開始時刻「２１：００」は過ぎていないため、Ｓ５０６（ＮＯ）で、Ｓ５０８へ処理が進む。前工程ジョブの［Ａカウンタ取得］、［Ｂカウンタ取得］ジョブは、完了していないためＳ５０９（ＮＯ）と判定される。現在時刻が第２の開始時刻「０６：００」を過ぎているため、Ｓ５１４（ＹＥＳ）と判定され、Ｓ５１５に進む。未完了の前工程ジョブである［Ａカウンタ取得］ジョブ、［Ｂカウンタ取得］ジョブは、Ｓ５１５〜Ｓ５２０の繰り返し処理の対象となる。前工程の［Ａカウンタ取得］ジョブは、ステータスが「処理中」である。このため、Ｓ５１９で、開始時刻リストに対して、［Ａカウンタ取得］ジョブの処理開始日時「２０１４−０４−０６  ０６：３５」に第２の待機時間（６０分）を加算した、「２０１４−０４−０６  ０７：３５」が追加される。また、前工程の［Ｂカウンタ取得］ジョブは、ステータスが「開始待ち」である。このため、Ｓ５１８で、開始時刻リストには、［Ｂカウンタ取得］ジョブの実行指示日時「２０１４−０４−０６  ０１：００」に第１の待機時間（１２０分）を加算した、「２０１４−０４−０６  ０３：００」が追加される。Ｓ５２１では、現在時刻が、Ｓ５１８で追加された「２０１４−０４−０６  ０３：００」を経過しているので、Ｓ５０７に進み、［カウンタ集計］ジョブの実行指示が呼び出される。
【０１０５】
［本実施例における効果］
本実施例では、前工程の完了を待たずに後工程のジョブを実行指示すべき２種類の開始時刻（第１の開始時刻と第２の開始時刻）を定義している。
【０１０６】
例えば、メンテナンスなどで停止していたジョブ実行サーバ１０２が、第１の開始時刻と第２の開始時刻との間で復旧した場合には、前工程のジョブの処理ステータスを考慮した上で後工程のジョブの実行指示が制御されることになる。つまり、本実施例では、ジョブフローに含まれるいくつかのジョブの処理の進捗が遅れた場合でも、段階的に、後工程のジョブの実行指示を強制するようにしている。これにより、管理者などが定義したジョブフローの順番制御などを可能な限り維持しつつも、ジョブフロー全体として、処理の開始が厳守すべき期限までに一切行われていないといったことも抑制できる。
【０１０７】
（実施例２）
実施例１の変形例として、図５のＳ５２１において、現在時刻が、開始時刻リストに追加された全ての時刻を過ぎているかを判定する、といったことも考えられる。ここでは、現在時刻が、開始時刻リストに追加された全ての時刻を過ぎていると判定された場合のみＳ５０７に進むものとする。
【０１０８】
この変更により、「開始待ち」ステータスの前工程のジョブについての第１の待機時間、または、「処理中」ステータスの前工程のジョブについての第２の待機時間を考慮した時刻まで、後工程となるジョブの実行指示を見合わせることができる。
【０１０９】
つまり、本実施例は、実施例１よりも、ジョブフローの実行順がより維持されることになる。実行順の影響が大きいサービスに関連するジョブフローの場合には、本実施例における変更が有効である。
【０１１０】
また、実施例１と本実施例との切り換えのための条件を、ジョブフロー定義ファイル１４２の各ジョブフローの定義に前工程ジョブの待機条件として追加してもよい。この場合には、ジョブフロー制御部１１４が、実施例１の図５のＳ５２１のタイミングで、この待機条件を確認して、処理を切り換えることになる。
【０１１１】
（実施例３）
実施例１の変形例として、図５のＳ５１５〜Ｓ５２０において、特定の未完了の前工程ジョブのみを対象とする、といったことも考えられる。この場合は、ジョブフロー定義ファイル１４２の各ジョブフローの定義に前工程ジョブの待機条件として、対象とする前工程ジョブを指定することで実現できる。なお、ジョブフロー制御部１１４は、指定されていた前工程ジョブが完了していた場合には、Ｓ５１５〜Ｓ５２１の処理をスキップして、Ｓ５０７に進むことになる。
【０１１２】
（実施例４）
本実施例では、上記した実施例に加えて、さらに図５で処理対象となったジョブフローの前工程ジョブとして定義されるジョブが、さらに別のジョブフローの定義に含まれる場合も考慮する。具体的には、本実施例は、図５のＳ５１６で「実行未指示」ステータスであったジョブについて、当該ジョブを含む別のジョブフローで定義されるその前工程ジョブのステータスについても更に考慮することになる。
【０１１３】
例えば、テナントＩＤ「１２３ＡＡ」の［レポート作成］ジョブに係るジョブフロー（図１１の行３０〜４１）を処理対象とした場合を想定する。テナントＩＤ「１２３ＡＡ」のタイムゾーンであるＧＭＴ＋０９：００において、現在時刻が「２０１４−０４−０６：０６：３０」とする。
【０１１４】
［レポート作成］ジョブの前工程ジョブは、［カウンタ集計］ジョブと［ログ情報の集計］ジョブである。なお、［カウンタ集計］ジョブのステータスは「開始待ち」を示す（図１２  行１２１４）。［ログ情報の集計］ジョブのステータスは［実行未指示］である（図１２  行１２１５）。
【０１１５】
ここで、［ログ情報の集計］ジョブの前工程である［ログ情報取得］ジョブのステータスは「処理中」であり、処理開始日時が「２０１４−０４−０６：０６：１０」である。この場合、［ログ情報取得］ジョブについて、図５のＳ５１９の処理が適用される。よって、開始時刻リストに、処理開始日時に第２の待機時間（１２０分）を加えた「２０１４−０４−０６  ０８：１０」が追加される。従って、現在時刻が、開始時刻リストに追加された時刻を過ぎていないと判定される。このため、［ログ情報の集計］ジョブは、前工程ジョブの状態を考慮して、その実行指示が一旦待機されていることになる。
【０１１６】
このような場合、［ログ情報の集計］ジョブが前工程ジョブの状態を考慮してジョブ実行を見合わせたにもかかわらず、［レポート作成］ジョブが［ログ情報の集計］ジョブの完了を待たずに実行されてしまうことになる。
【０１１７】
よって、本実施例では、［レポート作成］ジョブに係るジョブフローを処理対象とした場合に、Ｓ５１５〜Ｓ５２１について、［実行未指示］ステータスの［ログ情報の集計］ジョブの前工程である［ログ情報取得］ジョブも処理の対象とする。
【０１１８】
本実施例によれば、上記した他の実施例より、さらに、管理者などが定義したジョブフローの順番制御などを維持することが可能になる。
【０１１９】
（実施例５）
本実施例は、実施例４の変形例である。具体的には、［実行未指示］ステータスのジョブの前工程ジョブのステータスにより、Ｓ５１８やＳ５１９に進んだ際に、その処理を以下のように変更する。
【０１２０】
Ｓ５１８では、処理対象のジョブフローの定義で設定される第１の待機時間と、［実行未指示］ステータスのジョブに係るジョブフローの定義で設定される第１の待機時間と、を実行指示時刻に加える。また、Ｓ５１９では、処理対象のジョブフローの定義で設定される第２の待機時間と、［実行未指示］ステータスのジョブに係るジョブフローの定義で設定される第２の待機時間と、を処理開始時刻に加える。
【０１２１】
本実施例では、結果的に、［レポート作成］ジョブに係るジョブフローを処理対象としている場合には、Ｓ５１９において、［ログ情報取得］ジョブの処理開始日時「２０１４−０４−０６  ０６：１０」に２４０分を加算した「２０１４−０４−０６  １０：１０」を開始時刻リストに追加することになる。その後のＳ５２１では、現在時刻がその時刻を過ぎていないため、ＮＯと判定される。
【０１２２】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
【０１２３】
ここで、本発明は、上述した実施形態の機能を実現する１以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の一つである。また、そのプログラムは、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給され、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の一つとして、さらにそのプログラム自体、あるいは該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【０１２４】
１００  管理システム
１０１  管理サーバ
１０２  ジョブ実行サーバ
１０３  ＤＢサーバ
【図１】
2016004305.tif 000003
【図２】
2016004305.tif 000004
【図３】
2016004305.tif 000005
【図４】
2016004305.tif 000006
【図５】
2016004305.tif 000007
【図６】
2016004305.tif 000008
【図７】
2016004305.tif 000009
【図８】
2016004305.tif 000010
【図９】
2016004305.tif 000011
【図１０】
2016004305.tif 000012
【図１１】
2016004305.tif 000013
【図１２】
2016004305.tif 000014
【図１３】
2016004305.tif 000015
【図１４】
2016004305.tif 000016