JP5774070B2 - サーバ装置、サーバ装置の制御方法、及びプログラム - Google Patents

Description

本発明は、サーバ装置、サーバ装置の制御方法、及びプログラムに関する。

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

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

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

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

しかしながら、特許文献１の方法では、同一種類のエラーの通知回数を削減することができるが、異なる種類のエラーの通知回数を削減することは難しい。すなわち、受注、画像処理、印刷処理等を含む複数の工程の処理を実行する場合、発生し得るエラーは、同一種類とは限らないため、複数種類が同時に通知されると、その状況を確認するために、作業者側の操作負荷が増大してしまう恐れがある。

また、エラー通知を受けた作業者は、受信したエラー通知の異常を修復するために復旧作業を行うが、複数のエラー通知を受けても、どのように、どの順番で復旧したらよいのか容易に認識することが難しい。従って、各工程における処理が並列的に実行されている場合は、さらに作業者の負担が重くなる場合があった。

本発明は、上記課題を鑑みてなされたものであり、システムのエラー情報を作業者に通知する回数を削減し、かつエラー発生時の復旧手段、復旧順序を明確にし、エラー発生時の復旧効率を向上させるサーバ装置を提供することを目的とする。

上記課題を解決するために、本発明に係るサーバ装置は、受注する注文に対応する商品を構成する部品に対して行う処理のログを取得する取得手段と、前記取得手段により取得した前記ログに基づいて前記処理の工程毎にエラー情報を生成する生成手段と、前記生成手段により生成した前記エラー情報を解析して復旧手順毎に通知情報を集約する通知情報集約手段と、前記通知情報を順次読み込んで、前記通知情報における前記復旧手順が既に読み込んだ復旧手順と同一である場合に、前記復旧手順に対応する前記注文におけるジョブＩＤを前記通知情報に統合する統合手段と、前記通知情報を通知する通知手段と、を備え、前記通知手段は、前記復旧手順が既に読み込んだ復旧手順と同一でない場合、前記統合手段により統合することなく、前記通知情報を通知することを特徴とする。

本発明によれば、システムのエラー情報を作業者に通知する回数を削減し、かつエラー発生時の復旧手段、復旧順序を明確にし、エラー発生時の復旧効率を向上させるサーバ装置を提供することができる。

印刷システムにおける注文を示す図である。 印刷システムの構成を示すブロック図である。 図２に示した管理サーバの構成を示すブロック図である。 サーバ装置が管理する処理工程を示す図である。 管理サーバのハードウェア構成を示すブロック図である。 エラー通知サービスのモジュール構成を示す図である。 データベース構造を示す図である。 処理工程の優先度を示す図である。 通知するメッセージフォーマットを示す図である。 サーバ装置の制御方法を示すフローチャートである。 本発明の一実施形態に係る通知処理を示すフローチャートである。 本発明の一実施形態に係るデータベース構造を示す図である。 本発明の一実施形態に係るデータベース構造を示す図である。 本発明の一実施形態に係るデータベース構造を示す図である。 本発明の一実施形態に係る通知情報のメッセージの一例を示す図である。 本発明の一実施形態に係る通知情報のメッセージの一例を示す図である。 本発明の一実施形態に係る通知情報のメッセージの一例を示す図である。 本発明の一実施形態に係る復旧手順毎の通知情報を模式化した図である。 本発明の一実施形態に係る復旧手順毎の通知情報を模式化した図である。 本発明の一実施形態に係る復旧手順毎の通知情報を模式化した図である。

以下、本発明を実施するための形態について図面などを参照して説明する。

図１は、本実施形態の印刷システムにおける注文の一例を示す図である。まず、注文１は、１以上の商品で構成される注文である。本実施形態において、商品とは、フォトブック２とする。フォトブック２は、本文３と表紙４、帯５、ジャケット６で示す複数の部品で構成される。各部品のコンテンツは、それぞれ１つのＰＤＦとして入稿され、該ＰＤＦ中に画像が配置されている。また、各部品は、フォトブックを生産するために各種ジョブに分割される。本文３は、本文印刷ジョブ７、表紙印刷ジョブ８に分割され、帯５は、帯印刷ジョブ９、帯５を断裁するパラメータを格納する断裁ジョブ１０に分割される。また、ジャケット６は、ジャケット印刷ジョブ１１、ジャケット６を断裁するパラメータを格納する断裁ジョブ１２に分割される。

