JP7086767B2 - プリントサーバー、制御方法、およびそのプログラム - Google Patents

Description

本発明は、非同期通信で通信を行うプリントサーバー、制御方法、およびそのプログラムに関する。

近年、インターネット上にサーバーを配置し、サーバーがクラウドサービスを提供するビジネスが展開されてきている。例えば、データをファイル形式に保存するストレージサービスや、データベース機能を提供するデータベースサービスなどである。また、印刷システムにおいても、プリントサーバーをインターネット上のプリントサービスとして提供する形態が求められてきている。

また、再利用性、保守性、柔軟性を向上せさせるため、クラウドサービスを小規模のサービス単位に細分化し、それを組み合わせてサービスを提供するマイクロサービスのアーキテクチャが主流となってきている。マイクロサービスアーキテクチャは、細分化されたサービスの独立性が高い（疎結合）ことが一つの重要な要素であり、それを実現するためにＰｕｂ／Ｓｕｂメッセージングモデルが適用される。

Ｐｕｂ／Ｓｕｂメッセージングモデルは、メッセージを送信するパブリッシャーと、受信する側のサブスクライバーが中間に存在するトピック（名前付き論理チャネル）を介して情報のやり取りを行う。パブリッシャーは、受信する側を意識することなく情報を送信し、サブスクライバー側は自分の処理に必要な情報のトピックのみを受信するため、互いサービスを意識する必要が無い。そのため、パブリッシャーとサブスクライバーの結合度を低くすることができ、非同期通信を可能にしている。

特許文献１では、複数のサービス間が非同期通信を行い、システムの処理効率の低下を抑えながら連携する方法が述べられている。

特開２００８－２７３４４

しかしながら、クラウドサービスにおいて、非同期通信で情報のやり取りを行う場合、インターネット上の通信環境や遅延等のトラブルが発生する場合がある。特に、第三者提供のサービスを利用してメッセージの送受信を行う場合もそのサービスの障害等により、受信側でメッセージの受信が遅延する場合がある。

文書を管理する文書サービスと、印刷を管理する印刷サービスを想定した場合、文書が入稿されたことを印刷サービスは非同期通信で確認する。そこで遅延が発生すると、印刷サービス側が文書入稿済の情報を受信していない状況で印刷リクエストを受け付けてしまい、対象の文書を印刷できない虞がある。また、２つのサービスを同期させる形態を取った場合、印刷リクエストのたびに文書サービスに問い合わせを行うと、サービス呼び出しに関わるコストが増大し、印刷処理のパフォーマンスに大きく影響する。

そこで、本願発明の目的は、文書サービスと印刷サービスとが非同期で連携するシステムにおいて、非同期通信で遅延が発生した場合でも入稿された文書を印刷することを可能とする機能を提供することを目的とする。

本発明の一実施形態に係るプリントサーバーは、文書情報を基に文書データを取得し、前記文書データを基に印刷データを作成し、前記印刷データをプリンターへ送信するプリントサーバーであって、入稿リクエストを受け付けたことで文書サーバーが生成した文書情報を、前記文書サーバーのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を読み出すことなく、中継サービスを介することで間接的に取得する第１の取得手段と、クライアントから印刷リクエストを受信し、前記印刷リクエストから文書ＩＤを特定し、前記文書ＩＤを含む前記文書情報を前記第１の取得手段によって取得しているか否かを判定する判定手段と、前記判定手段により取得していないと判定された場合に、前記文書サーバーが提供する前記ＡＰＩを呼び出して前記文書サーバーから前記文書ＩＤに対応する前記文書情報を取得する第２の取得手段と、を有し、前記判定手段により取得していると判定された場合は、前記第２取得手段により前記文書情報の取得は行われないことを特徴とする。

文書サービスと印刷サービスとが非同期で連携するシステムにおいて、非同期通信で遅延が発生した場合でも入稿された文書を印刷することを可能とする機能を提供することが可能になる。

ネットワーク構成を示すブロック図 プリントサーバー、プリンターのハードウェア構成図 印刷システムのモジュール構成図 （ａ）文書サーバーのソフトウェア構成図（ｂ）プリントサーバーのソフトウェア構成図 メッセージ送信処理の例 プリントサーバー、文書サーバーで管理するデータ （ａ）実施例１における文書サーバーが外部から入稿リクエストを受け付けた際の処理フロー（ｂ）プリントサーバーが外部から印刷リクエストを受け付けた際の処理フロー （ａ）実施例２における文書サーバーが外部から入稿リクエストを受け付けた際の処理フロー（ｂ）実施例２におけるプリントサーバーが印刷リスエストを受け付けた際に文書ＩＤが指定されていなかった場合の処理フロー プリントサーバーが外部から印刷リクエストを受け付けた際に未印刷文書リストが遅延する可能性を考慮した場合の処理フロー

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

