Recently, I got in a situation where a customer reported data loss. More specifically when sending an outbound email in reply to an inbound email. Where at the moment the user hit the ‘Send’ button, the actual email composed by the user got lost and instead an empty email was sent. Quite annoying, to say the least. More annoyingly, for the end-user: this event would go completely unnoticed. Not reproducible and with a fairly low frequency, but reported by many different users. Finding a pattern led nowhere. Since Siebel leverages the CKEDITOR library for rich text editing, this was for me one of the suspects.
I implemented a presentation model to catch the EmailSend method on the “Comm Outbound Item Form Applet New” applet, in order to get some grip on the situation. I found that by logging each and every EmailSend event through the central error logging facility exposed as business service in this implementation, that somehow in certain situations truly the data in the CKEDITOR control would be different from the data saved on the business component (and sent…). But still now clue on the “why”.
Typically a situation where you’d want to have an eye on each of the user’s browser consoles to see if any uncaught (or caught) error got reported. And especially that is a problem. Where debugging Siebel traditionally has been pretty much server-centric, the browser plays a huge role these OpenUI days.
I reckoned, I’m surely not the only one facing this challenge! Imagine you run a multi M$ or B$ eCommerce site, you surely want to have comfort and confidence that your platform runs fine on any browser or device. Assume that on Android 3.x using Firefox as browser you cannot conclude a purchase because of some unexpected error happening which no developer nor tester could have foreseen (“who runs Android 3.x with a Firefox browser”)?
It turns out there are quite some error handling frameworks out there: Sentry, Airbrake, Rollbar to name a few. And Bugsnag. Bugsnag seemed to be pretty flexible. Bugsnap is a paid service. Now one issue which might immediately come to mind: can we use such as cloud service? I agree, that might be a showstopper from a data-privacy or company policy point of view. But Bugsnag also allows for an on-premise ‘implementation’. That said, I was interested enough to give it a go. And really, working with Bugsnag is child’s play. After creating a trial account, I got it working in a matter of minutes just by adding the Bugsnag “notifier” library per Siebel manifest administration. Setting the Bugsnap API Key in the browser’s console followed by a call to the notifier’s Bugsnag.notify() and bob’s your uncle.
So that worked out pretty fine so far. And that’s interesting too, through the Bugsnag notifier you’d have an alternative for SiebelJS.Log() for situations where it would make sense. But more importantly I needed to verify whether those nasty uncaught exceptions would be be caught by the Bugsnag notifier too, which should be the core reason to use it after all. The Bugsnag notifier hacks into the window.onerror to achieve this. To test this, I just added a throw() to one of my existing customizations to simulate it.
You’d already see the exception’s trace mentions ‘_super.bugsnag’. So something’s going on!
Unfortunately, not too much detail. But at least the Bugsnag notifier logged the exception. In the next post I will explain how to integrate Bugsnag properly into Siebel and how to add more Siebel contextual details whenever an uncaught exception gets logged (or when an error is logged by code per design or for debugging needs). To eventually get something similar to this….