JP5638761B2 - 画面生成方法、画面表示方法、画面生成装置、及びプログラム - Google Patents

Description

本発明は、画面生成方法、画面表示方法、画面生成装置、及びプログラムに関する。

従来、ＡＳＰ（Application Service Provider）等において提供されるＷｅｂアプリケーションについては、利用者に応じたニーズに対応するため、Ｗｅｂサーバ側において、一つのアプリケーションを利用者ごとにカスタマイズし、それぞれを別個に管理及び動作させる必要があった。なお、ここでいう利用者とは、企業、団体、官公庁等、ＡＳＰの提供者とサービスの利用契約を結んでいる組織をいう。

一方、昨今注目されているＳａａＳ（Software as a Service）と呼ばれるシステム形態では、同一のＷｅｂアプリケーションを同一のサーバ上で動かし、複数の利用者に同一のＷｅｂアプリケーションを利用させることで、運用コストの削減を図っている。
特開２００２−１６３３８２号公報

しかしながら、利用者によっては、Ｗｅｂアプリケーションの標準仕様として提供されている画面ではなく、利用者ごとに固有にカスタマイズされた画面を利用したいという要望がある。

但し、一般的に、Ｗｅｂアプリケーションは画面遷移を伴うため、一つのサービスにおいて複数の画面が利用されうる。複数の画面を構築するためのデータを単純に利用者ごとに管理したのでは管理するデータ量が増加し、ＳａａＳによるメリットが減殺されてしまうという問題がある。

本発明は、上記の点に鑑みてなされたものであって、利用者に応じてカスタマイズされた画面の提供を効率的に行うことのできる画面生成方法、画面表示方法、画面生成装置、及びプログラムの提供を目的とする。

そこで上記課題を解決するため、本実施の形態の画面生成方法は、複数の端末装置に対して提供する画面の画面データを生成するコンピュータが、前記複数の端末装置に含まれるある端末装置からの操作入力に基づく複数の画面遷移それぞれにおいて、遷移先となる遷移先画面を定義する定義情報が前記ある端末装置の属するテナントに対応付けて記憶手段に記憶されているか否かを判定し、前記ある端末装置の属するテナントに個別に対応付けて記憶された定義情報が記憶されていないときは、前記記憶手段に記憶された、前記ある端末装置の属するテナントに対応付けて記憶された定義情報と異なる定義情報であって、前記記憶手段に遷移先画面の定義情報が対応付けて記憶されていない前記複数の端末装置で共用される定義情報に基づいて遷移先画面の画面データを生成し、前記記憶手段に前記ある端末装置の属するテナントに対応付けて記憶された定義情報が記憶されているときは、前記ある端末装置の属するテナントに対応付けて記憶された定義情報に基づいて遷移先画面の画面データを生成する。

このような画面生成方法では、利用者に応じてカスタマイズされた画面の提供を効率的に行うことができる。

利用者に応じてカスタマイズされた画面の提供を効率的に行うことができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。同図において、クライアント装置３０ａ、３０ｂ、及び３０ｃとＷｅｂサーバ１０とはインターネット等のネットワークを介して接続されている。

Ｗｅｂサーバ１０は、画面生成方法を実行するコンピュータ（画面生成装置）の具体例である。Ｗｅｂサーバ１０は、画面遷移を伴うサービスをネットワークを介して提供する。具体的には、Ｗｅｂサーバ１０は、インターネットを介してアプリケーションソフトウェア（以下、説明の便宜上単に「アプリケーション」という。）の機能によるサービスをテナント（後述する）に提供する。Ｗｅｂサーバ１０によるサービスの提供形態としては、ＳａａＳ（Software as a Service）が一例として挙げられる。なお、Ｗｅｂサーバ１０は、サービスの提供者によって管理されている。

クライアント装置３０ａ、３０ｂ、及び３０ｃ等（以下、総称する場合「クライアント装置３０」という。）は、サービス利用者側に属するコンピュータである。クライアント装置３０ａ、クライアント装置３０ｂ、クライアント装置３０ｃは、それぞれテナントＡ、テナントＢ、テナントＣに属する。本実施の形態においてテナントとは、サービス提供者との間でサービスの利用契約を結んだ企業又は団体等の組織をいう。したがって、テナントは一人以上のユーザの集合であるといえる。

Ｗｅｂサーバ１０は、ＨＴＴＰ（HyperText Transfer Protocol）サーバ１１、アプリケーションサーバ１２、拡張タグ処理部１３、業務アプリケーション１４、テナント判定部１５、及び画面定義データ１７等のソフトウェアを有する。

