new community extension proposal: camunda-bpm-reactor - event based process models

154 views
Skip to first unread message

Jan Galinski

unread,
Nov 11, 2015, 11:11:07 AM11/11/15
to camunda BPM platform contributors
Hi

I am looking for a sponsor for a new extension I am working on.

https://github.com/jangalinski/camunda-bpm-reactor

Since I worked with the somewhat limited event/subscribe mechanism in the engine-cdi module I had this idea of making some couplings of model and code more "aspect-oriented". If for example (see our skill based routing showcase) I always call the same rule service to determine candidate groups, why do I have to add a listener to every task in every model.
This can be achieved by using a parse listener to programmatically add listeners to every element. Problem: now the engine has to know the code of the listener, otherwise we get a CNFE. If we could decouple engine and listener, we would be safe and could use whatevercode we like to implement the functionality,as long as we have access to the eventBus the engine is publishing to.

Thats where this extension comes into play:

I used the EventBus from projectreactor.io. Its a really cool project and mainly focusses on RxJava, async streams and so on, but they also have the rather simple bus in place that allows to separate event-topic and event-payload. Other then with the engine-cdi approach, I do not need qualifiers, I use a topic URI:

/camunda/{type}/{process}/{element}/{event}

When the engine publishes an task create event, it uses /camunda/userTask/Process_1/UserTask_2/create and wraps the delegateTask to a reactor Event<DelegateTask>.

I now can have multiple subsribers to this event:

leaving everything unspecified "/camunda/{type}/{process}/{element}/{event}" means: I get notified for everything that happens

if I am only interested in task creations, I subsribe to /camunda/userTask/{process}/{element}/create, now I get all task create events for all processes and tasks

and if i am interested in the very task mentioned above, I use the full topic: /camunda/userTask/Process_1/UserTask_2/create

Of course this can easily be configured via annotations:


@CamundaSelector(type = "userTask", event = TaskListener.EVENTNAME_CREATE)
public class TaskCreateListener extends SubscriberTaskListener {
 
  public TaskCreateListener() {
    register(CamundaReactor.eventBus());
  }

  @Override
  public void notify(DelegateTask delegateTask) {
 ....
  }
}



I got this pretty far, we are planning to use this approach in production. I know you guys are busy with the 7.4, but I would be happy if you could have a look into it (there are tests and a small example project available) and give me your feedback.
And I hope that I will find a sponsor who helps me bringing this over to the camunda repo as a community extension. I would be also glad if anyone  wants to help me on this, I could use an additional pair of eyes and input.


Thanks
Jan

Rob P

unread,
Nov 17, 2015, 5:37:03 AM11/17/15
to camunda BPM platform contributors
Hi Jan,

Interesting idea. I really like these event driven, extensible architectures. Are you aware of AWS lambda functions? If not, have a quick look at AWS SNS and Lambda functions (http://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html). The reason I say this is, perhaps you could consider making the pattern pluggable to use different realisations of the pattern.

regards

Rob

Jan Galinski

unread,
Nov 17, 2015, 7:38:57 AM11/17/15
to camunda BPM platform contributors
Hi Rob

glad you like it. Judging from a very short glance at the aws lambdas, I would say these are different concepts ... I am addressing Java eventing inside the engine, or at least in the same VM as the engine. Using the camunda delegates (delegateTask, delegateExecution) directly, I am forced to use synchronous event dispatching (same thread). I cannot see how this would be possible to combine with the aws stuff.

Of course you could implement custom listeners in a plugin that communicate with the outside world on process lifecycle events, but that would be a different approach. For that, you could easily reuse my "RegisterAll" parse listener [1].

If you want to detach service implementation from the process implementation, have a look at the new camunda external tasks: http://stage.docs.camunda.org/manual/develop/user-guide/process-engine/external-tasks/  I would imagine they fit better with the aws concept.

cu
Jan


[1] https://github.com/jangalinski/camunda-bpm-reactor/blob/master/extension/core/src/main/java/org/camunda/bpm/extension/reactor/plugin/RegisterAllBpmnParseListener.java

Rob P

unread,
Nov 22, 2015, 10:05:39 PM11/22/15
to camunda BPM platform contributors
Hi Jan,

thanks for the response.

The common abstraction I had in mind was an event stream and an event handler. Hence in my case I was interested in the scale AWS offers. I suspect in your case you are wanting inline with the JVM.

Hence what I am alluding to is if the pattern is an event stream and handler, then Id advocate a plugabble approach such that inline or cloud is potentially supported.

regards

Rob

Jan Galinski

unread,
Jan 13, 2016, 10:19:23 AM1/13/16
to camunda BPM platform contributors
Ping ....

I didn't get any feedback from the camunda guys so far ... I think this is really ool stuff and would love to see this published as a community extension.
What do you think?

Philipp Ossler

unread,
Jan 14, 2016, 2:27:17 AM1/14/16
to camunda BPM platform contributors
Hi Jan,

I am sorry for the missing feedback but we were a bit busy. I looked at your proposal and I think it is a cool idea, too. I will have a closer look next week and give you feedback.

Greetings,
Philipp

Jan Galinski

unread,
Jan 14, 2016, 4:37:01 AM1/14/16
to camunda BPM platform contributors
Thanks, Philipp. Looking forward to it.
Reply all
Reply to author
Forward
0 new messages