JP2004258823A - Business process transaction method and system, and transaction program therefor - Google Patents
Business process transaction method and system, and transaction program therefor Download PDFInfo
- Publication number
- JP2004258823A JP2004258823A JP2003046684A JP2003046684A JP2004258823A JP 2004258823 A JP2004258823 A JP 2004258823A JP 2003046684 A JP2003046684 A JP 2003046684A JP 2003046684 A JP2003046684 A JP 2003046684A JP 2004258823 A JP2004258823 A JP 2004258823A
- Authority
- JP
- Japan
- Prior art keywords
- business process
- message
- next step
- definition
- line
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/103—Workflow collaboration or project management
Abstract
Description
【０００１】
【発明の属する技術分野】
本発明はワークフローやビジネスプロセスの処理技術に関する
【０００２】
【従来の技術】
従来ワークフローの標準化やこれを実現した各種プロダクトにみられるように、ビジネスプロセスの制御はワークフロー技術の応用として実現されてきた。この方法では、まず利用者がビジネスプロセスを定義し、ワークフローエンジンと呼ばれるソフトウェアコンポーネントがこの定義に基づき個々のステップの遂行責任を持つソフトウェアや人に対し遠隔手続き呼び出し（ＲＰＣ）やメッセージ送信などの通信手段を用い、ビジネスプロセス定義に従い順次起動ないし作業依頼することでビジネスプロセスの実行と進行状況監視を行っていた。
【０００３】
また、ビジネスプロセス定義の分野ではＸＭＬ言語を用いた記述方法の標準化が議論されていることが知られている。これらは記述のための文法規則であり、記述された定義文書の使い方について規定するものではない。
【０００４】
更に、特開平９−２６５４０８号公報で開示されているような技術では、ワークフローの分散実行という意味で類似の領域を狙ったものであり、▲１▼ビジネスプロセスの自動化というより文書ベースのワークフローの自動化であること、及び▲２▼送信されるワークフロー定義にはフロー情報のほかにプログラムが含まれ各ノードで実行されることを前提にしていること、が特徴であり、本特許の請求項としている、ＸＭＬ「文書」引渡しによる人間の操作を前提としない「ビジネスプロセス」実行の実現、ステップ実行主体の動的発見、文書情報やメッセージ情報の参照による転送、ビジネスプロセス進捗状況モニタリングのための監視ノードの設定、など各種の点において異なるもの（対象領域、技術要素）である。
【０００５】
【特許文献１】
特開平９−２６５４０８号
【０００６】
【発明が解決しようとする課題】
ワークフローエンジンという制御コンポーネントにより集中制御や管理を行うため、その集中制御・管理専用の信頼性の高いソフトウェアやハードウェアが必要であった。
【０００７】
更に、企業の境界をまたがるようなビジネスプロセスではマスタ・スレーブという関係はなじまなず、各企業システムが対等な関係で連携しビジネスプロセスを実現出来るようにすることが求められていた。
【０００８】
また、ステップを実行する主体はその実行に必要最低限の情報だけを与えて処理を行う仕組みとなっていたため、その実行主体にとって当該処理を行うことがビジネス面から妥当か否かといった判断を行う情報が十分に与えられていなかった。
【０００９】
本発明の目的は、分散処理環境におけるビジネスプロセスの実行を分散型で実現することにある。
【００１０】
【課題を解決するための手段】
上記課題を改善するために、文書記述言語を用いて記述したビジネスプロセス定義とビジネスプロセス実行に必要な情報をメッセージ送信という機能を用いステップ間で順次渡して行くという手段を用意する。これにより、制御ノードを必要とせず、参加計算機ノードが対等な立場で、更にビジネスプロセスとしてのコンテキストを理解した上で各ステップ処理を遂行出来るようになる。
【００１１】
一方、ビジネスプロセス処理の進行状況のモニタリング用に監視ノードを用意し、ステップ処理終了時点の結果通知を受けられるようにする。これを用意することで、進行状況のモニタリングだけでなく、ステップでの処理が不成功となった場合に適切な動作を取らせることが可能となる。
【００１２】
【発明の実施の形態】
以下、本発明の実施例を図面に基づいて説明する。図１は本発明における一実施例の構成を示すものである。本実施例では、ネットワーク８で接続された七つの計算機ノードを示しており、ビジネスプロセス起動ノード１がビジネスプロセスを起動する。このビジネスプロセスで最初に行うステップは布地購入ステップで、ビジネスプロセス起動ノード１は布地購入ステップ実行ノード４に図２から図６に例を示したビジネスプロセス定義文書と、図７に示すメッセージを送信する。布地購入ステップの実行終了後、図７のビジネスプロセス定義文書にある条件に従って、衣料品の製造ステップ実行ノード５または衣料品以外の製造ステップ実行ノード６のいずれかに、図２から図６に例を示したビジネスプロセス定義文書と図７のような必要な情報を含むメッセージを送信する。なおメッセージ形式は各ステップ実行ノードが公開している形式に従うものとする。これらのステップでの処理が終了すると、衣料品の製造ステップ実行ノード５または衣料品以外の製造ステップ実行ノード６のいずれかから、パッケージステップ実行ノード７に、図２から図６に例を示したビジネスプロセス定義文書と図７のような必要な情報を含むメッセージを送信する。パッケージステップ実行ノードでの処理が正常に終了すると、ビジネスプロセスが完了し、ビジネスプロセス終了報告ノードに報告を送信する。
【００１３】
ビジネスプロセスの進行状況のモニターを可能にするため、各ステップでの処理が正常に終了した時点でビジネスプロセス監視ノード２に通知メッセージを送信するものとする。ステップでの処理に問題があった場合は、ビジネスプロセス監視ノード２が、それまで正常終了の報告をあげてきた各ステップ実行ノードに対して補償動作指示などの適切な動作を実施する。
【００１４】
ここで、ビジネスプロセス起動ノード１、ビジネスプロセス監視ノード２、ビジネスプロセス終了報告ノード３の三つのノードは、同じ計算機であっても構わないし、別々の計算機としても構わない。
【００１５】
なお、ビジネスプロセス定義文書を直接メッセージの一部として送信するのではなく、ネットワーク上のアクセス可能な場所に置き、ＵＲＬのようなアクセス方法と位置情報を参照という形でメッセージに含めて送信しても良い。
【００１６】
図２〜図６は本ビジネスプロセスをＸＭＬ文書として定義した例である。本発明はＸＭＬ言語での記述例を示しているが、ＸＭＬに限定されるものではない。構造的に記載可能なデータ構造であれば適用可能である。プログラム間で通信するメッセージを文書という表現をしているが、メッセージや要求（リクエスト）でも実現可能である。図２は文書構造であり、ビジネスプロセスは説明、属性、責任システム、ビジネスプロセス・インバリアント、ビジネスプロセス事前条件、報告先、ステップ定義、ビジネスプロセス事後条件から構成されることを示す。また、その内部に複数のステップを定義することが出来る。またステップは、インバリアント、事前条件、シグニチャ、事後条件、次のステップという要素から構成されることを示している。図３以降がビジネスプロセスの定義実体の例である。
【００１７】
図７はビジネスプロセス定義文書と共に各ステップに送られるメッセージの例である。宛先によりステップを遂行する計算機とアプリケーションが指定され、ビジネスプロセスＩＤ、ステップＩＤにより、どのビジネスプロセスのどのステップの処理を行うのかを指示している。それ以降のデータはステップ実行に必要となるパラメタである。
安全性の観点からメッセージ自体をＰＫＩ等を用い暗号化することもある。
【００１８】
図８はビジネスプロセスの実行に参加する各計算機ノードにおける処理の流れの例を示したものである。９でメッセージを受信し、そのメッセージ中にビジネス定義文書が含まれていればそれを１０で取り出し、含まれていない場合には１１のようにＵＲＬ情報をもとにネットワーク経由で取り出し、１２でメッセージに含まれるパラメタ情報と併せて解析を行う。この結果に基づき、１３でビジネスプロセス定義のなかで遂行を求められているステップを発見し、処理に必要な入力情報であるシグニチャを１４で作り上げ、１５で処理の実行を行う。その結果は１６で監視ノードへ報告し、ステップ定義に含まれる条件により、１７で次に行われるべきステップを確定する。最後に１８で次のステップに渡すべきメッセージを組立て、１７で確定したステップ実行計算機ノードに宛てこれを送信する。
【００１９】
図９はこれらビジネスプロセス処理方法を実現する装置の構造例を示したものである。１９はビジネスプロセス利用者システム例であり、ディスプレイ２０、入力装置２１、ＣＰＵ２２を備えている。この装置でビジネスプロセス定義編集プログラムとＷｅｂサービスクライアントプログラム２３を動作させることで、１９の利用者はビジネスプロセス定義文書を作成するとともに、３１で示すビジネスプロセスステップ実行装置にその処理実行の依頼を行う。２４はビジネスプロセス監視装置の構成例であり、ディスプレイ２５、入力装置２６、ＣＰＵ２７を備えている。この装置でビジネスプロセス進捗管理Ｗｅｂサービスプログラム２８を動作させることで、３１で示すビジネスプロセスステップ実行装置から実行結果を随時受信し、１９のビジネスプロセス利用者システムなどから進捗状況の把握が可能となる。また、実行できなかったという結果を受け取った場合、ビジネスプロセス利用者から得た取るべき動作のテーブルなどをＤＢ２９に保管し、対応するエントリを読み出すことで動作指示を出すことができる。３１はビジネスプロセスステップ実行装置の構成例であり、ディスプレイ３２、入力装置３３、ＣＰＵ３４を備えている。この装置でビジネスプロセスステップ処理Ｗｅｂサービスプログラム３５を動作させることで、ビジネスプロセス定義に現れる各ステップの処理を実行することができる。１９、２４、３１の各装置はネットワーク３０で接続されており、オープンな通信が出来るものとしている。
【００２０】
図１０は本ビジネスプロセス処理方法とビジネスプロセス処理装置を使い、ビジネスプロセスの進捗状況監視と必要に応じ補償動作を起動するなどの対応を代行するというビジネスの方法例を示したものである。３６のビジネスプロセス利用者は、ビジネスプロセスの定義を行い、その実行を３７のビジネスプロセス処理サービス提供者に依頼する。ビジネスプロセス処理サービス提供者は依頼者に替わり、ビジネスプロセスの始めのステップを実行するステップ実行装置３８に対し、ビジネスプロセス定義文書とステップ処理に必要なパラメタ情報をメッセージとして送信する。３８はステップ処理後、図１に対する説明で述べたような方法で、３９や４０のステップ実行装置にメッセージを送信する。このとき、各ステップ処理終了後に処理終了や処理不可といった結果情報を３７に送信するが、処理不可の場合には、３７から補償行為に相当する別のビジネスプロセスが流されることもある。３７は利用者に対してビジネスプロセスの管理というサービスを提供することで対価を得る。
【００２１】
以下、例を用い本発明を実現した場合のプログラムの動作を説明する。
【００２２】
１ ビジネスプロセス開始プログラムの動作
１．１ 前提
１）ビジネスプロセス定義（ＸＭＬ文書）はビジネスプロセス開始プログラム実行前に以下のいずれかの形態で作成されているものとする。
【００２３】
すべての値が入った定義文書（例：サービス実行者名や渡すパラメタ値全て）−これはビジネスプロセスの実行者、パラメタ等を全て固定にし、途中で変更を許さないもの。この場合には、変更が行われなかったことを証明するための機構（例えば暗号化やデジタル署名）を併用することを想定する。
【００２４】
部分的にパラメタ化された定義文書（例：サービス実行者に渡す各種情報をパラメタ化したもの）―これはステップ実行結果をビジネスプロセス定義の一部として次のステップに渡す場合などを想定。
【００２５】
すべての変数要素をパラメタ化し、テンプレートとしての利用を目的とした定義文書（例：典型的な購買プロセス）−これはビジネスプロセス定義のテンプレートのライブラリやリポジトリがあり、そこからベースとなるテンプレートを検索し、カスタマイズし利用する。
【００２６】
２）上記ビジネスプロセス定義は、▲１▼ビジネスプロセス開始プログラムへの入力データ、または、▲２▼ビジネスプロセス定義リポジトリ（ＤＢ）から読み出して自らの用途用にパラメタ設定、という形態で利用する
１．２ 例に基づく処理ロジックの説明
１）ビジネスプロセスＸＭＬ定義文書の読み込みを行う
２）同文書の構文解析を行う
３）＜説明＞を画面に出力する（図３の２行目に対応し「本ビジネスプロセスは布地を購入し衣料品等を製造販売するもの」というメッセージをディスプレイに表示）
４）＜属性＞がビジネストランザクションであることをチェックする（図３の３行目「ビジネストランザクション」に対応）
５）＜責任システム＞が本ビジネスプロセス実行を開始するシステム名と一致することをチェックする（図３の４行目「ＡＢＣ製作所．ｃｏｍ／ＢＰ」に対応）
６）＜ビジネスプロセスインバリアント＞として＜ビジネスプロセスＩＤ＞が含まれていることをチェックする（図３の５から７行目「ＸＹＺ１２３４７７」に対応）
７）＜ビジネスプロセスＩＤ＞が設定されている場合はこれを本ビジネスプロセスのＩＤとして保存する（設定されていない場合には、ビジネスプロセス開始プログラムが一意な値を生成し設定）
８）＜ビジネスプロセス事前条件＞の＜布地ストック＞の値（１００）と現実のストック数（開始プログラムが情報ベースより読み出す）を比較し、現実のストック数が１００以下であることをチェックする（図３の８から１０行目「１００」に対応）
９）＜報告先＞が設定されている場合にはこれを本ビジネスプロセスでの報告先として保存する（設定されていない場合には、ここに責任システムのアドレスを設定）（図３の１１行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ＲｅｐｏｒｔＨａｎｄｌｅｒ」に対応）
１０）＜ステップ定義＞が存在することをチェックする（図３の１２行目に対応）
１１）最初に現れる＜ステップ＞の属性である識別子（サービス名）を保存する（図３の１３行目及び図７の１８行目「布地購入」に対応）
１２）保存した識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１３）ステップ実行者に渡すパラメタの準備を行う
＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の１４−１６行目に対応した図７の１９行目「７」）
＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２２行目に対応した図７の２０行目「ＡＢＣ０００８９１」）
＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２３行目に対応した図７の２１行目「木綿布地」）
＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２４行目に対応した図７の２２行目「５００００」）
＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２５行目に対応した図７の２３行目「３０００」）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２６行目に対応「２００２０７０１」）
１４）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ ヘッダ部分
・ 発信システム名：責任システム名
・ ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・ 宛先システム名：選定されたサービス提供者名
・ ステップ名：ステップ識別子
・ 監視システム名：報告者名
・ コンテンツ部分
＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１５）選定したサービス提供者へこのメッセージを送信する
１６）監視システムにビジネスプロセス文書を送付し当該ビジネスプロセスがスタートしたことを連絡する
２ 衣料材購入ステップでのプログラムの動作
２．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する（図７に例示した内容）
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では布地購入ステップ）（図３の１３行目の情報を使用）
４）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
２．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図３の１５行目に対応し、図７の１９行目の値で置き換えることに相当）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図３の２２から２６行目及び図７の２０から２４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図３の２１行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図３の２０から２７行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図３の２８から３２行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図３の２９行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図３の３０行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図３の３１行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図３の３４行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図３の３５行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図３の３９行目と４３行目が条件で、各々の遷移先が４０行目と４４行目）
・本例では、プロダクトタイプが衣料品用布地であれば衣料品製造というステップへ、プロダクトタイプが非衣料品用布地であれば非衣料品製造というステップへ、各々遷移する、という例である。
【００２７】
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の３行目または図５の３行目に対応した図７の１９行目）
＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１０行目または図５の１０行目に対応した図７の２０行目）
＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１１行目または図５の１１行目に対応した図７の２１行目）
＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１２行目または図５の１２行目に対応した図７の２２行目）
＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１３行目または図５の１３行目に対応した図７の２３行目）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１４行目または図５の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの衣料材購入ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
３ 衣料品製造ステップ
３．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では衣料品製造ステップ）（図４の１行目「衣料品製造」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
３．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図４の２−４行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図４の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図４の９行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図４の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図４の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図４の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図４の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図４の１９行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図４の２２行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図４の２３行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図４の２７行目が条件で２８行目が遷移先）
・本例では、プロダクトタイプが衣料品であればパッケージというステップへ、遷移する、という例である。
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
・＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の３行目に対応した図７の１９行目）
・＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１０行目に対応した図７の２０行目）
・＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１１行目に対応した図７の２１行目）
・＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１２行目に対応した図７の２２行目）
・＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１３行目に対応した図７の２３行目）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの衣料材製造ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
４ 非衣料品製造ステップ
４．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では非衣料品製造ステップ）（図５の１行目「非衣料品製造」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
４．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図５の２から４行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図５の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図５の９行目「ｑｑｑ．ｐｐｐ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図５の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図５の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図５の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図５の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図５の１９行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図５の２２行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図５の２３行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図５の２７行目が条件で２８行目が遷移先）
・本例では、プロダクトタイプが非衣料品であればパッケージというステップへ遷移する、という例である。
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
・＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の３行目に対応した図７の１９行目）
・＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１０行目に対応した図７の２０行目）
＊ ＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１１行目に対応した図７の２１行目）
・＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１２行目に対応した図７の２２行目）
・＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１３行目に対応した図７の２３行目）
・＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの非衣料材製造ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
５ パッケージステップ
５．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例ではパッケージステップ）（図６の１行目「パッケージ」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
５．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図６の３から５行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図６の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図６の９行目に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図６の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図６の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図６の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図６の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図６の１９行目に対応）
６）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図６の２２行目に対応）
７）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図６の２３行目に対応）
８）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図６の２６行目に対応）
・本例では、次のステップに関する情報が無いため、ビジネスプロセスは終了となり、ビジネスプロセス終了報告先へ遷移する、という例である。（図６の３１行目に対応）
９）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：ビジネスプロセス終了プログラム
・ステップ名：無し
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１０）監視システムに本ビジネスプロセスが終了したことを連絡した後、ビジネスプロセス終了プログラムへこのメッセージを送信する
６ ビジネスプロセス終了報告先の動作
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）オペレータにビジネスプロセス終了メッセージをあげる
７ ビジネスプロセス監視プログラムの動作
１）成功報告メッセージを受信した場合
・ビジネスプロセスにおける各ステップの進行状況をビジネスプロセス実行履歴情報として保存する
２）進行状況の問い合わせを受信した場合
・保存した各ステップの進行状況を回答する
３）失敗報告メッセージを受信した場合
・責任システムに連絡すると共に、定められた補償動作等を実行するために新たなビジネスプロセスを開始する
４）ステップ実行不可メッセージを受信した場合
・ビジネスプロセス定義文書にステップ実行者が特定されている場合は失敗報告メッセージを受信した場合の処理を行う。特定されていない場合には、ＵＤＤＩのような動的発見機構を用い代替のステップ実行ノードを発見し、そのノードにビジネスプロセスの続行を依頼する。
【００２８】
以上によれば、ネットワーク環境におけるビジネスプロセスの実行を、対等かつ分散型で実現できる。また、ビジネスプロセス定義を共有することで、ビジネス内容を理解した上でビジネスプロセスの遂行に参加するか否かを判断できる。
【００２９】
また、監視ノードを用意することで、分散して実行が進んで行くビジネスプロセスの進行状況をモニターすることが出来る。更に、ビジネスプロセスの実行途上で何らかのエラーが発生した場合の収拾処理も、この監視ノードを用いることで用意することが出来る。
【００３０】
また、ビジネスプロセスの各ステップを実行する計算機ノード間でデータの受け渡しが必要になった場合、単にメッセージに含めて送信するだけでなく、ＵＲＬなどの記法を使いデータの所在場所とアクセス方法だけをメッセージに含めて送信することが出来る。
【００３１】
また、ビジネスプロセスのフローにおける各ステップ実行計算機ノードの特定方法に関し、ビジネスプロセス定義文書中はサービス名やサービス内容だけを記述しておき、実行時にＵＤＤＩなどを使ったＷｅｂサービスの動的発見メカニズムを利用し物理的なサービス実行計算機ノードを特定する、ことが出来る。
【００３２】
また、オープンなネットワーク環境に展開されるビジネスプロセスの管理を代行するという行為がビジネスとして成立することを示している。
【００３３】
【発明の効果】
分散処理環境におけるビジネスプロセスの実行を分散型で実現することが可能となる。
【図面の簡単な説明】
【図１】本発明における一実施例で、布地加工パッケージビジネスプロセスシステムを本発明の方法で実現する場合のシステム構成を示すものである。
【図２】図１で参照される、ＸＭＬ言語による布地加工パッケージビジネスプロセス定義例を示すものである。
【図３】図１における衣料購入で受け付けるメッセージ例を示すものである。
【図４】図１における衣料品製造で受け付けるメッセージ例を示すものである。
【図５】図１における非衣料品製造で受け付けるメッセージ例を示すものである。
【図６】図１におけるパッケージで受け付けるメッセージ例を示すものである。
【図７】ビジネスプロセス定義文書と共に各ステップに送られるメッセージの例である。
【図８】図１で参照される、各ステップ実行計算機ノードでの処理手順例である。
【図９】図１で参照される、各ステップ実行計算機ノードの構成要素例である。
【図１０】図１で参照されるビジネスプロセス例において、起動、監視、終了、といった管理機能を代行するビジネスの構成例である。
【符号の説明】
１ ビジネスプロセス起動計算機ノード
２ ビジネスプロセス監視計算機ノード
３ ビジネスプロセス終了報告計算機ノード
４ 布地購入ステップ実行計算機ノード
５ 衣料品製造ステップ実行計算機ノード
６ 非衣料品製造ステップ実行計算機ノード
７ パッケージステップ実行計算機ノード
８ ネットワーク
９ メッセージ受信処理
１０ メッセージよりビジネスプロセス文書を抽出する処理
１１ ネットワークよりビジネスプロセス文書を抽出する処理
１２ パラメタと定義文書の解析処理
１３ 実行ステップ発見処理
１４ シグニチャの作成処理
１５ 当該ステップ実行処理
１６ 当該ステップ実行結果の監視ノードへの報告処理
１７ 次のステップ確定処理
１８ 次のステップへ送るメッセージ組立て送信処理
１９ ビジネスプロセス利用者システム（装置）
２０ ディスプレイ装置
２１ 入力装置
２２ 中央処理装置（ＣＰＵ）
２３ ビジネスプロセス定義編集プログラム及びＷｅｂサービスクライアントプログラム
２４ ビジネスプロセス監視システム（装置）
２５ ディスプレイ装置
２６ 入力装置
２７ 中央処理装置（ＣＰＵ）
２８ ビジネスプロセス進捗管理Ｗｅｂサービスプログラム
２９ 動作データベース装置
３０ ネットワーク
３１ ビジネスプロセスステップ実行装置
３２ ディスプレイ装置
３３ 入力装置
３４ 中央処理装置（ＣＰＵ）
３５ ビジネスプロセスステップ処理Ｗｅｂサービスプログラム
３６ ビジネスプロセス利用者
３７ ビジネスプロセス処理サービス
３８ ビジネスプロセスステップ実行装置
３９ ビジネスプロセスステップ実行装置
４０ ビジネスプロセスステップ実行装置[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to workflow and business process processing technology.
[0002]
[Prior art]
Conventionally, business process control has been realized as an application of workflow technology, as seen in standardization of workflows and various products that have realized this. In this method, a user first defines a business process, and a software component called a workflow engine communicates with software or persons responsible for performing individual steps based on the definition, such as remote procedure call (RPC) and message transmission. The execution and the progress monitoring of the business process have been performed by sequentially starting or requesting work according to the business process definition using means.
[0003]
In the field of business process definition, it is known that standardization of a description method using an XML language is being discussed. These are grammatical rules for description and do not prescribe how to use the described definition document.
[0004]
Furthermore, the technology disclosed in Japanese Patent Application Laid-Open No. 9-265408 aims at a similar area in terms of distributed execution of a workflow, and (1) a document-based workflow rather than a business process automation. It is characterized by the fact that it is automation, and that (2) the transmitted workflow definition contains a program in addition to the flow information and is executed on each node. Realization of "business process" execution that does not require human operation by passing XML "document", dynamic discovery of step execution entity, transfer by referring to document information and message information, monitoring for business process progress monitoring They differ in various points such as node settings (target areas, technical elements).
[0005]
[Patent Document 1]
JP-A-9-265408
[0006]
[Problems to be solved by the invention]
Since centralized control and management are performed by a control component called a workflow engine, highly reliable software and hardware dedicated to the centralized control and management were required.
[0007]
Further, in a business process that straddles the boundary of a company, the relationship of master / slave does not adapt, and it has been required that each company system can cooperate in an equal relationship to realize a business process.
[0008]
In addition, since the entity that executes the step performs the process by giving only the minimum information necessary for the execution, the execution entity determines whether or not performing the process is appropriate from a business perspective. Not enough information was given.
[0009]
An object of the present invention is to realize execution of a business process in a distributed processing environment in a distributed manner.
[0010]
[Means for Solving the Problems]
In order to solve the above problem, a means is provided for sequentially passing the business process definition described in the document description language and information necessary for the execution of the business process between the steps using a function of message transmission. As a result, the control node is not required, and the participating computer nodes can perform each step process from an equal standpoint while further understanding the context as a business process.
[0011]
On the other hand, a monitoring node is prepared for monitoring the progress of the business process processing, so that a result notification at the end of the step processing can be received. By preparing this, it becomes possible not only to monitor the progress, but also to take an appropriate action when the processing in the step becomes unsuccessful.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 shows the configuration of one embodiment of the present invention. In this embodiment, seven computer nodes connected by the network 8 are shown, and the business process activation node 1 activates a business process. The first step performed in this business process is a cloth purchase step, and the business process start node 1 transmits a business process definition document shown in FIGS. 2 to 6 and a message shown in FIG. 7 to the cloth purchase step execution node 4. I do. After the execution of the cloth purchase step, according to the conditions in the business process definition document of FIG. 7, either the clothing manufacturing
[0013]
In order to enable monitoring of the progress of the business process, a notification message is transmitted to the business process monitoring node 2 when the processing in each step ends normally. If there is a problem in the processing in the step, the business process monitoring node 2 performs an appropriate operation such as a compensation operation instruction to each step execution node that has reported the normal end.
[0014]
Here, the three nodes of the business process start node 1, the business process monitoring node 2, and the business process
[0015]
Instead of sending the business process definition document directly as a part of the message, place it in an accessible location on the network and include the access method such as URL and the location information in the form of a reference and send it. Is also good.
[0016]
2 to 6 show examples in which the business process is defined as an XML document. The present invention shows a description example in the XML language, but is not limited to XML. Any data structure that can be described structurally is applicable. Although the message communicated between the programs is expressed as a document, it can be realized by a message or a request. FIG. 2 shows a document structure, which shows that a business process is composed of a description, attributes, a responsibility system, a business process invariant, a business process precondition, a report destination, a step definition, and a business process postcondition. Also, a plurality of steps can be defined therein. Further, it is shown that the step is composed of the following elements: an invariant, a precondition, a signature, a postcondition, and a next step. FIG. 3 et seq. Are examples of business process definition entities.
[0017]
FIG. 7 is an example of a message sent to each step together with a business process definition document. The computer which executes the step and the application are specified by the destination, and the business process ID and the step ID indicate which step of which business process is to be processed. Subsequent data are parameters necessary for step execution.
From the viewpoint of security, the message itself may be encrypted using PKI or the like.
[0018]
FIG. 8 shows an example of the flow of processing in each computer node participating in the execution of a business process. At
[0019]
FIG. 9 shows an example of the structure of an apparatus for implementing these business process processing methods. Reference numeral 19 denotes an example of a business process user system, which includes a
[0020]
FIG. 10 shows an example of a business method in which the present business process processing method and the business process processing apparatus are used to monitor the progress of a business process and activate a compensation operation if necessary. The 36 business process user defines a business process, and requests the 37 business process processing service providers to execute the business process. The business process processing service provider sends a business process definition document and parameter information necessary for step processing as a message to the
[0021]
Hereinafter, the operation of the program when the present invention is realized will be described using an example.
[0022]
1 Business process start program operation
1.1 Assumption
1) It is assumed that the business process definition (XML document) is created in one of the following forms before executing the business process start program.
[0023]
Definition document containing all values (eg, service executor name and all parameter values to be passed)-This is one that fixes the executor of the business process, all the parameters, etc., and does not allow changes during the process. In this case, it is assumed that a mechanism (for example, encryption or digital signature) for proving that the change has not been performed is also used.
[0024]
Partially parameterized definition document (eg, a parameterized version of the information passed to the service executor)-This assumes that the step execution results will be passed to the next step as part of the business process definition.
[0025]
A definition document for parameterizing all variable elements and using it as a template (eg a typical purchasing process)-this is a library or repository of business process definition templates, from which the base template can be searched And customize and use.
[0026]
2) The business process definition is used in the form of (1) input data to a business process start program or (2) parameter setting for own use by reading from a business process definition repository (DB).
1.2 Description of processing logic based on examples
1) Read the business process XML definition document
2) Parse the document
3) Output <Explanation> on the screen (corresponding to the second line in FIG. 3, a message “This business process purchases fabric and manufactures and sells clothing etc.” is displayed on the display)
4) Check that <attribute> is a business transaction (corresponding to "business transaction" on the third line in FIG. 3)
5) Check that <responsibility system> matches the name of the system that starts execution of this business process (corresponds to "ABC Mfg. Com / BP" in the fourth line of FIG. 3).
6) Check that <business process ID> is included as <business process invariant> (corresponding to “XYZ123477” on
7) If <business process ID> is set, save this as the ID of this business process (if not set, the business process start program generates a unique value and sets it)
8) The value (100) of <cloth stock> in <business process preconditions> is compared with the actual stock number (the starting program is read from the information base), and it is checked that the actual stock number is 100 or less ( (Corresponds to "100" in lines 8 to 10 in FIG. 3)
9) If <report destination> is set, save it as the report destination in this business process (if not set, set the address of the responsible system here) (
10) Check that <step definition> exists (corresponds to the twelfth line in FIG. 3)
11) Save the identifier (service name), which is the attribute of <step> that appears first (corresponding to “purchase cloth” on
12) Select a step performer based on the saved identifier
-Selection by name service (when the identifier is a specific system name)
-Selection by UDDI (If the identifier is a service name, search the service by UDDI and select a service provider that meets the criteria)
13) Prepare parameters to be passed to the step executor
If <invariant> is <days>, the specific value of <days> is set as <Days> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing will occur. No ("7" on line 19 in FIG. 7 corresponding to lines 14-16 in FIG. 3)
Regarding <Order ID>, the specific value of <Order ID> is set as <OrderID> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (see FIG. ("ABC000891" on
Regarding <Order Type>, the specific value of <Order Type> is set as <OrderType> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done.
Regarding <quantity>, the specific value of <quantity> is set as <Quantity> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (see FIG. 3). (“50000” on
As for <unit price>, the specific value of <unit price> is set as <Price> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (see FIG. 3). (“3000” on
Regarding the <order date>, the specific value of the <order date> is set as <Date> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is performed (see FIG. (Corresponding to the 26th line of No. 3 “20020701”)
14) Assemble the following message to be sent to the selected service provider (the main items are illustrated in FIG. 7)
・ Header part
-Outgoing system name: Responsible system name
・ Business process ID: Business process ID
-Destination system name: Selected service provider name
-Step name: Step identifier
・ Monitoring system name: Reporter name
・ Content part
An XML document composed of a (name, value) list of <Days>, <OrderID>, <OrderType>, <Quantity>, <Price>, and <Date> (the original <days>, <order ID>, < (If order type, <quantity>, <unit price>, <order date> are not set by responsible system)
The above business process definition XML document (or its URL)
15) Send this message to the selected service provider
16) Send the business process document to the monitoring system and notify that the business process has started.
2 Operation of the program in the clothing purchase step
2.1 Assumption
1) Receive the message
2) Analyze the message and save each information of the header part and each information of the content part (contents illustrated in FIG. 7)
3) Using the step name included in the header part, determine the corresponding step from the business process definition of the content part (in the example, cloth purchase step) (use the information on the 13th line in FIG. 3)
4) If the step execution cannot be accepted, notify the monitoring node to that effect.
2.2 Description of processing logic based on examples
1) The value of "days" of "invariant"("Days") is replaced with the value of <Days> because the message has <Days> (corresponding to the 15th line in FIG. 3 and the 19th line in FIG. 7). Equivalent to the value of
2) Similarly, for <Order ID>, <Order type>, <Quantity>, <Unit price>, and <Order date>, values of <OrderID>, <OrderType>, <Quantity>, <Price>, <Date> (Corresponding to
3) Check that the value of <contract> of <preconditions> (contracted) matches the contract relationship information (read from the information base) between the stepper and the responsible system (see FIG. 3).
4) Prepare for application startup
Set the <IN signature> information that is a parameter at the time of application startup (corresponding to
・ Contract text: Set the document or URL, etc.
・ Order ID: Set a value suitable for <OrderID>
-Order type: Set a value that matches <OrderType>
-Quantity: Set a value that matches <Quantity>
-Unit price: Set a value that matches <Price>
-Order date: Set a value that matches <Date>
5) Start the application, obtain a return (result), and set <OUT signature> information (corresponding to
Success or failure: indicates whether or not the application process has been completed normally (corresponding to the 29th line in FIG. 3)
-Product type: Product type created as a result of application processing (corresponding to
-Tag ID: Identifier for delivering the product to the subsequent steps (corresponding to the 31st line in FIG. 3)
6) Confirm that the value of <success / fail> is successful: If the value is unsuccessful, the subsequent processing is not performed, and a failure report message is transmitted to the reporter.
7) Check that the value (yes) of <shipped> in <post-condition> matches the <shipped> status (read from the information base) in this step's business process (identified by ID) Yes (corresponds to line 34 in FIG. 3)
8) Check that the value (yes) of <paid> in <post-condition> matches the <paid> status (read from the information base) in this step's business process (identified by ID) Yes (corresponding to
9) Confirmation of next step
-When the value of <product type> in the return of application startup matches <product type> in <condition> of <next step>. The value of <Step ID> in the next line is the next step ID. (
In this example, if the product type is clothing fabric, the process goes to the step of manufacturing clothing, and if the product type is non-clothing fabric, the process transitions to the step of manufacturing non-garment.
[0027]
10) The identifier (service name) which is the attribute of the step determined by the above determination is read from the business process definition XML document.
11) Select a step performer based on the identifier
-Selection by name service (when the identifier is a specific system name)
-Selection by UDDI (If the identifier is a service name, search the service by UDDI and select a service provider that meets the criteria)
12) Prepare parameters to be passed to the step executor
If <invariant> is <days>, the specific value of <days> is set as <Days> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing will occur. No (line 19 in FIG. 7 corresponding to
Regarding <Order ID>, the specific value of <Order ID> is set as <OrderID> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (see FIG. (
Regarding <Order Type>, the specific value of <Order Type> is set as <OrderType> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done. (
Regarding <quantity>, the specific value of <quantity> is set as <Quantity> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (see FIG. 4). The twelfth line or the twenty-second line in FIG. 7 corresponding to the twelfth line in FIG. 5)
As for <unit price>, the specific value of <unit price> is set as <Price> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is performed (see FIG. 4).
Regarding the <order date>, the specific value of the <order date> is set as <Date> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is performed (see FIG. (4th line of FIG. 4 or 24th line of FIG. 7 corresponding to the 14th line of FIG. 5)
13) Assemble the following message to be sent to the selected service provider (the main items are illustrated in FIG. 7)
・ Header part
・ Originating system name: Responsible system name
・ Business process ID: Business process ID
-Destination system name: Name of the selected service provider
-Step name: Step identifier
・ Monitoring system name: Reporter name
・ Content part
An XML document composed of a (name, value) list of <Days>, <OrderID>, <OrderType>, <Quantity>, <Price>, and <Date> (the original <days>, <order ID>, < (If order type, <quantity>, <unit price>, <order date> are not set by responsible system)
-The above business process definition XML document (or its URL)
14) After notifying the monitoring system that the clothing purchase step of the business process has been completed, send this message to the selected service provider.
3 Clothing manufacturing steps
3.1 Assumption
1) Receive the message
2) Analyze the message and save each information of the header part and each information of the content part
3) Using the step name included in the header portion, determine the corresponding step from the business process definition of the content portion (in the example, a clothing manufacturing step) (corresponding to “clothing manufacturing” in the first line of FIG. 4).
4) If necessary, check with the monitoring node to confirm that the previous step has been completed normally.
5) If step execution cannot be accepted, notify the monitoring node to that effect.
3.2 Description of processing logic based on examples
1) The value of "days" of "<invariant>"("Days") is replaced by the value of <Days> because the message contains <Days> (corresponding to the second to fourth lines in FIG. 4).
2) Similarly, for <Order ID>, <Order type>, <Quantity>, <Unit price>, and <Order date>, values of <OrderID>, <OrderType>, <Quantity>, <Price>, <Date> And save (corresponds to
3) Check that the value of <contract> of <preconditions> (contracted) matches the contract relationship information (read from the information base) between the step performer and the responsible system (see FIG. 4). The ninth line corresponds to the description content of “xxx.yyy.com/contract.doc”)
4) Prepare for application startup
-Set <IN signature> information that is a parameter at the time of application startup (corresponding to lines 8 to 15 in FIG. 4)
・ Contract text: Set the document or URL, etc.
・ Order ID: Set a value suitable for <OrderID>
-Order type: Set a value that matches <OrderType>
-Quantity: Set a value that matches <Quantity>
-Unit price: Set a value that matches <Price>
-Order date: Set a value that matches <Date>
5) Activate the application, obtain a return (result), and set <OUT signature> information (corresponding to
Success or failure: indicates whether or not the application process has been completed normally (corresponding to the 17th line in FIG. 4)
-Product type: Type of product created as a result of application processing (corresponding to
-Tag ID: an identifier for delivering the product to the subsequent steps (corresponding to line 19 in FIG. 4)
6) Confirm that the value of <success / fail> is successful: If the value is unsuccessful, the subsequent processing is not performed, and a failure report message is transmitted to the reporter.
7) Check that the value (yes) of <shipped> in <post-condition> matches the <shipped> status (read from the information base) in this step's business process (identified by ID) Yes (corresponds to line 22 in FIG. 4)
8) Check that the value (yes) of <paid> in <post-condition> matches the <paid> status (read from the information base) in this step's business process (identified by ID) Yes (corresponding to
9) Confirmation of next step
-When the value of <product type> in the return of application startup matches <product type> in <condition> of <next step>. The value of <Step ID> in the next line is the next step ID. (
In this example, if the product type is clothing, the process transitions to the step of packaging.
10) The identifier (service name) which is the attribute of the step determined by the above determination is read from the business process definition XML document.
11) Select a step performer based on the identifier
-Selection by name service (when the identifier is a specific system name)
-Selection by UDDI (If the identifier is a service name, search the service by UDDI and select a service provider that meets the criteria)
12) Prepare parameters to be passed to the step executor
-If <Invariant> is <Days>, the specific value of <Days> is set as <Days> in the message sent with the business process definition. However, what if the responsible system sets a numerical value from the beginning? Nothing (line 19 in FIG. 7 corresponding to
-Regarding <Order ID>, the specific value of <Order ID> is set as <OrderID> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done ( (
-Regarding <Order Type>, the specific value of <Order Type> is set as <OrderType> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done ( (
-Regarding <quantity>, the specific value of <quantity> is set as <Quantity> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (FIG. 6). (The 22nd line in FIG. 7 corresponding to the 12th line)
-Regarding <unit price>, the specific value of <unit price> is set as <Price> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (FIG. 6).
Regarding the <order date>, the specific value of the <order date> is set as <Date> in the message sent with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is performed (see FIG. (
13) Assemble the following message to be sent to the selected service provider (the main items are illustrated in FIG. 7)
・ Header part
・ Originating system name: Responsible system name
・ Business process ID: Business process ID
-Destination system name: Name of the selected service provider
-Step name: Step identifier
・ Monitoring system name: Reporter name
・ Content part
An XML document including a (name, value) list of <Days>, <OrderID>, <OrderType>, <Quantity>, <Price>, <Date> (the number of <days>, <order ID>, <When order type>, <quantity>, <unit price>, and <order date> are not set by the responsible system)
-The above business process definition XML document (or its URL)
14) After notifying the monitoring system that the clothing material manufacturing step of the business process has been completed, send this message to the selected service provider.
4 Non-clothing manufacturing steps
4.1 Assumption
1) Receive the message
2) Analyze the message and save each information of the header part and each information of the content part
3) Using the step name included in the header part, determine the corresponding step from the business process definition of the content part (in the example, a non-clothing manufacturing step) (corresponding to “non-clothing manufacturing” in the first line of FIG. 5)
4) If necessary, check with the monitoring node to confirm that the previous step has been completed normally.
5) If step execution cannot be accepted, notify the monitoring node to that effect.
4.2 Description of processing logic based on examples
1) The value of “days” of “<invariant>” (“Days”) is replaced with the value of “Days” because the message has <Days> (corresponding to the second to fourth lines in FIG. 5).
2) Similarly, for <Order ID>, <Order type>, <Quantity>, <Unit price>, and <Order date>, values of <OrderID>, <OrderType>, <Quantity>, <Price>, <Date> Replace and save (corresponds to
3) Check that the value (contracted) of <contract> of <preconditions> matches the contract relationship information (read from the information base) between the step executor and the responsible system (see FIG. 5).
4) Prepare for application startup
-Set <IN signature> information that is a parameter at the time of application startup (corresponding to lines 8 to 15 in FIG. 5)
・ Contract text: Set the document or URL, etc.
・ Order ID: Set a value suitable for <OrderID>
-Order type: Set a value that matches <OrderType>
-Quantity: Set a value that matches <Quantity>
-Unit price: Set a value that matches <Price>
-Order date: Set a value that matches <Date>
5) Start the application, obtain a return (result), and set <OUT signature> information (corresponding to
Success or failure: indicates whether the application process has been completed normally (corresponding to the 17th line in FIG. 5)
-Product type: Product type created as a result of application processing (corresponding to
-Tag ID: Identifier for delivering the product to the subsequent steps (corresponding to line 19 in FIG. 5)
6) Confirm that the value of <success / fail> is successful: If the value is unsuccessful, the subsequent processing is not performed, and a failure report message is transmitted to the reporter.
7) Check that the value (yes) of <shipped> in <post-condition> matches the <shipped> status (read from the information base) in this step's business process (identified by ID) (Corresponding to
8) Check that the value (yes) of <paid> in <post-condition> matches the <paid> status (read from the information base) in this step's business process (identified by ID) (Corresponding to
9) Confirmation of next step
-When the value of <product type> in the return of application startup matches <product type> in <condition> of <next step>. The value of <Step ID> in the next line is the next step ID. (
In this example, if the product type is non-clothing, the process transits to the step of packaging.
10) The identifier (service name) which is the attribute of the step determined by the above determination is read from the business process definition XML document.
11) Select a step performer based on the identifier
-Selection by name service (when the identifier is a specific system name)
-Selection by UDDI (If the identifier is a service name, search the service by UDDI and select a service provider that meets the criteria)
12) Prepare parameters to be passed to the step executor
-If <invariant> is <days>, set the specific value of <days> as <Days> in the message sent with the business process definition. However, what if the responsible system sets the number from the beginning? Nothing (line 19 in FIG. 7 corresponding to
-Regarding <Order ID>, the specific value of <Order ID> is set as <OrderID> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done ( (
* Regarding <Order Type>, the specific value of <Order Type> is set as <OrderType> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done ( (
-Regarding <quantity>, the specific value of <quantity> is set as <Quantity> in the message sent together with the business process definition. However, if the responsible system sets the numerical value from the beginning, nothing is done (FIG. 6). (The 22nd line in FIG. 7 corresponding to the 12th line)
-Regarding <unit price>, the specific value of <unit price> is set as <Price> in the message sent together with the business process definition. However, if the responsible system sets a numerical value from the beginning, nothing is done (FIG. 6).
-Regarding <order date>, the specific value of <order date> is set as <Date> in the message sent with the business process definition. However, if the responsible system has set a numerical value from the beginning, nothing is done ( (
13) Assemble the following message to be sent to the selected service provider (the main items are illustrated in FIG. 7)
・ Header part
・ Originating system name: Responsible system name
・ Business process ID: Business process ID
-Destination system name: Name of the selected service provider
-Step name: Step identifier
・ Monitoring system name: Reporter name
・ Content part
An XML document including a (name, value) list of <Days>, <OrderID>, <OrderType>, <Quantity>, <Price>, and <Date> (the number of <days>, <order ID>, <When order type>, <quantity>, <unit price>, and <order date> are not set by the responsible system)
-The above business process definition XML document (or its URL)
14) Send this message to the selected service provider after notifying the monitoring system that the non-garment material manufacturing step of the business process has been completed.
5 Package steps
5.1 Assumption
1) Receive the message
2) Analyze the message and save each information of the header part and each information of the content part
3) Using the step name included in the header part, determine the corresponding step from the business process definition of the content part (package step in the example) (corresponding to "Package" on the first line in FIG. 6)
4) If necessary, check with the monitoring node to confirm that the previous step has been completed normally.
5) If step execution cannot be accepted, notify the monitoring node to that effect.
5.2 Description of processing logic based on examples
1) The <Days> value (“Days”) of <Invariant> is replaced with the value of <Days> because the message has <Days> (corresponding to the third to fifth lines in FIG. 6).
2) Similarly, for <Order ID>, <Order type>, <Quantity>, <Unit price>, and <Order date>, values of <OrderID>, <OrderType>, <Quantity>, <Price>, <Date> Replace and save (corresponds to
3) Check that the value of <contract> of <preconditions> (contracted) matches the contract relationship information (read from the information base) between the step executor and the responsible system (see FIG. 6). (Corresponds to line 9)
4) Prepare for application startup
-Set <IN signature> information that is a parameter at the time of application startup (corresponding to lines 8 to 15 in FIG. 6)
・ Contract text: Set the document or URL, etc.
・ Order ID: Set a value suitable for <OrderID>
-Order type: Set a value that matches <OrderType>
-Quantity: Set a value that matches <Quantity>
-Unit price: Set a value that matches <Price>
-Order date: Set a value that matches <Date>
5) Start the application, obtain a return (result), and set the <OUT signature> information (corresponding to
Success or failure: indicates whether or not the application processing has been completed normally (corresponding to the 17th line in FIG. 6)
-Product type: Product type created as a result of application processing (corresponding to
-Tag ID: Identifier for delivering the product to the subsequent steps (corresponding to line 19 in FIG. 6)
6) Check that the value (yes) of <shipped> in <post-condition> matches the <shipped> status (read from information base) in the step process's business process (identified by ID) (Corresponding to
7) Check that the value (yes) of <paid> in <post-condition> matches the <paid> status (read from the information base) in this step's business process (identified by ID) (Corresponding to
8) Confirmation of next step
-When the value of <product type> in the return of application startup matches <product type> in <condition> of <next step>. The value of <Step ID> in the next line is the next step ID. (Corresponding to
In this example, since there is no information on the next step, the business process ends, and the process transits to the business process end report destination. (Corresponding to line 31 in FIG. 6)
9) Assemble the following message to be sent to the selected service provider (the main items are illustrated in FIG. 7)
・ Header part
・ Originating system name: Responsible system name
・ Business process ID: Business process ID
-Destination system name: Business process end program
・ Step name: None
・ Monitoring system name: Reporter name
・ Content part
An XML document including a (name, value) list of <Days>, <OrderID>, <OrderType>, <Quantity>, <Price>, and <Date> (the number of <days>, <order ID>, <When order type>, <quantity>, <unit price>, and <order date> are not set by the responsible system)
-The above business process definition XML document (or its URL)
10) After notifying the monitoring system that this business process has ended, send this message to the business process end program.
6 Business process end report destination operation
1) Receive the message
2) Analyze the message and save each information of the header part and each information of the content part
3) Give a business process end message to the operator
7 Operation of business process monitoring program
1) When a success report message is received
-Save the progress of each step in the business process as business process execution history information
2) When a progress inquiry is received
・ Respond the progress of each saved step
3) When a failure report message is received
・ Contact the responsible system and start a new business process in order to execute the prescribed compensation operation, etc.
4) When a step execution impossible message is received
-If the step executor is specified in the business process definition document, perform the process when a failure report message is received. If not specified, an alternative step execution node is found using a dynamic discovery mechanism such as UDDI, and the node is requested to continue the business process.
[0028]
According to the above, the execution of the business process in the network environment can be realized on an equal and distributed basis. Further, by sharing the business process definition, it is possible to determine whether to participate in the execution of the business process after understanding the business content.
[0029]
Also, by providing monitoring nodes, it is possible to monitor the progress of business processes that are being executed in a distributed manner. Further, a collection process in the case where an error occurs during the execution of the business process can be prepared by using the monitoring node.
[0030]
When it becomes necessary to transfer data between the computer nodes that execute each step of the business process, not only send the data in a message but also use a notation such as URL to specify the location and access method of the data. It can be sent in a message.
[0031]
In addition, regarding the method for specifying each step execution computer node in the business process flow, only the service name and service contents are described in the business process definition document, and a dynamic discovery mechanism of the Web service using UDDI or the like at the time of execution is provided. It is possible to specify a physical service execution computer node by using it.
[0032]
It also indicates that the act of acting for the management of business processes deployed in an open network environment is established as a business.
[0033]
【The invention's effect】
Execution of business processes in a distributed processing environment can be realized in a distributed manner.
[Brief description of the drawings]
FIG. 1 shows a system configuration in a case where a fabric processing package business process system is realized by a method of the present invention in one embodiment of the present invention.
FIG. 2 shows an example of a fabric processing package business process definition in XML language referred to in FIG.
FIG. 3 shows an example of a message accepted for purchase of clothing in FIG. 1;
FIG. 4 shows an example of a message accepted in the manufacture of clothing in FIG.
FIG. 5 shows an example of a message accepted in non-clothing production in FIG. 1;
FIG. 6 shows an example of a message accepted by the package in FIG. 1;
FIG. 7 is an example of a message sent to each step together with a business process definition document.
FIG. 8 is an example of a processing procedure in each step execution computer node referred to in FIG. 1;
FIG. 9 is an example of components of each step execution computer node referred to in FIG. 1;
FIG. 10 is a configuration example of a business that performs management functions such as starting, monitoring, and termination in the business process example referred to in FIG. 1;
[Explanation of symbols]
1 Business process start computer node
2 Business process monitoring computer node
3 Business process end report computer node
4 Fabric purchase step execution computer node
5 Apparel manufacturing step execution computer node
6 Non-clothing manufacturing step execution computer node
7 Package step execution computer node
8 Network
9 Message reception processing
10 Process to extract business process document from message
11 Processing to extract business process documents from the network
12 Parameter and definition document analysis
13 Execution step discovery process
14 Signature Creation Process
15 Step execution process
16 Reporting the execution result of the step to the monitoring node
17 Next step confirmation processing
18. Message assembling and sending processing to be sent to the next step
19 Business process user system (device)
20 Display device
21 Input device
22 Central Processing Unit (CPU)
23 Business Process Definition Editing Program and Web Service Client Program
24 Business Process Monitoring System (Equipment)
25 Display device
26 Input device
27 Central Processing Unit (CPU)
28 Business Process Progress Management Web Service Program
29 Operation database device
30 Network
31 Business process step execution device
32 Display device
33 Input device
34 Central Processing Unit (CPU)
35 Business Process Step Processing Web Service Program
36 Business Process User
37 Business Process Processing Service
38 Business Process Step Execution Device
39 Business process step execution device
40 Business Process Step Execution Device
Claims (8)
ビジネスプロセス定義を含むメッセージを参照し、次のステップへの入力パラメタを論理メッセージとして生成し、前記次のステップを実行する計算機へ送信することにより、当該計算機がそのステップを実行するとともに前記ビジネスプロセス定義に含まれる情報を解析して実行すべき次のステップを決定し、前記ビジネスプロセス定義メッセージの処理にて生成した前記次のステップへの入力パラメタを論理メッセージとして生成して次のステップを実行する計算機ノードに送信することを特徴としたビジネスプロセス処理方法。In a business process processing method performed by a plurality of computers capable of communicating with each other,
By referring to the message including the business process definition, generating an input parameter to the next step as a logical message and transmitting the logical message to a computer that executes the next step, the computer executes the step and executes the business process. Analyzes the information included in the definition to determine the next step to be executed, generates the input parameter to the next step generated in the processing of the business process definition message as a logical message, and executes the next step A business process processing method characterized by transmitting a business process to a computer node.
ビジネスプロセス定義を含むメッセージを参照し、次のステップへの入力パラメタを論理メッセージとして生成し、前記次のステップを実行する計算機へ送信する手段と、当該計算機がそのステップを実行するとともに前記ビジネスプロセス定義に含まれる情報を解析して実行すべき次のステップを決定し、前記ビジネスプロセス定義メッセージの処理にて生成した前記次のステップへの入力パラメタを論理メッセージとして生成して次のステップを実行する計算機ノードに送信する手段とを備えたことを特徴としたビジネスプロセス処理システム。In a business process processing system where multiple computers that can communicate with each other cooperate,
Means for referring to a message including a business process definition, generating an input parameter to the next step as a logical message, and transmitting the logical message to a computer that executes the next step; Analyzes the information included in the definition to determine the next step to be executed, generates the input parameter to the next step generated in the processing of the business process definition message as a logical message, and executes the next step Means for transmitting data to a computer node to be processed.
ビジネスプロセス定義を含むメッセージを参照し、次のステップへの入力パラメタを論理メッセージとして生成し、前記次のステップを実行する計算機へ送信する機能と、当該計算機がそのステップを実行するとともに前記ビジネスプロセス定義に含まれる情報を解析して実行すべき次のステップを決定し、前記ビジネスプロセス定義メッセージの処理にて生成した前記次のステップへの入力パラメタを論理メッセージとして生成して次のステップを実行する計算機ノードに送信する機能とを有することを特徴としたビジネスプロセス処理プログラム。In a business process processing program in a business process processing system performed by a plurality of computers that can communicate with each other,
A function of referring to a message including a business process definition, generating an input parameter to a next step as a logical message, and transmitting the logical message to a computer that executes the next step; Analyzes the information included in the definition to determine the next step to be executed, generates the input parameter to the next step generated in the processing of the business process definition message as a logical message, and executes the next step A business process processing program having a function of transmitting data to a computer node that performs the processing.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003046684A JP4352722B2 (en) | 2003-02-25 | 2003-02-25 | Business process processing method and system, and processing program therefor |
| US10/650,688 US20040167795A1 (en) | 2003-02-25 | 2003-08-29 | Method and system for processing business process, and processing program therefor |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003046684A JP4352722B2 (en) | 2003-02-25 | 2003-02-25 | Business process processing method and system, and processing program therefor |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004258823A true JP2004258823A (en) | 2004-09-16 |
| JP4352722B2 JP4352722B2 (en) | 2009-10-28 |
Family
ID=32866549
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003046684A Expired - Fee Related JP4352722B2 (en) | 2003-02-25 | 2003-02-25 | Business process processing method and system, and processing program therefor |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040167795A1 (en) |
| JP (1) | JP4352722B2 (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007249598A (en) * | 2006-03-16 | 2007-09-27 | Mitsubishi Electric Corp | Processing flow control device, application execution device, processing flow control system, processing flow control method and processing flow control program |
| JP2010002963A (en) * | 2008-06-18 | 2010-01-07 | Hitachi Ltd | Service cooperation method, service cooperation program, bp (business process) node, and service cooperation system |
| WO2010018637A1 (en) * | 2008-08-15 | 2010-02-18 | 富士通株式会社 | Business flow distributed processing system and method |
| WO2011042969A1 (en) * | 2009-10-07 | 2011-04-14 | Nakashima Hirofumi | P2p-type work flow system |
| CN102810070A (en) * | 2012-07-16 | 2012-12-05 | 福建富士通信息软件有限公司 | High-performance professional ability packaging process engine and process control method thereof |
| JP2013012014A (en) * | 2011-06-29 | 2013-01-17 | Yahoo Japan Corp | Application platform device, application platform system and operation method of application platform device |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4625337B2 (en) * | 2004-02-23 | 2011-02-02 | 株式会社リコー | Process management apparatus, process management method, and process management program |
| US8650152B2 (en) * | 2004-05-28 | 2014-02-11 | International Business Machines Corporation | Method and system for managing execution of data driven workflows |
| CA2661477A1 (en) | 2006-08-13 | 2008-02-21 | Controls Force Ltd. | Systems and methods for message-based control and monitoring of a business process |
| US9020944B2 (en) | 2009-10-29 | 2015-04-28 | International Business Machines Corporation | Systems and methods for organizing documented processes |
| US8561080B2 (en) * | 2011-04-26 | 2013-10-15 | Sap Ag | High-load business process scalability |
| CN113409153A (en) * | 2020-03-16 | 2021-09-17 | 京东安联财产保险有限公司 | Business process management system, business process processing method, equipment and storage medium |
| CN112433794A (en) * | 2020-11-20 | 2021-03-02 | 金蝶云科技有限公司 | Method for controlling service progress of ERP system and related equipment |
| CN113762910B (en) * | 2020-11-27 | 2024-04-16 | 北京京东振世信息技术有限公司 | Document monitoring method and device |
| CN113435842A (en) * | 2021-06-28 | 2021-09-24 | 京东科技控股股份有限公司 | Business process processing method and computer equipment |
| CN113778572B (en) * | 2021-09-28 | 2023-09-15 | 广州四三九九信息科技有限公司 | Method for automatically linking multiple CLI programs into task flow |
| CN114785874B (en) * | 2022-06-16 | 2022-09-06 | 成都中科合迅科技有限公司 | Method for providing high-availability transmission channel based on multi-network protocol |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5754857A (en) * | 1995-12-08 | 1998-05-19 | Sun Microsystems, Inc. | Distributed asynchronous workflow on the net |
| US6463420B1 (en) * | 1999-12-30 | 2002-10-08 | General Electric Company | Online tracking of delivery status information over a computer network |
| JP2002074090A (en) * | 2000-08-29 | 2002-03-12 | Mori Seiki Co Ltd | Network system |
| US20020143660A1 (en) * | 2001-03-29 | 2002-10-03 | International Business Machines Corporation | Method and system for online shopping |
| GB2381710B (en) * | 2001-10-31 | 2004-01-21 | Sun Microsystems Inc | Method and apparatus for routing signed messages |
-
2003
- 2003-02-25 JP JP2003046684A patent/JP4352722B2/en not_active Expired - Fee Related
- 2003-08-29 US US10/650,688 patent/US20040167795A1/en not_active Abandoned
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007249598A (en) * | 2006-03-16 | 2007-09-27 | Mitsubishi Electric Corp | Processing flow control device, application execution device, processing flow control system, processing flow control method and processing flow control program |
| JP2010002963A (en) * | 2008-06-18 | 2010-01-07 | Hitachi Ltd | Service cooperation method, service cooperation program, bp (business process) node, and service cooperation system |
| WO2010018637A1 (en) * | 2008-08-15 | 2010-02-18 | 富士通株式会社 | Business flow distributed processing system and method |
| JP5024453B2 (en) * | 2008-08-15 | 2012-09-12 | 富士通株式会社 | Business flow distributed processing system and method |
| US8583754B2 (en) | 2008-08-15 | 2013-11-12 | Fujitsu Limited | Business flow distributed processing system and method |
| WO2011042969A1 (en) * | 2009-10-07 | 2011-04-14 | Nakashima Hirofumi | P2p-type work flow system |
| GB2486151A (en) * | 2009-10-07 | 2012-06-06 | Hirofumi Nakashima | P2p-type work flow system |
| CN102576429A (en) * | 2009-10-07 | 2012-07-11 | 中岛裕文 | P2P-type work flow system |
| JP5117619B2 (en) * | 2009-10-07 | 2013-01-16 | 裕文 中島 | P2P type workflow system |
| JP2013012014A (en) * | 2011-06-29 | 2013-01-17 | Yahoo Japan Corp | Application platform device, application platform system and operation method of application platform device |
| CN102810070A (en) * | 2012-07-16 | 2012-12-05 | 福建富士通信息软件有限公司 | High-performance professional ability packaging process engine and process control method thereof |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4352722B2 (en) | 2009-10-28 |
| US20040167795A1 (en) | 2004-08-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004258823A (en) | Business process transaction method and system, and transaction program therefor | |
| US6658483B1 (en) | Electronic transaction system and method and storage medium storing therein control program for executing format conversion in electronic transaction | |
| Tan et al. | A petri net-based method for compatibility analysis and composition of web services in business process execution language | |
| US7707587B2 (en) | Scheduler supporting web service invocation | |
| US7949999B1 (en) | Providing support for multiple interface access to software services | |
| US7343554B2 (en) | Mechanisms for supporting back button function of web browser as web service server in interaction with business process engine | |
| US20020143819A1 (en) | Web service syndication system | |
| Falazi et al. | Smart contract invocation protocol (SCIP): A protocol for the uniform integration of heterogeneous blockchain smart contracts | |
| US7418632B2 (en) | Service processing system, processing result management device and processing result checking method of service processing system | |
| US20050071243A1 (en) | Non-disruptive business process debugging and analysis | |
| WO2002071216A2 (en) | A method and a bridge for coupling a server and a client of different object types | |
| JP2008003709A (en) | Management device, task management method, and program | |
| JP4852906B2 (en) | Cooperation processing system and apparatus | |
| JP2006277644A (en) | Data migration support system and data migration support program | |
| KR100574158B1 (en) | Method and apparatus for controlling a multi-node process | |
| Helal et al. | The internet enterprise | |
| JP2004185166A (en) | Service part selection support method | |
| Mateo et al. | A coloured Petri net approach to model and analyse stateful workflows based on WS-BPEL and WSRF | |
| JP2004310742A (en) | Service processing method and device | |
| KR102659154B1 (en) | Appartus for providing application services, method thereof, and computationally-implementable storage medium for storing a program for providing application services | |
| KR102659150B1 (en) | Appartus for providing application services, method thereof, and computationally-implementable storage medium for storing a program for providing application services | |
| JP2000207474A (en) | Workflow support execution system | |
| JP2002288360A (en) | Method and system for purchasing software | |
| Akram et al. | Grid Business Process: Case Study | |
| Cicirelli et al. | Integration and interoperability between Jini services and web services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060216 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080728 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080819 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081020 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090119 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090421 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090622 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090707 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090720 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120807 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120807 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130807 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |