JP6157181B2

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

Info

Publication number: JP6157181B2
Application number: JP2013077128A
Authority: JP
Inventors: 武司高橋
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-04-02
Filing date: 2013-04-02
Publication date: 2017-07-05
Anticipated expiration: 2033-04-02
Also published as: JP2014203170A; US9720776B2; US20140325517A1

Description

本発明は、並列分散処理を実行するサーバーシステム、その制御方法、およびそのプログラムに関する。

近年、サーバーコンピューター側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（ＳｏｆｔｗａｒｅａｓａＳｅｒｖｉｃｅ）という技術が利用され始めている。クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ処理を並列に分散して実行することで、多くのクライアントからの要求を同時に処理することが可能となる。また、サーバーで実行されるジョブの一連の処理をタスク処理という単位に分解し、各タスク処理を実行するタスクを連結させて並行で処理することで多数のジョブをスケーラブルに処理することが可能なことも特徴である。本明細書ではこのようなシステムをクラウドシステムと称する。

クラウドシステムにおいて、コンピューターリソースのスケーラビリティ向上や、クライアントからの要求のピーク時にシステムダウンを防ぐために、バックエンドプロセスが能動的に非同期でジョブを取得して実行する形態が特許文献１に開示されている。このような形態において、バックエンドプロセスに異常などが発生し処理が完了しない場合、その処理をもう一度実行させるリトライの機能が必要になる。リトライが行われると、異常が発生したバックエンドプロセスとは別のバックエンドプロセスであってもジョブの処理が可能になる。ここでいう「バックエンドプロセス」とは、ＯＳからは別のプロセスとして認識・管理されるが、異常が発生したバックエンドプロセスと同じ処理を実行するプログラムを表している。バックエンドプロセスの異常は、コンピューターにおいてハードウェア故障が発生した場合、またはバックエンドプロセスに実装したソフトウェアのバグなどによって発生する。

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

バックエンドプロセスに規定処理を実装しタスクを実現した場合、ジョブ処理が正常に実行されるようにするため、タスクに後処理を実行する仕組みを取り入れることが考えられる。後処理とは、ジョブ処理が失敗したことをメールで通知する処理、エラーログを出力する処理、およびステータスを変更する処理等が挙げられる。何れもユーザーにジョブ処理が正常に実行されなかったことを伝達することで、ジョブ処理が再度行われ正常に実行されることを期待するための処理である。

しかしながら、クラウドシステムのリトライの機構は非同期で並列処理を行うため、同一のタスクが同一ジョブを繰り返し実行するとは限らない。そのため、タスクは取得したジョブのジョブ処理が何回目の実行なのかは判断できず、後処理を適切なタイミングで実行することができない。

そこで本願発明では、タスクの試行回数が最大試行回数を超えていない場合は通常ジョブを送信しタスクに特定の処理を実行させ、タスクの試行回数が最大試行回数を超えている場合は失敗ジョブを送信し特定の処理に対応する後処理を実行させるサーバーシステムを提供することを目的の１つとする。

規定処理を実行する複数のタスクと通信可能であり、発生したジョブを前記規定処理が夫々異なる複数の前記タスクに順次処理を実行させることによりジョブ処理を実現するサーバーシステムであって、前記タスクにより実行された前記規定処理が失敗したことに応じて前記タスクの試行回数をカウントし、カウントした前記タスクの試行回数が該試行回数に制限を設けるための最大試行回数を超えたことに応じて前記ジョブの試行回数をカウントするカウント手段と、前記タスクが前記ジョブの取得を要求した際に、前記カウント手段によりカウントされたタスクの試行回数が前記最大試行回数を超えていない場合は通常ジョブを送信し、前記カウント手段によりカウントされたタスクの試行回数が前記最大試行回数を超えているが前記ジョブの試行回数が該試行回数に制限を設けるための最大試行回数を超えていない場合は、失敗ジョブを送信せずに前記ジョブ処理を始めからやり直すように制御するジョブ管理手段と、前記タスクは、前記ジョブ管理手段から前記通常ジョブが送信された場合、前記規定処理を実行し、前記ジョブ管理手段から前記失敗ジョブが送信された場合、前記規定処理に対応する後処理を実行するジョブ実行手段と、を有することを特徴とする。

本発明によると、ジョブ処理が何回目の実行なのか判断できないタスクであっても、後処理を適切なタイミングで実行することができる。

本発明の実施例１におけるクラウドシステムの全体構成を示す図である。本発明の実施例１におけるクライアント端末、サーバーコンピューターのハードウェア構成図である。本発明の実施例１におけるクライアント端末のシステム構成図である。本発明の実施例１における画像形成装置の内部構成の詳細を示す図である。本発明の実施例１におけるスキャンサービスサーバー群のシステム構成図である。本発明の実施例１におけるスキャンサービスサーバー群のユーザーインターフェースの一例である。本発明の実施例１におけるスキャンサービスサーバー群にて保持するスキャンチケットの一例である。本発明の実施例１におけるスキャンサービスサーバー群にて保持するテンプレートの一例である。本発明の実施例１における画像形成装置のユーザーインターフェースの一例である。本発明の実施例１におけるタスクサーバーのシステム構成図である。本発明の実施例１におけるスキャン処理の一連の流れを示すシーケンス図である。本発明の実施例１におけるフローサービスサーバー群のシステム構成図の概要である。本発明の実施例１におけるルート管理サービスサーバー群のシステム構成図である。本発明の実施例１におけるルート管理サービスサーバー群にて保持するルート情報の一例である。本発明の実施例１におけるルート管理サービスサーバー群にて保持するタスク情報の一例である。本発明の実施例１におけるジョブ管理サービスサーバー群のシステム構成図である。本発明の実施例１におけるジョブ管理サービスサーバー群にて保持するジョブ情報の一例である。本発明の実施例２における一時ファイル管理サービスサーバー群のシステム構成図である。本発明の実施例２における一時ファイル管理サービスサーバー群にて保持する一時ファイル情報の一例である。本発明の実施例２におけるルート管理サービスサーバー群にて保持するルート最大試行回数定義の一例である。本発明の実施例２におけるジョブ管理サービスサーバー群にて保持するジョブ情報の一例である。本発明の実施例１におけるジョブ管理サービスサーバー群が実施する、タスクサーバーへのタスク応答に関するフローチャートである。本発明の実施例１におけるタスクサーバーが実施する処理に関するフローチャートである。本発明の実施例１におけるジョブ管理サービスサーバー群が実施する、タスクサーバーへのタスク応答に関するフローチャートである。本発明の実施例３におけるクラウドシステムの全体構成を示す図である。本発明の実施例３における管理者端末のシステム構成図である。本発明の実施例３における再実行ツールのユーザーインターフェースの一例である。本発明の実施例３における再実行ツール２６０１が実施する処理に関するフローチャートである。

クラウドシステムのリトライの機構は非同期で並列処理を行うため、同一のタスクが同一ジョブを繰り返し実行するとは限らない。そのため、タスクは取得したジョブのジョブ処理が何回目の実行なのかは判断できず、後処理を適切なタイミングで実行することができない。タスクはジョブ処理が何回目の実行なのかを判断することができないので、例えば、処理が失敗する度にメールを通知する実装にしたとする。しかし、３回リトライすると失敗の度にメールが送信されることになるので、実際失敗したジョブは一つであるにも関わらず３通失敗通知が送られてしまいユーザーを混乱させることがある。ここでは、この課題を解決するためのクラウドシステムについて詳細に説明する。以下、本発明を実施するための最良の形態について図面を用いて説明する。

図１は、本発明の実施の形態に係るクラウドシステムを含むシステムの全体構成を示す図である。図１で、スキャンサービスサーバー群１０１、フローサービスサーバー群１０２、タスクサーバー１０３、１０４、クライアント端末１０６、画像形成装置１０７、インターネットサービスサーバー１０８は、ネットワーク１１０〜１１２を介して接続されている。図１において、タスクサーバー１０３、１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバー群１０８は、夫々複数存在することを仮定している。

