Развертывание BizTalk — файлы привязки неправильно импортированы в настраиваемый компонент конвейера

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

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

<ReceivePipelineData>&lt;Root xmlns:xsd="http://www.w3.org/2001/XMLSchema" … Components&gt;&lt;Component Name="I.MMA.COMPONENT"&gt;&lt;Properties &gt;&lt;Customer vt="8"&gt;CUSTOMER_NAME&lt;/Customer&gt;&lt; … etc.

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

У меня такое поведение на разных машинах, кто-нибудь понял, что происходит?


biztalk custom-pipeline-component biztalk-deployment
person Tom Kerkhove    schedule 30.10.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Недавно я переместил свой компонент конвейера с одного этапа на другой, но не обновил Stage CategoryId, и значения были проигнорированы.

person Tom Kerkhove    schedule 30.10.2013

arrow_upward
0
arrow_downward

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

person Bert    schedule 31.10.2013
comment
Проблема заключалась в том, что я не обновил свой Stage CategoryId, как указано ниже! - person Tom Kerkhove; 31.10.2013