Skip to content
This repository has been archived by the owner on May 4, 2022. It is now read-only.


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Camunda Platform 7 Build project with Maven Maven Central

DEPRECATED: Note that this project is deprecated and archived


for the previous version, please go to

Event-based listeners and delegates for Camunda BPM.

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 achieve 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:

  • access the eventBus instance used in the plugin by calling CamundaReactor.eventBus().
  • Use this bus to register an instance of an appropriate listener and specify the topic parts you are interested in.


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

  • provide extension for CDI (?)
  • use eventbus for message correlation end/start
  • ...