JP2013228958A - ワークフローシステム、ワークフローシステムの制御方法、プログラムおよび記録媒体 - Google Patents

Abstract

【課題】 開発者が定義したワークフローの経路に対して、ワークフローシステムの利用者が、制約なく容易に経路を編集できるワークフローシステムを提供する。
【解決手段】 クライアント装置において、ワークフローの経路情報を定義する経路情報オブジェクトを含む前記電子帳票を表示させ、経路情報オブジェクトにおけるアクティビティの情報の編集操作を受け付けて経路情報オブジェクトに反映し、電子帳票における帳票情報をワークフローサーバに送信する。ワークフローサーバは、クライアント装置から送信された帳票情報の経路情報オブジェクトに含まれるアクティビティ毎に、該アクティビティに関連付けられた情報をアクティビティ情報としてアクティビティ情報記憶手段に登録させる。
【選択図】図９

Description

本発明は、開発者によるワークフローの定義が容易であり、またユーザがワークフローのプロセスを簡単に編集できる簡易ワークフローシステムに関する。

従来から、会社などの組織において文書の回覧、承認などを確実に処理するためにワークフローシステムが用いられている。しかしながら、ワークフローの回覧先、承認先などの経路と、経路における各の回覧先、承認先の担当者（ユーザ）や権限などアクティビティとを、ワークフローシステムの導入時に、厳密に定義する必要があった。

そのため、ワークフローシステムを導入するための開発者の作業負荷は高く、また導入されたワークフローシステムを利用するユーザも、導入時の定義に従うこととなり、柔軟な経路編集（例えば、回覧先、承認先（アクティビティ）の追加、スキップ、変更）をすることが困難であった。

特許文献１では、開発者は、基本となる経路と、経路における各アクティビティのみを定義し、ユーザが使用する際には、「選択項目」により基本の経路の「次の担当者」以外の者を回覧先、承認先とすることができるワークフローシステムが提案されている。

選択項目には、例えば次の担当者をスキップして、次の次の担当者に承認依頼などをまわす「スキップ処理」がある。

特開平１０−１７７６０８号公報

しかしながら、特許文献１におけるワークフローシステムであっても、基本となる経路およびその経路上に現れるアクティビティについては、開発者が定義する必要がある。さらに開発者が定義した経路に従わずにユーザが利用できる「選択項目」における各項目についても、ワークフローシステム内に予め組み込まれている必要がある。

従って、ワークフローの定義を開発するための負荷を削減する効果は、あくまで「選択項目」に明示的に組み込まれる部分に限定されている。また、ユーザから見てもワークフローの柔軟性は、あくまで「選択項目」に明示的に組み込まれた範囲での経路の編集に限定されている。

本発明の目的は、開発者が定義したワークフローの経路に対して、ワークフローシステムの利用者が、制約なく容易に経路を編集できるワークフローシステムを提供することである。

本発明は、クライアント装置と、電子帳票の処理を制御するワークフローサーバがネットワークを介して接続可能なワークフローシステムであって、前記クライアント装置は、ワークフローサーバから受信した画面データに基づき、ワークフローの経路情報を定義する経路情報オブジェクトを含む前記電子帳票を表示させる表示制御手段と、前記表示制御手段により表示された前記経路情報オブジェクトにおけるアクティビティの情報の編集操作を受け付ける経路編集受付手段と、前記電子帳票におけるユーザ処理の操作に基づき、前記電子帳票における帳票情報を前記ワークフローサーバに送信する帳票情報送信手段と、を備え、前記ワークフローサーバは、前記クライアント装置の前記帳票情報送信手段から送信された前記帳票情報を受信する帳票情報受信手段と、前記帳票情報受信手段により受信した前記帳票情報の前記経路情報オブジェクトに含まれるアクティビティ毎に、該アクティビティに関連付けられた情報をアクティビティ情報としてアクティビティ情報記憶手段に登録させるアクティビティ情報登録手段と、を備えることを特徴とする。

本発明により、開発者が定義したワークフローの経路に対して、ワークフローシステムの利用者が、制約なく容易に経路を編集できるワークフローシステムを提供することが可能となる。

本発明の実施形態に係わるシステム構成の一例を示す図である。 本発明の実施形態に係わるワークフローサーバ、クライアント装置、開発装置のハードウェア構成の一例を示すブロック図である。 本発明の実施形態に係わるワークフローシステムにおけるソフトウェア構成の一例を示すブロック図である。 開発者がワークフローを開発する処理の一例を示すフローチャートである。 ワークフローを開発する際に定義する定義体の関連図の一例である。 ワークフローの起票時のメニューと、処理待ち案件一覧を開発する際に定義する定義体の関連図の一例である。 ワークフロー定義を格納するデータベース構成の一例である。 ユーザがワークフローの申請時に利用する画面の一例である。 ユーザがワークフローの確認時に利用し、アクティビティの追加／更新の操作をする画面の一例である。 ユーザがワークフローの確認時に利用し、アクティビティの削除の操作をする画面の一例である。 ワークフロー実行履記憶とアクティビティ情報記憶部のデータベース構成の一例である。 ワークフローの実行処理の一例を示すフローチャートである。 ワークフローの実行処理においてアクティビティの追加／更新をする処理の一例を示すフローチャートである。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１は、本発明の実施形態に係わるシステム構成の一例を示す図である。

図１において、ワークフローシステムは、少なくとも１つのクライアント装置１０１とワークフローサーバ１０２がネットワーク１０４を介して接続されている。更に開発装置１０３もシステム構成に含まれ、ネットワーク１０４を介してクライアント装置１０１とワークフローサーバ１０２に接続されていてもよい。

ユーザは、例えばウェブブラウザやクライアントソフトウェアなどを利用して、クライアント装置１０１から、ワークフローサーバ１０２に対して、ワークフロー進行の要求などを行う。

ワークフローサーバ１０２は、要求に応じた処理、管理をおこない、必要があればクライアント装置１０１に対して結果などを送信する。

開発者は、例えばウェブブラウザやクライアントソフトウェアなどを利用して、開発装置１０３から、ワークフローの定義などを行う。その際、開発操作は開発装置１０３のみで処理可能であり最終的な定義結果をワークフローサーバ１０２に格納してもよい。あるいは開発装置１０３とワークフローサーバ１０２が協調して開発のための動作をし、また定義結果を随時、ワークフローサーバ１０２に格納するような構成であってもよい。

ワークフローサーバ１０２、クライアント装置１０１、開発装置１０３の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。

クライアント装置１０１ａ、ワークフローサーバ１０２ａ、開発装置１０３ａは、それぞれＬＡＮにおいて接続されてもよい。また、クライアント装置１０１ｂ、ワークフローサーバ１０２ｂ、開発装置１０３ｂは、それぞれインターネット上、クラウド上において構成されてもよい。前述の構成が混在するものであってもよい。

図２は、本発明の実施形態に係わるワークフローサーバ、クライアント装置、開発装置のハードウェア構成の一例を示すブロック図である。

図２に示すように、ワークフローサーバ１０２、クライアント装置１０１は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０３、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。 ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードし、ロードしたプログラムを実行することで各種動作を実現する。

また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。

ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。

メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、あるいは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０４を介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いた通信等が可能である。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明についても後述する。

図３は、本発明の実施形態に係わるワークフローシステムにおけるソフトウェア構成の一例を示すブロック図である。

ワークフローシステムのユーザが、クライアント装置１０１においてワークフローシステムのクライアント画面を起動した後、ユーザの指示により処理待ち案件一覧要求送信部３０１により、処理待ち案件の一覧をワークフローサーバ１０２に要求する。処理待ち案件の一覧とは、承認者が、申請者から何らかの申請がされているか確認する場合や、あるいは申請者が、何らかの申請に対して承認者により否認されているか確認する場合の、案件がリストアップされているものである。

