JP2014002759A - グラフベース計算におけるデータ記録 - Google Patents

Abstract

【課題】ランタイムにてグラフベース計算におけるデータ処理成分の実行をトレースする。
【解決手段】ルールセットおよび対応するテストデータが入力として受け取られる（３０２）。生成器は、ルールセットに基づいて変換式を生成するとともに、テストデータ内の全てのレコードに対する出力値を算出する（３０４）。オプションとして、ユーザは、ログ情報の特徴を設定することができる（３０６）。生成された変換式を含むグラフベース計算のトレース実行においてログ情報が生成される（３０８）。ログ情報はログポートから出力され（３１０）、どのルールが実行されたかを実行後に判定するために分析される。
【選択図】図３

Description

関連する出願の相互参照

本出願は、２００８年６月３０日に出願された米国出願Ｎｏ．６１／０７７，０２２に基づく優先権を主張するものであり、その内容はここに参照として取り込まれる。

本記載は、一般に、グラフベース計算におけるデータ記録に関する。

複雑な計算は、有向グラフによるデータフロー（該計算の成分がグラフの頂点に関係付けられ、各成分間のデータフローがグラフのリンク（弧、辺）に対応する。）として表現し得ることが多い。このようなグラフベース計算を採用するシステムは、米国特許第５，９６６，０７２号，「グラフとして表現される計算の実行」に記載されている。頂点と関係付けられる上記計算は、人が読み取れる形式にて記述される場合もあり、「ビジネスルール」とも称呼される

一の態様において、一般に、方法は、データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様であって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義するルール仕様、を受け取るステップ；前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式を生成するステップであって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスを提供することを含むステップ；および、前記生成された変換式を用いて少なくとも一つのデータフローを変換するステップであって、ランタイムにて前記グラフベース計算における前記データ処理成分の実行をトレースすること、前記設定されたログ特性に準じて前記トレースされた実行に基づいてログ情報を生成すること、および、前記生成されたログ情報を格納または出力すること、を含むステップ、を含む。

いくつかの態様には、後述する特徴の一または複数が含まれ得る。

前記ログの特性を設定することは、ログ情報が生成される少なくとも一つのイベントを選択することを含む。

前記少なくとも一つのイベントは、前記受け取られるルール仕様に関連付けられたルールに準じて前記データフローに係るレコードを変換することに関連付けられる。

前記少なくとも一つのイベントは、変換されるレコードに係るエラーを特定することを含む。

前記少なくとも一つのイベントは、与えられたレコードについてのルールケースの条件を満たすことを含む。

与えられたレコードについてのルールケースの条件を満たすことは、前記与えられたレコードに係る値に基づく論理式を満たすことを含む。

与えられたレコードについてのルールケースの条件を満たすことは、前記レコードに係る値と前記ルールケースに関連付けられた値とを比較することを含む。

ログ情報を生成することは：
前記受け取られたルール仕様によって定義される前記ルールを含むルールセットの詳細を各々含む一または複数の凡例ログメッセージを生成すること、および、
複数のトレースログメッセージであって、各トレースログメッセージは凡例レコードと関連付けられるとともに、前記受け取られたルール仕様に関連付けられたルールに準じて前記データフローに係るレコードを変換することに関連付けられた少なくとも一つのイベントを記述するトレースログメッセージ、を生成すること、を含む。

前記イベントを記述するトレースログメッセージは、前記凡例レコードに係るインデックスを用いてデータ処理成分の少なくとも一つの入力または出力を記述する。

一または複数の凡例メッセージを生成することは、グラフベース計算の一回の実行ごとに一つの凡例メッセージを生成することを含む。

前記生成された変換式を用いる前記データ処理成分は、前記受け取られたルール仕様に関連付けられた第１のルールに準じて前記データフローに係る入力レコードを変換する。

前記トレースされた実行に基づいてログ情報を生成することは、前記規定された判断基準が満たされる前記第１のルールの各ルールケースに対してログメッセージを生成することを含む。

前記トレースされた実行に基づいてログ情報を生成することは、前記生成された変換式を用いて前記データ処理成分によって生成された変換されたレコードにおける各値に対してログメッセージを生成することを含む。

前記生成されたログ情報を格納または出力することは、前記データ処理成分の一または複数のログポートからログメッセージを出力することを含む。

前記生成されたログ情報を格納または出力することは、データ処理成分における前記ログポートからのログメッセージに係るデータフローを受け取ること、および、前記ログメッセージの少なくとも一部から派生するログ情報を格納すること、をさらに含む。

前記方法は、ログメッセージに係る前記受け取ったデータフローをフィルタリングすること、および、前記ログメッセージのサブセットから派生するログ情報を格納すること、をさらに含む。

前記生成されたログ情報を格納または出力することは：
前記規定された判断基準が満たされるトリガされたルールケースを指し示すデータ処理成分における前記ログポートからのログメッセージに係るデータフローを受け取ること、
前記入力レコードの全てによってトリガされる前記ルール仕様によって定義される前記ルールの各々に係る各ルールケースに対する少なくとも一つのログメッセージを提供する入力レコードの縮小セットを決定するために前記ログメッセージを検査すること、および、
前記入力レコードの縮小セットを格納すること、をさらに含む。

他の態様において、一般に、コンピュータシステムは、データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様を格納する格納システムであって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義する、格納システム；前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式を生成するように構成された生成器であって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスを提供する生成器；および、前記生成された変換式を用いて少なくとも一つのデータフローを変換するように構成されたグラフベース計算システムであって、ランタイムにて前記グラフベース計算における前記データ処理成分の実行をトレースすること、前記設定されたログ特性に準じて前記トレースされた実行に基づいてログ情報を生成すること、および、前記生成されたログ情報を格納または出力すること、を含むグラフベース計算システム、含む。

他の態様において、一般に、コンピュータプログラムは、コンピュータ読み取り可能な媒体に格納され、該コンピュータプログラムは：データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様であって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義するルール仕様、の受け取り；前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式の生成であって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスの提供を含む、該変換式の生成；および、前記生成された変換式を用いた少なくとも一つのデータフローの変換であって、ランタイムにおける前記グラフベース計算における前記データ処理成分の実行のトレース、前記設定されたログ特性に準じて前記トレースされた実行に基づくログ情報の生成、および、前記生成されたログ情報の格納または出力、を含む該データフローの変換、をコンピュータシステムに実行させる命令を含む。

他の態様において、一般に、コンピュータシステムは、データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様を受け取る手段であって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義する、該ルール仕様を受け取る手段；前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式を生成する手段であって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスを提供することを含む手段；および、前記生成された変換式を用いて少なくとも一つのデータフローを変換する手段であって、ランタイムにて前記グラフベース計算における前記データ処理成分の実行をトレースすること、前記設定されたログ特性に準じて前記トレースされた実行に基づいてログ情報を生成すること、および、前記生成されたログ情報を格納または出力すること、を含む手段、を含む。

以下、本発明の一または複数の実施形態の詳細について、図面および記述とともに説明する。本発明の他の特徴、目的および利点は、同記述、同図面および請求の範囲から理解され得る。

グラフベース計算環境における入力データから出力データへの変換を表す。 グラフベース計算におけるグラフの一例を表す。 情報の記録とともに変換式を生成することについてのブロック図を表す。 スプレッドシート型のルール項目の一例を表す。 個別型のルールの一例を表す。 グラフベース計算環境においてデータ記録を実行することについてのフローチャートを表す。 グラフベース計算環境における記録方式の設定についてのグラフィカルユーザインターフェイスの一例を表す。

データ記録および監査のメカニズムの一例として、グラフベース計算システムにおけるグラフベース計算に関連付けられるメタデータを保持したグラフベース計算構造が挙げられる。本例において、各々のコンピュータプログラムは、計算グラフ（データフローグラフまたは単にグラフとも称呼される。）を用いて実行される。グラフは、データ処理成分を表す一または複数の節点または頂点であって、成分間のデータの流れを表す有向辺によって接続された節点または頂点を含む。グラフは、並行処理環境において実行され得る。システムは、グラフの作成における変化を記録し、統計的依存性の分析を行い、グラフの作成に関するメタデータを管理する。グラフに関連するメタデータを保管することにより、生じ得るデータインパクトの分析（データがグラフにおいて実行されているときにどのように変化するか、および、他のグラフにおいてその変化が与える影響を、ユーザに対して視覚的に表現すること）が可能となる。さらに、コードが変更されても複数のバージョンのグラフを保管することを可能とする設定／変更マネジメントをシステムが提供することにより、最新のコードおよびデータが確実に入手され得る。

メタデータのサブセットとしてのビジネスルールは、システムに格納される。ビジネスルールの種々の態様は、例えば米国出願Ｎｏ．１１／７３３，４３４に記載されており、その内容はここに参照として取り込まれる。各々のビジネスルールは、個々のオブジェクトに格納され得る。ビジネスルールは、データを一のフォーマットから他のフォーマットへ変換するための判断基準、データに関する決定をするための判断基準、または、入力データのセットに基づいて新たなデータを生成するための判断基準、のセットとして表現され得る。例えば、図１Ａにおいて、フライト予約システムにおけるレコード１０２は、各フィールドに格納される値として、乗客の名前１０４、乗客の今年度の飛行マイル１０６、乗客のチケットのクラス１０８、および、乗客の座席の行１１０、を含む。ビジネスルールは、この乗客が搭乗グループ１に属すべきことを指示する。ビジネスルールは、一般に人間には容易に理解されるものの（例えば、「ファーストクラスの乗客はグループ１に属する」）、データを操作するために同ビジネスルールを用いる際にはコンピュータが理解可能な形態に翻訳される必要がある場合がある。

グラフベース計算環境においてビジネスルールを実行するために、変換式１１２が生成される。同変換式１１２は、一または複数のデータソース（例えば、入力データセット１００）からレコード１０２のような入力レコードを受け取り、出力レコード（例えば、出力データセット１２０に用いられる乗客名１０４および乗客の属するグループ１１８を示すレコード１１４）を提供する。本例において、上記データセットはレコードの一例を示すものであり、一般にデータセットに含まれるレコードの数は制限されない。入力および出力データセットは、データストリームとして処理され得る（例えば、データセットを構成するデータがグラフに流入または流出するように）。

そこで、変換式は、データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算に実装され得る。例えば、図１Ｂにおける単純な計算グラフ１３０においては、２つのデータセット１３２および１３４（例えば、利用頻度の高い乗客のデータおよびフライト予約データ）が入力され、各データセットのデータが一体として使用可能となるように同データがフォーマット成分１３６および１３８において個別にフォーマットされ、そして、結合部分１４０においてそれらが結合されて出力データセット１４２が生成される。変換式は、計算グラフ３０内にあるようなグラフベース計算そのものであってもよく、グラフの成分（例えば、グラフ１３０を構成する個々の成分１３６，１３８および１４０）内に実装されているものよい。

技術分野に詳しくないユーザであっても容易に変換式を生成することができるように、ルールセットとも称呼されるビジネスルールのセットをそれらユーザが理解し易い形式にて入力するツールが提供される。同ツールは、ユーザが変換式に実行させたい内容をコンピュータシステムに伝えるものである。一の変換式を生成するルールのセットが一のルールセットである。また、ルールセットは、入力に応じてルールの異なる出力値を決定する一または複数のルールケースによって構成され得る。また、ルールセットは、他のルールを含んでもよい。ルールセットに含まれる他のルールは、追加の出力値または代替の出力値を決定してもよい。また、ルールセットは、「被包含」ルールセットとも称呼される他のルールセットを含んでもよい。

図１Ｃは、情報を記録しながら変換式を生成するシステムの一般的なモデルを示す。ビジネスルール環境（ＢＲＥ）は生成器１５０を含む。同生成器１５０は、エディタ１５４からルールセット１５２を入力として受け取って変換式１５６を生成する。変換式生成のオプションの一つとして、それに続いて、グラフィカルユーザインターフェイスにおいて種々の記録イベントおよび情報のカスタマイズによるロギングが行われ得る。ログは、所定のシステムおよびネットワーク内にて生じるイベントについての記録である。ログはエントリーによって構成され、各エントリーはシステムおよびネットワークにて生じる特定のイベントに関連する情報を含む。ログは、トラブルシューティング、および、種々の機能（システムやネットワークのパフォーマンスの最適化、ユーザの操作の記録、ならびに、異常処理の調査に有用な情報の提供など）に供するように用いられ得る。また、ログは、種々の異なる種類のイベントに関連する情報を含み得る。また、生成された変換式１５６は、システムのアーキテクチャならびに変換式およびビジネスルールの目的に応じて、一のグラフまたはグラフ全体そのもので使用されるべき成分としてグラフベース計算システム１５８でに提供され得る。生成器１５０として、例えば、コンパイラ、特注のプログラム、または、ルールセット１５２を受け取って変換式１５６を出力するための標準的なツールを用いて構成される他のグラフベース計算、が挙げられる。

生成器１５０は、ルールセット１５２が編集されたときに変換式１５６をアップデートし得る。また、エディタ１５４は、ルールセット１５２が編集されたときにそのルールセット全体を提供してもよく、新しいまたは変更されたルールまたは新しいまたは変更されたルールケース１５２ａだけを提供してもよい。また、生成器１５０は、変換式を用いるシステムの性能および要求に応じて、元の変換式１５６の全体を置き換えるための新しい変換式を生成してもよく、変換式を含む成分１５６ａを提供してもよい。

グラフベース計算１５８の際にロギングを行うための個別・専用の実行エンジンは、必要ではない。ロギングは、その記録が行われる際にグラフ成分によって呼び出される機能を用いて行われるように構成され得る。記録の異なる態様として、ルールの実行についての監査報告が提供され得る。例えば、図１Ｃにおいて（実線矢印によって示される実際のデータフローとは異なる）破線矢印に示されるように、ルールセット１５２内の特定の入力記録にログ１６０ａが戻されてもよいし、事前に実行された特定のルールケース１５２ａにログ１６０ｂが反映されてもよい。

図２Ａに示すように、いくつかの例において、スプレッドシートのフォーマットにルールが入力され得る。スプレッドシート２００のトリガ列２０２，２０４，２０６，２０８が入力可能なデータ値に対応し、行２１０ａ〜ｈがルールケース（すなわち、入力可能なデータ値に関連する判断基準のセット）に対応する。ルールケースが判断基準を備えているトリガ列それぞれに関し、所定のレコード（例えば、図１Ａにおける１０２）内のデータ値がトリガ判断基準を満たしていれば、そのレコードにルールケース２１０ｎが適用される。ルールケース２１０ｎが適用されると、一または複数の出力列２１２に基づいて出力が生成される。ここで、全てのトリガ判断基準が満たされたルールケースは、「トリガされた」とも称呼される。各出力列２１２は潜在的な出力変数に対応し、その出力変数に関し、適用可能な行２１０ｎの対応するセル内の値が（もしあれば）出力を決定する。後述するように、セルは、上記変数に割り当てられる値を含むことができるし、出力値を生成するために計算されなければならない数式を含むこともできる。図２Ａにおいては出力列は一のみ示されているが、一よりも多い出力列が設けられていてもよい。

変数に対応する列、数式ではあるが一旦計算された後に変数のように扱われる数式を格納した列、および、数式のみを格納した列といった様々な幾つかの形式のトリガ列が挙げられる。他の形式の列の例として、データのみを格納した列、および、データのみを各ノズルした列に基づいて列毎に計算する数式を特定する列が挙げられる。数式のみを格納した列は、変数に対応する列または変数として扱われる列よりも簡便である。

図２Ａの例においては、第１の行２１０ａは列２０２のみに判断基準を有し、これは乗客の合計飛行マイルが１，０００，０００以上であれば他の列の値が如何なる値であるかに係わらずルールケースが適用されることを表している。この場合、このユーザに対する出力変数「搭乗グループ」はグループ１に設定される。同様に、第２のルールケース２１０ｂは、ファーストクラスの乗客であれば常にグループ１に設定されることを表している。いくつかの例においては、ルールが順に評価されれば、１，０００，０００マイル以上を有し且つファーストクラスのチケットを有する乗客はグループ１に設定されるが、第１のルールケース２１０ａのみがトリガされる。一のルールケースがトリガされれば、そのルールの他のルールケースは評価される必要はない。

次のルールケース２１０ｃは２つの入力値２０２および２０４に基づくものであり、合計飛行マイルおよび今年度のマイルの双方の判断基準が満たされれば、乗客はグループ２に設定される。第４のルールケース２１０ｄにおいては、ビジネスクラスの乗客であれば常にグループ２に設定される。残りのルールケース２１０ｅ〜ｈは、他のルールケースに関係する判断基準（すなわち、「他」および「同上」）を有する。「他」は、その行よりも上の行であってその左側において同じ判断基準を有する行（すなわち、ルール２１０ｂおよび２１０ｄ）において、その列におけるいずれの判断基準も満たされないことを表している。一方、「同上」は、その列におけるその上のルールケースが適用された場合にそのルールケースが適用されることを表している。よって、第５のルールケース２１０ｅは、２つの列２０２または２０４における判断基準がいずれも満たされず（満たされていれば、ルールケース２１０ａまたは２１０ｃによって処理される）、かつ、「座席クラス」の列が「ファースト」または「ビジネス」ではなく（列２０６が「他」であるから）、かつ、「座席の行」の値２０８が１０以下である記録に適用される。残りのルールケース２１０ｆ〜ｈは、列２０２および２０４に関する上のいずれのルールケースにも適合せず、且つ、「座席クラス」の列が「ファースト」または「ビジネス」ではなく、かつ、「座席の行」に適切な値がある記録に適用される。

図２Ａの例におけるルールケース２１０ａ〜ｈは、図２Ｂに示すように各々がスプレッドシートに格納された個別の単純なルールとしても表され得る。ルール２２０ａ〜ｄは図２Ａの行２１０ａ〜ｄにそれぞれ対応し、ルール２２０ｅは行２１０ｅ〜ｈに対応する４つのルールケースを有する。ユーザは、図２Ａに示すテーブル全体を生成するのではなく、これら個々のルールを個別に生成することができる。各ルールケースは、全てのトリガ列に値を格納しているとともに全ての出力列に値を格納している（値は空欄であってもよい。すなわち、「いずれも可」に設定されてもよい。）。複数のルールが同じ出力を生成する場合、それらルールは順序付けられ、一のルール内のルールケースが入力によってトリガされて出力を生成するまで順に検討される。一のルール内のいずれのルールケースもトリガされなければ、同じ出力を生成する次のルールが処理される。全てのルール内のいずれのルールケースもトリガされなければ、初期設定値が使用される。

いくつかの例において、エディタのインターフェイス１５０は、数式を格納したセルをグラフィカルに特定してもよい。これにより、真か偽かが評価される数式と、行の変数と比較される値を返す数式と、の違いをユーザが理解し易くなる。入力の際、ユーザは、例えばアスタリスクを最初に入力することによって特定のセルが数式セルであることを指定し得る。

出力変数に対応する列について、以下のうちの一つがセルに格納され得る。
・値
出力変数に割り当てられる値。
・数式
この数式の値が出力変数に割り当てられる。数式によってＮＵＬＬが求められた場合、出力フィールドがＮＵＬＬ禁止でなければ、フィールドにＮＵＬＬが設定される。出力フィールドがＮＵＬＬ禁止であれば、エラーが生成される。
・「ＮＵＬＬ」の文字
出力フィールドがＮＵＬＬ容認であれば、フィールドにＮＵＬＬが割り当てられる。そうでない場合、エラーが生成される。
・空の文字列
出力フィールドが初期設定値であれば、初期設定値が割り当てられる。そうでない場合、セルはＮＵＬＬが格納されているように扱われる。
・「同上」の文字
出力フィールドに上のセルにて計算された値と同じ値が割り当てられる。

可能であれば、エラーが検出されたとき（すなわち、ＮＵＬＬ禁止フィールドである出力列にＮＵＬＬが設定されたとき）、エラーが報告される。しかし、テストタイムまたはランタイムまで報告されないエラーもあり得る。

テーブルの行として生成された場合でも個別のルールとして生成された場合でも、各ルールは所定の属性のセットを有する。ルールセットは、同ルールセットに含まれるルールに適用されるこれら属性を定めてもよい。これら属性の例として、名前、ルールタイプ、説明やコメントフィールド、出力変数のリスト、入力変数のリスト、引数のリスト、トリガ列のリスト、更新履歴、テストデータセット、および、エラー処理動作、が挙げられる。名前は読んで字の如くであり、ルールをルールセット内に並べるために用いられる。いくつかの例において、ルールタイプはルールセットのプロパティである。出力変数のリストは、ルールによって生成または割り当てられた変数のセットである。これはルールセットから引き継いでもよく、出力が一または複数となってもよい。入力変数のリストは、ルールがレコードを評価するために必要とする全ての変数を特定するものであり、列の最上段の変数および数式内にて用いられる変数（例えば、図２Ａにおけるルール２１０ｃにて用いられる「前年度の飛行マイル」値は、数式内にて用いられるものの、それ自体の列を有さない。）が含まれる。

ルールは、単独発動型であっても複数発動型であってもよい。例えば、複数のルールケースが一または複数の出力のための複数の値を生成するために用いられてもよい。複数のルールケースをトリガすることができるルールは、複数発動型ルールとも称呼される。複数発動型ルールは、そのルールによって計算される出力のタイプに基づいてのみ特定される。ルールによって計算される出力がリスト（各レコードについて複数の値を有し得る出力）であれば、ルールは複数発動型ルールである。複数発動型ルールにおいて、ルールケースが一旦トリガされると、対応する出力値は出力のための値のリストに付け加えられる。しかし、単独発動型ルールと異なり、複数発動型ルールにおいては、一のルールケースがトリガされた後においても評価は継続される。各々のルールケースが順に評価され、トリガされる全てのルールケースの出力値が出力のための値のリストに付け加えられる。

いくつかの例において、上述した例とは逆に、ルールは、行におけるルールケースをＡＮＤ形式にて評価するとともに列をＯＲ形式にて評価してもよい。つまり、一つのセルが真でありさえすれば各々の行はトリガされ（列はＯＲ形式）、全ての行がトリガされた場合にのみルールが出力を生成する（行はＡＮＤ形式）。

引数のリストは、関数ルールに対してのみ存在する。そのリストは、ルールに入力されるパラメータの名前および形式を特定するものであり、ルールセットのプロパティであってもよい。トリガ列のリストは、どの列がルールのアプリケーションをトリガし得るかを特定する。図２Ａおよび図２Ｂに示される入力変数に限られず、トリガ列には、パラメータ、ルックアップ変数、先に実行されるルールからの出力変数、被包含ルールセットの出力変数、ルールセットのパラメータ、または、数式、が対応され得る。トリガ列には、関数ルール（すなわち、引数）からの出力変数が含まれ得る。

エラー処理は、ルールを評価する際に生じるエラーをルールセットから生成された変換式がどのように扱うかを決定する。トリガ数式におけるエラーの処理の選択肢として、エラーを許可すること（この場合、変換式はエラーを引き起こすレコードを拒否する。）、または、エラーを無視すること（トリガ数式が偽であるとみなすことと同等であり、次の数式に移動する。）、が挙げられる。出力数式に対しては、エラーを許可してレコードを拒否すること、エラーを無視して出力にＮＵＬＬを設定すること、または、その行を無視して次の行に進むこと、によってエラーが処理され得る。

