JP2013106193A

JP2013106193A - システム、およびその制御方法。

Info

Publication number: JP2013106193A
Application number: JP2011248820A
Authority: JP
Inventors: Makoto Mihara; 誠三原
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2011-11-14
Filing date: 2011-11-14
Publication date: 2013-05-30

Abstract

【課題】複数のタスクからなる一連の処理において、各タスクにて生成されたデーターを安全に保管するために複数のサーバーに分けて保存すると、保存容量やデーター転送量の増大が起こるためコストがかかり、パフォーマンスの劣化が発生する
【解決手段】データーを生成する各タスクに重要度を設定し、その重要度に応じて保存の多重度や、保持期間を変更することでタスク連結システムにおけるデーター容量の削減を図る。
【選択図】図１１

Description

本発明は、タスクを連結させてジョブを処理するシステム、およびその制御方法に関する。

近年、サーバーコンピューター側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（ＳｏｆｔｗａｒｅａｓａＳｅｒｖｉｃｅ）という技術が利用され始めている。
クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データー変換やデーター処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。また、クラウドコンピューティングの特徴を生かすため、サーバーでの一連の処理を細かく規定されたタスクの連結で実現し、それらを同時並行で処理することで、多数のジョブをスケーラブルに処理する技術が存在する。
上記処理において、各タスクにてデーター変換やデーター処理された結果生成されるデーターを多重化し、耐障害性を高めて保存することが必要となる場合がある。
また、このようなデーターの保存における技術として、特許文献１では、データーの内容を判断し、重要なものはセキュリティレベルが高いサーバーに保存し、重要でないデーターはセキュリティレベルが低いサーバーに保存するという制御が行われている。

特開２０１１−１６４８８５

しかしながら、従来技術ではそのデーターの内容が重要か否かという観点で保存先を切り分けているだけであり、一連のジョブ処理の中での各タスクの特性によるデーターの重要度が加味されていない。また一連のジョブ処理の中でタスクが順次実行されていくことで、各タスクにおける処理結果データーの保存が必要となるため、通常のデーター保存と比較してデーターの保存容量や転送容量といったコストの増大は非常に大きな課題となる。
そこで、各タスクに重要度を持たすことで、データー保存の多重度やデーター保持期間に基づくデーター保存を実現することで、一連のジョブ処理における低コストのデーター保存実現を目的とする。
また、サーバーシステムの異常によりデーターが失われた場合の適切なリカバリーを行い、ジョブ処理の継続を実現することを目的とする。
さらには、一連のタスクの連続性を元に、さらなるデーター容量の削減を実現することを目的とする。
本願発明は、上述した目的の内、少なくとも一つの目的を達成するためのサーバーシステムを提供することを目的とする。

本発明の一実施形に係るシステムは、夫々が規定された処理を実行する複数のタスクの中からデバイスを起点として生成される特定ジョブを処理するためのタスクを決定し、決定されたタスクを連結させ各タスクを順次実行していくことで前記特定ジョブを処理するシステムであって、前記特定ジョブを処理するための前記各タスクが出力した出力データーを順次保存していく保存手段と、タスクが出力する出力データーの取り扱いに差異を持たせるために、タスク毎に重要度を設定する設定手段と、を有し、前記各タスク内の特定のタスクは、規定された処理を実行した後に出力する出力データーを前記特定のタスクに設定された前記重要度に従った保存方法で前記保存手段に保存することを特徴とする。

本発明によれば、タスクを連結させてジョブを処理するシステムにおいて、コストを削減しつつデーターの適正な保存が可能となる。

本発明の実施例におけるクラウドシステムの全体構成を示す図である。本発明の実施例におけるクライアント端末、サーバーコンピューターのハードウェア構成図である。本発明の実施例におけるクライアント端末のシステム構成図である。本発明の実施例における画像形成装置の内部構成の詳細を示す図である。本発明の実施例におけるスキャンサービスサーバーのシステム構成図である。本発明の実施例におけるスキャンサービスサーバーのユーザーインターフェースの一例である。本発明の実施例におけるスキャンサービスサーバーにて保持するチケット情報の一例である。本発明の実施例におけるスキャンサービスサーバーにて保持するテンプレートの一例である。本発明の実施例における画像形成装置のユーザーインターフェースの一例である。本発明の実施例におけるタスクサービスサーバーのシステム構成図である。本発明の実施例におけるスキャン処理の一連の流れを示すシーケンス図である。本発明の実施例におけるフローサービスサーバーのシステム構成図の概要である。本発明の実施例におけるルート管理サービスサーバーのシステム構成図である。本発明の実施例におけるルート管理サービスサーバーにて保持するルート情報の一例である。本発明の実施例におけるルート管理サービスサーバーにて保持するタスク情報の一例である。本発明の実施例におけるジョブ管理サービスサーバーのシステム構成図である。本発明の実施例におけるジョブ管理サービスサーバーにて保持するジョブ情報の一例である。本発明の実施例における一時ファイル管理サービスサーバーの全体構成を示す図である。本発明の実施例における中央管理サーバーのシステム構成である。本発明の実施例における中央管理サーバーにて保持する、ファイルサーバー情報、ファイルパス情報の一例である。本発明の実施例における一時ファイル管理サービスサーバーにて使用するファイルサーバーのフォルダの階層構造を示す図である。本発明の実施例におけるジョブ管理サービスサーバーが実施する、ジョブのリカバリー処理のフローチャートである。本発明の実施例におけるジョブ管理サービスサーバーが実施する、データーのシュリンク処理のフローチャートである。

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

図１は、本発明の実施の形態に係るクラウドシステムの全体構成を示す図である。

図１において、スキャンサービスサーバー１０１、フローサービスサーバー１０２、タスクサービスサーバー１０３、１０４、クライアント端末１０６、画像形成装置１０７、インターネットサービスサーバー１０８は、ネットワーク１１０〜１１２を介して接続されている。図において、タスクサービスサーバー１０３、１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバー１０８は、複数台接続されていることを仮定している。ネットワーク１１０〜１１２は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データー放送用無線回線等のいずれであり。またこれらの組み合わせにより実現される、いわゆる通信ネットワークである。ネットワーク１１０〜１１２は、データーの送受信が可能であればよい。一般的なクラウドサービスでは、ネットワーク１１０、１１２はインターネット、ネットワーク１１１は企業内ネットワークやサービスプロバイダーのネットワークとなる。

スキャンサービスサーバー１０１、フローサービスサーバー１０２、タスクサービスサーバー１０３、１０４は、一般的にサーバーコンピューター上にて実行されており、これらサービス群がユーザーに対してクラウドサービスを提供する。また、様々な企業などにより、同様にクラウドサービスサーバー１０８がインターネット上に公開されており、これらも一般的にサーバーコンピューター上にて実行されている。本願発明では各サーバーをサービスと記載する。クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデーターアシスタント）等から成るが、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、ＷｏｒｌｄＷｉｄｅＷｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。このクライアント端末１０６のようなデバイスからのジョブ処理の開始指示を起点としてジョブ処理が開始される。

なお、本実施例では複数のサーバー群から構成されるシステムがクラウドサービスを提供することを想定しているが、これらのサーバー群を１台に集約しても良い。なお、デバイスに相当するクライアント端末からクラウドに実行依頼が送信されたことに応じて、クラウド側は規定された処理を実行する複数のタスクを連結させてジョブを処理することになる。各タスクは、ジョブを処理するためにデーター処理を順次実行・順次保存していく。即ち、デバイスを起点としてジョブが生成され、タスクを順次実行することでジョブが処理されるのである。本願発明ではジョブが生成されるタイミングをデバイスからの実行依頼としたが、後述する作成済みのスキャンチケットを選択した時点からをジョブが生成されるタイミングとしても良い。どの時点においてジョブが生成されるかは任意のタイミングではあるが、少なくともデバイスからの実行依頼をクラウド側へ送信することでジョブが処理される点はどのタイミングであっても共通である。

図２は、本発明の実施形態に係るクライアント端末１０６、サービス群１０１〜１０４を実行するサーバーコンピューターのハードウェア構成図である。図２において、ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ（ＣＰＵ）２０２は装置全体の制御を行う。ＣＰＵ２０２はハードディスク（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、ＲａｎｄａｍＡｃｃｅｓｓＭｅｍｏｒｙ（ＲＡＭ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。ＲｅａｄＯｎｌｙＭｅｍｏｒｙ（ＲＯＭ）２０４は記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データーを記憶する。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。

ディスプレイ２０６は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インターフェース２０８は外部装置Ｉ／Ｆであり、プリンター、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデーターの流れを司るものである。ネットワークインターフェースカード（ＮＩＣ）２０９は、該インターフェース２０９、ネットワーク１１０〜１１２を介して外部装置とのデーターのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２の構成例に限定されるものではない。例えば、データーやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。

図３は、本発明の実施形態に係るクライアント端末１０６のシステム構成図である。図３において、Ｗｅｂブラウザ３０１を利用し、スキャンサービス１０１が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザーは本クライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドサービスを利用する。

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

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

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

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

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

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

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

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

