JP2008040803A

JP2008040803A - 業務監視システム及び業務監視方法及びプログラム

Info

Publication number: JP2008040803A
Application number: JP2006214405A
Authority: JP
Inventors: Koichiro Ueno; 浩一郎上野
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2006-08-07
Filing date: 2006-08-07
Publication date: 2008-02-21

Abstract

【課題】早期に業務イベントを検出し、業務プロセス監視品質を向上させることを目的とする。
【解決手段】業務監視システム１００において、ユーザインタフェース監視部１１０が、ユーザインタフェース基盤４００を監視し、業務イベントに該当する業務遂行者６０１の操作あるいは監視対象業務システム２００の応答を抽出し、抽出した操作あるいは応答をイベントデータとしてイベントキューにエンキューすることで、実行中の業務プロセスの進行状況をリアルタイムに監視することができる。
【選択図】図１

Description

本発明は、業務システムにおける業務イベントをリアルタイムに監視する技術及び複数の組織間／計算機間／システム間を跨る業務プロセスを監視する技術に関する。

特開２００５−１１５４９４号公報（「業務プロセストラッキング装置、業務プロセストラッキング方法、業務プロセストラッキングプログラム、業務プロセストラッキングプログラムを記録した記録媒体」）では、業務プロセスの状況を監視するために、業務ＤＢ（データベース）を監視してイベントを検出する方法が開示されている。
図２６はこの従来技術を示す機能とデータの構成図である。

図２６において、業務遂行者６０１は、監視対象業務システム２００を用いて実際に業務を遂行する担当者である。
監視対象業務システム２００は、ユーザインタフェース部２０１と業務ロジック部２０２と業務データ入出力部２０３とシステム連携処理部２０４から構成される。
ユーザインタフェース部２０１は、業務遂行者６０１が業務を遂行するために操作する画面である。
業務ロジック部２０２は、業務遂行者６０１の指示により業務データを処理する。
業務データ入出力部２０３は、業務ロジック部２０２が処理する業務データを業務ＤＢ３０１から入力し、業務ロジック部２０２の処理結果を業務ＤＢ３０１に出力する。
システム連携処理部２０４は、業務ロジック部２０２が処理する業務データを他システム３０２と交換する。

なお業務システムは業務毎に存在するが、以下の基盤ソフトウェアは業務内容とは独立に存在する。
ユーザインタフェース基盤４００は、ユーザインタフェース部２０１を動作させる基盤である。
ＤＢ管理システム５０１は、業務ＤＢ３０１を動作させる基盤である。
システム間メッセージ交換ミドルウェア５０２は、他システム３０２とメッセージ交換を実行する基盤である。

業務監視システム７００は以下から構成される。
業務ＤＢ監視部１０６は、ＤＢ管理システム５０１を監視して、業務イベントをイベントキュー１０１に送信する。
イベントキュー１０１は、イベントを先入れ先出し（ＦＩＦＯ）方式で格納する。
業務プロセス監視結果更新部１０２は、イベントキューからイベントを取出し、そのイベントが業務プロセスの何に該当するかをイベント／業務プロセス対応設定ＤＢ１０３から読み出し、業務プロセス監視結果ＤＢ１０５に格納する。
イベント／業務プロセス対応設定ＤＢ１０３は、イベントの種類が業務プロセスの何に該当するかの設定を格納する。
例えば図２７は、ビジネスプロセスをＵＭＬ（ＵｎｉｆｉｅｄＭｏｄｅｌｉｎｇＬａｎｇｕａｇｅ）１．４アクティビティ図の形式でイベント／業務プロセス対応設定ＤＢ１０３に格納している例である。
図２７では、あるビジネスプロセスＡを構成するアクティビティ群とそれらの間の遷移、更にその遷移のガード条件としてイベントが設定情報として格納されていることを示している。
業務プロセス監視結果ＤＢ１０５は、業務プロセスインスタンス毎にその進行状況を格納する。
例えば図２８は、図２７のビジネスプロセスＡのインスタンス毎にその進行状況を格納している業務プロセス監視結果ＤＢ１０５を示している。
業務プロセス監視部１０４は、業務プロセス監視結果ＤＢ１０５内の業務プロセスインスタンスが定められた状況になったら業務監視者６０２に警告を送信し、あるいは業務監視者６０２の操作により業務プロセス監視結果を一覧表示／グラフ表示する。
業務監視者６０２は、業務監視システム７００から進行状況の警告を受けたり、業務監視システム７００を利用して業務の進行状況を検査したりする担当者である。なお業務監視者６０２は、業務遂行者６０１と同一人である場合もあるし、その上司や顧客など別人である場合もある。

特開２００５−１６６０３８号公報（「ビジネスプロセスの進捗判断方法、変換装置、ビジネスプロセスの進捗判断コンピユ−タプログラム、ビジネスプロセス統合システムの問題解決方法」）では、業務プロセスの状況を監視するために、システム間メッセージ交換ミドルウェアを監視してイベントを検出する方法が開示されている。図２９はこの従来技術を示す機能とデータの構成図である。

システム間メッセージ監視部１０７は、システム間メッセージ交換ミドルウェア５０２を監視して、業務イベントをイベントキューに送信する。その他の構成要素は図２６と同じである。
特開２００５−１１５４９４号公報特開２００５−１６６０３８号公報

業務プロセスは、複数の組織（他企業を含む）を跨って実行される。
このため業務プロセスは、異種技術で実装された複数の業務システムを自動連携、あるいは業務遂行者の動作を仲介して、実行されている。
業務プロセス全体をリアルタイムに監視するためには、他組織が管理している、異種技術で実装された、複数の業務システム群を横断して監視する必要がある。
このような監視を行う業務監視システムは以下の理由により、監視対象の業務システムを改造せずに、監視対象業務システムとは独立に構成する必要がある。
１．業務システムが運用中であり、改造できない。
２．業務システムが他組織の管理のため、改造できない。
３．業務システム内部の実装技術が旧式であり、業務監視システムとの連携を実現できない。
４．監視により業務システムへの負荷が高まった場合、業務に悪影響を与えないように監視を控えなければならない。
５．システム構築技術に追随して業務システムが変化する場合、業務システム中に監視ロジックが入っていると、監視するための改造が毎回発生し無駄である。
６．ビジネス環境に追随して業務プロセスが変化する場合、業務システム中に監視ロジックが入っていると、監視するための改造箇所が発散してしまい効率が悪い。

業務監視システムを監視対象業務システムとは独立に構成するために、従来技術では業務システムの外側にあるミドルウェアの機能を用いて監視していた。
ミドルウェア側の機能を用いることにより、業務システム側には改造が必要ない。具体的には特開２００５−１１５４９４号公報では業務ＤＢ３０１を監視するためにＤＢ管理システム５０１の機能を、特開２００５−１６６０３８号公報ではシステム間連携を監視するためにシステム間メッセージ交換ミドルウェア５０２の機能を用いていた。
これらの従来技術では、業務ＤＢ３０１や他システム３０２など所謂リソースとの相互作用のみを監視し、その監視から検出した業務イベントが業務プロセス通り業務監視システムにエンキューされていると仮定している。このため、従来技術では以下の問題がある。
１．リソースまで処理が到達しない業務遂行者の操作による業務イベントを検出できない。
２．業務遂行者の操作からリソースの処理まで到達するのに長時間要する状況が発生した場合、業務イベントの検出が遅れる。
３．業務システム内の処理が時間を要する状況が発生した場合、リソースとの相互作用から検出したイベント間の時間間隔では業務的な精度が低い。
４．他組織が管理する業務システムのリソースに機密保護などのため接続できない場合、業務プロセスを全く監視できない。
５．複数組織を横断する業務プロセスを監視する場合、計算機／ネットワーク／監視方式がそれぞれの業務システムで異なるため、各業務システムの監視部が検出したイベントは業務監視システムのイベントキューに業務プロセス通りの順番でエンキューされないことに対処できない。

図３０〜図３３は、Ｊ２ＥＥ（Ｊａｖａ（登録商標）２ｐｌａｔｆｏｒｍ，ＥｎｔｅｒｐｒｉｓｅＥｄｉｔｉｏｎ）で業務システムを構築した場合の上記問題の具体例を示している。
図３０は業務システムの構成を示すＵＭＬ１．４オブジェクト図であり、図３１〜図３４は従来技術の問題を示すＵＭＬ１．４シーケンス図である。

図３１は上記の問題１に対応しており、業務遂行者と業務システムとの相互作用が業務ＤＢまで到達しないまま、業務遂行者がキャンセルを行っている。
例えば受注管理システムでは顧客のキャンセル操作も重要な業務イベントであり、従来技術では、業務ＤＢに処理が到達していないため、このキャンセル操作を検出できない。

