〔第1実施形態〕
以下、図面を参照して、本発明の詳細を説明する。
図1は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。
実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末(ワークフロー及び伝票設計用端末)400、業務を遂行する処理者(担当者)に対応して設けられたワークフロー操作用コンピュータ端末(ワークフロー操作用端末)300、ワークフローを実行するための各種テーブル、各種プログラムを格納するワークフローサーバ200を備えている。
これらワークフロー及び伝票設計用端末400,ワークフロー操作用端末300,ワークフローサーバ200は、それぞれネットワーク500に接続され運用されている。
ワークフロー及び伝票設計用端末400は、伝票デザイナプログラム401及びシステム管理プログラム402を有し、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末400は、ワークフローサーバ200に組織テーブル,役割テーブル,ユーザテーブル,ユーザ役割テーブル,配送定義情報,各種伝票情報等を登録することができる。このワークフロー及び伝票設計用端末400は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ200に接続することが可能になる。
ワークフロー操作用端末300は、ワークフロー操作用端末300上で実行されるWebブラウザ301を用いて、伝票に関するアクセス情報をワークフローサーバ200に対してHTTPで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Java(登録商標)アプレット302等を利用することにより実行する。なお、このワークフロー操作用端末300は、予め指定された所定の業務を行う担当者(例えば、起票者、課長、部長等)に配置されている。
ワークフローサーバ200は、ワークフローシステムに関する情報(組織テーブル,役割テーブル,ユーザテーブル,ユーザ役割テーブル,配送定義情報,配送情報テーブル,閲覧権テーブル(起票者閲覧権テーブル,承認者閲覧権テーブル),各種伝票情報を格納するRDBMS(Relational DataBaSe Management SyStem)205、ワークフロー操作用端末300よりの要求を受け付けて要求を実行するためのHTTPサーバ201,サーブレットエンジン202,ワークフロープログラム203、ワークフロー通知機能を実現するSMTPサーバ204にて構成されている。
以下、図2を参照して、図1に示したワークフローサーバ200,ワークフロー操作用端末300,ワークフロー及び伝票設計用端末400に適用可能なコンピュータのハードウェア構成について説明する。
図2は、図1に示したワークフローサーバ200,ワークフロー操作用端末300,ワークフロー及び伝票設計用端末400に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
図2において、101はCPUで、ROM103又はハードディスク(HD)(その他の記憶装置、例えば、フレキシブルディスク,CD−ROM,DVD−ROM等どのような記憶装置であってもよい)104に格納されたプログラムをRAM102上にロードして実行することにより、コンピュータ全体を制御する。RAM102は、CPU101の作業領域として使用される。
108は通信インタフェースで、通信ネットワーク500への接続を可能とする。106は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。107は表示装置で、CRT,LCD等で構成される。
なお、図1に示したワークフローサーバ200のRDBMS205は、ワークフローサーバ200のHD104内に構築されている。また、ワークフローサーバ200のHTTPサーバ201,サーブレットエンジン202,ワークフロープログラム203,SMTPサーバ204は、ワークフローサーバ200のCPU101が、HD104に格納されるプログラムをRAM102上にロードして実行することにより、実現される。
また、図1に示したワークフロー操作用端末300のWebブラウザ301は、ワークフロー操作用端末300のCPU101が、HD104に格納されるプログラムをRAM102上にロードして実行することにより、実現される。
さらに、図1に示したワークフロー操作用端末300のJava(登録商標)アプレット302は、ワークフロー操作用端末300のCPU101が、ワークフローサーバ200よりダウンロードされたプログラムをWebブラウザ301上で実行することにより、実現される。
また、図1に示したワークフロー及び伝票設計用端末400の伝票デザイナプログラム401,システム管理プログラム402は、ワークフロー及び伝票設計用端末400のCPU101が、HD104に格納されるプログラムをRAM102上にロードして実行することにより、実現される。
図3は、図1に示したワークフローシステムにおける伝票の流れを示す模式図である。
本実施形態のワークフローシステムでは、ワークフロー操作用端末300を用いて、図3に示すように、伝票の起票,伝票の承認/否認の手続きを、ノードと呼ばれる組織と役割で定義された担当者が行う。なお、伝票が配送されるノードをひとつに括ったものをビジネスプロセスと定義する。
図4は、図1に示したワークフローサーバ200のRDBMS205に記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。なお、この組織テーブルは、ワークフローを実現するための組織に関する情報記憶するためのものである。
図4に示す組織テーブルにおいて、組織IDは、任意の組織名をコードとして表記したものであり、常に上位組織IDを網羅している。また、組織名は、組織IDの表示上の名称を示したものである。さらに、親組織IDは、上位の組織IDを示したものである。
図5は、図1に示したワークフローサーバ200のRDBMS205に記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。なお、この役割テーブルは、ワークフローを実現するための役割に関する情報を記憶するためのものである。
図5に示す役割テーブルにおいて、役割IDは、任意の役割名をコードとして表記したものである。また、役割名は、役割IDの表示上の名称を示したものである。
図6は、図1に示したワークフローサーバ200のRDBMS205に記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。なお、このユーザテーブルは、ワークフローを利用するためのユーザの情報を記憶するためのものである。
図6に示すユーザテーブルにおいて、ユーザIDは、利用者を任意のコードとして表示したものである。また、パスワードは、ワークフローシステムにログインする際にユーザIDと共に認証に利用するためのものである。さらに、ユーザ名は、ユーザIDの表示上の名称を示したものである。
図7は、図1に示したワークフローサーバ200のRDBMS205に記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。なお、この役職テーブルは、ワークフローを利用するための役職の情報を記憶するためのものである。
図7に示すように、役職テーブルの各レコードは、ユーザテーブル内で定義されている「ユーザID」,役割テーブル内で定義されている「役割ID」,組織テーブル内で定義されている「組織ID」で構成されている。
図8は、図1に示したワークフローサーバ200のRDBMS205に記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。なお、この配送定義情報は、伝票が配送される経路を定義した情報を記憶するためのものである。
ここでは、一例として役割が「社員」→「部長」→「本部長」→3f「事業本部長」→「社長」の順に伝票配送をする例を示している。このように伝票の配送経路を定義した場合、この配送経路の配送定義情報は、図9に示すような5レコードの情報として作成される。
以下、配送定義情報の作成方法について説明する。
例えば、伝票名が「交通費」の場合、まず、ユーザがワークフロー及び伝票設計用端末400から、システム管理プログラムを用いて、伝票名に「交通費」と設定し、次に、各ノードを設定する。ノード1を例にすると、ノード1に役割IDに部長を示すコード「U0007」を設定し、対象となる組織を選択(ここでは組織ID「80」の「A会社」を選択)することにより、「伝票名」が「交通費」,「組織ID」が「80」,「ノード番号」が「1」,「経路役割ID」が「部長」を示す役割ID「004」、「経路組織ID」が役割を担う組織IDとして設定される。なお、ここでは、対象となる組織として、組織ID「80」の「A会社」が選択されており、役割ID「部長」を持つ配送対象者は決定されない。そのため、経路組織IDは「NULL」となっている(図中では空白で示している)。
図9は、図1に示したワークフローサーバ200のRDBMS205に記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。なお、この配送情報テーブルは、後述する図10に示すワークフローシステムにおける配送処理時に図8に示した配送定義情報に基づいて生成されるものであり、ワークフローの経路,状態等を記憶するためのものである。また、この配送情報テーブルは、特に、ユーザID「U0012」のユーザが起票した場合に対応する。この場合、伝票は、ユーザID「U0012」,「U0007」,「U0003」,「U0002」,「U0001」のように配送されることとなる。
以下、図10を参照して、本発明のワークフローシステムにおける配送処理手順の全体の流れについて説明する。
図10は、本発明のワークフローシステムにおける第1の制御処理手順の一例を示すフローチャートであり、図1に示したワークフローサーバ200のワークフロープログラム203による配送処理に対応する。なお、図中、S5000〜S5013は各ステップを示す。
まず、ワークフロープログラム203を実行するワークフローサーバ200のCPU(以下、ワークフローサーバ200のCPU)が、ワークフロー操作用端末300より伝票処理要求を受信すると(ステップS5000)、配送処理を開始する。
ワークフローサーバ200のCPUは、ステップS5000で受信した伝票処理要求の要求区分である「起票」,「承認」,「否認」に基づいて、配送処理を切り替えていく(ステップS5001)。
ステップS5001において、ワークフローサーバ200のCPUが、ステップS5000で受信した伝票処理要求の要求区分が「起票」であると判定した場合には、ステップS5002において、ワークフローサーバ200のCPUは、起票時の情報として、ノード番号「0」を配送情報テーブルに設定する。「処理ユーザ」には、起票したユーザのユーザIDを設定する。
例えば、図8に示した配送定義情報に基づく伝票が起票された場合、図9に示したように、配送情報テーブルのノード番号「0」のレコードに、伝票名に「交通費」、伝票番号を起票時に発行される伝票番号(ここでは「00001」とする)、ノード番号に「0」、処理ユーザを起票ユーザのユーザID「U0012」、状態に「処理済」を設定する。
次に、ステップS5003において、ワークフローサーバ200のCPUは、現在のノード番号を「1」とし、ステップS5000で受信した伝票処理要求の伝票名に対応する配送定義情報(図8)を参照し、ノード番号「1」の情報(経路役割ID,経路組織ID)を取得し、ステップS5008に進む。
例えば、図8に示した配送定義情報に基づく伝票が起票された場合、経路役割ID「004」,経路組織ID「NULL」を取得する。
一方、ステップS5001で、ワークフローサーバ200のCPUが、ステップS5000で受信した伝票処理要求の要求区分が「承認」又は「否認」であると判定した場合には、ステップS5004において、ワークフローサーバ200のCPUは、配送情報テーブル(図9)を参照して現在のノード番号を取得する。
次に、ステップS5005において、ワークフローサーバ200のCPUは、ステップS5000で受信した伝票処理要求の要求区分が「承認」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップS5007において、ステップS5004で取得した現在のノード番号をデクリメントした後、該デクリメントした現在のノード番号を持つ配送定義情報(図8)を参照し、該現在のノード番号の情報(経路役割ID,経路組織ID)を取得し、ステップS5008に進む。
一方、ステップS5005で、ワークフローサーバ200のCPUが、ステップS5000で受信した伝票処理要求の要求区分が「承認」であると判定した場合には、ステップS5006において、ステップS5004で取得した現在のノード番号をインクリメントした後、該インクリメントした現在のノード番号を持つ配送定義情報(図8)を参照し、該現在のノード番号の情報(経路役割ID,経路組織ID)を取得し、ステップS5008に進む。
そして、ステップS5009において、ワークフローサーバ200のCPUは、ステップS5003、S5006、又はS5007で取得した経路役割ID,経路組織IDを用いて、ユーザ役職情報(図7)を参照して次の配送対象ユーザIDを決定する(役職テーブル(図7)から役割IDが経路役割IDで、組織IDが経路組織IDのユーザIDを決定する)。なお、取得した組織経路IDが「NULL」の場合(図8の空白の場合)には、現在のノード番号より1つ小さいノード番号に対応するユーザIDの属する組織IDを「経路組織ID」として次の配送対象ユーザIDを決定するものとする。さらに、これでも次の配送対象ユーザIDを決定することができない場合(ユーザ役職情報(図7)に、役割IDが経路役割IDで、組織IDが経路組織IDのレコードが存在しない場合)には、該組織IDの親組織IDを「経路組織ID」として次の配送対象ユーザIDを決定するものとし、次の配送対象ユーザIDが決定するまでこの処理を繰り返すものとする。
例えば、図8に示した配送定義情報に基づく伝票が起票された場合、図9に示したように、ステップS5003で、ノード番号「1」の経路役割ID「004」,経路組織ID「NULL」が取得され、該取得された経路役割ID「004」,経路組織ID「NULL」に基づいて配送対象となるユーザIDが決定される。ここで、取得した経路組織IDが「NULL」であるため、現在のノード番号「1」より1つ小さいノード番号「0」に対応するユーザID「U0012」の属する組織ID「8010101010」を「経路組織ID」として次の配送対象ユーザIDを決定する。このとき、ユーザ役職情報(図7)に、役割ID「004」で、組織ID「8010101010」のレコードが存在しないため、組織ID「8010101010」の親組織ID「80101010」を「経路組織ID」として次の配送対象ユーザIDを決定する。ここで、ユーザ役職情報(図7)を参照すると、役割ID「004」で、組織ID「8010101010」のユーザIDは「U0007」となり、このユーザID「U0007」が次の配送対象ユーザIDに決定される。
次に、ステップS5009において、ワークフローサーバ200のCPUは、ステップS5000で受信した伝票処理要求が最終承認者からのものであるか否かを判定する。
ステップS5009で、ワークフローサーバ200のCPUが、ステップS5000で受信した伝票処理要求が最終承認者からのものであると判定した場合には、ステップS5010において、配送情報テーブル(図9)から当該配送情報を削除するとともに、SMTPサーバ204により起票者に全て承認された旨のワークフロー通知を行い、処理を終了する。
一方、ステップS5009で、ワークフローサーバ200のCPUが、ステップS5000で受信した伝票処理要求が最終承認者からのものでないと判定した場合には、ステップS5011において、ワークフローサーバ200のCPUは、ステップS5000で受信した伝票処理要求の要求区分が「承認」又は「起票」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップS5013において、配送情報テーブル(図9)から上記現在ノード番号を削除するとともに、SMTPサーバ204により配送対象者に否認された旨のワークフロー通知を行い、処理を終了する。
一方、ステップS5011で、ワークフローサーバ200のCPUが、ステップS5000で受信した伝票処理要求の要求区分が「承認」又は「起票」であると判定した場合には、ステップS5012において、配送情報テーブル(図9)に次のノード番号の情報を設定(この時、「処理ユーザ」には、ステップS5009で決定された次の配送対象ユーザIDを設定)するとともに、SMTPサーバ204により配送対象者にワークフロー通知を行い、処理を終了する。
以下、図11〜図23を用いて本実施形態における電子文書の振り直し処理について説明する。
ここで、振り直し処理とは、経路,組織,役割の変更が行われた場合、変更後の経路(旧組織の次承認者を新組織の次承認者に変更した経路)で伝票が配送されるようにする機能である。即ち、旧組織において次承認者として配送されている伝票(処理待ち状態の伝票)を取り戻し、新組織の次承認者に配送し直すことである。
図11は、本発明のワークフローシステムにおける第2の制御処理手順の一例を示すフローチャートであり、図1に示したワークフローサーバ200のワークフロープログラム203による組織変更による配送伝票の振り直し処理に対応する。なお、図中、S901〜S914は各ステップを示す。
まず、システム管理者によりログインされたクライアント装置(ワークフロー操作用端末300)から、組織変更にともなう配送伝票の振り直し処理の開始が指示されると、ワークフローサーバ200のCPUは、本フローチャートの処理を開始し、ステップS901において、ワークフローサーバ200のCPUは、ワークフロー操作用端末300からの起票処理要求の受け付けを停止するとともに、配送情報テーブルを所定のバックアップ領域(例えば、ワークフローサーバ200内のHD)に退避させる。
次に、ステップS902において、ワークフローサーバ200のCPUは、文書配送停止処理を行って、処理待ち伝票を配送停止状態にする。なお、この処理の詳細は図12に示す。
次に、ステップS903において、ワークフローサーバ200のCPUは、処理待ち状態の伝票があるか否かを判定し、まだあると判定した場合には、ステップS902に戻り、再度、文書配送停止処理を実行する。
一方、ステップS903で、ワークフローサーバ200のCPUが、処理待ち状態の伝票がもうない(処理待ち伝票をすべて停止した)と判断した場合には、ステップS904において、ワークフローサーバ200のCPUは、既存のユーザテーブル,役割テーブル,組織テーブルを所定のバックアップ領域(例えば、ワークフローサーバ200内のHD)に退避させる。
次に、ステップS905で、ワークフローサーバ200のCPUは、組織,役割,ユーザ情報の変更作業を受け付け、変更作業の終了が指示されると、ステップS906において、各テーブル(ユーザテーブル,役割テーブル,組織テーブル)を更新する。
次に、ステップS907において、ワークフローサーバ200のCPUは、更新された各テーブルをもとに配送伝票振り直し処理を行う。なお、この処理の詳細は図16に示す。
次に、ステップS908において、ワークフローサーバ200のCPUは、ステップS907の配送伝票振り直し処理でエラーが発生したか否かを判定し、エラーが発生したと判断した場合には、ステップS909において、各テーブル(ステップS904で退避させた既存のユーザテーブル,役割テーブル,組織テーブル、ステップS901で退避させた配送情報テーブル)のロールバック処理を行う。
そして、ステップS910において、ワークフローサーバ200のCPUは、処理待の伝票の処理ユーザに対応するワークフロー操作用端末300の画面に、旧組織での承認行為を速やかに継続する旨のメッセージを表示させる。
最後に、ステップS914において、ワークフローサーバ200のCPUは、ワークフロー操作用端末300からの起票処理要求の受け付けを再開し、処理を終了する。
一方、ステップS908で、ワークフローサーバ200のCPUが、ステップS907の配送伝票振り直し処理が正常終了した(エラー発生なし)と判断した場合には、ステップS911において、ワークフローサーバ200のCPUは、振り直しする伝票があるか否かを判定し、まだあると判定した場合には、ステップS907に戻り、再度、配送伝票振り直し処理を実行する。
一方、ステップS911で、ワークフローサーバ200のCPUが、振り直しする伝票がもうないと判断した場合には、ステップS912において、ワークフローサーバ200のCPUは、停止文書再開処理を行って、配送停止状態の伝票を処理待ち状態にして配送を再開させる。なお、この処理の詳細は図21に示す。
次に、ステップS913において、ワークフローサーバ200のCPUは、停止状態の伝票があるか否かを判定し、まだあると判定した場合には、ステップS912に戻り、再度、停止文書再開処理を実行する。
一方、ステップS913で、ワークフローサーバ200のCPUが、停止状態の伝票がもうない(停止状態の伝票をすべて再開した)と判断した場合には、最後に、ステップS914において、ワークフローサーバ200のCPUは、ワークフロー操作用端末300からの起票処理要求の受け付けを再開し、処理を終了する。
以下、図12〜図15を参照して、図11のステップS902に示した文書配送停止処理について詳細に説明する。
図12は、本発明のワークフローシステムにおける第3の制御処理手順の一例を示すフローチャートであり、図1に示したワークフローサーバ200のワークフロープログラム203による文書配送停止処理(図11のステップS902)に対応する。なお、図中、S701〜S706は各ステップを示す。
まず、ステップS701において、ワークフローサーバ200のCPUは、配送情報テーブル(図13)より、状態が「処理済」以外の伝票を取得する。
図13は、本発明のワークフローシステムにおける配送情報テーブルの一例を示す図である。
次に、ステップS702において、ワークフローサーバ200のCPUは、ステップS701で取得した、状態が「処理済」以外の伝票に基づいて、図14に示すような画面をワークフロー操作用端末300の表示装置(システム管理者のクライアント画面)に表示する。
図14は、本発明のワークフローシステムにおける現在回付中伝票一覧画面の一例を示す図であり、特に、文書配送停止処理中に表示される現在回付中伝票一覧画面に対応する。
図14において、601は「全停止」ボタンで、回付中(「処理待」)の全ての伝票の状態を「停止中」にする場合に指示する。602は「停止」ボタンで、対応する伝票の状態を「停止中」にする場合に指示する。
以下、図12のフローチャートの説明に戻る。
次に、ステップS703において、ワークフローサーバ200のCPUは、ステップS701で取得した、状態が「処理済」以外の伝票の中に、回付中(「処理待」)の伝票(停止にする伝票)があるか否かを判定し、ないと判断した場合には、そのまま本フローチャートの処理を終了する。
一方、ステップS703で、ワークフローサーバ200のCPUが、ステップS701で取得した、状態が「処理済」以外の伝票の中に、回付中の伝票(停止にする伝票)があると判断した場合には、ステップS704に処理を移行させる。
次に、ステップS704において、ワークフローサーバ200のCPUは、「全停止」ボタン601がワークフロー操作用端末300(システム管理者のクライアント装置)の入力装置により指示されたか否かをワークフロー操作用端末300からの通知により判断し、指示されたと判断した場合には、ステップS705において、配送情報テーブル内の回付中の全ての伝票の状態を「停止中」にし、本フローチャートの処理を終了する。
一方、ステップS704で、ワークフローサーバ200のCPUが、「全停止」ボタン601がワークフロー操作用端末300(システム管理者のクライアント装置)の入力装置により指示されず「停止」ボタン602が指示されたと判断した場合には、ワークフローサーバ200のCPUは、ステップS706において、配送情報テーブル内の対応する伝票の状態を「停止中」にし、本フローチャートの処理を終了する。全ての回付中伝票を停止したときの配送情報テーブルの状態を図15に示す。
図15は、本発明のワークフローシステムにおける配送情報テーブルの一例を示す図であり、全ての回付中伝票を停止したときの状態に対応する。
なお、このように配送停止された伝票は、承認処理待ち状態ではあるが、当該承認者がログインしても、ワークフローサーバ200のCPUは、承認処理待ち一覧に表示しないように制御する。
以下、図16〜図21を参照して、図11のステップS907に示した配送伝票振り直し処理について詳細に説明する。
図16は、本発明のワークフローシステムにおける第4の制御処理手順の一例を示すフローチャートであり、図1に示したワークフローサーバ200のワークフロープログラム203による配送伝票振り直し処理(図11のステップS907)に対応する。なお、図中、S801〜S809は各ステップを示す。
まず、ステップS801において、ワークフローサーバ200のCPUは、配送情報テーブル(図15)より、状態が停止中(「停止中」又は「停止中(検査済)」)の伝票を取得する。
次に、ステップS802において、ワークフローサーバ200のCPUは、ステップS801で取得した、状態が停止中の伝票に基づいて、図17に示すような画面をワークフロー操作用端末300(システム管理者のクライアント装置)の表示装置に表示する。
図17は、本発明のワークフローシステムにおける伝票配送経路振り直し画面の一例を示す図である。
図17において、1001は「全検査」ボタンで、停止中の全ての伝票の振り直しを検査する場合に指示する。1002は「検査」ボタンで、対応する伝票の振り直しを検査する場合に指示する。
以下、図16のフローチャートの説明に戻る。
次に、ステップS803において、ワークフローサーバ200のCPUは、ステップS801で取得した、状態が停止中の伝票の中に、検査済みでない伝票(検査する伝票)があるか否かを判定し、ないと判断した場合には、そのまま本フローチャートの処理を「正常」終了する。
一方、ステップS803で、ワークフローサーバ200のCPUが、ステップS801で取得した、状態が停止中の伝票の中に、検査済でない伝票(検査する伝票)があると判断した場合には、ステップS804に処理を移行させる。
次に、ステップS804において、ワークフローサーバ200のCPUは、「全検査」ボタン1001がワークフロー操作用端末300(システム管理者のクライアント装置)の入力装置により指示されたか否かをワークフロー操作用端末300からの通知により判断し、指示されたと判断した場合には、ステップS805において、図11のステップS906で更新された各テーブル(ユーザテーブル,役割テーブル,組織テーブル)と図8に示した配送定義情報等を用いて、配送情報テーブル内の「停止中」の全ての伝票を振り直しを行って振り直しの可否を検査し、ステップS807に処理を移行させる。
一方、ステップS804で、ワークフローサーバ200のCPUが、「全検査」ボタン1001がワークフロー操作用端末300の入力装置により指示されず「検査」ボタン1002が指示されたと判断した場合には、ステップS806において、ワークフローサーバ200のCPUは、図11のステップS906で更新された各テーブル(ユーザテーブル,役割テーブル,組織テーブル)と図8に示した配送定義情報等を用いて、配送情報テーブル内の対応する伝票の振り直しを行って振り直しの可否を検査し、ステップS807に処理を移行させる。
以下、振り直しの検査に関して説明する。
まず、ワークフローサーバ200のCPUは、図10のステップS906で更新された各テーブル(ユーザテーブル,役割テーブル,組織テーブル)と振り直し対象の伝票の配送定義情報に基づいて、当該伝票の配送経路を振り直しする。そして、この振り直しの結果から伝票の振り直しの可否を判定する。
この際、ワークフローサーバ200のCPUは、回付中伝票の振り直しが不可能(エラー)となる場合を以下の3つの検出項目により検出する。
まず、第1の検出項目は、上述した振り直しの際に、回付中電子文書の起案者が所属する組織が存在しなかった場合、この場合、当該組織を組織情報,役割情報の変更時に、誤操作等により削除してしまったものとして、振り直し不可(エラー)とし、この旨をシステム管理者のクライアント画面(ワークフロー操作用端末)に警告表示する。
また、第2の検出項目は、上述した振り直しの際に、回付中電子文書の配送経路の組織に該当するユーザが存在しなかった場合、この場合、当該ユーザを組織情報,役割情報,ユーザ情報の変更時に誤操作等により削除したものとして、振り直し不可(エラー)とし、この旨をシステム管理者のクライアント画面(ワークフロー操作用端末)に警告表示する。
さらに、第3の検出項目は、上述した振り直しの際に、回付中電子文書の配送経路の組織,役割が存在しなかった場合、この場合、当該組織,役割を組織情報,役割情報の変更時に誤操作等により削除したものとして、振り直し不可(エラー)とし、この旨をシステム管理者のクライアント画面(ワークフロー操作用端末)に警告表示する。
また、上記第1〜3の検出項目に該当しない場合は、振り直し可(正常)とし、この旨をシステム管理者のクライアント画面(ワークフロー操作用端末)に通知表示する。
以下、図16のフローチャートの説明に戻る。
ステップS805又はS806で、伝票の振り直しの検査が終了すると、次に、ステップS807において、ワークフローサーバ200のCPUは、ステップS805又はステップS806での振り直し検査結果がエラーであったか否かを判定し、エラーであったと判断した場合には、ステップS808において、ワークフローサーバ200のCPUは、図18に示す検査結果画面をワークフロー操作用端末300の表示装置(システム管理者のクライアント画面)に送信し表示させる。
この警告表示により、組織テーブル,役割テーブル,ユーザテーブルの変更時に、誤操作等があったことを自動的に(人手による検知処理を行うことなく)検知し、システム管理者に警告することができる。
図18は、本発明のワークフローシステムにおける検査結果画面の一例を示す図であり、特に検査結果がエラーであった場合に対応する。
そして、図18に示す「ロールバック」1101がワークフロー操作用端300の入力装置により指示されたことを示す通知をワークフロー操作用端300から受け取ると、ワークフローサーバ200のCPUは、本フローチャートの処理を「エラー」終了する。
一方、ステップS807で、ワークフローサーバ200のCPUが、ステップS805又はステップS806での振り直し検査結果がエラーでなかったと判断した場合には、図19に示す検査結果画面をワークフロー操作用端末300の表示装置(システム管理者のクライアント画面)に表示する。
図19は、本発明のワークフローシステムにおける検査結果画面の一例を示す図であり、特に、検査結果が正常であった場合に対応する。
そして、図19に示す「OK」ボタン1102がワークフロー操作用端300の入力装置により指示されたことを示す通知をワークフロー操作用端300から受け取ると、ワークフローサーバ200のCPUは、ステップS809に処理を進める。
ステップS809において、ワークフローサーバ200のCPUは、検査した伝票の振り直し結果を実際の配送情報テーブルに反映し、該伝票の状態を「停止(検査済)」にし、本フローチャートの処理を「正常」終了する。
図20は、本発明のワークフローシステムにおける配送情報テーブルの一例を示す図であり、全伝票検査後の状態に対応する。
なお、このように配送停止された伝票(「停止中(処理済)の伝票」)は、承認処理待ち状態ではあるが、当該承認者がログインしても、ワークフローサーバ200のCPUは、承認処理待ち一覧に表示しないように制御する。
以下、図21〜図23を参照して、図11のステップS912に示した停止文書再開処理について詳細に説明する。
図21は、本発明のワークフローシステムにおける第5の制御処理手順の一例を示すフローチャートであり、図1に示したワークフローサーバ200のワークフロープログラム203による停止文書再開処理(図11のステップS912)に対応する。なお、図中、S711〜S715は各ステップを示す。
まず、ステップS711において、ワークフローサーバ200のCPUは、配送情報テーブル(図15)より、状態が「処理済」以外の伝票を取得する。
次に、ステップS712において、ワークフローサーバ200のCPUは、ステップS711で取得した、状態が「処理済」以外の伝票に基づいて、図22に示すような画面をワークフロー操作用端末300の表示装置に表示する。
図22は、本発明のワークフローシステムにおける現在回付中伝票一覧画面の一例を示す図であり、特に、停止文書再開処理中に表示される現在回付中伝票一覧画面に対応する。
図22において、801は「全再起動」ボタンで、停止中の全ての伝票の状態を「処理待」にして再開させる場合に指示する。802は「再起動」ボタンで、対応する伝票の状態を「処理待」にして再開させる場合に指示する。
以下、図21のフローチャートの説明に戻る。
次に、ステップS713において、ワークフローサーバ200のCPUは、ステップS711で取得した、状態が「処理済」以外の伝票の中に、状態が「停止中」の伝票(再開する伝票)があるか否かを判定し、ないと判断した場合には、そのまま本フローチャートの処理を終了する。
一方、ステップS713で、ワークフローサーバ200のCPUが、ステップS701で取得した、状態が「処理済」以外の伝票の中に、状態が「停止中」の伝票(再開にする伝票)があると判断した場合には、ステップS714に処理を移行させる。
次に、ステップS714において、ワークフローサーバ200のCPUは、「全再起動」ボタン801がワークフロー操作用端末300の入力装置により指示されたか否かをワークフロー操作用端末300からの通知により判断し、指示されたと判断した場合には、ステップS715において、配送情報テーブル内の「停止中」の全ての伝票の状態を「処理待」にし、本フローチャートの処理を終了する。
一方、ステップS714で、ワークフローサーバ200のCPUが、「全再開」ボタン801がワークフロー操作用端末300の入力装置により指示されず「再開」ボタン802が指示されたと判断した場合には、ステップS716において、ワークフローサーバ200のCPUは、配送情報テーブル内の対応する伝票の状態を「処理待」にし、本フローチャートの処理を終了する。一部の伝票を再開したときの配送情報テーブルの状態を図23に示す。
図23は、本発明のワークフローシステムにおける配送情報テーブルの一例を示す図であり、一部の伝票を再開したときの状態に対応する。
なお、このように配送再開された伝票は、当該承認者がログインすると、ワークフローサーバ200のCPUが、ワークフロー操作用端末300の承認処理待ち一覧に表示して処理を促すように制御する。
以上示したように、本発明は、以下の第1〜4の機能を有する。
まず、本発明の第1の機能は、文書配送停止機能(図12)に対応するものであり、ワークフローの運用環境変更時(組織情報,役割情報,ユーザ情報等の更新時)、承認待ち電子文書を検索し、該検索された当該電子文書の一覧を表示し、組織,役割変更時には、システム管理者の権限により、特定または全ての電子文書配送処理を停止する機能である。なお、配送停止された当該電子文書は、承認処理待ち状態であるが、当該承認者が当該ワークフローシステムにログインしても承認処理待ち一覧には表示されない、すなわち承認行為を行うことができない。
本発明の第2の機能は、配送伝票振り直し処理(図16)に対応するものであり、ワークフローシステムの組織情報,役割情報,ユーザ情報等を、組織変更にともない更新したタイミングで、変更される組織情報,役割情報,ユーザ情報の論理的な誤りを自動検出する機能である。まず第1の検出項目は、回付中電子文書の起案者が所属する組織が存在しない場合、当該組織を組織情報,役割情報等の変更時に誤操作により削除したものとして、これをシステム管理者のクライアント画面に警告表示を行うものである。また、第2の検出項目は、回付中電子文書の配送経路の組織に当該者が存在しない場合、当該者を組織・役割情報変更時に誤操作により削除したものとして、これをシステム管理者のクライアント画面に警告表示を行うものである。さらに、第3の検出項目は、当該電子文書の承認直前の当該者の組織,役割が存在しない場合、当該組織を組織情報,役割情報等の変更時に誤操作により削除したものとして、これをシステム管理者のクライアント画面に警告表示を行うものである。
また、これにより、ワークフローの運用環境変更後(組織情報,役割情報,ユーザ情報等の更新後)に、行き場のない伝票が発生してしまうことを防止することができる。
本発明の第3の機能は、図11のステップS907のロールバック処理に対応するものであり、組織情報,役割情報の更新ミスを発見した場合、更新前の組織情報,役割情報にロールバックさせる機能である。この機能により、あたかも組織情報,役割情報をオフラインと同じ環境にて、当該情報を確認させることができる。
本発明の第4の機能は、図21に示した停止文書配送再開処理に対応するものであり、第1の機能により停止していた電子文書配送処理を一部またはすべての電子文書に対して再開させる機能である。このとき、当該承認処理待ちの電子文書は、更新された組織情報,役割情報に基づいた配送経路情報に書き換えられている。
以上に示したように、組織情報,役割情報の更新後、承認処理待ち伝票を対象として配送経路の再設定や、組織情報,役割情報の誤設定の検出を自動化する(人手を介することなく行う)ことで、システム管理者の負荷を軽減することができる。
なお、上記実施形態では、振り直し検査結果が1つでもエラーとなった場合には、図11のステップS909に移行し、各テーブルのロールバック処理を行う構成について説明したが、振り直し検査結果がエラーとなった伝票があった場合でも、当該エラーとなった伝票のみを「保留」伝票として扱い、エラーのなかった他の伝票のワークフローのみを再開可能に構成してもよい。以下、その実施形態について説明する。
図24は、本発明のワークフローシステムにおける検査結果画面の一例を示す図であり、振り直しエラーとなった伝票を保留可能な場合に対応する。なお、図18と同一のものには同一の符号を付してある。
図24において、1103は「保留」ボタンで、このボタンを、ワークフロー操作用端300の入力装置により指示することにより、この通知を受けたワークフローサーバ200のCPUは、配送情報テーブル内において、エラーとなった伝票1104の状態を「保留」に変更して、配送伝票振り直し処理を「正常」終了する。
例えば、ある組織,役割(ポスト)が空席となっているような場合、伝票の次承認者の組織,役割に対応するユーザが存在しないものとして、エラーとなってしまう。このような場合でも、そのポストに関連した伝票のみを「保留」とすることで、組織テーブル,役割テーブル等を更新することができ、人事異動等のワークフローの運用環境の変化にともない、フレキシブルに配送伝票振り直し処理を行うことが可能となる。
なお、「保留」となった伝票は、該ポストが埋まり次第、該「保留」となっている伝票の状態を「処理待ち」に変更することにより、再開することが可能となる。
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
なお、上記した実施形態の各変形例を組み合わせた構成も全て本発明に含まれるものである。
以下、図25に示すメモリマップを参照して本発明に係るワークフローシステムを構成する各情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
図25は、ワークフローシステムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体(記憶媒体)のメモリマップを説明する図である。
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報,作成者等も記憶され、かつ、プログラム読み出し側のOS等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
本実施形態における図10,図11,図12,図16,図21に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、CD−ROMやフラッシュメモリやFD等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク,ハードディスク,光ディスク,光磁気ディスク,CD−ROM,CD−R,DVD−ROM,磁気テープ,不揮発性のメモリカード,ROM,EEPROM,シリコンディスク等を用いることができる。
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ,データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。