JP2016024721A

JP2016024721A - サーバシステム、方法、およびそのプログラム

Info

Publication number: JP2016024721A
Application number: JP2014149939A
Authority: JP
Inventors: 佐藤　雄一郎; Yuichiro Sato; 雄一郎佐藤
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-07-23
Filing date: 2014-07-23
Publication date: 2016-02-08
Anticipated expiration: 2034-07-23
Also published as: JP6415155B2

Abstract

【課題】本番環境とサンドボックス環境の複数の実行環境を有するクラウドプラットフォームサービスからリクエストが来た場合、文書生成サービスがどの環境からリクエストが来たのかを判別可能とする。
【解決手段】文書生成サービスはアクセストークンとともにテナントＩＤ、クラウドプラットフォームサービスの組織ＩＤ、組織種別を紐づけて管理する。クラウドプラットフォームサービスが文書生成リクエストのパラメータにテナントＩＤおよび自身の組織ＩＤを含めて送信すると、文書生成サービスはテナントＩＤ、組織ＩＤが一致するアクセストークンをパラメータにして、組織種別応じたクラウドプラットフォームサービスへのＵＲＬを使用して文書生成処理を実行する。
【選択図】図８

Description

本発明は、サービス間連携を行うサーバシステム、方法、よびそのプログラムに関する。

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

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

クラウドプラットフォームサービスと文書生成サーバが連携を行う場合、ユーザがそれぞれのサーバで認証を行うことなく２つのサーバを連携させることが可能である。それが、例えばＯＡｕｔｈを始めとする認可の仕組みである。文書生成サーバはアクセストークンと呼ばれる認可情報を送信するとともにクラウドプラットフォームサービス上にあるデータへアクセスすることで、ユーザが認証情報を入力することなく文書生成サーバはそのデータの取得が可能となる。

また、クラウドプラットフォームサービスにはサンドボックス機能を備えるサービスもあり、運用中の環境（データや設定などの環境情報）のコピー環境を作成することが可能である。このサンドボックス環境を用いることで運用中の本番環境に影響を与えることなく、開発行為を行うことが可能となる。この場合、文書生成サーバは本番環境とテスト環境の両方にアクセスするために複数のアクセストークンを管理する必要がある。

従来、複数のアクセストークンを管理する方法について以下の方法が開示されている。特許文献１には中継サーバにアクセストークンとユーザＩＤを併せて保持することにより、クライアントから機能提供サービスにアクセスする際に中継サーバを介することでユーザＩＤのみで機能提供サービスにアクセスする方法が開示されている。

特開２０１４−１０７６９

クラウドプラットフォームサービスでサンドボックス環境を作成し、両方の環境が文書生成サービスを始めとする別のクラウドサービスに処理のリクエストを送信してきた場合、別のクラウドサービスは本番環境およびサンドボックス環境にアクセスするために夫々の環境に対応する複数のアクセストークンを保持しておく必要がある。

ここで問題なのは、サンドボックス環境は本番環境のコピー環境でありどちらの環境であっても送信するリクエストの内容は同一であるので、従来の仕組みでは文書生成サービスがどのアクセストークンを使用してクラウドプラットフォームサービスにアクセスすればいいのかを特定することができない。

本願発明の目的は、同一のリクエストを送信する複数の環境と連携するサーバがリクエストを受信した際、そのリクエストが何れの環境からのリクエストであるかを認識し、使用するアクセストークンを特定することでリクエストを送信してきた環境と連携することを実現する。

本発明の一実施形に係るサーバシステムは、複数の実行環境を有するサーバと通信可能なサーバシステムであって、認証情報を入力することなく特定の実行環境からデータの取得を可能にする前記複数の実行環境毎に発行された認可情報を、夫々の認可情報が対応する実行環境と関連付くよう、前記複数の実行環境の夫々に対して一意に割り当てられた識別情報と関連付けて管理する管理手段と、前記サーバにおける任意の実行環境からデータ処理のリクエストとともに前記任意の実行環境に対して一意に割り当てられた識別情報を受信する受信手段と、前記受信手段により受信された識別情報を基に、前記管理手段により管理された認可情報の中から前記受信された前記識別情報に関連付く認可情報を特定する特定手段と、前記特定手段により特定された認可情報を用いて前記リクエストを送信した前記任意の実行環境にアクセスし、認証情報を入力することなく前記任意の実行環境からデータを取得し、取得された前記データに対し処理を施すことを特徴とする。

同一のリクエストを送信する複数の環境と連携するサーバがリクエストを受信した際、そのリクエストが何れの環境からのリクエストであるかを認識し、使用するアクセストークンを特定することでリクエストを送信してきた環境と連携することが実現できる。

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

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