図３２は上記の問題２に対応しており、業務遂行者と業務システムとの一時的な相互作用はビジネスロジックであるステートフルセッションビーンに保存され、業務遂行者が例えば数日後に操作を再開して初めて業務ＤＢまで処理が到達している。
例えば受注管理システムにおいて、注文する製品と数量を一時的に格納するショッピングカート機能をステートフルセッションビーンで実装している場合、従来技術では業務遂行者の最初の注文操作（メッセージ番号１：送信ボタン押下）から長時間経た後（メッセージ番号１８：業務データ出力のあった時点）にしか業務イベントを検出できない。

図３３は上記の問題３に対応しており、リソース監視から検出されるイベントの時間間隔（メッセージ番号１０：業務データ出力からメッセージ番号２２：業務データ出力まで）が、業務遂行者の操作間隔（メッセージ番号１２：画面表示化からメッセージ番号１３：送信ボタン押下）に比べて長い。
例えば受注管理システムにおいて、見積結果の有効期限の猶予時間を監視するには業務遂行者の操作間隔を監視したいが、従来技術ではリソース監視から検出される時間幅の広いイベント時間間隔しか監視できない。

図３４は、問題５を説明するＵＭＬ１．４配置図である。
組織Ａ用計算機には業務システム１と、それを監視する業務１用監視部がデプロイされており、組織Ｂ用と組織Ｃ用も同様である。
業務システム１／業務システム２／業務システム３はネットワークを介して業務プロセスを進行させ、その進行状況を各監視部が監視する。各監視部はイベントを検出したらそれをネットワーク経由で業務監視用計算機のイベントキューにエンキューする。
しかし、計算機／ネットワーク経路／監視方式がそれぞれの業務システムで異なるため、各監視部がイベントキューにエンキューする順番は業務プロセス通りとは限らないが、従来技術の業務プロセス監視結果更新部はこのような業務プロセス通りにならない場合に対処できない。

この発明は、上記のような問題点を解決することを主な目的としており、従来は監視できなかった業務イベントを検出し、従来より早期に業務イベントを検出し、業務的に監視したい時間間隔の精度を従来より上げ、更に組織間／計算機間／システム間を跨って業務プロセスを監視できるようにし、業務プロセス監視品質を向上させることを目的とする。

本発明に係る業務監視システムは、
監視対象業務システムの業務プロセスにおけるイベントの発生を通知するイベントデータを用いて前記業務プロセスの監視を行う業務監視システムであって、
前記監視対象業務システムを利用する端末装置と前記監視対象業務システムとの間で送受信されるメッセージを取得し、取得したメッセージを解析してイベントデータを生成し、生成したイベントデータをイベントキューにエンキューするイベントデータ生成部を有することを特徴とする。

また、本発明に係る業務監視システムは、
監視対象業務システムにおける業務プロセスの監視を行う業務監視システムであって、
前記業務プロセスのシーケンスを複数のイベントとそれぞれのイベントの遷移元ノード及び遷移先ノードとして示す業務プロセスシーケンス情報を記憶する業務プロセスシーケンス情報記憶部と、
前記業務プロセスにおけるイベントの発生を通知するイベントデータをイベントキューからデキューし、前記業務プロセスシーケンス情報に基づき、デキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードを判断し、デキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードと既にデキュー済みのイベントデータに対応するイベントの遷移元ノード及び遷移先ノードとに基づき、前記業務プロセスの開始ノードから遷移が開始しているノードの範囲を開始ノード遷移範囲として特定するとともに、前記開始ノード以外の中間ノードから遷移が開始しているノードの範囲を中間ノード遷移範囲として特定するノード遷移範囲特定部を有することを特徴とする。

本発明によれば、従来は監視できなかった業務イベントを検出し、従来より早期に業務イベントを検出し、業務的に監視したい時間間隔の精度を従来より上げることが可能となる。
また、本発明によれば、組織間／計算機間／システム間を跨って業務プロセスを監視することができる。
そして、これらの効果により、業務プロセス監視品質を向上させることが可能となる。

実施の形態１．
本実施の形態では、監視対象業務システムの業務プロセスにおけるイベントの発生を通知するイベントデータを用いて業務プロセスの監視を行う業務監視システムにおいて、業務遂行者の操作と、操作に対応する監視対象業務システムの応答を監視することにより、実行中の業務プロセスの進行状況をリアルタイムに監視する方法を説明する。

図１は、この発明の実施の形態１を示す機能とデータの構成図である。
本実施の形態に係る業務監視システム１００は、イベントデータ生成部として機能するユーザインタフェース監視部１１０を備える。
ユーザインタフェース監視部１１０は、ユーザインタフェース基盤４００を監視して、業務イベントに該当する業務遂行者６０１の操作あるいは監視対象業務システム２００の応答を、イベントキューに送信する。
図１に示すその他の要素は図２６と同じである。
なお、図１では、図２６に示している業務ＤＢ監視部１０６の記載を省略しているが、業務監視システム１００は、業務ＤＢ監視部１０６を有していてもよい。

図２は、図１に示す業務監視システム１００と監視対象業務システム２００とを同じ計算機に搭載する例を示す。
図２では、業務監視システム１００と監視対象業務システム２００を業務用サーバ装置２０００に統合し、業務遂行者６０１が業務遂行者用クライアント端末４０００（端末装置）を用いて業務用サーバ装置２０００にアクセスする。また、業務監視者６０２は、業務監視者用クライアント端末４００１を用いて業務用サーバ装置２０００にアクセスする。
また、図２の例では、図１のユーザインタフェース基盤４００は、業務遂行者用クライアント端末４０００内のユーザインタフェース基盤（クライアント側）４０１と監視対象業務システム２００内のユーザインタフェース基盤（サーバ側）４０２とに分かれる。

図３は、図１に示す業務監視システム１００と監視対象業務システム２００とを異なる計算機に搭載する例を示す。
図３では、業務監視システム１００は業務監視用サーバ装置１０００に実装され、監視対象業務システム２００は業務用サーバ装置２０００に実装されている。
業務遂行者６０１は、業務遂行者用クライアント端末４０００（端末装置）を用いて業務用サーバ装置２０００にアクセスする。
また、業務監視者６０２は、業務監視者用クライアント端末４００１を用いて業務監視用サーバ装置１０００にアクセスする。
また、図２と同様に、図３でも、図１のユーザインタフェース基盤４００は、業務遂行者用クライアント端末４０００内のユーザインタフェース基盤（クライアント側）４０１と監視対象業務システム２００内のユーザインタフェース基盤（サーバ側）４０２とに分かれる。

ここで、図５のフローチャートを参照して、ユーザインタフェース監視部１１０の動作例（業務監視方法）を概説する。なお、ユーザインタフェース監視部１１０の動作の詳細な説明は後述する。
ユーザインタフェース監視部１１０は、監視対象業務システム２００を利用する業務遂行者用クライアント端末４０００（端末装置）と監視対象業務システム２００との間で送受信されるメッセージを取得し（Ｓ５０１）（メッセージ取得ステップ）、取得したメッセージを解析する（Ｓ５０２）（イベントデータ生成ステップ）。
そして、メッセージの解析の結果、メッセージの内容が所定の業務イベントに該当するか否かを判断し（Ｓ５０３）（イベントデータ生成ステップ）、業務イベントに該当しない場合（Ｓ５０３でＮｏの場合）は処理を終了する。
一方、業務イベントに該当する場合（Ｓ５０３でＮｏの場合）は、業務イベントの内容を示すイベントデータを生成し（Ｓ５０４）（イベントデータ生成ステップ）、生成したイベントデータをイベントキュー１０１にエンキューする（Ｓ５０５）（エンキュー処理ステップ）。

次に、ユーザインタフェース監視部１１０の動作の詳細について、いくつかの具体例を用いて説明する。
各具体例はＵＭＬ１．４のコラボレーション図（図６〜図８）で示す。
図中の各オブジェクトのステレオタイプ名は、そのオブジェクトがユーザインタフェース基盤なのか、ユーザインタフェース部なのか、ユーザインタフェース部なのかを示すとする。

図６は、ユーザインタフェース基盤（クライアント側）４０１がブラウザであり、ユーザインタフェース基盤（サーバ側）４０２がＳｅｒｖｌｅｔコンテナの例である。
この場合、ユーザインタフェース監視部１１０はＳｅｒｖｌｅｔフィルタとして実装可能である。
なおＳｅｒｖｌｅｔおよびＪＳＰ（登録商標）（ＪａｖａＳｅｒｖｅｒＰａｇｅｓ）を含むＪａｖａ（登録商標）に関する仕様は「Ｊａｖａ（登録商標）ＣｏｍｍｕｎｉｔｙＰｒｏｃｅｓｓ」（ＪＣＰ）で規定されている。
Ｓｅｒｖｌｅｔフィルタとして実装されたユーザインタフェース監視部１１０は、業務遂行者６０１と監視対象業務システム２００との間で交換される情報（メッセージ）に相当するＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）リクエストとＨＴＴＰレスポンスの内容から業務イベントを検出し、イベントデータをイベントキューにエンキューする。

