JP6226561B2 - 情報処理装置、情報処理装置の制御方法、及びプログラム - Google Patents

Description

本発明は、情報処理装置、情報処理装置の制御方法、及びプログラムに関するものである。

近年、デジタル印刷機の発展と共に、オンデマンド印刷が生産現場で流行している。オンデマンド印刷を行っている生産現場において、生産管理ソフトウェアや画像形成装置で処理エラーが発生した時点で、管理者にエラー発生を通知して当該エラーから素早く復帰し、生産を継続したいという要望がある。

しかし、エラー通知方法によっては、管理者側に煩わしい手間が発生してしまう。例えば、複数の処理工程を得て印刷物を生成する際に、エラーの発生した全ての工程でエラー通知を行うと管理者に大量のエラー通知が送信されてしまい、管理者の操作負荷が増加する。

特許文献１には、エラー通知回数を削減する方法として、特定のエリア内やグループ内で使用されている複数の画像形成装置で同一のエラーが発生した場合、管理サーバが同一エラーをまとめて管理者に通知することが記載されている。

特開２０１２−６４０４５号公報

しかしながら、特許文献１の方法では、同一種類のエラーの通知回数を削減する。その結果、例えば納品すべき成果物を出力するまでに、複数の工程、受注、画像処理、印刷処理等を含む処理を実行する場合において、発生しうるエラーが同一種類とは限らない。その結果、複数同時にエラーが通知されるとその状況を確認するために、管理者側の操作負荷が増大してしまう。

また、エラー通知を受けた管理者は通知を受けた異常を修復するために復旧作業を行うが、エラーが復旧した時点で、当該エラーから復旧したジョブの処理を次にどの処理から順番に処理すべきかを容易に認識できないおそれがあった。これらは、各工程における処理が並列的に実行されている場合は、さらに管理者の負担が重くなる場合があった。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、複数種類の部品を複数の工程で生成するオンデマンド印刷においてエラーが発生している状態であっても、エラーに関する情報と、エラーが起こった工程に関する情報を一つのエラー通知として管理者に通知できる仕組みを提供することである。
また、本発明のさらなる目的は、エラーが復旧したことに応じて、管理者に通知すべきリカバリ情報に次に対応すべきエラー情報を含めることができる仕組みを提供することである。

上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。
受注する印刷注文に対応する商品を構成する部品を生成する複数の工程のいずれか１つにおいて、前記部品に行う第１の処理と、前記複数の工程のいずれか１つにおいて、前記商品を構成する部品のうち、前記第１の処理が実行される部品とは異なる部品に行う第２の処理を並行して実行する実行手段と、前記第１の処理によって得られた第１のログと前記第２の処理によって得られた第２のログとを集約する集約手段と、前記集約手段によって集約されたログに基づいて、前記第１の処理乃至前記第２の処理において生成された部品に関する情報と前記生成された部品が生成された工程に関する情報とを格納する格納手段と、前記第１の処理と前記第２の処理の結果がエラーであった場合、前記格納手段によって格納されたログに基づいて、前記第１の処理及び第２の処理に対応する工程に関する情報と前記工程において生成されていた前記部品に関する情報とを取得しエラー通知を生成する第１の生成手段と、前記第１の生成手段によって生成されたエラー通知を通知する通知手段と、を備えることを特徴とする。

本発明によれば、複数の部品で成果物を成している場合でも、管理者に通知する回数を削減し、なおかつエラー復旧時点で成果物のどの処理から再開したらよいかが分かるようになるという効果がある。

印刷システムにおけるオンデマンド処理の一例を説明する図である。 印刷システムの構成を説明するブロック図である。 図２に示した管理サーバの構成を示すブロック図である。 管理サーバ（情報処理装置）が管理する処理工程を説明する図である。 図３に示したデータベースで管理するデータの構造を説明する図である。 図３に示した管理サーバのハードウェア構成を示すブロック図である。 エラー通知アプリのモジュール構成を示す図である。 構成情報ファイルの例を示す図である。 管理サーバにて発生したエラーの例を示す図である。 ログファイルのフォーマットとログファイルの具体例を示す図である。 通知情報生成部が作成するメッセージの構成を説明する図である。 リカバリ情報生成部が生成するリカバリ情報を示す図である。 管理サーバ（情報処理装置）の制御方法を説明するフローチャートである。 管理サーバ（情報処理装置）の制御方法を説明するフローチャートである。

次に本発明を実施するための最良の形態について図面を参照して説明する。
〔第１実施形態〕
図１は、本実施形態を示す印刷システムにおけるオンデマンド処理の一例を説明する図である。

図１において、注文１は１以上の商品で構成される。本実施形態において、商品は、フォトブック２を想定している。フォトブック２は、本文３と表紙４、帯５、ジャケット６の複数の部品で構成される。部品のコンテンツはそれぞれ１つのＰＤＦとして入稿され、前記ＰＤＦ中に画像が配置されている。そして、部品それぞれに対して１つの印刷ジョブが第１実施形態の情報処理システムにより作成される。
＜システム構成の説明＞
図２は、第１実施形態を示す印刷システムの構成を説明するブロック図である。
図２において、１００は注文サーバで、ＷＡＮ等のネットワーク２００を介して印刷ラボ３００と通信可能に接続されている。

注文サーバ１００は、Ｗｅｂ経由の入稿システムである。例えば、前記フォトブック２をＷｅｂ経由で購入する場合、顧客は自宅のクライアント装置を用いて、例えばクライアント装置のＷｅｂブラウザを起動し、注文サーバ１００が提供するＷｅｂサイトにアクセスする。顧客は、そして、接続された注文サーバ１００が提供する注文用に使用されるＵＩ画面を使って写真（画像データ）を注文サーバ１００にアップロードし、提示された金額を支払い、フォトブック２の注文をする。この注文が図１に示した注文１に対応する。

印刷ラボ３００において、４００は管理サーバ（単に情報処理装置と呼ぶこともある）で、注文サーバ１００から発行された注文１をネットワーク２００を介して受注し、受注した注文１を管理する。５００は画像形成装置で、成果物を生産する。６００は出力先装置で、管理サーバ４００で発生したエラーの通知処理を行う。なお、出力先装置６００としては、第１実施形態では携帯電話を想定しているが、クライアントコンピュータやスマートフォン（高機能携帯電話）、タブレット（多機能携帯端末）等を用いてもよい。
図３は、図２に示した管理サーバ４００の構成を示すブロック図である。

図３において、４１０は受注アプリで、注文サーバ１００からネットワーク２００を経由して注文を受注する。４２０は生産管理アプリケーション（以下、アプリと呼ぶ）で、受注した注文の面付け処理を行う。なお、生産管理アプリ４２０は、受注する印刷注文に対応する製品（例えばフォトブック）を構成する部品（例えば表紙、本文等）に所定の処理を実行する複数のモジュールを備える。ここで、所定の処理とは受注する印刷注文で特定される印刷すべき画像データに行う処理であって、画像補正、レイアウト処理、ジョブ作成処理、ジョブ発行処理等が含まれる。

４４０はデータベースで、受注した注文やコンテンツデータなどを格納して管理する。４３０はエラー通知アプリケーションで、受注アプリ４１０と生産管理アプリ４２０が出力するログファイルを取得して、出力先装置６００にエラー通知を行う。

生産管理アプリ４２０は、画像補正モジュール４２１、ＰＤＦレイアウトモジュール４２２、ジョブ作成モジュール４２３、ジョブ発行モジュール４２４で構成される。画像補正モジュール４２１は、フォトブック２の部品のコンテンツ内に配置された画像に対して画像補正処理を行う。ＰＤＦレイアウトモジュール４２２は、フォトブックの部品のコンテンツに対して、中綴じや断裁といった加工時に使用するトンボや検品用のバーコードを付加するためのＰＤＦレイアウト処理を行う。

ジョブ作成モジュール４２３は、フォトブックの部品それぞれに対して、印刷ジョブを作成する。ジョブ発行モジュール４２４は、ジョブ作成モジュール４２３が作成した前記印刷ジョブを画像形成装置５００に対して発行する。

生産管理アプリ４２０は、受注アプリ４１０から注文を受け取ると、図４の工程例に示す通り、部品それぞれに対して、画像補正処理工程とＰＤＦレイアウト処理工程、ジョブ作成処理工程を行う。また、図４に示す通り、各工程間において、本文や表紙といった部品種別ごとに処理は非同期で行われる。

例えば、本文の場合、画像補正処理工程、ＰＤＦレイアウト処理工程、ジョブ作成処理工程とシーケンシャルに処理が行われるが、それとは非同期で表紙や帯、ジャケットに対する処理が並行で行われる。なお、図５に示すジョブ発行は、作業者によって行われ、管理サーバ４００が提供するキーボードやマウスといった入力装置からの指示に応じて実行される。

