JPH0991402A - イメージデータ管理装置 - Google Patents

Abstract

(57)【要約】 【目的】 ワークフローのイメ−ジデ−タ管理装置にお
いて、作業中のシステム障害の発生やユーザによる中断
時にもユーザが更新途中のデータを保護する。 【構成】 サ−バ１００から転送された画像デ−タを複
数のクライアント２００において順に更新するワ−クフ
ロ−システムのイメ−ジデ−タ管理装置において、クラ
イアントには更新中のデータを一時的に蓄積する手段２
３５を設け、サ−バには、画像デ−タベ−ス１４０と、
画像デ−タ蓄積部１４５と、ワ−クフロ−管理部１２０
と、復旧状況管理部１５０とを少なくとも設け、前記復
旧状況管理部１５０は、前記管理装置に障害が発生し画
像デ−タの復旧が要求される場合に更新処理の途中で前
記一時的蓄積手段または画像デ−タ蓄積部に画像デ−タ
が保存されているか否かの管理情報をワ−クフロ−管理
部から引き出して呼び出すべき画像デ−タを特定する機
能を果たすものである。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はクライアント／サーバシ
ステムにおけるイメージデータの管理装置に関わり、特
にある書類の画像データの複数のユーザが順次表示しな
がら次々加工を施していく一般にワークフローと呼ばれ
る利用方法を用いるシステムにおいて、作業中のシステ
ム障害の発生やユーザによる中断時にも作業途中のデー
タを保護するデータ管理装置に関わる。

【０００２】

【従来の技術】大量の画像データを蓄積し、クライアン
トからの要求に応じてＬＡＮ（LocalArea Network:ロー
カル・エリア・ネットワーク）を介してデータを転送す
るシステムとしては従来、電子ファイリングシステムが
ある。この代表的な例としては例えば株式会社日立製作
所のHitFile-6500が知られている。これらのシステムは
光ディスク等の大容量のストレージに文書等の画像を２
値のデータとして蓄積し、ネットワークを介して行われ
るパソコン等のクライアントからの検索要求を実行し該
当するイメ−ジデータを要求元のクライアントに転送、
表示するものである。

【０００３】これらのシステムの主たる用途は複数のユ
ーザが共用し参照する図面等の文書画像を蓄積し、個々
のユーザの独立した要求に応じるものであった。

【０００４】これに対して近年、あらかじめ定められた
順序で複数の担当者間を流れ、各担当者が順次それぞれ
の処置を実行することで業務を行う帳票等の文書を扱う
システムが広まりつつある。これらはワークフローシス
テムと呼ばれ、単なる検索／応答ではなく業務に応じた
文書の流れをあらかじめ定義し書類を画像データとして
登録し、定義されたユーザ間を次々に転送して、各担当
者が画像データあるいはそれに付随するコードデータに
修正・追加を加えていくシステムである。この場合登録
された書類の画像データおよびそれに付随するコードデ
ータは各ユーザ間を動く度に変更が加えられていくこと
になる。

【０００５】従来の電子ファイルシステムではイメージ
データを最初に登録された形態のまま保存し、もし変更
が加えられた場合には新規のイメージデータとして新た
に登録が行われることになる。したがってシステムに障
害が発生した場合においても、登録された時点でのデー
タのみを確保しておけば復旧が可能であった。

【０００６】しかしながらワークフローシステムにおい
ては、処理中の文書は処理の過程で加えれたデータ自体
が重要であり、また各データの時間的整合性を取る必要
がある。これはつまりワークフローが認識している位置
と画像およびコードデータの状況が一致していなければ
ならないことである。これらの課題については、用途が
異なるため従来の電子ファイルシステムでは考慮されて
いない。

【０００７】クライアント／サーバシステムにおいて画
像データを扱う場合の障害対策としては「特公平５−２
５８０２９号公報（画像処理装置）」が公知である。こ
の方式ではイメージデータの転送中に障害が発生した場
合、あらかじめ定めておいた連絡先に障害の発生を通知
する機能を有するもので、処理ごとに通知先を定義する
ことができる。

【０００８】しかしながら、この方式ではデータ自体の
保護については考慮されていない。

【０００９】

【発明が解決しようとする課題】上記の通り従来の方式
ではワークフローシステムに適用した場合、フローの過
程にあるデータを保護する有効な手段がない。また、ユ
ーザがあるデータに追加・更新を加えている最中に処理
を中断する場合、ワークフローの管理下のまま加工中の
データを一時的に保存しておく手段もない。したがっ
て、例えばファイルシステムを２重化するなど既知の方
式によってデータの保護を図っても、ユーザが処理中の
データについてはワークフローが認識した形ではファイ
ル上に蓄積されていないために全くの無防備である。

【００１０】本発明が解決しようとする課題は以下の通
りである。

【００１１】（１）登録後いつくかのユーザによる処理
を経て追加・変更が加えられたデータを保護することが
できない。

【００１２】（２）ワークフローの管理デ−タベ−ス
（ＤＢ）と、画像ＤＢと、検索・管理情報およびコード
データのためのＤＢがそれぞれ独立に存在することか
ら、フロー中に障害が発生した場合、各ＤＢ内容の整合
性を復元することが困難である。

【００１３】（３）ユーザが処理をしている途中経過を
システム全体として蓄積しておく手段がない。個々のユ
ーザレベルにおいてもデータを保護する場合ローカルに
クライアント上に蓄積するとフローからはずれてしまう
ため現実的には利用できない。また、（２）と同様の理
由により、システム全体に障害が生じた場合、ＤＢ中の
データとローカルデータの差異をいかに扱うべきかの判
断を行う有効な手段がない。

【００１４】

【課題を解決するための手段】上記第１の目的を達成す
るために、本発明では以下の手段を有する。

【００１５】（１）ユーザでの処理を終え、画像データ
ベースおよびコード情報のデータベースを更新する場合
に、該データの複製をサーバ中に記録する手段。

【００１６】（２）更新中のデータをクライアント上に
一時的に蓄積する手段。

【００１７】（３）前記更新中データが存在することを
示す記号をデータベース中に蓄積する手段。

【００１８】（４）当該一時データファイルが各時点で
どのクライアント上に一時保存されているかを記録して
おく手段と該記録を読みだす手段。

【００１９】（５）データの復旧が要求された場合に、
その時点でサーバに記録されている前段終了時点での複
製データか、クライアントに記録されている更新中デー
タの一時保存ファイルのいずれからデータを読みだすべ
きか判断する手段。

【００２０】（６）担当者の処理が完了した時点で、処
理の結果更新されたデータをサーバのデータベース中に
蓄積し、該蓄積が確認された時点でサーバ／クライアン
ト上の総ての更新中データを削除する手段。

【００２１】

【作用】以下、本発明の原理と動作を説明する。

【００２２】前記本発明が解決しようとする課題（１）
に対して本発明では、フローに流れている画像データを
その途中段階でバックアップする手段を有する。そのた
め、本発明では本来のデータベースの他にサーバないし
はクライアント上にバックアップのためにフロー中のデ
ータを記録する。

【００２３】また、これらの記録されたデータを利用す
るためには、システム上のどこにどの時点のデータが登
録されているかを管理しておくことが必要になる。

【００２４】本発明ではワークフローの各ステップもし
くは個々の担当者の終了ごとに、サーバのデータベース
のデータを更新する際に、同時にバックアップのための
複製も実行しサーバ中に記録する。一方、クライアント
では該クライアントを利用して処理を実行しているユー
ザの指示、もしくは経過時間等の要因で処理中のデータ
を刻々蓄積する。

【００２５】さて、これらのファイルによって復元され
たデータが他のデータベース、特にワークフローの管理
情報と整合性を保つためには、各管理情報の更新を同期
させることが必要である。

【００２６】そのため、ワークフロー側の情報が更新さ
れる時点、即ちフロー中の個々のユーザが自分の処理を
完了し、次ぎにサーバに登録もしくは担当者に転送する
タイミングでサーバ側のバックアップデータも更新する
ことにより、すくなくともサーバ中のバックアップデー
タとワークフローとの整合性をとることができる。

【００２７】一方、各クライアント中に記録される更新
中のデータは、その存在自体を記録しておくことによ
り、復元時に担当者の定められた処理が完了した後にさ
らにロスの少ない復旧を実現する上で利用することがで
きる。

【００２８】また、このデータは一時的なものであるか
ら、仮にワークフロー管理用のデータベースなど他のデ
ータベースにおいて復旧に十分な条件がそろわない場合
には、上記のサーバ中のバックアップデータを利用し、
本更新中データを無視することにより、各ＤＢでの整合
性を維持できる。

【００２９】

【実施例】以下、本発明の実施例を詳細に説明する。

【００３０】図１は本発明の一実施例の構成を説明する
図である。簡単のため本明細書ではサーバとクライアン
ト各１台ずつの構成を記しているが、実際のＣＳＳ（Ｃ
lient Ｓerver Ｓystem）環境においては複数のサーバ
／クライアントに適用することはいうまでもない。

【００３１】図中１００はサーバ、２００はクライアン
トである。サーバおよびクライアント中の各矩形は機能
のモジュールを表わし、１１０はネットワーク・オペレ
ーションシステムを含めた通信制御部、１２０はあらか
じめ設定した条件に従いデータベースに蓄積されている
画像およびそのほかのデータの転送を制御するワークフ
ロー管理部、１３０は画像データの管理情報および画像
に付随して付加されるコードデータを蓄積しているコー
ド情報データベース、１４０は書類等の画像をデータと
して蓄積・管理する画像データベース、１５０は画像デ
ータの復旧の際にワークフロー管理部１２０から処理の
途中経過を蓄積しているデータが保存されているか否か
の情報を引出し呼び出すべきデータを特定する復旧状況
管理部である。

【００３２】前記復旧状況管理部１５０は、ステ−タス
情報判定部１５１（ステ−タス欄の情報を読みだして前
段まで遡るべきか否かを判断する）、読みだしファイル
判断部１５２（前記ステ−タス情報判定部１５１の判断
にしたがって具体的にどのファイルを読みだすべきかを
判断する）、フロ−状況整合制御部１５３（ファイルの
更新とフロ−を整合させるため、必要に応じて、例えば
前段まで遡る場合にワ−クフロ−管理情報へ更新を指示
する）、ロ−カルファイルアクセス検証部１５４（復旧
時に読みだすファイルがロ−カルファイルに保持されて
いる場合、当該ファイルへのアクセスが可能か否かを検
証し判断する）及びファイル転送管理部１５５（ロ−カ
ルもしくはサ−バ上の該当する転送元ファイルに対して
転送先を指示する）から構成されている。

【００３３】また、１２５，１３５，１４５はそれぞれ
該当するデータベースによってデータの蓄積されている
データの蓄積部を示すが、この３箇所は論理的に分割さ
れているだけで、物理的には同一のデータストレージで
あっても何等支障はない。

【００３４】１２５は、ワークフローに従い、各データ
の位置、転送すべきユーザ名等フロー管理情報の他、各
データが現在どのようなステータスにあるか等復旧時の
判断に必要な情報を記録した文書フロー管理テーブルが
記録されているフロー情報管理部である。また、１３５
は検索情報およびコードデータを記録するコード情報蓄
積部であり、１４５はフローによってシステムを流れる
中心である画像データ自体が記録されている画像データ
蓄積部である。

【００３５】一方、クライアントにおいては、２１０は
上記サーバの１１０と同様にオペレーション・システム
を含めたネットワーク制御部、２２０はワークフローに
従い該当する画像データを要求し表示するワークフロー
クライアントのアプリケーション・モジュール、２３０
は表示された画像データに対して各種のＯＡ的処理を実
行する文書処理アプリケーション・モジュールである。
更に、前記文書処理アプリケーション・モジュール２３
０には、サ−バより転送されたデ−タを一時的に保存す
るロ−カルファイル２３５が接続されている。前記ロ−
カルファイル２３５は、蓄積時に複製も作成保持すると
共に、クライアント上で部分的な更新が実行されている
過程においては、このロ−カルファイルの片側に対して
更新を常に反映させるものである。

【００３６】いま、本システムの利用方法として書類を
イメージデータとして入力して画像データベース１４０
に蓄積し、その画像データをワークフローを用いて回覧
しながら各ユーザが画像に対してコメントなどコード情
報を付加していくことにより、業務を遂行していく場合
を例にして説明する。

【００３７】スキャナなどより入力された画像データは
画像データベース１４０の管理のもと画像データ蓄積部
１４５に記録される。この時該データの管理情報はコー
ド情報データベース１３０の管理下でコード情報蓄積部
１３５に記録される。

【００３８】ここでフローの途中でシステムに障害が発
生し、画像中のデータが失われた場合について説明す
る。

【００３９】まず、フロー中でありながら、障害発生時
点ではどの当該データもクライアントに呼び出されてお
らず、サーバ中の一時蓄積ファイルにも前段の終了時点
のデータが記録されている場合について述べる。

【００４０】次ぎのデータアクセスに応じて、コード情
報データベース中の該データの管理情報を検索する。こ
の時要求されたデータが失われていることが判明すれ
ば、さらにワークフロー管理部１２０より、当該データ
の文書フロー管理テーブルを検索する。その結果、該デ
ータにはサーバ中に前段終了時点でのデータがサーバ中
にバックアップされていることが判明する。そこで該バ
ックアップデータを読みだすことによりフロー処理を支
障なく継続することができる。なおこの場合、フロー中
の位置付け等はオリジナルのデータと同じステータスで
あるので、変更／修正等をする必要はない。

【００４１】次ぎにあるクライアントで既に処理を行っ
ている最中に障害が発生した場合、サーバもしくはクラ
イアント中に一時蓄積されている処理の最中にあるデー
タと、サーバ中に複製により記録されている前段の出力
結果にあたるデータが同時に存在する。この場合には更
新の途中経過のデータが存在することを管理情報データ
ベースより引出し、その結果を用いてサーバもしくはク
ライアント中のデータを読みだすことにより処理を継続
し、処理完了後サーバのデータベースに処理結果をあら
ためて蓄積することにより、障害発生によるデータのロ
スを最小限にとどめることができる。

【００４２】この際、フロー管理情報により当該クライ
アントでのデータは既に更新されていることが確認され
た場合には、クライアントもしくはサーバの一時蓄積デ
ータを用いることになり、処理が開始されていない場
合、つまり前段の完了時点という形でステータスが保存
されている場合にはサーバ中のバックアップデータを読
みだすことになる。

【００４３】これらの動作を実現するために、ワークフ
ローの管理で用いるデータベースには従来の各項目に加
えて各文書の現在位置、つまりはフロ−のどこまで来て
いるかという情報と、そこでのステータス、つまり「完
了」しているか「未処理」かあるいは「処理中」つまり
更新がはじまっているかを記録する手段と、更新途中の
データがクライアント上に記録されているか等の情報も
記録する領域が与えられている。

【００４４】これらの情報の一記載例を図２に示す。こ
こに示したデータはワークフロー管理部に記載されてい
る各項目から、本発明によるデータ復旧に関連する部分
のみを抜粋したものであり、通常のワークフローシステ
ムで管理情報が必要とする公知の項目には含まれていな
いものもある。既にフローに投入されているすべての文
書が図２の管理表に記載されることになり、フローを完
了すると管理表から削除される。

【００４５】図中３１０は現在フロー中を流れている文
書の名称を記載する欄であり、担当者欄３２０は現在ど
のユーザに当該文書が割り当てられているかを示す。こ
こでフローを終えた文書は後述のように、一定の時間間
隔もしくはその他の条件により削除されるが、それまで
の間本欄は「担当者なし」を示す符号を記載しておく。
この図では「Ｆｉｎ」として記載されている。また前段
担当者欄３３０は当該ユーザの前にその文書に処理を施
したユーザ名であり、次ぎの担当者が該文書にアクセス
するまでは、この前段担当者の処理結果が当該データの
最終形態となる。また、該文書フローに投入された直後
の場合、本欄と空白となる。

【００４６】ステータス欄３４０には各担当者における
該文書の処理状況を記載する。本実施例では簡単のた
め、該時点でアクセスされていないことを示す記号
「Ｎ」と、処理中を示す「Ｐ」と、前述したようにフロ
ーの全ての段階を完了し削除を待っている状態を示す
「Ｆ」の３種類の記号を用いるが、実際のシステムにお
いては、処理の課程をより詳細に記述するためにさらに
多くの識別コードを利用することもできる。

【００４７】データの復旧においては、復旧状況管理部
１５０のステ−タス情報判定部１５１がステ−タス欄３
４０の情報を読みだし、前段まで遡るべきか否かを判定
して適切なバックアップデータを選択することになる。

【００４８】またアトリビュート記入欄３５０には該文
書の最も近い状況を記録したファイルのパス名が記録さ
れる。したがって、担当者が未アクセスの文書データの
場合、この欄には前段担当者の処理完了時点でのデータ
のパス名つまり出力結果のファイル名が記録されること
になる。また、各ユーザにおけるデータ更新の最中にデ
ータをサーバ側に一時登録した場合、本欄の内容は更新
され、一時登録されたデータのパス名が記録されること
になる。

【００４９】前段アトリビュート記入欄３５５には、前
段担当者における終了状態を記録したデータを複写した
ファイルのパス名が記録される。この欄は次ぎの担当者
が処理を完了し、処理結果を出力してそのデータを複写
し終えるまでは変更されることはない。

