JP2011215826A

JP2011215826A - 帳票生成装置、帳票生成装置の制御方法、プログラム

Info

Publication number: JP2011215826A
Application number: JP2010082801A
Authority: JP
Inventors: Kensuke Tsutsumi; 健介堤
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2010-03-31
Filing date: 2010-03-31
Publication date: 2011-10-27
Anticipated expiration: 2030-03-31
Also published as: US20110246867A1; JP5538981B2

Abstract

【課題】ユーザが帳票生成サービスにおいて行われたデータの修正を確認可能な情報処理装置を提供する。
【解決手段】データ管理サービス１０１と通信可能な帳票生成サービス１０２であって、フォームを管理するフォーム管理部５１６と、データ管理サービス１０１からデータを取得するリクエスト処理部５１４と、取得されたデータまたは、取得されたデータを元に変更されたデータを、フォームに対してオーバーレイするオーバーレイ実行部５１５と、オーバーレイされたデータが、変更されたデータである場合に、データ管理サービス１０１に対して変更の内容を通知するリクエスト処理部５１４を有する。
【選択図】図１２

Description

本発明は、オーバーレイに使用するデータの管理を行うデータ管理サービスと通信可能な帳票生成装置、帳票生成装置の制御方法、プログラムに関する。

近年、ネットワークインフラの整備によるネットワーク回線の高速化やグリッドコンピューティング技術の向上により、ネットワーク上に仮想マシンを構築できるクラウドサービスが普及し始めている。クラウドサービスの普及に伴い、クラウドサービス上の仮想マシンを利用してＳａａＳ（ＳｏｆｔｗａｒｅａｓａＳｅｒｖｉｃｅ）を提供する構成がとられるようになってきた。帳票生成サービスにおいても他のサービスとの連携が重要になってきている。ここで、帳票生成サービスとは、帳票データをフォームに対して合成（オーバーレイ）して帳票を生成するサービスである。帳票生成サービスと他のサービスとの連携としては、以下のようなサービスが例として考えられる。即ち、帳票生成サービスが他のサービスから保持されているデータを取得し、取得したデータを帳票データとしてフォームにオーバーレイするといったサービスである。

ここで、情報処理装置における帳票データのオーバーレイの際に、ユーザは、フォームに対してオーバーレイする帳票データを変更する場合がある。このような場合に、情報処理装置が、帳票データの変更履歴を保存する技術が特許文献１に記載されている。特許文献１では、変更履歴を残すことによってユーザは活動の履歴を知ることができ、また変更点の詳細を把握することができる。

特開２００１−００５８８７号公報

データを保持し、管理するデータ管理サービスと、オーバーレイを実行する帳票生成サービスとの連携において、帳票生成サービスがオーバーレイ実行する直前にデータ管理サービスから取得したデータを一時的に変更したいというニーズがある。しかし帳票生成サービスでデータを一時的に変更して帳票を生成した場合、データ管理サービスにはデータ変更は反映されない。そのため、帳票生成サービスにより作成された帳票が、元のデータが使われた帳票なのか、変更後のデータが使用された帳票なのかデータ管理サービスを使用しているユーザは認識することができないという課題がある。

上述した特許文献１の方法によってデータの修正・変更内容をオーバーレイするフォームと紐付けて履歴情報として保存することによって、ユーザは履歴情報から修正・変更内容を知ることができる。しかし、オーバーレイ実行するサービスとデータ管理するサービスが異なる場合、オーバーレイ直前の一時的なデータ変更はデータ管理サービスに反映されず、作成された帳票に使用されたデータをユーザは認識することができない。

上記の課題を解決するため、本発明は、ユーザが、帳票生成サービスにおいて行われたデータの修正を確認可能な情報処理装置を提供することを目的とする。

上記の課題を解決するため、本発明に係る帳票システムは、フォームに対してオーバーレイするためのデータを管理するデータ管理サービスと通信可能な帳票生成システムであって、前記フォームを管理する管理手段と、前記データ管理サービスから前記データを取得する取得手段と、前記取得手段により取得されたデータまたは、前記取得手段により取得されたデータを元に変更されたデータを、前記フォームに対してオーバーレイするオーバーレイ手段と、前記フォームに対してオーバーレイされたデータが、前記取得手段により取得されたデータを元に変更されたデータである場合に、前記データ管理サービスに対して前記変更の内容を通知する通知手段とを有することを特徴とする。

データ管理システムのデータを外部のシステムで一時的にデータを変更した場合に、データを変更したこと、及び変更内容をデータ管理システムに通知することにより、ユーザはデータ管理システムの画面で外部システムにおけるデータ変更を知ることができる。

本発明の一実施例に適用される帳票システムの構成を示すブロック図。本発明の一実施例に適用されるコンピュータのハードウェア構成図。（ａ）は本発明の一実施例に適用されるデータ管理サービスのハードウェア構成図。（ｂ）は本発明の一実施例に適用されるデータ管理サービスのソフトウェア構成図。（ａ）はデータ管理サービスが保持するレコード情報の一例を示す図。（ｂ）はデータ管理サービスが保持する履歴情報の一例を示す図。（ａ）は本発明の一実施例に適用される帳票生成サービスのハードウェア構成図。（ｂ）は本発明の一実施例に適用される帳票生成サービスのソフトウェア構成図。（ａ）は帳票生成サービスが保持するリクエスト情報の一例を示す図。（ｂ）は帳票生成サービスが保持するフォーム対応情報の一例を示す図。（ｃ）は帳票生成サービスが保持するデータ取得クエリファイルの一例を示す図。（ａ）はデータ管理サービスが生成するログイン画面の一例を示す図。（ｂ）はデータ管理サービスが生成する商談画面の一例を示す図。（ａ）は帳票生成サービスが生成するフォーム選択画面の一例を示す図。（ｂ）は帳票生成サービスが生成するデータ確認画面の一例を示す図。帳票生成サービスのリクエスト受信時の処理を示すフローチャート。帳票生成サービスのデータ取得リクエスト受信時の処理を示すフローチャート。帳票生成サービスのオーバーレイ実行リクエスト受信時の処理を示すフローチャート。帳票生成サービスの帳票生成処理の処理を示すフローチャート。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

