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
<callout entity="lead" event="PostUpdate">
onerror="abort " >
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:
Handling Exceptions in try/catch/finally Blocks
- 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.
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.