(57)【要約】      （修正有）【課題】バッチシステムではバッチ対象データが確定するまでバッチ処理を開始できなった。また、バッチ処理に平均値の算出等の集計処理がある場合は、全てのバッチ対象データが揃うまでバッチ処理を実行できなかった。このため、蓄積されたデータを一括処理するバッチ処理の性能向上を図る。【解決手段】バッチ対象データが確定していない状態でも、バッチ対象データが発生したら、そのデータをロット化してバッチ処理を実行する。バッチ処理が実行される度に中間結果を保存し、新規にバッチ処理を実行する度に、その結果を中間結果に反映する。実行したバッチ処理の結果が業務的に問題ないことを保証するためのフロー制御機能を持つ。また、処理済みのバッチ対象データに変更が発生した場合は、変更後のデータに対するバッチ処理を実行して、変更による差分を中間結果に反映する。【選択図】図４
2008097476.tif 000002
【特許請求の範囲】
【請求項１】
バッチ処理の処理対象となるデータを受け付けて一括処理を行うバッチシステムにおいて、
前記データを受け付けて、保存する手段と、
前記保存する手段の保存状況を監視することで、他のデータとの待ち合わせが必要かを示すガード条件を満たしているかを検知する手段と、
前記検知する手段で前記ガード条件を満たしたことを検知した場合、当該検知の度に前記データをロット単位でバッチ処理する手段と、
前記ガード条件を満たしていない場合には、前記バッチ処理を抑止する手段を有することを特徴とするバッチシステム。
【請求項２】
請求項１に記載のバッチシステムにおいて、
前記抑止する手段は、前記保存する手段に保存されたデータを保持続けるよう制御することを特徴とするバッチシステム。
【請求項３】
請求項１または２のいずれかに記載のバッチシステムにおいて、
前記ガード条件には、所定のイベントが発生したか否かを示すイベント型条件、前記他のデータの入力が必要か否かを示す待ち合わせ型条件およびデータ件数が所定数以上であるか否かを示すデータ件数型条件のうち少なくとも１つを含むことを特徴とするバッチシステム。
【請求項４】
請求項１乃至３のいずれかに記載のバッチシステムにおいて、
前記検知する手段は、前記保存する手段に新規のデータが受付けられているかを検知することを特徴とするバッチシステム。
【請求項５】
請求項１乃至４のいずれかに記載のバッチシステムにおいて、
前記バッチ処理の結果に対応する中間結果を算出する手段と、
当該中間結果を用いて、複数のバッチ処理の整合を取る手段をさらに有することを特徴とするバッチシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、蓄積されたデータを一括処理するバッチ処理における性能向上技術と、バッチ処理の処理対象となるデータ（バッチ対象データ）のフロー制御の技術に関する。
【背景技術】
【０００２】
バッチ処理の性能向上を実現する技術として、特許文献１がある。特許文献１においては、通常のオンライン処理状態では、オンライン系の２重化データベースを構成し、バッチ処理時には２重化が切離されて独立のオンライン系データベースおよびバッチ系データベースを構成するデータベース機構と、入力メッセージの要求するオンライン処理を、通常のオンライン処理状態では２重化データベースを対象に実行し、バッチ処理状態では上記独立のオンライン系データベースを対象に実行するオンライン処理機構と、上記独立のバッチ系データベースを対象にバッチ処理を実行するバッチ処理機構と、このバッチ処理機構によるバッチ処理開始時からオンライン処理機構によるオンライン処理の少なくとも入力の履歴をとるトレース機構と、このトレース機構によってとられた上記履歴をもとに過去に実行されたオンライン処理をバッチ系データベースを対象に再現するオンライン復元機構とを設け、オンライン処理の再現が終了した後に独立のオンライン系データベースおよびバッチ系データベースを２重化データベースに戻して通常のオンライン処理を再開するようにしたことを特徴とする。
【０００３】
【特許文献１】特開平２−１２４４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献１のバッチシステムにおいては、バッチ対象データが確定した時点でオンライン処理と並行してバッチ処理を実行する。これにより、すべてのバッチ対象データが揃ってからバッチ処理を開始する方法と比較してバッチ処理の開始時間が早まり、それに伴ってバッチ処理の終了時間を早めることができる。通常のバッチシステムの方式を図１に、特許文献１のバッチシステムの方式を図２に示す。
【０００５】
しかしながら、特許文献１のバッチシステムではバッチ対象データが確定するまでバッチ処理を開始できない。また、バッチ処理に平均値の算出等の集計処理がある場合は、全てのバッチ対象データが揃うまでバッチ処理を実行できない。このため、バッチ対象データとバッチ処理の内容の特性によっては、バッチ処理の開始時間を早めることができない。
【課題を解決するための手段】
【０００６】
バッチ対象データが確定していない状態でも、バッチ対象データが発生したら、そのデータをロットという単位にまとめて（ロット化して）逐次型のバッチ処理を実行する。
【０００７】
逐次処理方式のバッチシステムはバッチ処理が実行される度に中間結果を保存する。そして、新規にバッチ処理を実行する度に、その結果を中間結果に反映する。
【０００８】
逐次処理方式のバッチシステムは、実行したバッチ処理の結果が業務的に問題ないことを保証するための、バッチ対象データに対するフロー制御機能が必要となる。このフロー制御機能であるガード機能も本発明に含まれる。
【０００９】
本ガード機能は、バッチ処理を実行する前に、バッチ対象データが予め設定した条件（ガード条件）をクリアするかどうかで待ち合わせが必要かを判定する機能を提供する。待合せが必要なければバッチ対象データをバッチ処理に流し、待合せが必要であれば条件を満たすまでバッチ対象データをバッチ処理に流さずに保留する。
【００１０】
また、処理済みのバッチ対象データに取消し・変更が発生した場合は、取消し・変更対象のデータに対するバッチ処理を実行して、取消し・変更による差分を中間結果に反映する。逐次処理方式のバッチシステムの方式を図３に示す。
【００１１】
より詳細には、本発明は以下の態様も含まれる。
バッチ処理の処理対象となるデータを受け付けて一括処理を行うバッチシステムにおいて、前記データを受け付けて、保存する手段と、前記保存する手段の保存状況を監視することで、他のデータとの待ち合わせが必要かを示すガード条件を満たしているかを検知する手段と、前記検知する手段で前記ガード条件を満たしたことを検知した場合、当該検知の度に前記データをロット単位でバッチ処理する手段と、前記ガード条件を満たしていない場合には、前記バッチ処理を抑止する手段を有することを特徴とするバッチシステム。
【００１２】
また、このバッチシステムにおいて、前記抑止する手段は、前記保存する手段に保存されたデータを保持続けるよう制御することを特徴とするバッチシステムも本発明に含まれる。
【００１３】
また、これらのバッチシステムにおいて、前記ガード条件には、所定のイベントが発生したか否かを示すイベント型条件、前記他のデータの入力が必要か否かを示す待ち合わせ型条件およびデータ件数が所定数以上であるか否かを示すデータ件数型条件のうち少なくとも１つを含むことを特徴とするバッチシステムも本発明に含まれる。
【００１４】
また、これらのバッチシステムにおいて、前記検知する手段は、前記保存する手段に新規のデータが受付けられているかを検知することを特徴とするバッチシステムも本発明に含まれる。
【００１５】
さらに、これらのバッチシステムにおいて、前記バッチ処理の結果に対応する中間結果を算出する手段と、当該中間結果を用いて、複数のバッチ処理の整合を取る手段をさらに有することを特徴とするバッチシステムも本発明に含まれる。
【００１６】
なお、このバッチシステムを用いた処理方法やこのバッチシステムを実現するためのコンピュータプログラムも本発明に含まれる。
【発明の効果】
【００１７】
本発明により、バッチ対象データやバッチ処理の内容の特性に関わらずバッチ処理の終了時間を早めることができる。
【発明を実施するための最良の形態】
【００１８】
本発明の実施の形態について、図面を用いて説明する。
まず、本実施の形態におけるシステム構成図を図４に示す。各オンライン処理サーバ１０とバッチ処理サーバ２０はネットワークを介して互いに接続されている。また、各サーバは、メモリ、ハードディスクを含む記憶装置、ＣＰＵなどの処理装置を有し、記憶装置に格納されたプログラムに従って処理装置が情報処理を実施するものである。
【００１９】
各オンライン処理サーバ１０で実行されるオンラン処理によってバッチ対象データが生成され、バッチ対象データはネットワークを介してはバッチ処理サーバ２０に送信される。バッチ処理サーバ２０に送信されたバッチ対象データはデータベース８０に格納される。本発明の逐次処理方式のバッチシステムは、図４のバッチ処理サーバ２０で実行される。
【００２０】
バッチ処理サーバ２０には、バッチ対象データとバッチ処理の結果等を格納する記憶装置であるデータベース８０が搭載され、バッチ処理を制御するバッチ管理機能３０と各バッチ処理（バッチ処理（フェーズ１）５０、バッチ処理（フェーズ２）６０、バッチ処理（フェーズ３）７０、）が動作する。なお、バッチ処理が複数のフェーズに分かれていない場合、動作するバッチ処理は１つでもよい。バッチ管理機能３０は、バッチ対象データを各バッチ処理に引き渡すと共に、各バッチ処理の起動制御を行う。各バッチ処理は、受け取ったバッチ対象データに対する業務処理を実行して、その結果をデータベース８０に蓄積する。
【００２１】
以下、本実施の形態の処理内容について説明する。
本実施の形態において、図４のシステム構成で、バッチ処理が実行されるまでの処理手順を示すフローチャートを図５に示す。
ステップ２００において、バッチ管理機能３０はバッチ処理の起動条件を満たしているかを判定する。バッチ管理機能３０が判定するバッチ処理の起動条件は以下の３点がある。
【００２２】
（１）既定件数のバッチ対象データの蓄積
バッチ管理機能３０は、定期的にデータベース８０に既定件数のバッチ対象データが蓄積されたかを判定する。判定する間隔と判定基準となるバッチ対象データの件数は、バッチ処理サーバ２０の記憶装置に保持している。
【００２３】
（２）既定時刻
バッチ管理機能３０は、バッチ処理を実行するための予め定められた時刻（既定時刻）になったかを判定する。判定基準となる既定時刻は、バッチ処理サーバ２０の記憶装置に保持している。
【００２４】
（３）前回のバッチ起動からの経過時間
バッチ管理機能３０は、前回バッチ起動時からの既定の時間が経過したかを判定する。前回のバッチ起動時刻と判定基準となる経過時間は、バッチ処理サーバ２０の記憶装置に保持している
判定の結果、バッチ処理の起動条件を満たしている場合は、ステップ３００に進む。バッチ処理の起動条件を満たしていない場合は処理を行わず、一定間隔後に再度ステップ２００を実行する。
【００２５】
ステップ３００において、ステップ２００の判定の結果、バッチ処理の起動条件を満たしている場合はバッチ処理を実行する。バッチ処理の終了後はステップ２００に戻る。
【００２６】
本実施の形態におけるバッチ処理のシステム構成図を図６に示す。
ここで、入力情報ＤＢ８１とは、バッチ対象データが格納された記憶装置である。ガード機能５１は、設定した条件（ガード条件）をクリアするかどうかで待ち合わせが必要かを判定するフロー制御機能を提供する。バッチ処理にフロー制御が必要ない場合は、ガード機能５１は無くてもよい。ガード条件定義ファイル５２とは、ガード機能５１の判定条件となるガード条件を保持するファイルであり、ガード条件に関する情報として、フロー識別子と種別とガード条件の３点を保持する。条件適用テーブル８２とは、ガード条件の変動データが格納された記憶装置である。保留情報ＤＢ８３とは、ガード条件をクリアしなかった場合にバッチ対象データを保留する記憶装置である。バッチ処理機能５３は、バッチ処理として業務処理を実行する。なお、バッチ処理機能５３を設けないことも可能である。出力情報ＤＢ８４とは、バッチ処理の結果を格納する記憶装置で、次フェーズのバッチ処理の入力となる。バッチ管理機能３０とは図４のバッチ管理機能３０と同じであり、バッチ処理に対する制御機能を提供する。
【００２７】
入力情報ＤＢ８１と条件適用テーブル８２と保留情報ＤＢ８３と出力情報ＤＢ８４の４つのＤＢテーブルは、図４のデータベース８０に格納されている。ガード機能５１と４つのＤＢテーブル、バッチ処理機能５３と４つのＤＢテーブルはそれぞれ１：１に対応する。あるガード機能５１とバッチ処理機能５３は、自身が使用する４つのＤＢテーブルを特定するために、４つのＤＢテーブルに関する情報を保持している。
【００２８】
本実施の形態において、図６のシステム構成で、バッチ処理の処理手順を示すフローチャートを図７に示す。
【００２９】
ステップ３０２において、バッチ管理機能３０がバッチ処理を起動する。バッチ管理機能３０によって、ガード機能５１とバッチ処理機能５３の双方が起動される。バッチ管理機能３０がガード機能５１を起動する際、バッチ管理機能３０はガード機能５１に対してフロー識別子を送付する。フロー識別子とは、バッチ処理中の処理フローの位置（フェーズ）を識別する情報である。
【００３０】
ステップ３０３において、ガード機能５１は、入力情報ＤＢ８１からバッチ対象データを取得する。バッチ対象データとは、オンライン処理サーバ１０から送付されたバッチ処理の対象となるデータ、もしくは上流（前フェーズ）のバッチ処理の結果である。バッチ対象データのデータ構造はバッチ処理の内容に依存するが、必ずデータＩＤを保持する。データＩＤとは、バッチ対象データを一意に識別する情報である。ガード機能５１は、入力情報ＤＢ８１に格納されているバッチ対象データを全て取得する。ガード機能５１がバッチ対象データを取得する方法は、バッチ管理機能３０が入力情報ＤＢ８１のバッチ対象データをガード機能５１に送信する方法と、ガード機能５１が入力情報ＤＢ８１からバッチ対象データを取り出す方法がある。なお、ガード機能５１を設けないことも可能であり、この場合はバッチ処理機能５３が入力情報ＤＢ８１からバッチ対象データを取得する。
【００３１】
ステップ３０４において、ガード機能５１はガード条件定義ファイル５２からガード条件を読込む。ガード条件定義ファイル５２には、フロー識別子とガード条件の対応を示す情報が格納されている。ガード条件とは、ガード機能５１がバッチ対象データを下流に流すか否かを判定する条件文である。ガード条件には以下に示す３つの種類がある。
【００３２】
（１）イベント型ガード条件
予め定められたイベントが発生したかを判定する。イベント型ガード条件には以下の２つの判定方法がある。
【００３３】
１つ目の判定方法は、イベントが発生するまでバッチ対象データを保留し、イベントが発生したら保留されていたバッチ対象データを無条件に下流に流す方法である。本判定方法の場合、イベント型ガード条件を満たすバッチ対象データが下流のバッチ処理に渡されるタイミングは、そのバッチ対象データがガード機能５１に投入されるタイミングに依存する。
【００３４】
２つ目の判定方法は、イベントが発生するまでバッチ対象データを保留し、イベントが発生したら、その時刻より前にバッチ処理に投入された全てのバッチ対象データの到着を待ってバッチ対象データを下流に流す方法である。本判定方法の場合、イベント型ガード条件を満たす全てのバッチ対象データは、同時に下流のバッチ処理に渡される。但し、イベント発生後には、該当するイベント型ガード条件を満たすバッチ対象データは発生しないことを前提としている。この判定方法を実現するためには、バッチ管理機能３０がバッチ処理を起動する際にバッチ対象データのデータＩＤと投入時間を取得して、各バッチ対象データのデータＩＤと投入時間をガード機能５１に送付する必要がある。ガード機能５１は、イベントの発生時刻と各バッチ対象データの投入時刻を比較してイベントの発生よりも先に投入されたバッチ対象データのデータＩＤ特定し、それらのデータＩＤを持つバッチ対象データの到着を待ってバッチ対象データを下流に流す。
【００３５】
イベント型ガード条件は、「締め」等のイベントによってバッチ対象データが揃ったことを保証できる場合に適用する。
【００３６】
（２）待合せ型ガード条件
ある１つのバッチ対象データに対して、下流に流すために必要な他のバッチ対象データが揃っているかを判定する。上流で並列に実行される複数の処理が完了して、バッチ対象データが揃ったら下流に流す。待合せ型ガード条件は、あるバッチ対象データと組になる特定のバッチ対象データの到着によってデータが揃ったことを保証できる場合に適用する。
【００３７】
（３）データ件数型ガード条件
バッチ対象データが、ある一定件数揃っているかを判定する。データ件数が条件を満たすとバッチ対象データを下流に流す。データ件数型ガード条件は、件数によってバッチ対象データが揃ったことを保証できる場合に適用する。
【００３８】
ステップ３０５において、ガード機能５１はステップ３０２でバッチ管理機能３０から送付されたフロー識別子をキーとして、ガード条件定義ファイル５２から適用するガード条件を特定する。ガード条件定義ファイル５２では、フロー識別子とガード条件が１：１に対応しており、フロー識別子によってガード条件が一意に特定される。
【００３９】
ステップ３０６において、ガード機能５１はガード条件定義ファイル５２より適用するガード条件が待合せ型か否かを判定する。ガード条件定義ファイル５２では、ガード条件と種別が１：１に対応している。種別は対応するガード条件がイベント型か待合せ型かデータ件数型かを示すため、ガード機能５１は、ステップ３０５で特定したガード条件に対応する種別を参照することで適用するガード条件が待合せ型か否かを判定する。適用するガード条件が待ち合わせ型の場合はステップ３０８に、そうでない場合はステップ３０７に進む。
【００４０】
ステップ３０７において、ステップ３０６の判定で適用するガード条件が待合せ型でない場合、ガード機能５１は条件適用テーブル８２からガードの変動データを読み込む。イベント型ガード条件の場合、イベントテーブルから該当するイベントが発生したか否かを示す情報を読み込む。データ件数型ガード条件の場合は、グローバル変数テーブルよりデータ件数を示す情報を読み込む。イベントテーブルに格納されているイベントが発生したか否かを示す情報とグローバル変数テーブルよりデータ件数を示す情報はフロー識別子と１：１に対応しており、フロー識別子によって読み込む変動データが一意に識別される。
【００４１】
ステップ３０８において、ガード機能５１は取得したバッチ対象データがガード条件をクリアしているかを判定する。
【００４２】
ステップ３０９において、バッチ対象データがガード条件をクリアしていた場合、ガード機能５１は該当データをバッチ処理機能５３に渡す。バッチ処理機能５３は該当データに対する業務処理を実行する。ガード機能５１の後にバッチ処理機能５３を設けないことも可能であり、その場合、ガード機能５１は該当するバッチ対象データを出力情報ＤＢ８４に格納する。
【００４３】
ステップ３１０において、業務処理の終了後、バッチ処理機能５３は、該当データに対する処理結果を出力情報ＤＢ８４に格納する。この時、バッチ処理機能５３は入力情報ＤＢ８１もしくは保留情報ＤＢ８３の入力となったバッチ対象データを削除する。出力情報ＤＢ８４は下流のバッチ処理の入力情報となる。
【００４４】
ステップ３１１において、バッチ対象データがガード条件をクリアしていない場合、ガード機能５１は該当データを保留情報ＤＢ８３に格納する。
【００４５】
ステップ３１２において、ガード機能５１は新規にバッチ対象データが入力される度に、保留情報ＤＢ８３に格納されている全てのデータがガード条件をクリアしているかを判定する。つまり、ステップ３０３が実行されるたびに、保留情報ＤＢ８３に格納されている各データに対してステップ３０８の判定を実行する。
【００４６】
本実施の形態において、処理済みのバッチ対象データに取消し・変更が発生した場合のシステム構成を図８に示す。
【００４７】
取消し情報ＤＢ（１）８５とは、取消し処理を実行するためのデータ（取消しデータ）が格納された記憶装置である。取消し機能５４とは、取消し情報ＤＢ（１）８５に格納された取消しデータを使用してバッチ対象データの処理結果を取り消す機能を提供する。取消し情報ＤＢ（２）８６とは、下流（次フェーズ）のバッチ処理に対する取消しデータを格納する記憶装置である。入力情報ＤＢ８１、ガード機能５１、保留情報ＤＢ８３、出力情報ＤＢ８４、バッチ管理機能３０は、図６の同番号のものと同じである。
【００４８】
本実施の形態において、図８のシステム構成で、処理済みのバッチ対象データに対する取消し処理の処理手順を示すフローチャートを図９に示す。
【００４９】
ステップ４０２において、あるバッチ対象データの処理結果に対して取消し処理が必要となった場合、システム運用で取消し情報ＤＢ（１）８５に取消しデータを登録する。取消しデータの内容はバッチ処理の内容に依存するが、必ずキー情報としてデータＩＤを保持する。データＩＤとはバッチ対象データを一意に識別する情報であり、取消しデータのデータＩＤと等しいバッチ対象データの処理結果に対して取消し処理を実行する。
【００５０】
ステップ４０３において、バッチ管理機能３０が取消し処理を起動する。バッチ管理機能３０は定期的に取消し情報ＤＢ（１）８５を監視しており、取消しデータが登録されたことを検知するとガード機能５１と取消し機能５４を起動する。
【００５１】
ステップ４０４において、バッチ管理機能３０は取消し情報ＤＢ（１）８５から取消しデータを取得してガード機能５１に送付する。ガード機能５１を設けていない場合、バッチ管理機能３０は取消し機能５４に取消しデータを送付する。
【００５２】
ステップ４０５において、ガード機能５１は取消しデータのデータＩＤを抽出する。そして、抽出した取消しデータのデータＩＤと同じデータＩＤを持つバッチ対象データが保留情報ＤＢ８３に格納されていないかを判定する。
【００５３】
ステップ４０６において、取消しデータのデータＩＤと同じデータＩＤを持つバッチ対象データが保留情報ＤＢ８３に格納されていた場合、そのデータＩＤを持つバッチ対象データを保留情報ＤＢ８３から削除する。
【００５４】
ステップ４０７において、取消しデータのデータＩＤと同じデータＩＤを持つバッチ対象データが保留情報ＤＢ８３に格納されていない場合、ガード機能５１は取消しデータを取消し機能５４に渡す。取消し機能５４は、そのデータＩＤを持つバッチ対象データに対する取消し処理を実行する。取消し処理の内容はバッチ処理の内容に依存するが、結果として出力情報ＤＢ８４に格納されている該当データＩＤのバッチ対象データの処理結果を削除もしくは変更する。
【００５５】
ステップ４０８において、取消し機能５４は、下流（次フェーズ）のバッチ処理に対する取消しデータを取消し情報ＤＢ（２）８６に登録する。取消し処理を下流に伝播させるために、ステップ４０７において削除もしくは変更した出力情報ＤＢ８４のデータのデータＩＤを持つ取消しデータを取消し情報ＤＢ（２）８６に登録する。
【００５６】
処理済みのバッチ対象データに変更が発生した場合、処理結果を更新する必要がある。この場合は、該当するバッチ対象データに対する取消し処理を実行後、変更後のバッチ対象データに対するバッチ処理を実行することで対処できる。
【産業上の利用可能性】
【００５７】
本発明により、バッチ処理の性能を向上させることが可能になる。
【図面の簡単な説明】
【００５８】
【図１】通常のバッチシステムの方式
【図２】オンラインと並行に実施するバッチシステムの方式
【図３】逐次処理方式のバッチシステムの方式
【図４】全体システム構成図
【図５】バッチ処理が実行されるまでの処理手順を示すフローチャート
【図６】バッチ処理のシステム構成図
【図７】バッチ処理の処理手順を示すフローチャート
【図８】取消し処理のシステム構成図
【図９】取消し処理の処理手順を示すフローチャート
【符号の説明】
【００５９】
１０…オンライン処理サーバ
２０…バッチ処理サーバ
３０…バッチ管理機能
４０…バッチ処理の開始
５０…バッチ処理（フェーズ１）
５１…ガード機能
５２…ガード条件定義ファイル
５３…バッチ処理機能
５４…取消し機能
６０…バッチ処理（フェーズ２）
７０…バッチ処理（フェーズ３）
８０…データベース（ＤＢ）
８１…入力情報ＤＢ
８２…条件適用テーブル
８３…保留情報ＤＢ
８４…出力情報ＤＢ
８５…取消し情報ＤＢ（１）
８６…取消し情報ＤＢ（２）
【図１】
2008097476.tif 000003
【図２】
2008097476.tif 000004
【図３】
2008097476.tif 000005
【図４】
2008097476.tif 000006
【図５】
2008097476.tif 000007
【図６】
2008097476.tif 000008
【図７】
2008097476.tif 000009
【図８】
2008097476.tif 000010
【図９】
2008097476.tif 000011