図５は、図３に示したデータベース４４０で管理するデータの構造を説明する図である。
図５において、データベース４４０は、商品テーブル４４１と工程テーブル４４２、進捗テーブル４４３にて構成される。ここで、商品テーブル４４１の１レコードには受注した商品１つが格納される。

商品テーブル４４１のレコードそれぞれは、工程テーブル４４２と関連づけられている。工程テーブル４４２は受注登録工程、画像補正工程、ＰＤＦレイアウト工程、ジョブ作成工程、ジョブ発行工程といった、商品を作るために印刷システムで行われる工程が定義されている。工程テーブル４４２に定義された工程それぞれに、進捗テーブル４４３が関連付けられている。進捗テーブル４４３は、商品を構成する部品に関して、工程の進捗具合を記録したテーブルである。

図６は、図３に示した管理サーバ４００のハードウェア構成を示すブロック図である。
図６において、７００は中央処理装置で、上記プログラムおよび関連データが記憶されているフロッピー（登録商標）ディスク、ＣＤ―ＲＯＭ、ＩＣメモリカード等の記憶媒体をシステムに接続された媒体読取装置７０６から読み込む。その後、補助記憶装置７０２から主記憶装置７０１にロードされたアプリケーションプログラムによって、入力装置７０５から入力される情報を処理して、出力装置７０４やネットワークＩ／Ｆ７０７経由で画像形成装置５００に出力する。

なお、本実施形態では、出力装置７０４はディスプレイなどの表示装置とし、本来出力装置に含まれる画像形成装置５００と区別する。また、入力装置７０５はキーボード、ポインティングデバイス等で構成されているものとする。なお、後述のフローチャートで示す手順は管理サーバ４００の主記憶装置７０１、補助記憶装置７０２、ＲＯＭ７０３のいずれかに記憶され、中央処理装置７００により実行される。

さらに補助記憶装置７０２は、ハードディスク、光磁気ディスクで構成されるものであっていいし、これらの組み合わせで構成されるものであってもよい。また、それぞれの装置がネットワークを介して接続されていようとも、本発明を制約するものではない。
図７は、図３に示した管理サーバ４００内のエラー通知アプリ４３０のモジュール構成を示す図である。
図７において、エラー通知アプリ４３０は、エラー情報取得部４３１と通知情報生成部４３２、復旧情報取得部４３３、リカバリ情報生成部４３４、出力部４３５から構成される。以下、各モジュールの機能を説明する。

エラー情報取得部４３１は、受注アプリ４１０と生産管理アプリ４２０が出力するログファイルを一定間隔で部品毎に取得し、取得したログファイルを解析する。そして、当該ログファイルの解析後、取得した進捗情報をデータベース４４０の進捗テーブル４４３に書き込む。

通知情報生成部４３２は、進捗テーブル４４３の進捗列を参照し、エラーがある場合、進捗テーブル４４３から当該エラー情報を取得し、後述する図１０に一例を示すメッセージを作成する。具体的には、通知情報生成部４３２は、エラー情報取得部４３１が作成した進捗情報から取得可能な複数のエラー情報を解析して最初に発生した処理に対応づけられた通知情報を生成する。なお、作業者が復旧作業をすぐに行えるようにするために、最初に検知されたエラーはすぐに送るようにする。また、前記エラー情報は、商品単位でまとめて一つのメッセージとする。

復旧情報取得部４３３は、進捗テーブル４４３の復旧フラグを確認し、エラーが復旧したものが１つでも存在するかどうかを判断する。商品に復旧フラグが１つでも存在する場合は、リカバリ通知対象と判断する。

リカバリ情報生成部４３４は、復旧情報取得部４３３が復旧されたエラーがあると判断した場合、復旧されたエラーに関連する商品に対する工程それぞれの進捗状況のうち「Ｗａｉｔｉｎｇ」と「Ｅｒｒｏｒ」のものを進捗テーブル４４３から取得する。そして、リカバリ情報が作成される。なお、進捗状況が「Ｃｏｍｐｌｅｔｅｄ」の処理は再処理が必要ないので、リカバリ情報には含めない。

出力部４３５は、通知情報生成部４３２が生成した通知内容あるいはリカバリ情報生成部４３４が生成したリカバリ情報を受け取り、エラー通知アプリ４３０の通知構成情報ファイル８００（後述する）に記述された宛先８４０に通知を行う。

図８は、図７に示したエラー通知アプリ４３０が参照する通知構成情報ファイル８００の例を示す図である。本例は、ＸＭＬ形式でファイルが定義された例である。
図８において、ログファイルの取得先８１０は、アプリ毎にログファイルの取得先を決定できる。具体的にはＬｏｇｓ要素の子要素にＬｏｇ要素を設け、前記Ｌｏｇ要素にアプリそれぞれのログファイルまでのファイルパスを定義する。
また、ログファイルの取得間隔８２０は、第１実施形態において、設定された所定の時間間隔は、例えば３００秒（５分）とする。エラー通知の送り先８３０には差出人のメールアドレスを記入する。エラー通知の宛先８４０には通知の宛先である印刷システムの管理者のメールアドレスを記入する。なお、宛先８４０のＰｒｏｄｕｃｔＩＤ属性に特定の商品番号あるいは空白を記述することができる。ＰｒｏｄｕｃｔＩＤ属性に特定の商品番号が記載されている場合、通知時に特定の商品に関する通知のみを受けとることを指定できる。また、宛先８４０のＰｒｏｄｕｃｔＩＤ属性が空白である場合は通知をすべて受け取ることを指定できる。
８４１はリカバリ情報を一定時間毎に送るための時間指定項目で、本例では、「３６００」秒としている。エラー通知アプリ４３０は、起動時に通知構成情報ファイル８００を読み込み、ログファイルの取得先８１０と取得間隔８２０、送り先８３０、宛先８４０を決定する。なお、宛先８４０は、製品単位毎に異なる管理者を指定することが可能に構成されている。

図９は、図２に示した管理サーバ４００にて発生したエラーの例を示す図である。
図９において、上記ログファイルの取得間隔８２０で特定される時間、「３００」秒の間に本文と表紙にて画像補正処理エラーが発生し、帯にＰＤＦレイアウト処理エラーが発生している例である。そして、次の「３００」秒の間にジャケットにてジョブ作成処理エラーが発生している。

図１０は、図７に示したエラー情報取得部４３１が読み込むログファイルのフォーマットとログファイルの具体例を示す図である。
図１０において、ログファイルのフォーマット９００は、日付／時間９０１とスレッドＩＤ９０２、種別９０３、関数名９０４、エラーコード９０５、備考欄９０６で構成される。スレッドＩＤ９０２は、エラーが発生したスレッドの番号を表す。種別９０３は、ログの種別を表し、文字列で「Ｅｒｒｏｒ」あるいは「Ｃｏｍｐｌｅｔｅｄ」、「Ｗａｉｔｉｎｇ」が記述される。関数名９０４は、エラーが発生した関数名を表す。エラーコード９０５はエラーに割り振られたユニークな番号が入る。備考欄９０６には、商品を特定する番号（プロダクトＩＤ）と部品名（例えば本文等）、エラーメッセージ（例えば画像補正失敗）が入り、区切り文字としてダブルコロン「：」を用いる。

９１０，９２０はログファイルである。ログファイル９１０では、エラーログ９１１と９１２が商品番号「００１」に関して本文と表紙の画像補正処理が失敗、エラーログ９１３が帯のＰＤＦレイアウト処理が失敗、エラーログ９１４がジャケットのジョブ作成処理が失敗したことを表している。ログファイル９２０は、本文と表紙、帯で発生した前記エラーが復旧されたことを示すログファイルである。

図１１は、図７に示した通知情報生成部４３２が作成するメッセージの構成を説明する図である。
図１１において、９３０は通知内容のフォーマットで、日付／時間９３１と種別９３２、備考欄９３３で構成される。備考欄は商品を特定する情報と部品名、エラーメッセージで構成され、区切り文字としてダブルコロン「：」を用いる。
９４０はメッセージで、フォーマット９３０に基づいて作成され、ログファイル９１０から取得した情報を埋め込んで作成される。

図９のエラー例の場合、最初の３００秒にて検知されたエラーログ９１１とエラーログ９１２、エラーログ９１３は通知情報生成部４３２にて商品単位で１つのメッセージとしてまとめられる。このため、それぞれのメッセージ９４１、９４２は１つのメッセージ９４０として１回だけ通知が行われる。

この際、図１０に示すようにログファイル９１０のエラーログ９１４に関してはエラーの検出が行われて進捗テーブル４４３に書き込まれる。しかし、通知回数削減のためエラー検知した時点でユーザに対する通知は行われないように制御して、図１２に示すリカバリ情報の一部として通知されるように制御する。

図１２は、図７に示したリカバリ情報生成部４３４が生成するリカバリ情報を示す図である。本例は、プロダクトＩＤが「００１」に対するリカバリ情報である。
図１２において、９５０はリカバリ情報で、残処理情報９５１〜９５３から構成される。残処理情報９５１はそれぞれデータベース４４０の工程テーブル４４２に登録された工程に対して、図５に示した進捗テーブル４４３に格納された進捗情報から「Ｗａｉｔｉｎｇ」及び「Ｅｒｒｏｒ」のものを残処理一覧として生成される。

図１３は、本実施形態を示す管理サーバ（情報処理装置）の制御方法を説明するフローチャートである。本例は、管理サーバ４００における図７に示したエラー通知アプリ４３０がログファイルの取得からデータベースに書き込むまでの処理例である。なお、本願のフローチャートの各ステップは、図６に示した中央処理装置（ＣＰＵ）がＲＯＭ７０３や、他の記憶装置から主記憶装置７０１に読み込む制御プログラム（後述するモジュール）を実行することで実現される。なお、以下の説明では、制御の主体をエラー通知アプリ４３０等のモジュールとして説明する。

まず、Ｓ１０００にて、復旧情報取得部４３３は、エラー通知アプリ４３０の通知構成情報ファイル８００に記述されたログファイルの取得先８１０と取得間隔８２０を基にログファイルを取得する。次に、Ｓ１００１にて、復旧情報取得部４３３は、Ｓ１０００で取得したログファイルを解析し、Ｓ１００２にて、復旧情報取得部４３３は、解析結果を進捗テーブル４４３に書き込む。以上で、本ログファイル取得処理およびデータベース書込に関する処理が終了する。
次に、Ｓ１００３で、エラー通知アプリ４３０は、後述する図１４に詳細を示す通知処理を実行する。本処理は、一定時間経過したら処理を終了する。

図１４は、図１３に示したＳ１００３の通知処理の詳細例である。なお、以下の説明では、制御の主体をエラー通知アプリ４３０等のモジュールとして説明する。また、本処理は、商品テーブル４４１に格納された全商品に対して行われる。

Ｓ１００４で、通知情報生成部４３２は、進捗テーブル４４３の進捗列を参照し、商品１つに関するエラーの発生状況を判断する。つまり、通知情報生成部４３２は、判定対象の商品を構成する部品の少なくとも１つの進捗列にエラーが記述されているか判定する。ここで、エラーが発生していないと通知情報生成部４３２が判断した場合は、次の部品に処理を移る。
一方、Ｓ１００４で、エラーが発生していると通知情報生成部４３２が判断した場合、Ｓ１００５で、通知情報生成部４３２は当該エラーの通知状況を確認し、Ｓ１００６で当該エラーが判定対象の商品に関して初めて検出されたかどうかを判断する。ここで、初めてのエラーが検出されたと通知情報生成部４３２が判断した場合は、Ｓ１００７に移る。Ｓ１００７で、通知情報生成部４３２は未通知のエラーリストを作成する。一方、エラーの検出が初めてではないと通知情報生成部４３２が判断した場合は、Ｓ１００８に移り、通知情報生成部４３２は通知済みのエラーリストを作成する。以上、Ｓ１００４−Ｓ１００８の処理を、対象商品を構成する全ての部品に対して実行する。Ｓ１００９で、通知情報生成部４３２は通知済みのエラーリストがあるかどうかを判断する。前記通知済みのエラーリストがある場合は、Ｓ１０１６に移る。前記通知済みのエラーリストがない場合は、Ｓ１０１０に移る。Ｓ１０１０で、通知情報生成部４３２は未通知のエラーリストがあるかどうかを判断する。前記未通知のエラーリストがある場合、通知情報生成部４３２はＳ１０１１に移る。前記未通知のエラーリストがない場合は当該商品に対する処理を完了し、次の商品に対する処理に移る。

Ｓ１００５で、通知情報生成部４３２は、進捗テーブル４４３の通知フラグを参照し、判定対象の商品に関する通知状況を確認する。次に、Ｓ１００６で、通知情報生成部４３２は、進捗テーブル４４３の通知フラグが「Ｔｒｕｅ」となっている場合は通知済みであると判断し、「Ｆａｌｓｅ」であると判断した場合は、通知済みでないと判断する。
なお、既にエラーが発生している場合において、２回目のログファイル取得でエラーが検知された場合、通知回数削減のためにエラー通知は行わない。そのかわり、当該エラーはリカバリ情報の一部として通知する。

