JP2020067718A - 文書生成システムおよびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】Ｗｅｂブラウザに表示したＷｅｂ帳票を電子文書として保存する際のユーザー操作の負荷を軽減する。【解決手段】文書生成システムであって、文書データから、第１のファイル形式の複数の帳票データを生成する生成手段と、前記第１のファイル形式の複数の帳票データを、第２のファイル形式の複数の帳票データに変換する変換手段と、前記変換手段にて変換された第２のファイル形式の複数の帳票データを、保存要求を受け付け可能に表示部に表示させる表示手段と、前記表示部にて表示させた第２のファイル形式の複数の帳票データに対する保存要求を受け付けたことに応じて、前記第２のファイル形式の複数の帳票データに対応する前記第１のファイル形式の複数の帳票データを１の第１のファイル形式のデータに結合して記憶部に保存させる保存手段とを有する。【選択図】 図８

Description

本発明は、文書生成システムおよびその制御方法、並びにプログラムに関する。

昨今、ペーパーレス化による業務の効率化や省資源化を目的として、紙媒体の情報を文書データに置き換える企業が増加している。例えば、社内で運用されている業務帳票もその対象であり、特に基幹系システムが出力する帳票は大量のページ数を出力することが多く、運用コストが莫大なものになることから、帳票の電子化が積極的に行われている。

また、業務データの管理や各種処理を行う形態として、クラウドサービスの利用が普及し始めている。ユーザーは、クライアント端末のＷｅｂブラウザからインターネットを介してクラウドサービスのＷｅｂページにアクセスし、そのＷｅｂページ上で電子化された帳票文書データを閲覧する。さらに、業務フローに応じて閲覧している帳票文書データを編集・印刷するような利用ケースの増加が予想される。Ｗｅｂページ上で帳票文書データを扱う場合、帳票システムで一般的に利用されるＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）形式のデータではなく、よりＷｅｂとの親和性が高いＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）等の形式を使用することが想定される。ＳＶＧを使用することで、画面の拡大縮小による画質劣化が発生せず、従来の帳票文書データでは実現が困難なダイナミックな表現を用いた描画が可能となり、付加価値が高いＷｅｂ帳票を実現可能である。

帳票文書全体の生成が完了してからＷｅｂブラウザに表示すると、特にページ数の多い業務帳票では、帳票生成を行ってからＷｅｂページ上で閲覧できるまでユーザーが待たされる可能性がある。そのため、文書全体が生成され送信されるのを待つのではなく、帳票文書を所定のページ単位毎に分割してＰＤＦを生成し、各ＰＤＦを夫々ＳＶＧ等に変換する。そして、変換完了したページから順に素早く受信してＷｅｂブラウザに表示する。このような帳票文書生成システムにおいて、クライアント端末のＷｅｂブラウザに表示したＷｅｂ帳票を電子文書として保存したいことが想定される。しかし、ＳＶＧは容易に書き換え可能なため保存の用途に適しておらず、保存用途にはＰＤＦが適している。そのため、ＰＤＦ形式の帳票文書を保存用として改めて生成することが考えられる。特許文献１には、複数の印刷データ文書を結合して１つの文書データを生成する手法が開示されている。

特開２００２−６３０００号公報

しかしながら、ＰＤＦ形式の帳票文書を保存用として再生成するには以下の問題があった。ユーザーは元のＷｅｂページに再度アクセスし、閲覧していた帳票と同一のデータを再度選択し、Ｗｅｂ帳票閲覧用途でなく保存用途を指定して帳票作成操作を行う必要があるため、ユーザー操作の手間がかかる。また、特許文献１の場合、ユーザーの操作により１つ以上の文書データを任意の順に並べて１つの印刷データ文書へ結合するため、ユーザーによる指示操作が必要となり手間がかかってしまう。

そこで、本発明は、Ｗｅｂブラウザに表示した帳票を電子文書として保存する際のユーザー操作の負荷を軽減することを目的とする。

上記課題を解決するために本発明は以下の構成を有する。すなわち、文書生成システムであって、文書データから、第１のファイル形式の複数の帳票データを生成する生成手段と、前記第１のファイル形式の複数の帳票データを、第２のファイル形式の複数の帳票データに変換する変換手段と、前記変換手段にて変換された第２のファイル形式の複数の帳票データを、保存要求を受け付け可能に表示部に表示させる表示手段と、前記表示部にて表示させた第２のファイル形式の複数の帳票データに対する保存要求を受け付けたことに応じて、前記第２のファイル形式の複数の帳票データに対応する前記第１のファイル形式の複数の帳票データを１の第１のファイル形式のデータに結合して記憶部に保存させる保存手段とを有する。

本発明により、Ｗｅｂブラウザに表示した帳票を電子文書として保存する際のユーザー操作の負荷を軽減できる。

本実施形態に係るシステム構成の例を示す図。 本実施形態に係る装置のハードウェア構成の例を示す図。 本実施形態に係る装置のソフトウェア構成の例を示す図。 本実施形態に係るオーバレイ処理のフローチャート。 第１の実施形態に係るデータ変換処理のフローチャート。 本実施形態に係るインデックスファイルの例を示す図。 第１の実施形態に係るクライアント端末の帳票保存要求処理のフローチャート。 第１の実施形態に係る帳票生成サーバの帳票保存処理のフローチャート。 本実施形態に係る業務画面の例を示す図。 本実施形態に係るＷｅｂ帳票画面の例を示す図。 第２の実施形態に係るデータ変換処理のフローチャート。 第２の実施形態に係るクライアント端末の帳票保存要求処理のフローチャート。 第２の実施形態に係る帳票生成サーバの帳票保存処理のフローチャート。 第２の実施形態に係る保存ページ指定画面の例を示す図。 第３の実施形態に係る業務サーバの帳票表示要求処理のフローチャート。 第３の実施形態に係るクライアント端末の帳票データ情報取得要求処理のフローチャート。 第３の実施形態に係るクライアント端末のＷｅｂ帳票表示処理のフローチャート。 第３の実施形態に係るクライアント端末の帳票保存要求処理のフローチャート。 第３の実施形態に係る帳票生成サーバの帳票保存処理のフローチャート。

以下、本発明を実施するための一実施形態について図面を用いて説明する。なお、以下に示す形態等は一例であり、これに限定することを意図するものではない。

＜第１の実施形態＞
［システム構成］
図１は、本発明の実施形態に係るシステム構成の例を示す図である。図１において、クライアント端末１０２は、有線または無線ＬＡＮを介してローカルネットワーク１０１に接続され、ローカルネットワーク１０１を介してインターネット１００にアクセスする。インターネット１００上またはローカルネットワーク１０１上には、各種サーバが設けられ、クライアント端末１０２はこれらのサーバにアクセス可能である。クライアント端末１０２は、例えばデスクトップパソコン、ノートパソコン、スマートフォンやタブレットＰＣ等が該当する。クライアント端末１０２は、Ｗｅｂブラウザ等のプログラムを実行する環境を内蔵している。ここでば、クライアント端末１０２は、１台のみが示されているが、複数のクライアント端末がネットワーク上に存在してよい。

業務サーバ１０３は、ユーザー業務情報を管理するサーバである。本実施形態では業務サーバ１０３で業務情報を管理し、販売員が業務サーバ１０３の情報を用いて顧客に対して営業を行うユースケースを想定している。業務サーバ１０３はクライアント端末１０２からのリクエストに応じて業務情報の表示と、帳票データ生成指示を行うための画面を提供する。

帳票生成サーバ１０４は、業務サーバ１０３から業務情報を受け取り、オーバレイ出力処理、並びに帳票閲覧プログラムの生成処理を実行する。すなわち、帳票生成サーバ１０４は、テキストデータであるフィールドデータファイルと所定のフォーム情報を含むフォーム情報ファイルとを重ね合わせて印刷ページを生成する。そして、帳票生成サーバ１０４は、仮想プリンタ（不図示）に指示して上記生成された印刷ページをＰＤＦファイルとして生成する。さらに、帳票生成サーバ１０４は、生成した帳票文書を閲覧できる帳票閲覧プログラムを生成する。

本実施形態において帳票閲覧プログラムとは、ネットワークを介して配信可能な、Ｗｅｂブラウザ上で動作するＷｅｂアプリケーションである。多くの場合、これらのＷｅｂアプリケーションは、Ｗｅｂページを表現するマッシュアップ言語（例えば、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ））及びＷｅｂブラウザ上で動作するプログラミング言語（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標））により動作するアプリケーションである。帳票閲覧プログラムは、Ｗｅｂブラウザ上で動作するＷｅｂアプリケーション以外にも、コンピュータシステム上で実行、動作するアプリケーションでもよい。本実施形態では、クライアント端末１０２が、各データを表示する表示部として機能するＷｅｂブラウザを備え、これを用いた形態について説明する。

