Show pageOld revisionsBacklinksBack to top This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. [<10>] ====== 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 //**AwareIM**//. 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 time(( This may not be true if the action was triggered in the middle of the evaluation of an un-ordered collection of rules – see [[2000_concepts:0800_data_processing:0100_rule_evaluation:0700_evaluation_unorder_rule_collections|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. )). 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 //**AwareIM**// 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 //**AwareIM**// 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: - Rules attached to a business object the instance of which has been created or modified.(( 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 [[2000_concepts:0800_data_processing:0100_rule_evaluation:0700_evaluation_unorder_rule_collections|Evaluation of Unordered Rule Collections]]. We will ignore this case for purposes of the current discussion. )) - 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 ''[[ref:a_f:a:create|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: <code aim>ENTER NEW Driver CREATE Policy Policy.State='Calculated' </code> 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 [[2000_concepts:0800_data_processing:0100_rule_evaluation:0400_cross_reference_rules|Cross-reference Rules]] section. Log In