(57)【要約】【課題】Ｗｅｂアプリケーションの開発時におけるモジュールの管理工数、コーディング工数を低減する。画面遷移全体が見えなくても画面遷移が決まったところから単独で実装可能にし、開発の効率化を図る。【解決手段】クライアントから業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を受付ける要求受付手段と、受付けた前記業務処理の識別情報に対応する業務処理モジュールに処理を振り分け、処理結果を取得する業務処理振り分け手段と、前記識別情報と業務処理モジュールの処理結果に基づいて複数の画面生成モジュールのいずれかに処理結果の画面生成処理を振り分ける生成画面制御手段と、振り分けられた処理結果の画面データを生成し、要求元のクライアントへの応答として出力する複数の画面生成モジュールから成る画面生成手段とを備える。【選択図】　　　　図２
2004038559.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの要求内容に応じた業務処理を予め用意された複数の業務処理モジュールのいずれかに振り分け、処理結果を要求元のクライアントに返信するＷｅｂアプリケーション制御装置であって、
クライアントから業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を受付ける要求受付手段と、
受付けた前記業務処理の識別情報に対応する業務処理モジュールに処理を振り分け、処理結果を取得する業務処理振り分け手段と、
前記識別情報と業務処理モジュールの処理結果に基づいて複数の画面生成モジュールのいずれかに処理結果の画面生成処理を振り分ける生成画面制御手段と、
振り分けられた処理結果の画面データを生成し、要求元のクライアントへの応答として出力する複数の画面生成モジュールから成る画面生成手段と
を備えることを特徴とするＷｅｂアプリケーション制御装置。
【請求項２】
複数の業務処理モジュールを使用してそれぞれ異なる業務処理を行うためのシナリオを記述した複数の業務シナリオモジュールを備え、前記業務処理振り分け手段は前記業務処理の識別情報として前記業務シナリオモジュールに対応する識別情報をクライアントから受付け、受付けた識別情報に対応した業務シナリオモジュールに対し処理を振り分けることを特徴とする請求項１に記載のＷｅｂアプリケーション制御装置。
【請求項３】
業務処理要求を送信するクライアントと、業務処理要求をネットワークを介して受付け、要求内容に応じた業務処理を実行し、処理結果を要求元のクライアントに返信するアプリケーションサーバとを備えるネットワークシステムにおいて、
前記クライアントが、業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を送信する手段を有し、
前記アプリケーションサーバが、
クライアントから業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を受付ける要求受付手段と、
予め用意された複数の業務処理モジュールのうちクライアントから受付けた前記業務処理の識別情報に対応する業務処理モジュールに処理を振り分け、処理結果を取得する業務処理振り分け手段と、
前記識別情報と業務処理モジュールの処理結果に基づいて複数の画面生成モジュールのいずれかに処理結果の画面生成処理を振り分ける生成画面制御手段と、
振り分けられた処理結果の画面データを生成し、要求元のクライアントへの応答として出力する複数の画面生成モジュールから成る画面生成手段と
を備えることを特徴とするネットワークシステム。
【請求項４】
前記アプリケーションサーバが、複数の業務処理モジュールを使用してそれぞれ異なる業務処理を行うためのシナリオを記述した複数の業務シナリオモジュールをさらに備え、前記業務処理振り分け手段は前記業務処理の識別情報として前記業務シナリオモジュールに対応する識別情報をクライアントから受付け、受付けた識別情報に対応した業務シナリオモジュールに対し処理を振り分けることを特徴とする請求項３に記載のネットワークシステム。
【請求項５】
クライアントからの要求内容に応じた業務処理を予め用意された複数の業務処理モジュールのいずれかに振り分け、処理結果を要求元のクライアントに返信するＷｅｂアプリケーション制御プログラムであって、
クライアントから業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を受付ける要求受付ステップと、
受付けた前記業務処理の識別情報に対応する業務処理モジュールに処理を振り分け、処理結果を取得する業務処理振り分けステップと、
前記識別情報と業務処理モジュールの処理結果に基づいて複数の画面生成モジュールのいずれかに処理結果の画面生成処理を振り分ける生成画面制御ステップと、
振り分けられた処理結果の画面データを生成し、要求元のクライアントへの応答として出力する画面生成ステップと
を備えることを特徴とするＷｅｂアプリケーション制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クライアントがＷｅｂアプリケーションアクセス時に出す要求を受け取り、当該要求に基づいて実行する業務を決定し、業務の実行結果から出力する情報および表示方法を決定するＷｅｂアプリケーション制御装置に関し、特に、Ｗｅｂアプリケーションの開発工数を削減し、効率的な開発を可能にするＷｅｂアプリケーション制御装置およびネットワークシステム並びにプログラムに関する。
【０００２】
【従来の技術】
近年、インターネット、イントラネット上のＷｅｂアプリケーションシステムでサーバサイドの技術を利用したシステムが普及してきている。
近年のＷｅｂアプリケーションの開発においてサーバ上のアプリケーションの設計方法についてはいくつかの方法が知られている。
図１７は、クライアントからの要求を受付けるモジュール（サーブレット）と業務処理を行うモジュール（Ｂｅａｎ）と画面を出力するモジュール（ＪＳＰ）を対応させて設計する方法（以降、個別方式と呼ぶ）の概要を示す図であり、特開２００１−３４４１０５号公報で開示されている。
この図１７で示される方法にあっては、クライアントから送信される業務処理要求を入力として受付ける要求受付部１７０１と要求内容に応じた業務処理結果を行う業務処理モジュール１７０２と、処理結果の画面を生成する画面生成モジュールと１７０３とを１対１に対応付け、要求受付部１７０１で受付けた業務処理要求の内容に応じた業務処理を対応する業務処理モジュール１７０２で実行させ、その結果に応じた画面を対応する画面生成モジュール１７０３で生成させ、その生成結果の画面を業務処理要求に対する応答（出力）として要求元のクライアントに返信するように構成される。
【０００３】
一方、図１８に示すように、クライアントからの要求を１つの代表モジュール（要求受付部）１８０１が受け付け、要求内容に応じた業務処理モジュールおよび画面遷移決定モジュールを業務処理決定部１８０２で決定し、その決定結果に応じた業務処理を複数の業務処理モジュール１８０３−１〜１８０３−ｎのいずれかに振り分けて実行させ、その結果に応じた画面遷移を画面遷移決定モジュール１８０４で決定し、その決定結果に従った画面を画面生成モジュール１８０５で生成させ、業務処理要求に対する応答（出力）として要求元のクライアントに返信するようにした方法（以降、エンジン方式と呼ぶ）が「ＥＪＢコンポーネントによるＷｅｂシステム構築技法」（２００２年３月１５日発行、著者：湯浦克彦　他、発行所：ソフト・リサーチ・センター）の１２９〜１３１ページで開示されている。
【０００４】
【発明が解決しようとする課題】
上記従来技術は近年のシステム開発での開発サイクルの短時間化に合わせて開発されたものである。特に業務系システムや業務サービスをＷｅｂ上で公開する場合、その開発サイクルを短縮することは顧客ニーズとして強い要求事項である。Ｗｅｂアプリケーションシステムにおいて、Ｗｅｂページのデザインや情報を定期的に変更するだけでなく、そのシステム上で新規サービスを早期に公開したり、サービスを迅速に拡張可能にすることが求められている。それらの顧客ニーズに対応し、Ｗｅｂアプリケーションシステムの開発サイクルに対応するためにも、その開発作業を軽減させ、かつ、スピードアップを図る必要がある。
【０００５】
しかし、従来の方法には以下のような問題点がある。
特開２００１−３４４１０５号公報で開示されている図１７の個別方式の場合、要求を受付けるモジュールを画面生成モジュールと１対１に対応させて作成しているため、要求を受付けるモジュールは必ず、画面と同じ個数だけ必要となる。したがって、画面数が増加すると要求を受付けるモジュールの個数も増加する。要求を受付けるモジュールは実行時に別々にメモリにロードされるため、画面数の増加に伴い、メモリ上にロードされる要求受付モジュールの数も増加し、リソースの消費量が増加し、性能が低下するという問題がある。
また、管理面の問題として画面数の増加に伴って、モジュールの管理工数が増加するという問題が発生する。また、要求を受付けるモジュールは、たとえ数行のコーディングであっても、コーディングの必要が必ず発生するため、画面数が増えるとコーディングの負担が大きくなるという問題がある。
【０００６】
一方、図１８のエンジン方式では１つの要求受付モジュールがクライアントからの要求を代表して受付けた後、複数の業務処理モジュールの中から、実行する業務処理モジュールを決定する。そのときには画面遷移情報を定義した画面遷移定義ファイル１８０６が必要である。さらに業務処理の結果によって出力する画面を変更するためには、画面遷移決定モジュール１８０４を業務処理モジュールごとに実装する必要がある。
上述のようにエンジン方式の場合には、要求を受付けるモジュールは１つでよい。このため、管理工数やコストが増大するという問題は発生しない。
【０００７】
しかしながら、実行する業務処理モジュールを決定するためには、画面遷移の情報を定義した画面遷移定義ファイルが必要になる。このため、画面遷移が複雑になると、面遷移定義ファイルも複雑になり、画面遷移定義ファイルの設計、および作成にかかる負担が増加するという問題がある。
さらに、画面遷移全体が画面遷移定義ファイルに記述されるため、画面遷移全体が見えなければ、実装に着手できないという問題があった。
【０００８】
本発明の目的は、Ｗｅｂアプリケーションの開発時にクライアントからの要求を受付けるモジュールがシステム上に少なくとも１つ有することでＷｅｂアプリケーションを実装可能にし、画面数の増加に伴ってリソースの消費量が増加し、モジュールの管理工数が増加し、モジュールのコーディング工数が増加するといった問題を解決することにある。
さらに画面遷移定義ファイルを不要にすることで、画面遷移定義ファイルの設計、作成にかかる工数を削減し、また、画面遷移全体が見えなくても画面遷移が決まったところから単独で実装可能にすることで、開発の効率的向上を可能にすることにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明に係るＷｅｂアプリケーション制御装置は、クライアントからの要求内容に応じた業務処理を予め用意された複数の業務処理モジュールのいずれかに振り分け、処理結果を要求元のクライアントに返信するＷｅｂアプリケーション制御装置であって、
クライアントから業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を受付ける要求受付手段と、受付けた前記業務処理の識別情報に対応する業務処理モジュールに処理を振り分け、処理結果を取得する業務処理振り分け手段と、前記識別情報と業務処理モジュールの処理結果に基づいて複数の画面生成モジュールのいずれかに処理結果の画面生成処理を振り分ける生成画面制御手段と、振り分けられた処理結果の画面データを生成し、要求元のクライアントへの応答として出力する複数の画面生成モジュールから成る画面生成手段とを備えることを特徴とする。
また、複数の業務処理モジュールを使用してそれぞれ異なる業務処理を行うためのシナリオを記述した複数の業務シナリオモジュールを備え、前記業務処理振り分け手段は前記業務処理の識別情報として前記業務シナリオモジュールに対応する識別情報をクライアントから受付け、受付けた識別情報に対応した業務シナリオモジュールに対し処理を振り分けることを特徴とする。
【００１０】
また、業務処理要求を送信するクライアントと、業務処理要求をネットワークを介して受付け、要求内容に応じた業務処理を実行し、処理結果を要求元のクライアントに返信するアプリケーションサーバとを備えるネットワークシステムにおいて、前記クライアントが、業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を送信する手段を有し、
前記アプリケーションサーバが、クライアントから業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を受付ける要求受付手段と、
予め用意された複数の業務処理モジュールのうちクライアントから受付けた前記業務処理の識別情報に対応する業務処理モジュールに処理を振り分け、処理結果を取得する業務処理振り分け手段と、前記識別情報と業務処理モジュールの処理結果に基づいて複数の画面生成モジュールのいずれかに処理結果の画面生成処理を振り分ける生成画面制御手段と、振り分けられた処理結果の画面データを生成し、要求元のクライアントへの応答として出力する複数の画面生成モジュールから成る画面生成手段とを備えることを特徴とする。
また、前記アプリケーションサーバが、複数の業務処理モジュールを使用してそれぞれ異なる業務処理を行うためのシナリオを記述した複数の業務シナリオモジュールをさらに備え、前記業務処理振り分け手段は前記業務処理の識別情報として前記業務シナリオモジュールに対応する識別情報をクライアントから受付け、受付けた識別情報に対応した業務シナリオモジュールに対し処理を振り分けることを特徴とする。
【００１１】
また、クライアントからの要求内容に応じた業務処理を予め用意された複数の業務処理モジュールのいずれかに振り分け、処理結果を要求元のクライアントに返信するＷｅｂアプリケーション制御プログラムであって、クライアントから業務処理の対象となるデータと共に実行すべき業務処理の識別情報を含む要求を受付ける要求受付ステップと、受付けた前記業務処理の識別情報に対応する業務処理モジュールに処理を振り分け、処理結果を取得する業務処理振り分けステップと、前記識別情報と業務処理モジュールの処理結果に基づいて複数の画面生成モジュールのいずれかに処理結果の画面生成処理を振り分ける生成画面制御ステップと、振り分けられた処理結果の画面データを生成し、要求元のクライアントへの応答として出力する画面生成ステップとを備えることを特徴とするＷｅｂアプリケーション制御プログラム。
【００１２】
【発明の実施の形態】
以下、本発明を実施する場合の一形態について、図面を参照して具体的に説明する。
図１および図２は、本発明を適用したネットワークシステムの一実施形態の構成例を示すブロック図である。
本発明に係るＷｅｂアプリケーション制御装置を構成する処理プログラム制御装置１１０は、Ｗｅｂアプリケーション１０７のアプリケーションサーバ１０４内に存在する。
Ｗｅｂアプリケーション１０７は、インターネット１０２上で利用可能なアプリケーションであり、クライアント１０１からの要求を受付けるＷｅｂサーバ１０３、業務処理を行うアプリケーションサーバ１０４、データベース１０６にアクセスするデータベースサーバ１０５、およびデータベース１０６から構成されている。
クライアント１０１は、ユーザ１００による操作を受け付け、インターネット１０２を経由してＷｅｂアプリケーション１０７に入力電文１３０を送信し、Ｗｅｂアプリケーション１０７からの出力電文１３１を受け取り、ユーザ１００に提示するＷｅｂブラウザ１４１や個別アプリケーション１４２などアプリケーションまたはハードウェアデバイスで構成されている。
【００１３】
アプリケーションサーバ１０４には、図２に示すように、クライアント１０１からの入力電文１３０を受け取り、受け取った入力電文の内容に応じた業務処理を業務シナリオモジュール１１４の複数の業務シナリオモジュール（シナリオ１〜Ｎ）１１４１のいずれかに振り分けて実行させ、その実行結果を受け取り、出力電文１３１を生成する画面生成モジュール１１６を決定する業務処理プログラム制御装置１１０と、業務１〜業務Ｌから成る複数の業務モジュール１１５を使用して、一連の業務を実行する業務シナリオモジュール１１４と、業務処理を行う業務１〜業務Ｌから成る業務モジュール１１５と、クライアント１０１に返送する出力電文１３１の生成を行う画面生成モジュール１１６が存在する。
各業務シナリオモジュール１１４１は、それぞれ一意に識別するためのＩＤが付けられている。各業務シナリオモジュール１１４１は、クライアント１０１からの要求を受付けてから、クライアント１０１へ応答するまでに行う処理ごとに、１モジュール存在する。
各業務シナリオモジュール１１４１とは、複数の業務モジュールを組み合わせて使用し、所定の処理結果を得るためのシナリオが記述されたモジュールであり、シナリオ１〜Ｎではそれぞれ異なる処理結果を得るようなシナリオが記述されている。シナリオとしては、所定の処理結果を得るために必要となる１ないし複数の業務モジュール名、その業務モジュールの実行順序等が記述されている。
また、各業務モジュール１１５１は１つの業務処理ごとに存在し、また画面生成モジュール１１６は複数の画面生成モジュール（画面生成１〜Ｍ）１１６１で構成され、各画面生成モジュール１１６１は１つの画面に対して１つ存在する。
【００１４】
業務処理プログラム制御装置１１０は図２に示すように、クライアント１０１がインターネット１０２を介して送信した入力電文１３０を受付ける要求受付部１１１と、入力データ１２１を渡して処理を振り分け、業務処理結果を受け取る業務処理振分部１１２と、業務処理結果１１７に従って実行する画面生成モジュール１１６を決定する生成画面制御部１１３と、入力データ１２１、実行シナリオＩＤ１２２、業務結果コード１２３、出力情報１２４、生成画面決定テーブル１２５を格納するメモリ１２０から構成される。
業務処理プログラム制御装置１１０を構成する要求受付け部１１１、業務処理振り分け部１１２、生成画面制御部１１３は、具体的にはプログラムで構成されるものである。
【００１５】
以下、本発明に係る業務処理プログラム制御装置１１０の各構成要素について説明する。
要求受付部１１１は、クライアント１０１からの要求を受付けるモジュールである。要求受付部１１１は図３に示すようなフォーマット構成の入力電文１３０を受け付け、入力電文１３０中から実行シナリオＩＤ２０４と入力データ２０５を取得し、メモリ１２０上の入力データ１２１、実行シナリオＩＤ１２２にそれぞれ格納する処理を行う。
要求受付部１１１には個々の画面生成モジュール１１６に依存する処理を含まないため、従来の個別方式のように要求受付部１１１と画面生成モジュール１１６を対応させる必要はない。したがって、要求受付部１１１は画面生成モジュール１１６と関係なく、アプリケーションサーバ１０４上に少なくとも１つあればよい。
【００１６】
業務処理振分部１１２は要求内容に応じた業務処理を実行するための業務シナリオモジュール１１４１（シナリオ１〜Ｎのいずれか）を決定した後、メモリ１２０上の入力データ１２１を渡して業務処理を実行させ、業務処理結果１１７を受け取るモジュールである。業務処理振分部１１２は業務シナリオモジュール１１４１（シナリオ１〜Ｎのいずれか）を決定する際に、メモリ１２０上から実行シナリオＩＤ１２２を取得する。各業務シナリオモジュール１１４１には、一意に識別するためのシナリオＩＤが付けられており、実行シナリオＩＤ１２２から、実行する業務シナリオモジュール１１４１を一意に決定する。したがって、実行する業務シナリオモジュール１１４１を決定するために、従来のエンジン方式で必要な画面遷移の情報を定義した画面遷移定義ファイルは不要になる。
【００１７】
業務処理振分部１１２は、業務処理実行後、業務シナリオモジュール１１４から業務処理結果１１７を受け取り、その業務処理結果１１７から図６に示すような業務結果コード５０３と出力情報５０４を取得し、メモリ１２０上に業務結果コード１２３と出力情報１２４としてそれぞれ格納する。
生成画面制御部１１３は、出力電文１３１を生成する画面生成モジュール１１６を決定し、実行するモジュールである。画面生成モジュール１１６１（画面生成１〜Ｍのいずれか）を決定する際には、メモリ１２０上の実行シナリオＩＤ１２２と業務結果コード１２３をもとに、生成画面決定テーブル１２５を参照して決定する。
【００１８】
図３は入力電文１３０の構造を示す図である。
入力電文１３０はＨＴＴＰヘッダ２０１と現画面ＩＤ２０２とイベントＩＤ２０３と実行シナリオＩＤ２０４と入力データ２０５、および各項目を連結する「＆」２０６から構成される。
ＨＴＴＰヘッダ２０１は、ＨＴＴＰで通信する際の電文のヘッダである。現画面ＩＤ２０２は、クライアント１０１に現在表示されている画面のＩＤである。イベントＩＤ２０３は、クライアント１０１上で発生したイベントに対応するＩＤである。実行シナリオＩＤ２０４は実行する業務シナリオモジュール１１４１のＩＤで業務処理振り分け部１１２において、実行する業務シナリオモジュール１１４１を決定する際に使用する。入力データ２０５は、クライアント１０１から入力され、業務処理の入力となるデータであり、各データ間は「＆」２０６で結合されている。なお、現画面ＩＤ２０２、イベントＩＤ２０３は業務処理において、一般的に使用されるものである。
【００１９】
図４は出力電文１３１の構造を示す図である。
出力電文１３１は、ＨＴＴＰヘッダ３０１、画面レイアウト３０２、業務結果の出力３０３、イベントに対する処理コード３０４から構成される。
ＨＴＴＰヘッダ３０１はＨＴＴＰで通信する際のヘッダである。画面レイアウト３０２は画面のレイアウトに関するＨＴＭＬである。業務結果の出力３０３は業務処理を実行した結果を表示する部分のＨＴＭＬである。イベントに対する処理コード３０４は、画面上でボタンクリックなどのイベントが発生した際に、クライアント１０１上で行う処理を実行するコードである。
【００２０】
図５は入力データ１２１の構造を示す図である。
入力データ１２１はキー４０１と値４０２の組を持つハッシュテーブルであり、現画面ＩＤ４０３、イベントＩＤ４０４、その他のデータ４０５から構成される。現画面ＩＤ４０３はクライアント１０１に現在表示されている画面のＩＤであり、イベントＩＤ４０４はクライアント１０１上で発生したイベントのＩＤである。その他のデータ４０５はクライアント１０１から入力されたデータで、業務処理の入力となるデータである。
【００２１】
図６は業務処理結果１１７の構造を示す図である。
業務処理結果１１７はキー５０１と値５０２の組を持つハッシュテーブルである。業務処理結果１１７は、業務結果コード５０３と出力情報５０４から構成される。業務結果コード５０３は、業務シナリオモジュール１１４１で業務を実行した結果の状態を表すコードである。出力情報５０４は、業務処理の結果として出力電文１３１を生成するための情報である。
【００２２】
図７は、生成画面決定テーブル１２５の構造を示す図である。
生成画面決定テーブル１２５は、行方向６０２にシナリオＩＤ、列方向６０１に業務結果コードを取り、各カラム６０３に実行する画面生成モジュール１１６のＩＤを設定した表である。
生成画面決定テーブル１２５は、生成画面制御部１１３において、実行する画面生成モジュール１１６を決定する際に使用される。
【００２３】
図８は、上記の構成における動作を示すフローチャートである。
以下、このフローチャートに従ってクライアントからの要求を受付けてから業務処理結果を返信するまでの動作について説明する。
まず、ユーザ１００の操作によりクライアント１０１が実行シナリオＩＤ２０４を含む入力電文１３０を生成し、インターネット１０２を介してＷｅｂサーバ１０３に入力電文１３０を送信する（ステップ７０１）。Ｗｅｂサーバ１０３は入力電文１３０を受け取り、アプリケーションサーバ１０４に渡す（ステップ７０２）。
アプリケーションサーバ１０４上の要求受付部１１１は、入力電文１３０を受け取り、入力電文１３０から実行シナリオＩＤ２０４と入力データ２０５を取得し（ステップ７０３）、取得した実行シナリオＩＤ２０４と入力データ２０５を、それぞれメモリ１２０上の実行シナリオＩＤ１２２、入力データ１２１として格納する（ステップ７０４）。
【００２４】
業務処理振分部１１２はメモリ１２０上から実行シナリオＩＤ１２２を取得し（ステップ７０５）、取得した実行シナリオＩＤ１２２に対応する業務シナリオモジュール１１４１に処理を振り分けるよう決定する（ステップ７０６）。さらに、メモリ１２０から入力データ１２１を取得して、ステップ７０６で決定した業務処理モジュール１１４１に、取得した入力データ１２１を渡して、呼び出す（ステップ７０７）。
呼び出された業務シナリオモジュール１１４１は入力データ１２１を受け取り、業務処理を実行するのに必要な業務モジュール１１５１を実行し、業務処理を実行する（ステップ７０８）。
さらに業務処理結果１１７を生成し、業務処理結果１１７内に業務処理の結果の状態を表すコードである業務結果コード５０３と、出力電文１３１を生成する際に使用する情報である出力情報５０４を格納し、業務処理振分部１１２に返す（ステップ７０９）。
【００２５】
業務処理振分部１１２は、業務処理結果１１７を受け取り、業務処理結果１１７から、業務結果コード５０３と出力情報５０４を取得し（ステップ７１０）、取得した業務結果コード５０３と出力情報５０４をそれぞれ業務結果コード１２３、出力情報１２４として、メモリ１２０上に格納する（ステップ７１１）。
次に生成画面制御部１１３はメモリ１２０上から実行シナリオＩＤ１２２と業務結果コード１２３を取得する（ステップ７１２）。
生成画面制御部１１３はメモリ１２０上の生成画面決定テーブル１２５を参照し、ステップ７１２で取得した実行シナリオＩＤ１２２の行、業務結果コード１２３の列を参照し、該当カラムに設定されている画面生成モジュール１１６１のＩＤを取得し、取得した画面生成モジュール１１６１のＩＤに対応する画面生成モジュール１１６を実行する（ステップ７１３）。
【００２６】
画面生成モジュール１１６１はメモリ１２０上から出力情報１２４を受け取り、出力電文１３１を生成し、クライアント１０１に送信する（ステップ７１４）。クライアント１０１は受け取った出力電文１３１を解釈して、ユーザ１００が閲覧可能な形式で表示する（ステップ７１５）。
【００２７】
次に、簡単なＷｅｂアプリケーションの例によって、本実施形態の動作を具体的に説明する。
図９はＷｅｂアプリケーションの画面遷移の一例を示す図である。
図９で示されるＷｅｂアプリケーションは、会員情報入力画面８１０と入力内容確認画面８２０と会員登録画面８３０から構成される。各画面の画面ＩＤは、それぞれＧ０００１、Ｇ０００２、Ｇ０００３である。
会員情報入力画面８１０はユーザ１００が会員登録をするために会員情報を入力する画面である。
会員情報入力画面８１０は氏名８１１、氏名（カナ）８１２、メールアドレス８１３、電話番号８１４の入力ボックスと、「登録」ボタン８１５により構成される。「登録」ボタン８１５を押下すると、入力内容確認画面８２０に遷移する。
【００２８】
入力内容確認画面８２０は、ユーザ１００が会員情報入力画面８１０で入力した情報に誤りがないかを、ユーザ１００に確認する画面である。
入力内容確認画面８２０は、ユーザ１００が会員情報入力画面８１０で入力した氏名８２１、氏名（カナ）８２２、メールアドレス８２３、電話番号８２４、「登録する」ボタン８２５、「キャンセル」ボタン８２６によって構成される。「登録する」ボタン８２５を押下すると、会員情報入力画面８１０で入力された情報をデータベース１０６に格納し、会員登録完了画面８３０に遷移する。「キャンセル」ボタン８２６を押下すると、会員情報入力画面８１０に戻る。その際、会員情報入力画面８１０上の、氏名８１１、氏名（カナ）８１２、メールアドレス８１３、電話番号８１４の入力ボックスには先に会員情報入力画面８１０でユーザ１００が入力した情報を初期値として表示する。
【００２９】
会員登録完了画面８３０は、ユーザ１００に対して、会員登録が完了したことを伝える画面である。会員登録完了画面８３０は、登録完了のメッセージ８３１と「登録画面へ」ボタン８３２によって構成される。
「登録画面へ」ボタン８３２を押下すると、会員情報入力画面８１０に遷移する。その際の会員情報入力画面８１０上の氏名８１１、氏名（カナ）８１２、メールアドレス８１３、電話番号８１４の入力ボックスは空欄になっている。
【００３０】
次に、図９のＷｅｂアプリケーションの会員情報入力画面８１０において「登録」ボタン８１５を押した場合の動作を、図１０から図１４を用いて図８のフローチャートに沿って説明する。
まず、会員情報入力画面８１０においてユーザ１００が、氏名８１１、氏名（カナ）８１２、メールアドレス８１３、電話番号８１４を入力し、「登録」ボタン８１５を押すと、クライアント１０１は入力電文１３０を生成し、インターネット１０２を介してＷｅｂサーバ１０３に入力電文１３０を送信する。
この入力電文１３０の中に実行シナリオＩＤ２０４として実行する業務シナリオのＩＤ（この例では、会員情報を登録する業務を実行するための業務シナリオのＩＤ＝Ｇ００１）が含まれている。
【００３１】
図１０は、図９の会員情報入力画面８１０で入力した情報によって生成される入力電文の一例を示す図である。
ＨＴＴＰヘッダ９０１はデータの送信方法や、クライアント１０１の情報を含むＨＴＴＰのヘッダ部分である。
現画面ＩＤ９０２はキーが「Ｃ」で、値には会員情報入力画面８１０の画面ＩＤ「Ｇ０００１」が設定されている。イベントＩＤ９０３は、キーが「Ｅ」で、値は「Ｇ０００１−０１」が設定されている。実行シナリオＩＤ９０４は、キーが「Ｒ」で、値は「Ｓ０００２」が設定されている。
入力データ９０５には、ＮＡＭＥ、ＫＡＮＡ＿ＮＡＭＥ、ＭＡＩＬ、ＴＥＬの項目があり、その値は、それぞれ「平岡」、「ヒラオカ」、「ａａａａ＠ｘｘｘｘ．ｃｏ．ｊｐ」、「０４５−＊２３−４＊＊７」となっている。
【００３２】
Ｗｅｂサーバ１０３は入力電文１３０を受け取り、アプリケーションサーバ１０４に渡す。
アプリケーションサーバ１０４上の要求受付部１１１は、入力電文１３０を受け取り、図１０の入力電文１３０から、実行シナリオＩＤ９０４「Ｓ０００２」と入力データ９０５を取得する。取得した実行シナリオＩＤ９０４「Ｓ０００２」と入力データを、それぞれメモリ１２０内に実行シナリオＩＤ１２２、入力データ１２１として格納する。
【００３３】
図１１は入力データ１２１の一例を示す図である。
この例では、図１の現画面ＩＤ９０２が１００１に、イベントＩＤ９０３が１００２に、入力データ９０５が１００３にそれぞれ設定されている。
次に業務処理振分部１１２は、メモリ１２０上から実行シナリオＩＤ１２２「Ｓ０００２」を取得し、「Ｓ０００２」に１対１に対応する業務シナリオモジュール１１４１に処理を振り分ける。この処理の振分時に、メモリ１２０から入力データ１２１を取得して、業務処理モジュール１１４１に渡す。
シナリオＩＤＳ０００２の業務シナリオモジュール１１４１は、入力データ１２１を受け取り、業務処理を実行するのに必要な１つまたは複数の業務モジュール１１５１を実行し、業務処理結果１１７を返す。
【００３４】
図１２は業務結果１１７の例を示す図である。
図１２で示される業務結果コード１１０１は「０」である。例えば、「０」が正常に業務を終了した場合だとするともし、業務実行中にエラーが発生した場合には、業務結果コード１１０１として、発生したエラーに対応する「０」以外の値を設定する。業務結果１１７のうち出力情報１１０２は、入力内容確認画面８２０に出力する情報であり、会員情報入力画面８１０上の氏名８１１、氏名（カナ）８１２、メールアドレス８１３、電話番号８１４に入力された値である。
次に業務処理振分部１１２は、業務処理結果１１７を受け取り、業務処理結果１１７から、業務結果コード１１０１「０」と出力情報１１０２を取得し、取得した業務結果コード１１０１「０」と出力情報１１０２をそれぞれメモリ１２０内に、業務結果コード１２３、出力情報１２４として格納する。
【００３５】
図１３は生成画面決定テーブル１２５の例を示す図である。
生成画面制御部１１３は、メモリ１２０上から実行シナリオＩＤ１２２「Ｓ０００２」と業務結果コード１２３「０」を取得し、生成画面決定テーブル１２５を参照して、実行する画面生成モジュールを決定する。
例えば、生成画面決定テーブル１２５が図１３のようになっていると、生成画面制御部１１３は、生成画面決定テーブル１２５を参照し、実行シナリオＩＤ「Ｓ０００２」に対応する列１２０１、業務結果コード「０」に対応する行１２０２を参照し、該当するカラム１２０３に設定されているＰ０００２を取得する。そして、Ｐ０００２に対応する画面生成モジュール１１６１（画面生成１〜Ｍのいずれか）を実行する。
【００３６】
次に画面生成モジュール１１６１は、メモリ１２０から出力情報１２４（図１２の１１０２の内容）を取得し、出力電文１３０を生成して、クライアント１０１に送信する。クライアント１０１は、出力電文１３１を受け取り、ユーザ１００に図９の入力内容確認画面８２０の画面を提示する。
【００３７】
図１４は出力電文１３０の例を示す図である。
ＨＴＴＰヘッダ１３０１はＨＴＴＰで通信する際のヘッダである。画面レイアウト１３０２は、入力内容確認画面８２０を表示するＨＴＭＬである。業務結果の出力１３０３は業務の結果を表示するＨＴＭＬであり、ユーザ１００が会員登録入力画面８１０で入力した情報を画面表示する部分、及び次のイベントで入力電文１３０として送信するための情報を埋め込んだ部分となっている。イベントに対する処理コード１３０４は「登録する」ボタン８２５の押下時と「キャンセル」ボタン８２６の押下時に、実行シナリオＩＤ２０４を含む入力電文１３０を生成してＷｅｂサーバ１０３に送信する処理を記述したコードとなっている。
【００３８】
ここで、入力電文１３０中に実行シナリオＩＤ２０４を埋め込む方法について説明する。
「登録する」ボタン８２５を押下すると、「登録する」ボタン８２５のｏｎＣｌｉｃｋイベント１３０５が発生する。ｏｎＣｌｉｃｋイベント１３０５において、「Ｇ０００２−０１」１３０７、「Ｓ０００３」１３０８を引数として、ｐｅｒｆｏｒｍＥｖｅｎｔ関数１３０６を呼び出す。
ｐｅｒｆｏｒｍＥｖｅｎｔ関数とは、呼び出されると、イベントＩＤと実行シナリオＩＤを入力電文の中に埋め込み、その入力電文をサーバへ送信を行う機能を有する。
ｐｅｒｆｏｒｍＥｖｅｎｔ関数１３０６では、受け取った第１引数「Ｇ０００２−０１」をイベントＩＤとして、隠しフィールドの「Ｅ」１３０９に設定する。また、第２引数「Ｓ０００３」を実行シナリオＩＤとして、隠しフィールドの「Ｒ」１３１０に設定する。最後に、ｓｕｂｍｉｔ１３１１を実行し、Ｗｅｂサーバ１０３へ入力電文１３０を送信する。このように、クライアント１０１は、入力電文１３０中にイベントＩＤ２０３と実行シナリオＩＤ２０４を埋め込む。
【００３９】
図１５および図１６はｐｅｒｆｏｒｍＥｖｅｎｔ関数１３０６の引数の設計方法を示す図である。
具体的には入力内容確認画面８２０の設計の例である。
まず、画面上で発生するイベントを設計し、イベントの一覧としてイベント一覧１４０１を作成する。イベント一覧１４０１は、画面生成モジュール１１６１ごとに作成する。次に、イベント発生時にクライアント１０１からＷｅｂサーバ１０３に送信する入力電文１３０を設計し、項目送信仕様１４０２を作成する。項目送信仕様１４０２には、送信する入力電文１３０の実行シナリオＩＤ２０４、および入力データ２０５を記述する。項目送信仕様１４０２は、イベント一覧１４０１に記入されているイベントごとに作成する。
例えば、入力内容確認画面８２０の場合、「登録する」ボタン８２５の押下時のｐｅｒｆｏｒｍＥｖｅｎｔ関数１３０６の第１引数１３０７には、項目送信仕様１４０２のイベントＩＤ「Ｇ０００２−０１」１１０３を設定する。第２引数１３０８には、項目送信仕様１４０２の実行シナリオＩＤ「Ｓ０００３」１４０４を設定する。
このような設計によって画面遷移の全体が見えなくても、個々の画面を独立して設計、および実装可能になる。
【００４０】
【発明の効果】
以上、説明したように本発明によれば、クライアントからの要求を受付けるモジュールを、業務処理を行うモジュールや画面出力するモジュールと対応させる必要がない。したがって、要求を受付けるモジュールは、システム上に少なくとも１つあれば実装可能となり、要求を受付けるモジュールの個数の制限が緩和される。これにより、画面数が増えても、要求を受付けるモジュールの数は増加せず、個別方式で発生するリソース消費量の増加、すなわち性能の劣化を防げる。さらに、要求を受付けるモジュールの増加に伴う、コーディング工数、および管理工数の増加も防げる。
また、本発明によれば、実行する業務処理モジュールを決定するのに従来のようなエンジン方式に必要な画面遷移情報を定義した画面遷移定義ファイルが不要である。この結果、画面遷移定義ファイルの設計、および実装にかかる工数を削減できる。さらに、画面遷移の全体が見えなくても、画面遷移が決まったところから単独で開発できるため、効率的な開発が可能になる。
【図面の簡単な説明】
【図１】本発明を適用したネットワークシステムの一実施の形態を示す構成図である。
【図２】本発明に係る業務処理プログラム制御装置の実施の形態を示す構成図である。
【図３】入力電文の例を示す図である。
【図４】出力電文の例を示す図である。
【図５】入力データの例を示す図である。
【図６】業務処理結果の例を示す図である。
【図７】生成画面決定テーブルの例を示す図である。
【図８】本発明の実施の形態の動作を示すフローチャートである。
【図９】Ｗｅｂアプリケーションの画面遷移の一例を示す図である。
【図１０】入力電文の具体例を示す図である。
【図１１】入力データの具体例を示す図である。
【図１２】業務処理結果の具体例を示す図である。
【図１３】生成画面決定テーブルの具体例を示す図である。
【図１４】出力電文の具体例を示す図である。
【図１５】ｐｅｒｆｏｒｍＥｖｅｎｔ関数の引数の設計方法を説明する図である。
【図１６】ｐｅｒｆｏｒｍＥｖｅｎｔ関数の引数の設計方法を説明する図である。
【図１７】従来技術の１つである個別方式を示す図である。
【図１８】従来技術の１つであるエンジン方式を示す図である。
【符号の説明】
１０１…クライアント、１０２…インターネット、１０３…Ｗｅｂサーバ、
１０４…アプリケーションサーバ、１０５…データベースサーバ、１０６…データベース、１０７…ＷＥＢアプリケーション、１１０…処理プログラム制御装置、１１１…要求受付部、１１２…業務処理振分部、１１３…生成画面制御部、１１４…業務シナリオモジュール、１１５…複数の業務モジュール、１１６…画面生成モジュール、１１７…業務結果、１２０…メモリ、１２１…入力データ、１２２…実行シナリオＩＤ、１２３…業務結果コード、１２４…出力情報、１２５…生成画面決定テーブル、１３０…入力電文、１３１…出力電文。
【図１】
2004038559.tif 000003
【図２】
2004038559.tif 000004
【図３】
2004038559.tif 000005
【図４】
2004038559.tif 000006
【図５】
2004038559.tif 000007
【図６】
2004038559.tif 000008
【図７】
2004038559.tif 000009
【図８】
2004038559.tif 000010
【図９】
2004038559.tif 000011
【図１０】
2004038559.tif 000012
【図１１】
2004038559.tif 000013
【図１２】
2004038559.tif 000014
【図１３】
2004038559.tif 000015
【図１４】
2004038559.tif 000016
【図１５】
2004038559.tif 000017
【図１６】
2004038559.tif 000018
【図１７】
2004038559.tif 000019
【図１８】
2004038559.tif 000020