図９〜図１３を用いて、Ｓｅｒｖｌｅｔフィルタが業務イベントを検出する手順を説明する。
図９は、監視対象画面の例（図９（ａ））とそのＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）部分（図９（ｂ））である。
例えば、［ＡＤＤ］ボタンがクリックされると、ＨＴＴＰリクエスト内のパラメータ名Ａｄｄにパラメータ値ＡＤＤが格納されてブラウザから送信される。これを監視をするために、このＨＴＭＬフォームのＡＣＴＩＯＮ属性が指定するＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）（図９の例では“ＨＴＴＰ：／／＊＊＊＊＊” ＭＥＴＨＯＤ＝“ＰＯＳＴ”）に対してＳｅｒｖｌｅｔフィルタをＳｅｒｖｌｅｔコンテナに設定する。この設定がされ、ブラウザが該当するＵＲＬにＨＴＴＰリクエストを送信すると、ＳｅｒｖｌｅｔコンテナがＳｅｒｖｌｅｔフィルタにＨＴＴＰリクエストとＨＴＴＰレスポンスを転送する。
図１０と図１１は、Ｓｅｒｖｌｅｔフィルタが読み込む業務イベント対応一覧である。
図１０はＨＴＴＰリクエストから業務イベントを検出するためのものであり、業務イベント名と、その発生に該当するＨＴＴＰリクエスト中のパラメータ名とパラメータ値の組合せを定義する。
図１１はＨＴＴＰレスポンスから業務イベントを検出するためのものであり、業務イベント名と、その発生に該当するＨＴＴＰレスポンス中のタグ要素と値を定義する。

図１２はＳｅｒｖｌｅｔフィルタがＨＴＴＰリクエストを転送された時の動作である。
図１２において、Ｓｅｒｖｌｅｔフィルタ（ユーザインタフェース監視部１１０）は、ＨＴＴＰリクエストを転送された場合に、業務イベント対応一覧（図１０）から１行読み込み（Ｓｔｅｐ１２０１）、読み込んだパラメータ名とパラメータ値がＨＴＴＰリクエストに含まれている場合、対応する業務イベントのイベントデータを生成し（Ｓｔｅｐ１２０２）、当該業務イベントのイベントデータをエンキューする（Ｓｔｅｐ１２０３）。

図１３はＳｅｒｖｌｅｔフィルタがＨＴＴＰレスポンスを転送された時の動作である。
図１３において、Ｓｅｒｖｌｅｔフィルタ（ユーザインタフェース監視部１１０）は、ＨＴＴＰレスポンスを転送された場合に、業務イベント対応一覧（図１１）から１行読み込み（Ｓｔｅｐ１３０１）、読み込んだＨＴＭＬ要素名と値がＨＴＴＰレスポンスに含まれている場合、対応する業務イベントのイベントデータを生成し（Ｓｔｅｐ１３０２）、当該業務イベントのイベントデータをエンキューする（Ｓｔｅｐ１３０３）。

図７と図８は、ユーザインタフェース基盤（クライアント側）４０１がメールクライアントであり、ユーザインタフェース基盤（サーバ側）４０２がメールサーバとメール転送設定部の例である。
この場合、ユーザインタフェース監視部１１０はメール受信機能付き業務イベント監視部として実装可能である。
メール受信機能付き業務イベント監視部は、業務遂行者６０１と監視対象業務システム２００との間で交換されるメールの内容から業務イベントを検出し、イベントキューにエンキューする。
図７は監視対象業務システム２００から業務遂行者６０１宛てに送信するメールを、図８は業務遂行者６０１から監視対象業務システム２００宛てに送信するメールを監視している動作をそれぞれ説明している。

図１４〜図１７を用いて、メール受信機能付き業務イベント監視部が業務イベントを検出する手順を説明する。
図１４は、業務遂行者６０１が業務遂行者用クライアント端末４０００を用いて監視対象業務システム２００に送信するメール例であり、この例ではユーザ登録を依頼している。
図１５は、図１４を受信した監視対象業務システム２００が業務遂行者６０１に返信するメール例であり、この例ではユーザ登録が完了し、パスワードを通知している。
図１６はメール受信機能付き業務イベント監視部が読み込む業務イベント対応一覧であり、業務イベント名と、その発生に該当するメールの内容を定義する。
図１７はメール受信機能付き業務イベント監視部がメールを受信した時の動作である。
図１７において、メール受信機能付き業務イベント監視部（ユーザインタフェース監視部１１０）は、メールを受信した場合に、業務イベント対応一覧（図１６）から１行読み込み（Ｓｔｅｐ１７０１）、読み込んだＦｒｏｍ、Ｔｏ、Ｓｕｂｊｅｃｔ、Ｂｏｄｙの値が受信したメールに含まれている場合、対応する業務イベントのイベントデータを生成し（Ｓｔｅｐ１７０２）、当該業務イベントのイベントデータをエンキューする（Ｓｔｅｐ１７０３）。

このように、本実施の形態に係る業務監視システムでは、業務遂行者と業務システムとの相互作用を監視するユーザインタフェース監視部（イベントデータ生成部）を備える。
そして、ユーザインタフェース監視部は、監視対象業務システムを利用する端末装置と監視対象業務システムとの間で送受信されるメッセージを取得し、取得したメッセージを解析してイベントデータを生成し、生成したイベントデータをイベントキューにエンキューする。

また、ユーザインタフェース監視部は、メッセージの例として、監視対象業務システムと端末装置との間で送受信されるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）リクエスト及びＨＴＴＰレスポンスの少なくともいずれかを取得する。

また、ユーザインタフェース監視部は、メッセージの例として、監視対象業務システムと端末装置との間で送受信される電子メールを取得する。

このようなユーザインタフェース監視部を備えたことで、本実施の形態によれば、従来は監視できなかった業務イベントを検出し、従来より早期に業務イベントを検出し、業務的に監視したい時間間隔の精度を従来より上げることが可能となる。
つまり、従来技術の問題の１〜４を解決することができる。

なお、以上の説明では、ユーザインタフェース監視部の監視対象のメッセージを、ＨＴＴＰリクエスト、ＨＴＴＰレスポンス及び電子メールとしたが、これら以外のメッセージを監視対象としてもよい。

また、本実施の形態において説明した業務監視用サーバ装置１０００、業務用サーバ装置２０００、業務遂行者用クライアント端末４０００及び業務監視者用クライアント端末４００１は、例えば、図４に示すハードウェア資源により実現可能である。
なお、図４の構成は、あくまでも業務監視用サーバ装置１０００、業務用サーバ装置２０００、業務遂行者用クライアント端末４０００及び業務監視者用クライアント端末４００１のハードウェア構成の一例を示すものであり、業務監視用サーバ装置１０００、業務用サーバ装置２０００、業務遂行者用クライアント端末４０００及び業務監視者用クライアント端末４００１のハードウェア構成は図４に記載の構成に限らず、他の構成であってもよい。

図４において、業務監視用サーバ装置１０００、業務用サーバ装置２０００、業務遂行者用クライアント端末４０００及び業務監視者用クライアント端末４００１は、プログラムを実行するＣＰＵ９１１（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）９１３、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。更に、ＣＰＵ９１１は、ＦＤＤ９０４（ＦｌｅｘｉｂｌｅＤｉｓｋＤｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。

通信ボード９１５は、ネットワークに接続されている。例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。

上記プログラム群９２３には、本実施の形態及び以下に述べる実施の形態の説明において「〜部」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、本実施の形態及び以下に述べる実施の形態の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の評価」、「〜の更新」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、本実施の形態及び以下に述べる実施の形態の説明で示すフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、本実施の形態及び以下に述べる実施の形態の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」、「手段」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、本実施の形態及び以下に述べる実施の形態の「〜部」としてコンピュータを機能させるものである。あるいは、本実施の形態及び以下に述べる実施の形態の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、本実施の形態及び以下に述べる実施の形態に示す業務監視用サーバ装置１０００、業務用サーバ装置２０００、業務遂行者用クライアント端末４０００及び業務監視者用クライアント端末４００１は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

実施の形態２．
本実施の形態では、監視対象業務システムにおける業務プロセスの監視を行う業務監視システムにおいて、監視対象毎のシステム性能や、それぞれの監視手段／イベント送信経路などが異なるため、到着順番が業務プロセス定義通りでないイベントデータを補正して監視する方法を説明する。
ここで、補正するとは、イベントデータの到着順序が矛盾しているだけならば最終的に業務プロセスのシーケンスにおける終了ノードまで遷移させることができるということである。

図１８は、この発明の実施の形態２を示す機能とデータの構成図である。
図１８に示す要素のうち、補正機能付き業務プロセス監視結果更新部１２０、補正機能付き業務プロセス監視部１２１及び補正機能付き業務プロセス監視結果ＤＢ１２２以外の要素は図１及び図２６と同じである。

