Wednesday, July 20, 2016

JavaScript Best Practices for Microsoft Dynamics CRM 2015

One of the great features of Microsoft Dynamics CRM 2015 is that it has the ability to write JavaScript to interact with the system. JavaScript has many capabilities, and it’s important to know the boundaries of what you should and should not do with JavaScript in regards to what Microsoft Supports respective to Microsoft Dynamics CRM. In today’s blog, we will go over the guidelines for dos and don’ts when using JavaScript with Dynamics CRM. Let’s get started! 
Below are some common things you can do with JavaScript in Microsoft Dynamics CRM:
1. Interact with the CRM UI
  • Modify Fields and Controls
    • Show, hide, set and get values
    • Save and refresh forms
    • Call actions based on form navigation
  • Modify the menu bar and navigation actions
  • Launch a form that the user has permissions to view
  • Launch dialogs
2. Push\Pull Data
  • Query and manipulate data from the form
  • Query the user’s properties and security permissions
  • Query and manipulate data from other entities
  • Query and manipulate data external to CRM
3. Interact with Business Process Flows
  • With the Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM Online 2015 Update, the client-side object of Xrm.Page.data.process allows you to interact with business process flows in your scripts
When dealing with the CRM UI, the SDK documents the exposed objects and the properties that are available to interface with. As a general rule, you should adhere to the exposed objects and interact with them via the documented properties and methods using the Xrm.Page object model. 
Many developers who know JavaScript and understand that these controls can be found in the HTML tend to go straight to the HTML DOM and manipulate the UI in this manner. This basically bypasses the supported means that is documented in the SDK. The problem with this approach is that the Microsoft Dynamics CRM development team reserves the right to change how pages are composed, all the way down to the ID values for elements. So by using the Xrm.Page object model, you can be assured that your code is protected from future changes in how pages are implemented. 
For example, if you were navigating the HTML DOM structure (instead of using the Xrm.Page protocol) and using window.getElementById or even manipulating the innerHTML or outerHTML, an update rollup or a service pack could cause your script to fail. Additionally, the DOM structure can be different from one browser to the next, so using this navigation method introduces risk, while using the documented API of the Xrm.Page object model has no navigation risks. CRM 2015 On-Premises and CRM Online support the following browsers:
  • Internet Explorer on Windows
  • Firefox on Windows
  • Safari on Mac OS X
  • Chrome on Windows or Google Nexus 10
Factors to Consider when Using JavaScript
Here are some performance items to keep in mind:
1. Limit the number of Script libraries your form references. Performance can lag when you view a form for the first time that has multiple scripts. Starting with CRM 2013, scripts are loaded asynchronously and any onload event will fire as soon as the scripts are all downloaded. Additionally, if your OnChange or OnSave events require certain libraries, do not load them with the OnLoad event because of the perceived performance lag.
2. Remember to collapse all the tabs when you design your forms so that the page can load as fast as possible. All elements inside the sections of the collapsed tabs are not loaded until the tab is opened. There is a TabStateChange event that can invoke your code as needed.
Here are some factors to keep in mind when comparing Business Rules and JavaScript:
1. Capabilities: At a high level, Business Rules are not as robust in their functionality or capabilities as JavaScript, but they are easier to create and maintain by non-developers. Business Rules provide a subset of capabilities that JavaScript provides. The following list shows the business rule action capabilities:
  • Set and clear field values
  • Set field requirement levels
  • Show and hide fields
  • Enable and disable fields
  • Validate data and show error messages
2. Scope:
  • JavaScript can be fired on any form and field event that’s exposed via the SDK. Business rules can only fire when the form is loaded and when a field value changes, not when a form is saved (unless the scope is set at the entity level).
  • JavaScript that is associated with the OnChange event for a field will not be fired as the Business Rule sets the value of the field. Meaning, if a Business Rule changes a field value, the OnChange JavaScript will not be invoked for the changed field. This is a good thing, because it ensures that recursive loops are avoided.
  • It’s important to know that CRM 2015 executes JavaScript before Business Rules are executed. If you have multiple Business Rules, CRM executes the Business Rules in the order that they were activated, executing the oldest FIRST and the newest LAST.
  • In CRM 2015, Business Rules can be defined to run at the entity level instead of strictly at the client UI level. This means that regardless if the user invoked the rule via form navigation, or if a system via integration interacted with the platform, the behavior of the business rule will be adhered to.
This adds additional complexity into your system integration design because there is another place within CRM that exposes business processes that can affect system integration. On the positive side, you can rest assured that if you do define your Business Rules to run at the entity level, your system integration will adhere to the rule whereas if you had used JavaScript, the logic would not be invoked by system integration. So, apart from technical aspects, there are fundamental business process aspects to consider when using JavaScript vs. a Business Rule.
The fact that JavaScript only executes when a user is manually interacting with the forms presents a challenge when designing your solution. If you use JavaScript to cause certain validation or actions and then you realize that you need to integrate with external systems that also need that validation or subsequent actions, you’ll need to rethink your strategy on how to accommodate validation, etc.
For example, let’s look at a scenario where you have a form and you are using JavaScript to query different data, evaluate it, and then cause other subsequent actions to occur. You might have a Project Type drop down on the form and you write JavaScript in the OnChange event to look at the value selected. If the Time and Material option is selected, your code then restricts the Payment drop down field to only two valid payment options that you want the user to select from. Since this only happens in the UI, any other systems that could also update the Project Type need to have validation to ensure that invalid Payment options aren’t saved. In this case, you will have to rethink the whole process to allow plugins to evaluate data and only permit the expected values and not rely solely on client side JavaScript. So when using JavaScript, you need to understand that it is only executed when a user is using the user interface.
If the business rule was defined to run at the entity level, the server will execute the rule after any synchronous plug-ins are executed for the entity.
That’s all for our blog today! You can learn more about Microsoft Dynamics CRM 2015 on our website. If you want more tips and tricks like this one for CRM, make sure you sign up to receive our monthly newsletter so you can stay up-to-date with everything happening in the world of CRM!

No comments:

Post a Comment