JP2014142733A - 文書生成システム - Google Patents
文書生成システム Download PDFInfo
- Publication number
- JP2014142733A JP2014142733A JP2013009760A JP2013009760A JP2014142733A JP 2014142733 A JP2014142733 A JP 2014142733A JP 2013009760 A JP2013009760 A JP 2013009760A JP 2013009760 A JP2013009760 A JP 2013009760A JP 2014142733 A JP2014142733 A JP 2014142733A
- Authority
- JP
- Japan
- Prior art keywords
- data
- document generation
- acquisition
- cloud platform
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】クラウドサーバからの複数テーブルデータ取得時に、取得件数制限を行う場合、データ取得をユーザの意図したとおりに動作させる。
【解決手段】データアクセス部は、フォーム情報管理部からクエリコマンドを取得し(S1401)、クラウドプラットフォームサービスからのデータ取得に特殊なJOIN構文での呼び出しが必要かどうか判定し(S1402)、特殊なJOIN構文を発行するかどうかを判定し(S1403)、クエリコマンドに定義されたデータ取得件数制限の設定を無効化する(S1404)。取得件数制限部は、フォーム情報管理部からクエリコマンドを取得し(S1401)、取得後のデータに対する件数制限設定を取得し(S1407)、データアクセス部によって取得されたデータに対して件数制限を行う(S1408)。件数制限管理部は、ユーザの指示に従って、クエリコマンドに対して、前記取得後のデータに対する件数制限設定を行う)。
【選択図】図14
【解決手段】データアクセス部は、フォーム情報管理部からクエリコマンドを取得し(S1401)、クラウドプラットフォームサービスからのデータ取得に特殊なJOIN構文での呼び出しが必要かどうか判定し(S1402)、特殊なJOIN構文を発行するかどうかを判定し(S1403)、クエリコマンドに定義されたデータ取得件数制限の設定を無効化する(S1404)。取得件数制限部は、フォーム情報管理部からクエリコマンドを取得し(S1401)、取得後のデータに対する件数制限設定を取得し(S1407)、データアクセス部によって取得されたデータに対して件数制限を行う(S1408)。件数制限管理部は、ユーザの指示に従って、クエリコマンドに対して、前記取得後のデータに対する件数制限設定を行う)。
【選択図】図14
Description
本発明は、クラウド上に保存されたデータをフォームオーバレイして文書を作成するシステムに関し、特に、クラウドサーバ上での文書生成方法に関する。
近年、サーバーコンピュータ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステムが普及し始めている。ユーザは、クライアントコンピュータのブラウザからインターネットを介してクラウドサーバコンピュータのWebページにアクセスし、そのWebページ上で閲覧したい業務データを表示する。その画面から文書作成指示を行うと、文書生成サーバにリダイレクトされ、文書生成サーバから返される画面にてフォームオーバレイに使用するフォームをユーザが選択する。そして、文書生成サーバがクラウドサーバ上にあるデータを取得して文書を生成して、文書をブラウザへダウンロードする。クラウドサーバの代表例として、例えば、Salesforce.com社のSalesforce CRM(登録商標)がある。
クラウドサーバからデータを取得する際には、専用のクエリ言語が使用される。例えば、Salesforce CRMの場合、SOQLというSQLに類似した構文のクエリ言語を用いてデータを取得する。SOQLでは後述するマルチテナントの考え方が考慮されており、例えば一度に取得できるデータ件数に制約がある等、SQLで可能な処理が出来ない場合も多い。
文書生成サーバは、クラウドサーバから取得したデータを様々に加工して文書上に表現する。例えば、クラウドサーバのデータベースに定義された複数のテーブルのデータを、1つの表に流し込んで文書を生成する。
このように、クラウドサーバから取得したデータを文書上に表現する場合、各クラウドサーバが定義する取得用のクエリ言語に従ってデータを取得する必要がある。従来、前記クエリ言語は専用のエディタを使ってユーザに設定させ、クエリコマンドとして保持する技術が存在する(特許文献1参照)。
クラウドサーバや文書生成サーバは、複数の企業・組織から使用されることが前提である(一般的にマルチテナントと呼ばれる)。このため、一部の企業・組織によって各サーバのリソースが占有される状況は好ましくない。リソースの占有を防ぐため、従来技術では、特にクラウドサーバからのデータ取得に制約があった。Salesforce CRMの場合、前記SOQLの構文に制限を持たせることでデータ取得時の負荷を軽減している。例えば、クラウドサーバ上に定義された複数のテーブルのデータを取得したい場合、通常のデータベースにおけるSQLであればJOIN構文を用いて複数テーブルのデータを1つにまとめて取得する。JOIN構文は、複数テーブル同士の結び付けを自由に定義できるためサーバ側で動的に結びつけを処理する必要があり、サーバ負荷が大きい。このため、SOQLではJOIN構文を許可していない。SOQLでは、テーブル同士の結び付けをあらかじめ項目の種別として定義し(参照項目または主従項目)、その種別で結び付けられたテーブル同士のみが取得できる限定的なJOIN構文を用意している(Parent−Child Relationship構文)。Parent−Child Relationship構文の一例を以下に挙げる。
Select Name, (Select Name, Uriage From Tenpo) From Todofuken
Todofukenテーブルから都道府県名(Name)を、Todofukenテーブルと結びつくTenpoテーブルから店舗名(Name)および売り上げ(Uriage)データを取得するSOQL構文である。このSOQLを実行すると各店舗の所在地(都道府県名)と売り上げデータを一覧で取得できる。
Todofukenテーブルから都道府県名(Name)を、Todofukenテーブルと結びつくTenpoテーブルから店舗名(Name)および売り上げ(Uriage)データを取得するSOQL構文である。このSOQLを実行すると各店舗の所在地(都道府県名)と売り上げデータを一覧で取得できる。
マルチテナントの観点から、SOQLには上記のような制限がある。従来、この制限下でデータの取得件数制限構文(Limit構文)を組み合わせると、データの取得がユーザの意図した動作にならない場合があるという問題があった。例えば、先ほどのTodofukenおよびTenpoテーブルからのデータ取得時、取得する件数を売り上げ上位10件に絞り込みたいとする。この場合、SOQLでは下記の構文でクエリを行う。
Select Name, (Select Name, Uriage From Tenpo Limit 10) From Todofuken Limit 10
Parent−Child Relationship構文では結びつくそれぞれのテーブルを複数のSelect句でクエリするが、Limit構文を組み合わせる場合、それぞれのSelect句に対してのみ指定が可能となる。このため、Limit構文で取得件数を制限できるのは、Todofukenテーブル、Tenpoテーブルそれぞれであって、データを結びつけた(Joinした)後の結果に対する件数制限ではない。この結果、Todofukenテーブルのデータが10件に絞られてしまうことにより、本来売り上げ上位10件に入っている都道府県データが削除され、上位10件のデータを取得できないということが起こりえる。また、TodofukenおよびTenpoテーブルそれぞれの取得件数は10件に制限されるが、各テーブルを結び付けて一覧取得した場合の件数は、10件を超えることが起こりえる(例えば1都道府県に店舗が2店以上ある場合)。この点でもユーザが本来意図する10件の制限という動作を実現することができない。
Parent−Child Relationship構文では結びつくそれぞれのテーブルを複数のSelect句でクエリするが、Limit構文を組み合わせる場合、それぞれのSelect句に対してのみ指定が可能となる。このため、Limit構文で取得件数を制限できるのは、Todofukenテーブル、Tenpoテーブルそれぞれであって、データを結びつけた(Joinした)後の結果に対する件数制限ではない。この結果、Todofukenテーブルのデータが10件に絞られてしまうことにより、本来売り上げ上位10件に入っている都道府県データが削除され、上位10件のデータを取得できないということが起こりえる。また、TodofukenおよびTenpoテーブルそれぞれの取得件数は10件に制限されるが、各テーブルを結び付けて一覧取得した場合の件数は、10件を超えることが起こりえる(例えば1都道府県に店舗が2店以上ある場合)。この点でもユーザが本来意図する10件の制限という動作を実現することができない。
クライアント端末101、クラウドプラットフォームサービス102および文書生成サーバ103がネットワークで接続された文書生成システムであって、以下を含む。
クラウドプラットフォームサービス102からのデータ取得に、特殊なJOIN構文での呼び出しが必要かどうか判定するデータアクセス部504。独自に件数制限を行う取得件数制限部507。件数制限設定を保持する件数制限管理部508。
データアクセス部504は、フォーム情報管理部505からクエリコマンド1006を取得し(S1401)、取得した情報をもとにクラウドプラットフォームサービス102からのデータ取得に、特殊なJOIN構文での呼び出しが必要かどうか判定し(S1402)、特殊なJOIN構文を発行するかどうかを判定し(S1403)、発行する場合、クエリコマンド1006に定義されたデータ取得件数制限の設定を無効化する(S1404)。
取得件数制限部507は、フォーム情報管理部505からクエリコマンド1006を取得し(S1401)、クエリコマンド1006から取得後のデータに対する件数制限設定を取得し(S1407)、取得した件数制限設定に基づいて、データアクセス部504によって取得されたデータに対して件数制限を行う(S1408)。
件数制限管理部508は、ユーザの指示に従って、クエリコマンド1006に対して、前記取得後のデータに対する件数制限設定を行う(S1301)。
本発明によれば、クラウドサーバからの複数テーブルデータ取得時に、データの取得件数制限を行う場合でも、データ取得をユーザの意図したとおりに動作させることができる。
以下、本発明を実施するための最良の形態について図面を用いて説明する。
図1は、本発明の実施例のシステム構成を示すブロック図である。
図中、101は、後述するクラウドプラットフォームサービス102および後述する文書生成サーバ103に対してリクエストを発行するクライアント装置101である。図中、102はクラウドプラットフォームサービス102であり、クライアント装置101や文書生成サーバ103からのリクエストに応じて、保持するデータの表示・更新等を行う。図中、103は、文書生成サーバ103であり、クライアント装置101からリクエストを受信して文書生成を行う。
また、上記各構成要素はネットワーク100により通信可能に接続されている。ネットワークは、例えば、インターネット等のLAN、WAN、電話回線、専用デジタル回線、ATMやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれである。また、これらの組み合わせにより実現される、いわゆる通信ネットワークである。
ネットワークはデータの送受信が可能であればよい。
クライアント装置101からクラウドプラットフォームサービス102、文書生成サービス103への通信手段、文書生成サーバ103からクラウドプラットフォームサービス102への通信手段、及び各サーバ間の通信手段が異なっていてもよい。
図2は、図1のクライアント装置101、クラウドプラットフォームサービス102、文書生成サーバ103のハードウェア構成を示すブロック図である。図中、201は内部バスで接続される各デバイス(後述のROM、RAM他)を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するCPUである。202はBIOSが格納してあるROMである。203はCPU201のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりするRAM(直接記憶装置)である。204は基本ソフトウェアであるOSやソフトウェアモジュールが記憶されているHDD(ハードディスクドライブ)、もしくはSSD(ソリッドステートドライブ)などの間接記憶装置である。205は入力装置であり不図示のキーボードやポインティングデバイスなどである。206は出力装置でありディスプレイが接続される。207はネットワーク100に接続するためのI/Fである。
これらハードウェアでは、起動後CPU201によりBIOSが実行されOSがHDD204からRAM203に実行可能にロードされる。CPU201はOSの動作に従って後述する各種ソフトウェアモジュールをHDD204からRAM203に随時、実行可能にロードする。各種ソフトウェアモジュールは上記各デバイスの協調によりCPU201によって実行され動作する。また、I/F207はネットワーク100に接続されており、OSの動作に従ってCPU201により制御され、上述した通信手段による通信を実現している。
図3は、本発明の実施の形態に係る文書生成システムの全体構成を示す図である。
図中、クライアント装置101はユーザインタフェースアプリケーションとしてWebブラウザ301を備えている。
クラウドプラットフォームサービス102は、クラウドプラットフォームサービスを使用するユーザの管理や、業務データ、後述する文書生成サーバ103へのリダイレクトを行うための設定を管理する。
また、クラウドプラットフォームサービス102は、マルチテナントが前提であり、使用する企業・組織毎に前述のユーザ管理、業務データ管理等が行われる。
文書生成サーバ103は、Webサーバ303、および、文書生成サービス304を備える。
文書生成サーバ103は、Webサーバ303、および、文書生成サービス304を備える。
Webサーバ303はいわゆるWebアプリケーションの機能を有するよう構成されており、クライアント101はWebブラウザ301を介してアクセスする事が出来る。
Webサーバ303はWebブラウザ301からのリクエストに対してユーザインタフェース情報を返答する。Webブラウザ301はWebサーバ303から得られたユーザインタフェース情報をレンダリングし表示する。
表示されたユーザインタフェース情報には、たとえば、後述する文書生成サーバ103が管理するフォームの一覧や、文書生成をリクエストするためのインタフェース等が含まれている。
また、Webサーバ303はWebブラウザ301から文書生成リクエストを受信すると、クラウドプラットフォームサービス102から業務データを取得し、該業務データとともに文書生成サービス304に対して文書生成のリクエストを送信する。
文書生成サービス304は、受信したデータと自身で管理するフォームおよびクエリコマンドを使用してオーバレイ処理を行い、文書データを生成する。クエリコマンドには、クラウドプラットフォームサービス102からの業務データ取得方法等が設定されている。
図4は、クラウドプラットフォームサービス102上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図2で示したHDD204に記憶されており、前述したようにCPU201によってRAM203にロードされ実行される。
クラウドプラットフォームサービス102は以下で構成される。
クライアント装置101のWebブラウザ301や文書生成サーバ103のWebサーバ303との通信を処理する送受信部401。
送受信部401が受け付けたリクエストに従って処理を実行する制御部402。
Webブラウザ301にレスポンスを返すためのWebページを生成するページ生成部403。
Webブラウザ301にレスポンスを返すためのWebページを生成するページ生成部403。
ログイン要求してきたユーザを認証する認証部405。
認証部405にて認証に成功したユーザのセッション情報を管理するセッション管理部404。
業務データをDB408に保持し要求に応じてDB408から業務データの取得、あるいは業務データの更新を行うデータ管理部406。
文書生成サーバ103へのリダイレクトを行うための設定を保持する設定管理部407である。
クラウドプラットフォームサービス102はこれら各構成要素の協調により、後述する処理を実行する。
また、図中、408は管理ユーザデータや業務データを格納するDB408であり、図2で示したHDD204に記憶されている。
管理ユーザデータや業務データは、企業・組織(以降、組織と表記)毎に管理される。各組織には組織IDが自動的に割り当てられ、組織IDとともに各データが管理される。ユーザ認証時、ユーザが所属する組織の組織IDを取得しセッション管理部404に保存する。以降のデータ取得等の処理は組織IDをもとに行われ、組織IDの一致するデータのみを参照することが可能となっている。
また、DB408には、文書生成サーバ103へのリダイレクトを行うための設定も格納される。DB408に格納された業務データや文書生成サーバ103へリダイレクトを行うための設定は、Webブラウザ301を介して、ユーザ(管理者)により任意のタイミングで設定更新が行われる。
図5は、文書生成サーバ103のWebサーバ303上で動作するソフトウェアモジュールの構成図である。
なお各ソフトウェアモジュールは図2で示したHDD204に記憶されており、前述したようにCPU201によってRAM203にロードされ実行される。
Webサーバ303は以下で構成される。
クライアント装置101のWebブラウザ301やクラウドプラットフォームサービス102、文書生成サービス304との通信を処理する送受信部501。受け付けたリクエストに従って処理を実行する制御部502。Webブラウザ301にレスポンスを返すためのWebページを生成するページ生成部503。クラウドプラットフォームサービス102にアクセスして業務データを取得するデータアクセス部504。後述のフォーム情報テーブルを管理するフォーム情報管理部505。Webブラウザ301のセッション情報を管理するセッション管理部506。データアクセス部504が取得した業務データに対して、取得件数の制限を行う取得件数制限部507。取得件数の制限設定を管理する取得制限管理部508である。Webサーバ303はこれら各構成要素の協調により、後述する処理を実行する。
図6は、文書生成サーバ103の文書生成サービス304上で動作するソフトウェアモジュールの構成図である。
なお各ソフトウェアモジュールは図2で示したHDD204に記憶されており、前述したようにCPU201によってRAM203にロードされ実行される。
文書生成サービス304は以下で構成される。
Webサーバ303からの文書生成リクエストを受け付ける要求受信部601。受け付けたリクエストに従って処理を実行する制御部602。フォームデータを管理するフォーム管理部603。Webサーバ303から送信された業務データとフォームを使用してオーバレイ処理を行い、文書データを生成する文書生成部604。生成された文書データをWebサーバ303またはクライアント端末101に送信する文書送信部605である。
図7は、クライアント装置101のWebブラウザ301から、クラウドプラットフォームサービス102にアクセスして業務データを表示した場合の業務画面701の例である。なお、図7は、ユーザがクラウドプラットフォームサービス102にログイン済の状態である。業務画面701は、あるレコードの詳細情報702や商品703が表示されている。図7では、商談に関する業務画面の商談レコードの詳細を表示している。また、文書生成サーバ103へリダイレクトを行うための設定がなされたカスタムボタン704が表示されている。カスタムボタン704は、ボタン押下時の動作や、どの画面に表示するか、等を任意に設定可能で、ユーザ(管理者)によって画面に配置される。
図8は、クラウドプラットフォームサービス102のデータ管理部406が保持する業務データのうち、商談に関するデータのテーブル構造例を示す図である。
業務データはデータテーブル800で管理され、商談テーブル801、および、商品テーブル811によって構成されている。
商談テーブル801は、レコードの識別子であるレコードID802、レコードをユーザが容易に区別するために任意の名前を設定可能な商談名803で構成される。
商品テーブル811は、商談レコードID812、商品テーブルのレコードの識別子であるレコードID813、品名814、数量815、価格816から構成される。また、商談レコードID812は、商談テーブルのレコードID802とリレーションしている。
図9は、クラウドプラットフォームサービス102の設定管理部407で保持するカスタムボタンの定義情報の例を示す図である。
図9では、カスタムボタンが「商談」画面と「顧客」画面に定義されており、「商談」画面に表示するカスタムボタンの設定情報には、ボタン表示名903、および、文書生成サーバ103へリダイレクトを行うためのパラメータ情報が格納されている。
文書生成サーバURI904は、文書生成サーバ103のURIを「http://〜」の形式で指定したパラメータである。セッションID905は、ログインしたユーザのセッションIDを取得して文字列「sid=<セッションID>」をURLパラメータに付加する設定である。CPSURL906は、文書生成サーバ103がクラウドプラットフォームサービス102にアクセスするためのURLを文字列「srv_url=<クラウドプラットフォームサービスURL>」としてURLパラメータに付加する設定である。
クラウドプラットフォームサービス102にアクセスするためのURLは組織毎に固有であり、ユーザ認証時に、制御部502が、ユーザが所属する組織に応じたURLを取得してセッション管理部404に保存する。
組織ID907は、ログインしたユーザの組織IDを取得して文字列「orgid=<組織ID>」をURLパラメータに付加する設定である。レコードID908は、画面に表示した商談レコードのレコードID1202を取得して文字列「recid=<レコードID>」をURLパラメータに付加する設定である。
図10は、Webサーバ303のフォーム情報管理部505が保持するフォーム情報テーブルのテーブル構造を示す図である。
フォーム情報テーブル1001のフォーム情報レコードは、以下で構成される。
該レコードの所有者である組織を識別する組織ID1003。フォーム選択画面に表示する名称である表示名1004。文書生成サービス304のフォーム管理部603で管理されているフォームのファイル名であるフォームファイル名1005。クラウドプラットフォームサービス102からデータを取得するためのクエリを記述したクエリコマンド1006。フォームファイル内に定義されている固定的なデータに関する情報であるフォーム情報107。
該レコードの所有者である組織を識別する組織ID1003。フォーム選択画面に表示する名称である表示名1004。文書生成サービス304のフォーム管理部603で管理されているフォームのファイル名であるフォームファイル名1005。クラウドプラットフォームサービス102からデータを取得するためのクエリを記述したクエリコマンド1006。フォームファイル内に定義されている固定的なデータに関する情報であるフォーム情報107。
図11は、図1の文書生成システムにおけるクライアント装置101のWebブラウザ303で表示する画面のフローを示した図である。
なお、以降の図では、クラウドプラットフォームサービスをCPSと略して表記している。
業務画面1101は、クラウドプラットフォームサービス102が作成し、クライアント装置101に返す画面であり、例えば、図7の業務画面701が表示される。
文書生成ボタン1102は、クラウドプラットフォームサービス102へ文書生成リクエストを発行するボタンである。
クラウドプラットフォームサービス102は文書生成ボタン1102が押下されると、文書生成サーバ103へリダイレクトするURLを返却する。
クライアント装置101のWebブラウザ301は、リダイレクトするURLを受けるとこのURLに従った文書生成サーバ103へリダイレクトする。
リダイレクトでリクエストを受けた文書生成サーバ103は、フォーム選択画面1103をクライアント装置101のWebブラウザ301に返す。
フォーム選択画面1103は文書生成に使用するフォームを選択するフォーム選択1104を備える。
また、ユーザから文書作成ボタン1105の選択を受けたクライアント装置101のWebブラウザ301は、フォーム選択1104の選択結果を文書生成サーバ103に送信する。これらの情報を受け取った文書生成サーバ103は、業務画面1101の業務データをクラウドプラットフォームサービス102から取得する。データ取得中画面1106は、文書生成サーバ103がクラウドプラットフォームサービス103から業務データを取得中の間クライアント装置101のWebブラウザ301に表示される。文書生成サーバ103がクラウドプラットフォームサービス103からの業務データ取得が完了すると、文書生成サーバ103は取得したデータを確認可能なデータ確認画面1107をクライアント装置101のWebブラウザ301に返す。ユーザから作成ボタン1108の選択を受けたクライアント装置101のWebブラウザ301は、文書生成サーバ103に文書生成リクエストを送信する。文書生成リクエストを受けた文書生成サーバ103は、選択されたフォームとクラウドプラットフォームサービス103から取得した業務データを使用して文書生成処理を行う。文書生成処理の間、クライアント装置102のWebブラウザ301は、作成中画面1109を表示する。文書の作成が完了すると、クライアント端末101のWebブラウザ301は完了画面1110を表示する。
図12は、本発明の実施例1における文書生成システムが行う処理の流れを示している。なお、ユーザは不図示のログイン画面にてクラウドプラットフォームサービス102にログイン済とし、Webブラウザ301には図7の業務画面701が表示されており、カスタムボタン704は、予め、図9の設定がなされているものとする。
はじめ、ユーザによりクライアント装置101のWebブラウザ301に表示された業務画面701のカスタムボタン704が押下される(S1201)と、クラウドプラットフォームサービス102では、S1202においてリダイレクトURL作成処理を行う。
S1202において、制御部402はカスタムボタンに設定された文書生成サーバURI904、セッションID905、CPSURL906、組織ID907およびレコードID908を取得し、これら取得したパラメータからリダイレクトURLを生成する。そして、リダイレクトさせるためのレスポンスをWebブラウザ301に返す。
S1203で、Webブラウザ301はクラウドプラットフォームサービス102から返されたレスポンスを受信すると、セッションID905、CPSURL906、組織ID907、レコードID908を文書生成サーバ103に送信する。
S1203で、Webブラウザ301はクラウドプラットフォームサービス102から返されたレスポンスを受信すると、セッションID905、CPSURL906、組織ID907、レコードID908を文書生成サーバ103に送信する。
S1204で、Webサーバ303はWebブラウザ301からのリダイレクトを受信すると、まず制御部502は、セッションID905、CPSURL906、組織ID907およびレコードID908をセッション管理部506に保存する。
次に、制御部502はフォーム情報レコード1002に含まれるフォームの表示名1004のリストをフォーム情報管理部505から取得し、フォームの表示名1004のリストからフォーム選択画面1103を作成、クライアント端末101に送る。
S1205では、ユーザによりフォーム選択画面1103のフォーム1104が選択され、文書作成ボタン1105が押下されると、Webサーバ303に対して選択フォーム1104とともに文書生成リクエストが送信される。
S1206にてWebサーバ303が文書生成リクエストを受信すると、文書生成サービス103は選択フォーム1104で指定されたフォームに一致するクエリコマンド1006を発行し、クラウドプラットフォームサービス102にデータ取得リクエストを行う。
その際、クラウドプラットフォームサービス102のURLおよび取得データの内容は、セッション管理部506に保存されているCPSURL905および組織ID907、レコードID908をそれぞれ使用する。次に、S1207において文書生成サーバ103は、データ取得中画面1106を作成し、Webブラウザ301に送る。
Webブラウザ301は定期的にS1208でデータ取得完了確認リクエストを文書生成サーバ103に送信する。文書生成サーバ103のWebサーバ303は、クラウドプラットフォームサービス02からデータ取得のレスポンスが返るまでは、S1207と同様のデータ取得中画面1106をWebブラウザ301に送る。
次に、クラウドプラットフォームサービス102からデータ取得のレスポンスが文書生成サーバ103に返る。
Webサーバ303の制御部502は、取得データをセッション管理部506へ保存する。
その後にWebブラウザ301からデータ取得完了の確認リクエストが送られてくると、Webサーバ303はクラウドプラットフォームサービス102から取得したデータでデータ確認画面1107を生成し、Webブラウザ301へ返す(S1209)。
S1209においてWebブラウザ301に返された取得データ確認画面1107にて、ユーザにより作成ボタン1108が押下されると、Webブラウザ301より、Webサーバ303に対して、文書生成リクエストが送信される(S1210)。
S1210において、Webサーバ303が文書生成リクエストを受信すると、後述の文書生成処理を行う。
図13は、本発明におけるWebサーバ303の件数制限設定保存処理を示すフローチャートである。
ステップS1301で件数制限管理部508は、ユーザの指示に従って、クエリコマンド1006に対して、ステップS1407で後述する取得後のデータに対する件数制限設定を保存する。ユーザは、件数制限管理部508が提供する不図示のUIを操作して、件数制限設定値(例えば10等)を指定する。なお、取得後のデータに対する件数制限設定を保持したクエリコマンド1006がフォーム情報管理部505で管理されてさえいればよい。このため、件数制限管理部508はWebサーバ303に属している必要はない。例えば、別のサーバはクライアント装置101に属していても構わない。
図14は、本発明におけるWebサーバ303の文書生成処理を示すフローチャートである。
ステップS1401でデータアクセス部504は、ユーザからの指定に基づいて、フォーム情報管理部505から該当のクエリコマンド1006を取得する。
ステップS1402でデータアクセス部504は、ステップS1401で取得したクエリコマンド1006を解析してクラウドプラットフォームサービス102からのデータ取得に特殊なJOIN構文での呼び出しが必要かどうかを判定する。例えば、Salesforce CRMの場合、データ取得にはSOQLを使用する必要があり、通常のSQLでのJOIN構文が使用できないため特殊なJOIN構文が必要と判定する。特殊なJOIN構文呼び出しが必要と判定した場合にはステップS1403に遷移し、不要と判定した場合にはステップS1405に遷移する。
ステップS1403でデータアクセス部504は、データ取得のために特殊なJOIN構文を発行するかどうかを判定する。例えば、取得するデータが1つのテーブルに格納されている場合には、JOINする必要がないのでJOIN構文を発行しない。JOIN構文を発行すると判定された場合にはステップS1404に遷移し、発行しないと判定された場合にはステップS1405に遷移する。
ステップS1404でデータアクセス部504は、ステップS1401で取得したクエリコマンド1006にデータ取得件数制限の設定があるかどうかを検出し、ある場合その設定を無効化したクエリ文字列を生成する。例えば、クエリコマンド1006にテーブルAからのデータ取得に対して10件以上取得しない設定(Limit 10)がなされていた場合、「Limit 10」という構文を取り除いたクエリ文字列を生成する。
ステップS1405でデータアクセス部504は、通常のクエリ文字列もしくはステップS1404で生成したクエリ文字列を使用して、クラウドプラットフォームサービス102からのデータ取得を行う。
ステップS1406で取得件数制限部507は、独自に取得件数制限を行う必要があるかどうかを決定するため、ステップS1404でLimit構文を取り除いたクエリ文字列を生成したかどうかを判定する。生成した場合ステップS1407に遷移し、生成していない場合本フローを終了する。
ステップS1407で取得件数制限部507は、クエリコマンド1006から、取得後のデータに対する件数制限設定を取得する。取得後のデータに対する件数制限設定(以降、取得後データ件数制限設定)は、結び付けられた複数のテーブルを結合(JOIN)した後のデータに対する件数制限設定である。例えば、
Select Name, (Select Name, Uriage From Tenpo) From Todofuken
上記のようなSOQLを発行して得られたデータが100件だったとしても、取得後データ件数制限設定が「10」となっていれば、取得されるデータは10件となる。
Select Name, (Select Name, Uriage From Tenpo) From Todofuken
上記のようなSOQLを発行して得られたデータが100件だったとしても、取得後データ件数制限設定が「10」となっていれば、取得されるデータは10件となる。
ステップS1408で取得件数制限部507は、ステップS1407で取得した、取得後データ件数制限設定に基づいて、取得されたデータに対して件数制限を行う。
以上でWebサーバ303の文書生成処理を示すフローチャートが完了する。
101 クライアント装置
102 クラウドプラットフォームサービス
103 文書生成サーバ
301 Webブラウザ
303 Webサーバ
304 文書生成サービス
502 制御部
503 ページ生成部
102 クラウドプラットフォームサービス
103 文書生成サーバ
301 Webブラウザ
303 Webサーバ
304 文書生成サービス
502 制御部
503 ページ生成部
Claims (1)
- クライアント端末101、クラウドプラットフォームサービス102および文書生成サーバ103がネットワークで接続された文書生成システムであって、以下を含む。
クラウドプラットフォームサービス102からのデータ取得に、特殊なJOIN構文での呼び出しが必要かどうか判定するデータアクセス部504。独自に件数制限を行う取得件数制限部507。件数制限設定を保持する件数制限管理部508。
データアクセス部504は、フォーム情報管理部505からクエリコマンド1006を取得し(S1401)、取得した情報をもとにクラウドプラットフォームサービス102からのデータ取得に、特殊なJOIN構文での呼び出しが必要かどうか判定し(S1402)、特殊なJOIN構文を発行するかどうかを判定し(S1403)、発行する場合、クエリコマンド1006に定義されたデータ取得件数制限の設定を無効化する(S1404)。
取得件数制限部507は、フォーム情報管理部505からクエリコマンド1006を取得し(S1401)、クエリコマンド1006から取得後のデータに対する件数制限設定を取得し(S1407)、取得した件数制限設定に基づいて、データアクセス部504によって取得されたデータに対して件数制限を行う(S1408)。
件数制限管理部508は、ユーザの指示に従って、クエリコマンド1006に対して、前記取得後のデータに対する件数制限設定を行う(S1301)。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013009760A JP2014142733A (ja) | 2013-01-23 | 2013-01-23 | 文書生成システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013009760A JP2014142733A (ja) | 2013-01-23 | 2013-01-23 | 文書生成システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014142733A true JP2014142733A (ja) | 2014-08-07 |
Family
ID=51423974
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013009760A Pending JP2014142733A (ja) | 2013-01-23 | 2013-01-23 | 文書生成システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2014142733A (ja) |
-
2013
- 2013-01-23 JP JP2013009760A patent/JP2014142733A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5528229B2 (ja) | 文書生成装置、文書生成システム、文書アップロード方法及びプログラム | |
JP2011203894A (ja) | 情報処理装置、帳票データ作成方法、及びコンピュータプログラム | |
KR102136474B1 (ko) | 가상 세션에서의 클라이언트 측 키보드 레이아웃과 서버 측 키보드 레이아웃의 동기화 | |
EP3232335B1 (en) | Method and device for providing authentication information on web page | |
KR101086620B1 (ko) | 스마트 오피스 시스템 및 운용을 위한 서버 및 운용 방법 | |
CN113360160A (zh) | 部署应用的方法、装置、电子设备和存储介质 | |
JP2015141473A (ja) | サーバーシステム、サーバーシステムを制御する方法、プログラム | |
JP2021166020A (ja) | 情報処理装置、設置管理サーバ、システム、それらの制御方法、及びプログラム | |
US10762275B2 (en) | Information processing apparatus, method, and storage medium | |
US9032541B2 (en) | Information processing system, information processing apparatus, and computer-readable storage medium | |
JP2013210912A (ja) | データ処理装置、データ処理システム及びプログラム | |
US20220337668A1 (en) | Systems and methods for real-time repository management for universal service deployment | |
US10713278B2 (en) | Flexible configuration of offline synchronization scope | |
KR101777850B1 (ko) | 업무 시스템 제공 방법 및 장치 | |
JP6370342B2 (ja) | 電子機器、表示方法、およびプログラム | |
CN102904742B (zh) | 对可执行节点的操作方法及系统 | |
JP2014142733A (ja) | 文書生成システム | |
JP2015005150A (ja) | 文書生成システム | |
US9553935B2 (en) | Mechanism for configuring service endpoints in native client applications at runtime | |
JP2013037642A (ja) | 文書生成システム | |
JP2015005146A (ja) | 文書生成システム | |
WO2011117954A1 (ja) | 仮想マシン管理装置、仮想マシン管理方法、及びプログラム | |
JP2016014915A (ja) | 文書生成システムおよびその制御方法、並びにプログラム | |
US10586078B2 (en) | Document system, control method, and storage medium | |
JP2017126231A (ja) | 文書生成システム |