1.3.2.1.1 Defining Business Rules

The Business Rules Check processor allows a set of business rules to be defined and maintained outside of EDQ, and applied using a single processor. Rules are defined in terms of attributes, which are independent of any data structure. Attributes have tags such as a1, a2, a3 and so on, and must be mapped to the appropriate fields in the input data when the Business Rules Check processor is configured (see the Business Rules Check topic).

The business rules can be defined:

Business rule structure

Business rules are made up of three types of component:

  • Checks are small, re-usable pieces of logic. They have a user-defined name, a type of check to be performed, and zero to several options whose meaning varies depending on the type. Checks can be built up to create more complex conditions, or can be used directly in rules. See Defining Checks.

  • Conditions are more complex pieces of logic, which apply checks to attributes, but are not full rules. Using conditions in your business rule configuration is optional, and not always necessary. Conditions can act as a gateway to a rule; if a rule is assigned a condition, the rest of the rule will only be evaluated if the condition passes. Conditions can be built out of checks, or out of other conditions, leading to complex logical structures. See Defining Conditions.

  • Rules specify which checks will be applied to which attributes. A rule has an ID and a label for ease of reference, and also specifies the error code, error message and the severity of the error to be raised if the rule fails. See Defining Rules.

Defining Checks

A check has the following characteristics:

  • A name, which is defined by the user and allows the check to be referenced from elsewhere;

  • A check type, which defines the operation that the check will perform, and

  • Up to three options, which provide any additional information that the check operation needs in order to work.

A check does not specify the attribute that it will work against.

The following table describes the supported check types:

Name Description Options

No Data Check

Used to check that a field is blank. The check will fail if the field contains any data.

None

Population Check

Used to check that a field is not blank. The check will fail if the field does not contain any data.

None

Character Check

Used to check that data in a field contains only characters from the specified list.

Option 1 = the list of permitted characters (see Note, below), OR

Option 2 = the name of the worksheet containing the permitted characters (for use with Excel-based rules only), OR

Option 3 = the name of the reference data containing the permitted characters

Invalid Character Check

Used to check that data in a field does not contain any characters from the specified list.

Option 1 = the list of invalid characters (see Note, below), OR

Option 2 = the name of the worksheet containing the invalid characters (for use with Excel-based rules only), OR

Option 3 = the name of the reference data containing the invalid characters

Min Length Check

Used to specify a minimum length for string data in a field

Option 1 = the minimum length of the data field

Max Length Check

Used to specify a maximum length for string data in a field

Option 1 = the maximum length of the data field

List Check

Used to check that data in a field contains only values from the specified list.

Option 1 = a single permitted value, OR

Option 2 = the name of the worksheet containing the permitted values (for use with Excel-based rules only), OR

Option 3 = the name of the reference data containing the permitted values

Invalid List Check

Used to check that data in a field does not contain any values from the specified list.

Option 1 = a single invalid value, OR

Option 2 = the name of the worksheet containing the invalid values (for use with Excel-based rules only), OR

Option 3 = the name of the reference data containing the invalid values

Regex Check

Used to check that data in a field conforms to a regular expression.

Option 1 = the regular expression, OR

Option 2 = the name of the worksheet containing the regular expression (for use with Excel-based rules only), OR

Option 3 = the name of the reference data containing the regular expression

Invalid Regex Check

Used to check that data in a field does not conform to a regular expression.

Option 1 = the invalid regular expression, OR

Option 2 = the name of the worksheet containing the invalid regular expression (for use with Excel-based rules only), OR

Option 3 = the name of the reference data containing the invalid regular expression

Script

Used to specify an external script which will perform processing on the data.

Option 1 = the script code or the name of the script to be executed

Option 2 = the script language. Valid values are 'javascript' or 'groovy'. The language defaults to javascript if no option is specified.

Fail

Used to specify a check which will always fail.

None

Note:

Lists of valid or invalid characters are case sensitive and can include all characters, including alphanumeric characters, whitespace characters and special characters. Where a list is supplied directly in the check, it should be entered as a single string without delimiters or whitespace characters, as these would be interpreted as part of the list itself.

Defining Conditions

Conditions associate checks with attributes. As well as associating a single check with a single attribute, a condition can apply two checks to a single attribute, or a single check to two attributes. It can also be used to aggregate other conditions together to create a more complex condition. Conditions have the following attributes:

  • A name, which is defined by the user and allows the condition to be referenced from elsewhere;

  • A Type field, which specifies the type of the entries in the Condition fields (Checks, Attributes or Conditions);

  • At least one Condition field. Condition fields can contain checks, attributes or conditions, as specified by the Type;

  • An 'Attribute or Check' field, whose content depends on the value of the Type. If the Type is 'Checks', this field contains the attribute to which the checks will be applied. If the Type is 'Attributes', this field contains the check that will be applied to the attributes. If the type is 'Conditions', this field is not used.

  • An Operator field, which can contain one of the logical operators AND, OR and NOT. If this field is set to AND, and a value is set in more than one Condition field, then both the conditions must evaluate to true for the condition as a whole to return true. If set to OR, then only one condition from the set must return true for the whole condition to evaluate To true. If set to NOT, the condition evaluates to the opposite of the expression specified in the first Condition field. If this field is NULL, its meaning is assumed to be 'AND'. The operators AND and OR have no meaning unless at least two conditions fields are set.

The following table summarizes the behavior when two condition fields, named Condition1 and Condition2, are in use:

If Type is set to... Then Condition1 and Condition2 contain... And Attribute or Check contains... If Condition1 and Condition2 are set, then... The AND operator will cause the condition to return... The OR operator will cause the condition to return...

Checks

A check or checks

An attribute

The two checks will both be applied to the attribute.

TRUE if and only if both conditions return TRUE for the attribute

TRUE if at least one of the conditions returns TRUE for the attribute

Attributes

An attribute or attributes

A check

The check will be applied to both attributes.

TRUE if and only if the condition returns TRUE for both attributes

TRUE if the condition returns TRUE for at least one of the attributes

Conditions

Conditions

Nothing

Both conditions will be evaluated.

TRUE if and only if both conditions return TRUE

TRUE if at least one of the conditions returns TRUE

It will readily be seen that by combining checks with different attributes and operators, and aggregating the resulting conditions together to form more complex conditions, complex logical checks can be built up.

Defining Rules

Rules are the top-level entities in the business rules check. They bring together checks and conditions, specify which attributes the checks should be applied to, and specify the error code and error message that should be raised if the rule fails. In addition, the severity of the error can be specified at this level.

Rules have the following fields:

  • The Rule ID is a numeric identifier for the rule;

  • The Rule Label is a human-readable name for the rule;

  • The Disable field can be set to 'Yes' to remove the rule from processing without deleting it;

  • The Apply to Attribute field specifies the attribute to which the checks should be applied;

  • The Condition field specifies a condition that should be evaluated before the rule is applied. The rule will not be applied if the condition is not met.

  • The Error Code specifies the error code that will be returned if the rule fails. Error codes are defined entirely at the user's discretion and can be in any format.

  • The Error Message is a user-defined message that will be returned if the rule fails.

  • The Error Severity specifies an indication of the severity of the rule failing. Error severities are defined entirely at the user's discretion and can be in any format.

  • Check 1 specifies the first check to be applied to the attribute;

  • Check 2 specifies the second check to be applied to the attribute.

If two checks are specified, then the rule only passes if the attribute passes both checks. That is, the result is the logical AND of both checks.

Note:

Conditions can be applied to rules in order to ensure a complex set of conditions is not true. The logic describing the invalid configuration is specified using conditions. Then, a very simple rule can be created which is controlled by the condition and has Check 1 set to 'Fail'. When a rule is configured in this way, the condition will be evaluated for each row analyzed, and, if the condition is met, the rule will always fail.

Defining business rules in an Excel spreadsheet

If you want to use an Excel Spreadsheet to define your business rules, it must conform to the following rules:

  • It must be placed in the [Install Path]/oedq_local_home/businessrules directory, where [Install Path] represents the root of your EDQ installation.

  • The rules, conditions and checks must be defined on three separate worksheets, named Rules, Conditions and Checks, respectively.

  • You may supply further worksheets in the same Excel file to contain additional data, for use in list checks and so on.

  • The Rules worksheet should contain columns named as follows:

    • Rule ID

    • Rule Label

    • Disable

    • Apply to Attribute

    • Condition

    • Error Code

    • Error Severity

    • Error Message

    • Check 1

    • Check 2

  • The Conditions worksheet should contain columns named as follows:

    • Condition Name

    • Attribute or Check

    • Type

    • Operator

    • Condition1

    • Condition2 ... ConditionN

  • The Checks worksheet should contain columns named as follows:

    • Check Name

    • Check Type

    • Option 1

    • Option 2

    • Option 3

Defining business rules in reference data

If you want to use reference data to contain your business rules, it must conform to the following rules:

  • Three separate sets of reference data (or two sets, if you are not using conditions) must be available, specifying the rules, conditions and checks, respectively.

  • The structure of the reference data must be the same as that described for the Excel spreadsheets, above.