JP2014186707A

JP2014186707A - 文書生成システム

Info

Publication number: JP2014186707A
Application number: JP2013063124A
Authority: JP
Inventors: Yuichiro Sato; 雄一郎佐藤
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-03-26
Filing date: 2013-03-26
Publication date: 2014-10-02

Abstract

【課題】複数のサービスが連携して動作するワークフロー全体の処理結果をクラウドプラットフォームサービス上で一意に確認できるようにする。
【解決手段】文書生成サーバ１０３は、クラウドプラットフォームサービス１０２からのアクセスの検証を行うための認証キーを発行し、認証キーをテナントＩＤとともに管理し、クラウドプラットフォームサービスから取得したアクセストークンをテナントＩＤに紐付けて保存する。クラウドプラットフォームサービスからの文書生成リクエストの検証をテナントＩＤおよび認証キーにて行い、テナントＩＤに紐付くアクセストークンを取得し、取得したアクセストークンを用いてクラウドプラットフォームサービスからデータの取得を行う。取得したアクセストークンおよび前記クラウドプラットフォームサービスから受信したジョブＩＤを用いてクラウドプラットフォームサービスへ文書送信処理結果の書込み要求を行う。
【選択図】図１

Description

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

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

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

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

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

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

従来、複数のサービスがそれぞれ保有するＩＤを連携させる方法が開示されている。特許文献１には、サービス提供サーバがユーザのアクセスを認証サーバへ誘導し、認証サーバとユーザ間で認証情報の登録、認証処理を実行する方法が開示されている。特許文献２には、連携するサービス提供サーバのそれぞれでユーザ識別情報を管理する方法が開示されている。

特開２０１１−２２１７２９号公報特開２０１０−１１３４６２号公報

複数のサービスが連携して動作するワークフロー全体の処理結果をクラウドプラットフォームサービス上で一意に確認できるようにするためには、各サービスの処理結果を履歴としてクラウドプラットフォームサービスに保存する必要がある。

しかしながら、このワークフローではユーザが介在しないため、通常のユーザを基準とした認証の仕組みを用いることが出来ず、クラウドプラットフォームサービスが文書生成指示を行う場合、文書生成サーバが処理を完了するまで接続を維持する必要がある。
そのため、処理完了までコネクションを切断することができず、文書生成サーバは大量のリクエストを同時に受け付けることができない。また、文書生成処理が一定時間をこえると、リクエスト側のクラウドプラットフォームサービスがタイムアウトするため、文書生成処理結果をクラウドプラットフォームサービスに送信することができない。

クライアント端末１０１、クラウドプラットフォームサービス１０２および文書生成サーバ１０３、プリンタ１０４がネットワークで接続された文書生成システムであって、クラウドプラットフォームサービス１０２は以下を含む。

スケジュールジョブを登録するスケジュール管理部３０３。

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

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

スケジュールジョブの実行結果である実行履歴情報９２０を作成し、文書生成サーバ１０３からの要求に応じて実行履歴情報９２０を更新する実行履歴管理部３０５。

前記実行履歴管理部３０５はさらに、スケジュールジョブの実行結果を一意に識別するジョブＩＤを作成する。

前記生成したジョブＩＤとともに文書生成サーバ１０３へ文書生成リクエストを行うステップ（Ｓ１３０１）。

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

さらに文書生成サーバ１０３は以下を備える。

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

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

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

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

前記取得したアクセストークンを用いてクラウドプラットフォームサービス１０２からデータの取得を行うステップ（Ｓ１３１０）。

前記取得したアクセストークンおよび前記クラウドプラットフォームサービス１０２から受信したジョブＩＤを用いてクラウドプラットフォームサービス１０２へ文書送信処理結果の書込み要求を行うステップ（Ｓ１３１３）を有するシステム。

複数のサービスが連携してスケジュールジョブを実行するシステムにおいて、ユーザが介在しない状態で動作する場合においても、長時間コネクションを維持することなく文書生成の実行履歴をクラウドプラットフォームサービスに書き込むことが可能。これにより、
文書生成サーバは大量のリクエストを同時に受け付けることが可能となる。

また、長時間の文書生成処理であったとしても、実行履歴をクラウドプラットフォームサービスに送信することができる。

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

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

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

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

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

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

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

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

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

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

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

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

図２は、図１のクライアント装置１０１、クラウドプラットフォームサービス１０２、文書生成サーバ１０３のハードウェア構成を示すブロック図である。図中、２０１は内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するＣＰＵである。２０２はＢＩＯＳが格納してあるＲＯＭである。

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

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

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

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

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

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

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

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

前述のスケジュール管理部３０３によって実行された文書生成要求の成否を含む実行履歴を保持し管理する実行履歴管理部３０５。

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

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

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

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

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

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

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

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

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

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

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

文書生成要求による文書生成処理の成否を含む実行履歴をクラウドプラットフォームサービス１０２に保存するためのリクエストを送信する実行履歴書き込み部４０６。

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

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

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

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

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

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

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

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

図８は、クライアント端末１０１から、クラウドプラットフォームサービス１０２にアクセスして表示した、実行履歴一覧画面８００の例である。なお、図８は、ユーザがクラウドプラットフォームサービス１０２にログイン済の状態である。

実行履歴一覧画面８００は、実行中または実行済みのジョブの履歴であるジョブ実行履歴８０１からなる。本画面に表示された実行履歴を確認することで、前述のスケジュール設定画面７００で登録したジョブの処理結果が確認できる。ジョブ実行履歴８０１に表示されるカラムの内容は、後述する実行履歴情報９２０の内容が表示される。

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

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

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

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

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

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

また、実行履歴情報９２０は前述の実行履歴一覧画面８００に表示されるジョブの実行結果情報であり、以下からなる。

ジョブを一意に識別するジョブＩＤ９２１。

どのスケジュール情報に基づいて実行されたジョブなのかを区別するためのバッチジョブ名９２２。

ジョブの実行履歴が更新された日時である実行日時９２３。

ジョブの処理状態であるステータス９２４。

ジョブの処理状態の詳細情報であるメッセージ９２５からなる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｓ１２１０にて、ページ生成部４０２はアクセストークン、リフレッシュトークン保存完了のメッセージを生成し、クライアント端末１０１に返す。

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

本フローは、クラウドプラットフォームサービス１０２のスケジュール管理部３０３が管理するジョブ開始日時９１２に従って、文書生成処理が開始されることによって始まる。

クラウドプラットフォーム１０２のスケジュール管理部３０３は、Ｓ１３０１においてスケジュール情報９１０のレコードを取得し、現在日時がジョブ開始日時９１２であるバッチジョブ名９１１、印刷パラメータ９１３を取得する。

Ｓ１３０２にて、実行履歴管理部３０５は文書生成処理の実行履歴を保存するためのレコードである実行履歴情報９２０を新規作成する。レコードは作成の際、実行履歴管理部３０５は一意のジョブＩＤ９２１を生成する。

Ｓ１３０３で、実行履歴管理部３０５はＳ１３０１で取得したバッチジョブ名９１１をバッチジョブ名９２２に、現在時刻を実行日時９２３に、文書生成開始を示すステータスをステータス９２４に、詳細メッセージをメッセージ９２５に書き込む。

Ｓ１３０４でスケジュール管理部３０３は、文書生成サーバ１０３に対して認証情報９００のテナントＩＤ９０１、認証キー９０２とともに、ジョブＩＤ９２１と印刷パラメータ９１３を文書生成リクエストとして送信する。この時、認証情報９００をリクエストに含めるだけでなく、ダイジェスト認証のように文書生成サーバ１０３からチャレンジを受け取り、チャレンジとともに認証情報９００のダイジェスト値をリクエストに含めるなど、どのような方法でもよい。

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

Ｓ１３０７にて、実行履歴書込部４０６はリクエストの検証結果をレスポンスとしてクラウドプラットフォームサービス１０２に送信する。

レスポンスにはＳ１３０５で受信したジョブＩＤ、検証結果、メッセージを含める。

Ｓ１３０６でリクエストの検証が正しくないと判断された場合、このＳ１３０７で文書生成処理は中断される。