処理待ち案件一覧要求受信部３１２は、処理待ち案件一覧要求送信部３０１から送信された処理待ち案件一覧の要求を受信し、処理待ち案件一覧画面データ生成部３１３に画面データの生成を指示する。

処理待ち案件一覧画面データ生成部３１３は、アクティビティ情報記憶部３２２とワークフロー実行記憶部３２３から、前記ユーザが処理すべき処理待ちのアクティビティ情報とワークフローの実行中の情報を取得し、これらの情報に基づき処理待ち案件一覧の画面データを生成する。また、生成された画面データの各処理待ち案件には、その処理待ち案件がユーザにより選択された場合に、いずれの画面データを表示すべきかを示す画面ＩＤまたはそれらを導出するためのデータが含まれている。

生成された処理待ち案件一覧画面データは、処理待ち案件一覧画面データ送信部３１４により、ワークフローサーバ１０２から、クライアント装置１０１送信される。

処理待ち案件一覧画面データ受信部３０２は、ワークフローサーバ１０２から送信された処理待ち案件一覧画面データを受信し、処理待ち案件一覧画面データ表示制御部３０３に渡し、クライアント装置１０１に表示させる。

ここで、ユーザが新たに電子帳票の起票を使用とする場合には、複数ある申請内容からいずれの申請（交通費申請、出張申請など）をするか選択するための申請内容の一覧が表示される。表示画面に一覧として表示されてもよいし、メニューなどに列挙されてもよい。

処理対象選択部３０４は、処理待ち案件一覧からユーザが選択した処理対象、または前記申請内容の一覧（メニューでもよい）からユーザが選択した申請内容を受け付け、処理対象送信部３０５に渡される。

処理対象送信部３０５は、前記選択された処理対象をワークフローサーバ１０２に送信し、処理対象受信部３１５が受信する。受信した処理対象は、画面データ生成部３１６に渡される。

画面データ生成部３１６は、処理対象が、申請内容の一覧（またはメニュー）から選択された申請内容である場合には、各申請内容に画面ＩＤまたそれらを導出するためのデータ（画面ＩＤ等情報）が含まれており、その画面ＩＤ等情報に対応するレイアウトに基づき、必要な情報を設定するなどして画面データを生成する。

また、処理対象が、処理待ち案件である場合には、前述の通り、処理待ち案件一覧の処理待ち案件毎に、対応する画面ＩＤまたそれらを導出するためのデータ（画面ＩＤ等情報）が含まれている。その画面ＩＤ等情報に対応するレイアウトに基づき、処理待ち案件（案件ＩＤなどで特定されている）に対応する必要な情報を設定するなどして画面データを生成する。

画面を生成するに当たり、アクティビティ情報記憶部３２２やワークフロー実行記憶部３２３、更に業務データベースを参照することは可能であるが、それは各画面ＩＤに対応する画面生成ロジックとして処理が定義されている。

画面データ受信部３０６は、ワークフローサーバ１０２から送信された画面データを受信し、表示制御部３０７に渡し、クライアント装置１０１に表示させる。

クライアント装置１０１において、経路編集受付部３０８は、ユーザが経路編集をする操作を受け付ける。ユーザが指定した操作が、アクティビティの追加、削除、または更新かに応じて処理し、フローウィジェット上のアクティビティのデータを変更する。変更結果は、表示制御部３０７に渡され、表示画面に反映される。

また電子帳票に対してユーザの入力などが完了し、申請、承認などの処理が行われると（例えば申請ボタン、承認ボタンが押下されると）、帳票情報送信部３０９が、入力結果等を帳票情報としてワークフローサーバ１０２に送信する。ワークフローサーバ１０２においては、帳票情報受信部３１８が、帳票情報を受信する。受信した帳票情報から、処理されたアクティビティでの入力情報などの情報を取得し、ユーザが行った処理に応じて各アクティビティのステータスを変更し、アクティビティ情報登録部３１９によりアクティビティ情報記憶部３２２及びワークフロー実行記憶部３２３に登録する。

クライアント装置１０１において、保存指示部３１０は、ユーザが利用しているワークフロー定義に対して、経路編集をした結果を後に再利用するため、ワークフローサーバ１０２に格納する指示を受け付け、ワークフロー定義送信部３１１に渡す。

ワークフロー定義送信部３１１は、経路編集されたワークフロー定義を、ワークフローサーバ１０２に送信する。ワークフローサーバ１０２においては、ワークフロー定義受信部３２０が、ワークフロー定義を受信する。受信したワークフロー定義は、ワークフロー定義登録部３２１により、ワークフロー定義記憶部３２４に登録される。

なお、３０１〜３２１のそれぞれの機能部が、図３の通り、クライアント装置１０１とワークフローサーバ１０２において構成されるのは一例であり、その他の構成であってもよい。例えば経路編集受付部３０８で受け付けた編集内容は、ワークフローサーバ１０２に送信され、ワークフローサーバ１０２において画面データが再生成され、その結果をクライアント装置１０１に送り返し、表示制御部３０７で表示を編集してもよい。本構成は、あくまで一例である。

また、図３には示していないが、処理済み（あるいはこれから処理待ちになる予定）の案件に対して、案件の処理状況を追跡できるために、ユーザが自己に関連している案件の一覧を表示する画面、その案件の内容を確認できる画面の画面データ取得要求、表示制御があってもよい。

次に、図４から図７を用いて、ワークフローシステムが開発者に開発装置１０３を操作させ、ワークフローの各種定義体を作成する処理（以降、簡単に「開発者に定義させる」という場合がある）を説明する。

図４は、開発者がワークフローを開発する処理の一例を示すフローチャートである。図４のフローチャートの各ステップは、開発装置１０３上のＣＰＵ２０１で実行される。各ステップは、開発者による操作を受け付けて必要な定義体を構成していく。図４のフローチャートでは、ワークフローの定義結果は最後にまとめてワークフローサーバ１０２に格納するものとしている。実際には、フローチャートの処理においては、必要に応じてワークフローサーバ１０２と通信を行い、定義したワークフローの定義体をワークフローサーバ１０２の記憶部に随時格納するように実装してもよい。

ステップＳ４０１からＳ４１２においては、作成しようとするワークフローの定義に現れる１つのアクティビティに対応する各種定義体の定義を行う。すなわち、ワークフローの定義に現れるアクティビティの数だけ、ステップＳ４０１からＳ４１２が繰り返される。ただし、実際には複数のアクティビティで再利用可能なアクティビティもあり、必ずしも全てのステップでの定義体を開発者に作成させる必要はない。

ステップＳ４０１においては、アクティビティにおいてユーザが使用する画面のレイアウトを開発者に作成させる。具体的には、画面のベースとなるコンテナを新規に生成し、例えばアクティビティの名称を表示するためのテキストオブジェクト、ユーザに必要な情報を入力させるためのテキストボックスオブジェクト、申請や承認、確認を行い、次のアクティビティに進むときに押下するボタンオブジェクトなどを開発者に配置させる。これらの画面が、ユーザがワークフローを利用する際の帳票画面となる。１つのレイアウトの例を図５により簡単に説明する。

なお、以降「押下」とは、マウスによって対象となるオブジェクトをクリックすること、キーボード操作で対象となるオブジェクトにフォーカスさせエンターキーを押すなど、何らかの操作で対象となるオブジェクトを選択することを含む。

図５は、ワークフローを開発する際に定義する定義体の関連図の一例である。図５では、１つのアクティビティで必要な定義体の例を示すものであるが、前述の通り下記で説明する各定義体は、他のアクティビティを定義する際に再利用可能なものもあるため、必ずしも全てを定義する必要はない。あくまで一例である。

