Decision Management (ODM,ADS)

Issue: Generating Excel Scenarios File Template doesn't work if Java XOM contains attributes of type 'java.time.LocalDate'.

We tried changing the data type to 'java.util.Date' to make it work for the Decision Runner, but it breaks the decision service API by giving the 'date-time' format for the date fields.

Java XOM attribute with 'java.util.Date' type

"tradeDate" : {
            "type" : "string",
            "format" : "date-time"
          }

Java XOM attribute with 'java.time.LocalDate' type

"tradeDate" : {
            "type" : "string",
            "format" : "date"
          }

Also, we tried using @ApiModelProperty annotation with no luck.

@ApiModelProperty(dataType = "java.time.LocalDate")

private java.util.Date tradeDate;

To this issue, does anyone know a solution that works for decision service API consumers and decision runner scenarios template generation?

Hi Charan

You should use java.util.Date in the XOM and BOM as ODM does not support the java.dateTime library. Everything will then work in ODM, including Decision Runner. 
What remains after this is your need to have java.dateTime.LocalDate in HTDS. For this there are the following  solutions:

1) You can add additional methods in the XOM and BOM that map between  java.util.Date and java.dateTime.LocalDate and vice versa, and use ODM annotations to exclude java.time.LocalDate from Decision Runner and JAXB annotations to exclude the java.util.Date from the HTDS generation. However this is a dirty solution. It is not very reusuable.

2) A better solution is to write an XMLAdapter in Java and use the @XmlJavaTypeAdapter JAXB XML annotation to apply it on the XOM to marshall / unmarshall between the java.dateTime.LocalDate and java.util.Date. You can find examples of how to do this on the web for JSON and SWAGGER. JAXB annotations work with JSON. This is more elegant. It is a pure Java solution and is reusable.

3) The best solution of all is to write a mediation component (see https://www.linkedin.com/pulse/building-better-rule-application-architecture-peter-warde). In the above solutions you are using direct integration with decision service clients. You are tightly coupling providers and consumer. If you use a mediation component, you would get the benefits of for data type transformation, ruleset versioning, data validation, error handling etc. etc. Long term it is the only real viable solution.

Hope this helps.

"tradeDate" : {            "type" : "string",            "format" : "date-time"          }

"tradeDate" : {            "type" : "string",            "format" : "date"          }