JP2001014389A - ワークフローサーバおよびクライアント端末 - Google Patents

Abstract

(57)【要約】 【課題】 ビジネスプロセス定義を容易にしたワークフ
フローサーバおよびクライアント端末を提供する。 【解決手段】 ワークフローサーバ１が、ワークフロー
データベース３０の他に、ビジネスプロセスのコンポー
ネントとなる定義データを記憶するためのファイル１０
を有し、ファイル１０に蓄積されたデータセットのコン
ポーネント名称の一覧６０をクライアント端末画面に出
力し、ユーザが指定したコンポーネントについて、ファ
イル１０から対応する定義データを読み出し、上記クラ
イアント端末に出力するコンポーネント管理機能２０を
備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はワークフローシステ
ムに関し、特に、業務の流れを定義するためのビジネス
プロセス定義ツールを備えたワークフローサーバおよび
クライアント端末に関する。

【０００２】

【従来の技術】ワークフローシステムは、複数の人が時
系列的に関与するオフィス業務を効率的に処理するため
に開発された計算機ネットワークシステムであり、オフ
ィス業務において電子化文書の形式で発生する各案件の
流れを業務毎に予め定義しておくことによって、クライ
アント端末で処理された案件が、業務フロー(以下、ビ
ジネスプロセスと言う)に沿って次の担当者に自動的に
遷移されるようにしたものである。

【０００３】ワークフローシステムは、例えば、ＬＡＮ
に代表される通信ネットワークによって相互接続された
複数のクライアント端末と、上記通信ネットワークを介
して各クライアント端末と交信するワークフローサーバ
とからなり、上記ワークフローサーバが、各ビジネスプ
ロセスを予め定義したプロセス管理テーブルを備え、各
クライアント端末で起案された新たな案件（電子化文
書）、あるいは他のユーザから転送されてクライアント
端末で追加処理された案件をビジネスプロセスに沿った
次のステップに自動的に遷移させる。

【０００４】ビジネスプロセスは、ノードと呼ばれる複
数のステップからなり、業務内の各処理単位は、アクテ
ィビティ（Activity）と呼ばれるノードで定義される。
各Activityに付随して、例えば、その処理の担当者（以
下、Participantと記述する）と、処理を実行するため
の必要なアプリケーション・プログラム（以下、Applica
tionと記述する）とが定義される。ビジネスプロセスの
構成ノードとしては、上記Activityの他に、プロセスの
開始、終了ノードと、案件の分岐点や合流点を示すため
の制御ノードが含まれる。

【０００５】各ビジネスプロセスの定義は、サーバまた
はクライアント端末の表示画面において、開始ノードと
終了ノード間に配列された複数のノードシンボル間を案
件の流れを示すアロー記号で結合し、各Activityノード
に関して、それぞれのParticipantとApplicationを定義
することによって達成される。

【０００６】現在市販されているワークフローシステム
の機能に関しては、例えば、「オペレーションズリサー
チ」誌、1996、10月号の第559頁-第568頁に「ワークフ
ロー管理システムの有効性」と題して紹介されている。
従来製品の中には、例えば、ユニシス社のワークフロー
システム「Staffware」のように、ツールボックスから
アイコンを選択し、ドラッグ＆ドロップして必要項目を
入力するようにした、グラフィカル・ワークフロー・デ
ファイナー（ＧＷＤ）機能を備えたものも知られてい
る。

【０００７】

【発明が解決しようとする課題】然るに、従来のワーク
フローシステムでは、新たなビジネスプロセス定義が必
要となった時、ビジネスプロセスを構成する全てのノー
ドを新たに定義するか、あるいは、既存のビジネスプロ
セス定義全体をコピーし、その一部に変更を加え、出来
上がったビジネスプロセスに新たなプロセス名を与えて
登録すると言う手法が採用されている。このため、従来
の方法では、新規ビジネスプロセスの作成に時間がかか
りるという問題があった。また、既存のビジネスプロセ
ス定義に含まれる比較的共通性のあるノードに全面的、
あるいは部分的な定義変更が生じた場合、従来は、上記
ビジネスプロセス定義をコピーして生成された他の全て
のビジネスプロセス定義について、上記定義変更ノード
の使用の有無をチェックし、個別に変更を加える必要が
あったため、変更漏れが発生するという問題もあった。

【０００８】本発明の目的は、新たなビジネスプロセス
を容易に定義できるワーフローサーバおよびクライアン
ト端末を提供することにある。本発明の他の目的は、既
存ビジネスプロセスのコンポーネントの定義変更を容易
にしたワークフローサーバおよびクライアント端末を提
供することにある。本発明の更に他の目的は、新たなビ
ジネスプロセス定義およびビジネスプロセスのコンポー
ネント定義を容易に行えるワークフローシステム用のユ
ーザインタフェースを提供することにある。

【０００９】

【課題を解決するための手段】上記目的を達成するた
め、本発明のワークフローサーバは、既存のビジネスプ
ロセス定義におけるプロセスの一部あるいは全体をコン
ポーネント部品としてファイルに蓄積しておき、クライ
アント端末で新たなビジネスプロセスを生成する時、ユ
ーザがこれらのコンポーネント部品を利用できるように
したことにある。

【００１０】すなわち、本発明による本発明のワークフ
ローサーバは、業務毎に定義された各ビジネスプロセス
のコンポーネントとなるデータセットを記憶するための
ファイル手段と、上記ファイル手段に記憶された各デー
タセットのコンポーネント名称の一覧をクライアント端
末の１つにビジネスプロセス定義ツール情報として提供
し、上記クライアント端末が指定した特定のコンポーネ
ントについて、上記ファイル手段から対応するデータセ
ットを読み出して上記クライアント端末に送信するコン
ポーネント管理手段とを備えたことを特徴とする。本発
明の好ましい実施例では、上記ファイル手段は、例え
ば、コンポーネントの種類別にデータセットを記憶する
ための複数のテ―ブルを有し、上記コンポーネント管理
手段が、上記コンポーネント名称の一覧を上記テーブル
毎に区分してクライアント端末に提供する。上記コンポ
ーネント管理手段は、クライアント端末で生成された新
たなコンポーネント名をもつデータセットを上記ファイ
ル手段に追加登録する。

【００１１】他の観点によれば、本発明によるワークフ
ローサーバは、それぞれ複数のノードからなるビジネス
プロセスの定義データを記憶するための第１記憶手段
と、上記第１記憶手段に記憶されたビジネスプロセスの
コンポーネントを定義したデータセットを記憶するため
の第２記憶手段と、各クライアント端末で生成または処
理された案件を上記第１記憶手段に記憶された上記案件
と対応するビジネスプロセス定義データに従って遷移さ
せるためのワークフロー管理手段と、上記クライアント
端末からの要求に応答して、上記第２記憶手段に記憶さ
れた上記各データセットが有するコンポーネント名称の
一覧を提供し、上記クライアント端末からコンポーネン
ト名を指定したデータ転送要求に応答して、該コンポー
ネント名と対応するデータセットを上記クライアント端
末に送信するコンポーネント管理手段とを備えたことを
特徴とする。

【００１２】本発明の他の特徴は、上記ワークフローサ
ーバにおいて、上記第１記憶手段に記憶された各ビジネ
スプロセスの定義データが、各ビジネスプロセスを構成
するノード間の接続関係を定義し、上記第２記憶手段に
記憶されたデータセットの少なくとも一部が、上記ビジ
ネスプロセス定義データで使用されたノード名と対応し
たコンポーネント名を有し、上記ワークフロー管理手段
が、上記第１記憶手段に記憶されたビジネスプロセス定
義データと、該ビジネスプロセス定義データ中のノード
名からリンクされる上記第２記憶手段に記憶されたデー
タセットとに基いて、各案件を制御する点にある。

【００１３】ここで、上記コンポーネント管理手段は、
クライアント端末で生成された新たなプロセス名をもつ
ビジネスプロセスの定義データを上記第１記憶手段に追
加登録する機能と、クライアント端末で生成された新た
なコンポーネント名をもつデータセットを上記第２記憶
手段に追加登録するための手段を備える。本発明の好ま
しい実施例によれば、ワークフローサーバは、クライア
ント端末から特定のコンポーネントについてビジネスプ
ロセスの検索要求を受けたとき、上記第１記憶手段に記
憶されたビジネスプロセスのうち、上記特定コンポーネ
ントを構成要素としているビジネスプロセスを検索し、
該当するビジネスプロセスの名称を上記クライアント端
末に回答するための検索手段を備える。

