A natural follow up to my BizTalk 2010: Calling Dynamics CRM 4.0 Web Services post is one that deals with the Exceptions, or Faults, that these Web Services may return. When using the CRM 4.0 Adapter, the adapter would take care of handling SOAP exceptions and bundling them up into a CRM Response message that had a Return Code and Error Nodes. Whether your operation was successful or not, you could always expect the same type of response message from CRM.
Now that we are not using this adapter anymore we need to be able to catch our own exceptions coming out of CRM. If we don’t perform these actions below(or similar actions) we can expect an error message like the following.
Inner exception: Received unexpected message type 'http://schemas.xmlsoap.org/soap/envelope/#Fault' does not match expected type 'http://schemas.microsoft.com/crm/2007/WebServices#CreateResponse'.
The issue is we have a Solicit Response Send Port in which we are sending a typed Request message into CRM and are expecting a typed Response message in return. When we encounter a SOAP Fault, a typed message is being returned, it just isn’t what we are expecting. In order to avoid these situations, we need to perform the following actions within our BizTalk solution.
Note: these actions are not specific to CRM, but may be used in other Web Service scenarios.
<ns0:CreateResponse xmlns:ns1="http://schemas.microsoft.com/crm/2007/CoreTypes" xmlns:ns2="http://microsoft.com/wsdl/types/" xmlns:ns3="http://schemas.microsoft.com/crm/2006/Query" xmlns:ns0="http://schemas.microsoft.com/crm/2007/WebServices" xmlns:ns4="http://schemas.microsoft.com/crm/2006/Scheduling" xmlns:ns5="http://schemas.microsoft.com/crm/2006/WebServices" xmlns:ns6="http://schemas.microsoft.com/crm/2006/CoreTypes">
<ns0:CreateResult>soap:Server - Server was unable to process request. -</ns0:CreateResult>
Note: some other blog posts mention using an XPATH statement, within our WCF Send Port, for both types of messages that we are expecting; typed CRM response and SOAP Fault. In my scenario, this step was not required since I am expecting a typed SOAP Fault exception object within my Scope – Exception handler.