JP2001005680A - ワークフロー管理システム、コードジェネレータおよびワークフロー処理のプロセス変更方法 - Google Patents

Abstract

(57)【要約】 【課題】 ワークフロー処理のプロセスを容易に修正す
る。 【解決手段】 プロセス定義データを入力することによ
り、一連かつ複数のアクティビティからなるワークフロ
ー処理のプロセスは定義される。このワークフロー管理
システム１１では、起票者２４によって入力されたプロ
セス定義情報Ｄ２３は、識別手段Ｆ１３によって、各ア
クティビティにおける処理内容に関するオブジェクト定
義情報Ｄ２３ａおよびアクティビティの順序に関するフ
ロー定義情報Ｄ２３ｂに分離される。オブジェクト定義
情報およびフロー定義情報からそれぞれオブジェクト定
義コードＤ２５ａおよびフロー定義コードＤ２５ｂを生
成する。オブジェクト定義コードおよびフロー定義コー
ドは独立したデータであるため、これら定義コードに基
づいて動作するワークフロー処理についてのプロセスの
変更は、個々の定義コードの修正により行うことができ
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ワークフロー管
理システム、ワークフロー管理システムに用いるコード
ジェネレータおよびワークフロー処理のプロセスの変更
方法に関する。

【０００２】

【従来の技術】従来、ワークフロー管理システムが、複
数の端末計算機が接続されたネットワークシステムで、
一連かつ複数の工程からなる情報処理すなわちワークフ
ロー処理を効率よく行うために利用されている。ワーク
フロー処理に係るデータは、パッケージとして各計算機
の間を定められた順序で移動し、および、各計算機で処
理される。これらの各計算機を操作して各処理者がデー
タを参照したり書き換えたりする。このような、ワーク
フロー管理システムの一例が文献Ｉ（日経コンピュー
タ」１９９７．９．１号 第２０４〜２１７頁）に開示
されている。

【０００３】図９は、文献Ｉに開示されているワークフ
ロー管理システムを各機能毎にブロックで分割して概略
的に示す図である。図９では、データを角の丸い長方形
で示し、機能手段（アプリケーション等）を角張った長
方形で示してある。図９に示すように、このワークフロ
ー管理システム２０１は、ワークフローエンジンＡ２０
３と、プロセス定義ツールＡ２０５と、ワークリストハ
ンドラＡ２０７と、モニタリングツールＡ２０９とを有
する。広く用いられているクライアント／サーバシステ
ムでは、ワークフロー処理を制御するワークフローエン
ジンＡ２０３がワークフローサーバ２０４で動作してお
り、各処理者はクライアント計算機を操作して担当の工
程（アクティビティ）を実行する。

【０００４】プロセス定義ツールＡ２０５は、各工程の
処理内容と、アクティビティの順序とを定義するための
機能モジュールである。プロセス定義ツールＡ２０５
は、新規にワークフロー処理を開始するとき、プロセス
定義データＤ２１１を生成する。プロセス定義データＤ
２１１は、各アクティビティにおける処理内容と、アク
ティビティの順序とに関するデータを一体のデータとし
て含む。また、プロセス定義データＤ２１１は、ワーク
フロー処理の終了条件等の制御条件に関するデータを含
むことがある。一般的なプロセス定義ツールＡ２０５で
はグラフィカルユーザインターフェース（ＧＵＩ）環境
が整えられている。そのため、処理者は、マウス操作に
よってポインタを用いることによりプロセス（アクティ
ビティの順序および各アクティビティでの処理内容）を
容易に定義できる。

【０００５】ワークフローエンジンＡ２０３は、ワーク
フロー処理を制御する機能モジュールである。具体的に
言うと、ワークフローエンジンＡ２０３は、プロセス定
義データＤ２１１を解釈してこの解釈に基づいて処理内
容を示すワークアイテムをワークリストＤ２１３に追加
する。なお、ワークリストＤ２１３は、各処理者が処理
すべきワークアイテムを格納するデータ領域であり、個
々の処理者毎に設けられる。

【０００６】各処理者は、ワークリストハンドラＡ２０
７によって示されるワークアイテムにしたがって、クラ
イアントアプリケーションＡ２１５等を用いてアクティ
ビティを実行する。また、人間による処理を必要としな
いアクティビティについては、ワークフローエンジンＡ
２０３によって起動された起動アプリケーションＡ２１
７が、アクティビティを実行する。図９に示すように、
これらクライアントアプリケーションＡ２１５或いは起
動アプリケーションＡ２１７はアプリケーションデータ
Ｄ２１９を利用することがある。

【０００７】ワークリストハンドラＡ２０７は、ワーク
リストＤ２１３を参照して処理すべきワークアイテムを
各処理者に示すことにより、各処理者に処理内容に関す
る指示を与える。その処理者が作業を終了すると、ワー
クリストハンドラＡ２０７はワークリストＤ２１３から
ワークアイテムを削除する。ワークフローエンジンＡ２
０３は、ワークアイテムの削除によってアクティビティ
の終了を認識して、次の処理者のワークリストＤ２１３
にワークアイテムを付加する。

【０００８】モニタリングツールＡ２０９は、ワークフ
ローエンジンＡ２０３を監視することによってワークフ
ロー処理の進行具合を確認する機能モジュールである。
モニタリングツールＡ２０９によって、監督者或いは各
処理者は必要に応じてワークフロー処理の途中経過や終
了結果を参照することができる。

【０００９】ワークフロー制御データＤ２２１は、複数
のワークフロー処理を並行して行う場合、各ワークフロ
ー処理を受け持つワークフローエンジンを互いに識別す
るのに用いられる。また、ワークフロー関連データＤ２
２３は、ワークフロー処理に関連する様々な情報を含
む。ワークフロー関連データＤ２２３は、例えば購入物
品の価格データ等であり、価格帯によって担当すべき処
理者が変化する場合等に用いられる。

【００１０】図９に示すように、ワークフローエンジン
Ａ２０３がプロセス定義データＤ２１１に基づいて各ア
クティビティにおける処理を制御することにより、ワー
クフロー処理は行われる。一般的に言うと、ワークフロ
ー処理は、繰り返し行われる定型業務およびアドホック
な非定型業務の二つの業務に分類される。定型業務には
出張費伝票、備品購入伝票または予算申請などがあり、
非定型業務には資料回覧、技術文書作成またはソフト開
発などがある。業務の効率を向上させるためには、これ
ら多種多様な業務に適用できるワークフロー管理システ
ムが必要である。

【００１１】典型的に言うと、定型業務のワークフロー
処理では、アクティビティの順序および各アクティビテ
ィにおける処理内容が殆ど変化しないため、一つのプロ
セス定義データを用いることが多い。一方、非定型業務
のワークフロー処理では、アクティビティの順序および
各アクティビティにおける処理内容が一定ではないの
で、ワークフロー処理を行う毎にプロセス定義データを
生成することが多い。

【００１２】

【発明が解決しようとする課題】しかしながら、従来の
ワークフロー管理システムでは、定型業務或いは非定型
業務のいずれにおいても、各アクティビティの処理内容
或いは処理順序を変更する場合にはプロセス定義データ
の全体を修正する必要があった。例えば、ルーチンワー
クである備品購入伝票において決裁者を変更する場合に
は、今まで用いていたプロセス定義データを修正しなけ
ればならない。また、アドホックに発生する資料回覧に
おいて資料の回覧先を変更したい場合には、資料回覧を
開始する前にプロセス定義データを修正しなければなら
ない。

【００１３】このようなアクティビティの処理順序の変
更を容易に行うため、図９のワークフロー管理システム
２０１では、ワークフローエンジンＡ２０３が組織／役
割データＤ２２５を参照する。組織／役割データＤ２２
５とは、課長や部長などの組織内の役職等を示す一般的
宛先名と、処理者の名前等の具体的宛先名とを関連付け
たデータである。この場合、プロセス定義データＤ２１
１に一般的宛先名を定義しておくだけで、ワークフロー
エンジンＡ２０３は、組織／役割データＤ２２５を参照
することにより一般的宛先名から具体的宛先名を判断で
きる。そのため、決裁ルートに沿う役職にある処理者が
人事異動等によって他の処理者に変更された場合でも、
動的に宛先が認識されるため、決裁ルートの宛先名を変
更する必要が無くなる。

【００１４】このような組織／役割データの導入によっ
て変更が不必要になる場合はあるが、役職で処理順序を
定義しないワークフロー処理では、依然としてアクティ
ビティの処理順序をプロセス定義データから修正する必
要があった。

【００１５】したがって、定型業務および非定型業務の
いずれのワークフロー処理においても、一つのアクティ
ビティにおける処理内容を変更する場合、或いは、アク
ティビティの処理順序を変更する場合には、プロセス定
義データを修正し或いはプロセス定義データを新たに作
成する。このように、従来のワークフロー処理では、プ
ロセスに関する変更はプロセス定義データの再定義を伴
うため非能率的であり、容易に行うことができなかった
（第１の問題点）。

【００１６】また、通常、新たにワークフロー処理を開
始するときには、プロセス定義データを新規に作成す
る。このとき、ワークフロー処理を適用する業務の種類
が多岐に渡る場合には、必然的にプロセス定義データも
様々な内容を有することとなる。ワークフローエンジン
は、それらのプロセス定義データを解釈してかつ実行で
きなければならないから、多種のワークフロー処理を実
行するための多くの基本的な機能を予め具備している必
要がある。したがって、ワークフローエンジンの構成が
複雑となり、ワークフローエンジンとして機能するワー
クフローエンジンコードの占有メモリが必然的に大きく
なる（第２の問題点）。

【００１７】そのため、少なくとも第１の問題点を解決
でき、好ましくは第２の問題点も解決できるワークフロ
ー管理システムが望まれていた。

【００１８】

【課題を解決するための手段】したがって、この出願に
係る発明のワークフロー管理システムは、複数の計算機
を有するネットワークシステムで、一連かつ複数の工程
からなるワークフロー処理を、各工程における処理内容
およびそれら工程の順序に関するプロセス定義情報に基
づいて、各工程ごとに行うワークフロー管理システムに
おいて、前述のプロセス定義情報から、各工程における
処理内容に関するオブジェクト定義情報と、工程の順序
に関するフロー定義情報とを識別する識別手段と、前述
のワークフロー処理に用いる基本的な機能を提供する複
数のプログラムを格納してあるプログラム格納部と、前
述のオブジェクト定義情報を解釈してこの解釈に応じた
プログラムをプログラム格納部から読み出し、かつ、こ
の読み出されたプログラムに基づいて各工程における処
理内容に関するコードであるオブジェクト定義コードを
生成するオブジェクト定義コード生成手段と、前述のフ
ロー定義情報を解釈してこの解釈に応じたプログラムを
プログラム格納部から読み出し、かつ、この読み出され
た各工程の順序に関するコードであるフロー定義コード
を生成するフロー定義コード生成手段と、前述のフロー
定義コードおよび前述のオブジェクト定義コードを解釈
することにより、ワークフロー処理を制御するワークフ
ローエンジンとを具える。

【００１９】このワークフロー管理システムの構成によ
れば、ワークフロー処理のプロセスを定義をする際、起
票者がワークフロー処理を開始させるためにプロセスを
定義する。起票者が入力したプロセス定義情報は、識別
手段によってフロー定義に関する部分およびオブジェク
ト定義に関する部分に分離される。この分離の後、前者
の部分はフロー定義コード生成手段によってコード化さ
れてフロー定義コードとして生成され、および、後者の
部分はオブジェクト定義コード生成手段によってコード
化されてオブジェクト定義コードとして生成される。よ
って、ワークフロー処理を行うとき、プロセス（各アク
ティビティにおける処理内容およびアクティビティの順
序）を変更する場合であっても、プロセス定義データそ
のものを修正する必要がない。言い換えれば、各アクテ
ィビティにおける処理内容のみを変更したい場合にはオ
ブジェクト定義コードのみを修正すれば良く、アクティ
ビティの順序（アクティビティを行う処理者の変更）を
変更したい場合にはフロー定義コードのみを修正すれば
よい。

【００２０】また、この発明の実施に当たり、より好適
には、前述のオブジェクト定義情報および前述のフロー
定義情報を解釈してこの解釈に応じたプログラムをプロ
グラム格納部から読み出すことにより、この読み出され
たプログラムに基づいてワークフローエンジンコードを
生成するワークフローエンジンコード生成手段を更に具
え、および、このワークフローエンジンコードによって
前述のワークフローエンジンコードを機能させるのが良
い。

【００２１】それにより、フロー定義情報およびオブジ
ェクト定義情報に定義された機能を実現するための必要
最低限の構成のみを有するワークフローエンジンコード
を生成できる。よって、ワークフローエンジンコードの
占有メモリを小さくできる。なお、ワークフローエンジ
ンコードとは、ＣＰＵで実行されることにより仮想的に
ＣＰＵにワークフローエンジンを存在させかつ機能させ
るプログラムコードを意味する。

【００２２】また、この発明の実施に当たり、好適に
は、前述のオブジェクト定義コードおよび前述のフロー
定義コードを高水準言語のコードの状態で保存する定義
コード保存手段を更に具えるのが良い。それにより、フ
ロー定義或いはオブジェクト定義についての修正をする
とき、修正する者は、各定義コードを理解しながらコー
ドを追加したり削除したり或いは修正したりすることが
できる。

【００２３】また、この発明の実施に当たり、好適に
は、前述のワークフローエンジンは上位階層から複数の
下位階層に機能を継承する階層構造を有し、かつ、個々
の下位階層のワークフローエンジンは相互にアクセスす
る通信機能を有するのがよい。それにより、下位階層の
ワークフローエンジンをネットワークシステム内のホス
ト計算機に分散できる。このように、ワークフローエン
ジンに階層構造を与え、個々の下位階層のワークフロー
エンジンに通信機能を設けると、下位下層のワークフロ
ーエンジンは、ネットワークシステム内の任意のホスト
計算機に分散して存在できる。よって、負荷分散による
ネットワークシステムの効率および安定性が実現でき
る。

【００２４】また、上述のように下位階層のワークフロ
ーエンジンを分散させてなるワークフロー管理システム
では、前述のフロー定義コードに一般的な宛先名を予め
定義する場合、一般的宛先名から具体的宛先名を生成す
る宛名変換手段を更に具えていて、この宛名変換手段
が、ワークフローエンジンと相互にアクセスする通信機
能を有するのが望ましい。

【００２５】従来、宛名変換を行うには、宛名変換手段
はワークフローエンジンの存在するホスト計算機と同一
のホスト計算機に設ける必要があった。しかしながら、
宛名変換手段に通信機能を設けたため、上述のように下
位階層のワークフローエンジンを分散させた場合であっ
ても、宛名変換手段は下位階層のワークフローエンジン
と相互にアクセスできる。よって、宛名変換手段を下位
階層のワークフローエンジンと別のホスト計算機に設け
ることができる。

【００２６】また、この出願に係る発明のコードジェネ
レータは、複数の計算機を有するネットワークシステム
で、一連かつ複数の工程からなるワークフロー処理を行
う際、各工程における処理内容およびそれら工程の順序
に関するプロセス定義情報から、ワークフローエンジン
の解釈できるコードを生成するコードジェネレータであ
って、前述のプロセス定義情報から、各工程における処
理内容に関するオブジェクト定義情報と、工程の順序に
関するフロー定義情報とを識別する識別手段と、前述の
オブジェクト定義情報からワークフローエンジンの解釈
できるオブジェクト定義コードを生成するオブジェクト
定義コード生成手段と、前述のフロー定義情報からワー
クフローエンジンの解釈できるフロー定義コードを生成
するフロー定義コード生成手段とを具える。

【００２７】このコードジェネレータの構成によれば、
識別手段が、プロセス定義情報をオブジェクト定義情報
およびフロー定義情報に分離させたのち、オブジェクト
定義情報からオブジェクト定義コードを生成しかつフロ
ー定義情報からフロー定義コードを生成する。そのた
め、各工程における処理内容のみを変更したい場合には
オブジェクト定義コードを修正し、また、工程の処理順
序のみを変更したい場合にはフロー定義コードを修正す
ればよい。よって、プロセスを能率的にかつ容易に変更
することができる。なお、オブジェクト定義コードおよ
びフロー定義コードは、例えば、高水準言語としてのＪ
ａｖａ言語或いはＣ++のソースプログラムコードすなわ
ち、オブジェクト定義ソースプログラムコードおよびフ
ロー定義ソースプログラムコードとして生成される。こ
のとき、これらオブジェクト定義コードおよびフロー定
義コードは、コンパイルされると、ワークフローエンジ
ンが解釈できる実行型プログラムコードとなる。

【００２８】また、この出願に係るワークフロー処理の
プロセスの変更方法の発明では、一連かつ複数の工程か
らなるワークフロー処理を行う前に、各工程の処理内容
および工程の処理順序に関するプロセス定義情報から、
各工程の処理内容に関するオブジェクト定義情報と、工
程の処理順序に関するフロー定義情報とを識別し、オブ
ジェクト定義情報からワークフローエンジンの解釈でき
るオブジェクト定義コードを生成し、かつ、フロー定義
情報からワークフローエンジンの解釈できるフロー定義
コードを生成するワークフロー処理について、当該ワー
クフロー処理のプロセスを変更するに当たり、各工程の
処理内容のみを変更する場合にはオブジェクト定義コー
ドのみを修正し、工程の処理順序のみを変更する場合に
はフロー定義コードのみを修正する。

【００２９】このプロセスの変更方法によれば、各工程
における処理内容のみを変更したい場合若しくは工程の
処理順序のみを変更したい場合のいずれにも、互いに独
立に存在するオブジェクト定義コード或いはフロー定義
コードの一方を修正することにより対応できる。よっ
て、プロセスを能率的にかつ容易に変更できる。

【００３０】

【発明の実施の形態】以下、図を参照して、この発明の
ワークフロー管理システムの実施の形態につき説明す
る。なお、この説明に用いる各ブロック図は、これら発
明を理解できる程度に各構成成分をブロックで表して概
略的な機能上の相互関係を示しているに過ぎない。ま
た、各図において同様な構成成分については、同一の番
号を付して示し、その重複する説明を省略することがあ
る。また、各図で角張った長方形は機能単位を示し、角
の丸い長方形はデータを示す。

【００３１】（第１の実施の形態）ワークフロー管理シ
ステムでは、ワークフロー処理のプロセスを定義したの
ち当該ワークフロー処理を実行する必要がある。そのた
め、第１の実施の形態では、ワークフロー管理システム
のプロセスを定義する形態につき説明し、次にワークフ
ロー管理システムのワークフロー処理を実行する形態に
つき説明し、続いてワークフロー処理のプロセスを変更
する方法につき説明する。

