Today I was training customers in extending CRM on CRM 2015 update 1. Using the brand new training materials from course 80547AE – Extending Dynamics CRM 2015. One of the topics I discussed in the introduction was integrating Dynamics CRM with the Azure Service Bus.
The official training slide showed the following image.
This image and some background information one of the customers gave me triggered me. The customer described the application landscape being used in his company.
An application landscape consisting of a number of legacy systems, Tibco middleware, custom applications and somewhere in the middle was floating Dynamics CRM. An older version of Dynamics CRM, soon to be replaced by a brand new shiny 2015 edition. All systems running on premise.
In the picture above, an user action triggers a plugin. The plugin runs some custom code that triggers the remote service bus. From there on, some black magic happens and something is going to be processed.
My gripe with this sketch is that setting up remote connections can be time consuming which can influence the user experience in a negative manner. Furthermore I miss a feedback from the service bus telling e.g. the action is done.
If I had to draw the image above, I would make a number of changes which would result in a much better user experience and much more unified manner to integrate the CRM environment in an application landscape.
In this article I’ll describe my vision.
A user triggers a plugin (e.g. by doing an update). The plugin forces an asynchronous plugin to fire. The async plugin fires a custom action. The custom action runs synchronous and its task is to send a message to the service bus (online / on-premise).
From there on the third party system can do whatever it wants with the message. Once done, the third party server places a message on the service bus indicating the whatever action is done (either by giving a status or a result).
A process on the service bus, picks up the message and invokes a custom action on CRM (Custom receive action). The receive action updates an entity on CRM. The reason I choose to implement a send action and a receive action is to provide a generic mechanism for sending and receiving messages to and from the service bus.
Based on the message the action decides what to do with the outgoing or incoming message. By following this implementation pattern, the communication logic is centralized around two actions, resulting in an easier to maintain solution on CRM.
As you can see, this scenario is more complex than the example provided by Microsoft. The advantages of my scenario are:
- better user experience
The user does not have to wait for the action to connect to the serice bus. - Unified handling of sending and retrieving messages to and from the service bus
By introducing two custom actions, we have streamlined and abstracted the communication to the service bus. By using generic actions we can use parameters to put messages on a specific queue.
In case the service bus changes we only have to change a single implementation for sending messages. Furthermore we have implemented a feedback mechanism, to retrieve messages in CRM. - Reusability of functionality
Write once…run everywherereuse multiple times. - Lower maintenance costs
as functionality is centralized, maintenance costs are lower.
The disadvantages are:
- Initialilly much more complex
The initial setup is more complex, this might result in higher initial costs. - high level of abstraction
To master the level of abstraction, documentation / education is key.
Regardless whether your service bus is hosted on Azure or not, the high level design remains the same.