図１は、本発明の実施例のシステム構成を示すブロック図である。１０１は、後述するクラウドプラットフォームサービス１０２および後述する文書生成サービス１０３に対してリクエストを発行するクライアント１０１である。クラウドプラットフォームサービス（以降、ＣＰＳ）１０２は、クライアント１０１や文書生成サービス１０３からのリクエストに応じて、保持するデータの表示・更新等を行う。文書生成サービス１０３は、ＣＰＳ１０２からのリクエストを受信して文書生成を行う。また、クライアント１０１からのリクエストに応じて保持する設定情報の表示・更新等を行う。

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

ネットワークはデータの送受信が可能であればよい。クライアント１０１とＣＰＳ１０２および文書生成サービス１０３との通信手段、文書生成サービス１０３とＣＰＳ１０２やプリンタ１０４との通信手段、及び各サーバ間の通信手段が異なっていてもよい。

ＣＰＳ１０２は、ユーザの管理、業務データ等のデータの管理、後述する文書生成サービス１０３への文書生成リクエストを送信する。また、ＣＰＳ１０２は、複数の企業・組織から使用されることが前提であり（一般的にマルチテナントと呼ばれる）、使用する企業・組織毎に前述のユーザ管理、業務データ管理等が行われる。さらにＣＰＳ１０２は、サンドボックス環境という特定の組織のコピー（データや設定などの環境情報）環境の作成が可能である。このサンドボックス環境は本番環境と同じ設定、データを保持するが、本番環境とは別の環境であり、このサンドボックス環境を用いてサービス間連携のテストを行うことで運用中の本番環境に影響を与えることなく本番と同様の動作テストを行うことが出来るので精密な開発行為を行うことが可能となる。本番環境とサンドボックス環境では、外部（例えば文書生成サービス１０３）からのリクエストを受け付けるためのＵＲＬおよび／またはＡＰＩが異なり、認証情報だけでなくアクセスするＵＲＬが環境の種別に一致している必要がある。

文書生成サービス１０３はいわゆるＷｅｂアプリケーションの機能を有するよう構成されており、クライアント１０１を介してアクセスする事ができ、クライアント１０１からのリクエストに対してユーザインタフェース情報を返答する。また、文書生成サーバ１０３はＣＰＳ１０２からの文書生成リクエストを受信すると、ＣＰＳ１０２から業務データ等のデータを取得し、受信したデータとＣＰＳ１０２で管理するフォームデータを使用してオーバーレイ処理を行い、文書データを生成する。この時、適宜ＣＰＳ１０２に対して、文書生成履歴の書込みリクエストを送信する。なお、図１に示すシステムを構成する各装置は１台ずつ存在するように示したが複数台であっても良い。サーバシステムと称した場合、１台のサーバおよび複数台のサーバから構成されるサーバ群を含むサーバのことを指す。

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

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

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

ＣＰＳ１０２は以下で構成される。クライアント１０１または文書生成サービス１０３からのリクエストを受け付け、処理結果を送信する送受信部３０１。認証処理部３０２は、文書生成サービス１０３からのアクセストークン取得リクエストに応じてアクセストークンの生成および送信を行い、また、クライアント１０１または文書生成サービス１０３からのリクエストに応じてユーザ認証を行う。また、認証処理部３０２は文書生成サービス１０３へ文書生成リクエストを送信する際の認証処理を行う。文書生成実行履歴を含む業務データおよび各種設定をデータベースに保持し、リクエストに応じてデータの取得、あるいはデータの更新を行うデータ管理部３０３。クライアント１０１またはＣＰＳ１０２自身によるスケジュール実行などからのリクエストに応じて、文書生成サービス１０３へ文書生成リクエストを送信する文書生成要求部３０４。

クライアント１０１からのリクエストを受け付け、サンドボックス環境の作成や更新、削除を行うサンドボックス管理部３０５である。本番環境とサンドボックス環境の違いについて説明する。始めに、環境とはプログラム、およびデータが特定の範囲内の領域に展開されてプログラムが実行されデータ処理が行われるシステム領域を指す。そして、本番環境とはユーザからの実際の処理依頼を受けたことに応じてデータ処理を行い、その結果をユーザに提供するための実行環境である。一方、サンドボックス環境は本番環境でユーザの要望する結果が出せるか否かを検証するための実行環境である。何れも実行環境であり、同一のプログラム、同一のデータが取り扱われるので動作や構成自体に差異はなく、ただ、互いの領域に存在するプログラム、データにアクセスすることはできない。

よって、図３に示す論理的に構築されたソフトウェア構成に関して本番環境とサンドボックス環境に差異がないのはもちろんのこと、取り扱うデータ種に関しても差異はない、言わば論理的に完全に独立した実行環境同士である。しかし、リクエストを外部から受け付けた際に何れの実行環境でデータ処理を行うかを特定する必要があるため、実行環境の各種機能を呼び出すためのＵＲＬ、および／またはＡＰＩは夫々異なるという性質がある。なお、何れの環境もＣＰＳ１０２内で実現される実行環境であり、本実施例ではサンドボックス環境が１つとして説明するが複数存在しても良い。ＣＰＳ１０２にて実現された各環境におけるこれら各構成要素は、互いに協調して動作することにより後述する処理を実行する。

また、上述のデータベースは管理ユーザデータや業務データ、テナントＩＤ、認証キーを格納するストレージであり、図２で示したＨＤＤ２０４に記憶されている。前述のデータベースに格納されるデータは企業・組織（以降、組織と表記）毎に管理される。各組織には組織ＩＤと呼ばれる実行環境を一意に識別するための識別情報が自動的に割り当てられ、組織ＩＤとともに各データが管理される。以降のデータ取得等の処理は組織ＩＤをもとに行われ、組織ＩＤの一致するデータのみを参照することが可能となっている。組織ＩＤは本番環境および各々のサンドボックス環境で異なる値が割り当てられる。

図４は、文書生成サービス１０３上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。文書生成サービス１０３は以下で構成される。クライアント１０１またはＣＰＳ１０２からのリクエストを受け付け、処理結果を送信する送受信部４０１。クライアント１０１からのログインリクエストに対するユーザ認証およびＣＰＳ１０２からの文書生成リクエストに対する認証を行う認証処理部４０２。後述のアクセストークンおよびテナントＩＤ、組織ＩＤ、組織種別を管理する設定管理部４０３。

文書生成リクエストによる文書生成処理の成否を含む処理状況を、文書生成実行履歴としてＣＰＳ１０２に保存するためのリクエストを送信する実行履歴管理部４０４。ＣＰＳ１０２にアクセスして業務データを取得し、その業務データとフォームを使用してオーバーレイ処理を行い、文書データを生成する文書生成部４０５。なお、文書生成部４０５がサービス提供を行うサービス提供部である。文書生成サーバ１０３はこれら各構成要素の協調により、後述する処理を実行する。

表１−Ａおよび表１−Ｂは、ＣＰＳ１０２が保持する情報のテーブル構造例を示す表である。表１−Ａは文書生成サービス１０３への文書生成リクエスト時に使用する認証情報Ｔ１００であり、文書生成サーバ１０３のテナントを識別するテナントＩＤおよび、認証キーからなる。表１−Ｂは実行履歴情報Ｔ１１０であり、文書生成処理のジョブ実行結果情報が格納され、以下からなる。ジョブを一意に識別するジョブＩＤおよびジョブを判別するためのジョブ名、ジョブの実行履歴が更新された日時である実行日時、ジョブの処理状態であるステータス、ジョブの処理状態の詳細情報であるメッセージからなる。

表２−Ａおよび表２−Ｂは、文書生成サービス１０３が保持する情報のテーブル構造例を示す図である。表２−Ａは、ＣＰＳ１０２からの文書生成リクエストを認証するために使用する文書生成認証情報Ｔ２００であり、テナントＩＤおよび認証キーからなる。表２−Ｂは、文書生成サービス１０３からＣＰＳ１０２への実行履歴書き込みの認証および業務データの取得の認証に使用されるアクセストークン情報Ｔ２１０であり、以下に記載の情報で構成される。文書生成サービス１０３のテナントを識別するテナントＩＤ。ＣＰＳ１０２の組織を一意に識別するための組織ＩＤ。ＣＰＳ１０２へのアクセス先組織が本番環境かサンドボックス環境かによってＵＲＬを決定するための組織種別。ＣＰＳ１０２にアクセスする際に認証情報として使用するアクセストークンおよびアクセストークンを更新するためのリフレッシュトークン。

図５は、クライアント１０１から、文書生成サービス１０３にアクセスして表示した、認証認可設定画面５００の例である。なお、図５は、ユーザが文書生成サービス１０３のユーザとしてログイン済の状態である。認証認可設定画面５００は、ＣＰＳ１０２からの文書生成リクエストの認証に必要なテナントＩＤ５０１および認証キー５０２、そして文書生成サービス１０３がＣＰＳ１０２へアクセスするためのアクセストークン一覧５０３を表示する。さらに認証認可設定画面５００は、ＣＰＳ１０２からアクセストークンを取得するための組織種別チェックボックス５０４および登録ボタン５０５を備える。組織種別チェックボックス５０４および登録ボタン５０５押下時の処理は後述する。

