JP5011463B2 - ワークフロー制御システムおよびワークフロー制御プログラム - Google Patents

Description

本発明は、ワークフロー制御システムおよびワークフロー制御プログラムに関する。

会社内などで、申請書を電子的に回覧させて決済するための種々のワークフローシステムが提案されている。ワークフローシステムにおいては、承認権限をもつ社員の情報を、承認順、つまり、回議ルートにしたがってテーブルに格納しておき、申請書類を、テーブルに格納された回議ルートにしたがって、社員にメール送信するように構成されている。特許文献１には、人事異動などによる回議ルートの変更に柔軟に対応できるように、ルート・コードのそれぞれについて、リンク・データおよび文書の回議順を定めたルート・テーブル、文書の種類を特定する文書種類特定コードと、ルート・コードとを対応させたルート選択テーブル、並びに、構成員特定コードのそれぞれと、リンク・データとを対応させたアサイン・テーブルとを備えたワークフロー制御システムが開示されている。特許文献１に開示されたシステムによれば、アサイン・テーブルの構成員特定コードやリンク・データを修正・変更することにより、他のテーブルを変更することなく、人事異動などに伴う回議ルートの変更に対応することが可能となる。

また、特許文献２には、回議者、回議順を特定する回議順ＩＤ、回議者の権限タイプを示す権限タイプコードを特定する情報を含むレコードを格納した回議情報テーブルと、隣接する回議順ＩＤの先後を示す情報を含むレコードを格納した回議順連結テーブルとを備え、回議情報テーブル中にレコードを挿入するとともに、必要に応じて回議順連結テーブルも更新することにより、回議者の追加に対応できるフロー制御システムが開示されている。このように、ワークフロー制御システムにおいては、組織変更にともなって、或いは、回議者の要望に応じて、回議者および回議順を含む回議フローが変更できるようになっている。
特開２００３−１１４９６７号公報 特開２００５−２８４７６５号公報

特許文献１や特許文献２に示すフロー制御システムにおいても、回議フローの変更の際には、テーブルの更新が必要となる。たとえば、特許文献２に示す技術では、回議者の追加や変更、或いは、回議順の変更のためには、回議情報テーブルおよび回議順連結テーブルが更新される。

また、通常の回議の際には、文書ごとに、当該文書が現在どの回議順に位置しているかを示すステータスを含むテーブルが利用され、このテーブルは、文書が、承認者や決裁者の操作にしたがって、文書テーブルのレコードのステータスが変更される。

従来、上述した回議フローの変更に伴うテーブルの更新や、回議における文書のテーブルにおけるステータスの変更の際には、申請者、承認者或いは決裁者が、クライアントの入力装置を操作して、回議者や回議順の変更、或いは、申請や承認を指示することに応答して、端末装置とネットワークを介して接続されたワークフロー制御システムにおいて、たとえば、他のトランザクションによるデータの更新を排除するために、いったん更新対象となるテーブル或いはテーブルのレコードをロックした上で、以下の処理が実行される。
（１）ワークフロー制御システムは、処理対象となるテーブルについて、ワークテーブルを記憶装置上に作成し、ワークテーブルを対象として、新たな回議者や回議順についてのレコードを追加し、或いは、該当レコードにおいてステータスを示す値を更新する。
（２）次いで、ワークフロー制御システムは、更新されたワークテーブルのレコードを、本来のテーブル（実テーブル）に書き換える。

上述したように、本来のテーブルのレコードを更新した後に、ロックを解除して、他のトランザクションによるテーブルのレコードの更新を認める。フロー上に存在する文書が増大するのにしたがって（つまり、ワークフローシステムの利用者が増大するのに従って）、他のトランザクションが、あるトランザクションにかかるテーブル更新に伴うロックによってロック待ちとなる状態が多発する可能性がある。

特に、上記（１）、（２）の作業中のテーブル或いはレコードのロックがボトルネックとなる。

本発明は、利用者が増大して、フロー上に存在する文書数などが大きくなっても、ワークテーブルの更新においてロック待ちが生じず、円滑なフロー制御を実現するシステムおよびプログラムを提供することを目的とする。

本発明の目的は、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバおよびその回議順を示す情報と、申請書について何らかのアクションが求められるメンバを特定する情報と、を含むレコードを有する、１以上のテーブルからなるテーブル群を備え、申請書ＩＤにて特定される申請書のデータを、前記テーブル群を構成する１以上のテーブルのレコードに基づいた回議順にしたがって特定されたメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバであって、
クライアントからの申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記申請書ＩＤにて特定されるテーブルのレコードの更新を制御するために、それぞれが１以上のテーブルから構成される、複数のワークテーブル群を生成可能なテーブル制御手段と、
前記クライアントからのメンバの追加、更新或いは削除の指示の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、回議順において隣接するメンバとメンバとの間に新たなメンバを追加し、ある回議順のメンバを変更し、或いは、ある回議順のメンバを削除することを示す指示を受信して、前記１以上のテーブルにおいて、追加すべきレコードおよびその位置、更新すべきレコードおよびその位置、或いは、削除すべきレコードおよびその位置を特定するテーブル管理手段と、を備え、
前記テーブル制御手段が、
前記申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記受信した情報に基づく一連のレコード群をロックし、
前記複数生成可能なワークテーブル群のうち、何れか１つのワークテーブル群を生成し、当該ワークテーブル群を構成する１以上のワークテーブルに、前記１以上のテーブルでそれぞれロックされたレコード群を格納し、
前記テーブル管理手段からの、前記１以上のテーブルにおける、追加すべきレコードおよびその位置、更新すべきレコードおよびその位置、或いは、削除すべきレコードおよびその位置を示す情報に基づいて、前記生成されたワークテーブル群を構成するワークテーブルのそれぞれにおいて、レコードの追加、更新、削除を実行し、
前記ワークテーブル群を構成する１以上のワークテーブルのそれぞれの、追加、更新或いは削除されたレコードを、前記テーブル群を構成する１以上のテーブルに、それぞれ格納し、
その後、前記テーブル群を構成する１以上のテーブルにおいて、一連のレコード群のロックを解除するように構成されたことを特徴とするワークフロー制御サーバにより達成される。

また、本発明の目的は、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバおよびその回議順を示す情報と、申請書について何らかのアクションが求められるメンバを特定する情報と、を含むレコードを有する、１以上のテーブルからなるテーブル群を備え、申請書ＩＤにて特定される申請書のデータを、前記テーブル群を構成する１以上のテーブルのレコードに基づいた回議順にしたがって特定されたメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバであって、
クライアントからの申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記申請書ＩＤにて特定されるテーブルのレコードの更新を制御するために、それぞれが１以上のテーブルから構成される、複数のワークテーブル群を生成可能なテーブル制御手段と
前記クライアントからの申請書ＩＤにて特定される申請書について、申請或いは承認を含むアクションの受信にしたがって、前記テーブル群を構成する１以上のテーブルを参照して、前記回議順において、申請書について次にアクションが求められるメンバを特定して、当該テーブルのレコードにおいて、申請書について何らかのアクションが求められるメンバを特定する情報を更新すべきレコードを特定するワークフロー進行処理手段と、を備え、
前記テーブル制御手段が、
前記申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記受信した情報に基づく一連のレコード群をロックし、
前記複数生成可能なワークテーブル群のうち、何れか１つのワークテーブル群を生成し、当該ワークテーブル群を構成する１以上のワークテーブルに、前記１以上のテーブルでそれぞれロックされたレコード群を格納し、
前記ワークフロー進行処理手段からの、前記１以上のテーブルにおける、申請書について何らかのアクションが求められるメンバを特定する情報を更新すべきレコードの情報に基づいて、前記生成されたワークテーブル群を構成するワークテーブルのそれぞれにおいて、レコードを更新し、
前記ワークテーブル群を構成する１以上のワークテーブルのそれぞれの、更新されたレコードを、前記テーブル群を構成する１以上のテーブルに、それぞれ格納し、
その後、前記テーブル群を構成する１以上のテーブルにおいて、一連のレコード群のロックを解除するように構成されたことを特徴とするワークフロー制御サーバにより達成される。

本発明の好ましい実施態様においては、前記テーブル群を構成する１以上のテーブルのレコードが、当該レコードにかかるメンバが何らかのアクションをすべきであることを示すアクティブメンバフラグと、アクションが終了していることを示すアクション終了フラグを含み、前記ワークフロー進行処理手段が、前記テーブル群を構成する１以上のテーブルにおいて、アクティブメンバフラグおよび／またはアクション終了フラグを更新すべきレコードを特定し、
前記テーブル制御手段が、前記ワークテーブル群を構成する１以上のワークテーブルにおいて、前記特定されたレコードのアクティブメンバフラグおよび／またはアクション終了フラグを更新するように構成されたことを特徴とする請求項２に記載のワークフロー制御サーバ。

本発明の別の好ましい実施態様においては、前記テーブル群が、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバを特定する情報と、申請書について何らかのアクションが求められるメンバを特定する情報とを含むレコードを有するメンバテーブル、並びに、前記申請書ＩＤと、回議順において隣接する２つのメンバにおいて先行するスタートメンバを特定する情報と、後続するエンドメンバを特定する情報とを含むレコードを有するメンバ連結テーブルを含み、
前記テーブル制御手段が、複数生成可能なワークテーブル群のうちの、何れか１つのワークテーブル群として、前記メンバテーブルおよび前記メンバ連結テーブルのそれぞれのワークテーブルを含むワークテーブル群を生成するように構成されたことを特徴とする請求項１ないし３の何れか一項に記載のワークフロー制御サーバ。

本発明のさらに別の好ましい実施態様においては、前記テーブル群が、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバを特定する情報と、当該メンバが属する、一定のメンバの集合体であるファミリを特定する情報と、申請書について何らかのアクションが求められるメンバを特定する情報とを含むレコードを有するメンバテーブル、前記申請書ＩＤと、回議順において隣接する２つのメンバにおいて先行するスタートメンバを特定する情報と、後続するエンドメンバを特定する情報とを含むレコードを有するメンバ連結テーブル、前記申請書ＩＤと、前記ファミリを特定する情報と、前記申請書について何らかのアクションが求められるメンバが属するファミリを特定する情報と、を含むファミリテーブル、並びに、前記申請書ＩＤと、回議順において隣接する２つのファミリにおいて先行するスタートファミリを特定する情報と、後続するエンドファミリを特定する情報とを含むレコードを有するファミリ連結テーブルを含み、
前記テーブル制御手段が、複数生成可能なワークテーブル群のうちの、何れか１つのワークテーブル群として、前記メンバテーブル、メンバ連結テーブル、ファミリテーブルおよびファミリ連結テーブルのそれぞれのワークテーブルを含むワークテーブル群を生成するように構成されたことを特徴とする請求項１ないし３の何れか一項に記載のワークフロー制御サーバ。

また、本発明の好ましい実施態様においては、前記テーブル制御手段が、前記クライアントと前記制御サーバとの間のセッションについて、前記制御サーバが付与したセッションＩＤに基づいて、前記複数生成可能なワークテーブル群のうち、何れか１つのワークテーブル群を生成することを特徴とする請求項１ないし５の何れか一項に記載のワークフロー制御サーバ。

さらに、本発明の目的は、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバおよびその回議順を示す情報と、申請書について何らかのアクションが求められるメンバを特定する情報と、を含むレコードを有する、１以上のテーブルからなるテーブル群を備え、申請書ＩＤにて特定される申請書のデータを、前記テーブル群を構成する１以上のテーブルのレコードに基づいた回議順にしたがって特定されたメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバにおいて、前記ワークフロー制御サーバに、
クライアントからの申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記申請書ＩＤにて特定されるテーブルのレコードの更新を制御するために、それぞれが１以上のテーブルから構成される、複数のワークテーブル群を生成可能なテーブル制御ステップ、並びに、
前記クライアントからのメンバの追加、更新或いは削除の指示の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、回議順において隣接するメンバとメンバとの間に新たなメンバを追加し、ある回議順のメンバを変更し、或いは、ある回議順のメンバを削除することを示す指示を受信して、前記１以上のテーブルにおいて、追加すべきレコードおよびその位置、更新すべきレコードおよびその位置、或いは、削除すべきレコードおよびその位置を特定するテーブル管理ステップを実行させ、かつ、
前記ワークフロー制御サーバに、
前記申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記受信した情報に基づく一連のレコード群をロックするステップと、
前記複数生成可能なワークテーブル群のうち、何れか１つのワークテーブル群を生成し、当該ワークテーブル群を構成する１以上のワークテーブルに、前記１以上のテーブルでそれぞれロックされたレコード群を格納するステップと、
前記テーブル管理手段からの、前記１以上のテーブルにおける、追加すべきレコードおよびその位置、更新すべきレコードおよびその位置、或いは、削除すべきレコードおよびその位置を示す情報に基づいて、前記生成されたワークテーブル群を構成するワークテーブルのそれぞれにおいて、レコードの追加、更新、削除を実行するステップと、
前記ワークテーブル群を構成する１以上のワークテーブルのそれぞれの、追加、更新或いは削除されたレコードを、前記テーブル群を構成する１以上のテーブルに、それぞれ格納するステップと、
その後、前記テーブル群を構成する１以上のテーブルにおいて、一連のレコード群のロックを解除するステップと、を実行させることを特徴とするワークフロー制御プログラムにより達成される。

また、本発明の目的は、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバおよびその回議順を示す情報と、申請書について何らかのアクションが求められるメンバを特定する情報と、を含むレコードを有する、１以上のテーブルからなるテーブル群を備え、申請書ＩＤにて特定される申請書のデータを、前記テーブル群を構成する１以上のテーブルのレコードに基づいた回議順にしたがって特定されたメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバにおいて、前記ワークフロー制御サーバに、
クライアントからの申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記申請書ＩＤにて特定されるテーブルのレコードの更新を制御するために、それぞれが１以上のテーブルから構成される、複数のワークテーブル群を生成可能なテーブル制御ステップ、並びに、
前記クライアントからの申請書ＩＤにて特定される申請書について、申請或いは承認を含むアクションの受信にしたがって、前記テーブル群を構成する１以上のテーブルを参照して、前記回議順において、申請書について次にアクションが求められるメンバを特定して、当該テーブルのレコードにおいて、申請書について何らかのアクションが求められるメンバを特定する情報を更新すべきレコードを特定するワークフロー進行処理手段を実行させ、かつ、
前記ワークフロー制御サーバに、
前記申請書ＩＤを指定する情報の受信にしたがって、前記テーブル群を構成する１以上のテーブルにおいて、前記受信した情報に基づく一連のレコード群をロックするステップと、
前記複数生成可能なワークテーブル群のうち、何れか１つのワークテーブル群を生成し、当該ワークテーブル群を構成する１以上のワークテーブルに、前記１以上のテーブルでそれぞれロックされたレコード群を格納するステップと、
前記ワークフロー進行処理手段からの、前記１以上のテーブルにおける、申請書について何らかのアクションが求められるメンバを特定する情報を更新すべきレコードの情報に基づいて、前記生成されたワークテーブル群を構成するワークテーブルのそれぞれにおいて、レコードを更新するステップと、
前記ワークテーブル群を構成する１以上のワークテーブルのそれぞれの、更新されたレコードを、前記テーブル群を構成する１以上のテーブルに、それぞれ格納するステップと、
その後、前記テーブル群を構成する１以上のテーブルにおいて、一連のレコード群のロックを解除するステップと、を実行させることを特徴とするワークフロー制御プログラムにより達成される。

好ましい実施態様においては、前記テーブル群を構成する１以上のテーブルのレコードが、当該レコードにかかるメンバが何らかのアクションをすべきであることを示すアクティブメンバフラグと、アクションが終了していることを示すアクション終了フラグを含み、
前記ワークフロー進行処理ステップにおいて、前記ワークフロー制御サーバに、前記テーブル群を構成する１以上のテーブルにおいて、アクティブメンバフラグおよび／またはアクション終了フラグを更新すべきレコードを特定するステップを実行させ、かつ、
前記ワークフロー制御サーバに、
前記ワークテーブル群を構成する１以上のワークテーブルにおいて、前記特定されたレコードのアクティブメンバフラグおよび／またはアクション終了フラグを更新するステップを実行させる。

別の好ましい実施態様においては、前記テーブル群が、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバを特定する情報と、申請書について何らかのアクションが求められるメンバを特定する情報とを含むレコードを有するメンバテーブル、並びに、前記申請書ＩＤと、回議順において隣接する２つのメンバにおいて先行するスタートメンバを特定する情報と、後続するエンドメンバを特定する情報とを含むレコードを有するメンバ連結テーブルを含み、
前記ワークフロー制御サーバに、複数生成可能なワークテーブル群のうちの、何れか１つのワークテーブル群として、前記メンバテーブルおよび前記メンバ連結テーブルのそれぞれのワークテーブルを含むワークテーブル群を生成するステップを実行させる。

さらに別の好ましい実施態様においては、前記テーブル群が、回議すべき申請書を特定する申請書ＩＤと、申請書を回議すべきメンバを特定する情報と、当該メンバが属する、一定のメンバの集合体であるファミリを特定する情報と、申請書について何らかのアクションが求められるメンバを特定する情報とを含むレコードを有するメンバテーブル、前記申請書ＩＤと、回議順において隣接する２つのメンバにおいて先行するスタートメンバを特定する情報と、後続するエンドメンバを特定する情報とを含むレコードを有するメンバ連結テーブル、前記申請書ＩＤと、前記ファミリを特定する情報と、前記申請書について何らかのアクションが求められるメンバが属するファミリを特定する情報と、を含むファミリテーブル、並びに、前記申請書ＩＤと、回議順において隣接する２つのファミリにおいて先行するスタートファミリを特定する情報と、後続するエンドファミリを特定する情報とを含むレコードを有するファミリ連結テーブルを含み、
前記ワークフロー制御サーバに、複数生成可能なワークテーブル群のうちの、何れか１つのワークテーブル群として、前記メンバテーブル、メンバ連結テーブル、ファミリテーブルおよびファミリ連結テーブルのそれぞれのワークテーブルを含むワークテーブル群を生成するステップを実行させる。

また、好ましい実施態様においては、前記テーブル制御ステップにおいて、前記ワークフロー制御サーバに、前記クライアントと前記制御サーバとの間のセッションについて、前記制御サーバが付与したセッションＩＤに基づいて、前記複数生成可能なワークテーブル群のうち、何れか１つのワークテーブル群を生成するステップを実行させる。

本発明によれば、利用者が増大して、フロー上に存在する文書数などが大きくなっても、ロック待ちが生じず、円滑なフロー制御を実現するシステムおよびプログラムを提供することが可能となる。

以下、添付図面を参照して、本発明の実施の形態について説明する。図１は、本発明の実施の形態にかかるワークフロー制御サーバを含む全体構成を示すブロックダイヤグラムである。図１に示すように、ワークフロー制御サーバ（以下、単に「制御サーバ」とも称する。）１０には、ＬＡＮ、ＷＡＮなどのネットワーク１２を介して、クライアント１４−１、１４−２、・・・が接続できるようになっている。本実施の形態においては、制御サーバ１０を、企業の社員が、申請や承認の必要な申請書の回議に利用する。クライアント１４−１、１４−２、・・・のそれぞれは、社員が使用し、ネットワーク１２を介して、制御サーバ１０にアクセスし、申請書のデータを受け取って、申請書の所定の項目に入力するとともに、申請や承認など、申請書に必要な処理を施すことができるようになっている。なお、以下、特に役職などを限定しない場合に、クライアント１４を操作して、申請書を作成し、或いは、申請書を申請、承認等する者を、単に「社員」と称する。

図１に示すように、制御サーバ１０は、企業に属する社員、部署、役職などに関する定義情報である各種マスタを記憶したマスタデータベース（ＤＢ）１６と、回議する申請書に関する種々のテーブルを記憶したテーブルＤＢ１８とを備えている。これらマスタＤＢ１６およびテーブルＤＢ１８に記憶されたマスタやテーブルについては、後に詳述する。また、テーブルの更新の際に利用されるワークテーブルは、制御サーバ１０の記憶装置中に生成される。なお、本実施の形態において、記憶装置は、物理的には制御サーバ１０のハードディスク装置やＲＡＭなどのメモリを含む。

