简体   繁体   中英

DMN Table per condition

I want to leverage on DMN to create a calculation, but the rules for this vary per country per category, so the rules USA and category1, would be different than the rules for USA and category2, and would also be different for Canada and Category 1.

I don't want to add columns for country category and keep it all on a the same table because this will make a super big table, and since each would be maintained by a different set of users would just be simpler to keep it separate if possible.

Is there a way to model this with DMN?

I know BPMN could be use to make this decision on which table to call but was curious if DMN alone would handle this case.

thanks in advance

I know BPMN could be use to make this decision on which table to call but was curious if DMN alone would handle this case.

The most appropriate methodology guideline in your case is indeed to combine the power of BPMN to coordinate which decision service (DMN) to evaluate.

That premised, you may have two alternative options using DMN alone.

DMN-only, option 1

You could define a decision service per each of the DMN model file, each modeling the country-specificity. Then in a "supervisor" DMN model you could evaluate the appropriate decision service from all the countries imported DMN models.

Pro:

  • DMN-only
  • each DMN could indeed be maintained by a different set of users
  • reusability of the defined country-specific decision services

Cons:

  • scalability is limited by the number of options, iff having many country-specific models to import

Example:

选项1

this example actually shows which decision to pick, ie: all variations are evaluated, and then only the desired one is selected.

But you can definitely refactor the model only to invoke just-and-only the imported decision service you want (eg: either of s.Standard card ds() or g.Gold card ds() ).

I wanted to show this example as it's a bit broader than your use-case, but as mentioned you can have it simpler.

DMN-only, option 2

You could use the non-DMN-standard invoke() function to dynamically invoke the desired DMN model from a given DMN model, provided the invoked DMN model is resolvable by the specific platform API --ie: on Drools is part of the same KieContainer , on Kogito is part of the same Kogito application.

Pro:

  • DMN-only
  • each DMN could indeed be maintained by a different set of users

Cons:

  • the invoke() function is a Drools extended built-in function not part of the DMN Specification.

Example:

选项2 drd

In this example, country is used to lookup the name of the model containing the decision table we want to invoke to evaluate the purchase age ; then the extended built-in function is used to invoke the desired model, passing the required inputs:

选项2运行

This second screenshot shows from left to right: an example of a country-specific DMN model, the "supervisor" DMN model performing the invocation, example of Scenario Test running it for a few selected countries and showing the purchase age is the one requested.

I believe this is one of the very few cases where it actually make sense to leverage platform-integration aspects (such as invoke() function) as it would be naive importing 249 models of the different ISO Countries variants..

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM