One of the big selling points of the ESB Portal is the fact that it is so easy to resubmit messages, potentially even editing them prior to the resubmission.  This takes away a lot of the pain I previously had to deal with when thinking of retry mechanisms (one of the patterns I used before was to have the orchestration in error dehydrate, have an email sent out to IT administrators with HTTP links in them to either resume, suspend, or terminate said orchestration.  This could be a pain to implement though and tended to muddy up your orchestrations with non-core process logic).

However, one can’t just allow for the resubmission of messages which could potentially be edited without some kinds of auditing feature.  This is one of the areas where the ESB Portal shines, because it can audit all message resubmissions, listing the time of the resubmission, the resubmitter, the status of the resubmission, and the unedited and edited message.  It was more than a little irritating when I found that the dates being displayed on the Audit Log and the Audit Resubmitted Message Viewer page were showing incorrectly, upto years into the future in fact!  What’s even more irritating was that the dates on all the other pages appeared to show up correctly.

Last I checked it was still 2012

A quick query on the AuditLog table in the ESBException database showed that the date was actually being stored correctly, albeit in UTC.  So that leaves to reason that it is just being displayed incorrect.

Checking around the rest of the database, it is quickly apparent that most (or all)  of the dates in the ESB databases are held in UTC, and they’re definitely being converted to local time correctly in the rest of the portal, so what gives?  Time to do some code inspection and debugging.

If you take a look at the AuditLog.ascx file in the Admin Folder in the ESB.Portal project, you’ll see that a javascript method is used to convert the UTC data to local time as below.

Next step was to do some debugging and I was pretty surprised by the output.

As you can see very clearly, the UTCToLocalDate method is called with a parameter value of “23/02/2012 9:06:19 a.m.” but when a new javascript date variable is spun up passing this value in as the constructor, the new variable comes out with a totally unexpected value.  Obviously there are restrictions on what sort of string values you can pass in as constructors to the javascript date object because it just isn’t happy with the date time format that was used in this case.

So I figured I had two options to fix this problem.  Either I could get smart in the javascript and manipulate the utc string variable so that it conforms to a javascript date format, or I could see how the remaining ESB portal pages were handling their UTC to Local Date format conversions and implement a similar solution on these pages.  I chose the latter because it sounds that much easier.  I inspected the FaultViewer.ascx page in the faults directory in the ESB.Portal project and found that it was instead using a .NET helper class to the do the UTC To Local conversions and the date being passed in as a parameter was of the same format as the date passed in to the javascript method.

Ok, so to fix the Audit Log page, edit the AuditLog.ascx file in the admin folder in the ESB.Portal project so that the date section looks likes the below.

And now to fix the Resumbitted Message Viewer page, edit the ResubmittedMessageViewer.ascx file in the admin folder in the ESB.Portal project so that the resubmitted date section looks like the below.

I acknowledge that this most probably is an issue to do with the locale in our environment but I am loathe to make any changes to production servers, so this is the best fix for me.  Our servers are all set to the correct time zone, and the culture in the web.config files for the ESB.Portal and supporting services was set appropriately to EN-NZ,  but when I checked the SQL Server setup the language was set to American English, so this could be a part of the problem.

That said, this problem might also be New Zealand wide, or it could possibly even be global, I have no idea.  If any of you experience the same problem please do let me know where you are from, what time zone your server is set to, and what language your SQL Server is set to.