JP2021502658A - 実行可能論理を用いて構造化データアイテムを処理するためのキーベースのロギング - Google Patents

Abstract

各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するためのデータ処理システムであって、その処理が、実行可能論理を表す仕様にアクセスすることと、キーの所定の値に対するログ記録を生成することであって、キーの所定の値と関連付けられる１つ又は複数のデータアイテムの各々に対し、そのデータアイテムと関連付けられたキーの所定の値に対して維持される仕様の所定の状態を特定すること、そのデータアイテムを処理することであって、そのデータアイテムにおいて、仕様の特定された所定の状態で指定された実行可能論理を実行することを含む、処理すること、及び、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成することを含む、生成することとを含む、生成することとによって行われる、データ処理システム。

Description

本説明は、データアイテムのストリームにおける１つ又は複数のキー入力データアイテム（例えば、ネットワーク接続アプリケーションからネットワーク接続を介してもたらされるデータアイテム）に現在適用されている実行可能論理の実行からキー特有のログを生成するためのコンピュータ実装方法、データ処理システム及び機械可読ハードウェア記憶装置に関する。

ログは、オペレーティングシステム若しくは他のソフトウェア起動の際に起こるイベント又は通信ソフトウェアの異なるユーザ間のメッセージを記録する。

一般態様１では、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するためのデータ処理システムによって実施される方法であって、仕様が実行可能論理を表し、仕様がキーと関連付けられ、仕様の状態がキーのそれぞれの値に対して維持される、方法であり、実行可能論理を表す仕様にアクセスすることであって、キーの特定の値に対する仕様の状態が、その状態で実行可能な実行可能論理の１つ又は複数の部分を指定する、アクセスすることと、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、１つ又は複数のデータアイテムの各々が、キーの所定の値と関連付けられる、受信することと、キーの所定の値に対するログ記録を生成することであって、ログ記録が、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を指定する、生成することであり、キーの所定の値と関連付けられる１つ又は複数のデータアイテムの各々に対し、そのデータアイテムと関連付けられたキーの所定の値に対して維持される仕様の所定の状態を特定すること、データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、仕様の特定された所定の状態で指定された実行可能論理の１つ又は複数の部分を実行することを含む、処理すること、及び、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成することを含む、生成することとを含む、方法について説明する。

態様１による態様２では、方法は、ログ記録をキー別に分類することであって、第１のキーと関連付けられた第１のログ記録が、第１のグループに分類され、第２のキーと関連付けられた第２のログ記録が、第２のグループに分類される、分類することをさらに含む。

態様１又は２による態様３では、ログ記録は、メモリにおいて分類される。

態様１〜３のいずれか１つによる態様４では、各ログ記録は、データアイテムの処理の１つ又は複数の属性を示す１つ又は複数のフィールドを含み、少なくとも１つのログ記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。

態様１〜４のいずれか１つによる態様５では、特定のキーと関連付けられたログ記録のサブセットは、キーフィールドを含まない。

態様１〜５のいずれか１つによる態様６では、特定のキーと関連付けられたログ記録のうち、たった１つのログ記録しかキーフィールドを含まない。

態様１〜６のいずれか１つによる態様７では、方法は、事前に定義された時間間隔の終了時に、特定のキーと関連付けられた特定のグループのログ記録をファイルに書き込むことをさらに含む。

態様１〜７のいずれか１つによる態様８では、方法は、ファイルを再フォーマットすることと、再フォーマット済みのファイルをインデックス付き圧縮フラットファイル（ＩＣＦＦ）に書き込むことと、キー別にインデックスにおいてＩＣＦＦのインデックスを生成することとをさらに含む。

態様１〜８のいずれか１つによる態様９では、仕様は、多数のノードを有するチャートを含み、各ノードは、実行可能論理の１つ又は複数の部分を表し、チャートは、実行可能なものであり、チャートの実行により、実行可能論理の複数の部分が実行され、方法は、ログ記録に基づいて、１つ又は複数のデータアイテムを処理する際にチャートの１つ又は複数のノードを通じて走査をトレースすることをさらに含む。

態様１〜９のいずれか１つによる態様１０では、方法は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを特定するために、ログ記録を構文解析することをさらに含む。

態様１〜１０のいずれか１つによる態様１１では、ログ記録は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを指定する。

態様１〜１１のいずれか１つによる態様１２では、方法は、ユーザ起動によるノードのうちの１つの選択を受信することと、選択を受信することに応答して、選択されたノードによって表される実行可能論理の１つ又は複数の部分をユーザが構成するための構成手段を提供する構成エリアをグラフィカルユーザインタフェース上に表示させることであって、構成手段が、監査を有効化及び無効化するための手段を含む、表示することと、構成手段を介してユーザ起動による監査の有効化を受信し、選択されたノードと関連付けられたログ記録を生成させることとを含む。

態様１〜１２のいずれか１つによる態様１３では、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成することは、生成されたログ記録において、実行可能論理のそれらの１つ又は複数の部分の実行の結果を指定すること、実行可能論理のそれらの１つ又は複数の部分が実行され次第読み取られるか又は設定される変数を指定すること、或いは、実行される実行可能論理のそれらの１つ又は複数の部分を特定することを含む。

態様１〜１３のいずれか１つによる態様１４では、方法は、実行可能論理の１つ又は複数の部分を実行することに応答して、コンピューティングシステムによって実行予定のアクションを開始することをさらに含む。

態様１〜１４のいずれか１つによる態様１５では、アクションは、実行可能論理の１つ又は複数の部分の実行の実行特性に基づいて、実行可能論理の１つ又は複数の部分の実行のための追加の演算資源を要求することを含む。

態様１〜１５のいずれか１つによる態様１６では、方法は、各状態に対して実行可能論理のどの部分が現在実行されているかを示す状態データをデータリポジトリ又はインメモリデータグリッドに格納することによって、状態を維持することをさらに含む。

態様１〜１６のいずれか１つによる態様１７では、方法は、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムの処理の完了に応答して、キーのその値に対する現在の状態を指定するために、状態データを更新することをさらに含む。

態様１〜１７のいずれか１つによる態様１８では、方法は、チャートのどのノードを走査するか及びデータアイテム別に走査ノードを何回走査するかを示すメトリクスを動的に決定することをさらに含む。

態様１〜１８のいずれか１つによる態様１９では、方法は、チャートを通じて取った経路を文書化するログ記録のストリームを生成することと、生成されたログ記録を変換することと、変換済みのログ記録をリレーショナルデータベース又はインデックス付き圧縮フラットファイルに格納することであって、指定された粒度でログ記録を一括することを含む、格納することとをさらに含む。

態様１〜１９のいずれか１つによる態様２０では、方法は、ユーザインタフェースを介して、決定されたメトリクスを動的に出力することであって、出力されたメトリクスが、決定されたメトリクスの変更に応答して更新される、出力することをさらに含む。

態様１〜２０のいずれか１つによる態様２１では、方法は、ストリームの複数のデータアイテムのうちの第１のデータアイテムのユーザ選択を受信することと、複数のデータアイテムのうちの選択された第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分の表示を表示させることとをさらに含む。

態様１〜２１のいずれか１つによる態様２２では、方法は、現在処理されているストリームの複数のデータアイテムのうちの選択された第１のデータアイテムを既定の参照データアイテムと比較することと、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムが既定の参照データアイテムと一致するかどうかについての表示を出力することとをさらに含む。

態様１〜２２のいずれか１つによる態様２３では、方法は、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分を既定の参照実行可能論理と比較することと、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分が既定の参照実行可能論理と一致するかどうかについての表示を出力することとをさらに含む。

態様１〜２３のいずれか１つによる態様２４では、ログ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第１のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第２のフィールドとを有する構造化データ記録である。

態様１〜２４のいずれか１つによる態様２５では、ログ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する構造化データ記録である。

態様１〜２５のいずれか１つによる態様２６では、仕様はチャートであり、１つ又は複数のログ記録は、キーの特定の値と関連付けられた１つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。

態様１〜２６のいずれか１つによる態様２７では、方法は、１つ又は複数のデータアイテムの処理に基づいて１つ又は複数の出力記録を生成することであって、１つ又は複数の出力記録の各々が、ログ記録に含まれないデータを含む、生成することをさらに含む。

一般態様２８では、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するためのデータ処理システムであって、仕様が実行可能論理を表し、仕様がキーと関連付けられ、仕様の状態がキーのそれぞれの値に対して維持される、データ処理システムであり、１つ又は複数の処理デバイスと、命令を格納する１つ又は複数の機械可読ハードウェア記憶装置とを含む、データ処理システムであり、命令が、実行可能論理を表す仕様にアクセスすることであって、キーの特定の値に対する仕様の状態が、その状態で実行可能な実行可能論理の１つ又は複数の部分を指定する、アクセスすることと、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、１つ又は複数のデータアイテムの各々が、キーの所定の値と関連付けられる、受信することと、キーの所定の値に対するログ記録を生成することであって、ログ記録が、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を指定する、生成することであり、キーの所定の値と関連付けられる１つ又は複数のデータアイテムの各々に対し、そのデータアイテムと関連付けられたキーの所定の値に対して維持される仕様の所定の状態を特定すること、データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、仕様の特定された所定の状態で指定された実行可能論理の１つ又は複数の部分を実行することを含む、処理すること、及び、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成することを含む、生成することとを含む動作を実行するために１つ又は複数の処理デバイスによって実行可能である、データ処理システムについて説明する。

態様２８による態様２９では、動作は、ログ記録をキー別に分類することであって、第１のキーと関連付けられた第１のログ記録が、第１のグループに分類され、第２のキーと関連付けられた第２のログ記録が、第２のグループに分類される、分類することをさらに含む。

態様２８又は２９による態様３０では、ログ記録は、メモリにおいて分類される。

態様２８〜３０のいずれか１つによる態様３１では、各ログ記録は、データアイテムの処理の１つ又は複数の属性を示す１つ又は複数のフィールドを含み、少なくとも１つのログ記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。

態様２８〜３１のいずれか１つによる態様３２では、特定のキーと関連付けられたログ記録のサブセットは、キーフィールドを含まない。

態様２８〜３２のいずれか１つによる態様３３では、特定のキーと関連付けられたログ記録のうち、たった１つのログ記録しかキーフィールドを含まない。

態様２８〜３３のいずれか１つによる態様３４では、動作は、事前に定義された時間間隔の終了時に、特定のキーと関連付けられた特定のグループのログ記録をファイルに書き込むことをさらに含む。

態様２８〜３４のいずれか１つによる態様３５では、動作は、ファイルを再フォーマットすることと、再フォーマット済みのファイルをインデックス付き圧縮フラットファイル（ＩＣＦＦ）に書き込むことと、キー別にインデックスにおいてＩＣＦＦのインデックスを生成することとをさらに含む。

態様２８〜３５のいずれか１つによる態様３６では、仕様は、多数のノードを有するチャートを含み、各ノードは、実行可能論理の１つ又は複数の部分を表し、チャートは、実行可能なものであり、チャートの実行により、実行可能論理の複数の部分が実行され、動作は、ログ記録に基づいて、１つ又は複数のデータアイテムを処理する際にチャートの１つ又は複数のノードを通じて走査をトレースすることをさらに含む。

態様２８〜３６のいずれか１つによる態様３７では、動作は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを特定するために、ログ記録を構文解析することをさらに含む。

態様２８〜３７のいずれか１つによる態様３８では、ログ記録は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを指定する。

態様２８〜３８のいずれか１つによる態様３９では、動作は、ユーザ起動によるノードのうちの１つの選択を受信することと、選択を受信することに応答して、選択されたノードによって表される実行可能論理の１つ又は複数の部分をユーザが構成するための構成手段を提供する構成エリアをグラフィカルユーザインタフェース上に表示させることであって、構成手段が、監査を有効化及び無効化するための手段を含む、表示することと、構成手段を介してユーザ起動による監査の有効化を受信し、選択されたノードと関連付けられたログ記録を生成させることとをさらに含む。

態様２８〜３９のいずれか１つによる態様４０では、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成することは、生成されたログ記録において、実行可能論理のそれらの１つ又は複数の部分の実行の結果を指定すること、実行可能論理のそれらの１つ又は複数の部分が実行され次第読み取られるか又は設定される変数を指定すること、或いは、実行される実行可能論理のそれらの１つ又は複数の部分を特定することを含む。

態様２８〜４０のいずれか１つによる態様４１では、動作は、実行可能論理の１つ又は複数の部分を実行することに応答して、コンピューティングシステムによって実行予定のアクションを開始することをさらに含む。

態様２８〜４１のいずれか１つによる態様４２では、アクションは、実行可能論理の１つ又は複数の部分の実行の実行特性に基づいて、実行可能論理の１つ又は複数の部分の実行のための追加の演算資源を要求することを含む。

態様２８〜４２のいずれか１つによる態様４３では、動作は、各状態に対して実行可能論理のどの部分が現在実行されているかを示す状態データをデータリポジトリ又はインメモリデータグリッドに格納することによって、状態を維持することをさらに含む。

態様２８〜４３のいずれか１つによる態様４４では、動作は、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムの処理の完了に応答して、キーのその値に対する現在の状態を指定するために、状態データを更新することをさらに含む。

態様２８〜４４のいずれか１つによる態様４５では、動作は、チャートのどのノードを走査するか及びデータアイテム別に走査ノードを何回走査するかを示すメトリクスを動的に決定することをさらに含む。

態様２８〜４５のいずれか１つによる態様４６では、動作は、チャートを通じて取った経路を文書化するログ記録のストリームを生成することと、生成されたログ記録を変換することと、変換済みのログ記録をリレーショナルデータベース又はインデックス付き圧縮フラットファイルに格納することであって、指定された粒度でログ記録を一括することを含む、格納することとをさらに含む。

態様２８〜４６のいずれか１つによる態様４７では、動作は、ユーザインタフェースを介して、決定されたメトリクスを動的に出力することであって、出力されたメトリクスが、決定されたメトリクスの変更に応答して更新される、出力することをさらに含む。

態様２８〜４７のいずれか１つによる態様４８では、動作は、ストリームの複数のデータアイテムのうちの第１のデータアイテムのユーザ選択を受信することと、複数のデータアイテムのうちの選択された第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分の表示を表示させることとをさらに含む。

態様２８〜４８のいずれか１つによる態様４９では、動作は、現在処理されているストリームの複数のデータアイテムのうちの選択された第１のデータアイテムを既定の参照データアイテムと比較することと、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムが既定の参照データアイテムと一致するかどうかについての表示を出力することとをさらに含む。

態様２８〜４９のいずれか１つによる態様５０では、動作は、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分を既定の参照実行可能論理と比較することと、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分が既定の参照実行可能論理と一致するかどうかについての表示を出力することとをさらに含む。

態様２８〜５０のいずれか１つによる態様５１では、ログ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第１のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第２のフィールドとを有する構造化データ記録である。

態様２８〜５１のいずれか１つによる態様５２では、ログ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する構造化データ記録である。

態様２８〜５２のいずれか１つによる態様５３では、仕様はチャートであり、１つ又は複数のログ記録は、キーの特定の値と関連付けられた１つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。

態様２８〜５３のいずれか１つによる態様５４では、動作は、１つ又は複数のデータアイテムの処理に基づいて１つ又は複数の出力記録を生成することであって、１つ又は複数の出力記録の各々が、ログ記録に含まれないデータを含む、生成することをさらに含む。

一般態様５５では、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するための１つ又は複数の機械可読ハードウェア記憶装置であって、仕様が実行可能論理を表し、仕様がキーと関連付けられ、仕様の状態がキーのそれぞれの値に対して維持される、１つ又は複数の機械可読ハードウェア記憶装置であり、命令を格納する１つ又は複数の機械可読ハードウェア記憶装置であり、命令が、実行可能論理を表す仕様にアクセスすることであって、キーの特定の値に対する仕様の状態が、その状態で実行可能な実行可能論理の１つ又は複数の部分を指定する、アクセスすることと、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、１つ又は複数のデータアイテムの各々が、キーの所定の値と関連付けられる、受信することと、キーの所定の値に対するログ記録を生成することであって、ログ記録が、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を指定する、生成することであり、キーの所定の値と関連付けられる１つ又は複数のデータアイテムの各々に対し、そのデータアイテムと関連付けられたキーの所定の値に対して維持される仕様の所定の状態を特定すること、データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、仕様の特定された所定の状態で指定された実行可能論理の１つ又は複数の部分を実行することを含む、処理すること、及び、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成することを含む、生成することとを含む動作を実行するために１つ又は複数の処理デバイスによって実行可能である、１つ又は複数の機械可読ハードウェア記憶装置について説明する。

態様５５による態様５６では、動作は、ログ記録をキー別に分類することであって、第１のキーと関連付けられた第１のログ記録が、第１のグループに分類され、第２のキーと関連付けられた第２のログ記録が、第２のグループに分類される、分類することをさらに含む。

態様５５又は５６による態様５７では、ログ記録は、メモリにおいて分類される。

態様５５〜５７のいずれか１つによる態様５８では、各ログ記録は、データアイテムの処理の１つ又は複数の属性を示す１つ又は複数のフィールドを含み、少なくとも１つのログ記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。

態様５５〜５８のいずれか１つによる態様５９では、特定のキーと関連付けられたログ記録のサブセットは、キーフィールドを含まない。

態様５５〜５９のいずれか１つによる態様６０では、特定のキーと関連付けられたログ記録のうち、たった１つのログ記録しかキーフィールドを含まない。

態様５５〜６０のいずれか１つによる態様６１では、動作は、事前に定義された時間間隔の終了時に、特定のキーと関連付けられた特定のグループのログ記録をファイルに書き込むことをさらに含む。

態様５５〜６１のいずれか１つによる態様６２では、動作は、ファイルを再フォーマットすることと、再フォーマット済みのファイルをインデックス付き圧縮フラットファイル（ＩＣＦＦ）に書き込むことと、キー別にインデックスにおいてＩＣＦＦのインデックスを生成することとをさらに含む。

態様５５〜６２のいずれか１つによる態様６３では、仕様は、多数のノードを有するチャートを含み、各ノードは、実行可能論理の１つ又は複数の部分を表し、チャートは、実行可能なものであり、チャートの実行により、実行可能論理の複数の部分が実行され、動作は、ログ記録に基づいて、１つ又は複数のデータアイテムを処理する際にチャートの１つ又は複数のノードを通じて走査をトレースすることをさらに含む。

態様５５〜６３のいずれか１つによる態様６４では、動作は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを特定するために、ログ記録を構文解析することをさらに含む。

態様５５〜６４のいずれか１つによる態様６５では、ログ記録は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを指定する。

態様５５〜６５のいずれか１つによる態様６６では、動作は、ユーザ起動によるノードのうちの１つの選択を受信することと、選択を受信することに応答して、選択されたノードによって表される実行可能論理の１つ又は複数の部分をユーザが構成するための構成手段を提供する構成エリアをグラフィカルユーザインタフェース上に表示させることであって、構成手段が、監査を有効化及び無効化するための手段を含む、表示することと、構成手段を介してユーザ起動による監査の有効化を受信し、選択されたノードと関連付けられたログ記録を生成させることとをさらに含む。

態様５５〜６６のいずれか１つによる態様６７では、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成することは、生成されたログ記録において、実行可能論理のそれらの１つ又は複数の部分の実行の結果を指定すること、実行可能論理のそれらの１つ又は複数の部分が実行され次第読み取られるか又は設定される変数を指定すること、或いは、実行される実行可能論理のそれらの１つ又は複数の部分を特定することを含む。

態様５５〜６７のいずれか１つによる態様６８では、動作は、実行可能論理の１つ又は複数の部分を実行することに応答して、コンピューティングシステムによって実行予定のアクションを開始することをさらに含む。

態様５５〜６８のいずれか１つによる態様６９では、アクションは、実行可能論理の１つ又は複数の部分の実行の実行特性に基づいて、実行可能論理の１つ又は複数の部分の実行のための追加の演算資源を要求することを含む。

態様５５〜６９のいずれか１つによる態様７０では、動作は、各状態に対して実行可能論理のどの部分が現在実行されているかを示す状態データをデータリポジトリ又はインメモリデータグリッドに格納することによって、状態を維持することをさらに含む。

態様５５〜７０のいずれか１つによる態様７１では、動作は、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムの処理の完了に応答して、キーのその値に対する現在の状態を指定するために、状態データを更新することをさらに含む。

態様５５〜７１のいずれか１つによる態様７２では、動作は、チャートのどのノードを走査するか及びデータアイテム別に走査ノードを何回走査するかを示すメトリクスを動的に決定することをさらに含む。

態様５５〜７２のいずれか１つによる態様７３では、動作は、チャートを通じて取った経路を文書化するログ記録のストリームを生成することと、生成されたログ記録を変換することと、変換済みのログ記録をリレーショナルデータベース又はインデックス付き圧縮フラットファイルに格納することであって、指定された粒度でログ記録を一括することを含む、格納することとをさらに含む。

態様５５〜７３のいずれか１つによる態様７４では、動作は、ユーザインタフェースを介して、決定されたメトリクスを動的に出力することであって、出力されたメトリクスが、決定されたメトリクスの変更に応答して更新される、出力することをさらに含む。

態様５５〜７４のいずれか１つによる態様７５では、動作は、ストリームの複数のデータアイテムのうちの第１のデータアイテムのユーザ選択を受信することと、複数のデータアイテムのうちの選択された第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分の表示を表示させることとをさらに含む。

態様５５〜７５のいずれか１つによる態様７６では、動作は、現在処理されているストリームの複数のデータアイテムのうちの選択された第１のデータアイテムを既定の参照データアイテムと比較することと、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、現在処理されているストリームの複数のデータアイテムのうちの第１のデータアイテムが既定の参照データアイテムと一致するかどうかについての表示を出力することとをさらに含む。

態様５５〜７６のいずれか１つによる態様７７では、動作は、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分を既定の参照実行可能論理と比較することと、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、複数のデータアイテムのうちの第１のデータアイテムにおいて現在実行されている実行可能論理の１つ又は複数の部分が既定の参照実行可能論理と一致するかどうかについての表示を出力することとをさらに含む。

態様５５〜７７のいずれか１つによる態様７８では、ログ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第１のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第２のフィールドとを有する構造化データ記録である。

態様５５〜７８のいずれか１つによる態様７９では、ログ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する構造化データ記録である。

態様５５〜７９のいずれか１つによる態様８０では、仕様はチャートであり、１つ又は複数のログ記録は、キーの特定の値と関連付けられた１つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。

態様５５〜８０のいずれか１つによる態様８１では、動作は、１つ又は複数のデータアイテムの処理に基づいて１つ又は複数の出力記録を生成することであって、１つ又は複数の出力記録の各々が、ログ記録に含まれないデータを含む、生成することをさらに含む。

上記の態様は、以下の利点のうちの１つ又は複数を含み得る。

本明細書で説明されるロギングシステムは、システム資源（メモリ及び処理能力など）への影響を最小限に抑えながらログ記録を処理することができる。それに加えて、本明細書で説明されるシステムは、レイテンシを低減しながらこれらのログ記録を処理する。実行可能論理の実行のメトリクスは、ユーザがこれらのメトリクスをリアルタイムで追跡できるように、動的に決定及び出力される。その上、ユーザは、余分なデータ量の生成を低減しながら、対象の部分にロギングの焦点を置くためにどの実行可能論理ログ記録を生成するかを制御することができる。これにより、ユーザは、根本的なデータ処理システムを理解する、追跡する及び正しく動作する上で手助けが得られる。

本発明の他の特徴及び利点は、以下の説明から及び特許請求の範囲から明らかになるであろう。

データベース管理システムの概略図である。 フローチャートの図である。 フローチャートの図である。 フローチャートの図である。 フローチャートの図である。 フローチャートの図である。 フローチャートの図である。 フローチャートの図である。 フローチャートインスタンスの図である。 実行可能論理を用いて構造化データアイテムを処理するためのキーベースのロギング用のシステムの図である。 フローチャートの図である。 実行可能論理を用いて構造化データアイテムを処理するためのキーベースのロギングの例示的なプロセスの図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。 ＩＣＦＦ記録及び関連データブロックの生成及びインデックス生成を示す図である。

図１を参照すると、ロギング用のシステム１０は、データソース１２を含み、データソース１２は、記憶装置又はオンラインデータストリームへの接続などのデータの１つ又は複数のソースを含み得、１つ又は複数のソースの各々は、様々な格納フォーマット（例えば、データベーステーブル、スプレッドシートファイル、フラットテキストファイル又はメインフレームによって使用されるネイティブフォーマット）のいずれでもデータを格納することができる。実行環境１４（例えば、データ処理システム）は、実行モジュール１６及びユーザインタフェースモジュール２２を含む。実行環境１４は、適切なオペレーティングシステム（ＵＮＩＸ(登録商標)オペレーティングシステムなど）の制御下で１つ又は複数のコンピュータをホストとし得る。例えば、実行環境１４は、複数ノード並列コンピューティング環境を含み得、複数ノード並列コンピューティング環境は、複数の中央処理装置（ＣＰＵ）を使用したコンピュータシステムの構成を含み、ローカル接続（例えば、ＳＭＰコンピュータなどのマルチプロセッサシステム）又はローカル分散されるか（例えば、クラスタ若しくはＭＰＰとして結合された複数のプロセッサ）、リモート接続又はリモート分散されるか（例えば、ＬＡＮ若しくはＷＡＮネットワークを介して結合された複数のプロセッサ）、或いは、それらの任意の組合せのものである。

実行モジュール１６は、コンピュータプログラムによってデータ記録（本明細書では、「データアイテム」とも呼ばれる）が処理される対象となる一意的なキー（例えば、識別子（ＩＤ））の各々に対する、コンピュータプログラム（例えば、その全内容が参照により本明細書に組み込まれる「Ｅｘｅｃｕｔｉｎｇ Ｃｏｍｐｕｔａｔｉｏｎｓ Ｅｘｐｒｅｓｓｅｄ ａｓ Ｇｒａｐｈｓ」と称する米国特許第米国特許５，９６６，０７２号明細書で説明されるようなデータフローグラフなどのチャート）の状態及びコンピュータプログラムを通じてデータが取った経路についての詳細を提供するロギング（例えば、チャートロギング）を実施する。いくつかの例では、実行モジュール１６は、その全内容が参照により本明細書に組み込まれる米国特許出願公開第２００９／０３２７１９６号明細書で説明されるようなグラフベースの演算において、データロギングを実施する。この出願では、「データフローグラフ」又は「チャート」という用語は、「コンピュータプログラム」の例として又は「コンピュータプログラム」に対する他の言葉として使用される。いくつかの例では、「データフローグラフ」及び「チャート」という用語は、本明細書では、便宜上、互いに交換可能に且つ区別なく使用される。いくつかの例では、一意的なキーは、チャートによって記録が処理される対象となる各顧客用の顧客ＩＤを表す。ユーザインタフェースモジュール２２は、ロギング情報（例えば、チャートのどの部分を走査するかを示すメトリクス及び記録のグループ別にチャートの特定の部分を何回走査するかを示す集計メトリクス）を表示する。この仕様全体を通じて説明されるメトリクスは、動的に（すなわち、実行可能論理の実行の間に）決定することができる。この例では、チャート（例えば、データフローグラフ）は、データ記憶装置２６に格納することができる。データソース１２を提供する記憶装置は、実行環境１４にローカル接続されても（例えば、実行環境１４を起動しているコンピュータに接続された記憶媒体（例えば、ハードディスク１８）上に格納する）、実行環境１４にリモート接続されてもよい（例えば、ローカルエリア又は広域データネットワーク上で実行環境１４を起動しているコンピュータと連通するリモートシステム（例えば、メインフレーム２０）をホストとする）。

実行環境１４は、１つ又は複数のユーザインタフェースを表示するためにユーザインタフェースモジュール２２によって使用されるデータを格納するデータ記憶装置２６と連通する。また、データ記憶装置２６は、データ記憶装置２６に格納されたユーザインタフェース及びチャート（ロギング機能を有する）を開発するための開発環境２８（例えば、任意選択であり得る）にもアクセスすることができ、ユーザインタフェース及びチャートは、実行モジュール１６によってアクセスされ（チャートを実行する際）、ユーザインタフェースを表示するためにユーザインタフェースモジュール２２によって使用される。

いくつかの例では、チャート又はデータフローグラフは、１つ又は複数のデータソースからのデータを処理するデータフローグラフ実行環境内で実行されるコンピュータプログラムである。データソースからのデータは、コンピュータプログラムに従って操作及び処理され、１つ又は複数のデータシンクにエクスポートされる。データソース及びシンクは、例えば、ファイル、データベース、データストリーム又はキューを含み得る。データフローグラフは、有向グラフとして表され、有向グラフは、データ処理コンポーネントを表すノード（各々が少なくとも１つのデータ入力からのデータを処理するため及び少なくとも１つのデータ出力にデータを提供するためのプログラムコード（例えば、実行可能論理）を含む）と、データソース及び／又はシンクにアクセスするためのデータセットオブジェクトを表すノードとを含む。ノードは、コンポーネント間のデータのフローを表す有向リンクによって接続され、有向リンクは、データソースを始点とし、データシンクを終点とする。上流のコンポーネントのデータ出力ポートは、下流のコンポーネントのデータ入力ポートに接続される。データフローグラフは、データセットオブジェクトによって表される異なるデータソース及び異なるデータシンクに対して再利用することができる。データフローグラフを実施するために使用されるデータ構造及びプログラムコードは、例えば、異なるソース又はシンクを容易に代用できるようにするために、例えば、パラメータ化することによって、複数の異なる構成をサポートすることができる。その上、いくつかの構成では、データフローグラフにおけるデータのフローは、コンポーネントのうちの１つ又は一連のコンポーネントをバイパスできるように、パラメータを使用することによって変更することができる。一般に、パラメータは、データフローグラフのコンポーネントの特性を表し、その特性は、値で構成することができ、且つ、その値を変更することができる。例えば、そのような特性は、データフローグラフの使用の合間に変更することができ、その変更の結果、データフローグラフは、異なる形で動作を実行することができる。

データフローグラフの構築は、いくつかの事例では、本質的には、高度に技術的なものであり得る。特有のビジネス目的を達成するために記載しているが、グラフの根本的な構造及び構築は、技術的考慮点に基づいて決定される。例えば、グラフのコンポーネントは、再利用性を最大化するか又は並列処理をサポートするように選択することができる。他方では、どのように及びどこでグラフを使用するかは、ビジネス上の決定であることが多い。そのようなパラメータ化されたデータフローグラフと関連付けられたパラメータのいくつかは、ユーザがその実装形態の背後にある技術的複雑性を理解する必要なしに、ビジネスユーザがデータフローグラフをカスタマイズできるようにするために使用することができる。パラメータ化されたデータフローグラフは、カスタマイゼーションを簡略化し、再利用を容易にする。

