(57)【要約】【課題】メッセージ受信処理において制御付処理遅延分岐を実行することができるプロセスエンジンを提供する。【解決手段】プロセスエンジン１０は、他のプロセスエンジン１０ａからメッセージを受信するメッセージ受信部３１を備えている。送受信メッセージ順序正確性判定モジュール６０は、プロセスエンジンモジュール４０の現処理状態を記憶している。妥当性判定部６２は、受信したメッセージと現処理状態に基づいて受信したメッセージが現処理状態で受信すべきメッセージであるか否かを判定する。受信したメッセージが現処理状態において受信すべきメッセージであると判定された時、プロセスエンジンモジュール４０にメッセージを送信する。そして、送受信メッセージ順序正確性判定モジュール６０は受信したメッセージが受信すべきメッセージであった時またはメッセージを送信した時、受信または送信したメッセージに基づいて現処理状態を更新する。【選択図】    図１
2006072797.tif 000002
【特許請求の範囲】
【請求項１】
集団の中で予め定められた業務処理手順に基づいて電子化された業務情報の処理を行う業務処理部を備え前記集団ごとに設置された複数の業務処理装置から構成される業務処理システムにおける業務処理装置であって、
他の業務処理装置から前記業務情報を受信する受信手段と、
前記業務処理手順に基づいて求められる前記業務処理部の現処理状態を記憶する状態記憶手段と、
受信した前記業務情報が前記現処理状態において受信すべき業務情報であるか否かを前記状態記憶手段から読み出した前記現処理状態に基づいて判定する判定手段と、
前記判定手段によって受信した前記業務情報が前記現処理状態において受信すべき業務情報であると判定された時、前記受信手段が受信した前記業務情報を前記業務処理部に送信する業務情報取得手段と、
前記判定手段によって前記現処理状態において受信すべき業務情報であると判定された時または前記業務処理部が前記他の業務処理装置に前記業務情報を送信した時、受信または送信した前記業務情報に基づいて前記業態記憶手段の前記現処理状態を更新する状態更新手段と、
を備えたことを特徴とする業務処理装置。
【請求項２】
前記受信手段が受信した前記業務情報を記憶する業務情報記憶手段を更に備え、
前記業務情報取得手段は、
前記判定手段によって受信した前記業務情報が前記現処理状態において受信すべき業務情報であると判定された時、前記受信手段が受信した前記業務情報を前記業務情報記憶手段に登録する業務情報登録手段と、
前記業務情報処理部から業務情報取得要求を受信した時、前記業務情報取得要求に基づいて前記業務情報を前記業務情報記憶手段から読み出して前記業務処理部に送信する業務情報送信手段と、
前記業務情報取得要求に含まれている前記現処理状態に基づいて、読み出した前記業務情報を前記業務情報記憶手段から削除するか否かを決定する削除決定手段と、
前記決定手段によって削除すると決定された時、読み出した前記業務情報を前記業務情報記憶手段から削除する業務情報削除手段と、
を備えたことを特徴とする請求項１に記載の業務処理装置。
【請求項３】
集団の中で予め定められた業務処理手順に基づいて電子化された業務情報の処理を行う業務処理部を備え前記集団ごとに設置された複数の業務処理装置から構成される業務処理システムにおける業務処理装置のコンピュータを、
他の業務処理装置から前記業務情報を受信する受信手段、
前記業務処理手順に基づいて求められる前記業務処理部の現処理状態を記憶する状態記憶手段、
受信した前記業務情報が前記現処理状態において受信すべき業務情報であるか否かを前記状態記憶手段から読み出した前記現処理状態に基づいて判定する判定手段、
前記判定手段によって受信した前記業務情報が前記現処理状態において受信すべき業務情報であると判定された時、前記受信手段が受信した前記業務情報を前記業務処理部に送信する業務情報取得手段、
前記判定手段によって前記現処理状態において受信すべき業務情報であると判定された時または前記業務処理部が前記他の業務処理装置に前記業務情報を送信した時、受信または送信した前記業務情報に基づいて前記業態記憶手段の前記現処理状態を更新する状態更新手段、
として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、主に企業間取引におけるワークフローを実行するプロセスエンジンに相当する業務処理装置及びそのコンピュータプログラムに関する。
【背景技術】
【０００２】
まず最初に、前提知識となる上記の業務処理装置に該当する従来のプロセスエンジンについて、そして、想定する適応モデル、対比すべきプロセスエンジンに関する技術について説明する。
【０００３】
プロセスエンジンとは、プロセス、即ち電子化された情報の受け渡しや処理の手順を形式的に定義したものを実行及び制御するコンピュータによって構成されるシステムである。このプロセスエンジンは、企業における業務の効率化を支援する。プロセスの記述方式は、処理ノードと制御ノードとそれらのノード間における方向のある接続関係を定義した記述方式を前提とする。ここで、処理ノードとは、何らかの情報の受け渡しや処理を実際に行うことを想定したノードである。一方、制御ノードとは処理手順の定義において、処理手順の分岐、合流、並列実行の開始や終了、処理手順の定義の開始や終了を表すノードである。この記述方式は一般的であり、具体的にはＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）のアクティビティ図やフローチャートなどがある。
【０００４】
次に、複数の企業が参加する企業間取引の全体をプロセスによって制御する企業間連携システムについて説明する。企業間連携システムは、機密性の保持や組織的独立性の確保といった社会的な要求から、個々の企業の内部プロセスを可能な限り他の企業から隠蔽するように構成することが求められている。そのため、企業間取引の全体業務プロセス（以下、グローバルプロセスと呼ぶ）を、企業単位のプロセスに分割し（以下、分割したプロセスをインターナルプロセスと呼ぶ）、企業単位で配置されたプロセスエンジンが個々に定義されたプロセスを実行することにより、全体業務を実行するというモデルが考えられる。このモデルにおいて、各プロセスエンジン間は、プロセスエンジン同士が相互にメッセージを送受信することにより協調して処理を行う。このようなモデルは「プロセスエンジンの協調作業による分散システムの実現」と呼ばれている。
【０００５】
図１２にその構成モデルを示す。このモデルにおいて、サービスとはビジネス上で意味を持つ程度の粒度を持つ機能を提供するシステムを示しており、当該サービスの連携手順や、連掲示に送受信する情報や文書などがビジネスプロセスとして定義されている。これらの定義を個々のプロセスエンジンが解釈して、全体でまとまった処理を実現する。
【０００６】
次に、上述した「プロセスエンジンの強調作業による分散システムの実現」という目的に関する従来技術を説明する。
従来のグローバルプロセスの記述仕様として、非特許文献１に示すＷＳＣＩ（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｃｈｏｒｅｏｇｒａｐｈｙ  Ｉｎｔｅｒｆａｃｅ）や非特許文献２に示すＷＳ−ＢＰＥＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  −  Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｅｘｅｃｕｔｉｏｎ  Ｌａｎｇｕａｇｅ）などが提案されている。これらの記述仕様はグローバルプロセスを実行する企業ごとのプロセスエンジンのそれぞれに対し、他のプロセスエンジンとの連携手順を定義し、その連携手順を相互に関連付ける方法でグローバルプロセスを定義する。また、分散したプロセスエンジンによって企業間連携を実現する例としては、特許文献１に示す技術がある。さらに、グローバルプロセスを企業間の文書のやり取りで表現する「会話型プロセス」として定義し、その定義からインターナルプロセスを導出する方式が特許文献２に開示されている。
【特許文献１】特開２０００−２５０９６７号公報
【特許文献２】特開２００４−１６４４４９号公報
【非特許文献１】Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｃｈｏｒｅｏｇｒａｐｈｙ  Ｉｎｔｅｒｆａｃｅ，[online]，２００２年８月，Ｗ３Ｃ，[平成１６年８月１３日検索]，インターネット<URL:http://www.w3.org/TR/wsci/>
【非特許文献２】Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｅｘｅｃｕｔｉｏｎ  Ｌａｎｇｕａｇｅ  ｆｏｒ  Ｗｅｂ  Ｓｅｒｖｉｃｅ，[online]，２００３年５月，ＩＢＭ，[平成１６年８月１３日]，インターネット<http://www-106.ibm.com/developerworks/library/ws-bpel/>
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、「プロセスエンジンの協調作業による分散システムの実現」を検討した場合に、従来の技術では、プロセスエンジン間の協調のために必要なメッセージの受信処理に関して課題がある。この課題において前提となるメッセージ受信処理を説明し、そして、従来の技術では実現できないメッセージ受信処理について説明する。
【０００８】
＜メッセージ受信処理＞
図１２のモデルの分散システムでは、分散システム中の各プロセスエンジンは、その他のプロセスエンジンとメッセージの送受信を行うことによりシステム間の連携を行う。メッセージ受信処理は、以下の３つのステップで行われる。
処理１：メッセージを受信するまで待機する。
処理２：受信したメッセージが現在実行しているプロセスの状態において期待される妥当なメッセージであるかを判定する。
処理３：受信したメッセージに予め対応付けられた動作を行う。
【０００９】
メッセージ受信処理には、同時に複数のメッセージの受信を待機する状況も存在する。複数のメッセージ受信を待機している状況における各待機メッセージの関係は以下のように分類できる。
関係１：排他関係：同時に受信を待機しているメッセージ群において、どれか１つのメッセージのみを受信しなくてはならない。
関係２：独立関係：同時に受信を待機しているメッセージ群において、すべてのメッセージを受信しなくてはならない。
関係３：半排他関係：あるメッセージｘを受信したらメッセージｙは受信しなくてもよいが、メッセージｙを受信したら、メッセージｘを受信しなくてはならない。
関係４：３つ以上のメッセージ受信を待機し、それらの任意の２つのメッセージ間の関係において、関係１〜３で混在している場合
【００１０】
＜従来の技術では実現できないメッセージ受信処理＞
従来の技術である非特許文献１に示すＷＳＣＩや非特許文献２に示すＷＳ−ＢＰＥＬでは、関係１及び２は記述可能であり、ＷＳＣＩ及びＷＳ−ＢＰＥＬに対応したプロセスエンジンは、そのメッセージ受信処理を行うことが可能である。しかし、ＷＳＣＩ及びＷＳ−ＢＰＥＬでは、関係３及び関係４に示された制御付処理遅延分岐を記述することはできず、プロセスエンジンもそのメッセージ受信処理を行うことができないという課題がある。また、特許文献１及び特許文献２に記載されたシステムも、関係３及び関係４のメッセージ受信処理を処理することができないという課題がある。
【００１１】
本発明は、上記課題を解決するためになされたもので、その目的は、メッセージ受信処理において制御付処理遅延分岐を実行することができるプロセスエンジン、即ち業務処理装置を提供することにある。
【課題を解決するための手段】
【００１２】
上述した課題を解決するために、本発明は、集団（例えば、後述する企業）の中で予め定められた業務処理手順（例えば、後述するプロセス）に基づいて電子化された業務情報（例えば、後述するメッセージ）の処理を行う業務処理部（プロセスエンジンモジュール４０）を備え前記集団ごとに設置された複数の業務処理装置（プロセスエンジン１０）から構成される業務処理システム（プロセスエンジンシステム１）における業務処理装置であって、他の業務処理装置から前記業務情報を受信する受信手段（メッセージ受信部３１）と、前記業務処理手順に基づいて求められる前記業務処理部の現処理状態（例えば、後述するペトリネットにおけるマーキングデータ）を記憶する状態記憶手段（マーキング保持テーブル６１）と、受信した前記業務情報が前記現処理状態において受信すべき業務情報であるか否かを前記状態記憶手段から読み出した前記現処理状態に基づいて判定する判定手段（妥当性判定部６２）と、前記判定手段によって受信した前記業務情報が前記現処理状態において受信すべき業務情報であると判定された時、前記受信手段が受信した前記業務情報を前記業務処理部に送信する業務情報取得手段（メッセージ取得部３３）と、前記判定手段によって前記現処理状態において受信すべき業務情報であると判定された時または前記業務処理部が前記他の業務処理装置に前記業務情報を送信した時、受信または送信した前記業務情報に基づいて前記業態記憶手段の前記現処理状態を更新する状態更新手段（妥当性判定部６２）と、を備えたことを特徴とする業務処理装置である。
【００１３】
本発明は、上記の発明において、前記受信手段が受信した前記業務情報を記憶する業務情報記憶手段（メッセージ保存テーブル３２）を更に備え、前記業務情報取得手段は、前記判定手段によって受信した前記業務情報が前記現処理状態において受信すべき業務情報であると判定された時、前記受信手段が受信した前記業務情報を前記業務情報記憶手段に登録する業務情報登録手段（メッセージ受信部３１）と、前記業務情報処理部から業務情報取得要求を受信した時、前記業務情報取得要求に基づいて前記業務情報を前記業務情報記憶手段から読み出して前記業務処理部に送信する業務情報送信手段（メッセージ取得部３３）と、前記業務情報取得要求に含まれている前記現処理状態に基づいて、読み出した前記業務情報を前記業務情報記憶手段から削除するか否かを決定する削除決定手段（メッセージ取得部３３）と、前記決定手段によって削除すると決定された時、読み出した前記業務情報を前記業務情報記憶手段から削除する業務情報削除手段（メッセージ取得部３３）と、を備えたことを特徴とする。
【００１４】
本発明は、集団の中で予め定められた業務処理手順に基づいて電子化された業務情報の処理を行う業務処理部を備え前記集団ごとに設置された複数の業務処理装置から構成される業務処理システムにおける業務処理装置のコンピュータを、他の業務処理装置から前記業務情報を受信する受信手段、前記業務処理手順に基づいて求められる前記業務処理部の現処理状態を記憶する状態記憶手段、受信した前記業務情報が前記現処理状態において受信すべき業務情報であるか否かを前記状態記憶手段から読み出した前記現処理状態に基づいて判定する判定手段、前記判定手段によって受信した前記業務情報が前記現処理状態において受信すべき業務情報であると判定された時、前記受信手段が受信した前記業務情報を前記業務処理部に送信する業務情報取得手段、前記判定手段によって前記現処理状態において受信すべき業務情報であると判定された時または前記業務処理部が前記他の業務処理装置に前記業務情報を送信した時、受信または送信した前記業務情報に基づいて前記業態記憶手段の前記現処理状態を更新する状態更新手段、として機能させるためのコンピュータプログラムである。
【発明の効果】
【００１５】
この発明によれば、業務処理装置は、予め定められた業務処理手順に基づいて求められる前記業務処理部の現処理状態を状態記憶手段に記憶する。そして、他の業務処理装置から前記業務情報を受信し、状態記憶手段から読み出した現処理状態に基づいて受信した業務情報が現処理状態において受信すべき業務情報であるか否かを判定する。受信した業務情報が現処理状態において受信すべき業務情報であると判定された時、業務情報処理部に業務情報を送信する。現処理状態において受信すべき業務情報であると判定された時または業務処理部が他の業務処理装置に業務情報を送信した時、受信または送信した業務情報に基づいて業態記憶手段の現処理状態を更新する構成になっている。そのため、業務処理装置は、実際の業務情報の処理を行う業務処理部の現処理状態を業務処理部を参照することなく得ることが可能となる。それによって、業務処理部が実際に業務情報を受信する前に、受信した業務情報が現処理状態において妥当な業務情報であるか否かを判定することが可能となり、新たに受信した業務情報が妥当なものであるかを判定する処理を追加する必要がなくなる。
【００１６】
また、本発明によれば、業務処理装置は、受信した業務情報を記憶する業務情報記憶手段を備えており、受信した業務情報が現処理状態において受信すべき業務情報であると判定された時、受信した業務情報を業務情報記憶手段に登録する。そして、業務情報処理部から業務情報取得要求を受信した時、業務情報取得要求に基づいて業務情報を業務情報記憶手段から読み出して業務処理部に送信する。また、業務情報取得要求に含まれている現処理状態に基づいて、読み出した業務情報を業務情報記憶手段から削除するか否かを決定し、削除すると決定した時、読み出した業務情報を業務情報記憶手段から削除する構成となっている。そのため、例えば、業務処理部の現処理状態が半排他関係にある２つの業務情報のいずれか一方の受信を待機している状態であっても、業務情報を一度受信して次段の分岐を決定して本来当該業務情報を受信すべき状態に遷移した時まで業務情報を保持しておくことが可能となる。それによって、業務処理部の処理と業務情報の受信処理を非同期に行うことができ、制御付遅延分岐処理が可能となる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の一実施形態による上述した業務処理装置に該当するプロセスエンジン及びプロセスエンジンシステムを図面を参照して説明する。
図１は、本実施形態によるプロセスエンジンシステム１を示した概略ブロック図である。同図において、プロセスエンジンシステム１は、プロセスエンジン１０とネットワーク１００と他企業が有しているプロセスエンジン１０ａから構成されている。プロセスエンジン１０は、上述した通り企業内における電子化された情報をメッセージとして送受信する手順や、当該メッセージの処理の手順を形式的に定義したものを実行及び制御するコンピュータから構成されている。
【００１８】
プロセスエンジン１０において、メッセージ受信モジュール３０は、他のプロセスエンジン１０ａからメッセージを受信する。メッセージ受信モジュール３０において、メッセージ受信部３１は、他のプロセスエンジン１０ａからメッセージを受信すると共に、後述する送受信メッセージ順序正確性判定モジュール６０に受信したメッセージを送信する。また、送受信メッセージ順序正確性判定モジュール６０からメッセージの判定結果を受信し、判定結果に基づいて受信したメッセージをメッセージ保存テーブル３２に登録する。メッセージ取得部３３は、プロセスエンジンモジュール４０からの要求を受けてメッセージ保存テーブル３２に登録されているメッセージを読み出し、プロセスエンジンモジュール４０に送信する。
【００１９】
プロセスエンジンモジュール４０は、企業における業務の手順に基づいて作成されたプロセス記述に基づいてメッセージ取得部３３から受信したメッセージをサービス５０に対して振り分けて送信する。ここで、サービスとはビジネス上で意味を持つ程度の粒度を持つ機能を提供するシステムを示しており、例えば、商品購買システム、流通管理システムなどが該当する。
【００２０】
メッセージ送信モジュール２０は、ネットワーク１００を介して他のプロセスエンジン１０ａにメッセージを送信する。メッセージ送信モジュール２０においてメッセージ送信部２１は、プロセスエンジンモジュール４０からメッセージを受信し、ネットワーク１００を介して他のプロセスエンジン１０ａに当該メッセージを送信する。また、送受信メッセージ順序正確性判定モジュール６０に、メッセージを送信したことを通知する。
【００２１】
送受信メッセージ順序正確性判定モジュール６０は、プロセスエンジン１０の処理状態の現状態を送受信されたメッセージとプロセスに従って導きだし、現処理状態を内部に記録している。そして、プロセス記述に基づく実行過程において、次に実行可能な処理を内部に記憶している現処理状態の情報から判定する。つまり、送受信メッセージ順序正確性判定モジュール６０は、プロセスエンジン１０の処理状態の変化に同期して内部に記憶している現処理状態を更新しており、プロセスエンジン１０を参照することなく、プロセスエンジン１０の現処理状態を認識することが可能である。
【００２２】
送受信メッセージ順序正確性判定モジュール６０において、妥当性判定部６２は、メッセージ受信部３１からメッセージを受信し、受信したメッセージが妥当か否かを内部に記憶している現処理状態に基づいて判定する。また、メッセージ送信部２１から送信したメッセージの情報を受信し、現処理状態を更新する。マーキング保持テーブル６１、マーキング無しペトリネット保持テーブル６３、受信イベント対応プレース取得テーブル６４の３つのテーブルは、プロセス記述を変換して得られた後述するペトリネットという二部有向グラフで制御や処理手順を示す方式において、当該二部有向グラフで示された情報を登録しておくためのテーブルである。妥当性判定部６２は、これら３つのテーブルを参照して、テーブルに記憶されている情報からペトリネットを構築する。そして、構築したペトリネットを実行することにより現処理状態を導き出し、当現処理状態に基づいて受信メッセージの判定を行う。ペトリネット生成部６５は、プロセスエンジンモジュール４０で使われているプロセス記述をペトリネットへ変換し、マーキング無しペトリネット保持テーブル６３及び受信イベント対応プレース取得テーブル６４に変換後の情報を登録する。
【００２３】
図２は、半排他関係にあるメッセージや、３つ以上のメッセージ受信を待機し、それらの任意の２つのメッセージの関係において排他関係、独立関係、半排他関係があるメッセージを受信して処理を行うために、プロセス記述において新たに付け加えた「制御付遅延分岐」という制御ノードを示した図である。なお、図２の記載はＵＭＬのアクティビティ図に従って記載されたものである。
【００２４】
制御付遅延分岐は、制御ノードの１つとして記述され、処理手順の分岐を示すノードと同様に、１つのノードの接続と複数のノードへの接続が定義されている。文献（Ｗ．Ｍ．Ｐ．ｖａｎ  ｄｅｒ  Ａａｌｓ，Ａ．Ｈ．Ｍ．ｔｅｒ  Ｈｏｆｓｔｅｄｅ，Ｂ．Ｋｉｅｐｕｓｚｅｗｓｋｉ，ａｎｄ  Ａ．Ｐ．Ｂａｒｒｏｓ．“Ｗｏｒｋｆｌｏｗ  ｐａｔｔｅｒｎｓ，Ｔｅｃｈｎｉｃａｌ  ｒｅｐｏｒｔ  ＦＩＴ−ＴＲ−２００２−２，Ｆａｃｕｌｔｙ  ｏｆ  ＩＴ，Ｑｕｅｅｎｓｌａｎｄ  Ｕｎｉｖｅｒｓｉｔｙ  ｏｆ  Ｔｅｃｈｎｏｌｏｇｙ，  Ｊｕｌｙ  ２００２  <URL:http://www.tm.tue.nl/it/reserach/patterns>）で示されている遅延分岐も同様な制御ノードとして記述されることとなる。
【００２５】
通常の処理手順の分岐を表すノードは、複数のノードへの接続それぞれに、分岐先を決定するガード条件が記述され、ガード条件を満たした接続を分岐先として選択する。遅延分岐を示すノードは、任意にこの制御ノードの接続が繰り返された後に、イベント処理ノードに接続され、メッセージ受信時にそのメッセージを処理するイベント処理ノードが実行されるような接続を分岐先として選択する。メッセージ受信時にそのメッセージを処理するイベント処理ノードが実行されるような接続を分岐先として選択する。制御付遅延分岐を示すノードは、任意個の制御ノードの接続が繰り返された後に、イベント処理ノードに接続される。
【００２６】
制御付遅延分岐は、遅延分岐と同様、イベント発生時にそのイベントを処理するイベント処理ノードが実行されるような接続を分岐先として選択する。制御付遅延分岐が遅延分岐と異なる点は、制御付遅延分岐の場合には、制御付遅延分岐に接続されている制御ノードを処理してから、イベント処理ノードがイベントの処理を実行する点にある。
【００２７】
制御付遅延分岐ノードにおいて制御付遅延分岐ノードと分岐先となるイベント処理ノードの間に任意個の制御ノードの接続を記述することで、様々な関係を有する複数イベントの発生を待機する処理を記述できる。
【００２８】
図２において制御付遅延分岐ノードはＵＭＬの<<deferred>>ステレオタグをつけた分岐で表現し、イベント処理ノードを<<event>>ステレオタグで表現すると、上述した独立関係及び排他関係は（ａ）のように記載され、半排他関係は（ｂ）のように記載される。また、３つ以上のメッセージ受信を待機し、それらの任意の２つのメッセージの関係において独立関係、半排他関係がある場合は（ｃ）のように記載される。
【００２９】
図２に示すような制御付遅延分岐ノードを実現するため本実施形態のプロセスエンジン１０では以下に示す（１）、（２）について考慮されている。
（１）プロセスエンジン１０が、プロセスの実行中に制御付遅延分岐の処理（以下、アクティビティと呼ぶ）に到達すると、どの分岐へ分岐するかが決定するまでは、当該制御付遅延分岐のアクティビティにおいて待機する必要がある。従来のプロセスエンジンでは<<event>>アクティビティ状態でしか、メッセージの送受信をする必要がなかったが、本実施形態のプロセスエンジン１０は、<<deferred>>アクティビティで待機している状態においても、その制御付遅延分岐から分岐する先の<<event>>アクティビティに対応したメッセージを受信する必要がある。そのためにプロセスエンジン１０ではメッセージ保存テーブル３２をメッセージ受信モジュール３０に備えており、<<event>>アクティビティ以外の状態でも非同期にメッセージを受信できるようにしている。
【００３０】
（２）プロセスエンジン１０のメッセージ受信処理においては、上述した通り、メッセージの妥当性を判断するという処理を行う必要がある。従来のプロセスエンジンでは、どの種類のメッセージを妥当なメッセージとして処理するのかという判定を、どの<<event>>アクティビティ状態で待機しているのかによって決定するだけでよかった。しかし、本実施形態では<<deferred>>アクティビティの状態が存在し、<<deferred>>アクティビティ状態であっても分岐先の<<event>>アクティビティで受信するメッセージを受信して分岐先を決定する必要がある。そのためにプロセスエンジン１０では、プロセス記述を変換したペトリネットを採用し、判定時に並列処理によって<<deferred>>アクティビティ状態で受信したメッセージを判定することを可能としている。
【００３１】
図３は、送受信メッセージ順序正確性判定モジュール６０のペトリネット生成部６５が行うプロセス記述からペトリネットによる二部有向グラフへの変換を説明するための図である。送受信メッセージ順序正確性判定モジュール６０は、システムのプロセスをペトリネットでモデル化し、そのペトリネット上で正確性の判定を行う。ペトリネットは、並列処理を行うシステムに有効なモデル化手法であり、複数の処理の関連を考慮したシステムの動作をモデル化することができる。
【００３２】
モデル化のためのプロセス記述からペトリネットへの変換は以下のようにして行う。
手順１：並列処理開始ノード、並列処理終了ノードを除く全てのノードに対応するプレースを生成する。
手順２：並列処理開始ノード、並列処理終了ノードに対応するトランジションを生成する。さらに、接続元ノードの数と同じ数のプレースを生成し、各プレースを生成したトランジションへ接続する。さらに、接続先ノードの数と同じ数のプレースを生成し、生成したトランジションから各プレースへの接続を定義する。
手順３：上記の手順において生成されたプレース、トランジションのノードデータをマーキング無しペトリネット保持テーブル６３のノード保持テーブルに登録する。
手順４：プロセス定義において処理順序を表すノードの接続関係全てに対しトランジションを生成し、接続関係がある２つのノードの接続元ノードに対応するプレースを、生成したトランジションへ接続する。また、生成したトランジションを接続先ノードに対応するプレースへ接続する。接続元ノードが並列処理開始ノードあるいは、並列処理終了ノードである場合は、手順２で生成したプレースのうち、接続元の無い任意のプレースを接続先とする。
手順５：ここまでの手順で生成されたノードの接続関係を、マーキング無しペトリネット保持テーブル６３の接続関係保持テーブルに登録する。
【００３３】
上記の手順によって図３（ａ）に示すプロセス記述がペトリネット生成部６５によって図３（ｂ）に示すペトリネットへ変換される。変換されたペトリネットは、ある時点でのマーキングがその時点までに受信したメッセージのリストから定められるシステムの状態を一意に特定するという特徴を有する。この特徴から、与えられたペトリネット上のマーキングにおいてトークンが配置可能なプレースを求めることにより、プロセスにおける次に実行可能な処理ノードを特定することができる。変換されたペトリネットを表すデータはペトリネット生成部６５によってマーキング無しペトリネット保持テーブル６３に登録される。
【００３４】
なお、上述した、マーキング、プレース、トークン、トランジションという用語はペトリネットで用いられる用語であり、詳細は以下の文献に記載されている。（「青山  幹雄ら、「ペトリネットの理論と実線」、朝倉書店、システム制御情報ライブラリ１３巻（ISBN4-252-20973-8）、１９９５年１１月」、「ペトリネット入門、<URL:http://www.aichi-pu.ac.jp/ist/~qua/intropn/intropn.html>」）
【００３５】
図４は、マーキング無しペトリネット保持テーブル６３のデータ構成を示した図である。マーキング無しペトリネット保持テーブル６３は、ノード保持テーブル６３ａと接続関係保持テーブル６３ｂの２つのテーブルから構成されている。
ノード保持テーブル６３ａにおいて、ペトリネットＩＤにはペトリネットを一意に特定するＩＤが設定される。ノードＩＤには、個々のノードをペトリネット内で一意に特定するＩＤが設定される。ノード種別には、ノードが「プレース」あるいは「トランジション」のいずれであるかを示す情報が設定される。ノード属性には、ノード種別が「プレース」の場合に、そのノードがプロセスにおいて<<event>>アクティビティなのか<<deferred>>アクティビティなのかを示す情報が設定される。
【００３６】
接続関係保持テーブル６３ｂにおいて、ペトリネットＩＤは上述した通りペトリネットを一意に特定するＩＤが設定される。入力ノードＩＤには、接続関係の入力ノードに付与されたＩＤが設定される。出力ノードＩＤには、接続関係の出力ノードに付与されたＩＤが設定される。
【００３７】
図５は、受信イベント対応プレース取得テーブル６４のデータ構成を示した図である。同図において、イベント受信アクティビティＩＤにはメッセージ内容をその種別によって分類し、一意に識別できるように付与したＩＤが設定される。具体的には、図２（ａ）において示した<<event>>アクティビティａ１、ａ２、ａ３ごとに設定されるＩＤであり、受信したメッセージに含まれている情報である。ペトリネットＩＤとノードＩＤには当該イベント受信アクティビティの状態で、実行されるペトリネットＩＤと、当該ペトリネットＩＤが示すペトリネット内において、当該イベント受信アクティビティ状態の時にトークンが配置されるノードのノードＩＤが設定されている。
【００３８】
図６は、マーキング保持テーブル６１のデータ構成を示した図である。
同図において、セッションＩＤには、プロセスを処理単位に分割したセッションに付与されたＩＤが設定される。ここで、プロセスが例えば商品購買処理だった場合に、セッションは、発注者と販売者の間で行われる１回のメッセージの送受信などの処理単位である。つまり、セッションＩＤは受信するメッセージ単位にＩＤが存在し、受信したメッセージに含まれている情報である。当該プロセスの中でペトリネットＩＤにはそのプロセスに対応するペトリネットＩＤが設定される。マーキングデータは、プロセスの状態を示す情報であり、当該ペトリネットＩＤに含まれているノードであってマークされているノード、即ちトークンが配置されているノードのノードＩＤが設定されている。
【００３９】
図７は、メッセージ受信モジュール３０のメッセージ保存テーブル３２のデータ構成を示した図である。同図において、メッセージ内容には、どの企業が送信元であるかを含んだ情報が受信順に登録されている。
【００４０】
図８は、プロセスエンジン１０の処理を示したＵＭＬのアクティビティ図である。プロセスエンジン１０では、メッセージ受信モジュール３０とプロセスエンジンモジュール４０が並列に動作する。メッセージ受信モジュール３０は、図８（ａ）に示す処理を行う。
図８（ａ）において、メッセージ受信モジュール３０は、他のプロセスエンジン１０ａ
からメッセージを受信した時に処理を開始する。そして、最初にメッセージを送受信メッセージ順序正確性判定モジュール６０に送信し、メッセージの妥当性の検証の結果を受信する（ステップＳ８−１）。次に、受信したメッセージをメッセージ保存テーブル３２に登録し、メッセージ取得部３３にメッセージ取得処理を再開させる（ステップＳ８−２）。
【００４１】
一方、プロセスエンジンモジュール４０は、図８（ｂ）に示す処理を行う。
図８（ｂ）において、予め定義されているプロセスを実行する時に、処理を開始する。プロセスの実行中に<<deferred>>アクティビティあるいは、<<event>>アクティビティが実行される（ステップＳ８−３）。プロセスが終了であればそのまま終了する。プロセスが実行中であれば、メッセージ取得部３３に要求を送信し、メッセージ取得部３３を介してメッセージ保存テーブル３２からメッセージを取得する。この時、メッセージが取得できるまで待機する。そしてステップＳ８−３に戻る（ステップＳ８−４）。
【００４２】
図９と図１０を参照して、図８（ａ）のメッセージ受信処理について更に詳細に説明する。
図９は、メッセージ受信モジュール３０によって行われる処理を示したＵＭＬのアクティビティ図である。実行契機は他のプロセスエンジン１０ａからメッセージを受信した時である。メッセージを受信したメッセージ受信モジュール３０は、メッセージの妥当性を検証するために妥当性判定部６２に受信したメッセージを送信し、妥当性判定の処理を呼び出す（ステップＳ９−１）。妥当性判定部６２から妥当性判定結果を受信し、受信メッセージが妥当でない場合には異常終了する（ステップＳ９−２）。受信メッセージが妥当である場合には、メッセージ保存テーブル３２に受信したメッセージを登録する（ステップＳ９−３）。次に、メッセージの受信を待機しているメッセージ取得部３３の処理を再開させる（ステップＳ９−４）。そして、正常終了する（ステップＳ９−５）。
【００４３】
図１０は、図９のステップＳ９−１で呼び出された送受信メッセージ順序正確性判定モジュール６０の妥当性判定部６２の処理を示したＵＭＬのアクティビティ図である。
最初にメッセージ受信モジュール３０から受信したメッセージから特定できるセッションＩＤに基づいてペトリネットのマーキングデータをマーキング保持テーブル６１から読み出す（ステップＳ１０−１）。対応するマーキングデータが無い場合には、受信したメッセージから特定されるペトリネットＩＤをマーキング保持テーブル６１から取得し、そのプロセス開始ノードに対応するプレースにトークンを１つ配置することにより、マーキングデータを生成して初期化し、当該生成したマーキングデータを読み出す（ステップＳ１０−２）。次に、読み出したマーキングデータに対応するペトリネットＩＤに基づいてマーキング無しペトリネット保持テーブル６３より当該ペトリネットＩＤに対応する情報を読み出す。（ステップＳ１０−３）。読み出した情報からペトリネットを構築し、同じく読み出したマーキングデータを構築したペトリネットに設定する。そして、ペトリネットを実行し、実行結果が受信メッセージに対応する受信イベント対応プレース取得テーブル６４に登録されているノードＩＤと一致するか否かによって、受信メッセージの妥当性を検証する（ステップＳ１０−４）。妥当でない場合には戻り値に「妥当でない」を設定して応答する（ステップＳ１０−５）。妥当である場合には、ペトリネットのマーキングを受信メッセージを受信した状態に変更する（ステップＳ１０−６）。変更されたマーキングデータをマーキング保持テーブル６１に登録する（ステップＳ１０−７）。そして、戻り値に「妥当である」を設定して応答する（ステップＳ１０−８）。
【００４４】
図１１を参照して、図８（ｂ）のプロセスエンジンモジュール４０から要求を受信したメッセージ取得部３３の処理について説明する。
図１１は、メッセージ取得部３３の処理を示したＵＭＬのアクティビティ図である。本処理の実行契機は、プロセスエンジンモジュール４０において、<<deferred>>アクティビティに相当する分岐処理アクティビティが実行された時、あるいは<<event>>アクティビティに相当するイベント処理アクティビティが実行された時である。
【００４５】
具体的に<<deferred>>アクティビティと<<event>>アクティビティが混在する処理を説明するため、図２（ｂ）に示す制御付遅延分岐処理に基づいてメッセージ取得部３３の処理を説明する。
最初にメッセージ取得部３３は、プロセスエンジンモジュール４０が<<deferred>>アクティビティ状態であることを受信する。図２（ｂ）では次に受信するメッセージとしてはｂ１またはｂ２の受信メッセージであるため、受信メッセージ保存テーブル３２にｂ１またはｂ２のメッセージが登録されているか否かを調べるステップＳ１１−１）。登録されていない場合には、メッセージが登録されるのを待機する（ステップＳ１１−２）。ここで、ｂ２のメッセージが登録されると、メッセージ取得部３３はメッセージ保存テーブル３２よりｂ２のメッセージを取得する（ステップＳ１１−３）。取得した時点では、<<deferred>>アクティビティ状態であるため、メッセージ保存テーブル３２よりｂ２のメッセージを削除せずに、プロセスエンジンモジュール４０にｂ２メッセージを送信する（ステップＳ１１−５）。
【００４６】
次に、ｂ２メッセージを受信したプロセスエンジンモジュール４０は<<deferred>>アクティビティ状態でｂ２メッセージを受信したことから本来ｂ２を受信するべき<<event>>アクティビティ状態に分岐し、ｂ２の<<event>>アクティビティ状態であることをメッセージ取得部３３に通知する。ｂ２の<<event>>アクティビティ状態を受信したメッセージ取得部３３は、上記と同様にメッセージ保存テーブル３２に取得したいメッセージが登録されているかを調べる（ステップＳ１１−１）。この場合、既にｂ２のメッセージは登録されているため、メッセージ保存テーブル３２からｂ２のメッセージを読み出す（ステップＳ１１−３）。ここで、プロセスの状態は<<event>>アクティビティ状態であるため、メッセージ保存テーブル３２よりｂ２のメッセージを削除する（ステップＳ１１−４）。そして、メッセージ取得部３３は、取得したｂ２のメッセージをプロセスエンジンモジュール４０に送信し、処理を終了する（ステップＳ１１−５）。このようにして、<<deferred>>アクティビティ状態であってもメッセージを受信することが可能となる。
【００４７】
なお、上記の実施形態では図２（ｂ）についてのみ説明したが、本発明はこれに限られず制御付遅延分岐処理であれば、上述した処理と同様に実現することが可能である。
【００４８】
上述の業務処理装置は内部に、コンピュータシステムを有している。そして、上述したペトリネットの処理過程やメッセージの送受信、登録、読み出しの処理過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【図面の簡単な説明】
【００４９】
【図１】本実施形態によるプロセスエンジン及びプロセスエンジンシステムを示すブロック図である。
【図２】同実施形態における制御付遅延分岐を説明するための図である。
【図３】同実施形態におけるプロセス記述からペトリネットへの変換を示した図である。
【図４】同実施形態におけるマーキング無しペトリネット保持テーブル６３のデータ構成を示した図である。
【図５】同実施形態における受信イベント対応プレース取得テーブルのデータ構成を示した図である。
【図６】同実施形態におけるマーキング保持テーブルのデータ構成を示した図である。
【図７】同実施形態におけるメッセージ保存テーブルのデータ構成を示した図である。
【図８】同実施形態におけるプロセスエンジンの処理を示したアクティビティ図である。
【図９】同実施形態におけるメッセージ受信モジュールの処理を示したアクティビティ図である。
【図１０】同実施形態における妥当性判定部の処理を示したアクティビティ図である。
【図１１】同実施形態におけるメッセージ取得部の処理を示したアクティビティ図である。
【図１２】従来の技術を説明するための図である。
【符号の説明】
【００５０】
１０  プロセスエンジン
１０ａ  他のプロセスエンジン
３１  メッセージ受信部
４０  プロセスエンジンモジュール
６０  送受信メッセージ順序正確性判定モジュール
６２  妥当性判定部
【図１】
2006072797.tif 000003
【図２】
2006072797.tif 000004
【図３】
2006072797.tif 000005
【図４】
2006072797.tif 000006
【図５】
2006072797.tif 000007
【図６】
2006072797.tif 000008
【図７】
2006072797.tif 000009
【図８】
2006072797.tif 000010
【図９】
2006072797.tif 000011
【図１０】
2006072797.tif 000012
【図１１】
2006072797.tif 000013
【図１２】
2006072797.tif 000014