Build Status Maven Central

for the previous version, please go to

Event-based listeners and delegates for camunda.

A note on this extension: the underlying reactor-eventbus was dropped when the reactor framework moved to pivotal afew years ago. This extension works on a fork (see extension/eventbus) of that bus, which unfortunately is not very well tested, it is supposed to work "as is" (and does).

Since the original extension authors meanwhile moved on to work with the camunda spring boot starter and use the spring event bridge to achive the same effect as this extension does, it is not maintained on a regular basis.

TLDR: Use at own risk. It has proven to work in production environments. But if you are on spring-boot: do not use the reactor, use the spring-native event-bridge. And if you want this extension to prosper in the future: contact us and become a maintainer.

What is this about?

This extension provides a process engine plugin that registers Execution- and TaskListeners to all possible elements and all possible events. These listeners then publish their delegates (DelegateTask, DelegateExcution) to an event bus.

Custom implementations that are interested in certain events may register on that bus and will get notified and executed when the registered listeners fire.

Publishing and subscribing uses a topic pattern /camunda/{context}/{type}/{process}/{element}/{event} so it is possible to register on all that happens on the engine or the assignement event of a concrete userTask in a concrete process.

Reference: a similar approach was already done in the engine-cdi module using CDI observers and qualifiers.

Why do I need this?

Using an event bus decouples registration and implementation of listeners. The bpmn file has not to be touched for this. This is useful for implementations that can be considered "aspects" of the engine like task assignment and monitoring.

Instead of registering listeners all over your bpmn files that always call the same rule service to determine the candidate groups of a task or write runtime information to a data source, you just hook into the event bus stream and wait for notification.

While this could be achieved with custom plugins/parselisteners, these share the problem that the engine has to have access to the code of the listeners added. With the decoupling via eventbus, this is avoided.

How is it done?

This extension uses the event bus provided by This bus is fairly advanced and stable and allows separation of event-payload (the DelegateExpression) and event topic, so we do not need any additional qualifiers or concrete types to distinct between "listen to create of task B" or "listen to all events of task A".

Using the extension is straight forward, you need to:


Register a listener that is fired for all "create" events on any user task in the system.

@CamundaSelector(type = "userTask", event = TaskListener.EVENTNAME_CREATE)
public class TaskCreateListener implements TaskListener {

  public TaskCreateListener(EventBus eventBus) {

  public void notify(DelegateTask delegateTask) {

More examples can be found in the sub-module examples.


If you have multiple task listener for an event, per default the task listener from this extension gets called in the end. When setting the following property to true, the reactor task listener get's always called first!

camunda.bpm.reactor.reactor-listener-first-on-user-task: true


This extensions works with delegateTasks and delegateEvents directly. These cannot be used outside the current thread, so the eventBus used is synchronous.

Next Steps