1- Upon looking at the docs (over the last few weeks), my understanding is that there is strong support for decision tables themselves, including inputs/outputs/annotations as well as hit policies to work out which rules did pass and which did not.
2- There is support for JUEL but not for FEEL.
3- There is no support (yet) for chaining decisions (DRG?), though presumably we can use a DecisionTask and BPMN to chain multiple decisions together. I’m not quite aware of the difference here - is it mainly that the hit policies don’t run quite the same (e.g. would only run on the first decision table)?
Is there anything I should be aware of in terms of flowable and DMN?
Does anyone have any performance metrics of flowable’s DMN decision tables? e.g. is it more performant to run one big table of rules or several tables of smaller rules? Say I had a list of products to sell, would iterating over the new entire product catalogue with each product having its own decision table be performant? (talking a few hundred products with say 20/30 rules in each decision table)
Thanks - any pointers in terms of best practices would be great.
Support for DRG is on the roadmap but there is no clear timeline for it yet. You’re correct that you could model multiple decision tasks to chain decisions together. But DRGs will eventually bring more functionality than ‘just’ chaining. I’m not sure what you mean with ; ’ that the hit policies don’t run quite the same '?
In regards to the best practice part.
Would it be necessary to have a different decision table for each product? In other words; Does each product has it’s set of different rules?
Or can the same decision table definition be used?
Thanks for quick reply. In terms of 3. I meant that with drg you would presumably know that which rules have hit. Whereas in a BPM, if you had a chain of decision tables X, X+1, X+2 and an outcome of the rule X table was fatal, then you’d naturally stop there rather processing to X+1, etc. In terms of querying status, you’d get less or it is more convoluted as you have to query and aggregate each table?
But I may be misunderstanding the benefits of drg over and above decision tables…You mention drg will provide more functionality than just chaining. Do you have a particular vision in mind?
Not sure if we are on the same page regarding DRGs / DRDs.
In my view a DRD depicts a decision with it’s dependencies / requirements.
This can be for example supporting decisions or input data. The decisions don’t have to be of the type Decision Tables.
Eventually we want to support other decision types in addition to decision tables. For example Boxed Expressions and / or Literal Expressions. The invocations of these other expression types can be modelled in the DRG / DRD.