JP2015103172A - Ｗｅｂシステムの入力チェック処理システム及び入力チェック処理方法 - Google Patents

Abstract

【課題】Ｗｅｂシステムの入力チェックシステムで画面内項目に対して入力チェックを行う際に、システムの性能を劣化させることなく、項目の属性判定を実施せずともチェックの実行有無を判定できる方式を提供する。【解決手段】チェック定義内に契約種別コードの値に対して、チェック処理の実行可否を設定し、クライアントからのチェック処理要求に対して、契約種別コードの値をもとに、チェック処理定義内に契約種別コードが存在するかを判定し、その判定結果をもとにチェック処理の実行の有無を振り分ける。【選択図】図１

Description

本発明は、Ｗｅｂシステムの入力チェック処理システム及び入力チェック処理方法に関するものである。

従来より、Ｗｅｂシステムの会話型入力処理では、単一な画面項目に入力された入力内容の正当性、および複数の画面項目に入力された入力内容の相互関係、画面項目に入力された入力内容とデータベースで保持するデータの関連性をチェックするための、入力チェック処理が行われている。従来、この入力チェック処理は、プログラム内にアルゴリズムとして記述されていた。もしくは、特許文献１にて公開されている、チェック処理を定義としてアルゴリズムから切り出し、定義を読み込むことでチェック処理を行う方法も知られている。

特開平６−２７４３８９号公報

特許文献１にて公開されているような、チェック仕様の定義を読み込むことで入力チェック処理を実施するシステムでは、定義に記載されている入力チェック処理を網羅的に実施するため、定義中の特定のチェック処理を実行しないという判定はできない。また、定義に記載されているチェック処理を網羅的に実施するため、特定の要件によってチェック処理の結果を切り替えることもできない。

オンラインＷｅｂシステムの中でも電力会社の販売系システムでは、入力チェック処理を行う際に、実施対象の画面項目の属性が非活性や非表示の場合にチェック処理を実施しないこととなっている。また、全てのチェック処理が上記仕様に従うのではなく、ある特定の場合、例えば過去に登録したデータの訂正を行う場合は対象の画面項目が非活性でもチェック処理を実施する。

上記のような仕様のシステムにおける画面内項目に対しての入力チェック処理を実装する場合、特許文献１にて公開されている方式では、アルゴリズム中においてチェック処理の対象の画面項目全ての属性を判定しなければならないため、プログラム中に属性を判定するアルゴリズムを組み込むことが必要不可欠となってしまい、システムの規模が増大してしまう。画面内の項目数が多い場合、もしくは画面内のチェック処理の数が多い場合は、属性を判定する回数が多くなるため、システムの性能が劣化することが懸念される。また、上記したように対象項目が非活性でもチェック処理を実施しなければならない要件が発生した場合、特許文献１にて公開されている方式では、画面項目の属性判定にプラスして特別な分岐処理を行わなければならない。

本発明の課題は、Ｗｅｂシステムの入力チェックシステムで画面内項目に対して入力チェックを行う際に、システムの性能を劣化させることなく、項目の属性判定を実施せずともチェックの実行有無を判定できる方式を提供することにある。

上記課題を解決するために、本発明のＷｅｂシステムの入力チェック処理システムの代表的な例では、イベント処理部と、チェック処理制御部とを備えており、処理対象となるイベントデータには、前記Ｗｅｂシステムのエンドユーザの契約種別コードが含まれており、前記イベント処理部は、処理対象となる前記イベントデータを取得し、前記チェック処理制御部は、前記契約種別コードごとに実施されるべきチェック処理の定義が記載されたチェック処理定義を参照して、受け付けた前記イベントデータの契約種別コードが前記定義に存在するかを判定し、前記定義に前記契約種別コードが含まれる場合、前記イベントデータのチェック処理を実行することを特徴とする。

本発明により、入力チェック処理実行時に多数の画面項目の属性判定を網羅的に行うことが回避され、システム面での性能劣化を防ぐことができる。