言い換えれば、図１に示されるコンピュータシステム１０は、データ記憶装置２６に結合された任意選択の開発環境２８であって、チャート又はデータフローグラフと関連付けられたコンピュータプログラムを構築するように構成された開発環境２８であり、チャート又はデータフローグラフが、データ処理コンポーネントのチャート又はグラフを通じて１つ又は複数の入力データセットから１つ又は複数の出力データセットに流れるデータにおいて実行される演算を実施し、チャート又はデータフローグラフが、データ記憶装置２６内のデータ構造によって指定され、チャート又はデータフローグラフが、多数のノードを有し、多数のノードが、データ構造によって指定され、１つ又は複数のリンクによって接続されたデータ処理コンポーネントを表し、リンクが、データ構造によって指定され、データ処理コンポーネント間のデータフローを表す、開発環境２８と、データ記憶装置２６に結合された実行環境１４であって、１つ又は複数のコンピュータをホストとする実行環境１４であり、実行モジュール１６を含む実行環境１４であり、実行モジュール１６が、チャート又はデータフローグラフを指定する格納されたデータ構造を読み取り、実行モジュール１６によってチャート又はデータフローグラフに割り当てられたデータ処理コンポーネントの演算を実行するために演算資源の割り当て及び構成を行うように構成され、実行モジュール１６が、本明細書で説明される方法又はプロセスのいずれか１つが実行されるようにデータ処理コンポーネントの割り当てられた演算の実行のスケジューリング及び制御を行うように構成される、実行環境１４とを含み得る。

以下でさらに詳細に説明されるように、図２Ａ〜２Ｄは、フローチャートを通じる進行を示し、フローチャートの様々な状態で様々なノードが実行されることを示す。図２Ｅ〜２Ｇは、様々な状態で生成される様々な監査記録を示す。

図２Ａを参照すると、略図２９ａは、データ処理コンポーネントを表すノード３２ａ〜３２ｇを有するそのフローチャート３２を含む仕様３０を示す。一般に、仕様は、実行可能論理を表し、様々な状態を指定するものであり、仕様の状態は、以前のデータアイテムにおける実行可能論理の実行から達した状態に基づいて、その状態で実行可能な実行可能論理の１つ又は複数の部分を指定する。一般に、実行可能論理は、ソースコード及び他のコンピュータ命令を含む。この例では、１つ又は複数のデータ処理コンポーネントは、実行可能論理の特定の分類又は部分を指す。一般に、チャートは、データ記録を処理するためのテンプレートを含む。このテンプレートは、グラフィック論理ユニットを含み、グラフィック論理ユニットは、入力データ記録に対処し、出力データ記録（例えば、仕様に含まれる論理に基づいて生成されたデータ記録）を生成するためのものである。チャートは、仕様の例である。一般に、グラフィック論理ユニットは、グラフ上で少なくとも部分的に生成された（例えば、チャートを構築するためのテンプレート（図示せず）からウィンドウへの様々なノードのドラッグ・アンド・ドロップによって）論理を含む。例では、ノードは、論理（図示せず）を含み、論理は、入力データ記録をどのように処理するか、実行可能論理によって使用される変数に対する値をどのように設定するか、どの出力データ記録を生成するか（例えば、論理によって指定される条件が満たされ次第）などを指定する。例では、ノードは、ノードの論理において使用されるパラメータの値及び／又は変数の値をユーザが入力することによって、プログラム可能である。

ノードの論理は実行可能論理にコンパイルされるため、及び、各ノードはその実行可能論理の１つ又は複数の部分に対応するため、チャート自体は実行可能なものである。例えば、システムは、ノードの論理を実行可能論理にコンパイルすることによって、仕様（及び／又は仕様のチャート）を変換する。チャート自体が実行可能なものであるため、チャート自体は、データ記録の処理や、停止、開始及び中止が可能である。また、システムは、例えば、ノード３２ａ〜３２ｇのうちのどのノードが現在実行されているかを追跡することによって、フローチャート３２の状態を維持する。フローチャート３２の状態は、フローチャート３２によって表される実行可能論理の状態に相当する。例えば、フローチャート３２の各ノードは、実行可能論理の特定の状態（実行可能論理の１つ又は複数の部分はその状態で実行可能である）を表す。以下でさらに詳細に説明されるように、キーの多くの値に対してフローチャート３２が実行されている際、システムは、例えば、各インスタンスに対して状態を維持することによって、キーの各値に対してフローチャート３２の状態を維持する。一般に、仕様のインスタンスは、キーの一意的な値に対する仕様の特有の実現（例えば、仕様において表される実行可能論理の実行及びキーの一意的な値の各々に対する実行可能論理の状態の維持による）を含む。この例では、フローチャート３２は、状態遷移図を含み、状態遷移図では、各受信データ記録は、ノード間の遷移を推進し、データ記録は、以前のデータ記録の処理から達した状態に基づいて評価される。フローチャート３２のノード間のリンクは、論理の時間的な流れを表す。

また、仕様３０は、キー３２ｈも含み、キー３２ｈは、キー３２ｈを含むか又はキー３２ｈと関連付けられたデータ記録をフローチャート３２が処理することを特定する。この例では、カスタム識別子（ＩＤ）がキーとして使用される。キー３２ｈは、データ記録のフィールドのうちの１つ（例えば、サービス加入者＿ＩＤフィールド、顧客＿ＩＤフィールド、セッション＿ＩＤフィールドなど）に対応し得る。この例では、顧客＿ＩＤフィールドがキーフィールドである。特定のデータ記録に対し、システムは、そのデータ記録に対するキーフィールドの値を特定することによって、そのデータ記録に対するキーの値を決定する。

この例では、フローチャート３２は、指定されたタイプの（例えば、フローチャート３２が構成される際に指定された）ものであるデータ記録を購読する。この例では、フローチャート３２は、キー３２ｈを含むデータ記録を購読する。この例では、フローチャート３２とデータ記録は、キーを共有する。一般に、フローチャートは、フローチャートのキーを含むそれらのデータ記録を処理するために論理を含めることによってデータ記録のタイプを購読する。データ記録処理が始まると、システムは、例えば、キーの新しい値の各々に対する実行可能論理の状態（フローチャートにおいて表される）を維持することによって、そのフローチャートに対するキーの新しい値の各々に対する新しいフローチャートインスタンスを開始する。一般に、フローチャートインスタンスは、キーの一意的な値に対するフローチャートの特有の実現（例えば、仕様において表される実行可能論理の実行及びキーの一意的な値の各々に対する実行可能論理の状態の維持による）を含む。システムは、特定のキー値に対するデータ記録に対処するために、フローチャートインスタンス（延いては根本的な実行可能論理）を構成することによって、データ記録処理を実行する。例では、フローチャートは、顧客ショートメッセージサービス（ＳＭＳ）データ記録を購読する。特定の顧客ＩＤに対するフローチャートインスタンスは、その顧客のデータ記録を管理する。受信データ記録において遭遇する顧客ＩＤと同数のフローチャートインスタンスが存在し得る。

図２Ｂを参照すると、略図２９ｂは、フローチャート３２の実行の開始を示す。この例では、ノード３２ａは、実行可能論理の開始を表すものであり、現在実行されている（例えば、ノード３２ａの周りの太線によって示されるように）。この例では、フローチャート３２は、ノード３２ａが実行されている状態である。図２Ｃを参照すると、略図２９ｃは、ノード３２ａの完了に続くフローチャート３２の状態を示す。この例では、フローチャート３２の状態は、ノード３２ｂに遷移し、ノード３２ｂは、実行可能論理の１つ又は複数の他の部分を表す。ノード３２ｂは、待機ノード（以下では、待機ノード３２ｂと呼ばれる）を含む。待機ノード３２ｂは、入力データ記録が１つ又は複数の条件を満たすまで実行可能論理の一部分（待機ノード３２ｂに対応する）が待つという待機状態を表す。例では、待機状態は、フローチャート３２の別の状態（例えば、システムが待機ノードを実行し（待機状態を実施するため）、次いで、１つ又は複数の他のノードを実行する状態）の一部であり得る。待機ノード３２ｂによって表される実行可能論理の部分の完了に続いて、システムは、待機状態を終了し、ノード３２ｃを実行する。ノード３２ｃは、決定を実施するための実行可能論理を表す。この例では、ノード３２ｃは、決定ノードを含む。以下では、ノード３２ｃは、決定ノード３２ｃと呼ばれる。一般に、決定ノードは、決定の実行用の論理（例えば、ブール値に評価する論理）を含むノードを含む。

図２Ｄを参照すると、略図２９ｄは、ノード３２ｃによって表される決定の結果に基づくフローチャート３２の状態を示す。具体的には、ノード３２ｃによって表される決定の結果に基づいて、フローチャート３２の状態は、別の待機ノードであるノード３２ｄに遷移する。（変形形態では、フローチャート３２の状態は、ノード３２ｇに遷移することがあり得る（それにより、状態は、ノード３２ａに戻る））。待機ノード３２ｄによって表される実行可能論理の部分の完了に続いて、フローチャート３２の状態は、送信ノードを含むノード３２ｅに遷移する。一般に、送信ノードは、別のシステムへのデータ送信を引き起こすための実行可能論理を表すノードを含む。ノード３２ｅによって表される実行可能論理の部分の実行の完了に続いて、フローチャート３２の状態は、終了ノードを含むノード３２ｆに遷移する。一般に、終了ノードは、実行可能論理の実行が完了したことを表す。

この例では、フローチャート３２は、２つの状態を含み、第１の状態は、ノード３２ｂ、３２ｃ、３２ｇによって表され、第２の状態は、ノード３２ｄ、３２ｅ、３２ｆによって表される。この第１の状態では、システムは、特定のデータ記録を待ち（ノード３２ｂによって表されるように）、次いで、ノード３２ｃを実行し、これを受けて、第２の状態（その開始は、ノード３２ｄによって表される）への遷移（仕様３０及び／又はチャート３２の遷移）が起こるか、又は、ノード３２ｇの実行が起こる。第２の状態になった時点で、システムは、再び、特定のデータ記録を待ち（ノード３２ｄによって表されるように）、次いで、ノード３２ｅ及びノード３２ｆを実行する。待機ノード以外のノードを含めることにより、フローチャート３２は、データ記録の時間的な処理の論理グラフを含む。

図２Ｅを参照すると、略図２９ｅは、フローチャート３２の開始状態を示し、開始状態では、開始ノード３２ａが実行され次第、監査記録が生成される。具体的には、開始ノード３２ａは、この例で示されるように、例えば、フローチャート３２が、開始ノード３２ａが実行されている状態である際に、監査記録３２ｉを生成するように構成されたデータ処理コンポーネントを表す。一般に、監査記録（又は「ログ記録」とも呼ばれる）は、データアイテム（例えば、データの構造化アイテム）を含み、データアイテムは、データ記録又はイベントを処理する際に走査されるノード（及び／又は実行されるデータ処理コンポーネント）並びにデータ記録又はイベントの処理の１つ又は複数の属性を指定する。いくつかの例では、ログ記録は、構造化データ記録であり、構造化データ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第１のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第２のフィールドとを有する。この例では、特定のキーに対するデータ記録が処理された時点で、システムは、監査記録（又は１つ若しくは複数の監査記録）を生成し、キーの特定の値に対する仕様の状態を表すデータを第１のフィールドに格納し、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを第２のフィールドに格納する。さらなる他の例では、ログ記録は、構造化データ記録であり、構造化データ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する。この例では、監査記録が生成された時点で、システムは、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを監査記録のフィールドに投入する。さらなる他の例では、仕様はチャートであり、１つ又は複数のログ記録は、キーの特定の値と関連付けられた１つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。この例では、システムは、キーの特定の値と関連付けられた１つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定するログ記録を生成する。さらなる他の例では、システムは、１つ又は複数のデータアイテムの処理に基づいて１つ又は複数の出力記録を生成する。この例では、１つ又は複数の出力記録の各々は、ログ記録に含まれないデータを含む。

以下でさらに詳細に説明されるように、様々なタイプの監査記録は、様々なフィールドを有するように事前に定義され、各フィールドタイプは、データ記録又はイベントの処理の１つ又は複数の属性を指定する。一般に、イベントは、その特定の発生又は不在を表すデータ記録（例えば、事前に定義されたフォーマットのもの）を含む。この例では、ノード３２ａは、編集可能なものであり、編集は、例えば、ノード３２ａをクリックすることによって行うことができ、それにより、ノード（延いてはノードによって表されるデータ処理コンポーネント）を構成する際に使用することができる構成画面が表示される。構成の一部は、監査の有効化（又は「ロギング」とも呼ばれる）及びそのノードが走査され次第生成される予定の１つ又は複数のタイプの監査記録の指定を含み得る。別の例では、本明細書で説明されるシステムは、ユーザインタフェース用のデータを生成し、ユーザインタフェースは、様々なタイプの監査記録の視覚表現を表示し、様々なタイプの監査記録の有効化／無効化の制御を提供する。次いで、この例では、システムは、特定タイプのノード若しくはデータ処理コンポーネントに対応するか又は特定タイプのノード若しくはデータ処理コンポーネントと関連付けられたタイプの監査記録を生成する（例えば、そのタイプの監査記録に対するロギングが使用可能になった際）。例えば、監査記録３２ｉは、チャートの開始を指定するデータのロギングのためのチャート開始監査記録である。従って、チャート開始監査記録を使用可能にすることをユーザが指定した場合は、本明細書で説明されるシステムは、開始ノードがチャートを開始し、且つ、チャート開始監査記録がチャート開始のロギングを行うという事実に基づいて、チャート開始監査記録と開始ノード（例えば、ノード３２ａ）との間の対応を特定し、チャート開始監査記録を生成する。この例では、監査記録３２ｉは、キーフィールド（チャートのインスタンスが作成されるか又はチャートが実行される対象となるキーを指定するための）、チャート３２を一意的に識別する識別子を指定するためのチャート＿ＩＤ及びチャートを開始したことを指定するための「開始」の値を含む。

図２Ｆを参照すると、略図２９ｆは、フローチャート３２の第２の状態を示し、第２の状態では、監査記録３２ｊが生成される。具体的には、決定ノード３２ｃによって表されるデータ処理コンポーネントは、この例で示されるように、例えば、フローチャート３２が、決定ノード３２ｃが実行されている状態である際に、監査記録３２ｊを生成するように構成される。（この例では、この状態で待機ノード３２ｂも実行されている。しかし、待機ノード３２ｂは、監査記録を生成するようには構成されていない）。この例では、監査記録３２ｊのうちの１つは、例えば、肯定リンク３２を走査するか又は否定リンク３２ｍを走査するかを指定することによって、決定ノード３２ｃの結果を指定する。監査記録３２ｊの他のものは、例えば、決定ノード３２ｃによって表されるデータ処理コンポーネントが実行され次第読み取られるか又は設定される変数を指定することができる。この例では、監査記録３２ｊは、キーフィールドを含む必要はないが、その理由は、監査記録は、指定されたパルス（例えば、時間又は事前に定義された時間間隔）で処理システム（例えば、監査記録を処理する内部又は外部のコンピューティングシステム）に送信され、その結果、監査記録は、グループで、ブロックで又はファイルの一部として送信されるためである。