【００１４】また、本発明は、業務毎に予め定義された
ビジネスプロセスに従って案件を遷移するワークフロー
サーバに接続されたクライアント端末において、表示画
面と、上記表示画面でカーソル位置を操作するための入
力装置と、上記表示画面にビジネスプロセス定義用ウイ
ンドウとコマンドメニューとを生成し、ユーザ操作に応
じて、上記ワークフローサーバとの交信および上記ウイ
ンドウ内の表示内容の変更を行うための制御手段とを有
し、上記コマンドメニューが、ビジネスプロセスのコン
ポーネント種類に応じた複数のボタンを有し、上記ウイ
ンドウが、ビジネスプロセスのコンポーネント名称の一
覧を表示するための第１領域と、新たなビジネスプロセ
ス定義または新たなコンポーネント定義に使用される第
２領域とからなり、上記制御手段が、上記ウインドウの
生成時に、上記ワークフローサーバから入手した登録済
みビジネスプロセスのコンポーネント名称の一覧を上記
第１領域に表示する機能を備え、これによって、クライ
アント端末のユーザが、上記コマンドメニューと上記コ
ンポーネント名称の一覧を利用してビジネスプロセスを
定義できるようにしたことを特徴とする。

【００１５】本発明のクライアント端末の他の特徴は、
上記制御手段が、上記コマンドメニューにおけるボタン
選択を伴うユーザ操作に応答して、選択されたボタンと
対応するコンポーネントのシンボル、または該コンポー
ネントと対応する定義用ダイアログを上記第２領域に生
成する機能と、上記第１領域に表示されたコンポーネン
ト名称一覧から特定のコンポーネントを選択し、該特定
コンポーネントうを上記第２領域へ複写するユーザ操作
に応答して、上記特定コンポーネントを示すシンボル、
または該特定コンポーネントと対応した定義用ダイアロ
グを上記第２領域に生成するための機能とを備えたこと
にある。

【００１６】本発明のクライアント端末の更に他の特徴
は、上記制御手段が、上記定義用ダイアログでユーザに
よって入力されたコンポーネント定義データをワークフ
ローサーバに登録要求するための機能を備えたことにあ
る。本発明の実施例によれば、上記コマンドメニュー
は、ビジネスプロセス名定義用ダイアログを生成するた
めのボタンを有し、上記制御手段が、上記ボタン選択を
伴うユーザ操作に応答して、上記第２領域にビジネスプ
ロセス名定義用ダイアログを生成し、上記記第２領域で
定義された新たなビジネスプロセスの定義データを上記
ダイアログで入力されたプロセス名によってワークフロ
ーサーバに登録要求するための機能を備える。上記各定
義用ダイアログは、例えば、定義データの登録を指示す
るためのアイコンを備えており、前記制御手段は、ユー
ザが上記アイコンを選択したことに応答して、上記定義
用ダイアログで定義済みのデータセットをワークフロー
サーバに登録要求する。

【００１７】

【発明の実施の形態】以下、本発明の実施例を図面を参
照して説明する。図１は、本発明によるワークフローシ
ステムの構成を示す。ワークフローシステムは、ワーク
フローサーバ１と、上記サーバ１にＬＡＮ２を介して接
続された複数のクライアント端末５（５−１〜５−Ｎ）
からなる。ワークフローサーバ１は、ビジネスプロセス
のコンポーネント情報を蓄積するためのファイル（以
下、リポジトリファイルと言う）１０と、リポジトリ管
理用のプログラムメモリ２０と、ワークフローシステム
で処理される案件データ、ビジネスプロセス定義テーブ
ル（プロセス管理テーブル）、その他のワークフローデ
ータを蓄積するためのワークフロー・データベース３０
と、ワークフロー管理用のプログラムメモリ４０と、こ
れらの要素を接続するバス３を備えている。

【００１８】上記リポジトリ管理用のプログラムメモリ
２０には、リポジトリファイル１０に蓄積されたコンポ
ーネント情報を参照するための参照ルーチン２１と、リ
ポジトリファイル１０を内容を更新するための登録ルー
チン２２と、ユーザが特定のコンポーネント、例えば、
特定のActivityを指定したとき、上記特定Activityが関
係するビジネスプロセスを検索するための検索ルーチン
２３を含む。また、上記ワークフロー管理用のプログラ
ムメモリ４０には、案件をそれに対応するビジネスプロ
セスに従って遷移させるためのビジネスプロセス管理
（ワークフロー制御）ルーチン４１と、各ビジネスプロ
セスで定義されているActivityやSub-Processなどのコ
ンポーネント情報に関して、リポジトリ管理用プログラ
ムに問い合わせるリポジトリアクセスルーチン４２を含
む。

【００１９】クライアント端末５は、それぞれ表示画面
上でカーソルをドラッグ＆ドロップ操作するためのマウ
スを具備しており、クライアント端末のうち、ビジネス
プロセスの開発担当者によって使用される少なくとも１
つの端末５−１は、ビジネスプロセス定義ツール用のメ
モリ５０に、リポジトリファイル１０に蓄積されたコン
ポーネント情報にアクセスするためのリポジトリアクセ
スルーチン５１と、新たに開発したビジネスプロセス定
義情報をワークフローデータベース３０に登録するため
のビジネスプロセス登録ルーチン５２と、ビジネスプロ
セス定義情報やリポジトリファイルから読み出されたコ
ンポーネント情報を端末画面に表示するための表示制御
ルーチン５３とを備えている。尚、リポジトリアクセス
ルーチン５１は、ワークフロー管理メモリに用意された
リポジトリアクセスルーチン４２と同様、リポジトリ管
理用の参照ルーチン２１および登録ルーチン２２を呼び
出す機能を備えている。

【００２０】本発明の特徴は、ビジネスプロセスの構成
要素となるActivityや後述するサブプロセス（SubProce
ss）等のコンポーネント情報をリポジトリファイル１０
に蓄積しておき、新たなビジネスプロセスを定義する際
に、上記リポジトリファイル１０に蓄積された既存のコ
ンポーネント情報を再利用できるようにしたことにあ
る。

【００２１】従来のビジネスプロセス定義では、例え
ば、図２に示すように、端末画面上で、開始ノード１０
０Ｓと終了ノード１００Ｅとの間にActivity１００（１
００−１、１００−２、…）を定義し、各Activity１０
０に対して、ダイアログ画面Ｄ（Ｄ−１、Ｄ−２、…）
でParticipant１１２やApplication１１３などの属性情
報を定義するトップダウン形式の開発方法が採用されて
いた。

【００２２】これに対して、本発明では、例えば、図３
に示すActivity１００−１と１００−８ように、リポジ
トリファイル１０に蓄積された既存のコンポーネント情
報のうちで新規ビジネスプロセスに適用できるノード要
素はリポジトリファイル１０から呼び出し、リポジトリ
ファイルにない新たなノード要素１００−Ｎについての
み、ダイアログ画面ＤでParticipant１１２やApplicati
on１１３などの属性情報を定義し、これらのノード要素
を組み合わせることによって、新たなビジネスプロセス
を定義する。本発明において、新たなノード要素１００
−Ｎは、リポジトリファイル１０から複写した既存のコ
ンポーネント情報の一部を変更したものであってもよ
く、これらの新たなノード要素は、新たなノード識別名
を付してリポジトリファイル１０に追加登録される。

【００２３】図４は、ビジネスプロセス定義で使用され
るフロー制御ノードを示す。図において、１４−１は、
複数の出力ルート８２Ａ、８２Ｂ、…を持つ分岐点にお
いて、入力ルート８１から遷移してきた案件を予め定義
された条件を満たす出力ルート８２Ａに選択的に転送す
る分岐ノード、１４−２は、複数の出力ルート８２Ａ、
８２Ｂ、…を持つ分岐点において、入力ルート８１から
遷移してきた案件をコピーし、業務処理を並列的に実行
するために複数の出力ルートに転送する分業ノードを示
す。また、１４−３は、複数の入力ルート８１Ａ、８１
Ｂ、…の合流点において、何れかの入力ルートから先に
到着した案件を出力ルート８２に転送する先着ノード、
１４−４は、複数の入力ルート８１Ａ、８１Ｂ、…の合
流点において、全ての入力ルートで案件が受信済みとな
った時点で出力ルート８２に案件を転送する待合ノード
を示す。

