BizTalk Summit 2012: возрождение

В Microsoft кончились разговоры о плавном перерождении BizTalk Server в Azure. Microsoft восстанавливает инвестирование в BizTalk в полном объеме (?) Ура!

Несколько факторов стали решающими:

  • Влияние проходящего, вяло текущего кризиса
  • Поднимающаяся волна обновлений версий BizTalk Server
  • Давление клиентов и партнеров
  • Microsoft стал зарабатывать на BizTalk

Все это мы узнали на прошедшем в Рэдмонде саммите, посвященном одному продукту Microsoft, BizTalk Server.

Cам факт этого саммита уже говорит о многом. Я не припоминаю подобных мероприятий в последнее время, посвященным отдельным продуктам.
Открывал конференцию большим докладом Scott Guthrie. Ничего конкретного я тут сказать не могу, саммит проходил на условиях NDA, т.е. почти все, что нам рассказывали, было секретом. То, что я здесь рассказываю, является результатом моих умозаключений и не представляет собою официальную точку зрения Microsoft.

Теперь поподробнее об этих самых факторах.

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

Оканчивается срок гарантийной поддержки BizTalk Server 2006, той самой версии с которой и начался бум внедрений BizTalk. Старые версии работают по-прежнему надежно, но вот техника с тех пор прошла не один круг модернизации. Надо ставить новую технику, к которой есть запчасти. Это тянет за собою обновление операционной системы. А это приводит к тому, что надо менять и BizTalk Server, потому что старая версия BizTalk работает только на старой версии операционной системы. Обновили сервера, обновили ОС, обновили и BizTalk.

Microsoft несколько лет назад решило, что эволюционный путь технологий неизбежно приведет к перерождению BizTalk в набор сервисов, которые сейчас значатся под общим маркетинговым именем Azure. Но этого не произошло. И не из-за недостатков Azure, а по более глубоким причинам. Главные из которых, это надежность BizTalk и консерватизм рынка. Рынок у BizTalk – это рынок больших корпораций. Интеграция для них – не метод для бурного роста, для инноваций, совсем нет. Для них это — возможность повысить эффективность основных бизнес-процессов. А эти основные процессы в больших корпорациях очень консервативные. Они и должны быть такими, потому что они должны быть надежными, надежными и еще раз надежными. К примеру,  финансовые транзакции можно пропускать только через систему, которая уже доказала свою надежность многими годами работы. 12 лет BizTalk на этом рынке, и только в последние годы корпорации начали использовать его на жизненно-важных процессах. Пройдет еще лет 5 и они начнут серьезно рассматривать Azure, если она покажет себя  надежно.

BizTalk очень часто – первая серверная система от Microsoft, которая проникает в большую корпорацию. До него там работали только мэйнфреймы, IBM, Oracle, SAP. И BizTalk играет роль тарана, пробивающего брешь в мощной и серьезной обороне. Специалисты этих корпораций убеждаются, что Microsoft, несмотря на “детские” по их масштабам цены, поставляет серверные системы со взрослыми характеристиками. За BizTalk следуют SQL Server, Windows Server. Оброна прорвана. И Microsoft начинает ощущать это с помощью хорошего датчика, своего банковского аккаунта.

Корпорациям не нужны иновации ради иноваций, им важнее гарантии, что купленная система будет стабильно развиваться и будет обеспечена поддержкой на многие годы вперед. Корпорациям не нужны не подтвердившие свою надежность и стабильность Azure, cloud (пока не подтвердившие). Им нужны от Microsoft стабильные инвестиции в BizTalk, SQL, Winsows.

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

Вот такие оптимистичные настроения навеял на меня прошедший BizTalk Summit 2012.

1 комментарий

Filed under BizTalk, Заметки, Microsoft, MVP

BizTalk: маппинг с помощью Xslt

BizTalk Map редактор (Mapper) — хороший редактор, особенно в последней 2010 версии. Но и он иногда не справляется с некоторыми видами маппинга. Когда это случается, самое время вспомнить про Xslt код. Самое время вспомнить, что maps базируются на Xslt коде и выполняются с помощью Xslt парсера.

Щелкните правой клавишей по Mapper Grid (полю между схемами) и выберите команду Properties /Custom XSLT Path.  Введите имя файла с Xslt кодом. Теперь будет выполняться только код из этого файла, забудьте про все связи и функтоиды на картинке Маппера.