＜システム構成＞
図１は、本発明において本施例に適用される帳票システムの構成を示すブロック図である。図１において、帳票システムは、データ管理サービス１０１、帳票生成サービス１０２、クライアント１０４により構成され、それぞれの構成は、通信回線１０３を介して通信可能に接続される。

データ管理サービス１０１は、帳票作成の際に、フォームに対してオーバーレイされるデータを保持、管理するサービスであり、クライアント１０４に対して、Ｗｅｂページを介したデータの確認・編集などのサービスを提供する。帳票生成サービス１０２は、フォームを管理しており、データ管理サービス１０１からデータ取得を行い、オーバーレイを実行することでクライアントの所望する帳票を生成するサービスである。

クライアント１０４は、Ｗｅｂブラウザが配備されているコンピュータであり、Ｗｅｂブラウザを介してデータ管理サービス１０１及び、帳票生成サービス１０２に対してリクエストを行う。通信回線１０３は、いわゆる通信ネットワークである。通信回線１０３は、例えばインターネットやイントラネット等のＬＡＮ，ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか又はこれらの組み合わせにより実現される。通信回線１０３は、データの送受信が可能であればよく、クライアント１０４からデータ管理サービス１０１や帳票生成サービス１０２への通信手段、データ管理サービス１０１から帳票生成サービス１０２への通信手段が異なっていてもよい。

＜クライアント１０４＞
図２は、クライアント１０４に適用される基本的なコンピュータ（情報処理装置）のハードウェア構成を示すブロック図である。

図２において、コンピュータは、外部機器Ｉ／Ｆ２０１、ＮｅｔＷｏｒｋＩ／Ｆ２０２、ＣＰＵ２０３、ＲＯＭ２０４、ＲＡＭ２０５、ＨＤＤ２０６、入力装置２０７、表示装置２０８により構成され、それぞれの構成はシステムバスを介して互いに接続されている。システムバスは、例えば、ＰＣＩバス、ＡＧＰバス、及びメモリバス等から成る。尚、図２では、各バス問の接続用チッブや、いわゆるＳＣＳＩやＡＴＡＰＩのような構成要素間の入出力用インターフェースは省略されている。

ＣＰＵ２０３は、ＲＯＭ２０４またはＨＤＤ２０６に記憶されたプログラムをＲＡＭ２０５に読み込み、このプログラムに基づき処理を実行することによって、コンピュータ上の各処理を司る。ＲＯＭ２０４は、本装置の各処理に関わるプログラムやデータを記憶する。ＲＡＭ２０５は、本装置の各処理に関わる一時的なデータを電気的に記憶する。ＨＤＤ２０６は、本装置の各処理に関わるプログラムやデータ、及び一時的なデータ等を記憶する。

入力装置２０７は、ユーザからの本装置への指示入力を受け付けるキーボードやポインティングデバイスである。表示装置２０８は、本装置の動作状況や、本装置上で動作する各プログラムが出力する情報を表示する。ＮｅｔｗｏｒｋＩ／Ｆ２０２は、ネットワーク経由でＬＡＮ及びインターネットに接続し、外部と情報交換を行う。外部機器Ｉ／Ｆ２０１は外部記憶機器等を接続する。

クライアント１０４は情報処理を行うためのクライアントコンピュータである。尚、クライアント１０４で動作する各ソフトウェアモジュールはＲＯＭ２０４またはＨＤＤ２０６に記憶されている。そして、各ソフトウェアモジュールは、ＣＰＵ２０３によってＲＡＭ２０５にロードされ実行される。各クライアント１０４は図示省略したネットワークインタフェースを介し通信回線１０３に接続されている。クライアント１０４はそれぞれ永続記憶装置を接続したコンピュータであってもよいし、一時記憶装置のみによって構成されたＴｈｉｎＣｌｉｅｎｔ構成をとってもよい。クライアント１０４にはＷｅｂブラウザが配備されており、ユーザの指示に従ってＷｅｂブラウザを用いてＷｅｂサーバにリクエストを行ったり、ＷｅｂブラウザからのＨＴＭＬを解析し画面に表示したりできる。尚、Ｗｅｂブラウザの画面は、表示装置２０８に表示され、ユーザからの指示は入力装置２０７を介して入力される。

＜データ管理サービス１０１＞
図３（ａ）は、データ管理サービスに適用される基本的なコンピュータ（データ管理装置、データ管理システム）のハードウェア構成を示すブロック図である。尚、外部機器Ｉ／Ｆ３０１、ＮｅｔＷｏｒｋＩ／Ｆ３０２、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤＤ３０６、入力装置３０７、表示装置３０８の各構成は、図２のクライアント１０４の構成と同様であるため詳細な説明は省略する。

図３（ｂ）は、本実施例に適用される、データ管理サービス１０１のソフトウェア構成を示した図である。尚、図３（ｂ）に示される各ソフトウェアモジュールはＨＤＤ３０６に記憶されており、前述したようにデータ管理サービス１０１のＣＰＵ３０３によってデータ管理サービス１０１のＲＡＭ３０５にロードされ実行される。データ管理サービス１０１は、Ｗｅｂサーバ部３１１、レコード管理部３１５により構成される。

Ｗｅｂサーバ部３１１は、リクエスト処理部３１２、画面生成部３１３、ロジック部３１４からなる。リクエスト処理部３１２は、クライアント１０４及び帳票生成サービス１０２から通信回線１０３を介してリクエストを受信する。そして、リクエスト処理部３１２は、受信したリクエストに対するレスポンスの生成をロジック部３１４に依頼し、ロジック部３１４により生成されたレスポンスをクライアント１０４又は帳票生成サービス１０２に返す。リクエスト処理部３１２は、クライアント１０４からのリクエストにはレスポンスとしてクライアント１０４の表示装置２０８にＷｅｂブラウザで表示させるためのＷｅｂページや、リダイレクトするための情報（リダイレクト情報）を返す。リクエスト処理部３１２は、帳票生成サービス１０２からのリクエストにはＸＭＬ形式にフォーマットした情報をレスポンスとして返す。リクエスト処理部３１２が受け付けるリクエストにはログインリクエスト、帳票生成リクエスト、データ取得リクエスト、履歴通知リクエスト、ファイルアップロードリクエストなどがある。