ここで、通知情報生成部４３２が未通知のエラーリストがあると判断した場合、Ｓ１０１１にて、通知情報生成部４３２は、進捗テーブル４４３からエラー情報を取得する。次に、Ｓ１０１２にて、通知情報生成部４３２は、エラー情報を前記商品単位でまとめ、出力先装置６００に応じたメッセージを作成する。その際、通知情報生成部４３２は、メッセージ作成後、進捗テーブル４４３のエラーが生じた部品の通知フラグを「Ｔｒｕｅ」に変更する。

次に、Ｓ１０１３で、出力部４３５は、通知構成情報ファイル８００に記述された宛先８４０のＰｒｏｄｕｃｔＩＤ属性に特定の商品番号が記載されているかどうかを判断する。ここで、宛先８４０のＰｒｏｄｕｃｔＩＤ属性に特定の商品番号が記載されていると出力部４３５が判断した場合、Ｓ１０１４へ進む。そして、Ｓ１０１４で、出力部４３５は、ＰｒｏｄｕｃｔＩＤ属性にて指定された商品番号に合致する商品のみ、通知情報生成部４３２が作成したメッセージを当該宛先に通知する。
一方、Ｓ１０１３で、宛先８４０のＰｒｏｄｕｃｔＩＤ属性が空白であると出力部４３５が判断した場合、Ｓ１０１５で、出力部４３５は、すべての商品に関して通知情報生成部４３２が作成したメッセージを当該宛先に通知する。

一方、Ｓ１００９で、通知済みエラーリストがあると通知情報生成部４３２が判断した場合、Ｓ１０１６にて、復旧情報取得部４３３は、進捗テーブル４４３の復旧フラグを参照する。そして、復旧情報取得部４３３は、判定対象の商品を構成する部品の中でエラーが復旧した部品が１つでも存在するかどうかを判断する。ここで、商品に復旧フラグが１つでも存在すると、復旧情報取得部４３３が判断した場合は、リカバリ通知対象とする。
このため、Ｓ１０１７にて、復旧していると復旧情報取得部４３３が判断した場合はＳ１０１８へ進む。そして、Ｓ１０１８で、復旧情報取得部４３３が当該部品の工程一覧と進捗状況を工程テーブル４４２と進捗テーブル４４３から取得する。
一方、Ｓ１０１７で、エラーが復旧していないと復旧情報取得部４３３が判断した場合はＳ１０２１に移る。そして、Ｓ１０２１で、復旧情報取得部４３３は、エラー通知から通知構成情報ファイル８００の時間指定項目８４１で指定された一定時間が経過しているかどうかを判断する。ここで、一定時間経過していると復旧情報取得部４３３が判断した場合、エラー通知アプリ４３０は、Ｓ１０１８へ処理を移す。一方、Ｓ１０２１で、一定時間経過していないと復旧情報取得部４３３が判断した場合、次の項目に対する処理に移る。

そして、Ｓ１０１９で、リカバリ情報生成部４３４は、復旧情報取得部４３３が取得した工程一覧と進捗状況を基に、リカバリ情報を作成する。具体的には、復旧されたエラーに関連する商品に対する工程それぞれの進捗状況のうち「Ｗａｉｔｉｎｇ」と「Ｅｒｒｏｒ」のものを進捗テーブル４４３から取得し、図１２に一例を示すリカバリ情報を作成する。本実施形態では、リカバリ情報生成部４３４が復旧したエラー情報を除いて未対応のエラー情報と、進捗情報とから再開すべき処理を特定するリカバリ情報を含む通知情報を生成する例を示している。

なお、進捗状況が「Ｃｏｍｐｌｅｔｅｄ」の処理は再処理が必要ないので、リカバリ情報には含めないように制御している。そして、出力部４３５は、Ｓ１０２０にて、リカバリ情報生成部４３４が作成した前記リカバリ情報を通知構成情報ファイル８００に記述された宛先８４０に通知する。Ｓ１０２０の処理が終了した後、通知情報生成部４３２は、Ｓ１０１０の処理を実行する。これにより、リカバリ情報作成中に新たなエラーが発生した場合にも対応すること可能となる。以上で、本通知処理に関する処理が終了する。
ここで、図５を用いて図１４の処理を具体的に説明する。なお、図５では、画像補正工程の本文と、ＰＤＦレイアウト工程の帯でエラーが発生しているとする。

