Process Event Bus in Activiti Engine

[cstettler]

Dear Activiti community,

I'd like to get your feedback on the idea of having a process event bus component as part of the Activiti engine.

The process event bus is a lightweight and extensible "message bus" that allows for registering to and receiving events with rich context information from the Activiti engine and other Activiti components such as the deployment mechanism, the repository or the identity management (so not only events directly resulting from the pvm / while executing a process instance would be fired, but also events from other components).

Possible events that could/should be fired:
- starting and ending a process instance / activity instance
- receiving events/signals from external systems
- creating, assigning, delegating, completing a (user) task
- deploying a new process definition (version)
- creating / manipulating users
- starting / stopping the engine

Based on such events, the following use cases could be supported:
- process history / process execution statistics
- audit log
- external task management
- process inspection / diagnosis / debugging
- process simulation

In short, the process event bus should support the following mechanisms:
- register/unregister event listeners for specific event types
- possibility to fire events from specific activities and service components
- possibility to trigger custom events out of the process itself
- extensible event type hierarchy
- support for enabling/disabling specific types of events

We see that concept as an integral part of the Activit engine and a crucial and powerful option to integrate Activit into various environments and to extend the engine with higher-level, value-added components. While developing edoras workflow for customer projects in the past, we heavily relied on the concept of the process event bus (even for core technical aspects like persistence or security), and we learned this to be a powerful concept for implementing specific customer requirements such as connecting to an existing auditing system or feeding a management cockpit application in a "clean" way based on a well-designed, generic extension point.

The branch "chst-history" contains both a process event bus spike and an simple implementation of a process history based on events received from the process event bus. Please note that this branch does not include the major refactorings that have been made on the trunk during the last few days, but the concepts are still valid. Essential classes can be found in modules/activiti-engine/src/main/java/org/activiti/pvm/event. Regarding the new pvm approach developed on the trunk, the process event bus could register itself with the low-level event mechanism provided by the pvm, enrich these low-level events with the required semantics and propagate them to the registered process event bus listeners.

My questions for you:
- what is your opinion regarding such a process event bus component as part of the Activiti engine?
- do you see any specific pros and cons for having a process event bus in Activiti?
- do you see additional use cases based on your experiences and plans?
- what other event types would you expect to see?

Your valuable feedback is highly appreciated!

Regards,
Christian

[micha_kiener]

As we want Activiti being adopted not only by developers, but also by BPM product vendors, ISVs and others, the Process Event Bus is a great mechanism for loosely coupled extensions to the engine.

Even in a project scenario where specific requirements are needed, the PEB supports an easy way of extending the core functionality given by the Activiti engine.

As an addition, we used the PEB for runtime SLA management, whereas we tracked the generation of process instances and task creation / completion using events on the bus and calculated the time they used in comparison with the SLA agreed with the customer. That could be done totally loosely coupled from the engine in a generic way.

[trademak]

I really like the idea of the process event bus.
A high-class BPM engine should have a solid and clear way of handling events and this is a good solution.
I think it would also be nice if you can fire custom events and specific points in a BPMN proces.
This can then be used to create all kinds of process reports.
It would also be nice if process variables can be part of the event message.

Best regards,

Tijs

[tombaeyens]

I'm mostly interested to know the concrete use cases for which this generic mechanism is necessary.

Currently in the process execution, we have static events being fired to avoid lots of unnecessary object creation.  But this means that the event mechanism has to be process execution aware.  Because we pass the execution as a parameter to the listener.  So in the current event mechanism, listeners can access the process variables because they have access to the execution.  And if you don't access the variables, they are not loaded from the db.

In Micha's proposal, the difference is that the event listener mechanism is more generic (like e.g. the java util listener).  So that it can also be used for other situations then only for process execution.

In the approach that I take, we build specific listeners for each purpose and that way, the event names can be static.  And the context can be derived from the specific object like execution or task.

If companies want to add a generic layer, then that should be possible.  In that case, the generic process event bus could listen to e.g. all process execution events, all task events and maybe even more events.  Then a full event object could be instantiated and dispatched in the generic process event bus.  But imo, the instantiation of these event objects and the generic event bus should be optional.  As for now, I don't see the use cases that mandate or justify such a generic approach.

[kurt]

Process Event Bus - the real innovation of Activiti

I have build a rule based process engine and i have implemented such an event bus - but I didn´t call it PEB.
Following features could integrated in a proper way:
- logging of all engine events
- visualization of rule / process engine states with SVG
- integration of application specific task assignment implementation
- debugging support of the engine
- …..

For my opinion, the PEB is the key feature for lightweight process engine and für powerfull adaptability!

"unnecessary object creation"
if no event listener is registered, no event object must be created.

"If companies want to add a generic layer, then that should be possible"
In real world situations most of companies will really need this generic event mechanism.

Best regards

Kurt

[cmuelder]

hi tom,

from our point of view regarding the main business processes for data exchange in the utilities market, there are always additional things that have to be done. E.g. if we receive mails to start a process, this mail needs to be copied to other folders or send to other people. If a process instance is finished, i could trigger the archiving of the relevant data.

These "activities" might be interesting, but i don´t want to model those for our main business processes.

[tombaeyens]

Christian, how do you want to subscribe to those events then?  In the process definition?  or in the Activiti Engine configuration?  or does this question miss your point?