BizTalk Server: Built-In Tracking vs. BAM vs. Custom Code

Замечание по переводу:

  • Tracking – трекинг
  • Custom Code – оригинальный код

Перед нами стоит одна и та же задача каждый раз, когда мы создаем BizTalk приложение. Как нам делать tracking, monitoring, logging, tracing?

Мы, конечно, знаем, чем различаются все эти термины. И знаем, чем они похожи друг на друга. Разные названия с похожей целью и с похожими средствами. Общее у этих терминов: мы извлекаем данные, сохраняем их, обрабатываем и предъявляем на обозрение. Требования к этой функциональности тоже похожие: все должно происходить как можно быстрее и в разработке и в работе; эти процессы не должны мешать основным процессам; изменения должны быть простыми. Стоит упомянуть, что супер-надежность – не в этом списке.

Почему это важно в BizTalk Server?

Причина такая – BizTalk перемещает очень важные данные. Если возникают проблемы в общении между системами, подозрения всегда падают на интеграционную систему. Настоящая проблема редко будет именно в интеграционной системе, в BizTalk, но он всегда будет под подозрением. Поэтому нам очень важно, чтобы данные оставляли следы. В случае проблем мы должны иметь возможность найти причины или четко предъявить доказательства невиновности BizTalk SmileА если серьезно, то в случае инцидента всегда желательно иметь возможность вернуться назад в прошлое и провести расследование.

Три альтернативы

BizTalk Tracking

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

Преимущества:

  • Установка: все необходимые трекинговые компоненты устанавливаются вместе с BizTalk, от них нельзя отказаться. Дополнительные усилия по установке равны нулю.
  • Усилия разработчика для поддержки трекинга равны нулю. Ему ничего не надо дополнительно программировать. Оператор просто включает или отключает трекинг для нужных компонент.
  • Дополнительная нагрузка на систему небольшая, но ощутимая. Разработчики BizTalk создали специальные механизмы буферизации, позволяющие трекингу не мешать основной работе. Несмотря на это, рекомендутся включать встроенный трекинг только тогда, когда он действительно нужен.

Недостатки:

  • Записывается только предопределенный набор информации. Мы не можем, к примеру, записывать не все сообщение, а только самые важные значения из этого сообщения.
  • Средства доступа записанного трекинга реализованы плохо. Форматы отчетов чрезвычайно неудобные и этих отчетов явно недостаточно.
  • Нет API для доступа к трекинговой информации. Формат баз данных нетревиальный и сложен для понимания, а описаний этого формата нет. На мой взгляд, это самый большой недостаток встроенного трекинга.

BizTalk BAM

Вот здесь я подсчитал размер разных частей BizTalk с точки зрения разработчика. На долю BAM проходится около 20% всего кода BizTalk Server, одних только SQL stored procedures около 300 штук, 90 таблиц, 10 Мбайт .NET кода. Очевидно, что архитекторы и программисты BizTalk вложили массу усилий в BAM, полагая его одной из важнейших частей системы.

Доступ к BAM осуществляется по двум сценариям. Главный сценарий я описал в этой статье.  В этом сценарии разработчик использует специальный редактор – Tracking Profile Editor и Excel. В результате получается схема того, как информация извлекается из работающих процессов, оркестрешн и портов. По этой схеме генерируется множество таблиц в базе данных, генерируются кубы в SSAS (SQL Server Analytical Service) и еще многo чего создается в SQL базах. Схемы подключатся к BizTalk приложениям, при этом в самих приложениях никакой дополнительный код не создается. В этом сценарии трекинг может включиться или отключиться, а приложение об этом ничего не знает.

Во втором сценарии используется специализированный BAM API. Разработчик должен явно вставить в нужные части приложения вызовы к BAM, записывая в базы BAM нужную информацию.

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

Обработанная в BAM трекинговая информация отражается на специальном сайте – BAM Портале. Информация там доступна в виде так называемых Pivot-table, которые предоставляют богатые возможности по группированию информации.

Что мы имеем в результате?

Преимущества:

  • Богатые возможности по извлечению информации.
  • Богатые возможности по агрегированию информации.
  • Богатые возможности по отображению информации.

Недостатки:

  • Установка: ВАМ устанавливается как дополнительный компонент BizTalk. Как правило установка BAM более сложна, чем установка всех остальных частей BizTalk. Установка BAM в много-серверной конфигурации с жесткими административными ограничениями может вылиться в очень дорогой и длительный проект.
  • Развертывание (deployment): Развертывание трекинг схем также довольно сложный процесс.
  • Дополнительные знания: Разработчику надо освоить дополнительные редакторы, надо разобраться в работе BAM, в том, как пользоваться BAM API. Я неоднократно сталкивался с безобразными реализациями, созданными разработчиками без соответствующего опыта.
  • Сложность в изменениях: Любые изменения в трекинг схемах могут привести к потере предыдущих данных. Подключение старых данных к новым – нетривиальная задача.
  • Дополнительная нагрузка на систему значительная, в основном со стороны дополнительных баз данных и SSAS.