図５を用いて、スキャンサービスサーバー１０１に関して説明する。スキャンサービスサーバー１０１はクラウドサービスにおけるスキャン機能の提供を行うサービスである。図５は、本発明の実施形態に係るスキャンサービス１０１のシステム構成図である。スキャンサービス１０１は、Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ部５０２、テンプレート管理ＤＢ部５０３からなる。これら構成要素により各種処理が実行されることでスキャンサービス１０１がユーザーに提供される。Ｗｅｂアプリケーション部５０１はスキャン機能を提供するアプリケーションプログラムを提供する。チケット作成部５１１はユーザーがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットには、画像形成装置１０７で原稿をスキャンする際の設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメーター等が記録されている。

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

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

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

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

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

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

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

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

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

引き続き、図１０にて、本発明の実施形態に係るタスクサービスサーバー１０３、１０４のシステム構成図を説明する。各タスクサービスサーバーは、スキャンサービスを実現するための要素機能を実現するサービスである。例えば画像データー対して画像処理を行うタスクサービスや、ファイル共有機能を提供するような他のクラウドサービス１０８に対して、画像データーを送信する処理を行うタスクサービスが存在する。本実施例においては、タスクサービスサーバー１０３は、画像データーに対してＯＣＲ処理を行いＯＣＲ結果のテキストデーターを画像データーに埋め込む処理を行う。また、タスクサービスサーバー１０４は、クラウドサービス１０８の中のストレージ機能を提供する特定のサービスに対して、画像データーをアップロードし保管する処理を行う。

以下、図１１のスキャン処理のシーケンス図の流れとともに各構成要素の説明を行うタスクサービスサーバー１０３、１０４のタスク取得部１０１１は、ステップＳ１１１２、Ｓ１１１３、Ｓ１１１９、Ｓ１１２０にて、定期的にフローサービスサーバー１０２に問い合わせを行い、各タスクサービスサーバー１０３、１０４にて処理可能なタスクを取得する。タスクサービスサーバー１０３、１０４のデーター取得部１０１２は、タスク取得部１０１１で取得した情報を元に、ステップＳ１１１４、Ｓ１１１５、Ｓ１１２１、Ｓ１１２２にてフローサービスサーバー１０２より処理すべき画像データーの取得を行う。

タスクサービスサーバー１０３、１０４のタスク処理部１０１５は、ステップＳ１１１６、Ｓ１１２３にて取得した画像データーに対して各種処理を行う。タスクサービスサーバー１０３のタスク処理部１０１５は、ステップＳ１１１６での処理結果をステップＳ１１１７にてデーター保存部１０１３を通して、フローサービスサーバー１０３に保存する。タスクサービスサーバー１０４のタスク処理部１０１５は、ステップＳ１１２３での処理結果をステップＳ１１２４にてクラウドサービス１０８にデーター送信する。タスクサービスサーバー１０３、１０４のタスクステータス通知部１０１４は一連のタスク処理の終了結果をステップＳ１１１８、Ｓ１１２５にて、フローサービスサーバー１０３に通知する。以上で、スキャンジョブの一連の処理が完了する。タスク処理の結果は、各タスクに設定されている重要度に応じて、異なる保存方法で出力結果をメモリに保存していく。

続いて、フローサービスサーバー１０２の詳細な説明を行う。フローサービスサーバー１０２は本願発明における中心的なサービスであり、ルート管理、ジョブ管理、一時ファイル管理を行うサービスである。図１２は、フローサービスサーバー１０２のシステム構成の概要である。フローサービスサーバー１０２は、ルート管理サービスサーバー１２０１、ジョブ管理サービスサーバー１２０２、一時ファイル管理サービスサーバー１２０３の各サーバーからなる。これらサーバー上により各種処理が実行されることで各サービスが提供され、それらが連携することで、フローサービスサーバー１０２がユーザーに提供される。

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

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

図１４にて、ルート情報管理ＤＢ部１３０１で管理されている情報の一例を示す。ルートＩＤ１４０１がルートを一意に識別するＩＤである。シーケンス番号１４０２はそのルートの何番目に実行するタスクであるかを保持する。タスクＩＤ１４０３はどのタスクを実行するかを保持する。例えば、データー１４１３、１４１４、１４１５で、ルートＩＤ１４０１が００２のルートを定義している。１４１３が１番目に実行するタスクであり、タスクＩＤ１４０３がＴａｓｋ１のタスクを実行する。同様に、１４１４が２番目に実行するタスクであり、Ｔａｓｋ３のタスクを、１４１５は３番目に実行するタスクでＴａｓｋ５のタスクを実行するという定義となる。このように、１ルートに対して複数のタスクが割り当てられており、更に規定された順番通りにタスクが実行されるように、幾つかのタスクが連結する。

図１５にて、タスク情報管理ＤＢ部１３０２で管理されている情報の一例を示す。タスクＩＤ１５０１がタスクを一意に識別するＩＤである。タスク名１５０２はそのタスクの名前である。続いて、多重度１５０３と削除１５０４にてそのタスクの重要度の設定を保持する。多重度１５０３はそのタスクの処理結果を保存する際、どの程度の多重度でデーターを保存しておくのかを示す設定である。多重度１５０３が０の場合は処理結果を保存しないタスクであり、その他の場合は多重度の数である。多重度が大きいほど重要なタスクとなる。重要度が高まれば多重化させて出力データーを保存することになる。タスクサービス１０３、１０４のデーター保存１０１３はデーター保存Ｓ１１１５を実行する際に、本設定を元にフローサービス１０２にデーター保存依頼を行う。削除１５０４はそのデーターをジョブ終了時まで保持するべきか否かを示すフラグである。削除１５０４が１の場合にはジョブ処理の途中で削除可能であり、０の場合はジョブが終了するまで削除してはいけない。また、値がないものはそもそもデーターを保存していないタスクである。削除１５０３は０のものが重要なタスクとなる。

例えば、タスク定義１５１８のように、スキャンデーターを保存するタスクでは、多重度が２、削除は０と設定される。これは、ユーザーが画像形成装置１０７にて原稿をスキャンした際、処理の結果を待たず原稿を破棄してしまった場合でも、必ず生成したスキャンデーターを保持するための設定である。

タスク定義１５１５のように、クラウド１よりデーターを取得するタスクでは、多重度が２、削除は０と設定される。これは、クラウド１にアクセスする際、認証トークンといった認証情報を利用するためである。一般的に認証トークンは有効期間が決まっているため、認証トークン有効期限が切れた場合クラウド１にアクセスできなくなる。いったんアクセスできて取得した情報は再取得できるかわからないので確実に保持するための設定である。本設定は、例えばワンタイムパスワードでの認証が必要なサービスへのアクセスや、ワンタイムＵＲＬへのアクセスが必要な処理の場合でも同様である。

タスク定義１５１３のように、データー変換サービス連携を行う場合では、多重度が２、削除は１と設定される。他サービスに画像データーを送信し、その変換結果を取得するような処理の場合、一般的に処理に時間がかかるうえ、１処理毎に課金される場合がある。このため、データー自体は再生成できるができれば再生成を行いたくないので、データーが失われにくい設定は行う。ただし、あくまでも処理の途中結果であるため、ジョブを処理している最中であっても削除を許可する。

タスク定義１５１６のように、ＰＤＦフォーマットのデーターをＪＰＥＧフォーマットのデーターに変換する処理では、多重度が１、削除は１と設定される。このような処理は処理コストが低く、本スキャンサービス内でのみ処理する機能の為、データー自体の再生成も容易であり多重度無しで設定する。さらには、処理の途中結果であるため処理途中での削除を許可する。本実施例では少なくとも３つのレベルの重要度を設定しており、多重度２、削除０のものが最も重要度が高く、次いで多重度１、削除１のものが２番目に重要度が高く、最後に多重度１、削除０を両方のレベルより低い重要度と定めている。各タスクは、この重要度のレベルの内何れか１つのレベルが設定され、設定されたレベルに応じた方法で出力データーを保存し、また、保存された出力データーはレベルに応じた設定に従い削除制御が行われる。

以上、説明してきたように、夫々が規定された処理を実行する複数のタスクの内、デバイスを起点として生成されるジョブを処理するためのタスクを連結させて各タスクを順次実行していくことで前記ジョブを処理するシステムにおいて、タスク毎に異なる重要度を設定する。結果、各タスクが出力する出力結果の取り扱いに差異を持たすことができ、各タスクは、上述したように重要度に従った保存方法でメモリにタスクの出力結果を保存する。

図１６を用いて、ジョブ管理サービスサーバー１２０２に関して説明する。ジョブ管理サービスサーバー１２０２は、タスクサービスサーバー１０３、１０４からのリクエストに対してタスク情報の授受や、各タスクの状態を管理するためのサービスである。外部Ｉ／Ｆ１６０１は、タスクサービスサーバー１０３、１０４、および画像形成装置１０７との通信を行う。外部Ｉ／Ｆ１６０１を通じて、ジョブ管理サービスサーバー１２０２の各機能へのアクセスを行う。ジョブ情報管理ＤＢ部１６０２は、作成された各ジョブのステータスや、各ジョブが扱うデーターのＩＤを管理する。ジョブ情報管理ＤＢ部１６０２の詳細な内容は、図１７に記載されており、ジョブ情報管理ＤＢ部１６０２の内容に関する説明は後述する。

