JP2000511674A - 企業間プロセスを作成し、実行し、保守するためのシステム及び方法 - Google Patents

Abstract

(57)【要約】 分散配置された組織間において、共有され、自動化されたビジネスプロセスを作成し、実行し、及び維持するためのシステム及び方法であって、このシステム及び方法は、統一されていない情報システム間における相互運用を可能にする能力を備えている。このシステムは、サイトと呼ばれる複数の独立した通信サブシステムを備えており、これらのサイトは、共有化された共用プロセス定義と、専用プロセス定義を表現し、及び実行する共通の手段を備えたサーバを有する。プロセスの実行は、調和されたサイト間メッセージ交換を含み、このメッセージ交換は、各サイトに限定された制御されたアクションのシーケンスに結合される。共用プロセス定義またはモジュールは、独立したサイト間の相互作用（対話）を捕捉する。相互作用には、１つのサイトが、別のサイトに既知のタイプのメッセージを送信する通信イベントが含まれる。各定義は、参加しているサイト間における１組の有効な通信イベントのシーケンスを指定する。任意の共用プロセス定義に関連して、１組のより低レベルのプロセス定義、または専用のプロセス定義、またはモジュールが存在する。専用プロセス定義は、その特定の共用プロセスノードが実行されるときに、サイトで実行することができる１組の可能性のあるローカルアクションを指定する。好ましい実施態様では、専用プロセス定義は、動作パラメータやソフトウエアアプリケーションの相互作用のような構成に関して定義される。

Description

【発明の詳細な説明】 発明の名称 企業間プロセスを作成し、実行し、保守するためのシステム及び方法 発明の背景 １．発明の分野 本発明は、一般的に情報システムに関連し、特に、分散情報システム間の作業 の連係（調和した動作）を可能にするシステム及び方法に関連する。 ２．関連技術の説明 独立した単一の企業（事業）体から複数の相互依存型の企業体への、最近の企 業組織の構造の変化は、単一のメインフレームから、パーソナルコンピュータ及 びワークステーションからなる分散型ネットワークへのコンピュータシステムに おける類似の発展を反映している。コンピュータネットワークは、分散したサイ ト間で情報をやり取りしたり、作業を実行するのに極めて効率が良いので、現代 のネットワークは、まぎれもなくこの技術革新の有益な産物である。例えば、買 い物を注文したり、それを確認するというような日常的な作業を、共有コンピュ ータネットワークによって、既存のシステム間で自動的に実行することができる 。しかしながら、この技術には多くの欠点が存在するために、企業内用途用の従 来のネットワーク技術の十分な開発が妨げられてきた。 ビジネスパートナーとの間で共有ネットワークを使用することによって現れる 最も切迫した問題は、（１）相手（パートナー）のコンピュータシステムが統一 されていないこと、（２）相手のシステムが使用するデータが統一されていない こと、（３）システム間の通信セキュリティ及び信頼性、及び（４）パートナー 間の法律的、組織的、及び文化的な境界、である。 システムの不統一に関しては、企業（組織体）は、互いに互換性のないオペレ ーティングシステム、ミドルウエアシステム、及びソフトウエアアプリケーショ ンをしばしば組み合わせて使用している。広く普及したミドルウエアは、現在も 配備されつつあるが、先導的な陣営間の相互運用は、依然として、十分 に規定されなければならないものである。特に、解決が困難なのはアプリケーシ ョンレベルでの違いであり、それは、基本的なものであって、長期にわたって解 決されるべき課題として存在し続けるであろう。 データの不統一という第２の問題に関しては、異なるアプリケーション、及び それらのアプリケーションのユーザは、しばしば、同じタスクを実行するのに、 異なる方法で情報を表現し、または、異なる種類の情報を使用する。これらの違 いは、アプリケーション及びそれらのユーザが異なる企業間に分散している場合 に、特に重大なものとなりうる。情報における関連する構文上及び意味上の相違 を埋めるためには、変換能力並びに中間オブジェクトを組み合わせたものが必要 となる。 通信セキュリティ及び信頼性という第３の問題については、ビジネスネットワ ークのシステム間のどの対話にも、信頼性があり、かつ安全な通信経路が参加者 間に存在することが必要である。安全性に関する問題は、インターネットが通信 経路内のリンクとして使用される場合に、特に重大である。なぜなら、このメデ ィアは、盗聴や他の形態のセキュリティ攻撃を受けやすいからである。 第４の問題に関しては、複数のパートナー間のビジネス（業務）プロセスを自 動化する努力を行うことよって、複数の組織に分散したプロジェクトの管理に関 連する技術的でない多くの障害を克服しなければならない。これらの課題には、 プロジェクトの優先順位とリソースの割り当てにおけるミスマッチ、言葉の違い による障壁、時間帯の違い、及び会社と政府の両方による規制が含まれる。これ らの課題によって、達成可能な協働レベルが制限される。従って、技術的な解決 策は、この解決策を実施するために必要となる、相互の約束事の範囲及び複雑さ を最小限にすることに焦点を合わせたものでなければならない。 現在のところ、相互依存プロセスを１つのコンピュータシステムを超えて、従 来のコンピュータネットワークリソースによって接続された他のシステムに拡張 するための方法として、少なくとも５つの方法が知られている。第１は、複数の コンピュータシステムのユーザが、電話、ファックス、または他のメディアを介 して互いに情報をやり取りする手動的なアプローチである。やり取りされた情報 は、次に、人手によって、それぞれのコンピュータシステムに入力 される。この手動的なアプローチは、自動化における差異を埋めるために使用す ることができるものであるが、これは明らかに、信頼性があり、かつ効率の良い 方法でパートナー間のプロセスを堅固に結合する能力を制限する。 第２のアプローチ（これは、自家製のメインフレームアプリケーションの時代 に生まれたものであるが）は、電子データ交換（ＥＤＩ）として知られている。 ＥＤＩは、広い意味で定義された用語であるが、最も頻繁には、特定の組の標準 、技術（付加価値通信網、ダイレクトダイアルアップ、ソフトウエアマッピング （mappingsoftware））、及び会社間の電子データ交換用に使用される実務慣行 を指している。ＥＤＩにおいては、ビジネス情報（例えば、買い物の注文）を収 集したものを、１つのアプリケーションシステムから読み出して、中間フォーマ ットにマッピングし、ＶＡＮ（付加価値通信網）を介してパートナーに送信し、 パートナーがパートナーのアプリケーションに適したフォーマットにマッピング して、パートナーのアプリケーションに読み込むことができる。代替的には、ダ イレクトダイアリング（direct dialing）をＶＡＮの代わりに使用することがで きる。しかしながら、ＥＤＩは、一般的にバッチ指向であり、広範にわたるフォ ーマットのカスタマイズが必要であり、プロセスを支援するものではない。 ビジネス要件がＥＤＩモデルに適さないときに使用される第３のアプローチは 、ユーザの仕様に合わせて設計され、実装されたカスタムシステムを使用するこ とである。このアプローチは、コストが高く、ネットワークプログラミング及び システムインテグレーション作業の組み合わせを必要とし、特定のユーザのため だけの特定の目的を遂行するものである。さらに、これは、柔軟性がなく、変更 することが困難である。 最近、技術における２つのトレンドが、アプリケーションシステムが相互に関 わり合うことができる方法を根本的に変えた。その結果、ＥＤＩの適用だけでな く、第４及び第５のアプローチを上記の３つに加えなければならない。第１のト レンドは、ネットワークインフラストラクチャの急速な拡大である。このインフ ラストラクチャの最も明白な部分は、インターネットによって提供されるいたる ところに見られる接続性である。ほとんどすべての組織が、インタ ーネットに接続されている（あるいは、まもなく接続されるであろう）。この接 続性には、分散アプリケーションの取扱いをより簡単にし、ソフトウエアコンポ ーネントの非常に高い相互運用性を約束する分散オブジェクトフレームワーク及 びメッセージ指向ミドルウエアのような、ミドルウエア技術の拡張セットとサー ビスが結合される。 第２のトレンドは、会社によって使用される企業向けアプリケーションシステ ムにおける進歩に関係する。これらのシステムにおける重要な進歩は、オブジェ クトインターフェースの進展、及びワークフロー／プロセスのモデリング能力の 進展を含む。オブジェクトインターフェースは、アプリケーションに対して情報 をやり取りする方法において、ＳＱＬ（Structured Query Language）、または ファイルベースのインターフェースのような従来の方法よりも、より柔軟で、か つ負担の少ない方法を提供する。現在、いくつかのアプリケーションベンダーが 、異なるアプリケーションモジュール間においてワークフローを設計し実装する 能力を提供している。この能力によって、会社は、自身のビジネスプロセスによ り容易に注力することができ、また、ビジネスパートナーのプロセスに接続する 必要性がより明確になる。 これらのトレンド、及びビジネスの相互依存を拡張するための第４のアプロー チの最も明らかな効果は、ビジネス対ビジネスの対話のためにワールドワイドウ ェブ（ＷＷＷ）を使用することである。このモデルでは、ある業務（ビジネス） の従業員が、標準的なウェブブラウザを使用することによって、カタログまたは 出荷情報のような他の会社の業務アプリケーションに属する情報にアクセスする 。しかしながら、このアプローチは、異なる組織のアプリケーションシステム間 で依存した対話を必要とする、多くの拡張された事業プロセスには適さない。 第５のアプローチは、論理的に統合されたハイパフォーマンスの分散アプリケ ーションを作成することを可能にする新しいミドルウエア技術を活用する。同じ 技術を、異なるベンダーからのアプリケーションの組の間、及び、異なるビジネ スにおけるシステム間での相互運用を提供するために使用することができるが、 重大な問題によって実現性が制限される。第1に、ミドルウエア技術 を使用することは、かなりのプログラミングスキルと、セキュリティ、同期化、 及び他のネットワークに関する問題に対する専門の知識とが要求されるプログラ ミングタスクである。そのような努力にかけるコストは、分散アプリケーション に関わるベンダーに対しては正当化することができようが、特定の拡張された事 業プロセスに関与することを望む会社が、一から分散システムを構築するために 必要な資本を投入する可能性は低い。 最後に、インターネットＥＤＩと呼ばれるＥＤＩの適用には、上述した従来の ＥＤＩによるアプローチをインターネット伝送媒体に移行することを試みる多く の方法が実際にある。これらの方法は、付加価値通信網（ＶＡＮ）に関連する高 い通信コストを低減したいという要望によって動機付けをされている。実質的に は、これらの方法は、従来のＥＤＩとほとんど違いがない。メッセージフォーマ ット、マッピングソフトウエア、さらに構造の包み（enveloping construct）さ えも同じものを利用する。しかしながら、オープンネットワークを使用すること は、以前は、ＶＡＮサービスの一部分であった、特別なセキュリティ、信頼性、 及び検査能力を必要とする。さらに、オープンネットワーク構成におけるこれら の追加サービスの使用は、情報交換の終端においてソフトウエアによってサポー トされなければならない。従って、インターネットＥＤＩは、プロセスサポート の欠如、扱いにくい表現形式、及び新しい実践方式にかみ合わない統合モデルの ような、重大な制限を受ける。 上記アプローチでは、本質的に異なるシステム間に、安全でかつ保守可能であ る複雑な自動化プロセスを実装したいという高まる要求に応えることはできない 。従って、拡張されたビジネスの相互依存性を設計して制御するためのシステム 及び方法が必要とされている。すなわち、それらは、（１）既存のビジネスアプ リケーションシステム間における、ピアツーピアの通信（対話）に特に焦点をお き、（２）安全で信頼性のある通信をサポートし、（３）カスタムソフトウエア の開発を最小限にし、（４）統一されていないデータ表現形式を取り扱う機能を 有し、（５）企業向け（事業用）アプリケーションの内外に及ぶ複雑なプロセス をサポートする能力を有する、ものである。 発明の要約 本発明は、企業間プロセスを生成し、実行し、及び保守するためのシステム及 び方法である。企業間プロセスは、組織の境界を横断して、また、統一されてい ない情報システム間において、これらのプロセスを自動化するための特別の用意 を備えた分散情報システム間の、共有（共用）化され自動化されたビジネスプロ セスまたはワークフローである。 このシステムは、共通の能力を備えたサイトと呼ばれる複数の独立した通信サ ブシステムから構成される。各サイトは、共用プロセス定義を表現し、実行する ための共通の手段を有するサーバーを備えている。これらのサイトは、システム 間の共用プロセスを実行している間、協力して動作する。プロセスの実行には、 各サイトに限定された一連の制御されたアクションに結合される、サイト間の連 係したメッセージ交換が含まれる。さらに、各サイトは、システム間プロセス、 及び内部プロセスをサーバー上で実行するために、たくさんのアプリケーション プログラム及びオペレーティングシステムの中の任意の１つを備えることができ る。 本発明のシステムにおいては、自動化されたシステム間プロセスは、２レベル のプロセスモデルで表される。トップレベル、すなわち共用（パブリック）プロ セス定義／モジュールは、独立したサイト（典型的には、それぞれが、組織また は事業単位を表す）間の相互作用（interaction、対話）を捕捉する。相互作用 は、ノードによって共用プロセス定義内で指定される１つのサイトが、他のサイ トに既知のタイプのメッセージを送信する通信イベントを備える。この場合には 、共用プロセス定義は、１組のサイト間の相互依存通信イベントの論理的なグル ープ分け、または有向グラフである。各定義は、参加サイト間における一連の有 効な通信イベントの組を規定する。 任意の共用プロセス定義に関連して、１組のより低レベルの、または、専用（ プライベート）のプロセス定義もしくはモジュールがある。個別の専用プロセス 定義は、共用プロセスの各ノードに結合される。この専用プロセス定義は、特定 の共用プロセスノードが実行されるときに、サイトで実行可能な、１組の可能性 のあるローカルなアクションを規定する。好ましい実施態様では、専用 プロセス定義は、ノードまたはサイトに固有の動作パラメータ、及びソフトウエ アアプリケーションの相互作用のような構成に関して定義される。 図面の簡単な説明 図１は、本発明に従って、共用（パブリック）プロセス定義と、専用（プライ ベート）プロセス定義を有する複数のサイトを備える、拡張された事業システム のブロック図である。 図２は、本発明に従って、ノード、アーク(arc)、及びそれらの間の接続を含 む共用プロセス定義を表す図である。 図３は、本発明に従って、専用プロセス定義を実行するためのプロセスを示す 流れ図である。 図４は、本発明に従うシステムのブロック図である。 図５は、本発明に従って、共用プロセス定義を配信するための方法を示す流れ 図である。 図６は、本発明に従って、共用プロセス定義を実装するための方法を示す流れ 図である。 図７は、本発明に従って、特定のプロセスタイプのインスタンスを実行するた めの方法を示す流れ図である。 図８は、共用プロセス定義を編集するためのグラフィックユーザインターフェ ースを表示している表示装置を示す図である。 図９は、専用プロセス定義を編集するためのグラフィックユーザインターフェ ースを表示している表示装置を示す図である。 好ましい実施態様の説明 図１に、拡張された事業用システム１００の好ましい実施態様を示す。本発明 の好ましい実施態様による拡張された事業用システム１００は、好ましくは、通 信ネットワーク１０４によって結合された個別の組織に設置された、複数のサイ ト１０１、１０２、及び１０３から構成される。これらのサイト１０１〜１０３ は拡張された事業用システム１００を形成し、このシステム１００にお いて、各サイト１０１〜１０３の内部プロセスは、連係した情報交換シーケンス によって、他のサイト１０１〜１０３の内部プロセスに結合される。例えば、サ イト１０１〜１０３は、供給チェーンの３つの要素、すなわち、供給者、製造者 及び顧客を含む企業とすることができる。しかしながら、当業者には、サイト１ ０１〜１０３を、任意の数のサイトが存在可能な任意のタイプのビジネス単位ま たは機能に対するものとすることができ、３つのサイト１０１〜１０３は、一例 として提供されただけのものであるということが理解されよう。 これらのサイト１０１〜１０３の各々は、制御区域を表しており、情報を記憶 し、その情報を検索して、変更するためのロジックを備えた１組のアプリケーシ ョンシステムによって構成される。例示のアプリケーションは、ＥＲＰ（事業リ ソースプランニング、Enterprise Resource Planning）アプリケーションの組、 製品データ管理（ＰＤＭ）システム、物流アプリケーション、及び先進のプラン ニングシステム（ＡＰＳ）を備える。 本発明の動作は、各サイト１０１〜１０３内の連係した一連のアクションを含 んでおり、これらのサイトは、異なるサイト１０１〜１０３間の連係した一連の 情報交換に関連付けられている。各サイト１０１〜１０３内で実行されるアクシ ョンには、主として、サイト１０１〜１０３に関連するアプリケーションに対す る情報のやり取りが含まれる。サイト１０１〜１０３間の各情報交換の前に、送 信サイト内で一連のアクションが起こり、該情報交換の後に、受信サイト内で別 の一連のアクションが起こる。従って、これらのサイト固有の一連のアクション は、１組の情報交換を、単一の連係した一連の相互作用（対話）に結合するコネ クション（結合子）として機能する。 可能性のある一連のローカルアクション、及びサイト間交換は、プロセス定義 言語によって規定される。この言語は、複雑な分岐及びループ論理を可能にし、 ローカルアクションのシーケンスとサイト間交換との間の関係を制御（支配）す る制約を取り込むことができる。さらに明確に言うと、好ましい実施態様のプロ セス定義言語は、ノードと、（図２に示すような、そして、以下で説明する）有 向グラフを作成するための特定の命令及びロジックに結合されたアーク要素（ア ークエレメント）とを備える。単一の発信元ノード２０５〜２２ ５及び単一の送信先ノード２０５〜２２５が、各アーク要素を定義する。各ノー ド２０５〜２２５は、１組の入力アーク、及びそれを先行するノード２０５〜２ ２５に結合する関連ロジック、さらに、１組の出力アーク、及びそれを後のノー ド２０５〜２２５に結合する関連ロジックとを備える。所定のノード２０５〜２ ２５に対する入力アーク間の関係は、論理文によって定義されるが、この論理文 は、場合によっては、入れ子になった結合及び分離を行う命題結合記号(proposi tional connective)を含み、各アークは、個別の命題シンボルによって表される 。所定のノードに対する出力アークは、等価な形式の個別の論理文によって関連 付けられる。ノード２０１は、入力アークをもたず、イニシエータ（開始）ノー ドと呼ばれる。ノード２９９は、出力アークをもたず、ターミナル（終端）ノー ドと呼ばれる。 好ましい実施態様では、サイト間の情報交換の収集と、サイト固有のアクショ ンシーケンスを表すために、２レベルのプロセスモデルが使用される。共用プロ セス定義またはモジュール１１６ａが、すべてのサイト間の情報交換の間の関係 を規定する。共用プロセス定義１１６ａ内の特定のノードに対する、単一のサイ ト１０１、１０２、１０３内の可能性のあるアクションシーケンスは、専用プロ セス定義またはモジュール１１８ａ、１１８ｂ、１１８ｃによって規定される。 共用プロセス定義及び専用プロセス定義１１６ａ、１１８ａ、１１８ｂ、１１８ ｃは、いずれも、ノード２０５〜２２５及びアーク要素に対して特定の解釈を有 するプロセス定義言語の最上部で構築される。共用プロセス定義１１６ａにおい て、各ノード要素は、特定のサイト１０１、１０２、１０３を表し、各アーク要 素は、アークの送信先ノードによって表されるサイトに対するアークの発信元ノ ードによって表されるサイト１０１、１０２、１０３から送信される特定の情報 内容を有するメッセージを表す。共用プロセスに対するグラフは、開始ノードを １つだけ含むことができる。この場合、共用プロセス定義１ｌ６ａは、特定の目 的のために、１組のサイト１０１〜１０３の間で、「誰が、いつ、何をするか」 を規定するものである。各共用プロセス定義１１６ａは、参加サイト１０１、１ ０２、１０３の間で、１組の有効な通信イベントのシーケンスを規定する。より 詳しくは、同じ共用プロセス定義１１６ａが、 この共用プロセス定義１１６ａ内のアクションを有する各サイト１０１、１０２ ２、１０３に与えられる。図１に示すように、各サイト１０１、１０２、１０３ は、各サイト間プロセスに対して１つずつ、１つまたは複数の共用プロセス定義 １１６ａを有することができる。専用プロセス定義１１８ａ、１１８ｂ、１１８ ｃにおいて、ノード要素は、特定のプログラムに基づいたアクションを表し、ア ーク要素は、これらのアクションが実行される順序を規定する。専用プロセス定 義１１８ａ、１１８ｂ、１１８ｃは、サイト１０１〜１０３がどのようにして受 信メッセージを処理して、出力メッセージを構築するかを規定する。さらに、専 用プロセス定義１１８ａ、１１８ｂ、１１８ｃは、共用プロセス定義１１６ａの ノード内で起こることを規定する。従って、専用プロセス定義１１８ａ、１１８ ｂ、１１８ｃは、この専用プロセス定義１１８ａ、１１８ｂ、１１８ｃが割り当 てられ、または、動作する特定のサイト１０１、１０２、１０３に適合したルー チン及びプロセスを備える。さらに詳しくは、専用プロセス定義１１８ａ、１１ ８ｂ、１１８ｃは、それが割り当てられるサイトのオペレーティングシステム、 アプリケーション、及びリソースを使用して相互作用をするために設計される。 従って、図１に示すように、各専用プロセス定義１１８ａ、１１８ｂ、１１８ｃ は、各サイト１０１、１０２、１０３に対するものとは異なる。それにも関わら ず、サイト１０１、１０２、１０３が類似して構成される（例えば、同じオペレ ーティングシステム、アプリケーション、及びリソースを有するように構成され る）場合には、この専用プロセス定義１１８ａ、１１８ｂ、１１８ｃを使用また は共用することができる。各サイト１０１、１０２、１０３は、また、図１に示 すように、複数の専用プロセス定義１１８ａ、１１８ｂ、１１８ｃを備えること ができるということが、当業者には理解されよう。この複数の専用プロセス定義 １１８ａ、１１８ｂ、１１８ｃは、ある共用プロセス定義１１６ａに対するもの とすることも、また、それとは異なる共用プロセス定義１１６ａに対するものと することも可能である。 この好ましい実施態様は、構造及び動作が制限されたオブジェクトとして、サ イト１０１、１０２及び１０３間を送信されるメッセージに含まれる情報をモデ ル化する。これらのオブジェクトはデータの入れ物であって、その可能性 のある内容が、オブジェクト定義１２０ａ、１２０ｂ、１２０ｃによって規定さ れる。好ましい実施態様では、オブジェクト定義１２０ａ、１２０ｂ、１２０ｃ は、ＸＭＬ（拡張マークアップ言語）ＤＴＤ（文書型定義）の形態を取る。この 定義は、そのタイプのすべてのオブジェクトの語義的及び文法的型式を規定する 。オブジェクト定義１２０ａ、１２０ｂ、１２０ｃは、共用プロセス定義、及び 専用プロセス定義の両方によって参照される。 図２に、典型的な共用プロセス定義２００を示す。この共用プロセス定義２０ ０は、流れ図として図で示されている。図２は、サイト１０１〜１０３間で起こ りうる１組の相互作用を規定する共用プロセス定義２００を示している。プロセ ス定義２００は、２０５から２２５までの１組のノード、及び、２３０から２５ ０までの１組の通信イベントを含む。各ノードは、特定のサイト１０１〜１０３ に対応し、共用プロセス定義２００の各ノード２０５〜２２５に関連して、専用 プロセス定義１１８ａ、１１８ｂ、１１８ｃがある。図３に、ノード２１０に関 連する典型的な専用プロセス定義３００を示す。 共用プロセス定義２００において、あるノードを他のノードに接続する各通信 イベント２３０〜２５０は、既知のオブジェクトタイプのメッセージの交換を表 す。例えば、既知のオブジェクトは、購入発注オブジェクト、確認メッセージオ ブジェクト等のような従来のタイプのビジネスオブジェクトのうちの任意の１つ とすることができる。そのようなオブジェクト１２０ａ、１２０ｂ、１２０ｃは 、オブジェクト定義１２０ａ、１２０ｂ、１２０ｃにおいて定義され、それによ って、各サイト１０１、１０２、１０３が、共用レベルまたは専用レベルのいず れかのレベルでオブジェクトを処理する必要に応じて、オブジェクト定義１２０ ａ、１２０ｂ、１２０ｃを使用することができる。すなわち、共用プロセス定義 ２００は、図１に示すように、サイト１０１〜１０３間の相互依存通信イベント ２３０〜２５０の論理的なグループ分け、または有向グラフである。このグルー プ分けは、参加サイト１０１、１０２、１０３の間の１組の有効な通信イベント のシーケンスを規定する。具体的には、共用プロセス定義２００は、通信イベン ト２３０において、サイト１０１からサイト１０２に送られる購入発注を記述す る。この購入発注は、ノード２０５に関連するサ イト１０１の専用プロセスによって生成される。ノード２１０は、分岐ノードで あり、２つの通信イベント２３５及び２４０が、そのノードで生成される。指定 された分岐条件に依存して、それらのイベントのうちの１つのイベント、または 両方のイベントが発生する。これらの２つのイベントがトリガされる条件は、共 用プロセス定義２００によっては指示されない。なぜなら、それらを知っている のはサイト１０２のみだからである。これらの条件は、ノード２１０、従って、 サイト１０２に関連する専用プロセス定義１１８ｂに含まれている。専用プロセ ス定義１１８ｂは、共用プロセス定義１１６ａのインスタンスに相当する１組の 専用プロセス定義とすることができるということが、当業者には、また、理解さ れよう。 イベント２３５及び／又は２４０の発生により、直後に続くノード（１つまた は２つのノード）が実行され、図の下方に向かって実行が進行する。ノード２２ ５は、それに接続した組の１つまたは全てのイベントを待つことができる分岐結 合ノードである。ノード２２５の実行に続いて、共用プロセスは終端（ターミナ ル）２９９で終了する。 共用プロセス定義２００の２０５から２２５の各ノードに関連して、専用プロ セス定義１１８ａ、１１８ｂ、１１８ｃがある。例えば、図３に、ノード２１０ に関連する専用プロセス定義３００を示す。共用プロセス定義２００とは異なり 、専用プロセス定義３００の内容は、対応するサイト（この場合、サイト１０２ ）によってのみ、決定され、かつ認識される。専用プロセス定義３００は、所定 のロジックに従って制御される多くのアクション（３０５から３３０）を含む。 起こりうるアクションには、外部のビジネスアプリケーション通信、スクリプト 実行、ユーザ通知と承認、時間遅れ、出力オブジェクト仕様、及びサブプロセス 実行が含まれる。専用プロセス定義３００のすべてのインスタンスは、通信イベ ント２３０に含まれるオブジェクトタイプ「購入発注」にアクセスすることがで きる。専用プロセス定義３００のどのアクションも、このオブジェクトを参照す ることができる。専用プロセス定義３００は、通信イベント２３５及び２４０に それぞれ対応して、「確認応答（Acknowledgement）」または、「購入発注」の タイプのいずれかのオブジェクトを生成しなければな らない。 図３には、専用プロセス定義３００の典型的な１実施態様が示されている。専 用プロセス定義３００は、通信イベント２３０が完了した後に実行するイニシエ ータアクション３０１で始まる。このプロセスは、オブジェクトが、サイト１０ １、１０２、１０３に転送または受信されると、通信イベントに続くノードに対 応する専用定義が自動的に開始するような、種々の他の専用プロセス定義に対す るものと類似しているということが、当業者には理解されよう。専用プロセス３ ００は、アクション３０５を続行する。アクション３０５の実行は、受信した購 入発注に相当する情報ブロックを、ビジネスアプリケーション１１３に送ること を伴う。アクション３０５の実行が完了すると、アクション３１０に移る。アク ション３１０は、ビジネスアプリケーション１１４に照会して、通信イベント２ ３０の購入発注に関連する品物の在庫があるか、あるいは外部に委託されている かを決定することを伴う。この照会の結果は、専用プロセス３００に関連する１ 組の変数のうちの「OUTSOURCED」という名前の変数に入れられる。アクション３ １５が、アクション３１０に続いて実行される。アクション３１５には、スクリ プトアクション内での、OUTSOURCEDの値についてのIF-THEN-ELSEの条件テストが 含まれる。この条件テストの結果によって、アクション３１５の完了に続いて、 経路Ａまたは経路Ｂのどちらをとるかが決定される。経路Ａをとると、アクショ ン３２０に進む。アクション３２０は、「確認応答」のタイプのオブジェクトを 構築し、専用プロセスの出力として指定することを伴う。経路Ｂをとると、アク ション３２５に進む。アクション３２５は、「購入発注」のタイプのオブジェク トを構築し、専用プロセスの出力として指定することを伴う。経路ＡとＢはアク ション３３０で終了する。アクション３３０は、稼働中のプロセスに関連する所 定のステータス情報を、電予メールによって指定されたユーザに通知することを 伴う。この情報は、購入発注の特徴（指標）の識別と、ビジネスアプリケーショ ン照会の結果を含むものである。専用プロセスは、アクション３３０の実行に続 いて終了し、制御は、共用プロセスレベルに戻る。このような専用定義を使用す ることは、特に有利である。なぜなら、これによってサイト間プロセスの一様な 制御及び調整が提 供されるとともに、特定のサイトのコントローラが、特定のサイトのパラメータ 、リソース、及び他の制約に従う任意の方法で、専用定義を実施することを可能 にする、専用定義の使用による最大限の柔軟性が許容されるからである。 好ましい実施態様の各サイトは、共用プロセス及び専用プロセスの設計、実装 、及び保守をサポートするコンポーネントと、これらのプロセスの実行をサポー トするランタイムコンポーネントの組み合わせを備える。図４に、例としてのサ イト１０２の好ましい構成を示す。 標準的なサイト１０２は、単一のサーバ４８０と、ネットワーク４０９を介し てサーバと通信する１つまたは複数のクライアント４６０、４７０から構成され る。クライアント４６０及び４７０、サーバ４８０は、別々のホストコンピュー タ上で動作する。クライアント４６０及び４７０は、グラフィックユーザインタ ーフェース（ＧＵＩ）４６５及び４７５をそれぞれ備えている。さらに、サーバ ４８０は、データベース４１０、アプリケーション４２０及び４３０を備えてい るか、または、それらにアクセスすることができる。好ましい実施態様では、デ ータベース４１０は、サーバ４８０が置かれているホストコンピュータとは別の ホストコンピュータに置かれる。クライアント４６０及び４７０、サーバ４８０ は、指定された従来の通信プロトコルに従って、ネットワーク４０９を介して対 話することによって、関連する情報の共通の表現を共有する。そのような共有さ れた情報の表現は、共用プロセス定義及び専用プロセス定義、オブジェクト定義 、プロセス実行履歴、並びに、サイトが対話する他のサイトに関する情報を含む 。ユーザ４４０及び４５０は、クライアントのＧＵＩ４６５及び４７５を介して サイト１０２と対話して、上記のように範囲を定められた共有された情報の表現 を目視し、生成し、編集し、及び管理する。例えば、ユーザ４４０及び４５０は 、共用プロセス２００と専用プロセス３００のグラフィック表現をＧＵＩ４６５ 及び４７５上で見て、編集することができる。図８及び図９に、図２及び図３に それぞれ関連して説明した共用プロセス定義及び専用プロセス定義に相当するＧ ＵＩの１画面を示す。 好ましい実施態様のサーバ４８０は、中間層マネージャセット４８２、実行エ ンジン４８４、伝送マネージャ（トランスポータ）４８６、及びアダプター ４８８、４８９から構成される。中間層マネージャセット４８２は、ネットワー ク４０９、エンジン４８４、及びデータベース４１０間の情報のアクセスとその 流れを制御する。さらに、それは、関連するアプリケーションロジックを実施し 、これらの構成要素の間の情報の一貫性を保証する。ネットワーク４０９に関し ては、マネージャセット４８２は、同時に動作しているクライアントとサーバ４ ８０の他の構成要素からの情報に対するアクセスを仲介する。 以下に詳細に説明するように、共用プロセス２００と専用プロセス３００のイ ンストールには、ユーザ４４０または４５０の事前の承認が必要である。この承 認が受け入れられた場合には、それは、適正なユーザによって、それぞれのＧＵ Ｉを介してクライアント４６０または４７０に入力される。次に、ローカルなイ ンストール信号が、ネットワーク４０９を介してサーバ４８０に中継される。受 信信号に従って動作するマネージャセット４８２は、エンジン４８４へのプロセ ス定義のインストールを開始する。インストールの間、実行エンジン４８４は、 それが受信するプロセス定義を、データベース４１０に保存されている実行可能 な状態マシンに転送する。この転送は、目的のサイトを含むアークに接続された すべてのノードを共用プロセス定義から抜き取る。結果とし生じた状態マシンは 、単一のサイトが、元の共用プロセスの実行に参加するのに必要なすべての情報 を含んでいる。インストールが完了すると、マネージャセット４８２が、データ ベース４１０に記憶された、または、クライアント４６０及び４７０から受け取 ったプロセスを実行するために必要な追加の情報をエンジン４８４に与える。共 有データの持続性が、データベース４１０との通信によって維持される。 共用プロセス定義２００及び専用プロセス定義３００のインストールが完了す ると、エンジン４８４がそれらの実行を制御する。実行中、実行エンジン４８４ は、２つの重要な作業、すなわち、伝送マネージャ４８６を介する他のサイトと の入出力通信と、アダプター４８８及び４８９を介するアプリケーション４２０ 及び４３０との対話を管理する。エンジン４８４は、また、マネージャセット４ ８２を介して、ユーザ４４０及び４５０に対するメッセージの送受信、及びデー タベース４１０へのログ情報の格納を含むいくつかの補助的な作 業を管理する。 定義２００のような共用プロセス定義の実行中、伝送マネージャ４８６が、イ ンターネット１０４に対する通信を管理する。例えば、共用プロセス定義２００ は、サイト１０２による購入発注２３０及び確認応答２４５の受信、並びに確認 応答２３５及び購入発注２４０の送信を予期する。この機能においては、マネー ジャ４８６は、（それが使用するサービスの属性に基づいて）再試行と確認応答 のロジックを処理するのが好ましい。メッセージは、任意の特定の伝送サービス の外側で生成され、通信セキュリティは、メッセージベースである。出所と配送 の両方に対する拒否されない受信がサポートされる。 実行中、アダプター４８８と４８９が、実行エンジン４８４と、外部アプリケ ーション４２０及び４３０との間のデータの流れを仲介する。例えば、専用プロ セス定義３００のステップ３１５を参照すると、エンジン４８４は、アダプター ４８８または４８９を介して、問題の品物が外部委託されているかどうかを判定 するアプリケーション４２０または４３０にリクエストを送信することができる 。次に、アプリケーションは、それぞれのアダプターを介して応答する。４８８ 及び４８９に対するアダプター構成オプションは、関連するサイトに対する専用 プロセスの作成者によって設定される。これらのアダプター４８８及び４８９は 、それらの許容可能な構成オプションを、それらのインストール時に中間層マネ ージャセット４８２に伝える。アダプター４８８及び４８９に対する構成インタ ーフェースによって、専用プロセスは、外部アプリケーションにデータを挿入し たり、外部アプリケーションからデータを検索したり、または、外部アプリケー ションによって生成された特定のイベントに対して問い合わせる（聞く）ことが できる。ここで、データが挿入されたか、検索されたか、または問い合わせられ たかは、オブジェクト定義によって表される。アダプター４８８及び４８９は、 また、状態/一貫性管理の一様な特性を保証し、システムに統合することができ る異なるアプリケーション間の動作を検査する。プロセスの実行中、アダプター ４８８及び４８９は、専用プロセスにおいて指定されたアクションに対する挿入 、検索及び問い合わせを目的のアプリケーション４２０及び４３０との特定の対 話にマッピングする。 好ましい実施態様のサイトの動作は、共用プロセス定義、関連する専用プロセ ス及びオブジェクト定義のライフサイクルを循環する。図５に示すように、この サイクルは、共用プロセス定義と参照するオブジェクト定義の作成から始まり、 次に、共用プロセス定義とオブジェクト定義の配信、必要な専用プロセス定義の 作成、プロセスのインストールに続き、そして、プロセスの実行で終了する。 ステップ５０２で、ユーザが共用プロセス定義を作成する。共用プロセス定義 ２００が作成されるサイトは、オーサリングサイトと呼ばれる。共用プロセス定 義２００の作成には、共用プロセス定義内のサイト間メッセージを表すすべての オブジェクト定義の作成が含まれる。好ましい実施態様では、共用プロセス定義 及びオブジェクト定義の両方とも、クライアントのＧＵＩ４６５及び４７５を介 してマネージャセット４８２と対話するユーザ４４０及び４５０によって作成さ れる。共用プロセス定義２００の作成中、例えば、ユーザ４４０は、すべての参 加サイト１０１、１０２、及び１０３間の対話シーケンスと、これらの対話を結 合するロジックを指定する。この例では、ＧＵＩ４６５は、図２の図と同じ様に 見える流れ指標（インジケータ）によって内部接続された１組のアイコンとして 、定義２００を表示する。購入発注、確認応答、及び拒否オブジェトに対する定 義もまた、それらが事前に存在していなければ、ユーザ４４０によってＧＵＩ４ ６５を介して作成される。 共用プロセス及び必要なオブジェクトを定義した後、ユーザは、プロセスの配 信に進む。ステップ５０４で、オーサリングサイトは、インターネット１０４を 介して、作成した共用プロセス定義と参照されるオブジェクト定義を、共用プロ セスに参加するすべてのサイトに送信する。インターネット１０４は、ローカル エリアネットワーク（ＬＡＮ）上のイントラネット、ワイドエリアネットワーク （ＷＡＮ）上のインターネット、またはいわゆるインターネットとすることがで きるということが、当業者には理解されよう。この場合、サイト１０２は、オー サリングサイトであり、サイト１０１及び１０３は、参加サイトである。サイト １０２が、共用プロセス定義２００と関連するオブジェクト定義をインターネッ トを介して送信するために、これらの定義は、マネージャ セット４８２から伝送マネージャ４８６へ、及びそこから参加サイトの伝送マネ ージャへと送信される。共用プロセス定義２００及びオブジェクト定義が参加サ イト（この場合には、サイト１０１と１０３）の伝送マネージャによって受け取 られると、それらの定義は、伝送マネージャから中間層マネージャに、データベ ースへの永続的な記憶のために渡される。受信した共用プロセス定義２００及び オブジェクト定義をクライアントのＧＵＩによって検査した後、参加サイト１０ １及び１０３のユーザは、共用プロセス定義を承認または不承認しなければなら ない。この承認または不承認は、パートナーのサイトの伝送マネージャを介して オーサリングサイトに送られる。共用プロセス定義２００が、参加サイト１０１ 及び１０３で検査されている間に、オーサリングサイト１０２は、ステップ５０ ８で、伝送マネージャ４８６によって受け取られることになる承認または不承認 の結果を待つ。サイト１０１及び１０３による承認または不承認は、技術的な関 心事ではなくて、営業的な関心事を表すものであろう。パートナーのサイトが、 定義２００に記述された商用上の配置（commercial arrangement）が許容可能で あることを見いだした場合は、それは、この場合サイト１０２であるオーサリン グサイトに承認信号を返す。ステップ５０８で、システムは、すべての承認が得 られたかどうかについて検査をし、参加サイト１０１または１０３のいずれかが 共用プロセス２００を承認しない場合には、オーサリングサイト１０２が、中止 メッセージを伝送マネージャ４８６を介してパートナーのサイト１０１及び１０ ３に配信し、そして、ステップ５１０に進む。この場合には、共用プロセス定義 ２００は破棄され、サイト１０１、１０２、及び１０３は、新たな共用プロセス 定義について交渉を開始することができる。ステップ５０８で、共用プロセス定 義があまねく許可された場合には、オーサリングサイト１０２は、パートナーサ イトのそれぞれにコミットメッセージ（commit message）を配信する。 コミットメッセージがオーサリングサイトによって送信されて、参加サイトに よって受信された後、オーサリングサイトと参加サイトの両方のサイトは、各サ イトが所有する共用プロセスノードに関連する専用プロセスの生成に進む。これ は、図５のステップ５１４によって表されている。各サイトのユーザは、 ユーザのサイトに関連する共用プロセス定義の各ノードに対する専用プロセス定 義を作成する。例えば、ユーザ４００は、ノード２１０に対する専用プロセス定 義３００と、ノード２２０に対する付随する専用プロセス定義を作成する。とい うのは、ノード２１０及び２２０は、それぞれサイト１０２に関連付けられてい るからである。同様に、サイト１０１のユーザは、ノード２０５及び２２５に対 する専用プロセス定義を作成し、一方、サイト１０３のユーザは、ノード２１５ に対する定義を作成する。 必要な専用プロセス定義を首尾良く実装した後、各参加サイトは、専用プロセ ス定義の実装完了を示すメッセージをオーサリングサイトに送信する。ステップ ５１６で、オーサリングサイトは、すべてのサイトからの専用プロセス完了信号 を収集する。もし、どれかのサイトが１つまたは複数の専用プロセスの実装に失 敗した場合には、そのサイトは、オーサリングサイトに失敗メッセージを送信す る。この場合は、実装プロセスは中止され（ステップ５１８）、プロセス定義２ ００は破棄される。オーサリングサイトが、すべての参加サイトから、専用プロ セスの実装がうまく完了したことを示すメッセージを受け取り、さらに、それ自 身の専用プロセスを首尾良く実装すると、オーサリングサイトは、インストール プロセスを開始することができる（ステップ５２０）。 プロセスのインストール（ステップ５２０）は、オーサリングサイトがインス トールメッセージをすべての参加サイトに送信することから始まる。このインス トールメッセージを受信すると、各参加サイトは、ローカルに共用プロセスをイ ンストールする。図６は、単一のサイトで、共用プロセス定義に関連する専用プ ロセス定義をインストールするためのプロセスを示す流れ図である。ステップ６ ０２で、共用プロセス定義及び関連する専用プロセス定義が、マネージャセット ４８２から実行エンジン４８４に送られる。ステップ６０４で、共用プロセス定 義は、対象としているサイトに対してのみの状態を含む状態マシンを作成するた めにコンパイルされる。例えば、サイト１０２における共用プロセス定義２００ のコンパイルの処理は、ノード２１０及び２２０に関連した状態を生成すること になる。状態マシンに記憶されるのは、各状態に対するトリガイベントである。 共用プロセス定義２００の例を続行して、サイト１０ ２は、そのイベント２３０、すなわちサイト１０１からの購入発注を記録し、ノ ード２１０に関連した状態、及び、サイト１０３からの確認応答であるイベント ２４５をトリガし、ノード２２０に関連する状態をトリガする。ステップ６０６ で、状態マシンの各状態は、「コール（call）」コマンドによって関連する専用 プロセス定義に結合される。例えば、サイト１０２は、専用プロセス定義３００ をノード２１０に関連する状態に結合する。この結合の結果は、ノード２１０に 関連する状態が、サイト１０１からの購入発注によってトリガされると、専用プ ロセス定義３００が呼び出されて実行されるということである。ステップ６０８ で、対象とするサイトが共用プロセスのイニシエータであるかどうかが判定され る。サイト１０２の例のように、イニシエータでなければ、実行エンジンは、受 信すべきトリガメッセージを決定して、それを伝送マネージャに登録する。サイ ト１０２の例では、サイト１０１からの購入発注２３０と、サイト１０３からの 確認応答２４５という２つのトリガメッセージがある。もし、サイトが共用プロ セスのイニシエータであれば、第１の専用プロセスに対するトリガイベントは、 そのサイトの内部にあり、ステップ６１２で、イベントトリガ、スケジューリン グされたスタートアップ、または、サブプロセスのトリガとして登録される。 共用プロセスを首尾良くインストールすると、各参加サイトは、オーサリング サイトにインストール確認メッセージを返す。ステップ５２２で、オーサリング サイトは、すべての参加サイトからのインストール確認メッセージを収集する。 どれかのサイトが、共用プロセスをインストールすることができなかった場合に は、そのプロセスは上述したようにステップ５２４で中止される。オーサリング サイトにおけるインストールの成功によって、すべての関連するサイトで共用プ ロセスがインストールされたということを示す、すべての参加サイトへのメッセ ージの送信がトリガされる。この時点で、プロセスは、実行の準備が整う（ステ ップ５２６）。 上述したように、共用プロセスの実行は、実際には、パートナーのサイトにお ける関連する専用プロセスの対話的な実行によって行われる。単一のサイトによ るインストールされた共用プロセスの実行のようすを図７に示す。実行は、 ステップ７０２で、パートナーのサイトからのメッセージの受信、アプリケーシ ョンに関連するイベント、スケジューリングされたスタートアップ、またはサブ プロセスのトリガを含むことができる開始イベントにより始まる。例えば、共用 プロセス定義２００のノード２１０は、サイト１０１からの購入発注メッセージ の受信によってトリガされる。ステップ７０４で、そのトリガされたサイトにお ける実行エンジンが、適切な状態マシンにおいてインスタンスを作成して、その 状態マシンを初期状態に設定する。ステップ７０６で、実行エンジンは、関連す る共用プロセスノードに関連した専用プロセスを取り出す。例えば、ノード２１ ０のトリガ時に専用プロセス定義３００がアクセスされる。ステップ７０８で、 実行エンジンは、イベント２３０の内容を含む適切なデータを専用プロセスに送 って、その実行を開始する。ステップ７１０で、専用プロセスが実行されて、実 行エンジンにデータ返し、ステップ７１２で、実行エンジンは、その返されたデ ータに基づいて動作する。例えば、専用プロセス３００は、サイト１０１に確認 応答を送信するための命令、またはサイト１０３への購入発注のいずれかを実行 エンジン４８４に返す。ステップ７１０における専用プロセスの実行の間、エン ジン４８４は、アプリケーション４２０と４３０を利用することができるという ことに注意すべきである。実行エンジン４８４は、それに従って応答する。ステ ップ７１４で、共用プロセス定義がローカルに終了した状態となったかどうかに ついての判定が実行エンジンによってなされる。この判定は、ローカルな判定で あって、共用プロセスにおける参加サイトに限定される。例えば、ノード２２０ の完了は、サイト１０２についてのローカルな終了状態である。なぜなら、それ は、サイト１０２に対応するプロセス２００における最終ノードであるからであ る。同様に、付随する専用プロセスの結果に依存して、ノード２１０の完了を、 サイト１０２に対するローカルな終了状態とすることができる。ローカルな終了 が起こると、ステップ７１６で、そのサイトについての共用プロセスは終了する 。ステップ７１６は、２つのフェーズのコミットプロトコル（commit protocol ）が、サイト１０１、１０２、及び１０３間で実行されて、プロセス２００の実 行が相互に完了したことが保証されるまでは完了しない。 ステップ７１４で、ローカルに終了した状態にならない場合は、伝送マネージ ャは、パートナーのサイトからのトリガメッセージを待つ（ステップ７１８）。 例えば、ノード２１０の結果が、イベント２４０における購入発注の送信である 場合は、伝送マネージャ４８６は、イベント２４５の確認応答を待って、ノード ２２０に関連する専用プロセスをトリガする。ステップ７２０でトリガメッセー ジが受信されると、ステップ７２２において、実行エンジンは、関連するプロセ スの状態について調べる。次に、専用プロセスが、ステップ７０６で実行を開始 し、上述したように実行される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，Ｍ Ｗ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，Ｅ Ｓ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，Ｍ Ｇ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ， ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，Ｖ Ｎ，ＹＵ，ＺＷ (72)発明者 フロスト，ヒルドレス，ロバート アメリカ合衆国カリフォルニア州94131, サンフランシスコ，チャーチ・ストリー ト・1513 (72)発明者 シブナブカラス，チェリア アメリカ合衆国カリフォルニア州94002, ベルモント，カールモント・ドライブ・ナ ンバー１・2156 (72)発明者 ニベリンク，ミッチェル，ダブリュー アメリカ合衆国カリフォルニア州94061, レッドウッド・シティ，ウエスト・オーク ウッド・ブルバード・299 【要約の続き】 ルが存在する。専用プロセス定義は、その特定の共用プ ロセスノードが実行されるときに、サイトで実行するこ とができる１組の可能性のあるローカルアクションを指 定する。好ましい実施態様では、専用プロセス定義は、 動作パラメータやソフトウエアアプリケーションの相互 作用のような構成に関して定義される。

