-
Sub-task
-
Resolution: Unresolved
-
L3 - Default
-
None
-
None
-
None
AT
In the Process Engine, I can restore the DMN legacy behavior to keep my current DMN models as-is.
Scope
- Minimum: legacy mode can be turned on for all DMN models or none
- Maximum: legacy mode can be turned on/off per DMN model
Implementation outline
- Different factories for different versions of the engine (Legacy & Scala)
- Flag for enabling legacy behavior to generate the legacy engine or Scala engine
- DecisionInvocation uses the DmnEngine from the config
- ProcessEngineConfigurationImpl#initDmnEngine should look for a flag for legacy behavior and initialize the corresponding engine
- Maximum Scope
- Gradual update of single models could be achieved by
- Register two DMN deployers (legacy and Scala) that receive the deployment unit and need to decide based on the config if they parse the DMN deployment or not
- Allow to configure which models to parse as legacy by either
- Provide an engine config option with a list of DMN model keys that should be parsed as legacy OR
- Allow to define a marker in the respective models to be parsed as legacy or not
- Get the right engine for the model by either
- introduce new getter in engine config “getDmnEngineByKey” that receives the engine respecting the DMN model key OR
- change the current getter “getDmnEngine” to require a key parameter so people notice right away something changed in that behavior (it is private API)
- Gradual update of single models could be achieved by
This is the controller panel for Smart Panels app
[CAM-12925] In Process Engine, I can restore the legacy behavior
Fix Version/s | New: 7.15.0 [ 16006 ] |
Description |
Original:
h3. AT
In Process Engine, I can restore the legacy behavior See https://docs.google.com/document/d/1fvp2qf75W7VBSFjfHVz3iRN4Ynq349R6qtq3eP62opw/edit#bookmark=id.w7tx54oviqyj |
New:
h3. AT
* In Process Engine, I can restore the legacy behavior * Scope ** Minimum: legacy on/off for all models ** Maximum: legacy on/off per model See https://docs.google.com/document/d/1fvp2qf75W7VBSFjfHVz3iRN4Ynq349R6qtq3eP62opw/edit#bookmark=id.w7tx54oviqyj |
Mentioned Roles |
Mentioned Groups |
Assignee | New: Tobias Metzke-Bernstein [ tobias.metzke ] |
Fix Version/s | Original: 7.15.0 [ 16006 ] |
Description |
Original:
h3. AT
* In Process Engine, I can restore the legacy behavior * Scope ** Minimum: legacy on/off for all models ** Maximum: legacy on/off per model See https://docs.google.com/document/d/1fvp2qf75W7VBSFjfHVz3iRN4Ynq349R6qtq3eP62opw/edit#bookmark=id.w7tx54oviqyj |
New:
h3. AT
In the Process Engine, I can restore the DMN legacy behavior to keep my current DMN models as-is. h3. Scope * Minimum: legacy mode can be turned on for all DMN models or none * Maximum: legacy mode can be turned on/off per DMN model h3. Implementation outline * Different factories for different versions of the engine (Legacy & Scala) * Flag for enabling legacy behavior to generate the legacy engine or Scala engine * DecisionInvocation uses the DmnEngine from the config * ProcessEngineConfigurationImpl#initDmnEngine should look for a flag for legacy behavior and initialize the corresponding engine * Maximum Scope ** Gradual update of single models could be achieved by *** Provide an engine config option with a list of DMN model keys that should be parsed as legacy OR Allow to define a marker in the respective models to be parsed as legacy or not *** Register two DMN deployers (legacy and Scala) that receive the deployment unit and need to decide based on the config if they parse the DMN deployment or not *** Either introduce new getter in engine config “getDmnEngineByKey” that receives the engine respecting the DMN model key OR change the current getter “getDmnEngine” to require a key parameter so people notice right away something changed in that behavior (it is private API) See https://docs.google.com/document/d/1fvp2qf75W7VBSFjfHVz3iRN4Ynq349R6qtq3eP62opw/edit#bookmark=id.w7tx54oviqyj |
Mentioned Roles |