Здесь английская версия. Английская версия, но уже в TechNet.

Главное описание OD – на MSDN.

Здесь я обсуждаю детали реализации OD.

Замечания по поводу OD

• OD режим (режим упорядоченной, последовательной доставки) противоположен режему Параллельной Доставки. Параллельная доставка – это самый производительный режим; OD – менее продуктивный режим.
• Протоколы, поддерживающие стандарт WS-ReliableMessaging и протоколы, такие как MSMQ, сами по себе поддерживают OD. Другие протоколы, такие как  FTP, File, SQL, SMTP, не имеют понятия о каком-либо «порядке»в последовательностях.
• Обычно приложение BizTalk-a – это только часть полного маршрута на пути доставки сообщений.
• Есть два основных подхода к реализации OD:
  • Все шаги на всем маршруте доставки сообщения поддерживают OD независимо друг от друга.
  • Система, которая является потребителем сообщений, сама восстановливает порядок сообщений, сама беспокоится о потерянных сообщениях и о дублированных сообщениях. Канал доставки сообщений может поддерживать OD и может не поддерживать OD.
• Порядок – понятие относительное. Последовательности могут строиться относительно только одного или нескольких параметров. Например, порядок сообщений может поддерживаться только относительно сообщений, относящийся к одним и тем же компаниям, либо компаниям + отделам внутри компаний.

OD и архитектура BizTalk

• MessageBox – это реализация Очереди Сообщений (Message Queue). OD – это одна из внутренних характеристик MessageBox.
• BizTalk по умолчанию работает в режиме Параллельной Доставки.
• Есть три части в архитектуре обработки сообщений BizTalk-а, не относящихся к MessageBox: Receive Locations; Orchestrations; Send порты.
  • Receive Locations поддерживают OD на уровне транспортных протоколов (к примеру,  в MSMQ и WCF адаптерах).
  • OD в Orchestrations реализовано с помощью шаблона Последовательных Конвоев (sequential convoy pattern).
  • Send порты поддерживают OD для всех статических адаптеров.
• BizTalk Pipelines (входящие в состав Receive и Send портов) всегда обрабатывают сообщения последовательно, используя потоки (streams).

OD и порты

Чтобы заставить Receive Locations работать в режиме OD, мы устанавливаем параметр  “Ordered Delivery” в Receive Location Transports, в тех транспортах, где это поддерживается. Если этот параметр установлен, BizTalk Adapter для соответствующего транспортного протокола автоматически обеспечивает реализацию OD.

Чтобы заставить Send порты работать в режиме OD, мы устанавливаем параметр  “Ordered Delivery” в Send портах. Если этот параметр установлен, BizTalk MessageBox автоматически обеспечивает реализацию OD.

OD Send Port instance работает как singleton сервис, т.е.сервис, который может быть запущен только в единственном экземпляре. После того, как он стартует, он постоянно остается в рабочем режиме (Running state). Он не изменит режим, если мы сделаем рестарт его Host Instance. Если надо, мы можем вручную удалить этот сервис, но по умолчанию он работает неограниченно долго.

OD и Orchestrations

MessageBox реализует шаблон Последовательного Конвоя, чтобы обеспечить OD.  [См.Using Correlations in Orchestrations]. Смотрите детальное описание этого шаблона здесь BizTalk Server 2004 Convoy Deep Dive.
Это не просто шаблон, которому должны следовать разработчики при создании Orchestration. Внутри MessageBox реализованы специальные механизмы, поддерживающие этот шаблон.

OD и Orchestration: Пример

Рассмотим четыре Orchestrations, реализующих разые подходы в последовательной доставке сообщений.

Первое – ProcessNoOrder Orchestration. Оно обрабатывает все сообщения без всякого порядка. По одному экземпляру ProcessNoOrder Orchestration будет создаваться для обработки каждого нового входящего сообщения.

Последнее – ProcessInOrder Orchestration обрабатывает все сообщения в одной последовательности.  Только один экземпляр ProcessInOrder Orchestration будет создан.

ProcessInOrderByCompany Orchestration обрабатывает сообщения в нескольких последовательностях, собранных (кореллированных) (correlated) в соответствии со значением параметра Company (A, B, C, D и т.д.). Отдельная очередь создается для каждого нового значения Company. Сообщения внутри очередей обрабатываются последовательно. Очереди для разных Companies независимы. Отдельный экземпляр ProcessInOrderByCompany Orchestration будет создаваться для каждого нового значения Company.

ProcessInOrderByProduct Orchestration работает абсолютно так же, как и ProcessInOrderByCompany Orchestration но очереди собираются в соответствии со значением параметра Product (xx, yy и т.д.).

Обсуждение

Быстродействие

По умолчанию все экземпляры Orchestration и Messaging сервисов работают в режиме Parallel Delivery, обеспечиая тем самым максимальную производительность.

Если включить режим Ordered Delivery в Send порту, BizTalk будет инициировать экземпляр Send порта как единственный (singleton) сервис. Он будет запускаться всегда только в единственном экземпляре. У нас здесь нет гибкости, которую мы имеем с Orchestration, где мы можем настроить «степень параллельности» и где мы можем контролировать время жизни экземпляров.

Send порт может работать в двух OD режимах, может быть в двух состояниях,  включен или выключен:

• OD выключен: много экземпляров порта, по одному на каждое входное сообщение; одно сообщение на очередь; максимальная производительность.
• OD включен: всегда только один экземпляр порта на все сообщения; все сообщения в одной очереди; минимальная производительность.

Orchestration может работать также в двух OD режимах OD. Чтобы «изменить» режим, нам надо изменить дизайн Orchestration. Это не просто изменение одного параметра в настройках.

• OD выключен: много экземпляров Orchestration, по одному на каждое активирующее входное сообщение; одно активирующее сообщение на очередь; максимальная производительность.
• OD включен: один или несколько экземпляров Orchestration, один на каждую новую коррелированную последовательность сообщений; одна очередь на каждую такую последовательность; производительность от минимальной до максимальной, в зависимости от коррелирующих параметров.

Тщательно спроектировав коррелирующий набор параметров мы можем настроить производительность Orchestration. Например, если мы хотим, чтобы все документы, относящиеся к одной компании, обрабатывались последовательно, мы включаем параметр НазваниеКомпании в коррелирующий набор. Если на тысячу документов приходится сотня компаний, то производительность будет ближе к максимальной. Но если есть только две компании, то производительность будет ближе к минимальной, так как в первом случае документы будут обрабатывать сотня экземпляров Orchestration, а во втором – только два экземпляра. Чтобы увеличить производительность для второго варианты, мы можем добавить в коррелирующий набор дополнительный параметр, к примеру Отдел. В результате будет больше уникальных сочетаний НазваниеКомпании +НазваниеОтдела и будет стартовать больше экземпляров Orchestration.

Orchestrations и Зомби

BizTalk Server version Next, Последовательная доставки и Зомби

Есть вероятность, что BizTalk Server version Next добавит автоматический режим OD в Orchestrations, реализует шаблон, подобный реализованному в Send портах.

Мы увидим три новых параметра в Orchestration: Ordered Delivery, Stop on Exception, и Recycle Interval (in seconds).

Параметр Ordered Delivery работает очень похоже на такой же параметр в Send порту. Теперь нам не надо вручную строить Последовательный Конвой. Не нужен больше Цикл (Loop) внутри  Orchestration.

Было бы замечательно, если бы эти параметры были бы доступны в run-time.

Если параметр Ordered Delivery установлен как True, Orchestration работает как Singleton. Первый Receive будет принимать все коррелированные сообщения в последовательнсти. Коррелирующий набор создается неявно в соответствии с Акривирующим Subscription выражением (Activation Subscription expression).

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

Есть два больших преимущества в новом режиме:

• Это значительно упрощает создание Orchestration, обеспечивающих Последовательную Доставку сообщений.
• Это нивелирует проблему с Зомби. Теперь жизненный цикл экземпляра Orchestration более контролируем. Экземпляр удаляется (recycled) только тогда, когда в MessageBox нет сообщений, стоящих в очередь к этому экземпляру.

Заключение

Мы обсудили реализацию Последовательной Доставки сообщений в BizTalk Server и возможные пути по ее улучшению.

Пора повеселиться

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