【００５０】したがって、前段アトリビュート記入欄３
５５のデータが保持されていれば、最低限一つ前の段階
の処理結果をユーザは得ることができるため、どのよう
な障害でもその時点でデータにアクセスしていた本人以
外は復旧のためにデータを見直す必要はなく、過去に遡
って書類の再処理を行うことは生じない。

【００５１】次に、本方式によるデータの管理を実行す
る際のデータのバックアップの手順を、図３を用いて説
明する。図３はある担当者がワークフローにしたがって
送られてきた文書に処理を施し、その結果をサーバに送
りかえした場合のデータベース側の更新手順を示すフロ
ーである。４１０において担当者が処理を終了し、４１
５においてデータサーバに保存することを宣言する。

【００５２】データは４２０においてネットワークを開
始、クライアントからサーバへ送られ、４２５において
まず画像データベース１４０管理下の画像データ蓄積部
１４５に記録される。次ぎにコード情報データベース１
３０によりコード情報蓄積部１３５に記録されている当
該データの検索情報を更新する（４３０）。この結果、
今記録した画像データを今後データベースの一要素とし
て検索・要求することができる。その後に該データを別
の名称でストレージ上の別の場所に複製記録する（４３
５）。

【００５３】更新後のデータの記録に伴い、次ぎの段階
としてワークフローの管理情報の更新を行う（４４
０）。まずは通常のワークフローとしての管理情報を更
新した後、前段担当者の処理結果として当該データを登
録し、ステータス情報、前段担当者名４４５も更新す
る。さらにアトリビュート情報と前段アトリビュート情
報を４５０，４５５にて更新する。ここで前段アトリビ
ュート情報には前述の複写データのパス名を記録する。
ここでアトリビュート情報を記載したことにより、以後
ワークフローから呼び出された際に、該当するファイル
として本データがあてはまるだけでなく、前段の処理結
果を必要とした場合に、同複写データを呼び出すことが
できことになる。

【００５４】これらの処理を完了した上で、担当者名を
更新する（４６０）。さらに最終段階で、これまで前段
出力結果として一時的に記録していた前の前段出力結果
のデータもしくはその複写データを削除する（４６
５）。この結果、本システムでは恒に現在行われている
更新処理の前の段階の処理結果のみが２重データの形で
記録されていることになる。

【００５５】次ぎにクライアントにおける文書処理の過
程において更新途中のデータをローカルに記録しておく
場合の手順を図４を用いて説明する。この時、クライア
ントのメモリ上にある処理中のデータが通常の方法でロ
ーカルファイル２３５に５１０において記録される。こ
こで、クライアントからネットワークを介して、サーバ
にアクセスしサーバ中の画像データとして該ファイルが
登録され（５２０）、さらにワークフロー管理情報では
最新のデータとして該データを登録する（５３０）。そ
の上でワークフロー管理テーブル中のアトリビュート情
報に該ローカルファイルのパス名を５４０において登録
する。

【００５６】この結果、前段処理結果としてはサーバ中
に記録されている該データの複製ファイルが指定された
まま、処理中の最新データのバックアップ情報としてク
ライアントのローカルファイルが登録されることにな
る。またこれに続いて同じくワークフロー管理テーブル
中にある担当者欄や、ステータス欄も５５０にて更新す
る。この結果、この時点でワークフロー管理テーブル上
で新しい担当者が該データにアクセスし、内容の更新が
行われたことが認知されることになる。

【００５７】なお、最新ファイルがローカルファイル２
３５に存在することを明確にするため、ワークフロー管
理テーブル上に識別子を記録する方法も可能である。

【００５８】ここまでに説明した手順を実行することに
よってサーバ中にデータは２重化されて記録される上、
クライアント２００上に記録されたローカルファイル２
３５もワークフロー管理対象として扱えることになる。

【００５９】なお、クライアント２００のローカルファ
イル２３５にデータを登録した時点で、同時にサーバ中
に該データの複製を登録し、アトリビュートデータ自体
を２重に持つことも可能である。この場合管理の方法は
各種存在するが、一例としてはワークフロー管理テーブ
ル中のアトリビュート情報の登録欄を２重化し、更新中
データのバックアップファイルとしておくことによって
実現できる。

【００６０】次に、システムに障害が発生した場合のデ
ータ復旧の手順につき図５を用いて説明する。

