Business Rules

Most business rules are evaluated when a particular business object is created or modified and therefore most rules are attached to business objects. Some rules may also be attached to notifications (they are evaluated when a notification is created or received) or to timer events (scheduling rules). A rule consists of a condition (which is optional) and actions. To define a rule you need to specify these conditions and actions using the Rule Language. To make this task simpler AwareIM provides the Context Assistant, which prompts you for the right actions and conditional expressions to use when defining a rule. You can also use the information provided in the AwareIM Rule Language Reference section.

An application that you configure may have many rules. If you want to find a particular rule in the Configuration Tool you can use “Search Rules” functionality – see the Searching Rules section. You can also use various filtering options available in the Rule Collection Editor. The Rule Collection Editor may display all rules in the application or only rules attached to a particular business object or notification – see the “Working with Rule Collection Editor” section.

Quite often you are dealing with the situation when rules need to be evaluated only after the action of the previous rule has been executed, i.e you seem to be dealing with the ordered sequence of rules. However, in AwareIM most rule sequences are un-ordered (except processes that have “Maintain Order” property checked), i.e. AwareIM does not guarantee the order in which rules will be evaluated (see the “Rule Evaluation” section).

One way around this is to use an ordered process, however, this approach is not recommended as the general solution, as the process should not contain any business logic (see Business Rules). The better solution is to get rid of the explicit order and break up an ordered rule sequence into a number of independent rules that get triggered when the value of some attribute or list changes. One way to do this is to introduce the “State” attribute to the object. The “first” rule may set the state to some value and the “second” rule can be made dependent on this value. The “second” rule can then set the state to some other value which the “third” rule will check and so on. Note that although we are using the terms “second”, “third” etc, each rule is independent of other rules as it only depends on whether the conditions that it checks are true or false (it does not care who sets the value of the state attribute and when - as long as the state has a particular value the rule will be evaluated). State attribute is often a good solution to the problem, however, any other trigger will do (for example, you can check whether an object has been added to a list) – as long as one rule sets the trigger and another rule checks it, we can express any ordered sequence as an un-ordered collection of independent rules.

Most rules in AwareIM are un-ordered, i.e. AwareIM does not guarantee the order in which the rules will be evaluated. Consequently, the same rule may be submitted for evaluation several times and so its action may be executed several times as well (see the “Rule Evaluation” section). For actions that modify attribute values this is not a problem, provided that the last execution of the action sets the attribute to the correct value. AwareIM guarantees that this will be the case provided that rules are consistent and independent of one another.

What about rules that perform a different action, for example report errors or request services? Will they be executed several times as well? The answer is no, because AwareIM assigns different priorities to rules invoking such actions to make sure that they are evaluated after the rules that modify attributes (see the “Rule Priorities” section ). Even so, it is probably not a very good idea to execute certain actions from rules attached to business objects without taking special precautions, as the rules will be evaluated every time the object is changed. For example, let us consider the following rule:

IF Account.State = 'Open' THEN 
   CREATE AccountOpeningLetter WITH 
    AccountOpeningLetter.Addressee = Account.Holder 

The way the rule is written the letter to account holder will be created every time the Account object is changed (provided that it is in the “Open” state) – even if changes have nothing to do with the state of the account. This is not what we want. What we really want to do is to create a letter only when the account becomes open. Therefore we have to write our rule as follows:

IF Account.State WAS CHANGED TO 'Open' THEN 
   CREATE AccountOpeningLetter WITH 
    AccountOpeningLetter.Addressee = Account.Holder 

In certain cases it may even be necessary to introduce a state or some other attribute to check whether an action has been performed, for example:

IF Policy.ExpiryDate<=CURRENT_DATE AND Policy.LetterCreated='No' THEN 
   CREATE ExpiryLetter WITH 
    ExpiryLetter.Addressee = Policy.Holder 

Note that it is not necessary to take any precautions when sending e-mails – AwareIM will send all e-mails only after all rules have been evaluated (more precisely, e-mails just like any other notifications are sent when the current transaction is committed – see the “Rules and Transactions” section).

AwareIM Rule Language is the language of rules only – it does not include variables or loops as programming languages do. Consequently, it is not possible to iterate over business objects. How can then an action be performed on several business objects? The answer is that any action is automatically performed on all objects that are in the current context. The context usually contains objects found by a query, so the action is performed on all found objects. For example,

FIND Account WHERE Account.Balance < 100
Account.State='CLOSED' 

The second action that changes the state of the account to CLOSED will be performed on all objects found by the FIND action and so all accounts with balances less than 100 will be closed.

Execution of rules can be checked using the Execution Log and Log Viewer. See the “Execution Log” section.