帳票生成サーバ１０４は、フォーム情報ファイルに業務情報を重ね合わせて帳票文書を生成し管理する。また、帳票生成サーバ１０４は、変換サーバ１０５に対して、生成した帳票文書をＷｅｂ帳票文書に変換する変換リクエストを行う。また、帳票生成サーバ１０４は、クライアント端末１０２から帳票文書の保存リクエストを受け付けて、帳票文書をストレージサーバ１０６に保存する。

また、本実施形態において、扱うファイル形式（フォーマット）として、ＰＤＦファイルと、ＳＶＧファイルを例に挙げて説明する。しかし、これらのファイル形式に限定するものではなく、本発明を適用可能な特性を有するファイル形式であれば、他のファイル形式を用いてもよい。

変換サーバ１０５は、帳票生成サーバ１０４から帳票文書の変換リクエストを受け付けて、Ｗｅｂ帳票文書を生成する。Ｗｅｂ帳票文書とは、Ｗｅｂページ上で扱うＳＶＧ等の形式の帳票文書である。

ストレージサーバ１０６は、ファイル管理を行うサーバであり、クライアント端末１０２、帳票生成サーバ１０４、もしくは変換サーバ１０５からのファイルアップロード／ダウンロードを受け付ける。ストレージサーバ１０６は、ファイルのライフサイクルを管理する機能を有し、保存後一定時間経過したファイルをストレージサーバ１０６が自動的に削除する。本実施形態では、所定のファイルパスに保存したファイルは、保存後一日以上経過すると自動的に削除されるものとする。以降、ライフサイクル管理機能により自動的に削除される領域を「ライフサイクル管理領域」と記載する。このような領域以外にも、ストレージサーバ１０６は、自動的にはファイルを削除せず、ユーザー等の削除指示に基づいてファイルを削除する保存領域を備えてよい。

なお、本実施形態では、予めユーザー管理者が各サーバに次の情報を保存しておくものとする。すなわち、業務サーバ１０３に業務情報データが保存され、帳票生成サーバ１０４に顧客データに対応するフォーム情報ファイルが保存される。

また、図１では、各サーバを個別に示したが、この構成に限定するものではなく、例えば、１台の装置が複数のサーバの機能を備えていてもよいし、複数の装置にて１つのサーバの機能を実現してもよい。例えば、各種サーバをまとめて、文書生成システムとして扱ってよい。

［ハードウェア構成］
図２は、本実施形態に係るクライアント端末１０２、業務サーバ１０３、帳票生成サーバ１０４、変換サーバ１０５、およびストレージサーバ１０６として動作可能な情報処理装置のハードウェア構成の例を示す図である。ここでは各機器が同じ構成を備えるものとして説明するが、それぞれが異なる部位を備えていてもよい。

図２に示す情報処理装置２００は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、入力装置２０５、出力装置２０６、およびＩ／Ｆ（インターフェース）２０７を含んで構成され、各部位は、内部バス２０８を介して通信可能に接続される。ＣＰＵ２０１は、内部バス２０８で接続される各部位を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行する。ＲＯＭ２０２は、不揮発性の記憶部であり、例えば、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）などが格納される。ＲＡＭ２０３は、揮発性の記憶部であり、ＣＰＵ２０１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりする。ＨＤＤ２０４は、不揮発性の記憶装置であり、基本ソフトウェアであるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やソフトウェアモジュールなどが記憶されている。入力装置２０５は、例えば、ユーザーの操作によりユーザー入力を受け付ける際に用いられ、不図示のキーボードやポインティングデバイスなどが該当する。出力装置２０６は、情報処理装置２００における処理結果を出力する際に用いられ、ディスプレイなどが該当する。Ｉ／Ｆ２０７は、ネットワークに接続するためのインターフェースであり、外部装置と通信する際に用いられる。

情報処理装置２００が起動した後、ＣＰＵ２０１によりＢＩＯＳが実行され、ＯＳがＨＤＤ２０４からＲＡＭ２０３に実行可能にロードされる。ＣＰＵ２０１は、ＯＳの動作に従って後述する各種ソフトウェアモジュールをＨＤＤ２０４からＲＡＭ２０３に随時、実行可能にロードする。各種ソフトウェアモジュールは上記各デバイスの協調によりＣＰＵ２０１によって実行され動作する。また、Ｉ／Ｆ２０７はインターネット１００、ローカルネットワーク１０１に接続されており、ＯＳの動作に従ってＣＰＵ２０１により制御され、上述した通信手段による通信を実現する。

［ソフトウェア構成］
図３は、本実施形態に係るクライアント端末１０２、業務サーバ１０３、帳票生成サーバ１０４、変換サーバ１０５、およびストレージサーバ１０６のソフトウェア構成の例を示す図である。各ソフトウェア構成と、各装置が扱う管理情報について説明する。ここでは、本発明の動作、処理に関する構成のみを説明し、それ以外の構成については説明を省略する。

（業務サーバ）
業務サーバ１０３は、Ｗｅｂ画面Ｉ／Ｆ３３１、業務情報管理部３３２、およびストレージ３３３を含んで構成される。各ソフトウェアモジュールは、業務サーバ１０３が備えるＨＤＤ２０４に記憶されており、ＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂ画面Ｉ／Ｆ３３１は、業務サーバ１０３のユーザーインターフェースを提供し、クライアント端末１０２のＷｅｂブラウザ３２１からの要求に応じて、業務情報を表示する画面を生成して返す。業務情報管理部３３２は、業務情報をストレージ３３３に記憶して管理する。これらの情報は、業務サーバ１０３の外部メモリではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバに記憶するように構成してもよい。

業務情報管理部３３２が管理している顧客情報の例を表１に示す。

顧客情報は、帳票を生成する際に使用するデータテーブルである。本実施形態において、顧客情報は、顧客を一意に識別するための顧客ＩＤ、氏名、住所、生年月日、および連絡先を含んで構成される。帳票を生成するために必要なデータは、本実施形態の顧客情報に限らず、製品の在庫や納品情報、入出金情報等、様々な物が想定される。ここで示す顧客情報の項目は一例であり、他の情報を含んでいてもよい。

業務情報管理部３３２が管理している帳票情報の例を表２に示す。

帳票情報は、帳票を生成する際に使用する帳票テンプレート情報を保持するデータテーブルである。帳票情報は、帳票情報を一意に識別するための帳票ＩＤ、画面表示用の帳票名、帳票生成サーバ１０４で管理されているフォーム情報ファイルを特定する帳票テンプレートＩＤを含んで構成される。ここで示す帳票情報の項目は一例であり、他の情報を含んでいてもよい。

業務サーバ１０３のＷｅｂ画面Ｉ／Ｆ３３１は、クライアント端末１０２のＷｅｂブラウザ３２１から帳票プレビュー指示を受け付ける。業務情報管理部３３２は、該当の顧客情報と、帳票情報の帳票テンプレートＩＤを帳票生成サーバ１０４に送信し、帳票生成のリクエストを行う。

（帳票生成サーバ）
帳票生成サーバ１０４は、Ｗｅｂサーバ３４１、帳票情報管理部３４２、オーバレイ部３４３、保存文書生成部３４４、およびストレージ３４５を含んで構成される。各ソフトウェアモジュールは、帳票生成サーバ１０４が備えるＨＤＤ２０４に記憶されており、ＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂサーバ３４１は、帳票生成サーバ１０４の各種インターフェースを提供し、クライアント端末１０２のＷｅｂブラウザ３２１や、業務サーバ１０３からのリクエストを受付け、応答を返す。帳票情報管理部３４２は、帳票テンプレート情報、および、帳票データ情報をストレージ３４５に格納して管理する。保存文書生成部３４４は、保存に適した形式の帳票文書を生成する。

帳票情報管理部３４２が管理している帳票テンプレート情報の例を表３に示す。

帳票テンプレート情報は、帳票生成サーバ１０４が管理するフォーム情報ファイルのデータテーブルである。本実施形態では、フォーム情報ファイルをストレージサーバ１０６にファイルとして保持している。帳票テンプレートＩＤはフォーム情報ファイルを一意に識別するためのＩＤ（識別情報）であり、業務サーバ１０３で管理される帳票情報の帳票テンプレートＩＤに対応する。

