CRM Integration considerations

Every CRM solution has to be integrated with in-house applications in addition to other systems like Microsoft Outlook, Microsoft GP etc in order to leverage most out of CRM. In this blog I will give a generic overview of how to go about the whole integration exercise. This blog covers integration with custom applications and the series would continue to cover integration with Microsoft GP and other products.

Microsoft Dynamics CRM 4.0 features a couple of web services, so that using these web services one can easily talk to CRM. Now that WCF and WWF is replacing integration products because of its reliability, scalability and robustness so I think that is the solution one should consider for CRM integration with other applications. CRM has following out of the box services.

1. CRM Service
   – This is used to interact with the entity instance data.
2. MetaData Service
   – This is used to interact with the entity model.

CRM Service is where all the action takes place, this is our (for the outside world) interface to CRM. It might feel tempting to just directly access the CRM database and do all the stuff but that’s neither supported nor a recommended approach. Whereas the MetaData Service is used to retrieve all metadata, add/update attributes in entities or add/remove an option from picklist etc.

Some common methods for CRM Service are as follows:

1. Create
   – Creates an instance of any entity that supports the Create message, including custom entities.
2. Retrieve
   – Retrieves an instance of an entity.
3. RetrieveMultiple
   – Uses a custom query (QueryExpression) to retrieve strongly typed results.
4. Update
   – Updates an existing entity instance.
5. Delete
   – Deletes an existing entity instance.
6. Fetch
   – Use a custom query (FetchXML) to retrieve results in XML format.

Another important method is the Execute Method which is message based and is used for specialized business logic.

Now that we have some basic knowledge of the services that will help us talk with CRM, let’s start talking about integration. Suppose we have an existing application that is used for operations that affect the way we manage our customers. It could be an application that is used for membership updates with each customer getting different level of customer support based on membership.  Ideally this system should be integration with CRM so that sales team is informed on membership/membership updates to perform operations that would guarantee greater level of customer satisfaction.  Similarly we would like the CRM solution to be integrated with other applications so that changes in one system are reflected in the other.  Another example is registration on site that might lead to creation of lead/account in CRM so that sales team could talk to customer/potential customer. Without going into the intricacies of your integration requirement it is evident that CRM needs to be integrated with other application and an architecture that offers de-coupled, SOA model of integration would suffice for most of integration requirements.

Normally the integration results in a two-way communication between CRM and other applications. Let’s take the example when a registration process should result in the creation of lead/account/contact or opportunity in CRM. In this case an action in custom application results in something happening in CRM. Same is to for many operations happening with CRM that should update the other systems.

Let’s identify the building blocks for our solution. For our existing system to talk with CRM we already have the CRM Service, but for CRM to talk to our existing system we’ll need to have a service as well. Let’s call it CRM Integration Service.

Considering that one would like to integrate the two systems using WCF it’s obvious that the existing application architecture needs to be extended to expose some of the operations through a WCF contract. We do it by adding an integration helper. This will be completely responsible for all the integration calls from our existing system to CRM. In case there is no requirement for the response from CRM for the operation resulting from custom application one would have one-way calls in our new CRM Integration Service and we’ll execute service calls on a separate thread from thread pool, so that our normal flow of application isn’t disturbed.Any exception will be handled in that separate thread from thread pool.

Our CRM integration service should meet following requirements.

1. It should have no impact on the existing application. This is important because in case one ends up changing the existing application you would have to go through the complete testing and deployment cycle.
2. The integration should be configuration driven so that the channel could be closed between custom application and CRM.
3. Error handling in the integration layer should not affect the application that is responsible for invoking the operation.
4. Integration layer should be robust which means in case of failure it should be able to restore and sync up the two systems.
5. Scalability can be a concern but it is driven mostly by the traffic and the direction of that traffic. I will not talk much about it in this series.
6. Unit work performed by integration layer should be small. This is very important and I will write more about this in my next blog.

These are some of the integration considerations for any sort of integration. Having worked in EAI and B2B integration projects, I know through my experience that these are absolutely critical requirements for the integration to work.  In the next post we will discuss how our integration solution would cover these requirements. I will also share some code and requirements/problems that we addressed as part of our implementation.