本発明の一実施例に係る、Ｗｅｂシステムの入力チェック処理システムの構成の一例を示す図である。 一実施例におけるイベント処理データの生成フローである。 一実施例におけるデータテーブル内部のエンティティ一例である。 一実施例におけるデータテーブル内部のエンティティ一例である。 一実施例におけるチェック処理定義の一例である。 一実施例におけるチェック処理設計書の一例である。 一実施例における画面I/O設計書の一例である。 一実施例におけるチェック処理要求時の処理フローである。 一実施例におけるチェック処理定義生成のフローである。 一実施例におけるチェック処理定義自動生成処理のフローである。

本発明の一実施形態によれば、上記課題を解決するために、チェック仕様の定義内において、入力チェック処理ごとに契約種別の属性を設定し、当該チェック処理を実行可能な契約種別コード（契約種別番号）を記載する。システム側は画面内の各画面項目の属性を判定することなく、クライアント側から送付される当該画面で処理中の契約種別コードがチェック仕様の定義内に設定された契約種別の属性内に含まれているかどうかのみを判定することで、網羅的な判定無しに、チェック実施可否の判定が可能となる。ここで使用するチェック仕様の定義は、チェック処理設計書、および画面I/O設計書から自動生成される仕組みとする。また、上記のようにチェック仕様の定義内に契約種別の属性を設定する方式の場合、メッセージと契約種別のみ異なる定義を準備することで、契約種別ごとに画面に表示するメッセージを切り替えることが可能となる。

以下、本発明の一実施例を、図面を参照しながら説明する。図１は本実施例のＷｅｂシステムの入力チェック処理システムの構成図である。本実施例のシステムは、大別して、入力チェック処理システムのユーザ（以下、単にユーザ）が入力チェック処理要求を行うクライアント１０１と、このユーザの要求に基づいて入力チェック処理を制御するサーバ１０２を備える。クライアント１０１とサーバ１０２はネットワークで接続され通信可能である。サーバ１０２はさらに、操作対処取得部１０３と、イベント処理部１０４、チェック処理制御部１０５、データテーブル１０６、チェック処理定義１０７、イベント結果処理部１０８を備える。サーバ１０２は、さらに、チェック処理用定義のファイルを自動生成するチェック定義生成部（図８参照）も備えている。

イベント処理部１０４は、クライアント１０１で発生したイベントを取得し、イベントデータを取得する。また、操作対象取得部１０３に操作対象お客さまデータ取得要求を行う。なお、この「お客さま」は、電力会社の電力供給のサービスをうける顧客、換言すると、入力チェック処理の対象となる電力会社のＷｅｂシステムの、エンドユーザ（以下、Ｗｅｂシステムのエンドユーザ）である。操作対象取得部１０３はデータテーブル１０６のチェック処理用データテーブルより「お客さまデータ」を取得し、イベント処理部１０４へ返却する。次に、イベント処理部１０４はチェック処理制御部１０５へチェック処理要求を行い、クライアント画面から取得したアクションフォームデータとともにイベント処理データ２０７をチェック処理制御部１０５へ送付する。

チェック処理制御部１０５は、イベント処理データ（図２、２０７）を受け取る。イベント処理部１０４からのチェック処理要求には、画面内の単一項目に対する単一チェック処理要求と、画面内の複数項目に対する相互チェック処理要求と、画面内の項目とチェック処理データテーブル内項目に対する関連チェック処理要求がある。チェック処理制御部１０５ではそれらの要求内容とイベント処理データ、チェック処理データテーブル１０６、チェック処理定義１０７を元にチェック処理の実行可否を判定する。その結果、実行可の場合はチェック処理を実行し、チェック処理結果をイベント処理結果１０８に送付し、実行不可の場合はチェック処理を実行せずにイベント処理結果１０８に処理結果を送付する。この処理結果は、クライアント１０１に送付される。チェック処理の実行可否の判定については、図７により後述する。

データテーブル１０６のチェック処理データテーブルには、操作対象取得部１０３へ送付する「操作対象お客さまデータ」、およびクライアント１０１から関連チェック処理が要求された際に、チェック処理制御部１０５から参照される画面項目情報以外の「データ」を保持する。

チェック処理定義１０７には、クライアント１０１で実施されるチェック処理の定義情報が記載されており、チェック処理制御部１０５はこの定義情報を参照してチェック処理を実行する。また、チェック処理定義１０７には、クライアント１０１で処理中に保持する契約種別コードに対するチェック処理の実行可否が記載されており、チェック処理制御部１０５はチェック処理定義１０７の実行可否を参照して実行可否判定を実施する。

