JP2006235874A - 業務用情報処理システム - Google Patents

Abstract

【課題】 ３層型システム等のクライアント／サーバシステムを利用して業務システムを開発するとき、開発が標準化され、プログラムを修正することなく画面開発を行うことができ、画面レイアウトデザインと画面フォーム部分との切分けを行うことができ、作業効率を向上することができる業務用情報処理システムを提供する。
【解決手段】 この業務用情報処理システムは、プレゼンテーション層１とビジネスロジック層２とデータ層３からなる３層型システム等のクライアント／サーバシステムを用いて構築され、クライアント／サーバシステムのビジネスロジック層２で、クライアント１１から送信されるリクエストのリクエスト内容を処理する処理機能部を２段階の処理手段（２３，２６）により実現し、ビジネスロジック層２を２層構造２Ａ，２Ｂによって形成する。リクエスト処理部２６とレスポンス処理部２７が抽出して設けられる。
【選択図】 図２

Description

本発明は業務用情報処理システムに関し、特に、３層型システム等のクライアント／サーバシステムを用いて業務システムを構築する場合にビジネスロジック層の一部機能を抽出して２層で構成して画面の部品化および顧客業務に対応したカスタマイズ化に好適な業務用情報処理システムに関する。

クライアント／サーバシステムによる分散処理では、クライアントのＷｅｂ情報に係るデータリクエスト（データ要求）に対してサーバはリクエストされたデータをクライアントに送信する。このＷｅｂを利用した分散処理のシステム構成は、近年、３層型システム（Ｗｅｂ３層システム）が採用されている。

図１２に従って３層型システムの構成を説明する。３層型システムはプレゼンテーション層５０１とビジネスロジック層５０２とデータ層５０３とから構成される。プレゼンテーション層５０１はクライアント側に設けられ、ビジネスロジック層５０２とデータ層５０３はサーバ側に設けられる。

３層型システムでは、クライアント／サーバシステムにおける「クライアント」の部分を「入出力部分（ユーザインターフェース部分）」と「その他の実務的な処理部分」とに分け、当該入出力部分のみを、Ｗｅｂブラウザを用いてクライアント５０４に設けるように構成している。このクライアント５０４は上記のごとく「プレゼンテーション層」と呼ばれている。

上記の「その他の実務的な処理部分」は、サーバ側に設けられ、上記のごとく「ビジネスロジック層」と呼ばれている。ビジネスロジック層５０２は、その他の実務的な処理を実行するＷｅｂアプリケーションサーバ５０５で構成されている。上記のクライアント５０４とＷｅｂアプリケーションサーバ５０５はインターネット回線５０６を介して接続されている。

また上記データ層５０３はデータベースサーバ５０７とデータベース５０８によって構成されている。上記のＷｅｂアプリケーションサーバ５０５はデータベースサーバ５０７に接続されている。

上記構成を有する３層型システムのクライアント／サーバシステムを利用して、顧客（企業等）が、例えば自社の営業業務等の業務システム（ＣＲＭやＳＦＡ等）を構築するとき、その業務システムでは、システムの開発・設計・修正（変更）の観点で次の問題が提起される。

従来の業務システム、すなわちＣＲＭパッケージやＳＦＡパッケージでは、顧客の業務をパッケージに当て嵌めてシステムを開発等して構築するものが主流であった。このため、顧客にとっては、業務システムにおいて不必要な機能が付加され、さらにクライアントの画面の構成も必要以上に複雑となり、各顧客の業務に必要のない余分な画面も多々存在し、使いづらいものであった。

さらに従来の業務システムの場合、既に完成した業務システムにおいて、業務の変更等の顧客の事情に応じて例えばクライアントの画面で画面追加の変更を行う場合には、通常プログラム自体を変更しなければならず、作業手順において手間がかかるものであった。

例えば「既に実行可能な顧客情報参照画面に新しく電話番号欄を追加する」ときには、図１３に示すフローチャートのごときプロセスが必要であった。すなわち、プレゼンテーション層ではＪＳＰファイルに欄を追加し（ステップＳ１０１）かつプレゼンテーション層処理プログラムに電話番号にあたる表示領域部分を追加し（ステップＳ１０２)、内部処理（ビジネスロジック層）では固有ロジック（アクション）処理プログラムに電話番号にあたる領域の処理部分を追加し（ステップＳ１０３）、データ層ではＤＢ処理のプログラムに電話番号項目に対する処理を追加する（ステップＳ１０４）ということが必要であった。このように従来開発型の業務システムでは、画面確認とプログラム修正を行うことが要求された。よって手間がかかるものであった。

また例えば「顧客マスタのデータに変更が加えられたら管理者にメールを送信する」という変更を行うときには、図１４に示すフローチャートのごときプロセスが必要であった。すなわち、内部処理（ビジネスロジック層）において固有ロジック（アクション）処理プログラムに「変更が加えられたら」という条件を加え（ステップＳ２０１）、さらに固有ロジックとしてメールを送信するプログラムを作成する（ステップＳ２０２）ということが必要であった。このように従来開発型の業務システムでは、実行確認とプログラム修正を行うことが要求された。よって手間がかかるものであった。

一般的に業務システム等に関するプログラムの開発・設計の先行技術文献として下記の特許文献１と特許文献２を挙げることができる。

特許文献１は、プログラム設計の生産性を高め、顧客の要求を満たすプログラムを容易かつ迅速に作成できるプログラム設計方式を開示する。このプログラム設計方式は、それ以前の新規プログラム開発方式における、既存プログラムに含まれる類似のプログラムソースも含めて開発することに起因するプログラム生産性の低下等に鑑み、プログラム設計の生産性を高め、顧客の要求を満たすようにしたものである。このため、当該プログラム設計方式によれば、代表的には、目的とするプログラムを構成する処理単位を設定し、当該処理単位を基に階層構造でプログラムを設計し、かつ当該処理単位ごとに処理手順を設定し、この処理手順に従って処理内容を設計するようにしている。

上記特許文献１によるプログラム設計方式では、あくまでもプログラムそれ自体の設計の容易化を図るものであり、ソースコードの自動生成の仕組みを提案しており、コンパイルの工程は必須となる。

特許文献２は、利用者の多種の要求に応じて処理画面とその表示データを変更する場合に、プログラムコードを修正することなく、カスタマイズ作業を容易に行うことができる情報処理システムを開示している。この情報処理システムによれば、表示手段に示される処理画面に表示された「データ項目」や「そのデータ項目の性質を表す属性」が記述されたフォーム定義ファイルを読み取るフォーム定義読取り手段と、フォーム定義読取り手段で読み取られた内容に基づき処理画面を表示させる内容を動的に変更する処理画面変更手段を付設している。これにより、処理画面に表示するデータ項目のカスタマイズを、フォーム定義ファイルを修正するだけで行うことができる。

上記特許文献２による情報処理システムでは、処理画面に関してカスタマイズ作業が頻繁に生じるものに関しては、フォーム定義ファイルに記述するようにし、プログラムコードを修正することなく当該フォーム定義ファイルを修正するだけで処理画面やその表示データの変更を可能にするものである。しかし特許文献２による情報処理システムによれば、処理画面の画面表示すなわちフォーム定義ファイルに重点を置いていることから、画面表示の内容に関する顧客に応じた可変性を重視しているということができる。
特開平８−１６３７７号公報 特開平１１−２１２６９４号公報

顧客企業に対して３層型システム等のクライアント／サーバシステムを利用して営業業務システム等を開発して提供する場合、各顧客企業におけるクライアントにおいて、その処理画面に表示される表示内容を変更させる各種の操作ボタンは顧客企業ごとで大きく変わるという特性を有している。当該ボタンの動作の開発・設計・修正は、実際にはビジネスロジック層での処理が大いに関与し、さらにビジネスロジック層での処理は多種多様であるので、顧客企業ごとの業務システムの開発には多大の労力が必要となる。

本発明の目的は、上記の課題に鑑み、３層型システム等のクライアント／サーバシステムを利用して業務システムを開発するとき、開発が標準化され、難しいプログラム言語を知らなくても画面開発を行うことができ、画面レイアウトデザインと画面フォーム部分との切分けを行うことができ、作業効率を向上することができ、開発・導入時のコストを低減することができる業務用情報処理システムを提供することにある。

本発明の他の目的は、３層型システム等のクライアント／サーバシステムを利用して業務システムを開発するときにおいて、画面部分と制御部分を順次に作りながら開発工程を進めることができ、顧客との意思疎通が簡単になり顧客満足度の高い高品質の業務システムを開発できる業務用情報処理システムを提供することにある。

本発明の他の目的は、３層型システム等のクライアント／サーバシステムを利用して業務システムを開発するときにおいて、ビジネスロジック層での多種多様の処理を、プログラムを修正することなく顧客の要望に応じて簡易に変更することのできる業務用情報処理システムを提供することにある。

本発明に係る業務用情報処理システムは、上記目的を達成するために、次のように構成される。

本発明に係る業務用情報処理システム（請求項１に対応）は、プレゼンテーション層とビジネスロジック層とデータ層からなる少なくとも２層型システム（２層型、３層型、多層型の各システム）のクライアント／サーバシステムを用いて構築される業務用情報処理システムであり、クライアント／サーバシステムのアプリケーションサーバ（Ｗｅｂアプリケーションサーバ等のビジネスロジック層）で、クライアントから送信されるリクエストのリクエスト内容を処理する処理機能部を２段階の処理手段により実現し、ビジネスロジック層を２層構造によって形成したことを特徴づけられる。

