JP4367426B2 - ワークフロートラッキングシステム、統合管理装置、方法、プログラム、及びそれを記録した情報記録媒体 - Google Patents

Description

本発明は、一般にはインターネットの利用の有無を問わず、複数の業務アプリケーションシステム群を連携させて、業務連携を実施するワークフロー管理システムに属し、そのワークフロー管理システムを用いることで、業務アプリケーションシステム上で実施される業務の進捗トラッキング、状況評価に関する。

従来の業務プロセストラッキング装置に関する方式例を以下に二つ記す。図１８に示す方は、ワークフロー管理に対して分散的な管理概念のない方式（以下、従来第１の方式）である。図１９に示す方は従来の業務プロセストラッキング装置で分散的な管理概念がある方式であるが、効率などの点で課題が存在すると考えられる方式（以下、従来第２の方式）である。

図１８は、特許文献１に開示された、従来第１の方式のシステムの構成例を示す。

図１８に示すシステムにおいて、B1はイベントデータを収集し管理するイベント管理装置、B3、B4及びB5は業務システム、B6は利用者端末である。

イベント管理装置B1内において、入力部B11はイベントデータの検索条件を入力する。イベントキューB12は、業務システムB3〜B5から送信されたイベントデータがキューイングされる。イベント関連付け部B13は、イベントキューB12内のイベントデータを業務データ単位にまとめ、業務データ間の関連付けを行う。イベント管理ＤＢB14は、関連付けられた業務データが蓄積される。業務プロセスＤＢB15は、業務プロセスの定義情報と業務データの定義情報とが蓄積される。出力部B16は、利用者端末B6から入力された検索条件に基づくイベント管理ＤＢB14の検索結果を出力する。

業務プロセスとは、業務システム間を跨ぐ業務全体の流れを意味する。以下では、業務プロセスが、受注、在庫照会、発注、受入、出荷、配送等の業務から構成されるものとして説明する。また、業務データとは、前述したように、あるまとまった単位の業務の間で共有されるイベントデータを意味する。業務データは、イベント管理ＤＢB14内では、各業務の伝票という形で蓄積される。

業務システムB3において、アプリケーションB30及びB30’は、それぞれ業務システムB3内で業務を実行する。状態ＤＢB31は、アプリケーションB30の状態が蓄積されている、状態ＤＢB31’は、アプリケーションB30’の状態が蓄積されている。イベント抽出部B32は、状態ＤＢB31及び状態ＤＢB31’からイベントデータを抽出する。イベントデータ変換部B33は、抽出したイベントデータを、例えばXML（Extensible Markup Language）形式に変換する。イベントデータ送信部B34は、変換されたイベントデータをイベント管理装置B1に送信する。イベント抽出定義のデータ（以下、単にイベント抽出定義という）B320は、業務システムB3内のどのデータ項目を抽出するかが定義されている。

業務システムB4内において、アプリケーションB40及びB40’は、業務システムB4内で業務を実行する。状態ＤＢB41は、アプリケーションB40の状態が蓄積されている。状態ＤＢB41’は、アプリケーションB40’の状態が蓄積されている。イベント抽出部B42は、状態ＤＢB41又は状態ＤＢB41’からイベントデータを抽出する。イベントデータ変換部B43は、抽出したイベントデータを、例えばXML形式に変換する。イベントデータ送信部B44は、変換されたイベントデータをイベント管理装置B1に送信する。イベント抽出定義B420は、業務システムB4内のどのデータ項目を抽出するかが定義されている。

業務システムB5内において、アプリケーションB50及びB50’は、業務システムB5内で業務を実行する。状態ＤＢB51は、アプリケーションB50の状態が蓄積されている。状態ＤＢB51’は、アプリケーションB50’の状態が蓄積されている。イベント抽出部B52は、状態ＤＢB51又は状態ＤＢB51’からイベントデータを抽出する。イベントデータ変換部B53は、抽出したイベントデータを例えばXML形式に変換する。イベントデータ送信部B54は、変換されたイベントデータをイベント管理装置B1に送信する。イベント抽出定義B520は、業務システムB5内のどのデータ項目を抽出するかが定義されている。

イベント管理装置B1のイベントキューB12にキューイングされるイベントデータは、例えば、イベントの種別を示すイベント種別、イベントが属しているデータの識別子である主キー、主キーに対応する業務に関連する業務のイベントが属しているデータの識別子である関連キー、製造番号、個数、単価等の属性データから構成される。

業務システムB3〜B5は、次のように配置される。業務システムB3は、例えば、受注及び在庫照会という業務を実行し、受注伝票を扱う。業務システムB4は、例えば、発注及び受入という業務を実行し、発注伝票を扱う。業務システムB5は、例えば、出荷及び配送という業務を実行し、配送伝票を扱う。

従来第１の方式では、業務プロセスのトラッキングの準備として、業務プロセスＤＢB15に格納する業務プロセス及び業務データの定義情報の入力、並びに各業務システムB3〜B5のイベント抽出部B32〜B52に設定するイベント抽出定義B320〜B520の入力が必要となる。

図１９は、特許文献２に記載された、分散的な管理概念を持つ従来業務プロセストラッキングに関する技術を用いた方式（以下、従来第２の方式）のシステム構成例を示す。

図１９には、共通業務プロセスの実行に関与する二つの組織（記号：ORG1）A1、（記号：ORG2）A2の全体図が示されている。これらの二つの組織は、例えば同じ企業又は会社のパートナー組織であり、各組織は共通業務プロセスのそれぞれの部分を実施する。あるいは、一方の組織、例えば組織A1が顧客組織で、業務プロセスの少なくとも一部の実行を供給業者である組織A2に委託しているケースなども該当する。この方式の従来技術は、共通業務プロセスの実行に関与する組織が三つ以上の場合も適用できる。

この業務プロセスの実行に関与する各組織A1、A2（以下、単に関与組織と呼ぶ）は、業務プロセスのそれぞれの部分の管理目的で、それぞれのワークフロー管理システム（記号：WfMS1）A3、（記号：WfMS2）A4を有する。具体的には各関与組織A1、A2におけるそれぞれのワークフロー管理システムA3、A4は、その組織のそれぞれのデータ処理システム上で稼働するコンピュータ・ベースの管理システムに相当する。
各関与組織A1、A2のデータ処理システムは、１台、またはより一般的には数台のパーソナル・コンピュータ又はワークステーションを含み、数台の場合にはLAN（Local Area Network）、WAN(Wide Area Network)などのデータ通信ネットワークを介して相互接続されており、組織が地理的に異なる場所に分散している場合にはインターネットを介して相互接続される。

各関与組織A1、A2のワークフロー管理システムA3、A4は、ワークフロー管理システム・サーバ（記号：WfMS1_S）A5、（記号：WfMS2_S）A6を含む（これらを以下では単にワークフロー・サーバと呼ぶ）。ワークフロー・サーバA5、A6は、ワークフロー管理システムA3、A4のサーバとして動作稼働するサーバ・コンピュータ・アプリケーションである。ワークフロー・サーバA5、A6は、業務プロセスの各部分の実行状態に関する情報を維持管理し、更新する。ワークフロー・サーバが維持管理する情報は、ワークフロー上のイベント操作によって、状態変更が生じ、当該実行状態に関する情報が更新される。

これらワークフロー管理システムA3、A4の導入により、一般の業務プロセスを、電子化することが可能となり、統語構造単位（Syntactical Unit）に基づきモデリング、電子業務プロセスが定義される。当該電子業務プロセスのモデルが作成された後は、企業内又は会社内で行われる同様のプロセスのクラスのテンプレートを構成することになる。該プロセス・テンプレートは、一般にデータ処理システムによってインスタンス化し、解釈することができ、業務プロセスを行うのに必要な作業ステップの個々シーケンスを判断することができる。作業ステップのシーケンスは、プロセス・テンプレートのインスタンス化のコンテキストに依存することになる。プロセス・テンプレートのインスタンスとその解釈が、個々のプロセスを表す。プロセス・テンプレートの基本要素をアクティビティと呼ぶ。アクティビティは、意味論的（Semnaticalな）エンティティと見做すこともできる業務アクションを表す。プロセス・テンプレートは、ワークフロー・アクティビティと、その実行順序と割り当てられる資源とを記述する。

図１９で示すように、ワークフロー・サーバA5は、複数のプロセス・テンプレート（記号：PT1）A13、（記号：PT2）A11、．．を保持管理する。同様に、ワークフロー・サーバA6は、複数のプロセス・テンプレート（記号：PT1'）A14、（記号：PT2'）A12、．．を保持管理する。

プロセス・テンプレートA11のプロセス・インスタンス（記号：PI１（PT1））A9が、ワークフロー・サーバA5上で稼働している様子も略図で示されており、同じプロセス・テンプレートA11の対応するプロセス・インスタンスＰＩ（PT1）がワークフロー・サーバA6上で稼働している。

各関与組織A1、A2では、ワークフロー・サーバA5、A6が、それぞれのワークフロー・サーバが稼働しているのと同じサーバ・コンピュータ又はワークステーション上で稼働しているそれぞれの状態シャドウイング・エンジン（記号：SSE1）A15、（記号：SSE2）A16と対話する。

また、各関与組織A1、A2では、複数のワークフロー管理システム・クライアント（記号：WfMS1_C）A17、（記号：、WfMS2_C）A18（以下、単にワークフロー・クライアントと呼ぶ）が、それぞれの状態シャドウイング・エンジンA15、A16が備えるインタフェースを介して、ワークフロー・サーバA5、A6と対話している。
ワークフロー・クライアントA17、A18は、パーソナル・コンピュータ又はワークステーションで稼働するクライアント・アプリケーションである。関与組織A1、A2内のワークフロー管理システムA3、A4の利用者（記号：Ｕａ）A27、（記号：Ｕｂ）A29、（記号：Ｕｃ）A28、（記号：Ｕｄ）A30は、ワークフロー・クライアントA17、A18を使用して、所属する組織のワークフロー管理システムA3、A4と対話することができる。

ワークフロー・サーバA5、A6は、それぞれインタフェース（記号：WfMS1_SＴ）、（記号：WfMS2_SＴ）を備え、それによって組織A1、A2内の利用者A27、A29、A28、A30がワークフロー・クライアントA17、A18を介して操作して、それぞれの当該ワークフロー・サーバA5、A6にログオンし、その組織で実行されているアクティビティの状態（たとえば開始、終了、完了）を参照、必要に応じて当該アクティビティの状態の更新を加えることができる。異なる利用者がそれぞれの利用者識別子、例えば利用者A27はUIDa、A29はUIDb、A28はUIDc、A30はUIDdを持ち、それによってワークフロー・クライアントA17、A18がワークフロー・サーバA5、A6と対話してワークフロー管理システムの状態参照と更新とを行うことができる。これらの異なる利用者識別子には異なる特権レベルを割り当てることができ、それによって異なる利用者が異なる特権レベルで当該ワークフロー管理システムA3、A4を操作することができる。例えば、利用者識別子UIDaを持つ利用者A27には、ワークフロー管理システムA3の状態の参照と更新とを行う特権を割り当てることができ、識別子UIDbを持つ利用者A29には、より低い特権が割り当てられ、ワークフロー管理システムA3の状態の参照のみを行うことができる。

二つの組織A1、A2の状態シャドウイング・エンジンA15、A16は互いに通信することが可能である。この対話は、LAN、WAN、インターネットなど、２つの組織A1、A2のデータ処理システムに任意の好適なデータ通信インフラストラクチャDCIを接続することによって可能になる。

各状態シャドウイング・エンジンA15、A16は、状態シャドウイング機能を実現し、それによって共通業務プロセスの実行に関与する組織のうちの一つの組織の利用者が他の関与組織内のワークフローの進捗をトラッキングすることができる。たとえば、当該状態シャドウイング機能によって、組織A1内のワークフロー管理システムA3の利用者A27、A29は、組織A2内のワークフローの進捗をトラッキングすることができ、また、その逆も同様である。

具体的には、状態シャドウイング・エンジンA15、A16によって実現された状態シャドウイング機能によって、各関与組織A1、A2のワークフロー管理システムA3、A4内に、共通業務プロセスのうちの他の組織によって実行されている部分の内部複製であるシャドウを作成することが可能となる。

共通業務プロセスのそれぞれの部分の実行中に、関与組織の一つ、例えば組織A2によって操作が行われると、ローカルのワークフロー管理システムA4が状態を変更し、状態シャドウイング・エンジンA16を介して、他の関与組織、例えば組織A1のワークフロー管理システムA3に、その状態変更を通知するメッセージを送る。関与組織A1の状態シャドウイング・エンジンA15は当該メッセージを受け取り、必要に応じて変換し、対応する状態変更を生じさせる。それによって組織A2のワークフロー管理システムA4の状態を複製することができる。

状態シャドウイング・エンジンA15、A16は、付随するワークフロー・サーバA5、A6の既存のインタフェース（記号：WfMS1_SＩ）A7、（記号：WfMS2_SＩ）A8を利用して、それらサーバ間で相互に通信する。

このために、状態シャドウイング・エンジンA15、A16には、適切な高レベルの特権を持つそれぞれの利用者識別子UIDx、UIDｙが定義される。状態シャドウイング・エンジンA15、A16は、それぞれのワークフロー・サーバA5、A6にログインする際、利用者識別子UIDx、UIDｙを使用する。以上から、状態シャドウイング・エンジンA15、A16は、それぞれの通信相手のワークフロー・サーバA5、A6から見れば、一つのワークフロー・クライアントと見なされる。
特開２００５−１１５４９４号公報 特開２００４−５５５０号公報

従来の業務プロセストラッキング装置に関する課題を記す。
従来第２の方式は、従来第１の方式における幾つかの課題は解決しているが、従来第２の方式自身にも固有の課題は存在している。そこで、まず従来第１の方式における課題を説明する。

従来第１の方式における課題は複合・階層的であり、基本的課題と関連課題とに分けられる。
基本的課題として２点ほど挙げられる。

基本的課題の１点目は、従来第１の方式は、EAI(Enterprise Application Integration)関係の製品に見られる方式で、分散化された環境では対応できないことである。昨今のインターネットをベースとした組織間の連携、異なる会社間の業務連携は極めて広がりの大きい事項であり、単一の業界だけでは対応できる事項ではない。そのため、業際事項（ある業界に関する事項及びこれとは別の業界に関する事項並びにこれらの業界の間にまたがる事項）を含め標準の役割が非常に大きくなる。その為、現実にはマルチベンダによる分散環境により、初めて実現可能となる。しかし、図１８に示されるような従来第１の方式は、ワークフローレベルで分散化された環境を指向している訳ではない。

基本的課題の２点目は、従来第１の方式では、ワークフローエンジンの役割について、明確に規定されていないことである。図１８に示すような環境を構築する際には、ワークフローエンジンの役割は決定的であり、この存在を無視したシステム連携は想定できない。このため、サービス指向の連携する場合、他のワークフローシステムとの連携がまったく取れないという課題が出る。

以上の二つの基本的課題により、更に三つの関連課題が発生する。
第１の関連課題は、自ら業務フローを定義しなければならないことである。通常のワークフロー、業務トラッキング製品では、内部のワークフローエンジンにより業務プロセスの流れは制御されている。しかし、従来第１の方式では、ワークフローエンジンとは独立となっているため、自ら業務フローを定義・入力しなければならない。これは、業務上のフローがダイナミックに変化する場合、全て業務の登録し直さなければならない、もしくはワークフローエンジンと二重に定義情報を入力しなければならない課題を引き起こす。

第２の関連課題は、従来第１の方式のシステムは、業務フローエンジンと組み合わせても業務全体の流れをトラッキングできる訳ではないということである。すなわち、従来第1の方式のシステムは、業務フローにおけるイベントを一つの単位としてトラッキングするため、業務フローとして定義されていない動作や、業務フローを遂行する上で実行されるアプリケーションの内部においてどのような処理が行われるかについてまでトラッキングができるわけではない。換言すると、従来第１の方式では、厳密なトラッキングをする場合、全ての枝葉末節までの業務データを登録しなければ、仔細はトラッキングできない。通常、ワークフローエンジンにより業務の流れが制御されている現状で、このように全ての業務全体の流れをトラッキングするには非現実的である。

第３の関連課題としては、状態管理ＤＢを配置することで業務システムを汚さずに（業務システムに機能を追加することなく）、イベント収集できる旨を主張しているが、通常、アプリケーションは種々のプラットフォームがあり、また開示されない場合もある。現実の運用環境を考えた場合、図１８のような状態管理ＤＢを配置することは現実的ではない。

従来第１の方式における以上の五つの課題に対して、従来第２の方式は、幾つかの課題を解決している。上記の第２の基本的な課題については、従来第２の方式で解決し得る。また、第１の関連課題に関してもテンプレートの概念を開発環境に適用することで、解決し得る。

また、第２の関連課題については、図１９のテンプレートの作成範囲を広げる、もしくは新たなテンプレートを作成し、複数のワークフロー・サーバ（記号：WfMS2_S、WfMS1_S）を立ち上げ、シャドウイングを実施することで、トラッキングの範囲を広げることはできる。しかし、第２の関連課題、並びに、上記第１の基本的な課題に関しては、従来第２の方式で完全に解決するためには前提条件も存在する。従来第２の方式では標準として定義されるべき部分と、それ以外の部分についての切り分けが曖昧である。従って、原理的には先の第１の基本的課題、並びに第２の関連課題に対する解決策を実現し得たとしても、実際の実装の中では従来第２の方式だけでは解決し得ない場合も存在する。

また、第３の関連課題については、特に言及されているわけではなく、従来第２の方式は、解決策とは独立（換言すると、従来の第２の方式では第３の関連課題を解決できない）である。ここでは、「業務プロセストラッキングのための観測手段の業務アプリケーションシステムに対する独立性に関する課題」と称する。

従来第２の方式自身にも課題は存在している。当該方式では、分散化しているワークフローの進捗管理をすることは可能である。しかし、本方式では業務のトラッキングを第一に指向している訳ではない。原理的には全ての複数ワークフロー・サーバが、分散化しているワークフローの進捗管理を共有しているため、任意のワークフロー・サーバに対するワークフロー・クライアントを見ることで、業務のトラッキングは実現し得る。

しかし、当該の従来第２の方式では、全ての複数ワークフロー・サーバ間でお互いに進捗を通信し合わなければ、これを実現できない。この場合、参加するワークフロー・サーバがN台になれば、一つの通信に対して原理的にNの自乗の通信が発生することになり、ネットワークの利用効率が決定的に落ちる課題が懸念される。以下、この課題を、「業務プロセストラッキング処理で分散的な管理概念がある方式の管理非効率に関する課題」と表記する。

本発明の目的は、下記の課題を解決することにある。

従来第１の方式についての上記の五つの課題点を全て解決すること。

従来第２の方式で新たに発生した、上記「業務プロセストラッキング処理で分散的な管理概念がある方式の管理非効率に関する課題」を解決すること。

従来第１の方式で発生し、従来第２の方式では、完全に解決できない、上記「業務プロセストラッキングのための観測手段の業務アプリケーションシステムに対する独立性に関する課題」を解決すること。

すなわち、本発明は、分散化された環境に対応可能、他のワークフローシステムとの連携が容易、業務フローの定義が不要、状態管理ＤＢの設置が不要、かつネットワークの利用効率を落とすことのないワークフロートラッキングシステム、ワークフロー統合管理装置、ワークフロー統合管理方法、ワークフロー統合管理プログラム、及びそれを記録した記録媒体を目的とする。

上記目的を達成するため、本発明は、第１の態様として、ワークフローを管理・実行する複数のワークフロー実行装置と、該ワークフロー実行装置のそれぞれからワークフローに関する情報を取得し、これらを統合した統合ワークフローを生成するワークフロー統合管理装置とを有するワークフロートラッキングシステムであって、前記各ワークフロー実行装置は、自装置が管理する任意のワークフローを実行する際に自装置において発生するイベントの内容を表し、それぞれのイベントごとに固有のイベント情報を記録する手段と、記録済みの前記イベント情報と前記ワークフローの内容を標準化されたデータ形式で表すワークフロー記述とを前記ワークフロー統合管理装置へ送信する手段とを有し、前記ワークフロー統合管理装置は、前記各ワークフロー実行装置から、前記ワークフロー記述を取得する手段と、前記各ワークフロー実行装置から取得した前記イベント情報によって特定される各イベントに関して、他のイベントとの関連を検出するイベント関連検出手段と、前記各ワークフロー実行装置から取得した前記ワークフロー記述から、前記ワークフロー記述に含まれる他のワークフロー記述で定義されるサービスを指定する情報に基づいて各ワークフロー記述のリンク関係を作成することによって前記統合ワークフローを生成した後、当該統合ワークフローに複数の前記イベント情報を関連付ける手段と、前記各ワークフロー実行装置から取得した全ての前記イベント情報を記録するイベント情報記録手段と、前記イベント情報記録手段に記録されたイベント情報を、他の装置からの要求に応じて参照させる手段と、を有することを特徴とするワークフロートラッキングシステムを提供するものである。

本発明の第１の態様においては、標準化されたデータ形式とは異なる形式でワークフロー記述が定義されたワークフロー実行装置には、そのワークフロー記述を標準化されたデータ形式に変換する標準化装置が内蔵又は接続されていることが好ましい。

本発明の第１の態様の上記のいずれの構成においても、ワークフロー統合管理装置は、イベント情報に対して人間が認識可能な形式の任意の情報を付加する手段を更に有することが好ましい。また、ワークフロー統合管理装置は、イベント情報記録手段に記録したイベント情報に基づいて統計処理を行い統計データを生成するパッチ処理手段を有することが好ましい。また、ワークフロー実行装置は、ワークフローを実行する際に通信相手となる業務アプリケーションシステムに固有な通信手順を、標準化された通信手順に変換するためのアダプタを複数備えることが好ましい。

また、上記目的を達成するため、本発明は、第２の態様として、ワークフローを管理・実行する複数のワークフロー実行装置のそれぞれからワークフローに関する情報を取得し、これらを統合した統合ワークフローを生成するワークフロー統合管理装置であって、前記各ワークフロー実行装置から、前記ワークフローの内容を標準化されたデータ形式で表すワークフロー記述を取得する手段と、前記各ワークフロー実行装置が前記ワークフローを実行する際にその装置において発生するイベントの内容を表し、それぞれのイベントごとに固有のイベント情報を前記各ワークフロー実行装置から取得する手段と、取得した前記イベント情報によって特定される各イベントに関して、他のイベントとの関連を検出するイベント関連検出手段と、前記各ワークフロー実行装置から取得した前記ワークフロー記述から、前記ワークフロー記述に含まれる他のワークフロー記述で定義されるサービスを指定する情報に基づいて各ワークフロー記述のリンク関係を作成することによって前記統合ワークフローを生成した後、当該統合ワークフローに複数の前記イベント情報を関連付ける手段と、前記各ワークフロー実行装置から取得した全ての前記イベント情報を記録するイベント情報記録手段と、前記イベント情報記録手段に記録されたイベント情報を、他の装置からの要求に応じて参照させる手段と、を有することを特徴とするワークフロー統合管理装置を提供するものである。

本発明の第２の態様においては、イベント情報に対して人間が認識可能な形式の任意の情報を付加する手段を更に有することが好ましい。

本発明の第２の態様の上記のいずれの構成においても、イベント情報記録手段に記録したイベント情報に基づいて統計処理を行い統計データを生成するパッチ処理手段を有することが好ましい。

また、上記目的を達成するため、本発明は、第３の態様として、ワークフローを管理・実行する複数のワークフロー実行装置と、該ワークフロー実行装置のそれぞれからワークフローに関する情報を取得し、これらを統合した統合ワークフローを生成するワークフロー統合管理装置とを用いたワークフロー統合管理方法であって、前記各ワークフロー実行装置が、自装置が管理する任意のワークフローを実行する際に自装置において発生するイベントの内容を表し、それぞれのイベントごとに固有のイベント情報を記録する工程と、前記各ワークフロー実行装置が、記録済みの前記イベント情報と前記ワークフローの内容を標準化されたデータ形式で表すワークフロー記述とを前記ワークフロー統合管理装置へ送信する工程と、前記ワークフロー統合管理装置が、前記各ワークフロー実行装置から取得した前記イベント情報によって特定される各イベントに関して、他のイベントとの関連を検出するイベント関連検出工程と、前記ワークフロー統合管理装置が、前記各ワークフロー実行装置から取得した前記ワークフロー記述から、前記ワークフロー記述に含まれる他のワークフロー記述で定義されるサービスを指定する情報に基づいて各ワークフロー記述のリンク関係を作成することによって前記統合ワークフローを生成した後、当該統合ワークフローに複数の前記イベント情報を関係付ける工程と、前記ワークフロー統合管理装置が、前記各ワークフロー実行装置から取得した全ての前記イベント情報を記録するイベント情報記録工程と、前記ワークフロー統合管理装置が、前記イベント情報記録手段に記録されたイベント情報を、他の装置からの要求に応じて参照させる工程と、を有することを特徴とするワークフロー統合管理方法を提供するものである。

本発明の第３の態様においては、標準化されたデータ形式とは異なる形式でワークフロー記述が定義されたワークフロー実行装置は、そのワークフロー記述を標準化されたデータ形式に変換してワークフロー統合管理装置へ送信することが好ましい。

本発明の第３の態様の上記のいずれの構成においても、ワークフロー統合管理装置が、イベント情報に対して人間が認識可能な形式の任意の情報を付加する工程をさらに有することが好ましい。また、ワークフロー統合管理装置が、イベント情報記録工程において記録したイベント情報に基づいて統計処理を行い統計データを生成するパッチ処理工程を有することが好ましい。

また、上記目的を達成するため、本発明は、第４の態様として、上記本発明の第３の態様のいずれかの構成にかかるワークフロー統合管理方法をコンピュータに実行させるためのワークフロー統合管理プログラムを提供するものである。

また、上記目的を達成するため、本発明は、第５の態様として、ワークフロー統合管理プログラムを記録したコンピュータが読取可能な情報記録媒体を提供するものである。

本発明によれば、分散化された環境に対応可能、他のワークフローシステムとの連携が容易、業務フローの定義が不要、状態管理ＤＢの設置が不要、かつネットワークの利用効率を落とすことのないワークフロートラッキングシステム、ワークフロー統合管理装置、ワークフロー統合管理方法、ワークフロー統合管理プログラム、及びそれを記録した記録媒体を提供できる。

〔発明の原理〕
本発明は、複数の業務アプリケーションシステム群の起動状態、操作順序の定義を維持管理し、制御する、あるまとまった業務範囲を意味する全体ワークフローのそれぞれの要素ワークフロー部分を、ワークフローエンジンを実装した複数のワークフロー管理システムが独立・分散して管理、保持している環境下で、分散された要素ワークフロー部分の実行を統合して管理する方法を具現する装置である。従来課題を以下の手段により解決する。
〔手段１〕
以下の六つの要素手段の組み合わせ。
・複数のワークフロー管理システムに分散している要素ワークフローの記述を収集する手段。
・分散している要素ワークフローの記述を予め指定された標準形式として記述・管理する手段。
・分散している要素ワークフローのうち標準形式で記述されていないものの記述を当該標準形式に変換する手段。
・分散している要素ワークフローの記述を複数個合成し、全体のワークフローの記述を再生するワークフロー合成手段。
・要素ワークフロー部分を実施する際に事象として発生するイベント群を当該全体のワークフローの記述に位置付け、当該イベント群以外のイベント群と関連して記録するイベント格納要素手段。
・イベント格納手段に記録されている任意の情報を、要求に応じて他の装置に参照させる要素手段。
〔手段２〕
標準形式として記述された要素ワークフローの外側の領域で事象として発生するイベント群を取り込むことを可能することを目的として、要素ワークフロー部分を実施する際に事象として発生するイベント群が、標準形式として記述・管理する方式と異なる場合に、その仲立ちを取り持つ代理通信手段。
〔手段３〕
分散する要素ワークフローの記述が機械可読形式であることから、当該要素ワークフローの記述内の記述子に対して、任意の情報を付与するアプリケーションラベル入力手段。
〔手段４〕
要素ワークフロー部分を実施する際に事象として発生するイベント群を全体のワークフローの記述に当てはめ、当該イベント群以外のイベント群と関連して記録するイベント格納手段をアクセスし、当該イベント群に関連する統計データを生成する処理手段。
〔手段５〕
全体ワークフローの記述により、起動状態、操作順序の定義を維持管理され、制御される複数の業務アプリケーションシステム群を、ワークフローエンジンを実装したワークフロー管理システムが呼び出す際に、当該業務アプリケーションシステム群固有の通信手順を、標準的な通信手順として変換するアダプタ処理手段。
〔効果をもたらす手段の働き〕
従来第１の方式により発生する最初の基本的課題は、標準の役割を明確に定義し、マルチベンダ化を促進することであり、これに対しては、特に手段１で組み合わされる以下の３つの要素手段が有効に機能する。
(1)分散している要素ワークフローの記述を予め指定された標準形式として記述・管理する手段。
(2)分散している要素ワークフローのうち標準形式で記述されていないものの記述を当該標準形式に変換する手段。
(3)分散している要素ワークフローの記述を複数個合成し、全体のワークフローの記述を再生するワークフロー合成手段。

