一般態様1では、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を特定するためのデータ処理システムによって実施される方法であって、仕様が実行可能論理を表し、仕様がキーと関連付けられ、仕様の状態がキーのそれぞれの値に対して維持される、方法であり、実行可能論理を表す仕様にアクセスすることであって、キーの特定の値に対する仕様の状態が、その状態で実行可能な実行可能論理の1つ又は複数の部分を指定する、アクセスすることと、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、1つ又は複数のデータアイテムの各々が、キーの所定の値と関連付けられる、受信することと、キーの所定の値に対するログ記録を生成することであって、ログ記録が、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を指定する、生成することであり、キーの所定の値と関連付けられる1つ又は複数のデータアイテムの各々に対し、そのデータアイテムと関連付けられたキーの所定の値に対して維持される仕様の所定の状態を特定すること、データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、仕様の特定された所定の状態で指定された実行可能論理の1つ又は複数の部分を実行することを含む、処理すること、及び、キーのその所定の値に対する実行可能論理のそれらの1つ又は複数の部分の実行を指定するログ記録を生成することを含む、生成することとを含む、方法について説明する。
態様1による態様2では、方法は、ログ記録をキー別に分類することであって、第1のキーと関連付けられた第1のログ記録が、第1のグループに分類され、第2のキーと関連付けられた第2のログ記録が、第2のグループに分類される、分類することをさらに含む。
態様1又は2による態様3では、ログ記録は、メモリにおいて分類される。
態様1〜3のいずれか1つによる態様4では、各ログ記録は、データアイテムの処理の1つ又は複数の属性を示す1つ又は複数のフィールドを含み、少なくとも1つのログ記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。
態様1〜4のいずれか1つによる態様5では、特定のキーと関連付けられたログ記録のサブセットは、キーフィールドを含まない。
態様1〜5のいずれか1つによる態様6では、特定のキーと関連付けられたログ記録のうち、たった1つのログ記録しかキーフィールドを含まない。
態様1〜6のいずれか1つによる態様7では、方法は、事前に定義された時間間隔の終了時に、特定のキーと関連付けられた特定のグループのログ記録をファイルに書き込むことをさらに含む。
態様1〜7のいずれか1つによる態様8では、方法は、ファイルを再フォーマットすることと、再フォーマット済みのファイルをインデックス付き圧縮フラットファイル(ICFF)に書き込むことと、キー別にインデックスにおいてICFFのインデックスを生成することとをさらに含む。
態様1〜8のいずれか1つによる態様9では、仕様は、多数のノードを有するチャートを含み、各ノードは、実行可能論理の1つ又は複数の部分を表し、チャートは、実行可能なものであり、チャートの実行により、実行可能論理の複数の部分が実行され、方法は、ログ記録に基づいて、1つ又は複数のデータアイテムを処理する際にチャートの1つ又は複数のノードを通じて走査をトレースすることをさらに含む。
態様1〜9のいずれか1つによる態様10では、方法は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを特定するために、ログ記録を構文解析することをさらに含む。
態様1〜10のいずれか1つによる態様11では、ログ記録は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを指定する。
態様1〜11のいずれか1つによる態様12では、方法は、ユーザ起動によるノードのうちの1つの選択を受信することと、選択を受信することに応答して、選択されたノードによって表される実行可能論理の1つ又は複数の部分をユーザが構成するための構成手段を提供する構成エリアをグラフィカルユーザインタフェース上に表示させることであって、構成手段が、監査を有効化及び無効化するための手段を含む、表示することと、構成手段を介してユーザ起動による監査の有効化を受信し、選択されたノードと関連付けられたログ記録を生成させることとを含む。
態様1〜12のいずれか1つによる態様13では、キーのその所定の値に対する実行可能論理のそれらの1つ又は複数の部分の実行を指定するログ記録を生成することは、生成されたログ記録において、実行可能論理のそれらの1つ又は複数の部分の実行の結果を指定すること、実行可能論理のそれらの1つ又は複数の部分が実行され次第読み取られるか又は設定される変数を指定すること、或いは、実行される実行可能論理のそれらの1つ又は複数の部分を特定することを含む。
態様1〜13のいずれか1つによる態様14では、方法は、実行可能論理の1つ又は複数の部分を実行することに応答して、コンピューティングシステムによって実行予定のアクションを開始することをさらに含む。
態様1〜14のいずれか1つによる態様15では、アクションは、実行可能論理の1つ又は複数の部分の実行の実行特性に基づいて、実行可能論理の1つ又は複数の部分の実行のための追加の演算資源を要求することを含む。
態様1〜15のいずれか1つによる態様16では、方法は、各状態に対して実行可能論理のどの部分が現在実行されているかを示す状態データをデータリポジトリ又はインメモリデータグリッドに格納することによって、状態を維持することをさらに含む。
態様1〜16のいずれか1つによる態様17では、方法は、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムの処理の完了に応答して、キーのその値に対する現在の状態を指定するために、状態データを更新することをさらに含む。
態様1〜17のいずれか1つによる態様18では、方法は、チャートのどのノードを走査するか及びデータアイテム別に走査ノードを何回走査するかを示すメトリクスを動的に決定することをさらに含む。
態様1〜18のいずれか1つによる態様19では、方法は、チャートを通じて取った経路を文書化するログ記録のストリームを生成することと、生成されたログ記録を変換することと、変換済みのログ記録をリレーショナルデータベース又はインデックス付き圧縮フラットファイルに格納することであって、指定された粒度でログ記録を一括することを含む、格納することとをさらに含む。
態様1〜19のいずれか1つによる態様20では、方法は、ユーザインタフェースを介して、決定されたメトリクスを動的に出力することであって、出力されたメトリクスが、決定されたメトリクスの変更に応答して更新される、出力することをさらに含む。
態様1〜20のいずれか1つによる態様21では、方法は、ストリームの複数のデータアイテムのうちの第1のデータアイテムのユーザ選択を受信することと、複数のデータアイテムのうちの選択された第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分の表示を表示させることとをさらに含む。
態様1〜21のいずれか1つによる態様22では、方法は、現在処理されているストリームの複数のデータアイテムのうちの選択された第1のデータアイテムを既定の参照データアイテムと比較することと、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムが既定の参照データアイテムと一致するかどうかについての表示を出力することとをさらに含む。
態様1〜22のいずれか1つによる態様23では、方法は、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分を既定の参照実行可能論理と比較することと、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分が既定の参照実行可能論理と一致するかどうかについての表示を出力することとをさらに含む。
態様1〜23のいずれか1つによる態様24では、ログ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第1のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第2のフィールドとを有する構造化データ記録である。
態様1〜24のいずれか1つによる態様25では、ログ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する構造化データ記録である。
態様1〜25のいずれか1つによる態様26では、仕様はチャートであり、1つ又は複数のログ記録は、キーの特定の値と関連付けられた1つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。
態様1〜26のいずれか1つによる態様27では、方法は、1つ又は複数のデータアイテムの処理に基づいて1つ又は複数の出力記録を生成することであって、1つ又は複数の出力記録の各々が、ログ記録に含まれないデータを含む、生成することをさらに含む。
一般態様28では、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を特定するためのデータ処理システムであって、仕様が実行可能論理を表し、仕様がキーと関連付けられ、仕様の状態がキーのそれぞれの値に対して維持される、データ処理システムであり、1つ又は複数の処理デバイスと、命令を格納する1つ又は複数の機械可読ハードウェア記憶装置とを含む、データ処理システムであり、命令が、実行可能論理を表す仕様にアクセスすることであって、キーの特定の値に対する仕様の状態が、その状態で実行可能な実行可能論理の1つ又は複数の部分を指定する、アクセスすることと、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、1つ又は複数のデータアイテムの各々が、キーの所定の値と関連付けられる、受信することと、キーの所定の値に対するログ記録を生成することであって、ログ記録が、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を指定する、生成することであり、キーの所定の値と関連付けられる1つ又は複数のデータアイテムの各々に対し、そのデータアイテムと関連付けられたキーの所定の値に対して維持される仕様の所定の状態を特定すること、データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、仕様の特定された所定の状態で指定された実行可能論理の1つ又は複数の部分を実行することを含む、処理すること、及び、キーのその所定の値に対する実行可能論理のそれらの1つ又は複数の部分の実行を指定するログ記録を生成することを含む、生成することとを含む動作を実行するために1つ又は複数の処理デバイスによって実行可能である、データ処理システムについて説明する。
態様28による態様29では、動作は、ログ記録をキー別に分類することであって、第1のキーと関連付けられた第1のログ記録が、第1のグループに分類され、第2のキーと関連付けられた第2のログ記録が、第2のグループに分類される、分類することをさらに含む。
態様28又は29による態様30では、ログ記録は、メモリにおいて分類される。
態様28〜30のいずれか1つによる態様31では、各ログ記録は、データアイテムの処理の1つ又は複数の属性を示す1つ又は複数のフィールドを含み、少なくとも1つのログ記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。
態様28〜31のいずれか1つによる態様32では、特定のキーと関連付けられたログ記録のサブセットは、キーフィールドを含まない。
態様28〜32のいずれか1つによる態様33では、特定のキーと関連付けられたログ記録のうち、たった1つのログ記録しかキーフィールドを含まない。
態様28〜33のいずれか1つによる態様34では、動作は、事前に定義された時間間隔の終了時に、特定のキーと関連付けられた特定のグループのログ記録をファイルに書き込むことをさらに含む。
態様28〜34のいずれか1つによる態様35では、動作は、ファイルを再フォーマットすることと、再フォーマット済みのファイルをインデックス付き圧縮フラットファイル(ICFF)に書き込むことと、キー別にインデックスにおいてICFFのインデックスを生成することとをさらに含む。
態様28〜35のいずれか1つによる態様36では、仕様は、多数のノードを有するチャートを含み、各ノードは、実行可能論理の1つ又は複数の部分を表し、チャートは、実行可能なものであり、チャートの実行により、実行可能論理の複数の部分が実行され、動作は、ログ記録に基づいて、1つ又は複数のデータアイテムを処理する際にチャートの1つ又は複数のノードを通じて走査をトレースすることをさらに含む。
態様28〜36のいずれか1つによる態様37では、動作は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを特定するために、ログ記録を構文解析することをさらに含む。
態様28〜37のいずれか1つによる態様38では、ログ記録は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを指定する。
態様28〜38のいずれか1つによる態様39では、動作は、ユーザ起動によるノードのうちの1つの選択を受信することと、選択を受信することに応答して、選択されたノードによって表される実行可能論理の1つ又は複数の部分をユーザが構成するための構成手段を提供する構成エリアをグラフィカルユーザインタフェース上に表示させることであって、構成手段が、監査を有効化及び無効化するための手段を含む、表示することと、構成手段を介してユーザ起動による監査の有効化を受信し、選択されたノードと関連付けられたログ記録を生成させることとをさらに含む。
態様28〜39のいずれか1つによる態様40では、キーのその所定の値に対する実行可能論理のそれらの1つ又は複数の部分の実行を指定するログ記録を生成することは、生成されたログ記録において、実行可能論理のそれらの1つ又は複数の部分の実行の結果を指定すること、実行可能論理のそれらの1つ又は複数の部分が実行され次第読み取られるか又は設定される変数を指定すること、或いは、実行される実行可能論理のそれらの1つ又は複数の部分を特定することを含む。
態様28〜40のいずれか1つによる態様41では、動作は、実行可能論理の1つ又は複数の部分を実行することに応答して、コンピューティングシステムによって実行予定のアクションを開始することをさらに含む。
態様28〜41のいずれか1つによる態様42では、アクションは、実行可能論理の1つ又は複数の部分の実行の実行特性に基づいて、実行可能論理の1つ又は複数の部分の実行のための追加の演算資源を要求することを含む。
態様28〜42のいずれか1つによる態様43では、動作は、各状態に対して実行可能論理のどの部分が現在実行されているかを示す状態データをデータリポジトリ又はインメモリデータグリッドに格納することによって、状態を維持することをさらに含む。
態様28〜43のいずれか1つによる態様44では、動作は、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムの処理の完了に応答して、キーのその値に対する現在の状態を指定するために、状態データを更新することをさらに含む。
態様28〜44のいずれか1つによる態様45では、動作は、チャートのどのノードを走査するか及びデータアイテム別に走査ノードを何回走査するかを示すメトリクスを動的に決定することをさらに含む。
態様28〜45のいずれか1つによる態様46では、動作は、チャートを通じて取った経路を文書化するログ記録のストリームを生成することと、生成されたログ記録を変換することと、変換済みのログ記録をリレーショナルデータベース又はインデックス付き圧縮フラットファイルに格納することであって、指定された粒度でログ記録を一括することを含む、格納することとをさらに含む。
態様28〜46のいずれか1つによる態様47では、動作は、ユーザインタフェースを介して、決定されたメトリクスを動的に出力することであって、出力されたメトリクスが、決定されたメトリクスの変更に応答して更新される、出力することをさらに含む。
態様28〜47のいずれか1つによる態様48では、動作は、ストリームの複数のデータアイテムのうちの第1のデータアイテムのユーザ選択を受信することと、複数のデータアイテムのうちの選択された第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分の表示を表示させることとをさらに含む。
態様28〜48のいずれか1つによる態様49では、動作は、現在処理されているストリームの複数のデータアイテムのうちの選択された第1のデータアイテムを既定の参照データアイテムと比較することと、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムが既定の参照データアイテムと一致するかどうかについての表示を出力することとをさらに含む。
態様28〜49のいずれか1つによる態様50では、動作は、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分を既定の参照実行可能論理と比較することと、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分が既定の参照実行可能論理と一致するかどうかについての表示を出力することとをさらに含む。
態様28〜50のいずれか1つによる態様51では、ログ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第1のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第2のフィールドとを有する構造化データ記録である。
態様28〜51のいずれか1つによる態様52では、ログ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する構造化データ記録である。
態様28〜52のいずれか1つによる態様53では、仕様はチャートであり、1つ又は複数のログ記録は、キーの特定の値と関連付けられた1つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。
態様28〜53のいずれか1つによる態様54では、動作は、1つ又は複数のデータアイテムの処理に基づいて1つ又は複数の出力記録を生成することであって、1つ又は複数の出力記録の各々が、ログ記録に含まれないデータを含む、生成することをさらに含む。
一般態様55では、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を特定するための1つ又は複数の機械可読ハードウェア記憶装置であって、仕様が実行可能論理を表し、仕様がキーと関連付けられ、仕様の状態がキーのそれぞれの値に対して維持される、1つ又は複数の機械可読ハードウェア記憶装置であり、命令を格納する1つ又は複数の機械可読ハードウェア記憶装置であり、命令が、実行可能論理を表す仕様にアクセスすることであって、キーの特定の値に対する仕様の状態が、その状態で実行可能な実行可能論理の1つ又は複数の部分を指定する、アクセスすることと、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信することであって、1つ又は複数のデータアイテムの各々が、キーの所定の値と関連付けられる、受信することと、キーの所定の値に対するログ記録を生成することであって、ログ記録が、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を指定する、生成することであり、キーの所定の値と関連付けられる1つ又は複数のデータアイテムの各々に対し、そのデータアイテムと関連付けられたキーの所定の値に対して維持される仕様の所定の状態を特定すること、データ処理システムによって、そのデータアイテムを処理することであって、そのデータアイテムにおいて、仕様の特定された所定の状態で指定された実行可能論理の1つ又は複数の部分を実行することを含む、処理すること、及び、キーのその所定の値に対する実行可能論理のそれらの1つ又は複数の部分の実行を指定するログ記録を生成することを含む、生成することとを含む動作を実行するために1つ又は複数の処理デバイスによって実行可能である、1つ又は複数の機械可読ハードウェア記憶装置について説明する。
態様55による態様56では、動作は、ログ記録をキー別に分類することであって、第1のキーと関連付けられた第1のログ記録が、第1のグループに分類され、第2のキーと関連付けられた第2のログ記録が、第2のグループに分類される、分類することをさらに含む。
態様55又は56による態様57では、ログ記録は、メモリにおいて分類される。
態様55〜57のいずれか1つによる態様58では、各ログ記録は、データアイテムの処理の1つ又は複数の属性を示す1つ又は複数のフィールドを含み、少なくとも1つのログ記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。
態様55〜58のいずれか1つによる態様59では、特定のキーと関連付けられたログ記録のサブセットは、キーフィールドを含まない。
態様55〜59のいずれか1つによる態様60では、特定のキーと関連付けられたログ記録のうち、たった1つのログ記録しかキーフィールドを含まない。
態様55〜60のいずれか1つによる態様61では、動作は、事前に定義された時間間隔の終了時に、特定のキーと関連付けられた特定のグループのログ記録をファイルに書き込むことをさらに含む。
態様55〜61のいずれか1つによる態様62では、動作は、ファイルを再フォーマットすることと、再フォーマット済みのファイルをインデックス付き圧縮フラットファイル(ICFF)に書き込むことと、キー別にインデックスにおいてICFFのインデックスを生成することとをさらに含む。
態様55〜62のいずれか1つによる態様63では、仕様は、多数のノードを有するチャートを含み、各ノードは、実行可能論理の1つ又は複数の部分を表し、チャートは、実行可能なものであり、チャートの実行により、実行可能論理の複数の部分が実行され、動作は、ログ記録に基づいて、1つ又は複数のデータアイテムを処理する際にチャートの1つ又は複数のノードを通じて走査をトレースすることをさらに含む。
態様55〜63のいずれか1つによる態様64では、動作は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを特定するために、ログ記録を構文解析することをさらに含む。
態様55〜64のいずれか1つによる態様65では、ログ記録は、チャートのどのノードを走査し且つチャートのどのノードを走査しないかを指定する。
態様55〜65のいずれか1つによる態様66では、動作は、ユーザ起動によるノードのうちの1つの選択を受信することと、選択を受信することに応答して、選択されたノードによって表される実行可能論理の1つ又は複数の部分をユーザが構成するための構成手段を提供する構成エリアをグラフィカルユーザインタフェース上に表示させることであって、構成手段が、監査を有効化及び無効化するための手段を含む、表示することと、構成手段を介してユーザ起動による監査の有効化を受信し、選択されたノードと関連付けられたログ記録を生成させることとをさらに含む。
態様55〜66のいずれか1つによる態様67では、キーのその所定の値に対する実行可能論理のそれらの1つ又は複数の部分の実行を指定するログ記録を生成することは、生成されたログ記録において、実行可能論理のそれらの1つ又は複数の部分の実行の結果を指定すること、実行可能論理のそれらの1つ又は複数の部分が実行され次第読み取られるか又は設定される変数を指定すること、或いは、実行される実行可能論理のそれらの1つ又は複数の部分を特定することを含む。
態様55〜67のいずれか1つによる態様68では、動作は、実行可能論理の1つ又は複数の部分を実行することに応答して、コンピューティングシステムによって実行予定のアクションを開始することをさらに含む。
態様55〜68のいずれか1つによる態様69では、アクションは、実行可能論理の1つ又は複数の部分の実行の実行特性に基づいて、実行可能論理の1つ又は複数の部分の実行のための追加の演算資源を要求することを含む。
態様55〜69のいずれか1つによる態様70では、動作は、各状態に対して実行可能論理のどの部分が現在実行されているかを示す状態データをデータリポジトリ又はインメモリデータグリッドに格納することによって、状態を維持することをさらに含む。
態様55〜70のいずれか1つによる態様71では、動作は、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムの処理の完了に応答して、キーのその値に対する現在の状態を指定するために、状態データを更新することをさらに含む。
態様55〜71のいずれか1つによる態様72では、動作は、チャートのどのノードを走査するか及びデータアイテム別に走査ノードを何回走査するかを示すメトリクスを動的に決定することをさらに含む。
態様55〜72のいずれか1つによる態様73では、動作は、チャートを通じて取った経路を文書化するログ記録のストリームを生成することと、生成されたログ記録を変換することと、変換済みのログ記録をリレーショナルデータベース又はインデックス付き圧縮フラットファイルに格納することであって、指定された粒度でログ記録を一括することを含む、格納することとをさらに含む。
態様55〜73のいずれか1つによる態様74では、動作は、ユーザインタフェースを介して、決定されたメトリクスを動的に出力することであって、出力されたメトリクスが、決定されたメトリクスの変更に応答して更新される、出力することをさらに含む。
態様55〜74のいずれか1つによる態様75では、動作は、ストリームの複数のデータアイテムのうちの第1のデータアイテムのユーザ選択を受信することと、複数のデータアイテムのうちの選択された第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分の表示を表示させることとをさらに含む。
態様55〜75のいずれか1つによる態様76では、動作は、現在処理されているストリームの複数のデータアイテムのうちの選択された第1のデータアイテムを既定の参照データアイテムと比較することと、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムと既定の参照データアイテムとの間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、現在処理されているストリームの複数のデータアイテムのうちの第1のデータアイテムが既定の参照データアイテムと一致するかどうかについての表示を出力することとをさらに含む。
態様55〜76のいずれか1つによる態様77では、動作は、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分を既定の参照実行可能論理と比較することと、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかを判断することと、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分と既定の参照実行可能論理との間の偏差が存在するか又はそのような偏差が存在しないかの判断に基づいて、複数のデータアイテムのうちの第1のデータアイテムにおいて現在実行されている実行可能論理の1つ又は複数の部分が既定の参照実行可能論理と一致するかどうかについての表示を出力することとをさらに含む。
態様55〜77のいずれか1つによる態様78では、ログ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第1のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第2のフィールドとを有する構造化データ記録である。
態様55〜78のいずれか1つによる態様79では、ログ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する構造化データ記録である。
態様55〜79のいずれか1つによる態様80では、仕様はチャートであり、1つ又は複数のログ記録は、キーの特定の値と関連付けられた1つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。
態様55〜80のいずれか1つによる態様81では、動作は、1つ又は複数のデータアイテムの処理に基づいて1つ又は複数の出力記録を生成することであって、1つ又は複数の出力記録の各々が、ログ記録に含まれないデータを含む、生成することをさらに含む。
上記の態様は、以下の利点のうちの1つ又は複数を含み得る。
本明細書で説明されるロギングシステムは、システム資源(メモリ及び処理能力など)への影響を最小限に抑えながらログ記録を処理することができる。それに加えて、本明細書で説明されるシステムは、レイテンシを低減しながらこれらのログ記録を処理する。実行可能論理の実行のメトリクスは、ユーザがこれらのメトリクスをリアルタイムで追跡できるように、動的に決定及び出力される。その上、ユーザは、余分なデータ量の生成を低減しながら、対象の部分にロギングの焦点を置くためにどの実行可能論理ログ記録を生成するかを制御することができる。これにより、ユーザは、根本的なデータ処理システムを理解する、追跡する及び正しく動作する上で手助けが得られる。
本発明の他の特徴及び利点は、以下の説明から及び特許請求の範囲から明らかになるであろう。
図1を参照すると、ロギング用のシステム10は、データソース12を含み、データソース12は、記憶装置又はオンラインデータストリームへの接続などのデータの1つ又は複数のソースを含み得、1つ又は複数のソースの各々は、様々な格納フォーマット(例えば、データベーステーブル、スプレッドシートファイル、フラットテキストファイル又はメインフレームによって使用されるネイティブフォーマット)のいずれでもデータを格納することができる。実行環境14(例えば、データ処理システム)は、実行モジュール16及びユーザインタフェースモジュール22を含む。実行環境14は、適切なオペレーティングシステム(UNIX(登録商標)オペレーティングシステムなど)の制御下で1つ又は複数のコンピュータをホストとし得る。例えば、実行環境14は、複数ノード並列コンピューティング環境を含み得、複数ノード並列コンピューティング環境は、複数の中央処理装置(CPU)を使用したコンピュータシステムの構成を含み、ローカル接続(例えば、SMPコンピュータなどのマルチプロセッサシステム)又はローカル分散されるか(例えば、クラスタ若しくはMPPとして結合された複数のプロセッサ)、リモート接続又はリモート分散されるか(例えば、LAN若しくはWANネットワークを介して結合された複数のプロセッサ)、或いは、それらの任意の組合せのものである。
実行モジュール16は、コンピュータプログラムによってデータ記録(本明細書では、「データアイテム」とも呼ばれる)が処理される対象となる一意的なキー(例えば、識別子(ID))の各々に対する、コンピュータプログラム(例えば、その全内容が参照により本明細書に組み込まれる「Executing Computations Expressed as Graphs」と称する米国特許第米国特許5,966,072号明細書で説明されるようなデータフローグラフなどのチャート)の状態及びコンピュータプログラムを通じてデータが取った経路についての詳細を提供するロギング(例えば、チャートロギング)を実施する。いくつかの例では、実行モジュール16は、その全内容が参照により本明細書に組み込まれる米国特許出願公開第2009/0327196号明細書で説明されるようなグラフベースの演算において、データロギングを実施する。この出願では、「データフローグラフ」又は「チャート」という用語は、「コンピュータプログラム」の例として又は「コンピュータプログラム」に対する他の言葉として使用される。いくつかの例では、「データフローグラフ」及び「チャート」という用語は、本明細書では、便宜上、互いに交換可能に且つ区別なく使用される。いくつかの例では、一意的なキーは、チャートによって記録が処理される対象となる各顧客用の顧客IDを表す。ユーザインタフェースモジュール22は、ロギング情報(例えば、チャートのどの部分を走査するかを示すメトリクス及び記録のグループ別にチャートの特定の部分を何回走査するかを示す集計メトリクス)を表示する。この仕様全体を通じて説明されるメトリクスは、動的に(すなわち、実行可能論理の実行の間に)決定することができる。この例では、チャート(例えば、データフローグラフ)は、データ記憶装置26に格納することができる。データソース12を提供する記憶装置は、実行環境14にローカル接続されても(例えば、実行環境14を起動しているコンピュータに接続された記憶媒体(例えば、ハードディスク18)上に格納する)、実行環境14にリモート接続されてもよい(例えば、ローカルエリア又は広域データネットワーク上で実行環境14を起動しているコンピュータと連通するリモートシステム(例えば、メインフレーム20)をホストとする)。
実行環境14は、1つ又は複数のユーザインタフェースを表示するためにユーザインタフェースモジュール22によって使用されるデータを格納するデータ記憶装置26と連通する。また、データ記憶装置26は、データ記憶装置26に格納されたユーザインタフェース及びチャート(ロギング機能を有する)を開発するための開発環境28(例えば、任意選択であり得る)にもアクセスすることができ、ユーザインタフェース及びチャートは、実行モジュール16によってアクセスされ(チャートを実行する際)、ユーザインタフェースを表示するためにユーザインタフェースモジュール22によって使用される。
いくつかの例では、チャート又はデータフローグラフは、1つ又は複数のデータソースからのデータを処理するデータフローグラフ実行環境内で実行されるコンピュータプログラムである。データソースからのデータは、コンピュータプログラムに従って操作及び処理され、1つ又は複数のデータシンクにエクスポートされる。データソース及びシンクは、例えば、ファイル、データベース、データストリーム又はキューを含み得る。データフローグラフは、有向グラフとして表され、有向グラフは、データ処理コンポーネントを表すノード(各々が少なくとも1つのデータ入力からのデータを処理するため及び少なくとも1つのデータ出力にデータを提供するためのプログラムコード(例えば、実行可能論理)を含む)と、データソース及び/又はシンクにアクセスするためのデータセットオブジェクトを表すノードとを含む。ノードは、コンポーネント間のデータのフローを表す有向リンクによって接続され、有向リンクは、データソースを始点とし、データシンクを終点とする。上流のコンポーネントのデータ出力ポートは、下流のコンポーネントのデータ入力ポートに接続される。データフローグラフは、データセットオブジェクトによって表される異なるデータソース及び異なるデータシンクに対して再利用することができる。データフローグラフを実施するために使用されるデータ構造及びプログラムコードは、例えば、異なるソース又はシンクを容易に代用できるようにするために、例えば、パラメータ化することによって、複数の異なる構成をサポートすることができる。その上、いくつかの構成では、データフローグラフにおけるデータのフローは、コンポーネントのうちの1つ又は一連のコンポーネントをバイパスできるように、パラメータを使用することによって変更することができる。一般に、パラメータは、データフローグラフのコンポーネントの特性を表し、その特性は、値で構成することができ、且つ、その値を変更することができる。例えば、そのような特性は、データフローグラフの使用の合間に変更することができ、その変更の結果、データフローグラフは、異なる形で動作を実行することができる。
データフローグラフの構築は、いくつかの事例では、本質的には、高度に技術的なものであり得る。特有のビジネス目的を達成するために記載しているが、グラフの根本的な構造及び構築は、技術的考慮点に基づいて決定される。例えば、グラフのコンポーネントは、再利用性を最大化するか又は並列処理をサポートするように選択することができる。他方では、どのように及びどこでグラフを使用するかは、ビジネス上の決定であることが多い。そのようなパラメータ化されたデータフローグラフと関連付けられたパラメータのいくつかは、ユーザがその実装形態の背後にある技術的複雑性を理解する必要なしに、ビジネスユーザがデータフローグラフをカスタマイズできるようにするために使用することができる。パラメータ化されたデータフローグラフは、カスタマイゼーションを簡略化し、再利用を容易にする。
言い換えれば、図1に示されるコンピュータシステム10は、データ記憶装置26に結合された任意選択の開発環境28であって、チャート又はデータフローグラフと関連付けられたコンピュータプログラムを構築するように構成された開発環境28であり、チャート又はデータフローグラフが、データ処理コンポーネントのチャート又はグラフを通じて1つ又は複数の入力データセットから1つ又は複数の出力データセットに流れるデータにおいて実行される演算を実施し、チャート又はデータフローグラフが、データ記憶装置26内のデータ構造によって指定され、チャート又はデータフローグラフが、多数のノードを有し、多数のノードが、データ構造によって指定され、1つ又は複数のリンクによって接続されたデータ処理コンポーネントを表し、リンクが、データ構造によって指定され、データ処理コンポーネント間のデータフローを表す、開発環境28と、データ記憶装置26に結合された実行環境14であって、1つ又は複数のコンピュータをホストとする実行環境14であり、実行モジュール16を含む実行環境14であり、実行モジュール16が、チャート又はデータフローグラフを指定する格納されたデータ構造を読み取り、実行モジュール16によってチャート又はデータフローグラフに割り当てられたデータ処理コンポーネントの演算を実行するために演算資源の割り当て及び構成を行うように構成され、実行モジュール16が、本明細書で説明される方法又はプロセスのいずれか1つが実行されるようにデータ処理コンポーネントの割り当てられた演算の実行のスケジューリング及び制御を行うように構成される、実行環境14とを含み得る。
以下でさらに詳細に説明されるように、図2A〜2Dは、フローチャートを通じる進行を示し、フローチャートの様々な状態で様々なノードが実行されることを示す。図2E〜2Gは、様々な状態で生成される様々な監査記録を示す。
図2Aを参照すると、略図29aは、データ処理コンポーネントを表すノード32a〜32gを有するそのフローチャート32を含む仕様30を示す。一般に、仕様は、実行可能論理を表し、様々な状態を指定するものであり、仕様の状態は、以前のデータアイテムにおける実行可能論理の実行から達した状態に基づいて、その状態で実行可能な実行可能論理の1つ又は複数の部分を指定する。一般に、実行可能論理は、ソースコード及び他のコンピュータ命令を含む。この例では、1つ又は複数のデータ処理コンポーネントは、実行可能論理の特定の分類又は部分を指す。一般に、チャートは、データ記録を処理するためのテンプレートを含む。このテンプレートは、グラフィック論理ユニットを含み、グラフィック論理ユニットは、入力データ記録に対処し、出力データ記録(例えば、仕様に含まれる論理に基づいて生成されたデータ記録)を生成するためのものである。チャートは、仕様の例である。一般に、グラフィック論理ユニットは、グラフ上で少なくとも部分的に生成された(例えば、チャートを構築するためのテンプレート(図示せず)からウィンドウへの様々なノードのドラッグ・アンド・ドロップによって)論理を含む。例では、ノードは、論理(図示せず)を含み、論理は、入力データ記録をどのように処理するか、実行可能論理によって使用される変数に対する値をどのように設定するか、どの出力データ記録を生成するか(例えば、論理によって指定される条件が満たされ次第)などを指定する。例では、ノードは、ノードの論理において使用されるパラメータの値及び/又は変数の値をユーザが入力することによって、プログラム可能である。
ノードの論理は実行可能論理にコンパイルされるため、及び、各ノードはその実行可能論理の1つ又は複数の部分に対応するため、チャート自体は実行可能なものである。例えば、システムは、ノードの論理を実行可能論理にコンパイルすることによって、仕様(及び/又は仕様のチャート)を変換する。チャート自体が実行可能なものであるため、チャート自体は、データ記録の処理や、停止、開始及び中止が可能である。また、システムは、例えば、ノード32a〜32gのうちのどのノードが現在実行されているかを追跡することによって、フローチャート32の状態を維持する。フローチャート32の状態は、フローチャート32によって表される実行可能論理の状態に相当する。例えば、フローチャート32の各ノードは、実行可能論理の特定の状態(実行可能論理の1つ又は複数の部分はその状態で実行可能である)を表す。以下でさらに詳細に説明されるように、キーの多くの値に対してフローチャート32が実行されている際、システムは、例えば、各インスタンスに対して状態を維持することによって、キーの各値に対してフローチャート32の状態を維持する。一般に、仕様のインスタンスは、キーの一意的な値に対する仕様の特有の実現(例えば、仕様において表される実行可能論理の実行及びキーの一意的な値の各々に対する実行可能論理の状態の維持による)を含む。この例では、フローチャート32は、状態遷移図を含み、状態遷移図では、各受信データ記録は、ノード間の遷移を推進し、データ記録は、以前のデータ記録の処理から達した状態に基づいて評価される。フローチャート32のノード間のリンクは、論理の時間的な流れを表す。
また、仕様30は、キー32hも含み、キー32hは、キー32hを含むか又はキー32hと関連付けられたデータ記録をフローチャート32が処理することを特定する。この例では、カスタム識別子(ID)がキーとして使用される。キー32hは、データ記録のフィールドのうちの1つ(例えば、サービス加入者_IDフィールド、顧客_IDフィールド、セッション_IDフィールドなど)に対応し得る。この例では、顧客_IDフィールドがキーフィールドである。特定のデータ記録に対し、システムは、そのデータ記録に対するキーフィールドの値を特定することによって、そのデータ記録に対するキーの値を決定する。
この例では、フローチャート32は、指定されたタイプの(例えば、フローチャート32が構成される際に指定された)ものであるデータ記録を購読する。この例では、フローチャート32は、キー32hを含むデータ記録を購読する。この例では、フローチャート32とデータ記録は、キーを共有する。一般に、フローチャートは、フローチャートのキーを含むそれらのデータ記録を処理するために論理を含めることによってデータ記録のタイプを購読する。データ記録処理が始まると、システムは、例えば、キーの新しい値の各々に対する実行可能論理の状態(フローチャートにおいて表される)を維持することによって、そのフローチャートに対するキーの新しい値の各々に対する新しいフローチャートインスタンスを開始する。一般に、フローチャートインスタンスは、キーの一意的な値に対するフローチャートの特有の実現(例えば、仕様において表される実行可能論理の実行及びキーの一意的な値の各々に対する実行可能論理の状態の維持による)を含む。システムは、特定のキー値に対するデータ記録に対処するために、フローチャートインスタンス(延いては根本的な実行可能論理)を構成することによって、データ記録処理を実行する。例では、フローチャートは、顧客ショートメッセージサービス(SMS)データ記録を購読する。特定の顧客IDに対するフローチャートインスタンスは、その顧客のデータ記録を管理する。受信データ記録において遭遇する顧客IDと同数のフローチャートインスタンスが存在し得る。
図2Bを参照すると、略図29bは、フローチャート32の実行の開始を示す。この例では、ノード32aは、実行可能論理の開始を表すものであり、現在実行されている(例えば、ノード32aの周りの太線によって示されるように)。この例では、フローチャート32は、ノード32aが実行されている状態である。図2Cを参照すると、略図29cは、ノード32aの完了に続くフローチャート32の状態を示す。この例では、フローチャート32の状態は、ノード32bに遷移し、ノード32bは、実行可能論理の1つ又は複数の他の部分を表す。ノード32bは、待機ノード(以下では、待機ノード32bと呼ばれる)を含む。待機ノード32bは、入力データ記録が1つ又は複数の条件を満たすまで実行可能論理の一部分(待機ノード32bに対応する)が待つという待機状態を表す。例では、待機状態は、フローチャート32の別の状態(例えば、システムが待機ノードを実行し(待機状態を実施するため)、次いで、1つ又は複数の他のノードを実行する状態)の一部であり得る。待機ノード32bによって表される実行可能論理の部分の完了に続いて、システムは、待機状態を終了し、ノード32cを実行する。ノード32cは、決定を実施するための実行可能論理を表す。この例では、ノード32cは、決定ノードを含む。以下では、ノード32cは、決定ノード32cと呼ばれる。一般に、決定ノードは、決定の実行用の論理(例えば、ブール値に評価する論理)を含むノードを含む。
図2Dを参照すると、略図29dは、ノード32cによって表される決定の結果に基づくフローチャート32の状態を示す。具体的には、ノード32cによって表される決定の結果に基づいて、フローチャート32の状態は、別の待機ノードであるノード32dに遷移する。(変形形態では、フローチャート32の状態は、ノード32gに遷移することがあり得る(それにより、状態は、ノード32aに戻る))。待機ノード32dによって表される実行可能論理の部分の完了に続いて、フローチャート32の状態は、送信ノードを含むノード32eに遷移する。一般に、送信ノードは、別のシステムへのデータ送信を引き起こすための実行可能論理を表すノードを含む。ノード32eによって表される実行可能論理の部分の実行の完了に続いて、フローチャート32の状態は、終了ノードを含むノード32fに遷移する。一般に、終了ノードは、実行可能論理の実行が完了したことを表す。
この例では、フローチャート32は、2つの状態を含み、第1の状態は、ノード32b、32c、32gによって表され、第2の状態は、ノード32d、32e、32fによって表される。この第1の状態では、システムは、特定のデータ記録を待ち(ノード32bによって表されるように)、次いで、ノード32cを実行し、これを受けて、第2の状態(その開始は、ノード32dによって表される)への遷移(仕様30及び/又はチャート32の遷移)が起こるか、又は、ノード32gの実行が起こる。第2の状態になった時点で、システムは、再び、特定のデータ記録を待ち(ノード32dによって表されるように)、次いで、ノード32e及びノード32fを実行する。待機ノード以外のノードを含めることにより、フローチャート32は、データ記録の時間的な処理の論理グラフを含む。
図2Eを参照すると、略図29eは、フローチャート32の開始状態を示し、開始状態では、開始ノード32aが実行され次第、監査記録が生成される。具体的には、開始ノード32aは、この例で示されるように、例えば、フローチャート32が、開始ノード32aが実行されている状態である際に、監査記録32iを生成するように構成されたデータ処理コンポーネントを表す。一般に、監査記録(又は「ログ記録」とも呼ばれる)は、データアイテム(例えば、データの構造化アイテム)を含み、データアイテムは、データ記録又はイベントを処理する際に走査されるノード(及び/又は実行されるデータ処理コンポーネント)並びにデータ記録又はイベントの処理の1つ又は複数の属性を指定する。いくつかの例では、ログ記録は、構造化データ記録であり、構造化データ記録は、キーの特定の値に対する仕様の状態を表すデータを格納するための第1のフィールドと、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するための第2のフィールドとを有する。この例では、特定のキーに対するデータ記録が処理された時点で、システムは、監査記録(又は1つ若しくは複数の監査記録)を生成し、キーの特定の値に対する仕様の状態を表すデータを第1のフィールドに格納し、キーのその特定の値に対し、実行可能論理の実行が開始された時刻から現在の時刻までに、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを第2のフィールドに格納する。さらなる他の例では、ログ記録は、構造化データ記録であり、構造化データ記録は、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを格納するためのフィールドを有する。この例では、監査記録が生成された時点で、システムは、キーの特定の値に対し、現在の時刻に、仕様によって表される実行可能論理のどの部分が実行されたかを指定するデータを監査記録のフィールドに投入する。さらなる他の例では、仕様はチャートであり、1つ又は複数のログ記録は、キーの特定の値と関連付けられた1つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定する。この例では、システムは、キーの特定の値と関連付けられた1つ又は複数のデータ記録を処理する際に実行可能論理のどの部分が実行されるかを表すチャートを通じる経路を指定するログ記録を生成する。さらなる他の例では、システムは、1つ又は複数のデータアイテムの処理に基づいて1つ又は複数の出力記録を生成する。この例では、1つ又は複数の出力記録の各々は、ログ記録に含まれないデータを含む。
以下でさらに詳細に説明されるように、様々なタイプの監査記録は、様々なフィールドを有するように事前に定義され、各フィールドタイプは、データ記録又はイベントの処理の1つ又は複数の属性を指定する。一般に、イベントは、その特定の発生又は不在を表すデータ記録(例えば、事前に定義されたフォーマットのもの)を含む。この例では、ノード32aは、編集可能なものであり、編集は、例えば、ノード32aをクリックすることによって行うことができ、それにより、ノード(延いてはノードによって表されるデータ処理コンポーネント)を構成する際に使用することができる構成画面が表示される。構成の一部は、監査の有効化(又は「ロギング」とも呼ばれる)及びそのノードが走査され次第生成される予定の1つ又は複数のタイプの監査記録の指定を含み得る。別の例では、本明細書で説明されるシステムは、ユーザインタフェース用のデータを生成し、ユーザインタフェースは、様々なタイプの監査記録の視覚表現を表示し、様々なタイプの監査記録の有効化/無効化の制御を提供する。次いで、この例では、システムは、特定タイプのノード若しくはデータ処理コンポーネントに対応するか又は特定タイプのノード若しくはデータ処理コンポーネントと関連付けられたタイプの監査記録を生成する(例えば、そのタイプの監査記録に対するロギングが使用可能になった際)。例えば、監査記録32iは、チャートの開始を指定するデータのロギングのためのチャート開始監査記録である。従って、チャート開始監査記録を使用可能にすることをユーザが指定した場合は、本明細書で説明されるシステムは、開始ノードがチャートを開始し、且つ、チャート開始監査記録がチャート開始のロギングを行うという事実に基づいて、チャート開始監査記録と開始ノード(例えば、ノード32a)との間の対応を特定し、チャート開始監査記録を生成する。この例では、監査記録32iは、キーフィールド(チャートのインスタンスが作成されるか又はチャートが実行される対象となるキーを指定するための)、チャート32を一意的に識別する識別子を指定するためのチャート_ID及びチャートを開始したことを指定するための「開始」の値を含む。
図2Fを参照すると、略図29fは、フローチャート32の第2の状態を示し、第2の状態では、監査記録32jが生成される。具体的には、決定ノード32cによって表されるデータ処理コンポーネントは、この例で示されるように、例えば、フローチャート32が、決定ノード32cが実行されている状態である際に、監査記録32jを生成するように構成される。(この例では、この状態で待機ノード32bも実行されている。しかし、待機ノード32bは、監査記録を生成するようには構成されていない)。この例では、監査記録32jのうちの1つは、例えば、肯定リンク32を走査するか又は否定リンク32mを走査するかを指定することによって、決定ノード32cの結果を指定する。監査記録32jの他のものは、例えば、決定ノード32cによって表されるデータ処理コンポーネントが実行され次第読み取られるか又は設定される変数を指定することができる。この例では、監査記録32jは、キーフィールドを含む必要はないが、その理由は、監査記録は、指定されたパルス(例えば、時間又は事前に定義された時間間隔)で処理システム(例えば、監査記録を処理する内部又は外部のコンピューティングシステム)に送信され、その結果、監査記録は、グループで、ブロックで又はファイルの一部として送信されるためである。
例えば、システムは、キー別に監査記録を分類し、第1のキーと関連付けられた第1の監査記録は、第1のグループに分類され、第2のキーと関連付けられた第2の監査記録は、第2のグループに分類される。この例では、監査記録は、システム(例えば、システム10)のメモリにおいて分類される。システムは、空間効率のためにメモリにおいて監査記録を分類し、その結果、システムは、例えば、各監査記録にキーを含めることによって、順次関連する監査記録にわたってデータを複製する必要はない。各監査記録は、データアイテムの処理の1つ又は複数の属性を示す1つ又は複数のフィールドを含む。少なくとも1つの監査記録に対し、フィールドは、データアイテムと関連付けられたキーの値を指定するキーフィールドである。監査記録はキー別に分類されるため、特定のキーと関連付けられた監査記録のサブセットは、キーフィールドを含まない。いくつかの例では、特定のキーに対するグループに含まれる監査記録のうち、たった1つの監査記録しかキーフィールドを含まない。この例では、システムは、事前に定義された時間間隔(例えば、パルス)の終了時に、特定のキーと関連付けられた特定のグループの監査記録をファイルに書き込む。
例えば、システムは、第1の監査記録又はチャート開始監査記録のコンテンツを構文解析することによって、グループ(ブロック又はファイルとして表され得る)内の監査記録に対するキーを識別する。すべての監査記録がキーフィールド(及びチャート_IDフィールドなどの他のフィールド(監査記録32iと同じパルスに含まれる他の監査記録によってチャート開始監査記録内を検索することもできる))を含む必要があるわけではないため、本明細書で説明されるシステムは、各監査記録がイベントのキー入力ロギングを可能にするためにキーフィールドを含む必要がある場合のシステム資源への影響と比べて、システム資源(メモリ及び処理能力など)への影響を最小限に抑えながら監査記録を処理することができる。それに加えて、本明細書で説明されるシステムは、各監査記録がキーフィールドを含む必要がないことを理由に監査記録のサイズが低減されるため、各監査記録がキーフィールドを有する監査記録の処理のレイテンシと比べて、レイテンシを低減しながらこれらの監査記録を処理する。それに加えて、システムは、特定のキーに割り当てられたパーティション内(メモリ内)に監査記録を格納するように構成され、それにより、各監査記録がキーフィールドを含む必要性がさらに低減される。新しいパルスの開始時は、本明細書で説明されるシステムは、そのパルスに対するその第1の監査記録にキーフィールドを含むように構成される。
図2Gを参照すると、略図29gは、フローチャート32の第3の状態を示し、第3の状態では、監査記録32kが生成される。具体的には、送信ノード32eは、監査記録32kを生成するようにも構成される。この例では、監査記録32kの少なくとも1つは、送信ノード32eによって表されるデータ処理コンポーネントによって実施されたアクションを指定する。また、監査記録32jと同様に、監査記録32kは、監査記録32iを含むものと同じパルスの一部として送信されるため、監査記録32kもキーフィールドを含む必要がない。監査記録32kの他のものは、アクションが送信された時刻、変数読み取りの値、変数設定の値などを指定することができる。
この例では、システムは、1つ又は複数のデータアイテムを処理する際にチャート32の1つ又は複数のノードを通じて走査をトレースするために、監査記録のコンテンツを構文解析する。それに加えて、システムは、チャート32のどのノードを走査し且つチャート32のどのノードを走査しないか、及び、それらのノードをなぜ走査しないか(例えば、それらのノードに対してどのリンク又は経路を走査しなかったか)を特定するために、監査記録を構文解析する。
図3を参照すると、略図37は、フローチャートインスタンス33、34(例えば、システムによってフローチャート32(図2A)から生成されたもの)及びデータ記録36a、36bのデータアイテムを示す。すなわち、フローチャート32の新しいコピー又はインスタンスは、データ記録36a、36bにおいて検出された新しいキーの各々に対して作成される。
フローチャートインスタンス33、34の各々は、「顧客_id」キーと関連付けられる。フローチャートインスタンス33は、この例ではキーフィールドであるその「顧客_id」フィールドに「VBN3419」の値を含むデータ記録を処理する。フローチャートインスタンス34は、その「顧客_id」フィールドに「CND8954」の値を含むデータ記録を処理する。この例では、システムは、各フローチャートインスタンスに対して実行可能論理を再実行することはしない。むしろ、システムは、実行可能論理を実行し、次いで、キーのそれぞれの値に対する状態を維持することによってフローチャートインスタンスを実施する。それに従って、「データ記録を処理するフローチャートインスタンス」の例は、システムが実行可能論理(フローチャートによって表されるもの)を実行し、キーの各値に対する状態を維持し、キーの特定の値と関連付けられたデータ記録を処理する(キーのその特定の値に対する状態マシンの状態に基づいて)ことである。
この例では、フローチャートインスタンス33は、図2Aのノード32a〜32gのそれぞれに相当するノード33a〜33gと、リンク33l、33mとを含む。フローチャートインスタンス34は、図2Aのノード32a〜32gのそれぞれに相当するノード34a〜34gと、リンク34l、34mとを含む。
フローチャートインスタンス自体は実行可能なものである。キーの特定の値と関連付けられた入力データ記録をシステムが受信した後、キーのその特定の値に対するフローチャートインスタンスは、入力データ記録を処理し、その処理は、例えば、システムが、データ記録において、フローチャートインスタンスに対応する実行可能論理の1つ又は複数の部分(或いはフローチャートインスタンスの1つ又は複数のノード)を実行することによって行われる。フローチャートインスタンスは、入力データ記録が終了ノード又は待機ノードに達するまで、入力データ記録の処理を続ける。この例では、フローチャートインスタンスは、例えば、終了ノード又は待機ノードに対応する実行可能論理の部分に達するまでシステムが入力データ記録の処理を続けることによって、入力データ記録の処理を続ける。入力データ記録が待機ノードに達した場合は、フローチャートインスタンスは、ある時間量が経過するまで又は適切な新しい入力データ記録が到着するまで休止する。一般に、適切なデータ記録は、1つ又は複数の指定条件又は基準(例えば、ノードの論理に含まれるもの)を満たすデータ記録を含む。入力データ記録が終了ノードに達した場合は、フローチャートインスタンスの実行は完了する。
フローチャートインスタンスは、それ自体のライフサイクルを有する。データ記録が到着すると、フローチャートインスタンスの現在の状態又はステータスが変化する(すなわち、データ記録が決定をトリガする、フローチャートインスタンスの開始に戻る、又は、顧客にメッセージが送信される)。顧客用のフローチャートインスタンスは、データ記録が終了ノードに達した時点で終了する。
この例では、システムは、キーフィールドの「VBN3419」の値(例えば、顧客_id=VBN3419)に対してフローチャートインスタンス33を開始する。フローチャートインスタンス33は、VBN3419の顧客_idを含むデータ記録36a、36bのサブセットを処理する。この例では、フローチャートインスタンス33は、顧客_idキーフィールドに「VBN3419」の値を有するデータ記録36aを処理する。フローチャートインスタンス33のノード33a、33b、33c、33dは、データ記録36aを処理する。この例では、ノード33aによって表される処理コンポーネントが実行され次第、システムは、監査記録33iを生成し、監査記録33iは、VBN3419のキーに対してチャート32(チャート_ID:3454が割り当てられている)が開始されることを指定する。ノード33cに対応するデータ処理コンポーネントが実行され次第、システムは、監査記録33jを生成し、監査記録33jの少なくとも1つは、インスタンス33のリンク33lを走査することを指定する。フローチャートインスタンス33の現在の状態は、ノード33eの破線によって表されるように、アクションを送信するか又は実行する状態である。この例では、ノード33eによって表されるデータ処理コンポーネントは、監査記録33kを生成し、監査記録33kの少なくとも1つは、そのアクションを指定する。アクションは、送信されるSMSメッセージ(例えば、オファ又はプロモーションを含むもの)を送信することを含み得る。本明細書で説明される他のそのような「アクション」は、処理済みのデータ記録をさらに処理するために別のコンピュータプログラムの実行を開始すること、メモリへの処理済みのデータ記録の格納を開始すること、ネットワーク接続を介する別のコンピュータシステムへの処理済みのデータ記録の送信を開始すること、又は、1つ若しくは複数のフローチャート32、33、34のノードによって表される1つ若しくは複数のデータ処理コンポーネントに対する追加の演算資源を要求することのうちの1つ又は複数であり得る。例えば、フローチャートインスタンス33の結果は、フローチャートインスタンス33の1つ又は複数の実行特性に基づいて、フローチャートインスタンス33のノード(ノード32b、32c、32d、32e、32f、33b、33c、33d、33eのうちの1つなど)によって表されるデータ処理コンポーネントのうちの1つに対する追加の演算資源を要求するアクションの実行であり得る。そのような実行特性の例は、待機ノード32b、32d、33a又は33dのうちの1つ又は複数の待機時間であり得る。追加の演算資源に対する要求が認められると、要求された追加の演算資源の配分の受信へと至る。本明細書で使用される「演算資源」という用語は、実行環境14によってアクセス可能なメモリ(主要メモリなど)の部分へのアクセス、実行環境14によってアクセス可能なデータ記憶装置(データソース12若しくはデータ記憶装置26など)へのアクセス、及び、実行環境14の必要な処理能力量へのアクセス(実行環境14によってアクセス可能なCPU又は仮想コアへのアクセスなど)のうちの1つ又は複数を含む。
この例では、システムは、特定のキー値(すなわち、VBN3419)に対して実行されるインスタンス33に対する状態を維持する。従って、システムは、そのキー値と関連付けられたイベント又はデータ記録を処理する際、その特定のキー値に対してインスタンス33のどのノードを走査するかをロギングすることができる。それに加えて、パルスで監査記録を分類することにより、監査記録33i、33j、33kが同じパルスに含まれる際は、監査記録33j、33kは、キーフィールドを含む必要がなく、依然として、監査記録33iにおいて指定されたキーに対する監査記録として特定することができる。
システムは、「CND8954」のキーの値(例えば、顧客_id=CND8954)に対してフローチャートインスタンス34を開始する。フローチャートインスタンス34は、CND8954の顧客_idを含むデータ記録36a、36bのサブセットを処理する。この例では、フローチャートインスタンス34は、待機ノード34b、34dを含む。各データ記録は、1つのフローチャートインスタンスあたり1つのみの待機ノードの条件を満たすことができる。それに従って、フローチャートインスタンス34は、例えば、決定ノード34cの出力が「肯定」である際、ノード34a、34bを通じてノード34dまで顧客_id=CND8954を有するデータ記録36bを処理し、次いで、ノード34eに進む前に、同じキーを有する第2のデータ記録を待つ。ノード34aでデータ記録36bが処理され次第、本明細書で説明されるシステムは、監査記録34iを生成し、監査記録34iは、CND8954のキーに対してチャート32(チャート_ID:3454によって識別される)が開始されることを指定する。しかし、この例では、ノード34gの周りの点線によって表されるように、決定ノード34cの出力は、「否定」である。従って、ノード34cによって表されるデータ処理コンポーネントは、監査記録34jを生成し、監査記録34jのうちの1つは、決定ノード34cによって表される決定の結果に基づいてリンク34mを走査することを指定する。この例では、送信ノード34eは走査しない。従って、送信ノード34eによって表されるデータ処理コンポーネントは、監査記録を生成しない。前述の例では、データ記録を処理するノードへの言及は、データ記録を処理するノードを表すデータ処理コンポーネントを指す。それに加えて、これらの例では、チャート自体は実行可能なものである。すなわち、その実行により、チャートのノードに対応する実行可能論理が実行されるか、又は、実行論理の部分を封入するデータ処理コンポーネントが実行される。
図3の変形形態では、システムは、単一のキー値に対して複数のフローチャートインスタンスを生成する。例えば、同じ顧客に対して、異なる開始日及び終了日を有する多くのフローチャートインスタンスが存在することも、同じ顧客に対して、異なる目的(異なる産業プロセス又は異なる販売キャンペーンなど)の多くのフローチャートインスタンスが存在することもあり得る。
この例では、システムは、状態データ(例えば、各インスタンスに対してどのノードが現在実行されているかを示すデータ)をデータリポジトリ又はインメモリデータグリッドに格納することによって、インスタンスに対する状態を維持する。一般に、状態データは、状態を示すデータを含む。この例では、インスタンスは、キーの値と関連付けられる。データリポジトリ又はインメモリデータグリッドは、キーの値を格納する。システムは、キーの各値に対する状態データを格納することによって、インスタンスに対する状態を維持する。キーの特定の値に対するデータ記録の処理が完了次第、システムは、次のノード(図2Aのフローチャート32の)がキーのその値に対する現在の状態を表すことを指定するために、データリポジトリにおいて、状態データを更新する。次いで、別のデータ記録が到着すると、システムは、データリポジトリにおいて、キーのその値に対する現在の状態を検索し、キーのその値に対する実行可能論理の現在の状態を表すノードに対応する実行可能論理の部分を実行する。
図4を参照すると、環境100は、監査ロギング用のアーキテクチャを示す。環境100は、データ記録(及び/又は他の構造化データアイテム)を処理するように構成されたイベントエンジン102を有するシステム101(例えば、データ処理システム)を含む。この例では、イベントエンジン102は、ルールセットログ104、チャート実行モジュール106及びチャート108を含む。また、環境100は、データベース110、112も含む。この例では、ルールセットログ104は、その全内容が参照により本明細書に組み込まれる米国特許第7,877,350号明細書において説明されているような、ビジネスルール環境(BRE)におけるルールの実行生成されたログ(例えば、どのルールが実行されるか、それらのルールがいつ実行されるか、パラメータの値及び/又は実行中に設定された値などを示すロギングデータ又はルールケーストレース情報(本明細書では、トレーシング情報とも呼ばれる))を含む。この例では、イベントエンジン102は、任意選択によりその情報を監査記録に含めるため(例えば、ルールセットによって取り扱われ且つチャート決定ブロックに含まれないビジネス論理を説明するため)、ビジネスルール環境からルールケーストレース情報を収集する。例では、BREは、グラフのコンポーネント上のポートにそのログを書き込み、次いで、そのポートからファイルにそのログを書き込むことによって、ロギングデータストリームを実装する。この例では、イベントエンジン102は、BREのトレーシング情報を書き出す関数呼び出しを、イベントエンジン102が現在のイベントに対する監査記録(及び他の監査情報)を収集しているイベントエンジンの内部データ構造にトレーシング情報を格納する関数呼び出しと置き換えることによって、そのロギングデータストリームを傍受する。いくつかの例では、イベントエンジン102は、BREが使用しているロギング関数の代替の実装形態(例えば、write_to_log)を提供することによって、ロギングデータストリームを傍受する。他の例では、BREは、異なる関数を使用するオプションをサポートする。
この例では、チャート実行モジュール106は、1つ又は複数のデータフローグラフ(例えば、チャート108のうちの1つ)を実行するように構成される。この例では、チャート108のうちの1つは、イベントエンジングラフであり、イベントエンジングラフは、クラスタメトリクスを生成し、それらをデータベース110のファイルに直接書き込む。一般に、イベントエンジングラフは、イベントエンジン102の性能をモニタするためのグラフである。一般に、クラスタメトリクスは、システム及び/又はイベントエンジン102の集計レベルでの詳細(性能詳細など)を指し、例えば、データフローグラフのどの部分を走査するかを示すメトリクスや、記録のグループ別にデータフローグラフの特定の部分を何回走査するかを示す集計メトリクスである。いくつかの例では、このファイルは、すべてのパルス(例えば、データプッシュ)において追加され(例えば、他の以前に格納されたファイルに追加される又は更新される)、新しいファイルが毎日開かれる。
この例では、イベントエンジンビジネス論理から別のデータ経路が生じる(例えば、チャートを実行するチャート実行モジュール106の実行に基づいて)。チャートが実行されると、チャート実行モジュール106は、チャートを通じて取った経路(退出した待機ブロック、走査したフロー及び送信したアクションなど)を文書化する監査記録111のストリームを生成する。この例では、監査記録は、監査ファイル(すなわち、データベース112)に格納されたロギング済みの活動又はデータベース116に格納されたインデックス付き圧縮フラットファイル(ICFF)に格納されたロギング済みの活動を含む。一般に、監査ファイルは、様々な監査記録を格納するためのファイルを含む。この例では、監査記録111は、各パルスの終了時にファイルに書き込まれる。この例では、データベース112は、1つのパルスにつき1つの新しいファイルを受信する。
環境100は、グラフを含む監査ファイルプロセッサモジュール114を含み、監査ファイルプロセッサモジュール114に含まれるグラフは、未加工情報(すなわち、データベース112に格納された監査ファイル)を処理し、未加工情報をICFF用のフォーマットに再フォーマットする。この例では、データベース112は、再フォーマットのために監査ファイルプロセッサモジュール114に監査ファイルを送信する。これを受けて、監査ファイルプロセッサモジュール114は、再フォーマット済みのファイルをデータベース116に送信し、データベース116は、再フォーマット済みのファイルをICFF記録116aに書き込む(1つ又は複数のキーフィールド(例えば、対象者ID)別にインデックス生成され(インデックス116において)、時間別に(例えば、1時間毎に又は日毎に)まとめられる)。この例では、ICFF記録116aは、データブロック116cを参照する(例えば、ポインタ又は別の参照データ構造を介して)。この例では、未加工情報の一部分は、ICFF記録116a用に再フォーマットされる(次いで、インデックス116bにおいてインデックス生成される)が、未加工情報の他の部分は、データブロック116cに格納され、データブロック116cは、ICFF記録116aによって参照され、従って、ICFF記録116aを介して識別可能及びアクセス可能である。
いくつかの例では、指定された粒度(例えば、1つのチャートに対して1人のサービス加入者の1つのイベント)で監査記録を一括し、ICFF記録に格納されるキーフィールド(例えば、イベントタイプ、サービス加入者ID、タイムスタンプ、チャートインスタンスIDなどに対するフィールド)を演算し、次いで、以下の通り、残りの監査記録を集合体にまとめることによって、監査記録及び/又は監査ファイルは、ICFF用に再フォーマットされる。
例では、イベントエンジン102は、空間効率に対して最適化された(例えば、クエリ効率に対して最適化されるというよりむしろ)監査記録を生成する。この例では、監査記録は、空間効率に対して最適化される(例えば、すべての監査記録がタイムスタンプ、サービス加入者_IDなどを含むとは限らないということによって)。これらの監査記録をICFFに入れるため、本明細書で説明されるシステムは、より完全な記録(例えば、すべての監査記録にタイムスタンプ及び対象者IDを含むもの)を使用する必要があり、その結果、本明細書で説明されるシステムは、個々の記録(例えば、監査記録のコンテンツに基づくもの)を効率的に検索することができる。
いくつかの例では、データベース116の実装の目標はイベントのシーケンスに対するクエリを可能にすることであるため、データベース116は、ICFFというよりむしろ、リレーショナルデータベースを含む。その実施のため、システムは、監査記録のストリームを1つ又は複数の記録(例えば、ICFF記録)に変換する。各記録は、1つ又は複数のインデックス生成可能/検索可能なキーフィールド並びに監査イベントの残りの部分を表すデータ集合体を含む。
いくつかの例では、記録の粒度のレベルは、1つのチャートに対して1人のサービス加入者(例えば、ユーザ)の1つのイベントである。従って、本明細書で説明されるシステムは、1つのチャートに対して1人のサービス加入者の1つのイベントに対応する監査記録のシーケンスを抽出する(例えば、データベース112の監査ファイルから)。この例、イベントは順番に起こる。それに加えて、各イベントに対する監査記録は、データベース112に(例えば、データベース112のファイルに)順番に格納される。抽出された監査記録を使用することにより、システムは、複数のキーフィールド(例えば、イベントタイプフィールド、サービス加入者IDフィールド、タイムスタンプフィールド、チャートインスタンスIDフィールドなどを含む)を有する記録を生成する。いくつかの例では、シーケンスにおける第1の監査記録は、これらの複数のキーフィールドに対する値を含む。システムは、新しい記録を生成する際にこれらの含まれる値を使用する。それに加えて、システムは、そのシーケンスの残りの監査記録に相当するデータブロックを構築する。システムは、生成された新しい記録の一部として又は生成された新しい記録と関連付けて、データの集合体として(例えば、バイナリラージオブジェクト(BLOB)型として)、そのデータブロックをデータベース116に格納する(例えば、生成された新しい記録の参照データ集合体又はblob型を有することによって)。
生成された記録及び/又はデータ集合体を使用することにより、システムは、様々な情報(例えば、「6月8日にサービス加入者12345がイベント7を受けてからどうなったか?」など)に対して、ICFF(又はデータベース116)へのクエリを行い、次いで、イベントエンジン内部で行われた決定のシーケンス及びそのイベントの関連ルールセットを表示することができる。別の例では、システムは、次のクエリ、すなわち、「6月8日にサービス加入者12345がメッセージを送信してからどうなったか?」によって、ICFF(又はデータベース116)へのクエリを行う。この例では、このクエリに答えるため、生成された新しい記録は、メッセージアクションがトリガされた(又はトリガされなかった)ことを特定するために、別のキーフィールドを含む。従って、サポートすべきクエリの範囲に基づいて、システムは、どのキーフィールドを記録に含めるかを選択する。
この例では、データベース116は、未加工メトリクスをICFFに格納する。この例では、環境100は、メトリクスにアクセスするためのインタフェースを備えたメトリクスデータベース120も含む。従って、環境100は、未加工メトリクスを集計してそれらをメトリクスデータベース120に書き込むために、バッチグラフを起動する(例えば、10分毎に)バッチグラフモジュール118を含む。また、環境100は、例えば、ユーザインタフェース124に表示するためのメトリクス(システム100において主流の1つ又は複数の状態)を演算するために、「必要に応じて」起動されるバッチグラフモジュール122も含む。この例では、バッチグラフモジュール122は、メトリクスデータベース120からの及び/又はデータベース116からのメトリクスにアクセスし、ユーザインタフェース124に表示するためにそれらのアクセスしたメトリクスを処理する。この例では、バッチグラフモジュール118によって生成又は実行されたグラフは、永続状態を保持せず、メトリック状態は、メトリクスデータベース120において永続される。従って、マッチグラフモジュール120は、ユーザインタフェース122に表示するためのメトリクスに対して、メトリクスデータベース120へのクエリを行う。例では、様々なタイプのユーザインタフェースが表示されており、例えば、メトリクスの動的表示、メトリクスに関するレポート及び調査インタフェースを含み、その各々について以下で説明する。
メトリクスの動的表示では、コンソールがメトリクス(例えば、集計カウント)を表示し、その表示では、それらのメトリクスが準リアルタイムで更新される。システムは、このデータ及びメトリクスに対して、メトリクスデータベース120へのクエリを行う。この例では、コンソールは、ウェブユーザインタフェース(UI)であり、サーバからデータをプルする(例えば、タイマーで又は指定時刻に)ことのみ行うポーリングインタフェースを含む。従って、バッチグラフモジュール118によって生成されたグラフは、データをUIにプッシュすることができない。代わりに、UI(例えば、ウェブページ)は、更新されたカウント表示するために、サーバへのクエリを断続的に行う。更新されたカウントは、メトリクスデータベース120に格納される。この例では、UI(ウェブページ)とメトリクスデータベース120との間のインタフェースを取るサーバ側論理が存在し、例えば、ブラウザとデータベースとの間に位置するJavaアプリケーションサーバを含む。
別の例では、ユーザインタフェース124は、メトリクスデータベース120からクエリされたメトリクスに関するレポートを表示する。この例では、ユーザは、レポート及びダッシュボードのメトリクスを見ることができる。メトリクスは、何人の人が各キャンペーンに参入しているか、何人の人が各ブランチ(例えば、チャートの)を走査したか、何人の人がオファを得たか、何人の人がオファを承諾したかなどを指定する。ユーザインタフェースは、このレポートのさらなる詳細まで「掘り下げる」ための制御を含む。掘り下げるため(例えば、「トリガイベントを捉えたが、オファを得ることができなかったこれらの10人の対象者はどうなったか?」というクエリに答えるため)、システムは、データベース116のICFFの記録にアクセスする。これらのレポートを実施するため、システムは、サービス側モジュール(この例では、バッチグラフモジュール122である)を実装し、このモジュールは、掘り下げが要求される際に、メトリクスデータベース122及びデータベース116にアクセスすることができる。
さらなる別の例では、ユーザインタフェース124は、調査インタフェースを含み、調査インタフェースでは、ユーザは、「6月8日にサービス加入者12345がイベント7を受けてからどうなったか?」など、質問をすることができる。これらの質問に答えるため、システムは、ユーザインタフェース124とデータベース116のICFFとの間のサーバ側モジュール(例えば、Java、グラフなど)を使用して、ICFF(例えば、データベース116の)へのクエリを行う。
イベントエンジン102は、データベース116のICFFに格納するために、複数の異なるタイプの監査記録を作成する。以下の表1は、それらの対応するフィールドを有する異なるタイプの監査記録を指定する。以下の監査記録タイプのいくつかは、ロギングのレベルに応じて任意選択である。この例では、ICFFは、上記で説明されるように、例えば、ICFF記録のキーフィールドを生成する際に使用するため、以下の表1に示されるフィールドに相当するフィールドのリストを格納する。以下の表1のイタリック体のフィールドに対する値は、イベントエンジン102によって生成されるものではないが、本明細書で説明されるシステムによって、データがICFFに書き込まれる際に監査ストリームを遡ることによって推測される。これは、イベントエンジン102がかなり少量のデータを生成する必要があることを意味する。以下の表1では、「?」の列は、監査記録が任意選択であるかどうかを示す。「+」の記号は、監査記録がイベントエンジン107によって生成されることを意味する。文字は、監査記録が任意選択により生成され、関連制御点のセットによって制御されることを意味し、アスタリスクは、その記録タイプがデフォルトで使用可能であることを示す。
例では、データベース112は、各対象者に対して(例えば、キー別に)監査記録を分類する(例えば、継続的に又は断続的に)。すなわち、監査記録は、対象者又はキー別に自動的に分類される。その結果、イベントエンジン102は、監査ファイルの各監査記録においてタイムスタンプ、対象者_id又はインスタンス_idを複製する(例えば、1パルス毎に)必要はない。むしろ、データベース112は、グループ内のこれらのフィールドの以前に生じた値に基づいて、これらのフィールドから値を得ることができる。この例では、パルス間で状態を保存する必要はない。これは、例えば、ブロック開始監査記録は何パルスも前のものであり得るため、ブロック退出監査記録はブロック_名を有する必要があることを意味する。データベース112では、監査記録は、前述の表1に示される関連フィールドを備えている。
例では、システムは、チャートに対する対象者(例えば、ユーザ又はサービス加入者)のイベントの発生を検出する。従って、イベントエンジン102は、「イベント捕捉」監査記録を生成し、次いで、「イベントディスパッチ」監査記録を生成し、次いで、「ブロック退出−イベント」監査記録を生成する。これらの監査記録から、システム(例えば、監査ファイルプロセッサモジュール114)は、次のフィールド、すなわち、イベント_タイプ、タイムスタンプ及びインスタンス_iに対する値を得る。この例では、システムは、これらの監査記録をまとめてblob型に収集し、キーフィールド(例えば、イベント_タイプ、タイムスタンプ及びインスタンス_id)は、システムによって、捉えたデータから(例えば、監査記録から)の別の記録(例えば、ICFF記録)において設定される。
別の例では、チャートに対する対象者の1つのタイムアウトが起こる。この例では、イベントエンジン102は、次の監査記録、すなわち、アラームタイプの「イベント捕捉」監査記録を生成し、次いで、「アラームディスパッチ」監査記録を生成し、次いで、「ブロック退出−アラーム」監査記録を生成する。これらの監査記録から、システムは、次のキーフィールド、すなわち、イベント_タイプ、タイムスタンプ及びインスタンス_idに対する値を決定する。この例では、システムは、ブロック退出−アラーム監査記録からインスタンス_idフィールドの値を決定する(例えば、そのフィールドの値を推測するというよりむしろ)。この例では、システムは、これらの監査記録をblob型に収集し、キーフィールド(例えば、イベント_タイプ、タイムスタンプ、インスタンス_idなど)は、システムによって、捉えたデータ(例えば、監査記録)から設定される。
さらなる別の例では、チャートを開始するという対象者のイベントが起こる。この例では、イベントエンジン102は、「イベント捕捉」監査記録(チャート開始タイプのものでも、別のタイプのものでもよい)を生成し、次いで、「イベントディスパッチ」監査記録を生成し、次いで、「チャート開始」監査記録を生成する。これらの監査記録から、システムは、次のキーフィールド、すなわち、イベント_タイプ、タイムスタンプ及びインスタンス_idに対する値を得る。システムは、監査記録をblob型に収集し、キーフィールド(イベント_タイプ、タイムスタンプ、インスタンス_idなど)は、捉えたデータ(例えば、監査記録)から設定される。
監査記録はキー別に分類されるため、特定のキーと関連付けられた監査記録のサブセットは、キーフィールドを含まない。例えば、データベース112又は監査ファイルプロセッサモジュール114は、次の監査記録のシーケンス、すなわち、イベント捕捉監査記録、イベントディスパッチ監査記録、ブロック退出−イベント監査記録を受信することができる。この例では、データベース112又は監査ファイルプロセッサモジュール114は、イベント捕捉監査記録から対象者ID(例えば、キー)を得る。従って、イベントエンジン102は、イベントディスパッチ及びブロック退出監査記録においてキーを複製する必要はないが、その理由は、イベント捕捉監査記録の後、これらの監査記録がメモリにおいて(例えば、データベース112又は他のシステムメモリにおいて)順次的なものであるためである。同様に、イベントディスパッチ監査記録は、インスタンスIDフィールドを含む。従って、イベントエンジンは、ブロック退出監査記録においてこのフィールドを含むコピーする必要はない。システムは、監査記録メモリ(及びディスク上)を分類するため、システムは、グループ内のすべての監査記録にわたってキーをコピーする必要はなく、それにより、会話のシステム資源、メモリ消費量が低減される。
過剰量のデータの生成を回避するため、ユーザは、イベントエンジンが監査記録をいつ生成するか及びどの監査記録を生成するかを制御する。監査(延いてはメトリクス)は完全に無効化することができるが、監査が有効化される場合は、監査記録の主要セット(前の表においてプラス記号でマーク付けされたもの)が使用不能になることはない。監査記録の主要セットは、イベントエンジン入力(イベント及びアラーム)、出力(アクション)、エラー、並びに、チャート及び待機ブロック活動を追跡する。一般に、アラームは、将来において事前に計算された時刻に到着する事前に定義されたタイプのデータ記録(例えば、チャートがそれ自体を送信する)を含む。他の監査記録タイプは、選択的に使用可能及び使用不能にすることができる。任意選択の監査記録を使用可能にする次元は2つあり、それらは、何を使用可能にすべきか及びそれをいつ使用可能にすべきかである。何を使用可能にすべきかに関しては、選択的に使用可能/使用不能にすることができる多くの別個のグループの監査記録がある。それらは以下を含む。
・ A:アラーム設定(デフォルトでオン)
・ D:決定(デフォルトでオン)
・ P:モニタリングポイント(デフォルトでオン)
・ R:ルールセット呼び出し及びルールセットイベント
・ S:変数設定
・ V:変数読み取り
・ L:検索アクセス及び検索変数
それをいつ使用可能にすべきかに関しては、これらの監査イベントのロギングは、すべてを使用可能にすることも、以下のうちの1つ又は複数に基づいて制限することもできる。
・ 対象者id(例えば、キー)の指定セットのみ
・ チャート記名及び/又はモニタリング名の指定セットのみ
・ イベントタイプ(例えば、記録タイプ)の指定セットのみ
例では、イベントエンジン102は、制御点を通じてこれらの監査記録のロギングを構成する。一般に、制御点は、ランタイムパラメータを含み、ランタイムパラメータは、ユーザ(チャートを生成する)によって定義され、ランタイムに1つ又は複数のチャート(又はチャートインスタンス)の挙動を変更するために使用される。この例では、監査記録は、4つの相関制御点のセットによって制御される(例えば、イベントエンジンによって)。5つの制御点は、以下の通りである。
・ 監査タイプ−これは、有効化する監査記録タイプのリストであり、上記の表1にリストされる文字を使用する。
・ 監査エンティティ−これは、対象者idのリストである。空白でない場合、イベントエンジンは、このリストに含まれる対象者idに対する監査タイプリスト内の監査記録タイプのみを生成する。(そうでなければ、すべての対象者idが監査される)。
・ 監査イベント−これは、イベントタイプのリストである(例えば、イベントタイプに相当するか又はイベントタイプを表す数)。空白でない場合、イベントエンジンは、このリストに含まれるイベントタイプに対する監査タイプリスト内の監査記録タイプのみを生成する。(そうでなければ、すべてのイベントが監査される)。様々なタイプのイベントがあり、例えば、SMSメッセージが送信されたことを指定するイベント、ユーザがモバイルプランを更新したことを指定するイベントなどを含む。
・ 監査チャート−これは、チャート名及びモニタリング名のリストである。空白でない場合、イベントエンジンは、このリストにチャート名又はモニタリング名が含まれるチャートに対する監査タイプの監査記録タイプを生成する。(そうでなければ、すべてのチャートが監査される)。
・ 監査変数−これは、変数名のコンマ分離リストを含む。空白でなく、且つ、変数に対する監査記録タイプ(例えば、変数設定又は変数読み取り)を生成するようにイベントエンジンが構成される場合、イベントエンジンは、変数名がこのリストに含まれる場合のみ監査記録を生成する。
いくつかの例では、イベントエンジン102は、異なるグループの監査記録に対して異なるルールを適用する。この例では、第1のルールセット(例えば、監査タイプ1、監査エンティティ1、監査イベント1、監査チャート1及び監査変数1)を有する第1のグループの監査記録(例えば、第1の監査グループ)と、第2のルールセット(例えば、監査タイプ2、監査エンティティ2、監査イベント2、監査チャート2及び監査変数2)を有する第2のグループの監査記録(例えば、第2の監査グループ)などがある。
この例では、監査タイプ、監査エンティティ、監査イベント、監査チャート及び監査変数の各々は、ある種のフィルタを含む。これらのフィルタのいずれか又はすべてが設定された場合は、イベントのサブセットのみが追加の監査(例えば、任意選択の形態の監査を含む監査)を有する。
例では、システムは、第1の監査グループを以下の通り実施することによって、最小限で監査するように構成される。
監査タイプ1=「」(任意選択を使用不能にする)
監査エンティティ1=「」(すべての対象者ID)
監査イベント1=「」(すべてのイベントタイプ)
監査チャート1=「」(すべてのチャート)
監査変数1=「」(すべての変数、ただし、システムは任意選択の変数ロギングを無効化するように構成されるため、これは無視される)
ここで、別の例では、システムは、対象者_ID 12345がオファの送信に対する基準をすべて満たしているにもかかわらず、なぜこの対象者番号へのオファが一度も送信されなかったのかを評価するように構成される。このオファを実施するチャートは「マイオファチャート」であり、トリガイベントは数値6である。この特定の対象者IDにオファが送信されない理由についてのさらなる多くの詳細を得るため、システムは、第2の監査グループを用いて次の通り構成される。
監査タイプ2=「ADPRSVL」(すべての監査タイプを使用可能にする)
監査エンティティ2=「12345」(この対象者IDのみ)
監査イベント2=「6」(このイベントタイプのみ)
監査チャート2=「マイオファチャート」(このチャートのみ)
監査変数2=「」(すべての変数)
この例では、イベントが起こると、システムは、最初に、対象者IDが監査イベント2のリストに含まれているかどうか、イベントタイプが監査イベント2のリストに含まれているかどうか、チャートが監査チャート2のリストに含まれているかどうかを確かめる。これらのすべての属性(例えば、フィルタ)が真に評価された場合は、システムは、監査タイプ2において指定されるようにすべての監査記録タイプを実施し、それにより、そのイベントの間の任意選択のロギングが開始される。真に評価されなかった場合は、システムは、監査タイプ1を実施し、それにより、単にデフォルトでのロギングが行われる。この例では、システムは、最初に高位番号のグループをチェックし、マッチするグループが見つかるまで逆方向に進むように構成される。マッチするグループが見つからなかった場合は、システムは、デフォルトを実施及び使用する。変形形態では、システムは、さらなる任意選択のロギングを追加するすべてのマッチンググループの融合体を取るように構成することができる。
この例では、イベントエンジン102は、条件監査ロギングを実施し(例えばモニタリングポイント監査記録の実施を介して)、その実行性能を最適化する。この性能を最適化するため、イベントエンジン102は、条件付き監査決定を行うためのデータ構造を事前に計算する(例えば、事前に生成する)。一般に、条件付き監査決定は、条件が指定値(例えば、真又は偽)に評価されるものを監査記録が生成されることを指定する。この例では、イベントエンジンは、イベント又はアラームに対するイベント処理の開始時に条件付き監査計算を行う。例えば、イベントエンジンがイベント又はアラームを検出するたび(ただし、例えば、すべての監査記録においてというよりむしろ、各イベント又はアラームの処理の開始時のみ)、イベントエンジンは、計算を実行する(例えば、上記で説明される監査グループにおいて)。イベントエンジンは、条件付き監査計算をグローバル変数のパッケージに保存し、その内部で条件付きであり得る監査関数の各々に対するクエリを行う。
各監査記録タイプに対し、イベントエンジン102は、その監査記録タイプに対する監査記録が生成されているかどうかを指定する単一のフラグを実施する。イベントエンジン102は、単一のフラグを実施する際、監査エンティティ及び監査イベントリストのコンテンツを分析するが、その理由は、これらのリストは両方とも、イベント処理を開始した際に指定又は生成されるためである。多くのチャートによって1つのイベントを処理することができるため、イベントエンジンは、監査関数(例えば、監査記録タイプ)が実施されているかどうかをチャート毎に判断する。監査チャートが空白でない場合、イベントエンジンは、実施されているチャートのidとどのチャートが監査記録を生成しているか(及びどの監査記録タイプを生成しているか)を指定するインスタンスidとの間の比較を簡略化するために、監査チャートのコンテンツをインスタンスidのリスト(各々がチャートを識別する)に変換する。
例では、イベントエンジン102は、メモリ(例えば、イベントエンジン102内又はイベントエンジン102を含むシステム内の)において配列で監査記録を収集し、次いで、イベント又はイベントストリームの処理の終了時に1つのブロックで監査記録を監査ファイルに書き出す。この例では、異なるイベント(すなわち、異なるキー又はユーザIDと関連付けられたイベント)からの監査記録は、メモリにおいて混合されることはない。むしろ、メモリは仕切られており、各パーティションはそれ自体の監査ファイルを有する。従って、イベントエンジン102は、監査記録をキー別に自動的に分類するように構成される。
この例では、監査ファイルはバージョン化される。各パルスに対し、監査ファイルの1つのインスタンスが存在する。監査ファイルはディスク上で蓄積し、監査ファイル処理グラフ(監査ファイルプロセッサモジュール114によって実行される)は、パルスの終了時に各監査ファイルを取り出し(各パーティションから)、監査記録を後処理し、それらをICFFに書き込む。
この例では、システムは、例えば、イベントエンジン102のメモリから監査記録を読み取るというよりむしろ、ICFF(データベース116)からの監査記録を後処理することによってメトリクスデータベース120を生成する。この例では、ICFFはパージされない。従って、メトリクスデータベース120は、異なる集計期間の使用を含めて、いつでも再作成することができる。この例では、メトリクスデータベース120の表は、1つのデータベースを複数のクラスタに対して使用できるように、クラスタ_名の列を有する。一般に、クラスタは、イベントエンジンインスタンスを含む。一般に、イベントエンジンインスタンスは、キーの一意的な値に対する1つ又は複数の仕様(イベントエンジン102によって1つ又は複数のチャートが実行される対象となる)の特有の実現を含む。すなわち、各対象者IDは、正確に1つのイベントエンジンインスタンスによって取り扱われる。従って、一意的なキー(例えば、対象者ID)の各々に対し、そのチャートのすべてを有する正確に1つのイベントエンジンインスタンスが存在する。同じクラスタに対する監査記録は、同じ値のクラスタ_名を有する。
この例では、メトリクスデータベース120は、イベントエンジン102によって処理されたイベントの総数(例えば、イベント捕捉監査記録に基づく)、エラーが生じたイベントの数(例えば、エラーディスパッチ監査記録に基づく)、キャンペーンをトリガしたイベントの数(例えば、アクション送信監査記録に基づく)、どのサービス加入者が特定のキャンペーンに対してある段階から別の段階に移動したか(例えば、ブロック進入監査記録に基づく)、特定の日に対してイベントエンジンにおいてキャンセル又は追加されたサービス加入者の数(例えば、チャート開始及びチャート終了監査記録に基づく)、イベントエンジンで起動しているチャートの総数(例えば、チャート開始監査記録に基づく)及びイベントエンジンによってイベントが処理されている時にイベントエンジン102の状態を追跡するものなど、イベントエンジン102の状態を示すメトリクスに対してクエリを行うことができる。
それに加えて、メトリクスデータベース120は、特定のキーに対して(例えば、各サービス加入者に対して)メッセージが送信されなかった理由を指定するデータを回収するために、クエリを行うことができる(例えば、クライアントデバイス又は本明細書で説明されるシステムによって)。その実施のため、イベントエンジンは、取ったリンク(及び/又はチャート内で実行されたコンポーネント)並びにイベントエンジン102を介してアクセス及び実施されたルールセットケースをロギングするように構成される(例えば、どのコンポーネント及び/又はリンクが実行されるかを指定する監査記録を生成することによって)。次いで、システムは、特定のメッセージが送信されなかった理由(例えば、監査記録によって指定されるように、代替の経路が走査されたために送信されているメッセージに対応する経路が一度も走査されなかったため)を決定するために、チャートを通じて取った経路(例えば、監査記録によって指定されるような)を、チャートを通じるすべての潜在的な経路と比較するように構成可能である。
図5を参照すると、チャート250は、ノード252〜266を含む。この例では、ノード252〜264の各々は、1つ又は複数の監査記録を自動的に生成するためのコードを含むデータ処理コンポーネントを表す。例えば、ノード252は、チャート開始監査記録252aを生成するように構成されたデータ処理コンポーネントを表す。ノード254は、変数設定監査記録254a及び変数読み取り監査記録254bを生成するように構成されたデータ処理コンポーネントを表す。この例では、変数設定監査記録254aは、設定されている変数名を指定する。この例では、変数名は、「次のメッセージ日」である。変数読み取り監査記録254bは、読み取られている変数名を指定する。この例では、読み取られている変数名は、「開始日」である。ノード256によって表されるデータ処理コンポーネントは、監査記録256a〜256iを生成する。ノード258によって表されるデータ処理コンポーネントは、監査記録258a〜258cを生成する。ノード260によって表されるデータ処理コンポーネントは、監査記録260a〜260gを生成する。ノード262によって表されるデータ処理コンポーネントは、監査記録262a〜262cを生成する。ノード264によって表されるデータ処理コンポーネントは、監査記録264a〜264gを生成する。この例では、「次のメッセージ日」は、イベントエンジンがメッセージを処理する次の日付である。この例では、「次のメッセージ日」は、キャンペーンの初日であるように設定される。この例では、チャート250が開始される(キャンペーンが開始する前であり得る)とすぐに、イベントエンジンは、ノード256、260、264によってそれぞれ表される開始、オファ及びIVRアクションを送信する。この例では、開始、オファ及びIVRアクションは、チャートによって送信される3つのアクションである。対象者がキャンペーンをトリガすると、システムは、開始アクションを送信する。システムは、オファのための外部のサブシステムを構成するためにオファアクションを送信し(例えば、アカウントに資金を追加投入すると10分間の無料通話が得られる)、電話の着信を取り扱う外部のサブシステムを構成するためにIVRアクションを送信する(例えば、「利用可能なオファを知らせてください」)。この例では、対応するメタデータが空白の場合又はサービス加入者(キーによって表される)が対照群内に含まれる場合(ノード258によって表されるように)は、チャート250は、ノード260には進行せず(従って、オファアクションを送信しない)、代わりに、ノード262に進行する。この例では、IVRに対応するメタデータが空白の場合又はサービス加入者(キーによって表される)が対照群内に含まれる場合(ノード262によって表されるように)は、チャート250は、ノード264には進行せず(従って、IVRアクションを送信しない)、代わりに、ノード266に進行し、ノード266によって表されるように、イベントエンジンがメッセージ処理を毎日実行する必要があるかどうかを確かめる。
図6を参照すると、プロセス280は、データ処理システムによって、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を特定するために実施され、仕様は実行可能論理を表し、仕様はキーと関連付けられ、仕様の状態はキーのそれぞれの値に対して維持される。
動作の際、データ処理システムは、実行可能論理を表す仕様にアクセスし(282)、キーの特定の値に対する仕様の状態は、その状態で実行可能な実行可能論理の1つ又は複数の部分を指定する。また、データ処理システムは、例えば、入力デバイス又はポート上で、データのストリームのデータアイテムを断続的に受信し(284)、1つ又は複数のデータアイテムの各々は、キーの所定の値と関連付けられる。データ処理システムは、キーの所定の値に対するログ記録を生成し(286)、ログ記録は、各々がキーの所定の値と関連付けられる1つ又は複数のデータアイテムを処理する際に実行される実行可能論理の1つ又は複数の部分を指定する。この例では、生成することは、キーの所定の値と関連付けられる1つ又は複数のデータアイテムの各々に対し、次の動作を含む。データ処理システムは、そのデータアイテムと関連付けられたキーの所定の値に対する仕様の所定の状態を特定する(288)。データ処理システムは、所定の状態と関連付けられたものとして仕様において表される実行可能論理の1つ又は複数の部分の実行に従って、そのデータアイテムを処理する(290)。データ処理システムは、キーのその所定の値に対する実行可能論理のそれらの1つ又は複数の部分の実行を指定するログ記録を生成する(292)。
図7A〜7Hは、チャートの実行の間の監査記録生成からのICFF記録及びデータブロックの生成を示す。ここで図7Aを参照すると、略図300は、コンポーネント304〜316を有するチャート301を含む。現実世界の例では、チャート301は、例えば、複数の通話切断を経験している顧客を補償することを希望する通信会社によって実行するように構成される。具体的には、顧客がこの2時間の間に通話切断を2回経験した場合(コンポーネント308によって指定されるように)又は丸1日の間に通話切断が4回あった場合(コンポーネント318によって指定されるように)は、通信会社は、顧客のアカウントに5分間の無料通話を追加する(コンポーネント310、314によって指定されるように)。会社は、24時間に1回支払うだけである(コンポーネント306、312によって指定されるように)。チャート301は、使用期限なく起動される。この例では、本明細書で説明されるシステムがチャート301を実行する。
図7Bを参照すると、略図303は、チャート301が実行を開始したというチャート301の状態を示している。チャート301の開始時、チャート301は第1の状態であり、第1の状態では、コンポーネント304が実行され(コンポーネント304の周りの太線によって示されるように)、それにより、システムは、監査記録324を生成する。図7Cを参照すると、略図305は、チャート301が第2の状態に進行していることを示し、第2の状態では、システムは、指定されたイベントを待ち、次いで、イベントが検出され次第、様々な決定を行い、様々なアクションを実行する。この例示的な状態では、システムは、コンポーネント306を実行し(コンポーネント306の周りの太線によって指定されるように)、システムは、監査記録326を生成する。コンポーネント306では、システムは、例えば、最後の通話が切断されたことを指定するイベント(すなわち、「最後の通話が切断された」というイベントタイプ)などの指定されたイベントを待つように構成される。この例では、システムは、イベント302(例えば、構造化データアイテム又はデータ記録)を受信し、イベント302は、このイベントが「最後の通話が切断された」というイベントタイプのものであることを指定するデータを含む。イベント302が検出され次第、システムは、監査記録322を生成し、コンポーネント306(又はコンポーネント306によって表される実行可能論理を実行するシステム)は、この24時間の間に支払いがあったかどうかを判断する(すなわち、現在の時刻−最後の通話切断の支払時刻≧24時間)。その実施の際、システムは、監査記録328、330を生成し、その各々は、読み取った変数の値を指定する。イベント302が検出され、この24時間の間に支払いが行われなかったことが検出され次第、システムは、第2の状態を保持しながら、監査記録332を生成し、コンポーネント308に進行する。
図7Dを参照すると、略図307は、コンポーネント308の周りの太線によって示されるように、システムがコンポーネント308を実行するチャート301の状態を示している。この例では、コンポーネント308(又はコンポーネント308によって表される実行可能論理を実行するシステム)は、変数の値を読み取る際に監査記録334、336を生成する。この例では、コンポーネント308によって表される論理は、読み取った変数の値に基づいて、「否定」の値に評価する。
図7Eを参照すると、略図309は、チャート301のさらなる別の状態を示し、依然として第2の状態を保持したまま、コンポーネント318が実行される(コンポーネント318の周りの太線によって示されるように)。コンポーネント318では、システムは、監査記録362を生成し、監査記録362は、「1時間あたりの通話切断回数」という変数の読み取った値を指定する。この例では、システムは、コンポーネント318によって表される論理が「肯定」の値に評価すると決定し、監査記録364を生成し、監査記録364のコンテンツは、コンポーネント318(「決定2」と呼ばれる)が「肯定」の値に評価したことを指定する。
図7Fを参照すると、略図311は、チャート301がコンポーネント310に進行したことを示し、コンポーネント310は、監査記録340を生成する。図7Gを参照すると、略図313は、チャート301が次いでコンポーネント312に進行したことを示し、コンポーネント312は、監査記録342を生成する。
図7Hを参照すると、略図315は、チャート301が次いでコンポーネント314に進行したことを示し、コンポーネント314は、監査記録344を生成する。次いで、チャート301は、コンポーネント316に進行する。この例では、システムは、監査記録322、324、326、328、330、332、334、336、338、340、342、344、362、364を一括し、ICFF記録に格納するキーフィールド(例えば、イベントタイプ、対象者ID、タイムスタンプ、インスタンスIDに対するフィールド)を特定し、次いで、残りの監査記録を集合体にまとめる。この例では、システムは、キーフィールド(例えば、監査記録322、324からの)を含むICFF記録348を生成する。監査記録326、328、330、332、334、336、338、340、342、344、362、364のコンテンツ及びICFF記録348に含まれない監査記録322、324のコンテンツは、データブロック350に含まれる。システムは、ICFF記録348及びデータブロック350をデータベース346に格納する。この例では、データベース346は、インデックス352を格納し、ICFF記録348は、次のフィールド別に、すなわち、インデックス352の行354に示されるような、タイムスタンプ、対象者_ID及びイベントタイプ別に、インデックス352においてインデックス生成される。この例では、インデックス352は、他のICFF記録の(例えば、他のチャート及び/又は他の対象者IDに対する)インデックスを生成する行356、358、360も含む。この例では、ICFF記録348は、参照データ構造366(例えば、ポインタ)を介してデータブロック350を参照する。変形形態では、ICFF記録348及びデータブロック350を組み合わせて、インデックス付きのICFFデータブロック(又はデータブロック)にする。
上記で説明される技法は、コンピュータ上で実行するためのソフトウェアを使用して実施することができる。例えば、ソフトウェアは、1つ又は複数のプログラムされた又はプログラム可能なコンピュータシステム(分散、クライアント/サーバ若しくはグリッドなどの様々なアーキテクチャのものであり得る)上で実行される1つ又は複数のコンピュータプログラムの手順を形成するものであり、各コンピュータシステムは、少なくとも1つのプロセッサと、少なくとも1つのデータ記憶システム(揮発性及び不揮発性メモリ及び/又は記憶素子を含む)と、少なくとも1つの入力デバイス又はポートと、少なくとも1つの出力デバイス又はポートとを含む。ソフトウェアは、より大きなプログラムの1つ又は複数のモジュールを形成することができ、モジュールは、例えば、チャート及びフローチャートの設計及び構成に関連する他のサービスを提供する。チャートのノード、リンク及び要素は、コンピュータ可読媒体に格納されるデータ構造として又はデータリポジトリに格納されるデータモデルに適合する他の組織化データとして実装することができる。
本明細書で説明される技法は、デジタル電子回路において、コンピュータハードウェア、ファームウェア、ソフトウェアにおいて又はそれらの組合せで実装することができる。装置は、有形に具体化されるか又はプログラマブルプロセッサによって実行するための機械可読記憶装置(例えば、非一時的な機械可読記憶装置、機械可読ハードウェア記憶装置など)に格納されるコンピュータプログラム製品において実装することができ、方法のアクションは、入力データに基づいて動作して出力を生成することによって機能を実行するために命令のプログラムを実行するプログラマブルプロセッサによって実行することができる。本明細書で説明される実施形態並びに請求項及び本明細書で説明される技法の他の実施形態は、有利には、データ記憶システムとのデータ及び命令の送受信を行うように結合された少なくとも1つのプログラマブルプロセッサと、少なくとも1つの入力デバイスと、少なくとも1つの出力デバイスとを含むプログラマブルシステム上で実行可能な1つ又は複数のコンピュータプログラムにおいて実装することができる。各コンピュータプログラムは、高水準手続き型若しくはオブジェクト指向プログラミング言語で又は必要に応じてアセンブリ言語若しくは機械語で実施することができ、いかなる事例においても、言語は、コンパイラ型又はインタープリタ型言語であり得る。
コンピュータプログラムの実行に適したプロセッサは、例として、汎用マイクロプロセッサと専用マイクロプロセッサの両方及び任意の種類のデジタルコンピュータの任意の1つ又は複数のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリ若しくはランダムアクセスメモリ又はその両方から命令及びデータを受信する。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令及びデータを格納するための1つ又は複数のメモリデバイスである。また、一般に、コンピュータは、データを格納するための1つ又は複数の大容量記憶装置(例えば、磁気ディスク、光磁気ディスク若しくは光ディスク)を含むか、或いは、データの受信若しくは転送又はその両方を行うために1つ又は複数の大容量記憶装置に動作可能に結合される。コンピュータプログラム命令及びデータを具体化するためのコンピュータ可読媒体は、不揮発性メモリのすべての形態を含み、例として、半導体メモリデバイス(例えば、EPROM、EEPROM及びフラッシュメモリデバイス)や、磁気ディスク(例えば、内部ハードディスク又はリムーバブルディスク)や、光磁気ディスクや、CD−ROM及びDVD−ROMディスクを含む。プロセッサ及びメモリは、専用論理回路によって補充することも、専用論理回路に組み込むこともできる。前述のいずれも、ASIC(特定用途向け集積回路)によって補充することも、ASIC(特定用途向け集積回路)に組み込むこともできる。
ユーザとの対話を提供するため、実施形態は、ユーザに情報を表示するための表示デバイス(例えば、LCD(液晶ディスプレイ)モニタ)や、ユーザがコンピュータに入力を提供できるようにするためのキーボード及びポインティングデバイス(例えば、マウス又はトラックボール)を有するコンピュータ上で実装することができる。ユーザとの対話を提供するため、他の種類のデバイスを使用することもでき、例えば、ユーザに提供されるフィードバックは、感覚フィードバック(例えば、視覚フィードバック、聴覚フィードバック又は触覚フィードバック)のいかなる形態でもよく、ユーザからの入力は、音響、音声または触覚入力を含むいかなる形態でも受信することができる。
実施形態は、バックエンドコンポーネント(例えば、データサーバとして)を含むか、ミドルウェアコンポーネント(例えば、アプリケーションサーバ)を含むか、フロントエンドコンポーネント(例えば、ユーザが実施形態の実装形態と対話できるようにするためのグラフィカルユーザインタフェース若しくはウェブブラウザを有するクライアントコンピュータ)を含むか、そのようなバックエンド、ミドルウェア又はフロントエンドコンポーネントの任意の組合せを含む、コンピューティングシステムにおいて実装することができる。システムのコンポーネントは、デジタルデータ通信の任意の形態又は媒体(例えば、通信ネットワーク)によって相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク(LAN)及び広域ネットワーク(WAN)(例えば、インターネット)を含む。
システム及び方法又はそれらの一部は、「ワールドワイドウェブ」(ウェブ又はWWW)を使用することができ、「ワールドワイドウェブ」は、ハイパーテキスト転送プロトコル(HTTP)を利用するインターネット上のサーバの集合体である。HTTPは、テキスト、グラフィックス、画像、音声、映像、ハイパーテキストマークアップ言語(HTML)及びプログラムなどの異なるフォーマットの情報であり得る資源へのアクセスをユーザに提供する公知のアプリケーションプロトコルである。ユーザによってリンクが指定され次第、クライアントコンピュータは、ウェブサーバへのTCP/IP要求を行い、情報(HTMLに従ってフォーマットされた別のウェブページであり得る)を受信する。また、ユーザは、画面上の命令に従ってあるデータを入力するか又は選択したアイコンをクリックすることによって、同じ又は他のサーバ上の他のページにもアクセスすることができる。また、ユーザが所定のコンポーネントに対するオプションを選択できるようにするため、ウェブページを使用する実施形態に対して、当業者に知られているいかなるタイプの選択デバイス(チェックボックス、ドロップダウンボックス及び同様のものなど)も使用できることにも留意されたい。サーバは、UNIX(登録商標)マシンを含む様々なプラットフォーム上で起動することができるが、Windows 2000/2003、Windows NT、Sun、Linux(登録商標)、Macintoshなどの他のプラットフォームを使用することもできる。コンピュータユーザは、Firefox、Netscape Navigator、Microsoft Internet Explorer又はMosaicブラウザなどの閲覧ソフトの使用を通じて、ウェブ上のサーバ又はネットワーク上で利用可能な情報を閲覧することができる。コンピューティングシステムは、クライアント及びサーバを含み得る。クライアント及びサーバは、一般に、互いにリモート場所に位置し、典型的には、通信ネットワークを通じて対話する。クライアントとサーバとの関係は、コンピュータプログラムによって生じ、コンピュータプログラムは、それぞれのコンピュータ上で起動しており、互いにクライアント・サーバ関係を有するものである。
他の実施形態は、説明及び請求項の範囲及び精神内である。例えば、ソフトウェアの本質のため、上記で説明される機能は、ソフトウェア、ハードウェア、ファームウェア、配線又はこれらの任意の組合せを使用して実装することができる。機能を実装する特徴もまた、様々な位置に物理的に位置し得、機能の一部が異なる物理的場所で実装されるように分散されることを含む。本明細書における及び本出願全体を通じる「a」という用語の使用は、制御様式では使用されず、従って、「a」という用語に対して複数の意味或いは「1つ又は複数の」という意味を除外することを意図しない。それに加えて、仮特許出願に対して優先権が主張される範囲で、仮特許出願は制限するものではなく、本明細書で説明される技法をどのように実装できるかについての例を含むものであることを理解されたい。
本発明の多くの実施形態について説明してきた。それにもかかわらず、当業者であれば、請求項及び本明細書で説明される技法の精神及び範囲から逸脱することなく、様々な変更を行えることが理解されよう。