Business Rules in the Rules Engine

Previous Next

The purpose of a USoft Rules Engine is to :

•Implement business rules in application data whenever a client attempts to enter, change, or remove data.

•Provide business data thus implemented, that is: provide data that have a high level of data quality because they are subjected to business rule implementation.

This help topic is a primer in business rules as a key concept. Later sections provide in-depth background on the workings of the USoft Rules Engine.

collapseBusiness rules as a structuring concept

Business rules state such things as:

•What is not allowed in given situations.

•The intended behavior: how to react to business events and situations.

•How results are calculated, for example the price of an order.

For example, a rule can state that a customer needs a certain level of credit when placing a large order, or that a customer should always receive confirmation of an order being placed.

USoft Rules Engines are based on the premise that business rules, in the sense of OMG's SBVR (Semantics of Business Vocabulary and Rules) standard, are the principal format that an organisation (knowingly or implicitly) uses to define how it works, how it wants to do business, and how it serves its customers or stakeholders. Therefore, entire business-critical information systems or system components can be realised and maintained with essentially just business rules as their input.
collapseKey benefits of rules-based systems

Key benefits of rules-based systems include:

SPOD

Single Point Of Definition. Business rule and implementations are defined and stored only once in a central repository.

Automatic rules activation

A Rules Engine is responsible for determining which rules must be evaluated when, and in what sequence. Lower-level coding of rule activation logic is no longer required.

Declarative tooling

The development platform allows you to set trivial aspects of business systems declaratively, to prevent non-trivial rules from being swamped by trivial rules such as a data element being mandatory.

Modularity

Rule implementations are indepedent of database, middleware and GUI specifics of the IT context where they are deployed and also largely independent on the implementation of neighbouring rules.

Support for Agile change

Rule change is easier because individual, modular implementations map directly to validated rule specifications.

Cross-referencing capability

Cross-references between rules and the conceptual model make it easy to find and retrieve rules and to assess the impact of any change.
collapseA business rule typology

Different types of business rule can be distinguished:

Instruction rules

Instruction rules tell operators what must be done when a specific business event occurs at some point in a process. An instruction rule could detail what must be done when a client cancels an order. An instruction rule may take the form of a paragraph in a user manual, a notice, or an explanatory text in a computer screen.

 

The existence of an instruction rule is a sign that some required rules-based design is not fully implemented (automated) in an application.

Restriction rules

Restriction rules define the constraints, in the narrow sense of "restrictions", to which information in the system must be subjected. They ensure that invalid information does not enter the system.

Typical examples are minimum values, illegal combinations of values or compulsory combinations of values. An example of a compulsory combination could be: "An address that has a post-office box number must also have a ZIP code for this post-office box".

Restriction rules define allowed states and all allowed transitions in the information system.

A special category of restriction rule are rules that restrict a person's access to computer resources on the basis of roles associated with that person (authorisation rules).

Behaviour rules

Behaviour rules express how a system should behave in given situations. They state what the system should do automatically.

 

An example of a behaviour rule is that, in a specific setting, a system must automatically retrieve and then produce on a screen a list of all available options that correspond to a set of user requirements.

Deduction rules

Deduction rules state how information must be derived or calculated from other information.

 

Deduction rules are a special kind of behaviour rules.

 

Presentation rules

Presentation rules state how a system must present itself to human users in terms of the organisation of screens, the behavior of fields, buttons and other controls, prompts and texts used in the screens, and overall graphic design.

 

Examples include: "All primary keys should be presented with a blue border on the screens.

Order-handling information and order-price information should be clearly situated together on the screen."
collapseBusiness rule implementation examples

Some business rules are implemented directly in the data model. An example is a rule that each Customer must have a registered Bank Account that is implemented by declaring, in the Customer table, a column Bank Account with the attribute Mandatory = Yes.

Many business rules in USoft, however, are defined by SQL statements that are technically referrred to in USoft Definer as constraints. Below are 2 examples.

Example Rule 1

A Customer cannot withdraw money if their account is overdrawn or the account has been frozen.

The precise conditions are: the sum of the TRANSACTIONS is less than 0 or the ACCOUNT_STATUS is Blocked.

Implementation:

SELECT   '' RESTRICT

FROM     account a

WHERE    0 > 

(    

         SELECT    SUM( t.txn_amount )

         FROM      transaction t

         WHERE     a.account_id = t.account_id

)

OR       a.account_status = 'BLOCKED'

 

 

This business rule is a restrictive type of constraint. It affects two database objects. This rule would ensure that the situation (described above) would never be possible.

This business rule is checked regardless how these transactions enter the system (e.g. direct entry, background process, or batch process).

Also, this business rule is checked regardless of how the rule is broken (e.g. adding a new transaction, changing the amount of any transaction, or setting the account to frozen).

 

Example Rule 2

Customers are charged an ATM transaction fee of $1.00. If the customer has generated more than 10 ATM transactions since the last statement, ATM transaction fees would be waived.

Implementation:

INSERT INTO transaction_fee

(

         account_id

,        txn_amoun

,        txn_date

,        txn_fee_id

)

SELECT   account_id

,        1

,        SYSDATE

,        1

FROM     transaction t

WHERE    OLD( txn_id ) IS NULL

AND      10 >

(

         SELECT     COUNT(*)

         FROM       transaction_fee tf, account a

         WHERE      tf.txn_date   > a.last_statement_date

         AND        tf_account_id = a.account_id

         AND        tf_account_id = t.account_id

)

 

 

This Rule is behavioral, corrective. If a transaction is generated, then the Rule will check to see if 10 transaction fees have already been created since the last statement date. If less than 10 have been created, the Rule will create a new transaction fee to go along with the transaction the user has just entered.