ジョブ追加部１６０３は、スキャンサービスサーバー１０１が、図１１において、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ投入リクエストＳ１１０９を受け、ジョブ情報管理ＤＢ部１６０２に、ジョブ情報を格納する。ここで、ジョブ情報とは、図１７に示されるジョブ情報管理ＤＢ部１６０２に存在する各カラム（１７０１〜１７０７）から構成される。ジョブ情報取得部１６０４は、タスクサービスサーバー１０３、１０４から外部Ｉ／Ｆ１６０１を通じて発行されるタスク取得リクエストＳ１１１０を受け、ジョブ情報管理ＤＢ部１６０２から、ジョブ情報を取得する。ここで取得したジョブ情報は、タスク取得Ｓ１１１１にてタスクサービスサーバー１０３、１０４に渡される。ジョブ情報更新部１６０５は、結果通知Ｓ１１１６にて、タスクサービスサーバー１０３、１０４から、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ情報更新リクエストを受け、ジョブ情報管理ＤＢ部１６０２の該ジョブの情報を更新する。ここで、更新される情報として、カレントタスクＩＤ１７０４、およびステータス１７０５、最終更新時刻１７０６がある。カレントタスクＩＤ１７０４を更新する前には、ルート管理サービス部１２０１の外部Ｉ／Ｆ１３０３を通じて、ルート情報管理ＤＢ部１３０１から、該ルートＩＤにおける次のタスクＩＤを取得する。取得したタスクＩＤを以て、カレントタスクＩＤ１７０４を更新する。また、ステータス１７０５は０、最終更新時刻１７０６は現在時刻で更新する。

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

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

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

続いて、図１８、図１９、図２０、図２１を用いて、一時ファイル管理サービス１２０３について説明する。図１８は一時ファイル管理サービス１２０３の全体構成を示す図である。図１８において、中央管理サーバー１８０１、ファイルサーバーＡ１８０２、ファイルサーバーＢ１８０３、ファイルサーバーＣ１８０４はネットワーク１８１０を介して接続されている。また、ネットワーク１８１０はネットワーク１１０と接続されている。ネットワーク１８１０はネットワーク１１０と同様のデーターの送受信が可能な通信ネットワークである。中央管理サーバー１８０１は一般的にサーバーコンピューター上にて実行される。ファイルサーバー１８０２〜１８０４は一般にサーバーコンピューター上にて実行されており、必要に応じて電子データーを保存、削除、取得する機能を有している。

続いて、一時ファイル管理機能を提供する中央管理サーバー１８０１について図１９、図２０、図２１を用いて説明する。図１９は、本発明の実施形態に係る、中央管理サーバー１８０１のシステム構成図である。中央管理サーバー１８０１は、Ｗｅｂアプリケーション部１９０１、バックエンド部１９０２、ファイルサーバー管理ＤＢ部１９３１、パス管理ＤＢ部１９３２からからなる。これら構成要素により各種処理が実行されることでサービスを行う。

Ｗｅｂアプリケーション部１９０１が、一時ファイル管理機能を提供するＷｅｂアプリケーションプログラムである。各機能については後述する。バックエンド部１９０２は、ファイルサーバー１８０２〜１８０４へのファイル保存、取得、削除などの機能を実現する。ファイルサーバー管理ＤＢ部１９３１、パス管理ＤＢ部１９３２は、一時ファイル管理機能を実現するためのデーターを管理する。

ファイルサーバー管理ＤＢ部１９３１は、ファイルの格納先であるファイルサーバー１８０２〜１８０４に関する情報を管理する。図２０にファイルサーバー管理ＤＢ部１９３１で管理するデーターの例を示す。ＩＤ２００１は、ファイルサーバーを一時ファイル管理サービス１２０３内で一意に識別するための情報である。ホスト名２００２は、ネットワーク１８１０上におけるファイルサーバーの一意のアドレスを示し、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてファイルサーバー１８０２〜１８０４にアクセスする際に使用する。アクティブフラグ２００３は、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてホスト名２００２に存在するファイルサーバーとの通信の可否を示す真偽値であり、通信可能な場合はＴｒｕｅ、通信不可能な場合はＦａｌｓｅを取る。共有フォルダ名２００４はファイルサーバー１８０２〜１８０４上に作成した共有フォルダ名である。ホスト名２００２と共有フォルダ名２００４から、ファイルサーバー１８０２〜１８０４上に作成した共有フォルダのフルパスが得られる。