イベント結果処理部１０８はチェック処理制御部１０５から送付されたチェック処理結果を受け取り、「処理結果」を解析した後にこの結果をクライアント１０１に返却する。

次に、イベント処理部１０４で生成し・保持されるイベント処理データ２０７について、図２を参照しながら、説明する。
図２は、Ｗｅｂシステムの入力チェック処理システムが、会話型入力処理により、クライアント１０１の画面データからイベント処理データを生成するフローである。同図に示す通り、イベント処理部１０４はクライアント１０１上のクライアント画面２０１の各データを取得し、イベント処理データ２０７として保持する。クライアント画面２０１はエラーメッセージ表示部２０２を持ち、同箇所にイベント処理結果処理部１０８からの処理結果によりエラーメッセージが表示される。また、活性項目画面表示部２０３、非活性項目画面表示部２０４、および非表示項目部２０５を保持し、それぞれの画面項目名、画面項目値、画面項目属性がアクションフォームデータ２０８としてイベント処理データ２０７内に保持される。さらに、イベント処理データ２０７に保持される「操作対象お客さまデータ」２０９には、電力会社の顧客（Ｗｅｂシステムのエンドユーザ）のサービス契約番号、契約種別番号、設備番号が含まれている。

また、クライアント画面２０１はイベント実行開始部２０６を保持し、イベント実行開始部２０６を押下することでクライアント１０１からイベント実行要求が発行され、それがサーバ１０２により受け付けられ、イベントデータ２１０としてイベント処理データ２０７内に保持される。

次に、操作対象取得部１０３およびチェック処理制御部１０５から参照される、データテーブル１０６について説明する。

図３Ａ、図３Ｂは、データテーブル１０６内部のエンティティの一例を示している。図３Ａに記載されている契約エンティティ３０１は、お客さまの契約マスタデータ（サービス契約番号３０１１、契約種別コード３０１２、設備番号３０１３、契約電力３０１４）を保持する。現在操作しているお客さまのサービス契約番号３０１１を本データに紐づけることで契約種別コード３０１２を操作対象お客さまデータ２０９に設定することができる。また、データテーブル１０６は、図３Ｂに記載されているチェック用エンティティ３０２を保持しており、関連チェック処理が要求された際に、チェック処理制御部１０５から参照される。このチェック用エンティティ３０２には、サービス契約番号３０１１、チェック項目（項目Ａ３０２１、項目Ｂ３０２２、項目Ｃ３０２３）等のデータを保持する。

図４に、チェック処理定義１０７の一例を示す。図５は、チェック処理を実施する要件が記載されたチェック処理設計書５０１の一例である。図６は、画面項目Ｉ／Ｏ設計書６０１の一例である。これらの構成、機能に関しては、後で詳細に説明する。

次に、チェック処理制御部１０５を主体にして処理される、チェック処理実行判定について説明する。
図７は、クライアント１０１からサーバ１０２にチェック処理要求があった際のシステムの処理を示すフローチャートである。同図に示すように、クライアント１０１がサーバ１０２にイベント実行処理を要求すると、チェック処理制御部１０５はイベント処理部１０４から入力チェック処理要求を受け付け（Ｓ７０１）、データテーブル１０６にアクセスし（Ｓ７０２）、イベント処理データ２０７の「操作対象お客さまデータ」２０９の情報から契約種別コード３０１２を取得する（Ｓ７０３）。次に、チェック処理制御部１０５はチェック処理定義１０７の読込を実施し（Ｓ７０４〜Ｓ７０６）、先ほど取得した契約種別コード３０１２が今回のチェック処理要求に該当するチェック処理定義１０７に存在するか確認する（Ｓ７０７）。存在する場合（ＹＥＳ）は、チェック処理要求に応じてデータテーブル１０６を参照し、入力チェック処理を実行する（Ｓ７０８）。存在しない場合（ＮＯ）は、今回のチェック処理要求に該当する入力チェック処理はなしとして（Ｓ７０９）、入力チェック処理は実行しない。チェック処理制御部１０５はこれら結果を反映したデータを処理結果としてまとめ（Ｓ７１０〜Ｓ７１２）、処理結果をイベント結果処理部１０８へ送付する（Ｓ７１３）。

