JP2012247885A - スケジュール管理システム、スケジュール管理システムの制御方法及びプログラム - Google Patents

Abstract

【課題】スケジュール管理システムクライアントが管理するバッチが実行可能かスケジュール管理システムサーバに問い合わせることで、インターネット上にポートを公開する必要なくセキュアな環境でバッチ処理システムを稼動させる手段を提供する。
【解決手段】スケジュール管理システムサーバ１０１に対して所定のネットワークプロトコルポートのみを開放する。このネットワークプロトコルポートを介して、該当するカレンダ情報にアクセスを行うことで不要なポートを開放することを避ける。
【選択図】図１

Description

本発明は、企業の営業日や休業日を定めたカレンダ情報を集中管理する方法、及び、システムのバッチ処理実行スケジュールを集中管理する方法と、複数の企業カレンダ情報に則ってバッチ処理を実行する機能と、企業カレンダ情報を他アプリケーションに提供する機能に関する。

利用者がインターネット上にあるアプリケーションやハードウェアリソースを任意に選択し、利用するクラウドコンピューティングが普及している。これに伴い、企業システムの業務システムがインターネット上のアプリケーションに置き換わる、あるいは企業システム自体がインターネット上のハードウェアリソース上で稼働するようになっている。

これにより、アプリケーションやハードウェアのメンテナンス等、システムの運用コストの削減や、システム障害による業務停止のリスクを避ける等の効果が期待できる。

このような状況を背景に、定期的に大量データを編集するようなバッチ処理を実行するシステムと、それらの実行スケジュールを管理しバッチ処理を起動させる自動起動システムをインターネット上のハードウェアリソースを利用して稼働させることが想定されている。

特開平９‐６４５７号公報（特許文献１）は、特定の日付、時刻、曜日・時刻でプログラムを自動起動することにより定型業務の自動実行を可能とする、プログラム自動制御装置を開示する。

特開平１０‐６９５７８号公報（特許文献２）には、本日実行すべきデータ処理業務を確認する作業に連動して、この確認作業によって本日実行すべき業務である認識したデータ処理業務の起動を指令できるようにする旨が開示されている。

特開平９‐６４５７号公報 特開平１０‐６９５７８号公報

しかし、クラウドコンピューティングにおいては、バッチシステムとスケジュール管理システム間での通信にインターネットを利用することとなり、どちらか一方に公開用のポートを開ける必要がある。このため、セキュリティリスクを増大させるといった問題が発生する。

このようなシステムをクラウドコンピューティング環境で利用する場合、システム間情報連携を実現するセキュアなシステム構成の検討が必要となる。

本発明の目的は、スケジュール管理システムクライアントが管理するバッチが実行可能かスケジュール管理システムサーバに問い合わせることで、インターネット上にポートを公開する必要なくセキュアな環境でバッチ処理システムを稼動させる手段を提供することにある。

本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次の通りである。

本発明の代表的な実施の形態に関わるスケジュール管理システムは、スケジュール管理システムサーバが稼働する第１のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第２のサイトと、を含み、これらの第１のサイトと第２のサイトがインターネットを介して接続され、業務アプリケーションが動作する該スケジュール管理システム外のサイトと接続する論理的なインターフェースを第１のサイトは有することを特徴とする。

このスケジュール管理システムにおいて、スケジュール管理システムサーバは、バッチ処理の開始処理を行うスケジュール管理システムクライアントから出力される呼び出しでバッチ処理可否判定処理を開始し、バッチ処理可否判定処理の結果を、スケジュール管理システムクライアントに戻すことを特徴としても良い。

このスケジュール管理システムにおいて、バッチ処理可否判定処理に際し、スケジュール管理システムサーバは自身が有する１又は２以上のリポジトリからスケジュールの基礎情報を用いることを特徴としても良い。

このスケジュール管理システムにおいて、バッチ処理可否判定処理を受信したスケジュール管理システムクライアントは所定の場合にバッチ処理を実行することを特徴としても良い。

本発明の代表的な実施の形態に関わるスケジュール管理システムの制御方法は、スケジュール管理システムサーバが稼働する第１のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第２のサイトと、を含み、第１のサイトと第２のサイトがインターネットを介して接続され、スケジュール管理システムクライアントがスケジュール管理システムサーバに処理を行うべきバッチの有無の確認を要求するバッチ処理確認ステップと、バッチ処理確認ステップでの要求を受けて、スケジュール管理システムサーバが処理を行うべきバッチの有無を確認し、スケジュール管理システムクライアントに確認の結果を送信するバッチ処理確認ステップと、を有することを特徴とする。