ＨＴＴＰサーバ１１は、クライアント装置３０との通信を制御する。例えば、ＨＴＴＰサーバ１１は、クライアント装置３０からの要求（ＨＴＴＰリクエスト）を受信し、当該要求に対する応答（ＨＴＴＰレスポンス）を返信する。

アプリケーションサーバ１２は、クライアント装置３０からの要求に応じた（ＵＲＬ（Uniform Resource Locator）に対応した）業務アプリケーション１４を起動させる（呼び出す）。アプリケーションサーバ１２は、また、業務アプリケーション１４による処理結果に応じ、クライアント装置３０へ返信するための画面データ（ＨＴＭＬデータ）を生成する。画面データは、画面定義データ１７を利用して生成される。本実施の形態では、画面定義データ１７としてＪＳＰ（Java（登録商標） Server Pages）データを適用した例を説明する。したがって、アプリケーションサーバ１２は、ＪＳＰの実行環境であるＪＳＰコンテナを含む。

拡張タグ処理部１３は、画面定義データ１７に記述されている拡張タグに対応した処理を実行する。すなわち、画面定義データ１７は、本実施の形態において独自に定義された拡張タグを含む。

業務アプリケーション１４は、いわゆるＷｅｂアプリケーションであり、機能に応じて複数存在する。本実施の形態において、各業務アプリケーション１４は、複数のテナントより共通的に利用される。

テナント判定部１５は、ＨＴＴＰサーバ１１によって受信されるＨＴＴＰリクエストに含まれている情報に基づいて当該ＨＴＴＰリクエストの送信元のクライアント装置３０（ユーザ）が属するテナントを判定する。テナント判定部１５は、判定結果のテナントの識別情報（以下、「テナントＩＤ」という。）をセッションスコープ１８に記録（登録）する。「セッションスコープ」とは、クライアント装置３０とＷｅｂサーバ１０とのセッション（又はセッション情報）を管理するためにメモリ装置１０３内に生成されるデータをいい、例えば、一般的にセッションオブジェクトと呼ばれる。テナントＩＤは、テナントごとに一意となるように割り当てられている。セッションスコープ１８に記録されたテナントＩＤは、アプリケーションサーバ１２が拡張タグ処理部１３を利用してテナントごとにカスタマイズされた画面データを生成する際に参照される。なお、本実施の形態では、クライアント装置３０とテナントＩＤとを関連付けて保持するための識別子記憶手段としてセッションスコープ１８を用いる。但し、クライアント装置３０との関連付けをセッションが接続されている間維持することが可能であれば、他のデータ（記憶領域）を識別子記憶手段として用いてもよい。また、セッションＩＤと同様にテナントＩＤをクッキー情報とし、ＨＴＴＰリクエストのたびにクライアント装置３０より送信されるようにしてもよい。

図２は、本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。図２のＷｅｂサーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有する。

Ｗｅｂサーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ（例えば、画面定義データ１７）等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２から読み出されたプログラムが格納される。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってＷｅｂサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

以下、Ｗｅｂサーバ１０の処理手順について説明する。図３は、Ｗｅｂサーバによる処理手順を説明するためのフローチャートである。

ＨＴＴＰサーバ１１によるクライアント装置３０ａからのＨＴＴＰリクエストの受信に応じ（Ｓ１０１）、テナント判定部１５は、クライアント装置３０ａとのセッションに対応するセッションスコープ１８にテナントＩＤが登録されているか否かを判定する（Ｓ１０２）。

なお、各セッションはセッションＩＤによって識別される。セッションＩＤは、セッションの開設時にアプリケーションサーバ１２によって割り当てられ、クライアント装置３０ａに送信される。クライアント装置３０ａは、セッションＩＤをＣｏｏｋｉｅ（クッキー）等に保持しておき、ＨＴＴＰリクエストの度にＷｅｂサーバ１０に対して送信する。また、セッションスコープ１８は、セッションの開設時にセッションＩＤと共にアプリケーションサーバ１２によって生成され、セッションＩＤに関連付けられて管理されている。したがって、テナント判定部１５は、セッションＩＤに基づいて現在のセッションに対応するセッションスコープ１８を取得することができる。

ところで、本実施の形態においてセッションスコープ１８にテナントＩＤが登録されていないという状態は、受信されたＨＴＴＰリクエストがログイン要求である場合に相当する。ログイン要求には、クライアント装置１０のＷｅｂブラウザに表示されているログイン画面に対して入力されたユーザＩＤ（各ユーザを識別するＩＤ）及びパスワードが含まれている。そこで、この場合（Ｓ１０２でＮｏ）、テナント判定部１５は、テナントＩＤ管理テーブルに基づいて、ＨＴＴＰリクエスト（ログイン要求）に含まれているユーザＩＤに対応するテナントＩＤを判定する（Ｓ１０３）。