【００２４】図５は、ビジネスプロセスとサブプロセス
（Sub-Process）の１例を示す。ここに例示したビジネ
スプロセスは、開始ノード１００Ｓと終了ノード１００
Ｅとの間に定義された「Activity1」１００−１と、分
岐ノード「Control1」１００Ｃ−１と、「Activity2」
１００−２と、「Activity3」１００−３と、先着ノー
ド「Control2」１００Ｃ−２とからなり、これらのノー
ド要素がアローＰ１〜Ｐ７によって関連付けられてい
る。

【００２５】サブプロセスは、ビジネスプロセスの一部
であり、例えば、破線枠７０で囲んで示すように、アロ
ー（例えば、Ｐ３〜Ｐ６）で関連付けられた複数のノー
ド要素（例えば、Activity１００−２、１００−３と、
制御ノード１００Ｃ−１、１００Ｃ−２）からなる部分
を意味している。破線枠７０で示した部分をサブプロセ
ス名「SubProcess1」で定義した場合、上記ビジネスプ
ロセスは、開始ノード１００Ｓと、「Activity1」１０
０−１と、「SubProcess1」７０、終了ノード１００Ｅ
とからなるもつプロセスとして定義できる。

【００２６】図６は、ワークフローデータベース３０に
形成されるビジネスプロセス定義テーブル３１の構成を
示す。ビジネスプロセス定義テーブル３１は、それぞれ
ビジネスプロセス名３０１と、互いに対をなす遷移元３
０２および遷移先３０３からなる複数のエントリ３００
（３００−１、３００−２、…）を含んでいる。

【００２７】ここに例示したエントリ３００−１〜３０
０−３は、図６のビジネスプロセスの定義データに相当
しており、エントリ３００−１は、開始ノード(ノード
名「Start」)１００Ｓと「Activity1」１００−１との
関係、エントリ３００−２は、「Activity1」１００−
１と「SubProcess1」７０と関係、エントリ３０−３
は、「SubProcess1」７０と終了ノード（ノード名「En
d」）１００Ｅとの関係を示している。同一ビジネスプ
ロセスに属した各エントリには、同一のビジネスプロセ
ス名３０１（この例では「BP1」）が付与してあり、ビ
ジネスプロセス定義テーブル３１において、各ビジネス
プロセスは、同一プロセス名をもつ複数のエントリから
なっている。

【００２８】図７の（Ａ）〜（Ｅ）は、リポジトリファ
イル１０におけるコンポーネント情報の格納形式の１例
を示す。リポジトリファイル１０には、コンポーネント
情報の種類に応じて、Activityテーブル１１と、Partic
ipantテーブル１２と、Applicationテーブル１３と、制
御ノードテーブル１４と、Sub-Processテーブル１５と
が形成されている。

【００２９】Activityテーブル１１は、Activity名１１
１と、Participant名１１２と、Application名１１３
と、その他の属性情報１１４とからなる複数のエントリ
１１０（１１０−１、１１０−２、…）を有し、上記Pa
rticipant名１１２とApplication名１１３は、それぞれ
Participantテーブル１２とApplicationテーブル１３へ
のアクセスキーとなっている。尚、上記その他の属性１
１４としては、例えば、各Activityの作成者や作成日時
など情報が設定される。

【００３０】Participantテーブル１２は、 Activityテ
ーブル１１に定義された各Activityの処理担当者を特定
するためのエントリ１２０（１２０−１、１２０−２、
…）を定義しており、ここに示した例では、各エントリ
１２０は、Participant名１２１と、決定ルール１２２
と、その他の項目１２３からなっている。上記決定ルー
ル１２３には、処理担当者を特定するためのSQL文や、
処理担当者を決定するために実行すべき分散オブジェク
トの名前などが設定される。

【００３１】Applicationテーブル１３は、Application
名１３１と、実行すべきプログラムを呼び出すための情
報(プログラムのフルパスや分散オブジェクトの名前な
ど)を示す実行プログラム名１３２と、その他の項目１
３３とからなる複数のエントリ１３０（１３０−１、１
３０−２、…）を含む。

【００３２】制御ノードテーブル１４は、制御ノード名
１４１と、制御ノードの種別１４２と、１対の遷移元１
４３および遷移先１４４と、その他の項目１４５とから
なる複数にエントリ１４０（１４０−１、１４０−２、
…）を含んでいる。図４に示したように、制御ノード
は、１つの入力パスから複数の出力パスへの分岐点、ま
たは複数の入力パスから１つの出力パスへの合流点とな
っているため、１つの制御ノードの全ての遷移元と遷移
先との関係を定義するためには、例えば、エントリ１４
０−１と１４０−２、１４０−３と１４０−４のよう
に、同一の制御ノード名１４１をもつ複数のエントリが
必要となる。

【００３３】Sub-Processテーブル１５は、Sub-Process
名１５１と、Activity名１５２と、遷移元１５３と、遷
移先１５４と、その他の項目１５５とからなる複数のエ
ントリ１５０（１５０−１、１５０−２、…）を含み、
同一のサブプロセスに属したエントリには同一Sub-Proc
ess名１５１が付与されている。図７の（Ｅ）に示した
エントリ１５０−１〜１５０−４は、図５に示したサブ
プロセス「SubProcess1」と対応しており、エントリ１
５０−１は制御ノード１００Ｃ−１、エントリ１５０−
２はActivityノード１００−２、エントリ１５０−３は
Activityノード１００−３、また、エントリ１５０−４
は制御ノード１００Ｃ−２について、それぞれの遷移元
と遷移先との関係を定義している。

【００３４】次に、図８を参照して、本発明でクライア
ント端末５の表示画面に生成されるビジネスプロセス定
義ツールについて説明する。本発明では、クライアント
端末のユーザが、例えば、表示画面に表示されたアイコ
ンの１つを選択することによって、ビジネスプロセス定
義の開始を指令した時、上記クライアント端末が備える
マルチウインドウ制御機能を利用して、表示画面上にビ
ジネスプロセス定義ツール用のウインドウ６と、コマン
ドメニュー７を生成する。

【００３５】上記ウインドウ６は、左右２つの表示領域
（ペイン）６Ａ、６Ｂに分割され、左ペイン６Ａには、
リポジトリファイル１０に蓄積されたコンポーネントの
名称がツリー形式で表示される。左ペイン６Ａに表示さ
れるコンポーネントツリーは、図７で説明したリポジト
リファイル１０内のActivityテーブル１１、Participan
tテーブル１２、Applicationテーブル１３、Sub-Proces
sテーブル１５および制御ノードテーブル１４と対応し
て、各テーブル毎の登録エントリ名を示す５種類のサブ
ツリー６０Ａ〜６０Ｅからなっている。右ペイン６Ｂ
は、コマンドメニュー７と上記左ペインに表示されたコ
ンポーネントとを選択的に利用して、既存コンポーネン
トの定義内容の変更や、新規ビジネスプロセスおよびコ
ンポーネントの生成作業を行うための領域となってい
る。

【００３６】コマンドメニュー７は、マウス操作によっ
て選択される複数のアイコン（メニューボタン）からな
り、コンポーネント生成用のメニューボタンとして、開
始ノード１００Ｓを生成するためのボタン７Ｂ、終了ノ
ード１００Ｅを生成するためのボタン７Ｃ、Activity定
義用のダイアログＤ１を生成するためのボタン７Ｄ、Pa
rticipant定義用のダイアログＤ２を生成するためのボ
タン７Ｅ、Application定義用のダイアログＤ３を生成
するためのボタン７Ｆ、Sub-Process定義用のダイアロ
グＤ４を生成するためのボタン７Ｇ、図４に示した制御
ノード１４−１〜１４−４を生成するためのボタン７Ｈ
〜７Ｋ、アローを生成するためのボタン７Ｌが用意され
ている。また、その他のメニューボタンとして、左ペイ
ン６Ａで選択された特定コンポーネントが関係している
既登録ビジネスプロセスの検索を指示するためのボタン
７Ａと、右ペイン６Ｂに生成されたビジネスプロセスの
登録を指示するためのボタン７Ｍと、ビジネスプロセス
定義ツール・ウインドウ６の閉鎖を指示するためのボタ
ン７Ｎが用意されている。

【００３７】ユーザが、例えば、メニューボタン７Ｂを
選択した後、カーソルを右ペイン６Ｂの適当な位置に移
動してマウスをクリック操作すると、開始ノード１００
Ｓを示すシンボルが表示される。メニューボタン７Ｃを
選択して同様の操作を行うと、終了ノード１００Ｅを示
すシンボルが表示される。また、ユーザが、左ペイン６
Ａに表示されたActivity名サブツリー６０Ａから、例え
ば、「Activity1」を選択し、右ペインの所望の位置に
ドラッグ＆ドロップ操作すると、Activity１を示すノー
ドシンボル１００−１が表示される。

