HK1187704A - Method and system for managing rules applied to data in a data storage system - Google Patents

Description

Method and system for managing rules applied to data in a data storage system

The present application is a divisional application of the invention patent application having an application date of 2008/3/27, application number of 200880011618.0, entitled "editing and compiling business rules".

Technical Field

The present invention relates to a method and system for managing rules applied to data in a data storage system.

Background

Complex computations are often represented as data flowing through a directed graph, with the components of the computation being associated with vertices (vertices) of the graph and data flowing between components corresponding to links (arcs), edges (edges)) of the graph. A system for implementing such graph-based computations is described in U.S. Pat. No. 5,966,072executing computations represented As Graphs. In some cases, the computations associated with the vertices are described in a human-readable form called a "business rule".

Disclosure of Invention

According to an aspect of the present invention, there is provided a method for managing one or more rules applied to data in a data storage system, the method comprising: receiving data from the data storage system at an input device or port; and processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying portions of the rule specification at an editor interface; applying the rule to one or more records of the received data to obtain result information; and displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

According to another aspect of the present invention, there is provided software stored on a computer readable medium for managing one or more rules applied to data in a data storage system, the software including instructions for causing a computer system to perform the steps of: receiving data from the data storage system at an input device or port; and processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying portions of the rule specification at an editor interface; applying the rule to one or more records of the received data to obtain result information; and displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

According to another aspect of the present invention, there is provided a computer system for managing one or more rules applied to data in a data storage system, the computer system comprising: an input device or port configured to receive data from the data storage system; and at least one processor configured to process at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying portions of the rule specification at an editor interface; applying the rule to one or more records of the received data to obtain result information; and displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

According to another aspect of the present invention, there is provided a computer system for managing one or more rules applied to data in a data storage system, the computer system comprising: means for receiving data from the data storage system; and means for processing at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying portions of the rule specification at an editor interface; applying the rule to one or more records of the received data to obtain result information; and displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

According to another aspect of the present invention, there is provided a method for managing one or more rules applied to data in a data storage system, the method comprising: receiving data from the data storage system at an input device or port, the data comprising an input value and a reference output value corresponding to the input value; and processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying information defining at least a portion of the rule specification at an editor interface; applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and providing an indication of the comparison of the generated output value with the reference output value in the received data.

According to another aspect of the present invention, there is provided software stored on a computer readable medium for managing one or more rules applied to data in a data storage system, the software including instructions for causing a computer system to perform the steps of: receiving data from the data storage system at an input device or port, the data comprising an input value and a reference output value corresponding to the input value; and processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying information defining at least a portion of the rule specification at an editor interface; applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and providing an indication of the comparison of the generated output value with the reference output value in the received data.

According to another aspect of the present invention, there is provided a computer system for managing one or more rules applied to data in a data storage system, the computer system comprising: an input device or port configured to receive data from the data storage system, the data comprising an input value and a reference output value corresponding to the input value; and at least one processor configured to process at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying information defining at least a portion of the rule specification at an editor interface; applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and providing an indication of the comparison of the generated output value with the reference output value in the received data.

According to another aspect of the present invention, there is provided a computer system for managing one or more rules applied to data in a data storage system, the computer system comprising: means for receiving data from the data storage system, the data comprising an input value and a reference output value corresponding to the input value; and means for processing at least a portion of the received data according to a rule specified by at least a portion of the rule specification, the processing comprising: displaying information defining at least a portion of the rule specification at an editor interface; applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and providing an indication of the comparison of the generated output value with the reference output value in the received data.

In general, in one aspect, a component in a graph-based computation having data processing components connected by link elements representing data flows is updated by: the method includes receiving a rule specification, generating a transformation for transforming data based on the rule specification, associating the transformation with a component in the graph-based computation, and updating the transformation associated with the component in the graph-based computation according to the new or edited rule specification in response to determining that a new rule specification has been received or an existing rule specification has been edited.

Implementations may include one or more of the following features.

A rule specification is received, including a row of a table that receives the rule specification from a user, the row defining a rule case and containing a relationship for each of a set of one or more potential inputs. Receiving the rule specification further includes receiving a second row of the table from the user, the second row defining a second rule case and containing a second relationship for each of a second set of one or more potential inputs. The relationship includes one or more of: have a value equal to a threshold, have a value above a threshold, have a value below a threshold, have a value belonging to a set of values, have a value matching a pattern (pattern), have a relationship to a value of another input, have a relationship to a value of an output of another rule specification, or have a relationship to a value in memory. The row also contains an output comprising one or more of the following or a combination thereof: an input value, a predetermined value, or a value calculated from one or more input values. A table is received that includes a set of test columns, each test column containing values of one or more potential inputs, and for each test column, a row of the rule specification is identified that will generate an output of the given input values for the test column, and the identification of the row identified by each test column is output to a user. A table is generated that includes a result row for each test column, each result row indicating an output that the input value for a given test column is to generate. Generating the table includes, in each result row, indicating whether to change from an output indicated as a previous version of the rule specification to an output to be generated. In response to a user interaction with a result line, an indication is made as to which rule case in the rule specification is to generate an output in the result line.

A table is generated that includes an evaluation row corresponding to each row of the rule specification, in each evaluation row of the table, for each potential input, indicating whether a value in a first test row corresponding to the potential input satisfies a relationship of the potential input, and in the evaluation row corresponding to the row of the rule specification where a given input value of the first test row will generate an output, indicating that the output will be generated. The evaluation row has an order corresponding to the order of the rows of the rule specification, and wherein the evaluation row indicating the output corresponds to the first row of the rule specification that satisfies each relationship of the potential inputs. Indicating the output to be generated in each evaluation row corresponding to the row of the rule specification that satisfies each relationship of the potential inputs. A table is generated that includes evaluation rows corresponding to each row of the rule specification, in each evaluation row, an input indicating how many test columns have a relationship in the corresponding row that satisfies the rule specification. Each test column also contains an expected output value, and each result row indicates whether the output that will be generated for the input value of a given corresponding test column matches the expected output in the test column. Determining that a rule set including the first rule specification and the second rule specification is valid in response to determining, for each test column, at least one row of the second rule specification will generate an output for the input value for the given test column.

A table is generated that includes a result row for each test column, each result row indicating each output generated by a row in one of the rule specifications for the input value of a given test column. For an output generated for an input value of a given first test column, a graphical display of the interrelationship between the rule-canonical input and output is generated that will result in the generation of the output. The table of received test columns includes: the method includes receiving a set of input values from a user, matching the set of input values to potential input values of a rule specification, and storing the set of input values in a column of a table. The receiving of the set of input values is in response to displaying the identification of potential input values. The set of rule specifications is determined to be valid in response to determining that each rule specification in the set of rule specifications will generate at least one output. In response to determining that the rule specification is not valid, a source of the rule specification is notified that the rule specification is not valid.

Updating the transformation includes: confirming that the rule specification is valid, generating a new transformation based on the new or edited rule specification, disassociating the first transformation from the component, and associating the new transformation with the component. Updating the transformation includes: confirm that the rule specification is valid, wait for a graphics-based computation to be performed, when a component is activated, generate a new transformation based on the new or edited rule specification, and associate the new transformation with the component. Generating the transformation includes converting each of the plurality of rule cases in the rule specification to a logical expression to form a plurality of logical expressions, and compiling the plurality of logical expressions into computer-executable code. Compiling the plurality of logical expressions includes one or more of: combine expressions, optimize individual expressions, and optimize groups of expressions. Compiling the plurality of logical expressions includes associating the expressions with components suitable for use in graph-based computing.

In general, in one aspect, the calculation is tested by: receiving a rule specification comprising a set of rule cases, each rule case comprising a relationship of a potential input and a corresponding output; a set of test cases is received, each test case containing values of one or more potential inputs, and for each test case, one of the rule cases is identified that will generate an output for the input value of the given test case.

Implementations may include one or more of the following features.

In response to identifying a rule case for which an output is to be generated for each test case, an indication is stored or output that the rule specification is valid. In response to identifying a rule case that will generate an output for each test case, an indication that an output will be generated is stored or output. Receiving the set of test cases includes receiving a table of a set of test columns, each test column containing values for one or more potential inputs of a corresponding one of the test cases. For each test case and for an identified rule case for that test case, identifying what output will be generated by the identified rule case. For each test case and for an identified rule case for that test case, one or more input values in the test case that are output by the identified rule case are identified. Also included is for each test case, indicating for each rule case which relationships of the rule case are satisfied and not satisfied by the values in the test case.

The rule cases have an order, and the identified rule case for each test case corresponds to the first rule case in the order that satisfies each relationship of the potential inputs. Receiving a second rule specification comprising a second set of rule cases, the one or more rule cases comprising a relationship of one or more outputs of the first rule specification to corresponding inputs of the second rule specification. For each test case, one of the rule cases of the second rule specification that identifies an output to the given test case's input values and the identified rule case of the first rule specification will generate an output. For each test case, a graphical display of the inputs and the interrelationships between the outputs of the first and second rule specifications that will result in the generation of the outputs of the second rule specification is generated. For each test case, each rule case that will generate an output for the input value for the given test case is indicated. For each rule case, a value is indicated that indicates how many test cases have potential inputs that will cause the rule case to generate an output.

Each test case includes an output. It is determined whether the output generated by the identified rule case matches the output included in the test case, and the results of the determination are stored or exchanged. A table is generated that includes a result row for each test case, each result row indicating an output to be generated by the rule specification for the input value of the given test case. In each result row, it is indicated whether to change from an output indicated as a previous version of the rule specification to an output to be generated. In response to a user interaction with the result row, an identified rule case that will generate an output is indicated in the result row. For one of the test cases, a table is generated that includes an evaluation row corresponding to each rule case of the rule specification, in each evaluation row of the table, for each potential input, a relationship that indicates whether a value of the potential input in the test case satisfies the potential input in the rule case corresponding to the evaluation row. In an evaluation row of the table of identified rule cases corresponding to a test case, an output to be generated by the rule case is indicated.