［実施例１］
＜ネットワーク構成＞
図１は、本発明の実施形態に係る印刷システムのネットワーク構成を示す図である。図において、プリンター１０５、クライアント端末１０８はローカルネットワーク１０６を介して複数台接続されていることを想定している。プリンター１０５、クライアント端末１０８は、ローカルネットワーク１０６を介してインターネットワーク１０７にアクセスし、プリントサーバー１０１、文書サーバー１０２、ストレージサーバー１０３、認証サーバー１０４にアクセスすることができる。

プリンター１０５、クライアント端末１０８は有線または無線ＬＡＮを介してネットワークに接続する。ネットワーク１０６～１０７は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれである。またこれらの組み合わせにより実現される、いわゆる通信ネットワークである。ネットワーク１０６～１０７は、データの送受信が可能であればよい。そして、クライアント端末１０８からプリントサーバー１０１、プリンター１０５への通信機能、プリンター１０５からプリントサーバー１０１、文書サーバー１０２、ストレージサーバー１０３、認証サーバー１０４への通信機能は異なっていてもよい。

クライアント端末１０８は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータアシスタント）等から成るが、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０８では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、Ｗｏｒｌｄ ＷｉＤｅ Ｗｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。

プリントサーバー１０１は、あらかじめ文書サーバー１０２に入稿された文書を識別する情報と、出力先プリンター１０５を識別する情報を印刷リクエストと共にクライアント端末１０８のＷｅｂブラウザから受ける。そして、印刷指示を行うコマンドを含めたレスポンスをクライアント端末１０８のＷｅｂブラウザに返す。クライアント端末１０８のＷｅｂブラウザは、指定のプリンター１０５に対し受け取った印刷コマンドを発行する。プリンター１０５は、クライアント端末１０８のＷｅｂブラウザから印刷コマンドを受けると、ストレージサーバー１０３から印刷データを取得し、印刷を行う。なお、プリンター１０５でＩＣカードを用いてプルプリントする場合、プリンター１０５から印刷リクエストを受ける場合もある。

実施例１では各装置が１台である形態を説明するが、各装置が複数台あってもよい。さらに、プリントサーバー１０１、文書サーバー１０２、ストレージサーバー１０３、認証サーバー１０４は複数台のサーバーを仮想化によって１台のサーバーとして機能させる形態であってもよい。

＜プリントサーバー、文書サーバー、プリンターのハードウェア構成＞
図２は、プリントサーバー１０１、文書サーバー１０２のハードウェア構成と、プリンター１０５のハードウェア構成を示す図である。特に断らない限り、本発明の機能が実行可能であるならば単体の機器であっても、複数の機器からなるシステムであっても、本発明が適用できることは言うまでもない。また、特に断らない限り、本発明の機能が実行可能であるならば、ＬＡＮ、ＷＡＮ等のネットワークを介して接続が為され、処理が行われるシステムであっても本発明を適用できることは言うまでもない。実施例１ではシステムバス２１９により各構成要素が接続されているものとして説明する。

２２０は情報処理装置の制御装置であるＣＰＵであり、記憶装置２２４に格納されているプリントサーバーのアプリケーションプログラム、オペレーティングシステム等を実行する。また、ＣＰＵ２２０はＲＡＭ２２２にプログラム実行に必要な情報、ファイル等を一時的に格納する制御を行う。また、ＣＰＵ２２０はプリントサーバープログラムにおける印刷データへの変換処理等を実行する。

２２１は記憶手段であるＲＯＭであり、内部には基本Ｉ／Ｏプログラム等のプログラム、印刷データへのデータ変換の際に使用するフォントデータ、印刷処理、データ変換処理に必要な各種データを記憶する。２２２は一時記憶ユニットであるＲＡＭであり、ＣＰＵ２２０の主メモリやワークエリア等として機能する。２２４は外部記憶手段の一つで、大容量メモリとして機能する記憶装置であり、アプリケーションプログラム、ＯＳ等を格納している。２２３は、ネットワークインターフェースカード（ＮＩＣ）であり、インターフェース２２３を介して外部装置とのデータのやり取りを行う。

プリンター１０５のハードウェアの各構成要素は、システムバス２３０に接続されている。２０９はプリンター１０５のコントローラであり、プリンターの制御系を司る機器である。２３１は装置全体の制御を行うＣＰＵであり、システムバス２３０に接続される各種デバイスとのアクセスを統括的に制御する。この制御は、ＲＯＭ２３２に記憶された制御プログラム等あるいはディスクコントローラ（ＤＫＣ２３５）を介して接続された外部メモリ２３６に記憶された制御プログラムやリソースデータ（資源情報）等に基づく。２３３はＣＰＵ２３１の主メモリ、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。

