JP5174633B2 - サービス統合画面制御装置及びサービス統合画面制御プログラム及び記録媒体 - Google Patents

Description

本発明は、Ｗｅｂシステムのアプリケーション開発技術で特にインタフェース定義に関するものである。

Ｗｅｂシステムのクライアント画面では、複数のコンテキストが分割された領域に表示されて提供されることが多い。一画面上に複数の処理を実現できる反面、実現するためのアプリケーション開発は複雑になっている。これらのコンテキストは関連のない内容である場合もあり、コンテキストに対する処理をそれぞれに開発する負荷が高くなっている。

このような複数コンテキストを表示するＷｅｂシステムにおいて、この画面で操作している領域に表示されているコンテキストに対してメニューを制御する技術として特表２００７−５１０１８８号公報「コンテキスト・メニューの制御方法およびシステム」が公開されている。

特表２００７−５１０１８８号公報では、複数領域に分割されたＷｅｂページに対して、サーバから領域ごとのメニュー情報とメニュー呼び出し監視機能を前もってダウンロードし、それぞれの画面分割された領域においてメニュー呼び出しを検知するとコンテキスト毎のメニューを表示、実行を可能とする。
特表２００７−５１０１８８号公報

既存のＷｅｂシステムをラッピングしたサービスを統合したシステムを開発する場合、既存システムの複数画面にまたがる処理を統合するため、画面上の情報が多くなり操作の流れもわかりにくくなる。開発効率を向上するために既に開発されたシステムを流用した場合でも、統合システムの開発の負荷が大きいという課題がある。特許文献１に記載の技術では、複数領域において領域毎に対応したメニュー制御、機能呼び出し制御を行うことを目的としているが、領域に対する画面制御や領域間における連携処理やレイアウト制御について考慮がされていない。

この発明は、上記のような課題を解決することを主な目的の一つとし、複数領域間にまたがった業務の流れに伴う画面制御や、サーバの機能呼び出しをわかりやすく定義化することにより、プログラミングを行うことなく定型化した操作の定義を行った統合システムを提供することで、開発効率を向上させることを目的とする。

この発明のサービス統合画面制御装置は、
指示に従ってサービスを呼び出し、呼び出したサービスを実行して実行結果を出力するサービス制御機能部と、
既存システムを統合した統合システムを利用するクライアント端末装置のブラウザ画面におけるリクエストであって前記ブラウザ画面への操作を示すアクション情報と前記操作が行われた前記ブラウザ画面における操作フレームを示す操作フレーム情報とを含むリクエストを前記クライアント端末装置から受信し、前記操作フレームと、前記操作と、呼び出しの対象となる前記サービスと、呼びだされたサービスが実行された場合の前記実行結果を表示するフレームである結果フレームとの対応関係が複数定義されたサービス呼出定義を参照することにより、受信した前記操作フレーム情報と前記アクション情報とから呼び出すべき前記サービスと前記呼び出すべきサービスの実行結果を表示する前記結果フレームとを決定すると共に、決定した前記サービスの実行を前記サービス制御機能部に指示して実行させ、前記サービス制御機能部から前記実行結果を入力し、入力した前記実行結果と決定した前記結果フレームとを出力するリクエスト制御機能部と、
前記リクエスト制御機能部から前記実行結果と前記結果フレームとを入力し、前記クライアント端末装置の前記ブラウザ画面に前記結果フレームを表示する時の前記ブラウザ画面における前記結果フレームの少なくともフレーム位置とフレームサイズとを含むフレーム表示状態が定義されているフレーム定義を参照することにより、入力した前記結果フレームの前記フレーム表示状態を決定し、決定した前記フレーム表示状態と前記実行結果とから画面構成を示す画面構成情報を生成し、生成した画面構成情報を前記クライアント端末装置へ送信するレイアウト制御機能部と
を備えたことを特徴とする。

この発明により、プログラミングを行うことなく定型化した操作の定義を行った統合システムを提供することができる。

実施の形態１．
図１〜図５を参照して実施の形態１を説明する。図１は、既存システムをターゲットにした統合システムを実行する場合のサービス統合画面制御装置１００の構成図である。図１において、サービス統合画面制御装置１００は、ラッピングサーバ１１１に配置されている。

サービス統合画面制御装置１００は、レイアウト制御機能部１１２、リクエスト制御機能部１１４、サービス制御機能部１１６、及び格納部９０１を備える。実施の形態１〜３のサービス統合画面制御装置１００〜３００では、格納部９０１（プロセス状態定義格納部、プロセスフレーム定義格納部）は、後述するサービス呼出定義、フレーム定義、プロセス状態定義、プロセスフレーム定義を格納する。なお、格納部９０１は、サービス統合画面制御装置が備えても良いし、サービス統合画面制御装置の外部においてラッピングサーバ１１１が備えても構わない。

サービス統合画面制御装置１００は、クライアント端末装置１０１（以下クライアントという）にあるブラウザ１０２からリクエストがあると、既存システムＡ１２１、既存システムＢ１２２を操作するラッピングエンジン１１７上のサービスを実行し、結果を取得してブラウザ画面を生成して、ブラウザ１０２のリクエスト処理や画面表示処理を行うスクリプトをもつリクエスト要求機能部１０３とともにクライアントへ返す。

