特許7372977 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ アビニシオ　テクノロジー　エルエルシーの特許一覧

特許7372977監査データを出力する際の回復性を実装するための専用監査ポート

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2A
2B
2C
2D
2E
3A
3B
4A
4B
4C
5A
5B
6A
6B
6C
6D
6E
7
8

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-10-24

(45)【発行日】2023-11-01

(54)【発明の名称】監査データを出力する際の回復性を実装するための専用監査ポート

(51)【国際特許分類】

G06F 11/34 20060101AFI20231025BHJP

【ＦＩ】

G06F11/34 176

【請求項の数】 20

(21)【出願番号】P 2021540392

(86)(22)【出願日】2019-09-25

(65)【公表番号】

(43)【公表日】2022-01-11

(86)【国際出願番号】 US2019052882

(87)【国際公開番号】W WO2020068927

(87)【国際公開日】2020-04-02

【審査請求日】2022-09-22

(31)【優先権主張番号】62/736,259

(32)【優先日】2018-09-25

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】509123208

【氏名又は名称】アビニシオテクノロジーエルエルシー

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部達彦

(72)【発明者】

【氏名】ポール・ヴァイザー

(72)【発明者】

【氏名】トレバー・マーフィー

【審査官】稲葉崇

(56)【参考文献】

【文献】特表２０１３－５３６５３１（ＪＰ，Ａ）

【文献】特表２０１４－５０９０１２（ＪＰ，Ａ）

【文献】特表２０１０－５３４８９１（ＪＰ，Ａ）

【文献】特表２０１６－５１７５６５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ１１／０７，１１／２８－１１／３６

Ｇ０６Ｆ８／００－８／３８

Ｇ０６Ｆ８／６０－８／７７

Ｇ０６Ｆ９／４４－９／４４５，９／４５１

Ｇ０６Ｆ１１／１４

(57)【特許請求の範囲】

【請求項1】

トランザクションを表す１つ又は複数のデータレコードを処理するデータフローグラフを実行するためのデータ処理システムによって実装される方法であって、前記データフローグラフは複数のコンポーネント及びリンクを含み、コンポーネントは１つ又は複数の入力レコードを処理するために前記１つ又は複数の入力レコードに適用される計算を表し、入力レコードは前記トランザクションを表す前記１つ又は複数のデータレコードへの指定の関係を有し、前記リンクは前記コンポーネントを接続し、前記コンポーネント間のデータフローを表し、
前記複数のコンポーネント及び前記リンクを含む前記データフローグラフを実行するステップであって、前記データフローグラフを前記実行するステップが前記複数のコンポーネントの所与のコンポーネントを実行するステップを含み、前記所与のコンポーネントは入力ポート、監査ポート、及び出力ポートを含み、
前記入力ポートは前記トランザクションを表す前記１つ又は複数のデータレコードへの指定の関係を有する前記入力レコードの１つ又は複数を受信するためのものであり、
前記監査ポートは前記トランザクションの少なくとも一部を表す監査データを提供するためのものであり、
前記出力ポートは１つ又は複数の出力レコードを提供するためのものであり、
前記複数のコンポーネントの少なくとも１つは前記所与のコンポーネントの実行よりも前に実行するように構成される、
実行するステップと、
前記トランザクションを表す前記１つ又は複数のデータレコードを前記複数のコンポーネント及び前記リンクを有する前記データフローグラフによって処理するステップであって、前記複数のコンポーネントの前記少なくとも１つによって処理される前記入力レコードの１つ又は複数を指定する状態を前記複数のコンポーネントの前記少なくとも１つが保存する、処理するステップと、
前記所与のコンポーネントを前記実行する間、前記所与のコンポーネントによる前記入力レコードの１つ又は複数の処理中にエラーが発生した場合、
前記複数のコンポーネントの前記少なくとも１つの状態を前記保存済みの状態に回復し、
前記回復した状態に基づいて前記データフローグラフの前記所与のコンポーネントに関する前記監査データの少なくとも一部を回復するステップと、
前記トランザクションの少なくとも一部を表す前記回復済みの監査データの前記少なくとも一部を前記監査ポート上で提供するステップと、
前記１つ又は複数の出力レコードを前記出力ポート上で提供するステップと
を含む、方法。

【請求項2】

前記回復される監査データが第１の監査データであり、前記監査ポートが第１の監査ポートであり、前記所与のコンポーネントが第１のコンポーネントであり、前記方法が
前記第１の監査データを第２のコンポーネントの第２の監査ポート上で出力される第２の監査データと指定の時間間隔で結合するステップ
を更に含む、請求項１に記載の方法。

【請求項3】

前記所与のコンポーネントが第１のコンポーネントであり、前記回復される監査データが第１の監査データであり、前記方法が
第１のデータ処理システム上で前記第１のコンポーネントを実行するステップと、
第２のデータ処理システム上で前記データフローグラフの第２のコンポーネントを実行するステップと、
前記回復済みの監査データ及び前記第２のコンポーネントの第２の監査ポートから出力される第２の監査データを第３のデータ処理システム上で受信するステップと
を更に含む、請求項１に記載の方法。

【請求項4】

前記受信した回復済みの監査データ及び第２の監査データをメモリ内に記憶するステップと、
前記記憶した監査データから１つ又は複数のメトリックを動的に生成するステップと
を更に含む、請求項３に記載の方法。

【請求項5】

第１の監査データ及び第２の監査データからデータを集約するステップと、
その集約済みデータを記憶するステップと
を更に含む、請求項１に記載の方法。

【請求項6】

前記回復済みの監査データを特定の分類に割り当てることによって前記回復済みの監査データを分類するステップと、
特定のキャンペーンに対するユーザの対話を示す監査メトリックを前記特定の分類に割り当てられた監査データから生成するステップと
を更に含む、請求項１に記載の方法。

【請求項7】

前記エラーが前記発生したことに応答し、前記所与のコンポーネントが、前記複数のコンポーネントの前記少なくとも１つの前記状態を含み且つ前記入力レコードの１つ又は複数のどれが前記複数のコンポーネントの前記少なくとも１つによって前回成功裏に処理されたのかを指定するエラーログをエラーログポート上で出力し、前記状態は前記コンポーネントのどれが前回成功裏に処理を完了したのかを指定する、請求項１に記載の方法。

【請求項8】

前記所与のコンポーネントが前記エラーログをエラーハンドラコンポーネントに出力し、前記エラーハンドラコンポーネントは前記エラーログに基づいてロールバックコンポーネントにメッセージを伝送し、前記ロールバックコンポーネントは前記メッセージを使用し、前記複数のコンポーネントの前記少なくとも１つが実行されており、前記複数のコンポーネントの前記少なくとも１つによって前回成功裏に処理された前記入力レコードの前記１つ又は複数が前記複数のコンポーネントの前記少なくとも１つによって処理されている状態へと前記データフローグラフの状態を戻す、請求項７に記載の方法。

【請求項9】

トランザクションを表す１つ又は複数のデータレコードを処理するデータフローグラフを実行するための１つ又は複数の機械可読ハードウェア記憶装置であって、前記データフローグラフは複数のコンポーネント及びリンクを含み、コンポーネントは１つ又は複数の入力レコードを処理するために前記１つ又は複数の入力レコードに適用される計算を表し、入力レコードは前記トランザクションを表す前記１つ又は複数のデータレコードへの指定の関係を有し、前記リンクは前記コンポーネントを接続し、前記コンポーネント間のデータフローを表し、以下のステップ、つまり
前記複数のコンポーネント及び前記リンクを含む前記データフローグラフを実行するステップであって、前記複数のうちの所与のコンポーネントは入力ポート、監査ポート、及び出力ポートを含み、
前記入力ポートは前記トランザクションを表す前記１つ又は複数のデータレコードへの指定の関係を有する１つ又は複数の入力レコードを受信するためのものであり、
前記監査ポートは前記トランザクションの少なくとも一部を表す監査データを提供するためのものであり、
前記出力ポートは１つ又は複数の出力レコードを提供するためのものであり、
前記コンポーネントの少なくとも１つは前記所与のコンポーネントの実行よりも前に実行するように構成される、
実行するステップと、
前記トランザクションを表す前記１つ又は複数のデータレコードを前記コンポーネント及び前記リンクを有する前記データフローグラフによって処理するステップであって、前記コンポーネントの前記少なくとも１つによって処理される１つ又は複数の入力レコードを指定する状態を前記コンポーネントの前記少なくとも１つが保存する、処理するステップと、
前記所与のコンポーネントによる１つ又は複数の入力レコードの処理中にエラーが発生した場合、
前記コンポーネントの前記少なくとも１つの状態を前記保存済みの状態に回復し、
前記回復した状態に基づいて前記データフローグラフの前記所与のコンポーネントに関する前記監査データの少なくとも一部を回復するステップと、
前記トランザクションの少なくとも一部を表す前記回復済みの監査データの前記少なくとも一部を前記監査ポート上で提供するステップと、
前記１つ又は複数の出力レコードを前記出力ポート上で提供するステップと
を含む操作を実行するために１つ又は複数の処理装置によって実行可能な命令を記憶する、
１つ又は複数の機械可読ハードウェア記憶装置。

【請求項10】

前記回復される監査データが第１の監査データであり、前記監査ポートが第１の監査ポートであり、前記所与のコンポーネントが第１のコンポーネントであり、前記操作が
前記第１の監査データを第２のコンポーネントの第２の監査ポート上で出力される第２の監査データと指定の時間間隔で結合するステップ
を更に含む、請求項９に記載の１つ又は複数の機械可読ハードウェア記憶装置。

【請求項11】

前記所与のコンポーネントが第１のコンポーネントであり、前記回復される監査データが第１の監査データであり、前記操作が
第１のデータ処理システム上で前記第１のコンポーネントを実行するステップと、
第２のデータ処理システム上で前記データフローグラフの第２のコンポーネントを実行するステップと、
前記回復済みの監査データ及び前記第２のコンポーネントの第２の監査ポートから出力される第２の監査データを第３のデータ処理システム上で受信するステップと
を更に含む、請求項９に記載の１つ又は複数の機械可読ハードウェア記憶装置。

【請求項12】

前記操作が
前記受信した回復済みの監査データ及び第２の監査データをメモリ内に記憶するステップと、
前記記憶した監査データから１つ又は複数のメトリックを動的に生成するステップと
を更に含む、請求項１１に記載の１つ又は複数の機械可読ハードウェア記憶装置。

【請求項13】

前記操作が
第１の監査データ及び第２の監査データからデータを集約するステップと、
その集約済みデータを記憶するステップと
を更に含む、請求項９に記載の１つ又は複数の機械可読ハードウェア記憶装置。

【請求項14】

前記操作が
前記回復済みの監査データを特定の分類に割り当てることによって前記回復済みの監査データを分類するステップと、
特定のキャンペーンに対するユーザの対話を示す監査メトリックを前記特定の分類に割り当てられた監査データから生成するステップと
を更に含む、請求項９に記載の１つ又は複数の機械可読ハードウェア記憶装置。

【請求項15】

トランザクションを表す１つ又は複数のデータレコードを処理するデータフローグラフを実行するためのデータ処理システムであって、前記データフローグラフは複数のコンポーネント及びリンクを含み、コンポーネントは１つ又は複数の入力レコードを処理するために前記１つ又は複数の入力レコードに適用される計算を表し、入力レコードは前記トランザクションを表す前記１つ又は複数のデータレコードへの指定の関係を有し、前記リンクは前記コンポーネントを接続し、前記コンポーネント間のデータフローを表し、前記システムは１つ又は複数の処理装置、及び
前記複数のコンポーネント及び前記リンクを含む前記データフローグラフを実行するステップであって、前記複数のうちの所与のコンポーネントは入力ポート、監査ポート、及び出力ポートを含み、
前記入力ポートは前記トランザクションを表す前記１つ又は複数のデータレコードへの指定の関係を有する１つ又は複数の入力レコードを受信するためのものであり、
前記監査ポートは前記トランザクションの少なくとも一部を表す監査データを提供するためのものであり、
前記出力ポートは１つ又は複数の出力レコードを提供するためのものであり、
前記コンポーネントの少なくとも１つは前記所与のコンポーネントの実行よりも前に実行するように構成される、
実行するステップと、
前記トランザクションを表す前記１つ又は複数のデータレコードを前記コンポーネント及び前記リンクを有する前記データフローグラフによって処理するステップであって、前記コンポーネントの前記少なくとも１つによって処理される１つ又は複数の入力レコードを指定する状態を前記コンポーネントの前記少なくとも１つが保存する、処理するステップと、
前記所与のコンポーネントによる１つ又は複数の入力レコードの処理中にエラーが発生した場合、
前記コンポーネントの前記少なくとも１つの状態を前記保存済みの状態に回復し、
前記回復した状態に基づいて前記データフローグラフの前記所与のコンポーネントに関する前記監査データの少なくとも一部を回復するステップと、
前記トランザクションの少なくとも一部を表す前記回復済みの監査データの前記少なくとも一部を前記監査ポート上で提供するステップと、
前記１つ又は複数の出力レコードを前記出力ポート上で提供するステップと
を含む操作を実行するために前記１つ又は複数の処理装置によって実行可能な命令を記憶する１つ又は複数の機械可読ハードウェア記憶装置を含む、
データ処理システム。

【請求項16】

前記回復される監査データが第１の監査データであり、前記監査ポートが第１の監査ポートであり、前記所与のコンポーネントが第１のコンポーネントであり、前記操作が
前記第１の監査データを第２のコンポーネントの第２の監査ポート上で出力される第２の監査データと指定の時間間隔で結合するステップ
を更に含む、請求項１５に記載のデータ処理システム。

【請求項17】

【請求項18】

前記操作が
前記受信した回復済みの監査データ及び第２の監査データをメモリ内に記憶するステップと、
前記記憶した監査データから１つ又は複数のメトリックを動的に生成するステップと
を更に含む、請求項１７に記載のデータ処理システム。

【請求項19】

前記操作が
第１の監査データ及び第２の監査データからデータを集約するステップと、
その集約済みデータを記憶するステップと
を更に含む、請求項１５に記載のデータ処理システム。

【請求項20】

前記操作が
前記回復済みの監査データを特定の分類に割り当てることによって前記回復済みの監査データを分類するステップと、
特定のキャンペーンに対するユーザの対話を示す監査メトリックを前記特定の分類に割り当てられた監査データから生成するステップと
を更に含む、請求項１５に記載のデータ処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

技術分野
本明細書の説明は、データ項目のストリーム内のデータ項目、例えばネットワークアプリケーションからネットワーク接続経由で入ってくるデータ項目に目下適用されている実行可能ロジックの実行からログを生成するためのコンピュータによって実装される方法、データ処理システム、及び機械可読ハードウェア記憶装置に関する。

【0002】

優先権の主張
本願は、参照によりその全内容を本明細書に援用する、２０１８年９月２５日に出願された米国特許出願第６２／７３６，２５９号明細書の優先権を米国特許法第１１９条（ｅ）の下で主張する。

【背景技術】

【0003】

背景
ログは、オペレーティングシステム若しくは他のソフトウェアの実行の際に生じるイベント、又は通信ソフトウェアの様々なユーザ間のメッセージを記録する。

【発明の概要】

【課題を解決するための手段】

【0004】

概要
一部の実装形態では、トランザクションを表す１つ又は複数のデータレコードを処理するデータフローグラフを実行するためのデータ処理システムによって実装される方法であって、データフローグラフは複数のコンポーネント及びリンクを含み、コンポーネントは１つ又は複数の入力レコードを処理するために１つ又は複数の入力レコードに適用される計算を表し、入力レコードはトランザクションを表す１つ又は複数のデータレコードへの指定の関係を有し、リンクはコンポーネントを接続し、コンポーネント間のデータフローを表し、複数のコンポーネント及びリンクを含むデータフローグラフを実行するステップであって、複数のうちの所与のコンポーネントは入力ポート、監査ポート、及び出力ポートを含み、入力ポートはトランザクションを表す１つ又は複数のデータレコードへの指定の関係を有する１つ又は複数の入力レコードを受信するためのものであり、監査ポートはトランザクションの少なくとも一部を表す監査データを提供するためのものであり、出力ポートは１つ又は複数の出力レコードを提供するためのものであり、コンポーネントの少なくとも１つが所与のコンポーネントの実行よりも前に実行するように構成される、実行するステップと、トランザクションを表す１つ又は複数のデータレコードをコンポーネント及びリンクを有するデータフローグラフによって処理するステップであって、コンポーネントの少なくとも１つによって処理される１つ又は複数の入力レコードを指定する状態をコンポーネントの少なくとも１つが保存する、処理するステップと、所与のコンポーネントによる１つ又は複数の入力レコードの処理中にエラーが発生した場合、コンポーネントの少なくとも１つの状態を保存済みの状態に回復し、回復した状態に基づいてデータフローグラフの所与のコンポーネントに関する監査データの少なくとも一部を回復するステップと、トランザクションの少なくとも一部を表す回復済みの監査データの少なくとも一部を監査ポート上で提供するステップと、１つ又は複数の出力レコードを出力ポート上で提供するステップとを含む、方法。動作中にシステムに特定の操作又はアクションを実行させるソフトウェア、ファームウェア、ハードウェア、又はそれらの組み合わせをシステム上にインストールすることにより、それらのアクションを実行するように１つ又は複数のコンピュータのシステムを構成することができる。データ処理機器によって実行されるとき機器に特定の操作又はアクションを実行させる命令を含めることにより、それらのアクションを実行するように１つ又は複数のコンピュータプログラムを構成することができる。

【0005】

一部の実装形態では、回復される監査データが第１の監査データであり、監査ポートが第１の監査ポートであり、所与のコンポーネントが第１のコンポーネントであり、この方法が、第１の監査データを第２のコンポーネントの第２の監査ポート上で出力される第２の監査データと指定の時間間隔で結合するステップを更に含む。所与のコンポーネントが第１のコンポーネントであり、回復される監査データが第１の監査データであり、この方法が、第１のデータ処理システム上で第１のコンポーネントを実行するステップと、第２のデータ処理システム上でデータフローグラフの第２のコンポーネントを実行するステップと、回復済みの監査データ及び第２のコンポーネントの第２の監査ポートから出力される第２の監査データを第３のデータ処理システム上で受信するステップとを更に含む。一部の実装形態では、この方法が、受信した回復済みの監査データ及び第２の監査データをメモリ内に記憶するステップと、記憶した監査データから１つ又は複数のメトリックを動的に生成するステップとを更に含む。一部の実装形態では、この方法が、第１の監査データ及び第２の監査データからデータを集約するステップと、その集約済みデータを記憶するステップとを更に含む。一部の実装形態では、この方法が、回復済みの監査データを特定の分類に割り当てることによって回復済みの監査データを分類するステップと、特定のキャンペーンに対するユーザの対話を示す監査メトリックを特定の分類に割り当てられた監査データから生成するステップとを更に含む。

