JP2016009423A - 情報処理装置、情報処理装置の制御方法、およびプログラム - Google Patents

Abstract

【課題】バッチ処理の際に、リトライしたとしても解消することのないエラーの場合に、エラー原因となったデータを容易に特定する情報処理装置、情報処理装置の制御方法、およびプログラムを提供する。
【解決手段】ユニット単位を１つのトランザクション１６０１として、データの更新処理を行った後、エラーとなったユニット１６０２が存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度ユニット分けし、更新処理を再度行う。これにより、エラーとなったユニットに含まれるデータ数を少なくすることができるため、どのデータに不具合があるのか特定することが容易になる。
【選択図】図１６

Description

本発明は、バッチ処理を行う情報処理装置、情報処理装置の制御方法、およびプログラムに関する。

近年、企業内では、クライアント端末に特別なアプリケーションをインストールすることなく業務が行えるように、業務用アプリケーションのＷｅｂ化が急速に進んでいる。そしてこのような業務アプリケーションの開発現場においては、開発スキル不足や要員不足を解決するために、Ｗｅｂアプリケーションをプログラミングレスで容易に作成できる開発ツールが用いられている。このような開発ツールを用いると、プログラミングう言語の知識を有していなくても、業務・設計ノウハウを活用して基本設計情報を定義するだけで、Ｗｅｂアプリケーションを自動生成することができる。

ところで、このようなＷｅｂアプリケーションを用いて入力されるデータベースでは、例えば、大量に発生するデータの更新や不要データの削除など、定期的なメンテナンスが必要となる場合がある。このような大量のデータメンテナンスを、１件ごとに行うことは困難であるため、バッチプログラムを開発してトランザクション単位で処理されることが一般的である。

Ｗｅｂアプリケーションの管理者は、このようなバッチプログラムも用いることで、定期的にデータのメンテナンスを行うことになるが、このようなバッチ処理は毎回処理が成功するとは限らず、処理中にエラーが発生して処理が中断してしまうことがある。このようなエラーの原因としては、ネットワークやメモリ等の利用環境に不具合がある場合や、トランザクション内のデータに不整合がある場合や、バッチプログラムの不具合がある場合など、複数の理由が考えられる。

このような不具合の種類によっては何回かバッチプログラムを実行すると処理が行えることもあるため、エラーが発生した場合にはバッチプログラムを再度実行（リトライ）することが通常である。しかしながらエラーの種類によってはバッチプログラムを再度実行してもエラーが解消しないこともあるため、リトライを際限なく繰り返さないようにする仕組みが必要となる。このような仕組みとして特許文献１には、リトライ回数が規定の回数より少ない場合のみリトライし、規定回数以上となった場合にはリカバリ処理を行わないようにすることが開示されている。さらに特許文献１では、エラーの種類ごとにリトライ回数を定めておくことにより、エラー種別に応じて適切な数だけリカバリ処理が行えることが開示されている。

特開２０１０−１７６３０３号公報

しかしながら、特許文献１の方法を用いたとしても、リトライ回数を超えて異常終了となった場合、管理者はトランザクション内のエラー原因となっているデータを特定し、適宜修正を行う必要であった。そして、１トランザクション内には複数のデータが含まれており、不整合のデータの特定作業はかなり煩雑であることから、エラーの原因となっているデータを容易に特定できる仕組みが求められている。

本実施形態は、上記課題を鑑みてなされたものであり、バッチ処理においてエラーが発生したとしても、当該エラーの原因となったデータを容易に特定することができる仕組みを提供することを目的としている。

複数のデータを記憶する記憶手段を備えたサーバ装置と通信可能に設けられた情報処理装置であって、前記複数のデータを複数のユニットに区分けする第１の区分手段と、前記区分けされたユニットを１つのトランザクションとして、前記記憶手段のデータの更新処理を行う更新手段と、前記更新処理でエラーとなったユニットが存在するか否かを特定する特定手段と、前記特定手段でエラーとなったユニットが存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度区分けする第２の区分手段と、前記特定手段でエラーとなったユニットが存在すると特定された場合には、前記第２の区分手段で再度区分けされたユニット単位で、前記更新手段に前記更新処理を再度行わせるリトライ手段と、を有することを特徴とする情報処理装置。

このように、１つのトランザクションで処理されるデータの数が減るようにリトライ処理を行うことで、エラーとなったユニットに含まれるデータ数を少なくすることができる。これにより、バッチ処理においてエラーが発生したとしてもエラーの原因となるデータを容易に特定することができる。

Ｗｅｂアプリケーション自動生成システム（情報処理システム）のシステム構成の一例を示す図である。 開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理端末１０４のハードウェア構成を示す図である。 Ｗｅｂアプリケーション自動生成システムの機能構成を説明するための図である。 データベース定義１１１の一例を説明するための図である。 データモデル定義１１２の一例を説明するための図である。 ビジネスプロセス定義１１３の一例を説明するための図である。 入出力定義１１４の一例を説明するための図である。 Ｗｅｂアプリケーションを自動生成する際の流れを説明するためのフローチャートである。 ユーザ登録画面９０１の一例を示す図である。 ユーザ一覧画面１００１の一例を示す図である。 バッチ入出力定義１５１の一例を説明するための図である。 バッチアプリケーションを自動生成する際の流れを説明するためのフローチャートである。 バッチ処理時の流れを説明するためのフローチャートである。 バッチ処理時の流れを説明するためのフローチャートである。 エラー処理時の流れを説明するためのフローチャートである。 トランザクションのエラーリトライ処理を説明するための概念図である。

以下、図面を参照して、本発明の実施形態を詳細に説明する。

図１は、本実施形態におけるＷｅｂアプリケーション自動生成システム（以下、情報処理システムとも称する）のシステム構成を示す図である。本発明のＷｅｂアプリケーション自動生成システムは、開発用端末１０１、サーバ１０２（サーバ装置）、利用者用端末１０３、バッチ処理用端末１０４が、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワーク１０５を介して相互にデータ通信可能に接続されている。

Ｗｅｂアプリケーションとは、企業内で用いられる業務用アプリケーションをＷｅｂ上で実施することができるアプリケーションのことであり、クライアント端末上に特別なアプリケーションをインストールすることなく業務を行うことができるため、近年広く用いられている。本発明のＷｅｂアプリケーションシステムは、このようなＷｅｂアプリケーションを指定した要件定義情報からプログラミングレスで自動生成することができるシステムである。このようなシステムを用いることにより、開発スキルが不足していたしても各企業内で容易にＷｅｂ上の業務アプリケーションを開発することができる。

図１に示す開発用端末１０１には、Ｗｅｂアプリケーション（プログラム）を自動生成する際に開発者が使用する端末でありプログラムを自動生成する開発ツールがインストールされている。この端末で予め要件定義を行い、開発ツールに読み込ませて自動生成処理を行うことでＷｅｂアプリケーション１３０（プログラム）が生成される。また、Ｗｅｂアプリケーションで生成されたデータの更新作業をバッチ処理として行う際に用いる要件定義行っておき、同様にこれを開発ツールに読み込ませて自動生成処理を行うことで、バッチアプリケーション１７０（プログラム）が生成される。

サーバ１０２は、開発用端末１０１で生成されたＷｅｂアプリケーション（プログラム）を保持運用し、業務アプリケーションを本番環境として提供するために用いられる。そして、利用者用端末１０３を介してＷｅｂアプリケーション１３０（プログラム）へのアクセスを受け付ける。そして、Ｗｅｂアプリケーションを用いて生成されたデータをデータベース１４０内に記憶している。

利用者用端末１０３は、一般に本番環境において業務アプリケーションを利用するユーザが利用する端末であり、本端末を用いてサーバ１０２に接続することで、Ｗｅｂ化されたアプリケーションを利用することができる。

バッチ処理端末１０４は、Ｗｅｂアプリケーションを管理する管理者が使用する端末であり、バッチアプリケーション１７０を記憶しており、当該バッチアプリケーション１７０を用いてサーバ１０２に記憶されたデータの更新処理をバッチ処理として行う指示を出す際に用いられる。

図２は、開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理端末１０４のハードウェア構成を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１（記憶手段）には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理端末１０４の実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボードや不図示のマウス等のポインティングデバイス等の入力デバイス２０９からの入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ディスプレイ２１０等の表示器への表示を制御する。表示器の種類はＣＲＴや、液晶ディスプレイを想定するが、これに限らない。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明の開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理端末１０４が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行可能となるものである。

さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１に格納されている。

図３は、Ｗｅｂアプリケーション自動生成システムの構成図および生成されたアプリケーション等の機能構成を説明するための図である。

開発用端末１０１は、Ｗｅｂアプリケーション定義部１１０とバッチアプリケーション定義部１５０とＷｅｂアプリケーション生成部１２０とソースコード保持部１２１とバッチアプリ生成部１６０を有している。

サーバ１０２は、開発用端末１０１のＷｅｂアプリ生成部１２０で生成されたＷｅｂアプリケーション１３０を保持し、利用者用端末１０３から入力データ等をデータベースに記憶している。

バッチ処理用端末１０４は、開発用端末１０１のバッチアプリ生成部１６０で生成されたバッチアプリケーション１７０と、バッチ処理のために用いるファイルの入力を受け付けるファイル入力部１９０と、バッチ処理でエラーとなったデータが出力されるエラー出力部１８０を有している。

（Ｗｅｂアプリケーションの自動生成処理）
次に、図３乃至図１０を用いて、開発者がＷｅｂアプリケーションを開発用端末１０１で自動生成する際の流れを説明する。図４乃至７は、図３のＷｅｂアプリケーション定義部１１０に記憶されるデータベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、入出力定義１１４等の開発者によって予め設定した定義の一例を示したものである。

図４はＷｅｂアプリケーションがアクセスするサーバの設定を記憶したデータベース定義１１１である。図４に示すように、データベース定義には、サーバ１０２のコード４０１、サーバの名前４０２、接続ＵＲＬ情報４０３、サーバの種類４０４、データベース名４０５、アプリケーションがデータベースにアクセスする際に必要となるユーザ名４０６及びパスワード４０７が定義されている。

図５は、スキーマ情報として定義されるデータモデル定義１１２である。図５（ａ）に示すように、各データモデル定義は、コード５０１と名前５０２を付与して管理されており、詳細定義もそれぞれ定義されている。例えば図５（ａ）のコード『Ｕｓｅｒ』では、図５（ｂ）に示す項目５１０と図５（ｃ）に示す操作コード５２０が詳細定義されている。