Буду рад, если вы напишете свои варианты ответов в комментариях. Спасибо!

Я буду помечать вопросы, на которые поступили интересные / правильные ответы.

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

К примеру, временная проблема в сети может привести к сотням повторяющийся сообщений. В результате email сообщение теряет VIP статус до уровня «белого шума».

Подобные email «наводнения» могут быть «осушены» с помощью этого примера.

Пример демонстирует использование email сообщений в случае ошибок в BizTalk. В примере серии однотипных сообщений фильтруются и, в результате, только одно сообщение уходит к адресату.

Код этого примера загружен на MSDN Gallery. 

Код был использован в нескольких реальных проектах.

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

• Routing Failed Messages in ports
• Catching Failed Messages with Send Port
• Catching Failed Messages with Orchestration
• Handling Exceptions inside Orchestration
• Handling SOAP Fault messages inside Orchestration

В примере – код для BizTalk приложения и троечки Web-services.

Открываю себе потихоньку zip архив. Не открывается. И так пробую, и так. Пришлось в конце концов почитать, что ж там пишется, в ошибке.

Читаю в пятый раз. Не пойму, что ж ему не нравится. Написано же, 174 GB свободно. Что еще надо?

Читаю в шестой раз. Потихоньку проникаюсь ужасом ситуации. Файл в архиве размером в 5.99 PB (пета байт = 1 миллион гига байт).

Я бы его в интернете вывесил, для любования. Но это ж сколько лет надо, чтобы его в интернет загрузить.

Я уже который год получаю ежедневные сводки с Monster.com и с Dice.com по ключевому слову BizTalk. Анализирую тенденции.

Тенденции последних полутора лет таковы:

• Постоянно растет процент позиций по администрированию BizTalk.
• Растет доля проектов по знавоохранению. Ключевые слова HL7 и HIPAA.
• Появляются проекты в финансах. Ключевые слова SWIFT, EDI.
• Все больше новых проектов с EDI.

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

Со здравоохраненьем понятно, сейчас в этой сфере в Америке затеяли большую перестройку. Все бурлит. Компании продаются, покупаются. Рождаются новые стандарты, меняются законы. Новые системы надо интегрировать, без BizTalk не обойтись.

Финансисты начинают проекты с BizTalk по другой причине. Банки и фонды очень консервативны. Новые технологии должны доказать свою состоятельность в течении лет, прежде чем фининсисты решатся доверять им свои деньги. Годы прошли, надежность BizTalk подтверждена на многих больших и малых проектах. Пора переходить от специализированных дорогих интеграционных систем к универсальным, значительно более дешевым системам, таким как BizTalk.

Та же ситуация с EDI проектами. Системы, работающие с EDI стандартом, как правило старые и очень ответственные системы. Эти системы используют большие компании, государственные службы, такие же консервативные, как и банки.

Тенденции четко показывают, то BizTalk выходит в стадию зрелости.

Microsoft Virtual Academy

Evaluation Download Center

TechNet Cloud Hub

• About the BizTalk Orchestration Engine
• BizTalk Server 2004 Convoy Deep Dive
• Working with Convoy Scenarios
• Using Correlations in Orchestrations
• Using Transactions and Handling Exceptions

Теории здесь на несколько дней.

Practice:

1. В Проект №1 (совсеми последующими улучшениями) добавить orch OrderShipping, которое принимает все OrderDetails, адресованные отдельной ShippingCompany. Сделать его, используя шаблон Unified Sequencial Convoy. Первое сообщение OrderDetails будет активировать отдельную orch instance для отдельной ShippingCompany. Последующие сообщения OrderDetails будут обрабатываться этой же instance. Все OrderDetails объединяются в одно сообщение OrderDetailsSummary (cделать схему этого сообщения).  OrderDetailsSummary завершается после объединения 5 сообщений OrderDetails ИЛИ через 10 минут после старта. OrderDetailsSummary выводится в FILE Send port.
2. Добавить еще один FILE Send port, который будет отлавливать и выводить сообщения FailureReport. Смоделировать ошибки в orch  и убедиться что информация об ошибке доставляется на этот порт.
3. Добавить SMTP Send port, который будет отлавливать и отправлять по почте информацию об ошибках.
4. Tracing: во все orch добавить Expression shapes в след.местах: в начале/конце orch; после создания/receive/send всех сообщений; после ветвления в шейпах с несколькими ветвями; после начала каждого нового цикла в Loop. В Expression shapes добавить вывод отладочной информации: содержимое новых сообщений, измененных переменных и т.п. Использовать DebugView, чтобы вывести эту отладочную информацию.
5. Tracking: включить полный Tracking для всех orch и портов. Отследить: прохожение сообщений; содержимое сообщений во всех возможных точках; контекст сообщений.
6. to be continued…