図４は、テナントＩＤ管理テーブルの構成例を示す図である。同図に示されるように、テナントＩＤ管理テーブル１６には、ユーザＩＤとテナントＩＤとの対応情報が登録されている。例えば、ログイン要求に含まれているユーザＩＤが「ｕｓｅｒ０１」であった場合、テナント判定部１５は、対応するテナントＩＤは「ＡＡＡ」であると判定する。

続いて、テナント判定部１５は、判定結果としてのテナントＩＤをセッションスコープ１８に登録する（Ｓ１０４）。

なお、テナントにおける各ユーザがテナントＩＤを知っているという前提であれば、ログイン時等にテナントＩＤをユーザに入力させるようにしてもよい。この場合、クライアント装置３０からのＨＴＴＰリクエストにはテナントＩＤが含まれている。したがって、ＨＴＴＰリクエストに含まれているテナントＩＤをそのままセッションスコープ１８に登録すればよい。

但し、本実施の形態のように、Ｗｅｂサーバ１０においてユーザＩＤに基づいてテナントＩＤを自動的に判定することにより、テナントの各ユーザにテナントＩＤを周知させる必要をなくすことができる。また、各ユーザは、テナントＩＤを記憶したり、ログイン時にテナントＩＤを入力したりする必要はない。したがって、ユーザの作業負担を軽減することができる。

一方、セッションスコープにテナントＩＤが既に登録されている場合（すなわち、ＨＴＴＰリクエストがログイン要求以外の業務ロジックの実行要求の場合）（Ｓ１０２でＹｅｓ）、ステップＳ１０３及びＳ１０４の処理は行われない。

続いて、アプリケーションサーバ１２は、ＨＴＴＰリクエストの内容（例えば、ＨＴＴＰリクエストに含まれるＵＲＬ等）に応じた業務アプリケーション１４を判定し、当該業務アプリケーション１４を呼び出す（又は起動する）（Ｓ１０５）。ＨＴＴＰリクエストの内容に応じた業務アプリケーション１４の判定は、例えば、補助記憶装置１０２に記録されている、ＵＲＬと業務アプリケーション１４との対応情報等に基づいて行えばよい。

続いて、呼び出された業務アプリケーション１４は、自らに実装されている業務ロジックを実行する（Ｓ１０６）。業務ロジックの実行が完了すると、業務アプリケーション１４は、実行結果に応じた画面データの生成をアプリケーションサーバ１２に要求する。画面データの生成の要求の際、業務アプリケーション１４は、画面データの生成に利用するＪＳＰファイルのファイル名をアプリケーションサーバ１２に指定する。

続いて、アプリケーションサーバ１２は、業務アプリケーション１４に指定されたＪＳＰファイルに基づいて画面データ（ＨＴＭＬデータ）を生成する（Ｓ１０７）。アプリケーションサーバ１２は、生成された画面データをＨＴＴＰサーバ１１に出力する。続いて、ＨＴＴＰサーバ１１は、業務アプリケーション１４によって生成された画面データをＨＴＴＰレスポンスに含めてクライアント装置３０ａに送信する（Ｓ１０８）。

図３の処理が繰り返し実行することにより、Ｗｅｂサーバ１０がクライアント装置３０ａに提供する画面（すなわち、クライアント装置３０ａにおいて表示される画面）は、例えば、図５に示されるように遷移する。

図５は、本実施の形態における画面遷移の例を示す図である。同図には、画面Ａ、画面Ｂ、及び画面Ｃの順で画面が遷移することが示されている。すなわち、図３の処理が一回行われることにより、クライアント装置３０ａには画面Ａが表示される。画面Ａにおいて操作指示が入力されると、当該操作指示に応じて再度図３の処理が実行される。その結果、クライアント装置３０ａには画面Ｂが表示される。画面Ｂにおいて操作指示が入力されると、当該操作指示に応じて再度図３の処理が実行される。その結果、クライアント装置３０ａには画面Ｃが表示される。

なお、図３及び図５においては、クライアント装置３０ａを例として説明したが、クライアント装置３０ｂ及び３０ｃにおいても同様の処理手順及び画面遷移が実行される。但し、本実施の形態では、画面Ａ、画面Ｂ、及び画面Ｃのうちの少なくとも一部の画面をテナントごとにカスタマイズしたものを表示させることができる。テナントごとに固有の画面の表示を可能とするため、本実施の形態における画面定義データ１７は、図６に示されるような構成を有する。

図６は、本実施の形態における画面定義データの構成例を示す図である。本実施の形態において、画面定義データ１７は、ＪＳＰファイルの集合である。各ＪＳＰファイルは、その機能、役割、又は位置付けに応じたフォルダに分類されて保存されている。同図では、ルートフォルダ１７１、標準フォルダ１７２、テナントＡ用フォルダ１７３、テナントＢ用フォルダ１７４がＪＳＰファイルの格納用のフォルダとして示されている。

ルートフォルダ１７１は、画面定義データ１７の格納用のフォルダのルート（最上位）のフォルダである。ルートフォルダ１７１は、インクルードファイルとして機能するＪＳＰファイルを格納する。本実施の形態においてインクルードファイルとは、拡張タグ処理部１３を呼び出すための定義（拡張タグ）が記述されたＪＳＰファイルをいう。拡張タグ処理部１３は、セッションスコープ１８に記録されているテナントＩＤに応じ、画面データの生成に用いる画面定義ファイルを標準フォルダ１７２又は各テナント用のフォルダ（テナントＡ用フォルダ１７３若しくはテナントＢ用フォルダ１７４）のいずれかより選択する。したがって、インクルードファイルは、テナントＩＤに応じて使用する画面定義ファイルを選択するための定義がなされたＪＳＰファイルであると解釈することもできる。図中において、各インクルードファイルから各画面定義ファイルへの矢印は、斯かる選択関係を表現したものである。

インクルードファイルは、画面遷移における一連の画面ごとに生成される。したがって、同図では、画面Ａに対応するインクルードファイル１７１ａ、画面Ｂに対応するインクルードファイル１７１ｂ、画面Ｃに対応するインクルードファイル１７１ｃが示されている。なお、同図において、ルートフォルダのパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ」とされている。また、各インクルードファイルのファイル名は、ａ．ｊｓｐ、ｂ．ｊｓｐ、ｃ．ｊｓｐとされている。

図７は、インクルードファイルの定義例を示す図である。同図では、インクルードファイル１７１ａの定義例が示されているが、インクルードファイル１７１ｂ及び１７１ｃの定義内容も同様でよい。

同図において、ｓａａｓ：ｉｎｃｌｕｄｅタグ１７１２は、本実施の形態における拡張タグの具体例である。すなわち、ｓａａｓ：ｉｎｃｌｕｄｅタグ１７１２は、拡張タグ処理部１３を呼び出すための定義に相当する。

記述１７１１は、ＪＳＰ標準の定義であり、ｓａａｓ：ｉｎｃｌｕｄｅタグ１７１２の処理を可能とするための定義がされている箇所を示す。すなわち、記述１７１１に含まれているＵＲＬ「http://fx-saas.net/r3/tags-html」によって識別されるファイル内に、ｓａａｓ：ｉｎｃｌｕｄｅタグと拡張タグ処理部１３との対応情報が含まれている。本実施の形態において、拡張タグ処理部１３は、Ｊａｖａ（登録商標）のクラスとして実装されている。したがって、当該対応情報のより具体的な内容は、ｓａａｓ：ｉｎｃｌｕｄｅタグと拡張タグ処理部１３のクラス名との対応付けの定義である。

図６に戻る。標準フォルダ１７２は、Ｗｅｂサーバ１０が標準で（デフォルトで）提供する画面を生成するための定義情報（画面定義データ）を格納したＪＳＰファイル（画面定義ファイル）を格納するフォルダである。標準フォルダ１７２には、画面遷移に係る一連の画面ごとに標準の画面定義ファイルが保存されている。同図では、画面Ａに対応する画面定義ファイル１７２ａ、画面Ｂに対応する画面定義ファイル１７２ｂ、画面Ｃに対応する画面定義ファイル１７２ｃが示されている。なお、本実施の形態において、標準フォルダ１７２は、ルートフォルダ１７１の直下に「ｃｏｍｍｏｎ」というフォルダ名で作成されている。したがって、標準フォルダのパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ｃｏｍｍｏｎ」となる。また、標準フォルダ１７２における各画面定義ファイルのファイル名は、ａ．ｊｓｐ、ｂ．ｊｓｐ、ｃ．ｊｓｐとされている。すなわち、本実施の形態では、各画面定義ファイルのファイル名は、対応するインクルードファイルのファイル名と一致する。具体的には、画面定義ファイル１７２ａのファイル名は「ａ．ｊｓｐ」である。画面定義ファイル１７２ｂのファイル名は「ｂ．ｊｓｐ」である。画面定義ファイル１７２ｃのファイル名は「ｃ．ｊｓｐ」である。

テナントＡ用フォルダ１７３及びテナントＢ用フォルダ１７４は、それぞれ、テナントＡ用又はテナントＢ用に固有にカスタマイズされた画面定義ファイルを格納するフォルダである。但し、各テナント用フォルダには、必ずしも全ての画面に対する画面定義ファイルは格納されておらず、カスタマイズが必要な画面に対する画面定義ファイルのみが格納されている。例えば、テナントＡ用フォルダ１７３には、画面Ａ用の画面定義ファイル１７３ａと画面Ｃ用の画面定義ファイル１７３ｃとが格納されている。また、テナントＢ用フォルダ１７４には、画面Ｂ用の画面定義ファイル１７４ｂのみが格納されている。

なお、本実施の形態においてテナントＡ用フォルダ１７３、テナントＢ用フォルダ１７４は、それぞれルートフォルダの直下に各テナントのテナントＩＤをフォルダ名として作成されている。したがって、テナントＡ用フォルダ１７３のパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ＡＡＡ」となる。また、テナントＢ用フォルダ１７４のパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ＢＢＢ」となる。また、各テナント用フォルダに格納されている画面定義ファイルのファイル名は、対応するインクルードファイルのファイル名と一致する。具体的には、画面定義ファイル１７３ａのファイル名は「ａ．ｊｓｐ」である。画面定義ファイル１７３ｃのファイル名は「ｃ．ｊｓｐ」である。画面定義ファイル１７４ｂのファイル名は「ｂ．ｊｓｐ」である。

図８は、画面定義ファイルの定義例を示す図である。同図において、左側は標準の画面定義ファイル１７１ａの定義例である。右側はテナントＡ用の画面定義ファイル１７２ａである。具体的な定義内容については、標準のＪＳＰの仕様に基づくためここでの説明は省略する。ここでは、二つの画面定義ファイルの相違点（図中破線で囲まれた記述１７１５と記述１７２５）に注目する。記述１７１５では、「計測項目検索・一覧画面」という文字列が＜ｈ２＞タグによって囲まれている。一方、記述１７２５では、同一の文字列が＜ｈ１＞タグによって囲まれている。すなわち、テナントＡ用の画面Ａでは、「計測項目検索・一覧画面」という文字列のサイズが変更されている。

ところで、上記では、標準フォルダのフォルダ名は「ｃｏｍｍｏｎ」であり、各画面定義ファイルのファイル名は、対応するインクルードファイルのファイル名と一致するといったように、それぞれ固定的に定められている。標準フォルダのフォルダ名や画面定義ファイルのファイル名に柔軟性を持たせるため、インクルードファイルを図９のように定義してもよい。

図９は、インクルードファイルの第二の定義例を示す図である。図９中、図７と対応する部分には同一符号を付し、その説明は適宜省略する。

同図において、ｓａａｓ：ｉｎｃｌｕｄｅタグは、ｄｅｆａｕｌｔＪｓｐ属性１７１３及びｊｓｐ属性１７１４を含む。ｄｅｆａｕｌｔＪｓｐ属性１７１３の値は、標準フォルダ１７２のフォルダ名（すなわち、標準フォルダ１７２の識別情報）を示す。ｊｓｐ属性１７１４の値は、当該インクルードファイルに対応する画面定義ファイルのファイル名（すなわち、画面定義ファイルの識別情報）を示す。したがって、図９の定義例によれば、画面Ａの標準の画面定義ファイルのパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ｄｅｆａｕｌｔ／ａａａａａａ．ｊｓｐ」とされる。また、画面ＡのテナントＡ用の画面定義ファイルのパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ＡＡＡ／ａａａａａａ．ｊｓｐ」とされる。

標準フォルダ１７２のフォルダ名や画面定義ファイルのファイル名を変更可能とすることで、標準フォルダ１７２のフォルダ構成や画面定義ファイルのファイル構成に柔軟性を持たせることが可能となる。なお、ｄｅｆａｕｌｔＪｓｐ属性及びｊｓｐ属性は、インクルードファイルごと、すなわち、画面ごとに定義されうる。したがって、画面ごとに標準フォルダ１７１のパス名を変更したり、画面定義ファイルのファイル名を変更したりすることができる。

画面定義データ１７に関して、図５〜図９において説明したことを前提とし、図３のステップＳ１０７の詳細について説明する。図１０は、画面データ生成処理の処理手順を説明するためのフローチャートである。

ステップＳ２０１において、アプリケーションサーバ１２は、業務アプリケーション１４より指定されたＪＳＰファイルを取得し、当該ＪＳＰファイルを実行する。ここで、実行対象とされるＪＳＰファイルはインクルードファイルに相当する。例えば、遷移先の画面が画面Ａである場合、業務アプリケーション１４からは画面Ａのファイル名（ａ．ｊｓｐ）が指定される。アプリケーションサーバ１２は、ルートフォルダ１７１内より当該ファイル名に係るＪＳＰファイル（すなわち、インクルードファイル）を取得し、実行する。

