Hi,
something similar was already discussed here, but unfortunately it didn’t address the main issue:
Conditional flow expression using just created output parameter - Camunda Platform 7 Topics / Camunda Platform 7 Process Engine - Camunda Platform Forum
The issue I seem to have found is that output parameters, defined in Camunda Modeller, are not recognized by conditional flows:
conditionalFlowDemo.bpmn (7.0 KB)
When an output parameter is defined, it is recognized properly by an X-GateWay, but conditional flows seem to be checked before the outputs are processed and you get the following error:
Caused by: org.camunda.bpm.engine.impl.javax.el.PropertyNotFoundException: Cannot resolve identifier 'taskOutput'
Using conditional flows allows you to create much more compact diagrams, especially if it’s a boolean based decision. Is this a bug and can it be fixed easily?
was anyone able to recreate this error or am I the only one?
Hi @krisMeta and welcome to the Camunda Community!
I think the problem in your model is that in the Task With Output element you are setting the value to value, but then in your conditional flow, you are testing that ${taskOutput == "value"} If you change the element’s output to be “value” I think it will work as expected.
test-condition.bpmn (3.4 KB) Built this small test and it works fine. I then altered your model and it works as well.
conditionalFlowDemo.bpmn (3.6 KB)
While using conditional flows can make the process diagram more compact, it is much harder to read, understand, and (as you’re finding) debug should problems arise.
I hope this solves your problem.
Best,
dg
1 Like
Hi @davidgs,
thank you for your reply.
I’m a little confused though. Are you trying to tell me that I made a typo somewhere
and set the taskOutput variable to value instead and that’s why it’s not set for the conditional flow?
It may be, that you downloaded an older version of the example I created. I did a few typos at the beginning but corrected them and as far as I can see they are not present in the current version.
I ran your example. Since you used a User Task to set the output, I needed to claim and complete it first, before the conditional flow was processed. Then I got the same error:
To me, it still seems that conditional flows are processed before outputs are set.
It’s not a typo, per se. This will be easier to explain if we use a different variable name than value. Your process variable name is taskOutput. And you are setting the value of taskOutput to value. So let’s change that to say the value of taskOutput is Foobar. In your conditional, you are looking for ${tastOutput == "Foobar"} which is a quoted string value. However, in your variable assignment statement, you are not using a quoted string. you are using value, not “value”, and therein lies the problem. Try setting the value of taskOutput to “Foobar” and change your comparator to ${taskOutput == "Foobar"} and you will see what I mean.
If you look at the 2 examples I sent back, you will note that I am setting the variable taskOutput to “value”, not value.
Using value as an actual value makes things very confusing, so I would advise against it in the future.
dg
So, we seem to have a great misunderstanding here and I am not able to recreate what you are saying. We can use Foobar instead of value if this helps us to understand each other.
This is how I understand (and have tested) how Camunda works, when defining an output:
I can set the Assignment type and it is set to String or expression.
To me, this means, that if I type text, it is interpreted as a String. It is only interpreted as an expression if I surround it with ${<expression>}.
Here are some examples to confirm my understanding:
- If the value field is filled with
Foobar, then the remaining process interprets it’s as a string consisting of Foobar.
taksOutputSetsFoobar.bpmn (5.4 KB)
taksOutputSetsNotFoobar.bpmn (5.4 KB)
- If I fill the field with
"Foobar" instead, it will be interpreted as a string consisting of "Foobar"
taksOutputSetsQuotFoobarQuot.bpmn (5.5 KB)
taksOutputSetsQuotNotFoobarQuot.bpmn (5.5 KB)
- And if I fill it with the expression
${"Foobar"} it will be interpreted as a string consisting of Foobar
taksOutputSetsFoobarAsExpression.bpmn (5.5 KB)
taksOutputSetsNotFoobarAsExpression.bpmn (5.5 KB)
All these processes create the expected results for me. Do they yield different results for you?
Because if they do, then we must be using some very different Camunda versions or something else is completely off.
Also, this is not the problem, because I got the exact same error when using your process example, as you can see in the screenshot I attached to my previous post.
If I take the first example from this post (taksOutputSetsFoobar.bpmn) and replace the XOR-Gateway with a conditional flow setup, I get the mentioned Error:
taksOutputSetsFoobarConditionalFlowError.bpmn (4.8 KB)
Does this process not throw this error for you?
If this isn’t a bug, how do I make this work?
Hi @krisMeta,
Yes, I faced the same error when tested with version 7.17.0. It looks like a bug.
I never thought of using conditional flows before.
I am running Camunda Platform 7.15-ee right now, and all I can say is that if you put quotes around the string in the value assignment, it works. If you don’t, it will not.
This will not work:
This will:
I will have to get 7.17 up and see if the same is true there.
dg
1 Like
@hassang: Thanks for testing this. It’s good to know that I’m not the only one 
@davidgs: this is very interesting (and a little unintuitive imho 
). I’m running 7.17.0, just as @hassang.
However, are we in agreement that this would be a separate topic and is not related to the conditional flow issue?
