(57)【要約】【課題】  シャットダウンを延期することで、誤って外部情報処理装置にデータを送信する可能性を低下させることを目的とする。【解決手段】  ジョブに関するジョブ情報を取得して、ジョブ情報に基づいてタスクを実行して、シャットダウンイベントを受信した場合に、実行されるタスクが外部情報処理装置にデータを送信する送信タスクであると判断した場合に、シャットダウンを延期する。【選択図】  図９
2015005203.tif 000002
【特許請求の範囲】
【請求項１】
ジョブに関するジョブ情報を取得する取得手段と、
前記ジョブ情報に基づいてタスクを実行する実行手段と、
シャットダウンイベントを受信する受信手段と、
前記受信手段が前記シャットダウンイベントを受信した場合に、前記実行手段によって実行される前記タスクが外部情報処理装置にデータを送信する送信タスクであるか否かを判断する判断手段と、
前記判断手段が前記実行手段によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断した場合にシャットダウンを延期する延期手段と、を有することを特徴とする情報処理装置。
【請求項２】
前記延期手段は前記実行手段によって実行される前記タスクが完了するまで前記シャットダウンを延期することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記実行手段によって実行されている前記タスクが存在するか否かを判断する第２の判断手段と、を有し、
前記第２の判断手段が前記実行手段によって実行されている前記タスクは存在しないと判断した場合に前記延期手段は前記シャットダウンを延期しないことを特徴とする請求項１又は請求項２に記載の情報処理装置。
【請求項４】
前記実行手段は前記タスクの実行に失敗した場合に所定のリトライ回数まで前記タスクの実行をリトライして、
前記受信手段が前記シャットダウンイベントを受信した場合に、前記実行手段は前記タスクの実行に失敗した場合にリトライカウントを上げないことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記実行手段は前記ジョブに基づいて前記タスクを連結して実行することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記判断手段は、前記実行手段によって実行される前記タスクが前記外部情報処理装置に前記データを送信した場合に、前記実行手段によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
前記実行手段によって実行されている前記タスクの種別を取得する第２の取得手段と、を有し、
前記判断手段は、前記第２の取得手段によって取得された前記タスクの種別が前記送信タスクである場合に、前記実行手段によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項８】
前記実行手段によって実行されている前記タスクの残り処理時間が所定時間以内であるか否かを判断する第３の判断手段と、を有し、
前記延期手段は、前記判断手段が前記実行手段によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクではないと判断して、かつ前記判断手段が前記実行手段によって実行される前記タスクの残り処理時間が所定時間以内である判断した場合にシャットダウンを延期することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項９】
コンピュータに、
ジョブに関するジョブ情報を取得する取得工程と、
前記ジョブ情報に基づいてタスクを実行する実行工程と、
シャットダウンイベントを受信する受信工程と、
前記受信工程で前記シャットダウンイベントを受信した場合に、前記実行工程によって実行される前記タスクが外部情報処理装置にデータを送信する送信タスクであるか否かを判断する判断工程と、
前記判断工程で前記実行工程によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断した場合にシャットダウンを延期する延期工程と、を実行させることを特徴とするプログラム。
【請求項１０】
前記コンピュータに、
前記延期工程は前記実行工程によって実行される前記タスクが完了するまで前記シャットダウンを延期することを特徴とする請求項９に記載のプログラム。
【請求項１１】
前記コンピュータに、
前記実行工程によって実行されている前記タスクが存在するか否かを判断する第２の判断工程と、を実行させ、
前記第２の判断工程で前記実行工程によって実行されている前記タスクは存在しないと判断した場合に前記延期工程は前記シャットダウンを延期しないことを特徴とする請求項９又は請求項１０に記載のプログラム。
【請求項１２】
前記実行工程は前記タスクの実行に失敗した場合に所定のリトライ回数まで前記タスクの実行をリトライして、
前記受信工程で前記シャットダウンイベントを受信した場合に、前記実行工程は前記タスクの実行に失敗した場合にリトライカウントを上げないことを特徴とする請求項９乃至１１のいずれか１項に記載のプログラム。
【請求項１３】
前記実行工程は前記ジョブに基づいて前記タスクを連結して実行することを特徴とする請求項９乃至１２のいずれか１項に記載のプログラム。
【請求項１４】
前記コンピュータに、
前記判断工程は、前記実行工程によって実行される前記タスクが前記外部情報処理装置に前記データを送信した場合に、前記実行工程によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断することを特徴とする請求項９乃至１３のいずれか１項に記載のプログラム。
【請求項１５】
前記コンピュータに、
前記実行工程によって実行されている前記タスクの種別を取得する第２の取得工程と、を実行させ、
前記判断工程は、前記第２の取得工程によって取得された前記タスクの種別が前記送信タスクである場合に、前記実行工程によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断することを特徴とする請求項９乃至１３のいずれか１項に記載のプログラム。
【請求項１６】
前記コンピュータに、
前記実行工程によって実行されている前記タスクの残り処理時間が所定時間以内であるか否かを判断する第３の判断工程と、を実行させ、
前記延期工程は、前記判断工程で前記実行工程によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクではないと判断して、かつ前記判断工程で前記実行工程によって実行される前記タスクの残り処理時間が所定時間以内である判断した場合にシャットダウンを延期することを特徴とする請求項９乃至１４のいずれか１項に記載のプログラム。
【請求項１７】
ジョブに関するジョブ情報を取得する取得工程と、
前記ジョブ情報に基づいてタスクを実行する実行工程と、
シャットダウンイベントを受信する受信工程と、
前記受信工程で前記シャットダウンイベントを受信した場合に、前記実行工程によって実行される前記タスクが外部情報処理装置にデータを送信する送信タスクであるか否かを判断する判断工程と、
前記判断工程で前記実行工程によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断した場合にシャットダウンを延期する延期工程と、を有することを特徴とする制御方法。
【請求項１８】
ジョブに関するジョブ情報を取得する取得手段と、
前記ジョブ情報に基づいてタスクを実行する実行手段と、
シャットダウンイベントを受信する受信手段と、
前記受信手段が前記シャットダウンイベントを受信した場合に、前記実行手段によって実行される前記タスクが外部情報処理装置にデータを送信する送信タスクであるか否かを判断する判断手段と、
前記判断手段が前記実行手段によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断した場合にシャットダウンを延期する延期手段と、を有することを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はタスクを実行する情報処理装置及びプログラム、制御方法、システムに関する。
【背景技術】
【０００２】
近年、サーバーコンピューター側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）という技術が利用され始めている。
【０００３】
クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ変換やデータ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。また、クラウドコンピューティングの特徴を活用するため、サーバーでの一連の処理を細かく規定されたタスクの連結で実現し、それらを同時並行で処理することで、多数の処理をスケーラブルに処理する技術が存在する。タスクの連結によって実現される一連の処理のことを、ジョブと呼ぶ。例えば、画像の鮮鋭化を行うタスク、外部のクラウドサービスにデータを格納するタスク、メールを送信するタスクなどがある。また、例えば上記の画像の鮮鋭化を行った後、外部のクラウドサービスにデータを格納するタスクがある。上記のタスクは仮想化されたサーバーコンピューター（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ、ＶＭ）上で動作するタスクプロセスにより実行される。本明細書ではこのようなシステムをクラウドシステムと称する。
【０００４】
非特許文献１はクラウドシステムにおいて、コンピューターリソースのスケーラビリティ向上に関する内容や、プロセスがメッセージからキューを取得する技術を開示している。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Ｗｉｎｄｏｗｓ（登録商標）  Ａｚｕｒｅ  Ｑｕｅｕｅ−キューストレージのプログラミング  ｈｔｔｐ：／／ｇｏ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／？ｌｉｎｋｉｄ＝９７３４５８８（２０１３年６月３日検索）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
クラウドシステムにおいても、サーバーなどの情報処理装置あるいは情報処理装置で実行されるＶＭがシャットダウンされる可能性がある。例えばＯＳ（オペレーションシステム）のバージョンアップや、ハードウェアの電源断、ＶＭ上の何らかのプロセスの異常などが原因として考えられる。具体的な事例としてはタスクプロセスが動作しているＶＭが不定期にシャットダウンや再起動を起こす場合が挙げられる。このような問題は非特許文献１についても生じる可能性がある。
【０００７】
しかしながら、従来から知られているクラウドシステムなどを司る情報処理装置あるいは情報処理装置で実行されるＶＭでは次の問題が生じる可能性があった。例えば、タスクの実行途中でシャットダウンが発生し、再起動後に再度同じタスクを実行（リトライ）するケースを考える。このケースで実行途中だったタスクが外部情報処理装置にデータを送信していた場合、外部情報処理装置にもう一度データを送信する問題が生じる。例えば、外部のクラウドサービスにデータを保存するタスクやメールを送信するタスクなどは外部情報処理装置にデータを送信するタスクである。このように、外部情報処理装置にデータの送信を複数回行うと、ユーザーに意図しない結果をもたらす可能性がある。例えば、外部のシステムにユーザーデータが二重に登録されることや、メールが二度送信されることが想定される。上記の結果は、ユーザーに対して混乱を与えるだけでなく、誤った課金を発生させることが想定される。
【０００８】
そこで、本明細書では、シャットダウンを延期することで、誤って外部情報処理装置にデータを送信する可能性を低下させることを目的とする。
【課題を解決するための手段】
【０００９】
上記の目的を達成するための本発明に係る情報処理装置は、
ジョブに関するジョブ情報を取得する取得手段と、
前記ジョブ情報に基づいてタスクを実行する実行手段と、
シャットダウンイベントを受信する受信手段と、
前記受信手段が前記シャットダウンイベントを受信した場合に、前記実行手段によって実行される前記タスクが外部情報処理装置にデータを送信する送信タスクであるか否かを判断する判断手段と、
前記判断手段が前記実行手段によって実行される前記タスクは前記外部情報処理装置に前記データを送信する前記送信タスクであると判断した場合にシャットダウンを延期する延期手段と、を有することを特徴とする。
【発明の効果】
【００１０】
本発明によると、シャットダウンを延期することで、誤って外部情報処理装置にデータを送信する可能性を低下させることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施例１におけるクラウドシステムの全体構成を示す図である。
【図２】本発明の実施例１におけるクライアント端末、サーバーコンピューターのハードウェア構成図である。
【図３】本発明の実施例１におけるルート管理サービスサーバー群にて保持するタスク情報の一例である。
【図４】本発明の実施例１における画像形成装置の内部構成の詳細を示す図である。
【図５】本発明の実施例１におけるスキャンサービスサーバー群のシステム構成図である。
【図６】本発明の実施例１におけるジョブ管理サービスサーバー群のシステム構成図である。
【図７】本発明の実施例１におけるジョブ管理サービスサーバー群にて保持するジョブ情報の一例である。
【図８】本発明の実施例１におけるジョブ管理サービスサーバー群が実施する、タスクサーバーへのタスク応答に関するフローチャートである。
【図９】本発明の実施例１におけるタスクサーバー１０３及び１０４のオペレーションシステムにシャットダウンイベントが発生した際の処理フローに関するフローチャートである。
【図１０】本発明の実施例１におけるタスクサーバーのシステム構成図である。
【図１１】本発明の実施例１におけるスキャン処理の一連の流れを示すシーケンス図である。
【図１２】本発明の実施例１におけるフローサービスサーバー群のシステム構成図の概要である。
【図１３】本発明の実施例２におけるタスクサーバー１０３及び１０４のオペレーションシステムにシャットダウンイベントが発生した際の処理フローに関するフローチャートである。
【図１４】本発明の実施例３におけるタスクサーバー１０３及び１０４のオペレーションシステムにシャットダウンイベントが発生した際の処理フローに関するフローチャートである。
【発明を実施するための形態】
【００１２】
（実施例１）
図１は、本発明の実施の形態に係るクラウドシステムの全体構成を示す図である。
【００１３】
図１において、スキャンサービスサーバー群１０１、フローサービスサーバー群１０２、タスクサーバー１０３及び１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバー群１０８は、ネットワーク１１０〜１１２を介して接続されている。図１において、タスクサーバー１０３及び１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバー群１０８は、複数台接続されていることを仮定している。ネットワーク１１０〜１１２は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれであり。またはこれらの組み合わせにより実現される、いわゆる通信ネットワークである。ネットワーク１１０〜１１２は、データの送受信が可能であればよい。本明細書ではネットワーク１１０及び１１２はインターネット、ネットワーク１１１は企業内ネットワークやサービスプロバイダーのネットワークである。スキャンサービスサーバー群１０１、フローサービスサーバー群１０２、タスクサーバー１０３及び１０４は、サーバーコンピューター上にて仮想サーバーによって実現されており、これらサービスサーバー群がユーザーに対してクラウドサービスを提供する。なお、タスクサーバー１０３及び１０４は両サーバーを単一の仮想サーバーによって実現しても構わないし、複数の仮想サーバーによって実現しても構わない。また、クラウドサービスサーバー群１０８はインターネット上に公開されており、クラウドサービスサーバー群１０８もサーバーコンピューター上にて実行されている。
【００１４】
以降、本明細書で説明するサーバーのそれぞれの機能は単体のサーバー又は単体の仮想サーバーによって実現しても構わないし、あるいは複数のサーバーや複数の仮想サーバーによって実現しても構わない。あるいは複数のサーバーが仮想サーバーとして単体のサーバー上で実行されても構わない。
【００１５】
クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、パーソナルデータアシスタント（ＰＤＡ）等から成るが、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。
【００１６】
図２（Ａ）は、本発明の実施形態に係るクライアント端末１０６、各サービスサーバー１０１〜１０４、クラウドサービスサーバー群１０８の各サーバー（情報処理装置）のハードウェア構成図である。
【００１７】
図２（Ａ）において、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）２０２は装置全体の制御を行う。ＣＰＵ２０２はＨａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、Ｒａｎｄａｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）２０３にプログラムの実行に必要な情報、データを含むファイル等を一時的に格納する制御を行う。Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）２０４は記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービスサーバー群のプログラム、ＯＳ、関連プログラム等を格納している。ディスプレイ２０６は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インターフェース２０８は外部装置Ｉ／Ｆであり、プリンター、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司るものである。Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ（ＮＩＣ）２０９は、該インターフェース２０９、ネットワーク１１０〜１１２を介して外部装置とのデータのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２（Ａ）の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。
【００１８】
加えて、ＣＰＵ２０２がＨＤＤ２０５に記憶されているプログラムに基づき処理を実行することによって、図５等に示されるようなソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。
【００１９】
図２（Ｂ）は、本発明の実施形態に係るクライアント端末１０６のソフトウェア構成図である。図２（Ｂ）において、Ｗｅｂブラウザ３０１を利用し、スキャンサービスサーバー群１０１が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザーはクライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドサービスを利用する。
【００２０】
図４は、本発明の実施形態に係る画像形成装置１０７のハードウェア構成を例示するブロック図である。本実施例ではスキャン・プリントの両機能を併せ持つ装置を例にするが、スキャンサービスを実現するに当たっては、プリント機能のない、スキャン専用装置でも良い。
【００２１】
図４において、画像形成装置１０７は、画像処理ユニット４０１、印刷ユニット４０２、およびスキャンユニット４０３から構成される。画像処理ユニット４０１は、ＣＰＵ４０４、直接記憶部４０５、間接記憶部４０６、ユーザーインターフェース４０７、外部インターフェース４０８から構成されている。
【００２２】
ＣＰＵ４０４は、所定のプログラムを実行し、画像形成装置１０７の各種制御を指示するユニットである。直接記憶部４０５は、ＣＰＵ４０４がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ４０４が実行するプログラムは直接記憶部４０５にロードされる。直接記憶部４０５は、ＲＡＭにより実現される。間接記憶部４０６は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部４０６に記憶されている各種プログラムは、ＣＰＵ４０４がプログラムを実行する際に直接記憶部４０５へ移動する。間接記憶部４０６は、Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ（ＳＳＤ）、または、ＨＤＤにより実現される。なお、ＣＰＵ４０４はマルチプロセッサでも良い。
【００２３】
ここで、プラットフォームプログラムによって実現されるプラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置１０７上で実行できる他、画像形成装置１０７の操作画面をカスタマイズすることが可能になる。
【００２４】
プラットフォームの実現方法について説明する。ＣＰＵ４０４は、間接記憶部４０６に記憶されたプラットフォームプログラムを直接記憶部４０５に移動する。移動が完了するとＣＰＵ４０４は、プラットフォームプログラム（例えば、Ｊａｖａ（登録商標））を実行することができる状態になる。本発明の実施例では、ＣＰＵ４０４がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０７のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。
【００２５】
プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本発明の実施例において、プラットフォーム上には、スキャンした画像をクラウドサービスに送信するスキャンソフトウェアが動作している。スキャンソフトウェアは、ネットワークを介して接続されているスキャンサービスサーバー群１０１より、例えば、Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）と言った通信プロトコルによってスキャンチケットの一覧の受信を行う。スキャンチケットにはスキャンの為の設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。ユーザーはスキャンソフトウェア部にて表示されたスキャンチケット一覧より、スキャンチケットを選択し、原稿を読み込ませることでスキャンを完了できる。スキャンソフトウェア部はユーザーが選択したスキャンチケットの情報とスキャンした画像データを合わせてスキャンサービスサーバー群１０１に送信する。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０７の制御を実現することができる。
【００２６】
アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部４０６に記憶されたアプリケーションプログラムを直接記憶部４０５に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本発明の実施例ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例で開示するフローチャートの各処理の一部を行うことが可能である。
【００２７】
図４の説明に戻る。ユーザーインターフェース４０７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、タッチパネル、キーボード又はマウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース４０８は、外部装置からのデータ受信や外部装置へのデータ送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別筐体のホストコンピュータや画像形成装置等の別筐体の装置が含まれる。画像形成装置１０７は、ネットワーク１１０及び１１１を介して、クライアント端末１０６、スキャンサービスサーバー群１０１と通信可能である。
【００２８】
続いて、クラウドサービスを提供するスキャンサービスサーバー群１０１、タスクサーバー１０３及び１０４の各サービスサーバー群に関して説明する。
【００２９】
図５を用いて、スキャンサービスサーバー群１０１に関して説明する。スキャンサービスサーバー群１０１はクラウドサービスにおけるスキャン機能の提供を行うサービスサーバー群である。図５は、本発明の実施形態に係るスキャンサービスサーバー群１０１のソフトウェア構成図である。スキャンサービスサーバー群１０１は、Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ部５０２、テンプレート管理ＤＢ部５０３からなる。これら構成要素により各種処理が実行されることでスキャンサービスサーバー群１０１がユーザーに提供される。
【００３０】
Ｗｅｂアプリケーション部５０１はスキャン機能を提供するアプリケーションプログラムを提供する。チケット作成部５１１はユーザーがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットには、画像形成装置１０７で原稿をスキャンする際の設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメーター等が記録されている。
【００３１】
なお、本明細書でタスクとは処理内容を意味する。処理内容には後述する画像処理やデータ保存などが含まれる。
【００３２】
図１１にて、チケット作成部５１１は、クライアント端末１０６のＷｅｂブラウザ３０１からのスキャンチケット作成画面リクエストＳ１１０１を受け取り、スキャンチケット作成画面を生成しレスポンスＳ１１０２を行う。この際、チケット作成部５１１はテンプレート管理部５１６より、テンプレート管理ＤＢ部５０３に登録されているスキャンチケットのテンプレートを取得し、テンプレートに含まれるテンプレート名を、クライアント端末１０６のＷｅｂブラウザ３０１に表示する。
【００３３】
ユーザーがクライアント端末１０６のＷｅｂブラウザ３０１にて操作を行い、スキャンチケット作成リクエストＳ１１０３を行うと、スキャンチケット作成と、チケット管理部５１５への保存を依頼する。チケット管理部５１５は、チケット保存のリクエストを受け、チケット管理ＤＢ部５０２にチケット情報を保存する。チケット管理ＤＢ部５０２の詳細は後述する。チケット管理部５１５は、チケット情報を保存した後、レスポンスＳ１１０４を行う。
【００３４】
外部Ｉ／Ｆ５１４は画像形成装置１０７上で動作するスキャンソフトウェア部との通信を行う。スキャンソフトウェア部より、外部Ｉ／Ｆ５１４を通じて、チケット一覧部５１２の機能や、スキャン受信部５１３の機能へのアクセスを行う。図１１にて、画像形成装置１０７のスキャンソフトウェア部は外部Ｉ／Ｆ５１４を通じてチケット一覧部５１２に対して、チケット一覧取得Ｓ１１０５を行う。チケット一覧部５１２では、スキャンチケットの一覧をチケット管理部５１５より生成し、スキャンソフトウェア部にレスポンスＳ１１０６を返す。レスポンスを受け取った画像形成装置１０７は、取得したチケット一覧を図４におけるユーザーインターフェース４０７上に表示する。
【００３５】
図１１のスキャン処理Ｓ１１０７にて、ユーザーは、ユーザーインターフェース４０７上に表示されたチケットのいずれかを選択し、画像形成装置に備え付けられたスキャン装置に紙を設置し、スキャン実行する。これにより、スキャンソフトウェア部は、スキャン送信Ｓ１１０８にて、外部Ｉ／Ｆ５１４を通じてスキャン受信部５１３に対して、スキャンした画像データとスキャンチケットの送信を行う。
【００３６】
スキャン受信部５１３は、送信されたスキャンチケット、および画像データを受信する。スキャン受信部５１３はステップＳ１１０９にて、受信した画像データを、フローサービスサーバー群１０２に投入する。フローサービスサーバー群１０２は、画像データを正しく受信できた場合には、スキャンサービスサーバー群１０１に、画像データを一意に表すＩＤ（ファイルグループＩＤ）を応答する。その後、スキャン受信部５１３は、ジョブ投入リクエストＳ１１１１にて、ファイルグループＩＤ、およびスキャンチケットをフローサービスサーバー群１０２に送信する。
【００３７】
以上がスキャンサービスサーバー群１０１のシステム構成と、スキャンジョブの投入までの流れである。
【００３８】
引き続き、図１０にて、本発明の実施形態に係るタスクサーバー１０３及び１０４のソフトウェア構成図を説明する。タスクサーバー１０３はタスクプロセス１０１０で、タスクサーバー１０４はタスクプロセス１０１１で構成される。
【００３９】
タスクプロセス１０１０、１０１１は、スキャンサービスを実現するための要素機能を実現する実行プロセスである。タスクプロセス１０１０、１０１１は常駐の実行プロセスとして、ジョブ管理サービスサーバー群１２０２と定期的に通信を行い、処理すべきタスクが存在すれば、処理を実行する。タスクプロセス１０１０、１０１１は、タスクサーバー１０３上でサーバーリソースに余裕がある限り、任意の数起動させることができる。
【００４０】
タスクプロセス１０１０、１０１１は、タスク実行スレッド１０２０、タスク基本スレッド１０３０で構成される。タスクプロセス１０１１のタスク実行スレッド１０２０及びタスク基本スレッド１０３０についてはタスクプロセス１０１０のタスク実行スレッド１０２０及びタスク基本スレッド１０３０と同一の構成である。よって、図１０中ではタスクプロセス１０１１のタスク実行スレッド１０２０及びタスク基本スレッド１０３０の詳細な構成は省略している。タスク実行スレッド１０２０は、後述のタスク処理を実行する実体である。
【００４１】
さらに、タスク実行スレッド１０２０は、データ取得１０２２及びデータ保存１０２３、内部変数で構成される。本実施例においては、タスクプロセス１０１０はタスク処理として、画像データに対してＯＣＲ処理を行いＯＣＲ結果のテキストデータを画像データに埋め込む処理を行う。他にタスク処理には、例えば、画像データ対して画像処理を行う処理、ファイル共有機能を提供するような他のクラウドサービスサーバー群１０８に対して、画像データを送信する処理が存在する。また、タスクプロセス１０１１はタスク処理として、クラウドサービスサーバー群１０８の中のストレージ機能を提供する特定のサービスに対して、画像データをアップロードし保管する処理を行う。データ取得１０２２は、タスク実行スレッド１０２０が、一時ファイル管理サービスサーバー群１２０３からデータを取得するためのインターフェースである。また、データ保存１０２３はタスク実行スレッド１０２０が、一時ファイル管理サービスサーバー群１２０３にデータを保存するためのインターフェースである。なお、内部変数は外部影響情報１０２４及び処理残り時間１０２５を含む。外部影響情報１０２４及び処理残り時間１０２５については図９の説明以降で詳しく説明する。
【００４２】
タスク基本スレッド１０３０は、タスク取得１０３１、タスクステータス通知１０３２で構成される。タスク取得１０３１は、ジョブ管理サービスサーバー群１２０２から処理対象のタスクを取得するためのインターフェースである。タスク取得１０３１は、ジョブ管理サービスサーバー群１２０２に対して、タスク実行スレッド１０２０の処理中にタスクプロセス１０１０、１０１１のステータスを通知するためのインターフェースである。また、タスクサーバー１０３のタスク基本スレッド１０３０の処理内容とタスクサーバー１０４のタスク基本スレッド１０３０の処理内容は同一である。すなわち、タスク基本スレッド１０３０によってタスクサーバー１０３とタスクサーバー１０４は共通してジョブ管理サービスサーバー群１２０２に処理を行うことができる。
【００４３】
以下、図１１のスキャン処理のシーケンス図の流れとともに各構成要素の説明を行う。
【００４４】
タスクサーバー１０３及び１０４のタスク取得１０３１は、ステップＳ１１１２及びＳ１１２０にて、定期的にフローサービスサーバー群１０２に問い合わせを行い、各タスクサーバー１０３及び１０４にて処理可能なタスクを取得する。フローサービスサーバー群１０２の各タスクサーバー１０３及び１０４への応答に関する詳細なフローは、図８を用いて後述する。
【００４５】
タスクサーバー１０３及び１０４のデータ取得１０２２は、タスク取得１０３１で取得した情報を元に、タスク実行スレッド１０２０を起動し、データ取得１０２２によってステップＳ１１１４及びＳ１１１５、Ｓ１１２１、Ｓ１１２２にてフローサービスサーバー群１０２より処理すべき画像データの取得を行う。
【００４６】
タスクサーバー１０３及び１０４のタスク処理は、ステップＳ１１１６又はＳ１１２４にて取得した画像データに対してタスク処理を実行する。
【００４７】
タスクサーバー１０３及び１０４のタスクステータス通知１０３２は、Ｓ１１１７又はＳ１１２５にてタスクステータス通知１０３２を介して定期的にフローサービスサーバー群１０２に状態通知を行う。
【００４８】
タスクサーバー１０３のタスク実行スレッド１０２０は、ステップＳ１１１６での処理結果をステップＳ１１１８にてデータ保存１０２３を通して、フローサービスサーバー群１０２に保存する。
【００４９】
タスクサーバー１０４のタスク実行スレッド１０２０は、ステップＳ１１２４での処理結果をステップＳ１１２６にてクラウドサービスサーバー群１０８にデータ送信する。
【００５０】
タスクサーバー１０３及び１０４のタスクステータス通知１０３２は一連のタスク処理の終了結果をステップＳ１１１９及びＳ１１２７にて、フローサービスサーバー群１０２に通知する。このとき、フローサービスサーバー群１０２は、上述の終了結果が正常終了であれば、ジョブを次のタスクの処理対象とする、もしくは一連のジョブにおける最後のタスクであればジョブを完了とする。終了結果が異常終了であれば、もう一度タスクサーバー１０３及び１０４の処理対象とするため、Ｓ１１１２又はＳ１１２０以降の処理が再度実行される。
【００５１】
図１１の処理において問題となるのはＳ１１１６及びＳ１１２４のタスク処理の実行中にタスクサーバー１０４にシャットダウンイベントが発生した際に、特にＳ１１２６のデータ送信処理が再度行われてしまうことである。本課題を解決するためのシャットダウン時の処理については、図９を用いて後述する。
【００５２】
なお、シャットダウンイベントはタスクサーバー１０３及び１０４の各仮想サーバーに対して発生する。通常、タスクサーバー１０３及び１０４はシャットダウンイベントが発生次第速やかに停止（シャットダウン）する。
【００５３】
以上で、スキャンジョブの一連の処理が完了する。
【００５４】
続いて、フローサービスサーバー群１０２の詳細な説明を行う。フローサービスサーバー群１０２はルート管理、ジョブ管理、一時ファイル管理を行うサービスサーバー群である。
【００５５】
図１２は、フローサービスサーバー群１０２のシステム構成の概要である。
【００５６】
フローサービスサーバー群１０２は、ルート管理サービスサーバー群１２０１及びジョブ管理サービスサーバー群１２０２、一時ファイル管理サービスサーバー群１２０３の各サーバーからなる。これらサーバー上により各種処理が実行されることで各サービスサーバー群が提供され、それらが連携することで、フローサービスサーバー群１０２がユーザーに提供される。
【００５７】
ルート管理サービスサーバー群１２０１はタスクとタスクを連結させたルートの情報を管理する。ルートの情報にはどのタスクの処理の次にどのタスクの処理を行うのかが記載されている。ジョブ管理サービスサーバー群１２０２はルートの情報に基づきジョブの処理を管理する。一時ファイル管理サービスサーバー群１２０３はジョブ投入時のデータや各タスクの処理結果データの保存を管理する。
【００５８】
引き続きフローサービスサーバー群１０２を構成するルート管理サービスサーバー群１２０１、ジョブ管理サービスサーバー群１２０２、一時ファイル管理サービスサーバー群１２０３の詳細な説明を行う。
【００５９】
図３にて、ルート管理サービスサーバー群１２０１で管理されている情報の一例を示す。タスクＩＤ１５０１がタスクを一意に識別するＩＤである。タスク名１５０２はそのタスクの名前である。中止時間１５０３はジョブ管理サービスサーバー群１２０２がタスクサーバー１０３又は１０４の処理を中止するまでの時間である。中止時間１５０３で示される時間以上、タスクサーバー１０３又は１０４が実行状態だった場合、ジョブ管理サービスサーバー群はタスクサーバーに異常が発生したと判断して他のタスクサーバー１０３又は１０４へジョブを委譲する。タスクサーバー１０３及び１０４は、ハードウェア故障やソフトウェアバグによる障害などの発生や、ネットワーク切断などにより通信できない場合がある。さらに、例えば画像処理や外部クラウドへの保存処理など、処理対象のデータが巨大な場合にもタスクサーバー１０３又は１０４は長時間実行状態となる。このような場合も、異常が発生したと判断される。
【００６０】
タスク種別１５０４は、タスクの種別を表わす識別子である。本実施例においては、タスク種別が“ｉｎｐｕｔ”のタスクは、スキャンサービスの実現に必要な入力ファイルを取得するタスクであることを示す。タスク種別が“ｐｉｐｅ”のタスクは、フローサービスサーバー群１０２から取得した入力ファイルに対して、何らかの処理を行い、再びフローサービスサーバー群１０２に格納するタスクであることを示す。タスク種別が“ｏｕｔｐｕｔ”のタスクは、フローサービスサーバー群１０２から取得したファイルを外部のクラウドサービスに転送する、プリントアウトするなどの出力を行うタスクであることを示す。
【００６１】
図６を用いて、ジョブ管理サービスサーバー群１２０２に関して説明する。ジョブ管理サービスサーバー群１２０２は、タスクサーバー１０３及び１０４からのリクエストに対してタスク情報の授受や、各タスクの状態を管理するためのサービスサーバー群である。
【００６２】
外部Ｉ／Ｆ１６０１は、タスクサーバー１０３及び１０４、画像形成装置１０７との通信を行う。外部Ｉ／Ｆ１６０１を通じて、ジョブ管理サービスサーバー群１２０２の各機能へのアクセスを行う。ジョブ情報管理ＤＢ部１６０２には、作成された各ジョブのステータスや、各ジョブが扱うデータのＩＤが保存される。ジョブ情報管理ＤＢ部１６０２の詳細な内容は図７を用いて後述する。ジョブ追加部１６０３は、スキャンサービスサーバー群１０１が、図１１において、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ投入リクエストＳ１１１１を受け、ジョブ情報管理ＤＢ部１６０２にジョブ情報を格納する。
【００６３】
ここで、ジョブ情報とは、ジョブに関する情報であり、図７に示されるジョブ情報管理ＤＢ部１６０２に存在する各カラム（１７０１〜１７０７）から構成される。
【００６４】
ジョブ情報取得部１６０４は、タスクサーバー１０３及び１０４から外部Ｉ／Ｆ１６０１を通じて発行されるタスク取得リクエストＳ１１１０を受け、ジョブ情報管理ＤＢ部１６０２からジョブ情報を取得する。ここで取得したジョブ情報は、タスク取得Ｓ１１１２にてタスクサーバー１０３及び１０４に渡される。ジョブ情報の受け渡しに関わる詳細な説明は図８を用いて後述する。ジョブ情報更新部１６０５は、結果通知Ｓ１１１９にて、タスクサーバー１０３及び１０４から、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ情報更新リクエストを受け、ジョブ情報管理ＤＢ部１６０２の該ジョブの情報を更新する。ここで、更新される情報は、カレントタスクＩＤ１７０４及びステータス１７０５、最終更新時刻１７０６である。カレントタスクＩＤ１７０４を更新する前には、ルート管理サービスサーバー群１２０１の外部Ｉ／Ｆ１３０３を通じて、ルート情報管理ＤＢ部１３０１から、前述のルートの情報における次のタスクＩＤを取得する。取得したタスクＩＤを以て、カレントタスクＩＤ１７０４を更新する。また、ステータス１７０５は０、最終更新時刻１７０６は取得した時刻で更新する。ジョブ状態通知部１６０６は、状態通知Ｓ１１１７及びＳ１１２５にて、タスクサーバー１０３及び１０４から外部Ｉ／Ｆ１６０１を通じて発行される状態通知リクエストを受け付ける。
【００６５】
続いて、図７を用いて、ジョブ情報管理ＤＢ部１６０２に保持されるデータについて説明する。ジョブＩＤ１７０１は、各ジョブ情報に一意に割り当てられるＩＤである。ファイルグループＩＤ１７０３は、一時ファイル管理サービスサーバー群１２０３から発行されるＩＤである。カレントタスクＩＤ１７０４は、そのジョブにおいて処理を行うべきタスクを示すタスクＩＤである。タスクサーバー１０３及び１０４は、このカレントタスクＩＤ１７０４を確認し、自タスクサーバーに割り当てられたタスクＩＤと等しい行を選択し処理を行う。本ＩＤは、該タスクの処理が完了した際には、ジョブ情報更新部１６０５が、前述のルートの情報における次のタスクのタスクＩＤに更新する。ステータス１７０５には、処理待ち（０）、実行中（１）、エラー発生（２）を表す値が設定される。タスクサーバー１０３及び１０４がジョブを選択する際には、ステータスが０となっている行を選択する。これにより、複数のタスクサーバーが同一のタスクを処理するといった事態を防ぐことができる。タスクサーバー１０３及び１０４が、ジョブを選択した後に、タスクサーバー１０３及び１０４は、外部Ｉ／Ｆ１６０１を通じて、ジョブ情報更新部１６０５より、ステータス１７０５を１に変更する。最終更新時刻１７０６は、タスクサーバー１０３及び１０４が該ジョブに対して、何らかの処理を実行した際に、更新される。ここで、何らかの処理とは、ステータスの更新処理や、ジョブの取得処理である。タスクサーバー１０３及び１０４がジョブを取得する際に、自タスクＩＤと等しいジョブ情報が複数存在していた場合には、最終更新時刻１７０６が最も古いジョブを選択する。これにより、全てのジョブを平均的に処理することが可能となる。パラメーター１７０７には、詳細設定画面６０５にて設定した設定情報や、タスクサーバー１０３及び１０４が、他のタスクサーバー１０３及び１０４に渡す設定情報などを記載する。タイムスタンプ１７０８は、ジョブ情報が更新されるたびに自動的に更新される値である。タスクサーバー１０３及び１０４の、ジョブ情報更新部１６０５や、ジョブ状態通知部１６０６への通信の際に、タイムスタンプを受け渡すことで、他のタスクサーバー１０３及び１０４にジョブが委譲されていないことを保証できる。
【００６６】
なお本明細書では、ジョブはタスクを確実に実行するために、一度実行が失敗した後にリトライが行われる。リトライの回数（リトライ回数）を管理するためにリトライカウント１７０９が用意されている。リトライカウント１７０９は、ジョブがリトライされた回数を示す。タスクサーバー１０３及び１０４はタスクの処理に失敗すると失敗することを示す通知を行う。その際、ジョブ管理サービスサーバー群１２０２は直ちにステータス１７０５をエラー発生（２）にするのではなく、リトライカウント１７０９を一つ増加させてステータス１７０５を処理待ち（０）に更新する。その結果、タスクサーバー１０３及び１０４により再度タスクが取得され、タスクが実行される。本実施例においては、リトライカウント１７０９の上限は２として、リトライカウント１７０９が２を超えた場合にはステータス１７０５はエラー発生（２）となる。
【００６７】
一時ファイル管理サービスサーバー群１２０３は、スキャンサービスサーバー群１０１やタスクサーバー１０３及び１０４からの要求に応じて、ファイルを格納し、その格納先のパスを管理するサービスサーバー群である。タスクサーバー１０３及び１０４からファイル取得要求があった際には保存したファイルのバイナリデータをタスクサーバー１０３及び１０４に返却する。また、タスクサーバー１０３及び１０４やジョブ管理サービスサーバー群１２０２からファイル削除の要求があった際には、保存したファイルを削除する。スキャンサービスサーバー群１０１やタスクサーバー１０３及び１０４は一時ファイル管理サービスサーバー群１２０３によって、ファイルの格納先のパスやファイルサーバーの状態を気にすることなく、ファイルの保存及び取得、削除を行うことができる。
【００６８】
ここで、ジョブ管理サービスサーバー群１２０２がタスクサーバー１０３からジョブの問い合わせを受けたときの応答フローについて、図８を用いて説明する。なお、タスクサーバー１０４の処理も図８と同一である。
【００６９】
Ｓ２２０１でジョブ管理サービスサーバー群１２０２は、タスクサーバー１０３からタスク要求を受信する。このとき、タスク要求にはタスクＩＤが含まれている。
【００７０】
Ｓ２２０２でジョブ管理サービスサーバー群１２０２は、ジョブ情報管理ＤＢ部１６０２を参照して、ジョブ情報を取得する。
【００７１】
Ｓ２２０３で、ジョブ管理サービスサーバー群１２０２は、実行すべきジョブがあった場合はＳ２２０４へ、実行すべきジョブがなかった場合はＳ２２０５へ処理を分岐させる。このとき、実行すべきジョブとして判断される条件は、ステータスが処理待ち（０）、かつタスクＩＤがＳ２００１で受信したタスクＩＤと等しいことである。
【００７２】
Ｓ２２０５で、ジョブ管理サービスサーバー群１２０２は中止時間１５０３を超過して実行中となっているジョブの有無を確認する。このとき、ステータスが実行中（１）で、最終更新時刻１７０６から中止時間１５０３以上経過しているかどうかを判断する。ジョブ管理サービスサーバー群１２０２は、中止時間１５０３を超過して実行中となっているジョブがあった場合はＳ２２０４へ、なかった場合はＳ２２０６へ処理を分岐させる。本ステップにより、Ｓ２２０４の処理を行わせることにより、実行中のタスクサーバーから、別のタスクサーバーへ処理を委譲することができる。
【００７３】
Ｓ２２０４で、ジョブ管理サービスサーバー群１２０２は、タスクサーバー１０３に対象ジョブのジョブ情報を送信する。タスクサーバー１０３は、受け取ったジョブ情報をもとに、タスクを実行する。ここで、Ｓ２２０４で送信するジョブはＳ２２０３またはＳ２２０５で選択されたジョブである。Ｓ２２０４で選択されたジョブは、新規投入されたジョブ、または別のタスクサーバーの実行が終了したジョブ、あるいはリトライ対象のジョブである。新規投入されたジョブとは文字通り新規に投入されたジョブである。別のタスクサーバーの実行が終了したジョブとは例えば、タスクサーバー１０３による実行によりタスクサーバー１０４の処理対象となったジョブである。リトライ対象のジョブとは例えば、タスクサーバー１０３でのタスク実行に失敗して再度タスクサーバー１０３が実行するジョブである。Ｓ２２０５で選択されたジョブは、処理中止時間以上実行中だったため、ジョブ管理サービスサーバー群１２０２がタスクサーバー１０３に異常が発生したと判断して、委譲されるジョブである。
【００７４】
Ｓ２２０６で、ジョブ管理サービスサーバー群１２０２は、タスクサーバー１０３に対象ジョブが存在しなかったため、タスクプロセス１０１０にｎｕｌｌを送信する。タスクサーバー１０３は、ｎｕｌｌを受信すると処理対象のジョブが存在しないと判断して、一定時間後に再度問い合わせを行う。
【００７５】
以上、図８に示された処理フローにより、ジョブ管理サービスサーバー群１２０２は一連のジョブをタスクの連結によって実行することができる。
【００７６】
続いて、図９を用いて、タスクサーバー１０３及び１０４でのタスク処理の実行中に、タスクサーバー１０３及び１０４のオペレーションシステムにシャットダウンイベントが発生した際の処理について説明する。以降、タスクサーバー１０３を例に図９の処理を説明するが、タスクサーバー１０４で実行される処理も図９と同一である。
【００７７】
Ｓ２３０１で、タスクサーバー１０３のタスクプロセス１０１０は、オペレーションシステムからのシャットダウンイベントを受信する。
【００７８】
Ｓ２３０２で、タスクプロセス１０１０は、タスク実行スレッド１０２０がタスク処理を実行中であるかを判断する。タスク実行スレッド１０２０がタスク処理を実行中であればＳ２３０３へ、実行中でなければ図９の処理を終了する。
【００７９】
Ｓ２３０３で、タスクプロセス１０１０は外部影響情報１０２４を取得する。
【００８０】
外部影響情報１０２４とは、タスク処理の実行中に、外部システムに対して影響を与える処理を実行したかどうかを示す情報である。外部システムに対して影響を与えるとは、外部システムにデータを送信することを意味する。データの送信の具体例は外部システムへのデータの保存やメール送信、ＡＰＩの実行といった内容が考えられる。また、外部システムとはクラウドサービスサーバー群１０８などの外部情報処理装置を意味する。外部影響情報１０２４は、初期状態では「無」であり、タスク実行スレッド１０２０内で、外部システムに対する影響を与える処理を実行した際に「有」として更新する。外部影響情報１０２４が「有」であれば、すでに外部システムに対して影響を与えたことを示し、外部影響情報１０２４が「無」であれば、外部システムに対して影響を与えていないことを示す。
【００８１】
Ｓ２３０４で、タスクプロセス１０１０は外部影響情報１０２４が「有」であるかを判断する。外部影響情報１０２４が「有」であれば実行中のタスクは外部システムに対して影響を与えるタスク（送信タスク）であると判断してＳ２３０５へ進む。一方、「無」であればＳ２３０８へ進む。
【００８２】
Ｓ２３０５で、タスクプロセス１０１０は、タスク実行スレッド１０２０がタスク処理の実行を完了したかどうかを確認する。タスク処理が完了した場合はＳ２３０６へ、完了しなかった場合はＳ２３０７へ処理を分岐させる。
【００８３】
Ｓ２３０７で、タスクプロセス１０１０は一定時間待機する。このとき、タスクプロセス１０１０は、必要であればオペレーションシステムに対してシャットダウンを延期するためのメッセージを送るように構成しても構わない。上記処理は、オペレーションシステムのシャットダウン仕様に応じて動作すべきであり、シャットダウンを延期するためのメッセージを送る構成は必須ではない。Ｓ２３０６で、タスクプロセス１０１０はジョブ管理サービスサーバー群１２０２に完了を通知する。
【００８４】
Ｓ２３０８では、タスクプロセス１０１０は、タスク処理をすべて中止する。
【００８５】
Ｓ２３０９で、タスクプロセス１０１０は、ジョブ管理サービスサーバー群１２０２にタスク処理を中止したことを示す通知する。ジョブ管理サービスサーバー群１２０２は、タスクプロセス１０１０から中止通知が行われると、リトライカウント１７０９を上げることなく、再びタスクプロセス１０１０の処理対象として復帰させる。これは、タスク処理が想定された回数実行されることを保証することで、クラウドシステムとしての可用性を維持するためである。
【００８６】
以上のように、実施例１では、タスク処理の実行中にシャットダウンイベントが発生した際にも、外部システムに影響を与える処理を実行した場合には、ジョブ管理サービスサーバー群１２０２への完了通知を行うことができる。また、外部サービスに影響を与える処理を実行していなかった場合には、即座にシャットダウンすることができる。このことから、シャットダウンイベントの発生に伴い、外部システムに二重に影響を与えることを防止できる。
【００８７】
（実施例２）
実施例１では、図９外部影響情報１０２４によって、実行中のタスク処理を即座に終了させるか、終了まで待ち合わせるかを切り替えた。上記の処理は、外部システムに影響を与える内容のタスク処理を実行している際にも、まだ外部影響情報１０２４が更新されていなければ、即座にタスク処理を終了させることができる。しかしながら、タスク実行スレッド１０２０内で外部影響情報１０２４を適切に更新する必要があるため、より容易にプログラムを構築するために、外部影響情報１０２４を参照するのではなく、タスク処理のタスク種別１５０４により、一律にタスク処理を即座に終了させるか、終了まで待ち合わせるかを切り替えることもできる。
【００８８】
本実施例では、上記の実現方法について図１３を用いて説明する。図１３のフローチャート以外の処理は、実施例１と同様のため省略する。なお、図９の処理との違いはＳ２３０３及びＳ２３０４（図１３ではＳ２４０３及びＳ２４０４）の処理である。よって、既に説明したステップと同じ処理については、既に説明したステップの番号と同一の番号を付与し、説明を省略する。また、タスクサーバー１０３を例に図１３の処理を説明し、タスクサーバー１０４で実行される処理は図１３と同一である。
【００８９】
Ｓ２３０２でタスクが実行中であると判断した場合にＳ２４０３へ進む。Ｓ２４０３で、タスクプロセス１０１０はタスク種別１５０４を取得する。タスク種別１５０４はジョブ管理サービスサーバー群１２０２からジョブ情報とともに送られる。また、タスク処理に紐づく情報であるため、タスクプロセス１０１０のプログラム内にあらかじめ入力しておいてもよい。
【００９０】
Ｓ２４０４で、タスクプロセス１０１０はタスク種別１５０４が「ｏｕｔｐｕｔ」（送信タスク）であるかを確認する。タスク種別１５０４が「ｏｕｔｐｕｔ」であればＳ２３０５へ、そうでなければＳ２３０８へ処理を分岐させる。
【００９１】
以上のように、実施例２では、タスク処理のタスク種別１５０４により、一律にタスク処理を即座に終了させるか、終了まで待機させるかを切り替える処理について説明した。実施例２によると、外部影響情報１０２４をタスク実行スレッド１０２０内で更新することなく、外部システムへの二重処理を一律に防ぐことができる。
【００９２】
上記実施例２では、外部影響情報１０２４を参照するのではなく、タスク処理のタスク種別１５０４により、一律にタスク処理を即座に終了させるか、終了まで待機するかを切り替える方法について説明した。上記により、タスク実行スレッド１０２０内で外部影響情報１０２４を更新することなく、より容易にプログラムを構築することができる。
【００９３】
（実施例３）
実施例１では、外部影響情報１０２４によって、実行中のタスク処理を即座に終了させるか、終了まで待機させるかを切り替えた。上記の処理は、外部システムに影響を与える内容のタスク処理を実行している際にも、まだ外部影響情報１０２４が更新されていなければ、即座にタスク処理を終了させることができる。
【００９４】
しかしながら、シャットダウンが発生した場合に、即座にタスク処理を停止すると、処理時間が非常に長いタスク処理についても、停止されてしまう。タスク処理が停止されると、再度タスクサーバー１０３及び１０４のタスクプロセス１０１０及び１０１１でのタスク処理の実行が繰り返されることになり、スループットが低下してしまう。実施例３においては、タスク実行スレッド１０２０内の処理残り時間１０２５を参照して、ある閾値よりも処理残り時間１０２５が短い場合は、シャットダウン処理を待機させることにより、上記の課題を解決する。
【００９５】
図１４を用いて、上記処理を説明する。なお、図９の処理との違いはＳ２５０８の処理の有無である。よって、既に説明したステップと同じ処理については、既に説明したステップの番号と同一の番号を付与し、説明を省略する。また、タスクサーバー１０３を例に図１４の処理を説明し、タスクサーバー１０４で実行される処理は図１４と同一である。
【００９６】
Ｓ２３０４で、タスクプロセス１０１０が外部影響情報１０２４は「有」であると判断した場合にＳ２５０８に進む。Ｓ２５０８で、タスクプロセス１０１０は処理残り時間１０２５を取得し、処理残り時間１０２５が所定時間以内であればＳ２５０５へ、所定時間以上であればＳ２５０９へ処理を分岐させる。所定時間とは、あらかじめタスクサーバー１０３が保持している時間情報である。また、処理残り時間１０２５とは、タスク処理の実行中に、タスク処理の実行を終えるまでの時間を保持しておくための情報である。タスク実行スレッド１０２０は、タスク処理の進捗から、処理残り時間１０２５を予測し、更新する。
【００９７】
以上のように、実施例３では、処理を終了するのに長い時間を要するタスク処理の実行中にシャットダウンイベントが発生した際に、タスク処理の完了までの時間が所定の時間よりも短い場合には、処理が完了するまでシャットダウンを延期することができる。このことから、シャットダウンイベントの発生に伴うタスクサーバー１０３及び１０４が実行するタスク処理のパフォーマンスの低下を防止することができる。
【００９８】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。
【００９９】
即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2015005203.tif 000003
【図２】
2015005203.tif 000004
【図３】
2015005203.tif 000005
【図４】
2015005203.tif 000006
【図５】
2015005203.tif 000007
【図６】
2015005203.tif 000008
【図７】
2015005203.tif 000009
【図８】
2015005203.tif 000010
【図９】
2015005203.tif 000011
【図１０】
2015005203.tif 000012
【図１１】
2015005203.tif 000013
【図１２】
2015005203.tif 000014
【図１３】
2015005203.tif 000015
【図１４】
2015005203.tif 000016