本発明の代表的な実施の形態に関わるプログラムは、スケジュール管理システムサーバ上で動作するものであって、スケジュール管理システムサーバとコンピュータネットワークで接続されるスケジュール管理システムクライアント上で動作するバッチ実行モジュールから、企業ＩＤとバッチＩＤを取得し、バッチ処理の要否を判定し、コンピュータネットワークを介してバッチ実行モジュールに判定の結果を返送することを特徴とする。

このプログラムにおいて、判定の結果が肯定的なものである場合には、スケジュール管理システムサーバ内のバッチ実行スケジュールリポジトリの最終実施日を更新することを特徴としても良い。

スケジュール管理システムサーバがスケジュール管理システムクライアントに実行命令を出すのではなく、スケジュール管理システムクライアントが管理しているバッチが実行可能か否かをスケジュール管理システムサーバに問い合わせることで、バッチ処理システム環境でインターネット上にポートを公開する必要はなく、セキュアな環境でバッチ処理システムの稼働が可能となる。

また、インターネット上の様々なアプリケーションは、スケジュール管理システムサーバで管理された情報を元に、各企業に適したユーザインターフェース等のサービスを提供可能となる。さらに、企業独自のカレンダ情報が手に入ることから、「３月第２営業日」等の抽象表現での日付指定が業務アプリケーション上で可能となる。

本発明を実現するスケジュール管理システムの全体概要図である。 図１で説明した各サイトの開放ポート一覧に関する図である。 スケジュール管理システムサーバの構成図である。 スケジュール管理システムクライアントの構成図である。 スケジュール管理システムサーバで公開されるＷｅｂサービスの一覧に関する図である。 定休日情報リポジトリの一例を示す図である。 例外休業日情報リポジトリの一例を示す図である。 バッチ実行スケジュールリポジトリの一例を表す図である。 本発明におけるバッチ実行モジュールの動作を示すフローチャートである。 本発明における実行判定モジュールの動作を示すフローチャートである。 本発明におけるカレンダ情報提供モジュールの動作を示すフローチャートである。 本発明における日付提供モジュールの動作を示すフローチャートである。

以下の実施の形態においては、便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明する。しかし、特に明示した場合を除き、それは互いに無関係なものではなく、一方は他方の一部又は全部の変形例、詳細、補足説明などの関係にある。また、以下の実施の形態において、要素の数など（個数、数値、量、範囲などを含む）に言及する場合、特に明示した場合及び原理的に明らかに特定の数に限定される場合などを除き、その特定の数に限定されるものでなく、特定の数以上でも以下でも良い。

さらに、以下の実施の形態において、その構成要素は、特に明示した場合及び原理的に明らかに必須であると考えられる場合を除き、必ずしも必須のものでないことは言うまでもない。

以下、図を用いて本発明の実施の形態を説明する。

（実施の形態）
本発明に関わるスケジュール管理システムの概略動作は以下のようになる。

スケジュール管理システムクライアントは、スケジュール管理システムサーバに対して一定間隔でバッチ処理の実行の可否について問い合わせを行う。問い合わせを受けたスケジュール管理システムサーバは、自身が管理するバッチ実行スケジュールと企業のカレンダ情報を参照し、処理を行うべきバッチがあるかを確認する。

処理を行うバッチの有無の判定結果は、スケジュール管理システムサーバからスケジュール管理システムクライアントに伝達される。処理を要するバッチがあった場合には、スケジュール管理システムクライアントは指定されたバッチ処理を実行する。

次にインターネット上の業務アプリケーションが企業独自のカレンダ情報を取り込む場合について説明する。

またインターネット上にある業務アプリケーションは、複数の企業が汎用化された同じ業務アプリケーションを利用し、迅速かつ安価にアプリケーションを導入できる。一方で、インターネット上にある業務アプリケーションでは個別の企業の営業日や休業日を登録することはできず、画面情報にも反映されないため、利用者にとっては不便なユーザインターフェースとなっている。

これに対し、本発明では、業務アプリケーションは必要に応じて、特定企業の特定の期間についてスケジュール管理システムサーバに問い合わせる。問い合わせを受けたスケジュール管理システムサーバは自身が管理するカレンダ情報を参照し、指定された期間の営業日、休日といったカレンダ情報をアプリケーションに返す。