図６は、クライアント１０１から、ＣＰＳ１０２にアクセスして表示した、認証情報登録画面６００の例である。なお、図６は、ユーザがＣＰＳ１０２のユーザとしてログイン済の状態である。認証情報登録画面６００は、前述の認証認可設定画面５００から取得したテナントＩＤ、認証キーを入力するテナントＩＤ６０１、認証キー６０２および、入力した値をデータ管理部３０３に保存するリクエストを発行するＯＫボタン６０３が表示されている。ユーザはまず認証認可設定画面５００にアクセスし、そこに表示されたテナントＩＤ５０１および認証キー５０２を控えておく。ここに表示される値は設定管理部４０３が文書生成認証情報Ｔ２００から取得した値である。次に認証情報登録画面６００にアクセスし、控えておいた値をテナントＩＤ６０１および認証キー６０２を入力、ＯＫボタン６０３を押下する。ＯＫボタン６０３が押下されることで、ＣＰＳ１０２の送受信部３０１に認証情報登録リクエストが送信される。送受信部３０１が認証情報登録リクエストを受け取ると、ＣＰＳ１０２のデータ管理部３０３は受け取ったテナントＩＤと認証キーをそれぞれ認証情報Ｔ１００のテナントＩＤ、認証キーとしてレコードに保存する。

図７は、ＣＰＳ１０２にアクセスするための認可情報を文書生成サービス１０３に保存する処理の流れを示している。認可の方法としてＯＡｕｔｈプロトコルが一般的であり図７の処理もＯＡｕｔｈプロトコルに従う認可処理の一例である。

はじめ、Ｓ７０１においてユーザは不図示のログイン画面にて認証情報を入力し、文書生成サービス１０３は認証処理を行いユーザのログインを許可し、認証情報確認画面５００をクライアント１０１上に表示する。Ｓ７０２において、認証情報確認画面５００の登録ボタン５０５を押下すると、認可開始リクエストが文書生成サービス１０３に送信される。この時、組織種別チェックボックス５０４のチェック状態もリクエストに含まれた状態で送信される。

リクエストを受信した送受信部４０１は、Ｓ７０３でクライアント１０１を経由してＣＰＳ１０２にスコープをパラメータとして認可リクエストを行う。この際、文書生成サービス１０３はクライアント１０１に対しＣＰＳ１０２へアクセスするようリダイレクトの命令を出す。なお、スコープとは認可許可する範囲を示すもので、本実施例ではＣＰＳ１０２のユーザデータ操作を認可の範囲としてスコープ指定している。

Ｓ７０４からＳ７０７までの処理は、ＯＡｕｔｈプロトコルの一般的な認可処理フローのため、一部説明を割愛する。Ｓ７０４に対するレスポンスとしてクライアント１０１に返される認可画面は、ユーザが認証情報確認画面にて選択した何れかの実行環境におけるユーザの権限を、文書生成サービス１０３に委譲することを許可するか否かを問い合わせる画面である。例えば、認証されたユーザが任意の実行環境におけるユーザの権限を文書生成サービス１０３に委譲することを認可画面を介して許可する指示をした場合、任意の実行環境に対応する認可情報がＣＰＳ１０２により発行される。文書生成サービス１０３は認可情報を用いて任意の実行環境にアクセスした場合は、認証情報を入力することなく、即ち通常の認証処理が行われることなくアクセスできる。認可情報の発行処理は実行環境毎に行うことになる。なお、本実施例ではＣＰＳ１０２が認証および認可等の認証機能を備えている前提で説明したが、ＣＰＳ１０２と連携する別の認証サーバが代理で行っても良い。ここで、Ｓ７０３の結果返されるログイン画面はＣＰＳ１０２のログイン画面であって、ユーザは生成したいアクセストークンのユーザでログインする。

Ｓ７０７にて文書生成サービス１０３がアクセストークンおよびリフレッシュトークンを受信すると、送受信部はこのアクセストークンをパラメータとして、組織ＩＤ取得リクエストをＣＰＳ１０２に送信する。この時、Ｓ７０２のリクエストパラメータで受け取っていた組織種別チェックボックス５０４の状態によってＣＰＳ１０２へのアクセスＵＲＬを切り替える。組織種別チェックボックス５０４がＯＮだった場合、つまりサンドボックス環境のアクセストークンを取得していた場合はサンドボックス環境用のアクセスＵＲＬを選択し、ＯＦＦだった場合は本番環境用のアクセスＵＲＬを選択してＣＰＳ１０２にアクセスする。

Ｓ７０８にて組織ＩＤ取得リクエストを受信したＣＰＳ１０２の送受信部３０１は、データ管理部３０３からアクセストークンに紐づくユーザの組織ＩＤを文書生成サービス１０３へ返す。Ｓ７０９にて、設定管理部４０３は表２−Ｂに記載のアクセストークン情報として、ＣＰＳ１０２から取得したアクセストークン、リフレッシュトークン、組織ＩＤ、本番環境かサンドボックス環境かを識別する組織種別、テナントＩＤを保存し管理する。なお、設定管理部４０３は、夫々の情報、具体的にはアクセストークン、リフレッシュトークン、組織ＩＤ、および組織種別の夫々が関連付くように保存・管理する。そして送受信部４０１はアクセストークン、リフレッシュトークン保存完了のメッセージを生成し、クライアント１０１に返す。

図８は、本発明の実施例における文書生成システムが行う文書生成処理の流れを示している。本実施例では、ＣＰＳ１０２のデータをフォームデータに挿入し帳票データを生成し、その帳票データを定期時刻にまとめてバッチプリントする形態を想定している。本フローは、ＣＰＳ１０２の文書生成要求部３０４によって文書生成処理が開始されることによって始まる。文書生成要求部３０４による文書生成処理は、ＣＰＳ１０２による定期実行（不図示）など、どのような方法で開始されてもよい。これは、本番環境であってもサンドボックス環境であっても同じである。

ＣＰＳ１０２の文書生成要求部３０４は、Ｓ８０１においてデータ管理部３０３よって認証情報Ｔ１００のテナントＩＤ、認証キー、および自身の組織ＩＤを取得し、これをパラメータとして文書生成リクエストを送信する。この際に送信するリクエストは同一種のリクエストであり、本番環境とサンドボックス環境の夫々から送信されるリクエストが異なるのは組織ＩＤのみである。この時、認証キーをリクエストに含めるだけでなくダイジェスト認証のように文書生成サービス１０３からチャレンジを受け取り、チャレンジとともに認証キーから生成したダイジェスト値をリクエストに含めるなど、どのような方法でもよい。

Ｓ８０２で文書生成サービス１０３は文書生成リクエストを受信すると、認証処理部４０２は、文書生成認証情報Ｔ２００に保持するテナントＩＤ、認証キーを用いてリクエストに含まれる認証情報の検証を行う。この時、ダイジェスト認証のようにＣＰＳ１０２へチャレンジを送信し、それに対しＣＰＳ１０２から受信したダイジェスト値で認証を行うなど、どのような方法でもよい。

Ｓ８０３で、文書生成部４０５は設定管理部４０３を通じて文書生成認証情報Ｔ２００から、リクエストに含まれるテナントＩＤ、組織ＩＤと一致するレコードのアクセストークン、および組織種別を取得する。Ｓ８０４で、文書生成部４０５はアクセストークンおよび組織種別が取得できたかどうかを確認し、取得できなかった場合はリクエストの検証が不正であると判断された、このＳ８０４で文書生成処理は中断される。アクセストークンおよび組織種別が取得できた場合、Ｓ８０５で送受信部４０１はリクエストの検証結果をレスポンスとしてＣＰＳ１０２に送信する。

Ｓ８０６でレスポンスとして送受信部３０１がリクエストの検証結果を受信した時点でＣＰＳ１０２と文書生成サービス１０３のコネクションは切断される。Ｓ８０７で文書生成部４０５はＣＰＳ１０２が公開するＷｅｂサービスＡＰＩのアクセス先ＵＲＬを組織種別によって決定する。なお、組織種別ではなく、組織を識別するための組織ＩＤから特定しても良い。例えば、組織種別が本番環境の場合は「ｈｔｔｐｓ：／／ｗｗｗ．ｃｐｓ．ｃｏｍ」とし、サンドボックス環境の場合は「ｈｔｔｐｓ：／／ｔｅｓｔ．ｃｐｓ．ｃｏｍ」にアクセスする。これは、組織種別、または組織ＩＤ毎に事前に用意されたＵＲＬである。なお、本実施例ではＵＲＬ形式のアドレスとしたが、直接ＡＰＩを呼び出す形態であっても良い。以降、文書生成サービス１０３からＣＰＳ１０２へのアクセスは、前記Ｓ８０７で決定したＵＲＬに対して、パラメータにＳ８０３で取得したアクセストークンを認証情報として含めることで行われる。

Ｓ８０８で実行履歴管理部４０４は、文書生成処理が開始された旨の実行履歴を作成するため、実行履歴情報Ｔ１１０のレコードの実行履歴作成要求をＣＰＳ１０２へ送信する。実行履歴作成要求はパラメータとして、ジョブ名、ステータス、メッセージを含める。Ｓ８０９でまず、送受信部３０１が実行履歴作成要求を受け付けると、認証処理部３０２はリクエストが送信されたＵＲＬが本番環境向けか、サンドボックス環境向けかを判断し、そのうえでアクセストークンによる認証を行う。

このとき、正しいアクセストークンであっても、本番環境とサンドボックス環境のどちらのユーザのアクセストークンかどうかとＵＲＬが一致しない場合は認証に失敗する。以降、ＣＰＳ１０２は文書生成サービス１０３からリクエストを受け付けると、前記の認証処理を行う。Ｓ８０９で認証に成功するとアクセストークンに紐づくユーザで実行履歴作成要求を受け付け、データ管理部３０３はリクエストパラメータの内容に従って実行履歴情報Ｔ１１０のレコードを新規作成する。レコードは作成の際、一意のジョブＩＤを生成しレコードのジョブＩＤとして保存し、レスポンスとして文書生成サービス１０３へジョブＩＤを送信する。

Ｓ８１０にて、文書生成部４０５は業務データの取得要求（クエリ）を行う。前記Ｓ８０７で決定したＵＲＬに対して、パラメータとしてＳ８０３で取得したアクセストークンを指定する。Ｓ８１１でＣＰＳ１０２のデータ管理部３０３は業務データ取得要求を受け、文書生成サービス１０３へ業務データを送信する。Ｓ８１２で、文書生成サービス１０３の文書生成部４０５は、不図示のフォーム管理モジュールが管理するフォームを取得して、前記取得した業務データと前記取得したフォームから文書データを生成する。Ｓ８１２の文書生成処理は公知のため説明を割愛する。

Ｓ８１３で、実行履歴管理部４０４は文書生成処理結果を実行履歴更新要求としてＣＰＳ１０２に送信する。前記Ｓ８０７で決定したＵＲＬに対し、パラメータにはＳ８０３で取得したアクセストークン、Ｓ８０９で取得したジョブＩＤ、ステータスとして文書生成処理結果、メッセージとして詳細メッセージを含める。Ｓ８１４でＣＰＳ１０２の送受信部３０１は実行履歴更新要求を受け、データ管理部３０３を通じて実行履歴情報Ｔ１１０のジョブＩＤと要求に含まれるジョブＩＤが一致するレコードに、ステータス、メッセージを書き込む。以上により、文書生成システムが行う文書生成処理が実行される。

実施例１では、ＣＰＳ１０２の組織ＩＤとテナントＩＤが一致するアクセストークンを使用して文書生成処理を行うことで、文書生成リクエストの送信元組織を判別していた。本実施例では、ＣＰＳ１０２の本番環境およびサンドボックス環境で組織ＩＤが同一の場合や、組織を一意に区別するための情報が存在しない場合の文書生成方法について説明する。

以下、実施例１で記載済みの内容については説明を省略する。表３は実施例２における文書生成サービス１０３が保持する文書生成サービス１０３からＣＰＳ１０２への実行履歴書き込みの認証および業務データの取得の認証に使用されるアクセストークン情報Ｔ３００であり、以下からなる。文書生成サービス１０３のテナントを識別するテナントＩＤ。ＣＰＳ１０２へのアクセス先組織が本番環境かサンドボックス環境かによってＵＲＬを決定するための組織種別。ＣＰＳ１０２にアクセスする際に認証情報として使用するアクセストークンおよびアクセストークンを更新するためのリフレッシュトークン。

図９は本発明の実施例２における文書生成システムが行う文書生成処理の流れを示している。本フローは、ＣＰＳ１０２の文書生成要求部３０４によって文書生成処理が開始されることによって始まる。文書生成要求部３０４による文書生成処理は、ＣＰＳ１０２による定期実行（不図示）など、どのような方法で開始されてもよい。

Ｓ９０１においてＣＰＳ１０２の文書生成要求部３０４は、データ管理部３０３を通じて文書生成処理の実行履歴を保存するためのレコードである実行履歴情報Ｔ３００のレコードを新規作成する。レコード作成の際、データ管理部３０３は一意のジョブＩＤを生成する。Ｓ９０２にて、文書生成要求部３０４はデータ管理部３０３を通じて認証情報Ｔ１００のテナントＩＤ、認証キー、およびＳ９０１で生成したジョブＩＤを取得し、これをパラメータとして文書生成リクエストを送信する。この時、認証キーをリクエストに含めるだけでなくダイジェスト認証のように文書生成サービス１０３からチャレンジを受け取り、チャレンジとともに認証キーから生成したダイジェスト値をリクエストに含めるなど、どのような方法でもよい。

Ｓ９０３で文書生成サービス１０３は文書生成リクエストを受信すると、認証処理部４０２は、文書生成認証情報Ｔ２００に保持するテナントＩＤ、認証キーを用いてリクエストに含まれる認証情報の検証を行う。この時、ダイジェスト認証のようにＣＰＳ１０２へチャレンジを送信し、それに対しＣＰＳ１０２から受信したダイジェスト値で認証を行うなど、どのような方法でもよい。Ｓ９０４で文書生成部４０５は、設定管理部４０３を通じて文書生成認証情報Ｔ３００から、リクエストに含まれるテナントＩＤが一致するレコードの数を取得する。レコード数が０、つまりテナントＩＤに紐づくアクセストークンおよび組織種別が存在しない場合はこのＳ９０４で文書生成処理を中断する。レコード数が１、つまり唯一１つのアクセストークンおよび組織種別が存在する場合は、文書生成部４０５はこのアクセストークンおよび組織種別を取得しＳ９１９を実行する。