ネットワーク１１０〜１１２は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれである。また、これらの組み合わせにより実現される、いわゆる通信ネットワークである。ネットワーク１１０〜１１２は、データの送受信が可能であればよい。クラウドサービスでは、通常、ネットワーク１１０、１１２はインターネット、ネットワーク１１１は企業内ネットワークやサービスプロバイダーのネットワークとなる。スキャンサービスサーバー群１０１、フローサービスサーバー群１０２、タスクサーバー１０３、１０４は、一般的に複数のサーバーコンピューター群で構成されており、これらサーバー群がユーザーに対してクラウドサービスを提供する。しかし、サーバーコンピューター群は１台で構成されていても良く、例えば、フローサービスサーバー群１０２は夫々が異なる機能を持つサーバー群で構成されているがプロセスとして実装しても良い。このように、本願発明を達成するためのサーバーの数に制限はないため、サーバーシステムと称した場合は１台のサーバー、またはサーバー群で構成されるサーバーを指すものとする。

実施例１におけるスキャンサービスサーバー群１０１が提供するサービスとは、ユーザーが画像形成装置でスキャンしたことで得られる画像データに対して画像処理を施し、外部のクラウドサービスに保存するサービスである。また、夫々の処理は、タスクサーバー１０３、および１０４により実現され、各タスクサーバーが順次処理することでスキャンサービスが提供される。

また、様々な企業などにより外部サーバーシステムであるクラウドサービスサーバー群１０８がインターネット上に公開されており、これらも一般的に複数のサーバーコンピューター上にて実現される。クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータシスタント）等から成るが、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、ＷｏｒｌｄＷｉｄｅＷｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。

図２は、実施例１に係るクライアント端末１０６、サービス群１０１〜１０４を実行するサーバーコンピューターのハードウェア構成図である。図２において、ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ（ＣＰＵ）２０２は装置全体の制御を行う。ＣＰＵ２０２はハードディスク（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、ＲａｎｄａｍＡｃｃｅｓｓＭｅｍｏｒｙ（ＲＡＭ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。ＲｅａｄＯｎｌｙＭｅｍｏｒｙ（ＲＯＭ）２０４は記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。ディスプレイ２０６は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インターフェース２０８は外部装置Ｉ／Ｆであり、プリンター、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司るものである。ネットワークインターフェースカード（ＮＩＣ）２０９は、該インターフェース２０９、ネットワーク１１０〜１１２を介して外部装置とのデータのやり取りを行う。なお、上記コンピューターの構成はその一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。

図３は、実施例１に係るクライアント端末１０６のシステム構成図である。図３において、Ｗｅｂブラウザ３０１を利用し、スキャンサービスサーバー群１０１が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザーは本クライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドシステムのサービスを利用する。Ｗｅｂブラウザ３０１は、ＣＰＵ２０２がＨＤＤ２０５に保存されたＷｅｂブラウザのプログラムを実行することにより実現される。

図４は、実施例１に係る画像形成装置１０７の内部構成を例示するブロック図である。実施例１ではスキャン・プリントの両機能を併せ持つ画像形成装置を例に説明するが、スキャンサービスを実現するに当たっては、プリント機能のない、スキャン専用装置でも良い。図４において、画像形成装置１０７は、画像処理ユニット４０１、印刷ユニット４０２、および読み込みユニット４０３から構成される。画像処理ユニット４０１は、ＣＰＵ４０４、直接記憶部４０５、間接記憶部４０６、ユーザーインターフェース４０７、外部インターフェース４０８から構成されている。

ＣＰＵ４０４は、所定のプログラムを実行し、画像形成装置１０７の各種制御を指示するユニットである。ＣＰＵ４０４は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）により実現される。直接記憶部４０５は、ＣＰＵ４０４がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ４０４が実行するプログラムは直接記憶部４０５にロードされる。直接記憶部４０５は、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）により実現される。間接記憶部４０６は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部４０６に記憶されている各種プログラムは、ＣＰＵ４０４がプログラムを実行する際に直接記憶部４０５へ移動する。間接記憶部４０６は、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）、または、ＨＤＤ（ＨａｒｄＤｉｓｃＤｒｉｖｅ）により実現される。なお、ＣＰＵ４０４はマルチプロセッサでも良い。

ここで、プラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置１０７上で実行できる他、画像形成装置１０７の操作画面をカスタマイズすることが可能になる。

プラットフォームの実現方法について説明する。ＣＰＵ４０４は、間接記憶部４０６に記憶されたプラットフォームプログラムを直接記憶部４０５に移動する。移動が完了するとＣＰＵ４０４は、プラットフォームプログラム（例えば、Ｊａｖａ（登録商標））を実行することができる状態になる。本発明の実施例では、ＣＰＵ４０４がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０７のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。

プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。実施例１において、プラットフォーム上には、スキャンした画像をクラウドサービスに送信するスキャンソフトウェアが動作している。スキャンソフトウェアは、ネットワークを介して接続されているスキャンサービスサーバー群１０１より、例えば、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）と言った通信プロトコルによってスキャンチケットの一覧の受信を行う。スキャンチケットにはスキャンの為の設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。ユーザーはスキャンソフトウェア部にて表示されたスキャンチケット一覧からスキャンチケットを選択し、原稿を読み込ませることでスキャンサービスを受けることができる。スキャンソフトウェア部はユーザーが選択したスキャンチケットの情報と、画像データを合わせてスキャンサービスサーバー群１０１に送信する。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０７の制御を実現することができる。

アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部４０６に記憶されたアプリケーションプログラムを直接記憶部４０５に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本発明の実施例ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例で開示するフローチャートの各処理の一部を行うことが可能である。

ユーザーインターフェース４０７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース４０８は、外部装置からのデータ受信や外部装置へのデータ送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０７は、ネットワーク１１０、１１１を介して、クライアント端末１０６、スキャンサービスサーバー群１０１と通信可能である。

続いて、クラウドサービスを提供するスキャンサービスサーバー群１０１、タスクサーバー１０３、１０４の各サービスサーバー群に関して説明する。また、各サービスサーバー群の説明とともに、図１１のスキャン処理のシーケンス図を用いてクラウドスキャンサービスの処理の流れを合わせて説明する。

図５を用いて、スキャンサービスサーバー群１０１に関して説明する。スキャンサービスサーバー群１０１はクラウドサービスにおけるスキャン機能の提供を行うサービスサーバー群である。図５は、実施例１に係るスキャンサービスサーバー群１０１のシステム構成図である。スキャンサービスサーバー群１０１は、Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ部５０２、テンプレート管理ＤＢ部５０３からなる。これら構成要素により各種処理が実行されることでスキャンサービスサーバー群１０１がユーザーに提供される。これら構成要素は、ＣＰＵ２０２がＨＤＤ２０５に保存された各種プログラムを実行することにより実現される。

Ｗｅｂアプリケーション部５０１はスキャン機能を提供するアプリケーションプログラムである。チケット作成部５１１はユーザーがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットには、画像形成装置１０７で原稿をスキャンする際のスキャン設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメーター等が記録されている。

図１１にて、チケット作成部５１１は、クライアント端末１０６のＷｅｂブラウザ３０１からのスキャンチケット作成画面リクエストＳ１１０１を受け取り、スキャンチケット作成画面を生成しレスポンスＳ１１０２を行う。この際、チケット作成部５１１はテンプレート管理部５１６より、テンプレート管理ＤＢ部５０３に登録されているスキャンチケットのテンプレートを取得し、テンプレートに含まれるテンプレート名をＷｅｂブラウザ３０１に表示させる。テンプレート管理ＤＢ部５０３の詳細な内容は、図８を用いて後で説明する。また、テンプレート名を表示する画面は図６に示す通りであり、表示画面についても後述する。

ユーザーがＷｅｂブラウザ３０１を操作しスキャンチケット作成リクエストＳ１１０３を行うことで、スキャンチケット作成、およびチケット管理部５１５への保存が依頼される。チケット管理部５１５は、チケット保存のリクエストを受け、チケット管理ＤＢ部５０２にスキャンチケットを保存する。チケット管理ＤＢ部５０２の詳細な内容は図７に記載されている。チケット管理ＤＢ部５０２の詳細は後述する。チケット管理部５１５は、スキャンチケットを保存した後、レスポンスＳ１１０４を行う。