【００３８】サブツリー６０Ａには存在しない新たなノ
ード、例えば、アクティビティー名「Activity3」をも
つノード１００−２を生成したい時、ユーザは、メニュ
ーボタン７Ｄを選択した後、右ペイン内の所望のカーソ
ル位置でマウスをクリックする。これによって、右ペイ
ン６Ｂには、Activity定義ダイアログＤ１が生成され
る。図８では、説明の便宜上、ノード１００−２のシン
ボルにラベル「Activity3」を付し、上記シンボルとは
離間した位置にダイアログＤ１を表示してあるが、上記
マウス操作がなされた時点では、ラベル「Activity3」
は未定であり、Activity定義ダイアログＤ１はノード１
００−２を覆った位置に生成される。

【００３９】Activity定義ダイアログＤ１は、Activity
名の入力枠６１Ａと、Participant名の入力枠６１Ｂ
と、Application名の入力枠６１Ｃと、これらの入力枠
で定義されたActivityのリポジトリファイル１０への登
録を指示するためのＯＫボタン６７と、Activity定義ダ
イアログＤ１を閉鎖（消去）するためのキャンセルボタ
ン６８とを含んでいる。上記入力枠６１Ｂ、６１Ｃに
は、名称データ（Participant名とApplication名）をキ
ーボードから入力する場合に押下されるボタン６５Ｂ、
６５Ｃと、コンボボックスから既存の名称を選択する場
合に操作されるスクロールボタン８８Ｂ、６６Ｃとがそ
れぞれ付随している。メニューボタン７Ｄの選択によっ
てActivity定義ダイアログＤ１を生成した時点では、入
力枠６１Ａ〜６１Ｃは空白となっている。

【００４０】ユーザが、上記入力枠６１Ａ〜６１Ｃにア
クティビティ名と属性データ（Participant名とApplica
tion名）とを設定した後、ＯＫボタン６７を選択する
と、リポジトリファイル１０のActivityテーブル１１に
新たなエントリ１１０−３が登録され、左ペイン６Ａの
サブツリー６０Ａに、アクティビティ名称「Activity
3」が追加表示される。ユーザがキャンセルボタン６８
を選択すると、ダイアログＤ１が消え、ラベル「Activi
ty3」をもつノードシンボル１００−２が現れる。ユー
ザは、ビジネスプロセスに必要な全てのノード要素が右
ペイン６Ｂに揃った時点で、ノード間を順次にパスＰ１
〜Ｐ３で結合する。これらのパスは、メニューボタン７
Ｌを選択した後、２つのノードシンボル間でカーソルを
ドラッグすることによって描かれる。

【００４１】上記事例では、メニューボタン７Ｄの選択
によってActivity定義ダイアログＤ１を生成し、アクテ
ィビティ名称「Activity3」をもつ新たなActivityを定
義したが、新たなActivityは、既存Activityの定義デー
タの一部を変更することによって生成してもよい。例え
ば、図８において、シンボル１００−１をダブルクリッ
クすると、リポジトリファイル１０からActivity1の定
義データが読み出され、 Activity1の現在の定義内容を
示すActivity定義ダイアログＤ１が生成され、入力枠６
１Ａ〜６１Ｃの表示データを訂正することによって、Ac
tivity1の定義内容を変更することができる。従って、
既存のActivityのうちの１つを左ペイン６Ａから右ペイ
ン６Ｂに複写し、複写されたActivityのシンボルをダブ
ルクリックすることによってActivity定義ダイアログＤ
１を生成し、Participant名６１ＢとApplication名６１
Ｃの少なくとも一方を修正し、Activity名６１Ａを新た
なActivity名に変更した後、ＯＫボタン６７を押下すれ
ば、リポジトリファイル１０に新たなActivityを追加で
きる。尚、右ペイン６Ｂに生成したビジネスプロセス中
の特定のノードを消去する場合は、キーボードにあるDe
lete用のファンクションキーを使用する。

【００４２】リポジトリファイル１０に蓄積された既存
コンポーネントを再利用するために、左ペイン６Ａに表
示されたコンポーネントを右ペイン６Ｂに複写する場
合、次に述べる２通りのコピー方法を使い分ける。図９
の（Ａ）は、左ペイン６Ａに表示されたコンポーネント
を通常のドラッグ＆ドロップ操作（以下、「Shallowコ
ピー」と言う）によって右ペイン６Ｂに複写した場合の
元のエントリ１１０と複写エントリ１１０Ｓとの関係を
示す。既存コンポーネントをShallowコピーした場合、
実エントリとしては元のエントリ１１０にみが存在して
おり、表示画面上で複写エントリ１１０Ｓに対して行っ
た内容変更操作１００Ｐは、そのまま元のエントリ１１
０に反映される。図９の（Ｂ）は、例えば、キーボード
上の制御（Ctrl）キーを押下した状態で、左ペイン６Ａ
に表示されたコンポーネントをドラッグ＆ドロップ操作
（以下、「Deepコピー」と言う）することによって右ペ
イン６Ｂに複写した場合の元のエントリ１１０と複写エ
ントリ１１０Ｄとの関係を示す。 既存コンポーネント
をDeepコピーした場合は、元のエントリとは独立した形
で、既存コンポーネントと同一の内容を持つ新たな複写
エントリ１１Ｄが生成される。この場合、複写エントリ
１１Ｄに対して行った内容変更操作１１０Ｐは、元のエ
ントリ１１０には反映されない。

【００４３】従って、元のエントリの定義内容を変更し
たい場合は、目的のコンポーネントをShallowコピー
し、エントリ名をそのままにして、ＯＫボタン６７を押
す。一方、元のエントリの内容を保存したまま、これを
利用して新たなエントリを生成したい場合は、目的のコ
ンポーネントをDeepコピーし、定義内容を変更した後、
新たなコンポーネント名を与えた上で、ＯＫボタンを押
せばよい。尚、左ペイン６Ａにある１つのコンポーネン
トがDeepコピーによって右ペイン６Ｂに複写された場
合、ユーザには複写コンポーネントの定義内容を変更す
る意志があるものと判断できるため、シンボルのダブル
クリック操作がなくても、ドラッグ＆ドロップ操作の終
了と同時に定義用ダイアログを自動的に生成し、ユーザ
が直ちに定義変更操作に移れるようにしてもよい。

【００４４】図１０の（Ａ）と（Ｂ）は、メニューボタ
ン７Ｅ、７Ｆの選択によって生成されるParticipant定
義ダイアログＤ２とApplication定義ダイアログＤ３の
フォーマットを示す。Participant定義ダイアログＤ２
には、Participant名の入力枠６２ＡとParticipantの決
定ルールの入力枠６２Ｂ、Application定義ダイアログ
Ｄ３には、Application名の入力枠６３Ａと実行プログ
ラム名の入力枠６３Ｂとがそれぞれ用意してあり、これ
らのダイアログにも、Activity定義ダイアログＤ１と同
様、ＯＫボタン６７とCancelボタン６８とが備わってい
る。

【００４５】図１１は、Sub-Process定義ダイアログＤ
４のフォーマットと、その生成方法を示す。Sub-Proces
s定義ダイアログＤ４は、ユーザが、メニューボタン７
Ｇを選択した後、右ペイン６Ｂに表示されているビジネ
スプロセス中でSub-Processとしてまとめたい複数のノ
ード、例えば、ノード１００−Ａ〜１００−Ｃを枠７０
で囲んだ時点で生成される。Sub-Process定義ダイアロ
グＤ４には、Sub-Process名の入力枠６４と、ＯＫボタ
ン６７と、Cancelボタン６８とが用意されている。上述
した定義ダイアログＤ２、Ｄ３およびＤ４は、Activity
定義ダイアログＤ１と同様、左ペイン６Ａから右ペイン
６ＢへのコンポーネントのDeepコピー、あるいは右ペイ
ン６Ｂに表示されたコンポーネントのダブルクリックに
よっても生成される。

【００４６】図１２は、リポジトリ管理用プログラムメ
モリ２０に参照ルーチン２１として用意されたコンポー
ネント表示ルーチン２１０のフローチャートを示す。こ
のルーチンは、クライアント端末５−１でビジネスプロ
セス定義ツール・ウインドウ６が生成された時点で、リ
ポジトリアクセスルーチン５１から発行される表示デー
タ転送要求に応答して実行される。

【００４７】コンポーネント表示ルーチン２１０は、リ
ポジトリファイル１０に形成されたコンポーネントテー
ブル（Activityテーブル１１、Participantテーブル１
２、Applicationテーブル１３、制御ノードテーブル１
４およびSub-Processテーブル１５）と対応したサブツ
リー作成用の５つのサブルーチンの実行ステップ２１１
〜２１５と、これらのサブルーチンで作成された表示デ
ータをクライアント端末５−１に転送するためのステッ
プ２１６とからなっている。ステップ２１１では、Acti
vityテーブル１１を参照してツリー形式の表示データ６
０Ａを作成するサブルーチンが実行される。上記サブル
ーチンは、例えば、SQLのSELECT文を実行して、Activit
yテーブル１１内にあるActivity名を検索し（ステップ
２１１Ａ）、検索されたActivity名をリスト形式に変換
し（ステップ２１１Ｂ）、リスト形式のActivity名をツ
リー形式の表示データに変換する（ステップ２１１
Ｃ）。

【００４８】ステップ２１２〜２１５で実行されるサブ
ルーチンも、検索データ名と参照するコンポーネントテ
ーブルが異なるだけで、上記ステップ２１１で実行する
サブルーチンと同様のサブステップからなっており、そ
れぞれParticipant名、Application名、制御ノード名、
Sub-Process名を検索し、ツリー形式の表示データ６０
Ｂ〜６０Ｅに変換する。これらの表示データは、ステッ
プ２１６でクライアント端末に転送され、表示制御ルー
チン５３を介してウインドウ６の左ペイン６Ａに表示さ
れる。尚、コンポーネントツリーが長すぎるために全コ
ンポーネント名をペイン６Ａに同時表示できない場合
は、ツリーの一部を表示し、残り部分はスクロール機能
によって見れるようにする。

【００４９】検索ルーチン２３としては、上記コンポー
ネント表示ルーチン２１０の他に、ユーザによる右ペイ
ン６Ｂでのコンポーネント定義用ダイアログＤ１−Ｄ４
の生成操作に応答して実行されるコンポーネントデータ
検索ルーチンがある。このルーチンは、エントリ名（１
１１、１２１、１３１または１５１）がユーザ指定のコ
ンポーネント名と一致したエントリを単にリポジトリフ
ァイル１０から読み出し、エントリの内容（データセッ
ト）をクライアント端末に転送するものであり、図面に
よるフローチャートの説明は省略する。

【００５０】図１３〜図１６は、リポジトリ管理用プロ
グラムメモリ２０に登録ルーチン２２として用意された
コンポーネント別の登録ルーチンのフローチャートを示
す。

【００５１】図１３は、Activity登録ルーチン２２０を
示す。Activity登録ルーチン２２０は、図８に示したAc
tivity定義ダイアログＤ１においてユーザがＯＫボタン
６７を選択した時、リポジトリアクセスルーチン５１
が、アクセスされたダイアログの種類（この場合は、
「Activity」）を指定して、登録ルーチン２２にエント
リの登録要求を発行することによって実行される。Acti
vity登録ルーチン２２０では、Activity定義ダイアログ
Ｄ１における入力枠６１Ａ〜６１Ｃの入力データを変数
activity、participant、applicationにそれぞれ設定し
（ステップ２２１）、Activityテーブル１１から上記変
数activityと同一のActivity名１１１を持つエントリを
検索する（ステップ２２２）。

【００５２】検索結果を判定し（ステップ２２３）、目
的のエントリがActivityテーブル１１に既に登録済みの
場合は、検索された目的エントリのParticipant名１１
２、Application名１１３を変数participant、applicat
ionが示す内容にそれそれ置換え（ステップ２２４）、
目的エントリがActivityテーブル１１になかった場合
は、上記変数activity、participant、applicationが示
す内容をActivity名１１１、Participant名１１２、App
lication名１１３とする新たなエントリをＡｃｔｉｖｉ
ｔｙテーブル１１に追加（ステップ２２５）した後、更
新されたＡｃｔｉｖｉｔｙ名サブツリー６０Ａの表示デ
ータを作成し、クライアント端末に転送する（ステップ
２２６）。上記表示データは、図１２のステップ２１１
と同様のサブルーチンを実行することによって得られ
る。

【００５３】図１４は、Participant登録ルーチン２３
０を示す。Participant登録ルーチン２３０は、図１０
に示したParticipant定義ダイアログＤ２においてユー
ザがＯＫボタン６７を選択した時、リポジトリアクセス
ルーチン５１から発行される登録要求に応答して実行さ
れる。Participant登録ルーチン２３０では、Participa
nt定義ダイアログＤ２の入力枠６２Ａ、６２Ｂの入力デ
ータを変数participant、ruleにそれぞれ設定し（ステ
ップ２３１）、Participantテーブル１２から上記変数p
articipantと同一のParticipant名１２１を持つエント
リを検索する（ステップ２３２）。

【００５４】以下、Activity登録ルーチン２２０の場合
と同様、検索結果を判定し（ステップ２３３）、目的の
エントリがParticipantテーブル１２に既に登録済みの
場合は、検索された目的エントリの決定ルール１２２を
変数ruleが示す内容に置換え（ステップ２３４）、目的
エントリがParticipantテーブル１２になかった場合
は、上記変数participant、ruleの内容をParticipant名
１２１、rule名１２２とする新たなエントリを上記Part
icipantテーブル１２に追加（ステップ２３５）した
後、更新されたParticipant名サブツリー６０Ｂの表示
データを作成して、クライアント端末に転送する（ステ
ップ２３６）。上記表示データは、図１２のステップ２
１２と同様のサブルーチンを実行することによって得ら
れる。

【００５５】図１５は、Application登録ルーチン２４
０を示す。Application登録ルーチン２４０は、図１０
に示したApplication定義ダイアログＤ３においてユー
ザがＯＫボタン６７を選択した時、リポジトリアクセス
ルーチン５１から発行される登録要求に応答して実行さ
れる。Application登録ルーチン２４０では、Applicati
on定義ダイアログＤ３の入力枠６３Ａ、６３Ｂの入力デ
ータをそれぞれ変数appliとprogramに設定し（ステップ
２４１）、Applicationテーブル１３から上記変数appli
と同一のApplication名１３１を持つエントリを検索す
る（ステップ２４２）。

【００５６】以下、Activity登録ルーチン２２０の場合
と同様、検索結果を判定し（ステップ２４３）、目的の
エントリがApplicationテーブル１３に既に登録済みの
場合は、検索された目的エントリの実行プログラム名１
３２を変数programが示す内容に置換え（ステップ２４
４）、目的エントリがApplicationテーブル１３になか
った場合は、上記変数appli、programの内容をApplicat
ion名１３１、実行プログラム名１３２とする新たなエ
ントリを上記Applicationテーブル１３に追加（ステッ
プ２４５）した後、更新されたApplication名サブツリ
ー６０Ｃの表示データを作成し、クライアント端末に転
送する（ステップ２４６）。上記表示データは、図１２
のステップ２１３と同様のサブルーチンを実行すること
によって得られる。

【００５７】図１６は、Sub-Process登録ルーチン２５
０を示す。Sub-Process登録ルーチン２５０は、図１１
に示したSub-Process定義ダイアログＤ４においてユー
ザがＯＫボタン６７を選択した時、リポジトリアクセス
ルーチン５１から発行される登録要求に応答して実行さ
れる。Sub-Process登録ルーチン２５０では、Sub-Proce
ss定義ダイアログＤ４の入力枠６４Ａの入力データを変
数subに設定（ステップ２５１）した後、Sub-Processに
含まれるノードとアローの繋がりを辿ることによって、
ノード間の接続関係を示したリスト構造に変換する（ス
テップ２５２）。例えば、図１１に示したように、Sub-
Processが直列配置の３つのActivityノードＡ、Ｂ、Ｃ
からなっていた場合、ノードＡ、Ｂ、Ｃの接続関係を示
すリスト構造データが生成される。

【００５８】次に、Sub-Processテーブル１５から変数s
ubと同一のSub-Process名１５１を持つエントリを検索
する（ステップ２５３）。検索結果を判定し（ステップ
２５４）、もし、目的のエントリがＳｕｂ−Ｐｒｏｃｅ
ｓｓテーブル１５に既に登録済みの場合は、上記変数ｓ
ｕｂと同一のSub-Process名１５１を持つ既登録のエン
トリをSub-Processテーブル１５から削除する（ステッ
プ２５５）。この後、ステップ２５２で生成したリスト
構造データに基いて、各ノード毎に遷移元と遷移先を特
定し、ノード名を変数nod、特定された遷移元と遷移先
を変数srcとdestに設定し（ステップ２５６）、上記変
数sub、nod、src、destをそれぞれSub-Process名１５
１、Activity名１５２、遷移元１５３、遷移先１５４と
する新たなエントリをSub-Processテーブル１５に追加
登録する（ステップ２５７）。上述した新たなエントリ
の生成と登録は、リスト構造データに含まれるノード毎
に繰り返され、全てのノードについてのエントリの登録
が終了すると（ステップ２５８）、更新されたSub-Proc
ess名サブツリー６０Ｄの表示データを作成し、クライ
アント端末に転送する（ステップ２５９）。

