(57)【要約】      （修正有）【課題】ログを一元的に管理するシステムにおいて、ログの管理装置が処理継続不能状態になった場合でも、ログの記録漏れが発生することを防止する。【解決手段】フロントエンド処理部３１１が、画像形成装置１０４からの処理依頼を受信し、第１のキューに前記処理依頼に対応する第１のキューメッセージを格納し、バックエンド処理部３１２が、前記第１のキューメッセージを削除することなく取得し、第２のキューに未完ログの生成の指示に対応する第２のキューメッセージを格納し、ログ管理部３１３が、前記未完ログを生成し、生成した未完ログを保存手段に保存させ、前記バックエンド処理手段により前記処理依頼が完了したことに応じて、前記未完ログをログとして確定された完了ログとして書き換え、前記バックエンド処理部が、前記第１のキューに格納されている前記第１のキューメッセージを削除する。【選択図】図３
2012181759.tif 000002
【特許請求の範囲】
【請求項１】
画像形成装置からの処理依頼を受信し、第１のキューに前記処理依頼に対応する第１のキューメッセージを格納するフロントエンド処理手段と、
画像形成装置からの処理依頼に基づき処理を実行し、かつ前記フロントエンド処理手段により第１のキューに格納された第１のキューメッセージを削除することなく取得し、取得したことに応じて第２のキューに未完ログの生成の指示に対応する第２のキューメッセージを格納するバックエンド処理手段と、
前記バックエンド処理手段により格納された第２のキューメッセージであって、前記第２のキューに格納された第２のキューメッセージを取得したことに応じて前記未完ログを生成し、生成した未完ログを保存手段に保存させ、前記バックエンド処理手段により処理されたことに応じて、未完ログをログとして確定された完了ログとして書き換えるログ管理手段と、を有し、
前記バックエンド処理手段は、前記未完ログが完了ログとして書き換えられたことに応じて前記第１のキューに格納されている前記第１のキューメッセージを削除することを特徴とするサーバシステム。
【請求項２】
前記バックエンド処理手段がシャットダウンされ、前記バックエンド処理手段とは別のバックエンド処理手段が起動され、
前記別のバックエンド処理手段は、前記第１のキューメッセージを取得したことで前記第２のキューに第２のキューメッセージを格納する前に、前記保存手段により前記処理依頼に対応するログが保存されているか否かを確認し、該ログが保存されていない場合は、前記第２のキューに前記第２のキューメッセージを格納し、該ログが未完ログとして保存されている場合は、前記処理依頼に基づく処理を実行し、該ログが完了ログとして保存されている場合は、前記第１のキューに格納されている前記第１のキューメッセージを削除することを特徴とする請求項１に記載のサーバシステム。
【請求項３】
前記バックエンド処理手段は仮想マシンがバックエンド処理プログラムを実行することで実現され、前記ログ管理手段は仮想マシンがログ管理プログラムを実行することで実現され、前記フロントエンド処理手段は仮想マシンがフロントエンド処理プログラムを実行することで実現され、かつ前記バックエンド処理手段、前記ログ管理手段、および前記フロントエンド処理手段は、前記キューを介して処理依頼を行うことで夫々が独立して処理を実行することを特徴とする請求項１または２に記載のサーバシステム。
【請求項４】
前記処理依頼とは、データを印刷データへと変換するための依頼であって、
前記フロントエンド処理手段は、前記画像形成装置から前記処理の結果の取得を要求されたことに応じて前記保存手段により保存されているログを確認し、確認の結果、前記ログが未完ログであった場合は前記印刷データが印刷可能なリストに含まれないように、前記ログが完了ログであった場合は前記印刷データを印刷可能なリストに含まれるようリストを生成し、生成したリストを前記画像形成装置へ送信することを特徴とする請求項１乃至３のいずれか１項に記載のサーバシステム。
【請求項５】
フロントエンド処理手段は、画像形成装置からの処理依頼を受信し、第１のキューに前記処理依頼に対応する第１のキューメッセージを格納し、
バックエンド処理手段は、画像形成装置からの処理依頼に基づき処理を実行し、かつ前記フロントエンド処理手段により第１のキューに格納された第１のキューメッセージを削除することなく取得し、取得したことに応じて第２のキューに未完ログの生成の指示に対応する第２のキューメッセージを格納し、
ログ管理手段は、前記バックエンド処理手段により格納された第２のキューメッセージであって、前記第２のキューに格納された第２のキューメッセージを取得したことに応じて前記未完ログを生成し、生成した未完ログを保存手段に保存させ、前記バックエンド処理手段により処理されたことに応じて、未完ログをログとして確定された完了ログとして書き換え、
更に、前記バックエンド処理手段は、前記未完ログが完了ログとして書き換えられたことに応じて前記第１のキューに格納されている前記第１のキューメッセージを削除することを特徴とするサーバシステムを制御する制御方法。
【請求項６】
請求項５に記載の制御方法をサーバシステムで実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
アプリケーションから提供されるログを管理するサーバシステム、その制御方法、およびそのプログラムに関するものである。
【背景技術】
【０００２】
近年、クラウドコンピューティングシステムと呼ばれる技術が注目を集めている。クラウドコンピューティングシステムにおいて、クラウドサービスベンダーは、インターネット上に、仮想的なサーバ（ＶＭ：Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）やストレージ、また種々のサービスを提供する。アプリケーション開発者は、クラウドサービスベンダーに利用料を支払い、それらのサービスを使用することで、クラウドアプリケーションの開発が可能となる。
【０００３】
一方、従来からログの管理方法について考えられてきた。特許文献１では、ジョブの完了時やジョブのキャンセル時のログを、ログ管理端末に送信し、ログ管理端末がまとめて、記録装置に記録する。ログを一元的に管理することで、ログの利用が容易となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１６６４０８
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、クラウドコンピューティングシステムにおける、ログの管理方法について考える。前述したように、クラウドコンピューティンググシステムでは、ＶＭ上で種々のサービスが提供されている。各ＶＭ上で行われたサービスのログを利用するとした場合、各ＶＭ上に分散したログを、一元的に管理することが、ログの利用を容易にするためには必要である。
【０００６】
しかしながら、特許文献１のように、ログを管理端末に送信しその管理端末がログを記録装置に記録するような場合、管理端末、またはログを提供したモジュールが不慮の要因により停止した場合、ログの記載漏れ、またはログの２重記録が発生する。特にクラウドコンピューティングシステムでは、任意のタイミングで、各ＶＭが処理の継続が不可能になることを前提として設計を行う必要がある。これは、一般的にクラウドコンピューティングシステムが多数のＶＭから構成されていることが多いため、いずれかのＶＭが処理継続不可能な状態になる可能性が高くなるからである。
【０００７】
そこで、本発明では、任意のタイミングでＶＭが処理継続不可能な状態になった場合においても、ログを記録する方法を提案する。
【課題を解決するための手段】
【０００８】
本発明の一実施系に係るサーバシステムは、画像形成装置からの処理依頼を受信し、第１のキューに前記処理依頼に対応する第１のキューメッセージを格納するフロントエンド処理手段と、
画像形成装置からの処理依頼に基づき処理を実行し、かつ前記フロントエンド処理手段により第１のキューに格納された第１のキューメッセージを削除することなく取得し、取得したことに応じて第２のキューに前記未完ログの生成の指示に対応する第２のキューメッセージを格納するバックエンド処理手段と、前記バックエンド処理手段により格納された第２のキューメッセージであって、前記第２のキューに格納された第２のキューメッセージを取得したことに応じて前記未完ログを生成し、生成した未完ログを保存手段に保存させ、前記バックエンド処理手段により処理されたことに応じて、未完ログをログとして確定された完了ログとして書き換えるログ管理手段と、を有し、前記バックエンド処理手段は、前記未完ログが完了ログとして書き換えられたことに応じて前記第１のキューに格納されている前記第１のキューメッセージを削除することを特徴とする。
【発明の効果】
【０００９】
本願発明の未完ログの生成処理、完了ログへの書き換え処理、およびキューメッセージの削除処理により、ログの記録漏れ、または２重記録を防ぐことが出来る。
【図面の簡単な説明】
【００１０】
【図１】本発明におけるシステム構成図
【図２】（ａ）アプリケーションサーバ（１０１）のハードウェア構成図、  （ｂ）画像形成装置（１０４）のハードウェア構成図
【図３】機能ブロック図
【図４】（ａ）本発明におけるジョブキュー（６０１）に格納されるメッセージ  （ｂ）本発明におけるログキュー（６０２）に格納されるメッセージ
【図５】（ａ）本発明におけるログテーブルに格納されるデータのパターン１  （ｂ）本発明におけるログテーブルに格納されるデータのパターン２
【図６】（ａ）キャンセルを含んだフローにおけるログテーブルに格納されるログテーブルに格納されるデータのパターン１  （ｂ）キャンセルを含んだフローにおけるログテーブルに格納されるログテーブルに格納されるデータのパターン２  （ｃ）キャンセルを含んだフローにおけるログテーブルに格納されるログテーブルに格納されるデータのパターン３
【図７】ＰＣ（１０３）とフロントエンド処理部（３１１）のフローチャート
【図８】画像形成装置（１０２）とフロントエンド処理部（３１１）のフローチャート
【図９】バックエンド処理部（３１２）のフローチャート
【図１０】ログ管理部（３１３）のフローチャート
【図１１】キャンセルを含んだフローにおけるＰＣ（１０３）とフロントエンド処理部（３１１）のフローチャート
【図１２】キャンセルを含んだフローにおけるバックエンド処理部（３１２）のフローチャート
【図１３】キャンセルを含んだフローにおけるログ管理部（３１３）のフローチャート
【発明を実施するための形態】
【００１１】
クラウドコンピューティングシステムでは、任意のタイミングで、ＶＭの処理の継続が不可能になることを前提として設計を行う必要がある。これは、一般的にクラウドコンピューティングシステムが多数のＶＭから構成されていることが多いため、いずれかのＶＭが処理継続不可能な状態になる可能性が高くなるからである。
【００１２】
また、特定のクラウドコンピューティングシステムにおいてシステム全体のパフォーマンスを調整するために、ＶＭを削減するような（スケールイン）場合がある。この場合、削減するＶＭを指定することが出来ないため、何らかの処理をしているＶＭを削減する可能性がある。そのため、スケールインを行う場合にも、任意のタイミングでＶＭが処理継続不可能な場合に陥る。ログは、第３者による監査や、ユーザに対して使用量を請求するために使用されることが多い。そのため、ログの記録漏れや、２重記録が発生することはユーザに適正なサービスを提供することができなくなるため好ましくない。
【００１３】
そこで、本発明では、任意のタイミングでＶＭが処理継続不可能な状態になった場合においても、ログを記録する方法を提案する。またログを記録できていない場合には、ログを記録するまで処理を継続させない方法も提案する。
【００１４】
以下に、本発明の好ましい実施の形態を、添付の図面に基づいて詳細に説明する。始めに、本発明の各実施例で使用される用語の定義について説明する。ポーリングとは、クライアントがホストに要求をした処理の経過や完了を確認するために、クライアントが一定間隔でホストに処理の経過状況を問い合わせる処理のことである。
【実施例１】
【００１５】
［システム構成］
図１は、本発明の第１の実施形態に係るシステムの全体構成を示している。ネットワーク（１００）上にあるアプリケーションサーバ群（１０１）上に実装されたサービスと、種々のデータを保存しておくためのストレージサーバ（１０２）、および、イントラネット内にある、ＰＣ（１０３）や画像形成装置（１０４）から構成される。ネットワーク１００は、上述の各装置間での情報をやりとりのための通信回線として働き、有線、無線と回線の形態は問わない。
【００１６】
［サーバシステムのハードウェア構成］
アプリケーションサーバ群１０１に含まれるアプリケーションサーバはＣＰＵ２１１、直接記憶部２１２、ネットワークインターフェース２１３をもつ。ＣＰＵ２１１は所定のプログラムを実行し、アプリケーションサーバの各種制御を指示するユニットである。ＣＰＵ２１１は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）により実現される。直接記憶部２１２は、ＣＰＵ２０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２１１が実行するプログラムは直接記憶部２１２にロードされる。直接記憶部２１２は、ＲＡＭ（Ｒａｎｄａｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）により実現される。間接記憶部２１３は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。間接記憶部２１３に記憶されている各種プログラムは、ＣＰＵ２１１がプログラムを実行する際に直接記憶部２１２へ移動する。間接記憶部２１３は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ）、または、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ２１１はマルチプロセッサでも良い。ネットワークインターフェース２１３は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。ストレージサーバ１０２、ＰＣ１０３も同様のハードウェア構成をしているため、説明は割愛する。
【００１７】
［画像形成装置のハードウェア構成］
ＣＰＵ２１２は、所定のプログラムを実行し、画像処理ユニット２１１の各種制御を指示するユニットである。ＣＰＵ２１２は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）により実現される。直接記憶部２１３は、ＣＰＵ３０２がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２１２が実行するプログラムは直接記憶部２１３にロードされる。直接記憶部２１３は、ＲＡＭ（Ｒａｎｄａｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）により実現される。間接記憶部２１４は、アプリケーションプログラムを含む各種プログラムが記憶されている。間接記憶部２１４に記憶されている各種プログラムは、ＣＰＵ３０２がプログラムを実行する際に直接記憶部２１３へ移動する。間接記憶部２１４は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、または、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ２１２はマルチプロセッサでも良い。
【００１８】
［ソフトウェア構成］
図３は、本発明の第１の実施形態に関わるシステムを構成するバックエンド処理部３１２、フロントエンド処理部３１１、ログ管理部３１３、ＰＣ１０３、ストレージ３２１、キューサービス３２２、テーブル３２３、および、画像形成装置１０４の機能ブロック図を示している。ここで、バックエンド処理部３１２、フロントエンド処理部３１１、ログ管理部３１３は、前述したアプリケーションサーバ１０１に実装されたプログラムによって動作するものである。また、ストレージ３２１、キューサービス３２２、テーブル３２３は、前述したストレージサーバ１０２上に実装されたプログラムによって動作するものである。
【００１９】
まず、ＰＣ１０３についての説明を行う。ＰＣ１０３は、ネットワーク通信部３３１、ユーザインターフェース３３２、ウェブブラウザ３３３から構成される。ユーザインターフェース３３２は、ユーザが、ＰＣ１０３によって提供される各種アプリケーションを使用するためのインタフェースである。これを介して入力されるユーザ操作に従って、各種アプリケーションを実行する。アプリの１つであるウェブブラウザ３３３は、ネットワーク１００を介して、ネットワーク通信部３３１から送信および受信される情報に応じて、各種情報の表示を行う。ウェブブラウザ３３３は、図２（ａ）の間接記憶部２０３に保存されているプログラムが、直接記憶部２０２にロードされ、ＣＰＵ２０１により実行されることで実現される。第１の実施形態では、ＰＣ１０３を操作するユーザが、ユーザインターフェース３３２、ネットワーク通信部３３１を通してフロントエンド処理部３１１と通信を行い、データの送受信を行なう。
【００２０】
次に、アプリケーションサーバ１０１上に実装されるフロントエンド処理部３１１、バックエンド処理部３１２、ログ管理部３１３の説明を行う。フロントエンド処理部３１１は、ＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）、即ち仮想マシンがフロントエンド処理プログラムを実行することで実現される。バックエンド処理部３１２は、ＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）、即ち仮想マシンがバックエンド処理プログラムを実行することで実現される。ログ管理部３１３は、仮想マシンがログ管理プログラムを実行することで実現される。
【００２１】
仮想マシンは、仮想化技術によって物理的なサーバーコンピュータ群を論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータのことである。この論理的なコンピュータの単位は、インスタンスとして数えられる。本発明の実施例１では、インスタンス数１つに対し、サーバーコンピュータ群内の１台のサーバーコンピュータ上で動作する。
【００２２】
フロントエンド処理部３１１は、画像形成装置、または、ＰＣからのリクエストを受信し、各要求に応じた処理を行う。フロントエンド処理部３１１は、一般的なＷｅｂサーバと同等の機能を持ち、同期処理を行うことが可能である。フロントエンド処理部３１１は、後述のキューサービス３２２を介してバックエンド処理部３１２に対して処理内容を伝える役割を持つ。また、フロントエンド処理部３１１は、キューサービスへのメッセージの格納の他、ストレージ３２１やテーブル３２３にデータを格納することも可能である。
【００２３】
バックエンド処理部３１２は、フロントエンド処理部３１１からキューサービス３２２を介して伝えられた処理依頼に対する処理を行う機能を持つ。このキューサービスは第１のキューであり、第１のキューに格納されるキューメッセージは第１のキューメッセージである。バックエンド処理部は、キューサービス３２２に格納されたメッセージを取得し、メッセージに記載されている処理を行う。キューサービス３２２を用いることで、バックエンド処理部は非同期で処理を行うことが出来る。バックエンド処理部３１２は、バックエンド処理部３１２を実行しているサーバのメモリに処理プログラムをロードし処理を行う。バックエンド処理部は、キューサービス３２２からメッセージを取得するのみではなく、キューサービスにメッセージを格納することも可能である。また、ストレージ３２１、テーブル３２３からのデータの取得や、ストレージ３２１、テーブル３２３へのデータの格納も可能である。
【００２４】
ログ管理部３１３は、バックエンド処理部３１２からキューサービスを介して伝えられたメッセージに応じて処理を行う。このキューサービスは第２のキューであり、第２のキューに格納されるキューメッセージは第２のキューメッセージである。ログ管理部３１３は、バックエンド処理部３１２と同様に、非同期で処理を行うことが出来る。ログ管理部３１３は、ログ管理部３１３を実行しているサーバのメモリに処理プログラムをロードし処理を行う。ログ管理部３１３は、ストレージ３２１からのデータの取得、テーブル３２３からのデータの取得、および、テーブル３２３へのデータの格納が可能である。
【００２５】
ストレージサーバ１０２上に実装される、ストレージ３２１、キューサービス３２２、テーブル３２３の説明を行う。ストレージ３２１はバックエンド処理部３１２により処理された実行結果のデータを始めとする各種データを保存しておく機能を持つ。ストレージ３２１は図２（ａ）の間接記憶部２０３によって実現される。ストレージ３２１には、データを保存しておくだけではなく、そのデータにタグのように付加情報を付与することが可能である。
【００２６】
キューサービス３２２は、フロントエンド処理部３１１とバックエンド処理部３１２、または、バックエンド処理部３１２とログ管理部３１３とが非同期でデータ通信するための機能を持つ。なお、キューサービス３２２は、図２（ａ）の間接記憶部２０３に保存されているキュープログラムが、直接記憶部２０２にロードされて、ＣＰＵ２０１により実行されることで実現される。テーブル３２３は、処理の状態等の情報を保持するためのストレージを提供するサービスであり、一般的に公知のデータベースサービスが持つ機能と同じ機能を持つ。
【００２７】
最後に、画像形成装置１０４についての説明を行う。画像形成装置１０４は、印刷処理部３４１、印刷要求送信部３４２、ユーザインターフェース３４３、ウェブブラウザ３４４から構成される。印刷処理部３４１は、印刷データの印刷処理を行う。印刷要求送信部３４２は、ユーザインターフェース３４３によって指定された印刷設定等を、フロントエンド処理部３１１に送信し、その応答を受信するプログラムである。ユーザインターフェース３４３は、ユーザが印刷装置１０４によって提供される各種アプリケーションを使用するためのインタフェースである。これを介して入力されるユーザ操作に従って、各種アプリケーションを実行する。ウェブブラウザ３４４は、ネットワーク１００を介して接続されているデバイス内に保存されているデータや情報をユーザが閲覧することができる機能を持つ。ウェブブラウザ３４４は、図２（ｂ）の間接記憶部２１４に保存されているプログラムが、直接記憶部２１３にロードされ、ＣＰＵ２１２により実行されることで実現される。また、ユーザは、ウェブブラウザ３４４を用いてネットワーク上に存在する、ドキュメントや画像といった種々のコンテンツを閲覧し、ユーザインターフェース３４３を用いて選択、印刷指示を行うことが出来る。
【００２８】
［キューサービス］
まず、本発明が想定しているキューサービスが持つ機能について説明する。キューサービスは、フロントエンド処理部３１１、バックエンド処理部３１２と、ログ管理部３１３とが非同期でデータ通信するためのサービスを提供する。キューサービスに対し各種指示を出すことで、非同期でデータ通信する。これについて、具体的に説明する。キューサービスに対して行う指示とは、メッセージの追加指示、およびメッセージの取得指示、メッセージの削除処理である。メッセージとは、キューメッセージを指す。まず、非同期でデータ通信する一連の動作について説明する。処理を移譲したい処理部（フロントエンド処理部３１１、または、バックエンド処理部３１２）は、処理依頼に応じたメッセージを作成し、メッセージをキューサービスに追加するようにキューサービスに追加指示を送信する。追加指示を受信したキューサービスは、キューにメッセージを追加する。
処理を行う処理部（バックエンド処理部または、ログ管理部）は、メッセージを取得するために、キューサービスに取得指示を出す。取得指示を受けたキューサービスは、メッセージと、メッセージ毎に固有に割り振られたメッセージＩＤと、受取ＩＤとを取得指示に対するレスポンスとして処理部（バックエンド処理部または、ログ管理部）に返す。メッセージＩＤとは、メッセージを一意に定めるためにメッセージごとに割り振られた固有の情報である。受取ＩＤは、処理が終了した処理部がメッセージを削除指示する際に使用する。メッセージと、メッセージＩＤと、受取ＩＤは、関連付けされて保存されることになる。処理部は、処理依頼を完了すると、受取ＩＤに対応するメッセージの削除指示をキューサービスに対して行う。削除指示を受けたキューサービスは、処理部（バックエンド処理部または、ログ管理部）が指示した受取ＩＤに対応するメッセージをキューから削除する。これにより、削除指示を出した処理部（バックエンド処理部または、ログ管理部）以外のバックエンド処理部が同じメッセージを処理するという冗長な処理を防ぐことができる。
【００２９】
次に、ジョブキュー６０１と、ログキュー６０２の機能について説明する。ジョブキュー６０１と、ログキュー６０２は、キューサービス３２２である。ジョブキュー６０１は、ＰＣ１０３や、画像形成装置１０４からフロントエンドアプリケーション５０１に依頼された処理の内容を、バックエンド処理部３１２に移譲するために用いられる。この際、ジョブキューには、バックエンド処理部３１２が処理を行うに必要な情報が格納される必要がある。図４（ａ）に本実施例におけるジョブキュー６０１のメッセージ例を示す。図４（ａ）では、バックエンド処理部３１２が行う処理としてＦｏｒｍ合成を挙げた。しかしながら、バックエンド処理部３１２が行う処理に制限はなく、例えば、画像解析や、印刷データ変換等の処理をバックエンド処理部３１２に行わせることも可能である。
【００３０】
また、図４（ａ）では、メッセージに含まれる情報として、ＪｏｂＩｄとＪｏｂ、ＵｓｅｒＩｄ、ＤｏｃｕｍｅｎｔＰａｔｈの４つを挙げた。ＪｏｂＩｄは、バックエンド処理部が行う処理を一意に識別するためのＩＤである。Ｊｏｂは、バックエンド処理部が行う処理内容を一意に識別する情報である。また、ＵｓｅｒＩｄは操作を実施したユーザを一意に識別するためのＩＤである。また、ＤｏｃｕｍｅｎｔＰａｔｈは、印刷を行う対象のドキュメントが保存されているパスを表す。メッセージに格納可能な項目は上記の４つの制限されるものではない。上述したように、バックエンド処理部３１２が処理を行うのに必要な項目をメッセージに追加することが出来る。例えば、ドキュメントが外部ストレージにある場合においては、外部ストレージにアクセスするための、アカウントやパスワードをメッセージとして含めることが出来る。
【００３１】
ログキュー６０２は、バックエンド処理部３１２が、ログ管理部３１３に処理を移譲する際に用いられるキューサービスである。ログキュー６０２には、バックエンド処理部が行う処理の結果、ログとして記録する内容をメッセージとして格納する。図４（ｂ）では、メッセージとして、ＪｏｂＩｄ，Ｊｏｂ、ＵｓｅｒＩｄ，ＤａｔａＳｔｏｒｅＰａｔｈの４つを挙げた。メッセージの内容は上記の４つの制限されるものではない。上記４つの項目以外に、ログとして残す項目が存在する場合には、追加することが出来る。例えば、ログとして、ユーザの会社名を記録する場合には、メッセージに会社名を含める必要がある。
【００３２】
［ログテーブル］
本発明において、テーブル３２３として、ログテーブル（７０１、７０２）が存在する。図５（ａ）（ｂ）を用いて、ログテーブルの詳細について説明する。ログテーブルは、ログを記録するためのテーブルである。図５では、ログとして残す項目としてＪｏｂＩｄ、ＴｉｍｅＳｔａｍｐ、Ｊｏｂ、ＵｓｅｒＩｄ、Ｄｏｃｕｍｅｎｔ、ＤａｔａＳｔｏｒｅＰａｔｈの６つを挙げた。ログテーブルに記録するログの項目は上記６つに制限されるものではない。アプリケーションが、上記６つ以外の項目を新たに追加することが出来る。例えば、前述したように、会社名をログとして残す場合には、会社名を表すカラムをログテーブルに追加することで、対応可能となる。
ログテーブルに対するログ項目の格納の詳細なフローは後述するが、ログ管理部３１３は、ログキュー６０２に格納されているメッセージに従って、ＴｉｍｅＳｔａｍｐ以外の項目を格納する。この時、ＴｉｍｅＳｔａｍｐの値は未定とする（図５（ａ））。その後、バックエンド処理部３１２が処理をストレージに格納したデータに紐づけられたＴｉｍｅＳｔａｍｐを取得し、未定となっているＴｉｍｅＳｔａｍｐの項目を取得したＴｉｍｅＳｔａｍｐの値で更新する（図５（ｂ））。図５（ａ）に示すログは、ログの情報として未だ確定していないことから未完ログと称する。一方、図５（ｂ）に示すログは、ログとしての情報であることが確定しており、ログ情報を所望するユーザに対して十分なものであるため完了ログと称する。ＴｉｍｅＳｔａｍｐはログ情報として確定しているか否かを示す情報であることから本実施例ではフラグと称する。
【００３３】
［フローチャート］
図７、図８、図９、図１０を用いて、本発明におけるＰＣ１０３、フロントエンド処理部３１１、画像形成装置１０２、バックエンド処理部３１２、ログ管理部３１３の処理の流れを詳細に説明する。
【００３４】
［ＰＣ１０３とフロントエンド処理部３１１の処理の流れ］
まず、図７を用いて、ＰＣ１０３とフロントエンド処理部３１１の処理の流れについて説明する。Ｓ１１０１では、ＰＣ１０３は、フロントエンド処理部に対して印刷要求を行う。フロントエンド処理部３１１は、ＰＣ１０３に対して印刷可能なドキュメントの一覧を送信し、ＰＣ１０３はその中から印刷対象のデータを選択することで印刷要求を行う。Ｓ１１０２では、フロントエンド処理部３１１は、ＰＣ１０３から送信された印刷要求を受信する。Ｓ１１０３では、フロントエンド処理部３１１は、ジョブキューに図５（ａ）で示したようなメッセージを格納する。
【００３５】
［画像形成装置１０２とフロントエンド処理部３１１の処理の流れ］
次に、図８を用いて、画像形成装置１０２とフロントエンド処理部３１１の処理の流れについて説明する。Ｓ１２０１では、画像形成装置１０２は、フロントエンド処理部３１１に対して印刷可能なデータ一覧の取得要求を送信する。この時、データ一覧として取得するデータのユーザＩＤも同時に送信する。ユーザＩＤの入力方法に関しては特に制限はない。例えば、画像形成装置にカード認証や、タッチパネル等の認証機能を加え、そのユーザＩＤを送信する方法がある。
Ｓ１２０２では、フロントエンド処理部３１１は、画像形成装置１０２から送信された取得要求を受信する。Ｓ１２０３では、フロントエンド処理部３１１は、受信したユーザＩＤを持つエンティティの一覧をログテーブルから取得する。Ｓ１２０４では、フロントエンド処理部３１１は、取得した一覧からエンティティを一つ選択し、そのエンティティのＴｉｍｅＳｔａｍｐが未定かどうかをチェックする。未定であった場合には、Ｓ１２０５、未定ではなかった場合はＳ１２０６へ遷移する。Ｓ１２０５では、フロントエンド処理部３１１は、エンティティ、Ｄｏｃｕｍｅｎｔ、および、ＪｏｂＩｄを印刷可能なリストに加える。Ｓ１２０６では、フロントエンド処理部３１１は、Ｓ１２０３で取得したエンティティのリストの全てに対して処理を行ったかどうかをチェックする。全てに対して処理を行った場合には、Ｓ１２０７、全てに対して処理を行っていない場合には、Ｓ１２０４へ遷移する。Ｓ１２０７では、フロントエンド処理部３１１は、印刷可能なリストを画像形成装置に１０２に送信する。
Ｓ１２０８では、画像形成装置１０２は、フロントエンド処理部３１１から受信したで印刷可能なリストに含まれるデータを表示する。Ｓ１２０９では、画像形成装置１０２は、表示した一覧の中から印刷したいデータを選択し印刷要求を行う。この際、フロントエンド処理部に対して印刷するデータのＪｏｂＩｄを送信する。Ｓ１２１０では、フロントエンド処理部３１１は、画像形成装置１０２からの印刷要求を受信する。
Ｓ１２１１では、フロントエンド処理部３１１は、受信したＪｏｂＩｄを基に、ログテーブルからエンティティを取得し、そのエンティティのＤａｔａＳｔｏｒｅＰａｔｈを基にデータを取得する。Ｓ１２１２では、フロントエンド処理部３１１は、取得したデータを画像形成装置１０２に送信する。Ｓ１２１３では、画像形成装置１０２は、受信したデータを印刷する。
【００３６】
［バックエンド処理部３１２の処理の流れ］
図９を用いて、バックエンド処理部３１２の処理の流れについて説明する。Ｓ１３０１では、バックエンド処理部３１２は、ジョブキューをポーリングする。Ｓ１３０２では、バックエンド処理部３１２は、ジョブキューにメッセージが存在しているかどうかをチェックし、メッセージが存在した場合には、Ｓ１３０３、存在しない場合には、Ｓ１３０１に遷移する。Ｓ１３０３では、バックエンド処理部３１２は、ログテーブルにＳ１３０２で取得したメッセージに含まれるＪｏｂＩｄを持つエンティティが存在するかどうかをチェックする。エンティティが存在する場合にはＳ１３０６に、存在しない場合にはＳ１３０４に遷移する。
Ｓ１３０４では、バックエンド処理部３１２は、送信済みＪｏｂＩｄリストから、すでにそのＪｏｂＩｄを含むメッセージをログキューに格納したかどうかをチェックする。送信済みＪｏｂＩｄリストにＪｏｂＩｄが存在している場合、Ｓ１３０３に、存在していない場合はＳ１３０５に遷移する。Ｓ１３０５では、バックエンド処理部３１２は、ログキューに、ログに書き込まれるはずの内容、未完ログを生成しメッセージとして格納する。この際、ＴｉｍｅＳｔａｍｐは未定とし、メッセージには必ずＪｏｂＩｄを含む。また、送信済みＪｏｂＩｄリストに、ログキューに追加したメッセージに含まれるＪｏｂＩｄを追加する。
Ｓ１３０６では、バックエンド処理部３１２は、ログテーブルから取得したエンティティのＴｉｍｅＳｔａｍｐをチェックし、ＴｉｍｅＳｔａｍｐが未定の場合には、Ｓ１３０７、未定ではない場合にはＳ１３０９に遷移する。Ｓ１３０７では、バックエンド処理部３１２は、ジョブキューに入っていたメッセージの内容に従い、処理を行う。Ｓ１３０８では、バックエンド処理部３１２は、Ｓ１３０７の結果得られた処理結果をストレージ３２１に格納する。この際、処理結果には、ログに書くべきＴｉｍｅＳｔａｍｐと、ＪｏｂＩｄを紐づけて、ストレージに格納する。Ｓ１３０９では、バックエンド処理部３１２は、ジョブキューからメッセージを削除し、Ｓ１３０１に遷移する。
バックエンド処理部３１２をこのように構成することにより、バックエンド処理部３１２がシャットダウンし、別のバックエンド処理部３１２が起動した後でも２重書き込み、または記録漏れを防止することが可能になる。
【００３７】
［ログ管理部３１３の処理の流れ］
図１０を用いて、ログ管理部３１３の処理の流れについて説明する。Ｓ１４０１では、ログ管理部３１３は、ログキューをポーリングする。Ｓ１４０２では、ログ管理部３１３は、ログキューにメッセージが存在している場合には、Ｓ１４０３、存在していない場合にはＳ１４０１に遷移する。Ｓ１４０３では、ログ管理部３１３は、取得したメッセージに含まれるＪｏｂＩｄを持つエンティティがログテーブルに存在するかどうかをチェックする。存在しない場合にはＳ１４０４に、存在する場合には１４０５に遷移する。Ｓ１４０４では、ログ管理部３１３は、ログテーブルにログキューから取得したメッセージの内容を記録する。この際、ＴｉｍｅＳｔａｍｐは未定とする。
Ｓ１４０５では、ログ管理部３１３は、ストレージ３２１をポーリングして、メッセージに含まれるＪｏｂＩｄを紐づけられたデータが存在するかどうかをチェックする。存在する場合には、Ｓ１４０６、存在しない場合はＳ１４０５に遷移する。Ｓ１４０６では、ログ管理部３１３は、ストレージ３２１からデータに付属するＴｉｍｅＳｔａｍｐを取得する。Ｓ１４０７では、ログ管理部３１３は、ＪｏｂＩｄにより一意に識別されるエンティティのＴｉｍｅＳｔａｍｐを、取得したＴｉｍｅＳｔａｍｐで更新する。Ｓ１４０８では、ログ管理部３１３は、ログキューからメッセージを削除する。なお、本実施例におけるフラグをＴｉｍｅＳｔａｍｐとしたが、それ以外の情報であっても良い。例えば、単に、“未完”、“完了”の様な情報でフラグを実現しても良い。
以上説明したように、図７、図８、図９、図１０に従って処理すると、ログを記録する前に、ＶＭが処理継続不能となった場合においても、再度ログが記録される。ログを記録した後に、ＶＭが処理継続不能となった場合においても、ログの２重記録が発生しない。また、ログを書き込むまでは、処理結果のデータが印刷されることを防ぐことができる。
【実施例２】
【００３８】
本発明に係る第２の実施形態について説明する。以下構成に関しては実施例１と異なる点についてのみ説明する。本実施例は、実施例１に加え、ユーザが印刷指示をしたのちに、キャンセルを行った場合の処理に関する実施例である。
【００３９】
［ログテーブル］
本実施例における、ログテーブルの例を図６に示す。本実施例におけるログテーブルでは、図５で示したログテーブルのカラムに加え、Ｓｔａｔｕｓカラムを追加した。Ｓｔａｔｕｓカラムに設定される値は、Ｃａｎｃｅｌのみである。詳細なフローについては後述するが、ユーザがキャンセル指示を行った場合にＳｔａｔｕｓカラムにＣａｎｃｅｌの値が設定される。
ログテーブルに対するログ項目の格納の詳細なフローは後述するが、フロントエンド処理部３１１は、ＰＣ１０３からキャンセル要求を受信した場合は、ＳｔａｔｕｓにＣａｎｃｅｌを記録する（図６（ａ））。バックエンド処理部３１２は、処理を開始する前に、ログテーブルを確認し、ＪｏｂＩｄによって一意に識別されるエンティティのＳｔａｔｕｓがＣａｎｃｅｌであった場合には、ＴｉｍｅＳｔａｍｐを更新する（図６（ｂ））。ログ管理部３１３は、ログキューから受け取ったメッセージに基づいて、ログ管理部３１３は、ログキュー６０２に格納されているメッセージに従って、ＴｉｍｅＳｔａｍｐ以外の項目を格納する。この時、項目を格納するエンティティのＳｔａｔｕｓがＣａｎｃｅｌの場合は、ＴｉｍｅＳｔａｍｐには何も格納せず、Ｃａｎｃｅｌではない場合には、未定と格納する。
【００４０】
［フローチャート］
図１１、図１２、図１３を用いて、本発明におけるＰＣ１０３、フロントエンド処理部３１１、バックエンド処理部３１２、ログ管理部３１３の処理の流れを詳細に説明する。画像形成装置１０２の処理の流れに関しては、実施例１で示した処理の流れと同じであるため、説明は割愛する。
【００４１】
［ＰＣ１０３とフロントエンド処理部３１１の処理の流れ］
図１１を用いて、ＰＣ１０３とフロントエンド処理部３１１の処理の流れを説明する。ここで、事前条件として、Ｓ１１０１と同様にＰＣ１０３から印刷要求がなされているものとする。Ｓ１５０１で、ＰＣ１０３はキャンセル指示をフロントエンド処理部３１１に送信する。この際、キャンセル対象のＪｏｂＩｄを送信する。
Ｓ１５０２で、フロントエンド処理部３１１は、ＰＣ１０３から送信されたキャンセル指示を受信する。Ｓ１５０３で、フロントエンド処理部３１１は、受信したＪｏｂＩｄを持つエンティティがログテーブルに存在するかどうかをチェックする。存在している場合には、Ｓ１５０４、存在していない場合はＳ１５０５に遷移する。Ｓ１５０４で、フロントエンド処理部は、ＰＣ１０３にキャンセル処理失敗の旨を通知する。Ｓ１５０５で、フロントエンド処理部は、ログテーブルに受信したＪｏｂＩｄを持つエンティティを作成し、ＳｔａｔｕｓカラムをＣａｎｃｅｌとする。Ｓ１５０６で、フロントエンド処理部は、ＰＣ１０３にキャンセル処理成功の旨を通知する。Ｓ１５０７で、ＰＣ１０３は、フロントエンド処理部３１１から送信されるキャンセル処理成否の情報を受信する。
【００４２】
［バックエンド処理部３１２の処理の流れ］
図１２を用いて、バックエンド処理部３１２の処理の流れを詳細に説明する。Ｓ１６０１で、バックエンド処理部３１２は、ジョブキューをポーリングする。Ｓ１６０２で、バックエンド処理部３１２は、ポーリングした結果、ジョブキューにメッセージが存在した場合には、Ｓ１６０３、存在しない場合にはＳ１６０１に遷移する。Ｓ１６０３で、バックエンド処理部３１２は、メッセージに含まれるＪｏｂＩｄと同一のＪｏｂＩｄを持つエンティティがログテーブルに存在するかどうかをチェックする。存在する場合にはＳ１６０６、存在しない場合にはＳ１６０４に遷移する。
Ｓ１６０４で、バックエンド処理部は、バックエンド処理部３１２は、送信済みＪｏｂＩｄリストから、すでにそのＪｏｂＩｄを含むメッセージをログキューに格納したかどうかをチェックする。送信済みＪｏｂＩｄリストにＪｏｂＩｄが存在している場合、Ｓ１６０３に、存在していない場合はＳ１６０５に遷移する。
Ｓ１６０５では、バックエンド処理部３１２は、ログキューに、ログに書き込まれるはずの内容をメッセージとして格納する。この際、ＴｉｍｅＳｔａｍｐは未定とし、メッセージには必ずＪｏｂＩｄを含む。また、送信済みＪｏｂＩｄリストに、ログキューに追加したメッセージに含まれるＪｏｂＩｄを追加する。
Ｓ１６０６では、バックエンド処理部３１２は、エンティティのＳｔａｔｕｓを確認して、ＳｔａｔｕｓがＣａｎｃｅｌだった場合には、Ｓ１６０７に、Ｃａｎｃｅｌではなかった場合にはＳ１６１０に遷移する。Ｓ１６０７では、バックエンド処理部３１２は、ログテーブルのＴｉｍｅＳｔａｍｐを現在時刻に更新する。Ｓ１６０８では、バックエンド処理部３１２は、ＴｉｍｅＳｔａｍｐの更新が成功したかどうかをチェックし、更新が成功した場合には、Ｓ１６０９、更新が失敗した場合には、Ｓ１６０１に遷移する。Ｓ１６０９では、バックエンド処理部３１２は、ジョブキューからメッセージを削除する。
Ｓ１６１０では、バックエンド処理部３１２は、エンティティのタイムスタンプが未定であるかどうかをチェックし、未定であった場合には、Ｓ１６１１に、未定ではなかった場合には、Ｓ１６０９に遷移する。Ｓ１６１１では、バックエンド処理部３１２は、ジョブキューのメッセージの内容に従い、処理を行う。Ｓ１６１２では、バックエンド処理部３１２は、ストレージに処理の結果を格納する。この時、処理結果にログに記録されるべきＴｉｍｅＳｔａｍｐと、ＪｏｂＩｄを紐づける。
【００４３】
［ログ管理部３１３の処理の流れ］
Ｓ１７０１では、ログ管理部３１３は、ログキューをポーリングする。Ｓ１７０２では、ログ管理部３１３は、ポーリングした結果、ログキューにメッセージが存在した場合には、Ｓ１７０３、存在しない場合にはＳ１７０１に遷移する。Ｓ１７０３では、ログ管理部３１３は、ログテーブルにメッセージに格納されたＪｏｂＩｄを持つエンティティが存在するかどうかをチェックする。エンティティが存在する場合には、Ｓ１７０４、存在しない場合にはＳ１７０６に遷移する。
Ｓ１７０４では、ログ管理部３１３は、ＪｏｂＩｄによって一意に識別されるエンティティのＳｔａｔｕｓカラムがＣａｎｃｅｌであるかどうかを確認する。ＳｔａｔｕｓカラムがＣａｎｃｅｌであった場合には、Ｓ１７０５、Ｃａｎｃｅｌでなかった場合にはＳ１７０６に遷移する。Ｓ１７０５では、ログ管理部３１３は、ログテーブルにログキューから取得したメッセージの内容を書き込む。この時、ＴｉｍｅＳｔａｍｐカラムには値を設定しない。
Ｓ１７０６では、ログ管理部３１３は、ログテーブルにログキューから取得したメッセージの内容を書き込む。この時、ＴｉｍｅＳｔａｍｐカラムには未定の値を設定する。Ｓ１７０７では、ログ管理部３１３は、ストレージ３２１をポーリングして、指定のＪｏｂＩｄを持つデータが存在しているかどうかをチェックする。存在している場合には、Ｓ１７０８、存在していない場合にはＳ１７０１に遷移する。Ｓ１７０８では、ログ管理部３１３は、ストレージ３２１に存在するデータに紐づけられているＴｉｍｅＳｔａｍｐを取得する。Ｓ１７０９では、ログ管理部３１３は、ログテーブルにおいて、ログキューから取得したメッセージに含まれるＪｏｂＩｄを持つエンティティを更新する。Ｓ１７１０では、ログ管理部３１３は、ログキューからメッセージを削除する。
以上説明したように、図１１、図１２、図１３に従って処理すると、一度印刷要求をフロントエンド処理部に送信した後に、キャンセル指示をした場合でも、処理をキャンセルすることが出来る。また、ログ管理部３１３が任意のタイミングで、処理停止になった場合でも、その処理がキャンセルされたことを示すログを残すことが出来る。
【符号の説明】
【００４４】
１０１  アプリケーションサーバ群
１０２  ストレージサーバ
１０３  ＰＣ
１０４  画像形成装置
３１１  フロントエンド処理部
３１２  バックエンド処理部
３１３  ログ管理部
３２１  ストレージ
３２２  キューサービス
３２３  テーブル
【図１】
2012181759.tif 000003
【図２】
2012181759.tif 000004
【図３】
2012181759.tif 000005
【図４】
2012181759.tif 000006
【図５】
2012181759.tif 000007
【図６】
2012181759.tif 000008
【図７】
2012181759.tif 000009
【図８】
2012181759.tif 000010
【図９】
2012181759.tif 000011
【図１０】
2012181759.tif 000012
【図１１】
2012181759.tif 000013
【図１２】
2012181759.tif 000014
【図１３】
2012181759.tif 000015