帳票生成サーバ１０４のＷｅｂサーバ３４１は、業務サーバ１０３からの帳票生成リクエストを受け付けると、リクエストに含まれる顧客情報と、帳票テンプレートＩＤを基にオーバレイ部３４３にオーバレイ出力を指示する。オーバレイ部３４３は、該当の帳票テンプレート情報の帳票テンプレートＵＲＬにアクセスしてフォーム情報ファイルをストレージサーバ１０６から取得してフォーム情報を取り出し、該当の顧客情報と重ね合わせてオーバレイ出力しＰＤＦファイルを生成する。帳票テンプレートＵＲＬは、帳票テンプレートが格納された位置を示すＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である。

また、帳票生成サーバ１０４の帳票情報管理部３４２は、出力したＰＤＦファイルを、ストレージサーバ１０６のライフサイクル管理領域にＰＤＦファイルの情報を記述したオーバレイインデックスファイルとともに管理する。オーバレイインデックスファイルについては後述する。さらに、帳票生成サーバ１０４の帳票情報管理部３４２は、出力したＰＤＦの情報を変換サーバ１０５に送信し、Ｗｅｂ帳票文書への変換リクエストを行う。

帳票情報管理部３４２が管理し、ストレージ３４５に保持する帳票データ情報の例を表４に示す。

帳票データ情報は、帳票生成サーバ１０４で管理される帳票文書データについてのデータテーブルである。オーバレイＩＤは、業務サーバ１０３から帳票生成リクエストを受け付けた際に帳票情報管理部３４２が発行するＩＤであり、オーバレイ処理を一意に識別可能なＩＤである。オーバレイインデックスファイルＵＲＬは、オーバレイ部３４３が生成するＰＤＦファイルに関する情報が記載されたインデックスファイルにアクセスするためのＵＲＬである。オーバレイ処理を開始した時点でオーバレイ部３４３がオーバレイインデックスファイルを生成する。オーバレイインデックスファイルについては後述する。変換ＩＤは、帳票生成サーバ１０４が変換サーバ１０５に対して変換リクエストを発行した際に、変換サーバ１０５が発行し応答として返すＩＤであり、変換処理を一意に識別可能なＩＤである。変換インデックスファイルＵＲＬは、変換インデックスファイルを取得するためのＵＲＬである。変換インデックスファイルについては後述する。

帳票生成サーバ１０４は、変換サーバ１０５に対して変換ＩＤを指定して変換情報取得リクエストを行う。応答として変換インデックスファイルＵＲＬが返された場合、帳票データ情報に保持する。

Ｗｅｂサーバ３４１は、クライアント端末１０２から帳票文書保存リクエストを受け付けると、リクエストに含まれるオーバレイＩＤをもとに該当帳票データ情報からオーバレイインデックスファイルＵＲＬにアクセスする。そして、保存文書生成部３４４は、取得したオーバレイインデックスファイルに記述されているＰＤＦファイルを取得して保存用帳票文書を生成する。

（変換サーバ）
変換サーバ１０５は、Ｗｅｂサーバ３５１、変換情報管理部３５２、データ変換部３５３、およびストレージ３５４を含んで構成される。各ソフトウェアモジュールは、変換サーバ１０５が備えるＨＤＤ２０４に記憶されており、ＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂサーバ３５１は、変換サーバ１０５の各種インターフェースを提供し、帳票生成サーバ１０４から帳票文書の変換リクエスト、および、変換情報取得リクエストを受け付け、応答を返す。変換情報管理部３５２は、変換データ情報をストレージ３５４に格納して管理する。

変換情報管理部３５２が管理し、ストレージ３５４に保持する変換情報の例を表５に示す。

変換情報は、変換情報管理部３５２で管理される変換処理についてのデータテーブルである。変換ＩＤは、帳票生成サーバ１０４から変換リクエストを受け付けた際に、変換情報管理部３５２が発行するＩＤであり、変換処理を一意に識別可能なＩＤである。オーバレイインデックスファイルＵＲＬは、変換対象のファイルに関する情報が記載されたインデックスファイルにアクセスするためのＵＲＬであり、帳票生成サーバ１０４から変換リクエストを受け付けた際に併せて受け取る。オーバレイインデックスファイルについては後述する。変換インデックスファイルＵＲＬは、変換インデックスファイルにアクセスするためのＵＲＬである。変換処理を開始した時点でデータ変換部３５３が変換インデックスファイルを生成する。変換インデックスファイルについては後述する。

データ変換部３５３は、オーバレイインデックスファイルを定期的に取得する。そして、データ変換部３５３は、オーバレイインデックスファイルに記述されている変換対象のデータを取得して変換を行い、その結果を変換インデックスファイルに記述する。また、変換サーバ１０５は、帳票生成サーバ１０４から変換ＩＤを指定した変換情報取得リクエストを受け付けると、変換情報管理部３５２が該当の変換情報を抽出して返す。

（ストレージサーバ）
ストレージサーバ１０６は、Ｗｅｂサーバ３６１、ファイル情報管理部３６２、およびストレージ３６３を含んで構成される。各ソフトウェアモジュールは、ストレージサーバ１０６が備えるＨＤＤ２０４に記憶されており、ＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂサーバ３６１は、ストレージサーバ１０６の各種インターフェースを提供する。ファイル情報管理部３６２は、ファイル情報を管理し、Ｗｅｂサーバ３６１で受け付けたリクエストに応じてファイルの入出力を行う。ストレージ３６３はファイル情報やストレージサーバ１０６が受信したファイルを格納する。

ファイル情報管理部３６２が管理するファイル情報の例を表６に示す。

ファイル情報は、ファイル情報管理部３６２で管理されるストレージサーバ１０６に保存するファイルの情報である。データＵＲＬは、ストレージサーバ１０６に保存するファイルを一意に識別するＵＲＬである。ファイルパスは、ストレージ上のファイルパスであり、ファイルの格納場所を示す。データＵＲＬに対するリクエストをＷｅｂサーバ３６１で受け付け、ファイル情報管理部３６２が該当するファイル情報を更新し、ストレージ３６３のファイル操作を行う。例えば、ストレージサーバ１０６に対してファイル操作を要求するクライアントは、データＵＲＬに対してＨＴＴＰ ＧＥＴメソッドをリクエストすることで、対応するファイルをダウンロード可能である。また、クライアントは、データＵＲＬに対してＨＴＴＰ ＰＵＴメソッドにファイル添付してリクエストすることで、ファイルをアップロードして保存可能である。さらに、クライアントは、データＵＲＬに対してＨＴＴＰ ＤＥＬＥＴＥメソッドをリクエストすることで、対応するファイルを削除可能である。

［インデックスファイル］
次に、帳票生成サーバ１０４のオーバレイ実行時、変換サーバ１０５の変換実行時にそれぞれ生成し、逐次更新を行うインデックスファイルについて説明する。

図６おいて、状態６００〜６３０は、帳票生成サーバ１０４と、変換サーバ１０５が夫々、オーバレイ出力処理、データ変換処理を実行する際に生成、更新を行うインデックスファイルの例（状態）を時系列に示したものである。帳票生成サーバ１０４、及び、変換サーバ１０５はまず、処理が開始された時点で、ストレージサーバ１０６のライフサイクル管理領域にインデックスファイルを生成する（状態６００）。本実施形態では、インデックスファイルはＪＳＯＮファイル形式を採用し、「ｄａｔａＬｉｓｔ」をキーとする処理結果のデータＵＲＬのリストと、「ｅｎｄ」をキーとする処理完了フラグを含んで構成される。帳票生成サーバ１０４、変換サーバ１０５が用いるインデックスファイルはそれぞれ同じ構成であるものとする。以下の説明において、帳票生成サーバ１０４がオーバレイ実行時に生成、更新するインデックスファイルを「オーバレイインデックスファイル」と称する。また、変換サーバ１０５が変換実行時に生成、更新するインデックスファイルを「変換インデックスファイル」と称する。以下の説明や図面において、オーバレイインデックスファイルを「ｐｄｆ−ｉｎｄｅｘ」とも示し、変換インデックスファイルを「ｓｖｇ−ｉｎｄｅｘ」とも示す。

本実施形態では、オーバレイ出力結果をＰＤＦファイルとし、ファイル出力単位は１ページ毎とする。例えば、３ページの帳票に対して３つのＰＤＦファイルが出力される。ただし、ファイル出力単位は１ページ毎とする必要はなく、複数ページ固定、全体ページ数から計算した値等、帳票生成サーバ１０４のオーバレイ部３４３で制御可能であればこれに限らない。また、変換サーバ１０５による変換処理もオーバレイ出力結果のＰＤＦファイル単位で変換を行う。