２４０は大容量メモリとして機能する外部記憶ユニットである。２３９は操作パネル（操作部）であり、画面を表示、または、画面を介したユーザーの操作指示を受け付ける。また、プリンター１０５の動作モード等の設定やプリンター１０５の動作状況の表示、印刷するコンテンツデータを指定する等の操作を行うためのボタンおよび液晶パネル等の表示部も配置される。２３４は、ネットワークインターフェースカード（ＮＩＣ）であり、インターフェース２３４を介して外部装置とのデータのやり取りを行う。なお、本図で示したプリントエンジン２３８は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式（レーザービーム方式）やインクジェット方式、昇華方（熱転写）方式等が挙げられる。２３７のラスタコントローラは、ＰＤＬ言語である印刷データを画像データに変換するコントローラである。２４１の機器Ｉ／Ｆは、ＵＳＢ等で接続可能な外部機器との接続Ｉ／Ｆである。

＜システム構成＞
図３は、本発明の実施形態に係る印刷システムの構成図である。ここでは、印刷システムの構成図を用いて、各サーバー、プリンター、クライアント端末の動作について説明する。これらの動作は、各装置のメモリに保存されたプログラムをＣＰＵが実行することにより実現される。

文書サーバー１０２は、他サービス、または他プログラムから投入される文書データの投入先を示すＵＲＬを作成し、他サービス、または他プログラムに返す。このＵＲＬはストレージサーバー１０３への文書データのアップロード先を示すＵＲＬである。他サービス、または他プログラムはそのＵＲＬに対し、文書データをストレージサーバー１０３にアップロードする。文書サーバー１０２は、アップロードされた旨を他サービス、または他プログラムから受け取ると入稿された文書データの印刷文書情報６２０をデータベース３０１に保存する。

図３において、データベース３０１はプリントサーバー１０１、文書サーバー１０２に夫々記載しているが、本実施例では一つのデータベースで論理的に区切られたデータベースを用いることを想定している。当然、物理的に別々のデータベースを使用してもよい。同時に文書サーバー１０２は、印刷文書情報６２０をメッセージとして送信する。このメッセージの送信方法に関しては後述するが、プリントサーバー１０１は、名前付き論理チャネルを介してメッセージを受信する。プリントサーバー１０１は、Ｗｅｂブラウザ３０２からの印刷リクエストを受けると、印刷リクエストとともに受け取る文書ＩＤ６２１に紐づく文書データをストレージサーバー１０３から取得し、取得した文書データを基に印刷データへの変換を行う。プリントサーバー１０１は、印刷データを作成し、ストレージサーバー１０３上のダウンロードＵＲＬを作成し、印刷データをストレージサーバー１０３にアップロードする。

認証サーバー１０４は、プリントサーバー１０１にアクセスするためのユーザー名、パスワード、認証トークン、認可トークンなどの認証情報を保持している。プリントサーバー１０１は、クライアント端末１０８内のＷｅｂブラウザ３０２からのリクエストに含まれる認証トークンを認証サーバー１０４に送り、トークンの正当性を検証する。このとき、Ｗｅｂブラウザ３０２からのリクエストに認証トークンが存在しない場合は、プリントサーバー１０１は、リクエストを認証サーバー１０４にリダイレクトさせる。

認証サーバー１０４は、Ｗｅｂブラウザ３０２にログイン画面５００を返す。認証サーバー１０４は、Ｗｅｂブラウザ３０２に表示されたログイン画面５００からのログインリクエストに含まれるユーザー名、パスワードと認証サーバー１０４で保持するユーザー名、パスワードとの照合により正当性の検証を行う。検証が成功すると、認証サーバー１０４は、ユーザーに紐づく認証トークンを発行し、このトークンとともにＷｅｂブラウザ３０２に対し、プリントサーバー１０１へのリダイレクトを行うレスポンスを送る。

Ｗｅｂブラウザ３０２は、認証トークンを含めたリクエストをプリントサーバー１０１に送り、プリントサーバー１０１からのレスポンスによりＷｅｂ画面を受信し表示を行う。認証サーバー１０４は、プリンター１０５に配備されるプルプリントアプリケーション３０３がプリントサーバー１０１にアクセスするために必要な認可トークンを発行する。また、認証サーバー１０４は、プルプリントアプリケーション３０３からプリントサーバー１０１にアクセスする場合にリクエストに含まれる認可トークンの正当性検証を行う。

プルプリントアプリケーション３０３は、認可トークンを含めたリクエストをプリントサーバー１０１に送り、ダウンロードＵＲＬを取得する。プルプリントアプリケーション３０３は、ダウンロードＵＲＬに従い、ストレージサーバー１０３から印刷データを取得し、印刷装置制御部３０４に印刷データを送り、印刷を行う。

