(57)【要約】【課題】オンライン処理とバッチ処理を効率よく同時に実行することが可能なプログラム制御方法及びシステムを提供することを目的とする。【解決手段】ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、オンライン処理サービスへの要求数のしきい値を定義し、前記しきい値とオンライン処理サービスへの要求数を比較し、オンライン処理サービスへの要求数が前記しきい値を超えた場合にバッチ処理サービスを一時的に停止させる。オンライン処理サービスへの要求数が前記しきい値より小さくなったとき、バッチ処理再開の指示を出す。また、１つのプログラムでオンライン処理とバッチ処理の両サービスを処理させ、要求数に応じてサービスを切り替えて実行させる。【選択図】　図１
2004094711.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、
オンライン処理サービスへの要求に関し、前記サーバ上でそれらの要求を処理する際の負荷を判断する指標となるしきい値を定義するステップと、
前記しきい値を指標として、オンライン処理サービスへの要求にかかる負荷が大きいかどうかを判定するステップと、
オンライン処理サービスへの要求にかかる負荷が大きいと判定されたとき、バッチ処理サービスを一時的に停止させるステップと
を備えることを特徴とする負荷バランス機能を有するプログラム制御方法。
【請求項２】
請求項１に記載のプログラム制御方法において、
オンライン処理サービスへの要求数とバッチ処理サービスへの要求数に応じて、オンライン処理サービスとバッチ処理サービスを切り替えて実行するステップをさらに備えたことを特徴とする負荷バランス機能を有するプログラム制御方法。
【請求項３】
ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、
オンライン処理サービスへの要求数のしきい値を定義するステップと、
前記しきい値とオンライン処理サービスへの要求数を比較するステップと、
オンライン処理サービスへの要求数が前記しきい値を超えた場合にバッチ処理サービスを一時的に停止させるステップと
を備えることを特徴とする負荷バランス機能を有するプログラム制御方法。
【請求項４】
請求項３に記載のプログラム制御方法において、
前記バッチ処理を一時的に停止させるとき、処理を中断したデータファイルを処理中のバッチ処理として保持しておくステップと、
オンライン処理サービスへの要求数が前記しきい値より小さくなったとき、バッチ処理再開の指示を出すステップと、
再開の指示を受けたバッチアプリケーションが、前記保持してあった処理中のバッチ処理のデータファイルの読み込みを再開し、バッチ処理を行うステップと
を備えたことを特徴とする負荷バランス機能を有するプログラム制御方法。
【請求項５】
請求項３に記載のプログラム制御方法であって、
前記オンライン処理サービスを行うプログラムと前記バッチ処理サービスを行うプログラムとが１つのプログラムで実現されていることを特徴とする負荷バランス機能を有するプログラム制御方法。
【請求項６】
ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御システムであって、
オンライン処理サービスへの要求に関し、前記サーバ上でそれらの要求を処理する際の負荷を判断する指標となるしきい値を定義する手段と、
前記しきい値を指標として、オンライン処理サービスへの要求にかかる負荷が大きいかどうかを判定する手段と、
オンライン処理サービスへの要求にかかる負荷が大きいと判定されたとき、バッチ処理サービスを一時的に停止させる手段と
を備えることを特徴とする負荷バランス機能を有するプログラム制御システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上で該当するサービスプログラムに処理を振り分けるプログラム制御方法及びシステムに関する。
【０００２】
【従来の技術】
従来、リアルタイム性を求められるオンライン処理は昼間に行い、リアルタイム性を求められないバッチ処理はオンライン処理が停止する夜間に行われていた。こうすることで、日中はバッチ処理の負荷を気にすることなく、オンラインサービスだけの処理に集中させ、レスポンスを確保していた。
【０００３】
【発明が解決しようとする課題】
ところで、上記従来技術によれば、オンラインサービスが停止している時間だけバッチ処理を実行できるが、オンラインサービスが停止する時間が短いか、あるいは２４時間オンラインサービスを提供するケースを考慮しておらず、バッチサービスを実行する時間が限られてしまっていた。また、オンライン処理中にバッチ処理を実行すると、オンラインサービスの性能が劣化するという問題があった。企業の国際化などの動きの中で、オンライン処理の２４時間連続運転化が急速に進展しているため、従来のように夜間や休日だけバッチ処理を行うわけにはいかなくなってきている。
【０００４】
また、オンライン処理の２４時間連続運転化に伴い、オンラインの処理状況を考慮して、バッチ処理を起動するタイミングを人が決めることが難しくなってきている。
【０００５】
本発明の目的は、上記の従来型における問題点に鑑み、オンライン処理とバッチ処理を効率よく同時に実行することが可能なプログラム制御方法及びシステムを提供することにある。
【０００６】
【課題を解決するための手段】
上記の目的を達成するため、本発明は、ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、オンライン処理サービスへの要求に関し、前記サーバ上でそれらの要求を処理する際の負荷を判断する指標となるしきい値を定義し、前記しきい値を指標として、オンライン処理サービスへの要求にかかる負荷が大きいかどうかを判定し、オンライン処理サービスへの要求にかかる負荷が大きいと判定されたとき、バッチ処理サービスを一時的に停止させることを特徴とする。
【０００７】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
【０００８】
図１に、本発明を適用した処理システムの全体構成を示す。ネットワーク１６０に、オンラインクライアント１００，１１０、バッチクライアント１２０、及びサーバ１３０が接続されている。サーバ１３０は、要求受付機能１３１、トランザクション管理機能１３２、キュー１３３、定義ファイル１３４、オンラインアプリケーション１４１、バッチアプリケーション１４２、及びデータベース１５０を有する。
【０００９】
図２に、キュー１３３の詳細を示す。ここでは、キュー１３３は、種別２０１、会員コード２０２、商品コード２０３、数量２０４、データファイル２０５、及び処理の状況２０６の各項目を有するものとする。種別２０１が“ＯＮ”であるレコードは、オンラインクライアント１００，１１０からの要求を示す。オンライン要求には、会員コード、商品コード、及び数量のデータが含まれる。種別２０１が“ＢＡ”のレコードは、バッチクライアント１２０からの要求を示す。種別２０１が“ＰＲ”のレコードは、バッチクライアント１２０からの要求で、現在処理が中断されているものを示す。種別２０１が“ＢＡ”または“ＰＲ”の場合、バッチ処理すべきデータファイルの格納先がデータファイル２０５の欄に記載される。処理の状況２０６は、バッチ処理が中断されたとき（“ＰＲ”のとき）の処理中の場所、すなわちバッチ処理しているデータファイルのどこまで処理したかを示す位置である。
【００１０】
図３に、データファイル２０５の項目で指される格納先に存在するバッチ処理用のデータファイルの内容例を示す。データファイルは、図３に示すように、会員コード３０１と、商品コード３０２と、数量３０３の組み合わせを複数記述したテキスト形式のデータファイル３００である。バッチ処理を行う際には、このデータファイルのレコードを読み出してデータベースに格納する。
【００１１】
図４に、データベース１５０のテーブル構造を示す。テーブル４００は、会員コード４０１と、商品コード４０２と、数量４０３の項目を備えている。音来所理やバッチ処理によって、このデータベースにデータが格納されていく。
【００１２】
図５に、定義ファイル１３４の詳細を示す。定義ファイル１３４の内容５００は、項目５０１と、値５０２からなる。例えば、項目５０１は「しきい値」であり、値５０２は「５」であるとき、しきい値の値を「５」と定義したことを意味する。しきい値の意味については後述する。
【００１３】
図６に、要求受付機能１３１の処理フローチャート６００を示す。要求受付機能１３１では、ステップ６０１でクライアントからのリクエストを受け付け、ステップ６０２でデータをキュー１３３に格納する。これらの処理を繰り返し実行する。
【００１４】
図７に、トランザクション管理機能１３２の処理フローチャート７００を示す。トランザクション管理機能１３２では、まずステップ７０１で、定義ファイル１３４からしきい値の値を取得し、キュー１３３から該キュー１３３に現在格納されているデータの個数（詳しくは、全体のデータ数のほか、種別“ＯＮ”のデータの個数、及び種別“ＰＲ”のデータがあるかどうか）を取得する。次に、ステップ７０２で、ステップ７０１で得たしきい値の値とキュー１３３に格納されている種別が“ＯＮ”であるデータの個数とを比較する。種別“ＯＮ”のデータの個数がしきい値以上であるときは、オンライン処理要求の数がしきい値以上ということであるから、ステップ７０３でバッチ処理に停止指示を出し、ステップ７０１に戻る。例えば、図５に示したようにしきい値の値が５である場合は、オンライン処理要求の個数が５個以上のときにバッチ処理が停止され、オンライン処理が優先的に実行される。
【００１５】
ステップ７０２でしきい値の値のほうが大きい場合、ステップ７０４で、キュー１３３に格納されたデータの個数が０であるかどうかを判断する。データの個数が０であれば、処理要求がないということであるから、ステップ７０１に戻る。データの個数が０でない場合、ステップ７０５で、キュー１３３に処理中のバッチ処理があるかどうか、すなわち種別“ＰＲ”のデータがあるかどうかを判断する。処理中のバッチ処理がある場合、ステップ７０６で、その種別“ＰＲ”のデータをキュー１３３から取り出し、そのデータに基づいてバッチ処理（図９）を起動し、ステップ７０１に戻る。キュー１３３に処理中のバッチ処理がない場合は、ステップ７０７に進む。
【００１６】
ステップ７０７で、キュー１３３（図２）からデータ（１レコード）を取得する（取り出す）。ステップ７０８で、取得したデータの種別が“ＯＮ”であるかどうかを判断する。データの種別が“ＯＮ”である場合は、ステップ７０９で、取得したデータに基づいてオンライン処理（図８）を起動し、ステップ７０１に戻る。キュー１３３から取得したデータの種別が“ＯＮ”でない場合は、取得したデータがバッチ処理要求（種別“ＢＡ”）であるということである。この場合は、ステップ７１０で、しきい値とキュー１３３のデータ中の種別が“ＯＮ”であるデータの個数とを比較する。種別“ＯＮ”の個数がしきい値の値以上のときは、オンライン処理要求が多いということであるから、ステップ７１１でデータ（ステップ７０７で取り出した種別“ＢＡ”のデータ）をキュー１３３に戻して、ステップ７０１に戻る。ステップ７１０でしきい値の値のほうが大きい場合は、オンライン処理要求が少ないということであるから、ステップ７１２で前記取得したデータに基づいてバッチ処理（図９）を起動し、ステップ７０１に戻る。
【００１７】
図８に、オンラインアプリケーション１４１の処理（ステップ７０９）のフローチャートを示す。ステップ８０１で、トランザクションを開始する。ステップ８０２で、与えられたデータ（会員コードと商品コードと数量）をデータベース１５０に格納する。ステップ８０３で、コミット（Ｃｏｍｍｉｔ）処理、すなわちデータベース１５０へのデータ変更を確定する処理を行う。ステップ８０４で、トランザクションを終了する。
【００１８】
図９に、バッチアプリケーション１４２の処理（ステップ７０６，７１２）のフローチャートを示す。ステップ９０１で、トランザクションを開始する。ステップ９０２で、バッチ処理するデータファイル（図３）から１レコード取り出しデータベース１５０（図４）に格納する。ステップ９０３で、バッチ処理停止指示（ステップ７０３の指示）が出ているかどうかを判断する。バッチ処理停止指示が出ている場合は、ステップ９０５に進み、データベースをコミットしてそれまでの処理を確定させる。その後、ステップ９０６でトランザクションを終了（中断）し、ステップ９０７で処理を中断したデータファイルを特定する種別“ＰＲ”のレコードをキュー１３３（図２）に戻す。このとき、処理の状況２０６には、処理を中断した位置を格納しておくものとする。
【００１９】
ステップ９０３でバッチ処理停止指示が出ていない場合は、ステップ９０４で、バッチ処理が終了したかどうか（すなわち、データファイル（図３）の内容をすべてデータベース（図４）に格納したかどうか）を判断する。バッチ処理が終了していない場合は、ステップ９０２に戻る。バッチ処理が終了した場合は、ステップ９０５でデータベースをコミットして処理を確定させ、ステップ９０６でトランザクションを終了する。この場合、ステップ９０７は行わない。
【００２０】
次に、上述の本実施形態のシステムの全体の動きを具体例で説明する。
【００２１】
オンラインクライアント１００，１１０は商品コードと数量を指定して、またバッチクライアント１２０は図３のようなデータファイルを指定して、それぞれ要求受付機能１３１に要求を発行する。要求を受けた要求受付機能１３１は、図６に示したフローチャートに示す通り、要求を待ち受け、受け付けた要求の内容をキュー１３３（図２）に格納する。オンラインクライアント１００，１１０からの要求を受け付けた場合は種別２０１を“ＯＮ”とし、バッチクライアント１２０からの要求を受け付けた場合は種別２０１を“ＢＡ”とする。オンラインクライアント１００，１１０は、要求時に会員コードと商品コードと数量を伝えるものとし、要求受付機能１３１は受け取った会員コードと商品コードと数量をキュー１３３（図２）の該当する欄ににそれぞれ格納する。バッチクライアント１２０は、図３に示すデータファイル３００を要求受付機能１３１に渡すものとし、要求受付機能１３１は受け取ったデータファイル３００の格納先をキュー１３３のデータファイル２０５の欄に書き込む。
【００２２】
トランザクション管理機能１３２は、図７に示す通り、定期的にキュー１３３を監視し、キュー１３３に要求があれば、種別に応じたアプリケーションに処理を依頼する。オンラインアプリケーション１４１及びバッチアプリケーション１４２はそれぞれマルチスレッドで複数の要求を同時に処理することが可能であるものとする。オンラインアプリケーション１４１は、図８に示す通り、要求に応じてデータベース１５０にデータを格納する。バッチアプリケーション１４２は、図９に示す通り、要求と同時に受け取ったデータファイルの内容に従って、データベース１５０に複数のデータを格納する。
【００２３】
本実施形態のトランザクション管理機能１３２は、キュー１３３に格納された要求のうち種別が“ＯＮ”の要求の数が、定義ファイル１３４のしきい値で定義された数よりも多いかどうかを判定する。多い場合には、オンライン処理要求が多いということであるから、バッチアプリケーション１４２に一時停止の指示を出す。一時停止の指示を受けたバッチアプリケーション１４２は、データファイル３００の読み込みを中止し、一度データベース１５０をコミットする。そして、当該処理途中のデータファイルについては、種別“ＰＲ”のレコードをキュー１３３に戻して、バッチアプリケーション１４２を一時的に停止させる。なお、データファイル３００のどこまで処理したかを、処理の状況２０６の欄に格納しておくものとする。
【００２４】
トランザクション管理機能１３２は、再びキュー１３３の監視を継続し、キュー１３３に格納された要求のうち種別が“ＯＮ”になっているものの数が、定義ファイル１３４のしきい値で定義された数よりも少なくなったとき、キュー１３３に処理途中のバッチ処理があるかどうかを調べ、あればそのバッチ処理の再開の指示をバッチアプリケーション１４２に出す。再開の指示を受けたバッチアプリケーション１４２は、中断していたデータファイル３００の読み込みを再開し、処理を続行する。
【００２５】
さらに、トランザクション管理機能１３２はキュー１３３を監視し、キュー１３３から取得したデータの種別が“ＢＡ”であり、キュー１３３に格納された要求のうち種別が“ＯＮ”になっているものの数が定義ファイル１３４のしきい値で定義された数より多ければ、データをキュー１３３に格納し、バッチサービスを後に回し、オンラインサービスを優先して処理する。
【００２６】
なお、上記実施形態では、図１に示すように、オンラインアプリケーション１４１とバッチアプリケーション１４２とを分けた例で説明した。これらのアプリケーションは共通する処理を行う部分が多いので、両機能を備えた１つのアプリケーションとすることもできる。図１０に、図１のオンラインアプリケーション１４１とバッチアプリケーション１４２の両方を兼ね備えたオンライン・バッチアプリケーション１４３を有するプログラム制御システムの構成を示す。他の部分は、上記実施形態と同様である。図７に示したトランザクション管理機能１３２の処理のフローチャートに従うことで、図１０に示すように１つのプログラムでオンライン・バッチアプリケーション１４３を実現することが可能となる。
【００２７】
また、上記実施の形態では、項目５０１としてオンライン要求数についてのしきい値だけを定義したが、バッチ処理数、オンライン処理の実行数、実行可能最大数、あるいは実行可能最小数などをしきい値として定義して、オンライン処理とバッチ処理とを効率よく同時に実行させることも可能である。複数のしきい値の判別を組み合わせることも可能である。
【００２８】
上記のようにすることによって、オンラインクライアントの要求が多いときにはオンラインアプリケーションの処理を優先し、逆にオンラインクライアントの要求が少ないときにはバッチ処理を行わせることが可能となる。
【００２９】
【発明の効果】
以上説明したように、本発明によれば、オンライン処理とバッチ処理を効率よく同時に実行することができる。また、オンラインの処理状況を考慮し、バッチ処理を起動することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るシステムの全体構成を示す図である。
【図２】キューの詳細図である。
【図３】データファイルの詳細図である。
【図４】データベースのテーブル構造図である。
【図５】定義ファイルの詳細図である。
【図６】要求受付機能の処理の流れを示すフローチャートである。
【図７】トランザクション管理機能の処理の流れを示すフローチャートである。
【図８】オンラインアプリケーションの処理の流れを示すフローチャートである。
【図９】バッチアプリケーションの処理の流れを示すフローチャートである。
【図１０】本発明の変形例の構成を示す図である。
【符号の説明】
１００，１１０……オンラインクライアント
１２０……バッチクライアント
１３０……サーバ
１３１……要求受付機能
１３２……トランザクション管理機能
１３３……キュー
１３４……定義ファイル
１４１……オンラインアプリケーション
１４２……バッチアプリケーション
１４３……オンライン・バッチアプリケーション
１５０……データベース
１６０……ネットワーク
【図１】
2004094711.tif 000003
【図２】
2004094711.tif 000004
【図３】
2004094711.tif 000005
【図４】
2004094711.tif 000006
【図５】
2004094711.tif 000007
【図６】
2004094711.tif 000008
【図７】
2004094711.tif 000009
【図８】
2004094711.tif 000010
【図９】
2004094711.tif 000011
【図１０】
2004094711.tif 000012