【0006】

他の実装形態では、エラーが発生したことに応答し所与のコンポーネントが、複数のコンポーネントの少なくとも１つの状態を含み且つ入力レコードの１つ又は複数のどれが複数のコンポーネントの少なくとも１つによって前回成功裏に処理されたのかを指定するエラーログをエラーログポート上で出力し、状態はコンポーネントのどれが前回成功裏に処理を完了したのかを指定する。更に他の実装形態では、所与のコンポーネントがエラーログをエラーハンドラコンポーネントに出力し、エラーハンドラコンポーネントはエラーログに基づいてロールバックコンポーネントにメッセージを伝送し、ロールバックコンポーネントはメッセージを使用し、複数のコンポーネントの少なくとも１つが実行されており、複数のコンポーネントの少なくとも１つによって前回成功裏に処理された入力レコードの１つ又は複数が複数のコンポーネントの少なくとも１つによって処理されている状態へとデータフローグラフの状態を戻す。

【0007】

上記の内容の全て又は一部は、ハードドライブ、ダイナミックランダムアクセスメモリ等のランダムアクセスメモリ記憶装置、機械可読ハードウェア記憶装置、及び他の種類の非一時的機械可読記憶装置である、１つ若しくは複数の非一時的機械可読記憶媒体及び／又は１つ若しくは複数のコンピュータ可読ハードウェア記憶装置上に記憶され、１つ又は複数の処理装置上で実行可能な命令を含むコンピュータプログラム製品として実装することができる。上記の内容の全て又は一部は、１つ又は複数の処理装置及び述べた機能を実装するための実行可能命令を記憶するためのメモリを含み得る機器、方法、又は電子システムとして実装することができる。

【0008】

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

【0009】

本明細書に記載のシステムは、システムの計算資源に対する影響（メモリ及び／又は処理能力の消費等）を低減しながら又は最小限にしながら等、システムの性能を改善した状態でデータを処理することができる。加えて本明細書に記載のシステムはこのデータ（例えば入力データ、出力データ、監査データ、テストデータ、又はログデータ）をレイテンシを低減し且つ拡張性のあるやり方で処理する。具体的には、本システムは出力ポートに関してシステムの性能に悪影響を及ぼすことなしに監査データを回復可能なやり方で出力することができる。実行可能ロジックの実行のメトリックを動的に決定し、ユーザがそれらのメトリックをリアルタイムで追跡することができるように出力することができる。この脈絡において、システムのエラー状態がメトリックから検出されユーザに知らされ、そのユーザには好ましくは検出されたエラーを修正する方法の手引き（例えば指導）も提供される。更に、過度なデータ量の生成を減らしながら関心のある部分にロギングの的を絞るために、どの実行可能ロジックについてログレコードを生成すべきかをユーザが制御できることが好ましい。これらの事柄のそれぞれが、基礎を成すデータ処理システムをユーザが理解し、追跡し、資源効率の高いやり方で適切に動作させることを支援する。

【0010】

１つ又は複数の実施形態の詳細を添付図面及び以下の説明に記載する。本明細書に記載の技法の他の特徴、目的、及び利点がこの説明及び図面から、並びに添付の特許請求の範囲から明らかになる。

【図面の簡単な説明】

【0011】

図面の説明

【図1】データベース管理システムの概略図である。

【図2A】回復性を有する監査ポートを示す。

【図2B】回復性を有する監査ポートを示す。

【図2C】回復性を有する監査ポートを示す。

【図2D】回復性を有する監査ポートを示す。

【図2E】回復性を有する監査ポートを示す。

【図3A】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図3B】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図4A】データベース管理システムの概略図である。

【図4B】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図4C】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図5A】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図5B】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図6A】フローチャートの図である。

【図6B】フローチャートの図である。

【図6C】フローチャートの図である。

【図6D】フローチャートの図である。

【図6E】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図7】実行可能ロジックを用いた構造化データ項目の処理をロギングするための環境を示す。

【図8】回復性を有する監査ポート上の出力監査データにおけるプロセスの一例の図である。

【発明を実施するための形態】

【0012】

説明
本明細書に記載のシステムは、計算グラフ又はデータ処理グラフとも呼ばれるデータフローグラフのコンポーネント上の専用監査ポートを提供する。概して、データフローグラフはグラフ形式のコンピュータプログラムであり、計算を表し、計算の第１のプロセスを表す第１の頂点と、計算の第２のプロセスを表す第２の頂点と、第１の頂点を第２の頂点に接続し、第１のプロセスと第２のプロセスとの間のデータフローを表すリンクとを有し、第１の頂点及び第２の頂点は自らに関連する状態をそれぞれ有し、リンクは自らに関連する通信方法を有し、第１の頂点とリンクとの間の接続はその接続に関連する第１のアクセス方法を有し、第２の頂点とリンクとの間の接続はその接続に関連する第２のアクセス方法を有する。グラフの頂点はコンポーネントと呼ぶこともできる。コンポーネントは概して、データに適用される実行可能ロジックの一部を含む又は参照することによって実行可能であり、データを受信し、（実行可能ロジックの一部をデータに適用することによって）処理し、出力するための入力ポート及び出力ポート並びにログポート及びエラーポート、及び監査ポートを有する。コンポーネントがエラーに遭遇した場合、回復性がないのでログポート及びエラーポート上のデータが失われる。対照的に、監査ポート上のデータは重要であり、行われたトランザクションを表す。完了したトランザクションの数又は顧客が受諾したオファーの数等、有意味のメトリックが監査データから導出される。そのため監査ポートは、監査データ自体の回復性を与えるための回復性を実装する。監査ポートは直交データフローを提供するので、別個の監査ポートを有することにより、監査ポートは出力ポートの性能に影響を及ぼすことなしに監査データを回復可能な方法で出力することができる。

【0013】

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

【0014】

実行モジュール１６は、データレコード又はデータ項目を処理する際に実行される実行可能ロジックの１つ又は複数の部分に関する詳細、及び／又はコンピュータプログラム（例えば参照によりそのそれぞれの全内容を本明細書に援用する「ＥｘｅｃｕｔｉｎｇＣｏｍｐｕｔａｔｉｏｎｓＥｘｐｒｅｓｓｅｄａｓＧｒａｐｈｓ」と題された米国特許第５，９６６，０７２号明細書に記載の又は米国特許出願公開第２０１６／０３４２３９６号明細書に記載のデータフローグラフ等のチャート）を通るデータの状態及びデータがたどる経路に関する詳細を与えるロギング（例えばチャートロギング、データフローグラフロギング等）を実装する。本願では、「実行可能ロジックの一部」という用語は実行可能ロジックのサブセット、例えば実行可能ロジックの１００％未満を意味し得る。一部の例では、例えば１つ又は複数のフィールドを有するデータレコードであって、各フィールドが実行可能ロジックの特定の部分を用いて特定のデータ項目を処理することの特性又は属性を表す値を記憶する、データレコードを含む監査レコードを生成することによって実行モジュール１６がこのロギングを実装する。以下でより詳細に説明するように、下記では監査レコードをログレコード又は監査データと呼ぶ場合もある。一部の例では、そのデータレコード（本明細書では「データ項目」とも呼ぶ）がコンピュータプログラムによって処理される固有のキー（例えば識別子（ＩＤ））ごとに実行モジュール１６がロギングを実装する。一部の例では、参照によりその全内容を本明細書に援用する米国特許出願公開第２００９／０３２７１９６号明細書に記載されているようなグラフベースの計算として表されるコンピュータプログラムのためのデータロギングを実行モジュール１６が実装する。本願では、「データフローグラフ」又は「チャート」という用語は「コンピュータプログラム」の例として又は他の言葉として使用する。一部の例では便宜上「データフローグラフ」又は「チャート」という用語を本明細書の中で交換可能に及び区別なく使用する。一部の例では、固有のキーはレコードがチャートによって処理される各顧客の顧客ＩＤを表す。メトリック（例えばチャートのどの部分が横断されたのかを示すメトリック及びチャートの一定の部分がレコード群によって横断された回数を示す集約メトリック）等のロギング情報をユーザインタフェースが表示する。本明細書の全体を通して記載するメトリックは動的に、例えば実行可能ロジックの実行中に決定することができる。換言すれば、これらのメトリックは静的ではなく動的に変化することができ、リアルタイムで継続的に更新することができる。本明細書の全体を通して記載するメトリックは、データ項目を処理する際に実行される実行可能ロジックの１つ又は複数の部分の計算性能属性に関する情報を提供し得る。この例では、チャート（例えばデータフローグラフ）がデータ記憶域２６（本明細書ではメモリ２６とも呼ぶ）内に記憶され得る。データソース１２を提供する記憶装置は実行環境１４にとってローカルとする、例えば実行環境１４を実行するコンピュータに接続される記憶媒体（例えばハードドライブ１７）上に記憶することができ、又は実行環境１４にとって遠隔的とする、例えば実行環境１４を実行するコンピュータとローカルデータネットワーク又は広域データネットワーク上で通信する遠隔システム（例えばメインフレーム２０）上にホストすることができる。

【0015】

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

【0016】

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

【0017】

この例では、データフローグラフがグラフィカル層及びデータ処理層を含む。グラフィカル層は、グラフィカルユーザインタフェース内の可視要素（例えばノード、データ処理コンポーネント、ポート、及び矢印又はリンク）を含む。便宜上及び制限なしに、本明細書ではデータ処理コンポーネント及びそのデータ処理コンポーネントによって表される基礎を成すプログラムコード（例えば実行可能ロジック）をまとめて「データ処理コンポーネント」と呼ぶ場合がある。同様に、便宜上及び制限なしに、本明細書ではポート（例えばコンピュータポート又はインタフェースの可視要素）及びそのポートによって表される基礎を成すプログラムコード（例えば実行可能ロジック）をまとめて「ポート」と呼ぶ場合がある。一部の例では、ポートはシステムへのインタフェース、ソフトウェアプログラム若しくは実行可能ロジックへのインタフェース、又はシステム、ソフトウェアプログラム、若しくは実行可能ロジックへの通信経路である。便宜上及び制限なしに、本明細書ではデータフローグラフ及びそのデータフローグラフによって表される基礎を成すプログラムコード（例えば実行可能ロジック）をまとめて「データフローグラフ」と呼ぶ場合がある。便宜上及び制限なしに、本明細書ではチャート及びそのチャートによって表される基礎を成すプログラムコード（例えば実行可能ロジック）をまとめて「チャート」と呼ぶ場合がある。実行される実行可能ロジックはデータ処理層の一部であるのに対し、表示されるノード、コンポーネント、及び矢印はグラフィカル層の一部であり、データフローグラフによって表される実行可能ロジックを実行する方法に関する情報をカプセル化する。

【0018】

一部の事例では、データフローグラフの構築は実際に極めて技術的であり得る。特定のビジネスの目的を達成するために書かれるが、グラフの基礎を成す構造及び構築は技術的検討に基づいて決定される。例えばグラフコンポーネントは、再利用可能性を最大化するように又は並列処理をサポートするように選択することができる。かかるパラメータ化されたデータフローグラフに関連するパラメータの一部は、その実装の背後にある技術的な複雑さをビジネスユーザが理解することを必要とせずに、ユーザがデータフローグラフをカスタマイズできるようにするために使用することができる。パラメータ化されたデータフローグラフはカスタマイズを簡単にし、再利用を促進する。

【0019】

換言すれば、図１に示すコンピュータシステム１０は、データ記憶域２６に結合される任意選択的な開発環境２８であって、開発環境２８はデータ処理コンポーネントのチャート又はグラフにより１つ又は複数の入力データセットから１つ又は複数の出力データセットに流れるデータに対して実行される計算を実装するチャート又はデータフローグラフに関連するコンピュータプログラムを構築するように構成され、チャート又はデータフローグラフはデータ記憶域２６内のデータ構造によって指定され、データ構造によって指定され且つ１つ又は複数のリンクによって接続されるデータ処理コンポーネントを表す複数のノードを有し、リンクはデータ構造によって指定され、データ処理コンポーネント間のデータフローを表す、任意選択的な開発環境２８と、データ記憶域２６に結合され１つ又は複数のコンピュータ上にホストされる実行環境１４であって、実行環境１４はチャート又はデータフローグラフを指定する記憶済みのデータ構造を読み出すように、及び実行モジュール１６によってチャート又はデータフローグラフに割り当てられるデータ処理コンポーネントの計算を実行するための計算資源を割り当てて構成するように構成される実行モジュール１６を含み、本明細書に記載の方法又はプロセスの何れか１つが実行されるように実行モジュール１６はデータ処理コンポーネントの割り当て済みの計算の実行をスケジューリングし制御するように構成される、実行環境１４とを含み得る。実行モジュール１６は、データソース１２からデータを読み出し、チャート又はデータフローグラフ形式で表される実行可能コンピュータプログラムを使用してデータを処理するように構成される。

【0020】

この例では、監査レコード（又は「ログレコード」とも呼ぶ）が、データレコード又はイベントを処理する際に横断されるノード（及び／又は実行されるデータ処理コンポーネント）を指定するデータ項目（例えば構造化データ項目）、及びデータレコード又はイベントを処理することの１つ又は複数の属性を含む。一部の例では、ログレコードは、特定のキー値に関する仕様の状態を表すデータを記憶するための第１のフィールドを有する構造化データレコードである。概して仕様は、例えばデータ項目を処理する際に実行される実行可能ロジックの視覚的表現である。そのため仕様はチャート、データフローグラフ等とすることができ、又はそれらを含み得る。以下でより詳細に説明するように、仕様はグラフィカル層の一部である。概して、実行可能ロジックはソースコード及び他のコンピュータ命令を含む。ログレコードは、その特定のキー値について実行可能ロジックの実行を開始した時点から現時点まで、仕様によって表される実行可能ロジックのどの部分が実行されているのか（及び／又は複数の分散されたマシンの中のどのマシン上でそのロジックが実行されたのか）を指定するデータを記憶するための第２のフィールドを含み得る。概して及びこの例では、（例えば特定のキーについて）データレコードを処理すると、システムはその特定のキー値について実行可能ロジックの実行を開始した時点から現時点まで、監査レコード（又は１つ若しくは複数の監査レコード）を生成し、特定のキー値に関する仕様の状態を表すデータを第１のフィールド内に記憶し、仕様によって表される実行可能ロジックのどの部分が実行されているのかを指定するデータを第２のフィールド内に記憶する。更に他の例ではログレコードは、仕様によって表される実行可能ロジックのどの部分が特定のキー値について現時点において実行されているのかを指定するデータを記憶するためのフィールドを有する構造化データレコードである。この例では、ログレコードを生成すると、システムは仕様によって表される実行可能ロジックのどの部分が特定のキー値について現時点において実行されているのかを指定するデータを用いてログレコードのフィールドにデータ投入する。更に他の例では、仕様がチャートであり、１つ又は複数のログレコードが、特定のキー値に関連する１つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定する。この例ではシステムが、特定のキー値に関連する１つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定するログレコードを生成する。更に他の例では、システムが１つ又はデータ項目を処理することに基づいて１つ又は複数の出力レコードを生成する。この例では、１つ又は複数の出力レコードのそれぞれがログレコード内に含まれないデータを含む。

【0021】

以下でより詳細に説明するように、様々な種類の監査レコードが様々なフィールドと共に予め定められ、それぞれのフィールドの種類はデータレコード又はイベントを処理することの１つ又は複数の属性を指定する。概してイベントは、特定の発生又は発生の欠如を表す（例えば既定の形式の）データレコードを含む。

【0022】

この例では、性能モニタリングモジュール１８が監査レコード及び実行モジュール１６の性能に関する他の性能メトリックを収集する。性能モニタリングモジュール１８は、実行モジュール１６から監査レコードを収集する監査ログモジュール２４（本明細書では「集約エンジン」とも呼ぶ）を含み、実行モジュール１６は更には各データ処理コンポーネントから監査レコードをそれぞれ作成する複数の別個のチャートを実行している場合がある。監査ログモジュール２４は、例えば本明細書に記載の通りに監査ログを分類する分類器２４ａを含む。監査ログモジュール２４は、監査レコードのコンテンツを「マスタ」ログ（例えば指定の期間にわたって受信される監査レコードのコンテンツを含むログレコード）へと結合することによって（例えば指定の時間間隔において）受信済みの監査レコードを集約する。これらの集約済みのログレコードは、例えばその後のアクセスのためにデータ記憶域２６内に記憶され、及び／又は集約済みの監査レコードからメトリックを生成するメトリック生成モジュール２５に伝送するためにデータストア４０内に記憶される。概してメトリックは、例えば読み出されたレコード数、読み出されたバイト数、書き込まれたレコード数、書き込まれたバイト数、使用されたプロセッサ時間、及び経過時間のうちの一部又は全てを含む集約レベルにおける詳細データを含む。メトリックはイベント（例えばデータレコード）ごとの、従ってイベントの種類ごとのシステムによる計算レイテンシも指定し得る。集約済みの監査レコードから生成される他の種類のレイテンシメトリックは、レイテンシメトリック（例えばデータレコードがソースにおいて作成されたときから現時点、つまり「今の」時点までの時間）、データレコードがソースにおいて作成されたときからデータレコードがシステムによって最初に認められたときまでのレイテンシを指定する外部レイテンシメトリック、データレコードがシステムによって最初に認められたときから今の時点までのレイテンシを指定する内部レイテンシメトリック、及び論理時間から今の時点までのレイテンシを指定する論理遅延メトリックを含む。システムは、コンピュータプログラムの個々のプロセス（データフローグラフ内の個々のコンポーネント等）の実行時間、プログラム又はグラフの総実行時間、特定のプログラム又はグラフに関するプログラム又はグラフの平均実行時間等、数多くの他の種類のメトリックを計算することもできる。メトリック生成モジュール２５は生成したメトリックをデータストア４２に出力する。

【0023】

性能モニタリングモジュール１８は、メトリック生成モジュール２５から生成される１つ又は複数のメトリックを含む、及び／又は収集済みの監査レコードからの未処理の（及び／又は集約済みのデータ）を含む出力データセットを（例えばデータストア４０、４２の１つ又は複数から取得されるデータから）生成する。この例では、環境１４（例えばデータ処理システム）が出力データセットの１つ又は複数の部分をユーザインタフェース内に表示する。

【0024】

図２Ａを参照し、実行モジュール１６が第１の時点Ｔ１においてデータフローグラフ２３を記憶する（又はそれにアクセスする）。この例では、データフローグラフ２３がデータソース２３ａ、コンポーネント２３ｂ、２３ｃ、２３ｅ、２３ｊ、２３ｌ、２３ｍ、及びデータシンク２３ｚ、２３ｎを含む。

【0025】