外部Ｉ／Ｆ５１４は画像形成装置１０７上で動作するスキャンソフトウェア部との通信を行う。スキャンソフトウェア部より、外部Ｉ／Ｆ５１４を通じて、チケット一覧部５１２の機能や、スキャン受信部５１３の機能へのアクセスを行う。図１１にて、画像形成装置１０７のスキャンソフトウェア部は外部Ｉ／Ｆ５１４を通じてチケット一覧部５１２に対して、チケット一覧取得Ｓ１１０５を行う。チケット一覧５１２では、スキャンチケットの一覧をチケット管理部５１５より生成し、スキャンソフトウェア部にレスポンスＳ１１０６を返す。レスポンスを受け取った画像形成装置１０７は、取得したチケット一覧を図４におけるユーザーインターフェース４０７上に表示する。表示画面例は、図９に記載されている。表示画面例の説明は後述する。

図１１のスキャン処理Ｓ１１０７にて、ユーザーは、ユーザーインターフェース４０７上に表示されたチケットのいずれかを選択し、画像形成装置に備え付けられたスキャン装置に紙を設置し、スキャン実行する。これにより、スキャンソフトウェア部は、スキャン送信Ｓ１１０８にて、外部Ｉ／Ｆ５１４を通じてスキャン受信５１３に対し、スキャンした画像データとスキャンチケットの送信を行う。

スキャン受信部５１３は、送信されたスキャンチケット、および画像データを受信する。スキャン受信部５１３はステップＳ１１０９にて、受信した画像データを、フローサービスサーバー群１０２に投入する。フローサービスサーバー群１０２は、画像データを正しく受信できた場合には、スキャンサービスサーバー群１０１に画像データを一意に識別するＩＤ（ファイルグループＩＤ）を応答する。その後、スキャン受信部５１３は、ジョブ投入Ｓ１１１１にて、ファイルグループＩＤ、およびスキャンチケットをフローサービスサーバー群１０２に送信する。以上がスキャンサービスサーバー群１０１のシステム構成と、スキャンジョブの投入までの流れである。

図６にて、チケット作成画面６０１の説明を行う。チケット作成画面６０１は、図５のテンプレート管理ＤＢ５０３から取得したテンプレート（図中６０２、６０３、６０４）を表示する。ユーザーは、表示されたテンプレートの中から、実行するテンプレートを選択する。テンプレートを選択すると、詳細なチケット設定を行う画面６０５が表示される。図６において、同一画面に詳細設定画面６０５が表示されているが、別ウィンドウで詳細設定画面６０５を開くようにしても構わない。詳細設定画面６０５中では、選択したテンプレートに応じたスキャンの設定を行うことが出来る。例えば、スキャン設定の例としては、図中に示す様にサイズや、カラー、白黒といった色調、またスキャンデータのフォーマット等の設定がある。ユーザーは、詳細な設定を行った後、チケット発行ボタン６０６を押下すると、図５のチケット管理ＤＢ部５０２に、チケットの情報が新規作成される。チケット管理ＤＢ部５０２に保存されるスキャンチケットは、後述する。スキャンチケットが、チケット管理ＤＢ部５０２に正しく作成された場合には、チケット番号６０７に、チケットに固有に割り当てられたＩＤが表示される。このＩＤは、図７におけるチケットＩＤ７０２と同じ値となる。ユーザーは、チケット番号６０７に表示されたＩＤを記憶し、画像形成装置１０７に移動する。

図７にて、チケット管理ＤＢ部５０２で管理されている情報の一例を示す。ユーザーＩＤ７０１は、チケットを作成したユーザーを一意に表すＩＤである。チケットＩＤ７０２は、チケットを一意に定義するＩＤである。このチケットＩＤは、図６のチケット発行６０６を押下した際にチケット作成部５１１にて生成され、チケット管理ＤＢ５０２に保存される。ルートＩＤ７０３は、チケット作成画面６０１にてユーザーが選択したテンプレートに対応するルートＩＤである。ユーザーがチケットを選択し、スキャンを実行した場合には、そのスキャンデータは、ルートＩＤ７０３に定義されたタスクの順番で処理される。パラメーター７０４は、詳細設定画面６０５にて設定したスキャンの設定が記録されている。

図８にて、テンプレート管理ＤＢ５０３で管理されているテンプレートの一例を示す。テンプレート管理ＤＢ５０３は、図１３のルート情報管理ＤＢ部１３０１にて管理されるルート情報と、チケット作成画面上に表示されるテンプレートを紐づけるためのデータベースである。ここで、テンプレートは、テンプレートＩＤ８０１、テンプレート名８０２、およびルートＩＤ８０３から構成される。テンプレートＩＤ８０１は、各テンプレートを一意に表すＩＤである。テンプレート名８０２は、図６のチケット作成画面６０１に表示される名前である。ルートＩＤ８０３は、図１４における、ルート情報管理ＤＢ部１３０１にて管理されるルートＩＤ１４０１への外部キーを表す。

図９にて、図１１のチケット一覧取得Ｓ１１０５にて、取得したスキャンチケットが表示される画面例を説明する。本画面は、画像形成装置１０７のユーザーインターフェース４０７上に表示される。画面上には、チケット管理５０２から取得したチケットＩＤ７０２が表示されている（９０１〜９０６）。ユーザーは、実行するチケットを選択し、画像形成装置１０７にスキャン対象の原稿を設置し、スキャンボタン９０７を押下する。これにより、図１１におけるスキャン送信Ｓ１１０８が実行される。スキャン送信Ｓ１１０８が実行されると、スキャンサービスサーバー群１０１のスキャン受信５１３に対して、スキャンしたデータと、チケットが送信される。

引き続き、図１０にて、実施例１に係るタスクサーバー１０３、１０４のシステム構成図を説明する。各タスクサーバーは、スキャンサービスを実現するための要素機能を実行するサーバーである。なお、実施例１ではタスクサーバーの例を説明するが、例えば、フローサービスサーバー群１０２のプロセスとして実現させても良い。そこで、プロセス、およびサーバーの両方に対応するため実施例１では単にタスクと称する。例えば、画像データ対して画像処理を行うタスクサーバーや、ファイル共有機能を提供するような他のクラウドサービスサーバー群１０８に対して、画像データを送信する処理を行うタスクサーバーが存在する。実施例１においては、タスクサーバー１０３は、画像データに対してＯＣＲ処理を行いＯＣＲ結果のテキストデータを画像データに埋め込む処理を行う。また、タスクサーバー１０４は、クラウドサービスサーバー群１０８の中のストレージ機能を提供する特定のサービスに対して、画像データを送信し保管する処理を行う。何れも後述する通常処理部１０１３により実現される機能である。

このように、異なる規定処理を実行する複数のタスクサーバーが存在し、発生したジョブを規定処理が夫々異なる複数のタスクサーバーが順次処理を実行することによりジョブ処理を行う。例えば、画像形成装置にてスキャンされたことにより生成された画像データに対し画像処理を施し、当該画像処理が施された画像データを外部サーバーシステムに送信する送信処理を実行する形態が考えられる。なお、タスクサーバーの機能は画像処理、送信処理に限らずその他の処理も実現可能である。

また、タスクサーバー１０３、１０４は前述の要素機能（ＯＣＲ結果を画像データに埋め込む処理、またはクラウドサービスサーバー群１０８へ画像データを保管する処理）が失敗した場合に、後処理を実行する機能を有する。後処理の具体的な内容としては、タスクサーバー１０３、１０４がエラーの内容を示すエラーログを出力する出力処理、エラーの内容を示すエラーメールをスキャン実行者に通知する通知処理、ステータスを表示する画面をエラーステータスに変更しエラーステータスを表示するステータス表示処理、などといったことが例として考えられる。

なお、タスクサーバー１０３、１０４はそれぞれ複数存在する。これはタスクサーバーの目的が、可用性と、大量処理を同時並行で実施するスケーラビリティと１つのサーバーがクラッシュしても他のサーバーが代替する可用性をもって要素機能を実現するプラットフォーム的位置づけだからである。プラットフォーム的な位置づけであるため、各タスクサーバーの通常処理部１０１３、後処理部１０１４は、サービスの開発者がプログラム・組み込み可能な構成を想定している。これにより、取得したジョブに対してどのような機能を実行するか、および機能実行に失敗した場合にどのような処理を実行させるかを、クラウドシステムを利用してサービス開発者が自由に決定できる。また、もちろん無制限にジョブを他のサーバーが代替してジョブ処理の再試行を繰り返すわけではなく、一定回数の再試行を行っても失敗する場合にはそのジョブを失敗状態にし、後処理を行う必要がある。