Ｓ１００４で、通知情報生成部４３２が進捗テーブル４４３の進捗欄を確認する。本文にエラーが発生しているので、本文の通知フラグを確認する。図５の進捗テーブル４４３では、本文の通知フラグがＦＡＬＳＥなので、通知情報生成部４３２がＳ１００７で本文を未通知エラーリストに登録し、残り部品の処理を行う。その結果、進捗テーブル４４３では、ＰＤＦレイアウト工程の帯にエラーが発生しているので、通知情報生成部４３２がＰＤＦレイアウト工程の帯の通知フラグを確認する（Ｓ１００６）。ＦＡＬＳＥなので、通知情報生成部４３２がＳ１００７でＰＤＦレイアウト工程の帯を未通知エラーリストに登録する。

商品１を構成する全ての工程の全ての部品の処理が完了したら、通知情報生成部４３２の処理はＳ１００９に進む。この時点では、通知済みのエラーリストは作成されてなく、かつ、未通知のエラーリストが作成されているで、通知情報生成部４３２の処理はＳ１０１１に進み、画像補正工程の本文とＰＤＦレイアウト工程の帯のエラー内容を進捗テーブル４４３から取得する。具体的には、「画像補正失敗」と「面付け失敗」が取得される。

通知情報生成部４３２は、Ｓ１０１１にて取得したエラー内容を元にメッセージを作成する。具体的には、図１１のメッセージ９４０のようなメッセージが作成される。なお、画像補正工程の本文とＰＤＦレイアウト工程の帯でエラーが発生した場合を想定しているので、メッセージ９４０からは９４２のメッセージが除かれたメッセージがＳ１０１２で作成される。Ｓ１０１３、Ｓ１０１４、Ｓ１０１５にて、通知処理を行う。

一定時間が経過した後、ログ取得が再度実行されると、Ｓ１００４で、通知情報生成部４３２が進捗テーブル４４３の進捗欄を確認する。本文にエラーが発生しているので、Ｓ１００５で、通知情報生成部４３２が画像補正工程の本文の通知フラグを確認すると、ＴＲＵＥなので、Ｓ１００８に進む。
通知情報生成部４３２が本文を通知済みのエラーリストに登録する。残りの部品についても同様の処理を行うと、ＰＤＦレイアウト工程の帯を通知済みのエラーリストに登録する。すべての部品の処理が完了したら、通知情報生成部４３２はＳ１００９に進む。この時点では、通知済みのエラーリストは作成されているので、通知情報生成部４３２はＳ１０１６に進む。

復旧情報取得部４３３は画像補正工程の本文のエラー復旧状況を確認すると、復旧フラグがＴＲＵＥになっているので、本文の各工程の進捗状況を取得する。具体的には、受注登録工程、画像補正工程、ＰＤＦレイアウト工程、ジョブ作成工程、ジョブ発行工程の各工程の本文の進捗状況が取得される。
そして、次のエラー部品の処理に移り、Ｓ１０１６で、復旧情報取得部４３３はＰＤＦレイアウト工程の帯のエラー復旧状況を確認する。復旧フラグがＦＡＬＳＥになっているので、Ｓ１０２１に移る。

Ｓ１０２１で、復旧情報取得部４３３は一定時間が経過しているかどうかを判断する。一定時間が経過している場合、各工程の帯の進捗状況をリカバリ情報に記述すると判断し、Ｓ１０１８に進む。

そして、Ｓ１０１９で、リカバリ情報生成部４３４は、復旧情報取得部４３３が取得した各工程の進捗状況を基に、リカバリ情報を作成する。具体的には、エラーが発生した部品に対する各工程の進捗状況のうち「Ｗａｉｔｉｎｇ」と「Ｅｒｒｏｒ」のものを進捗テーブル４４３から取得し、図１２に一例を示すリカバリ情報を作成する。本実施形態では、復旧されていないエラー情報と進捗情報とから再開すべき処理を特定するリカバリ情報を含む通知情報を生成する例を示している。

本実施形態によれば、１つの商品を成している複数の部品に関する処理それぞれがエラーを起こした場合において、商品単位で集約した１つの通知情報を生成し、これを管理者に通知するので、エラーの通知回数を削減することができる。
また、エラー復旧時点で、商品に関連付いた処理の進捗状況を基に１つの通知情報を生成し、これを管理者に通知するので、リカバリ時の作業者の作業を明白にすることができる。
また、リカバリ情報は商品単位で通知する形態で記載しているが、復旧手段が同一であれば、復旧手段単位でまとめて通知することも可能である。

