JP2009522643A - イベントストリーム上の多次元集合体 - Google Patents

Abstract

どのイベントが利用可能かに関するメタデータに基づくレポートを作成するためのイベントストリーム上の多次元集合体。集合体定義ツールは、イベントストリームを受信し、イベントからアクティビティを定義するために、ユーザ入力への応答、関心があるイベントの識別、および相関パターンを特定する。ユーザインタフェースにより、ユーザが、所望のレポートの次元構造体およびイベントのデータ項目と次元構造体との間のマッピングを定義できる。

Description

本発明は、イベントストリーム上の多次元集合体に関する。

多くの企業では、ビジネス活動の監視と取引の処理を行うために、コンピュータシステムを利用する。特に複雑な取引と活動を行う企業体では、分散コンピュータシステムを多く用いる。そのようなものとして、現在のネットワーク、システム、アプリケーション、およびビジネスは、本質的に分散型およびイベント駆動型である。

例えば、オンライン小売業者は、ビジネスアプリケーションを使用してオンライン注文書を受け取り、在庫アプリケーションを使用して店の在庫管理と納入業者との連絡を取り、他のアプリケーションまたはサービスを使用してオンラインのインタフェースの作成と発送を管理する。他の例では、ウェブサーバは、重いクライアント負荷を抱え、多数の様々なＵＲＬ(uniform resource locators)に登録されている多くのスクリプトを配信することが多い。各クライアントの要求は、複数の監視イベントが生じる可能性があり、それらの要求は、互いに非同期的および独立して扱われるため、サーバは、監視イベントの連続的なストリームを作成する。この例では、ネットワーク管理者は、これらの監視イベントに基づくネットワーク性能の分析に大いに関心を持つかもしれない。

関心があるイベントは、企業の至るところで起きる。残念ながらイベント駆動型システムのユーザは、イベントに含まれる情報を容易に検証するか、または関心があるパターンを全体的に分析する中心的な部分がないために、イベントストリームからの情報を容易に抽出することができないことが多い。このためイベント駆動型システムを使用する企業の中には、価値のある情報に対して無知である結果、状況の変化および発展を認識し、それらに対応するユーザの能力をひどく損なう恐れがある。

現在、リモートイベントの監視および集中化を行う多様な技術が存在する。例えば、オペレーション管理ツールは、サーバイベントを管理するために、報告と動向分析に加え、監視と警告も提供する。また監視収集サービスは、セキュリティイベントを管理する。小売業界では、従来型のＲＦＩＤ(radio frequency identification)のフレームワークが、在庫追跡等の目的でかなり普及している。しかしユーザは、イベント情報を集めるためのレポートを、速く、容易に、直観的に定義することがまだできない。

例えば、現在のＢＡＭ(business activity monitoring)のユーザの経験上、ビジネス過程、およびビジネスアナリストと開発者の役割の分離を重視している。標準的なＢＡＭの解決法では、先にビジネスアナリストが、観察モデル（例えば、望ましいデータ閲覧）を定義し、その後開発者が実装することにより、これらのモデルを利用可能なイベントにマップする。このトップダウン方式は、ＢＡＭにとっては効果があるが、利用可能なイベントを理解し、主としてボトムアップ、つまりイベントからレポートまでを行うことを望む一人のユーザによって、システムが構成される場合、直感的な解決法を提供しない。

どのイベントが利用可能かに関するメタデータに基づくレポートをユーザが直接定義できる改良されたイベント報告を提供することにより、発明の実施形態は、周知の報告システムの１または２以上の欠陥を克服する。発明の態様によりユーザは、どのようにイベントストリームをデータおよび多次元集合体に「整形」したいか、ＳＱＬおよびデータウェアハウジングの知識を用いずに考えることができる。関心があるイベントを集中化させることによりユーザは、イベントストリームのデータビューを容易に作成し、ＢＡＭツール等で利用できる相関プロセッサを使用できる。一態様において本発明は、関心がある、望ましい相関パターンおよび次元構造体であるイベントを特定するユーザ入力を捕え、次にイベントのデータ項目と次元構造体との間をマップする。本発明の態様は有利に、現在のＢＡＭランタイムと関連して機能し、イベントストリームがどのような種類であっても集合体へと仮想的に操作する。

イベントストリームからレポートを作成し、直観的にユーザ体験の定義を行うコンピュータ実行命令を有するコンピュータ読み取り可能媒体は、本発明の態様をさらに具体化する。もう１つの方法として本発明の実施形態は、他の各種方法および装置を含むことができる。

他の機能を、本明細書で一部明白に、一部指摘する。

本発明の開示では、以下の詳細な説明でさらに記述される簡略化形式で、概念の選択を紹介する。本発明の開示は、請求された発明の対象の重要または必須の機能を明らかにするものでなく、請求された発明の対象の範囲を決定するための補助として使用されるものでもない。

対応する参照文字は、図中に対応する部分を示す。

図１を参照して、本発明が、イベントストリーム上の多次元集合体を定義するために実施できる例示的なコンピュータ環境２０を示す。図のように、コンピュータ装置２２は、イベントストリーム２４を処理して、ストリームの中の情報の代表である１または２以上のレポート２６を作成するためのコンピュータ実行命令を実行する。一実施形態では、コンピュータ装置２２上で実装される集合体定義ツール２８は、イベントストリーム２４の中のどのイベントに関心があるか、望ましい相関パターンは何か、望ましい次元構造体は何か、およびイベントの中のデータ項目と次元構造体との間のマッピングは何かに関するユーザ入力を捕える。

本発明の態様を示すために、図２に、イベントストリーム２４の例を提示する。この場合、イベントストリーム２４は、ウェブサーバ３２の中の診断イベントのストリームを備える。サーバ３２の管理者または他のユーザは、どのようにイベントデータが「整形」されるか定義することによって、各種レポートを得ることができる。例示目的のために、ウェブサーバ３２は、外部スクリプト３４の実行が可能であり、４つの監視イベント（大まかにＡ、Ｂ、Ｃ、およびＤで表す）を搭載している。クライアントがサーバ３２のソケットを開く時、スクリプト３４のＵＲＬおよびある主張を伴うリクエスト（例えば、HTTPGET）を送信できる。次にサーバ３２は、ある出力を作る適正なスクリプト３４を特定し、実行する。図２に、スクリプト３４を実行するコンポーネント３６を示す。サーバ３２は、２００（ＯＫ）または５００（内部のサーバエラー）等の状態コードを返信し、ソケットを閉める前に、スクリプトからの出力またはエラー情報をクライアントに流す。

一実施形態では、４つの診断イベントＡ、Ｂ、Ｃ、およびＤは、ウェブサーバ３２の監視に利用可能である。Ａにおいて、イベントHTTPRequest_Beginは、ＵＲＬおよびバイトで表した入力リクエストのサイズ等のデータを含む。Ｂにおいて、イベントScriptExecution_Beginは、サーバ３２がスクリプト処理（例えばPerlインタープリタ）を発生させる時に起こる。Ｃにおいて、イベントScriptExecution_Endは、実行されたスクリプト３４が完了（または結果として起こるエラーコード）した時を示す。Ｄにおいて、イベントHTTPRequest_Endは、リクエストが完了（任意のエラーコードを含む）した時に起こる。これらの例では、起こる可能性のあるイベントのリストとそれらのイベントが含む（例えばそれらのイベントのスキーマ）データの形は、前もって分かる。発明の態様に従って、集合体定義ツール２８は、イベントストリーム２４を処理するイベントメタデータを利用する。図２を例とするイベントのメタデータは、以下に示すような、項目名がメタデータを特定するＸＭＬ(extensible markup language)によって具体化できる。

図２をさらに参照して、サーバ３２は、多くのクライアントからの重い負荷を抱え、様々なＵＲＬに登録されている多くの様々なスクリプト３４を配信する。この例で各リクエストでは、４つの監視イベントが生じ、それらのリクエストは互いに非同期および独立して扱われるため、サーバ３２は、監視イベントの連続的なストリームを作成する。従って、同時に処理されるリクエストのイベントは、交互配置される。

少なくとも一部のスクリプト３４が、エラーを含み、機能しなくなることは珍しくない。そのようなエラーが発生する場合、ウェブサーバ３２は、エラー５００（内部サーバエラー）をクライアントに返すが、安全上の理由からエラーコードを伝えることができない。サーバ３２の管理者は、どのスクリプト３４が機能していないか、どれくらいの頻度で機能しなくなるのか、どんなエラーコードを伴っているのか確かめたい傾向がある。図３は、発明の実施形態に従った多次元集合体の態様を示す例示的な画面情報であり、この種の情報を管理者に提供するのに有効なフォーマット（例えばＵＲＬごとのエラー理由）である。それらの情報は、監視イベント（例えばイベントストリーム２４）のストリームの中に含まれる。

ウェブサーバの例では、ＵＲＬは１つのイベントの中にあり、スクリプト３４からのエラーコードは、別のイベントの中にあり、HTTP Result Codeは、また別のイベントの中にある。図３に示される例示的なレポートを得るために、集合体定義ツール２８を含むシステム２０は、個々のリクエストに対するイベントを関連付けるまたは「まとめる」。言い換えれば、集合体定義ツール２８により、システム２０は、関心があるイベントを、全てのアクティビティ（例えば仕事の単位）を表すレコードに蓄積させて、次にそれらのアクティビティを多次元構造体に集合させることができる。図３では、多次元集合体は、ＵＲＬおよび｛HTTPResult, ReturnCode｝によってグループ分けされた着信総数を蓄積する。

ウェブサーバ３２の管理者にとってのもう一つの関心があるレポートは、サーバの性能（例えば各ＵＲＬのリクエストを実行するのにどれくらい時間がかかるか、スクリプト３４が終了するのに今回何パーセントが待機させられているか）についてかもしれない。図４は、発明の実施形態に従った多次元集合体の態様をさらに示す例示的な画面情報である。この例では、システム２０は、ＵＲＬごとのリクエスト期間（例えばイベントＡとイベントＤとの間の期間）およびＵＲＬごとのスクリプト期間（例えばイベントＢとイベントＣとの間の期間）を示すレポートを提示する。図示された構造体では、レポートは、１次元（ＵＲＬ）および２つの計測（リクエスト期間およびスクリプト期間）を有する。

先の例と同様に、関心があるデータは、複数のイベントに含まれる。例えば、ＵＲＬは、HTTPRequest_Beginの中にあり、それらのリクエストの平均期間は、リクエストごとのHTTPRequest_BeginとHTTPRequest_Endとの間の時間を平均することによって計算され、スクリプト期間は、ScriptExecution_BeginとScriptExecution_Endとの間の時間を平均することによって計算される。ウェブサーバ３２の管理者は、自分たちのメタデータに基づくイベントについて再度知る。この場合、管理者は、どんなレポートが望ましいか既に知っていて、どのようにデータが処理されるべきかについて少なくとも高レベルのアイディアを有しているかもしれない。残念ながら、既存のテクノロジーは、開発者に、これらの情報を要求として取るように求めて、関心があるレポートを作成するためにデータウェアハウスを構築する。本発明の実施形態により、有利に、管理者は、直接実行可能な構造化された方法で、要求を捕えることができる。

図５，６、および７を参照して、発明の態様は、３つのステップを用いてユーザ入力を捕える。すなわち、関心があるイベントを選択すること、相関関係（例えばアクティビティ動作）を特定すること、およびどのようにしてイベントデータが集合体（例えば次元構造体およびマッピング）として変換されるか特定することである。

図５は、発明の実施形態に従った関心があるイベントを選択するユーザインタフェースの態様を示す例示的な画面情報である。図５に、ウェブサーバ３２の例を継続する。図のように、ユーザインタフェースは、観察モデルを定義する、または言い換えれば関心があるイベントを選択するツールを提供する。ツールの左枠は、最初の空白を示す。管理者が、「イベント追加」ボタンをクリックすると、ユーザインタフェースは、例えばメタデータごと等のイベントのリストを示すようなダイアログボックスを表示する。管理者は、次に関心があるイベント（およびＯＫをクリックする）を選択できる。ダイアログボックスまたはポップアップウィンドウは消えて、左枠は今度、選択されたイベントのスキーマで埋められる。この場合、システム２０は、イベントのメタデータからスキーマを検索する。

図５のユーザインタフェースによっても、管理者が、相関基準つまり、複数のイベントが同じアクティビティ（例えばHTTPRequest）に属する指標であることをユーザが考慮する相関基準を定義できる。例えば、管理者は、各イベントにある「RequestID」フィールドを右クリックし、文脈メニューから「Make Correlation Key」を選ぶことによってイベントをグループ分けするRequestIDを選択できる。さらに、管理者は、定義されたアクティビティの中のどのイベントが最初（Begin）であり最後（End）であるか特定する。例えば、管理者は、これらの選択を、Event Rootsを右クリックし、文脈メニューから開始「Begin」または終了「End」を選ぶことによって行う。当然のことながら、ユーザインタフェースの記述は、単に例示的なものであり、ユーザは、関心があるイベントおよび相関基準を他の手段（例えばドラッグおよびドロップまたはチェックボックス）で特定することができる。

これらの動作の結果、図５の左枠の一覧が、図６に示すようにあらわれる。図６は、発明の実施形態に従ったアクティビティ動作（例えば相関関係、開始イベントおよび終了イベント）を定義するユーザインタフェースの態様を示す例示的な画面情報である。この例では、管理者は、右クリックしてRequestIDをCorrelation Key（例えばこのRequestIDと相関があるイベント）に登録する。HTTPRequest_Beginのルートにあるグラフィカルアイコンは、これがアクティビティ（例えばルートにある円形を緑色の三角形に変える）の開始イベントであることを示す。同様に、HTTPRequest_Endのルートにあるグラフィカルアイコンは、これがアクティビティ（例えばルートにある円形を赤色の四角形に変える）の終了イベントであることを示す。両方のイベントにあるペイロードのデータ項目「RequestID」は、Correlation Keyとして図６に反転表示される。

多くのイベントは、開始イベントでも終了イベントでもない同じアクティビティに属すことができ、それらの１つがそのアクティビティの特定のインスタンスの中で起こる限り、複数の開始イベントまたは終了イベントになる可能性がある。また、図６の例では、１つのCorrelation Keyが使用されている。当業者は、管理者が、複雑なパターン（ＢＡＭ連続に似たもの）をわずかにより複雑なＵＩの表示を用いて定義できることを評価する。

Correlation Keyおよび開始−終了を特定することで、ストリーム処理システムに、あるイベントインスタンスを一緒に属するものとみなす方法、新しいインスタンスの開始のタイミング、データを削除するタイミングを知らせる。もう１つの方法として、これらのアクティビティ動作は、以下の例に示すように、イベントメタデータの注釈形式で既に存在することができる。

この場合、メタデータは、アクティビティ動作を特定するので、管理者は、過去のマニュアルステップを省略し、関心があるイベントのみを選択することができ、図６に示す結果を再度得る。

この例において管理者が、いったん関心があるイベントとアクティビティ動作を特定すると、管理者は、アクティビティがどのように集合化されるか定義することができる。この実施例でそれを行うために、管理者は、左側のイベントスキーマからの項目を、図５，６、および７のＵＩの右枠にドラッグする。いったん項目がドロップされると、「計測する」または「次元を作成する」等のオプションを用いて文脈メニューを支援する。これらのオプションから選ぶことによって、管理者は、右枠の付随のアイコンを用いて新しいツリー構造体を定義する。図７は、望ましいレポート（例えば図３および図４）を支援するために、発明の実施形態に従ったイベントスキーマから次元構造体およびマッピングを定義するユーザインタフェースの態様を示す例示的な画面情報である。

ウェブサーバの例に引き続き、管理者は、図３に示すような望ましいレポートは、全てのリクエストのカウントを使用することに気付くかもしれない。このことは、イベントHTTPRequest_Beginの発生のカウントと同じである。従って、管理者は、そのイベントのルートを右にドラッグし、次にその上を右クリックして「計測を作成する」を選ぶ。この時点で、円形のアイコンは、合計シンボルに変わる。図３のレポートは、様々なＵＲＬのカウントを識別する。この場合、それらのＵＲＬは次元であるから、管理者が「ＵＲＬ」を右にドラッグし、文脈メニューから「次元を作成する」を選ぶ。

図３のカウントも、先にHTTP Result Codeによってグループ分けされ、その後にスクリプト３４からのReturn Codeによってグループ分けされる。これは、２つのレベルを用いて次元を定義することによって達成できる。管理者がHTTP Result Codeを右にドラッグし、「次元を作成する」を選ぶことで、ＵＲＬに類似の次元サブツリーに変換する。管理者は次に、ScriptExecution_EndイベントからのReturn Codeを、この次元のルートにドラッグする。従って、Return Codeは、同じ次元で別のレベルになる。最後に、管理者は、その次元を「エラー」と呼ばれる名前に変更する。

図４のレポートを得るために、最初から最後までのイベントの期間が平均化される。このことをツールの中で捕えるために、管理者は、HTTPRequest_Beginのルートを再度ドラッグするが、このとき管理者は、「期間を開始する」を選ぶ。例えば、新しいノードが、クロックおよび計測矢印アイコンを伴ってあらわれ、イベントは、この期間ノードの下方にあるスタートノードとして動く。管理者が次にHTTPRequest_Endのルートを期間ノード上にドラッグすることで、この期間の終了イベントとしてあらわれる。最後に、管理者は、期間ノード上をクリックし、「計測を作成する」を選ぶ。ユーザは次に、集合体機能（平均）を選択し、新しい計測ノードがその期間の親としてあらわれる。管理者は、これらを、ユーザがレポートの中で見たいものに名前を変更する。管理者は、別の期間（例えばScriptExecution_BeginとScriptExecution_Endとの間）を、計測として定義することができる。

管理者が、ユーザインタフェースツール（例えばReturn Code）の右枠の任意の項目上をクリックする場合、イベントメタデータの中の対応する項目が反転されるので、これがどこから来たのか明確になる。これを用いることでツールは、例えば図３および４のようなレポートを作成する方法の十分な情報を含む。

当然のことながら、発明の各種態様は、ＵＩの特定の外観および特定の表示に限定されない。むしろユーザインタフェースがツールを提供することにより、ユーザは、どのイベントに関心があるのか、アクティビティ（相関）動作、望ましい次元構造体、期間の含有、イベントと次元構造体との間のマッピング等のいくつかの情報を捕えることができる。さらに、ウェブサーバ３４および管理者が上述の事例を使用することは、単に例示的である。当業者は、ビジネスユーザが、関心があるレポートを例えばＲＦＩＤ等の体系化されたイベント発生源から同じ要領で定義できることを容易に理解する。一般に発明の態様は、既知のメタデータを用いることで、任意のユーザおよび任意のイベントストリームに適用できる。

図８は、発明の実施形態の態様をさらに実行する例示的なコンピュータシステムのブロック図である。このツールに集められた情報が、実行に十分であるか示すために、発明の一実施形態を用いて、既存のＢＡＭ基盤を組み込む。この実施形態では、イベントストリーム２４形式のメタデータで、起こりうる可能な（例えば利用可能な）イベントのスキーマを説明する。集合体定義ツール２８は、上述のメタデータを消費する。その出力時に集合体定義ツール２８は、ＢＡＭ定義３８（例えばＸＭＬファイル）を作る。ＢＡＭ定義３８は、関心のあるアクティビティ、計測および次元を説明する標準フォーマットに含むことができる。コマンドラインツールbm.exe４０は、ＢＡＭ定義３８を消費し、ストリーム認識データウェアハウス４２（例えば動的ＢＡＭ基盤）を作る。ツール２８からの別の出力は、傍受構成４６であり、ＢＡＭウェアハウス４２の中の相関ヒント、イベントとアクティビティとの間のマッピングを定義する。

ＭＯＭ（オペレーション監視イベント）、ウィンドウズ（登録商標）版監視収集サービス（セキュリティ監視イベント）またはＲＦＩＤ（ビジネスイベント）等の基盤または集合メカニズム４８は、実行中イベントを集める。比較的小さなプラグ着脱可能なコンポーネント（例えばインターセプタ５０）がフィルタをかけ、イベントをそれらの元のスキーマからＢＡＭＡＰＩの特性に類似のアクティビティ変更イベントへ転送する。別のコンポーネント（または同等のもの）は、アクティビティ変更イベントを取り込み、ＢＡＭＡＰＩを呼び出す。

図９は、発明の実施形態に従ったイベントストリーム２４からレポートを作成する例示的な動作を示すフロー図である。動作中、コンピュータ２２は、複数のイベントを含むイベントストリーム２４からレポートを作成する方法を行うためのコンピュータ実行命令を実行する。６０において開始し、集合体定義ツール２８は、イベントストリーム２４を受信し、関心があるイベントに関連するメタデータを検索する。ユーザ入力に基づいて、イベントストリーム２４の中の１または２以上の関心があるイベントは、６２において識別される。６４に進み、集合体定義ツール２８は６６において、これらの関心があるイベントをどのように相関させるかメタデータに基づいて定義する。発明の態様はレポートを作成するために、６６においてレポートの次元構造体を定義し、次に６８において相関イベントを次元構造体にマッピングする。７０においてイベントストリームの連続的な処理が起こり、７２においてユーザインタフェースは、レポート形式で、ユーザにマッピングを表す情報を提示する。