Ｓ９１９で文書生成部４０５はＣＰＳ１０２が公開するＷｅｂサービスＡＰＩのアクセス先ＵＲＬを組織種別によって決定する。詳細はＳ８０７と同様のため省略する。そして後述するＳ９１０に処理を移行する。レコード数が複数存在する場合は、Ｓ９０５の処理に移行する。Ｓ９０５で文書生成部４０５は、Ｓ９０４で取得したレコードの１件からアクセストークンおよび組織種別を取得する。このときすべてのレコードについて取得が終わっていた場合、Ｓ９０５で文書生成処理を中断する。Ｓ９０５でアクセストークンおよび組織種別が取得できた場合、Ｓ９０６の処理に移行する。Ｓ９０６はＳ８０７およびＳ９１９と同様のため省略する。

以降、文書生成サービス１０３からＣＰＳ１０２へのアクセスは、前記Ｓ９０６またはＳ９１９で決定したＵＲＬに対して、パラメータにＳ９０４で取得したアクセストークンを認証情報として含めることで行われる。Ｓ９０７で文書生成サービス１０３の実行履歴管理部４０４は、前記Ｓ９０３で取得したジョブＩＤを検索キーとしてＣＰＳ１０２に対してジョブＩＤが一致する実行履歴の取得リクエストを送信する。Ｓ９０８でまず、送受信部３０１が実行履歴取得リクエストを受け付けると、認証処理部３０２はリクエストが送信されたＵＲＬが本番環境向けか、サンドボックス環境向けかを判断し、そのうえでアクセストークンによる認証を行う。このとき、正しいアクセストークンであっても、本番環境とサンドボックス環境のどちらのユーザのアクセストークンかどうかとＵＲＬが一致しない場合は認証に失敗する。以降、ＣＰＳ１０２は文書生成サービス１０３からリクエストを受け付けると、前記の認証処理を行う。

実行履歴の取得リクエストを受信した送受信部３０１は、データ管理部３０３を通じて実行履歴情報Ｔ３００からジョブＩＤが一致する実行履歴情報を取得する。ジョブＩＤが一致する実行履歴が存在すればそのレコード情報を、存在しない場合はその旨を文書生成サービス１０３へレスポンスとして送信する。Ｓ９０９において、Ｓ９０８でジョブＩＤが一致する実行履歴が取得できた場合は、文書生成リクエストを送信したＣＰＳ１０２の組織のアクセストークンであるとして、文書生成部４０５はＳ９１０を実行する。ジョブＩＤが一致する実行履歴が取得できなかった場合、文書生成リクエストを送信したＣＰＳ１０２の組織のアクセストークンでないと判断してＳ９０５に遷移する。

Ｓ９１０、Ｓ９１１はそれぞれＳ８０５、Ｓ８０６と同様のため記載を省略する。Ｓ９１２で実行履歴管理部４０４は、文書生成処理が開始された旨の実行履歴を書き込むため、実行履歴情報Ｔ１１０のレコードの実行履歴更新要求をＣＰＳ１０２へ送信する。実行履歴更新要求はパラメータとして、ジョブＩＤ、ジョブ名、ステータス、メッセージを含める。Ｓ９１３で送受信部３０１が実行履歴更新要求を受け付けると、アクセストークンに紐づくユーザで実行履歴更新要求を受け付け、データ管理部３０３はリクエストパラメータの内容に従って実行履歴情報Ｔ１１０のレコードを更新する。以降、Ｓ９１４からＳ９１８はＳ８１０からＳ８１４と同様のため、記載を省略する。以上により、実施例２における文書生成システムが行う文書生成処理が実行される。

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

１０１クライアント
１０２クラウドプラットフォームサービス
１０３文書生成サービス
３０３データ管理部
３０５サンドボックス管理部
４０４実行履歴管理部

Claims