【００３２】図１は、第１の実施の形態のワークフロー
管理システムについて、主要な機能単位の相互関係を概
略的に示すブロック図である。ただし、図１中の各機能
単位は、ハードウェア資源としての中央処理装置がその
機能単位に対応するプログラムを実行することにより、
仮想的に中央処理装置に存在する。以下では、中央処理
装置に仮想的に実現される機能単位を角張った長方形、
記憶装置のデータ領域に形成されるデータ情報を丸みを
帯びた長方形で示してある。また、図２は、図１の各機
能単位を１台のホスト計算機で動作させた場合を例とし
て、各機能単位によるハードウェア資源の利用形態を概
略的に示す図である。

【００３３】以下、図１および図２を参照して、実施の
形態のワークフロー管理システムのプロセスを定義する
形態につき説明する。ただし、実施の形態のワークフロ
ー管理システムでは特にワークフローエンジンコード生
成手段が設けてある。

【００３４】周知のごとく、ワークフロー管理システム
は、複数のホスト計算機を有するネットワークシステム
で、一連かつ複数のアクティビティからなるワークフロ
ー処理を各アクティビティ毎に行うことにより、ワーク
フロー処理を実行する。

【００３５】図１に示す第１の実施の形態のワークフロ
ー管理システム１１は、識別手段Ｆ１３と、オブジェク
ト定義コード生成手段Ｆ１５と、フロー定義コード生成
手段Ｆ１７と、ワークフローエンジンコード生成手段Ｆ
１９と、プログラム格納部２１とを有する。なお、ここ
ではこれら各機能単位Ｆ１３、Ｆ１５、Ｆ１７およびＦ
１９は、図２のホスト計算機ｈ１の中央処理装置（ＣＰ
Ｕ）ｃ１で仮想的な機能手段として動作するように構成
されている。

【００３６】図２に示すホスト計算機ｈ１は、ハードデ
ィスクや光ディスク等の記憶装置ｍ１と、ＣＰＵｃ１
と、マンマシンインターフェース用の入力装置ｉ１とを
有する。ＣＰＵｃ１には、これら記憶装置ｍ１、入力装
置ｉ１、上述の各機能単位Ｆ１３、Ｆ１５、Ｆ１７およ
びＦ１９その他の動作のタイミングや始動或いは停止を
含む所要の制御を行うための制御部を図示せずも含んで
いる。なお、ホスト計算機ｈ１の記憶装置ｍ１には、識
別手段Ｆ１３の機能を実現させる識別プログラムＤ１３
と、オブジェクト定義コード生成手段Ｆ１５の機能を実
現させるオブジェクト定義コード生成プログラムＤ１５
と、フロー定義コード生成手段Ｆ１７の機能を実現させ
るフロー定義コード生成プログラムＤ１７と、ワークフ
ローエンジンコード生成手段Ｆ１９の機能を実現させる
ワークフローエンジンコード生成プログラムＤ１９とが
格納されている。

【００３７】先ず、ワークフロー処理のプロセスを定義
するに当たり、起票者２４は、ホスト計算機ｈ１の入力
装置ｉ１を操作して記憶装置ｍ１にプロセス定義情報Ｄ
２３を格納する。このとき、起票者２４は、ホスト計算
機ｈ１の入力装置ｉ１から例えばキーボードからのスク
リプト入力或いはポインタデバイスからのＧＵＩ操作に
よって、プロセス定義情報Ｄ２３を入力する。これによ
り、プロセス定義情報Ｄ２３がホスト計算機ｈ１の記憶
装置ｍ１に格納される。ただし、プロセス定義情報Ｄ２
３は、各アクティビティの処理内容に関するデータすな
わちオブジェクト定義情報Ｄ２３ａと、アクティビティ
の順序に関するデータすなわちフロー定義情報Ｄ２３ｂ
とを含む。

【００３８】プロセス定義情報Ｄ２３が入力されると、
識別手段Ｆ１３は、記憶装置ｍ１に格納されたプロセス
定義情報Ｄ２３を読み出してきて、このプロセス定義情
報Ｄ２３からオブジェクト定義情報Ｄ２３ａおよびフロ
ー定義情報Ｄ２３ｂを互いに識別する。しかる後、識別
されたオブジェクト定義情報Ｄ２３ａおよびフロー定義
情報Ｄ２３ｂを記憶装置ｍ１に格納する。なお、識別手
段Ｆ１３は、記憶装置ｍ１に格納されている識別プログ
ラムＤ１３をＣＰＵｃ１が読み出しかつ実行することに
より、仮想的な機能単位としてＣＰＵｃ１で動作する。

【００３９】プログラム格納部２１は、ワークフロー処
理に用いる基本的な機能を提供する複数の基本機能提供
プログラムＤ２２を格納している。なお、プログラム格
納部２１は、例えばホスト計算機ｈ１の記憶装置ｍ１内
のデータ領域に形成される。

【００４０】例えば、この基本機能提供プログラムＤ２
２は、ワークフロー処理に用いる基本的な機能を各機能
毎に区分された複数のプログラムからなる。このよう
に、基本的な機能が各機能毎に区分されていると、不必
要な機能を読み出すことなく必要な機能だけを読み出す
ことができる。したがって、基本機能提供プログラムＤ
２２から生成されるオブジェクト定義コードＤ２５ａ、
フロー定義コードＤ２５ｂおよびワークフローエンジン
コードＤ２７の占有メモリを小さくできる。

【００４１】オブジェクト定義コード生成手段Ｆ１５
は、オブジェクト定義情報Ｄ２３ａを解釈してこの解釈
に応じた基本機能提供プログラムＤ２２をプログラム格
納部２１から読み出すことにより、読み出された基本機
能提供プログラムＤ２２に基づいてオブジェクト定義コ
ードＤ２５ａを生成する。このとき、具体的にはオブジ
ェクト定義コード生成手段Ｆ１５はホスト計算機ｈ１内
で次のように機能する。

【００４２】すなわち、ホスト計算機ｈ１のＣＰＵｃ１
が記憶装置ｍ１に格納されているオブジェクト定義コー
ド生成プログラムＤ１５を読み出してかつ実行する。そ
れにより、オブジェクト定義コード生成手段Ｆ１５が起
動する。オブジェクト定義コード生成手段Ｆ１５は、記
憶装置ｍ１からオブジェクト定義情報Ｄ２３ａを読み出
すと共に、オブジェクト定義情報Ｄ２３ａに基づいてオ
ブジェクト定義コードＤ２５ａの生成に必要な基本機能
提供プログラムＤ２２かどうかを判断して当該基本機能
提供プログラムＤ２２を読み出す。しかるのち、オブジ
ェクト定義コード生成手段Ｆ１５は、読み出された基本
機能提供プログラムＤ２２およびオブジェクト定義情報
Ｄ２３ａを例えば組み合わせてオブジェクト定義コード
Ｄ２５ａを生成する。例えば、このときオブジェクト定
義コード生成手段Ｆ１５は、複数の基本機能提供プログ
ラムＤ２２を読み出してオブジェクト定義コードＤ２５
ａを生成しても良い。なお、生成されたオブジェクト定
義コードＤ２５ａは、少なくとも各アクティビティにお
ける共通の処理内容を定義した基本ソースプログラムを
含むソースプログラムとして記憶装置ｍ１に格納され
る。

【００４３】フロー定義コード生成手段Ｆ１７は、フロ
ー定義情報Ｄ２３ｂを解釈してこの解釈に応じた基本機
能提供プログラムＤ２２をプログラム格納手段２１から
読み出すことにより、読み出された基本機能提供プログ
ラムＤ２２に基づいてフロー定義コードＤ２５ｂを生成
する。このとき、具体的にはフロー定義コード生成手段
Ｆ１７はホスト計算機ｈ１内で次のように機能する。

【００４４】すなわち、ホスト計算機ｈ１のＣＰＵｃ１
が記憶装置ｍ１に格納されているフロー定義コード生成
プログラムＤ１７を読み出してかつ実行する。それによ
り、フロー定義コード生成手段Ｆ１７が起動する。フロ
ー定義コード生成手段Ｆ１７は、記憶装置ｍ１からフロ
ー定義情報Ｄ２３ｂを読み出すと共に、フロー定義情報
Ｄ２３ｂに基づいてフロー定義コードＤ２５ｂの生成に
必要な基本機能提供プログラムＤ２２かどうかを判断し
て当該基本機能提供プログラムＤ２２を読み出す。しか
るのち、フロー定義コード生成手段Ｆ１７は、読み出さ
れた基本機能提供プログラムＤ２２およびフロー定義情
報Ｄ２３ｂを例えば組み合わせてフロー定義コードＤ２
５ｂを生成する。例えば、このときフロー定義コード生
成手段Ｆ１７は、複数の基本機能提供プログラムＤ２２
を読み出してフロー定義コードＤ２５ｂを生成しても良
い。なお、生成されたフロー定義コードＤ２５ｂは、少
なくともアクティビティの順序を定義したソースプログ
ラムを含むソースプログラムとして記憶装置ｍ１に格納
される。

【００４５】ワークフローエンジンコード生成手段Ｆ１
９は、識別されたオブジェクト定義情報Ｄ２３ａおよび
フロー定義情報Ｄ２３ｂを解釈してこの解釈に応じた基
本機能提供プログラムＤ２２をプログラム格納部２１か
ら読み出すことにより、読み出された基本機能提供プロ
グラムＤ２２に基づいてワークフローエンジンコードＤ
２７を生成する。このとき、具体的にはワークフローエ
ンジンコード生成手段Ｆ１９はホスト計算機ｈ１内で次
のように機能する。

