Hello there,
I’m starting with Camunda 7.14.0 migrating from Activiti 6.0.0 and I’m running into some difficulties to migrate our engine-wide event listeners to something that works in Camunda in a similar fashion.
Our application is a standalone spring based one and my initial idea was to add the ProcessEngine to the context using a SpringProcessEngineConfiguration as configuration. This seems to work and my preliminary tests are running.

But I find no way to set global listeners like in Activiti. I’ve read that I could subclass ProcessApplication and implement for instance the getExecutionListener method. I tried the following:

    @ProcessApplication
    private static class MyProcessApplication extends SpringProcessApplication {
        @Override
        public ExecutionListener getExecutionListener() {
            return new ExecutionListener() {
                public void notify(DelegateExecution execution) throws Exception {
                    LOGGER.info("Got execution {}", execution);
                    //TODO: Check on the execution information
                    execution.removeVariable("objectId");
Define the ProcessEngine as a spring bean and therefore use the ManagedProcessEngineFactoryBean as the factory for the processEngine (since it seems to be the way to have control from the context of the ProcessEngine creation)
       @Bean
        public SpringProcessEngineConfiguration processEngineConfiguration() {
            SpringProcessEngineConfiguration processEngineConfiguration = new SpringProcessEngineConfiguration();
            processEngineConfiguration.setDataSource(dataSource());
            processEngineConfiguration.setProcessEngineName("default");
            processEngineConfiguration.setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_TRUE);
            processEngineConfiguration.setTransactionManager(transactionManager());
            processEngineConfiguration.setJobExecutorActivate(true);
            processEngineConfiguration.setExpressionManager(new SpringExpressionManager(context, null));
            return processEngineConfiguration;
        @Bean
        public ManagedProcessEngineFactoryBean engineFactory(SpringProcessEngineConfiguration engineConfiguration) {
            ManagedProcessEngineFactoryBean factoryBean = new ManagedProcessEngineFactoryBean();
            factoryBean.setProcessEngineConfiguration(engineConfiguration);
            return factoryBean;
Add an empty processes.xml in the META-INF directory
I created a simple workflow with start node, service task node and end node and even though it runs on my test case, my code returned by getExecutionListener never gets called.
My questions are:
What am I doing wrong so that the execution listener is not invoked upon workflow execution?
Is there any other recommended way to achieve the same result without using a ProcessApplication? I would prefer to do the bootstrap of the workflows as part of the spring context initialization so that everything is in the same place so my initial aim would be to intercept on the ProcessEngine itself if that is ever possible.
My main aim here is to listen on completion and cancelled process instance events, but I don’t want to add the listeners to every BPM process definition.
I’m attaching the test code I’m currently using.
Thanks!

Manuel
CamundaEngineTest.java (6.8 KB)
              
Hello again,
just a shorter and easier to answer (I hope) related question:

Is there support in Camunda BPM to set a global listener and react to events like workflow cancellation and/or finalization?
Thanks and best regards

Manuel
              
Gottach,
Well one thing you could do is build an engine plugin that is a composite class of the history event handler

image746×532 71.1 KB
You could then intercept any events from the engine and run custom code based on the event. You can read more about that in the docs.
              
Thanks a lot for the suggestion Niall, but I’m afraid the events are not specific enough for my needs.

The approach works and I’m getting events from the engine, problem is that for a workflow cancelation, I get just something like this:
09:16:28.361 [main] INFO c.i.t.g.c.CamundaEngineTest - Got event of type class org.camunda.bpm.engine.impl.history.event.HistoricTaskInstanceEventEntity with content HistoricTaskInstanceEventEntity[taskId7, assignee=null, owner=null, name=The Nice User Task, description=null, dueDate=null, followUpDate=null, priority=50, parentTaskId=null, deleteReason=Testing, taskDefinitionKey=userTask, durationInMillis=null, startTime=Fri Dec 04 09:16:28 CET 2020, endTime=Fri Dec 04 09:16:28 CET 2020, id=7, eventType=complete, executionId=4, processDefinitionId=UserTask:1:3, rootProcessInstanceId=4, processInstanceId=4, activityInstanceId=userTask:6, tenantId=null]
This is a cancellation happening as result of calling

RuntimeService.deleteProcessInstance for a process instance where the execution reached an user task. My problem is: How can I tell whether a cancellation is taking place? I’m afraid the event is not specific enough, is it? Or am I missing something?
              
Some new findings about this topic:

The reason why my ProcessApplication was not receiving task or execution events is because I was not registering a ProcessApplicationEventListenerPlugin in the process engine configuration. Once that was done, I started receiving events as expected.

But still I don’t find a way to clearly identify if a process instance is cancelled. I haven’t seen any event I can directly relate to that. How could I do that with Camunda?

Additionally I would find a way to react when a process instance execution finishes.
              
Hi Rob,

thanks a lot for the suggestion. But ours is currently a spring application (not spring boot) and I wouldn’t like to add spring-boot just to be able to have event handling working as expected. On the other side, after enabling the ProcessApplicationEventListenerPlugin in the process application I’m getting execution and task events on the ProcessApplication listeners and I guess these events are the same I would get using the Spring Eventing Bridge approach, right?

I’m still trying to figure out how to clearly know whether a workflow was cancelled or finished by looking at the existing events though.