従来第１の方式により発生する第二の基本的課題は、ワークフローエンジンの役割が決定的に重要であるにも関わらず、具体的定義がなされていないため、サービス指向の連携する場合、他のワークフローシステムとの連携がまったく取れないという問題である。これに対しても、特に手段１で組み合わされる以下の３つの要素手段が有効に機能する。
(1)分散している要素ワークフローの記述を予め指定された標準形式として記述・管理する要素手段。
(2)分散している要素ワークフローのうち標準形式で記述されていないものの記述を当該標準形式に変換する手段。
(3)分散している要素ワークフローの記述を複数個合成し、全体のワークフローの記述を再生するワークフロー合成手段。

この方式では、図１９の方式とは異なり、標準化するべき対象を、既存の標準化機能範囲と明確に連携させているため、従来第１の方式により発生する最初の基本的課題、第二の基本的課題は明確に解決できることになる。

従来第１の方式により発生する第一の関連課題は、当該方式では、ワークフローエンジンとは独立となっているため、自ら業務フローを定義・入力しなければならないことである。
これは、業務上のフローがダイナミックに変化する場合、全て業務の登録し直さなければならない、もしくはワークフローエンジンと２重に定義情報を入力しなければならない問題を引き起こす。

上記課題に対しては、特に手段１で組み合わされる以下の４つの要素手段が有効に機能する。
(1)複数のワークフロー管理システムに分散している要素ワークフローの記述を収集する手段。
(2)分散している要素ワークフローの記述を予め指定された標準形式として記述・管理する要素手段。
(3)分散している要素ワークフローのうち標準形式で記述されていないものの記述を当該標準形式に変換する手段。
(4)分散している要素ワークフローの記述を複数個合成し、全体のワークフローの記述を再生するワークフロー合成手段。

従来第１の方式により発生する第二の関連課題は、業務フロー定義の外側、並びにアプリケーション内部のフローについてトラッキングができるわけではなく、厳密なトラッキングをする場合、全ての枝葉末節までの業務データを登録しなければ、仔細はトラッキングできないことを意味する、ことである。

当該、第二の関連課題に対しては、以下の機能により問題解決が可能となる。
(1)業務プロセストラッキング装置で分散的な管理概念のある方式を採用していること。
(2)上記手段２である仲立ちを取り持つ代理通信手段を備えること。
(3)業務アプリケーションシステム群固有の通信手順を、標準的な通信手順として変換するアダプタ処理手段を備えること。
(4)複数の分散している要素ワークフローの記述を合成し、全体のワークフローの記述を再生するワークフロー合成手段を備えること。
以上により、これらを組み合わせて全ての枝葉末節までの業務データを合成することが可能となるため、解決できることになる。

上記「業務プロセストラッキング処理で分散的な管理概念がある方式の管理非効率に関する課題」に対する解決手段としては、図１９に記した従来の業務プロセストラッキング装置で分散的な管理概念が完全に対照分散処理であることに対して、本発明は業務プロセスモニタ・トラッキング装置を配置し、集中方式としていることである。

その前提としては、
(1)分散している要素ワークフローの記述を複数個合成し、全体のワークフローの記述を再生するワークフロー合成手段。
(2)要素ワークフロー部分を実施する際に事象として発生するイベント群を当該全体のワークフローの記述に当てはめ、当該イベント群以外のイベント群と関連して記録するイベント格納手段。
(3)イベント格納手段に記録されている任意の情報を、要求に応じて他の装置に参照させる要素手段。
(4)要素ワークフローの記述内の記述子に対して、業務内の意味情報を付与するアプリケーションラベル入力手段。
(5)集中的に統計処理を実施する、統計データを生成する処理手段。
以上の五つの要素が存在していることである。

上記「業務プロセストラッキングのための観測手段の業務アプリケーションシステムに対する独立性に関する課題」に対する解決としては、複数の業務アプリケーションシステム群を、ワークフローエンジンを実装したワークフロー管理システムが呼び出す際に、当該業務アプリケーションシステム群固有の通信手順を、標準的な通信手順として変換するアダプタ処理手段である。

上記原理に基づく本発明は、そこに含まれる要素手段により、図１８に示した従来第１の方式の業務プロセストラッキング装置で発生する上記五つの課題全てを解決しえるので有効である。
更に、当該五つの課題に対する従来解決策として従来第２の方式よりも、より効率性が高いことが期待できることから、更に有効である。

以下、上記原理に基づく本発明の好適な実施の形態について説明する。

〔第１の実施形態〕
図１は、本発明を好適に実施した第１の実施形態にかかる分散ワークフロー管理方法に基づく業務プロセストラッキング装置の構成を示す。この業務プロセストラッキング装置は、分散ワークフロー管理方式に基づく複数のワークフローシステム（記号：WfMS_1）１、（記号：WfMS_２）２、並びに独自実装で、複数配置される他社・既存ワークフローシステム（記号：WfMS_３）３、並びに他社・既存ワークフローシステム３の複数をまとめ、この分散ワークフロー管理方法への仲介を行うProxyシステム（記号：PrxS）４、ワークフローシステム１、２やProxyシステム４から、各種イベント情報を収集した後、整理、統合、格納するための分散ワークフローモニタシステム（記号：DsWfMS）５、並びに分散ワークフローモニタシステム５にアクセスするためのクライアントシステムとして、Webブラウザによるクライアントサイト6、60を含んで構成される。

ワークフローシステム１は、複数の業務アプリケーションシステム（記号：AP_A）７、（記号：AP_B）８と通信を行う。また、ワークフローシステム２は、複数の業務アプリケーションシステム（記号：AP_C）９、（記号：AP_D）１０と通信を行う。また、ワークフローシステム３は、複数の業務アプリケーションシステム（記号：AP_E）１１、（記号：AP_F）１２と、Proxyシステム４を介して通信を行う。

上記の通信を実現するために、業務アプリケーションシステム７は、データ通信部（記号：COM_A）１３を含む。また、業務アプリケーションシステム８は、データ通信部（記号：COM_B）１４を含む。

同様に、業務アプリケーションシステム９は、データ通信部（記号：COM_C）１５を含む。また、業務アプリケーションシステム１０は、データ通信部（記号：COM_D）１６を含む。

同様に、業務アプリケーションシステム１１は、データ通信部（記号：COM_E）１７を含む。また、業務アプリケーションシステム１２は、データ通信部（記号：COM_F）１８を含む。

これに対して、ワークフローシステム１は、データ通信部１３と通信を行うためのアダプタ（記号：AD1_A）１９を含むとともにデータ通信部１４と通信を行うためのアダプタ（記号：AD1_B）２０も含む。これらのアダプタは、ワークフローシステム１に含まれるワークフローエンジン（記号：WfE_1）２９が動作した結果、必要な通信を業務アプリケーションシステム７、業務アプリケーションシステム８と行う際に通信プロトコル上の差異及び操作上の差異を変換する。

同様に、ワークフローシステム２は、データ通信部１５と通信を行うためのアダプタ（記号：AD２_C）２１を含むとともにデータ通信部１６と通信を行うためのアダプタ（記号：AD２_D）２２も含む。これらのアダプタは、ワークフローシステム２に含まれるワークフローエンジン（記号：WfE_２）３２が動作した結果、必要な通信を業務アプリケーションシステム９、業務アプリケーションシステム１０と行う際に通信プロトコル上の差異及び操作上の差異を変換する。

同様に、ワークフローシステム３は、データ通信部１７と通信を行うためのアダプタ（記号：AD３_E）２３を含むとともにデータ通信部１８と通信を行うためのアダプタ（記号：AD３_F）２４も含む。これらのアダプタは、ワークフローシステム３に含まれるワークフローエンジン（記号：WfE_３）３７が動作した結果、必要な通信を業務アプリケーションシステム１１、業務アプリケーションシステム１２と行う際に通信プロトコル上の差異及び操作上の差異を変換する。

なお、ワークフローシステム３は、独自実装の他社・既存ワークフローエンジンであることを想定しているため、データ通信部１７とアダプタ２３と間の通信、並びにデータ通信部１８とアダプタ２４と間の通信は、Proxyシステム４内のプロキシ部（記号：Prx_3）３５を介して実現される。

ワークフローエンジン２９の挙動は、ワークフローシステム１に含まれるワークフロー定義（記号：Wf定義_１）３１で定義される。通常、一つのワークフロー定義３１は、二つの部分で構成される。一方は、ワークフローエンジン２９の挙動のみを表す部分であり、他方は、ワークフローエンジン２９が通信する相手のインタフェースを表す部分である。これらのうち、前者は、WS-BPEL(Web Service Business Process Execution Language)を用いて記述されるのが標準であり、後者は、WSDL(Web Service Definition Language)を用いて記述されるのが標準である。
ワークフロー定義３１は、分散配置されている他のワークフローシステム２、Proxyシステム４を介して通信されるワークフローシステム３との間でやりとりする処理要求・処理応答メッセージに関するイベント、並びに複数の業務アプリケーションシステム７、８との通信の結果発生する処理要求・処理応答メッセージに関するイベントが発生した場合に、ワークフローエンジン２９がどのような状態になり、どのような処理要求、処理応答メッセージを発するかを規定している。

ワークフローエンジン３２の挙動は、ワークフローシステム２に含まれるワークフロー定義（記号：Wf定義_２）３４で定義される。ワークフロー定義３４は、分散配置されている他のワークフローシステム１、Proxyシステム４を介して通信されるワークフローシステム３からの処理要求、処理応答メッセージに関するイベント、並びに複数の業務アプリケーションシステム９、１０との通信の結果発生する処理要求、処理応答メッセージに関するイベントが発生した場合に、ワークフローエンジン３２がどのような状態になり、どのような処理要求、処理応答メッセージを発するかを規定している。

ワークフローエンジン３７の挙動は、ワークフローシステム３に含まれるワークフロー定義（記号：Wf定義_３）３９で定義される。ワークフロー定義３９は、ワークフローシステム１、ワークフローシステム２からProxyシステム４を介して通信される処理要求、処理応答メッセージに関するイベント、並びに複数の業務アプリケーションシステム１１、１２からProxyシステム４を介して通信される処理要求、処理応答メッセージに関するイベントが発生した場合に、ワークフローエンジン３７がどのような状態になり、どのような処理要求、処理応答メッセージを発するかを規定している。なお、ワークフローシステム３は、独自実装の他社・既存ワークフローエンジンであることを想定しているため、ワークフロー定義３９は、標準化された形式（例えば、WS-BPEL及びWSDL）で記述されるとは限らない。その場合、後述するWf定義・サービス定義取得部５５が、それらを標準化された形式に変換する。

ワークフローシステム１で発生する処理要求、処理応答メッセージに関するイベントは、ワークフローシステム１内に点在する複数のイベント抽出部により検出される。データ通信部１３とアダプタ１９との間の通信は、アダプタ１９内に組み込まれたMsgイベント抽出部２５によって全て検出される。同様に、データ通信部１４とアダプタ２０との間の通信は、アダプタ２０内に組み込まれたMsgイベント抽出部２６によって全て検出される。ワークフローエンジン２９の挙動は、Ｅｎｇイベント抽出部３０によって検出される。

Msgイベント抽出部２５、Msgイベント抽出部２６、Ｅｎｇイベント抽出部３０によって抽出されたイベント情報は、ワークフローシステム１内のイベントデータ保持部４０に一時的の保管され、適宜、共通データ送信部４１により、分散ワークフローモニタシステム５に転送される。

ワークフローシステム２で発生する処理要求、処理応答メッセージに関するイベントは、ワークフローシステム２内に点在する複数のイベント抽出部により検出される。データ通信部１５とアダプタ２１との間の通信は、アダプタ２１内に組み込まれたMsgイベント抽出部２７によって全て検出される。同様に、データ通信部１６とアダプタ２２との間の通信は、アダプタ２２内に組み込まれたMsgイベント抽出部２８によって全て検出される。ワークフローエンジン３２の挙動は、Ｅｎｇイベント抽出部３３によって検出される。

Msgイベント抽出部２７、Msgイベント抽出部２８、Ｅｎｇイベント抽出部３３によって抽出されたイベント情報は、ワークフローシステム２内のイベントデータ保持部４２に一時的に保管され、適宜、共通データ送信部４３により、分散ワークフローモニタシステム５に転送される。

ワークフローシステム３で発生する処理要求、処理応答メッセージに関するイベント群の収集は、独自実装の他社・既存ワークフローエンジンであるため、ワークフローシステム１や２とは処理方式が異なる。データ通信部１７とアダプタ２３との間の通信は、プロキシ部３５を介して行なわれる。そのため、発生する処理要求、処理応答メッセージに関するイベントは、Proxyシステム４内のプロキシ部３５に連結された、Ｐｒｘイベント抽出部３６によって検出される。データ通信部１８とアダプタ２４との間の通信で、発生する処理要求、処理応答メッセージに関するイベントも、Ｐｒｘイベント抽出部３６によって検出される。