図１に示す例示的な動作環境は、コンピュータが実行するコンピュータ実行命令等の汎用コンピュータ装置（例えばコンピュータ装置２２）を含む。コンピュータ装置は、典型的には少なくともあるコンピュータ読み取り可能媒体形式を有する。揮発性および不揮発性媒体と、取り外し可能および不可能の両方を含むコンピュータ読み取り可能媒体は、汎用コンピュータ装置がアクセスできる、任意の利用可能なものにできる。１例および限定のないものとして、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体を含む。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造体、プログラムモジュールまたは他のデータ等の情報の記憶のための任意の方法またはテクノロジーで実行される揮発性および不揮発性、取り外し可能および不可能の媒体を含む。

図１０は、発明の態様を実行するコンピュータ実行命令を含む例示的なコンピュータ読み取り可能媒体７６を示すブロック図である。図のように、発明の一実施形態は、イベントスキーマコンポーネント、集合体定義ツール、およびビジネスアクティビティモニタを含む。

通信媒体は典型的には、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、または他のデータを、搬送波または他の運搬メカニズム等の変調データ信号で具体化し、任意の情報提供媒体を含む。当業者は、１または２以上の特性セットまたは信号の情報を符号化するような方法で変更された変調データ信号に精通している。有線ネットワークまたは直接有線接続等の有線媒体、音響、ＲＦ、赤外線等の無線媒体、および他の無線媒体は、通信媒体の例である。上記の任意の組み合わせも、コンピュータ読み取り可能媒体の範囲に含まれる。コンピュータ装置は、取り外し可能および／または不可能、揮発性および／または不揮発性メモリ形式で、コンピュータ記憶媒体を含むか、またはアクセスする。ユーザは、入力装置またはキーボード、ポインティング装置（例えばマウス、トラックボール、ペンまたはタッチパッド）等のユーザインタフェース選択装置を介して、コマンドおよび情報をコンピュータ装置に入力できる。他の入力装置（図示せず）を、コンピュータ装置に接続できる。モニタまたは他の種類のディスプレイ装置（図示せず）も、コンピュータ装置に接続される。モニタに加え、コンピュータは、プリンタ、スピーカ等の他の周辺出力装置（図示せず）を多く含み、出力周辺インタフェース（図示せず）を介して接続できる。

コンピュータ２２は、１または２以上のリモートコンピュータを論理結合したネットワーク環境で動作できる。リモートコンピュータは、パーソナルコンピュータ、サーバ（例えばサーバ３２）、ルータ、ネットワークＰＣ、ピア装置または他の共通ネットワークノードになることができ、典型的には上述のコンピュータ２２と比べて多くのまたは全ての構成要素を含む。それらのネットワーク環境は、会社、企業規模のコンピュータネットワーク、インターネット、グローバルコンピュータネットワーク（例えばインターネット）で当たり前となっている。

例示的なコンピュータシステム環境に関連して説明したが、発明の態様は、多数の他の汎用または専用コンピュータシステム環境または構成を用いて使用できる。コンピュータシステム環境は、発明の態様の使用の範囲または機能性に関してどんな制限も与えていない。さらにコンピュータシステム環境は、例示的な作動環境で示されたコンポーネントのいずれか１つまたはそれらの組み合わせに関して、依存または必要条件を有するものとして解釈されるべきでない。発明の実施形態の使用に適した公知のコンピュータシステム、環境、および／または構成は、パーソナルコンピュータ、サーバコンピュータ、携帯型またはラップトップ型装置、マルチプロセッサシステム、マイクロプロセッサを用いるシステム、セットトップボックス、プログラム可能な家庭電化製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、任意の上記システムまたは装置等を含む分散コンピュータ環境を含むが、これらに限定されない。