複数の実行環境を有するサーバと通信可能なサーバシステムであって、
認証情報を入力することなく特定の実行環境からデータの取得を可能にする前記複数の実行環境毎に発行された認可情報を、夫々の認可情報が対応する実行環境と関連付くよう、前記複数の実行環境の夫々に対して一意に割り当てられた識別情報と関連付けて管理する管理手段と、
前記サーバにおける任意の実行環境からデータ処理のリクエストとともに前記任意の実行環境に対して一意に割り当てられた識別情報を受信する受信手段と、
前記受信手段により受信された識別情報を基に、前記管理手段により管理された認可情報の中から前記受信された前記識別情報に関連付く認可情報を特定する特定手段と、
前記特定手段により特定された認可情報を用いて前記リクエストを送信した前記任意の実行環境にアクセスし、認証情報を入力することなく前記任意の実行環境からデータを取得し、取得された前記データに対し処理を施すサービス提供手段と、を有するサーバシステム。
前記管理手段は、実行環境にアクセスするため前記複数の実行環境毎に用意されたアドレスおよび／またはＡＰＩを、前記認可情報と同様、前記複数の実行環境の夫々対して一意に割り当てられた識別情報と関連付けて管理し、
前記特定手段は、前記受信手段により受信された識別情報を基に、前記管理手段により管理されたアドレスおよび／またはＡＰＩの中から前記受信された前記識別情報に関連付くアドレスおよび／またはＡＰＩを特定し、
前記サービス提供手段は、前記特定手段により特定されたアドレスおよび／またはＡＰＩと認可情報を用いて前記リクエストを送信した前記任意の実行環境にアクセスすることを特徴とする請求項１に記載のサーバシステム。
前記サーバは、ログイン画面を介してユーザに入力された認証情報を基に認証を行い、認証された前記ユーザが認可画面を介し、前記サーバシステムに前記任意の実行環境における前記ユーザの権限を委譲することを許可した場合に前記認可情報を発行する認証機能と連携するサーバであって、
前記複数の実行環境の内、何れかの実行環境に対応する前記認可情報を発行する指示を受け付けるための認証情報確認画面をユーザが操作するクライアントに提供する提供手段を有する請求項１または２に記載のサーバシステム。
前記提供手段により提供された認証情報確認画面を介し、前記任意の実行環境に対応する前記認可情報を発行する指示を受け付けたことに応じて、前記クライアントに対し前記認証機能に対して前記任意の実行環境に対応する前記認可情報を発行するための命令を送信することを特徴とする請求項３に記載のサーバシステム。
前記リクエストは、前記サーバ内にて管理されるデータをバッチプリントするためのリクエストであり、前記任意の実行環境により定期時刻に送信され、
前記サービス提供手段は、前記データをフォームに挿入し帳票データを生成する処理を施すことを特徴とする請求項１乃至４の何れか１項に記載のサーバシステム。
複数の実行環境を有するサーバと通信可能なサーバシステムを制御する方法であって、
管理手段は、認証情報を入力することなく特定の実行環境からデータの取得を可能にする前記複数の実行環境毎に発行された認可情報を、夫々の認可情報が対応する実行環境と関連付くよう、前記複数の実行環境の夫々に対して一意に割り当てられた識別情報と関連付けて管理し、
受信手段は、前記サーバにおける任意の実行環境からデータ処理のリクエストとともに前記任意の実行環境に対して一意に割り当てられた識別情報を受信し、
特定手段は、前記受信手段により受信された識別情報を基に、前記管理手段により管理された認可情報の中から前記受信された前記識別情報に関連付く認可情報を特定し、
サービス提供手段は、前記特定手段により特定された認可情報を用いて前記リクエストを送信した前記任意の実行環境にアクセスし、認証情報を入力することなく前記任意の実行環境からデータを取得し、取得された前記データに対し処理を施すことを特徴とする方法。
前記管理手段は、実行環境にアクセスするため前記複数の実行環境毎に用意されたアドレスおよび／またはＡＰＩを、前記認可情報と同様、前記複数の実行環境の夫々対して一意に割り当てられた識別情報と関連付けて管理し、
前記特定手段は、前記受信手段により受信された識別情報を基に、前記管理手段により管理されたアドレスおよび／またはＡＰＩの中から前記受信された前記識別情報に関連付くアドレスおよび／またはＡＰＩを特定し、
前記サービス提供手段は、前記特定手段により特定されたアドレスおよび／またはＡＰＩと認可情報を用いて前記リクエストを送信した前記任意の実行環境にアクセスすることを特徴とする請求項６に記載の方法。
前記サーバは、ログイン画面を介してユーザに入力された認証情報を基に認証を行い、認証された前記ユーザが認可画面を介し、前記サーバシステムに前記任意の実行環境における前記ユーザの権限を委譲することを許可した場合に前記認可情報を発行する認証機能と連携するサーバであって、
提供手段は、前記複数の実行環境の内、何れかの実行環境に対応する前記認可情報を発行する指示を受け付けるための認証情報確認画面をユーザが操作するクライアントに提供することを特徴とする請求項６または７に記載の方法。
前記提供手段により提供された認証情報確認画面を介し、前記任意の実行環境に対応する前記認可情報を発行する指示を受け付けたことに応じて、前記クライアントに対し前記認証機能に対して前記任意の実行環境に対応する前記認可情報を発行するための命令を送信することを特徴とする請求項８に記載の方法。
前記リクエストは、前記サーバ内にて管理されるデータをバッチプリントするためのリクエストであり、前記任意の実行環境により定期時刻に送信され、
前記サービス提供手段は、前記データをフォームに挿入し帳票データを生成する処理を施すことを特徴とする請求項６乃至９の何れか１項に記載の方法。
請求項６乃至１０の何れか１項に記載の方法をコンピュータに実行させるためのプログラム。