Get complete tree of decisions of DMN instance from REST API

Hi,

I’m implementing a big decision tree that has a top-level output if data is valid or not. We work solely via the REST interface of Camunda. When I evaluate my decision, I get a very nice outcome, being true or false as expected. But now I would like to get the entire decision tree of how this decision was executed.

The problem I encounter is when I evaluate with endpoint

/decision-definition/key/{decisionKey}/evaluate

I get this back:
[
{
“outputParm”: {
“type”: “Boolean”,
“value”: false,
“valueInfo”: {}
}
}
]

Unfortunately there’s no reference to the rootDecisionInstanceId. So I’m unable to get from /history/decision-instance?rootDecisionInstanceId={theRootDecisionInstanceId} the tree of decisions that build up this decision.

So, my problem would be solved if the rootDecisionInstanceId would be included in the return of /decision-definition/key/{decisionKey}/evaluate and /decision-definition/{decisionId}/evaluate. But I’m open to any other suggestion of course.

Thank you!
Rogier

Hi @rogier.roukens,

you’re right. Currently, there is no way to get the rootDecisionInstanceId from the evaluation result.

Why do you want to get the decision tree?
What information do you need from it?

Best regards,
Philipp

Hi Philipp,

Thanks for taking the time to read my question and replying! The decision we are building has multiple functions. The input is a number of parameters (the values of a certain object) as filled in by the user in an application. The decision has an end outcome: ‘Are the parameters valid’. But to determine if the parameter are valid many sub decisions and calculations, like min and max values are calculated and DMN tables are evaluated. The end result (‘Are the parameters valid’) is used by the requester, but also all the intermediate results (the min and max values and DMN outputs) are needed to do stuff. Also, if the parameters are not valid, we want to tell the requester WHY the parameters are not valid. So, which parameter is invalid and what was the exact reason (‘parameter x above maximum y’ for example).

To get all input and output parameters of all underlying decisions we intend to use the following call:

http://localhost:8080/engine-rest/history/decision-instance?rootDecisionInstanceId={theRootDecisionInstanceId}&includeInputs=true&includeOutputs=true

For this would give us a basis to work from. Actually, while working on this problem I also checked Drools to see how that application handles a DMN evaluation. If I understand it correctly when you execute a Drools DMN rules tree, the complete decision tree with all inputs and outputs and all decision is returned (Drools Documentation). That actually meets our requirements completely. But we don’t really want to add another rules engine in our landscape currently.

So, to get the complete decision tree, we need at least the rootDecisionInstanceId…

Hopefully this answers your question.

Rogier

My first idea is that you should include all results from the decisions instead of query the history. As a root decision, you can have a decision literal expression which invokes all decisions and collects the results.

Related posts:

Does this help you?

Best regards,
Philipp

Hi Philipp,

That would help I guess if there is some general ‘one liner’ (to fill in in the literal expression) that produces all underlying results?

Of course I could write some script that mimics all underlying logic, but to me that’s very redundant logic which is already available in the underlying DMN requirements model. The relations of input and output and of all decisions is already known and registered in the DMN requirements model. And as said, the history/decision-instance?rootDecisionInstanceId={theRootDecisionInstanceId}&includeInputs=true&includeOutputs=true gives me exactly what I need, in one call! Writing and maintaining some ugly script that gathers this, does not comply with my architecture views.

And is not always the output of ‘how did the system come to this decision?’ a requirement of any decision support system? Camunda only produces the end result. Producing more verbose output, if needed, is to me a very trivial requirement. And also delivered by at least one other BRMS (Drools). (Since I’m a developer myself of course I understand that not all trivial requirements have been noted by someone and thus, been build. So my plea is for trying to get this on the backlog of Camunda DEV, and not ‘blaming’ that it is not already there :wink: )

I also don’t have the scala-DMN extension. Did take a look at it, but I try to stay with the basic Camunda installation as much as possible currently. And as I feel this is so trivial, I find it hard to believe that extensions are needed to get such basic results.

Maybe you have a suggestion of a literal expression (the ‘one liner’ I mention above) to get all underlying results?

Rogier

Hi! We have the exact same requirmeent and are facing the same challenge. It would be interesting if @rogier.roukens found a solution you could share? Or even better if @Philipp_Ossler could say that this will be included in future development or, even better, is being developed :wink:

-Finnur

Hi @Finnur_Olafsson,

Unfortunately, I never got a satisfactory answer or solution from Camunda team. I solved the problem by putting a decision table as top level element on my DMB tree. This table outputs all parameters that I want to have as output. It gives a lot of trouble because of name data type inconsistencies etc when making changes to the DMN. Having this solution out-of-the-box would be very easy in my opinion and very ‘obvious’ functionality. But, it’s not answered unfortunately.

Here’s a screenshot of the table to output the parameters I need to have. With it, we could solve our requirement. But it does take manual effort to keep it consistent. Getting the output of the DMN from REST API is, for me, still a really needed function.

Regards,
Rogier

Please have a look at Retrieving decision instance id.

As you mentioned, you could have a literal expression to collect the results. The easiest would be to just reference the decision results. For example:

{
    minMaxImpairment: minMaxImpairment,
    maxMaxImpairment: maxMaxImpairment,
    ... 
}

Providing a generic script is a bit complicated because you don’t have access to the current decision and tree.

I think it would be more convenient to handle this in the backend and provide a just REST API.

And also, feel free to create a pull request: https://app.camunda.com/jira/browse/CAM

Best regards,
Philipp

Hi Philipp,

Thanks again. Of course, you did mentioned these (type of) solutions before. I understand there are several work arounds possible. Mine is also workable, that’s why I posted it here. I think what @Finnur_Olafsson and I are looking for is out-of-the-box support of this functionality from the REST API. The REST API is very feature rich on some area’s, but lacks features on other. This is normal of course in agile products. Our question is: what is the route to the REST API backlog? We understand it’s not in the current REST API. But maybe in the next? Can you add stories to the backlog?

Rogier