REST API variable structure

Camunda 8 Topics
1

We are planning the migration from Camunda7 to Camunda8. We are working with Camunda as a standalone shared server and communicating with it via REST API. My question is now
How do I have to format the REST API request
/v2/decision-definitions/evaluate for a really simple DMN.
My test was like this (Request body):

{
    "decisionDefinitionId": "ER001",
    "variables": {
        "MYDATE":"2029-05-03T10:30:00Z"
    }
}

but the variable is not detected as a date.

            "evaluatedInputs": [
                {
                    "inputId": "Input_1",
                    "inputName": "MYDATE",
                    "inputValue": "\"2029-05-03T10:30:00Z\""

The old format in Camunda7:

{
  "variables" : {
    "MYDATE" : { "value" : "2019-05-03T01:22:22.143+0100", "type" : "Date" }
  }
}

is also not working.
Are there any examples available? In the documentation I can only find:
"variables": {}

Regards
Edmund

2

Hi @Edmund - this is an interesting scenario. The data that is sent to the server is just a JSON document, which doesn’t have a native date format and uses a string representation. On the backend, it doesn’t know what variables should be a date, so it continues as a string. I think the best approach is to convert the value to a date using FEEL inside your DMN using the conversion function.

I have brought this to the attention of the product team to investigate further, though, to see if there’s a more elegant solution that could be implemented.

1 Like
3

Hi Nethan,
this interesting scenario is the scenario from Camunda7. We are using this REST API for more than 5 years now.
…
{
“variables” : {
“MYDATE” : { “value” : “2019-05-03T01:22:22.143+0100”, “type” : “Date” }
}
}
…
from Camunda7 is sending the datatype together with the value and the value is then interpreted inside the DMN as a date.
You mean this has also changed in Camunda8 and we have to change hundreds of DMNs?

Regards
Edmund

4

Hi @Edmund - that’s not necessarily what I’m saying. The execution engine and API was built from scratch for C8, so there are differences with C7. But at the same time, we want to make sure migrations aren’t a series of long manual tasks and we want to automate as much of that as it is possible to automate.

Do you have an enterprise license for C7? We have a taskforce dedicated to assisting with C7->C8 migrations that I can get you in touch with. I’ve also raised this concern with our product management team to investigate, from both a migration tooling perspective as well as supporting dates natively in variable parameters.

5

Hi Nathan,
yes the customer I am working for has an enterprise license and we are in contact with our Camunda Contact representative. I am just trying to get deeper in this new system to understand what and where we have to do changes.

Regards
Edmund

6

@Edmund - understood! I’ve brought this to attention of the migration taskforce!

7

Thanks Edmund for reporting this. I agree that we should allow setting the type, your use case of DMN evaluation using dates is spot on. I started a discussion with product management/engineering if and when we could include this. For tracking I created this issue: REST API: Support variable type for process variables (e.g. date) · Issue #29678 · camunda/camunda · GitHub. Feel free to add comments or feedback either here on in this issue!
Best - Bernd

8

I also have a follow-up question @Edmund: Do you also call this DMN decision table from a BPMN process?

9

Hi, yes, we call our DMNs almost exclusively via a BPMN. This DMN is used to accelerate several thousand calls of a DMN with several variable sets. This speeds it up by reducing the network latency time. The BPMN collects the DMN results and returns them in a result list (Json).
We were able to migrate this BPMN into the new C8 environment, there is just one smaller problem which was discussed here:
Running dynamic DMN in BPMN.

10

So do I understand correctly that you solved the missing type problem (I guess by converting the type yourself in the DMN)?

I will also briefly chekc status of the other issue.

11

Yes, we are using the FEEL conversion in the DMN expression field. Unfortunately this means that our business users have to go through hundreds of rules…which is error prone.

12

I think this change in all files could probably be automated.

we also created this feature request now, which would also solve the problem as it tries to do an auto-conversion in this case: [DMN] Convert string value to input type · Issue #30144 · camunda/camunda · GitHub

But please note this is not yet prioritized and planned - so I can’t say when this will land in the product (yet)

13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.