補正機能付き業務プロセス監視結果更新部１２０は、イベントキュー１０１からイベントデータを取出し、そのイベントデータが業務プロセスの何に該当するかをイベント／業務プロセス対応設定ＤＢ１０３から読み出し、イベントデータの到着順序が矛盾していても補正して補正機能付き業務プロセス監視結果ＤＢ１２２に格納する。
補正機能付き業務プロセス監視結果ＤＢ１２２は、業務プロセスインスタンス毎にその進行状況を補正情報も含めて格納する。
補正機能付き業務プロセス監視部１２１は、補正機能付き業務プロセス監視結果ＤＢ１２２内の補正情報も含めた業務プロセスインスタンスが定められた状況になったら業務監視者６０２に警告を送信し、あるいは業務監視者６０２の操作により補正情報も含めた業務プロセス監視結果を一覧表示／グラフ表示する。
ここで、補正情報とは、後述する仮終点トークンが位置するアクティビティを示す。仮終点トークンが位置するアクティビティは、そこに至る途中の遷移を起こすイベントをまだ受信していないため、業務プロセスインスタンスの未確認最新状況である。また、後述するカレントトークンが位置するアクティビティは、受信したイベントで順番に遷移しているため、業務プロセスインスタンスの確認済み状況である。
補正機能付き業務プロセス監視結果更新部１２０は、業務プロセスインスタンスの未確認最新状況も処理できることが特徴である。
状況の監視のしかたは、確認済み状況と未確認最新状況では同じである。例えば、仮終点トークンあるいはカレントトークンが位置するアクティビティが、その状態でいる期間が期限を越えていないかなどである。

本実施の形態では、補正機能付き業務プロセス監視結果ＤＢ１２２が業務プロセスの進行状況を管理するためにペトリネットの概念「トークン」を用いる。
トークンは、業務プロセスを構成するアクティビティ間（アクティビティ図上ではノード間）をイベント発生に伴って移動する。
トークンは、ＵＭＬアクティビティ図上のフォークノードで分裂し、ジョインノードで合体する。
更に補正機能を実現するために、ペトリネット用語「トークン」を以下のように拡張する。
カレントトークンは、アクティビティ図で定義されたシーケンス通りに矛盾無く遷移した結果、現在アクティブなノード上に存在するトークンである。カレントトークンは、現在アクティブなノードから遷移を起こすイベント発生により、その遷移先ノードに移動する。
仮始点トークンと仮終点トークンはペアで用い、現在アクティブなノードから遷移させるのではない矛盾したイベントが到着した場合に使用する。矛盾したイベントの到着とは、本来は現在アクティブなノードから遷移させるイベントが来るはずなのに、イベントの到着順番が入れ替わって、後から来るべきイベントが先に到着したことを意味する。
このように到着順が矛盾したイベントが来た場合にそれを記録するために、そのイベントにより遷移する遷移元ノードに仮始点トークンを生成し、その遷移先ノードに仮終点トークンを生成する。このように後から起こるべきなのに先に遷移したことを記録した仮始点トークンと仮終点トークンは、カレントトークンが同一ノード上に遷移してくると、消滅する。
イベントの到着順が途中は矛盾していも、最終的に全てのイベントが到着した状況では、全ての仮始点トークンと仮終点トークンは消滅し、カレントトークンは終了ノード上に遷移している。
補正機能付き業務プロセス監視結果更新部１２０は、カレントトークン、仮始点トークン、仮終点トークンを用いて業務プロセスの進行状況を更新することが特徴である。
補正機能付き業務プロセス監視結果ＤＢ１２２は、カレントトークン、仮始点トークン、仮終点トークンを含めて格納することが特徴である。

イベント／業務プロセス対応設定ＤＢ１０３は、前述したように、例えば図２７に示す形態で、業務プロセスのシーケンスを複数のイベントとそれぞれのイベントの遷移元ノード及び遷移先ノードとして示す情報（業務プロセスシーケンス情報）を記憶している。イベント／業務プロセス対応設定ＤＢ１０３は、業務プロセスシーケンス情報記憶部の例である。
補正機能付き業務プロセス監視結果更新部１２０は、業務プロセスにおけるイベントの発生を通知するイベントデータをイベントキュー１０１からデキューし、業務プロセスシーケンス情報に基づき、デキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードを判断し、デキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードと既にデキュー済みのイベントデータに対応するイベントの遷移元ノード及び遷移先ノードとに基づき、業務プロセスの開始ノードから遷移が開始しているノードの範囲を開始ノード遷移範囲として特定するとともに、開始ノード以外の中間ノードから遷移が開始しているノードの範囲を中間ノード遷移範囲として特定する。補正機能付き業務プロセス監視結果更新部１２０は、ノード遷移範囲特定部の例である。

また、補正機能付き業務プロセス監視結果更新部１２０（ノード遷移範囲特定部）は、新たにイベントデータをデキューする度に、新たにデキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードと既にデキュー済みのイベントデータに対応するイベントの遷移元ノード及び遷移先ノードとに基づき、開始ノード遷移範囲及び前記中間ノード遷移範囲の少なくともいずれかを更新する。
そして、補正機能付き業務プロセス監視結果更新部１２０は、更新の結果、開始ノード遷移範囲と中間ノード遷移範囲とが連結する場合に、開始ノード遷移範囲に中間ノード遷移範囲を連結させた範囲を新たな開始ノード遷移範囲として更新する。

そして、前述したように、開始ノード遷移範囲の特定にあたり、補正機能付き業務プロセス監視結果更新部１２０は、業務プロセスにおける開始イベントのイベントデータをデキューした場合に、開始イベントの遷移先ノードに対してペトリネットのカレントトークンを生成して開始ノード遷移範囲を特定し、中間ノード遷移範囲の特定にあたり、業務プロセスにおける開始イベント以外のイベントのイベントデータをデキューした場合に、当該イベントの遷移元ノードと遷移先ノードに対してペトリネットのトークンを拡張した仮始点トークンと仮終点トークンとをそれぞれ生成して中間ノード遷移範囲を特定する。
また、補正機能付き業務プロセス監視結果更新部１２０は、新たにイベントデータをデキューする度に、カレントトークン及び仮終点トークンの少なくともいずれかを移動させて、開始ノード遷移範囲及び中間ノード遷移範囲の少なくともいずれかを更新する。
更に、補正機能付き業務プロセス監視結果更新部１２０は、更新の結果、開始ノード遷移範囲と中間ノード遷移範囲とが連結する場合に、カレントトークンを仮終点トークンの位置まで移動させるとともに、仮始点トークンと仮終点トークンとを削除して、開始ノード遷移範囲に中間ノード遷移範囲を連結させた範囲を新たな開始ノード遷移範囲として更新する。

本実施の形態に係る業務監視システム１００と監視対象業務システム２００との関係は、図３４に示す関係となることが考えられる。
つまり、監視対象業務システムがそれぞれ異なる組織用計算機（組織Ａ用計算機から組織Ｃ用計算機）に実装され、業務監視システムが業務監視用計算機に実装される形態が考えられる。そして、それぞれの組織用計算機からのイベントデータが業務監視用計算機に実装されている業務監視システムに集められ、従来では、イベントデータの到着順が業務プロセスのシーケンス通りにならなかった場合に対応できなかったが、本実施の形態では、上記のカレントトークン、仮始点トークン及び仮終点トークンを用いて、イベントデータの到着順が業務プロセスのシーケンス通りにならなかった場合にも対応可能である。
図３４に示す関係に則して、図１８に示す構成の計算機構成は、図１９に示すように、監視対象業務システム２００が業務用サーバ装置２０００上に存在し、業務監視システム１００が業務監視用サーバ装置１０００上に存在するという形態が考えられる。なお、図１９における他システム３０２は、業務用サーバ装置２０００とは別の計算機上に存在するものとする。
また、図２０に示すように、業務監視システム１００が監視対象としているいずれかの監視対象業務システム２００と業務監視システム１００とが同一の計算機（業務用サーバ装置２０００）に実現されていてもよい。この場合にも、他システム３０２は、業務用サーバ装置２０００とは別の計算機上に存在するものとする。
なお、作図上の都合から、図１９及び図２０では、図１８に示したシステム間メッセージ監視部１０７を省略しているが、図１９及び図２０にはシステム間メッセージ監視部１０７が含まれているものとする。

次に、本実施の形態に係る補正機能付き業務プロセス監視結果更新部１２０の動作（業務監視方法）について説明する。
図２１は、補正機能付き業務プロセス監視結果更新部１２０の動作例を示す。
図２１はＵＭＬ１．４アクティビティ図を用いて、１つのイベントインスタンスをデキューしてそのイベントインスタンスを処理する手順を示している。１つのイベントインスタンスの処理が終了すれば、次にデキューしたイベントに対してまた図２１の先頭から処理を開始する。
図２１において、Ｓｔｅｐ１がデキュー処理ステップに相当し、Ｓｔｅｐ２以降がノード遷移範囲特定ステップに相当する。
図２１に示す各ステップは、図２２〜２４に示す具体例を参照しながら、説明する。