アプリケーションサーバ１２は、インクルードファイルを１行ずつ実行していく過程において、ｓａａｓ：ｉｎｃｌｕｄｅタグを検出すると（Ｓ２０２でＹｅｓ）、拡張タグ処理部１３を呼び出す。ｓａａｓ：ｉｎｃｌｕｄｅタグの検出に応じて拡張タグ処理部１３を呼び出すことは、例えば図７の記述１７１１に基づいて判定される。

拡張タグ処理部１３は、呼び出しに応じ、自らに実装された処理を実行する（Ｓ２０３）。拡張タグ処理部１３による処理が完了すると、画面データ生成処理は完了する。

続いて、図１０のステップＳ２０３の詳細について説明する。図１１は、拡張タグ処理部による処理手順を説明するためのフローチャートである。

ステップＳ３０１において、拡張タグ処理部１３は、処理対象となっているセッションのセッションスコープ１８よりテナントＩＤを取得する。ここで、アプリケーションサーバ１２、テナント判定部１５、及び拡張タグ処理部１３は同一スレッド内において動作する。したがって、拡張タグ処理部１３は、アプリケーションサーバ１２において当該スレッド空間内に生成され、テナント判定部１５によってテナントＩＤが記録されたセッションスコープ１８を参照すればよい。

続いて、拡張タグ処理部１３は、取得されたテナントＩＤを使用して、テナント用フォルダのパス名を生成する（Ｓ３０２）。本実施の形態において、テナント用フォルダのパス名は、ルートフォルダ１７１のパス名に対してテナントＩＤを付加したものである。したがって、例えば、テナントＩＤが「ＡＡＡ」であれば、テナントＡ用フォルダ１７３のパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ＡＡＡ」として生成される。

続いて、拡張タグ処理部１３は、ｓａａｓ：ｉｎｃｌｕｄｅタグにｊｓｐ属性が指定されているか否かを確認する（Ｓ３０３）。ｊｓｐ属性が指定されている場合（Ｓ３０３でＹｅｓ）、拡張タグ処理部１３は、テナント用フォルダのパス名にｊｓｐ属性の値を付加したものを処理対象の画面定義ファイルのパス名とする（Ｓ３０４）。具体的には、ｊｓｐ属性の値が「ａａａａａａ．ｊｓｐ」であれば、当該画面定義ファイルのパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ＡＡＡ／ａａａａａａ．ｊｓｐ」とされる。

一方、ｊｓｐ属性が指定されていない場合（Ｓ３０３でＮｏ）、拡張タグ処理部１３は、テナント用フォルダのパス名に、現在処理対象のインクルードファイルのファイル名を付加したものを処理対象の画面定義ファイルのパス名とする（Ｓ３０５）。具体的には、現在処理対象のインクルードファイルのファイル名が「ａ．ｊｓｐ」であれば、当該画面定義ファイルのパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ＡＡＡ／ａ．ｊｓｐ」とされる。

ステップＳ３０４又はＳ３０５に続いて、拡張タグ処理部１３は、生成されたパス名に係る画面定義ファイルの存否を判定する（Ｓ３０６）。当該画面定義ファイルが存在する場合（すなわち、テナントＩＤに係るテナント用にカスタマイズされた画面定義ファイルが存在する場合）（Ｓ３０６でＹｅｓ）、拡張タグ処理部１３は、当該画面定義ファイルをアプリケーションサーバ１２に実行させる（Ｓ３０７）。その結果、例えば、テナントＡ用フォルダ１７３内の画面定義ファイルが実行された場合、テナントＡ用にカスタマイズされた画面データが生成される。

一方、生成されたパス名に係る画面定義ファイルが存在しない場合（Ｓ３０６でＮｏ）、拡張タグ処理部１３は、ｓａａｓ：ｉｎｃｌｕｄｅタグにｄｅｆａｕｌｔＪｓｐ属性が指定されているか否かを確認する（Ｓ３０８）。ｄｅｆａｕｌｔＪｓｐ属性が指定されている場合（Ｓ３０８でＹｅｓ）、拡張タグ処理部１３は、ルートフォルダのパス名にｄｅｆａｕｌｔＪｓｐ属性の値を付加したものを遷移先の画面の標準フォルダ１７１のパス名とする（Ｓ３０９）。具体的には、ｄｅｆａｕｌｔＪｓｐ属性の値が「ｄｅｆａｕｌｔ」であれば標準フォルダ１７１のパス名は、「ＷＥＢ−ＩＮＦ／ｊｓｐ／ｄｅｆａｕｌｔ」とされる。