図５（ｂ）は、データベース上で受け付ける項目として、項目コード５１１、項目の名前５１２、ＮＵＬＬを許可するか否かを設定する項目５１３、桁数５１４、データタイプ５１５を定義している。この例では、データモデル「ＵＳＥＲＳ」に対して、「ＩＤ」から「ＰＨＯＮＥ」までのデータモデル項目を定義している。ここで定義する各項目はＷｅｂアプリケーションが接続するデータベースのテーブルのカラム名と一致する。

図５（ｃ）は、データモデルに対する操作をどのように受け付けるかを設定した操作コードであり、操作コード５２１、当該操作の名前５２２、操作タイプ５２３が定義されている。すなわち、データモデルが関連するテーブルに対して操作内容を定義するものである。ここでは、操作コード『ＲＥＧＩＳＴ』というコードを有するユーザ登録操作は、操作タイプ『ＩＮＳＥＲＴ』であると定義されており、つまりユーザ登録操作で入力されたデータがデータベースに挿入されるというように定義されている。

図６は、Ｗｅｂアプリケーションの業務フローを定義するためのビジネスプロセス定義１１３である。図６（ａ）に示すように、各ビジネスプロセス定義は、コード６０１と名前６０２を付与して管理されており、詳細なロジック定義もそれぞれ定義されている。なお、ビジネスプロセスのコード６０１は、後述する入出力定義からの呼び出し指定するコードとして用いられる。詳細なロジック定義としては、図６（ｂ）に示すように、制御コード６１１、データモデルコード６１２、機能コード６１３、パラメータ６１４、作業コード６１５が設定されている。

例えば図６（ａ）のコード『ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ』のビジネスプロセス定義では、制御コード６１１の設定順に以下のような処理が行われる。この例ではＷｅｂ画面の入力内容を制御コード「ＩＮ」で受け取り、受け取ったデータを作業コード「ＩＮＰＵＴ」として定義している。次に制御コード「ＣＡＬＬ」でデータモデル「ＵＳＥＲ」に対する操作を定義している。つまり、まず（１）『ＩＮ』制御として、図５のＵＳＥＲ（ユーザマスタ）というデータモデルコード５０１から、入力データを取得する。その際に、当該作業コードに『ＩＮＰＵＴ』というコードを付与する。次に、（２）『ＣＡＬＬ』制御として、図５（ｃ）のデータモデル定義の操作コードとして設定されており『ＩＮＳＥＲＴ』処理を、『ＩＮ』制御で読み込んだ入力データ（作業コード『ＩＮＰＵＴ』）に対して行うビジネスロジックが定義している。

図７は、Ｗｅｂ画面に配置する各表示項目の入出力定義１１４である。ここで設定されている項目が、利用者用端末１０３の表示画面に表示され、本番環境時にユーザが用いる画面として用いられる。図７（ａ）に示すように、各入出力定義は、コード７０１と名前７０２を付与して管理されており、詳細な項目定義もそれぞれされている。例えば図７（ａ）のコード『ＵＳＥＲ＿ＲＥＧＩＳＴ』では、図７（ｂ）に示す項目タイプ７１１、項目コード７１２、名前７１３、表示７１４、加工式７１５、次入出力７１６、データモデルコード７１７、データモデル項目コード７１８が定義されている。

この例では、項目タイプ「ＩＯ入出力」と定義されている項目は入出力項目（データを入力およびデータを表示する「フィールド」）である。項目タイプ「Ａアクション」と定義されている項目はアクション項目（処理を呼び出し、画面を遷移する「ボタン」）である。この例における、項目コード「ＲＥＧＩＳＴ＿ＢＰ」はアクション項目である。アクション項目「ＲＥＧＩＳＴ＿ＢＰ」の加工式７１５には、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」が定義されている。「ＲＥＧＩＳＴ＿ＢＰ」のアクションでは、ビジネスプロセス「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」が呼び出されることを示す定義である。そして、次入出力先として、「ＵＳＥＲ＿ＬＩＳＴ」のコードが定義されている。すなわち、「登録」アクションが行われると、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」の加工式で定義されたアクションが実行された後、「ＵＳＥＲ＿ＬＩＳＴ」に画面遷移することが定義されている。

図９が、入出力定義１１４で定義された「ＵＳＥＲ＿ＲＥＧＩＳＴ（ユーザ登録）」のＷｅｂ画面の一例である。この画面により利用者用端末１０３を介してユーザがユーザ登録処理を行うことができる。ユーザＩＤ９０２、ユーザ名９０３、ふりがな９０４、性別９０５、年齢９０６、誕生日９０７、電話番号９０８、登録ボタン９０９、戻るボタン９１０は、それぞれ図７（ｂ）の項目名前７１３に設定された項目に対応している。

図１０は、入出力定義１１４で定義された「ＵＳＥＲ＿ＬＩＳＴ（ユーザ一覧）」のＷｅｂ画面の一例である。つまりこの例では、図９の画面で各項目が入力され登録ボタン９０９が押下されると、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」の加工式で定義されたユーザ登録処理が行われ、その結果「ＵＳＥＲ＿ＬＩＳＴ」として表示されるように定義されている。

図８は、図４乃至７に示すようなＷｅｂアプリケーション定義部１１０に記憶されているデータベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、入出力定義１１４等の要件定義がされた後、Ｗｅｂアプリケーションを自動生成する際の流れを説明するためのフローチャートである。

このような処理は、開発用端末１０１のＣＰＵ２０１が記憶されている制御プログラムを読み出して実行することにより実現される。

まず、Ｓ８０１では、開発用端末１０１のＣＰＵ２０１が、データベース定義１１１をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ８０２では、データモデル定義１１２をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ８０３では、ビジネスプロセス定義１１３をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ８０４では、入出力定義１１４をＷｅｂアプリケーション定義部１１０から読み込む。

このような定義はＸＭＬ形式で記述されているため、Ｓ８０５では、開発用端末１０１のＣＰＵ２０１が、ＸＭＬファイルを構造解析し、必要な定義内容をメモリ上にオブジェクトデータとして保存する。

次に、Ｓ８０６では、生成処理は開発用端末１０１のＣＰＵ２０１がＷｅｂアプリ生成部１２０として機能し、予め設定されているソースコードテンプレートを、ソースコード保持部１２１から読み込み、Ｓ８０７でメモリ上に保存した定義データをソースコードテンプレートに埋め込んだ、ソースコードファイル、すなわちＷｅｂアプリケーションを生成する。

以上のように、予め定義した要件定義とソースコードを用いることにより、Ｗｅｂアプリケーションが自動生成される。開発者は、このように生成したＷｅｂアプリケーションを、サーバ１０２に保存して業務アプリケーションの開発作業を終了する。

（バッチアプリケーションの自動生成処理）
次に、図３、図１１及び図１２を用いて、Ｗｅｂアプリケーションの管理者がデータベース１４０に記憶されたデータの更新をバッチ処理として行う際に用いる、バッチアプリケーションを、開発者が開発用端末１０１で自動生成する際の流れを説明する。

一般的にＷｅｂアプリケーションを運用していくためには適宜バッチ処理を行い、データのメンテナンスを行うということが必要となる。本実施形態ではＷｅｂアプリケーションを用いてユーザ登録をする例で説明しているが、このようなアプリケーションを用いた業務で１日に大量のユーザ登録がなされた場合や一度に大量のユーザデータの編集が行われる際には、処理を一括で進めることができるようにバッチ処理を行うことが通常である。このようなバッチ処理に用いるアプリケーションは、個別開発を行うことが一般的であるが、本実施形態におけるバッチアプリケーションは、Ｗｅｂアプリケーションで画面単位に行っていた処理をバッチ化するのみでよいため、多くの部分で共通な領域が存在する。このバッチアプリケーションの自動生成処理ではＷｅｂアプリケーション定義をそのまま用い、最小限の定義を追加するだけで、Ｗｅｂアプリケーションで行っていた操作の機能を有するバッチアプリケーションを容易に作成することができる。

図１１のバッチ入出力定義は、バッチアプリケーションへの入力データとなる項目一覧を定義したもので、図３のバッチアプリケーション定義部１５０に記憶されるバッチ入出力定義１５１の一例を示したものである。Ｗｅｂアプリケーションの入出力定義と異なり、バッチアプリケーションは利用者による入出力がＷｅｂ画面上で行われることはないため、画面定義としては不要であるが、このように、入出力定義１１４に対応する項目をバッチ入出力定義１５１として用意しておくことにより、Ｗｅｂアプリケーション定義部１１０に定義された、データベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、を再度バッチ処理用に用意することなくそのまま利用し、バッチアプリケーションを自動生成させることができる。

図１１（ａ）に示すように、バッチ入出力定義１５１は、コード１１０１と名前１１０２と、ｄａｔａＵｎｉｔ値１１０３を付与して管理されており、さらに詳細な項目定義もされている。例えば図１１（ａ）のコード『ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＡＴＣＨ』では、図１１（ｂ）に示す項目タイプ１１１１、項目コード１１１２、名前１１１３、表示１１１４、加工式１１１５、次入出力１１１６、データモデルコード１１１７、データモデル項目コード１１１８が定義されている。

これらの図１１（ｂ）の項目は図７の入出力定義１１４の項目とほぼ同じであり、大きく異なるのはｄａｔａＵｎｉｔ値１１０３が定義されている点である。なお、バッチアプリケーションでは、アクション項目「Ｂ戻る」が定義されていないが、これは、バッチ処理においては、元の画面へ「戻る」処理が不要であるからである。

ｄａｔａＵｎｉｔ値１１０３とはバッチアプリケーションによる大量のデータ処理に対して、何件毎にコミット処理を行うかを設定する値である。例えば、１万件のユーザ登録に対して、ｄａｔａＵｎｉｔを１００に設定すると、１００回のトランザクション処理が発生し、１００回コミットするバッチ処理となる。ここで設定されるｄａｔａＵｎｉｔ値が小さすぎると、データベース接続、コミット処理、クローズ処理に係る処理時間が大きくなり、バッチ処理全体のパフォーマンスが悪くなる。一方、ｄａｔａＵｎｉｔ値が大きすぎると、トランザクション当たりのデータ量が多くなり、メモリエラーが発生する可能性が高くなる。そのため、バッチアプリケーションに合わせた最適なｄａｔａＵｎｉｔ値を決定する必要がある。

バッチ入出力定義に定義されているアクション項目「ＥＸＥＣ＿ＡＣＴＩＯＮ登録」の加工式１１１５には、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」が定義されている。この「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」は図６に示すＷｅｂアプリケーションで利用しているビジネスプロセス定義のコードである。すなわち、このように定義しておくことによりバッチアプリケーションからもＷｅｂアプリケーションと同様のビジネスプロセス定義を利用することが可能であり、バッチアプリケーション用にビジネスプロセスを作成する必要がない。Ｗｅｂアプリケーションのビジネスプロセス定義をバッチアプリケーションでも利用することにより、そしてビジネスプロセス定義で利用されているデータモデル定義、さらにはデータベース定義についても、Ｗｅｂアプリケーションで利用した定義をそのまま利用することができる。

図１６は、図４乃至６に示すようなＷｅｂアプリケーション定義部１１０に記憶されているデータベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、等の要件定義がされ、さらに図１１に示すバッチアプリケーション定義部１５０に記憶されているバッチ入出力定義１５１がされた後に、バッチアプリケーションを自動生成する際の流れを説明するためのフローチャートである。

このような処理は、開発用端末１０１のＣＰＵ２０１が記憶されている制御プログラムを読み出して実行することにより実現される。

まず、Ｓ１２０１では、開発用端末１０１のＣＰＵ２０１が、データベース定義１１１をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ１２０２では、データモデル定義１１２をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ１２０３では、ビジネスプロセス定義１１３をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ１２０４では、バッチ入出力定義１５１をバッチアプリケーション定義部１５０から読み込む。

このような定義はＸＭＬ形式で記述されているため、Ｓ１２０５では、開発用端末１０１のＣＰＵ２０１が、ＸＭＬファイルを構造解析し、必要な定義内容をメモリ上にオブジェクトデータとして保存する。

次に、Ｓ１２０６では、開発用端末１０１のＣＰＵ２０１がバッチアプリ生成部１６０として機能し、予め設定されているソースコードテンプレートを、ソースコード保持部１２１から読み込み、Ｓ１２０７でメモリ上に保存した定義データをソースコードテンプレートに埋め込んだ、ソースコードファイル、すなわちバッチアプリケーションを生成する。

以上のように、予め定義した要件定義とソースコードを用いることにより、バッチアプリケーションが自動生成される。開発者は、このように生成したバッチアプリケーションを、バッチ処理用端末１０４に保存してバッチアプリケーションの生成作業を終了する。

（バッチアプリケーションによるバッチ処理）
通常Ｗｅｂアプリケーションの管理者は、上記のように生成されたバッチプログラムを用いて定期的にデータのメンテナンスを行うが、このようなバッチプログラムによるバッチ処理は毎回成功するとは限らず、処理中にエラーが発生して処理が中断してしまうことがある。このようなエラーの原因としては、ネットワークやメモリ等の利用環境に不具合がある場合や、トランザクション内のデータに不整合がある場合や、バッチプログラムの不具合がある場合など、複数の理由が考えられる。このような不具合の種類によっては何回かバッチプログラムを実行するとエラーが解消して処理が行えることもあるため、エラーが発生した場合にはバッチプログラムを再度実行（リトライ）することが通常である。しかしながらエラーの種類によってはバッチプログラムを再度実行してもエラーが解消しないこともあるため、所定回数繰り返したのちリトライを行ことなく異常終了させ、管理者が事後的にエラーの原因となったデータを特定し、適宜修正を行っていた。

しかし１トランザクション内にはｄａｔａＵｎｉｔ値１１０３として設定されているように、複数のデータが一括して処理するように設定されており、管理者による不整合のデータの特定作業はかなり煩雑である。そのためこのようなエラーの原因となっているデータを容易に特定できるバッチ処理方法が求められている。

ここでは、図３、図１３乃至図１６を用いて、エラーの原因となっているデータを容易に特定できるようなバッチ処理を説明する。

Ｗｅｂアプリケーションの管理者は、バッチ処理端末１０４に記憶されたバッチアプリケーションを用いてバッチ処理を行う。このようなバッチ処理はサーバ１０２に負荷がかかるため、他の業務が行われない深夜等にまとめて行われるのが一般的である。

バッチ処理用端末１０４には、図３に示すようにバッチアプリケーション１７０と、バッチ処理に用いるファイル入力部１９０と、バッチ処理に失敗した際に生成されるエラーファイル１８１が出力されるエラー出力部１８０が設けられている。

ファイル入力部１９０からは、例えばＣＳＶ形式のバッチ処理に用いるファイル入力を受け付けることができる。バッチアプリケーション１７０は、ファイル取得部１７２と、バッチ処理部１７１と、バッチエラー出力部１７３と、ｄａｔａＵｎｉｔ値管理部１７４とを有している。ファイル入力部１９０から入力された入力ファイルは、ファイル取得部１７２で取得される。そしてバッチ処理動作が実行されると、詳細は後述するがバッチ処理部１７１がデータベース１４０に対して１つのトランザクションごとに処理を行いコミットさせるか、エラーが発生したとしてトランザクションをロールバックさせる。

