BPMN Conditional Events

[Schimak Martin]

Hi all,

I am interested whether there already exist plans or discussions for how to support BPMN conditional events. If yes, I would like to inform myself about the status of this discussion. https://app.camunda.com/jira/browse/CAM-14 just states that it is unclear.

Can you give me any further hints?

Martin.

[Daniel Meyer]

Hi Martin,

these are my thoughts:

From the point of view of the workflow engine a conditional event means:
- when the scope of the event (process definition, task, subprocess ...)
is instantiated, I start waiting on the condition,
- when the scope is destroyed i stop waiting on the condition,
- when the condition is fulfilled, the semantics of the event are
executed (cancel activity, interrupt flow scope, concurrent in flow
scope...) and continue along all outgoing sequence flows.

This part is very plain and very simple.

The only remaining question is: how does the workflow engine get
notified that the condition is fulfilled. There I would provide multiple
possibilities:
- Api method (aka external trigger),
- a variable listener which is notified whenever variables visible from
the scope of the condition event are created / changed / deleted and can
then evaluate a condition. Such a listener can be implemented using
JUEL, Groovy, Java ... Bit like sentries in CMMN...
- other ways that people come

That would me my current way of approaching it...

Daniel

[Schimak Martin]

Hi Daniel

> From the point of view of the workflow engine a conditional event means:
> - when the scope of the event (process definition, task, subprocess ...) is instantiated, I start waiting on the condition,
> - when the scope is destroyed i stop waiting on the condition,
> - when the condition is fulfilled, the semantics of the event are executed (cancel activity, interrupt flow scope, concurrent in flow scope...) and continue along all outgoing sequence flows.
>
> This part is very plain and very simple.

Yes.

> The only remaining question is: how does the workflow engine get notified that the condition is fulfilled. There I would provide multiple possibilities:
> - Api method (aka external trigger),
> - a variable listener which is notified whenever variables visible from the scope of the condition event are created / changed / deleted and can then evaluate a condition. Such a listener can be implemented using JUEL, Groovy, Java ... Bit like sentries in CMMN...
> - other ways that people come

Thanks for this information. I like the approach of looking at a BPMN condition as basically being a boolean expression from an implementation perspective. Two things come to my mind here when reading about the variable listener:

First one, as an alternative to actively asking the engine to evaluate a condition, one might also provide the possibility to ask the process engine to regularly „poll“ / evaluate a condition. Depending on circumstances, this might become unfortunate from a performance perspective, but would be very simple to define: a boolean expression plus a polling interval.

Second thing: a BPMN condition can principally trigger several times (start events, non-interrupting boundary events, …) - just as long as we „wait on the condition“. So the question arises: when do we consider a condition to trigger „another“ time? I see two options: either we consider the condition to trigger every time we evaluate it to true. Or we demand, that we need to see a „switch“ and just trigger, if we evaluate the condition to true AND provided we evaluated it to false the last time we checked. My thought is: it might be useful to provide the user both options for the triggering behavior of a condition.

> That would me my current way of approaching it…

So actually it is not as unclear as CAM-14 currently states! :-)

I appreciate your work so much.

Many greetings,
Martin.

[Schimak Martin]

I wrote: "as an alternative to actively asking the engine to evaluate a condition …“ but I actually meant: "as an alternative to evaluating a condition when visible variables change …". But it might also be useful to have the option to actively trigger a condition evaluation via the API.

So to sum that up, we would have three options to notify the engine - but probably not to notify that a condition is fulfilled but maybe rather to ask that the condition should be evaluated: variable in scope changes, actively triggered from outside via API, time based polling/evaluation by the engine. And maybe two options to define the triggering behavior: always or just after the detection of a boolean value "switch".

Many greetings,
Martin.