【００６１】システムに障害が発生し（６１０）、ワー
クフローが指示したデータが正常に得られない場合、図
１の１５０に示したシステムの復旧状況管理のモジュー
ルが作動６１５し、図２のワークフロー管理テーブル３
００にアクセスし、ステータス情報３４０を獲得する
（６２０）。ここで、ステ−タス情報判定部１５１によ
りステータス情報の内容が未アクセスを示す「Ｎ」であ
れば、復旧に用いるデータは前段の出力結果となるた
め、前段アトリビュート情報３５５からデータを獲得す
る（６２５）。

【００６２】更新中を示す「Ｐ」であればアトリビュー
ト情報３５０からパス名を獲得する（６３０）。また、
同時に該データを転送する先にあたる担当者のユーザ名
も獲得する。ここではまず「Ｐ」の場合について説明す
る。この場合、データはローカルファイル２３５から呼
び出すことが必要なため、まずはじめに該当するローカ
ルファイルがアクセス可能な状態にあるか否かをネット
ワークを用いて検証する（６４０）。通常、ネットワー
ク・オペレーションシステムは接続されたクライアント
の状況をモニタする機能を有しているので、これらの既
知の方法により検証を行う。

【００６３】次ぎに、ロ−カルファイルアクセス検証部
１５４により、該当するファイルが接続されアクセス可
能な状態にあるか否かを判断し（６５０）、アクセス可
能であることが判明すれば、アトリビュートのパス名に
従い、読みだしファイル判断部１５２により、ローカル
ファイルから該当するデータを読みだし（６５５）、該
当する転送元ファイルに対して転送先を指示するファイ
ル転送管理部１５５によって、復旧を要するユーザへ再
送信する（６６０）ことにより、データの紛失による損
失を最小に抑制することができる。

【００６４】一方、当該ファイルが接続されていない又
はファイル化していない場合（６７０）、前段アトリビ
ュートのパス名に従い、サーバ中に記録されていた前段
処理の出力結果データの複製データを読みだし（６７
５）、復旧を要するユーザへ再送信する（６８０）。こ
の場合、ワークフローにおけるステータスが変わってし
まうため、フロ−状況整合制御部１５３がワ−クフロ−
管理情報へ更新を指示し、６８５においてワークフロー
管理テーブルを状況にあわせて修正する（６９０）必要
がある。

【００６５】このような手順によりフロー中でなおかつ
ユーザが更新している過程にあるデータをバックアップ
しておき、なおかつ物理的にはローカルファイルであり
ながらワークフローの管理の元、再度フローを継続する
ことができる。

【００６６】次ぎに図６を用いて前段担当者の出力時点
に遡ってデータを復旧する場合について説明する。この
ような過程をたどるのは新規の担当者がアクセスを未だ
にしていない場合に該当する。また、ワークフロー管理
情報の内部に矛盾が生じた場合も、データの整合性を確
保するために該データを用いる。

【００６７】この場合、管理情報テーブルのステータス
情報が「Ｎ」であることを検知すると、未だにアクセス
されていないと判断し、前段アトリビュート情報を獲得
し（７１０）、該アトリビュートのパス名に従い、ロー
カルファイルから該当するデータを読みだし（７２
０）、復旧を要するユーザへ再送信する（７３０）。こ
の場合、新担当者は該データに対して未アクセスである
ため、ワークフロー管理情報としてなにも変更する必要
はない。

【００６８】また、このような形で複製データを用いて
復旧を行った場合は、該データに対してユーザが変更を
加える前に、再度該データを複写し（７４０）、２重に
管理しておく必要がある。データの複写とそれにより変
更されたワークフロー管理テーブル記載情報の更新７５
０を完了した後にクライアントに対してデータの修正を
許可する（７６０）。

【００６９】さて前述のとおり、復旧の際には該当する
データの状況やネットワークを介したファイルのアクセ
ス状況から、転送すべきファイルを判断するため復旧状
況管理モジュールが存在する。復旧状況管理モジュール
はワークフロー管理テーブルの内容のうち主に図２に記
載した項目と、その時点でのネットワーク状況、つまり
アクセス可能なファイルの状況を判断し、転送すべきフ
ァイルを定める。

【００７０】図７にこの復旧状況管理モジュールの各条
件における動作の一例を示す。この図の場合、ローカル
ファイルにアクセスが行われるのは、最新ユーザが既に
該ファイルに対する更新を実行しており、さらに更新中
のデータを一時保存してある場合に限られ、実際のデー
タ読み込みの時点で当該ローカルファイルに対してアク
セスが可能な状態である場合に限られる。