上記の業務用情報処理システムでは、顧客企業の営業業務システム等の処理画面の表示内容の開発・設計・修正を行う場合に、顧客企業ごとの業務要件に容易に対応してシステムの開発・設計・修正が可能であり、顧客企業ごとのカスタマイズを容易に行うことが可能となるように、ビジネスロジック層でのリクエスト処理の可変性を高める。業務システムにおけるクライアントの処理画面におけるボタンの動作等の表示内容を部品化することが可能である。

本発明に係る業務用情報処理システム（請求項２に対応）は、上記のシステム構成において、好ましくは、クライアントは入出力部分としてのクライアントプログラムを備えており、第１の処理手段は、クライアントのクライアントプログラムから送信されるリクエストを処理するリクエスト処理手段と、クライアントのクライアントプログラムへ送信するためのレスポンスデータを用意するレスポンス処理手段とから構成される。上記のクライアントプログラムは、ブラウザと同様に、クライアントからのリクエストの入力を受け付け、サーバにリクエストデータを送信し、サーバからのレスポンスデータを受け付け、結果を表示させる機能を有するものであればよい。例えば、今日でいうブラウザがそれに相当する。

顧客企業の業務システムにおいて業務に関する処理画面における「保存」、「検索」、「追加」等のボタンの動作等は、これらの処理内容はビジネスロジック層に含まれ、顧客企業ごとに大きく変わる。これらのボタンの動作等の開発・設計・修正は、ビジネスロジック層での処理を変える必要があるが、上記の本発明のシステムでは、修正等に労力が必要なビジネスロジック層での処理を部品化し、かつ複数の部品を組み合わせて動的に画面開発上の処理ロジックを作成することが可能となる。

本発明に係る業務用情報処理システム（請求項３に対応）は、上記のシステム構成において、好ましくは、第２の処理手段は、クライアントのクライアントプログラムから送信されるリクエストを受付け、リクエスト処理手段に所定情報を送るリクエスト受付け手段と、リクエスト処理手段から送られる実行結果を受け、レスポンス処理識別情報（画面のＩＤ情報等）をレスポンス処理手段に送るレスポンス処理決定手段と、レスポンス処理手段からの処理データを受け、クライアントのクライアントプログラムへＨＴＭＬ等のレスポンスデータを送信する送信手段とから構成される。

本発明に係る業務用情報処理システム（請求項４に対応）は、上記のシステム構成において、好ましくは、リクエスト処理手段へ送られるリクエストに含まれる情報は、クライアントプログラムのリクエスト処理識別情報（画面のＩＤ情報等）と当該画面上で操作されたリクエスト処理サブ識別情報（ボタン名情報等）であることで特徴づけられる。

本発明に係る業務用情報処理システム（請求項５に対応）は、上記のシステム構成において、好ましくは、リクエスト処理手段は、リクエストから顧客ごとの業務要件に対応するリスト情報を読み込み、処理ロジックを作成する処理ロジック作成手段を有することで特徴づけられる。

本発明に係る業務用情報処理システム（請求項６に対応）は、上記のシステム構成において、好ましくは、リスト情報はプログラム名とパラメータを含むことを特徴とする。

本発明に係る業務用情報処理システム（請求項７に対応）は、上記のシステム構成において、好ましくは、上記処理ロジックは、上記業務要件で決まる実行手順と、この実行手順の各手順に対応するプログラムおよびパラメータとで構成されることにより特徴づけられる。

本発明に係る業務用情報処理システム（請求項８に対応）は、上記のシステム構成において、好ましくは、処理ロジック作成手段は、プログラム名に対応するプログラムを、予め用意されたプログラム群を格納する記憶装置（ファイルシステム、データベースサーバ等）から読み込むことで特徴づけられる。

本発明によれば次の効果を奏する。
第１に、３層型システム等のクライアント／サーバシステムを利用して営業業務等の業務システムを開発するとき、ビジネスロジック層のリクエスト処理等の処理部分を部品化したため、処理画面の開発が標準化され、難しいプログラム言語を知らなくても処理画面の開発を行うことができ、画面レイアウトデザインと画面フォーム部分との切分けを行うことができる。また業務システムの開発・設計・修正において、作業効率を向上することができ、開発・導入時のコストを低減することができる。
第２に、３層型システム等のクライアント／サーバシステムを利用して営業業務等の業務システムを開発するときにおいて、画面部分と制御部分を順次に作りながら開発工程を進めることができ、顧客との意思疎通が簡単になり顧客満足度の高い高品質の業務システムを開発することができる。
第３に、３層型システム等のクライアント／サーバシステムを利用して営業業務等の業務システムを開発するときにおいて、ビジネスロジック層での多種多様の処理を、プログラムを修正することなく顧客の要望に応じて簡易に変更することができ、顧客企業ごとの業務要件に応じて処理画面の開発・修正をカスタマイズ化することができる。
第４に、処理画面のレイアウトやボタン等の動作の開発・設計・修正についての作業効率を高めることができる。