制御サーバ１０は、ネットワークを介したクライアント１４からの指示に応答して、各種テーブルのレコードの生成や更新を、後述するＤＢ制御部２４に指示するテーブル管理部２０と、テーブルＤＢ１８に記憶されたテーブルのレコードを参照して、申請書を回議順にしたがって回議する（つまりフローを進行させる）フロー制御部２２と、テーブル管理部２０やフロー管理部２２による指示に基づいて、トランザクションを制御するとともに、記憶装置中にワークテーブルを生成して、テーブルのレコード更新を実現するＤＢ制御部２４と、を備えている。また、制御サーバ１０は、クライアント１４の表示装置の画面上に表示すべき画像を生成して、クライアント１４に送信し、また、クライアント１４からの指示を受け入れるユーザインタフェース（Ｉ／Ｆ）２６を備えている。

図２は、本実施の形態にかかる制御サーバ１０における処理の概要、並びに、マスタＤＢ１６およびテーブルＤＢ１８に格納されたマスタおよびテーブルを示す図である。図２に示すように、制御サーバ１０においては、社員がクライアント１４を操作して、ログインし（ステップ２０１）、クライアント１４の表示装置の画面上に表示された画像を参照して、申請書を作成する（ステップ２０２）。申請書が完成すると、社員によるクライアント１４の操作にしがって、申請書のデータ（各種テーブルのレコード）が、テーブルＤＢ１８中のテーブルに保存される（ステップ２０３）。ステップ２０１〜２０３が、社員による申請書の作成に応答して実行される処理の概略である。

その一方、社員が申請書を承認或いは決裁する際には、社員のクライアント１４の操作に応答して、制御サーバ１０は、既存の申請書のデータをテーブルＤＢ１８のテーブルから読み出して、クライアント１４の表示装置の画面上に表示する（ステップ２１１）。社員はクライアント１４の表示装置の画面上に表示された申請書を参照して、申請書が承認或いは決裁可能であれば、入力装置を操作して、承認或いは決裁の指示を入力する。これに応答して、制御サーバ１０は、テーブルＤＢ１８中の必要なテーブルのレコードを生成し、或いは、レコードを更新する（ステップ２１２）。これら制御サーバ１０における処理については後に詳述する。

図２に示すように、本実施の形態においては、たとえば、マスタＤＢ１６は、社員マスタ１０１、部署マスタ１０２、役職マスタ１０３、役割マスタ１０４、アサインマスタ１０５、文書マスタ１０６、ルートマスタ１０７、ステータスマスタ１０８およびアクションマスタ１０９を記憶する。また、テーブルＤＢ１８は、実申請書テーブル１５１、履歴テーブル１５２、ファミリテーブル１５３、メンバテーブル１５４、ファミリ連結テーブル１５５、メンバ連結テーブル１５６および添付書類テーブル１５７を記憶する。

図３は、マスタＤＢ１６に記憶されたマスタのそれぞれのレコードの項目の例を示す図である。図３（ａ）に示すように、社員マスタのレコードは、社員コード、社員名称およびログインＩＤという項目を有する。図３（ｂ）に示すように、部署マスタのレコードは、部署コードおよび部署名称という項目を有する。図３（ｃ）に示すように、役職マスタのレコードは、役職コード、役職階級および役職名称という項目を有する。図３（ｄ）に示すように、役割マスタのレコードは、役割コードおよび役割名称という項目を有する。図３（ｅ）に示すように、アサインマスタのレコードは、社員コード、部署コード、役職コードおよび役割コードを有する。

ログインの際には、制御サーバ１０が社員マスタを参照して、社員がクライアント１４を操作して入力した社員コードおよびＩＤと、社員マスタに記憶された、入力された社員コードで特定されるレコード中のログインＩＤとが比較される。また、アサインマスタのレコードには、ある社員の、部署、役職、役割が関連付けられて記憶されている。したがって、制御サーバ１０の処理においては、まずアサインマスタを参照して、アサインマスタのレコードから、社員マスタ、部署マスタ、役職マスタ或いは役割マスタのレコードを特定することが可能となる。

また、本実施の形態においては、マスタＤＢ１６には、さらに、文書マスタ、ルートマスタ、権限マスタ、ステータスマスタ、アクションマスタなどが含まれる。図３（ｆ）に示すように、文書マスタは、文書コード、文書区分コード、文書名称および文書データ形式コードという項目を有する。図３（ｇ）に示すように、ルートマスタのレコードは、ルートコード、ルート名および文書区分コードという項目を有する。図３（ｈ）に示すように、権限マスタのレコードは、権限コードおよび権限名称という項目を有する。

また、図３（ｉ）に示すように、ステータスマスタのレコードは、ステータスコード、文書区分コード、ステータスタイプコードおよびステータス名称という項目を有し、図３（ｊ）に示すように、アクションマスタのレコードは、アクションコード、文書区分コード、アクションタイプコード、アクション名称、アクション後ステータスコードという項目を有する。

上述したマスタのレコードの項目は、一例にすぎず、各マスタは、図３に示した項目以外の項目を含み得ることは言うまでも無い。

本実施の形態においては、社員が、クライアント１４の入力装置を操作して、必要な情報を入力すると、制御サーバ１０は、文書を回議するために必要な種々のテーブルのレコードを生成して、生成された種々のテーブルのレコードを、テーブルＤＢ１８に記憶する。

図４は、テーブルＤＢ１８に記憶されたテーブルのそれぞれのレコードの項目を示す図である。図４（ａ）に示すように、実申請書テーブルのレコードは、申請書ＩＤ、文書コード、ステータスコード、ヘッダ社員コード、ヘッダ部署コード、ヘッダ役職コード、起案者社員コード、起案者部署コード、および、起案者役職コードという項目を有する。図４（ｂ）に示すように、履歴テーブルのレコードは、申請書ＩＤ，履歴ＩＤ、社員コード、部署コード、役職コード、権限コード、アクションコード、および、アクション実行日時という項目を有する。図４（ｃ）に示すように、ファミリテーブルのレコードは、申請書ＩＤ、ファミリＩＤ、アクティブファミリフラグおよびアクション終了フラグという項目を有する。図４（ｄ）に示すように、メンバテーブルのレコードは、申請書ＩＤ、ファミリＩＤ、メンバＩＤ、アクティブメンバフラグ、アクション終了フラグ、権限コード、社員コード、部署コード、役職コードおよび役割コードという項目を有する。図４（ｅ）に示すように、ファミリ連結テーブルは、申請書ＩＤ、スタートファミリＩＤおよびエンドファミリＩＤという項目を有する。図４（ｆ）に示すように、メンバ連結テーブルは、申請書ＩＤ、ファミリＩＤ、スタートメンバＩＤおよびエンドメンバＩＤという項目を有する。また、図４（ｇ）に示すように、添付書類テーブル（ｆ）は、申請書ＩＤ，添付書類ＩＤ、ファイル名、添付ファイルおよび添付者社員コードという項目を有する。なお、上述したテーブルのレコードの項目も、一例にすぎず、各テーブルは、図４に示した項目以外の項目を含み得ることは言うまでも無い。

図４（ａ）〜（ｇ）に示されるように、各テーブルのレコードのキー項目は申請書ＩＤであり、申請書ＩＤによって各テーブル中のレコードを特定できるようになっている。実申請書テーブルのレコードは、申請書ごとに１つだけ存在する。実申請書テーブルのレコードにより、ある社員（起案者）が作成し、回議する申請書を特定することができる。また、履歴テーブルのレコードには、承認や決裁した社員について、その行為（アクション）などが格納される。

さらに、本実施の形態においては、申請書ＩＤで規定される申請書の回議順は、ファミリテーブル、メンバテーブル、ファミリ連結テーブルおよびメンバ連結テーブルのレコードにより特定される。後に詳述するが、本実施の形態においては、回議順を規定するために、１以上のファミリ、および、ファミリ内のメンバが設けられている。図５（ａ）は、ある申請書の回議順の例を示す図である。図５（ａ）に示す例では、３つのファミリ（「ファミリ０」〜「ファミリ２」）が存在している。「ファミリ０」には、「メンバ０」として「申請者Ａ」が存在し、「ファミリ１」には、「メンバ０」として「承認者Ｂ」が存在するとともに、「メンバ１」として「承認者Ｃ」が存在し、「ファミリ２」には、「メンバ０」として「決裁者Ｅ」が存在する。図６（ａ）は、図５（ａ）に示す回議順を表すメンバテーブルおよびファミリテーブルのレコードの部分を示す図である。申請書ＩＤは全てのレコードで共通であるため図示していない。また、回議順を理解するために特に必要ではない項目についても、図示していない。

メンバテーブルにおいては、回議順に存在する社員のそれぞれのファミリＩＤ、メンバＩＤなどを含むレコードが格納されている。たとえば、符号６０１に示すレコードは、「ファミリ０」の「メンバ０」であることがわかる。図６（ａ）において、ＡＭＦは、アクティブメンバフラグを表し、ＦＭＦは、アクション終了フラグを表す。これらフラグについては後述する。また、ファミリテーブルにおいては、各ファミリのレコードは、ＡＦＦ（アクティブファミリフラグ）およびＦＦＦ（アクション終了フラグ）を含む。図６（ａ）において、 「ファミリ０」に関するファミリテーブルのレコードを符号６２１で示し、対応するメンバテーブルのレコードを符号６０１で示す。また、「ファミリ１」に関するファミリテーブルのレコードを符号６２２で示し、対応するメンバテーブルのレコードを符号６０２で示す。さらに、「ファミリ２」に関するファミリテーブルのレコードを符号６２３で示し、対応するメンバテーブルのレコードを符号６０３で示す。

図６（ａ）においては示さないが、図５（ａ）の回議順を表すために、ファミリ連結テーブルおよびメンバ連結テーブルのレコードも生成される。ファミリ連結テーブルのレコードにおける「スタートファミリＩＤ」は連結される２つのファミリのうち、スタート側（上流側）のファミリのファミリＩＤを示す。また、「エンドファミリＩＤ」は、連結される２つのファミリのうち、エンド側（下流側）のファミリのファミリＩＤを示す。図５（ａ）、図６（ａ）に示す例では、ファミリ連結テーブルには、「スタートファミリＩＤ」が「０」で「エンドファミリＩＤ」が「１」であるようなレコード、および、「スタートＩＤ」が「１」で「エンドファミリＩＤ」が「２」であるようなレコードが含まれる。