Claims (1)

1. 【特許請求の範囲】 １．第１のサイトに関連した第１のノード、第２のサイトに関連した第２のノー ド、及び前記第１及び第２のノードに結合されたアークとからなる共用プロセス 定義を使用して、前記第１と第２のサイト間のプロセスを調和させるための方法 であって、 前記第１のノードに関する共有情報によって関連付けられた第１の専用プロセ ス定義を実行することによって、前記第１のサイトにおいて前記共用プロセス定 義の前記第１のノードを実行するステップと、 前記アークによって定義されたメッセージの受信時に、前記第２のノードに関 する共有情報によって関連付けられた第２の専用プロセス定義を実行することに よって、前記第２のサイトにおいて前記共用プロセス定義の前記第２のノードを 実行するステップ とからなる方法。 ２．前記アークが、ビジネスオブジェクトである請求項１の方法。 ３．前記第１のサイトにおいて、前記共用プロセス定義を作成するステップと、 前記第２のサイトに、前記共用プロセス定義を配信するステップと、 前記第１のサイトにおいて、共有情報によって、前記第１のノードに、該第１ のサイトからのメッセージの送信に先行するアクションを含む第１の専用プロセ ス定義を関連付けるステップと、 前記第２のサイトにおいて、共有情報によって、前記第２のノードに、該第２ のサイトによるメッセージの受信に続くアクションを含む第２の専用プロセスを 関連付けるステップ とからさらになる請求項２の方法。 ４．前記配信するステップが、さらに、 前記第２のサイトにおいて前記共用プロセス定義を検査するステップと、 前記第２のサイトにおいて前記共用プロセス定義が承認された場合に、前記第 ２のサイトから前記第１のサイトに承認信号を送信するステップと、 前記第２のサイトにおいて前記共用プロセス定義が承認されない場合に、前記 第２のサイトから前記第１のサイトに不承認信号を送信するステップ を含む、請求項３の方法。 ５．前記配信するステップが、さらに、 前記第２のサイトからの承認信号を前記第１のサイトで受信した場合に、前記 第２のサイトにコミットメッセージを送信するステップと、 前記第１のサイトにおいて、前記共用プロセス定義と前記第１の専用プロセス 定義をインストールするステップと、 前記第１のサイトからのコミットメッセージを前記第２のサイトで受信した場 合に、前記第２のサイトにおいて、前記共用プロセス定義と前記第２の専用プロ セス定義をインストールするステップ を含む、請求項４の方法。 ６．前記配信するステップが、さらに、 前記第２のサイトからの不承認信号を前記第１のサイトで受信した場合に、前 記第２のサイトに中止メッセージを送信するステップ を含む、請求項５の方法。 ７．前記第１のサイトにおいて、前記共用プロセス定義を第１の状態マシンに変 換するステップと、 前記第２のサイトにおいて、前記共用プロセス定義を第２の状態マシンに変換 するステップ をさらに含む、請求項３の方法。 ８．第１のプロセス実行履歴に、前記共用プロセス定義の第１のノードの実行を 記録するステップと、 第２のプロセス実行履歴に、前記共用プロセス定義の第２のノードの実行を記 録するステップと、 前記第１及び第２のプロセス実行履歴を検査するステップ をさらに含む請求項３の方法。 ９．第１のサイトと第２のサイト間のプロセスを調和させるための方法であって 、 前記第１のサイトにおいて、該第１のサイトに関連する第１のノード、前記第 ２のサイトに関連する第２のノード、及び前記第１のノードと前記第２のノ ード間に介在するアークとを含む共用プロセス定義を作成するステップと、 前記共用プロセス定義を前記第２のサイトに配信するステップと、 前記第１のサイトにおいて、前記第１のノードに関する共有情報によって関連 付けられた第１の専用プロセス定義を作成するステップであって、該プロセス定 義において、前記第１のサイトからのメッセージの送信に先行するアクションが 定義されることからなる、ステップと、 前記第２のサイトにおいて、前記第２のノードに関する共有情報によって関連 付けられた第２の専用プロセス定義を作成するステップであって、該プロセス定 義において、前記第２のサイトによるメッセージの受信に続くアクションが定義 されることからなる、ステップと、 前記第１のサイトにおいて前記第１の専用プロセス定義を実行することによっ て、前記共用プロセス定義の前記第１のノードを実行するステップと、 前記メッセージの受信時に、前記第２のサイトにおいて前記第２の専用プロセ ス定義を実行することによって、前記共用プロセス定義の前記第２のノードを実 行するステップ とからなる方法。 １０．第１のサイトと第２のサイト間のプロセスを制御するプロセス定義を作成 するための方法であって、 前記第１のサイトにおいて、該第１のサイトに関連する第１のノード、前記第 ２のサイトに関連する第２のノード、及び前記第１のノードと前記第２のノード 間に介在するアークとを含む共用プロセス定義を作成するステップと、 前記共用プロセス定義を前記第２のサイトに配信するステップと、 前記第１のサイトにおいて、前記第１のノードに関する共有情報によって関連 付けられた第１の専用プロセス定義を作成するステップであって、該プロセスに おいて、前記第１のサイトからのメッセージの送信に先行するアクションが定義 されることからなる、ステップと、 前記第２のサイトにおいて、前記第２のノードに関する共有情報によって関連 付けられた第２の専用プロセス定義を作成するステップであって、該プロセスに おいて、前記第２のサイトによるメッセージの受信に続くアクションが定 義されることからなる、ステップ とからなる方法。