[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ] Matteo Mortari edited comment on DROOLS-5973 at 2/15/21 11:06 AM: ------------------------------------------------------------------ Hi Andrew, thank you for raising this report but I believe there is actually no bug. I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface. I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry. In DMN there is no Enumeration as a type per-se. Possibly when reported, there has been some confusion about some wording in the Editor. In DMN one can only define some constraints on an existing type in the domain. For instance one might want to constrain {{FEEL:string}} to some specific values: !screenshot-1.png|thumbnail! or equivalently: !screenshot-2.png|thumbnail! but the ItemDefinition would still be a {{FEEL:string}}, just constrained to some specific values. Similarly in Java, a {{java.lang.Enum}} is NOT a {{java.lang.String}}. Or for another DMN example, one might want to constrain {{FEEL:number}} to some specific values: !screenshot-3.png|thumbnail! or equivalently: !screenshot-4.png|thumbnail! but once again, the ItemDefinition would still be a {{FEEL:number}}, just constrained to some specific values. so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance: {code:java} final DMNContext context = DMNFactory.newContext(); context.set( "InputData-periodicity", "Weekly" ); context.set( "InputData-numericBase", 8 ); {code} Of course we try to have some convenience, so the value {{8}} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird. Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example: {code:java} public enum Periodicity { DAILY("Daily"), WEEKLY("Weekly"), MONTHLY("Monthly"); private String v; private Periodicity(String val) { this.v = val; } public String asString() { return v; } } ... final DMNContext context = DMNFactory.newContext(); context.set("InputData-periodicity", Periodicity.WEEKLY.asString()); {code} I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug. Hope this helps, please let us know! was (Author: tari_manga): Hi Andrew, thank you for raising this report but I believe there is actually no bug. I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface. I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry. In DMN there is no Enumeration as a type per-se. Possibly when reported, there has been some confusion about some wording in the Editor. In DMN one can only define some constraints on an existing type in the domain. For instance one might want to constrain {{FEEL:string}} to some specific values: !screenshot-1.png|thumbnail! or equivalently: !screenshot-2.png|thumbnail! but the ItemDefinition would still be a {{FEEL:string}}, just constrained to some specific values. Similarly in Java, a {{java.lang.Enum}} is NOT a {{java.lang.String}}. Or for another DMN example, one might want to constrain {{FEEL:number}} to some specific values: !screenshot-3.png|thumbnail! or equivalently: !screenshot-4.png|thumbnail! but once again, the ItemDefinition would still be a {{FEEL:number}}, just constrained to some specific values. so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance: {code:java} final DMNContext context = DMNFactory.newContext(); context.set( "InputData-periodicity", "Weekly" ); context.set( "InputData-numericBase", 8 ); {code} Of course we try to have some convenience, so the value {8} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird. Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example: {code:java} public enum Periodicity { DAILY("Daily"), WEEKLY("Weekly"), MONTHLY("Monthly"); private String v; private Periodicity(String val) { this.v = val; } public String asString() { return v; } } ... final DMNContext context = DMNFactory.newContext(); context.set("InputData-periodicity", Periodicity.WEEKLY.asString()); {code} I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug. Hope this helps, please let us know! -- This message was sent by Atlassian Jira (v8.13.1#813001)