バッチエラー出力部１７３は、バッチ処理部１７１でエラーが発生したトランザクションについてのエラーファイル１８１をエラー出力部１８０に出力させる。そして、ファイル取得部１７２は、このようなエラーファイル１８１を更新データとして用いてリトライ処理を行う。

次に図１３乃至図１５のフローチャートを用いて本実施形態におけるバッチ処理及びリトライ処理についての流れを説明する。このような処理は、バッチ処理用端末１０４のＣＰＵ２０１が記憶されている制御プログラムを読み出して実行することにより実現される。

Ｓ１３０１では、バッチ処理用端末１０４のＣＰＵ２０１のファイル取得部１７２が、ファイル入力部１９０から入力されたファイルを取得する。

Ｓ１３０２では、バッチ処理用端末１０４のＣＰＵ２０１がバッチアプリケーションとして定義されたｄａｔａＵｎｉｔ値１１０３を初期のｄａｔａＵｎｉｔ値として取得し、ｄａｔａＵｎｉｔ値管理部１７４に記憶する。

Ｓ１３０３では、バッチ処理用端末１０４のＣＰＵ２０１のバッチ処理部１７１が区分手段として機能し、ファイル取得部１７２で取得したファイルの入力データを、ｄａｔａＵｎｉｔ値管理部１７４に記憶されたｄａｔａＵｎｉｔ値を用いて複数に区分けする。ここでは、区分けされたデータ一覧の単位を１つのトランザクションとして更新処理されるユニットと呼ぶ。

Ｓ１３０４では、バッチ処理用端末１０４のＣＰＵ２０１がユニット分だけ繰り返して図１４に示すバッチ処理を行う。

Ｓ１４０１では、バッチ処理用端末１０４のＣＰＵ２０１がデータベース１４０に対してデータをユニット単位で更新するトランザクション処理の実行を行う（更新処理）。

Ｓ１４０２では、バッチ処理用端末１０４のＣＰＵ２０１が、トランザクション処理中にエラーが発生したかを判断する。

トランザクション処理中にエラーが発生しなかったと判断した場合には、Ｓ１４０３では、バッチ処理用端末１０４のＣＰＵ２０１が、更新処理は無事に終了したとして、トランザクションのコミット待ち領域に当該処理結果を格納する。そして、Ｓ１４０４では、当該ユニットに関するトランザクションをコミットする。

一方、トランザクション処理が成功しなかった場合には、Ｓ１４０５に進み、当該ユニットに含まれるデータをすべてエラーファイルに出力する。そしてエラーファイルに出力後、Ｓ１４０６にて当該ユニットに関するトランザクションをロールバックする。

このようなバッチ処理を、Ｓ１３０３で区分けして生成されたユニット分繰り返し行う。そしてすべてのユニットに関する処理が完了すると、バッチ処理の繰り返しは終了する。

次に、全ユニット分のバッチ処理が終了した後に、Ｓ１３０５において、Ｓ１３０７で行われたリトライ処理の回数が既に所定の回数未満であるか判断する。リトライ回数は、管理者が任意に設定することができる値であり、この所定の回数以上である場合には、トランザクションのリトライ処理が必要以上に多すぎてサーバ等に負荷をかけることになるため、まだエラーが含まれているユニットとして「異常終了」ユニットとしてエラー出力部１８０に記憶させて終了する。このように異常終了されたユニットは、管理者が個別に更新処理を行う。

一方、Ｓ１３０５においてリトライ回数が所定未満の場合には、再度リトライ処理に進むべくＳ１３０６に進む。そして、Ｓ１３０６では、バッチ処理用端末１０４のＣＰＵ２０１が、エラー出力部１８０にエラーファイル１８１として出力されたファイルが存在するか否かを判断する。Ｓ１３０６でエラーファイル１８１が存在しないと判断された場合には、全てのユニットでエラーが発生することなくバッチ処理が完了したとして、処理を終了する。

一方、Ｓ１３０６でエラー出力部１８０にエラーファイル１８１として出力したファイルが存在すると判断、すなわち更新処理でエラーとなったユニットが存在すると特定した場合には、Ｓ１３０７に進み、図１５に示すリトライ処理を行う。

Ｓ１５０１では、まずｄａｔａＵｎｉｔ値管理部１７４に記憶されているｄａｔａＵｎｉｔ値（ｎ）を２で除して、ｄａｔａＵｎｉｔ値（ｎ＋１）を算出する。算出されたｄａｔａＵｎｉｔ値（ｎ＋１）が、小数点以下を含む場合には、切り捨てをおこない、整数となるようにする。なお、ここでの算出処理は、ｄａｔａＵｎｉｔ値（ｎ＋１）が、予め記憶されているｄａｔａＵｎｉｔ値より小さな値となればよく、２で除する場合に限られない。

Ｓ１５０２では、バッチ処理用端末１０４のＣＰＵ２０１が、Ｓ１５０１で算出されたｄａｔａＵｎｉｔ値（ｎ＋１）が所定の値未満か判断する。所定の値未満である場合には、ユニットのデータ数をこれ以上小さくできないため、処理を終了する。なお、本実施例では、所定の値が１を例示しているが、この値は適宜管理者が設定することが可能である。