本発明の実施例によれば、入力チェック処理を実施することで、クライアントの画面２０１のアクションフォームデータ２０８の各項目の活性・非活性、および表示・非表示を判定することなく、必要十分で性能劣化のない入力チェック処理を実施することが可能となる。

次に、チェック処理の定義ファイル１０７について説明する。
図４は、チェック処理制御部１０５が読込を実施するチェック処理定義１０７の一例である。チェック処理定義１０７はクライアント１０１で表示されるクライアント画面２０１毎に作成され、区別手段として画面要素（Disp Name）４０１が記載される。画面要素４０１は画面名称属性を持ち、画面ＩＤが設定される。イベントデータ２１０で保持する画面ＩＤと画面要素４０１に設定された画面ＩＤとが等しい場合にチェック処理制御部１０５で読み込みが実行される。

また画面要素４０１はチェック要素（Check Event）４０２を複数個持つ。チェック要素４０２はイベント属性（Check Event）、チェックＩＤ属性（CheckID）、メッセージＩＤ属性（MessageID）、契約種別コード属性（KyksbtCd）を持ち、それぞれ設定される。チェック処理制御部１０３はチェック要素４０２中の契約種別コード属性（KyksbtCd）を参照し、操作対象お客さまデータ２０９中の契約種別コード３０１２に該当する契約種別コードが存在するかを判定する。

また、チェック要素４０２はチェック項目要素４０３、４０４を複数個持つ。チェック項目要素４０３、４０４はチェック項目名称属性（Check Param Name）を持ち、それぞれチェック処理の引数として必要な項目が設定される。また、チェック要素４０２は色付け項目要素（Color Param Name）４０５も複数個持つ。色付け項目要素４０５は色付け項目名称属性を持ち、それぞれイベント結果処理部１０８に処理結果を送付した後に処理結果画面反映として画面に色付け表示される項目が設定される。

ここで、仕様の変更などで契約種別が増加した場合や、特定の契約種別の場合のみ非活性でもチェック処理を実行したい要件が発生した場合は、チェック要素４０２中の契約種別コード属性（KyksbtCd）を書きかえることのみで要件が達成でき、図７のフローチャートに独自のアルゴリズムを追加することはない。

チェック要素４０６は、チェック要素４０２に対してメッセージＩＤ属性（MessageID）および契約種別属性（KyksbtCd）のみが異なる値が設定された定義である。これらのチェック要素４０２，４０６によるチェック処理の内容は同一である。

しかし、特定の契約種別に該当するエンドユーザに対しては通常と異なるメッセージを表示したい場合などには、チェック要素４０６のように契約種別コード属性（KyksbtCd）を別の値として設定し、新規に表示させたいメッセージＩＤ属性（MessageID）を設定することのみで実施でき、図７のフローチャートにおいて処理結果に対して契約種別ごとに分岐させてメッセージＩＤを切り替えるアルゴリズムを組み込まなくてよい。

次に、チェック処理定義１０７を生成する方法について説明する。
図５は、入力チェック処理を実施する要件が記載されたチェック処理設計書５０１の一例である。チェック処理設計書５０１はイベント５０２、チェックＩＤ５０３、メッセージＩＤ５０４、主項目５０５、従項目５０６、チェック引数５０７が記載される。イベント５０２にはクライアント画面２０１上のイベント実行開始部２０６にて実行されるイベントを記載する。チェックＩＤ５０３には実際に処理を行う一意なチェックＩＤを記載する。メッセージＩＤ５０４にはエラー時にクライアント画面２０１上のエラーメッセージ表示部２０２に設定するメッセージに紐付くＩＤを記載する。また、契約種別コードによって出力メッセージ内容を可変としたい場合は、メッセージＩＤ５０４に該当契約種別コードとメッセージＩＤを併せて記載する。主項目５０５には該当チェックの主たる項目を記載する。従項目５０６には主項目以外のチェック処理に関連する項目を記載する。