既存システムＡ１２１と既存システムＢ１２２とは、データ処理システムの例である。ラッピングエンジン１１７は、既存画面への入力値と操作方法とを指定して画面遷移後に結果を取得するサービス（例えばサービスＡ１１８、サービスＢ１１９）を、「サービス実行定義１２０」の情報を元に実行する。「サービス実行定義１２０」は、ラッピングエンジン１１７が実行するサービスの入出力の型定義を定義するＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）と、既存Ｗｅｂシステムへのアクセス手順を記述したスクリプト、ＨＴＭＬデータへの入力対象となる要素および出力の抽出対象となる要素を記述したパス指定から構成される。

ブラウザ１０２は、システムが統合された統合システムにおけるクライアント画面である。ブラウザ１０２は、例えばフレームＡ１０２ａ、フレームＢ１０２ｂ、フレームＣ１０２ｃで分割したり、あるいは、フレームＸ１０２ｇのように分割なく一画面にて機能を表示することもある。ブラウザ１０２は、それぞれのフレームで既存システムＡ１２１や既存システムＢ１２２の機能を呼び出す。また、リクエスト要求機能部１０３は、ブラウザ１０２で起こったイベントすべてをハンドリングしており、どのフレームでどの部品によりイベントが起きたかのアクション情報とともにリクエストを送信する。

サービス統合画面制御装置１００には、レイアウト制御機能部１１２、リクエスト制御機能部１１４、サービス制御機能部１１６が含まれる。

リクエスト制御機能部１１４は、クライアント１０１からのリクエストを受信すると、サービス呼出定義（Ａ−１）に従ってリクエストに対応したサービスを選択してサービス制御機能部１１６を用いて呼び出し、結果である画面情報をレイアウト制御機能部１１２で生成してクライアントへ返す機能である。

図２はサービス呼出定義（Ａ−１）を示す図である。サービス呼出定義（Ａ−１）にはブラウザ画面においてイベントが起きたフレーム２０１とアクション２０２との組合せで呼び出すサービス２０３と、サービス結果を出力するフレームである結果２０４を定義してある。リクエスト制御機能部１１４は、サービス実行後は、サービス結果とサービス呼出定義（Ａ−１）に定義されている結果を出力するフレーム（結果フレーム）と、そしてサービスの呼出し動作情報をレイアウト制御機能部１１２へ渡す。

サービス制御機能部１１６は、既存システムＡ１２１や既存システムＢ１２２を実行させるサービスそれぞれに対して、サービス実行定義１２０のサービスの入出力の型定義情報より作成され、入力値を取得して保持し、サービスを実行して出力値を保持する機能を持つ。

レイアウト制御機能部１１２は、リクエスト制御機能部１１４から取得したサービス結果である画面の情報を、フレーム定義（Ｂ−１）をもとにブラウザ１０２の画面の構成情報に基づいて組み込んで全体の画面構成を生成する。さらに、リクエスト制御機能部１１４から受け取った画面部品内のサービスの呼出し動作を定義した情報によりスクリプトを生成してリクエスト要求機能部１０３として、画面情報と一緒にクライアント１０１へ送信する機能である。

図３は、フレーム定義（Ｂ−１）を示す図である。フレーム定義（Ｂ−１）は、ブラウザ画面におけるフレーム位置やサイズ、およびサービス結果である画面情報がない場合の初期画面の情報を含むフレーム表示状態を定義している。

（動作）
次に、実施の形態１に係るサービス統合画面制御装置１００の動作を詳細に説明する。

図４は、実施の形態１に係る最適ブラウザエンジンを提供して既存システムのエミュレートを実行するサービス統合画面制御装置１００の動作を示すフローチャートである。また図５は図４をシーケンス化した図である。以下、サービス統合画面制御装置１００の動作を図４、図５を参照して説明する。

（ブラウザ１０２）
クライアント１０１の備える統合システムのブラウザ１０２は、必要な値が入力されボタンが押下げされると、リクエストを発行する（Ｓ４０１）。

（リクエスト要求機能部１０３）
リクエスト要求機能部１０３は、ブラウザ１０２におけるイベントをすべて取得し、どのフレームでどの画面部品でイベントを発生したかという「アクション情報」（例えばどのボタンが押下げされたか）、アクション（操作）が発生した「フレーム」（操作フレーム情報）と共に「リクエスト情報」をリクエスト制御機能部１１４へ送信する（Ｓ４０２）。「アクション情報」、「フレーム」、「リクエスト情報」をリクエストという場合がある。

（リクエスト制御機能部１１４）
リクエスト制御機能部１１４は、「リクエスト情報」と「フレーム」と「アクション情報」をリクエスト要求機能部１０３から取得して、サービス呼出定義（Ａ−１）を参照することにより「フレーム」と「アクション」に対応するサービスを決定して、サービス制御機能部１１６を呼び出す（Ｓ４０３）。

（サービス制御機能部１１６）
サービス制御機能部１１６は、ブラウザ１０２での入力値を設定し、リクエスト制御機能部１１４にて決定されたサービスを実行する。そして、実行結果を出力値として設定してリクエスト制御機能部１１４に出力する。（Ｓ４０４）。

（リクエスト制御機能部１１４）
リクエスト制御機能部１１４は、サービス制御機能部１１６から取得した「実行結果」を、サービス呼出定義（Ａ−１）に定義されている「結果フレーム」と一緒に、レイアウト制御機能部１１２へ渡す（Ｓ４０５）。

（Ｓ４０３のサービス実行処理の詳細）
ここで、Ｓ４０３で処理されるサービスの実行処理を図２のサービス呼出定義（Ａ−１）と図３のフレーム定義（Ｂ−１）を用いて説明する。

（設例１）
例えばブラウザ１０２のフレームＸ１０２ｇにてログイン画面を表示し、ボタンＸ１０２ｈを押下するとリクエスト制御機能部１１４へこの情報（アクション情報＝ボタン情報Ｘ（１０２ｈ）、フレーム＝フレームＸ（１０２ｇ））が送信される。そこで、リクエスト制御機能部１１４は、リクエスト要求機能部１０３から取得した情報が、「フレームがＸ」で、「アクションがボタンＸ」の組合わせであることから、図２のサービス呼出定義（Ａ−１）を参照することにより、「Ｌｏｇｉｎサービス」を呼び出す。これによりログイン処理が行われる。さらに、リクエスト制御機能部１１４は、その結果取得される画面がＡ１であることを取得する。

（設例２）
また、クライアントのフレームＡ１０２ａの画面にてユーザが値を入力し、ボタンＡ１０２ｄを押下した場合には、リクエスト要求機能部１０３からリクエスト制御機能部１１４には入力値と、フレームＡ１（フレーム）と、ボタンＡでアクション（アクション情報）が起きたことが送信される。そこで、リクエスト制御機能部１１４は、サービス呼出定義（Ａ−１）を参照することにより、フレームエリア２０１でフレームＡ１、アクションエリア２０２でボタンＡが定義されているので、サービスエリア２０３より呼び出すサービスが「ＳｅｒｖｉｃｅＡ」であることを取得する。また、「ＳｅｒｖｉｃｅＡ」を実行した結果、取得される画面情報を出力するのはフレームＢ（結果フレーム）であることがわかる。リクエスト制御機能部１１４により、これらの情報がレイアウト制御機能部１１２へ渡される（Ｓ４０５）。

（レイアウト制御機能部１１２）
レイアウト制御機能部１１２は、フレーム定義（Ｂ−１）に従って、ブラウザの画面構成を行う（Ｓ４０６）。例えば、フレームＸ（フレーム）でボタンＸが押下（アクション情報）された場合には、Ｓ４０５に示すように、レイアウト制御機能部１１２は、リクエスト制御機能部１１４から、実行結果と、フレームＡ１（結果フレーム）へサービスの結果を表示するべき情報を取得する。この場合は、レイアウト制御機能部１１２は、この情報を取得すると、図３のフレーム定義（Ｂ−１）を参照することによりフレームＡ１（結果フレーム）を特定し、フレームＡ１の位置エリア３０３（位置列）や幅エリア３０４、高さエリア３０５から表示情報を取得してそのフレームに実行結果を表示する画面構成を行う。また、フレーム２エリア（３０２）の情報から、フレームＡ１は、フレームＢ（１０２ｂ）とフレームＣ（１０２ｃ）から構成されることを取得する。フレームＢ（１０２ｂ）とフレームＣ（１０２ｃ）へは表示される情報が指定されていないため、初期画面エリア３０６の情報により、初期画面情報を表示する。サービスが指定されている場合には、サービス実行後の画面（実行結果）を表示する。

（レイアウト制御機能部１１２）
次に、レイアウト制御機能部１１２は、画面情報としてリクエスト制御機能部１１４によりサービス結果が設定されているかどうかを判断する（Ｄ４０１）。フレームに対してサービス結果の画面情報がリクエスト制御機能部１１４から渡されている場合には、その画面情報を設定する（Ｓ４０７）。渡されていない場合には、フレーム定義（Ｂ−１）において設定されている初期画面を画面情報として設定する（Ｓ４０８）。

（Ｓ４０６の画面構成の詳細）
ここで、Ｓ４０６でレイアウト制御機能部１１２により実行される、画面情報の設定を図２のサービス呼出定義（Ａ−１）、図３のフレーム定義（Ｂ−１）を用いて説明する。

図３のフレーム定義（Ｂ−１）におけるフレームエリア３０１にはフレームの名前が設定されており位置エリア３０３にフレームの表示する位置が示されている。左上のポイントが位置する場所を画面全体のおけるパーセンテージで示している。幅エリア３０４、高さエリア３０５では、それぞれフレームの幅と高さを画面全体のパーセンテージで示している。初期画面エリア３０６では、何も画面情報が指定されていない場合のデフォルト画面として表示する画面情報を設定する。

図２のサービス呼出定義（Ａ−１）により、フレームＡ１においてボタンＡが押下されＳｅｒｖｉｃｅＡが実行された場合には、レイアウト制御機能部１１２には、リクエスト制御機能部１１４からＳｅｒｖｉｃｅＡの画面情報とフレームＢという情報が渡され（Ｓ４０５）、レイアウト制御機能部１１２は、フレームＢにその画面情報を設定する（Ｓ４０６、Ｄ４０１のＹ、Ｓ４０７）。フレームＣに対して、何も渡されてない場合には初期画面エリア３０６のＧａｍｅｎＣ．ｊｓｐの画面情報が設定される。

