Information Technology Reference
In-Depth Information
do so. In order to communicate information back and forth from the process memory to
the rule memory, we need to configure event listeners to populate relevant information
changes from one component to the other. Luckily for us, if we want to automatically add
a process instance to the working memory (and communicate its internal changes to it for
reevaluation when necessary), you can add a particular event listener called
RuleAwareProcessEventLister
:
ksession.addEventListener(new
RuleAwareProcessEventLister());
This listener will make sure that when a process instance is added, changed, or removed,
it gets inserted, updated, or deleted from the rule memory. Note that it finishes with the
word
Lister
and not
Listener
. This is not a typo in the topic, but in the code itself,
and it has been maintained like this for backward compatibility issues.
Another important configuration that we need to be aware of is related to the use of rule-
flow groups. Whenever we enter a Business Rule task or an ad hoc process, the KIE ses-
sion will not fire all the rules associated with those ruleflow groups automatically. All it
will do is notify the internal structure of the KIE session that the ruleflow group is activ-
ated, and the user needs to decide whether and when they should fire all the rules. In the
majority of cases, we want to fire all rules activated in a ruleflow group when we reach a
Business Rule task or an ad hoc subprocess. In order to do so, we have a method in the
AgendaEventListener
interface to take specific actions after a ruleflow group is ac-
tivated, and we can invoke a
fireAllRules
method inside it:
ksession.addEventListener(new DefaultAgendaEventListener() {
public void
afterRuleFlowGroupActivated(RuleFlowGroupActivatedEvent
event) {
KieSession kses = (KieSession)
event.getKieRuntime();
kses.fireAllRules();
}
});
With these event listeners, rules from a ruleflow group can be invoked and fired from a
process instance.