【００４６】すなわち、ホスト計算機ｈ１のＣＰＵｃ１
が記憶装置ｍ１に格納されているワークフローエンジン
コード生成プログラムＤ１９を読み出してかつ実行する
ことにより、ワークフローエンジンコード生成手段Ｆ１
９が起動する。起動したワークフローエンジンコード生
成手段Ｆ１９は、記憶装置ｍ１からオブジェクト定義情
報Ｄ２３ａおよびフロー定義情報Ｄ２３ｂを読み出すと
共に、これらの定義情報Ｄ２３ａおよびＤ２３ｂに基づ
いてワークフローエンジンコードＤ２７の生成に必要な
基本機能提供プログラムＤ２２かどうかを判断して当該
基本機能提供プログラムＤ２２を読み出す。しかるの
ち、ワークフローエンジンコード生成手段Ｆ１９は、読
み出された基本機能提供プログラムＤ２２からワークフ
ローエンジンコードＤ２７を生成する。例えば、このと
きワークフローエンジンコード生成手段Ｆ１９は、複数
の基本機能提供プログラムＤ２２を組み合わせてワーク
フローエンジンコードＤ２７を生成する。なお、生成さ
れたワークフローエンジンコードＤ２７は、オブジェク
ト定義コードＤ１５およびフロー定義コードＤ１７を解
釈（ただし、Ｊａｖａプログラミングにおける「参照」
の意味を含む。）してかつこの解釈に基づいてワークフ
ロー処理を制御するためのソースプログラムとして記憶
装置ｍ１に格納される。

【００４７】また、実際にワークフロー処理を行う際に
は、例えばホスト計算機ｈ１のＣＰＵｃ１が記憶装置ｍ
１に格納されているワークフローエンジンコードＤ２７
を読み出してかつ実行することにより、一つの機能単位
としてのワークフローエンジンが起動してワークフロー
処理の制御動作を行う。

【００４８】なお、識別手段Ｆ１３、オブジェクト定義
コード生成手段Ｆ１５およびフロー定義コード生成手段
Ｆ１７は、コードジェネレータＦ２８という一つの機能
単位として認識できる。コードジェネレータＦ２８は、
複数のホスト計算機を有するネットワークシステムで、
一連かつ複数のアクティビティからなるワークフロー処
理を行う際、各アクティビティにおける処理内容および
それらアクティビティの順序に関するプロセス定義情報
から、ワークフローエンジンの解釈できるプロセスに関
するコードを生成する。特に、このコードジェネレータ
Ｆ２８は、プロセス定義情報Ｄ２３から、オブジェクト
定義コードＤ２５ａおよびフロー定義コードＤ２５ｂを
区別してそれぞれ生成する。そのため、一般的なワーク
フロー管理システムについて、そのワークフローエンジ
ンがオブジェクト定義コードＤ２５ａおよびフロー定義
コードＤ２５ｂを解釈できる構成であれば、このコード
ジェネレータＦ２８の部分のみを適用できる。

【００４９】ここで、具体的なワークフロー処理を実行
する場合を例として、以上説明した各機能単位につき更
に詳細に説明する。

【００５０】なお、ここではワークフロー管理システム
を、オブジェクト指向プログラミング（ＯＯＰ）を用い
て構築する。周知の如く、Ｊａｖａ言語やＣ＋＋言語等
は、ＯＯＰに適している。ＯＯＰを用いると、上述した
ワークフローエンジンについて、基本的な機能のみを有
する上位階層（スーパークラス）から具体的かつ個別な
機能を有する下位階層（サブクラス）までを含む、階層
構造を有するワークフローエンジンとして定義できる。
このとき、オブジェクト定義コードおよびフロー定義コ
ードは、ワークフローエンジンに参照されるオブジェク
トとなる。

【００５１】図３は、図１のワークフロー管理システム
の具体的な機能構成を概略的に示した図であって、図１
に示すワークフローエンジンに代えてクラス構造すなわ
ち階層構造を有するワークフローエンジンを用いる場合
のワークフロー管理システムについて、その主要な機能
単位の相互関係を概略的に示すブロック図である。な
お、図３の各機能単位は、ハードウェア資源としてのＣ
ＰＵがその機能単位に対応するプログラムを実行するこ
とにより、仮想的にＣＰＵに存在する機能単位である。
ただし、便宜上、図３ではワークフローエンジンサブク
ラスＦ２７ａおよびＦ２７ｂは、それぞれホスト計算機
ｈ２およびｈ３の各ＣＰＵで動作する仮想的な機能単位
として示してある。

【００５２】図４は、図３のワークフロー管理システム
の各機能単位を動作させるネットワークシステムの一例
を示す図である。図４には３つのホスト計算機ｈ１、ｈ
２およびｈ３が接続されたネットワークシステムが示さ
れている。図４に示すように、各ホスト計算機ｈ１、ｈ
２およびｈ３は、ＣＰＵｃ１、ｃ２およびｃ３と、ハー
ドディスクや光ディスク等の記憶装置ｍ１、ｍ２および
ｍ３と、マンマシンインターフェース用の入力装置ｉ
１、ｉ２およびｉ３とを具える。また、図示せずも、各
ホスト計算機ｈ１、ｈ２およびｈ３は一般に表示装置等
を有する。既に説明したようにＣＰＵｃ１、ｃ２および
ｃ３は、各機能単位を駆動するための制御部を有してい
る。また、ＣＰＵｃ１、ｃ２およびｃ３には各ハードウ
ェア資源を駆動するドライバソフトや一般的なＯＳソフ
ト等が動作していても良い。なお、図４は、ワークフロ
ー管理システムの各構成が存在できる計算機の一例を示
しているに過ぎない。

【００５３】ここで具体的なワークフロー処理の例とし
て、２つのアクティビティからなるワークフロー処理を
実施する。すなわち、図３および図４に示すように、こ
のワークフロー処理では、先ず起票者２４がホスト計算
機ｈ１を操作してワークフロー処理のプロセスを定義
し、次に処理者３１ａがホスト計算機ｈ２を操作してア
クティビティを実行し、その後、処理者３１ｂがホスト
計算機ｈ３を操作してアクティビティを実行する。

【００５４】図３および図４に示すワークフローエンジ
ンは、上位階層から下位階層までの複数の階層構造を有
する。すなわち、このワークフローエンジンを機能させ
るコードは、上位階層のワークフローエンジンコード
（ワークフローエンジンスーパークラスコード）Ｄ２７
ｓ、下位階層のワークフローエンジンコード（ワークフ
ローエンジンサブクラスコード）Ｄ２７ａおよびＤ２７
ｂという２層の階層構造を有している。

【００５５】ただし、ここではワークフローエンジンコ
ード生成手段Ｆ１９は、ソースプログラムコードである
ワークフローエンジンサブクラスコードＤ２７ａおよび
Ｄ２７ｂを生成する。なお、このワークフローエンジン
サブクラスコードＤ２７ａは、ワークフローエンジンサ
ブクラスＦ２７ａを機能させ、ワークフローエンジンサ
ブクラスコードＤ２７ｂは、ワークフローエンジンサブ
クラスＦ２７ｂを機能させる。

【００５６】このように階層構造を有するワークフロー
エンジンを用いる場合、下位階層のワークフローエンジ
ンコードのみを生成するのが好ましい。

【００５７】周知の如く、ワークフローエンジンサブク
ラスＦ２７ａおよびＦ２７ｂは、ワークフローエンジン
スーパークラス（図中では機能単位ではなくコードとし
て示してある。）Ｄ２７ｓから機能的な継承（インヘリ
タンス）を行うことができる。したがって、ワークフロ
ーエンジンスーパークラスコードＤ２７ｓで基本機能を
定義しておけば、ワークフローエンジンサブクラスＦ２
７ａおよびＦ２７ｂでは、当該基本機能を継承できる。
そのため、ワークフローエンジンサブクラスコードＤ２
７ａおよびＤ２７ｂでは、当該基本機能と異なる機能の
みを定義すればよい。

【００５８】このように、ワークフローエンジンコード
生成手段Ｆ１９は、ＯＯＰに基づいて、基本機能を定義
した上位階層のワークフローエンジンコードＤ２７ｓか
ら機能的な継承をする下位階層のワークフローエンジン
コードＤ２７ａおよびＤ２７ｂであって、かつ、具体的
な固有の機能を定義した下位階層のワークフローエンジ
ンコードＤ２７ａおよびＤ２７ｂを生成するのが好まし
い。それにより、ワークフローエンジンとして機能させ
る全体のソースプログラムコードの記述を簡略化できる
ため、ワークフローエンジンコードを容易に生成でき
る。それと同時に、ワークフローエンジンコードの記憶
装置内の占有メモリを低減できる。なお、図３に示すよ
うに、ワークフローエンジンスーパークラスコードＤ２
７ｓ等を含むクラスライブラリＤ５２は、例えばプログ
ラム格納部２１に設けておく。

【００５９】また、スーパクラスからサブクラスに渡る
階層構造を有するワークフローエンジンコードについ
て、ワークフローエンジンサブクラスコードＤ２７ａお
よびＤ２７ｂに通信機能を設定して互いにアクセスでき
るようにしておけば、ワークフローエンジンサブクラス
Ｄ２７ａおよびＤ２７ｂは、それぞれネットワークシス
テム内の任意のホスト計算機に分散して存在できる。よ
って、負荷分散によるネットワークシステムの効率およ
び安定性の向上が実現できる。