上述したように、変換式はルールセットから生成される。ルールセットは、後述する属性を有し得る。

＜名前、記述およびコメント＞
これらはルールセットを特定する。バックエンド実行に応じて、ルールセットは、システム内の自らの位置についての識別情報を含み得る。いくつかの例において、ルールセットの位置は、プロジェクト内のパスである。いくつかの例において、ルールセットは、リレーショナルデータベース内にて体系化され、名前によって位置を特定される。変更履歴は、変更名、日付、および、チェックインコメントを含み得る。

＜変換式のタイプ＞
これは、ルールセットから生成される変換式のタイプを決定する。後述するように、可能な値の例として、リフォーマット、ジョイン、ロールアップおよびフィルタが挙げられる。

＜入力データセット＞
これらは、編集のためのフィールドのリストおよび名前付き定数を提供する。いくつかの例において、初期設定により、変換式が生成されるとき、入力データセットのうちの一つのレコードフォーマットが採用されることになる。異なる環境に対してルールセットが変換式を生成することが許容されるように、複数の入力データセットがあってもよい。これにより、論理対物理マップの複数のセット（すなわち、物理名のセットが異なるもの）も許容される。いくつかの例においては、一または複数のデータセットを備えた入力マッピングテーブルがあってもよい。いくつかの例においては、ジョイン成分は、複数の入力マッピングテーブルを有してもよく、その各々が複数のデータセットを有してもよい。

＜出力データセット＞
これらは、出力フィールド名のリストを提供する。初期設定により、変換式が生成されるとき、出力データセットうちの一つのレコードフォーマットが採用されることになる。出力データセットは入力データセットと同一であってもよい。被包含ルールセットは、出力データセットを有さない。いくつかの例において、入力データセットと同様に、異なる環境に対してルールセットが変換式を生成することが許容されるように、複数の出力データセットがあってもよい。

＜被包含ルールセットのリスト＞
一のルールセットは他のルールセットによって計算された出力フィールド（出力レコードフォーマットのフィールドではなく、明示的にリストにされた出力フィールド）を使用し得る。包含ルールセット内に視認される被包含ルールセットの出力変数のセットを定める被包含ルールセットマッピングテーブルに基づき、被包含ルールセットにおける出力変数は、包含ルールセットにおける変数として用いられ得る。

＜被包含変換式ファイルのリスト＞
ルールセットが処理されるときに用いられる変換式を特定する一または複数のファイルが、オプションとして含まれ得る。

＜変数と定数とをリストにする一連のマッピングテーブル＞
これらテーブルは、入力データセットおよび出力データセットに関連付けられる。それらは、変数のリストをエディタに知らせ、ビジネス名と技術名との間のマップを文書化する。各変数は、ビジネス名、（数式を用いて計算され得る）技術名、および、ベースタイプ（文字列、数字、日付または日時）を有する。ビジネス名と技術名との間のマップを文書化する定数のリストが、オプションとして各変数に関連付けられる。変数テーブルの詳細は、後述される。

＜外部テストデータファイルへの参照＞
上述した組み込みテストデータセットと同様、テストファイルはルールをテストするために用いられる。

＜非拒否フラグ＞
このフラグが設定されているとき、ルールセットによって生成された変換式はレコードを拒否しない（エラーを生じる）。このフラグは、エラーを生じるルールがトリガされないかのように、そのルールを無視するように用いられる。

＜デプロイメントテーブル＞
これは、どのルールが各ビルドに含まれるべきかを（間接的に）示す一または複数のデプロイメントをリストにする。デプロイメントテーブルの詳細は、後述される。

＜オプションキー＞
これは、ジョイン型またはロールアップ型のルールセットのためのキーを表す特別な入力フィールドのビジネス名をユーザが特定できるようにする。いくつかの例において、キーは入力値のテーブルの項目として実際に採用される。

＜ルックアップファイルのオプションリスト＞
これは、ビジネス名、キー情報、および、入力変数および定数の完全なテーブル、ルックアップファイル毎に１つのテーブル、を提供する。ルックアップファイルのサポートの詳細は、後述される。

＜パラメータのテーブル＞
これは、環境またはランタイムにおけるパラメータに由来する変数をリストする。

ルールセットが関連付けられるいくつかの異なるテーブルとして：
１．入力変数および定数のテーブル
変換型ルールセットとして、このテーブルは、ルール内で参照される入力レコードフォーマットのフィールドを含む。レコードフォーマットの全てのフィールドがリストされる必要はないが、通常はそのようにされる。ジョイン型ルールセットとして、複数の入力テーブルがあり、各テーブルはジョイン操作に対する１つの入力データセットを示す。
２．全ての被包含ルールセットに対する入力変数および定数のテーブル
被包含ルールセットを用いる場合、各被包含ルールセットは、それ自体の入力変数および定数のテーブルを有する。変換式が生成されたとき、被包含ルールセットによって用いられる入力変数は、包含を行うルールセットに即して実際の入力箇所に振り分けられる。そのため、このリストは、包含ルールセットへ引き継がれる。複数の被包含ルールセットが包含される場合、各入力変数のテーブルが引き継がれる（被包含ルールセット自体がルールセットを包含する場合、二次的変数は引き継がれない）。被包含ルールセットから引き継がれる入力変数および定数は、包含ルールセットでの使用には利用できない。このテーブルが含まれることにより、被包含ルールセットへの入力と包含ルールセットへの入力との間のマッピングが確立される。詳細については後述される。
３．全ての被包含ルールセットに対する出力変数および定数のテーブル
ルールセットが包含されている場合、被包含ルールセットの出力は包含ルールセットへの入力となる。このテーブルは、それら全ての変数をリストにする。このテーブルは、初期状態では、全ての被包含ルールセット内の出力の変数および定数のテーブルから直接読み込まれる。ただし、名前の衝突を避けるためにビジネス名を変更し得る。このテーブルにおいて、技術名は被包含ルールセット内のビジネス名のままである。
４．出力変数および定数のテーブル
変換型ルールセットでは、このテーブルは、ルールセットによって計算される出力レコードフォーマットのフィールドを含む。計算されない出力変数も包含され得るが、ルールセットにより無視されることになる。（生成される変換式は、入力を出力へコピーするワイルドカードのルールを有する。さらに、出力は、包含された初期設定値を有し得る。）
出力変数は、中間変数としても用いられ得る。これは、一のルールから生成された出力の値が後のルールにおいて参照され得ること、を意味する。出力がこの用途に用いられるとともに、変換式からの出力レコードに出力が直接含まれない場合もある。
５．パラメータのテーブル
ルールは、パラメータへの参照を含んでもよい。パラメータは、グラフのパラメーターセットに即してランタイム時に用いられる。他の変数と同様、ルールセット内にて、パラメータは、ビジネス名、技術名（例えば、＄ＲＵＮＤＡＴＥ）およびタイプを有する。
６．ルックアップファイルごとの変数マッピングのテーブル
これらは、入力テーブルと同様であるが、ルックアップファイル用のレコードフォーマットでフィールドへ振り分けられる。

非共有ルールセット（変換式を生成するよう設計されている。）は、通常、入力データセットおよび出力データセットの両方に結びつけられている。入力データセットは入力変数のソースである。出力データセットは出力変数のソースである。ルールセットは、複数の入力データセットおよび／または複数の出力データセットを有する場合もある。その場合、各々の入力データセットおよび出力データセットが、変換式の入力または出力となり得る。入力変数のセットは１つのみ（ジョイン操作は除く。）であっても、異なるデータセットに対してはビジネス名と技術名との間のマッピングが異なってもよい。いくつかの例において、入力変数はルールセットによって使用されるとともに、入力変数が第１の入力データセット内には存在する一方で第２の入力データセット内には存在しなくてもよい。その場合、第２の入力データセットにおいて、関数が不足している変数の技術名として特定される。ルールセットが入力変数を使用しない場合、全ての入力データセットに対して技術名を提供する必要はない。

被包含ルールセット取扱いはいくらか異なる。被包含ルールセットは、関係する入力および出力のデータセットを有さなくてもよい。それらに代えて、被包含ルールセットは、入力変数および出力変数を有する。被包含ルールセットを包含するルールセットの役割は、入力と出力をマッピングすることである。

＜変数＞
変数は以下のプロパティを有し、テーブル形式にてユーザに提供される：
１．ビジネス名（論理名）
ビジネス名は、ルールにて使用される名前である。いくつかの例において、２つの入力変数が同一の名前を有さず、２つの出力変数が同一の名前を有さず、被包含ルールセットからの２つの出力が同一の名前を有さず、さらに、同一ルックアップファイル内の２つのルックアップ変数が同一の名前を有さない、ような制限が設けられる。入力変数は、出力変数と同一の名前を有し得る。その場合、ユーザインターフェースは、コンテキストに基づき、または、出力変数の名前の前に「ｏｕｔ」のような接頭語を用いることにより、入力と出力とを区別させてもよい。異なるルックアップファイル内のルックアップ変数は、同一の名前を有し得る。その場合、ルックアップファイルの名前自体のような接頭語を用いることにより、区別され得る。
２．単純な型
いくつかの例において、４つの基本型（文字列、数字、日付および日時）がサポートされ得る。これらは、文字列型（ｉｎｔ）、１０進数型（２０）、日付型（「ＹＹＹＹ−ＭＭ−ＤＤ」）および日時型（「ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ２４：ＭＩ：ＳＳ．ｎｎｎｎｎｎ」）に対応する。基本型と実際型との間の変換は、ビジネスルールの編集とは別に（例えば、生成される変換式成分によって）扱われる。
３．初期設定値
初期設定値は、出力変数に対してのみ必要である。この値は、（１）その出力に対するルールの出力列に空のセルがある場合、または（２）いずれのルールもその出力の値を計算するためにトリガされない場合、に用いられる。初期設定値は、出力変数がＮＵＬＬ容認な限り、ＮＵＬＬと（および空のセルをＮＵＬＬと解釈するように）し得る。
初期設定値は、ルール数式テーブルの出力列で使用される式と全く同じ式である。これは、初期設定値が入力変数または出力定数を参照でき、または数式を含み得ることを意味する。初期設定値は、循環参照とならない限り、他の出力を参照し得る。
４．技術名（物理名）または数式
これは変数を特定する数式である。入力および被包含変数のフィールド名の代わりに数式を使用できる（いくつかの例において、出力変数に数式を使用することは許容されない。）。ベクトルの場合、数式は完全修飾されるべきである。
入力を促されている変数および被包含ルールセットからの入力変数および出力変数を処理する場合、変数に関連付けられる技術名は、共有ルールセット内で使用されるビジネス名そのものである。内部でのみ使用される出力変数を処理する場合（一のルールにおいて計算されると共にそれに続くルールにおいて使用される中間変数）、技術名をブランクとし得る。
５．オプションとしての説明およびコメント

＜定数＞
変数の種々のテーブルは、変数だけでなく定数のマッピングも含む。定数はＣ＋＋のｅｎｕｍに対応する。システムは、有効値および無効値に由来する定数値、ならびに有効範囲および無効範囲に由来する定数範囲をサポートし得る。さらに、異なる値および／または範囲のセットを表す定数を生成することも可能である。

定数は変数と関係付けられる。これは、定数のビジネス名はルールセット全体を通じて固有名である必要がないことを意味する。エディタは、通常、その定数がルール内のどの列に現れるかに基づいて任意の定数に対するコンテキストを知る。しかし、ユーザは、数式中の異なる変数に属する定数を選択することも可能である。その場合、定数は、変数名（例えば、「飛行クラス．ビジネス」によって修飾される。

出力変数を計算する場合、単一の値の定数値のみが使用される（出力フィールドに範囲を割り当てるのは無意味である。）。

定数は、以下のプロパティを有し、テーブル形式でユーザに提供される（変数および定数は、テーブルを別のテーブルに組み込む場合と同様に、混ざり合ってもよい）。
１．変数名
定数は１つの変数に当てはまる。変数名は、実際には関連付けられる変数自体の一部である。
２．ビジネス名
ビジネス名はルールで使用される名前である。名前は、値を特定するものでなくてもよい（具体的には、内部スペースおよび句読点が許容される。）。定数に対するビジネス名は、適用される変数内にて固有のものである場合がある。
３．定数型
値、範囲またはセットのうちの１つ。上記したように、範囲およびセットは、比較（入力）にて用いられる場合には適正であるが、割り当て（出力）にて用いられる場合は適正ではない。
４．値に関して：実際値
本実施例において、文字列は引用符で囲まれ、数字は囲まれな。日付および日時は、初期設定形式にて引用符で囲まれる（例えば、「ＹＹＹＹ−ＭＭ−ＤＤ」）。変数型へ自動変換される単純な型を数式が返す限り、数式を用いてもよい。
定数が、被包含ルールセットの入力または出力のテーブルの一部である場合、値は存在しない。その代わり、値は、対応する入力変数または出力変数に対して関連付けられた定数のビジネス名である。
５．範囲に関して：最小値および最大値
上述した実際値と同様、両者は定数または数式である。範囲は、ルール内比較の簡易表現として使用される。等式による比較だけが範囲に許され、本システムは、範囲を「変数＞＝最小値および変数＜＝最大値」に翻訳する。最小値が特定されない場合、その部分の比較はスキップされる。最大値についても同様である。範囲は、コンマで最小値と最大値を区切る形式にて格納される。
６．セットに関して：コンマで区切られた値のリスト
リストの各要素は、上述した実際値と同様、定数または数式である。等式による比較だけがセットに許され、本システムは、セットを「変数の集合［値のベクトルリスト］」の形式にて数式に翻訳する。
７．オプションとしての説明およびコメント

共有ルールセットから引き継がれた変数を処理する場合、定数も引き継がれる。共有ルールセットに対する入力変数および出力変数を示すテーブルにおいて、これら変数に関連付けられる定数も示される。これら定数に対する初期設定のマッピングは、引き継がれる情報の一部であるが、ユーザは定数値を書き換える得る。

本システムは、変数の使用時に定数の不一致に起因するコンフリクトの可能性がある場合を検出する。具体的には、（１）ある変数の値が別の変数へコピーされる場合、（２）両方の変数が定義された定数を有す場合、および（３）定数のセットが名前および値の両方で同一でない場合、ユーザが一の変数の値を他の変数の値に翻訳する必要があるエラーが発生する。ソース変数の例として、入力変数、ルックアップ変数、被包含ルールセットからの出力、および、入力として使用される出力変数、が挙げられる。ターゲット変数の例として、出力変数、および、被包含ルールセットへの入力、が挙げられる。割り当ては、ルール数式または変数テーブルにおいて行われ得る。

＜変数の順序付け＞
循環ロジックを防ぐために、本システムは、変数およびルールを厳格に順序付けする。全般的な順序付けの例は、以下の通りである。
入力変数およびパラメータ。
第１の被包含ルールセットの入力マッピング。
第１の被包含ルールセットの出力値。
・・・
Ｎ番目の被包含ルールセットの入力マッピング。
Ｎ番目の被包含ルールセットの出力値。
第１のルックアップファイルの初期設定キー値。
第１のルックアップファイルの出力フィールド。
・・・
Ｎ番目のルックアップファイルの初期設定キー値。
Ｎ番目のルックアップファイルの出力フィールド。
全ての出力変数の初期設定値。

各項目の計算では前回のステップで計算された値が用いられる。これは、例えば、第１の被包含ルールがそのマッピングテーブルの入力変数およびパラメータを参照し得ることを意味する。しかし、第２の被包含ルールは、その入力を第１の被包含ルールから計算された出力へ振り分け得る。同様に、各出力変数に対する初期設定値はいずれのルールよりも前に計算されるので、それら初期設定値は、入力変数、パラメータ、ルックアップファイル、または、いずれかの被包含ルールからの出力の値、に基づく。ルールの出力を実際に計算する際、後のルールが先のルールで計算される値を用いることができるように、ルールは順に評価される。

＜変数へのデータセットのリンク＞
いくつかの例において、入力変数のテーブルは入力データセットレコードフォーマットから直接得られ、ビジネス名は入力データセットのメタデータから得られる。しかし、いくつかの例において、ルールセット内にこのマッピングのコピーを有することには利点がある。第１に、ルールセット内に変数マッピングテーブルのコピーを有することにより、生成環境の状況から外れたルールセットの編集が可能となる。ルールセットおよび関連付けられるルールは、サンドボックス内でシリアル化されるとともに、サンドボックスプロジェクトの一部として編集され得る。第２に、入力変数マッピングテーブルのコピーを有することにより、ユーザによるコンフリクトの解決または既存のメタデータの書き換えが可能となる。例えば、入力データセット内の２つのフィールドが同じビジネス名に振り分けられた場合、これらビジネス名の１つは入力変数テーブルの中で変更され得る。

ルールセットが始めて生成されたとき、入力変数テーブルは空である。ユーザが入力データセットを特定すると直ぐに、入力変数テーブルが入力データセットのメタデータから自動的に記入される（同じロジックが出力変数および出力データセットにも適用されるが、これ以降の説明は簡便のために入力データセットだけに絞られる。）。

この説明において、簡便のために「入力データセット」との用語が用いられる。入力変数にリンクし得るゼロ以上の入力データセットと、出力データセットにリンクできる別のゼロ以上の入力データセットと、がある。具体的に述べると、入力変数テーブルは、ビジネス名に対して１つの列、タイプなどに対して１つの列、および技術名に対して多数の列（入力データセットあたり１つ）を有する。一の入力データセットが指定されると、同様な技法を用いて２番目が追加され得る。ただし、２番目または後続のデータセットの場合には、技術名とビジネス名との間のマッピングが不完全なことがある。これは、特に
２番目および後続の各フィールドがいずれの変数に振り分けられるかを、システムが算定し得ない場合があるからである。そのような実施例では、ユーザは、いずれの不足情報をも手動で訂正し得る。

最初に入力データセットから入力テーブルを生成するとき、入力データセット内の各々フィールド毎に１つの入力変数が生成される。入力変数の技術名はフィールド名とする。タイプはフィールドのタイプに基づいて割り当てる。ボイドは文字列のように処理され、実数は数字のように処理される。サブレコード内のフィールドは対応する入力変数を有するが、サブレコードは対応する入力変数を有さない。ユニオンはユニオンの各ブランチに対する入力変数をもたらす。要素がベクトルの場合、対応する入力変数の技術名は、ベクトルの第１の要素（ｉｎ．ｖｅｃｔ［０］）を利用する。ユーザはこれを上書きし得る。例えば、複数出力変換式では、ユーザは技術名をｉｎ．ｖｅｃｔ［ｉｎｄｅｘ］とするように変更し得る。または、ベクトルが固定長の場合、ユーザは、ベクトルの他の要素に対応する追加の入力変数を生成してもよい。ユニオンおよびベクトルは、出力データセットではサポートされなくてもよい（それらのために出力変数が生成されなくてもよい。）。いくつかの例において、複数出力成分のバリエーションは複数の出力レコードの代わりに出力ベクトルを出力してもよい。

いくつかの実施例では、ビジネス名はメタデータから計算される。フィールドのビジネス名を決定するためのロジックの例は、以下の通りである。
フィールド（物理要素）が表示名を有する場合、フィールドの表示名がビジネス名として用いられる。
そうでない場合、フィールドが論理要素を有するとともに論理要素が表示名を有すれば、論理要素の表示名がビジネス名として用いられる。
そうでない場合、フィールドが論理要素を有すれば、論理要素名がビジネス名として用いられる。
そうでない場合、ビジネス名は技術名から算出される。

コンフリクト（二重の名前）が生じる場合、一のビジネス名のみが割り当てられる。他のフィールドにはいずれのビジネス名も割り当てられない。

いくつかの例において、ルールセットとデータセットのメタデータとの間の動的リンクはない。ユーザがメタデータのデータを変更する場合（例えば、論理要素の改名）、その変更は本システムによって自動的にピックアップされない。いくつかの例において、データ間の双方向関係性を用いてその変更を検出できるようにし得る。

ユーザが第２のデータセットをルールセットへ追加する場合、本システムは、上記にてリストしたものと同様の物理・論理マッピングルールを用いて、各々のビジネス名に対するフィールドを満たそうとする。変数がマッピングされない場合、その変数に対する技術語は追加データセットのために空のままとされ、ユーザはフィールド名または数式を手動にて記入しなければならない。利用可能なフィールドは、ユーザインターフェースにおいてプルダウンリスト形式にて表示される。

入力変数テーブルがデータセットのメタデータから生成されるとき、定数もデータセットのメタデータから入力変数テーブルに追加される。本システムは、論理または物理要素のそれぞれに関係する有効性確認スペックに関連する全ての有効値および無効値ならびに全ての有効範囲および無効範囲に対して定数を生成する。

定数に対するビジネス名を決定するための論理の例は、以下の通りである。
有効値（有効範囲等）が表示名を有する場合、表示名をビジネス名として用いられる。
そうでない場合、有効値（有効範囲等）が記述を有すれば、その記述がビジネス名として用いられる。
そうでない場合、定数は、ビジネス名なしで変数テーブルに含まれる。

データセットで始まる変数を生成することは必ずしも必要ではない。入力変数のリストを生成する第２の方法は、基礎システム内の論理入力を特定することである。論理入力を選択すると、本システムは、論理入力内の論理要素毎に１つの変数を有する変数テーブルを生成する。変数のビジネス名は論理要素の表示名とされる。論理要素が有効性確認スペックを有する場合、以前の文書ルールを用いて定数も生成される。

最後に、入力変数および出力変数は、変数テーブルにそれらを順次追加するか、またはルールを編集しながらそれらを生成するかのいずれかにより、手動にて追加され得る。例えば、ユーザが列をルールに追加するとき、ユーザはどの入力変数をその列に使用すべきかを選択する。ただし、ユーザは「ｎｅｗ．．．」を選択するとともにオンザフライで入力変数を生成することもできる。本システムは、ユーザにデータ型およびオプションのコメントを入力するように促す。技術名は後で入力されてもよい。

本システムには、ルールの編集を可能にするための変数リストが必要である。しかし、ビジネス名と技術名との間のマッピングは、後で完成されてもよい。マッピングは、ユーザが外部テストファイルに対して全ルールセットをテストするか、または、ルールセットから変換式を実際に生成するか、の準備ができている場合のみ必要とされてもよい。

＜被包含ルールセット＞
いくつかの例において、ルールセットを共有できる。具体的に述べると、被包含ルールセットは、別のルールセット内部に包含されるように設計されるので、その論理は包含ルールセットの生成変換式の一部となる。

被包含ルールセットは、専ら共有されるように設計されるのが通常であるが、被包含ルールセットは変換式を生成するために独立して使用され得る。例えば、ユーザは、フィルタ型変換式のブーリアン出力を計算するルールセットを生成できる。しかし、同時に、そのルールセットを別の変換式内に包含させて、ブーリアン出力（包含ルールセットで利用可能な、共有ルールセットの出力変数）を用いてもっと複雑な出力を計算し得る。

被包含ルールセットは、他の形式のルールセットと同様である。被包含ルールセットは入力変数および出力変数を有する。被包含ルールセットは、それ自体、他の被包含ルールセットを包含できる。しかし、被包含ルールセットの入力および出力の変数の取扱いは、変換型ルールセットを有するものと異なる。変換型ルールセットでは、入力および出力の変数は技術名に割り当てられるので、変換式が生成され得る。しかし、被包含ルールセットでは、入力および出力の変数を技術名にマッピングする必要がない。（あるルールセットが変換式を生成するために共有され且つ使用される場合、変換式を生成するデプロイメントのために入力および出力変数は技術名にマッピングされる。）

