Hide Forgot
Affects: Documentation (Ref Guide, User Guide, etc.) Date of First Response: 2009-03-18 11:23:25 project_key: SOA A clarification is needed for this section of the JBoss Rules Guide. "2.5.4.3. Retraction Agenda groups are a handy way to create a "flow" between grouped rules. " The previous paragraph indicated that a flow between rules cannot be relied on. Are we saying that the flow between groups is a way around that limitation?
Darrin - I don't see the text that you list in the description of this JIRA. What I see in the Rules guide is: 2.5.7.2. Agenda Groups Sometimes known as "modules" in CLIPS terminology, Agenda groups are a way to partition the activation of rules on the agenda. At any one time, only one group has "focus" which means that only the activations for rules in that group will take effect. You can also "auto focus" a rule, causing its agenda group to gain "focus" when that rule's conditions are true. Agenda groups are a way to create a "flow" between grouped rules. You can switch the group which has focus either from within the rule engine, or from the API. If your rules have a clear need for multiple "phases" or "sequences" of processing, agenda groups can be used for this purpose. 2.5.4.3. Retraction "Retraction" is when you retract a fact from the Working Memory, which means it will no longer track and match that fact, and any rules that are activated and dependent on that fact will be cancelled. Note that it is possible to have rules that depend on the "non existence" of a fact, in which case retracting a fact may cause a rule to activate (see the 'not' and 'exist' keywords). Retraction is done using the FactHandle that was returned during the assert.
copy/paste FAIL! :-(
A clarification was requested here by QE as these two statements seem to be at odds with each other. Perhaps the term "flow" is being used for two different concepts here? Can someone expand on what is meant exactly in each circumstance? Given that there is an actual Rules feature called RuleFlow perhaps the term shouldn't be used in the Rules documentation at all outside of that feature to avoid ambiguity. Section 2.5.7.1 Conflict Resolution states: "As a general rule, it is a good idea not to count on the rules firing in any particular order, and try and author the rules without worrying about a "flow" where the order matters." Section 2.5.7.2 Agenda Groups states: "Agenda groups are a way to create a "flow" between grouped rules."
Emailed Len for more info and got "Hi Neil - yes - on the 2nd one: Section 2.5.7.2 Agenda Groups states: "Agenda groups are a way to create a "flow" between grouped rules." Does this allow the user to set up a specific order of the rules running? --Len"
To clarify the statements, one should not count on an ***individual rule*** firing order, because that is not the way business rules should be written. Although, rules engines have several features that allow *higher level* control on the firing order of ***groups of rules***. Such features include (but are not limited to): * conflict resolution strategies: like salience, recency, etc * rule groups that allow the user to define groups of related rules: agenda groups, activation groups and ruleflow groups So, for instance, inside a given agenda-group, the user should not count on rule A firing before B (if he is not using some other conflict resolution strategy like salience), BUT he can define flows of groups of rules where rules from agenda-group G1 (or ruleflow-group) will fire before rules from agenda-group G2, etc. Hope it helps, Edson
Clarified text as follows: "Although it is sometimes unavoidable, you should avoid relying on your rules being fired in a specific order. Remember that you should not be authoring rules as though they are steps in a imperative process." "Agenda Groups are commonly used to define one or more subsets of rules that apply to specific circumstances, such as phases of processing, and to control when these sets of rules apply."