), колишня назва - 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) дозволяють це робити.

Сподобалося повідомлення -