この例では、データフローグラフ２３は単方向リンクによって結合される幾つかの頂点（即ちソース２３ａ、コンポーネント２３ｂ、２３ｃ、２３ｅ、２３ｊ、２３ｌ、２３ｍ、及びデータシンク２３ｚ、２３ｎ）を含む計算グラフの一例である。計算グラフ２３は、トランザクション処理システムに関連する計算グラフに従って処理される個々のトランザクション等、一連の作業要素で構成されるワークフローを処理する。トランザクションは複数の作業要素で構成され得る。各コンポーネントは、全体的な計算グラフによって定められる計算の一部に関連する。この例では、コンポーネント２３ａが１つ又は複数のトランザクションに関連する最初の一連の作業要素のための記憶域へのアクセスを提供し、その一連を自らの出力リンク上で伝える。コンポーネントのそれぞれに関連する計算を実装するプロセスは作業要素を順に処理し、典型的にはその頂点の出力リンクの１つ又は複数の上に作業要素をもたらす。

【0026】

この例ではコンポーネント２３ｅが、入力レコードを受信するための入力ポート２３ｄ、出力レコードを出力するための出力ポート２３ｆ、エラーログを出力するためのエラーログポート２３ｇ、及び監査データを出力するための監査ポート２３ｈを含む。この例では、監査ポート２３ｈが監査データをデータシンク２３ｎに、例えば監査データを収集するための専用データソースに出力するように構成される。同様にコンポーネント２３ｊは、（出力レコードをデータシンク２３ｚに出力するための）出力ポート２３ｏ、（エラーログをエラーハンドラコンポーネント２３ｌに出力するための）エラーログポート２３ｐ、及び監査データをデータシンク２３ｎに出力するための監査ポート２３ｑを有する。

【0027】

この例ではデータフローグラフ２３が、例えばコンポーネント（例えば２３ｒ、２３ｊ）による処理中にエラーが発生した場合にエラーメッセージを受信するエラーハンドラコンポーネント２３ｌを含む。データフローグラフ２３は、エラーの前の状態にデータフローグラフを戻し又はロールバックするロールバックコンポーネント２３ｍも含む。概してロールバックは、フェイルオーバが時点まで処理済みデータを巻き戻すこと、従って処理済みを前の無矛盾の時点まで「巻き戻すこと」を可能にする。具体的には、コンポーネント２３ｊからの入力データは、グラフ２３がトランザクションの処理を開始する前に事柄（例えばデータ又はコンポーネント）の状態が何だったのか、具体的にはコンポーネント２３ｅが実行を開始する前にグラフ２３の状態が何だったのかをエラーハンドラコンポーネント２３ｌに伝える。以下でより詳細に説明するように、エラーハンドラコンポーネント２３ｌはそれをロールバックコンポーネント２３ｍに出力し、ロールバックコンポーネント２３ｍはそれを使用して、他のコンポーネントによって修正された任意のデータをトランザクションの実行前の状態に回復する。

【0028】

図２Ｂを参照し、データ処理システムが第２の時点Ｔ２においてデータフローグラフを実行する。この例では、ソースコンポーネント２３ａが入力レコード２３ｒをコンポーネント２３ｂに伝送し、コンポーネント２３ｂは入力レコード２３ｒを処理してレコード２３ｓを出力する。次いでレコード２３ｓがコンポーネント２３ｃに入力され、コンポーネント２３ｃはレコード２３ｓを処理し、その処理に基づいてレコード２３ｔを出力する。コンポーネント２３ｃはレコード２３ｔをコンポーネント２３ｅに伝送し、コンポーネント２３ｅはレコード２３ｔである入力レコードを入力ポート２３ｄにおいて受信する。それを受けてコンポーネント２３ｅが入力レコード２３ｔを処理し、出力レコード２３ｖを出力ポート２３ｆ上で出力する。コンポーネント２３ｅは、どのレコード（即ちレコード２３ｔ）がコンポーネント２３ｅによって処理されるのかをチェックポイントするチェックポイント操作も実装することができる。チェックポイント操作は、データフローグラフ２３の現在の状態が、コンポーネント２３ｅが成功裏に実行しレコード２３ｔを処理した状態であることを指定するチェックポイントメッセージ２３ｕを生成する。コンポーネント２３ｅは更に、チェックポイントメッセージ２３ｕを出力ポート２３ｆ上で出力する。この例では、コンポーネント２３ｅが自らの入力レコードを成功裏に処理するので、エラーログポート２３ｇ上では何も出力されない。コンポーネント２３ｅは、入力レコード２３ｒによって表されるトランザクションの１つ又は複数の部分を表す監査データ２３ｗを監査ポート２３ｈ上で出力する。

【0029】

図２Ｃを参照し、第３の時点Ｔ３においてデータフローグラフ２３の実行がコンポーネント２３ｊに進み、コンポーネント２３ｊは出力ポート２３ｏ、エラーログポート２３ｐ、及び監査ポート２３ｑを含む。この例では、コンポーネント２３ｊがレコード２３ｖ及びチェックポイントメッセージ２３ｕを入力として受信する。コンポーネント２３ｊは入力レコード２３ｖを処理する際にエラーに遭遇する。この時点において、コンポーネント２３ｊがエラーに遭遇し入力レコード２３ｖの処理を完了し処理に由来する監査データを出力することができなかったので、コンポーネント２３ｊにおいて入力レコード２３ｖを処理することによる監査データが失われる。そのため、コンポーネント２３ｊはエラーログ２７ａをエラーログポート２３ｐ上で出力し、エラーログ２７ａは最後の成功裏に実行されたコンポーネントの状態を含み、どの入力レコード（即ちレコード２３ｔ）がそのコンポーネントによって最後に成功裏に処理されたのかも指定する。この時点において、コンポーネント２３ｊは目下有効にされているエラーハンドラコンポーネント２３ｌにエラーログ２７ａを出力する。エラーハンドラコンポーネント２３ｌは、最後の成功裏に実行されたコンポーネントであるコンポーネント２３ｅの状態（即ち状態Ｃ３）及びそのコンポーネントによってどのレコードが処理されたのかを指定するメッセージ２７ｂを（同じく目下有効にされている）ロールバックコンポーネント２３ｍに伝送する。メッセージ２７ｂを使用し、ロールバックコンポーネント２３ｍは図２Ｄに示すようにコンポーネント２３ｅが実行されておりレコード２３ｔが処理されている状態へとデータフローグラフ２３の状態を戻し、従ってコンポーネント２３ｊに関する監査データの回復性を有効にする。

【0030】

図２Ｅを参照し、コンポーネント２３ｅが実行し入力レコード２３ｄを処理する状態へとデータフローグラフ２３の状態が戻される。この例では、コンポーネント２３ｊが入力レコード２３ｖを成功裏に処理し、データシンク２３ｚ内に保存される出力レコード２７ｄを出力ポート２３ｏ上で出力することができる。この例ではエラーログポート２３ｐ上でエラーログが出力されず、データシンク２３ｎ内に保存される監査データ２７ｃを監査ポート２３ｑが出力する。この例では監査データ２７ｃが回復済みの監査データである。本明細書に記載の通り、収集されデータシンク２３ｎ内に保存される監査データ２３ｗ、２７ｃは集約され結合され得る。

【0031】

図３Ａを参照し、環境１０は含み、実行モジュール１６によって実行されるグラフ等のプログラムから監査レコードを収集する（及びそれらの収集済みの監査レコードからメトリックを生成する）。

【0032】

実行モジュール１６はグラフ３０等のコンピュータプログラムを実行する。一部の実装形態では、グラフ３０が事前にコンパイルされていてもよい。この例では、実行モジュールはコンピュータシステムによって実行されるプロセス又は１組のプロセスであり得る。グラフは、データ記憶域２６（図１）等の非一時的コンピュータ可読記憶装置内に記憶され得る１組のコンピュータ可読命令であり得る。グラフ３０はデータストア、例えば図１のデータ記憶域２６からロードされ得る。

【0033】

この例では、グラフ３０が、入力ポート３２ａ、出力ポート３２ｂ、及び監査ポート３２ｃを含むコンポーネント３２を含む。本明細書では監査ポートを「ログポート」又は「インタフェース」と呼ぶ場合もある。概して、監査ポートは監査レコード（本明細書では「ログ」又は「ログレコード」とも呼ぶ）を出力するためのポートである。一部の例では、監査ポートが監査レコード又はログレコードを出力するためのインタフェースを含み、監査ポートは監査レコードを出力するためだけの専用ポートであり得る。この例では、監査ポートが入力ポート及び出力ポートのそれぞれと分かれている。この例では、コンポーネント３２がデータソース３４からデータを読み出し、その読み出しデータを入力ポート３２ａ経由で受信する。この例では、コンポーネント３２（又はコンポーネント３２によって表される実行可能ロジック）が１つ又は複数の監査レコードを生成し、それらの監査レコードをポート３２ｃ上で出力する。コンポーネント３２はリンク３８によって別のコンポーネント３６に接続される。コンポーネント３６は、入力ポート３６ａ、出力ポート３６ｂ、及び監査ポート３６ｃを含む。コンポーネント３２の出力ポート３２ｂからのデータレコードがコンポーネント３６の入力ポート３６ａ内に伝えられる。概してポートは、データフローグラフのコンポーネントがデータを受信し又は提供することができる任意の機構を指す。ポートは、例えば伝送制御プロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）ポート、ネットワークソケット、又はソフトウェアパイプであり得る。ポートは、例えば共用メモリへの読み書き等、コンポーネント間の他の通信方法を指す場合もある。

【0034】

コンポーネント３６は出力レコード５１ａ～５１ｂ（図３Ｂ）を出力ポート３６ｂ上に作成し、それらの出力レコードはデータストア３８内に記憶され得る。この例では、コンポーネント３６がコンポーネント（３２又は３６）の性能特性をモニタし記録し、それらのモニタリング及び／又は性能特性を含む監査レコードを生成する。例えばコンポーネント３６は、使用されたプロセッサ時間、経過時間、読み出しバイト数、読み出しレコード数、書き込みバイト数、書き込みレコード数、実行回数、実行に失敗した回数、総持続時間、平均レコード処理速度（レコード／秒）、平均バイト処理速度（バイト／秒）等の何れか１つ又は組み合わせ等の性能メトリックを収集し、それらの収集済みのメトリックを監査レコード内に含めることができる。

【0035】

監査レコードは、コンポーネント３６の監査ポート３６ｃ上に（例えばコンポーネント３６によって、又はコンポーネント３６によって表される基礎を成す実行可能ロジックによって）作成することができる。例えば監査レコードは、コンポーネント３６の性能に関する情報及び先に記載した他の情報を含む１つ又は複数のレコードであり得る。

【0036】

この例では、ポート３２ｃ、３６ｃ上で出力される監査レコードが監査ログモジュール２４によって収集される。この例では、以下でより詳細に説明するように監査ログモジュール２４が監査レコードを後処理する。監査ログモジュール２４は更に、収集済みの監査レコード内のデータを指定の時間間隔において（例えば１時間ごとに）結合し及び／又はロールアップする。概して「結合」操作は２つ以上の別個のファイル又はデータレコードからのデータを組み合わせることを指す。概して「ロールアップ」操作は、１つ又は複数のファイル又はデータレコードからデータを集約し、その集約済みのデータを出力することを指す。例えばロールアップ操作は、１つ又は複数のデータレコード内のフィールド内の値に基づいて和、最小、最大を計算することができる。この例では、監査ログモジュール２４が指定の時間間隔において集約済みの監査レコード（例えばその特定の時間間隔の間に収集される個々の監査レコードに対して結合及び／又はロールアップ操作を行うことによって生成される監査レコード）を作成する。監査ログモジュール２４は、集約済みの監査レコードを性能モニタリングモジュール１８内のデータストア４０に伝送する。一部の実装形態では、監査レコードを書き込む性能上の影響を最小化するようにデータストア４０が選択される。例えば、データストア４０に監査レコードを書き込むことによって生じるレイテンシを減らすことが有利であり得る。一部の実装形態では、データストア４０が共用メモリ４０内に位置し得る。共用メモリ４０はランダムアクセスメモリ（ＲＡＭ）等の高速メモリであり得る。共用（例えば半導体）メモリに書き込む操作は概して少ないオーバヘッドを生ぜしめ、その結果低速メモリ、つまり磁気ディスク（例えばハードディスク）等の永続データ記憶域に書き込む同様の操作よりも高速である。この例では、例えば集約済みの監査レコードと共に収集済みの監査レコードを指定の時間間隔において記憶することにより、監査ログモジュール２４が収集済みの監査レコードをデータストア４０内に一括で記憶する。

【0037】

断続的に、例えば５分、１０分、又は３０分ごとに、メトリック生成モジュール２５は集約済みの監査ログをデータストア４０から読み出し、集約済みの監査ログから性能メトリックを生成する。メトリック生成モジュール２５は集約済みの監査ログ（及び／又は保存されている場合は個々の監査ログ）をデータストア４０から読み出すことができ、そのデータを更に処理し集約することができる。例えばメトリック生成モジュール２５は、単一のトランザクションを一緒に構成する複数のプログラム又はデータフローグラフに関連する性能メトリックを監査ログ内に含まれるデータに基づいて組み合わせることができる。性能モニタリングモジュール１８は、出力データセット内にそれらのメトリックを含めることにより、性能メトリックをユーザにグラフィカルに提示し或いは出力することができる。メトリック生成モジュール２５は性能メトリックをデータストア４２に書き込む。一部の実装形態では、データストア４２が永続データストア内に位置し得る。次いでデータストア４２は、生成済みのメトリックの少なくとも一部を出力データセットとして出力する。この例では、コンポーネント３２及び３６がコンピュータプログラムの実行可能ロジックの２つの異なる部分の２つの説明的な例を表す。

【0038】

図３Ｂは、データフローが示されている図３Ａの改変形態である。この例では、コンポーネント３２がデータソース３４からデータレコード４４ａ～４４ｄを（入力ポート３２ａ上で）受信する。コンポーネントは、受信データレコード４４ａ～４４ｄのそれぞれを処理する。この例では、コンポーネント３２が処理されるデータレコードのそれぞれについて監査レコードを生成する。そのためコンポーネント３２は、データレコード４４ａ～４４ｄのそれぞれについて監査レコード５０ａ～５０ｄを生成する。この例では、コンポーネント３２が監査レコード５０ａ～５０ｄのそれぞれをポート３２ｃ上で出力し、監査レコード５０ａ～５０ｄをポート３２ｃ経由で監査ログモジュール２４に伝送する。この例ではポート３２ｃが、監査ログを生成するためだけの及びそれらの監査ログを監査ログモジュール２４に送信するためだけの専用インタフェースである。

【0039】

この例では、レコード４４ａ～４４ｄのそれぞれを処理した後、コンポーネント３２がレコード４６ａ～４６ｃを出力ポート３２ｂ上で出力し、レコード４６ａ～４６ｃはコンポーネント３６の入力ポート３６ａに伝送される。この例では、コンポーネント３２によるレコード４４ａ～４４ｄの処理が３つの出力レコード４６ａ～４６ｃだけをもたらす。コンポーネント３６はレコード４６ａ～４６ｃを処理し、レコード４６ａ～４６ｃのそれぞれについて監査レコード４８ａ～４８ｃを生成し、それらのレコードは出力ポート３６ｃ上で出力され、監査ログモジュール２４に伝送される。この例では、監査ログモジュール２４が監査レコード４８ａ～４８ｃ及び５０ａ～５０ｄを収集し、それらの監査レコード４８ａ～４８ｃ及び５０ａ～５０ｄに対してロールアップ及び／又は結合操作を実行して集約済みの監査レコードを作成する。監査ログモジュール２４は集約済みの監査レコードをデータストア４０（例えば共用ＲＡＭ）に伝送する。メトリック生成モジュール２５は集約済みの監査レコードを読み出し、それを受けて本明細書に記載の様々なメトリックを表すメトリックデータ（又はデータレコード）を生成する。メトリック生成モジュール２５は、記憶するために及びメトリックデータの少なくとも一部を出力データセットに出力するために、メトリックデータをデータストア４２に伝送する。

【0040】

図４Ａを参照し、環境１０の改変形態を示す。この改変形態では、実行モジュール１６がデータ処理システム６２（本明細書では第１の処理システム６２とも呼ぶ）及びデータ処理システム６４（第２の処理システム６４とも呼ぶ）という２つの別個のシステムを含む。処理システム６２はメモリ６２ａ及び実行サブシステム６２ｂを含む。処理システム６４はメモリ６４ａ及び実行システム６４ｂを含む。処理システム６２、６４のそれぞれは、例えばデータフローグラフ、チャート等を表す実行可能ロジックを含むコンピュータプログラムの様々な種類の実行可能ロジックを実行するように構成される。この例では、監査ログモジュール２４がシステム６２、６４のそれぞれから出力（例えば監査又はログレコード）を受信する。システム６２、６４は分散型の処理システムである。

【0041】

図４Ｂを参照し、環境６０は（実行モジュール１６内に含まれる）データ処理システム６２、６４、及び性能モニタリングモジュール１８をやはり含む実行環境１４を含む。この例では、データ処理システム６２がコンポーネント７４ａ、７５ａ、７６ａ、７８ａ、８０ａ、８２ａ、８４ａ、及びデータストア８６ａ、８８ａを有する（特定のデータフローグラフのバージョンである）データフローグラフ６６ａを表す実行可能ロジックを実行する。以下、データフローグラフ及び／又はチャートの実行は、データフローグラフ又はチャートをそれぞれ表す実行可能ロジックの実行を指す。この例ではコンポーネントは、データ処理エンティティ間のデータフローを表す１つ又は複数のリンクによって接続される複数のデータ処理エンティティ（例えば１つ又は複数のＣＰＵ）を表し得る。データ処理システム６４は、データ処理システム６２によって実行される特定のデータフローグラフの別のバージョンであるデータフローグラフ６６ｂを表す実行可能ロジックを実行する。この例では、データ処理システム６２、６４が入力される受信データレコード（例えば１つのデータストリームから又は複数のデータストリームから受信されるデータレコード）を並列処理するための分散型システムである。改変形態では、データ処理システム６２、６４のそれぞれが別個のデータフローグラフを実行している場合もある。

【0042】

この例では、データフローグラフ６６ａ、６６ｂのそれぞれが、リアルタイム入力データストリーム内に含まれるデータ項目に対するプロセスを実行する。この例では、データ処理システム６２、６４のそれぞれが、データレコード（例えば全ての記録され及び／又は受信されるイベントのワイドレコード）を生成し、その生成済みのレコードをデータストア８６ａ、８６ｂに（それぞれ）発行する際にデータフローグラフ６６ａ、６６ｂを（それぞれ）実行する。

【0043】

データフローグラフ６６ａは、ソースデータリーダ又は複数のソースデータリーダをサブスクライブする（例えばそこからデータを受信する）サブスクライブコンポーネント７５ａを含む。サブスクライブコンポーネント７５ａにより、データフローグラフ６６ａはリアルタイムデータストリーム内に含まれるデータ項目にリアルタイムでアクセスする。この例では、サブスクライブコンポーネント７５ａが（例えば数千ものレコードを含む）リアルタイム入力データストリームを（例えばその可読性を保証するためにデータストリームに対して幾らかの初期処理を行い得る）データ待ち行列から受信する。データはサブスクライブコンポーネント７５ａから分割コンポーネント７４ａに流れ、分割コンポーネント７４ａはデータフロー内で受信される（イベントを含む）データ項目をイベントの種類ごとに分割し又は分ける。この例では、分割コンポーネント７４ａが様々な種類のデータレコード又はイベントを検出するように構成され、特定の種類のイベントを処理するように構成される他のコンポーネントに対して様々な種類のイベントを分割する。この例では、コンポーネント７６ａ、７８ａ、８０ａ、８２ａのそれぞれが特定の種類のイベントを処理するように構成される。

【0044】

この例では、データフローグラフ６６ｂが結合操作を実装する結合コンポーネント８４ａを含む。結合操作は様々な種類のデータ、例えばコンポーネント７６ａ、７８ａ、８０ａ、８２ａからのイベントを結合する。この例では、データがコンポーネント７６ａ、７８ａ、８０ａ、８２ａから結合コンポーネント８４ａに流れ、結合コンポーネント８４ａはそれらのイベントをワイドレコード（例えば様々な処理済みのレコード内に含まれる値を記録するためのフィールドを有するデータレコード）内で結合する。この例では、イベントコンポーネント７６ａ、７８ａ、８０ａ、８２ａのそれぞれが、エンティティのためのユーザＩＤ等、イベントに関連するエンティティを一意に識別するデータに関連してイベントを結合コンポーネント８４ａに送信する。結合コンポーネント８４ａの出力は、どの特定の既定のイベント及びそれらのイベントに関連するユーザＩＤがを指定するデータを有するデータレコードである。しかし改変形態では、結合コンポーネント８４ａの出力は、コンポーネント７６ａ、７８ａ、８０ａ、８２ａによる受信データレコードの処理を表すコンテンツを有するデータレコードであり得る。この例では、データ（例えばデータレコード）が結合コンポーネント８４ａからデータストア８６ａに流れ、結合コンポーネントから出力されるデータレコードが出力される。

【0045】

この例では、（データ処理システム６２上で実行される）コンポーネント７４ａ、７５ａ、７６ａ、７８ａ、８０ａ、８２ａ、８４ａのそれぞれが監査ポート７４ｃ、７５ｃ、７６ｃ、７８ｃ、８０ｃ、８２ｃ、８４ｃを有し、それらの監査ポートは個々のコンポーネントによって１つ又は複数のデータレコードを処理することの１つ又は複数の属性を表す１つ又は複数の監査レコードをそれぞれ出力する。例えば監査ポート７４ｃは、コンポーネント７５ａから受信されるデータレコードに対して分割操作を行うことを示す監査レコードを出力する。データ処理システム６２上で実行されるデータストア８８ａが、監査ポート７４ｃ、７５ｃ、７６ｃ、７８ｃ、８０ｃ、８２ｃ、８４ｃ上で出力される監査レコードを受信し、本明細書に記載の更なる処理のためにそれらの監査レコードを（例えば１時間ごと等の指定の時間において）監査ログモジュール２４に伝送する。この例では、コンポーネント７４ａ、７６ａ、７８ａ、８０ａ、８２ａ、及び８４ａがコンピュータプログラムの実行可能ロジック（ここではデータフローグラフ６６ａ）の様々な部分の説明的な例を表す。

【0046】

データフローグラフ６６ｂは、ソースデータリーダ又は複数のソースデータリーダをサブスクライブする（例えばそこからデータを受信する）サブスクライブコンポーネント７５ｂを含む。サブスクライブコンポーネント７５ｂにより、データフローグラフ６６ｂはリアルタイムデータストリーム内に含まれるデータ項目にリアルタイムでアクセスする。この例では、サブスクライブコンポーネント７５ｂが（例えば数千ものレコードを含む）リアルタイム入力データストリームを（例えばその可読性を保証するためにデータストリームに対して幾らかの初期処理を行い得る）データ待ち行列から受信する。データはサブスクライブコンポーネント７５ｂから分割コンポーネント７４ｂに流れ、分割コンポーネント７４ｂはデータフロー内で受信される（イベントを含む）データ項目をイベントの種類ごとに分割し又は分ける。この例では、分割コンポーネント７４ｂが様々な種類のデータレコード又はイベントを検出するように構成され、特定の種類のイベントを処理するように構成される他のコンポーネントに対して様々な種類のイベントを分割する。この例では、コンポーネント７６ｂ、７８ｂ、８０ｂ、８２ｂのそれぞれが特定の種類のイベント（例えばレコード）を処理するように構成される。

【0047】

この例では、データフローグラフ６６ｂが結合操作を実装する結合コンポーネント８４ｂを含む。結合操作は様々な種類のデータ、例えばコンポーネント７６ｂ、７８ｂ、８０ｂ、８２ｂからのイベントを結合する。この例では、データがコンポーネント７６ｂ、７８ｂ、８０ｂ、８２ｂから結合コンポーネント８４ｂに流れ、結合コンポーネント８４ｂはそれらのイベントをワイドレコード（例えば様々な処理済みのレコード内に含まれる値を記録するためのフィールドを有するデータレコード）内で結合する。この例では、イベントコンポーネント７６ｂ、７８ｂ、８０ｂ、８２ｂのそれぞれが、エンティティのためのユーザＩＤ等、イベントに関連するエンティティを一意に識別するデータに関連してイベントを結合コンポーネント８４ｂに送信する。結合コンポーネント８４ｂの出力は、どの特定の既定のイベント及びそれらのイベントに関連するユーザＩＤがを指定するデータを有するデータレコードである。しかし改変形態では、結合コンポーネント８４ｂの出力は、コンポーネント７６ｂ、７８ｂ、８０ｂ、８２ｂによる受信データレコードの処理を表すコンテンツを有するデータレコードであり得る。この例では、データ（例えばデータレコード）が結合コンポーネント８４ｂからデータストア８６ｂに流れ、結合コンポーネントから出力されるデータレコードが出力される。

【0048】

この例では、（データ処理システム６４上で実行される）コンポーネント７４ｂ、７５ｂ、７６ｂ、７８ｂ、８０ｂ、８２ｂ、８４ｂのそれぞれが監査ポート７４ｄ、７５ｄ、７６ｄ、７８ｄ、８０ｄ、８２ｄ、８４ｄを有し、それらの監査ポートは個々のコンポーネントによって１つ又は複数のデータレコードを処理することの１つ又は複数の属性を表す１つ又は複数の監査レコードをそれぞれ出力する。例えば監査ポート７４ｄは、コンポーネント７５ｂから受信されるデータレコードに対して分割操作を行うことを示す監査レコードを出力する。データ処理システム６４上で実行されるデータストア８８ｂが、監査ポート７４ｄ、７５ｄ、７６ｄ、７８ｄ、８０ｄ、８２ｄ、８４ｄ上で出力される監査レコードを受信し、本明細書に記載の更なる処理のためにそれらの監査レコードを（例えば１時間ごと等の指定の時間において）監査ログモジュール２４に伝送する。この例では、コンポーネント７４ｂ、７６ｂ、７８ｂ、８０ｂ、８２ｂ、及び８４ｂがコンピュータプログラムの実行可能ロジック（ここではデータフローグラフ６６ｂ）の様々な部分の説明的な例を表す。

【0049】

この例では、監査ログモジュール２４が分散型システム、例えばデータ処理システム６２、６４から監査レコードを受信し、それらの分散型システムのそれぞれはコンポーネント７５ａ、７５ｂからそれぞれ受信されるデータレコードの処理を分割している。事実上、監査ログモジュール２４は、データレコードを分割し多くの異なるシステムにわたって分散式に実行されているデータフローグラフから監査レコードを受信する。この例では、コンポーネント７４ａ～ｂ、７５ａ～ｂ、７６ａ～ｂ、７８ａ～ｂ、８０ａ～ｂ、８２ａ～ｂ、８４ａ～ｂのそれぞれが監査ポートを有する。一部の改変形態では、データフローグラフ内に含まれるコンポーネントのサブセットだけが監査ポートを有し得る。

【0050】

この例では、分散型データ処理システム６２、６４のそれぞれが、実行環境１４及び環境１０（図１）のそれぞれと別個である。各データ処理システム６２、６４から、監査ログモジュール２４はその分散型データ処理システムに由来する１つ又は複数のログレコードを受信し、分散型データ処理システム６２、６４のそれぞれから受信されるログレコードのコンテンツを結合する。この例では、データ処理システム６２、６４のそれぞれがデータストリームの１つ又は複数のデータ項目を入力装置又はポート（例えばコンポーネント７５ａ、７５ｂのそれぞれ）上で断続的に受信する。受信される１つ又は複数のデータ項目の少なくとも１つについて、グラフ６６ａ、６６ｂをそれぞれ表す実行可能ロジックの第１の部分をそのデータ項目に対して実行することを含め、データ処理システム６２、６４のそれぞれがデータ項目を処理する。例えば第１の部分は、分割コンポーネント、例えばコンポーネント７４ａ、７４ｂの１つを表す実行可能ロジックを含み得る。この例ではシステム６２、６４のそれぞれが、実行可能ロジックをひいては表すデータフローグラフ６６ａ、６６ｂに関する仕様に（例えば図１内のデータ記憶域２６から）アクセスする。この実行に応答し、システム６２、６４のそれぞれは、その分散型データ処理システム上でそのデータ項目を処理する際に実行される実行可能ロジックの第１の部分を第１のログレコードが指定した状態で第１のログレコードを生成し、例えば第１のログレコードを監査ログモジュール２４に（例えばリアルタイムで、指定の時間において、及び／又は一括で）伝送するデータストア８８ａ（例えば共用ＲＡＭ）に第１のログレコードをまず伝送することにより、第１のログレコードをインタフェース（例えば監査ポート７４ｃ、７４ｄのそれぞれ）によって監査ログモジュール２４に出力する。ログレコードは、特定のコンポーネントによってデータレコード又はイベントを処理することの属性の値を含む。例えば（コンポーネントがデータレコードを処理し始めてからコンポーネントがデータレコードの処理を完了するまでの経過時間を指定する）レイテンシ属性、（処理されるデータレコード内に含まれるキーを指定する）キー属性、（コンポーネントによって処理されているデータレコードのコンテンツを指定する）コンテンツ属性、（コンポーネントが処理を開始する時間を指定する）開始時間属性等を含む様々な種類の属性がある。この例では、監査ログモジュール２４が受信済みの監査ログのコンテンツを結合し、それをメモリ（例えばデータストア４０）内に記憶する。このメモリはＲＡＭ又はハードディスクとすることができる。次いで、メトリック生成モジュール２５が結合済みのコンテンツにメモリからアクセスし、結合済みのコンテンツから１つ又は複数のメトリックを生成する。

【0051】

図４Ｂの例では、データフローグラフ６６ａ、６６ｂ内の各コンポーネントが、より正確且つより粒度の細かい監査ロギングを可能にするための監査ポートを含む。加えて、監査ログモジュール２４は複数のシステム６２、６４から監査レコードを収集し、システム６２、６４のそれぞれによって処理されるレコードは例えば分割コンポーネント７４ａ、７４ｂによる処理において分割される。そのため、監査ログモジュールは複数の分割されたシステムから監査レコードを収集することができる。システム６２、６４のそれぞれが自らの監査レコードを個々に収集するのではなく監査ログモジュールが複数の分割されたシステムから監査レコードを収集する利点は、監査ログモジュール２４がマルチシステムエラー（例えば両方のシステム６２、６４にわたって生じるエラー）及び実行モジュール自体の中のエラーを検出できることである。かかるエラーを検出するための手段、及び最終的にそれらの検出済みのエラーを訂正するための手段も前々から提供することは、システム性能を改善しレイテンシを減らす手段をもたらす。一例では、例えばグラフ６６ａ、６６ｂ内のコンポーネント７８ａ、７８ｂによって表される特定のコンポーネントがデータを再フォーマットするためのコンポーネントである。この例では、入力される一定のデータの種類についてのみ特定のコンポーネントが再フォーマットを適切に行うことができない。データフローグラフが複数のシステム（例えば１００個のシステム）にわたって実行される場合、特定のコンポーネントは１００個の別個のシステム上で実行されている。コンポーネント７８ａ、７８ｂが１００個等の複数のシステム（１００個のシステムのそれぞれは異なる種類のデータ又は異なるデータ形式を処理している）にわたって実行されるとき、監査ログモジュール２４はコンポーネント７８ａ、７８ｂに関する監査レコードを（コンポーネント７８ａ上の専用出力ポートを介して）収集しているので、監査ログモジュール２４は特定のコンポーネントが再フォーマットを正しく行うことができない一定のデータの種類又は形式を識別することができる。監査ログモジュール２４内で全ての監査レコードを中心的に収集することにより、監査ログモジュール２４は集合的なエラーデータ（コンポーネント７８ａ、７８ｂが再フォーマットすることができない様々な異なる種類のデータの種類又は形式）を識別することができる。そのため、最終的により時間がかかり新たなデータの種類について問題を解決できない場合さえある個々のマシン上での個別の修正ではなく、（例えばコンポーネント７８ａ、７８ｂのための中央ライブラリ又はリポジトリ内に記憶される実行可能ロジックを編集することにより）特定のコンポーネントに関する問題をシステム全般にわたって訂正するためにこの集合的なエラーデータが実行環境１４によって使用され得る。従って、基礎を成すデータ処理システムの計算性能が改善される。

【0052】

加えて、監査ログモジュール２４が全ての又は複数のマシンにわたって監査レコードを中心的に収集しているので、実行環境１４（例えばデータ処理システム）はリアルタイムの監査レコード及びメトリックを大規模に生成する（例えば１日当たり数十億のイベントについて監査レコードを生成し処理する）。かかる生成の理由は、監査レコードをシステム上でローカルにしか記憶せず、それらのレコードを指定の時間において監査ログモジュールにプッシュするのではなく、チャート又はデータフローグラフ６６ａ、６６ｂ等のコンピュータプログラムを実行している各システム（例えばシステム６２、６４）が監査ログモジュール２４に向けて監査レコードをリアルタイムで、即ちプログラム／チャート／データフローグラフが目下実行されている間に自動的にプッシュし、そのためプログラム／チャート／データフローグラフの実行中に且つこの実行が完了する前に既に監査レコードが監査ログモジュール２４にとってアクセス可能になるからである。監査レコードは、対応するシステム６２、６４上で監査レコードをローカルに一切記憶することなしにログモジュール２４に直接プッシュすることができ、又はプログラム／チャート／データフローグラフの実行中にログモジュール２４にとって既にアクセス可能なデータストア８８ａ、８８ｂ内にローカルに記憶することができる。データストア８８ａ、８８ｂは、レコードをローカルに記憶する場合でもレイテンシを減らすのに依然として有益な共用メモリ（例えばＲＡＭ）とすることができる。加えて、各コンポーネントは専用監査ポートを有し、専用監査ポートはそのコンポーネントがデータレコード又はイベントを処理するときに関して監査ログモジュールが監査レコードをリアルタイムで受信することを更に可能にする。これにより監査レコードを受信する際のレイテンシが減る。例えば監査レコードがチャート又はデータフローグラフの完了時にしか生成されない場合、システムがチャート又はデータフローグラフの実行を完了するのを待つことによるレイテンシが生じ、そのことはひいては（監査レコード内で表される）エラーを訂正する際の及び／又はメトリックを生成する際のレイテンシを増やす。各コンポーネントが専用監査ポートを有し、そのコンポーネントが実行を終えるや否や（例えばそのコンポーネントによって表される実行可能ロジックが実行を終えるや否や）監査レコードを監査ログモジュールに（例えばレコードをローカルに記憶することなしに直接、又は共用メモリを介して）自動的にプッシュすることにより、監査レコードをｒｅｃｅｉｃｉｎｇする際の及びそれらの監査レコードからメトリックを計算する際のレイテンシが、チャートの完了時にのみ監査レコードを受信する際のレイテンシと比較して減る。

【0053】

更に、（複数のマシン上で実行される）グラフの分散型の性質及び各グラフがレコードの処理を分割することは、イベント又はデータレコードがグラフ内の各コンポーネントによって処理される場合と比較し、監査レコードが監査ログモジュールによってリアルタイムで及び／又はほぼリアルタイム（例えばライブ時間）で受信されることを可能にし、そのことはひいてはリアルタイムのメトリックを生成できるようにし、それによりそのメトリックに基づいてエラーをリアルタイムで識別することを可能にする。受信済みのレコードを処理するためにそれらのレコードをそれぞれ分割する複数のシステムにわたって（各コンポーネントがデータレコード又はイベントを処理するとき）監査レコードが並列に生成されるので、実行環境１４は監査レコードを大規模に処理することができる。つまり、データレコードが受信されればされるほど、又はより多くの待ち行列がサブスクライブされると（従ってそれらのクエリによってより多くのデータレコードが受信されると、各コンポーネントの実行時に監査レコードを大規模に且つリアルタイムで生成することを可能にする（グラフ及び／又はチャートの各コンポーネントが専用監査ポートを含みながら適切なグラフ及び／又はチャートを実行する）更に多くのシステムを追加してデータレコードの増加を処理することにより及び大規模に処理を行うことにより、実行環境１４はそれらのデータレコードを大規模に処理することができる。監査レコードの生成（及び監査レコードを生成する結果として生じるフロー）がデータストリームを処理するデータフローと別個なので、実行環境１４はそれらのレコードを大規模に処理することもできる。つまり、監査レコードを生成するための専用ポートを有することにより、監査レコードの生成が（データ処理に由来する）データフローに対して直交し、そのため監査レコードを生成することはデータフローに影響を及ぼさない。つまりデータ処理システムは、データ処理システムの複数のサブシステムによって処理されるデータ項目を含むデータストリームと別個のデータストリーム内にログデータを出力できるようにする専用ログポートをそれぞれ含む複数の処理システム（又はサブシステム）を含み、それによりログデータを出力することがデータの処理にレイテンシを生じさせることがない。具体的には、出力（例えば監査レコード）はデータフローに対して非同期だと考えることができる。データフローグラフによるデータ処理はデータ処理の第１の層である。監査ポートは第２の層である。そのため第２の層の性能が第１の層に影響を与えることはない。この第２の（非同期）層において監査レコードを生成することにより、レコードの生成が影響を受けることはない。このことは監査レコード及び（監査レコードから生成される）メトリックを大規模に生成することを可能にする。

【0054】