同様に、メンバ連結テーブルのレコードにおける「スタートメンバＩＤ」は連結される２つのメンバのうち、スタート側（上流側）のメンバのメンバＩＤを示す。また、「エンドメンバＩＤ」は、連結される２つのメンバのうち、エンド側（下流側）のメンバのメンバＩＤを示す。

以下、図２などを参照して、本実施の形態にかかる制御サーバを利用した、回議のための申請書の作成および申請、並びに、承認や決裁の権限をもつ社員による承認、決裁の処理の概略について説明する。

申請者となる社員は、クライアント１４を操作してログインＩＤを入力して、ログインする。ログインの際には、制御サーバ１０は、社員マスタ１０１を参照して、ログインした社員に関するレコード見出して、入力されたログインＩＤと、社員マスタ１０１のレコード中のログインＩＤとを照合してログインさせるか否かを判断する。また、社員によるクライアント１４の操作に応答して、制御サーバ１０は、文書マスタ１０６から所定の文書のコードや、ルートマスタ１０７からのレコードを取得して、文書などを含む初期画面を作成してクライアント１４に送信する。社員は、クライアント１４を操作して、ルートマスタのレコードの情報などに基づいて、回議すべき社員を特定していく。制御サーバ１０は、クライアント１４からの指示にしたがって、アサインマスタ１０５などを参照して、文書を回議すべき他の社員の情報をクライアント１４に提示すればよい。

申請書とするべき文書、回議すべき社員および回議順の情報が確定すると、社員からの入力やマスタの参照結果に基づいて、実申請書テーブル１５１、ファミリテーブル１５３、メンバテーブル１５４、ファミリ連結テーブル１５５およびメンバ連結テーブル１５６のレコードが生成される。ここで、実申請書テーブル１５１は、申請書を特定するものであり、ファミリテーブル１５３、メンバテーブル１５３、ファミリ連結テーブル１５５およびメンバ連結テーブル１５６は、回議順を特定するとともに、回議中の申請書のステータス（現在誰の承認或いは決裁が済んでおり、誰の承認を待つ状態であるか）を示すものとなる。

また、申請書に添付書類があれば、添付書類テーブル１５６のレコードも生成される。その一方、実申請書テーブルのレコードが生成された段階では、履歴テーブル１５２のレコードは生成されず、申請書が申請され、また、承認や決裁された場合に、制御サーバ１０により、履歴テーブル１５２のレコードが生成される。

フロー進行処理部２２は、ファミリテーブル１５３、メンバテーブル１５４、ファミリ連結テーブル１５５およびメンバ連結テーブル１５６を参照して、回議において次に承認或いは決済を求めるべき社員を特定して、その社員に対してメールを送信する。

メールを受信した社員は、クライアント１４を操作して、制御サーバ１０にアクセスして、承認或いは決裁すべき申請書の情報を取得すべく、制御サーバ１０に指示を与える。これに応答して、実申請書テーブル１５１のレコードに示す申請書データを、クライアント１４の表示装置の画面上に表示し（ステップ２１１）、社員による承認或いは決裁を促す。

社員による承認或いは決裁を受けると、制御サーバ１０は、承認或いは決裁にしたがって、実申請書テーブル、ファミリテーブル、メンバテーブルなどのレコードを更新するとともに、承認或いは決裁した社員に関する履歴テーブルのレコードを生成する。

上述したように、申請者となる社員が申請書を作成した際には、テーブルＤＢ１８中に各種のテーブルが作成される。また、承認或いは決裁すべき社員による承認や決裁がなされた際には、実申請書テーブル、ファミリテーブル、メンバテーブルなどのレコードの更新や、履歴テーブルのレコードの追加が行われる。

さらに、本実施の形態においては、申請者となる社員（或いは承認者となる社員であっても良い）が、回議順を変更し、或いは、承認者や決裁者となる社員を削除或いは追加する場合に、これに伴うテーブル（たとえば、ファミリテーブル、メンバテーブル、メンバ連結テーブル）のレコードの追加、削除、更新も行われる。

特に、回議順の変更に伴うテーブルのレコードの更新など、或いは、承認や決裁の際のテーブルの更新などは、制御サーバ１０に対して大きな負荷を与えることになるため、本実施の形態では、後述する手法で負荷を分散して、円滑な処理の進行を実現している。

まず、回議順の変更等に伴うテーブルのレコードの更新について説明する。図７は、図５（ａ）に示す回議順の状態を示すレコードが各種テーブル（たとえば、図６（ａ）参照）に記憶された状態で、申請者となる社員によるクライアント１４に応答して、制御サーバ１０により生成され、クライアント１４の画面上に表示された経費申請を行うための経費申請画面の例を示す図である。

図７においては、実申請書テーブルの該当レコードの情報などに基づいて、申請者の情報が表示されるとともに（符号７０１参照）、申請書自体を作成することができるようになっている（符号７０２参照）。また、画面の下部には、申請者、承認者、決裁者およびその回議順の表示欄が設けられている（符号７０３参照）。図７において、「回０」と表されている欄７１１が、図５（ａ）や図６（ａ）における「ファミリ０（図５（ａ）の符号５０１参照）」に相当する。また、「回１」および「回２」と表されている欄７１２、７１３が、それぞれ、「ファミリ１（図５（ａ）の符号５０２参照）」および「ファミリ２（図５（ａ）の符号５０３参照）」に相当する。また、欄７１２および欄７１３には、メンバを追加するためのボタン７２２、７２３が設けられている。社員は、クライアント１４を操作して、ボタン７２２或いは７２３をオンすることで、ボタンのオンにかかるファミリにメンバを追加することができる。

たとえば、クライアント１４の操作によりボタン７２２がオンされると、制御サーバ１０のテーブル管理部２０は、アサインマスタ１０５などを参照して、当該ファミリに追加されるメンバとなりえる社員のリストを作成して、クライアント１４の画面上に表示する。社員がクライアント１４を操作して、リスト中の社員を指定すると、制御サーバ１０は、そのファミリにメンバとして指定された社員が追加された状態を示す画像を作成して、これをクライアント１４の画面上に表示する。また、制御サーバ１０のテーブル管理部２０は、指定された社員の社員コードを一時的に記憶しておく。この社員コードは、「申請」ボタンまたは「一時保存」ボタンがオンされたときの、メンバテーブル、ファミリテーブルおよびメンバ連結テーブルの更新のために使用される。

図８は、画面上「回１」と表されたファミリである「ファミリ１」に承認者が追加された状態を示す、経費申請画面の例を示す図である。この例は、図５（ｂ）に示す回議順の状態に相当する。欄８０３において、「回１」と表示されたファミリには、「承認者Ｄ」がメンバとして追加されている。図５（ｂ）においても、「ファミリ１」には、「メンバ２」として「承認者Ｄ」が追加されている（符号５１２参照）。

図８に示す画面が表示された状態で、社員がクライアント１４を操作して、「申請」ボタンまたは「一時保存」ボタンをオンすると、制御サーバ１０のテーブル管理部１０、および、その動作を後に詳述するＤＢ制御部２４は、これに応答して、回議順が、欄８０３に示された状態と合致するように、メンバテーブル中に追加されたメンバに関するレコードを追加する。図６（ｂ）は、レコードが追加された状態のメンバテーブルおよびファミリテーブルを示す図である。この例では、既存のファミリにメンバを追加するだけであったので、ファミリテーブルに変更はない。図６（ｂ）に示すメンバテーブルにおいて、ファミリＩＤが「１」である（つまり、「ファミリ１」である）レコード群（符号６１２参照）において、「社員コードＤ」という社員コードを含むレコードが追加されている。

無論、新たにファミリが追加される場合も考えられる。この場合には、メンバテーブルおよびファミリテーブルにレコードが追加される。また、ファミリ連結テーブルのレコードも追加および更新される。また、回議順からメンバを削除する場合には、メンバテーブルからレコードが削除される。ファミリ全体が削除される場合には、メンバテーブルに加えて、ファミリテーブルやファミリ連結テーブルのレコードも削除、更新等される。

上述したメンバテーブルなどのレコードの更新における具体的な処理については後述する。

次に、承認や決裁の際のテーブルの更新について説明する。以下、図５（ｂ）に示す回議順に基づいて、図６（ｂ）に示すようなレコードを格納したメンバテーブルおよびファミリテーブルがテーブルＤＢ１８に記憶された状態を考える。図９〜図１０は、申請前から最終的な決裁にいたるまでのメンバテーブルおよびファミリテーブルの状態の例を示す図である。なお、図９、図１０においても、処理において参照されない項目や、処理に無関係なレコードは省略されている。

申請者である社員Ａにより申請がされる以前には、メンバテーブルおよびファミリテーブルは、図９（ａ）に示す状態となっている。メンバテーブルにおいて、アクティブメンバフラグ（ＡＭＦ）は、現在文書が、そのレコードに格納された社員の元にあり、当該社員による何らかのアクション（たとえば、申請、承認、決裁）を待っている状態を示している。同様に、ファミリテーブルにおいて、アクティブファミリフラグは、現在文書が、そのファミリに属する社員の元にあることを示している。したがって、申請前の状態であれば、ワークテーブルにおいて、文書を申請すべき「社員Ａ（社員コード＝Ａの社員）」のレコードにおいて、ＡＭＦが「１」であり、また、アクションが終了している社員は存在しないため、各レコードのＦＭＦは「０」となっている。また、ファミリテーブルにおいて、文書を申請すべき「社員Ａ」が属するファミリである「ファミリ０（ファミリＩＤ＝０のファミリ）」のレコードにおいて、ＡＦＦが「１」である。また、全てのメンバによるアクションが終了しているファミリは存在しないため、各レコードのＦＦＦは「０」となっている。

図１１は、テーブル更新処理の処理ロジックを示すフローチャートである。後に、実際のテーブルの更新処理と関連させて再度説明するため、ここでは、主として、フラグのセットおよびクリアについて説明する。また、この例では、単純化するため、社員はクライアントを操作して、申請書を申請し、承認する場合、つまり、申請書が上流から下流に流れていく場合について説明する。実際には、申請書は承認者により承認されず、申請者に戻るように、下流から上流に戻る場合もある。また、実際の回議においては、回議順で次の順番に位置する社員を飛ばして、さらにその次に位置する社員など他の社員に申請書が送られる場合や、回議において同時に複数の社員に申請書が送られる場合などがあり得る。

制御サーバ１０のフロー進行処理部２２は、メンバテーブル、ファミリテーブル、ファミリ連結テーブルおよびメンバ連結テーブルを参照して、アクションのあった社員の次の回議順にあるような社員を特定する（ステップ１１０１）。次いで、フロー進行処理部２２は、メンバテーブルを参照して、次の回議順にある社員が、現在の回議順にある社員と同じファミリに属しているか否かを判断する（ステップ１１０２）。ステップ１１０２でイエス(Yes)と判断された場合には、フロー進行処理部２２は、メンバテーブルにおいて、現在の回議順にある社員のレコードについて、そのＦＭＦを「１」にセットするとともに、ＡＭＦを「０」にリセットする）（ステップ１１０３）。

その一方、ステップ１１０２でノー(No)と判断された場合には、フロー進行処理部２２は、メンバテーブルにおいて、現在の回議順にある社員のレコードについて、そのＦＭＦを「１」にセットするとともに、ＡＭＦを「０」にリセットする（ステップ１１０４）。このステップ１１０４は、ステップ１１０３と同様の処理である。さらに、フロー進行処理部２２は、メンバテーブルにおいて、次の回議順にかかるファミリの全メンバ（つまり、次の回議順にかかるファミリに属する全社員）のレコードについて、ＡＭＦを「１」にセットする（ステップ１１０５）。また、フロー進行処理部２２は、ファミリテーブルにおいて、現在の回議順にある社員が属するファミリのレコードについて、ＦＦＦを「１」にセットするとともに、「ＡＦＦ」を「０」にリセットする（ステップ１１０６）。さらに、フロー進行処理部２２は、ファミリテーブルにおいて、次の回議順にある社員が属するファミリのレコードについて、ＡＦＦを「１」にセットする（ステップ１１０７）。

このように、本実施の形態においては、回議される申請書が位置しているファミリに属するメンバについては、メンバテーブルのレコード中、ＡＭＦが「１」となっている。また、回議が終了した（つまり、必要なアクションが実行済み）のメンバについては、メンバテーブルのレコード中、ＦＭＦが「１」となっている。また、回議される申請書が位置しているファミリについては、ファミリテーブルの該当レコード中、ＡＦＦが「１」となっている。また、回議が終了した（つまり、所属するメンバの全てのアクションが実行済み）のファミリについては、ＦＦＦが「１」となっている。本実施の形態では、これらフラグにより、現在申請書が位置しており、アクションが必要となっているメンバや、当該メンバが属するファミリ、或いは、回議が終了したメンバおよびファミリを特定することができる。

たとえば、「社員Ａ」がクライアントを操作して、申請書を申請すると、制御サーバ１０のフロー進行処理部２２は、メンバテーブル、ファミリテーブル、メンバ連結テーブルおよびファミリ連結テーブルを参照して、次の回議順の社員を特定する。この例では、「社員Ｂ（社員コード＝Ｂの社員）」が次の回議順の社員となる。フロー進行処理部２２がメンバテーブルを参照すると、次の回議順の「社員Ｂ」は、「社員Ａ」と同一ファミリでないことがわかるため（図１１のステップ１１０２でノー）、以下、ステップ１１０４から１１０７の処理が実行されて、メンバテーブルおよびファミリテーブルのフラグが書き換えられる（図９（ｂ）の符号９０１、９０２参照）。テーブルの更新が終了すると、次の回議順の「社員Ｂ」のクライアントに対してメールが送信され、「社員Ｂ」による承認待ちの状態となる。

「社員Ｂ」がクライアントを操作すると、制御サーバ１０が経費申請書承認画面（図示せず）をクライアントに送信し、クライアントの表示装置上に表示する。経費申請書承認画面は、経費申請画面（図７参照）に類似するものである。

「社員Ｂ」がクライアントを操作して、申請書を承認すると、制御サーバ１０のフロー進行処理部２２は、メンバテーブル、ファミリテーブル、メンバ連結テーブルおよびファミリ連結テーブルを参照して、次の回議順の社員を特定する。この例では、「社員Ｃ（社員コード＝Ｃの社員）」が次の回議順の社員となる。フロー進行処理部２２がメンバテーブルを参照すると、次の回議順の「社員Ｃ」は、「社員Ｂ」と同一のファミリであることがわかるため、ステップ１１０２でイエス(Yes)と判断されメンバテーブルの一部レコードのフラグが更新される（図９（ｃ）の符号９０３参照）。

図１０（ａ）に示すように、次の回議順の「社員Ｃ（社員コード＝Ｃ）」の承認時には、「社員Ｃ」とさらに次の回議順の「社員Ｄ（社員コード＝Ｄの社員）」とが同一のファミリであるため、メンバテーブルの一部のレコードが更新される（符号１００１参照）。図１０（ｂ）に示すように、「社員Ｄ（社員コード＝Ｄ）の社員」の承認時には、「社員Ｄ」とさらに次の回議順の「社員Ｅ（社員コード＝Ｅの社員）」とが同一のファミリではないため、メンバテーブルおよびファミリテーブルのレコードのフラグが更新される（符号１００２、１００３参照）。図１０（ｃ）は、社員Ｅの決裁時に、フロー進行処理部２２により更新されたメンバテーブルおよびファミリテーブルを示す。図１１のフローには示していないが、次の回議順が存在しない場合には、フロー進行処理部２２は、メンバテーブルおよびファミリテーブルにおいて、決裁或いは承認した社員のレコードのＦＭＦおよびＦＦＦをそれぞれ「１」にするとともに、ＡＭＦおよびＡＦＦを「０」にリセットする。

このように、回議順の追加や変更、或いは、申請者による申請や承認者による承認の際には、メンバテーブルおよびファミリテーブルのレコードの更新が生じる。そこで、本実施の形態においては、テーブルＤＢ１８をアクセスしてレコードを実際に更新するＤＢ制御部２４を設け、テーブル管理部２０やフロー進行処理部２２はＤＢ制御部２４にレコードの更新を指示するように構成される。

以下、ＤＢ制御部２４による処理について説明する。図１２は、制御サーバ１０のＤＢ制御部２４、および、テーブルＤＢ１８などを含む記憶装置の構成を示すブロック図である。図１２に示すように、記憶装置１２００は、テーブルＤＢ１８を含む。図１２には図示しないが、記憶装置１２００は、マスタＤＢ１６も含む。ここにいう記憶装置１２００は、物理的には、制御サーバ１０のハードディスク装置およびＲＡＭなどのメモリを含む。

図１２に示すように、記憶装置１２００には、さらに、複数のワークテーブル群を含み得る。本実施の形態においては、ＤＢ制御部２４により、記憶装置１２００中に１０個のワークテーブル群１２０１−１〜１２０１−１０が作成され得る。ワークテーブル群（たとえば、ワークテーブル群１２０１）には、テーブルＤＢ１８中のテーブルの所定数のレコードがコピーされ、或いは、新規に所定項目を有する所定数のレコードが作成される。

図１３および図１４は、本実施の形態にかかる制御サーバ１０において、テーブルＤＢ１８のテーブルのレコードを作成する際に実行される処理を示すフローチャートである。図１３に示すように、
ユーザＩ／Ｆ２６が、クライアント１４からのログオンを受信すると（ステップ１３０１）、セッションＩＤを採番する（ステップ１３０２）。セッションＩＤはクライアント１４にも送信され、このセッションにおいては、クライアント１４は受信したセッションＩＤを利用する。

なお、クライアントのログオンの際には制御サーバ１０はユーザ認証を実行する。ユーザ認証などの後、ユーザＩ／Ｆ２６が、クライアント１４から申請書選択情報を受信すると、たとえば、テーブル管理部２０に、受信した申請書選択情報を通知する（ステップ１３０３）。テーブル管理部２０は、申請書選択情報を参照して、申請書ＩＤ、社員コードなどを特定する。これにより、テーブル管理部２０は、ファミリテーブル、メンバテーブル、ファミリ連結テーブルおよびメンバ連結テーブルなど、各種テーブルにおいて、申請書に関連する一連のレコード群を特定する（ステップ１３０４）。ここで、申請書ＩＤおよび社員コードと、メンバテーブル等のフラグを参照して、制御サーバ１０にアクセスしたクライアントを操作する社員の元に申請書が位置しているか、つまり、当該社員が申請書を申請し或いは承認する状態であるかを判断して、当該社員の元に申請書が位置している場合のみ、ステップ１３０４以降の処理を実行するように構成しても良い。

ステップ１３０４においては、たとえば、それぞれのテーブルにおいて、申請書選択情報にて示される申請書ＩＤと同じ申請書ＩＤをもつようなレコード群を特定すればよい。ここでは、ファミリテーブル、メンバテーブル、ファミリ連結テーブルおよびメンバ連結テーブルについて詳細に説明するが、他のテーブルについても、レコードの追加、更新、削除がある場合には、同様の処理が施される。

ＤＢ制御部２４は、一連のレコード群の情報の通知を受けると、ＤＢ制御部２４は、記憶装置１２００中に、それぞれのテーブルのワークテーブル（ファミリワークテーブル、メンバワークテーブル、ファミリ連結ワークテーブルおよびメンバ連結ワークテーブル）を含むワークテーブル群＃Ｎ（図中、符号１２０１−Ｎで示す）を生成する（ステップ１３０５）。ステップ１３０５において、ワークテーブル群＃Ｎの一連のレコードをロックする。このワークテーブル群を構成するワークテーブルには、一連のレコード群が格納される。

なお、本実施の形態においては、ワークテーブル群＃Ｎの番号「Ｎ」は、セッションＩＤの末尾一桁の数字を使用する。これにより、最大で１０個のワークテーブル群を生成することが可能となる。