The evaluation rows have an order corresponding to an order of rule cases within the rule specification, and wherein the evaluation row indicating the output corresponds to a first rule case that is satisfied by each relationship of the potential inputs. An output to be generated by the test case in each evaluation row that indicates the rule case satisfied by each relationship corresponding to the potential input. A second rule specification is received that includes a second set of rule cases, indicating outputs to be generated by each rule specification. A table is generated that includes a result row for each test case, each result row indicating each output generated by the rule specification for the input value of a given test case. In response to a user interaction with the output indicated in the results row, indicating which rule case will generate the indicated output. The indicated rule case is from a second rule specification, and indicating the indicated rule case includes: an output indicating a rule case from the first rule specification and a rule case that satisfies an input relationship of the indicated rule case. Receiving the set of test cases includes: the method includes receiving a set of input values from a user, matching the set of input values to potential input values of a rule specification, and storing the set of input values in a column of a table. The receiving of the set of input values is in response to displaying the identification of potential input values.

In general, in one aspect, a component in a graph-based computation having data processing components connected by linking elements representing data flows, the component including a transformation that transforms data based on a rule specification, the rule specification including a set of rule cases, each rule case including a relationship of potential inputs and corresponding outputs, and testing is performed by performing the graph-based computation on the set of input data in an execution environment, registering the input data and outputs resulting from the computation on each item of data in the set of input data, and identifying, for each item of data in the registered set of input data, one of the rule cases that will generate the registered output for a given input value in the item in a testing environment separate from the execution environment.

The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.

Drawings

FIG. 1A is an example of a transformation.

Fig. 1B is an example of a graph.

FIG. 1C is a block diagram of the generation and updating of transformations.

Fig. 2A is an example of a rule entry (entry) based on an extended page (spaadsheet).

Fig. 2B is an example of various rules.

FIG. 3 is a test data set.

Fig. 4A is the test results.

Fig. 4B and 4C are details of the test results.

Fig. 5 and 7 are flowcharts.

Fig. 6 is an example of transform codes.

Detailed Description

Business rules may be represented as a set of criteria that may be used, for example, to convert data from one format to another, make determinations about data, or generate new data based on a set of input data. For example, in FIG. 1A, a record 102 in the flight reservation system indicates the passenger's name 104, how many miles the passenger has flown this year 106, the passenger's ticket's cabin class 108, and the row 110 in which his seats are located. The business rules indicate that such passengers should be brought into the boarding group 1. Often the business rules are easily understandable to humans, i.e., "first class passengers are in group 1", but may need to be converted into something that the computer can understand before using the business rules to manipulate the data. To implement business rules in a graph-based computing environment, a transformation 112 is generated, the transformation 112 receiving input records (such as record 102) from one or more data sources (e.g., input data set 100), and inserting an output record (e.g., record 114) into an output data set 120 indicating the passenger name 104 and which group it was in 118. The input and output data sets may also be referred to as data streams. The transformation may then be implemented in a graph-based computation having data processing components connected by links representing elements of data flow. For example, the simple computational graph 130 of FIG. 1B takes as input two data sets 132, 134 (e.g., frequent flight data and flight reservation data), formats the data in each set in separate formatting components 136, 138 so that they can be used together, and combines them in a join (join) component 140 to produce an output data set 142. The transformation itself may be a graph-based computation, such as the computation in graph 130, or may be implemented within a component of a graph, such as the various components 136, 138, and 140 included in graph 130.

To simplify the creation of transformations for non-technical users, such users are provided with tools to enter a set of business rules, called a rule set, in a format familiar to the user, that tells the computer system what the user wants the transformation to do. A rule set is a set of rules that produce a single transformation. The rule may consist of one or more cases where different values are calculated for the output of the rule depending on the input. A rule may also include other rules. Other rules in the rule set may produce additional or alternative output values. The set of rules may contain other rule sets that we call the "included" rule set.

A general model of a transformation generation system is shown in fig. 1C. The generator 150 receives as input the rule set 152 from the editor 154 and generates a transformation 156. Depending on the architecture of the system and the purpose of the transformation, as well as the business rules, the generated transformation 156 may be provided to the graph-based computing system 158 as a component used in the graph or in the entire graph itself. The generator 150 may be, for example, an assembler, a custom built program, or another graph-based computation configured using standard tools to receive the rule set 152 and the output transformation 156.

The generator 150 may also update the transformation 156 as the rule set 152 is edited. When editing the rule set 152, the editor 154 may provide the entire rule set to the editor or it may only provide new or modified rules or cases of rules 152 a. The generator 150 may generate an entire new transformation to replace the original transformation 156, or it may provide a component 156a containing the transformation, depending on the performance and needs of the system using the transformation.

As shown in FIG. 2A, in some examples, an (enter) rule may be added in an extended page format. The trigger columns (trigger columns) 202, 204, 206, 208 in the extended page 200 correspond to available data values, while the rows 210a-h correspond to rule cases, i.e., sets of criteria related to the available data values. If the data value recorded for each trigger column in which the rule case has criteria satisfies the trigger criteria, then the rule case 210n is applied to the given record (e.g., 102 in FIG. 1A). If the rule case 210n is applied, an output is generated based on one or more output columns 212. A rule case in which all input relationships of the rule case are satisfied may be referred to as "triggered. Each output column 212 corresponds to a potential output variable for which the value in the corresponding cell (cell) of the applicable row 210n determines an output (if any). As will be discussed below, a cell may contain a value assigned to a variable or it may contain a value that must be evaluated to generate an output value. Although only one is shown in fig. 2A, there may be more than one output column.

There may be several different types of trigger columns, including: columns corresponding to variables, columns that contain expressions but are treated as variables once operated on, and columns that contain only expressions. Other column types include columns that contain only data and columns that specify expressions to evaluate each row, based on the columns containing only data. Columns containing only expressions are simpler than those corresponding to or treated as variables. Such columns may include one of the following:

● expression. The condition is considered true if the evaluation of the expression evaluates to a non-zero, non-null value.

● the keyword "any", or a string (string). This condition is always true. Each empty cell in the trigger column is equivalent to a cell that explicitly contains the key "any".

● keyword "other". If none of the cells above the cell containing "others" is true, then the condition is true and all cells to the left in the row are equivalent.

● the keyword is "same". If the above element is true, then the condition is true.

The columns corresponding to the variables may have two types of cells. One type of cell is an expression cell. Those cells behave exactly as the cells in the column containing only expressions described above. However, the key "this" may be used in expressions to refer to column variables. Another type of cell is a comparison value. An exemplary grammar (grammar) for comparing values is as follows:

wherein "^*"means that the term is repeated zero or more times.

Any suitable programming language or syntax (syntax) may be used. Examples may include C, Java, DML, or Prolog. The column variable is compared to the comparison value according to an operator, function, or dependency (membership) expression. In the example of fig. 2A, the first two columns 202 and 204 contain compare values with a "> =" operator, such that the criteria are met if the value of the column is greater than or equal to the corresponding number. If no operator is present, as in the "bin level of seat" column, "then" equal "is assumed. The constants may be any legal constant in whatever programming language or syntax is used in the underlying system. Other constants and variables are business terms defined within the rule set, as described below. An expression is any legal expression in the language used that returns a compatible data type to be compared to the column variables. In some examples, expressions inside the comparison values are included in parentheses to avoid confusion. For the simple _ function, the function is applied to the column variable, so the "is _ null" key is the same as the expression "is _ null (this)".

In the example of FIG. 2A, the first row 210a has only one column 202, which indicates that if the total number of miles that the traveler frequently flies is greater than 1,000,000, then the rule case applies regardless of what value any other column may have. In this case, the "boarding group" outputs the variable that the user was placed in group 1. Likewise, the second rule case 210b indicates that any passenger in the first class is in group 1. In some examples, the rules are evaluated sequentially, so travelers and first class tickets that have exceeded 1,000,000 miles will be in group 1, but will only trigger the first rule case 210 a. Once a rule case is triggered, there is no need to evaluate other rule cases in the rule.

The next rule case 210c is based on the two input values 202 and 204, if the criteria defined by both total frequent flyer miles and current year miles are met, then the passenger is in group 2. In the fourth rule case 210d, any business class customers are also in group 2. The remaining rule cases 210e-h contain criteria relating to other rule cases, i.e., "other" and "same". As described above, "other" indicates that any of the criteria of the column in the row above it is not satisfied and that it has the same criteria to the left (i.e., rules 210b and 210 d), "same" indicates that the rule case applies whether the above rule case to which it is applied is with respect to that column. Thus, the fifth rule case 210e is applied to any record that does not match any of the criteria in the first two columns 202 or 204 (because it may be handled by rule cases 210a or 210 c), does not have a "first" or "business" in the "bin level of seat" column (the keyword "other" in column 206), and has a value 208 of "row of seats" that is less than or equal to 10. Each of the remaining rule cases 210f-h applies to the following records: it also does not match any higher rule case with a value in column 202 or 204, does not have a value of "first" or "business" in the "slot level of seat" column, and has an appropriate "row of seats".

The rule cases 210a-h in the example of FIG. 2A may also be represented as individual simple rules, each in its own extended page, as shown in FIG. 2B. Rules 220a-d correspond to lines 210a-d of FIG. 2A, respectively, while rule 220e has four rule cases corresponding to lines 210e-h together. The user may create these individual rules separately rather than generating the entire table shown in fig. 2A. Each rule contains a value for each trigger column and a value for each output column (which may be empty, i.e., effectively set to "arbitrary"). When multiple rules generate the same output, the rules are ordered and considered in sequence until a rule case in a rule triggers at the input and generates an output. If no rule condition is in the rule trigger, the next rule that produces the same output is processed. If no situation in any rule triggers an output, a default value is used.

In some examples, the editor interface may graphically identify a cell (cell) containing an expression. This will help the user understand the difference between the expression that will evaluate itself as true or false and the expression that returns the value compared to the column variable. When the user is typing (type), he can indicate the unit to be specified as an expression unit by, for example, typing an asterisk at the beginning.

In some examples, the values and expressions are DML expressions. A full DML language may be supported. Special keys and business names for fields and values are encoded as strings of preprocessed output of DML expressions. Note that an expression may not only use a logical (business) name for a variable, but may also refer to an actual physical name, although this may interfere with testing.

