), прежнее название - Axelot Datareon ESB, предназначена для построения распределённого информационного ландшафта предприятия. Программный продукт обеспечивает взаимодействие всех интегрируемых приложений в одном центре, объединяя существующие источники информации и предоставляя централизованный обмен данными между разными информационными системами.

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

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

Функциональные возможности

• Поддержка различных стандартов и сценариев интеграции
• Централизованное управление интеграционным ландшафтом с помощью экосистемы Eclipse
• Трансформация данных (многошаговые алгоритмы преобразования данных с контролем различных условий)
• Передача данных любого размера (вертикальное и горизонтальное масштабирование)
• Простая интеграция с продуктами на платформе «1С:Предприятие 8»
• Обеспечение безопасной передачи данных
• Диагностика и мониторинг состояния всей сети передачи данных

Решаемые задачи

• Передача данных между различными информационными системами (с маршрутизацией или «точка-точка»)
• Формирование единого информационного пространства в гетерогенных средах
• Построение распределённой системы на основании событийной модели в следующих вариантах:
  • построение приложений со сквозными бизнес-процессами на основании событийной модели;
  • создание системы с синхронизацией бизнес-приложений в различных информационных системах
• Получение масштабируемой архитектуры управления уровня предприятия/холдинга
• Развертывание системы обмена данными на транспортном уровне и на уровне бизнес-логики
• Делегирование задачи построения информационных потоков аналитическим отделам
• Уменьшение общей сложности интеграционной схемы и снижение требования к пропускной способности каналов
• Увеличение общей стабильности транспортного уровня передачи данных
• Снижение транзакционных издержек при обмене данными между различными подразделениями

2017

Axelot Datareon ESB 2.1.0.0

Решение AXELOT Datareon ESB вошло в список компетенций Gold Application Development - факт, подтверждающий высокое качество продукта и его совместимость с продуктами Microsoft .

AXELOT Datareon ESB предоставляет для бизнеса ряд ключевых преимуществ:

• Возможность интеграции;
• Надежность и возможность многократного использования ресурсов;
• Получение масштабируемой архитектуры управления уровня предприятия/холдинга;
• Делегирование задачи построения информационных потоков аналитическим отделам;
• Уменьшение общей сложности интеграционной схемы и снижение требования к пропускной способности каналов;
• Увеличение общей стабильности транспортного уровня передачи данных;
• Снижение транзакционных издержек при обмене данными между различными подразделениями;
• Снижение общих затрат на обслуживание и сопровождение информационной системы.

Основные возможности системы:

• Большое количество коннекторов к различным системам: 1С:Предприятие 8 , SOAP-сервисы, REST-сервисы, MS SQL , IBM DB2 , Oracle DB , PostgreSQL , SharePoint , OData, TCP, Siemens TeamCenter и другие;
• Механизм плагинов для самостоятельной разработки коннекторов;
• Поддержка различных языков программирования и технологий при разработке сценариев взаимодействия: 1С:Предприятие 8, JavaScript, T-SQL;
• Настройка многошаговых сценариев трансформации данных с использованием визуальных механизмов мэппинга и произвольных XSLT-преобразований;
• Работа с различными форматами данных (XML, JSON, XLS, DBF, CSV, Base64 и другие);
• Статическая и динамическая маршрутизация информационных пакетов;
• Высокая скорость взаимодействия и отказоустойчивость: пониженные требования к пропускной способности сети, балансировка нагрузки, изоляция информационных доменов, возможности мониторинга состояния узлов интеграции;
• Поддержка событийной модели, синхронные и асинхронные вызовы, гарантированная доставка;
• Изменение интеграционных сценариев систем-подписчиков (механизмов выгрузки/загрузки, трансформации и маршрутизации) в "горячем" режиме без необходимости их остановки (включая конфигурации на платформе 1С:Предприятие 8);
• Диагностика и мониторинг всех процессов интеграции, возможности отладки и трассировки информационных пакетов.

Особое внимание уделено интеграции приложений на платформе 1С:Предприятие 8 . В поставку включена специальная подсистема, которая встраивается в любую типовую конфигурацию на платформе "1С:Предприятие 8" и обеспечивает все необходимые механизмы для быстрой и удобной настройки и администрирования интеграции. Взаимодействие "AXELOT: ESB Сервисная шина данных" с конфигурацией на платформе "1С:Предприятие 8" осуществляется посредством SOAP и REST-сервисов.

Серверные компоненты "AXELOT: ESB Сервисная шина данных" разработаны на языке С++. Администрирование и настройка "AXELOT: ESB Сервисная шина данных" осуществляется в среде разработки Eclipse и может выполняться совместно с разработкой систем на платформе "1С:Предприятие 8" в "1С :Enterprise Development Tools". "AXELOT: ESB Сервисная шина данных" является мультиплатформенной и поддерживает операционные системы MS Windows и Linux .

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

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали - теперь это улица Марии Ульяновой, а дом 25 по этой улице - хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…

Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась.

Как это было раньше? Один банк отправлял другому электронное сообщение (Уж извините, я тогда в Инкомбанке работал, потому про банки буду рассказывать). Второй банк сообщение получал и отправлял на него квитанцию. Все это десять раз шифровалось, заверялось цифровой подписью, в квитанцию включалась хеш-функция исходного сообщения … номера входящих и исходящих, отметки времени (тоже, кстати, криптографические) и т.д. и т.п. Наиболее обсуждаемый вопрос тех лет, а нужно ли на квитанцию формировать квитанцию о получении квитанции и что делать, когда квитанция не доставлена. В общем, страшно вспомнить до какого уровня сложности можно довести процесс синхронизации состояний множественных виртуальных образов одного реального документа. С бумагой было проще. По крайней мере, до изобретения ксерокса.

Возвращаемся в современность. Если очереди сообщений существовали для того, чтоб безопасно и гарантированно сообщения доставлять, то сервисная шина появилась для того, чтоб обмен сообщениями исключить. И не надо мне рассказывать, что эта самая шина как раз и осуществляет обмен сообщениями. Я это знаю, мы и сами так делаем, только это не очень правильно. Изначальная идея сервисной шины, тем более Enterprise Service Bus (ESB) состоит не в том, чтоб передавать сообщения, а в том, чтоб любое приложение не заботилось о необходимости создания своего локального экземпляра объекта. Смысл сервиса в том, чтоб всегда можно было такой объект получить. Нужен вам документ – вбили URL и методом HTTP GET документ получили и почитали. Захотели документ изменить – по тому же самому URL, методом HTTP PUT документ изменили. POST-ом добавили, DELETE-ом удалили, ну что может быть проще? Присвойте вы документу URL. Воспользуйтесь протоколом в стиле WebDAV чтобы взять документ, поработать и в новом статусе вернуть на его место, то самое, определенное в качестве мастер-копии, т.е. на тот же URL с которого взяли

Иначе – апокалипсис. Квитанции и уведомления об изменении статуса – это еще полбеды. Необходимость одинаково толковать поля документов, а для этого синхронизировать справочники – вот это беда. Третья улица строителей в Москве и 3-я улица строителей в Питере, как это известно из главного новогоднего фильма, далеко не одно и то же. Пожалуй, единственный справочник одинаково трактуемый в разных ведомствах это григорианский календарь. И то, я до конца не уверен. Или другой пример — моё имя в загранпаспорте не совпадает с моим же именем на британской визе, вклеенной в тот же загранпаспорт. В паспорте написано MAXIM, а в визе — MAKSIM. Я из-за этого границу пересекать боюсь 🙂 Прибавим к этому различие наборов состояний документа в разных системах, разные графы переходов, составные документы, включающие в себя набор других документов, электронные конверты и пр. Мы получаем задачу невероятной комбинаторной сложности. А если документ не в одно ведомство пойдет, а сразу в несколько? В одном его исполнят, в другом отвергнут, в третьем – потеряют. Потому процессные человечки очень скоро добавят к этому документу маршрут, лаконично выраженный в нотации BPMN на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато программисты продолжают работать)

Интеграционная шина данных предназначена для построения композитных приложений, использующих различные стандарты и технологии взаимодействия, построенные по разным принципам. Особое внимание уделено интеграции приложений на платформе «1С:Предприятие».