画面生成部３１３は、Ｗｅｂページ生成に必要な画像やＨＴＭＬ、スタイルなどの画面情報を管理する。画面生成部３１３はロジック部３１４からの指示によりＨＤＤ３０６から画面情報を取得しロジック部３１４に提供する。

ロジック部３１４は、リクエスト処理部３１２が受け付けたリクエストに応じてレスポンスを生成しリクエスト処理部３１２に渡す。レスポンスの種類には、Ｗｅｂページ、ＸＭＬデータ、リダイレクト情報などがある。ロジック部３１４は、Ｗｅｂページのレスポンスを生成する場合に、画面生成部３１３により生成された画面情報に対してレコード管理部３１５により保持されるレコード情報、履歴情報を挿入することでＷｅｂページを生成する。また、ロジック部３１４は、ＸＭＬのレスポンスを生成する場合に、レコード管理部３１５からレコード情報を取得しＸＭＬ形式に成形する。また、ロジック部３１４は、リダイレクト情報のレスポンスを生成する場合に、事前に登録されているリダイレクト先とリダイレクト先に渡すパラメータ情報を、クライアント１０４でリダイレクトされる形式に成形する。クライアント１０４でのリダイレクト方法としては、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）の＜ｍｅｔａ＞タグを用いた方法や、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔを用いた方法などがある。尚、ロジック部３１４の処理フローの詳細は後述する。

レコード管理部３１５は、ＨＤＤ３０６に記憶されているレコード情報や履歴情報の読み書きを行うとともに、その管理をする。レコード管理部３１５は、ロジック部３１４からの情報取得指示によりＨＤＤ３０６から該当の情報を読み出しロジック部３１４に返す。またレコード管理部３１５は、ロジック部３１４からの情報更新指示によりＨＤＤ３０６に記憶されている情報を更新する。

図４（ａ）は、データ管理サービス１０１のレコード管理部３１５が管理するレコード情報の一例を示す図である。レコード情報４００は、組織ＩＤ４０１、ユーザＩＤ４０２、テーブルＩＤ４０３、レコードＩＤ４０４、商談名４０５、作成者４０６、日付４０７、担当者４０８、取引先４０９、住所４１０、品名４１１、数量４１２、価格４１３からなる。

組織ＩＤ４０１、ユーザＩＤ４０２、テーブルＩＤ４０３、レコードＩＤ４０４はそれぞれ組織、ユーザ、テーブル、レコードを一意に識別するＩＤである。これらのＩＤによってレコード管理部３１５は、一つのレコード情報４００を識別することができる。ここでデータ管理サービス１０１におけるユーザは、ユーザＩＤとともにユーザ情報として記憶されており、データ管理サービス１０１がログインリクエスト受け付け時に認証に利用する。ユーザ情報にはユーザ名、パスワードやユーザＩＤなどがある。またデータ管理サービス１０１において定義される組織には複数ユーザが属することができ、ユーザを組織（グループ）として管理することが出来る。定義された組織には組織ＩＤ４０１が割り振られ、その組織に所属するユーザのユーザ情報には組織ＩＤ４０１が記憶される。

図１の帳票システムにおいて、ユーザ認証はクライアント１０４からのログインリクエストを受け付けたデータ管理サービス１０１で行われる。帳票生成サービス１０２では認証された情報としてセッションＩＤを受け取ることによって、データ管理サービス１０１へのアクセスの認証を引き継ぐことができる。またデータ管理サービス１０１において処理単位でのテーブルを定義し組織内のユーザで共有することができる。テーブルには例えば商談、契約、レポートなどといった処理があり、それぞれにレコードが定義される。ユーザは定義されたテーブルを選択し作業を行う。本実施例ではテーブルの一例として商談が選択しているものとする。商談名４０５、作成者４０６、日付４０７、担当者４０８、取引先４０９、住所４１０、品名４１１、数量４１２、価格４１３は商談テーブルにおいて定義されたレコードの一例である。

図４（ｂ）は、データ管理サービス１０１のレコード管理部３１５が管理する履歴情報の一例を示す図である。履歴情報４２０は組織ＩＤ４２１、ユーザＩＤ４２２、テーブルＩＤ４２３、レコードＩＤ４２４、日付４２５、件名４２６、内容４２７からなる。組織ＩＤ４２１、ユーザＩＤ４２２、テーブルＩＤ４２３、レコードＩＤ４２４はそれぞれ組織、ユーザ、テーブル、レコードを一意に識別するＩＤであり、前述のレコード情報４００と同様である。その他、履歴が登録された日付４２５、履歴の件名４２６、履歴の詳細情報である内容４２７がある。

＜帳票生成サービス１０２＞
図５（ａ）は、帳票生成サービス１０２に適用される基本的なコンピュータ（帳票生成装置、帳票生成システム）のハードウェア構成を示すブロック図である。尚、外部機器Ｉ／Ｆ５０１、ＮｅｔＷｏｒｋＩ／Ｆ５０２、ＣＰＵ５０３、ＲＯＭ５０４、ＲＡＭ５０５、ＨＤＤ５０６、入力装置５０７、表示装置５０８の各構成は、図２のクライアント１０４の構成と同様であるため詳細な説明は省略する。

図５（ｂ）は、本実施例に適用される、帳票生成サービス１０２のソフトウェア構成を示した図である。尚、図５（ｂ）に示される各ソフトウェアモジュールはＨＤＤ５０６に記憶されており、前述したように帳票生成サービス１０２のＣＰＵ５０３によってデータ管理サービス１０１のＲＡＭ５０５にロードされ実行される。帳票生成サービス１０２は、Ｗｅｂサーバ部５１１、オーバーレイ実行部５１５、フォーム管理部５１６からなる。

Ｗｅｂサーバ部５１１はリクエスト処理部５１２、画面生成部５１３、ロジック部５１４からなる。画面生成部５１３の機能は先述のデータ管理サービス１０１の画面生成部３１３と同等であるため説明を省略し、リクエスト処理部５１２、ロジック部５１４について説明する。

リクエスト処理部５１２は、クライアント１０４から帳票生成リクエスト、フォーム選択リクエスト、オーバーレイ実行リクエストを受信する。そして、リクエスト処理部５１２は、Ｗｅｂページまたはプレビューファイルのレスポンスをクライアント１０４に対して返す。また、リクエスト処理部５１２は、データ管理サービス１０１に対してデータ取得リクエスト、履歴通知リクエスト、ファイルアップロードリクエストを行う。尚、本実施例において帳票生成リクエストにおいてクライアント１０４から渡される情報をリクエスト情報として説明するが詳細は図６を用いて後述する。

ロジック部５１４は、リクエスト処理部５１２が受け付けたリクエストに応じてレスポンスを生成しリクエスト処理部５１２に渡す。また、ロジック部５１４は、リクエスト処理部５１２に対してデータ取得リクエスト、履歴通知リクエスト、ファイルアップロードリクエストの依頼を行う。ロジック部５１４は、データ管理サービス１０１へのデータ取得リクエストで得られたデータを持ってオーバーレイ実行部５１５に対してオーバーレイ実行指示を行い、オーバーレイ実行結果を受け取る。ロジック部５１４の処理フローの詳細は後述する。

オーバーレイ実行部５１５は、ロジック部５１４からのオーバーレイ実行指示を受け、フォーム管理部５１６よりフォームを取得し、取得したフォームに対して、オーバーレイ実行指示時に渡されたデータをオーバーレイする。そしてオーバーレイの実行により生成された帳票データをロジック部５１４に返す。また、オーバーレイ実行部５１５はフォーム対応情報を保持する。フォーム対応情報の詳細は図６を用いて後述する。

フォーム管理部５１６は、フォームの登録や取得などの管理を行う。フォーム管理部５１６で管理されるフォームは、オーバーレイ実行で変更されない定型の文字列や画像などの定型領域と、オーバーレイ実行時にデータを入れ込む可変領域がある。そして、オーバーレイ実行部５１５が、フォームの可変領域にデータを入れ込むことでオーバーレイが実行され、帳票データが生成される。フォームやオーバーレイの処理の詳細については一般的な方法が用いられるため、本明細書においては説明を省略する。

図６（ａ）は、リクエスト処理部５１２が帳票実行リクエストを受け付けたときにクライアント１０４から渡されるリクエスト情報の一例を示す図である。リクエスト情報６００はＵＲＬのパラメータとして渡されても、ＨＴＭＬ内のデータとして渡されてもよく、リクエストの形式は問わない。リクエスト情報６００はＵＲＬ６０１、セッションＩＤ６０２、組織ＩＤ６０３、ユーザＩＤ６０４、テーブルＩＤ６０５、レコードＩＤ６０６からなる。リクエスト情報６００はデータ管理サービス１０１へのデータ取得リクエストする際に用いられる情報であり、ＵＲＬ６０１はデータ取得リクエストのリクエスト先である。セッションＩＤ６０２はデータ管理サービス１０１で発行されたＩＤであり、セッションＩＤをデータ取得リクエストに加えることにより認証が行われる。組織ＩＤ６０３、ユーザＩＤ６０４、テーブルＩＤ６０５、レコードＩＤ６０６は先述のレコード情報４００のものと同様であり、一意のレコードを識別するための情報である。

図６（ｂ）は、データ管理サービス１０１でのテーブルと、データ管理サービス１０１へのデータ取得リクエスト時に実行するクエリファイルと、フォームを対応付けるためのフォーム対応情報６１０である。フォーム対応情報６１０は組織ＩＤ６１１、テーブルＩＤ６１２、表示名６１３、フォームパス６１４、データ取得クエリファイルパス６１５からなる。組織ＩＤ６１１、テーブルＩＤ６１２は、先述したレコード情報４００のものと同様であり、組織ＩＤ６１１、テーブルＩＤ６１２よりテーブルを一意に識別するための情報である。表示名６１３は、図８にて後述するフォーム選択画面に表示されるフォームの表示名である。フォームパス６１４はフォームが格納されているファイルパスである。データ取得クエリファイルパス６１５はデータ管理サービス１０１へのデータ取得リクエストで実行されるクエリファイルのファイルパスである。

図６（ｃ）は、データ取得クエリファイルの一例を示す図である。データ取得クエリファイル６２０は、ＦＲＯＭ句、ＷＨＥＲＥ句、ＳＥＬＥＣＴ句からなる。ＦＲＯＭ句、ＷＨＥＲＥ句にて、それぞれ取得したいテーブルとレコードが指定されている。ＳＥＬＥＣＴ句にて、取得したい項目（取得キー）が指定されている。オーバーレイ実行時にはＳＥＬＥＣＴ句の並び順でフォームの可変領域にデータがオーバーレイされることとなる。

＜データ管理サービス１０１画面＞
図７（ａ）はデータ管理サービス１０１で生成され、クライアント１０４の表示装置２０８にＷｅｂブラウザの画面として表示されるログイン画面の一例である。ログイン画面７００は、データ管理サービス１０１への初回アクセス時に表示される画面である。ユーザの操作により、ユーザ名７０１、パスワード７０２の領域それぞれに対して入力が行われ、ログインボタン７０３を押下されることにより、入力されたユーザ名、パスワードでデータ管理サービス１０１にログインリクエストが行われる。ログインリクエストを受け付けたデータ管理サービス１０１は認証を行い、認証に成功した場合にレスポンスとして商談画面７１０を返す。認証に失敗した場合にはログイン失敗のメッセージとともに再度ログイン画面７００が表示される。

図７（ｂ）はデータ管理サービス１０１にログインリクエストを行った後にレスポンスとして返される商談画面の一例を示す図である。商談画面７１０は、商談選択７１１、商談情報７１２、添付ファイル７２１、履歴７２２の各領域からなる。商談選択７１１では、事前に登録された商談情報をプルダウンで選択することができ、プルダウンで選択された商談の情報が商談情報７１２、添付ファイル７２１、履歴７２２に表示される。商談の登録や削除などの操作については本発明と関係しないため省略する。