以下に、本発明の好適な実施形態（実施例）を添付図面に基づいて説明する。

図１は、本発明に係る業務用情報処理システムに適用される代表例として３層型システムのクライアント／サーバシステムの構成を示す。この３層型システムは、全体として、プレゼンテーション層１とビジネスロジック層２とデータ層３とから構成されている。プレゼンテーション層１はクライアント側に設けられ、ビジネスロジック層２とデータ層３はサーバ４側に設けられる。

上記３層型システムにおいて、「入出力部分（ユーザインターフェース部分）」のみを、例えばＷｅｂブラウザ（クライアントプログラム）１１ａを用いてクライアント１１に設けている。クライアント１１はプレゼンテーション層１と呼ばれる。また「実務的な処理部分」はサーバ４側に設けられ、ビジネスロジック層２と呼ばれる。ビジネスロジック層２は実務的な処理を実行する機能部分である。

この実施形態において、ビジネスロジック層２は、より詳しくは、Ｗｅｂアプリケーションサーバ１２とＷｅｂアプリケーションフレームワーク１３と特定アプリケーション手段１４との３つの部分によって構成されている。ビジネスロジック層２は、システム構成上では、Ｗｅｂアプリケーションサーバ１２とＷｅｂアプリケーションフレームワーク１３から成る層部分２Ａと、この実施形態で特定の機能を抽出して作られた特定アプリケーション手段１４の層部分２Ｂの２層構造によって構成されている。

Ｗｅｂアプリケーションサーバ１２とＷｅｂアプリケーションフレームワーク１３から成る層部分２Ａで形成される機能（手段）は、スレッド管理、セッション管理、httpリクエスト（リクエスト）解釈、画面遷移管理、ＸＭＬ処理、ＸＳＬＴレンダリング処理等の機能である。これらの機能は、Ｗｅｂアプリケーションサーバ１２とＷｅｂアプリケーションフレームワーク１３のうちのいずれかに適宜に分けて設けられる。ビジネスロジック層２の実務的な処理部分に関して上記した以外の処理機能は、抽出されることにより上記特定アプリケーション手段１４内の機能として設けられる。特定アプリケーション手段１４の構成・機能の詳細は後述される。

上記のクライアント１１は、インターネット１５を介して、ビジネスロジック層２内のＷｅｂアプリケーションサーバ１２と接続されている。

さらに上記データ層３はデータベースサーバ１６とデータベース１７によって構成されている。ビジネスロジック層２のＷｅｂアプリケーションサーバ１２はデータベースサーバ１６に接続されている。

上記のごとき３層型システムのクライアント／サーバシステムに基づいて構成される本実施形態に係る業務用情報処理システムは、顧客企業の例えば営業業務システムの開発に用いられる。

次に、図２〜図７を参照して、ビジネスロジック層２等における詳細な機能構成とその処理動作を説明する。図２は本実施形態に係る業務用情報処理システムでのアプリケーション全体の処理概要を示す。図３はビジネスロジック層２内の特定アプリケーション手段１４でのリクエスト処理のプロセスを示し、図４は特定アプリケーション手段１４でのレスポンス処理のプロセスを示す。図５は処理ロジック作成エンジンのフローチャートを示し、図６は処理ロジック実行エンジンのフローチャートを示し、図７はデータ抽出ロジック作成エンジンのフローチャートを示している。

図２において、上記ビジネスロジック層２は２つのブロック２１，２２の部分で構成される。ブロック２１は、Ｗｅｂアプリケーションサーバ１２とＷｅｂアプリケーションフレームワーク１３から成る層部分２Ａに対応している。ブロック２２は、上記特定アプリケーション手段１４の層部分２Ｂに対応している。ブロック２１は、機能として、リクエストリスナー２３と画面遷移処理部２４とレンダリング処理部２５を備えている。ブロック２２は、機能として、リクエスト処理部２６とレスポンス処理部２７を備えている。ブロック２２の内容は、Ｗｅｂアプリケーションサーバから抽出された機能である。またブロック２１では前述したスレッド管理やセッション管理等の機能要素の図示は省略されている。