Ｓ１３０８でレスポンスとしてリクエストの検証結果を受信した実行履歴管理部３０５は、実行履歴情報９２０のジョブＩＤ９２１とレスポンスに含まれるジョブＩＤが一致するレコードに、ステータス９２４、メッセージ９２５を書き込む。

具体的には、ステータス９２４にはレスポンスの検証結果、メッセージ９２５にはレスポンスに含まれるメッセージを書き込む。

この時点でクラウドプラットフォームサービス１０２と文書生成サーバ１０３のコネクションは切断される。

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

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

Ｓ１３１１でクラウドプラットフォームサービス１０２のデータ管理部３０４は、業務データ取得のＡＰＩ要求を受けて、文書生成サーバ１０３へ業務データを送信する。

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

Ｓ１３１３で、実行履歴書込部４０６は文書生成処理結果を履歴書込要求としてクラウドプラットフォームサービス１０２に送信する。クラウドプラットフォームサービス１０２が公開するＷｅｂサービスＡＰＩに対して、パラメータとしてＳ１３０９で取得したアクセストークン１００３を指定することで実行履歴書込みが可能となる。履歴書込要求には、Ｓ１３０９で取得したアクセストークン１００３、Ｓ１３０５で取得したジョブＩＤ９２１、ステータスとして文書生成処理結果、メッセージとして詳細メッセージを含む。

Ｓ１３１４でクラウドプラットフォームサービス１０２の実行履歴管理部３０５は履歴書込要求を受けて、実行履歴情報９２０のジョブＩＤ９２１と要求に含まれるジョブＩＤが一致するレコードに、ステータス９２４、メッセージ９２５を書き込む。

以上により、文書生成システムが行う文書生成処理における実行履歴書込処理が実行される。

１０１クライアント装置
１０２クラウドプラットフォームサービス
１０３文書生成サーバ
３０５実行履歴管理部
４０６実行履歴書込部
９２０実行履歴情報

Claims

クライアント端末１０１、クラウドプラットフォームサービス１０２および文書生成サーバ１０３、プリンタ１０４がネットワークで接続された文書生成システムであって、クラウドプラットフォームサービス１０２は以下を含む。
スケジュールジョブを登録するスケジュール管理部３０３。
文書生成サーバ１０３からの要求に対してアクセストークンを発行するアクセス制御部３０１。
文書生成サーバ１０３へのアクセス検証に使用される認証キーをテナントＩＤに紐付けて保存するステップ（Ｓ１１１１）。
スケジュールジョブの実行結果である実行履歴情報９２０を作成し、文書生成サーバ１０３からの要求に応じて実行履歴情報９２０を更新する実行履歴管理部３０５。
前記実行履歴管理部３０５はさらに、スケジュールジョブの実行結果を一意に識別するジョブＩＤを作成する。
前記生成したジョブＩＤとともに文書生成サーバ１０３へ文書生成リクエストを行うステップ（Ｓ１３０１）。
文書生成サーバ１０３からの要求に応じて業務データを送信するデータ管理部３０４。
さらに文書生成サーバ１０３は以下を備える。
クラウドプラットフォームサービスの１０２からのアクセスの検証を行うための認証キーを発行するステップ（Ｓ１１０３）。
前記認証キーをテナントＩＤとともに管理する設定管理部４０３。
前記設定管理部４０３はさらに、クラウドプラットフォームサービス１０２から取得したアクセストークンをテナントＩＤに紐付けて保存する（Ｓ１２１０）。
クラウドプラットフォームサービス１０２からの文書生成リクエストの検証を前記テナントＩＤおよび認証キーにて行うステップ（Ｓ１３０６）。
前記テナントＩＤに紐付くアクセストークンを取得するステップ（Ｓ１３０９）。
前記取得したアクセストークンを用いてクラウドプラットフォームサービス１０２からデータの取得を行うステップ（Ｓ１３１０）。
前記取得したアクセストークンおよび前記クラウドプラットフォームサービス１０２から受信したジョブＩＤを用いてクラウドプラットフォームサービス１０２へ文書送信処理結果の書込み要求を行うステップ（Ｓ１３１３）を有するシステム。