次に、図２を参照して、第１実施形態に係る印刷システムの構成を説明する。図２は、印刷システムの構成を示すブロック図である。まず、注文サーバ１００は、ＷＡＮ等のネットワーク２００を介して印刷ラボ３００と通信可能に接続されている。なお、本実施形態に係る注文サーバ１００は、Ｗｅｂ経由の入稿システムである。

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

印刷ラボ３００において、管理サーバ４００は、注文サーバ１００から発行された注文１を、ネットワーク２００を介して受注し、受注した注文１を管理する。プリンタ装置５００は、本文３、表紙４、帯５、ジャケット６の各印刷物を生成する。出力先装置６００は、管理サーバ４００で発生したエラーの通知情報を送信する。なお、本実施形態において、出力先装置６００として、携帯電話を用いているが、クライアントコンピュータやスマートフォン（高機能携帯電話）、タブレット（多機能携帯端末）等を用いてもよい。断裁装置７００は、断裁ジョブに格納されたパラメータに従ってプリンタ装置５００から出力された帯５、ジャケット６の用紙に断裁処理を行う。

図３は、図２に示した管理サーバ４００の構成を示すブロック図である。まず、受注サービス３０１は、注文サーバ１００からネットワーク２００を介して注文１を受注する。プリプレスサービス３０２は、受注した注文１に対して、部品毎にレイアウト処理を実行する。ジョブ作成サービス３０３は、部品毎に後述するジョブを生成する。ジョブ発行サービス３０４は、部品毎にプリンタ装置５００、断裁装置７００にジョブの送信を行う。

エラー通知サービス３０５は、本実施形態に係る受注サービス３０１、プリプレスサービス３０２、ジョブ作成サービス３０３、およびジョブ発行サービス３０４が出力するログファイルを取得する。そして、エラーが発生していた場合、出力先装置６００にエラーの通知処理を行う。データベース３０６は、後述する各種データを格納する領域である。

次に、図４は、図３で示した受注サービス３０１、プリプレスサービス３０２、ジョブ作成サービス３０３、およびジョブ発行サービス３０４の処理の流れを示す図である。まず、受注サービス３０１は、注文１を受信すると、プリプレスサービス３０２に対して受注登録４０１を行う。受注登録４０１を受けたプリプレスサービス３０２は、部品毎のレイアウト処理を行う。即ち、本文レイアウト４０２、表紙レイアウト４０３、帯レイアウト４０４、ジャケットレイアウト４０５の処理を行う。

各部品のレイアウト処理が終了するとプリプレスサービス３０２は、ジョブ作成サービス３０３に各部品に対するジョブの作成を依頼する。即ち、本文レイアウト４０２の処理が終了すると、本文ジョブ作成４０６が行われる。同様に、表紙レイアウト４０３の処理が終了すると、表紙ジョブ作成４０７が行われ、帯レイアウト４０４の処理が終了すると、帯ジョブ作成４０８が行われ、ジャケットレイアウト４０５の処理が終了するとジャケットジョブ作成４０９が行われる。

ジョブ作成サービス３０３で各ジョブが作成されると、ジョブ発行サービス３０４で、ジョブの送信処理が行われる。即ち、本文ジョブ作成４０６が終了すると本文印刷ジョブ送信４１０がプリンタ装置５００に対して行われる。同様に、表紙ジョブ作成４０７が終了すると、表紙印刷ジョブ送信４１１が行われる。また、帯ジョブ作成４０８は、帯印刷ジョブ４１２と帯断裁ジョブ４１３の２つのジョブを作成し、それぞれプリンタ装置５００、断裁装置７００に送信する。同様に、ジャケットジョブ作成４０９は、ジャケット印刷ジョブ４１４とジャケット断裁ジョブ４１５の２つのジョブを作成し、それぞれプリンタ装置５００、断裁装置７００に送信する。

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