図５の５０１は開発画面のベースとなるコンテナ、５０２はワークフロー「回覧板」を定義する際の最初の「回覧板（申請）」の画面を定義する例である。レイアウト上には、このアクティビティ名と、申請ボタン５０５、その他の入力項目レイアウトを開発者に定義させる。なお、アクティビティ名には、「回覧板（申請）」と定義されているが、この文字列は固定で定義してもよいし、後述するアクションで画面表示をする際に動的に定義するようにしてもよい。

ステップＳ４０２においては、前述の画面レイアウト上にワークフローにおける経路（アクティビティの並び）を配置するための経路情報オブジェクトを、開発者に配置させる。図５においては、経路情報オブジェクト５０４が開発者によって配置された例を示している。

ステップＳ４０３においては、前述において作成したアクティビティに対応する画面が表示される際に実行されるアクションを、開発者に定義される。図５においては、５０３において例が示されている。５０３において、「回覧板（申請）」画面に対応するアクションとして、「ログインユーザ名を取得しアクティビティの画面内に表示する」、「経路情報をワークフロー定義Ｂ（後述）からアクティビティ情報を読み込み、経路情報オブジェクト５０４に設定する」などの処理を記載する。また、外部データベース（業務関係ＤＢ、人事関係ＤＢ）などと連携した処理を記載してもよい。例えば、経路情報オブジェクト５０４における申請者以外の承認者などを、人事データベースにおける上司を設定する処理を定義してもよい。本例（「回覧板」）では、申請者の上司である「課長」「部長」を自動的に設定するようアクションを定義したとする。

ステップＳ４０４においては、申請／確認／承認など、ワークフローを次のアクティビティに進めるために押下するボタンに対応するアクションを、開発者に定義させる。図５においては、申請ボタン５０５に対応するアクション（５０７）を定義させる。例えば、「クライアント装置１０１の帳票画面でユーザが入力した内容のエラーチェックを行う」、「ワークフローが初期に申請されたものであればフローＩＤを付与する」、「入力結果などをアクティビティ情報記憶部（後述）などに登録する」などの処理である。

ステップＳ４０５においては、経路情報オブジェクト５０４が押下された場合のアクションを開発者に定義させる。図５の５０８が対応するアクションの例である。まず、アクティビティが１つ（例えば「申請」）だけであれば、「申請」アクティビティの後に他のアクティビティを追加するための「追加確認ダイアログ」を表示させる処理を定義させる。また、それ以外の場合であれば「追加／削除／更新確認ダイアログ」を表示させる処理を定義させる。

ステップＳ４０６においては、「追加確認ダイアログ」（図５の５０９）のレイアウトを開発者に定義させる。このダイアログでは、経路情報オブジェクト５０４上で選択されたアクティビティ（実行中のアクティビティとは異なってもよい）の後ろに新たなアクティビティを追加することをユーザに確認させるための画面である。

ステップＳ４０７においては、「追加／削除／更新確認ダイアログ」（図５の５１０）のレイアウトを開発者に定義させる。このダイアログでは、経路情報オブジェクト５０４上で選択されたアクティビティ（実行中のアクティビティとは異なってもよい）の後ろに新たなアクティビティを追加する、または選択されたアクティビティを削除／更新することをユーザに確認させるための画面である。

ステップＳ４０８においては、ステップＳ４０６、Ｓ４０７において定義したダイアログ（図５の５０９、５１０）の追加ボタン５１１、削除ボタン５１３、更新ボタン５１４が押下された際のアクション（図５の５１５）を、開発者に定義させる。本例では１つのアクションとしているが、追加、削除、更新のそれぞれに分かれていてもよい。このアクションには、追加ボタン５１１が押下された場合には追加ダイアログ５１６を表示、削除ボタン５１３が押下された場合には経路情報オブジェクト５０４から選択されたオブジェクトを削除、更新ボタン５１４が押下された場合には更新ダイアログ５２２を表示するための処理を開発者に定義させる。

ステップＳ４０９においては、アクティビティの追加処理をユーザにさせるための追加ダイアログ（５１６）のレイアウトを開発者に定義させる。

ステップＳ４１０においては、追加ダイアログ（５１６）のＯＫボタン（５２０）押下時に、ユーザが設定した値を、経路情報オブジェクト５０４に反映させるための処理などをアクションとして開発者に定義させる。例えば、「経路情報オブジェクトにアクティビティを追加する」、「アクティビティ名を追加したアクティビティに設定する」、「処理するユーザのユーザ名を設定する」などである。また、図５の追加ダイアログ（５１６）では、追加するアクティビティに対応する画面を指定する方法はないが、複数の画面をリストボックスなどで指定できるようにし、ステップＳ４１０においては、ユーザが指定した画面との対応付けをアクティビティに設定するようにしてもよい。

ステップＳ４１１においては、アクティビティの更新処理をユーザにさせるための更新ダイアログ（５２２）のレイアウトを開発者に定義させる。

ステップＳ４１２においては、更新ダイアログ（５２２）のＯＫボタン（５２４）押下時に、ユーザが設定した値を、経路情報オブジェクト５０４に反映させるための処理などをアクションとして開発者に定義させる。例えば、「選択したアクティビティの名称を更新する」、「処理するユーザのユーザ名を更新する」などである。

ステップＳ４１３においては、開発者にアクティビティ及び関連する定義体を更に定義するか確認する。更に定義する場合（ＹＥＳの場合）、ステップＳ４０１に進む。定義を完了する場合（ＮＯの場合）、ステップＳ４１４に進む。

なお、後述するワークフローとしては、「回覧板」ワークフローとして、「回覧申請」、「課長確認」、「部長確認」の３つのアクティビティを標準で定義されたものを例として利用する。ただし、「課長確認」と「部長確認」については、アクティビティ名とユーザ名が異なる（表示する際にアクションにより異なる表示をする）だけであり、定義体は同一のものを呼び出すものとする。また、追加ダイアログ（５１６）により追加されるアクティビティも「課長確認」、「部長確認」と同一の定義体に関連付けられるものとする。

すなわち、例として「回覧板」ワークフローの実体は、最初のアクティビティに「回覧申請」、それ以降のアクティビティ（追加するアクティビティも含め）として「確認」の２種類の定義体で構成されるワークフローとなる。

また、ステップＳ４０５〜ステップＳ４１２で定義される画面レイアウトの５０９、５１０、５１６、５２２、及びアクションの５０８、５１５、５１７、５２３の全て、または一部は、経路情報オブジェクト５０４に関連する定義体として、あらかじめ標準で定義されていてもよい。

以上のステップでワークフローの定義体の定義に関する処理の説明を完了する。続くステップにより、これらの定義体が呼び出される処理を、開発者に定義させる。

ステップＳ４１４においては、開発者に初期画面の呼出を定義させる。すなわち上記のフローチャートの例では、経路情報として最初の定義体である「回覧板（申請）」に対応する画面をメニュー（図５の５０６）に登録させる。より詳細には図６を用いて説明する。

図６は、ワークフローの起票示のメニューと、処理待ち案件一覧を開発する際に定義する定義体の関連図の一連である。図５のメニュー５０６と図６のメニュー５０６は同一のものである。メニュー５０６には、例えば既に３つの項目（「交通費申請」など）が登録されている。ステップＳ４１４では、開発者に、前述のステップまでにおいて定義した「回覧板」ワークフローをユーザが実行できるようにメニュー５０６に「回覧板」を登録させる（実際には６０１のように文字列として「回覧板」を対応付ける）。

ステップＳ４１５においては、６０１から登録した項目が選択された場合の処理を、開発者にアクションとして定義させる。前述の「回覧板」の例では、「回覧板（申請）」の画面を表示させるアクションを定義させる（６０２）。

ステップＳ４１６において、処理待ち案件一覧画面（６０３）を表示する際のアクション（６０４）を開発者に定義させる。具体的には、例として、ログインユーザを取得し、後述するアクティビティ情報記憶部３２２から、当該ログインユーザが処理すべき処理待ちアクティビティ情報を処理待ち案件一覧の画面レイアウトに埋め込む処理を定義させる。詳細な情報としては、前記処理待ち案件であるワークフロー名（例えば「回覧板」など）、アクティビティ名（「課長確認」など）を起動時に表示させる処理を定義させる。その他、次のステップで定義させるアクションで使用する情報は、処理待ち案件一覧画面（６０３）にあらかじめ埋め込むよう定義させる。さらに各表示項目とその表示項目が選択された場合のアクション（６０５）を定義させる。すなわち、処理待ち案件として表示された情報や、そのステータス（申請が初めてか、却下された後の再申請か、など）などにより、表示する画面が異なる可能性があるため、選択された処理待ち案件に応じて、画面（画面ＩＤ）を特定し、当該画面の呼出表示処理をアクションとして定義させる。

また、処理待ち一覧画面自体が定義されていない場合（最初のワークフローを定義する際）には、処理待ち案件一覧の画面レイアウト自体を開発者に定義させるステップも必要である（不図示）。

以上のように、処理待ち案件一覧画面（６０３）から、ユーザが処理待ち案件を選択したときに、ワークフローシステムにおいて実行される処理は、６０４、６０５に記載されている。特に、６０４には、開発者により、次に遷移する画面条件と、その画面（画面ＩＤ）が対応付けられて実装されている。あるいは、画面ＩＤが直接埋め込まれていなくとも、ワークフロー定義の種類とアクティビティの種類の２次元データ構成のテーブルに画面ＩＤを登録しておき、例外的な画面遷移以外は、そのテーブルを参照するなど、様々な方式が考えられる。いずれにしても、６０４のアクションに従って処理待ち案件一覧画面が生成される。

すなわち、後述するユーザの利用時において、経路情報オブジェクト５０４にアクティビティを追加、更新、削除しても、６０４のアクションで次の画面ＩＤがされ、画面自体は、画面ＩＤ（例えば５０１）と画面データを生成するためのアクション（例えば５０３）で処理が定義されている。

この構成により、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの追加、更新、削除を行うことができるという効果が得られる。

ステップＳ４１７においては、前述のステップで作成したワークフローの定義体、メニューや処理待ち案件一覧に関連する定義の内容を、開発装置１０３からワークフローサーバ１０２に送信し、格納するよう要求する。

ワークフローサーバ１０２においては、この要求に従って、各種定義をワークフロー定義記憶部３２４および関連する画面レイアウト記憶部（不図示）、アクション記憶部（不図示）に記憶する。

次に、ステップＳ４１７でワークフローサーバ１０２に格納要求した定義体のうち、ワークフローサーバ１０２のワークフロー定義記憶部３２４に記憶するワークフロー定義について図７を用いて説明する。

図７は、ワークフロー定義を格納するデータベース構成の一例である。例として、前述のワークフローとして「回覧板」、その経路情報には３つのアクティビティ「回覧申請」、「課長確認」、「部長確認」が定義されている。

ワークフロー定義Ａ７００は、ワークフローの案件自体の情報（ワークフローの情報）を格納するテーブルの一例である。ワークフローが起票される際に、後述するワークフロー実行記憶部を構成するための定義であり、定義時点ではヘッダ（データ項目）のみ定義されており、中にデータが格納されていなくともよい。また、説明する画面の例として後述の図８、図１０が対応する。

ｉｓｓｅ＿ｉｄ７０１は、ワークフローの起票時にユーザが、またはシステムが自動的に付与する発行ＩＤに対応する項目である。本例では、検索キーとして任意に付与する。

ｔｉｔｌｅ７０２は、起票したワークフローの件名をユーザが入力するテキストボックスに対応する項目である。

ｂｏｄｙ７０３は、「回覧申請」に係る内容をユーザが入力する本文のテキストボックスに対応する項目である。

ｃｏｍｍｅｎｔ７０４は、「回覧」の内容の確認者が、確認事項などを自由に記載するコメントに対応する項目である。図８では表示されないが、図１０で表示されている。図８と図１０の違いは、異なるアクティビティにおいて、異なる画面レイアウトを定義するか、または同一の画面レイアウトではあるが、画面を表示する際のアクションにより、コメントの項目を表示するか否かを制御することにより実現する。

ｆｌｏｗ＿ｉｄ７０５は、ワークフローを特定するためのキーとなるＩＤであり、一意的に付与される。ワークフロー定義記憶部のテーブル構成が、ワークフロー定義毎に分かれている場合には、同一のテーブル構成の中で一意的であればよい。ワークフロー実行結果のデータとして、後述するワークフロー定義Ｂ７１０（アクティビティの定義を格納）と対応付けるために用いる（図１１参照）。

ワークフロー定義Ｂ７１０は、アクティビティの定義を格納するデータ構成の一例であり、前述の通りｆｌｏｗ＿ｉｄ（７０５、７１１）によりワークフロー定義Ａ７００のデータ構成と対応付けられている。

ａｃｔ＿ｉｄ７１２は、アクティビティを特定するための一意的なＩＤである。本例では、定義した順に１から番号を付与している。

ａｃｔ＿ｎａｍｅ７１３は、アクティビティ名である。例えば図８〜図１０の経路情報オブジェクト５０４（ａ〜ｇ）に表示される。

ａｃｔ＿ｎｏ７１４は、アクティビティの実行順序である。従って、実行時にアクティビティが追加、削除された場合には、定義順にかかわらず、実際に実行されるべき順に１から番号を付与する。例えば図８〜図１０の経路情報オブジェクト５０４に表示されるアクティビティの順番に一致する。

ｕｓｅｒ＿ｉｄ７１５は、実行予定または実行結果としてのユーザＩＤである。

ｕｓｅｒ＿ｎａｍｅ７１６は、実行予定または実行結果としてのユーザ名である。

ｓｔａｔｅ７１７は、アクティビティの状態である。例えば、「ｔｏｄｏ」は、対応するｕｓｅｒ＿ｉｄ７１５（またはｕｓｅｒ＿ｎａｍｅ７１６）のユーザにとって、該当するアクティビティが処理待ち状態であることを示す。ただし、最初のアクティビティのみは、起票前には「ｔｏｄｏ」とする。「ｄｏｎｅ」は、該当するアクティビティが既に処理済みであることを示す。「ｗａｉｔ」は、未処理であり、対応するユーザにとってまだ処理待ちにもなっていない状態である。

ｅｘｅｃｕｔｉｏｎ＿ｄａｔｅ７１８は、該当するアクティビティの処理が完了した日時である。

ｆｌｏｗ＿ｓｔａｔｅ７１９は、ワークフローの実行状態である。ワークフロー定義体においては、「ｉｎｉｔｉａｌ」が格納される。またワークフローの実行中は、「ａｃｔｉｖｅ」、全てのアクティビティが処理され完了状態となった場合には「ｃｏｍｐｌｅｔｅ」が格納される。

これにより図４〜図７の説明を完了する。すなわち、図４のフローチャートによるワークフローシステムが開発者に開発装置１０３を操作させ、ワークフローの各種定義体を作成する処理の説明を完了する。

次に図８から図１１を用いて、ユーザがクライアント装置１０１において、ワークフロー（例として「回覧板」）を申請、確認する操作と、実行時のデータを管理する記憶部のデータの状態を説明する。