ユーザが被包含ルールセットを別のルールセットに包含させる場合、包含ルールセットは、被包含ルールセットの入力および出力をマッピングするための変数マッピングテーブルを有する必要がある。包含ルールセットに関連して、共有されるルールセットの入力変数および出力変数だけが視認される。共有ルールセットに包含されるいずれのルールセットのいずれの変数も、包含ルールセットには現れない。

包含ルールセットに関連して、共有ルールセットの入力変数は、包含ルールセットの変数、または、これらの変数を用いる数式に割り当てられる必要がある。共有ルールセットのビジネス名は変数マッピングテーブルにリストされるが、それら名前は包含ルールセット内のルールで使用するようには利用されない。それに代えて、包含ルールセットは、共有ルールセットの各入力変数（ビジネス名による）を包含ルールセット内の数式に一致させることだけを必要としてもよい。

被包含ルールセットの評価は、変数、パラメータおよびルックアップを入力する前に行われるように考えられているので、被包含ルールセットの出力はルックアップのキーとして使用され得る。いくつかの例において、評価の順序はよりフレキシブルであり、ルックアップの順序付けと被包含ルールセットの評価とは、依存関係に基づいて自動的に決定される。いずれかの出力変数が計算されてから被包含ルールセットが評価されるので、包含ルールセット内の出力変数は被包含ルールセット内の入力にマッピングされない。被包含ルールセット入力へのマッピングを単純な入力変数にて行うことができない場合、代わりに数式が用いられ得る。

被包含ルールセット入力変数へのマッピングは、被包含ルールセット内の入力変数がＮＵＬＬ容認な限り、ＮＵＬＬとし得る。マッピングは空のままにし得る。マッピングが空のままである場合、その入力変数が包含ルールセットの出力の計算で必要とされる場合であり且つその場合に限り、変換式生成時にエラーが報告される。いくつかの例において、全てがＮＵＬＬ容認とされることにより、ユーザインターフェースが簡略化される。

包含ルールセットに関連して、共有ルールセットの出力変数も、包含ルールセット内のビジネス名にマッピングされる必要がある。このマッピングテーブルは上記のマッピングテーブルとは逆である。共有ルールセットの入力変数をマッピングするとき、そのテーブルは、共有ルールセットの入力変数のビジネス名を包含ルールセット内の既存の変数にマッピングする。しかし、共有ルールセットの出力変数をマッピングするとき、包含ルールセットは、共有ルールセット出力のビジネス名を規定する表（包含ルールセット内の名前を共有ルールセット内の対応する名前にマッピングする表）を有する。

出力変数マッピングは、潜在的な名前コンフリクトを解決するために必要である。初期設定のマッピングは、包含ルールセットおよび共有ルールセットの双方にて同一のビジネス名を単純に用いている。しかし、共有ルールセット内の出力変数の名前は包含ルールセットで既に定義されている変数のビジネス名とコンフリクトする可能性があるので、包含ルールセット内のマッピングされた名前は変更され得る。

共有ルールセットからの出力の全てがマッピングされる必要はない。ある出力がマッピングされないままの場合、その出力を包含ルールセットにて用いることはできず、共有ルールセットからの対応するロジックは無視される。他方、共有ルールセットからの入力の全てはマッピングされてもよい。ただし、ルールセット設計者が必要ないと確信している場合、それらは関心のない変数へマッピングされ得る。いくつかの例において、本システム自体は、どの入力が実際にマッピングされる必要があるかを決定してもよい。

いくつかの例において、マッピングテーブルは、参照によって行われずビジネス名で行われる。共有ルールセットが別のルールセットに包含される場合、包含ルールセットは、共有ルールセットから入力および出力のコピーを得る。これらの名前は、マッピング情報とともに包含ルールセットに格納される。共有ルールセットの変更は可能なので、いくつかの入力または出力を追加、削除、または改名させることができる。

包含ルールセットと被包含ルールセットの間の参照整合性問題は、ルールセットがシステムからロードされるときに包含ルールセットによって取り扱われ得る。共有ルールセットから消える入力変数は、包含ルールセットから削除される。共有ルールセットに追加される入力変数は、包含ルールセット内のマッピングテーブルに追加されるが、マッピングされないままとされる。同様に、共有ルールセットに追加される出力変数は、包含ルールセット内のマッピングテーブルに追加されるが、マッピングされないままとされる。出力変数が共有ルールセットから削除されて包含ルールセット内で使用されない場合にはマッピングテーブルから削除されるだけであるが、出力変数が包含ルールセット内で使用される場合には変数がもはや利用できない旨のエラーをユーザは通知される。

包含ルールセットは、共有ルールセットからの冗長な情報を実際に維持する。具体的に述べると、入力および出力の変数マッピングテーブルにおいて、包含ルールセットは、共有ルールセット内のビジネス名のリストを包含ルールセット内の対応する名前と併せて維持することだけが必要とされもよい。効率向上のため、包含ルールセットは、共有ルールセットからコピーされたタイプ、初期設定値、説明およびコメントも維持する。これら値は、包含ルールセットを編集するときに読み取られるに過ぎないが、報告の生成および他の分析の効率向上のために包含される。

共有ルールセットマッピングテーブルは、包含ルールセット内に１つの追加項目（追加コメント）も有する。これにより、ユーザは、マッピングされた値に別のコメントを追加することが許される。

＜ルックアップファイル＞
ルールセットは、オプションとして１つ以上のルックアップファイルを有し得る。ルールセット内の各ルックアップファイルは以下の情報を含む。
１．ルックアップファイルのビジネス名
２．オプションの記述およびコメント
３．キーを作成するフィールドのビジネス名のリスト
これらの名前は、ルックアップファイルが数式に追加される場合に用いられ、ユーザは、ｌｏｏｋｕｐ（Ｍｙ Ｌｏｏｋｕｐ Ｆｉｌｅ，
＜顧客名キー＞，＜アカウントタイプキー＞）のような表示を見る。
４．各々のキーの初期設定数式のリスト
５．ルックアップファイルの技術名
いくつかの例において、これはデプロイメントにおいて上書きされ得る。
６．１つ以上のルックアップデータセット
各ルックアップファイルは、ルールセットが入力データセットと関連付けられているように、システム内にてデータセットと緩く関連付けされている。初期設定により、ルールセット内の各ルックアップファイルと関連付けられる１つのルックアップデータセットがあるが、他のデプロイメントで使用するためのより多くのルックアップデータセットがあり得る。
７．入力変数および定数のテーブル
これは、ルックアップファイル毎に１つのテーブルがあることを除き、ルールセットの入力変数および定数のテーブルと同様である。入力変数と同様、ルックアップファイルの入力変数および定数のテーブルは、関連付けられるルックアップデータセットの各々に対応する複数の技術名を有し得る。

１よりも多いルックアップファイルが存在してもよいことを除き、ルックアップファイルは入力変数と同様に取り扱われる。各ルックアップファイルは、１つのページ上で編集され、ビジネス名と技術名との間のマッピングテーブルを有し、複数のデータセットと関連付けられ得る。それらは、各フィールドと関係付けられる定数も有する。入力変数のメタデータが入力データセットからロードされるように、ルックアップファイルのマッピングは、ルックアップデータセットのメタデータを読み込むことによって初期化され得る。

ユーザがルックアップフィールド変数を用い且つそのキーがルックアップ内に見つからない場合、フィールドの値はＮＵＬＬとされる。フィールドがＮＵＬＬの場合にルールケースが特にトリガしない限り、ルールケースは偽と評価されてスキップされる。そのような場合、エラーは生じない。ユーザがルックアップファイル変数（フィールドではなく、ルックアップファイル自体）を用いる場合、関数ルックアップの一致が推測され、ルックアップファイル変数が真または偽であるか評価される。双方の場合が入力または出力列に対するルール数式へ適用される。ユーザが出力変数の初期設定としてルックアップフィールド変数を用いる場合、ルックアップの発見の失敗はＮＵＬＬに読み替えられる。

ルックアップ処理（参照ファイルから一または複数のデータレコードを検索するためにキーが用いられる。）は、通常の処理に比べて処理が遅い。ＢＲＥには、ルックアップ結果をキャッシュすることによって高負荷のルックアップ処理の数を制限するように設計されたコードが、各レコードに対して含まれている。ルールがルックアップ変数（ルックアップ処理から返される値のうちの一つ）を参照するときはいつでも、変換式生成プロセスにおいてルックアップ処理はサブルーチン呼び出しへ変換される。サブルーチンは、サブルーチンが現在のレコードに対してすでに呼び出されているか否かを示すグローバルブーリアン（各レコードが開始される際に偽に初期設定される。）を含む。ルックアップサブルーチンが最初に呼び出されるとき、ブーリアンは偽である。この場合、ブーリアンは真に設定される。そして、実際のルックアップ処理が実行され、ルックアップコールによって返されるレコードは変数内にキャッシュされる。最後に、テストが可能となったとき、ルックアップ処理の結果がイベントログに追加される。

同じレコードの処理における後続するルックアップ処理は、同じサブルーチンを呼び出す。しかし、後続のサブルーチンが呼び出されるとき、ブーリアンは真である。これにより、冗長なルックアップ処理に代えて（および追加のログイベントを生成することを避けるために）すでに読み込まれてキャッシュされたデータを返し得るように、サブルーチンの処理が変更される。

簡便のため、キャッシュは１つのキー値に対してのみ行われる。異なるキー値を用いて同じルックアップファイルへの複数参照が（同じレコードにおいて）行われる場合、それらルックアップ結果のうちの１つのみがキャッシュされる。他のルックアップサブルーチン呼び出しの全ては、実際のルックアップ処理に変換される。これにより、熟練した技術者は、単なる変数に代えてキャッシュ結果に対するハッシュテーブルを用いることにより、異なるキーによる複数ルックアップをサポートするための拡張を如何に行うべきかを把握し得る。

＜パラメータ＞
ルールセットはパラメータを参照してもよい。いくつかの例において、各ルールセットは、オプションのパラメータテーブル（変数テーブルと同様、パラメータのビジネス名を技術名にマッピングする。）を有する。パラメータテーブルの各項目は、以下の属性を有する。
１．ビジネス名
これは、ルール本体に現れるときのパラメータの名前である。一般に、パラメータは入力変数が使用されるところではどこでも使用し得る。
２．技術名
これは、開発環境におけるパラメータの名前である。
３．パラメータの型（文字列、１０進数、日付または日時）
生成された変換式において、パラメータは必要に応じて他の型に変換され得る。
４．オプションとしての説明およびコメント。

パラメータは、入力ファイル全体にわたってパラメータ値が定数であることを除いて変数と同様であり、その値は処理が開始されると外部から指定される。

＜ルールのテストおよび記録＞
変換式の生成の一部には、変換式が対応することになるルールをテストすることが含まれる。ルールは検証もされる（すなわち、ルールのシンタックスおよびセマンティックの一貫性がチェックされる。）。検証とは逆に、ルールを実行して正当性をユーザが確認すること（例えば、期待される出力がもたらされるか、または、出力を期待値と手動で比較すること）によってもテストは行われる。

システムは、２つのレベルのテストをサポートする。上述したように、各ルールは、関連付けられたテストデータセット（値および期待される結果を組み込んだテーブル形式）を有してもよい。これはユニットテストとも称呼される。ルールを編集する場合、テストデータのライン毎にルールの出力を再評価することができる。実際の結果と期待される結果との間の不一致または有効な結果の生成の失敗は、解決すべくハイライトされる。