加えて、上記のようにシステムが（例えば適切なデータフローグラフ及び／又はチャートを実行する追加のシステムを実装することにより）データレコードを大規模に処理することができるので、実行環境１４はメトリックを大規模に生成することができる。加えて、監査レコードがリアルタイムで又はほぼリアルタイムで受信され処理されることに応答して、及び受信され処理されるときにメトリックが生成されるので、（全ての実行中のシステムにわたる各コンポーネントが実行を終了するとき）メトリックがリアルタイムで又はほぼリアルタイムで生成される。

【0055】

全てのメトリックを中心的に収集することにより（例えば全ての監査レコードを中心的に収集し、中心的に収集した監査レコードからメトリックを生成することにより）、実行環境１４はより正確で粒度が細かく集約的なメトリックをリアルタイムで生成し表示することができる。例えば個々のコンポーネント、例えばコンポーネント７８ａの処理速度をそのコンポーネントの実行時にほぼリアルタイムで計算することができる。例えばコンポーネント７８ａが１００台の異なるマシンにわたって実行されており、（コンポーネント７８ａのための専用ポートによって）コンポーネント７８ａに関して作成される各監査レコードが、コンポーネント７８ａがｄａｔａｒｅｃｉｒｄの処理を開始したとき及びコンポーネント７８ａがデータレコードの処理を完了したときを指定するレイテンシメトリックを含む場合、メトリック生成モジュールはコンポーネント７８ａがデータレコードの処理を開始するときからデータレコードの処理を完了するときまでの平均レイテンシ（例えば処理時間）を（コンポーネント７８ａの実行（又はコンポーネント７８ａを表す実行可能ロジックの実行）と比較して）ほぼリアルタイムで計算することができる。（グラフレベルとは対照的に）コンポーネントレベルでメトリックを計算できることにより、メトリック生成モジュールは、グラフレベルのメトリックからはマスクされ又は容易に明らかでない場合があるコンポーネントレベルのエラー及びレイテンシの問題を識別できるようにする。コンポーネントごとに監査レコードを（専用監査ポートによって）受信することは、メトリック生成モジュールがそれらのコンポーネント固有メトリックを生成することを可能にする。例えば監査レコードがグラフ全体にわたってしか生成されない場合、レイテンシメトリックはグラフ全体のレイテンシを示すに過ぎない。この例では、５ミリ秒未満のレイテンシメトリックを有するグラフを許容可能と見なす。この例では、コンポーネント７８ａを実行しているグラフの平均レイテンシ時間が４ミリ秒である。そのためグラフが許容可能な性能を有するとシステムは判定する。しかし、メトリック生成モジュールがコンポーネント７８ａ自体の平均レイテンシ時間を計算する場合、そのレイテンシ時間は１５ミリ秒である。コンポーネント７８ａの実行と比較してほぼリアルタイムで監査レコードを生成する専用監査ポートをシステムのそれぞれの上で実行されるコンポーネント７８ａのそれぞれが有し、それらの監査レコードが監査ログモジュールによって収集され、次いで粒度の細かいリアルタイムのメトリックを生成するためにメトリック生成モジュールによって処理されるので、メトリック生成モジュールは（複数の異なるシステムにわたってコンポーネント７８ａを実行することに基づく）この平均レイテンシ時間を計算することができる。個々のコンポーネントについてリアルタイムのメトリックを集約レベルで生成するメトリック生成モジュールの能力により、システムは個々のコンポーネントのレイテンシ又は性能の問題を識別し、（例えばそのコンポーネントを表す実行可能ロジックを修正することによって）それらのレイテンシの問題に対処し或いはかかる問題を修復し、それにより個々のコンポーネントの性能の問題を識別しない場合のグラフ実行のレイテンシと比較してグラフ実行のレイテンシを減らし、システム全体の性能を改善することができる。

【0056】

この例では、処理システム６２がログデータの出力を記憶するためのデータストア８８ａを含む。この例では、処理システム６２がデータ項目を処理するための実行可能ロジック（例えばデータフローグラフ又はチャートのための実行可能ロジック）を記憶するメモリ６２ａ（図４Ａ）を含む。（データフローグラフ６６ａによって表す）実行可能ロジックの（例えばコンポーネント８２ａによって表す）第１の部分は、データストア８８ａにログデータを出力するための第１の専用出力ポート（例えば出力ポート８２ｃ）を含み、第１の専用出力ポートは実行可能ロジックの第１の部分によるデータ項目の処理を示すログデータを出力する。この例では、実行可能ロジックの（例えばコンポーネント８０ａによって表す）第２の部分がデータストア８８ａにログデータを出力するための第２の専用出力ポート（例えば出力ポート８０ｃ）を含み、第２の専用出力ポートは実行可能ロジックの第２の部分によるデータ項目の処理を示すログデータを出力する。この例ではシステム６２は、受信されるデータ項目の最初のものについて、実行可能ロジックの第１の部分を用いてその第１のデータ項目を処理する実行システム６２ｂ（図４Ａ）を含む。この例では、データ項目を処理するための第２の処理システム（例えばシステム６４）が環境１４内に含まれる。第２の処理システムは、データ項目を処理するための（データフローグラフ６６ｂによって表す）実行可能ロジックを記憶するデータストア８８ｂ及びメモリ（例えば図４Ａ内の６４ａ）を含む。第２の処理システム内の実行システム（例えば図４Ａ内の実行システム６４ｂ）は実行可能ロジックを実行し、データストア内に記憶されるログデータをもたらすように構成される。モニタリングシステム（例えば性能モニタリングモジュール１８）は、第１の処理システム６２のデータストア８８ａから記憶済みのログデータを得る、取得する、又は受信するための、及び第２の処理システム６４のデータストア８８ｂから第２の処理システムに由来するログデータを得る、取得する、又は受信するための入力ポート（例えば監査ログモジュール２４上の入力ポート２４ａ）を含む。

【0057】

第１の処理システム６２及び第２の処理システム６４のそれぞれについて、個々の実行システム（例えば図４Ａ内の６２ｂ、６４ｂのそれぞれ）又は実行可能ロジックが複数の受信済みのデータ項目を分割し、それによりデータ項目の２つ以上が実行可能ロジックの分割コンポーネント（例えばコンポーネント７４ａ又は７４ｂ）に割り当てられ、各分割コンポーネントは出力ポート（例えば７４ｃ、７４ｄ）及び入力ポート（例えば７４ｅ、７４ｆのそれぞれ）を含み、実行システムは、分割コンポーネントごとに及び分割コンポーネントの入力ポートにおいて受信されるデータ項目ごとに、その分割コンポーネントに割り当てられるそのデータ項目を処理すること、及び分割コンポーネントによるそのデータ項目の処理を指定するログデータを分割コンポーネントの出力ポート上で出力することを含む操作を実行し、その処理システムのためのデータストアはその処理システムのための分割コンポーネントの出力ポートから出力されるログデータを受信する。この例では、モニタリングシステム１８が第１の処理システム６２及び第２の処理システム６４の個々のデータストア８８ａ、８８ｂから出力されるログデータを受信し、受信されるログデータは第１の処理システム６２及び第２の処理システム６４の個々の分割コンポーネント７４ａ、７４ｂの個々の出力ポート７４ｃ、７４ｄから出力される。

【0058】

図４Ｃを参照し、環境１００は監査ログモジュール２４内に含まれるコンポーネントを示す。この例では監査ログモジュール２４が、ソースデータリーダ、複数のソースデータリーダ、及び／又はデータベース（例えば図４Ｂ内のデータストア８８ａ）をサブスクライブする（例えばそこからデータを得る、取得する、又は受信する）サブスクライブコンポーネント１０４を含む。サブスクライブコンポーネント１０４は監査ログレコードを受信するためのポート１０４ａを含む。監査ログモジュール２４は、ソースデータリーダ、複数のソースデータリーダ、及び／又はデータベース（例えば図４Ｂ内のデータストア８８ｂ）をサブスクライブする（例えばそこからデータを受信する）サブスクライブコンポーネント１０６も含む。サブスクライブコンポーネント１０６は監査レコードを受信するためのポート１０６ａを含む。この例では、監査ログモジュール２４が結合コンポーネント１１２及び分類器コンポーネント１１６も含む。

【0059】

この例では、サブスクライブコンポーネント１０４が監査レコード１０１ａ～１０１ｄに（例えば図４Ｂ内のデータストア８８ａから）リアルタイムでアクセスする。サブスクライブコンポーネント１０４は（例えば全てのフィールドの値が指定の形式にあることを確実にするために）監査レコード１０１ａ～１０１ｄの幾らかのフォーマッティングを行うことができ、又は（例えば別のデータストア（不図示）にアクセスし、監査レコード内で指定される特定の加入者について取得データを追加する、及びその取得データを拡張として監査レコードに追加することによって）幾らかの拡張データを追加することができる。サブスクライブコンポーネント１０４は、監査レコード１０８ａ～１０８ｄを結合コンポーネント１１２に出力する。監査レコード１０８ａ～１０８ｄは、監査レコード１０１ａ～１０１ｄと同じとすることができ、又は例えば監査レコード１０１ａ～１０１ｄの１つ又は複数が再フォーマットされ及び／又は拡張される場合は異なる場合がある。

【0060】

この例では、サブスクライブコンポーネント１０６が監査レコード１０２ａ～１０２ｄに（例えば図４Ｂ内のデータストア８８ｂから）リアルタイムでアクセスする。サブスクライブコンポーネント１０６は（例えば全てのフィールドの値が指定の形式にあることを確実にするために）監査レコード１０２ａ～１０２ｄの幾らかのフォーマッティングを行うことができ、又は（例えば別のデータストア（不図示）にアクセスし、監査レコード内で指定される特定の加入者について取得データを追加する、及びその取得データを拡張として監査レコードに追加することによって）幾らかの拡張データを追加することができる。サブスクライブコンポーネント１０６は、監査レコード１１０ａ～１１０ｄを結合コンポーネント１１２に出力する。監査レコード１１０ａ～１１０ｄは、監査レコード１０２ａ～１０２ｄと同じとすることができ、又は例えば監査レコード１０２ａ～１０２ｄの１つ又は複数が再フォーマットされ及び／又は拡張される場合は異なる場合がある。

【0061】

結合コンポーネント１１２は、監査レコード１０８ａ～１０８ｄを監査レコード１１０ａ～１１０ｄと１時間ごと等の指定の時間間隔において結合する。一部の例では、コンテンツをマージし結合済みの監査レコード１１４を作成することによって監査レコード１０８ａ～１０８ｄが監査レコード１１０ａ～１１０ｄと結合される。他の例では、監査レコード１０８ａ～１０８ｄが監査レコード１１０ａ～１１０ｄとキーによって結合される。例えば監査レコードの１つ又は複数が特定のキー値及びそのキーに関連するフィールドを含む場合、そのキーに関する監査レコードをもたらすためにその特定のキー値に関する監査レコード（又は監査レコード内に含まれるフィールド）を結合する。結合コンポーネント１１２は結合済みの監査レコードを分類器コンポーネント１１６に出力し、分類器コンポーネント１１６は例えばキーによって決定される監査レコードの種類ごとに監査レコードを分類する。この例では、分類器１１６が３つの異なるレコードの種類１１６ａ～１１６ｃを識別し、それらはソートコンポーネント１１７によってソート（例えば時間ソート）される。ソートされ分類された監査レコードがデータストア４０に出力され、データストア４０（例えばＲＡＭ）内に記憶される。

【0062】

図５Ａを参照し、監査レコードの分類済みの一例を示す。この例では、（図４Ｃ内の分類器１１６と同じでも異なってもよい）分類器２４ａが様々な監査レコードをキー値によって分類する。この例では、監査レコード１０１ａ、１０２ｃが「Ｏｐｓ」の同じキー値をそれぞれ有し、従って「オペレーション分類」の特定のレコードの種類に分類される。監査レコード１０１ｂ、１０２ｂは「履行」の同じキー値をそれぞれ有し、従って「履行」分類の特定のレコードの種類に分類される。監査レコード１０１ｄ、１０２ａは「消費者」の同じキー値をそれぞれ有し、従って「消費者」分類の特定のレコードの種類に分類される。図５Ｂを参照し、レコードの種類１１６ａ、１１６ｂ、１１６ｃのそれぞれがソートコンポーネント１１７によってソートされている。この例では、監査レコード１０１ａ、１０２ｃがレコードの種類１１６ａ内に含まれる。監査レコード１０１ｂ、１０２ｂはレコードの種類１１６ｂ内に含まれる。監査レコード１０１ｄ、１０２ａはレコードの種類１１６ｃ内に含まれる。この例では、ソートコンポーネント１１７がタイムスタンプによってソートするように構成される。そのため、オペレーション分類内の監査レコード１０２ｃ、１０１ａはタイムスタンプによってソートされる。履行分類内の監査レコード１０１ｂ、１０２ｂはタイムスタンプによってソートされる。消費者分類内の監査レコード１０２ａ、１０１ｄはタイムスタンプによってソートされる。監査ログモジュール２４は、ソート済みの監査ログを記憶するためにデータシンク４０に出力する。それを受けてメトリック生成モジュール２５は、例えば特定のユーザに関する、特定の期間にわたる、特定のキー等に関するメトリックを生成するためにデータシンクをクエリすることができる。この例では、メトリック生成モジュールがメトリック１０３を生成する。

【0063】

改変形態では、監査ログモジュール２４が、ログレコードを受信するための単一の入力ポート、例えば１０４ａを有する単一のサブスクライブコンポーネントを含み得る。以下でより詳細に説明するように、図４Ａ～図４Ｄは（参照によりその全内容を本明細書に援用する米国特許出願公開第２０１７－０３４４６７２号明細書に記載の）フローチャートによる経過を示し、フローチャートの様々な状態において様々なノードが実行されることを示す。図６Ａ～図６Ｄは、様々な状態において生成される様々な監査レコードを示す。

【0064】

図６Ａを参照し、図１２９ａはシステム６２を示す、データ処理コンポーネントを表すノード１３２ａ～１３２ｇを有する（仕様１３０によって指定される）フローチャート１３２実行する。この例では、ノード１３２ａ、１３２ｃ、１３２ｅのそれぞれが、個々のノードの実行に関係するデータ（例えばメタデータ）を含む１つ又は複数の監査レコードを出力するための監査ポート１３２ｊ、１３２ｋ、１３２ｑをそれぞれ有する。この例では、仕様が実行可能ロジックを表し様々な状態を指定し、仕様の状態は、前のデータ項目に対して実行可能ロジックを実行することによって到達する状態に基づく、その状態において実行可能な実行可能ロジックの１つ又は複数の部分を指定する。この例では、データ処理コンポーネントの１つ又は複数が実行可能ロジックの特定のグループ又は部分を指す。概して、チャートはデータレコードを処理するためのテンプレートを含む。このテンプレートは、入力データレコードに反応して出力データレコード、例えば仕様に含まれるロジックに基づいて生成されるデータレコードを作成するためのロジックのグラフィックユニットを含む。チャートは仕様の一例である。概して、ロジックのグラフィックユニットは、例えばテンプレート（不図示）からチャートを構築するためのウィンドウに様々なノードをドラッグアンドドロップすることによって少なくとも部分的にグラフィカルに生成されるロジックを含む。一例ではノードが、入力データレコードをどのように処理するのか、実行可能ロジックによって使用される変数の値をどのように設定するのか、例えばロジックによって指定される条件を満たしたときどの出力データレコードを生成するのか等を指定するロジック（不図示）を含む。一例では、ノードのロジック内で使用されるパラメータ及び／又は変数の値をユーザが入力することによってノードがプログラム可能である。

【0065】

ノード内のロジックが実行可能ロジックにコンパイルされ、各ノードがその実行可能ロジックの１つ又は複数の部分に対応するときチャート自体が実行可能である。例えばシステムは、ノード内のロジックを実行可能ロジックにコンパイルすることによって仕様（及び／又は仕様内のチャート）を変換する。チャート自体が実行可能なので、チャート自体がデータレコードを処理することができ、チャート自体を停止、開始、及び一時停止することができる。システムは、例えばノード１３２ａ～１３２ｇのどれが目下実行されているのかを追跡することによってフローチャート１３２の状態も保つ。フローチャート１３２の状態は、フローチャート１３２によって表される実行可能ロジックの状態に対応する。例えばフローチャート１３２内の各ノードは、実行可能ロジックの特定の状態を表す（実行可能ロジックの１つ又は複数の部分がその状態において実行可能である）。以下でより詳細に説明するように、フローチャート１３２が様々なキー値について実行されている場合、システムは例えばインスタンスごとに状態を保つことによりキー値ごとにフローチャート１３２の状態を保つ。概して仕様のインスタンスは、例えば仕様内で表される実行可能ロジックを実行し実行可能ロジックの状態を固有のキー値ごとに保つことによる、固有のキー値に関する仕様の具体的実現を含む。この例では、フローチャート１３２が状態遷移図を含み、各入力データレコードがノード間の遷移を駆動し、データレコードは前のデータレコードを処理することによって到達する状態に基づいて評価される。フローチャート１３２内のノード間のリンクは時間的なロジックフローを表す。

【0066】

仕様１３０はキー１３２ｈも含み、キー１３２ｈはフローチャート１３２がキー１３２ｈを含む又はキー１３２ｈに関連するデータレコードを処理することを識別する。この例ではカスタム識別子（ＩＤ）がキーとして使用されている。キー１３２ｈは、例えばｓｕｂｓｃｒｉｂｅｒ＿ＩＤフィールド、ｃｕｓｔｏｍｅｒ＿ＩＤフィールド、ｓｅｓｓｉｏｎ＿ＩＤフィールド等のデータレコードのフィールドの１つに対応し得る。この例では、ｃｕｓｔｏｍｅｒ＿ＩＤフィールドがキーフィールドである。特定のデータレコードについて、システムはそのデータレコードのキーフィールドの値を識別することによってそのデータレコードのキー値を決定する。改変形態では、仕様がキーに関連しなくてもよく、フローチャートがキーと独立に実行され得る。

【0067】

この例では、フローチャート１３２が（例えば指定の種類のものであり、フローチャート２３２の構成時に指定される）データレコードをサブスクライブする。この例では、フローチャート１３２がキー３２ｈを含むデータレコードをサブスクライブする。この例では、フローチャート１３２及びデータレコードがキーを共有する。概してフローチャートは、フローチャートのキーを含むデータレコードを処理するためのロジックを含むことにより、それらのデータレコードの種類をサブスクライブする。データレコードの処理が始まると、システムは例えば新たなキー値ごとに（フローチャート内で表される）実行可能ロジックの状態を保つことにより、そのフローチャートに関する新たなキー値ごとの新たなフローチャートのインスタンスを開始する。概してフローチャートのインスタンスは、例えば仕様内で表される実行可能ロジックを実行し実行可能ロジックの状態を固有のキー値ごとに保つことによる、固有のキー値に関するフローチャートの具体的実現を含む。システムは、特定のキー値についてデータレコードに応答するようにフローチャートのインスタンス（従って基礎を成す実行可能ロジック）を構成することによってデータレコードの処理を行う。一例では、フローチャートが顧客のショートメッセージサービス（ＳＭＳ）データレコードをサブスクライブする。特定の顧客ＩＤのためのフローチャートのインスタンスが、その顧客に関するデータレコードを管理する。入力データレコード内で遭遇する顧客ＩＤと同じだけのフローチャートのインスタンスがあり得る。

【0068】

この例では、図１２９ａがフローチャート１３２の実行の開始を示す。この例では、ノード１３２ａが実行可能ロジックの開始を表し、（例えばノードａ３２ａを囲む太線によって示すように）目下実行されている。この例では、フローチャート１３２はノード１３２ａが実行されている状態にある。

【0069】

この例では、開始ノード１３２ａの実行時に監査レコード１３２ｉが生成される。この例で示すように、具体的には開始ノード１３２ａは、例えば開始ノード１３２ａが実行されている状態にフローチャート１３２がある場合に監査レコード１３２ｉを監査ポート１３２ｊ上で生成するように構成されるデータ処理コンポーネントを表す。この例では、監査レコードを生成すると、システムは仕様によって表される実行可能ロジックのどの部分が特定のキー値について現時点において実行されているのかを指定するデータを用いて監査レコードのフィールドにデータ投入する。この例では監査レコード１３２ｉが、（フローチャート１３２によって目下処理されているレコードのキー値を指定する「３２４２５」の値を有する）キーフィールド、（フローチャート１３２の識別子を指定する「４２４２４」の値を用いてデータ投入されている）ｃｈａｒｔ＿ＩＤフィールド、及び（ノード１３２ａを表す「開始」の値を用いてデータ投入されている）コンポーネント（「Ｃｏｍｐ」）フィールドの３つのフィールドを有する。この例では、監査レコード１３２ｉが監査レコードを収集するデータストア１３４に監査ポート１３２ｊ上で出力される。指定の時間間隔において（例えば１時間ごとに）、データストア１３４は収集した監査レコードを監査ログモジュール２４（図４Ｂ）に伝送するように構成される。

【0070】

更に他の例では、仕様がチャートであり、１つ又は複数のログレコードが、特定のキー値に関連する１つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定する。この例ではシステムが、特定のキー値に関連する１つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定するログレコードを生成する。更に他の例では、システムが１つ又はデータ項目を処理することに基づいて１つ又は複数の出力レコードを生成する。この例では、１つ又は複数の出力レコードのそれぞれがログレコード内に含まれないデータを含む。

【0071】

様々な種類の監査レコードが様々なフィールドと共に予め定められ、それぞれのフィールドの種類はデータレコード又はイベントを処理することの１つ又は複数の属性を指定する。概してイベントは、特定の発生又は発生の欠如を表す（例えば既定の形式の）データレコードを含む。この例では、ノード１３２ａは例えばノード１３２ａ上でクリックすることによって編集可能であり、そのようにクリックすることはノードを構成する際に、そのため更にはノードによって表されるデータ処理コンポーネントを構成する際に使用することができる構成画面を表示させる。構成の一部は、監査（又は「ロギング」とも呼ぶ）をオンにすること、及びそのノードの横断時に生成される監査レコードの１つ又は複数の種類を指定することを含み得る。別の例では、本明細書に記載のシステムが、様々な種類の監査レコードの視覚的表現を表示する及び様々な種類の監査レコードをオン／オフするためのコントロールを提供するユーザインタフェース用のデータを生成する。この例では、システムは特定の種類のノード又はデータ処理コンポーネントに対応する又は関連する種類の監査レコードを（例えばその種類の監査レコードのロギングが有効にされている場合）生成する。例えば監査レコード１３２ｉは、チャートの開始を指定するデータをロギングするためのチャート開始監査レコードである。そのためチャート開始監査レコードが有効だとユーザが指定する場合、本明細書に記載のシステムは開始ノードがチャートを開始しチャート開始監査レコードがチャートの開始をログすることに基づいてチャート開始監査レコードと開始ノード（例えばノード１３２ａ）との間の対応を識別し、チャート開始監査レコードを生成する。

【0072】

図６Ｂを参照し、図１２９ｆはノード１３２ａの完了後のフローチャート１３２の状態を示す。この例では、フローチャート１３２の状態が実行可能ロジックの１つ又は複数の他の部分を表すノード１３２ｂに遷移する。ノード１３２ｂは待機ノード（以下、待機ノード１３２ｂ）を含む。待機ノード１３２ｂは、１つ又は複数の条件を満たす入力データレコードを（待機ノード１３２ｂに対応する）実行可能ロジックの一部が待つ待機状態を表す。一例では、待機状態はフローチャート３２の別の状態、例えばシステムが（待機状態を実装するために）待機ノードを実行し、次いで１つ又は複数の他のノードを実行する状態の一部であり得る。待機ノード１３２ｂによって表される実行可能ロジックの一部の完了後、システムは待機状態を抜け、決定を下すための実行可能ロジックを表すノード１３２ｃを実行する。この例では、ノード１３２ｃが決定ノードを含む。以下、ノード１３２ｃを決定ノード１３２ｃと呼ぶ。概して、決定ノードは決定を実行するためのロジック（例えばブール値について評価するロジック）を含むノードを含む。

【0073】

フローチャート１３２のこの第２の状態では、監査レコード１３２ｒが（例えば図１内の実行モジュール１６によって）生成され、ノード１３２ｃの監査ポート１３２ｋ上でデータストア１３４に出力され、データストア１３４は監査レコード１３２ｒを収集し記憶する。具体的には、決定ノード１３２ｃによって表されるデータ処理コンポーネントは、この例で示すように例えば決定ノード１３２ｃが実行されている状態にフローチャート１３２がある場合に監査レコード１３２ｒを生成するように構成される。（この例では待機ノード１３２ｂもこの状態で実行されている。しかし待機ノード１３２ｂは監査レコードを生成するように構成されていない。）

【0074】

この例では、例えばはいのリンク１３２ｌが横断されているか又はいいえのリンク１３２ｍが横断されているかを指定することにより、監査レコード１３２ｒが決定ノード１３２ｃの結果を指定する。この例では、はいのリンク１３２ｌが横断されていることを指定するデータを「Ｖａｒ決定」の変数内に監査レコード１３２が記憶する。改変形態では、例えば決定ノード１３２ｃによって表されるデータ処理コンポーネントの実行時に、読み出され又は設定される変数を監査レコードが指定することもできる。この例では監査レコード１３２ｒがキーフィールドを含む必要がなく、それは監査レコード１３２ｒが指定のパルス（例えば時間又は既定の時間間隔）において処理システム（例えば監査レコードを処理する内部の又は外部の計算システム）に伝送され、監査レコードがグループ、ブロック内で、又はファイルの一部として伝送されることをもたらすからである。

【0075】

例えばシステムは監査レコードをキーごとにまとめ、第１のキーに関連する第１の監査レコードは第１のグループにまとめられ、第２のキーに関連する第２の監査レコードは第２のグループにまとめられる。この例では、監査レコードがシステム（例えば図１内のシステム１４）のメモリ内にまとめられる。システムはスペース効率を得るために監査レコードをメモリ内にまとめ、そのためシステムは、例えば各監査レコード内にキーを含めることで逐次的に関係する監査レコードにわたってデータを複製する必要がない。各監査レコードは、データ項目を処理することの１つ又は複数の属性を示す１つ又は複数のフィールドを含む。少なくとも１つの監査レコードについて、フィールドはデータ項目に関連するキーの値を指定するキーフィールドである。監査レコードがキーごとにまとめられるので、特定のキーに関連する監査レコードのサブセットはキーフィールドを含まない。一部の例では、特定のキーに関するグループ内に含まれる監査レコードの１つだけがキーフィールドを含む。この例では、システムが特定のキーに関連する特定のグループ内の監査レコードを既定の時間間隔（例えばパルス）の終わりにファイルに書き込む。

【0076】

例えばシステムは、第１の監査レコード又はチャート開始監査レコードのコンテンツを構文解析することによって（ブロック又はファイルとして表され得る）グループ内の監査レコードのためのキーを識別する。全ての監査レコードがキーフィールド（及び監査レコード１３２ｉと同じパルス内に含まれる他の監査レコードによってチャート開始監査レコード内で同じく探索され得るｃｈａｒｔ＿ＩＤフィールド等の他のフィールド）を含む必要はないので、本明細書に記載のシステムは、イベントのキー付きロギングを有効にするために各監査レコードがキーフィールドを含まなければならない場合のシステム資源に対する影響と比較し、システム資源（メモリ及び処理能力等）に対する最小限の影響を伴って監査レコードを処理することができる。加えて、各監査レコードがキーフィールドを含む必要がないことで監査レコードのサイズが小さくなるので、本明細書に記載のシステムはそれぞれがキーフィールドを有する監査レコードを処理するレイテンシと比較し、レイテンシを減らしながらこれらの監査レコードを処理する。加えて本システムは特定のキーに割り当てられる（メモリ内の）パーティション内に監査レコードを記憶するように構成され、各監査レコードがキーフィールドを含む必要性を更に減らす。新たなパルスの開始時に、本明細書に記載のシステムはそのパルスのその最初の監査レコード内にキーフィールドを含めるように構成される。

【0077】

図６Ｃを参照し、図１２９ｆはノード１３２ｃによって表される決定の結果に基づくフローチャート１３２の状態を示す。具体的には、ノード１３２ｃによって表される決定の結果に基づき、フローチャート１３２の状態が別の待機ノードであるノード１３２ｄに遷移する。（改変形態ではフローチャート１３２の状態は（ノード１３２ａに状態を再び遷移させる）ノード１３２ｇに遷移することができる）。待機ノード１３２ｄによって表される実行可能ロジックの一部の完了後、フローチャート１３２の状態が送信ノードを含むノード１３２ｅに遷移する。概して、送信ノードは別のシステムへのデータ伝送を引き起こすための実行可能ロジックを表すノードを含む。ノード３１２ｅによって表される実行可能ロジックの一部を実行し終えた後、フローチャート３２の状態は完了ノードを含むノード１３２ｆに遷移する。概して、完了ノードは実行可能ロジックの実行が完了したことを表す。

【0078】

フローチャート１３２のこの第３の状態において、例えば送信コンポーネント１３２ｅによって表される実行可能ロジックによって監査レコード１３２ｓが生成される。この例では、監査レコード１３２ｓは送信ノード１３２ｅによって表されるデータ処理コンポーネントによって実装されたアクションを指定する。監査レコード１３２ｓは送信コンポーネント１３２ｅの監査ポート１３２ｑ上で出力され、データストア１３４によって収集される。この例では、監査レコード１３２ｓが変数（「Ｖａｒアクション」）を含み、その値は送信コンポーネント１３２ｅによって開始されるアクションを指定する。この例では、送信コンポーネント１３２ｅがＳＭＳサービスを更新するためのオファーを送信するアクションを開始する。そのため「Ｖａｒアクション」の値が「ＳＭＳ更新のオファー」に設定される。監査レコード１３２ｒ、１３２ｓが監査レコード１３２ｇを含む同じパルスの一部として伝送されるので、監査レコード１３２ｇ及び１３２ｒと同様に監査レコード１３２ｓもキーフィールドを含む必要がない。監査レコードの他のものはアクションが送信された時間、読み出された変数の値、設定された変数の値等を指定することができる。この例では、データストア１３４が監査レコード１３２ｉ、１３２ｒ、１３２ｓを収集し及び伝送する、次いで例えば本明細書に記載の技法を用いた更なる処理のために（例えば指定の時間において）性能モニタリングモジュールに。

【0079】

図６Ｄを参照し、図１４０はシステム６４が（仕様１４１によって指定される）チャート１４４を実行することを示し、ノード１４０ａ～１４０ｇはデータ処理コンポーネントを表す。この例では仕様１４１がキーと独立しており、特定のキーに関連するデータレコードだけを処理するわけではない。この例では、ノード１４０ａ、１４０ｂ、１４０ｃ、１４０ｅが監査レコードを出力するための監査ポート１４０ｊ、１４０ｋ、１４０ｌ、１４０ｍをそれぞれ含む。この例では、チャート１４４の実行が開始されるとノード１４０ａが実行され、ノード１４０ａの実行は「５３４２２」及び「開始」の値をそれぞれ有する「ｃｈａｒｔ＿ＩＤ」フィールド及び「ＶａｒＣｏｍｐ」フィールドを指定する監査レコード１４０ｎを監査ポート１４０ｊ上で出力する。この例では、データストア１４２が監査レコード１４０ｎを受信し記憶する。次いでチャート１４４はノード１４０ｂに進み、ノード１４０ｂの実行はアップグレードするためのオファーをシステムのユーザに送信する（例えば電話サービス）。ノード１４０ｂが実行されると（例えばノード１４０ｂによって表される実行可能ロジックが実行されると）、システムは出力ポート１４０ｋ上で出力されデータストア１４２に伝送される監査レコード１４０ｏを生成する。

【0080】

ノード１４０ｂの実行後にノード１４０ｃが実行される。ノード１４０ｃは決定ノードである。決定ノード１４０ｃの実行は「はい」のリンク１４０ｒが横断されることをもたらし、ひいては監査レコード１４０ｐをシステムに生成させる。この例では、監査レコード１４０は「Ｖａｒ決定」と名付けられた変数の値を記憶する。「Ｖａｒ決定」変数は、ノード１４０ｃの「はい」のリンクが横断されたのか「いいえ」のリンクが横断されたのかを指定する。この例でははいのリンクが横断されたので、「Ｖａｒ決定」変数の値が「はい」に設定される。監査レコード１４０ｐが監査ポート１４０ｌ上で出力される。データストア１４２が監査レコード１４０ｐを収集し、それを記憶する。

【0081】

ノード１４０ｃの実行後にチャート１４４はノード１４０ｄ～１４０ｆを実行する。この例では、ノード１４０ｅの実行が、１４０ｍの部分上で出力される監査レコード１４０ｑを生成する。この例では、監査レコード１４０ｑは、ノード１４０ｅによって表される実行可能ロジックの実行によりどのアクションが実行され又は開始されたのかを指定する変数（即ち「Ｖａｒアクション」変数）の値を記憶する。この例では、「Ｖａｒアクション」変数の値は、ＳＭＳサービスを更新するためのオファーがユーザに送信されたことを指定するための「ＳＭＳ更新のオファー」である。データストア１４２がデータレコード１４０ｑを収集する。指定の時間において、データストア１４２は監査レコード１４０ｎ、１４０ｏ、１４０ｐ、１４０ｑを一括し、それらを監査ログモジュールに伝送する。

【0082】

図６Ｅを参照し、環境１５０は環境１００の改変形態である。この例では、サブスクライブコンポーネント１０４がデータストア１３４から監査レコード１３２ｉ、１３２ｒ、１３２ｓを読み出し、それらを結合コンポーネント１１２に伝送する。サブスクライブコンポーネント１０４はデータストア１４２から監査レコード１４０ｎ～１４０ｑを読み出し、それらを結合コンポーネント１１２に伝送する。この例では、結合コンポーネント１１２は監査レコード１３２ｉ、１３２ｒ、１３２ｓ及び監査レコード１４０ｎ～１４０ｑのコンテンツを結合済みの監査レコード１５２へと結合する。結合コンポーネント１１２は結合済みの監査レコード１５２をロールアップコンポーネント１１６に出力し、ロールアップコンポーネント１１６は結合済みの監査レコード１５２内の１つ又は複数の個々のフィールドの１つ又は複数の値に対してロールアップ操作を実行してロールアップ済みのレコード１５４を生成する。この例では、ロールアップ済みのレコード１５４が集約フィールド、即ち「ＣｏｕｎｔＳＭＳ更新のオファー」を含む。このフィールドは「ＳＭＳ更新のオファー」の値を有する変数の数を指定する。この例では、結合済みのレコード１５２が「ＳＭＳ更新のオファー」の値を有する（どちらも「Ｖａｒアクション」と名付けられた）２つの変数を含む。そのため、集約フィールド「ＣｏｕｎｔＳＭＳ更新のオファー」の値は「２」である。ロールアップコンポーネント１１６は、本明細書に記載の更なる処理のために、例えばメトリックを生成するためにロールアップ済みのレコード１５４をデータストア４０に伝送する。

【0083】

図７を参照し、環境１６０は監査ロギングのためのアーキテクチャを示す。環境１６０は、データレコード（及び／又は他の構造化データ項目）を処理するように構成される実行モジュール１６４を有するシステム１６２（例えばデータ処理システム）を含む。この例では、実行モジュール１６４が規則セットログ１６８、チャート選択モジュール１７０、及びチャート１７２を含む。システム１６２は、監査ログモジュール１６６及びメトリック生成モジュール１６７も含む。この例では、規則セットログ１６８がログ（例えばどの規則が実行されるのか、その規則が何時実行されるのか、パラメータの値、及び／又は実行中に設定される値等を示すロギングデータ又は規則ケーストレース情報（本明細書ではトレーシング情報とも呼ぶ））を含み、参照によりその全内容を本明細書に援用する米国特許第７，８７７，３５０号明細書に記載のビジネス規則環境（ＢＲＥ）内の規則の生成された実行。参照番号１９８によって示すように、規則セットログ１６８から出力されるこのロギング情報はデータストア１７４内に入力される。この例では、（例えばチャート決定ブロック内ではなく規則セットによって処理したビジネスロジックに対処するために）実行モジュール１６４がビジネス規則環境から規則ケーストレース情報を収集してその情報を監査レコード内に任意選択的に含める。一例では、グラフコンポーネント上のポートに自らのログを書き込み、そのログをポートからファイルに書き込むことによってＢＲＥがロギングデータストリームを実装する。この例では、実行モジュール１６４が現在のイベントに関する監査レコード（及び他の監査情報）を収集しているイベントエンジンの内部データ構造の中にトレーシング情報を記憶する関数呼び出しでＢＲＥ内のトレーシング情報を書き出す関数呼び出しを置換することにより、実行モジュール１６４がそのロギングデータストリームをインタセプトする。一部の例では、ＢＲＥが使用しているロギング関数（例えばｗｒｉｔｅ＿ｔｏ＿ｌｏｇ）の代替的実装を提供することにより、実行モジュール１６４がロギングデータストリームをインタセプトする。他の例では、様々な関数を使用するための選択肢をＢＲＥがサポートする。

【0084】

