Search code examples
wcfesbsonic

Error 404 calling WCF Service from Sonic ESB

We have a WCF Service that is working fine, there are 4 customers using this service without problems, but I have this one customer who is complaining that he can't call the webservice anymore for the last few days.

We did not change anything since October and he also claims he did not change anything.

As I said, I have other customers using this service just fine and we also can call the service from SOAP UI. We even tried to create a new isolated machine in AWS and call the service in order to make sure it is not something like a firewall issue blocking the communication from outside our network.

For what I can see from the stack trace he sent me, this customer uses Sonic ESB to call our service. I really don't understand how Sonic ESB works but my guess is that the error is caused by Sonic ESB, not my service. It is like it creates an "adapter" in between his application and my service.

Which led me this following conclusion:

1) Looking at his request XML (he sent me) I can see that it does not match the WSDL I have provided, for instance:

(I have changed few names and values for obvious reasons)

<CreateOrderGatewayCompanyName> --> This would be just CreateOrderGateway
  <header>  --> this header seems specific to Sonic ESB, nothing to do with us
     <user>123414714</user>
     <idProcess>5411251</idProcess>
     <channel>EB</channel>
     <ip>[ip number here]</ip>
     <sessionId>1fd5a3f4d8f4dsa5f4dsaf4dsf1da5.xyz</sessionId>
  </header>
  <body>
    <idCampania>xyz</idCampania> --> This would be "CampaignId"
    ...
    <order>
       ...
       <fecha>2016-12-21</fecha> --> This would be "Date"
       ...
    </order>
  </body>
</CreateOrderGatewayCompanyName>

So I can only conclude that somewhere in the process, the ESB will convert this weird XML in the proper SOAP request format my service is expecting.

2) Looking at the exception stack trace he sent me, I can see this 404 error:

<?xml version="1.0" encoding="UTF-8"?>
<exception xmlns="http://www.sonicsw.com/sonicesb/exception">
 <message>Exception while retrieving soap envelope from response: 
&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"&gt;
&lt;HTML&gt;&lt;HEAD&gt;&lt;TITLE&gt;Not Found&lt;/TITLE&gt;
&lt;META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"&gt;&lt;/HEAD&gt;
&lt;BODY&gt;&lt;h2&gt;Not Found&lt;/h2&gt;
&lt;hr&gt;&lt;p&gt;HTTP Error 404. The requested resource is not found.&lt;/p&gt;
&lt;/BODY&gt;&lt;/HTML&gt;
</message>
 <class>com.sonicsw.xqimpl.invkimpl.wsif.providers.axissoap.SoapProviderInvocationException</class>
 <detail/>
 <stackTrace><![CDATA[org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
...

And here is the thing, this 404 HTML code that he is getting as a response DOES NOT come from my server because we use IIS 8.5 and the 404 error page of IIS does not look like this one, the HTML is different and the message is different as well. It would be something like:

“404 - File or directory not found. The resource you are looking for might have been removed, had its name changed,..”

So does anyone know if this Sonic ESB actually creates an adapter or proxy in the middle of the applications? And if someone already have experienced an error like this what would be the cause? I'm 100% positive my service is working fine.

Solution

  • It turns out that a network trace (wireshark) on my server revealed that my customer's proxy was modifying the "Host" of the request, for instance, instead of

    Host: ourdomain.com

    It was modified like

    Host: proxy.customer.com:8080

    So when this request arrived at the IIS server, the binding was configured to "ourdomain.com" and then it dropped the request. For some weird reason, a guy named "Microsoft HTTPAPI" returned the reply with that 404 error page my customer was getting on their application.

    So we have fixed the problem changing our IIS bindings because I don't want to wait my customer to investigate what the hell is his proxy doing with the host name.