Ｐｒｘイベント抽出部３６によって抽出されたイベント情報は、Proxyシステム４内のイベントデータ保持部４５に一時的に保管される。

これに対して、ワークフローエンジン３７の挙動は、ワークフローシステム３内に配置されたEngイベント抽出部３８によって検出され、共通データ送信部４７に一時的に保存される。その後、ワークフローシステム３内に一時的に保存されたイベントに関するデータは共通データ送信部４７によって適宜、Proxyシステム４へ送信される。

その後、Proxyシステム４は、自身の共通データ受信部４６を用いて、上記のイベントに関するデータを収集し、Proxyシステム４内のイベントデータ保持部４５に一時的に保管する。

イベントデータ保持部４５に一時的に保管した、イベントに関する全てのデータは、適宜、共通データ送信部４４により、分散ワークフローモニタシステム５に転送される。

分散ワークフローモニタシステム５は、ワークフロー定義３１、ワークフロー定義３４、ワークフロー定義３９を受信し、一部変換を施すWf定義・サービス定義取得部５５、並びにWf定義・サービス定義取得部５５が得た全てのワークフロー定義から、統合されたワークフロー定義を合成するWf合成部４８、当該合成したワークフロー定義を格納管理する合成Wf定義５０を含む。

特にWf定義・サービス定義取得部５５は、外部に置かれたリポジトリ５６へのアクセスが可能である。

更に、分散ワークフローモニタシステム５は、ワークフローシステム１、ワークフローシステム２、並びにProxyシステム４からイベントに関する全てのデータを受信するイベントデータ受信部４９、統合・合成したワークフロー定義を格納管理する合成Wf定義５０を参照し、イベントデータ受信部４９が受ける全てのイベントデータを整理、関係付ける（イベントの出生死滅の因果関係を定義する）処理を行うイベントデータ関係付け部５１、関連付けのなされたイベントデータを保持するイベント格納ＤＢ５２を含む。イベントデータ同士を関係付ける処理については後段で詳細に説明する。

更に、分散ワークフローモニタシステム５は、統合・合成したワークフロー定義を格納管理する合成Wf定義５０内のデータに対し、業務に関連したラベルを定義、命名するアプリケーションであるAPラベル入力部５８、合成Wf定義５０を基に、ある該当条件のイベントデータを検索するアプリケーションである検索機能部５３、検索機能部５３の戻す結果を基に合成Wf定義５０内のデータに関連付け、イベントデータを時系列に並べて表示するためのトラッキング表示作成部５４、更にイベント格納ＤＢ５２に格納管理されたデータを基に統計処理、評価処理を行うバッチ処理部５９をも含む。なお、バッチ処理部５９の動作（データベースに蓄積されたデータを基に、統計・評価処理を行う動作）は、従来公知の動作と同様であるため、これに関しては詳細な説明を割愛する。

APラベル入力部５８の操作は１台以上のクライアントサイト６０を介して行われ、クライアントサイト６０にWebブラウザによって表示された画面（各種イベントに意味付けを定義するための画面）を用いて行われる。

また、検索機能部５３、トラッキング表示作成部５４の操作は、１台以上のクライアントサイト６を介して行われ、クライアントサイト６にWebブラウザによって表示された画面を用いて行われる。

〔動作の説明〕
図２に、分散配置された通常のワークフローエンジンからイベント情報を収集する際の手順概要を示す。

ワークフローエンジン２９が、業務アプリケーションシステム７と通信をする場合、ワークフロー定義３１に基づき、アダプタ１９に、処理要求メッセージC1を送付する。処理要求メッセージC1は、Webサービス等で成される場合もあり、XML等を用いて、定義される。

アダプタ１９では、処理要求メッセージC1を、業務アプリケーションシステム７が受け入れられるような通信プロトコル、並びに手順に変換し、新たな処理要求メッセージC2として、業務アプリケーションシステム７内の、データ通信部１３に送付する。

データ通信部１３は、処理要求メッセージC2を受理し、業務アプリケーションシステム７に引き渡す。その結果、必要であれば、新たな処理応答メッセージC3が生成され、データ通信部１３からアダプタ１９送信される。

アダプタ１９は、受信した処理応答メッセージC3を、予め規定されている通信プロトコル、並びに手順に変換し、処理応答メッセージC４としてワークフローエンジン２９へ送信する。

ワークフローエンジン２９は、ワークフロー定義３１に基づき、次の挙動を決定する。その結果、業務アプリケーションシステム８と通信をする場合、ワークフロー定義３１に基づき、今度はアダプタ２０に処理要求メッセージC5を送付する。処理要求メッセージC5も、Webサービス等で成される場合もあり、XML等を用いて、定義される。

アダプタ２０では、処理要求メッセージC5を、業務アプリケーションシステム８が受け入れられるような通信プロトコル、並びに手順に変換し、新たな処理要求メッセージC6として、業務アプリケーションシステム８内のデータ通信部１４へ送付する。

データ通信部１４は、処理要求メッセージC6を受理し、業務アプリケーションシステム８に引き渡す。その結果、必要であれば、新たな処理応答メッセージC7が生成され、データ通信部１４からアダプタ２０に送信される。

アダプタ２０は、処理応答メッセージC7を予め規定されている通信プロトコル、並びに手順に変換し、処理応答メッセージC８として、ワークフローエンジン２９へ送信する。

ワークフローエンジン２９は、ワークフロー定義３１に基づき、次の挙動を決定するが、その挙動の一つとしてワークフローシステム２と通信をする場合がある。その場合、ワークフロー定義３１に基づき、今度はワークフローシステム２へ処理要求メッセージC21を送付する。処理要求メッセージC21も、Webサービスなどで成される場合もあり、XMLなどを用いて、定義される。

処理要求メッセージC21に応じて処理応答メッセージC22が送信されてきた場合、ワークフローエンジン２９はこれを受信する。

ワークフローシステム１で発生する処理要求、処理応答メッセージに関するイベントは、ワークフローシステム１内に点在する複数のイベント抽出部により抽出される。具体的には、アダプタ１９には、Msgイベント抽出部２５が組み込まれている。

Msgイベント抽出部２５は、アダプタ１９が処理要求メッセージC1を受信した段階で、これを検出し、メッセージに関するイベントC17としてイベントデータ保持部４０に記録する。また、Msgイベント抽出部２５は、アダプタ１９が、処理要求メッセージC1を業務アプリケーションシステム７が受け入れられるような通信プロトコル、並びに手順に変換し、処理要求メッセージC2として送信した段階で、これを検出し、メッセージに関するイベントC18としてイベントデータ保持部４０に記録する。

同様に、Msgイベント抽出部２５は、アダプタ１９が処理応答メッセージC3をデータ通信部１３から受信した段階で、これを検出し、メッセージに関するイベントC19としてイベントデータ保持部４０に記録する。また、Msgイベント抽出部２５は、アダプタ１９が、処理応答メッセージC3を変換して、処理応答メッセージC4とし、ワークフローエンジン２９に送付した段階で、これを検出し、メッセージに関するイベントC20としてイベントデータ保持部４０に記録する。

同様に、アダプタ２０には、Msgイベント抽出部２６が組み込まれている。

Msgイベント抽出部２６は、Msgイベント抽出部２５はと同じ要領で、処理要求メッセージC5を検出し、メッセージに関するイベントC13としてイベントデータ保持部４０に記録する。加えて、処理要求メッセージC6を検出し、メッセージに関するイベントC14としてイベントデータ保持部４０に記録する。更に、処理応答メッセージC7を検出し、メッセージに関するイベントC15としてイベントデータ保持部４０に記録する。最後に処理応答メッセージC8を検出し、メッセージに関するイベントC16としてイベントデータ保持部４０に記録する。

ワークフローエンジン２９の挙動は、Engイベント抽出部３０によって検出される。ワークフローエンジン２９から発生したメッセージ、並びに受理されたメッセージに関する一連のイベントは全て、Engイベント抽出部３０が扱う。

例えば、アダプタ１９に引き渡された処理要求メッセージC1はEngイベント抽出部３０で検出し、エンジンにおけるメッセージに関するイベントC9としてイベントデータ保持部４０に記録する。同様に、アダプタ１９から引き渡された処理応答メッセージC4をEngイベント抽出部３０で検出し、エンジンにおけるメッセージに関するイベントC10としてイベントデータ保持部４０に記録する。

更に、アダプタ２０に引き渡された処理要求メッセージC5はEngイベント抽出部３０で検出し、エンジンにおけるメッセージに関するイベントC11としてイベントデータ保持部４０に記録する。同様に、アダプタ２０から引き渡された処理応答メッセージC8をEngイベント抽出部３０で検出し、エンジンにおけるメッセージに関するイベントC12としてイベントデータ保持部４０に記録する。

更に、別のワークフローシステム２と通信をする場合も同様に扱う。ワークフローシステム２に送付した処理要求メッセージC21はEngイベント抽出部３０で検出し、エンジンにおけるメッセージに関するイベントC23としてイベントデータ保持部４０に記録する。また、処理要求メッセージC21の結果として戻される処理応答メッセージC22もEngイベント抽出部３０で検出し、エンジンにおけるメッセージに関するイベントC24としてイベントデータ保持部４０に記録する。

ワークフローシステム１内のイベントデータ保持部４０に記録されたイベントデータ（Msgイベント抽出部２５で記録されたメッセージに関するイベントであるC17、C18、C19、C20、及びMsgイベント抽出部２６で記録されたメッセージに関するイベントであるC13、C14、C15、C16、並びにＥｎｇイベント抽出部３０で検出し、エンジンにおけるメッセージに関するイベントであるC9、C10、C11、C12、C23、C24）の各々は、一時的の保管され、その後、これを基にした所定のフォーマットのイベントデータ転送メッセージC25が共通データ送信部４１によって作成され、分散ワークフローモニタシステム５へ適宜、転送される。

分散ワークフローモニタシステム５には、イベントに関する全てのデータを受信するイベントデータ受信部４９が存在しており、イベントデータ転送メッセージC25を受理する。

次に図３を用い、独自実装の他社・既存ワークフローエンジンからＰｒｏｘｙシステムを介してイベント情報を収集する際の手順概要を説明する。

ワークフローエンジン３７が、業務アプリケーションシステム１１と通信をする場合、ワークフロー定義３９に基づき、アダプタ（記号：AD1_E）２３に、処理要求メッセージC30を送付する。処理要求メッセージC30は、Webサービス等で成される場合もあり、XMLなどを用いて定義されるが、ここではワークフローシステム３は、独自実装の他社・既存ワークフローエンジンであることを想定しているため、データ通信部１７とアダプタ２３との間の通信、並びにデータ通信部１８とアダプタ２４との間の通信は、Proxyシステム４内のプロキシ部３５を介して実現され、必ずしもWebサービス等で成されるとは限らない。

アダプタ２３では、処理要求メッセージC30を、業務アプリケーションシステム１１が受け入れられるような通信プロトコル、並びに手順に変換し、新たな処理要求メッセージC31として、業務アプリケーションシステム１１内の、データ通信部１７に向けて送付する。

業務アプリケーションシステム１１へのメッセージの送付は、Proxyシステム４内のプロキシ部３５を介して実現されるため、一度、プロキシ部３５が処理要求メッセージC31を受け、更にデータ通信部１７に向けて、処理要求メッセージC32として送信する。

データ通信部１７は、処理要求メッセージC32を受理し、業務アプリケーションシステム１１に引き渡す。その結果、必要であれば、新たな処理応答メッセージC33が生成され、データ通信部１７からアダプタ２３に向けて送信される。

業務アプリケーションシステム１１からワークフローシステム３へのメッセージの送付の場合も、Proxyシステム４内のプロキシ部３５を介して実現されるため、一度、プロキシ部３５が処理応答メッセージC33を受け、更にアダプタ２３に向けて、処理応答メッセージC34として送信する。

アダプタ２３は、処理応答メッセージC34を予め規定されている通信プロトコル、並びに手順に変換し、処理応答メッセージC35として、ワークフローエンジン３７に送付する。

ワークフローエンジン３７は、ワークフロー定義３９に基づき、次の挙動を決定する。その結果、業務アプリケーションシステム１２に通信をする場合、ワークフロー定義３９に基づき、ワークフローエンジン３７は今度はアダプタ２４に、処理要求メッセージC36を送付する。

アダプタ２４では、処理要求メッセージC36を、業務アプリケーションシステム１２が受け入れられるような通信プロトコル、並びに手順に変換し、新たな処理要求メッセージC37として、業務アプリケーションシステム１２内の、データ通信部１８に向けて送付する。

業務アプリケーションシステム１２へのメッセージの送付は、Proxyシステム４内のプロキシ部３５を介して実現されるため、一度、プロキシ部３５が処理要求メッセージC37を受け、更にデータ通信部１８に向けて、新処理要求メッセージC38として送信する。

データ通信部１８は、処理要求メッセージC38を受理し、業務アプリケーションシステム１２に引き渡す。その結果、必要であれば、新たな処理応答メッセージC39が生成され、データ通信部１８からアダプタ２４に向けて応答される。

この場合も、送付の際は、Proxyシステム４内のプロキシ部３５を介して実現されるため、一度、プロキシ部３５が処理応答メッセージC39を受け、更にアダプタ２４に向けて、新処理応答メッセージC40として送付し直す。

アダプタ２４は、新処理応答メッセージC40を予め規定されている通信プロトコル、並びに手順に変換し、処理応答メッセージC41として、ワークフローエンジン３７に戻す。

ワークフローエンジン３７は、ワークフロー定義３９に基づき、次の挙動を決定するが、挙動の一つとしてワークフローシステム２と通信をする場合がある。その場合、ワークフロー定義３９に基づき、今度はワークフローシステム２に処理要求メッセージC48を送付する。処理要求メッセージC48は、Webサービス等で成されるとは限らず、任意の表現にて、定義される。

処理要求メッセージC48の結果は、処理応答メッセージC49として、ワークフローエンジン３７に戻される。

ワークフローシステム３で発生する処理要求、処理応答メッセージに関するイベント群の検出は、独自実装の他社・既存ワークフローエンジンであるため、通常の処理方式とは異なる方法が採用される。

データ通信部１７とアダプタ２３との間の通信は、プロキシ部３５を介して行なわれる。そのため、発生する処理要求、処理応答メッセージに関するイベントは、Proxyシステム４内のプロキシ部３５に連結された、Prxイベント抽出部３６によって検出される。データ通信部１８とアダプタ２４との間の通信で、発生する処理要求、処理応答メッセージに関するイベントも、Prxイベント抽出部３６によって検出される。

Prxイベント抽出部３６は、アダプタ２３が処理要求メッセージC31を送信し、プロキシ部３５が受信し、それをデータ通信部１７に向けて、C32として送信した段階で、これを検出し、メッセージに関するイベントC50としてイベントデータ保持部４５に記録する。また、Prxイベント抽出部３６は、データ通信部１７が処理応答メッセージC33を送信し、プロキシ部３５が受信し、それをアダプタ２３に向けてC34として送信した段階で、これを検出し、メッセージに関するイベントC51としてイベントデータ保持部４５に記録する。

同様に、Prxイベント抽出部３６は、アダプタ２４が処理要求メッセージC37を送信し、プロキシ部３５が受信し、それをデータ通信部１８に向けて、C38として送信した段階で、これを検出し、メッセージに関するイベントC52としてイベントデータ保持部４５に記録する。また、Prxイベント抽出部３６は、データ通信部１８が処理応答メッセージC39を送信し、プロキシ部３５が受信し、それをアダプタ２４に向けてC40として送信した段階で、これを検出し、メッセージに関するイベントC53としてイベントデータ保持部４５に記録する。

Prxイベント抽出部３６によって抽出されたイベント情報は、Proxyシステム４内のイベントデータ保持部４５に一時的の保管される。

これに対して、ワークフローエンジン３７の挙動は、ワークフローシステム３内に配置されたEngイベント抽出部３８によって検出される。

例えば、アダプタ２３に引き渡された処理要求メッセージC30はEngイベント抽出部３８で検出し、エンジンにおけるメッセージに関するイベントC42として共通データ送信部４７に一時的に記録する。同様に、アダプタ２３から引き渡された処理応答メッセージC35をEngイベント抽出部３８で検出し、エンジンにおけるメッセージに関するイベントC43として共通データ送信部４７に一時的に記録する。

更に、アダプタ２４に引き渡された処理要求メッセージC36はEngイベント抽出部３８で検出し、エンジンにおけるメッセージに関するイベントC44として共通データ送信部４７に一時的に記録する。同様に、アダプタ２４から引き渡された処理応答メッセージC41をEngイベント抽出部３８で検出し、エンジンにおけるメッセージに関するイベントC45として共通データ送信部４７に一時的に記録する。

更に、ワークフローシステム２と通信をする場合も同様に扱う。ワークフローシステム２に送付した処理要求メッセージC48はEngイベント抽出部３８で検出し、エンジンにおけるメッセージに関するイベントC46として共通データ送信部４７に一時的に記録する。また、処理要求メッセージC48の結果として戻される処理応答メッセージC49もEngイベント抽出部３８で検出し、エンジンにおけるメッセージに関するイベントC47として共通データ送信部４７に一時的に記録する。

その後、ワークフローシステム３内に配置された共通データ送信部４７を用いて、イベントに関するデータを、Proxyシステム４に適宜、決められたフォーマットにてイベントデータ転送メッセージC54が作成され、転送される。

その後、Proxyシステム４は、自身の共通データ受信部４６を用いて、イベントに関するイベントデータ転送メッセージC54を受信し、Proxyシステム４内のイベントデータ保持部４５に一時的に保管する。

その後、共通データ送信部４４により、分散ワークフローモニタシステム５に適宜、決められたフォーマットにてイベントデータ転送メッセージC26が作成され、転送される。

分散ワークフローモニタシステム５には、イベントに関する全てのデータを受信するイベントデータ受信部４９が存在しており、イベントデータ転送メッセージC26を受理する。

図４では、分散配置されたワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合・合成されたＷｆ定義を生成する際の手順、並びに統合された当該Ｗｆ定義をメンテナンスする際の手順概要を記す。

ワークフローシステム１に含まれるワークフローエンジン２９の挙動は、ワークフロー定義３１で定義される。通常、ワークフロー定義３１は、ワークフローエンジン２９の挙動のみを記載し、標準化された形式であるWS-BPELとWSDLとを始めとするプロセスの記述等で記載される。

ワークフローシステム２に含まれるワークフローエンジン３２の挙動は、ワークフロー定義３４で定義される。通常、ワークフロー定義３４は、ワークフローエンジン３２の挙動のみを記載し、標準化された形式であるWS-BPELとWSDLとを始めとするプロセスの記述等で記載される。

ワークフローシステム３に含まれるワークフローエンジン３７の挙動は、ワークフロー定義３９で定義される。ここで、ワークフローシステム３は、独自実装の他社・既存ワークフローエンジンであることを想定しているため、ワークフロー定義３９は、標準化された形式であるWS-BPELとWSDLとで記載されるとは限らない。

ワークフロー定義３１は、定義転送メッセージC60として、またワークフロー定義３４は、定義転送メッセージC61として、またワークフロー定義３９は、定義転送メッセージC62として、分散ワークフローモニタシステム５内の、Wf定義・サービス定義取得部５５に適宜、転送される。

Wf定義・サービス定義取得部５５が、定義転送メッセージC60、C61、C62を受信すると、その形式を判断する。もし、標準化された形式（例えば、WS-BPELとWSDL）で定義されていない定義転送メッセージ（ここではC62）を受信すると、Wf定義・サービス定義取得部５５が標準化された形式（例えば、WS-BPELとWSDL）に変換し、保持する。

図５は、Ｗｆ定義の一つの表現形式を記した図であり、WS-BPELとWSDとの記述例を記したものである。標準化されていないワークフロー定義３９でも、通常はほぼ等価な情報項目を持つことが一般的である。

図５でプロセス定義D1は一つのWS-BPELのインスタンスとして記載される。プロセス定義D1は、定義部D3、アクティビティ部D4、D5、D6を含んで構成される。

アクティビティ部D4、D5、D6は、該当するメッセージを受信した場合の挙動を定義するアクティビティ部D4、実際の業務ロジックに相当する挙動を定義するアクティビティ部D5、該当するメッセージを往信する場合の挙動を定義するアクティビティ部D6に分類される。

これに対して、具体的なサービス定義D2は、一つのWSDLのインスタンスとして記載される。サービス定義D2は、プロセス定義D1と直接関係するもの、並びに独立に記載されるものの２種類が存在する。

サービス定義D2は、サービスを呼び出す場合のメッセージ形式、サービスを呼び出したことで発生する往信メッセージの形式を定義するメッセージ定義部D7、メッセージ定義部D7を使って実際のインタフェースを定義するポート定義部D8、ポート定義部D8を実際のトランスポートに対応付けるバインディング部D9、バインディング部D9等を使ってサービスとして定義するサービス定義部D10を含んで構成される。

メッセージを受信した場合の挙動を定義するアクティビティ部D4で、任意のサービスを特定する場合、そのサービスに相当するサービス定義D2のポート定義部D8を参照することになる。同様にメッセージを往信する場合の挙動を定義するアクティビティ部D6や、実際の業務ロジックに相当する挙動を定義するアクティビティ部D5で、任意のサービスを特定する場合、間接的に当該サービスに相当するサービス定義D2のポート定義部D８を参照することになる。

図５のサービス定義D2、プロセス定義D1は通常、計算機可読の表現で記載され、意味的な情報を直接含むことは少ない。

その後、Wf定義・サービス定義取得部５５は、取得、もしくは変換にて得た標準化された形式（例えば、WS-BPELとWSDL）によるワークフロー定義３１、３４、３９の全てを保持する。その場合、外部に置かれたリポジトリ５６にて保存しても良い。

分散ワークフローモニタシステム５内には、Wf定義・サービス定義取得部５５が得た、全てのワークフロー定義３１、３４、３９等から、統合されたワークフロー定義を合成するWf合成部４８、当該合成したワークフロー定義を格納管理する合成Wf定義５０が存在する。

Wf合成部４８は、要素となる全てのワークフロー定義を得るため、Wf定義・サービス定義取得部５５を随時起動する。Wf定義・サービス定義取得部５５は、既に内部で保持している要素となる全てのワークフロー定義情報を入手するとともに、リポジトリ５６に対して、問い合わせC74を実施し、要素となる残りの全てのワークフロー定義情報をも入手する。

その後、Wf定義・サービス定義取得部５５は、全てのワークフロー定義情報C75を、Wf合成部４８に引き渡す。Wf合成部４８は、図６〜図１１に記された手順で、統合・合成されたワークフロー定義C63を生成しそれを、合成Wf定義５０に渡す。

ワークフローシステム１の各種イベント抽出部によって抽出されたイベント情報は、ワークフローシステム１内のイベントデータ保持部４０に一時的に保管され、適宜、共通データ送信部４１により、イベントデータ転送メッセージC25として分散ワークフローモニタシステム５に転送される。分散ワークフローモニタシステム５では、その内部にあり、イベントに関する全てのデータを受信するイベントデータ受信部４９がイベントデータ転送メッセージC25を受信する。

ワークフローシステム２の各種イベント抽出部によって抽出されたイベント情報は、ワークフローシステム２内のイベントデータ保持部４２に一時的に保管され、適宜、共通データ送信部４２により、イベントデータ転送メッセージC25’として分散ワークフローモニタシステム５に転送される。分散ワークフローモニタシステム５では、イベントデータ受信部４９がイベントデータ転送メッセージC25’を受信する。

これに対して、Proxyシステム４の各種イベント抽出部によって抽出されたイベント情報は、Proxyシステム４内のイベントデータ保持部４５に一時的に保管される。

また、Proxyシステム４と連携するワークフローシステム３内の各種イベント抽出部によって抽出されたイベント情報は、ワークフローシステム３内の共通データ送信部４７からイベントデータ転送メッセージC54としてProxyシステム４に送付される。

Proxyシステム４には、イベントデータ受信部４６が配置されており、これを用いてイベントデータ転送メッセージC54を受信する。その後、イベントデータ転送メッセージC54に記載された全てのイベント情報は、イベントデータ保持部４５に一時的に保管される。

イベントデータ保持部４５内に一時的に保管した、イベントに関する全てのデータは、適宜、共通データ送信部４４により、イベントデータ転送メッセージC26として分散ワークフローモニタシステム５に転送される。分散ワークフローモニタシステム５では、その内部にあり、イベントに関する全てのデータを受信するイベントデータ受信部４９がイベントデータ転送メッセージC26を受信する。

イベントデータ受信部４９は、イベントに関する全てのデータC64を、イベントデータ関係付け部５１に引き渡す。イベントデータ関係付け部５１は、統合・合成したワークフロー定義を格納管理する合成Wf定義５０を参照し、その内部に管理されているサービス定義・プロセス定義情報C67を検索、参照しながら、イベントに関する全てのデータC64の各々が、どのサービス・プロセスのメッセージインスタンスに相当するかを整理、関係付け、かつ現在、イベント格納ＤＢ５２にて管理されているメッセージインスタンス群C66を検索の上で、関係付ける。その後、新たなメッセージインスタンスC65のレコードとしてイベント格納ＤＢ５２に格納する。この処理については、後段で図１２を用いて詳細に説明する。

合成Wf定義５０に管理されるサービス定義・プロセス定義情報は、図５に記載されるようなプロセス定義D1、定義部D3、アクティビティ部D4、D5、D6、サービス定義D2、メッセージ定義部D7、ポート定義部D８、バインディング部D9、サービス定義部D10等を含んで構成される。これらは、上記のように計算機可読の表現で記載され、意味的な情報（人間が理解可能な形式の情報）を直接含むことは少ない。

このため、分散ワークフローモニタシステム５には、合成Wf定義５０に管理されるサービス定義・プロセス定義情報にアプリケーション上の表現（人間が理解可能な形式の情報）を追加するため、APラベル入力部５８が存在する。

主にシステム管理者である利用者は、１台以上のクライアントサイト６０を起動することで、ＡＰラベル入力部５８を操作することになる。

図１３は、ＡＰラベル入力部５８の処理によってクライアントサイト６０に表示される画面（各種イベントに意味付けを定義するための画面）の概要図である。図示するのは、クライアントサイト６０上に表示され、ＡＰラベル入力部５８に所属し、各種イベントに意味付けを定義するための画面である。Webブラウザ６１の上に統合・合成したワークフロー定義全体を表示する画面フレーム６２と入力用の画面フレーム６４とが表示される。

画面フレーム６２には、統合・合成したワークフロー定義全体を構成するプロセス定義D1の全てのもの、該プロセス定義に所属するアクティビティ部の全て、並びに該アクティビティ部間の関係を定義する全てのサービス定義をもとにしたグラフ構造を意味する図が表示される。

入力用の画面フレーム６４には、表形式の入力欄が表示され、アクティビティ部のインスタンスに対応する表示名の入力欄６５、アクティビティ部のインスタンスに対応する意味の入力欄６６、並びにOKボタン６７、キャンセルボタン６８を含んで構成される。

利用者が、クライアントサイト６０上のWebブラウザ６１の上で操作すると、合成Wf定義５０に管理されるサービス定義・プロセス定義情報が、ＡＰラベル入力部５８を介して、画面フレーム６２上に表示される。画面フレーム６２上のグラフ構造から、あるアクティビティ部のインスタンスに対応するノードを一つ選択する。すると、入力用の画面フレーム６４が表示される。ここでの入力欄で、先に選択したノードに対応するアクティビティ部のインスタンスに対して定義名と意味とを自然言語表現にて入力し、OKボタン６７を押下する。

このような操作を行うと、定義名・意味情報C77が、ＡＰラベル入力部５８に送付される。ＡＰラベル入力部５８が一度、定義名・意味情報C77を入手すると、合成Wf定義５０に管理されるサービス定義・プロセス定義情報から、アクティビティ部のインスタンスに相当するものを選び出し、当該インスタンスに関係付けるように定義名・意味情報C78を合成Wf定義５０に格納する。

