Properties promotion/demotion




НазваниеProperties promotion/demotion
страница1/17
Дата конвертации12.12.2012
Размер0.65 Mb.
ТипДокументы
  1   2   3   4   5   6   7   8   9   ...   17

Заметки : bts_CleanupMsgbox




Вторник, 17 Февраля 2009 г. 02:39 (ссылка) +в цитатник или сообщество +поставить ссылку

Странный параметр этой stored procedure остается 0 при ее интерактивном запуске. Но если по каким-то причинам вас угораздило изменить его на 1 и вы потеряли все активные subscriptions - не все потеряно. Экспортируем все (Sic!) установленные в  BizTalk group applications и импортируем их заново из полученных msi. Потерянные subscriptions будут восстановлены!

Рубрики: 

BizTalk




Комментарии(0) [+ в друзья]

Properties promotion/demotion




Суббота, 06 Сентября 2008 г. 01:59 (ссылка) +в цитатник или сообщество +поставить ссылку

 As a direct message creator, the receive adaptor has a practically unfathomable power over the message context. It kindly writes to the context whatever it is that an adaptor designer's infinite power contemplates: the properties it considered to be useful and valuable, but two of these properties are extremely important.
These are "MessageType" and "InboundTransportType". They so important not only because most of subscriptions are evaluated on the "MessageType" stuff, but also because sometimes promoted properties are only the one way to link together the content and the context of the message.
The story of promotion, began in the receiver, is unfinished business. If following the BizTalk Engine and the XML Pipeline (if desired), within which XML Disassmbler component pushes up all the message fields and attributes marked as promoted, into the same message context. You can rely on this feature for safely map the inbound document into another one as the part of receive port. If the target of mapping does not have the same structure as the original message and you wondering how to pass into the 'extended' fields - just promote them in the original message and XML Disassambler will do the job. 'Extended' fields will be passed into in the message context.
Following the message life-circle, the context is brought to the orchestration.
 Here the things going easy: despite any transformation, you can pass through the context as simple as coping it all (Message2(*) = Mesage1(*)) or its part (Message2(MyPromotedPropert1) = Message1(MyPromotedProperty1) ) to the transformation target. But how the orchestration itself can promote additional properties?
Well, it actually does so a lot when it uses correlation sets, dynamic port addressing and so forth. All it is about the promotion. For example, when XLANG/s schedule assigns the dynamic port address; it actually asks the engine to stick the address property on the outbound message so the further processing will takes it into the consideration. The same is true about the correlations: the correlated properties are promoted when leaving the schedule on behalf of their 'initialization' and are participated in subscription evaluation when they come back in the 'following' receive.
Explicit intentions to promote the property also may be expressed by orchestration, but they remain just intentions.  Without passing to XML Disassembler these properties will never reach the context – so happens to the promotions did in the orchestration and passed through direct send port: no pipeline is attached to direct port processing and consequently no XML Disassembler will realize the intentions.
Going in opposite direction, there is must be a way to do the reverse operation that may be called as simple as context’s cleaning up. It’s generally good idea to keep the context as small as needed for the processing. (Maybe because the fact that if the context were only growing it would become Samoan.) Such operation is known as demotion and all its about is to populate the message content by the properties already published to its context. Usually after demotion, the context properties are cleaned up and sometimes just this part of the procedure is called demotion as well.
As you can deduce, the component responsible for this duty is XML Assembler build-in with a XML Send pipeline, although it is a bit quirky then its brother. Indeed, it rationally designed to ignore the message entries if they already were populated.  Given that sadness fact that xml-nills are considered to be the first class citizens in the document population, this rationality leaded to confuse many BizTalk-programmers. The special value presented in BizTalk mapper in 2006 edition dilutes the population.
Worth to note that property demotion may be based not only on the custom property schema you added to the BizTalk solution. When you build up the promotion for the document schema, you can reference any pre-build property schema that shipped with BizTalk.

Рубрики: 

BizTalk




Комментарии(0) [+ в друзья]



(Почти) все о BizTalk MessageBox




Пятница, 29 Августа 2008 г. 17:43 (ссылка) +в цитатник или сообщество +поставить ссылку

MessageBox - это центральная часть BizTalk Server, которая служит для ведения сообщений и их адресации. MessageBox представляет собой базу данных, реализованную на Microsoft SQL Server, в основе дизайна которой лежат следующие фундаментальные принципы :

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

  • Доступ к MessageBox имеет только специальная часть BizTalk Server - Message Agent. Ему, почти единственному, разрешено записывать в базу новые объекты, удалять и изменять их. Message Agent не имеет документированного API. Доступ к нему, в свою очередь, возможен только в той степени, в которой внешним программам - прежде всего, адаптерам - нужно абстрагировать процесс создания, модификации или удаления сообщений в терминах абстрактных сообщений, но никак не в терминах объектов базы данных.  Все остальные программы могут, но очень осторожно, исполнять только запросы на выборку и просмотр объектов из таблиц базы. Messageagent реализован в виде COM server, из .NET доступ к нему возможен с помощью Microsoft.BizTalk.Agent.Interop.

  • MessageBox разработан для поддержки только корпоративных сетей. О попытках вынести его за пределы таких сетей, сделав доступным для Интернет-сервисов, см. здесь.

  • Попав в MessageBox, сообщение становится неизменяемым, т.е. все, кто получают это сообщение впоследствии, на самом деле имеют дело с его копией, в которую нельзя вносить изменений. С точки зрения MessageBox, этот принцип позволяет быть более экономным, сохраняя только оригинал сообщения, и в дальнейшем увеличивать/уменьшать только  связанный с ним RefCounter.

Для повышения эффективности сообщения записываются в MessageBox как batch. Batch генерируется в MessageAgent  и может считаться набором сообщений, рассматриваемых как одна транзакция. Многие batches однако, состоят только из одного сообщения.

Как часть batch, сообщения попадают в MessageBox в два этапа. На первом этапе вызывается stored procedure bts_InsertProperty, задачей которого является занести все контекстные properties сообщения в таблицу MessageProps в сопровождении соответствующего batchID. Сразу же после этого вызывается другая stored procedure - bts_FindSubscriptions, кот. должна проверить subscription predicates на сравнение с записанными properties, т.е. найти хотя бы одного подписчика для записываемого сообщения. Если не удалось вычислить ни одного подписчика, сообщение удаляется из рассмотрения с сопроводительной ошибкой. (Error event 5778 - "Could not find a matching subscription for the message."). 

Если хотя бы один подписчик найден, сообщение записывается в таблицу spool, где оно и будет находиться на все время своей жизни внутри BizTalk. Еще до записи в таблицу MessageProps, сообщению присваивается уникальный GUID, кот. для таблицы spool записывается в колонку uidMessageID. Это и есть уникальный номер сообщения, на который, начиная с этого момента, будут ссылаться все остальные записи в других таблицах, или, другими словами, все BizTalk-services, которые тем или иным способом будут иметь дело с этим сообщением. Stored procedure, исполняющая запись сообщения в MessageBox, называется bts_InsertMessage. Она же, зная связанный с сообщением batchID,  удалит только что записанные MessageProps, если запись завершилась успешно.

Сообщение состоит из parts. В простейшем случае из одной, называемой body. Но и в более сложных случаях невозможна ситуация, когда подписчик получит только part сообщения, а не его целиком. Тем не менее, с точки зрения MessagedBox, сообщение хранит свои parts отдельно от самого сообщения, в таблице MessageParts. Название bts_InsertMessage не совсем отвечает предназначению этой stored procedure : для каждого вносимого в MessageBox сообщения она вызывается несколько раз, причем каждый эта процедура исполняет несколько различные функции, в зависимости от передаваемых параметров. При первом вызове bts_InsertMessage просто внесёт в таблицу spool контекст сообщения (поле imgContext), а последующие вызовы запишут parts сообщения в таблицу Parts. Запись в Parts осуществляется "внутренней" stored procedure под названием int_InsertPart.

Вообще все db-процедуры, оперирующие сообщениями, рассматривают их как image. В этот image записывается stream из IBaseMessagePart.Data, который, в свою очередь, представляет собой сериализированную форму сообщения : в большинстве случаев XML, но можер быть и любой объект, поддающийся сериализации и де-сериализации.

Вернемся к bts_InsertMessage. Помимо занесения сообщения в таблицы Spool и Parts, эта процедура (с помощью bts_EvaluateSubscription) сообщает о нём BizTalk host'у, просматривая имеющиеся subscriptions на предмет найти нужного подписчика. Как только подписчик  найден, это означает для MessageAgent, что ему известен host, который должен обработать данное сообщение. В самом деле, смысл создания subscription состоит не только в назначении предикатов, но и в сопоставлении их равенства определенному сервису,  который назначен на обработку сообщений, удовлетворяющих проверенным предикатам. Поэтому в таблице Subscription  поле nvcApplicationName содержит имя host'a. Теперь по этому имени MessageAgent знает, в workQ какого host'a нужно передавать сообщение.  Делается это с помощью stored procedure int_InsertIntoQ_
  1   2   3   4   5   6   7   8   9   ...   17

Похожие:

Properties promotion/demotion icon*мит-инфо   russian national centre 
...
Properties promotion/demotion icon   ..  (Table)   (Table Properties)

Properties promotion/demotion iconПротокол № от 2012 г. Автор: Костенко Анатолий Филиппович Рецензенты: Голованов В. М. канд пед наук, профессор ман, член Общероссийского Союза писателей «Воинское содружество»
Костенко А. Ф. Самопродвижение (self-promotion) – стратегия самопрезентации. – Борисоглебск. 2012, 168 с
Properties promotion/demotion iconНастоящий цветок в букете Djеев от Deniskin Promotion Booking&Event Agency
Сначала она просто позировала за пультом, а музыка играла с cd без ее участия, но уже после нескольких подобных выступлений она поняла,...
Разместите кнопку на своём сайте:
kak.znate.ru


База данных защищена авторским правом ©kak.znate.ru 2012
обратиться к администрации
KakZnate
Главная страница