Our system imports several DMN tables that are based on common DMN sub-decision.
Although there is a standard mechanism to versioning imported decisions, we have a problem with versions of the sub-decisions.
What is the best way to manage versions in that case?
Are there some concerns being put to develop some out-of-the-box approach?
Many thanks
Hi @mkumorek,
can you please describe your use case in more detail?
How do you evaluate the sub-decisions?
How do you import the sub-decisions?
Best regards,
Philipp
Hi @Philipp_Ossler,
I import whole Decision Requirements Graph, that contains internal decisions:
In java it looks that way:
repositoryService
.createDeployment()
.addInputStream(drgName, drgStream)
.deploy();
Let’s say I have DRG_1 that evaluates Subdecision_1.
Some time later I add a new DRG_2, that defines also Subdecision_1 (already imported key) and it overwrites the former one, because has the same key.
Now, DRG_1 uses the latter (inappropriate) Subdecision_1, just because it is newer.
Is there a way to enforce that all imported decisions has unique key? Like adding some suffix/prefix?
Keys would be differentiable because they would look like e.g.
“DRG_1_Subdecision_1” vs “DRG_2_Subdecision_1”.
I am curious if someone had similar problem and there is some existing, suggested, or planned solution?
Hi @Philipp_Ossler,
maybe there is a versioning of Decisions planned like the BPMN engine does? I see similarities to the handling of call activities using camunda:calledElementBinding
or camunda:calledElementVersion
here.
Can you comment on that?
Hi @mkumorek,
how do you invoke Subdecision_1
in DRG_1
?
If you have a decision in DRG_1
which has Subdecision_1
as a required decision, then it should always evaluate the version and not a newer one.
Best regards,
Philipp
the versioning in the same to BPMN but DMN has no “Call Decision” element. So if you want to evaluate a decision from another DRG then you have to handle it your own.
Best regards,
Philipp
Hi @Philipp_Ossler,
thank you for your help. I tested the topic more deeply and realized 2 things:
-
I was wrong about using this “newer version”. My tests show that the DRG always uses proper Subdecision, while being evaluated.
-
I looked into the DB, and found that Sub can be joined to the DRG with:
- DEPLOYMENT_ID
- DEC_REQ_ID
And that is probably reason, why it works
Thanks!
Mariusz