商談情報７１２は、商談の作成者７１３、日付７１４、担当者７１５、取引先７１６、住所７１７、商品情報７１８、更新ボタン７１９、帳票生成ボタン７２０からなる。ここで表示される情報は前述のレコード情報４００として保存されている。担当者７１５、取引先７１６、住所７１７、商品情報７１８は、ユーザの入力可能なテキストボックスである。更新ボタン７１９が押下されるとテキストボックスで入力された値がデータ管理サービス１０１に通知されレコード情報４００に記録される。帳票生成ボタン７２０が押下されるとデータ管理サービス１０１に帳票生成リクエストが行われ、そのレスポンスとして帳票生成サービス１０２への帳票生成リクエストのリダイレクトが返される。帳票生成リクエストを受け付けた帳票生成サービス１０２は図８にて後述のフォーム選択画面をレスポンスとしてクライアント１０４に送信する。

添付ファイル７２１はデータ管理サービス１０１にアップロードされたファイルの情報を表示する領域である。添付ファイル７２１の領域にはアップロードされた日時やファイル名やアップロード実行者を表示する。ここでファイル名をクリックすることによりアップロードされたファイルをダウンロードすることもできる。
履歴７２２はデータ管理サービス１０１におけるレコードに対して行った操作の履歴を表示する領域である。履歴７２２の領域には履歴情報４２０に保存された日付４２５、件名４２６、内容４２７が表示される。

＜帳票生成サービス１０２画面＞
図８（ａ）は、帳票生成サービス１０２で生成され、クライアントの表示装置２０８にＷｅｂブラウザの画面として表示されるフォーム選択画面の一例である。フォーム選択画面８００は、帳票生成サービス１０２が帳票生成リクエストを受け付けた場合のレスポンスとして返す画面である。フォーム選択８０１のプルダウンでは帳票生成リクエストで渡されたリクエスト情報６００の組織ＩＤ６０３、テーブルＩＤ６０５と一致するフォーム対応情報６１０の表示名６１３を選択することができる。アクション選択８０２ではオーバーレイ実行後の動作を指定するプルダウンである。選択可能な項目として本実施例ではプレビューと添付がある。ここで、アクション選択８０２において選択される「プレビュー」と「添付」について説明する。プレビューとは、帳票生成サービス１０２が、オーバーレイによって生成した帳票データをクライアント１０４に送信し、クライアント１０４の表示装置２０８にて表示させる方法を指す。また、添付とは、帳票生成サービス１０２が、オーバーレイによって生成した帳票データをデータ管理サービス１０１にアップロードする方法を指す。データ取得ボタン８０３が押下されると、フォーム選択８０１とアクション選択８０２で選択された値を持って帳票生成サービス１０２へデータ取得リクエストが行われ、データ取得が成功するとレスポンスとしてデータ確認画面８１０が返される。

図８（ｂ）は、帳票生成サービス１０２で生成され、クライアントの表示装置２０８にＷｅｂブラウザの画面として表示されるデータ確認画面の一例を示す図である。データ確認画面８１０では、テキストボックス８１１において、データ管理サービス１０１から取得したデータを確認、変更することができる。作成ボタン８１２が押下されるとテキストボックス８１１で変更された値または、変更されず確認のみされた値を持って帳票生成サービス１０２にオーバーレイ実行リクエストが行われる。オーバーレイ実行リクエストを受け付けた帳票生成サービス１０２の処理の詳細は後述する。尚、本実施例においては、オーバーレイ実行リクエストに付随するデータを変更データと称する。ここで、変更データは、テキストボックス８１１で変更された値または、変更されず確認のみされた値のいずれのデータも指す。

＜帳票生成サービス１０２リクエスト受信時フロー＞
図９は、帳票生成サービス１０２がリクエストを受信したときの処理フローを示した図である。尚、図９のフローチャートの各処理は、ＨＤＤ５０６に記憶されている各ソフトウェアモジュールをＣＰＵ５０３が実行することにより実現される。

Ｓ９００において、リクエスト処理部５１２は、リクエストの受信が行われたか否かを判断する。Ｓ９００での判断の結果、リクエストの受信が行われたと判断された場合は、Ｓ９０１に移行し、リクエストの受信が行われていないと判断された場合は、Ｓ９００に戻りリクエストの受信を待つ。

Ｓ９０１において、リクエスト処理部５１２は、受信したリクエストのＵＲＬを確認し、リクエストが、帳票生成リクエスト，データ取得リクエスト、オーバーレイ実行リクエストのいずれであるかを判断する。それぞれのリクエストには異なるＵＲＬが定義されておりリクエスト処理部５１２が受信したＵＲＬによりリクエストの種類を判断できる。Ｓ９０１での判断の結果、受信したリクエストが帳票生成リクエストであると判断された場合は、フォーム選択処理Ｓ９０２に移行する。一方、受信したリクエストがデータ取得リクエストであると判断された場合は、データ取得処理Ｓ９０３に移行する。また、受信したリクエストがオーバーレイ実行リクエストであると判断された場合は、データ変更処理Ｓ９０４に移行する。

Ｓ９０２において、リクエスト処理部５１２は、生成されたフォーム選択画面８００をレスポンスとしてクライアント１０４に返す。フォーム選択画面８００の生成については前述の通りである。Ｓ９０３においては、データ取得処理が行われる。データ取得処理の処理フローについては詳細を後述する。Ｓ９０４においては、データ変更処理が、Ｓ９０５においては、帳票生成処理が行われる。データ変更処理及び帳票生成処理の詳細については後述する。尚、図示を省略しているがデータ変更処理Ｓ９０４においてエラーが発生した場合には帳票生成処理９０５は実行されず処理は終了となる。

＜帳票生成サービス１０２データ取得リクエスト受信時フロー＞
図１０は、帳票生成サービス１０２が帳票生成リクエストを受信したときのデータ取得処理（Ｓ９０３）の詳細を示すフローチャートである。尚、図１０のフローチャートの各処理は、ＨＤＤ５０６に記憶されている各ソフトウェアモジュールをＣＰＵ５０３が実行することにより実現される。

