Details
-
Task
-
Resolution: Won't Do
-
Critical
-
None
-
None
-
None
-
2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25), 2021 Week 07-09 (from Feb 15), 2021 Week 10-12 (from Mar 8), 2021 Week 13-15 (from Mar 29), 2021 Week 16-18 (from Apr 19), 2021 Week 19-21 (from May 10), 2021 Week 22-24 (from May 31), 2021 Week 25-27 (from Jun 21), 2021 Week 28-30 (from Jul 12), 2021 Week 31-33 (from Aug 2), 2021 Week 34-36 (from Aug 23), 2021 Week 37-39 (from Sep 13), 2021 Week 40-42 (from Oct 4), 2021 Week 43-45 (from Oct 25), 2021 Week 46-48 (from Nov 15), 2021 Week 49-51 (from Dec 6th), 2022 Week 02-04 (from Jan 10)
-
Undefined
-
NEW
-
NEW
-
---
-
---
Description
To have Trusty-PMML working withouth MVEL (i.e. drools-7.45) a fix has been made.
Unfortunately, that modification broke DMN-PMML integration inside drools.
A very quick and dirty solution has been to
1) expose the
DMNRuntimeKB runtimeKB inside DMNRuntimeImpl
2) based on the actual class at runtime, if it is "DMNRuntimeKBWrappingIKB" use a code patch the works in drools, otherwise the "kogito" one.
This has been done only for extreme needs, but must be redisigned and properly implemented ASAP
The root cause of that is DMN ignoring the Kogito API.
Kogito defines a container class (org.kie.kogito.app.Application) that is meant to be used by all components (processes, ruleunits, decisions and predictions) to invoke the others.
Trusty PMML fullfill this API, exposing predictive models throught the the
org.kie.kogito.app.PredictionModels.getPredictionModel(String modelName)
but since DMNKogito completely ignore this, a painful workaround has been needed to solve the issue.
Instead of adding workarounds one on top of the other, a different approach on DMN side is required, respecting the constraints put by the containers.
Having done that, the DMN-PMML integration would be automatically resolved.
I'll be available for more explanation, if needed.