例えば、システムは、キー別に監査記録を分類し、第１のキーと関連付けられた第１の監査記録は、第１のグループに分類され、第２のキーと関連付けられた第２の監査記録は、第２のグループに分類される。この例では、監査記録は、システム（例えば、システム１０）のメモリにおいて分類される。システムは、空間効率のためにメモリにおいて監査記録を分類し、その結果、システムは、例えば、各監査記録にキーを含めることによって、順次関連する監査記録にわたってデータを複製する必要はない。各監査記録は、データアイテムの処理の１つ又は複数の属性を示す１つ又は複数のフィールドを含む。少なくとも１つの監査記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。監査記録はキー別に分類されるため、特定のキーと関連付けられた監査記録のサブセットは、キーフィールドを含まない。いくつかの例では、特定のキーに対するグループに含まれる監査記録のうち、たった１つの監査記録しかキーフィールドを含まない。この例では、システムは、事前に定義された時間間隔（例えば、パルス）の終了時に、特定のキーと関連付けられた特定のグループの監査記録をファイルに書き込む。

例えば、システムは、第１の監査記録又はチャート開始監査記録のコンテンツを構文解析することによって、グループ（ブロック又はファイルとして表され得る）内の監査記録に対するキーを識別する。すべての監査記録がキーフィールド（及びチャート＿ＩＤフィールドなどの他のフィールド（監査記録３２ｉと同じパルスに含まれる他の監査記録によってチャート開始監査記録内を検索することもできる））を含む必要があるわけではないため、本明細書で説明されるシステムは、各監査記録がイベントのキー入力ロギングを可能にするためにキーフィールドを含む必要がある場合のシステム資源への影響と比べて、システム資源（メモリ及び処理能力など）への影響を最小限に抑えながら監査記録を処理することができる。それに加えて、本明細書で説明されるシステムは、各監査記録がキーフィールドを含む必要がないことを理由に監査記録のサイズが低減されるため、各監査記録がキーフィールドを有する監査記録の処理のレイテンシと比べて、レイテンシを低減しながらこれらの監査記録を処理する。それに加えて、システムは、特定のキーに割り当てられたパーティション内（メモリ内）に監査記録を格納するように構成され、それにより、各監査記録がキーフィールドを含む必要性がさらに低減される。新しいパルスの開始時は、本明細書で説明されるシステムは、そのパルスに対するその第１の監査記録にキーフィールドを含むように構成される。

図２Ｇを参照すると、略図２９ｇは、フローチャート３２の第３の状態を示し、第３の状態では、監査記録３２ｋが生成される。具体的には、送信ノード３２ｅは、監査記録３２ｋを生成するようにも構成される。この例では、監査記録３２ｋの少なくとも１つは、送信ノード３２ｅによって表されるデータ処理コンポーネントによって実施されたアクションを指定する。また、監査記録３２ｊと同様に、監査記録３２ｋは、監査記録３２ｉを含むものと同じパルスの一部として送信されるため、監査記録３２ｋもキーフィールドを含む必要がない。監査記録３２ｋの他のものは、アクションが送信された時刻、変数読み取りの値、変数設定の値などを指定することができる。

この例では、システムは、１つ又は複数のデータアイテムを処理する際にチャート３２の１つ又は複数のノードを通じて走査をトレースするために、監査記録のコンテンツを構文解析する。それに加えて、システムは、チャート３２のどのノードを走査し且つチャート３２のどのノードを走査しないか、及び、それらのノードをなぜ走査しないか（例えば、それらのノードに対してどのリンク又は経路を走査しなかったか）を特定するために、監査記録を構文解析する。

図３を参照すると、略図３７は、フローチャートインスタンス３３、３４（例えば、システムによってフローチャート３２（図２Ａ）から生成されたもの）及びデータ記録３６ａ、３６ｂのデータアイテムを示す。すなわち、フローチャート３２の新しいコピー又はインスタンスは、データ記録３６ａ、３６ｂにおいて検出された新しいキーの各々に対して作成される。

フローチャートインスタンス３３、３４の各々は、「顧客＿ｉｄ」キーと関連付けられる。フローチャートインスタンス３３は、この例ではキーフィールドであるその「顧客＿ｉｄ」フィールドに「ＶＢＮ３４１９」の値を含むデータ記録を処理する。フローチャートインスタンス３４は、その「顧客＿ｉｄ」フィールドに「ＣＮＤ８９５４」の値を含むデータ記録を処理する。この例では、システムは、各フローチャートインスタンスに対して実行可能論理を再実行することはしない。むしろ、システムは、実行可能論理を実行し、次いで、キーのそれぞれの値に対する状態を維持することによってフローチャートインスタンスを実施する。それに従って、「データ記録を処理するフローチャートインスタンス」の例は、システムが実行可能論理（フローチャートによって表されるもの）を実行し、キーの各値に対する状態を維持し、キーの特定の値と関連付けられたデータ記録を処理する（キーのその特定の値に対する状態マシンの状態に基づいて）ことである。

この例では、フローチャートインスタンス３３は、図２Ａのノード３２ａ〜３２ｇのそれぞれに相当するノード３３ａ〜３３ｇと、リンク３３ｌ、３３ｍとを含む。フローチャートインスタンス３４は、図２Ａのノード３２ａ〜３２ｇのそれぞれに相当するノード３４ａ〜３４ｇと、リンク３４ｌ、３４ｍとを含む。

フローチャートインスタンス自体は実行可能なものである。キーの特定の値と関連付けられた入力データ記録をシステムが受信した後、キーのその特定の値に対するフローチャートインスタンスは、入力データ記録を処理し、その処理は、例えば、システムが、データ記録において、フローチャートインスタンスに対応する実行可能論理の１つ又は複数の部分（或いはフローチャートインスタンスの１つ又は複数のノード）を実行することによって行われる。フローチャートインスタンスは、入力データ記録が終了ノード又は待機ノードに達するまで、入力データ記録の処理を続ける。この例では、フローチャートインスタンスは、例えば、終了ノード又は待機ノードに対応する実行可能論理の部分に達するまでシステムが入力データ記録の処理を続けることによって、入力データ記録の処理を続ける。入力データ記録が待機ノードに達した場合は、フローチャートインスタンスは、ある時間量が経過するまで又は適切な新しい入力データ記録が到着するまで休止する。一般に、適切なデータ記録は、１つ又は複数の指定条件又は基準（例えば、ノードの論理に含まれるもの）を満たすデータ記録を含む。入力データ記録が終了ノードに達した場合は、フローチャートインスタンスの実行は完了する。

フローチャートインスタンスは、それ自体のライフサイクルを有する。データ記録が到着すると、フローチャートインスタンスの現在の状態又はステータスが変化する（すなわち、データ記録が決定をトリガする、フローチャートインスタンスの開始に戻る、又は、顧客にメッセージが送信される）。顧客用のフローチャートインスタンスは、データ記録が終了ノードに達した時点で終了する。

この例では、システムは、キーフィールドの「ＶＢＮ３４１９」の値（例えば、顧客＿ｉｄ＝ＶＢＮ３４１９）に対してフローチャートインスタンス３３を開始する。フローチャートインスタンス３３は、ＶＢＮ３４１９の顧客＿ｉｄを含むデータ記録３６ａ、３６ｂのサブセットを処理する。この例では、フローチャートインスタンス３３は、顧客＿ｉｄキーフィールドに「ＶＢＮ３４１９」の値を有するデータ記録３６ａを処理する。フローチャートインスタンス３３のノード３３ａ、３３ｂ、３３ｃ、３３ｄは、データ記録３６ａを処理する。この例では、ノード３３ａによって表される処理コンポーネントが実行され次第、システムは、監査記録３３ｉを生成し、監査記録３３ｉは、ＶＢＮ３４１９のキーに対してチャート３２（チャート＿ＩＤ：３４５４が割り当てられている）が開始されることを指定する。ノード３３ｃに対応するデータ処理コンポーネントが実行され次第、システムは、監査記録３３ｊを生成し、監査記録３３ｊの少なくとも１つは、インスタンス３３のリンク３３ｌを走査することを指定する。フローチャートインスタンス３３の現在の状態は、ノード３３ｅの破線によって表されるように、アクションを送信するか又は実行する状態である。この例では、ノード３３ｅによって表されるデータ処理コンポーネントは、監査記録３３ｋを生成し、監査記録３３ｋの少なくとも１つは、そのアクションを指定する。アクションは、送信されるＳＭＳメッセージ（例えば、オファ又はプロモーションを含むもの）を送信することを含み得る。本明細書で説明される他のそのような「アクション」は、処理済みのデータ記録をさらに処理するために別のコンピュータプログラムの実行を開始すること、メモリへの処理済みのデータ記録の格納を開始すること、ネットワーク接続を介する別のコンピュータシステムへの処理済みのデータ記録の送信を開始すること、又は、１つ若しくは複数のフローチャート３２、３３、３４のノードによって表される１つ若しくは複数のデータ処理コンポーネントに対する追加の演算資源を要求することのうちの１つ又は複数であり得る。例えば、フローチャートインスタンス３３の結果は、フローチャートインスタンス３３の１つ又は複数の実行特性に基づいて、フローチャートインスタンス３３のノード（ノード３２ｂ、３２ｃ、３２ｄ、３２ｅ、３２ｆ、３３ｂ、３３ｃ、３３ｄ、３３ｅのうちの１つなど）によって表されるデータ処理コンポーネントのうちの１つに対する追加の演算資源を要求するアクションの実行であり得る。そのような実行特性の例は、待機ノード３２ｂ、３２ｄ、３３ａ又は３３ｄのうちの１つ又は複数の待機時間であり得る。追加の演算資源に対する要求が認められると、要求された追加の演算資源の配分の受信へと至る。本明細書で使用される「演算資源」という用語は、実行環境１４によってアクセス可能なメモリ（主要メモリなど）の部分へのアクセス、実行環境１４によってアクセス可能なデータ記憶装置（データソース１２若しくはデータ記憶装置２６など）へのアクセス、及び、実行環境１４の必要な処理能力量へのアクセス（実行環境１４によってアクセス可能なＣＰＵ又は仮想コアへのアクセスなど）のうちの１つ又は複数を含む。

この例では、システムは、特定のキー値（すなわち、ＶＢＮ３４１９）に対して実行されるインスタンス３３に対する状態を維持する。従って、システムは、そのキー値と関連付けられたイベント又はデータ記録を処理する際、その特定のキー値に対してインスタンス３３のどのノードを走査するかをロギングすることができる。それに加えて、パルスで監査記録を分類することにより、監査記録３３ｉ、３３ｊ、３３ｋが同じパルスに含まれる際は、監査記録３３ｊ、３３ｋは、キーフィールドを含む必要がなく、依然として、監査記録３３ｉにおいて指定されたキーに対する監査記録として特定することができる。

システムは、「ＣＮＤ８９５４」のキーの値（例えば、顧客＿ｉｄ＝ＣＮＤ８９５４）に対してフローチャートインスタンス３４を開始する。フローチャートインスタンス３４は、ＣＮＤ８９５４の顧客＿ｉｄを含むデータ記録３６ａ、３６ｂのサブセットを処理する。この例では、フローチャートインスタンス３４は、待機ノード３４ｂ、３４ｄを含む。各データ記録は、１つのフローチャートインスタンスあたり１つのみの待機ノードの条件を満たすことができる。それに従って、フローチャートインスタンス３４は、例えば、決定ノード３４ｃの出力が「肯定」である際、ノード３４ａ、３４ｂを通じてノード３４ｄまで顧客＿ｉｄ＝ＣＮＤ８９５４を有するデータ記録３６ｂを処理し、次いで、ノード３４ｅに進む前に、同じキーを有する第２のデータ記録を待つ。ノード３４ａでデータ記録３６ｂが処理され次第、本明細書で説明されるシステムは、監査記録３４ｉを生成し、監査記録３４ｉは、ＣＮＤ８９５４のキーに対してチャート３２（チャート＿ＩＤ：３４５４によって識別される）が開始されることを指定する。しかし、この例では、ノード３４ｇの周りの点線によって表されるように、決定ノード３４ｃの出力は、「否定」である。従って、ノード３４ｃによって表されるデータ処理コンポーネントは、監査記録３４ｊを生成し、監査記録３４ｊのうちの１つは、決定ノード３４ｃによって表される決定の結果に基づいてリンク３４ｍを走査することを指定する。この例では、送信ノード３４ｅは走査しない。従って、送信ノード３４ｅによって表されるデータ処理コンポーネントは、監査記録を生成しない。前述の例では、データ記録を処理するノードへの言及は、データ記録を処理するノードを表すデータ処理コンポーネントを指す。それに加えて、これらの例では、チャート自体は実行可能なものである。すなわち、その実行により、チャートのノードに対応する実行可能論理が実行されるか、又は、実行論理の部分を封入するデータ処理コンポーネントが実行される。

図３の変形形態では、システムは、単一のキー値に対して複数のフローチャートインスタンスを生成する。例えば、同じ顧客に対して、異なる開始日及び終了日を有する多くのフローチャートインスタンスが存在することも、同じ顧客に対して、異なる目的（異なる産業プロセス又は異なる販売キャンペーンなど）の多くのフローチャートインスタンスが存在することもあり得る。

この例では、システムは、状態データ（例えば、各インスタンスに対してどのノードが現在実行されているかを示すデータ）をデータリポジトリ又はインメモリデータグリッドに格納することによって、インスタンスに対する状態を維持する。一般に、状態データは、状態を示すデータを含む。この例では、インスタンスは、キーの値と関連付けられる。データリポジトリ又はインメモリデータグリッドは、キーの値を格納する。システムは、キーの各値に対する状態データを格納することによって、インスタンスに対する状態を維持する。キーの特定の値に対するデータ記録の処理が完了次第、システムは、次のノード（図２Ａのフローチャート３２の）がキーのその値に対する現在の状態を表すことを指定するために、データリポジトリにおいて、状態データを更新する。次いで、別のデータ記録が到着すると、システムは、データリポジトリにおいて、キーのその値に対する現在の状態を検索し、キーのその値に対する実行可能論理の現在の状態を表すノードに対応する実行可能論理の部分を実行する。

図４を参照すると、環境１００は、監査ロギング用のアーキテクチャを示す。環境１００は、データ記録（及び／又は他の構造化データアイテム）を処理するように構成されたイベントエンジン１０２を有するシステム１０１（例えば、データ処理システム）を含む。この例では、イベントエンジン１０２は、ルールセットログ１０４、チャート実行モジュール１０６及びチャート１０８を含む。また、環境１００は、データベース１１０、１１２も含む。この例では、ルールセットログ１０４は、その全内容が参照により本明細書に組み込まれる米国特許第７，８７７，３５０号明細書において説明されているような、ビジネスルール環境（ＢＲＥ）におけるルールの実行生成されたログ（例えば、どのルールが実行されるか、それらのルールがいつ実行されるか、パラメータの値及び／又は実行中に設定された値などを示すロギングデータ又はルールケーストレース情報（本明細書では、トレーシング情報とも呼ばれる））を含む。この例では、イベントエンジン１０２は、任意選択によりその情報を監査記録に含めるため（例えば、ルールセットによって取り扱われ且つチャート決定ブロックに含まれないビジネス論理を説明するため）、ビジネスルール環境からルールケーストレース情報を収集する。例では、ＢＲＥは、グラフのコンポーネント上のポートにそのログを書き込み、次いで、そのポートからファイルにそのログを書き込むことによって、ロギングデータストリームを実装する。この例では、イベントエンジン１０２は、ＢＲＥのトレーシング情報を書き出す関数呼び出しを、イベントエンジン１０２が現在のイベントに対する監査記録（及び他の監査情報）を収集しているイベントエンジンの内部データ構造にトレーシング情報を格納する関数呼び出しと置き換えることによって、そのロギングデータストリームを傍受する。いくつかの例では、イベントエンジン１０２は、ＢＲＥが使用しているロギング関数の代替の実装形態（例えば、ｗｒｉｔｅ＿ｔｏ＿ｌｏｇ）を提供することによって、ロギングデータストリームを傍受する。他の例では、ＢＲＥは、異なる関数を使用するオプションをサポートする。

