(57)【要約】【課題】  業務システムが何らかの障害で深夜処理をできない場合などの状況に対応し、自動的に再処理を行い、また処理結果のデータに対して適切な更新日時を付与することが可能な日付管理の仕組みを提供する。【解決手段】  バッチ処理を実行するにあたり、システム日付とは異なる日付でバッチを処理するための仮想処理日を記憶する。バッチ処理起動時には、ログ情報記憶手段に過去の異常終了したバッチ処理がある場合には、またスケジューラにおいて未実行であり既に起動時間が経過しているバッチ処理がある場合には、対応する仮想処理日における処理として実行する。監視部は、バッチ処理を監視して異常終了した場合には、異常終了した旨と再実行する際の処理開始位置と、ログ情報記憶手段に記憶し、後の再開を待つ。【選択図】図８
2014071751.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションサーバとネットワークを介して接続可能であり、アプリケーションサーバにおけるバッチ処理の実行に関わる日付を制御する日付管理装置であって、
前記日付管理装置によりスケジュール管理されるバッチ処理と、該バッチ処理の起動の日時と、をスケジュール情報として記憶するスケジュール記憶手段と、
前記バッチ処理を実行するにあたり、システムが管理する日付とは異なる日付で該バッチを処理するための仮想処理日を記憶する仮想処理日記憶手段と、
前記バッチ処理の終了状態と、該バッチ処理の実処理日と、をログ情報として記憶するログ情報記憶手段と、
前記ログ情報記憶手段において、終了状態が未完了である前記バッチ処理、および前記スケジュール記憶手段における前記スケジュール情報の日時を経過している未実行の該バッチ処理を、順序に従って起動し、前記仮想処理日記憶手段に記憶された該バッチ処理に対応する前記仮想処理日における処理として実行するバッチ処理起動手段と、
前記バッチ処理起動手段で起動された前記バッチ処理からの通知を監視する監視手段と、
前記監視手段により監視する該バッチ処理が異常終了した場合には、ログ情報記憶手段に、該バッチ処理が異常終了した旨と、再実行する際の処理開始位置と、を登録するログ情報登録手段と、
を備えることを特徴とする日付管理装置。
【請求項２】
前記監視手段により監視する該バッチ処理が正常終了したと判定された場合には、前記仮想処理日記憶手段に、前記バッチ処理の次回の実行の前記仮想処理日を記憶する仮想処理日登録手段と、を更に備え、
ログ情報登録手段は、
前記監視手段により監視する該バッチ処理が正常終了したと判定された場合には、該バッチ処理が正常終了した旨を、前記ログ情報記憶手段に登録することを特徴とする請求項１に記載の日付管理装置。
【請求項３】
前記バッチ処理起動手段において、前記バッチ処理を起動する順序とは、前記仮想処理日が古い順序であって、且つ、同一の該仮想処理日である場合には、前記スケジュール情報における日時、および該スケジュール情報に先行バッチとして順序関係が記載されている場合には、その順序に従うことを特徴とする請求項１または請求項２に記載の日付管理装置。
【請求項４】
アプリケーションサーバとネットワークを介して接続可能であり、アプリケーションサーバにおけるバッチ処理の実行に関わる日付を制御する日付管理装置の制御方法であって、
スケジュール登録手段が、前記日付管理装置によりスケジュール管理されるバッチ処理と、該バッチ処理の起動の日時と、をスケジュール情報としてスケジュール記憶手段に記憶させるスケジュール登録ステップと、
仮想処理日登録手段が、前記バッチ処理を実行するにあたり、システムが管理する日付とは異なる日付で該バッチを処理するための仮想処理日を仮想処理日記憶手段に記憶させる仮想処理日登録ステップと、
ログ情報登録手段が、前記バッチ処理の終了状態と、該バッチ処理の実処理日と、をログ情報としてログ情報記憶手段に記憶させるログ情報登録ステップと、
バッチ処理起動手段が、前記ログ情報記憶手段において、終了状態が未完了である前記バッチ処理、および前記スケジュール記憶手段における前記スケジュール情報の日時を経過している未実行の該バッチ処理を、順序に従って起動し、前記仮想処理日記憶手段に記憶された該バッチ処理に対応する前記仮想処理日における処理として実行するバッチ処理起動ステップと、
監視手段が、前記バッチ処理起動ステップで起動された前記バッチ処理からの通知を監視する監視ステップと、
ログ情報登録手段が、前記監視ステップにより監視する該バッチ処理が異常終了した場合には、ログ情報記憶手段に、該バッチ処理が異常終了した旨と、再実行する際の処理開始位置と、を登録するログ情報登録ステップと、
を備えることを特徴とする日付管理装置の制御方法。
【請求項５】
コンピュータを、アプリケーションサーバとネットワークを介して接続可能であり、アプリケーションサーバにおけるバッチ処理の実行に関わる日付を制御する日付管理装置として機能させるためのプログラムであって、
前記コンピュータを、
前記日付管理装置によりスケジュール管理されるバッチ処理と、該バッチ処理の起動の日時と、をスケジュール情報としてスケジュール記憶手段に記憶させるスケジュール登録手段、
前記バッチ処理を実行するにあたり、システムが管理する日付とは異なる日付で該バッチを処理するための仮想処理日を仮想処理日記憶手段に記憶させる仮想処理日登録手段、
前記バッチ処理の終了状態と、該バッチ処理の実処理日と、をログ情報としてログ情報記憶手段に記憶させるログ情報登録手段、
前記ログ情報記憶手段において、終了状態が未完了である前記バッチ処理、および前記スケジュール記憶手段における前記スケジュール情報の日時を経過している未実行の該バッチ処理を、順序に従って起動し、前記仮想処理日記憶手段に記憶された該バッチ処理に対応する前記仮想処理日における処理として実行するバッチ処理起動手段、
前記バッチ処理起動手段で起動された前記バッチ処理からの通知を監視する監視手段、
前記監視手段により監視する該バッチ処理が異常終了した場合には、ログ情報記憶手段に、該バッチ処理が異常終了した旨と、再実行する際の処理開始位置と、を登録するログ情報登録手段、
を備えることを特徴とする日付管理装置として機能させることを特徴とするプログラム。
【請求項６】
請求項５に記載されたプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、実際の日付（システム時刻）とは異なる日付を指定して、バッチを処理するための日付管理装置に関する。
【背景技術】
【０００２】
一般的に、コンピュータのハードウェア、またはＯＳ（オペレーティング・システム）は、コンピュータ上の固有の日付・時刻を有する（以下、システム時刻という）。
【０００３】
システム日付は２４時を過ぎると次の日付となってしまい、例えば深夜に実行するバッチ処理の場合に置いて、処理が翌日まで継続する場合がある。またはネットワークなどの外部要因により障害が発生し、翌日の深夜までバッチ処理の再開ができない場合がある。このような場合、システム時刻を利用することで、バッチ処理の途中から日付が変わってしまうことになる。しかしながら、実際には、一連のバッチ処理においては同一日付（例えばバッチ処理を開始した日付）で全てのデータの処理を完了させたい場合がある。
【０００４】
そのため、深夜のバッチ処理で障害が発生した場合には、システム管理者がシステム内の日付を手作業で更新（前日に戻す）し、障害で中断していた前日深夜のバッチ処理を再実行し、再度、日付を当日に戻して実行する、などの作業コストが発生していた。また日付の操作を誤るリスクもあった。
【０００５】
特許文献１では、業務日付を１つのコンピュータの中に複数持つことを可能とし、複数業務システムの同居および同じ業務システム内でも別の業務システムを持つことができるようにしている。そして、複数の業務日付の中から、対応する業務システムに対応する業務日付を自動的に取得することができる日付管理の技術を提供している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−２６８７６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載の方法では、業務システムが何らかの障害で深夜処理をできない場合などの状況に対応し、自動的に再処理を行うことはできない。
【０００８】
本発明は、上記問題に鑑み、業務システムが何らかの障害で深夜処理をできない場合などの状況に対応し、自動的に再処理を行い、また処理結果のデータに対して適切な更新日時を付与することが可能な日付管理の仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、アプリケーションサーバとネットワークを介して接続可能であり、アプリケーションサーバにおけるバッチ処理の実行に関わる日付を制御する日付管理装置であって、前記日付管理装置によりスケジュール管理されるバッチ処理と、該バッチ処理の起動の日時と、をスケジュール情報として記憶するスケジュール記憶手段と、前記バッチ処理を実行するにあたり、システムが管理する日付とは異なる日付で該バッチを処理するための仮想処理日を記憶する仮想処理日記憶手段と、前記バッチ処理の終了状態と、該バッチ処理の実処理日と、をログ情報として記憶するログ情報記憶手段と、前記ログ情報記憶手段において、終了状態が未完了である前記バッチ処理、および前記スケジュール記憶手段における前記スケジュール情報の日時を経過している未実行の該バッチ処理を、順序に従って起動し、前記仮想処理日記憶手段に記憶された該バッチ処理に対応する前記仮想処理日における処理として実行するバッチ処理起動手段と、前記バッチ処理起動手段で起動された前記バッチ処理からの通知を監視する監視手段と、前記監視手段により監視する該バッチ処理が異常終了した場合には、ログ情報記憶手段に、該バッチ処理が異常終了した旨と、再実行する際の処理開始位置と、を登録するログ情報登録手段と、を備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、業務システムが何らかの障害で深夜処理をできない場合などの状況に対応し、自動的に再処理を行い、また処理結果のデータに対して適切な更新日時を付与することが可能な日付管理の仕組みを提供することを可能とする。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係わるシステム構成の一例を示す図である。
【図２】本発明の実施形態に係わる日付管理装置のハードウェア構成の一例を示すブロック図である。
【図３】本発明の実施形態に係わるバッチ処理のスケジュールテーブルの一例を示す図である。
【図４】本発明の実施形態に係わるスケジューラに従ったバッチ処理のパターンの一例を示す図である。
【図５】本発明の実施形態に係わるアプリケーションデータの遷移の一例を示す図である。
【図６】本発明の実施形態に係わるバッチ処理管理ログのデータ構成の一例を示す図である。
【図７】本発明の実施形態に係わるバッチ処理毎の仮想処理日の遷移の一例を示す図である。
【図８】本発明の実施形態に係わるバッチ処理起動の処理の一例を示すフローチャートである。
【図９】本発明の実施形態に係わるバッチ処理の監視処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
【００１３】
図１は、本発明の実施形態に係わるシステム構成の一例を示す図である。
【００１４】
本発明の実施形態におけるシステム構成では、日付管理装置１０１がアプリケーションサーバ１０２とネットワーク１０３（ＬＡＮ・ＷＡＮ）を介して接続されている。また、日付管理装置１０１とアプリケーションサーバ１０２が同一の筐体であってもよい。
【００１５】
日付管理装置１０１によってアプリケーションサーバ１０２におけるバッチ処理の制御がされており、またアプリケーションサーバ１０２で実行されるバッチ処理の結果、すなわち成功したか、または失敗したか、などのログが後述の通り、日付管理装置１０１により記録される。
【００１６】
図２は、本発明の実施形態に係わる日付管理装置１０１のハードウェア構成の一例を示すブロック図である。アプリケーションサーバ１０２に対しても適用可能である。
【００１７】
図２に示すように、日付管理装置１０１は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。
【００１８】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００１９】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。
【００２０】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【００２１】
また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。
【００２２】
ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。
【００２３】
メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、あるいは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００２４】
通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０３を介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を用いた通信等が可能である。
【００２５】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。
【００２６】
本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明についても後述する。
【００２７】
図３は、本発明の実施形態に係わるバッチ処理のスケジュールテーブル（スケジュール記憶部）の一例を示す図である。スケジュールテーブルは、後述する図８のフローチャートから参照され、通常は、定時にバッチ処理を開始するためのスケジュール管理に使用する。
【００２８】
例えば、企業などで所定の業務時間内ではバッチ処理を実行せず、従業員がアプリケーションサーバ１０２にアクセスしない夜間の時間帯などに、大量のデータを一気に処理する。そのためのバッチ処理起動のトリガーとなる。
【００２９】
図３のスケジュールテーブルは、“バッチ名”、“開始時刻”、“先行バッチ”により構成されている。これらの情報をまとめてスケジュール情報と呼ぶ。
【００３０】
“バッチ名”は、バッチ処理のプログラム実行形式ファイルを指し示すものなどである。図３の例では、入庫入力バッチ、受注入力バッチが指し示されている。例えば、従業員が所定の業務時間内に、発注してあった商品を受け取り、倉庫に入庫されたことを確認して入庫処理（商品名と個数など）を行う。この情報は入庫入力テーブルに登録される。これを入庫入力バッチにより、夜間に在庫マスターに反映させる、などの処理を行う。
【００３１】
“開始時刻”は、前述のバッチ処理を開始する時刻である。図３のように時刻だけを指定するのではなく、曜日（毎週金曜日に処理をする）、日付（毎月１５日に処理をする）などの指定があってもよい。
【００３２】
“先行バッチは、”あるバッチ処理を実行するために、順序関係として他のバッチ処理が障害なく完了していなければならない、ということを表す。例えば、図３の受注入力バッチ処理は２３：００から開始されるように指定されているが、２３：００を過ぎても入庫入力バッチ処理が完了していなければ、その完了を待つ必要がある。
【００３３】
以上のデータ項目は、管理者がこれらのデータをファイルに直接書き込むか、またはファイルやデータベースに書き込めるようなＧＵＩ（グラフィカル・ユーザ・インタフェース）を提供することにより実現することが可能である。
【００３４】
図４は、本発明の実施形態に係わるスケジューラに従ったバッチ処理のパターンの一例を示す図である。図３で説明したスケジュールテーブルに従って、後述する図８のフローチャートにより起動したバッチ処理を行った結果、正常に処理が進んだ場合、または途中で障害が発生した場合の複数パターンを例として説明する。
【００３５】
（１）の正常パターンは、まず“入庫入力バッチ”が２１：００に起動され、成功終了する。次に“受注入力バッチ”が起動される。図４の例では、スケジュールテーブルに記載されたとおり、２３：００から実行されているが、“入庫入力バッチ”で処理するデータが大量であるなどの理由で処理が完了していない場合には、処理が完了するまで起動せずに待つ。
【００３６】
（２）の異常終了（バッチ全体のロールバック）は、先に実行される“入庫入力バッチ”の処理の途中で、障害が発生する例である。障害が発生した場合、“入庫入力バッチ”が処理全体をロールバックし、アプリケーションのデータベースを２１：００直前の状態に戻す。この場合、次の“受注入力バッチ”は実施されない。例えば、翌日にシステム管理者が障害ログを見て改めて“入庫入力バッチ”を最初から再実行する必要がある。
【００３７】
しかしながら、ここで処理日付の問題が発生する。例えば、入庫入力バッチにより、前述の在庫マスターを更新したい場合に、当初、従業員により入庫入力した処理日付をそのまま在庫マスターでの更新日としたい、という場合がある。しかし、前述のように障害により入庫入力バッチを翌日に再実行する場合において、実際の日時（システム時刻）を使用するのであれば、“本来望ましい更新日”の“翌日の日付”が更新日となってしまう。
【００３８】
本発明では、後述する“仮想処理日”を用いることで、例えバッチ処理で障害が発生したとしても、適切な更新日で在庫マスターのデータを更新することが可能となる。また、本発明においては、例えバッチ処理実行中に２４：００を超え、日付が変わってしまっても“仮想処理日”を用いることにより適切な更新日で在庫マスターのデータを更新することが可能となる。
【００３９】
（３）の異常終了（バッチの内、処理中のトランザクションをロールバック）は、先に実行される入庫入力バッチは成功終了し、その後、受注入力バッチが開始されたが、受注入力バッチの途中で障害が発生する例である。なお、受注入力は複数のデータ（群）から構成され、順次処理されてそれぞれのそのデータ（群）の正常終了か異常終了（バッチ処理の障害発生）か、の判断ができるものとする。
【００４０】
すなわち、受注入力バッチの例では、途中までのデータ（群）の処理は成功しているので後でやり直す必要はない。異常終了（バッチ処理の障害発生）したところ（処理開始位置）を記憶しておき、その時点から再実行する。
【００４１】
本発明では上記の通り、障害が発生した場合に、いずれの時点（いずれのバッチ処理のいずれのデータの処理）から再開すればよいか、またデータをいつの日付として更新すればよいか（仮想処理日）を可能とする効果を得る。
【００４２】
次に図５から図７を用いて、バッチ処理が成功した場合、障害発生により失敗した場合の仮想処理日の扱いについて説明していく。なお、アプリケーションの１つ目の例としては、所定業務時間内に従業員により入庫情報を登録させる“入庫情報登録システム”と、夜間に入庫情報を在庫マスターに反映させる“入庫入力バッチ”を想定する。また、アプリケーションの２つめの例としては、所定業務時間内に作業員により受注情報を登録させる“受注情報登録システム”と、夜間に受注情報を在庫マスターに反映させる“受注入力バッチ”を想定する。前述したように（図３）、“入庫入力バッチ”は、“受注入力バッチ”の先行バッチである。
【００４３】
図５は、本発明の実施形態に係わるアプリケーションデータの遷移の一例を示す図である。
【００４４】
（１）のデータは、８月２４日の深夜バッチが開始される前の状態である。在庫マスター５０１ａは、８月２３日の更新を成功した状態で完了している。８月２４日の所定の業務時間内に入庫入力テーブル５０２ａと、受注入力テーブル５０３ａが、従業員により入力される。
【００４５】
なお、入庫入力テーブル５０２ａと受注入力テーブル５０３ａの処理日は、８月２４日であり、実際には、後述する図７の“仮想処理日”が８月２４日になったときに実行される。つまり、８月２３日以前のバッチ処理において障害が発生している可能性があり、障害があった場合には、仮想処理日を８月２４日以前のものとして、まず８月２４日以前のバッチ処理（対応する処理日のデータ）を完了した後、８月２４日のバッチ処理を開始するためである。
【００４６】
次に、図５の５０２ａ、５０３ａを在庫マスター５０１ａに反映するために、図７を用いて仮想処理日管理について説明する。
【００４７】
図７は、本発明の実施形態に係わるバッチ処理毎の仮想処理日の遷移の一例を示す図である。図７の仮想処理日管理テーブル（仮想処理日記憶部）は、バッチ名と仮想処理日とで構成される。
【００４８】
仮想処理日とは、バッチ名に該当するバッチ処理が次に動作するときに、“いつの日付”として動作させるか、を決定するものである。図７の（１）８月２４日、（１−１）８月２４日分の処理実行前では、前日の８月２３日分の処理が成功して完了しているため、バッチ処理の次の実行は“８月２４日”として動作することになるため、仮想処理日に実際のシステム日付と同じ“８月２４日”が記載されている。
【００４９】
なお、バッチ処理が成功終了している場合には、図７の仮想処理日（例えば（１−２）の入庫入力バッチの８月２５日）は、図６の仮想処理日（例えば（１）の仮想処理日８月２４日）の翌日（８月２５日）と一致している。
【００５０】
また、成功終了しているか否かは、図６の該当バッチ処理の“実処理日”が記載されているか否かにより判定してもよい。さらに図６の（１）実処理日が記載されていない場合（異常終了している場合）には、図６の（１）の仮想処理日と図７の（１−２）の仮想処理日８月２４日と一致する。図７の仮想処理日管理テーブルも実行結果として記載されるので、管理ログテーブルの一部と見なすことで、管理ログテーブルの前述の状態をもとにして、既に完了しているべきバッチ処理が、正常終了したか、異常終了しており再実行しなければいけないかを判断することができる。この場合、図６の仮想処理日と、図７の仮想処理日を区別するため、図７の仮想処理日は“次回予定仮想処理日”と見なされる。
【００５１】
図５の説明に戻る。仮想処理日が８月２４日の夜間バッチ処理で、“入庫入力バッチ”は成功し、更に“受注入力バッチ”は、受注入力テーブル５０３ａの４データのうち、２データの処理を成功し、３データ目（Ｃ社のデータ）で障害が発生したとする。これは図４の（３）のパターンである。この時、図７の仮想処理日管理テーブルは、（１−２）の通りとなっている。成功した“入庫入力バッチ”の仮想処理日は、翌日の“８月２５日”となっている。途中で障害が発生した“受注入力バッチ”の仮想処理日は、後で“８月２４日”分のデータを処理する必要があるため（受注入力バッチを８月２４日として起動する必要があるため）“８月２４日”のままである。以上で、システム日付８月２４日のバッチ処理は完了したが、その時点でのバッチ処理の結果を管理するログテーブルの状態を図６にて説明する。
【００５２】
図６は、本発明の実施形態に係わるバッチ処理管理ログのデータ構成の一例を示す図である。管理ログテーブル（ログ情報記憶部）は、バッチ名、終了状態、仮想処理日、実処理日、から構成されている。これらのデータ項目をまとめてログ情報と呼ぶ。１つのログ情報は、１つのバッチ処理結果に対応する。８月２４日のバッチ実行結果のログの例では、８月２４日（仮想処理日）に実行されるべき入庫入力バッチ（バッチ名）が、８月２４日（実処理日）に成功して完了（終了状態）したと記録される。続いて、８月２４日（仮想処理日）に受注入力バッチが実行されるが、“Ｃ社の受注処理データ”で異常終了した旨のログが登録される（ログ情報登録部）。
【００５３】
次に図５の説明に戻る。（２）は８月２５日のアプリケーションデータの状態である。前回のバッチ処理（１）では、在庫マスター５０１ａに４０個が入庫され、またＡ社、Ｂ社の２５個が受注処理されているため、（２）の在庫マスター５０１ｂの現在在庫は４５個である。また、受注入力テーブル５０３ｂには、前日に障害により処理できなかったＣ社、Ｄ社のデータと、８月２５日の所定の業務時間内に従業員により登録されたＥ社、Ｆ社、Ｇ社のデータ（合計５件）がある。
【００５４】
次に８月２５日の夜間バッチ処理を、図７の（２）８月２５日の図を用いて説明する。バッチ処理前の仮想処理日管理テーブルは、入庫入力バッチが８月２５日（前日成功終了しているため、日付が１日増えている）、受注入力バッチが８月２４日（失敗しているため前日のまま）となっている。
【００５５】
図５の説明に戻る。８月２５日の夜間バッチでは、入庫入力バッチ処理に障害が発生したとする。後続バッチである受注入力バッチ処理も実行されない。図４のパターン（２）の場合である。在庫マスター５０１ｂは如何なる更新もされず、翌日の処理まで（３）の状態に留まる。一方、図７の仮想処理日管理テーブルにおいても、８月２５日に如何なるバッチ処理も実行されないため、仮想処理日も変更されず、（２−２）の状態となる。
【００５６】
図６の（２）８月２５日実行後においては、入庫入力バッチが異常終了でロールバック、受注入力バッチは未処理として登録される。
【００５７】
次に図５の説明に戻る。（３）は、８月２６日のアプリケーションデータの状態である。前日（８月２５日）の処理は失敗しているため、在庫マスター５０１ｃの値は前日と同じである。また、入庫入力テーブル５０２ｃは、前日のデータに加え、８月２６日の所定の業務時間内に入力された入庫入力データ（５０個を入庫するもの）が、８月２６日付で登録されている。
【００５８】
一方、受注入力テーブル５０３ｃには、８月２４日の２件（Ｃ社、Ｄ社）、８月２５日の３件（Ｅ〜Ｇ社）、更に８月２６日の所定業務時間内に入力された３件の受注入力データ（Ｈ〜Ｊ社）が、８月２６日付で登録されている。
【００５９】
次に８月２６日の夜間バッチの処理を、図７の（３）８月２６日の図を用いて説明する。前日のバッチ処理が失敗しているため、（３−１）の仮想処理日は前日の開始前（（２−１）８月２５日分の処理実行前））と同じままである。
【００６０】
図５の説明に戻る。８月２６日の夜間バッチは、全て成功したとする。その結果は、（４）の通りである。入庫入力テーブル５０２ｄ、受注入力テーブル５０３ｄには、所定の業務時間前なので、データは何もない状態である。
【００６１】
実際には、両バッチ処理は、交互に順次実行される。これを図７の（３）８月２６日の仮想処理日管理テーブルを用いて説明する。（３−１）、すなわち８月２６日のバッチ処理実行前の仮想処理日管理テーブルは、入庫入力が８月２５日（まず、８月２５日分のデータを処理して終了するとの指示）となっている。また、受注入力は８月２４日（まず、８月２４日分のデータを処理して終了するとの指示）となっている。
【００６２】
ここで、後述するフローチャートで詳しく述べるように、仮想処理日付の最も古いものから実行するため、まず８月２４日分の受注入力バッチを実行する。これにより、Ｃ社、Ｄ社のデータが処理される。その後、仮想処理日は（３−２）の通り、両バッチの仮想処理日が８月２５日となる。さらに、仮想処理日を８月２５日として、入庫処理バッチ、受注処理バッチの順で処理され、いずれも成功すると、仮想処理日は（３−３）の通りいずれも８月２６日となる。同様に８月２６日の処理も実行し、仮想処理日は（３−４）の通りいずれも８月２７日となる。
【００６３】
８月２７日は、実際の日付（システム日付）を超えているため、これで処理は終了となる。バッチ処理の終了が翌日になる場合には、仮想処理日と実際の日付（システム日付）が同日であれば終了する、という条件にしてもよい。また、例えば８月２６日深夜のバッチ処理を行う際には、図６の管理ログテーブルにおける仮想処理日の最新のもの（例えば（２）８月２５日の実行結果では８月２５日が登録されている）の翌日分、すなわち８月２６日まで実行するようにしてもよい。この場合、システム日付が８月２７日にずれ込んでも、バッチ処理を８月２６日分の仮想処理日に処理すべきアプリケーションデータまでで終了することができる。
【００６４】
本発明により、夜間バッチ処理において障害が発生した場合であって、その処理を翌日に行う場合であっても、仮想処理日を用いて本来処理すべき日付のデータとして処理することができるという効果を得られる。また、深夜午前０時をまたぐ場合であっても、仮想処理日を用いることで、バッチ処理開始日（実際には前日の日付）を用いてデータを処理することができるという効果を得られる。
【００６５】
図８は、本発明の実施形態に係わるバッチ処理起動の処理の一例を示すフローチャートである。図８の各ステップは、日付管理装置１０１のＣＰＵ２０１によって実行される。
【００６６】
ステップＳ８０１からステップＳ８０９のループ処理は、仮想処理日の中で一番古い日付（最初の日付）から、最後の日付までを繰り返す。最後の日付の判断は、具体的には前述の通り、一連のバッチ処理実行前に、本フローチャートで図６のログを読み取ることで判断する。ただし、他の方法であってもよい。例えば、８月２６日（システム日付として８月２７日まで処理がまたがることがある）に、８月２７日以降のデータがアプリケーションのデータとして存在しないことが保証されていれば、データがないことで処理を中断してもよい。
【００６７】
ステップＳ８０２においては、仮想処理日を１つ固定（着目）する。
【００６８】
ステップＳ８０３からステップＳ８０８のループ処理は、着目している仮想処理日において実行すべきバッチ処理の全てに対するループである。過去の日付のものであれば、成功しているもの／障害により失敗しているもののいずれもあり得るが、失敗しているもの、すなわち未処理のものだけでよい。この未処理のもの、には、一部のデータのみ処理し、全てのデータを処理し切れていない、中断されたものも含む。また、このループでは、スケジュールテーブルを確認し、同一の仮想処理日において、先行すべきバッチ処理は、先に実行するため、ループにおけるバッチ処理の起動もその順序に従う。
【００６９】
ステップＳ８０４においては、バッチスケジュールＤＢにおける１つのバッチ処理に着目する。前述の通り、着目中の仮想処理日で終了しているもの（ログを参照）は、処理しなくてよい。
【００７０】
ステップＳ８０５において、着目したバッチ処理が未実行であり開始時間を経過しているか否かを判定する。過去に実行すべきであったのにバッチ処理の障害や、先行バッチが未完了のため実行できなかったバッチ処理は、既に指定の開始時間を過ぎているので、ＹＥＳとなる。また、初めて実行する仮想処理日であっても、時刻が過ぎていればＹＥＳとなる。それ以外はＮＯとなる。ＹＥＳの場合には、ステップＳ８０６に進む。ＮＯの場合にはステップＳ８０８に進む。
【００７１】
ステップＳ８０６においては、着目中のバッチ処理に対する先行バッチが完了しているか否か確認する。完了している場合（ＹＥＳ）にはステップＳ８０７、完了していない場合（ＮＯ）にはステップＳ８０８に進む。ただし、ＮＯとして、ここで実行しなかったバッチ処理は、先行するバッチ処理が完了した段階で起動するため、改めて本ループを繰り返した際に呼び出せるようにしておく。
【００７２】
ステップＳ８０７においては、着目中のバッチ処理を起動する。
【００７３】
図８のフローチャートにおける起動処理により、過去に遡って正常終了していないバッチ処理から最新日付のデータに対応するバッチ処理までを、管理者による日付変更操作などなく、自動的に実行していくという効果を得ることができる。
以上により、図８のフローチャートの説明を完了する。
【００７４】
図９は、本発明の実施形態に係わるバッチ処理の監視処理の一例を示すフローチャートである。図８のフローチャートにおいて起動されたバッチ処理を監視し、完了状態をログに記録する。図９の各ステップは、日付管理装置１０１のＣＰＵ２０１によって実行される。
【００７５】
ステップＳ９０１からステップＳ９０７のループは、実行中のバッチ処理からの通知を受けて、通知内容に応じた対応するために、本発明の実施形態におけるいずれかのバッチ処理の起動時から完了時まで、繰り返している。
【００７６】
ステップＳ９０２においては、実行中のいずれかのバッチから通知を受けたか否かを判定する。通知を受けた場合（ＹＥＳ）には、ステップＳ９０３に進む。通知を受けていない場合（ＮＯ）には、ステップＳ９０７に進む。
【００７７】
ステップＳ９０３においては、通知内容が、“成功終了”、“障害発生”のいずれかを判定する。成功終了の場合には、ステップＳ９０４に進む。障害発生の場合には、ステップＳ９０６に進む。
【００７８】
ステップＳ９０４においては、管理ログテーブルに、前記通知をしてきたバッチ処理が成功して終了した旨を記載する。次にステップＳ９０５において、そのバッチ処理に対応する仮想処理日（図７）を登録、更新する（仮想処理日登録部）。通常は１日増やす。ただし、そのバッチ処理が土日の夜間は処理されない、月末しか処理されない、というものであれば、そのスケジュールに従って、“次の実行予定日”に更新する。そのため不図示ではあるが、図３には、実行する日付、曜日、平日のみ、月末である、などの条件を設定可能にしてもよい。
【００７９】
ステップＳ９０６においては、管理ログテーブルに、前記通知をしてきたバッチ処理が、失敗した旨を記載する。また、次回の再実行のため、失敗の状態も記載する。例えば、全処理をロールバックしたため最初からやり直すのか（図４の（２）のパターン）、ある特定のデータまでは処理を成功したため途中から実行するのか（図４の（３）のパターン）、を記載する。
【００８０】
図９のフローチャートによる監視処理により、各バッチ処理の成功終了／障害発生の通知を受け、のちに図８のフローチャートの起動処理により、再実行するためのログを適切に記録するという効果を得られる。
以上により、図９のフローチャートの説明を完了する。
【００８１】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【００８２】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００８３】
また、本発明におけるプログラムは、図８、図９に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図８、図９の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図８、図９の各装置の処理方法ごとのプログラムであってもよい。
【００８４】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【００８５】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【００８６】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【００８７】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８８】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８９】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。  さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【００９０】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【００９１】
１０１  日付管理装置
１０２  アプリケーションサーバ
１０３  ネットワーク
【図１】
2014071751.tif 000003
【図２】
2014071751.tif 000004
【図３】
2014071751.tif 000005
【図４】
2014071751.tif 000006
【図５】
2014071751.tif 000007
【図６】
2014071751.tif 000008
【図７】
2014071751.tif 000009
【図８】
2014071751.tif 000010
【図９】
2014071751.tif 000011