Action Execution

Before an action triggered by a rule is executed the system’s data is assumed to be in a stable state. The “data” here means the entire collection of data available– all instances of all business objects stored in the database or in some other storage media known to Aware IM. A stable state means that all the data is consistent and nothing is happening – the state of the system is “fixed” at this moment in time1).

An action may disturb the stable state of the system by doing one of the following:

  • Creating a new instance of some business object
  • Modifying the existing instance of some business object

After the disturbance occurs Aware IM starts checking if there are rules defined anywhere in the system that react to the creation or modification of the business object instance. If that is the case Aware IM starts evaluation of such rules. These rules in turn may create or modify other instances of business objects and cause other disturbances and so on – thus starting a chain reaction that stops only when there are no rules to evaluate any more, in which case the system moves to a stable state again (but this state is different from the previous state as the the data is probably different).

We said above that if there are rules anywhere in the system that react to the creation or modification of the business object instance, they are evaluated. What does “anywhere in the system” mean here? It means the following:

  1. Rules attached to a business object the instance of which has been created or modified.2)
  2. Rules attached to other business objects that refer to the business object instance that has been created or modified.

The first set of rules has already been mentioned before – whenever a new instance of a business object is being created or the existing instance is being modified, and there are rules attached to this business object, they are evaluated. In the example of the previous section rules attached to the Driver business object are evaluated after the form has been filled out (this is when the instance of the Driver object is created in the system). Rules attached to the Policy business object are evaluated immediately after the CREATE action creates a new instance of the Policy object. Let us suppose now that we modify our process to add an action that sets the state of the policy after it has been created, so the process now looks like this:

ENTER NEW Driver
CREATE Policy
 Policy.State='Calculated' 

The action in the third rule unconditionally modifies the attribute of the Policy object – this causes the rules attached to the Policy object to be evaluated again.

The second set of rules (those rules that refer to the instance of the business object that has been created or modified) is called cross-reference rules. An explanation of what these are, are given in the Cross-reference Rules section.


1)
This may not be true if the action was triggered in the middle of the evaluation of an un-ordered collection of rules – see Evaluation of Unordered Rule Collections. In this section, however, we will assume for simplicity that the state of the system is always stable prior to the execution of an action.
2)
This does not apply to the instance of a business object the rules of which are already being evaluated as part of an un-ordered collection of rules - see Evaluation of Unordered Rule Collections. We will ignore this case for purposes of the current discussion.
  • Last modified: 2022/09/13 18:15