Вот пример из реального проекта.

Посмотрим налево на исходную схему. В ней есть два исходных адреса (Address_1, Address_2, City, Zip). Один на верхнем уровне исходной схемы, другой на внутри записи Member_Address с параметром MaxOccurs=* (это означает, что запись может повторяться неограниченное количество раз).

Результирующий адрес расположен внутри записи Locator также с параметром MaxOccurs=*.

Map.Pict

Нам надо трансформировать все исходные структуры адреса в одну результирующую структуру.

К примеру, исходный XML документ выглядит так:

Source.Xml

Тогда результирующий XML документ должен выглядеть так:

Output.Xml

То есть один адрес верхнего уровня и два адреса нижнего уровня преобразовались в три адреса на одном и том же уровне.

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

Попробуем сделать это же с помощью Xslt кода и получим простой и однозначный маппинг:

Xslt

Просто и элегантно.

4 комментария

Filed under BizTalk, BizTalk course

BizTalk: Последовательная доставка сообщений

Это еще одно описание Последовательной Доставки сообщений [Ordered Delivery —  OD] в BizTalk Server.

Здесь английская версия. Английская версия, но уже в 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. На рисунке это сервисы находящиеся в колонке All in Parallel. Оно обрабатывает все сообщения без всякого порядка. По одному экземпляру ProcessNoOrder Orchestration будет создаваться для обработки каждого нового входящего сообщения.

Последнее — ProcessInOrder Orchestration обрабатывает все сообщения в одной последовательности.  На рисунке это сервисы находящиеся в колонке All in Order. Только один экземпляр ProcessInOrder Orchestration будет создан и все сообщения будут обрабатываться им по очереди.

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

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

В Orchestration мы можем настроить производительность системы для последовательной доставки сообщений. Это не только два режима: максимальной производительности и без всякого порядка или минимальной производительности для всех подряд сообщений. Производительность можно регулировать, задавая порядок по некоторым параметрам, группируя сообщения в отдельные очереди.

Обсуждение

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

По умолчанию все экземпляры 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: Instance Subscription and Convoys: Details статью с описанием этой проблемы.) Эта проблема может быть уменьшена, но не может быть полностью устранена. Мы ожидаем, что в новой версии BizTalk Server эта проблема будет решена.

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 и возможные пути по ее улучшению.

2 комментария

Filed under BizTalk

BizTalk: Вопросы для интервью максимальной сложности

Эта подборка вопросов — 6 часть из серии «Вопросы для интервью».

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

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

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

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

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

Оставьте комментарий

Filed under BizTalk, BizTalk course, Certification, Работа

BizTalk: Samples: ErrorHandling: Notification emails

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

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

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

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

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

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

Оставьте комментарий

Filed under BizTalk

BizTalk: Sample: Error Handling

Недавано я загрузил «BizTalk: Пример: Обработка ошибок» in 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.

Оставьте комментарий

Filed under BizTalk

файл размером в 5.99 PB

Никому ничего плохого не делаю.

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

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

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

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

Оставьте комментарий

Filed under Заметки

Работа для BizTalk developers

Рынок ИТ специальностей, а именно вакансии для BizTalk разработчиков — некоторые тенденции.

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

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

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

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

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

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

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

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

О чем все это говорит?
Во-первых, вялое, медленное утверждение BizTalk  на интеграционном пространстве дает смелость утверждать, что рынок труда будет (и есть) таким же нединамичным, консервативным. Спрос на специалистов будет (и есть) стабильным в длительной перспективе.

Во-вторых, специализация будет усиливаться. Акценты в найме смещаются просто от специалиста по BizTalk ,к примеру, к специалисту по BizTalk со знанием HIPAA 5010, специалисту со знаием RosettaNet и т.п.

2 комментария

Filed under BizTalk, Работа

BizTalk next

Интересны новые технологии, которые будут использоваться для интеграции завтра?
Уже сейчас можно приступать к их изучению.
Смотри здесь:

Microsoft Virtual Academy

Evaluation Download Center

TechNet Cloud Hub

Оставьте комментарий

Filed under BizTalk, Certification, Microsoft

BizTalk course: 10 Orchestrations

Theory:

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

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…

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

3 комментария

Filed under BizTalk, BizTalk course, Microsoft