JP2009282777A - アプリケーションプログラムの提供システム及びアプリケーションプログラム - Google Patents

Abstract

【課題】マルチテナント型アプリケーションのカスタマイズ機能に拡張性を持たせると共にメンテナンス時の対応が容易なアプリケーションプログラムの提供システムを提供すること。
【解決手段】リポジトリ管理システム１０１は、商談管理アプリケーション１２５をカスタマイズする利用者カスタマイズ機能部１０２と、商談管理アプリケーションの標準アプリケーション定義を保持する標準アプリケーション定義領域１０６と、作成されたアプリケーション定義を保持するアプリケーション定義領域１１０と、ユーザ名とパスワードによるリポジトリ管理システム１０１への認証と、ユーザ名から、利用者毎の定義領域を取得するための振り分けとを行う認証エンジン１１７と、アプリケーション定義情報を解析し、商談管理アプリケーションに提供する定義情報解析エンジン１１８と、を備えて構成されている。
【選択図】図１

Description

本発明はアプリケーションプログラムの提供システム及びアプリケーションプログラムに係り、特に、マルチテナント型アプリケーションを容易に実現するためのリポジトリ（カスタマイズ情報管理領域）を備え、カスタマイズ性およびメンテナンス性を維持・向上させたアプリケーションプログラムの提供システム及びアプリケーションプログラムに関する。

近年、多くの企業がネットワーク経由で利用可能なアプリケーションを提供している。Google社による、ワープロ、表計算ソフトや、カレンダーといったアプリケーションプログラム（以下、「アプリケーション」と略称する）や、SalesForce.com社による、顧客管理アプリケーションなどがその代表例である。これらの何れのアプリケーションも、複数の利用者によって同一のアプリケーションおよびハードウェア環境が共有される。また、データベースやウェブページなどの設定を利用者毎にカスタマイズすることが可能であるという特徴を有しており、マルチテナント型アプリケーションと呼ばれている。

このようなマルチテナント型アプリケーションでは、利用者毎に専用の環境を構築する必要がないことから、アプリケーションの迅速な導入と、ＴＯＣ（total Cost of Ownership）の削減が可能である。また、複数の利用者で同一の環境を利用することで、バージョンアップなどのメンテナンス時の対応が共通化されるため、アプリケーションのメンテナンスを容易に実行することが可能である。

尚、このようなマルチテナント型アプリケーションでは、複数の全ての利用者に対して、同一バージョンのアプリケーションを提供することになるが、利用者毎に微妙に異なる仕様要求を満たすために、利用者の仕様要求に応じて、利用者自身がアプリケーションのカスタマイズや機能の新規追加を行う機能（即ち、利用者カスタマイズ機能）を持たせることが一般的となっている。

このような利用者カスタマイズ機能として、例えば特開２００１−３１２４００公報では、利用者毎にパラメータを保持してアプリケーションをカスタマイズする技術を開示している（特許文献１参照）。また、特表２００７−５３１９４１号公報に見られるように、利用者毎にデータベースをカスタマイズする技術を利用してマルチテナント型アプリケーションの利用者カスタマイズ機能を実現する技術が開示されている（特許文献２参照）。
特開２００１−３１２４００号公報 特表２００７−５３１９４１号公報

ところで、前述のマルチテナント型アプリケーションでは、利用者カスタマイズ機能が重要となるため、アプリケーション定義（ここではデータベース定義、ビジネスロジック定義、及びウェブページ定義、の三要素で構成されるものとする）は、利用者の要件に応じてカスタマイズされる必要がある。しかしながら、上記背景技術で述べた従来のアプリケーションプログラムの提供システム及びアプリケーションプログラムにあっては、利用者毎のカスタマイズ要求に対応するために、アプリケーション定義を利用者毎に変更した場合には下記の問題点が生じる可能性がある。

即ち、例えば、ビジネスロジック定義を利用者毎に変更する場合、この変更により、ビジネスロジック（即ちアプリケーションのプログラム自体）が利用者毎に異なるものとなってしまうため、アプリケーションのバージョンアップや、バグ対応に伴うメンテナンス用バッチの実行時などで弊害が生じる可能性があり、本来のマルチテナント型アプリケーションの特徴（即ちアプリケーションメンテナンス時の対応の容易性）が失われてしまうことがある。

そこで、メンテナンスの容易性を保持しつつ、利用者カスタマイズを実現するために、提供するアプリケーションには、利用者毎のカスタマイズ情報を保持するリポジトリ（カスタマイズ情報を格納して管理する領域）を構成し、このリポジトリの情報を元に、カスタマイズ部分を動的に切り替える仕組みが開発されている。尚、このリポジトリは、当該アプリケーションのプログラム中に、if文等の分岐命令として、予め組み込んでおく方法が確立している。

しかしながら、このようなリポジトリの組み込み方法では、提供するアプリケーションに、カスタマイズ可能な処理の全てを、分岐命令で網羅するようなコードを動的に組み込むことができる機能が必要となり、マルチテナント型アプリケーション開発時における生産性、およびメンテナンス性を悪化させてしまう。
また、カスタマイズ可能な処理の全てを、分岐命令で網羅したアプリケーションが予め定義されることから、想定外のカスタマイズ要求には対応できないという欠点がある。

さらに、マルチテナント型のアプリケーションを開発する際に必要な条件として、利用者毎のカスタマイズ情報を管理することが要求される。このため、前述のとおり、アプリケーションには、カスタマイズ情報を管理するリポジトリと呼ばれる管理領域（単純なファイルシステムやデータベースの場合）を備えさせる必要があり、開発者は、このリポジトリからカスタマイズ情報を拾い上げて、アプリケーションと関連付けて開発を行う必要がある。しかしながら、このような構成では、利用者による様々な種類のアプリケーションのカスタマイズや追加が行われた際に、例えば、それらの変更を理解するための仕組みを全てアプリケーション側で保持する必要があり、このため、アプリケーション自体が大きく複雑になってしまうという問題点がある。

本発明は、上記従来の問題点に鑑みてなされたものであって、マルチテナント型アプリケーションのカスタマイズ機能に拡張性を持たせると共にメンテナンス時の対応が容易なアプリケーションプログラムの提供システムを提供することを目的としている。
本発明の他の目的は、マルチテナント型アプリケーションのカスタマイズ機能に拡張性を持たせると共にメンテナンス時の対応が容易なアプリケーションプログラムを提供することにある。

上記課題に鑑みて鋭意研究の結果、本発明者は、アプリケーションとマルチテナント対応用のリポジトリとを分離させることにより、アプリケーション開発者がマルチテナントへの対応を意識することなくマルチテナント型アプリケーションを開発することが可能となることに想到し本発明をなすに至った。

すなわち、本発明は、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型アプリケーションを提供するアプリケーションプログラムの提供システムであって、標準仕様を定義した標準アプリケーション定義情報と、前記標準アプリケーション定義情報よりも拡張された仕様を定義した拡張アプリケーション定義情報と、前記利用者が定義した利用者アプリケーション定義情報とを格納しているリポジトリ管理領域と、前記利用者とのインタフェース手段を備え、前記リポジトリ管理領域に格納されている前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報を、前記利用者の各々が前記インタフェース手段を通じて要求する仕様にカスタマイズさせて更新する手段と、前記リポジトリ管理領域に格納されている標準アプリケーション定義情報、前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報に基づいて、前記利用者の各々に提供されるプログラム構成を変更するレンダリング手段を有するアプリケーションプログラム本体とを有することを特徴とするアプリケーションプログラムの提供システムを提供するものである。

また、前記アプリケーションプログラムの提供システムにおいて、前記アプリケーション定義情報は、データベースの仕様を定義するデータベース定義と、ウェブページの仕様を定義するウェブページ定義と、前記アプリケーションプログラムのロジックを定義するロジック定義とを含むことを特徴とする。

さらに、前記アプリケーションプログラムの提供システムにおいて、前記リポジトリ管理領域内に、前記利用者の各々に対応してカスタマイズされた定義情報を、前記利用者ごとに格納するキャッシュメモリ領域を設け、前記レンダリング手段は、前記キャッシュメモリ領域に格納された最新の更新日付の定義情報を参照することを特徴とする。
前記利用者毎のキャッシュメモリ領域の使用により、アプリケーション定義の参照に要する時間を短縮することができる。

また、本発明は、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型アプリケーションを提供するアプリケーションプログラムの提供用プログラムであって、標準仕様を定義した標準アプリケーション定義情報と、前記標準アプリケーション定義情報よりも拡張された仕様を定義した拡張アプリケーション定義情報と、前記利用者が定義した利用者アプリケーション定義情報とを格納している、前記サーバの記憶装置に設けられたリポジトリ管理領域に対してデータの読み書きを行う機能と、前記利用者とのインタフェース手段を提供する機能と、前記リポジトリ管理領域に格納されている前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報を、前記利用者の各々が前記インタフェース手段を通じて要求する仕様にカスタマイズさせて更新する機能と、前記リポジトリ管理領域に格納されている標準アプリケーション定義情報、前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報に基づいて、前記利用者の各々に提供されるアプリケーションプログラム本体のプログラム構成を変更するレンダリング機能とを前記サーバに実行させることを特徴とするアプリケーションプログラムの提供用プログラムを提供するものである。

また、前記アプリケーションプログラムの提供用プログラムにおいて、前記アプリケーション定義情報は、データベースの仕様を定義するデータベース定義と、ウェブページの仕様を定義するウェブページ定義と、前記アプリケーションプログラムのロジックを定義するロジック定義とを含むことを特徴とする。

また、前記アプリケーションプログラムの提供用プログラムにおいて、前記リポジトリ管理領域内に、前記利用者の各々に対応してカスタマイズされた定義情報を、前記利用者ごとに格納するキャッシュメモリ領域が設けられており、前記レンダリング機能は、前記キャッシュメモリ領域に格納された最新の更新日付の定義情報を参照することを特徴とする。

即ち、本発明に係るアプリケーションプログラムの提供システム及びアプリケーションプログラムは、マルチテナント型アプリケーションが標準で提供するアプリケーション定義を標準アプリケーション定義とし、リポジトリ管理システムで管理する。

また、利用者カスタマイズ機能によって標準アプリケーション定義を拡張した場合に作成されるアプリケーション定義を拡張アプリケーション定義とする。さらに、利用者カスタマイズ機能で利用者が独自に定義したアプリケーション定義を利用者アプリケーション定義とし、リポジトリ管理システムで管理する。これら３種類のアプリケーション定義はリポジトリ管理システムに専用の領域を準備し、ファイルもしくはデータベースで管理することとする。

利用者がアプリケーションを利用するタイミングで、リポジトリ管理システムは、利用者ごとに管理している標準アプリケーション定義、拡張アプリケーション定義をマージして適切な形式のアプリケーション定義を作成し、アプリケーションに対して提供するが、ここで、利用者アプリケーション定義は利用者特有のアプリケーションであるため、そのままの形でアプリケーションに対して提供することができるようにしている。

さらに、本発明に係るアプリケーションプログラムの提供システム及びアプリケーションプログラムは、これらの定義情報を基に、レンダリング（定義情報から、HTML、データベース、或いはプログラムといった実体を生成すること）を行い、アプリケーションを構築し、これにより、アプリケーションを、利用者毎に最適にカスタマイズされた状態で提供することを可能にしている。

尚、このような構成により、アプリケーションから、マルチテナント用のリポジトリ管理システムを分離することができる（アプリケーションとリポジトリとの関連性はリポジトリ管理ステムから提供される定義ファイルに限定される）ため、アプリケーション側は、標準アプリケーション定義、拡張アプリケーション定義、利用者アプリケーション定義が分離されていることを意識せずに、リポジトリ管理システムから提供される統合された単一の形式のアプリケーション定義のみを受け取れば良いことになる。その結果、この単一のアプリケーション定義を基に、通常のアプリケーションを構築するだけでよいため、アプリケーション開発者は、マルチテナント対応を意識することなく、定義情報からアプリケーション実体へのレンダリングを行うだけで、利用者カスタマイズに対応したマルチテナント型アプリケーションを開発することを可能にしている。

また、リポジトリ管理システム上で、標準アプリケーション定義と拡張アプリケーション定義および利用者アプリケーション定義が分離されているため、アプリケーションのメンテナンスは、利用者によるカスタマイズ結果に影響されることなく、標準アプリケーション定義のみを対象としても構わないのである。このため、アプリケーションに対してメンテナンスの簡易性を維持させることが可能となる。

尚、利用者カスタマイズ機能は、利用者用のインタフェースを作成し、拡張アプリケーション定義と利用者アプリケーション定義のみを操作させることで、標準アプリケーション定義に影響を与えることなく実現可能である。ここで作成する利用者用のインタフェースは、アプリケーション定義が複数存在することを意識させない設計とすることで、利用者の操作性を向上させている。

以上説明したように、本発明のアプリケーションプログラムの提供システム及びアプリケーションプログラムによれば、アプリケーションとマルチテナント対応用のリポジトリが分離されているため、アプリケーション開発者は、マルチテナントへの対応を意識することなく、マルチテナント型アプリケーションを開発することが可能となる効果がある。

また、標準アプリケーション定義と利用者のカスタマイズ定義との２つのアプリケーション定義を分離することで、マルチテナント型アプリケーションのメリット、即ち、メンテナンス時の対応の容易性と利用者カスタマイズ機能とを同時に実現可能となる効果がある。

この結果、アプリケーションとマルチテナント対応用のリポジトリがやり取りするのは定義ファイルのみとなり、アプリケーションは、リポジトリから提供される定義情報のみを基に、単純に、データベース、ウェブページ、或いはビジネスロジックを構築するだけでよいので、開発者は、マルチテナント対応であることを意識する必要がなくなるといった効果もある。

以下、本発明のアプリケーションプログラムの提供システムの最良の実施形態について、図面を参照して詳細に説明する。尚、本発明に係るアプリケーションプログラムについては、本発明に係るアプリケーションプログラムの提供システムを組み込んで動作するプログラムであることから、当該プログラムに関する説明は以下の説明に含まれるものとする。

以下、簡易的なマルチテナント型商談管理アプリケーションを例に、本発明を詳細に説明する。
図１は、本発明の実施形態に係るアプリケーションプログラムの提供システムを採用したマルチテナント型商談管理アプリケーションの全体構成を示す構成図である。
同図において、本実施形態のアプリケーションプログラムの提供システムを採用したマルチテナント型商談管理アプリケーションは、商談管理アプリケーション１２５（アプリケーションプログラムの本体）と、リポジトリ管理システム１０１と、を備えて構成される。

リポジトリ管理システム１０１は、利用者が商談管理アプリケーション１２５をカスタマイズするために利用する利用者カスタマイズ機能部１０２と、商談管理アプリケーションの標準機能を実現するための標準アプリケーション定義を保持する標準アプリケーション定義領域１０６（リポジトリ管理領域）と、利用者（ここでは「ユーザＡ」とする）のカスタマイズ機能を利用して作成されたアプリケーション定義を保持するアプリケーション定義領域１１０（リポジトリ管理領域）と、ユーザ名とパスワードによるリポジトリ管理システム１０１への認証と、ユーザ名から、利用者毎の定義領域を取得するための振り分けとを行う認証エンジン１１７と、リポジトリ内のアプリケーション定義情報を解析し、商談管理アプリケーションに提供する定義情報解析エンジン１１８と、を備える。

利用者カスタマイズ機能部１０２は、後述するカスタマイズＵＩ（ユーザインタフェース）１０４によって変更されたアプリケーション定義を利用者アプリケーション定義領域に反映するための定義更新部１０３と、アプリケーション定義を変更するためのユーザインタフェースを与えるカスタマイズＵＩ１０４と、アプリケーション定義を解析するための解析部１０５と、を備える。

標準アプリケーション定義領域１０６は、商談管理アプリケーション１２５が標準仕様で利用するデータベース定義１０７と、ウェブページ定義１０８と、ビジネスロジック定義１０９（ロジック定義）と、を備える（ここで、いずれの定義も複数とすることができる）。

