Syntactic validation of Expressions and DelegateExpressions

I am currently implementing some use case specific validation of process diagrams. Mostly this involves validating the contents of ‘Properties’ ‘Form keys’ "Data assocications’ etc.

To implement the validators I am using the new 7.6 validation API. This eases the implementation, as you do not have to worry about how to iterate over ModelElement’s and provides some validation context.

One thing I would like to validate is the syntax of the Expressions and DelegateExpressions that are in the diagrams. I’ve been searching the complete Camunda API, and currently cannot find anything that helps in this regard. The only time expressions are validated is when they are being executed!

Obviously there is a limit to what can be statically validated without executing the expressions (halting problem!). In particular the static analysis does not know what variables will be set in the execution context. My aim is to validate at least the EL syntax and to provide some assistance to see if unknown CDI named beans are being referenced.

Does anyone have any experience in this regard? Hints on how I can access the expression evaluator to perform syntax checking would be appreciated!


1 Like

Hi @mstevens,

One option would be calling ExpressionManager#createExpression which internally delegates to ExpressionFactory#createValueExpression. The latter throws an instance of ELException in case of syntactical errors. You can obtain an ExpressionManager from an instance of ProcessEngineConfigurationImpl via #getExpressionManager. I don’t think there is a dedicated validation API.



thanks for the pointer. I followed up on this using both the instance of ExpressionManger from ProcessEngineConfigurationImpl getExpressionManager() and a new instance of ExpressionManger. Both work fine when just using ‘createExpression’. I experimented with evaluation the Expression with a mock VariableScope. Interestingly in neither case can I evaluate the expression with value().

The problem here lies with the implementation of ‘org.camunda.bpm.engine.impl.el.JuelExpression’ which call ‘Context.getProcessEngineConfiguration()’. This relieas on ‘processEngineConfigurationStackThreadLocal’ which is not set not being called from the ProcessEngine. I guess this is to be expected when abusing ‘impl’ classes!

Hi @mstevens,

I am also interested in the possibilities of BPMN diagram validations and wonder what the “new 7.6 validation API” you are talking about could be. Do you mean the Camunda BPMN model API? If not, please share the information that I missed so far :wink:

At the first look it seems easy to statically validate the BPMN syntax but hard to do this for EL expressions with/and bean references. I hardly can imagine a way how this could be done without the necessary context. So at the end only a unit test can guarantee that a process is executable (on all pathes) - or am I wrong here?

Kind regards,