なお、本実施形態において、出力装置５０４は、ディスプレイなどの表示装置であり、一般的に出力装置に含まれるプリンタ装置５００と区別されて構成される。また、入力装置５０５は、キーボード、ポインティングデバイス等で構成される。なお、後述のフローチャートで示す工程は、管理サーバ４００の主記憶装置５０１、補助記憶装置５０２、ＲＯＭ５０３のいずれかに記憶され、中央処理装置５００により実行される。さらに、補助記憶装置５０２は、ハードディスク、光磁気ディスクで構成されてよく、若しくはこれらの組み合わせで構成されてもよい。また、それぞれの装置がネットワークを介して接続されていようとも、本実施形態を制約するものではない。

図６は、図３に示した管理サーバ４００内のエラー通知サービス３０５のモジュール構成を示す図である。まず、エラー通知サービス３０５は、エラー情報取得部（取得手段）６０１、通知情報生成部（生成手段）６０２、出力部（通知手段）６０３から構成される。エラー情報取得部６０１は、受注サービス３０１、プリプレスサービス３０２、ジョブ作成サービス３０３、ジョブ発行サービス３０４が出力するログファイルを一定間隔で取得し、当該取得したログファイルを解析する。そして、当該ログファイルの解析後、取得したエラー情報を図７で後述するデータベース３０６内の進捗テーブル７０３に書き込む。

通知情報生成６０２は、後述の進捗テーブル７０３の進捗を参照し、エラー情報がある場合、進捗テーブル７０３から当該エラー情報を取得し、後述する図９に示すフォーマットのメッセージを作成する。具体的には、通知情報生成部６０２は、不図示の通知情報集約手段を有し、エラー情報取得部６０１が作成した進捗情報から取得した複数のエラー情報を解析して、作業者が行う復旧作業の復旧手順毎に集約し、通知情報を生成する。また、出力部６０３は、通知情報生成部６０２が生成した通知情報を出力先装置６００に通知する。

図７は、エラー通知サービスがデータベース３０６で管理するデータの構造を示す図である。図７を参照して、データベース３０６は、商品テーブル７０１、大工程テーブル７０２、進捗テーブル７０３で構成される。また、商品テーブル７０１には、注文ＩＤと、当該注文ＩＤに対応する受注した商品の１つが格納される。商品テーブル７０１の注文ＩＤのそれぞれは、大工程テーブル７０２と関連づけられている。また、大工程テーブル７０２は、商品を作るために印刷システムで行われる工程が定義されている。本実施形態では、受注サービス３０１が行う受注登録工程、プリプレスサービス３０２が行うプリプレス（レイアウト）工程、ジョブ作成サービス３０３が行うジョブ作成工程、ジョブ発行サービス３０４が行うジョブ発行工程が定義されている。さらに、大工程テーブル７０２に定義された工程それぞれに、進捗テーブル７０３が関連付けられている。なお、本実施形態において、進捗テーブル７０３は、エラー情報を含む、各工程の進捗を記録したテーブルである。

次に、進捗テーブル７０３について説明する。まず、注文番号格納領域７０４は、工程の注文を一意に識別する識別子（注文ＩＤ）が格納される領域である。工程格納領域７０５は、図４で示した部品毎の工程を格納する領域である。ジョブＩＤ格納領域７０６は、各工程のジョブを一意に識別する識別子（ジョブＩＤ）が格納される領域である。進捗情報格納領域７０７は、エラー情報を含む各工程の進捗情報が記載される領域である。復旧コード格納領域７０８は、工程でエラーが発生した際の、復旧手段を一意に識別する復旧コードが格納される領域である。エラー対象格納領域７０９は、実際にエラーの原因となった対象が格納される領域である。復旧方法格納領域７１０は、作業者がエラーを復旧するための方法が記載される領域である。発生時刻格納領域７１１は、実際にエラーが発生した時刻を識別する情報が格納される領域である。

図８は、エラー通知サービスがデータベース３０６で管理する工程優先度テーブルの構造を説明する図である。まず、工程８０１は、各工程を識別する情報が格納され、工程優先度８０２は、工程８０１に対応する工程毎の優先度が記載される領域である。実際には、後述するような優先度に従って、復旧情報の通知順が決定される。

