My first investigations of the new conditional event show me that an “activated” conditional event is internally represented by an event subscription of the new type “conditional”. I have a few questions regarding this.
Is every conditional event (regardless of “flavour” being intermediate, boundary, event sub process, …) internally being represented by such an event subscription - or are there any important differencies in internal representation?
When reading the documentation, it is a bit unclear to me what the role the scope of the variable is regarding the different “flavours” of conditional events. A variable in which scope has to change so that a specific flavour of conditional event actually triggers. Could you clarify this for me, please?
For testing purposes: is there a possibility to explicitely “trigger” a conditional event via the API without actually changing any of the process variables, the condition of a conditional event is listening to? What I mean is something similar to explicitely triggering a timer job via the management service. I know that there is the possibility to “signal” a waiting (intermediate event) execution to move on. But this won’t work for all conditional event “flavours” (like boundary, event sub process, intermediate combined with event based gateway…), would it?
Yes, every conditional event is internally represented as event subscription. But this can change to the next alpha release, see this CAM-6870 ticket.
This can be explained with an example from programming language:
{ //parent scope
//if we set a variable here, this variable is available in all child scopes
{//child scope (parent of there child scope)
//if we set a variable here, this variable is available in all child scopes
//->not in parent or sibling scope
{//child scope
//only available in this scope
}
}
//child scope (sibling of other child)
{
//variable only available in this scope
}
}
The same is this with a process model. See for example the following process model:
Say we stay in UserTask A and we set a variable on process instance level, the variable is available on all conditions.
The event sub process will be executed in this case. If we set a variable on the sub process level the variable is available on the conditions Bcondition and Acondition. The boundary event Bcondition will be triggered. If we set a local variable on A only the Acondition has access to the variable and will be triggered. Hope that makes it more clear.
No there is no API right now. You can set the condition to ${true} and update an existing variable or call ExecutionEntity#dispatchEvent(VariableEvent).
OK, this is totally clear now and will work as I would expect it to work! Many thx! I must say that after having read the documentation it was unclear to me whether I am supposed to set a variable for a boundary event condition always at the local scope of the activity it is attached too… which would have been disappointing for me.
With regards to the event subscriptions: I figure it will be time saving to wait a bit longer until the feature becomes a bit more stable!
I am looking forward to learn about your design decisions until release of 7.6: even if an event subscription might seem to be “unnecessary persistence” for now, I would argue that an intermediate conditional event is a waitstate… and that it should be possible somehow for the Camunda API user to find out that a process instance is waiting at a certain point - and this should be possible not just via consulting history tables, but via consulting runtime tables. But then the question arises: which runtime object can I query for to find out? An event subscription? Something else?
That’s a good rule of thumb. The method RuntimeService#getActivityInstance provides a representation that is in line with BPMN activity instances. Perhaps that is easier usable than executions.
An option, but then I tie my code - which is just interested in the current existence of a specific activityInstance - to the position of the activity in the bpmn scope tree.
No I can’t elaborate on that, actually! I was not aware of the activityInstance.getActivityInstances(activityId) method which was introduced somewhen in 7.3 or 7.4 - I just remembered myself traversing through a painful tree of arrays somewhen before that… and when doing such a thing quickly (with a non-generic traversing approach) the code becomes tied to the position of the activity in the tree. Everything understood and fine now! Many thanks Thorben.
Many thx! I must say that after having read the documentation it was unclear to me whether I am supposed to set a variable for a boundary event condition always at the local scope of the activity it is attached too… which would have been disappointing for me.
I was not aware of the activityInstance.getActivityInstances(activityId) method which was introduced somewhen in 7.3 or 7.4 - I just remembered myself traversing through a painful tree of arrays somewhen before that… and when doing such a thing quickly (with a non-generic traversing approach) the code becomes tied to the position of the activity in the tree. Everything understood and fine now! Many thanks Thorben.