Unable to Get SoapException Detail in Client

Question

Our company works with healthcare and banking using external vendors who provide web services.  They have provided WSDL and API documentation.  Their services are based on .ASMX services and use standard SoapException handling.  We have no control over the web services and the actual soap exceptions.  Since these are NOT WCF services we don't have classes for exceptions returned, these instead are covered in the API documents and must be hand coded.

Our problem has been that the vendors provide detail information in the standard soap "detail" section of the SoapException and while we have the API specification for what should be there we could not access that information.  Microsoft has decided not to include direct access to the SoapException through the WCF FaultException class for what ever reason.  This makes the task of getting the Soap Fault detail near impossible it would seem.

In another thread on this forum "Problem Catching SoapExceptions" the topic has been explored.  The thread morphed to not one of "catching" the exception to one of getting the information contained in the fault.

So if you are getting SoapExceptions converted by WCF clients to FaultException and you want to get at the actual fault detail then this is the place.

Thanks to John Saunders for help.

Here is an example of what we are trying to accomplish.  The web service is pushing back a SoapException fault and WCF converts it to a FaultException.  The "detail" section of the XML is not available to a FaultException. So how do we get the detail. Below is a sample of an exception intercepted by fiddler2.
From fiddler this is what we get... sanitized

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
 <soap:Fault>
  <faultcode>soap:Client</faultcode>
  <faultstring>System.Web.Services.Protocols.SoapException: Provisioning violation: unknown IP address. IP address [xxxxxxx]  is not recognized or client application is not a licensed subscriber to RTMS</faultstring>
  <faultactor>GetPurseInfo</faultactor>
  <detail>
    <faulttype>Data</faulttype>
    <errorlist>
      <field errorcode="Client" errortype="Provision">[127.0.0.1]</field>
    </errorlist>
  </detail>
 </soap:Fault>
</soap:Body>
</soap:Envelope>

As you can see there is valuable information buried in the detail section. In WCF a custom fault would make this child's play.

Not to keep you in suspense any longer here is the solution again courtesy of John Saunders.

private void ComplexSoapExceptionHandler(Exception exception)
{
    try
    {
        throw exception;
    }
    catch (FaultException faultException) //Catches the SOAP exceptions thrown by web services
    {
        var fault = faultException.CreateMessageFault();
        var doc = new XmlDocument();
        var nav = doc.CreateNavigator();
        if (nav != null)
        {
            using (var writer = nav.AppendChild())
            {
                fault.WriteTo(writer, EnvelopeVersion.Soap11);
            }
            string s = doc.InnerXml; //do something with it
        }
    }
}

There are other ways to do this but this is compact and complete.  All you have to do is parse the InnerXml into something that makes sense for your application.

Answer 1

Hi ,

Please let us know whether you have resolved this question via John Saunders's advice. Or you can have a look at the message inspector in client to check the message to implement your requirement. Please have a look at this class for defining a message inspector object that can be added to the MessageInspectors collection to view or modify messages.
http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.iclientmessageinspector.aspx

---

Best regards,
Riquel
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

Yes, I was able to retrieve the information from the detail that I required using the method described.  However I am looking into the recomendation you suggested for future use.

I think that this subject is poorly documented as I know that I spent at least two days at work searching for a solution BEFORE resorting to hitting the forums.  Even that took two more days to come up with this solution.

I have been in this business for nearly 30 years so I do understand the problems with documentation and how to make it.

I write this in hopes that it finds it way back to documentors.  In a project, typically when we finally get to the coding stage we will have a team of people coding a project.  They are not necessarily well versed in the entire .NET stack thus rely on search engines to find detail on implementation.  That means that documentation that either has no remarks/samples or simply refers to so other "global" area in MSDN is useless.  That means that important documentation is overlooked.  The Overview sections is where I go first.  I want/expect that the overview will at least tell me what types of problems this area of the .NET framework is trying to address.  The "Related Topics" section is critical in searching the documentation.

Case in point - your suggestion of the IClientMessageInspector.  The documentation is so spares that it is practically useless.  Exception handling is critical yet this is treated like it just something that you tack on if you can't do it anyother way.

In this case I chased dozens of promising leads up and down the documentation.  I NEVER even got a clue that this existed.  A quick scan of the documentation still hasn't told me what it is really "supposed" to do nor is there any real example other than the class definitions - which at I get from ReSharper when I roll over it.

BOTTOM LINE:
If it is worth inclusion in the framework then it should be documented.  If it is not documented then it has no value.


Many of us who have written against Microsoft frameworks don't use any undocumented features because they have a way of coming around and biting us later (usually a couple years later when everybody who worked on the project is gone.)

This in not a rant, I always push for more documentation.  I push my teams and myself personally to FULLY document all code.  To the point of even sometimes putting in personal comments.

Larry

Answer 3

After about three hours of reading the "non-existant" documentation for the IClientMessageInspector and searching MSDN, Bing, and Google, I can say that no one in his right mind would should attempt to use this as a solution.

Larry

Answer 4

Hi Larry,

Please have a look at Extending Clients for more information how to use IClientMessageInspector interface.
http://msdn.microsoft.com/en-us/library/ms730107.aspx
This topic describes how to use the ClientRuntime and ClientOperation classes in a Windows Communication Foundation (WCF) client application to modify the default execution behavior of a WCF client or to intercept or modify messages, parameters, or return values prior to or subsequent to sending or retrieving them from the channel layer.

---

Best regards,
Riquel
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.