パス管理ＤＢ部１９３２は一時ファイル管理サービス１２０３で管理している、ファイルサーバー１８０２〜１８０４に保存された一時ファイルとフォルダに関する情報を管理する。本発明では、一時ファイル管理サービス１２０３で管理するファイルとフォルダをあわせてエンティティと呼ぶ。図２０にパス管理ＤＢ部１９３２で管理するデーターの例を示す。ファイルＩＤ２０１０は、ファイルサーバー１８０２〜１８０４でエンティティを一意に識別するための情報である。ファイルグループＩＤ２０１１は各エンティティを関連するジョブでグループ化するための情報である。従って、同一ジョブによって生成されたエンティティは同一のファイルグループＩＤ２０１１を持つ。タスクＩＤ２０１２は各エンティティに関連するタスクのタスクＩＤ、またはフォルダを表す「Ｆｏｌｄｅｒ」、またはスキャンサービスサーバー１０１からの要求により格納されたファイルを表す「ｉｎｉｔ」のいずれかの値が入る。本発明では、スキャンサービスサーバー１０１からの要求により格納されたファイルを初期データーと呼ぶ。Ｎｏ２０１３は各タスクによって生成されたファイルのファイル番号を示す。パス２０１４はエンティティの格納先のフルパスを示し、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてエンティティにアクセスする際に使用する。ホスト名２０１５は各エンティティの格納先のファイルサーバーのホスト名を示す。作成日２０１６及び有効期限２０１７は各エンティティの作成日及び有効期限を示す。

ファイルサーバー１８０２〜１８０４は、一時ファイル管理サービス１２０３で管理するファイルを格納する。図２１にファイルサーバー１８０２〜１８０４のフォルダの階層構造を示す。フォルダ２１０１は共有フォルダであり、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてアクセス可能とする。共有フォルダ２１０１は各サーバーに少なくとも１つ存在し、ファイルサーバー管理ＤＢ部１９３１の共有フォルダ名２００４と一致する。本発明では共有フォルダ２１０１の深さを０とする。共有フォルダ２１０１の直下にある、深さ１のフォルダ群２１３１の各フォルダ２１１１、２１２１のフォルダ名はファイルグループＩＤ２０１１に対応する。また、２１１１および２１２１の直下にある深さ２のフォルダ群２１３２の各フォルダ２１１２、２１１３、２１２２、２１２４、２１２７のフォルダ名はタスクＩＤ２０１２に対応する。一時ファイル管理で管理される一時ファイルは、深さ２のフォルダ群２１３２の直下に保存される。このときのファイル名はＮｏ２０１３に対応する。

続いて、Ｗｅｂアプリケーション部１９０１が持つ各機能について説明する。ファイル保存部１９１１は、スキャンサービスサーバー１０１やタスクサービスサーバー１０３、１０４からのリクエストに応じて、ファイルサーバー１８０２〜１８０４にファイルを多重化して保存する機能を実現する。多重度は呼び出し元であるスキャンサービス１０１やタスクサービスサーバー１０３、１０４から１以上の整数を指定でき、多重度１の場合は多重化せずに保存する場合と同義である。また多重度の最大値は、ファイルサーバー１８０２〜１８０４に存在する共有フォルダ数であり、それ以上は無視される。

ファイル保存部１９１１は、スキャンサービスサーバー１０１からの初期データー保存のリクエストを受信すると、まず現在稼働中のファイルサーバーの中から保存先のファイルサーバーを選択する。この際、ファイル保存部１９１１は、深さ１のフォルダ群２１３１のフォルダ数が少ないファイルサーバーから順に指定された多重度分だけ選択する。これは、各ファイルサーバー１８０２〜１８０４の容量を均一化するためである。スキャンサービスサーバー１０１からの初期データー保存のリクエストには、多重度、タスクＩＤ、Ｎｏが含まれる。ファイル保存１９１１はファイルグループＩＤを生成し、ファイルグループＩＤ、タスクＩＤ、Ｎｏに基づいて保存先のファイルパスを生成し、後述のファイル保存処理を実行する。

ファイル保存部１９１１がタスクサービス１０３、１０４からファイル保存のリクエストを受信した場合は、そのリクエストには、多重度、ファイルグループＩＤ、タスクＩＤ、Ｎｏが含まれる。ファイル保存１９１１は、受信したリクエストに含まれるファイルグループＩＤと同一のファイルグループＩＤを持つ初期データーが保存されているファイルサーバーをパス管理ＤＢ部１９３２から取得する。ファイル保存１９１１は、ファイル保存先のファイルサーバーを、取得したファイルサーバーの中から多重度分だけランダムに選択する。ファイル保存部１９１１は、選択した各ファイルサーバーに対して、ファイルグループＩＤ、タスクＩＤ、Ｎｏに基づいて保存先のファイルパスを決定し、ファイル保存処理を実行する。