アプリケーションでは受け取ったカレンダ情報を元に画面の表示などを行う。

図１は、本発明を実現するスケジュール管理システムの全体概要図である。

本発明に関わるシステムは、インターネット１０によって相互に接続される、スケジュール管理システムサーバ１０１が稼働するサイト１１と、スケジュール管理システムクライアント１０２とバッチ処理システム１０３が稼働するサイト１２、インターネット上で公開される業務アプリケーション１０４が稼働するサイト１３により構成される。

インターネット１０とは、インターネットプロトコル技術を用いて相互接続されたコンピュータネットワークである。

従来、企業が持つ複数のバッチ処理システムは社内ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）など、外部と隔離された環境に配置される。これらの複数のバッチ処理システムはスケジュール管理システムからの起動命令で各バッチ処理が稼動する。インターネット１０を経由する場合、スケジュール管理システムがバッチ処理システムに命令を出すために必要なＴＣＰ等のトランスポート層のプロトコルで用いるネットワークポートをインターネット上に公開する必要がある。これはバッチ処理システムが配置された全環境で必要となる為、バッチ処理システムが多いほどセキュリティのリスクを増大させることとなっていた。

また特に手段を講じなければ、Ｅｎｄ Ｔｏ Ｅｎｄの経路は、保証されるものではなく、経路上のデータの安全性は保証されない。さらには、不足の第三者がインターネット１０経由でサイト１１、１２、１３に不正にアクセスを試みることも可能であるため、各サイトは一定の安全措置を採る必要がある。

本発明は、これらのリスクを解消するための物である。

スケジュール管理システムサーバ１０１は、企業の営業日と休業日を定義したカレンダ情報と、バッチ処理システムの実行スケジュールを管理するシステムサーバである。

スケジュール管理システムクライアント１０２は、スケジュール管理システムサーバ１０１が管理するスケジュールに基づいてバッチ処理システムを実行する上位ソフトウェアモジュールである。

バッチ処理システム１０３は、スケジュール管理システムクライアント１０２により実行され、インターネット上のハードウェアを利用する際に、自社で運用していたスケジュール監視システム（図示せず）をスケジュール管理システムサーバ１０１が提供するスケジュール管理システムに置き換える下位ソフトウェアモジュールである。

なお、サイト１２上のスケジュール管理システムクライアント１０２及びバッチ処理システム１０３の対は複数存在すると思われるが、説明の簡略化のために一組に制限している。サイト１２上にスケジュール管理システムクライアント１０２及びバッチ処理システム１０３の対が複数存在する場合も本発明の射程に含まれるのは言うまでもない。

また、スケジュール管理システムクライアント１０２及びバッチ処理システム１０３が動作するサイト１２が複数存在することも発明者は想定している。これらも本発明の射程に含まれる。

サイト１３上で動作する業務アプリケーション１０４は、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（登録商標）やＧｏｏｇｌｅ Ａｐｐｓ（登録商標）などインターネット上で公開される業務アプリケーションである。

図２は、図１で説明した各サイトの開放ポート一覧に関する図である。ここで、「ポート番号」はＴＣＰ（トランスミッションコントロールプロトコル）またはＵＤＰ（ユーザデータグラムプロトコル）で定義される使用ポートアドレスのことを言う。

サイト１１では、スケジュール管理システムクライアント１０２からの問い合わせと、業務アプリケーション１０４からの問い合わせをＷｅｂサービスとして受け付ける。このため、インターネット１０を経由してのサイト１１へのポート番号８０（ＨＴＴＰ）、若しくはポート番号４４３（ＨＴＴＰＳ）の通信が許可されている。

サイト１２では、スケジュール管理システムクライアント１０２がスケジュール管理システムサーバ１０１のＷｅｂサービスに問い合わせるために、サイト１２からインターネット１０を経由してのポート番号８０、若しくはポート番号４４３が解放されている。

サイト１３に関してもサイト１２と同様である。これにより、不適切なポートを経由しての外部からのアクセスをサイト１２とサイト１３は遮断することができる。

図３は、スケジュール管理システムサーバ１０１の構成図である。

スケジュール管理システムサーバ１０１は、定休日情報リポジトリ３０２と、例外休業日情報リポジトリ３０３と、バッチ実行スケジュールリポジトリ３０４と、実行判定モジュール３０５と、カレンダ情報提供モジュール３０６と、日付提供モジュール３０７と、を含んで構成される。

