Command Pattern
One of the most common IT projects that business application developers do is integration between multiple systems. In the CRM world it is not uncommon to see integrations to/from various application and services such as ERP systems, social networks, application providers (e.g. campaign marketing), etc.
While there are heavy duty tools for different scenarios (E.g. CRM-GP connector) as well as whole frameworks for orchestration (e.g. BizTalk) the pattern that I describe here will allow you to achieve simple integration scenarios between Dynamics CRM and any other system; it is also helpful as a building block when developing more complex integration schemes.
Getting information in or out of Dynamics CRM is usually not a problem; we have a rich set of APIs (web services) that allow you to do CRUD operations pretty easily. The problem is usually how to “push” information out of the system automatically.
In an On-Premise installation of Dynamics CRM doing push operations is pretty easy as you can leverage workflow custom activities or plug-ins to notify external systems that an event happened, in fact this is how many CRM-SystemX connectors work. In CRM Online (v4) since plug-ins and custom workflow activities are not supported* pushing information out is a bit more challenging and even if those items were supported chances are that network connectivity issues could get in your way (e.g. firewalls may prevent you from reaching the external application).
Enter the “Command” pattern. This is not by any stretch a new concept and plenty of partners have already implemented integrations with CRM that use the approach I describe here. Still, some of you may find this useful.
The approach is very straight forward; you have 2 components (besides all other components in your existing systems): the “Command” and the “Connector” that processes command instances.
Command
To represent a command you create a custom entity that will serve as the “Command” that you are issuing to an external system. You can have one attribute per parameter that you command needs or it can be as simple as having one attribute (e.g. commandBody) holding a set of XML instructions. If you want it to be more users friendly I recommend having one attribute per parameter. You will also need attributes to hold the status of the command (e.g. pending, processed, delayed…).
Connector
This is the piece that will be processing Commands. A connector can be all sorts of applications but they usually manifest in the form of Windows Services, Scheduled Jobs, etc. The job of the connector is to read the command and do whatever it needs to do in the external system, usually contacting a web service and perform synch operations. The connector can contact back CRM (via web services) to update the status of the command as well as to update/synch any related data.
One of the nice things about this pattern is that you separate the connector from the command. This gives you the flexibility to implement a “push” connector (e.g. a plug-in that gets fired upon a command instance creation) that works in CRM On-premises or a “pull” connector (e.g. a windows service that periodically queries CRM for new commands to be executed) that would work in either CRM on-premises or online.
Hooking up workflow
With the introduction of the web workflow designer in CRM V4 more and more customizers, power users and even some business users create, configure and monitor workflows on a regular basis. What if one of the steps in the workflow process requires send/synch information between multiple systems? Well, the pattern described above works perfectly with workflow and you don’t even need to create a custom activity. All users have to do is a “create” step for the command entity and specify the parameters they need using the workflow designer.
Of course anybody that has spent time doing integrations among systems knows that the devil is in the details (e.g. retries, cycles, timeouts, synch logic) but at least the pattern described here should help you get to a good start.
As a teaser, this pattern will also work with CRM5 even though you will have additional tools and services to achieve integration scenarios.
Cheers