アプリケーション定義領域１１０は、利用者カスタマイズ機能により、標準仕様のアプリケーション定義に対する拡張や追加を行う拡張データベース定義１１１と、拡張ウェブページ定義１１２と、拡張ビジネスロジック定義１１３と、を備え、さらに、利用者カスタマイズ機能により、利用者専用に作成されるアプリケーションの定義を与える利用者データベース定義１１４と、利用者ウェブページ定義１１５と、利用者ビジネスロジック定義１１６と、を備える。

定義情報解析エンジン１１８は、アプリケーション定義を解析するための解析部１１９と、解析部によって得られたユーザ（ここではユーザＡ）用の定義情報を格納しているメモリ空間であるユーザＡメモリ領域１２０と、を備える。ここで、ユーザＡメモリ領域１２０とは、それぞれユーザＡに対応した一種のキャッシュメモリ領域であり、商談アプリケーション１２５の使用直前に、アプリケーション定義領域１１０の情報（ウェブページ定義１２２、ビジネスロジック定義１２３、及びデータベース定義１２４）の、常に最新更新日のものと置き換えられて参照されるメモリ領域である。

商談管理アプリケーション１２５は、レンダリング部１２１（レンダリング手段）と、業務用に使用する業務用データベース１２６と、データベースアクセスを実行するためのルーチン１２７と、ビジネスロジックを実行するためのルーチン１２８と、HTML形式のウェブページ１２９と、を備える。尚、ユーザＡは符号１３０で示す。

以下、本実施形態のアプリケーションプログラムの提供システムを採用したマルチテナント型商談管理アプリケーションが有する各構成要素の動作について説明する。
まず、利用者カスタマイズ機能部１０２の処理について説明する。
利用者カスタマイズ機能部１０２における利用者カスタマイズ機能とは、提供するアプリケーション（例えば、商談管理アプリケーション１２５）を利用者のニーズに沿ってカスタマイズする機能である。利用者カスタマイズ機能部１０２によって、２種類のアプリケーション定義が新たに作成される。即ち、所定のデータベース定義に対して新たに定義列を追加するといった機能を有する拡張アプリケーション定義（ここでは商談管理アプリケーションの定義を拡張する）と、新機能（例えば顧客管理機能）を新たに実装するといった、商談管理アプリケーションに新たにアプリケーション定義を追加する利用者アプリケーション定義との、計２つである。

利用者カスタマイズ機能部１０２が、ユーザＡに関するデータベース定義のカスタマイズを行う際には、最初に、ユーザＡの認証エンジンを介したログインの実行を処理する。ユーザＡによるログインは、ユーザIDおよびパスワードにて行われ、例えば、ユーザＡと正しく認証されることで、標準アプリケーション定義領域１０６へのアクセス許可と、利用者アプリケーション定義領域１１０（ここではユーザＡ対応の領域）へのアクセス許可が付与される。正しく認証が行われない場合は、これらの定義領域へのアクセスは許可されない（否認）。このログインを実行させることで、解析部１０５が、標準アプリケーション定義領域１０６から商談管理アプリケーションのデータベース定義１０７を取得する。

図３は、データベース定義の１例を示す説明図である。
同図に示すように、必要なデータベース定義はファイル名で取得される。同図の２行目がデータベースの名称定義である。ここでは、namespace(所有者情報)に『アプリケーション』、name（テーブル名）に『account』が設定されており、nameはファイル名と同一である。以上により、図３に示すデータベース定義は、標準のデータベース定義１０７のaccountテーブルであることが分かる。同図の３行目以降はテーブルに固有のプロパティー情報であり、name（名称）、type（データ型）などが定義されている。アプリケーション定義や標準ビジネスロジック定義についても同様にXML形式のデータで格納されているものとする。

次に、解析部１０５は、利用者アプリケーション定義領域１１０（ここではユーザＡ対応の領域）から、拡張データベース定義１１１を取得する。拡張データベース定義１１１は、利用者アプリケーション定義領域１１０（即ち、ユーザＡ対応の領域）から、標準のデータベース定義と同一のファイル名で取得される。

図４は、拡張データベース定義の１例を示す説明図である。
同図に示す拡張データベース定義には、標準のデータベース定義１０７を上書きするためのMain Table Propertyと、利用者が拡張した項目であるPropertyとがある。同図の２行目がデータベースの名称定義である。図３に示す標準のデータベース定義１０７とほぼ同じ名称定義であるが、拡張データベース定義であることを示すために、nameが『account＿ユーザA』となっている。同図の３行目以降はプロパティー情報である。拡張データベース定義は２種類のプロパティー情報を保持する。１つ目がMain Table Propertyである。Main Table Propertyは標準のデータベース定義１０７のプロパティー情報を上書きするためのプロパティー情報である。また、２つ目がPropertyである。Propertyは利用者が追加したプロパティー情報であり、標準のデータベース定義１０７とは全く関連性がない。

マージする際は、同じファイル名を有する前記２つのデータベース定義をマージ（併合処理）する。具体的には拡張データベース定義の持つ２つのプロパティー情報で標準のデータベース定義１０７を上書きする。上書きする項目がない場合は、標準のデータベース定義１０７をそのまま使用する。マージした後、accountテーブルの定義情報として利用者毎に提供する。そのため、利用者は定義情報が分割されていることを意識することはない。

以上に述べたように、解析部１０５は標準のデータベース定義１０７と、拡張データベース定義１１１とをマージし、その結果をカスタマイズ用のアプリケーション定義（ここではデータベース定義）として内部メモリ（一時的な作業用メモリ）に格納する。
また、解析部１０５は、利用者アプリケーション定義領域１１０（ユーザＡ対応）から、利用者データベース定義１１４も取得する。
図５は、利用者データベース定義１１４の１例を示す説明図である。
同図に示すように、利用者データベース定義１１４は標準のデータベース定義１０７と同じ構成であるが、特定の利用者（ここではユーザＡ）のみが利用可能な専用のデータベースである。このため、２行目のnamespaceが「アプリケーション」ではなく「ユーザＡ」となっている。利用者カスタマイズ機能部１０２は、この利用者データベース定義１１４も、カスタマイズ用に内部メモリへと格納する。内部メモリに格納されるデータベース定義の形式は、図３もしくは図５で示されるデータベース定義と同一の形式である。

ユーザＡが利用可能な全てのデータベース定義が内部メモリに格納された後、ユーザＡは、これらのデータベース定義に対してカスタマイズを行う。このカスタマイズは専用のカスタマイズユーザＵＩ１０４を介して、若しくは定義情報の直接的な更新によって行うものとする。カスタマイズが終わった後、定義更新部１０３によって、アプリケーション定義領域１１０の拡張アプリケーション定義（ここでは拡張データベース定義１１１）と、利用者アプリケーション定義（ここでは利用者データベース定義１１４）が更新される（当然ながら、標準のデータベース定義１０７は更新されない）。

以上がカスタマイズツールを利用した、カスタマイズと、リポジトリへの反映とを行う機能であり、利用者はユーザインタフェースを利用して、利用者のニーズに応じたカスタマイズが可能となる。

図２は、利用者カスタマイズ機能部１０２の処理の流れを示すフローチャート図である。
以下、図１を参照し、利用者カスタマイズ機能部１０２の処理の流れについて、アプリケーション定義のデータベース定義をカスタマイズする場合を例に、図２に示すフローチャート図を使用して詳細に説明する。
（ステップＳ２００）
ステップＳ２００では、ユーザＡ（符号１３０）が、カスタマイズＵＩ１０４にアクセスする。
（ステップＳ２０１）
ステップＳ２０１では、認証エンジン１１７が、上記アクセスを許可するために、ユーザＡの認証を行い、認証が得られない場合は処理を終了し、認証が得られた場合はステップＳ２０２に進む。
（ステップＳ２０２）
ステップＳ２０２では、解析部１０５が、標準アプリケーション定義領域１０６から、データベース定義１０７を取得する。
（ステップＳ２０３）
ステップＳ２０３では、解析部１０５が、利用者アプリケーション定義領域１１０に、拡張データベース定義１１１が存在するか否かを検証し、拡張データベース定義１１１が存在する場合はステップＳ２０４に移り、拡張データベース定義１１１が存在しない場合はステップＳ２０８に進む。

（ステップＳ２０４）
ステップＳ２０４では、解析部１０５が、以下のステップＳ２０５からステップＳ２０７までの処理を、拡張データベース定義１１１の定義数だけ反復できるように細工する。
（ステップＳ２０５）
ステップＳ２０５では、解析部１０５が、利用者アプリケーション定義領域１１０（ユーザＡ対応）から、拡張データベース定義１１１を取得する。
（ステップＳ２０６）
ステップＳ２０６では、解析部１０５が、拡張データベース定義１１１と対応する標準のデータベース定義１０７をマージ処理する。
（ステップＳ２０７）
ステップＳ２０７では、解析部１０５が、前記マージしたデータベース定義の各々を内部メモリに格納する。この後、ステップＳ２０５からの拡張データベース定義１１１の定義数だけの反復処理が完了している場合はステップＳ２０８に進む。

（ステップＳ２０８）
ステップＳ２０８では、解析部１０５が、利用者アプリケーション定義領域１１０に、利用者データベース定義１１４が存在するか否かを検証し、利用者データベース定義１１４が存在する場合はステップＳ２０９に移り、利用者データベース定義１１４が存在しない場合はステップＳ２１２に進む。

（ステップＳ２０９）
ステップＳ２０９では、解析部１０５が、以下のステップＳ２１０からステップＳ２１１までの処理を、利用者データベース定義１１４の定義数だけ反復できるように細工する。
（ステップＳ２１０）
ステップＳ２１０では、解析部１０５が、利用者アプリケーション定義領域１１０（ユーザＡ対応）から、利用者データベース定義１１４を取得する。
（ステップＳ２１１）
ステップＳ２１１では、解析部１０５が、前記取得したデータベース定義の各々を内部メモリに格納する。この後、ステップＳ２１０からの利用者データベース定義１１４の定義数だけの反復処理が完了している場合はステップＳ２１２に進む。
（ステップＳ２１２）
ステップＳ２１２では、ユーザＡが、内部メモリに格納されたデータベース定義の各々をカスタマイズする。
（ステップＳ２１３）
ステップＳ２１３では、定義更新部１０３が、カスタマイズ情報（ユーザＡによってカスタマイズされた情報）に基づいて、アプリケーション定義領域１１０の拡張アプリケーション定義（ここでは拡張データベース定義１１１）を更新する。
（ステップＳ２１４）
ステップＳ２１４では、定義更新部１０３が、カスタマイズ情報（ユーザＡによってカスタマイズされた情報）に基づいて、アプリケーション定義領域１１０の利用者アプリケーション定義（ここでは利用者データベース定義１１４）を更新し、処理を終了する。