発明の実施形態は、プログラムモジュール等の、１または２以上のコンピュータまたは他の装置によって実行されるコンピュータ実行命令の一般的な文脈で説明できる。一般的に、プログラムモジュールは、特別なタスクを行い、特別な抽象データ型を実行するルーティン、オブジェクト、コンポーネントおよびデータ構造体を含むが、これらに限定されない。発明の態様も、分散コンピュータ環境で実施され、そこではタスクが通信ネットワークを介してリンクされたリモート処理装置によって行われる。分散コンピュータ環境では、プログラムモジュールは、メモリ記憶装置を含んだローカルリモートコンピュータ記憶媒体とリモートコンピュータ記憶媒体の両方に格納できる。

本明細書に図示した実行順序または説明した実行方法は、他に特定されない限り必須のものでない。つまり、それらの方法の構成要素を、他に限定されない限り任意の順序で行うことができ、それらの方法は、本明細書で開示されたものとほぼ同数の構成要素を含むことが発明者によって考えられる。例えば特別な構成要素を別の構成要素の前に、同時に、または後に実行するのは、発明の範囲内であることが考えられる。

発明の実施形態は、コンピュータ実行命令を用いて実行される。コンピュータ実行命令は、１または２以上のコンピュータ実行コンポーネントまたはモジュールで構成できる。発明の態様は、コンポーネントまたはモジュール等を任意の数および構成で実行できる。発明の態様は例えば、本明細書で説明される特定のコンピュータ実行命令か、または特定のコンポーネントまたはモジュールに限定されない。発明の他の実施形態は、本明細書に説明されるものとほぼ同等の機能性を有するさまざまなコンピュータ実行命令またはコンポーネントを含むことができる。

本発明の構成要素または実施形態を導入する場合、冠詞の「ａ」「ａｎ」「ｔｈｅ」「ｓａｉｄ」は、１または２以上の構成要素があることを意味するものである。「備えた（comprising）」「含んだ（including）」および「有する（having）」の言葉は、内包的なものであり、挙げられた構成要素以外に追加的な構成要素もあり得るという意味である。

上記に照らして、いくつかの発明の目的は実行され、他の有利な成果も達成される。

発明の実施形態の範囲から逸脱することなく、上記の構成と方法において各種変更が行われる可能性があり、上述に含まれ、添付図に示される全ての内容は、図解的に解釈されるものであり、意味を限定するものではない。

本発明の一実施形態を実行する例示的なコンピュータシステムのコンポーネントを示すブロック図である。 本発明の一実施形態を用いた例示的なイベントストリームの発生源を示すブロック・フロー図である。 本発明の一実施形態にかかる多次元集合体の態様を示す例示的な画面情報の図である。 本発明の一実施形態にかかる多次元集合体の態様をさらに示す例示的な画面情報の図である。 本発明の一実施形態にかかる関心があるイベントを選択するユーザインタフェースの態様を示す例示的な画面情報の図である。 本発明の一実施形態にかかるアクティビティ動作を定義するユーザインタフェースの態様を示す例示的な画面情報の図である。 本発明の一実施形態にかかるイベントスキーマからの次元構造体およびマッピングを定義するユーザインタフェースの態様を示す例示的な画面情報の図である。 本発明の一実施形態の態様をさらに実行する例示的なコンピュータシステムのブロック図である。 本発明の一実施形態にかかるイベントストリームからレポートを作成する例示的な動作を示すフロー図である。 本発明の態様を実行するコンピュータ実行命令を含む例示的なコンピュータ読み取り可能媒体を示すブロック図である。

Claims (20)

1. イベントストリームからレポートを作成するコンピュータ化された方法であって、前記イベントストリームは複数のイベントを備え、前記方法は、
   前記イベントストリームの中の１または２以上の関心があるイベントを識別すること、
   前記関心があるイベントに関連するメタデータを検索すること、
   前記検索されたメタデータに基づいて前記関心があるイベントを相関させること、
   前記レポートの次元構造体を定義すること、および、
   前記相関性のあるイベントを前記次元構造体にマッピングして前記レポートを作成すること
   を備えることを特徴とする方法。