このような処理が終了すると、たとえば、テーブル管理部２０は、経費申請画面を作成して、ユーザＩ／Ｆ２６に伝達する（ステップ１３０６）。ユーザＩ／Ｆ２６は、経費申請画面をクライアント１４に送信する（ステップ１３０７）。或いは、クライアント１４の操作者が、承認者である場合には、フロー進行処理部２２が、経費申請書承認画面を作成し、ユーザＩ／Ｆ２６が、経費申請書承認画面をクライアント１４に送信する。

図１４に示すように、ユーザＩ／Ｆ２６が、クライアント１４からのアクションを受信すると（ステップ１４０１）、その情報が、テーブル管理部２０やフロー進行処理部２２に伝達される。アクションには、申請書の申請や承認が含まれる。以下、クライアント１４から、申請や承認などのアクションが送信され、フロー進行処理部２２が、図１１に示すようにテーブルのフラグを更新すべく処理を実行する場合について説明する。しかしながら、以下の処理は、クライアント１４からユーザＩ／Ｆ２６にファミリやメンバの追加（図５（ａ）、（ｂ）、図７および図８参照）の指示が与えられた場合にも同様に実行される。

図１４に示すように、フロー進行処理部２２は、メンバテーブル、ファミリテーブル、メンバ連結テーブルおよびファミリ連結テーブル中、更新すべきレコードおよび当該レコード中の項目の値を特定する（ステップ１４０２）。たとえば、図１１に示すように、レコードのフラグを「１」にセットすること、或いは、「０」にリセットすることが該当する。更新すべきレコードおよびレコード中の項目の値の情報は、ＤＢ管理部２４に伝達される。

ＤＢ管理部２４は、ワークテーブル群＃ＮおよびテーブルＤＢにおいて一連のレコードをロックする（ステップ１４０３）。次いで、ＤＢ管理部２４は、メンバワークテーブル、ファミリワークテーブル、メンバ連結ワークテーブル、ファミリ連結ワークテーブルの、更新すべきレコードの項目の値を、伝達された情報に従って更新する（ステップ１４０４）。次いで、ＤＢ管理部２４は、ワークテーブル群＃Ｎ中のメンバワークテーブル、ファミリワークテーブル、ファミリ連結ワークテーブル、メンバ連結ワークテーブルを、それぞれ、メンバテーブル、ファミリテーブル、ファミリ連結テーブルおよびメンバ連結テーブルの対応する部分にコピーする（ステップ１４０５）。つまり、ワークテーブルとして取り出したレコードに、更新後のワークテーブルのレコードの値を、それぞれ書き込む。その後、ＤＢ管理部４４は、ワークテーブル群＃Ｎを削除し（ステップ１４０５）、ワークテーブル群＃ＮおよびテーブルＤＢ１８において、メンバテーブル、ファミリテーブル、メンバ連結テーブル、ファミリ連結テーブルの一連のレコードのロックを解除する（ステップ１４０６）。

ＤＢ制御部２４はテーブルのレコードの更新が終了し、ロックを解除したことをフロー進行処理部２２に通知する。この通知は、ユーザＩ／Ｆ２６にも伝達される。ユーザＩ／Ｆ２６は、クライアント１４に処理終了を通知する（ステップ１４０７）。

なお、処理が完了する前にクライアント１４がログオフし、或いは、何らかの理由で、クライアント１４とワークフロー制御サーバ１０との間のセッションが途切れた場合には、ＤＢ制御部２４は、ワークテーブル群＃Ｎを削除し、テーブルＤＢ１８のテーブルの一連のロックを解除する。たとえば、図１３の処理により、クライアント１４に経費申請画面が送信された状態で、クライアント１４がログオフした場合には、上述の通り、ＤＢ制御部２４は、ワークテーブル群＃Ｎの削除と、テーブルのロックの解除とを実行する。

図１３および図１４の処理は、並列的に実行される。たとえば、あるクライアント（クライアント１４−１）からのログオンにより、その末尾が「０」であるようなセッションＩＤが採番され、ワークテーブル群＃０が生成され、ワークテーブル群＃０の更新が行われ地得る状態で、他のクライアント（クライアント１４−２）からのログオンにより、その末尾が「１」であるようなセッションＩＤが採番されれば、ワークテーブル群＃１が生成され、ワークテーブル群＃０の更新と並列的に、ワークテーブル群＃１が更新され得る。

本実施の形態によれば、更新の対象となるテーブルのそれぞれについて、一連のレコード群（同じ申請書ＩＤをもつ一連のレコード群）からなるワークテーブルを生成し、テーブル中の一連のレコード群をコピーする。本実施の形態においては、ワークテーブル群は複数生成できるようになっており、たとえば、クライアントのアクセスに対して制御サーバ１０が与えたセッションＩＤの末尾の数字Ｎと同じ値を有するワークテーブル群＃Ｎが生成される。つまり、セッションＩＤの末尾の数字に基づいて、ワークテーブル群が割り当てられる。これにより、複数のクライアントからの指示にしたがって、複数の申請書を作成し、或いは、複数の申請書を回議する場合であっても、テーブル更新に伴うロックによりロック待ちになる状態が生じる可能性を減じることができる。

本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

たとえば、前記実施の形態においては、セッションＩＤの末尾の数字に基づいて、ワークテーブル群を割り当てていたがこれに限定されるものではなく、クライアントのログオン順に、ワークテーブル群の割り当てを決定しても良い。或いは、ログオンしたクライアントを操作している社員の社員ＩＤの末尾一桁の数字に基づいて、ワークテーブル群を割り当てても良い。また、前記実施の形態においては、１０個のワークテーブル群を生成可能としているが、これに限定されるものではない。

さらに、前記実施の形態においては、回議順は、メンバテーブル、ファミリテーブル、ファミリ連結テーブルおよびメンバ連結テーブルの４つのテーブルにより特定できるように構成されている。本実施の形態においては、メンバの集合体としてファミリという概念を導入し、ファミリ内を構成するメンバを特定するためのテーブル（メンバテーブル）およびファミリ内のメンバの回議順を特定するためのテーブル（メンバ連結テーブル）を設けるとともに、申請書を回議させるべきファミリを特定するためのテーブル（ファミリテーブル）およびファミリ間の回議順を特定するためのテーブル（ファミリ連結テーブル）を採用している。

しかしながら、回議順を特定するテーブルは上記構成に限定されるものではない。たとえば、メンバテーブルおよびメンバ連結テーブルにより回議順を決定するように構成しても良いし、単一のルートテーブルにより回議順を決定するように構成しても良い。つまり、本実施の形態においては、申請書ごとに回議すべきメンバおよび間の順序がテーブルに格納されていれば良い。図１５（ａ）、（ｂ）は、それぞれ、本発明の他の実施の形態にかかるメンバテーブルおよびメンバ連結テーブルの部分の例を示す図である。これは、図６（ａ）、（ｂ）に示すように、ある申請書ＩＤをもつ申請書について、「社員Ａ（社員コード＝Ａの社員）」〜「社員Ｅ（社員コード＝Ｅ）」の社員に至るまで、「社員Ａ」〜「社員Ｅ」の順で回議順が決定されている状態を示している。他の実施の形態においては、メンバテーブルは図１６（ａ）に示すように、図４（ｄ）に示すメンバテーブルからファミリＩＤを除いたような項目を有している。また、図１６（ｂ）に示すように、メンバ連結テーブルも、図４（ｇ）に示すメンバ連結テーブルからファミリＩＤを除いた構成となっている。

他の実施の形態においても、制御サーバ１０は、図１３および図１４に示す処理ステップにしたがって、図１５（ａ）、（ｂ）に示すような、メンバテーブルおよびメンバ連結テーブルにおいて、同じ申請書ＩＤを有する一連のレコード群がロックされ（ステップ１３０４、１３０５等）、セッションＩＤに基づいて、所定番号のワークテーブル群が生成されて、メンバテーブルのレコード群が、メンバワークテーブルにコピーされるとともに、メンバ連結テーブルのレコード群が、メンバ連結ワークテーブルにコピーされることになる。その後、ワークテーブル群のワークテーブルの該当レコードが更新され（ステップ１４０４）、ワークテーブルのレコードが、テーブルのレコードにコピーされる（ステップ１４０５）。このような処理の後、レコード群のロックが解除される（ステップ１４０６）。

先に述べたように、回議を構成するメンバおよびメンバ間の回議順が、単一のルートテーブルにより表される場合であっても本発明を適用することができる。たとえば、特許文献１に示すように、ルートテーブルを利用することができる。

図１は、本発明の実施の形態にかかるワークフロー制御サーバを含む全体構成を示すブロックダイヤグラムである。 図２は、本実施の形態にかかる制御サーバにおける処理の概要、並びに、マスタＤＢおよびテーブルＤＢに格納されたマスタおよびテーブルを示す図である。 図３（ａ）〜（ｈ）は、それぞれ、本実施の形態にかかる社員マスタ、部署マスタ、役職マスタ、役割マスタ、アサインマスタ、文書マスタ、ルートマスタおよび権限マスタのレコードに含まれる項目を示す図である。 図４（ａ）〜（ｆ）は、それぞれ、実申請書テーブル、履歴テーブル、ファミリテーブル、メンバテーブル、ファミリ連結テーブル、メンバ連結テーブル、添付書類テーブルのレコードに含まれる項目を示す図である。 図５（ａ）、（ｂ）は、それぞれ、ある申請書の回議順の例を示す図である。 図６（ａ）、（ｂ）は、それぞれ、図５（ａ）、（ｂ）に示す回議順を表すメンバテーブルおよびファミリテーブルのレコードの部分を示す図である。 図７は、クライアントの表示装置に表示される画面の例を示す図である。 図８は、クライアントの表示装置に表示される画面の例を示す図である。 図９（ａ）〜（ｃ）は、それぞれ、社員Ａの申請前、社員Ａの申請時および社員Ｂの承認時におけるメンバテーブル、ファミリテーブルの状態を示す図である。 図１０（ａ）〜（ｃ）は、それぞれ、社員Ｃの承認時、社員Ｄの承認時および社員Ｅの決裁時におけるメンバテーブル、ファミリテーブルの状態を示す図である。 図１１は、本実施の形態にかかるワークフロー更新処理の例を示すフローチャートである。 図１２は、制御サーバのＤＢ制御部、および、テーブルＤＢなどを含む記憶装置の構成を示すブロック図である。 図１３は、本実施の形態にかかる制御サーバにおいて、テーブルＤＢのテーブルのレコードを作成する際に実行される処理を示すフローチャートである。 図１４は、本実施の形態にかかる制御サーバにおいて、テーブルＤＢのテーブルのレコードを作成する際に実行される処理を示すフローチャートである。 図１５（ａ）、（ｂ）は、それぞれ、本発明の他の実施の形態にかかるメンバテーブルおよびメンバ連結テーブルの部分の例を示す図である。 図１６（ａ）、（ｂ）は、それぞれ、他の実施の形態にかかるメンバテーブルおよびメンバ連結テーブルのレコードに含まれる項目を示す図である。