【００５９】登録ルーチン２３には、上述したコンポー
ネント別の登録ルーチンの他に、図２８で後述するプロ
セス名定義ダイアログＤ５においてユーザがＯＫボタン
６７を選択した時、リポジトリアクセスルーチン５１か
ら発行される登録要求に応答して実行されるビジネスプ
ロセス登録ルーチンが含まれる。このルーチンは、右ペ
イン６Ｂで定義された複数ノードからなるビジネスプロ
セスの定義データをデータベース３０にあるビジネスプ
ロセス定義テーブル３１に追加するためのものであり、
使用する変数名とテーブル名、エントリ形式が異なるだ
けで、基本的には図１６のSub-Process登録ルーチンと
同様の手順をもつため、具体的なフローチャートの説明
は省略する。

【００６０】図１７は、リポジトリファイル１０で管理
されているコンポーネントの１つを特定し、そのコンポ
ーネントが使われているビジネスプロセス定義を検索す
る場合のユーザ操作を示す。ユーザは、検索用のメニュ
ーボタン７Ａを押した後、左ペイン６Ａに表示されたコ
ンポーネントツリーの中から１つのコンポーネント名を
選択する。上記ユーザ操作によって、検索ルーチン２３
が実行され、検索結果がウインドウＷ１に表示される。

【００６１】図１８は、ビジネスプロセス名を検索する
ための検索ルーチン２３のフローチャートを示す。上記
検索ルーチン２３では、ユーザが選択したコンポーネン
ト名称を変数componameに設定し（ステップ２６１）、
ワークフローデータベース３０にあるビジネスプロセス
定義テーブル３１から、遷移元３０２または遷移先３０
３に上記変数componameと同一のノード名をもつエント
リを検索する（ステップ２６２）。

【００６２】上記検索結果には、図６に示したビジネス
プロセス名BP1をもつエントリ３００−１と３００−
２、または３００−２と３００−３の例からも明らかな
ように、同一のビジネスプロセス名をもつ複数のエント
リが重複して含まれているため、ビジネスプロセス名の
重複したエントリを排除（ステップ２６３）した後、ビ
ジネスプロセス名表示リストをクライアント端末に転送
する（ステップ２６４）。

【００６３】以下、図１９〜図２７を参照して、上述し
たツール画面（ユーザインタフェース）で既存コンポー
ネントを利用して行われる本発明によるビジネスプロセ
ス定義の具体例について説明する。ここでは、図１９に
示すように、旅費申請Activity１００−１１と旅費審査
Activity１００−１２とからなる旅費申請ビジネスプロ
セス定義が既にビジネスプロセス定義テーブル３１に登
録済であり、上記２つのActivity１００−１１と１００
−１２の定義データがリポジトリファイル１０に蓄積さ
れてという条件のもとで、新たに、図２０に示す休暇申
請ビジネスプロセスを定義する場合を例にとって、ユー
ザ操作に伴う定義ツール画面６とリポジトリファイル１
０の変化を説明する。

【００６４】図１９に示す旅費申請ビジネスプロセスに
おいて、旅費申請Activity１００−１１は、「Particip
ant名６１Ｂで定義された各旅費申請者が、Application
名６１Ｃで定義された旅費申請書作成プログラムを起動
し、クライアント端末５−Ｊの画面上に表示された旅費
申請書の各入力項目にデータ入力することによって、旅
費申請書を作成」する業務処理を意味している。旅費申
請Activity１００−１１で発生した案件（電子文書化さ
れた旅費申請書）は、上記クライアント端末５−Ｊから
ワークフローサーバ１に転送され、ワークフローデータ
ベース３０に蓄積される。この時、上記ワークフローデ
ータベース３０に蓄積された案件は、ビジネスプロセス
管理ルーチン４１によって、ビジネスプロセスの次ノー
ドである旅費審査Activity１００−１２にリンクされて
いる。

【００６５】旅費審査Activity１０−１２は、「Partic
ipant名６１Ｂで定義された各旅費申請者の上長が、App
lication名６１Ｃで定義された旅費申請書審査プログラ
ムを起動することによって、クライアント端末５−Ｋの
画面上で各案件（旅費申請書）を審査」する業務処理を
意味している。上記旅費申請書審査プログラムは、申請
者が作成した旅費申請書をワークフローデータベース３
０から端末画面に呼び出し、承認、非承認の判断結果を
入力できるようにしたプログラムである。

【００６６】図２１は、休暇申請ビジネスプロセスの定
義操作に着手する時点でのリポジトリファイル１０の状
態を示す。リポジトリファイルのActivityテーブル１１
には、Activity名１１１が「旅費申請」と「旅費審査」
の２つのエントリ１１０−１１と１１０−１２が登録さ
れ、Participantテーブル１２には、 Participant名１
２１が「申請者」と「申請者上長」の２つのエントリ１
２０−１１と１２０−１２が登録されている。申請者用
のエントリ１２０−１１の決定ルール１２２に設定され
た「LoginUser」は、ワークフローシステムにログイン
しているクライアント端末のユーザＩＤを申請者として
扱うための実行可能なプログラムまたは分散オブジェク
トの名称を示している。また、申請者上長用のエントリ
１２０−１２の決定ルール１２２に設定された「Superi
or」は、各案件の申請者（ユーザＩＤ）に基いてテーブ
ル検索することによって申請者上長を特定するための実
行可能プログラムまたは分散オブジェクトの名称を示し
ている。

【００６７】Applicationテーブル１３には、Applicati
on名１３２が「旅費申請書作成」と「旅費申請書審査」
の２つのエントリ１３０−１１と１３０−１２が登録さ
れ、これらのエントリには、実行プログラム１３２とし
て「CreateTravelExpense」と「ExamineTravelExpens
e」がそれぞれ設定されている。「CreateTravelExpens
e」は、旅費申請書を画面表示し、必要項目にデータを
入力させる実行可能なプログラムまたは分散オブジェク
トの名称であり、「ExamineTravelExpense」は、データ
入力済みの旅費申請書を画面に表示し、承認または非承
認を選択できるようにした実行可能なプログラムまたは
分散オブジェクトの名称を示している。

【００６８】ここで新たに生成しようとしている休暇申
請ビジネスプロセスは、図２０に示すように、休暇申請
Activity１００−１３と休暇審査Activity１００−１４
とからなる。ここで、上記休暇申請Activity１００−１
３のParticipant名は「申請者」、休暇審査Activity１
００−１４のParticipant名は「申請者上長」となって
いるため、これらのノードは、旅費申請ビジネスプロセ
ス定義用の旅費申請Activity１００−１１と旅費審査Ac
tivity１００−１２に共通点をもっている。

【００６９】休暇申請ビジネスプロセスの生成に際し
て、クライアント端末５−Ｊのユーザは、先ず、休暇申
請用と休暇申請書審査用のアプリケーションプログラム
を作成する。これらのプログラムは、任意のプログラミ
ング言語で開発した実行可能なプログラム、または分散
オブジェクトのどちらであってもよい。次に、ユーザ
は、上記休暇申請用プログラムをリポジトリファイル１
０に登録する。上記プログラムの登録は、図８に示した
ビジネスプロセス定義ツール・ウインドウ６において、
メニューボタン７Ｆを選択することによって、右ペイン
６ＢにApplication定義用ダイアログＤ３−１３を生成
した後、入力枠６３Ａと６３Ｂに、例えば、図２２の
（Ａ）に示すように、定義データを入力することによっ
て達成できる。この例では、Application名「休暇申請
書作成」と実行プログラム名「CreateHolidayApplicati
on」をそれぞれ入力枠６３Ａ、６３Ｂに入力した後、Ｏ
Ｋボタン６７をクリックする。

