JP2015082183A - 文書生成システム - Google Patents

Abstract

【課題】複数のサービスが連携して動作するワークフローでは、各サービスでの処理が全て成功し、ユーザが出力結果を得られた時に課金する。【解決手段】クライアント端末、クラウドプラットフォームサービスおよび文書生成サーバ１０３、プリンタサーバ１０４がネットワークで接続された文書生成システムであって、文書生成サーバ１０３は、クラウドプラットフォームサービスからの文書生成リクエストを受信（Ｓ１３０１）し、検証を前記テナントＩＤおよび認証キーにて行い（Ｓ１３０２）、前記取得したアクセストークンを用いてクラウドプラットフォームサービスからデータの取得を行い（Ｓ１３０３）、前記取得したデータから文書生成を行う（Ｓ１３０４）。文書生成リクエストを受信したのはアクセス制御部かリクエスト処理部か判定し（Ｓ１３０５）、前記判定結果がアクセス制御部の場合、操作名に接頭辞を付けて課金ログを出力する（Ｓ１３０７）。【選択図】図１３

Description

本発明は、クラウド上に保存されたデータをフォームオーバーレイして文書を作成および印刷するシステムに関し、特にユーザが介在しない自動ワークフロー処理における課金方法に関する。

近年、サーバーコンピュータ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステムが普及し始めている。

ユーザは、クライアントコンピュータのブラウザからインターネットを介してクラウドプラットフォームサービスのＷｅｂページにアクセスし、自動ワークフロー（夜間バッチ印刷など）を指定日時に実行するためのスケジュール登録を行う。クラウドプラットフォームの代表例として、例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社のＳａｌｅｓｆｏｒｃｅ ＣＲＭ（登録商標）がある。

複数サービスの連携によって成立つ自動ワークフローシステム（自動夜間バッチ印刷など）を実現する場合、クラウドサーバコンピュータはスケジュールに従って文書生成サーバへ文書生成指示を行う。そして文書生成サーバはクラウドプラットフォームサービス上にあるデータを取得して文書を生成する。

クラウドプラットフォームと文書生成サーバが連携を行う場合、ユーザがそれぞれのサーバで認証を行うことなくサーバ間で認証を連携させることが可能である。従来複数のサーバ間で認証を連携させる技術として、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるシングルサインオン（以下ＳＳＯ）の仕組みがある。ＳＡＭＬのＳＳＯにおいて、ユーザは、認証サービスを提供する側（以下ＩｄＰ）、および認証サービスの認証結果を信頼してサービスを提供する側（以下ＳＰ）の両方のユーザＩＤを保有している。ユーザがＩｄＰで認証を受けると、ＳＰはその認証結果を信頼して、そのアクセスをＳＰ内で管理するＩＤとして認証する（ＩｄＰ先行）。また、ＩｄＰで認証を受けていない未認証のユーザがＳＰにアクセスしてきた場合、ＳＰは、未認証のユーザを適切なＩｄＰへと誘導し、ＩｄＰで認証させる（ＳＰ先行）。

ＳＡＭＬによるＳＳＯを行う場合、ＩｄＰが保有するＩＤとＳＰが保有するＩＤを対応付け（以下、ユーザマッピングと称する）を行って管理する。特に、ユーザを識別することが不可欠なサービスと文書生成サーバを連携させる場合、ユーザマッピングによるＩＤ管理が必要となる。ユーザを識別することが不可欠なサービスには、文書をＩＤ毎に管理・印刷を行うプリントサーバがある。

このようなサービスにおける課金は、処理ごとに出力される課金ログを集計することによって行われる。文書生成サーバにおける課金ログは文書生成成功時に出力される。一方、文書生成サーバで実行可能な操作には複数サービスの連携によって動作するものがある。