図８は、ユーザがワークフローの申請時に利用する画面の一例である。ユーザとして「鈴木一郎」がログインして操作している（８０３）。申請はメニュー５０６を押下し、さらに６０１のワークフローの一覧からいずれかを選択することで開始する。例では「回覧板」（８０２）を選択したとして説明する。

「回覧板」を選択すると８０４の画面が表示される（ただし各テキストボックスは未入力の状態である）。起票時における画面表示のアクション（図５の５０３）定義により、最初のアクティビティ名「回覧申請」が表示される（８０５）。また、同アクションによりワークフロー定義Ｂ７１０（図７）から３つのアクティビティ名を読み込んで、ａｃｔ＿ｎｏ７１４で指定された順番に経路情報オブジェクト５０４ａに表示する。「回覧申請」のユーザ名はログインユーザ名、「課長確認」、「部長確認」のユーザ名は、前述の通り人事データベースなどから組織情報を取得して、「鈴木一郎」の上司の氏名を当てはめた結果である。現在処理しているアクティビティは協調などにより分かりやすく表示することが可能である。

さらに表示後に、ユーザが、発行ＩＤ８０６に「１０１−００３」、件名８０７に「資料回覧」、本文８０８に「ご覧ください。」と入力した結果であるが８０４の状態である。入力が終わった後、ユーザによる申請ボタン５０５の押下により、申請処理は終了し、ワークフローは次のアクティビティに進む。この時点で、処理結果がワークフローサーバ１０２に登録されるので、図１１を用いて説明する。

図１１は、ワークフロー実行記憶部とアクティビティ情報記憶部のデータベース構成の一例である。各期億部の構成については、ワークフロー実行記憶部３２３はワークフロー定義Ａ７００（図７）と同一、またアクティビティ情報記憶部３２２はワークフロー定義Ｂ７１０と同一であるため、詳細のデータ項目の説明は省略する。

ワークフロー実行記憶部３２３ａには、アクティビティ「回覧申請」において入力した、発行ＩＤ８０６の「１０１−００３」はｉｓｓｕｅ＿ｉｄに、件名８０７の「資料回覧」はｔｉｔｌｅに、本文８０８の「ご覧ください。」はｂｏｄｙに登録される。ｃｏｍｍｅｎｔは、アクティビティ「回覧申請」では入力用のテキストボックスが表示されないため、何も格納されない。またｆｌｏｗ＿ｉｄには自動的に「１８６」が付与され、格納される。

また、アクティビティ情報記憶部３２２ａに登録されるアクティビティの情報について説明する。アクティビティ「回覧申請」において、経路情報オブジェクト５０４上のアクティビティが編集されていないため、アクティビティの構成は同一である。そこで図７のワークフロー定義Ｂ７１０と違いがあるデータ項目のみ説明する。

ｆｌｏｗ＿ｉｄには、ワークフロー実行記憶部３２３ａのｆｌｏｗ＿ｉｄと同一の値が格納される。

ｕｓｅｒ＿ｉｄ、ｕｓｅｒ＿ｎａｍｅについては、アクティビティ「回覧申請」の画面が表示された時点でアクションにより決定されているので、その値が各アクティビティに格納される。

ｓｔａｔｅについては、アクティビティ「回覧申請」の処理が完了しているため、「回覧申請」に対しては「ｄｏｎｅ」へ変更された上で格納される。一方、アクティビティ「課長申請」が処理待ちの状態に変わるので「ｔｏｄｏ」へ変更された上で格納される。

ｅｘｅｃｕｔｉｏｎ＿ｄａｔｅについては、処理が完了したアクティビティ「回覧申請」についてのみ、実際に処理した日時が格納される。

ｆｌｏｗ＿ｓｔａｔｅについては、ワークフロー処理が実行中であるため、３つのアクティビティに対して全て「ａｃｔｉｖｅ」が格納される。

以上で、アクティビティ「回覧申請」の処理の結果を完了した時点のデータベースの状態について説明を完了する。

次にアクティビティ「課長確認」について、図９を用いて説明する。アクティビティ「回覧申請」の処理が完了した段階で、ユーザ「山田二郎」に対して、発行ＩＤ「１０１−００３」のワークフローのアクティビティ「課長確認」が処理待ち案件となる。

図９は、ユーザがワークフローの確認時に利用し、アクティビティの追加／更新の操作をする画面の一例である。まず、「山田二郎」がワークフローの「処理待ち案件一覧」を確認するための画面（９０１）を表示する。

処理待ち案件一覧の画面（９０１）には、「鈴木一郎」が申請した「資料回覧」の処理待ち案件が１つ表示されている。この画面は、処理待ち案件一覧のレイアウト（６０３）上に、アクション（６０４）に基づいて例えばアクティビティ情報記憶部３２２（図１１の３２２ａ）、ワークフロー実行記憶部３２３（図１１の３２３ａ）からログインユーザである「山田二郎」が処理すべき情報を検索して生成する。前記処理すべき情報とは、具体的には、ｕｓｅｒ＿ｉｄ７１５、ｓｔａｔｅ７１７などにより検索される。

処理待ち案件一覧の画面（９０１）の発行ＩＤ「１０１−００３」の行（処理待ち案件）を押下すると、対応付けられた、回覧板のアクティビティ「課長確認」の画面を表示する（９０３）。この画面は、不図示の「課長確認」画面のレイアウトと、当該画面の表示時に呼び出されるアクションにより生成される。

経路情報オブジェクト５０４ｂでは、現在処理中のアクティビティ「課長確認」が強調表示されている。また、ユーザ「山田二郎」は、コメント９０５「読みました。」を入力したとする。

ここで、経路情報オブジェクト５０４ｂにアクティビティを追加する例を説明する。２つめのアクティビティ「課長確認」の直後に、他の課長に回覧したいとする。この時、アクティビティ「課長確認」をフォーカスして押下すると、追加／削除／更新確認のダイアログ（５１０）が表示される。ここで追加ボタン（５１１）を押下すると、追加内容を入力するダイアログ（５１６）が表示される。追加ダイアログ（５１６）で、アクティビティ名（５１８）に「課長確認２」、ユーザ名（（５１９）に「清水四郎」を入力し、ＯＫボタン（５２０）を押下すると、経路情報オブジェクト５０４ｃの通りになる。すなわち、フォーカスしていたアクティビティ「課長確認」の次に、新しいアクティビティ「課長確認２」が追加された。

同様にアクティビティ「課長確認２」をフォーカスして、アクティビティ名「課長確認３」、ユーザ名「斉藤五郎」のアクティビティを追加する。またアクティビティ「部長確認」（９０８）をフォーカスして、アクティビティ名「営業確認」、ユーザ名「営業太郎」のアクティビティを追加する。結果は、経路情報オブジェクト５０４ｄの通りになる。

以上の説明の通り、ユーザは、例えばワークフロー「回覧板」を使用しているときに、設計者（開発者）の定義の意図や、上司／部下などの経路の定義にとらわれることがない。すなわち資料の回覧をすべきと判断した他部門の管理職、あるいは図示していないが、他部門の一般社員であってもワークフローの経路情報に動的で柔軟な追加が可能であるという効果を得ることができる。

また図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの追加を行うことができるという効果が得られる。

次に直前に追加したアクティビティを更新する例について説明する。アクティビティ「営業確認」をフォーカスして、追加／削除／更新確認のダイアログ（５１０）を表示させ、更新ボタン（５１４）を押下すると、図５の更新ダイアログ５２２が表示される。ここで、アクティビティ名「部長確認２」、ユーザ名「田中六郎」としてＯＫボタン（５２４）を押下すると、経路情報オブジェクト５０４ｅの通りになる（最後のアクティビティが９０９の通りになる）。

