I just wanted to write something down regarding my recent journey into the world of Microsoft Dynamics CRM. The main focus will be on custom development within CRM, which includes the core framework, Client and Server extensibility, the SDK and managing customizations. I won’t be digging very deep in the CRM domain related processes and assuming that you’re somewhat familiar with tracking sales, marketing and customer care.
The theme is basically: What does development in Microsoft Dynamics CRM look like.
Dynamics CRM expectations
To keep a long story short, I had to look into Microsoft Dynamics CRM. Sometimes in life you just have to deal with the lesser-interesting projects / technologies / domains. You just can’t be lucky all the time… Well, this was my initial thought. Not fully fair to say given that I haven’t read up on any technical details or even seen the product. However, I do know that CRM isn’t the domain of my choice. There are definitely interesting challenges in this space, which are requiring innovative solutions. But don’t believe that integrating an exciting third party service, leave alone developing one, is part of a typical Dynamics CRM implementation.
To get up and running quickly, I’ve decided to use the cloud based offering instead. I’m not yet interested in the IT-pro side of Dynamics CRM. A 30 day trail version can be requested here: http://www.microsoft.com/en-us/dynamics/crm-free-trial-overview.aspx
Note: I’ve used the following resources:
- Microsoft Dynamics CRM 2013 Unleashed
- Microsoft Dynamics CRM Customization Essentials
- Several Dynamics CRM training sessions published on Pluralsight
Looks like a designer missed the deadline…
Designers, Wizards and builders
The product contains many Tools for building CRM related assets. It’s essential to know these tools given that they are responsible for creating and altering fundamental objects within Dynamics CRM. By default, the tooling is already capable to handle complex scenarios, allowing Consultants / Developers to build Entities, Forms, Views, navigation assets and the like.
I won’t be focusing on the Designers/Builders/Wizards, but I do believe that the developers are playing a important part when it comes to change tracking, scripting/packaging environments and applying best practices. In addition, it’s not always as straightforward as it looks. The system, just like every other piece of software, has its constraints and it’s up to the developer to know how to handle those properly.
Note: I understand that everyone has different interests, some like to work more closely with the business and others like to dive deeper into the development part. Unless you’re working for an ISV, the CRM environment might be more interesting for people who like a bit of both, but leaning more towards the business side.
Extensibility and Development
Below I’m including a list containing common extensibility points. Most of them work in conjunction with the designers other can be used within the same application domain or called from a different environment. As mentioned before, make sure to do some research before building custom assets. Dynamics CRM already supports a lot of common and advanced scenarios out of the box and don’t forget to leverage the rich ecosystem of plugins available.
Note: The Dynamics CRM SDK contains many code samples, including cross platform integration.
1) Client side Extensibility – Form Scripting
Form scripting gives the possibility to interact with form controls, allowing the implementation of complex dynamics business rules within a form. The script will be invoked based on Form Events and often used to improve the user experience or automaton.
Don’t forget that Dynamics CRM supports non-IE browsers and therefore required to adhere to web development standards.
- Interacting with form controls, Data and Context (http context)
- Xrm.Page API Should be used, don’t depend on the client side UI.
- Runs within the users security context
- Web resource can be shared across multiple forms
- Web resource can be included into a deployment package
2) Client side Extensibility – Custom Controls
You can even take this a step further by including HTML based Web resource. The HTML based Web resource can be associated within an existing form, functioning as a compound control. It’s not that hard to create these types of controls when using the CRM SDK. But there are some restriction and naming conventions that you have to read up on.
When having complex logic, including a rich client based control can simplify the form or enable advanced business logic not possible using the default input types and form scripting. What’s important to know is that the code will execute within the same context and therefore able to call the REST based API.
3) API for Data and Services
Dynamics CRM exposes three types of API’s; however the Organizational web service is the one which will be used most often because this service exposes your CRM entities. The Deployment web service can be used in case of advanced deployment scenarios allowing the deployment of assets shared by multiple tenants. The Discovery web service can be seen as a service level metadata service.
– Discovery service
The Discovery Service is a global installation-level service that allows the caller to determine the correct organization and URL for their needs. Because Microsoft Dynamics CRM is a multi-tenant environment, a single Microsoft Dynamics CRM server can be hosting multiple business organizations. Because each Microsoft Dynamics CRM server may be handling a Web Service Method call for a different organization every time, the Web services must be notified of the target organization that a user is intending to reach.
– Organizational service
This is the primary web service that accesses data and metadata for your organization is IOrganizationService. This web service contains the methods that you use to write code that uses all the data and metadata in Microsoft Dynamics CRM.
– Deployment service
The deployment service allows you to create solutions to take advantage of support for multiple organizations—also called multi-tenant support. Microsoft Dynamics CRM enables you to host multiple customer organizations within a single deployment. This capability benefits hosted solutions or businesses that require a separation of data inside the organization. Because using the deployment service requires access to the CRM server, it can only be used for Microsoft Dynamics CRM on-premises deployments.
A web service proxy can be generated for each of all the web services mentioned above by using the WSDL or you could use the .NET helper classes provided within the CRM SDK.
I would highly recommend using the helper classes, which will simplify the construction of requests a lot. The API also supports batching of requests into a single web service method call.
4) CRM plugins
A plug-in is custom business logic (code) that you can integrate with Microsoft Dynamics CRM and Microsoft Dynamics CRM Online to modify or augment the standard behavior of the platform. Another way to think about plug-ins is that they are handlers for events fired by Microsoft Dynamics CRM. You can subscribe, or register, a plug-in to a known set of events to have your code run when the event occurs.
Before a plug-in can be used, it must be registered with the server. You can programmatically register plug-ins with Microsoft Dynamics CRM. Details can be found here:
- Server side code implement in .NET
- Using a command based pattern
- Able to obtain the execution context
- Able to reference the CRM services
5) Azure integration
You can connect Microsoft Dynamics CRM and Microsoft Dynamics CRM Online with the Microsoft Azure platform by coupling the CRM event execution pipeline to the Microsoft Azure Service Bus. This connection lets the data that’s been processed as part of the current CRM operation to be posted to the bus. Microsoft Azure Service Bus solutions that are “CRM-aware” can listen for and read the data that’s posted on the service bus by Microsoft Dynamics CRM.
More information can be found here: https://msdn.microsoft.com/en-us/library/gg334766.aspx
At this point I was running out of exploration time and therefore better to call this a pre-conclusion. Although I haven’t played with the Workflow and Server side extensions, I can conclude that the options to extend and interact with dynamics CRM are more interesting than initially expected. The abstraction layer does what it needs to do and limits the amount of required plumbing.
If you are into CRM processes or perhaps a SharePoint developer, interested in a different level of abstraction, Dynamics might be of your interest. Personally I would prefer building something in ASP.NET MVC over CRM forms and views. However working with the plugin model, web services and Azure Service bus integration can be quite compelling .