Chapter 87. Decision engine event listeners and debug logging

The decision engine generates events when performing activities such as fact insertions and rule executions. If you register event listeners, the decision engine calls every listener when an activity is performed.

Event listeners have methods that correspond to different types of activities. The decision engine passes an event object to each method; this object contains information about the specific activity.

Your code can implement custom event listeners and you can also add and remove registered event listeners. In this way, your code can be notified of decision engine activity, and you can separate logging and auditing work from the core of your application.

The decision engine supports the following event listeners with the following methods:

Agenda event listener

public interface AgendaEventListener
    extends
    EventListener {
    void matchCreated(MatchCreatedEvent event);
    void matchCancelled(MatchCancelledEvent event);
    void beforeMatchFired(BeforeMatchFiredEvent event);
    void afterMatchFired(AfterMatchFiredEvent event);
    void agendaGroupPopped(AgendaGroupPoppedEvent event);
    void agendaGroupPushed(AgendaGroupPushedEvent event);
    void beforeRuleFlowGroupActivated(RuleFlowGroupActivatedEvent event);
    void afterRuleFlowGroupActivated(RuleFlowGroupActivatedEvent event);
    void beforeRuleFlowGroupDeactivated(RuleFlowGroupDeactivatedEvent event);
    void afterRuleFlowGroupDeactivated(RuleFlowGroupDeactivatedEvent event);
}

Rule runtime event listener

public interface RuleRuntimeEventListener extends EventListener {
    void objectInserted(ObjectInsertedEvent event);
    void objectUpdated(ObjectUpdatedEvent event);
    void objectDeleted(ObjectDeletedEvent event);
}

For the definitions of event classes, see the GitHub repository.

Red Hat Process Automation Manager includes default implementations of these listeners: DefaultAgendaEventListener and DefaultRuleRuntimeEventListener. You can extend each of these implementations to monitor specific events.

For example, the following code extends DefaultAgendaEventListener to monitor the AfterMatchFiredEvent event and attaches this listener to a KIE session. The code prints pattern matches when rules are executed (fired):

Example code to monitor and print AfterMatchFiredEvent events in the agenda

ksession.addEventListener( new DefaultAgendaEventListener() {
   public void afterMatchFired(AfterMatchFiredEvent event) {
       super.afterMatchFired( event );
       System.out.println( event );
   }
});

Red Hat Process Automation Manager also includes the following decision engine agenda and rule runtime event listeners for debug logging:

  • DebugAgendaEventListener
  • DebugRuleRuntimeEventListener

These event listeners implement the same supported event-listener methods and include a debug print statement by default. You can add additional monitoring code for a specific supported event.

For example, the following code uses the DebugRuleRuntimeEventListener event listener to monitor and print all working memory (rule runtime) events:

Example code to monitor and print all working memory events

ksession.addEventListener( new DebugRuleRuntimeEventListener() );

87.1. Practices for development of event listeners

The decision engine calls event listeners during rule processing. The calls block the execution of the decision engine. Therefore, the event listener can affect the performance of the decision engine.

To ensure minimal disruption, follow the following guidelines:

  • Any action must be as short as possible.
  • A listener class must not have a state. The decision engine can destroy and re-create a listener class at any time.
  • Do not use logic that relies on the order of execution of different event listeners.
  • Do not include interactions with different entities outside the decision engine within a listener. For example, do not include REST calls for notification of events. An exception is the output of logging information; however, a logging listener must be as simple as possible.
  • You can use a listener to modify the state of the decision engine, for example, to change the values of variables.