図２２〜図２４は、様々なバリエーションのイベントデータ到着順序における補正機能付き業務プロセス監視結果更新部１２０の処理例を示している。
これらは図２７に示すイベント／業務プロセス対応設定ＤＢの内容（ビジネスプロセスＡ）を例として対象にしている。
図２２〜図２４の縦軸は到着順にイベントを上から下に並べている。横軸はノードを並べている。縦軸と横軸の交差セルにはトークンの振舞いを記述している。交差セルに記述されているトークンの表記法は、「＜＃＞」がカレントトークン、「（＃）」が仮始点トークン、「｛＃｝」が仮終点トークン、「＃」は各トークンを識別するキー値である。

図２２は、図２７に示す業務プロセスのシーケンスにおいて最初に到着すべきであるイベントデータが実際には最後に到着した例を示している。
図２１に基づいて、補正機能付き業務プロセス監視結果更新部１２０の動作を説明する。
Ｓｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ１が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ０からＡｃｔｉｖｉｔｙ１への遷移」が代入される。ここで、Ｓｔｅｐ２に示す「遷移設定情報」とは、ｅｖｅｎｔの種類が遷移（ｔｒａｎｓｉｔｉｏｎ）させる始点ノードと終了ノードのペアの情報である。例えば図２７のイベント／業務プロセス対応設定ＤＢの格納例の場合では、図２５に示す情報が遷移設定情報となる。
Ｓｔｅｐ３では変数ｅｖｅｎｔに代入されているｅｖｅｎｔ１は１番目に到着したものなので、変数ｐｒｏｃｅｓｓは空である。
変数ｐｒｏｃｅｓｓが空なのでＳｔｅｐ４が実行され、新たなプロセスインスタンスが生成され変数ｐｒｏｃｅｓｓに代入され、Ｓｔｅｐ５により補正機能付き業務プロセス監視結果ＤＢ１２２に格納される。なお、Ｓｔｅｐ３の「ｅｖｅｎｔに対応する業務プロセス」とはｅｖｅｎｔにより遷移を引き起こされる業務プロセスのことである。例えば図２７のイベント／業務プロセス対応設定ＤＢの格納例では、ｅｖｅｎｔ０に対応する業務プロセスはビジネスプロセスＡである。また、「業務プロセスインスタンス」は「業務プロセス」の個々の実体である。
次に、変数ｔｒａｎｓｉｔｉｏｎが「Ａｃｔｉｖｉｔｙ０からＡｃｔｉｖｉｔｙ１への遷移」なので、Ｓｔｅｐ７が実行され、Ａｃｔｉｖｉｔｙ０上に仮始点トークンが生成される。これは図２２では、行「ｅｖｅｎｔ１」の列「Ａｃｔｉｖｉｔｙ０」上の「（１）生成」が該当する。
Ｓｔｅｐ８により変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるＡｃｔｉｖｉｔｙ１上に仮終点トークンが生成される。これは図２２では行「ｅｖｅｎｔ１」の列「Ａｃｔｉｖｉｔｙ１」上の「｛１｝生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンがないので何も実行しない。
変数ｐｒｏｃｅｓｓ上にはまだカレントトークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、最初にデキューしたｅｖｅｎｔ１の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ２が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ１からフォークノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓにはｅｖｅｎｔ１の処理で生成された業務プロセスインスタンスが代入される。変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行され、Ａｃｔｉｖｉｔｙ１に含まれるトークンとして仮終点トークン｛１｝を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔにはカレントトークンが含まれていないので何もしない。
Ｓｔｅｐ１４では仮終点トークン｛１｝を変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるフォークノードへ移動させる。これは図２２では行「ｅｖｅｎｔ２」の列「フォーク１」上の「｛１｝移動」が該当する。
Ｓｔｅｐ９により仮終点トークン｛１｝はフォークノードにより分裂して遷移する。これは図２２では行「ｅｖｅｎｔ２」の列「Ａｃｔｉｖｉｔｙ２」上の「｛１−１｝分裂」と、列「Ａｃｔｉｖｉｔｙ３」上の「｛１−２｝分裂」に該当する。
変数ｐｒｏｃｅｓｓ上にはまだカレントトークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ２の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ３が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ２からジョインノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓにはｅｖｅｎｔ１の処理で生成された業務プロセスインスタンスが代入される。変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ２に含まれるトークンとして仮終点トークン｛１−１｝を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔにはカレントトークンが含まれていないので何もしない。
Ｓｔｅｐ１４では仮終点トークン｛１−１｝を変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるジョインノードへ移動させる。これは図２２では行「ｅｖｅｎｔ３」の列「ジョイン１」上の「｛１−１｝移動」が該当する。
Ｓｔｅｐ９では遷移可能なトークンがないので何も実行しない。
変数ｐｒｏｃｅｓｓ上にはまだカレントトークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ３の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ４が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ３からジョインノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓにはｅｖｅｎｔ１の処理で生成された業務プロセスインスタンスが代入される。変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ３に含まれるトークンとして仮終点トークン｛１−２｝を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔにはカレントトークンが含まれていないので何もしない。
Ｓｔｅｐ１４では仮終点トークン｛１−２｝を変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるジョインノードへ移動させる。これは図２２では行「ｅｖｅｎｔ４」の列「ジョイン１」上の「｛１−２｝移動」が該当する。
Ｓｔｅｐ９では仮終点トークン｛１−１｝と｛１−２｝を含むジョイン１内でトークンが合体しＡｃｔｉｖｉｔｙ４に移動する。これは図２２では行「ｅｖｅｎｔ４」の列「ジョイン１」上の「｛１｝合体」と、列「Ａｃｔｉｖｉｔｙ４」上の「｛１｝移動」が該当する。
変数ｐｒｏｃｅｓｓ上にはまだカレントトークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ４の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ５が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ４から終了ノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓにはｅｖｅｎｔ１の処理で生成された業務プロセスインスタンスが代入される。変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行され、Ａｃｔｉｖｉｔｙ４に含まれるトークンとして仮終点トークン｛１｝を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔにはカレントトークンが含まれていないので何もしない。
Ｓｔｅｐ１４では仮終点トークン｛１｝を変数ｔｒａｎｓｉｔｉｏｎの終点ノードである終了ノードへ移動させる。これは図２２では行「ｅｖｅｎｔ５」の列「終了ノード」上の「｛１｝移動」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。変数ｐｒｏｃｅｓｓ上にはまだカレントトークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ３の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ０が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「開始ノードからＡｃｔｉｖｉｔｙ１への遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓにはｅｖｅｎｔ１の処理で生成された業務プロセスインスタンスが代入される。変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードなので、Ｓｔｅｐ１５が実行される。
Ｓｔｅｐ１５では変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるＡｃｔｉｖｉｔｙ０上にカレントトークン＜１＞」が生成される。これは図２２では行「ｅｖｅｎｔ０」の列「Ａｃｔｉｖｉｔｙ０」上の「＜１＞生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。カレントトークン＜１＞が存在するＡｃｔｉｖｉｔｙ０には仮始点トークン（１）が存在するのでＳｔｅｐ１０が実行される。
Ｓｔｅｐ１０ではカレントトークン＜１＞をＡｃｔｉｖｉｔｙ０上の仮始点トークン（１）のペアである仮終点トークン｛１｝の終了ノードまで移動させる。これは図２２では行「ｅｖｅｎｔ０」の列「終了ノード」上の「＜１＞移動」に該当する。
Ｓｔｅｐ１１ではカレントトークン＜１＞と同じノードにある仮終点トークン｛１｝とそのペアである仮始点トークン（１）を削除する。これは図２２では行「ｅｖｅｎｔ０」の列「終了ノード」上の「｛１｝削除」と、列「Ａｃｔｉｖｉｔｙ０」上の「（１）削除」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ０の処理が終了する。
以上で到着順が矛盾したイベント群を補正することができる。

