When Cool Technology Isn’t
When Cool Technology Isn’t
By: William Hageman | Consulting Services
Sometimes technology outsmarts its creators to the detriment of the end user. Recently we ran into a situation where a very clever piece of software was just flat out used one too many places.
We had an 11g Imaging client using WebCenter Enterprise Capture, (WEC), go live in 15 countries simultaneously. Part of the ROI to the client was WEC’s ability to let end users capture and index locally. So day one we had documents being indexed in over a dozen time zones. Other than a few rogue, (read ancient), scanners being problematic the roll out was painless.
A few days later we started receiving reports from the Brazil office that the Invoice Date the users claimed to be entering during the Indexing cycle was showing up in downstream applications as the day before. Had to be operator error, right? But they claimed it always happened. The home office looked at the invoices they were indexing, no problem. Then Australia chimed in with the problem, happening consistently. So I tested it on our internal systems, consistent changing of the Invoice Date occurred. After a quick note to revise our test scripts to actually look at the Invoice Date, the hunt for the cause began.
I’ll skip to the end game, locations in earlier time zones than the main office, and data center, experienced the issue whereas those in later, or the same, did not. This is where slick technology being used where it shouldn’t be comes in to play. WEC is very browser aware, using the locale and time settings of the local client system when displaying data and labels. To facilitate this time and dates are stored on the central server in Zulu, Greenwich, time. This allows that time or date to show correctly no matter where the data is brought up and shown on any WEC application. Cool. But…
The end users entered the Invoice Date from a calendar control. When they picked a date, say February 15th, in the Brazilian time zone, (Z -02), it was stored in the browser as 2015-02-15T00:00:00 but was written back to the server, in a US time zone, as 2015-02-15T02:00:00, (Zulu). But when read by the WEC Commit application the date was converted to 2015-02-14T20:00:00, (Z -06). OK if it only is used again by another WEC client but when committed out to WebCenter Imaging, (WCI), neither WCI nor the server knew what time zone it came from so it got committed as the 14th. Ooops!
After a conversation with Oracle it became evident that there was no “Good” fix. And since it was a “Cool” feature, albeit having gone rogue in this case, it wasn’t considered a bug that needing fixing.
The solution presented below has been working around the globe for over 6 months. It is ugly and crude and I don’t believe it will work with the server being in Europe or Asia, (anywhere Zulu +), without modification. It simply shifts all datetime fields, with the exception of ScanDate, to being 6 in the morning. This time needs to be modified when used to reflect the WEC server’s greatest difference from Zulu. Remember daylight savings time if applicable. To use the earlier example the Brazilian time of 2015-02-15T00:00:00 gets written back to the server as 2015-02-15T08:00:00, (6AM plus Brazil’s -02 shift). When pulled up at the US time zone server by WEC Commit the datetime becomes 2015-02-15T02:00:00. WCI gets it as 201-02-15. Not the least bit slick but it is working for the client. If the server gets moved, read DR, to a different time zone things will get slewed.
Caveats aside, it is possibly the only way to circumvent the “Cool” internationalization feature that is used a little too much in WEC. Plus it is a good example of several uses of the JavaScript in WEC and may spark a better idea on your part. Just be careful where you use this cool technology.
