Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 5) - Generating a proxy service

Within a Windows command prompt, navigate to the bin directory beneath the CRM SDK download package.

Execute the CrmSvcUtil.exe utility which creates .NET classes for the entities within Dynamics CRM 2011. This utility has a series of command line parameters including:

Using these parameters, a sample query to generate the early-bound Dynamics CRM class looks like this:

CrmSvcUtil.exe /url:http://<server>/<orgName>/XRMServices/2011/Organization.svc /out:"C:\temp\CrmEntites.cs" /username:<username> /password:<password> /domain:<domain> /namespace:Chapter3.CrmProxyService


					  

The resulting C# class contains definitions for all of the standard and custom entities present in the target Dynamics CRM system. This class allows us to deal only with typed entities and avoid interacting with the raw Entity format.

In Visual Studio 2010, create a new Web Site project of type WCF Service and name it Chapter3-DynamicsCRM.SvcProxy.

Right-click the new project and choose to Add Existing Item. Locate the CrmEntities.cs class that was generated earlier and include it in this project. Add it to the App_Code folder of the project.

Once again, right-click the project and choose to Add New Item. Select the WCF Service type and name it CrmCustomerProxy.svc.

The contract for this service is displayed, which will contain the data type and operation that BizTalk will invoke. Note that the CrmEntities.cs class does not contain WCF serializable types. Therefore, we cannot simply return the Dynamics CRM "customer" type from our service. Define a new class in ICrmCustomerServiceProxy.cs that describes a customer. Be aware that we are using a single CRM entity, Customer, in this example. A similar exercise would have to be performed for each entity that we wish to expose to BizTalk.

[DataContract(Namespace="http://chapter3/data")]
public class Customer
{
[DataMember]
public string NamePrefix { get; set; }
[DataMember]
public string FirstName { get; set; }
[DataMember]
public string MiddleName { get; set; }
[DataMember]
public string LastName { get; set; }
[DataMember]
public string PrimaryAddressStreet { get; set; }
[DataMember]
public string PrimaryAddressCity { get; set; }
[DataMember]
public string PrimaryAddressState { get; set; }
[DataMember]
public string PrimaryAddressPostalCode { get; set; }
[DataMember]
public string PhoneNumber { get; set; }
[DataMember]
public string EmailAddress { get; set; } }


					  

Also in this ICrmCustomerProxy.cs file, add the service contract. This contract contains a single operation that takes in a customer object and returns a string containing the new record's unique identifier.

[ServiceContract(Namespace="http://chapter3/service")]
public interface ICrmCustomerProxy
{
[OperationContract]
string AddCustomer(Customer newCustomer);
}

Switch to the generated CrmCustomerProxy.cs file and add a placeholder for the required AddCustomer operation.

Before going further, add an assembly reference to this project. Point to the Microsoft.Xrm.Sdk.dll that is included in the bin folder of the Dynamics CRM SDK download.

At the top of the CrmCustomerProxy.cs code class, add three references:

using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Client;
using System.ServiceModel.Description; //for credentials
using Chapter3.CrmProxyService; //generated class

When calling the Dynamics CRM WCF SOAP service through code, we have the option of using a special service proxy class included in the SDK (OrganizationServiceProxy). By combining this proxy class with a Dynamics CRM WCF behavior (ProxyTypesBehavior), we can work solely with typed objects and let those objects get translated to, and from, Entities underneath the covers. At the beginning of the AddCustomer operation&;, add the following code, which creates a variable for the service proxy and defines the client credentials object:

OrganizationServiceProxy proxy;
ClientCredentials creds = new ClientCredentials();
creds.Windows.ClientCredential =
System.Net.CredentialCache.DefaultNetworkCredentials;

Define the two variables that will hold our Dynamics CRM contact object and the GUID value that is returned when a new contact is created.

Contact newContact;
Guid newContactId;

We are ready to instantiate the custom service proxy that we used to call the Dynamics CRM service. Notice that our credential object is passed into the constructor. After the proxy is instantiated, add the custom Dynamics CRM WCF behavior to the endpoint:

using (proxy = new OrganizationServiceProxy(new
Uri("http://<server>/<instance>/XRMServices/2011/Organization
.svc"),
null,
creds,
null))
{
proxy.ServiceConfiguration.CurrentServiceEndpoint.
Behaviors.Add(new ProxyTypesBehavior());
}

Create the mapping between the service's customer definition and the Dynamics CRM contact entity:

newContact = new Contact();
newContact.Salutation = newCustomer.NamePrefix;
newContact.FirstName = newCustomer.FirstName;
newContact.MiddleName = newCustomer.MiddleName;
newContact.LastName = newCustomer.LastName;
newContact.Address1_Line1 = newCustomer.PrimaryAddressStreet;
newContact.Address1_City = newCustomer.PrimaryAddressCity;
newContact.Address1_StateOrProvince =
newCustomer.PrimaryAddressState;
newContact.Address1_PostalCode =
newCustomer.PrimaryAddressPostalCode;
newContact.Telephone1 = newCustomer.PhoneNumber;
newContact.EMailAddress1 = newCustomer.EmailAddress;

Finally, invoke the service, pass in the Dynamics CRM entity, and get the GUID response. Return the string value of the GUID from the service operation:

newContactId = proxy.Create(newContact);

Build the service and deploy it to a local web server. Pull up the service in the browser to ensure that it is configured correctly:

If you choose, you may also try and call this service using the WCF Test Client. Make sure that the service sits within an Application Pool that runs with a domain account that has access to Dynamics CRM 2011.