Интеграционный адаптер что это
Как интегрировать Эквио с сервисами компании?
Эквио — платформа с открытым интеграционным API (Application programming interface). Это значит, что Заказчик может интегрировать нашу LMS в свою IT‑инфраструктуру собственными силами. Можно импортировать данные в Эквио или, наоборот, экспортировать их из платформы во внутренние системы. Например, можно автоматически добавлять и блокировать пользователей, показывать KPI и т.д.
Кроме того, можно заказать интеграцию платформы со сторонними сервисами у наших специалистов.
Что можно импортировать в Эквио
Вот так видит данные сотрудников администратор на платформе Эквио
Чтобы правильно распределять доступ к обучающему контенту между сотрудниками, платформа позволяет присвоить пользователям значения специальных атрибутов — групп. Стандартные названия этих групп: регион и город проживания, должность, департамент, роль, команда и т.д. Названия групп могут быть переименованы, чтобы более полно отражать специфику кадрового учёта. Значения этих групп для каждого пользователя также могут быть импортированы из HR-системы Заказчика. Обязательно учитывается статус пользователя (уволен/активен).
KPI, который компания рассчитывает по каждому сотруднику, можно также импортировать на платформу Эквио. Это поможет лучше оценивать эффективность обучения и мотивировать пользователей.
Для документационного обеспечения участия сотрудников и партнёров в бонусной программе, можно организовать процесс заполнения анкеты, загрузку скан-копий необходимых документов в Эквио. При помощи интеграции можно экспортировать из Эквио результаты заполнения анкеты и скан-копии документов в систему Заказчика. После проверки анкеты во внешней системе в Эквио можно импортировать результаты проверки анкет. В этом случае в Эквио загрузятся данные о статусе проверки, даты заполнения и проверки анкеты, комментарий HR.
Так руководитель компании может быть уверен, что учёл все достижения сотрудников, а не только их активность на платформе Эквио.
В Эквио сотрудники копят бонусные баллы, часть которых можно начислять из других ресурсов и систем
Как мы интегрируем Эквио со сторонними сервисами
Мы уже писали, что интеграция с сервисами компании возможна благодаря открытому API платформы Эквио. Расскажем, как конкретно происходит обмен данными. Для этого разработчики платформы Эквио используют интеграционные адаптеры и интеграционное API.
Интеграционные адаптеры
Адаптер — это консольное приложение, запускаемое на регулярной основе (например, ежедневно). Он позволяет учесть специфику способа (файл на SFTP-сервере, витрина данных, веб-сервис и др.) и формата предоставления или получения данных (набор полей) на стороне Заказчика, а также реализовать специфическую логику преобразования данных, необходимую Заказчику. Наши разработчики создают адаптеры индивидуально с учётом специфики систем клиента.
Вот как это выглядит:
Интеграционный адаптер Эквио
У нас есть шаблонные ТЗ с описанием типовых сценариев интеграции нашей платформы. Стандартный функционал включает импорт пользователей, KPI, экспорт статистики. По желанию Заказчика мы можем доработать их, добавив дополнительные функции. После согласования формата и способа выгрузки данных, разработчики приступают к созданию механизма экспорта. Время разработки составляет примерно 30 часов на 1 стандартный адаптер.
Преимущества интеграционного адаптера в том, что Заказчику не нужно вникать в особенности нашего API. Это дополнительный сервис для наших клиентов, отлично подходящий для компаний без IT-экспертизы в области HR-систем.
Приведём несколько примеров успешных интеграций с помощью адаптера.
Другой вариант интеграции Эквио со сторонними приложениями — интеграционное API. Поскольку все работы здесь выполняет Заказчик, доступ к API входит в общую стоимость пользования платформой. Мы бесплатно предоставляем интеграционный токен, а разработчики клиента создают собственную логику импорта/экспорта данных и автоматизируют процесс обмена данными между Эквио и IT-системами компании.
Схема API интеграции выглядит так:
Интеграционное API Эквио
Интеграцию проводят в соответствии со спецификацией OpenAPI 3.0. Документация в формате Swagger находятся в открытом доступе.
Плюсы такого решения — возможность для Заказчика самостоятельно разработать логику переноса данных в/из Эквио. Это удобно для компаний, в штате которых есть соответствующие ИТ-специалисты.
Напоследок приведём пример использования интеграционного API одним из наших заказчиков. Стояла задача перенести пользователей из 1С в Эквио. Компания разработала механизм экспорта сведений, который раз в сутки обновлял профили пользователей, добавлял новых сотрудников и удалял неактуальные аккаунты.
Эквио поддерживает передачу авторизации внешним серверам
Это позволяет использовать уже существующие учётные записи пользователей и реализовать SSO (Single Sign-on, возможность однократного входа в систему при использовании нескольких приложений). Если у заказчика есть другие приложения, авторизующиеся при помощи сервера авторизации, в них можно добавлять ссылки на ресурсы Эквио, по которым будет возможен бесшовный переход (переход без повторной авторизации).
Что можно экспортировать из Эквио
Вот так выглядят данные о прохождении обучающего курса на платформе Эквио
Это был краткий обзор возможностей интеграции платформы Эквио со сторонними сервисами. Советуем также посмотреть наши статьи: Настройки авторизации и верификации и Архитектура и хранение данных.
Интеграционный адаптер
Как понять, нужен ли вам интеграционный адаптер?
Вам необходимо интегрировать 3 и более приложения/сервиса по нескольким объектам интеграции;
В будущем вам понадобится подключить большее число приложений;
Вы используете более одного типа коммуникационного протокола;
Вам требуется разветвление или слияние потоков информации либо контент-зависимая маршрутизация;
Вам требуется гарантированная доставка данных вне зависимости от временной неработоспособности отправителей и получателей информации;
IT-инфраструктура большинства организаций обычно складывается годами и даже десятилетиями. За это время автоматизируются всевозможные бизнес-процессы с использованием разных информационных систем: ERP для учёта, ECM для автоматизации документооборота, CRM для взаимодействия с клиентами, HRM для кадровиков, PLM/PDM системы для управления жизненным циклом продукции.
Все эти системы между собой каким-либо образом интегрированы, поэтому для бизнес-процессов компании необходимо, чтобы эти системы взаимодействовали и обменивались данными. В большинстве случаев архитектура интеграции информационных систем строится по принципу «каждый с каждым» и выглядит следующим образом:
Такая архитектура, уже изначально малоэффективная, со временем, в результате изменения процессов и внедрения новых систем и технологий, становится совершенно неподдерживаемой:
количество связей между различными системами и их сложность растут в геометрической прогрессии, а настройки обмена данными оказываются расконцентрированными по различным местам;
возникает двойной ввод данных;
разночтения в нормативно-справочной информации;
замена или доработка какой-либо системы ведет к полной переработке всех интеграционных механизмов;
отсутствует возможность эффективного контроля и аналитики, а также многие другие проблемы.
В итоге замедляются процессы и возникают ошибки в оперативных, тактических и стратегических решениях.
Для построения распределенного корпоративного информационного ландшафта, нами было разработано интеграционное решение TANAIS.Adapter, который обеспечивает надежный обмен сообщениями между системами на основе сервис-ориентированной архитектуры.
TANAIS.Adapter выступает в роли платформы, которая выстраивает общение между системами, используя набор плагинов.
Обмен сообщениями/данными между приложениями и информационными системами;
Трансформацию данных для передачи в соответствующем формате в другую систему;
Приоритизацию сообщений обмена в соответствии с заданными алгоритмами;
Гарантированную доставку сообщений в системы приемники;
Обеспечение безопасности данных;
Синхронизацию справочной информации между различными приложениями и информационными системами;
Организацию единой точки доступа к данным;
Унификацию взаимодействия с внешними информационными системами;
Мониторинг передаваемых данных;
Снижение трудоемкости процесса сбора и агрегации информации;
Повышение оперативности подготовки отчетов;
Интеграционные плагины – отвечают за получение/передачу информации между разными системами;
Трансформационные плагины – отвечают за трансформацию передаваемых данных. Каждая система передает платформе информацию в своем формате. Если платформа видит, что в другую систему данные должны поступать в другом формате, она вызывает трансформационный плагин, который преобразует данные и возвращает их платформе в необходимом формате;
Для взаимодействия с внешними сервисами – отвечают за обмен информацией с внешними сервисами, например проверка контрагентов;
Для мобильной платформы – позволяют использовать одно мобильное приложение для работы со всеми корпоративными информационными системами;
Для торговых площадок – позволяют автоматизировать взаимодействие с ЕИС и различными ЭТП.
Корпоративный ландшафт после внедрения интеграционного адаптера выглядит следующим образом:
Управление интеграционными процессами при такой архитектуре значительно проще и позволяет гарантировать, что интеграционное сообщение не будет потеряно и все данные будут доставлены от источников адресатам. Помимо этого, значительно возрастает скорость обработки информации, поскольку все процессы протекают в плагинах. Их использование значительно упрощает архитектуру интеграционной платформы.
Возможности
TANAIS.Adapter предоставляет следующие возможности:
Всего существует четыре режима, в которых работает интеграционный адаптер:
Архитектура интеграционного адаптера
На рисунке ниже представлена архитектура интеграционного адаптера, составляющими частями которого являются:
Веб-сервис, обеспечивающий получение и отправку интеграционных сообщений из и во внешние системы;
Очередь интеграционных сообщений, обеспечивающая хранение сообщений;
Обработчик очереди, осуществляющий выемку сообщений из очереди и их передачу плагинам трансформации и интеграции;
Всего существует четыре режима, в которых работает интеграционный адаптер:
Режим реального времени (Real-time)
В данном режиме задается расписание, по которому интеграционный адаптер (ИА) подключается к системам-источникам (СИ), забирает данные, ставит их в очередь сообщений и, подключаясь к системам-приемникам (СП), обеспечивает доставку этих сообщений.
Система-источник передает сообщение ИА, указывая тип источника события. ИА определяет каким системам-приемникам необходимо осуществить доставку данного сообщения, ставит в очередь сообщения для каждой из систем-приемников. Системы-приемники подключаются к ИА и забирают имеющиеся для них сообщения.
Система-источник подает сообщение в ИА, указывая тип источника события. ИА определяет каким системам-приемникам необходимо осуществить доставку данного сообщения, ставит их в очередь сообщений и, подключаясь к системам-приемникам, доставляет сообщение.
Режим реального времени
Система-источник подключается к ИА с запросом данных, указывая код источника события, и ожидает ответа от ИА. Ожидание ответа от ИА продолжается либо до его получения, либо до истечения таймаута ожидания. Очереди сообщений при данном взаимодействии не используются.
5 типов плагинов
Работа Интеграционного адаптера строится на использовании 5 типов плагинов, которые могут быть задействованы во всех четырех режимах.
Интеграционные плагины позволяют передавать данные из одной системы в другую. Их можно назвать основообразующими плагинами платформы. Благодаря им мы можем связывать между собой абсолютно любые системы.
Трансформационные плагины снимают необходимость задумываться, в каком формате мы отправляем документ из одной системы в другую. Если платформа видит, что в другую систему данные должны поступать в формате, отличающемся от текущего, она вызывает трансформационный плагин, который преобразует данные и возвращает их в очередь документов на передачу другой системе.
Помимо обмена информацией между внутренними информационными системами, благодаря этим плагинам Интеграционный адаптер может выстраивать обмен информацией с внешними сервисами. Так, например, проверку контрагента можно будет провести не выходя из системы, в которой вы работаете.
При использовании Интеграционного адаптера в сочетании с мобильной платформой вам больше не надо будет запускать отдельные приложения для ваших корпоративных информационных систем. Достаточно запустить одно приложение, которое позволит работать со всеми системами, которые используются на предприятии и к которым у вас есть доступ.
Взаимодействие с электронными торговыми площадками формируют пятый тип плагинов. Они позволяют автоматизировать взаимодействие с различными ЭТП и с ЕИС. Эти плагины необходимы при автоматизации закупочной деятельности и особенно актуальны для компаний, которые проводят закупки по 223-ФЗ и 44-ФЗ.
Настройка интеграции
Настройка вариантов обмена данными осуществляется через WEB-интерфейс. Важным отличием нашего решения от других интеграционных шин является то, что в нём можно задавать маршрутизацию пакетов и задавать отношения между системами.
В интеграционном адаптере (TANAIS.Adapter) настраивается взаимоотношение между системами (источник или приемник), типы этих взаимоотношений (активное или пассивное) и определяется, требуется ли трансформация сообщения перед передачей его в систему приемник. Таким образом, система Источник отправляет одно единственное сообщение в ИА, а он уже занимается пассивной или активной доставкой до систем приемников.
В качестве базы данных для интеграционного адаптера используется Microsoft SQL Server.
Формат обмена данными
При использовании трансформационных плагинов части КИС отправляют информацию в привычном им формате.
Однако, если вы не хотите использовать трансформационные плагины, тогда через Интеграционный адаптер все части КИС общаются между собой посредством XML-файлов. Так, например, тот же новый контрагент, если он создается в управленческой системе, то данные о нём выгружаются в адаптер и забираются оттуда всеми системами, которым нужна информация о контрагенте (СЭД, бухгалтерия, сайт). Пример формата данных для обмена записями о контрагентах выглядит следующим образом:
Бизнес-эффект
Использование TANAIS.Adapter позволяет максимально эффективно использовать программное обеспечение существующее на предприятии. Автоматизированный подход требует гораздо меньше времени и других ресурсов, снижает затраты на обучение персонала и обеспечивает высокую скорость обмена информацией. Подобный эффект достигается за счет следующих факторов:
Все общение между ИТ-системами получается унифицированным
Единое информационное пространство;
Масштабируемую архитектуру управления уровня предприятия/холдинга;
Систему обмена данными на транспортном уровне и на уровне бизнес-логики;
Унификация взаимодействия различных информационных систем;
Возможность делегировать задачи построения информационных потоков аналитическим отделам;
Общее упрощение интеграционной схемы и снижение требования к пропускной способности каналов;
Увеличение общей стабильности транспортного уровня передачи данных;
Снижение транзакционных издержек при обмене данными между различными подразделениями;
Снижение общих затрат на обслуживание и сопровождение информационной системы.
Брокер интеграции приложений
Типичная вычислительная инфраструктура предприятий характеризуется фактической изолированностью составляющих ее приложений, что с точки зрения бизнеса ведет к задержкам выполнения деловых процессов, нарушению взаимодействия между подразделениями, препятствует управлению и контролю, приводя к снижению эффективности работы организации в целом. В общем случае, отсутствие интегрированности ставит под вопрос полезность ИТ для бизнеса. Статья посвящена разбору предлагаемых компанией IBM технологий интеграции приложений, призванных решить проблему изолированности.
Технических подходов к решению задачи интеграции немало, однако нельзя забывать, что задачу эту приходится решать на уникальном организме вычислительной среды конкретного предприятия. Различные подходы можно разделить на несколько групп.
Прежде всего, отметим кардинальный подход, требующий полной замены существующих систем. Это позволяет заранее предусмотреть и заложить взаимосвязи между отдельными компонентами уже на этапе проектирования. Однако за достоинства новой технологии придется расплачиваться потерей уже сделанных наработок, людских и материальных инвестиций. Типичные примеры подобного подхода — интеграция на базе комплексной системы ERP или на базе «домашней» разработки с использованием объектной технологии. Кроме неизбежных потерь и трудностей переходного периода принцип полной замены не решает проблем интеграции для будущих усовершенствований: новая система, как правило, не покрывает всю прикладную функциональность, которая может потребоваться предприятию, — следовательно, проблема интеграции остается.
Второй подход, связанный с переделкой механизмов доступа к старым системам при помощи новых интерфейсов, предусматривает написание различного рода обертывающих и представляющих программ. Подход этот более экономичный, поскольку позволяет сохранить существующие системы. Но в то же время он позволяет реализовывать достаточно ограниченные сценарии взаимодействия между системами.
Наконец, более глубокий интеграционный подход должен обеспечить взаимодействие систем для различных сценариев, выстраивание сложных процессов передачи данных и управления между участниками с обеспечением реакции на различные типы событий. Гибкое интеграционное решение должно быть открытым для будущих изменений.
Типичные интеграционные задачи
Интеграционные проекты всегда уникальны, однако можно указать типичные задачи: синхронизация данных, работа составных приложений и сквозные бизнес-процессы.
Большинство современных корпоративных приложений используют реляционные базы, как основу для хранения и доступа к прикладным и системным данным. Поэтому неудивительно, что часто под интеграцией понимают обмен данными между базами, и целью интеграции ставится синхронизация источников данных, с которыми работают различные приложения. Cинхронизация данных означает отсутствие взаимодействия прикладных процессов и компонентов различных систем, вместо него имеет место взаимодействие компонентов хранения данных.
Работа составного приложения подразумевает взаимодействие процессов, исполняющихся в различных системах, позволяющее приложению реагировать на события, произошедшие в другой системе. Сценарий такого взаимодействия может варьироваться от достаточно простого до весьма сложного. Для целостной реализации распределенного делового процесса, охватывающего несколько систем, уже недостаточно простой «соединительной» функциональности. Интеграционное решение должно также отслеживать сложную логику взаимодействия систем, использовать определенные исполнительные и контролирующие правила. В то же время интеграционные задачи могут очень сильно различаться по своим характеристикам: временным, транзакционным, объемным. Скажем, пакетное перемещение данных, происходящее редко, налагает иные требования, чем перемещения, выполняемые в режиме близкого к реальному времени. Транзакционные перемещения и взаимодействия требуют, в свою очередь, поддержки дополнительных интеграционных механизмов.
Разнообразие условий привело к значительному разнообразию в реализациях программных решений интеграции, однако со временем выработалась типичная функциональность и архитектура.
Компоненты и топология интеграции
Среди основных компонентов реализации топологии интеграции можно выделить: транспортную инфраструктуру, проложенную между приложениями; адаптеры и коннекторы, привязывающие прикладные системы к транспортной инфраструктуре; интеграционный сервер, берущий на себя разнообразную обработку и исполнение вычислительных процедур и процессов, связанных с интеграцией.
Транспортная среда должна обеспечивать более высокую надежность передачи данных между приложениями и большую гибкость для различных сценариев взаимодействия по сравнению со стандартными сетевыми службами. Для некоторых интеграционных задач транспортная среда должна обеспечивать транзакционный режим передачи. Кроме того, для интеграционной транспортной среды необходим еще целый ряд функций, например, система подтверждений доставки информации, передача в соответствии с приоритетами и др.
Топология интеграционного решения отражает различные способы соединения взаимодействующих приложений и интеграционных компонентов. Среди основных топологий выделяются соединения типа «точка-точка», шлюзы и шины (рис. 1).
 |
