Зомби в BizTalk

Question

У меня есть приложение BizTalk 2006 R2, которое отлично работает. Он получает сообщения, обрабатывает их и отправляет правильные ответы.

Но хотя все правильно (сообщения успешно подобраны оркестровкой и ответ отправляется без ошибок), BizTalk по-прежнему генерирует «сообщение не потребляемую» ошибка, связанные с сообщением ответа ...

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

Есть ли у кого-нибудь идеи о том, что может вызвать эту ошибку?

Answer 1

Это звучит как зомби. Использует ли ваша оркестровка корреляцию и время ожидания? Если это так, вы находитесь на Земле Зомби. Проблема в том, что у вас есть ожидание и просмотр seocndary в ожидании, чтобы увидеть, какие триггеры первыми. Если ожидание запускается первым, а затем появляется новое сообщение о корреляции, ... Zombie.

Сообщите нам больше о вашей оркестровке, и мы сможем обсудить решение.

Answer 2

Да, это распространенная проблема, которая в большинстве случаев может быть преодолена небольшим изменением способа объединения вашего решения.

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

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

Способы минимизации этой проблемы заключаются в сокращении объема работы, которую выполняет оркестровка после тайм-аута. Сделайте окно для Зомби возможным как можно меньше.

Иногда невозможно избежать этой проблемы без детерминированного термина, поэтому я обнаружил, что я создаю процесс «ZombieHandler», который получает эти сообщения и очищается после себя.

Если бы вы могли написать больше информации о вашем процессе, мы могли бы попробовать помочь еще.

Answer 3

Ошибка находится на панели группы BizTalk, а не в журнале событий, и является «экземпляр завершен без использования всех его сообщений. Экземпляр и его неиспользуемые сообщения были приостановлены». В принципе, у меня есть основная оркестровка, которая получает сообщение через двухсторонний порт, отправляет его в поле сообщения при инициализации корреляции. Следующая форма в этой оркестровке ждет сообщения (без какой-либо логики таймаута) и следует за корреляцией, созданной в предыдущей форме отправки. Когда ответ получен, он отправляется обратно первоначальному реквестору.

Это очень простая оркестровка (скриншот: http://img139.imageshack.us/img139/2307/orchestration.jpg) практически без логики. Дело в том, что я всегда получаю правильные ответы, поэтому я не могу понять, что вызывает ошибку «сообщение не потребляется». Кстати, сообщение, помеченное как нерасходуемое, является ответным сообщением.

Другие идеи?

Ps. ryancrawcour, можете ли вы рассказать о своем ZombieHandler? К каким свойствам вы привязываете такую ​​оркестровку?

Answer 4

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

Можете ли вы сделать шаг назад и объяснить, что является требованием для корреляции? Какие сообщения вы пытаетесь связать togeather здесь? Я предполагаю, что если вы удалите корреляцию из этой оркестровки, она будет работать отлично.

Вот вам link в корреляционном учебнике, если вы хотите взглянуть.

Answer 5

@ChrisLoris:

Скриншот оркестровки: http://img139.imageshack.us/img139/2307/orchestration.jpg

На скриншоте выше вы можете видеть, что у меня есть гармоническое сочетание, связанный с приема/передачи порта. В основном я получаю сообщение для обработки, обновляю несколько атрибутов и отправляю его в поле сообщения при инициализации корреляции на основе определенного свойства (позволяет называть его MsgIdentifier). Другие оркестровки будут отображать это сообщение и выполнять реальную обработку. Когда ответ отправляется в окно сообщения с тем же MsgIdentifier (настраиваемое свойство), эта оркестровка выбирает его и отправляет обратно исходному реквестору.

Корреляция инициализируется в форме отправки, которая отправляет запрос в поле сообщения, и следующая форма приема ожидает ответа, который следует за той же корреляцией, то есть имеет то же значение в свойстве MsgIdentifier.

Подумайте об этом оркестровке в качестве брокера, посредника между внешней системой и внутренней работой приложения BizTalk.

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

Answer 6

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