ファイル保存処理では、ファイル保存部１９１１がバックエンド部１９０２に対して保存先ファイルパスとファイルのバイナリデーターを送信する。バックエンド部１９０２は保存先のファイルサーバーとの通信の可否を確認し、通信可能であった場合はファイルを保存先ファイルパスに保存する。多重保存する場合は上記の処理を多重度分繰り返す。バックエンド部１９０２は、全てのファイルの保存が完了したらファイル保存部１９１１に結果を返す。ファイル保存部１９１１はパス管理ＤＢ部１９３２に保存先ファイルパスに関するエントリを多重度分追加する。ファイル保存処理の完了後、初期データーを保存した場合のみ、呼び出し元のスキャンサービス１０１に対してファイルグループＩＤを返却する。

ファイル取得部１９１２はタスクサービスサーバー１０３、１０４からの要求に応じてファイルサーバー１８０２〜１８０４に保存されたファイルをタスクサービス１０３、１０４に返す。ファイル取得部１９１２はタスクサービスサーバー１０３、１０４からのリクエストを受信すると、リクエストに含まれるファイルグループＩＤやタスクＩＤ、Ｎｏに基づいてパス管理ＤＢ部１９３２に問い合わせ、格納先のファイルパスを取得する。ファイル取得部１９１２はバックエンド部１９０２に対して格納先のファイパスを送信する。バックエンド部１９１２は格納先のファイルサーバーとの通信の可否を確認し、通信可能であった場合はファイルのバイナリデーターをファイル取得部１９１２に返す。ファイル取得部１９１２はバックエンド部１９１２から返却されたバイナリデーターをタスクサービス１０３、１０４に返す。

ファイル削除１９１３はタスクサービスサーバー１０３、１０４やジョブ管理サービスサーバー１２０２からの要求に応じてファイルサーバー１８０２〜１８０４に格納されたエンティティを削除する。ファイル削除部１９１３はタスクサービスサーバー１０３、１０４やジョブ管理サービス部１２０２からのリクエストを受信すると、リクエストに含まれるファイルグループＩＤやタスクＩＤ、Ｎｏに基づいてパス管理部１９３２に問い合わせる。ファイル削除部１９１３は取得した格納先のエンティティパスをバックエンド部１９０２に対して格納先のエンティティパスを送信する。バックエンド部１９１２は格納先のファイルサーバーとの通信の可否を確認し、通信可能であった場合はエンティティを削除する。バックエンド部１９０２は削除が完了したら、ファイル削除部１９１３に結果を返す。エンティティの削除に成功したら、ファイル削除部１９１３はパス管理ＤＢ部１９３２から削除したエンティティに関するエントリを削除する。以上により、タスクの重要度に応じてデーターの保存多重度を変化させることが実現でき、低コストでのデーター保存が可能となる。

引き続き、一時ファイル管理サービス１２０３にて管理しているデーターに異常が発生した場合のリカバリー処理と、ジョブにおけるデーター保存をさらに削減する処理に関して説明する。図２２はジョブ実行中にタスクが保存データーにアクセスできなかった場合にジョブ管理サービス１２０２が行うジョブのリカバリー処理を示すフローチャートである。即ち、特定のタスクが１個前のタスクが出力した出力データーにアクセスできなかった場合の処理の説明である。

本処理は、ジョブ管理サービスサーバー１２０２がタスクサービスサーバー１０３、１０４よりデーターアクセスエラーの通知を受けた場合に実行される。エラー通知を受けたジョブ管理サービスサーバー１２０２はステップＳ２２０２にて、エラーが発生したタスクを実行しているジョブの情報とジョブのルート情報をジョブ管理情報ＤＢ部１６０２より取得する。ステップＳ２２０３では取得したジョブ情報を元に、現在実行中のタスクがジョブの最初のタスクであるか否かを判別する。本判断は、ジョブ管理情報ＤＢ部１６０２のルートＩＤ１７０２、カレントタスクＩＤ１７０４および、ルート情報管理ＤＢ部１３０１のシーケンス番号１４０２の情報を利用して行う。現在実行中のタスクが最初のタスクであった場合、そのジョブは継続して処理が続けられないのでステップＳ２２０４にてジョブをエラーとしてそのジョブを終了する。

ステップＳ２２０３にて最初のタスクではないと判断した場合、ステップＳＪ０５にてエラーが発生したタスクの１個前のタスクの入力データーにアクセスを試み、アクセスできるか否かをチェックする。アクセスできる場合、ステップＳ２２０６にて、次にジョブが実行すべきタスクを１個前のタスクに設定しジョブを継続する。ステップＳ２２０５にて、データーにアクセスできない場合、ステップＳ２２０７にて１個前のタスクを実行タスクに設定し、再度ステップＳ２２０３からの処理を行う。