クライアント１１では、顧客企業の営業業務システムのユーザー等が、Ｗｅｂブラウザ１１ａで表示された任意の表示画面における任意のボタン（保存ボタン等）をクリック操作したとする。この操作は「httpリクエスト（リクエスト）」を発生させる。この操作によって、クライアント１１からビジネスロジック層２のブロック２１内のリクエストリスナー２３に対して「httpリクエスト」に係るデータが上記のインターネット１５を経由して送信される。リクエストリスナー２３は、「httpリクエスト」に係るデータを受け付けると、当該「httpリクエスト」から後述のhttpリクエストエンジンに基づき「画面ＩＤ」および「ボタン名」に係るデータを取り出し、ブロック２２のリクエスト処理部２６に送る。「画面ＩＤ」はＷｅｂブラウザ１１ａで表示された画面を特定する情報であり、「ボタン名」は当該画面における保存ボタン等を特定する情報である。リクエスト処理部２６は、受信した画面ＩＤとボタン名に係るデータ等に基づき後述の所定処理（処理ロジックの作成・実行）を行い、その「実行結果（＝リターンコード）」に係るデータをブロック２１の画面遷移決定処理部２４に送る。画面遷移決定処理部２４は、リクエスト処理部２６から送られた実行結果に係るデータに基づき「遷移先画面ＩＤ」に係るデータを生成し、ブロック２２のレスポンス処理部２７に送る。この「遷移先画面ＩＤ」は、この後、クライアント１１のＷｅｂブラウザ１１ａでの画面遷移を実行するための情報である。画面遷移の情報は、実行結果の内容（成功または失敗等）に基づいて決まる。レスポンス処理部２７は、「遷移先画面ＩＤ」に係るデータを受けとると、上記データベースサーバ１６から遷移先の画面に係る情報等を取得し、「クエリ結果」に係るデータをブロック２１のレンダリング処理部２５に送る。レンダリング処理部２５は、「クエリ結果」を受けてレンダリング処理を行い、クライアント１１のＷｅｂブラウザ１１ａで解釈可能なＨＴＭＬ情報を作成して、クライアント１１のＷｅｂブラウザ１１ａに対して送信する。

クライアント１１では、レンダリング処理部２５から送信されたＨＴＭＬ情報を受けて、担当者の次の操作を条件にしてＷｅｂブラウザ１１ａの画面を変化させる。

次に図３に従って上記リクエスト処理部２６によるリクエスト処理の内容を具体的に説明する。図３において、斜線で示したブロックはプログラムを意味し、その他のブロックはデータを意味している。また図３中の破線ブロックは上記のリクエスト処理部２６を示している。

クライアント１１のＷｅｂブラウザ１１ａから送信された「httpリクエスト」はリクエストリスナー２３によって受け付けられる。Ｗｅｂブラウザ１１ａの「httpリクエスト」には「画面ＩＤ」と「ボタン名」が含まれている。「画面ＩＤ」としては例えば「日報入力」であり、「ボタン名」としては例えば「保存」である。リクエストリスナー２３内のhttpリクエスト解釈エンジン３１によって、httpリクエストに係るデータ３２と、画面ＩＤに係るデータ３２とボタン名に係るデータ３３が取り出され、これらはリクエスト処理部２６に供給される。

リクエスト処理部２６は処理ロジック作成エンジン３４と処理ロジック実行エンジン３５を備えている。処理ロジック作成エンジン３４は、画面ＩＤに係るデータ３２とボタン名に係るデータ３３が与えられる。処理ロジック作成エンジン３４は、画面ＩＤに基づいてＡＤＸＭＬ（Application Definition XML：アプリケーション定義ＸＭＬ）３６を取得する。処理ロジック作成エンジン３４は「画面」および「ボタン名」に応じて「処理ロジック」を動的に作成するものである。処理ロジック作成エンジン３４によって作成された「処理ロジック」に係るデータ３７は処理ロジック実行エンジン３５に与えられる。

「処理ロジック」に係るデータ３７は、例えば、画面ＩＤが「日報入力」でありかつボタン名が「保存」である場合には、（１）日報テーブルに書き込む（Insert）こと、（２）管理者にメール送付すること、（３）受注トランザクション（受注トラン）に書き込む（Insert）こと、（４）顧客マスタを更新すること、である。

処理ロジック実行エンジン３５は、上記の「処理ロジック」に係るデータ３７と「httpリクエスト」に係るデータ３８とに基づいて、上記の処理ロジック（（１）〜（４））を実行する（ステップ３９）と共に、実行結果（リターンコード）４０を出力する。実行結果（リターンコード）４０としては、例えば「新規遷移」や「保存の成功／失敗」などである。

