(57)【特許請求の範囲】
【請求項１】
複数のコンピュータ端末が接続されるネットワークにおいて、ワークフローに従って当該コンピュータ端末を利用する担当者の間で当該ネットワークを介したデータの受け渡しを行うワークフローシステムであって、
前記コンピュータ端末に割り当てられる処理として、プロジェクト型の配列変数を指定させることが可能であり並列経路を多重化して扱うノードと、当該ノードの処理順を決定するためのパスとを定めたワークフロー定義および当該ワークフロー定義で参照されるデータ定義からなるプロジェクトを記憶する記憶手段と、
前記記憶手段に記憶された前記プロジェクトを読み出し、読み出された当該プロジェクトを用いて前記ワークフローの業務単位であるプロセスを作成して、前記コンピュータ端末に対して処理を割り当てる管理手段と、を備え、
前記記憶手段に記憶される前記プロジェクトにおける前記データ定義では、データとしてプロジェクト型およびその配列が定義されることを特徴とするワークフローシステム。
【請求項２】
前記記憶手段に記憶される前記プロジェクトは、定義ＩＤによって識別されることを特徴とする請求項１記載のワークフローシステム。
【請求項３】
ネットワークに接続され、担当者の間でワークフローを実行するための操作用コンピュータ端末と、
扱われる処理の単位であるノードに対して複数のプロセスを多重化するためのプロジェクト型の配列変数を指定して並列経路を多重化して扱うワークフローを設計する設計用コンピュータ端末と、
前記設計用コンピュータ端末により設計された前記ワークフローを記憶手段に記憶すると共に、当該記憶手段に記憶された当該ワークフローを読み出し、ノードに割り当てられた処理であるアクティビティに対応して前記操作用コンピュータ端末にアクセスするワークフローサーバと、を備え、
前記設計用コンピュータ端末により設計されたワークフローにおけるプロジェクト型の配列変数は、前記ノードと当該ノードの処理順を決定するためのパスとを定めたワークフロー定義および当該ワークフロー定義で参照されるデータ定義とを用いて指定され、当該データ定義では、データとしてプロジェクト型およびその配列が定義されることを特徴とするワークフローシステム。
【請求項４】
前記プロジェクト型の配列変数は、自己を識別するための定義ＩＤを属性として定義され、
前記ワークフローサーバは、定義された前記定義ＩＤを用いて前記プロジェクト型の配列変数に関する情報を記憶することを特徴とする請求項３記載のワークフローシステム。
【請求項５】
前記操作用コンピュータ端末は、割り当てられた処理の実行後にアクティビティの終了を前記ワークフローサーバに通知し、
前記ワークフローサーバは、前記ワークフローによる全てのアクティビティを終了した後にプロセスを完了することを特徴とする請求項３記載のワークフローシステム。
【請求項６】
ワークフローを実行する複数のコンピュータ端末に対してネットワークを介して接続される情報処理装置であって、
プロジェクト型の配列変数を指定させることが可能であり並列経路を多重化して扱う複数のノードとそれらを結ぶパスとで構成されたワークフロー定義および当該ワークフロー定義で参照されるデータ定義を含めたプロジェクトを記憶する記憶手段と、
前記記憶手段に記憶される前記プロジェクトを読み出し、読み出された当該プロジェクトを用いて前記ワークフローの業務単位であるプロセスを管理するプロセス管理手段と、
前記プロセス管理手段により管理される前記プロセスに基づいて前記コンピュータ端末に対してアクセスするユーザ管理手段と、を備え、
前記記憶手段に記憶される前記プロジェクトにおける前記データ定義では、データとしてプロジェクト型およびその配列が定義されることを特徴とする情報処理装置。
【請求項７】
前記記憶手段は、前記プロジェクトを一意に定める定義ＩＤに関連付けて当該プロジェクトを格納することを特徴とする請求項６記載の情報処理装置。
【請求項８】
コンピュータに実行させるプログラムを当該コンピュータの入力手段が読取可能に記憶した記憶媒体であって、
前記プログラムは、
ネットワークに接続された複数のコンピュータ端末に対して割り当てられる業務であるノードの１つとしてプロセスを多重化するためのプロジェクト配列型ノードをパスを用いて連結した状態にて、当該プロジェクト配列型ノードに配列されるプロジェクトを記憶手段に格納する処理を前記コンピュータに実行させ、
前記プロジェクトは、並列経路を多重化して扱う複数のノードとそれらを結ぶパスとで構成されたワークフロー定義および当該ワークフロー定義で参照されるデータ定義を含み、当該データ定義ではデータとしてプロジェクト型およびその配列が定義されることを特徴とする記憶媒体。
【請求項９】
前記プロジェクトは、配列の個々の要素が異なる種類のプロジェクトとして前記記憶手段に格納されることを特徴とする請求項８記載の記憶媒体。
【請求項１０】
前記プロジェクトは、複数のノードとそれらを結ぶパスで構成されたワークフロー定義、およびワークフローの業務単位であるプロセスで設定および参照できるデータの定義であるデータ定義をまとめた単位として前記記憶手段に格納されることを特徴とする請求項８記載の記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、オフィスにおけるワークフローの改善に係り、特に、動的に経路を変更できるワークフローシステム等に関する。
【０００２】
【従来の技術】
オフィスにおける事務処理の効率化、ファイルキャビネットのスペースコストの問題、環境問題等から、伝票処理を電子化して、ペーパーレスな帳票処理システムを構築することの必要性が提唱されて久しい。しかしながら、実際の伝票処理は複雑であり、更に例外処理に対する対応の問題などから、ペーパーレスな帳票処理システムは、未だ十分に普及されているとは言い得ない。また、多数の伝票を電子化するために、伝票定義や経路定義の簡単さが要求され、現実にフィットした承認システムとするための柔軟な経路指定の機能が要求されている。
【０００３】
ここで、ワークフローシステムに関する従来技術として、例えば、特開平１０−４９６０３号公報、特開平１０−１７７６１０号公報、特開平５−２１６７３６号公報が存在する。この特開平１０−４９６０３号公報には、異なるプロセス間の回覧、即ち、プロセスＡからプロセスＢへデータを回覧する場合に、プロセスＡで定義されるデータはプロセスＢでは読み取ることができないように設定することで、秘密事項の漏洩を防ぐ技術について開示されている。また、特開平１０−１７７６１０号公報には、複数の担当者における処理を規定して各担当者間でデータを受け渡すワークフローシステムにて、次の担当者に処理を割り付ける前に規定されたデータ変換を実行することで、各担当者にその業務処理の内容に応じて形式の異なる文書を送る等、業務処理の簡素化を図る技術について示されている。また、特開平５−２１６７３６号公報には、電子化された文書(伝票)の処理先が文書や発行者によって異なる場合に、組織を表現するディレクトリを参照することによって、処理すべき文書に依存した経路ルールと送付先を決定する技術について開示されている。
【０００４】
【発明が解決しようとする課題】
このように、従来のワークフローシステムでは、データの値によって回覧経路を動的に変更するために、個々の担当者をデータ参照により決定するような経路や、固定された外部のワークフロー定義を指定するような経路の定義は可能であった。しかしながら、担当部門を動的に指定するような業務は一般的ではあるものの、それぞれの部門内での回覧経路が部門毎に異なる場合や、その最大回覧部門数を考慮したワークフローを定義する必要があった。
【０００５】
また、担当者レベルの動的経路や、固定された外部経路と条件分岐を用いたワークフロー定義では、最大回覧部門数が大きくなればなるほど、その経路は複雑で巨大なものとなってしまい、フロー条件の組み合わせを考慮すると、正しい定義をすることさえ困難となる。例えば、ワークフローシステムの一つである電子帳票承認システムにおいて、稟議を回す場合に、多くの部門を並列に回し、全ての部門の承認をもって次の承認に進むケースがよくある。ところが、部門によって承認のパターンは様々な上に、案件によってどの部門に回すかが異なり、例えば、最大、数十部門を回す伝票も現われている。
【０００６】
更に、従来、文字や数値によるデータを定義し、そのデータの値を参照または設定するようなアクティビティを実現する画面を開発する場合に、専用の開発ツールなどを用いて画面入力項目とデータ名とを関連付ける作業が行われていた。しかしながら、例えば、上述のように数十部門を回すような伝票、および承認経路を設計する場合に、最大数の部門を想定してワークフローを設計する必要がある。そのため、その設計画面が巨大かつ複雑となり、ユーザオペレーションが複雑になるだけではなく、組織変更に対応するための設計変更のコストが多大となっていた。また、指定した担当者によって経路を切り替えるような複雑な動的変更をワークフローに加えるためには、専用のプログラムを開発し、ワークフローの途中で実行させる必要があった。
【０００７】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、例えば回覧経路が部門毎に異なる複数部門の回覧等、複雑なワークフローを、単純な定義によって実現することにある。
また他の目的は、ワークフローの途中で実行させるような専用のプログラムを開発しない場合であっても、複雑な経路パターンの組み合わせに対応させることにある。
【０００８】
【課題を解決するための手段】
かかる目的のもと、本発明は、経路定義において、ノードとしてプロジェクト変数を指定させることで、ダイナミックにサブ経路を変更する仕組みを実現しており、また、プロジェクト変数に配列型の変数を指定させることで、同期タイプの並列経路を１つのノードで多重化して扱うことを可能としている。即ち、本発明は、複数のコンピュータ端末が接続されるネットワークにおいて、ワークフローに従ってコンピュータ端末を利用する担当者の間でデータの受け渡しを行うワークフローシステムであって、コンピュータ端末に割り当てられる処理として、プロジェクト型の配列変数を指定させることが可能であり並列経路を多重化して扱うノードと、このノードの処理順を決定するためのパスとを定めたワークフロー定義およびこのワークフロー定義で参照されるデータ定義からなるプロジェクトを作成してワークフローを設計する設計手段と、作成されたプロジェクトを記憶する記憶手段と、記憶されたプロジェクトを読み出し、読み出されたプロジェクトを用いてワークフローの業務単位であるプロセスを作成してコンピュータ端末に対して処理を割り当てる管理手段とを備えたことを特徴としている。
【０００９】
ここで、このデータ定義では、データとしてプロジェクト型およびその配列が定義されることを特徴としている。また、記憶手段に記憶されるプロジェクトは、定義ＩＤによって識別されることを特徴とすることができる。更に、配列の個々の要素が異なる種類のプロジェクトを扱ってワークフローを設計することを特徴とすれば、複雑な定義からなるワークフローを、プロジェクトを用いた極めてシンプルな定義によって提供できる点で好ましい。
【００１０】
他の観点から把えると、本発明が適用されるワークフローシステムでは、ネットワークに接続され、担当者の間でワークフローを実行するための操作用コンピュータ端末と、扱われる処理の単位であるノードに対して複数のプロセスを多重化するためのプロジェクト変数を指定して並列経路を多重化して扱うワークフローを設計する設計用コンピュータ端末と、設計されたワークフローを記憶手段に記憶すると共に、当該記憶手段に記憶された当該ワークフローを読み出し、ノードに割り当てられた処理であるアクティビティに対応して操作用コンピュータ端末にアクセスするワークフローサーバとを備えたことを特徴している。ここで「プロセス」とは、ワークフローの業務単位であり、例えば、「８月業務報告」と「９月業務報告」とは異なるプロセスであるが、同じ「業務報告」というプロジェクトとなる。従って、この場合、経路パターンは同じであるが、データの内容が異なってくる。これは、同じプロジェクトで異なるプロセスの例だが、ノードで多重化されるプロセスは、異なるプロジェクトの異なるプロセスであっても良い。
【００１１】
ここで、このプロジェクト変数は、ノードとこのノードの処理順を決定するためのパスとを定めたワークフロー定義およびこのワークフロー定義で参照されるデータ定義とを用いて指定されることを特徴とすれば、例えば、経路やフィールド定義といったリソースを決定する際に有用となる。
また、このプロジェクト変数は、自己を識別するための定義ＩＤを属性として定義され、このワークフローサーバは、この定義ＩＤを用いてプロジェクト変数に関する情報を記憶することを特徴とすれば、プロジェクトで別のプロジェクトの経路やフィールドといったリソースを再利用する際にも、プロジェクトを一意に選定できる点で好ましい。
更に、操作用コンピュータ端末は、割り当てられた処理の実行後にアクティビティの終了をワークフローサーバに通知し、ワークフローサーバは、ワークフローによる全てのアクティビティを終了した後にプロセスを完了することを特徴としている。
【００１２】
一方、本発明は、ワークフローを実行する複数のコンピュータ端末に対してネットワークを介して接続されるワークフローサーバ等の情報処理装置であって、プロジェクト型の配列変数を指定させることが可能であり並列経路を多重化して扱う複数のノードとそれらを結ぶパスとで構成されたワークフロー定義およびこのワークフロー定義で参照されるデータ定義を含めたプロジェクトを記憶する記憶手段と、この記憶手段に記憶されるプロジェクトを読み出し、読み出されたプロジェクトを一意に定める定義ＩＤを用いて管理するプロジェクト管理手段と、管理されるこのプロジェクトを用いてワークフローの業務単位であるプロセスを管理するプロセス管理手段と、管理されるプロセスに基づいてコンピュータ端末に対してアクセスするユーザ管理手段とを備えたことを特徴としている。
【００１３】
また、本発明は、ネットワークに接続された複数のコンピュータ端末によるワークフローを定義するコンピュータ端末等からなる情報処理装置であって、ワークフローの実行担当者のコンピュータ端末に対して割り当てられる業務であるノードを選定させ、ノードについて並列経路を多重化して扱うと共に、このノードの処理順を決めるパスをつないでワークフロー定義を決定させるワークフロー定義決定手段と、選定されたノードの実行ユーザを定義すると共に、パスが有効となる条件を定義させるデータ定義手段と、決定されたワークフロー定義および定義されたデータ定義に対し、これらを特定できる情報として、例えば、ワークフロー定義とデータ定義とをまとめた単位であるプロジェクトに対して、これを一意に特定できる定義ＩＤを付加して記憶手段に登録させる登録指示手段とを備えたことを特徴としている。
【００１４】
更に、本発明が適用されるワークフロー定義格納方法は、ネットワークに接続された複数のコンピュータ端末に対して割り当てられる業務であるノードの１つとしてプロセス、経路パターンおよびデータセットを多重化するためのプロジェクト配列型ノードの選定を受け付け、選定を受け付けたノードおよび選定されるプロジェクト配列型ノードを経路(パス)を用いて連結した状態にて、プロジェクト配列型ノードに配列されるプロジェクトを記憶手段に格納することを特徴としている。
【００１５】
ここで、このプロジェクトは、複数のノードとそれらを結ぶパスで構成されたワークフロー定義、およびワークフローの業務単位であるプロセスで設定および参照できるデータの定義であるデータ定義をまとめた単位であることを特徴とすることができる。また、この選定されるプロジェクトは、配列の個々の要素が異なる種類のプロジェクトであることを特徴とすれば、配列型の変数を指定させることで、並列経路を１つのノードで多重化することができる点で好ましい。
【００１６】
他の観点から把えると、本発明は、ネットワークに接続された複数のコンピュータ端末にて実行されるワークフロー定義方法であって、データセットと経路とを統一して扱えるプロジェクト型変数からなるノードをワークフローの１つのノードとして導入し、プロジェクト型変数を配列として指定することで、同期的に分岐される複数の子プロセス(サブプロセス)を１つのノードとして扱うことを特徴としている。
ここで、このプロジェクト型変数には、明示的な設定がない場合に適用されるプロトタイプを設定することを特徴とすることができる。また、ここで用いられる「子プロセス(サブプロセス)」は、例えば、経路パターンとデータセットの両方を意味するものとすることができる。
【００１７】
一方、本発明は、コンピュータに実行させるプログラムをコンピュータの入力手段が読取可能に記憶した記憶媒体であって、このプログラムは、ネットワークに接続された複数のコンピュータ端末に対して割り当てられる業務であるノードの１つとしてプロセスを多重化するためのプロジェクト配列型ノードの選定を受け付ける処理と、選定を受け付けたプロジェクト配列型ノードをパスを用いて連結した状態にて、プロジェクト配列型ノードに配列されるプロジェクトを記憶手段に格納する処理とをコンピュータに実行させることを特徴としている。ここで、このプロジェクトは、配列の個々の要素が異なる種類のプロジェクトとして記憶手段に格納されることを特徴とすることができる。また、複数のノードとそれらを結ぶパスで構成されたワークフロー定義、およびワークフローの業務単位であるプロセスで設定および参照できるデータの定義であるデータ定義をまとめた単位として記憶手段に格納されることを特徴とすることができる。
【００１８】
また、他の記憶媒体に格納されるプログラムでは、データセットと経路とを統一して扱えるプロジェクト型変数からなるノードをワークフローの１つのノードとして導入する処理と、プロジェクト型変数を配列として指定することで、同期的に分岐される複数の子プロセスを１つのノードとして扱う処理とをコンピュータに実行させることを特徴としている。これらの記憶媒体としては、例えば、ＣＤ−ＲＯＭ等の媒体が該当する。
【００１９】
更に、本発明が適用されるプログラム伝送装置は、コンピュータに、ワークフローの実行担当者に対して割り当てられる業務であるノードを選定する処理と、選定されるノードの１つとしてプロセス、経路パターンおよびデータセットを多重化するためのプロジェクト配列型ノードを選定する処理と、ノードおよびプロジェクト配列型ノードを経路を用いて接続する処理と、プロジェクト配列型ノードに配列されるプロジェクトを選定する処理とを実行させるプログラムを記憶する記憶手段と、この記憶手段からプログラムを読み出してプログラムを送信する送信手段とを備えている。
【００２０】
更にまた、本発明が適用されるプログラム伝送装置は、コンピュータに、データセットと経路とを統一して扱えるプロジェクト型変数からなるノードをワークフローの１つのノードとして導入する処理と、プロジェクト型変数を配列として指定することで、同期的に分岐される複数の子プロセスを１つのノードとして扱う処理とを実行させるプログラムを記憶する記憶手段と、この記憶手段からプログラムを読み出して送信する送信手段とを備えることを特徴としている。
【００２１】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
まず、具体的な説明に入る前に、本実施の形態にて用いられる主要な用語について以下に列挙して説明する。
・ワークフロー定義
複数のノードとそれらを結ぶパスで構成された定義。
・ノード
ワークフロー定義で扱う処理定義の単位。実際の処理者とデータ入力画面が割り当てられる。
・データ定義
プロセスで設定および参照できるデータの定義。データの名称、型、配列かどうかを定義する。型には、文字列型や数値型がある。
・データ属性定義
データが保持する値を制限する属性の定義で、データ定義の一部である。文字型データに対する属性には文字数の制限などが、数値型データに対する属性には範囲指定などがある。
・プロジェクト
ワークフロー定義とデータ定義をまとめた単位。プロセス定義と等価である。プロジェクトは定義ＩＤで識別され、プロジェクトが決定されると、そのワークフロー定義とデータ定義も決定される。
・プロセス
ワークフローの業務単位。プロジェクトを具現化したもの。プロセスは、その元となるプロジェクトのワークフロー定義で示される経路パターンに沿って業務が流れる。また、データ定義で示されるデータセットは、個々のプロセスで異なる内容を記憶する。
・アクティビティ
ノードに割り当てられた処理。処理者が割り当てられていれば、担当者の処理になる。
【００２２】
次に、本実施の形態における具体的な説明に入る。
本実施の形態の理解を容易にするために、まず、適用事例を用いて説明する。
図１８(ａ),(ｂ)は、ワークフロー設計者および伝票起票者による操作の一例を示した図であり、本実施の形態が適用される単純な例を示している。
同じ経路パターンの多重化の場合、図１８(ａ)に示すように、ワークフローの設計者は、あるノードの設定としてプロジェクト型の配列変数ＰＲＪ[ ]を参照するように指定する。ここに、ＰＲＪのプロトタイプ属性(明示的な設定がない場合に採用されるもの)として、プロジェクトの定義ＩＤ“bumon_prj”を設定する。図１８(ａ)に示される「Project＝Field(ID)＋サブ経路：bumon」の表現では、「プロジェクト型データを参照するノードでは、そのアクティビティとして、参照されたプロジェクトの定義を使って子プロセスを生成・実行している。また、同じbumonというプロジェクトを使った子プロセスを生成・実行する場合でも、各子プロセスのＩＤという名前のデータを別々に設定することで、異なるユーザ(もしくは部門)に回覧できる。」という意味を示している。
【００２３】
図１８(ｂ)に示すように、伝票を起票するユーザは、その時点にてダイナミックに承認すべき部門のＩＤ(soumu,keiri,eigyou)を入力する。図１８(ｂ)に示すＩＮＰＵＴタグによって、これらは変数ＰＲＪの各配列要素における変数ＩＤに関連付けられている。データ値が代入される場合、プロジェクトのプロトタイプ属性としてbumon_prjが設定されているので、このノードのアクティビティとしてプロジェクト定義ＩＤ(bumon_prj)のプロジェクトを使って作成された子プロセスが設定され、この子プロセス内のデータである変数ＩＤに値が設定される。業務処理として、伝票が処理されるとき、このノードの設定はプロジェクト型の配列を参照するよう設定されていることから、配列要素の数だけ子プロセスが生成され、並列に処理される。経路は、プロジェクトbumon_prjで定義されたものが利用され、先頭のノード設定がデータ参照指定でＩＤという名前のデータを参照するように設定されているので、それぞれＩＤ＝“soumu”、ＩＤ＝“keiri”、ＩＤ＝“eigyou”が評価される。そして、それぞれの部門に送付され、その部門での担当者が承認をする。これによって、一連のワークフローを実現することが可能となる。
【００２４】
一方、異なる経路パターンの多重化の場合、ワークフロー設計者は、同様に、あるノードの設定としてプロジェクト型の配列変数ＰＲＪ[ ]を参照するように指定する。次に、伝票を起票するユーザは、その時点でダイナミックに承認すべき部門用のプロジェクトの定義ＩＤ(soumu_prj,keiri_prj,eigyou_prj)を入力する。ＩＮＰＵＴタグによって、これらは変数ＰＲＪの各配列要素に別々のプロジェクトとして設定される。この伝票が処理されるとき、このノードではプロジェクト型の配列を参照するように設定されていることから、配列要素の数だけ子プロセスが生成され、並列に処理される。このとき、それぞれ異なるプロジェクトＩＤ(soumu_prj,keiri_prj,eigyou_prj)が評価され、異なる種類の子プロセスが設定される。経路は、それぞれのプロジェクトで定義されたものが利用され、別々の経路を用いてそれぞれの部門に送付されて、その部門での担当者が承認する。各子プロセスは、同期されて次のノードに進む。このようにして、異なる経路パターンを多重化したワークフローが実現される。
尚、ここで示したフローの本質的な経路設計を含む親プロジェクトは、同じ経路パターンの多重化の場合と異なる経路パターンの多重化の場合で同じとすることが可能である。
【００２５】
このように、本実施の形態では、ワークフロー定義やデータ定義、表示形式、関連プログラムなどの複数のリソースから構成されるアプリケーションの構成単位をプロジェクトと呼び、このプロジェクトという概念において、ワークフロー定義内のノードなどの要素やデータ定義で定義された変数名といったリソースの名前空間を一意に決定するために、プロジェクト名等からなるプロジェクトＩＤを採用している。また、このプロジェクトで、別のプロジェクトのワークフロー定義やデータ定義といったリソースを再利用するために、プロジェクト型のデータという概念を導入している。ワークフロー定義上のノードの設定としてこのプロジェクト型データを参照するように指定することで、いわゆる「子プロセス」を実現している。更に、プロジェクト型データを配列型と定義することで、並列な子プロセスを実現している。これらの概念によって、子プロセスや子プロセス内のデータに対して柔軟な制御が可能となる。
【００２６】
次に、本実施の形態を全体システム構成から順に詳述していく。
図１は、本実施の形態が適用されたワークフローシステムの概略構成を示す図である。本実施の形態におけるワークフローシステムは、ワークフローの設計のための設計用コンピュータ端末１０、業務を遂行する担当者に対応して設けられたワークフローの操作用コンピュータ端末２０、ワークフローを実行するための各種プログラムが格納されるワークフローサーバ３０とを備えている。この設計用コンピュータ端末１０、操作用コンピュータ端末２０、およびワークフローサーバ３０は、それぞれ接続されてネットワークを形成している。
【００２７】
設計用コンピュータ端末１０は、ワークフローの設計機能が導入されており、業務処理をワークフローシステムで実現するための定義機能を備えている。業務処理の定義を行うユーザは、この設計用コンピュータ端末１０を用いて業務処理手順をワークフローシステムに定義する。操作用コンピュータ端末２０は、予め指定された業務を実行する機能があり、複数の業務担当者が操作できるように配置されている。
【００２８】
設計者は、設計用コンピュータ端末１０を用いて、自己の識別情報を入力してワークフローシステムに接続する。また、設計者は、ワークフロー設計機能を用いて、対象業務における処理の流れと処理で用いられるデータ構造とを設計する。
図２(ａ),(ｂ)は、対象業務における処理の流れを示したプロジェクト(プロセス定義)を示した図であり、図２(ａ)はワークフロー定義の一例を示し、図２(ｂ)はこのワークフロー定義で参照されるデータ定義の一例を示している。図２(ａ)において、丸印はノードと呼ばれ、担当者(業務担当者)に割り当てられる業務を示している。矢印はパスと呼ばれ、業務処理の順番、即ち、処理の繋がりを示している。本実施の形態では、全てのノードにて単一のデータ定義が参照され、各処理間で必要となるデータの受け渡しも矢印で示されるパスに従うと仮定している。しかしながら、複数のデータ定義が存在し、異なるデータの受け渡しがパスで定義されていても構わない。図２(ｂ)では、ユーザＩＤ(UserＩＤ)、名前(Name)として“String(文字列型)”が定義され、アドレス(Address)として“String[]”、Ageとして“Integer(数値型)”が定義されている。
【００２９】
設計用コンピュータ端末１０を用いている設計者は、設計ツールを用いてノードを並べ、処理順を決めるためにパスを繋いでいく。ノードおよびパスに対して、その属性を規定することができる。ノードの属性としては、ノードの名前および担当者となる実行ユーザを定義する。実行ユーザの割り当てタイプには、ユーザＩＤを直接入力する直接指定、他の処理ユーザとの関係(例えば、ノードＡ(NodeＡ)の処理ユーザの上司など)で示した関係指定、および、図２(ｂ)で示したようなデータ定義で定義されるデータの値を処理ユーザとするデータ参照指定がある。パスの属性としては、そのパスが有効となる条件を定義する。このようにして設計用コンピュータ端末１０にて作成されたプロジェクトは、ワークフローサーバ３０に登録される。このとき、プロジェクトを一意に特定することができる定義ＩＤが付加されて登録される。プロジェクトから作成される個々の業務フローがプロセスであり、このプロセスを形成する担当者ごとの処理がアクティビティとなる。
【００３０】
各担当者は、操作用コンピュータ端末２０を用い、自己の識別情報を入力してワークフローシステムに接続する。担当者は、図２(ａ)に示したようなワークフロー定義を参照して、新たにプロセスを作成したり、自分に割り当てられているアクティビティを表示して、指定されている処理を実行する。各担当者の処理は、図２(ａ)のワークフロー定義の１つであるノードに対応している。担当者の処理が終了すると、ワークフロー定義のパスに従って次の担当者の処理が割り当てられる。
【００３１】
図３は、ワークフローサーバ３０の概略構成を示した説明図である。本実施の形態におけるワークフローサーバ３０は、管理手段として、プロジェクト管理プログラム３１、プロセス管理プログラム３２、クライアント要求管理プログラム３３、およびユーザ管理プログラム３４を備えている。また、記憶手段として、ワークフロー定義記憶部３５、データ定義記憶部３６、プロセス記憶部３７、ワークフロー状況記憶部３８、およびユーザ情報記憶部３９を備えているが、これらの記憶手段はネットワーク内のどこに存在していても構わない。
【００３２】
プロジェクト管理プログラム３１は、設計用コンピュータ端末１０にて設計者が定義したプロジェクトのワークフロー定義とデータ定義とに関するデータをワークフロー定義記憶部３５およびデータ定義記憶部３６に保存して管理する。それぞれのプロジェクトは、定義ＩＤによって識別されている。新たな定義の登録、および既に存在している定義の修正は、全てプロジェクト管理プログラム３１を通じて、定義ＩＤを用いて管理する。また、担当者が新規プロセスを作成する際には、その担当者が作成できるプロセスの一覧を、プロジェクト管理プログラム３１がワークフロー定義記憶部３５とデータ定義記憶部３６とに格納されたデータを用いて作成する。
【００３３】
プロセス管理プログラム３２は、プロジェクトの定義を用いて作成されたプロセスの管理を行う。プロセスは、定義ＩＤと、同じ定義から作成された複数のプロセスを識別するためのプロセスＩＤとを有し、この定義ＩＤとプロセスＩＤとの組み合わせで管理されている。また、プロセス記憶部３７には、現在実行中のアクティビティ、アクティビティを実行している若しくは実行すべき担当者(実行ユーザを含む)、プロセスで用いられているデータが保管されている。これらの情報をもとに、アクティビティの終了時に次の担当者の割り当てが行われる。プロセス管理プログラム３２は、プロセスの作成、アクティビティの割り当て、プロセスの完了といったイベントが発生する度に、その状況をワークフロー状況記憶部３８に書き込んでいる。
【００３４】
クライアント要求管理プログラム３３は、操作用コンピュータ端末２０を用いる担当者の要求を受け付ける機能を有している。また、担当者に現在、割り当てられている(実行ユーザが担当者になっている)アクティビティの一覧を提供したり、担当者のアクティビティ終了要求を受け付ける機能を備えている。また、ワークフロー状況記憶部３８に残された情報を用いてプロセスの処理状況を提供している。
【００３５】
ユーザ管理プログラム３４は、ワークフローシステムに参加できる担当者のコントロールを行っている。そのために、ユーザ情報をユーザ情報記憶部３９に登録しておき、必要に応じてアクセスしている。新たなユーザが操作用コンピュータ端末２０を用いてシステムに接続しようとする場合には、ユーザの入力したＩＤおよびパスワードのチェックが行われる。また、ユーザ情報記憶部３９には、ユーザの属する組織や、組織の階層構造、ユーザの上司関係、ユーザの権限区分等の情報が保存されている。これらの情報は、プロセス管理が次のアクティビティに対して担当者を割り当てる際に参照される。参照される情報は、例えば、図２(ａ)に示されるようなワークフロー定義のノードの属性によって異なっている。
【００３６】
次に、本実施の形態におけるワークフローシステムの動作について説明する。
図４(ａ),(ｂ)は、登録済みプロジェクトの一例を示した図である。ここでは、プロジェクト「定義Ａ」と、プロジェクト「定義Ｂ」とが事前に登録されていると仮定している。それぞれのプロジェクトは、前述したように、ワークフロー定義とデータ定義とをまとめた単位として登録されている。
図４(ａ)に示すプロジェクト「定義Ａ」では、それを用いたプロセスを開始すると、まずノードＡ(NodeＡ)に対応したアクティビティの担当者が、プロセスのデータUserＩＤに代入されている人に割り当てられる。そのアクティビティが終了すると、ノードＢ(NodeＢ)に対応したアクティビティが、ノードＡのアクティビティを実行したユーザの上司に割り当てられる。
【００３７】
図４(ｂ)に示すプロジェクト「定義Ｂ」において、それを用いたプロセスを開始すると、まずノードＡ(NodeＡ)に対応したアクティビティの担当者が、プロセスのデータUserＩＤに代入されている人に割り当てられる。そのアクティビティが終了すると、ノードＣ(NodeＣ)のアクティビティの担当者が、プロセスのデータReviewer(検閲者)に代入されている人に割り当てられる。更に、ノードＢ(NodeＢ)に対応したアクティビティの担当者は、ノードＡのアクティビティを実行したユーザの上司に割り当てられる。
尚、プロジェクト「定義Ａ」は定義ＩＤとして“定義Ａ”を、プロジェクト「定義Ｂ」は定義ＩＤとして“定義Ｂ”を、それぞれ有している。
【００３８】
図５は、本実施の形態にて採用されたプロセス定義方法によって作成される定義の一例を示した図である。ここでは、まず、設計者が、図５に示す定義を設計用コンピュータ端末１０の設計ツールを用いて作成する。この例では、通常のノード５１および通常のノード５２との間に、プロジェクト配列型ノード５３が設けられている。図５のプロジェクト「定義Ｃ」のワークフロー定義におけるノードＢ(NodeＢ)と、データ定義におけるDepts が本実施の形態で採用される定義方法である。ノードＢのユーザ割り当ては、従来の定義と同じようにデータ参照となっているが、参照するデータのタイプはプロジェクト型の配列と定義されている。
【００３９】
このプロジェクト型の配列の要素には他のプロジェクトから作成されたプロセスがその値として代入される。但し、このDeptsはプロトタイプ属性として“定義Ａ”が与えられているため、明示的な定義ＩＤの設定がなければプロジェクト“定義Ａ”のプロセスが代入されることを示している。これらの定義から、このノードＢにおけるアクティビティが有効になると、プロジェクト型データDeptsが指すプロセスで置き換えられることを意味し、また配列で定義されている場合は、複数の別プロセスを同時にこのアクティビティとして開始することを意味している。定義されたプロジェクトはワークフローサーバ３０に送られ、プロジェクト管理プログラム３１を経てワークフロー定義記憶部３５とデータ定義記憶部３６とに保存される。ここでは、定義ＩＤとして“定義Ｃ”を与えて保存したと仮定する。
【００４０】
本実施の形態におけるワークフローシステムにて、例えば、担当者Ａが新規の業務フローとして図５のプロジェクト「定義Ｃ」を用いて新たなプロセスを作成する場合、新規作成要求がワークフローサーバ３０のクライアント要求管理プログラム３３に送られる。要求を受け取ったクライアント要求管理プログラム３３は、プロセス管理プログラム３２に新規プロセスの作成を要求する。そして、プロセス記憶部３７内に、定義ＩＤとして“定義Ｃ”が、プロセスＩＤとして“Ｃ００１”が設定され、新たなプロセスとして作成されて保存される。
【００４１】
図６は、プロセス記憶部３７における状態の一例を示した図である。プロセス記憶部３７内における個々のプロセスは、定義ＩＤとプロセスＩＤとの組み合わせで識別されるため、この識別表現として“定義Ｃ：Ｃ００１”のように記述される。また、このプロセスの開始要求も同様にクライアント要求管理プログラム３３を経てプロセス管理プログラム３２に送られ、アクティビティとして“NodeＡ”が、実行ユーザとして“担当者Ａ”が設定される。
【００４２】
図６に示す状態で、担当者Ａが操作用コンピュータ端末２０を用いてワークフローシステムに接続すると、実行ユーザとして自分に割り当てられた“定義Ｃ：Ｃ００１”におけるアクティビティ“NodeＡ”を知ることができる。担当者Ａが更に端末からこのアクティビティの開始を要求すると、関連付けられたプログラムが起動され、担当者Ａは処理画面を得ることができる。
【００４３】
図７は、担当者が得るワークフロー操作の処理画面の一例を示した図であり、図８は、クライアント要求管理プログラム３３に送られるデータを示した図である。ここでは、代入先データ名毎に対応する設定値が定められている。図７に示す処理画面には、プロジェクト「定義Ｃ」のデータ定義で定義されたデータ構造に対するデータ入力域が設けられている。この図７の例では、ラベル「名前：」および「課題：」で示されるテキスト入力域が、図８に示すように、それぞれプロジェクト「定義Ｃ」のデータ構造における代入先データ名“Name”および“Subject”に関連付けられている。また、図７に示す「回覧先：」というラベルで示されたテーブルの１行目の１カラム目が、図８に示す“Depts[1]”に関連付けられ、２カラム目が“Depts[2].UserID”というデータ名に関連付けられている。２行目以降も同様に“Depts[n]”と“Depts[n].UserID”というデータ名に関連付けられている。但し、図５にて説明したように、この例では、プロトタイプ属性として“定義Ａ”が与えられているため、明示的な定義ＩＤの設定がない“Depts[1]”および“Depts[2]”では、プロジェクト“定義Ａ”のプロセスが代入される。担当者Ａがこの操作画面で図７に示すように入力して処理を確定した場合、その情報は、図８に示すような形式でワークフローサーバ３０のクライアント要求管理プログラム３３に送られる。
【００４４】
図９は、クライアント要求管理プログラム３３にて実行されるデータ設定の評価手順を示すフローチャートである。ここでは、図７で示した入力画面における「回覧先：」の１行目のデータ設定を例にとって説明する。ここでは、予め入力画面で入力項目に割り当てられた代入先データ名は、“Depts[1].UserID”であり、入力された値“総務”が設定値となる。これは図８の３行目に相当する設定項目である。
【００４５】
まず、クライアント要求管理プログラム３３がこの値を設定する要求を受け取ると、現在のプロセス“定義Ｃ：Ｃ００１”を「親プロセス」として評価ロジックが呼び出される(ステップ１０１)。そして、「評価データ名」に代入先データ名の最初のデータ名部分を設定し(ステップ１０２)、「INDEX」に代入先データ名における最初のデータ名の配列添え字部分を設定し(ステップ１０３)、「残りフレーズ」に代入先データ名から評価データ名とINDEXを除いた部分を設定する(ステップ１０４)。ここでは、代入先データ名が“Depts[1].UserID”であることから、「評価データ名」として“Depts”、「INDEX」として“[1]”、「残りフレーズ」として“UserID”が得られる。
【００４６】
次に、親プロセスにおいて、評価データ名のデータが定義されているか否かが判断される(ステップ１０５)。定義されていない場合には、データ定義で定義されていないデータに値を設定しようとしたものとして、エラーとなる(ステップ１０６)。ステップ１０５にて定義されている場合には、「評価データ」に親プロセス内で評価データ名を持つデータが設定される(ステップ１０７)。このプロセスのプロジェクト「定義Ｃ」のデータ定義では“Depts”が定義されていることから、その値が「評価データ」とされる。
【００４７】
次に、評価データの型がプロジェクト型か否かが判断される(ステップ１０８)。プロジェクト型ではない場合には、評価データのINDEX要素に設定値が代入される(ステップ１０９)。プロジェクト型である場合には、残りフレーズが空ではないか否かが判断される(ステップ１１０)。前述した例では、ステップ１０６の「評価データ」である“Depts”は、「定義Ｃ」のデータ定義において“Project[]”と定義されているので、プロジェクト型の配列であることがわかる。また、「残りフレーズ」には“UserID”が設定されているため空ではない。
【００４８】
ステップ１１０にて、「残りフレーズ」が空ではない場合には、「評価データ」がまだプロセスを指していないか否かが判断される(ステップ１１１)。この例で「評価データ」がプロセスを指しているかどうかを確認すると、図６で“定義Ｃ：Ｃ００１”のデータを見れば、この状態ではまだプロセスは指していないことが解かるので、プロトタイプ属性の確認に移る。即ち、評価データにプロトタイプ属性が定義されているか否かが判断される(ステップ１１２)。定義されていない場合には、プロトタイプ属性が定義されていないデータの内部データに対し、定義ＩＤを設定しないで直接、アクセスしようとしたものとして、エラーとなる(ステップ１１５)。この例では、「評価データ」である“Depts”は、「定義Ｃ」のデータ定義においてプロトタイプ属性が“定義Ａ”と定義されている。そこで、定義ＩＤにプロトタイプ属性を設定し、プロセスを作成し、また、評価データのINDEX要素が作成したプロセスを指すように設定する(ステップ１１３)。即ち、定義ＩＤが“定義Ａ”であるプロジェクトからプロセスが作成され、プロセス記憶部３７の中に、“定義Ａ”および“Ａ００１”を識別子として有するプロセスが保存される。また、「評価データ」の「INDEX」要素である“Depts[1]”には、そのプロセスを指すように“定義Ａ：Ａ００１”が設定される。
【００４９】
次に、親プロセスに「評価データ」の「INDEX」要素が指すプロセスを設定し、代入先データ名に残りのフレーズを設定する(ステップ１１４)。この例では、「親プロセス」を「評価データ」の「INDEX」要素“Depts[1]”が指すプロセス“定義Ａ：Ａ００１”に設定し、「代入先データ名」に「残りフレーズ」“UserID”を設定する。その後、ステップ１０２にジャンプする。ステップ１１１にて、評価データがプロセスを指している場合には、直接、ステップ１１４へ移行する。
【００５０】
更に評価を進めると、「評価データ名」として“UserID”が得られ(ステップ１０２)、「INDEX」として“”（空文字）が得られ(ステップ１０３)、「残りフレーズ」として“”（空文字）が得られる(ステップ１０４)。このプロセスのプロジェクト「定義Ａ」のデータ定義では“UserID”が定義されているので(ステップ１０５)、その値を「評価データ」とする(ステップ１０７)。 この「評価データ」の「INDEX」要素である“UserID”は、「定義Ａ」のデータ定義において“String”と定義されているので文字型であってプロジェクト型ではないことがわかる(ステップ１０８)。したがって、最終的に「親プロセス」か否かを示すプロセス“定義Ａ：Ａ００１”のデータ“UserID”に、設定値“総務”が設定される(ステップ１０９)。
【００５１】
ステップ１１０にて、残りフレーズが空である場合には、「評価データ」がまだプロセスを指していないか否かが判断され(ステップ１１６)、指していない場合には、定義ＩＤに設定値を設定し、プロセスを作成し、「評価データ」の「INDEX」要素が作成したプロセスを指すように設定する(ステップ１１７)。ステップ１１６にてプロセスを指している場合に、「評価データ」の定義ＩＤが設定値と等しい場合には(ステップ１１８)、既に設定されている定義ＩＤとは異なる定義ＩＤを設定しようとしたものとしてエラーとなる。
【００５２】
図１０は、図８に示される全てのデータを評価した結果として、プロセス記憶部３７にて得られる状態の一例を示した図である。ここでは、プロジェクトを識別するための定義ＩＤ、プロセスＩＤ、親プロセス、アクティビティ、実行ユーザ、データ、子プロセス数の各項目に対して、対応する評価結果を得ることができる。例えば、担当者Ａがアクティビティの処理を終了したとき、終了要求がワークフローサーバ３０のクライアント要求管理プログラム３３に送られる。クライアント要求管理プログラム３３は、プロセス管理プログラム３２を呼び出し、“定義Ｃ：Ｃ００１”のプロセスをプロセス記憶部３７から取り出し、プロジェクト「定義Ｃ」のワークフロー定義をワークフロー定義記憶部３５から取り出してフロー評価を行う。
【００５３】
図１１は、本実施の形態におけるフロー評価手順を示したフローチャートである。このフロー評価手順では、図１０に示すようなプロセス記録部３７の状態から、まず、子プロセス数が０か否かが判断され (ステップ２０１)、０でない場合には、評価手順の処理は終了する。子プロセス数が０である場合には、アクティビティ名を取得する(ステップ２０２)。ここで、アクティビティ名が空か否かが判断され(ステップ２０３)、空でない場合には、アクティビティ名を起点とするパスをワークフロー定義記憶部３５から検索する(ステップ２０４)。
【００５４】
次に、アクティビティ名を起点とするパスが存在しているか否かが判断され(ステップ２０５)、存在していない場合には、完了処理が実行されて(ステップ２０６)、処理が終了する。アクティビティ名を起点とするパスが存在する場合には、パスの終点ノードに指定されているノードをフロー定義から検索し(ステップ２０７)、検索されたノードの指定内容により実行ユーザＩＤを特定する(ステップ２０８)。ステップ２０３でアクティビティ名が空である場合には、ワークフロー定義記憶部３５から先頭になるアクティビティ名を検索し(ステップ２０９)、ステップ２０８に移行する。このステップ２０８の後に、ノードをプロセスのアクティビティに、特定したユーザＩＤを実行ユーザＩＤにセットする(ステップ２１０)。そして、マッチした経路がまだあるか否かが判断され(ステップ２１１)、まだある場合には、プロセスを複製して(ステップ２１２)、ステップ２０７に戻り、マッチした経路がない場合には、フロー評価手順の処理が終了する。
【００５５】
図１２は、本実施の形態における実行ユーザ割り当て手順を示したフローチャートである。まず、割り当てタイプを取得し(ステップ３０１)、直接指定か否かが判断される(ステップ３０２)。直接指定である場合には、定義で指定されたユーザを取り出し(ステップ３０３)、実行ユーザ割り当て手順の処理が終了する。直接指定でない場合には、関係指定か否かで手順が異なる(ステップ３０４)。関係指定である場合には、指定された関係を取り出し(ステップ３０５)、関係を使ってユーザ情報を検索し(ステップ３０６)、関係を満たすユーザを取得して(ステップ３０７)、実行ユーザ割り当て手順の処理が終了する。
【００５６】
ステップ３０４で関係指定でない場合には、データ参照か否かが判断され(ステップ３０８)、データ参照でない場合には、実行ユーザ割り当て手順の処理が終了する。データ参照である場合には、指定されたデータの型をチェックするが(ステップ３０９)、データの型がプロジェクト型であるか否かでその後の処理が異なる(ステップ３１０)。即ち、プロジェクト型である場合には、データで示される子プロセスを取得し(ステップ３１１)、子プロセス数にデータの要素数(開始する子プロセスの数)を代入する(ステップ３１２)。そして、全ての子プロセスに対してフロー評価を行ってプロセスを開始して(ステップ３１３)、一連の処理が終了する。一方、プロジェクト型でない場合には、データ値を取り出し(ステップ３１４)、データ値をユーザとして(ステップ３１５)、実行ユーザ割り当て手順の処理が終了する。
【００５７】
図１３は、本実施の形態における完了処理の手順を示したフローチャートである。完了処理では、まず、プロセスのアクティビティをクリアし(ステップ４０１)、実行ユーザをクリアする(ステップ４０２)。次に、親プロセスを持つ子プロセスかどうかがチェックされ(ステップ４０３、ステップ４０４)、子プロセスである場合には、親プロセスの子プロセスカウントを１つ減らし(ステップ４０５)、親プロセスのフロー評価を実行する(ステップ４０６)。最後に、プロセス記憶部３７から情報を削除して(ステップ４０７)、完了処理が終了する。子プロセスでない場合には、そのままプロセス記憶部３７から情報を削除して(ステップ４０７)、完了処理が終了する。
【００５８】
図１４は、図１１、図１２、図１３に示した処理を実行することによるプロセス記憶部３７の状態を示した図である。図１１〜図１３の処理によって、図１０の状態が図１４に示すように変更されている。この図１４に示す状態では、子プロセス“定義Ａ:Ａ００１”が“総務”というユーザＩＤを持った担当者に、子プロセス“定義Ａ:Ａ００２”が“経理”というユーザＩＤを持った担当者に、子プロセス“定義Ｂ:Ｃ００１”が“営業”というユーザＩＤを持った担当者に、それぞれ割り当てられている。即ち、３つの子プロセスが並列に実行されている。割り当てられたユーザが本実施の形態におけるワークフローシステムに接続すると、自分が実行ユーザになっているアクティビティが存在することが分かり、それを実行することが可能となる。また、例えば、“総務”というユーザＩＤを持った担当者がそのアクティビティを終了すると、プロセス“定義Ａ:Ａ００１”は、その上司に割り当てられる。
【００５９】
図１５は、今までの例における全体のプロセスフローを示した図である。このプロセスフローでは、図５にて示したプロジェクト「定義Ｃ」において、ノードＢ(NodeＢ)のアクティビティが有効になり、プロジェクト型データDepts[1]〜[3]が指すプロセスで置き換えられている。即ち、定義Ａの２つの経路と定義Ｂの経路とからなる並列経路が、１つのノードで多重化して扱われており、通常のノード５１と５２との間に、３つのサブ経路からなるノード類５４を実行させることができる。
【００６０】
図１６は、図７に示した「回覧先：」のデータとして、他のデータを指定した場合を示している。図８にて説明した場合と同様に、この図１６に示されるデータは、クライアント要求管理プログラム３３に送られる。ここでは、Depts[1]からDepts[4]まで、プロジェクト配列型のデータとして扱われる。また、Depts[1]およびDepts[2]は“定義Ｂ”、Depts[3]およびDepts[4]は“定義Ａ”と設定され、Depts[1].UserIDからDepts[4].UserIDまで、User１〜User４が設定されている。
【００６１】
図１７は、「回覧先：」として図１６を指定した場合の全体のプロセスフローを示した図である。ここでは、図５にて示したプロジェクト「定義Ｃ」において、ノードＢ(NodeＢ)のアクティビティが有効になり、プロジェクト型データDepts[1]〜[4]が指すプロセスで置き換えられている。即ち、定義Ａの２つの経路と定義Ｂの２つ経路とからなる並列経路が、１つのノードで多重化して扱われており、通常のノード５１と５２との間に、４つのサブ経路からなるノード類５５を実行させることができる。
【００６２】
以上、本実施の形態における処理をまとめると、本実施の形態では、データ定義で定義できるデータとして、プロジェクト型およびその配列を定義できるようにしている。また、プロジェクト型データは、属性として、プロトタイプ属性と呼ばれる、事前指定プロジェクトの定義ＩＤを指定することができる。プロセスを作成すると、そのプロセスが定義されているプロジェクトのデータ定義に従ってデータセットが作成されプロセス記憶部３７に記憶される。このようにして作成されたデータには、各ノードに関連付けられた画面を通して値を設定することができる。
【００６３】
プロジェクト型として定義されたデータには前述したように定義ＩＤが添えられている。プロジェクトの定義ＩＤを指定すると、そのデータには指定したプロジェクトのデータ定義に従った新たなデータセットが作成され、その後はその新たなデータを設定および参照することができる。特にプロジェクトの定義ＩＤを指定しなくても、プロトタイプ属性に定義ＩＤが設定されている場合は、そのプロトタイプ属性であるプロジェクトのデータ定義に従ったデータを初めて参照または設定した時点で自動的にデータセットを作成することが可能となる。従って、明示的に定義ＩＤを指定する必要はない。
また、配列データの場合には、必要な要素数だけプロジェクトの定義ＩＤを指定することで、1つのデータで複数のプロジェクトのデータを扱うことが可能となる。この配列データにおいてもプロトタイプ属性が設定されている場合は、値を初めて参照・設定した時点で、その配列要素に対して自動的にデータセットが作成される。
【００６４】
プロセス作成直後、もしくはアクティビティが終了すると、ワークフロー定義に従って次に有効となるノードを見つけ出す。この有効となるノードに個別の担当者が割り当てられている場合には、その担当者に処理を割り当てる。また、ノードにデータを参照するよう定義されていた場合は、そのデータが指し示す値を使って担当者を識別し、その担当者が処理を割り当てる。ただし、そのノードがプロジェクト型のデータを参照するよう定義されている場合は、そのデータが指し示す別のワークフロー定義から子プロセスを作成し、この子プロセス自体をこのノードのアクティビティとする。このとき、実際の処理担当者は、子プロセスの先頭ノードを評価して決定することが可能となる。更に、そのノードがプロジェクト型のデータを配列として記憶している場合には、その配列の要素すべてに対して子プロセスを作成し、その子プロセス自体をこのノードのアクティビティとすることができる。この配列を参照して作成された子プロセス群は、そのすべての子プロセスの完了をもって、親プロセスにおけるノードのアクティビティの終了とされる。
【００６５】
このように、本実施の形態によれば、経路定義において、ノードとしてプロジェクト変数を指定させることで、ダイナミックにサブ経路を変更することが可能となる。また、そのプロジェクト変数に配列型の変数を指定させることで、同期タイプの並列経路を１つのノードで多重化して扱うことができる。言い換えれば、本質的な経路定義では、ノードとして唯一プロジェクト変数を指定するだけなので、ユーザオペレーションを極めてシンプルにすることができ、組織変更などに簡単に対応することが可能となる。また、担当者である起票者が伝票上で承認先部門を指定するだけで、複数部門に並列に承認依頼ができる稟議用の伝票等の設計が容易となる。
【００６６】
尚、本実施の形態にて説明したワークフローを実行するプログラムは、記憶媒体に格納されて販売等に供されるが、この記憶媒体としては、これらの処理を実行するためのソフトウェアが格納された、例えばＣＤ−ＲＯＭ等の媒体が代表的なものである。また、プログラムをネット等を介してダウンロードする態様では、プログラムの伝送装置における媒体や、ダウンロードした後のハードディスク等の記憶媒体も含まれることは言うまでもない。これらの記憶媒体に格納されたプログラムは、入力手段としての、例えばＣＤ−ＲＯＭドライバによって読み取られることが可能である。また、プログラムの伝送装置では、例えば、インターネットに接続されたコンピュータ端末からのダウンロード要求に応じて、本実施の形態を実現可能なプログラムを供給できるインターフェイス手段(送信手段)を備えていれば良い。
【００６７】
【発明の効果】
以上説明したように、本発明によれば、複雑なワークフロー設計を単純な定義によって実現することが可能となる。
【図面の簡単な説明】
【図１】  本実施の形態が適用されたワークフローシステムの概略構成を示す図である。
【図２】  (ａ),(ｂ)は、対象業務における処理の流れを示したプロジェクト(プロセス定義)を示した図である。
【図３】  ワークフローサーバ３０の概略構成を示した説明図である。
【図４】  (ａ),(ｂ)は、登録済みプロジェクトの一例を示した図である。
【図５】  本実施の形態にて採用されたプロセス定義方法によって作成される定義の一例を示した図である。
【図６】  プロセス記憶部３７における状態の一例を示した図である。
【図７】  担当者が得るワークフロー操作の処理画面の一例を示した図である。
【図８】  クライアント要求管理プログラム３３に送られるデータを示した図である。
【図９】  クライアント要求管理プログラム３３にて実行されるデータ設定の評価手順を示すフローチャートである。
【図１０】  図８に示される全てのデータを評価した結果として、プロセス記憶部３７にて得られる状態の一例を示した図である。
【図１１】  本実施の形態におけるフロー評価手順を示したフローチャートである。
【図１２】  本実施の形態における実行ユーザ割り当て手順を示したフローチャートである。
【図１３】  本実施の形態における完了処理の手順を示したフローチャートである。
【図１４】  図１１、図１２、図１３に示した処理を実行することによるプロセス記憶部３７の状態を示した図である。
【図１５】  全体のプロセスフローを示した図である。
【図１６】  図７に示した「回覧先：」のデータとして、他のデータを指定した場合を示した図である。
【図１７】  「回覧先：」として図１６を指定した場合の全体のプロセスフローを示した図である。
【図１８】  (ａ),(ｂ)は、ワークフロー設計者および伝票起票者による操作の一例を示した図である。
【符号の説明】
１０…設計用コンピュータ端末、２０…操作用コンピュータ端末、３０…ワークフローサーバ、３１…プロジェクト管理プログラム、３２…プロセス管理プログラム、３３…クライアント要求管理プログラム、３４…ユーザ管理プログラム、３５…ワークフロー定義記憶部、３６…データ定義記憶部、３７…プロセス記憶部、３８…ワークフロー状況記憶部、３９…ユーザ情報記憶部
【図１】
0004299447.tif 000002
【図２】
0004299447.tif 000003
【図３】
0004299447.tif 000004
【図４】
0004299447.tif 000005
【図５】
0004299447.tif 000006
【図６】
0004299447.tif 000007
【図７】
0004299447.tif 000008
【図８】
0004299447.tif 000009
【図９】
0004299447.tif 000010
【図１０】
0004299447.tif 000011
【図１１】
0004299447.tif 000012
【図１２】
0004299447.tif 000013
【図１３】
0004299447.tif 000014
【図１４】
0004299447.tif 000015
【図１５】
0004299447.tif 000016
【図１６】
0004299447.tif 000017
【図１７】
0004299447.tif 000018
【図１８】
0004299447.tif 000019