For my SOAP requests to 3rd party I have to format the datetime as datetime-tz for UTC, to do this I am pulling a datetime-tz out of the database in UTC+8 (Western Australian Standard Time) then converting it to UTC by doing DATETIME-TZ(datefield, 00).
This works perfectly (though when I do 1 of the datetime-tz requests I have to strip out the +HH:MM and change it to a "Z" but that isn't really a problem, however, when the response comes back from the 3rd party it has an 'AuthDateTime' field which is also in UTC.
I have checked the original SOAP response XML that I got back (before the parser ever gets its grubby little mits on it to put the XML into a dataset) and what I am getting back is the following:
<tns:AuthDateTime>2016-06-13T05:17:33.000632</tns:AuthDateTime>
When I check the resultant temp-table after the parser has done its job, it comes back with (and this is what also gets stored in the DB:
16/06/2016 05:17:33.000+08:00
This is a bit undesirable (I cannot change how the 3rd party is returning it, maybe their format is too much for the parser...)
Is there any easy way to make it so that when the temp-table (and the DB) see it, it has +00:00 on it instead?
There's no time-zone on the datetime value returned, so the AVM assumes the session zone. To store the date, you can add the timezone if you know it. The DATETIME-TZ() function has a variant to that takes a DT-TZ value and a timezone, so you can convert it to whatever timezone you need.
The snippet below shows this
def var c1 as char. c1 = "2016-06-13T05:17:33.000632". session:date-format = 'ymd'. message
'this is automatically converted using the session timezone:' datetime-tz(c1) skip datetime-tz(
datetime(c1),
+000)
view-as alert-box.
Indeed so, unfortunately I can't do anything about that, that is how the 3rd party returns it.
The most I can do is try and get it into something I can deal with, which I managed to do by following the above steps for.
One of the many issues with having to deal with a 3rd party web service I guess.
The mismatch in dates (13 vs 16) is a typo I hope?
ummm, oops, yes, it is a typo, sorry, should have been 13/06/2016.
There's no time-zone on the datetime value returned, so the AVM assumes the session zone. To store the date, you can add the timezone if you know it. The DATETIME-TZ() function has a variant to that takes a DT-TZ value and a timezone, so you can convert it to whatever timezone you need.
The snippet below shows this
def var c1 as char. c1 = "2016-06-13T05:17:33.000632". session:date-format = 'ymd'. message
'this is automatically converted using the session timezone:' datetime-tz(c1) skip datetime-tz(
datetime(c1),
+000)
view-as alert-box.
You might be able to use SESSION:TIMEZONE=0
The problem with this is that I never get to see the datetime in the format that the XML file has it, the SOAP parser converts the datetime to a +08:00 when it puts it into a temp-table for me.
Actually, n/m, I can use that to fix up what gets stored in the database, basically pull out the datetime-tz with the incorrect timezone, convert it to a datetime then back to a datetime-tz with the correct timezone.
with regards to 'session', is that per-agent when it comes to webspeed? or is it going to be global across all webspeed agents?
the XML has the datetime (2016-06-13T05:17:33.000632) without any timezone specified. so it's a datetime not a datetime-tz
looks like the soap parser is putting in the session timezone when it makes a datetime-tz out of it.
Indeed so, unfortunately I can't do anything about that, that is how the 3rd party returns it.
The most I can do is try and get it into something I can deal with, which I managed to do by following the above steps for.
One of the many issues with having to deal with a 3rd party web service I guess.
I'm not too familiar with Webspeed , but I SESSIONapplies to each agent, or AVM (ABL virtual machine). Someone please correct me if I'm wrong.
The SESSION is per agent in webspeed terms . It can be changed in code but all agents will be started with the same value (specified in the properties file)