Capture Sonic Connect SOAP Faults (8.0.1)

I have been trying to approach the problem by adding the Fault definition to the WSDL. This leaves me with two problems:

1) No namespace on the Fault

One trading partner is sending back a SOAP Fault like this:

        soapenv:Server.Processing

       [Authorization Failure] Server rejected request

       TheTradingPartner

            com.them.invoker.common.FirewallException: IP Address x.x.x.x not permitted to access any Web Services for message null:null

Note the xmlns=""

How do I define that in the WSDL?

2) Other Faults

This is just one trading partner. We have some cases where we exchange the same messages with multiple trading partners, using different ESB products.

How can I make the Fault capture more generic?

Thanks

Steve

I believe you must define a valid fault defintion in your WSDL, even though you are going to receive faults that don't match the definition.   Take a look at the the following example taken from CXF's wsdl_first sample.

{code}

{code}

I create a SC Web Service Client from the above WSDL.

When SC receives a SOAP fault that matching the definition of "NoSuchCustomerException" Fault, SC converts it to the following ESB Fault message.

Notice the fault name, fault code, fault string are put in the ESB headers.   The fault detail is put in the ESB mesage body with content-id "NoSuchCustomerException" which is the fault name as in the WSDL.

{code}

   
   
   
   
   
   
    <?xml version="1.0" encoding="UTF-8"?>
<example:getCustomersByName
        xmlns:example="http://customerservice.example.com/">
    <name>None</name>
</example:getCustomersByName>
    <?xml version="1.0" encoding="utf-8"?><ns2:NoSuchCustomer xmlns:ns2="http://customerservice.example.com/">
        <customerName>None</customerName></ns2:NoSuchCustomer>

{code}

If SC receives a SOAP fault that does not match the definition in the WSDL, for example ...

{code}

  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/1999/XMLSchema">
  
    
     soapenv:Server.Processing
     [Authorization Failure] Server rejected request
       TheTradingPartner
      
            com.them.invoker.common.FirewallException: IP Address x.x.x.x not permitted to access any Web Services for message null:null
      
     
 

{code}

(BTW, your fault detail has a problem.  The "Error" element is not closed by a .  That can cause problem parsing the SOAP message.)

A ESB Fault message is still produced by SC.  The fault string, fault actor, and fault code are put in the ESB headers as before.  However, the fault detail is not put in the body.  This is an expected behavior.

{code}

   
   
   
   
   
   
   
    <?xml version="1.0" encoding="UTF-8"?>
<example:getCustomersByName
        xmlns:example="http://customerservice.example.com/">
    <name>None</name>
</example:getCustomersByName>

{code}

The empty string namespace (xmlns="") in your example does not seem to have any effect.  The same ESB Fault message is resulted with or without the empty string namespace.

HTH

Hi William

Thanks for the effort you put in on this. If I interpret your response correctly:

- If the WSDL explicitly defines SOAP Faults and one of them is returned then an ESB Fauilt occurs and the detail is available in the ESB Message.

- If any other SOAP Fault is returned then then an ESB Fault occurs but the SOAP Fault detail is not available in the ESB Message

- and that's the way Sonic works.

So, when something unexpected is returned from the trading partner, information is lost and the problem diagnosis process is hindered. This is why, in another post, I have requested being able to capture the SOAP Envelopes in the ESB Message.

Another related problem is that we exchange the same messages with multiple trading partners with a variety of ESB implementations. Predicting all the SOAP Faults they may generate in advance is pretty difficult (an understatement).

My previous experience has been to be able to generically capture SOAP Faults and record the content. None of the WSDLs we have define Faults defined and our existing ESB deals with SOAP Faults quite well.

(The missing tag in what I posted reflects my clumsy fingers, rather than poorly formed XML)

Regards

Steve

Your interpretion of my response is correct.  Regarding predictiing fault thrown from trading partners, I thought WSDL contract was a way to solve this kind of issues.  A fault in the contract can be generic (the detaiil can be any type) but it is important that the service knows what application level faults may get.  Maybe it is just naiveness on my part.   You have a point about losing fault detail to make troubleshooting more difficult.  I'll log a defect targetting for 8.1.  Thanks for bringing it up.

Regards.

Hi William

I have neve seen SOAP Faults used for application level errors. Such errors are usually architected into the messages level exchange. SOAP Faults are generally reserved for infrastructure, security and uncatered for events (like exceptions thrown). Even looking at a Web Service ESB Process; If I do some bad programming and the process breaks, Sonic will return an unexpected and undocumented SOAP Fault. If I arbitrarily throw a Fault, Sonic will return an undocumented SOAP Fault.

Thanks for following up with a defect.

Regards

Steve

This issue is fixed in 8.1