【００７０】これと同様にして、休暇申請書審査用のプ
ログラムを登録するために、Application定義ダイアロ
グＤ３−１４を生成し、図２２の（Ｂ）に示すように、
Application名「休暇申請書審査」と実行プログラム名
「ExamineHolidayApplication」とをそれぞれ入力枠６
３Ａ、６３Ｂに入力した後、ＯＫボタン６７をクリック
する。これらのユーザ操作によって、図２４に示すよう
に、リポジトリファイル１０のApplicationテーブル１
３に、Application名が「休暇申請書作成」、「休暇申
請書審査」の２つのエントリ１３０−１３、１３０−１
４が追加登録される。

【００７１】次に、休暇申請Activity１００−１３を新
規に追加する。ユーザは、メニューボタン７Ｄを選択す
ることによって、図２３に示すActivity定義ダイアログ
Ｄ１−１３を生成し、Activity名６１Ａに「休暇申請」
を入力する。ここで、休暇申請Activity１００−１３で
定義したいParticipant名「申請者」とApplication名
「休暇申請者作成」は、既にリポジトリファイル１０に
登録済みとなっているため、キーボードから文字入力す
る代わりにスクロールキー６６Ａ、６６Ｂを操作して、
コンボボックスから目的のParticipant名とApplication
名を選択すればよい。

【００７２】上記定義データの設定の後、ユーザがActi
vity定義ダイアログＤ１−１３でＯＫボタン６７をクリ
ックすることによって、リポジトリファイル１０のActi
vityテ−ブル１１には、図２４に示すように、休暇申請
用の新たなエントリ１１０−１３が追加される。

【００７３】図２５は、休暇申請ビジネスプロセスを作
成するためにウインドウ６で行われるユーザ操作を示
す。ビジネスプロセス定義ツール・ウインドウの左ペイ
ン６Ａには、図２４に示したリポジトリファイル１０の
内容と対応したコンポーネントツリーが表示されてい
る。ユーザは、メニューボタン７Ｂ、７Ｃを選択して、
右ペイン６Ｂに開始ノード１００Ｓと終了ノード１００
Ｅを生成した後、左ペイン６ＡにあるActivity名サブツ
リー６０Ａから、休暇申請１１１−１３をShallowコピ
ーで、また、旅費申請１１１−１２をDeepコピーで右ペ
イン６Ｂに複写する。

【００７４】旅費申請ActivityをDeepコピーした時、右
ペイン６Ｂには、図２６に示す旅費申請定義データを含
むActivity定義ダイアログＤ１−１２が生成されるた
め、ユーザは、訂正後のActivity定義ダイアログＤ１−
１４に示すように、Participant名「申請者上長」を残
して、Activity名６１ＡとApplication名６１Ｂの内容
をそれぞれ「休暇審査」と「休暇申請書審査」に訂正し
た後、ＯＫボタンをクリックする。

【００７５】上記ＯＫボタンのクリックによって、リポ
ジトリファイル１０のActivityテーブル１１には、図２
７に示すように、休暇審査用のActivityエントリ１１０
−１４が追加される。Activity定義ダイアログＤ１−１
４を閉じた時点で、図２５に示したノード１００−１２
は、Activity名「休暇審査」をもつシンボル１００−１
４に変化し、上記ノードシンボル１００−１４をダブル
クリックすれば、ダイアログＤ１−１４によって定義内
容を参照できる状態となっている。従って、この状態
で、メニューボタン７Ｌを選択しながら各ノード間をア
ローで結合することによって、図２０に示した休暇申請
ビジネスプロセスを完成できる。

【００７６】左ペイン６Ｂで定義された図２０の休暇申
請ビジネスプロセスをワークフローデータベース３０に
登録したい場合、ユーザは登録用のメニューボタン７Ｍ
をクリックする。上記メニューボタン７Ｍのクリックに
応答して、端末画面上には、図２８に示すように、プロ
セス名の入力枠６９をもったプロセス名定義ダイアログ
Ｄ５が生成される。ユーザが、上記入力枠６９に新たな
ビジネスプロセス名、例えば「休暇」を入力した後、Ｏ
Ｋボタン６７をクリックすると、登録ルーチン２２のう
ちのビジネスプロセス登録ルーチンが起動され、上記休
暇申請ビジネスプロセスの定義データがビジネスプロセ
ス管理テーブル３１に登録される。この場合、休暇申請
ビジネスプロセスの定義データは、それぞれがビジネス
プロセス名３０１として「休暇」を有し、開始ノードと
休暇申請Activity、休暇申請Activityと休暇審査Activi
ty、休暇審査Activityと終了ノードをそれぞれの遷移元
３０２と遷移先３０３とする３つのエントリに分かれて
いる。

【００７７】

【発明の効果】以上の実施例の説明から明らかなよう
に、本発明では、ワークフローシステムで既に登録済み
のビジネスプロセス定義に含まれるコンポーネントの定
義データをコンポーネントファイル（リポジトリファイ
ル）に蓄積しておき、新たなビジネスプロセスを定義す
る際に、既存のコンポーネントを組合せ、必要に応じ
て、既存コンポーネントの部分的変更、または新コンポ
ーネントの追加を行うようにしているため、所望のビジ
ネスプロセス定義を短時間で完了できる。また、実施例
に示したように、クライアント端末の表示画面に生成し
たビジネスプロセス定義用のツールウインドウに既存コ
ンポーネントを一覧表示しておき、ユーザが所望コンポ
ーネントを複写することによって作業領域にコンポーネ
ントを生成し、コンポーネント対応の定義用ダイアログ
を通して各コンポーネントの定義内容を表示する方式を
採用すれば、既存コンポーネントの内容確認と訂正を迅
速に行うことができ、新たなビジネスプロセス定義に必
要なコンポーネントを簡単な操作で確実に準備できる。

【図面の簡単な説明】

【図１】本発明のワークフローシステムの構成図。

【図２】従来のビジネスプロセス定義の開発方法を示す
図。

【図３】本発明によるビジネスプロセス定義の開発方法
を示す図。

【図４】ビジネスプロセス定義に使用される制御ノード
を示す図。

【図５】ビジネスプロセスとサブプロセスの１例を示す
図。

【図６】ワークフローデータベース３０に形成されるビ
ジネスプロセス定義テーブルの構成図。

【図７】リポジトリファイル１０に形成される各種コン
ポーネントテーブルの構成図。

【図８】クライアント端末画面に生成されるビジネスプ
ロセス定義ツール・ウインドウとActivity定義ダイアロ
グＤ１を説明するための図。

【図９】コンポーネントのShallowコピーとDeepコピー
の違いを説明するための図。

【図１０】Participant定義ダイアログＤ２とApplicati
on定義ダイアログＤ３のフォーマットを示す図。

【図１１】サブプロセスの指定方法とSub-Process定義
ダイアログＤ４のフォーマットを説明するための図。

【図１２】参照ルーチン２１の一部であるコンポーネン
ト表示ルーチン２１０の機能を示すフローチャート。

【図１３】登録ルーチン２２の一部であるActivity登録
ルーチン２２０の機能を示すフローチャート。

【図１４】登録ルーチン２２の一部であるParticipant
登録ルーチン２３０の機能を示すフローチャート。

【図１５】登録ルーチン２２の一部であるApplication
登録ルーチン２４０の機能を示すフローチャート。

【図１６】登録ルーチン２２の一部であるSub-Process
登録ルーチン２５０の機能を示すフローチャート。

【図１７】指定コンポーネントと関係するビジネスプロ
セス定義の検索結果の表示画面Ｗ１の１例を示す図。

【図１８】ビジネスプロセス名検索ルーチン２３の機能
を示すフローチャート。

【図１９】既存ビジネスプロセスの１例（旅費申請ビジ
ネスプロセス）を示す図。

【図２０】新たに生成するビジネスプロセスの１例（休
暇申請ビジネスプロセス）を示す図。

【図２１】新ビジネスプロセスの生成時点でのリポジト
リファイル１０の状態を示す図。

【図２２】新ビジネスプロセスで使用するApplication
プログラムを登録するために生成されるApplication定
義ダイアログＤ３−１３とＤ３−１４を示す図。

【図２３】新ビジネスプロセスを構成するActivityのう
ちの１つを定義し、登録するため生成されるActivity定
義ダイアログＤ１−１３を示す図。

【図２４】更新されたリポジトリファイル１０の状態を
示す図。

【図２５】ビジネスプロセス定義ツール・ウインドウに
おけるユーザ操作を説明するための図。

【図２６】複写されたActivityの元の定義内容と変更後
の定義内容を説明するための図。

【図２７】新ビジネスプロセスの完成時点におけるリポ
ジトリファイル１０の状態を示す図。

