mscrm

Javascript development often takes the backseat, compared to C#, while extending Dynamics CRM. There are valid reasons for implementing a business logic as a plugin or a custom workflow step. But, in this post I will talk only about how to effectively manage and write Javascript code for Dynamics CRM. These are my primary objectives:1.)Manage dependencies
2.)Control load sequence based on dependencies
3.)Promote code reuse
4.) Organise code effectively into manageable chunks

Dynamics CRM, doesn’t offer anything out-of-the box for accomplishing any of the above objectives. Ecmascript 6 will offer the much needed module feature1, but until all major browsers support Ecmascript 6, we can use any of the open-source script loaders. My framework of choice is require.js.

Current Process

The current process for Dynamics CRM script development:
1.)Create JS web resources
2.)Add web resources to the form
3.)Add event handlers for form load, form save and field change

Javascript webresources may not load in the order specified in the form2. This could cause script errors if you are expecting the scripts to load in a certain order. It is also cumbersome to add all the required scripts and setting up the event handlers.

Using require.js with Dynamics CRM 2013

RequireJS3 automatically loads dependent scripts/modules, when they are needed. Dynamics CRM, caching strategy4 means that we also need to know the magic string in the web resource url, so that we can use it in require.js. There are two ways to get this magic string:
1.) Parse it in the url of the initial loading script
2.) Use the undocumented WEB_RESOURCE_ORG_VERSION_NUMBER4 global

Setup

I have the following scripts
1.)Require.js – Require JS library
2.)Main.js – Initial loading script
3.)Form_script.js – Form script, contains event handlers for form load, form save and field change
4.)Common_script.js – Script library to be reused throughout the CRM organisation

Plugin Registration tool’s profiling functionality has made plugin debugging a lot easier. The ease of use can sometimes tempt you to use this feature in the early stages of plugin development, to analyse what is state of PluginExecutionContext, InputParameter, Pre/Post Images etc. This gives you an understanding of the plugin’s flow and state, but only after it has been deployed to CRM. This, however, is not unit testing.

Right click on Microsoft.Xrm.Sdk in your unit test project and click on Add Fakes Assembly

Right click on System in your unit test project and click on Add Fakes Assembly

After you have added all your references you project should look something like this

Okay. Now what?

Now you can start writing your tests. To write an effective unit test you should start stubbing some classes in the Microsoft.Xrm.Sdk and overriding their behaviours. You have to use the following stubs inplace of their originals:

StubIPluginExecutionContext

StubITracingService

StubIOrganizationService

StubIServiceProvider

Scenario

You are developing a plugin which prevents the user from creating more than one opportunity for a customer.

Dynamics CRM 2013 has done away with the ribbon interface, with the exception of a few forms. There are also some changes in the subgrid behavior. These are1.) When you select a record in a subgrid ribbon menu no longer appears on top of the page2.) Clicking the “+” icon above the subgrid, may display an inline lookupI say “may” because it depends on the relationship. An inline lookup is only displayed when the parent entity field is NOT mandatory on the child record you are trying to create. When the inline lookup is displayed on a subgrid, there is no way to access this inline lookup control using CRM Client API.There is however, an unsupported way to set the default view on an inline lookup. I am using Ribbon Workbench, by Scott Durow, as it makes the process much easier.First notedown the name of the subgrid. In this example, I am trying to customise the contact subgrid on account. Note this down, as it is required in the later steps.

In this case, the subgrid is called accountContactsGrid. Next we have to get the GUID of the view we want to default to. There are two ways to do this: looking into the database or using Developer Tools. Open an account record, and try to add a contact to the subgrid. When the lookup selection popup appears, use Developer Tools to get the GUID of the required view. In this case, we want the GUID of Contacts: No Campaign Activities in Last 3 Months view. Note this down, as it also required in the script we will add later.

Open the solution with the contact entity in Ribbon Workbench. In this case I am trying to change the behavior of the contact subgrid. Ribbon Workbench displays the following subgrid menu for the contact entity.

Since this is a 1:M relationship and account relationship field is not mandatory on contact record, the first Add Existing button has to be customised. Right click on the first Add Existing button and click Customise Command.

The default command behavior is as below

The Mscrm.GridRibbonActions.addExistingFromSubGridStandard function is called with the entity typecode and the grid control as parameters. This has to be changed to call our custom function in a JavaScript webresource.

Create, upload and publish a new Javascript webresource with the code below. Since the contact entitity can be a subgrid in other entities as well, we want to restrict this behavior only to account entity. We can further lock down this behavior to a specific form on the account entity, if we want, but we are not going to do this in this instance.

Notice that we are using the name of the subgrid and the GUID of the required view. After uploading this script as a javascript webresource, we have to change the behavior of the “Add Existing” button using Ribbon Workbench. Change it to call our NYR.addExistingContactSubgrid function. In this case my webresource name is nyr_contact_ribbon.js.

Finally, publish the changes using Ribbon Workbench. Now, when you try to add contact from the subgrid in the account entity, Contacts: No Campaign Activities in Last 3 Months will be the default view.

I have used this to control the inline lookup behavior on a 1:M relationship, but the same approach can be followed for a M:M relationship as well. Notice that I have also hardcoded the GUID of the view. You can use SOAP/OData to retrieve the viewid using the viewname, to improve this code. This is an unsupported customisation, so please use it at your own risk.