定休日情報リポジトリ３０２は、企業毎の定休日を管理するリポジトリ（データ格納部）である。

例外休業日情報リポジトリ３０３は、企業毎の定休日以外の休業日を管理するリポジトリである。

これらの定休日情報リポジトリ３０２及び例外休業日情報リポジトリ３０３は、該企業の定休日など、スケジュールの基礎情報を提供する。すなわち該当日が定休日情報リポジトリ３０２及び例外休業日情報リポジトリ３０３から上げられる情報に含まれていなければ、営業日であるとの判断をなすことができる。

バッチ実行スケジュールリポジトリ３０４は、バッチ処理システム１０３の稼働スケジュールを管理するリポジトリである。

実行判定モジュール３０５は、スケジュール管理システムクライアント１０２からの問い合わせに対して、対象のバッチがその時実行出来るか否かを判定するソフトウェアモジュールである。

カレンダ情報提供モジュール３０６は、業務アプリケーション１０４からの問い合わせに対して、休業日情報を返すソフトウェアモジュールである。

日付提供モジュール３０７は、業務アプリケーション１０４からの問い合わせに対して、抽象的な表現を具体的な日付に変換するソフトウェアモジュールである。

スケジュール管理システムサーバ１０１が持つ実行判定モジュール３０５と、カレンダ情報提供モジュール３０６と、日付提供モジュール３０７はＳａａＳ等のＷｅｂサービスとしてインターネットに公開されている。

図４は、スケジュール管理システムクライアント１０２の構成図である。

スケジュール管理システムクライアント１０２は、バッチ実行モジュール４０２とプロパティファイル４０３を含んで構成される。

バッチ実行モジュール４０２は、スケジュール管理システムサーバ１０１の実行判定モジュール３０５にバッチ処理システム１０３の起動可否を確認し、可能であった場合はバッチ処理システム１０３を起動するソフトウェアモジュールである。

プロパティファイル４０３は、バッチ実行モジュール４０２が管理するバッチ処理システム１０３を表すＩＤとバッチ処理システム１０３を所有する企業ＩＤが格納されたデータ格納部である。

図５は、スケジュール管理システムサーバ１０１で公開されるＷｅｂサービスの一覧に関する図である。

実行判定モジュール３０５は、スケジュール管理システムクライアント１０２のバッチ実行モジュール４０２から渡される企業ＩＤとバッチＩＤを引数として取得し、バッチＩＤが表すバッチ処理システム１０３がその時起動可能であるかを判定し、その可否情報をスケジュール管理システムクライアント１０２に返す。

カレンダ情報提供モジュール３０６は、業務アプリケーション１０４から渡される企業ＩＤと、確認期間開始日と確認期間終了日で指定される期間情報を元に、企業ＩＤに該当する企業に関して、指定された期間内の休業日一覧を呼び出し元の業務アプリケーション１０４に返す。

日付提供モジュール３０７は業務アプリケーション１０４から渡される企業ＩＤと、日付確認の対象月を指定する確認指定月情報と、確認指定月情報で指定された月の中で何番目の営業日（または休業日）を検索するかを指定する確認数え日と、日付確認の対象が営業日か休業日かを指定する営業日休業日フラグを元に、定休日情報リポジトリ３０２と例外休業日情報リポジトリ３０３を参照し、具体的な日付情報を返す。例えば、業務アプリケーション１０４から、企業ＩＤとして対象の企業ＩＤ、確認指定月として１、確認数え日として３、営業日休業日フラグとしてｔｒｕｅを受け取った場合、日付提供モジュール３０７は企業ＩＤの定休日情報リポジトリ３０２と例外休業日情報リポジトリ３０３の情報を参照し、企業ＩＤに該当する企業の１月の第３営業日にあたる日付情報を呼び出し元の業務アプリケーション１０４に返す。

図６は、定休日情報リポジトリ３０２の一例を示す図である。

ここでは、企業ＩＤとその企業の定休日（定期休業曜日）が登録されている。図６の場合、ＣｏｍｐａｎｙＡは土曜日と日曜日が定休日であり、ＣｏｍｐａｎｙＢは火曜日が定休日であることが登録されている。

図７は、例外休業日情報リポジトリ３０３の一例を示す図である。

ここでは、企業ＩＤとその企業の定休日以外の休業日（例外休業日）が登録されている。

