(Article works with CRM Dynamics 3.0 and BizTalk Server 2004 onwards)
BizTalk CRM adapter can be used to send or push data to CRM system from any other application system. For example, account data can be pushed to CRM server from commerce server. But when it comes to receiving or pulling data out of CRM, Adapter is not the way because it comes with send adapter only. Well, one can design to run a scheduled orchestration which pools CRM server to fetch required data using SOAP adapter and CRM web service. But pooling is not a smart way. Ideally, any scalable design should pull incremental data when any data change happens. You can call this event (data change/addition) driven incremental data receive.
To design event driven incremental data receive, you have to use some of the in-house features of CRM. These features are – “Workflow” and “BizTalk Logic Extension” or “Callout”. Let’s talk little about these.
Microsoft CRM provides an event driven workflow framework on which developers can write custom logic. You can write a .net component and make it work under a workflow rule definition. Workflow rules can be bound to the following events that can be performed on an entity instance –
· Change Status
For example, if you create a workflow which has a rule which is bound to run on create event for “contact” entity instance, then whenever an instance of “contact” entity is created, it will trigger workflow rule and rule will in reverse call .net component. You can learn more about CRM workflow @ http://msdn2.microsoft.com/en-us/library/aa685987.aspx .
“Business Logic Extensions” or “Callout” is another event driven framework in CRM. Callouts can be configured to run (a .net component) upon occurrence of some event. Callouts support following event for CRM entities –
· Status Change
· Send Mail
Callouts can be two types of –
· Pre Callout – executes before occurrence of event
· Post Callout – executes after occurrence of event
For example, if you configure a post callout on create event of “contact” entity, then whenever an instance of “contact” entity is created, it will trigger configured post callout and callout will in reverse call .net component. You can learn more about CRM callout @ http://msdn2.microsoft.com/en-us/library/aa680495.aspx.
Both of these features are simple, configurable, require .net based coding and are very powerful. You are not required to be a CRM expert to use or implement them.
Designing Event Driven Incremental Data Import
There are few things which make “workflow” and “callout” a great instrument to design event based data pull –
· Both run when events like create, update, delete etc. occurs on CRM entities. Since these events occur when changes happen to entity instances; you can put logic in workflow or callout to read entity instance data just change and play with it. In other world, you can fetch incremental data change.
· Both are configurable
· As an event action, both can run .net components.
Let’s take a scenario and see how these things work together to give desired design.
Scenario: Contoso is an online retail company. It has an e-commerce site with commerce server at back end. And its customer care offices run CRM. Customers can call Contoso customer care center agents to update their profile, credit card and demographic information. Agents use CRM web client to perform job. Customers can also do the same job using self care portal which in reverse uses CRM web service to update information in CRM system. In both of these cases, customer contact information is updated in CRM system. Requirement is that “as soon as customer contact information is updated in CRM system; it should get synchronized to commerce server”.
In this overall requirement, underline statement requires customer contact data to be pulled from CRM system and get pushed into commerce system. You want to do incremental data update and want pull to happen only when any customer contact information is changed. Let’s see a simple possible solution for this -
Solution: here are step by step things I will like to do to implement this solution.
· I am assuming that customer accounts are implemented as “contact” entity in CRM system.
· First you create a BizTalk project. You add a schema having those fields or properties which we need to synchronize between CRM and Commerce.
· Then you add an orchestration. Orchestration will use a “Request-Response” port to read messages of schema type defined above. Once message is read, orchestration uses this message and commerce profile send adapter to send contact information into commerce system. Off course, there will some logic and data mapping between your schema and commerce profile schema. Well, I am sure smart implementation will have more decoupled and scalable orchestration design.
· When orchestration logic is complete, expose orchestration as web service and perform necessary port binding in BizTalk administrator.
· You are done with orchestration which can carry data between CRM and Commerce system. Now, we need to hook this orchestration with CRM in such a way that whenever contact entity instance is updated in CRM; it should trigger orchestration and pass required contact data from CRM to Commerce system.
· To perform required clip, create a workflow or post callout in CRM on “contact” entry and subscribe it to “update” event. As an action, workflow or callout will call a .net component and pass contact instance information to it.
· .Net component will call BizTalk web service exposed above and will use contact instance information to populate fields of schema in web service and finally call web service.
· And it works. Whenever, a contact entity instance is updated in CRM, configured workflow or callout will get triggered. Workflow or callout will fire .net component execution. Component will call web service passing contact instance information. Web service will pass data to orchestration and orchestration will push data into commerce system using adapters.
· That’s it. Solution triggers data synchronization only when any data change happens. Only incremental data is passed between systems.
· Well web service is one way. You can also used file, ftp or any other channel based integration.
Choosing between workflow and business logic extension (callout)
You saw that we can use both callout and workflow to implement pull solutions. Question is when to use workflow and when callout? You can use following guidelines –
· Callout supports more events than workflow.
· Workflows run asynchronous while callouts work synchronous.
· Callouts support all entities in CRM but workflow has reservations for few.
· Workflow can be run manually but callout cannot be.
· Callouts can be managed using automated deployment but workflow is not. One has to use workflow manager for workflow deployment.
Workflow and callout are two wonderful features in CRM which can be leveraged by BizTalk to write a smart pull operation. You just need to use their potential and fit in design. Hope you find this article useful.