【００６０】なお、ここでは、図４に示すように、ホス
ト計算機ｈ１にて生成されたワークフローエンジンサブ
クラスコードＤ２７ａおよびＤ２７ｂは、それぞれホス
ト計算機ｈ２およびｈ３に分散している。このように、
図４のワークフローエンジンサブクラスコードＤ２７ａ
はホスト計算機ｈ２で動作して図３に示すワークフロー
エンジンサブクラスＦ２７ａとして機能し、図４のワー
クフローエンジンサブクラスコードＤ２７ｂはホスト計
算機ｈ３で動作して図３に示すワークフローエンジンサ
ブクラスＦ２７ｂとして機能する。図３および図４に示
すように、処理者３１ａは、ホスト計算機ｈ２を操作す
ることによりアクティビティを行い。その後、処理者３
１ｂは、ホスト計算機ｈ３を操作することにより別のア
クティビティを行う。このように、ワークフローエンジ
ンコードを生成するとき、各処理者のホスト計算機毎
に、互いに異なるワークフローエンジンサブクラスを定
義するのが良い。それにより、容易に処理者の特定がで
きるため、ワークフロー処理のプロセスを定義すること
が容易となる。

【００６１】ここでは、上述のごとく処理者毎に下位階
層のワークフローエンジンコードを生成するため、次の
ようなプロセス定義情報を生成する。すなわち、図３で
は、前述したプロセス定義情報として例えばプロセス定
義スクリプトＤ４３を用いる。このとき、起票者２４は
例えばホスト計算機ｈ１の入力装置ｉ１を操作してプロ
セス定義スクリプトＤ４３を入力する。このプロセス定
義スクリプトＤ４３は、オブジェクト定義スクリプトＤ
４３ａおよびフロー定義スクリプトＤ４３ｂを含む。

【００６２】このとき、ホスト計算機ｈ１のＣＰＵｃ１
にＯＳソフトやエディタソフトを動作させておくと、記
憶装置ｍ１にはデータとしてのプロセス定義スクリプト
Ｄ４３が格納される。なお、このプロセス定義スクリプ
トＤ４３は、ワークフロー処理のプロセス定義に関する
情報を簡単な内部コードで記述したデータである。ただ
し、ここでいう内部コードとはスクリプト識別手段Ｆ４
５が認識できるコードである。

【００６３】図５は、具体的なワークフロー処理に対す
るプロセス定義スクリプトの一例である。図５に示すプ
ロセス定義スクリプトは、オブジェクト定義スクリプト
Ｄ４３ａおよびフロー定義スクリプトＤ４３ｂを含む。

【００６４】また、これらのスクリプトＤ４３ａおよび
Ｄ４３ｂを相互に識別するため、各スクリプトＤ４３ａ
およびＤ４３ｂには異なる識別子が付加されている。図
５に示す例では、識別子engines および識別子flowがフ
ロー定義スクリプトＤ４３ｂを示し、識別子doがオブジ
ェクト定義スクリプトＤ４３ａを示す。

【００６５】識別子engines はワークフローエンジンサ
ブクラス名を指定する。ここでは、各処理者３１ａおよ
び３１ｂ毎に異なるワークフローエンジンサブクラスコ
ードが生成されているため、ワークフローエンジンサブ
クラス名によって各アクティビティを実行する処理者３
１ａおよび３１ｂを定義している。例えば、図５に示す
ように、処理者３１ａに対してはワークフローエンジン
サブクラスＦ２７ａ（loanTeller）を定義し、処理者３
１ｂに対してはワークフローエンジンサブクラスＦ２７
ｂ（loanDecision）を定義している。

【００６６】識別子flowは、ワークフローエンジンサブ
クラス名を順次に指定することにより、アクティビティ
の処理順序を定義する。すなわち図３では、ワークフロ
ーエンジンサブクラスＦ２７ａ（loanTeller）およびＦ
２７ｂ（loanDecision）の順に、アクティビティが実行
される。

【００６７】識別子doは、各アクティビティにおける処
理内容を定義する。すなわち図５に示すように、ワーク
フローエンジンサブクラスＦ２７ａ（loanTeller）では
メソッドstart という処理内容が定義され、ワークフロ
ーエンジンサブクラスＦ２７ｂ（loanDecision）ではメ
ソッドdecideLoanという処理内容が定義される。

【００６８】図３に示すように、このようなプロセス定
義スクリプトＤ４３は、ホスト計算機ｈ１のＣＰＵｃ１
で動作するスクリプト識別手段Ｆ４５に読み込まれる。
このとき、スクリプト識別手段Ｆ４５は、プロセス定義
スクリプトＤ４３に含まれる識別子に基づいて、プロセ
ス定義スクリプトＤ４３をオブジェクト定義スクリプト
Ｄ４３ａおよびフロー定義スクリプトＤ４３ｂに分離す
る。その後、スクリプト識別手段Ｆ４５は、ホスト計算
機ｈ１に分離したオブジェクト定義スクリプトＤ４３ａ
およびフロー定義スクリプトＤ４３ｂを記憶装置ｍ１に
格納する。なお、スクリプト識別手段Ｆ４５は、図４に
示すホスト計算機ｈ１の記憶装置ｍ１に格納されている
スクリプト識別プログラム（図示せず）をＣＰＵｃ１が
読み出してかつ実行することにより、機能する仮想的な
機能単位である。

【００６９】なお、プログラム格納部２１は、具体的に
言うと、次のような基本機能提供プログラムＤ２２を有
する。すなわち、プログラム格納部２１は、例えば、 新規にワークフロー処理を開始させる機能を実現する
基本機能提供プログラムＤ２２と、 実行中のワークフロー処理の進行状況を確認する機能
を実現する基本機能提供プログラムＤ２２と、 ワークフロー処理を中止する機能を実現する基本機能
提供プログラムＤ２２と、 ワークフロー処理における全てのアクティビティの終
了を確認する機能を実現する基本機能提供プログラムＤ
２２と、 中止または終了したワークフロー処理に関する情報を
破棄する機能を実現する基本機能提供プログラムＤ２２
と、 処理者毎に設けられたワークリストにワークアイテム
を付加する機能を実現する基本機能提供プログラムＤ２
２と、 ワークリストにおけるワークアイテムの削除によって
アクティビティの終了を認識する機能を実現する基本機
能提供プログラムＤ２２とを有する。

【００７０】なお、図４に示すように、ここでは階層構
造を有するワークフローエンジンのクラスがホスト計算
機ｈ１、ｈ２およびｈ３に分散して存在しているため、
プログラム格納部２１は、ワークフローエンジンサブ
クラスが他のワークフローエンジンと相互に通信するた
めの通信機能を実現する基本機能提供プログラムＤ２２
を有するのが好ましい。また、プログラム格納部２１
は、人間による処理を必要としないアクティビティに
ついて、起動アプリケーションによってアクティビティ
を自動処理する基本機能提供プログラムＤ２２を有して
も良い。また、図４に示すように、プログラム格納部２
１は、例えばホスト計算機ｈ１の記憶装置ｍ１のデータ
領域として設けられる。

【００７１】また、Ｊａｖａ言語によるＯＯＰを行うに
は、プログラム格納部２１が、ワークフローエンジンの
スーパークラス等のワークフロー処理に利用できるクラ
スを定義したクラスライブラリ５２を有するのが望まし
い。図３では、クラスライブラリＤ５２はワークフロー
エンジンスーパークラスコードＤ２７ｓ（DWorkflowEng
ine ）およびその他のスーパークラスコードＤ２７ｔ
（LoanApp2）を含む。

【００７２】ワークフローエンジンコード生成手段Ｆ１
９は、記憶装置ｍ１のプログラム格納部２１から上述の
ような〜の基本機能提供プログラムＤ２２、記憶装
置ｍ１に蓄積されたオブジェクト定義スクリプトＤ４３
ａおよびフロー定義スクリプトＤ４３ｂを読み出したの
ち、読み出された〜の基本機能提供プログラムＤ２
２を組み合わせて、ワークフローエンジンサブクラスＦ
２７ａ（LoanTeller）およびＦ２７ｂ（LoanDecision）
として機能するワークフローエンジンサブクラスコード
Ｄ２７ａ（LoanTeller）およびＤ２７ｂ（LoanDecisio
n）を生成する。

【００７３】このとき、ワークフローエンジンコード生
成手段Ｆ１９は、ワークフロー処理に関するオブジェク
ト定義スクリプトＤ４３ａおよびフロー定義スクリプト
Ｄ４３ｂを解釈することにより、当該ワークフロー処理
に必要な基本機能のみを有するワークフローエンジンサ
ブクラスコードＤ２７ａ（LoanTeller）およびＤ２７ｂ
（LoanDecision）を生成する。すなわち、ワークフロー
エンジンコード生成手段Ｆ１９は、オブジェクト定義ス
クリプトＤ４３ａおよびフロー定義スクリプトＤ４３ｂ
で定義されたワークフロー処理に必要な基本機能のみを
読み込みかつ不必要な機能を読み込まない。例えば、ス
クリプト識別手段Ｆ４５から読み出されたオブジェクト
定義スクリプトＤ４３ａおよびプログラム格納部２１か
ら読み出された〜の基本機能の幾つかを組み合わせ
て、ワークフローエンジンサブクラスコードＤ２７ａ
（LoanTeller）およびＤ２７ｂ（LoanDecision）が生成
される。そのため、このワークフローエンジンサブクラ
スコードＤ２７ａ（loanTeller）およびＤ２７ｂ（Loan
Decision）は、必要最低限の構成のみを有し、従って占
有メモリが小さくなる。具体的に言うと、例えば、従来
のワークフローエンジンでは任意のステップ数のアクテ
ィビティが処理できなければならないが、実施の形態の
ワークフローエンジンは、２つのアクティビティが処理
できればよいため、余分なクラスやメソッドの定義を省
略したコードとなる。

【００７４】オブジェクト定義コード生成手段Ｆ１５
は、記憶装置ｍ１のプログラム格納部２１から上述のよ
うな基本機能提供プログラムＤ２２と、記憶装置ｍ１に
蓄積されたオブジェクト定義スクリプトＤ４３ａとを読
み出したのち、読み出された基本機能提供プログラムＤ
２２およびオブジェクト定義スクリプトＤ４３ａを組み
合わせてオブジェクト定義コードＤ４７ａを生成する。

【００７５】フロー定義コード生成手段Ｆ１７は、記憶
装置ｍ１のプログラム格納部２１から上述のような基本
機能提供プログラムＤ２２と、記憶装置ｍ１に蓄積され
たフロー定義スクリプトＤ４３ｂとを読み出したのち、
読み出された基本機能提供プログラムＤ２２およびフロ
ー定義スクリプトＤ４３ｂを組み合わせてフロー定義コ
ードＤ４７ｂを生成する。

【００７６】図６および図７は、オブジェクト定義コー
ド生成手段Ｆ１５およびフロー定義コード生成手段Ｆ１
７によってＪａｖａ言語によるソースプログラムコード
として生成されたオブジェクト定義コードＤ４７ａおよ
びフロー定義コードＤ４７ｂの一部を示した図である。

【００７７】図６に示すソースプログラムコードのうち
１〜２行目のコードは、ワークフローエンジンのスーパ
ークラスコードＤ２７ｓ（DWorkflowEngine ）に対する
サブクラスコードＤ２７ａ（loanDecision）を定義す
る。３〜７行目のコードは、ワークフローエンジンサブ
クラスコードＤ２７ｂ（loanDecision）について例外処
理を宣言している。８行目〜１１行目のコードは、ワー
クフローエンジンサブクラスコードＤ２７ｂ（loanDeci
sion）における処理内容を示すメソッドdecideloanを定
義する。また、１２〜２４行目のコードは、ワークフロ
ーエンジンサブクラスコードＤ２７ｂ（loanDecision）
を開始したとき最初に実行されるメソッドが定義され
る。

【００７８】図７に示すソースプログラムコードのうち
１〜２行目のコードによって、ワークフロー処理に必要
なその他のスーパークラスコードＤ２７ｔ（LoanApp2）
のサブクラスLoanFlow2 が定義される。３〜７行目のコ
ードは、その他のスーパークラスコードＤ２７ｔ（Loan
Flow2 ）の初期化および名前の定義を行う。８〜２６行
目のコードは、loanFlow2 に用いるワークフローエンジ
ンサブクラスコードＤ２７ａ（loanTeller）およびＤ２
７ｂ（loanDecision）を登録する。２７〜３１行目のコ
ードは、ワークフローエンジンサブクラスコードＤ２７
ａ（loanTeller）およびＤ２７ｂ（loanDecision）の名
前のテーブルを作成する。３２〜３４行目のコードは、
ワークフロー処理の名前のテーブルを作成する。３５〜
３７行目のコードは、ワークフロー処理のタイムリミッ
トテーブルを作成する。３８〜４０行目のコードは、ワ
ークフロー処理の終了を判定するテーブルを作成する。

【００７９】また、実際にワークフロー処理を行うと
き、図３に示すワークフローエンジンサブクラスＦ２７
ａ（loanTeller）およびＦ２７ｂ（LoanDecision）が駆
動して、オブジェクト定義コードＤ４７ａおよびフロー
定義コードＤ４７ｂのクラスやメソッドの参照を行うこ
とにより、ワークフロー処理を制御する。

【００８０】また、実際にワークフロー処理を行うと
き、オブジェクト定義コードＤ４７ａおよびフロー定義
コードＤ４７ｂには、プロセスに関する定義が記述され
ていなければならない。これらの定義コードＤ４７ａお
よびＤ４７ｂは、一つのステップで生成しても良いし、
或いは複数ステップに分けて生成しても良い。例えば、
コードジェネレータＦ２８では基本的な定義コードのみ
を生成し、基本的な定義コードに具体的な定義コードを
追加することにより、定義コードを完成させても良い。
言い換えれば、複数ステップに分けてオブジェクト定義
コードＤ４７ａやフロー定義コードＤ４７ｂを生成する
場合、先ずオブジェクト定義基本コードとして各アクテ
ィビティに共通の処理内容を定義するコードを生成し、
および、オブジェクト定義拡張コードとして個々のアク
ティビティに固有の処理内容を定義するコードをオブジ
ェクト定義基本コードに追加することにより、オブジェ
クト定義コードを生成しても良い。具体的に言うと、図
６のオブジェクト定義コードＤ４７ａは、８〜９行目の
ブロックにオブジェクト定義拡張コードとして、個々の
アクティビティに固有のメソッドが追加されると、オブ
ジェクト定義コードとして完成する。このように、オブ
ジェクト定義コード生成手段Ｆ１５がオブジェクト定義
基本コードを生成したのち、オブジェクト定義基本コー
ドにオブジェクト定義拡張コードを付加するのが好まし
い。それにより、個々のオブジェクト定義コードが簡潔
となる。

【００８１】なお、説明の都合上、仮想的な各機能単位
である識別手段、ワークフローエンジンコード生成手
段、オブジェクト定義コード生成手段、フロー定義コー
ド生成手段を特定の同一ホスト計算機のＣＰＵに存在さ
せたが、これら各機能単位は任意のホスト計算機のＣＰ
Ｕに存在できる。また、プログラム格納部２１、オブジ
ェクト定義コードＤ４７ａ、フロー定義コードＤ４７ｂ
も任意のホスト計算機の記憶装置に存在して良い。

【００８２】以上のような手順で、プロセス定義スクリ
プトでワークフロー処理のプロセスを定義することによ
り、ワークフローエンジンサブクラスコードＤ２７ａ
（LoanTeller）およびＤ２７ｂ（LoanDecision）と、オ
ブジェクト定義コードＤ４７ａと、フロー定義コードＤ
４７ｂとが生成できる。ただし、ワークフロー処理の開
始の際には、ホスト計算機ｈ１で生成されたワークフロ
ーエンジンサブクラスコードＤ２７ａ（LoanTeller）お
よびＤ２７ｂ（LoanDecision）を、それぞれホスト計算
機ｈ２およびホスト計算機ｈ３に分散させる。

【００８３】従来のワークフロー管理システムと同様
に、図３に示す各ワークフローエンジンサブクラスＦ２
７ａ(loanTeller)およびＦ２７ｂ（LoanDecision）と同
一ホスト計算機には、各々ワークリストＤ５３ａおよび
Ｄ５３ｂと、ワークリストハンドラＦ５５ａおよびＦ５
５ｂとが設けられている。ワークリストＤ５３ａおよび
Ｄ５３ｂは、個々の処理者３１ａおよび３１ｂ毎に設け
られる。

【００８４】各ホスト計算機ｈ２およびｈ３では次のよ
うな処理が行われる。すなわち、先ず、各処理者３１ａ
は、ワークフローエンジンサブクラスＦ２７ａ(loanTel
ler)によってワークリストＤ５３ａに示されたワークア
イテムを参照する。それにより、処理者３１ａは処理す
べきアクティビティを認識する。そして、処理者３１ａ
はクライアントアプリケーションＤ５７等を用いてアク
ティビティを実行する。アクティビティに含まれる作業
が終了すると、ワークリストハンドラＦ５５ａはワーク
リストＤ５３ａからワークアイテムを削除する。それに
より、ワークフローエンジンサブクラスＦ２７ａ（loan
Teller）は、アクティビティの終了を検出する。その
後、ワークフローエンジンＦ２７ａ（loanTeller）は、
アクティビティで処理されたデータを次のワークフロー
エンジンＦ２７ｂ（loanDecision）に送付する。

【００８５】そして、各処理者３１ｂは、ワークフロー
エンジンサブクラスＦ２７ｂ（loanDecision）によって
ワークリストＤ５３ｂに示されたワークアイテムを参照
する。処理者３１ｂは処理すべきアクティビティを認識
する。そして、処理者３１ｂはクライアントアプリケー
ションＤ５７等を用いてアクティビティを実行する。ア
クティビティが終了すると、処理者３１ｂはワークリス
トハンドラＦ５５ｂを操作してワークリストＤ５３ｂか
らワークアイテムを削除する。それにより、ワークフロ
ーエンジンサブクラスＦ２７ｂ（loanDecision）は、ア
クティビティの終了を検出する。同時に、ワークフロー
エンジンＦ２７ｂ（loanDecision）は、ワークフロー処
理の全てのアクティビティの終了を検出して、例えば処
理者３１ａ等にワークフロー処理の終了および結果を通
知する。

【００８６】続いて、上述のワークフロー管理システム
を一適用例としてワークフロー処理のプロセスを変更す
る方法につき説明する。

【００８７】実施の形態のワークフロー管理システムの
プロセスの変更は、オブジェクト定義コードＤ２５ａ
（Ｄ４７ａ）或いはフロー定義コードＤ２５ｂ（Ｄ４７
ｂ）を書き換えて行う。したがって、従来技術のワーク
フロー管理システムのようにプロセス定義データそのも
のを書き換える必要がない。すなわち、実施の形態のワ
ークフロー管理システムによれば、各アクティビティの
処理内容のみを変更したい場合にはオブジェクト定義コ
ードＤ２５ａのみを修正し、アクティビティの順序のみ
を変更したい場合にはフロー定義コードＤ２５ｂのみを
修正すればよい。

【００８８】具体的に言うと、例えば図７のフロー定義
コードに従うワークフロー処理において、処理者を変更
したい場合には、フロー定義コードに記述されたワーク
フローエンジンサブクラス（loanDecision）を別のワー
クフローエンジンサブクラスに名称の変更をすればよ
い。また、例えば図６のオブジェクト定義コードに従う
ワークフロー処理において、ワークフローエンジンサブ
クラス（loanDecision）の処理内容を変更したい場合に
は、オブジェクト定義コードの処理内容を示すメソッド
decideLoanを修正すればよい。このように、オブジェク
ト定義コード或いはフロー定義コードの一方の修正が他
方の修正に影響しないため、プロセスは容易に変更でき
る。

【００８９】オブジェクト定義コード或いはフロー定義
コードを修正するには、前述のワークフロー管理システ
ムが、オブジェクト定義コードおよび前述のフロー定義
コードを高水準言語のコードの状態で保存する定義コー
ド保存手段（図示していない。）を更に具えるるのが望
ましい。

【００９０】図６および図７に示すオブジェクト定義コ
ードおよびフロー定義コードは、ワークフロー処理を開
始する前に生成される。これらの定義コードはこの実施
の形態ではソースプログラムである。これらの定義コー
ドはコンパイルされることにより、動作可能なオブジェ
クトプログラムとなる。例えば、Ｊａｖａ言語ソースプ
ログラムをコンパイルすると、ソースプログラムはプラ
ットフォームに依存せずに動作するバイトコードに変換
されて実行型プログラムとなる。コンパイルしたバイト
コードデータそのものを書き換えるのは困難であるか
ら、コンパイルする前の状態すなわち例えばＪａｖａ言
語のソースプログラムコードを保存しておく。それによ
り、各アクティビティにおける処理内容或いは処理順序
を変更する際、Ｊａｖａ言語のソースプログラムコード
の一部を修正することにより、新たなオブジェクト定義
コード或いはフロー定義コードが作成できる。新たな定
義コードを、コンパイルしてバイトコードに変換したの
ち修正前のバイトコードデータと置換すれば、プロセス
に関する定義が修正できる。

【００９１】（第２の実施の形態）以下の第２の実施の
形態では、第１の実施の形態のワークフロー管理システ
ムに宛名変換手段を設けた形態につき説明する。ただ
し、ここでは特に階層構造を有するワークフローエンジ
ンを設けている形態につき説明する。第１の実施の形態
にて説明したワークフロー管理システムでは、アクティ
ビティの処理順序はフロー定義コードに静的に定義され
る。すなわち、アクティビティの処理者を示すコードに
は具体的な宛先が示されており、人事異動等による宛先
の変更すなわちアクティビティの順序の変更があった場
合、フロー定義コードを書き換える必要がある。

【００９２】ところで、文献Ｉ等に開示されている宛名
変換手段を用いると、動的に処理順序を定義できるた
め、プロセス定義データを修正する必要が無くなること
が知られている。しかしながら、文献Ｉに開示されるワ
ークフロー管理システムの場合、ワークフローエンジン
はサーバで、また、宛名変換手段はワークフローエンジ
ンと同一のサーバで動作する。そのため、宛名変換手段
を含むサーバの負担が大きくなる。また、実際にサーバ
がダウンしたときには、ワークフロー処理が中断されて
しまうという問題があった。

【００９３】図８は、第２の実施の形態のワークフロー
管理システムを動作させるワークフロー管理システムの
各機能単位を模式的かつ概略的に示すブロック図であ
る。ただし、図８では図４と同一の機能単位については
示しておらず、図４と異なる点のみすなわちワークフロ
ーエンジンサブクラスＦ２７ａ、Ｆ２７ｂおよび宛名変
換手段Ｆ６７が示される。

【００９４】図８に示すように、第２の実施の形態のワ
ークフロー管理システムは、宛名変換手段Ｆ６３を有す
る。ここで、ホスト計算機ｈ４のＣＰＵｃ４が記憶装置
ｍ４の宛名変換プログラムＤ６３を読み出しかつ実行す
ることにより、宛名変換手段Ｆ６３は仮想的な機能手段
としてＣＰＵｃ４で動作する。

【００９５】図８に示すワークフローエンジンは、ＯＯ
Ｐによってプログラミングされており、スーパークラス
から複数のサブクラスＦ２７ａおよびＦ２７ｂに機能を
継承するクラス構造を有する。そして、個々のワークフ
ローエンジンサブクラスＦ２７ａおよびＦ２７ｂは、各
処理者毎に分散して存在するため、互いにアクセスする
ための各通信機能Ｆ６７ａおよびＦ６７ｂを有する。

【００９６】そして、この第２の実施の形態の宛名変換
手段Ｆ６３は、特に、通信機能Ｆ６７ｔを備える点を特
徴とする。よって、宛名変換手段Ｆ６３と、複数のワー
クフローエンジンサブクラスＦ２７ａおよびＦ２７ｂと
は通信によって互いにアクセスできる。

【００９７】宛名変換手段Ｆ６３は、周知のごとく、課
長や部長など組織内の役職等を示す一般的宛先名を、処
理者の名前等の具体的宛先名に変換する機能モジュール
である。また、この宛名変換手段Ｆ６３は、従来構成と
同様に組織／役割データＤ６５を参照する。例えば備品
購入の決裁のワークフロー処理を行う場合、決裁ルート
は役職で決定されることが多いから、予め宛先名を役職
で指定する。そのため、決裁ルートに沿う役職にある処
理者が人事異動等によって他の処理者に変わっても動的
に宛先が判断されるため、決裁ルートすなわち宛先名を
変更する必要が無い。

【００９８】ここで図８を参照して、宛名変換手段６３
によって一般的宛先名から具体的宛先名を判断する流れ
について説明する。

【００９９】ワークフローエンジンサブクラスＦ２７ａ
は、フロー定義コード中に定義されたアクティビティの
処理者が一般的な宛先名で記述されている場合、先ず、
そのワークフロー処理を開始させたワークフローエンジ
ンサブクラス名すなわち処理者を調べる。次に、ワーク
フローエンジンサブクラスＦ２７ａは、各通信機能Ｆ６
７ａおよびＦ６７ｔを介して宛名変換手段Ｆ６３とネッ
トワーク通信することにより、一般的宛先名および開始
者名を宛名変換手段Ｆ６３に送信する。

【０１００】このとき、宛名変換手段６３は、実行中の
ワークフロー処理の開始者名から開始者の組織内の役割
（所属部署や役職等）を認識すると共に、この開始者の
役割および一般的宛先名から次のアクティビティを担当
する処理者名を調べる。そして、次の処理者名からワー
クフローエンジンサブクラス名を得て、次のアクティビ
ティを処理すべきワークフローエンジンサブクラス名
を、ワークフローエンジンサブクラスＦ２７ａに送信す
る。そして、この後、次のアクティビティを処理べきワ
ークフローエンジンサブクラスＦ２７ｂが起動する。

【０１０１】以上のように、第２の実施の形態では、図
８に示すようにワークフローエンジンが階層構造をなす
複数のワークフローエンジンサブクラスＦ２７ａおよび
Ｆ２７ｂとして異なるホスト計算機ｈ３およびｈ４に分
散しており、および、宛名変換手段Ｆ６３が通信機能を
有する。すなわち、ホスト計算機ｈ２ではワークフロー
エンジンサブクラスＦ２７ａが動作し、ホスト計算機ｈ
３ではワークフローエンジンサブクラスＦ２７ｂが動作
し、および、ホスト計算機ｈ４では宛名変換手段Ｆ６３
が動作する。このように、宛名変換手段Ｆ６３と、ワー
クフローエンジンサブクラスＦ２７ａおよびＦ２７ｂと
が異なるホスト計算機に存在しても、宛名変換手段Ｆ６
３が通信機能Ｆ６７ｔを有するため、宛名変換手段Ｆ６
３はワークフローエンジンサブクラスＦ２７ａおよびＦ
２７ｂと互いに通信できる。したがって、宛名変換手段
Ｆ６３を任意のホスト計算機に移動させることができ
る。すなわち、従来のように宛名変換手段Ｆ６３をワー
クフローエンジンと同一ホストに設ける必要がない。

【０１０２】そのため、宛名変換手段を含むホスト計算
機の負担を小さくしシステムダウンの可能性を低減させ
ることができる。また、宛名変換手段を含むホスト計算
機がシステムダウンしたときでも、別のホスト計算機に
宛名変換手段を移動することによって、ワークフロー処
理を続行できる。

【０１０３】

【発明の効果】上述した説明から明らかなように、この
発明のワークフロー管理システムによれば、ワークフロ
ー処理のプロセスを定義をする際、起票者が入力したプ
ロセス定義情報は、識別手段によってフロー定義に関す
る部分およびオブジェクト定義に関する部分に分離され
たのち、フロー定義コード生成手段およびオブジェクト
定義コード生成手段によってコード化される。そのた
め、ワークフロー処理を行うとき、各アクティビティに
おける処理内容およびアクティビティの順序を変更する
場合であっても、プロセス定義データそのものを修正す
る必要がない。言い換えれば、各アクティビティにおけ
る処理内容のみを変更したい場合にはオブジェクト定義
コードのみを修正すれば良く、アクティビティの順序
（アクティビティを行う処理者の変更）を変更したい場
合にはフロー定義コードのみを修正すればよい。したが
って、プロセスを能率的にかつ容易に変更することがで
きる。

【０１０４】また、この発明のコードジェネレータによ
れば、識別手段が、プロセス定義情報をオブジェクト定
義情報およびフロー定義情報に分離させたのち、オブジ
ェクト定義情報からオブジェクト定義コードを生成しか
つフロー定義情報からフロー定義コードを生成する。そ
のため、各工程における処理内容のみを変更したい場合
にはオブジェクト定義コードを修正し、工程の処理順序
のみを変更したい場合にはフロー定義コードを修正すれ
ばよい。よって、プロセスを能率的にかつ容易に変更す
ることができる。

【０１０５】また、このワークフロー処理のプロセスの
変更方法の発明によれば、プロセス定義情報から、オブ
ジェクト定義コードおよびフロー定義コードを生成する
ワークフロー処理のプロセスを変更するのに、各工程の
処理内容のみを変更する場合にはオブジェクト定義コー
ドのみを修正し、工程の処理順序のみを変更する場合に
はフロー定義コードのみを修正する。したがって、この
プロセスの変更方法によれば、各工程における処理内容
のみを変更したい場合若しくは工程の処理順序のみを変
更したい場合のいずれにも、互いに独立に存在するオブ
ジェクト定義コード或いはフロー定義コードの一方を修
正することにより対応できる。よって、プロセスを能率
的にかつ容易に変更できる。

【図面の簡単な説明】

【図１】第１の実施の形態のワークフロー管理システム
の機能単位の相互関係を概略的に示すブロック図であ
る。

【図２】図１の各機能単位を１台のホスト計算機で動作
させた場合を例として、各機能単位によるハードウェア
資源の利用形態を概略的に示す図である。

【図３】図１のワークフロー管理システムの具体的な機
能構成を概略的に示した図である。

【図４】図３のワークフロー管理システムの各機能単位
を動作させるネットワークシステムの一例を示す図であ
る。

【図５】具体的なワークフロー処理に対するプロセス定
義スクリプトの一例である。

【図６】ソースプログラムコードとして生成されたオブ
ジェクト定義コードの一部を示した図である。

【図７】ソースプログラムコードとして生成されたフロ
ー定義コードの一部を示した図である。

【図８】第２の実施の形態のワークフロー管理システム
を動作させるネットワークシステムの各機能単位を模式
的かつ概略的に示すブロック図である。

【図９】従来のワークフロー管理システムの構成を示す
ブロック図である。

【符号の説明】

１１、４１：ワークフロー管理システム Ｆ１３：識別手段 Ｄ１３：識別プログラム Ｆ１５：オブジェクト定義コード生成手段 Ｄ１５：オブジェクト定義コード生成プログラム Ｆ１７：フロー定義コード生成手段 Ｄ１７：フロー定義コード生成プログラム Ｆ１９：ワークフローエンジンコード生成手段 Ｄ１９：ワークフローエンジンコード生成プログラム ２１：プログラム格納部 Ｄ２２：基本機能提供プログラム Ｄ２３：プロセス定義情報 Ｄ２３ａ：オブジェクト定義情報 Ｄ２３ｂ：フロー定義情報 ２４：起票者 Ｄ２５ａ、Ｄ４７ａ：オブジェクト定義コード Ｄ２５ｂ、Ｄ４７ｂ：フロー定義コード Ｄ２７：ワークフローエンジンコード Ｆ２７ａ、Ｆ２７ｂ：ワークフローエンジンサブクラス Ｄ２７ａ、Ｄ２７ｂ：ワークフローエンジンサブクラス
コード Ｄ２７ｓ：ワークフローエンジンスーパークラスコード Ｄ２７ｔ：その他のスーパークラスコード Ｆ２８：コードジェネレータ ３１ａ、３１ｂ：処理者 Ｄ４３：プロセス定義スクリプト Ｄ４３ａ：オブジェクト定義スクリプト Ｄ４３ｂ：フロー定義スクリプト Ｆ４５：スクリプト識別手段 Ｄ５２：クラスライブラリ Ｄ５３ａ、Ｄ５３ｂ：ワークリスト Ｆ５５ａ、Ｆ５５ｂ：ワークリストハンドラ Ｄ５７：クライアントアプリケーション Ｆ６３：宛名変換手段 Ｄ６３：宛名変換プログラム Ｄ６５：組織／役割データ Ｆ６７ａ、Ｆ６７ｂ、Ｆ６７ｔ：通信機能

Claims (7)

【特許請求の範囲】
1. 【請求項１】 複数の計算機を有するネットワークシス
   テムで、一連かつ複数の工程からなるワークフロー処理
   を、各工程における処理内容およびそれら工程の順序に
   関するプロセス定義情報に基づいて、各工程毎に行うワ
   ークフロー管理システムにおいて、 前記プロセス定義情報から、各工程における処理内容に
   関するオブジェクト定義情報と、工程の順序に関するフ
   ロー定義情報とを識別する識別手段と、 前記ワークフロー処理に用いる基本的な機能を提供する
   複数のプログラムを格納してあるプログラム格納部と、 識別された前記オブジェクト定義情報を解釈して該解釈
   に応じた前記プログラムを前記プログラム格納部から読
   み出すことにより、該読み出されたプログラムに基づい
   て各工程における処理内容に関するコードであるオブジ
   ェクト定義コードを生成するオブジェクト定義コード生
   成手段と、 前記フロー定義情報を解釈して該解釈に応じた前記プロ
   グラムを前記プログラム格納部から読み出すことによ
   り、該読み出されたプログラムに基づいて各工程の順序
   に関するコードであるフロー定義コードを生成するフロ
   ー定義コード生成手段と、 前記フロー定義コードおよび前記オブジェクト定義コー
   ドを解釈することにより、前記ワークフロー処理を制御
   するワークフローエンジンとを具えることを特徴とする
   ワークフロー管理システム。
2. 【請求項２】 請求項１に記載のワークフロー管理シス
   テムにおいて、 識別された前記オブジェクト定義情報および前記フロー
   定義情報を解釈して該解釈に応じた前記プログラムを前
   記プログラム格納部から読み出すことにより、該読み出
   されたプログラムに基づいてワークフローエンジンコー
   ドを生成するワークフローエンジンコード生成手段を更
   に具え、および、前記ワークフローエンジンコードによ
   って前記ワークフローエンジンを機能させることを特徴
   とするワークフロー管理システム。
3. 【請求項３】 請求項１に記載のワークフロー管理シス
   テムにおいて、 前記オブジェクト定義コードおよび前記フロー定義コー
   ドを高水準言語のコードの状態で保存する定義コード保
   存手段を更に具えることを特徴とするワークフロー管理
   システム。
4. 【請求項４】 請求項１に記載のワークフロー管理シス
   テムにおいて、 前記ワークフローエンジンが上位階層から複数の下位階
   層に機能を継承する階層構造を有し、かつ、個々の前記
   下位階層のワークフローエンジンは相互にアクセスする
   通信機能を有することを特徴とするワークフロー管理シ
   ステム。
5. 【請求項５】 請求項４に記載のワークフロー管理シス
   テムにおいて、 前記フロー定義コードに一般的な宛先名を予め定義する
   場合、該一般的宛先名から具体的宛先名を生成する宛名
   変換手段を更に具えており、および、 前記宛名変換手段が、前記下位階層のワークフローエン
   ジンと相互にアクセスする通信機能を有することを特徴
   とするワークフロー管理システム。
6. 【請求項６】 複数の計算機を有するネットワークシス
   テムで、一連かつ複数の工程からなるワークフロー処理
   を行う際、各工程における処理内容およびそれら工程の
   順序に関するプロセス定義情報から、ワークフローエン
   ジンの解釈できるプロセスに関するコードを生成するコ
   ードジェネレータであって、 前記プロセス定義情報から、各工程における処理内容に
   関するオブジェクト定義情報と、工程の順序に関するフ
   ロー定義情報とを識別する識別手段と、 前記オブジェクト定義情報から、ワークフローエンジン
   の解釈できるオブジェクト定義コードを生成するオブジ
   ェクト定義コード生成手段と、 前記フロー定義情報から、ワークフローエンジンの解釈
   できるフロー定義コードを生成するフロー定義コード生
   成手段とを具えることを特徴とするコードジェネレー
   タ。
7. 【請求項７】 一連かつ複数の工程からなるワークフロ
   ー処理を行う前に、各工程の処理内容および工程の処理
   順序に関するプロセス定義情報から、各工程の処理内容
   に関するオブジェクト定義情報と、工程の処理順序に関
   するフロー定義情報とを識別し、前記オブジェクト定義
   情報からワークフローエンジンの解釈できるオブジェク
   ト定義コードを生成し、かつ、前記フロー定義情報から
   ワークフローエンジンの解釈できるフロー定義コードを
   生成するワークフロー処理のプロセスを変更するに当た
   り、 各工程の処理内容のみを変更する場合にはオブジェクト
   定義コードのみを修正し、工程の処理順序のみを変更す
   る場合にはフロー定義コードのみを修正することを特徴
   とするワークフロー処理のプロセス変更方法。