【００７１】なお、以上述べたような、復旧状況管理モ
ジュ−ル１５０による自動的な復旧判断に拠らずに、こ
の復旧判断をユーザ自身が行うことも可能である。その
場合、該データに関連するファイル、あるいは該データ
の過去のある時点でバックアップしたファイルをユーザ
に示し、ユーザが復旧で読みだすファイルを指定するこ
とによっても実現できる。

【００７２】更に、図３におけるデ−タのバックアップ
手順において、サ−バより送られたデ−タをユ−ザが更
新した場合に更新の結果をサ−バ１００の画像デ−タ蓄
積部１４５に記録する際に、２箇所に別のファイル名で
記録し、２個所のファイルの内一方は当該ファイルの更
新が生じても更新せずに残しておき、ユ−ザの処理が完
了した場合に残しておいたファイルを削除するものであ
る。

【００７３】以上のような構成要素を持ち、手順に従う
ことにより本発明は前述の各課題を解決することができ
る。

【００７４】

【発明の効果】以上説明したごとく、本発明によればワ
ークフローシステムにおいて、フローの過程にあるイメ
ージデータを保護できる。そのため、ユーザがデータを
更新している最中に中断もしくはシステム障害が生じた
場合にも、その時点でのデータを復旧することができ
る。また、フローからはずすことなくバックアップでき
るため、引き続きフローに従った回覧が継続できる。

【図面の簡単な説明】

【図１】システム全体の一構成例を説明するための図で
ある。

【図２】文書フロー管理テーブルにおいて本発明特有の
記載項目の説明をするための図である。

【図３】フローの各段階終了時点でのサーバにおけるデ
ータのバックアップ手順を説明する図である。

【図４】クライアントにおける処理中のデータに対する
データバックアップの手順を説明する図である。

【図５】障害発生時にデータを復旧する手順を説明する
図である。

【図６】障害発生時にデータをフローの前段者の処理終
了時点の状態で復旧する手順を説明する図である。

【図７】復旧状況管理部の動作例を説明するための図で
ある。

【符号の説明】

１００ サーバ １１０ 通信制御部 １２０ ワークフロー管理部 １２５ フロー状況蓄積部 １３０ コード情報データベース １３５ コード情報蓄積部 １４０ 画像データベース １４５ 画像データ蓄積部 １５０ 復旧状況管理モジュール ２００ クライアント ２１０ 通信制御部 ２２０ ワークフロークライアントアプリケーションモ
ジュール ２３０ 文書処理アプリケーションモジュール ３００ ワークフロー管理テーブル ３１０ 文書名欄 ３２０ 担当者欄 ３３０ 前段担当者欄 ３４０ ステータス欄 ３５０ アトリビュート欄 ３５５ 前段アトリビュート欄 ４１０ 文書処理の終了 ４１５ 更新結果の保存指示 ４２０ サーバへのデータ転送 ４２５ 画像データベース更新 ４３０ 検索情報更新 ４３５ 更新結果の複製 ４４０ ワークフロー情報の更新 ４４５ 前段担当者欄登録 ４５０ アトリビュート情報更新 ４５５ 前段アトリビュート情報更新 ４６０ 担当者欄更新 ４６５ 旧データの削除 ５１０ ローカルファイルへの保存指示 ５２０ 画像データベースへの登録 ５３０ ワークフロー管理情報更新 ５４０ アトリビュート情報登録 ５５０ ワークフロー管理テーブル更新 ６１０ 障害発生 ６１５ 復旧状況管理モジュール作動 ６２０ ステータス情報取得 ６２５ ステータス情報内容による分岐 ６３０ 前段アトリビュート情報の取得 ６３５ アトリビュート情報の取得 ６４０ ローカルファイル接続確認 ６５０ ファイルアクセスの可否による分岐 ６５５ ローカルファイルのリモート読みだし ６６０ ユーザへの再送信 ６７０ 前段アトリビュート情報の取得 ６７５ サーバ内の前段出力結果のデータ読みだし ６８０ ユーザへの再送信 ６８５ ワークフロー管理テーブルの修正 ７１０ 前段アトリビュート情報の取得 ７２０ サーバ内の前段出力結果の読みだし ７３０ ユーザへの再送信

