我们有一个运行良好的WCF服务,有4个客户使用这项服务没有问题,但我有一个客户抱怨他在过去几天不能再打电话给网络服务了。
自10月以来,我们没有改变任何事情,他也声称他没有改变任何事情。
正如我所说,我有其他客户使用此服务,我们也可以从SOAP UI调用该服务。我们甚至尝试在AWS中创建一个新的隔离计算机并调用该服务,以确保它不会阻止来自我们网络外部的通信的防火墙问题。
我从他发给我的堆栈跟踪中可以看到,该客户使用Sonic ESB来拨打我们的服务。我真的不明白Sonic ESB是如何工作的,但我的猜测是错误是由Sonic ESB引起的,而不是我的服务。就好像它在他的应用程序和我的服务之间创建了一个“适配器”。
这导致我得出以下结论:
1)查看他的请求XML(他发给我)我可以看到它与我提供的WSDL不匹配,例如:
(由于显而易见的原因,我更改了一些名称和值)
<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>
所以我只能得出结论,在这个过程的某个地方,ESB会以我服务期望的正确SOAP请求格式转换这个奇怪的XML。
2)看着他发给我的异常堆栈跟踪,我可以看到这个404错误:
<?xml version="1.0" encoding="UTF-8"?>
<exception xmlns="http://www.sonicsw.com/sonicesb/exception">
<message>Exception while retrieving soap envelope from response:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Not Found</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Not Found</h2>
<hr><p>HTTP Error 404. The requested resource is not found.</p>
</BODY></HTML>
</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)
...
这就是问题,这个404 HTML代码作为回应而不是来自我的服务器因为我们使用IIS 8.5而且IIS的404错误页面看起来不像这个,HTML不同而且消息也是不同的。它会是这样的:
“404 - 找不到文件或目录。 您正在寻找的资源可能已被删除,其名称已更改,..“
那么有人知道这个Sonic ESB是否真的在应用程序中间创建了一个适配器或代理?如果某人已经遇到过这样的错误,那会是什么原因?我100%肯定我的服务工作正常。
答案 0 :(得分:0)
您的客户是否发送了正在发送的实际肥皂请求? 他可以启用实际的Web服务调用(最简单的方法是从管理控制台执行此操作)。
http://knowledgebase.progress.com/articles/Article/S6498
在知道发送它的确切soap请求之后,它将更容易调试。
另外,我建议您在测试时将服务器中的请求跟踪启用几分钟,以便丢弃在中间进行的任何其他修改。
答案 1 :(得分:0)
事实证明,我服务器上的网络跟踪(wireshark)显示我的客户的代理正在修改&#34; Host&#34;例如,请求而不是
主持人:ourdomain.com
它被修改为
主持人:proxy.customer.com:8080
因此,当此请求到达IIS服务器时,绑定被配置为&#34; ourdomain.com&#34;然后它放弃了请求。出于一些奇怪的原因,一个名为&#34; Microsoft HTTPAPI&#34;用我的客户在申请时获得的404错误页面返回了回复。
所以我们已经修复了改变我们的IIS绑定的问题,因为我不想等待我的客户调查他的代理人使用主机名做什么。