いくつかの例において、外部入力テストファイルは、標準メカニズムを用いてサーバープロセスにアクセス可能である。外部ファイルを用いるテストはファイルテストとも称呼される。テストファイルは、入力データセットをルールセットにマッチさせるレコードフォーマットを有する。いくつかの例において、代替レコードフォーマットが提供されてもよい。オプションとして、ユーザは、期待される結果を含むデータセットを特定し得る。システムは、テストデータセットに対してルールセットを実行し、どのような出力がなぜ生成されたかを表示する。期待された結果が含まれていた場合、システムは実際の結果と期待された結果とを比較し、相違するあらゆるレコードをリストにする。いくつかの例において、ユーザが個々の値をインクリメトに再試行できるように、インターフェースが拡張され得る。

ユニットテストとファイルテストとの違いの例として、以下が挙げられる。
１．ルックアップファイルに関して：
ユニットテストモードにおいて、各テストケースについて、各ルックアップ変数の値がテストの一部として定義される。キーは規定されない；テストが実行されるとき、各テストケースについて、各ルックアップ変数に対して同一の値が採用される。テストデータセットは複数のテストケースを含み、各テストケースは各ルックアップ変数に対して異なる値を規定できる。ファイルテストモードでは、実際のルックアップファイルが用いられる。これは、異なるキーが異なる値を返すことを意味するとともに、特定のキーについて与えられるルックアップ変数に用いられる値をテスト中に変更することができないことも意味する。
２．被包含ルールセットに関して：
ユニットテストモードにおいて、被包含ルールセットは、実行されず、完全である必要さえもない。それに代えて、各被包含ルールセットからの各出力に対し、テストデータセット内にて値が指定される。ファイルテストモードでは、被包含ルールセットが、稼働中に実行されるであろう方法にて実行される。これは、被包含ルールセットに必要とされるいずれのルックアップファイルまたはパラメータも、テストタイムに指定されなければならないということを暗示する。
３．パラメータに関して：
ユニットテストモードにおいて、各テストケースの各パラメータに対して異なる値が設定され得る。ファイルテストモードにおいて、各パラメータの値はテスト全体について定数である。
４．現在の日付に関して：
テストにおいて、ルールが現在の日付または時間を参照する場合、ユーザは現在の日時として用いられるべき値を指定する。ユニットテストモードにおいて、日付および時間は各テストケースについて相違し得る。ファイルテストモードにおいて、テスト全体に対して単一の日付および時間の値が設定される（この値は、テスト実行時のマシンの日付および時間と異なっていてもよい。）。
５．レコードフォーマットおよびマッピングに関して：
ユニットテストにおいて、マッピングは指定される必要はない。テストは全体的に変数のビジネス名に基づいて実施される。ファイルテストについて、全ての変数は技術名にマッピングされ、入力、出力およびルックアップのレコードフォーマットが指定される。

図３におけるフローチャート３００に示すように、ルールセットは、特別な特徴を有する記録を行いつつ、テストされて正当性を確認される。３０２において、一または複数のルールセットおよび対応するテストデータが入力として受け取られる。３０４において、生成器は、ルールセットに基づいて変換式を生成するとともに、テストデータ内の全てのレコードに対する出力値を算出するためにそれを用いる。オプションとして、ユーザは、ログ（生成された変換式を含むグラフベース計算のトレース実行３０８において生成される。）の特徴を設定することができる。グラフベース計算において、関連する成分の「ログ」ポートは出力をテストするために用いられる。「ログ」ポートは、成分のための帯域外通信チャンネルである。それは、実際の出力データのレコードフォーマットの変更を求めない変換式からの追加出力メタデータを取得する方法の１つである。３１０において、ストレージシステム内のログファイルへ集められたログメッセージに実行中においてアクセス可能であるとき、ログ情報はログポートから出力される。オプションとして、ログメッセージがフィルタされるとともに、それらのサブセットがログファイルに格納されてもよい。例えば、出力レコードが変更されない場合、生成された変換式を含む成分は、大部分の入力レコードをパスしてもよい（例えば、与えられた入力レコードに対していずれのルールケースもトリガされない場合）。トリガされたルールケース（同ルールケースは入力レコードのフィールドにおける一または複数の値を変更する。）に対応するログメッセージのみを格納することが望ましい。グラフにおける一または複数の成分は、ログポートからのレコードを、それらログメッセージのみがログファイルに記載されるようにフィルタし得る。

テスト用に生成された変換式は、通常の実行用に生成される変換式とわずかに異なってもよい。例えば、通常の実行において、その変換式を用いる成分は、所定の出力ポートについて所定のタイプの出力レコードを生成してもよい。テストタイムにおいて、テスト関連出力は、出力レコードが不変であってもログポートに送られる。

第１のテストケースを始めとして、テストケースの入力は変換式に入力され、出力はどのルールがその出力を生成したかについての標識とともに出力配列に記載される。このプロセスは、最後の行が評価されるまで各行に対して繰り返される。出力配列は、上述したように、結果テーブルを生成するために用いられ得る。出力配列は、ルールセットが有効であるか否かを判定するために評価されてもよい。出力値は、生成された出力値についてのテストデータに含まれてもよく、一のテストにて生成された値がその前のテストにて生成された値と比較され得る。出力配列の第１の行を始めとして、生成された出力は、テストデータまたは事前のテスト結果から期待される出力と比較される。いずれかの出力が一致しない場合、不一致である旨が記録される。これが各行について繰り返される。いくつかの例において、評価ステップは出力生成ステップに統合される。上述したように、一のルールセットの出力は他のルールセットへの入力であってもよく、そのような場合には被包含ルールセットは包含ルールセットの一部として評価される。

ユーザは、出力フィールドまたは入力フィールドにて用いられる数式によってテストされるルールを制限し得る。いくつかの例において、ユーザは、テスト中にルールを実行不可とし得る。いくつかの例において、ユーザはテストファイル全体が処理されることを待つ必要はなく、テスト結果は始めのいくつかのレコードが実行されれば入手可能となる。

テストデータ自体に加え、ファイルテストおよび記録について以下の情報が３０８においてトレースされ得る。
１．入力データセットの物理位置
これは、各入力データセットに対する入力変数テーブルにおけるルールセットに格納される。ジョイン型データセットについて、全ての物理位置が必要とされる。物理位置が必要とされるときはいつでも、データベースのテーブル名が用いられ得る。
２．入力データセットのレコードフォーマット
初期設定として、これは、入力データセットに対するデータセット定義から取得される。サンドボックス内にチェックアウトされる異なるレコードフォーマットによってこれを上書きし得る領域が、入力変数内にある。ジョイン型変換式について、全てのレコードフォーマットが必要とされる。
３．どのデプロイメントが用いられるか。
４．全てのルックアップファイルについての物理位置
これはルールセットファイルテーブルに格納される。
５．各ルックアップファイルのレコードフォーマット
各ルックアップファイルに関連付けられるデータセット定義または上書きされたレコードフォーマットファイルにから取得される。
６．各パラメータについての値
これはテストパラメータダイアログにて設定される。
７．出力ファイルについての物理位置
これは回帰（比較）テストが行われる場合にのみ必要とされる。これは出力変数テーブルに格納される。
８．出力ファイルについてのレコードフォーマット
上記同様、回帰テストが行われる場合にのみ必要とされ、出力データセット定義またはオプションとしての上書きレコードフォーマットファイルから取得される。
９．プロジェクトサンドボックスの位置
テストはホスト上のサンドボックスの外にて行われなければならない。サンドボックスは、ルールセットを含むプロジェクトのチェックアウトコピーであるべきである。全てのレコードフォーマットファイルは、サンドボックスから取得され得る。
１０．ルールが「ｎｏｗ」、「ｔｏｄａｙ」または同様の値を参照するときの日付と時間について用いられる値

本例において、変換式は初期設定ではセル状態を記録しないが、この機能は図４に示すユーザインターフェイス４００において有効化され得る。すなわち、ユーザは、種々の特定の判断基準の記録をオン・オフするように３０６にて記録の特徴を設定し得る。ユーザインターフェイス４００は、いつログメッセージ（「ログレコード」とも称呼される。）が生成されるか（各入力レコードについて、いつエラーが生じるか、または、いつ特定の数式が真であるか、を含む。）を特定するセクション４１０、各ログメッセージに何が含まれているか（例えば、ルールケース実行、入力値、出力値、ルックアップ値、被包含ルールセットからの出力値、パラメータ値、および／または、各セルの評価の結果）を特定するセクション４２０、を含む。入力、出力などを記録することによって実行が遅くなるが、小さな程度に過ぎない。セル状態を記録することによって実行が相当程度遅くなり、一桁程度遅くなる可能性もある。テストが実行されると、検索された結果が所定の設定に従って表示される。

テストおよび／または記録が行われない場合であっても、生成器は、入力、出力などを記録する変換式を生成してもよく、その変換式を稼働中に用いてもよい。拡張された変換式は、同様の出力を生成するとともに、どのルールが実行されたかを実行後に判定するために分析され得る一群のログメッセージを生成し得る。ユーザがログファイルにて生成されたログメッセージ３１０を保存した場合、テスト入力が用いられなくても、稼働中におけるルールセットの実行を再現するための事実の後にＢＲＥが用いられ得る。この実行はプレイバックと呼ばれ、監査において有用である。ログファイルは、上述した、入力、出力、ルックアップ、トリガされたルールケースなどの詳細を含む。それは、どのバージョン（名前およびバージョン）のルールケースがログファイルを生成した変換式を生成するために用いられたかを厳密に記述するヘッダも有する。稼働中において、顧客はログポートの出力をファイル（圧縮されてもよい。）に保存すべきである。監査に際してセッションをプレイバックするためには、顧客は、ＢＲＥを起動してプレイバックセッションを開始する。顧客は、セッションログを含むファイルを特定する。ＢＲＥは、ヘッダを読み取り、記載されているルールセットおよびバージョンを開き、ログファイルの残りをファイルまたはユニットテストモードにて実行されているように実行する。プレイバック中の表示は、以下の例外を除き、ユーザがファイルまたはユニットテストを実行した後に見る表示と同じ表示である。例外として、（１）回帰データとの比較がないこと、（２）セル状態のような情報がログから失われ表示されない可能性があること、および、（３）表示されるルールセットのバージョンが正しいバージョンではない場合があるので、ルールセットはプレイバック中に読み取り専用とされること、が挙げられる。

記録機能が可能とされているとき、生成された変換式はログステートメントを含むように修正される。ログメッセージは、任意文字列をログポートに出力する機能であるｗｒｉｔｅ＿ｔｏ＿ｌｏｇ（）をコールすることによって生成され得る。ｗｒｉｔｅ＿ｔｏ＿ｌｏｇ（）が使用されるとき、特定のフォーマットのデータがログポートに書き出される。例えば、ログポートフォーマットの例は、以下の通りである。

ログ情報は全てｅｖｅｎｔ＿ｔｅｘｔフィールド（ｗｒｉｔｅ＿ｔｏ＿ｌｏｇ（）のコールにおいて特定される文字列を含む。）に格納される。ログポートレコードの他のフィールドは、成分によって自動的に満たされ、ＢＲＥに無視される。

（ログメッセージに特有の）ｅｖｅｎｔ＿ｔｅｘｔのフォーマットの例は、以下の通りである。

ｏｐＣｏｄｅｓの例は、以下の通りである。

本例において、入力レコード毎に１つのログメッセージが存在する。ログメッセージは一連のイベントを含む。入力、出力、ルックアップフィールド、実行されるルールケース、などの１つ毎に１つのイベントが存在する。これにより、入力レコード毎に多量の一連のイベントが構成される。

