One can imagine many scenarios where
Dynamics CRM either publishes data to BizTalk Server or queries
BizTalk-exposed service endpoints. For instance, when a customer
requests a refund for a defective product, the call center agent may
record this request in Dynamics CRM. After the phone call is over,
Dynamics CRM should send a message to a returns processing system which
handles the crediting of a customer's account. In another scenario,
BizTalk Server may be the host of a data aggregation service which
queries three enterprise systems that store "customer" data and
aggregates the responses. Dynamics CRM may want to execute that service
when a call center agent views a customer record so that they get a
fuller picture of that customer's interactions with the company.
There are three viable places where Dynamics CRM can
communicate with BizTalk Server. First, a Dynamics CRM form is capable
of executing client-side JavaScript at various points in the form
lifecycle. One can definitely use JavaScript to invoke web services,
including web services exposed by BizTalk Server. However, note that
JavaScript invocation of web services is typically synchronous and could
have a negative impact on the user experience if a form must constantly
wait for responses from distributed services. Also, JavaScript that
runs within Dynamics CRM is client-side and tied directly to the page on
which it resides. If we programmatically interact with a Dynamics CRM
entity, then any code existing in client-side script will not get
invoked. For instance, if after an "account" record is created we send a
message, via JavaScript, to BizTalk, this logic would not fire if we
created an "account" record programmatically.
The second place where Dynamics CRM can communicate
with BizTalk Server is through workflows. A workflow in Dynamics CRM is
an automated process where a set of steps is executed according to rules
that we define. For example, when a sales opportunity is closed, we run
a workflow that adds a message to the customer record, notifies all
parties tied to the opportunity, and sends a polite email to the lost
prospect. Workflows are based on Windows Workflow 4.0 technology and can
be built either in the Dynamics CRM application itself or within Visual
Studio 2010. The Dynamics CRM web application allows us to piece
together workflows using previously registered workflow steps. If we
need new workflow steps or need to construct something complex, we can
jump into Visual Studio 2010 and define the workflow there. Why would we
choose to use a workflow to send a message to BizTalk Server? If you
have a long-running process that can either be scheduled or executed on
demand, and want the option for users to modify the process, then
workflow may be the right choice.
The final strategy for communicating between Dynamics
CRM and BizTalk Server is to use plugins. Plugins are server-based
application extensions that execute business logic and get tied directly
to an entity. This means that they are invoked whether we work in the
Dynamics CRM web interface or through the API. I can run a plugin both
synchronously and asynchronously, depending on the situation. For
instance, if we need to validate the data on a record prior to saving
it, we can set a plugin to run before the "save" operation is committed
and provide some user feedback on the invalid information. Or, we could
choose to asynchronously call a plugin after a record is saved and
transmit data to our service bus, BizTalk Server. In the following
exercise, we will leverage plugins to send data from Dynamics CRM to
BizTalk Server.
Integration to BizTalk Server
In this first walkthrough, we will build a plugin
that communicates from Dynamics CRM to a BizTalk Server located. An
event message will be sent to BizTalk whenever a change occurs on an
Account record in Dynamics CRM.
Setup
This exercise leverages a BizTalk Server project
already present in your Visual Studio 2010 solution. We are going to
publish a web service from BizTalk Server that takes in a message and
routes it to a BizTalk send port that writes the message to the file
system.
If you have not already done so, go to the code package for this book and navigate to C:\LOBIntegration\Chapter03\Chapter3-DynamicsCRM and open the Visual Studio 2010 solution file named Chapter3-DynamicsCRM.sln.
Find the BizTalk Server project named Chapter3-DynamicsCRM.AcctRouting and open it.
The book's code package includes a custom schema named AccountEventChange_XML.xsd and notice which elements we want from Dynamics CRM 2011 when an account changes. The first element, EventSource,
is used to designate the source of the change event, as there may be
multiple systems that share changes in an organization's accounts.
This
BizTalk project should be set to deploy to a BizTalk application named
Chapter3. Build and deploy the project to the designated BizTalk Server.
After
confirming a successful deployment, launch the BizTalk WCF Service
Publishing Wizard. We are going to use this schema to expose a web
service entry point into BizTalk Server that Dynamics CRM 2011 can
invoke.
On the WCF Service Type wizard page, select a WCF-BasicHttp adapter and set the service to expose metadata and have the wizard generate a receive location for us in the Chapter3 application:
On the Create WCF Service wizard page, choose to Publish schemas as WCF service. This option gives us fine-grained control over the naming associated with our service.
On
the next page, delete the two-way operation already present in the
service definition. Rename the topmost service definition to AccountChangeService and assign the service the same name. Right-click the service and create a new one-way operation named PublishAccountChange. Right click the Request message of the operation and choose the AccountChangeEvent message&; from our BizTalk Project's DLL:
On the following wizard page, set the namespace of the service to http://Chapter3/AccountServices.
Next, set the location of our service to http://localhost/AccountChangeService and select the option to allow anonymous access to the generated service. Finally, complete the wizard by clicking the Create button on the final wizard page.
Confirm
that the wizard successfully created both an IIS-hosted web service,
and a BizTalk receive port/location. Ensure that the IIS web service is
running under an Application Pool that has permission to access the
BizTalk databases.
In order to test this service, first go to the BizTalk Server Administration Console and locate the Chapter3 application.
Right click the Send Ports folder and create a new, static one-way send port named Chapter3.SendAccountChange.FILE. Set the send port to use the FILE adapter and select the FileDrop\DropCustomerChangeEvent folder that is present in the chapter's code package:
This
send port should listen for all account change event messages,
regardless of which receive location (and system) that they came from.
Go to the Filters tab of this send port. Set the filter Property to BTS.MessageType and filter Value to http://Chapter3-DynamicsCRM.AcctRouting.AccountChangeEvent_XML#AccountChangeEvent.
All that remains is to test our service. Open the WCF Test Client application and add a new service reference to http://localhost/AccountChangeService/AccountChangeService.svc.
Invoke the PublishAccountChange
method&; and, if everything is configured correctly, we will see a
message emitted by BizTalk Server that matches our service input
parameters:
We now are sufficiently ready to author the Dynamics CRM plugin, which calls this BizTalk service.