Поддержка различных стандартов и сценариев интеграции с помощью интеграционной шины данных

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

В DATAREON ESB существуют следующие типы коннекторов:

• Коннектор SOAP-сервисов, включая web-сервисы «1С:Предприятие 8»
• Коннектор REST-сервисов, включая web-сервисы «1С:Предприятие 8»
• Коннектор MS SQL
• Коннектор IBM DB2
• Коннектор Oracle
• Коннектор PostgreSQL
• Коннектор SharePoint
• Коннектор OData 1C
• Коннектор TCP
• Коннектор Siemens Team Center
• Коннектор SAP и другие.

Все коннекторы имеют возможности параметрической настройки подключения к системе-источнику и взаимодействию с ней.

Список доступных коннекторов постоянно расширяется, полный перечень необходимо уточнять в компании DATAREON .

В составе DATAREON ESB присутствует механизм, позволяющий самостоятельно разрабатывать различные коннекторы на языке Java или языках платформы.Net. Таким образом может быть реализован любой пользовательский сценарий подключения к системам-источникам.

На мой взгляд можно выделить два подхода к построению интеграционной шины предприятия:

• "от интегрируемых систем";


• "от реализуемых процессов".

Давайте рассмотрим данные подходы подробнее.

Подход "от интегрируемых систем"

В данном случае интеграционная шина рассматривается как некий транспорт, который осуществляет маршрутизацию и согласование протоколов обмена сообщениями. Все сообщения проходят по цепочке: входной канал адаптера системы-источника -> маршрутизатор -> выходной канал системы-приемника. Тип связи между данными компонентами и конкретные технологии зависят от того, может ли быть у сообщений, поступающих из одной системы-источника, несколько систем-приемников, от ожидаемой нагрузке и подхода к обеспечению целостности данных (используется общая транзакция для всех систем-источников, либо данные в каждую систему-источник передаются в своей транзакции).

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


2. Легкость подключения новых систем-приемников: для подключения новой системы-приемника достаточно внести данные в таблицу маршрутизации.


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


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


5. Разделяемость системы между разработчиками. Так как ядро системы и все адаптеры независимы друг от друга (связь обеспечивается только через выделенные и описанные интерфейсы), то задачи по их разработке могут быть разделены между программистами, что позволяет распараллелить процесс создания и внедрения интеграционного решения.

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


2. Данная схема подходит для реализации асинхронного обмена. В случае синхронного либо смешанного обмена трудоемкость в реализации данного подхода значительно возрастает.


3. Может иметь место снижение производительности решения. Например, в случае если сообщение в каждую из систем-приемников должно передаваться в отдельной транзакции, требуется разделение системы-источника, ядра и систем-приемников очередями. Данные очереди могут стать узким местом системы.

Подход "от реализуемых процессов"

В данном случае отдельно рассматривается каждый бизнес-процесс, в котором требуется осуществление обмена данными между несколькими системами. Шина реализует данный обмен. Событием, запускающим процесс обмена, является получение сообщения из системы-источника. Полученное из системы-источника сообщение передается в одну или несколько систем-получателей, при этом реализуется не просто транспортные функции, но и производится отслеживание результата обработки сообщения и корреляция передаваемого сообщения с другими.

У данного подхода есть следующие плюсы:

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


2. Трудоемкость реализации как асинхронного, так и синхронного обмена примерно одинакова.


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

У данного подхода есть следующие минусы:

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


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


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

Выбор подхода осуществляется по следующему алгоритму:

1. Получить от аналитиков список и описание интегрируемых систем и типов сообщений.


2. Получить от аналитиков список и описание бизнес-процессов, в которых участвуют требующие интеграции системы.


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


4. Если процессы подразумевают преимущественно синхронный обмен, при этом процессы комплексные, т.е. прохождение сообщения зависит от результатов его обработки в системах-приемниках, то выбираем второй подход. Аргументом в пользу данного подхода может являться еще и тот факт, что количество типов сообщений сопоставимо с количеством интегрируемых систем.

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

Понравилось сообщение -