For a column corresponding to an output variable, a cell may contain one of:

● value. The value will be assigned to the output variable

● expression. The value of the expression will be assigned to the output variable. If the expression evaluates to NULL, the field takes the NULL value unless the output field is not nullable (non-nullable). In this case, an error is generated.

● keyword "null". If the output field is nullable, a NULL is assigned to the field. Otherwise, an error is generated.

● empty string. If the output field has a default value, the default value is assigned. Otherwise, the cell is treated as it contains the key "null".

● the keyword is "same". The output field is assigned the same value calculated in the unit above.

If possible, an error is reported as soon as possible (i.e., a "null" is placed in the output column of the non-nullable field). However, some errors may not be reported until test time or runtime.

In addition to expressions, the user may be allowed to append comments (comments) to any element in the rule. These annotations may be displayed as annotations attached to cells in a common spreadsheet program, such as Microsoft Excel.

In some examples, the rules of the editor interface may be configured such that the content that the user may enter is more severely limited than the technical requirements of the interface requirements. For example, the interface may be configured to allow only certain types of variables or certain types of expressions in order to provide a simpler, further restricted user interface. The interface may also be configured to restrict which elements of the rules may be changed based on the role or user ID of the user. Such restrictions may be applied to the set of rules by an administrator.

Whether created in terms of rows of a table or in terms of individual rules, each rule has a particular set of attributes. The rule sets may determine the attributes of the rules they include. These attributes may include name, rule type, description and comment fields, list of output variables, list of input variables, list of topics (arguments), list of trigger columns, modification history, test data set, and error handling behavior. The name is self-explanatory and is used to list the rules in a rule set. The rule type may be, for example, "normal" or "functional". In some examples, a rule type is a property (property) of a rule set. The list of output variables is the set of variables produced by the rule or values assigned by the rule. This may be inherited from a rule set (inherite), and there may be one or more outputs. The list of input variables identifies all variables that the rule needs to evaluate for records, including those at the top of the column and those used inside the expression (e.g., "recent frequent flyers miles" as used in rule 210c in FIG. 2A, used in the expression, but without its own column).

In some examples, multiple rule cases may be used to generate multiple output records for a single input record. Such a set of rules is called a normalized (normaize) set of rules. In the normalized rule set, one of the outputs is identified as a critical output. When evaluating a rule that calculates this critical output, the rule case triggered by the input and the output generated are recorded (note). The rules are then evaluated again, disabling the previously triggered rule cases to see if any other rule cases trigger and produce an output. This is repeated until no rule case triggers. Each output may be stored as a separate output record. In some examples, rule cases are grouped such that if one rule case triggers, other rule cases within its group are also prohibited when the next iteration (iteration) on the same input.

In some examples, the rules may be evaluated in a reverse manner to that described above by performing an and operation on the columns by the rule case in the row and performing an or operation on the columns. That is, the rule produces an output only if each row is triggered (AND 'ed over the rows), but only a single cell needs to be true for each row to trigger (OR' ed over the columns).

Only a list of topics is presented for the functional rules. Which identifies the name and type of parameter entered into the rule and may be a characteristic of the rule set. The list of trigger columns identifies which column may trigger the application of the rule. In addition to the input variables shown only in the examples of fig. 2A and 2B, the trigger column may correspond to a parameter, a lookup variable, an output variable from an earlier rule, an output variable of an included (inclusive) rule set, a parameter to a rule set, or an expression. They may also include input variables from functional rules, i.e., from topics.

The modification history includes the name, date, and comments of the modification. In some examples, there is one modification history for each rule, and one modification history for the test set (discussed below).

Error handling determines how the transformation created from the rule set handles errors that occur when evaluating the rules. To handle errors in the trigger expression, the option (option) is either allow error, where transformation reject (reject) results in erroneous records, or ignore error, which is equivalent to assuming the trigger expression is false and proceeding to the next rule. For output expressions, errors can be handled by: allow the error and reject the record, ignore the error and set the output to NULL, or ignore the row in the rule and proceed to the next row.

Test data

To assist in evaluating whether the rule set is working as expected, a test data set may be included. The test data set of a rule set is a set of prototype (formal) inputs and expected outputs, for example, as shown in FIG. 3. The test data set consists of an extended page like table 400, table 400 having one row 402a-e for each field referenced by a rule and one row 404 for each output (in this example, there is only one). The user may then create the test cases and desired results represented in columns 406a-r of test data. The test data may be saved using rules. The example of fig. 3 contains possible inputs 402A-e and an expected output 404 that is a rule with respect to fig. 2A-2B. For various combinations of frequent flyer miles and seating arrangements 406, it shows what boarding groups 404 should be calculated (there are more combinations than possible inputs shown). In some examples, the test input includes a value or each variable in each lookup. The test input may also include the value of each parameter and the value used as "now" for any rule as a reference to the current date or time. To test individual (units), the test input may include the values of any included rule set, such that it is not necessary to evaluate the included rule set when testing the included rule set.

In some examples, columns 402, 404 in the individual test table are determined by software based on user actions. When a user edits a rule, the details of the rule are parsed and a deterministic (definitive) list of referenced input variables is generated. The list includes variables used in the column header and variables embedded in the expression. A column is generated for each variable, each technology variable embedded in the expression, and each find expression. In some examples, the user creates the test table 400 by providing test cases one at a time (one at a time) at a time. For example, the user may specify that passengers with a total of 2,000,000 frequent flyers, 200,000 miles per year, 150,000 miles per year, and first class tickets in row 5 should be located at the boarding group 1. The software determines which of rows 402a-e and row 404 corresponds to these inputs and outputs and creates a corresponding column 406a in table 400. This may be repeated as many test cases the user wishes to enter. In some cases, the software may provide an interface to the user that presents each potential input or output variable so that the user can simply enter or select values without knowing what variables require them.

The user may then fill in the test case and perform the test. In this regard, the software evaluates the rules of each row of the test data set table and calculates a result value. If the resulting value matches the desired value (the value entered by the user in the column corresponding to the output variable), an indication is given that the rule is valid, e.g., the output element may be shown in green. If the resulting value does not match the expected value, an indication is made to that, e.g., the cell may be shown in red and the expected and actual values displayed. The user can then update the test case or adjust (fix) the rule. Of course other user interface mechanisms may be used. For example, rather than comparing the calculated output to the input expected output, the testing process may simply display what the calculated value is and let the user evaluate whether it is correct.

In some examples, the user has actual data that it can use to generate the test data. An end user of a business rule may provide such data to a developer for testing. To deal with situations where the user does not have actual data to test, the software may provide a simple form of data entry for entering test data one record at a time. The user may type the value of each field in the input data set and these records will be added to the identified test data set.

In some examples, the rules are validated as they are entered (valid), and rules that do not produce the desired output may be immediately identified on the interface, similar to a word processor may mark misspelled words as they are entered.

In some examples, after a test is performed, the user may select any row in the test data set table (test case). If a row is selected, the corresponding row in the rule table that produces the output for that test case will be displayed. In addition to expressions, the user may also append comments to any element in the test data table.

More about rule sets

As described above, the transformation is generated according to a set of rules. The rule set may have the following properties:

name, description, and annotationThis helps to identify the rule set. Depending on the back-end implementation, the rule set may include an identification of its location within the system. In some examples, the position of the rule set is a path (path) in the item (project). In some examples, the rule sets may be organized in a relational database and located by name. The modification history includes a modification name, date, and check-in comments.

Transformation typeIt determines what type of transformation is generated from the rule set. Possible values include reformatting, join (join), accumulate (rolup), and filter (filter), as discussed below.

Input data collectionIt provides a list of fields and named constants (constants) for editing. In some examples, the record format of one of the input data sets will be assumed by default when generating the transformation. There may be multiple sets of inputs, allowing the rule sets to generate transformations for different environments. This also allows multiple sets of logic to be physically mapped, i.e., different sets of physical names. In some examples, there is an input mapping table with one or more data sets. In some examples, the join component can have multiple input mapping tables, and each input mapping table can have multiple dataAnd (4) collecting.

Outputting a data setIt provides a list of output field names. By default, the record format of one of the output data sets will be assumed when the transformation is generated. The output data set may be the same as the input data set. The included rule set will not have an output data set. In some examples, as with the input data set, there are multiple output sets, allowing the rule set to generate transformations for different environments.

List of included rule setsOne rule set may use output fields computed by another rule set (explicitly listed output fields, not fields of the output record format). The output variables in the included (included) rule set may be used as variables in the included (included) rule set based on a mapping table of the included rule set that defines the set of output variables from the included rule set that are visible in the included rule set.

List of included transform filesOne or more files that may optionally include transformations that specify the transformations to be used when processing the rule set.

A series of mapping tables listing variables and constants-associating the tables with each other using input and output data sets (interwin). It makes the list of variables known to the editor and proves the mapping between the business name and the technical name (DML). Each variable has a business name, a technical name (DML expression), and a basic type (string, number, date, or datetime). Associated with each variable is a list of optional constants that demonstrate a mapping between business names and DML constant values. The variable tables are described in more detail below.

Reference to external test data filesThe test file is used for testing rules, similar to the embedded test data set discussed above.

Non-rejection flagIf the flag is set, the transformation produced by the rule set will not reject the recording (throw the error away). The flag may be used so that the rule that throws the error is ignored as if the rule had never been triggered.

Scheduling tablesIt lists one or more schedules (deployments) indicating which rules are to be included (indirectly) in each compilation (build). The schedule table is described in detail later.

Selectable keywords(key) -it lets the user specify the business name of the special input field that represents the keyword for the combined type and accumulated type rule set. In some examples, the key is actually implemented as an entry in a table of input variables, with the type of key.

Optional list for finding filesIt provides a complete table of business names, key information and input variables and constants, one table per lookup file. Lookup file support is described in more detail below.

Tables of parametersIt lists variables whose values come from the environment or from the parameter set at runtime.

Tables of variables and constants

As described above, each rule set has an associated set of tables of variables and constants. In some examples, the tables are private (private) to the rule sets and cannot be shared between the rule sets. The table of variables and constants is used for several purposes:

1. a list of the input variables used as a rule set and the determinations of the output variables resulting from the rule set calculations.

2. As a list of business names available during editing. When compiled, the system will present a suggested list of business names for variables and constants. The list is from a table of variables and constants.

3. As a mapping table for translating (translate) business names into technology names. The rules will include the business name (in text, as inside the DML preprocessor directive(s) described later). When creating a transformation, the business name is replaced by a technical name or DML expression. Some tables, such as input variables and output variables, may have multiple data sets, each with a different technical name for the business name. The translation used is dependent on scheduling (detailed later)

The rule set may have several different tables. These tables are similar in many respects, but with the following subtle differences. These tables include:

1. a table of variables and constants is input. For a rule set of transform type, the table contains the fields in the input record format that will be referenced in the rule. Not every field in the record format needs to be listed, but they are usually listed. For a rule set of join types, there will be multiple input tables, each representing one input data set of join operations.

2. A table of input variables and constants for all included rule sets. When using included rule sets, each included rule set has its own table of input variables and constants. When a transformation is compiled, the input variables used by the included rule set must be mapped to the actual inputs in the context of the included rule set. Thus, the list is promoted (remote) to include a set of rules. If multiple included rule sets are included, each input variable table is promoted. (if the included rule set itself includes a rule set, then the second level variable is not promoted). The input variables and constants promoted from the included rule set are not available for the included rule set. The inclusion of only the table makes it possible to establish a mapping between the inputs of the included rule set and the inputs of the included rule set. See below for more details.

3. A table of output variables and constants for all included rule sets. When a rule set has been included, the output of those included rule sets becomes the input that includes the rule set. The table lists all of those variables. Initially populating (post) directly from a table of output variables and constants of all included rule sets; however, business names may be changed to avoid name conflicts. For this table, the technology name is really the business name inside the (really) rule set that is included.

4. A table of variables and constants is output. The table contains fields in the output record format to be computed by the rule set corresponding to the rule set for the transform type. Non-computed output variables may also be included and these output variables will be ignored by the rule set. (the generated transformation has a wildcard rule to copy the input to the output.

The output variable may also be used as an intermediate variable, meaning that the value of the output generated from one rule may be referenced in subsequent rules. Sometimes, the output is used only in this way; the output is never directly included in the output record from the transform.

5. Table of parameters. A rule may include a reference to a parameter. The (resolve) parameters are resolved at runtime in the context of a set of graphics parameters. Like other variables, parameters in a rule set have business names, technology names (e.g., $ RUNDATE), and types.

6. A table of variable mappings for each lookup file. This is similar to the input table, but maps to fields in the record format of the lookup file.

An unshared set of rules, which are designed to produce transformations, are typically tied to both the (tie) input and output data sets. The input data set is the source of the input variables. The output data set is the source of the output variable. Sometimes, a rule set will have multiple input data sets and/or multiple output data sets. In this case, each input data set and output data set is a possible input or output of the transform. There is only one set of input variables (other than join operations), but there may be different mappings between business names and technology names for different data sets. In some cases, the input variables may be used by the rule sets and presented in one input data set but not in a second input data set. In this case, the DML expression must be specified in the second input data set as the technical name of the missing (missing) variable. If the rule sets do not use the input variables, there is no need to provide a technical name for each input data set.

Also, there may be only one set of output variables. If a given output data set does not have a field corresponding to an output variable (e.g., no technical name exists), the output will be ignored when generating the transformation for that output data set.

Some (somewhat) treat (deal) differently the rule set that is included. The included rule sets do not have associated input and output data sets. Instead, they have only input variables and output variables. The rule set containing the included rule set is responsible for mapping inputs and outputs. As described in more detail later.

Variables of

The variables may have the following characteristics and may be presented to the user in list form (tabular form):

1. business name (logical name). The business name is the name used in the rule. In some examples, restrictions are imposed such that no two input variables may have the same name, no two output variables may have the same name, no two outputs from the included rule set may have the same name, and no two lookup variables in the same lookup file may have the same name. The input variables may have the same name as the output variables. In this case, the user interface may disambiguate the input and output based on context or using a prefix (prefix) such as "out" before the name of the output variable. The lookup variables in different lookup files may have the same name. In this case, using a prefix such as looking up the name of the file itself will disambiguate between them.

2. And (4) simple type. In some examples, four basic types may be supported-string, number, date, and datetime. These correspond to character strings of DML type (int), decimal (20), date ("YYYY-MM-DD"), and time of day ("YYYY-MM-DDHH 24: MI: SS. nnnnnnnn"). For example, the transformation between the base type and the actual type used in the transformation is handled separately from the editing of the business rules by the generated transformation component.

3. A default value. The default values are only required for the output variables. It is the value used in the following case: (1) when there are empty cells in the regular output column for the output, or (2) when there is no regular trigger for the output to calculate a value. The default value may be NULL (and NULL cells are interpreted as NULL) as long as the output variable is nullable.

The default value is an expression, as used in the output column of the regular expression table. This means that the default value may reference an input variable or an output constant or contain an expression. The default value may also refer to other outputs as long as no (introduce) loop (circulation) is introduced.

4. Technical name (physical name) or expression. This is an expression that specifies a variable. An expression may be used instead of a field name for the input and included variables (in some examples, the expression is not allowed to be used for the output variables). In the case of a vector (vector), the expression should be fully qualified (qualify).

When processing elevated variables and input and output variables from the included rule set, the technology name associated with the variable is just the business name used inside the shared rule set. The technical name may be null when processing output variables that are used only internally (intermediate variables that are calculated in one rule and used in subsequent rules).

5. Optional description and comments

Constant number

The various tables of variables include mappings for constants as well as variables. The constants correspond to the enumeration (enum) in C + +. The software may support constant values initially from valid and invalid (invalid) values, and constant ranges initially from valid and invalid ranges. Further, constants may be created that represent a set of unique (distint) values and/or ranges.

Constants are associated with variables. This means that the business name of a constant need not be unique throughout the rule set. The editor typically learns the context (context) of any constant based on which column in the rule the constant appears; however, the user may select the constants to belong to different variables in the expression. In this case, constants with variable names would be eligible (e.g., "Airline class. bussiness").

When computing output variables, only constants of a single value are used (it makes no sense to assign a range to the output field).

Constants have the following properties and can be presented to the user in list form (variables and constants can be mixed (intercity), similar to embedding a table inside another table).

1. Variable names. All constants are applied exactly (exact) to one variable. The variable name is actually part of the associated variable itself.

2. Name of business. The business name is the name used in the rule. The name need not be an identifier of a value, in particular, internal spaces (space) and punctuation (puntations) are allowed. The business name of a constant only has to be unique within the variable to which it applies.

3. The constant type. A value, range, or set. As previously described, ranges and sets are legal (legal) only if used in comparisons (inputs) rather than allocations (outputs).

4. For the values: the actual value. In the current example, the string should be located in a quote (quote) and the number should not. Date and date-time should be in quotes when in default form (e.g., "YYYY-MM-DD"). It also allows the use of expressions as long as the expression returns a simple type that can be automatically converted to a variable type.

When a constant is part of a table of inputs or outputs of an included rule set, there is no value. Instead, the value is the business name of the associated constant for the corresponding input or output variable.

5. For the range: a minimum value and a maximum value. Both are constants or expressions, as are the actual values demonstrated above. The scope is used for short expressions (shorthand) of comparisons in the rule. Only an equal (equivalence) comparison is allowed for the range, and the software will translate to "variable > = min and variable < = max". If a minimum is not specified, then a portion of the comparison is skipped. The same situation applies to the maximum. The minimum and maximum may be separated by commas (commas) to actually store the range.

6. For a set: a list of comma separated values. Each element in the list is a constant or expression, as is the actual value demonstrated above. Only an equal comparison for the set is allowed and the software will translate to an expression in the form of a variable member of "[ vector of values ].

7. Optional description and comments

When processing elevated variables from a shared rule set, constants are also elevated. In the table showing the input and output variables of the shared rule set, the constants associated with these variables are also shown. The default mapping of these constants is part of the information being promoted, but the user can override the (override) constant value.

The software will detect when there is a possible conflict in the use of variables because of a non-matching constant. Specifically, if (1) the value of any variable is copied to another variable, and (2) if both variables have defined constants, and (3) the sets of constants in the name and value are not equal, an error is generated that the user needs to translate the value of one variable to the value of the other variable. The original variables include input variables, lookup variables, outputs from the included rule set, and output variables used as inputs. The target variables include output variables and inputs to the included rule set. The allocation may occur in a regular expression or a variable table.

Naming limitation

All that can be used as input typically needs to have a name that is unique within the entire rule set. This includes the business name of the input variable, the business name of the parameter, and the business name of the output mapped to each included rule set. For join operations, input variables in different input sets may have the same name. For example, prefixes corresponding to business names of the input set may be utilized to make them unambiguous.

The output variables must also be unique. However, the output variables may have the same name as the input variables. An input variable is assumed if the output variable has the same name as the input variable and the variable's name is used where the input variable's name is allowed (as in the trigger column of the rule). To use output variable substitution, for example, it is necessary to qualify a variable name by inputting "out. < variable-name >" when the name is input. This is simply the interface sign (navigation) -the internal representation of the variable is unambiguous.

Ambiguities may still exist between variables and constants having the same name. In this case, the software will support (revolut) constants when in the context where both constants and variables with the same name make sense. The user may qualify a variable name to override it by using, for example, the grammar "in. < variable-name >.

In some examples, it is assumed that the business names are UTF-8 so that they may include international characters. The business names may include spaces, periods, brackets, and the like. However, in such an example, the business name is not allowed to include any characters (control characters) between 0x00 and 0x 31. All business name matches are case-specific, although the user interface may allow the user to enter business names with wrong capital letters and then suggest (supergeet) the correct capital, for example, using an auto-completion mechanism.

Sequence of variables

To avoid circular logic (circular logic), the software enforces a strict order of variables and rules. The overall sequence is as follows:

1. input variables and parameters

2. Input mapping of a first included rule set

3. Output values of the first included rule set

...

4. Input mapping of the Nth included rule set

5. Output value of Nth included rule set

6. Default key value of first lookup file

7. Output field of first lookup file

...

8. Nth search file default key value

9. Output field of Nth search file

10. Default values for all output variables

The calculation of each term uses the values calculated in the previous step. This means, for example, that the first included rule may reference input variables and parameters in its mapping table. However, the second included rule may map its inputs to outputs calculated from the first included rule. Similarly, the default values for each output variable are calculated before any rule, so that they are based on the values of the input variables, parameters, look-up files, or outputs from any included rule. When the output of a rule is actually calculated, the rules are evaluated in order so that subsequent rules may use the values calculated from previous rules.

Linking data collections to variables

In some examples, the table of input variables is directly from the input data set record format and the business name is from metadata about the input data set. However, in some examples, there is an advantage of having a copy of such a mapping inside the rule set. First, having a copy of the variable mapping table in the rule set allows rules to be edited outside the context of the production environment. The rule set and associated rules may be serialized (seriolize) into a sandbox (sandbox) and edited as part of a sandbox item. Second, having a copy of the variable mapping table allows the user to resolve conflicts or otherwise overwrite existing metadata. For example, if two fields in an input data set map to the same business name, one of these business names may be changed in the table of input variables.

When the rule set is first created, the input variable table is empty. As soon as the user identifies an input data set, the input variable table is automatically populated from the metadata of the input data set (the same logic applies to the output variables and the output data set, but the remaining discussion will focus on the input data set for brevity).

For the sake of brevity, the singular term "input data set" is used in this discussion. There are zero or more input data sets that may be linked to input variables, and separate sets of zero or more input data sets that may be linked to output data sets. Specifically, the input variable table has one column for business names, one column for types, etc., and many columns for technology names, one per input data set. Once a single set of input data is specified, a second can be added using similar techniques. However, in the case of the second or subsequent data set, the mapping between the technical name and the business name may be incomplete, particularly since the system may not be able to ascertain to which variable each field in the second and subsequent data sets maps. In such an example, the user may manually correct any missing information.

When an input form is initially created from an input data set, each field in the input data set will cause an input variable to be created. The technical name of the input variable will be the name of the field. The type will be assigned based on the field type. Null (void) will be treated as a string and real numbers will be treated as numbers. A child record will not have a corresponding input variable although fields inside the child record have a corresponding input variable. The union (union) will result in an input variable for each branch (branch) of the union. If the element is a vector, the technical name of the corresponding input variable will assume the first element ("in.vect [0 ]") of the vector. The user can override this. For example, in the normalized type conversion, the user may change the technology name to in. Alternatively, if the vector is a fixed length, the user may create additional input variables corresponding to other elements of the vector. Union sets and vectors (for which no output variables will be created) may not be supported in the output data set. In some examples, variations of the normalization component may output an output vector instead of a plurality of output records.

In some examples, the business name is computed from the metadata. The logic for determining the business name for a field is as follows:

1. if this field (physical element) has a display _ name, the display _ name of this field is used as the business name.

2. Otherwise, if the field has a logical element and the logical element has a display _ name, then the display _ name of the logical element is used as the business name.

3. Otherwise, if the field has a logical element, the name of the logical element is used as the business name.

4. Otherwise, the business name is computed from the technical name.

If there is a conflict (duplicate name), only one business name will be assigned. No business name will be assigned to the other fields.

In the following example, there is no dynamic link between the rule set and the data set metadata. If a user changes metadata data (e.g., renames a logical element), the change is not automatically picked up by software (pick up). In some examples, a two-way (two-way) relationship between data may be used to allow such changes to be detected.

If the user adds a second set of data to the rule set, the software will attempt to populate the fields of each business name using the same physical-to-logical mapping rules as listed above. If a variable cannot be mapped, the technical term (term) for that variable will leave a blank for the added data set and the user will have to manually fill in the field name or expression. The available fields will be listed in the drop down of the user interface.

Meanwhile, an input variable table is built according to the data set metadata, and constants can be added to the input variable table according to the data set metadata. The software will create constants for all valid and invalid values and for all valid and invalid ranges: all valid and invalid values and all valid and invalid ranges are associated with a Validation Specification (Validation Spec) associated with each logical or physical element.

The logic for determining the business name for a constant is as follows:

1. if a valid value (valid range, etc.) has a display _ name, then the display _ name is used as the business name.

2. Otherwise, if a valid value (valid range, etc.) has a description, the description is used as a business name.

3. Otherwise, the constant would be included in the variable table without the business name.

It is not necessary to create variables starting with a data set. The second way is to create a list of input variables to identify logical entities (entries) in the underlying system. If a logical entity is selected, the software will create a table of variables with one variable for each logical element in the logical entity. The business name of the variable will be the display _ name of the logical element. If the logical element has a verification specification, the constants will also be created using the previous document rules.

Finally, the input variables and output variables may be added manually, either by adding them to a variable table or by creating them while editing the rules. For example, when a user adds a column to a rule, he selects which input variable should be used for that column. He may also select "new …" and create the input variable online (on the fly). The software will then prompt the user for the data type and optional comments. No technical name needs to be filled in until later.

The software needs a list of variables in order to allow editing of the rules. However, the mapping between business names and technology names does not have to be done until later. This mapping is only needed when the user is ready to test the entire rule set against an external test file or actually create a transformation from the rule set.

Included rule set

In some examples, a rule set may be shared. In particular, specifying that an included rule set is included within another rule set makes the logic of the rule set part of the transformation generated by the included rule set.

Although the included rule sets are typically specifically designated as shared, the included rule sets may also be used individually to create the transformations. For example, a user may create a rule set for computing boolean output for a filter type of transformation. But at the same time, the rule set may be included in another transformation and more complex outputs may be computed using boolean outputs (output variables of the shared rule set that are available in the included rule set).

The rule set included is similar to other types of rule sets. They have input variables and output variables. And may themselves include other included rule sets. But the processing for the input and output variables in the included rule set is different from the processing of the rule set for the transform type. In a rule set of transform types, mapping input and output variables to technology names allows a transform to be generated. But in the rule set included, there is no need to map the input and output variables to the technology name (if the rule set is shared and used to generate transformations, the input and output variables are mapped to the technology name in order to generate an arrangement of transformations (deployment)).

When a user includes an included rule set into another rule set, the included rule set needs to have a variable mapping table to map the inputs and outputs of the included rule set. In the context of the included rule set, only the input variables and output variables are visible in the shared rule set. Any variable of any rule set included in the shared rule set is not exposed (exposed) to the included rule set.

In the context of an included rule set, it is necessary to map the input variables of the shared rule set to the variables of the included rule set, or to use the expressions of these variables. The business names of the shared rule set will be listed in the variable mapping table, but these names will not be available for the rules in the included rule set. Alternatively, the included rule set need only match each input variable of the shared rule set (by business name) to an expression in the included rule set.

The included rule set to be evaluated is considered prior to inputting variables, parameters, and lookups, so that the output of the included rule set can be used as a key (key) for the lookup. In some examples, the order of evaluation is more flexible and the order of finding the evaluation relative to the included rule set may be automatically determined based on a dependency analysis. Because the included rule set is evaluated before any output variables are computed, no output variables in the included rule set can be mapped to the inputs of the included rule set. An expression may be used instead if the mapping of inputs to the included rule set cannot be done with simple input variables.

The mapping for an included rule set input variable may be NULL as long as the input variable in the included rule set is nullable. The mapping may also be left blank. If the mapping is left blank, errors will be reported at the time of transformation generation if and only if input variables are needed in the computation of the output of the included rule set. In some examples, it is assumed that everything is nullable, which simplifies the user interface.

In the context of an included rule set, there is also a need to map the output variables of the shared rule set to business names in the included rule set. The mapping table is the inverse of the mapping table described above. When mapping an input variable of a shared rule set, the table maps the business name of the input variable of the shared rule set to an existing variable in the included rule set. But when mapping the output variables of the shared rule set, the included rule set has a table specifying the business name of the output of the shared rule set-mapping the names in the included rule set to corresponding names in the shared rule set.

Output variable mappings are needed to resolve potential naming conflicts. The default mapping is to simply use the same business name in both the included rule set and the shared rule set. The name of an output variable in a shared rule set may conflict with the business name of an already defined variable in the included rule set, and thus the mapped name in the included rule set may be changed.

Not every output from the shared rule set needs to be mapped. If the output is left unmapped, it cannot be used in the included rule set, and the corresponding logic from the shared rule set will be ignored. On the other hand, all inputs from the shared rule set should be mapped, although if the designer of the rule set believes they will not be needed, they may be mapped to variables that are not of interest. In some examples, the system itself may determine which inputs really need to be mapped.

In some examples, the mapping table is done by business name rather than by reference. When a shared rule set is included in another rule set, the included rule set gets a copy of the inputs and outputs from the shared rule set. These names are stored with the mapping information in the included rule set. The resulting set of sharing rules may be changed to cause some inputs or outputs to be added, deleted, or renamed.

When a rule set is loaded from the system, referential integrity issues between the included rule set and the included rule set may be handled by the included rule set. Input variables that disappear from the shared rule set are deleted from the included rule set. The input variables added to the shared rule set are added to the mapping table of the included rule set, but remain unmapped. Likewise, the output variable added to the shared rule set is added to the mapping table of the included rule set, but remains unmapped. If an output variable is deleted from the shared rule set and it is not used in the included rule set, it is simply deleted from the mapping table, but if used in the included rule set, the user gets an error that the variable is no longer available.

The included rule set actually retains (persistence) redundant information from the shared rule set. In particular, in the input and output variable mapping tables, the included rule sets need only maintain a list of business names in the shared rule set along with the corresponding names in the included rule sets. The included rule set also retains the output of type, defaults, descriptions and annotations, all replicated shared rule sets for efficiency. These values are readable/read-only when compiling the included rule set, but are included for efficiency for generating reports and other analysis.

The shared rule set mapping table also has an additional entry (entry) in the included rule set that is an additional annotation. This allows the user to add another annotation to the mapped value.

Constants of shared rule set

Included in the mapping table for included rule sets are constants for input and output variables of the shared rule set. Constants used by a shared rule set may have to be mapped, as the variables themselves. For input variables, the shared rule set may internally compare the field with constants defined in its input table. When a shared rule set is included in another rule set, the constants for its input variables are copied to the included rule set. The user may then override the values in the context of the included rule set. In general, when a user defines a mapping between a shared rule set input variable and a variable in the included rule set, the constants between the two variables will match (match up). If this is not the case, the user will need to provide the technical value for any constant value defined by the set of sharing rules.

Searching for files

The rule set optionally has one or more look-up files. Each lookup file in the rule set includes the following information:

1. looking up the business name of the file.

2. Optional description and comments.

3. A list of business names of the fields that make up the key. These names are used when adding the find file to the expression so that the user sees the following: lookup (My Lookup File, < customer name key >, < account type key >) (Lookup (My Lookup File, < customer name key >, < account type key >).

4. A list of default expressions for each keyword.

5. And searching the technical name of the file. In some examples, may be covered in the arrangement.

6. One or more sets of lookup data. Each lookup file is loosely tied (tie) to a data set within the system, just as a rule set is tied to an input data set. By default, there is one set of lookup data associated with each lookup file in the rule set, but in alternative arrangements there may be multiple sets of lookup data for use.

7. A table of variables and constants is input. This is like a table of input variables and constants for a rule set, except that there is one table for each lookup file. Like the input variables, the table of input variables and constants for the lookup file may have a plurality of technical names, which correspond to each of the associated lookup data sets.

The lookup file is processed just like the input variable, except that there may be more than one lookup file. Each lookup file is edited on a page, has a mapping table between business names and technology names, and can be associated with multiple data sets. They also have constants associated with each field. Just as metadata for input variables is loaded from an input data set, the mapping of the lookup file may be initialized by reading the metadata of the lookup data set.

If the user uses a lookup field variable and no key is found in the lookup, the value of the field is assumed to be null. If the field is empty, unless the rule case is specifically triggered, the rule case is evaluated as false (false) and the rule case is skipped. In this case, no error is generated. If the user uses the find file variable (find file itself and not a field), then the function lookup _ match is assumed such that the find file variable evaluates to true (true) or false. Both cases apply to regular expressions of input columns or output columns. If the user defaults to using the lookup field variable as an output variable, the lookup fault is found to translate to NULL.

Parameter(s)

The rule set may reference parameters. In some cases, each rule set has an optional parameter table that maps the business name of a parameter to its technology name like a variable table. Each entry in the parameter table has the following attributes:

1. name of business. This is the name of the parameter when it appears in the rule ontology (body). In general, also wherever a parameter can be used at an input variable.

2. Technical name. This is the name of a parameter in the development environment

3. The type of parameter (string, decimal, date or time of day). In the generated transformation, the parameters may be converted to other types as needed.

4. Optional description and comments.

Parameters are like variables except that their values are constant throughout the input file, and when processing begins, their values are specified externally.

Test rules

Part of generating or updating a transformation is testing its corresponding rule. The rules are also verified, i.e. checked for consistency of syntax (syntax) and semantics (semantic). In contrast to verification, tests involving the execution and correctness of rules are determined by the user, for example by the user providing an expected output or manually comparing the output to an expected value.

The software supports testing on two levels. As previously described, each rule may have an associated set of test data in the form of an embedded table of values and expected results. This is called unit testing. When the rules are edited, the output of the rules may be re-evaluated for each row of test data. Any mismatches between the actual and expected results or faults that produce valid results are highlighted for resolution.

In some examples, the external input test file is accessible to the server process using standard mechanisms. A test using an external file is called a file test. The test file has a record format that matches the input data set of the rule set. In some examples, alternative recording formats may be provided. Alternatively, the user may identify a data set containing the desired results. The software runs a set of rules for the test data set and displays what output was produced, and why. If the expected results are included, the software compares the actual results against the expected results and lists any records that differ. In some examples, the interface may be extended to allow a user to incrementally retrain the values.

Some differences between unit testing and file testing include:

1. for the search file: in the unit test mode, the value of each lookup variable is defined for each test as part of the test. No keyword is specified; when the test runs, each lookup variable assumes the same value for each test case. The test data set contains a plurality of test cases, and each test case may specify a different value for each lookup variable. In the file test mode, the actual search file is used. This means that different keys may return different values, but this also means that the value used for any given lookup variable may not be changed in the test for a particular key.

2. For the included rule set: in the unit test mode, the included rule set is not executed and it need not even be complete. Alternatively, a value is specified in the test data set for each output from each included rule set. In the file test mode, the included rule set is executed in such a manner that the rule set included at the time of production will be executed. This implies that any look-up files or parameters needed by the included rule set also have to be specified at the test time.

3. For the parameters: in the unit test mode, a different value may be set for each parameter of each test case. In the file test mode, the value of each test is constant for the entire test.

4. For the current date: when testing, the user specifies a value that should be assumed to be the current date and time, provided the rule references the current date or time. In the unit test mode, the date and time may be different for each test case. In the file test mode, a single date and time is set for the entire test (this value may be different from the value of the date and time of the machine when the test is run).

5. For record format and mapping: no mapping is required to be specified for unit testing; the variable-based business name was tested in its entirety. For file testing, all variables are mapped to technology names and specify the record format of input, output, and lookup.

In the example of the output screen of FIG. 4A, a results table 410 is shown in which the output for each test case is displayed in a separate row 412i, and columns 413a-d show the test cases and the output calculated for each test case. When a row 412a is selected (shown in FIG. 4A by the dashed line), the input values 414A-414g from the corresponding test case are shown in input table 414. The outputs 416a-416c of the test case are shown in output table 416. The output 416i shown in table 416 may be an expected output from a test case, a calculated actual output, or both. Various interface prompts (cue) may be used to inform the user about the status of the test. For example, icon 419 indicates that the outputs in rows 412b and 412d of test case 2 and test case 4 have changed since the rule set was last tested. If there are no "default" rules to capture combinations of input values that do not match any other rule, then a test case with such inputs produces a null output 418. If the input record is rejected with a processing error (such as divided by zero), an error may be indicated in the same manner. If more than one rule case is triggered by a test case, the number of rule cases triggered may be indicated (422). By interacting with one of the displayed outputs, e.g. by clicking on it, the user can be taken to a screen detailing how the output is determined, as shown in fig. 4B.

In the output screen example of FIG. 4B, the table 430 displays the single test case 412 from FIG. 4A and indicates each input criterion 436i that is true in any rule case 434i with a dark border (border). For example, in the sixth rule case 434f, the cells containing the values of the third and fourth inputs 436c and 436d are highlighted because the values 412f and 412g of these inputs in the test case 412 match the values in the rule case (the bay is not the first or business bay, row < = 40). Indeed, any of a variety of graphical techniques (such as highlighting, color, font, or border) may be used to distinguish between true cells and false cells. The first rule case, rule case 434c, in which all values match the test case, is indicated by the dashed boundary, which is the trigger rule and the rule case that produces the output indicated in line 412b in FIG. 4A. Displaying not only the triggered rule case 434c but also other rule cases allows the user to quickly determine what rule cases will need to be applied and what changes to achieve the desired output. In some examples, multiple rule cases may be indicated that may have been triggered (e.g., if a higher has not been triggered). Column 438 may show the output triggered by each rule case (if it is to be triggered). These features may be assisted, for example, in the case of debug (debug) rules.

In some examples, the output of one rule set may be input to another rule set. How a given test case is evaluated by a set of rules in this case can be graphically illustrated as in fig. 4C. The business rules that place travelers from the test scenario of fig. 4A and 4B into boarding group 2 are shown as boxes (boxes) 442, which boxes 442 receive input from test case table 412 and provide output to output table 416. In this example, the second business rule indicates that travelers whose annual mileage is increasing should be rewarded. The rule receives input from the first rule that the mileage is increasing, in addition to receiving input from the test case, and is shown as box 444. Because the passenger is in the economy class (coach), the rules give the passenger free drinks (if the passenger is in the first class, she will have received free drinks and may require different feedback). In some examples, clicking on a displayed rule will lead the user to a display of how to trigger the rule, as shown in fig. 4B for the first rule 442.

The rule set is tested and verified using the process shown in FIG. 5. One or more rule sets 602 and corresponding test data 604 are inputs to the process. The software generates a transformation (606) based on the set of rules and uses it to calculate an output value for each record in the test data. In graphical computing, the output is tested using the "log" port (port) of the component concerned. The transformation generated for the test may be slightly different from the transformation that would be generated for the execution. At test time, additional output is added to the output record. The output is an array (array) containing the identification of the rule sets that actually generated the output and which rule case within those rule sets is responsible for the output. Multiple outputs, i.e., different outputs from different rule sets, may be generated for each test case. As discussed above, this array is used to generate the output tables shown in FIGS. 4A and 4B. In some examples, the test output is more complex than a single array. The output includes the following values: the value of each input for a given record, the value of each parameter, the value of each output from the included rule set, and the value read from each lookup file (including indicating which key is used for the lookup).

Starting with a first test case (608), the inputs of the test case are input (610) to the transform, and the output is written (612) to the output array along with an indication of which rule generated the output. This process is repeated for each row (614, 616) until the last row has been evaluated (614). The output array may then be used to generate 617 the result tables 410 and 420 as discussed above. The output array may be evaluated to determine if the rule set is valid, as shown in the remaining steps of fig. 5. Output values may be included in the test data and the output values generated from one test may be compared with the previous in-test output with the expected output from the test result with the test data 604 or the previous test result 617 (620). If none of the outputs match, then the mismatch is registered (log) (622). This process is repeated for each row (624, 626). In some examples, the evaluating step is integrated into the output generating step, and as the outputs are generated, each generated output is compared to a corresponding expected output. Any mismatches or other errors in processing the test data results are registered. As noted above, the output of one rule set may be input to another rule set, in which case the included rule set is evaluated as part of the included rule set.

The user may limit the rules tested by the output field. In some examples, a user may choose to disable (disable) rules during testing. In some examples, the user does not have to wait for all test files to be processed; test results can be obtained as long as the first few records are worked to output (work way to the output).

In addition to the test data itself, any of the following information may be used for file testing and included as part of the rule set.

1. The physical location of the data set is input. This is stored in the rule set of the input variable table for each input data set. For a join-type data set, all physical locations are required. Table names in the database may be used whenever a physical location is required.

2. The record format of the input data set. By default, this is taken from the data set definition of the input data set. There is a location in the input variable to override this with the different record formats checked into the sandbox. For the combination type transformation, all record formats are required.

3. Which arrangement is to be used.

4. All find the physical location of the file. This is stored in a look-up file table.

5. The record format of each lookup file. Taken from the data set definition associated with each lookup file or from an overlay record format file.

6. The value of each parameter. This will be set in the test parameters dialog (dialog).

7. The physical location of the file is output. This physical location is only needed when performing recursive (comparison) tests. Which is stored in an output variable table.

8. And outputting the recording format of the file. Again, this is only required when performing regression testing and is taken according to the output data definition or according to the optional overlay record format file.

9. Location of the item sandbox. The test must be performed outside of the sandbox on the host computer. A sandbox should be a verified copy of the item containing the rule set. All record format files will be fetched from the sandbox.

10. Values for date and time when the rule references "now", "today", or similar values.

There are three possible types of transformations: one that is unregistered, one that has all of the inputs, outputs, rules executed, etc. registered, and one that additionally includes details as to which cells in each rule are false or empty. The test may use either of the latter two types of registrations. If the transform does not register the unit state, it is simply not shown in the user interface. Registering inputs, outputs, etc. slows execution but only by a small amount. Registering the cell state slows execution by a significant amount, perhaps due to an order of magnitude.

When not tested, the user may still output the transformation registering the input, output, etc., and use the transformation in the generation. The enhanced transformation generates the same output, as well as a series of enrollment messages that can be analyzed to determine which rules were executed. If the user saves the generated registration, the information in FIGS. 4A, 4B, and 4C can be calculated by using the information in the registration, and the business rules environment can be used after the fact that the execution of the rule set in production is answered, even if no test input is used. We call this execution replay and it can be used for auditing.

Overlap analysis

In some examples, as mentioned above, when a user runs a test data set against a rule set, each rule triggered may be tracked (track), i.e., a rule case that satisfies all of its input conditions and will produce an output if a higher priority rule case has not yet satisfied all of its input conditions. After processing the test data, the software may later process (post-process) the test output data and generate a list of each rule or rule case that is not triggered by any rule case. This information may be overlaid (overlaid) over the display of the rules of the editor to quickly show the user which rules are triggered or not. From this information, the user can view possible rules that are obscured by other rules (obscure), i.e., overlapping rules. A count (count) may also be shown for each rule case. Counting may be useful when it has just been known whether a rule case is triggered, particularly for adjusting (tune) values to achieve a desired output release and for identifying the most likely rule case for regulating performance.

Transformation generation

Business rules are evaluated in an application (graph) by converting each rule set into a transformation. The transform is then attached (attach) to the component in the graph. Such components may be sub-graphs that contain a set of standard components linked in a particular way for performing the transformation. Such sub-graphs can then be used with add-ons, for example, to be combined and accumulated using keywords.

The transformation code may be generated from the business rules in a variety of ways. In examples where the interior of the transformation is not designated as user edit, the generation process may result in a transformation that is difficult to understand (compound), but the transformation enforces the rules more efficiently than applying the rules one by one. In some examples, as shown in fig. 6, a simple if-then-else chain 500 may be used to capture the logic in the rule set (repeat the rule set table 200 of fig. 2A for reference). Shown in chain 500, there is one "if … then … (… … if … …)" clause 502i for each rule case 210 a. As-is such chains can be used or they can be optimized depending on the availability of suitable computing resources and priorities of the users of the system. In some cases, dedicated computing resources or other techniques may be used to improve the performance of the generated transformation. Some details of how the transformation is generated may be stored in the arrangement. The rule sets that can be used in multiple graphs can have multiple arrangements for their different possible users. The rule set may also contain a superset of rules, only some of which are needed in each arrangement that identifies which rules are used when generating the transformation.

In some examples, if a rule includes a column that is a fractional number, and there are a large number of different values that match the column, we can improve the performance of the transformation by writing a "switch" statement branch on the indicated column. For example, consider this rule:

flight number	Rows of seats	Registration group (output)
			1	＜10	1
1		2
			2	＜15	1
2		2
			3		1
4		1
			5	＜10	1
5	＜20	2
			5		3

The transformation of the rule may be generated in two ways. As such:

if(NUM==1andROW<10)thenBG=1

else if(NUM==1)then BG=2

if(NUM==2and ROW<15)then BG=1

else if(NUM==2)then BG=2

else if…

or as such:

Switch(NUM)

case1:if(ROW<10)then BG=1else BG=2

case2:if(ROW<15)then BG=1else BG=2

...

another technique we can use is to look up the file in memory. If the rule has a number of constant values, with a small number (if any) of expressions, instead of if the else logic, we can just use a look-up table. In this case, the look-up table is part of the rule (not separately maintained). For example, consider the rule:

starting city	Destination city	Service space	Expression formula	Frequent flyer mileage
					BOS	LAX	First class cabin		6000
BOS	LAX	Business cabin		3000
					BOS	LAX	Economy cabin	Is Using Miles=yes	0
BOS	LAX	Economy cabin	else	3000
					BOS	CHI	First class cabin		2000
BOS	CHI	Economy cabin		1000
					BOS	NYC	First class cabin		1500
BOS	NYC	Business cabin		1000
					BOS	NYC	Economy cabin		500

The rule is processed by building a look-up table in memory with the following information:

starting point	Destination	Cabin space	Expiration date	Mileage
					BOS	LAX	1	0	6000
BOS	LAX	2	0	3000
					BOS	LAX	3	1	3000
BOS	CHI	1	0	2000
					BOS	CHI	2	0	1000
BOS	NYC	1	0	1500
					BOS	NYC	2	0	1000
BOS	NYC	3	0	500

The transformation is as follows:

int expr=lookup(from,dest,class).expr

int miles=lookup(from,dest,class).miles

if(expr==1and is_using_miles)miles=0

return miles;

each rule set has an arrangement table. The placement table maps names to details about the configuration of the placement. Each entry in the placement table contains the following information:

1. the name of the arrangement. Any string that must be unique within a rule set.

2. The data set name is input. If there are multiple input data sets listed in the input variable table, each entry in the arrangement table indicates which input data sets are used for the arrangement.

3. And outputting the data set name. If there are multiple output data sets listed in the output variable table, each entry in the arrangement table indicates which output data sets are used for the arrangement.

4. The placement name of each included rule set. For each included rule set, we need to indicate which arrangements should be used for each corresponding arrangement of the included set.

5. Component and target location of transform file to be generated

In some examples, there is always at least one arrangement named default. This is an arrangement (deployment) used when no other arrangement is specified.

In one exemplary embodiment, there is a basis for transformation generation. First, the software will only output the output rules computed in the rule set. All other outputs are processed with wildcards in the transformation. Typically, only the output variables that are used internally cause the creation of local variables in the generated transformation. That is, if necessary, the generated transformation may include more local variables to avoid duplicate computations (e.g., if optimized for speed over space).

FIG. 7 shows how the rule set is evaluated within the generated transformation. For each output (702), the relevant rules are evaluated in sequence. For rules that generate disjoint (dis join) outputs, the transform generator decides the order of evaluation of the rules based on a dependency analysis. Cyclicity is not allowed and reported as error. If two or more rules generate the same output, then their execution order is the same as the order in which they are listed in the rule set. Within each rule (704), the evaluation rule cases are evaluated sequentially from top to bottom. For each rule case (706), the trigger columns for each rule may be evaluated (708) in an undefined order (e.g., the software may not guarantee the order of evaluation within a single rule case). Whenever a rule case is found in which all triggers are true (non-zero/false and non-null), the corresponding output value is used (716). This process continues as long as the rule case evaluates to false (718, 712, 720, 722). If no rule triggers for a given output (720), the transformation explicitly sets the output value to NULL or a suitable default value (724).

Depending on the transform type, there are differences in the following transforms:

● reformat-the input is called "in" and the input variable may have a technical name like "in. The output is called "out" and the output variable may have a technical name like "out.

● bind-the two inputs are called "in 0" and "in 1". The output is referred to as "out" and the wildcard rule assumes that in0 is copied to "out". All parameters may be set between generations. The rule set may have multiple sets of inputs, one set for each input to the join. The rule set will also specify the join type, whether the input should be non-spoofed (de-processed), and the business name of the field to use for the keyword to join (in some examples, this must be present in each input set). Also, the user may be allowed to specify an expression for each input that is used as an input filter.

● accumulate-the input is called "in" and the output is called "out". In the rule set of the accumulation type, the user is allowed to use an aggregation function (which is not supported in other transformation types). If the user creates output variables with the technical names "in _ select" or "output _ select", the "in _ select" and/or "output _ select" functions are added to the transformation with the logic that computes the rules for these outputs. The inputs to these two functions are called "in" (even though out _ select usually names its parameter "out"). As in the join type, all parameters may be set when generating a component.

● sift-output one of two predefined constants. The only output variable for a filter type of transformation is the type component "select", which is passed to the output is non-zero and non-null. In some examples, it is implemented in a child graph as a reformatted component.

Additional transform types may also be implemented:

● the scan-scan function takes two inputs named "temp" and "in" and produces an output named "out". The rules in the rule set may use fields from both temp and in records. This can be determined by the technical name of the input variable. (for example, the technology name may be set to the string "temp.

The record format for a temporary variable ("temp") of a transform contains every output generated by a set of rules. An initialization function is automatically created by software to initialize each field in a temporary record format to their default values. An end (finalize) function is also automatically created by software; the function simply copies the temporary record to the output and adds the wildcard rule. As with the accumulation case, scan-type transformations also support the creation of an in _ select function and an output _ select function if the variables with these technical names are in the output variable table.

● the normalization-normalization function takes two inputs, "in" and "index" and produces an output named "out". The index (index) input is not a record, rather if the user wants to use the index in a rule, they create an input variable that is mapped to the technology name of the index (the index variable can also be used in various DML expressions). The software will have the length of the rule it passes through as described above.

The normalized type rule set also supports output variables named "in _ select" and "output _ select", as do the accumulation type rule sets.

● classification-the rule has N outputs and the transformation decides which output should be used for each record. For this component, the software creates out a class (in) function. The output is a single integer value indicating which (possibly more than one) output port should be used. Output 0 means the 0 th port, output 1 means the first port, and so on.

The only output variable for a transformation of class type is a "select" type component, which will be the index of the output port (based on zero). This is similar to screening, except that N values are used for the output instead of two.

● the function-function type rule set may be converted to a DML transform file, but not as a component transform. In contrast, when a rule set of a function type is converted into a transform, a constructed transform file to be included in other transforms is designed. Each output variable is converted into a DML function. The inputs to these functions depend on the type of rule. For a rule of function type, the input is the input for the rule in the order listed in the table. For non-function type rules, each output function takes a single input named in, which is a record with all fields corresponding to the input variables.

When a rule set is used to generate a transformation that will in turn be part of a graph, the graph component includes the name and arrangement of the rule set. The graphics developer can then zoom the rule set instead of the transformation generated in the component. Changes to the rule set cause the transformation to be regenerated.

Other features and variations may include generating reports on rules used in a particular rule set, a more granular licensing model that allows some users to edit rules rather than adding input, for example. An internal rule dependency tree (dependency tree) may be implemented for each output. A rule or set of rules may have a legal date or an expired date. A single input record may produce multiple outputs, e.g., if the criteria of multiple rules are met, they may all operate instead of just the first. Support for vector output may be provided. For example, users may be able to specify their own validity functions in the edit to further protect or restrict business users.

The business rule management methods described above may be implemented using software executing on a computer. For example, the software forms procedures in one or more computer programs that execute on one or more programmed or programmable computer systems (which may be of various architectures such as distributed, client/server, or grid) each of which includes at least one processor, at least one data storage system (including volatile and non-volatile memory and/or storage elements), at least one input device or port, and at least one output device or port. The software may form one or more modules of a larger program that provides other services related to designing and computing graphic configurations, for example. The nodes and elements in the graph may be implemented as data structures stored in a computer-readable medium or other organized data suitable for a data model stored in a data repository (repository).

The software may be provided on a readable medium, such as a CD-ROM, conveyed (encoded in a propagated signal) by a general or special purpose programmable computer or over a network to a computer executing the software. All functions may be performed on a dedicated computer or using dedicated hardware, such as a co-processor. The software may be implemented in a distributed manner where different portions of the calculations specified by the software are performed by different computers. Each such computer program is preferably stored on or downloaded to a storage media or device (such as a solid state memory or solid state media, or magnetic or optical media) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer system to perform the procedures described herein. The inventive system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer system to operate in a specific and predefined manner to perform the functions described herein.

A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, some of the steps described above may be order independent, and thus may be performed in an order different than that described.

It is to be understood that the foregoing is intended to illustrate and not to limit the scope of the invention, which is defined by the scope of the appended claims. For example, many of the above-described functional steps may be performed in a different order without actually affecting the overall process. Other embodiments are within the scope of the following claims.

Claims (39)

1. A method for managing one or more rules applied to data in a data storage system, the method comprising:

receiving data from the data storage system at an input device or port; and

processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying portions of the rule specification at an editor interface;

applying the rule to one or more records of the received data to obtain result information; and

displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

2. The method of claim 1, wherein applying the rule comprises: the rule is applied to input values in the received data to generate output values.

3. The method of claim 2, wherein displaying at least a portion of the result information comprises: and displaying the comparison result of the generated output value and other output values.

4. The method of claim 3, wherein the other output value comprises a reference output value in the received data that corresponds to the input value.

5. The method of claim 3, wherein the other output values comprise output values generated for a previous version of the rule specification.

6. The method of claim 1, the processing further comprising: information defining at least a portion of the rule specification is received from a user.

7. The method of claim 6, wherein displaying at least a portion of the result information comprises: displaying verification information based on the result information while the received information is being entered into the editor interface.

8. The method of claim 1, wherein a portion of the rule specification includes one or more rule cases, and at least one rule case defines a condition for each of one or more potential inputs.

9. The method of claim 8, wherein at least one rule case defines an output associated with a result of evaluating the defined condition.

10. The method of claim 8, wherein displaying at least a portion of the result information comprises: displaying an indication of a triggering rule case for which an input value as a potential input in the received data satisfies a defined condition of the rule case.

11. The method of claim 10, wherein displaying at least a portion of the result information comprises: a count of the number of times that the trigger rule case triggered for different sets of input values in the received data is displayed.

12. The method of claim 10, wherein displaying at least a portion of the result information comprises: information is displayed on how to trigger the trigger rule scenario.

13. The method of claim 12, further comprising: displaying the information on how to trigger the trigger rule scenario in response to a user interaction with at least a portion of the displayed result information.

14. The method of claim 12, wherein the information on how to trigger a triggering rule case comprises input values for conditions in the received data rule for evaluating a definition of a rule case.

15. The method of claim 8, wherein displaying at least a portion of the result information comprises: displaying an indication of an un-triggered rule case for which an input value as a potential input in the received data does not satisfy a defined condition of the rule case.

16. The method of claim 15, wherein displaying at least a portion of the result information comprises: a count of the number of times that different sets of input values in the received data did not trigger an un-triggered rule case is displayed.

17. The method of claim 1, wherein displaying at least a portion of the result information in association with a particular display portion of the rule specification comprises: displaying at least a portion of the result information in superimposition with the display of the particular display portion of the rule specification.

18. The method of claim 1, wherein displaying at least a portion of the result information in association with a particular display portion of the rule specification comprises: displaying the particular display portion of the rule specification in a particular color.

19. The method of claim 1, wherein the result information comprises a calculation result from applying the rule to a record.

20. The method of claim 1, wherein the result information is based on a plurality of computed results from applying the rule to a plurality of records.

21. The method of claim 1, wherein the editor interface enables editing of the rule specification and displaying a result of reapplying a rule specified by at least a portion of the edited rule specification.

22. The method of claim 1, wherein the processing comprises:

receiving information in the editor interface that redefines at least a portion of the rule specification;

reapplying the rules to one or more records of the received data to obtain update result information; and

displaying the update result information in the editor interface in association with a particular display portion of the rule specification.

23. The method of claim 1, wherein applying the rule to one or more records of the received data comprises: applying the rule specified by at least a portion of the rule specification to a plurality of records of the received data.

24. The method of claim 23, wherein displaying at least a portion of the result information comprises: a count of the number of times the record of the received data achieves a particular result is displayed.

25. Software stored on a computer-readable medium, for managing one or more rules applied to data in a data storage system, the software including instructions for causing a computer system to:

receiving data from the data storage system at an input device or port; and

processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying portions of the rule specification at an editor interface;

applying the rule to one or more records of the received data to obtain result information; and

displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

26. A computer system for managing one or more rules applied to data in a data storage system, the computer system comprising:

an input device or port configured to receive data from the data storage system; and

at least one processor configured to process at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying portions of the rule specification at an editor interface;

applying the rule to one or more records of the received data to obtain result information; and

displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

27. A computer system for managing one or more rules applied to data in a data storage system, the computer system comprising:

means for receiving data from the data storage system; and

means for processing at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying portions of the rule specification at an editor interface;

applying the rule to one or more records of the received data to obtain result information; and

displaying at least a portion of the result information in the editor interface in association with a particular display portion of the rule specification.

28. A method for managing one or more rules applied to data in a data storage system, the method comprising:

receiving data from the data storage system at an input device or port, the data comprising an input value and a reference output value corresponding to the input value; and

processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying information defining at least a portion of the rule specification at an editor interface;

applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and

providing an indication of a comparison of the generated output value with the reference output value in the received data.

29. The method of claim 28, wherein providing the indication comprises: displaying a result of the comparison in the editor interface.

30. The method of claim 29, wherein displaying the results comprises: displaying a portion of the rule specification in a particular color.

31. The method of claim 28, wherein a portion of the rule specification includes one or more rule cases, and at least one rule case defines a condition for each of one or more potential inputs.

32. The method of claim 31, wherein at least one rule case defines an output associated with a result of evaluating a defined condition.

33. The method of claim 28, wherein the rule specification is stored in association with the data from the data storage system.

34. The method of claim 28, further comprising: an input is received identifying the data from the data storage system.

35. The method of claim 28, wherein the reference output value comprises a value previously generated based on the input value.

36. The method of claim 35, wherein the previously generated values comprise values generated in previous tests of the rule specified by at least a portion of the rule specification.

37. Software stored on a computer-readable medium, for managing one or more rules applied to data in a data storage system, the software including instructions for causing a computer system to:

receiving data from the data storage system at an input device or port, the data comprising an input value and a reference output value corresponding to the input value; and

processing, with at least one processor, at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying information defining at least a portion of the rule specification at an editor interface;

applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and

providing an indication of a comparison of the generated output value with the reference output value in the received data.

38. A computer system for managing one or more rules applied to data in a data storage system, the computer system comprising:

an input device or port configured to receive data from the data storage system, the data comprising an input value and a reference output value corresponding to the input value; and

at least one processor configured to process at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying information defining at least a portion of the rule specification at an editor interface;

applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and

providing an indication of a comparison of the generated output value with the reference output value in the received data.

39. A computer system for managing one or more rules applied to data in a data storage system, the computer system comprising:

means for receiving data from the data storage system, the data comprising an input value and a reference output value corresponding to the input value; and

means for processing at least a portion of the received data according to a rule specified by at least a portion of a rule specification, the processing comprising:

displaying information defining at least a portion of the rule specification at an editor interface;

applying the rule specified by at least a portion of the rule specification to the input value in the received data to generate an output value; and

providing an indication of a comparison of the generated output value with the reference output value in the received data.