レイアウト制御機能部１１２では、このように画面情報を生成しクライアント１０１へ送信し、ブラウザ１０２の画面を更新する。この時、前もって用意された画面表示や操作に必要なスクリプトを画面情報に加え、サービス呼出定義（Ａ−１）の画面部品内のサービスの呼出すアクション情報より、サービス呼出しのスクリプトを生成し、リクエスト要求機能も一緒にクライアントへダウンロードさせる（Ｓ４０９）。

以上、実施の形態１のように、既存システムをエミュレートするサービスを組み合わせた統合システムに対して、クライアント画面の画面分割情報と分割した領域とサービスとの連携を定義した情報とサービス統合画面制御装置により、画面構成やサービスを呼び出すプログラミングを行うことなく統合システムの画面を表示および実行できることが可能である。

実施の形態２．
図６〜図１２を参照して実施の形態２を説明する。

図６は、実施の形態２のサービス統合画面制御装置２００の構成例を示す。

（プロセス状態定義（Ｃ））
サービス統合画面制御装置２００は、実施の形態１のサービス統合画面制御装置１００に対して、さらに、プロセス状態定義（Ｃ）を備えた点が異なる。「プロセス状態定義（Ｃ）」とは、ターゲットとしている統合システムの業務プロセスを定義しており、現在のプロセス状態が記載される情報である。

図７は、プロセス状態定義（Ｃ）の一例を示す図である。プロセス状態定義（Ｃ）は、次のエリア（列）を有する。プロセスエリア６０１は統合システム上で処理する業務の流れを示すエリアでる。状態エリア６０２は現在の状態を示しており、まだ実行されていない場合「ｗａｉｔ」、実行中の場合は「ａｃｔｉｖｅ」、処理済みの場合は「ｄｏｎｅ」と記載される。後述のように、リクエスト制御機能部１１４が「ｗａｉｔ」、「ａｃｔｉｖｅ」、「ｄｏｎｅ」等の状態を更新する。業務グループエリア６０３は、指定されているプロセスの状態が「ａｃｔｉｖｅ」になったときに、実行を開始する業務を指定するエリアである。

図８は、実施の形態２におけるサービス呼出定義（Ａ−２）の一例を示す図である。サービス呼出定義（Ａ−２）は、プロセス状態を管理する場合に使用される。サービス呼出定義（Ａ−２）には、実施の形態１のサービス呼出定義（Ａ−１）に対し、さらに、業務グループエリア７０１、プロセスエリア７０２が追加されている。複数の業務がどのタイミングから変更になるかを業務グループエリア７０１で指定し、また、それぞれのサービス処理がどのプロセスに対応しているかをプロセスエリア７０２で指定している。

図９は、実施の形態２におけるフレーム定義（Ｂ−２）を示す。実施の形態１における図３のフレーム定義（Ｂ−１）に対して、フレーム定義（Ｂ−２）は、業務毎のフレーム定義ができるように、業務グループエリア８０１において業務グループの情報を指定し、それぞれに対してフレーム定義を指定している。

（動作）
次に動作について図１０〜図１２を参照しながら説明する。
ここで、
図１０はサービス統合画面制御装置２００の動作を示すフローチャートである。
図１１は、図１０をシーケンス化した図である。
図１２は、サービス統合画面制御装置２００の動作を示す別のフローチャートである。

クライアント１０１にある統合システムのブラウザ１０２は、必要な値が入力されボタンが押下されるとリクエストを発行し（Ｓ４０１）、リクエスト要求機能部１０３がリクエスト情報をリクエスト制御機能部１１４へ送信する（Ｓ４０２）。

（リクエスト制御機能部１１４）
リクエスト制御機能部１１４はリクエスト（リクエスト情報、フレーム、アクション情報）を受信すると、プロセス状態定義（Ｃ）より現在ａｃｔｉｖｅであるプロセスを取得する。初期状態でａｃｔｉｖｅなプロセスがない場合には一番最初のプロセスをａｃｔｉｖｅに変更し、そのプロセスと業務グループ情報を取得する（Ｓ９０１）。

次に、リクエスト制御機能部１１４は、サービス呼出定義（Ａ−２）を参照して呼び出すサービスを取得し、サービス制御機能部１１６を呼び出す（Ｓ４０３）。そして、サービス制御機能部１１６が指定されたサービスを実行し、サービス結果を出力値として設定する（Ｓ４０４）。また、リクエスト制御機能部１１４はサービス呼出定義（Ａ−２）を参照して、サービス実行後のプロセスを取得する（Ｓ９０２）。

次に、リクエスト制御機能部１１４は、取得したプロセスがＳ９０１で取得したプロセスに対して変更されているかどうかを確認する（Ｄ９０１）。変更されている場合には、プロセス状態定義（Ｃ）のプロセスの状態エリア６０２の値を更新する（Ｓ９０３）。終了したプロセスは「ｄｏｎｅ」とし、変更されたプロセスを「ａｃｔｉｖｅ」とする。終了したプロセスに対して、プロセス状態定義（Ｃ）の次の業務グループエリア６０３から値を取得する。そして、リクエスト制御機能部１１４は、サービス結果と結果フレーム、そしてプロセス情報と業務グループ情報をレイアウト制御機能部１１２へ送る。そして、画面更新処理を行う。

ここで、Ｓ９０１からＳ９０４までの動作を図７のプロセス状態定義（Ｃ）、図８のサービス呼出定義（Ａ−２）を参照して説明する。プロセス状態定義（Ｃ）より、現在「ａｃｔｉｖｅ」であるプロセスは「詳細１２」である。次にクライアント端末のフレームＤにてボタンＤが押下された場合に、サービス呼出定義（Ａ−２）より、呼び出すサービスはサービスエリア２０３より「ＳｅｒｖｉｃｅＤ」、結果エリア２０４より結果表示を行うのが「フレームＸ」、次のプロセスが「作業２１」となる（Ｓ９０２）。そして、このＳｅｒｖｉｃｅＤを実行し、結果をサービス制御機能部１１６で取得する。

プロセスが「詳細１２」から「作業２１」に変更されているため、リクエスト制御機能部１１４は、プロセス状態定義（Ｃ）において、「詳細１２」の状態エリア６０２の値を「ｄｏｎｅ」に更新すると共に、作業２１の状態エリア６０２の値を「ａｃｔｉｖｅ」に更新する（Ｓ９０３）。また、詳細１２の状態エリア６０２の値が「ｄｏｎｅ」に変更されたため、次の業務グループエリア６０３より指定されている値、「業務２」を取得する。そして、リクエスト制御機能部１１４は、サービス制御機能部１１６が取得したサービス結果と、結果を表示するフレームが「Ｘ」であること、またプロセスが「作業２１」で、次の業務グループが「業務２」であることをレイアウト制御機能部１１２へ送って画面更新処理を行う。

図１２は、レイアウト制御機能部１１２の動作（Ｄ１００１〜Ｓ１００１）を示すフローチャートである。図１２を参照して説明する。レイアウト制御機能部１１２では、業務グループが更新されているか確認を行う（Ｄ１００１）。更新されている場合には、フレーム定義（Ｂ−２）から、変更された業務グループに対応するフレーム情報を取得する（Ｓ１００１）。レイアウト制御機能部１１２は、Ｓ１００１で取得したフレーム定義情報に従って、画面を構成し（Ｓ４０６）、サービス結果を反映して画面情報を設定（Ｓ４０７、Ｓ４０８）、クライアント１０１へ送信する（Ｓ４０９）。

業務グループが業務１から業務２に更新された場合には、レイアウト制御機能部１１２では、フレーム定義（Ｂ−２）おいて業務グループが業務２に対応するフレーム情報を取得する。業務１の場合のフレーム情報が更新され業務２に対応したフレーム情報となる。フレームＸに結果を出力する場合に、フレーム３０１ｂにおいてフレームＸを選択し、その位置、サイズ、初期画面情報を取得してその画面情報に従ってサービス結果を表示する。

以上、実施の形態２のように、プロセス状態定義（Ｃ）をもたせ、業務におけるプロセス、および複数の業務に対する業務グループを管理することにより、複数の既存システムを組み合わせた統合システムに対してもプログラミングを行うことなく画面構成をそれぞれに対応した画面表示および実行が可能である。

実施の形態３．
図１３〜図１５を参照して実施の形態３を説明する。図１３は、実施の形態３のサービス統合画面制御装置３００の構成図である。サービス統合画面制御装置３００は実施の形態１のサービス統合画面制御装置１００に対して、統合システムにおいて業務のプロセス状態を「プロセスフレーム定義（Ｄ）」に基づいて表示するプロセス表示機能部１１０１が追加されている。さらに、プロセス表示機能部１１０１はプロセス状態定義（Ｃ）の情報も参照する。また、プロセス状態を表示した例として、業務グループ表示エリア１１０４とプロセス表示エリア１１０５を表示するフレームプロセス１１０３を統合システムのブラウザ１０２に表示している。

図１４は、プロセスフレーム定義（Ｄ）を示す図である。図１４のプロセスフレーム定義（Ｄ）は、プロセス状態を示すフレームの定義情報を業務グループごとに定義している。また、各プロセスフレームにおいて業務グループの情報を表示するイメージ情報とプロセス情報を表示するイメージ情報を、それぞれ業務表示エリア１２０６とプロセス表示エリア１２０７にて指定する。

図１５は、サービス統合画面制御装置３００の動作を示すフローチャートである。図１５を参照してサービス統合画面制御装置３００の動作を説明する。ここで図１５は、図１３のプロセス表示機能部１１０１により、プロセスフレーム定義（Ｄ）に基づいて統合システムにプロセス状態を表示するサービス統合画面制御装置３００のうちレイアウト制御機能部１１２の動作例を示すフローチャートである。

リクエスト制御機能部１１４からサービス結果情報と結果を表示するフレーム名、現在の業務グループ情報とプロセス情報を取得後、レイアウト制御機能部１１２は、業務グループが更新されているか確認を行い（Ｄ１００１）、更新されている場合には、フレーム定義（Ｂ−２）から業務グループに対応したフレーム情報を取得する（Ｓ１００１）。また、プロセス表示機能部１１０１がプロセスフレーム定義（Ｄ）から業務グループに対応したプロセスフレーム情報を取得する（Ｓ１３０１）。レイアウト制御機能部１１２は、プロセスフレーム定義（Ｄ）に従って統合システム画面を構成する。プロセスフレームは一部のエリアであるため、残りのエリアに対してはフレーム定義（Ｂ−２）に従って画面を構成する（Ｓ１３０２）。

ここで、Ｓ１３０１とＳ１３０２の動作を図１２を例に説明する。レイアウト制御機能部１１２より、業務グループが「業務２」に更新され、プロセス情報が「作業２１」、サービス結果と結果表示のフレームがＸである情報を取得した場合を例とする。プロセス表示機能部１１０１は、プロセスフレーム定義（Ｄ）より業務２に対応するプロセスフレームの位置・サイズ情報とともに業務表示エリア１２０６より業務情報を表示するイメージが「ＧｏｕｍｕＩｍａｇｅ」で、プロセス表示エリア１２０７よりプロセス情報を表示するイメージが「ＰｒｏｃｅｓｓＩｍａｇｅ」であることを取得する。次に、プロセスフレーム情報に従って、フレームＰをトップから高さ１０％のエリアに設定する。残り９０％のエリアに対しフレーム定義（Ｂ−２）の「業務２」とフレームＸのフレーム定義情報に従って、フレームを設定する。フレーム定義（Ｂ−２）ではフレームＸは、幅、高さとも１００％なので、残りのエリアすべてにフレームＸを構成する。

次に、プロセス表示機能部１１０１は、プロセスフレームに現在の業務グループ名と業務グループに対応するプロセス全ての情報と現在のプロセスを強調表示した画面情報をレイアウト制御機能部１１２へ送る（Ｓ１３０３）。業務情報表示エリア１１０４とプロセス情報表示エリア１１０５におけるイメージの表示方法はあらかじめプロセス表示機能部１１０１において用意されており、プロセスフレーム定義（Ｄ）より取得した業務情報とプロセス情報を表示するイメージを組み合わせて表示する。業務グループ情報は、リクエスト制御機能部１１４より取得した情報を表示する。プロセス情報はプロセス状態定義（Ｃ）より取得した業務グループに対応するプロセス名を表示する。そして、リクエスト制御機能部１１４より取得した現在のプロセス情報では強調表示を指定する。

以上、実施の形態３のように、現在のプロセス状態情報を表示するプロセス表示機能部をレイアウト制御機能部に組み込むことにより、統合システム画面にプロセス情報の表示を容易に組み込むことが可能となり、統合システム操作時にナビゲーション機能と現在の進捗確認機能を実現することが可能である。

実施の形態４．
実施の形態４は実施の形態１〜３のサービス総合画面制御装置を含むラッピングサーバ１１１のハードウェア構成の一例を説明する。

図１６は、コンピュータで実現されるラッピングサーバ１１１の外観の一例を示す図である。図１６において、ラッピングサーバ１１１は、システムユニット８３０、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶）の表示画面を有する表示装置８１３、キーボード８１４（Ｋｅｙ・Ｂｏａｒｄ：Ｋ／Ｂ）、マウス８１５、ＦＤＤ８１７（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・ Ｄｒｉｖｅ）、コンパクトディスク装置８１８（ＣＤＤ：Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｄｒｉｖｅ）、プリンタ装置８１９などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。

図１７は、コンピュータで実現されるラッピングサーバ１１１のハードウェア資源の一例を示す図である。図１７において、ラッピングサーバ１１１は、プログラムを実行するＣＰＵ８１０（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。ＣＰＵ８１０は、バス８２５を介してＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８１１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８１２、表示装置８１３、キーボード８１４、マウス８１５、通信ボード８１６、ＦＤＤ８１７、ＣＤＤ８１８、プリンタ装置８１９、磁気ディスク装置８２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置８２０の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。

ＲＡＭ８１２は、揮発性メモリの一例である。ＲＯＭ８１１、ＦＤＤ８１７、ＣＤＤ８１８、磁気ディスク装置８２０等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部、バッファの一例である。通信ボード８１６、キーボード８１４、ＦＤＤ８１７などは、入力部、入力装置の一例である。また、通信ボード８１６、表示装置８１３、プリンタ装置８１９などは、出力部、出力装置の一例である。

通信ボード８１６は、ネットワーク（ＬＡＮ等）に接続されている。通信ボード８１６は、ＬＡＮに限らず、インターネット、ＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。

磁気ディスク装置８２０には、オペレーティングシステム８２１（ＯＳ）、ウィンドウシステム８２２、プログラム群８２３、ファイル群８２４が記憶されている。プログラム群８２３のプログラムは、ＣＰＵ８１０、オペレーティングシステム８２１、ウィンドウシステム８２２により実行される。

上記プログラム群８２３には、以上に述べた実施の形態の説明において「〜部」として説明した機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ８１０により読み出され実行される。

ファイル群８２４には、以上に述べた実施の形態の説明において、「サービス呼出定義」、「フレーム定義」、「プロセス状態定義」、「プロセスフレーム定義」などとして説明した情報や、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明した情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ８１０によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。

また、以上に述べた実施の形態の説明においては、データや信号値は、ＲＡＭ８１２のメモリ、ＦＤＤ８１７のフレキシブルディスク、ＣＤＤ８１８のコンパクトディスク、磁気ディスク装置８２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｋ）等の記録媒体に記録される。また、データや信号は、バス８２５や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、以上に述べた実施の形態の説明において、「〜部」として説明したものは、「手段」、「〜回路」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明したものは、ＲＯＭ８１１に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ８１０により読み出され、ＣＰＵ８１０により実行される。すなわち、プログラムは、以上に述べた「〜部」としてコンピュータを機能させるものである。あるいは、以上に述べた「〜部」の手順や方法をコンピュータに実行させるものである。