| Рис. 1. Различные архитектуры интеграции |
Соединение «точка-точка» означает, что интегрируемые приложения устанавливают прямые соединения друг с другом. Простота метода осложняется необходимостью для взаимодействующих приложений, во-первых, знать точную адресную информацию о партнере и, во-вторых, уметь осуществлять преобразования между форматами данных используемых партнерами. Интеграция данного типа часто означает разработку дополнительного и изменение существующего программного кода как минимум для одного, а чаще для обоих взаимодействующих приложений.
Использование адаптеров и коннекторов обеспечивает преобразование специфических интерфейсов и данных конкретного приложения в интерфейсы и данные стандартной интеграционной среды (например, данные из таблиц реляционной базы данных в сообщения транспортной инфраструктуры). Прикладные программные интерфейсы API позволяют встроить в приложения код, позволяющий работать с транспортной инфраструктурой. Настройка интерфейсов, адресной информации и процедур трансформации, применяемых в адаптерах вместо написания кода, позволяет ускорить внедрение интеграционного решения. Типичные примеры — адаптеры для подсоединения известных прикладных систем, таких как SAP R/3 и Siebel, технологические адаптеры, позволяющие работать с базами данных DB2, Oracle, Microsoft SQL Server, плоскими файлами, системами электронной почты, наконец, адаптеры для специализированных сетей передачи деловой информации EDIFACT, ACORD, SWIFT, RosettaNet.
Следующий важный компонент интеграционной среды — интеграционный сервер, шлюз или интеграционный брокер, возникающий как центральный узел обращения интегрируемых систем и приложений. Через него направляются потоки сообщений и данных с этих систем; он перераспределяет, обрабатывает и направляет эти потоки. Использование интеграционного сервера позволяет возложить на него функции адресации и трансформации передаваемых данных, причем гораздо более сложные, чем в случае прямого соединения или использования адаптеров. Централизованное исполнение функций обработки передаваемой информации и данных также означает использование общего репозитория для корпоративных интеграционных правил. Правила из общего репозитория обозримы и прозрачны для разработчиков и системных администраторов, могут дополняться и изменяться при изменении деловых процессов и состава вычислительной среды, что позволяет эффективно соединять и динамически управлять интеграционным решением.
Стандартное интеграционное решение от IBM базируется на транспортном слое системы очередей сообщений WebSphere MQ, многочисленных адаптерах WebSphere BusinessIntegration Adapters и интеграционном брокере WebSphere MQ Integrator [1].
Транспортный базис интеграционного решения
Благодаря простоте, надежности и универсальности программное обеспечение систем очередей сообщений является одной из самых перспективных технологий интеграции. Системы очередей сообщений предоставляют асинхронный метод взаимодействия для прикладных программ. Приложения обмениваются данными, посылая и принимая их в виде сообщений. При этом приложения не взаимодействуют друг с другом напрямую, а обращаются к службе очередей сообщений и при помощи API получают доступ к очередям и сообщениям. Очереди представляют собой промежуточное место хранения сообщений, своего рода специализированную базу данных с механизмами, гарантирующими сохранность данных: журналирование, восстановление после сбоев, обработка транзакций.
В распределенной среде за передачу сообщений между системами отвечают сетевые компоненты системы очередей сообщений. Так, WebSphere MQ использует каналы передачи сообщений, обеспечивающие гарантированную передачу сообщений поверх разнообразных сетевых соединений. При использовании протокола гарантированной передачи посылаемое сообщение не будет удалено из очереди на сервере посылки до тех пор, пока оно не будет полностью принято на сервере-адресате — при передаче сообщений реализуется сетевая транзакция.
Среди преимуществ системы очередей сообщений можно отметить многообразие сценариев взаимодействия программ — от простой рассылки информации адресатам до поддержки контентной адресации в модели «публикация-подписка» и сложных распределенных и распараллеленных вычислительных процессов. Кроме того, существование дополнительного звена в виде очередей сообщений позволяет вставлять промежуточную обработку передаваемой информации для решения различных задач: обеспечение безопасности и совместимости форматов, динамической маршрутизации, анализа контента и т.д.
Интеграционные адаптеры
Адаптеры играют роль связующих мостиков между прикладными системами, с одной стороны, и транспортной средой вместе с брокером интеграции, с другой (рис. 3). Обычно адаптер выступает как постоянно работающий процесс, отслеживающий наступления различных событий в прикладной системе и транспортной среде. Адаптер поддерживает два основных сценария:
Адаптеры также могут поддерживать функции трансформации и преобразования данных, посылаемых между системами (правда, обычно более простые, чем интеграционный брокер). В зависимости от реализации поведение адаптера может быть статическим или позволять динамические изменения, управляемые происходящими событиями.
Интеграционный брокер
Интеграционные брокеры (рис.4) обеспечивают взаимодействие приложений через центральный промежуточный шлюз, поддерживающий интеллектуальную обработку и распределение данных между приложениями. Роль брокера в интеграционной среде, основанной на передаче сообщений, — это роль почтамта, сортирующего и регистрирующего почтовые отправления, проверяющего адресную информацию и распределяющего их для дальнейшей отправки адресатам.
 |
