Catch Those Uncaught Exceptions From Your Browser In Open UI – Part II

bugsnag-logo-1A few weeks back I posted an initial article about my experiences with Bugsnag. On a quest to get more insight in ‘what happens in the browser’, because by and large ‘what happens in the browser, stays in the browser’ I bumped into this neat tool. In this space of error reporting and incident management tools, alternatives exists such as Airbrake, Sentry, Rollbar and Raygun to name a few. I choose for a proof of concept Bugsnag because it appeared to be simple to integrate as well as it’s offered as 100% free trial.

Deploying complex web applications such as Siebel which are built on top of a bundled set of libraries such as JQuery, RequireJS and CKEditor poses a real challenge. Add the diversity of browsers in the mix, and you have a nice cocktail. Just the believe that functionality will work cross-browser is an utopia. Gaining the insight in ‘what happens in the browser’ can be considered a must-have, especially in a diverse environment where Siebel is exposed on different browsers, platforms, devices, in managed desktop environments or to users in the uncontrolled big, bad, world out there.

Setting up your trial account with Bugsnag requires just a few clicks. In return you will be provided an API key and access to your own Bugsnag dashoard.

The Bugsnag ‘notifier’ library is available to be integrated in any web application. Integrating it with Siebel turned out to be extremely simple. Just adding the library as ‘Application’ / ‘Common’ did the job. Setting the apiKey followed by invoking the notify() function in the console is enough to test the essentials.

Bugsnag.apiKey = “d31fd6cda4a46a9f4e251207c8xxxxxx”;

Bugsnag.notify(“SBL-ERR-BUGSNAG”, “Log this error”);

Logging onto your Bugsnag dashboard should show within the blink of an eye the error!


Nice. But we need to do better!

When Bugsnag intercepts an uncaught exception, it would be useful to have some contextual information being sent alongside the call stack, won’t it? For that particular purpose, the Bugsnag API allows to add ‘meta data’ by using the ‘beforeNotify’ function.

I ended up with a straight-forward piece of code, which loads as Application / Common file.

  1. It creates a new class ‘SiebelBugSnagNotifier’
  2. Next it creates a dependency on the Bugsnag Javascript API (‘bugsnag-2.min.js’)
  3. Following the apiKey is set (I opted for sake of simplicity to hard-code the key…)
  4. Next the beforeNotify() function is implemented
  5. The ‘metaData’ and ‘user’ JSON objects are populated with contextual information. Other than essential static details such as Login Name, User Responsibilities, View Name & Title – I added also the raw data (if available) from the applet which had focus the moment the exception got caught.


Now, what happens when I on-purpose generate an uncaught exception? Well, first of all we get a nice call stack leading quickly to the error. And yes, I made a type calling ‘setTimeout’ in the /siebel/custom/CheckCommitPendingPR.js!


Further, the view context gets provided…


As well as the raw data…


And the logged in user details too…


All together, quite happy with the end-result. And other than logging uncaught exceptions, calling Bugsnag.notify() anywhere in your code, could be an alternative for SiebelJS.Log(). But use it sparsely in that case, since it will definitely incur overhead. And we do not want to slow-down Siebel, do we?

You can grab the code here. If you have thoughts, let me know.

– Jeroen


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s