バッチ処理部５９は、指定された時間ごとに起動し、イベント格納ＤＢ５２に格納管理されたメッセージインスタンスのレコードに対して適宜検索を掛けていく。特に指定の統計処理に必要なメッセージインスタンスのレコード群C80を取り出し、内部での計算において入力値として用いる。

バッチ処理部５９は、指定の統計処理計算が終了した段階で、その結果値C79をイベント格納ＤＢ５２に格納する。そのようにすることで、トラッキングなどでそれらの統計データを用いることが可能となる。

システム管理者である利用者は、１台以上のクライアントサイト６を起動することで、統合されたＷｆ定義を表示する、もしくは統合されたＷｆ定義上で流通するイベント群を表示することが可能である。図１４〜１７は、当該クライアントサイト６上に表示される画面の構成であり、検索機能部５３、トラッキング表示作成部５４に所属し、統合されたＷｆ定義を表示する、もしくは統合されたＷｆ定義上で流通するイベント群を表示するための画面概要図である。

図１４は、クライアントサイト６上に表示され、検索機能部５３に所属し、統合されたＷｆ定義を検索するための画面概要図である。Webブラウザ７６の上に、統合プロセス定義名を検索する際の指定入力欄７１、検索ボタン６９、リスト表示ボタン７０、OKボタン７４、キャンセルボタン７５、複数エントリからなる統合プロセス定義名の一覧、当該統合プロセス定義名の一覧から一つの統合プロセス定義名を選択するため、各々のエントリに付与されたチェックボックス群７３、並びにマウスポインタ７２を含んで構成される。

図１４の画面で、統合プロセス定義名を検索する際の指定入力欄７１に検索文字列を入れ、検索ボタン６９を押下する、もしくはリスト表示ボタン７０を押下すると、図４に示したように、クライアントサイト６から分散ワークフローモニタシステム５にWf定義検索メッセージC68が転送される。その後、検索機能部５３がWf定義検索メッセージC68を受け取った後、合成Wf定義５０に対して、検索問い合わせを実施し、検索結果C70を得る。その後、検索機能部５３は検索結果C90をクライアントサイト６に戻し、Webブラウザ７６に表示する。

また、図１４の画面上の統合プロセス定義名の一覧から一つ選択し、そのエントリに付与されたチェックボックス７３にチェックの後、OKボタン７４を押下する。すると、図４に示したように、クライアントサイト６から分散ワークフローモニタシステム５にWf定義要求メッセージC91が転送される。その後、検索機能部５３がWf定義要求メッセージC91を受け取った後、合成Wf定義５０に対して、検索問い合わせを実施し、問い合わせ結果C92を得る。

その後、検索機能部５３は、イベント格納ＤＢ５２に状況状態の確認問い合わせC69を行った後、トラッキング表示作成部５４に必要な起動情報引数C71を渡し、これを起動する。トラッキング表示作成部５４は起動後、合成Wf定義５０からプロセス定義情報他の描画に必要な情報C81を受ける。その後、トラッキング表示作成部５４は当該表示データC73をクライアントサイト６に戻し、図１５の画面をWebブラウザ７７に表示する。

図１５は、クライアントサイト６上に表示され、トラッキング表示作成部５４に所属し、統合されたＷｆ定義をビジュアルに表示するための画面概要図である。

図１５の画面では、Webブラウザ７７の上に、業務アプリケーションシステム７、８等を意味し、ネットワーク上のロケーション情報と合わせて表示するラベル群８０、Wf定義上のプロセス定義を出生死滅の存在する時系列表示したシンボル群、当該プロセス定義に所属するアクティビティ部間の関係をメッセージによる通信、矢印として表現するサービス定義に関するシンボル群８２、サービス定義をズームアップできるように、各々のシンボル８２に付与されたチェックボックス群８１、ズームアップを指定する詳細表示ボタン７９、Wf定義の指定箇所に相当するプロセスに関連するメッセージインスタンスのレコード群をイベント格納ＤＢ５２から検索するためのフォーカスボタン７８、Ｗｆ定義配下のプロセスに関連するメッセージインスタンスのレコード群一覧をリストアップ表示するための画面フレームを含んで構成される。なお、リストアップ表示するための画面フレームは表示されない場合もある。

図１５の画面にて、ズームアップ処理をするため、あるシンボル８２に付与されたチェックボックス８１にチェックし、ズームアップを指定する詳細表示ボタン７９を押下する。すると、図４に示したように、クライアントサイト６から分散ワークフローモニタシステム５にWf定義要求メッセージC91が転送される。その後、検索機能部５３がWf定義要求メッセージC91を受け取った後、合成Wf定義５０に対して、検索問い合わせを実施し、問い合わせ結果C92を得る。

その後、検索機能部５３は、イベント格納ＤＢ５２に状況状態の確認問い合わせC69を行った後、トラッキング表示作成部５４に必要な起動情報引数C71を渡し、これを起動する。トラッキング表示作成部５４は起動後、合成Wf定義５０からプロセス定義情報他の描画に必要な情報C81を受ける。その後、トラッキング表示作成部５４は表示データC73をクライアントサイト６に戻し、図１６の画面をWebブラウザ８３に表示する。

図１６は、クライアントサイト６上に表示され、トラッキング表示作成部５４に所属し、統合されたＷｆ定義の詳細をビジュアル表示するとともに、Ｗｆ定義配下のプロセスのインスタンスの一覧をリストアップ表示するための画面概要図である。
Webブラウザ８３の上に業務アプリケーションシステム７、８等を意味し、ネットワーク上のロケーション情報と合わせて表示するラベル群８４、Wf定義上のプロセス定義を出生死滅の存在する時系列表示したシンボル群、当該プロセス定義に所属するアクティビティ部間の関係をメッセージによる通信、矢印として表現するサービス定義に関するシンボル群８８を含んで構成され、図１５のものよりも、より細密に表現される。

更に図１６の画面では、各々のシンボル８８に付与されたチェックボックス群８９、図１３の画面フレーム６４で入力され、合成Wf定義５０で管理されているアクティビティ部のインスタンスに対応する定義名・意味情報によるラベル群８７、キャンセルボタン８６、Wf定義の指定箇所に相当するプロセスに関連するメッセージインスタンスのレコード群をイベント格納ＤＢ５２から検索するためのフォーカスボタン８５、Ｗｆ定義配下のプロセスに関連するメッセージインスタンスのレコード群一覧をリストアップ表示するための画面フレーム、マウスポインタ９３を含んで構成される。

リストアップ表示するための画面フレームには、指定されたＷｆ定義配下のプロセスに関連するメッセージインスタンスのレコード群のリスト表示９４、とその各々に付与されたチェックボックス群９２、選択結果を意味するOKボタン９０、キャンセルボタン９１を含んで構成される。

図１６のリストアップ表示するための画面フレーム上のチェックボックス群９２にマウスポインタ９３を持って行き、チェックの後、選択結果を意味するOKボタン９０を押下すると、図１７の画面に遷移することになる。

図１６のリストアップ表示するための画面フレーム上のチェックボックスの一つ９２にマウスポインタ９３を持って行き、チェックの後、選択結果を意味するOKボタン９０を押下する。すると、図４に示したように、クライアントサイト６から分散ワークフローモニタシステム５にWf定義詳細情報要求メッセージC93が転送される。

その後、トラッキング表示作成部５４がWf定義詳細情報要求メッセージC93を受け取った後、イベント格納ＤＢ５２に対して、詳細問い合わせを実施し、詳細問い合わせ結果C72を得る。その後、トラッキング表示作成部５４は当該詳細問い合わせ結果データC94をクライアントサイト６に戻し、図１７の画面をWebブラウザ95に表示する。

図１７は、クライアントサイト６上に表示され、検索機能部５３に所属し、図１６でＷｆ定義配下のプロセスに関連するメッセージインスタンスのレコード群一覧をリストアップ表示されたものから一つ選択し、そこに付与された統計データ詳細を表示するための画面概要図である。

図１７の画面では、Webブラウザ９５の上に、図１６上で選択されたプロセスに関連するメッセージインスタンスのレコードに関する情報９６を表示するとともに、当該レコードに関連する全ての統計データ詳細を表示するフレーム９７、OKボタン９８、キャンセルボタン９９を含んで構成される。

図６は、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集した後、統合されたＷｆ定義との関係を記した図である。また、図７〜図１１は、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合されたＷｆ定義を生成するための手順と原理を記した図である。

図６で、Wf定義・サービス定義取得部５５を随時起動すると、既に内部で保持しているワークフロー定義３１、ワークフロー定義３４の他、ワークフロー定義３９のように、他の形式から変換したワークフロー定義、更に不図示の別のワークフローシステムからも他のワークフロー定義（記号：Wf定義_N）を入手する。加えて、リポジトリ５６に対して、問い合わせC74を実施し、統合後のワークフローの要素となりうる残りの全てのワークフロー定義情報をも入手する。なお、リポジトリ５６に対する問い合わせC74は、処理開始前に予め全て実施してしまっても良いし、必要に応じてその都度処理中に実施しても良い。

ワークフロー定義３１の内、ワークフローエンジンの挙動のみを記載し、標準化された形式であるWS-BPELの部分を図６〜図１２ではD20と表記する。これに対して、WSDLを始めとする部分を図６〜図１２ではD21と表記する。

ワークフロー定義３４の内、ワークフローエンジンの挙動のみを記載し、標準化された形式であるWS-BPELの部分を図６〜図１２ではD22と表記する。これに対して、WSDLを始めとする部分を図６〜図１２ではD23と表記する。

同様に他のワークフローエンジンの挙動のみを記載し、標準化された形式であるWS-BPELの部分を図６〜図１２ではD24と表記する。これに対して、他のWSDLを始めとする部分を図６〜図１２ではD25、D26、D27、D28と表記する。

図６〜図１２では、図５で定義されたアクティビティ部のうち、該当するメッセージを受信した場合の挙動を定義するアクティビティ部D4をシンボル「Rv」の修飾子、実際の業務ロジックに相当する挙動（他のサービスを呼び出す動作を含む）を定義するアクティビティ部D5をシンボル「ｌ」の修飾子、該当するメッセージを往信する場合の挙動を定義するアクティビティ部D6をシンボル「Rp」の修飾子を付けて表現する。

例えば、ワークフロー定義３１内の、受信した場合の挙動を定義するアクティビティ部は、シンボル「1Rv」で表現される。また、実際の業務ロジックに相当する挙動を定義するアクティビティ部は、シンボル「1l1」で表現される。ここで、業務ロジックに相当する挙動を定義するアクティビティ部は複数定義し得るので、シンボル「1l1」「1l2」と複数出現し得る。また、該当するメッセージを往信する場合の挙動を定義するアクティビティ部、シンボル「1Rp」で表現される。

その後、Wf定義・サービス定義取得部５５は、ワークフローエンジンの挙動のみを記載したWS-BPEL部分と、他のWSDL部分であり、D20、D21、D22、D23、D24、D25、D26、D27、D28に相当する全てのワークフロー定義情報C75-1、C75-2、C75-3、C75-4、C75-5、C75-6、C75-7、C75-8とを、Wf合成部４８に引き渡す。

Wf合成部４８は、順番にそれらを参照して、統合・合成されたワークフロー定義C63を生成し、それを、合成Wf定義５０に渡す。

図７〜図１１では、Wf合成部４８が、統合・合成されたワークフロー定義C63を生成する手順を説明する。
ここで、WS-BPEL部D20の実際の業務ロジックに相当する挙動を定義するアクティビティ部1l1には、別のサービス（D23で指定されるサービス）を呼び出すことが定義されているものとする。また、WS-BPEL部D22の実際の業務ロジックに相当する挙動を定義するアクティビティ部2l1には、別のサービス（D25で指定されるサービス）を呼び出すことが定義されているものとする。さらに、WS-BPEL部D24の実際の業務ロジックに相当する挙動を定義するアクティビティ部3l1には、別のサービス（D26、D28でそれぞれ指定されるサービス）を呼び出すことが定義されているものとする。
また、ワークフローの合成は、予め定義された所定の順序で行われる。ここでは、ワークフロー定義３１、ワークフロー定義３４、ワークフロー定義３９の順で合成するものとする。

まず、Wf合成部４８は、図７に示すように、ワークフロー定義３１に相当するワークフロー定義情報C75-1、C75-5を読み込み、自身のメモリ部に展開する。

この際、ワークフロー定義情報C75-1、C75-5を最初に読み出すことは、予め運用者が定義したルールで指定されている。具体的な一例を挙げると、Wf合成部４８に引き渡される前段階で全てのワークフロー定義の内部を事前評価することで、どのワークフロー定義情報から読み出すのかを指定する方法がある。この事前評価では、各ワークフロー定義内のメッセージを能動的に発するアクティビティ定義数を数え上げ、点数として加点していき、加点された点数が大きいワークフロー定義は、メッセージに関するイベントを能動的な発する確率が高いので、ワークフロー定義を優先的に扱う。

以上の結果、三つのアクティビティ部（受信した場合の挙動を定義するアクティビティ部「1Rv」、実際の業務ロジックに相当する挙動を定義するアクティビティ部「1l1」、該当するメッセージを往信する場合の挙動を定義するアクティビティ部「1Rp」）がメモリ上に展開されることになる。

続けて、Wf合成部４８は、メモリ上に展開したアクティビティ部を順次確認し、起動する。受信した場合の挙動を定義するアクティビティ部「1Rv」に続けて、実際の業務ロジックに相当する挙動を定義するアクティビティ部「1l1」が起動される。アクティビティ部「1l1」は、図５のD5である実際の業務ロジックに相当する挙動を定義するアクティビティ部に相当する。この部分で、INVOKEと記載され、その名称であるname部分に他サービス相当のものが指定されている場合、それは別のサービスを呼び出すことになる。この例では上記のように、アクティビティ部「1l1」にはD23で定義されるサービスが指定されている。そこで、Wf合成部４８は、D23のWSDLを参照するため、C75-1、C75-5に続けてワークフロー定義３４に相当するワークフロー定義情報C75-2、C75-6を読み込み、自身のメモリ部に続けて展開する。

