Разблокировать входящее сообщение и создать фиксированный пакет входных сообщений в оркестровке

Question

http://blogs.msdn.com/b/brajens/archive/2006/07/20/biztalk-custom-receive-pipeline-component-to-batch-messages.aspx

Я следую вышеприведенной статье, но хочу реализовать это в оркестровке

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

1. Использование цикла foreach.
   а) прочитать каждое сообщение и добавить в новое сообщение, пока оно не достигнет фиксированная партия
   б) используя позицию xpath / [local-name () = 'Root' и Пространство имен-URI () = 'http://mycompany.com']/[local-name()='content' и namespace-uri () = '' и position ()> = 0 и position <фиксированный размер] (что не работает) </p>

2. Вызов компонента пользовательского трубопровода (как указано выше)

---

Прежде всего, спасибо парню за все ваши ценные ответы,

Прямо сейчас я реализовал это в оркестровке, используя цикл foreach, xpath (счетчик тог и один входной узел) и переменную сообщения (создал новое неограниченное сообщение для назначения связанного фиксированного номера входных сообщений). Сейчас работает нормально.

Вы, ребята, согласны с этим подходом или у вас есть какие-либо проблемы?

Answer 1

Простой способ достижения высокой пропускной способности (большие сообщения и / или большое количество сообщений) - запустить входящее сообщение через карту в принимающем порту, который использует пользовательский XSLT. Эта карта затем сгруппирует XML в группы правильного размера - после отображения XML может выглядеть примерно так:

<ns0:sample xmlns:ns0='http://MGSIBREDemo.LoanRequest' xmlns:ns1='http://MGSIBREDemo.LoanRequestGroup'>
 <ns1:group>
  <data1><name>name1</name></data1>
  <data1><name>name2</name></data1>
  <data1><name>name3</name></data1>
  <data1><name>name4</name></data1>
 </ns1:group>
 <ns1:group>
  <data1><name>name5</name></data1>
  <data1><name>name6</name></data1>
  <data1><name>name7</name></data1>
  <data1><name>name8</name></data1>
 </ns1:group>
 <ns1:group>
  <data1><name>name9</name></data1>
  <data1><name>name10</name></data1>
 </ns1:group>
</ns0:sample>

После этого первого шага вам нужно будет отправить сообщение из BizTalk и получить его снова. Затем вы можете использовать обычный конвейерный компонент XML disasebler для отладки сообщения (как, например, описано здесь ).

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

Недостаток заключается в том, что производительность снижается при записи сообщения на диск или в очередь для последующего их чтения.

Было бы замечательно, если бы была возможность выполнить отладку на стороне отправки с использованием ассемблера XML, но сегодня это невозможно.

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

Answer 2

Лучшее решение - использовать пользовательский компонент конвейера, такой как тот, на который ссылается ваш вопрос.Прелесть этого в том, что вы можете вызывать конвейер изнутри оркестровки, и его не нужно привязывать к определенному месту приема: http://geekswithblogs.net/sthomas/archive/2005/06/16/44023.aspx.

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