(57)【特許請求の範囲】
【請求項１】
企業システムにおいて複数のアプリケーションを統合するシステムであって、
前記システムは、前記複数のアプリケーションの間に接続された統合サーバを備え、
前記統合サーバによって、
１つまたは複数の予め定義されたビジネスプロセスを実行するプロセスエンジンと、
前記プロセスエンジンの指揮下で動作する、少なくとも１つの予め定義されたビジネスプロセスに基づいて前記複数のアプリケーションの間で１つまたは複数のメッセージングサービスを実行するランタイムエンジンと
が実行され、前記各ビジネスプロセスは、前記複数のアプリケーションの間のメッセージ交換を定義し、
前記システムは、
前記複数のアプリケーションの企業システムにおける設計時の記述を保管するリポジトリと、
前記複数のアプリケーションの企業システムにおける構成に固有な記述を保管するディレクトリと
をさらに含み、前記設計時の記述は、設計時のビジネスプロセスを含み、かつ、前記構成に固有な記述は、前記複数のビジネスアプリケーションの間で実行される構成に固有なビジネスプロセスを含み、かつ、メッセージ交換を実行するために、前記ランタイムエンジンによって使用され、
前記ディレクトリに保管された構成に固有なビジネスプロセスのそれぞれは、前記リポジトリに保管された設計時のビジネスプロセスのうちの元のビジネスプロセスへのリンクを含み、かつ、
前記リポジトリに保管された設計時のビジネスプロセスのそれぞれは、前記複数のアプリケーションの間の、論理インタフェースおよび物理インタフェースを含む通信を定義するプロセス定義を含むシステム。
【請求項２】
前記１つまたは複数の予め定義されたビジネスプロセスの一部は、前記ランタイムエンジンによる実行のために前記プロセスエンジンによってアクセス可能である請求項１に記載のシステム。
【請求項３】
前記メッセージングサービスは、前記プロセスエンジンによって実行される前記１つまたは複数のビジネスプロセスに従って、メッセージの論理ルーティング、あるアプリケーションから他のアプリケーションへのメッセージのマッピング、および前記複数のアプリケーションの物理アドレス解決を含む請求項１に記載のシステム。
【請求項４】
前記リポジトリは、前記複数のアプリケーションの設計時のインタフェース記述、前記複数のアプリケーションの間で交換されるメッセージのメッセージコンテキスト記述、および前記設計時のインタフェース記述の組を関連付けるインタフェースマッピング記述をさらに含み、
前記設計時のインタフェース記述、前記メッセージコンテキスト記述、および前記インタフェースマッピング記述は、少なくとも１つの設計時のビジネスプロセスにリンクされる請求項１に記載のシステム。
【請求項５】
前記リポジトリは、前記設計時のビジネスプロセスを抽象化して表現する設計時のビジネスシナリオ記述をさらに含む請求項１または４に記載のシステム。
【請求項６】
前記各設計時のインタフェース記述は、少なくとも１つのインタフェース型オブジェクトおよび／または少なくとも１つのメッセージ型オブジェクトへのリンクを含む請求項４に記載のシステム。
【請求項７】
前記各設計時のインタフェースマッピング記述は、ビジネスプロセスに基づくインタフェースの組の間のマッピングを定義する少なくとも１つのメッセージマッピングオブジェクトへのリンクを含む請求項４に記載のシステム。
【請求項８】
前記ディレクトリは、構成に固有なビジネスシナリオ記述をさらに含み、
前記構成に固有なビジネスシナリオ記述は、前記構成に固有なビジネスプロセスを含む請求項１から７のいずれか一項に記載のシステム。
【請求項９】
前記各構成に固有なビジネスプロセスは、少なくとも１つのルーティング関係オブジェクトおよび／または少なくとも１つのマッピング関係オブジェクトへのリンクを含む請求項８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共同ビジネスプロセスのための企業システム、関連するアーキテクチャおよび方法に関する。
【０００２】
本願は、2003年5月16日に出願した米国仮出願第60/471237号の優先権を主張するものである。
【背景技術】
【０００３】
企業は、その情報システムおよび企業ソフトウェアシステムの間の統合およびコラボレーションの高まる必要性に直面している。ほとんどの現在のシステム環境(landscape)において、多くのコンポーネントが、1対1の関係で他のコンポーネントに直接に接続され、統合機能は、アプリケーションコンポーネントおよび個々のマッピングプログラムに組み込まれている。この条件下で、情報共有の管理は困難である。これらの基盤は、実際のビジネスプロセスを正確に表すことがほとんどできず、その柔軟性において、ビジネスプロセスを左右する動的なビジネスシナリオに制限されている。
【０００４】
しかし、新しい電子ビジネスコラボレーションは、通常、企業の境界の内側および外側のすべてのアプリケーションの間の接続性を必要とする。インターネットなどのネットワークは、システムがほぼ瞬間的に他のシステムまたは個人と通信する機会を提供する。かつてはイントラネットおよびそのユーザに制限されていたビジネスプロセスが、現在は、ウェブサービスの有効な構成要素となりインターネットに移行しつつある。ウェブサービスは、オープンなインターネット標準を通して公開し、発見し、または呼び出すことができる、プログラム可能、自己完結的、自己記述的なモジュール式のアプリケーション機能である。しかし、異種システム環境での既存の企業ソフトウェアの包括的なシステムアップグレードまたは大規模リプレース戦略は、コストが高すぎるか、時間コストおよび資本コストの点で単純に実現不能である傾向がある。
【０００５】
技術的な接続性は、ハイパーテキスト転送プロトコル(HTTP)および拡張マークアップ言語(XML)などのオープンなプロトコルおよび標準規格を使用して提供されるが、異なるビジネスの意味規則（semantics）をマッピングするという課題が残される。さらなる効率化を実現するために、企業は、ますます、企業または企業内の機能にまたがる新しい種類の共同ビジネスプロセスを展開することを要求されるようになる。さらに、企業は、ますます、バッチ処理の実行ではなく、リアルタイムシナリオを処理し、管理することを必要とする。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本願は、実際のビジネスプロセスおよびシナリオによるメッセージに基づく通信を管理し、実行するビジネスプロセス管理(BPM)システムおよび方法を開示する。
【課題を解決するための手段】
【０００７】
このBPMシステムには、アプリケーションシステムにおけるビジネスプロセスに従って命令を実行するように構成されたビジネスプロセスエンジン(以下では、単純にするために「プロセスエンジン」とも称する)が含まれる。プロセスエンジンは、状態を統合サーバ上で保存して、相関関係のあるメッセージを処理する。相関関係(correlation)とは、プロセスエンジンが、単一の製品に関する購入注文(PO;Purchase Order)および送り状など、意味規則的に関連したものとしてメッセージを識別できることを意味する。プロセスエンジンは、1つのプロセス実体(instance)で複数のメッセージを受信し、保持することができる。
【０００８】
プロセスエンジンは、明示的なシリアライゼーション(肯定応答の処理を含む)を実行するように構成される。このシリアライゼーションは、送信側システムおよび受信側システムから独立しており、順序通り正確に１回だけ(Exactly Once In Order)のEOIO処理と異なり、複数の送信側システムおよび受信側システムが関与するときに動作する。プロセスエンジンは、さらに、応答メッセージの処理を含めるために、プロセスによって制御されたマルチキャストを実行するように構成される。
【０００９】
プロセスエンジンは、相関関係のあるメッセージを収集することもできる。プロセスエンジンは、変換サービスも提供し、この変換サービスは、複数のメッセージを1つのメッセージに結合する(例えば、購入注文ヘッダと任意の個数の購入注文ポジション(purchase order position)とを単一の購入注文に結合する)だけでなく、例えば、購入注文を購入注文ヘッダおよび任意の個数の購入注文ポジションに分割するなど、1つのメッセージを複数の部分に分割するように構成されている。ビジネスプロセス(以下では単に「プロセス」とも呼ぶ)は、すべての参加するメッセージ(そのプロセスが以前に受信したメッセージ)からの情報を使用することができ、以前の要求のオリジナルの送信側に応答をルーティングすることができる。
【発明を実施するための最良の形態】
【００１０】
上記および他の実施形態を、これから添付図面を参照して詳細に説明する。
【００１１】
本明細書で説明するシステムおよび方法は、異種システム環境でのアプリケーション間のメッセージ通信プロトコルを定義するビジネスプロセスの管理に関する。ビジネスプロセス管理のシステムおよび方法は、XMLおよびHTTPなどのオープンな標準規格およびトランスポートプロトコルを使用してシステム環境内の様々なアプリケーションの間のコラボレーションを統合し、動作させるように構成された交換基盤で最適に実施される。
【００１２】
図１は、アプリケーションの統合およびメッセージ交換のためのシステム100の単純化されたブロック図である。システム100に、企業の内部コンポーネント(IC)102間およびファイヤウォール105を介して1つまたは複数のIC・102と通信する外部コンポーネント(EC)104の間での共同処理のための交換基盤(XI)110が含まれる。IC・102およびEC・104は、ウェブポータル、購入プログラムまたは販売プログラム、電子メール、ビジネス管理プログラム、プロジェクト計画プログラムなどの複数のプロセスまたはサービスとそのソフトウェアおよびハードウェアのうちのいずれかを表し、好ましくはウェブベースアプリケーションである。IC・102、EC・104のそれぞれは、複数の通信プロトコルまたは標準規格のうちの少なくとも1つに従って、1つまたは複数の他のコンポーネントとメッセージを介して通信する。
【００１３】
XI・110は、コンポーネント102および104の間のコラボレーションを実行する自己完結的なモジュール化された交換プラットフォームである。XI・110には、共有コラボレーション知識を保管する中央統合リポジトリおよび中央統合ディレクトリが含まれる。XI・110は、拡張可能マークアップ言語(XML)、ウェブサービス記述言語(WSDL)、およびシンプルオブジェクトアクセスプロトコル(SOAP)などの様々な標準マークアップ言語などのオープンな標準規格をサポートして、コンポーネント102、104および異種コンポーネントインタフェースにまたがるメッセージに基づく通信の技術的に抽象化されたインタフェースを提供する。XI・110の自己完結的なモジュール化された機能は、標準インターネットテクノロジに基づく1つまたは複数のウェブサービスとして提供することができ、したがって、オープンな標準規格を使用してコンポーネント102、104のネットワーク内で公開し、発見し、アクセスすることができる。
【００１４】
図２に、アプリケーション間のメッセージに基づくコラボレーションを容易にするためのXI・110を含むシステム環境200を示す。交換基盤110には、統合リポジトリ202、統合ディレクトリ204、システム環境ディレクトリ203、および統合サーバ206が含まれる。統合リポジトリ202は、XI・110を介して通信できるすべてのソフトウェアコンポーネントの設計時のコラボレーション記述を取り込む。統合ディレクトリ204は、実行時のシステム環境200の構成に固有なコラボレーション記述を取り込み、これには、システム環境ディレクトリ203からの実際のコンポーネントインストレーションおよび外部コンポーネントに関する接続性記述へのアクセスが含まれ、これらのすべてが、システム環境200の共同ビジネスの意味規則を表す。統合サーバ206は、実行時に共同ビジネスの意味規則を使用して、アクティブなソフトウェアコンポーネントの間のメッセージに基づくコラボレーションを実行する。
【００１５】
統合サーバ206に、サービスを接続し、価値連鎖の処理フローを管理するために実行時にメッセージングおよびビジネスプロセス制御を提供するランタイムエンジン214が含まれる。BPMシステム299は、統合サーバ206上でランタイムエンジン214の下に常駐する。BPMシステム299には、ビジネスプロセス管理のランタイム実行のためにランタイムエンジン214の上で走行するビジネスプロセスエンジンまたは「プロセスエンジン」(図示せず)が含まれる。
【００１６】
統合サーバ206には、通常はアプリケーション固有の実装を必要とする統合サービス216も含まれる。統合リポジトリ202および統合ディレクトリ204と同様に、統合サーバ206は、既存システム基盤内での展開のために構成される。統合サーバ206は、ランタイムコラボレーション環境においてサポートされるシステム環境の統合ディレクトリ204の共有コラボレーション知識を適用する専用サーバであることが好ましい。ランタイムワークベンチ208は、組織またはユーザがXI・110の信頼できる動作を管理できるようにする。
【００１７】
XI・110には、統合サーバ206と、固有(proprietary)アプリケーション211、ウェブベースサービス213、およびサードパーティアプリケーション215との間の接続性を提供する様々なアダプタ209も含まれる。XI・110に、例えばJava(登録商標)およびABAPなどのウェブ固有プログラミング言語を使用する標準コンピューティングプラットフォームに従ってプログラムされたウェブベースアプリケーションを提供するウェブアプリケーションサーバ210も含めることができる。ウェブアプリケーションサーバ210に、Java(登録商標)アプリケーション220およびABAPアプリケーション222などのウェブアプリケーションおよび他のコンポーネントの間のメッセージングおよびビジネスプロセス制御を提供するランタイムエンジン214の実体も含まれる。
【００１８】
ソフトウェアコンポーネント用の新しいインタフェースを、プロキシを使用するアプリケーションコンポーネントを使用して定義することができ、このプロキシは、ソフトウェアコンポーネント用のインタフェースをXI・110内でローカルに実装することを可能にする。プロキシは、通信技術スタックをアプリケーションに透過的にし、アプリケーションにプログラミング言語依存インタフェースを提示する。プロキシは、統合リポジトリ202に保管された情報に基づいて、プロキシジェネレータ218によって生成することができる。プロキシジェネレータ218は、WSDLおよびXSDLなどの標準ウェブベース言語を用いて記述されたインタフェース情報を使用して、アプリケーション開発システム内でプラットフォーム依存およびプログラミング言語依存のコードを作成する。通信ロジックは、ウェブベースアプリケーション213用の、Java(登録商標)、ABAP、および.NETなどそれぞれの開発プラットフォームのインタフェース記述を表すプロキシに基づいて実装することができる。プロキシは、プラットフォーム固有データ型をXMLに変換し、コンポーネント固有ローカル統合エンジンへのアクセスを提供する。アウトバウンド側で、プロキシが完全に生成される。アウトバウンドプロキシは、アプリケーションの開発者によって提供されるサービス呼出しを介して呼び出すことができる。インバウンド側では、受信するアプリケーションによって実装される、プロキシの骨組み(skelton)だけを生成する必要がある。
【００１９】
図３に、統合リポジトリ202、システム環境ディレクトリ203、統合ディレクトリ204、およびランタイムエンジン214の実体化を詳細に示す。統合リポジトリ202に、設計時のビジネスプロセス232、ルーティングオブジェクト234、マッピング236、およびインタフェース238が含まれ、これらのすべてが、1つまたは複数のビジネスシナリオ230に従って定義されている。統合リポジトリ202は、システム環境ディレクトリ203から、システム環境内のすべてのソフトウェアコンポーネント240の記述にアクセスする。統合リポジトリ202のビジネスシナリオ230は、アプリケーションコンポーネントまたは企業の間のメッセージ交換を記述し、構成する。企業は、XI・110の迅速な構成のための最良の実現として、統合リポジトリ202内で記述された1つまたは複数のビジネスシナリオを選択することができる。
【００２０】
ビジネスプロセス232は、ビジネスプロセスエンジン274を使用して実行される拡張可能複合ウェブサービスとして実現することができる。各ビジネスプロセス232は、統合リポジトリ202内で集中的にモデル化される。企業またはユーザは、そのビジネスの必要性に従って、技術的な実装と独立に、各ビジネスプロセス232を設計する。ビジネスプロセステンプレートの複数のカテゴリすなわち、例えば包括的ビジネスプロセス、業界固有プロセス、および企業固有プロセスを設けることができる。各プロセスは、必要であり、相互接続されなければならないウェブサービスを識別する。1つの具体的な実装で、ビジネスプロセス232は、グラフィカルインタフェースを使用して定義される。グラフィカルビジネスプロセス定義言語は、BPEL4WS 1.1仕様に従って定義される。ビジネスプロセス232は、標準フォーマット(これは、現在はBPEL4WS 1.1仕様である)にエクスポートし、標準フォーマットからインポートすることができる。拡張可能なインポート/エクスポートフレームワークが、他の標準規格またはBPEL4WSの新しいバージョン用のエクスポート/エクスポート機能を提供することを可能にする。ビジネスプロセスエンジン274は、これらのモデルを解釈し、実行して、ソフトウェアコンポーネントの間のコラボレーションを実行することができる。
【００２１】
ルーティングオブジェクト234は、共同処理中にコンポーネントとビジネスパートナの間で配送しなければならないメッセージの潜在的な受信側を判定する予め定義された判断基準である。ルーティングオブジェクトに関する情報は、配送の前に完全なメッセージを処理する必要を避けるための受信側判定に使用される。マッピング236は、メッセージインタフェース238、メッセージタイプ、または統合リポジトリ202内のデータ型の間の必要な変換を定義する。これらの変換は、構造的変換と値マッピングを含む。構造的変換は、構文的または構造的に異なる意味規則的に同等の型に使用され、値マッピングは、オブジェクトが複数のシステムで異なるキーによって識別されるときに使用することができる。特定の実装で、グラフィカルマッピングツールが、マッピングを助けるために提供され、データの変換は、XSLT(XMLスタイルシート言語変換)またはJava(登録商標)コードに基づく。
【００２２】
統合リポジトリ202は、インタフェース開発、ストレージ、および検索の中央エントリポイントであり、システム環境内のすべてのソフトウェアコンポーネントのすべてのメッセージインタフェースを記述するインタフェース238を含む。したがって、インタフェース238は、任意の技術を使用して、任意のソフトウェアコンポーネントで実施することができる。メッセージインタフェースは、メッセージ型からなり、このメッセージ型は、データ型からなる。データ型は、XSDL(XMLスキーマ定義言語)を使用して記述することができる。データ型の例は「アドレス」であり、これは、メッセージ型「POを作成する」で使用され、メッセージ型「送り状を作成する」について再利用することができる。インタフェース238は、インバウンド、アウトバウンド、および抽象または同期および非同期など、任意の分類に従って配置することができる。
【００２３】
コンポーネント240は、アプリケーションコンポーネントに関する情報ならびにお互いに対するその依存性に関する情報を含むコンポーネント記述を表す。特定の実装で、コンポーネント記述は、分散管理タスクフォース(Distributed Management Taskforce)の標準である共通情報モデル(CIM;Common Information Model)に基づく。統合リポジトリ202に、設計時の情報が含まれるので、実際のインストレーションと独立なコンポーネント型情報だけが、システム環境ディレクトリ203にコンポーネント240として保管される。コンポーネント記述は、APIを使用して、またはグラフィカルユーザインタフェースを使用して対話的に追加することができる。
【００２４】
統合ディレクトリ204は、システムにインストールされている各コンポーネントの構成に固有の、統合リポジトリ202からの情報の詳細を示す。統合ディレクトリ204の構成に固有なコラボレーション記述は、統合リポジトリ202内の内容から自動的に作成するか、グラフィカルユーザインタフェースを使用してユーザが手動で作成することができる。1つの実装において、統合ディレクトリ204は、Java(登録商標)プラットフォーム上で作られ、その内容は、オープンなインターネット標準規格を使用してXMLを用いて表現される。統合リポジトリ202は、統合ディレクトリ204またはすべてのランタイム共同プロセスに影響せずにアップグレードすることができる。その場合に、ユーザは、所定の自動アップグレードとしてまたはグラフィカルツールを介して手動で、統合ディレクトリ204に転送しなければならない変更を判断する。
【００２５】
統合ディレクトリ204には、ビジネスシナリオ250、ビジネスプロセス252、コンテキストオブジェクト254、および実行可能なマッピング256の構成に固有な記述が含まれる。統合ディレクトリ204には、アクティブなウェブサービス258およびアクティブなビジネスパートナ260の記述も含まれる。統合ディレクトリ204は、システム環境ディレクトリ203からのアクティブなシステム環境262の記述を使用する。統合ディレクトリ204内のビジネスシナリオ250は、特定の実装に関連する実際の構成のコンテキストでのインタフェースおよびマッピング256の間の交信の全体的なビューを表す。ビジネスプロセス252は、すべてのアクティブなビジネスプロセスの実行可能な記述を表す。
【００２６】
コンテキストオブジェクト254は、ビジネスレベルでのメッセージの受信側を決定する。一実施形態において、メッセージの内容が、コンテキストオブジェクト254として使用される。他のパラメータも使用することができる。関連する入力パラメータに、送信側、送信側メッセージ型、受信側を識別するメッセージ、および受信側メッセージ型が含まれる。コンテキストオブジェクト254は、XMLパス言語(XPath)を使用して(すなわち、グラフィカルツールを使用して)宣言的に記述するか、Java(登録商標)でコーディングすることができる。統合エンジン214は、実行時に、コンテキストオブジェクト254の情報にアクセスする。
【００２７】
コンテキストオブジェクト254は、統合ディレクトリ204で記述されたウェブサービス258によって提供される物理アドレスから送信側および受信側を分離するために、送信側および受信側を記述するのに論理項(logical term)を使用することができる。したがって、物理アドレスを、ビジネス指向内容を変更せずに変更することができる。統合ディレクトリ204内のマッピング256は、すべてのサポートされるマッピングを含む統合リポジトリマッピング236と対照的に、アクティブなシステム環境に必要なマッピングを表す。しかし、マッピングの新しいシーケンスなどの一部の新しいエントリは、例えばマッピングに関する追加ウェブサービスのアドレッシングのために、統合ディレクトリ204内でのみ作ることができる。統合エンジン214は、実行時に統合ディレクトリマッピング256にアクセスする。
【００２８】
コンテキストオブジェクト254は、意味規則的に同一のペイロード情報にアクセスするための一意の名前を提供する。例えば、コンテキストオブジェクトは、送り状および購入注文に関して「plant」の一意のアクセス名を提供することができる。送り状の「plant」のXPathを、「A/B/C/plant」と定義することができ、購入注文の「plant」のXPathは、「X/Y/Z/werk」のようになる。コンテキストオブジェクト254の「plant」は、上述したXPathが指定されたメッセージインタフェースの送り状および購入注文に割り当てられる。これによって、plantのXPathがn個の異なる場所で定義されていないことが確かめられる。
【００２９】
ウェブサービス258は、現在アクティブなシステム環境内で実装されたインタフェースならびに記述されたビジネスパートナ260によってサポートされるアクティブなウェブサービスを記述する。したがって、ウェブサービス258を記述した情報を、UDDI(Universal Description,Discovery,and Integration)互換のディレクトリと交換するか、手動で追加することができる。各ウェブサービス258の記述は、物理アドレッシングの詳細と、アクセス情報と、URL(uniform resource locator)、プロトコル、およびセキュリティ情報などの他の特殊な属性も提供する。1つの実装で、ウェブサービス258が、WSDLで記述され、SOAPおよびebXMLが、メッセージングプロトコルとして使用される。統合エンジン214も、実行時にウェブサービス258に関する情報にアクセスする。
【００３０】
システム環境ディレクトリ203のシステム環境262は、XI・110を使用する現在のシステム環境を記述する。システム環境262は、システム内のあるマシンにインストールされ、使用可能であるコンポーネント、選択された実体またはクライアント、インストールされたコンポーネントに関するさらなる情報、他のシステム環境などを記述する。システム環境262の記述は、オープンアーキテクチャに基づき、共通情報モデル(CIM)などの広く受け入れられている標準規格を厳守することができる。したがって、多数の固有(proprietary)コンポーネントおよびサードパーティコンポーネントを、実際のシステム環境にインストールされるときにシステム環境262にそれ自体を自動的に登録するように構成することができる。システム環境262の記述へのアクセスインタフェースも、WBEM(Web-based Enterprise Management)およびSOAP標準規格などのオープンな標準規格に基づくものとすることができる。
【００３１】
ビジネスパートナ260は、名前、住所、およびURLなどの企業のビジネスパートナに関する情報を定義するが、より詳細な洗練された情報も含めることができる。例えば、ビジネスパートナ260に、直接に受信し、処理することのできるメッセージフォーマットの記述、あるいは安全な通信に使用されるセキュリティプロトコルまたはパートナシップで使用される取引条件の記述を含めることができる。ビジネスパートナ260に保管される情報の種類は、XI・110を使用する企業の固有な判断によって制御することができる。
【００３２】
統合ディレクトリ204およびランタイムエンジン214は、共同ビジネスプロセスを実行するための共同ランタイム環境を形成する。共同ランタイム環境は、接続されたソフトウェアコンポーネントおよびビジネスパートナの間でのメッセージ交換に関連するすべてのランタイムコンポーネントを提供する。統合サーバ206は、共同ランタイム環境またはウェブアプリケーションサーバ210を実行し、このいずれかに、統合ディレクトリ204によって提供される情報リソースに従ってランタイムエンジン214の実体を含めることができる。
【００３３】
様々な相互接続されたコンポーネントの間ですべてのメッセージを交換するランタイムエンジン214には、2つの層すなわち、統合層272と、メッセージングおよびトランスポート層(MTL)280とが含まれる。統合層272には、中央でモデル化されたビジネスプロセスを実行するビジネスプロセスエンジン274、論理ルーティングサービス276、およびマッピングサービス278が含まれる。MTL・280は、物理アドレス解決サービス282、メッセージングおよびキューイングサービス284、HTTPを介するトランスポートサービス286、およびデータベース288を提供する。統合サーバ206内の統合サービス216は、ランタイムエンジン214をサポートすることができる。MTL・280は、ウェブアプリケーションサーバ210内のランタイムエンジン214の各実体内ならびに様々なソフトウェアコンポーネントに接続されるアダプタフレームワークの各アダプタ209内にも含まれる。各MTL・280は、以下でさらに説明するように、EOプロトコルの実行で役割を有する。
【００３４】
実行時に、ビジネスプロセス252が、実体化され、ビジネスプロセスエンジン274によって実行され、ビジネスプロセスエンジン274は、ビジネスプロセスモデルに従って、ウェブサービス258で記述されたそれぞれのウェブサービスを、その位置と独立に実行する。ビジネスプロセスエンジン274は、実行されるビジネスプロセス252の意味規則と独立であり、ランタイムシステム環境の技術的なコンポーネントと交信するためにビジネスプロセス252を仲介し、容易にするものとして構成される。
【００３５】
図４は、アプリケーションの間でメッセージを交換する処理でのランタイムエンジン214およびBPM・299の複数の機能を示すブロック図である。送信側アプリケーション303が、送信側コンポーネントシステム302に常駐し、送信側コンポーネントシステム302は、送信側アプリケーション303のハードウェアおよびソフトウェアのプラットフォームを表す。1つまたは複数の受信側アプリケーション305が、それぞれ受信側コンポーネントシステム304に常駐する。メッセージ310の通信経路には、送信側コンポーネントシステム302からランタイムエンジン214およびアダプタ309を介して受信側コンポーネントシステム304へのアウトバウンドインタフェースにおいてアウトバウンドプロキシ307を含めることができる。受信側コンポーネントシステム304は、アダプタではなくインバウンドプロキシ311を使用することもできる。図示の受信側コンポーネントシステム304の構成および接続性は、単に例示であり、そのような構成および接続性が、任意の個数の形をとることができることに留意されたい。図示の例は、非同期と同期の両方の通信を例示するものである。同期通信では、ルーティングおよび物理アドレス解決が、要求に関してのみ必要である。というのは、応答が、既に知られている送信側に転送されるからである。
【００３６】
所与のメッセージについて、論理ルーティングサービス276は、312に示されているように、送信側アプリケーションおよびメッセージインタフェースの情報を使用して、対応するルーティング規則を評価することによって、受信側および必要なインタフェースを判定する。ルーティング規則は、統合ディレクトリ204によって提供されるランタイムシステム環境の構成に固有な記述の一部であり、XPath表現またはJava(登録商標)コードとして実装することができる。マッピングサービス278は、314で、メッセージ、送信側、および送信側インタフェースならびに受信側および受信側インタフェースに依存する必要な変換を判定する。非同期通信の場合に、メッセージ方向さえもが、入力、出力、およびフォールトメッセージを適切に変換するために判定される。
【００３７】
統合ディレクトリ204から必要なマッピングを取得した後に、マッピングサービス278は、送信されるメッセージの内容に対してXSLTマッピングまたはJava(登録商標)コード(あるいは所与のシーケンスでの任意の組合せ)のいずれかを実行することができる。統合層の下で、メッセージング、キューイング、およびトランスポートサービス284が、メッセージを所期の受信側または必要な受信側に転送する。メッセージが、各受信側によって期待されるフォーマットに変換された後に、316で、必要な受信側サービスの物理アドレスおよび他の関連属性が、統合ディレクトリ204から取得され、メッセージにマッピングされる。
【００３８】
メッセージングおよびキューイングサービス284内のキューイングエンジン(図示せず)が、入ってくるメッセージ、出てゆくメッセージ、エラーのあるメッセージ、および作業中(work-in-progress)のメッセージを永続的に保管する。ランタイムエンジン214のメッセージング層は、アプリケーションコンポーネントを物理的に切断するキューイング機能を提供し、メッセージがプロトコルに従って正確に1回だけ(Exactly Once)配信される(すなわち「EO」プロトコル)ことを保証する。トランスポートサービス286は、ランタイムエンジン214がクライアントとサーバの両方として動作することを可能にする。トランスポートサービス286は、アウトバウンド通信を可能にするクライアントおよび入ってくるドキュメントを受け入れることによってインバウンド通信を処理するサーバを実装する。追加サーバ機能は、使用されるトランスポートプロトコルを介してポーリングをサポートすることによって、受信側がサーバを有しない状況に対処することができる。好ましくはHTTPが使用されるが、他のトランスポートプロトコルも使用することができる。
【００３９】
図５は、統合サーバ502に統合されたプロセスエンジン504を含むBPMシステム500のアーキテクチャブロック図である。プロセスエンジン504および統合サーバ502は、そのランタイム構成でこのように呼ばれるが、その「定義時」の構成では、それぞれ、プロセスエディタおよび統合ビルダとも呼ばれる。BPMシステム500内のプロセス定義506およびBPMランタイム508は、異なる開発プラットフォームに基づく。例えば、プロセス定義506は、J2EEプラットフォーム505など、Java(登録商標)に基づき、ランタイム508は、ABAPに基づく。BPMシステム500に、統合サーバ502上の監視および管理ツール524が含まれる。
【００４０】
プロセス定義506のモジュールは、XMLオブジェクトおよび相関関係を使用して、統合ディレクトリ514のXIオブジェクト512からインポートされた展開ルールに基づいて、プロセスを定義する。XIオブジェクト512は、システムランタイム構成516について定義されたルーティングおよびマッピングに基づく。XIオブジェクト512は、統合リポジトリ522内のビジネスプロセス518およびシステム環境の設計時の構成520を定義するのにも使用される。ビジネスプロセス518は、他のすべての統合リポジトリ522のオブジェクトおよびツールと統合され、これによって、他のXIオブジェクトとの間のリンクが可能になる。プロセス(すなわち、パターンおよびテンプレート)を顧客に配信することができ、エクステンションの概念を提供することができる。アプリケーション固有の内容も、配信することができる。一部のアプリケーションは、顧客に配信できるプロセスおよび/またはエクステンションを作成することができる。BPMシステム500に、普遍的な接続性のための標準規格ベースアダプタをインポートし、エクスポートするインポート/エクスポートフレームワーク526が含まれる。BPMシステム500に、ユーザ指定のビジネスプロセス詳細を受信するインタフェースを含めることができる。
【００４１】
ビジネスプロセスモデル化シナリオを、モデル化パターン(または単に「パターン」)とも称する。以下で説明するパターンは、高水準の基本構成要素であり、デッドライン、例外などのプロセスエンジン504の基本機能と互いに組み合わせることができる。
【００４２】
1)送信および受信:プロセスエンジン504によって制御されるメッセージ送信は、しばしば、相関関係のある応答メッセージを待つそれぞれの受信ステップと組み合わされる。受信ステップは、キューイング機構としての関連する相関関係のアクティブ化から始めて、メッセージを待たなければならない。
【００４３】
2)シリアライゼーション:このパターンには、1.メッセージを受信し、プロセスデータコンテキスト内でローカルに保管するステップと、2.データコンテキストを保持し、ある条件が満足されたときに受信したメッセージの送信を開始するステップと、3.受信側の従属関係を考慮して、所定の順序で、受信したメッセージを送信するステップとを含めることができる。この第3ステップは、a.応答/肯定応答に関係なく(「撃ち放し(fire and forget)」)またはb.応答もしくは肯定応答を受信する(直列化を可能にする)ことができる。プロセスエンジン504は、次のメッセージを送信する前に、以前に送信されたメッセージの技術的なACKまたはそのメッセージからのビジネス応答を待つように構成することができる。
【００４４】
3)変換/結合/分割:プロセスエンジン504は、プロセスコンテキスト内でメッセージを変換する。次の変換を実行することができる:1.(N:1)複数の収集されたメッセージを1つの新しいメッセージに変換する(例えば、複数の送り状を1つの組み合わされた送り状に変換するか、POヘッダおよび複数のPOポジションを1つのPOに変換する);2.(1:N)1つのメッセージを複数の他のメッセージに変換する(例えば、組み合わされた送り状をオリジナルPOに関する送り状に変換する);3.(1:1)は、上記で説明した変換の特殊な事例である。必要な場合に、N:Mマッピングも可能である。
【００４５】
4)マルチキャスト:プロセスエンジン504は、応答/肯定応答に関係なく(「撃ち放し」)または複数の応答/肯定応答の受信に基づいて、メッセージの受信側を判断し(内容ベースの条件も使用して)、メッセージをこれらの受信側に送信するように構成することができる。メッセージは、並列にまたは順次送信することができる。
【００４６】
5)収集:このパターンは、任意の個数のメッセージを受信することができる受信ステップを使用する。プロセスの観点から、収集シナリオの終りは、「プッシュ」(すなわち、N個のメッセージが到着した、あるデッドラインに達したなど、ある条件に達した)または、プロセスエンジンが、収集の終りを示す特殊なメッセージを待つ「ポール」を介して定義することができる。
【００４７】
図５も参照して、図６に、複数の「クライアント」アプリケーションシステムを編成する、BPMシステム500のランタイムおよび統合サーバ502のそれぞれのプロセスエンジンのワークフロー600を示す。統合サーバ502は、メッセージを介してクライアントアプリケーションシステム503と通信する独立コンポーネントである。メッセージ関連機能(送信、作成、変換、結合、分割など)は、統合サーバ502のメッセージング層(「低水準XIランタイム関数」)へのサービス呼出しによって実現されることが好ましい。プロセスエンジン504は、メッセージペイロードを直接に変更しないことが好ましい。むしろ、メッセージは変換によって変更され、この変換を以下でさらに説明する。
【００４８】
プロセスエンジン504は、アプリケーションシステム503上ではなく、統合サーバ502上のプロセスだけに焦点を合わせている。プロセスエンジン504は、バックエンドシステム内のプロセスの制御に使用されるのではなく、メッセージを介してバックエンドプロセスと通信することができるが、プロセスエンジン504は、バックエンドシステムのアプリケーション機能、組織管理機能、およびユーザ管理機能と交信しない。プロセスエンジン504は、メッセージング層アプリケーションを使用するが、ビジネスワークフローは、それぞれのアプリケーションシステムのアプリケーション、ユーザ管理、および組織管理を使用する。プロセスエンジン504は、同期アウトバウンドインタフェースを介して通信をサポートする。
【００４９】
ビジネスプロセス管理
XI環境へのプロセス管理の統合は、2つの部分すなわち、1)ビジネスプロセスとの間のすべての参照を取り扱う「外部ビュー」と、2)プロセスおよびモデル化ツールを探索する「内部ビュー」とで説明することができる。
【００５０】
外部ビュー
プロセスは、統合リポジトリ522と統合ディレクトリ514との両方に内部表現(representation)を有する。プロセス定義は、作成され、統合リポジトリ522だけに保管される。これによって、クライアントシステム503へのプロセス定義のトランスポートが可能になる。統合ディレクトリ514に保管されたプロセスは、簡略な内部表現に依存し、この内部表現は、統合リポジトリ522内の関連するプロセス定義を指し示す。各ビジネスプロセスは、XIオブジェクト(ナビゲーションツリーにおいて視覚的に表現され、他のXIオブジェクトとの間のリンクにおいて使用可能である)として、XI環境内でプロセスエンジン504を統合する機能を提供する。ビジネスプロセス518は、確立されたXIオブジェクト型を使用することができ、冗長なオブジェクト型を作成しない。ビジネスプロセス518に、前に使用されたインタフェースなどのパブリック部分と、ステップ型および相関関係を使用するプロセスグラフを含むプライベート部分が含まれる。プロセス実体は、ランタイム508内で停止し、再始動することができる。プロセス実体は、特定のステップから再始動する(例えば、あるステップ中にエラーが発生した場合に、そのステップから再始動する)こともできる。
【００５１】
図７に、統合リポジトリ522内のビジネスプロセス518との間のリンクを示す。このリンクには、(2)抽象化されたインタフェース702、(3)コンテキストオブジェクト704、および(4)インタフェースマッピング706への参照が含まれる。絶対的なリンクは、(1)ビジネスシナリオのアクションがプロセス定義を参照すること、(5)インタフェースマッピング706がメッセージマッピング712を参照することを含む。ビジネスプロセス518は、ビジネスシナリオ720内で使用でき、ビジネスシステム間の仲介者として動作する。
【００５２】
ビジネスプロセス518は、すべてのインバウンド通信およびアウトバウンド通信を反映するプロセスインタフェース708を有する。プロセスインタフェース708内で使用されるインタフェースに、2つのタイプすなわち、プロセス固有インタフェース(プロセス用の特殊な正規化インタフェース)および(不要なインタフェースの作成を避けるための)送信側/受信側ビジネスシステムのミラーリングされたアウトバウンド/インバウンドインタフェースが含まれる。ミラーリングを行って、オリジナルインタフェースと同一のメッセージ型をポイントする新しい抽象インタフェース702を作成しなければならない。抽象インタフェース702は、インバウンドの役割ならびにアウトバウンドの役割に使用することができる。これによって、プロセスが受信し、後に変更なし(変換なし)で送信するメッセージに関するマッピングが不要であることが保証される。プロセスがインバウンドメッセージおよびアウトバウンドメッセージを必要とする場合には、インバウンドからアウトバウンドへの変換が必要になる。さらに、プロセス固有インタフェースは、アタッチされたビジネスシステム内にプロキシを有する必要がない。これは、いわゆる抽象インタフェース702につながり、この抽象インタフェース702は、ビジネスプロセス518が使用できる唯一のタイプのインタフェースである。ローカルインタフェースは、(ミラーリングを処理するために)他のインタフェース708を参照でき、(プロセス固有インタフェースを実現するために)メッセージ型710を参照することもできる。
【００５３】
コンテキストオブジェクト704は、名前または他のメッセージ内容を介してペイロード情報にアクセスするのに使用することができる。データを、コンテキストオブジェクト704に書き込まないことができる。インタフェースマッピング706は、変換ステップ内でビジネスプロセス518によってアドレッシングされる。
【００５４】
ビジネスシナリオ720は、1つまたは複数のビジネスプロセス518を参照することができる。1つのビジネスプロセスが、1つの「スイムレーン(swim lane)」すなわちプロセスフローを占有する。各プロセスは、ビジネスシステムとして扱われる。プロセススイムレーン内のアクションは、再利用可能な別々のアクションとしては保管されない。アクションは、アウトバウンドインタフェースまたはインバウンドインタフェース(あるいはその両方)としてビジネスプロセス518によって使用されるインタフェースを表す。「普通の」シナリオの場合に、アクションのインタフェースの一部が、接続のターゲットまたはソースでない場合がある。ビジネスプロセスの場合に、各アクションは、インバウンドおよび/またはアウトバウンドの意味規則を有する1つのインタフェースを表し、接続でターゲットおよび/またはソースとして使用されなければならない。ビジネスシナリオ720からビジネスプロセス518へのナビゲーションが提供される。
【００５５】
図８に、単純なシリアライゼーションユースケースを示す。O*は、アウトバウンドインタフェースを表す。I*は、インバウンドインタフェースを表す。L*は、ローカルインタフェースを表す。インタフェースL2およびL4のメッセージは、ビジネスプロセス(それぞれが、まず到着し、プロセスを開始することができる)によって受信され、シーケンシャルな順序で送信される。各アクションは、インバウンドインタフェース(受信)およびアウトバウンドインタフェース(送信)としてビジネスプロセスによって使用される1つのインタフェースを表す。したがって、各アクションは、アクションへおよびアクションからという2つの接続を有する。
【００５６】
図９に、基本結合シナリオを示す。インタフェースL2およびL4のメッセージは、ビジネスプロセス(それぞれがプロセスを開始することができる)によって受信され、インタフェースL5の新しいメッセージに変換され、このメッセージが送信される。インタフェースL2およびL4を表すアクションは、インバウンド(受信)接続だけを有し、インタフェースL5を表すアクションは、アウトバウンド接続(送信)だけを有する。
【００５７】
ビジネスシナリオに関して、ビジネスプロセスを異なる形でモデル化することができる。1つの形を、「プロセスファースト(process first)」またはボトムアップと呼び、これにはプロセス定義およびプロセスインタフェースの作成が含まれる。このプロセスシグネチャに、インバウンドの役割および/またはアウトバウンドの役割を有するインタフェースが含まれる。これらのインタフェースのメッセージは、プロセスによって受信/送信することができる。プロセスシグネチャは、プロセス定義およびコンテナ要素から導出することができ、プロセス設計者によって定義される必要はない。プロセスインタフェースのインバウンド部分は、所与のインタフェースのメッセージを受信する受信ステップ(すなわち、受信されなければならないコンテナ要素の型)に基づく。プロセスシグネチャのアウトバウンド部分は、所与のインタフェースのメッセージを送信する送信ステップ(すなわち、送信されるコンテナ要素の型)に基づく。この方法には、ビジネスシナリオにプロセス定義を導入することも含まれる。ビジネスシナリオ内で、アクションは、ビジネスプロセスのインタフェースを指す。
【００５８】
プロセスをモデル化できるもう1つの形を、「シナリオファースト(scenario first)」またはトップダウンと呼び、これには、次のステップが含まれる:1.ビジネスシナリオにスイムレーンとしてプロセス定義を導入し(存在しない場合には暗黙のうちにプロセス定義を作成する)、2.プロセスのスイムレーンにアクションを追加する(プロセスインタフェースを暗黙のうちに作成/編集する)。
【００５９】
図７に示されているように、統合リポジトリ522から統合ディレクトリ514への遷移は、できる限り苦労のないものにしなければならない。一実施形態で、統合ディレクトリ514内のプロセス732が、作成され、命名され、統合リポジトリ522内のアクティブなプロセス定義506にリンクされる。統合ディレクトリ514内の複数のプロセスに統合リポジトリ522内の同一のプロセスをポイントさせることも可能である。その後、他のすべての統合ディレクトリオブジェクトを、プロセス732にリンクすることができる。この遷移を簡単にするために、プロセス732を、ユーザインタフェースに表示されるユーザ構成可能な遷移「ウィザード」に含めることができる。
【００６０】
統合ディレクトリ514内のプロセス732に、簡略な(thin)表現が含まれ、このプロセスは、名前によって識別され、ビジネスシナリオ730へのルーティング関係734の依存性に起因して、ビジネスシナリオ730に含まれる。ディレクトリプロセス732に、それが発したリポジトリプロセス518(アクティブなバージョン)への参照(リンク)が含まれる。したがって、統合ディレクトリ514内のプロセス表現は、プロセス定義を含まない。したがって、統合ディレクトリ514でのプロセスのカスタマイズまたは構成は不要である。
【００６１】
統合ディレクトリ514内のプロセス732は、プロセス732との間のルーティング関係734およびマッピング関係736の指定を可能にする。これは、マッピング機能およびルーティング機能がソースまたはターゲットとしてプロセス732を認識することを必要とする(すなわち、ビジネスプロセスを、ビジネスシステムのようにアドレッシングすることができる)ことを意味する。統合ビルタインタフェース内で、プロセスまたはビジネスシステムがアドレッシングされるかどうかが可視でなければならない。プロセス732は、ルーティングでメッセージの送信側としても使用される。例えば、同一インタフェースのメッセージを異なる受信側に送信する2つの異なる送信ステップを、同一プロセス内で区別しなければならない。
【００６２】
ステートレスシナリオ(プロセスなし)からステートフルシナリオ(プロセスあり)への遷移は、できる限り滑らかにしなければならない。図１０に、ステートレス通信を示す。接続(ルーティング)O2からI2およびO4からI4は、直列化することができ、OおよびIは、使用されるインタフェースである。
【００６３】
図１１に、ステートフルシナリオを示す。ステートフルシナリオを作成するために、接続(ルーティング)O2からI2およびO4からI4を除去する必要がある。ローカルインタフェースL2(O2へのミラーリングされたインタフェース)およびL4(O4へのミラーリングされたインタフェース)ならびにプロセス定義を、作成する必要がある。次に、プロセススイムレーン(BP1)を、ビジネスシナリオに導入する必要がある。アクションを、プロセスインタフェースから引き継ぐことができ、プロセスとの間の接続(ルーティング)すなわちO2からL2およびL2からI2とO4からL4およびL4からI4を適合させなければならない。インタフェースO2とI2の間で使用されたマッピングは、インタフェースL2とI2の間で再利用することができる(L2がO2のミラーなので)。同一のことが、O4/L4およびI4にあてはまる。
【００６４】
このシステムに、ビジネスプロセスのグラフィカルモデル化用のグラフィカルプロセスモデル化ツールを含めることができる。グラフィカルプロセスモデル化ツールに、モデル化要素および基本モデル化パラダイムをグラフィカルに示すプロセスビルダグラフィカルユーザインタフェース(GUI)が含まれる。
【００６５】
各プロセスは、そのプロセス内で使用可能なデータを使用して実行される。このデータは、プロセスコンテナのエンティティであるコンテナ要素(変数)に保管される。コンテナ要素は、プロセスをモデル化するときに定義することができ、一意の名前および型を含めることができる。コンテナ要素は、マルチライン(すなわち、要素のテーブル)として定義することができる。コンテナ要素は、型に従ってグループ化することができる。そのような型の1つが、インタフェース(すなわち、プロセスによって処理されるメッセージに関する)である。もう1つのそのような型が、単純なXSD型(すなわち、プロセス制御データ、例えばカウンタなどに関する)である。受信側も、マルチキャストの必要に応じて、1つのデータ型として指定することができる。
【００６６】
プロセスインタフェースは、プロセスの(インタフェース)シグネチャを表す。これには、インバウンドの役割および/またはアウトバウンドの役割を有するインタフェースが含まれる。これらのインタフェースのメッセージは、プロセスによって受信/送信することができる。プロセスインタフェースは、プロセス定義およびコンテナ要素から導出することができる。プロセスインタフェースのインバウンド部分は、所与のインタフェースのメッセージを受信する受信ステップ(すなわち、受信しなければならないコンテナ要素の型)に基づく。プロセスインタフェースのアウトバウンド部分は、所与のインタフェースのメッセージを送信する送信ステップ(すなわち、送信されるコンテナ要素の型)に基づく。
【００６７】
プロセスに送信されるメッセージは、プロセス定義だけではなく、プロセスの正しい実体にも配信される必要がある。この「実体ルーティング」は、包括的に達成することができる。新しいプロセス実体の開始は、特別な事例である。プロセスによって処理されるメッセージは、疎結合される。同一プロセスによって処理されなければならないメッセージの依存性は、ビジネスデータに依存する。
【００６８】
相関関係は、これらの依存性を定義する手段である。相関関係の宣言的指定は、メッセージの宣言的特性に依存する。特性は、単に、メッセージ内のフィールドである。相関関係は、複数のフィールドを使用して定義することができる。相関関係トークン(すなわち、相関特性の値)の各メッセージ内での位置は、プロセス定義で宣言的に表すことができる。相関関係は、情報を保持する最初のメッセージが使用可能である限り、プロセス実体のスコープ内で実体化することができる。この実体化は、送信ステップおよび受信ステップによってモデル化される。
【００６９】
プロセスは、メッセージ到着のみによってトリガを与えることができる。アプリケーション呼出し、API、または人間の介入を介するプロセスの開始を、トリガを与えるメッセージを使用することにマッピングすることができる。トリガを与えるメッセージは、受信ステップで識別することができる。したがって、受信されるメッセージを、BPEL4WSと同様に、トリガを与えるメッセージとして宣言することができる。受信ステップにトリガを与えるものとして宣言できるように、このステップは、プロセスの初めに定義される必要がある。
【００７０】
受信ステップは、プロセスに送信されたメッセージを消費するのに使用される。各受信ステップは、複数の受信ステップが同一インタフェースのメッセージを待っている場合であっても、それ自体のメッセージを得る。メッセージがプロセスに送信され、受信ステップがまだ実体化されていない場合には、受信ステップに達するまで、プロセスエンジンがメッセージをキューイングする。
【００７１】
上記で説明したように、メッセージは、プロセスに送信される。受信ステップがメッセージを消費しない場合には、プロセスが、到着するメッセージをキャッシングする。受信ステップに達した場合に、「最も古い」メッセージがキャッシュから取得され、受信ステップが完了する。プロセスが受信ステップに達し、キャッシュが空である場合には、そのプロセスは、新しいメッセージが到着するまで待つ。BPMシステム内の各受信ステップの実体は、複数のイベント消費者が同一イベントの際に通知される古典的なイベントに基づく発行(publish)および承諾（subscribe）と異なり、それ自体のメッセージを得る。
【００７２】
受信ステップは、受信ステップを完了するために満足されなければならないすべての相関関係を参照する。複数の相関関係がある場合に、受信ステップ(および意味規則)を完了するために、すべての参照される相関関係が満足されなければならない。受信ステップは、受信されたメッセージの消費の際に実体化される必要がある相関関係も参照する。メッセージの到着は、新しいデータをプロセスに持ち込むことができる唯一の形である。
【００７３】
同一インタフェースのメッセージに関する複数の受信ステップを設けることができる。図１２に示されているように、少なくとも3つのシナリオすなわち、順番に、並列に、および繰り返して、を可能とすることができる。これらを、これから順番に説明する。
【００７４】
順番のシナリオでは、複数の受信ステップが、同一インタフェースのメッセージを待っている。メッセージは、異なる時点(t1およびt2)に到着し、受信ステップは、相関関係のアクティブ化のときから待機期間を開始する。意味規則は、次の通りである:各受信が、それ自体の(異なる)メッセージを得る;最初のメッセージは、最初の受信ステップを完了させ、第2のメッセージは、第2の受信ステップを完了させる;最初のメッセージは、両方(またはより多くの)受信ステップを完了させない。このアクションは、競合状態を回避し、メッセージが失われないことを保証する。
【００７５】
繰り返しのシナリオでは、受信ステップが、同一インタフェースのメッセージをループ内で待っている。メッセージ(同一インタフェースの)は、異なる時点(t1、t2、およびt3)に到着し、受信ステップは、相関関係のアクティブ化のときから待つ。意味規則は、次の通りである:受信ステップがメッセージを消費しない場合に、プロセスは、到着するすべてのメッセージをキャッシングする;受信ステップに達した場合に、「最も古い」メッセージがキャッシュから取得され、受信ステップが完了する;プロセスが受信ステップに達し、キャッシュが空である場合には、プロセスは、新しいメッセージが到着するまで待つ。そのような「ループ式受信」は、収集シナリオを実現するのに役立つ。
【００７６】
並列のシナリオは、2つの受信ステップが同一インタフェースの同一メッセージを並列に待っている状況を取り扱う。メッセージは、異なる時点(t1およびt2)に到着し、両方の受信ステップが、相関関係のアクティブ化のときから待つ。意味規則は、次の通りである:最初のメッセージは、両方の受信ステップを完了させない;各受信ステップは、それ自体のメッセージを得るが、順序は任意とすることができる。
【００７７】
受信のメッセージングおよびステップを説明したので、メッセージ送信および送信ステップをこれから説明する。送信ステップは、プロセス内で既に使用可能なメッセージを送信するのに使用される。送信ステップの実行によって、プロセスエンジンは、(アウトバウンド)メッセージを処理のためにパイプラインに提供する。送信されるメッセージの受信側は、ディレクトリ内のルーティング構成を介して、または受信側判定ステップと組み合わされたプロセス定義によって直接に、または応答すべき別のメッセージを使用して、判定するか指定することができる。
【００７８】
ルーティング構成がディレクトリから取得されるときに、プロセス名およびアウトバウンドインタフェースは、メッセージ内の送信側情報である。メッセージは、パイプラインに提供され、このパイプラインで、適切なルーティング関係が評価されて、ターゲットのインタフェースおよび受信側が判定される。コンテキストオブジェクトを使用して、図１３に示されているように、同一インタフェース上の異なる送信ステップの間で区別することができる。受信側がプロセス定義によって直接に指定されるときには、受信側(すなわち、ビジネスシステム)を、直接に入力するか、受信側判定ステップによって計算することができる。この場合に、パイプラインがルーティング構成の際に受信側をもう一度計算してはならない。
【００７９】
ルーティング構成(ディレクトリ)が使用される場合に、コンテキストオブジェクトは、プロセス内の異なる場所から同一インタフェースのメッセージを送信する送信ステップを区別する必要があり、例えば、送信ステップは、それぞれ、スイッチ要素の排他的な枝に置かれ、異なる受信側に送信する必要がある。コンテキスト情報がないと、送信ステップが同一プロセスの一部であり、同一インタフェース上で送信しているので、送信ステップを互いに区別することが不可能になる場合がある。ルーティングは、プロセス名とインタフェース名しか使用することができない。コンテキストオブジェクトは、送信ステップを介して追加コンテキスト情報をルーティングに提供することを可能にする。この情報を、ルーティング条件で使用し、ルーティング関係を真または偽に分類することができる。
【００８０】
非同期通信は、送信ステップのデフォルト動作である。メッセージは、パイプラインを使用して(応答またはフォールトメッセージを受信せずに)受信側に送信される。非同期通信について、肯定応答(非パイプライン/パイプラインによる肯定応答、技術的な肯定応答、アプリケーションによる肯定応答(デフォルト:肯定応答なし))を待つことが可能である。これらの肯定応答は、受信側の、ビジネスメッセージではなく(肯定または否定の) 技術的な応答である。肯定応答は、受信側(アダプタ、システムなど)がこれらの肯定応答を送信できる場合に限って受信することができる。
【００８１】
送信中のエラーは、プロセスレベルでは可視でない。したがって、送信ステップは、エラー状況を返さない。送信ステップは、メッセージをパイプラインに提供できるときに終了し、プロセスエンジンが、要求された肯定応答(要求された場合に)を受信する。再試行は、XIランタイムによって実現される(再試行回数は、CPAで定義することができる)。というのは、プロセスエンジンが、再試行を実行するように構成されていないからである。
【００８２】
送信ステップは、同期通信にも使用することができる。この場合に、送信ステップは、2つのメッセージを扱い、一方のメッセージは、送信され、もう1つのメッセージは、結果として受信される。同期通信を使用すると、呼出しが即座に結果を返すので、肯定応答を処理する必要がない。
【００８３】
プロセスエンジンは、送信ステップを介して肯定または否定の肯定応答を送信することもできる。呼出し側システムによって要求され、明示的に回答されていない肯定応答は、プロセスが正常に終了したときに満足される。
【００８４】
受信側判定ステップは、パイプラインの受信側判定を呼び出して、ルーティング情報を使用してメッセージの受信側を計算する。このステップは、受信側のリストを返す。受信側のリストは、プロセスによって制御されたマルチキャストを可能にする。送信ステップと同様に、受信側判定ステップは、ルーティング条件の評価に使用できるコンテキスト情報を供給する。
【００８５】
変換ステップは、メッセージを結合し(N:1);メッセージを分割し(1:N);1つのメッセージをあるインタフェースから別のインタフェースに変換する(特殊な事例としての1:1)ように構成される。変換ステップごとに、マッピングプログラム(インタフェースマッピング)と変換シナリオに参加するメッセージの両方を指定する必要がある場合がある。マッピングプログラムは、異なる変換事例を処理できる必要がある。メッセージの変換は、プロセスエンジンによって呼び出されるサービスによって行われる。変換サービスは、完全なメッセージ(ペイロード、アタッチメントなど)を処理できなければならない。
【００８６】
メッセージペイロードにリンクされたアタッチメント(例えば、アタッチメントとしてのカタログ参照ピクチャ)は、このサービスによって次のように扱われる必要がある。結合の場合に、図１４に示されているように、すべてのアタッチメントが収集され、結合されたメッセージにアタッチされる。アタッチメントは、メッセージペイロードによって参照される名前を保持する。すべてのアタッチメントが、一意の名前(例えば、GUID)を使用しなければならない。分割の場合に、大量のデータがトランスポートされる場合であっても、すべてのアタッチメントを、単純に複製し、作成されたメッセージにアタッチすることができる。したがって、変換ステップに、変換、結合、および分割の動作が含まれる。新しいメッセージを作成する動作は、変換ステップの特殊な事例である。
【００８７】
動作時に、変換ステップは、1つまたは複数のメッセージ(ペイロード以外)およびマッピングプログラムをインポートパラメータとして用いてXIランタイムのマッピングサービスを呼び出し、エクスポートパラメータとして1つまたは複数の新しいメッセージ(ペイロードだけではない)を受信する。変換ステップは、メッセージに対して動作し、したがって、他の値のソースまたはターゲット(例えば、単純なXSD型)が、使用されないことが好ましい。
【００８８】
値マッピングは、プロセス内では可能でない。というのは、値マッピングに必要な送信側および/または受信側の情報が、プロセス内で使用可能でなく、マッピングプログラムに提供できないからである。したがって、プロセスは、値に関する「正規化された」メッセージフォーマットを必要とする。図１５に示されているように、プロセスへの値マッピングは、プロセス正規化された値フォーマットとして送信側ビジネスシステムA(BSA)の値を選択する。しかし、プロセスがメッセージを受信するか送信するときには、値マッピングが可能である。
【００８９】
制御フローに関連するモデリング要素またはステップに、スイッチ、割当、制御、ブロック、並列セクション、ループ、待機、空、例外、およびデッドラインが含まれる。スイッチは、複数の分岐を提供し、各分岐が、条件と評価の明示的順序とを備える。条件が真を返す最初の分岐が、実行時に採用される。他のすべての分岐は、無視される。分岐が一致しない(すなわち、すべての分岐条件が偽を返す)場合に、デフォルト分岐が採用される。割当ステップは、コンテナ要素の値を変更する(すなわち、トップレベルアクセス)。メッセージ(ペイロード、ヘッダなど)は、この動作によって変更することができない。ペイロードを変更するためには、変換ステップを実行しなければならない。メッセージペイロードには、XPath、コンテキストオブジェクト、または他の類似する手段を介してアクセスすることができる。
【００９０】
制御ステップは、制御フローに影響する複数の異なる機能、例えば例外の送信またはプロセスの終了を提供する。制御ステップは、異なる機能のために特殊化されたステップ型である。制御ステップに、例外送信機能および/または取消/終了機能を含めることができる。フォールト状況では、例外ハンドラによって処理される例外を送信できなければならない。送信された例外は、一意の例外名によって識別することができる。フォールト状況では、ある点でユーザを関係させることができなければならない。制御ステップのこの実装は、SAPの警告管理(Alert Management)にアラートを送信する可能性を提供する。
【００９１】
取消/終了機能性は、フォールト処理および補償動作なしで、プロセスおよびすべての参加するステップを終了することを可能にする。明示的な取消機能性と暗黙の取消機能性を区別することができる。制御ステップの明示的な取消機能性は、あるプロセス状態(受信されたメッセージまたはデッドライン)のときにプロセス全体を終了させる。このステップを処理することによって、プロセスが停止し、プロセス実体それ自体ならびにアクティブステップが終了される。
【００９２】
図１７に示されているように、暗黙の取消機能性は、プロセス内でモデル化されるのではなく、プロセスエンジンの特徴である。明示的な終了と比較して、暗黙の事例は、プロセス全体に影響するのではなく、プロセスのある部分(例えば、1つまたは複数のフォーク分岐)だけに影響する。暗黙の取消機能性の1つの例が、第1の分岐が合流ステップ(2つのうちの1つ)で並列セクションを完了する、2つの分岐を有する並列セクションである。したがって、一方の分岐が合流ステップに達し、合流条件が真である場合に、他方の分岐は、暗黙のうちに取り消される必要がある。t1において、両方の分岐がアクティブであると仮定する。t2において、一方の分岐が合流ステップに達し、他方の分岐はまだ処理中である。t3において、他方の分岐が取り消され(第1の分岐について合流条件が真であった)、プロセスは、合流ステップの後から継続される。明示的取消と同様に、補償は提供されない。分岐は、さらなる通知なしで暗黙のうちに取り消される。最終的にオープンされている通信を、合流条件を定義するときに考慮しなければならない。
【００９３】
ブロック(BPELでは「スコープ」、BPMLでは「シーケンス」と呼ぶ)を設けて、コンテナ定義を共有できる、順次実行されるステップのコレクションを定義することができる。これによって、ドキュメント化の目的も満たされる。ブロックを使用して、複数のステップを含むデッドラインを定義し、例外およびその範囲を定義することができる。デッドラインおよび例外は、ブロックについて定義されるので、ブロックでデッドラインハンドラおよび例外ハンドラを定義することも可能である。
【００９４】
例外は、上記で説明した制御ステップを使用して、またはシステムによって送信することができる。モデル化ツールは、例外ハンドラを定義する可能性を提供する。例外は、プロセスロジックがビジネスフォールトをシグナリングすることを可能にする。複数の異なる例外型に、プロセスロジックによって明示的に送信されるアプリケーション例外と、プロセスエンジンによって送信されるシステム例外が含まれる。例外は、ブロックレベルで定義することができる。ブロックは、その例外のスコープを表す。各ブロックは、任意の個数の例外を有することができる。各例外は、一意の名前を保持し、再定義することはできない。
【００９５】
例外は、一意の例外名を識別することによって、制御ステップ(throw例外)を介して送信することができる。例外ハンドラを、そのスコープ内の既存の例外について定義することができる。例外の送信は、次のように処理することができる。第1に、例外ハンドラを、例外名について見つける。throwコマンドを囲む内側ブロックをまず検索し、囲むブロック内で例外ハンドラを見つけられない場合には、次に上位のブロックに移り、例外ハンドラを見つけられない限りこれを繰り返す(例外伝搬)。第2に、例外ハンドラを保持するブロック内のすべてのアクティブステップを停止する。ハンドラが親ブロック内で見つかった場合には、すべてのアクティブステップと共に、このブロックを停止する。第3に、例外ハンドラを起動し、例外ハンドラ内のステップを実行する。第4に、例外ハンドラの終りに、ブロック(例外ハンドラがそこで定義されている)を、普通に完了する。例外をブロックの1つで処理できない場合には、そのプロセスはエラー状態になる。
【００９６】
デッドラインは、プロセスの期日を監視し、見過ごされたデッドラインの際に反応するために設けられている。モデル化ツールは、デッドラインハンドラをモデル化する可能性も提供する。デッドラインは、モデル化要素ブロックだけについて使用可能であり、他の要素は、デッドラインをサポートしない。これによって、ステップの組を監視できるようになり、競合状態が回避される。競合状態は、デッドラインが受信ステップまたは送信ステップだけにアタッチされ、ステップが実体化される前にデッドラインに達した場合に発生する可能性がある。
【００９７】
デッドラインには、デッドライン期日、デッドラインスコープ(いつデッドラインがアクティブ化され、かつ/または非アクティブ化されるか)、および見過ごされたデッドラインの際の反応の定義が含まれる。デッドライン定義は、週末、祝日などを顧慮しないようにプログラムすることができる。期日に達した場合に、ブロック内のすべてのステップを終了し、対応するデッドラインハンドラを起動するデッドライン例外が送信される。対応するデッドラインハンドラは、到達したデッドラインの際の反応をモデル化することができる。デフォルトデッドライン反応がなくてもよい。各ブロックは、1つのデッドラインだけを保持することができる。このデッドラインは、デッドライン例外として使用できる、それ自体の割り当てられた例外名を有しなければならない。デッドラインハンドラは、この例外について定義される。
【００９８】
デッドラインに、デッドライン定義(日時)および見逃されたデッドラインの際の反応が含まれる。システムは、プロセスアクティビティの実行に関する時間制約の定義をサポートする(例えば、プロセスは、ペイロード指定のデッドラインの3日前に停止しなければならない)。反応は、例えば条件が所与の時間枠内で満足されない場合に、適当なビジネスシステムへのメッセージの送信、および/または、例外状況に関するアラート機構(例えばSAPの警告管理(Alert Management)を用いたユーザ通知) を引き起こすことができる。
【００９９】
プロセスビルダは、2種類の並列セクションすなわち、静的変形および動的変形を提供するように構成されている。静的並列セクション(フォークおよび合流)は、任意の個数の分岐および同期化を有する並列セクションを提供し、この個数は、定義時に定義することができる。この並列セクションは、次の条件のときに終了する:特殊化された条件として、メッセージおよびコンテナ変数に対して操作する任意の条件として、「m個のうちのn個」の論理が設けられる(すべての論理は「n個のうちのn個」を使用して可能である)。両方の条件が、分岐が合流ステップに達したときに必ず検査される。1つの条件が真を返す場合に、他のすべてのアクティブ分岐が終了される。プロセスは、並列セクションの終りの直後の次のステップから継続される。
【０１００】
動的並列セクション(Par For Each)は、1つの定義された分岐および同期化を有する並列セクションを提供するブロックである。この分岐の並列実行の個数は、実行時に決定することができる。動的並列セクションは、マルチライン要素(テーブル)を割り当てられる。定義された分岐(ブロック)は、この要素のラインごとに並列に実行される。マルチライン要素が空である場合には、動的並列セクションは、即座に完了する。各分岐は、それ自体のアドレス空間を有する。動的並列セクションは、ある条件下で終了する:特殊化されたデフォルト条件として、メッセージおよびコンテナ変数に対して操作する任意の条件として、すべての分岐が完了しなければならない。両方の条件が、分岐がその終り(ブロックの終り)に達したときに必ず検査される。1つの条件が真を返す場合に、他のすべてのアクティブ分岐が終了される。プロセスは、並列セクションの終りの直後の次のステップから継続される。
【０１０１】
プロセスビルダは、異なる種類のループを提供することができる。ループの1つのタイプが、「while」ループである。whileループは、任意の条件が満足されるまで、ステップの組を繰り返す。ループのもう1つのタイプが、「For Each」ループである。For Eachは、マルチライン要素(テーブル)を割り当てられたブロックである。これは、所与のマルチライン要素についてループし、要素のラインごとに関連するステップを順番に(次々に)実行する。マルチライン要素が空の場合には、For Eachループは実行されない(すなわち、プロセスは、エラー状態にならない)。プロセスは、ブロックの終りの直後の次のステップから継続される。
【０１０２】
待機ステップは、あるデッドラインに達するかある期間の遅延が経過するまでの、プロセスフロー内の遅延を指定する。空の要素またはステップは、単に、何も実行せず、モデル化されるステップの位置設定記号(placeholder)として動作しなければならない。
【０１０３】
したがって、制御フローモデル化要素を説明したので、これからモデル化パターンを説明する。これらのパターンは、上述した要件を実装するプロセスを構成するのに使用される高水準の基本構成要素である。各パターンを、1つまたは複数の他のパターンと組み合わせることができ、デッドライン、例外などの基本的な(atomic)プロセスエンジン機能とも組み合わせることができる。モデル化パターンに、直列化メッセージ/シーケンス;変換/結合/分割;マルチキャスト;および収集が含まれる。
【０１０４】
直列化されるメッセージおよび/またはシーケンスについて、複数の受信ステップ(必要なすべてのステップをプロセスに取り込むための)および複数の送信ステップを、順序を保証する形で組み合わせることができる。送信ステップが、技術的な肯定応答を利用して、メッセージが実際に受信側システムにドロップされることを保証することが重要である。代替案では、もう1つの受信側ステップをモデル化して、対応するビジネス応答を得なければならない。したがって、そのようなパターンに、メッセージを受信するステップと;受信側の技術的な依存性に関する所与の順序で受信されたメッセージを送信するステップを含めることができる。後者のステップについて、次のメッセージを送信する前にメッセージの肯定応答を待ち;メッセージごとに1つの受信側をアドレッシングする。
【０１０５】
変換/結合/分割モデル化パターンには、(N:1)収集されたメッセージを1つの新しいメッセージに変換する(例えば、複数の送り状を1つの組み合わされた送り状に変換する);または(1:N)1つのメッセージを複数の他のメッセージに変換する(組み合わされた送り状をオリジナルのPOに関する送り状に変換する)が含まれる。マルチキャストモデル化パターンに、メッセージを受信するか変換を介して作成するステップと;受信側を得るステップと;メッセージを受信側に送信するステップとが含まれる。最後のステップは、回答/肯定応答を気にせずに(撃ち放し)、あるいはある数の回答/肯定応答を受信することによって(逆シリアライゼーション)実行することができる。
【０１０６】
メッセージ関連ステップの実行について、プロセスエンジンは、XIランタイムによって提供されるサービスに頼り、プロセスエンジンによって提供されるサービスに頼らない。XIランタイムは、プロセスエンジンによって使用される次のサービスを提供する:送信;受信側判定;および変換。モデル化ツールを提供することができる。プロセスエンジンは、メッセージビュー(XIランタイム)からおよびプロセスビュー(プロセスランタイム)からの技術的な監視も提供することができる。プロセス監視からメッセージ監視へおよびその逆へのナビゲートが可能でなければならない。さらに、XI監視基盤(すなわち、ランタイムワークベンチ)内の統合を実行することができる。プロセスエンジンコンポーネントテストは、プロセスエンジンが生きているかどうかをシグナリングしなければならない。最後に、プロセスは、CCMS基盤でアラートを転送することができる。
【０１０７】
監視は、2つの主な領域に分割することができる:プロセスエンジンの総合的状態の監視;および1つの単一プロセス実体の監視。前者の領域について、システムは、例えばすべてのアクティブプロセス実体の実際の状態のグラフィカル表示など、実行中のプロセス監視をサポートする。システムは、プロセス監視のためのデータボリュームおよび実行時性能情報もサポートすることができる。後者の領域について、システムは、プロセス実体ごとにプロセスログを書き込み(アプリケーションは、それ自体のアプリケーションメッセージをプロトコルに書き込む必要がある)、アプリケーションデータ(例えば、注文番号)を用いて選択する可能性と共にプロセスログを表示するように構成される。
【０１０８】
図１６に、ビジネスプロセスエンジンランタイム600の例を示す。例えば、SRMアプリケーション802は、統合サーバ206を介して供給業者アプリケーション804と通信する。ランタイム内ではSRMアプリケーション802に関してのみ表されているが、各アプリケーションに、インバウンドインタフェースおよびアウトバウンドインタフェースが含まれ、統合サーバ206への接続性のためにプロキシを含めることができる。統合リポジトリ202に、SRMアプリケーション802と供給業者アプリケーション804の間の意味規則的にリンクされた通信を表すビジネスプロセス232の実体が含まれる。
【０１０９】
ビジネスプロセス実体232に、論理インタフェースおよび物理インタフェースを含む、SRMアプリケーションと供給業者アプリケーションの間の通信を定義するプロセス定義が含まれる。このプロセス定義は、これらのアプリケーションのサービスの間で行われるメッセージングアクションおよび内容を定義し、望み通りに微細な精度にすることができる。
【０１１０】
統合サーバ206に、ビジネスプロセスエンジン274が含まれ、このビジネスプロセスエンジン274は、統合リポジトリから(および、図示されていない統合ディレクトリを介して)ビジネスプロセス実体を受信し、実行する。統合サーバ206には、論理ルーティング、マッピング、および物理アドレス解決などのメッセージング機能およびサービス806も含まれる。これらの機能およびサービス806に、送信側アプリケーションと受信側アプリケーションの間のメッセージの結合、分割、作成、および/またはマッピングのためのマップ変換サービスも含まれる。統合サーバ206は、アプリケーションサービス間のウェブベースメッセージング用のコアメッセージングサービスも提供する。
【０１１１】
上記で少数の実施形態を詳細に説明したが、他の変更が可能である。他の実施形態は、特許請求の範囲に含まれ得る。
【図面の簡単な説明】
【０１１２】
【図１】統合されたメッセージに基づくコラボレーションのための交換システムを示す単純化されたブロック図である。
【図２】交換基盤を示すブロック図である。
【図３】共同処理のための統合リポジトリ、統合ディレクトリ、およびランタイムエンジンを示す詳細なブロック図である。
【図４】複数のアプリケーションの間で単一のメッセージを通信する処理を示すブロック図である。
【図５】統合サーバおよびビジネスプロセスエンジンを含むBPMシステムを示すアーキテクチャブロック図である。
【図６】BPMシステムを示すワークフロー図である。
【図７】ビジネスプロセスとの間のリンクを示す図である。
【図８】BPMシステムのシリアライゼーションユースケースを示す図である。
【図９】BPMシステムの基本結合シナリオを示す図である。
【図１０】BPMシステム内のステートレス通信シナリオを示す図である。
【図１１】BPMシステム内のステートフル通信シナリオを示す図である。
【図１２】BPMシステム内の3タイプの通信シナリオを示す図である。
【図１３】同一インタフェースで異なる送信ステップの間から区別するためのコンテキストオブジェクトの使用を示す図である。
【図１４】BPMシステムでの結合事例の態様を示す図である。
【図１５】プロセス正規化された値フォーマット動作として値マッピング処理を示す図である。
【図１６】プロセスエンジンランタイムの実施形態を示す図である。
【図１７】暗黙の取消動作を示す図である。
【符号の説明】
【０１１３】
100  システム
102  内部コンポーネント(IC)
104  外部コンポーネント(EC)
105  ファイヤウォール
110  交換基盤(XI)
200  システム環境
202  統合リポジトリ
203  システム環境ディレクトリ
204  統合ディレクトリ
206  統合サーバ
208  ランタイムワークベンチ
209  アダプタ
210  ウェブアプリケーションサーバ
211  固有アプリケーション
213  ウェブベースサービス
214  ランタイムエンジン
215  サードパーティアプリケーション
216  統合サービス
218  プロキシジェネレータ
220  Java(登録商標)アプリケーション
222  ABAPアプリケーション
230  ビジネスシナリオ
232  設計時のビジネスプロセス
234  ルーティングオブジェクト
236  マッピング
238  インタフェース
240  ソフトウェアコンポーネント
250  ビジネスシナリオ
252  ビジネスプロセス
254  コンテキストオブジェクト
256  マッピング
258  ウェブサービス
260  ビジネスパートナ
262  システム環境
272  統合層
274  ビジネスプロセスエンジン
276  論理ルーティングサービス
278  マッピングサービス
280  メッセージングおよびトランスポート層(MTL)
282  物理アドレス解決サービス
284  メッセージングおよびキューイングサービス
286  トランスポートサービス
288  データベース
299  BPMシステム
302  送信側コンポーネントシステム
303  送信側アプリケーション
304  受信側コンポーネントシステム
305  受信側アプリケーション
307  アウトバウンドプロキシ
309  アダプタ
310  メッセージ
311  インバウンドプロキシ
500  BPMシステム
502  統合サーバ
504  プロセスエンジン
503  クライアントアプリケーションシステム
505  J2EEプラットフォーム
506  プロセス定義
508  BPMランタイム
512  XIオブジェクト
514  統合ディレクトリ
516  システムランタイム構成
518  ビジネスプロセス
520  設計時の構成
522  統合リポジトリ
524  監視および管理ツール
526  インポート/エクスポートフレームワーク
600  ワークフロー
702  抽象インタフェース
704  コンテキストオブジェクト
706  インタフェースマッピング
708  プロセスインタフェース
710  メッセージ型
712  メッセージマッピング
720  ビジネスシナリオ
730  ビジネスシナリオ
732  プロセス
734  ルーティング関係
736  マッピング関係
802  SRMアプリケーション
804  供給業者アプリケーション
806  メッセージング機能およびサービス
【図１】
0005290518.tif 000002
【図２】
0005290518.tif 000003
【図３】
0005290518.tif 000004
【図４】
0005290518.tif 000005
【図５】
0005290518.tif 000006
【図６】
0005290518.tif 000007
【図７】
0005290518.tif 000008
【図８】
0005290518.tif 000009
【図９】
0005290518.tif 000010
【図１０】
0005290518.tif 000011
【図１１】
0005290518.tif 000012
【図１２】
0005290518.tif 000013
【図１３】
0005290518.tif 000014
【図１４】
0005290518.tif 000015
【図１５】
0005290518.tif 000016
【図１６】
0005290518.tif 000017
【図１７】
0005290518.tif 000018