JP4006167B2 - ワークフロー管理システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ある決められた順序をもって業務の担当または複数の担当に対して業務を順次に送り、業務の通知を受けた担当のうち１人だけが業務を遂行できるワークフロー管理システムに係り、特に電子掲示板システムを有するグループウェアを有効利用したワークフロー管理システムに関する。
【０００２】
【従来の技術】
一般にワークフロー管理システムは、稟議書や交通費精算書など、予め決まった順番で回覧され、承認や否認を受けていく書類の流れを電子化して管理するようにしたものである。そこでワークフロー管理システムでは、ある決められた順序をもって業務の担当（業務を実行する実行者）または複数の担当（実行者の候補）に対して業務を順次送り、業務の通知を受けた担当のうち１人だけが業務を遂行できるようになっている。つまり、ワークフロー管理システムには、業務を実行する実行者の候補（実行候補者）に対してメール（電子メール）などで連絡し、実行候補者のうちのいずれか１人が業務を開始すると、他の実行候補者はその業務を実行しなくてもよい（実行できない）排他制御の機構がある。
【０００３】
一方、ワークフロー管理システムと連携使用されるものにグループウェアと呼ばれるソフトウェアがある。グループウェアは、グループ内の各ユーザの知的な作業を支援するもので、ユーザ間のコミュニケーションや情報の共有を実現することで、グループによる作業の効率化を図ることに特徴がある。
【０００４】
グループウェアは、１対１の連絡の通信手法であるメール（電子メール）、または情報を蓄積する掲示板（電子掲示板）機能が基本である。このため、グループウェアと連携したワークフロー管理システムでは、実行者の候補全てに通知を出し、１人の実行者が排他的に業務を実行することはできない。特に、多くのグループウェアでは、レプリケーションなどと呼ばれる、複数のサーバマシン間でデータの交換を行う形態、即ち複数のサーバマシンでデータの複製を保存する形態もあるため、排他制御は困難になっている。
【０００５】
このように、グループウェアと連携したワークフロー管理システムでは、たとえグループウェアの背後でワークフロー管理システムを動作させて、ワークフロー処理を実行しても、１人の実行者が排他的に業務（タスク）を実行することはできなかった。
【０００６】
【発明が解決しようとする課題】
さて、ワークフロー管理システムとグループウェアとを連携するには、連携用のエージェントシステムが用いられる。このエージェントシステムは、ワークフロー管理システムで作業が実行可能となったとき、その作業を実行する作業者を選び、その作業者が作業を開始したことにして、その後にグループウェアの電子メール機能を使って作業者に通知するのが一般的であった。
【０００７】
このように従来は、エージェントシステムが自動的に実行者を決めてしまうため、実質上、１つのワークフローの作業には候補として１人しか割り当てられなかった。
【０００８】
また、たとえ複数の候補者にワークフローの作業を割り当てても、各候補者は自身だけが当該作業を実行しているのか、或いは他の候補者が既に作業を実行しているのかを確認するために、一旦グループウェアサーバマシン内のエージェントシステムが処理し、画面を読み出し直さなければならないなど、利用者の操作が必要になるという問題があった。
【０００９】
本発明は上記事情を考慮してなされたものでその目的は、ワークフローの処理（タスク）が実行可能な状態となった場合に、そのタスクの実行候補者全員に通知を出し、自身で実行すると決めた候補者のうちのただ１人が当該タスクを実行することができるワークフロー管理システムを提供することにある。
【００１０】
【課題を解決するための手段】
本発明は、ワークフロー中の処理可能となったタスクの実行候補者として登録されたグループウェアの複数の利用者の各々に当該タスクを通知するエージェントシステムと、このエージェントシステムにより通知されたタスクの処理開始を利用者操作に応じて宣言するためのタスク処理開始宣言手段と、このタスク処理開始宣言手段によるタスク処理開始宣言を受けて、該当する利用者が当該タスク処理を実行可能か否かを確認することを、グループウェア管理用のグループウェアサーバマシン側に依頼するタスク処理実行可否確認依頼手段と、このタスク処理実行可否確認依頼手段による依頼に応じて、上記ワークフローを管理するワークフローサーバマシンと通信することにより、該当する利用者によるタスク処理が実行可能か否かを排他的に確認して、その確認結果を利用者側に通知する、グループウェアサーバマシンに設けられたタスク処理実行可否確認手段とを備えたことを特徴とする。
【００１１】
このような構成において、エージェントシステムはタスクの実行者を決めずに、実行候補者全員に処理可能となったタスクを通知する。このタスク通知を受けた各利用者（実行候補者）の操作に応じてタスク処理開始が宣言されると、当該候補者によるタスク処理の実行可否が、それぞれグループウェアサーバマシン側に自動的に依頼される。そして、グループウェアサーバマシン側では、この依頼の都度、タスク処理実行可否確認手段がワークフローサーバマシンとリアルタイムで通信することで、該当する利用者によるタスク処理が実行可能か否かの確認処理が速やかに行われ、その結果が利用者側に通知される。上記確認処理は、グループウェアサーバマシン側で排他的（例えば依頼順）に行われるため、複数の利用者に同一タスクの処理について実行可が通知されることはなく、つまり複数の利用者が同一タスクを同時に開始することはない。
【００１２】
このように、タスク通知を受けた候補者からのタスク処理開始宣言（要求）に伴うタスク処理の実行可否の確認を、全てグループウェアサーバマシン上のタスク処理実行可否確認手段、つまりワークフローのクライアント機能を有するタスク処理実行可否確認手段で即座に処理することで、自身で実行すると決めた候補者のうちのただ１人がタスクを速やかに実行することができる。これにより、複数の候補者に通知を出す窓口業務のようなグループウェアの適用分野でワークフロー処理ができる。
【００１３】
また本発明は、グループウェアサーバマシンが一般に有する掲示板システムの電子掲示板を利用して、ワークフロー中の処理可能となったタスクの処理対象となるタスク処理用文書が当該電子掲示板に設定される構成を適用すると共に、上記エージェントシステムが、処理可能となったタスクを実行候補者全員に通知するのに、該当するタスク処理用文書へのリンク情報が付加された電子メールを用い、利用者側のグループウェアクライアントマシン上で、利用者操作により自身宛ての上記電子メール（メール文書）が開かれて上記リンク情報（例えばアイコン形式のリンク情報）が選択された場合に、当該リンク情報によりリンクされている上記掲示板上のタスク処理用文書が上記グループウェアクライアントマシンにダウンロードされる構成を適用することをも特徴とする。ここでは、タスク処理実行可否確認依頼手段はグループウェアクライアントマシン上で動作することになる。
【００１４】
このような構成においては、グループウェアサーバマシンの掲示板システムの有効利用が図れると共に、グループウェアクライアントマシン側に、ワークフローサーバマシンとの通信機能（ワークフローのクライアント機能）を用意または配布することなく、ただ１人のタスク処理実行者を決めることが可能となる。
【００１５】
ここで、上記タスク処理実行可否確認依頼手段をタスク処理用文書に埋め込まれた所定の組み込みプログラムにより実現するとよい。また、この組み込みプログラム（タスク処理クライアントプログラム）を呼び出す（起動する）タスク処理開始宣言手段をＧＵＩ（Graphical User Interface）のボタン形式のコマンド、メニュー形式のコマンド、ショートカットキー等の操作コマンドにより実現するならば、利用者はボタン操作、メニュー選択操作、或いはショートカットキー操作などの単一の操作で、組み込みプログラム（タスク処理実行可否確認依頼手段）を呼び出す（起動する）ことが可能となる。また、上記グループウェアサーバマシンに設けられたタスク処理実行可否確認手段をワークフローのクライアント機能を有するサービスプログラム（タスク処理サーバプログラム）により実現するとよい。
【００１６】
この他、掲示板上には、種々のタスクについてのタスク処理用文書が存在し得ることから、当該タスク処理用文書と、タスク通知用の電子メールと、タスク処理が実行可能か否かの確認依頼とに、それぞれタスクを特定するためのタスク識別情報（タスクＩＤ）を付加するとよい。タスク処理用文書にはまた、該当するタスクの状態（例えば、「実行可」、「実行中」、「実行完了」など）を示すタスク状態情報も付加するとよい。この構成では、タスク処理が実行可となった利用者側のグループウェアクライアントマシンにダウンロードされたタスク処理用文書のタスク状態を「実行可」から「実行中」に変更すればよい。また、タスク処理完了時には、編集がなされたタスク処理用文書のタスク状態を「実行中」から「実行完了」に変更し、この変更後のタスク処理用文書により、上記掲示板上の対応するタスク処理用文書を更新すればよい。
【００１７】
なお、以上の装置（ワークフロー管理システム）に係る本発明は方法（ワークフロー管理方法）に係る発明としても成立する。
また、上記ワークフロー管理システム（またはワークフロー管理方法）に係る発明は、電子掲示板上の掲示文書に対して同時に書き込める利用者の数を制限する電子掲示板システム（または同システムにおける同時書き込み可能利用者数制限方法）に係る発明として捉えることも可能である。
【００１８】
ここでは、掲示文書に同時に書き込める利用者の数をｌに制限することで、排他制御できる。また、特定の掲示板に対して多くの利用者が同時に書き込むことを禁じることで、性能劣化の防止と議論の交錯の防止を図ることができる。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００２０】
図１は本発明の一実施形態に係るワークフロー管理システムのシステム構成を示すブロック図である。
同図において、ＬＡＮ、インターネット等のネットワーク１１には、ワークフローサーバマシン（以下、ワークフローサーバと称する）１２と、グループウェアサーバマシン（以下、グループウェアサーバと称する）１３と、複数のグループウェアクライアントマシン（以下、グループウェアクライアントと称する）１４とが接続されている。
【００２１】
ワークフローサーバ１２は、ある決められた順序をもって業務の実行者または実行者の候補（実行候補者）に対して業務を順次配布し、業務の配布を受けた実行候補者のうち１人だけが業務を遂行できるように管理するための、つまり機械的な作業を管理するための計算機である。
【００２２】
ワークフローサーバ１２は、一連の作業の流れの中で承認や否認といった個々の業務（タスク）が実行可能な状態になる毎に、当該業務を実行する実行者の候補を決定する。ここで、業務を実行する順番は予め決定される。通常はワ一クフロー管理システムの機能でＧＵＩを用いて順序が決定される。
【００２３】
グループウェアサーバ１３は、グループ内の各ユーザの知的な作業を支援してグループ作業の効率化を図るための計算機である。グループウェアサーバ１３上では、タスク処理サーバプログラム１３１と、ワークフローＡＰＩ（Application Program Interface）１３２とが動作可能なようになっている。
【００２４】
タスク処理サーバプログラム１３１は、後述するタスク処理クライアントプログラム１４６から呼び出され、ワークフローサーバ１２と通信して利用者が処理を実行できるかを確認し、当該タスク処理クライアントプログラム１４６に結果を返信する機能を実現する。ワークフローＡＰＩ１３２は、タスク処理サーバプログラム１３１がワークフローサーバ１２と通信をするためのインタフェースを提供する。
【００２５】
グループウェアサーバ１３は、各グループウェアクライアント１４から利用可能な掲示板（電子掲示板）１３３を有する電子掲示板システムと、電子メール機能とを備えている。
【００２６】
グループウェアサーバ１３はまた、当該グループウェアサーバ１３本来の上記電子メール機能とは別に、電子メールの発行制御を司るメール発行制御エージェント１３４を有している。このメール発行制御エージェント１３４は、ワークフローサーバ１２により起動され、当該ワークフローサーバ１２におけるワークフロー中で処理可能となったタスクの実行候補者の情報を当該ワークフローサーバ１２から取得して、その実行候補者全員に当該タスクを通知するためのメールを発行する新規なメール発行機能を有する。
【００２７】
なお、上記メール発行制御エージェント１３４は必ずしもグループウェアサーバ１３上に設けられる必要はなく、専用のクライアントマシン（メール発行クライアントマシン）または任意のグループウェアクライアント１４に設けられるようにしても構わない。
【００２８】
各グループウェアクライアント１４は、それぞれＧＵＩを持ち、グループウェアサーバ１３より掲示板１３３上のデータ（ここでは、メール発行制御エージェント１３４により発行されたメールにより通知されたタスクの処理対象となるタスク処理用文書）をダウンロードすることで、利用者操作による当該データの参照と変更を可能とする。
【００２９】
またグループウェアクライアント１４は、ダウンロードしたデータ（タスク処理用文書）が利用者の操作により変更された場合、利用者による画面を閉じる操作（ここでは、完了操作）などに応じて、その変更されたデータをグループウェアサーバ１３に返送する。利用者操作によるデータの変更は、グループウェアサーバ１３側のデーモンなどによって定期的にワークフローサーバ１２に通知される。
【００３０】
各グループウェアクライアント１４はまた、当該クライアント（クライアントマシン）の利用者に固有のメールボックス１４１を有している。メール発行制御エージェント１３４によりグループウェアクライアント１４の利用者宛に発行されるメール（メール文書）は当該クライアント１４のメールボックス１４１に格納される。なお、各利用者毎のメールボックス１４１が所定のサーバに置かれる構成であっても構わない。
【００３１】
次に、図１のワークフロー管理システムの動作を図２及び図３の動作説明図を参照して説明する。
まず、ワークフローサーバ１２にてジョブ（作業）が開始され、上記ジョブ中の１つのタスク（業務）が処理可能な状態になると、当該タスクの処理対象となる文書（タスク処理用文書）１３６がグループウェアサーバ１３の掲示板システムにより当該サーバ１３上の掲示板１３３に設定される。このタスク処理用文書１３６はワークフロー中の最初（先頭）のタスクであれば、該当するジョブに固有の文書のテンプレートであり、ワークフローの途中のタスクであれば、先行するタスクの処理で更新された文書である。
【００３２】
タスク処理用文書１３６には、該当するタスクの状態（例えば、「実行可」、「実行中」、「実行完了」など）を示すタスク状態情報と当該タスクの識別情報としてのタスクＩＤとが設定された隠しフィールド１３６ａが含まれている。この隠しフィールド１３６ａは、表示対象外であり、利用者から見えない。
【００３３】
ワークフローの途中のタスクが処理可能となった場合、タスク処理用文書１３６として、上記のように先行するタスクの処理で更新された文書が用いられるが、タスク状態は「実行完了」から「実行可」状態に、タスクＩＤは新たに処理可能となったタスクＩＤに変更される。
【００３４】
タスク処理用文書１３６には更に、（当該文書１３６の表示状態において）利用者がタスクの実行開始を宣言するための「開始」ボタン１３６ｂと、タスクの完了を通知するための「完了」ボタン１３６ｃとを含む、タスク処理に関係する各種指示ボタン（コマンドボタン）の情報が予め設定されている。
【００３５】
さて、ワークフローサーバ１２にて、上記ジョブ中の１つのタスク（業務）が処理可能な状態になった場合、「タスクレディ（ＴＡＳＫ＿ＲＥＡＤＹ）」イベント１２１が発生して、当該イベント１２１によりメール発行制御エージェント１３４に対してトリガ起動１２２がかけられる。ここでは、処理可能となったタスクが出張申請の承認または否認処理であるものとする。
【００３６】
するとメール発行制御エージェント１３４は、ワークフローサーバ１２との間で通信を行って、当該ワークフローサーバ１２から、タスク名（タスクＩＤ）と、（グループウェアの利用者であって）当該タスク名のタスクを実行する候補者（担当者）全員の情報とを取得する。そしてメール発行制御エージェント１３４は、該当するタスク名（タスクＩＤ）のタスクを示す電子メールを、実行候補者となった利用者全員について、当該利用者（が使用するグループウェアクライアント１４）のメールボックス１４１に配布するメール送信１３５を行う。この電子メールには、該当するタスクの処理対象となるタスク処理用文書（１３６）へのリンクを示す後述する文書アイコン（１４３ａ）が付加（設定）されている。
【００３７】
グループウェアクライアント１４の利用者は、メールボックス１４１にメールが配布されたことを認識すると、当該メール（メール文書）を開く操作１４２を行う。すると処理すべきタスク（出張申請の承認または否認処理）を通知するメール文書１４３が開かれる。このメール文書１４３には、該当するタスクのタスクＩＤが含まれると共に、前記したようにグループウェアサーバ１３の掲示板１３３上のタスク処理用文書１３６へのリンクを示す文書アイコン１４３ａが付加されている。
【００３８】
そこで利用者が、文書アイコン１４３ａをクリック（選択）する操作１４４を行うと、当該文書アイコン１４３ａとリンクされている、グループウェアサーバ１３の掲示板１３３上のタスク処理用文書１３６を呼び出して、グループウェアクライアント１４へのダウンロード１３７を行う処理が行われる。
【００３９】
これにより、グループウェアクライアント１４の表示器には、掲示板１３３上のタスク処理用文書１３６のコピーであるタスク処理用文書１４５が、処理すべきタスク（ここでは出張申請の承認または否認処理）を示す例えば帳票形式で表示される。このタスク処理用文書１４５の表示画面（ウィンドウ）を業務画面と呼ぶ。利用者（実行候補者）は、業務画面上でタスク（業務）の内容を確認することができる。
【００４０】
タスク処理用文書１３６のコピーであるタスク処理用文書１４５（が表示されている業務画面）には、前記「開始」ボタン１３６ｂと「完了」ボタン１３６ｃとを含む、タスク処理に関係する各種コマンドボタンが配置されている。「開始」ボタン１３６ｂは、利用者がタスクの実行開始を宣言する他に、タスクの実行を開始するのを決定する特定プログラム（以下、タスク処理クライアントプログラムと称する）１４６を起動する仕組みを実現するためのものである。なお、このようなＧＵＩのボタン形式のコマンドに代えて、メニュー形式のコマンドを用いることも、特定のキーまたはキーの組み合わせ（ショートカットキー）を、各コマンドに割り当てることも可能である。
【００４１】
利用者（実行候補者）は、業務画面上のタスク処理用文書１４５を参照してタスク（業務）の内容を確認すると、利用者自身が当該タスクの処理を開始しようとする場合には、業務画面上のタスク処理用文書１４５に付加されている「開始」ボタン１３６ｂをクリックして（押して）、自身が処理することを宣言し、他の利用者が当該タスクの処理を開始できないようにする。但し、以下に述べるように、既に他の利用者がタスク処理を開始している場合等には、タスク処理を宣言しても当該タスク処理を開始できない。
【００４２】
さて、「開始」ボタン１３６ｂには、タスク処理クライアントプログラム１４６がリンクされている。つまり、業務画面上に開かれているタスク処理用文書１４５には「開始」ボタン１３６ｂにリンクさせてタスク処理クライアントプログラム１４６が埋め込まれて（組み込まれて）いる。これは、グループウェアサーバ１３の掲示板１３３上のタスク処理用文書１３６に、「開始」ボタン１３６ｂにリンクさせてタスク処理クライアントプログラム１４６が埋め込まれていることによる。このようなプログラムは、一般にスクリプト、或いは組み込みプログラムなどと呼ばれる。
【００４３】
そこで、業務画面上に開かれているタスク処理用文書１４５上の「開始」ボタン１３６ｂがクリックされると、タスク処理クライアントプログラム１４６の呼び出し１４７が行われる。
【００４４】
タスク処理クライアントプログラム１４６は、グループウェアサーバ１３上のタスク処理サーバプログラム１３１との間でリアルタイムで通信１４８を行い、当該タスク処理サーバプログラム１３１を介してワークフローサーバ１２にタスク処理を開始できるか問い合わせる機能と、問い合わせた結果をタスク処理用文書１４５の隠しフィールド１３６ａ（のタスク状態情報部）に埋め込むと共に、利用者に画面表示等により通知する機能とを有する。
【００４５】
このため、タスク処理クライアントプログラム１４６が呼び出された場合、当該プログラム１４６（に従ってグループウェアクライアント１４）は、グループウェアサーバ１３上のタスク処理サーバプログラム１３１を呼び出して通信１４８を行い、隠しフィールド１３６ａに設定されているタスクＩＤの示すタスクについて、ワークフローサーバ１２に処理開始の可否を問い合わせることを依頼する。
【００４６】
このように、タスク処理用文書１４５（１３６）にタスク処理サーバプログラム１３１と通信を行うタスク処理クライアントプログラム１４６を組み込んでおくことで、各グループウェアクライアント１４側に、当該グループウェアクライアント１４とタスク処理サーバプログラム１３１との間で通信を行うことを可能とする、タスク処理クライアントプログラム１４６と比較してボリュームの大きい（同一バージョンの）ＡＰＩを、例えばグループウェアサーバ１３から配布する必要をなくすことができる。
【００４７】
さて、タスク処理サーバプログラム１３１がタスク処理クライアントプログラム１４６により呼び出されて、タスク処理開始の可否の問い合わせが依頼されると、当該タスク処理サーバプログラム１３１（に従ってグループウェアサーバ１３）は、ワークフローＡＰＩ１３２を介してワークフローサーバ１２との間で通信１３８を行い、問い合わせを受けたタスクの処理を利用者が開始できるか否かを確認する。
【００４８】
ここで、タスク処理サーバプログラム１３１の動作は、１つのグループウェアクライアント１４上のタスク処理サーバプログラム１３１からの問い合わせに対して排他的に行われ、他のグループウェアクライアント１４上のタスク処理サーバプログラム１３１からの問い合わせは待たされる。このため、複数の利用者が同一のタスク処理を同時に開始することはない。また、既に他の利用者がタスク処理を開始していたり、タスクが消滅していた場合は、利用者はタスク処理を開始できない。
【００４９】
ワークフローサーバ１２は、あるタスクＩＤのタスクの処理に対するタスク処理サーバプログラム１３１からの最初の問い合わせ（確認処理）に対しては、処理開始可を返す。これに対し、既に他の利用者がタスク処理を開始していたり、タスクが消滅していた場合は、その旨の理由を付して処理不可を返す。
【００５０】
これを受け、タスク処理サーバプログラム１３１（に従ってグループウェアサーバ１３）は、ワークフローサーバ１２に対する確認処理の結果をタスク処理クライアントプログラム１４６に通知する。
【００５１】
タスク処理クライアントプログラム１４６は、タスク処理サーバプログラム１３１からの確認結果を参照する。もし、確認結果がタスク処理を開始できることを示しているならば、タスク処理クライアントプログラム１４６は利用者に業務画面上に開かれているタスク処理用文書１３６での編集を許可すると共に、当該文書１３６の隠しフィールド１３６ａのタスク状態情報を「実行可」から「実行中」状態に変更する。これに対し、タスク処理が開始できないことを示しているならは、タスク処理クライアントプログラム１４６は理由を利用者に通知する。
【００５２】
利用者は、タスク処理用文書１３６上での編集が許可されると、当該文書１３６を対象に該当するタスク処理のためのデータ編集（記入）操作（ここでは、出張申請の承認または否認のための記入操作）を行う。
【００５３】
タスク処理（業務）を完了した利用者は、業務画面上に開かれているタスク処理用文書１３６に付加されている「完了」ボタン１３６ｃをクリックする。するとグループウェアクライアント１４はグループウェアサーバ１３の掲示板システムを用いて、利用者操作による編集（タスク処理）後のタスク処理用文書１４５に基づいて掲示板１３３上のタスク処理用文書１３６を更新させる。この更新処理には、タスク処理用文書１３６をタスク処理用文書１４５で置き換える方式、またはタスク処理用文書１３６に対してタスク処理用文書１４５上での変更・追加部分のみを反映させる方式のいずれを適用しても構わない。
【００５４】
これに対し、タスク処理（業務）を開始できなかった利用者が「完了」ボタン１３６ｃをクリックした場合には、タスク処理用文書１３６の表示画面（業務画面）が非表示となるだけである。
【００５５】
グループウェアサーバ１３は、各タスクＩＤのタスク処理の状況を定期的にワークフローサーバ１２に通知する。ワークフローサーバ１２は、グループウェアサーバ１３からタスク処理の完了が通知された場合、次のタスク処理の実行候補者を選択する。
【００５６】
以上は本発明をワークフロー管理システムに実施した場合について説明したが、これに限るものではない。例えば、上記ワークフロー管理システムで適用された技術、即ちタスク処理の実行候補者のうち、最初に当該タスク処理の開始を宣言した１人だけが当該タスク処理を実行して掲示板１３３上の文書を更新できる技術は、電子掲示板システムにおいて、電子掲示板毎に同時に書き込める利用者を制限する（例えば１人に制限する）ことに応用可能である。
【００５７】
具体的には、電子掲示板毎に同時書き込み者数を制限できる、前記タスク処理サーバプログラム１３１に相当するサービスプログラムを１つ用意する共に、電子掲示板に設定されている文書（掲示文書）内に、前記タスク処理クライアントプログラム１４６に相当するスクリプトなどと呼ばれる組み込みプログラムを埋め込み、利用者が掲示文書に書き込もうとするときに、当該組み込みプログラムから上記サービスプログラムを呼び出して、このサービスプログラムにより掲示文書に対して同時に書き込める数を確認することによって、掲示文書に対して同時に書き込める利用者の数を（例えば１人に）制限することが可能となる。
【００５８】
【発明の効果】
以上詳述したように本発明によれば、ワークフローの処理（タスク）が実行可能な状態となった場合に、エージエントシステムが自動的に実行者を決めずに、そのタスクの実行候補者全員に通知を出し、この通知を受けた候補者のうち、自身で実行すると決めた候補者の操作に応じて、当該候補者がタスクを実行可能か否かをワークフローサーバに問い合わせて確認する動作を、グループウェアサーバマシン側で排他的に行う構成としたので、タスクを実行すると決めた候補者のうちのただ１人が当該タスクを実行することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るワークフロー管理システムのシステム構成を示すブロック図。
【図２】図１のワークフロー管理システムの動作を説明するための図。
【図３】図１のワークフロー管理システムの動作を説明するための図。
【符号の説明】
１１…ネットワーク
１２…ワークフローサーバ（ワークフローサーバマシン）
１３…グループウェアサーバ（グループウェアサーバマシン）
１４…グループウェアクライアント（グループウェアクライアントマシン）
１３１…タスク処理サーバプログラム（タスク処理実行可否確認手段）
１３２…ワークフローＡＰＩ
１３３…掲示板（電子掲示板）
１３４…メール発行制御エージェント（エージェントシステム）
１３６…タスク処理用文書（掲示板１３３上のタスク処理用文書）
１３６ａ…隠しフィールド
１３６ｂ…「開始」ボタン（タスク処理開始宣言手段）
１３６ｃ…「完了」ボタン
１４１…メールボックス
１４３…メール文書
１４３ａ…文書アイコン（リンク情報、ダウンロード手段）
１４５…タスク処理用文書（グループウェアクライアント１４の業務画面上のタスク処理用文書）
１４６…タスク処理クライアントプログラム（タスク処理実行可否確認依頼手段）

