Este contenido no está disponible en el idioma seleccionado.

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);
}
Copy to Clipboard Toggle word wrap

Rule runtime event listener

public interface RuleRuntimeEventListener extends EventListener {
    void objectInserted(ObjectInsertedEvent event);
    void objectUpdated(ObjectUpdatedEvent event);
    void objectDeleted(ObjectDeletedEvent event);
}
Copy to Clipboard Toggle word wrap

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

Red Hat Decision 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 );
   }
});
Copy to Clipboard Toggle word wrap

Red Hat Decision 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() );
Copy to Clipboard Toggle word wrap

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.
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat