Best Practices for Microsoft Dynamics 365 Developments
Client Side Development
Following best practices will be followed for client side programming.
- Do not access DOM
- Use asynchronous data access methods
- Avoid use of ActiveX controls because they have known security problems.
- Avoid use of custom web pages.
- Ensure that custom web site runs on a different application pool account apart from that of Microsoft Dynamics CRM. This account should have the minimum access possible and one that does not have direct access to the Microsoft databases.
- Use plug-ins to apply business logic.
- Maximise client side validations instead of checking through plugin/workflow.
- The use of Silverlight for custom development should be avoided and HTML5 / Jscript / JSON used in preference
All common methods will be available in the following three class files:
abc_/Scripts/XRM.Global.js: This file will have all common methods for Form and Attributes.
abc_/Scripts/XRM.OData.js: This file will have generic methods to perform ODATA operations.
abc_/Scripts/XRM.SOAP.js: This file will have generic methods to perform SOAP operations.
These three classes will be wrapper classes around their general methods like CRUD operations for ODATA and SOAP.
Server Side Development
Following best practices will be followed for server side code development.
- Use multiple threads
- Allow the system to create GUIDs
- Customisation through code should be kept to a minimum where possible. When development is required it shall be done in accordance with the Microsoft Dynamics CRM SDK
- Use common methods like “CreateRequest”, “DeleteRequest” and so on instead of “Execute” method.
- Use early-bound types
- Limit the data you retrieve
- Adjust proxy settings on the client
- Do not modify CRM database by any other means than SDK.
- Minimise execution of plugin in administrator context as this code may access information that the logged-on user does not have access to.
- CRM 2013 development kit will be used for development of plug-ins which provides base class and single assembly for developing all plug-ins.
- Register pre or post images as applicable to get the attributes which are not changed on the entity.
- When writing a plug-in on update message, specify the filter attributes, so that plug-in gets called only when it is required.
- Enable early bound proxy types on the IOrganizationService object for early bound queries.
- Do proper exception handling in plug-ins.
- Avoid registering plug-in on “Execute message” as execute method will be called multiple times.
- Do not use class level variables in plug-in
- Write “atomic” custom workflows. Do not put whole logic in one big custom workflow. If a custom workflow code needs to do three operations then better create three custom workflow activities rather than one.
- Stop the workflow explicitly.
- Create child workflows if same steps of activities will be used in multiple workflows.
SQL Server Reporting Services:
Following best practices to be followed for Sql Server Reports development.
- Attributes Obtained Through Filtered Views: Although field names in Microsoft Dynamics CRM are case-sensitive and in mixed case, attribute names obtained through filtered views are all lowercase.
- Drop-Down List Attributes: All drop-down lists (pick lists) have two associated fields for every string in the list. For each string, there exists a value (code) field and a label (name) field, for example, listcode and listcodename. Reports display the label field and use the value field for numeric comparisons.
- Entity Attributes: For each entity table in the database, all primary key fields are in the name format entityid, for example, accountid. Each entityid field has an associated entityidname field that contains the value that should be displayed in reports.