ワークフローシステムおよびワークフローシステムの管理方法およびプログラムおよび記録媒体
【課題】異なる複数のワークフローに分散されて稼動するワークフローシステムの各ワークフローにおけるデータベース処理の高速化と、各ワークフローの一括管理による保守作業の軽減を実現し、大量の業務を抱える大規模組織におけるワークフローシステムのデータベース処理の高速化と保守作業負荷の軽減を図ること。
【解決手段】サーバ６００は、異なる複数のワークフロー（サーブレット１，サーブレット２）に分散された各ワークフロー間で共有するデータベース（組織ＤＢ６０８，ユーザＤＢ６０９，役割ＤＢ６１１）の内容を、前記各ワークフローでそれぞれキャッシュしておきデータベース処理を高速化しておき、また、サーバ６００の管理プログラムは、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュする構成を特徴とする。
【解決手段】サーバ６００は、異なる複数のワークフロー（サーブレット１，サーブレット２）に分散された各ワークフロー間で共有するデータベース（組織ＤＢ６０８，ユーザＤＢ６０９，役割ＤＢ６１１）の内容を、前記各ワークフローでそれぞれキャッシュしておきデータベース処理を高速化しておき、また、サーバ６００の管理プログラムは、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュする構成を特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なる複数のワークフローに分散され、前記各ワークフロー間でデータベースを共有するワークフローシステムおよびワークフローシステムの管理方法およびプログラムおよび記録媒体に関する。
【背景技術】
【０００２】
電子文書の承認業務の効率を向上させるインフラのひとつとして、ワークフローシステムがある。ワークフローシステムは、ワークフロー、組織、担当者といった対象が相互に依存しあったシステムを構成していることから、これらの対象の中のいずれかを変更しようとすると、他の対象も影響を受けざるおえないような変更を余儀なくされていた。
【０００３】
このため、ワークフローのカスタマイズは可能であるとしても、例えば、組織の変更といった対象の変更を行おうとした場合、組織に関連する対象も変更しなくてはならず、関連対象の検索等が複雑化し、簡単には対処できないという問題があった。
【０００４】
この問題に対し、特許文献１（特開２０００−２５０９６７号公報）は、ワークフロー管理機能と実行環境を分散化させることで、この問題を解決させようとした。
【０００５】
具体的には、ワークフロー制御サーバは、ワークフローを論理的な業務単位を形成するタスクと、入出力データと処理条件を含んだ階層構造の業務オブジェクトで構成し、この階層構造の各層の業務オブジェクト単位にワークフローの制御及び管理を行おうというものである。
【０００６】
組織や人の変更については、例えば、人の変更は、作業者と秘書エージェントの追加・削除を、組織の変更については、秘書エージェントの属性変更で対応する構成となっている。
【特許文献１】特開２０００−２５０９６７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記特許文献１では、組織・役割といったワークフロー共通のデータについても入出力データを業務オブジェクトに含んでいるため、組織変更等においては、各業務オブジェクトに含まれる組織情報データである秘書エージェントの属性をそれぞれ更新する必要があり、特に大量の業務を抱える大規模組織においては、システム管理者の保守作業負荷増大につながるといった問題があった。
【０００８】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、異なる複数のワークフローに分散された各ワークフロー間で共有するデータベースの内容を前記各ワークフローでそれぞれキャッシュし、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュすることにより、異なる複数のワークフローに分散されて稼動するワークフローシステムにおいて、各ワークフローにおけるデータベース処理の高速化と各ワークフローの一括管理による保守作業の軽減を実現し、大量の業務を抱える大規模組織におけるワークフローシステムのデータベース処理の高速化と保守作業負荷の軽減を図ることができるワークフローシステムおよびワークフローシステムの管理方法およびプログラムおよび記録媒体を提供することである。
【課題を解決するための手段】
【０００９】
本発明は、異なる複数のワークフローに分散されたワークフローシステムにおいて、該ワークフローシステムで用いる情報を管理するデータベースを前記各ワークフロー間で共有する共有手段と、前記データベースの内容を前記各ワークフローでそれぞれキャッシュするキャッシュ手段と、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュするリフレッシュ手段とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、異なる複数のワークフローに分散された各ワークフロー間で共有するデータベースの内容を前記各ワークフローでそれぞれキャッシュし、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュすることにより、異なる複数のワークフローに分散されて稼動するワークフローシステムにおいて、各ワークフローにおけるデータベース処理の高速化と、データベースの変更時にも各ワークフローをリブートすることなく各ワークフロー間のキャッシュの一貫性を保証することができる等の効果を奏する。
【００１１】
従って、各ワークフローの一括管理を実現し、大量の業務を抱える大規模組織におけるワークフローシステムのデータベース処理の高速化と保守作業負荷の軽減を両立することができる。
【００１２】
例えば、人事関連，総務関連といったカテゴリごとに伝票情報，経路情報を管理者の管理負担を増大させることなく、また、データベース処理効率を落とすことなく、独立して運用管理できるとともに、組織情報，役割情報については共通情報として一括管理が可能となる。これにより、分散ワークフローの各サブシステムにおける電子文書を含めた開発の効率の向上，システム管理者の運用効率の向上を実現できる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して、本発明の詳細を説明する。
【００１４】
図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【００１５】
本実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末（ワークフロー及び伝票設計用端末）４００、業務を遂行する処理者（担当者）に対応して設けられたワークフロー操作用コンピュータ端末（ワークフロー操作用端末）３００、ワークフローを実行するための各種テーブル，各種プログラムを格納するワークフローサーバ２００を備えている。
【００１６】
これらワークフロー及び伝票設計用端末４００，ワークフロー操作用端末３００，ワークフローサーバ２００は、それぞれネットワーク５００に接続され運用されている。
【００１７】
ワークフロー及び伝票設計用端末４００は、伝票デザイナプログラム４０１及びシステム管理プログラム４０２を有し、ワークフローサーバ２００上の図示しない管理プログラムと通信して、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末４００は、ワークフローサーバ２００に組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，各種伝票情報等を登録することができる。このワークフロー及び伝票設計用端末４００は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ２００に接続することが可能になる。
【００１８】
ワークフロー操作用端末３００は、ワークフロー操作用端末３００上で実行されるＷｅｂブラウザ３０１を用いて、伝票に関するアクセス情報をワークフローサーバ２００に対してＨＴＴＰで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Ｊａｖａ（登録商標）アプレット３０２等を利用することにより実行する。なお、このワークフロー操作用端末３００は、予め指定された所定の業務を行う担当者（例えば、起票者、課長、部長等）に配置されている。
【００１９】
ワークフローサーバ２００は、ワークフローシステムに関する情報（組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，配送情報テーブル等）を格納するＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａＳｅ Ｍａｎａｇｅｍｅｎｔ ＳｙＳｔｅｍ）２０５、ワークフロー操作用コンピュータ端末よりの要求を受け付けて要求を実行するためのＷＥＢサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３、ワークフロー通知機能を実現するＳＭＴＰサーバ２０４にて構成されている。
【００２０】
なお、ワークフロー操作用端末３００は、ワークフローサーバ２００に対して、伝票検索要求を送信し、ワークフローサーバ２００から返信される検索結果に基づいて、外部ＤＢに格納された決裁済みの伝票（電子文書）を閲覧可能である。
【００２１】
以下、図２を参照して、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成について説明する。
【００２２】
図２は、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【００２３】
図２において、１０１はＣＰＵで、ＲＯＭ１０３又はハードディスク（ＨＤ）（その他の記憶装置、例えば、フレキシブルディスク，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等どのような記憶装置であってもよい）１０４に格納されたプログラムをＲＡＭ１０２上にロードして実行することにより、コンピュータ全体を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。
【００２４】
１０７は通信インタフェースで、ネットワーク５００への接続を可能とする。１０５は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。１０６は表示装置で、ＣＲＴ，ＬＣＤ等で構成される。
【００２５】
なお、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５は、ワークフローサーバ２００のＨＤ１０４内に構築されている。また、ワークフローサーバ２００のＷＥＢサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３，ＳＭＴＰサーバ２０４は、ワークフローサーバ２００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２６】
また、図１に示したワークフロー操作用端末３００のＷｅｂブラウザ３０１は、ワークフロー操作用端末３００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２７】
さらに、図１に示したワークフロー操作用端末３００のＪａｖａ（登録商標）アプレット３０２は、ワークフロー操作用端末３００のＣＰＵ１０１が、ワークフローサーバ２００よりダウンロードされたプログラムをＷｅｂブラウザ３０１上で実行することにより、実現される。
【００２８】
また、図１に示したワークフロー及び伝票設計用端末４００の伝票デザイナプログラム４０１，システム管理プログラム４０２は、ワークフロー及び伝票設計用端末４００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２９】
図３は、図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【００３０】
本実施形態のワークフローシステムでは、ワークフロー操作用端末３００を用いて、図３に示すように、伝票の起票，伝票の承認／否認の手続きを、ノードと呼ばれる組織と役割で定義された担当者が行う。なお、伝票が配送されるノードをひとつに括ったものをビジネスプロセスと定義する。
【００３１】
図４は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。なお、この組織テーブルは、ワークフローを実現するための組織に関する情報を記憶するためのものである。
【００３２】
図４に示す組織テーブルにおいて、組織ＩＤは、任意の組織名をコードとして表記したものであり、常に上位組織ＩＤを網羅している。また、組織名は、組織ＩＤの表示上の名称を示したものである。さらに、親組織ＩＤは、上位の組織ＩＤを示したものである。
【００３３】
図５は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。なお、この役割テーブルは、ワークフローを実現するための役割に関する情報を記憶するためのものである。
【００３４】
図５に示す役割テーブルにおいて、役割ＩＤは、任意の役割名をコードとして表記したものである。また、役割名は、役割ＩＤの表示上の名称を示したものである。
【００３５】
図６は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。なお、このユーザテーブルは、ワークフローを利用するためのユーザの情報を記憶するためのものである。
【００３６】
図６に示すユーザテーブルにおいて、ユーザＩＤは、利用者を任意のコードとして表示したものである。また、パスワードは、ワークフローシステムにログインする際にユーザＩＤと共に認証に利用するためのものである。さらに、ユーザ名は、ユーザＩＤの表示上の名称を示したものである。
【００３７】
図７は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。なお、この役職テーブルは、ワークフローを利用するための役職の情報を記憶するためのものである。
【００３８】
図７に示すように、役職テーブルの各レコードは、ユーザテーブル内で定義されている「ユーザＩＤ」，役割テーブル内で定義されている「役割ＩＤ」，組織テーブル内で定義されている「組織ＩＤ」で構成されている。
【００３９】
図８は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。なお、この配送定義情報は、伝票が配送される経路を定義した情報を記憶するためのものである。
【００４０】
ここでは、一例として役割が「社員」→「部長」→「本部長」→「事業本部長」→「社長」の順に伝票配送をする例を示している。このように伝票の配送経路を定義した場合、この配送経路の配送定義情報は、図８に示すような５レコードの情報として作成される。
【００４１】
以下、配送定義情報の作成方法について説明する。
【００４２】
例えば、伝票名が「交通費」の場合、まず、ユーザがワークフロー及び伝票設計用端末４００から、システム管理プログラムを用いて、伝票名に「交通費」と設定し、次に、各ノードを設定する。ノード１を例にすると、ノード１に役割ＩＤに部長を示すコード「Ｕ０００７」を設定し、対象となる組織を選択（ここでは組織ＩＤ「８０」の「Ａ会社」を選択）することにより、「伝票名」が「交通費」，「組織ＩＤ」が「８０」，「ノード番号」が「１」，「経路役割ＩＤ」が「部長」を示す役割ＩＤ「００４」、「経路組織ＩＤ」が役割を担う組織ＩＤとして設定される。なお、ここでは、対象となる組織として、組織ＩＤ「８０」の「Ａ会社」が選択されており、役割ＩＤ「部長」を持つ配送対象者は決定されない。そのため、経路組織ＩＤは「ＮＵＬＬ」となっている（図中では空白で示している）。
【００４３】
図９は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。なお、この配送情報テーブルは、後述する図１０に示すワークフローシステムにおける配送処理時に図８に示した配送定義情報に基づいて生成されるものであり、ワークフローの経路，状態等を記憶するためのものである。また、この配送情報テーブルは、特に、ユーザＩＤ「Ｕ００１２」のユーザが起票した場合に対応する。この場合、伝票は、ユーザＩＤ「Ｕ００１２」，「Ｕ０００７」，「Ｕ０００３」，「Ｕ０００２」，「Ｕ０００１」のように配送されることとなる。
【００４４】
以下、図１０を参照して、本発明のワークフローシステムにおける配送処理手順の全体の流れについて説明する。
【００４５】
図１０は、本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０３による配送処理に対応する。なお、図中、Ｓ５０００〜Ｓ５０１３は各ステップを示す。
【００４６】
まず、ワークフロープログラム２０３を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）が、ワークフロー操作用端末３００より伝票処理要求を受信すると（ステップＳ５０００）、配送処理を開始する。
【００４７】
ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分である「起票」，「承認」，「否認」に基づいて、配送処理を切り替えていく（ステップＳ５００１）。
【００４８】
ステップＳ５００１において、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「起票」であると判定した場合には、ステップＳ５００２において、ワークフローサーバ２００のＣＰＵは、起票時の情報として、ノード番号「０」を配送情報テーブルに設定する。「処理ユーザ」には、起票したユーザのユーザＩＤを設定する。
【００４９】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図８に示したように、配送情報テーブルのノード番号「０」のレコードに、伝票名に「交通費」、伝票番号を起票時に発行される伝票番号（ここでは「００００１」とする）、ノード番号に「０」、処理ユーザを起票ユーザのユーザＩＤ「Ｕ００１２」、状態に「処理済」を設定する。
【００５０】
次に、ステップＳ５００３において、ワークフローサーバ２００のＣＰＵは、現在のノード番号を「１」とし、ステップＳ５０００で受信した伝票処理要求の伝票名に対応する配送定義情報（図８）を参照し、ノード番号「１」の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５１】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」を取得する。
【００５２】
一方、ステップＳ５００１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「否認」であると判定した場合には、ステップＳ５００４において、ワークフローサーバ２００のＣＰＵは、配送情報テーブル（図９）を参照して現在のノード番号を取得する。
【００５３】
次に、ステップＳ５００５において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップＳ５００７において、ステップＳ５００４で取得した現在のノード番号をデクリメントした後、該デクリメントした現在のノード番号を持つ配送定義情報（図９）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５４】
一方、ステップＳ５００５で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」であると判定した場合には、ステップＳ５００６において、ステップＳ５００４で取得した現在のノード番号をインクリメントした後、該インクリメントした現在のノード番号を持つ配送定義情報（図８）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５５】
そして、ステップＳ５００８において、ワークフローサーバ２００のＣＰＵは、ステップＳ５００３、Ｓ５００６、又はＳ５００７で取得した経路役割ＩＤ，経路組織ＩＤを用いて、ユーザ役職情報（図７）を参照して次の配送対象ユーザＩＤを決定する（役職テーブル（図７）から役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのユーザＩＤを決定する）。なお、取得した経路組織ＩＤが「ＮＵＬＬ」の場合（図８の空白の場合）には、現在のノード番号より１つ小さいノード番号に対応するユーザＩＤの属する組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとする。さらに、これでも次の配送対象ユーザＩＤを決定することができない場合（ユーザ役職情報（図７）に、役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのレコードが存在しない場合）には、該組織ＩＤの親組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとし、次の配送対象ユーザＩＤが決定するまでこの処理を繰り返すものとする。
【００５６】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図９に示したように、ステップＳ５００３で、ノード番号「１」の経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」が取得され、該取得された経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」に基づいて配送対象となるユーザＩＤが決定される。ここで、取得した経路組織ＩＤが「ＮＵＬＬ」であるため、現在のノード番号「１」より１つ小さいノード番号「０」に対応するユーザＩＤ「Ｕ００１２」の属する組織ＩＤ「８０１０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。このとき、ユーザ役職情報（図７）に、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のレコードが存在しないため、組織ＩＤ「８０１０１０１０１０」の親組織ＩＤ「８０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。ここで、ユーザ役職情報（図７）を参照すると、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のユーザＩＤは「Ｕ０００７」となり、このユーザＩＤ「Ｕ０００７」が次の配送対象ユーザＩＤに決定される。
【００５７】
次に、ステップＳ５００９において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであるか否かを判定する。
【００５８】
ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであると判定した場合には、ステップＳ５０１０において、配送情報テーブル（図９）から当該配送情報を削除するとともに、ＳＭＴＰサーバ２０４により起票者に全て承認された旨のワークフロー通知を行い、処理を終了する。
【００５９】
一方、ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものでないと判定した場合には、ステップＳ５０１１において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「起票」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップＳ５０１３において、配送情報テーブル（図９）から上記現在ノード番号を削除するとともに、ＳＭＴＰサーバ２０４により配送対象者に否認された旨のワークフロー通知を行い、処理を終了する。
【００６０】
一方、ステップＳ５０１１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「起票」であると判定した場合には、ステップＳ５０１２において、配送情報テーブル（図９）に次のノード番号の情報を設定（この時、「処理ユーザ」には、ステップＳ５００９で決定された次の配送対象ユーザＩＤを設定）するとともに、ＳＭＴＰサーバ２０４により配送対象者にワークフロー通知を行い、処理を終了する。
【００６１】
以下、図１１〜図１４を用いて本実施形態における分散ワークフローについて説明する。
【００６２】
図１１は、本発明のワークフローシステムの運用環境の一例を示すシステム構成図である。
【００６３】
図１１において、６００はサーバで、図１に示したワークフローサーバ２００に対応する。また、６２０はクライアントで、図１に示したワークフロー及び伝票設計用端末４００等に対応する。
【００６４】
サーバ６００は、Ｗｅｂサーバ６０１と複数のアプリケーションサーバ６０２，６０３で構成されている。アプリケーションサーバ１（６０２），アプリケーションサーバ２（６０３）は、サブシステムごとに起動がかけられ、ワークフローシステムのサーブレット１（６０４），サーブレット２（６０５）をそれぞれ別プロセスとして運用する。このように、本発明のワークフローシステムは、異なる複数のエンティティ（サーブレット）に分散されたワークフローシステムである。
【００６５】
アプリケーションサーバ１（６０２），アプリケーションサーバ２（６０３）は、データベースインスタンス１（６０６），データベースインスタンス２（６０７）をサーバ６００のメモリ上にそれぞれ生成する
なお、アプリケーションサーバ１（６０２）は、組織ＤＢ６０８，ユーザＤＢ６０９，経路ＤＢ６１０，役割ＤＢ６１１，伝票ＤＢ６１２の各テーブルを有するＤＢインスタンス１（６０６）を生成する。また、アプリケーションサーバ２（６０３）はアプリケーションサーバ１（６０２）と同様のテーブルを有するＤＢインスタンス２（６０７）をそれぞれ生成する。
【００６６】
本実施形態のシステム構成では、ＤＢインスタンス１（６０６）の組織ＤＢ（６０８）とユーザＤＢ（６０９）と役割ＤＢ（６１１）を本システムにおける共通データベースとして設定している。
【００６７】
サーブレット１（６０４）は、デフォルトの情報テーブルであるＤＢインスタンス１（６０６）にアクセスする。
【００６８】
サーブレット２（６０５）は、ユーザＤＢ（６０９）と組織ＤＢ（６０８）と役割ＤＢ（６１１）については共通データベースであるＤＢインスタンス１（６０６）をアクセスし、経路ＤＢ（６１５）、伝票ＤＢ（６１３）についてはデフォルトのＤＢインスタンス２（６０７）にアクセスする。なお、各サーブレットがアクセスするＤＢの情報は、サーバ６００のＨＤ等に記憶されている管理テーブルで記憶管理されている。
【００６９】
このように、本発明のシステムでは、ワークフローシステムで接続するデータベースの接続先をサブシステム（サーブレット）単位で指定可能とし、ワークフローシステムのシステム情報（組織情報，ユーザ情報，役割情報，伝票情報等）を、サブシステム間で部分共有可能としている。
【００７０】
なお、各アプリケーションサーバは、データベースへの接続のためのメモリキャッシュであるコネクションプーリングをサーバ６００のメモリ上にそれぞれ作成する。このコネクションプーリングにより、各アプリケーションサーバは、アプリケーション層で事前にデータベースへのコネクションを確保しておき、接続時の負荷を軽減している。また、各アプリケーションサーバは、データソースをサーバ６００上で起動されているネーミングサービス等に登録して、データベースの情報をサーバ６００のメモリ上にキャッシュする。このようにデータベースの処理を高速化している。
【００７１】
なお、アプリケーションサーバ１（６０２）とアプリケーションサーバ２（６０３）の切り替えは、クライアント６２０からアクセスするＵＲＬの切り替えにより実現される。
【００７２】
図１２は、本発明のワークフローシステムで運用されるワークフローサーバ６００の監視画面の一例を示す模式図である。なお、この監視画面は、クライアント６２０からサーバ６００にシステム管理者としてログインし、この監視画面を要求することにより、サーバ６００上で動作する管理プログラムから返信され、クライアント６２０のシステム管理プログラム４０２（図１）（Ｗｅｂブラウザ上等であってもよい）に表示される。
【００７３】
図１２において、７００は監視画面であり、この監視画面７００は、サーバ情報の一覧表示７０１と、データベースの接続情報一覧７０２とで構成されている。
【００７４】
サーバ情報一覧７０１は、ホスト名７０３と、サブシステムごとに起動をかけられたサーブレットの情報７０４の一覧を表示する。サーブレットの情報７０４は、サーブレット・パスを表示する。
【００７５】
なお、ここで示した例では、２つのサーバを生成し、ホスト名はともに"ＣＡＴ"（７０５，７０６）、サーブレット名称はサーブレットパスよりＷｅｂＪ（７０７）とＷｅｂＣ（７０８）であることがわかる。
【００７６】
なお、サーバ一覧７０１のラジオボタン７１９の切り替えにより、ＤＢ接続情報一覧７０２の表示が切り替わる。
【００７７】
ＤＢ接続情報一覧７０２は、組織ＤＢ，役割ＤＢ，経路ＤＢ，ユーザＤＢの各テーブル（組織テーブル７０９，役割テーブル７１０，経路テーブル７１１，ユーザテーブル７１２）へのログイン情報を表示する。なお、これらの情報は、サーバ６００のＨＤ等に記憶されている管理テーブルで記憶管理されている。
【００７８】
ログイン情報は、データベースへのログインＩＤ，パスワード，ホスト名，サーバ名称で構成される。
【００７９】
例えば、組織テーブル７０９のログイン情報７１３は、ログインＩＤが"Ｒｉｎｇｉ"、パスワードが"ｋａｎｎｏｎ"、ホスト名が"ｃａｔ"、サーバ名称が"ｗｅｂｊ"であり、それらを連結させてログイン情報"Ｒｉｎｇｉ／ｋａｎｎｏｎ／ｃａｔ／ｗｅｂｊ"としている。
【００８０】
また、７１４はサーバ追加ボタンで、サーバ一覧７０１にサーバを追加するためのものである。このサーバ追加ボタン７１４をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、サーバ一覧７０１の現在選択中のサーバの後に、新たなサーバ情報を追加制御する。図１２に示した例では、新たなサーバが、サーバ７０８の後に追加されることとなる。
【００８１】
７１５はサーバ修正ボタンで、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を変更するためのものである。このサーバ修正ボタン７１５をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を変更制御する。
【００８２】
７１６はサーバ削除ボタンで、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を削除するためのものである。このサーバ削除ボタン７１６をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を削除制御する。
【００８３】
７１７はＤＢ接続変更ボタンで、現在選択されているサーブレットに接続されているデータベース７０９〜７１２のログイン情報を変更するためのものである。このＤＢ接続変更ボタン７１７をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、現在選択されているサーブレットに接続されているデータベース７０９〜７１２のログイン情報を変更制御する。
【００８４】
７１８はテーブル内容変更ボタンで、現在選択されているサーバに接続されている組織テーブル７０９，役割テーブル７１０，経路テーブル７１１，ユーザテーブル７１２の各テーブルの内容を変更するためのものである。このテーブル内容変更ボタン７１８をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、現在選択されているサーバに接続されている組織テーブル７０９，役割テーブル７１０，経路テーブル７１１，ユーザテーブル７１２の各テーブルの内容を変更制御する。
【００８５】
なお、複数のサーブレットがアクセスすることを許可した共有データベース、例えば、組織テーブル７０９の内容変更を、ＷｅｂＪ（サーブレット１）を選択した状態で行った場合、通常、ＷｅｂＪ（サーブレット１）に割り当てられた組織テーブルのキャッシュは最新のものとなるが、ＷｅｂＣ（サーブレット２）に割り当てられた組織テーブルのキャッシュは旧情報のままである。
【００８６】
即ち、共有データベースの内容変更に対し、各サーブレットに割り当てられた当該データベースに対するキャッシュの内容がサーブレット間で不一致となり、キャッシュの一貫性が問題となる。この問題に対して、従来では、アプリケーションサーバを再起動して、各サーブレットに割り当てられた当該データベースに対するキャッシュの内容をサーブレット間で一致させるようにしていた。
【００８７】
本発明のワークフローシステムでは、共有データベース、例えば組織テーブル７０９の内容を変更した場合は、サーバ６００のＣＰＵが、変更時の選択サーブレットに割り当てられたキャッシュのリフレッシュのみならず、当該テーブルをキャッシュしている全てのサーブレットのキャッシュをリフレッシュするように制御している。
【００８８】
以下、図１３，図１４のフローチャートを参照して、本発明のワークフローシステムにおけるデータベーステーブル内容変更時のキャッシュリフレッシュ処理について説明する。
【００８９】
図１３は、本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートであり、データベーステーブル内容変更時のキャッシュリフレッシュ処理のメイン処理に対応する。なお、このフローチャートの処理は、図１１に示したサーバ６００のＣＰＵがＨＤ又はその他の記録媒体に格納されたプログラム（管理プログラム）をＲＡＭにロードして実行することにより実現されるものである。また、Ｓ８０１〜Ｓ８０３は各ステップを示す。
【００９０】
まず、サーバ６００のＣＰＵは、クライアント６２０から図１２に示したテーブル内容変更ボタン７１８がクライアント６２０の入力装置で押下指示されたことを示す通知を受信すると、本フローチャートの処理を開始する。
【００９１】
ステップＳ８０１において、サーバ６００のＣＰＵは、変更入力処理により、クライアント６２０からのテーブル内容の変更情報の入力を待機し、クライアント６２０からのテーブル内容の変更入力情報を受信すると、ステップＳ８０２において、ステップＳ８０１で入力された変更内容を、サーバ６００のＨＤ等に構築されている当該テーブルに書き込みテーブル内容を変更する。
【００９２】
そして、テーブルの内容が変更された後、ステップＳ８０３において、サーバ６００のＣＰＵは、各サーブレットに割り当てられている当該テーブルの全てのキャッシュをリフレッシュするキャッシュリフレッシュ処理を行い（詳細は図１４に示す）、本フローチャートの処理を終了する。
【００９３】
図１４は、本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートであり、図１３のステップＳ８０３に示したキャッシュリフレッシュ処理に対応する。なお、このフローチャートの処理は、図１１に示したサーバ６００のＣＰＵがＨＤ又はその他の記録媒体に格納されたプログラムをＲＡＭにロードして実行することにより実現されるものである。また、Ｓ９０１〜Ｓ９０６は各ステップを示す。
【００９４】
ステップＳ９０１において、サーバ６００のＣＰＵは、図１３のステップＳ８０２で内容変更したテーブル（当該テーブル）に接続されているサーブレット名称を１つ取得する。
【００９５】
次に、ステップＳ９０２において、サーバ６００のＣＰＵは、ステップＳ９０１で取得したサーブレット（当該サーブレット）の当該テーブルへのＤＢログイン情報（例えば、図１２の７１３）を、サーバ６００のＨＤ等に記憶されている管理テーブルから取得する。
【００９６】
次に、ステップＳ９０３において、サーバ６００のＣＰＵは、当該サーブレットのキャッシュメモリをサーバ６００のメモリ上から解放する。
【００９７】
次に、ステップＳ９０４において、サーバ６００のＣＰＵは、当該テーブルに接続するためのメモリキャッシュであるコネクションプーリングをサーバ６００のメモリ上に作成する。さらに、サーバ６００のＣＰＵは、当該テーブルのデータソースをサーバ６００上で起動されているネーミングサービス等に登録して、当該テーブルの情報をサーバ６００のメモリ上にキャッシュし、キャッシュリフレッシュを完了する。
【００９８】
次に、ステップＳ９０５において、サーバ６００のＣＰＵは、再び、当該テーブルに接続しているサーブレット名称（未処理のもの）の取得を試みる。そして、ステップＳ９０６において、サーバ６００のＣＰＵは、ステップＳ９０５でサーブレットが取得できたか否かを判定し、取得できた（まだキャッシュリフレッシュしていないサーブレットがあった）と判断した場合には、ステップＳ９０２に処理を戻し、次のサーブレットに対する処理を行う。
【００９９】
一方、ステップＳ９０６で、サーバ６００のＣＰＵが、ステップＳ９０５でサーブレットの取得ができなかった（もうキャッシュリフレッシュしていないサーブレットがなかった）と判断した場合には、本フローチャートの処理を終了する。即ち、当該テーブルに接続された全てのサーブレットについてキャッシュリフレッシュが完了するまでステップＳ９０２〜Ｓ９０５の処理を繰り返す。これにより、運用環境であるシステム情報（各テーブル）の更新時、アプリケーションサーバの再起動によるキャッシュリフレッシュではなく、各サーブレットの個別のキャッシュリフレッシュすることを可能にした。
【０１００】
以上示したように、ワークフローシステムのシステム情報（組織情報，ユーザ情報，役割情報，伝票情報等）を、サブシステム（サーブレット）間で部分共有可能とするため、ワークフローシステムで接続するデータベース（組織情報，ユーザ情報，役割情報，伝票情報等を格納）の接続先をサブシステム単位で指定可能とし（管理テーブルで管理）、運用環境であるシステム情報の更新時、アプリケーションサーバの再起動によるキャッシュリフレッシュではなく、各ワークフローサーバ（各サーブレット）の個別のキャッシュリフレッシュを可能にした。
【０１０１】
このように、複数アプリケーションサーバ，複数ワークフローの一括管理機能を実現したことで、例えば、人事関連，総務関連といったカテゴリごとに伝票情報，経路情報を独立して運用管理できるとともに、組織情報，役割情報等については共通情報として一括管理することを可能とした。これにより、各サブシステムにおける電子文書を含めた開発の効率向上、システム管理者の運用効率の向上を実現することができる。
【０１０２】
従って、大量の業務を抱える大規模組織におけるワークフローシステムの保守作業負荷の軽減を図ることができる。
【０１０３】
なお、上記実施形態内で示した各変形例のいずれか又は全てを組み合わせた構成も全て本発明に含まれるものである。
【０１０４】
また、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１０５】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１０６】
以下、図１５に示すメモリマップを参照して本発明に係るワークフローシステムを構成する各情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０１０７】
図１５は、本発明に係るワークフローシステムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【０１０８】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１０９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１１０】
本実施形態における図１０，図１３，図１４に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１１１】
以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１１２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１１３】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１１４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１７】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【図面の簡単な説明】
【０１１８】
【図１】本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【図２】図１に示したワークフローサーバ，ワークフロー操作用端末，ワークフロー及び伝票設計用端末に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【図３】図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【図４】図１に示したワークフローサーバのＲＤＢＭＳに記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。
【図５】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。
【図６】図１に示したワークフローサーバのＲＤＢＭＳに記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。
【図７】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。
【図８】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。
【図９】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。
【図１０】本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。
【図１１】本発明のワークフローシステムの運用環境の一例を示すシステム構成図である。
【図１２】本発明のワークフローシステムで運用されるワークフローサーバの監視画面の一例を示す模式図である。
【図１３】本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図１４】本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートである。
【図１５】本発明に係るワークフローシステムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【符号の説明】
【０１１９】
６００ サーバ
６０１ Ｗｅｂサーバ
６０２ アプリケーションサーバ１
６０３ アプリケーションサーバ２
６０４ ワークフローシステムサーブレット１
６０５ ワークフローシステムサーブレット２
６０６ ＤＢインスタンス１
６０７ ＤＢインスタンス２
６２０ クライアント
【技術分野】
【０００１】
本発明は、異なる複数のワークフローに分散され、前記各ワークフロー間でデータベースを共有するワークフローシステムおよびワークフローシステムの管理方法およびプログラムおよび記録媒体に関する。
【背景技術】
【０００２】
電子文書の承認業務の効率を向上させるインフラのひとつとして、ワークフローシステムがある。ワークフローシステムは、ワークフロー、組織、担当者といった対象が相互に依存しあったシステムを構成していることから、これらの対象の中のいずれかを変更しようとすると、他の対象も影響を受けざるおえないような変更を余儀なくされていた。
【０００３】
このため、ワークフローのカスタマイズは可能であるとしても、例えば、組織の変更といった対象の変更を行おうとした場合、組織に関連する対象も変更しなくてはならず、関連対象の検索等が複雑化し、簡単には対処できないという問題があった。
【０００４】
この問題に対し、特許文献１（特開２０００−２５０９６７号公報）は、ワークフロー管理機能と実行環境を分散化させることで、この問題を解決させようとした。
【０００５】
具体的には、ワークフロー制御サーバは、ワークフローを論理的な業務単位を形成するタスクと、入出力データと処理条件を含んだ階層構造の業務オブジェクトで構成し、この階層構造の各層の業務オブジェクト単位にワークフローの制御及び管理を行おうというものである。
【０００６】
組織や人の変更については、例えば、人の変更は、作業者と秘書エージェントの追加・削除を、組織の変更については、秘書エージェントの属性変更で対応する構成となっている。
【特許文献１】特開２０００−２５０９６７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記特許文献１では、組織・役割といったワークフロー共通のデータについても入出力データを業務オブジェクトに含んでいるため、組織変更等においては、各業務オブジェクトに含まれる組織情報データである秘書エージェントの属性をそれぞれ更新する必要があり、特に大量の業務を抱える大規模組織においては、システム管理者の保守作業負荷増大につながるといった問題があった。
【０００８】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、異なる複数のワークフローに分散された各ワークフロー間で共有するデータベースの内容を前記各ワークフローでそれぞれキャッシュし、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュすることにより、異なる複数のワークフローに分散されて稼動するワークフローシステムにおいて、各ワークフローにおけるデータベース処理の高速化と各ワークフローの一括管理による保守作業の軽減を実現し、大量の業務を抱える大規模組織におけるワークフローシステムのデータベース処理の高速化と保守作業負荷の軽減を図ることができるワークフローシステムおよびワークフローシステムの管理方法およびプログラムおよび記録媒体を提供することである。
【課題を解決するための手段】
【０００９】
本発明は、異なる複数のワークフローに分散されたワークフローシステムにおいて、該ワークフローシステムで用いる情報を管理するデータベースを前記各ワークフロー間で共有する共有手段と、前記データベースの内容を前記各ワークフローでそれぞれキャッシュするキャッシュ手段と、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュするリフレッシュ手段とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、異なる複数のワークフローに分散された各ワークフロー間で共有するデータベースの内容を前記各ワークフローでそれぞれキャッシュし、前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュすることにより、異なる複数のワークフローに分散されて稼動するワークフローシステムにおいて、各ワークフローにおけるデータベース処理の高速化と、データベースの変更時にも各ワークフローをリブートすることなく各ワークフロー間のキャッシュの一貫性を保証することができる等の効果を奏する。
【００１１】
従って、各ワークフローの一括管理を実現し、大量の業務を抱える大規模組織におけるワークフローシステムのデータベース処理の高速化と保守作業負荷の軽減を両立することができる。
【００１２】
例えば、人事関連，総務関連といったカテゴリごとに伝票情報，経路情報を管理者の管理負担を増大させることなく、また、データベース処理効率を落とすことなく、独立して運用管理できるとともに、組織情報，役割情報については共通情報として一括管理が可能となる。これにより、分散ワークフローの各サブシステムにおける電子文書を含めた開発の効率の向上，システム管理者の運用効率の向上を実現できる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して、本発明の詳細を説明する。
【００１４】
図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【００１５】
本実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末（ワークフロー及び伝票設計用端末）４００、業務を遂行する処理者（担当者）に対応して設けられたワークフロー操作用コンピュータ端末（ワークフロー操作用端末）３００、ワークフローを実行するための各種テーブル，各種プログラムを格納するワークフローサーバ２００を備えている。
【００１６】
これらワークフロー及び伝票設計用端末４００，ワークフロー操作用端末３００，ワークフローサーバ２００は、それぞれネットワーク５００に接続され運用されている。
【００１７】
ワークフロー及び伝票設計用端末４００は、伝票デザイナプログラム４０１及びシステム管理プログラム４０２を有し、ワークフローサーバ２００上の図示しない管理プログラムと通信して、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末４００は、ワークフローサーバ２００に組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，各種伝票情報等を登録することができる。このワークフロー及び伝票設計用端末４００は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ２００に接続することが可能になる。
【００１８】
ワークフロー操作用端末３００は、ワークフロー操作用端末３００上で実行されるＷｅｂブラウザ３０１を用いて、伝票に関するアクセス情報をワークフローサーバ２００に対してＨＴＴＰで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Ｊａｖａ（登録商標）アプレット３０２等を利用することにより実行する。なお、このワークフロー操作用端末３００は、予め指定された所定の業務を行う担当者（例えば、起票者、課長、部長等）に配置されている。
【００１９】
ワークフローサーバ２００は、ワークフローシステムに関する情報（組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，配送情報テーブル等）を格納するＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａＳｅ Ｍａｎａｇｅｍｅｎｔ ＳｙＳｔｅｍ）２０５、ワークフロー操作用コンピュータ端末よりの要求を受け付けて要求を実行するためのＷＥＢサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３、ワークフロー通知機能を実現するＳＭＴＰサーバ２０４にて構成されている。
【００２０】
なお、ワークフロー操作用端末３００は、ワークフローサーバ２００に対して、伝票検索要求を送信し、ワークフローサーバ２００から返信される検索結果に基づいて、外部ＤＢに格納された決裁済みの伝票（電子文書）を閲覧可能である。
【００２１】
以下、図２を参照して、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成について説明する。
【００２２】
図２は、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【００２３】
図２において、１０１はＣＰＵで、ＲＯＭ１０３又はハードディスク（ＨＤ）（その他の記憶装置、例えば、フレキシブルディスク，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等どのような記憶装置であってもよい）１０４に格納されたプログラムをＲＡＭ１０２上にロードして実行することにより、コンピュータ全体を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。
【００２４】
１０７は通信インタフェースで、ネットワーク５００への接続を可能とする。１０５は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。１０６は表示装置で、ＣＲＴ，ＬＣＤ等で構成される。
【００２５】
なお、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５は、ワークフローサーバ２００のＨＤ１０４内に構築されている。また、ワークフローサーバ２００のＷＥＢサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３，ＳＭＴＰサーバ２０４は、ワークフローサーバ２００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２６】
また、図１に示したワークフロー操作用端末３００のＷｅｂブラウザ３０１は、ワークフロー操作用端末３００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２７】
さらに、図１に示したワークフロー操作用端末３００のＪａｖａ（登録商標）アプレット３０２は、ワークフロー操作用端末３００のＣＰＵ１０１が、ワークフローサーバ２００よりダウンロードされたプログラムをＷｅｂブラウザ３０１上で実行することにより、実現される。
【００２８】
また、図１に示したワークフロー及び伝票設計用端末４００の伝票デザイナプログラム４０１，システム管理プログラム４０２は、ワークフロー及び伝票設計用端末４００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２９】
図３は、図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【００３０】
本実施形態のワークフローシステムでは、ワークフロー操作用端末３００を用いて、図３に示すように、伝票の起票，伝票の承認／否認の手続きを、ノードと呼ばれる組織と役割で定義された担当者が行う。なお、伝票が配送されるノードをひとつに括ったものをビジネスプロセスと定義する。
【００３１】
図４は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。なお、この組織テーブルは、ワークフローを実現するための組織に関する情報を記憶するためのものである。
【００３２】
図４に示す組織テーブルにおいて、組織ＩＤは、任意の組織名をコードとして表記したものであり、常に上位組織ＩＤを網羅している。また、組織名は、組織ＩＤの表示上の名称を示したものである。さらに、親組織ＩＤは、上位の組織ＩＤを示したものである。
【００３３】
図５は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。なお、この役割テーブルは、ワークフローを実現するための役割に関する情報を記憶するためのものである。
【００３４】
図５に示す役割テーブルにおいて、役割ＩＤは、任意の役割名をコードとして表記したものである。また、役割名は、役割ＩＤの表示上の名称を示したものである。
【００３５】
図６は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。なお、このユーザテーブルは、ワークフローを利用するためのユーザの情報を記憶するためのものである。
【００３６】
図６に示すユーザテーブルにおいて、ユーザＩＤは、利用者を任意のコードとして表示したものである。また、パスワードは、ワークフローシステムにログインする際にユーザＩＤと共に認証に利用するためのものである。さらに、ユーザ名は、ユーザＩＤの表示上の名称を示したものである。
【００３７】
図７は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。なお、この役職テーブルは、ワークフローを利用するための役職の情報を記憶するためのものである。
【００３８】
図７に示すように、役職テーブルの各レコードは、ユーザテーブル内で定義されている「ユーザＩＤ」，役割テーブル内で定義されている「役割ＩＤ」，組織テーブル内で定義されている「組織ＩＤ」で構成されている。
【００３９】
図８は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。なお、この配送定義情報は、伝票が配送される経路を定義した情報を記憶するためのものである。
【００４０】
ここでは、一例として役割が「社員」→「部長」→「本部長」→「事業本部長」→「社長」の順に伝票配送をする例を示している。このように伝票の配送経路を定義した場合、この配送経路の配送定義情報は、図８に示すような５レコードの情報として作成される。
【００４１】
以下、配送定義情報の作成方法について説明する。
【００４２】
例えば、伝票名が「交通費」の場合、まず、ユーザがワークフロー及び伝票設計用端末４００から、システム管理プログラムを用いて、伝票名に「交通費」と設定し、次に、各ノードを設定する。ノード１を例にすると、ノード１に役割ＩＤに部長を示すコード「Ｕ０００７」を設定し、対象となる組織を選択（ここでは組織ＩＤ「８０」の「Ａ会社」を選択）することにより、「伝票名」が「交通費」，「組織ＩＤ」が「８０」，「ノード番号」が「１」，「経路役割ＩＤ」が「部長」を示す役割ＩＤ「００４」、「経路組織ＩＤ」が役割を担う組織ＩＤとして設定される。なお、ここでは、対象となる組織として、組織ＩＤ「８０」の「Ａ会社」が選択されており、役割ＩＤ「部長」を持つ配送対象者は決定されない。そのため、経路組織ＩＤは「ＮＵＬＬ」となっている（図中では空白で示している）。
【００４３】
図９は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。なお、この配送情報テーブルは、後述する図１０に示すワークフローシステムにおける配送処理時に図８に示した配送定義情報に基づいて生成されるものであり、ワークフローの経路，状態等を記憶するためのものである。また、この配送情報テーブルは、特に、ユーザＩＤ「Ｕ００１２」のユーザが起票した場合に対応する。この場合、伝票は、ユーザＩＤ「Ｕ００１２」，「Ｕ０００７」，「Ｕ０００３」，「Ｕ０００２」，「Ｕ０００１」のように配送されることとなる。
【００４４】
以下、図１０を参照して、本発明のワークフローシステムにおける配送処理手順の全体の流れについて説明する。
【００４５】
図１０は、本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０３による配送処理に対応する。なお、図中、Ｓ５０００〜Ｓ５０１３は各ステップを示す。
【００４６】
まず、ワークフロープログラム２０３を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）が、ワークフロー操作用端末３００より伝票処理要求を受信すると（ステップＳ５０００）、配送処理を開始する。
【００４７】
ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分である「起票」，「承認」，「否認」に基づいて、配送処理を切り替えていく（ステップＳ５００１）。
【００４８】
ステップＳ５００１において、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「起票」であると判定した場合には、ステップＳ５００２において、ワークフローサーバ２００のＣＰＵは、起票時の情報として、ノード番号「０」を配送情報テーブルに設定する。「処理ユーザ」には、起票したユーザのユーザＩＤを設定する。
【００４９】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図８に示したように、配送情報テーブルのノード番号「０」のレコードに、伝票名に「交通費」、伝票番号を起票時に発行される伝票番号（ここでは「００００１」とする）、ノード番号に「０」、処理ユーザを起票ユーザのユーザＩＤ「Ｕ００１２」、状態に「処理済」を設定する。
【００５０】
次に、ステップＳ５００３において、ワークフローサーバ２００のＣＰＵは、現在のノード番号を「１」とし、ステップＳ５０００で受信した伝票処理要求の伝票名に対応する配送定義情報（図８）を参照し、ノード番号「１」の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５１】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」を取得する。
【００５２】
一方、ステップＳ５００１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「否認」であると判定した場合には、ステップＳ５００４において、ワークフローサーバ２００のＣＰＵは、配送情報テーブル（図９）を参照して現在のノード番号を取得する。
【００５３】
次に、ステップＳ５００５において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップＳ５００７において、ステップＳ５００４で取得した現在のノード番号をデクリメントした後、該デクリメントした現在のノード番号を持つ配送定義情報（図９）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５４】
一方、ステップＳ５００５で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」であると判定した場合には、ステップＳ５００６において、ステップＳ５００４で取得した現在のノード番号をインクリメントした後、該インクリメントした現在のノード番号を持つ配送定義情報（図８）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５５】
そして、ステップＳ５００８において、ワークフローサーバ２００のＣＰＵは、ステップＳ５００３、Ｓ５００６、又はＳ５００７で取得した経路役割ＩＤ，経路組織ＩＤを用いて、ユーザ役職情報（図７）を参照して次の配送対象ユーザＩＤを決定する（役職テーブル（図７）から役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのユーザＩＤを決定する）。なお、取得した経路組織ＩＤが「ＮＵＬＬ」の場合（図８の空白の場合）には、現在のノード番号より１つ小さいノード番号に対応するユーザＩＤの属する組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとする。さらに、これでも次の配送対象ユーザＩＤを決定することができない場合（ユーザ役職情報（図７）に、役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのレコードが存在しない場合）には、該組織ＩＤの親組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとし、次の配送対象ユーザＩＤが決定するまでこの処理を繰り返すものとする。
【００５６】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図９に示したように、ステップＳ５００３で、ノード番号「１」の経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」が取得され、該取得された経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」に基づいて配送対象となるユーザＩＤが決定される。ここで、取得した経路組織ＩＤが「ＮＵＬＬ」であるため、現在のノード番号「１」より１つ小さいノード番号「０」に対応するユーザＩＤ「Ｕ００１２」の属する組織ＩＤ「８０１０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。このとき、ユーザ役職情報（図７）に、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のレコードが存在しないため、組織ＩＤ「８０１０１０１０１０」の親組織ＩＤ「８０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。ここで、ユーザ役職情報（図７）を参照すると、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のユーザＩＤは「Ｕ０００７」となり、このユーザＩＤ「Ｕ０００７」が次の配送対象ユーザＩＤに決定される。
【００５７】
次に、ステップＳ５００９において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであるか否かを判定する。
【００５８】
ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであると判定した場合には、ステップＳ５０１０において、配送情報テーブル（図９）から当該配送情報を削除するとともに、ＳＭＴＰサーバ２０４により起票者に全て承認された旨のワークフロー通知を行い、処理を終了する。
【００５９】
一方、ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものでないと判定した場合には、ステップＳ５０１１において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「起票」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップＳ５０１３において、配送情報テーブル（図９）から上記現在ノード番号を削除するとともに、ＳＭＴＰサーバ２０４により配送対象者に否認された旨のワークフロー通知を行い、処理を終了する。
【００６０】
一方、ステップＳ５０１１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「起票」であると判定した場合には、ステップＳ５０１２において、配送情報テーブル（図９）に次のノード番号の情報を設定（この時、「処理ユーザ」には、ステップＳ５００９で決定された次の配送対象ユーザＩＤを設定）するとともに、ＳＭＴＰサーバ２０４により配送対象者にワークフロー通知を行い、処理を終了する。
【００６１】
以下、図１１〜図１４を用いて本実施形態における分散ワークフローについて説明する。
【００６２】
図１１は、本発明のワークフローシステムの運用環境の一例を示すシステム構成図である。
【００６３】
図１１において、６００はサーバで、図１に示したワークフローサーバ２００に対応する。また、６２０はクライアントで、図１に示したワークフロー及び伝票設計用端末４００等に対応する。
【００６４】
サーバ６００は、Ｗｅｂサーバ６０１と複数のアプリケーションサーバ６０２，６０３で構成されている。アプリケーションサーバ１（６０２），アプリケーションサーバ２（６０３）は、サブシステムごとに起動がかけられ、ワークフローシステムのサーブレット１（６０４），サーブレット２（６０５）をそれぞれ別プロセスとして運用する。このように、本発明のワークフローシステムは、異なる複数のエンティティ（サーブレット）に分散されたワークフローシステムである。
【００６５】
アプリケーションサーバ１（６０２），アプリケーションサーバ２（６０３）は、データベースインスタンス１（６０６），データベースインスタンス２（６０７）をサーバ６００のメモリ上にそれぞれ生成する
なお、アプリケーションサーバ１（６０２）は、組織ＤＢ６０８，ユーザＤＢ６０９，経路ＤＢ６１０，役割ＤＢ６１１，伝票ＤＢ６１２の各テーブルを有するＤＢインスタンス１（６０６）を生成する。また、アプリケーションサーバ２（６０３）はアプリケーションサーバ１（６０２）と同様のテーブルを有するＤＢインスタンス２（６０７）をそれぞれ生成する。
【００６６】
本実施形態のシステム構成では、ＤＢインスタンス１（６０６）の組織ＤＢ（６０８）とユーザＤＢ（６０９）と役割ＤＢ（６１１）を本システムにおける共通データベースとして設定している。
【００６７】
サーブレット１（６０４）は、デフォルトの情報テーブルであるＤＢインスタンス１（６０６）にアクセスする。
【００６８】
サーブレット２（６０５）は、ユーザＤＢ（６０９）と組織ＤＢ（６０８）と役割ＤＢ（６１１）については共通データベースであるＤＢインスタンス１（６０６）をアクセスし、経路ＤＢ（６１５）、伝票ＤＢ（６１３）についてはデフォルトのＤＢインスタンス２（６０７）にアクセスする。なお、各サーブレットがアクセスするＤＢの情報は、サーバ６００のＨＤ等に記憶されている管理テーブルで記憶管理されている。
【００６９】
このように、本発明のシステムでは、ワークフローシステムで接続するデータベースの接続先をサブシステム（サーブレット）単位で指定可能とし、ワークフローシステムのシステム情報（組織情報，ユーザ情報，役割情報，伝票情報等）を、サブシステム間で部分共有可能としている。
【００７０】
なお、各アプリケーションサーバは、データベースへの接続のためのメモリキャッシュであるコネクションプーリングをサーバ６００のメモリ上にそれぞれ作成する。このコネクションプーリングにより、各アプリケーションサーバは、アプリケーション層で事前にデータベースへのコネクションを確保しておき、接続時の負荷を軽減している。また、各アプリケーションサーバは、データソースをサーバ６００上で起動されているネーミングサービス等に登録して、データベースの情報をサーバ６００のメモリ上にキャッシュする。このようにデータベースの処理を高速化している。
【００７１】
なお、アプリケーションサーバ１（６０２）とアプリケーションサーバ２（６０３）の切り替えは、クライアント６２０からアクセスするＵＲＬの切り替えにより実現される。
【００７２】
図１２は、本発明のワークフローシステムで運用されるワークフローサーバ６００の監視画面の一例を示す模式図である。なお、この監視画面は、クライアント６２０からサーバ６００にシステム管理者としてログインし、この監視画面を要求することにより、サーバ６００上で動作する管理プログラムから返信され、クライアント６２０のシステム管理プログラム４０２（図１）（Ｗｅｂブラウザ上等であってもよい）に表示される。
【００７３】
図１２において、７００は監視画面であり、この監視画面７００は、サーバ情報の一覧表示７０１と、データベースの接続情報一覧７０２とで構成されている。
【００７４】
サーバ情報一覧７０１は、ホスト名７０３と、サブシステムごとに起動をかけられたサーブレットの情報７０４の一覧を表示する。サーブレットの情報７０４は、サーブレット・パスを表示する。
【００７５】
なお、ここで示した例では、２つのサーバを生成し、ホスト名はともに"ＣＡＴ"（７０５，７０６）、サーブレット名称はサーブレットパスよりＷｅｂＪ（７０７）とＷｅｂＣ（７０８）であることがわかる。
【００７６】
なお、サーバ一覧７０１のラジオボタン７１９の切り替えにより、ＤＢ接続情報一覧７０２の表示が切り替わる。
【００７７】
ＤＢ接続情報一覧７０２は、組織ＤＢ，役割ＤＢ，経路ＤＢ，ユーザＤＢの各テーブル（組織テーブル７０９，役割テーブル７１０，経路テーブル７１１，ユーザテーブル７１２）へのログイン情報を表示する。なお、これらの情報は、サーバ６００のＨＤ等に記憶されている管理テーブルで記憶管理されている。
【００７８】
ログイン情報は、データベースへのログインＩＤ，パスワード，ホスト名，サーバ名称で構成される。
【００７９】
例えば、組織テーブル７０９のログイン情報７１３は、ログインＩＤが"Ｒｉｎｇｉ"、パスワードが"ｋａｎｎｏｎ"、ホスト名が"ｃａｔ"、サーバ名称が"ｗｅｂｊ"であり、それらを連結させてログイン情報"Ｒｉｎｇｉ／ｋａｎｎｏｎ／ｃａｔ／ｗｅｂｊ"としている。
【００８０】
また、７１４はサーバ追加ボタンで、サーバ一覧７０１にサーバを追加するためのものである。このサーバ追加ボタン７１４をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、サーバ一覧７０１の現在選択中のサーバの後に、新たなサーバ情報を追加制御する。図１２に示した例では、新たなサーバが、サーバ７０８の後に追加されることとなる。
【００８１】
７１５はサーバ修正ボタンで、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を変更するためのものである。このサーバ修正ボタン７１５をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を変更制御する。
【００８２】
７１６はサーバ削除ボタンで、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を削除するためのものである。このサーバ削除ボタン７１６をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、サーバ一覧７０１のラジオボタン７１９で選択されているサーバ情報を削除制御する。
【００８３】
７１７はＤＢ接続変更ボタンで、現在選択されているサーブレットに接続されているデータベース７０９〜７１２のログイン情報を変更するためのものである。このＤＢ接続変更ボタン７１７をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、現在選択されているサーブレットに接続されているデータベース７０９〜７１２のログイン情報を変更制御する。
【００８４】
７１８はテーブル内容変更ボタンで、現在選択されているサーバに接続されている組織テーブル７０９，役割テーブル７１０，経路テーブル７１１，ユーザテーブル７１２の各テーブルの内容を変更するためのものである。このテーブル内容変更ボタン７１８をクライアント６２０の入力装置で押下指示すると、クライアント６２０からその旨の通知がサーバ６００に送信される。この通知を受信したサーバ６００では、現在選択されているサーバに接続されている組織テーブル７０９，役割テーブル７１０，経路テーブル７１１，ユーザテーブル７１２の各テーブルの内容を変更制御する。
【００８５】
なお、複数のサーブレットがアクセスすることを許可した共有データベース、例えば、組織テーブル７０９の内容変更を、ＷｅｂＪ（サーブレット１）を選択した状態で行った場合、通常、ＷｅｂＪ（サーブレット１）に割り当てられた組織テーブルのキャッシュは最新のものとなるが、ＷｅｂＣ（サーブレット２）に割り当てられた組織テーブルのキャッシュは旧情報のままである。
【００８６】
即ち、共有データベースの内容変更に対し、各サーブレットに割り当てられた当該データベースに対するキャッシュの内容がサーブレット間で不一致となり、キャッシュの一貫性が問題となる。この問題に対して、従来では、アプリケーションサーバを再起動して、各サーブレットに割り当てられた当該データベースに対するキャッシュの内容をサーブレット間で一致させるようにしていた。
【００８７】
本発明のワークフローシステムでは、共有データベース、例えば組織テーブル７０９の内容を変更した場合は、サーバ６００のＣＰＵが、変更時の選択サーブレットに割り当てられたキャッシュのリフレッシュのみならず、当該テーブルをキャッシュしている全てのサーブレットのキャッシュをリフレッシュするように制御している。
【００８８】
以下、図１３，図１４のフローチャートを参照して、本発明のワークフローシステムにおけるデータベーステーブル内容変更時のキャッシュリフレッシュ処理について説明する。
【００８９】
図１３は、本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートであり、データベーステーブル内容変更時のキャッシュリフレッシュ処理のメイン処理に対応する。なお、このフローチャートの処理は、図１１に示したサーバ６００のＣＰＵがＨＤ又はその他の記録媒体に格納されたプログラム（管理プログラム）をＲＡＭにロードして実行することにより実現されるものである。また、Ｓ８０１〜Ｓ８０３は各ステップを示す。
【００９０】
まず、サーバ６００のＣＰＵは、クライアント６２０から図１２に示したテーブル内容変更ボタン７１８がクライアント６２０の入力装置で押下指示されたことを示す通知を受信すると、本フローチャートの処理を開始する。
【００９１】
ステップＳ８０１において、サーバ６００のＣＰＵは、変更入力処理により、クライアント６２０からのテーブル内容の変更情報の入力を待機し、クライアント６２０からのテーブル内容の変更入力情報を受信すると、ステップＳ８０２において、ステップＳ８０１で入力された変更内容を、サーバ６００のＨＤ等に構築されている当該テーブルに書き込みテーブル内容を変更する。
【００９２】
そして、テーブルの内容が変更された後、ステップＳ８０３において、サーバ６００のＣＰＵは、各サーブレットに割り当てられている当該テーブルの全てのキャッシュをリフレッシュするキャッシュリフレッシュ処理を行い（詳細は図１４に示す）、本フローチャートの処理を終了する。
【００９３】
図１４は、本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートであり、図１３のステップＳ８０３に示したキャッシュリフレッシュ処理に対応する。なお、このフローチャートの処理は、図１１に示したサーバ６００のＣＰＵがＨＤ又はその他の記録媒体に格納されたプログラムをＲＡＭにロードして実行することにより実現されるものである。また、Ｓ９０１〜Ｓ９０６は各ステップを示す。
【００９４】
ステップＳ９０１において、サーバ６００のＣＰＵは、図１３のステップＳ８０２で内容変更したテーブル（当該テーブル）に接続されているサーブレット名称を１つ取得する。
【００９５】
次に、ステップＳ９０２において、サーバ６００のＣＰＵは、ステップＳ９０１で取得したサーブレット（当該サーブレット）の当該テーブルへのＤＢログイン情報（例えば、図１２の７１３）を、サーバ６００のＨＤ等に記憶されている管理テーブルから取得する。
【００９６】
次に、ステップＳ９０３において、サーバ６００のＣＰＵは、当該サーブレットのキャッシュメモリをサーバ６００のメモリ上から解放する。
【００９７】
次に、ステップＳ９０４において、サーバ６００のＣＰＵは、当該テーブルに接続するためのメモリキャッシュであるコネクションプーリングをサーバ６００のメモリ上に作成する。さらに、サーバ６００のＣＰＵは、当該テーブルのデータソースをサーバ６００上で起動されているネーミングサービス等に登録して、当該テーブルの情報をサーバ６００のメモリ上にキャッシュし、キャッシュリフレッシュを完了する。
【００９８】
次に、ステップＳ９０５において、サーバ６００のＣＰＵは、再び、当該テーブルに接続しているサーブレット名称（未処理のもの）の取得を試みる。そして、ステップＳ９０６において、サーバ６００のＣＰＵは、ステップＳ９０５でサーブレットが取得できたか否かを判定し、取得できた（まだキャッシュリフレッシュしていないサーブレットがあった）と判断した場合には、ステップＳ９０２に処理を戻し、次のサーブレットに対する処理を行う。
【００９９】
一方、ステップＳ９０６で、サーバ６００のＣＰＵが、ステップＳ９０５でサーブレットの取得ができなかった（もうキャッシュリフレッシュしていないサーブレットがなかった）と判断した場合には、本フローチャートの処理を終了する。即ち、当該テーブルに接続された全てのサーブレットについてキャッシュリフレッシュが完了するまでステップＳ９０２〜Ｓ９０５の処理を繰り返す。これにより、運用環境であるシステム情報（各テーブル）の更新時、アプリケーションサーバの再起動によるキャッシュリフレッシュではなく、各サーブレットの個別のキャッシュリフレッシュすることを可能にした。
【０１００】
以上示したように、ワークフローシステムのシステム情報（組織情報，ユーザ情報，役割情報，伝票情報等）を、サブシステム（サーブレット）間で部分共有可能とするため、ワークフローシステムで接続するデータベース（組織情報，ユーザ情報，役割情報，伝票情報等を格納）の接続先をサブシステム単位で指定可能とし（管理テーブルで管理）、運用環境であるシステム情報の更新時、アプリケーションサーバの再起動によるキャッシュリフレッシュではなく、各ワークフローサーバ（各サーブレット）の個別のキャッシュリフレッシュを可能にした。
【０１０１】
このように、複数アプリケーションサーバ，複数ワークフローの一括管理機能を実現したことで、例えば、人事関連，総務関連といったカテゴリごとに伝票情報，経路情報を独立して運用管理できるとともに、組織情報，役割情報等については共通情報として一括管理することを可能とした。これにより、各サブシステムにおける電子文書を含めた開発の効率向上、システム管理者の運用効率の向上を実現することができる。
【０１０２】
従って、大量の業務を抱える大規模組織におけるワークフローシステムの保守作業負荷の軽減を図ることができる。
【０１０３】
なお、上記実施形態内で示した各変形例のいずれか又は全てを組み合わせた構成も全て本発明に含まれるものである。
【０１０４】
また、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１０５】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１０６】
以下、図１５に示すメモリマップを参照して本発明に係るワークフローシステムを構成する各情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０１０７】
図１５は、本発明に係るワークフローシステムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【０１０８】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１０９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１１０】
本実施形態における図１０，図１３，図１４に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１１１】
以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１１２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１１３】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１１４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１７】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【図面の簡単な説明】
【０１１８】
【図１】本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【図２】図１に示したワークフローサーバ，ワークフロー操作用端末，ワークフロー及び伝票設計用端末に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【図３】図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【図４】図１に示したワークフローサーバのＲＤＢＭＳに記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。
【図５】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。
【図６】図１に示したワークフローサーバのＲＤＢＭＳに記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。
【図７】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。
【図８】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。
【図９】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。
【図１０】本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。
【図１１】本発明のワークフローシステムの運用環境の一例を示すシステム構成図である。
【図１２】本発明のワークフローシステムで運用されるワークフローサーバの監視画面の一例を示す模式図である。
【図１３】本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図１４】本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートである。
【図１５】本発明に係るワークフローシステムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【符号の説明】
【０１１９】
６００ サーバ
６０１ Ｗｅｂサーバ
６０２ アプリケーションサーバ１
６０３ アプリケーションサーバ２
６０４ ワークフローシステムサーブレット１
６０５ ワークフローシステムサーブレット２
６０６ ＤＢインスタンス１
６０７ ＤＢインスタンス２
６２０ クライアント
【特許請求の範囲】
【請求項１】
異なる複数のワークフローに分散されたワークフローシステムにおいて、
該ワークフローシステムで用いる情報を管理するデータベースを前記各ワークフロー間で共有する共有手段と、
前記データベースの内容を前記各ワークフローでそれぞれキャッシュするキャッシュ手段と、
前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュするリフレッシュ手段と、
を有することを特徴とするワークフローシステム。
【請求項２】
異なる複数のワークフローに分散され、前記各ワークフロー間でデータベースを共有するワークフローシステムの管理方法において、
前記データベースの内容を前記各ワークフローでそれぞれキャッシュするキャッシュステップと、
前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュするリフレッシュステップと、
を有することを特徴とするワークフローシステムの管理方法。
【請求項３】
請求項２に記載されたワークフローシステムの管理方法をコンピュータが実行するためのプログラム。
【請求項４】
請求項２に記載されたワークフローシステムの管理方法をコンピュータが実行するためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。
【請求項１】
異なる複数のワークフローに分散されたワークフローシステムにおいて、
該ワークフローシステムで用いる情報を管理するデータベースを前記各ワークフロー間で共有する共有手段と、
前記データベースの内容を前記各ワークフローでそれぞれキャッシュするキャッシュ手段と、
前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュするリフレッシュ手段と、
を有することを特徴とするワークフローシステム。
【請求項２】
異なる複数のワークフローに分散され、前記各ワークフロー間でデータベースを共有するワークフローシステムの管理方法において、
前記データベースの内容を前記各ワークフローでそれぞれキャッシュするキャッシュステップと、
前記データベースの内容が変更されたとき、当該データベースに関連した各ワークフローのキャッシュをそれぞれリフレッシュするリフレッシュステップと、
を有することを特徴とするワークフローシステムの管理方法。
【請求項３】
請求項２に記載されたワークフローシステムの管理方法をコンピュータが実行するためのプログラム。
【請求項４】
請求項２に記載されたワークフローシステムの管理方法をコンピュータが実行するためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００６−１８５１１７（Ｐ２００６−１８５１１７Ａ）
【公開日】平成１８年７月１３日（２００６．７．１３）
【国際特許分類】
【出願番号】特願２００４−３７７２７９（Ｐ２００４−３７７２７９）
【出願日】平成１６年１２月２７日（２００４．１２．２７）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【Ｆターム（参考）】
【公開日】平成１８年７月１３日（２００６．７．１３）
【国際特許分類】
【出願日】平成１６年１２月２７日（２００４．１２．２７）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【Ｆターム（参考）】
[ Back to top ]