しかし、別のタスクサーバー、もしくはタスクプロセスが再試行処理を代替する構成のため、タスクは失敗回数を数えることはできない。また、後処理をタスクサーバー、もしくはタスクプロセスが処理を失敗する度に後処理を実行すると好ましくない。例えば、試行回数の１、２回目は失敗し３回目で成功した場合、１、２回目の後処理で失敗メールをスキャン実行者に送信すると成功したにも関わらず、スキャン実行者が失敗メールを受け取るという矛盾が発生する。また、ある人がジョブを２つ投入して、うち一つのジョブは成功しもう一つが再試行３回全てに失敗した場合、失敗メールが３通送られる。この場合、メールを受け取った人は、一体いくつのジョブが失敗したのかわかりにくく混乱を招くことになる。

タスクサーバー１０３、１０４の構成要素であるタスク制御部１０１１、ジョブ通信部１０１２、通常処理部１０１３、後処理部１０１４は一つのサーバーにつき１セットである必要はなく、ＯＳ上のプロセスとして複数セット存在してもよい。以下、図１１のスキャン処理のシーケンス図の流れとともに各構成要素の説明を行う。ステップＳ１１１２、Ｓ１１１３、Ｓ１１１９、Ｓ１１２０にて、定期的にフローサービスサーバー群１０２に問い合わせを行い、各タスクサーバー１０３、１０４にて処理可能なタスクを取得する。フローサービスサーバー群１０２の各タスクサーバー１０３、１０４への応答に関する詳細なフローは、図２２を用いて後述する。

タスクサーバー１０３、１０４のタスク制御部１０１１は、ジョブ通信部１０１２を使用し、ステップＳ１１１２、Ｓ１１２０にて、定期的にフローサービスサーバー群１０２に問い合わせを行う。換言すると、ジョブ処理を行っていない待機中のタスク制御部１０１１は、ジョブ取得の為にフローサービスサーバー群１０２に対しポーリングを行うと言える。各タスクサーバー１０３、１０４にて処理可能なジョブが存在する場合には、ステップＳ１１１３、Ｓ１１２１にてその応答としてジョブ通信部１０１２は処理可能なジョブを取得する。フローサービスサーバー群１０２の各タスクサーバー１０３、１０４への応答に関する詳細なフローは、図２２を用いて後述する。

また、タスクサーバー１０３、１０４のジョブ通信部１０１２は、取得したジョブの情報を元に、ステップＳ１１１４、Ｓ１１１５、Ｓ１１２２、Ｓ１１２３にてフローサービスサーバー群１０２より処理すべき画像データの取得も行う。タスクサーバー１０３、１０４の通常処理部１０１３は、ジョブ通信部１０１２が取得した前記画像データに対し、ステップＳ１１１６、Ｓ１１２４にて各種処理を行うようタスク制御部１０１１から呼び出される。タスクサーバー１０３、１０４の後処理部１０１４は、ジョブ通信部１０１２が取得したジョブが失敗ジョブだった場合に、タスク制御部１０１１から呼び出されるが、詳細なフローに関しては図２３を用いて後述する。

タスクサーバー１０３、１０４のジョブ通信部１０１２は、Ｓ１１１７、Ｓ１１２５にて定期的にフローサービスサーバー群１０２に状態通知を行う。タスクサーバー１０３の通常処理部１０１３は、ステップＳ１１１６での処理結果をステップＳ１１１８にてタスク制御部１０１１、ジョブ通信部１０１２を通して、フローサービスサーバー群１０３に保存する。タスクサーバー１０４の通常処理部１０１３は、ステップＳ１１２４での処理結果をステップＳ１１２６にてクラウドサービスサーバー群１０８にデータ送信する。さらに、タスクサーバー１０３、１０４のジョブ通信部１０１２は、タスク制御部１０１１の指示に基づいて通常処理部１０１３の処理結果をフローサービスサーバー群１０２へ、ステップＳ１１１９、Ｓ１１２７にて結果リクエストとして通知する。フローサービスサーバー群１０２の各タスクサーバー１０３、１０４への結果リクエストの応答に関する詳細なフローは、図２２を用いて後述する。

続いて、フローサービスサーバー群１０２の詳細な説明を行う。フローサービスサーバー群１０２は本願発明における中心的なサービスサーバー群であり、ルート管理、ジョブ管理、一時ファイル管理を行うサービスサーバー群である。図１２は、フローサービスサーバー群１０２のシステム構成の概要である。

フローサービスサーバー群１０２は、ルート管理サービスサーバー群１２０１、ジョブ管理サービスサーバー群１２０２、一時ファイル管理サービスサーバー群１２０３の各サーバー群からなる。これらサーバー上において各種処理を実行するサービスが提供され、それらのサービスが連携することで、フローサービスサーバー群１０２がユーザーに提供される。ルート管理サービスサーバー群１２０１はタスクとタスクを連結させたルートの情報を管理する。ジョブ管理サービスサーバー群１２０２はルートの情報に基づきジョブの処理を管理する。

一時ファイル管理サービスサーバー群１２０３はジョブ投入時のデータや各タスクの処理結果データの保存を管理する。引き続きフローサービスサーバー群１０２を構成するルート管理サービスサーバー群１２０１、ジョブ管理サービスサーバー群１２０２、一時ファイル管理サービスサーバー群１２０３の詳細な説明を行う。

図１３は、ルート管理サービスサーバー群１２０１のシステム構成である。ルート管理サービスサーバー群１２０１は、ルート情報管理ＤＢ部１３０１、タスク情報管理ＤＢ部１３０２、外部Ｉ／Ｆ１３０３からなる。ルート情報管理ＤＢ部１３０１はタスクが順次処理を実行する順番、即ちタスクとタスクの連結をルートという単位で定義するための情報を保持している。タスク情報管理ＤＢ部１３０２は各規定処理をタスクという単位で定義し、タスクに関する情報を保持している。外部Ｉ／Ｆ１３０３はルート管理サービスサーバー群１２０１への問い合わせのためのＩ／Ｆであり、ジョブ管理サービスサーバー群１２０２等からルート情報管理ＤＢ部１３０１やタスク情報管理ＤＢ部１３０２を参照するためのＩ／Ｆである。

図１４にて、ルート情報管理ＤＢ部１３０１で管理されている情報を示す。ルートＩＤ１４０１がルートを一意に識別するＩＤである。シーケンス番号１４０２はそのルートの何番目に実行するタスクであるかを保持する。タスクＩＤ１４０３はどのタスクを実行するかを保持する。最大試行回数１４０４は、タスクが失敗した場合、そのタスクがジョブを何回処理可能にするかを定めている。ジョブ管理サービスサーバー群１２０２からタスクがジョブの取得要求を送信してきた際、この最大試行回数に至っていない場合には同じ規定処理を実行する他のタスクが同一のジョブを取得可能である。

例えば、データ１４１３、１４１４、１４１５で、ルートＩＤ１４０１が００２のルートを定義している。１４１３が１番目に実行するタスクであり、タスクＩＤ１４０３によればタスク１が処理を始めに実行する。同様に、シーケンス番号１４０２の値が２であるタスク３が２番目に処理を実行するタスクであり、最後にタスク５が処理を実行するという定義となる。即ち、タスク１、タスク３、タスク５の順番で順次処理が実行されることによりジョブ処理が行われる。