Claims (1)

1. ワークフロー中の処理可能となったタスクの処理対象となるタスク処理用文書であって、利用者がタスクの実行開始を宣言するのに用いられる開始ボタンが配置されると共に当該開始ボタンが選択されることにより呼び出される特定プログラムが埋め込まれたタスク処理用文書が設定される電子掲示板を有し、グループウェアを管理するグループウェアサーバマシンと、
   ワークフロー中の処理可能となったタスクの実行候補者として登録されたグループウェアの複数の利用者の各々に当該タスクを通知するための電子メールであって、当該タスクの処理対象となる前記タスク処理用文書へのリンク情報が付加されている電子メールを発行するメール発行機能を有するエージェントシステムと、
   前記エージェントシステムにより発行された電子メールに付加されている前記リンク情報が利用者操作により選択されることで、当該リンク情報によりリンクされている前記掲示板上の前記タスク処理用文書を前記利用者操作がなされたグループウェアクライアントマシンにダウンロードするダウンロード手段と、
   前記ダウンロードされたタスク処理用文書に配置されている前記開始ボタンが利用者操作により選択されることで、当該タスク処理用文書の編集を伴う前記タスクの処理開始を宣言するためのタスク処理開始宣言手段と、
   前記開始ボタンが利用者操作により選択されることで呼び出される前記特定プログラムに応じて、該当する利用者が前記タスク処理開始宣言手段によって宣言されたタスクの処理を実行可能か否かを確認することを、前記グループウェアサーバマシン側に依頼するタスク処理実行可否確認依頼手段と、
   前記タスク処理実行可否確認依頼手段による依頼に応じて、前記ワークフローを管理するワークフローサーバマシンと通信することにより、該当する利用者による前記タスク処理が実行可能か否かを排他的に確認して、その確認結果を前記利用者側に通知する、前記グループウェアサーバマシンに設けられたタスク処理実行可否確認手段とを具備することを特徴とするワークフロー管理システム。

Images