Запись в журнале событий движка xlang / s: Ошибка при создании службы X. Объект типа «Y» не может быть преобразован в тип «Y»

Question

xlang / s запись в журнале событий движка: ошибка при создании службы X. Объект типа «Y» не может быть преобразован в тип «Y».

Эта запись журнала событий выглядит так же, как обсуждается здесь:

Microsoft.XLANGs.Core.ServiceCreationException: Ошибка при создании службы ABC

Я исследовал 2 решения, предложенные в этом посте, но ни одно из них не устранило мою проблему.

Я использую BizTalk 2010 и вижу проблему с единообразным последовательным составом. Каждый экземпляр оркестровки изначально активируется, как и ожидалось. Все фигуры до получения второй фигуры выполняются без проблем. Проблема возникает, когда экземпляр оркестровки получает второе сообщение. Выполнение не продолжается после формы получения, которая соответствует этому второму сообщению.

Используя страницу Group Hub, я вижу, что второе сообщение связано с правильным экземпляром службы. Этот экземпляр службы приостановлен, и приведенное выше сообщение об ошибке отображается в журнале событий.

Иногда (примерно 1 из каждых 5 раз) вышеупомянутая проблема НЕ возникает. То есть последующие сообщения обрабатываются оркестровкой. Я кормлю одни и те же тестовые файлы каждый раз. Еще интереснее ... проблема НИКОГДА не возникает, если я устанавливаю точку останова (в Orchestration Debugger) для формы Listen непосредственно перед второй формой приема.

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

Кто-нибудь имеет представление о том, как предотвратить возникновение этой проблемы?

Спасибо

Answer 1

Я подал эту проблему в Microsoft.Оказывается, что «такое поведение на самом деле является существующим ограничением проекта, когда компилятор XLANG полагается на упаковщики типов».Проблема возникла по очень специфическому сценарию.У нас была оркестровка с переменной сообщения, непосредственно ссылающейся на схему, и другой переменной сообщения, ссылающейся на тип сообщения, состоящий из нескольких частей, основанный на той же схеме.Оркестровка, схема и тип сообщения из нескольких частей были определены в разных проектах.

Microsoft предложила изменить одну из переменных, чтобы обе ссылались на схему или оба ссылались на MMT.К сожалению, сохранение переменных такими, какими они были, было для нас критически важно.Мы обнаружили (и Microsoft подтвердила), что перемещение определения MMT в тот же проект, что и оркестровка, также решило проблему.

Answer 2

Используется ли только один хост-сервер BizTalk? Меня не удивит, если проблема будет связана с трудностью загрузки требуемой сборки из GAC. Если было задействовано несколько серверов BizTalk, возможно, один из них является виновником (или только один из них не является). Конечно, это может быть не так просто.

Альтернативой является второй ответ на другой вопрос, с которым вы связались, с указанием проверить, что требуемая схема не развернута более одного раза. У меня была эта проблема раньше, и единственный способ выяснить, что это происходит, это посмотреть в консоли администрирования BizTalk в BizTalk Group > Applications > <AllArtifacts> > Schemas и отсортировать по целевому пространству имен, чтобы увидеть, есть ли два (или больше) строки с одинаковой комбинацией целевого пространства имен и корневого имени.

Проблема также может быть вызвана несоответствием схемы, когда, возможно, развернута более старая / другая версия схемы, чем ожидалось, и поле, которое присутствует только иногда (следовательно, иногда оно работает), вызывает несоответствие. *

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