この結果、図８に示すように、新たに三つのアクティビティ部（受信した場合の挙動を定義するアクティビティ部「2Rv」、実際の業務ロジックに相当する挙動を定義するアクティビティ部「2l1」、該当するメッセージを往信する場合の挙動を定義するアクティビティ部「2Rp」）がＷｆ合成部４８のメモリ上に追加展開されることになる。

この場合、アクティビティ部「2Rv」はアクティビティ部「1l1」と、D23のWSDLを介して、呼び出し関係を持っている。そこで、アクティビティ部「1l1」と、受信した場合の挙動を定義するアクティビティ部「2Rv」並びに該当するメッセージを往信する場合の挙動を定義するアクティビティ部「2Rp」の間に呼び出し関係が成立することになる。よってWf合成部４８は、メモリ上にリンク関係を作成する。

Wf合成部４８は、同じ要領でアクティビティ部を順次確認し、起動する。アクティビティ部「1l1」に続けて、該当するメッセージを往信する場合の挙動を定義するアクティビティ部「1Rp」が起動される。また、アクティビティ部「1l1」に対してリンク関係があり、ワークフロー定義３４での受信した場合の挙動を定義するアクティビティ部「2Rv」に続けて、実際の業務ロジックに相当する挙動を定義するアクティビティ部「2l1」が起動される。

アクティビティ部「2l1」も、図５のD5である実際の業務ロジックに相当する挙動を定義するアクティビティ部に相当する。この部分で、INVOKEと記載され、その名称であるname部分に他サービス相当のものが指定されている場合、それは別のサービスを呼び出すことになる。この例では上記のように、アクティビティ部「2l1」にはD25で定義されるサービスが指定されている。そこで、Wf合成部４８は、D25のWSDLを参照するため、C75-2、C75-6に続けてワークフロー定義３９に相当するワークフロー定義情報C75-3、C75-７を読み込み、自身のメモリ部に続けて展開する。

この結果、図９のように、新たに四つのアクティビティ部（受信した場合の挙動を定義するアクティビティ部「3Rv」、実際の業務ロジックに相当する挙動を定義するアクティビティ部「3l1」及び「3l2」、該当するメッセージを往信する場合の挙動を定義するアクティビティ部「3Rp」）がメモリ上に追加展開されることになる。

この場合、アクティビティ部「3Rv」は、D25のWSDLを介してアクティビティ部「2l1」と呼び出し関係を持っている。そこで、アクティビティ部「2l1」と、受信した場合の挙動を定義するアクティビティ部「3Rv」並びに該当するメッセージを往信する場合の挙動を定義するアクティビティ部「3Rp」の間に呼び出し関係が成立することになる。よってWf合成部４８は、メモリ上にリンク関係を作成する。

Wf合成部４８は、同じ要領でアクティビティ部を順次確認し、起動する。アクティビティ部「2l1」に続けて、該当するメッセージを往信する場合の挙動を定義するアクティビティ部「2Rp」が起動される。また、アクティビティ部「2l1」に対してリンク関係があり、ワークフロー定義３９での受信した場合の挙動を定義するアクティビティ部「3Rv」に続けて、実際の業務ロジックに相当する挙動を定義するアクティビティ部「3l1」、並びに「3l2」が起動される。

アクティビティ部「3l1」並びに「3l2」も、ある実際の業務ロジックに相当する挙動を定義するアクティビティ部（図５のD5に示すようなアクティビティ部）に相当する。この部分で、INVOKEと記載され、その名称であるname部分に他サービス相当のものが指定されている場合、それは別のサービスを呼び出すことになる。この例では上記のように、アクティビティ部「3l1」にはD28で定義されるサービスが指定されており、アクティビティ部「3l2」にはD26で定義されるサービスが指定されている。そこでWf合成部４８は、関連するD27も含めてWSDLを参照するためC75-3、C75-7に続けてワークフロー定義情報C75-8を読み込み、D26、D27、D28を自身のメモリ部に続けて展開する。

新たなアクティビティの追加は存在しないが、実際の業務ロジックに相当する挙動を定義するアクティビティ部「3l1」、並びに「3l2」の参照先を関連付けるため、Wf合成部４８はD26、D27、D28を参照する。参照の結果、図１０のように、アクティビティ部「3l1」にはD28で定義されるサービスが指定されている、アクティビティ部「3l2」にはD26で定義されるサービスが指定されていることが確実になった状態で、Wf合成部４８は、この関連を確定し、図１１のように、D27、D28のWSDLに記載事項を自身のメモリ部に展開する。

Wf合成部４８は、サービスの呼び出しに応じて順次WSDLを読み込み、メモリ上へのアクティビティ部の展開や、メモリ上でのリンク関係の作成ができなくなるまで、上記同様の作業を継続する。これ以上、メモリ上へのアクティビティ部の展開や、メモリ上でのリンク関係の作成ができない場合は、メモリ上に展開した各アクティビティ部を、統合・組織化して、統合・合成されたワークフロー定義C63として生成する。

Wf合成部４８は、統合・合成されたワークフロー定義C63を生成した後は、それを恒久的に保存するため、合成Wf定義５０に渡す。合成Wf定義５０では、当該統合・合成されたワークフロー定義C63を保存、格納管理する。なお、合成Wf定義５０では、統合・合成されたワークフロー定義C63は一つだけではなく、独立に複数のものを保存し得る。

図１２は、統合されたＷｆ定義をもとに、各種イベントに関するデータをどのように整理、関係つけて格納するか、の手順と原理を記した図である。これは主に、イベントデータ関係付け部５１に関係する。概略は以下のようになる。

イベントデータ受信部４９は、イベントに関するデータC64’を、イベントデータ関係付け部５１に引き渡すと、これを統合・合成したワークフロー定義を格納管理する合成Wf定義５０を参照する。

合成Wf定義５０内部では、図１２に示すようにサービス定義・プロセス定義情報C67が管理されているため、どのサービス・プロセスのメッセージインスタンスに相当するかを整理、関係付けを検索するため問い合わせC67’を実施し、必要なサービス定義・プロセス定義情報のサブセットC67”を入手・参照する。

続けて、イベント格納ＤＢ５２にて管理されるメッセージインスタンス群C66を検索し、イベントに関するデータC64’が、どのイベントに関するデータの後続イベントに相当するかを特定する。

イベントデータ関係付け部５１は、データ間の必要な関係付けをすべて実施した後、イベントに関するデータC64’を、新たなメッセージインスタンスC65のレコードとしてイベント格納ＤＢ５２に格納する。その際、タイムスタンプ等が記録される。

統合されたＷｆ定義を基に、各種イベントに関するデータを整理、関係つけて格納する動作の一例を以下に記す。ここでは、メッセージに関するイベントであるとして説明する。
イベントデータ関係付け部５１が、イベントに関するデータC64’を受け取る。イベントに関するデータC64’には、イベントID、メッセージインスタンス種類、TimeStamp、イベントの種類等が記載されている。イベントは、メッセージに関するイベント、エンジンにおけるメッセージに関するイベントの両方を、各々識別する形で含んでいる。

イベントに関するデータC64’には、メッセージインスタンス種類が含まれるので、まず、これを確認する。図１２の場合、“２Y”という値を持つ。イベントデータ関係付け部５１は、“２Y”と言う値を基に、どのサービス・プロセスのメッセージインスタンスに相当するかを識別、検索するため、統合・合成したワークフロー定義C63を格納管理する合成Wf定義５０に対して、問い合わせC67’を実施する。

問い合わせC67’を受理した場合、合成Wf定義５０内部では、指定されている先の“２Y”という値を基に、複数管理されている統合・合成されたワークフロー定義C63を検索する。図１２の場合、WSDLがD26、D27、D28に関連するものが唯一であるので、統合・合成されたワークフロー定義C63は一意に決定できる。それを基に関連するサービス定義・プロセス定義情報のサブセットC67”を作成する。この場合、例えば、メッセージインスタンス種類が“１X”、“２X”、“３X”という値を持つことになるので、それらの情報がサービス定義・プロセス定義情報のサブセットC67”に含まれて作成される。その後、サービス定義・プロセス定義情報のサブセットC67”は、イベントデータ関係付け部５１に対して応答として送信される。

イベントデータ関係付け部５１は、サービス定義・プロセス定義情報のサブセットC67”を受理すると、ここに記載されているメッセージインスタンス種類が“１X”、“２X”、“３X”であることを基に、イベント格納DB５２にて管理されるメッセージに関するイベントを検索するため、検索要求を、イベント格納DB５２へ送信する。

図１２では、メッセージインスタンス種類が“１X”を持つメッセージに関するイベント群を２件、メッセージインスタンス種類が“3X”を持つメッセージに関するイベント群を２件引き当てた様子が記されている。

この段階では、メッセージインスタンス種類が“1X”を持つメッセージに関するイベント群、並びにメッセージインスタンス種類が“3X”を持つメッセージに関するイベント群から、該当するもの全てが取り出されてしまうので、イベントに関するデータC64’との関係のあるもののみを更に限定して抽出する。

限定方法については、幾つかの方式が存在する。例えば、グロールメッセージID等を付与する方式や、マイニングロジックで推定する方式がある。

ここでは、タイムスタンプと送信元アドレス、送信アドレス、並びにメッセージのダイジェスト値により規定されるグロールメッセージIDをメッセージの中に組み込み、メッセージに関するイベント群ではイベントデータに、このグロールメッセージIDを組み込む方式を想定している。

このグロールメッセージIDに関する条件を指定する方法により、イベントに関するデータC64‘との関係のあるもののみを、メッセージインスタンス種類が“1X”を持つメッセージに関するイベント群、並びにメッセージインスタンス種類が“3X”を持つメッセージに関するイベント群から取り出すことができる。

その後、それらをメッセージインスタンス群C66としてイベントデータ関係付け部５１に戻す。これにより、イベントに関するデータC64’が、メッセージに関するどのイベントに対する後続イベントに相当するかを特定することができることになる。

イベントデータ関係付け部５１は、他にもデータ間の必要な関係付けを行う必要がある場合、上記と同様な要領でこれを実施する。すべて実施した後、イベントに関するデータC64’を、新たなメッセージインスタンスC65のレコードとして生成する。

そして、メッセージに関するイベントであるメッセージインスタンスC65のレコードとしてイベント格納DB５２に、メッセージインスタンス群C66で戻されたものと関連を取りながら格納する。その際、タイムスタンプ等が記録される。

〔第２の実施形態〕
上記第１の実施形態では、業務プロセスモニタ・トラッキング装置の機能を中心に記載しており、特に構成要素について言及はしていない。そのため、機能的に図１と同等の要素が適用できる場合は、本発明の対象となる。

図２０は、本発明にかかる業務プロセスモニタ・トラッキング装置等をサービスプロバイダ運営体が保持して、サービスとして定義する場合の概要図である。

図２０に記されたサービスプロバイダ運営体１００は、本発明にかかる分散ワークフロー管理方法に基づく業務プロセストラッキング装置を含み、その主要構成要素である、分散ワークフロー管理方式に基づく複数のワークフローシステム１、２、並びに独自実装で、複数配置される他社・既存ワークフローシステム３、並びに当該他社・既存ワークフローシステム３の複数をまとめ、この分散ワークフロー管理方法への仲介を行うProxyシステム４、ワークフローシステム１、２、Proxyシステム４から、各種イベント情報を収集した後、整理、統合、格納するための分散ワークフローモニタシステム５を含む。

ここで、複数ワークフローシステム１、２の関係は、独立なサイトの集合でも、負荷分散のため対抗クラスタリングでも構わない。

また、分散ワークフローモニタシステム５にアクセスするためのクライアントシステムとして、Webブラウザによるクライアントサイト６は、サービスアクセス手段のため、当該サービスプロバイダ運営体１００には含まれない。

また、当該サービスプロバイダ運営体１００は、サービス利用者に接続サービスを提供するため、サービス利用者の複数業務アプリケーションシステム７、８の持つデータ通信部１３、データ通信部１４の各々に従った通信機能を提供する。同様に、サービス利用者の複数業務アプリケーションシステム９、１０の持つデータ通信部１５、データ通信部１６の各々に従った通信機能を提供する。同様にサービス利用者の複数業務アプリケーションシステム１１、１２の持つデータ通信部１７、データ通信部１８の各々に従った通信機能を提供する。

サービスプロバイダ運営体１００は、データ通信部１７、データ通信部１８の各々に従った通信機能を提供はするが、内部で管理するワークフローシステム３と直接、通信できない場合も有り得る。その様な場合は、Proxyシステム４を介して通信を行う。

このほかについては、上記第１の実施形態と同様であるため、重複する説明は割愛する。

〔第３の実施形態〕
図２１に、本発明を好適に実施した第３の実施形態にかかる業務プロセストラッキング装置を示す。この業務プロセストラッキング装置は、複数の業務アプリケーションシステムがその内部に、分散ワークフロー管理方式に基づく複数のワークフローシステムに相当する、ワークフローサブシステムを含んで、供給する。

図２１は、第１の実施形態において説明した本発明にかかる分散ワークフロー管理方法に基づく業務プロセストラッキング装置の一部を変形し、複数の業務アプリケーションシステム７、９がその内部に、分散ワークフロー管理方式に基づく複数のワークフローシステム１、２に相当するワークフローサブシステム１０１、１０２を含んで、供給する場合のシステム構成を示している。後の構成や動作に関しては、第１の実施形態と同様であるため、重複する説明は割愛する。