図２３は途中でイベントデータが抜けてそれが最後に到着した例を示す。
図２１に基づいて、補正機能付き業務プロセス監視結果更新部１２０の動作を説明する。
Ｓｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ０が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「開始ノードからＡｃｔｉｖｉｔｙ０への遷移」が代入される。
Ｓｔｅｐ３では変数ｅｖｅｎｔに代入されているｅｖｅｎｔ０は１番目に到着したものなので、変数ｐｒｏｃｅｓｓは空である。
変数ｐｒｏｃｅｓｓは空なのでＳｔｅｐ４が実行され、新たなプロセスインスタンスが生成され変数ｐｒｏｃｅｓｓに代入され、Ｓｔｅｐ５により補正機能付き業務プロセス監視結果ＤＢ１２２に格納される。変数ｔｒａｎｓｉｔｉｏｎは「開始ノードからＡｃｔｉｖｉｔｙ０への遷移」なので、Ｓｔｅｐ１５が実行される。
Ｓｔｅｐ１５では変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるＡｃｔｉｖｉｔｙ０上にカレントトークン＜１＞が生成される。これは図２３では行「ｅｖｅｎｔ０」の列「Ａｃｔｉｖｉｔｙ０」上の「＜１＞生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、最初にデキューしたｅｖｅｎｔ０の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ１が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ０からＡｃｔｉｖｉｔｙ１への遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行され、Ａｃｔｉｖｉｔｙ０に含まれるトークンとしてカレントトークン＜１＞を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。
変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔに含まれるカレントトークン＜１＞が、変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるＡｃｔｉｖｉｔｙ１へ移動する。これは図２３では「ｅｖｅｎｔ１」の列「Ａｃｔｉｖｉｔｙ１」上の「＜１＞移動」が該当する。
Ｓｔｅｐ１４では変数ｔｏｋｅｎＬｉｓｔ中に仮終点トークンが無いので何もしない。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。変数ｐｒｏｃｅｓｓ上には仮トークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ１の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ２が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ１からフォークノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行され、Ａｃｔｉｖｉｔｙ１に含まれるトークンとしてカレントトークン＜１＞を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。
変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔに含まれるカレントトークン＜１＞を変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるフォークノードへ移動する。これは図２３では行「ｅｖｅｎｔ２」の列「フォーク１」上の「＜１＞移動」が該当する。
Ｓｔｅｐ１４ではｔｏｋｅｎＬｉｓｔには仮終点トークンが無いのので何も実行しない。
Ｓｔｅｐ９によりカレントトークン＜１＞が分裂して、カレントトークン＜１−１＞とカレントトークン＜１−２＞が移動する。これは図２２では行「ｅｖｅｎｔ２」の列「Ａｃｔｉｖｉｔｙ２」上の「＜１−１＞分裂」と、列「Ａｃｔｉｖｉｔｙ３」上の「＜１−２＞分裂」に該当する。
変数ｐｒｏｃｅｓｓ上には仮トークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ２の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ４が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ３からジョインノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ３に含まれるトークンとしてカレントトークン＜１−２＞を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。
変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔに含まれるカレントトークン＜１−２＞が変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるジョインノードに移動する。これは図２３では行「ｅｖｅｎｔ４」の列「ジョイン１」上の「＜１−２＞移動」が該当する。
Ｓｔｅｐ１４ではｔｏｋｅｎＬｉｓｔには仮終点トークンが無いので何も実行しない。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
変数ｐｒｏｃｅｓｓ上には仮トークンが存在しないため、条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ４の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ５が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ４から終了ノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ４に含まれるトークンが無いので変数ｔｏｋｅｎＬｉｓｔには何も代入されない。
変数ｔｏｋｅｎＬｉｓｔは空なのでＳｔｅｐ７が実行される。
Ｓｔｅｐ７では変数ｔｒａｎｓｉｔｉｏｎの始点ノードであるＡｃｔｉｖｉｔｙ４上に仮始点トークン（１）を生成する。これは図２３では、行「ｅｖｅｎｔ４」の列「Ａｃｔｉｖｉｔｙ４」上の「（１）生成」が該当する。
Ｓｔｅｐ８では変数ｔｒａｎｓｉｔｉｏｎの終点ノードである終了ノード上に仮終点トークン｛１｝を生成する。これは図２３では行「ｅｖｅｎｔ４」の列「終了ノード」上の「｛１｝生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ５の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ３が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ２からジョインノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ２に含まれるトークンとしてカレントトークン＜１−１＞を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔに含まれるカレントトークン＜１−１＞を変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるジョインノードへ移動させる。これは図２３では行「ｅｖｅｎｔ３」の列「ジョイン１」上の「＜１−１＞移動」が該当する。
Ｓｔｅｐ１４では変数ｔｏｋｅｎＬｉｓｔには仮終点トークンが含まれていないので何も実行しない。
Ｓｔｅｐ９ではジョインノードでカレントトークン＜１−１＞とカレントトークン＜１−２＞が揃ったのでカレントトークン＜１＞として合体し、Ａｃｔｉｖｉｔｙ４へ移動する。これは図２３では、行「ｅｖｅｎｔ３」の列「ジョイン１」上の「＜１＞合体」と、列「Ａｃｔｉｖｉｔｙ４」上の「＜１＞移動」が該当する。
変数ｐｒｏｃｅｓｓ上のカレントトークン＜１＞が存在するＡｃｔｉｖｉｔｙ４には仮始点トークン（１）が存在するためＳｔｅｐ１０が実行される。
Ｓｔｅｐ１０ではカレントトークン＜１＞をＡｃｔｉｖｉｔｙ４上の仮始点トークン（１）のペアである仮終点トークン｛１｝の終了ノードまで移動させる。これは図２３では行「ｅｖｅｎｔ３」の列「終了ノード」上の「＜１＞移動」に該当する。
Ｓｔｅｐ１１ではカレントトークン＜１＞と同じノードにある仮終点トークン｛１｝とそのペアである仮始点トークン（１）を削除する。これは図２３では行「ｅｖｅｎｔ３」の列「終了ノード」上の「｛１｝削除」と、列「Ａｃｔｉｖｉｔｙ４」上の「（１）削除」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ３の処理が終了する。
以上で到着順が矛盾したイベント群を補正することができる。

図２４は、イベントデータがランダムに到着した例を示す。
図２１に基づいて、補正機能付き業務プロセス監視結果更新部１２０の動作を説明する。
Ｓｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ２が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ１からフォークノードへの遷移」が代入される。
Ｓｔｅｐ３では変数ｅｖｅｎｔに代入されているｅｖｅｎｔ２は１番目に到着したものなので、変数ｐｒｏｃｅｓｓは空である。
変数ｐｒｏｃｅｓｓは空なのでＳｔｅｐ４が実行され、新たなプロセスインスタンスが生成され変数ｐｒｏｃｅｓｓに代入され、Ｓｔｅｐ５により補正機能付き業務プロセス監視結果ＤＢ１２２に格納される。
変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類は開始ノードではないのでＳｔｅｐ７が実行される。
Ｓｔｅｐ７では変数ｔｒａｎｓｉｔｉｏｎの始点ノードであるＡｃｔｉｖｉｔｙ１上に仮始点トークン（１）を生成する。これは図２４では、行「ｅｖｅｎｔ２」の列「Ａｃｔｉｖｉｔｙ１」上の「（１）生成」が該当する。
Ｓｔｅｐ８では変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるフォークノード上に仮終点トークン｛１｝を生成する。これは図２４では行「ｅｖｅｎｔ２」の列「フォーク１」上の「｛１｝生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ２の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ５が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ４から終了ノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ４に含まれるトークンが無いので変数ｔｏｋｅｎＬｉｓｔには何も代入されない。
変数ｔｏｋｅｎＬｉｓｔは空なのでＳｔｅｐ７が実行される。
Ｓｔｅｐ７では変数ｔｒａｎｓｉｔｉｏｎの始点ノードであるＡｃｔｉｖｉｔｙ４上に仮始点トークン（２）を生成する。これは図２４では、行「ｅｖｅｎｔ５」の列「Ａｃｔｉｖｉｔｙ４」上の「（２）生成」が該当する。
Ｓｔｅｐ８では変数ｔｒａｎｓｉｔｉｏｎの終点ノードである終了ノード上に仮終点トークン｛２｝を生成する。これは図２４では行「ｅｖｅｎｔ５」の列「終了ノード」上の「｛２｝生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ５の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ１が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ０からＡｃｔｉｖｉｔｙ１への遷移」が代入される。Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ０に含まれるトークンが無いので変数ｔｏｋｅｎＬｉｓｔには何も代入されない。
変数ｔｏｋｅｎＬｉｓｔは空なのでＳｔｅｐ７が実行される。
Ｓｔｅｐ７では変数ｔｒａｎｓｉｔｉｏｎの始点ノードであるＡｃｔｉｖｉｔｙ０上に仮始点トークン（３）を生成する。これは図２４では、行「ｅｖｅｎｔ１」の列「Ａｃｔｉｖｉｔｙ０」上の「（３）生成」が該当する。
Ｓｔｅｐ８では変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるＡｃｔｉｖｉｔｙ１上に仮終点トークン｛３｝を生成する。これは図２４では行「ｅｖｅｎｔ１」の列「Ａｃｔｉｖｉｔｙ１」上の「｛３｝生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ１の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ３が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ２からジョインノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ２に含まれるトークンが無いので変数ｔｏｋｅｎＬｉｓｔには何も代入されない。
変数ｔｏｋｅｎＬｉｓｔは空なのでＳｔｅｐ７が実行される。
Ｓｔｅｐ７では変数ｔｒａｎｓｉｔｉｏｎの始点ノードであるＡｃｔｉｖｉｔｙ２上に仮始点トークン（４）を生成する。これは図２４では、行「ｅｖｅｎｔ３」の列「Ａｃｔｉｖｉｔｙ２」上の「（４）生成」が該当する。
Ｓｔｅｐ８では変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるジョインノード上に仮終点トークン｛４｝を生成する。これは図２４では行「ｅｖｅｎｔ３」の列「ジョイン１」上の「｛４｝生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ３の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ０が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「開始ノードからＡｃｔｉｖｉｔｙ０への遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードなのでＳｔｅｐ１５が実行される。
Ｓｔｅｐ１５では変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるＡｃｔｉｖｉｔｙ０上にカレントトークン＜１＞が生成される。これは図２４では行「ｅｖｅｎｔ０」の列「Ａｃｔｉｖｉｔｙ０」上の「＜１＞生成」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
変数ｐｒｏｃｅｓｓ上のカレントトークン＜１＞が存在するＡｃｔｉｖｉｔｙ０上に仮始点トークン（３）が存在するのでＳｔｅｐ１０が実行される。
Ｓｔｅｐ１０ではカレントトークン＜１＞をＡｃｔｉｖｉｔｙ０上の仮始点トークン（３）のペアである仮終点トークン｛３｝のＡｃｔｉｖｉｔｙ１まで移動させる。これは図２４では行「ｅｖｅｎｔ０」の列「Ａｃｔｉｖｉｔｙ１」上の「＜１＞移動」に該当する。
Ｓｔｅｐ１１ではカレントトークン＜１＞と同じノードにある仮終点トークン｛３｝とそのペアである仮始点トークン（３）を削除する。これは図２４では行「ｅｖｅｎｔ０」の列「Ａｃｔｉｖｉｔｙ１」上の「｛３｝削除」と、列「Ａｃｔｉｖｉｔｙ０」上の「（３）削除」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。
変数ｐｒｏｃｅｓｓ上のカレントトークン＜１＞が存在するＡｃｔｉｖｉｔｙ１上に仮始点トークン（１）が存在するのでＳｔｅｐ１０が実行される。
Ｓｔｅｐ１０ではカレントトークン＜１＞をＡｃｔｉｖｉｔｙ１上の仮始点トークン（１）のペアである仮終点トークン｛１｝のフォークノードまで移動させる。これは図２４では行「ｅｖｅｎｔ０」の列「フォーク１」上の「＜１＞移動」に該当する。
Ｓｔｅｐ１１ではカレントトークン＜１＞と同じノードにある仮終点トークン｛１｝とそのペアである仮始点トークン（１）を削除する。これは図２４では行「ｅｖｅｎｔ０」の列「フォーク１」上の「｛１｝削除」と、列「Ａｃｔｉｖｉｔｙ１」上の「（１）削除」が該当する。
Ｓｔｅｐ９ではカレントトークン＜１＞はフォークノードでカレントトークン＜１−１＞とカレントトークン＜１−２＞に分裂する。これは図２４では行「ｅｖｅｎｔ０」の列「Ａｃｔｉｖｉｔｙ１」上の「＜１−１＞分裂」と、列「Ａｃｔｉｖｉｔｙ３」上の「＜１−２＞分裂」に該当する。変数ｐｒｏｃｅｓｓ上のカレントトークン＜１−１＞が存在するＡｃｔｉｖｉｔｙ２上には仮始点トークン（４）が存在するのでＳｔｅｐ１０が実行される。
Ｓｔｅｐ１０ではカレントトークン＜１−１＞をＡｃｔｉｖｉｔｙ２上の仮始点トークン（４）のペアである仮終点トークン｛４｝のジョインノードまで移動させる。これは図２４では行「ｅｖｅｎｔ０」の列「ジョイン１」上の「＜１−１＞移動」に該当する。
Ｓｔｅｐ１１ではカレントトークン＜１−１＞と同じノードにある仮終点トークン｛４｝とそのペアである仮始点トークン（４）を削除する。これは図２４では行「ｅｖｅｎｔ０」の列「ジョイン１」上の「｛４｝削除」と、列「Ａｃｔｉｖｉｔｙ２」上の「（４）削除」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ０の処理が終了する。

続いてＳｔｅｐ１により変数ｅｖｅｎｔにはｅｖｅｎｔ４が代入される。
Ｓｔｅｐ２により変数ｔｒａｎｓｉｔｉｏｎには「Ａｃｔｉｖｉｔｙ３からジョインノードへの遷移」が代入される。
Ｓｔｅｐ３により変数ｐｒｏｃｅｓｓには既に生成された業務プロセスインスタンスが代入される。
変数ｐｒｏｃｅｓｓが空ではなく、変数ｔｒａｎｓｉｔｉｏｎの始点ノードの種類が開始ノードではないので、Ｓｔｅｐ１２が実行される。
Ｓｔｅｐ１２ではＡｃｔｉｖｉｔｙ３に含まれるトークンとしてカレントトークン＜１−２＞を取得して変数ｔｏｋｅｎＬｉｓｔに代入される。変数ｔｏｋｅｎＬｉｓｔは空ではないのでＳｔｅｐ１３が実行される。
Ｓｔｅｐ１３ではｔｏｋｅｎＬｉｓｔに含まれるカレントトークン＜１−２＞が変数ｔｒａｎｓｉｔｉｏｎの終点ノードであるジョインノードに移動する。これは図２４では行「ｅｖｅｎｔ４」の列「ジョイン１」上の「＜１−２＞移動」が該当する。
Ｓｔｅｐ１４ではｔｏｋｅｎＬｉｓｔには仮終点トークンが無いので何も実行しない。
Ｓｔｅｐ９ではジョインノードでカレントトークン＜１−１＞とカレントトークン＜１−２＞が揃ったのでカレントトークン＜１＞として合体し、Ａｃｔｉｖｉｔｙ４へ移動する。これは図２４では、行「ｅｖｅｎｔ４」の列「ジョイン１」上の「＜１＞合体」と、列「Ａｃｔｉｖｉｔｙ４」上の「＜１＞移動」が該当する。
変数ｐｒｏｃｅｓｓ上のカレントトークン＜１＞が存在するＡｃｔｉｖｉｔｙ４には仮始点トークン（２）が存在するためＳｔｅｐ１０が実行される。
Ｓｔｅｐ１０ではカレントトークン＜１＞をＡｃｔｉｖｉｔｙ４上の仮始点トークン（２）のペアである仮終点トークン｛２｝の終了ノードまで移動させる。これは図２４では行「ｅｖｅｎｔ４」の列「終了ノード」上の「＜１＞移動」に該当する。
Ｓｔｅｐ１１ではカレントトークン＜１＞と同じノードにある仮終点トークン｛２｝とそのペアである仮始点トークン（２）を削除する。これは図２４では行「ｅｖｅｎｔ４」の列「終了ノード」上の「｛２｝削除」と、列「Ａｃｔｉｖｉｔｙ４」上の「（２）削除」が該当する。
Ｓｔｅｐ９では遷移可能なトークンが無いので何も実行しない。条件［ｐｒｏｃｅｓｓ上のカレントトークンが存在するノードインスタンス上に仮トークンが存在しない］が成立し、デキューしたｅｖｅｎｔ４の処理が終了する。
以上で到着順が矛盾したイベント群を補正することができる。

本実施の形態では、業務プロセスの順序通りに格納されていないイベントキューからデキューして補正する補正機能付き業務プロセス監視結果更新部と、補正情報を格納できる補正機能付き業務プロセス監視結果ＤＢと、補正情報も含めて業務プロセスを監視する補正機能付き業務プロセス監視部を備える業務監視システムについて説明した。

そして、本実施の形態に係る業務監視システムによれば、組織間／計算機間／システム間を跨って業務プロセスを監視できる。
つまり、本実施の形態に係る業務監視システムは、従来技術の問題５を解決することができる。

なお、以上の説明では、カレントトークン、仮始点トークン及び仮終点トークンを用いて開始ノード遷移範囲及び中間ノード遷移範囲を特定、更新することとしたが、他の手段により開始ノード遷移範囲及び中間ノード遷移範囲を特定、更新してもよい。

実施の形態１に係るシステム構成例を示す図。実施の形態１に係るシステムの計算機構成例を示す図。実施の形態１に係るシステムの計算機構成例を示す図。実施の形態１及び２に係るシステムのハードウェア構成例を示す図。実施の形態１に係るユーザインタフェース監視部の動作例を示すフローチャート図。実施の形態１に係るシステムにおいてＨＴＴＰリクエストとＨＴＴＰレスポンスが送受信される場合の構成例を示す図。実施の形態１に係るシステムにおいて電子メールが送受信される場合の構成例を示す図。実施の形態１に係るシステムにおいて電子メールが送受信される場合の構成例を示す図。実施の形態１に係る監視対象画面の例とそのＨＴＭＬ部分の例を示す図。実施の形態１に係るＳｅｒｖｌｅｔフィルタが読み込む業務イベント対応一覧の例を示す図。実施の形態１に係るＳｅｒｖｌｅｔフィルタが読み込む業務イベント対応一覧の例を示す図。実施の形態１に係るＳｅｒｖｌｅｔフィルタの動作例を示すフローチャート図。実施の形態１に係るＳｅｒｖｌｅｔフィルタの動作例を示すフローチャート図。実施の形態１に係る業務遂行者と監視対象業務システムの間で送受信されるメール例を示す図。実施の形態１に係る業務遂行者と監視対象業務システムの間で送受信されるメール例を示す図。実施の形態１に係るメール受信機能付き業務イベント監視部が読み込む業務イベント対応一覧の例を示す図。実施の形態１に係るメール受信機能付き業務イベント監視部の動作例を示すフローチャート図。実施の形態２に係るシステム構成例を示す図。実施の形態２に係るシステムの計算機構成例を示す図。実施の形態２に係るシステムの計算機構成例を示す図。実施の形態２に係る補正機能付き業務プロセス監視結果更新部の動作例を示すフローチャート図。実施の形態２に係るイベントデータの到着順序が矛盾している場合のトークンの処理例を示す図。実施の形態２に係るイベントデータの到着順序が矛盾している場合のトークンの処理例を示す図。実施の形態２に係るイベントデータの到着順序が矛盾している場合のトークンの処理例を示す図。実施の形態２に係る遷移設定情報の例を示す図。従来技術を説明する図。イベント／業務プロセス対応設定ＤＢの格納例を示す図。業務プロセス監視結果ＤＢの格納例を示す図。従来技術を説明する図。業務システムの構成例を示す図。従来技術の問題点を説明する図。従来技術の問題点を説明する図。従来技術の問題点を説明する図。従来技術の問題点を説明する図。

