nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Process event bus, extracting the pvm and persistence

tombaeyens

This post summarizes my thoughts (after a weekend of reflection 🙂 ) on the discussions about Process event bus, extracting the pvm and persistence that we had on friday afternoon in the Activiti Community Kickoff Meeting.

Ordered by priority:

1) persistence. If the runtime data can't be properly persisted, there is no point in starting on the other topics.

2) process event bus. Necessary for building up history, so clearly within the 5.0 scope. The only part that I didn't wasn't cleared out in the meeting was if the PVM should include event listeners. This had a small impact on the design of the events. I think it is best to have event listeners as part of the PVM. Another aspect is the name. Since it is one-way, I think the name 'listener' is better then 'bus' I'll work out a proposal in this iteration for ProcessEvent's and ProcessEventListener. You can also build a proposal if you think that is necessary. Before the end of this iteration, we'll discuss and should come to agreement.

3) extracting the pvm is lowest priority and not a target within 5.0 for me. on the way back to belgium, I had a quick look and it seems to me that it is doable. I think we should create a jira issue for it and assign it to the 5.0.rc1. At that time we should evaluate if it is good to do it. If the other more important aspects are properly covered by then, then we can do the library split before 5.0.

Find more posts tagged with

Comments

cstettler

Related to the naming discussion in 2): to my understanding, the event bus is not one-way only (at least not from the point of view of other components plugged into the bus), as e.g. a task assignment module could listen to new task events being fired by the pvm, but could in turn also fire own task assigned events via the event bus. So it is not only the pvm that fires events and thus, other components are not only listeners.

micha_kiener

In my opinion, the naming is essential to start expressing the powerful concept behind the process event bus, so process events and listeners don't express that in its fully extend. The PEB should also be part of the PVM, as the most generic events are generated by the PVM itself, however, the PVM is not the only component creating events.

Second, if extracting the PVM is easy and doable, we should do it as it helps with a clear separation of concerns and modularization as well as additional value to be used on its own. I have doubts that we can really talk of a PVM, if too many things are just woven into it as this is currently the case.

tombaeyens

I still have trouble to see where we put the PEB. The PEB listeners should be configured. Configuration is engine and not pvm. So that part of PEB should go into engine. Whereas on the other hand, the process events are constructed and fired in the pvm. So event creation should go in PVM.

How do you see people subscribe to PEB events in the plain PVM (without the engine) ?

micha_kiener

The PEB itself is part of the PVM, however, it only supports bindings of subscribed components through an API, whereas configuration based binding is only supported within the engine. There is a set of basic events being known and fired by the PVM itself, though not limited to this basic set of event types.
In other words, when I want to use the PVM only (maybe to support my own, simple DSL on top of it), I can subscribe to PEB events by adding my listener through the PEB's API or I could come up with an own configuration handler on top of the PVM and my extensions.

Within the engine, I basically see three options for PEB subscribers:
- registering my own component through the configuration (e.g. Spring namespace handler supporting this feature)
- registering my own component through a plugin mechanism (we still would have to discuss its architecture though)
- during runtime, by adding my own component to the PEB through its API

tombaeyens

when I want to use the PVM only (maybe to support my own, simple DSL on top of it), I can subscribe to PEB events by adding my listener through the PEB's API

Would this come down to a static object/method?
Or would the listeners subscription methods be available on a ProcessDefinition?
Or some other way?