この例では、チャート選択モジュール１７０が、１つ又は複数のデータフローグラフ（例えばチャート１７２の１つ）を実行するように構成され、又は実行モジュール１６４内に含まれる様々なシステム上で実行されるチャート若しくはデータフローグラフを選択するように構成される。この例では、チャート１７２がデータフローグラフ６６ａ、６６ｂ（図４Ｂ）、及びチャート１３２（図６Ａ）、１４４（図６Ｄ）を含む。この例では、チャート選択モジュール１７０が図４Ｂに示すシステム６２、６４のそれぞれの上で実行するためのデータフローグラフ６６ａ、６６ｂ（図４Ｂ）をチャート１７２から選択する。異なる前の時点又は後の時点において、チャート選択モジュール１７０は更に図５Ａ～図５Ｄに示すシステム６２、６４のそれぞれの上で実行するためのチャート１３２、１４４（図６Ａ～図６Ｄ）をチャート１７２から選択する。この例ではチャート１３２、１４４（図６Ａ～図６Ｄ）の選択が図示されており、システム６２、６４のそれぞれの上でのそれらのチャート１３２、１４４（図６Ａ～図６Ｄ）の実行が図示されている。この例では、参照番号１９６、１９７のそれぞれによって示すようにシステム６２、６４の出力（例えばログレコード）がデータストア１７４に伝送される。

【0085】

この例では、チャート１７２の１つが、クラスタメトリックを生成しそれらをデータベース１７３内のファイル内に直接書き込むイベントエンジングラフである。概して、イベントエンジングラフは実行モジュール１４４の性能をモニタするためのグラフである。概してクラスタメトリックは性能の詳細、例えばデータフローグラフのどの部分が横断されるのかを示すメトリック及びデータフローグラフの一定の部分がレコード群によって横断される回数を示す集約メトリック等、システム及び／又は実行モジュール１６４の集約レベルにおける詳細を指す。一部の例では、このファイルが全てのパルス（例えばデータプッシュ）上で（例えば過去に記憶された他のファイル又は更新される）付加され、新たなファイルが毎日開かれる。

【0086】

この例では、（例えばチャートを実行するチャート選択モジュール１７０の実行に基づいて）チャート選択モジュール１７０から別のデータ経路が生じる。チャートが実行されるとき、チャート選択モジュール１７０はチャートによってたどられる経路、例えば終了した待機ブロック、横断したフロー、及び送信されたアクション等を記録する監査レコードのストリームを生成する。この例では監査レコードが、監査ファイル内（即ちデータベース１７４内）に記憶されるログ済み活動、又はデータベース１７５内に記憶されるインデックス付き圧縮フラットファイル（ＩＣＦＦ）内に記憶されるログ済み活動を含む。概して、監査ファイルは様々な監査レコードを記憶するためのファイルを含む。この例では、監査レコードが全てのパルスの終わりにファイルに書き込まれる。この例では、データベース１７４がパルスごとに１つの新たなファイルを受信する。

【0087】

環境１６０は、未処理の情報（即ちデータベース１７４内に記憶される監査ファイル）を処理し、その未処理の情報をＩＣＦＦ用の形式に再フォーマットするグラフを含む監査ファイルプロセッサモジュール１７６を含む。この例では、データベース１７４が監査ファイルを再フォーマットのために監査ファイルプロセッサモジュール１７６に伝送する。それを受けて監査ファイルプロセッサモジュール１７６は、再フォーマット済みのファイルをデータベース１７５に伝送し、データベース１７５は、１つ又は複数のキーフィールド（例えばハッシュ値、対象者ＩＤ又はキー）によって（インデックス１８０内で）インデックス付けされ、時間によって（例えば１時間ごと又は１日ごとに）まとめられるＩＣＦＦレコード１７８内に再フォーマット済みのファイルを書き込む。この例では、インデックス１８０が「ハッシュ値」カラム及び「アドレス」カラムを含む。ハッシュ値カラムは、インデックス付けされているＩＣＦＦレコード内のキー（又は他のデータ）のハッシュ値を含む。アドレスカラムは、ハッシュ値によって参照されるデータブロックのデータベースアドレスを含む。この例では、ＩＣＦＦレコード１７８がデータブロック１８２を（例えばポインタ又は別の参照データ構造によって）参照する。この例では、未処理の情報の一部がＩＣＦＦレコード１７８のために再フォーマットされる（後にインデックス１８０内でインデックス付けされる）が、未処理の情報の他の部分はデータブロック１８２内に記憶され、データブロック１８２はＩＣＦＦレコード１７８によって参照され、そのためＩＣＦＦレコード１７８によって識別可能且つアクセス可能である。

【0088】

この例では、監査ログモジュール１６６が監査レコード１３２ｉ、１３２ｒ、１３２ｓ（図６Ｅ）、及び監査レコード１４０ｎ～１４０ｑ（図６Ｅ）を受信してロールアップ済みのレコード１５４を作成し、ロールアップ済みのレコード１５４はロールアップ済みのデータレコード（図６Ｅ）内の未処理の情報を処理するために監査ファイルプロセッサモジュール１７６に伝送される。具体的には、監査ファイルプロセッサモジュール１７６は、ロールアップ済みのレコード１５４内の未処理の情報をＩＣＦＦ、例えばＩＣＦＦレコード１７８用の形式に再フォーマットする。この例では、ＩＣＦＦレコード１７８がキーフィールドとしてｃｈａｒｔ＿ＩＤフィールド（即ち監査レコード１３２ｉ、１４０ｑに由来する）を含む。ＩＣＦＦレコード１７８内に含まれない監査レコード１３２ｉ、１３２ｒ、１３２ｓ（図６Ｅ）、及び監査レコード１４０ｎ～１４０ｑ（図６Ｅ）のコンテンツはデータブロック１８２内に含まれる。システムは、ＩＣＦＦレコード１７８及びデータブロック１８２をデータベース１７５内に記憶する。この例では、データベース１７５がインデックス１８０を記憶し、ＩＣＦＦレコード１７８はＩＣＦＦレコード１７８内のキー（即ちキー：４２４２４及びキー：５３４２２）のハッシュ値によってインデックス１８０内でインデックス付けされる。この例では「４２４２４」及び「５３４２２」の値を、インデックス１８０のロー１８０ａ内で示すようにそのハッシュ値が「０１１０」である「４２４２４５３４２２」の文字列に連結することによってシステム１６２がキー：４２４２４及びキー：５３４２２のハッシュ値を生成する。インデックス１８０は、例えば異なる時点における及び／又は異なるチャートを実行することによる、例えば他の監査レコードのための他のＩＣＦＦレコードをインデックス付けするロー１８０ａ～１８０ｂも含む。この例ではＩＣＦＦレコード１７８が、インデックス１８０内のロー１８０ａ内で示す「０ｘ８２８２９」の値を有するアドレスフィールドによって（矢印１８３によって概念的に示すように）データブロック１８２を参照する。改変形態では、ＩＣＦＦレコード１７８が参照データ構造（例えばポインタ）によってデータブロック１８２を参照する。更に別の改変形態では、ＩＣＦＦレコード１７８及びデータブロック１８２が、インデックス付けされるＩＣＦＦデータブロック（又はデータブロック）へと組み合わせられる。

【0089】

一部の例では、監査レコードを指定の粒度（例えば１つのチャートに関する１人の加入者の１つのイベント）で一括し、ＩＣＦＦレコード上で記憶されるキーフィールド（例えばイベントの種類、加入者ＩＤ、タイムスタンプ、チャートインスタンスＩＤ等のためのフィールド）を計算し、次いで残りの監査レコードを集合にまとめることにより、監査レコード及び／又は監査ファイルが下記の通りＩＣＦＦのために再フォーマットされる。

【0090】

一例では、実行モジュール１６４が（例えばクエリ効率について最適化されているのではなく）スペース効率について最適化された監査レコードを生成する。この例では、例えば全ての監査レコードにｔｉｍｅｓｔａｍｐ、ｓｕｂｓｃｒｉｂｅｒ＿ＩＤ等を含めないことにより、監査レコードがスペース効率について最適化される。これらの監査レコードをＩＣＦＦ内に配置するために、本明細書に記載のシステムは（例えば全ての監査レコードに関するタイムスタンプ及び対象者ＩＤを含む）より完全なレコードを使用する必要があり、それにより本明細書に記載のシステムは（例えば監査レコードのコンテンツに基づく）個々のレコードを効率的に検索することができる。

【0091】

データベース１７５を実装する目標はイベントのシーケンスをクエリできるようになることなので、一部の例ではデータベース１７５がＩＣＦＦデータベースではなくリレーショナルデータベースを含む。かかるクエリを行うために、システムは監査レコードのストリームを１つ又は複数のレコード（例えばＩＣＦＦレコード）に変換する。各レコードは、１つ又は複数のインデックス可能／検索可能キーフィールド及び監査イベントの残りの部分を表すデータ集合を含む。

【0092】

一部の例では、レコードの粒度レベルが、１つのチャートに関する１人の加入者（例えばユーザ）の１つのイベントである。そのため本明細書に記載のシステムは、１つのチャートに関する１人の加入者の１つのイベントに対応する監査レコードのシーケンスを（例えばデータベース１７４内の監査ファイルから）抽出する。この例、イベントが逐次的に発生する。加えて、イベントごとの監査レコードはデータベース１７４内に（例えばデータベース１７４内のファイル内に）逐次的に記憶される。抽出した監査レコードを使用し、システムは例えばイベントの種類フィールド、加入者ＩＤフィールド、タイムスタンプフィールド、チャートインスタンスＩＤフィールド等を含む複数のキーフィールドを有するレコードを生成する。一部の例では、シーケンス内の第１の監査レコードがそれらの複数のキーフィールドの値を含む。システムは新たなレコードを生成する際にそれらの含まれた値を使用する。加えて、システムはそのシーケンスの残りの監査レコードに対応するデータブロックを構築する。システムは、生成される新たなレコードの一部として又は（例えば生成される新たなレコードにデータ集合又はｂｌｏｂを参照させることにより）生成される新たなレコードに関連して、そのデータブロックをデータ集合として（例えばバイナリラージオブジェクト（ＢＬＯＢ）として）データベース１７５内に記憶する。

【0093】

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

【0094】

この例では、データベース１７５が未処理のメトリックをＩＣＦＦ内に記憶する。この例では、環境１００がメトリックにアクセスするためのインタフェースを有するメトリックデータベース１８４も含む。システム１６２は、実行モジュール１６４内のメモリを読み出すのではなくＩＣＦＦからの監査レコードを後処理することによってメトリックデータベース１８４を作成する。ＩＣＦＦ１７５はパージされないので、様々な集約期間を使用することを含め任意の時点においてメトリックデータベース１８４を再作成することができる。

【0095】

従ってメトリック生成モジュール１６７は、未処理のメトリックを集約し、それらをメトリックデータベース１８４内に書き込むためのバッチグラフを（例えば１０分ごとに）実行するバッチグラフモジュール１８６を含む。メトリック生成モジュール１６７は、例えばユーザインタフェース１９０内に表示するためのメトリック（システム１６２内で見られる１つ又は複数の状態等）を計算するために「必要に応じて」実行されるメトリック計算モジュール１８８も含む。この例では、バッチグラフモジュール１８６がメトリックデータベース１８４及び／又はデータベース１７５からのメトリックにアクセスし、（この例では出力データセット１９２である）アクセスしたそれらのメトリックをユーザインタフェース１９０内で表示するために処理する。この例では、バッチグラフモジュール１８６によって生成され又は実行されるグラフが永続的な状態を有さず、メトリックの状態がメトリックデータベース１８４内で永続する。そのためバッチグラフモジュール１８６は、ユーザインタフェース１９０内で表示するためのメトリックをメトリックデータベース１８４にクエリする。一例では、例えばそのそれぞれを以下に記載するメトリックの動的表示、メトリックに関するレポート、及び調査インタフェースを含む様々な種類のユーザインタフェースが表示される。

【0096】

メトリックの動的表示では、コンソールがメトリック（例えば集約カウント）を表示し、表示内でそれらのメトリックをほぼリアルタイムで更新する。システムは、このデータ及びメトリックについてメトリックデータベース１８４をクエリする。この例ではコンソールが、（例えばタイマに基づいて又は指定の時間において）サーバからデータをプルすることしかできないポーリングインタフェースを含むウェブユーザインタフェース（ＵＩ）である。そのためＵＩ（例えばウェブページ）は、表示するための更新済みのカウントを求めて断続的にサーバをクエリする。更新済みのカウントはメトリックデータベース１８４内に記憶される。この例では、例えばブラウザとデータベースとの間に置かれるＪａｖａアプリケーションサーバを含む、ＵＩ（ウェブページ）とメトリックデータベース１８４との間でインタフェースするためのサーバ側ロジックがある。

【0097】

別の例では、ユーザインタフェース１９０が、メトリックデータベース１８４からクエリされるメトリックに関するレポートを表示する。この例では、ユーザがレポート及びダッシュボード内でメトリックを見ることができる。メトリックは、各キャンペーンに参加する人数、（例えばチャートの）各分岐を横断した人数、オファーを得た人数、オファーを受諾した人数等を指定する。ユーザインタフェースは、このレポート内の更なる詳細を「ドリルダウン」するためのコントロールを含む。ドリルダウンするために（例えば「トリガイベントを見たがオファーを得なかったそれらの１０人の対象者に何が起きたか」のクエリに回答するために）、システムはデータベース１７５内のＩＣＦＦ内のレコードにアクセスする。それらのレポートを実装するために、システムはドリルダウンがあるときにメトリックデータベース１８４及びデータベース１７５にアクセスすることができるサービス側モジュール（この例ではバッチグラフモジュール１８６）を実装する。

【0098】

更に別の例では、「加入者１２３４５が６月８日にイベント７を得たとき何が起きたか？」等の質問をユーザが尋ねることができる調査インタフェースをユーザインタフェース１９０が含む。これらの質問に回答するために、システムはユーザインタフェース１２４とデータベース１７５内のＩＣＦＦとの間のサーバ側モジュール（例えばＪａｖａ、グラフ等）を使用して（例えばデータベース１７５内の）ＩＣＦＦをクエリする。

【0099】

実行モジュール１６４は、データベース１７５内のＩＣＦＦ内に記憶するための複数の異なる種類の監査レコードを作成する。以下の表１は、様々な種類の監査レコードをその対応するフィールドと共に指定する。以下の監査レコードの種類の一部はロギングのレベルに応じて任意選択的である。この例では、例えば上記で説明したＩＣＦＦレコードのキーフィールドを生成する際に使用するための、以下の表１に示すフィールドに対応するフィールドの一覧をＩＣＦＦが記憶する。以下の表１の中でイタリック体で示すフィールドの値は実行モジュール１６４によって生成されるのではなく、ＩＣＦＦ内にデータが書き込まれるとき監査ストリームを振り返ることによって本明細書に記載のシステムによって推論される。このことは、実行モジュール１６４が著しく少ないデータを生成しなければならないことを意味する。以下の表１では、「？」カラムは監査レコードが任意選択的かどうかを示す。「＋」の記号は、監査レコードが実行モジュール１６４によって生成されることを意味する。文字は、監査レコードが任意選択的に生成され、１組の関係する制御ポイントによって制御されることを意味し、アスタリスクはレコードの種類がデフォルトで有効にされていることを示す。

【0100】

【表1】

【0101】

【表2】

【0102】

【表3】

【0103】

一例では、データベース１７４が監査レコードを（例えばキーによって）対象者ごとに（例えば継続的に又は断続的に）まとめる。つまり監査レコードが対象者又はキーによって自動的にまとめられる。その結果、実行モジュール１６４は（例えばパルスごとに）監査ファイル内の各監査レコード内でｔｉｍｅｓｔａｍｐ、ｓｕｂｊｅｃｔ＿ｉｄ、又はｉｎｓｔａｎｃｅ＿ｉｄを複製する必要がない。むしろデータベース１７４は、グループ内のこれらのフィールドの過去に発生した値に基づいてこれらのフィールドの値を得ることができる。この例では、パルス間で状態を保つ必要がない。つまり、例えばブロック開始監査レコードは何パルスも前である可能性があるので、ブロック終了監査レコードはｂｌｏｃｋ＿ｎａｍｅを有さなければならない。データベース１７４内で、監査レコードが上記の表１の中で示した関連フィールドと共に完成する。

【0104】

一例では、システムがチャートに関する対象者（例えばユーザ又は加入者）のイベントの発生を検出する。そのため、実行モジュール１６４は「イベント認識」監査レコード、次いで「イベントディスパッチ」監査レコード、次いで「ブロック終了－イベント」監査レコードを生成する。これらの監査レコードから、システム（又は例えば監査ファイルプロセッサモジュール１７６）はｅｖｅｎｔ＿ｔｙｐｅ、ｔｉｍｅｓｔａｍｐ、及びｉｎｓｔａｎｃｅ＿ｉのフィールド用の値を得る。この例では、システムがこれらの監査レコードを１つのｂｌｏｂ内に集め、認識されたデータから（例えば監査レコードから）（例えばｅｖｅｎｔ＿ｔｙｐｅ、ｔｉｍｅｓｔａｍｐ、及びｉｎｓｔａｎｃｅ＿ｉｄの）キーフィールドがシステムによって別のレコード（例えばＩＣＦＦレコード）内で設定される。

【0105】

別の例では、チャートに関する対象者についてタイムアウトが発生する。この例では実行モジュール１６４が、アラームの種類の「イベント認識」監査レコード、次いで「アラームディスパッチ」監査レコード、次いで「ブロック終了－アラーム」監査レコードを生成する。これらの監査レコードから、システムはｅｖｅｎｔ＿ｔｙｐｅ、ｔｉｍｅｓｔａｍｐ、及びｉｎｓｔａｎｃｅ＿ｉｄのキーフィールドの値を決定する。この例では、システムはｉｎｓｔａｎｃｅ＿ｉｄフィールドの値を、例えばそのフィールドの値を推論するのではなく、ブロック終了－アラーム監査レコードから決定する。この例では、システムがこれらの監査レコードをｂｌｏｂ内に集め、認識されたデータ（例えば監査レコード）からキーフィールド（例えばｅｖｅｎｔ＿ｔｙｐｅ、ｔｉｍｅｓｔａｍｐ、及びｉｎｓｔａｎｃｅ＿ｉｄ等）がシステムによって設定される。

【0106】

更に別の例では、チャートを開始するイベントが対象者について発生する。この例では、実行モジュール１６４が（チャート開始の種類とすることができ又は別の種類のものであり得る）「イベント認識」監査レコード、次いで「イベントディスパッチ」監査レコード、次いで「チャート開始」監査レコードを生成する。これらの監査レコードから、システムはｅｖｅｎｔ＿ｔｙｐｅ、ｔｉｍｅｓｔａｍｐ、及びｉｎｓｔａｎｃｅ＿ｉｄのキーフィールドの値を得る。システムは監査レコードをｂｌｏｂ内に集め、認識されたデータ（例えば監査レコード）から（ｅｖｅｎｔ＿ｔｙｐｅ、ｔｉｍｅｓｔａｍｐ、ｉｎｓｔａｎｃｅ＿ｉｄ等の）キーフィールドが設定される。

【0107】

