I’ve been spending some time recently helping customers getting started with Azure API Management, and recently ran into a small issue with the SOAP-to-REST feature that might trip others.
The issue in question came up because the request message on the SOAP service had a field of type
xsd:dateTime. When the Import API wizard imports the API WSDL, it does not appear to keep much track
of data types used, and so, it would generate a simple liquid template like this:
<sentOn>{{body.request.sentOn}}</sentOn>
We noticed that this was not working as expected: the service was returning an SAX error because it couldn’t parse the request. Using the API Inspector, we quickly realized the issue was the Date/Time format. The XML being sent to the service looked something like this:
<sentOn>9/2/2010 9:23:00 AM</sentOn>
This clearly was not in ISO 8601 format; the value was clearly being formatted in the U.S. English locale, which is invalid. To work around this, we edited the default policy generated by the Import API wizard, to use this:
<sentOn>{{body.request.sentOn | Date: 'o'}}</sentOn>
This forces the Liquid template to format the date/time value in the round-trip format,
which is ISO 8601 compliant. Unfortunately, this won’t quite solve the issue in every case. I’ve
noticed that in some scenarios (depending on what the input format looks like), API Management
won’t maintain the TimeZone information in the original value when using the o format (and sometimes
seems to round the time in unexpected ways). I presume this might be because API Management
is using DateTime rather than DateTimeOffset underneath, but I have no way to know for sure.
In the specific case I was looking at with the customer, we ended up using a custom format with no TimeZone information, since both consumer/service were in the same Time Zone and there’s no daylight savings time to deal with. If you’re in a different scenario, then ensuring all date/time info is in UTC might be worth considering.
