BizTalk - Почему приостановленное сообщение появляется в консоли для обработанного исключения?

Question

Вот изображение общей структуры, которую мы имеем в нескольких наших оркестровках BizTalk:

Поэтому, когда мы получаем информацию из API, а учетная запись не существует, мы прекращаем оркестровку. Это работает нормально, и я вижу, как оркестровка делает это и завершает свою работу, когда должна, но чего я не понимаю, почему я вижу приостановленное сообщение из GET в консоли? Поскольку обработка исключений работает, разве это не должно останавливать отображение ошибки в консоли?

В качестве обходного пути я рассмотрел использование компонента конвейера для проверки ответного сообщения, и если оно содержит то, что игнорироваться, просто вернуть null вместо сообщения. Будет ли это иметь желаемый эффект? Меня больше интересует, почему я вижу приостановленные сообщения в консоли.

Answer 1

Да, это известная проблема с адаптером WCF-WebHttp, связанная с тем, что он возвращает его как отформатированную ошибку SOAP, но без установки свойства контекста MessageType (см. Мой сообщение в блоге и найдите ошибку: адаптер BizTalk WCF-WebHttp не устанавливает тип сообщения при ошибке). Таким образом, хотя исключение возвращается в Orchestration и может обрабатываться там, сообщение не так, как BizTalk не знает, какой это тип, и оно приостанавливается.

Обходное решение, которое мы используем:

1. Чтобы установить параметр «Включить маршрутизацию для сбойных сообщений на порте отправки»
2. Чтобы иметь порт отправки, который подписывается на все ответные сообщения с этого порта отправки с использованием фильтра BTS.SPName = xxxx, а порт отправки отправляет его на пользовательский адаптер NULL (выбросить сообщение), и да, ваша оркестровка все равно получит хороший ответ, а также исключения.
3. Обновите порт отправки, который обрабатывает ошибки маршрутизации от других портов отправки, которые мы хотим go за исключением нашего исключения, чтобы исключить те порты отправки, которые мы обрабатываем через оркестровку.