帳票生成サーバ１０４、および変換サーバ１０５は夫々の処理開始時に、初期状態のインデックスファイル（状態６００）を生成する。この時、ファイルは生成されていないため、「ｄａｔａＬｉｓｔ」は要素が空であり、処理結果を示す「ｅｎｄ」の値は“ｆａｌｓｅ”である。この後、帳票生成サーバ１０４、および変換サーバ１０５は夫々、順次処理を実行し、処理結果のファイルをストレージサーバ１０６のライフサイクル管理領域にアップロードし、そのデータＵＲＬを「ｄａｔａＬｉｓｔ」に追加する。状態６１０は、１ファイル目がアップロードされたインデックスファイルの状態を示す。状態６２０は、２ファイル目がアップロードされたインデックスファイルの状態を示す。さらに、帳票生成サーバ１０４、および変換サーバ１０５は夫々、最後のページである３ファイル目の処理結果のファイルをアップロードした時点で、インデックスファイルを状態６３０に更新する。状態６３０では、「ｄａｔａＬｉｓｔ」に３ファイル目に対応するデータＵＲＬが追加されているとともに、処理完了フラグ「ｅｎｄ」が“ｔｒｕｅ”に更新されている。

変換サーバ１０５は、オーバレイインデックスファイルをストレージサーバ１０６から取得して参照することで、帳票生成サーバ１０４のオーバレイ出力の進捗を把握し、オーバレイ出力が完了しているＰＤＦファイルから変換処理を開始することができる。また、クライアント端末１０２は、変換インデックスファイルをストレージサーバ１０６から取得して参照することで、変換サーバ１０５の変換処理の進捗を把握し、変換が完了しているＷｅｂ帳票文書をダウンロードして表示することができる。

［オーバレイ処理］
図４は、本実施形態に係るクライアント端末１０２のＷｅｂブラウザ３２１が業務サーバ１０３に帳票プレビューリクエストを発行し、帳票生成サーバ１０４がオーバレイ出力処理を開始し、変換サーバ１０５へ変換リクエストを行うまでのフローチャートである。本フローは、ユーザーがクライアント端末１０２のＷｅｂブラウザ３２１に表示した画面において帳票プレビュー要求操作を実行することによって開始される。

クライアント端末１０２は、ユーザーによりＷｅｂブラウザ３２１に表示された業務画面９００の帳票プレビューボタン４３０の押下を受け付ける。これに伴って、Ｓ４．１．１にて、Ｗｅｂブラウザ３２１は、顧客ＩＤと帳票情報９２０で選択されている帳票情報の帳票ＩＤを含めて、帳票プレビューリクエストを業務サーバ１０３に送信する。

図９は、クライアント端末１０２のＷｅｂブラウザ３２１から、業務サーバ１０３にアクセスして業務データを表示した場合の業務画面９００の例である。業務画面９００には、業務サーバ１０３が保持する顧客情報９１０と帳票情報９２０が表示されている。また、帳票情報９２０は、帳票情報として登録されている帳票情報のうちのひとつを選択可能な帳票選択ドロップダウンリストである。帳票情報９２０にて指定された帳票情報（文書データ）が、プレビューの対象として扱われる。プレビューボタン９３０は、帳票プレビュー要求操作を行うためのボタンである。

Ｓ４．１．２にて、業務サーバ１０３の業務情報管理部３３２は、Ｓ４．１．１にて受信した帳票プレビューリクエストに含まれる顧客ＩＤ、帳票ＩＤに該当する顧客情報、帳票テンプレートＩＤを指定し、帳票生成サーバ１０４に帳票生成リクエストを送信する。

Ｓ４．１．３にて、帳票生成サーバ１０４は、帳票生成リクエストを受信すると、帳票情報管理部３４２がオーバレイＩＤを発行して帳票データ情報に登録する。さらに、帳票生成サーバ１０４は、リクエストに対する応答として、業務サーバ１０３にオーバレイＩＤを返す。

Ｓ４．１．４にて、業務サーバ１０３は、クライアント端末１０２のＷｅｂブラウザ３２１に対し、帳票生成サーバ１０４から取得したオーバレイＩＤを返す。

また、帳票生成サーバ１０４の帳票情報管理部３４２は、Ｓ４．１．３と並行して、リクエストに含まれる帳票テンプレートＩＤを基に帳票テンプレート情報から帳票テンプレートＵＲＬを取得する。そして、帳票情報管理部３４２は、顧客情報とともに、オーバレイ部３４３にオーバレイ出力指示を行う。

Ｓ４．２．１にて、帳票生成サーバ１０４のオーバレイ部３４３は、オーバレイ出力指示を受けると、オーバレイインデックスファイル（状態６００）を生成し、ストレージサーバ１０６のライフサイクル管理領域にアップロードする。

Ｓ４．２．２にて、オーバレイ部３４３は、Ｓ４．２．１でアップロードしたオーバレイインデックスファイル（状態６００）のデータＵＲＬを含む変換リクエストを変換サーバ１０５に送信する。

Ｓ４．２．３にて、オーバレイ部３４３は、ストレージサーバ１０６上の帳票テンプレートＵＲＬにアクセスしてフォーム情報ファイルを取得し、顧客情報と重ね合わせてオーバレイ処理を開始する。

Ｓ４．２．４．１にて、オーバレイ部３４３は、オーバレイ出力結果としてＰＤＦファイル（ＰＤＦ０１）を出力する。

Ｓ４．２．４．２にて、オーバレイ部３４３は、Ｓ４．２．４．１にて生成したＰＤＦファイル（ＰＤＦ０１）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。

Ｓ４．２．４．３にて、オーバレイ部３４３は、Ｓ４．２．４．２にてアップロードしたＰＤＦファイル（ＰＤＦ０１）のデータＵＲＬをオーバレイインデックスファイルの「ｄａｔａＬｉｓｔ」に追記する（状態６１０）。そして、オーバレイ部３４３は、このオーバレイインデックスファイルを、Ｓ４．２．１と同じデータＵＲＬにアップロードする。

同様に、オーバレイ部３４３は、次のオーバレイ処理を行い（Ｓ４．２．５．１）、その出力結果ＰＤＦ（ＰＤＦ０２）をストレージサーバ１０６のライフサイクル管理領域にアップロードする（Ｓ４．２．５．２）。さらに、オーバレイ部３４３は、アップロードしたＰＤＦファイル（ＰＤＦ０２）のデータＵＲＬをオーバレイインデックスファイルの「ｄａｔａＬｉｓｔ」に追記する（状態６２０）。そして、オーバレイ部３４３は、このオーバレイインデックスファイルをＳ４．２．１と同じデータＵＲＬにアップロードする（Ｓ４．２．５．３）。

Ｓ４．２．６．１〜Ｓ４．２．６．３は、最後のページ単位のオーバレイ処理である。Ｓ４．２．６．１にて、オーバレイ部３４３は、オーバレイ出力結果としてＰＤＦファイル（ＰＤＦ０３）を出力する。

Ｓ４．２．６．２にて、オーバレイ部３４３は、Ｓ４．２．６．１にて生成したＰＤＦファイル（ＰＤＦ０３）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。

Ｓ４．２．６．３にて、オーバレイ部３４３は、「ｄａｔａＬｉｓｔ」にＳ４．２．６．２にてアップロードしたＰＤＦファイル（ＰＤＦ０３）のデータＵＲＬを追加する。さらに、オーバレイ部３４３は、処理完了フラグ「ｅｎｄ」を、完了を表す値である“ｔｒｕｅ”に更新する。そして、オーバレイ部３４３は、そのオーバレイインデックスファイル（状態６１０）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。なお、オーバレイ出力単位が多い場合は、Ｓ４．２．５．１〜Ｓ４．２．５．３の処理が繰り返されることとなる。

一方、変換サーバ１０５は、Ｓ４．２．２にて変換リクエストを受け付けると、Ｓ４．３．１にて、変換情報管理部３５２で変換ＩＤを発行し、これを変換リクエストの応答として帳票生成サーバ１０４に返す。また、変換サーバ１０５は、受け取ったオーバレイインデックスファイルＵＲＬと合わせて変換ＩＤを変換情報として登録する。また、変換情報管理部３５２は、データ変換部３５３にオーバレイインデックスファイルＵＲＬを渡し、変換指示を行う。データ変換部３５３は、変換指示を受けると、初期状態の変換インデックスファイル（状態６００）を生成してストレージサーバ１０６のライフサイクル管理領域にアップロードする。さらに、データ変換部３５３は、そのデータＵＲＬを該当の変換情報に登録する。