また、ｄｅｆａｕｌｔＪｓｐ属性が指定されていない場合（Ｓ３０８でＮｏ）、拡張タグ処理部１３は、ルートフォルダのパス名に予め定められているフォルダ名（ｃｏｍｍｏｎ）を付加したものを遷移先の画面の標準フォルダ１７１のパス名とする（Ｓ３１０）。したがって、標準フォルダ１７１のパス名は「ＷＥＢ−ＩＮＦ／ｊｓｐ／ｃｏｍｍｏｎ」とされる。

ステップＳ３０８又はＳ３０９に続いて、拡張タグ処理部１３は、標準フォルダ１７１のパス名に画面定義ファイルのファイル名を付加し、標準の画面定義ファイルのパス名を生成する（Ｓ３１１）。ここで付加される画面定義ファイルのファイル名は、ステップＳ３０３〜Ｓ３０５において判定されたものに従う。すなわち、インクルードファイルにｊｓｐ属性が指定されていればｊｓｐ属性の値が採用される。ｊｓｐ属性が指定されていなければ、インクルードファイルのファイル名が採用される。

続いて、拡張タグ処理部１３は、生成されたパス名に係る画面定義ファイルをアプリケーションサーバ１２に実行させる（Ｓ３１２）。その結果、標準の画面定義ファイルに基づいて標準の画面データが生成される。

上述したように、本実施の形態によれば、画面遷移に係る一連の画面を生成する際に、テナント固有にカスタマイズされた画面定義ファイルが存在する場合は当該固有の画面定義ファイルが利用される。また、テナント固有にカスタマイズ画面定義ファイルが存在しない場合は、標準の（全てのテナントに対して共通の）画面定義ファイルが利用される。

例えば、図６のように画面定義ファイルが作成されている場合、テナントＡについては、画面Ｂは標準の画面が表示される。テナントＢについては、画面Ａ及びＣは標準の画面が表示される。また、テナントＣについては、固有の画面定義ファイルを作成されていないため、全ての画面について標準の画面が表示される。

したがって、画面遷移に係る全ての画面について画面定義ファイルを作成する必要はない。換言すれば、カスタマイズが必要な一部の画面について画面定義ファイルを作成すればよい。その結果、全ての画面について画面定義ファイルを作成する場合に比べ、画面定義ファイルのファイル数を削減することができる。よって、画面定義ファイルを作成するための工数や、画面定義ファイルを保存するための記憶容量等を削減することができる。

なお、カスタマイズの単位をテナントごとではなく、ユーザ（ここで、ユーザは一個人を意味する。）ごとにする必要がある場合、テナントＩＤをユーザＩＤに置き換えて本実施の形態を実施すればよい。具体的には、セッションスコープ１８にはユーザＩＤを記録すればよい。また、ユーザＩＤに応じて画面定義ファイルを作成しておけばよい。この場合、クライアント識別子の具体例は、テナントＩＤではなく、ユーザＩＤとなる。

また、画面定義データとして、ＪＳＰ以外のデータを用いてもよい。例えば、ＸＭＬ（eXtensible Markup Language）データやＸＳＬ（eXtensible Stylesheet Language）データを用いてもよい。また、ＡＳＰ（Active Server Pages）を用いてもよい。その他のデータ形式や、独自に定義したデータを用いてもよい。

また、本実施の形態では、標準の画面定義ファイルとテナントごとに固有の画面定義ファイルとを保存先のフォルダを変えることによって区別していたが、例えば、ファイル名によって区別するようにしてもよい。例えば、テナントごとに固有の画面定義ファイルには、テナントＩＤがファイル名に含まれるようにしてもよい。この場合、標準の画面定義ファイル及び各テナント用の画面定義ファイルは、同じフォルダ内に保存されていてもよい。

ところで、本実施の形態によれば、テナントごとに画面のカスタマイズが不可能であった（すなわち、全てのテナントに標準の画面が提供される）既存のシステムからの移行コストを低減できるというメリットもある。全てのテナントに標準の画面が提供されるシステムにおける画面定義データは、一般的に図１２のように構成される。

図１２は、全てのテナントに標準の画面が提供されるシステムにおける画面定義データの構成例を示す図である。図１２中、図６と対応する部分には同一符号を付している。