この例では、チャート実行モジュール１０６は、１つ又は複数のデータフローグラフ（例えば、チャート１０８のうちの１つ）を実行するように構成される。この例では、チャート１０８のうちの１つは、イベントエンジングラフであり、イベントエンジングラフは、クラスタメトリクスを生成し、それらをデータベース１１０のファイルに直接書き込む。一般に、イベントエンジングラフは、イベントエンジン１０２の性能をモニタするためのグラフである。一般に、クラスタメトリクスは、システム及び／又はイベントエンジン１０２の集計レベルでの詳細（性能詳細など）を指し、例えば、データフローグラフのどの部分を走査するかを示すメトリクスや、記録のグループ別にデータフローグラフの特定の部分を何回走査するかを示す集計メトリクスである。いくつかの例では、このファイルは、すべてのパルス（例えば、データプッシュ）において追加され（例えば、他の以前に格納されたファイルに追加される又は更新される）、新しいファイルが毎日開かれる。

この例では、イベントエンジンビジネス論理から別のデータ経路が生じる（例えば、チャートを実行するチャート実行モジュール１０６の実行に基づいて）。チャートが実行されると、チャート実行モジュール１０６は、チャートを通じて取った経路（退出した待機ブロック、走査したフロー及び送信したアクションなど）を文書化する監査記録１１１のストリームを生成する。この例では、監査記録は、監査ファイル（すなわち、データベース１１２）に格納されたロギング済みの活動又はデータベース１１６に格納されたインデックス付き圧縮フラットファイル（ＩＣＦＦ）に格納されたロギング済みの活動を含む。一般に、監査ファイルは、様々な監査記録を格納するためのファイルを含む。この例では、監査記録１１１は、各パルスの終了時にファイルに書き込まれる。この例では、データベース１１２は、１つのパルスにつき１つの新しいファイルを受信する。

環境１００は、グラフを含む監査ファイルプロセッサモジュール１１４を含み、監査ファイルプロセッサモジュール１１４に含まれるグラフは、未加工情報（すなわち、データベース１１２に格納された監査ファイル）を処理し、未加工情報をＩＣＦＦ用のフォーマットに再フォーマットする。この例では、データベース１１２は、再フォーマットのために監査ファイルプロセッサモジュール１１４に監査ファイルを送信する。これを受けて、監査ファイルプロセッサモジュール１１４は、再フォーマット済みのファイルをデータベース１１６に送信し、データベース１１６は、再フォーマット済みのファイルをＩＣＦＦ記録１１６ａに書き込む（１つ又は複数のキーフィールド（例えば、対象者ＩＤ）別にインデックス生成され（インデックス１１６において）、時間別に（例えば、１時間毎に又は日毎に）まとめられる）。この例では、ＩＣＦＦ記録１１６ａは、データブロック１１６ｃを参照する（例えば、ポインタ又は別の参照データ構造を介して）。この例では、未加工情報の一部分は、ＩＣＦＦ記録１１６ａ用に再フォーマットされる（次いで、インデックス１１６ｂにおいてインデックス生成される）が、未加工情報の他の部分は、データブロック１１６ｃに格納され、データブロック１１６ｃは、ＩＣＦＦ記録１１６ａによって参照され、従って、ＩＣＦＦ記録１１６ａを介して識別可能及びアクセス可能である。

いくつかの例では、指定された粒度（例えば、１つのチャートに対して１人のサービス加入者の１つのイベント）で監査記録を一括し、ＩＣＦＦ記録に格納されるキーフィールド（例えば、イベントタイプ、サービス加入者ＩＤ、タイムスタンプ、チャートインスタンスＩＤなどに対するフィールド）を演算し、次いで、以下の通り、残りの監査記録を集合体にまとめることによって、監査記録及び／又は監査ファイルは、ＩＣＦＦ用に再フォーマットされる。

例では、イベントエンジン１０２は、空間効率に対して最適化された（例えば、クエリ効率に対して最適化されるというよりむしろ）監査記録を生成する。この例では、監査記録は、空間効率に対して最適化される（例えば、すべての監査記録がタイムスタンプ、サービス加入者＿ＩＤなどを含むとは限らないということによって）。これらの監査記録をＩＣＦＦに入れるため、本明細書で説明されるシステムは、より完全な記録（例えば、すべての監査記録にタイムスタンプ及び対象者ＩＤを含むもの）を使用する必要があり、その結果、本明細書で説明されるシステムは、個々の記録（例えば、監査記録のコンテンツに基づくもの）を効率的に検索することができる。

いくつかの例では、データベース１１６の実装の目標はイベントのシーケンスに対するクエリを可能にすることであるため、データベース１１６は、ＩＣＦＦというよりむしろ、リレーショナルデータベースを含む。その実施のため、システムは、監査記録のストリームを１つ又は複数の記録（例えば、ＩＣＦＦ記録）に変換する。各記録は、１つ又は複数のインデックス生成可能／検索可能なキーフィールド並びに監査イベントの残りの部分を表すデータ集合体を含む。

いくつかの例では、記録の粒度のレベルは、１つのチャートに対して１人のサービス加入者（例えば、ユーザ）の１つのイベントである。従って、本明細書で説明されるシステムは、１つのチャートに対して１人のサービス加入者の１つのイベントに対応する監査記録のシーケンスを抽出する（例えば、データベース１１２の監査ファイルから）。この例、イベントは順番に起こる。それに加えて、各イベントに対する監査記録は、データベース１１２に（例えば、データベース１１２のファイルに）順番に格納される。抽出された監査記録を使用することにより、システムは、複数のキーフィールド（例えば、イベントタイプフィールド、サービス加入者ＩＤフィールド、タイムスタンプフィールド、チャートインスタンスＩＤフィールドなどを含む）を有する記録を生成する。いくつかの例では、シーケンスにおける第１の監査記録は、これらの複数のキーフィールドに対する値を含む。システムは、新しい記録を生成する際にこれらの含まれる値を使用する。それに加えて、システムは、そのシーケンスの残りの監査記録に相当するデータブロックを構築する。システムは、生成された新しい記録の一部として又は生成された新しい記録と関連付けて、データの集合体として（例えば、バイナリラージオブジェクト（ＢＬＯＢ）型として）、そのデータブロックをデータベース１１６に格納する（例えば、生成された新しい記録の参照データ集合体又はｂｌｏｂ型を有することによって）。

生成された記録及び／又はデータ集合体を使用することにより、システムは、様々な情報（例えば、「６月８日にサービス加入者１２３４５がイベント７を受けてからどうなったか？」など）に対して、ＩＣＦＦ（又はデータベース１１６）へのクエリを行い、次いで、イベントエンジン内部で行われた決定のシーケンス及びそのイベントの関連ルールセットを表示することができる。別の例では、システムは、次のクエリ、すなわち、「６月８日にサービス加入者１２３４５がメッセージを送信してからどうなったか？」によって、ＩＣＦＦ（又はデータベース１１６）へのクエリを行う。この例では、このクエリに答えるため、生成された新しい記録は、メッセージアクションがトリガされた（又はトリガされなかった）ことを特定するために、別のキーフィールドを含む。従って、サポートすべきクエリの範囲に基づいて、システムは、どのキーフィールドを記録に含めるかを選択する。

この例では、データベース１１６は、未加工メトリクスをＩＣＦＦに格納する。この例では、環境１００は、メトリクスにアクセスするためのインタフェースを備えたメトリクスデータベース１２０も含む。従って、環境１００は、未加工メトリクスを集計してそれらをメトリクスデータベース１２０に書き込むために、バッチグラフを起動する（例えば、１０分毎に）バッチグラフモジュール１１８を含む。また、環境１００は、例えば、ユーザインタフェース１２４に表示するためのメトリクス（システム１００において主流の１つ又は複数の状態）を演算するために、「必要に応じて」起動されるバッチグラフモジュール１２２も含む。この例では、バッチグラフモジュール１２２は、メトリクスデータベース１２０からの及び／又はデータベース１１６からのメトリクスにアクセスし、ユーザインタフェース１２４に表示するためにそれらのアクセスしたメトリクスを処理する。この例では、バッチグラフモジュール１１８によって生成又は実行されたグラフは、永続状態を保持せず、メトリック状態は、メトリクスデータベース１２０において永続される。従って、マッチグラフモジュール１２０は、ユーザインタフェース１２２に表示するためのメトリクスに対して、メトリクスデータベース１２０へのクエリを行う。例では、様々なタイプのユーザインタフェースが表示されており、例えば、メトリクスの動的表示、メトリクスに関するレポート及び調査インタフェースを含み、その各々について以下で説明する。

メトリクスの動的表示では、コンソールがメトリクス（例えば、集計カウント）を表示し、その表示では、それらのメトリクスが準リアルタイムで更新される。システムは、このデータ及びメトリクスに対して、メトリクスデータベース１２０へのクエリを行う。この例では、コンソールは、ウェブユーザインタフェース（ＵＩ）であり、サーバからデータをプルする（例えば、タイマーで又は指定時刻に）ことのみ行うポーリングインタフェースを含む。従って、バッチグラフモジュール１１８によって生成されたグラフは、データをＵＩにプッシュすることができない。代わりに、ＵＩ（例えば、ウェブページ）は、更新されたカウント表示するために、サーバへのクエリを断続的に行う。更新されたカウントは、メトリクスデータベース１２０に格納される。この例では、ＵＩ（ウェブページ）とメトリクスデータベース１２０との間のインタフェースを取るサーバ側論理が存在し、例えば、ブラウザとデータベースとの間に位置するＪａｖａアプリケーションサーバを含む。

別の例では、ユーザインタフェース１２４は、メトリクスデータベース１２０からクエリされたメトリクスに関するレポートを表示する。この例では、ユーザは、レポート及びダッシュボードのメトリクスを見ることができる。メトリクスは、何人の人が各キャンペーンに参入しているか、何人の人が各ブランチ（例えば、チャートの）を走査したか、何人の人がオファを得たか、何人の人がオファを承諾したかなどを指定する。ユーザインタフェースは、このレポートのさらなる詳細まで「掘り下げる」ための制御を含む。掘り下げるため（例えば、「トリガイベントを捉えたが、オファを得ることができなかったこれらの１０人の対象者はどうなったか？」というクエリに答えるため）、システムは、データベース１１６のＩＣＦＦの記録にアクセスする。これらのレポートを実施するため、システムは、サービス側モジュール（この例では、バッチグラフモジュール１２２である）を実装し、このモジュールは、掘り下げが要求される際に、メトリクスデータベース１２２及びデータベース１１６にアクセスすることができる。

さらなる別の例では、ユーザインタフェース１２４は、調査インタフェースを含み、調査インタフェースでは、ユーザは、「６月８日にサービス加入者１２３４５がイベント７を受けてからどうなったか？」など、質問をすることができる。これらの質問に答えるため、システムは、ユーザインタフェース１２４とデータベース１１６のＩＣＦＦとの間のサーバ側モジュール（例えば、Ｊａｖａ、グラフなど）を使用して、ＩＣＦＦ（例えば、データベース１１６の）へのクエリを行う。

イベントエンジン１０２は、データベース１１６のＩＣＦＦに格納するために、複数の異なるタイプの監査記録を作成する。以下の表１は、それらの対応するフィールドを有する異なるタイプの監査記録を指定する。以下の監査記録タイプのいくつかは、ロギングのレベルに応じて任意選択である。この例では、ＩＣＦＦは、上記で説明されるように、例えば、ＩＣＦＦ記録のキーフィールドを生成する際に使用するため、以下の表１に示されるフィールドに相当するフィールドのリストを格納する。以下の表１のイタリック体のフィールドに対する値は、イベントエンジン１０２によって生成されるものではないが、本明細書で説明されるシステムによって、データがＩＣＦＦに書き込まれる際に監査ストリームを遡ることによって推測される。これは、イベントエンジン１０２がかなり少量のデータを生成する必要があることを意味する。以下の表１では、「？」の列は、監査記録が任意選択であるかどうかを示す。「＋」の記号は、監査記録がイベントエンジン１０７によって生成されることを意味する。文字は、監査記録が任意選択により生成され、関連制御点のセットによって制御されることを意味し、アスタリスクは、その記録タイプがデフォルトで使用可能であることを示す。

例では、データベース１１２は、各対象者に対して（例えば、キー別に）監査記録を分類する（例えば、継続的に又は断続的に）。すなわち、監査記録は、対象者又はキー別に自動的に分類される。その結果、イベントエンジン１０２は、監査ファイルの各監査記録においてタイムスタンプ、対象者＿ｉｄ又はインスタンス＿ｉｄを複製する（例えば、１パルス毎に）必要はない。むしろ、データベース１１２は、グループ内のこれらのフィールドの以前に生じた値に基づいて、これらのフィールドから値を得ることができる。この例では、パルス間で状態を保存する必要はない。これは、例えば、ブロック開始監査記録は何パルスも前のものであり得るため、ブロック退出監査記録はブロック＿名を有する必要があることを意味する。データベース１１２では、監査記録は、前述の表１に示される関連フィールドを備えている。

例では、システムは、チャートに対する対象者（例えば、ユーザ又はサービス加入者）のイベントの発生を検出する。従って、イベントエンジン１０２は、「イベント捕捉」監査記録を生成し、次いで、「イベントディスパッチ」監査記録を生成し、次いで、「ブロック退出−イベント」監査記録を生成する。これらの監査記録から、システム（例えば、監査ファイルプロセッサモジュール１１４）は、次のフィールド、すなわち、イベント＿タイプ、タイムスタンプ及びインスタンス＿ｉに対する値を得る。この例では、システムは、これらの監査記録をまとめてｂｌｏｂ型に収集し、キーフィールド（例えば、イベント＿タイプ、タイムスタンプ及びインスタンス＿ｉｄ）は、システムによって、捉えたデータから（例えば、監査記録から）の別の記録（例えば、ＩＣＦＦ記録）において設定される。

別の例では、チャートに対する対象者の１つのタイムアウトが起こる。この例では、イベントエンジン１０２は、次の監査記録、すなわち、アラームタイプの「イベント捕捉」監査記録を生成し、次いで、「アラームディスパッチ」監査記録を生成し、次いで、「ブロック退出−アラーム」監査記録を生成する。これらの監査記録から、システムは、次のキーフィールド、すなわち、イベント＿タイプ、タイムスタンプ及びインスタンス＿ｉｄに対する値を決定する。この例では、システムは、ブロック退出−アラーム監査記録からインスタンス＿ｉｄフィールドの値を決定する（例えば、そのフィールドの値を推測するというよりむしろ）。この例では、システムは、これらの監査記録をｂｌｏｂ型に収集し、キーフィールド（例えば、イベント＿タイプ、タイムスタンプ、インスタンス＿ｉｄなど）は、システムによって、捉えたデータ（例えば、監査記録）から設定される。

さらなる別の例では、チャートを開始するという対象者のイベントが起こる。この例では、イベントエンジン１０２は、「イベント捕捉」監査記録（チャート開始タイプのものでも、別のタイプのものでもよい）を生成し、次いで、「イベントディスパッチ」監査記録を生成し、次いで、「チャート開始」監査記録を生成する。これらの監査記録から、システムは、次のキーフィールド、すなわち、イベント＿タイプ、タイムスタンプ及びインスタンス＿ｉｄに対する値を得る。システムは、監査記録をｂｌｏｂ型に収集し、キーフィールド（イベント＿タイプ、タイムスタンプ、インスタンス＿ｉｄなど）は、捉えたデータ（例えば、監査記録）から設定される。

監査記録はキー別に分類されるため、特定のキーと関連付けられた監査記録のサブセットは、キーフィールドを含まない。例えば、データベース１１２又は監査ファイルプロセッサモジュール１１４は、次の監査記録のシーケンス、すなわち、イベント捕捉監査記録、イベントディスパッチ監査記録、ブロック退出−イベント監査記録を受信することができる。この例では、データベース１１２又は監査ファイルプロセッサモジュール１１４は、イベント捕捉監査記録から対象者ＩＤ（例えば、キー）を得る。従って、イベントエンジン１０２は、イベントディスパッチ及びブロック退出監査記録においてキーを複製する必要はないが、その理由は、イベント捕捉監査記録の後、これらの監査記録がメモリにおいて（例えば、データベース１１２又は他のシステムメモリにおいて）順次的なものであるためである。同様に、イベントディスパッチ監査記録は、インスタンスＩＤフィールドを含む。従って、イベントエンジンは、ブロック退出監査記録においてこのフィールドを含むコピーする必要はない。システムは、監査記録メモリ（及びディスク上）を分類するため、システムは、グループ内のすべての監査記録にわたってキーをコピーする必要はなく、それにより、会話のシステム資源、メモリ消費量が低減される。

過剰量のデータの生成を回避するため、ユーザは、イベントエンジンが監査記録をいつ生成するか及びどの監査記録を生成するかを制御する。監査（延いてはメトリクス）は完全に無効化することができるが、監査が有効化される場合は、監査記録の主要セット（前の表においてプラス記号でマーク付けされたもの）が使用不能になることはない。監査記録の主要セットは、イベントエンジン入力（イベント及びアラーム）、出力（アクション）、エラー、並びに、チャート及び待機ブロック活動を追跡する。一般に、アラームは、将来において事前に計算された時刻に到着する事前に定義されたタイプのデータ記録（例えば、チャートがそれ自体を送信する）を含む。他の監査記録タイプは、選択的に使用可能及び使用不能にすることができる。任意選択の監査記録を使用可能にする次元は２つあり、それらは、何を使用可能にすべきか及びそれをいつ使用可能にすべきかである。何を使用可能にすべきかに関しては、選択的に使用可能／使用不能にすることができる多くの別個のグループの監査記録がある。それらは以下を含む。
・ Ａ：アラーム設定（デフォルトでオン）
・ Ｄ：決定（デフォルトでオン）
・ Ｐ：モニタリングポイント（デフォルトでオン）
・ Ｒ：ルールセット呼び出し及びルールセットイベント
・ Ｓ：変数設定
・ Ｖ：変数読み取り
・ Ｌ：検索アクセス及び検索変数

それをいつ使用可能にすべきかに関しては、これらの監査イベントのロギングは、すべてを使用可能にすることも、以下のうちの１つ又は複数に基づいて制限することもできる。
・ 対象者ｉｄ（例えば、キー）の指定セットのみ
・ チャート記名及び／又はモニタリング名の指定セットのみ
・ イベントタイプ（例えば、記録タイプ）の指定セットのみ

例では、イベントエンジン１０２は、制御点を通じてこれらの監査記録のロギングを構成する。一般に、制御点は、ランタイムパラメータを含み、ランタイムパラメータは、ユーザ（チャートを生成する）によって定義され、ランタイムに１つ又は複数のチャート（又はチャートインスタンス）の挙動を変更するために使用される。この例では、監査記録は、４つの相関制御点のセットによって制御される（例えば、イベントエンジンによって）。５つの制御点は、以下の通りである。
・ 監査タイプ−これは、有効化する監査記録タイプのリストであり、上記の表１にリストされる文字を使用する。
・ 監査エンティティ−これは、対象者ｉｄのリストである。空白でない場合、イベントエンジンは、このリストに含まれる対象者ｉｄに対する監査タイプリスト内の監査記録タイプのみを生成する。（そうでなければ、すべての対象者ｉｄが監査される）。
・ 監査イベント−これは、イベントタイプのリストである（例えば、イベントタイプに相当するか又はイベントタイプを表す数）。空白でない場合、イベントエンジンは、このリストに含まれるイベントタイプに対する監査タイプリスト内の監査記録タイプのみを生成する。（そうでなければ、すべてのイベントが監査される）。様々なタイプのイベントがあり、例えば、ＳＭＳメッセージが送信されたことを指定するイベント、ユーザがモバイルプランを更新したことを指定するイベントなどを含む。
・ 監査チャート−これは、チャート名及びモニタリング名のリストである。空白でない場合、イベントエンジンは、このリストにチャート名又はモニタリング名が含まれるチャートに対する監査タイプの監査記録タイプを生成する。（そうでなければ、すべてのチャートが監査される）。
・ 監査変数−これは、変数名のコンマ分離リストを含む。空白でなく、且つ、変数に対する監査記録タイプ（例えば、変数設定又は変数読み取り）を生成するようにイベントエンジンが構成される場合、イベントエンジンは、変数名がこのリストに含まれる場合のみ監査記録を生成する。

いくつかの例では、イベントエンジン１０２は、異なるグループの監査記録に対して異なるルールを適用する。この例では、第１のルールセット（例えば、監査タイプ１、監査エンティティ１、監査イベント１、監査チャート１及び監査変数１）を有する第１のグループの監査記録（例えば、第１の監査グループ）と、第２のルールセット（例えば、監査タイプ２、監査エンティティ２、監査イベント２、監査チャート２及び監査変数２）を有する第２のグループの監査記録（例えば、第２の監査グループ）などがある。

この例では、監査タイプ、監査エンティティ、監査イベント、監査チャート及び監査変数の各々は、ある種のフィルタを含む。これらのフィルタのいずれか又はすべてが設定された場合は、イベントのサブセットのみが追加の監査（例えば、任意選択の形態の監査を含む監査）を有する。

例では、システムは、第１の監査グループを以下の通り実施することによって、最小限で監査するように構成される。
監査タイプ１＝「」（任意選択を使用不能にする）
監査エンティティ１＝「」（すべての対象者ＩＤ）
監査イベント１＝「」（すべてのイベントタイプ）
監査チャート１＝「」（すべてのチャート）
監査変数１＝「」（すべての変数、ただし、システムは任意選択の変数ロギングを無効化するように構成されるため、これは無視される）

ここで、別の例では、システムは、対象者＿ＩＤ １２３４５がオファの送信に対する基準をすべて満たしているにもかかわらず、なぜこの対象者番号へのオファが一度も送信されなかったのかを評価するように構成される。このオファを実施するチャートは「マイオファチャート」であり、トリガイベントは数値６である。この特定の対象者ＩＤにオファが送信されない理由についてのさらなる多くの詳細を得るため、システムは、第２の監査グループを用いて次の通り構成される。
監査タイプ２＝「ＡＤＰＲＳＶＬ」（すべての監査タイプを使用可能にする）
監査エンティティ２＝「１２３４５」（この対象者ＩＤのみ）
監査イベント２＝「６」（このイベントタイプのみ）
監査チャート２＝「マイオファチャート」（このチャートのみ）
監査変数２＝「」（すべての変数）

この例では、イベントが起こると、システムは、最初に、対象者ＩＤが監査イベント２のリストに含まれているかどうか、イベントタイプが監査イベント２のリストに含まれているかどうか、チャートが監査チャート２のリストに含まれているかどうかを確かめる。これらのすべての属性（例えば、フィルタ）が真に評価された場合は、システムは、監査タイプ２において指定されるようにすべての監査記録タイプを実施し、それにより、そのイベントの間の任意選択のロギングが開始される。真に評価されなかった場合は、システムは、監査タイプ１を実施し、それにより、単にデフォルトでのロギングが行われる。この例では、システムは、最初に高位番号のグループをチェックし、マッチするグループが見つかるまで逆方向に進むように構成される。マッチするグループが見つからなかった場合は、システムは、デフォルトを実施及び使用する。変形形態では、システムは、さらなる任意選択のロギングを追加するすべてのマッチンググループの融合体を取るように構成することができる。

この例では、イベントエンジン１０２は、条件監査ロギングを実施し（例えばモニタリングポイント監査記録の実施を介して）、その実行性能を最適化する。この性能を最適化するため、イベントエンジン１０２は、条件付き監査決定を行うためのデータ構造を事前に計算する（例えば、事前に生成する）。一般に、条件付き監査決定は、条件が指定値（例えば、真又は偽）に評価されるものを監査記録が生成されることを指定する。この例では、イベントエンジンは、イベント又はアラームに対するイベント処理の開始時に条件付き監査計算を行う。例えば、イベントエンジンがイベント又はアラームを検出するたび（ただし、例えば、すべての監査記録においてというよりむしろ、各イベント又はアラームの処理の開始時のみ）、イベントエンジンは、計算を実行する（例えば、上記で説明される監査グループにおいて）。イベントエンジンは、条件付き監査計算をグローバル変数のパッケージに保存し、その内部で条件付きであり得る監査関数の各々に対するクエリを行う。

各監査記録タイプに対し、イベントエンジン１０２は、その監査記録タイプに対する監査記録が生成されているかどうかを指定する単一のフラグを実施する。イベントエンジン１０２は、単一のフラグを実施する際、監査エンティティ及び監査イベントリストのコンテンツを分析するが、その理由は、これらのリストは両方とも、イベント処理を開始した際に指定又は生成されるためである。多くのチャートによって１つのイベントを処理することができるため、イベントエンジンは、監査関数（例えば、監査記録タイプ）が実施されているかどうかをチャート毎に判断する。監査チャートが空白でない場合、イベントエンジンは、実施されているチャートのｉｄとどのチャートが監査記録を生成しているか（及びどの監査記録タイプを生成しているか）を指定するインスタンスｉｄとの間の比較を簡略化するために、監査チャートのコンテンツをインスタンスｉｄのリスト（各々がチャートを識別する）に変換する。

例では、イベントエンジン１０２は、メモリ（例えば、イベントエンジン１０２内又はイベントエンジン１０２を含むシステム内の）において配列で監査記録を収集し、次いで、イベント又はイベントストリームの処理の終了時に１つのブロックで監査記録を監査ファイルに書き出す。この例では、異なるイベント（すなわち、異なるキー又はユーザＩＤと関連付けられたイベント）からの監査記録は、メモリにおいて混合されることはない。むしろ、メモリは仕切られており、各パーティションはそれ自体の監査ファイルを有する。従って、イベントエンジン１０２は、監査記録をキー別に自動的に分類するように構成される。

この例では、監査ファイルはバージョン化される。各パルスに対し、監査ファイルの１つのインスタンスが存在する。監査ファイルはディスク上で蓄積し、監査ファイル処理グラフ（監査ファイルプロセッサモジュール１１４によって実行される）は、パルスの終了時に各監査ファイルを取り出し（各パーティションから）、監査記録を後処理し、それらをＩＣＦＦに書き込む。

この例では、システムは、例えば、イベントエンジン１０２のメモリから監査記録を読み取るというよりむしろ、ＩＣＦＦ（データベース１１６）からの監査記録を後処理することによってメトリクスデータベース１２０を生成する。この例では、ＩＣＦＦはパージされない。従って、メトリクスデータベース１２０は、異なる集計期間の使用を含めて、いつでも再作成することができる。この例では、メトリクスデータベース１２０の表は、１つのデータベースを複数のクラスタに対して使用できるように、クラスタ＿名の列を有する。一般に、クラスタは、イベントエンジンインスタンスを含む。一般に、イベントエンジンインスタンスは、キーの一意的な値に対する１つ又は複数の仕様（イベントエンジン１０２によって１つ又は複数のチャートが実行される対象となる）の特有の実現を含む。すなわち、各対象者ＩＤは、正確に１つのイベントエンジンインスタンスによって取り扱われる。従って、一意的なキー（例えば、対象者ＩＤ）の各々に対し、そのチャートのすべてを有する正確に１つのイベントエンジンインスタンスが存在する。同じクラスタに対する監査記録は、同じ値のクラスタ＿名を有する。

この例では、メトリクスデータベース１２０は、イベントエンジン１０２によって処理されたイベントの総数（例えば、イベント捕捉監査記録に基づく）、エラーが生じたイベントの数（例えば、エラーディスパッチ監査記録に基づく）、キャンペーンをトリガしたイベントの数（例えば、アクション送信監査記録に基づく）、どのサービス加入者が特定のキャンペーンに対してある段階から別の段階に移動したか（例えば、ブロック進入監査記録に基づく）、特定の日に対してイベントエンジンにおいてキャンセル又は追加されたサービス加入者の数（例えば、チャート開始及びチャート終了監査記録に基づく）、イベントエンジンで起動しているチャートの総数（例えば、チャート開始監査記録に基づく）及びイベントエンジンによってイベントが処理されている時にイベントエンジン１０２の状態を追跡するものなど、イベントエンジン１０２の状態を示すメトリクスに対してクエリを行うことができる。

それに加えて、メトリクスデータベース１２０は、特定のキーに対して（例えば、各サービス加入者に対して）メッセージが送信されなかった理由を指定するデータを回収するために、クエリを行うことができる（例えば、クライアントデバイス又は本明細書で説明されるシステムによって）。その実施のため、イベントエンジンは、取ったリンク（及び／又はチャート内で実行されたコンポーネント）並びにイベントエンジン１０２を介してアクセス及び実施されたルールセットケースをロギングするように構成される（例えば、どのコンポーネント及び／又はリンクが実行されるかを指定する監査記録を生成することによって）。次いで、システムは、特定のメッセージが送信されなかった理由（例えば、監査記録によって指定されるように、代替の経路が走査されたために送信されているメッセージに対応する経路が一度も走査されなかったため）を決定するために、チャートを通じて取った経路（例えば、監査記録によって指定されるような）を、チャートを通じるすべての潜在的な経路と比較するように構成可能である。