───────────────────────────────────────────────────── フロントページの続き (72)発明者 里 栄一 神奈川県小田原市国府津2880番地 株式会 社日立製作所ストレ−ジシステム事業部内 (72)発明者 西山 淳 神奈川県小田原市国府津2880番地 株式会 社日立製作所ストレ−ジシステム事業部内

Claims (3)

【特許請求の範囲】
1. 【請求項１】 サ−バに大量の画像データを蓄積し、ク
   ライアントからの要求に応じてＬＡＮ（Local Area Net
   work）を介して画像データを転送し、サ−バから転送さ
   れた画像デ−タを複数のクライアントにおいて順に更新
   するワ−クフロ−システムのイメ−ジデ−タ管理装置に
   おいて、 クライアントには更新中のデータを一時的に蓄積する手
   段を設け、 サ−バには、画像デ−タベ−スと、画像デ−タ蓄積部
   と、ワ−クフロ−の管理情報を保持して画像デ−タ及び
   他のデ−タの転送を制御するワ−クフロ−管理部と、前
   記管理装置に障害が発生し画像デ−タの復旧が要求され
   る場合に更新処理の途中で前記一時的蓄積手段または画
   像デ−タ蓄積部に画像デ−タが保存されているか否かの
   管理情報をワ−クフロ−管理部から引き出して呼び出す
   べき画像デ−タを特定するための復旧状況管理モジュ−
   ルと、を少なくとも設けて、 サ−バから転送されてきた画像デ−タをクライアントに
   おいて更新処理が終了した際にサ−バの画像デ−タ蓄積
   部の２個所に更新結果を記録し、画像デ−タの処理状況
   を表すステ−タス情報と記録された画像デ−タのファイ
   ルパス名を表すアトリビュ−ト情報とを含むワ−クフロ
   −の管理情報を更新すると共に、 更新途中の画像デ−タの記録については、クライアント
   の一時的蓄積手段に記録され且つ前記アトリビュ−ト情
   報に前記一時的蓄積手段のファイルのパス名を登録して
   処理中の最新画像デ−タにアクセスすることができるこ
   とを特徴とするイメ−ジデ−タ管理装置。
2. 【請求項２】 サ−バに大量の画像データを蓄積し、ク
   ライアントからの要求に応じてＬＡＮ（Local Area Net
   work）を介して画像データを転送し、サ−バから転送さ
   れた画像デ−タを複数のクライアントにおいて順に更新
   するワ−クフロ−システムのイメ−ジデ−タ管理装置に
   おいて、 クライアントには更新中のデータを一時的に蓄積する手
   段を設け、 サ−バには、画像デ−タベ−スと、画像デ−タ蓄積部
   と、ワ−クフロ−の管理情報を保持して画像デ−タ及び
   他のデ−タの転送を制御するワ−クフロ−管理部と、前
   記管理装置に障害が発生し画像デ−タの復旧が要求され
   る場合に更新処理の途中で前記一時的蓄積手段または画
   像デ−タ蓄積部に画像デ−タが保存されているか否かの
   管理情報をワ−クフロ−管理部から引き出して呼び出す
   べき画像デ−タを特定するための復旧状況管理モジュ−
   ルと、を少なくとも設けて、 前記復旧状況管理モジュ−ルは、前記障害の発生時点
   で、サ−バに記録されている前段クライアントの終了時
   点での複製デ−タファイルか、現クライアントに記録さ
   れている更新中デ−タの一時保存デ−タファイルのいず
   れか一方のファイルからデ−タを読みだすべきかを前記
   管理情報に基づいて判断する機能を有していることを特
   徴とするイメ−ジデ−タ管理装置。
3. 【請求項３】 請求項２において、 前記復旧状況管理モジュ−ルには、ステ−タス情報判定
   部と読みだしファイル判断部とロ−カルファイルアクセ
   ス検証部とを少なくとも有し、 前記ステ−タス情報判定部が、画像デ−タの処理状況を
   表すステ−タス情報を取得して前段クライアントの複製
   デ−タファイルに遡るのか否かを判定し、 前記読みだしファイル判断部が、前記判定に従い画像デ
   −タのファイルパス名を表すアトリビュ−ト情報から読
   みだすべき具体的なファイル名を判断し、 前記ロ−カルファイルアクセス検証部が、読みだすべき
   ファイルが前記一時的蓄積手段に保持されている場合前
   記ファイルへのアクセスが可能であるか否かを検証し判
   断することを特徴とするイメ−ジデ−タ管理装置。