Looks OK, SOAP based, XML (D'uh) so simple enough.
But for authentication they need you to get a "token", which is a chunk of raw XML sent in a CDATA response. Eeeeewwww
Well, I tried that, and parsed it, and included it in the request (with namespaces and all) and it failed. Given the way XML canonicalization works I expected to have to send character for character "as is". That is a horrid bodge to my XML library, but what the hell?
But still not working.
So why?
Well, not sure yet, but maybe HMRC do not understand summer time.
A request for a token at 17:05 BST gets a reply that includes...
IssueInstant="2013-04-06T16:05:00.185Z"Well, given that I just pressed the button when my watch said 17:05, that is pretty good, only 185 ms out :-)
For those that do not know, the Z on the end means Zulu time, i.e. GMT or UTC, not BST, so 17:05 being 16:05:00.185 is good.
But hang on ...
AuthenticationInstant="2013-04-06T17:05:00.185Z"
Thats an hour out... Worrying...
Then this bit...
<conditions notbefore="2013-04-06T17:05:00.185Z" notonorafter="2013-04-06T21:05:00.185Z">
That is not good. It looks like we can't use the token for an hour.
How hard is it to understand the basics of British Summer Time, FFS.
Update: Even waiting an hour did not help, and my error was using wrong servers and SOAP action in wrong places. They did not document simply what they are but provided an XML definition. They then use test system URIs in the namespaces on the live system which fooled me, but turns out to be what they want for it to work. Anyway, we now have a working DPS system, and all ready to do an Employer Alignment Summary this week ready for our first RTI submissions this month. Overall it has been probably less than a day's coding, and getting replies from HMRC test team on Sunday morning is impressive. I am sure there are several more hurdles though...
BST and any daylight saving times seem particularly hard to understand.
ReplyDeleteEvery single major release of iOS (the Apple flavor, not Cisco's) can't cope with daylight saving times and alarms. Alarms not ringing, ringing twice, ringing too late, too early, even switching am to pm or screwing up only workday repetitive alarms.
So obviously it only a few people have a clear understanding of the concept. Maybe we should start a "BST Switch consultancy service"...
HMRC probably subcontracted the XML stuff to the lowest bidder and got a bunch of people who'd never written a live system before.
ReplyDeleteI find it odd that Americans, who around 6 hours out of UTC, have so much trouble with timezones - we've got an excuse as we live in GMT for half the year so it can slip past testing.