＜文書サーバーのメッセージ送信＞
文書サーバー１０２のメッセージ送信処理について、図５を用いて説明する。本実施例では、文書サーバー１０２とプリントサーバー１０１は、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用いた情報のやり取りと、名前付き論理チャネルを使用した非同期メッセージを用いた情報のやり取りを行う。

プリントサーバー１０１および文書サーバー１０２は互いのＡＰＩを呼び出すことで、互いに相手が公開する機能を利用することが可能である。ただし、ＡＰＩを呼び出すことで呼び出し先のサーバーの負荷になるため実施例１では後に説明するリカバリ処理を除き極力はＡＰＩを呼び出さない作りとなっている。

文書サーバー１０２は、文書サーバー１０２が有するサービス以外の他サービス用に、名前付き論理チャネルを用意している。以降、名前付き論理チャネルのことをトピックと呼ぶ。実施例１では、文書サーバー１０２がクラウドサービスとして配置される際にトピック５０１も作成されることを想定しているが、文書サーバー１０２が必要に応じて動的に作成してもよい。また、実施例１においてトピックは第三者が提供するクラウドサービスを利用して作成することを想定している。トピックはクラウドサービス上で一意となる名前を持ち、その名前を用いて他サービス（本実施例ではプリントサーバー１０１）が購読の登録を行う。言うなれば、トピックとは仲介サービスであり、プリントサーバー１０１と文書サーバー１０２の非同期通信を実現するために必要な構成である。

トピック５０１に対して文書サーバー１０２が印刷文書情報６２０をメッセージとして送信すると、そのトピック５０１に対して購読の登録を行っているプリントサーバー１０１に対して通知が行われる。プリントサーバー１０１は受信したメッセージの情報をデータベース３０１に保持する。これにより、文書サーバー１０２、プリントサーバー１０１の非同期メッセージの送受信処理が実現できる。すなわち、プリントサーバー１０１と文書サーバー１０２は直接通信を行うのではなく、トピック５０１の機能を介して間接的に通信を行うので、各装置の状況を考慮することなくメッセージのやり取りが可能になる。

＜トピックの通知＞
トピックの通知処理について説明する。実施例１ではソフトウェアコンテナを利用した通知を想定している。ソフトウェアコンテナとは、隔離された空間毎にＯＳ環境（必要なＯＳ機能だけ）がプロセスとして実現される。５０３はソフトウェアコンテナを模式的に示した図である。５０３ように、物理マシン上の仮想マシンのＯＳからソフトウェアコンテナがプロセスとして起動し、あらかじめ登録されたコードを実行する。従来の仮想マシンのようにＯＳ全体を起動するのではなく、ホストＯＳ上でプロセスが起動するだけの処理となるため、非常に高速に起動する特徴がある。ただし、ソフトウェアコンテナを利用する場合、初回にコードをロードするためにコストがかかり、スケールアウトやソフトウェアコンテナ自体の障害等でソフトウェアコンテナの再作成が発生する場合に実行が遅延する可能性がある。

実施例１では、プリントサーバー１０１がトピック５０１の購読登録を行う際、プリントサーバー１０１のソフトウェアコンテナ５０２を登録する。文書サーバー１０２がトピック５０１に対してメッセージを送信すると、トピック５０１からソフトウェアコンテナ５０２が呼び出される。ソフトウェアコンテナ５０２は呼び出されると、所定のコードが実行され、受信したメッセージを確認し、プリントサーバー１０１に対して受信した内容を通知する。なお、トピック５０１はＶＭ上で動作するＯＳの上で動作するソフトウェア機能であるものとする。トピック５０１およびソフトウェアコンテナ５０２は、夫々、文書サーバー１０２およびプリントサーバー１０１とは異なる装置で実現さているものとして実施例１では説明する。しかし、同じ装置内であっても良い。

＜文書サーバーのソフトウェア構成＞
図４ａは、本発明の実施形態に係る文書サーバー１０２のソフトウェア構成図である。なお文書サーバー１０２の各ソフトウェアモジュールは図２ａで示した記憶装置２２４に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。ここでは、文書サーバー１０２が、外部リクエストを受信した際の文書サーバー１０２の各ソフトウェアモジュールの動作について説明する。

文書サーバー１０２は、外部リクエストを受け付けるＷｅｂサーバー４０１と、文書情報の管理を行う文書制御サーバー４０２から構成される。それぞれ独立したプログラムであり、それぞれ別々の情報処理装置に配置することも可能である。これらのプログラムはそれぞれネットワークに繋がった情報処理装置に配置し、それぞれのプログラム間で通信を行う。また、それぞれのサーバーは単体構成または、冗長構成をとるように配備されるので、１つのサーバーに対し複数の情報処理装置で構成されることもある。この構成は後述のプリントサーバー１０１ソフトウェア構成も同様である。

Ｗｅｂサーバー４０１は、他サービス、または他プログラム、またはプリンター１０５または、Ｗｅｂブラウザ３０２から文書入稿リクエストを受ける。各クライアントからリクエスト受付部４０３がリクエスト受けると、認証サーバー問い合わせ部４０４が認証サーバー１０４に対しトークンの正当性検証リクエストを送る。トークンの正当性が確認されると、リクエスト受付部４０３は、文書制御サーバー４０２にクライアントからのリクエストを送る。

文書制御サーバー４０２は、文書データの入稿リクエストを受けると文書管理部４０５で文書情報６００を作成し、データベース３０１に保存する。図６に文書情報６００を含む各情報を示す。また、文書制御サーバー４０２は、メッセージ送信部４０６で文書情報６００を前述のトピック５０１に対して送信する。この時点でプリントサーバー１０１はメッセージ受信部４１７を介してメッセージを受信し、後述する印刷文書情報６２０として保持する。

文書情報６００は、文書データを識別する文書ＩＤ６０１、文書名６０２、認証トークンに紐づくユーザー名６０３とストレージサーバー１０３に文書をアップロードするための文書ＵＲＬ６０４、ステータス６０５から構成される。文書ＵＲＬ６０４には、文書ＩＤ６０１が含まれる。また、ステータス６０５は「受信中」「未印刷」「待機中」「印刷待ち」「印刷中」「正常終了」「エラー終了」「不明終了」の各ステータスがある。

文書制御サーバー４０２は、文書情報６００のステータス６０５を「受信中」に変え、文書ＵＲＬ６０４をＷｅｂサーバー４０１に返す。そしてＷｅｂサーバー４０１がリクエスト元の他サービス、または他プログラムに対し文書ＵＲＬ６０４を返す。他サービス、または他プログラムはストレージサーバー１０３に文書データをアップロード完了すると、文書サーバー１０２にアップロード完了通知を送る。文書サーバー１０２はこの通知をＷｅｂサーバー４０１で受けると文書制御サーバー４０２は、文書情報６００のステータス６０５を「待機中」に変える。

＜プリントサーバーのソフトウェア構成＞
図４ｂは、本発明の実施形態に係るプリントサーバー１０１のソフトウェア構成図である。なおプリントサーバー１０１の各ソフトウェアモジュールは図２ａで示した記憶装置２２４に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。

プリントサーバー１０１は、外部リクエストを受け付けるＷｅｂサーバー４１１と、印刷ジョブ、印刷処理の制御を行う印刷制御サーバー４１２、文書データを印刷データに変換する変換サーバー４１３から構成される。

Ｗｅｂサーバー４１１は、他サービス、または他プログラム、またはプリンター１０５または、Ｗｅｂブラウザ３０２から印刷リクエスト、印刷データ取得リクエストを受ける。クライアントとなる各装置からリクエスト受付部４１４が各リクエストを受けると、認証サーバー問い合わせ部４１５が認証サーバー１０４に対しトークンの正当性検証リクエストを送る。トークンの正当性が確認されると、リクエスト受付部４１４は、印刷制御サーバー４１２にクライアントからのリクエストを送る。

印刷制御サーバー４１２が印刷リクエストを受け取ると、印刷ジョブ管理部４１６は印刷リクエストに対するジョブ情報６１０を作成し、データベース３０１に保存する。印刷リクエストには、印刷を行う文書ＩＤ６１２が含まれる。この文書ＩＤ６１２は、印刷文書情報６２０の文書ＩＤ６２１と同じであり、文書サーバー１０２からメッセージ通知され事前に保持している情報である。印刷文書情報６２０には文書ＵＲＬ６２２と文書入稿を受け付けた受付日時６２３も含まれる。

印刷ジョブ管理部４１６が作成するジョブ情報６１０は、印刷ジョブを識別するジョブＩＤ６１１と、認証トークンに紐づくユーザー名６１３と、印刷の受付日時６１４、変換ステータス６１５から成る。印刷ジョブ管理部４１６は、変換サーバー４１３に対し印刷データへの変換を指示する。

印刷制御サーバー４１２から印刷データ変換指示を受けると変換サーバー４１３の印刷データ管理部４１８は、文書ＵＲＬ６２２に従い、ストレージサーバー１０３から文書データをダウンロードする。そして、データ変換部４１９は、文書データを印刷データに変換し、ストレージサーバー１０３にアップロードする。

＜メッセージ遅延時のリカバリ処理＞
上記説明に加え、文書サーバー１０２からの入稿通知のメッセージが遅延した際のプリントサーバー１０１のリカバリ方法に関してフローチャート図７を用いて説明する。なお、前述の図４で説明しているため、一部の処理については簡単に説明する。