次に、図６は、クライアント画面２０１に表示される契約種別コード３０１２毎の画面項目に対する属性が記載された、画面項目Ｉ／Ｏ設計書６０１の一例である。画面項目Ｉ／Ｏ設計書６０１には、契約種別コード３０１２、および画面項目名６０３〜６０６を記載する。これにより、契約種別コード３０１２に対するが画面項目の属性（活性表示、非活性表示、非表示）が規定される。また、非活性表示でもチェック処理を実行したい特例が存在するため、その場合にはその旨を画面項目に記載する。

次に、チェック処理定義１０７の自動生成方法について説明する。
図８は、チェック処理定義の生成の手順の概要を示すフローである。チェック処理定義１０７はチェック定義生成部８０１にて自動生成され、図５のチェック処理設計書５０１、および図６の画面Ｉ／Ｏ設計書６０１をインプットとする。チェック定義生成部８０１では、図５のチェック処理設計部５０１をもとに、チェック処理定義１０７の画面要素４０１、チェック要素４０２、チェック項目要素４０３、色付け項目要素４０５を設定する。また、チェック項目要素４０２、色付け項目要素４０５が、図６の画面Ｉ／Ｏ設計書６０１にて全て「Ｉ／Ｏ」および「△」と記載されている契約種別コードをチェック要素４０２中の契約種別コード属性に設定する。また、チェック処理設計書５０１のメッセージＩＤ５０４に特例な場合の契約種別コード、およびメッセージＩＤが記載されている場合はチェック要素４０６をチェック要素４０２とは別に設定する。

チェック処理定義１０７を二つの設計書５０１、６０１から自動生成される仕組みとすることで、例え「電力システム改革」などにより大規模な変更が発生したとしても、本来修正すべき設計書の修正のみでチェック処理について修正が完了することとなり、プログラムに手を加えずに対応可能となる。

次に、図８で概要を述べたチェック処理定義１０７の自動生成処理の、詳細について説明する。
図９は、チェック処理定義の自動生成処理のフローである。チェック処理定義作成者は、チェック定義生成部８０１を起動し、チェック処理定義作成要求を行う。チェック処理定義作成者は要求時にチェック処理設計書５０１、および画面I／Ｏ設計書６０１を入力情報とする。チェック定義生成部８０１はチェック処理定義作成要求を受け取る（Ｓ９０１）。次に、入力情報読み込みとしてチェック処理設計書５０１、および画面I／Ｏ設計書６０１の内容をメモリに保存する（Ｓ９０２）。

次に、チェック処理定義１０７のファイルのみを作成し、ファイル内の先頭にXML文書であることを示すXML宣言（Ｓ９０３）、および画面要素４０１を作成する（Ｓ９０４）。

次に、ループ処理としてチェック処理設計書５０１中のチェックＩＤ欄５０３に記載されたチェックＩＤ分のチェック要素４０２を画面要素４０１の内部に記載していく（Ｓ９０５）。チェック要素４０２には、チェック処理設計書５０１に記載されたイベント欄５０２、チェックＩＤ欄５０３、メッセージＩＤ欄５０４の内容をそれぞれの属性に記載する。また、チェック要素４０２を１つ記載する毎にチェック処理設計書５０１中の該当する主項目５０５、および従項目５０６に対して画面Ｉ／Ｏ設計書６０１中の該当する画面項目を用いて画面Ｉ／Ｏ判定を実施する（Ｓ９０６）。判定の結果として「Ｉ/Ｏ」又は、「△」の場合、該当する契約種別コード６０２をチェック要素４０２中の契約種別属性に追加する（Ｓ９０７〜Ｓ９０９）。その際に、チェック処理設計書５０１中の該当するチェックＩＤ５０３に対するメッセージＩＤ５０４中に、Ｓ９０９において追加する予定の契約種別コードの記載有無判定を実施し（Ｓ９０７）、記載が有ればメッセージＩＤが異なるチェック要素４０２を作成し（Ｓ９０８）、契約種別属性、およびメッセージＩＤを追加する（Ｓ９０９）。なお、Ｓ９０６の判定で回答しなければ、これらの処理を省略する。