本例において、ログイベントにおける値フィールドは二進型ではない。それは、所定文字ｈｅｘ０１または改行を含まない。これらはイベント間またはレコード間の境界を誤ってトリガする場合があるからである。代わりに、全ての値は印刷可能な文字列に変換される。印刷不能な文字はｈｅｘ文字列に（例えば、改行は「＼ｘ０ａ」に）変換される。二進型変数は十進型などに変換される。

変換の最適化（内部ルックアップファイルを用いるような）は、記録の厳密さを確実にするために必要であれば、実行不可とされ得る。

第１のレコードが確認されたとき、対応するルールセットの詳細を含むログメッセージが生成される。これはいわゆる「凡例」ログメッセージであり、与えられたルールセットに対するグラフ実行毎に生成される。凡例ログメッセージの第１の部分は、ルールセットの場所およびバージョン名（プレイバックに必要である。）に加え、ログフォーマットバージョンを含む。各々の入力、出力、ルックアップファイル、ルックアップフィールド、パラメータなどの名前を記述する情報がそれに続く。それら名前はインデックスと関連付けられる（１は第１の入力変数であり、２は第２の入力変数である、など）。これにより、イベントに関連付けられる後続する「トレース」ログメッセージが、（名前ではなく）インデックスを用いて変数およびルールを参照し、ログファイルに場所を保存することができるようになる。

記録中のグラフによって処理されるデータフローの最初および全ての後続するレコードについて凡例ログメッセージがログファイルに記載された後、以下のログイベント（各々は対応するトレースログメッセージに関連付けられる。）が生じる。

（１）入力レコードが記録されている場合、ログメッセージは、各入力レコードについての入力変数の値を記述する入力変数の全てに対して生成される。
（２）パラメータが記録されている場合、ログメッセージは、パラメータの値を記述する入力変数の全てについて生成される。
（３）被包含ルールセットが存在する場合、被包含ルールセットにおけるルールが実行される。それらルールはこのロジックに準じて再帰的にログメッセージを生成する。
（４）ケース状態が記録されている場合、全てのルールにおける全てのケースの値が計算されて記録される。
（５）連結されたｉｆ−ｔｈｅｎ−ｅｌｓｅロジックまたはｓｗｉｔｃｈ分または内部ルックアップを用いて、実際のルールロジックは実行される。どのルールケースがトリガされるか確認された時点にて、そのトリガされるルールケースに対してログメッセージが生成される。
（６）どのルールケースがトリガされるか確認された時点にて、ルールの出力変数に値が書き込まれるとともに、割り当てられた値を記述するログメッセージ（例えば、変換されたレコードにおける値）が各出力に対して生成される。
（７）ルールが評価されている間に行われるルックアップ参照は、サブルーチンによって処理される。サブルーチンロジックは、ルックアップを行い、ルックアップファイルから読み込まれる全ての変数に対するログメッセージ（キーとして用いられる値および全ての見つけられたルックアップ変数の値を記述する。）を生成する。そして、サブルーチンは、ルックアップ値をメインロジックに返す。ルックアップサブルーチンは、それがすでに呼び出されたか否か、または、同じキーに対して二重のログイベントを生成することを避けなかったか否かを示すブーリアンを維持する。
（８）いずれのルールもトリガされない場合、最後のｅｌｓｅクローズ（または、ｓｗｉｔｃｈ文に対する初期設定クローズ）が実行されて初期設定出力値が割り当てられる。同時に、割り当てられた値を記述する各出力に対してログメッセージが生成される。

ログポートから提供されるログ情報は、種々の方法にて用いられ得る。例えば、いくつかの例において、テストデータセットとして用いられるデータセットと関連付けられる入力レコードの数は、グラフにおけるデータ処理成分のルールセットをテストするために用いられるテストデータセットのように、所定のシナリオに対して望ましい数よりも多くてもよい。ログポートからのログ情報は、グラフの初期処理中にグラフの成分によって処理され得る。それら成分は、ルールセットのルールにおける各ルールケースについての少なくとも一つのログメッセージを入力レコードの最小セットが提供するか、を決定するためにログ情報を調べることができる。例えば、成分は、各ルールにおける各ケースがトリガされる第１の入力レコードを特定する。そして、それら特定されたレコードは、縮小ルールセット（同ルールセットにおいては、全ての他の入力レコードが取り除かれる。）に関連付けられて格納される。限定テストデータセットは、ルールセットにおける同じルールおよびルールケースをテストすることができるが、テストを行う観点からより小さくより効率的であってもよい。

＜オーバーラップ解析＞
いくつかの例において、上述したように、ユーザがルールセットに対してテストデータセットを実行したとき、トリガした全てのルール（すなわち、全ての入力条件が満たされたルールケースであって、優先度がより高いルールケースに関する全ての入力条件が満たされなかったならば出力を生成したルールケース）が調査され得る。テストデータが処理された後、システムはテスト出力データを後処理し、どのテストケースによってもトリガされなかった全てのルールまたはルールケースのリストを生成し得る。どのルールがトリガされたか又はされなかったかをユーザに直ちに示すため、この情報はエディタ内のルールの表示上にオーバーレイされ得る。この情報から、ユーザは、他のルールによって覆い隠されている可能性のあるルール（すなわち、オーバーラップしているルール）を探し得る。各ルールケースについてカウントが示され得る。カウントは、ルールケースがトリガされたか否かを知ることと同様に有用であり得る。特に、出力の望ましい分布を達成するように値を調整する際、および、性能を調整するのに最適なルールセットを特定する際、に有用である。

＜変換式生成＞
ビジネスルールは、各ルールセットを変換式へ変換することにより、アプリケーション（グラフ）上にて評価される。変換式は、グラフ内の成分へアタッチされる。そのような成分は、変換式を実行するために特定の方法でリンクされる標準成分のセットを含むサブグラフであってもよい。これらサブグラフは、追加成分（例えば、ジョインおよびロールアップのためのキーを使用する。）とともに用いられ得る。

変換コードは、複数の方法にてビジネスルールから生成され得る。例えば、変換式の内部がユーザ編集されるように設計されていない場合、生成プロセスによって理解が困難な変換式が生成され得るが、ルールを１つずつ適用するよりもより効率良くルールが実施される。いくつかの例において、生成された変換式の性能を高めるべく、特殊なルックアップファイルまたは他の技術が用いられ得る。どのように変換式が生成されたかについてのいくつかの詳細は、デプロイメント内に格納され得る。複数のグラフで使用されるルールセットは、可能性がある別のユーザのための複数のデプロイメントを有してもよい。ルールセットは、ルールのスーパーセットを含んでもよく、その内のいくつかだけが各デプロイメント（そのデプロイメントは、変換式が生成されるときに使用されるルールを規定する。）にて要求される。ルールがｉｆ ｔｈｅｎ ｅｌｓｅロジックに代えて多数の定数値を有する場合（数式（もしあれば）は有さない。）、ルックアップテーブルが用いられ得る。この場合、ルックアップテーブルはルールの一部である（個別に保存されない。）。例として、以下のルールを検討する。

このルールは、以下の情報とともにメモリ内ルックアップテーブルを構成することにより取り扱われる：

そして、変換式は以下のようになる。

各ルールセットは、デプロイメントテーブル（名前をそのデプロイメントの構成についての詳細にマッピングするように適合されている。）を有する。図４に示すように、特定の実行情報を記録することを望むユーザは、各ルールセットのデプロイメントテーブルにおいて定義される属性に従い、グラフィカルユーザインターフェイス上の各項目を入力し得る。
１．デプロイメント名
ルールセット内部で一意でなければならない任意の文字列。
２．入力データセット名
入力変数テーブルに挙げられた複数の入力データセットがある場合、デプロイメントテーブルの各項目は、そのデプロイメントに対してどの入力データセットが使用されるかを指定する。
３．出力データセット名
出力変数テーブルに挙げられた複数の出力データセットがある場合、デプロイメントテーブルの各項目は、そのデプロイメントに対してどの出力データセットが使用されるかを指定する。
４．各被包含ルールセットに対するデプロイメント名
各被包含ルールセットについて、包含ルールセットの対応するデプロイメントに対してどのデプロイメントが使用されるべきかが指示される必要がある。
５．成分および生成されるべき変換式ファイルについてのターゲット場所。

いくつかの例において、初期設定と称呼される少なくとも１つのデプロイメントが常に存在する。これは他のデプロイメントが特定されない場合に使用されるデプロイメントである。

一の実施形態について、変換式生成の基本をここに示す。最初に、ルールセット内で計算される出力のためにルールが生成される。他の出力の全ては、変換式内のワイルドカードルールにて扱われる。一般に、内部のみにて使用される出力変数は、生成された変換式内にローカル変数を生成させる。すなわち、生成された変換式は、重複計算を避けるために、必要に応じて（例えば、最適化が領域確保よりも速度を目的とする場合）さらにローカルな変数を含んでもよい。

変換型に応じて、いくつかの変換の違いがある。
・リフォーマット
入力は「ｉｎ０」と呼ばれ、入力変数は「ｉｎ．ｆｉｅｌｄ」等の技術名を有してもよい。出力は「ｏｕｔ」と呼ばれ、出力変数は「ｏｕｔ．ｆｉｅｌｄ」等の技術名を有してもよい。
・ジョイン
２つの入力は「ｉｎ０」および「ｉｎ１」と呼ばれる。出力は「ｏｕｔ」と呼ばれ、ワイルドカードルールは「ｉｎ０」を「ｏｕｔ」にコピーすることとする。全てのパラメータは成分が生成されたときに設定される。ルールセットは、ジョインへの各入力毎に１つの複数の入力のセットを有する。ルールセットは、ジョイン型、入力が重複除外されるべきか否か、および、ジョインに対するキーとして用いられるフィールドのビジネス名、を指定する（いくつかの例において、これは各入力セットに存在しなければならない）。また、ユーザは、入力フィルタとして用いられる各入力についての数式を指定してもよい。
・ロールアップ
入力は「ｉｎ０」と呼ばれ、出力は「ｏｕｔ」と呼ばれる。ロールアップ型のルールセットの場合、ユーザは集計関数を使用することが許される（他の変換型ではサポートされない。）。技術名が「ｉｎｐｕｔ＿ｓｅｌｅｃｔ」または「ｏｕｔｐｕｔ＿ｓｅｌｅｃｔ」である出力変数をユーザが生成する場合、これら出力を計算するルールのロジックとともに「ｉｎｐｕｔ＿ｓｅｌｅｃｔ」および／または「ｏｕｔｐｕｔ＿ｓｅｌｅｃｔ」の関数が変換式に追加される。それら関数の双方の入力は「ｉｎ０」と呼ばれる（「ｏｕｔｐｕｔ＿ｓｅｌｅｃｔ」は、通常、そのパラメータを「ｏｕｔ」と名付けるのであるが。）。ジョイン型と同様、成分が生成されたときに全てのパラメータが設定され得る。
・フィルタ
２つの所定の定数のうちの一方が出力される。フィルタ型変換式の出力変数は、型成分「ｓｅｌｅｃｔ」のみである。同出力変数が非ゼロかつ非ＮＵＬＬであれば出力が渡される。いくつかの例において、これはサブグラフ内のリフォーマット成分として採用される。

追加の変換型も採用され得る。
・スキャン
スキャン型ルールセットについて、ユーザは、出力の一または複数の値であってレコード間にて記憶される値を特定し得る。これら出力の値は、通常、全てのレコードについて計算される。しかし、最後のレコードからの出力の値を含む出力の各々について、追加の組み込み入力が生成されてもよい。これにより、ユーザは、例えば、次のレコードにおける入力として用いられる状態にある出力変数に部分和を格納することにより、複数のレコードのフィールドの合計を計算し得る。
さらに、スキャン型ルールセットについて、ユーザはオプションキーを特定し得る。このキーは、レコードをまとめるために用いられる一または複数のフィールドである。スキャン型ルールセットについてキーが特定される際、レコード間にて記憶される全ての出力の状態はキーの特定の値ごとに異なる。例えば、キーが顧客番号であり、かつ、各顧客についての全てのトランザクションの合計を計算するために一の出力が用いられる場合、部分和は全ての顧客番号について保存され、各顧客に対して異なる和が計算される。
・分類
ルールはＮ個の出力を有し、変換式は各レコードについてどの出力が用いられるべきかを決定する。この成分について、システムは、ｏｕｔ：：ｃｌａｓｓｉｆｙ（ｉｎ）関数を生成する。出力は１つの整数値であり、どの出力ポート（２つ以上あり得る。）を使用すべきかを示すものである。例えば、０の出力は０番のポートを意味し、１の出力は１番のポートを意味する。
分類型変換の出力変数は、型成分「ｓｅｌｅｃｔ」のみである。同出力変数は、出力ポート（ゼロベース）のインデックスとされる。これは、出力として２個の代わりにＮ個の値が用いられることを除き、フィルタと同様である。
・関数
関数型ルールセットは、成分変換式としてではなく、変換式ファイルに変えられ得る。これに代えて、関数型ルールセットが変換式に変えられる場合、構築した変換ファイルは、他の変換式に含まれるように設計される。各出力変数は関数に変えられる。それら関数への入力は、ルールの型に依存する。関数型ルールにおいて、入力はテーブルにリスト化された順序のルールへの入力である。非関数型ルールにおいて、各出力関数はｉｎと名付けられた単一の入力（入力変数に対応するフィールドの全てを有するレコード）を用いる。

次にグラフの一部となる変換式を生成するためにルールセットが用いられる場合、グラフ成分にはルールセットの名前およびデプロイメントが含まれる。グラフ開発者は、成分内の生成された変換式に代えて、ルールセットを編集し得る。ルールセットを変更すると、変換式は再生成される。いくつかの例において、ユーザは、ＢＲＥによって生成された成分上にてシフトを押しながらダブルクリックし得る。シフトを押しながらダブルクリックすることにより、グラフィカル開発環境（ＧＤＥ）がＥＭＥ名、ルールセット名およびデプロイメントをパスしてＢＲＥを起動する。一の例として、コマンドラインインターフェイスがＢＲＥ処理を起動するために用いられ得る。ただし、その他のプロセス間コミュニケーション機構も採用され得る。

上述した記録手法は、コンピュータシステム上にて実行されるソフトウエアを用いて実現され得る。例えば、ソフトウェアは、一または複数のプログラムされた又はプログラム可能なコンピューターシステム（分散型、クライアント／サーバ型、または、グリッド型などの種々のアーキテクチャのものであってよい。）上にて実行される一または複数のコンピュータープログラム中のプロシージャを構成する。ここで、同コンピュータシステムは、少なくとも一つのプロセッサ、少なくとも一つのデータ格納システム（揮発性および不揮発性メモリおよび／または記憶要素を含む。）、少なくとも１つの入力装置またはポート、および、少なくとも１つの出力装置またはポート、を含む。ソフトウェアは、より大きなプログラム（例えば、計算グラフの設計および構成に関連する他のサービスを提供する。）の一または複数のモジュールを構成し得る。グラフのノードおよび要素は、コンピュータ読み取り可能な媒体に格納されるデータ構造として、または、データリポジトリに格納されるデータモデルに準拠する他の体系化データとして、実現され得る。

ソフトウェアは、汎用または専用のプログラマブルコンピュータによって読み取り可能な記憶媒体（ＣＤ−ＲＯＭ等）上において提供されてもよく、または、ネットワークの通信媒体を介してソフトウェアが実行されるコンピュータに伝送されてもよい（伝搬信号にエンコードされてもよい。）。関数の全ては、専用コンピュータ上にて、または、コプロセッサなどの専用ハードウエアを用いて、実行され得る。ソフトウェアは、分散方式（ソフトウェアが規定する計算の異なる部分が、異なるコンピュータにより実行される。）にて実行され得る。そのようなコンピュータープログラムの各々は、汎用または専用のプログラマブルコンピュータによって読み取り可能な記録媒体または記憶装置（例えば、固体メモリまたは媒体、あるいは、磁気媒体または光媒体）に格納されるか又はダウンロードされるか、が好ましい。これにより、コンピュータシステムが記憶媒体または記憶装置を読み取ってここに記載されているプロシージャを実行する際、コンピュータが構成されて実行される。本発明のシステムは、コンピュータープログラムにて構成されたコンピュータ読み取り可能な記憶媒体として実施されると考えることもできる。そのように構成された記憶媒体により、コンピューターシステムは、ここに記載した関数を実行する特定の及び所定の方法にて作動する。

本発明のいくつかの実施形態を説明した。しかし、当然のことながら、本発明の精神および範囲を逸脱することなく多様な改変を実施し得る。例えば、上述したいくつかのステップの順序は自由であるので、上記と異なる順序にて実行され得る。

当然のことながら、上記記載は、本発明を説明することを意図したものであって本発明の範囲を限定することを意図するものではない。本発明は、添付される特許請求の範囲によって定義される。例えば、上述したいくつかの関数ステップは、全体のプロセスに実質的な影響を与えることなく異なる順序にて実行され得る。他の態様は以下の特許請求の範囲に含まれる。

Claims (20)

1. データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様であって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義するルール仕様、を受け取るステップ；
   前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式を生成するステップであって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスを提供することを含むステップ；および、
   前記生成された変換式を用いて少なくとも一つのデータフローを変換するステップであって、ランタイムにて前記グラフベース計算における前記データ処理成分の実行をトレースすること、前記設定されたログ特性に準じて前記トレースされた実行に基づいてログ情報を生成すること、および、前記生成されたログ情報を格納または出力すること、を含むステップ、
   を含む方法。
2. 請求項１に記載の方法において、
   前記ログの特性を設定することは、ログ情報が生成される少なくとも一つのイベントを選択することを含む、方法。
3. 請求項２に記載の方法において、
   前記少なくとも一つのイベントは、前記受け取られるルール仕様に関連付けられたルールに準じて前記データフローに係るレコードを変換することに関連付けられる、方法。
4. 請求項３に記載の方法において、
   前記少なくとも一つのイベントは、変換されるレコードに係るエラーを特定することを含む、方法。
5. 請求項３に記載の方法において、
   前記少なくとも一つのイベントは、与えられたレコードについてのルールケースの条件を満たすことを含む、方法。
6. 請求項５に記載の方法において、
   与えられたレコードについてのルールケースの条件を満たすことは、前記与えられたレコードに係る値に基づく論理式を満たすことを含む、方法。
7. 請求項５に記載の方法において、
   与えられたレコードについてのルールケースの条件を満たすことは、前記レコードに係る値と前記ルールケースに関連付けられた値とを比較することを含む、方法。
8. 請求項１に記載の方法において、
   ログ情報を生成することは：
   前記受け取られたルール仕様によって定義される前記ルールを含むルールセットの詳細を各々含む一または複数の凡例ログメッセージを生成すること、および、
   複数のトレースログメッセージであって、各トレースログメッセージは凡例レコードと関連付けられるとともに、前記受け取られたルール仕様に関連付けられたルールに準じて前記データフローに係るレコードを変換することに関連付けられた少なくとも一つのイベントを記述するトレースログメッセージ、を生成すること、
   を含む、方法。
9. 請求項８に記載の方法において、
   前記イベントを記述するトレースログメッセージは、前記凡例レコードに係るインデックスを用いてデータ処理成分の少なくとも一つの入力または出力を記述する、方法。
10. 請求項８に記載の方法において、
    一または複数の凡例メッセージを生成することは、グラフベース計算の一回の実行ごとに一つの凡例メッセージを生成することを含む、方法。
11. 請求項１に記載の方法において、
    前記生成された変換式を用いる前記データ処理成分は、前記受け取られたルール仕様に関連付けられた第１のルールに準じて前記データフローに係る入力レコードを変換する、方法。
12. 請求項１１に記載の方法において、
    前記トレースされた実行に基づいてログ情報を生成することは、前記規定された判断基準が満たされる前記第１のルールの各ルールケースに対してログメッセージを生成することを含む、方法。
13. 請求項１１に記載の方法において、
    前記トレースされた実行に基づいてログ情報を生成することは、前記生成された変換式を用いて前記データ処理成分によって生成された変換されたレコードにおける各値に対してログメッセージを生成することを含む、方法。
14. 請求項１１に記載の方法において、
    前記生成されたログ情報を格納または出力することは、前記データ処理成分の一または複数のログポートからログメッセージを出力することを含む、方法。
15. 請求項１４に記載の方法において、
    前記生成されたログ情報を格納または出力することは、データ処理成分における前記ログポートからのログメッセージに係るデータフローを受け取ること、および、前記ログメッセージの少なくとも一部から派生するログ情報を格納すること、をさらに含む、方法。
16. 請求項１５に記載の方法であって、
    ログメッセージに係る前記受け取ったデータフローをフィルタリングすること、および、前記ログメッセージのサブセットから派生するログ情報を格納すること、をさらに含む、方法。
17. 請求項１４に記載の方法において、
    前記生成されたログ情報を格納または出力することは：
    前記規定された判断基準が満たされるトリガされたルールケースを指し示すデータ処理成分における前記ログポートからのログメッセージに係るデータフローを受け取ること、
    前記入力レコードの全てによってトリガされる前記ルール仕様によって定義される前記ルールの各々に係る各ルールケースに対する少なくとも一つのログメッセージを提供する入力レコードの縮小セットを決定するために前記ログメッセージを検査すること、および、
    前記入力レコードの縮小セットを格納すること、
    をさらに含む、方法。
18. データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様を格納する格納システムであって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義する、格納システム；
    前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式を生成するように構成された生成器であって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスを提供する生成器；および、
    前記生成された変換式を用いて少なくとも一つのデータフローを変換するように構成されたグラフベース計算システムであって、ランタイムにて前記グラフベース計算における前記データ処理成分の実行をトレースすること、前記設定されたログ特性に準じて前記トレースされた実行に基づいてログ情報を生成すること、および、前記生成されたログ情報を格納または出力すること、を含むグラフベース計算システム、
    を含むコンピュータシステム。
19. コンピュータ読み取り可能な媒体に格納されたコンピュータプログラムであって、該コンピュータプログラムは：
    データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様であって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義するルール仕様、の受け取り；
    前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式の生成であって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスの提供を含む、該変換式の生成；および、
    前記生成された変換式を用いた少なくとも一つのデータフローの変換であって、ランタイムにおける前記グラフベース計算における前記データ処理成分の実行のトレース、前記設定されたログ特性に準じて前記トレースされた実行に基づくログ情報の生成、および、前記生成されたログ情報の格納または出力、を含む該データフローの変換、
    をコンピュータシステムに実行させる命令を含むコンピュータプログラム。
20. データフローを表すリンク要素によって接続されるデータ処理成分を有するグラフベース計算についての少なくとも一つのルール仕様を受け取る手段であって、該ルール仕様は入力データに応じた一または複数の出力値を定めるための判断基準を規定する一または複数のルールケースと各々関連付けられたルールを定義する、該ルール仕様を受け取る手段；
    前記受け取られたルール仕様に基づくグラフベース計算における少なくとも一つのデータ処理成分に対する変換式を生成する手段であって、前記生成された変換式に関連付けられたログの特性を設定するインターフェイスを提供することを含む手段；および、
    前記生成された変換式を用いて少なくとも一つのデータフローを変換する手段であって、ランタイムにて前記グラフベース計算における前記データ処理成分の実行をトレースすること、前記設定されたログ特性に準じて前記トレースされた実行に基づいてログ情報を生成すること、および、前記生成されたログ情報を格納または出力すること、を含む手段、
    を含むコンピュータシステム。

Images