Hi all,
My issue seems simple, but I’m having a hard time solving it.
I have a XML string and I want to convert it to a document.
So far so good.
I use the service xmlNodeToDocument, passing the document type name as input and I have the document.
The problem is that my document have some Java types in it, like double, int, date and boolean.
When I use the xmlNodeToDocument, even though I’m passing the document type name as input, the result document is created with all fields as String, then, when I try to publish that document to the broker, I get an error complaining about these fields that not match the type.
Does anyone have a solution for that?
I would suggest also to not use types like int, date, boolean, etc. and keeping everything as a string. Strong typing within integrations usually is unnecessary. The one exception I often make is to transport dates as a Java date object–this makes many things simpler. But I also use a W3C formatted date/time string as the common format.
I’m encountering the exact same problem. We have some documents that are published to us, which have java.util.Dates defined in them - this is outside our control.
We’re currently testing our services by manually crafting the XML for broker documents then publishing them to the broker.
Ideally, the test team would be able to use the use the actual upstream XML document for the IS to pick up as this is more tester friendly (rather than publishing to the broker the brokerd document XML)
So we tried xmlStringToXMLNode then xmlNodeToDocument, but as already noted, the date becomes a String and the document cannot be published.
While we can hard code the date fields to manually convert and overwrite on the pipeline into the document, this becomes a bit laborious in our case (and how about document lists?).
I’ve tried for some time to find a generic solution (including giving a Java service the java.util.Date fields in a attempt to replace the string date in the document on the pipeline) but haven’t had any luck.