画面Ｉ／Ｏ設計書６０１と主項目、従項目による画面Ｉ／Ｏ判定（Ｓ９０６）を契約種別コード全数に対して行った後に、記載したチェック要素４０２それぞれに対してチェック項目要素４０３、および色付け項目要素４０５を作成する（Ｓ９１０）。チェック項目要素４０３に対しては、チェック処理設計書５０１のチェック引数欄５０７に記載された項目毎に要素を作成し、属性に項目名を記載する。色付け項目要素４０５に対しては、チェック処理設計書５０１の主項目欄５０５、および従項目欄５０６に記載された項目毎に要素を作成し、属性に項目名を記載する。また、主項目から作成した場合は、type属性に「main」を記載し、従項目から記載した場合は「servant」を記載する。

チェック処理設計書５０１中のチェックＩＤ欄５０３全数に対してチェック要素４０２の作成（Ｓ９０５）が完了すると、チェック定義生成部８０１はチェック処理定義作成者に対しチェック定義作成結果を送付する（Ｓ９１１）。チェック処理定義作成者は送付された結果を得ることでチェック処理定義１０７を得ることができる。

以上述べた通り、本実施例によれば、入力チェック処理実行時に多数の画面項目の属性判定を網羅的に行うことが回避され、システム面での性能劣化を防ぐことができる。

なお、将来、「電力システム改革」により、小売全面自由化や発送電分離により新たな契約形態や料金計算項目が導入されることが考えられる。この場合、システムへの新規契約種別コードの反映や新規画面項目の追加、もしくは新規契約形態独自の入力チェック方式追加（画面項目が非活性・非表示でもチェックを行う）の可能性があり、入力チェック処理の再検討に大きな工数が発生してしまう。

また、電力会社Ｗｅｂシステムでは入力チェック処理の結果として画面にエラー時のメッセージを表示するが、「電力システム改革」への対応により、本システムを扱うユーザが現在の顧客営業所オペレータのみでなく、別企業関係者が使用することが発生するかもしれない。この場合、チェック処理を実施しエラーとなった際に、操作している対象の顧客毎に画面表示するメッセージを切り替えることが要求される可能性があるが、現在のチェック処理の仕様では実現できずに、実現のためには大きな変更を実施しなければならない。

本実施例によれば、入力チェック処理実行時に多数の画面項目の属性判定を行うことが回避され、システム面での性能劣化を防ぐことができる。
また、システム開発者の立場から、アルゴリズム中に属性判定を実施する処理を組み込む必要がないため、アプリケーションの品質向上および開発量の削減が期待できる。また、仕様変更などにより非活性でも特定の契約種別コードの場合はチェックを実施することになった場合でも、特殊要件のためのアルゴリズムを追加することなく、チェック処理の定義中の契約種別の属性を修正することのみで実装できるため、品質の向上および開発両の削減が可能である。
さらに、チェック仕様の定義を、二つの設計書（チェック処理設計書、および画面I／Ｏ設計書）から自動生成することで、例え上記で述べたような「電力システム改革」などで契約の種類が大幅に増大される、または画面の項目が大幅に変更されたとしても、変更の影響によりプログラムに手を加えず、影響を最小限に抑えることができる。
また、いままでの方式では画面内の同一のチェック処理に対して表示されるメッセージを切り替えるためには、入力チェック処理の結果と画面で処理中の契約種別コードを判定するアルゴリズムを用意することが必要であったが、本発明ではチェック処理の定義を複数用意することのみで実施可能なため、アルゴリズムに手を加えることがなく、品質の低下を懸念しなくよい。

１０１ クライアント
１０２ サーバ
１０３ 操作対象取得部
１０４ イベント処理部
１０５ チェック処理制御部
１０６ データテーブル
１０７ チェック処理定義
１０８ イベント結果処理部
２０１ クライアント画面
２０２ エラーメッセージ表示部
２０３ 活性項目表示部
２０４ 非活性項目表示部
２０５ 非表示項目部
２０６ イベント実行開始部
２０７ イベント処理データ
２０８ アクションフォームデータ
２０９ 操作対象お客さまデータ
２１０ イベントデータ
３０１ 契約エンティティ
３０２ チェック用エンティティ
４０１ 画面要素
４０２ チェック要素
４０３ チェック項目要素
４０４ チェック項目要素
４０５ 色付け項目要素
４０６ メッセージＩＤ・契約種別が異なるチェック要素
５０１ チェック処理設計書
５０２ イベント欄
５０３ チェックＩＤ欄
５０４ メッセージＩＤ欄
５０５ 主項目欄
５０６ 従項目欄
５０７ チェック引数欄
６０１ 画面Ｉ／Ｏ設計書
８０１ チェック定義生成部。

