jangalinski
commented
6 years ago Hi ... basically, using any eventing mechansim is quite easy. It's separated in three parts: publishing and subcribe and handle.
Publishing is done by Using a custom BpmnParseListener, so when camunda reads a bpmn xml, it adds listeners programmatically (the same listeners you can define directly in the modeler). The trick is to register listeners for every possible event. See https://github.com/camunda/camunda-bpm-reactor/blob/master/extension/core/src/main/java/org/camunda/bpm/extension/reactor/plugin/parse/RegisterAllBpmnParseListener.java. If you just pass TaskListener and ExecutionListener implementations that publish to an osgi bus, you are done.
The third step "handle" is also easy, you just need a Listener instance that can work ith the passed delegate.
The second step "subscription" is the tricky one. How do you filter the DelegateTask/DelegateExecution events, so that you can limit your Handler to only work on "start" events, only work for a certain process and so on. Here the reactor-eventbus has the great feature of supporting topic based subscribtions, leveraged by the @CamundaSelector annotation. It seams to be a unique feature of the reactur-bus, I didn't find any event bus solution with a similar behavior.
I already worked with the spring eventing which supports conditional subscriptions, but its not as nice. I do not know the OSGI bus, but I guess that will be the tricky part to solve.
Important: The delegate instances that camunda hands to listeners are dependend on the thread-scope, so you must never work with async event handling.
I have one crazy idea in mind: expose the camundaSelector mechanism as api and then use code generation to create specific subscription beans, which would allow to simply replace the underlying event bus, buts that's far from being implemented and not my current focus.
I am very interested in any progress you make, so please feel free to keep me updated.
Hi, this is just an idea as I came across this because I might need something here for a separate auditing (among others).
As I am pretty much living in OSGi exclusively, and due to the fact that OSGi comes with an event system at its very core, I was wondering whether you would see anything against it.
Some pointers for where exactly to start a PoC implementation here would be great.