図７（ａ）は、文書サーバー１０２が外部から入稿リクエストを受け付けた際のフローチャートである。Ｓ７０１において、文書サーバー１０２は文書入稿リクエストを外部より受け付けると、文書管理部４０５で文書情報６００を作成し、データベース３０１に保存する。Ｓ７０２において、メッセージ送信部４０６は文書情報６００を前述のトピック５０１に対して送信する。Ｓ７０４において、プリントサーバー１０１のメッセージ受信部４１７は文書サーバー１０２からの文書情報６００を受信する。Ｓ７０５において、印刷ジョブ管理部４１６は文書情報６００をもとに印刷文書情報６２０を作成し、データベース３０１に保存する。ここで印刷文書情報６２０は、文書情報６００そのものではなく、プリントサーバー１０１が印刷処理を行うために必要な情報のみを文書情報６００から取得し保持する。

Ｓ７０３において、文書サーバー１０２は外部から文書のアップロード通知を受信するまで待機し、受信した時点で文書入稿処理を完了する。なお、フローチャートには全て図示していないが、実施例１において、文書情報６００のステータス６０５が変更するたびにメッセージ送信部４０６によりトピックに対して文書情報６００が送信される。

図７（ｂ）はプリントサーバー１０１が外部から印刷リクエストを受け付けた際のフローチャートである。Ｓ７０６において、印刷制御サーバー４１２が印刷リクエストを受け取ると、印刷ジョブ管理部４１６は印刷リクエストに対するジョブ情報６１０を作成し、データベース３０１に保存する。

Ｓ７０７において印刷ジョブ管理部４１６は、印刷リクエストに含まれる文書ＩＤ６１２が印刷文書情報６２０に存在するか確認する。Ｓ７０８において、印刷ジョブ管理部４１６は、印刷文書情報６２０に文書ＩＤ６１２が存在した場合はＳ７１０の処理を行う。存在しない場合はＳ７０９の処理を行う。なお、印刷文書情報６２０の文書ＩＤ６１２を参照する形態を説明したが、受信した文書情報６００を保存しているならばそれを参照しても良い。いずれにせよ、ここでの判定とは、印刷リクエストで指定された文書ＩＤ６１２を含む文書情報６００を取得したことがあるか否かの判定となる。

Ｓ７０９において、印刷ジョブ管理部４１６は、文書サーバー１０２のＡＰＩを呼び出し、文書ＩＤ６１２に対応する文書情報６００を取得し、印刷文書情報６２０として保持する。Ｓ７１０において、印刷ジョブ管理部４１６は、印刷文書情報６２０を用いて変換サーバー４１３に対して印刷データへの変換への指示を行う。

以上の処理により、他サービスから文書入稿の非同期メッセージ通知が遅延した場合でも、受信側で遅延していることを判断し、その場合にのみ文書情報を取得することができる。これにより呼び出し非同期通信で遅延が発生した場合でも他サービスのＡＰＩ呼び出しを極力抑え、印刷処理を継続することが可能となる。

［実施例２］
＜メッセージ遅延時のリカバリ処理（文書ＩＤ指定が無い場合）＞
実施例１では文書サーバー１０２からの入稿通知のメッセージが遅延した際のプリントサーバー１０１の処理に関して説明した。実施例１の方法は、印刷リクエストに文書ＩＤ６１２が指定されていた場合には通知が遅延していることを検知しリカバリ可能であるが、文書ＩＤ６１２が指定されていない場合にはリカバリできない。

想定されるユースケースは、プリンター１０５でＩＣカードを用いてプルプリントする際、ユーザーが文書を指定せずに、未印刷のものを全て一括で印刷するような場合が考えられる。このような場合は、ユーザーの情報のみで印刷リクエストを処理する必要があるが、プリントサーバー１０１だけでは全ての入稿の通知が届いているか判断することができない。例えば文書サーバー１０２には３文書入稿されていて、プリントサーバー１０１には２文書分しかメッセージ通知がされていない場合は、プリントサーバー１０１は２文書印刷するのみである。そうするとユーザーの所望する印刷結果を得ることができない。

以下、文書ＩＤ６１２が指定されない印刷リクエストでもプリントサーバー１０１でメッセージが遅延していることを検知する方法を説明する。なお、図中の番号および名称は特に断らない限り実施例１と同様である。

＜未印刷リストの送信＞
図８（ａ）は、文書サーバー１０２が外部から入稿リクエストを受け付けた際のフローチャートである。Ｓ７０１～Ｓ７０４は実施例１と同様であるため、説明は省略する。Ｓ８０１において、文書管理部４０５は文書情報６００のユーザー名６０３をもとに未印刷文書リストを作成する。すでに存在する場合は対象の文書ＩＤ６１２をリストに追加する。特に図示はしないが、未印刷文書リストは文書ＩＤ６１２の情報だけで構成されるリストである。Ｓ８０２において、メッセージ送信部４０６は未印刷文書リストを前述のトピックに対して送信する。Ｓ８０３において、プリントサーバー１０１のメッセージ受信部４１７は受信した未印刷リストをデータベース３０１に保存する。

図８（ｂ）はプリントサーバー１０１が印刷リスエストを受け付けた際に文書ＩＤ６１２が指定されていなかった場合の処理を示すフローチャートである。Ｓ７０６～Ｓ７１０の処理は実施例１と同様であるため説明は省略する。

Ｓ８０４において、印刷ジョブ管理部４１６は印刷リスエストに文書ＩＤ６１２が指定されているかどうかを確認する。Ｓ８０４において、印刷リクエストに文書ＩＤ６１２が指定されていた場合はＳ７０７の処理を行い、文書ＩＤ６１２が指定されていなかった場合はＳ８０５の処理を行う。

Ｓ８０５において、印刷ジョブ管理部４１６は印刷リクエストしたユーザー名６１３をもとに未印刷文書リストを特定する。Ｓ８０６において、印刷ジョブ管理部４１６は、未印刷文書リストに記載されている全ての文書ＩＤ６１２に対し、文書ＩＤ６１２で特定される印刷文書情報６２０が存在するか確認する。比較の結果、未印刷文書リストには文書ＩＤ６１２が記載されているが印刷文書情報６２０が存在しない場合、Ｓ７０８にて文書情報がないと判断されることになり、Ｓ７０９の処理が実行される。以下、実施例１と同じである。

以上の処理により、印刷対象の文書を特定できない場合でも、非同期メッセージの遅延が発生しているかどうか検知することが可能となり、ユーザーが所望する印刷物を出力することが可能となる。

［実施例３］
実施例２では文書ＩＤ６１２が指定されない印刷リクエストでもプリントサーバー１０１でメッセージが遅延していることを検知する方法を説明した。しかしながら、実施例２における未印刷文書リストも非同期メッセージであるため、ネットワークなどの状況により遅延することが想定される。以下、未印刷文書リストが遅延した場合でも通知が遅延していることを検知する方法を説明する。なお、図中の番号および名称は特に断らない限り実施例１および２と同様である。

＜メッセージ遅延時のリカバリ処理（未印刷文書リストの遅延）＞
図９は、プリントサーバー１０１が外部から印刷リクエストを受け付けた際に未印刷文書リストが遅延する可能性を考慮した場合の処理を示すフローチャートである。Ｓ７０６～Ｓ７１０および、Ｓ８０４～Ｓ８０６の処理は実施例１、実施例２と同様であるため説明は省略する。

Ｓ９０１において、印刷ジョブ管理部４１６は印刷リクエストしたユーザーの未印刷リストが存在するかどうか確認する。Ｓ９０１で未印刷文書リストが存在しない場合はＳ９０２において、印刷ジョブ管理部４１６は文書サーバー１０２のＡＰＩを呼び出し、未印刷文書リストの取得を行う。

Ｓ９０１において未印刷文書リストが存在した場合は、実施例２のＳ８０５と同様に印刷ジョブ管理部４１６は印刷リクエストしたユーザー名６１３をもとに未印刷文書リストを特定する。Ｓ９０４において、印刷ジョブ管理部４１６は、メッセージ受信部４１７に対し、新しいメッセージが来ているかどうか確認を行う。Ｓ９０５において、印刷ジョブ管理部４１６は、新規文書通知、すなわち新しい文書情報があった場合はＳ９０６の処理を行う。

Ｓ９０６において、印刷ジョブ管理部４１６は、印刷の受付日時６１４と、新規文書通知で受け付けた文書情報の受付日時でもある印刷文書情報６２０の受付日時６２３との比較を行う。しかし、文書情報の受付日時であっても良いし、印刷文書情報６２０の受付日時６２３は実質文書情報を受け付けた受付日時とも言える。Ｓ９０７において、印刷ジョブ管理部４１６は印刷の受付日時６１４より受付日時６２３が遅ければ、印刷リクエストよりも後に受信した文書であると判断する。

印刷の受付日時６１４より受付日時６２３が早ければ、印刷リクエストよりも先に入稿された文書であると判断し、未印刷文書リストの通知が遅れている可能性があるため最新の未印刷文書リストを文書サーバー１０２より取得する。

以上の処理により、ユーザー毎の未印刷リストの非同期メッセージが遅延した場合でも、遅延していることを検知し、ユーザーが印刷リクエストしたタイミングの印刷結果を出力することが可能となる。

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

１０１ プリントサーバー
１０２ 文書サーバー
４０５ 文書管理部
４０６ メッセージ送信部
４１６ 印刷ジョブ管理部
４１７ メッセージ受信部
６００ 文書情報
６１０ ジョブ情報
６２０ 印刷文書情報

Claims (10)