Claims (15)

1. Ｗｅｂシステムの入力チェック処理システムであって、
   イベント処理部と、
   チェック処理制御部とを備えており、
   処理対象となるイベントデータには、前記Ｗｅｂシステムのエンドユーザの契約種別コードが含まれており、
   前記イベント処理部は、処理対象となる前記イベントデータを取得し、
   前記チェック処理制御部は、前記契約種別コードごとに実施されるべきチェック処理の定義が記載されたチェック処理定義を参照して、受け付けた前記イベントデータの契約種別コードが前記定義に存在するかを判定し、前記定義に前記契約種別コードが含まれる場合、前記イベントデータのチェック処理を実行することを特徴とする入力チェック処理システム。
2. 請求項１において、
   前記入力チェック処理システムは、データテーブルを備えており、
   前記データテーブルには、契約エンティティ及びチェック用エンティティがチェック処理用データテーブルとして含まれており、
   前記契約エンティティは、前記エンドユーザのサービス契約番号及び前記契約種別コードを含むマスタデータが保持され、
   前記チェック用エンティティには、前記サービス契約番号及びチェック項目のデータが保持されることを特徴とする入力チェック処理システム。
3. 請求項２において、
   前記チェック仕様の定義内に、前記チェック処理ごとに契約種別の属性を設定し、当該チェック処理を実行可能な契約種別コードが記載されており、
   前記チェック処理制御部で、前記受け付けたイベントデータの前記契約種別コードが前記チェック仕様の定義内に設定された契約種別の属性内に含まれているかどうかを判定してチェック実施可否の判定を行うことを特徴とする入力チェック処理システム。
4. 請求項２において、
   前記入力チェック処理システムは、
   入力チェック処理を制御するサーバと、
   ネットワークを介して前記サーバに接続されたクライアントとを備えており、
   前記クライアントは、
   ユーザが、入力チェック処理要求を行うインターフェースとしてのクライアント画面を有しており、
   前記サーバは、さらに
   操作対処取得部と、
   前記チェック処理定義を自動生成するチェック定義生成部とを備えており、
   前記イベント処理部は、前記クライアントで発生したイベントを取得し、イベントデータを取得し、前記操作対象取得部に操作対象となる前記Ｗｅｂシステムのエンドユーザのデータ取得要求を行い、
   前記操作対象取得部は、前記データテーブルから前記エンドユーザのデータを取得し、前記イベント処理部へ返却し、
   前記イベント処理部は、前記チェック処理制御部へチェック処理要求を行うことを特徴とする入力チェック処理システム。
5. 請求項４において、
   前記クライアント画面は、活性項目画面表示部、非活性項目画面表示部、および非表示項目部を保持し、それぞれの画面項目名、画面項目値、画面項目属性がアクションフォームデータとして前記イベント処理データ内に保持され、
   前記イベント処理部は、前記クライアント画面の各データを取得し、前記イベント処理データとして保持することを特徴とする入力チェック処理システム。
6. 請求項５において、
   前記チェック処理制御部は、前記チェック処理要求の要求内容と前記イベント処理データ、前記チェック処理用データテーブル、前記チェック処理定義を元にチェック処理の実行可否を判定し、実行可の場合は前記チェック処理を実行し、チェック処理結果を前記イベント処理結果に送付し、実行不可の場合は前記チェック処理を実行せず、
   該前記チェック処理制御部の処理結果は、前記クライアント画面にイベント処理結果として出力されることを特徴とする入力チェック処理システム。
7. 請求項６において、
   前記チェック仕様の定義内に契約種別の属性を設定し、メッセージと契約種別のみ異なる定義を準備することで、契約種別ごとに前記クライアント画面に表示するメッセージを切り替えることを特徴とする入力チェック処理システム。