本発明である分散ワークフロー管理方法に基づく業務プロセスモニタ・トラッキング装置の最適な形態に関する全体構成の概要を記した図である。 本発明の内、分散配置された通常のワークフローエンジンからイベント情報を収集する際の手順概要を記した図である。 本発明の内、独自実装の他社・既存ワークフローエンジンからＰｒｏｘｙシステムを介してイベント情報を収集する際の手順概要を記した図である。 本発明の内、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合されたＷｆ定義を生成する際の手順、並びに統合された当該Ｗｆ定義をメンテナンスする際の手順概要を記した図である。 Ｗｆ定義の一つの表現形式を記した図である。 本発明の内、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集した後、統合されたＷｆ定義との関係を記した図である。 本発明の内、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合されたＷｆ定義を生成するための手順と原理を記した図である。 本発明の内、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合されたＷｆ定義を生成するための手順と原理を記した図である。 本発明の内、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合されたＷｆ定義を生成するための手順と原理を記した図である。 本発明の内、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合されたＷｆ定義を生成するための手順と原理を記した図である。 本発明の内、分散配置された通常のワークフローエンジンに独自に保持されているワークフロー定義（以下、Ｗｆ定義）群を収集し、統合されたＷｆ定義を生成するための手順と原理を記した図である。 本発明の内、統合されたＷｆ定義をもとに、各種イベントに関するデータをどの様に整理、関係つけて格納するか、の手順と原理を記した図である。 本発明の内、ＡＰラベル入力部に所属し、各種イベントに意味付けを定義するための画面概要図である。 本発明の内、検索機能部、トラッキング表示作成部に所属し、統合されたＷｆ定義を表示する、もしくは統合されたＷｆ定義上で流通するイベント群を表示するための画面概要図である。 本発明の内、検索機能部、トラッキング表示作成部に所属し、統合されたＷｆ定義を表示する、もしくは統合されたＷｆ定義上で流通するイベント群を表示するための画面概要図である。 本発明の内、検索機能部、トラッキング表示作成部に所属し、統合されたＷｆ定義を表示する、もしくは統合されたＷｆ定義上で流通するイベント群を表示するための画面概要図である。 本発明の内、検索機能部、トラッキング表示作成部に所属し、統合されたＷｆ定義を表示する、もしくは統合されたＷｆ定義上で流通するイベント群を表示するための画面概要図である。 従来の業務プロセスモニタ・トラッキング装置の方式概要を記した図である。 従来の分散ワークフロー管理方法、及びシステムの方式概要を記した図である。 本発明の別形態である、サービスプロバイダ運用体での利用方式の概要を記した図である。 本発明の別形態である、業務アプリケーションシステムによる業務プロセスモニタ・トラッキング装置の一部機能を組み込んで機能を実現する方式の概要を記した図である。

符号の説明

1、2 分散ワークフロー管理方式に基づくワークフローシステム
3 独自実装・既存ワークフローシステム
4 Proxyシステム
5 分散ワークフローモニタシステム
6 Webブラウザによるクライアントサイト
7、8、9、10、11、12 業務アプリケーションシステム
13、14、15、16、17、18 データ通信部
19、20、21、22、23、24 アダプタ
25、26、27、28 Msgイベント抽出部
29、32、37 ワークフローエンジン
30、33、38 Ｅｎｇイベント抽出部
31、34、39 ワークフロー定義
35 プロキシ部
36 Ｐｒｘイベント抽出部
40、42、45 イベントデータ保持部
41、43、44、47 共通データ送信部
46 共通データ受信部
48 ワークフロー合成部
49 イベントデータ受信部
50 合成Wf定義
51 イベントデータ関係付け部
52 イベント格納ＤＢ
53 検索機能部
54 トラッキング表示作成部
55 Wf定義・サービス定義取得部
56 リポジトリ
57 他のワークフロー定義
58 APラベル入力
59 バッチ処理部
60 Webブラウザによるクライアントサイト
61、76、77、83、95 Webブラウザ
62 統合・合成したワークフロー定義全体を表示する画面フレーム
64 入力用の画面フレーム
65 定義名の入力欄
66 意味の入力欄
67、74、90、98 OKボタン
68、75、86、91、99 キャンセルボタン
69 検索ボタン
70 リスト表示ボタン
71 指定入力欄
72、93 マウスポインタ
73 エントリに付与されたチェックボックス群
78、85 フォーカスボタン
79 詳細表示ボタン
80 ラベル群
81、89 シンボルに付与されたチェックボックス群
82 サービス定義に関するシンボル群
84 ロケーション情報と合わせて表示するラベル群
87 定義名・意味情報によるラベル群
88 シンボル群
92 チェックボックス群
94 レコード群のリスト表示
96 メッセージインスタンスのレコードに関する情報
97 統計データ詳細を表示するフレーム
100 サービスプロバイダ運営体
101、102 ワークフローサブシステム
C1、C2、C5、C6、C21、C48 処理要求メッセージ
C3、C4、C7、C8、C22、C49 処理応答メッセージ
C9、C10、C11、C12、C13、C14、C15、C16、C17、C18、C19、C20、C23、C24 メッセージに関するイベント
C25、C25’、C26、C54 イベントデータ転送メッセージ
C30、C31、C32、C33、C34、C35、C36、C37、C38、C39、C40、C41 処理要求メッセージ
C42、C43、C44、C45、C46、C47、C50、C51、C52、C53 メッセージに関するイベント
C60、C61、C62 定義転送メッセージ
C63 統合・合成されたワークフロー定義
C64 イベントに関する全てのデータ
C64’ イベントに関するデータ
C65 メッセージインスタンス
C66 メッセージインスタンス群
C67 サービス定義・プロセス定義情報
C67’ 関係付けを検索するため問い合わせ
C67” サービス定義・プロセス定義情報のサブセット
C68 Wf定義検索メッセージ
C69 状況状態の確認問い合わせ
C70 検索結果
C71 起動情報引数
C72 詳細問い合わせ結果
C73 表示データ
C74 問い合わせ
C75 ワークフロー定義情報
C75-1、C75-2、C75-3、C75-4、C75-5、C75-6、C75-7、C75-8 WS-BPEL、WSDLによるワークフロー定義情報
C77、C78 定義名・意味情報
C79 結果値
C80 メッセージインスタンスのレコード群
C81 描画に必要な情報
C90 検索結果
C91 Wf定義要求メッセージ
C92 問い合わせ結果
C93 Wf定義詳細情報要求メッセージ
C94 詳細問い合わせ結果データ
D1 プロセス定義
D2 サービス定義
D3 定義部
D4 該当するメッセージを受信した場合の挙動を定義するアクティビティ部
D5 実際の業務ロジックに相当する挙動を定義するアクティビティ部
D6 該当するメッセージを往信する場合の挙動を定義するアクティビティ部
D7 メッセージ定義部
D8 実際のインタフェースを定義するポート定義部
D9 バインディング部
D10 サービス定義部
D20 ワークフローエンジン挙動を記載、標準化されたWS-BPEL部
D21、D23、D25、D26、D27、D28 WSDL部
D22、D24 ワークフローエンジン挙動を記載、標準化されたWS-BPEL部
B1 イベント管理装置
B3、B4、B5 業務システム
B6 利用者端末
B11 入力部
B12 イベントキュー
B13 イベント関連付け部
B14 イベント管理ＤＢ
B15 業務プロセスＤＢ
B16 出力部
B30、B30’、B40、B40’、B50、B50’ アプリケーション
B31、B31’、B41、B41’、B51、B51’ 状態ＤＢ
B32、B42、B52 イベント抽出部
B33、B43、B53 イベントデータ変換部
B34、B44、B54 イベントデータ送信部
B320、B420、B520 イベント抽出定義データ
A1、A2 組織
A3、A4 ワークフロー管理システム
A5、A6 ワークフロー管理システム・サーバ
A7、A8 既存インタフェース
A9 プロセス・インスタンス
A11、A13 プロセス・テンプレート
A15、A16 状態シャドウイング・エンジン
A17、A18 ワークフロー管理システム・クライアント
A27、A28、A29、A30 利用者

Claims (14)

1. ワークフローを管理・実行する複数のワークフロー実行装置と、該ワークフロー実行装置のそれぞれからワークフローに関する情報を取得し、これらを統合した統合ワークフローを生成するワークフロー統合管理装置とを有するワークフロートラッキングシステムであって、
   前記各ワークフロー実行装置は、
   自装置が管理する任意のワークフローを実行する際に自装置において発生するイベントの内容を表し、それぞれのイベントごとに固有のイベント情報を記録する手段と、
   記録済みの前記イベント情報と前記ワークフローの内容を標準化されたデータ形式で表すワークフロー記述とを前記ワークフロー統合管理装置へ送信する手段とを有し、
   前記ワークフロー統合管理装置は、
   前記各ワークフロー実行装置から、前記ワークフロー記述を取得する手段と、
   前記各ワークフロー実行装置から取得した前記イベント情報によって特定される各イベントに関して、他のイベントとの関連を検出するイベント関連検出手段と、
   前記各ワークフロー実行装置から取得した前記ワークフロー記述から、前記ワークフロー記述に含まれる他のワークフロー記述で定義されるサービスを指定する情報に基づいて各ワークフロー記述のリンク関係を作成することによって前記統合ワークフローを生成した後、当該統合ワークフローに複数の前記イベント情報を関連付ける手段と、
   前記各ワークフロー実行装置から取得した全ての前記イベント情報を記録するイベント情報記録手段と、
   前記イベント情報記録手段に記録されたイベント情報を、他の装置からの要求に応じて参照させる手段と、
   を有することを特徴とするワークフロートラッキングシステム。
2. 前記標準化されたデータ形式とは異なる形式で前記ワークフロー記述が定義された前記ワークフロー実行装置には、そのワークフロー記述を前記標準化されたデータ形式に変換する標準化装置が内蔵又は接続されていることを特徴とする請求項１記載のワークフロートラッキングシステム。
3. 前記ワークフロー統合管理装置は、前記イベント情報に対して人間が認識可能な形式の任意の情報を付加する手段を更に有することを特徴とする請求項１又は２記載のワークフロートラッキングシステム。
4. 前記ワークフロー統合管理装置は、前記イベント情報記録手段に記録したイベント情報に基づいて統計処理を行い統計データを生成するパッチ処理手段を有することを特徴とする請求項１から３のいずれか１項記載のワークフロートラッキングシステム。
5. 前記ワークフロー実行装置は、前記ワークフローを実行する際に通信相手となる業務アプリケーションシステムに固有な通信手順を、標準化された通信手順に変換するためのアダプタを複数備えることを特徴とする請求項１から４のいずれか１項記載のワークフロートラッキングシステム。
6. ワークフローを管理・実行する複数のワークフロー実行装置のそれぞれからワークフローに関する情報を取得し、これらを統合した統合ワークフローを生成するワークフロー統合管理装置であって、
   前記各ワークフロー実行装置から、前記ワークフローの内容を標準化されたデータ形式で表すワークフロー記述を取得する手段と、
   前記各ワークフロー実行装置が前記ワークフローを実行する際にその装置において発生するイベントの内容を表し、それぞれのイベントごとに固有のイベント情報を前記各ワークフロー実行装置から取得する手段と、
   取得した前記イベント情報によって特定される各イベントに関して、他のイベントとの関連を検出するイベント関連検出手段と、
   前記各ワークフロー実行装置から取得した前記ワークフロー記述から、前記ワークフロー記述に含まれる他のワークフロー記述で定義されるサービスを指定する情報に基づいて各ワークフロー記述のリンク関係を作成することによって前記統合ワークフローを生成した後、当該統合ワークフローに複数の前記イベント情報を関連付ける手段と、
   前記各ワークフロー実行装置から取得した全ての前記イベント情報を記録するイベント情報記録手段と、
   前記イベント情報記録手段に記録されたイベント情報を、他の装置からの要求に応じて参照させる手段と、
   を有することを特徴とするワークフロー統合管理装置。
7. 前記イベント情報に対して人間が認識可能な形式の任意の情報を付加する手段を更に有することを特徴とする請求項６記載のワークフロー統合管理装置。
8. 前記イベント情報記録手段に記録したイベント情報に基づいて統計処理を行い統計データを生成するパッチ処理手段を有することを特徴とする請求項６又は７項記載のワークフロー統合管理装置。
9. ワークフローを管理・実行する複数のワークフロー実行装置と、該ワークフロー実行装置のそれぞれからワークフローに関する情報を取得し、これらを統合した統合ワークフローを生成するワークフロー統合管理装置とを用いたワークフロー統合管理方法であって、
   前記各ワークフロー実行装置が、自装置が管理する任意のワークフローを実行する際に自装置において発生するイベントの内容を表し、それぞれのイベントごとに固有のイベント情報を記録する工程と、
   前記各ワークフロー実行装置が、記録済みの前記イベント情報と前記ワークフローの内容を標準化されたデータ形式で表すワークフロー記述とを前記ワークフロー統合管理装置へ送信する工程と、
   前記ワークフロー統合管理装置が、前記各ワークフロー実行装置から取得した前記イベント情報によって特定される各イベントに関して、他のイベントとの関連を検出するイベント関連検出工程と、
   前記ワークフロー統合管理装置が、前記各ワークフロー実行装置から取得した前記ワークフロー記述から、前記ワークフロー記述に含まれる他のワークフロー記述で定義されるサービスを指定する情報に基づいて各ワークフロー記述のリンク関係を作成することによって前記統合ワークフローを生成した後、当該統合ワークフローに複数の前記イベント情報を関係付ける工程と、
   前記ワークフロー統合管理装置が、前記各ワークフロー実行装置から取得した全ての前記イベント情報を記録するイベント情報記録工程と、
   前記ワークフロー統合管理装置が、前記イベント情報記録手段に記録されたイベント情報を、他の装置からの要求に応じて参照させる工程と、
   を有することを特徴とするワークフロー統合管理方法。
10. 前記標準化されたデータ形式とは異なる形式で前記ワークフロー記述が定義された前記ワークフロー実行装置は、そのワークフロー記述を前記標準化されたデータ形式に変換して前記ワークフロー統合管理装置へ送信することを特徴とする請求項９記載のワークフロー統合管理方法。
11. 前記ワークフロー統合管理装置が、前記イベント情報に対して人間が認識可能な形式の任意の情報を付加する工程をさらに有することを特徴とする請求項９又は１０記載のワークフロート統合管理方法。
12. 前記ワークフロー統合管理装置が、前記イベント情報記録工程において記録したイベント情報に基づいて統計処理を行い統計データを生成するパッチ処理工程を有することを特徴とする請求項９から１１のいずれか１項記載のワークフロー統合管理方法。
13. 請求項９から１２のいずれか１項記載のワークフロー統合管理方法をコンピュータに実行させるためのワークフロー統合管理プログラム。
14. 請求項１３記載のワークフロー統合管理プログラムを記録したコンピュータが読取可能な情報記録媒体。
    
    

Images