図９は、図７に示した通知情報生成部６０２が作成するメッセージの構成を説明する図である。図９を参照して、時刻９０１は、通知の作成時刻を示し、通し番号９０２は、当該通知が全体通知の何番目か（通し番号）を示し、復旧メッセージ９０３は、作業者に対してエラーを復旧するためのメッセージを示す。また、注文番号９０４は、エラーが発生している注文番号（注文ＩＤ）を示し、ジョブ番号９０５は、当該エラーが発生しているジョブ番号（ジョブＩＤ）を示す。なお、これらの番号は、進捗テーブル７０３から取得した情報から作成され、出力装置６００に送信される。

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

まず、Ｓ１０００で、エラー情報取得部６０１は、図３で示した各種サービスが出力するログファイルを読み込む（取得する）。次に、Ｓ１００１で、Ｓ１０００において取得したログファイルを解析する。次に、Ｓ１００２で、Ｓ１００１における解析結果を進捗テーブル７０３に書き込む。そして、Ｓ１００３で、通知情報生成部６０２は、図１１のフローチャートで示す通知処理を実行する。

図１１は、本実施形態に係る通知処理を示すフローチャートである。まず、Ｓ１１００で、通知情報生成部６０２は、進捗テーブル７０３からすべてのエラー情報を読み込む。次に、Ｓ１１０１で、作業者の復旧方法を識別する復旧コードがすでに読み込んだエラーと同一であるか否かを判定する。復旧コードが既に読み込んだエラー情報と同一でないと判定された場合（Ｎｏ）、Ｓ１１０２に移行し、Ｓ１１０２で、復旧コードに対応する通知情報を作成する。一方、Ｓ１１０１で、復旧コードが既に読み込んだエラー情報と同一と判定された場合（Ｙｅｓ）、Ｓ１１０３に移行する。通知情報生成部６０２は、不図示の統合手段を更に有し、Ｓ１１０３で、統合手段は、既にＳ１１０２において作成された通知情報に注文番号、ジョブ番号を統合する。なお、この処理は、全ての進捗テーブル内のエラー情報が読み込まれるまで行われる。

次に、Ｓ１１０４で、Ｓ１１０２またはＳ１１０３において復旧コード毎にまとめられた通知情報に対して、発生時刻（時間）を基準として通知順を決定する。そして、Ｓ１１０５で、Ｓ１１０４において決定された通知順を、図８で示した工程優先度順に従って、再度決定する。次に、Ｓ１１０６で、仕掛り注文がある否かを判定する。仕掛り注文があると判定された場合（Ｙｅｓ）、Ｓ１１０７に移行し、Ｓ１１０７で、仕掛り注文を含む通知を先頭の通知と設定する。ここで、仕掛り注文とは、作業者が作業を開始した注文のことを示しており、例えば、同じ商品を構成する部品の一部がプリンタから出力された注文のことを示している。一方、仕掛り注文が無いと判定された場合（Ｎｏ）、すなわち、全ての通知情報の生成が終了した場合、Ｓ１１０８に移行し、Ｓ１１０８で、図９に示すような作業者に対する通知情報を生成し、Ｓ１１０９で、通知を行う。

以下、図１０および図１１のフローチャートを用いて具体例を詳述する。ここで、本実施形態において、図１８は、本実施形態に係るフローチャートに従って最終的に通知を行う復旧手順毎の通知情報を模式化した図である。復旧コード１８０１は、復旧手段を一意に識別するコードを示し、注文ＩＤ１８０２は、復旧コード１８０１で識別される復旧手段で復旧する注文ＩＤであり、ジョブＩＤ１８０３は、復旧コード１８０１で識別される復旧手段で復旧するジョブＩＤを示す。また、復旧方法１８０４は、復旧コードで識別される作業者に対する復旧方法を示している。さらに、通知順１８０５は、作業者に通知する順番を示す。

なお、本実施形態では、図１２で示すように、商品１、商品２、商品３が並行して製造されているとする。このとき、商品１は、ジョブ発行工程１２０９で、行１２０１〜１２０６で示すエラーが発生している。商品２は、受注登録工程１２１０で、行１２０７で示すエラーが発生している。商品３は、受注登録工程１２１１で、行１２０８で示すエラーが発生している。

以上から、商品１の製造の際、行１２０１〜１２０６に示すエラーは、ジョブ発行サービス３０４がログに出力していることを示す。また、商品２の製造の際、行１２０７に示すエラーは、受注サービス３０１がログに出力していることを示す。さらに、商品３の製造の際、行１２０８に示すエラーは、受注サービス３０１がログに出力していることを示す。

このとき、上記のＳ１０００で、エラー通知サービスは、各サービスのログを収集し、Ｓ１００１においてログを解析し、Ｓ１００２においてログ情報から進捗テーブル７０３に情報を書き込む。本実施形態では、書き込まれたデータが図１２に示される。そして、Ｓ１１００で、進捗テーブル７０３を読み込み、Ｓ１１０１において既に読み込んだエラーと復旧コードが同一か否かを判定する。

次に、図１２に示す行１２０１に示すエラーの読み込みの際、復旧コード“１２３“に相当するエラーは初めての読み込みとなり、当該情報は、図１８の行１８０６で示す。次に、行１２０２に示すエラーの処理の際、復旧コードは、行１２０１に示すエラーと同じ“１２３”であり、Ｓ１１０３に進み、注文番号、ジョブ番号が統合される。なお、注文番号は、行１２０１に示すエラーと同じであり、ジョブ番号が違うので該情報は、行１８０７のように追記される。そして、行１２０３に示すエラーの処理の際、復旧コードはエラー１２０１と同じ“１２３”であることから、Ｓ１１０３に進み、注文番号、ジョブ番号が統合される。

次に、行１２０４に示すエラーの処理の際、復旧コードは、“１２４”であり、復旧コード“１２４”に相当するエラーは初めての読み込みとなり、Ｓ１１０２において、行１８０８として書き込まれる。以下、同様に、最終的な通知情報は、全ての行１２０１〜１２０８に示すエラーを処理した結果、図１８に示す表となる。

次に、Ｓ１１０４で、復旧コード毎にまとめられた図１８に示す通知情報において、同一の復旧コード内の最も発生時刻が早いエラーを基準として、発生時刻が早い順に、全ての復旧コードの通知順１８０５が決定される。つまり、通知順１８０５で示すように、通知順は、復旧コード１２３、復旧コード１２４、復旧コード１０１の順になり、図１８に示すような通知順１８０５が決定される。

そして、Ｓ１１０５で、工程優先度順に並べ替える。ここで、工程優先度は、図８に示しているが、本実施形態では、印刷工程である復旧コード１２３が最も高く、次に断裁工程である復旧コード１２４、最後に、受注登録である復旧コード１０１となる。従って、Ｓ１１０５において、通知順は、通知順１８０５の通りで変更されない。また、Ｓ１１０６で、作業者工程を途中まで始めている仕掛け注文は、存在しないのでＳ１１０８に進み、通知情報が生成される。

この時、通知する通知情報のメッセージ例を図１５に示す。つまり、図１８の通知順１８０５に示した通知順に従って、図１５に示す通知情報のメッセージが通知される。行１８０６に示す情報が最初に通知される通知情報であり、この時の復旧メッセージ１５０２は、復旧方法１８０４に該当する。また、注文ＩＤ１５０３、ジョブＩＤ１５０４は、それぞれ注文ＩＤ１８０２、ジョブＩＤ１８０３に該当する。

次に、行１８０８で示した通知情報が２番目に通知される。この時の復旧メッセージ１５０６は、復旧方法１８０４に該当する。同様に、注文ＩＤ１５０７、ジョブＩＤ１５０８は、それぞれ注文ＩＤ１８０２、ジョブＩＤ１８０３に該当する。

最後に行１８０９で示した部分が通知情報１５０９として最後に通知される。この時の復旧メッセージは、復旧方法１８０４に該当する。同様に、注文ＩＤ１５１１、ジョブＩＤ１５０２は、それぞれ注文ＩＤ１８０２、ジョブＩＤ１８０３に該当する。最後にＳ１１０９において、図１５のメッセージが通知順に出力装置６００に通知される。

