(57)【特許請求の範囲】
【請求項１】
クライアント端末に送信するフォーム単位でサーバ側に用意された、所定のコンピュータ言語で記述されたソースコードをコンパイルして得られた入力チェックプログラムを起動させることにより、サーバ側に生成されるルールオブジェクト設定部、データ充填部、サーバ側適合性判定部、クライアント側コード生成部を備えたシステムであって、
クライアント端末から送信された対応フォームに対する入力データについてチェックを行う場合に、上記ルールオブジェクト設定部は、入力チェックの対象となるフィールドを特定するデータを充填するための項目、当該フィールドに対する入力データを充填するための項目、及び当該フィールドにおけるデータの適否を判定する際の基準となるデータを充填するための項目を有するルールオブジェクトを、サーバのメモリ空間に設定する処理を実行し、
上記データ充填部は、上記入力チェックプログラム内に設定された入力チェックの対象となるフィールド及び当該フィールドに係る判定基準データを特定するチェックロジックに従い、上記ルールオブジェクトに対し対象フィールドを特定するデータ及び当該フィールドに係る判定基準データを充填すると共に、クライアント端末から送信された当該対象フィールドに対する入力データを充填する処理を実行し、
上記サーバ側適合性判定部は、上記ルールオブジェクトに充填された対象フィールドに対する入力データと判定基準データとを比較し、当該フィールドに対する入力データの適否を判定する処理を実行し、
上記フォームと共にクライアント端末に送信されるクライアント側のチェックコードを生成する必要がある場合に、上記ルールオブジェクト設定部は、入力チェックの対象となるフィールドを特定するデータを充填するための項目、当該フィールドに対する入力データを充填するための項目、及び当該フィールドにおけるデータの適否を判定する際の基準となるデータを充填するための項目を有するルールオブジェクトを、サーバのメモリ空間に設定する処理を実行し、
上記データ充填部は、上記チェックロジックに従い、上記ルールオブジェクトに対し対象フィールドを特定するデータ及び当該フィールドに係る判定基準データを充填する処理を実行し、
上記クライアント側コード生成部は、上記ルールオブジェクトに充填された対象フィールドを特定するデータ及び判定基準データを抽出し、これを他のコンピュータ言語の文法に従って変換することにより、当該フィールドに対するクライアント側のチェックコードを生成する処理を実行することを特徴とする、
チェックコード生成機能を有する入力チェックシステム。
【請求項２】
上記サーバ側の入力チェックプログラムが、入力チェックの対象となるフィールドの少なくとも一部を異にし、同一フォームを通じてクライアント端末から送信される異なるリクエストに対して関連付けられた複数のチェックロジックを含んでおり、
上記クライアント側のチェックコードを生成する必要がある場合に、上記ルールオブジェクト設定部は、上記入力チェックプログラム中の各チェックロジックを検出し、入力チェックの対象となるフィールドを特定するデータを充填するための項目、当該フィールドに対する入力データを充填するための項目、及び当該フィールドにおけるデータの適否を判定する際の基準となるデータを充填するための項目を有するルールオブジェクトを、チェックロジック毎にサーバのメモリ空間に設定する処理を実行し、
上記データ充填部は、上記の各チェックロジックに従い、対応のルールオブジェクトに対し対象フィールドを特定するデータ及び当該フィールドに係る判定基準データをそれぞれ充填する処理を実行し、
上記クライアント側コード生成部は、上記の各ルールオブジェクトに充填された対象フィールドを特定するデータ及び判定基準データを抽出し、これを他のコンピュータ言語の文法に従って変換することにより、一のフォーム中の異なるリクエストボタンに係る複数のチェックコードを生成する処理を実行することを特徴とする、
請求項１に記載のチェックコード生成機能を有する入力チェックシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、チェックコードの自動生成技術に係り、特に、特定のコンピュータ言語で記述されたチェックロジックを基に、他の言語によって記述された同一内容のチェックロジックを実現するコードを自動的に生成する技術に関する。
【背景技術】
【０００２】
コンピュータプログラムの生産性を向上させるため、これまでも様々な自動化手法が提案されている。
例えば、特許文献１においては、データ項目への入力値が所定のデータ属性に合致しているか否かのチェック処理等を行う制御プログラムを、標準化されたソフトウェア部品として予め複数準備しておき、これらと標準化されたデータ項目単位の部品とを合成することによって必要な業務処理プログラムを自動生成する技術が開示されている。
この技術によれば、既存のソフトウェア部品同士を組み合わせることによって業務処理プログラムが容易に作成可能となり、プログラムの生産性を向上させることができる。
【特許文献１】特開平４−１７２５２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、情報通信の分野においては、特定の言語で作成されたプログラムを基に、他の言語で記述された同一内容のプログラムを開発することが求められる場合がある。
図１２はその一例を示すものであり、インターネット44やイントラネット等の通信網を介して接続された業務処理用のサーバ12に対して、クライアント端末14がデータの検索や登録・更新処理を要求する場面が描写されている。
ここで、ユーザ70がクライアント端末14のWebブラウザ上に表示されたフォーム71の入力フィールドに文字列を入力し、サーバ12に対して当該文字列の新規登録あるいは更新登録を要求すると、まずクライアント端末14内においてチェックプログラムが起動し、入力文字列の適否（桁数や文字種別等が適合しているか否か）が判定される。
クライアント側のチェックプログラムによって「適合」の判定が下された場合には、当該文字列の登録要求がサーバ12に送信され、サーバ側チェックプログラムによって適否が再度判定される。
そして、このサーバ側のチェックプログラムによって「適合」の判定が下された場合にのみ、ユーザ70の入力データがデータベース72に登録される仕組みとなっている。
【０００４】
このように、クライアント側とサーバ側とで二重のチェック処理を実施するのは、以下の理由による。
第１に、クライアント端末14にチェックプログラムを配置しておくだけでは、何らかの理由によってクライアント側のチェックプログラムが機能しない場合に、不正なデータがそのままサーバ側に登録される可能性が生じる。また、悪意のあるユーザ72が、チェックプログラムを搭載しないマシン73を介してサーバ12に不正アクセスし、許容外のデータを大量に送信する攻撃に対して無力となる。
第２に、サーバ12側にチェックプログラムを配置しておくだけでは、多数のクライアント端末14から同時に登録要求等が発せられた場合にチェック処理が追いつかなくなり、システムがダウンする可能性がある。また、サーバ12とクライアント端末14間で頻繁に応答を繰り返す必要が生じ、通信トラフィック量を増大させる原因となる。
このため、個々のクライアント端末14にチェックプログラムを配置しておき、ユーザ70の入力データをクライアント端末14内において一次的にチェックすると共に、万一に備えてサーバ12側でも同様のチェックを実行するように仕組まれている。
【０００５】
このように、クライアント端末14とサーバ12によって同一内容のチェックが二重に実施されるものであるため、当然ながらクライアント側で実行されるチェックロジック（チェック対象及び判定基準）とサーバ側で実行されるチェックロジックは同一であることが要求される。
しかし一方で、サーバ12とクライアント端末14とでは処理能力に差があるため、それぞれのチェックプログラムはマシン特性に応じて異なる言語で作成されるのが一般的である。
例えば、サーバ側のチェックプログラムは、Java（登録商標／以下同様）でソースコードが記述され、コンパイラによって実行モジュールが生成されるのに対し、クライアント側のチェックプログラムは、Webブラウザによって直接実行可能なJavaScriptによって記述されることが多い。
このため従来は、サーバ側のチェックプログラムをJavaで開発した後、これをJavaScriptに書き換えてクライアント側のチェックプログラムを作成し、Htmlファイルと共に各クライアント端末14に配信していた。
【０００６】
このように、同一のチェックロジックを含むプログラムでありながら、一方の言語で作成した後に他方の言語に移植するやり方では二度手間となり、その分開発コストが嵩むこととなる。
また、サーバ側のチェックロジックに変更が生じた場合、これに合わせて即座にクライアント側のチェックロジックを修正する必要が生じるが、従来のようにサーバ側プログラムとクライアント側プログラムとを別個に開発する手法では、サーバ側プログラムのバージョンアップからクライアント側プログラムのバージョンアップまでの間に所定のタイムラグが発生し、その間は旧バージョンのチェックプログラムを利用せざるを得ない。
さらに、サーバ側のプログラムを解析してロジックを抽出し、これをクライアント側の言語に書き換える段階で人為的なミスが発生する危険性が常に存在し、チェックロジックの同一性を確保することが難しい。
因みに、上記した特許文献１に開示されているプログラムの自動生成技術を用いることにより、サーバ側プログラムの開発自体を効率化することはある程度可能であるとしても、サーバ側プログラムを基に別言語で記述されたクライアント側プログラムを自動生成し、両者間のチェックロジックの同一性を確保することは全く期待できない。
【０００７】
この発明は、上記の問題点を解決するために案出されたものであり、あるコンピュータ言語によって作成されたチェックロジックを基に、チェックロジックの同一性を保持したまま他の言語によって記述されたチェックコードを自動生成することを可能とする技術を提供することを目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したチェックコード生成機能を有する入力チェックシステムは、クライアント端末に送信するフォーム単位でサーバ側に用意された、所定のコンピュータ言語で記述されたソースコードをコンパイルして得られた入力チェックプログラムを起動させることにより、サーバ側に生成されるルールオブジェクト設定部、データ充填部、サーバ側適合性判定部、クライアント側コード生成部を備えたシステムであって、クライアント端末から送信された対応フォームに対する入力データについてチェックを行う場合に、上記ルールオブジェクト設定部は、入力チェックの対象となるフィールドを特定するデータを充填するための項目、当該フィールドに対する入力データを充填するための項目、及び当該フィールドにおけるデータの適否を判定する際の基準となるデータを充填するための項目を有するルールオブジェクトを、サーバのメモリ空間に設定する処理を実行し、上記データ充填部は、上記入力チェックプログラム内に設定された入力チェックの対象となるフィールド及び当該フィールドに係る判定基準データを特定するチェックロジックに従い、上記ルールオブジェクトに対し対象フィールドを特定するデータ及び当該フィールドに係る判定基準データを充填すると共に、クライアント端末から送信された当該対象フィールドに対する入力データを充填する処理を実行し、上記サーバ側適合性判定部は、上記ルールオブジェクトに充填された対象フィールドに対する入力データと判定基準データとを比較し、当該フィールドに対する入力データの適否を判定する処理を実行し、上記フォームと共にクライアント端末に送信されるクライアント側のチェックコードを生成する必要がある場合に、上記ルールオブジェクト設定部は、入力チェックの対象となるフィールドを特定するデータを充填するための項目、当該フィールドに対する入力データを充填するための項目、及び当該フィールドにおけるデータの適否を判定する際の基準となるデータを充填するための項目を有するルールオブジェクトを、サーバのメモリ空間に設定する処理を実行し、上記データ充填部は、上記チェックロジックに従い、上記ルールオブジェクトに対し対象フィールドを特定するデータ及び当該フィールドに係る判定基準データを充填する処理を実行し、上記クライアント側コード生成部は、上記ルールオブジェクトに充填された対象フィールドを特定するデータ及び判定基準データを抽出し、これを他のコンピュータ言語の文法に従って変換することにより、当該フィールドに対するクライアント側のチェックコードを生成する処理を実行することを特徴としている。
上記「判定基準データ」としては、例えば入力データの形式を指定するデータや、データ長を指定するデータが該当する。また、対象フィールドに対するデータの入力が必須か否かを定義するデータも判定基準データに含まれる（以下同様）。
上記「対象フィールドに対する入力データ」とは、入力データが積極的に充填されている場合の他、入力データが存在せずブランクのままとなっている状態も含むものとする（以下同様）。
【０００９】
請求項２に記載したチェックコード生成機能を有する入力チェックシステムは、請求項１に記載のシステムを前提とし、さらに上記サーバ側の入力チェックプログラムが、入力チェックの対象となるフィールドの少なくとも一部を異にし、同一フォームを通じてクライアント端末から送信される異なるリクエストに対して関連付けられた複数のチェックロジックを含んでおり、上記クライアント側のチェックコードを生成する必要がある場合に、上記ルールオブジェクト設定部は、上記入力チェックプログラム中の各チェックロジックを検出し、入力チェックの対象となるフィールドを特定するデータを充填するための項目、当該フィールドに対する入力データを充填するための項目、及び当該フィールドにおけるデータの適否を判定する際の基準となるデータを充填するための項目を有するルールオブジェクトを、チェックロジック毎にサーバのメモリ空間に設定する処理を実行し、上記データ充填部は、上記の各チェックロジックに従い、対応のルールオブジェクトに対し対象フィールドを特定するデータ及び当該フィールドに係る判定基準データをそれぞれ充填する処理を実行し、上記クライアント側コード生成部は、上記の各ルールオブジェクトに充填された対象フィールドを特定するデータ及び判定基準データを抽出し、これを他のコンピュータ言語の文法に従って変換することにより、一のフォーム中の異なるリクエストボタンに係る複数のチェックコードを生成する処理を実行することを特徴としている。
【発明の効果】
【００１０】
この発明に係るチェックコード生成機能を備えた入力チェックシステムにあっては、所定のコンピュータ言語で記述された基本となる入力チェックプログラムの存在を前提としている。
また、この入力チェックプログラムは、特定フィールドにおける入力データの有無や値の適否を判定するに際して、まず対象フィールド、入力データ及びその判定基準データを充填するための器となるルールオブジェクトをメモリ空間に設定し、そこに所定のチェックロジックに従って対象フィールドを特定するデータ及び判定基準データを充填すると共に、ユーザによる入力データを充填した後、入力データと判定基準データとを比較してその適否を判定する方式を採用している。
このため、この入力チェックプログラムを仮想的に実行させ、当該ルールオブジェクトに対象フィールドを特定するデータ及び判定基準データを充填させた後、これらを外部に取り出すことによってチェックロジックの内容を顕在化することが可能となり、これを基に同一のチェックロジックを備えた他言語によるチェックコードを自動生成することが可能となっている。
この結果、例えば基本となるサーバ側のチェックロジックに変更が生じても、人手を介すことなく即座に同一のチェックロジックを反映したクライアント側のチェックコードを生成することが可能となり、開発コストの低減及びチェックロジックの一元管理を実現できる。
【発明を実施するための最良の形態】
【００１１】
図１は、この発明に係るシステム10の構成を示すブロック図であり、センターサーバ12とクライアント端末14とを備えている。
センターサーバ12は、Webサーバ16と、AP（Application）サーバ18と、DB（Database）サーバ20とを備えており、APサーバ18にはルールオブジェクト設定部22と、データ充填部24と、サーバ側の適合性判定部26と、クライアント側コード生成部28と、コード格納部30とが設けられている。
【００１２】
センターサーバ12は、それぞれWebサーバ16、APサーバ18、DBサーバ20として機能する独立したコンピュータをLAN接続することによって構成することもできるが、単一のコンピュータに各サーバ機能を実現するプログラムをセットアップすることによって構成することもできる。
APサーバ18のルールオブジェクト設定部22、データ充填部24、適合性判定部26、クライアント側コード生成部28は、APサーバ18のCPUが、サーバ側実行モジュールαに記述されたオブジェクトコード等に従って必要な処理を実行することによって実現される。また、コード格納部30は、APサーバ18のメモリや外部記憶装置内に設定されている。
【００１３】
クライアント端末14は、マウスやキーボード等の入力ディバイス32と、ディスプレイ34とが接続されたPC等のコンピュータよりなり、ファイル配信要求部36と、Webページ表示部38と、クライアント側の適合性判定部40と、データ処理要求部42とを備えている。
ここで、ファイル配信要求部36、Webページ表示部38、データ処理要求部42は、クライアント端末14のCPUが、汎用のWebブラウザプログラム等に従って必要な処理を実行することによって実現される。また、適合性判定部40は、同CPUがセンターサーバ12から送信されたクライアント側のチェックプログラム及びWebブラウザプログラム等に従い、必要な処理を実行することによって実現される。
【００１４】
このシステム10の場合、クライアント端末14に配信される多数のフォームに対応した単項目チェック用のJava実行モジュールがAPサーバ18内に個別に用意されており、クライアント端末14から特定フォームの配信リクエストが送信された時点で、対応のJava実行モジュールと同一のチェックロジックを備えたJavaScriptによるクライアント側チェックコードを自動生成し、フォーム（HTMLファイル）と共にクライアント端末14に配信することが前提となっている。
ただし、一旦生成されたクライアント側チェックコードは、コード格納部30に蓄積され、サーバ側実行モジュールがバージョンアップされるまで再利用される。
【００１５】
サーバ側実行モジュールの中、ルールオブジェクト設定部22、サーバ側適合性判定部26、及びクライアント側コード生成部28を実現するためのコードは各フォームで共通するため、Java言語の特徴である「継承」の仕組みを使って各実行モジュール内に実装され、データ充填部24を実現するためのコードのみがフォーム毎に書き分けられている。
【００１６】
図１２に示したケースと同様に、クライアント端末14とサーバ12とは、インターネット44等の通信網を介してネットワーク接続されている。
以下、図２〜図４のフローチャートに従い、サーバ12及びクライアント端末14における処理手順を説明する。
まず、ユーザがクライアント端末14からインターネット44経由でサーバ12のWebサイトにアクセスし、ID及びパスワードの入力を伴う認証ステップをクリアすると、Webサーバ16からクライアント端末14にメニュー表示用のWebファイルが送信される（Ｓ10）。
【００１７】
ここで、例えばユーザがサービスメニュー中の「色コードの登録」を選択すると、ファイル配信要求部36からWebサーバ16に対して色コード登録用フォームの配信リクエストが送信される（Ｓ12）。
これを受けたWebサーバ16は、コード格納部30をチェックし、当該フォームに関連付けられたチェックコードの有無を確認する（Ｓ14）。
そして、既に対応のチェックコードが存在している場合には、当該フォーム（Htmlファイル）と共にクライアント端末14に送信する（Ｓ16）。
このクライアント側のチェックコードは、JavaScriptによって記述されており、クライアント端末14のWebブラウザが直接解釈することによって入力データの適否が判定される（詳細は後述）。
【００１８】
以上の結果、クライアント端末14のWebブラウザ上には、図５に示すように、色コード登録用のフォーム46が表示される（Ｓ18）。
これに対しユーザは、色タイプコード入力フィールド47に所定のコードをキーボードからタイプ入力するか、マウス操作によってプルダウンメニューから特定のコードを選択し、「検索」ボタン48をクリックする。
この入力データを受け付けた後（Ｓ20）、クライアント側の適合性判定部40が起動し、その適否をチェックする（Ｓ22）。
【００１９】
例えば、色タイプコード入力フィールド47に関しては、JavaScriptによって以下のチェックコードが記述されている。
elementArraydoInquire=new Array(
"IroTypCd","t","int","2"
);
ここで、２行目の「IroTypCd」は当該入力フィールドの名前を、「t（＝true）」は必須入力項目であることを、「int」はデータ形式が数字コードであることを、「2」はデータ項目長が２桁であることを意味している。
【００２０】
したがって、ユーザが色タイプコード入力フィールド47に漢字で入力したり、５桁の数字を入力した場合には、適合性判定部40によって不適合と判定され、エラー表示欄49に「数字のみ入力可能です！」や「２桁で入力してください！」といったエラーメッセージが表示されることとなる（Ｓ24）。
また、当該入力フィールド47は検索処理要求時の必須入力項目であるため、ブランクのまま検索ボタン48がクリックされた場合にも、適合性判定部40によって不適合と判定され、図示の通りエラー表示欄49に「必須入力項目です！」というエラーメッセージが表示される。
【００２１】
これに対し、ユーザが初めから当該入力フィールド47に適正な値（例えば「01」）を入力した場合、あるいはエラーメッセージに従って必要な修正を施した場合、データ処理要求部42を通じて検索処理のリクエストがサーバ12に対して送信される（Ｓ26）。
これを受けたAPサーバ18は、当該フォーム46に対応したサーバ側の実行モジュールαを起動させ、クライアント端末14から送信された入力データ「01」の適否を判定する。
具体的には、以下の処理が実行される。
【００２２】
まず、図６に示すように、ルールオブジェクト設定部22により、所定のデータ項目が設定されたルールオブジェクト50が、APサーバ18のメモリ空間51上に設定される（Ｓ28）。
ここでは、チェック処理の対象フィールドを特定する「名前」と、クライアント端末14から送信された入力データが充填される「値」と、入力データの適否を判定する際の基準データが充填される「必須Flg」、「種類」、「項目長」の各データ項目が設定されている。
これらの中、判定基準項目の一つである「必須Flg」には、対象フィールドへの入力が必須であるか否かを規定するtrue（必須）またはfalse（必須でない）が充填される。また、「種類」には、対象フィールドのデータ形式を規定するint（数字コード）、char（半角カナ・英字・数字混合）、num（数値）、date（日付）、dbyte（全角文字）等が充填される。さらに、「項目長」には、対象フィールドのデータ長（桁数）を特定する数値が充填される。
【００２３】
つぎに、図７に示すように、データ充填部24によって上記ルールオブジェクト50の各項目に対し具体的なデータが充填される（Ｓ30）。
まず、データ充填部24は、「名前」の項目に色タイプコード入力フィールド47を示す「IroTypCd」を充填すると共に、「値」の項目にはクライアント端末14から送信された「01」を充填する。
つぎにデータ充填部24は、サーバ側実行モジュールαに記述されたコードに従い、判定基準項目に以下のデータを充填する。
必須Flg：true
種類：int
項目長：2
【００２４】
つぎに、サーバ側の適合性判定部26が起動し、上記ルールオブジェクト50の「値」に充填された入力データと、「必須Flg」、「種類」、「項目長」に充填された判定基準データとを比較することにより、入力データの適合性が判定される（Ｓ32）。
この場合、ユーザの入力データである「01」は各基準を満たしているため、適合性判定部26によって「適合」の判定が下される。
この結果、DBサーバから色タイプコード「01」に関連付けられたデータが抽出され（Ｓ36）、当該データを反映したフォーム（Htmlファイル）がWebサーバ16を通じてクライアント端末14に送信される（Ｓ38）。
【００２５】
これを受けたクライアント端末14のディスプレイ34上には、図８に示すように、ユーザが指定した色タイプコード「01」に属する色コードがリスト表示されたフォーム46が表示される（Ｓ40）。
ここでユーザは、登録済みの色コードを参照し、必要な箇所に修正を加えることができる。また、先頭行に設けられた空白の入力フィールドに色コードを新規に入力することもできる。
ユーザが必要なデータの入力を完了し、「登録・更新」ボタン52をクリックすると、この入力データを受け付けたクライアント側の適合性判定部40により、その適否がチェックされる（Ｓ42、Ｓ44）。
【００２６】
この「登録・更新」処理に関しては、JavaScriptによって以下のチェックコードが記述されている。
elementArraydoDefault=new Array(
"IroTypCd","t","int","2" ・・・(1)
"IroCd1","f","int","5"・・・(2)
"IroKj1","f","dbyte","0"・・・(3)
"IroKn1","f","char","0"・・・(4)
"IroCd2","f","int","5"・・・(5)
"IroKj2","f","dbyte","0"・・・(6)
"IroKn2","f","char","0"・・・(7)
・       ・
・（中略）
・
"IroCd15","f","int","5"・・・(8)
"IroKj15","f","dbyte","0"・・・(9)
"IroKn15","f","char","0"・・・(10)
);
【００２７】
ここで(1)のコードは、上記と同様、色タイプコード入力フィールド（IroTypCd）47が必須入力項目であり、データ形式がint型（数字コード）、桁数が２であることを意味している。
これに対し(2)のコードは、１行目の色コード入力フィールド（IroCd1）53が必須ではなく（f＝false）、かつデータ形式がint型（数字コード）で桁数が５であることを意味している。
(3)のコードは、１行目の色漢字名称入力フィールド（IroKj1）54が必須ではなく（f＝false）、かつデータ形式がdbytet型（全角文字）で項目長制限がないことを意味している。
(4)のコードは、１行目の色カナ名称入力フィールド（IroKn1）55が必須ではなく（f＝false）、かつデータ形式がchar型（半角カナ・英字・数字混合）で項目長制限がないことを意味している。
要するに、(2)〜(4)のコードによって、１行目に並んだ３つの入力フィールド53、54、55についての判定基準が定義されていることとなる。
同様に、(5)〜(7)のコードによって２行目に並んだ３つの入力フィールド56、57、58について判定基準が定義され、(8)〜(10)のコードによって１５行目に並んだ３つの入力フィールド59、60、61について判定基準が定義されている。
【００２８】
このため、例えばユーザが１行目の色漢字名称入力フィールド54に半角英字を含む「真っ黒ccc」を入力して「登録・更新」ボタン52をクリックすると、ユーザの入力データが適合性判定部40によってエラーと判定され、図示の通りエラー表示欄49に「全角文字のみ入力可能です！」のエラーメッセージが表示される（Ｓ46）。
【００２９】
これに対し、初めから全入力フィールドに適正なデータが入力されている場合、あるいはエラーメッセージに従って必要な修正を施した場合、データ処理要求部42を通じて入力データの登録・更新リクエストがサーバ12に送信される（Ｓ48）。
これを受けたAPサーバ18では、上記のサーバ側実行モジュールαが機能し、クライアント端末14から送信された入力データの適否が判定される。
具体的には、以下の処理が実行される。
【００３０】
まず、図９に示すように、ルールオブジェクト設定部22により、所定のデータ項目が設定されたルールオブジェクト62が、APサーバ18のメモリ空間51上に設定される（Ｓ50）。
この場合も上記と同様、チェック処理の対象フィールドを特定する「名前」と、クライアント端末14から送信された入力データが充填される「値」と、入力データの適否を判定する際の基準データが充填される「必須Flg」、「種類」、「項目長」の各データ項目が設定されている。
【００３１】
つぎに、データ充填部24によって上記ルールオブジェクト62に対し具体的なデータが充填される（Ｓ52）。
このフォーム46を通じた検索処理時には、上記の通り色タイプコード入力フィールド47への入力データについてのみ適否を判定すれば事足りたが、登録・更新時には全ての入力フィールドにおける入力データの適否を判定する必要があるため、図示の通り、データ充填部24はフォーム46中に表示された全ての入力フィールドに対して入力データ及び判定基準データを充填する。
図９においては、１行目から１５行目までの入力フィールドについてデータを充填した状態が描かれているが、画面スクロールによってさらに多くの行が表示される場合には、それらについても必要データの充填が実行される。
【００３２】
つぎに、適合性判定部26が上記ルールオブジェクト62に充填された入力データと判定基準データとを比較し、その適否を判定する（Ｓ54）。
ここで「適合」の判定が下された場合には、クライアント端末14から送信された入力データがDBサーバ20に登録・更新される（Ｓ58）。
【００３３】
このシステム10においては、クライアント端末14において入力データの適合性について一次チェックが完了しているため、サーバ側の適合性判定部26によってエラーメッセージが発行される可能性は低いといえるが、何らかの理由によってクライアント端末14側のチェック機能が動作しない場合であっても、サーバ10側において同一ロジックに基づくチェック処理が実行されるため、無効なデータ（ブランクを含む）に基づいて検索処理を実行したり、不正なデータが誤って登録されることがない（Ｓ34、Ｓ56）。
また、ハッカーなど悪意のユーザがサーバ12に侵入し、不正なデータを大量に送出する攻撃を仕掛けてきた場合にも、サーバ側のチェック機能によってこれを有効に排除することが可能となる。
【００３４】
上記においては、クライアント端末14から送信要求のあったフォーム46に関し、クライアント側のチェックコードがコード格納部30内にキャッシュされている場合について説明したが、ここに該当のコードが存在しない場合には、APサーバ18においてクライアント側コードが新規に生成される。
以下、図４のフローチャートに従い、この場合の処理手順について説明する。
【００３５】
まず、APサーバ18は、当該フォーム46に対応したサーバ側の実行モジュールαを起動させる（Ｓ60）。
つぎに、ルールオブジェクト設定部22が当該実行モジュールαの記述内容を解析し、該当のフォーム46において実行されるべきチェックロジック（対象フィールド及び判定基準の組合せ）の種類（パターン）を検出する（Ｓ62）。
図５及び図８に例示したフォーム46の場合には、上記の通り「検索」時と「登録・更新」時とで異なったチェックロジックが適用されるため、検索時用及び登録・更新時用の２種類のチェックロジックが検出される。
この前提として、サーバ側実行モジュールα内には、予めチェックロジックの種類について宣言する記述が設けられている。
【００３６】
つぎに、ルールオブジェクト設定部22は、図１０及び図１１に示すように、APサーバ18のメモリ空間51上にルールオブジェクト50、62を設定する（Ｓ64）。
このルールオブジェクト50、62は、サーバ側実行モジュールα内に設定されたチェックロジックの種類毎に設定され、対象フィールドを特定する「名前」と、判定対象である入力データを充填するための「値」と、判定基準データを充填するための「必須Flg」、「種類」、「項目長」の各データ項目を備えている。
因みに、図１０はフォーム46の「検索」処理時のルールオブジェクト50を示しており、図１１は同フォーム46の「登録・更新」処理時用のルールオブジェクト62を示している。
【００３７】
つぎに、サーバ実行モジュールαに記述されたコードに従い、データ充填部24が上記ルールオブジェクト50、62に対し必要なデータを充填する（Ｓ66）。
すなわち、チェックロジックの種類に応じ、フォーム46に設けられた該当の入力フィールドに、「名前」、「必須Flg」、「種類」、「項目長」の各データを充填する。
ここでは、クライアント端末14からの入力データは存在しないため、「値」の項目はブランクのまま残される。
【００３８】
必要なフィールドに対するデータの充填が完了した時点で、データ充填部24からクライアント側コード生成部28にルールオブジェクト50、62が渡される。
クライアント側コード生成部28は、ルールオブジェクト50、62に充填された各データを取り出し、JavaScriptの文法に従って変換することにより、クライアント側のチェックコードを生成する（Ｓ68）。
生成されたクライアント側のチェックコードは、コード格納部30にキャッシュされ（Ｓ70）、次に他のクライアント端末14から当該フォーム46の送信リクエストが発せられた際に再利用される。
同時に、生成されたクライアント側コードは、Webサーバ16によってフォーム（Htmlファイル）と共にクライアント端末14に送信され（図２のＳ16）、Webブラウザ上にフォーム46が表示された時点で入力待機状態となる。
【００３９】
なお、上記のクライアント側チェックコードは、チェック処理の対象フィールドと判定基準データを定義するものであり、ユーザからの入力データと判定基準データとを比較して適否を判定する機能を実現するためのコードは含まれていない。
この判定処理を実現するためのコード（JavaScript）については、各フォーム共通で汎用的に使い回せるものであるため、事前にクライアント端末14に配信されている。
もちろん、初めてサーバ12にアクセスしたクライアント端末14に対しては、この判定処理用のコードが配信される。
【００４０】
このシステム10においては、上記の通り、サーバ側の実行モジュールαはクライアント端末14に配信されるフォーム毎に作成され、予めAPサーバ18内に格納されているのに対し、クライアント側のチェックコードは予め作成されることはなく、クライアント端末14から特定フォームの表示リクエストが最初に送信された時点で、ルールオブジェクト設定部22、データ充填部24、及びクライアント側コード生成部28によって自動生成される。
このように、サーバ側の実行モジュールを基本に据え、必要に応じてクライアント側のチェックコードを動的に生成することにより、以下の利点が生じる。
第１に、サーバ側のチェックロジック（対象フィールド及び判定基準データ）に修正や変更が生じた場合でも、それに応じて直ちにクライアント側コードに修正・変更を加える必要がなく、クライアント端末14に該当のフォームを送信する際に自動的に最新のロジックを反映させたクライアント側コードが生成されるため、サーバ側のチェックロジックとクライアント側のチェックロジック間で完全な同一性を確保することが可能となる。
第２に、従来のようにサーバ側のチェックロジックを人為的に解析し、他の言語に翻訳する場合に比べて効率化や省力化が図れると共に、誤訳の発生も排除できる。
【００４１】
このシステム10の場合、上記のようにサーバ側実行モジュールによる入力データの判定処理が、ルールオブジェクトに対し必要データを充填するステップと、充填された入力データと判定基準データとを比較して適否を判定するステップによって実現されるため、サーバ側実行モジュールを仮想的に実行させることにより、各フィールドに係る判定基準データを外部に取り出すと共に、これに基づいて他言語によるチェックコードを生成することが可能となる。
もちろん、判定処理時とチェックコード生成時とで同じルールオブジェクトが用いられるため、サーバ側実行モジュールのチェックロジックを正確に反映させたクライアント側チェックコードを得ることができる。
【００４２】
この実施の形態においては、Java言語によって記述されたソースコードをコンパイルすることによってサーバ側実行モジュールαが生成され、これを仮想的に実行させることによって抽出した判定基準データを基にJavaScriptで記述されたクライアント側コードを自動生成する例を示したが、この発明はこれに限定されるものではなく、他の言語によって記述された実行モジュールに基づいて別の言語によるクライアント側コードを自動生成することもできる。
【００４３】
また、上記においては、ある入力フィールドに対する入力データの適否を「必須Flg」、「種類」、「項目長」の３つの観点から判定する例を示したが、この発明はこれに限定されるものではない。
例えば、判定基準項目の一つとして、他のフィールドへの入力値に基づく所定の演算処理を定義する項目を設定しておくことで、特定のフィールドにおける入力データの適否を、他のフィールドにおける入力データとの相対的な関係に基づいて判定することが可能となる。
【図面の簡単な説明】
【００４４】
【図１】この発明に係るシステムの構成を示すブロック図である。
【図２】サーバ及びクライアント端末における処理手順を説明するフローチャートである。
【図３】サーバ及びクライアント端末における処理手順を説明するフローチャートである。
【図４】サーバ及びクライアント端末における処理手順を説明するフローチャートである。
【図５】色コード登録用のフォームを示すレイアウト図である。
【図６】検索時におけるルールオブジェクトの一例を示すイメージ図である。
【図７】検索時におけるルールオブジェクトに必要データが充填された様子を示すイメージ図である。
【図８】色コード登録用のフォームを示すレイアウト図である。
【図９】登録・更新時におけるルールオブジェクトに必要データが充填された様子を示すイメージ図である。
【図１０】検索時用のチェックコード生成に際し、ルールオブジェクトに必要データが充填された様子を示すイメージ図である。
【図１１】登録・更新時用のチェックコード生成に際し、ルールオブジェクトに必要データが充填された様子を示すイメージ図である。
【図１２】サーバ側チェックプログラムとクライアント側チェックプログラムとの関係を示す概念図である。
【符号の説明】
【００４５】
10  システム
12  センターサーバ
14  クライアント端末
16  Webサーバ
18  APサーバ
20  DBサーバ
22  ルールオブジェクト設定部
24  データ充填部
26  サーバ側の適合性判定部
28  クライアント側コード生成部
30  コード格納部
32  入力ディバイス
34  ディスプレイ
36  ファイル配信要求部
38  Webページ表示部
40  クライアント側の適合性判定部
42  データ処理要求部
44  インターネット
46  色コード登録用のフォーム
47  色タイプコード入力フィールド
48  検索ボタン
49  エラー表示欄
50  ルールオブジェクト
51  メモリ空間
52  登録・更新ボタン
53  １行目の色コード入力フィールド（IroCd1）
54  １行目の色漢字名称入力フィールド（IroKj1）
55  １行目の色カナ名称入力フィールド（IroKn1）
56、57、58  ２行目に並んだ３つの入力フィールド
59、60、61  １５行目に並んだ３つの入力フィールド
62  ルールオブジェクト
【図１】
0004643900.tif 000002
【図２】
0004643900.tif 000003
【図３】
0004643900.tif 000004
【図４】
0004643900.tif 000005
【図５】
0004643900.tif 000006
【図６】
0004643900.tif 000007
【図７】
0004643900.tif 000008
【図８】
0004643900.tif 000009
【図９】
0004643900.tif 000010
【図１０】
0004643900.tif 000011
【図１１】
0004643900.tif 000012
【図１２】
0004643900.tif 000013