符号の説明

１０ ワークフロー制御サーバ
１２ ネットワーク
１４ クライアント
１６ マスタＤＢ
１８ テーブルＤＢ
２０ テーブル管理部
２２ フロー進行処理部
２４ ＤＢ制御部
２６ ユーザＩ／Ｆ

Claims (12)

1. １以上のレコードを有する１以上のテーブルからなるテーブル群を備え、前記テーブル群は、回議すべき申請書を特定する申請書ＩＤおよび前記申請書を回議すべきメンバを示す情報を含むレコードを有するメンバテーブルと、前記申請書ＩＤおよび回議順を示す情報を含むレコードを有するメンバ連結テーブルと、を備え、前記申請書ＩＤで特定される申請書のデータを、前記回議順に従って特定されるメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバであって、
   それぞれが１以上のテーブルから構成される、１以上のワークテーブル群を生成するとともに、生成した前記ワークテーブルを用いて前記テーブル群のテーブルのレコードを更新するデータベース制御手段と、
   クライアントからのログオン指示の受信に従って、一連のレコード群を特定し、当該一連のレコード群を特定する情報を前記データベース制御手段に与え、前記ログオン指示後の当該クライアントからの更新指示の受信に従って、当該更新指示の受信に応じて行う更新内容を特定し、当該特定した更新内容とともに更新の指示を前記データベース制御手段に与えるテーブル管理手段と、を備え、
   前記ログオン指示は、前記申請書ＩＤを備え、
   前記更新指示は、メンバを示す情報と、当該メンバの追加および削除のいずれかの処理指示を含み、さらに、前記処理指示が、メンバの追加である場合、前記更新指示は、前記回議順の中で、当該メンバを追加する位置を特定する追加位置情報を含み、
   前記テーブル管理手段は、
   前記メンバテーブルおよび前記メンバ連結テーブルの中の、前記ログオン指示に含まれる前記申請書ＩＤに合致する申請書ＩＤを備えるレコード群を、前記一連のレコード群として特定し、
   前記処理指示がメンバの追加である場合、前記更新指示で示されるメンバの、前記メンバテーブルのレコードを生成し、前記一連のレコード群に追加するとともに、前記回議順が前記追加位置情報で特定される位置となるよう前記一連のレコード群の中の前記メンバ連結テーブルのレコードを更新する処理を前記更新内容とし、
   前記処理指示がメンバの削除である場合、前記一連のレコード群の中の前記メンバテーブルのレコードから前記更新指示で示されるメンバを示す情報を含むレコードを削除するとともに、前記一連のレコード群の中の前記メンバ連結テーブルのレコードを更新する処理を前記更新内容とし、
   前記データベース制御手段は、
   前記テーブル管理手段から前記一連のレコード群を特定する情報を受信すると、当該一連のレコード群を格納するワークテーブルを生成するとともに当該情報で特定される一連のレコード群を当該ワークテーブルに格納し、
   前記テーブル管理手段から前記更新の指示および更新内容を受信すると、
   前記一連のレコード群をロックし、
   前記生成したワークテーブルの各レコードを、当該更新内容に従って更新し、
   前記ロックした一連のレコード群を前記更新後のワークテーブルの各レコードに置き換え、
   前記置き換え後、前記一連のレコード群のロックを解除すること
   を特徴とするワークフロー制御サーバ。
2. １以上のレコードを有する１以上のテーブルからなるテーブル群を備え、前記テーブル群は、回議すべき申請書を特定する申請書ＩＤ、前記申請書を回議すべきメンバを示す情報およびメンバ毎のアクションの処理の現状を示す情報を含むレコードを有するメンバテーブルと、前記申請書ＩＤおよび回議順を示す情報を含むレコードを有するメンバ連結テーブルと、を備え、前記申請書ＩＤにて特定される申請書のデータを、前記回議順に従って特定されるメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバであって、
   それぞれが１以上のテーブルから構成される、１以上のワークテーブル群を生成するとともに、生成した前記ワークテーブルを用いて前記テーブル群のテーブルのレコードを更新するデータベース制御手段と、
   クライアントからのログオン指示の受信に従って、一連のレコード群を特定し、当該一連のレコード群を特定する情報を前記データベース制御手段に与え、前記ログオン指示後の当該クライアントからのアクション指示の受信に従って、当該アクション指示に応じて行う更新内容および更新するレコード（更新レコード）を特定し、当該特定した更新内容、更新レコードを特定する情報および更新の指示を前記データベース制御手段に与えるとともに、前記回議順に従って前記申請書を次に回議するメンバを特定し、当該メンバに対して通知するフロー進行処理手段と、を備え、
   前記ログオン指示は、前記申請書ＩＤおよび当該ログオン指示の送信元のクライアントを使用するメンバを特定する情報を備え、
   前記回議順は、メンバを特定する情報により規定され、
   前記フロー進行処理手段は、
   前記メンバテーブルの中の、前記ログオン指示に含まれる前記申請書ＩＤに合致する申請書ＩＤを備えるレコードを、前記一連のレコード群として特定し、
   前記一連のレコード群の中の、前記ログオン指示に含まれるメンバを特定する情報に合致する前記メンバを示す情報を含むレコードを、前記更新レコードとして特定し、
   前記アクション指示を受信すると、前記更新レコードの、前記アクション処理の現状を示す情報を、アクション処理終了を意味する情報に変更する処理を前記更新内容とし、
   前記ログオン指示に含まれるメンバを示す情報の次の回議順のメンバとして前記メンバ連結テーブルに規定されるメンバを、前記次に回議するメンバとして特定し、
   前記データベース制御手段は、
   前記フロー進行処理手段から前記一連のレコード群を特定する情報を受信すると、当該一連のレコード群を格納するワークテーブルを生成するとともに当該情報で特定される一連のレコード群を当該ワークテーブルに格納し、
   前記フロー進行処理手段から前記更新の指示、前記更新レコードを特定する情報および更新内容を受信すると、
   前記更新レコードをロックし、
   前記生成したワークテーブルの中の、前記更新レコードに対応するレコードを、当該更新内容に従って更新し、
   前記一連のレコード群を前記更新後のワークテーブルの各レコードに置き換え、
   前記置き換え後、前記更新テーブルのレコードのロックを解除すること
   を特徴とするワークフロー制御サーバ。
3. 前記メンバテーブルは、メンバ毎に求められるアクションを示す情報を含み、
   前記メンバ毎のアクション処理の現状を示す情報は、前記申請書に対し、当該メンバが前記求められるアクションをすべきであることを示すアクティブメンバフラグと、当該メンバのアクションが終了していることを示すアクション終了フラグを含み、
   前記フロー進行処理手段は、前記更新レコードのメンバに求められるアクションと、前記回議順において当該メンバの次の回議順のメンバに求められるアクションとを比較し、両者が同じ場合、前記一連のレコード群のレコードの中の前記メンバテーブルのレコード群内の、前記次の回議順のメンバを示す情報を含むレコードの、前記アクティブメンバフラグを、前記アクションをすべき状態とし、両者が異なる場合、前記一連のレコード群のレコードの中の前記メンバテーブルのレコード群内の、前記次の回議順のメンバに求められるアクションと同じアクションを求められるメンバを示す情報を含む全レコードの、前記アクティブメンバフラグを、前記アクションをすべき状態とする処理を、さらに、前記更新内容とすること
   を特徴とする請求項２に記載のワークフロー制御サーバ。
4. 前記メンバ連結テーブルは、前記回議順を示す情報として、前記回議順が隣接する２つのメンバのうち、回議順が先となるメンバを特定するスタートメンバ情報と回議順が後となるメンバを特定するエンドメンバ情報とを備えること
   を特徴とする請求項１ないし３の何れか一項に記載のワークフロー制御サーバ。
5. 前記テーブル群は、
   前記申請書ＩＤと、メンバに求めるアクション種を示す情報であるファミリＩＤと、当該アクション種毎の処理の現状を示す情報と、を含むレコードを有するファミリテーブルと、
   前記申請書ＩＤと、前記アクション種の実行順を示す情報を含むレコードを有するファミリ連結テーブルと、を備え、
   前記ファミリテーブルのアクション種毎の処理の現状を示す情報は、当該アクション種が求められるメンバが当該アクションをすべきであることを示すアクティブファミリフラグと、当該アクション種が求められる全メンバによる当該アクションの処理が終了していることを示すアクション終了フラグと、を備え、
   前記ファミリ連結テーブルは、前記アクション種の実行順が隣接する２つのファミリのうち、前記実行順が先となるファミリを特定するスタートファミリ情報と、前記実行順が後となるファミリを特定するエンドファミリ情報と、を備え、
   前記メンバ連結テーブルは、前記ファミリＩＤをさらに備え、かつ、前記回議順を示す情報として、同一ファミリ内のメンバの中で、前記回議順が隣接する２つのメンバのうち、回議順が先となるメンバを特定するスタートメンバ情報と回議順が後となるメンバを特定するエンドメンバ情報と、を備え、
   前記テーブル管理手段は、前記ファミリテーブルおよび前記ファミリ連結テーブルの中の、前記ログオン指示に含まれる前記申請書ＩＤに合致する申請書ＩＤを備えるファミリテーブルおよびファミリ連結テーブルのレコードを、さらに、前記一連のレコード群に含めること
   を特徴とする請求項１ないし３の何れか一項に記載のワークフロー制御サーバ。
6. 当該制御サーバは、前記クライアントから前記ログオン指示を受信する毎に、セッションＩＤを発行し、
   前記データベース制御手段は、前記生成する前記ワークテーブルを、前記セッションＩＤに対応付けて管理すること
   を特徴とする請求項１ないし５の何れか一項に記載のワークフロー制御サーバ。
7. １以上のレコードを有する１以上のテーブルからなるテーブル群を備え、前記テーブル群は、回議すべき申請書を特定する申請書ＩＤ、前記申請書を回議すべきメンバを示す情報を含むレコードを有するメンバテーブルと、前記申請書ＩＤおよび回議順を示す情報を含むレコードを有するメンバ連結テーブルと、を備え、前記申請書ＩＤで特定される申請書のデータを、前記回議順に従って特定されるメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバにおいて、当該ワークフロー制御サーバを、
   それぞれが１以上のテーブルから構成される、１以上のワークテーブル群を生成するとともに、生成した前記ワークテーブルを用いて前記テーブル群のテーブルのレコードを更新するデータベース制御手段と、
   クライアントからのログオン指示の受信に従って、一連のレコード群を特定し、当該一連のレコード群を特定する情報を前記データベース制御手段に与え、前記ログオン指示後の当該クライアントからの更新指示の受信に従って、当該更新指示の受信に応じて行う更新内容を特定し、当該特定した更新内容とともに更新の指示を前記データベース制御手段に与えるテーブル管理手段として機能させ、
   前記ログオン指示は、前記申請書ＩＤを備え、
   前記更新指示は、メンバを示す情報と、当該メンバの追加および削除のいずれかの処理指示を含み、さらに、前記処理指示が、メンバの追加である場合、前記更新指示は、前記回議順の中で、当該メンバを追加する位置を特定する追加位置情報を含み、
   前記テーブル管理手段において、前記ワークフロー制御サーバを、さらに、
   前記メンバテーブルおよび前記メンバ連結テーブルの中の、前記ログオン指示に含まれる前記申請書ＩＤに合致する申請書ＩＤを備えるレコード群を、前記一連のレコード群として特定し、
   前記処理指示がメンバの追加である場合、前記更新指示で示されるメンバの、前記メンバテーブルのレコードを生成し、前記一連のレコード群に追加するとともに、前記回議順が前記追加位置情報で特定される位置となるよう前記一連のレコード群の中の前記メンバ連結テーブルのレコードを更新する処理を前記更新内容とし、
   前記処理指示がメンバの削除である場合、前記一連のレコード群の中の前記メンバテーブルのレコードから前記更新指示で示されるメンバを示す情報を含むレコードを削除するとともに、前記一連のレコード群の中の前記メンバ連結テーブルのレコードを更新する処理を前記更新内容とするよう機能させ、
   前記データベース制御手段において、前記ワークフロー制御サーバを、さらに、
   前記テーブル管理手段から前記一連のレコード群を特定する情報を受信すると、当該一連のレコード群を格納するワークテーブルを生成するとともに当該情報で特定される一連のレコード群を当該ワークテーブルに格納し、
   前記テーブル管理手段から前記更新の指示および更新内容を受信すると、
   前記一連のレコード群をロックし、
   前記生成したワークテーブルの各レコードを、当該更新内容に従って更新し、
   前記ロックした一連のレコード群を前記更新後のワークテーブルの各レコードに置き換え、
   前記置き換え後、前記一連のレコード群のロックを解除するよう機能させるためのワークフロー制御プログラム。
8. １以上のレコードを有する１以上のテーブルからなるテーブル群を備え、前記テーブル群は、回議すべき申請書を特定する申請書ＩＤ、前記申請書を回議すべきメンバを示す情報、およびメンバ毎のアクションの処理の現状を示す情報を含むレコードを有するメンバテーブルと、前記申請書ＩＤおよび回議順を示す情報を含むレコードを有するメンバ連結テーブルと、を備え、前記申請書ＩＤにて特定される申請書のデータを、前記回議順に従って特定されるメンバのクライアントに、ネットワークを介して送信することにより、前記申請書を回議するワークフロー制御サーバにおいて、当該ワークフロー制御サーバを、
   それぞれが１以上のテーブルから構成される、１以上のワークテーブル群を生成するとともに、生成した前記ワークテーブルを用いて前記テーブル群のテーブルのレコードを更新するデータベース制御手段と、
   クライアントからのログオン指示の受信に従って、一連のレコード群を特定し、当該一連のレコード群を特定する情報を前記データベース制御手段に与え、前記ログオン指示後の当該クライアントからのアクション指示の受信に従って、当該アクション指示に応じて行う更新内容および更新するレコード（更新レコード）を特定し、当該特定した更新内容、更新レコードを特定する情報および更新の指示を前記データベース制御手段に与えるとともに、前記回議順に従って前記申請書を次に回議するメンバを特定し、当該メンバに対して通知するフロー進行処理手段として機能させ、
   前記ログオン指示は、前記申請書ＩＤおよび当該ログオン指示の送信元のクライアントを使用するメンバを特定する情報を備え、
   前記回議順は、メンバを特定する情報により規定され、
   前記フロー進行処理手段において、前記ワークフロー制御サーバを、さらに、
   前記メンバテーブルの中の、前記ログオン指示に含まれる前記申請書ＩＤに合致する申請書ＩＤを備えるレコードを、前記一連のレコード群として特定し、
   前記一連のレコード群の中の、前記ログオン指示に含まれるメンバを特定する情報に合致する前記メンバを示す情報を含むレコードを、前記更新レコードとして特定し、
   前記アクション指示を受信すると、前記更新レコードの、前記アクション処理の現状を示す情報を、アクション処理終了を意味する情報に変更する処理を前記更新内容とし、
   前記ログオン指示に含まれるメンバを示す情報の次の回議順のメンバとして前記メンバ連結テーブルに規定されるメンバを、前記次に回議するメンバとして特定するよう機能させ、
   前記データベース制御手段において、前記ワークフロー制御サーバを、さらに、
   前記フロー進行処理手段から前記一連のレコード群を特定する情報を受信すると、当該一連のレコード群を格納するワークテーブルを生成するとともに当該情報で特定される一連のレコード群を当該ワークテーブルに格納し、
   前記フロー進行処理手段から前記更新の指示、前記更新レコードを特定する情報および更新内容を受信すると、
   前記更新レコードをロックし、
   前記生成したワークテーブルの中の、前記更新レコードに対応するレコードを、当該更新内容に従って更新し、
   前記一連のレコード群を前記更新後のワークテーブルの各レコードに置き換え、
   前記置き換え後、前記更新テーブルのレコードのロックを解除するよう機能させるためのワークフロー制御プログラム。
9. 前記メンバテーブルは、メンバ毎に求められるアクションを示す情報を含み、
   前記メンバ毎のアクション処理の現状を示す情報は、前記申請書に対し、当該メンバが前記求められるアクションをすべきであることを示すアクティブメンバフラグと、当該メンバのアクションが終了していることを示すアクション終了フラグを含み、
   前記フロー進行処理手段において、前記ワークフロー制御サーバを、さらに、
   前記更新レコードのメンバに求められるアクションと、前記回議順において当該メンバの次の回議順のメンバに求められるアクションとを比較し、両者が同じ場合、前記一連のレコード群のレコードの中の前記メンバテーブルのレコード群内の、前記次の回議順のメンバを示す情報を含むレコードの、前記アクティブメンバフラグを、前記アクションをすべき状態とし、両者が異なる場合、前記一連のレコード群のレコードの中の前記メンバテーブルのレコード群内の、前記次の回議順のメンバに求められるアクションと同じアクションを求められるメンバを示す情報を含む全レコードの、前記アクティブメンバフラグを、前記アクションをすべき状態とする処理を、さらに、前記更新内容とするよう機能させるための請求項８に記載のワークフロー制御プログラム。
10. 前記メンバ連結テーブルは、前記回議順を示す情報として、前記回議順が隣接する２つのメンバのうち、回議順が先となるメンバを特定するスタートメンバ情報と回議順が後となるメンバを特定するエンドメンバ情報とを備えること
    を特徴とする請求項７ないし９の何れか一項に記載のワークフロー制御プログラム。
11. 前記テーブル群は、
    前記申請書ＩＤと、メンバに求めるアクション種を示す情報であるファミリＩＤと、当該アクション種毎の処理の現状を示す情報と、を含むレコードを有するファミリテーブルと、
    前記申請書ＩＤと、前記アクション種の実行順を示す情報を含むレコードを有するファミリ連結テーブルと、を備え、
    前記ファミリテーブルのアクション種毎の処理の現状を示す情報は、当該アクション種が求められるメンバが当該アクションをすべきであることを示すアクティブファミリフラグと、当該アクション種が求められる全メンバによる当該アクションの処理が終了していることを示すアクション終了フラグと、を備え、
    前記ファミリ連結テーブルは、前記アクション種の実行順が隣接する２つのファミリのうち、前記実行順が先となるファミリを特定するスタートファミリ情報と、前記実行順が後となるファミリを特定するエンドファミリ情報とを備え、
    前記メンバ連結テーブルは、前記ファミリＩＤをさらに備え、かつ、前記回議順を示す情報として、同一ファミリ内のメンバの中で、前記回議順が隣接する２つのメンバのうち、回議順が先となるメンバを特定するスタートメンバ情報と回議順が後となるメンバを特定するエンドメンバ情報と、を備え、
    前記テーブル管理手段において、前記ワークフロー制御サーバを、さらに、
    前記ファミリテーブルおよび前記ファミリ連結テーブルの中の、前記ログオン指示に含まれる前記申請書ＩＤに合致する申請書ＩＤを備えるファミリテーブルおよびファミリ連結テーブルのレコードを、さらに、前記一連のレコード群に含めるよう機能させるためのこと
    を特徴とする請求項７ないし９の何れか一項に記載のワークフロー制御プログラム。
12. 当該制御サーバは、前記クライアントから前記ログオン指示を受信する毎に、セッションＩＤを発行し、
    前記データベース制御手段において、前記ワークフロー制御サーバを、
    前記生成する前記ワークテーブルを、前記セッションＩＤに対応付けて管理するよう機能させるための請求項７ないし１１の何れか一項に記載のワークフロー制御プログラム。

Images