次に、図１２と同様に、図１３で示すように、商品１、商品２、商品３が並行して製造されているとする。商品１は、エラーが発生せず、商品２は、ジョブ発行工程において、行１３０１〜１３０６で示すエラーが発生し、商品３は、ジョブ発行工程において、行１３０７〜１３１２で示すエラーが発生している。この時の処理を図１０および図１１のフローチャートを用いて詳述する。

まず、商品２の製造の際、行１３０１〜１３１２に示すエラーは、ジョブ発行サービス３０４がログに出力している。このとき、Ｓ１０００において、エラー通知サービスは、ジョブ発行サービス３０４のログを取得し、Ｓ１００１においてログを解析し、Ｓ１００２においてログ情報から進捗テーブル７０３に情報を書き込む。なお、本実施形態では、書き込まれたデータを図１３に示す。

次に、Ｓ１１００において、進捗テーブルを読み込み、Ｓ１１０１においてすでに読み込んだエラーと復旧コードが同一かどうかを判定する。図１３のエラー１３０１を読み込む際、復旧コード”１２３”に相当するエラーは初めての読み込みとなり、通知情報を図１９の行１９０１に示す。次に、行１３０２に示すエラーの処理の際、復旧コードは、エラー１３０１と同じ“１２３”であり、Ｓ１１０３に進み、注文番号、ジョブ番号が統合される。なお、注文番号は、行１３０１に示すエラーと同じであり、ジョブ番号が違うので該情報は、行１９０２のように追記される。以下、上記の処理を全ての行１３０３〜１３１２に示すエラーに関して繰り返す。

まず、行１３０７のエラーコードの読み込みの際、Ｓ１１０３において、注文番号、ジョブ番号が統合されるが、注文番号は、通知情報にないので行１９０３のように作成される。以下、同様に、最終的な通知情報は、全ての行１３０１〜１３１２に示すエラーを処理し、その結果を図１９に示す。次に、Ｓ１１０４において、復旧コードごとにまとめられた図１８に示す通知情報において、同一の復旧コード内の最も発生時刻が早いエラーで、全ての復旧コードの通知順１９０４が決定される。つまり、通知洵１９０４で示すように通知順は、復旧コード１０２、復旧コード１２４、復旧コード１０１の順となる。

次に、Ｓ１１０５において工程優先度順に並べ替える。工程優先度は、図８に示しているが、印刷工程である復旧コード１２３が最も高く、次に断裁工程である復旧コード１２４となり、通知順は、Ｓ１１０５において通知順１９０４の通りで変更されない。また、Ｓ１１０６において、作業者工程を途中まで始めている仕掛注文は、存在しないのでＳ１１０８に進み、通知情報が生成される。このときの通知情報を図１６に示す。つまり、図１９の行１９０５で示す部分が通知情報１６０１として最初に通知され、行１９０６で示す部分が通知情報１５０５として２番目に通知される。最後に、Ｓ１１０９において、図１６のメッセージが通知順に出力装置６００に通知される。

次に、図１２と同様に、図１４で示すように、商品１、商品２、商品３が並行して製造されているとする。商品１は、ジョブ発行工程において行１４０１〜１４０２で示すエラーが発生し、商品２は、ジョブ発行工程において、行１４０３〜１４０８で示すエラーが発生し、商品３は、ジョブ発行工程において、行１４０９〜１４１４で示すエラーが発生している。この場合について説明する。

まず、Ｓ１０００において、エラー通知サービスは、ジョブ発行サービスのログを収集し、Ｓ１００１において、ログを解析し、Ｓ１００２において、ログ情報から進捗テーブル７０３に情報を書き込む。本実施形態では、書き込まれたデータを図１４に示す。以下、同様に通知情報を作成するが、Ｓ１１０６において、注文番号０００１で示す商品１がジャケット断裁工程、帯断裁工程でエラーが発生している仕掛り注文となっている。この場合、Ｓ１１０７において、本工程を含む復旧コード１２４が優先され、図２０に示す通知順２００１のように通知順が変更される。このときの通知情報を図１７に示し、Ｓ１１０９において出力装置６００に通知される。

