2015-07-24 3 views
5

У меня есть оркестровка, которая получает запрос от службы локального отдыха, а затем отправляет запрос другой удаленной службе отдыха, а если удаленная служба успешно возвращает ответ с 200 HTTP-кодом, BizTalk сможет обрабатывать ответное сообщение , но если код ответа HTTP отличается от 200, BizTalk не смог обработать сообщение об ошибке.BizTalk Catch Http Ответный код

Журнал BizTalk дает нижеприведенную ошибку при просмотре событий.

Details:"System.Net.WebException: The remote server returned an unexpected response: (400) Bad Request. 
{"errorMessage":{"message":"En az 1 adres alani gereklidir.","moreInfoURL":"http://paritus.com/kb/api-errors","status":400}}". 

enter image description here

После этого вопроса я добавляю операцию замыкания на порт отправки, но BizTalk все еще не мог поймать сообщение потерпеть неудачу. У вас есть идея?

+0

Что находится в разделе «Исключение сбоя»? Вы поймаете System.Exception? Или вы поймаете Fault_1. Что определено в Fault_1? – Sven

+0

На самом деле я пытаюсь поймать сообщение об ошибке_1, которое появилось из порта отправки, но я не могу уловить ответ об ошибке HTTP. Если есть другая идея для обнаружения сообщения о неисправности, я могу попробовать ваше решение. – ibrahimsen

+0

Является ли это попыткой использовать адаптер WCF-WebHttp? Да, сообщение об ошибке не будет входить в неисправность порта, поскольку он не устанавливает тип сообщения в создаваемой SOAP-ошибке. На мой взгляд, ошибка, о которой я писал в своем блоге. Вы должны поймать его как System.Exception – Dijkgraaf

ответ

1

На самом деле вы не можете поймать такое исключение без дополнительной строки кодов :), потому что, когда вы поймаете это исключение на уровне оркестровки, WCF-адаптер уже инкапсулировал его, и вы не можете получить доступ к коду ошибки, проверьте эту статью для обработки таких ошибок. http://social.technet.microsoft.com/wiki/contents/articles/16625.biztalk-server-rest-services-error-handling.aspx

0

Да, есть проблема с адаптером WCF-WebHttp, поскольку он не устанавливает свойство контекста типа сообщения, если есть ошибка, и поэтому он не переходит в Тип ошибки определяется на порту.
Единственный способ поймать его - это блок System.Exception.

Смотрите мой блог BizTalk 2013 R2 known bugs, issues & quirks, BUG: BizTalk WCF-WEBHTTP АДАПТЕР НЕ SET MESSAGE TYPE ON ERROR

Update: Внизу больше не пытаться после CU 5 для BizTalk 2013 R2

также обратите внимание, что если конечные системы выдают код состояния 500, он НЕ выбрасывается как ошибка вообще, и вы должны сами проверить код состояния.

См. BizTalk WCF-WebHttp adapter does not detect 500 error