Why is the State of a Fact in a Rule Action Inconsistent with the Rule Condition?
The object was modified between the time the rule was activated and the time the rule was fired (executed), and the object was not re-asserted in the Rules Engine. Objects (Java or RL) must be asserted as facts in the Rules Engine before they are used in rule evaluations. When an object that has been asserted as a fact is modified, either in the action of a rule or by something external to the Rules Engine (presumably by the application), the object must be re-asserted in the Rules Engine in order for the current object state to be reflected in the Rules Engine and thus in the rule evaluation. If this is not done, the application and Rules Engine are in an inconsistent state which can lead to unexpected behavior. A Java bean may be written to support PropertyChangeListener so that the Rules Engine can automatically maintain a consistent state when a bean property us update. For more information, see Section 1.3.4.1, “Java Fact Type Definitions”. The one exception to this rule is for an
Related Questions
- What is the rule of Ihram of a woman who puts on socks and gloves? Is it permissible for her to take off what she had put on in the state of Ihram?
- Why does my Health Risk Questionnaire Web site Action Plan state that I must complete the Questionnaire by September 16?
- Why is the State of a Fact in a Rule Action Inconsistent with the Rule Condition?