図７の場合、ＣｏｍｐａｎｙＡは３月１０日と５月２０日、ＣｏｍｐａｎｙＢは１２月３１日が休業日であることが登録されている。

図８は、バッチ実行スケジュールリポジトリ３０４の一例を表す図である。

ここでは、バッチ処理システム１０３を表すバッチＩＤとその実行開始時刻、及び、実施周期、周期で指定された日にちが営業日の場合、バッチ処理システム１０３を起動させるか否かを表す営業日実施フラグ、周期で指定された日にちが休業日の場合、バッチ処理システム１０３を起動させるか否かを表す休業日実施フラグが登録されている。なお、図中の「最終実施日」は、バッチ処理を最後に行った日をいう。便宜上スケジュール管理システムクライアント１０２からスケジュール管理システムサーバ１０１への問い合わせがあった最終の日となると思われるが、「最終実施日」を如何様にするかは設計事項である。なお、後述する図１０ではステップＳ１１０９、Ｓ１１１１がこの「最終実施日」の更新に当たる。

図８では、ＢａｔｃｈＡは毎週水曜日の１１時に実行、ＢａｔｃｈＢは毎月最終日が営業日の場合のみ１２時に実行、ＢａｔｃｈＣは２０１１年の２月１８日から２日おきで、営業日に該当する日のみ実施することを表している。

なお、定休日情報リポジトリ３０２、例外休業日情報リポジトリ３０３及びバッチ実行スケジュールリポジトリ３０４は、各企業の担当者により予めこれらの情報が登録されているものとし、登録手段に関して言及しないものとする。

図９は、本発明におけるバッチ実行モジュール４０２の動作を示すフローチャートである。

バッチ実行モジュール４０２はＬｉｎｕｘ（登録商標）のｃｒｏｎやＷｉｎｄｏｗｓ（登録商標）のタスクスケジューラなどにより定期的に実行されるモジュールである。

起動したバッチ実行モジュール４０２はプロパティファイル４０３からバッチ処理システム１０３を管理する企業を表す企業ＩＤと、バッチ処理システム１０３を表すバッチＩＤを取得し（ステップＳ１００１）、スケジュール管理システムサーバ１０１の実行判定モジュール３０５を公開したＷｅｂサービスに問い合わせを行う（ステップＳ１００２）。

スケジュール管理システムサーバ１０１からの戻り値がｔｒｕｅの場合（ステップＳ１００３：Ｙｅｓ）、バッチ処理システム１０３を実行可能である。このため、プロパティファイル４０３から取得したバッチＩＤに該当するバッチ実行モジュール４０２を実行する（ステップＳ１００４）。スケジュール管理システムサーバ１０１からの戻り値がｆａｌｓｅの場合（ステップＳ１００３：Ｎｏ）、バッチ処理システム１０３は実行不可であるため、処理を終了することとなる。

図１０は、本発明における実行判定モジュール３０５の動作を示すフローチャートである。

実行判定モジュール３０５はＷｅｂサービスとして公開され、スケジュール管理システムクライアント１０２のバッチ実行モジュール４０２から呼び出されることで処理が開始する。

処理開始後、実行判定モジュール３０５は、まずバッチ実行モジュール４０２から取得した企業ＩＤ情報をキーに、定休日情報リポジトリ３０２と例外休業日情報リポジトリ３０３を参照し、休業日一覧を取得する（ステップＳ１１０１）。

次に、実行判定モジュール３０５は、処理実行時の日時とバッチ実行モジュール４０２から取得したバッチＩＤの情報をもとに、バッチ実行スケジュールリポジトリ３０４を参照する（ステップＳ１１０２）。

ステップＳ１１０２で参照した結果を元に実行判定モジュール３０５は処理実施日がバッチ実行スケジュールリポジトリ３０４の実施周期で指定された日に該当し、且つ、処理実施時刻がバッチ実行スケジュールリポジトリ３０４の始日時を過ぎている、且つ、バッチ実行スケジュールリポジトリ３０４の最終実行日時が実施日よりも過去の日付であるか（＝営業日であるか）を判定する（ステップＳ１１０３）。

営業日である場合（ステップＳ１１０４：Ｙｅｓ）、バッチ実行スケジュールリポジトリ３０４から取得した情報の営業日実施フラグを参照する。ｔｒｕｅである場合（ステップＳ１１０５：Ｙｅｓ）は、呼び出し元のバッチ実行モジュール４０２にｔｒｕｅ（ステップＳ１１０７）を返し、ｆａｌｓｅ（ステップＳ１１０５：Ｎｏ）である場合は、呼び出し元のバッチ実行モジュール４０２にｆａｌｓｅを返す（ステップＳ１１１０）。

また、実行判定モジュール３０５は、処理実施日が休業日であった場合（ステップＳ１１０４：Ｎｏ）、バッチ実行スケジュールリポジトリ３０４から取得した情報の休業日実施フラグを参照する。休業日実施がｔｒｕｅである場合は（ステップＳ１１０６：Ｙｅｓ）、呼び出し元のバッチ実行モジュール４０２にｔｒｕｅを返し（ステップＳ１１０８）、ｆａｌｓｅである場合は（ステップＳ１１０６：Ｎｏ）、呼び出し元のバッチ実行モジュール４０２にｆａｌｓｅを返す（ステップＳ１１１２）。

なお、呼び出し元のバッチ実行モジュール４０２にｔｒｕｅを返した場合、バッチ実行スケジュールリポジトリ３０４内のバッチＩＤに該当するデータに関して、最終実施日を処理実施日に書き換える（ステップＳ１１０９及びステップＳ１１１１）。

図１１は、本発明におけるカレンダ情報提供モジュール３０６の動作を示すフローチャートである。

カレンダ情報提供モジュール３０６はＷｅｂサービスとして公開される。業務アプリケーション１０４がカレンダ情報提供モジュール３０６を呼び出すことでカレンダ情報提供モジュール３０６の処理が開始される。

カレンダ情報提供モジュール３０６の処理開始後、カレンダ情報提供モジュール３０６は、まず業務アプリケーション１０４から取得した企業ＩＤ情報をキーに、定休日情報リポジトリ３０２と例外休業日情報リポジトリ３０３を参照し、該当企業の休業日を取得する（ステップＳ１２０１）。

次に、カレンダ情報提供モジュール３０６は、ステップＳ１２０１で取得した休業日情報から、業務アプリケーション１０４から取得した確認期間開始日と確認期間終了日で指定された期間に含まれる休業日の一覧を作成する（ステップＳ１２０２）。

その後カレンダ情報提供モジュール３０６は、作成した休業日一覧を呼び出し元の業務アプリケーション１０４に返す（ステップＳ１２０３）。

業務アプリケーション１０４はその画面表示に送られた休業日一覧を反映するなどして、利用者へのサービスの情報として利用する。

図１２は、本発明における日付提供モジュール３０７の動作を示すフローチャートである。

日付提供モジュール３０７はＷｅｂサービスとして公開される。日付提供モジュール３０７は業務アプリケーション１０４から呼び出されることで処理が開始する。

日付提供モジュール３０７の処理開始後、日付提供モジュール３０７は、まず業務アプリケーション１０４から取得した企業ＩＤ情報をキーに、定休日情報リポジトリ３０２と例外休業日情報リポジトリ３０３を参照し、休業日一覧を取得する（ステップＳ１３０１）。

次に業務アプリケーション１０４から取得した確認指定月、確認数え日、営業日休業日フラグを元に、具体的な日付を算出する（ステップＳ１３０２）。例えば、業務アプリケーション１０４から、企業ＩＤはＣｏｍｐａｎｙＡ、確認指定月は１、確認数え日は３、営業日休業日フラグとしてｔｒｕｅを受け取ったとき、定休日情報リポジトリ３０２の内容が図６、例外休業日情報リポジトリ３０３の内容が図７の状態とすると、処理実施年度の１月の中で、土曜日と日曜日を除く３つ目の日付を、呼び出し元の業務アプリケーション１０４に返す（ステップＳ１３０３）。このように、日付提供モジュール３０７を使用することで、業務アプリケーション１０４は抽象的に表現された日付情報から具体的な日付情報を取得することができる。

このように処理することで、インターネット上に不要なポートを公開する必要なくセキュアな環境でバッチ処理システムを稼動させることが可能となる。すなわち、１）企業が持つ複数のバッチ処理システムと、それらの管理と実行を行うスケジュール管理システムをインターネット上のハードウェアリソース上で稼動させる、２）企業が持つシステムをインターネット上にあるアプリケーションに置き換えるという問題を解決することができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更が可能であることは言うまでもない。