符号の説明

１００業務監視システム、１０１イベントキュー、１０２業務プロセス監視結果更新部、１０３イベント／業務プロセス対応設定ＤＢ、１０４業務プロセス監視部、１０５業務プロセス監視結果ＤＢ、１０６業務ＤＢ監視部、１０７システム間メッセージ監視部、１１０ユーザインタフェース監視部、１２０補正機能付き業務プロセス監視結果更新部、１２１補正機能付き業務プロセス監視部、１２２補正機能付き業務プロセス監視結果ＤＢ、２００監視対象業務システム、２０１ユーザインタフェース部、２０２業務ロジック部、２０３業務データ入出力部、２０４システム連携処理部、３００リソース、３０１業務ＤＢ、３０２他システム、４００ユーザインタフェース基盤、４０１ユーザインタフェース基盤（クライアント側）、４０２ユーザインタフェース基盤（サーバ側）、５０１ＤＢ管理システム、５０２システム間メッセージ交換ミドルウェア、６０１業務遂行者、６０２業務監視者、７００業務監視システム、１０００業務監視用サーバ装置、２０００業務用サーバ装置、４０００業務遂行者用クライアント端末、４００１業務監視者用クライアント端末。

Claims

監視対象業務システムの業務プロセスにおけるイベントの発生を通知するイベントデータを用いて前記業務プロセスの監視を行う業務監視システムであって、
前記監視対象業務システムを利用する端末装置と前記監視対象業務システムとの間で送受信されるメッセージを取得し、取得したメッセージを解析してイベントデータを生成し、生成したイベントデータをイベントキューにエンキューするイベントデータ生成部を有することを特徴とする業務監視システム。
前記イベントデータ生成部は、
前記メッセージとして、前記監視対象業務システムと前記端末装置との間で送受信されるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）リクエスト及びＨＴＴＰレスポンスの少なくともいずれかを取得することを特徴とする請求項１に記載の業務監視システム。
前記イベントデータ生成部は、
前記メッセージとして、前記監視対象業務システムと前記端末装置との間で送受信される電子メールを取得することを特徴とする請求項１に記載の業務監視システム。
監視対象業務システムにおける業務プロセスの監視を行う業務監視システムであって、
前記業務プロセスのシーケンスを複数のイベントとそれぞれのイベントの遷移元ノード及び遷移先ノードとして示す業務プロセスシーケンス情報を記憶する業務プロセスシーケンス情報記憶部と、
前記業務プロセスにおけるイベントの発生を通知するイベントデータをイベントキューからデキューし、前記業務プロセスシーケンス情報に基づき、デキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードを判断し、デキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードと既にデキュー済みのイベントデータに対応するイベントの遷移元ノード及び遷移先ノードとに基づき、前記業務プロセスの開始ノードから遷移が開始しているノードの範囲を開始ノード遷移範囲として特定するとともに、前記開始ノード以外の中間ノードから遷移が開始しているノードの範囲を中間ノード遷移範囲として特定するノード遷移範囲特定部を有することを特徴とする業務監視システム。
前記ノード遷移範囲特定部は、
新たにイベントデータをデキューする度に、新たにデキューしたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードと既にデキュー済みのイベントデータに対応するイベントの遷移元ノード及び遷移先ノードとに基づき、前記開始ノード遷移範囲及び前記中間ノード遷移範囲の少なくともいずれかを更新することを特徴とする請求項４に記載の業務監視システム。
前記ノード遷移範囲特定部は、
更新の結果、前記開始ノード遷移範囲と前記中間ノード遷移範囲とが連結する場合に、前記開始ノード遷移範囲に前記中間ノード遷移範囲を連結させた範囲を新たな開始ノード遷移範囲として更新することを特徴とする請求項４に記載の業務監視システム。
前記ノード遷移範囲特定部は、
前記業務プロセスにおける開始イベントのイベントデータをデキューした場合に、前記開始イベントの遷移先ノードに対してペトリネットのカレントトークンを生成して前記開始ノード遷移範囲を特定し、前記業務プロセスにおける開始イベント以外のイベントのイベントデータをデキューした場合に、当該イベントの遷移元ノードと遷移先ノードに対してペトリネットのトークンを拡張した仮始点トークンと仮終点トークンとをそれぞれ生成して前記中間ノード遷移範囲を特定することを特徴とする請求項４に記載の業務監視システム。
前記ノード遷移範囲特定部は、
新たにイベントデータをデキューする度に、前記カレントトークン及び前記仮終点トークンの少なくともいずれかを移動させて、前記開始ノード遷移範囲及び前記中間ノード遷移範囲の少なくともいずれかを更新することを特徴とする請求項７に記載の業務監視システム。
前記ノード遷移範囲特定部は、
更新の結果、前記開始ノード遷移範囲と前記中間ノード遷移範囲とが連結する場合に、前記カレントトークンを前記仮終点トークンの位置まで移動させるとともに、前記仮始点トークンと前記仮終点トークンとを削除して、前記開始ノード遷移範囲に前記中間ノード遷移範囲を連結させた範囲を新たな開始ノード遷移範囲として更新することを特徴とする請求項８に記載の業務監視システム。
監視対象業務システムの業務プロセスにおけるイベントの発生を通知するイベントデータを用いて前記業務プロセスの監視を行う業務監視方法であって、
前記監視対象業務システムを利用する端末装置と前記監視対象業務システムとの間で送受信されるメッセージを取得するメッセージ取得ステップと、
取得したメッセージを解析してイベントデータを生成するイベントデータ生成ステップと、
生成したイベントデータをイベントキューにエンキューするエンキュー処理ステップとを有することを特徴とする業務監視方法。
監視対象業務方法における業務プロセスの監視を行う業務監視方法であって、
前記業務プロセスにおけるイベントの発生を通知するイベントデータをイベントキューからデキューするデキュー処理ステップと、
前記業務プロセスのシーケンスを複数のイベントとそれぞれのイベントの遷移元ノード及び遷移先ノードとして示す業務プロセスシーケンス情報に基づき、デキューされたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードを判断し、デキューされたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードと既にデキュー済みのイベントデータに対応するイベントの遷移元ノード及び遷移先ノードとに基づき、前記業務プロセスの開始ノードから遷移が開始しているノードの範囲を開始ノード遷移範囲として特定するとともに、前記開始ノード以外の中間ノードから遷移が開始しているノードの範囲を中間ノード遷移範囲として特定するノード遷移範囲特定ステップとを有することを特徴とする業務監視方法。
監視対象業務システムの業務プロセスにおけるイベントの発生を通知するイベントデータを用いて前記業務プロセスの監視を行うコンピュータに、
前記監視対象業務システムを利用する端末装置と前記監視対象業務システムとの間で送受信されるメッセージを取得するメッセージ取得処理と、
取得したメッセージを解析してイベントデータを生成するイベントデータ生成処理と、
生成したイベントデータをイベントキューにエンキューするエンキュー処理とを実行させることを特徴とするプログラム。
監視対象業務方法における業務プロセスの監視を行うコンピュータに、
前記業務プロセスにおけるイベントの発生を通知するイベントデータをイベントキューからデキューするデキュー処理と、
前記業務プロセスのシーケンスを複数のイベントとそれぞれのイベントの遷移元ノード及び遷移先ノードとして示す業務プロセスシーケンス情報に基づき、デキューされたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードを判断し、デキューされたイベントデータに対応するイベントの遷移元ノード及び遷移先ノードと既にデキュー済みのイベントデータに対応するイベントの遷移元ノード及び遷移先ノードとに基づき、前記業務プロセスの開始ノードから遷移が開始しているノードの範囲を開始ノード遷移範囲として特定するとともに、前記開始ノード以外の中間ノードから遷移が開始しているノードの範囲を中間ノード遷移範囲として特定するノード遷移範囲特定処理とを実行させることを特徴とするプログラム。