Bpmn-js: Error: no namespace uri given for prefix <conditionExpression>

I am trying to change the conditionExpression:body property of a SequenceFlow element with a ‘bpmn:FormalExpression’ object within. It’s failing with the error message in the title.

Here is the code:

The issue happens in properties-panel.js at this line:

if (cExpr) {
  this._modeling.updateProperties(element, {
    "conditionExpression:body": inputField.val()

I don’t really understand the error. How do I fix this?

To reproduce, you can select the arrow labeled “No” and change the ‘Expression’ field in the custom properties panel.

If you’re unsure about how to create or update a certain model property you can always have a look at the model itself.

In your case the interesting part is: https://github.com/bpmn-io/bpmn-moddle/blob/master/resources/bpmn/json/bpmn.json#L1643

The conditionExpression property must be of type Expression, so let’s create one:

const expression = bpmnFactory.create("bpmn:Expression");

expression.body = "${foo}";

const sequenceFlow = elementRegistry.get("Flow_2");

modeling.updateProperties(sequenceFlow, {
  conditionExpression: expression

Here’s a working example: https://codesandbox.io/s/set-condition-expression-example-5cd4h

That’s very strange, because I made the included bpmn diagram using the camunda modeler desktop application (version 4.0.0). It doesn’t even set the type to ‘bpmn:FormalExpression’, but to ‘tFormalExpression’. Here’s the property from the modeler.

I did change the codesandbox again though, and adding the Expression property doesn’t work. You can use the same link to view it I think. This time updateProperty throws an error: ‘element required’.

Edit: It appears there was an issue with async awaiting the importXML method, but it appears to be working now. Though I still can’t change existing conditionExpressions using the modeling module. I can change it from the businessObject, but I want it to appear in the commandStack. For now, a solution is recreating the conditionExpression element every time, though that is far from ideal.

Can you point out where you observed this behavior?

Modeling#updateProperties is the method you should use to update any model properties using a command that can be reverted.

Instead of reinventing the wheel why not have a look at how this functionality is implemented in the existing properties panel: https://github.com/bpmn-io/bpmn-js-properties-panel/blob/master/lib/provider/camunda/parts/ConditionalProps.js#L84

I created a bpmn diagram using the windows desktop application (version 4.0.0) like shown in the above screenshot and saved it. Then I checked the generated xml and found this to be the generated expression element:

<bpmn:conditionExpression xsi:type="bpmn:tFormalExpression">${someVar}</bpmn:conditionExpression>

As far as I understand, this does in fact replace the conditionExpression property with a newly created conditionExpression. I just assumed this would be done differently as frequently creating and disposing variables is a performance issue. I’ll just do that then.

Though I still don’t understand why updating the ‘conditionExpression:body’ property doesn’t work. I have seen this being done before, though I can’t find it anymore.

Why would you assume that this is working? This is simply not how the toolkit works. You can’t just specify some object and the model objects will magically be created.

As for the xsi:type="bpmn:tFormalExpression" attribute, it is automatically set if you create a bpmn:FormalExpression instead of a bpmn:Expression which it inherits from. According to the BPMN specification the condition expression must be a bpmn:Expression so it can be that or a bpmn:FormalExpression.

Regarding the performance of creating new modal objects every time the condition is changed we never do that in batches so it’s neglectable.

Well clearly I meant for elements that already had a conditionExpression, but okay

Neither for elements that exist nor for elements that do not.