In 7.9 with conditional start events, how are multiple variables used?
in the docs: https://docs.camunda.org/manual/7.9/reference/bpmn20/events/conditional-events/#conditional-start-event (and the api docs for the /condition/evaluate endpoint) there is examples and references for submitting multiple variables. But based on the examples it appears that only a single variable can be caught and evaluated, per condition start event ?
(the workaround seems to be to submit a JSON variable and using scripting to evaluate it)
@camunda is there a way to eval the all of the variables being submitted?
After a little further testing:
the answer is:
execution is evailable within the scripting env of the start event, meaning you can do
execution.getVariables() for a map of all of the vars and then eval your vars based on the script to return True of false
Building on this:
How does Conditional Start Events scale?
Assuming you are not providing a process definition key as a filter option,
does Conditional Start Events essentially loop through every definition (even versions of defs?) and execute the expression or script?
The evaluation of start conditions works (behind the scenes) based on event subscriptions.
During the deployment if the process contains conditional start event, an conditional event subscription will be created (table ACT_RU_EVENT_SUBSCR).
When you trigger condition/evaluate each of the event subscriptions (if you don’t provide process definition id) will be called and try to evaluate the conditions. The successfully evaluated conditions will trigger process instances.
Definitely not , usually it has only one conditional event subscription per process definition (*if the process contains conditional start event).
Hope that helps.
@yana.vasileva this means that it is not possible to activate different versions of a process def using Conditional Starts? We should treat conditional starts as starting by Process Key?
it is possible if you specify their process definition id
Sure, but that is a single value input, meaning you would have to know all of the process def IDs upfront.
Unless you are using process definition IDs as a filter for eval of a conditionEvalBuilder/Condition API, only the most recent version definition will be evaluated (similar to how Start By Process Def Key functions in the Rest API, except we are talking about specific def IDs)
Event Subscriptions are created during deployment, and the subscription will only be for the most recent version of the process definition
If a Condition Eval Builder or Rest API equiv (/condition) is not provided a process ID, then all process definitions will be eval for the condition. This has scale considerations as the eval of the script s or EL can have a compounding effect for response times in the API when the Camunda Engine has a large number of process definitions with Conditional Start Events.
Your summary is pretty much accurate.
I want to add couple of things:
1/. In the engine, we usually work with the latest version of the process definition, so we stick to this behavior with conditional start event. In the other cases (which are rare or the process need to be deployed with other process definition key) when you need to work with another version you need to specify it somehow, so I guess this is not a big overhead to point the needed process definition id.
Also the event subscriptions work the same for messages.
3/. The evaluations could be “optimized” if you provide a variable name together with the condition. If you do that, the condition will be evaluated only in case the specified variable presents in the provided variables with which the evaluation was trigger.
Please share your thoughts considering the above.