As part of a requirement, I need to build a Camunda timer management app, where users will be able to suspend/unsuspend running timers etc. I have successfully used the exposed APIs of ManagementService (suspendJobById, setJobDueDate) and I was able to do the magic. Thing is I’m operating on microservices, and all this should be done asynchronously. As a matter of fact the camunda job management (including timers) will be a seperate microservice.
How it’s going
The camunda set-up in the existing microservices infrastructure is a distributed embedded engine, where multiple microservices have access to the same camunda cluster and each microservice handles its own camunda process instances. Now what I need to do is monitor the timer(job) registration/unregistration mechanism so that the app responds to events.
Question is:
Is there any provided event-based API for this (like the CDI event bridge) that I could use to monitor the timer instance lifecycle?
This is quite an interesting use case, i haven’t come across it before but i can think of two ways you might be able to achieve this - assuming you don’t want to be randomly polling the engine looking for changes.
Spring Eventing Bridge - If you’re using spring boot with the embedded engine there’s a way of utilizing Camunda and spring’s own event bridge. I haven’t tried it myself but i think it’s possible to send and receive events like timers being changed through that - Spring Eventing Bridge | docs.camunda.org
History Event Listener - any event that happens in the engine passes through the history event listener. You could create an engine plugin that listens to for the even you’re interested in and then perform whatever action you’re interested in doing then the event you have has be identified. History and Audit Event Log | docs.camunda.org
Let me just mention before elaborating on the issue that my stack is Eclipse MicroProfile project from Eclipse Foundation.
I have tried using the history plugin you mentioned and successfully managed to catch timer events. But I have found out that I need a Thread.sleep() to correlate job related data with process instances, which is quite ugly not to mention bad for performance.
As a result, I once again tried to use CDI event Bridge and couldn’t get the info I need, so I have to ask:
Is there another asynchronous API like CDI-event Bridge where I can have the complete timer job information (due date, activityId, name) the moment the timer is started or expired?
Alternatively, is there a way to use the various services (ManagementService, RuntimeService) to get the timer info I need using the CDI BusinessProcessEvent? Theoretically, I could get this information by using the supplied DelegateTask from the BusinessProcessEvent, but in my case they’re always null.
