Creating a framework for Microsoft Dynamics CRM 4.0 (client-side JS and server-side .Net)
Recently I had to create a framework for using (programming with) CRM. The first reason is
that when you want to do some tricky stuff in JavaScript, barely everything is considered a "hack"
in CRM, because you have to manipulate the DOM (Document Object Model) of the CRM pages.
For example, if you want to hide a field, you have to do a crmForm.field_id.style.display = 'none'; This
is officially unsupported but widely used. On the other hand, if you want to disable a field, you can
do crmForm.field_id.Disabled = true; This is supported because the "Disabled" property is CRM proprietary.
The other reason we wanted to create a framework is to create some base classes to encapsulate some functionnalities
and to enforce some development rules. For example, we decided to create 2 base classes for plug-in development.
Synchronous plug-in base class
Because we use synchronous plug-ins to do some server-side validations (before the create/update/delete happens) and
set some values on the DynamicEntity, we decided to create to abstract methods: Validate and ExecutePlugIn. The
Execute function of the plug-in is our real entry point, but the developper does not have the right to touch
this method; he has to override Validate to do his pre-validations and then return True or False wether the validation
passed or failed.
In addition to this, the Validate function is used to add functionnal messages to help the user
understand why the validations failed (if this is the case). If the Validate function returns False,
the real Execute method of the plug-in throws an InvalidPlugInExecution exception with all the messages
concatenated and separated with a distinct sign (like a big dot, a semicolon, an incremental number, etc...).
If the Validate function returns True, the next step in the Execute method is to call the ExecutePlugIn method that will do
the real job (if there is something to execute, because sometimes the plug-in is only there to do validations).
To make sure everything is trapped and logged, the ExecutePlugIn method is surrounded with a try catch. Try Catch's only function
is to log to the event viewer all the details of the exception and informations of the plug-in context and then rethrow the exception.
Asynchronous plug-in base class
Our asynchronous plug-ins are much more simpler than our synchronous plug-ins. The Validate function does not exist; there is only a
ExecutePlugIn method, and that method is surrounded with a try catch that catches all kind of exceptions and log them to the event viewer.
It does not rethrow the exception because when an asynchronous plug-in fails it cannot stop the CRM execution and display a message
to the user so the only thing we have to do is to log the error to the event viewer for further investigation.
HttpModule to manage the visibility of fields in entity forms
Because we wanted to provide a simple way for our developpers to enabled/disable/hide/display fields individualy on every entity form for each
display mode (create/update/bulk edit/disabled/read-only), we created an HttpModule that is supported by a .config file in which we defined
a custom configuration section (which defines every rule for every field). All our rules are based on the CRM security roles.
We choosed an HttpModule because we wanted a way to inject JavaScript code on every CRM page at runtime. We decided that this was a
safer solution than editing CRM ASPX pages. An HttpModule only involves that you modify the web.config file.
HttpModule to include JavaScript files in entity forms
For JavaScript development we decided to write every line of JS in .js files, not directly in the CRM. This has been decided for 2 major reasons.
First, I discovered that when you write a lot of JS code in CRM entities OnLoad and OnSave methods (as well as field's OnChange method) CRM
sonly brings your JavaScript to the client side half of the time. We all know that client-side scripting is weak, but normaly it works more
than half of the time. When we write some .js files and include them on a page, the browser always load them easily so we decided that all JS
code will be placed on .js files. Thoses files are splited so we have between 5 to 20 js files per entity.
Then, to include those .js files with <script src="scripts.js"></script> tags we use an HttpModule to inject those lines of HTML dynamically on each entity
page that needs to have those files. This HttpModule is supported by a .config file that maps .js files with entities where those files needs to be
included. We only include .js files where they need to be included because we want to keep the CRM as performant as possible.
There is more on our framework but with this you have a very good start !