Binding DMN inputs to process variables

I can’t figure out how to do the simplest of mappings between a process model’s variables and a DMN table in Platform 8.

My process instance clearly shows a process variable with a simple text value in Operate. I’ve configured the name of the same variable as the input expression for one of the inputs of my table. I have rows with “somevalue”, “someothervalue” in that column to match the string value. If I look in the DMN execution history though, the expression for the column comes up as null, which results in the wrong results from the table of course. I know the expression needs to be a FEEL expression, but the examples I can find also seem to refer to process variables in the DMN table as if those should be magically mapped.

I also tried adding an explicit input mapping, but those don’t help to get the input value into the DMN table either. It’s still null.

The documentation here: Input | Camunda Platform 8 Docs seems to be outdated as far as the screenshots for the DMN editor, but they also don’t explain how the mapping should be done.

Hey @tiesebarrell!
Do you have some process / decision diagram to share?

In my little example down below I have configured the DMN Table in such a way that the “Age” column refers to the “age” variable which is included in the expression.

Looking forward to a small example of yours! :slight_smile:
Best,
Thomas

Hi @Hafflgav, thanks for the response!

I have a similar setup as in your example, but there must be some silly difference I can’t find :slight_smile:

The DMN is attached and basically switches based on a single input and tries to determine the “sentiment” of a food review. The output is either positive or negative.

The process consists of a user task first, which is completed with a Camunda form and sets the foodRanking variable, a string value.

After the task, the decision is invoked and is supposed to act on the value chosen in the form and product the “sentiment” variable (this works fine, but the outcome is wrong, due to the null input). Then there’s a gateway that goes one way or the other based on the sentiment.

As you can see, this is bit of a contrived example for a comedic demo, but the principle is the same :wink: I configured all three (process, decision and form) in de web modeler inside the SaaS environment, FWIW.

decide-what-to-do (1).dmn (1.8 KB)
organise-cg.bpmn (7.6 KB)

Thanks,
Tiese

Hey @tiesebarrell!
Thanks for the very detailed description. :slight_smile:

I have uploaded your diagrams to my instance of web modeler and deployed both of them to my cluster.
Taking a look in Operate it shows me that the decision has been executed properly and the output is “cool”.

Going back to my process instance I can also see the newly added “sentiment” variable.

P.S.: The gateway works properly for me as well and I have changed nothing…

So I do have two more questions for you:

  • Have you deployed both, the BPMN and the DMN model to your cluster?
  • Which Zeebe version does your cluster have?

Let me know if you figured it out in the meantime. :slight_smile:
Have a great weekend!
Best,
Thomas

1 Like

Hi @Hafflgav,

thanks for running the example and checking it. I’ve retested too now, without the input mapping to the table too, because that shouldn’t be necessary. I deliberately re-deployed both process and table and checked that both had an incremented version number before I ran them. It works for me too, now, so it seems it had to be some kind of version mismatch before and now it’s okay. Very odd though. Since the process instance before HAD a process variable with the correct name and the input expression of the table referred to that name. But who knows, maybe I mixed up the deployments and had a crossover going on all the time, so the results were not what I expected!

It’s a 8.0.2 Zeebe cluster, BTW.

Thanks for helping out and pointing me to the redeployment, which seems to have forced things back into place and restored sanity :slight_smile:

1 Like

I am glad to hear that it worked out! :slight_smile:
Sometimes a redeployment is the best you can do. But this should not have happened in the first place for sure. - If I do hear this more often I will make sure that a bug is raised.

Thanks! :slight_smile: