Working and testing further with DMN API, few questions, so thought i would consolidate them
Ability to get Input Variables for a DMN? Does not appear to be the ability to query through the API what are the variable names and types that a DMN requires. Because a DMN seems to require all variables to be inputted as part of the POST, having the ability to get what are the required inputs would be very helpful.
Would be great to be able to get which rule(s) were validated as part of the DMN response. Especially when doing DMNs such as Collect Sum. Would be valuable to have the response (optionally) return a json object all all of the rules that were validated as part of the eval.
Ability to change hit policy as part of eval. There are situations where there may be multiple uses for the same rules but with a different hit policy. Would be great if we could change the hit policy as part of an optional variable with the POST for eval.
Asked this in another post (which i will ‘close’): Is it possible to have rules that are override rules that cancel out other rules (without chaining DMN together). A more specific example would be for Collect Sum (imagine a Pricing Table), and you are summing the various charged, but there is a specific rule that if matched, all other rules are irrelevant.
Ability to have the annotations returned as part of the eval response for the rule(s) that were valid.
I don’t think that this is a good idea since the hit policy is required for the semantics. For example, you can’t use a decision table with unique hit policy if it is designed for collect hit policy. Can you agree with it?
No. You should model it clear and that it is easy to understand. It might be a good idea to have multiple decisions and combine them using decision flow or decision requirement diagrams (comes with 7.6).
Since the annotations are just descriptions of the rules and not output values, I don’t think that they should be apart of the decision result. If you need this information (e.g. provide a reason for the result) then you should use another output value for it. I see this pattern in various examples.
1 and 2 we don’t agree on. . For 1. yes we can pull it from the XML, but knowing the inputs (and the outputs) as a API call make for a powerful app building APIs. Having to parse the XML means we have to load the entire DMN, and have xml parsing code on a per app basis, where is makes a lot of sense to have these functions be part of the DMN api: Specifically because they are common requests that would be made used by a app or another service that wants to call the DMN.
for 2, yes it is available as the history, but similar to 1, knowing which rules were hit would be a common function to be called right after a DMN is evaluated. So again would be common boilerplate code having to be carried around between apps.
So TLDR: Yes the data is available through XML / second API calls, but the functions/data requested would be common enough to look at adding them to (at least optional) responses to DMN evals.
yes, you have to load the DMN but you don’t need to parse the XML. You can use the Model Api which provides an easy access via Java code.
I’m not sure that kind of application you want to build. IMO, if an application wants to evaluate a DMN then it must know the inputs and outputs. Also, keep it mind that an input expression can be more than a simple expression which accesses a variable.
However, if you need these functions then you can embed the DMN / process engine in your own application and provide the Rest Api.
. For 1. yes we can pull it from the XML, but knowing the inputs (and the outputs) as a API call make for a powerful app building APIs. Having to parse the XML means we have to load the entire DMN, and have xml parsing code on a per app basis, where is makes a lot of sense to have these functions be part of the DMN api: Specifically because they are common requests that would be made used by a app or another service that wants to call the DMN.