2. 前記マッピングを表す情報をユーザに提示することをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記マッピングを表す情報を提示することは、グラフィカルレポートを作成することを備えることを特徴とする請求項２に記載の方法。
4. 前記グラフィカルレポートは、少なくとも棒グラフ、円グラフ、および表のうちの１つを備えることを特徴とする請求項３に記載の方法。
5. 前記関心があるイベントを識別することは、１または２以上のアクティビティを定義するユーザ入力の受信することであって、前記各アクティビティは、前記イベントストリームの中の少なくとも１つのイベントのインスタンスを複数含むことを備えることを特徴とする請求項１に記載の方法。
6. 前記定義された各アクティビティの開始イベントおよび終了イベントを定義することをさらに備えることを特徴とする請求項５に記載の方法。
7. 前記関心があるイベントを識別することは、イベントスキーマをユーザに表示することであって、前記イベントスキーマは、前記イベントストリームの中のイベントおよび関連するメタデータを表示することを備えることを特徴とする請求項１に記載の方法。
8. １または２以上のコンピュータ読み取り可能媒体は、請求項１に記載された方法を行うコンピュータ実行命令を有することを特徴とする請求項１に記載の方法。
9. ディスプレイを有するコンピュータシステムにおいて、前記ディスプレイは、レンダリングされるユーザインタフェースを有し、前記ユーザインタフェースは、
   イベントストリームの中の複数の利用可能なイベントを表示するイベントコンポーネントと、
   前記利用可能なイベントに関連するメタデータを表示するメタデータコンポーネントと、
   前記関連する表示されたメタデータに基づいて前記イベントコンポーネントから１または２以上の関心があるイベントを選択するユーザ入力に応答する選択コンポーネントと、
   前記選択された関心があるイベントを整理する相関キーおよび次元構造体を定義するユーザ入力に応答する構造体コンポーネントと
   を備えたことを特徴とするコンピュータシステム。
10. 前記相関キーに従った前記次元構造体にマッピングされた前記選択された関心があるイベントを有する前記次元構造体を表示するレポートコンポーネントをさらに備えたことを特徴とする請求項９に記載のユーザインタフェース。
11. 前記レポートコンポーネントは、グラフィカルレポートを備えたことを特徴とする請求項１０に記載のユーザインタフェース。
12. 前記グラフィカルレポートは、少なくとも棒グラフ、円グラフ、および表のうちの１つを備えたことを特徴とする請求項１１に記載のユーザインタフェース。
13. 前記相関キーは、１または２以上のアクティビティを特定し、前記各アクティビティは、少なくとも１つの前記関心があるイベントのインスタンスを複数含むことを特徴とする請求項９に記載のユーザインタフェース。
14. 前記選択コンポーネントは、特定された各アクティビティのイベントを開始することおよびイベントを終了することを定義するユーザ入力に応答することを特徴とする、請求項１３に記載のユーザインタフェース。
15. 前記構造体コンポーネントは、１または２以上の前記関心があるイベントを次元として定義するユーザ入力に応答することを特徴とする請求項９に記載のユーザインタフェース。
16. 前記構造体コンポーネントは、１または２以上の前記関心があるイベントを計測として定義するユーザ入力に応答することを特徴とする請求項９に記載のユーザインタフェース。
17. イベントストリームからレポートを作成するコンピュータ実行命令を有する少なくとも１つのコンピュータ読み取り可能媒体であって、
    前記イベントストリームの中の利用可能なイベントおよび関連するメタデータを記述するイベントスキーマと、
    前記イベントストリームの中の１または２以上の関心があるイベントを識別するためにユーザ入力を受信しおよび応答し、ならびに前記イベントスキーマで記述された前記メタデータに基づいて前記関心があるイベントを相関させる集合体定義ツールと、
    前記相関性のある関心があるイベントに従った１または２以上のアクティビティの定義を作成し、および前記アクティビティ定義のデータウェアハウスを生成するビジネスアクティビティモニタと
    を備えたことを特徴とする前記コンピュータ読み取り可能媒体。
18. 前記相関性のある関心があるイベントと前記データウェアハウスの中の前記アクティビティ定義との間のマッピングを定義する傍受構成をさらに備えたことを特徴とする請求項１７に記載のコンピュータ読み取り可能媒体。
19. 前記データウェアハウスから選択されたアクティビティ定義を表示するグラフィカル・ユーザ・インタフェースを作成するユーザ入力に応答する閲覧コンポーネントをさらに備えたことを特徴とする請求項１８に記載のコンピュータ読み取り可能媒体。
20. 前記集合体定義ツールは、前記相関性のある関心があるイベントの次元構造体を特定するユーザ入力に応答することを特徴とする請求項１７に記載のコンピュータ読み取り可能媒体。

Images