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

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.

he first article in this series looked at the basics of using callouts, their integral components, and how to create a simple callout. The rest of this series discusses more advanced callout techniques of exception handling, debugging, logging, evaluating workflows, improving performance, and making callouts asynchronous.

Handling Callout Exceptions
You can define and manage how your code handles callout exceptions:
  • In the Callout.config.xml file
  • During pre-callout enumeration
  • In try/catch/finally blocks
Each item in the preceding list is discussed briefly in the following sections.

Handling Exceptions in Callout.config.xml
The code below shows a typical Callout.config.xml file:

   <callout.config version="1.0" 
      xmlns=" http://schemas.microsoft.com/crm/2006/callout/">
   <callout entity="lead" event="PostUpdate">
     <subscription assembly="LeadIntegrationCRMCallout.dll" 
       onerror="abort " >
The subscription element in the preceding configuration file contains an attribute called onerror, which by default is set to "abort," which causes CRM to abort the method if an unhandled exception occurs in the callout code. When that happens, CRM also displays a dialog box on the client side. Alternatively, you can set the value of onerror to "ignore," which causes CRM to ignore any unhandled exception and continue with the method.

Handling Exceptions during Pre-Callout Enumeration
The Microsoft.Crm.Platform.Callout.Base class contains an enumeration called PreCalloutReturnValue. This enumeration has three return values that can help in handling the exceptions:

  • Continue: This is the default return value. When CRM returns this value the pre-callout has completed successfully and CRM can continue executing any other callouts specified for the same entity.
  • Abort: If this value is returned, additional callouts are not processed. If you return abort, you should also specify an error message in the errorMessage parameter which should be displayed in the dialog box on the CRM user interface.
  • Stop: If this value is returned, it means that the callout has completed successfully but additional callouts will not be processed.
Handling Exceptions in try/catch/finally Blocks
Of course, you always have the option of using try/catch/finally to handle exceptions. It's good practice to log the messages in the catch block because that aids in debugging.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date