JPH0683841A - 作業フロー管理システムと方法 - Google Patents

Abstract

(57)【要約】 【目的】 長時間運転作業フローの進行を実行かつトラ
ックし、かつ長時間運転作業フローの実行の間にシステ
ム障害から回復する作業フローの管理を目的とする。 【構成】 作業フローの各タイプはフロー150 としてモ
デル化され、アークと呼ばれるデータ信号パス154 によ
り相互接続された一組のステップ152 を具えている。フ
ロー150 はフローのネストを意味するサブフロー156 を
含むことができる。作業フローの各ステップ152 は入力
ポートと出力ポートを有しており、さらにフロー150 と
外界との間の入力事象と出力事象を写像するためにフロ
ー150 は特殊入力制御ステップ160 と出力制御ステップ
162 を有している。作業フローの判定規準は全作業フロ
ーが中間ストリームを失敗するなら節約できる作業単位
を遂行し、かつ拡張期間のシステムリソースと連合しな
い期間で十分短いことである。

Description

【発明の詳細な説明】

【０００１】

【技術分野】本発明は一般に計算機化された作業フロー
管理（work flow mangement ）、多重主体（multiple p
rincipals ）による協働的な参加を要求するコンピュー
タ化された協調（coordination）および計算機および／
または他の主体の分散された組により遂行されている長
時間運転プロセス（long running processes）の計算機
化された協調に関連している。

【０００２】

【背景技術】トランザクション処理の分野では、トラン
ザクションは典型的にはよく定義された開始と終了を有
する短期間計算（short lived computation)である。種
々のプロトコルはトランザクションのすべての関係者が
いかにしてトランザクションを終了させるかに同意する
ことを保証するために導入され、その大部分はいわゆる
２相コミット（２ＰＣ：two phase commit）プロトコル
に基づいている。

【０００３】トランザクション処理システムの重要な特
徴は信頼性と最小単位（atomicity)である。信頼性はシ
ステムの状態が障害の後で回復でき、かつすべての中断
トランザクションが再スタートできるか、さもなければ
システム障害が予測できない結果を生成しないように処
理されるかを保証するようなものに関連している。最小
単位は各トランザクションが成功する（その場合にはト
ランザクションの結果は持続的に蓄積される）か、ある
いは打ち切られる（その場合にはトランザクションによ
り影響されたすべてのデータはトランザクションの開始
の前の状態に戻される）かのいずれかの分割できない単
位として取り扱われることを意味している。

【０００４】作業フロー管理は典型的には、分、時間あ
るいは日の期間、従って通常のトランザクション処理シ
ステムにより処理された離散トランザクションのような
ずっと長い期間を有するビジネスアクティビテイのよう
なプロセスを含んでいる。作業フロー管理はまた典型的
な作業フローが多重計算機あるいは他のマシンを含まな
いが、多重の人間主体（human principals）の参加も含
まないという通常のトランザクション処理システムとは
異なっている。

【０００５】この文書は多重ユーザー計算やビジネスプ
ロセスのような長期間アクティビテイに関連している。
そのようなアクティビテイはしばしば作業フローとして
知られている。一例として、作業フローは大多数のソー
スからデータを収集し、次にあるやり方でそのデータを
統合するものである。データ収集プロセスはハードウエ
アおよび／または人間主体の種々の断片との多数の相互
作用を含み、かつ作業フローの期間はすべての所要の参
加計算機とハードウエアの他の断片の可用性に基づいて
拡張できる。長時間運転作業フローの他の例は新聞編集
を構成するプロセスであり、それは多数の個人ならびに
計算機と他のマシンによる協働的努力を要求する。

【０００６】本発明の前提は、任意のアクティビテイ管
理システムの重要な考察がシステム障害の回復であると
いうことである。アクティビテイ管理システムは一度シ
ステムがオンラインに戻されると実効的に任意のシステ
ム障害から自動的に回復できなければならない。このこ
とはその状態がシステム障害の丁度前にどうであったか
を決定し、かつできる限りわずかなバックトラッキング
により、ここでステップと呼ばれた、すべての中断作業
単位の処理を再開するのに十分なデータをシステムが蓄
積すべきであることを意味している。

【０００７】たいていのトランザクション処理システム
において、システム回復はそれらのトランザクションの
開始ですべての中断トランザクションを再スタートする
ことにより実現される。ログ記録はそのような各トラン
ザクションの始めと終りで蓄積され、どのトランザクシ
ョンが完了し、かつシステム障害が生起した場合にどれ
が中間プロセスにあるかをシステム障害回復ルーチンは
決定できる。この解決法は長時間運転作業フローを処理
するアクティビテイ管理システムには適していない。と
いうのは、その回復方法が多数の貴重な作業（ワーク）
の再行を意味するからである。長時間運転作業フローと
短期間トランザクションを区別する付加的な問題は各ト
ランザクションのステータスに関する十分な記録を保持
するという問題である。短期間トランザクションに対し
て、それは一般的に、（Ａ）各トランザクションの開始
をマークし、そのトランザクションの再スタートに十分
なデータを記録し、（Ｂ）必要なら変化が反転できるよ
うに種々のデータ構造に行われた変化を記録し、かつ
（Ｃ）一度トランザクションの結果が固定的に蓄積され
ると、トランザクションの結論をマークするログ記録を
発生し蓄積することで十分である。長時間運転作業フロ
ーに対して、システム障害点まで作業フローにより遂行
されたすべての作業を取り消すようシステムのバックア
ップをすることは典型的にはずっと複雑であろうし、あ
る場合には実効的に不可能であろう。

【０００８】長期間アクティビテイあるいは作業フロー
に関連した他の問題はデータインターロック機構の使用
に関連している。データベースの記録あるいは任意の他
の規定された対象とは一致しない変化をアクセスかつ実
行することを２つの異なる計算から防ぐために、たいて
いの多重タスク計算機システムはトランザクションが対
象のロックを完了するかあるいは明白に解放するまで１
つのプロセスが規定された対象の排他的使用を許容する
インターロック機構を備えている。たいていの場合、プ
ロセスが完了し、その結果が固定的に蓄積されるか、あ
るいはプロセスが打ち切られ、任意の暫定的変化が逆転
されるまでプロセスはこのプロセスにより使用された各
対象にロックを維持する。長期間アクティビテイに関連
する問題は、長期間の各作業単位により使用された対象
のロックがシステムデッドロックとなり得ることであ
り、ここで多数の作業単位は、他の作業単位あるいは作
業フローが、ブロックされた作業単位により必要とされ
た対象にロックするという理由で進行できない。明らか
に、デッドロック問題の範囲は各作業フローにより使用
された対象の平均数およびそれらの作業フローにより使
用された対象についての作業フロー間のオーバーラップ
の平均の量に関連している。それにもかかわらず、長期
間作業フローの期間はリソースと競合する作業フローが
有意な期間だけ遅延されるチャンスを大いに増大する。

【０００９】短期間トランザクションによる問題ではな
い長期間作業フローに関連する付加的な１つの問題はそ
れらの作業フローのトラッキングに関連する。短期間ト
ランザクションに対して、各トランザクションが処理中
か、処理中ではあるが所要のリソースが利用可能でない
ために進行がブロックされているか、打ち切られるか、
あるいは完了するかのいずれかであることを知ることは
一般に十分である。しかし、長期間作業フローに対し
て、ずっと詳細なレベルで各作業フローのステータスを
監視することは重要である。

【００１０】要約すると、短期間トランザクションから
長期間作業フローを区別する問題は、中断作業フロー、
データインターロックにより生起したデッドロックの回
復であり、かつ処理中の作業フローのステータスをトラ
ックするかあるいは監視できる必要性のあることであ
る。

【００１１】

【発明の開示】本発明はその広義の形で請求項１に引用
された作業フロー管理システムと請求項６に引用された
その方法に属している。

【００１２】特にここに記載されているのは、長時間運
転作業フローの進行を実行かつトラックし、かつ長時間
運転作業フローの実行の間にシステム障害からの回復の
作業フロー管理システムと方法とである。特定のシステ
ムで使用される長時間運転作業フローの各タイプはその
間にデータフローを持つ一組のステップとしてフロー記
述データベース（flow description database ）で表さ
れている。各ステップは応用プログラム（application
program ）を実行し、かつその結果の蓄積を持続的に蓄
積する個別計算として取り扱われる。ステップ間のデー
タフローはステップ間のアークとしてフロー記述データ
ベースに表されている。

【００１３】フローコントローラは定義された各タイプ
の作業フローの事例（instance）を実行するプロセスを
制御する。外部的に発生された入力事象信号の対応する
組がフローコントローラにより受信された場合に作業フ
ローの実行が始まる。作業フローの実行の間に、入力信
号の定義された組が受信された場合にのみ作業フローの
各ステップは例示（instantiate ）される。その点で所
要のタイプのステップの事例が創成され、かつ実行さ
れ、１つ以上の出力信号の発生となる。人間主体により
実行されるステップは人間主体に通知を送ること、ステ
ップが遂行されたことを示すために人間主体を待機する
こと、およびフロー制御プロセスの実行を再開すること
により遂行される。ステップの終了の後、ステップから
の出力信号はフロー記述データベースに蓄積された「ア
ーク」データに従って作業フローの他のステップに対す
る入力事象信号に変換される。

【００１４】その上、ログ記録は、作業フローの各ステ
ップの例示と実行と終了に基づいて持続的に蓄積され、
かつ出力事象信号もまたログされ、それによりシステム
障害の前に完成した作業（ワーク）の実効的な損失なし
に作業フローの回復に十分なデータを持続的に蓄積す
る。

【００１５】本発明のさらに詳しい理解は、実例により
かつ添付図面と共に理解される以下の好ましい実施例の
記述により行うことができる。

【００１６】

【実施例】図１を参照すると、本発明の好ましい実施例
は、ローカルもしくは広域回線網112 あるいは他のある
通信媒体により相互接続された一組の計算機102 −110
を有する分散型計算機システム100 のコンテキストで典
型的に動作する作業フロー管理システムとその方法であ
る。これらの各計算機102 −110 は分散型計算機システ
ム100 の個別ノードに位置されている。

【００１７】各計算機102 −110 はデータ処理ユニッ
ト、システムバス、ランダムアクセスメモリRAM 、読み
取り専用メモリ（ROM ）、大容量メモリ（例えば磁気デ
ィスクあるいは光学的ディスク）、ユーザーインタフェ
ース（例えばキーボード、モニター、プリンタ）、およ
び通信ポートを含む標準計算機システム成分を含んでい
る。これらの物理的計算機成分（示されていない）は本
発明により変更されず、従ってここで詳細に記述されな
い。

【００１８】少なくとも１つのネットワーク化された計
算機110 は作業フロー記述データベース114 を維持し、
かつシステム中の同じ計算機あるいは他の計算機は作業
フロー履歴データベース（work flow history databas
e）116 を維持する。以下に詳細に記述されるように、
作業フロー記述データベース114 はシステムに対して定
義された長時間運転作業フローの各タイプを表すデータ
を蓄積する。履歴データベース116 は本質的に、任意の
進行作業フロー（ongoing work flow ）のステータスを
決定し、かつシステム障害から回復する場合に進行作業
フローを再構成するために検査できるログ記録データベ
ースである。

【００１９】フロー管理システム成分 図２を参照すると、本発明の好ましい実施例は作業フロ
ーの実行を制御する一組のソフトウエアモジュールから
なるフロー管理システム120 を使用する。記述マネージ
ャーモジュール122 は作業フロー記述データベース114
の作業フローの各タイプを表すデータを蓄積する。記述
マネージャーモジュール122 と作業フロー記述データベ
ース114 の構造は図３−５を参照して以下に詳細に記述
されよう。

【００２０】好ましい実施例において、フローエディタ
モジュール124 は作業フローを定義するプロセスを促進
する図形インターフェースを備えている。しかし、標準
データベース編集ツールは本発明に従って作業フローを
定義するために使用できる。

【００２１】履歴マネージャーモジュール126 は作業フ
ローの実行の間に発生されたログ記録を蓄積する。ログ
記録は各実行作業フローの各ステップのステータスの決
定が可能であるように定義されかつ蓄積される。事実、
好ましい実施例で使用されたログ記録は作業フローの各
ステップの実行の正確な点の決定を許容し、かつシステ
ム障害と回復の場合に種々の中間ステップ段の各ステッ
プの再スタートを許容するのに十分である。履歴検査子
モジュール128 は作業フローの実行のステータスをチェ
ックするユーザーインターフェースを備えている。ログ
記録もまた完了した作業フローのレビューを許容する。
好ましい実施例で使用されたログ記録のフォーマット
と、各作業フローの現行ステータスの決定を助けるのに
使用されたログ記録間の連結は「ログ記録データベース
とシステム障害回復」と標記されたセクションで図19−
21を参照して以下に議論される。

【００２２】フローコントローラ130 は好ましい実施例
の主要機関（エンジン）である。それはあらかじめ定義
された長期作業フローの新しい事例の創成を含み、作業
フローのステップ間のメッセージの伝送を処理し、各ス
テップの結果を持続的に蓄積し、システムクラッシュ回
復とステータス監視に使用されたログ記録を創成する等
々の各作業フローの実行を制御する。フローコントロー
ラ130 とその内在するデータ構造は以下に徹底的に議論
される。

【００２３】フローデバッガー（flow debugger ）132
とフローシミュレータ134 は定義された作業フローのチ
エックとデバッグを行うと同時にプログラマーを援助す
るために作業フローを定義するプロセスの間に使用され
るソフトウエアモジュールである。

【００２４】作業フローの成分 図３を参照すると、作業フローの各タイプは「フロー」
150 としてモデル化されている。フロー150 はアークと
呼ばれたデータ信号パス154 により相互接続された一組
のステップ152 を具えている。フロー150 はサブフロー
156 を含むことができ、それはフローが組み込み（nes
t）できることを意味している。作業フローの各ステッ
プ152 は入力ポート158 を有し、かつ通常は少なくとも
１つの出力ポートを有している。さらに、フロー150 と
外界との間の入力事象と出力事象を写像するために、フ
ロー150 は特殊入力制御ステップ160 と出力制御ステッ
プ162 を有している。

【００２５】図３に示されたアーク154 の組は非常に簡
単であるが、ある環境のステップ間のデータパス連結は
非常に複雑であり、かつ一組のステップが特殊条件の下
で再度繰り返しできる状態のループもしくはフィードバ
ックパスさえ含むことを理解すべきである（入力条件と
出力条件の以下の議論を見よ）。

【００２６】好ましい実施例を使用して任意の長期アク
ティビテイあるいは作業フローを定義する場合に、どれ
だけ多くの作業が各ステップ152 に含まれるべきかにつ
いてのかなりの量の許容範囲が存在する。これは作業フ
ローを定義する個人の部分の選択プログラミング事項で
ある。一般の判定規準は、各ステップが、（１）有用で
ありかつ全作業フローが中間ストリームを失敗するなら
節約に値する作業単位を遂行すべきであり、かつ（２）
拡張期間に対するシステムリソースと連合しない期間で
十分短くなくてはならないことである。各ステップ152
あるいはサブフロー156 が既に実行を始める場合に、ど
んな入力を必要とするか、そしてどこでそれらの入力が
到来するか、かつどこにその出力を送るべきかの明らか
な判定規準でなければならない。

【００２７】図３に示されるように、作業フローは並列
作業フローパスを含むことができる。ステップが直列的
に実行される必要ない時はいつでも並列パスで作業フロ
ーを定義するのは有益である。というのは、もし十分な
リソース（例えば個人および／またはプロセッサ）が利
用可能であるなら、並列パスは同時に遂行できるからで
ある。このことはリソースを効率的に使用し、かつまた
作業フローの完了に必要な時間の量を低減できる。

【００２８】図４を参照すると、フロー中の各ステップ
152 はその各々がステップの実行に関連されたサブステ
ップを遂行するいくつかの成分を有する好ましい実施例
でモデル化される。入力条件評価モジュール170 はステ
ップ152 の事例が創成され、かつ実行されることを要求
するため何時十分な入力事象が受信されたかを決定す
る。入力データ写像モジュール（input data mapping m
odule ）172 は入力事象から受信されたデータを、規定
された応用ルーチン174 の実行に必要な順序に写像す
る。応用ルーチン174 はステップにより遂行される実際
の計算あるいは通知ルーチンである。ルーチン174 は作
業フローを設定するプログラマーにより定義されるのに
従って複雑あるいは簡単であり得る。出力データ写像モ
ジュール176は応用ルーチン174 からの出力値を規定さ
れた順序に写像し、かつ出力条件評価モジュール178 は
１つ以上の出力ポート180 を通して出力事象メッセージ
を発出する。

【００２９】作業フロー記述データベース 図２と図５を参照すると、特定の分散型計算機システム
で定義された作業フローの各タイプの「モデル」は、こ
こで作業フロー記述データベース114 と呼ばれる一組の
テーブルの形で蓄積される。換言すると、作業フローの
ステップ152 の間のすべての関係、ならびに作業フロー
の定義と実行に必要なすべての他の情報は一組のデータ
ベーステーブルの形に蓄積される。述語「ステップ」と
「作業単位」はここでは相互交換可能として使用されて
いる。

【００３０】概念的に、作業フロー記述データベースに
蓄積されたデータは何かデータベースの配列のようなビ
ジネスプロセス配列の規定に使用できる。ビジネスプロ
セス配列は作業単位、各作業単位を例示するの条件、作
業単位の実行に使用された応用プログラム、作業単位に
より発生された出力信号あるいはメッセージのフォーマ
ット等々を規定する。この配列はまた実行順序が変わる
条件の仕様を含めて、その順序もしくは実行に関して作
業単位間の接続の規定による作業フロー、および作業単
位間のメッセージとデータのフローを表している。本発
明は、顧客の制御の下で応用プログラムにより処理され
る個別作業単位の実行（例えばシステムの計算機による
プロセスの走行）と、システムのフローコントローラー
により処理される作業単位の実行の間に起こる制御との
間の明らかな区別を与える。

【００３１】以下の記述を理解するために、「フロータ
イプ」とそのフロータイプの事例との間を区別すること
が重要である。フロータイプは何回も遂行できる作業フ
ローのタイプを表している。フロータイプが呼び出され
る度毎に、そのフロータイプの事例が分散型計算機シス
テムで発生され、かつそれがトラックされるそのフロー
の事例の振る舞いである。同様に、ステップタイプは特
定のステップのモデルであり、一方、ステップの事例は
フローのそのステップタイプの１つのステップを表して
いる。

【００３２】− フローテーブル 図６を参照すると、フローテーブル200 は定義された各
フロータイプの１つの記録201 を含んでいる。各フロー
テーブル記録は各フロータイプに割り当てられた独自の
値であるフロータイプＩＤ 202、このフロータイプのフ
ローへの入力に関するテキストストリングを指摘する入
力スクリプトポインタ204 、出力スクリプトポインタ20
6 、例外ハンドラースクリプトポインタ208 、フローの
表現を表示する場合に使用された図形情報のファイルを
指摘する図形情報ポインタ210 、およびシステムユーザ
ーとプログラマーに示されたフロー名を含むテキストス
トリングであるフロータイプ名212 を含んでいる。スク
リプトポインタ204 ，206，208 はすべて「スクリプ
ト」テーブル（”script”table ）の記録を指摘し、そ
の各記録は記述テキストを含むテキストストリングを含
んでいる。

【００３３】− タイプ参照テーブル タイプ参照テーブル220 は各フロータイプの各ステップ
とフロー要素の記録221 を含んでいる。各タイプ参照記
録は、もし定義されたフロータイプなら、各フローとス
テップ要素に割り当てられた独自の値であるタイプ参照
ＩＤ 222、このフローのフローテーブル200 の対応記録
のポインタ（しばしば外的キー［foreign key ］と呼ば
れている）であるフロータイプＩＤ 224、特定のステッ
プに対応するステップタイプテーブルの記録を指摘する
フロー／ステップＩＤ 226、プロログ（Prolog）ＩＤ 2
28、エピログ（Epilog）ＩＤ 230、補償ルーチンポイン
タ232 、分画値（demarcation value ）234 、リソース
分解関数ＩＤ 236、タイムアウト期間237 、および応用
フラグ238 を含んでいる。分画値234 はステップがフロ
ーの開始であるか、終了であるかあるいは中間位置にあ
るかを示している。

【００３４】補償ルーチンポインタ232 は（タイムアウ
トのような）例外がステップあるいはフローの実行の間
に生起する場合に呼び出せる「補償ルーチン」を参照す
る。このように、ステップの各タイプは注文された補償
手順を有することができる。典型的には、フロー中の任
意のステップが実行に失敗すると、作業フローの放棄の
判定となり、失敗したステップの補償ルーチンが実行さ
れ、次に前に実行されたフローのすべてのステップの補
償ルーチンが走行するが、しかしそれはステップの逆順
で行われる。フローで既に実行されたステップの連鎖は
システムにより維持されたログ記録から決定され、それ
については後で記述されよう。補償ルーチンはこのよう
に作業フローあるいはフローが打ち切られた後の「クリ
ーンアップ」に使用される。好ましい実施例では、補償
ルーチンの使用は自動的ではないが、人間システムオペ
レータにより（例えばオペレータが試みたが失敗した後
で、作業フローの実行を再スタートする）行われる。

【００３５】リソース分解関数ＩＤ 236は、「リソー
ス」（すなわち、計算機あるいは選択された個人のよう
な代理人）をステップの実行のために選択するリソース
分解関数240 と呼ばれるソフトウエアルーチンを直接的
あるいは間接的に指摘する。リソースはしばしばここで
は「主体」と呼ばれている。ステップが例示される度毎
に、フローコントローラはステップ事例を実行するため
に定義されたリソースのリスト242 から１つのリソース
あるいは主体を選択するため規定されたリソース分解関
数を呼び出す。このように例示された各ステップの実行
に使用すべきリソースは実行の時点で動的に選択され
る。システムは多数のリソース分解関数を含むことがで
き、その各々は特定の事例の実行に使用すべきリソース
を選択する別々の判定規準を使用する。ある場合には、
リソースは長時間運転作業フローの以前のステップを実
行するために前に選択された同じリソースを選択すべき
であろう。リソース選択の他の判定規準はステップによ
り演じられた役割、ジョブが遂行される「顧客」あるい
は「注文主」、この点までの作業フローの履歴等々を含
むことができる。

【００３６】特定の個人にある種の作業フローステップ
をマネジャーが割り当てようと欲する作業フローに対し
て、マネジャーはあらかじめ定義されたファイルにその
ような作業割り当てを記録できる。そのような作業フロ
ーステップを実行する主体の選択に使用されたリソース
分解関数は個人がそのステップに割り当てられたかどう
かを見る（この場合には特定の個人はそのステップに割
り当てられる）あらかじめ定義されたファイルをまず考
慮する。ファイルにどんな割り当ても見いだされないな
ら、ステップの主体は以下に議論するように一組の選択
規準を使用してリソース分解関数により選択される。

【００３７】タイムアウト期間237 の値は関連フローあ
るいはステップの実行に割り付けるべき時間の最大量を
示している。

【００３８】ＡＰフラグ238 はもし記録221 に関連する
ステップが応用プログラムを実行するなら真であり、も
しステップが応用プログラムを実行しない制御ステップ
であるなら偽である。

【００３９】図６，７，８および９は作業フローの規定
された各タイプを表すために作業フロー記述データベー
スで使用された１次テーブルの配列を表していることに
注意すべきである。

【００４０】− アークテーブル アークテーブル250 はフロー内の各データパスに対し情
報を与える記録251 を含んでいる。各記録はフロータイ
プの各アークに対する独自のアークＩＤ 252、アークが
見いだされるフロータイプを示すフロータイプＩＤ 25
4、成分のタイプと、データ信号がアークにより受信さ
れるポートを規定する「フロムタイプ参照ＩＤ（From T
ype Ref ID）」256 と「フロムポートＩＤ（From Port
ID）」258、およびデータ信号が送られる成分のタイプ
とポートを規定する「ツータイプ参照ＩＤ（To Type Re
f ID）」260 と「ツーポートＩＤ（To Port ID）」262
を有している。アーク名264 はアークに与えられたラベ
ルあるいはテキストストリング名であり、典型的には
「フロー Ｘ アーク 21」のような値を有している。

【００４１】− ステップタイプテーブル ステップタイプテーブル270 は定義された各フロータイ
プの各ステップの１つの記録271 を含んでいる。ステッ
プタイプテーブル記録271 は独自のステップタイプＩＤ
272、このステップにより（あるならば）実行された応
用プログラムを識別する応用ＩＤ 274、入力スクリプト
ポインター276 と出力スクリプトポインター278 、ステ
ップに与えられたテキストストリング名であるステップ
名280 、および（あるなら）このステップにより実行さ
れた応用プログラムの名前を識別するテキストストリン
グである応用名282 を割り当てられる。

【００４２】− ポートテーブル 図７を参照すると、ポートテーブル300 は定義された各
フローの各ステップの各入力ポートと各出力ポートを定
義する。１つのポートのポートテーブル記録301 は独自
のポートＩＤ 302、ポートが定義されているフローある
いはステップを識別するフロー／ステップＩＤ 304、事
象タイプテーブル320 （以下に議論する）の記録321 を
参照する事象タイプＩＤ 306、ポートが入力ポートであ
るか出力ポートであるかを定義するポートタイプ308 、
および「出力ポートＡ」あるいは「Ｑ１」のようにポー
トに与えられたテキストストリング名であるポート名31
0を有している。

【００４３】入力条件と入力データ写像 概念的に、「事象」はデータ信号を発生する何物かの生
起である。この文書の目的に対して、事象信号（しばし
ば「事象」と呼ばれる）は事象を表すデータ信号であ
る。

【００４４】入力条件の目的は作業フロー記述データベ
ースで定義されたステップの各タイプの実行を始めるの
に十分な入力事象信号の１つ以上の組を規定することで
ある。特定のフローあるいはステップタイプは多重入力
条件を有し、その各々は入力事象信号の異なる組合せを
規定している。特定のステップタイプの任意の入力条件
に整合する入力事象信号をフローコントローラが受信す
る場合に、ステップの事例が創成され、かつ実行に対し
て予定（スケジュール）される。ステップ事例を創成す
るプロセスは「例示」あるいは「ステップの例示化（in
stantiating astep）」と呼ばれる。

【００４５】ポート、事象タイプ、入力データ写像、入
力条件およびＡＰＩテーブル300 ，320 ，340 ，360 お
よび380 は各ステップタイプの入力条件を定義し、また
各ステップタイプにより実行された応用プログラムによ
り必要とされたパラメータに事象信号に含まれたデータ
を写像する柔軟性のある機構を備えることである。

【００４６】− 事象タイプテーブル 事象の各タイプは事象により運ばれたデータの関連フォ
ーマットあるいはテンプレートを有し、かつ事象タイプ
テーブル320 は事象信号の各タイプのフォーマットを定
義する。各事象タイプ記録321 は事象信号の１データフ
ィールドを定義し、かつ独自の事象フィールドＩＤ 32
2、ならびにフィールドが定義されている事象のタイプ
を識別する事象タイプＩＤ 324を有している。例えば、
２つのデータフィールドを持つ事象信号は事象タイプテ
ーブル320 に２つの記録を有するであろう。記録321 は
このフィールドのデータが整数、浮動小数点数、ストリ
ング等々であるかどうかを示すデータタイプ値326 も有
している。サイズ328 はフィールドにより占有されたメ
モリの総量を示し、フィールド名330 はフィールドの名
前のテキストストリングである。

【００４７】−入力データ写像テーブル 入力データ写像テーブル340 の目的はステップの応用プ
ログラムにより必要とされた各パラメータにどの入力事
象信号が写像されるかを規定することである。テーブル
340 の各記録341 は特定ステップにより受信できる１つ
の入力事象を表し、かつ条件ＩＤ 342（これは以下に議
論する）、事象信号を受信するステップを識別するステ
ップタイプＩＤ 344、事象信号が受信されるポートを識
別するポートＩＤ 346、事象タイプテーブル320 の１つ
の記録を参照することにより事象信号のフォーマットを
定義する事象フィールドＩＤ 348、およびその値が事象
信号により与えられる応用プログラムのパラメータを識
別するパラメータＩＤ 350を含んでいる。

【００４８】− 入力条件テーブル 入力条件テーブル360 はいつ事象信号の正しい組合せが
作業フローのステップの実行を開始するために受信され
るかを規定する。上に説明したように、任意の１つのス
テップに対して、２つ以上の入力条件を有することが可
能である。各入力条件は１つ以上の入力ポートの論理的
連結であり、それは事象信号がその入力条件により規定
されたすべてのポートに事象信号が受信される場合に入
力条件が満足されることを意味している。任意の１つの
入力条件の満足はステップの例示化に対して十分であ
る。

【００４９】入力条件テーブル360 は各ステップの各入
力条件の一組の記録を有している。各記録361 は所属す
るステップのステップＩＤ 362、特定の入力条件を識別
する条件ＩＤ 364、事象信号が受信できるポートを識別
するポートＩＤ 366、フラグ値368 、および位置値（Po
sition Value）370 を含んでいる。入力条件テーブルの
記録は１つのステップＩＤのすべての記録361 が一緒に
クラスター化されるように順序付けられ、ステップの各
入力条件のすべての記録は位置値370 が各入力条件の記
録のクラスター内で値を増大するように一緒にクラスタ
ー化されかつ順序付けられた。フラグ値368 は特定入力
条件の最後の入力事象信号に対応する記録に対してのみ
「イエス」に等しく、さもなければ「ノー」に等しい。
このようにフラグ368 は入力信号の対応する組が例示に
必要かつ十分である場合にのみ「イエス」に等しい。

【００５０】図８を参照すると、入力条件テーブル360
の使用は実例により最も容易に説明される。３つの入力
ポートＰ，Ｑ，Ｒと２つの入力条件Ｃ1 とＣ2 とを有す
るステップStp 71を考察する。入力条件Ｃ1 は「Ｐと
Ｑ」であり、入力条件Ｃ2 は「ＱとＲ」である。このこ
とは、もしも事象信号がポートＰとＱ、あるいはポート
ＱとＲで受信されるなら、ステップStp 71は例示化され
よう。以下に説明されるように、分散型計算機システム
のすべての事象信号はＦＩＥ（フロー入力事象：flow i
nput event）キューと呼ばれるキューに蓄積される。そ
のキューの事象は事象信号が送られステップのステップ
ＩＤにより、次に入力ポートＩＤにより分類される。フ
ラグ368 と位置370 の値は各入力条件を満足するために
受信すべき入力事象信号の数のトラックを保持する単に
便宜的な方法である。

【００５１】− ＡＰＩテーブル ＡＰＩ（応用パラメータ入力：application parameter
input ）テーブル380の目的は応用プログラムに関連す
る各入力および出力パラメータを定義することである。
テーブル380 の各行381 は１つの応用プログラムに対し
１つのパラメータを定義する。各行381 の成分は定義さ
れたパラメータの独自パラメータＩＤ 382とパラメータ
名384 、定義されたパラメータに関連する応用プログラ
ムの応用ＩＤ 386、パラメータタイプ388 （すなわち入
力、出力、あるいは入力／出力）、パラメータが整数、
浮動小数点数かどうかを示すデータタイプ指示子（Data
Type Specifier ）390 等々、および応用プログラムの
コールストリングのパラメータの位置を示す位置値392
である。

【００５２】出力条件評価および出力データ写像 出力データ写像に関する基本概念は以下の通りである。
多数のステップ（すなわち応用プログラム）は同じ組の
事象信号（例えば出力ポートＱ1 とＱ2 の事象信号）を
それらが走行する度毎に出力するが、あるステップでは
同じ制御パラメータに基づく出力事象信号の異なる組を
発生できることが重要である。制御パラメータの個別の
各値は出力条件と呼ばれ、かつ出力事象信号の対応する
規定された組が発生される。

【００５３】好ましい実施例の図10と11を参照すると、
出力条件評価テーブル400 はどんな制御パラメータが出
力事象信号の選択を支配するか各プログラムを規定す
る。テーブル400 は、ステップタイプＩＤ402 を規定す
る各ステップタイプに対する１つの記録401 、および制
御パラメータが応用プログラムか、入力事象フィールド
か、あるいはステップの例示となる入力条件により発生
された出力パラメータであるかどうかを示すタイプ値40
4 を有している。２つの別のパラメータ406 と408 は出
力パラメータＩＤ、入力ポートと入力事象フィールド、
あるいは入力条件をタイプ値404 に依存して示してい
る。

【００５４】次に出力条件評価テーブル400 から得られ
た情報は使用すべき出力条件を選択するために値アウト
条件マップテーブル（Value OutCondition Map Table）
420の探索に使用される。値アウト条件マップテーブル4
20 は各ステップタイプに関連した各出力条件に対し１
つの記録421 を含んでいる。所与のステップタイプに対
して、ステップタイプＩＤ 422とテーブル420 のタイプ
値424 はテーブル400のものと同じである。所与のステ
ップタイプの各記録421 は異なる出力条件ＩＤ426を有
し、それはそのステップの例示入力条件を持つ入力条件
ＩＤフィールド428 を整合するか、あるいは規定された
出力パラメータあるいは入力事象フィールドの値で値フ
ィールドを整合するかのいずれかでそのような１つの記
録421 が選択される。テーブル400 と420 を使用する最
終結果は出力条件ＩＤの選択である。

【００５５】所与のステップタイプの各個別の出力条件
ＩＤに対して、出力条件テーブル440 は出力事象信号を
発生すべき各出力ポートに対し１つの記録441 を含んで
いる。このように、各記録441 は出力条件ＩＤ442 、ス
テップタイプＩＤ 444、および出力ポートＩＤ 446を含
んでいる。例えば、所与のステップに対して、出力ポー
トＱ1 とＱ2 は出力条件ＯＣ１が選択される場合に使用
され、一方、出力ポートＱ2 とＱ3 は出力条件ＯＣ２が
選択される場合に使用される。この例では、このステッ
プタイプに４つの出力条件テーブル記録441 が存在しよ
う。

【００５６】出力データ写像テーブル460 の目的は出力
事象信号の各データフィールドに入力すべき情報のソー
スを規定することである。データフィールドを有しない
事象を有することが可能であると注意すべきである。そ
のような事象信号はそれらが作業フローの特定のステッ
プの完了を示すことで有用である。兎に角、テーブル46
0 は選択された出力条件に関連する各出力事象の各デー
タフィールドに対し１つの記録461 を有している。各記
録461 は条件ＩＤ 462と、ステップタイプを規定するス
テップタイプＩＤ 464と、記録を適用する出力条件を含
んでいる。１つの出力事象フィールドのデータのソース
は入力ポートＩＤ 466と入力フィールドＩＤ 468による
か、あるいは出力パラメータＩＤ（フィールドＩＤ 468
に蓄積されている）によるかのいずれかで規定され、そ
して対応する出力事象フィールドは出力ポートＩＤ 470
と出力フィールドＩＤ 472により規定されている。

【００５７】選択された出力条件ＩＤと出力ポートＩＤ
の組が一度知られるなら、ポートテーブル300 は発生す
る必要のある各出力事象信号の事象タイプＩＤのルック
アップに使用され、次にそれらの事象タイプＩＤは発生
すべき出力事象の各データフィールドのデータタイプと
サイズを事象タイプテーブル320 でルックアップするの
に使用されることに注意されたい。

【００５８】選択的出力条件としてのループ ある種のコンテキストで、一組の１つ以上のステップが
繰り返される必要がある。図12に示された作業フロー47
0 の事例では、ステップ472 の役割はフロー中で以前の
ステップ152-1 から152-5 により遂行された作業をレビ
ューし、かつジョブがステップ474 に既に進行したかど
うか、あるいはその代わりにステップ476 に送り返され
るべきかを決定することである。例えば、図12に示され
たステップ476 と152-1 から152-5 はマシンの特定のタ
イプの修復に関連するタスクであり、かつステップ472
はいくつかの後続するステップ（マシンが修復したこと
を顧客に通知するような）にジョブを伝える前に遂行さ
れる品質レビューを表すであろう。

【００５９】図12に示された選択的ループパスは上記の
出力条件定義を使用して容易に実現される。特に、ステ
ップ472 は出力条件がステップ472 により発生された出
力パラメータに基づいて選択されることによる２つの出
力条件を有するよう定義されよう。このように、図11を
参照すると、ステップ472 に関連した出力条件評価テー
ブル400 の記録401 は評価パラメータのタイプが出力パ
ラメータであり、かつ使用すべき特定の出力パラメータ
をフィールド406 が規定する（例えば「品質」と呼ばれ
た出力パラメータ）ことをフィールド404 で規定しよ
う。値アウト条件マップテーブルはステップ472 に関連
する２つの記録を有し、それは例えば、品質＝１の値が
第１出力条件ＩＤにまず関連することを規定する１つの
記録と、品質の任意の他の値が第２の出力条件ＩＤに関
連することを規定する第２の記録である。出力条件テー
ブル440 はこれら２つの各出力条件ＩＤに使用すべき出
力ポート480 あるいは482 を規定する。最後に、出力デ
ータ写像テーブル460 は発生できる２つのタイプの出力
事象信号の各フィールドの内容を規定する。

【００６０】フローコントローラー 要約すると、上の記述はいかに作業フローが成分に分解
できる（ここではステップとフローと呼ばれる）ことを
示し、かついかに作業フローにより遂行すべきステップ
（作業単位）と、ステップ間のデータフローの完全な記
述が一組のデータベーステーブルに蓄積できるかを示し
ている。

【００６１】作業フロー記述データベース114 に蓄積さ
れたデータが一組の「作業フロータイプ」あるいは「ア
クティビテイタイプ」を表し、その各々は本質的に制限
のない回数だけ使用できるテンプレートであることを理
解すべきである。例えば、作業フローの１つのタイプが
計算機あるいは計算機の組の下でエンジンの自動化集合
であると仮定する。その作業フロータイプに関連するス
テップとフローは作業フロー記述データベース114 に蓄
積されよう。追加エンジンの集合プロセスが開始される
度毎に、この作業フロータイプの新しい事例は制御計算
機に創成されよう。このように、特定の作業フロータイ
プの事例の１ダースあるいは数百あるいは数千さえも同
時に計算機システムで実行されるかあるいは少なくとも
処理中であることは全くあり得ることである。

【００６２】さらに特定すると、新しい作業フローが開
始されるといつでも、作業フローの初期ステップの１つ
の事例が創成されかつ実行される。初期ステップから下
流の各ステップとフローは、十分な組の入力事象信号が
存在する場合にのみ創成されるかあるいは例示される。
フローの各事例は独自のフロー事例ＩＤならびにそのフ
ロータイプＩＤにより識別される。ステップの各事例は
独自のステップ事例ＩＤならびにそのステップタイプＩ
Ｄにより識別される。

【００６３】以下はいかに作業フローの実際の実行が処
理されるかの説明である。図13はフローコントローラー
130 の構成要素を表している。フローコントローラー13
0 は作業フローの各ステップの処理を制御するＴ1 から
Ｔ5 の５つのプロセスを使用している。これらの各プロ
セスは対応する入力キューを有している。図14から図19
はこれらのキューのデータ構造を示している。ＦＩＥキ
ューは入力データ事象を蓄積する。入力データ事象は以
前に実行されたステップにより発生された事象信号と外
部的に発生された事象信号の双方を含んでいる。典型的
に新しい作業フローの開始の要求を表している外部的に
発生された事象信号はポストサーバー500 と呼ばれたプ
ロセスによりＦＩＥキューに挿入される。

【００６４】フローコントローラー130 の重要な態様
は、フローコントローラー130 に関連した同時に走行す
るプロセスの数が、任意の１時点で実行される作業フロ
ーの数にかかわらず、一定に留まることである。以下に
説明されるように、各フローとステップ事例はフローコ
ントローラーにより特定のシステムリソース（典型的に
はシステムのプロセッサの１つ）の実行に割り当てられ
る。フローコントローラーのジョブは作業フローステッ
プとそれらのデータフローの実行に協調すべきである
が、しかし各ステップの実際の実行はどこか別に処理さ
れる。作業のこの分割を使用して、フローコントローラ
ー130 は、非常に広い範囲の作業負荷を処理できること
で「比例可能（scaleable ）」である。大多数の作業フ
ローを処理するようシステムをスケールアップするため
に、システムマネジャーはフローコントローラーが作業
を割り当てできるプロセッサの数を増大することのみを
必要とする。システムの種々のプロセッサによりシステ
ムで同時に実行されるステップあるいは応用プログラム
の数は、現在実行する作業フローの数とそれらの作業フ
ローのサービスに役立つ計算パワーの量の双方に依存す
る。

【００６５】プロセスＴ1 プロセスＴ1 はＦＩＥキュー510 の事象信号が対応フロ
ータイプあるいはステップタイプに規定された入力条件
に十分適合する時にはいつでもフローとステップの新し
い事例を創成する。図７と図８を参照して上に議論され
たように、ＦＩＥキューで待機する事象信号がステップ
タイプの入力条件を満足する時はいつでも、そのステッ
プタイプの事例が創成される。図14を参照すると、ＦＩ
Ｅキュー510 の各入力事象信号511 は、信号のアークが
位置されている閉じ込めフロー事例（enclosing Flow I
nstant）512 、ならびにステップタイプ514 、および入
力事象信号が向けられているステップタイプのポートＩ
Ｄ 516を規定する。

【００６６】各入力事象信号511 の他の情報は対応ログ
記録のポインタであるログ参照518フィールド、閉じ込
めフローのフロータイプ520 とフローリソース522 、お
よび事象信号を発生するステップと事象信号が送られる
ステップとを接続するアークのアークＩＤ 524を含んで
いる。また事象信号には、事象信号を発生するステップ
に関するリソースデータ526 、いつ事象が発生されたか
を示すタイムスタンプ（Timestamp ）530 、システムが
ＦＩＥ記録にＦＯＥ記録を変換しようと試みた回数を示
すリトライパラメータ532 、および事象信号のすべての
データフィールドが蓄積されているメモリの領域を指摘
する作業空間記述子（Workspace Descriptor）534 が存
在する。

【００６７】Ｔ1 プロセスが新しいステップ事例ＩＤを
割り当てかつ新しい記録541 をΦ５キュー540 に蓄積す
ることによりステップの「事例を創成」する。本質的
に、新しいステップ事例はΦ５キュー540 の新しい記録
541 としてのみこの点に存在する。

【００６８】図15に示されたように、Φ５キュー記録54
1 のいくつかのフィールドはＦＩＥキュー記録と同じで
ある。規定されたフロー事例ＩＤ、フロータイプＩＤお
よびフローリソースＩＤは創成されたステップ事例が位
置されるフロー事例に対応することに注意されたい。も
しステップ事例が入力制御ステップであるなら、Ｔ1プ
ロセスはΦ５キュー記録541 の発生の前に、まず新しい
フロー事例ＩＤと対応ログ記録を割り付ける。

【００６９】いくつかの事象信号が新しい１つのステッ
プ事例の創成に使用されるから、Φ５キュー記録541 の
作業空間記述子542 により指摘された事象データフィー
ルドはいくつかの入力事象からのデータを含むことがで
きる。各Φ５キュー記録541の新しい情報はステップ事
例ＩＤ 544、ステップの実行が割り当てられた計算機や
マシンもしくは個人を識別するステップリソースＩＤ 5
48を含んでいる。ステップリソースＩＤ 548は規定され
たステップタイプのタイプ参照テーブル220 （図６を見
よ）によるリソース分解関数参照を使用して選択され
る。

【００７０】プロセスＴ2 プロセスＴ2 は入力データ写像とリソース写像を遂行す
る。入力データ写像とリソース写像のいずれも入力およ
び出力制御ステップにより遂行されない。

【００７１】リソース割り付けは特定のステップあるい
はフローを実行できる計算機、マシンあるいは他の主体
のタイプもしくはクラスを決定するプロセスである。リ
ソース割り付けはタイプ参照テーブルで規定されたよう
なステップあるいはフローのリソース分解関数ＩＤに基
づいている。

【００７２】入力制御ステップと出力制御ステップの双
方に対して、Ｔ2 は制御ステップがＴ3 プロセスにより
既に処理されることを示すSTQ2 570キューに小さい記録
を入れる。Ｔ2 プロセスもまた制御ステップの記録をS
R2作業動作リスト（Work ToDo List ）580 に付加す
る。STQ1キュー560 とSTQ2キュー570 の記録のデータ構
造は図16に示されている。

【００７３】出力制御ステップは出力データ写像を要求
し、かつ制御ステップのS R2リスト580 に付加された記
録は、制御ステップが既に処理しているＴ3 プロセスを
通知する。S R2リスト580 の記録のデータ構造は図17に
示されている。S R2リストの記録のデータ構造は、状態
フィールド584 、時間設定586 、累積時間588 、および
現行位置590 の付加により、Φ５キューの記録のデータ
構造と同じであることに注意されたい。状態フィールド
584 は「スタートの待機」、「実行」あるいは「完了」
のようなステップのステータスを示している。その実行
が完了したことをステップのS R2記録が示す場合、プロ
セスＴ3 はそのステップの処理を引き継ぐ。もしステッ
プの実行がまだ完了せず、かつステップの開始時間にプ
ラスするステップのタイムアウト期間としてＴ2 プロセ
スにより計算されるなら、時間設定586 はステップがタ
イムアウトになる時間に等しい。

【００７４】無制御ステップに対して、Ｔ2 プロセスは
入力写像を遂行し、次いでステップがＴ3 プロセスによ
り実行と処理の用意ができていることを示すSTQ1キュー
560に小さい記録を入れる。Ｔ2 プロセスはまたS R2作
業動作リストに各ステップの記録を付加する。入力デー
タ写像を遂行するプロセスは上に述べられている。入力
データ写像プロセスの結果全体は応用プログラムを呼び
出すのに必要な順序で直列配列されたパラメータのリス
トである。写像された入力データはS R2記録の作業空間
記述子582 により参照されたメモリ領域に蓄積される。

【００７５】Ｔ2 プロセスにより遂行された第２関数は
各ステップとフロー事例のタイムアウト限界を監視して
いる。

【００７６】セッションマネジャー，Ｔ3 プロセスおよ
び応用実行 図13を参照すると、セッションマネジャープロセス600
の役割はSTQ1キュー560 の項目を読み取り、それらをキ
ュー560 から除外し、かつセッションマネジャー600 に
内部的に蓄積されたステータスリスト602 にそれらの項
目を付加することである。STQ1キュー560 の項目は各ス
テップが実行すべきリソース（すなわち、計算機）を示
していることに注意されたい。分散システムの種々の計
算機で走行する顧客プロセス610 はその顧客に属するス
テータスリスト602 ですべての項目のリストを得るよう
にセッションマネジャー600 にログされる。顧客プロセ
ス610 が新しい応用プログラムの実行に用意されている
場合、それは項目をリスト602 に選び取る（もしそのプ
ロセスが待機されているなら）。

【００７７】顧客プロセスはそれから以下のように応用
プログラム620 を実行する。まず、顧客は応用マネジャ
ープロセスＴ3 を呼び出し、それを実行すべきステップ
のステップ事例ＩＤ（STQ1キュー記録から得られた）に
伝え、かつ応用の入力パラメータのリストにそれを送る
ようプロセスＴ3 に要求する。応用マネジャープロセス
Ｔ3 は規定されたステップ事例ＩＤに対応するS R2リス
ト580 の記録を見いだす。するとそれはＴ3 プロセスと
顧客610 との間の「トランザクション」を開始し、かつ
走行すべき応用プログラム（ステップタイプテーブルか
ら得られた）の名前と、応用プログラムの入力パラメー
タ（規定されたステップ事例ＩＤに対応するS R2リスト
の記録から得られた）を顧客に送る。顧客は応用プログ
ラムを実行し、かつ得られた出力パラメータを応用マネ
ジャープロセスＴ3 に送る。プロセスＴ3 は実行される
ステップ事例のS R2記録の作業空間記述子582 により参
照された作業空間の出力パラメータを蓄積し、次にステ
ップの結果を持続的に蓄積する顧客プロセスによりトラ
ンザクションを終了する。

【００７８】この点で、応用マネジャープロセスＴ3 は
応用プログラムの実行が完了したことを示すSTQ1キュー
560 に記録を追加する。セッションマネジャー600 はそ
の内部リスト602 をアップデートするためにこの情報を
使用し、すなわちその内部リスト602 からのステップ事
例に対応する記録を削除する。

【００７９】次に、応用マネジャープロセスＴ3 は出力
写像、ステップの入力および出力パラメータの出力事象
信号のフィールドへの写像を遂行する。出力写像プロセ
スは図10を参照して上に説明された。

【００８０】各フローの終わりの最後のステップである
出力制御ステップもまた出力写像を受ける。各出力制御
ステップはSTQ2キューの記録ならびにS R2リストの項目
により表される。これらの記録は応用マネジャープロセ
スＴ3 により取り上げられ、かつ制御ステップへの入力
信号は入力信号データを位置するために対応S R2記録か
らの作業空間記述子を使用して出力信号に写像される。

【００８１】応用マネジャープロセスＴ3 はステップを
実行するためにΦ７キュー630 に１つの記録を発生す
る。Φ７キュー630 のフォーマットは図18に示されてい
る。各出力事象記録は対応ログ記録632 を識別するフィ
ールド、フロー事例634 −638および出力事象を発生す
るステップ事例640 −644 、ステップ事例を例示する入
力条件650 および出力信号発生を選択する出力条件652
、それにプラスして、 ステップに関連したすべての出
力事象データフィールドが蓄積されるメモリの領域を指
摘する作業空間記述子656 を有している。

【００８２】次に、ステップ終了プロセスＴ4 （図13を
見よ）が各出力事象信号のＦＯＥキュー660 の別々の出
力事象記録を発生する。ステップＴ4 は以下の「ログ記
録データベース」と名付けられたこの文書のセクション
で議論されるようなステップのログ記録も処理する。Ｆ
ＯＥキュー660 のフォーマットは図19に示されている。
各出力事象記録は対応するログ記録662 、フロー事例66
4 −668 、および出力事例を発生する発生ステップ事例
670 −678 、それにプラスして、出力事象信号のデータ
フィールドが蓄積されるメモリ領域を指摘する作業空間
記述子686 を識別するフィールドを有している。

【００８３】最後に、アーク分解プロセスＴ5 はＦＯＥ
キュー660 の各記録を調べ、アークテーブル250 （図６
を見よ）の対応記録をルックアツプし、次にＦＩＥキュ
ー510 の対応ＦＩＥ記録を創成する。ＦＩＥキューの記
録の構造は図14に関して上に議論された。まだ発生され
なかった新しいフローにその出力事象信号が送られる出
力制御ステップに対して、Ｔ1 プロセスはアークテーブ
ル250 で規定されたフロータイプの新しい事例を表す新
しいフロー事例ＩＤを発生する。

【００８４】このように、ステップの実行の処理の全サ
イクルを完了した。典型的なシステムでは、多数の異な
るフローからの多数のステップは同時に処理され、かつ
処理を待機する任意の１時点で各キューの多数の項目が
存在し得る。各ステップはＴ1 からＴ5 ループを通して
そのやり方で実行され、以前のキューのその記録は削除
され、かつ新しい記録はこのループに沿って次のキュー
で記録される。ログ記録はシステム障害により中断され
たステップの回復を許容するようプロセスＴ1からＴ5
の各々により発生される。ログ記録発生と保全について
は以下に議論される。

【００８５】プロセスＴ1 からＴ5 の間の動作の特定の
分割は本発明のただ１つの可能な実施例を表しているこ
とに注意すべきである。例えば、Ｔ3 プロセスとＴ4 プ
ロセスは容易に結合できる。しかし、発明者はステップ
をできる限り迅速に閉塞しかつ引き渡すのが望ましいと
見いした。従って、プロセスＴ3 はステップの実行を完
了し、かつ持続的にその結果を蓄積する可能な限り僅か
な作業を行い、次にプロセスＴ4 は出力事象信号発生の
プロセスを完了する。

【００８６】通知ステップ 図３と図13を参照すると、定義された作業フローのステ
ップ152 は自動化ステップ（計算機あるいは他のマシン
により自動的に遂行された）ならびに個人あるいは他の
独立主体（すなわちフローコントローラの観点から自律
である主体）によりあるいはその制御の下で遂行される
「手動」ステップの双方を含むことができる。この展望
から、本発明の目的は定義されたプロジェクトと一緒に
作業をする多数の主体により遂行されたアクティビティ
と協調すべきである。本発明の特定の応用に依存して、
「主体」は多数の人間代理人（human agent ）を含むこ
とができ、その各々にプロジェクトが次の段階に進める
前に定義された種々のタスクを遂行する必要があり、か
つまた定義されたプロジェクトが一度特定点に達したな
ら定義されたタスクを遂行する多数の計算機とマシンも
含むことができる。

【００８７】人間主体を含む定義されたプロジェクトの
タイプは著しく変化する。実例は自動車エンジンあるい
は時計の製造プロセス、あるいは新聞の編集の準備と組
立のプロセスさえも含んでいる。フロー仕様はタスク
（すなわちステップ）が遂行される必要のある順序を示
し、また各ステップを実行する必要のある主体のタイプ
を規定する。

【００８８】タイプ参照テーブルの各エントリー（図６
を見よ）はステップを実行するために「リソース」（す
なわち、計算機あるいは選ばれた人間のような他の代理
人）を選択するソフトウエアルーチンを直接的あるいは
間接的に指摘するリソース分解関数ＩＤ 236を含むこと
に注意されたい。リソース分解関数がステップを遂行す
るために人間主体を選択する場合、選択規準は典型的に
は選択すべき個人の所要の能力を示すジョブタイトルを
規定し、ならびに人間の実在作業負荷あるいは遂行され
ているジョブに対する個人の関係のような他の規準も規
定しよう。

【００８９】図13を参照すると、人間主体により実行す
べき「手動」ステップに関連する応用プログラムは典型
的には特定の個人、あるいは規定された「役割」（例え
ば特定のジョブタイトルあるいは記述）に適合する任意
の利用可能な個人に通知を送ることをそのただ１つのタ
スクとして有するであろう。典型的には、この通知は
（Ａ）特定のジョブが既に作業していること、および
（Ｂ）プロジェクトがその次の位相に進めるようにプロ
ジェクトの個人の作業が完了する場合に特定の指令が計
算機システムに入らなければならないことを述べるであ
ろう。

【００９０】上にも議論したように、ステップが自動化
計算あるいは手動ステップであるかどうかにかかわら
ず、Ｔ2 プロセスはSTQ1キュー560 を介してセッション
マネジャー600 にメッセージを送る。セッションマネジ
ャー600 はステータスリスト602 にステップを記入す
る。人間主体により遂行すべき手動ステップさえも計算
機により名目的に実行され、選択された計算機プロセッ
サは人間主体に通知する応用プログラムを実行する必要
がある。

【００９１】この通知ステップは実行中の他のステップ
と同じ基本ステップにより進行する。このように、Ｔ3
プロセスを介して入力パラメータを取り上げる。通知ス
テップの入力パラメータは特定ステップを遂行する人間
主体により必要とされた情報を含むであろう。その情報
は実行すべきタスクを単に識別するか、あるいはそれは
１つ以上の関連ファイルのようなものを含むことができ
る。情報はまたステップ間のアークに関連するデータフ
ローの外部の機構を使用して主体に伝えられる。例え
ば、プロジェクトに関係する情報は２次メモリの種々の
ファイルに蓄積される。通知メッセージが人間あるいは
プロジェクトで作業する自動化された主体にさえも送ら
れる場合、通知メッセージは入力パラメータとしてファ
イルのコピーに実際に伝えるよりもむしろファイルの名
前を単に示すであろう。

【００９２】同様に間接的な情報伝達機構は、他のもの
によりアクセス可能なあらかじめ定義された場所（ディ
スクファイルのようなもの）に情報を読み取るか書き込
むかのいずれかのステップを各作業フローに含むことに
より、別々の作業フロー事例間の情報（それは通常お互
いに通信できない）を通信するのに使用できる。

【００９３】人間主体により遂行すべき長時間を要する
ステップに対して、応用プログラム620 は実際には多数
のプログラムからなっている。例えば、１つのプログラ
ムが通知を送り、第２プログラムは（しばしば代理人と
呼ばれた）人間主体への残りのメッセージの周期的フォ
ローアップを送るのに使用でき、そして第３プログラム
はステップが完了したことを示すため人間代理人により
使用できる。この例では、第３プログラムは「応用プロ
グラム」が行われたことをプロセスＴ3 に通知し、かつ
発生された任意の出力へのポインタをＴ3 に伝え、その
後でシステムの履歴データベースのステップの実行結果
を表すデータを持続的に蓄積する。

【００９４】通知ステップの応用プログラムは通知が送
られる主体から「タスクが完了された」という指令の受
信が戻されるまでその実行を完了しない。多くの実例で
は、ファイルあるいは他のデータの組はフローの引き続
くステップに進むシステムに特定のステップを完了する
主体により運ばれるであろう。例えば、もし人間主体の
ジョブが規定された数の新聞「コラムインチ（column i
nches ）」に適合するよう新聞記事を編集したなら、こ
のステップに関連する応用プログラムからの出力は編集
された新聞記事を含むファイルであろう。

【００９５】代案として、人間主体により遂行されたス
テップの結果は引き続くステップにより使用されるディ
スク上のファイルにステップの結果を蓄積することによ
りフローコントローラに関連するデータフローの外部の
機構を使用して運ぶことができる。このシナリオでは、
ファイルは以前に同意したファイル名に割り当てられる
か（その場合にはステップは完了したことの指示の外は
どんな出力も生成しない）、あるいはファイル名は１つ
以上の出力事象信号の出力パラメータとして引き続くス
テップに伝えることができるかのいずれかであり得る。

【００９６】制御ステップ 作業フローのたいていのステップは１入力ポートと１出
力ポートを持つ単一ステップとしてモデル化され、ここ
で入力ポートと出力ポートに関連するメッセージはモデ
ル化されたタスクに関連する情報を運ぶよう構成されて
いる。そのような単一ステップは容易に理解され、かつ
使用される。というのは、それはただ１つの入力条件と
ただ１つの出力条件であるからである。そのようなステ
ップは参照すべきフローコンテキストとは相対的に独立
に設計できる。

【００９７】作業フローはこれら簡単なステップを一緒
に接続し、かつ創造的接続を与えるために制御ステップ
を使用できる。例えば、もし２つのステップＡとＢがＡ
からＢまでとして接続され、そしてＡの出力メッセージ
がＢの入力メッセージに全く整合しないなら、作業フロ
ー記述はメッセージフィールドのデータを写像するため
ステップＡとＢの間の制御ステップＣを含むよう設定で
きる。もし入力および出力メッセージフィールドの写像
がデータフィールドシャフリング以上を含むなら、この
写像を遂行する特殊応用プログラムを書き込み、次にそ
のプログラムを実行するよう定義されたステップＣを有
することが必要であろう。フローコンテキストとは相対
的に独立に設計すべき主要実行ステップが許容されると
いう理由でもし個別制御ステップが有用なら、その主要
関数ならびにステップＣの関数の双方を遂行するようス
テップＡは再書き込みできる。

【００９８】他の例では、もしステップＡの後で、２つ
のステップＢとＣはあるやり方で分割されたＡからのデ
ータで並列に進行でき、次に１入力ポートと２出力ポー
トおよびデータの分割に必要なデータ写像を有する制御
ステップの間にそれを置くことができる。

【００９９】ステップＥが進行できる前にもしも２つの
ステップＢとＣを結合すべきなら、２入力ポートと１出
力ポートを持つ制御ステップはＢとＣの後かつＥの前に
置くことができ、それはステップＢとＣの出力を連結
し、かつステップＥを開始する単一メッセージを生成す
る。

【０１００】同じ主体を使用すると、他のフローにこれ
らのフローを容易に埋め込む単一入力ポートと単一出力
ポートを有するようにフローはまた設計できる。

【０１０１】作業フローのある種の点に到達し、かつ同
意するまで作業フローを停止しようと欲することをもし
もユーザーが明確に通知したいなら、「区切点制御ステ
ップ（breakpoint control step ）」は再び「再スター
トする」許容リソースとして規定されたユーザーにより
フロー中に挿入できる。区切点ステップは通知の目標と
してユーザーにより特定応用ステップとして挿入でき
る。区切点に到達する場合にユーザーは自分の正規に行
うべき処理の区切点を見るであろう。さらに、顧客はユ
ーザーの指令でフローコントローラにステップ終了メッ
セージを送り返すことをユーザーに許容する簡単なプロ
グラムを統合できる。

【０１０２】作業フロー記述に「遅延制御ステップ」を
付加することにより２つのステップ間に遅延が導入でき
る（例えばある作用を取る前に恩恵期間（grace perio
d）を確実に与える）。いつフローコントローラに「ス
テップ終了」メッセージを送り返すかを決定するクロッ
クを監視する特殊な応用プログラムを呼び出すよう、遅
延制御ステップが設定できる。

【０１０３】ログ記録データベースとシステム障害回復 本発明の重要な態様はシステム障害の信頼性ある回復で
ある。長時間運転作業フローに対して、中間結果の回復
はそのごく初期においてそのような作業フローの不必要
な再スタートを回避することで重要である。

【０１０４】図20を参照すると、好ましい実施例で、ロ
グ記録のいくつかのタイプが発生されている。ログ記録
の主要なタイプは図20にリストされている。それから分
かるように、ＦＩＥ，ＦＯＥ，ＩＦＳ（例示フローステ
ップ：instantiate flow step ）およびＴＦＳ（終了フ
ローステップ：terminate flow step ）ログ記録はＦＩ
Ｅ，ＦＯＥ，Φ５キューおよびΦ７キューからの記録の
コピーを含んでいる。ＦＩＥログ記録はＴ5 アーク分解
プロセスとポストサーバーにより発生され、ＦＯＥ記録
はＴ4 終了プロセスにより発生され、ＩＦＳ記録はＴ1
入力データ写像プロセスにより発生され、そしてＴＦＳ
記録はＴ3 応用マネジャープロセスにより発生される。

【０１０５】ＩＦＰ（例示フロープロセス：instantiat
e flow process）およびＴＦＰ（終了フロープロセス：
terminate flow process）ログ記録はＴ1 およびＴ4 プ
ロセスによりそれぞれ発生される。ＷＳＰログ記録は種
々のキュー記録の作業空間記述子により参照されたデー
タ値を含んでいる。ＷＳＰログ記述は各データのデータ
タイプと関連事象フィールドがＷＳＰログ記録により規
定されるように自己記録フォーマット（self-documenti
ng format ）にこのデータを蓄積する。さらに、ＦＩ
Ｅ、ＦＯＥおよび他のログ記録参照は、それらの記録の
終りで作業空間記述子フィールドによるＷＳＰログ記録
の１つに対応し、それによりシステム障害からの回復に
必要な事象フィールドデータ値にアクセスする。

【０１０６】STQ1キュー、STQ2キューおよびS R2作業動
作リストに対応するどんなログ記録も存在しない。しか
し、STQ1キュー、STQ2キューおよびS R2作業動作リスト
の各々は、これらのエントリーデータ構造がシステム障
害の事象で再構成されるように独立に持続的に蓄積され
る。

【０１０７】ここでログ記録データベースとも呼ばれる
履歴データベース116 の構造は２つのテーブル700 と72
0 を含んでいる。第１のテーブル700 はログ記録を含
み、その各々はログ記録のタイプを示す「記録タイプ」
フィールド702 、規定されたログ記録の迅速なアクセス
を備える独自キー値704 （キー値はその特定の記録タイ
プに対して独自あることのみが必要である）、ログ記録
がシステム回復に必要であるかどうかを示す忘却フラグ
（Forgotten Flag）706 、ログ記録の全サイズを示すバ
ッファサイズ値708 、およびログ記録のすべてのデータ
フィールドが蓄積されているデータバッファ710 を含ん
でいる。

【０１０８】第２のテーブル720 は各ログ記録の「先行
者（predecessor ）」の発見に使用され、それはフロー
の処理の事象の連鎖の再現を可能とする。このテーブル
720の各記録は第１のテーブル700 にあるのと同じ記録
タイプとキー値、それにプラスして、ログ記録の先行者
の記録タイプとキー値を含んでいる。

【０１０９】図21と図22を参照すると、先行者ログ記録
の概念は実例により説明される。図21において、４つの
ステップＳ1 ，Ｓ2 ，Ｓ3 ，Ｓ4 を持つフローが示され
ている。４つのステップは入力ポートと出力ポートを有
し、ここではＰ1 からＰ9 とラベルされている。フロー
は外部的に導かれた２つの入力事象信号の受信により開
始される。

【０１１０】フロー750 の実行の間に発生されたログ記
録の組を理解するために、図13, 21, 22を参照して、図
13の処理ループを眺めるのは有用である。図22の時間ラ
インは左から右に進み、かつ図22の頂上の行は各ログ記
録を発生するプロセスを示している。各ボツクスの各説
明文は発生されたログ記録の記録タイプならびにログ記
録に関連したステップあるいは入力／出力ポートを示し
ている。時間の逆向きを示す矢印はどのログ記録が他の
各ログ記録の先行者であるかを示している。

【０１１１】図22の左側より開始して、最初の２つのＦ
ＩＥログ記録は外部的に導かれた入力信号を反映してい
る。次に、Ｔ1 プロセスはフローを例示し、ＩＦＰログ
記録とフローのステップＳ1 の創成がまた例示され、Ｉ
ＦＳ記録の創成が例示される。ステップＳ1 の実行の後
で、Ｔ3 プロセスはＴＦＳログ記録を発生し、そしてＴ
4 プロセスはポートＰ1 とＰ2 に発生された出力事象信
号に対応する２つのＦＯＥログ記録を発生する。各ログ
記録が作業フローのその先行者を指摘するやり方に沿っ
てログ記録を発生するプロセスＴ1 ，Ｔ3 ，Ｔ4 ，Ｔ5
により、フローのステップＳ4 が完了するまで事象のこ
の連鎖は継続する。

【０１１２】すべての進行作業フローのすべてのログ記
録は典型的にはディスク蓄積デバイスに通常簡単な時間
直列順序で持続的に蓄積される。フローが完了するとい
つでも、Ｔ4 プロセスは終了フロー（ＴＦＰ）ログ記録
ならびに各出力事象のＦＯＥログ記録を発生する。次に
Ｔ4 プロセスは図20に示されたログ記録の忘却フラグフ
ィールドを使用して「忘却」されたものとしてシステム
回復に不必要なフローのすべてのログ記録をマークす
る。特に、ＩＦＰ、ＴＦＰログ記録、およびフローによ
り出力された出力事象のＦＯＥログ記録のみがシステム
回復の目的に保持する必要がある。完了したフローのす
べてのログ記録を通すトレースは第２履歴データベース
テーブル720 により備えられた先行者ポインタを使用し
て遂行される。