即ち、複数のタスク内の特定のタスクが１個前のタスクが出力した出力データーにアクセスできなかった場合、ジョブ管理サービスサーバー１２０２は１個前のタスクに入力された入力データーにアクセスを行う。そして、アクセスできた場合は１個前のタスクの処理から再開するように制御するのである。以上の処理により、タスクにてデーターアクセスエラーが発生したジョブのリカバリー処理が完了し、データーが正常に保存されている状態からジョブが再開される。

図２３はジョブ実行中に各タスクが終了したタイミングでジョブ管理サービス１２０２が行うデーターのシュリンク処理を示すフローチャートである。本処理は、ジョブ管理サービス１２０２がタスクサービスサーバー１０３、１０４よりタスク実行完了の通知を受けた場合に実行される。タスク完了通知を受けたジョブ管理サービス１２０２はステップＳ２３０２にて、完了したタスクを実行しているジョブの情報とジョブのルート情報をジョブ管理情報ＤＢ部１６０２より取得する。ステップＳ２３０３では、ステップＳ２３０２にて取得した情報より、実行完了したタスクのジョブで、実行完了したタスクよりも前に実行したタスクの分ループ処理を行う。ステップＳ２３０４では実行完了タスクと前のタスクの多重度１５０３の設定を比較し、多重度が実行完了タスクより低いか否かを判断する。多重度が実行完了タスク以下、即ち低いと判断された場合、さらに前のタスクの削除１５０４の設定を確認し、削除１５０４が１の場合はステップＳ１５０５に進み、前のタスクが保存したデーターを削除する。

以上の処理により、最終実行タスクのデーターよりも多重度が低いデーターを削除することで、システムが保持するデーター量を減らすことが可能となる。さらには、データーの多重度が高く重要なデーターが保存されているため、システムの可用性を維持することが可能となる。

Claims

夫々が規定された処理を実行する複数のタスクの内、デバイスを起点として生成されるジョブを処理するためのタスクを連結させて各タスクを順次実行していくことで前記ジョブを処理するシステムであって、
前記特定ジョブを処理するための前記各タスクが出力した出力データーを順次保存していく保存手段と、
タスクが出力する出力データーの取り扱いに差異を持たせるために、タスク毎に重要度を設定する設定手段と、を有し、
前記各タスク内の特定のタスクは、規定された処理を実行した後に出力する出力データーを前記特定のタスクに設定された前記重要度に従った保存方法で前記保存手段に保存することを特徴とするシステム。
タスクを管理する管理手段を更に有し、
前記特定のタスクが前記保存手段にアクセスする際であって、前記特定のタスクの１個前のタスクが出力した出力データーにアクセスできなかった場合、前記管理手段は前記１個前のタスクに入力された入力データーにアクセスを行い、アクセスできた場合は前記１個前のタスクの処理から再開するように制御することを特徴とする請求項１に記載のシステム。
前記特定のタスクが出力データーを前記保存手段に保存した際に、前記特定のタスクの１個前のタスクに設定されている重要度が前記特定のタスクに設定されている重要度よりも低い場合、前記１個前のタスクが出力した出力データーを削除するように制御することを特徴とする請求項１または２に記載のシステム。
前記重要度は３つのレベルを規定しており、最も重要度が高いレベルを有するタスクは出力データーを多重化させて保存し、該出力データーは前記特定のジョブの処理が終了するまで削除されないように設定され、次いで重要度が高いレベルを有するタスクは出力データーを多重化させて保存し、該出力データーは前記特定のジョブの処理が終了するまでの間に削除可能になるよう設定され、両方のレベルよりも低いレベルを有するタスクは出力データーを多重化せずに保存することを特徴とする請求項１乃至３の何れか１項に記載のシステム。
夫々が規定された処理を実行する複数のタスクの内、デバイスを起点として生成されるジョブを処理するためのタスクを連結させて各タスクを順次実行していくことで前記ジョブを処理するシステムを制御する制御方法であって、
保存手段は、前記特定ジョブを処理するための前記各タスクが出力した出力データーを順次保存していき、
設定手段は、タスクが出力する出力データーの取り扱いに差異を持たせるために、タスク毎に重要度を設定し、
前記各タスク内の特定のタスクは、規定された処理を実行した後に出力する出力データーを前記特定のタスクに設定された前記重要度に従った保存方法で前記保存手段に保存するよう制御することを特徴とする制御方法。