本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン（コンピュータ）等の処理装置（ＣＰＵ、プロセッサ）にて実行することでも実現できる。

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。

４３０ エラー通知アプリ
４３１ エラー情報取得部

Claims (6)

1. 受注する印刷注文に対応する商品を構成する部品を生成する複数の工程のいずれか１つにおいて、前記部品に行う第１の処理と、前記複数の工程のいずれか１つにおいて、前記商品を構成する部品のうち、前記第１の処理が実行される部品とは異なる部品に行う第２の処理を並行して実行する実行手段と、
   前記第１の処理によって得られた第１のログと前記第２の処理によって得られた第２のログとを集約する集約手段と、
   前記集約手段によって集約されたログに基づいて、前記第１の処理乃至前記第２の処理において生成された部品に関する情報と前記生成された部品が生成された工程に関する情報とを格納する格納手段と、
   前記第１の処理と前記第２の処理の結果がエラーであった場合、前記格納手段によって格納されたログに基づいて、前記第１の処理及び第２の処理に対応する工程に関する情報と前記工程において生成されていた前記部品に関する情報とを取得しエラー通知を生成する第１の生成手段と、
   前記第１の生成手段によって生成されたエラー通知を通知する通知手段と、
   を備えることを特徴とする情報処理装置。
2. 前記エラーが復旧しているかどうかを判断する判断手段と、
   前記エラーが復旧していると判断されることに応じて、再開すべき処理を特定するリカバリ情報を含むリカバリ通知を生成する第２の生成手段と、を備え、
   前記通知手段は、前記第２の生成手段によって生成された前記リカバリ通知を通知することを特徴とする請求項１記載の情報処理装置。
3. 前記複数の工程は、印刷すべき画像データの画像補正工程、印刷すべき画像データのレイアウト工程および画像形成装置に出力するジョブを作成するジョブ作成工程の少なくとも１つを含むことを特徴とする請求項１又は２に記載の情報処理装置。
4. 受注する印刷注文に対応する商品を構成する部品を生成する複数の工程のいずれか１つにおいて、前記部品に行う第１の処理と、前記複数の工程のいずれか１つにおいて、前記商品を構成する部品のうち、前記第１の処理が実行される部品とは異なる部品に行う第２の処理を並行して実行する実行ステップと、
   前記第１の処理によって得られた第１のログと前記第２の処理によって得られた第２のログとを集約する集約ステップと、
   前記集約ステップによって集約されたログに基づいて、前記第１の処理乃至前記第２の処理において生成された部品に関する情報と前記生成された部品が生成された工程に関する情報とを格納する格納ステップと、
   前記第１の処理と前記第２の処理の結果がエラーであった場合、前記格納ステップによって格納されたログに基づいて、前記第１の処理及び第２の処理に対応する工程に関する情報と前記工程において生成されていた前記部品に関する情報とを取得しエラー通知を生成する第１の生成ステップと、
   前記第１の生成ステップによって生成されたエラー通知を通知する通知ステップと、
   を備えることを特徴とする制御方法。
5. 前記エラーが復旧しているかどうかを判断する判断ステップと、
   前記エラーが復旧していると判断されることに応じて、再開すべき処理を特定するリカバリ情報を含むリカバリ通知を生成する第２の生成ステップと、を備え、
   前記通知ステップでは、前記第２の生成ステップによって生成された前記リカバリ通知を通知することを特徴とする請求項４記載の制御方法。
6. 受注する印刷注文に対応する商品を構成する部品を生成する複数の工程のいずれか１つにおいて、前記部品に行う第１の処理と、前記複数の工程のいずれか１つにおいて、前記商品を構成する部品のうち、前記第１の処理が実行される部品とは異なる部品に行う第２の処理を並行して実行する実行ステップと、
   前記第１の処理によって得られた第１のログと前記第２の処理によって得られた第２のログとを集約する集約ステップと、
   前記集約ステップによって集約されたログに基づいて、前記第１の処理乃至前記第２の処理において生成された部品に関する情報と前記生成された部品が生成された工程に関する情報とを格納する格納ステップと、
   前記第１の処理と前記第２の処理の結果がエラーであった場合、前記格納ステップによって格納されたログに基づいて、前記第１の処理及び第２の処理に対応する工程に関する情報と前記工程において生成されていた前記部品に関する情報とを取得しエラー通知を生成する生成ステップと、
   前記生成ステップによって生成されたエラー通知を通知する通知ステップと、
   を備えることを特徴とする制御方法をコンピュータに実行させるためのプログラム。

Images