以上の説明の通り、ユーザは、例えば設計者（開発者）の定義の意図や、上司／部下などの経路の定義、あるいは他のユーザの経路情報の編集にとらわれることがなく、誤って作成、または異動などによりアクティビティは必要だが、ユーザ名を変更したいようなアクティビティについて、動的で柔軟な更新が可能であるという効果を得ることができる。

また図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの更新を行うことができるという効果が得られる。

ユーザ（「山田二郎」課長）が、課長確認アクティビティの画面（９０３）で、「確認」ボタン（９０６）を押下すると確認処理は終了し、ワークフローは次のアクティビティに進む。この時点で、処理結果がワークフローサーバ１０２に登録されるので、再度図１１を用いて説明する。

アクティビティ「回覧申請」と「課長確認」の結果として登録された内容については説明済みなので、アクティビティ「回覧申請」と「課長確認」の結果として登録される内容の違いについて述べる。

ワークフロー実行記憶部３２３ｂには、図９の９０５で「山田二郎」が入力した「読みました。」が新たに登録されている。

アクティビティ情報記憶部３２２ａにおいては、もともと３つのみ登録されていたアクティビティが６つになっている。これは図９の経路情報オブジェクト５０４ｅに対応する順番に並んでいる。ただし、ａｃｔ＿ｉｄは定義された順（または登録された順）になるため、「課長確認２」が“４”、「課長確認３」が“５”、「部長確認２」が“６”となっている。

ａｃｔ＿ｎａｍｅには、新たに追加されたアクティビティも含め、そのアクティビティの名称が図９で定義されたとおりに登録されている。

ａｃｔ＿ｎｏは、アクティビティを実行する順番であるため、定義順であるａｃｔ＿ｉｄとは異なり、図９の経路情報オブジェクト５０４ｅに並んでいる順に番号付けられており、そのため、アクティビティ情報記憶部３２２ａとは番号が変わっているアクティビティもある。

ｕｓｅｒ＿ｉｄおよびｕｓｅｒ＿ｎａｍｅには、新たに追加されたアクティビティも含め、ユーザＩＤとユーザ名が、図９の経路情報オブジェクト５０４ｅに並んでいる通りに登録される。

ｓｔａｔｅは、「山田二郎」（アクティビティ名「課長確認」）においては、処理が完了したため「ｄｏｎｅ」となっている。一方、次のアクティビティ（新たに追加されたアクティビティ）である「清水四郎」（アクティビティ名「課長確認２」）が「ｔｏｄｏ」となり、処理待ち案件であることを示す。

また、「山田二郎」（アクティビティ名「課長確認」）のｅｘｅｃｕｔｉｏｎ＿ｄａｔｅに処理時刻が登録される。

以上により、図９のアクティビティを完了した時点でのデータベース内の状態について説明を完了する。

次にアクティビティ「部長確認」について、図１０を用いて説明する（「課長確認２」、「課長確認３」は完了したものと見なす）。アクティビティ「課長確認３」の処理が完了した段階で、ユーザ「佐藤三郎」に対して、発行ＩＤ「１０１−００３」のワークフローのアクティビティ「部長確認」が処理待ち案件となる。この時点で、アクティビティの情報については、アクティビティ情報記憶部３２２ｃの通りになっているとする。

図１０は、ユーザがワークフローの確認時に利用し、アクティビティの削除の操作をする画面の一例である。まず、「佐藤三郎」がワークフローの「処理待ち案件一覧」を確認するための画面（１００１）を表示する。

処理待ち案件一覧の画面（１００１）には、「鈴木一郎」が申請した「資料回覧」の処理待ち案件が１つ表示されている。この画面は、処理待ち案件一覧のレイアウト（６０３）上に、アクション（６０４）に基づいて例えばアクティビティ情報記憶部３２２（図１１の３２２ｂ）、ワークフロー実行記憶部３２３（図１１の３２３ｂ）からログインユーザである「佐藤三郎」が処理すべき情報を検索して生成する。

処理待ち案件一覧の画面（１００１）の発行ＩＤ「１０１−００３」の行（処理待ち案件）を押下すると、対応付けられた、回覧板のアクティビティ「部長確認」の画面を表示する（１００３）。この画面は、不図示の「部長確認」画面のレイアウトと、当該画面の表示時に呼び出されるアクションにより生成される。

経路情報オブジェクト５０４ｆでは、現在処理中のアクティビティ「部長確認」が強調表示されている。

ここで、経路情報オブジェクト５０４ｆ上のアクティビティを削除する例を説明する。最後のアクティビティ「部長確認２」（９０９）を削除したいとする。この時、アクティビティ「部長確認２」をフォーカスして押下すると、追加／削除／更新確認のダイアログ（５１０）が表示される。ここで削除ボタン（５１３）を押下すると、アクティビティ名「部長確認２」が削除された経路情報オブジェクト５０４ｇが表示される。

ユーザ（「佐藤三郎」部長）が、部長確認アクティビティの画面（１００３）で、「確認」ボタン（９０６）を押下すると確認処理は終了し、ワークフローは次のアクティビティに進む。この時点で、処理結果がワークフローサーバ１０２に登録されるので、再度図１１を用いて説明する。

アクティビティ情報記憶部３２２ｄにおいては、アクティビティ情報記憶部３２２ｃで６つ登録されていたアクティビティが５つになっている。これは図１０の経路情報オブジェクト５０４ｇに対応する（「田中六郎」（アクティビティ名「部長確認２」）が削除されている）。

以上の説明の通り、ユーザは、例えば設計者（開発者）の定義の意図や、上司／部下などの経路の定義、あるいは他のユーザの経路情報の編集にとらわれることがなく、（例えば「回覧」することが）不適切であると判断されたアクティビティについての動的で柔軟な削除が可能であるという効果を得ることができる。

また図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの削除を行うことができるという効果が得られる。

全てのアクティビティの処理が完了したため、全てのｓｔａｔｅは「ｄｏｎｅ」、ｆｌｏｗ＿ｓｔａｔｅが「ｃｏｍｐｌｅｔｅ」となっている。

また「佐藤三郎」（アクティビティ名「部長確認」）のｅｘｅｃｕｔｉｏｎ＿ｄａｔｅに処理時刻が登録される。

以上により、図１０のアクティビティを完了した時点でのデータベース内の状態について説明を完了する。

これにより図８から図１１の説明を完了する。すなわち、ユーザがクライアント装置１０１において、ワークフロー（例として「回覧板」）を申請、確認する操作と、実行時のデータを管理する記憶部のデータの状態の説明を完了する。

次に図１２から図１３により、ワークフローシステムの動作について説明する。

図１２は、ワークフローの実行処理の一例を示すフローチャートである。図１２のフローチャートのステップＳ１２０１からＳ１２１０は、クライアント装置１０１上のＣＰＵ２０１で実行される。またステップＳ１２１１からＳ１２２０は、ワークフローサーバ１０２上のＣＰＵ２０１で実行される。

ステップＳ１２０１においては、ユーザからワークフローの処理対象の選択を受け付ける。ここで処理対象とは、申請時にメニューから選ばれる場合と、承認者／確認者などが処理待ち案件一覧から実行中且つログインユーザが処理すべき処理待ち案件を選択する場合がある。前者の場合、例えば図８のメニュー５０６からワークフローの一覧（６０１）が表示された場合には、ユーザが申請したい項目（例えば「回覧板」８０２）が選択され、ワークフロー「回覧板」の最初のアクティビティ「回覧申請」）を処理対象として受け付ける。一方、後者の場合、例えば図９の処理待ち案件一覧（９０１）から処理待ち案件（ワークフロー「回覧板」）のアクティビティ「課長確認」を処理対象として受け付ける。

ステップＳ１２０２においては、前記処理対象をユーザに操作させるために、ワークフローサーバ１０２に前述の処理対象を処理要求として送信する。

ステップＳ１２１１においては、クライアント装置１０１から送信された処理要求を受信する。

ステップＳ１２１２においては、処理要求に基づいて、画面データを生成する。具体的には、処理要求として、生成すべき画面の指定（画面レイアウトのＩＤ）が特定されており、当該画面レイアウトに対応するアクションにより、ワークフロー実行記憶部３２３、アクティビティ情報記憶部３２２の情報を利用して画面データを生成する。

ステップＳ１２１３においては、生成した画面データをクライアント装置１０１に送信する。

ステップＳ１２０３においては、ワークフローサーバ１０２から送信された画面データを受信する。

ステップＳ１２０４においては、画面データをクライアント装置１０１に接続された表示装置に表示し、ユーザからの電子帳票に対する入力処理、経路情報の編集処理、申請／承認／確認などのボタン押下による次のアクティビティへの進むための操作を受け付ける。電子帳票に対する入力処理についてはステップＳ１２０４の中で行われているものとして、以降の説明では省略する。

ステップＳ１２０５においては、操作内容による条件分岐を行う。具体的には、ユーザから受け付けた操作が、経路情報オブジェクト５０４において、アクティビティの編集を指示されたものである場合には、ステップＳ１２０６に進む。また、次のアクティビティへの進むための操作である場合には、ステップＳ１２１０に進む。

ステップＳ１２０６においては、経路情報オブジェクト５０４におけるユーザの操作内容による条件分岐を行う。具体的には、ユーザから受け付けた操作が、アクティビティの追加または更新の指示である場合には、ステップＳ１２０７に進む。アクティビティの削除の指示である場合には、ステップＳ１２０８に進む。

ステップＳ１２０７においては、アクティビティの追加／更新をするためのユーザ操作を受け付け、操作の結果を経路情報オブジェクト５０４に反映する。詳細については図１３において説明する。アクティビティの追加／更新の処理が完了したら、ステップＳ１２０４に進む。

ステップＳ１２０８においては、ユーザにより指定されたアクティビティを削除する。

ステップＳ１２０９においては、アクティビティが削除された結果を経路情報オブジェクト５０４に反映する。

ステップＳ１２１０においては、ユーザにより電子帳票に入力された内容、経路情報オブジェクト５０４などを、帳票情報としてワークフローサーバ１０２に送信する。

ステップＳ１２１４においては、クライアント装置１０１から送信された帳票情報を受信する。

ステップＳ１２１５においては、帳票情報に含まれる経路情報オブジェクト５０４の現アクティビティに対するｓｔａｔｅを「ｄｏｎｅ」に変更する。

ステップＳ１２１６においては、次アクティビティに対するｓｔａｔｅを「ｔｏｄｏ」とし、次アクティビティに対応するユーザにとっての「処理待ち案件」として指定する。

ステップＳ１２１７においては、処理中のワークフローにフローＩＤが付与されているか否かを判定する。ワークフローが起票された新しいものであれば、前述の帳票情報はクライアント装置１０１から初めて送信されてきたものであり、ワークフローサーバ１０２においてフローＩＤはまだ付与されていない場合があるからである。フローＩＤが付与されていなければ（“ＮＯ”の場合）には、ステップＳ１２１８に進む。フローＩＤが付与されていれば（“ＹＥＳ”の場合）には、ステップＳ１２２０に進む。

ステップＳ１２１８においては、帳票情報にフローＩＤを付与する。

ステップＳ１２１９においては、帳票情報を、ワークフロー実行記憶部３２３、アクティビティ情報記憶部３２２に新規に格納する。

ステップＳ１２２０においては、フローＩＤに基づき、ワークフロー実行記憶部３２３、アクティビティ情報記憶部３２２に既に格納されている情報と、前述の帳票情報を比較して、必要があれば書き換える。本願における「書き換える」とは、比較の結果としてアクティビティが編集されている場合（増減、更新、およびこれらの組み合わせ）の差分を反映すること、および既存の情報のうち、変更がある部分を書き換えることを含む。また、実際には差分のみ書き換えてもよいし、一度全て削除した上で、帳票情報を新たに格納し直す方法、その他いずれの方法であってもよい。これらいずれの方法であっても、本願における「書き換える」ものである。

以上で、図１２におけるフローチャートの処理の説明を完了する。次に、図１２のステップＳ１２０７に対応する処理の詳細を、図１３を用いて説明する。

図１３は、ワークフローの実行処理においてアクティビティの追加／更新をする処理の一例を示すフローチャートである。図１３のフローチャートのステップＳ１３０１からＳ１３０９は、クライアント装置１０１上のＣＰＵ２０１で実行される。またステップＳ１３１０からＳ１３１３は、ワークフローサーバ１０２上のＣＰＵ２０１で実行される。

ステップＳ１３０１においては、経路情報オブジェクト５０４におけるユーザの操作内容による条件分岐を行う。具体的には、ユーザから受け付けた操作が、アクティビティの追加である場合には、ステップＳ１３０２に進む。アクティビティの更新の指示である場合には、ステップＳ１３０３に進む。

ステップＳ１３０２においては、アクティビティを追加するための情報をユーザに入力させるため（図５の５１６）、画面データをワークフローサーバ１０２に要求する。

ステップＳ１３０３においては、アクティビティを更新するための情報をユーザに入力させるため（図５の５２２）、画面データをワークフローサーバ１０２に要求する。

ステップＳ１３１１においては、クライアント装置１０１から画面データの要求を受け付ける。

ステップＳ１３１２においては、要求がアクティビティの「追加」か「更新」かに応じて、画面データの生成を行う。

ステップＳ１３１３においては、生成した画面データをクライアント装置１０１に送信する。要求が「追加」であった場合（追加画面データを生成した場合）には、ステップＳ１３０４に進む。要求が「更新」であった場合（更新画面データを生成した場合）には、ステップＳ１３０７に進む。

ステップＳ１３０４においては、アクティビティを追加するための画面データを受信する。

ステップＳ１３０５においては、アクティビティを追加するための画面をクライアント装置１０１の表示装置に表示し、ユーザに必要な情報を入力させる。例として、図９のダイアログ（追加画面データに基づき生成した画面）５１６のアクティビティ名（５１８）、ユーザ名（５１９）に入力をさせて、受け付ける。

ステップＳ１３０６においては、前述のユーザ入力として受け付けた結果に基づき、経路情報オブジェクト５０４上に、アクティビティを追加する。以上により、追加処理の説明は完了する。

ステップＳ１３０７においては、アクティビティを更新するための画面データを受信する。

ステップＳ１３０８においては、アクティビティを更新するための画面に変更前のアクティビティ情報を設定して、クライアント装置１０１の表示装置に表示し、ユーザに必要な情報を入力させる。

ステップＳ１３０９においては、前述のユーザ入力として受け付けた結果に基づき、経路情報オブジェクト５０４上においてユーザに選択されているアクティビティの情報を更新する。以上により、更新処理の説明は完了する。

以上で、図１３におけるフローチャートの処理の説明を完了する。すなわち、図１２から図１３により、ワークフローシステムの動作についての説明を完了する。