次に、商談管理アプリケーション１２５側から見たリポジトリ管理システム１０１の使用方法について説明する。
ここでは、ユーザＡが、リポジトリ管理システム１０１から専用のウェブページ定義１２２を取得し、商談管理アプリケーション１２５上のユーザＡ専用のウェブページ１２９として利用する方法を例に説明する。ユーザＡが、アプリケーション１２５上のユーザＡ専用のウェブページ１２９にアクセスする際は、常に定義情報解析エンジン１１８を介するものとする。

認証エンジン１１７は、アプリケーションのログインIDと連携しており、ログインは、ユーザIDおよびパスワードの入力によって行われ、例えば、ユーザＡと正しく認証されることで、定義解析エンジン１１７に対して標準アプリケーション定義領域１０６へのアクセス許可と、ユーザＡアプリケーション定義領域１１０と、ユーザＡに対応するユーザＡメモリ領域１２０と、に対するアクセス許可が付与される。正しく認証が行われない場合は、このようなアクセスは許可されない（否認）。

アクセス許可が付与された後、定義情報解析エンジンの解析部１１９は、商談管理システム（ここでは商談管理アプリケーション１２５が必要とするページID（商談管理ページなどの一意な名称や、一意なID）を基に、ユーザＡメモリ領域１２０の検索を行う。ユーザＡメモリ領域１２０は、利用者Ａ用に用意されたキャッシュメモリ空間である、ユーザＡメモリ領域１２０に対象のウェブページ定義が存在する場合は、ユーザＡメモリ領域１２０のウェブページ定義１２２をそのまま使用する。但し、ユーザＡメモリ領域１２０に対象のウェブページ定義１２２が存在しない場合や、ユーザＡメモリ領域１２０に格納されるウェブページ定義１２２の情報が古いと判断される場合、解析部１１９は、ユーザＡメモリ領域１２０のウェブページ定義１２２は使用しないで、標準アプリケーション定義領域１０６中のウェブページ定義１０８を取得しに行く。ユーザＡメモリ領域１２０に格納されるウェブページ定義１２２の情報が古いとの判断は、ユーザＡメモリ領域１２０に格納されているウェブページ定義１２２の更新日付と、標準アプリケーション定義領域１０６、及び利用者アプリケーション定義領域１１０に格納されているウェブページ定義の更新日付を比較することで行い、即ち、ユーザＡメモリ領域１２０に格納されている更新日付の方が古いと判断される場合は、ユーザＡメモリ領域１２０に格納されているウェブページ定義１２２の情報も古いと判断する。

標準アプリケーション定義領域１０６中に古くはない標準アプリケーション定義が見つかった場合は、解析部１１９は、引き続き利用者アプリケーション定義領域１１１（ユーザＡ対応）を参照する。ここで、拡張ウェブページ定義１１２が存在する場合は、マージした結果を内部メモリに格納する。尚、この場合のマージの具体的な処理は、DBの場合と同様に、Main Page〜となっていて存在する情報は上書きし、それ以外の場合は標準のウェブページ定義１０８を使用するものとする。

また、拡張ウェブページ定義１１２が無い場合は、カスタマイズされていないものと見なし、標準ウェブページ定義１０８をそのまま内部メモリに維持する。標準のアプリケーション定義１０６自体が見つからない場合は、利用者が独自に作成した利用者ウェブページ定義１１５である可能性が高いので、利用者アプリケーション定義領域１１０（ユーザＡ対応）から利用者ウェブページ定義１１５を取得し、内部メモリに格納する。何れの場合にも、ウェブページ定義が無い場合は何も行わない。
上記の方法で利用者が要求するウェブページ定義が取得できるので、解析部１１９は、この取得したウェブページ定義で、ユーザＡメモリ領域を更新する。

図７は、標準のウェブページ定義の１構成例を示す説明図である。同図では、標準のウェブページ定義１０８の一部を示している。また、図８は、拡張ウェブページ定義の１構成例を示す説明図である。同図では拡張ウェブページ定義１１２の一部を示している。さらに、図９は、マージ後のウェブページ定義の１構成例を示す説明図である。同図ではマージ後にユーザＡメモリ領域１２０に格納されるウェブページ定義の一部を示している。

尚、利用者ウェブページ定義１１５については、標準のウェブページ定義１０８とほぼ同じであるため、図示は省略する。また、ビジネスロジック定義（１０９，１１３，１１６）、及びデータベース定義（１０７，１１１，１１４）についても、それぞれ同様の構成をとる（マージ前のデータベース定義については図３〜図５を参照）。

更新（即ちカスタマイズ）が行われた後、商談管理アプリケーション１２５のレンダリング部１２１は、ユーザＡメモリ領域１２０から、ウェブページ定義１２２を取得し、HTML形式に変換して参照可能にする。同様に、レンダリング部１２１は、ビジネスロジック定義１２３の場合はプログラムコード、また、データベース定義１２４の場合はデータベーススキーマへと変換し、商談管理アプリケーション１２５に対して提供する。これらの変換機能の実現には、O-Rマッピングツール（データベースを定義ファイルと関連付け、プログラムからアクセスする方法）や、レンダリングエンジンといった既存の機能を利用することも可能である。

図６は、商談管理アプリケーション１２５側から見たリポジトリ管理システム１０１使用時の処理の流れを示すフローチャート図である。
以下、図１を参照し、図６に示すフローチャート図を使用して、商談管理アプリケーション１２５側から見たリポジトリ管理システム１０１使用時の処理の流れを説明する。