Ｓ１００１において、リクエスト処理部５１２は、セッションが有効かどうか確認する。リクエスト処理部５１２は、セッション管理を行っており、クライアント１０４を識別する情報やクライアント１０４からリクエストされた情報をセッション情報として保持している。Ｓ１００１においてリクエスト処理部５１２によりセッション情報の正当性が確認され、その結果セッション情報が無効であると判断された場合にはＳ１０１２に移行する。一方、Ｓ１００１においてセッションが有効であると判断された場合、Ｓ１００２に移行する。

Ｓ１００２においてロジック部５１４は、帳票生成リクエストで渡されるリクエスト情報６００をセッションから取得する。リクエスト情報６００は帳票生成リクエスト受信時にセッション情報として保持されているものとする。Ｓ１００３において、ロジック部５１４は、フォーム選択画面８００におけるフォーム選択８０１、アクション選択８０２で選択された表示名６１３とアクション方式をリクエストから取得する。ここで受付処理を行ったアクション方式により、生成された帳票データがどのように送信されるかが判断されることとなる。

Ｓ１００４において、ロジック部５１４は、データ取得クエリファイル６２０を取得する。より具体的には、ロジック部５１４は、Ｓ１００３で取得した表示名６１３に紐付くデータ取得クエリファイルパス６１５をフォーム管理部５１６に管理されているフォーム対応情報６１０から特定し、データ取得クエリファイル６２０を取得する。Ｓ１００５において、ロジック部５１４は、リクエスト情報６００に含まれるテーブルＩＤ６０５、レコードＩＤ６０６をＳ１００４にて取得したデータ取得クエリファイル６２０に挿入しクエリ文を生成する。

Ｓ１００６において、ロジック部５１４は、リクエスト情報６００に含まれるＵＲＬ６０１（データ管理サービス１０１のＵＲＬ）へ、データ管理サービス１０１で発行されリクエスト情報に含まれるセッションＩＤ６０２で接続する。データ管理サービス１０１への接続が確立した後、Ｓ１００７において、ロジック部５１４は、Ｓ１００５で生成されたデータ取得クエリファイル６２０を実行しデータ管理サービス１０１からデータを取得する。

Ｓ１００８において、ロジック部５１４は、データ管理サービス１０１からのデータ取得に成功したか否かを判断する。Ｓ１００８において、データ取得に成功したと判断された場合は、Ｓ１００９に移行し、失敗したと判断された場合には、Ｓ１０１２に移行する。Ｓ１００９において、ロジック部５１４はデータ取得クエリファイル６２０におけるＳＥＬＥＣＴ文の取得キーと取得したデータ、表示名やアクション方式を同一のセッションＩＤのセッション情報として保存する。

Ｓ１０１０において、ロジック部５１４は、画面生成部５１３より取得データ確認画面情報を取得し、取得したデータを用いてデータ確認画面８１０を生成する。Ｓ１０１１において、リクエスト処理部５１２は、クライアント１０４に対してレスポンスとしてロジック部５１４により生成されたデータ確認画面８１０を返す。

Ｓ１０１２において、ロジック部５１４は画面生成部５１３よりエラー画面情報を取得しセッションエラーのメッセージとともにエラー画面生成する。そして、リクエスト処理部５１２が、生成されたエラー画面をレスポンスとしてクライアント１０４に対して返す。

＜帳票生成サービス１０２オーバーレイ実行リクエスト受信時フロー＞
図１１は帳票生成サービス１０２がオーバーレイ実行リクエストを受信したときの処理の詳細を示すフローチャートである。尚、図１１のフローチャートの各処理は、ＨＤＤ５０６に記憶されている各ソフトウェアモジュールをＣＰＵ５０３が実行することにより実現される。また、図１１のフローチャートでは、特にＳ９０４の処理の詳細について説明し、Ｓ９０５の処理については図１２を用いて後述する。

Ｓ１１０１において、リクエスト処理部５１２は、セッションが有効かどうか確認する。セッションが有効であると判断された場合は、Ｓ１１０１に移行し、セッションが有効でないと判断された場合は、Ｓ１１０８に移行する。Ｓ１１０２において、ロジック部５１４は、データ確認画面８１０のテキストボックス８１１に入力された変更データと、変更データに紐付くデータ取得クエリファイル６２０におけるＳＥＬＥＣＴ文の取得キーとをオーバーレイ実行リクエストから取得する。

Ｓ１１０３において、ロジック部５１４は、Ｓ１００９においてセッションに保存された取得キー及び、取得データを取得する。Ｓ１１０４において、ロジック部５１４は、変更データの値が取得データの値から変更されたかどうか判断する。変更データが変更されていると判断された場合は、Ｓ１１０５に移行し、変更データが変更されていないと判断された場合は、Ｓ９０５に移行する。尚、Ｓ１１０４におけるデータ変更されたかどうかの判断は、ロジック部５１４がＳ１１０３で取得された取得データとＳ１１０２で取得された変更データとを比較することにより行われる。変更データが変更されていない場合は、同一の取得キーの取得データの値と変更データの値とが同一の内容となる。

Ｓ１１０５においてロジック部５１４は、データ変更フラグをＯＮにする。Ｓ１１０６において、ロジック部５１４は、変更されている取得キーに対応する取得データの値を変更データの値に書き換える。

図１２は、帳票生成サービス１０２がオーバーレイ実行リクエストを受信したときの帳票生成処理（Ｓ９０５）の詳細である。尚、図１２のフローチャートの各処理は、ＨＤＤ５０６に記憶されている各ソフトウェアモジュールをＣＰＵ５０３が実行することにより実現される。