図５を参照すると、チャート２５０は、ノード２５２〜２６６を含む。この例では、ノード２５２〜２６４の各々は、１つ又は複数の監査記録を自動的に生成するためのコードを含むデータ処理コンポーネントを表す。例えば、ノード２５２は、チャート開始監査記録２５２ａを生成するように構成されたデータ処理コンポーネントを表す。ノード２５４は、変数設定監査記録２５４ａ及び変数読み取り監査記録２５４ｂを生成するように構成されたデータ処理コンポーネントを表す。この例では、変数設定監査記録２５４ａは、設定されている変数名を指定する。この例では、変数名は、「次のメッセージ日」である。変数読み取り監査記録２５４ｂは、読み取られている変数名を指定する。この例では、読み取られている変数名は、「開始日」である。ノード２５６によって表されるデータ処理コンポーネントは、監査記録２５６ａ〜２５６ｉを生成する。ノード２５８によって表されるデータ処理コンポーネントは、監査記録２５８ａ〜２５８ｃを生成する。ノード２６０によって表されるデータ処理コンポーネントは、監査記録２６０ａ〜２６０ｇを生成する。ノード２６２によって表されるデータ処理コンポーネントは、監査記録２６２ａ〜２６２ｃを生成する。ノード２６４によって表されるデータ処理コンポーネントは、監査記録２６４ａ〜２６４ｇを生成する。この例では、「次のメッセージ日」は、イベントエンジンがメッセージを処理する次の日付である。この例では、「次のメッセージ日」は、キャンペーンの初日であるように設定される。この例では、チャート２５０が開始される（キャンペーンが開始する前であり得る）とすぐに、イベントエンジンは、ノード２５６、２６０、２６４によってそれぞれ表される開始、オファ及びＩＶＲアクションを送信する。この例では、開始、オファ及びＩＶＲアクションは、チャートによって送信される３つのアクションである。対象者がキャンペーンをトリガすると、システムは、開始アクションを送信する。システムは、オファのための外部のサブシステムを構成するためにオファアクションを送信し（例えば、アカウントに資金を追加投入すると１０分間の無料通話が得られる）、電話の着信を取り扱う外部のサブシステムを構成するためにＩＶＲアクションを送信する（例えば、「利用可能なオファを知らせてください」）。この例では、対応するメタデータが空白の場合又はサービス加入者（キーによって表される）が対照群内に含まれる場合（ノード２５８によって表されるように）は、チャート２５０は、ノード２６０には進行せず（従って、オファアクションを送信しない）、代わりに、ノード２６２に進行する。この例では、ＩＶＲに対応するメタデータが空白の場合又はサービス加入者（キーによって表される）が対照群内に含まれる場合（ノード２６２によって表されるように）は、チャート２５０は、ノード２６４には進行せず（従って、ＩＶＲアクションを送信しない）、代わりに、ノード２６６に進行し、ノード２６６によって表されるように、イベントエンジンがメッセージ処理を毎日実行する必要があるかどうかを確かめる。

図６を参照すると、プロセス２８０は、データ処理システムによって、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するために実施され、仕様は実行可能論理を表し、仕様はキーと関連付けられ、仕様の状態はキーのそれぞれの値に対して維持される。

動作の際、データ処理システムは、実行可能論理を表す仕様にアクセスし（２８２）、キーの特定の値に対する仕様の状態は、その状態で実行可能な実行可能論理の１つ又は複数の部分を指定する。また、データ処理システムは、例えば、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信し（２８４）、１つ又は複数のデータアイテムの各々は、キーの所定の値と関連付けられる。データ処理システムは、キーの所定の値に対するログ記録を生成し（２８６）、ログ記録は、各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を指定する。この例では、生成することは、キーの所定の値と関連付けられる１つ又は複数のデータアイテムの各々に対し、次の動作を含む。データ処理システムは、そのデータアイテムと関連付けられたキーの所定の値に対する仕様の所定の状態を特定する（２８８）。データ処理システムは、所定の状態と関連付けられたものとして仕様において表される実行可能論理の１つ又は複数の部分の実行に従って、そのデータアイテムを処理する（２９０）。データ処理システムは、キーのその所定の値に対する実行可能論理のそれらの１つ又は複数の部分の実行を指定するログ記録を生成する（２９２）。

図７Ａ〜７Ｈは、チャートの実行の間の監査記録生成からのＩＣＦＦ記録及びデータブロックの生成を示す。ここで図７Ａを参照すると、略図３００は、コンポーネント３０４〜３１６を有するチャート３０１を含む。現実世界の例では、チャート３０１は、例えば、複数の通話切断を経験している顧客を補償することを希望する通信会社によって実行するように構成される。具体的には、顧客がこの２時間の間に通話切断を２回経験した場合（コンポーネント３０８によって指定されるように）又は丸１日の間に通話切断が４回あった場合（コンポーネント３１８によって指定されるように）は、通信会社は、顧客のアカウントに５分間の無料通話を追加する（コンポーネント３１０、３１４によって指定されるように）。会社は、２４時間に１回支払うだけである（コンポーネント３０６、３１２によって指定されるように）。チャート３０１は、使用期限なく起動される。この例では、本明細書で説明されるシステムがチャート３０１を実行する。

図７Ｂを参照すると、略図３０３は、チャート３０１が実行を開始したというチャート３０１の状態を示している。チャート３０１の開始時、チャート３０１は第１の状態であり、第１の状態では、コンポーネント３０４が実行され（コンポーネント３０４の周りの太線によって示されるように）、それにより、システムは、監査記録３２４を生成する。図７Ｃを参照すると、略図３０５は、チャート３０１が第２の状態に進行していることを示し、第２の状態では、システムは、指定されたイベントを待ち、次いで、イベントが検出され次第、様々な決定を行い、様々なアクションを実行する。この例示的な状態では、システムは、コンポーネント３０６を実行し（コンポーネント３０６の周りの太線によって指定されるように）、システムは、監査記録３２６を生成する。コンポーネント３０６では、システムは、例えば、最後の通話が切断されたことを指定するイベント（すなわち、「最後の通話が切断された」というイベントタイプ）などの指定されたイベントを待つように構成される。この例では、システムは、イベント３０２（例えば、構造化データアイテム又はデータ記録）を受信し、イベント３０２は、このイベントが「最後の通話が切断された」というイベントタイプのものであることを指定するデータを含む。イベント３０２が検出され次第、システムは、監査記録３２２を生成し、コンポーネント３０６（又はコンポーネント３０６によって表される実行可能論理を実行するシステム）は、この２４時間の間に支払いがあったかどうかを判断する（すなわち、現在の時刻−最後の通話切断の支払時刻≧２４時間）。その実施の際、システムは、監査記録３２８、３３０を生成し、その各々は、読み取った変数の値を指定する。イベント３０２が検出され、この２４時間の間に支払いが行われなかったことが検出され次第、システムは、第２の状態を保持しながら、監査記録３３２を生成し、コンポーネント３０８に進行する。

図７Ｄを参照すると、略図３０７は、コンポーネント３０８の周りの太線によって示されるように、システムがコンポーネント３０８を実行するチャート３０１の状態を示している。この例では、コンポーネント３０８（又はコンポーネント３０８によって表される実行可能論理を実行するシステム）は、変数の値を読み取る際に監査記録３３４、３３６を生成する。この例では、コンポーネント３０８によって表される論理は、読み取った変数の値に基づいて、「否定」の値に評価する。

図７Ｅを参照すると、略図３０９は、チャート３０１のさらなる別の状態を示し、依然として第２の状態を保持したまま、コンポーネント３１８が実行される（コンポーネント３１８の周りの太線によって示されるように）。コンポーネント３１８では、システムは、監査記録３６２を生成し、監査記録３６２は、「１時間あたりの通話切断回数」という変数の読み取った値を指定する。この例では、システムは、コンポーネント３１８によって表される論理が「肯定」の値に評価すると決定し、監査記録３６４を生成し、監査記録３６４のコンテンツは、コンポーネント３１８（「決定２」と呼ばれる）が「肯定」の値に評価したことを指定する。

図７Ｆを参照すると、略図３１１は、チャート３０１がコンポーネント３１０に進行したことを示し、コンポーネント３１０は、監査記録３４０を生成する。図７Ｇを参照すると、略図３１３は、チャート３０１が次いでコンポーネント３１２に進行したことを示し、コンポーネント３１２は、監査記録３４２を生成する。

図７Ｈを参照すると、略図３１５は、チャート３０１が次いでコンポーネント３１４に進行したことを示し、コンポーネント３１４は、監査記録３４４を生成する。次いで、チャート３０１は、コンポーネント３１６に進行する。この例では、システムは、監査記録３２２、３２４、３２６、３２８、３３０、３３２、３３４、３３６、３３８、３４０、３４２、３４４、３６２、３６４を一括し、ＩＣＦＦ記録に格納するキーフィールド（例えば、イベントタイプ、対象者ＩＤ、タイムスタンプ、インスタンスＩＤに対するフィールド）を特定し、次いで、残りの監査記録を集合体にまとめる。この例では、システムは、キーフィールド（例えば、監査記録３２２、３２４からの）を含むＩＣＦＦ記録３４８を生成する。監査記録３２６、３２８、３３０、３３２、３３４、３３６、３３８、３４０、３４２、３４４、３６２、３６４のコンテンツ及びＩＣＦＦ記録３４８に含まれない監査記録３２２、３２４のコンテンツは、データブロック３５０に含まれる。システムは、ＩＣＦＦ記録３４８及びデータブロック３５０をデータベース３４６に格納する。この例では、データベース３４６は、インデックス３５２を格納し、ＩＣＦＦ記録３４８は、次のフィールド別に、すなわち、インデックス３５２の行３５４に示されるような、タイムスタンプ、対象者＿ＩＤ及びイベントタイプ別に、インデックス３５２においてインデックス生成される。この例では、インデックス３５２は、他のＩＣＦＦ記録の（例えば、他のチャート及び／又は他の対象者ＩＤに対する）インデックスを生成する行３５６、３５８、３６０も含む。この例では、ＩＣＦＦ記録３４８は、参照データ構造３６６（例えば、ポインタ）を介してデータブロック３５０を参照する。変形形態では、ＩＣＦＦ記録３４８及びデータブロック３５０を組み合わせて、インデックス付きのＩＣＦＦデータブロック（又はデータブロック）にする。

上記で説明される技法は、コンピュータ上で実行するためのソフトウェアを使用して実施することができる。例えば、ソフトウェアは、１つ又は複数のプログラムされた又はプログラム可能なコンピュータシステム（分散、クライアント／サーバ若しくはグリッドなどの様々なアーキテクチャのものであり得る）上で実行される１つ又は複数のコンピュータプログラムの手順を形成するものであり、各コンピュータシステムは、少なくとも１つのプロセッサと、少なくとも１つのデータ記憶システム（揮発性及び不揮発性メモリ及び／又は記憶素子を含む）と、少なくとも１つの入力デバイス又はポートと、少なくとも１つの出力デバイス又はポートとを含む。ソフトウェアは、より大きなプログラムの１つ又は複数のモジュールを形成することができ、モジュールは、例えば、チャート及びフローチャートの設計及び構成に関連する他のサービスを提供する。チャートのノード、リンク及び要素は、コンピュータ可読媒体に格納されるデータ構造として又はデータリポジトリに格納されるデータモデルに適合する他の組織化データとして実装することができる。

本明細書で説明される技法は、デジタル電子回路において、コンピュータハードウェア、ファームウェア、ソフトウェアにおいて又はそれらの組合せで実装することができる。装置は、有形に具体化されるか又はプログラマブルプロセッサによって実行するための機械可読記憶装置（例えば、非一時的な機械可読記憶装置、機械可読ハードウェア記憶装置など）に格納されるコンピュータプログラム製品において実装することができ、方法のアクションは、入力データに基づいて動作して出力を生成することによって機能を実行するために命令のプログラムを実行するプログラマブルプロセッサによって実行することができる。本明細書で説明される実施形態並びに請求項及び本明細書で説明される技法の他の実施形態は、有利には、データ記憶システムとのデータ及び命令の送受信を行うように結合された少なくとも１つのプログラマブルプロセッサと、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを含むプログラマブルシステム上で実行可能な１つ又は複数のコンピュータプログラムにおいて実装することができる。各コンピュータプログラムは、高水準手続き型若しくはオブジェクト指向プログラミング言語で又は必要に応じてアセンブリ言語若しくは機械語で実施することができ、いかなる事例においても、言語は、コンパイラ型又はインタープリタ型言語であり得る。

コンピュータプログラムの実行に適したプロセッサは、例として、汎用マイクロプロセッサと専用マイクロプロセッサの両方及び任意の種類のデジタルコンピュータの任意の１つ又は複数のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリ若しくはランダムアクセスメモリ又はその両方から命令及びデータを受信する。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令及びデータを格納するための１つ又は複数のメモリデバイスである。また、一般に、コンピュータは、データを格納するための１つ又は複数の大容量記憶装置（例えば、磁気ディスク、光磁気ディスク若しくは光ディスク）を含むか、或いは、データの受信若しくは転送又はその両方を行うために１つ又は複数の大容量記憶装置に動作可能に結合される。コンピュータプログラム命令及びデータを具体化するためのコンピュータ可読媒体は、不揮発性メモリのすべての形態を含み、例として、半導体メモリデバイス（例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュメモリデバイス）や、磁気ディスク（例えば、内部ハードディスク又はリムーバブルディスク）や、光磁気ディスクや、ＣＤ−ＲＯＭ及びＤＶＤ−ＲＯＭディスクを含む。プロセッサ及びメモリは、専用論理回路によって補充することも、専用論理回路に組み込むこともできる。前述のいずれも、ＡＳＩＣ（特定用途向け集積回路）によって補充することも、ＡＳＩＣ（特定用途向け集積回路）に組み込むこともできる。

ユーザとの対話を提供するため、実施形態は、ユーザに情報を表示するための表示デバイス（例えば、ＬＣＤ（液晶ディスプレイ）モニタ）や、ユーザがコンピュータに入力を提供できるようにするためのキーボード及びポインティングデバイス（例えば、マウス又はトラックボール）を有するコンピュータ上で実装することができる。ユーザとの対話を提供するため、他の種類のデバイスを使用することもでき、例えば、ユーザに提供されるフィードバックは、感覚フィードバック（例えば、視覚フィードバック、聴覚フィードバック又は触覚フィードバック）のいかなる形態でもよく、ユーザからの入力は、音響、音声または触覚入力を含むいかなる形態でも受信することができる。

実施形態は、バックエンドコンポーネント（例えば、データサーバとして）を含むか、ミドルウェアコンポーネント（例えば、アプリケーションサーバ）を含むか、フロントエンドコンポーネント（例えば、ユーザが実施形態の実装形態と対話できるようにするためのグラフィカルユーザインタフェース若しくはウェブブラウザを有するクライアントコンピュータ）を含むか、そのようなバックエンド、ミドルウェア又はフロントエンドコンポーネントの任意の組合せを含む、コンピューティングシステムにおいて実装することができる。システムのコンポーネントは、デジタルデータ通信の任意の形態又は媒体（例えば、通信ネットワーク）によって相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク（ＬＡＮ）及び広域ネットワーク（ＷＡＮ）（例えば、インターネット）を含む。