（ステップＳ６００）
ステップＳ６００では、ユーザＡ（符号１３０）が、ウェブページ１２９にアクセスする。
（ステップＳ６０１）
ステップＳ６０１では、認証エンジン１１７が、上記アクセスを許可するために、ユーザＡの認証を行い、認証が得られない場合は処理を終了し、認証が得られた場合はステップＳ６０２に進む。
（ステップＳ６０２）
ステップＳ６０２では、解析部１０５が、ユーザＡメモリ領域１２０のウェブページ定義１２２に、対象のウェブページ定義が存在するか否かを検証し、対象のウェブページ定義が存在する場合はステップＳ６０３に移り、対象のウェブページ定義が存在しない場合はステップＳ６０５に進む。

（ステップＳ６０３）
ステップＳ６０３では、解析部１１９が、ユーザＡメモリ領域１２０の更新後にウェブページ定義１２２を更新すべき場合か否か（即ち、ウェブページ定義１２２の情報が古い場合か否か）を検証し、ウェブページ定義１２２を更新すべきでない場合はステップＳ６０４に進み、ウェブページ定義１２２を更新すべき場合はステップＳ６０５に移る。
（ステップＳ６０４）
ステップＳ６０４では、解析部１１９が、ユーザＡメモリ領域１２０のウェブページ定義１２２をそのまま使用することとし、ステップＳ６１６に移る。

（ステップＳ６０５）
ステップＳ６０５では、解析部１１９が、対象のウェブページ定義は標準のウェブページか否かを検証し、対象のウェブページ定義が標準のウェブページである場合はステップＳ６０６に移り、対象のウェブページ定義が標準のウェブページでない場合はステップＳ６０７に進む。

（ステップＳ６０６）
ステップＳ６０６では、解析部１１９が、標準アプリケーション定義領域１０６（ユーザＡ対応）中に拡張ウェブページ定義１１２が存在するか否かを検証し、前記領域に拡張ウェブページ定義１１２が存在する場合はステップＳ６１２に移り、前記領域に拡張ウェブページ定義１１２が存在しない場合はステップＳ６１０に進む。

（ステップＳ６０７）
ステップＳ６０７では、解析部１１９が、対象のウェブページ定義は利用者のウェブページか否かを検証し、対象のウェブページ定義が利用者のウェブページである場合はステップＳ６０８に進み、対象のウェブページ定義が利用者のウェブページでない場合は処理を終了する。
（ステップＳ６０８）
ステップＳ６０８では、解析部１１９が、利用者アプリケーション定義領域１１０（ユーザＡ対応）の利用者ウェブページ定義１１５を取得する。
（ステップＳ６０９）
ステップＳ６０９では、解析部１１９が、前記取得した利用者ウェブページ定義１１５を内部メモリに格納し、ステップＳ６１５に移る。

（ステップＳ６１０）
ステップＳ６１０では、解析部１１９が、標準アプリケーション定義領域１０６から標準のウェブページ定義１０８を取得する。
（ステップＳ６１１）
ステップＳ６１１では、解析部１１９が、前記取得した標準のウェブページ定義１０８を内部メモリに格納し、ステップＳ６１５に移る。

（ステップＳ６１２）
ステップＳ６１２では、解析部１１９が、利用者アプリケーション定義領域１１０（ユーザＡ対応）から、拡張ウェブページ定義１１２を取得する。
（ステップＳ６１３）
ステップＳ６１３では、解析部１１９が、前記取得した拡張ウェブページ定義１１２と、標準のウェブページ定義１０８とをマージする。
（ステップＳ６１４）
ステップＳ６１４では、解析部１１９が、前記マージしたウェブページ定義の各々を内部メモリに格納し、ステップＳ６１５に移る。

（ステップＳ６１５）
ステップＳ６１５では、解析部１１９が、内部メモリに格納されている情報でもって、ユーザＡメモリ領域１２０を更新する。
（ステップＳ６１６）
ステップＳ６１６では、商談管理アプリケーション１２５のレンダリング部１２１が、ユーザＡメモリ領域１２０内のウェブページ定義を基にHTML形式のウェブページ１２９（実体ページ）を作成する。

尚、上記のフローチャート図では、ウェブページ定義をレンダリングするまでの動作を示したが、データベース定義及びビジネスロジック定義をレンダリングする場合も同様である。

本実施形態によれば、標準のアプリケーション定義、拡張されたアプリケーション定義、利用者用のアプリケーション定義の相違箇所は、リポジトリ管理システム１０１において吸収処理されるため、商談管理アプリケーション１２５側では、単一の形式のアプリケーション定義のみを意識したレンダリング部１２１を作成するだけでよい。ユーザＡメモリ領域１２０に存在する単純なアプリケーション定義を基に、アプリケーションを構築するだけで、それぞれの利用者に適合した商談管理アプリケーションが構築され、利用者に提供することができる効果がある。

また、アプリケーションがメンテナンスされる場合、リポジトリ管理システム１０１における標準のアプリケーション定義は、利用者毎のアプリケーション定義から切り離された構成であるため、標準のアプリケーション定義を変更するだけでメンテナンスが可能となる効果がある。即ち、本実施形態によれば、アプリケーションのメンテナンス処理の存在が、利用者カスタマイズに対して影響を与えることもなく、逆に、アプリケーションのメンテナンス処理が、利用者カスタマイズから影響を受けることもない。

本発明は、マルチテナント型として提供されるアプリケーションプログラム全般に適用することが可能であり、とりわけ、利用者毎のカスタマイズ要求が発生するウェブサービス・アプリケーションや、定義情報を基に、データベース、ウェブページ、及びビジネスロジック等が更新されるアプリケーション全般の構築に好適である。