以上の説明により、図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの追加、更新、削除を行うことができるという効果が得られる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、図４、図１２、図１３に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図４、図１２、図１３の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図４、図１２、図１３の各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。 さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ クライアント装置
１０２ ワークフローサーバ
１０３ 開発装置
１０４ ネットワーク
３０１ 処理待ち案件一覧要求送信部
３０２ 処理待ち案件一覧画面データ受信部
３０３ 処理待ち案件一覧画面データ表示制御部
３０４ 処理対象選択部
３０５ 処理対象送信部
３０６ 画面データ受信部
３０７ 表示制御部
３０８ 経路編集受付部
３０９ 帳票情報送信部
３１０ 保存指示部
３１１ ワークフロー定義送信部
３１２ 処理待ち案件一覧要求受信部
３１３ 処理待ち案件一覧画面データ生成部
３１４ 処理待ち案件一覧画面データ送信部
３１５ 処理対象受信部
３１６ 画面データ生成部
３１７ 処理対象画面データ送信部
３１８ 帳票情報受信部
３１９ アクティビティ情報登録部
３２０ ワークフロー定義受信部
３２１ ワークフロー定義登録部
３２２ アクティビティ情報記憶部
３２３ ワークフロー実行記憶部
３２４ ワークフロー定義記憶部

Claims (9)

1. クライアント装置と、電子帳票の処理を制御するワークフローサーバがネットワークを介して接続可能なワークフローシステムであって、
   前記クライアント装置は、
   ワークフローサーバから受信した画面データに基づき、ワークフローの経路情報を定義する経路情報オブジェクトを含む前記電子帳票を表示させる表示制御手段と、
   前記表示制御手段により表示された前記経路情報オブジェクトにおけるアクティビティの情報の編集操作を受け付ける経路編集受付手段と、
   前記経路編集受付手段により受け付けたアクティビティの情報の編集結果を、前記経路情報オブジェクトに反映させる経路定義反映手段と、
   前記電子帳票におけるユーザ処理の操作に基づき、前記電子帳票における帳票情報を前記ワークフローサーバに送信する帳票情報送信手段と、を備え、
   前記ワークフローサーバは、
   前記クライアント装置の前記帳票情報送信手段から送信された前記帳票情報を受信する帳票情報受信手段と、
   前記帳票情報受信手段により受信した前記帳票情報の前記経路情報オブジェクトに含まれるアクティビティ毎に、該アクティビティに関連付けられた情報をアクティビティ情報としてアクティビティ情報記憶手段に登録させるアクティビティ情報登録手段と、
   を備えることを特徴とするワークフローシステム。
2. 前記ワークフローサーバは、更に、
   前記帳票情報に対応する前記アクティビティ情報が、前記アクティビティ情報記憶手段に登録されているか否かを判定する登録判定手段と、を備え、
   前記アクティビティ情報登録手段は、
   前記登録判定手段により、前記アクティビティ情報記憶手段に前記帳票情報に対応する該アクティビティ情報が登録されていないと判定した場合には、前記帳票情報受信手段により受信した前記帳票情報の前記経路情報オブジェクトに含まれるアクティビティ毎に、該アクティビティ情報を該アクティビティ情報記憶手段に登録させ、一方、該帳票情報に対応する該アクティビティ情報が登録されていると判定した場合であって、且つ該帳票情報に含まれる該アクティビティ情報と該アクティビティ情報記憶手段に登録されている該アクティビティ情報が同一でない場合には、該帳票情報に含まれる該アクティビティ情報により該アクティビティ情報記憶手段に登録されている該アクティビティ情報を書き換えることを特徴とする請求項１に記載のワークフローシステム。
3. 前記経路編集受付手段における編集操作は、
   前記経路情報オブジェクトにおいてユーザが指定した位置にアクティビティを追加する操作であることを特徴とする請求項１または請求項２に記載のワークフローシステム。
4. 前記経路編集受付手段における編集操作は、更に、
   前記経路情報オブジェクトにおいてユーザが指定した位置のアクティビティを削除するものであることを特徴とする請求項１乃至請求項３のいずれか１項に記載のワークフローシステム。
5. 前記経路編集受付手段における編集操作は、更に、
   前記経路情報オブジェクトにおいてユーザが指定した位置のアクティビティを更新するものであって、該更新においては、少なくとも該アクティビティの対応する名称およびユーザを変更することが可能であることを特徴とする請求項１乃至請求項４に記載のワークフローシステム。
6. 前記クライアント装置は、更に、
   前記経路編集受付手段によりユーザが編集した前記経路情報オブジェクトに基づき、新たなワークフロー定義を保存する指示をユーザから受け付ける保存指示受付手段と、
   前記新たなワークフロー定義を、前記ワークフローサーバに送信するワークフロー定義送信手段と、を備え、
   前記ワークフローサーバは、
   前記クライアント装置から送信された前記新たなワークフロー定義を受信するワークフロー定義受信手段と、
   前記ワークフロー定義受信手段により受信した前記新たなワークフロー定義を、ワークフロー定義記憶手段に登録するワークフロー定義登録手段と、
   を備えることを特徴とする請求項１乃至請求項５のいずれか１項に記載されたワークフローシステム。
7. クライアント装置と、電子帳票の処理を制御するワークフローサーバがネットワークを介して接続可能なワークフローシステムの制御方法であって、
   前記クライアント装置は、
   表示制御手段が、ワークフローサーバから受信した画面データに基づき、ワークフローの経路情報を定義する経路情報オブジェクトを含む前記電子帳票を表示させる表示制御工程と、
   経路編集受付手段が、前記表示制御工程により表示された前記経路情報オブジェクトにおけるアクティビティの情報の編集操作を受け付ける経路編集受付工程と、
   経路定義反映手段が、前記経路編集受付工程により受け付けたアクティビティの情報の編集結果を、前記経路情報オブジェクトに反映させる経路定義反映工程と、
   帳票情報送信手段が、前記電子帳票におけるユーザ処理の操作に基づき、前記電子帳票における帳票情報を前記ワークフローサーバに送信する帳票情報送信工程と、を備え、
   前記ワークフローサーバは、
   帳票情報受信手段が、前記クライアント装置の前記帳票情報送信工程から送信された前記帳票情報を受信する帳票情報受信工程と、
   アクティビティ情報登録手段が、前記帳票情報受信工程により受信した前記帳票情報の前記経路情報オブジェクトに含まれるアクティビティ毎に、該アクティビティに関連付けられた情報をアクティビティ情報としてアクティビティ情報記憶手段に登録させるアクティビティ情報登録工程と、
   を備えることを特徴とするワークフローシステムの制御方法。
8. クライアント装置と、電子帳票の処理を制御するワークフローサーバがネットワークを介して接続可能なワークフローシステムにおいて実行可能なプログラムであって、
   前記クライアント装置を、
   ワークフローサーバから受信した画面データに基づき、ワークフローの経路情報を定義する経路情報オブジェクトを含む前記電子帳票を表示させる表示制御手段、
   前記表示制御手段により表示された前記経路情報オブジェクトにおけるアクティビティの情報の編集操作を受け付ける経路編集受付手段、
   前記経路編集受付手段により受け付けたアクティビティの情報の編集結果を、前記経路情報オブジェクトに反映させる経路定義反映手段、
   前記電子帳票におけるユーザ処理の操作に基づき、前記電子帳票における帳票情報を前記ワークフローサーバに送信する帳票情報送信手段として機能させ、
   前記ワークフローサーバを、
   前記クライアント装置の前記帳票情報送信手段から送信された前記帳票情報を受信する帳票情報受信手段、
   前記帳票情報受信手段により受信した前記帳票情報の前記経路情報オブジェクトに含まれるアクティビティ毎に、該アクティビティに関連付けられた情報をアクティビティ情報としてアクティビティ情報記憶手段に登録させるアクティビティ情報登録手段として機能させるためのプログラム。
9. 請求項８に記載されたプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images