/
Business Rules - String Syntax

Business Rules - String Syntax

Owned by Matthew Garrett
Last updated: Sept 08, 2021
4 min read



Incorrect use of business rules in Framework ECM may cause errors and/or unpredictable behaviour. If unsure how to implement business rule changes, please contact your Framework Solution Provider.

Any field in the Framework ECM database may have none (0) 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.

Business 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 be valid.

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

Empty Rule

The empty rule (no rule) is an empty string:

  • “”

Non-Empty Rule

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 white space and enclosed in round brackets “( )”

  • Rule with one (1) clause: “[X <= Y]”

  • Rule with one (1) operator: “([x <= Y] AND [Y <= Z])”

  • Rule with two (2) operators: “([x <= Y] AND ([A = B] OR [Y <= Z]))”

Operators

An operator is any of the following:

  • AND

  • OR

  • NAND

  • NOR

  • XOR

  • XNOR

Clause

A clause features two (2) operands separated by a comparator, enclosed in square brackets.

  • [X <= Y]

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

Comparator

A comparator is any of the following:

  • <

  • >

  • <=

  • >=

  • =

  • !=

Operand

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

  • 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)

If operands are of different types, an error will be generated.

Creating Clauses

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

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

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

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

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

In addition to the above, a clause operand may include a mathematical manipulation of the field’s value.

Comparison

Users 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:

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

The units of the parameter in the operation depend on the operation or the value of the field’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. This may be numerical, date (days), time (minutes), currency (dollars), etc.

Using the third example above, if field 91 is a date, field 86 must be greater than field 91 minus 2 days.

Summary

A clause operand may also be the sum of two (2) or more field values. This is achieved by the use of the s character, and the list of comma separated fields to be summed enclosed in curly brackets:

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

Framework Examples

Rule for Administration 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)

Rule for Frame Complete:

  • [2123 <= 2135]

    • Base Complete Date (2123) must be less than or equal to Frame Complete (2135)



Rule for Drafting: Drawings (generic) Ordered e.g Contract Drawing Ordered

For rules to work on the generic Admin\Drafting screen you will need to write a rule within the Generic Drafting table that will include a clause for the Drawing Type ID (e.g Contract Dwgs Type ID = -16 in below example), since the generic drawings record may be one of many different types.

  • ([notNull<56>] OR ([17229 != '-16] OR [isNull<17224>]))

    • To enter a Contract Drawings Ordered date, the must be a Colour Selection Complete Date

Note: if the Drawing 'Ordered' field is used on a custom screen e.g. Admin Overview - you will need another rule to ensure it's caught there

Business Rules - Rule Control

A rule belonging to a specific 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 in the f_customRule field

  • 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 specific context (e.g.: region division) in the l_rDiv_id field in the rDiv table, and changes at log on/off. The l_context_id of 0 will apply a rule to all regions/divisions.