| Рис. 4. Интеграционный брокер |
Брокер возникает как промежуточный сервер в интеграционной транспортной среде и занимается обработкой потоков сообщений и передаваемых данных, а также исполнением вызовов и обращения по различным интерфейсам. Брокер перераспределяет, обрабатывает и направляет потоки информации, данных и сообщений между интегрируемыми системами.
Преобразование форматов данных
Передаваемые между системами данные могут иметь различную структуру, оформленную в самых разных форматах. На практике встречаются открытые стандартизованные форматы (например, XML), специфические для конкретной отрасли форматы (EDI или SWIFT), относящиеся к конкретной прикладной системе (SAP R/3) или уникальные форматы, разработанные для конкретного приложения. Брокер должен обеспечить совместимость форматов для всех участвующих в обмене сторон и уметь оперировать данными в форматах самых разных типов.
Маршрутизация информации и данных
Передача информации от одного приложения к другому может базироваться на методе прямой адресации, когда посылающее приложение явно знает и указывает своего корреспондента. Однако приложение в конечной точке этого может и не знать: реальная адресная информация может меняться, когда системы становятся активными или выбывают из эксплуатации либо адресная информация отсутствует по причинам обеспечения безопасности. Могут быть также случаи, когда адресная информация должна быть определена из содержания передаваемого сообщения или получена из внешних данных в момент обработки. В таких ситуациях брокер может выступать интеллектуальным маршрутизатором, анализируя адресную, контекстную и прикладную часть информации и используя бизнес-правила из репозитория, он распределяет данные по адресатам.
Подход, противоположный прямой адресации, — распределение информации на основании динамических запросов от приложений-пользователей информации. Технология сообщений позволяет эффективно реализовать модель публикация-подписка. Интеграционный брокер принимает заявки-подписки на информацию по темам от приложений-подписчиков и тематические сообщения-публикации от приложений-публикаторов. Брокер распределяет публикации по подписчикам на основании совпадения тематик и содержания, что является гибким динамическим механизмом адресации информации.
Взаимодействие с базами данных и другими системами
Обмен данными, обобщенно говоря, между внешней динамической транспортной системой и средой внутренних данных прикладных систем является наиболее часто повторяющимся действием. Подобный обмен должен быть реализован на общих для обеих сред языковых и интерфейсных средствах; необходима поддержка стандартов SQL, ODBC, XML. Правда, надо заметить, что серверы баз данных имеют собственные специальные средства для сбора, передачи и загрузки данных, а также средства репликации данных. В отличие от интеграционных брокеров инструменты СУБД ориентированы на работу только с базами данных. Если сравнивать возможности средств интеграционного брокера и средств сервера баз данных, то брокеры часто имеют более ограниченные возможности в использовании всех механизмов СУБД, в частности, в использовании групповых операций и в поддержке целостности модели данных. В то же время брокеры сообщений предоставляют более надежные транспортные механизмы, гибкую маршрутизацию и систему обработки и реакции на события.
Средства разработки, производительность и масштабируемость
Универсальный интеграционный брокер должен позволять создавать и выполнять произвольные процедуры обработки. Средства разработки таких процедур должны быть естественны и эффективны в освоении и использовании, предоставлять возможности групповой работы, поддерживать открытость и прозрачность кода процедур для повторного использования и внесения изменений.
Масштабы интеграционной задачи могут потребовать от брокера высокой пропускной способности, особенно если предположить, что потоки данных с нескольких интенсивно работающих систем должны пересекаться на брокере. Брокер должен обладать высокопроизводительным обрабатывающим ядром с возможностью масштабирования на различном оборудовании.
Архитектура WebSphere MQ Integrator
За свою историю данный программный продукт имел версии с разными именами: MQSeries Integrator [2], MQ Integrator, MQ Integation Broker, MQ Message Broker. Основные компоненты WebSphere MQ Integrator: система исполнительных брокеров, сервер конфигурации Configuration Manager и универсальная графическая среда разработки и администрирования ControlCenter (рис. 5). Брокеры, отвечающие за исполнение потоков обработки, являются исполнительной средой. Каждый брокер имеет собственную базу данных, хранящую часть данных главного репозитория. Многопроцессная и многопоточная архитектура ядра брокера обеспечивает масштабируемость. Служба форматирования сообщений позволяет брокеру разбирать сообщения на отдельные поля и оперировать с сообщениями как со сложно структурированными документами.
Сервер конфигурации — центральный компонент, управляющий ведением репозитория форматов и бизнес-правил, а также текущей работой брокеров. Взаимодействие между отдельными компонентами WebSphere MQ Integrator базируется на очередях WebSphere MQ. Все команды и запросы, идущие от ControlCenter на сервер конфигурации, реализуются в виде сообщений. Сам сервер конфигурации и брокеры связаны при помощи очередей сообщений WebSphere MQ, через которые передаются внутренние управляющие и отчетные сообщения WebSphere MQ Integrator в формате XML.
Поток обработки сообщения и его визуальное конструирование
Обработка сообщения, попавшего в брокер, определяется потоком обработки сообщения (message flow), представляющим собой направленный граф. Его узлы — это отдельные шаги или процедуры обработки, а ребра — пути сообщений в потоке между отдельными стадиями обработки (рис. 6). Фактически логическое представление процесса обработки данных и перехода контроля между стадиями обработки совпадет с физическим процессом внутренней трансформации сообщения на стадиях обработки. Поток обработки состоит из последовательности операций над сообщением и конструируется при помощи набора существующих стандартных обработчиков. Обработчики WebSphere MQ Integrator — это параметрически настраиваемые процедуры, реализующие отдельный шаг или специализированную функцию процесса обработки. В свойствах процедур-обработчиков определяются параметры, необходимые для исполнения данного потока. Скажем, если обработчик читает сообщения из очереди WebSphere MQ, то в качестве параметра определяется имя очереди. Если другой обработчик предназначен для обращения к внешней базе данных, то среди его параметров будут названия базы, таблиц и полей. Обработчики имеют точки входа и выхода — так называемые «терминалы». Входные и выходные терминалы обработчиков связываются соединениями, образуя направленный граф, который реализует пошаговую последовательность обработки сообщения.
 |
| Рис. 6. Пример потока обработки сообщений |
Поток обработки стандартно начинается с получения сообщения из очереди через входной обработчик (Input) и заканчивается рассылкой сообщений другим системам через один или несколько выходных обработчиков (Output), записью в базу данных, или публикацией сообщения для группы подписчиков по совпадению темы или просто уничтожением присланного сообщения. Чаще всего для связи с внешними системами используется транспорт WebSphere MQ, а входная очередь является сборным ящиком для приема информации в виде сообщений, поступающих извне. В других случаях процедура обработки может стартовать при получении данных с телеметрических устройств через протокол SCADA, с мобильных устройств при помощи MQSeries Everyplace или начинаться с запуска произвольного входного обработчика собственного написания. Важной задачей на стадии приема сообщения через входной обработчик Input, кроме чтения пришедшего сообщения из очереди, является правильная интерпретация его содержимого, отнесения к соответствующему домену, разбор сообщения в соответствии с типом и форматом на отдельные поля. При этом, для различных доменов сообщений (например, XML или SAP Idoc) существуют различные компоненты анализа и разборки структуры сообщения — парсеры, которые используются входным обработчиком. Среди параметров, определяющих поведение потока обработки и отдельных обработчиков, содержатся важнейшие определения о транзакционности данного потока обработки, о постоянстве или непостоянстве создаваемого сообщения, способе передачи контекста и идентификационной информации из исходного сообщения в новые сообщения, создаваемые в процессе обработки.
Целая группа обработчиков служит для маршрутизации и ветвления процесса обработки. Другие обработчики предназначены для реализации различных синтаксических и семантических проверок. Например, обработчик фильтра разделяет поток на отдельные ветви в зависимости от условия фильтрации. Условные переходы с динамическими и статическими назначениями внутри потока обеспечиваются обработчиками RouteToLabel и Label. Для реакции на возникающие ошибки и обработку исключительных состояний существуют обработчики TryCatch и Throw. Трассировка и проверка корректности потока и структуры проходящих сообщений осуществляются соответственно обработчиками Trace и Check, а обработчик FlowOrder определяет порядок прохождения отдельных ветвей потока обработки. Для взаимодействия с базами данных существуют специализированные обработчики, позволяющие визуально назначать связи и преобразования между полями базы данных и полями сообщения. Наиболее часто используемым и универсальным по возможностям является обработчик Compute, позволяющий писать разнообразные программы-скрипты на языке ESQL, расширении SQL3 [3].
Домены сообщений
На стадии первичной обработки любого сообщения, попавшего в WebSphere MQ Integrator, происходит его отнесение нужному домену (XML, JMS, MRM, NEON, BLOB) и разбор на отдельные поля. Некоторые типы сообщений WebSphere MQ Integrator умеет распознавать и обрабатывать динамически без использования предварительно занесенных в репозиторий метаданных, например, динамически происходит обработка так называемых «хорошо определенных» XML-документов. Для других типов XML-документов требуется предварительное занесение структуры в репозиторий, например, путем экспорта DTD документа. Среди доменов особо выделяется MRM (Message Repository Manager), являющийся основным репозиторием. MRM-сообщения могут иметь произвольную и очень сложную структуру; инструментальные средства брокера позволяют разрабатывать новые MRM-форматы.
Сообщения, созданные приложениями при помощи интерфейса JMS, могут относиться к нескольким типам языка Java: текст, потоки, карты и объекты Java. Опционально WebSphere MQ Integrator включает технологию разбора и обработки сообщений, лицензированную у компании NEON. Наконец, содержание неструктурированных сообщений и сообщений с неизвестной структурой трактуются как большие бинарные объекты и относятся к домену BLOB.
Остановимся на том, как WebSphere MQ Integrator определяет, к какому домену относится пришедшее сообщение. Информация о домене сообщения и сопутствующих параметрах формата может содержаться в самом сообщении или определяться информацией, хранящейся в репозитории MQ Integrator. В первом случае для определения формата сообщения используются поля стандартного заголовка и специализированные подзаголовки сообщений WebSphere MQ (например, подзаголовок MQRFH2, имеющий поля для определения набора, типа и формата сообщения). При использовании второго подхода в репозитории хранятся настройки потока обработки, параметры входного обработчика Input, позволяющие назначать домен, формат и тип для сообщений, которые будут попадать во входную очередь.
На этапе обработки брокер использует собственное внутреннее сообщение, созданное путем дополнения содержания оригинального служебной информацией, содержащей данные об исключительных состояниях, переменных окружения и адресатах назначения. Это сообщение используется процедурами-обработчиками и позволяет гибко управлять исполнением потока обработки на каждом его шаге.
Язык работы с сообщениями
Язык скриптов ESQL, развивающий широко используемый процедурный язык SQL3, дополнен средствами манипулирования сообщениями разнообразных форматов. ESQL используется в трех основных обработчиках — Compute, Filter, Database — и позволяет изменять содержание и служебные данные входного сообщения, создавать новые сообщения и обновлять внешние базы данных. Важной особенностью ESQL, отличающей его от SQL3, являются ссылочные конструкции, позволяющие адресовать отдельные поля и элементы в структурированном дереве сообщения, использовать разные методы для выделения отдельные группы элементов и методы навигации по дереву сообщения.
Администрирование брокера
Для поддержки жизнедеятельности брокера требуются разнообразные инструменты, начиная со средств разработки новых форматов и процедур обработки (в том числе, средств тестирования и отладки) и заканчивая средствами администрирования и мониторинга повседневной работы брокера и диагностики проблем. В WebSphere MQ Integrator используется интегрированная среда управления, являющаяся универсальным инструментарием и для разработчика, и для администратора. В среду управления входят компоненты, объединенные общей графической оболочкой и поддерживающие весь цикл работы брокера: определение форматов сообщений; разработка процедур обработки; режим тестирования; назначение разработанных процедур на исполнение конкретному брокеру; динамическое распространение изменений на уже работающие процедуры; определение общей топологии среды распределенных брокеров; мониторинг состояния действующих брокеров и потоков обработки; журналирование административных операций.
Расширение функциональности
WebSphere MQ Integrator можно расширить путем добавления новых обработчиков для программирования типичных функций. При этом предусмотрен стандартный инструментарий, позволяющий создавать новые разработчики на языках Cи и Java. Кроме того, доступны многочисленные дополнительные обработчики, разработанные партнерами, заказчиками и специалистами IBM, например, обработчики для посылки электронной почты, или посылки-приема файлов по FTP, выполнения XSLT преобразований и др. Внутренняя функциональность брокера может быть дополнена путем встраивания парсеров для работы со специализированными форматами сообщений. Репозиторий брокера позволяет работать с сообщениями практически любой сложности, однако использование специализированного парсера может оказаться более эффективным. Примером специализированного парсера могут служить компоненты для работы с документами SAP Idoc системы R/3.
Взаимодействие с системами workflow
Системы workflow позволяют отделять среду моделирования, среду управления и контроля за исполнением деловых процессов от внутренней закодированной логики прикладных систем, что позволяет гибко изменять деловые процессы в соответствии с изменениями и развитием бизнеса. Такие системы рассчитаны на исполнения процессов с долгим временем жизни, остановками и возобновлением процесса, участием людей-пользователей и приложений-автоматов. Интеграционные брокеры больше ориентированны на автоматическую обработку сообщений и документов с коротким временем исполнения.
Системы workflow и брокеры сообщений дополняют друг друга, соединяя функции управления бизнес-процессами с функциями трансформации и распределения данных. Например, для какого-либо бизнес-процесса необходимо сделать запрос к какой-либо внешней системе или выполнить внешнюю функцию. Подобный внешний вызов в WebSphere MQWorkflow реализуется в виде XML-сообщения, которое затем может быть преобразовано интеграционным брокером в сообщение формата внешней системы или обработано на самом брокере. Результат возвращается в систему управления бизнес-процессами WebSphere MQWorkflow и будет воспринят, как окончание очередной стадии бизнес процесса. В другом случае сообщение от прикладной системы, прошедшее через брокер, может вызвать старт бизнес-процесса под контролем WebSphere MQWorkflow. При этом система управления бизнес-процессами может реализовать в интересах интеграционного брокера сложную логику обработки, содержащуюся в модели бизнес-процесса.
Заключение
Неинтегрированность прикладных систем является общей и острой проблемой применения ИТ с точки зрения бизнеса. Одновременно, в информационной индустрии наблюдается быстрое развитие технологий, представляющих новые функции, и это быстрое развитие порождает дорогостоящий и рискованный соблазн полной замены существующих систем и технологий новыми. Разумной альтернативой столь радикальных подходов является интеграция существующих и новых приложений в единую среду обмена.
В основе интеграционного решения от IBM решения лежит базисная технология очередей сообщений WebSphere MQ [4] — асинхронная система передачи данных с механизмами гарантированной доставки. Поверх базовой структуры WebSphere MQ могут быть размещены другие программные компоненты для обработки передаваемой информации и управления сложными бизнес-процессами.