Ｓ１２０１において、オーバーレイ実行部５１５は、ロジック部５１４によるオーバーレイの指示を受けて、オーバーレイに必要な情報を取得する。ここで、オーバーレイに必要な情報とは、取得データ、データ変更フラグ、取得キーのうち、変更のあったキーと変更後の値、表示名、アクション方式である。Ｓ１２０２において、オーバーレイ実行部５１５は、オーバーレイに必要な情報を用いてオーバーレイを実行する。前述したがオーバーレイは、フォーム管理部５１６が保持するフォームとデータ取得クエリファイル６２０により取得されたデータを用いて、オーバーレイ実行部５１５が実行する。オーバーレイ実行方法の詳細については本発明と関連しないため省略するが、ここではオーバーレイ実行の結果、ＰＤＦ（ＰｏｒｔａｂｌｅＤｏｃｕｍｅｎｔＦｏｒｍａｔ）が生成されるものとする。

Ｓ１２０３において、ロジック部５１４は、オーバーレイ実行部５１５によるオーバーレイが成功しＰＤＦが生成されたか否かを判定する。オーバーレイが成功したと判定された場合は、Ｓ１２０４に移行し、オーバーレイが失敗したと判定された場合は、Ｓ１２２０に移行する。Ｓ１２０４において、ロジック部５１４は、データ変更フラグを確認し、データ管理サービスで管理されているデータに対して、生成された帳票のデータが変更されているか否かを判断する。生成された帳票のデータが変更されている（データ変更フラＯＮ）の場合には、Ｓ１２０９に移行し、変更されていない場合（データ変更フラグＯＦＦ）の場合には、Ｓ１２０５に移行する。

Ｓ１２０５において、ロジック部５１４は、フォーム選択画面８００にて選択されたアクション方式が「添付」であるか「プレビュー」であるかを判断する。アクション方式が「添付」と判断された場合は、Ｓ１２０６に移行し、アクション方式が「プレビュー」と判断された場合は、Ｓ１２０８に移行する。Ｓ１２０６において、リクエスト処理部５１２は、ロジック部５１４からの依頼を受けて、オーバーレイ実行部５１５により生成された帳票データであるＰＤＦをデータ管理サービス１０１に送信し、アップロードする。尚、アップロードされた帳票データはデータ管理サービス１０１に保存され、商談画面７１０の添付ファイル７２１の領域に表示される。Ｓ１２０７において、リクエスト処理部５１２は、Ｓ１２０６におけるアップロードが完了した後、ロジック部５１４の依頼を受けて、帳票データを添付したことをデータ管理サービス１０１に履歴として通知する。ここで通知された履歴は履歴情報４２０として保存され商談画面７１０の履歴７２２の領域に表示される。

Ｓ１２０８において、リクエスト処理部５１２は、ロジック部５１４からの依頼を受けて、オーバーレイ実行部５１５により生成された帳票データであるＰＤＦをクライアント１０４に対して送信する。Ｓ１２０９において、リクエスト処理部５１２は、ロジック部５１４の依頼を受けて、データ管理サービス１０１に対して生成した帳票データをプレビューしたこと（クライアント１０４に送信したこと）を履歴として通知する。ここで、通知を受けたデータ管理サービス１０１は履歴情報４２０として保存し、商談画面７１０の履歴７２２の領域に表示する。Ｓ１２０８においてＰＤＦを受け取ったクライアント１０４上ではＰＤＦリーダが起動され、表示装置２０８の画面上にＰＤＦが表示される。

Ｓ１２１０においては、Ｓ１２０５と同様アクション方式の判断が行われる。アクション方式が「添付」と判断された場合は、Ｓ１２１１に移行し、アクション方式が「プレビュー」と判断された場合は、Ｓ１２１５に移行する。

Ｓ１２１１においては、Ｓ１２０６と同様の処理が行われる。Ｓ１２１２において、ロジック部５１４は、Ｓ１２０１において取得され、オーバーレイ実行時に使用された取得キーと変更データをデータ管理サービス１０１に履歴通知のクエリに追加する。この処理により、オーバーレイ実行直前に変更された情報をデータ管理サービス１０１に通知することが可能となる。

Ｓ１２１３において、ロジック部５１４は、Ｓ１２０１において取得され、オーバーレイ実行時に使用された表示名、アクション方式をデータ管理サービス１０１に履歴通知のクエリに追加する。この処理により、オーバーレイ実行に使用した表示名、オーバーレイ実行後のアクションをデータ管理サービス１０１に通知することが可能となる。

Ｓ１２１４において、リクエスト処理部５１２は、ロジック部５１４からの依頼を受けて、Ｓ１２１２、Ｓ１２１３において生成されたクエリを実行し、データ管理サービス１０１に履歴通知を行う。ここで、通知を受けたデータ管理サービス１０１は履歴情報４２０として保存し、商談画面７１０の履歴７２２の領域に表示する。ユーザはＳ１２１１、Ｓ１２１２において追加したオーバーレイ実行直前の変更情報と、オーバーレイ実行に使用した表示名、オーバーレイ実行後のアクションを履歴７２２において確認することが可能となる。

Ｓ１２１５においては、Ｓ１２０８と同様の処理が行われる。Ｓ１２１６においては、Ｓ１２１２と同様の処理が行われる。Ｓ１２１７においては、Ｓ１２１３と同様の処理が行われる。Ｓ１２１８においては、Ｓ１２１４と同様の処理が行われる。Ｓ１２１５からＳ１２１８の処理により、帳票データであるＰＤＦがクライアントに送信されるとともに、帳票データを作成するためのオーバーレイ実行直前の変更情報をデータ管理サービス１０１に通知することができる。

Ｓ１２１９においては、Ｓ１２０６と同様の処理がバックグラウンドで行われる。この処理は、プレビューであっても生成された帳票に使用されたデータがデータ管理サービス１０１から取得したものと異なる場合にオーバーレイ実行結果をデータ管理サービス１０１に保存するための処理である。この処理によりデータ管理サービス１０１とクライアント１０４との両方に帳票データが送信され、ユーザはプレビューされたＰＤＦと閉じた後でも、商談画面７１０の履歴７２２の領域においてＰＤＦを確認することが可能となる。

Ｓ１２２０において、リクエスト処理部５１２は、ロジック部５１４からの依頼を受けて、処理が終了したことを示す完了画面をクライアント１０４に返す。完了画面の詳細は省略するが、完了画面情報を画面生成部５１３から取得し完了した処理の内容を示すメッセージを加えた画面をレスポンスとしてクライアント１０４に返す。