【０１１３】システム障害の事象において、履歴データ
ベースのログ記録はＦＩＥ、ＦＯＥ、Φ５キューおよび
Φ７キューに属するすべての項目を再生するように検査
される。これは各長時間運転作業フローのログ記録のレ
ビュー、システム障害により各フローとステップが中断
された点の発見、ログ記録のデータからの対応キュー記
録の再生、およびＴ1 プロセスからＴ5 プロセスの再ス
タートにより行われる。

【０１１４】図２に関して上に述べられたような履歴検
査子モジュール128 は作業フローを実行するステータス
チェックのユーザーインタフェースを備えている。履歴
検査子モジュール128 は規定された作業フロー事例のロ
グ記録を検索し、かつ各作業フロー事例のステータスを
要約するステータス情報を発生する。例えば、発生され
たステータス情報は典型的には作業フロー事例の開始以
来経過した時間の総計、保留している作業フローステッ
プのリスト、および失敗し、タイムアウトした任意の作
業フローのリストを含み、あるいは作業フロー事例の前
進をブロックする問題で遭遇するものを有している。

【０１１５】履歴検査子モジュールの使用を許容するマ
ネジャーはすべての保留作業フローのステータスをレビ
ューできないのみならず、各主体（すなわち個人、計算
機あるいはマシン）に割り当てられたすべての保留作業
フローステップもレビューできず、かつ１つの主体から
他の主体に保留作業フローステップを割り当てることに
より作業フローの完了を促進できない。例えば、もし作
業フローステップが病気の第１の個人に割り当てられる
か、あるいは作業とともにバックログされるか、さもな
ければ保留作業フローステップに留まることができない
なら、マネジャーは他の主体のワークロードをレビュー
でき、次に履歴データベースから得られた情報に基づく
他の主体の１つに第１の個人からのいくつかのステップ
を再度割り当てる。このような態様で作業フローステッ
プが新しい主体に「手動で」再割り当てされる度毎に、
対応ログ記録は作業フローの状態が正確に監視され続け
るように履歴データベース116 に蓄積される。

【０１１６】本発明は特定の僅かな実施例を参照して記
述されているが、この記述は本発明の例示的なもので、
かつ本発明を制限するものと解釈すべきでない。本発明
の真の精神と範囲を逸脱することなく当業者にとって種
々の修正が可能であろう。

【図面の簡単な説明】

【図１】図１は作業フローの遂行に使用された分散型計
算機システムのブロック線図である。

【図２】図２は作業フロー処理システムの１次ソフトウ
エア成分のブロック線図である。

【図３】図３は作業フローを図式的に描いている。

【図４】図４は単一ステップの成分のブロック線図であ
る。

【図５】図５は作業フロー記述データベースに使用され
た１次テーブルのブロック線図である。

【図６】図６は作業フロー記述データベーステーブルの
記録のデータ構造の１つを描いている。

【図７】図７は作業フロー記述データベーステーブルの
記録のデータ構造の別の１つを描いている。

【図８】図８は特定ステップを例示化する代案の入力条
件を表す一組の入力条件テーブルエントリのブロック線
図である。

【図９】図９は好ましい実施例の作業フロー記述データ
ベースの応用パラメータ識別テーブルのデータ構造を描
いている。

【図１０】図１０は一組の出力事象信号に応用プログラ
ムにより発生された出力パラメータを写像するプロセス
のフロー線図である。

【図１１】図１１は出力パラメータの写像に使用された
好ましい実施例の作業フロー記述データベースのテーブ
ルのデータ構造を描いている。

【図１２】図１２は一組のステップが繰り返されるフロ
ーを図式的に表している。

【図１３】図１３は作業フローのステップの例示と実行
を制御する好ましい実施例で使用されたプロセスとデー
タ構造を表すフロー管理システムのブロック線図であ
る。

【図１４】図１４は入力ならびに出力事象信号を表し、
かつ実行されているプロセスのステップを表す図１３の
フロー管理システムにより使用されたキューのデータ構
造を表している。

【図１５】図１５は入力ならびに出力事象信号を表し、
かつ実行されているプロセスのステップを表す図１３の
フロー管理システムにより使用されたキューのデータ構
造を表している。

【図１６】図１６は入力ならびに出力事象信号を表し、
かつ実行されているプロセスのステップを表す図１３の
フロー管理システムにより使用されたキューのデータ構
造を表している。

【図１７】図１７は入力ならびに出力事象信号を表し、
かつ実行されているプロセスのステップを表す図１３の
フロー管理システムにより使用されたキューのデータ構
造を表している。

【図１８】図１８は入力ならびに出力事象信号を表し、
かつ実行されているプロセスのステップを表す図１３の
フロー管理システムにより使用されたキューのデータ構
造を表している。

【図１９】図１９は入力ならびに出力事象信号を表し、
かつ実行されているプロセスのステップを表す図１３の
フロー管理システムにより使用されたキューのデータ構
造を表している。

【図２０】図２０は好ましい実施例に使用された履歴デ
ータベースの構造を描いている。

【図２１】図２１は好ましい実施例の作業フローを表し
ている。

【図２２】図２２は好ましい実施例の履歴データベース
に蓄積されたログ記録の図２１に対応する組を表してい
る。

【符号の説明】

100 分散型計算機システム 102 計算機 104 計算機 106 計算機 108 計算機 110 計算機 112 ローカルもしくは広域通信網 114 作業フロー記述データベース 116 作業フロー履歴データベース 118 表示装置 120 フロー管理システム 122 記述マネジャーモジュール 124 フローエディター 126 履歴マネジャー 128 履歴検査子モジュール 130 フローコントローラ 132 フローデバッガー 134 フローシミュレータ 150 フロー 152 ステップ 154 データ信号パスあるいはアーク 156 サプフロー 158 入力ポート 160 入力制御ステップ 162 出力制御ステップ 170 入力条件評価モジュール 172 入力データ写像モジュール 174 応用ルーチンあるいは応用プログラム 176 出力データ写像モジュール 178 出力条件評価モジュール 180 出力ポート 200 フローテーブル 201 記録 202 フロータイプＩＤ 204 入力スクリプトポインタ 206 出力スクリプトポインタ 208 例外ハンドラスクリプトポインタ 210 図形情報ポインタ 212 フロータイプ名 221 記録 220 タイプ参照テーブル 222 タイプ参照ＩＤ 224 フロータイプＩＤ 226 フロー／ステップＩＤ 228 プロログＩＤ 230 エピログＩＤ 232 補償ルーチンポインタ 234 分画値 236 リソース分解関数ＩＤ 237 タイムアウト期間 238 応用フラグあるいはＡＰフラグ 240 リソース分解関数 242 リソースのリスト 250 アークテーブル 251 記録 252 アークＩＤ 254 フロータイプＩＤ 256 フロムタイプ参照ＩＤ 258 フロムポートＩＤ 260 ツータイプ参照ＩＤ 262 ツーポートＩＤ 264 アーク名 270 ステップタイプテーブル 271 記録 272 ステップタイプＩＤ 274 応用ＩＤ 276 入力スクリプトポインタ 278 出力スクリプトポインタ 280 ステップ名 282 応用名 300 ポートテーブルあるいはＡＰＩテーブル 301 ポートテーブル記録 302 ポートＩＤ 304 フロー／ステップＩＤ 306 事象タイプＩＤ 308 ポートタイプ 310 ポート名 320 事象タイプテーブルあるいはＡＰＩテーブル 321 記録 322 事象フィールドＩＤ 324 事象タイプＩＤ 326 データタイプ値 328 サイズ 330 フィールド名 340 ＡＰＩテーブルあるいは入力データ写像テーブル 341 記録 342 条件ＩＤ 344 ステップタイプＩＤ 346 ポートＩＤ 348 事象フィールドＩＤ 350 パラメータＩＤ 360 ＡＰＩテーブルあるいは入力条件テーブル 361 記録 362 ステップＩＤ 364 条件ＩＤ 366 ポートＩＤ 368 フラグ値 370 位置値 380 ＡＰＩテーブルあるいは応用インタフェーステー
ブル 381 行 382 パラメータＩＤ 384 パラメータ名 386 応用ＩＤ 388 パラメータタイプ 390 データタイプ指示子 392 位置値 400 出力条件評価テーブル 401 記録 402 ステップタイプＩＤ 404 評価パラメータのタイプ値あるいはフィールド 406 パラメータあるいはフィールドあるいは入力条件
ＩＤ 408 入力事象フィールドＩＤ 420 値アウト条件マップテーブル 421 記録 422 ステップタイプＩＤ 424 タイプ値 426 出力条件ＩＤ 428 入力条件ＩＤ／ヌル 430 値 440 出力条件テーブル 441 記録 442 出力条件ＩＤ 444 ステップタイプＩＤ 446 出力ポートＩＤ 460 出力データ写像テーブル 461 記録 462 条件ＩＤ 464 ステップタイプＩＤ 466 入力ポートＩＤあるいはヌル 468 入力フィールドＩＤあるいは出力パラメータＩＤ 470 作業フローあるいは出力ポートＩＤ 472 ステップあるいは出力フィールドＩＤ 474 ステップ 476 ステップ 480 出力ポート 482 出力ポート 500 ポストサーバー 510 ＦＩＥキュー 511 入力事象信号 512 閉じ込めフロー事例ＩＤ 514 ステップタイプＩＤ 516 入力ポートＩＤ 518 ログ参照 520 閉じ込めフローフロータイプＩＤ 522 フローリソース 524 アークＩＤ 526 リソースデータ 530 タイムスタンプ 532 リトライパラメータ 534 作業空間記述子 540 Φ５キュー 541 Φ５キュー記録 542 作業空間記述子 544 ステップ事例ＩＤ 548 ステップリソースＩＤ 560 STQ1キュー 561 記録 570 STQ2キュー 580 S R2作業動作リスト 581 記録 582 作業空間記述子 584 状態フィールド 586 時間設定 588 累積時間 590 現行位置 600 セッションマネジャー 602 ステータスリストあるいは内部リスト 610 顧客プロセス 620 応用プログラム 630 Φ７キュー 631 記録 632 ログ参照 634 フロー事例ＩＤ 636 フロー事例あるいはフロータイプＩＤ 638 フロー事例あるいはフローリソースＩＤ 640 ステップ事例ＩＤ 642 ステップ事例あるいはステップタイプＩＤ 644 ステップ事例あるいはステップリソースＩＤ／ヌ
ル 650 入力条件ＩＤ 652 出力条件ＩＤ 656 作業空間記述子 660 ＦＯＥキュー 661 記録 662 ログ参照 664 フロー事例ＩＤ 666 フロー事例あるいはフロータイプＩＤ 668 フロー事例あるいはフローリソースＩＤ 670 ステップ事例 674 ステップ事例 676 ステップ事例 678 ステップ事例 686 作業空間記述子 700 第１テーブル 702 「記録タイプ」フィールド 704 キー値 706 忘却フラグ 708 バッファサイズ値 710 データバッファ 720 第２履歴データベーステーブル 750 フロー

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アーデル ゴネイミイ アメリカ合衆国 カリフォルニア州 95127 サン ノゼ ファーリンドン ド ライブ 1228 (72)発明者 カール クレイスナー アメリカ合衆国 カリフォルニア州 95032 ロス ガトーズ プレサー オー ク ロード 316897

Claims (9)

【特許請求の範囲】
1. 【請求項１】 作業フロー管理システムにおいて、 データを蓄積するメモリ手段と多数のリソースと通信す
   る通信手段を有する計算機システムであって、上記の多
   数のリソースが多数の人間主体を含むもの、 複数の作業フロータイプを表す作業フロー記述データを
   上記のメモリ手段に蓄積する作業フロー記述手段であっ
   て、上記の各作業フロータイプがその間の情報フローを
   持つ一組のステップとして上記の作業フロー記述データ
   により表され、上記の作業フロー記述データが上記の各
   ステップに出入りする情報フローを表すもの、 ここで各作業フローの少なくとも複数の上記のステップ
   は上記の作業フローの一部分として遂行すべき規定され
   た仕事の上記の１つの主体の通知、上記の１つの主体に
   よる上記の仕事の実行、および上記の規定された仕事が
   完了した場合に上記の主体による上記の作業フロー管理
   システムによる通知を具え、ここで上記の通知は上記の
   通信手段を介して実行され、 上記の作業フロー記述データにアクセスし、上記の複数
   の作業フロータイプの種々のものの事例を具える作業フ
   ロー事例を創成し、かつ上記の作業フロー事例の実行を
   制御するメモリ手段に連結された作業フローコントロー
   ラ、 創成された各作業フロー事例の第１ステップの実行を開
   始し、かつ上記の各ステップのあらかじめ定義された入
   力データ判定規準が上記のステップとは別のものからの
   情報フローにより満たされる場合に、創成された各作業
   フロー事例で互いにステップの実行を開始する手段を含
   む上記の作業フローコントローラ、 実行された各ステ
   ップからの結果を持続的に蓄積する手段を含む上記の作
   業フローコントローラ、および実行の間に上記の創成さ
   れた作業フロー事例に関するステータスデータを蓄積か
   つ検索する手段を含む履歴管理手段であって、ここで上
   記のステータスデータが上記の創成された作業フロー事
   例の上記の各ステップのステータス情報を含むもの、 それにより作業フローがステップのユニットで実行さ
   れ、かつ各作業フローのステータスが上記の各作業フロ
   ーに関連するステップの実行に関するステータスデータ
   の蓄積によりトラックされること、を具える作業フロー
   管理システム。
2. 【請求項２】 上記の作業フロー記述手段が、各作業フ
   ローの各ステップにより発生された出力事象信号を定義
   する出力事象テーブル手段、各作業フローの各ステップ
   の入力ポートを定義するポートテーブル手段、および定
   義された各出力事象テーブルに対して宛て先ステップ
   と、上記の出力事象信号が送るべき上記の宛て先ステッ
   プの入力ポートを示すデータを蓄積するアークテーブル
   手段を含み、 上記の作業フローコントローラが、（Ａ）上記の多数の
   作業フローの上記の創成された事例の実行ステップによ
   り発生された出力パーメータを受信し、かつ上記の出力
   事象テーブル手段に従って一組の対応出力事象信号を発
   生するステップ終了手段と、（Ｂ）上記のアークテーブ
   ル手段に従って上記の多数の作業フローの上記の創成さ
   れた事例の対応ステップの入力ポートに上記の出力事象
   信号を経路指定する分解手段を含む、請求項１に記載の
   作業フロー管理システム。
3. 【請求項３】 上記のフローコントローラが、（Ａ）上
   記の多数の作業フローの１つの創成された各事例、
   （Ｂ）上記の多数の作業フローの１つの創成された各事
   例の実行の終了、（Ｃ）上記の多数の作業フローの１つ
   のステップの創成された各事例、および（Ｄ）上記の多
   数の作業フローの１つのステップの創成された各事例の
   終了に対応するログ記録を持続的に発生する手段を含
   み、かつ上記の作業フロー管理システムが、上記の持続
   的ログ記録をレビューすることでシステム障害によって
   中断された作業フローを再スタートし、かつ既に終了さ
   れたステップの再実行を回避するように上記の中断作業
   フローの実行を再スタートする再スタート手段を含む、
   請求項１に記載の作業フロー管理システム。
4. 【請求項４】 上記のフロー記述手段が、（Ａ）複数の
   出力条件、（Ｂ）上記のステップの実行の後で上記の出
   力条件の１つを選択する判定規準、（Ｃ）各事象信号に
   含まれるべきパラメータの仕様を含めて、上記のステッ
   プの実行の後で発生すべき定義された各出力条件と関連
   する事象信号、および（Ｄ）上記の出力事象信号が送ら
   れるべき宛て先ステップを定義された各出力事象信号に
   示すデータとを、上記のステップの任意の規定されたも
   のに定義する出力事象定義手段を含み、 上記の作業フローコントローラが、（Ａ）上記の各ステ
   ップの実行の後で上記の出力条件の１つを選択する上記
   の判定規準を評価し、（Ｂ）上記の各ステップの実行の
   後で選択された出力条件に従って事象信号を発生し、か
   つ（Ｃ）上記のフロー記述手段により定義された対応宛
   て先ステップに上記の発生出力事象信号を送る手段を含
   み、 それにより、上記のステップの規定されたものが、上記
   のステップの上記の規定されたものの実行の後で評価さ
   れる定義された判定規準に従って異なる宛て先ステップ
   に異なる出力事象信号を送ることができる、請求項１に
   記載の作業フロー管理システム。
5. 【請求項５】 上記の作業フロー記述手段が、複数のリ
   ソース分解関数を含み、各リソース分解関数は上記の規
   定されたステップが例示される場合に、規定されたステ
   ップを実行するためにリソースを選択する判定規準を定
   義し、 上記のフロー記述手段が、上記のリソース分解関数の１
   つを上記の定義されたステップの各々に関連させる手段
   を含み、 上記の作業フローコントローラが、ステップが例示され
   る度毎に、上記の例示されたステップに関連するリソー
   ス分解関数を実行し、それにより上記の例示されたステ
   ップを実行するリソースを選択する手段を含み、ここで
   上記の作業フローコントローラは、作業フローの上記の
   創成された事例の上記のステップを例示し、例示された
   各ステップを実行するためにリソースを選択し、実行さ
   れたステップにより発生された出力事象信号を受信し、
   かつ作業フローの上記の創成された事例とは別のステッ
   プに上記の出力事象信号を送る複数の同時実行プロセス
   を含み、ここで上記の作業フローコントローラの上記の
   複数の同時実行プロセスの数がシステムに現存する例示
   されたステップの数にかかわらず一定に留まる、請求項
   １に記載の作業フロー管理システム。
6. 【請求項６】 多数の相互接続された計算機を有する分
   散型計算機システムにおける作業フローを遂行する方法
   において、 この方法のステップが、 上記の各ステップの出入りの情報フローを表す手段を含
   めて、その間の情報フローにより一組のステップとして
   多数の各作業フローを表すフロー記述データを計算機メ
   モリに蓄積し、 対応入力事象が受信される場合に上記の多数の作業フロ
   ーの１つの事例を創成し、かつ作業フローの上記の創成
   された事例の実行を制御し、かつフロー記述データによ
   り表された作業フローの創成された各事例のステップの
   組の実行を開始し、 実行された各ステップからの結果を持続的に蓄積し、か
   つその実行の間に上記の作業フローの上記の１つの上記
   の創成された事例に関するステータスデータを蓄積し、
   ここで上記のステータスデータは上記の作業フローの上
   記の１つの上記の創成された事例の上記の各ステップの
   ステータス情報を含み、かつ上記の作業フローのステー
   タスをレビューする場合、およびシステム障害により上
   記の１つの作業フローの中断から回復する場合に、上記
   のステータスデータを検索すること、を具える方法。
7. 【請求項７】 上記のフロー記述データが、各作業フロ
   ーの各ステップにより発生された出力事象信号を定義す
   る出力事象データ、各作業フローの各ステップの入力ポ
   ートを定義するポートデータ、および宛て先ステップ
   と、上記の出力事象信号が送られるべき上記の宛て先ス
   テップの入力ポートとを、定義された各出力事象信号に
   示すアークデータを含み、 上記の方法が、（Ａ）上記の多数の作業フローの上記の
   創成された事例の実行ステップにより発生された出力パ
   ラメータの受信と、上記の出力事象データに従う一組の
   対応出力事象信号の発生、および（Ｂ）上記のアークデ
   ータに従って上記の多数の作業フローの上記の創成され
   た事例の対応ステップの入力ポートに上記の出力事象信
   号を経路指定することを含む、請求項６に記載の作業フ
   ローを遂行する方法。
8. 【請求項８】 （Ａ）上記の多数の作業フローの１つの
   創成された各事例、（Ｂ）上記の多数の作業フローの１
   つの創成された各事例の実行の終了、（Ｃ）上記の多数
   の作業フローの１つのステップの創成された各事例、お
   よび（Ｄ）上記の多数の作業フローの１つのステップの
   創成された各事例の終了に対応するログ記録の持続的な
   発生、および上記の持続的なログ記録のレビューによる
   システム障害によって中断された上記の１つの作業フロ
   ーの再スタート、および既に終了されたステップの再実
   行を回避するように上記の中断作業フローの実行の再ス
   タートであつて、上記のフロー記述データが、（Ａ）複
   数の出力条件、（Ｂ）上記のステップの実行の後で上記
   の出力条件の１つを選択する判定規準、（Ｃ）各事象信
   号に含まれるべきパラメータの仕様を含めて、上記のス
   テップの実行の後で発生すべき定義された各出力条件に
   関連した事象信号、および（Ｄ）上記の出力事象信号が
   送られるべき宛て先ステップを定義された各出力事象信
   号に示すデータとを、上記のステップの規定された任意
   の１つに定義する出力事象データを含み、 上記の方法が、（Ａ）上記の各ステップの実行の後で上
   記の出力条件の１つを選択する上記の判定規準の評価、
   （Ｂ）上記のステップの実行の後で選択された出力条件
   に従う事象信号の発生、および（Ｃ）上記のフロー記述
   データにより定義された対応宛て先ステップへの上記の
   発生出力事象信号の送出を含み、 それにより、上記の
   ステップの規定されたものが上記のステップの上記の規
   定されたものの実行の後で評価される定義された判定規
   準に従って異なる宛て先ステップに異なる出力事象信号
   を送ることができること、を含む請求項７に記載の作業
   フローを遂行する方法。
9. 【請求項９】 上記のフロー記述データが、上記の定義
   されたステップが例示された場合に上記の定義されたス
   テップにリソースを選択するリソース分解関数を上記の
   定義されたステップの各々に関連させるデータを含み、 ステップが例示される度毎に、上記の方法が、上記の例
   示されたステップに関連したリソース分解関数を実行
   し、それにより上記の例示されたステップを実行するリ
   ソースを選択することを含み、 上記の方法が、作業フローの上記の創成された事例の上
   記のステップを例示し、例示された各ステップを実行す
   るリソースを選択し、実行されたステップにより発生さ
   れた出力事象信号を受信し、かつ作業フローの上記の創
   成された事例の他のステップに上記の出力事象信号を送
   る同時実行プロセスを含み、ここで上記の複数の同時実
   行プロセスの数がシステムの例示されたステップの数に
   かかわらず、一定に留まる、請求項６に記載の作業フロ
   ーを遂行する方法。