(57)【要約】      （修正有）【課題】クラウドサーバからの複数テーブルデータ取得時に、取得件数制限を行う場合、データ取得をユーザの意図したとおりに動作させる。【解決手段】データアクセス部は、フォーム情報管理部からクエリコマンドを取得し（Ｓ１４０１）、クラウドプラットフォームサービスからのデータ取得に特殊なＪＯＩＮ構文での呼び出しが必要かどうか判定し（Ｓ１４０２）、特殊なＪＯＩＮ構文を発行するかどうかを判定し（Ｓ１４０３）、クエリコマンドに定義されたデータ取得件数制限の設定を無効化する（Ｓ１４０４）。取得件数制限部は、フォーム情報管理部からクエリコマンドを取得し（Ｓ１４０１）、取得後のデータに対する件数制限設定を取得し（Ｓ１４０７）、データアクセス部によって取得されたデータに対して件数制限を行う（Ｓ１４０８）。件数制限管理部は、ユーザの指示に従って、クエリコマンドに対して、前記取得後のデータに対する件数制限設定を行う）。【選択図】図１４
2014142733.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末１０１、クラウドプラットフォームサービス１０２および文書生成サーバ１０３がネットワークで接続された文書生成システムであって、以下を含む。
クラウドプラットフォームサービス１０２からのデータ取得に、特殊なＪＯＩＮ構文での呼び出しが必要かどうか判定するデータアクセス部５０４。独自に件数制限を行う取得件数制限部５０７。件数制限設定を保持する件数制限管理部５０８。
データアクセス部５０４は、フォーム情報管理部５０５からクエリコマンド１００６を取得し（Ｓ１４０１）、取得した情報をもとにクラウドプラットフォームサービス１０２からのデータ取得に、特殊なＪＯＩＮ構文での呼び出しが必要かどうか判定し（Ｓ１４０２）、特殊なＪＯＩＮ構文を発行するかどうかを判定し（Ｓ１４０３）、発行する場合、クエリコマンド１００６に定義されたデータ取得件数制限の設定を無効化する（Ｓ１４０４）。
取得件数制限部５０７は、フォーム情報管理部５０５からクエリコマンド１００６を取得し（Ｓ１４０１）、クエリコマンド１００６から取得後のデータに対する件数制限設定を取得し（Ｓ１４０７）、取得した件数制限設定に基づいて、データアクセス部５０４によって取得されたデータに対して件数制限を行う（Ｓ１４０８）。
件数制限管理部５０８は、ユーザの指示に従って、クエリコマンド１００６に対して、前記取得後のデータに対する件数制限設定を行う（Ｓ１３０１）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウド上に保存されたデータをフォームオーバレイして文書を作成するシステムに関し、特に、クラウドサーバ上での文書生成方法に関する。
【背景技術】
【０００２】
近年、サーバーコンピュータ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステムが普及し始めている。ユーザは、クライアントコンピュータのブラウザからインターネットを介してクラウドサーバコンピュータのＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したい業務データを表示する。その画面から文書作成指示を行うと、文書生成サーバにリダイレクトされ、文書生成サーバから返される画面にてフォームオーバレイに使用するフォームをユーザが選択する。そして、文書生成サーバがクラウドサーバ上にあるデータを取得して文書を生成して、文書をブラウザへダウンロードする。クラウドサーバの代表例として、例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社のＳａｌｅｓｆｏｒｃｅ  ＣＲＭ（登録商標）がある。
【０００３】
クラウドサーバからデータを取得する際には、専用のクエリ言語が使用される。例えば、Ｓａｌｅｓｆｏｒｃｅ  ＣＲＭの場合、ＳＯＱＬというＳＱＬに類似した構文のクエリ言語を用いてデータを取得する。ＳＯＱＬでは後述するマルチテナントの考え方が考慮されており、例えば一度に取得できるデータ件数に制約がある等、ＳＱＬで可能な処理が出来ない場合も多い。
【０００４】
文書生成サーバは、クラウドサーバから取得したデータを様々に加工して文書上に表現する。例えば、クラウドサーバのデータベースに定義された複数のテーブルのデータを、１つの表に流し込んで文書を生成する。
【０００５】
このように、クラウドサーバから取得したデータを文書上に表現する場合、各クラウドサーバが定義する取得用のクエリ言語に従ってデータを取得する必要がある。従来、前記クエリ言語は専用のエディタを使ってユーザに設定させ、クエリコマンドとして保持する技術が存在する（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−２１５８２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
クラウドサーバや文書生成サーバは、複数の企業・組織から使用されることが前提である（一般的にマルチテナントと呼ばれる）。このため、一部の企業・組織によって各サーバのリソースが占有される状況は好ましくない。リソースの占有を防ぐため、従来技術では、特にクラウドサーバからのデータ取得に制約があった。Ｓａｌｅｓｆｏｒｃｅ  ＣＲＭの場合、前記ＳＯＱＬの構文に制限を持たせることでデータ取得時の負荷を軽減している。例えば、クラウドサーバ上に定義された複数のテーブルのデータを取得したい場合、通常のデータベースにおけるＳＱＬであればＪＯＩＮ構文を用いて複数テーブルのデータを１つにまとめて取得する。ＪＯＩＮ構文は、複数テーブル同士の結び付けを自由に定義できるためサーバ側で動的に結びつけを処理する必要があり、サーバ負荷が大きい。このため、ＳＯＱＬではＪＯＩＮ構文を許可していない。ＳＯＱＬでは、テーブル同士の結び付けをあらかじめ項目の種別として定義し（参照項目または主従項目）、その種別で結び付けられたテーブル同士のみが取得できる限定的なＪＯＩＮ構文を用意している（Ｐａｒｅｎｔ−Ｃｈｉｌｄ  Ｒｅｌａｔｉｏｎｓｈｉｐ構文）。Ｐａｒｅｎｔ−Ｃｈｉｌｄ  Ｒｅｌａｔｉｏｎｓｈｉｐ構文の一例を以下に挙げる。
【０００８】
Ｓｅｌｅｃｔ  Ｎａｍｅ，  （Ｓｅｌｅｃｔ  Ｎａｍｅ，  Ｕｒｉａｇｅ  Ｆｒｏｍ  Ｔｅｎｐｏ）  Ｆｒｏｍ  Ｔｏｄｏｆｕｋｅｎ
Ｔｏｄｏｆｕｋｅｎテーブルから都道府県名（Ｎａｍｅ）を、Ｔｏｄｏｆｕｋｅｎテーブルと結びつくＴｅｎｐｏテーブルから店舗名（Ｎａｍｅ）および売り上げ（Ｕｒｉａｇｅ）データを取得するＳＯＱＬ構文である。このＳＯＱＬを実行すると各店舗の所在地（都道府県名）と売り上げデータを一覧で取得できる。
【０００９】
マルチテナントの観点から、ＳＯＱＬには上記のような制限がある。従来、この制限下でデータの取得件数制限構文（Ｌｉｍｉｔ構文）を組み合わせると、データの取得がユーザの意図した動作にならない場合があるという問題があった。例えば、先ほどのＴｏｄｏｆｕｋｅｎおよびＴｅｎｐｏテーブルからのデータ取得時、取得する件数を売り上げ上位１０件に絞り込みたいとする。この場合、ＳＯＱＬでは下記の構文でクエリを行う。
【００１０】
Ｓｅｌｅｃｔ  Ｎａｍｅ，  （Ｓｅｌｅｃｔ  Ｎａｍｅ，  Ｕｒｉａｇｅ  Ｆｒｏｍ  Ｔｅｎｐｏ  Ｌｉｍｉｔ  １０）  Ｆｒｏｍ  Ｔｏｄｏｆｕｋｅｎ  Ｌｉｍｉｔ  １０
Ｐａｒｅｎｔ−Ｃｈｉｌｄ  Ｒｅｌａｔｉｏｎｓｈｉｐ構文では結びつくそれぞれのテーブルを複数のＳｅｌｅｃｔ句でクエリするが、Ｌｉｍｉｔ構文を組み合わせる場合、それぞれのＳｅｌｅｃｔ句に対してのみ指定が可能となる。このため、Ｌｉｍｉｔ構文で取得件数を制限できるのは、Ｔｏｄｏｆｕｋｅｎテーブル、Ｔｅｎｐｏテーブルそれぞれであって、データを結びつけた（Ｊｏｉｎした）後の結果に対する件数制限ではない。この結果、Ｔｏｄｏｆｕｋｅｎテーブルのデータが１０件に絞られてしまうことにより、本来売り上げ上位１０件に入っている都道府県データが削除され、上位１０件のデータを取得できないということが起こりえる。また、ＴｏｄｏｆｕｋｅｎおよびＴｅｎｐｏテーブルそれぞれの取得件数は１０件に制限されるが、各テーブルを結び付けて一覧取得した場合の件数は、１０件を超えることが起こりえる（例えば１都道府県に店舗が２店以上ある場合）。この点でもユーザが本来意図する１０件の制限という動作を実現することができない。
【課題を解決するための手段】
【００１１】
クライアント端末１０１、クラウドプラットフォームサービス１０２および文書生成サーバ１０３がネットワークで接続された文書生成システムであって、以下を含む。
【００１２】
クラウドプラットフォームサービス１０２からのデータ取得に、特殊なＪＯＩＮ構文での呼び出しが必要かどうか判定するデータアクセス部５０４。独自に件数制限を行う取得件数制限部５０７。件数制限設定を保持する件数制限管理部５０８。
【００１３】
データアクセス部５０４は、フォーム情報管理部５０５からクエリコマンド１００６を取得し（Ｓ１４０１）、取得した情報をもとにクラウドプラットフォームサービス１０２からのデータ取得に、特殊なＪＯＩＮ構文での呼び出しが必要かどうか判定し（Ｓ１４０２）、特殊なＪＯＩＮ構文を発行するかどうかを判定し（Ｓ１４０３）、発行する場合、クエリコマンド１００６に定義されたデータ取得件数制限の設定を無効化する（Ｓ１４０４）。
【００１４】
取得件数制限部５０７は、フォーム情報管理部５０５からクエリコマンド１００６を取得し（Ｓ１４０１）、クエリコマンド１００６から取得後のデータに対する件数制限設定を取得し（Ｓ１４０７）、取得した件数制限設定に基づいて、データアクセス部５０４によって取得されたデータに対して件数制限を行う（Ｓ１４０８）。
【００１５】
件数制限管理部５０８は、ユーザの指示に従って、クエリコマンド１００６に対して、前記取得後のデータに対する件数制限設定を行う（Ｓ１３０１）。
【発明の効果】
【００１６】
本発明によれば、クラウドサーバからの複数テーブルデータ取得時に、データの取得件数制限を行う場合でも、データ取得をユーザの意図したとおりに動作させることができる。
【図面の簡単な説明】
【００１７】
【図１】システム構成を示すブロック図である。
【図２】ハードウェア構成を示す図である。
【図３】文書生成システムの全体構成を示す図である。
【図４】クラウドプラットフォームサービスのソフトウェアモジュール構成図である。
【図５】Ｗｅｂサーバのソフトウェアモジュール構成図である。
【図６】文書生成サービスのソフトウェアモジュール構成図である。
【図７】クラウドプラットフォームサービスの業務画面例である。
【図８】クラウドプラットフォームサービスの業務データのテーブル構造例である。
【図９】クラウドプラットフォームサービスのカスタムボタンの定義情報例である。
【図１０】フォーム情報テーブルのテーブル構造を示す図である。
【図１１】Ｗｅｂブラウザで表示する画面フローを示した図である。
【図１２】実施例１における文書生成システムが行う処理シーケンスを示す図である。
【図１３】実施例１におけるＷｅｂサーバの件数制限設定保存処理を示すフローチャートである。
【図１４】実施例１におけるＷｅｂサーバの文書生成処理を示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１９】
図１は、本発明の実施例のシステム構成を示すブロック図である。
【００２０】
図中、１０１は、後述するクラウドプラットフォームサービス１０２および後述する文書生成サーバ１０３に対してリクエストを発行するクライアント装置１０１である。図中、１０２はクラウドプラットフォームサービス１０２であり、クライアント装置１０１や文書生成サーバ１０３からのリクエストに応じて、保持するデータの表示・更新等を行う。図中、１０３は、文書生成サーバ１０３であり、クライアント装置１０１からリクエストを受信して文書生成を行う。
【００２１】
また、上記各構成要素はネットワーク１００により通信可能に接続されている。ネットワークは、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれである。また、これらの組み合わせにより実現される、いわゆる通信ネットワークである。
【００２２】
ネットワークはデータの送受信が可能であればよい。
【００２３】
クライアント装置１０１からクラウドプラットフォームサービス１０２、文書生成サービス１０３への通信手段、文書生成サーバ１０３からクラウドプラットフォームサービス１０２への通信手段、及び各サーバ間の通信手段が異なっていてもよい。
【００２４】
図２は、図１のクライアント装置１０１、クラウドプラットフォームサービス１０２、文書生成サーバ１０３のハードウェア構成を示すブロック図である。図中、２０１は内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するＣＰＵである。２０２はＢＩＯＳが格納してあるＲＯＭである。２０３はＣＰＵ２０１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりするＲＡＭ（直接記憶装置）である。２０４は基本ソフトウェアであるＯＳやソフトウェアモジュールが記憶されているＨＤＤ（ハードディスクドライブ）、もしくはＳＳＤ（ソリッドステートドライブ）などの間接記憶装置である。２０５は入力装置であり不図示のキーボードやポインティングデバイスなどである。２０６は出力装置でありディスプレイが接続される。２０７はネットワーク１００に接続するためのＩ／Ｆである。
【００２５】
これらハードウェアでは、起動後ＣＰＵ２０１によりＢＩＯＳが実行されＯＳがＨＤＤ２０４からＲＡＭ２０３に実行可能にロードされる。ＣＰＵ２０１はＯＳの動作に従って後述する各種ソフトウェアモジュールをＨＤＤ２０４からＲＡＭ２０３に随時、実行可能にロードする。各種ソフトウェアモジュールは上記各デバイスの協調によりＣＰＵ２０１によって実行され動作する。また、Ｉ／Ｆ２０７はネットワーク１００に接続されており、ＯＳの動作に従ってＣＰＵ２０１により制御され、上述した通信手段による通信を実現している。
【００２６】
図３は、本発明の実施の形態に係る文書生成システムの全体構成を示す図である。
【００２７】
図中、クライアント装置１０１はユーザインタフェースアプリケーションとしてＷｅｂブラウザ３０１を備えている。
【００２８】
クラウドプラットフォームサービス１０２は、クラウドプラットフォームサービスを使用するユーザの管理や、業務データ、後述する文書生成サーバ１０３へのリダイレクトを行うための設定を管理する。
【００２９】
また、クラウドプラットフォームサービス１０２は、マルチテナントが前提であり、使用する企業・組織毎に前述のユーザ管理、業務データ管理等が行われる。
文書生成サーバ１０３は、Ｗｅｂサーバ３０３、および、文書生成サービス３０４を備える。
【００３０】
Ｗｅｂサーバ３０３はいわゆるＷｅｂアプリケーションの機能を有するよう構成されており、クライアント１０１はＷｅｂブラウザ３０１を介してアクセスする事が出来る。
【００３１】
Ｗｅｂサーバ３０３はＷｅｂブラウザ３０１からのリクエストに対してユーザインタフェース情報を返答する。Ｗｅｂブラウザ３０１はＷｅｂサーバ３０３から得られたユーザインタフェース情報をレンダリングし表示する。
【００３２】
表示されたユーザインタフェース情報には、たとえば、後述する文書生成サーバ１０３が管理するフォームの一覧や、文書生成をリクエストするためのインタフェース等が含まれている。
【００３３】
また、Ｗｅｂサーバ３０３はＷｅｂブラウザ３０１から文書生成リクエストを受信すると、クラウドプラットフォームサービス１０２から業務データを取得し、該業務データとともに文書生成サービス３０４に対して文書生成のリクエストを送信する。
【００３４】
文書生成サービス３０４は、受信したデータと自身で管理するフォームおよびクエリコマンドを使用してオーバレイ処理を行い、文書データを生成する。クエリコマンドには、クラウドプラットフォームサービス１０２からの業務データ取得方法等が設定されている。
【００３５】
図４は、クラウドプラットフォームサービス１０２上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。
【００３６】
クラウドプラットフォームサービス１０２は以下で構成される。
【００３７】
クライアント装置１０１のＷｅｂブラウザ３０１や文書生成サーバ１０３のＷｅｂサーバ３０３との通信を処理する送受信部４０１。
【００３８】
送受信部４０１が受け付けたリクエストに従って処理を実行する制御部４０２。
Ｗｅｂブラウザ３０１にレスポンスを返すためのＷｅｂページを生成するページ生成部４０３。
【００３９】
ログイン要求してきたユーザを認証する認証部４０５。
【００４０】
認証部４０５にて認証に成功したユーザのセッション情報を管理するセッション管理部４０４。
【００４１】
業務データをＤＢ４０８に保持し要求に応じてＤＢ４０８から業務データの取得、あるいは業務データの更新を行うデータ管理部４０６。
【００４２】
文書生成サーバ１０３へのリダイレクトを行うための設定を保持する設定管理部４０７である。
【００４３】
クラウドプラットフォームサービス１０２はこれら各構成要素の協調により、後述する処理を実行する。
【００４４】
また、図中、４０８は管理ユーザデータや業務データを格納するＤＢ４０８であり、図２で示したＨＤＤ２０４に記憶されている。
【００４５】
管理ユーザデータや業務データは、企業・組織（以降、組織と表記）毎に管理される。各組織には組織ＩＤが自動的に割り当てられ、組織ＩＤとともに各データが管理される。ユーザ認証時、ユーザが所属する組織の組織ＩＤを取得しセッション管理部４０４に保存する。以降のデータ取得等の処理は組織ＩＤをもとに行われ、組織ＩＤの一致するデータのみを参照することが可能となっている。
【００４６】
また、ＤＢ４０８には、文書生成サーバ１０３へのリダイレクトを行うための設定も格納される。ＤＢ４０８に格納された業務データや文書生成サーバ１０３へリダイレクトを行うための設定は、Ｗｅｂブラウザ３０１を介して、ユーザ（管理者）により任意のタイミングで設定更新が行われる。
【００４７】
図５は、文書生成サーバ１０３のＷｅｂサーバ３０３上で動作するソフトウェアモジュールの構成図である。
【００４８】
なお各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。
【００４９】
Ｗｅｂサーバ３０３は以下で構成される。
【００５０】
クライアント装置１０１のＷｅｂブラウザ３０１やクラウドプラットフォームサービス１０２、文書生成サービス３０４との通信を処理する送受信部５０１。受け付けたリクエストに従って処理を実行する制御部５０２。Ｗｅｂブラウザ３０１にレスポンスを返すためのＷｅｂページを生成するページ生成部５０３。クラウドプラットフォームサービス１０２にアクセスして業務データを取得するデータアクセス部５０４。後述のフォーム情報テーブルを管理するフォーム情報管理部５０５。Ｗｅｂブラウザ３０１のセッション情報を管理するセッション管理部５０６。データアクセス部５０４が取得した業務データに対して、取得件数の制限を行う取得件数制限部５０７。取得件数の制限設定を管理する取得制限管理部５０８である。Ｗｅｂサーバ３０３はこれら各構成要素の協調により、後述する処理を実行する。
【００５１】
図６は、文書生成サーバ１０３の文書生成サービス３０４上で動作するソフトウェアモジュールの構成図である。
【００５２】
なお各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。
【００５３】
文書生成サービス３０４は以下で構成される。
【００５４】
Ｗｅｂサーバ３０３からの文書生成リクエストを受け付ける要求受信部６０１。受け付けたリクエストに従って処理を実行する制御部６０２。フォームデータを管理するフォーム管理部６０３。Ｗｅｂサーバ３０３から送信された業務データとフォームを使用してオーバレイ処理を行い、文書データを生成する文書生成部６０４。生成された文書データをＷｅｂサーバ３０３またはクライアント端末１０１に送信する文書送信部６０５である。
【００５５】
図７は、クライアント装置１０１のＷｅｂブラウザ３０１から、クラウドプラットフォームサービス１０２にアクセスして業務データを表示した場合の業務画面７０１の例である。なお、図７は、ユーザがクラウドプラットフォームサービス１０２にログイン済の状態である。業務画面７０１は、あるレコードの詳細情報７０２や商品７０３が表示されている。図７では、商談に関する業務画面の商談レコードの詳細を表示している。また、文書生成サーバ１０３へリダイレクトを行うための設定がなされたカスタムボタン７０４が表示されている。カスタムボタン７０４は、ボタン押下時の動作や、どの画面に表示するか、等を任意に設定可能で、ユーザ（管理者）によって画面に配置される。
【００５６】
図８は、クラウドプラットフォームサービス１０２のデータ管理部４０６が保持する業務データのうち、商談に関するデータのテーブル構造例を示す図である。
【００５７】
業務データはデータテーブル８００で管理され、商談テーブル８０１、および、商品テーブル８１１によって構成されている。
【００５８】
商談テーブル８０１は、レコードの識別子であるレコードＩＤ８０２、レコードをユーザが容易に区別するために任意の名前を設定可能な商談名８０３で構成される。
【００５９】
商品テーブル８１１は、商談レコードＩＤ８１２、商品テーブルのレコードの識別子であるレコードＩＤ８１３、品名８１４、数量８１５、価格８１６から構成される。また、商談レコードＩＤ８１２は、商談テーブルのレコードＩＤ８０２とリレーションしている。
【００６０】
図９は、クラウドプラットフォームサービス１０２の設定管理部４０７で保持するカスタムボタンの定義情報の例を示す図である。
【００６１】
図９では、カスタムボタンが「商談」画面と「顧客」画面に定義されており、「商談」画面に表示するカスタムボタンの設定情報には、ボタン表示名９０３、および、文書生成サーバ１０３へリダイレクトを行うためのパラメータ情報が格納されている。
【００６２】
文書生成サーバＵＲＩ９０４は、文書生成サーバ１０３のＵＲＩを「ｈｔｔｐ：／／〜」の形式で指定したパラメータである。セッションＩＤ９０５は、ログインしたユーザのセッションＩＤを取得して文字列「ｓｉｄ＝＜セッションＩＤ＞」をＵＲＬパラメータに付加する設定である。ＣＰＳＵＲＬ９０６は、文書生成サーバ１０３がクラウドプラットフォームサービス１０２にアクセスするためのＵＲＬを文字列「ｓｒｖ＿ｕｒｌ＝＜クラウドプラットフォームサービスＵＲＬ＞」としてＵＲＬパラメータに付加する設定である。
【００６３】
クラウドプラットフォームサービス１０２にアクセスするためのＵＲＬは組織毎に固有であり、ユーザ認証時に、制御部５０２が、ユーザが所属する組織に応じたＵＲＬを取得してセッション管理部４０４に保存する。
【００６４】
組織ＩＤ９０７は、ログインしたユーザの組織ＩＤを取得して文字列「ｏｒｇｉｄ＝＜組織ＩＤ＞」をＵＲＬパラメータに付加する設定である。レコードＩＤ９０８は、画面に表示した商談レコードのレコードＩＤ１２０２を取得して文字列「ｒｅｃｉｄ＝＜レコードＩＤ＞」をＵＲＬパラメータに付加する設定である。
【００６５】
図１０は、Ｗｅｂサーバ３０３のフォーム情報管理部５０５が保持するフォーム情報テーブルのテーブル構造を示す図である。
【００６６】
フォーム情報テーブル１００１のフォーム情報レコードは、以下で構成される。
該レコードの所有者である組織を識別する組織ＩＤ１００３。フォーム選択画面に表示する名称である表示名１００４。文書生成サービス３０４のフォーム管理部６０３で管理されているフォームのファイル名であるフォームファイル名１００５。クラウドプラットフォームサービス１０２からデータを取得するためのクエリを記述したクエリコマンド１００６。フォームファイル内に定義されている固定的なデータに関する情報であるフォーム情報１０７。
【００６７】
図１１は、図１の文書生成システムにおけるクライアント装置１０１のＷｅｂブラウザ３０３で表示する画面のフローを示した図である。
【００６８】
なお、以降の図では、クラウドプラットフォームサービスをＣＰＳと略して表記している。
【００６９】
業務画面１１０１は、クラウドプラットフォームサービス１０２が作成し、クライアント装置１０１に返す画面であり、例えば、図７の業務画面７０１が表示される。
【００７０】
文書生成ボタン１１０２は、クラウドプラットフォームサービス１０２へ文書生成リクエストを発行するボタンである。
【００７１】
クラウドプラットフォームサービス１０２は文書生成ボタン１１０２が押下されると、文書生成サーバ１０３へリダイレクトするＵＲＬを返却する。
【００７２】
クライアント装置１０１のＷｅｂブラウザ３０１は、リダイレクトするＵＲＬを受けるとこのＵＲＬに従った文書生成サーバ１０３へリダイレクトする。
【００７３】
リダイレクトでリクエストを受けた文書生成サーバ１０３は、フォーム選択画面１１０３をクライアント装置１０１のＷｅｂブラウザ３０１に返す。
【００７４】
フォーム選択画面１１０３は文書生成に使用するフォームを選択するフォーム選択１１０４を備える。
【００７５】
また、ユーザから文書作成ボタン１１０５の選択を受けたクライアント装置１０１のＷｅｂブラウザ３０１は、フォーム選択１１０４の選択結果を文書生成サーバ１０３に送信する。これらの情報を受け取った文書生成サーバ１０３は、業務画面１１０１の業務データをクラウドプラットフォームサービス１０２から取得する。データ取得中画面１１０６は、文書生成サーバ１０３がクラウドプラットフォームサービス１０３から業務データを取得中の間クライアント装置１０１のＷｅｂブラウザ３０１に表示される。文書生成サーバ１０３がクラウドプラットフォームサービス１０３からの業務データ取得が完了すると、文書生成サーバ１０３は取得したデータを確認可能なデータ確認画面１１０７をクライアント装置１０１のＷｅｂブラウザ３０１に返す。ユーザから作成ボタン１１０８の選択を受けたクライアント装置１０１のＷｅｂブラウザ３０１は、文書生成サーバ１０３に文書生成リクエストを送信する。文書生成リクエストを受けた文書生成サーバ１０３は、選択されたフォームとクラウドプラットフォームサービス１０３から取得した業務データを使用して文書生成処理を行う。文書生成処理の間、クライアント装置１０２のＷｅｂブラウザ３０１は、作成中画面１１０９を表示する。文書の作成が完了すると、クライアント端末１０１のＷｅｂブラウザ３０１は完了画面１１１０を表示する。
【００７６】
図１２は、本発明の実施例１における文書生成システムが行う処理の流れを示している。なお、ユーザは不図示のログイン画面にてクラウドプラットフォームサービス１０２にログイン済とし、Ｗｅｂブラウザ３０１には図７の業務画面７０１が表示されており、カスタムボタン７０４は、予め、図９の設定がなされているものとする。
【００７７】
はじめ、ユーザによりクライアント装置１０１のＷｅｂブラウザ３０１に表示された業務画面７０１のカスタムボタン７０４が押下される（Ｓ１２０１）と、クラウドプラットフォームサービス１０２では、Ｓ１２０２においてリダイレクトＵＲＬ作成処理を行う。
【００７８】
Ｓ１２０２において、制御部４０２はカスタムボタンに設定された文書生成サーバＵＲＩ９０４、セッションＩＤ９０５、ＣＰＳＵＲＬ９０６、組織ＩＤ９０７およびレコードＩＤ９０８を取得し、これら取得したパラメータからリダイレクトＵＲＬを生成する。そして、リダイレクトさせるためのレスポンスをＷｅｂブラウザ３０１に返す。
Ｓ１２０３で、Ｗｅｂブラウザ３０１はクラウドプラットフォームサービス１０２から返されたレスポンスを受信すると、セッションＩＤ９０５、ＣＰＳＵＲＬ９０６、組織ＩＤ９０７、レコードＩＤ９０８を文書生成サーバ１０３に送信する。
【００７９】
Ｓ１２０４で、Ｗｅｂサーバ３０３はＷｅｂブラウザ３０１からのリダイレクトを受信すると、まず制御部５０２は、セッションＩＤ９０５、ＣＰＳＵＲＬ９０６、組織ＩＤ９０７およびレコードＩＤ９０８をセッション管理部５０６に保存する。
【００８０】
次に、制御部５０２はフォーム情報レコード１００２に含まれるフォームの表示名１００４のリストをフォーム情報管理部５０５から取得し、フォームの表示名１００４のリストからフォーム選択画面１１０３を作成、クライアント端末１０１に送る。
【００８１】
Ｓ１２０５では、ユーザによりフォーム選択画面１１０３のフォーム１１０４が選択され、文書作成ボタン１１０５が押下されると、Ｗｅｂサーバ３０３に対して選択フォーム１１０４とともに文書生成リクエストが送信される。
【００８２】
Ｓ１２０６にてＷｅｂサーバ３０３が文書生成リクエストを受信すると、文書生成サービス１０３は選択フォーム１１０４で指定されたフォームに一致するクエリコマンド１００６を発行し、クラウドプラットフォームサービス１０２にデータ取得リクエストを行う。
【００８３】
その際、クラウドプラットフォームサービス１０２のＵＲＬおよび取得データの内容は、セッション管理部５０６に保存されているＣＰＳＵＲＬ９０５および組織ＩＤ９０７、レコードＩＤ９０８をそれぞれ使用する。次に、Ｓ１２０７において文書生成サーバ１０３は、データ取得中画面１１０６を作成し、Ｗｅｂブラウザ３０１に送る。
【００８４】
Ｗｅｂブラウザ３０１は定期的にＳ１２０８でデータ取得完了確認リクエストを文書生成サーバ１０３に送信する。文書生成サーバ１０３のＷｅｂサーバ３０３は、クラウドプラットフォームサービス０２からデータ取得のレスポンスが返るまでは、Ｓ１２０７と同様のデータ取得中画面１１０６をＷｅｂブラウザ３０１に送る。
【００８５】
次に、クラウドプラットフォームサービス１０２からデータ取得のレスポンスが文書生成サーバ１０３に返る。
【００８６】
Ｗｅｂサーバ３０３の制御部５０２は、取得データをセッション管理部５０６へ保存する。
【００８７】
その後にＷｅｂブラウザ３０１からデータ取得完了の確認リクエストが送られてくると、Ｗｅｂサーバ３０３はクラウドプラットフォームサービス１０２から取得したデータでデータ確認画面１１０７を生成し、Ｗｅｂブラウザ３０１へ返す（Ｓ１２０９）。
【００８８】
Ｓ１２０９においてＷｅｂブラウザ３０１に返された取得データ確認画面１１０７にて、ユーザにより作成ボタン１１０８が押下されると、Ｗｅｂブラウザ３０１より、Ｗｅｂサーバ３０３に対して、文書生成リクエストが送信される（Ｓ１２１０）。
【００８９】
Ｓ１２１０において、Ｗｅｂサーバ３０３が文書生成リクエストを受信すると、後述の文書生成処理を行う。
【００９０】
図１３は、本発明におけるＷｅｂサーバ３０３の件数制限設定保存処理を示すフローチャートである。
【００９１】
ステップＳ１３０１で件数制限管理部５０８は、ユーザの指示に従って、クエリコマンド１００６に対して、ステップＳ１４０７で後述する取得後のデータに対する件数制限設定を保存する。ユーザは、件数制限管理部５０８が提供する不図示のＵＩを操作して、件数制限設定値（例えば１０等）を指定する。なお、取得後のデータに対する件数制限設定を保持したクエリコマンド１００６がフォーム情報管理部５０５で管理されてさえいればよい。このため、件数制限管理部５０８はＷｅｂサーバ３０３に属している必要はない。例えば、別のサーバはクライアント装置１０１に属していても構わない。
【００９２】
図１４は、本発明におけるＷｅｂサーバ３０３の文書生成処理を示すフローチャートである。
【００９３】
ステップＳ１４０１でデータアクセス部５０４は、ユーザからの指定に基づいて、フォーム情報管理部５０５から該当のクエリコマンド１００６を取得する。
【００９４】
ステップＳ１４０２でデータアクセス部５０４は、ステップＳ１４０１で取得したクエリコマンド１００６を解析してクラウドプラットフォームサービス１０２からのデータ取得に特殊なＪＯＩＮ構文での呼び出しが必要かどうかを判定する。例えば、Ｓａｌｅｓｆｏｒｃｅ  ＣＲＭの場合、データ取得にはＳＯＱＬを使用する必要があり、通常のＳＱＬでのＪＯＩＮ構文が使用できないため特殊なＪＯＩＮ構文が必要と判定する。特殊なＪＯＩＮ構文呼び出しが必要と判定した場合にはステップＳ１４０３に遷移し、不要と判定した場合にはステップＳ１４０５に遷移する。
【００９５】
ステップＳ１４０３でデータアクセス部５０４は、データ取得のために特殊なＪＯＩＮ構文を発行するかどうかを判定する。例えば、取得するデータが１つのテーブルに格納されている場合には、ＪＯＩＮする必要がないのでＪＯＩＮ構文を発行しない。ＪＯＩＮ構文を発行すると判定された場合にはステップＳ１４０４に遷移し、発行しないと判定された場合にはステップＳ１４０５に遷移する。
【００９６】
ステップＳ１４０４でデータアクセス部５０４は、ステップＳ１４０１で取得したクエリコマンド１００６にデータ取得件数制限の設定があるかどうかを検出し、ある場合その設定を無効化したクエリ文字列を生成する。例えば、クエリコマンド１００６にテーブルＡからのデータ取得に対して１０件以上取得しない設定（Ｌｉｍｉｔ  １０）がなされていた場合、「Ｌｉｍｉｔ  １０」という構文を取り除いたクエリ文字列を生成する。
【００９７】
ステップＳ１４０５でデータアクセス部５０４は、通常のクエリ文字列もしくはステップＳ１４０４で生成したクエリ文字列を使用して、クラウドプラットフォームサービス１０２からのデータ取得を行う。
【００９８】
ステップＳ１４０６で取得件数制限部５０７は、独自に取得件数制限を行う必要があるかどうかを決定するため、ステップＳ１４０４でＬｉｍｉｔ構文を取り除いたクエリ文字列を生成したかどうかを判定する。生成した場合ステップＳ１４０７に遷移し、生成していない場合本フローを終了する。
【００９９】
ステップＳ１４０７で取得件数制限部５０７は、クエリコマンド１００６から、取得後のデータに対する件数制限設定を取得する。取得後のデータに対する件数制限設定（以降、取得後データ件数制限設定）は、結び付けられた複数のテーブルを結合（ＪＯＩＮ）した後のデータに対する件数制限設定である。例えば、
Ｓｅｌｅｃｔ  Ｎａｍｅ，  （Ｓｅｌｅｃｔ  Ｎａｍｅ，  Ｕｒｉａｇｅ  Ｆｒｏｍ  Ｔｅｎｐｏ）  Ｆｒｏｍ  Ｔｏｄｏｆｕｋｅｎ
上記のようなＳＯＱＬを発行して得られたデータが１００件だったとしても、取得後データ件数制限設定が「１０」となっていれば、取得されるデータは１０件となる。
【０１００】
ステップＳ１４０８で取得件数制限部５０７は、ステップＳ１４０７で取得した、取得後データ件数制限設定に基づいて、取得されたデータに対して件数制限を行う。
【０１０１】
以上でＷｅｂサーバ３０３の文書生成処理を示すフローチャートが完了する。
【符号の説明】
【０１０２】
１０１  クライアント装置
１０２  クラウドプラットフォームサービス
１０３  文書生成サーバ
３０１  Ｗｅｂブラウザ
３０３  Ｗｅｂサーバ
３０４  文書生成サービス
５０２  制御部
５０３  ページ生成部
【図１】
2014142733.tif 000003
【図２】
2014142733.tif 000004
【図３】
2014142733.tif 000005
【図４】
2014142733.tif 000006
【図５】
2014142733.tif 000007
【図６】
2014142733.tif 000008
【図７】
2014142733.tif 000009
【図８】
2014142733.tif 000010
【図９】
2014142733.tif 000011
【図１０】
2014142733.tif 000012
【図１１】
2014142733.tif 000013
【図１２】
2014142733.tif 000014
【図１３】
2014142733.tif 000015
【図１４】
2014142733.tif 000016