ここで図５を参照して上記の処理ロジック作成エンジン３４の動作手順を詳述する。破線で示したブロックが処理ロジック作成エンジン３４である。最初のステップＳ１１では、「画面ＩＤ」に基づいて取得したＡＤＸＭＬ３６からリストの読み込みを行う。読み込まれたリストにはプログラム名とパラメータが含まれている。次にリストの中の第１行を実行して１つのプログラムを読み込む（ステップＳ１２)。読み込まれるプログラムは、プログラム群４１として、別途に記録装置（アプリケーションサーバないしはデータベースサーバ１６等）に事前に予め用意されている。次にパラメータをセットする（ステップＳ１３）。次の判断ステップＳ１４では、リストが最終行であるか否かが判定され、最終行でないときにはステップＳ１１に戻り、上記のステップＳ１１〜Ｓ１４を繰り返す。判断ステップＳ１４で最終行であると判断されたときには成果物としての「処理ロジック」に係るデータ３７が出力される。最終的な成果物としての「処理ロジック」に係るデータ３７の内容はブロック４２内に示されている。ブロック４２内の「処理ロジック」の内容は前述した通りである。ブロック４２内の記載において、（１），（２），（３），（４）の内容４２ａは実行順序を示し、４２ｂはパラメータを示し、４２ｃはプログラムを示している。処理ロジック作成エンジン３４における上記の動作手順に基づいて「処理ロジック」（３７）が作成される。

図８に上記ＡＤＸＭＬ３６のサンプルを示す。ＡＤＸＭＬ３６において、部分３６Ａはボタンに関する記述部分であり、部分３６Ｂはページ処理に関する記述部分である。ＡＤＸＭＬ３６のボタンに関する記述部分３６Ａにおいて、記述部分３６ａはサーチボタンに関する部分であり、記述部分３６ｂは行追加ボタンに関する部分であり、記述部分３６ｃは保存ボタンに関する部分であり、記述部分３６ｄは削除ボタンに関する部分である。またページ処理に関する記述部分３６Ｂにおいて、記述部分３６ｅは新規ページ作成に関する部分であり、記述部分３６ｆは検索ページに関する部分であり、記述部分３６ｇはページ追加に関する部分である。その他に同様に顧客の要望する処理内容に応じて記述部分を設けることができる。

次に図６を参照して上記の処理ロジック実行エンジン３５の動作手順を説明する。破線で示したブロックが処理ロジック実行エンジン３５である。最初のステップＳ２１では、「処理ロジック」に係るデータ３７の読み込みを行う。次にＮ行目を実行する（ステップＳ２２）。実際には第１行目から実行される。Ｎ行目の実行が成功か否かが判定される（ステップＳ２３）。判断ステップＳ２３がＹＥＳであるときには次の判断ステップＳ２４に移行し、ＮＯであるときにはステップＳ２５に移行する。判断ステップＳ２４では最終行であるか否かが判断される。判断ステップＳ２４で、ＮＯであるときにはＮを１つ増して（ステップＳ２６）からステップＳ２１に戻り、ステップＳ２１〜Ｓ２４を繰り返し、ＹＥＳであるときにはステップＳ２５に移行する。ステップＳ２５ではリターンコードをセットし、このリターンコードすなわち実行結果４０を出力する。

次に図４に従って上記レスポンス処理部２７によるレスポンス処理の内容を具体的に説明する。図４において、斜線で示したブロックはプログラムを意味し、その他のブロックはデータを意味している。また図４中の破線ブロック５１はデータ抽出部を示している。

リクエスト処理部２６から提供された実行結果４０は画面遷移確定エンジン５２に与えられる。画面遷移確定エンジン５２は、遷移前画面ＩＤと実行結果（リターンコード）４０とによって次画面ＩＤを確定する。次画面ＩＤに係るデータ５３は、データ抽出ロジック作成エンジン５４に供給される。データ抽出ロジック作成エンジン５４は、「次画面のＡＤＸＭＬ」に係るデータ５５と実行結果４０とからデータ抽出ロジックに係るデータ５６を抽出する。「次画面のＡＤＸＭＬ」は顧客に応じて自由に作成することができる。データ抽出ロジックに係るデータ５６はデータ抽出ロジック実行エンジン５７に与えられる。データ抽出ロジック実行エンジン５７は、データベースサーバ１６およびデータベース１７と、遷移前画面リクエストデータ５８等からデータを抽出し、クエリ結果に係るデータ５９を作成する。このクエリ結果に係るデータ５９は、前述したレンダリング処理部２５に送られる。

上記の次画面ＩＤに係るデータ５３に関しては、別途に、画面のレイアウトの部分を定義する次画面のＸＳＬ６０をレンダリング処理部２５に送る。

上記のデータ抽出ロジック作成エンジン５４の内容を図７に示す。データ抽出ロジック作成エンジン５４は、次画面のＡＤＸＭＬ７１（上記のデータ５５に対応）からリスト（プログラム名）を読み込み（ステップＳ３１）、次に、プログラム群７２からリストに記載されるプログラムを読み込む（ステップＳ３２)という処理を行う。上記のごとく「ボタン名」が保存の場合には、リターンコード（実行結果）による戻り画面は元の画面となる。