Ｓ４．４．１にて、帳票生成サーバ１０４は、Ｓ４．２．２の変換リクエストの応答で返された変換ＩＤをキーとして、変換サーバ１０５に定期的に変換情報の取得を行う。ここでの定期的な取得の間隔は特に限定するものではないが、予め規定されていてよい。Ｓ４．４．１の応答で得られる変換情報の変換インデックスファイルＵＲＬに値が存在した場合、帳票生成サーバ１０４は該当する帳票データ情報の変換インデックスファイルＵＲＬを更新し、Ｓ４．４．１の処理を終了する。

一方、クライアント端末１０２のＷｅｂブラウザ３２１は、Ｓ４．１．４でオーバレイＩＤを受け取った後、そのオーバレイＩＤを指定して定期的に帳票生成サーバ１０４へ帳票データ情報の取得を行う（Ｓ４．５．１）。ここでの定期的な取得の間隔は特に限定するものではないが、予め規定されていてよい。Ｓ４．５．１の応答に変換インデックスファイルＵＲＬが含まれる場合、Ｗｅｂブラウザ３２１はＳ４．５．１の処理を終了し、変換インデックスファイルの取得を開始する。この時、Ｗｅｂブラウザ３２１が取得する変換インデックスファイルの内容は、変換サーバ１０５で並列に行われている変換処理の進捗に応じて、図６の状態６００〜６３０のいずれかの状態となる。

［データ変換処理］
図５は、本実施形態に係る変換サーバ１０５のデータ変換と、クライアント端末１０２がＷｅｂ帳票文書を取得して表示するまでのフローチャートである。本フローの変換サーバ１０５のデータ変換は、Ｓ４．２．２において帳票生成サーバ１０４から変換リクエストを受信することによって開始される。本フローのクライアント端末１０２のＷｅｂ帳票文書表示フローは、クライアント端末１０２のＷｅｂブラウザ３２１が、図４に示すＳ４．５．１を終了して変換インデックスファイルの取得を開始することによって始まる。

変換サーバ１０５は、変換リクエストを受け付けると（図４に示すＳ４．２．２）、データ変換部３５３は、変換処理を開始する。

Ｓ５．１にて、データ変換部３５３は、変換リクエストに含まれるオーバレイインデックスファイルＵＲＬにアクセスしてオーバレイインデックスファイルをストレージサーバ１０６からダウンロードする。

Ｓ５．１．１．１にて、データ変換部３５３は、オーバレイインデックスファイルを参照し、「ｄａｔａＬｉｓｔ」にオーバレイ済みのデータＵＲＬが存在した場合（状態６１０）、そのデータＵＲＬからＰＤＦファイル（ＰＤＦ０１）を取得する。

Ｓ５．１．１．２にて、データ変換部３５３は、ＰＤＦファイル（ＰＤＦ０１）をＷｅｂ帳票文書（ＳＶＧ０１）へ変換する。

Ｓ５．１．１．３にて、データ変換部３５３は、Ｓ５．１．１．２にて生成したＷｅｂ帳票文書（ＳＶＧ０１）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。

Ｓ５．１．１．４にて、データ変換部３５３は、アップロードしたＷｅｂ帳票文書（ＳＶＧ０１）のデータＵＲＬを変換インデックスファイルの「ｄａｔａＬｉｓｔ」に追記し（状態６１０）、図４のＳ４．３．１と同じデータＵＲＬにアップロードする。以降、データ変換部３５３は、定期的にオーバレイインデックスファイルＵＲＬにアクセスしてオーバレイインデックスファイルを確認する。そして、データ変換部３５３は、Ｓ５．１．２．１〜Ｓ５．１．２．４、Ｓ５．１．３．１〜Ｓ５．１．３．４の処理を順次実行する。Ｓ５．１にて、オーバレイインデックスファイルの処理完了フラグ「ｅｎｄ」が“ｔｒｕｅ”であった場合（状態６３０）、データ変換部３５３は、Ｓ５．１．３．４において、変換インデックスファイルの処理完了フラグ「ｅｎｄ」を“ｔｒｕｅ”に更新する。Ｓ５．１．３．４では、「ｄａｔａＬｉｓｔ」に含まれるデータＵＲＬすべてに対しての変換処理が完了した時点である。これにより、変換インデックスファイルも状態６３０となる。

一方、Ｗｅｂブラウザ３２１は、図４のＳ４．５．１の応答で帳票データ情報の変換インデックスファイルＵＲＬを取得後、Ｓ５．２．１にて、変換インデックスファイルＵＲＬに定期的にアクセスし変換インデックスファイルをダウンロードする。ここでの定期的な取得の間隔は特に限定するものではないが、予め規定されていてよい。

Ｓ５．２．１にてダウンロードした変換インデックスファイルの「ｄａｔａＬｉｓｔ」にＵＲＬが存在した場合（状態６１０〜６３０）、Ｗｅｂブラウザ３２１は、そのデータＵＲＬからＷｅｂ帳票文書をダウンロードする。そして、Ｗｅｂブラウザ３２１は、ダウンロードしたＷｅｂ帳票文書をＷｅｂ帳票画面１０００に表示する（Ｓ５．２．１．１〜Ｓ５．２．１．３）。Ｗｅｂブラウザ３２１は、変換インデックスファイルの処理完了フラグ「ｅｎｄ」が“ｔｒｕｅ”となった時点（状態６３０）でＳ５．２．１の処理を終了する。

図１０は、Ｗｅｂブラウザ３２１に表示されるＷｅｂ帳票画面１０００の例である。Ｗｅｂ帳票画面１０００は、クライアント端末１０２のＷｅｂブラウザ３２１がＳ５．２．１、Ｓ５．２．１．１〜Ｓ５．２．１．３で取得し、表示した画面の例である。帳票画面１０２０は、Ｗｅｂブラウザ３２１が取得したＷｅｂ帳票文書を描画した例である。ページ情報１０１０は、取得したＷｅｂ帳票文書のページ数と現在表示中のページ数を示し、Ｓ５．２．１．１〜Ｓ５．２．１．３の処理進捗に従って変化する。保存ボタン１０３０は、帳票生成サーバ１０４に対して帳票文書の保存要求を実行するボタンである。

図４と図５に示すフローは、夫々のインデックスファイルの状態と内容を起点としており、帳票生成サーバ１０４のオーバレイ処理、変換サーバ１０５のデータ変換処理、クライアント端末１０２のＷｅｂ帳票文書の表示は並列して動作することができる。

帳票生成サーバ１０４は、オーバレイインデックスファイルをストレージサーバ１０６にアップロード（Ｓ４．２．１）した後、ＰＤＦ０１の処理が完了すると、Ｓ４．２．４．３でデータＵＲＬを追加（状態６１０に更新）する。続けて、帳票生成サーバ１０４は、ＰＤＦ０２の処理を開始する。このタイミングで、Ｓ５．１の処理にて定期的にオーバレイインデックスファイルを確認している変換サーバ１０５は、ＰＤＦ０１のデータＵＲＬが追加されたことを検知する。そして、変換サーバ１０５は、ＰＤＦ０１をＳＶＧ０１へ変換する処理を開始する（Ｓ５．１．１．１〜Ｓ５．１．１．４）。また、変換サーバ１０５は、ＳＶＧ０１の処理が完了すると、Ｓ５．１．１．４で変換インデックスファイルにＳＶＧ０１のデータＵＲＬを追加（状態６１０に更新）し、Ｓ５．１でＰＤＦ０２のデータＵＲＬが追加されたことを検知するとＰＤＦ０２の処理を行う。

さらに、クライアント端末１０２は、Ｓ４．５．１の応答として得られた変換インデックスファイルＵＲＬに定期的にアクセスし、変換インデックスファイルを確認する（Ｓ５．２．１）。Ｓ４．５．１で変換インデックスファイルＵＲＬが応答されるのは、Ｓ４．３．１で変換サーバ１０５が変換インデックスファイルを生成し、Ｓ４．４．１の応答として帳票生成サーバ１０４がそれを受け取ったタイミング以降となる。クライアント端末１０２は、変換インデックスファイルにＳＶＧ０１のデータＵＲＬが追加されたことを検知すると、Ｓ５．２．１．１でＳＶＧ０１を取得し、それをＷｅｂ帳票画面１０００に表示する。