Ｓ１２２１において、リクエスト処理部５１２は、ロジック部５１４からの依頼を受けて、エラー画面をクライアント１０４に返す。エラー画面は画面生成部５１３から画面情報を取得しエラー詳細メッセージを加えることロジック部５１４が生成する。

以上の処理により、データ管理サービス１０１が管理するデータを帳票生成サービス１０２が持つフォームにオーバーレイする際に、ユーザが帳票生成サービスにおいてデータの変更を行ったとしても、その変更をデータ管理サービスで確認可能となる。

（他の実施形態）
上述した実施例においては、データ管理サービス１０１及び帳票生成サービス１０２のハードウェア構成として、図３、図５を示し、情報処理装置として説明した。しかしながらこの構成に限ることはなく、例えは、ＣＰＵ、ＲＡＭ、ＨＤＤなどのコンピュータハードウェア資源を仮想化し、ソフトウェアを動作させるためのプラットフォームを公開するクラウドプラットフォーム上でソフトウェアを動作させてもよい。クラウドプラットフォーム上のソフトウェアはクラウドプラットフォームで保持するＲＡＭに展開されＣＰＵで実行される。しかし大量のコンピュータ資源はクラウドプラットフォームにより仮想化されているためソフトウェアはクラウドプラットフォームのバックグラウンドで動作するコンピュータ資源を意識する必要はない。代表的なクラウドプラットフォームの形態には、ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）やＷｅｂアプリケーションを登録できるものがある。本実施例ではクラウドプラットフォームの形態は問わない。尚、クラウドプラットフォーム上のソフトウェアはＮｅｔＷｏｒｋＩ／Ｆを介してＬＡＮ及びインターネットに接続することができる。

以上、本発明の実施形態について具体例を挙げて説明したが、本発明は上記の実施形態に限定されるものではない。また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

１０１データ管理サービス
１０２帳票生成サービス
１０４クライアント
５１２リクエスト処理部
５１４ロジック部
５１５オーバーレイ実行部
５１６フォーム管理部

Claims

フォームに対してオーバーレイするためのデータを管理するデータ管理サービスと通信可能な帳票生成装置であって、
前記フォームを管理する管理手段と、
前記データ管理サービスから前記データを取得する取得手段と、
前記取得手段により取得されたデータまたは、前記取得手段により取得されたデータを元に変更されたデータを、前記フォームに対してオーバーレイするオーバーレイ手段と、
前記フォームに対してオーバーレイされたデータが、前記取得手段により取得されたデータを元に変更されたデータである場合に、前記データ管理サービスに対して前記変更の内容を通知する通知手段と、
を有することを特徴とする帳票生成装置。
前記帳票生成装置は前記データ管理サービスに加えて、表示手段を有する情報処理装置と通信可能であり、
前記帳票データを、前記表示手段にて表示されるよう、前記情報処理装置に送信する第１の送信手段と、
前記帳票データを、前記データ管理サービスにて管理されるよう、前記データ管理サービスに送信する第２の送信手段と、
前記第１の送信手段と、前記第２の送信手段とのいずれの送信手段による送信を行うかを示す指示を受け付ける受付手段と、
前記受付手段の受け付けた指示に従って、前記第１の送信手段と、前記第２の送信手段とのいずれの送信手段による送信を行うかを判断する判断手段とを有することを特徴とする請求項１に記載の帳票生成装置。
前記判断手段は、前記受付手段により前記第１の送信手段にて前記帳票データを送信することを示す指示を受け付け、かつ、前記フォームに対してオーバーレイされたデータが前記取得手段により取得されたデータを元に変更されたデータである場合に、前記第１の送信手段と前記第２の送信手段との両方による送信を行うと判断することを特徴とする請求項２に記載の帳票生成装置。
前記第２の送信手段は、前記第１の送信手段と前記第２の送信手段との両方による送信を行う場合に、前記帳票データをバックグラウンドで送信することを特徴とする請求項３に記載の帳票生成装置。
フォームに対してオーバーレイするためのデータを管理するデータ管理サービスと通信可能な帳票生成装置の制御方法であって、
前記フォームを管理する管理工程と、
前記データ管理サービスから前記データを取得する取得工程と、
前記取得工程において取得されたデータまたは、前記取得工程において取得されたデータを元に変更されたデータを、前記フォームに対してオーバーレイするオーバーレイ工程と、
前記フォームに対してオーバーレイされたデータが、前記取得工程において取得されたデータを元に変更されたデータである場合に、前記データ管理サービスに対して前記変更の内容を通知する通知工程と、
を有することを特徴とする帳票生成装置の制御方法。
前記帳票生成装置は前記データ管理サービスに加えて、表示手段を有する情報処理装置と通信可能であり、
前記帳票データを、前記表示手段にて表示されるよう、前記情報処理装置に送信する第１の送信工程と、
前記帳票データを、前記データ管理サービスにて管理されるよう、前記データ管理サービスに送信する第２の送信工程と、
前記第１の送信工程と、前記第２の送信工程とのいずれの送信工程による送信を行うかを示す指示を受け付ける受付工程と、
前記受付工程で受け付けた指示に従って、前記第１の送信工程と、前記第２の送信工程とのいずれの送信工程による送信を行うかを判断する判断工程とを有することを特徴とする請求項５に記載の帳票生成装置の制御方法。
前記判断工程では、前記受付工程において前記第１の送信工程にて前記帳票データを送信することを示す指示を受け付け、かつ、前記フォームに対してオーバーレイされたデータが前記取得工程において取得されたデータを元に変更されたデータである場合に、前記第１の送信工程と前記第２の送信工程との両方による送信を行うと判断することを特徴とする請求項６に記載の帳票生成装置の制御方法。
前記第２の送信工程では、前記第１の送信工程と前記第２の送信工程との両方による送信を行う場合に、前記帳票データをバックグラウンドで送信することを特徴とする請求項７に記載の帳票生成装置の制御方法。
請求項５乃至８のいずれか１項に記載の帳票生成装置の制御方法の各工程をコンピュータに実行させるためのプログラム。