例えば、スケジュール管理システムサーバ１０１中には定休日情報リポジトリ３０２、例外休業日情報リポジトリ３０３、バッチ実行スケジュールリポジトリ３０４、実行判定モジュール３０５、カレンダ情報提供モジュール３０６、日付提供モジュール３０７が存在する。これらの役割を併せ持つソフトウェアモジュールに処理を一元化する場合や、いくつかの処理を行うモジュールを用いるなど、一般的な応用事例については当然に本発明の射程に含まれる。

また上記では、処理すべきバッチの有無の判定結果はその如何にかかわらずスケジュール管理システムサーバ１０１からスケジュール管理システムクライアント１０２へ伝達された。しかし、処理すべきバッチがあるときのみスケジュール管理システムサーバ１０１からスケジュール管理システムクライアント１０２に伝達するようにしても良い。

本発明を採用することで、インターネット上で提供されるハードウェアリソースを利用してバッチ処理システムをセキュアに稼動させる為の手段、または、インターネット上で公開されているアプリケーションを提供する事業者が、利用者が所属する企業の営業日と休業日情報に合わせたサービスを提供するための手段として利用することが可能となる。

１０：インターネット、１１、１２、１３：サイト、
１０１：スケジュール管理システムサーバ、
１０２：スケジュール管理システムクライアント、１０３：バッチ処理システム、
１０４：業務アプリケーション、３０２：定休日情報リポジトリ、
３０３：例外休業日情報リポジトリ、３０４：バッチ実行スケジュールリポジトリ、
３０５：実行判定モジュール、３０６：カレンダ情報提供モジュール、
３０７：日付提供モジュール、４０２：バッチ実行モジュール、
４０３：プロパティファイル。

Claims (7)

1. スケジュール管理システムサーバが稼働する第１のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第２のサイトと、を含み、前記第１のサイトと前記第２のサイトがインターネットを介して接続されるスケジュール管理システムであって、
   業務アプリケーションが動作する該スケジュール管理システム外のサイトと接続する論理的なインターフェースを前記第１のサイトは有することを特徴とするスケジュール管理システム。
2. 請求項１記載のスケジュール管理システムにおいて、
   前記スケジュール管理システムサーバは、バッチ処理の開始処理を行う前記スケジュール管理システムクライアントから出力される呼び出しでバッチ処理可否判定処理を開始し、
   前記バッチ処理可否判定処理の結果を、前記スケジュール管理システムクライアントに戻すことを特徴とするスケジュール管理システム。
3. 請求項２記載のスケジュール管理システムにおいて、
   前記バッチ処理可否判定処理に際し、前記スケジュール管理システムサーバは自身が有する１又は２以上のリポジトリからスケジュールの基礎情報を用いることを特徴とするスケジュール管理システム。
4. 請求項３記載のスケジュール管理システムにおいて、
   前記バッチ処理可否判定処理を受信した前記スケジュール管理システムクライアントは所定の場合にバッチ処理を実行することを特徴とするスケジュール管理システム。
5. スケジュール管理システムサーバが稼働する第１のサイトと、スケジュール管理システムクライアントとバッチ処理システムが稼働する第２のサイトと、を含み、前記第１のサイトと前記第２のサイトがインターネットを介して接続されるスケジュール管理システムの制御方法であって、
   前記スケジュール管理システムクライアントが前記スケジュール管理システムサーバに処理を行うべきバッチの有無の確認を要求するバッチ処理確認ステップと、
   前記バッチ処理確認ステップでの要求を受けて、前記スケジュール管理システムサーバが処理を行うべきバッチの有無を確認し、前記スケジュール管理システムクライアントに前記確認の結果を送信するバッチ処理確認ステップと、を有することを特徴とするスケジュール管理システムの制御方法。
6. スケジュール管理システムサーバ上で実行の判定を行うプログラムであって、
   該プログラムは、前記スケジュール管理システムサーバとコンピュータネットワークで接続されるスケジュール管理システムクライアント上で動作するバッチ実行モジュールから、企業ＩＤとバッチＩＤを取得し、バッチ処理の要否を判定し、前記コンピュータネットワークを介して前記バッチ実行モジュールに前記判定の結果を返送することを特徴とするプログラム。
7. 請求項６記載のプログラムにおいて、
   前記判定の結果が肯定的なものである場合には、前記スケジュール管理システムサーバ内のバッチ実行スケジュールリポジトリの最終実施日を更新することを特徴とするプログラム。

Images