RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Capitalizing on Microsoft Dynamics CRM 3.0 Callouts: Advanced Features : Page 3

Callouts can add business value, but just as with any other code, you need to be able to handle exceptions and debug the callout code.

Example MSMQ/Windows Service Callout
Here's a callout example that uses the design techniques discussed in the preceding section. This example uses MSMQ for the message store. The example is a post callout that fires after a sales lead gets updated in MSCRM.

Here's the callout constructor:

   public LeadCallout()
         eventLog = new EventLog();
         eventLog.Log = "Application";
         eventLog.Source = "LeadIntegrationCallout";
         XmlDocument doc = new XmlDocument();
         string assemblyName = System.Reflection.Assembly.
         string assemblyFolder = assemblyName.Substring(0, 
         string configFilePath = assemblyFolder + @"\" + 
            "Lead Callout.config";
         XmlNode node = doc.SelectSingleNode("//appSettings");
         if (node == null)
            throw new InvalidOperationException(
               "appSettings section not found in config file.");
         queuePath = ((XmlElement)node.SelectSingleNode(
         debug = ((XmlElement)node.SelectSingleNode(
         useBinaryFormat = ((XmlElement)node.SelectSingleNode(
         WriteToLog("Constructor Called", 
         WriteToLog("Config File Path: " + configFilePath, 
         WriteToLog("Assembly Folder: -----> " + 
            assemblyFolder, EventLogEntryType.Information);
      catch (Exception ex)
         WriteToLog(ex.ToString(), EventLogEntryType.Error);
The constructor code reads the following values from the configuration file of the callout DLL (the Lead callout.config):

  • QueuePath: Specifies the path of the MSMQ queue to use for storing messages.
  • UseBinaryFormatter: Determines whether to store messages in binary format in the MSMQ
  • CreateQueue: Indicates whether the queue exists or whether to create the queue via code.
  • Debug: Controls whether to log the messages in the Event log.
  • LogFilePath: Specifies the path of the log file.
Please note that the Lead callout.config is different from the callout configuration file; when you create a callout, a callout configuration file gets added as part of the solution, named callout.config.xml.

A Post-Callout Example
Listing 2 shows an example that illustrates how to design and implement post callouts.

As Listing 2 shows, the post callout logs some messages, checks the lead status, and when it's and MSCRMLEAD, calls the ProcessLeads() method to insert the record in the queue. To keeping this article focused on the callout itself, we won't discuss the implementation methods here, but you can download the code for all the methods (MSMQ handling, obtaining the status code, logging, etc.).

Deploying the Callout
To deploy the sample callout, you can place the LeadIntegrationCRMCallout.dll, the Lead callout.config, and the callout.config.xml files in the same location: C:\Program Files\Microsoft CRM\server\bin\assembly, (assuming you installed MSCRM on the C:\ drive).

With a callout that writes incoming messages to the MSMQ queue complete, you now need to create the Windows service that reads the queue and processes the messages. Just like the callout, the Windows service has a config file that will look much like this one:

   <?xml version="1.0" encoding="utf-8" ?>
         <add key="QueuePath" value=".\private$\leadrecord" />
         <add key="PollingInterval" value="5000" />
         <add key="ReceiveTimeout" value="3000" />
         <add key="DeleteMessageOnRecieve" value="True" />
         <add key="Debug" value="True" />      
In that configuration file, the attributes used are:

  • QueuePath: Specifies the path of the MSMQ queue.
  • Polling Interval: Controls the number of seconds to wait between checking the queue for new messages.
  • ReceiveTimeout: Controls the number of seconds to wait before stopping the receive operation from MSMQ.
  • DeleteMessageOnRecieve: If this value is false, the service will leave all messages stored in the queue for later reference; otherwise, it deletes them from the queue after processing.
  • Debug: If true, logs the messages to the Event log.
You can find the code for the Windows service used here in the downloadable code for this article, but briefly, the service uses a timer ticked every N seconds where N is the PollingInterval value specified in the configuration. The service reads messages from the Queue and does some custom processing. If the processing was successful, it deletes the record from the queue (if the DeleteMessageOnRecieve attribute value in the configuration file is true).

MSCRM 3.0 callouts are a powerful feature. When used with proper design techniques, callouts make the CRM engine far more extensible, and can provide seamless integration with other systems.

Joydip Kanjilal has over 10 years of industry experience with C, C++, Java, C#, VB, VC++, ASP.Net, XML, Design Patterns, UML, etc. He currently works as a senior project leader in a reputable multinational company in Hyderabad, India, and has contributed articles on .NET and related technologies to www.aspalliance.com.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date