(57)【要約】【課題】イベントを効率的かつ不足なくトラッキングすることを目的とする。イベントを業務プロセスと矛盾させずに記録することを目的とする。【解決手段】イベント受信部１１０は、業務システムからイベント情報を受信する。イベントエッジ生成部１３２は、イベント情報の受信した順序を示すイベントエッジ情報を生成する。データエッジ生成部１３３は、イベント情報より特定されるイベントで入出力された業務データとイベント情報とを関連付けするデータエッジ情報を生成する。業務プロセス記憶部１３５は、イベント情報とイベントエッジ情報とデータエッジ情報と業務データとを業務プロセス情報として業務プロセス記憶ＤＢ（ＤａｔａＢａｓｅ）に記憶する。【選択図】図１２
2009003682.tif 000002
【特許請求の範囲】
【請求項１】
業務処理を実行する業務システムから上記業務処理において所定のイベントが実行された場合に送信される情報であって、実行されたイベントを特定可能な情報であるイベント情報を受信してイベントキューに記憶するイベント受信部と、
上記イベント受信部が受信した順にイベントキューからイベント情報を取得するイベント取得部と、
上記イベント取得部が取得したイベント情報である現イベント情報と、上記現イベント情報を取得する直前に取得した前イベント情報とを関連付けするイベントエッジ情報を生成するイベントエッジ生成部と、
上記現イベント情報と、上記現イベント情報により特定されるイベントで入出力された業務データとを関連付けするデータエッジ情報を生成するデータエッジ生成部と、
上記データエッジ生成部が生成したデータエッジ情報によりイベント情報と関連付けされる業務データを取得する業務データ取得部と、
上記イベント取得部が取得したイベント情報と、上記イベントエッジ生成部が生成したイベントエッジ情報と、上記データエッジ生成部が生成したデータエッジ情報と、上記業務データ取得部が取得した業務データとを業務プロセス情報として業務プロセス記憶ＤＢ（ＤａｔａＢａｓｅ）に記憶する業務プロセス記憶部と
を備えることを特徴とする業務プロセス記録装置。
【請求項２】
上記データエッジ生成部は、生成するデータエッジ情報により現イベント情報と関連付けされる業務データが既に上記業務プロセス記憶ＤＢに記憶されている場合、上記現イベントと既に記憶されている上記業務データとを関連付けするデータエッジ情報を生成し、
上記業務プロセス記憶部は、データエッジ情報によりイベント情報と関連付けされる業務データが既に上記業務プロセス記憶ＤＢに記憶されている場合、上記業務データを上記業務プロセス記憶ＤＢに登録しない
ことを特徴とする請求項１記載の業務プロセス記録装置。
【請求項３】
上記業務プロセス記録装置は、さらに、
イベントの実行順序と、イベントとそのイベントで入出力される業務データとの対応関係とを業務プロセスを示す業務プロセス定義情報として予め記憶する業務プロセス定義ＤＢと、
上記イベント取得部が取得したイベント情報により特定されるイベントが実行されたタイミングと、上記イベントで入出力された業務データとが、上記業務プロセス定義ＤＢが記憶した業務プロセス定義情報が示す業務プロセスと整合するか否かを判定する業務プロセス確認部とを備え、
上記業務プロセス記憶部は、イベントが業務プロセス定義情報と整合すると上記業務プロセス確認部が判定した場合に業務プロセス情報を記憶する
ことを特徴とする請求項１又は２のいずれかに記載の業務プロセス記録装置。
【請求項４】
上記業務プロセス定義ＤＢは、
業務処理において実行される複数のイベントそれぞれを定義した複数のイベント定義情報を予め記憶したイベント定義ＤＢと、
業務処理において入出力される業務データを定義したデータ定義情報を予め記憶したデータ定義ＤＢと、
上記イベント定義ＤＢが記憶した複数のイベント定義情報の各イベント定義情報と、上記各イベント定義情報が示すイベントが実行される直前に実行される可能性のあるイベントを定義したイベント定義情報とを関連付けてイベントの実行順序を示したイベントエッジ定義情報を予め記憶したイベントエッジ定義ＤＢと、
上記複数のイベント定義情報の各イベント定義情報と、上記各イベント定義情報が示すイベントで入出力される可能性のある業務データを定義したデータ定義情報とを関連付けたデータエッジ定義情報を予め記憶したデータエッジ定義ＤＢとを備え、
上記業務プロセス確認部は、上記現イベント情報により特定されるイベントを定義したイベント定義情報と、上記前イベント情報により特定されるイベントを定義したイベント定義情報とを関連付けするイベントエッジ定義情報が上記イベントエッジ定義ＤＢに記憶されているか否かを判定するとともに、上記現イベント情報により特定されるイベントを定義したイベント定義情報と、上記現イベント情報により特定されるイベントで入出力された業務データを定義したデータ定義情報とを関連付けするデータエッジ定義情報が上記データエッジ定義ＤＢに記憶されているか否かを判定し、上記イベントエッジ定義情報が上記イベントエッジ定義ＤＢに記憶されており、かつ、上記データエッジ定義情報が上記データエッジ定義ＤＢに記憶されていると判断した場合、イベントが業務プロセス定義情報と整合すると判定する
ことを特徴とする請求項３記載の業務プロセス記録装置。
【請求項５】
上記業務プロセス記録装置は、さらに、
業務処理において実行される複数のイベントそれぞれを定義した複数のイベント定義情報を予め記憶したイベント定義ＤＢと、
業務処理において入出力される業務データを定義したデータ定義情報を予め記憶したデータ定義ＤＢとを備え、
上記業務プロセス記憶部は、上記イベント取得部が取得したイベント情報を、上記イベント定義ＤＢが記憶した上記イベント情報に対応するイベント定義情報と関連付けて記憶するとともに、上記業務データ取得部が取得した業務データを、上記データ定義ＤＢが記憶した業務データに対応するデータ定義情報と関連付けて記憶する
ことを特徴とする請求項１から３までのいずれかに記載の業務プロセス記録装置。
【請求項６】
上記業務プロセス記録装置は、さらに、
上記イベント定義ＤＢが記憶した複数のイベント定義情報の各イベント定義情報と、上記各イベント定義情報が示すイベントが実行される直前に実行される可能性のあるイベントを定義したイベント定義情報とを関連付けたイベントエッジ定義情報を予め記憶したイベントエッジ定義ＤＢと、
上記複数のイベント定義情報の各イベント定義情報と、上記各イベント定義情報が示すイベントで入出力される可能性のある業務データを定義したデータ定義情報とを関連付けたデータエッジ定義情報を予め記憶するデータエッジ定義ＤＢとを備え、
上記業務プロセス記憶部は、上記イベントエッジ生成部が生成したイベントエッジ情報を、上記イベントエッジ定義ＤＢが記憶したイベントエッジ定義情報の上記イベントエッジ情報が示す関連付けを含むイベントエッジ定義情報と関連付けて記憶するとともに、上記データエッジ生成部が生成したデータエッジ情報を、上記データエッジ定義ＤＢが記憶したデータエッジ定義情報の上記データエッジ情報が示す関連付けを含むデータエッジ定義情報と関連付けして記憶する
ことを特徴とする請求項５記載の業務プロセス記録装置。
【請求項７】
業務処理を実行する業務システムから上記業務処理において所定のイベントが実行された場合に送信される情報であって、実行されたイベントを特定可能な情報であるイベント情報を記憶するイベント記憶領域と、
イベント記憶領域に記憶された所定のイベント情報である現イベント情報と、上記現イベント情報が送信される直前に送信された前イベント情報とを関連付けするイベントエッジ情報を上記現イベント情報と上記前イベント情報とに関連付けて記憶するイベントエッジ記憶領域と、
上記現イベント情報と、上記現イベント情報により特定されるイベントで入出力された業務データとを関連付けするデータエッジ情報を上記現イベント情報に関連付けて記憶するデータエッジ記憶領域と、
上記データエッジ記憶領域に記憶されたデータエッジ情報によりイベント情報と関連付けされる業務データを上記データエッジ情報に関連付けて記憶する業務データ記憶領域と
を備えることを特徴とする業務プロセス情報のデータ構造。
【請求項８】
通信装置が、業務処理を実行する業務システムから上記業務処理において所定のイベントが実行された場合に送信される情報であって、実行されたイベントを特定可能な情報であるイベント情報を受信してイベントキューに記憶するイベント受信ステップと、
処理装置が、上記イベント受信ステップで受信した順にイベントキューからイベント情報を取得するイベント取得ステップと、
処理装置が、上記イベント取得ステップで取得したイベント情報である現イベント情報と、上記現イベント情報を取得する直前に取得した前イベント情報とを関連付けするイベントエッジ情報を生成するイベントエッジ生成ステップと、
処理装置が、上記現イベント情報と、上記現イベント情報により特定されるイベントで入出力された業務データとを関連付けするデータエッジ情報を生成するデータエッジ生成ステップと、
処理装置が、上記データエッジ生成ステップで生成したデータエッジ情報によりイベント情報と関連付けされる業務データを取得する業務データ取得ステップと、
記憶装置が、上記イベント取得ステップで取得したイベント情報と、上記イベントエッジ生成ステップで生成したイベントエッジ情報と、上記データエッジ生成ステップで生成したデータエッジ情報と、上記業務データ取得ステップで取得した業務データとを業務プロセス情報として記憶する業務プロセス記憶ステップと
を備えることを特徴とする業務プロセス記録方法。
【請求項９】
業務処理を実行する業務システムから上記業務処理において所定のイベントが実行された場合に送信される情報であって、実行されたイベントを特定可能な情報であるイベント情報を受信してイベントキューに記憶するイベント受信処理と、
上記イベント受信処理で受信した順にイベントキューからイベント情報を取得するイベント取得処理と、
上記イベント取得処理で取得したイベント情報である現イベント情報と、上記現イベント情報を取得する直前に取得した前イベント情報とを関連付けするイベントエッジ情報を生成するイベントエッジ生成処理と、
上記現イベント情報と、上記現イベント情報により特定されるイベントで入出力された業務データとを関連付けするデータエッジ情報を生成するデータエッジ生成処理と、
上記データエッジ生成処理で生成したデータエッジ情報によりイベント情報と関連付けされる業務データを取得する業務データ取得処理と、
上記イベント取得処理で取得したイベント情報と、上記イベントエッジ生成処理で生成したイベントエッジ情報と、上記データエッジ生成処理で生成したデータエッジ情報と、上記業務データ取得処理で取得した業務データとを業務プロセス情報として業務プロセス記憶ＤＢ（ＤａｔａＢａｓｅ）に記憶する業務プロセス記憶処理と
をコンピュータに実行させることを特徴とする業務プロセス記録プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、業務システムで実行された業務処理のプロセスを記録する業務プロセス記録技術に関する。
【背景技術】
【０００２】
特許文献１に係る業務プロセス記録システムでは、業務を実施したことを示すイベントを業務システムから抽出し、抽出したイベントを記録する。そして、ユーザ要求があるとイベントの履歴をトラッキング（業務プロセスの実行履歴又は進捗状況の表示）している。また、特許文献１に係る業務プロセス記録システムのイベントの記録形式は、そのイベントの入力あるいは出力となる業務データの階層下にイベントを記録している。つまり、入力または出力する業務データがあることを前提にイベントが記録されている。
【特許文献１】特開２００５−１１５４９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来の業務プロセス記録方法には、以下の（１）から（４）の課題がある。
（１）イベントが入力又は出力する業務データがあることを前提にイベントが記録される。そのため、業務データの入出力がないイベントを記録することができず、業務プロセスのトラッキングが不完全である。
（２）ある１つのイベントが複数の業務データを入出力する場合、どの業務データにイベントが付加されているか曖昧である。そのため、複数の業務データを入出力するイベントを検索するには、入出力する業務データ全てについて、そのイベントが付加されているかを調べなければならない。
（３）業務プロセスの実行履歴を表示するには、業務プロセスのイベントを全て取得し、開始時刻又は終了時刻でソートしなければならず非効率的である。
（４）受信したイベントを何らチェックをせず、そのまま記録する。そのため、業務プロセスと異なるイベントフローや入出力業務データであっても、矛盾したまま記録されてしまう。したがって、無意味な業務プロセスのトラッキングとなる虞がある。
【０００４】
この発明は、例えば、イベントを効率的かつ不足なくトラッキングすることを目的とする。また、イベントを業務プロセスと矛盾させずに記録することを目的とする。
【課題を解決するための手段】
【０００５】
本発明に係る業務プロセス記録装置は、例えば、業務処理を実行する業務システムから上記業務処理において所定のイベントが実行された場合に送信される情報であって、実行されたイベントを特定可能な情報であるイベント情報を受信してイベントキューに記憶するイベント受信部と、
上記イベント受信部が受信した順にイベントキューからイベント情報を取得するイベント取得部と、
上記イベント取得部が取得したイベント情報である現イベント情報と、上記現イベント情報を取得する直前に取得した前イベント情報とを関連付けするイベントエッジ情報を生成するイベントエッジ生成部と、
上記現イベント情報と、上記現イベント情報により特定されるイベントで入出力された業務データとを関連付けするデータエッジ情報を生成するデータエッジ生成部と、
上記データエッジ生成部が生成したデータエッジ情報によりイベント情報と関連付けされる業務データを取得する業務データ取得部と、
上記イベント取得部が取得したイベント情報と、上記イベントエッジ生成部が生成したイベントエッジ情報と、上記データエッジ生成部が生成したデータエッジ情報と、上記業務データ取得部が取得した業務データとを業務プロセス情報として業務プロセス記憶ＤＢ（ＤａｔａＢａｓｅ）に記憶する業務プロセス記憶部と
を備えることを特徴とする。
【発明の効果】
【０００６】
本発明に係る業務プロセス記録装置によれば、イベントが入力又は出力する業務データがあることとは無関係に記録されるため、イベントを効率的かつ不足なくトラッキングすることができる。
【発明を実施するための最良の形態】
【０００７】
実施の形態１．
まず、この実施の形態及び以下の実施の形態における業務プロセス記録装置１００の外観について説明する。図１は、業務プロセス記録装置１００を備える業務プロセス記録システムの外観の一例を示す図である。
【０００８】
図１に示すように、業務プロセス記録システムは、例えば、業務プロセス記録装置１００と業務システム２００とクライアント端末とを備える。
業務プロセス記録装置１００は、ＬＣＤ９０１（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）、キーボード９０２（Ｋ／Ｂ）、マウス９０３、サーバ９０４、データベース９０５を備える。
業務システム２００は、サーバ９０４を備える。
クライアント端末は、ＬＣＤ９０１、キーボード９０２、マウス９０３、ＰＣ９０６（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）を備える。
業務プロセス記録装置１００と業務システム２００とクライアント端末とは、ＬＡＮ９４０（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等を介して接続される。
【０００９】
次に、この実施の形態及び以下の実施の形態における業務プロセス記録装置１００のハードウェア構成について説明する。図２は、業務プロセス記録装置１００ハードウェア構成の一例を示す図である。
図２に示すように、業務プロセス記録装置１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３、ＲＡＭ９１４、ＬＣＤ９０１、キーボード９０２、マウス９０３、通信ボード９１５、磁気ディスク９２０（データベース９０５）と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
【００１０】
ＲＯＭ９１３、磁気ディスク装置９２０は、不揮発性メモリの一例である。ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３とＲＡＭ９１４とは、記憶装置の一例である。通信ボード９１５とキーボード９０２とマイク９０３とは、入力装置の一例である。また、通信ボード９１５は、出力装置の一例である。さらに、通信ボード９１５は、通信装置の一例である。
【００１１】
磁気ディスク装置９２０又はＲＯＭ９１３などには、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
【００１２】
上記プログラム群９２２には、以下の説明において「イベント受信部１１０」、「イベントキュー１２０」、「業務プロセス記録部１３０」、「業務プロセス定義ＤＢ１４０」、「業務プロセス記憶ＤＢ１５０」、「入力部１６０」、「出力部１７０」等として説明する機能を実行するプログラムやその他のプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２３には、以下の説明において、「イベント情報」、「業務データ」、「イベントエッジ情報」、「データエッジ情報」、「イベント定義情報」、「データ定義情報」、「イベントエッジ定義情報」、「データエッジ定義情報」等として説明する情報やデータや信号値や変数値やパラメータが、「ファイル」や「データベース」の各項目として記憶される。「ファイル」や「データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵ９１１の動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵ９１１の動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
また、以下の説明におけるフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、その他光ディスク等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００１３】
また、以下の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。また、「〜処理」として説明するものは「〜ステップ」であっても構わない。すなわち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、ＲＯＭ９１３等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、以下に述べる「〜部」としてコンピュータ等を機能させるものである。あるいは、以下に述べる「〜部」の手順や方法をコンピュータ等に実行させるものである。
【００１４】
次に、この実施の形態に係る業務プロセス記録装置１００の基礎となる業務プロセス記録技術について説明し、この実施の形態に係る業務プロセス記録装置１００が解決する課題をより明確にする。
業務プロセス記録装置１００の基礎となる業務プロセス記録技術では、イベントの入出力となる業務データの階層下にそのイベントを記録する。つまり、この記録形式では、入出力する業務データがあることを前提にイベントを記録する。
【００１５】
図３は、上記記録形式によりイベントを記録したＤＢのスキーマ（データベースの内部構造）を示したＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）クラス図である。図３では、テーブルをクラス、外部キーをクラス間の関連として表現している。また、イベントは業務データがあることが前提となっており、業務データは参照元の業務データがあることが前提となっている。そのため、イベント間の関連および、イベントと業務データ間の関連はコンポジションとして表現される。
したがって、上記記録形式では、業務データの入出力がないイベントを記録することができず、業務処理のトラッキングが不完全であるという課題がある（課題（１））。
【００１６】
また、上記記録形式では、１つのイベントが複数の業務データを入出力する場合、どの業務データにイベントを付加するかが曖昧である。
図４は、業務処理の一例をＵＭＬアクティビティ図で示したものである。図４では、イベント１はデータＡとデータＢを出力している。このような業務処理に対して、上記記録形式では、データＡを主業務データとした場合は図５に示すように記録する。一方、データＢを主業務データとした場合は図６のように記録する。つまり、データＡとデータＢとのいずれを主業務データと捉えるかで記録される内容が異なる。
したがって、上記記録形式では、イベント１がどちらの業務データに付加されるかが曖昧であるという課題がある（課題（２））。
【００１７】
また、イベント履歴をトラッキングするためには、イベントを受信した順序に取り出す必要があるが、上記記録形式では、イベントを受信した順序に取り出すには、以下の処理を行わなければならない。
（１）業務データの依存関係に基づき、業務処理で入出力される業務データを全て取り出す。（２）それぞれの業務データに付加して記録されているイベントを全て取り出し、イベントの開始時刻あるいは終了時刻でソートする。イベント履歴をトラッキングするために、これら（１）（２）を行うのは非常に効率が悪い。
図４と、図７から図１１までとに基づき、イベントを受信した順序に取り出すのに（１）（２）を行う必要があることを具体的に説明する。図７から図１０それぞれは、図４に示す業務処理のイベント１、イベント２、イベント３、イベント４の順に受信した場合に、上記記録形式により各イベントを受信したタイミングで記録されるイベント管理ＤＢの情報を示している。また、図１１は、イベント１、イベント３、イベント２、イベント４の順に受信する場合に、上記記録形式により全てのイベントを受信した時点で記録されるイベント管理ＤＢの情報を示している。
図４に示すようにデータＡはイベント１とイベント４の主業務データとなるため、図１０に示すように、イベント４を記録した時点で、「データＡ：ａ００１」の階層下にイベント１とイベント４とが付加されている。このため業務データを「データＡ：ａ００１」、「データＢ：ｂ００１」、「データＣ：ｃ００１」の順に辿って得られるイベントは、イベント１、イベント４、イベント２、イベント３の順となる。つまり、受信したイベントの順とは異なる。
さらに、図４に示すようにイベント２とイベント３は並列実行可能なので、図１１に示すようにイベント１、イベント３、イベント２、イベント４の順に受信する場合もあり得る。しかしこの順に受信してもイベント管理ＤＢで辿って得られるイベントは、先と同様にイベント１、イベント４、イベント２、イベント３の順であり、受信した順とは異なる。
つまり、単純に記録された順にデータを取得しても、イベントの受信順ではない。そのため、全てのイベントを取得した後に、全てのイベントを開始時刻あるいは終了時刻でソートする必要がある。
したがって、上記記録形式では、業務処理の実行履歴を表示する処理が非効率的であるという課題がある（課題（３））。
【００１８】
また、上記記録形式では、イベントや業務データを関連付けしてＤＢにイベントを記録する際、本来あるべき業務プロセスとの整合性の確認をとっていない。つまり、受信したイベントをそのまま記録するだけである。
したがって、上記記録形式では、業務プロセスと異なるイベントフローや入出力業務データがあっても、矛盾したまま記録されてしまうという課題がある（課題（４））。
【００１９】
この実施の形態に係る業務プロセス記録装置１００は、上記課題（１）から（３）までを解決することができる。
【００２０】
次に、図１２に基づき、この実施の形態に係る業務プロセス記録装置１００の機能について説明する。図１２は、この実施の形態に係る業務プロセス記録装置１００の機能を示す機能ブロック図である。
業務プロセス記録装置１００は、業務処理を実行する業務システム２００の業務プロセスを記録する。
業務プロセス記録装置１００は、イベント受信部１１０、イベントキュー１２０、業務プロセス記録部１３０、業務プロセス定義ＤＢ１４０、業務プロセス記憶ＤＢ１５０、入力部１６０、出力部１７０を備える。
【００２１】
イベント受信部１１０は、業務システム２００からイベント情報を受信してイベントキュー１２０に記憶する。
イベント情報は、業務処理において所定のイベントが実行された場合に業務システム２００から送信される情報であって、実行されたイベントを特定可能な情報である。
イベントは、例えば、業務処理における発注、受注等の各プロセスである。イベントが実行されるとは、業務処理における発注、受注等の各プロセスが実行されることである。
イベント情報は、イベントの終了時、あるいは開始時及び終了時等に業務システム２００から送信される。図６から図１１に示すイベント情報は、イベントの終了時のみに送られる場合の例を示す。以下の説明においても、イベント情報は、イベントの終了時のみに送られているものとする。
【００２２】
イベントキュー１２０は、イベント受信部１１０が受信したイベント情報を受信した順に記憶装置に記憶する。
【００２３】
業務プロセス記録部１３０は、イベントキュー１２０に記憶されたイベントを所定の形式で業務プロセス記憶ＤＢ１５０に記録する。
業務プロセス記録部１３０は、イベント取得部１３１、イベントエッジ生成部１３２、データエッジ生成部１３３、業務データ取得部１３４、業務プロセス記憶部１３５を備える。
イベント取得部１３１は、イベント受信部１１０が受信した順にイベントキュー１２０からイベント情報を取得する。
イベントエッジ生成部１３２は、イベント取得部１３１が取得したイベント情報である現イベント情報と、現イベント情報を取得する直前に取得した前イベント情報とを関連付けするイベントエッジ情報を生成する。
データエッジ生成部１３３は、現イベント情報と、現イベント情報により特定されるイベントで入出力された業務データとを関連付けするデータエッジ情報を生成する。
業務データ取得部１３４は、データエッジ生成部１３３が生成したデータエッジ情報によりイベント情報と関連付けされる業務データを取得する。
業務プロセス記憶部１３５は、イベント取得部１３１が取得したイベント情報と、イベントエッジ生成部１３２が生成したイベントエッジ情報と、データエッジ生成部１３３が生成したデータエッジ情報と、業務データ取得部１３４が取得した業務データとを業務処理のプロセスを示す業務プロセス情報として業務プロセス記憶ＤＢ１５０に記憶する。
なお、関連付けするとは、例えば、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ  ＤａｔａＢａｓｅ）であれば、関連付ける相手の主キーを外部キーとして持つことである。また、一方から他方へ、あるいは関連付ける相手をポインタ等により指し示すとしてもよい。以下の説明においても、関連付けするとは、上記の意味である。
【００２４】
業務プロセス定義ＤＢ１４０は、業務処理で実行されるイベントの型や業務データの型を予め記憶するＤＢである。型とは、定義情報のことである。
業務プロセス定義ＤＢ１４０は、イベント定義ＤＢ１４１、データ定義ＤＢ１４２を備える。
イベント定義ＤＢ１４１は、業務処理において実行される複数のイベントそれぞれを定義した複数のイベント型（イベント定義情報）を予め記憶装置に記憶する。
データ定義ＤＢ１４２は、業務処理において入出力される業務データを定義した業務データ型（データ定義情報）を予め記憶装置に記憶する。
【００２５】
業務プロセス記憶ＤＢ１５０は、業務プロセス情報を記憶するＤＢである。つまり、業務プロセス記憶ＤＢ１５０は、業務プロセス記憶部１３５により業務プロセス情報を記録されるＤＢである。すなわち、業務プロセス記憶ＤＢ１５０には、業務システム２００が業務処理を実行した時のイベント情報や業務データとそれらの間の関連を示すエッジ情報（イベントエッジ情報、データエッジ情報）が記憶される。
【００２６】
入力部１６０は、クライアント端末等からユーザが入力するイベントの検索条件を受け付け、検索条件を入力装置により入力する。
出力部１７０は、入力部１６０が入力した検索条件に基づき、業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とを検索する。そして、出力部１７０は、検索結果をクライアント端末等へ通信装置を介して出力する。
【００２７】
次に、図１３に基づき、業務プロセス定義ＤＢ１４０に記憶される定義情報と業務プロセス記憶ＤＢ１５０とに記憶される業務プロセス情報のデータ構造について説明する。図１３は、業務プロセス定義ＤＢ１４０に記憶される業務プロセス情報と業務プロセス記憶ＤＢ１５０に記憶される定義情報とのスキーマを示すＵＭＬクラス図である。
図１３では、テーブルをクラス、列をクラスの属性、外部キーをクラス間の関連として表現している。
イベント情報は、イベント情報から抽出された少なくとも一部の情報である。イベント情報には、イベントを特定するイベントの識別子と開始時刻と終了時刻のように、業務プロセス実行中の進捗情報を示す情報が含まれる。
業務データはイベントで入力又は出力されたデータである。
ノードはイベント情報と業務データをまとめた抽象的なスーパークラスである。
エッジは、ノードとノードを関連付けるものである。イベント情報とイベント情報とを関連付けるエッジは上述したイベントエッジ情報であり、イベント情報の順序関係を表す。つまり、イベントエッジ情報は、ｓｏｕｒｃｅ側のイベント情報の後にｔａｒｇｅｔ側のイベント情報を受信したことを示す。また、イベント情報と業務データとを関連付けるエッジはデータエッジ情報であり、イベント情報と業務データの入出力の関係を表す。つまり、データエッジ情報は、ｓｏｕｒｃｅ側がイベント情報でｔａｒｇｅｔ側が業務データの場合は出力を表し、ｓｏｕｒｃｅ側が業務データでｔａｒｇｅｔ側がイベント情報の場合は入力を表す。さらに、業務データと業務データとを関連付けるエッジは業務データエッジ情報であり、業務データ間の依存関係を表す。つまり、業務データエッジは、ｓｏｕｒｃｅ側の業務データがｔａｒｇｅｔ側の業務データに依存することを表す。
なお、イベント情報を記憶する領域をイベント情報記憶領域と呼ぶ。業務データを記憶する領域を業務データ記憶領域と呼ぶ。イベントエッジ情報を記憶する領域をイベントエッジ情報記憶領域と呼ぶ。データエッジ情報を記憶する領域をデータエッジ情報記憶領域と呼ぶ。業務データエッジ情報を記憶する領域を業務データエッジ情報記憶領域と呼ぶ。
【００２８】
イベント型は、業務処理で定義されるイベントを型として保持するものである。例えば、受信したイベント情報ａが、業務プロセスで定義されたイベント型Ａに対応するものであるときに、イベント情報ａからイベント型Ａを参照するようにイベント情報ａにイベント型Ａを関連付けて記録する。
業務データ型は、業務処理で入出力される業務データを型として保持するものである。例えば、受信したイベント情報が入出力する業務データｄが、業務処理で定義された業務データ型Ｄに対応するものであるときに、業務データｄから業務データ型Ｄを参照するように業務データｄに業務データ型Ｄを関連付けて記録する。
なお、イベント型を記憶する領域をイベント定義情報記憶領域と呼ぶ。業務データ型を記憶する領域を業務データ定義情報記憶領域と呼ぶ。
【００２９】
次に、図１４に基づき、この実施の形態に係る業務プロセス記録装置１００の動作について説明する。図１４は、業務プロセス記録部１３０の動作を示すＵＭＬアクティビティ図である。
なお、図１４に示すＵＭＬアクティビティ図は、１つのイベント情報についての処理である。つまり、全ての業務処理を記録するには、イベントキュー１２０に記憶されたイベント情報の数だけ、図１４に示す処理を繰り返す必要がある。
まず、前提として、イベント受信部１１０は、イベント情報を受信してイベントキュー１２０に既に記憶している状態であるとする。また、業務プロセス定義ＤＢ１４０は、イベントの型や業務データの型を既に記憶している状態であるとする。
【００３０】
まず、（Ｓ１０１）では、イベント取得部１３１は、イベントキュー１２０からイベント情報を取得する。
【００３１】
次に、（Ｓ１０２）では、業務プロセス記憶部１３５は、取得したイベント情報を業務プロセス記憶ＤＢ１５０に記録する。業務プロセス記憶部１３５は、例えば、イベント情報に含まれるイベントの識別子と開始時刻と終了時刻と等を記録する。
この際、業務プロセス記憶部１３５は、イベント情報を業務プロセス定義ＤＢ１４０が記憶したイベント型と関連付ける。例えば、イベントの識別子に基づきどのイベント型と関連付けすればよいか判別することができる。
【００３２】
次に、（Ｓ１０３）では、イベントエッジ生成部１３２は、直前に到着したイベント情報（前イベント情報）があるか否かを判定する。つまり、イベントエッジ生成部１３２は、取得したイベント情報（現イベント情報）が示すイベントが、一連の業務処理における初めのイベントであるのか、それとも既に実行されたイベントが存在するのかを判定する。
直前に到着したイベント情報があると判定した場合（Ｓ１０３でＹＥＳ）、（Ｓ１０４）へ進む。一方、直前に到着したイベント情報がないと判定した場合（Ｓ１０３でＮＯ）、（Ｓ１０５）へ進む。
【００３３】
次に、（Ｓ１０４）では、イベントエッジ生成部１３２は、現イベント情報と前イベント情報とをエッジを介して関連付ける。つまり、イベントエッジ生成部１３２は、イベントエッジ情報を生成し、前イベント情報と現イベント情報とにイベントエッジ情報を関連付ける。
なお、この際、前イベント情報をｓｏｕｒｃｅ、現イベント情報をｔａｒｇｅｔとして、前後関係を示す情報をイベントエッジ情報に含ませる。
【００３４】
次に、（Ｓ１０５）では、データエッジ生成部１３３は、現イベント情報が示すイベントが業務データを入力又は出力するか否かを判定する。
現イベント情報が業務データを入力又は出力するか否かの判定は、例えば、イベント情報に入出力するデータを含めて業務システム２００から受信することで容易に行うことができる。また、例えば、業務データの入出力があるか否かを示すフラグ等をイベント情報に持たせておき、業務データは業務システム２００が保持する等としてもよい。
現イベント情報が業務データを入力又は出力すると判定した場合（Ｓ１０５でＹＥＳ）、（Ｓ１０６）へ進む。一方、現イベント情報が業務データを入力及び出力しないと判定した場合（Ｓ１０５でＮＯ）、処理を終了する。
【００３５】
次に、（Ｓ１０６）では、業務データ取得部１３４は、現イベント情報が入力又は出力する業務データが既に業務プロセス記憶ＤＢ１５０に記憶されているか否かを判定する。
既に業務プロセス記憶ＤＢ１５０に記憶されていると判定した場合（Ｓ１０６でＹＥＳ）、（Ｓ１０８）へ進む。一方、業務プロセス記憶ＤＢ１５０に記憶されていないと判定した場合（Ｓ１０６でＮＯ）、（Ｓ１０７）へ進む。
【００３６】
次に、（Ｓ１０７）では、業務データ取得部１３４は、現イベント情報が入力又は出力する業務データを取得する。そして、業務プロセス記憶部１３５は、業務データを業務プロセス記憶ＤＢ１５０に記憶する。
この際、業務プロセス記憶部１３５は、業務データを業務プロセス定義ＤＢ１４０が記憶した業務データ型と関連付ける。例えば、イベント情報に入出力する業務データの業務データ型の識別情報を含めて受信することで容易に関連付けすることができる。
また、業務データ同士に関連がある場合には、業務データエッジ情報を生成して、業務データ同士を関連付けする。
【００３７】
そして、（Ｓ１０８）では、データエッジ生成部１３３は、現イベント情報と業務プロセス記憶ＤＢ１５０に記録されている業務データとエッジを介して関連付ける。つまり、データエッジ生成部１３３は、データエッジ情報を生成し、現イベント情報と入出力される業務データとにデータエッジ情報を関連付ける。
なお、この際、業務データを入力する場合には、業務データをｓｏｕｒｃｅ、イベント情報をｔａｒｇｅｔとし、業務データを出力する場合には、イベント情報をｓｏｕｒｃｅ、業務データをｔａｒｇｅｔとして入力又は出力を示す情報をデータエッジ情報に含ませる。
【００３８】
上述したように、図１４は、１つのイベント情報についての動作を示したものであり、１つのイベント情報についての処理が完了すると次のイベント情報についての処理が開始される。
【００３９】
次に、図４に示す業務処理をこの実施の形態に係る業務プロセス記録装置１００が記録する場合について説明する。図１５は、図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順にイベント情報を受信した際の業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とが記憶した情報を示すＵＭＬオブジェクト図である。
【００４０】
まず、図１５の構成について説明する。
図１５では、テーブル中の１レコード（タプル）をオブジェクトとして表現している。また、他のレコードへの外部キーによる参照をオブジェクト間の関連として表現している。
【００４１】
業務プロセス定義ＤＢ１４０は、業務処理で定義されたイベント情報や業務データを、イベント型や業務データ型として記憶する。そのため、業務プロセス定義ＤＢ１４０は、イベント１からイベント４までのイベント型と、業務データＡから業務データＣまでの業務データ型が記憶される。
一方、業務プロセス記憶ＤＢ１５０では受信したイベント情報を元にして情報を記録する。そのため、ｅｖｅｎｔ１からｅｖｅｎｔ４まで（それぞれイベント１からイベント４までに対応）と関連するエッジと業務データとが記録される。
【００４２】
業務プロセス記憶ＤＢ１５０は、イベント情報−エッジ−イベント情報と、イベント情報−エッジ−業務データとのいずれかで関連付けられて記録されている。
イベント情報（Ｓ）−エッジ−イベント情報（Ｔ）の関連では、前者のイベント情報（Ｓ）の直後に後者のイベント情報（Ｔ）が到着したことを示している。つまり、ここでのエッジはイベントエッジ情報である。（Ｓ）と（Ｔ）とは、それぞれｓｏｕｒｃｅとｔａｒｇｅｔとを示す。
業務データ（Ｓ）−エッジ−イベント情報（Ｔ）の関連ではイベント情報が業務データを入力していることを示している。イベント情報（Ｓ）−エッジ−業務データ（Ｔ）の関連ではイベント情報が業務データを出力していることを示している。つまり、ここでのエッジはデータエッジ情報である。（Ｓ）と（Ｔ）とは、上記同様それぞれｓｏｕｒｃｅとｔａｒｇｅｔとを示す。
なお、図１５では記載が複雑になることを避けるため、業務データ間の依存関係を示すエッジ（業務データエッジ情報）は省略している。また、図１５の業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０との間には、イベント情報−イベント型の関連と、業務データ−業務データ型の関連とがあり、それぞれ業務処理の定義に基づいて関連付けられている。
【００４３】
図４に示す業務処理をこの実施の形態に係る業務プロセス記録装置１００が記録する処理について具体的に説明する。ここでは、図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順にイベント情報を受信したとする。
【００４４】
イベント１を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント１を取得する（Ｓ１０１）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント１をｅｖｅｎｔ１として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント１（イベント型）とｅｖｅｎｔ１とを関連付ける（Ｓ１０２）。
イベント１の前にイベント情報を取得していない（Ｓ１０３でＮＯ）。また、イベント１では業務データＡと業務データＢとを出力している（Ｓ１０５でＹＥＳ）。さらに、業務データＡと業務データＢとは、業務プロセス記憶ＤＢ１５０には記憶されていない（Ｓ１０６でＮＯ）。そこで、業務データ取得部１３４は、業務データＡと業務データＢとを取得する。また、業務プロセス記憶部１３５は、業務データＡをｄａｔａＡ、業務データＢをｄａｔａＢとして業務プロセス記憶ＤＢ１５０に記憶する。さらに、業務プロセス記憶部１３５は、ｄａｔａＡとｄａｔａＢとをそれぞれ業務プロセス定義ＤＢ１４０のデータＡ（業務データ型）、データＢ（業務データ型）と関連付ける（Ｓ１０７）。
そして、ｅｖｅｎｔ１とｄａｔａＡをｅｄｇｅ１（データエッジ情報）を介して関連付け、ｅｖｅｎｔ１とｄａｔａＢをｅｄｇｅ２（データエッジ情報）を介して関連付ける（Ｓ１０８）。ここで、業務データＡと業務データＢとは、イベント１の出力であるから、ｅｄｇｅ１では、ｅｖｅｎｔ１が（Ｓ）であり、ｄａｔａＡが（Ｔ）である。また、ｅｄｇｅ２では、ｅｖｅｎｔ１が（Ｓ）であり、ｄａｔａＢが（Ｔ）である。
【００４５】
次に、イベント２を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント２を取得する（Ｓ１０１）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント２をｅｖｅｎｔ２として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント２（イベント型）とｅｖｅｎｔ２とを関連付ける（Ｓ１０２）。
イベント２の前にイベント１を取得している（Ｓ１０３でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ１とｅｖｅｎｔ２とをｅｄｇｅ３（イベントエッジ情報）を介して関連付ける（Ｓ１０４）。ここで、イベント１はイベント２の前に到着しているから、ｅｄｇｅ３では、ｅｖｅｎｔ１が（Ｓ）であり、ｅｖｅｎｔ２が（Ｔ）である。
イベント２では業務データＢを入力している（Ｓ１０５でＹＥＳ）。また、業務データＢは既に業務プロセス記憶ＤＢ１５０に記憶されている（Ｓ１０６でＹＥＳ）。そこで、ｅｖｅｎｔ２とｄａｔａＢをｅｄｇｅ４（データエッジ情報）を介して関連付ける（Ｓ１０８）。ここで、業務データＢはイベント２の入力であるから、ｅｄｇｅ４では、ｄａｔａＢが（Ｓ）であり、ｅｖｅｎｔ２が（Ｔ）である。
【００４６】
次に、イベント３を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント３を取得する（Ｓ１０１）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント３をｅｖｅｎｔ３として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント３（イベント型）とｅｖｅｎｔ３とを関連付ける（Ｓ１０２）。
イベント３の前にイベント２を取得している（Ｓ１０３でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ２とｅｖｅｎｔ３とをｅｄｇｅ５（イベントエッジ情報）を介して関連付ける（Ｓ１０４）。ここで、イベント２はイベント３の前に到着しているから、ｅｄｇｅ５では、ｅｖｅｎｔ２が（Ｓ）であり、ｅｖｅｎｔ３が（Ｔ）である。
イベント３では業務データＡを入力し、業務データＣを出力している（Ｓ１０５でＹＥＳ）。また、業務データＡは既に業務プロセス記憶ＤＢ１５０に記憶されているが、業務データＣは業務プロセス記憶ＤＢ１５０に記憶されていない（Ｓ１０６でＮＯ）。そこで、業務データ取得部１３４は、業務データＣを取得する。また、業務プロセス記憶部１３５は、業務データＣをｄａｔａＣとして業務プロセス記憶ＤＢ１５０に記憶する。さらに、業務プロセス記憶部１３５は、ｄａｔａＣを業務プロセス定義ＤＢ１４０のデータＣ（業務データ型）と関連付ける（Ｓ１０７）。
そして、業務プロセス記憶部１３５は、ｅｖｅｎｔ３とｄａｔａＡをｅｄｇｅ６（データエッジ情報）を介して関連付け、ｅｖｅｎｔ３とｄａｔａＣをｅｄｇｅ７（データエッジ情報）を介して関連付ける（Ｓ１０８）。ここで、業務データＡはイベント３の入力であるから、ｅｄｇｅ６では、ｄａｔａＡが（Ｓ）であり、ｅｖｅｎｔ３が（Ｔ）である。一方、業務データＣはイベント３の出力であるから、ｅｄｇｅ７では、ｅｖｅｎｔ３が（Ｓ）であり、ｄａｔａＣが（Ｔ）である。
【００４７】
次に、イベント４を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント４を取得する（Ｓ１０１）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント４をｅｖｅｎｔ４として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント４（イベント型）とｅｖｅｎｔ４とを関連付ける（Ｓ１０２）。
イベント４の前にイベント３を取得している（Ｓ１０３でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ３とｅｖｅｎｔ４とをｅｄｇｅ８（イベントエッジ情報）を介して関連付ける（Ｓ１０４）。ここで、イベント３はイベント４の前に到着しているから、ｅｄｇｅ８では、ｅｖｅｎｔ３が（Ｓ）であり、ｅｖｅｎｔ４が（Ｔ）である。
イベント４では業務データＡを入力している（Ｓ１０５でＹＥＳ）。また、業務データＡは既に業務プロセス記憶ＤＢ１５０に記憶されている（Ｓ１０６でＹＥＳ）。そこで、ｅｖｅｎｔ４とｄａｔａＡをｅｄｇｅ９（データエッジ情報）を介して関連付ける（Ｓ１０８）。ここで、業務データＡはイベント２の入力であるから、ｅｄｇｅ９では、ｄａｔａＡが（Ｓ）であり、ｅｖｅｎｔ４が（Ｔ）である。
【００４８】
次に、出力部１７０がイベント１からイベント４までを到着順に容易に取得できることを説明する。
まず、業務処理の最初のイベントであるイベント１（イベント型）と関連付けられたイベント情報を業務プロセス記憶ＤＢ１５０から検索する。すると、ｅｖｅｎｔ１が見つかる。
次に、ｅｖｅｎｔ１とエッジを介して関連付けられているイベント情報を探すと、ｅｖｅｎｔ２が見つかる。続いて、ｅｖｅｎｔ２とエッジを介して関連付けられているイベント情報を探すと、ｅｖｅｎｔ３が見つかる。同様に、ｅｖｅｎｔ３からはｅｖｅｎｔ４が見つかる。
つまり、単にイベント情報とイベントエッジ情報とを順に辿るだけで、イベントを到着順に取得することができる。
【００４９】
この実施の形態に係る業務プロセス記録装置１００によれば、業務データを前提にしてイベント情報を記録するのではなく、イベント情報どうしをエッジで接続して記録するため、業務データを入出力しないイベントの記録が可能となる。
そのため、イベント情報を欠落なく記録することができる（課題（１）を解決できる）。
また、イベントが入出力する業務データ全てとそのイベントを示すイベント情報とがエッジを介して接続されるため、業務データを入出力するイベントを一意に取得できる。（課題（２）を解決できる）。
さらに、イベントをトラッキングする際、単にイベント情報とイベントエッジ情報とを順に辿るだけで、イベントを到着順に取得することができる。そのため、イベントを受信順に効率的に取得できる（課題（３）を解決できる）。
【００５０】
上記説明をまとめると、この実施の形態に係る業務プロセス記録装置１００は、以下の手段を備えることを特徴とする。
（１）業務システム２００から送信されたイベントを到着順に蓄積する手段。
（２）業務データの型やイベントの型を蓄積する手段。
（３）業務プロセス実行時の業務データやイベント、およびそれらの順序を示すエッジを蓄積する手段。
（４）蓄積されたイベントを順に取り出し、業務データやイベントやエッジを、各々の型と対応付けて記録する手段。
（５）記録された業務プロセスを検索するための条件をユーザが入力する手段。
（６）ユーザが入力した検索条件に基づき、記録された業務プロセスの状況を表示する手段。
【００５１】
実施の形態２．
この実施の形態では、イベントを業務プロセスと矛盾させずに記録する業務プロセス記録装置１００について説明する。
つまり、この実施の形態では、上記課題（４）を解決することができる。
【００５２】
この実施の形態に係る業務プロセス記録装置１００は、イベント情報や業務データが予め記憶した正しい業務プロセスに整合していることをチェックした上で業務プロセス記憶ＤＢ１５０に記録する。
そこで、この実施の形態に係る業務プロセス記録装置１００は、実施の形態１に係る業務プロセス記録装置１００の機能に、イベント情報や業務データ業務プロセスに整合していることをチェックする機能と、正しい業務プロセスを記憶する機能とが追加されている。
【００５３】
図１６に基づき、この実施の形態に係る業務プロセス記録装置１００の機能について説明する。図１６は、この実施の形態に係る業務プロセス記録装置１００の機能を示す機能ブロック図である。ここでは、この実施の形態に係る業務プロセス記録装置１００の機能について、実施の形態１に係る業務プロセス記録装置１００の機能と異なる部分についてのみ説明する。
【００５４】
この実施の形態に係る業務プロセス定義ＤＢ１４０は、正しい業務プロセスを記憶する。この実施の形態に係る業務プロセス定義ＤＢ１４０は、実施の形態１に係る業務プロセス記録装置１００の機能に加え、さらに、イベントエッジ定義ＤＢ１４３、データエッジ定義ＤＢ１４４を備える。
イベントエッジ定義ＤＢ１４３は、イベント定義ＤＢ１４１が記憶した複数のイベント定義情報の各イベント定義情報と、各イベント定義情報が示すイベントが実行される直前に実行される可能性のあるイベントを定義したイベント定義情報（イベントエッジ型）とを関連付けてイベントの実行順序を示したイベントエッジ定義情報を予め記憶装置に記憶する。
データエッジ定義ＤＢ１４４は、複数のイベント定義情報の各イベント定義情報と、各イベント定義情報が示すイベントで入出力される可能性のある業務データを定義したデータ定義情報とを関連付けたデータエッジ定義情報（データエッジ型）を予め記憶装置に記憶する。
つまり、業務プロセス定義ＤＢ１４０は、イベントの型や業務データの型に加え、イベントの実行順序と、イベントとそのイベントで入出力される業務データとの対応関係とを業務プロセスを示す業務プロセス定義情報として予め記憶する。
【００５５】
この実施の形態に係る業務プロセス記録装置１００は、実施の形態１に係る業務プロセス記録装置１００の機能に加え、業務プロセス確認部１８０を備える。
業務プロセス確認部１８０は、イベント取得部１３１が取得したイベント情報により特定されるイベントの実行順序と、そのイベントで入出力された業務データとが、業務プロセス定義ＤＢ１４０が記憶した業務プロセス定義情報が示す業務プロセスと整合するか否かを判定する。具体的には、（１）業務プロセス確認部１８０は、現イベント情報により特定されるイベントを定義したイベント定義情報と、前イベント情報により特定されるイベントを定義したイベント定義情報とを関連付けするイベントエッジ定義情報がイベントエッジ定義ＤＢ１４３に記憶されているか否かを判定する。（２）業務プロセス確認部１８０は、現イベント情報により特定されるイベントを定義したイベント定義情報と、上記現イベント情報により特定されるイベントで入出力された業務データを定義したデータ定義情報とを関連付けするデータエッジ定義情報がデータエッジ定義ＤＢ１４４に記憶されているか否かを判定する。そして、（３）業務プロセス確認部１８０は、イベントエッジ定義情報がイベントエッジ定義ＤＢ１４３に記憶されており、かつ、データエッジ定義情報がデータエッジ定義ＤＢ１４４に記憶されていると判断した場合、イベントが業務プロセス定義情報と整合すると判定する。
【００５６】
業務プロセス記憶部１３５は、イベントが業務プロセス定義情報と整合すると業務プロセス確認部１８０が判定した場合に業務プロセス情報を記憶する。つまり、業務プロセス記憶部１３５は、イベントが業務プロセス定義情報と整合する場合に、イベント情報、業務データ、イベントエッジ情報、データエッジ情報等を記憶する。言い換えると、業務プロセス記憶部１３５は、イベントが業務プロセス定義情報と整合しない場合には、業務プロセス情報を記憶しない。
【００５７】
次に、図１７に基づき、業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とに記憶される業務プロセス情報のデータ構造について説明する。図１７は、業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とに記憶される業務プロセス情報のスキーマを示すＵＭＬクラス図である。ここでは、図１３と異なる部分のみ説明する。
ノード型は、イベント型と業務データ型との抽象的なスーパークラスである。
エッジ型は、ノード型と関連付けられる。つまり、エッジ型はイベント型と業務データ型とに関連付けられる。
また、エッジ型は、業務プロセス記憶ＤＢ１５０中のエッジと関連付けられる。
エッジ型とノード型の関連は、正しい業務プロセスを定義する際に決定され、予め業務プロセス定義ＤＢ１４０に記憶される。エッジ型とノード型の関連は、イベント受信時に決まるエッジとノードの関連と同様である。つまり、イベント型とイベント型とを関連付けるイベントエッジ型と、イベント型と業務データ型とを関連付けるデータエッジ型とがある。イベントエッジ型は、上述したようにイベントの実行順序を表す。データエッジ型は、上述したようにイベントで入出力される業務データを表す。また、エッジとノードの関連と同様に、（Ｓ）と（Ｔ）とが定義される。
なお、イベントエッジ型を記憶する領域をイベントエッジ定義情報記憶領域と呼ぶ。データエッジ型を記憶する領域をデータエッジ定義情報記憶領域と呼ぶ。
【００５８】
次に、図１８に基づき、この実施の形態に係る業務プロセス記録装置１００の動作について説明する。図１８は、業務プロセス記録部１３０の動作を示すＵＭＬアクティビティ図である。ここでは、図１４と異なる部分のみ説明する。
【００５９】
（Ｓ２０１）は、（Ｓ１０１）と同様である。
（Ｓ２０２）では、業務プロセス確認部１８０は、取得したイベント情報が示すイベントの型、そのイベント情報が入出力する業務データの型、前イベント情報が示すイベントの型を業務プロセス定義ＤＢ１４０が記憶した業務プロセス定義情報と比較して、整合性のチェックを行う。
つまり、業務プロセス確認部１８０は、業務プロセス記憶ＤＢ１５０が記憶した前イベントと、業務プロセス定義ＤＢ１４０が記憶した業務プロセス定義情報が示すイベントの型とを取得する。そして、業務プロセス確認部１８０は、業務プロセス定義情報において、現イベントの型と前イベントの型とがエッジ型を介して接続されているかを確認する。また、業務プロセス確認部１８０は、業務プロセス定義情報において、取得したイベント情報で入出力する業務データの型が、現イベントの型とエッジ型を介して接続されているかを確認する。いずれも接続されているとの確認が取れれば、整合すると判定する。つまり、（１）現イベントの型と前イベントの型とを関連付けするイベントエッジ型が存在するかを確認する。（２）現イベントの型と入出力される業務データの型とを関連付けするデータエッジ型が存在するかを確認する。そして、（３）いずれも存在するなら整合すると判定する。
【００６０】
（Ｓ２０３）では、業務プロセス確認部１８０は、（Ｓ２０２）で行ったチェックの結果、取得したイベント情報が業務プロセス定義情報に整合したか否かを判定する。
整合したと判定する場合（Ｓ２０３でＹＥＳ）、（Ｓ２０４）へ進む。一方、整合しないと判定する場合（Ｓ２０３でＮＯ）、（Ｓ２０５）へ進む。
【００６１】
（Ｓ２０４）は、（Ｓ１０２）と同様である。
一方、（Ｓ２０５）では、業務プロセス確認部１８０は、整合性違反であったことを業務プロセス記憶ＤＢ１５０に記憶し、処理を終了する。つまり、整合しないと判定する場合（Ｓ２０３でＮＯ）、取得したイベント情報は記憶しない。
【００６２】
（Ｓ２０６）から（Ｓ２１１）までは、（Ｓ１０３）から（Ｓ１０８）までと同様である。
但し、（Ｓ２０７）では、イベントエッジ生成部１３２は、生成したイベントエッジ情報を、業務プロセス定義ＤＢ１４０が記憶したイベントエッジ型と関連付ける。
また、（Ｓ２１１）では、データエッジ生成部１３３は、生成したデータエッジ情報を、業務プロセス定義ＤＢ１４０が記憶したデータエッジ型と関連付ける。
【００６３】
次に、図４に示す業務処理をこの実施の形態に係る業務プロセス記録装置１００が記録する場合について説明する。図１９は、図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順にイベント情報を受信した際の業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とが記憶した情報を示すＵＭＬオブジェクト図である。
【００６４】
まず、図１９の構成について図１５と異なる部分について説明する。図１５と異なる部分は以下である。
まず、業務プロセス定義ＤＢ１４０は、エッジ型を記憶している。また、エッジ型と業務データ型とが関連付けられている。さらに、エッジ型とイベント型が関連付けられている。また、さらに、業務プロセス定義ＤＢ１４０が記憶したエッジは業務プロセス定義ＤＢ１４０のエッジ型に関連付けられている。
【００６５】
業務プロセス定義ＤＢ１４０の、業務データ型（Ｓ）−エッジ型−イベント型（Ｔ）の関連は、イベント型のイベントが業務データ型の業務データを入力することを示している。また、イベント型（Ｓ）−エッジ型−業務データ型（Ｔ）の関連は、イベント型のイベントが業務データ型の業務データを出力することを示している。
イベント型Ａ（Ｓ）−エッジ型−イベント型Ｂ（Ｔ）の関連はイベント型Ａのイベントの直後のイベントの型はイベント型Ｂであることを示している。
これらの関連は業務プロセス定義時に規定される。
【００６６】
図４に示す業務処理をこの実施の形態に係る業務プロセス記録装置１００が記録する処理について説明する。ここでは、図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順にイベント情報を受信したとする。また、前提として、業務プロセス定義ＤＢ１４０は、図１９に示す情報を業務プロセス定義情報として記憶しているものとする。
【００６７】
イベント１を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント１を取得する（Ｓ２０１）。
業務プロセス確認部１８０は、整合性チェックを行う。取得したイベント１の前イベント情報が記憶されていない。また、取得したイベント１は、業務データＡと業務データＢとを出力する。そのため、イベント１と業務データＡと業務データＢとの整合性のみチェックする。ここで、業務プロセス定義ＤＢ１４０を見ると、イベント１（Ｓ）（イベント型）は業務データＡ（Ｔ）（業務データ型）と業務データＢ（Ｔ）（業務データ型）と関連付けされていることが分かる。つまり、業務プロセス定義ＤＢ１４０において、イベント１（Ｓ）（イベント型）と業務データＡ（Ｔ）（業務データ型）はエッジ１（データエッジ型）を介して関連付けられており、イベント１（Ｓ）（イベント型）と業務データＢ（Ｔ）（業務データ型）はエッジ２（データエッジ型）を介して関連付けられている。したがって、イベント１は、業務プロセス定義情報に整合すると判定する（Ｓ２０２、Ｓ２０３）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント１をｅｖｅｎｔ１として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント１（イベント型）とｅｖｅｎｔ１とを関連付ける（Ｓ２０４）。
イベント１の前にイベント情報を取得していない（Ｓ２０６でＮＯ）。また、イベント１では業務データＡと業務データＢとを出力している（Ｓ２０８でＹＥＳ）。さらに、業務データＡと業務データＢとは、業務プロセス記憶ＤＢ１５０には記憶されていない（Ｓ２０９でＮＯ）。そこで、業務データ取得部１３４は、業務データＡと業務データＢとを取得する。また、業務プロセス記憶部１３５は、業務データＡをｄａｔａＡ、業務データＢをｄａｔａＢとして業務プロセス記憶ＤＢ１５０に記憶する。さらに、業務プロセス記憶部１３５は、ｄａｔａＡとｄａｔａＢとをそれぞれ業務プロセス定義ＤＢ１４０のデータＡ（業務データ型）、データＢ（業務データ型）と関連付ける（Ｓ２１０）。
そして、業務プロセス記憶部１３５は、ｅｖｅｎｔ１とｄａｔａＡをｅｄｇｅ１（データエッジ情報）を介して関連付け、ｅｖｅｎｔ１とｄａｔａＢをｅｄｇｅ２（データエッジ情報）を介して関連付ける。また、業務プロセス記憶部１３５は、ｅｄｇｅ１（データエッジ情報）とｅｄｇｅ２（データエッジ情報）とをそれぞれ業務プロセス定義ＤＢ１４０のエッジ１（データエッジ型）とエッジ２（データエッジ型）と関連付ける（Ｓ２１１）。ここで、業務データＡと業務データＢとは、イベント１の出力であるから、ｅｄｇｅ１では、ｅｖｅｎｔ１が（Ｓ）であり、ｄａｔａＡが（Ｔ）である。また、ｅｄｇｅ２では、ｅｖｅｎｔ１が（Ｓ）であり、ｄａｔａＢが（Ｔ）である。
【００６８】
次に、イベント２を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント２を取得する（Ｓ２０１）。
業務プロセス確認部１８０は、整合性チェックを行う。取得したイベント２の前イベント情報としてイベント１が記憶されている。また、取得したイベント２は、業務データＢを入力する。そのため、イベント１とイベント２との整合性と、イベント２と業務データＢとの整合性とをチェックする。業務プロセス定義ＤＢ１４０において、イベント１（Ｓ）（イベント型）とイベント２（Ｔ）（イベント型）はエッジ３（イベントエッジ型）を介して関連付けられている。また、イベント２（Ｔ）（イベント型）と業務データＢ（Ｓ）（業務データ型）はエッジ４（データエッジ型）を介して関連付けられている。したがって、イベント２は、業務プロセス定義情報に整合すると判定する（Ｓ２０２、Ｓ２０３）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント２をｅｖｅｎｔ２として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント２（イベント型）とｅｖｅｎｔ２とを関連付ける（Ｓ２０４）。
イベント２の前にイベント１を取得している（Ｓ２０６でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ１とｅｖｅｎｔ２とをｅｄｇｅ３（イベントエッジ情報）を介して関連付ける。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したエッジ３（イベントエッジ型）とｅｄｇｅ３（イベントエッジ情報）とを関連付ける（Ｓ２０７）。ここで、イベント１はイベント２の前に到着しているから、ｅｄｇｅ３では、ｅｖｅｎｔ１が（Ｓ）であり、ｅｖｅｎｔ２が（Ｔ）である。
イベント２では業務データＢを入力している（Ｓ２０８でＹＥＳ）。また、業務データＢは既に業務プロセス記憶ＤＢ１５０に記憶されている（Ｓ２０９でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ２とｄａｔａＢをｅｄｇｅ４（データエッジ情報）を介して関連付ける。また、業務プロセス記憶部１３５は、ｅｄｇｅ４（データエッジ情報）を業務プロセス定義ＤＢ１４０のエッジ４（データエッジ型）と関連付ける（Ｓ２１１）。ここで、業務データＢはイベント２の入力であるから、ｅｄｇｅ４では、ｄａｔａＢが（Ｓ）であり、ｅｖｅｎｔ２が（Ｔ）である。
【００６９】
次に、イベント３を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント３を取得する（Ｓ２０１）。
業務プロセス確認部１８０は、整合性チェックを行う。取得したイベント３の前イベント情報としてイベント２が記憶されている。また、取得したイベント３は、業務データＡを入力し、業務データＣを出力する。そのため、イベント２とイベント３との整合性と、イベント３と、業務データＡ及び業務データＣとの整合性とをチェックする。業務プロセス定義ＤＢ１４０において、イベント２（Ｓ）（イベント型）とイベント３（Ｔ）（イベント型）はエッジ５（イベントエッジ型）を介して関連付けられている。また、イベント３（Ｔ）（イベント型）と業務データＡ（Ｓ）（業務データ型）はエッジ６（データエッジ型）を介して関連付けられている。さらに、イベント３（Ｓ）（イベント型）と業務データＣ（Ｔ）（業務データ型）はエッジ７（データエッジ型）を介して関連付けられている。したがって、イベント３は、業務プロセス定義情報に整合すると判定する（Ｓ２０２、Ｓ２０３）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント３をｅｖｅｎｔ３として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント３（イベント型）とｅｖｅｎｔ３とを関連付ける（Ｓ２０４）。
イベント３の前にイベント２を取得している（Ｓ２０６でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ２とｅｖｅｎｔ３とをｅｄｇｅ５（イベントエッジ情報）を介して関連付ける。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したエッジ５（イベントエッジ型）とｅｄｇｅ５（イベントエッジ情報）とを関連付ける（Ｓ２０７）。ここで、イベント２はイベント３の前に到着しているから、ｅｄｇｅ５では、ｅｖｅｎｔ２が（Ｓ）であり、ｅｖｅｎｔ３が（Ｔ）である。
イベント３では業務データＡを入力し、業務データＣを出力している（Ｓ２０８でＹＥＳ）。また、業務データＡは既に業務プロセス記憶ＤＢ１５０に記憶されているが、業務データＣは業務プロセス記憶ＤＢ１５０に記憶されていない（Ｓ２０９でＮＯ）。そこで、業務データ取得部１３４は、業務データＣを取得する。また、業務プロセス記憶部１３５は、業務データＣをｄａｔａＣとして業務プロセス記憶ＤＢ１５０に記憶する。さらに、業務プロセス記憶部１３５は、ｄａｔａＣを業務プロセス定義ＤＢ１４０のデータＣ（業務データ型）と関連付ける（Ｓ２１０）。
そして、業務プロセス記憶部１３５は、ｅｖｅｎｔ３とｄａｔａＡをｅｄｇｅ６（データエッジ情報）を介して関連付け、ｅｖｅｎｔ３とｄａｔａＣをｅｄｇｅ７（データエッジ情報）を介して関連付ける。また、業務プロセス記憶部１３５は、ｅｄｇｅ６（データエッジ情報）とｅｄｇｅ７（データエッジ情報）とをそれぞれ業務プロセス定義ＤＢ１４０のエッジ６（データエッジ型）とエッジ７（データエッジ型）と関連付ける（Ｓ２１１）。ここで、業務データＡはイベント３の入力であるから、ｅｄｇｅ６では、ｄａｔａＡが（Ｓ）であり、ｅｖｅｎｔ３が（Ｔ）である。一方、業務データＣはイベント３の出力であるから、ｅｄｇｅ７では、ｅｖｅｎｔ３が（Ｓ）であり、ｄａｔａＣが（Ｔ）である。
【００７０】
次に、イベント４を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント４を取得する（Ｓ２０１）。
業務プロセス確認部１８０は、整合性チェックを行う。取得したイベント４の前イベント情報としてイベント３が記憶されている。また、取得したイベント４は、業務データＡを入力する。そのため、イベント３とイベント４との整合性と、イベント４と業務データＡとの整合性とをチェックする。業務プロセス定義ＤＢ１４０において、イベント３（Ｓ）（イベント型）とイベント４（Ｔ）（イベント型）はエッジ８（イベントエッジ型）を介して関連付けられている。また、イベント４（Ｔ）（イベント型）と業務データＡ（Ｓ）（業務データ型）とはエッジ９（データエッジ型）を介して関連付けられている。したがって、イベント４は、業務プロセス定義情報に整合すると判定する（Ｓ２０２、Ｓ２０３）。
業務プロセス記憶部１３５は、業務プロセス記憶ＤＢ１５０にイベント４をｅｖｅｎｔ４として記録する。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したイベント４（イベント型）とｅｖｅｎｔ４とを関連付ける（Ｓ２０４）。
イベント４の前にイベント３を取得している（Ｓ２０６でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ３とｅｖｅｎｔ４とをｅｄｇｅ８（イベントエッジ情報）を介して関連付ける。また、業務プロセス記憶部１３５は、業務プロセス定義ＤＢ１４０が記憶したエッジ８（イベントエッジ型）とｅｄｇｅ８（イベントエッジ情報）とを関連付ける（Ｓ２０７）。ここで、イベント３はイベント４の前に到着しているから、ｅｄｇｅ８では、ｅｖｅｎｔ３が（Ｓ）であり、ｅｖｅｎｔ４が（Ｔ）である。
イベント４では業務データＡを入力している（Ｓ２０８でＹＥＳ）。また、業務データＡは既に業務プロセス記憶ＤＢ１５０に記憶されている（Ｓ２０９でＹＥＳ）。そこで、業務プロセス記憶部１３５は、ｅｖｅｎｔ４とｄａｔａＡをｅｄｇｅ９（データエッジ情報）を介して関連付ける。また、業務プロセス記憶部１３５は、ｅｄｇｅ９（データエッジ情報）を業務プロセス定義ＤＢ１４０のエッジ９（データエッジ型）と関連付ける（Ｓ２１１）。ここで、業務データＡはイベント２の入力であるから、ｅｄｇｅ９では、ｄａｔａＡが（Ｓ）であり、ｅｖｅｎｔ４が（Ｔ）である。
【００７１】
次に、整合性チェックにおいて整合しないと判定される場合について説明する。一例として、イベント１を受信後に、業務データＡと業務データＢとを入力するイベント４を受信した例を説明する。
イベント１は正しい順序および入出力を持っているため上記の通り記録される。
次に、イベント４を受信した場合について説明する。
イベント取得部１３１は、イベントキュー１２０からイベント４を取得する（Ｓ２０１）。
業務プロセス確認部１８０は、整合性チェックを行う。取得したイベント４の前イベント情報としてイベント１が記憶されている。また、取得したイベント４は、業務データＡと業務データＢと関連がある。そのため、イベント１とイベント４との整合性と、イベント４と業務データＡ及び業務データＢとの整合性とをチェックする。業務プロセス定義ＤＢ１４０において、イベント１（イベント型）とイベント４（イベント型）はエッジ（イベントエッジ型）を介して関連付けられていない。また、イベント４（イベント型）と業務データＢ（業務データ型）とはエッジ（データエッジ型）を介して関連付けられていない。したがって、イベント４は、業務プロセス定義情報に整合しないと判定する（Ｓ２０２、Ｓ２０３）。
業務プロセス確認部１８０は、イベント４は整合性違反であったことを業務プロセス記憶ＤＢ１５０に記憶する（Ｓ２０５）。
【００７２】
この実施の形態に係る業務プロセス記録装置１００によれば、イベントを記録する際、業務プロセス定義情報に則っているかをチェックする。そのため、業務プロセスに矛盾するイベント順番や入出力業務データが記録されることを抑止できる。
したがって、業務プロセスに矛盾しないイベントのみを記録することができる（課題（４）を解決できる）。
【００７３】
つまり、この実施の形態に係る業務プロセス記録装置１００は、以下の手段を備えることを特徴とする。
（１）業務システム２００から送信されたイベントを到着順に蓄積する手段。
（２）業務データの型やイベントの型、およびそれらの順序を示すエッジの型を蓄積する手段。
（３）業務プロセス実行時の業務データやイベント、およびそれらの順序を示すエッジを蓄積する手段。
（４）記録されたイベントを順に取り出し、業務データの型やイベントの型やエッジの型の関連と等しいかチェックした上で、業務データやイベントやエッジを各々の型と対応付けて記録する手段。
（５）記録された業務プロセスを検索するための条件をユーザが入力する手段。
（６）ユーザが入力した検索条件に基づき、記録された業務プロセスの状況を表示する手段。
【図面の簡単な説明】
【００７４】
【図１】業務プロセス記録装置１００を備える業務プロセス記録システムの外観の一例を示す図。
【図２】業務プロセス記録装置１００ハードウェア構成の一例を示す図。
【図３】業務プロセス記録装置１００の基礎となる業務プロセス記録技術によりイベントを記録したＤＢのスキーマを示したＵＭＬクラス図。
【図４】業務処理の一例を示すＵＭＬアクティビティ図。
【図５】業務プロセス記録装置１００の基礎となる業務プロセス記録技術により、図４のイベント１をデータＡを主業務データとして記憶した場合の記憶装置の状態を示す図。
【図６】業務プロセス記録装置１００の基礎となる業務プロセス記録技術により、図４のイベント１をデータＢを主業務データとして記憶した場合の記憶装置の状態を示す図。
【図７】図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順に受信する場合のイベント１受信時の記憶装置の状態を示す図。
【図８】図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順に受信する場合のイベント２受信時の記憶装置の状態を示す図。
【図９】図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順に受信する場合のイベント３受信時の記憶装置の状態を示す図。
【図１０】図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順に受信する場合のイベント４受信時の記憶装置の状態を示す図。
【図１１】図４に示す業務処理をイベント１、イベント３、イベント２、イベント４の順に受信する場合の全てのイベント受信時の記憶装置の状態を示す図。
【図１２】実施の形態１に係る業務プロセス記録装置１００の機能を示す機能ブロック図。
【図１３】実施の形態１に係る業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とに記憶される業務プロセス情報のスキーマを示すＵＭＬクラス図。
【図１４】実施の形態１に係る業務プロセス記録部１３０の動作を示すＵＭＬアクティビティ図。
【図１５】図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順にイベント情報を受信した際の実施の形態１に係る業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とが記憶した情報を示すＵＭＬオブジェクト図。
【図１６】実施の形態２に係る業務プロセス記録装置１００の機能を示す機能ブロック図。
【図１７】実施の形態２に係る業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とに記憶される業務プロセス情報のスキーマを示すＵＭＬクラス図。
【図１８】実施の形態２に係る業務プロセス記録部１３０の動作を示すＵＭＬアクティビティ図。
【図１９】図４に示す業務処理をイベント１、イベント２、イベント３、イベント４の順にイベント情報を受信した際の実施の形態２に係る業務プロセス定義ＤＢ１４０と業務プロセス記憶ＤＢ１５０とが記憶した情報を示すＵＭＬオブジェクト図。
【符号の説明】
【００７５】
１００  業務プロセス記録装置、１１０  イベント受信部、１２０  イベントキュー、１３０  業務プロセス記録部、１３１  イベント取得部、１３２  イベントエッジ生成部、１３３  データエッジ生成部、１３４  業務データ取得部、１３５  業務プロセス記憶部、１４０  業務プロセス定義ＤＢ、１４１  イベント定義ＤＢ、１４２  データ定義ＤＢ、１４３  イベントエッジ定義ＤＢ、１４４  データエッジ定義ＤＢ、１５０  業務プロセス記憶ＤＢ、１６０  入力部、１７０  出力部、１８０  業務プロセス確認部、９０１  ＬＣＤ、９０２  Ｋ／Ｂ、９０３  マウス、９０４  サーバ、９０５  データベース、９０６  ＰＣ、９１１  ＣＰＵ、９１２  バス、９１３  ＲＯＭ、９１４  ＲＡＭ、９１５  通信ボード、９１６  サーバＡ、９１７  サーバＢ、９１８  サーバＣ、９２０  磁気ディスク装置、９２１  ＯＳ、９２２  ウィンドウシステム、９２３  プログラム群、９２４  ファイル群。
【図１】
2009003682.tif 000003
【図２】
2009003682.tif 000004
【図３】
2009003682.tif 000005
【図４】
2009003682.tif 000006
【図５】
2009003682.tif 000007
【図６】
2009003682.tif 000008
【図７】
2009003682.tif 000009
【図８】
2009003682.tif 000010
【図９】
2009003682.tif 000011
【図１０】
2009003682.tif 000012
【図１１】
2009003682.tif 000013
【図１２】
2009003682.tif 000014
【図１３】
2009003682.tif 000015
【図１４】
2009003682.tif 000016
【図１５】
2009003682.tif 000017
【図１６】
2009003682.tif 000018
【図１７】
2009003682.tif 000019
【図１８】
2009003682.tif 000020
【図１９】
2009003682.tif 000021