【図２８】新ビジネスプロセスをワークフローデータベ
ースに登録するために生成されるプロセス名定義ダイア
ログＤ５を示す図。

【符号の説明】

１：ワークフローサーバ、 ２：ＬＡＮ、 ３：バス、
６：ビジネスプロセス定義ツール・ウインドウ、７：コ
マンドメニュー、 １０：リポジトリファイル、１１：
Activityテーブル、 １２：Participantテーブル、１
３：Applicationテーブル、 １４：制御ノードテーブ
ル、１５：Sub-Processテーブル、 ２０：リポジトリ
管理プログラム、３０：ワークフローデータベース、
４０：ワークフロー管理プログラム、５０：ビジネスプ
ロセス定義ツール用メモリ、Ｄ１：Activity定義用ダイ
アログ、Ｄ２：Participant定義用ダイアログ、Ｄ３：A
pplication定義用ダイアログ、Ｄ４：Sub-Process定義
用ダイアログ、Ｄ５：プロセス名定義用ダイアログ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 小山 善直 神奈川県横浜市中区尾上町六丁目81番地日 立ソフトウェアエンジニアリング株式会社 内 (72)発明者 大場 みち子 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 (72)発明者 玉樹 正人 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Ｆターム(参考） 5B045 BB01 BB47 5B049 AA01 AA02 AA06 CC21 DD01 EE05 FF03 GG04 GG07

Claims (12)

【特許請求の範囲】
1. 【請求項１】複数のクライアント端末と接続され、各ク
   ライアント端末で生成または処理された案件を業務毎に
   予め定義されたビジネスプロセスに従って遷移するワー
   クフローサーバにおいて、 業務毎に定義された各ビジネスプロセスのコンポーネン
   トとなるデータセットを記憶するためのファイル手段
   と、 上記ファイル手段に記憶された各データセットのコンポ
   ーネント名称の一覧を上記クライアント端末の１つにビ
   ジネスプロセス定義ツール情報として提供し、上記クラ
   イアント端末が指定した特定のコンポーネントについ
   て、上記ファイル手段から対応するデータセットを読み
   出して上記クライアント端末に送信するコンポーネント
   管理手段を備えたことを特徴とするワークフローサー
   バ。
2. 【請求項２】前記ファイル手段が、前記データセットを
   コンポーネントの種類別に記憶するための複数のテ―ブ
   ルを有し、 前記コンポーネント管理手段が、前記コンポーネント名
   称の一覧を上記テーブル毎に区分して前記クライアント
   端末に提供することを特徴とする請求項１に記載のワー
   クフローサーバ。
3. 【請求項３】前記コンポーネント管理手段が、前記クラ
   イアント端末で生成された新たなコンポーネント名をも
   つデータセットを前記ファイル手段に追加登録するため
   の手段を備えたことを特徴とする請求項１または請求項
   ２に記載のワークフローサーバ。
4. 【請求項４】複数のクライアント端末と接続され、各ク
   ライアント端末で生成または処理された案件を業務毎に
   予め定義されたビジネスプロセスに従って遷移するワー
   クフローサーバにおいて、 それぞれ複数のノードからなるビジネスプロセスの定義
   データを記憶するための第１記憶手段と、 上記第１記憶手段に記憶されたビジネスプロセスのコン
   ポーネントを定義したデータセットを記憶するための第
   ２記憶手段と、 各クライアント端末で生成または処理された案件を上記
   第１記憶手段に記憶された上記案件と対応するビジネス
   プロセス定義データに従って遷移させるためのワークフ
   ロー管理手段と、 上記クライアント端末からの要求に応答して、上記第２
   記憶手段に記憶された上記各データセットが有するコン
   ポーネント名称の一覧を提供し、上記クライアント端末
   からコンポーネント名を指定したデータ転送要求に応答
   して、該コンポーネント名と対応するデータセットを上
   記クライアント端末に送信するコンポーネント管理手段
   とを備えたことを特徴とするワークフローサーバ。
5. 【請求項５】前記第１記憶手段に記憶された各ビジネス
   プロセスの定義データが、各ビジネスプロセスを構成す
   るノード間の接続関係を定義しており、前記第２記憶手
   段に記憶されたデータセットの少なくとも一部が、上記
   ビジネスプロセス定義データで使用されたノード名と対
   応したコンポーネント名を有し、 前記ワークフロー管理手段が、上記第１記憶手段に記憶
   されたビジネスプロセス定義データと、該ビジネスプロ
   セス定義データ中のノード名からリンクされる上記第２
   記憶手段に記憶されたデータセットとに基いて、前記各
   案件を制御することを特徴とする請求項４に記載のワー
   クフローサーバ。
6. 【請求項６】前記コンポーネント管理手段が、前記クラ
   イアント端末で生成された新たなプロセス名をもつビジ
   ネスプロセスの定義データを前記第１記憶手段に追加登
   録するための手段を備えたことを特徴とする請求項４ま
   たは請求項５に記載のワークフローサーバ。
7. 【請求項７】前記コンポーネント管理手段が、前記クラ
   イアント端末で生成された新たなコンポーネント名をも
   つデータセットを前記第２記憶手段に追加登録するため
   の手段を備えたことを特徴とする請求項４〜請求項６の
   何れかに記載のワークフローサーバ。
8. 【請求項８】前記クライアント端末から特定のコンポー
   ネントについてビジネスプロセスの検索要求を受けたと
   き、前記第１記憶手段に記憶されたビジネスプロセスの
   うち、上記特定コンポーネントを構成要素としているビ
   ジネスプロセスを検索し、該当するビジネスプロセスの
   名称を上記クライアント端末に回答するための検索手段
   を備えたことを特徴とする請求項４〜請求項７に何れか
   に記載のワークフローサーバ。
9. 【請求項９】業務毎に予め定義されたビジネスプロセス
   に従って案件を遷移するワークフローサーバに接続され
   たクライアント端末において、 表示画面と、 上記表示画面のカーソル位置を操作するための入力手段
   と、 上記表示画面にビジネスプロセス定義用ウインドウとコ
   マンドメニューとを生成し、ユーザ操作に応じて、上記
   ワークフローサーバとの交信および上記ウインドウ内の
   表示内容の変更を行うための制御手段とからなり、 上記コマンドメニューが、ビジネスプロセスのコンポー
   ネント種類に応じた複数のボタンを有し、 上記ウインドウが、ビジネスプロセスのコンポーネント
   名称の一覧を表示するための第１領域と、新たなビジネ
   スプロセス定義または新たなコンポーネント定義に使用
   される第２領域とからなり、 上記制御手段が、 上記ウインドウの生成時に、上記ワークフローサーバか
   ら入手した登録済みビジネスプロセスのコンポーネント
   名称の一覧を上記第１領域に表示する機能と、 上記コマンドメニューにおけるボタン選択を伴うユーザ
   操作に応答して、選択されたボタンと対応するコンポー
   ネントのシンボル、または該コンポーネントと対応する
   定義用ダイアログを上記第２領域に生成する機能と、 上記第１領域に表示されたコンポーネント名称一覧から
   特定のコンポーネントを選択し、該特定コンポーネント
   を上記第２領域へ複写するユーザ操作に応答して、上記
   特定コンポーネントを示すシンボル、または該特定コン
   ポーネントと対応した定義用ダイアログを上記第２領域
   に生成するための機能とを備えたことを特徴とするクラ
   イアント端末。
10. 【請求項１０】前記制御手段が、前記定義用ダイアログ
    でユーザによって入力されたコンポーネント定義データ
    を前記ワークフローサーバに登録要求するための機能を
    備えることを特徴とする請求項９に記載のクライアント
    端末。
11. 【請求項１１】前記コマンドメニューが、ビジネスプロ
    セス名定義用ダイアログを生成するためのボタンを有
    し、 前記制御手段が、上記ボタン選択を伴うユーザ操作に応
    答して、前記第２領域にビジネスプロセス名定義用ダイ
    アログを生成し、前記記第２領域で定義された新たなビ
    ジネスプロセスの定義データを上記ダイアログで入力さ
    れたプロセス名によって前記ワークフローサーバに登録
    要求するための機能を備えることを特徴とする請求項９
    または請求項１０に記載のクライアント端末。
12. 【請求項１２】前記各定義用ダイアログが、定義データ
    の登録を指示するためのアイコンを備え、ユーザが上記
    アイコンを選択したことに応答して、前記制御手段が、
    上記定義用ダイアログで定義済みのデータセットの登録
    を前記ワークフローサーバに要求することを特徴とする
    請求項９〜請求項１１の何れかに記載のクライアント端
    末。