Захват данных из веб-службы .Net с ошибкой с кодом ошибки HTTP 500 - PullRequest
Новая
       40

Захват данных из веб-службы .Net с ошибкой с кодом ошибки HTTP 500

4 голосов
/ 17 октября 2008

У меня есть веб-служба .net, размещенная в IIS 6.0, которая периодически выходит из строя с http 500, потому что клиент подключается к нему с данными, которые не соответствуют wsdl.

Такие вещи, как элемент, указанный в методе как тип int, и входящий элемент xml содержит десятичное число.

Определение элемента WSDL: 

<s:element minOccurs="1" 
    maxOccurs="1" 
    form="unqualified" name="ItemCount" type="s:int" >

предоставленный элемент: 

<ItemCount>1.0</ItemCount>

Это оставляет ошибку 500 в журналах iis, но не возвращает информацию о сбое мыла или входных данных, которые вызвали ошибку.

В настоящее время я диагностировал несколько проблем с данными, полученными при захвате всего с помощью wireshark, но я хотел бы знать о других вариантах, которые, возможно, менее навязчивы.

Есть ли способ захвата отправляемых данных, который вызывает 500 ошибок (возможно, ТОЛЬКО захват данных, когда 500 происходит)? Возможно:

  • Настройка IIS
  • Настройка веб-сервиса
  • Изменение кода веб-сервиса

РЕДАКТИРОВАТЬ после тестирования ответ предоставлен tbreffni

Ответ, который лучше всего соответствовал тому, что был у меня после tbreffni - было несколько других хороших ответов, но этот ответ позволяет захватить полезную нагрузку, вызывающую ошибки десериализации, без запуска чего-либо вроде fiddler или wireshark.

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

  • Создайте расширение SOAP как DLL в соответствии с MSDN статьей
  • Добавьте .dll в каталог bin для службы для трассировки

  • В web.config службы для трассировки добавьте следующее в раздел webServices, заменив SOAPTraceExtension.TraceExtension и SOAPTraceExtension, чтобы соответствовать вашему расширению.





Ответы [ 6 ]

3 голосов
/ 17 октября 2008

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

Он очень хорошо умеет работать со сценариями и знает о запросах и ответах, поэтому я думаю, что вы могли бы заставить его регистрировать только 500 ошибок.

2 голосов
/ 21 октября 2008

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

Чтобы реализовать обработчик исключений для веб-службы .Net, необходимо создать расширение SOAP. См. Следующий MSDN Article для примера. Я использовал этот подход в нескольких производственных веб-сервисах, и он неоценим при определении проблем и их возникновении.

1 голос
/ 21 октября 2008

Вы смотрели на трассировку IIS на основе запроса: http://technet.microsoft.com/en-us/library/cc786920.aspx

1 голос
/ 17 октября 2008

Я никогда не использовал это сам, но только что нашел в MSDN: Включение трассировки в веб-службах ASP.NET

0 голосов
/ 21 октября 2008

Если вы хотите использовать инструмент, используйте WireShark.

В противном случае самый простой способ - захватить «все» (если вы используете ASMX) - включить трассировку на system.net

http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx

Если вы используете WCF, он имеет отличную поддержку трассировки, и вы можете использовать svctraceviewer для просмотра журналов трассировки. Не похоже, что вы используете WCF.

0 голосов
/ 17 октября 2008

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

Затем я могу заставить свой фасадный сервис вызывать реальный сервис с входными данными, предоставленными клиентом, а затем:

  • обрабатывать любые ошибки, регистрируя исходные данные и возвращенную ошибку мыла
  • Передать клиенту ответы на достоверные данные

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

К счастью, в этом случае есть только одна сторона, отправляющая сообщения в веб-сервис - методы анализатора пакетов (fiddler или wireshark) возможны, но отсутствие регистрации ошибок 500 заставило меня задуматься, «какие более приятные варианты существуют?» .

...