Ошибка 404 при вызове службы WCF из Sonic ESB

У нас есть служба WCF, которая работает нормально, есть 4 клиента, без проблем использующих эту услугу, но у меня есть один клиент, который жалуется, что он не может больше звонить в веб-службу в течение последних нескольких дней.

Мы ничего не изменили с октября, и он также утверждает, что ничего не изменил.

Как я уже сказал, у меня есть другие клиенты, использующие этот сервис, и мы также можем вызвать сервис из 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 преобразует этот странный XML в правильный формат запроса SOAP, который ожидает мой сервис.

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: 
&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)
...

И вот в чем дело: этот HTML-код 404, который он получает в ответ, НЕ приходит с моего сервера, потому что мы используем IIS 8.5, а страница с ошибкой 404 IIS не похожа на эту, HTML-код отличается, и сообщение также отличается. Это было бы что-то вроде:

"404 - файл или каталог не найден. Ресурс, который вы ищете, мог быть удален, если его имя было изменено,..”

Так кто-нибудь знает, действительно ли этот Sonic ESB создает адаптер или прокси посреди приложений? И если кто-то уже сталкивался с такой ошибкой, что было бы причиной? Я на 100% уверен, что мой сервис работает нормально.

Источник

2 ответа

Решение

Оказывается, что трассировка сети (wireshark) на моем сервере показала, что прокси-сервер моего клиента, например, изменял "Хост" запроса вместо

Хост: ourdomain.com

Было изменено как

Хост: proxy.customer.com:8080

Поэтому, когда этот запрос поступил на сервер IIS, привязка была настроена на "ourdomain.com", а затем он отбросил запрос. По какой-то странной причине парень по имени "Microsoft HTTPAPI" возвратил ответ с той страницей с ошибкой 404, которую мой клиент получал в своем приложении.

Таким образом, мы исправили проблему, изменяя наши привязки IIS, потому что я не хочу ждать, пока мой клиент выяснит, что, черт возьми, его прокси-сервер делает с именем хоста.

Источник

Ваш клиент отправил фактический запрос мыла, который отправляется? Он может включить фактический вызов веб-службы (самый простой способ - это сделать из консоли администратора).

http://knowledgebase.progress.com/articles/Article/S6498

Зная точный запрос мыла о том, что он отправляется, его будет легче отлаживать.

Также я рекомендую вам включить на несколько минут отслеживание запросов на вашем сервере, когда он проверяет, чтобы отменить, что любые другие модификации выполняются посередине.

Источник
Другие вопросы по тегам