Где и как ссылки на сборки сериализуются или десериализуются в Biztalk - PullRequest
0 голосов
/ 11 января 2012

Я застрял с проблемой. У меня есть приложение BizTalk 2010, которое ссылается на сторонние схемы DLL. Наш Архитектор сказал нам, чтобы мы не ссылались на него напрямую, так как для сериализации этой огромной библиотеки размером около 9 МБ потребуется больше времени, что вызовет больше работы Biztalk.

Поскольку эта DLL третьей части является схемой DLL, она будет развернута на MgmtDb под любым из приложений до любого другого развертывания приложения. Наши сообщения оркестровки имеют типы сообщений, на которые ссылаются из этой схемы dll.

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

Выполняется ли сериализация для каждого сообщения, которое создает экземпляр оркестровки.

Пожалуйста, поделитесь своими мыслями.

Спасибо.

Ответы [ 2 ]

2 голосов
/ 11 января 2012

Хотя верно, что указанная сборка будет добавлена ​​в MgmtDB, AFAIK, это только метаданные о сборке и добавленных в нее артефактах, например,

use BizTalkMgmtDb
select * from dbo.bts_assembly
... dbo.bts_orchestration
... dbo.bt_DocumentSpec
etc.

Возможно, он или она ссылается наэкземпляры сообщений, созданные из классов схемы в сборке (и хранящиеся в окне сообщений).Но размер сообщений будет определяться размером данных в нем, а не размером сборки.

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

Однако если эта сборка схемы, на которую ссылаются, также содержит другие артефакты, такие как пользовательские классы, используемые в оркестровках в качестве переменных, эти классы также должны быть serializable , как только оркестровка достигнет точки дегидратации (во избежание этого вам нужно будет выделить переменные перед обезвоживанием и / или использовать атомарную область действия, чтобы вообще не допустить дегидратации BizTalk, но обычно этоплохая идея, так как это ограничит масштабируемость)

0 голосов
/ 16 января 2012

Ваш Архитектор сделал неверное предположение о том, что BizTalk выполняет проверку Документа по его определенной Схеме.

Проверка большого документа по здоровенной Схеме, такой как EDIFACT или OASIS, может занять много времени.Ресурсы.Следовательно, BizTalk не будет проверять входящий документ по соответствующей схеме, если вы явно не попросите его сделать это в конвейере приема.По умолчанию для большинства компонентов Pipeline свойство ValidateDocument имеет значение «False».Таким образом, BizTalk будет выполнять распознавание документов только на основе пространства имен и корневого узла, и это делается при чтении потока первой пары сотен байтов потока документа.

Таким образом, вы можете свободно «ссылаться» наDLL сторонних производителей, единственное снижение производительности будет во время компиляции и развертывания.Если по какой-либо причине вам необходимо проверить Документ по этой Схеме, вам необходимо иметь его в БД управления независимо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...