図４において、レンダリング処理部２５では、レスポンス処理部２７から送られるクエリ結果に係るデータ５９に基づきＸＭＬトランスレータ６１が中間ＸＭＬ６２を作成する。次段のＸＳＬＴプロセッサ６３は、中間ＸＭＬ６２と次画面ＩＤに基づいて得られる次画面のＸＳＬ６０とに基づいてコンテンツ６４の部分のＨＴＭＬを作成すると共に、画面共通部分作成エンジン６５から提供される「ヘッダー」６６と「メニュー」６７と「フッター」６８の各部分と上記コンテンツ６４の部分を合成してＪＳＰ６９を作成して出力する。ＪＳＰ６９の構造は図４中に示される通りである。ＪＳＰ６９の構造において、コンテンツ６４の部分が、上記のごとくリクエスト処理部２６とレスポンス処理部２７を含む特定アプリケーション手段１４によって作られる部分である。こうして作られたＪＳＰ６９は、前述したように「ＨＴＭＬ」としてクライアント１１のＷｅｂブラウザ１１ａへ送信される。

上記の構成・処理動作において、例えば所定画面における保存ボタンに基づく上記（１）〜（４）の処理手順は、事前に用意されるＡＤＸＭＬ３６で顧客企業の業務システムに応じて任意に定義を行うことにより、顧客企業ごとの事情（業務要件等）に応じて任意に定めることができ、これによりカスタマイズを行うことができる。

図９Ａと図９Ｂに基づいて、クライアント１１におけるＷｅｂブラウザ１１ａでの画面での表示の一例が示される。この画面表示例では、営業日報に関する画面において、画面中に「行」を追加する例を示している。図９Ａは初期画面８１の表示例であり、図９Ｂは「行」が追加された後の画面８２の表示例である。

図９Ａで示した初期画面８１において、「行追加」のボタン８３をクリック操作すると、前述のごとく、「画面ＩＤ」と「ボタン名」とに基づいて、ビジネスロジック層２での特定アプリケーション手段１４のリクエスト処理部２６とレスポンス処理部２７等の処理機能に基づいて、行追加の処理が実行される。その結果、Ｗｅｂブラウザ１１ａの画面における初期画面８１は、図９Ｂに示される通り、複数の行による領域８４が追加された画面８２に変更される。

上記の初期画面８１では、その他に、「保存」のボタン８５、「削除」のボタン８６が設けられている。これらのボタンの操作に関しても前述と同様な処理が実行される。

次に、本発明に係るＷｅｂアプリケーションシステムと従来のシステムとを対比する。先に、図１３と図１４を参照して、従来型開発システムによる「既に実行可能な顧客情報参照画面に新しく電話番号欄を追加する」場合と「顧客マスタのデータに変更が加えられたら管理者にメールを送信する」場合とを説明した。従来開発型システムによれば、前者では画面確認とプログラム修正を行うことが必要であり、後者では実行確認とプログラム修正を行うことが必要であった。

上記に対して本発明に係るＷｅｂアプリケーションシステムを用いて「既に実行可能な顧客情報参照画面に新しく電話番号欄を追加する」ことを行うと、図１０に示す手順によって行うことができる。すなわち、ＡＤＸＭＬ３６のファイルにおいて電話番号にあたる領域について「表示形式」と「ＤＢ項目名」と「ＤＢ問い合わせ」を新たに定義し（ステップＳ４１）、次にＸＳＬファイルにおいて電話番号にあたる領域について「表示レイアウト」を新たに定義すればよい（ステップＳ４２）。従って本発明のシステムによれば、画面確認と設定変更だけで済み、プログラム修正を行う必要がないという利点を有する。さらにコンパイルを行う必要がないという利点を有する。

また本発明に係るＷｅｂアプリケーションシステムを用いて「顧客マスタのデータに変更が加えられたら管理者にメールを送信する」ことを行うと、図１１に示す手順によって行うことができる。すなわち、ＡＤＸＭＬファイルに「管理者にメールを送信する」部品を記述する（ステップＳ５１）。記述の行数は１行で済む。従って本発明のシステムによれば、実行確認を行うだけで済み、プログラム修正を行う必要がないという利点を有している。

以上の実施形態で説明された構成および配置関係については本発明が理解・実施できる程度に概略的に示したものにすぎない。従って本発明は、説明された実施形態に限定されるものではなく、特許請求の範囲に示される技術的思想の範囲を逸脱しない限り様々な形態に変更することができる。

本発明は、企業の営業業務システムの開発において画面要素の部品化を図り、顧客ごとに業務要件に応じて処理画面の表示内容および操作処理内容を個別に簡単に開発・設計。・修正するのに利用される。