Ｓ１５０２でｄａｔａＵｎｉｔ値（ｎ＋１）が所定の値以上と判断された場合には、Ｓ１５０３に進み、ｄａｔａＵｎｉｔ値管理部１７４に記憶されているｄａｔａＵｎｉｔ値をＳ１５０１で算出されたｄａｔａＵｎｉｔ値（ｎ＋１）に更新する。

Ｓ１５０４では、バッチ処理用端末１０４のＣＰＵ２０１が、エラー出力部１８０に出力されたエラーファイル１８１を取得する（メモリ内に読み込む）。そして、Ｓ１５０５で、エラーファイル１８１を、ｄａｔａＵｎｉｔ値管理部１７４に記憶されたｄａｔａＵｎｉｔ値を用いて複数に区分けする。つまりのバッチ処理用端末１０４のＣＰＵ２０１のバッチ処理部１７１が区分手段として機能し、初期のｄａｔａＵｎｉｔ値を２で除して算出されたｄａｔａＵｎｉｔ値（ｎ＋１）を用いて、エラーファイル１８１に含まれるデータの区分けを行う。ここでは、区分けされたデータ一覧の単位を１つのトランザクションとして再更新処理されるエラーユニットと呼ぶ。なお、Ｓ１５０４で取得されたエラーファイル１８１は、取得後に削除される。

そしてＳ１５０６では、Ｓ１３０４と同様に図１４に示したバッチ処理がエラーユニット分繰り返し行われる。そして、Ｓ１５０６のバッチ処理で再度エラーが発生した場合には、Ｓ１３０５に戻る。すなわち、リトライ回数が予め設定された所定回数に達するまで、ユニットに含まれるデータ数を細分化しながらリトライ処理を繰り返し行う。

図１６にこのようなリトライ処理によるバッチ処理の概念図を示す。最初のトランザクション内の処理単位は、ｄａｔａＵｎｉｔ値管理部１７４に初期値として記憶されたｄａｔａＵｎｉｔ値（１）となっている。ここでエラー有とされたユニット１６０２は、エラーリトライ処理（１）においては、初期のｄａｔａＵｎｉｔ値（１）を２で除して算出されたｄａｔａＵｎｉｔ値（２）で区分けされるため、トランザクション内の処理単位は、初期のユニット１６０１の単位の半分となっている。ここでエラーとなったエラーユニット１６０４は、再度、前回のリトライ処理で用いたｄａｔａＵｎｉｔ値（２）を２で除して算出されたｄａｔａＵｎｉｔ値（３）で区分けされるため、トランザクション内の処理単位は、エラーユニット１６０４の半分となっている。

なお、実施形態では、バッチ処理を行う際に用いられる入力データはＣＳＶ形式の入力ファイルによるデータの場合を例に説明したが、データベース１４０にアクセスして抽出したデータを用いても同様に行うことができる。

以上のように、リトライ処理が繰り返されるごとに、１つのトランザクションで処理されるデータの数が減るようにｄａｔａＵｎｉｔ値を更新していくことにより、エラーとなったユニットに含まれるデータ数を少なくすることができる。これにより、バッチ処理においてエラーが発生したとしてもエラーの原因となるデータを容易に特定することができる。さらに、異常終了として処理が行われなかったトランザクション内に含まれる正常のデータ数も少ないことから、管理者が個別にデータ更新処理する際にかかる時間も削減することができる。

また、本実施形態では、リトライ時に１つのユニットを複数に再区分けすることを例に説明をしたが、リトライ時に複数のユニットでエラーが発生していた場合には、複数のユニット内のデータをまとめて区分けしなおしてもよい。言い換えると、例えば２つのエラーが発生したユニットを３つエラーユニットとして再度区分けしてもよい。

なお、本実施形態においては、Ｗｅｂアプリケーション及びバッチアプリケーションを自動生成するツールで生成されたバッチアプリケーションによるバッチ処理のリトライ時の仕組みを例に説明を行ったが、このような仕組みはアプリを自動生成するツールで生成されたバッチアプリケーソン（プログラム）に限られず、バッチ処理するプログラムのいずれにも適用できることは言うまでもない。

本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置の情報処理装置が前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理を情報処理装置で実現する（実行可能とする）ために、前記情報処理装置にインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理を情報処理装置で実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行して情報処理装置にインストールさせて実現することも可能である。

また、情報処理装置が、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、情報処理装置上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、情報処理装置に挿入された機能拡張ボードや情報処理装置に接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１０１ 開発用端末
１０２ サーバ
１０３ 利用者用端末
１０４ バッチ処理端末
１３０ Ｗｅｂアプリケーション
１７０ バッチアプリケーション
１７１ バッチ処理部
１７３ バッチエラー出力部
１７４ ｄａｔａＵｎｉｔ値管理部

Claims (11)

1. 複数のデータを記憶する記憶手段を備えたサーバ装置と通信可能に設けられた情報処理装置であって、
   前記記憶手段に記憶された複数のデータを複数のユニットに区分けする第１の区分手段と、
   前記区分けされたユニットを１つのトランザクションとして、前記記憶手段のデータの更新処理を行う更新手段と、
   前記更新処理でエラーとなったユニットが存在するか否かを特定する特定手段と、
   前記特定手段でエラーとなったユニットが存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度区分けする第２の区分手段と、
   前記特定手段でエラーとなったユニットが存在すると特定された場合には、前記第２の区分手段で再度区分けされたユニット単位で、前記更新手段に前記更新処理を再度実行させるリトライ手段と、を有することを特徴とする情報処理装置。