Custom Code

Мы можем элементарно применять средства, используемые в обычных .NET приложениях. Это и стандартные .NET библиотеки, к примеру System.Diagnostics, включая Event Tracing for Windows (ETW). Это и наши любимые log4net, NLog. Это сверхбыстрые NonSQL базы данных, такие как Redis или специализированная для logging база данных InfluxDB.

Нам придется вставлять в код вызовы к соответствующим библиотекам.

Преимущества:

  • Полный контроль: Используется библиотека (библиотеки) наиболее подходящая для данных разработчиков, для данной организации, для данной инфраструктуры.
  • Простота: используются имеющиеся знания разработчиков и администраторов.
  • Дополнительная нагрузка на систему управляется. Можно, к примеру, всю дополнительную инфраструктуру, базы данных, портал отображения информации, вынести на отдельные серверы. Можно выбрать очень производительные библиотеки. Подход «только нужное и ничего лишнего» — обычно путь к хорошей производительности.
  • Поддержка: стандартные библиотеки как правило хорошо развиваются, что нельзя сказать о средствах, встроенных в BizTalk.

Недостатки:

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

Выбор лучшего метода

Абсолютно лучшего метода нет. Для разных сценариев разные методы подходят лучше или хуже. Я буду базироваться на своем одиннадцатилетнем опыте работы с BizTalk. За это время мне пришлось работать со многими реализациями трекинга. Самая лучшая реализация была сделала Йоси Даханом (Yossi Dahan). Он смог разобраться в структуре трекинг базы BizTalk и написал библиотеку для извлечения из нее данных, их обработки и презентации.

К сожалению, я не видел ни одной нормальной реализации на базе BAM (хотя я слышал о таковых). Основная проблема с такими реализациями в том, что их трудно поддерживать. Их могут делать опытные разработчики, с хорошим опытом в BizTalk и BAM, но таких очень мало. На смену им неизбежно приходят команды с минимальными или ограниченными знаниями. Результат иногда просто поражает. Со стороны администрирования все еще хуже. Несколько раз я наблюдал системы, в которых трекинг данные накапливались, но никак не отображались, так как BAM портал не могли поддерживать в работоспособном состоянии. Любое решение на базе BAM неизбежно обрастает оригинальным кодом.

BAM

Трекинг на базе BAM предпочтителен, если BizTalk приложения работают с долгоживущими процессами (long-running transactions). В этом случае важно отслеживать данные на различных этапах процессов.

Трекин на базе BAM возможен, если в вашей команде есть опытные BizTalk разработчики и администраторы. При этом вы уверены, что и в будущем они будут в вашей команде.

Иногда трекинг является не вспомогательным, а основным требованием к интеграционной системе. Представьте себе реализацию ESB или брокер, где все межсистемные коммуникации осуществляются через интеграционную систему не потому, что так быстрее или удобнее, а именно потому, что в единой интеграционной системе проще отслеживать все интеграционные процессы. Именно тогда, когда трекинг является основным смыслом интеграционной системы, BAM решает множество проблем сложного трекинга, таких как арегирование.

ВАМ обычно – самое затратное решение, он требует опытных разработчиков и администраторов и больших усилий в установке и работе.

Встроенный трекинг

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

Оригинальный код (Custom Code)

Трекинг на базе оригинального кода – это лучшее решение, если в вашей команде есть хорошие программисты на С#. Вам недостаточно хороших BizTalk разработчиков, которые отлично владеют редакторами схем, карт, оркестрейшн и немножко владеют C#. Вам нужны именно хорошие C#, .NET программисты. К счастью таких программистов намного больше, чем BizTalk разработчиков, поэтому оригинальный код – достаточно распространенный и удачный подход.

Вы должны понимать, что при изменениях в трекинге, вам придется менять код, что влечет за собою перекомпиляцию и переустановку приложений. Что, в свою очередь, требует развитой continuous integration в BizTalk разработке. То есть вам нужны стабильные и быстрые процессы обновления кода на работающих системах. Что, конечно, является признаком зрелой интеграции.

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

Filed under BizTalk, Integration Architecture

2 responses to “BizTalk Server: Built-In Tracking vs. BAM vs. Custom Code

  1. I think a consideration needs to also include how the features will be implemented — Synchronous vs Asynchronous. One of the benefits of using BAM is that you can do so in an Async manner that prevents blocking. If a developer is going to build a solution, it should not get in the way of BizTalk processing messages and subsequently be async

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s