以上の実施の形態１〜３では、サービス統合画面制御装置を説明したが、サービス統合画面制御装置の動作を、サービス統合画面制御装置１００が行うサービス統合画面制御方法として把握することも可能である。また、サービス統合画面制御方法をコンピュータに実行させるサービス統合画面制御プログラムとして把握することも可能である。また、
サービス統合画面制御プログラムを記録したコンピュータ読み取り可能な記録媒体として把握することも可能である。

以上の実施の形態では、既存のＷｅｂシステムの画面をラッピングしエミュレートできるサービスを組み合わせて統合したシステムを開発する際に、統合画面におけるレイアウトや画面遷移を定義情報として用意することによりプログラミングを行う必要がないサービス統合画面制御装置を説明した。

以上の実施の形態では、
既存システムを統合した統合システムを実行するクライアントのブラウザ画面におけるリクエストを、ラッピングサーバへリクエストを送信するリクエスト要求機能部と、
クライアントからのリクエストを取得し、サービス呼出定義情報に基づいて呼び出すサービスを決定してサービス制御機能部を実行し、その結果である画面情報をサービス呼出定義情報に定義されているクライアント画面のエリアに出力するリクエスト制御機能部と、
クライアントからの入力データを設定してサービスを呼び出し、出力データを出力するサービス制御機能部と、
リクエスト要求機能部からのリクエストにより、既存システムに対して、画面への入力データと操作および得られる出力データを定義したサービス実行定義情報をもとに既存システムを操作するサービスを実行するラッピングエンジンと、
クライアントのブラウザ画面の分割を定義したフレームの領域情報とサービスが呼び出されるフレームとサービス結果を出力するフレームとを定義したフレーム定義情報に基づいてブラウザ上のレイアウトを設定し、前記リクエスト制御機能部から実行結果を取得してブラウザ画面情報をクライアントへ送信するレイアウト制御機能部と、
を備えたサービス統合画面制御装置を説明した。

以上の実施の形態では、
前記リクエスト制御機能部は、更に、
統合システムにおける操作の流れをプロセスとして定義し、プロセスのどの状態にあるかを定義したプロセス状態定義情報に対して、クライアントからのリクエストに対してプロセスの状態を変更する機能部を有し、
前記サービス呼出定義情報にてサービス実行後に遷移するプロセスを定義しておき、この情報に従って、前記プロセス状態定義情報を更新後、レイアウト制御機能部へ実行結果とともにプロセス情報を送信する機能部を有し、
前記レイアウト制御機能部では、前記フレーム定義情報においてプロセス毎にレイアウトの初期化の定義があり、前記リクエスト制御機能部よりプロセス更新の情報を取得した場合には、レイアウト画面の初期化を行うサービス統合画面制御装置を説明した。

以上の実施の形態では、
前記レイアウト制御機能部は、更に、
プロセス状態表示をするプロセスフレームを作成するプロセス表示機能部を有し、前記リクエスト制御機能部より取得するプロセスの情報をもとにプロセスフレームにおいてプロセス全体の表示と現在のプロセスを強調表示するサービス統合画面制御装置を説明した。

実施の形態１におけるサービス統合画面制御装置１００の構成図。 実施の形態１におけるサービス呼出定義（Ａ−１）を示す図。 実施の形態１におけるフレーム定義（Ｂ−１）を示す図。 実施の形態１におけるサービス統合画面制御装置１００の動作を示すフローチャート。 実施の形態１におけるサービス統合画面制御装置１００の動作を示すシーケンス。 実施の形態２におけるサービス統合画面制御装置２００の構成図。 実施の形態２におけるプロセス状態定義（Ｃ）を示す図。 実施の形態２におけるサービス呼出定義（Ａ−２）を示す図。 実施の形態２におけるフレーム定義（Ｂ−２）を示す図。 実施の形態２におけるサービス統合画面制御装置２００の動作を示すフローチャート。 実施の形態２におけるサービス統合画面制御装置２００の動作を示すシーケンス。 実施の形態２におけるサービス統合画面制御装置２００の動作を示す別のフローチャート。 実施の形態３におけるサービス統合画面制御装置３００の構成図。 実施の形態３におけるプロセスフレーム定義（Ｄ）を示す図。 実施の形態３におけるレイアウト制御機能部１１２の動作のフローチャート。 実施の形態４におけるラッピングサーバ１１１の外観の一例。 実施の形態４におけるラッピングサーバ１１１のハードウェア構成の一例。

符号の説明

１００，２００，３００ サービス統合画面制御装置、１０１ クライアント、１０３ リクエスト要求機能部、１１１ ラッピングサーバ、１１２ レイアウト制御機能部、１１４ リクエスト制御機能部、１１６ サービス制御機能部、９０１ 格納部、１１０１ プロセス表示機能部。

Claims (5)