図１２に示されるように、全てのテナントに標準の画面が提供されるシステムでは、ルートフォルダ１７１内に、標準の画面定義データ１７１ａ、１７１ｂ、及び１７１ｃが保存されている。この状態から、図６の状態へ移行するためには、インクルードファイルの生成、標準の画面定義データの保存場所の移動、カスタマイズが必要なテナントに対する画面定義データの作成、及び拡張タグ処理部１３の実装を行えばよい。したがって、既存のプログラムのコーディングを変更したりする必要はない。よって、比較的簡便な作業によって、テナントごとにカスタマイズされた画面を提供可能なシステムに移行することができる。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。 Ｗｅｂサーバによる処理手順を説明するためのフローチャートである。 テナントＩＤ管理テーブルの構成例を示す図である。 本実施の形態における画面遷移の例を示す図である。 本実施の形態における画面定義データの構成例を示す図である。 インクルードファイルの定義例を示す図である。 画面定義ファイルの定義例を示す図である。 インクルードファイルの第二の定義例を示す図である。 画面データ生成処理の処理手順を説明するためのフローチャートである。 拡張タグ処理部による処理手順を説明するためのフローチャートである。 全てのテナントに標準の画面が提供されるシステムにおける画面定義データの構成例を示す図である。

１０ ＨＴＴＰサーバ
１１ ＨＴＴＰサーバ
１２ アプリケーションサーバ
１３ 拡張タグ処理部
１４ 業務アプリケーション
１５ テナント判定部
１７ 画面定義データ
１８ セッションスコープ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

Claims (4)

1. 画面データを生成するコンピュータが、
   端末装置からの操作入力に基づく複数の画面遷移それぞれにおいて、遷移先画面が該端末装置が属するテナントについて前記複数のテナントで共用される定義情報に基づく画面であり、前記共用される定義情報に基づいて前記遷移先画面の画面データを生成した後に、該端末装置についての次の遷移先画面が前記ある端末装置の属するテナントに対応付けられた、前記共用される定義情報と異なる定義情報に基づく画面であるときは、前記異なる定義情報に基づいて前記次の遷移先画面の画面データを生成する、
   ことを特徴とする画面生成方法。
2. 複数のテナントで共有される定義情報と、前記定義情報とは異なる定義情報との双方が対応づけられたテナントに属する端末装置からの操作入力に基づく複数の画面遷移それぞれにおいて、遷移先画面が前記端末装置が属するテナントについて前記複数のテナントで共用される定義情報に基づく画面であるときは、前記共用される定義情報に基づいて遷移先画面の画面データを生成し、遷移先画面が前記端末装置の属するテナントに対応付けられた、前記共用される定義情報と異なる定義情報に基づく画面であるときは、前記異なる定義情報に基づいて遷移先画面の画面データを生成する画面生成装置に対して、いずれのテナントに属するか識別可能なユーザ識別情報を送信し、
   送信した該ユーザ識別情報に基づいて前記画面生成装置によって判定されたテナントについて、前記端末装置についての遷移先画面が前記複数のテナントで共用される定義情報に基づく画面であるときは、前記共用される定義情報に基づいて生成された画面データを遷移先画面データとして受信し、送信した該ユーザ識別情報に基づいて前記画面生成装置によって判定されたテナントについて、前記端末装置についての遷移先画面が当該テナントに対応付けられた、前記共用される定義情報と異なる定義情報に基づく画面であるときは、前記異なる定義情報に基づいて生成された画面データを遷移先画面データとして受信し、
   受信した画面データを遷移先の画面データとして前記端末装置の表示部にそれぞれ表示する、
   ことを特徴とする画面表示を行う画面表示方法。
3. 端末装置からの操作入力に基づく複数の画面遷移それぞれにおいて、遷移先画面が該端末装置が属するテナントについて前記複数のテナントで共用される定義情報に基づく画面であり、前記共用される定義情報に基づいて前記遷移先画面の画面データを生成した後に、該端末装置についての次の遷移先画面が前記ある端末装置の属するテナントに対応付けられた、前記共用される定義情報と異なる定義情報に基づく画面であるときは、前記異なる定義情報に基づいて前記次の遷移先画面の画面データを生成する、
   ことを特徴とする画面生成装置。
4. 画面データを生成するコンピュータに、
   端末装置からの操作入力に基づく複数の画面遷移それぞれにおいて、遷移先画面が該端末装置が属するテナントについて前記複数のテナントで共用される定義情報に基づく画面であり、前記共用される定義情報に基づいて前記遷移先画面の画面データを生成した後に、該端末装置についての次の遷移先画面が前記ある端末装置の属するテナントに対応付けられた、前記共用される定義情報と異なる定義情報に基づく画面であるときは、前記異なる定義情報に基づいて前記次の遷移先画面の画面データを生成する、
   処理を実行させることを特徴とするプログラム。

Images