8. 請求項６において、
   前記チェック処理制御部による前記チェック処理の実施は、前記クライアント画面の各画面で実施し、前記チェック定義を読み込むことで順次チェック処理を実行し、前記画面項目による属性によるチェックの実行可否は前記チェック定義により実施されることを特徴とする入力チェック処理システム。
9. 請求項２において、
   前記契約エンティティは、前記Ｗｅｂシステムのエンドユーザの契約マスタデータとして、サービス契約番号、契約種別コード、設備番号、契約電力を保持し、該データに、現在操作している前記エンドユーザのサービス契約番号を紐づけることで、前記契約種別コードを操作対象の前記エンドユーザのデータに設定することを特徴とする入力チェック処理システム。
10. 請求項９において、
    前記チェック用エンティティは、前記サービス契約番号及び複数のチェック項目のデータを保持しており、関連するチェック処理が要求された際に、前記チェック処理制御部から参照されることを特徴とする入力チェック処理システム。
11. Ｗｅｂシステムの入力チェック処理システムであって、
    イベント処理部と、
    チェック定義生成部と、
    チェック処理制御部とを備えており、
    処理対象となるイベントデータには、前記Ｗｅｂシステムのエンドユーザの契約種別コードが含まれており、
    前記チェック定義生成部は、前記契約種別コードごとに実施されるべきチェック処理の定義が記載されたチェック処理定義を自動生成し、
    前記イベント処理部は、処理対象となる前記イベントデータを取得し、
    前記チェック処理制御部は、前記チェック処理定義を参照して、受け付けた前記イベントデータの契約種別コードが前記定義に存在するかを判定し、前記定義に前記契約種別コードが含まれる場合、前記イベントデータのチェック処理を実行することを特徴とする入力チェック処理システム。
12. 請求項１１において、
    前記入力チェック処理システムは、入力チェック処理要求を行うインターフェースとしてのクライアント画面を有するクライアントを備えており、
    前記チェック仕様の定義内に、前記チェック処理ごとに契約種別の属性が設定され、当該チェック処理を実行可能な契約種別コードが記載されており、
    前記チェック定義生成部は、
    チェック処理設計書および画面Ｉ／Ｏ設計書を入力として受け付け、前記チェック処理定義を自動生成するものであり、
    前記チェック処理設計書には、イベント、実際に処理を行う一意なチェックＩＤ、メッセージＩＤ、主項目、従項目、チェック引数が記載され、
    前記画面Ｉ／Ｏ設計書には、前記契約種別コードが前記チェック処理定義の契約種別コード属性に設定されていることを特徴とする入力チェック処理システム。
13. 請求項１２において、
    前記チェック定義生成部は、
    前記クライアントから、チェック処理定義作成要求を受け取り、
    前記チェック処理定義のファイルを作成し、前記画面要素を作成し、
    前記チェック処理設計書中の前記チェックＩＤ欄に記載されたチェックＩＤ分のチェック要素を画面要素の内部に記載し、前記チェック要素を１つ記載する毎に前記チェック処理設計書中の該当する主項目、および従項目に対して前記画面Ｉ／Ｏ設計書中の該当する画面項目を用いて画面Ｉ／Ｏ判定を実施し、
    前記チェック処理設計書中の該当する前記チェックＩＤに対するメッセージＩＤ中に、追加する予定の契約種別コードの記載有無判定を実施し、該当する記載が有ればメッセージＩＤが異なるチェック要素を作成し、契約種別属性、およびメッセージＩＤを追加することを特徴とする入力チェック処理システム。
14. Ｗｅｂシステムの入力チェック処理システムにより、チェック処理を実施する入力チェック処理方法であって、
    契約種別コードごとに実施されるべきチェック処理の定義が記載されたチェック処理定義を備えており、
    クライアントからサーバへの処理要求を受け付ける受付ステップと、
    前記クライアントからの要求結果をもとに契約種別コードがチェック定義に存在するかを判定する判定ステップと、
    前記判定ステップの結果、契約種別コードが含まれる場合、チェック処理を実行する実行ステップを備えることを特徴とする入力チェック処理方法。
15. 請求項１４において、
    前記チェック処理定義は、チェック処理設計書、および画面Ｉ／Ｏ設計書に基づいて、チェック定義生成部により自動生成されることを特徴とする入力チェック処理方法。

Images