本発明の代表的実施形態に係る業務用情報処理システムに適用される３層型システムのクライアント／サーバシステムの全体構成を示す構成図である。 本実施形態に係る業務用情報処理システムでのアプリケーション全体の処理概要を示すブロック構成図である。 本実施形態のビジネスロジック層内の特定アプリケーション手段でのリクエスト処理のプロセスを示すブロック図である。 本実施形態のビジネスロジック層内の特定アプリケーション手段でのレスポンス処理のプロセスを示すブロック図である。 本実施形態における処理ロジック作成エンジンの動作を示すフローチャートである。 本実施形態における処理ロジック実行エンジンの動作を示すフローチャートである。 本実施形態におけるデータ抽出ロジック作成エンジンの動作を示すフローチャートである。 本実施形態におけるＡＤＸＭＬの一例を示すコード図である。 本実施形態のクライアントにおけるＷｅｂブラウザでの画面での表示の一例であり、営業日報に関する初期画面の表示図である。 図９Ａに示された営業日報に関する初期画面で「行」が追加された後の画面の表示図である。 本発明に係る開発システムを用いて「既に実行可能な顧客情報参照画面に新しく電話番号欄を追加する」場合の処理プロセスを示すフローチャートである。 本発明に係る開発システムを用いて「顧客マスタのデータに変更が加えられたら管理者にメールを送信する」という変更を行う場合の処理プロセスを示すフローチャートである。 ３層型システムの構成を示すブロック構成図である。 従来の開発システムを用いて「既に実行可能な顧客情報参照画面に新しく電話番号欄を追加する」場合の処理プロセスを示すフローチャートである。 従来の開発システムを用いて「顧客マスタのデータに変更が加えられたら管理者にメールを送信する」という変更を行う場合の処理プロセスを示すフローチャートである。

符号の説明

１ プレゼンテーション層
２ ビジネスロジック層
３ データ層
４ サーバ
１１ クライアント
１１ａ Ｗｅｂブラウザ
１２ Ｗｅｂアプリケーションサーバ
１４ 特定アプリケーション手段
１５ インターネット
１６ データベースサーバ
２３ リクエストリスナー
２４ 画面遷移決定処理部
２５ レンダリング処理部
２６ リクエスト処理部
２７ レスポンス処理部
３２ 画面ＩＤ
３３ ボタン名
３４ 処理ロジック作成エンジン
３５ 処理ロジック実行エンジン
３６ ＡＤＸＭＬ
３７ 処理ロジック
４０ 実行結果

Claims (8)

1. 少なくとも２層型システムのクライアント／サーバシステムを用いて構築される業務用情報処理システムにおいて、
   前記クライアント／サーバシステムのアプリケーションサーバで、クライアントから送信されるリクエストのリクエスト内容を処理する処理機能部を２段階の処理手段により２層構造で形成したことを特徴とする業務用情報処理システム。
2. 前記クライアントは入出力部分としてのクライアントプログラムを備え、
   第１の前記処理手段は、前記クライアントの前記クライアントプログラムから送信される前記リクエストを処理するリクエスト処理手段と、前記クライアントの前記クライアントプログラムへ送信するためのレスポンスデータを用意するレスポンス処理手段とから成る、
   ことを特徴とする請求項１記載の業務用情報処理システム。
3. 第２の前記処理手段は、前記クライアントの前記クライアントプログラムから送信される前記リクエストを受付け、前記リクエスト処理手段に所定情報を送るリクエスト受付け手段と、前記リクエスト処理手段から送られる実行結果を受け、レスポンス処理識別情報を前記レスポンス処理手段に送るレスポンス処理決定手段と、前記レスポンス処理手段からの処理データを受け、前記クライアントの前記クライアントプログラムへ前記レスポンスデータを送信する送信手段とから成る、
   ことを特徴とする請求項２記載の業務用情報処理システム。
4. 前記リクエスト処理手段へ送られる前記リクエストに含まれる情報は、前記クライアントプログラムのリクエスト処理識別情報と当該画面上で操作されたリクエスト処理サブ識別情報であることを特徴とする請求項２または３記載の業務用情報処理システム。
5. 前記リクエスト処理手段は、前記リクエストから顧客ごとの業務要件に対応するリスト情報を読み込み、処理ロジックを作成する処理ロジック作成手段を有することを特徴とする請求項２または３記載の業務用情報処理システム。
6. 前記リスト情報はプログラム名とパラメータを含むことを特徴とする請求項５記載の業務用情報処理システム。
7. 前記処理ロジックは、前記業務要件で決まる実行手順と、この実行手順の各手順に対応するプログラムおよびパラメータとで構成されることを特徴とする請求項５記載の業務用情報処理システム。
8. 前記処理ロジック作成手段は、前記プログラム名に対応するプログラムを、予め用意されたプログラム群を格納する記憶装置から読み込むことを特徴とする請求項６記載の業務用情報処理システム。
   

Images