Page Comparison

Brief Overview:

Business rules within Framework force users to enter pertinent information before certain fields can be completed/filled.

...

It is recommended that the rule in question is tested adequately to check that it: a) works as it should, or b) does not work as it should. If b), then the string will need to be evaluated and retested to get the desired result.

Introduction

• Any field in Framework can have zero or more rules associated with it. For a new value to be accepted by that field, all rules for this field must evaluate to true.

• Rules are unique to RMS Fields and Region Divisions, allowing separate divisions of an organisation to specify their own local rules. Business Rules may be switched on/off at the rule level, division level and global level.

• All rules are stored in the database as text strings representing the conditions that as a whole, must logically evaluate to true for the rule to hold. In essence, if Framework accepts the syntax string of the rule, it does not necessarily equate to the rule holding in production. I.e. it will not trigger when you violate the rule.

• A rule is either empty, or a combination of clauses and logical operators (non-empty).

• The empty rule (no rule) is an empty string:
  Eg: “”

• A non-empty rule is either a single clause, or any number of sub-strings, containing 2 clauses and an operator, separated by any amount of whitespace and enclosed in round brackets “( )”

Empty Rules / Clauses and Logical Operators

Eg: “[X <= Y]”                                                      - rule with 1 clause
Eg: “([x <= Y] AND [Y <= Z])”                              - rule with 1 operator
Eg: “([x <= Y] AND ([A = B] OR [Y <= Z]))”         - rule with 2 operators

• An operator is any of the following: 
  AND, OR, NAND, NOR, XOR, XNOR

• A clause is 2 operands separated by a comparator, enclosed in square brackets.

 Eg:  [X <= Y]

Where there is any amount of whitespace between the comparator and operands.

• A comparator is any of the following:

 <, >, <=, >=, =, !=

In order: Less than, greater then, less than or equal to, greater than or equal to, equal to, not equal to.

...

A clause may also be a null test of a single field, using the following syntax:

• Eg: [isNull<1234>]     - Clause is true when field 1234 is null

• [notNull<1234>]         - Clause is true when field 1234 is not null

In addition to the above, a clause operand may include a mathematical manipulation of the field’s value. For example, you may wish to specify that one field be compared to 5% of another field, or one field be compared to another field minus 2 weeks. This is achieved by prefixing the field’s context ID with the operation and its parameter, followed by the operation again, as follows:

• Example:

[86 > %5.5%91]         -field 86 must be greater than 5.5% of field 91
[86 > *10*91]              -field 86 must be greater than 10 times field 91

...

Note: the units of the parameter in the operation depend on the operation or the field value’s type. For all *,/ and % operations, the parameter is converted to a floating point double beforehand. For + and – operations, the parameter is converted to the same type as the field value’s. This may be numerical, date (days), time (minutes), currency (dollars), etc. So, if field 91 is a date, the third above example says: ‘field 86 must be greater than field 91 minus 2 days. 

• A clause operand may also be the sum of 2 or more Field Values. This is achieved by the use of the ‘s’ character, and the list of fields to be summed enclosed in curly braces:

Example: [86 < s{20, 30, 40}]   - field 86 must be less than the sum of fields 20,30 and 40

Framework In-Practice Examples:

Rule for Admin Complete:

([86 <= 91] AND [64 < 91])

...

Base Start Date (2118) must be less than or equal to Frame Complete (2135)

Rule Control  

A rule belonging to a particular field can be found in the rms_ctxBRule table, indexed by the Field Context ID (l_rms_fieldCtx_id) and the Region Context ID (l_context_id)  - the Region Division to which the rule belongs.

• Individual rules can be switched on and off via f_customRule

• The message displayed to the user when a rule is violated is stored in m_notes

• The ID of the context the rule belongs to is stored in l_context_id

• Rule enforcement is enabled for a particular context (Region Division) via l_rDiv_id in the rDiv table, and changes at log on/off

NOTE: When a rule has been violated in Framework, the user is kept in edit mode to change the offending fields to valid values. If the user cancels at this point, ALL CHANGES WILL BE LOST, including changed fields that satisfied their business rules. Ensuring that the appropriate action is taken to correct the business rules will allow users to not lose any of the changes they have made.