Logging and Handling Microsoft Dynamics CRM 2013 Exceptions – Part 1

In this 3-parts post I would like to suggest a general approach and solution for logging and handling exceptions in Microsoft Dynamics CRM 2013 implementations.

By exceptions, I don’t mean Microsoft Dynamics CRM product core exceptions which occur from time to time. These are logged by various designated repositories (such as Event Viewer and CRM Trace) and beyond our reach anyway, certainly in Online deployments. I do mean unexpected events that arise from custom code written in both server and client side in most Microsoft Dynamics CRM 2013 implementations. These events are usually related to poorly written code, unexpected customization changes or external resources that are beyond your control.

Here are some examples for such exceptions:

  • Custom JavaScript code accessing an attribute of a an object with value of null
  • Custom JavaScript code accessing a field which was removed from the entity form
  • Custom Workflow Activity trying to access an external web service which does not respond or returns an error
  • Plugin code, triggered by an Update event, accessing an attribute which was not updated

Why is it important to log and handle such exceptions? Here are some of the reasons:

  • Bad user experience: When a custom code exception is not handled, it often bubbles to the user interface. This means a vague message is displayed to the end user, a message that he probably can’t handle or tell if and how it affect the business process he is attempting. 
  • Potential business damage: When a user encounters an exception he usually does one of two: ignore it and try again or report the system administrator.
    The first option is bad. It means your application is not healthy and you, as system administrator, are not aware. Beside your users getting frustrated, this may cause data integrity problems, junk data, missed business opportunities or other business related problems.
    It can cost you money!
  • Interrupting your users work: If a user does report an exception to the system administrator, he usually supplies minimum details, less than required to solve the problem without interrupting him to try and reproduce the exception. While some exception details are available to the user (approximate time, attempted business process, error message etc.), other critical details (Internal exception, Stack trace, source component etc.) are hidden from him. 
  • Security breach: Some unmanaged exceptions messages can expose internal mechanisms and supply hackers with details that can help them damage your organization.

Unfortunately, exceptions are part of any business application and cannot be completely avoided. The purpose of the suggested approach is to improve exception handling experience.

So, here is the business problem. In the next post I will describe the suggested solution approach, while the third post will discuss the actual implementation details.

Stay tuned.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s