図１５にて、タスク情報管理ＤＢ部１３０２で管理されている情報の一例を示す。タスクＩＤ１５０１がタスクを一意に識別するＩＤである。タスク名１５０２はそのタスクの名前である。中止時間１５０３はジョブ管理サービスサーバー群１２０２がタスクサーバー１０３、１０４の処理を中止するまでの時間である。中止時間１５０３で示される時間以上の時間、タスクサーバー１０３、１０４が実行状態だった場合、ジョブ管理サービスサーバー群１２０２はタスクサーバーに異常が発生したと判断し、同じ規定処理を実行する他のタスクサーバー１０３、または１０４へジョブを委譲する。タスクサーバー１０３、１０４は、ハードウェア故障やソフトウェアバグなどが発生する場合、ネットワーク切断などにより通信できない場合など、様々な異常が発生する。さらに、例えば画像処理や外部クラウドへの保存処理など、処理対象のデータが巨大な場合にもタスクサーバー１０３、１０４は長時間実行状態となる。このような場合も、異常が発生したと判断される。状態通知時間１５０４はジョブ管理サービスサーバー群１２０２がタスクサーバー１０３、１０４に対して状態通知させる時間を示す。ジョブ管理サービスサーバー群は、状態通知時間１５０４で示される時間からさらに数秒の猶予時間以上状態通知が行われなかった場合に、他のタスクサーバー１０３、１０４へジョブを委譲する。これらの中止処理により、タスクサーバー１０３、１０４に異常が発生した場合でも、委譲されたタスクサーバー１０３、１０４によってジョブの実行を完了させることができる。

図１６を用いてジョブ管理サービスサーバー群１２０２に関して説明する。ジョブ管理サービスサーバー群１２０２は、タスクサーバー１０３、１０４からのリクエストに対してタスク情報の授受や、各ジョブの状態を管理するためのサービスサーバー群である。

外部Ｉ／Ｆ１６０１は、タスクサーバー１０３、１０４、および画像形成装置１０７との通信を行う。外部Ｉ／Ｆ１６０１を通じて、ジョブ管理サービスサーバー群１２０２の各機能へのアクセスを行う。ジョブ情報管理ＤＢ部１６０２は、作成された各ジョブのステータスや、各ジョブが扱うデータのＩＤを管理する。ジョブ情報管理ＤＢ部１６０２の詳細な内容は、図１７に記載されており、ジョブ情報管理ＤＢ部１６０２の内容に関する説明は後述する。ジョブ追加部１６０３は、スキャンサービスサーバー群１０１が、図１１において、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ投入リクエストＳ１１１１を受け、ジョブ情報管理ＤＢ部１６０２に、ジョブ情報を格納する。

ここで、ジョブ情報とは、図１７に示されるジョブ情報管理ＤＢ部１６０２に存在する各カラム（１７０１〜１７０７）から構成される。ジョブ情報取得部１６０４は、タスクサーバー１０３、１０４から外部Ｉ／Ｆ１６０１を通じて発行されるタスク取得リクエストＳ１１１０を受け、ジョブ情報管理ＤＢ部１６０２から、ジョブ情報を取得する。ここで取得したジョブ情報は、タスク取得Ｓ１１１２にてタスクサーバー１０３、１０４に渡される。ジョブ情報の受け渡しに関わる詳細な説明は、図２２を用いて後述する。ジョブ情報更新部１６０５は、結果通知Ｓ１１１９にて、タスクサーバー１０３、１０４から、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ情報更新リクエストを受け、ジョブ情報管理ＤＢ部１６０２の該ジョブの情報を更新する。ここで、更新される情報として、カレントタスクＩＤ１７０４、およびステータス１７０５、最終更新時刻１７０６がある。カレントタスクＩＤ１７０４を更新する前には、ルート管理サービスサーバー群１２０１の外部Ｉ／Ｆ１３０３を通じて、ルート情報管理ＤＢ部１３０１から、該ルートＩＤにおける次のタスクＩＤを取得する。取得したタスクＩＤを以て、カレントタスクＩＤ１７０４を更新する。また、ステータス１７０５は処理待ち（０）、最終更新時刻１７０６は現在時刻で更新する。ジョブ状態通知部１６０６は、状態通知Ｓ１１１７、１１２５にて、タスクサーバー１０３、１０４から外部Ｉ／Ｆ１６０１を通じて発行される状態通知リクエストを受け付ける。

続いて、図１７を用いて、ジョブ情報管理ＤＢ部１６０２に保持されるデータについて説明する。ジョブＩＤ１７０１は、各ジョブ情報に一意に割り当てられるＩＤである。ルートＩＤ１７０２には、図６のチケット作成画面６０１にて選択したテンプレートに対応するルートＩＤが格納される。ファイルグループＩＤ１７０３は、一時ファイル管理サービスサーバー群１２０３から発行されるＩＤである。カレントタスクＩＤ１７０４は、そのジョブにおいて処理を行うべきタスクを示すタスクＩＤである。タスクサーバー１０３、１０４は、このカレントタスクＩＤ１７０４を確認し、自タスクサーバーに割り当てられたタスクＩＤと等しい行を選択し処理を行う。本ＩＤは、該タスクの処理が完了した際には、ジョブ情報更新１６０５が、該ルートＩＤの次のタスクのタスクＩＤに更新する。ステータス１７０５には、処理待ち（０）、実行中（１）、エラー発生（２）、完了（３）を表す値が設定される。タスクサーバー１０３、１０４がジョブを選択する際には、基本的にステータスが処理待ち（０）となっている行を選択する。これにより、複数のタスクサーバーが同一のタスクを処理するといった事態を防ぐことができる。

タスクサーバー１０３、１０４が、ジョブを選択した後に、タスクサーバー１０３、１０４は、外部Ｉ／Ｆ１６０１を通じて、ジョブステータス変更部１６０５より、ステータス１７０５を実行中（１）に変更する。最終更新時刻１７０６は、タスクサーバー１０３，１０４が該ジョブに対して、何らかの処理を実行した際に、更新される。ここで、何らかの処理とは、ステータスの更新処理や、ジョブの取得処理である。タスクサーバー１０３、１０４がジョブを取得する際に、自タスクＩＤと等しいジョブ情報が複数存在していた場合には、最終更新時刻１７０６が最も古いジョブを選択する。これにより、全てのジョブを平均的に処理することが可能となる。パラメーター１７０７には、詳細設定画面６０５にて設定した設定情報や、タスクサーバー１０３、１０４が、他のタスクサーバー１０３、１０４に渡す設定情報などを記載する。タイムスタンプ１７０８は、ジョブ情報が更新されるたびに自動的に更新される値である。

タスクサーバー１０３、１０４の、ジョブ情報更新１６０５や、ジョブ状態通知１６０６への通信の際に、タイムスタンプを受け渡すことで、他のタスクサーバー１０３、１０４にジョブが委譲されていないことを保証できる。最終状態通知時刻１７０９は、ジョブ情報取得１６０４において、一定時間実行されたままになっているジョブを他のタスクサーバー１０３、１０４へ委譲するために保存している時刻である。最終状態通知時刻１７０９から、中止時間１５０３経過した場合に、他のタスクサーバー１０３、１０４へジョブを委譲する。タスクの試行回数１７１０は、該ジョブをタスクが試行した回数を表すものであり、タスクが規定処理に失敗する毎にカウントされる。

一時ファイル管理サービスサーバー群１２０３は、スキャンサービスサーバー群１０１やタスクサーバー１０３、１０４からの要求に応じて、ファイルを格納し、その格納先のパスを管理するサービスサーバー群である。タスクサーバー１０３、１０４からファイル取得要求があった際には保存したファイルのバイナリデータをタスクサーバー１０３、１０４に返却する。また、タスクサーバー１０３、１０４やジョブ管理サービスサーバー群１２０２からファイル削除の要求があった際には、保存したファイルを削除する。スキャンサービスサーバー群１０１やタスクサーバー１０３、１０４は一時ファイル管理サービスサーバー群１２０３によって、ファイルの格納先のパスやファイルサーバーの状態を気にすることなく、ファイルの保存、取得、削除を行うことができる。

ここで、ジョブ管理サービスサーバー群１２０２がタスクサーバー１０３、１０４からジョブに関するリクエストを受けたときの応答フローについて、図２２を用いて説明する。ステップ２２０１でジョブ管理サービスサーバー群１２０２は、タスクサーバー１０３、１０４からジョブに関するリクエストを受信する。ステップ２２０２でジョブ管理サービスサーバー群１２０２は、リクエストの種類を判別し、ジョブ取得のリクエストの場合にはステップ２２０３を、結果報告リクエストの場合には２２０９を実行する。ジョブ取得リクエストにはタスクＩＤが含まれているが、ジョブ管理サービスサーバー群１２０２はステップ２２０３でそのタスクＩＤに紐づくジョブで処理対象のジョブを一つだけ取得する。この際、ジョブ管理サービスサーバー群１２０２は、ジョブ情報管理ＤＢ１６０２から次の条件に合致するジョブレコードを取得対象とする。カレントタスクＩＤ１７０４が取得リクエストに含まれるタスクＩＤに合致するもので、ステータス１７０５が処理待ち（０）、もしくは実行中（１）でも最終状態通知時刻１７０９から中止時間１５０３経過しているものが取得対象条件である。ステップ２２０３で、取得ジョブがあればステップ２２０４へ分岐するが、取得ジョブがなければステップ２２１２へと分岐する。