監査レコードはキーごとにまとめられるので、特定のキーに関連する監査レコードのサブセットはキーフィールドを含まない。例えば、データベース１７４又は又は監査ファイルプロセッサモジュール１７６は、イベント認識監査レコード、イベントディスパッチ監査レコード、ブロック終了－イベント監査レコードという監査レコードのシーケンスを受信することができる。この例では、データベース１７４又は又は監査ファイルプロセッサモジュール１７６がイベント認識監査レコードから対象者のＩＤ（例えばキー）を得る。そのため、実行モジュール１６４はイベントディスパッチ監査レコード及びブロック終了監査レコード内でキーを複製する必要がなく、それはこれらの監査レコードがイベント認識監査レコードの後にメモリ内で（例えばデータベース１７４又は他のシステムメモリ内で）シーケンシャルになるからである。同様に、イベントディスパッチ監査レコードはインスタンスＩＤフィールドを含む。そのためイベントエンジンは、ブロック終了監査レコード内にこのフィールドを含めるの複製する必要がない。システムが監査レコードメモリ（及びディスク上の）をまとめるので、システムはグループ内の全ての監査レコードにわたってキーを複製する必要がなく、それによりシステム資源をコンバースし、メモリ消費量を減らす。

【0108】

過度なデータ量の生成を回避するために、ユーザはイベントエンジンが監査レコードを生成するとき及びどの監査レコードを生成するのかを管理する。監査（従ってメトリック）は完全にオフにすることができるが、監査をオンにする場合、（先の表においてプラスの記号で印付けした）監査レコードのコアセットは無効にされない。監査レコードのコアセットは、イベントエンジンの入力（イベント及びアラーム）、出力（アクション）、エラー、並びにチャート及び待機ブロックの活動を追跡する。概してアラームは、予め計算された将来の時間に到達する（例えばチャートが自らに送信する）既定の種類のデータレコードを含む。他の監査レコードの種類は選択的に有効に及び無効にすることができる。任意選択的な監査レコードを有効にすることについて２つの側面があり、２つの側面とは何を有効にすべきか及びそれを何時有効にすべきかである。何を有効にすべきかについては、選択的に有効／無効にすることができる幾つかの別個の監査レコード群がある。それらは以下を含む：
・Ａ：アラームの設定（デフォルトでオン）
・Ｄ：行われた決定（デフォルトでオン）
・Ｐ：モニタリングポイント（デフォルトでオン）
・Ｒ：規則セットの呼び出し及び規則セットイベント
・Ｓ：変数の設定
・Ｖ：変数の読み出し
・Ｌ：ルックアップアクセス及びルックアップ変数

【0109】

何時有効にすべきかについては、これらの監査イベントのロギングを全てのものについて有効にすることができ、又は以下の１つ若しくは複数に基づいて限定することができる：
・１組の指定の対象者ｉｄ（例えばキー）だけ
・１組の指定の命名されたチャート及び／又はモニタリング名だけ
・１組の指定のイベントの種類（例えばレコードの種類）だけ

【0110】

一例では、実行モジュール１６４がこれらの監査レコードのロギングを制御ポイントによって構成する。概して制御ポイントは、（チャートを生成している）ユーザによって定められ、１つ又は複数のチャート（又はチャートインスタンス）の実行時における挙動を変更するために使用されるランタイムパラメータを含む。この例では、相互関係のある４つの制御ポイントの組によって監査レコードが（例えばイベントエンジンによって）制御される。５つの制御ポイントは以下の通りである：
・監査の種類－これは上記の表１で示した文字を使用してオンにされる監査レコードの種類のリストである。
・監査エンティティ－これは対象者ｉｄのリストである。空白でない場合、イベントエンジンはこのリスト内に含まれる対象者ｉｄについてのみ監査の種類リスト内の監査レコードの種類を生成する。（さもなければ全ての対象者ｉｄが監査される）。
・監査イベント－これはイベントの種類のリストである（例えば数字はイベントの種類に対応し又はイベントの種類を表す）。空白でない場合、イベントエンジンはこのリスト内に含まれるイベントの種類についてのみ監査の種類リスト内の監査レコードの種類を生成する。（さもなければ全てのイベントが監査される）。例えばＳＭＳメッセージが送信されたことを指定するイベント、ユーザがモバイルプランを新しくしたことを指定するイベント等を含む様々な種類のイベントがある。
・監査チャート－これはチャート名及びモニタリング名のリストである。空白でない場合、イベントエンジンはチャート名又はモニタリング名がこのリスト内に含まれるチャートについて監査の種類内の監査レコードの種類を生成する。（さもなければ全てのチャートが監査される）。
・監査変数－これは変数名のコンマ区切りのリストを含む。空白でなくイベントエンジンが変数（例えば設定される変数又は読み出される変数）に関する監査レコードの種類を生成するように構成される場合、イベントエンジンは変数名がこのリスト内にある場合にのみ監査レコードを生成する。

【0111】

一部の例では、実行モジュール１６４が異なる監査レコード群に異なる規則を適用する。この例では、第１の１組の規則（例えば監査の種類１、監査エンティティ１、監査イベント１、監査チャート１、及び監査変数１）を有する第１の監査レコード群（例えば第１の監査グループ）、及び第２の１組の規則（例えば監査の種類２、監査エンティティ２、監査イベント２、監査チャート２、及び監査変数２）を有する第２の監査レコード群（例えば第２の監査グループ）等がある。

【0112】

この例では、監査の種類、監査エンティティ、監査イベント、監査チャート、及び監査変数のそれぞれが一種のフィルタを含む。これらのフィルタの何れか又は全てが設定される場合、イベントのサブセットだけが追加の監査（例えば任意選択的な形式の監査を含む監査）を有する。

【0113】

一例では、以下のように第１の監査グループを実装することによってシステムが最小限の監査について構成される：
監査の種類１＝“”（任意選択的なものは有効にしない）
監査エンティティ１＝“”（全ての対象者ＩＤ）
監査イベント１＝“”（全てのイベントの種類）
監査チャート１＝“”（全てのチャート）
監査変数１＝“”（全ての変数だが、任意選択的な変数のロギングをオフにするようにシステムが構成されるのでこれは無視される）

【0114】

次に別の例では、ｓｕｂｊｅｃｔ＿ＩＤ１２３４５がオファーを送信するための全ての基準を満たしているにも関わらず、この対象者番号へのオファーが送信されない理由を評価するようにシステムが構成される。このオファーを実装するチャートは「ＭｙＯｆｆｅｒＣｈａｒｔ」であり、トリガイベントは６番である。オファーが送信されない理由に関するこの特定の対象者ＩＤについて全ての更に多くの詳細を得るために、システムは以下のように第２の監査グループを用いて構成される：
監査の種類２＝“ＡＤＰＲＳＶＬ”（全ての監査の種類を有効にする）
監査エンティティ２＝“１２３４５”（この対象者ＩＤだけ）
監査イベント２＝“６”（このイベントの種類だけ）
監査チャート２＝“ＭｙＯｆｆｅｒＣｈａｒｔ”（このチャートだけ）
監査変数２＝“”（全ての変数）

【0115】

この例では、イベントが発生すると、対象者ＩＤが監査イベント２のリスト内にあるか、及びイベントの種類が監査イベント２のリスト内にあるか、及びチャートが監査チャート２のリスト内にあるかをシステムがまず確認する。これらの属性（例えばフィルタ）の全てが真に評価される場合、システムは監査の種類２内で指定されるように全ての監査レコードの種類を実装し、そのことはそのイベントの持続時間にわたる任意選択的なロギングを開始する。そうではない場合、システムはデフォルトだけをログする監査の種類１を実装する。この例では、システムは高位番号のグループを最初に確認し、一致するグループが見つかるまで後方に進むように構成される。一致するグループが見つからない場合、システムはデフォルトを実装し使用する。改変形態では、更に多くの任意選択的なロギングを追加する、一致する全てのグループのユニオンを取るようにシステムを構成することができる。

【0116】

この例では、実行モジュール１６４が（例えばモニタリングポイント監査レコードの実装により）条件監査ロギングを実装し、その実行性能を最適化する。この性能を最適化するために、実行モジュール１６４は条件付きの監査の決定を行うためのデータ構造を予め計算する（例えば予め生成する）。概して条件付きの監査の決定は、監査レコードが生成されること、条件がどの指定の値（例えば真又は偽）に評価されるのかを指定する。この例では、イベントエンジンがイベント又はアラームに関するイベント処理の開始時に条件付きの監査の計算を行う。例えばイベントエンジンは、イベント又はアラームを検出するたびに（例えば上記の監査グループ内で）計算を行うが、（例えば全ての監査レコードに対してではなく）各イベント又はアラームの処理の開始時にのみ行う。イベントエンジンは、条件付きであり得る監査関数のそれぞれの中の大域変数及びクエリのパッケージ内に条件付きの監査の計算を保存する。

【0117】

監査レコードの種類ごとに、実行モジュール１６４はその監査レコードの種類の監査レコードが生成されているかどうかを指定する単一のフラグを実装する。実行モジュール１６４は単一のフラグを実装する際に監査エンティティ及び監査イベントのリストのコンテンツを分析し、それはイベントの処理が開始するときこれらのリストの両方が指定され又は生成されるからである。１つのイベントが多くのチャートによって処理され得るので、イベントエンジンは監査関数（例えば監査レコードの種類）が実装されているかどうかをチャートごとに判定する。監査チャートが空白でない場合、イベントエンジンは監査チャートのコンテンツを（それぞれチャートを識別する）インスタンスｉｄのリストに変換して、実装されているチャートのｉｄ及びどのチャートが監査レコードを生成しているのか（及びどの種類の監査レコードを生成しているのか）を指定するインスタンスｉｄ間の比較を単純化する。

【0118】

一例では、実行モジュール１６４が（例えば実行モジュール１６４内の又は実行モジュール１６４を含むシステム内の）メモリの中のアレイ内の監査レコードを収集し、イベント又はイベントストリームの処理の終了時に監査レコードを１つのブロック内で監査ファイルに書き出す。この例では、様々なイベント（即ち様々なキー又はユーザＩＤに関連するイベント）の監査レコードがメモリ内で混合されない。むしろメモリはパーティションに分割され、それぞれのパーティションが独自の監査ファイルを有する。そのため実行モジュール１６４は、監査レコードをキーによって自動的にまとめるように構成される。

【0119】

この例では、監査ファイルがバージョン付きである。パルスごとに監査ファイルの１つのインスタンスがある。監査ファイルはディスク上に蓄積し、監査ファイル処理グラフ（によって実行される又は監査ファイルプロセッサモジュール１７６）がパルスの終了時に各監査ファイルを（各パーティションから）入手し、監査レコードを後処理し、それらをＩＣＦＦ内に書き込む。

【0120】

この例では、例えば実行モジュール１６４内のメモリから監査レコードを読み出すのではなく、システムが（データベース１７５内の）ＩＣＦＦの監査レコードを後処理することによってメトリックデータベース１８４を生成する。この例ではＩＣＦＦがパージされない。そのため、様々な集約期間を使用することを含め任意の時点においてメトリックデータベース１８４を再作成することができる。この例では、メトリックデータベース１８４内のテーブルがｃｌｕｓｔｅｒ＿ｎａｍｅカラムを有し、そのため１つのデータベースを複数のクラスタに使用することができる。概して、クラスタはイベントエンジンのインスタンスを含む。概してイベントエンジンのインスタンスは、固有のキー値に関する１つ又は複数の仕様（実行モジュール１６４によって１つ又は複数のチャートが実行される）の具体的実現を含む。つまり各対象者ＩＤは、厳密に１つのイベントエンジンのインスタンスによって処理される。そのため固有のキー（例えば対象者ＩＤ）ごとに、そのチャートの全てを有する厳密に１つのイベントエンジンのインスタンスがある。同じクラスタに関する監査レコードは、同じｃｌｕｓｔｅｒ＿ｎａｍｅの値を有する。

【0121】

この例では、（例えばイベント認識監査レコードに基づく）実行モジュール１６４によって処理されるイベントの総数、（例えばエラーディスパッチ監査レコードに基づく）エラーを招いたイベントの数、（例えばアクション送信監査レコードに基づく）キャンペーンをトリガするイベントの数、（例えばブロック開始監査レコードに基づく）どの加入者が特定のキャンペーンの或るステージから別のステージに移るのか、（例えばチャート開始及びチャート完了監査レコードに基づく）特定の日にちにイベントエンジンにおいてキャンセルされ又は追加された加入者の数、（例えばチャート開始監査レコードに基づく）イベントエンジン内で実行されており、イベントエンジンによってイベントが処理されているときの実行モジュール１６４の状態を追跡する全体的なチャートの数等、実行モジュール１６４の状態を示すメトリックについてメトリックデータベース１８４をクエリすることができる。

【0122】

加えて、（例えば加入者ごとの）特定のキーについてメッセージが送信されなかった理由を指定するデータを取得するためにメトリックデータベース１８４が（例えばクライアント装置又は本明細書に記載のシステムによって）クエリされ得る。それを行うために、イベントエンジンは（例えばどのコンポーネント及び／又はリンクが実行されるのかを指定する監査レコードを作成することにより）実行モジュール１６４によってたどられたリンク（及び／又はチャート内で実行されるコンポーネント）及びアクセスされ実装される規則セットの事例をログするように構成される。次いでシステムは、チャートを通る全ての潜在的な経路に対して（例えば監査レコードによって指定される）チャートによってたどられる経路を比較して、（例えば監査レコードによって指定されるように代替経路を横断したためメッセージの送信に対応する経路が横断されなかったという理由で）特定のメッセージが送信されなかった理由を明らかにするように構成することができる。

【0123】

図８を参照し、トランザクションを表す１つ又は複数のデータレコードを処理するデータフローグラフを実行するためのための１つ又は複数のデータ処理システム（又は処理システム）によってプロセス２００が実装され、データフローグラフは複数のコンポーネント及びリンクを含み、コンポーネントは１つ又は複数の入力レコードを処理するために１つ又は複数の入力レコードに適用される計算を表し、入力レコードはトランザクションを表す１つ又は複数のデータレコードへの指定の関係を有し、リンクはコンポーネントを接続しコンポーネント間のデータフローを表す。操作、システムは複数のコンポーネント及びリンクを含むデータフローグラフを実行し実行し（２０２）、複数のうちの所与のコンポーネントは入力ポート、監査ポート、及び出力ポートを含む。入力ポートは、トランザクションを表す１つ又は複数のデータレコードへの指定の関係を有する１つ又は複数の入力レコードを受信するためのものである。監査ポートは、トランザクションの少なくとも一部を表す監査データを提供するためのものである。出力ポートは、１つ又は複数の出力レコードを提供するためのものである。コンポーネントの少なくとも１つ（例えば図２Ａ内のコンポーネント２３ｅ）が所与のコンポーネント（例えば図２Ａ内のコンポーネント２３ｊ）の実行よりも前に実行するように構成される。システムは、トランザクションを表す１つ又は複数のデータレコードをコンポーネント及びリンクを有するデータフローグラフによって処理し（２０４）、コンポーネントの少なくとも１つによって処理される１つ又は複数の入力レコードを指定する状態をコンポーネントの少なくとも１つが保存する。所与のコンポーネントによる１つ又は複数の入力レコードの処理中にエラーが発生した場合、システムはコンポーネントの少なくとも１つの状態を保存済みの状態に回復する（２０６）。回復した状態に基づいて、システムはデータフローグラフの所与のコンポーネントに関する監査データの少なくとも一部を回復する（２０８）。システムは、トランザクションの少なくとも一部を表す回復済みの監査データの少なくとも一部を監査ポート上で提供する（２１０）。システムは、１つ又は複数の出力レコードを出力ポート上で提供する（２１２）。

【0124】

上記の技法はコンピュータ上で実行するためのソフトウェアを使用して実装することができる。例えばソフトウェアは、（分散、クライアント／サーバ、又はグリッド等の様々なアーキテクチャのものとすることができる）１つ又は複数のプログラムされた又はプログラム可能なコンピュータシステム上で実行される１つ又は複数のコンピュータプログラムによって手続きを形成し、かかるコンピュータシステムは、少なくとも１個のプロセッサ、少なくとも１つのデータ記憶システム（揮発性及び不揮発性のメモリ及び／又は記憶素子を含む）、少なくとも１つの入力装置又はポート、及び少なくとも１つの出力装置又はポートをそれぞれ含む。ソフトウェアは、例えばチャート及びフローチャートの設計及び構成に関係する他のサービスを提供するより大きいプログラムの１つ又は複数のモジュールを形成し得る。チャートのノード、リンク、及び要素は、コンピュータ可読媒体内に記憶されるデータ構造又はデータリポジトリ内に記憶されるデータモデルに準拠する他の編成済みデータとして実装することができる。

【0125】

本明細書に記載した技法はデジタル電子回路、又はコンピュータハードウェア、ファームウェア、ソフトウェア、若しくはその組み合わせによって実装することができる。機器はプログラム可能なプロセッサによって実行するために機械可読記憶装置（例えば非一時的機械可読記憶装置、機械可読ハードウェア記憶装置等）の中に有形に具体化され又は記憶されるコンピュータプログラム製品によって実装することができ、方法のアクションは、入力データに作用して出力を生成することによって機能を実行するために命令のプログラムを実行するプログラム可能なプロセッサによって実行され得る。本明細書に記載した実施形態及び特許請求の範囲に記載の他の実施形態並びに本明細書に記載した技法は、データ及び命令をデータ記憶システムとの間でやり取りするために結合される少なくとも１個のプログラム可能なプロセッサと、少なくとも１つの入力装置と、少なくとも１つの出力装置とを含むプログラム可能なシステム上で実行可能な１つ又は複数のコンピュータプログラムによって有利に実装することができる。各コンピュータプログラムは高水準手続き型プログラミング言語若しくはオブジェクト指向プログラミング言語、又は所望の場合はアセンブリ言語若しくは機械言語によって実装することができ、何れにしても言語はコンパイラ型言語又はインタープリタ型言語とすることができる。

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

他の実施形態も本明細書及び特許請求の範囲に記載の範囲及び趣旨に含まれる。例えばソフトウェアの性質により、上記の機能はソフトウェア、ハードウェア、ファームウェア、ハードワイヤリング、又はそれらのものの何れかの組み合わせを使用して実装することができる。機能の一部が様々な物理的位置に実装されるように、機能を実装する特徴は分散させることを含め様々な位置に物理的に配置することもできる。本明細書及び本願の全体を通して「ａ」という語を使用することは限定的な意味で使用するのではなく、従って「ａ」という語について複数の意味又は「１つ又は複数」の意味を排除することは意図しない。加えて、仮特許出願に対して優先権が主張される限りにおいて、仮特許出願は限定ではなく本明細書に記載した技法をどのように実装し得るのかについての例を含むことを理解すべきである。

【0131】

本発明の幾つかの実施形態を説明してきた。それでもなお、特許請求の範囲及び本明細書に記載した技法の趣旨及び範囲から逸脱することなしに様々な修正を加えることができることを当業者なら理解されよう。

【図1】