2. 前記リトライ手段は、前記特定手段でエラーとなったユニットが存在する場合には、前記第２の区分け手段による再度の区分けと、前記リトライ手段による前記更新処理とを繰り返すことを特徴とする請求項１に記載の情報処理装置。
3. 前記リトライ手段は、前記第２の区分手段による再度の区分けと、前記リトライ手段による前記更新処理との繰り返しは、繰り返し回数が所定回数に達するまで行うことを特徴とする請求項２に記載の情報処理装置。
4. 前記リトライ手段は、前記第２の区分手段による再度の区分けと、前記リトライ手段による前記更新処理との繰り返しは、ユニットに含まれるデータ数が所定の数未満となるまで繰り返すことを特徴とする請求項２に記載の情報処理装置。
5. 前記更新手段は、前記更新処理でエラーが発生した場合には、エラーが発生したユニットのトランザクションをロールバックすることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記記憶手段のデータの更新に用いる更新データを取得する取得手段を更に有し、
   前記更新手段は、前記取得手段で取得した更新データを用いて、更新処理を行うことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 複数のデータを記憶する記憶手段を備えたサーバ装置と通信可能に設けられた情報処理装置の制御方法であって、
   前記複数のデータを複数のユニットに区分けする第１の区分工程と、
   前記区分けされたユニットを１つのトランザクションとして、前記記憶手段のデータの更新処理を行う更新工程と、
   前記更新処理でエラーとなったユニットが存在するか否かを特定する特定工程と、
   前記特定工程でエラーとなったユニットが存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度区分けする第２の区分工程と、
   を有し、
   前記特定工程でエラーとなったユニットが存在すると特定された場合には、前記第２の区分工程で再度区分けされたユニット単位で、前記記憶手段のデータの更新処理を行うリトライ工程と、を有することを特徴とする制御方法。
8. 複数のデータを記憶する記憶手段を備えたサーバ装置と通信可能に設けられた情報処理装置で実行可能なプログラムであって、
   前記情報処理装置を、
   前記複数のデータを複数のユニットに区分けする第１の区分手段、
   前記区分けされたユニットを１つのトランザクションとして、前記記憶手段のデータの更新処理を行う更新手段、
   前記更新処理でエラーとなったユニットが存在するか否かを特定する特定手段、
   前記特定手段でエラーとなったユニットが存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度区分けする第２の区分手段、
   前記特定手段でエラーとなったユニットが存在すると特定された場合には、前記第２の区分手段で再度区分けされたユニット単位で、前記更新手段に前記更新処理を再度実行させるリトライ手段、
   として機能させることを特徴とするプログラム。
9. 複数のデータを記憶する記憶手段を備えた情報処理装置であって、
   前記記憶手段に記憶された複数のデータを複数のユニットに区分けする第１の区分手段と、
   前記区分けされたユニットを１つのトランザクションとして、前記記憶手段のデータの更新処理を行う更新手段と、
   前記更新処理でエラーとなったユニットが存在するか否かを特定する特定手段と、
   前記特定手段でエラーとなったユニットが存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度区分けする第２の区分手段と、
   前記特定手段でエラーとなったユニットが存在すると特定された場合には、前記第２の区分手段で再度区分けされたユニット単位で、前記更新手段に前記更新処理を再度実行させるリトライ手段と、を有することを特徴とする情報処理装置。
10. 複数のデータを記憶する記憶手段を備えた情報処理装置の制御方法であって、
    前記複数のデータを複数のユニットに区分けする第１の区分工程と、
    前記区分けされたユニットを１つのトランザクションとして、前記記憶手段のデータの更新処理を行う更新工程と、
    前記更新処理でエラーとなったユニットが存在するか否かを特定する特定工程と、
    前記特定工程でエラーとなったユニットが存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度区分けする第２の区分工程と、
    を有し、
    前記特定工程でエラーとなったユニットが存在すると特定された場合には、前記第２の区分工程で再度区分けされたユニット単位で、前記記憶手段のデータの更新処理を行うリトライ工程と、を有することを特徴とする制御方法。
11. 複数のデータを記憶する記憶手段を備えた情報処理装置で実行可能なプログラムであって、
    前記情報処理装置を、
    前記複数のデータを複数のユニットに区分けする第１の区分手段、
    前記区分けされたユニットを１つのトランザクションとして、前記記憶手段のデータの更新処理を行う更新手段、
    前記更新処理でエラーとなったユニットが存在するか否かを特定する特定手段、
    前記特定手段でエラーとなったユニットが存在すると特定された場合には、当該ユニットを前回のデータ数よりも少ないデータ数となるように再度区分けする第２の区分手段、
    前記特定手段でエラーとなったユニットが存在すると特定された場合には、前記第２の区分手段で再度区分けされたユニット単位で、前記更新手段に前記更新処理を再度実行させるリトライ手段、
    として機能させることを特徴とするプログラム。