以上、本実施形態によれば、１つの商品を成している複数の部品に関する処理それぞれがエラーを起こした場合、復旧手順で集約した１つの通知情報を生成し、復旧すべき通知順に作業者に通知する。従って、エラーの通知回数を削減し、かつ容易に復旧作業を行うことができる。

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

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、材質、形状、寸法、形態、数、配置箇所等は、その要旨の範囲内で種々の変形および変更が可能である。

６０１ エラー情報取得部
６０２ 通知情報生成部
６０３ 出力部

Claims (11)

1. 受注する注文に対応する商品を構成する部品に対して行う処理のログを取得する取得手段と、
   前記取得手段により取得した前記ログに基づいて前記処理の工程毎にエラー情報を生成する生成手段と、
   前記生成手段により生成した前記エラー情報を解析して復旧手順毎に通知情報を集約する通知情報集約手段と、
   前記通知情報を順次読み込んで、前記通知情報における前記復旧手順が既に読み込んだ復旧手順と同一である場合に、前記復旧手順に対応する前記注文におけるジョブＩＤを前記通知情報に統合する統合手段と、
   前記通知情報を通知する通知手段と、を備え、
   前記通知手段は、前記復旧手順が既に読み込んだ復旧手順と同一でない場合、前記統合手段により統合することなく、前記通知情報を通知する
   ことを特徴とする情報処理装置。
2. 前記通知手段は、前記復旧手順の優先度が高い順番で通知することを特徴とする請求項１に記載の情報処理装置。
3. 前記通知手段は、前記エラーが発生した前記工程の優先度に基づく順番で前記通知情報を通知することを特徴とする請求項１に記載の情報処理装置。
4. 前記通知手段は、前記エラーが発生した時間に基づく順番で前記通知情報を通知することを特徴とする請求項１に記載の情報処理装置。
5. 前記注文のうち前記処理が既に開始されている注文である仕掛り注文が有る場合、前記通知手段は、前記仕掛り注文に含まれる前記エラーに基づく前記通知情報を最初に通知することを特徴とする請求項１に記載の情報処理装置。
6. 前記工程は、前記注文を受注する受注登録工程と、前記部品のレイアウトを行うプリプレス工程と、前記部品のジョブを作成するジョブ作成工程と、前記ジョブを送信するジョブ発行工程と、を含むことを特徴とする請求項１に記載の情報処理装置。
7. 前記工程の優先度は、受注登録工程、プリプレス工程、ジョブ作成工程、ジョブ発行工程の順番であることを特徴とする請求項３に記載の情報処理装置。
8. 前記集約した通知情報を順次読み込み、前記通知情報における前記復旧手順が既に読み込んだ復旧手順と同一か否かを判定する判定手段をさらに備えることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
9. 情報処理装置の制御方法であって、
   受注する注文に対応する商品を構成する部品に対して行う処理のログを取得する取得工程と、
   前記取得工程において取得した前記ログに基づいて前記処理の工程毎にエラー情報を生成する生成工程と、
   前記生成工程において生成した前記エラー情報を解析して復旧手順毎に通知情報を集約する通知情報集約工程と、
   前記通知情報を順次読み込んで、前記通知情報における前記復旧手順が既に読み込んだ復旧手順と同一である場合に、前記復旧手順に対応する前記注文におけるジョブＩＤを前記通知情報に統合する統合工程と、
   前記通知情報を通知する通知工程と、を有し、
   前記通知工程において、前記復旧手順が既に読み込んだ復旧手順と同一でない場合、前記統合工程において統合することなく、前記通知情報を通知する
   ことを特徴とする情報処理装置の制御方法。
10. 前記集約した通知情報を順次読み込み、前記通知情報における前記復旧手順が既に読み込んだ復旧手順と同一か否かを判定する判定工程をさらに有することを特徴とする請求項９に記載の情報処理装置の制御方法。
11. 請求項１乃至８のいずれか１項に記載の情報処理装置の各手段としてコンピューターを機能させるためのプログラム。
    

Images