システム及び方法又はそれらの一部は、「ワールドワイドウェブ」（ウェブ又はＷＷＷ）を使用することができ、「ワールドワイドウェブ」は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を利用するインターネット上のサーバの集合体である。ＨＴＴＰは、テキスト、グラフィックス、画像、音声、映像、ハイパーテキストマークアップ言語（ＨＴＭＬ）及びプログラムなどの異なるフォーマットの情報であり得る資源へのアクセスをユーザに提供する公知のアプリケーションプロトコルである。ユーザによってリンクが指定され次第、クライアントコンピュータは、ウェブサーバへのＴＣＰ／ＩＰ要求を行い、情報（ＨＴＭＬに従ってフォーマットされた別のウェブページであり得る）を受信する。また、ユーザは、画面上の命令に従ってあるデータを入力するか又は選択したアイコンをクリックすることによって、同じ又は他のサーバ上の他のページにもアクセスすることができる。また、ユーザが所定のコンポーネントに対するオプションを選択できるようにするため、ウェブページを使用する実施形態に対して、当業者に知られているいかなるタイプの選択デバイス（チェックボックス、ドロップダウンボックス及び同様のものなど）も使用できることにも留意されたい。サーバは、ＵＮＩＸ(登録商標)マシンを含む様々なプラットフォーム上で起動することができるが、Ｗｉｎｄｏｗｓ ２０００／２００３、Ｗｉｎｄｏｗｓ ＮＴ、Ｓｕｎ、Ｌｉｎｕｘ(登録商標)、Ｍａｃｉｎｔｏｓｈなどの他のプラットフォームを使用することもできる。コンピュータユーザは、Ｆｉｒｅｆｏｘ、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ又はＭｏｓａｉｃブラウザなどの閲覧ソフトの使用を通じて、ウェブ上のサーバ又はネットワーク上で利用可能な情報を閲覧することができる。コンピューティングシステムは、クライアント及びサーバを含み得る。クライアント及びサーバは、一般に、互いにリモート場所に位置し、典型的には、通信ネットワークを通じて対話する。クライアントとサーバとの関係は、コンピュータプログラムによって生じ、コンピュータプログラムは、それぞれのコンピュータ上で起動しており、互いにクライアント・サーバ関係を有するものである。

他の実施形態は、説明及び請求項の範囲及び精神内である。例えば、ソフトウェアの本質のため、上記で説明される機能は、ソフトウェア、ハードウェア、ファームウェア、配線又はこれらの任意の組合せを使用して実装することができる。機能を実装する特徴もまた、様々な位置に物理的に位置し得、機能の一部が異なる物理的場所で実装されるように分散されることを含む。本明細書における及び本出願全体を通じる「ａ」という用語の使用は、制御様式では使用されず、従って、「ａ」という用語に対して複数の意味或いは「１つ又は複数の」という意味を除外することを意図しない。それに加えて、仮特許出願に対して優先権が主張される範囲で、仮特許出願は制限するものではなく、本明細書で説明される技法をどのように実装できるかについての例を含むものであることを理解されたい。

本発明の多くの実施形態について説明してきた。それにもかかわらず、当業者であれば、請求項及び本明細書で説明される技法の精神及び範囲から逸脱することなく、様々な変更を行えることが理解されよう。

１００ 環境
１０２ イベントエンジン
１０４ ルールセットログ
１０６ チャート実行モジュール
１０８ チャート
１１０、１１２、１１６ データベース
１１１ 監査記録
１１４ 監査ファイルプロセッサモジュール

Claims (29)

1. 各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するためのデータ処理システムによって実施される方法であって、仕様が前記実行可能論理を表し、前記仕様が前記キーと関連付けられ、前記仕様の状態が前記キーのそれぞれの値に対して維持される、方法であり、
   前記実行可能論理を表す前記仕様にアクセスすることであって、前記キーの特定の値に対する前記仕様の状態が、その状態で実行可能な前記実行可能論理の１つ又は複数の部分を指定する、アクセスすることと、
   入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、前記１つ又は複数のデータアイテムの各々が、前記キーの前記所定の値と関連付けられる、受信することと、
   前記キーの前記所定の値に対するログ記録を生成することであって、前記ログ記録が、各々が前記キーの前記所定の値と関連付けられる前記１つ又は複数のデータアイテムを処理する際に実行される前記実行可能論理の前記１つ又は複数の部分を指定する、生成することであり、
   前記キーの前記所定の値と関連付けられる前記１つ又は複数のデータアイテムの各々に対し、
   そのデータアイテムと関連付けられた前記キーの前記所定の値に対して維持される前記仕様の所定の状態を特定すること、
   前記データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、前記仕様の前記特定された所定の状態で指定された実行可能論理の１つ又は複数の部分を実行することを含む、処理すること、及び、
   前記キーのその所定の値に対する前記実行可能論理のそれらの１つ又は複数の部分の前記実行を指定する前記ログ記録を生成すること
   を含む、生成することと
   を含む、方法。
2. ログ記録をキー別に分類することであって、第１のキーと関連付けられた第１のログ記録が、第１のグループに分類され、第２のキーと関連付けられた第２のログ記録が、第２のグループに分類される、分類することをさらに含む、請求項１に記載の方法。
3. 前記ログ記録が、メモリにおいて分類される、請求項２に記載の方法。
4. 各ログ記録が、データアイテムの処理の１つ又は複数の属性を示す１つ又は複数のフィールドを含み、少なくとも１つのログ記録に対し、フィールドが、前記データアイテムと関連付けられたキーの値を指定するキーフィールドである、請求項２に記載の方法。
5. 特定のキーと関連付けられたログ記録のサブセットが、前記キーフィールドを含まない、請求項４に記載の方法。
6. 特定のキーと関連付けられたログ記録のうち、たった１つのログ記録しか前記キーフィールドを含まない、請求項４に記載の方法。
7. 事前に定義された時間間隔の終了時に、特定のキーと関連付けられた特定のグループのログ記録をファイルに書き込むこと
   をさらに含む、請求項２に記載の方法。
8. 前記ファイルを再フォーマットすることと、
   前記再フォーマット済みのファイルをインデックス付き圧縮フラットファイル（ＩＣＦＦ）に書き込むことと、
   キー別にインデックスにおいて前記ＩＣＦＦのインデックスを生成することと
   をさらに含む、請求項７に記載の方法。
9. 前記仕様が、多数のノードを有するチャートを含み、各ノードが、前記実行可能論理の１つ又は複数の部分を表し、前記チャートが、実行可能なものであり、前記チャートの実行により、前記実行可能論理の複数の部分が実行される、請求項１に記載の方法であって、
   前記ログ記録に基づいて、１つ又は複数のデータアイテムを処理する際に１つ又は複数のノード前記チャートを通じて走査をトレースすること
   をさらに含む、方法。
10. 前記チャートのどのノードを走査し且つ前記チャートのどのノードを走査しないかを特定するために、前記ログ記録を構文解析すること
    をさらに含む、請求項９に記載の方法。
11. 前記ログ記録が、前記チャートのどのノードを走査し且つ前記チャートのどのノードを走査しないかを指定する、請求項１０に記載の方法。
12. ユーザ起動による前記ノードのうちの１つの選択を受信することと、
    前記選択を受信することに応答して、選択されたノードによって表される前記実行可能論理の前記１つ又は複数の部分をユーザが構成するための構成手段を提供する構成エリアをグラフィカルユーザインタフェース上に表示させることであって、前記構成手段が、監査を有効化及び無効化するための手段を含む、表示することと、
    前記構成手段を介してユーザ起動による前記監査の有効化を受信し、前記選択されたノードと関連付けられた前記ログ記録を生成させることと
    をさらに含む、請求項９に記載の方法。
13. 前記キーのその所定の値に対する前記実行可能論理のそれらの１つ又は複数の部分の前記実行を指定する前記ログ記録を前記生成することが、
    前記生成されたログ記録において、前記実行可能論理のそれらの１つ又は複数の部分の前記実行の結果を指定すること、前記実行可能論理のそれらの１つ又は複数の部分が実行され次第読み取られるか又は設定される変数を指定すること、或いは、実行される前記実行可能論理のそれらの１つ又は複数の部分を特定すること
    を含む、請求項１に記載の方法。
14. 前記実行可能論理の前記１つ又は複数の部分を実行することに応答して、コンピューティングシステムによって実行予定のアクションを開始すること
    をさらに含む、請求項１に記載の方法。
15. 前記アクションが、実行可能論理の前記１つ又は複数の部分の前記実行の実行特性に基づいて、実行可能論理の前記１つ又は複数の部分の前記実行のための追加の演算資源を要求することを含む、請求項１４に記載の方法。
16. 各状態に対して前記実行可能論理のどの部分が現在実行されているかを示す状態データをデータリポジトリ又はインメモリデータグリッドに格納することによって、前記状態を維持すること
    をさらに含む、請求項１に記載の方法。
17. 各々が前記キーの前記所定の値と関連付けられる前記１つ又は複数のデータアイテムの前記処理の完了に応答して、前記キーのその値に対する現在の状態を指定するために、前記状態データを更新すること
    をさらに含む、請求項１６に記載の方法。
18. 前記チャートのどのノードを走査するか及び前記データアイテム別に前記ノードを何回走査するかを示すメトリクスを動的に決定すること
    をさらに含む、請求項９に記載の方法。
19. チャートを通じて取った経路を文書化するログ記録のストリームを生成することと、
    前記生成されたログ記録を変換することと、
    前記変換済みのログ記録をリレーショナルデータベース又はインデックス付き圧縮フラットファイルに格納することであって、指定された粒度でログ記録を一括することを含む、格納することと
    をさらに含む、請求項１に記載の方法。
20. ユーザインタフェースを介して、前記決定されたメトリクスを動的に出力することであって、前記出力されたメトリクスが、前記決定されたメトリクスの変更に応答して更新される、出力すること
    をさらに含む、請求項１８に記載の方法。
21. 前記ストリームの前記複数のデータアイテムのうちの第１のデータアイテムのユーザ選択を受信することと、
    前記複数のデータアイテムのうちの前記選択された第１のデータアイテムにおいて現在実行されている前記実行可能論理の前記１つ又は複数の部分の表示を表示させることと
    をさらに含む、請求項１に記載の方法。
22. 現在処理されている前記ストリームの前記複数のデータアイテムのうちの前記選択された第１のデータアイテムを既定の参照データアイテムと比較することと、
    現在処理されている前記ストリームの前記複数のデータアイテムのうちの前記第１のデータアイテムと前記既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、
    現在処理されている前記ストリームの前記複数のデータアイテムのうちの前記第１のデータアイテムと前記既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかの前記判断に基づいて、現在処理されている前記ストリームの前記複数のデータアイテムのうちの前記第１のデータアイテムが前記既定の参照データアイテムと一致するかどうかについての表示を出力することと
    をさらに含む、請求項２１に記載の方法。
23. 前記複数のデータアイテムのうちの前記第１のデータアイテムにおいて現在実行されている前記実行可能論理の前記１つ又は複数の部分を既定の参照実行可能論理と比較することと、
    前記複数のデータアイテムのうちの前記第１のデータアイテムにおいて現在実行されている前記実行可能論理の前記１つ又は複数の部分と前記既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、
    前記複数のデータアイテムのうちの前記第１のデータアイテムにおいて現在実行されている前記実行可能論理の前記１つ又は複数の部分と前記既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかの前記判断に基づいて、前記複数のデータアイテムのうちの前記第１のデータアイテムにおいて現在実行されている前記実行可能論理の前記１つ又は複数の部分が前記既定の参照実行可能論理と一致するかどうかについての表示を出力することと
    をさらに含む、請求項２１に記載の方法。
24. ログ記録が、前記キーの特定の値に対する前記仕様の状態を表すデータを格納するための第１のフィールドと、前記キーのその特定の値に対し、前記実行可能論理の実行が開始された時刻から現在の時刻までに、前記仕様によって表される前記実行可能論理のどの部分が実行されたかを指定するデータを格納するための第２のフィールドとを有する構造化データ記録である、請求項１に記載の方法。
25. ログ記録が、前記キーの特定の値に対し、現在の時刻に、前記仕様によって表される前記実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する構造化データ記録である、請求項１に記載の方法。
26. 前記仕様がチャートであり、１つ又は複数のログ記録が、前記キーの特定の値と関連付けられた１つ又は複数のデータ記録を処理する際に前記実行可能論理のどの部分が実行されるかを表す前記チャートを通じる経路を指定する、請求項１に記載の方法。
27. １つ又は複数のデータアイテムの処理に基づいて１つ又は複数の出力記録を生成することであって、前記１つ又は複数の出力記録の各々が、前記ログ記録に含まれないデータを含む、生成することをさらに含む、請求項１に記載の方法。
28. 各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するためのデータ処理システムであって、仕様が前記実行可能論理を表し、前記仕様が前記キーと関連付けられ、前記仕様の状態が前記キーのそれぞれの値に対して維持される、データ処理システムであり、
    １つ又は複数の処理デバイスと、
    命令を格納する１つ又は複数の機械可読ハードウェア記憶装置と
    を含む、データ処理システムであり、前記命令が、
    前記実行可能論理を表す前記仕様にアクセスすることであって、前記キーの特定の値に対する前記仕様の状態が、その状態で実行可能な前記実行可能論理の１つ又は複数の部分を指定する、アクセスすることと、
    入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、前記１つ又は複数のデータアイテムの各々が、前記キーの前記所定の値と関連付けられる、受信することと、
    前記キーの前記所定の値に対するログ記録を生成することであって、前記ログ記録が、各々が前記キーの前記所定の値と関連付けられる前記１つ又は複数のデータアイテムを処理する際に実行される前記実行可能論理の前記１つ又は複数の部分を指定する、生成することであり、
    前記キーの前記所定の値と関連付けられる前記１つ又は複数のデータアイテムの各々に対し、
    そのデータアイテムと関連付けられた前記キーの前記所定の値に対して維持される前記仕様の所定の状態を特定すること、
    データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、前記仕様の前記特定された所定の状態で指定された実行可能論理の１つ又は複数の部分を実行することを含む、処理すること、及び、
    前記キーのその所定の値に対する前記実行可能論理のそれらの１つ又は複数の部分の前記実行を指定する前記ログ記録を生成すること
    を含む、生成することと
    を含む動作を実行するために前記１つ又は複数の処理デバイスによって実行可能である、データ処理システム。
29. 各々がキーの所定の値と関連付けられる１つ又は複数のデータアイテムを処理する際に実行される実行可能論理の１つ又は複数の部分を特定するための１つ又は複数の機械可読ハードウェア記憶装置であって、仕様が前記実行可能論理を表し、前記仕様が前記キーと関連付けられ、前記仕様の状態が前記キーのそれぞれの値に対して維持される、１つ又は複数の機械可読ハードウェア記憶装置であり、命令を格納する１つ又は複数の機械可読ハードウェア記憶装置であり、前記命令が、
    前記実行可能論理を表す前記仕様にアクセスすることであって、前記キーの特定の値に対する前記仕様の状態が、その状態で実行可能な前記実行可能論理の１つ又は複数の部分を指定する、アクセスすることと、
    入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、前記１つ又は複数のデータアイテムの各々が、前記キーの前記所定の値と関連付けられる、受信することと、
    前記キーの前記所定の値に対するログ記録を生成することであって、前記ログ記録が、各々が前記キーの前記所定の値と関連付けられる前記１つ又は複数のデータアイテムを処理する際に実行される前記実行可能論理の前記１つ又は複数の部分を指定する、生成することであり、
    前記キーの前記所定の値と関連付けられる前記１つ又は複数のデータアイテムの各々に対し、
    そのデータアイテムと関連付けられた前記キーの前記所定の値に対して維持される前記仕様の所定の状態を特定すること、
    データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、前記仕様の前記特定された所定の状態で指定された実行可能論理の１つ又は複数の部分を実行することを含む、処理すること、及び、
    前記キーのその所定の値に対する前記実行可能論理のそれらの１つ又は複数の部分の前記実行を指定する前記ログ記録を生成すること
    を含む、生成することと
    を含む動作を実行するために１つ又は複数の処理デバイスによって実行可能である、１つ又は複数の機械可読ハードウェア記憶装置。

Images