Register EventListener on JbppmContext

[camunda]

Hi.

Yesterday I was at customer and they did an extension to jbpm where they added the possibility to add EventListener to the JbpmContext (configured via jbpm.cfg.xml).

Today I face a similar problem, it would be interesting to get notified if each event fired inside the engine (basically to catch them and maybe throw the aggregated to some BAM engine).

What do you guys think, include such a feature in jbpm core? I think it is an interesting one without bit complexity. Also the guys from yesterday could provide some code for it (Tom, I heard there is a pending committer status request from them), so maybe it wouldn't be that hard...

Opinions?

Cheers
Bernd

[salaboy21]

Great, let me know if you upload some code to the repository to check it out!

[camunda]

Currently I am waiting for some feedback before committing, but the longer I think about it, the more valuable the feature looks to me...

[thomas.diesler]

This has been taken out of the 1-Jan cut of the API because we did not get to the general notion of Signals + Messages.

Nevertheless, I also think this is a valid concept. Here are the API drafts for it

SignalService
http://www.jboss.org/community/docs/DOC-12891

MessageService
http://www.jboss.org/community/docs/DOC-12889

[kukeltje]

@Bernd:

Yes would be great. Compare this solution to adding actions to each node (or generic events in the processdefinition) that is e.g. needed for SeeWhy.

@Thomas:
I think messages and signals are not necessarily the same as what Bernd proposes. Messages and Signals from BPMN are Business level things, where as what Bernd proposes is more like an extension to the engine itself to make it even more flexible.

[tom.baeyens]

"camunda" wrote:
Hi.

Yesterday I was at customer and they did an extension to jbpm where they added the possibility to add EventListener to the JbpmContext (configured via jbpm.cfg.xml).

Today I face a similar problem, it would be interesting to get notified if each event fired inside the engine (basically to catch them and maybe throw the aggregated to some BAM engine).

What do you guys think, include such a feature in jbpm core? I think it is an interesting one without bit complexity. Also the guys from yesterday could provide some code for it (Tom, I heard there is a pending committer status request from them), so maybe it wouldn't be that hard...

Opinions?

Cheers
Bernd

all our jbpm 3 efforts are now focussed on increasing the stability and test coverage (mainly dbs).

this feature should be discussed in terms of jbpm4. in that context, it might be an option to leverage the environment for that. after a event propagated all the way up to the environment, it could be propagated further on the environment contexts. good idea, but needs some more reflection. performance might become an issue so it should be possible somehow to configure which events are propagated to the environment like that.

[camunda]

@Thomas: I also the events I want to listen for are more inside of the engine (so implementation detail ;-)). But the Listeners you propose also make sense, even if I don't understand the API at this part yet...

@Tom: I expected you to say that ;-) And I agree with you, but for me the situation is not putting effort in jbpm 3 or 4, but to solve the problem in the customer project either by some workarounds around jbpm (in "our" code) or to implement it correctly in the jbpm 3 core. Effort could be maybe the same. So I think it makes more sense to contribute it to jbpm and maybe even gather experiences for jbpm 4. And even jbpm 3 will be around for quite a while I think...

So if you don't vote explicitly against it I would maybe contribute it if it comes to that point in the current project (concept isn't yet fixed), ok?

[tom.baeyens]

regrettably at this point we don't even have the bandwidth to verify the contributions on jbpm3. also we don't yet have the separate branch in place so that we more easily can accept community contributions and validate those before we actually adopt them into the stable branch.

[camunda]

Meaning what exactly in respect to my question?
By the way: Of course I would provide test cases as well...

[camunda]

Okay, here my proposal.

Add to GraphElement:

 /**
 * notify configured external event listeners of fired event.
 *
 * The notification is done BEFORE the event gets processed by jbpm
 * internally (meaning actions are executed), so it is visible
 * to the listeners even if exceptions occur inside of the actions
 * causing the stacktrace to abort
 */
 private void notifyListenerOfEvent(String eventType, ExecutionContext executionContext) {
 EventListenerUtil.notifyListenerOfEvent(eventType, executionContext);
 }

and call this method inside of the "fireAndPropagateEvent" method.

Now my first thought was, that the EventListenerUtil looks up jbpm.cfg.xnml via JbpmConfiguration to see if there is a bean "jbpm.event.listener" configured, e.g.

<bean name="jbpm.event.listener" class="MyEventListener">

Or to create some kind of jbpm event dispatcher to support a list of listeners:

<bean name="jbpm.event.dispatcher" class="org.jbpm.NN">
 <field name="listeners">
 <list>
 <bean class="MyEventListener1" />
 <bean class="MyEventListener2" />
 </list>
 </field>
</bean>

The code isn't hard there, just check in the JbpmConfiguration if the listener is/the listeners are set and if then call the listener.

What do you guys think? What would you prefer, simple one listener (so people with multiple listeners have to implement that themselvers) or multiple listeners?

This is a really powerfull machnism to hook into jbpm and to develop generic solutions around it, e.g. for BAM.... And it is not a big deal. I would like to start on this next week, hopefully we can come to some conclusions here. When finished I can also blog about how I use this to generate the BAM events we need in the project...

Cheers and have a nice weekend
Bernd

[camunda]

Damn it, submitted too early, now in the train (with a bit of fresh air in between) I had two additional thoughts:

1.) I think the single listener would enough. If we want to have something like a dispatcher it can be configured as Listener knowing a list of other listener it notifies.

2.) The EventListener is maybe really not important at the moment. I think the same thing is already supported by hook in an own LoggingService. This LoggingService gets all important events as Log as well, right? Or does anybody already dived deeper into it and knows something which is missing there?
So I can extend the LoggingService to serve as EventListener... I think for my purposes at the moment it should be sufficient. I will check that out on Monday morning....

So I think I started an unnecessary discussion, sorry for that! But finally it helped at least me to come to a solution ;-) Keep you posted about how I meet our BAM requirements...

[camunda]

Okay, to give you the latest update:

For creating the events I need, I implemented an own LoggingService, which keeps a list of ProcessLog objects internally in memory. When closing the LoggingService, I look through these evens and create the necessary BAM events and send them to my BAM service.

One important issue was, to place the LoggingService BEFORE the PersistenceService, by doing so, the LoggingService can still access the HibernateSession (otherwise it would be closed earlier). This works if the loadForUpate methods where called everywhere correctly :-)

But I discussed that implementation with another guy, and we concluded, that the EventListener still is a valuable Feature. Because if you really want to listen for events, it is the right place. Logs are created much later (e.g. during jbpmContext.close) and have different granularity.

What does others think about that?

For my problem I am happy with the LoggingService, for the other project, they patched jbpm already to include the EventListener. But I think it would make sense, at least for jbpm 4.

[tom.baeyens]

i have been thinking of unifying the 3 types of 'events' that we have in jbpm:

* signals (incoming events, incoming from the perspective of the process engine)
* events (internal events)
* process logs (outgoing events)

would it be possible to unify those 3 ? on my first chew, i could not be sure that this would not have disadvantages on the flexibility. but somehow it feels very close...

[tom.baeyens]

...because Bernd, what you describe is actually adding a logging listener to internal events. if we would unify them, then this would be replaced by just adding a generic (incoming, internal and outgoing) event listener.

[tom.baeyens]

Only now i see the second page :-) So you already made the connection to the loggingservice yourself :-)