Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

Version 1 Next »


 

  • Any field in the Framework Database may have zero or more rules associated with it. For a new value to be accepted by that field, all rules of 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

 

  • 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 “( )”

 

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:

 

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

 

  • An operand is either a database field’s context id (rmsFieldCtxPKID), or a literal value preceded by a ‘

 

Eg: 49882        - field context ID (long)

      ‘2/4/99       - literal value (date)

      ‘$4,500      - literal value (currency)

      ‘Hooper     - literal value (string)

      ‘1:00 PM   - literal value (time)

 

NOTE: if operands are of different types, an error will be generated

 

-          If the value of the left operand is null (missing, empty, “”, whitespace, unknown, undefined), the clause is False.

 

-          If the value of the right operand is null (missing, empty, “”, whitespace, unknown, undefined), the clause is True.

 

-          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 it’s parameter, followed by the operation again, as follows:

 

  • Eg: [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

[86 > -2-91]                 -field 86 must be greater than field 91 minus 2

[86 = +12+91]             -field 86 must equal field 91 plus 12

[86 != /4.0/91]             -field 86 must not equal field 91 divided by 4

 

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:

 

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

   20,30 and 40

 

-          A real-world example:

 

  • Rule for Admin Complete:

 

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

 

 

Building Permit Received Date (86) must be less than or equal to Admin Complete Date (91)

 

AND

 

Ordering Received Date (64) must be less than Admin Complete Date (91)

 

-          Another one:

 

  • Rule for Frame Complete:

 

[2118 <= 2135]

 

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

ssage displayed to the user when the rule is violated 

  • No labels