1. 文書情報を基に文書データを取得し、前記文書データを基に印刷データを作成し、前記印刷データをプリンターへ送信するプリントサーバーであって、
   入稿リクエストを受け付けたことで文書サーバーが生成した文書情報を、前記文書サーバーのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を読み出すことなく、仲介サービスを介することで間接的に取得する第１の取得手段と、
   クライアントから印刷リクエストを受信し、前記印刷リクエストから文書ＩＤを特定し、前記文書ＩＤを含む前記文書情報を前記第１の取得手段によって取得しているか否かを判定する判定手段と、
   前記判定手段により取得していないと判定された場合に、前記文書サーバーが提供する前記ＡＰＩを呼び出して前記文書サーバーから前記文書ＩＤに対応する前記文書情報を取得する第２の取得手段と、を有し、
   前記判定手段により取得していると判定された場合は、前記第２の取得手段により前記文書情報の取得は行われないことを特徴とするプリントサーバー。
2. 前記プリントサーバーは、前記仲介サービスに対しソフトウェアコンテナを購読登録し、前記仲介サービスから呼び出された前記ソフトウェアコンテナから前記文書情報を取得することを特徴とする請求項１に記載のプリントサーバー。
3. 前記ソフトウェアコンテナは、物理マシン上の仮想マシンのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上で起動するプロセスであることを特徴とする請求項２に記載のプリントサーバー。
4. 前記判定手段による判定とは、取得した前記文書情報を基に作成した印刷文書情報に前記文書ＩＤが含まれているか否かの確認であることを特徴とする請求項１乃至３の何れか１項に記載のプリントサーバー。
5. 前記文書情報の他に未印刷リストを前記仲介サービスを介して非同期で受信し、
   前記第２の取得手段は、前記判定手段により前記未印刷リストに記載された文書ＩＤに対応する前記文書情報を取得していないと判定されたことに応じて、前記文書サーバーが提供する前記ＡＰＩを呼び出して、前記未印刷リストに記載された文書ＩＤに対応する文書情報であり、取得できていない前記文書情報を取得することを特徴とする請求項１乃至４の何れか１項に記載のプリントサーバー。
6. 前記プリントサーバーは、前記クライアントから文書ＩＤを含まない印刷リクエストを受信した場合に前記未印刷リストを取得することを特徴とする請求項５に記載のプリントサーバー。
7. 前記第２の取得手段は、前記判定手段により前記未印刷リストを取得していないと判定されたことに応じて、前記文書サーバーへ問い合わせを行い取得できていない前記未印刷リストを取得することを特徴とする請求項５または６に記載のプリントサーバー。
8. 前記印刷リクエストの受付日時と新しく取得した文書情報の受付日時を比較する比較手段を有し、
   前記第２の取得手段は、前記印刷リクエストの受付日時より、新しく取得した文書情報の受付日時が早い場合、前記文書サーバーへ問い合わせを行い最新の前記未印刷リストを取得することを特徴とする請求項７に記載のプリントサーバー。
9. 文書情報を基に文書データを取得し、前記文書データを基に印刷データを作成し、前記印刷データをプリンターへ送信するプリントサーバーの制御方法であって、
   入稿リクエストを受け付けたことで文書サーバーが生成した文書情報を、前記文書サーバーのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を読み出すことなく、中継サービスを介することで間接的に取得する第１の取得ステップと、
   クライアントから印刷リクエストを受信し、前記印刷リクエストから文書ＩＤを特定し、前記文書ＩＤを含む前記文書情報を取得しているか否かを判定する判定ステップと、
   前記判定ステップにおいて取得していないと判定された場合に、前記文書サーバーが提供する前記ＡＰＩを呼び出して前記文書サーバーから前記文書情報を取得する第２の取得ステップと、を含み、
   前記判定ステップにより取得していると判定された場合は、前記第２の取得ステップによる前記文書情報の取得は行われないことを特徴とする制御方法。
10. 文書情報を基に文書データを取得し、前記文書データを基に印刷データを作成し、前記印刷データをプリンターへ送信するプリントサーバーで実行されるプログラムであって、
    入稿リクエストを受け付けたことで文書サーバーが生成した文書情報を、前記文書サーバーのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を読み出すことなく、中継サービスを介することで間接的に取得する第１の取得ステップと、
    クライアントから印刷リクエストを受信し、前記印刷リクエストから文書ＩＤを特定し、前記文書ＩＤを含む前記文書情報を取得しているか否かを判定する判定ステップと、
    前記判定ステップにおいて取得していないと判定された場合に、前記文書サーバーが提供する前記ＡＰＩを呼び出して前記文書サーバーから前記文書情報を取得する第２の取得ステップと、を含み、
    前記判定ステップにより取得していると判定された場合、前記第２の取得ステップによる前記文書情報の取得は行われないことを特徴とするプログラム。

Images