また、帳票生成サーバ１０４は、ＰＤＦ０１の処理の後、ＰＤＦ０２、ＰＤＦ０３を継続して処理し、オーバレイインデックスファイルを順次更新する（状態６２０、６３０）。

一方、変換サーバ１０５はＳ５．１の確認を継続し、オーバレイインデックスファイルの更新を検知すると、ＳＶＧ０２、ＳＶＧ０３の変換処理を行い、変換インデックスファイルを更新する。

さらに、クライアント端末１０２は、同様にＳ５．２．１の確認を継続し、変換インデックスファイルの更新を検知すると、内容に応じてＳＶＧ０２、ＳＶＧ０３のデータを取得し、それらをＷｅｂ帳票画面１０００に表示する。

［帳票保存要求処理］
図７は、本実施形態に係るクライアント端末１０２における帳票保存要求処理を示すフローチャートである。本フローは、クライアント端末１０２が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、Ｗｅｂブラウザ３２１にて表示しているＷｅｂ帳票画面１０００に設けられた保存ボタン１０３０がユーザーにより押下されることにより開始される。

Ｓ７０１にて、クライアント端末１０２のＷｅｂブラウザ３２１は、ユーザーにより保存ボタン１０３０が押下されると、帳票生成サーバ１０４に対して帳票保存リクエストを行う。このとき、Ｗｅｂブラウザ３２１は、図４のＳ４．１．４で受け取ったオーバレイＩＤを帳票保存リクエストに含めて送信する。そして、本処理フローを終了する。

［帳票保存処理］
図８は、本実施形態に係る帳票生成サーバ１０４における帳票保存処理を示すフローチャートである。本フローは、帳票生成サーバ１０４が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、帳票生成サーバ１０４が、クライアント端末１０２から送信された帳票保存リクエストを受信したことに応じて開始される。

Ｓ８０１にて、保存文書生成部３４４は、帳票保存リクエストを受信すると、リクエストに含まれるオーバレイＩＤを取得する。

Ｓ８０２にて、保存文書生成部３４４は、取得したオーバレイＩＤからオーバレイ処理を特定し、帳票データ情報（表４）からオーバレイインデックスファイルＵＲＬを取得する。

Ｓ８０３にて、保存文書生成部３４４は、取得したオーバレイインデックスファイルＵＲＬにアクセスし、オーバレイインデックスファイルをダウンロードする。

Ｓ８０４にて、保存文書生成部３４４は、ダウンロードしたオーバレイインデックスファイルを参照し、「ｄａｔａＬｉｓｔ」に含まれる全てのデータＵＲＬにアクセスし、全てのＰＤＦファイルを取得する。

Ｓ８０５にて、保存文書生成部３４４は、ＰＤＦファイルの取得が成功したかを判定する。取得が成功したと判定された場合（Ｓ８０５にてＹＥＳ）Ｓ８０６へ進み、失敗したと判定された場合（Ｓ８０５にてＮＯ）Ｓ８０８へ進む。

Ｓ８０６にて、保存文書生成部３４４は、取得したＰＤＦファイルをページ順に全て結合し、保存用ＰＤＦファイルを生成する。本実施形態では、ＰＤＦファイルを１ページ目から順に生成（Ｓ４．２．４．１、Ｓ４．２．５．１、Ｓ４．２．６．１）し、生成した各ＰＤＦファイルのファイル名にＰＤＦ０１、ＰＤＦ０２のようにシーケンシャルな番号を付与している。ＰＤＦファイルを結合する際は、ＰＤＦファイル名のシーケンシャルな番号をもとに１ページ目から順にファイルを結合する。なお、ページ順に結合する手段はこの方法に限定されるものではなく、例えば、オーバレイインデックスファイルにページ番号情報を記述する方法であってもよい。ＰＤＦファイルを結合する処理は公知であるため、ここでの詳細な説明は省略する。その後、Ｓ８０７へ進む。

Ｓ８０７にて、保存文書生成部３４４は、生成した保存用ＰＤＦファイルをストレージサーバ１０６のライフサイクル管理領域に保存する。そして、本処理フローを終了する。

Ｓ８０８にて、保存文書生成部３４４は、帳票保存処理にてエラーが発生したものとしてエラー処理を行う。そして、本処理フローを終了する。ここでのエラー処理の内容は特に限定するものでは無いが、例えば、クライアント端末１０２に対し、保存が失敗した旨の通知を行うような処理であってもよい。

本実施形態では、分割生成したＰＤＦファイル、ＳＶＧファイル、および保存用ＰＤＦファイルを、ストレージサーバ１０６のライフサイクル管理領域にアップロードするため、これらファイルは、例えば一日経過すると削除される。しかしながら、各ファイルのライフサイクルはこれに限定されるものではない。例えば、保存用ＰＤＦファイルをストレージサーバ１０６により自動的に削除されないようにしてもよい。この場合、例えば、保存文書削除画面（不図示）にてユーザーが削除指示操作を行い、クライアント端末１０２のＷｅｂブラウザ３２１が帳票生成サーバ１０４に保存文書削除リクエストを行う。これにより、帳票生成サーバ１０４がストレージサーバ１０６から該保存用ＰＤＦファイルを削除する。

以上、本実施形態により、Ｗｅｂ帳票文書の画面に表示した保存ボタンを押下することにより保存に適したファイル形式で保存文書を生成することができる。その結果、Ｗｅｂ帳票文書を保存する際のユーザー操作の負荷を軽減できる。

＜第２の実施形態＞
第１の実施形態では、Ｗｅｂ帳票の全ページを保存文書に含める構成について説明した。本実施形態では、ユーザーが保存要求の実行時に保存するページを指定する方法について説明する。なお、本実施形態では、オーバレイ出力結果のＰＤＦファイルの出力単位を複数ページとする。７ページの帳票に対して３つのＰＤＦファイルを出力し、最初に生成するＰＤＦは１ページ、２つ目と３つ目のＰＤＦは３ページでそれぞれ構成されているものとして説明する。本実施形態について図面を用いて説明する。なお、第１の実施形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

［データ変換処理］
図１１は、本実施形態に係る変換サーバ１０５のデータ変換と、クライアント端末１０２がＷｅｂ帳票文書を取得して表示するまでのフローチャートである。本フローの変換サーバ１０５のデータ変換は、図４のＳ４．２．２において帳票生成サーバ１０４から変換リクエストを受信することによって開始される。図１１に示すクライアント端末１０２のＷｅｂ帳票文書表示フローは、クライアント端末１０２のＷｅｂブラウザ３２１が図４のＳ４．５．１を終了して変換インデックスファイルの取得の開始に応じて開始される。なお、第１の実施形態にて述べた図５と同様のフローにおいては、同じ符号を付与し、以下、差異部分のみ説明する。

Ｓ１１．１．２．２にて、変換サーバ１０５のデータ変換部３５３は、ＰＤＦファイル（ＰＤＦ０２）をＷｅｂ帳票文書へ変換する。このとき、上述したようにＰＤＦ０２は３ページで構成されている。ＳＶＧは１ファイルあたり１ページで構成されるため、ＰＤＦ０２をＳＶＧに変換するとＳＶＧが３ファイル分だけ生成される（ＳＶＧ０２〜０４）。

Ｓ１１．１．２．３にて、データ変換部３５３は、Ｓ１１．１．２．２にて生成したＷｅｂ帳票文書（ＳＶＧ０２〜０４）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。さらに、データ変換部３５３は、アップロードしたＷｅｂ帳票文書（ＳＶＧ０２〜０４）のデータＵＲＬを変換インデックスファイルの「ｄａｔａＬｉｓｔ」に追記し（状態６２０）、Ｓ４．３．１と同じデータＵＲＬにアップロードする（Ｓ５．１．２．４）。

一方、クライアント端末１０２のＷｅｂブラウザ３２１は、変換インデックスファイルの「ｄａｔａＬｉｓｔ」に存在するデータＵＲＬを参照してＷｅｂ帳票文書をダウンロードする。そして、Ｗｅｂブラウザ３２１は、ダウンロードしたＷｅｂ帳票文書をＷｅｂ帳票画面１０００に表示する（Ｓ５．２．１．１、Ｓ１１．２．１．２〜Ｓ１１．２．１．７）。

［帳票保存要求処理］
図１２は、本実施形態に係るクライアント端末１０２のＷｅｂブラウザ３２１の帳票保存要求処理を示すフローチャートである。本フローは、クライアント端末１０２が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、Ｗｅｂブラウザ３２１にて表示しているＷｅｂ帳票画面１０００に設けられた保存ボタン１０３０がユーザーにより押下されることにより開始される。なお、第１の実施形態にて述べた図７と同様の処理は、同じ符号を付与しており、以下、差異部分のみ説明する。

Ｓ１２０１にて、クライアント端末１０２のＷｅｂブラウザ３２１は、ユーザーにより保存ボタン１０３０が押下されると、保存ページ指定画面１４０１を表示する。

図１４は、保存ページ指定画面１４０１の例である。保存ページ指定画面１４０１には、全てのページを保存することを指定するラジオボタン１４０２、特定のページを保存することを指定するラジオボタン１４０３、保存するページ番号を入力するテキストボックス１４０４が表示されている。保存ボタン１４０５は、帳票生成サーバ１０４に対して帳票文書の保存要求の実行を指示するボタンである。図１４の例では、１〜５ページを保存するよう指定されている。

Ｓ１２０２にて、Ｗｅｂブラウザ３２１は、保存ページ指定画面１４０１を介して保存ページの指定および、保存ボタン１４０５の押下をユーザーから受け付ける。

Ｓ７０１にて、Ｗｅｂブラウザ３２１は、帳票生成サーバ１０４に対して帳票保存リクエストを行う。このとき、Ｗｅｂブラウザ３２１は、Ｓ４．１．４で受け取ったオーバレイＩＤ、および保存ページ指定画面１４０１で指定された保存ページ番号を帳票保存リクエストに含める。ラジオボタン１４０２が選択されている場合、Ｗｅｂブラウザ３２１は、保存ページ番号に「全ページ」を意味する値を設定して帳票保存リクエストを送信する。ラジオボタン１４０３が選択され、テキストボックス１４０４にページ番号が入力されている場合、Ｗｅｂブラウザ３２１は保存ページ番号にテキストボックス１４０４に入力された値を設定して帳票保存リクエストを送信する。そして、本処理フローを終了する。

［帳票保存処理］
図１３は、本実施形態に係る帳票生成サーバ１０４における帳票保存処理を示すフローチャートである。本フローは、帳票生成サーバ１０４が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、帳票生成サーバ１０４が、クライアント端末１０２から送信された帳票保存リクエストを受信したことに応じて開始される。なお、第１の実施形態にて述べた図８と同様の処理については、同じ符号を付与し、以下、差異部分のみ説明する。

Ｓ８０６にて、帳票生成サーバ１０４の保存文書生成部３４４は、Ｓ８０４にて取得したＰＤＦファイルをページ順に全て結合する。

Ｓ１３０１にて、保存文書生成部３４４は、クライアント端末１０２から受信した帳票保存リクエストにて指定された保存ページ番号を取得する。

Ｓ１３０２にて、保存文書生成部３４４は、保存ページ番号が「全ページ」を意味する値であるか否かを判定する。「全ページ」を意味する値でないと判定された場合（Ｓ１３０２にてＮＯ）Ｓ１３０３へ進み、「全ページ」を意味する値であると判定された場合（Ｓ１３０２にてＮＯ）Ｓ８０７へ進む。

Ｓ１３０３にて、保存文書生成部３４４は、保存ページ番号をもとに、保存しないページを算出する。本例では、Ｓ８０６にて結合したＰＤＦファイルは７ページで構成されている。従って、例えば、図１４の例に表示されている状態で保存ボタン１４０５が押下された場合、保存しないページは「６〜７ページ」となる。

Ｓ１３０４にて、保存文書生成部３４４は、Ｓ８０６にて結合したＰＤＦから保存しないページを削除する。そして、Ｓ８０７へ進む。

以上、本実施形態により、第１の実施形態の効果に加え、Ｗｅｂ帳票文書を保存する際にユーザーが保存するページを指定することができる。

＜第３の実施形態＞
本発明に係る第３の実施形態について図面を用いて説明する。なお第１および第２の実施形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

［帳票表示要求処理］
図１５は、本実施形態に係る業務サーバ１０３における帳票表示要求処理を示すフローチャートである。本フローは、業務サーバ１０３が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、Ｓ４．１．１にてクライアント端末１０２のＷｅｂブラウザ３２１が業務サーバ１０３に帳票プレビューリクエストを送信することによって開始される。なお、第１の実施形態にて述べた図４のフローに該当する処理については、同じ符号を付与している。

Ｓ１５０１にて、業務サーバ１０３は、クライアント端末１０２から帳票プレビューリクエストを受信する。

Ｓ４．１．２にて、業務情報管理部３３２は、帳票生成サーバ１０４に帳票生成リクエストを送信する。

Ｓ４．１．３にて、業務情報管理部３３２は、帳票生成サーバ１０４から帳票生成リクエストに対するレスポンスを受信する。

Ｓ１５０２にて、業務情報管理部３３２は、Ｓ４．１．１にて受信した帳票プレビューリクエストに含まれる帳票ＩＤをもとに、保存が必要な帳票であるか否かを判定する。なお、本実施形態では、保存が必要な帳票であるか（保存の可否）は帳票の種類毎に決められており、保存が必要な種類の帳票に対して、その指定を管理者が予め帳票情報のデータテーブルに設定しておくものとする。このデータテーブルは、例えば、業務サーバ１０３の記憶部にて保持される。保存が必要な帳票であると判定された場合（Ｓ１５０２にてＹＥＳ）Ｓ１５０３へ進み、保存が必要でないと判定された場合（Ｓ１５０２にてＮＯ）Ｓ４．１．４へ進む。

Ｓ１５０３にて、業務情報管理部３３２は、文書アップロードＵＲＬを生成する。文書アップロードＵＲＬとは、帳票生成サーバ１０４が生成した保存用ＰＤＦファイルをアップロードするためのＵＲＬである。

Ｓ１５０４にて、業務情報管理部３３２は、Ｓ１５０３にて生成した文書アップロードＵＲＬをクライアント端末１０２に対するレスポンスに含める。

Ｓ４．１．４にて、業務情報管理部３３２は、クライアント端末１０２からの帳票プレビューリクエストに対するレスポンスを返す。そして、本処理フローを終了する。なお、保存が必要でないと判定された場合（Ｓ１５０２にてＮＯ）、文書アップロードＵＲＬはレスポンスに含まれない。

［帳票データ情報取得要求処理］
図１６は、本実施形態に係るクライアント端末１０２における帳票データ情報取得要求処理を示すフローチャートである。本フローは、クライアント端末１０２が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、Ｓ４．１．４で業務サーバ１０３から帳票プレビューリクエストに対するレスポンスを受信することによって開始される。なお、第１の実施形態にて述べた図４のフローに該当する処理おいては、同じ符号を付与している。

Ｓ１６０１にて、クライアント端末１０２のＷｅｂブラウザ３２１は、帳票プレビューリクエストに対するレスポンスに文書アップロードＵＲＬが含まれているかを判定する。文書アップロードＵＲＬが含まれていると判定された場合（Ｓ１６０１にてＹＥＳ）Ｓ１６０２へ進み、含まれていないと判定された場合（Ｓ１６０１にてＮＯ）Ｓ４．５．１へ進む。

Ｓ１６０２にて、Ｗｅｂブラウザ３２１は、クエリパラメータにレスポンスに含まれていた文書アップロードＵＲＬを含める。そして、Ｓ４．５．１へ進む。

Ｓ４．５．１にて、Ｗｅｂブラウザ３２１は、帳票生成サーバ１０４へアクセスを行い、帳票データ情報の取得を行う。そして、本処理フローを終了する。

［帳票表示処理］
図１７は、本実施形態に係るクライアント端末１０２におけるＷｅｂ帳票表示処理を示すフローチャートである。本フローは、クライアント端末１０２が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、クライアント端末１０２がＳ４．５．１の応答で帳票データ情報の変換インデックスファイルＵＲＬを取得することによって開始される。なお、第１の実施形態にて述べた図５のフローに該当する処理おいては、同じ符号を付与しており、以下、差異部分のみ説明する。

Ｓ５．２．１．１〜Ｓ５．２．１．３にてＳＶＧファイルをダウンロードして表示した後、Ｓ１７０１にて、Ｗｅｂブラウザ３２１は、クエリパラメータに文書アップロードＵＲＬが含まれるかを判定する。クエリパラメータに文書アップロードＵＲＬが含まれると判定された場合（Ｓ１７０１にてＹＥＳ）Ｓ１７０２へ進み、含まれないと判定された場合（Ｓ１７０１にてＮＯ）本処理フローを終了する。つまり、クエリパラメータに文書アップロードＵＲＬが含まれないと判定された場合には、Ｗｅｂ帳票画面１０００上に保存ボタン１０３０は表示されず、ユーザーは保存処理を要求することができないこととなる。なお、保存ボタン１０３０は表示しつつ、押下ができないような状態に制御するような構成であってもよい。

Ｓ１７０２にて、Ｗｅｂブラウザ３２１は、Ｗｅｂ帳票画面１０００に保存ボタン１０３０を表示する。そして、本処理フローを終了する。

［帳票保存要求処理］
図１８は、本実施形態に係るクライアント端末１０２における帳票保存要求処理を示すフローチャートである。本フローは、クライアント端末１０２が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、Ｗｅｂブラウザ３２１にて表示しているＷｅｂ帳票画面１０００に設けられた保存ボタン１０３０がユーザーにより押下されることにより開始される。なお、第１の実施形態にて述べた図７と同様の処理は、同じ符号を付与し、以下、差異部分のみ説明する。

Ｓ１８０１にて、クライアント端末１０２のＷｅｂブラウザ３２１は、ユーザーにより保存ボタン１０３０が押下されると、クエリパラメータに文書アップロードＵＲＬが含まれるか否かを判定する。クエリパラメータに文書アップロードＵＲＬが含まれると判定された場合（Ｓ１８０１にてＹＥＳ）Ｓ１８０２へ進み、含まれないと判定された場合（Ｓ１８０１にてＮＯ）Ｓ７０１へ進む。

Ｓ１８０２にて、Ｗｅｂブラウザ３２１は、帳票保存リクエストに文書アップロードＵＲＬを含める。そして、Ｓ７０１へ進む。

Ｓ７０１にて、Ｗｅｂブラウザ３２１は、帳票保存リクエストを帳票生成サーバ１０４に送信する。そして、本処理フローを終了する。なお、文書アップロードＵＲＬが含まれないと判定された場合、帳票保存リクエストに文書アップロードＵＲＬは含まれない。

［帳票保存処理］
図１９は、本実施形態に係る帳票生成サーバ１０４における帳票保存処理を示すフローチャートである。本フローは、帳票生成サーバ１０４が備えるＣＰＵ２０１が対応するプログラムをＨＤＤ２０４等から読み出して実行することにより実現される。本実施形態では、帳票生成サーバ１０４が、クライアント端末１０２から送信された帳票保存リクエストを受信したことに応じて開始される。なお、第１の実施形態にて述べた図８と同様の処理については、同じ符号を付与し、以下、差異部分のみ説明する。

Ｓ８０６にて、帳票生成サーバ１０４の保存文書生成部３４４は、Ｓ８０４にて取得したＰＤＦファイルをページ順に全て結合する。

Ｓ１９０１にて、保存文書生成部３４４は、クライアント端末１０２から受信した帳票保存リクエストが文書アップロードＵＲＬを含むか否かを判定する。帳票保存リクエストに文書アップロードＵＲＬを含むと判定された場合（Ｓ１９０１にてＹＥＳ）Ｓ１９０２へ進み、含まないと判定された場合（Ｓ１９０１にてＮＯ）Ｓ８０７へ進む。

Ｓ１９０２にて、保存文書生成部３４４は、Ｓ８０６にて結合したＰＤＦファイルを該文書アップロードＵＲＬが示す場所に対して送信する。そして、本処理フローを終了する。

Ｓ８０７にて、保存文書生成部３４４は、Ｓ８０６にて結合したＰＤＦファイルをストレージサーバ１０６のライフサイクル管理領域に保存する。そして、本処理フローを終了する。

以上、本実施形態により、第１の実施形態の効果に加え、保存が必要な帳票文書である場合のみＷｅｂ帳票画面に保存ボタンを表示し、保存が不要な帳票文書である場合は保存操作を無効とすることにより、意図せずに文書が保存されることを抑止できる。

＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０２…クライアント端末、１０３…業務サーバ、１０４…帳票生成サーバ、１０５…変換サーバ、１０６…ストレージサーバ

Claims (10)

1. 文書生成システムであって、
   文書データから、第１のファイル形式の複数の帳票データを生成する生成手段と、
   前記第１のファイル形式の複数の帳票データを、第２のファイル形式の複数の帳票データに変換する変換手段と、
   前記変換手段にて変換された第２のファイル形式の複数の帳票データを、保存要求を受け付け可能に表示部に表示させる表示手段と、
   前記表示部にて表示させた第２のファイル形式の複数の帳票データに対する保存要求を受け付けたことに応じて、前記第２のファイル形式の複数の帳票データに対応する前記第１のファイル形式の複数の帳票データを１の第１のファイル形式のデータに結合して記憶部に保存させる保存手段と
   を有することを特徴とする文書生成システム。
2. 前記表示部は、クライアント端末のＷｅｂブラウザであり、
   前記保存要求は、前記Ｗｅｂブラウザに表示された保存ボタンが押下されることによりなされることを特徴とする請求項１に記載の文書生成システム。
3. 文書データの指定を受け付ける指定手段を更に有し、
   前記生成手段は、前記指定手段にて指定を受け付けた文書データから前記第１のファイル形式の複数の帳票データを生成することを特徴とする請求項１または２に記載の文書生成システム。
4. 前記表示部にて表示させた前記第２のファイル形式の複数の帳票データのうち、保存させる帳票データの指定を受け付ける受け付け手段を更に有し、
   前記保存手段は、前記受け付け手段にて受け付けた帳票データに対応する前記第１のファイル形式の帳票データを１の前記第１のファイル形式のデータに結合して前記記憶部に保存させることを特徴とする請求項１乃至３のいずれか一項に記載の文書生成システム。
5. 文書データの種類に基づいて、当該文書データの保存の可否を判定する判定手段を更に有し、
   前記表示手段は、前記判定手段にて保存ができないと判定された文書データに対応する第２のファイル形式の帳票データを前記表示部に表示させる際には、前記保存要求の受け付けができないように制御することを特徴とする請求項１乃至４のいずれか一項に記載の文書生成システム。
6. 前記生成手段にて生成された第１のファイル形式の複数の帳票データと、前記変換手段にて変換された第２のファイル形式の複数の帳票データはそれぞれ、所定の時間が経過した後に削除される保存領域に保存され、
   前記保存手段にて保存された第１のファイル形式のデータは、ユーザーによる削除指示がなされるまで保存されることを特徴とする請求項１乃至５のいずれか一項に記載の文書生成システム。
7. 前記第１のファイル形式は、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）形式であり、
   前記第２のファイル形式は、ＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）形式である、ことを特徴とする請求項１乃至６のいずれか一項に記載の文書生成システム。
8. 前記生成手段、前記変換手段、前記表示部、および前記記憶部はそれぞれ異なる装置に設けられることを特徴とする請求項１乃至７のいずれか一項に記載の文書生成システム。
9. 文書生成システムの制御方法であって、
   文書データから、第１のファイル形式の複数の帳票データを生成する生成工程と、
   前記第１のファイル形式の複数の帳票データを、第２のファイル形式の複数の帳票データに変換する変換工程と、
   前記変換工程にて変換された第２のファイル形式の複数の帳票データを、保存要求を受け付け可能に表示部に表示させる表示工程と、
   前記表示部にて表示させた第２のファイル形式の複数の帳票データに対する保存要求を受け付けたことに応じて、前記第２のファイル形式の複数の帳票データに対応する前記第１のファイル形式の複数の帳票データを１の第１のファイル形式のデータに結合して記憶部に保存させる保存工程と
   を有することを特徴とする制御方法。
10. １または複数のコンピュータを動作させることにより、
    文書データから、第１のファイル形式の複数の帳票データを生成する生成手段と、
    前記第１のファイル形式の複数の帳票データを、第２のファイル形式の複数の帳票データに変換する変換手段と、
    前記変換手段にて変換された第２のファイル形式の複数の帳票データを、保存要求を受け付け可能に表示部に表示させる表示手段と、
    前記表示部にて表示させた第２のファイル形式の複数の帳票データに対する保存要求を受け付けたことに応じて、前記第２のファイル形式の複数の帳票データに対応する前記第１のファイル形式の複数の帳票データを１の第１のファイル形式のデータに結合して記憶部に保存させる保存手段と
    を備える文書生成システムとして機能させるためのプログラム。

Images