ステップ２２１２では、ジョブ管理サービスサーバー群１２０２はリクエスト元タスクに対してｎｕｌｌを返し、本フローを終了する。タスクサーバー１０３、１０４は、ｎｕｌｌを受信すると処理対象のジョブが存在しないと判断して、一定時間後に再度問い合わせを行うポーリング処理を実施する。ステップ２２０４では、ジョブ管理サービスサーバー群１２０２は取得ジョブの確認を行い、正常ジョブであればステップ２２０５を、タイムアウトジョブであればステップ２２０６をそれぞれ実行する。正常ジョブとはステータス１７０５が処理待ち（０）となっているものであり、タイムアウトジョブとはステータス１７０５が実行中（１）のものである。これはステップ２２０３の取得条件で示したようにステータス１７０５が実行中（１）で取得条件に合致する場合には最終状態通知時刻１７０９から中止時間１５０３経過しているジョブのみが対象となっているからである。

ステップ２２０５でジョブ管理サービスサーバー群１２０２は、取得ジョブのタスクの試行回数１７１０を確認し、タスクの最大試行回数１４０４未満であればステップ２２０７を、タスクの最大試行回数１４０４以上であればステップ２２０８を実行する。ステップ２２０７では、ジョブ管理サービスサーバー群１２０２はステータス１７０５を実行中（１）に最終状態通知時刻を現在時刻に変更した後、リクエスト元タスクに通常ジョブを返す。ステップ２２０８では、ジョブ管理サービスサーバー群１２０２はステータス１７０５をエラー発生（２）に変更し、リクエスト元タスクに失敗ジョブとして返す。

一方ステップ２２０２でリクエストの種類が結果報告と判定された場合には、ステップ２２０９が実行されるが、リクエストに処理結果と処理対象のジョブＩＤが含まれる。ステップ２２０９では、ジョブ管理サービスサーバー群１２０２はリクエストに含まれる処理結果が成功か失敗かを確認し、確認の結果、成功の場合にはステップ２２１０へ、失敗の場合にはステップ２２１１へと分岐する。ステップ２２１０では、ジョブ管理サービスサーバー群１２０２は、リクエストに含まれるジョブＩＤと合致するレコードをジョブ情報管理ＤＢ１６０２から探し、そのジョブの正常更新を実行する。ここでいう正常更新とは、カレントタスクＩＤを、ルート情報管理ＤＢ部１３０１を参照して次のタスクＩＤに、ステータス１７０５を処理待ち（０）に、そしてタスクの試行回数１７１０を０に、最終更新日時１７０６を現在時刻にそれぞれ変更する処理である。ただし、次のタスクＩＤが存在しない場合には、ステータス１７０５は完了（３）にし、最終更新日時１７０６を現在時刻にそれぞれ変更する処理となる。ステップ２１１１では、ジョブ管理サービスサーバー群１２０２は、タスクの失敗回数をカウントするために、タスクの試行回数１７１０に１を加えた値に更新する。以上、図２２に示された処理フローにより、ジョブ管理サービスサーバー群１２０２は最大試行回数までは通常ジョブを配信でき、最大試行回数に達した場合には失敗ジョブを配信できる。

図２２では、ジョブ管理サービスサーバー群１２０２が最大試行回数までは通常ジョブを配信でき、最大試行回数に達した場合には失敗ジョブを配信するフローを説明した。ここではさらに図２３を用いて、ジョブ管理サービスサーバー群１２０２からタスクサーバー１０３、１０４がジョブを取得して処理を実行するフローについて説明する。

ステップ２３０１で、タスクサーバー１０３、１０４はジョブ管理サービスサーバー群１２０２からジョブを取得する。ステップ２３０２で、タスクサーバー１０３、１０４は取得ジョブの確認を行うが、ｎｕｌｌを取得した場合には処理対象のジョブが存在しないと判断してそのまま本フローを一旦終了し、一定時間後にジョブ取得を再度試みる。取得ジョブが通常ジョブだった場合にはステップ２３０３へ、失敗ジョブだった場合にはステップ２３０７へと分岐する。ステップ２３０３では、タスクサーバー１０３、１０４内でタスク制御部１０１１が通常処理部１０１３を呼び出し実行する。ステップ２３０４では、タスク制御部１０１１が通常処理部１０１３の実行結果を判定し、成功だった場合にはステップ２３０５へ失敗だった場合にはステップ２３０６へ分岐する。

ステップ２３０５では、タスク制御部１０１１はジョブ通信部１０１２を利用して成功したジョブＩＤと成功結果をジョブ管理サービスサーバー群１２０２へ結果報告リクエストとして通知する。ステップ２３０６では、タスク制御部１０１１はジョブ通信部１０１２を利用して失敗したジョブＩＤと失敗結果をジョブ管理サービスサーバー群１２０２へ結果報告リクエストとして通知する。つまり、結果報告リクエストは、成功か失敗かの「処理結果」を含んでいることになる。一方、ステップ２３０２で取得ジョブが失敗ジョブだった場合にはステップ２３０７において、タスク制御部１０１１は後処理部１０１４を呼び出し実行する。ステップ２３０５、２３０６、２３０７実行後については、タスクサーバー１０３、１０４は本フローを一旦終了し、一定時間後にジョブ取得を再度試みる。以上、図２３に示された処理フローにより、タスクサーバー１０３、１０４は取得したジョブの種類に応じて通常処理と後処理を呼び分けることができる。

以上のように実施例１では、タスクの試行回数が最大試行回数を超えていない場合は通常ジョブを送信しタスクに特定の処理を実行させ、タスクの試行回数が最大試行回数を超えている場合は失敗ジョブを送信し特定の処理に対応する後処理を実行させるサーバーシステムについて説明した。結果、ジョブ処理が何回目の実行なのか判断できないタスクであっても、後処理を適切なタイミングで実行することができる。

実施例１において、ジョブ管理サービスサーバー群１２０２は、タスクの最大試行回数分だけ処理に失敗した際に、後処理用に失敗ジョブを配信する構成とした。実施例２では、ジョブの再試行まで含めて全ての再試行が失敗した時に初めて失敗ジョブを配信する形態について説明する。ジョブの再試行を実施することで、タスクの処理結果ファイルを一時ファイル管理サービスサーバーから取り出せなくなった場合でも処理が継続できるという処理継続性の向上が見込める。よって実施例２で示すジョブが失敗してからエラー通知を行う形態は、タスクが失敗してからエラー通知を行う実施例１の形態に比べ、処理継続性を向上させつつ時後処理も１度に限定することができる。

一時ファイル管理サービスサーバー群１２０３は複数の一時ファイル管理サービスから構成され、スキャンサービスサーバー群１０１から投入された画像データは初期データとして複数の一時ファイル管理サービスで多重保持する。例えば、サーバーＡ、Ｂという２台の一時ファイル管理サービスサーバーが存在する場合を考える。スキャンサービスサーバー群１０１からサーバーＡへの保存要求が行われると、サーバーＡからサーバーＢにも保存要求が行われ、双方に保存が完了した後にスキャンサービスサーバー群１０１へ応答を返すことで初期データが複製される。

一方で、タスクの処理結果を一時ファイル管理サービスサーバー群１２０３へ保存する場合には多重保持されない。つまり、タスクサーバー１０３の処理結果ファイルはサーバーＡもしくはサーバーＢのどちらか一方にのみ格納される。これはタスクの結果ファイルはタスクサーバー１０３の処理を再実行すれば生成可能なので、ディスク容量節約のため多重保持しない構成になっている。一方、スキャンしたことで得られる画像データは再度ユーザーに要求しないと手に入れることができないデータであり、その取得は難しい。よって、スキャンしたことで得られる画像データのような初期データ、または取得が難しいデータは一時ファイル管理サービスサーバー群１２０３により多重保持される。

図１８を用いて、一時ファイル管理サービスサーバー群１２０３に関して説明する。図１８は一時ファイル管理サービスサーバーのシステム構成を表す図である。外部Ｉ／Ｆ１８０１は、タスクサーバー１０３、１０４、および画像形成装置１０７との通信を行う。外部Ｉ／Ｆ１８０１を通じて、一時ファイル管理サービスサーバー群１２０３の各機能へのアクセスを行う。ファイル管理部１８０２は保存要求を受けたファイルを保存する領域である。一時ファイル管理ＤＢ部１８０３は、ファイル管理部１８０２の位置情報を管理するデータベースであり、一時ファイル管理サービスサーバー群１２０３でミラーリング同期されており、どの一時ファイル管理サービスサーバーでも同じデータを読み取れる。

外部Ｉ／Ｆ１８０１は、保存要求を受けるとファイル管理部１８０２にファイルを保存し、一時ファイル管理ＤＢ１８０３にその情報を書き込む。初期ファイルの場合には、他の一時ファイル管理サーバーにファイル保存要求を出す。逆に外部Ｉ／Ｆ１８０１がファイル読み出し要求を受けると、要求に含まれるファイルグループＩＤを元に一時ファイル管理ＤＢを検索し、ファイルの保存場所を特定する。特定したファイル保存場所を元に外部Ｉ／Ｆ１８０１はファイル管理部１８０２にアクセスし、ファイル取得を行う。

図１９は、一時ファイル管理ＤＢ１８０３で管理される一時管理情報の一例である。ファイルＩＤ１９１０は一つのジョブ内で一意に識別するためのＩＤであり、初期ファイルと結果ファイルで同一のファイルグループＩＤが割り振られる。ファイルグループＩＤは初期ファイル保存要求時に外部Ｉ／Ｆ１８０１が生成する。Ｎｏ１９１１は何番目のタスクによって生成されたかを示しており、０番は初期ファイルであることを示す。パス１９１２はファイル管理部１８０２内に保存されているファイルパスを表す。ホスト名１９１３はファイルが保存されているホストを表す。以上、図１８、１９の構成により、一時ファイル管理サービスサーバーが１台クラッシュしても、初期ファイルはタスクサーバー１０３、１０４から読み出し可能である。

図１９の状態で、ＳｅｒｖｅｒＡがクラッシュするとファイルグループＩＤがＦＧ１のファイルはＮｏ．１のファイル、つまり最初のタスク（タスクサーバー１０３）が生成する結果ファイルへ次のタスク（タスクサーバー１０４）がアクセスできない状態になる。そこで、実施例２におけるクラウドプラットフォーム、ジョブ実行方法、およびプログラムは、ジョブに対して最初のタスクから処理を再試行する仕組みを提供することで結果ファイルを再生成し、ジョブを完結させることができる。これを実施例１における「タスクの再試行」と区別し、「ジョブの再試行」と呼ぶ。実施例１によるとタスクサーバー１０４の処理は結果ファイルがないためタスクの再試行は全て失敗し、その後、タスクサーバー１０４の後処理部１０１４が実行されてしまう。しかし、実施例２においては、タスクの再試行が全て失敗した後ジョブの再試行が実行されたことでジョブの処理が成功する可能性がある。この場合、後処理部１０１４は実行されない。ジョブの再試行まで含めて全て失敗した後、初めて失敗ジョブを配信するフローをジョブ管理サービスサーバー群１２０２が実行すること後処理の実行を抑えることができ、余分な後処理の実行を抑えることができる。

図２０を用いて、実施例２におけるルート情報管理ＤＢ部１３０１で図１４のテーブルと共に管理されるルート最大試行回数定義テーブルの一例を示す。ルートＩＤ２００１はルートＩＤ１４０１と同じくルートを一意に識別するＩＤであり、図１４と図２０のデータを紐づけるキーになっている。ジョブの最大試行回数２００２は、対応するルートＩＤで投入されたジョブの再試行を何回実施するかを定義した値である。

図２１を用いて、実施例２におけるジョブ情報管理ＤＢ部１６０２に保持されるデータについて説明する。図２１は図１７に加え、ジョブの試行回数２１０１を管理する列が増えたテーブルである。ジョブの試行回数２１０１は対象のジョブがジョブの再試行を何回実施したかを示す値であり、タスクの試行回数が最大試行回数を超える毎にカウントされる値である。

以下、実施例２におけるジョブ管理サービスサーバー群１２０２がタスクサーバー１０３、１０４からジョブの問い合わせを受けたときの応答フローについて、図２０、２１、２４を用いて説明する。図２４のステップ２４０１からステップ２４１２は、図２２のステップ２２０１からステップ２２１２と同様である。ステップ２４０５にてジョブ管理サービスサーバー群１２０２は、取得ジョブのタスクの試行回数１７１０を確認し、タスクの最大試行回数１４０４未満であればステップ２４０７を、タスクの最大試行回数１４０４以上であればステップ２４１３を実行する。ステップ２４１３では、ジョブ管理サービスサーバー群１２０２は、ジョブの試行回数２１０１を確認し、ジョブの最大試行回数２００２未満であればステップ２４１４を、ジョブの最大試行回数２００２以上であればステップ２４０８を実行するよう分岐する。

ステップ２４１４では、ジョブ管理サービスサーバー群１２０２はルート管理サービスサーバー群１２０１にリクエストを出して、該ルートＩＤの最初のタスクＩＤを取得し、該ジョブのカレントタスクＩＤ１７０４を更新する。ステップ２４１５では、ジョブ管理サービスサーバー群１２０２は、ジョブ処理の失敗回数をカウントするために、ジョブにおけるジョブの試行回数２１０１に１を加算した値に更新する。ステップ２４１６では、ジョブ管理サービスサーバー群１２０２は該ジョブのタスクの試行回数１７１０を０にリセットし、最終状態通知時刻を現在時刻に更新する。そして、リクエスト元のタスクにｎｕｌｌを返却し、始めからジョブ処理がやり直される。結果、エラーが発生したタスクに原因はなくその手前のタスクの処理が失敗したことが要因でエラーとなっていたジョブが正常にジョブ処理され、かつエラー通知が行われることもなくなる。以上、図２４に示された処理フローにより、ジョブ管理サービスサーバー群１２０２は、タスクの再試行に加えジョブの再試行まで全て失敗、もしくはタイムアウトが発生した場合に限って失敗ジョブを配信することができる。

実施例２では、再試行機能によりジョブを別のタスクプロセスに移譲するクラウドシステムにおいて、タスクの再試行に加えジョブの再試行まで全て失敗、もしくはタイムアウトが発生した場合にのみ後処理を実行することができる。つまり実施例２で示すジョブが失敗してからエラー通知を行う形態は、タスクが失敗してからエラー通知を行う実施例１の形態に比べ、ジョブの再試行という処理継続性を向上させつつ時後処理も１度に限定することができる。

実施例２において、タスクの再試行やジョブの再試行を行い、失敗したジョブに対して、タスクサーバー１０３、１０４で定義した後処理を実行するようにした。しかし、失敗したジョブの種類によっては、メール通知やエラーログで画像形成装置の管理者やクラウドシステムの管理者などに通知しても再実行してもらうのが困難な場合がある。例えば、画像形成装置の日々の初回起動イベントやエラーイベントなどのマシンイベントや、特定日時でのスケジュール実行処理など、ユーザー操作ではないイベントを契機に実行されるジョブがこれに該当する。

実施例３では、カウントされたタスクの試行回数が最大試行回数を超え、かつジョブの試行回数も最大試行回数を超えたことによりジョブ処理が中断されているジョブに対し再試行が指定された場合、指定ジョブのステータス、ジョブの試行回数、およびタスクの試行回数をリセットする手段を提供する。

図２５は、本実施例に係るクラウドシステムの全体構成を示す図である。図２５は、フローサービスサーバー群１０２の管理者が利用する管理者端末１０５と、管理者端末１０５がフローサービスサーバー群１０２と通信するための通信ネットワーク１１３を図１に追加したものである。管理者端末１０５を実行するサーバーコンピューターのハードウェア構成図は図２で示される通りである。

図２６は、前記管理者端末１０５のシステム構成図である。再実行ツール２６０１は、フローサービスサーバー群１０２と通信を行って指定ジョブを再実行させるツールである。図２７は再実行ツール２６０１の画面であり、クラウドサービスの管理者によってジョブＩＤ指定部２７０１にジョブＩＤが指定され、再処理実行ボタン２７０２を管理者に押下されることで図２８に示すフローが実行される。

図２８は、再実行ツール２６０１の処理フローを表す図である。ステップ２８０１で、再実行ツール２６０１はジョブＩＤ指定部２７０１に指定されたジョブＩＤを読み込む。ステップ２８０２で、再実行ツール２６０１はジョブ管理サービスサーバー群１２０２に対して、ステップ２８０１で読み込んだジョブＩＤに対応するジョブのステータス１７０５の確認を実施する。ステップ２８０２で確認したステータス１７０５が「エラー発生（２）」の場合には、ステップ２８０３が実行され、「エラー発生（２）」以外の場合にはフローを終了する。

ステップ２８０３では、ステップ２８０１で読み込んだジョブＩＤに対応するジョブの状態をリセットする。すなわち再実行ツール２６０１は該ジョブに関して、タスクの試行回数１７１０を０にリセットし、最終状態通知時刻１７０９を現在時刻に、ステータス１７０５を処理待ち（０）に、それぞれ変更する。これら図２８の一連の流れにより、再実行ツール２６０１は、図２１のテーブルにおける指定されたジョブＩＤに対応するレコードのステータス１７０５を処理待ち（０）に、タスクの試行回数１７１０とジョブの試行回数２１０１を０にする。図２１のテーブルがリセットされた状態になると、タスクサーバー１０４は図１１のフローチャートにおいて、Ｓ１１２２から中断されていたジョブのジョブ処理が再開される。

以上のように実施例３では、システム管理者が失敗したジョブＩＤを通知されれば、再実行ツール２６０１が、対象ジョブの発生イベントを再度発生させることなく、失敗ジョブを再度実行する状態にすることができる。

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

１０１スキャンサービスサーバー群
１０２フローサービスサーバー群
１０３１０４タスクサーバー
１０６クライアント端末
１０７画像形成装置
１０８クラウドサービスサーバー群

Claims

規定処理を実行する複数のタスクと通信可能であり、発生したジョブを前記規定処理が夫々異なる複数の前記タスクに順次処理を実行させることによりジョブ処理を実現するサーバーシステムであって、
前記タスクにより実行された前記規定処理が失敗したことに応じて前記タスクの試行回数をカウントし、カウントした前記タスクの試行回数が該試行回数に制限を設けるための最大試行回数を超えたことに応じて前記ジョブの試行回数をカウントするカウント手段と、
前記タスクが前記ジョブの取得を要求した際に、前記カウント手段によりカウントされたタスクの試行回数が前記最大試行回数を超えていない場合は通常ジョブを送信し、前記カウント手段によりカウントされたタスクの試行回数が前記最大試行回数を超えているが前記ジョブの試行回数が該試行回数に制限を設けるための最大試行回数を超えていない場合は、失敗ジョブを送信せずに前記ジョブ処理を始めからやり直すように制御するジョブ管理手段と、
前記タスクは、前記ジョブ管理手段から前記通常ジョブが送信された場合、前記規定処理を実行し、前記ジョブ管理手段から前記失敗ジョブが送信された場合、前記規定処理に対応する後処理を実行するジョブ実行手段と、
を有することを特徴とするサーバーシステム。
前記ジョブ管理手段は、
前記カウント手段によりカウントされたタスクの試行回数が該試行回数に制限を設けるための最大試行回数を超え、かつ前記ジョブの試行回数が該試行回数に制限を設けるための最大試行回数を超えた場合に前記失敗ジョブを送信することを特徴とする請求項１に記載のサーバーシステム。
前記ジョブ管理手段は、
前記カウント手段によりカウントされたタスクの試行回数が該試行回数に制限を設けるための最大試行回数を超え、かつ前記ジョブの試行回数が該試行回数に制限を設けるための最大試行回数を超えたことにより中断されたジョブ処理に対し再試行が指定された場合、該ジョブの試行回数、および該タスクの試行回数をリセットし前記ジョブ処理を始めからやり直すように制御することを特徴とする請求項１または２に記載のサーバーシステム。
前記後処理とは、
エラーログの出力処理、およびエラーメールの通知処理、およびエラーステータスを表示するステータス表示処理の内の少なくとも１つの処理であることを特徴とする請求項１乃至３の何れか１項に記載のサーバーシステム。
前記ジョブとは、
画像形成装置にてスキャンされたことにより生成された画像データに対し画像処理を施し、該画像処理が施された画像データを外部サーバーシステムに送信する送信処理を実行するためのジョブであることを特徴とする請求項１乃至４の何れか１項に記載のサーバーシステム。
前記規定処理とは、
前記画像データに対し画像処理、および該画像処理が施された画像データを前記外部サーバーシステムに送信する送信処理を含む処理の内の少なくとも１つの処理であることを特徴とする請求項５に記載のサーバーシステム。
規定処理を実行する複数のタスクと通信可能であり、発生したジョブを前記規定処理が夫々異なる複数の前記タスクに順次処理を実行させることによりジョブ処理を実現するサーバーシステムを制御する制御方法であって、
前記タスクにより実行された前記規定処理が失敗したことに応じて前記タスクの試行回数をカウントし、カウントした前記タスクの試行回数が該試行回数に制限を設けるための最大試行回数を超えたことに応じて前記ジョブの試行回数をカウントするカウントステップと、
前記タスクが前記ジョブの取得を要求した際に、前記カウントステップによりカウントされたタスクの試行回数が前記最大試行回数を超えていない場合は通常ジョブを送信し、前記カウントステップによりカウントされたタスクの試行回数が前記最大試行回数を超えているがジョブの試行回数が該試行回数に制限を設けるための最大試行回数を超えていない場合は、失敗ジョブを送信せずに前記ジョブ処理を始めからやり直すように制御するジョブ管理ステップと、
前記タスクは、前記ジョブ管理ステップから前記通常ジョブが送信された場合、前記規定処理を実行し、前記ジョブ管理ステップから前記失敗ジョブが送信された場合、前記規定処理に対応する後処理を実行するジョブ実行ステップと、
を有することを特徴とする制御方法。
前記ジョブ管理ステップは、
前記カウントステップによりカウントされたタスクの試行回数が該試行回数に制限を設けるための最大試行回数を超え、かつ前記ジョブの試行回数が該試行回数に制限を設けるための最大試行回数を超えた場合に前記失敗ジョブを送信することを特徴とする請求項７に記載の制御方法。
前記ジョブ管理ステップは、
前記カウントステップによりカウントされたタスクの試行回数が該試行回数に制限を設けるための最大試行回数を超え、かつ前記ジョブの試行回数が該試行回数に制限を設けるための最大試行回数を超えたことにより中断されたジョブ処理に対し再試行が指定された場合、該ジョブの試行回数、および該タスクの試行回数をリセットし前記ジョブ処理を始めからやり直すように制御することを特徴とする請求項７または８に記載の制御方法。
前記後処理とは、
エラーログの出力処理、およびエラーメールの通知処理、およびエラーステータスを表示するステータス表示処理の内の少なくとも１つの処理であることを特徴とする請求項７乃至９の何れか１項に記載の制御方法。
前記ジョブとは、
画像形成装置にてスキャンされたことにより生成された画像データに対し画像処理を施し、該画像処理が施された画像データを外部サーバーシステムに送信する送信処理を実行するためのジョブであることを特徴とする請求項７乃至１０の何れか１項に記載の制御方法。
前記規定処理とは、
前記画像データに対し画像処理、および該画像処理が施された画像データを前記外部サーバーシステムに送信する送信処理を含む処理の内の少なくとも１つの処理であることを特徴とする請求項１１に記載の制御方法。
請求項７乃至１２の何れか１項に記載の制御方法をサーバーシステムに実行させるためのプログラム。