Практики по этой части будет еще много.

Maps: практика и еще раз практика. Теории здесь мало.

Основные моменты в трансформациях:

• Изменения в уровнях вложенности.
• Schema paremeters: MinOccurs and MaxOccurs
• Преобразования в/из Empty и Null значения.
• Условные преобразования
• Коды, их использование, генерация, lookup
• Script functoids: in-line code; Xslt-code; Xslt-templates
• Использование pure Xslt.

Задания:

1. Сделать map схемы Order.xsd в схему ShippingOrder.xsd. Это пример на трансформацию схемы с глубокой иерархией узлов в так называемую «плоскую» схему. [Файлы схем надо сохранить и переименовать, удалив .doc в конце.]
2. Сделать обратное преобразование: map схемы ShippingOrder в Order.
3. Условные преобразования: При преобразовании из п.1 использовать такую логику: TotalAmount = Quantity * Price * (100%+Tax). Tax определяется по полю CompanyOriginator.Address.StateProvince: если WA, то Tax = 10%, если CA, то Tax = 8.5%, если BC, то Tax = 12%. Могут быть только три вышеперечисленных значения.
1. при преобразовании использовать только обычные фанктоиды. Script functoid не испльзовать.
2. использовать Script functoid: Inline C#
3. использовать Script functoid: Inline Xslt
4. использовать Script functoid: Inline Xslt call template
4. В Order_to_ShippingOrder map для nodes OrderDetail.item и company name добавить дополнительную логику: если node is Null, то в ShippingOrder должно получиться не Null, а Empty string, т.е.пустая строка («»). Соответсвенно изменить схему Order, чтобы эти nodes могли быть null. Использовать те же четыре метода из предыдущего пункта.
5. В Order_to_ShippingOrder map для nodes Order. добавить дополнительную логику: если StateProvince в полном виде (к примеру Washington), то сделать преобразование в кодWA. Если уже WA, то использовать то, что есть. Если ошибка в StateProvince, то использовать то, что есть. Только для тех StateProvince, которые перечислены в п.3.
6. Повторить п.5, но для преобразования сделать и использовать  дополнительный C# проект …Helper , класс MapHelper.

В качестве образца с удовольствием рекомендую проект Андрея Кошелева.

• Создание Web-service (WS)
• Интеграция BizTalk с WS
• Publishing WS – Создание WS из BizTalk
• Consuming WS – Обменн данными между WS и BizTalk

 Одна из важнейших частей системной интеграции – Web-services (WS). Для начала сделайте Лабораторную работу (см.ниже 1), потом почитайте немного теории. Чтобы сделать следующие (см.ниже 2 и 3) примеры, вам понадобится установить Windows Samples. Здесь инструкции по загрузке и установке. Сами примеры небольшие и не загромождены частностями.

BizTalk может делать (publish) WS на базе Orch, т.е.он показывает Orch внешнему миру, как будто это WS. Кроме этого он может использовать (consume) WS, т.е. запрашивать и получать данные у WS.

Для независимой отладки WS чаще всего используется утилита SoapUI. Ее бесплатную версию желательно скачать и установить.

Все это может занять 4-10 часов.

Практика:

1. MSDN Virtual Lab: BizTalk Server 2009: Using the WCF Adapters in BizTalk Server 2009
2. Windows Communication Foundation (WCF). Getting Started sample
3. Windows Communication Foundation (WCF). Getting Started Tutorial

Теория

1. Windows Communication Foundation (WCF) Conceptual Overview
2. BizTalk Server 2010: Using Web Services
3. BizTalk: Document: Consuming and Exposing Web Services from an Orchestration