従来、ユーザがサービスを利用する際の状況とユーザ情報に基づいて課金額を算出するものがある(特許文献１参照）。

特開２０１３−２０２９８号公報

複数のサービスが連携して動作するワークフローでは、各サービスでの処理が全て成功し、ユーザが出力結果を得られた時に集計する。

しかしながら課金ログは各サービスにおいて処理ごとに出力される為、一部のサービスで処理に失敗した場合、文書生成サーバでの処理に成功していれば課金ログが出力されユーザは出力結果を得られないにもかかわらず課金される。

クライアント端末１０１、クラウドプラットフォームサービス１０２および文書生成サーバ１０３、プリントサーバ１０４がネットワークで接続された文書生成システムであって、クラウドプラットフォームサービス１０２は以下を含む。スケジュールジョブを登録するスケジュール管理部３０３。

文書生成サーバ１０３からの要求に対してアクセストークンを発行するアクセス制御部３０１。

文書生成サーバ１０３へのアクセス検証に使用される認証キーをテナントＩＤに紐付けて保存するステップ（Ｓ１１１１）。

文書生成サーバ１０３へ文書生成リクエストを行うステップ（Ｓ１３０１）。

文書生成サーバ１０３からの要求に応じて業務データを送信するデータ管理部３０４。
さらに文書生成サーバ１０３は以下を備える。

クラウドプラットフォームサービスの１０２からのアクセスの検証を行うための認証キーを発行するステップ（Ｓ１１０３）。

前記認証キーをテナントＩＤとともに管理する設定管理部４０３。

前記設定管理部４０３はさらに、クラウドプラットフォームサービス１０２から取得したアクセストークンをテナントＩＤに紐付けて保存する（Ｓ１２１０）。

クラウドプラットフォームサービス１０２からの文書生成リクエストの検証を前記テナントＩＤおよび認証キーにて行うステップ（Ｓ１３０２）。

クラウドプラットフォームサービス１０２からデータの取得を行うステップ（Ｓ１３０３）。

前記取得したデータから文書の生成を行う文書生成部４０５。

文書生成リクエストを受信したのがアクセス制御部４０１か判定する（Ｓ１３０５）。

課金ログを出力する課金ログ出力部４０６。

前記課金ログ出力部４０６はさらに、前記操作が他サービスと連携する操作の時、接頭辞付き課金ログを出力する（Ｓ１３０７）。

文書と共に印刷リクエストを送信するステップ（Ｓ１３０８）を有するシステム。

複数のサービスが連携してスケジュールジョブを実行するシステムにおいて、文書生成サーバ単体で行った処理と課金ログの内容を切り替えることが可能。これにより複数サービスが連携する場合に、途中のサービスで処理が失敗した場合でもシステム全体での処理失敗と判断可能になる。

システム構成を示すブロック図 ハードウェア構成を示す図 クラウドプラットフォームサービスのソフトウェアモジュール構成図 文書生成サーバのソフトウェアモジュール構成図 文書生成サーバの認証情報確認画面例 クラウドプラットフォームサービスの認証情報登録画面例 クラウドプラットフォームサービスのスケジュール設定画面例 プリントサーバのソフトウェアモジュール構成図 クラウドプラットフォームサービスの保持する情報のテーブル構造 文書生成サーバの保持する情報のテーブル構造 クラウドプラットフォームサービスへの認証情報登録処理シーケンス 文書生成サーバへのアクセストークン登録処理シーケンス 実施例１における文書生成システムの文書生成処理を示すフローチャート 実施例２における文書生成システムの文書生成処理を示すフローチャート

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

図１は、本発明の実施例のシステム構成を示すブロック図である。

図中、１０１は、後述するクラウドプラットフォームサービス１０２および後述する文書生成サーバ１０３に対してリクエストを発行するクライアント装置１０１である。図中、１０２はクラウドプラットフォームサービス１０２であり、クライアント装置１０１や文書生成サーバ１０３からのリクエストに応じて、保持するデータの表示・更新等を行う。図中、１０３は、文書生成サーバ１０３であり、クライアント装置１０１からリクエストを受信して文書生成を行う。図中、１０４はプリントサーバ１０４であり、文書生成サーバ１０３からのリクエストにより、印刷を行う。

また、上記各構成要素はネットワーク１００により通信可能に接続されている。ネットワークは、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれである。また、これらの組み合わせにより実現される、いわゆる通信ネットワークである。

ネットワークはデータの送受信が可能であればよい。

クライアント装置１０１とクラウドプラットフォームサービス１０２および文書生成サーバ１０３との通信手段、文書生成サーバ１０３とクラウドプラットフォームサービス１０２やプリントサーバ１０４との通信手段、及び各サーバ間の通信手段が異なっていてもよい。

クラウドプラットフォームサービス１０２は、クラウドプラットフォームサービスを使用するユーザの管理や、業務データ、後述する文書生成サーバ１０３へのリダイレクトを行うための設定を管理する。

また、クラウドプラットフォームサービス１０２は、複数の企業・組織から使用されることが前提であり（一般的にマルチテナントと呼ばれる）、使用する企業・組織毎に前述のユーザ管理、業務データ管理等が行われる。

文書生成サーバ１０３は、いわゆるＷｅｂアプリケーションの機能を有するよう構成されており、クライアント端末１０１は介してアクセスする事ができ、クライアント端末１０１からのリクエストに対してユーザインタフェース情報を返答する。

また、文書生成サーバ１０３は文書生成要求を受信すると、クラウドプラットフォームサービス１０２から業務データを取得し、受信したデータと自身で管理するフォームを使用してオーバーレイ処理を行い、文書データを生成する。

また、文書生成サーバ１０３は生成した文書データを、クライアント端末１０１からのリクエストに応じて、文書データをプリントサーバ１０４に対して印刷実行する。

またプリントサーバ１０４は文書生成サーバ１０３からクライアント端末１０１経由で印刷実行のリクエストを受け取ると、文書生成サーバ１０３に印刷実行のリクエストを発行することで文書データの印刷を行う。

図２は、図１のクライアント装置１０１、クラウドプラットフォームサービス１０２、文書生成サーバ１０３のハードウェア構成を示すブロック図である。図中、２０１は内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するＣＰＵである。２０２はＢＩＯＳが格納してあるＲＯＭである。２０３はＣＰＵ２０１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりするＲＡＭ（直接記憶装置）である。２０４は基本ソフトウェアであるＯＳやソフトウェアモジュールが記憶されているＨＤＤ（ハードディスクドライブ）、もしくはＳＳＤ（ソリッドステートドライブ）などの間接記憶装置である。２０５は入力装置であり不図示のキーボードやポインティングデバイスなどである。２０６は出力装置でありディスプレイが接続される。２０７はネットワーク１００に接続するためのＩ／Ｆである。

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

図３は、クラウドプラットフォームサービス１０２上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

クラウドプラットフォームサービス１０２は以下で構成される。

文書生成サーバ１０３からのアクセストークン取得リクエストに応じてアクセストークンの生成および送信を行い、また、クライアント端末１０１または文書生成サーバ１０３からの要求に応じてユーザ認証を行うアクセス制御部３０１。

クライアント端末１０１や文書生成サーバ１０３にレスポンスを返すためのＷｅｂページを生成するページ生成部３０２。

指定時刻に文書生成サーバ１０３に文書生成要求を送信するためのスケジュール設定および印刷パラメータをデータベースに保持し、さらにスケジュール設定の内容に従って指定時刻に文書生成要求を送信するスケジュール管理部３０３。

業務データをデータベースに保持し、要求に応じて業務データの取得、あるいは業務データの更新を行うデータ管理部３０４。

クラウドプラットフォームサービス１０２はこれら各構成要素の協調により、後述する処理を実行する。

また、上述のデータベースは管理ユーザデータや業務データ、テナントＩＤ、認証キーをスケジュール設定および印刷パラメータ設定格納するストレージであり、図２で示したＨＤＤ２０４に記憶されている。

前述のデータベースに格納されるデータは企業・組織（以降、組織と表記）毎に管理される。各組織には組織ＩＤが自動的に割り当てられ、組織ＩＤとともに各データが管理される。以降のデータ取得等の処理は組織ＩＤをもとに行われ、組織ＩＤの一致するデータのみを参照することが可能となっている。

図４は、文書生成サーバ１０３上で動作するソフトウェアモジュールの構成図である。

なお各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

文書生成サーバ１０３は以下で構成される。

クライアント装置１０１からのログイン要求およびクラウドプラットフォームサービス１０２からの文書生成要求のユーザ認証を行うアクセス制御部４０１。

クライアント装置１０１からの文書生成要求を受信するリクエスト処理部４０７。

クライアント端末１０１やクラウドプラットフォームサービス１０２にレスポンスを返すためのＷｅｂページを生成するページ生成部４０２。

後述のアクセストークンおよびテナントＩＤを管理する設定管理部４０３。

クラウドプラットフォームサービス１０２にアクセスして業務データを取得するデータアクセス部４０４。

データアクセス部４０４で取得した業務データとフォームを使用してオーバーレイ処理を行い、文書データを生成する文書生成部４０５。

文書生成要求による実行履歴を集計する為のログを出力する課金ログ出力部４０６。

文書生成サーバ１０３はこれら各構成要素の協調により、後述する処理を実行する。

図８は、プリントサーバ１０４上で動作するソフトウェアモジュールの構成図である。
なお各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

プリントサーバ１０４は以下で構成される。

クライアント装置１０１からのログイン要求および文書生成サーバ１０３からの印刷要求のユーザ認証を行うアクセス制御部８０１。

クライアント端末１０１や文書生成サーバ１０３にレスポンスを返すためのＷｅｂページを生成するページ生成部８０２。

ユーザ・組織ごとの設定を管理する設定管理部８０３。

組織ごとのプリンタ情報の管理と印刷指示を行うプリンタ管理部８０４。

印刷要求による実行履歴を集計する為のログを出力する課金ログ出力部８０６。

図５は、クライアント端末１０１から、文書生成サーバ１０３にアクセスして表示した、認証情報確認画面５００の例である。なお、図５は、ユーザが文書生成サーバ１０３にログイン済の状態である。

認証情報確認画面５００は、クラウドプラットフォームサービス１０２からアクセストークンを取得し、登録するための登録ボタン５０１、文書生成要求の認証に必要なテナントＩＤ５０２、認証キー５０３が表示されている。

登録ボタン５０１押下時の処理は後述する。

図６は、クライアント端末１０１から、クラウドプラットフォームサービス１０２にアクセスして表示した、認証情報登録画面６００の例である。なお、図６は、ユーザがクラウドプラットフォームサービス１０２にログイン済の状態である。

認証情報登録画面６００は、前述の認証情報確認画面５００から取得したテナントＩＤ、認証キーを入力するテナントＩＤ６０１、認証キー６０２および、入力した値を設定管理部３０６に保存するリクエストを発行するＯＫボタン６０３が表示されている。

テナントＩＤおよび認証キーをクラウドプラットフォームサービス１０２に登録する処理は後述する。

図７は、クライアント端末１０１から、クラウドプラットフォームサービス１０２にアクセスして表示した、スケジュール設定画面７００の例である。なお、図７は、ユーザがクラウドプラットフォームサービス１０２にログイン済の状態である。

スケジュール設定画面７００は、スケジュール名であるジョブ情報設定領域７０１、ジョブの開始日時を設定する開始時刻設定領域７０２、ジョブ実行時の印刷パラメータを設定する印刷パラメータ設定領域７０３、登録ボタン７０４から成る。ユーザは、スケジュール設定画面７００を操作し、文書生成要求を実行したい時刻および印刷パラメータ等を入力して登録ボタン７０４を押す。登録ボタン７０４が押下されると、クラウドプラットフォームサービス１０２のスケジュール管理部３０３は、指示された設定を後述のスケジュール情報９１０に保存する。

図９は、クラウドプラットフォームサービス１０２が保持する情報のテーブル構造を示す図である。

認証情報９００は、文書生成サーバ１０３への文書生成要求時に使用する認証情報であって、文書生成サーバ１０３のテナントを識別するテナントＩＤ９０１および、認証キー９０２からなる。

また、スケジュール情報９１０はスケジュール管理部３０３が文書生成要求実行に使用する情報であって、以下からなる。

前述の実行履歴情報でジョブを区別するためのバッチジョブ名９１１。

文書生成要求を実行する日時であるジョブ開始日時９１２。

どのような文書を生成するかどうかを指定するための印刷パラメータ９１３からなる。

図１０は、文書生成サーバ１０３が保持する認証情報１０００のテーブル構造を示す図である。

認証情報１０００は、クラウドプラットフォームサービス１０２からの文書生成リクエストの認証および、文書生成サーバ１０３からクラウドプラットフォームサービス１０２への実行履歴書き込みの認証に使用され、以下からなる。

文書生成サーバ１０３のテナントを識別するテナントＩＤ１００１、および認証キー１００２。

クラウドプラットフォームサービス１０２にアクセスする際に認証情報として使用するアクセストークン１００３およびリフレッシュトークン１００４。

図１１は、本発明の実施例における、文書生成システムが行う文書生成サーバ１０３にアクセスするための認証情報をクラウドプラットフォームサービス１０２に登録する処理の流れを示している。

はじめ、Ｓ１１０１、Ｓ１１０２においてユーザは付図示のログイン画面にて文書生成サーバ１０３へのログインを行う。

Ｓ１１０３において、文書生成サーバ１０３のアクセス制御部４０１はユーザのテナントに紐付く認証キーが存在するかどうかを設定管理部４０３経由で認証情報１０００を確認し、存在しなければ認証キーを生成、設定管理部４０３に保存する。

次にＳ１１０４で、ページ生成部４０２は設定管理部４０３からテナントＩＤと認証キーを取得し、認証情報確認画面５００を作成しクライアント端末１０１に返す。

Ｓ１１０５においてクライアント端末１０１は認証情報確認画面５００を表示し、ユーザにテナントＩＤおよび認証キーを確認させる。

次にＳ１１０６、Ｓ１１０７においてユーザは付図示のログイン画面にてクラウドプラットフォームサービス１０２へのログインを行う。

Ｓ１１０８にて、クラウドプラットフォームサービス１０２のページ生成部３０２は、認証情報登録画面６００を生成し、クライアント端末１０１に返す。

ユーザはＳ１１１０において、認証情報登録画面６００のテナントＩＤ６０１、認証キー６０２に、認証情報確認画面５００に表示されているテナントＩＤと認証キーを入力し、ＯＫボタン６０３を押下することで、認証情報登録リクエストを送信する。

Ｓ１１１１でデータ管理部３０４は、受け取ったテナントＩＤと認証キーをそれぞれ認証情報９００のテナントＩＤ９０１、認証キー９０２としてレコードに保存する。

図１２は、本発明の実施例における、文書生成システムが行う文書生成サーバ１０３がクラウドプラットフォームサービス１０２にアクセスするための認可情報を文書生成サーバ１０３に登録する処理の流れを示している。認可の方法としてＯＡｕｔｈプロトコルが一般的であり図１２の処理もＯＡｕｔｈプロトコルに従う認可処理の一例である。

Ｓ１２０１からＳ１２０２の処理は、前述のＳ１１０１からＳ１１０５の処理と同様のため、省略する。

Ｓ１２０３において、認証情報確認画面５００の登録ボタン５０１を謳歌すると、認可会始リクエストが文書生成サーバ１０３に送信される。リクエストを受信したアクセス制御部４０１は、Ｓ１２０４にて、クライアント端末１０１を経由してクラウドプラットフォームサービス１０２にスコープをパラメータとして認可リクエストを行う。スコープとは認可許可する範囲を示すもので、本実施例ではクラウドプラットフォームサービス１０２のユーザデータ操作を認可の範囲としてスコープ指定している。

Ｓ１２０５からＳ１２０９までの処理は、ＯＡｕｔｈプロトコルの一般的な認可処理フローのため、説明を割愛する。

Ｓ１２０９にて、文書生成サーバ１０３はアクセストークン、リフレッシュトークンを受信すると設定管理部４０３は認証情報１０００として、アクセストークン１００３、リフレッシュトークン１００４をユーザのテナントＩＤに紐付けて保存する。
Ｓ１２１０にて、ページ生成部４０２はアクセストークン、リフレッシュトークン保存完了のメッセージを生成し、クライアント端末１０１に返す。

図１３は、本発明の実施例における文書生成システムが行う、スケジュール情報９１０に設定したスケジュールに従って実行する文書生成処理の流れを示している。

本フローは、文書生成サーバ１０３が文書生成リクエストを受信し、文書生成処理が開始されることによって始まる。

Ｓ１３０１で文書生成サーバ１０３は文書生成リクエストを受信すると、Ｓ１３０２にてアクセス制御部４０１は、認証情報１０００に保持するテナントＩＤ１００１、認証キー１００２を用いて、リクエストに含まれる認証情報９００の検証を行う。

Ｓ１３０２で、アクセス制御部４０１は認証情報１０００から、リクエストに含まれるテナントＩＤがテナントＩＤ１００１と一致するレコードのアクセストークン１００３を取得する。

Ｓ１３０３にて、データアクセス部４０４は業務データの取得要求（クエリ）を行う。クラウドプラットフォームサービス１０２が公開するＷｅｂサービスＡＰＩに対して、パラメータとしてＳ１３０２で取得したアクセストークン１００３を指定することで業務データの取得が可能となる。

Ｓ１３０４で、文書生成サーバ１０３の文書生成部４０５は、不図示のフォーム管理モジュールが管理するフォームを取得して、前記取得した業務データと前記取得したフォームから文書データを生成する。Ｓ１３０４の文書生成処理は公知のため説明を割愛する。

Ｓ１３０５で、文書生成サーバ１０３の課金ログ出力部４０６は、文書生成リクエストを受信したのがアクセス制御部４０１であるか判定する。

リクエスト処理部４０７で受信した文書生成リクエストの場合、Ｓ１３０６で、課金ログ出力部４０６は文書生成処理を行った日時、テナントＩＤ、ユーザＩＤとさらに文書生成リクエストで指定された操作名をログファイルに出力する。

アクセス制御部４０１で受信した文書生成リクエストの場合、Ｓ１３０７で、課金ログ出力部４０６は文書生成処理を行った日時、テナントＩＤ、ユーザＩＤと、さらに他サービスと連携するフロー中の操作であることを示す接頭辞を付与した操作名をログファイルに出力する。接頭辞は通常の操作名と判別できればどのようなものでも構わない。

以上により、文書生成システムが出力する課金ログに、他サービスと連携したフロー中の処理であるか判別可能な情報が付与される。

Ｓ１３０８で、プリントサーバ１０４のプリンタ管理部８０４は受信した印刷リクエストに印刷を実行する。

Ｓ１３０９で、プリントサーバ１０４の操作ログ出力部８０５は印刷処理を行った日時、テナントＩＤ、ユーザＩＤをログファイルに出力する。

請求項１に記載の帳票生成サービスであって、さらに以下を備えることを特徴とする。
文書生成サーバ１０３の課金ログ出力部は文書生成リクエストをどこで受信したか判定する（Ｓ１４０５）。アクセス制御部以外で受信した場合、課金ログを出力する（Ｓ１４０６）。アクセス制御部４０１で受信した場合、課金ログは出力せずプリントサーバ１０４へ印刷リクエストを送信する（Ｓ１４０７）。以上により、文書生成システムは課金対象となる文書生成の場合のみ、課金ログを出力する。

１０１ クライアント装置
１０２ クラウドプラットフォームサービス
１０３ 文書生成サーバ

Claims (2)

1. クライアント端末１０１、クラウドプラットフォームサービス１０２および文書生成サーバ１０３、プリンタサーバ１０４がネットワークで接続された文書生成システムであって、クラウドプラットフォームサービス１０２は以下を含む。
   スケジュールジョブを登録するスケジュール管理部３０３。
   文書生成サーバ１０３からの要求に対してアクセストークンを発行するアクセス制御部３０１。
   文書生成サーバ１０３へのアクセス検証に使用される認証キーをテナントＩＤに紐付けて保存するステップ（Ｓ１１１１）。
   文書生成サーバ１０３からの要求に応じて業務データを送信するデータ管理部３０４。
   さらに文書生成サーバ１０３は以下を備える。
   クラウドプラットフォームサービスの１０２からのアクセスの検証を行うための認証キーを発行するステップ（Ｓ１１０３）。
   前記認証キーをテナントＩＤとともに管理する設定管理部４０３。
   前記設定管理部４０３はさらに、クラウドプラットフォームサービス１０２から取得したアクセストークンをテナントＩＤに紐付けて保存する（Ｓ１２１０）。
   クラウドプラットフォームサービス１０２からの文書生成リクエストの検証を前記テナントＩＤおよび認証キーにて行うステップ（Ｓ１３０２）。
   前記取得したアクセストークンを用いてクラウドプラットフォームサービス１０２からデータの取得を行うステップ（Ｓ１３０３）。
   前記取得したデータから文書生成を行う文書生成部４０５。
   文書生成リクエストを受信したのはアクセス制御部４０１かリクエスト処理部４０７か判定するステップ（Ｓ１３０５）
   前記判定結果がアクセス制御部４０１の場合、操作名に接頭辞を付けて課金ログを出力するステップ（Ｓ１３０８）を有するシステム。
2. 請求項１に記載の帳票生成サービスであって、さらに以下を備えることを特徴とする。
   文書生成サーバ１０３の課金ログ出力部は文書生成リクエストをどこで受信したか判定する（Ｓ１４０５）。アクセス制御部以外で受信した場合、課金ログを出力する（Ｓ１４０６）。アクセス制御部４０１で受信した場合、課金ログは出力せずプリントサーバ１０４へ印刷リクエストを送信する（Ｓ１４０７）。