本発明の実施形態に係るアプリケーションプログラムの提供システムを採用したマルチテナント型商談管理アプリケーションの全体構成を示す構成図である。 利用者カスタマイズ機能部１０２の処理の流れを示すフローチャート図である。 データベース定義の１例を示す説明図である。 拡張データベース定義の１例を示す説明図である。 利用者データベース定義１１４の１例を示す説明図である。 商談管理アプリケーション１２５側から見たリポジトリ管理システム１０１使用時の処理の流れを示すフローチャート図である。 標準のウェブページ定義の１構成例を示す説明図である。 拡張ウェブページ定義の１構成例を示す説明図である。 マージ後のウェブページ定義の１構成例を示す説明図である。

符号の説明

１０１…リポジトリ管理システム
１０２…利用者カスタマイズ機能部
１０３…定義更新部
１０４…カスタマイズＵＩ（ユーザインタフェース）
１０５…解析部（利用者カスタマイズ機能部１０２に付属）
１０６…標準アプリケーション定義領域
１０７…データベース定義（標準の定義）
１０８…ウェブページ定義（標準の定義）
１０９…ビジネスロジック定義（標準の定義）
１１０…利用者アプリケーション定義領域（ユーザＡ対応）
１１１…拡張データベース定義
１１２…拡張ウェブページ定義
１１３…拡張ビジネスロジック定義
１１４…利用者データベース定義
１１５…利用者ウェブページ定義
１１６…利用者ビジネスロジック定義
１１７…認証エンジン
１１８…定義情報解析エンジン
１１９…解析部（定義情報解析エンジン１１８に付属）
１２０…ユーザＡメモリ領域
１２１…レンダリング部
１２２…ウェブページ定義（ユーザＡメモリ領域に付属）
１２３…ビジネスロジック定義（ユーザＡメモリ領域に付属）
１２４…データベース定義（ユーザＡメモリ領域に付属）
１２５…商談管理アプリケーション
１２６…業務用データベース
１２７…データベースアクセス用ルーチン（プログラム）
１２８…ビジネスロジック用ルーチン（プログラム）
１２９…ウェブページ（HTML形式）

Claims (6)

1. 同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型アプリケーションを提供するアプリケーションプログラムの提供システムであって、
   標準仕様を定義した標準アプリケーション定義情報と、前記標準アプリケーション定義情報よりも拡張された仕様を定義した拡張アプリケーション定義情報と、前記利用者が定義した利用者アプリケーション定義情報とを格納しているリポジトリ管理領域と、
   前記利用者とのインタフェース手段を備え、前記リポジトリ管理領域に格納されている前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報を、前記利用者の各々が前記インタフェース手段を通じて要求する仕様にカスタマイズさせて更新する手段と、
   前記リポジトリ管理領域に格納されている標準アプリケーション定義情報、前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報に基づいて、前記利用者の各々に提供されるプログラム構成を変更するレンダリング手段を有するアプリケーションプログラム本体と、
   を有することを特徴とするアプリケーションプログラムの提供システム。
2. 前記アプリケーション定義情報は、データベースの仕様を定義するデータベース定義と、ウェブページの仕様を定義するウェブページ定義と、前記アプリケーションプログラムのロジックを定義するロジック定義とを含むことを特徴とする請求項１記載のアプリケーションプログラムの提供システム。
3. 前記リポジトリ管理領域内に、前記利用者の各々に対応してカスタマイズされた定義情報を、前記利用者ごとに格納するキャッシュメモリ領域を設け、前記レンダリング手段は、前記キャッシュメモリ領域に格納された最新の更新日付の定義情報を参照することを特徴とする請求項１または請求項２記載のアプリケーションプログラムの提供システム。
4. 同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型アプリケーションを提供するアプリケーションプログラムの提供用プログラムであって、
   標準仕様を定義した標準アプリケーション定義情報と、前記標準アプリケーション定義情報よりも拡張された仕様を定義した拡張アプリケーション定義情報と、前記利用者が定義した利用者アプリケーション定義情報とを格納している、前記サーバの記憶装置に設けられたリポジトリ管理領域に対してデータの読み書きを行う機能と、
   前記利用者とのインタフェース手段を提供する機能と、
   前記リポジトリ管理領域に格納されている前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報を、前記利用者の各々が前記インタフェース手段を通じて要求する仕様にカスタマイズさせて更新する機能と、
   前記リポジトリ管理領域に格納されている標準アプリケーション定義情報、前記拡張アプリケーション定義情報及び前記利用者アプリケーション定義情報に基づいて、前記利用者の各々に提供されるアプリケーションプログラム本体のプログラム構成を変更するレンダリング機能と
   を前記サーバに実行させることを特徴とするアプリケーションプログラムの提供用プログラム。
5. 前記アプリケーション定義情報は、データベースの仕様を定義するデータベース定義と、ウェブページの仕様を定義するウェブページ定義と、前記アプリケーションプログラムのロジックを定義するロジック定義とを含むことを特徴とする請求項４記載のアプリケーションプログラムの提供用プログラム。
6. 前記リポジトリ管理領域内に、前記利用者の各々に対応してカスタマイズされた定義情報を、前記利用者ごとに格納するキャッシュメモリ領域が設けられており、前記レンダリング機能は、前記キャッシュメモリ領域に格納された最新の更新日付の定義情報を参照することを特徴とする請求項４または請求項５記載のアプリケーションプログラムの提供用プログラム。

Images