Интеграции внешних систем с Optimacros через корпоративную шину данных

С развитием IT-инфраструктуры и внедрением новых информационных систем перед компаниями всё острее встаёт задача интеграции этих систем для эффективного обмена данными. Чем масштабнее становится "парк" информационных решений в IT-ландшафте организации, тем сложнее поддерживать устойчивую и управляемую интеграцию между ними.

В случае применения концепции прямой интеграции (Point-to-Point) каждая система строит отдельные каналы обмена данными со всеми другими системами. При таком подходе количество связей растёт экспоненциально: для N систем требуется организовать N*(N-1)/2 индивидуальных соединений, чтобы обеспечить их полное взаимодействие. Это приводит к высокой сложности архитектуры, затрудняет её развитие и сопровождение.

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

Одним из вариантов решения проблемы является имплементация концепции шины данных (Enterprise Service Bus, или ESB). При такой схеме все системы подключаются к единому центру (шине), через который и происходит взаимодействие. Таким образом, количество необходимых соединений сокращается с N*(N-1)/2 до N, что значительно упрощает архитектуру интеграции, снижает стоимость её поддержки и позволяет быстрее подключать новые системы к существующему IT-ландшафту.

Одной из основ интеграции через шину данных являются универсальные транспортные протоколы, такие как HTTP и HTTPS, обеспечивающие надёжный обмен данными по вебу. Для построения асинхронного взаимодействия между системами применяются также специализированные протоколы обмена сообщениями, например, AMQP и MQTT, которые позволяют реализовать очереди сообщений и событийную архитектуру.

Не менее важным элементом являются стандарты взаимодействия с ресурсами и сервисами. Наиболее широко распространены REST — легковесный архитектурный стиль работы через HTTP, и SOAP — формализованный протокол обмена сообщениями в формате XML, обеспечивающий строгую структуру и стандартизацию взаимодействий.

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

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

Событийная интеграция — это архитектурный подход, при котором системы обмениваются сообщениями не в ответ на прямой запрос, а при наступлении определённых событий. Такие события соответствуют хозяйственным операциям, зарегистрированным в ИТ-системах. Они служат триггером для запуска интеграционных процессов.

Процесс событийной интеграции начинается с того, что система-источник (например, ERP, MDM или HR-система) генерирует событие. Это может быть любое бизнес-событие: регистрация нового контрагента, создание заказа, приём на работу сотрудника.

С точки зрения шины данных, каждое событие представляет собой структурированные данные в формате JSON или XML, включающие обязательные параметры: тип события, временную метку (timestamp), уникальные идентификаторы и бизнес-данные.

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

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

Однако на практике трансформацию данных может также осуществлять и система-источник и система-приемник.

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

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

После определения маршрута шина данных преобразует событие в формат, ожидаемый системой-получателем, и отправляет его через REST API или другие предусмотренные интерфейсы. Для каждой системы может быть настроен собственный REST-endpoint, специфическая схема данных и механизм аутентификации.

После отправки события шина данных переходит к этапу контроля доставки. Для подтверждения успешной обработки сообщения системой-получателем, как правило, используется HTTP-ответ со статусом 200 OK, но может использоваться иной согласованный механизм подтверждения.

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

API Service в Optimacros — это механизм для организации внешнего доступа к функциональности моделей воркспейса через WEB API.

Работа API Service устроена следующим образом. Для каждого API сервиса задаются параметры: имя, алиас, ссылка на модель и ссылка на управляющий скрипт. Управляющий скрипт обрабатывает входящие запросы: принимает данные, выполняет нужные операции с моделью (см. раздел Реализация скрипта-контроллера) и возвращает ответ клиенту.

Детальная инструкция по принципам работы и настройке API Service приведена в Разделе 3.10 Руководства администратора Workspace. В этом же разделе можно найти примеры управляющего скрипта. Последний удобно использовать для отладки соединения с клиентом и анализа содержимого запросов клиента, однако он не подойдет для промышленной реализации управляющего скрипта или так называемого скрипта-контроллера.

Скрипт-контроллер или управляющий скрипт связывается с API Service Оптимакрос и первый принимает на себя управление поступившим на http-запросом. Запросы могут иметь разные методы (GET, POST и др.), содержать URL-параметры запроса, тело запроса или приложенные к запросу файлы (для POST). Назначение запроса, его содержание, структура его тела в общем случае будут различаться и требовать специализированной обработкой.

Обобщенно, скрипт контроллер должен выполнять следующие функции:

➀ Получать первичное управление поступившим на Endpoint http-запросом;

➁ Проверять метод запроса (например GET/ POST), чтобы далее правильно извлечь из него информацию;

➂ Для POST запросов извлекать и валидировать тело запроса. В зависимости от задач, валидация может несколько различаться. Например, скрипт может содержать следующие проверки:

• тело запроса не пустое;
• json/XML имеют валидную структуру;
• поступивший поток зарегистрирован в системе и может быть обработан в модели;
• вместе с запросом переданы обязательные параметры, и они имеют не пустое значение.

➃ Выполнять процессинг запроса через вызов целевого интеграционного скрипта исходя из идентифицированного потока (маршрутизация запросов) и передавать в целевой скрипт требуемую информацию ( тело запроса, параметры и т.д.);

➄ Считывать результаты выполнения интеграционных скриптов (из логгера или через дополнительный запрос), формировать ответ в шину;

➅ Логгировать общие результаты исполнения всей цепочки скриптов (интеграционных скриптов, вспомогательных скриптов, самого скрипта-контроллера).

В некоторых ситуациях может быть полезной реализация дополнительных функций скрипта-контроллера, таких как имплементация «очереди» потоков на Endpoint – см. раздел Очередь запросов на RESTAPI Service Optimacros;

Интеграционные скрипты, извлекающие и преобразующие данные поступивших с шины запросы, являются разновидностью core_export_import скриптов стандартной библиотеки Оптимакрос. Для описываемого в настоящей статье вида интеграции подойдут типы источников OM_WEB_SERVICE_GENERAL_PASSIVE или OM_WEB_SERVICE_FILES_PASSIVE (см. https://support.optimacros.com/topic/5644/yadro-core_export_import).

Эти типы источников обеспечивают обработку запросов на API Service и имеют настройку разбора json/ XML для преобразования форматов в тубулярный вид.

Полезные материалы и описание настройку парсинга json можно найти по ссылке выше для ядер версий 1.15.4, 1.10.17 и 1.10.8.

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

Пример вызова:

Основной задачей интеграционного скрипта является получение данных из источника, их преобразование (если требуется) и сохранение результатов в приемнике. Приемник в Оптимакрос может иметь разный тип, но, если требуется загрузить данные в собственное хранилище, обычно используется тип OM_MULTICUB.

Распространённым архитектурным паттерном является импорт данных в «плоский» мультикуб, состоящий из нумерованного справочника и кубов данных. В этом случае мультикуб концептуально напоминает двумерную таблицу, где элементы нумерованного справочника являются строками, а кубы — столбцами или полями таблицы. Например:

При использовании событийной интеграции запросы поступают на API Service системы, где обрабатываются интеграционными скриптами и сохраняются в мультикубе-приёмнике, организованном, например, по описанному выше принципу. Поскольку данные должны накапливаться без перезаписи друг друга, возникает задача корректного определения «последней заполненной строки» для каждого нового запроса.

Технически определить очередную «строку» для записи не составит труда через одну из вариаций формул. В приведённом примере достаточно получить значение в элементе «Итого» куба Ordinal и прибавить единицу, что даст номер первой свободной строки - 13386.

Однако на практике такой способ оказывается ненадёжным. Дело в том, что работа интеграционных скриптов и пересчет формул выполняется в разных, несинхронизированных потоках. При массовой обработке запросов, поступающих почти одновременно на эндпоинт API Service, скрипты могут завершить выполнение быстрее, чем пересчитается итоговое значение счётчика. Чем больше записанных строк в мультикубе, тем медленнее пересчитывается Ordinal, увеличивая риск того, что несколько потоков попытаются записать данные в одну и ту же строку.

Более правильным решением является использование счётчиков, управляемых самими интеграционными скриптами. В этом случае скрипт дополнительно определяет количество строк в поступившем запросе и инкрементирует значение специализированного счётчика занятых строк. Значение счётчика хранится в специальной ячейке: оно считывается до выполнения скрипта и обновляется только после успешной записи данных.

Одним из важных аспектов эффективной работы интеграционных решений через API Service Optimacros является обработка поступающих запросов в условиях высокой нагрузки. На эндпоинт API Service может поступить несколько тысяч запросов одновременно, например когда система-источник передает исторические данные за предыдущий период. Из каждого запроса извлекаются данные для импорта в мультикуб-приемник. При большом потоке событийных запросов каждая операция сохранения становится триггером для пересчёта цепочек кубов в модели, таких как: проверка уникальности значений, проверка связей через FINDITEM, обработка ошибок в загрузочных мультикубах и другие вычисления, необходимые для реализации бизнес-логики модели. Таким образом, система одновременно инициирует множество "холостых" пересчётов, что приводит к лавинообразному росту потребления ресурсов, замедлению работы всей модели и в критических случаях — к её падению. Между тем часто пересчет модели требуется только после обработки и сохранения всего пакета исторических данных.

В Optimacros очередь запросов реализуется через компонент Redis Queue. Однако в текущих версиях ПО доступ к данным этой очереди (например, получение информации о размере очереди) не реализован.

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

·При достижении определённого порога необработанных запросов на эндпоинт, авто-пересчёт модели временно отключается.

·После обработки всей очереди и окончания поступления запросов, пересчёт автоматически включается обратно.

Такая организация обработки позволяет существенно разгрузить модель в моменты пиковых нагрузок, ускорить загрузку данных через API Service и повысить общую отказоустойчивость системы.

Настройка интеграции с корпоративной шиной данных подразумевает получение тестовых запросов API сервисов Optimacros и дальнейшее профилирование их обработки. Согласно принципам событийной интеграции через ESB, чтобы событие было передано в шину данных, оно должно быть инициировано системой-источником (см. раздел Принцип событийной интеграции через ESB).

Однако организация полноценного тестирования через реальные системы-источники на практике оказывается не всегда удобной. Для этого требуется развёртывание тестовых контуров, копирование экземпляров систем и выдача доступа проектной команде к каждой из них. Либо необходимо привлекать команду Заказчика уже на ранних этапах тестирования, что может быть обременительным и нецелесообразным.

Для упрощения процесса применяются специализированные инструменты тестирования REST API. Одним из наиболее популярных решений является Postman — платформа для разработки, тестирования и мониторинга веб-API. Postman предоставляет удобный графический интерфейс для отправки HTTP-запросов и анализа ответов, поддерживая работу с REST, SOAP, GraphQL и другими протоколами.

На этапе разработки Postman может успешно выполнять роль альтернативного источника событий, эмулируя работу внешней шины данных. Инструмент обеспечивает следующую функциональность при взаимодействии с API Service Optimacros:

• Проверку авторизации через пользовательский токен;
• Отправку HTTP-запросов различных типов (GET, POST и других);
• Подготовку заголовков запросов (Headers) в требуемом формате;
• Формирование тела запроса в различных форматах, включая возможность прикрепления файлов;
• Настройку автоматизированного тестирования ответов от API Service Optimacros (например, проверку статуса и содержимого ответа);
• Создание коллекций запросов и реализацию пакетной отправки для целей нагрузочного тестирования.

Использование Postman позволяет значительно упростить процесс начального тестирования интеграции, снизить зависимость от внешних команд и ускорить этапы отладки интеграционных скриптов.

Более подробную информацию о возможностях и настройках Postman можно найти в официальной документации сервиса.

Реализация событийной интеграции через шину данных в Optimacros имеет ещё одну важную особенность, связанную с архитектурой самой платформы. Поскольку Optimacros, как и другие аналогичные in-memory решения, хранит все рабочие данные в оперативной памяти сервера, любые изменения сохраняются на диск только в момент выполнения фонового или ручного бэкапирования.

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

Другой ситуацией «потери запросов» может являться временная недоступность вокспейса из-за технических работ или «обрывом связи» между сервером с системой-источником и сервером Optimacros. Как уже говорилось выше, в этом случае шина попробует повторно отправить запрос, но количество и продолжительность таких повторов обычно ограниченно настройками самих сервисов шины.

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

Одним из архитектурных подходов решения подобных проблем может являться архивирование http-запросов на диске. Для этого в интеграционных скриптах предусмотрен блок настроек ARCHIVATE_REQUEST. В нем указывается тип подключаемого устройства для хранения логов (FTP, 'SHARED_FOLDER', 'SHAREPOINT') и путь к целевой директории относительно точки монтирования.

Стандартных средств восстановления архивных запросов через переотправку их на API Service Optimacros в текущих релизах Optimacros нет. Однако с использованием доступных API-интерфейсов платформы можно разработать скрипты, обеспечивающие следующую функциональность:

• Чтение архивных файлов с запросами по заданным критериям (например, в интервале дат DATE_FROM — DATE_TO);
• Формирование очереди для повторной отправки запросов;
• Отправка архивированных запросов обратно на API Service Optimacros;
• Обработка ответов от сервера по результатам выполнения;
• Исключение повторного архивирования переотправленных событий для предотвращения их дублирования.

На момент написания настоящей статьи у автора имеется следующий набор скриптов реализующий полный цикл задач интеграции корпоративной шины данных с API Service Optimacros:

REST API Gateway 2.1.js – Скрипт-контроллер: Валидация и диспетчеризация входящих потоков по интеграционным скриптам-процессорам.

REST API Queue Manager 2.1.js – Управление очередью запросов. Скрипт считает количество http-запросов, ожидающих исполнение на REST API Gateway. Если очередь больше порогового значения, отключается автоматический пересчет модели, что сильно снижает нагрузку на модель при одновременном поступлении большого количества запросов.

REST API Response Info 1.2.js – Логгирование и передача ответа в шину данных. Формирование ответа клиенту по результатам обработки запроса, поступившего на REST APIEndpoint

REST API Requests Recovery 1.1.js – Восстановление архивных запросов через переотправку их на API Service OM