1. 指示に従ってサービスを呼び出し、呼び出したサービスを実行して実行結果を出力するサービス制御機能部と、
   既存システムを統合した統合システムを利用するクライアント端末装置のブラウザ画面におけるリクエストであって前記ブラウザ画面への操作を示すアクション情報と前記操作が行われた前記ブラウザ画面における操作フレームを示す操作フレーム情報とを含むリクエストを前記クライアント端末装置から受信し、前記操作フレームと、前記操作と、呼び出しの対象となる前記サービスと、呼びだされたサービスが実行された場合の前記実行結果を表示するフレームである結果フレームとの対応関係が複数定義されたサービス呼出定義を参照することにより、受信した前記操作フレーム情報と前記アクション情報とから呼び出すべき前記サービスと前記呼び出すべきサービスの実行結果を表示する前記結果フレームとを決定すると共に、決定した前記サービスの実行を前記サービス制御機能部に指示して実行させ、前記サービス制御機能部から前記実行結果を入力し、入力した前記実行結果と決定した前記結果フレームとを出力するリクエスト制御機能部と、
   前記リクエスト制御機能部から前記実行結果と前記結果フレームとを入力し、前記クライアント端末装置の前記ブラウザ画面に前記結果フレームを表示する時の前記ブラウザ画面における前記結果フレームの少なくともフレーム位置とフレームサイズとを含むフレーム表示状態が定義されているフレーム定義を参照することにより、入力した前記結果フレームの前記フレーム表示状態を決定し、決定した前記フレーム表示状態と前記実行結果とから画面構成を示す画面構成情報を生成し、生成した画面構成情報を前記クライアント端末装置へ送信するレイアウト制御機能部と
   を備えたことを特徴とするサービス統合画面制御装置。
2. サービス統合画面制御装置は、さらに、
   少なくとも一つのプロセスから構成される複数の業務と、前記プロセスのうち現在実行中のプロセスを示す実行中情報とを含むと共に、前記プロセスが実行終了となった場合に次に実行される業務が定義されたプロセス状態定義を格納するプロセス状態定義格納部を備え、
   前記サービス呼出定義は、
   前記サービス制御機能部による前記サービスの実行後に遷移するべき前記プロセスが定義されており、
   前記フレーム定義は、
   前記業務ごとに前記フレーム表示状態が定義されており、
   前記リクエスト制御機能部は、
   前記リクエストを受信すると前記プロセス状態定義格納部に格納されている前記プロセス状態定義を参照することにより現在実行中のプロセスを取得すると共に、前記サービス制御機能部に実行させた前記サービスの実行後に遷移するべき前記プロセスを前記サービス呼出定義を参照して特定し、特定した前記プロセスを現在実行中として取得した前記プロセスに代えて実行中として書き換える更新処理を前記プロセス状態定義に対して実施し、現在実行中として取得した前記プロセスの次に実行するべき前記業務を前記プロセス状態定義を参照することにより特定し、特定した前記業務を示す業務と、前記実行結果と、前記結果フレームとを前記レイアウト制御機能部に出力し、
   前記レイアウト制御機能部は、
   前記リクエスト制御機能部から出力された前記業務と、前記結果フレームと、前記実行結果とを入力し、前記フレーム定義を参照することにより、前記画面構成情報を生成することを特徴とする請求項１記載のサービス統合画面制御装置。
3. 前記サービス統合画面制御装置は、さらに、
   前記業務と前記プロセスとを表示する領域であるプロセスフレームが定義されたプロセスフレーム定義を格納するプロセスフレーム定義格納部を備え、
   前記リクエスト制御機能部は、
   さらに、実行中に書き換えた前記プロセスを前記レイアウト制御機能部に出力し、
   前記レイアウト制御機能部は、
   前記リクエスト制御機能部から出力された前記プロセスを入力すると共に、入力した前記プロセスと、前記レイアウト制御機能部から入力した前記業務と、前記プロセス状態定義と、前記プロセスフレーム定義とに基づいて、前記業務と前記プロセスとを表示する前記プロセスフレームの構成情報を生成し、生成した前記プロセスフレームの構成情報を前記クライアント端末装置に送信するプロセス表示機能部を備えたことを特徴とする請求項２記載のサービス統合画面制御装置。
4. コンピュータを
   指示に従ってサービスを呼び出し、呼び出したサービスを実行して実行結果を出力するサービス制御機能部、
   既存システムを統合した統合システムを利用するクライアント端末装置のブラウザ画面におけるリクエストであって前記ブラウザ画面への操作を示すアクション情報と前記操作が行われた前記ブラウザ画面における操作フレームを示す操作フレーム情報とを含むリクエストを前記クライアント端末装置から受信し、前記操作フレームと、前記操作と、呼び出しの対象となる前記サービスと、呼びだされたサービスが実行された場合の前記実行結果を表示するフレームである結果フレームとの対応関係が複数定義されたサービス呼出定義を参照することにより、受信した前記操作フレーム情報と前記アクション情報とから呼び出すべき前記サービスと前記呼び出すべきサービスの実行結果を表示する前記結果フレームとを決定すると共に、決定した前記サービスの実行を前記サービス制御機能部に指示して実行させ、前記サービス制御機能部から前記実行結果を入力し、入力した前記実行結果と決定した前記結果フレームとを出力するリクエスト制御機能部、
   前記リクエスト制御機能部から前記実行結果と前記結果フレームとを入力し、前記クライアント端末装置の前記ブラウザ画面に前記結果フレームを表示する時の前記ブラウザ画面における前記結果フレームの少なくともフレーム位置とフレームサイズとを含むフレーム表示状態が定義されているフレーム定義を参照することにより、入力した前記結果フレームの前記フレーム表示状態を決定し、決定した前記フレーム表示状態と前記実行結果とから画面構成を示す画面構成情報を生成し、生成した画面構成情報を前記クライアント端末装置へ送信するレイアウト制御機能部、
   として機能させるためのサービス統合画面制御プログラム。
5. 請求項４記載のサービス統合画面制御プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images