BizTalk Zombies - любой способ явно УДАЛИТЬ подписку из оркестровки BizTalk

Question

Справочная информация:

Мы используем множество агрегационных, одноэлементных и многотонных оркестровок, аналогично методике Кругового Робина Серотера , описанной здесь (BizTalk 2009).

Все эти типы оркестрации имеют довольно произвольные точки выхода или продолжения (для агрегатов), обычно определяемые таймером - то есть, если Orch не получил больше сообщений в течение X минут, затем приступают к пакетированию,и если по истечении Y прошло больше минут, а сообщений больше нет, выйдите.(Мы также закрываем наши одиночные / N-тонны из-за опасений по поводу снижения производительности после того, как большое количество сообщений было подписано на синглтон за период).

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

Если сообщение вызывает зомби в одной из подписок, сообщение также не распространяется на ДРУГИХ подписчиков (то есть орги полностью отделены от оркестровки «вызывающих зомби»), то есть сообщение, вызывающее зомби, не обрабатывается.

Вопрос

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

На этом этапе мы рассмотрим даже решение для взлома, такое как отраженный вызов BizTalk API или прямое удаление SQL для MsgBoxDB.

Answer 1

Нет, вы не можете явно удалить подписку в Orchestration.

Подписка будет удалена, так как Orchestration завершает свою работу, но сообщение, поступающее в этот точный экземпляр, будет направлено в Orchestration, нооркестровка закончится без обработки, и это ваш зомби.

Статья Microsoft о зомби http://msdn.microsoft.com/en-us/library/bb203853.aspx

Мне когда-то также приходилось иметь шаблон получения, отправки, агрегирования и отправки.Получение конвертированных сообщений от нескольких отправителей, их обработка, агрегирование по предполагаемому получателю (на основе двух правил: количества сообщений или задержки по времени, в зависимости от того, что наступило раньше).Этот сценарий созрел для Зомби, и когда я прочитал о них, я разработал его так, чтобы этого не произошло.Это было для BizTalk 2004 года. Я отослал сообщения и вставил их в базу данных.У меня была хранимая процедура, которая была опрошена принимающим портом, который работал бы, если бы был пакет для отправки, если он был, это вызвало бы Orcherstration, который принял бы это сообщение и динамически направил бы его.Поскольку ни одному из оркестров не пришлось ждать другого сообщения, они могли бы закончить грациозно, и не было бы зомби.