(For those of you not using Microsoft’s CRM software, you can find out all about it here.)

Our Process

At Knowledge Relay, we have been using Microsoft CRM for quite a while now (since its first release). Among other things, we use it to keep track of potential contacts (CRM Leads) that have registered with us on our Web site to download the software products we sell. Once we have a lead in the system, a salesperson can make the decision when to convert the lead into a CRM Contact or CRM Customer based on other criteria (such as the lead downloading or purchasing our software).

Despite achieving this customer-to-Web site tracking, we were not achieving the kind of efficiency and automation goals to make the product really simple and effective for our small sales staff to use. Sales persons were having to manually copy information out of e-mails generated by our Web site and paste that information into forms within the CRM system. Obviously, this is not a model of efficiency. So, we decided to look into the possibility of having our Web site automatically generate both leads and activities associated with those leads. Then, any sales person logging into CRM would see the items appear in their activity list.

Knowing that Microsoft CRM is an ASP.NET Web application powered by XML Web Services at the back-end, I had a hunch that either I’d need to call the appropriate Web Services from my code, or use the CRM API which, in turn, would call the appropriate Web Services. Because the latter is the approach I found used in the CRM SDK, I went with that. Now that I knew how to programmatically access the CRM, I set out to accomplish the following:

Developing the Solution

With my developer hat on, I went to the Class Library section of the CRM SDK Reference. The first page reads:

“This class library is a library of classes, interfaces, and enumerations that are included in the Microsoft CRM SDK. These are found in the Microsoft.Crm.Platform.Proxy.dll assembly. This library provides access to system functionality and is designed to be the foundation on which custom Microsoft CRM applications are built.

The Microsoft.Crm.Platform.Types.dll assembly contains the value types used to build XML strings for the APIs found in the proxy assembly.”

Eureka! Okay, so I found the names of the two assemblies I need to reference to have access to the CRM system functionality. Now, all I need to do is go find these two assemblies. My first thought was to go look in the bin directory beneath the root of the CRM virtual directory where the CRM was installed on our server. I found many assemblies there, but neither of the two I was looking for.

Strangely enough, it turns out that these two assemblies are not copied from the CRM disc as part of the installation process. To get them, you’ll have to locate the wwwrootbin directory on your installation CD. This wasn’t mentioned anywhere that I could find in the CRM SDK Documentation, but the Microsoft.public.crm.developer newsgroup produced the answer without much trouble. Now that I had these two assemblies, I created a new ASP.NET project in Visual Studio.NET 2003 and referenced them from the /bin subdirectory of my project virtual directory.

In the small corner of the CRM I worked in (Leads and Activities), creating CRM objects generally followed the same pattern:

1. Construct a string that points to the CRM platform server’s virtual directory. For example, http://myservername/mscrmservices/. This directory should contain the .srf files that will be referenced in the URL property of various CRM objects. You’ll see more about this in the code samples listed later.
   


2. Create a Microsoft.Crm.Platform.Proxy.BizUser object and assign it the necessary credentials using a System.Net.CredentialCache object. Add credentials using the URI of the .srf files that the CRM Objects need access to.
   


3. Use the BizUser.WhoAmI() method to return a Microsoft.Crm.Platform.Proxy.CUserAuth object that will contain the GUID representing the System User Id for the BizUser object. You’ll need this GUID value to inject into the <owner> node of the XML text you submit to the CRMLead.Create() method.
   


4. Construct an XML string that describes the CRM Object you want to create. The CRM SDK Documentation conveniently provides links to .xsd files that describe the XML schemas for the various CRM Objects.
   


5. Optionally, you can capture the GUID value for the created CRMLead or CRMActivity object returned by their respective Create() methods. You may or may not need to store this GUID somewhere for later use.

Page 2: The Code