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

Если размер модели значителен (например, 3–5 ГБ и более), то использование стандартного подхода – загрузка бэкапа на локальный персональный компьютер, а затем повторная отправка на удалённый сервер для восстановления – становится проблемным. Это требует времени и хорошей пропускной способности сети, особенно если подключение осуществляется через VPN или скорость обмена ограничена политиками безопасности. Кроме того, подобный процесс зачастую противоречит требованиям информационной безопасности: резервные копии могут содержать персональные, конфиденциальные или чувствительные бизнес-данные, которые запрещено копировать на локальные устройства сотрудников.

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

Одним из удобных и функциональных клиентов для подключения к Linux-серверам из среды Windows является MobaXterm. Он сочетает в себе функциональность терминала, графического интерфейса и встроенного X-сервера, что делает его удобным для работ, описанных в настоящей статье.

Cкачать MobaXterm можно с официального сайта: https://mobaxterm.mobatek.net

После установки и запуска MobaXterm выполните следующие шаги для подключения:

① Нажмите кнопку Sessions (Сеансы) → New Session (Новая сессия) → выберите SSH.
② Введите следующие данные (их необходимо запросить у администратора заказчика):

• Remote host (адрес удалённого сервера)
• Port (по умолчанию используется 22, но в инфраструктуре заказчика может быть другой)
• Username (логин для подключения)
• Метод аутентификации:

∘ По логину и паролю: выбрать опцию “Specify username” и ввести логин; пароль будет запрошен при подключении.
∘ По приватному ключу (Private Key): выбрать “Use private key”, указать путь к .pem или .ppk файлу. Важно удостовериться, что ключ не защищён паролем или пароль известен.
③ Дополнительные настройки, которые понадобятся на следующих шагах работы с подключением:

• Убедитесь, что опция X11-Forwarding включена (если потребуется запуск графических окон).
• Проверьте, что X-сервер активен: в правом верхнем углу MobaXterm иконка с буквой X должна быть подсвечена. Это необходимо для работы с утилитами, использующими графический интерфейс.

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

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

Как правило, программные компоненты Optimacros устанавливаются в директорию /om. Иногда используется путь /opt/om, в более редких случаях — другие пользовательские каталоги. Внутри /om можно найти следующие ключевые подкаталоги:

• ./docker — платформа контейнеризации, внутри которой развёрнут Login Center;
• ./login-center — установочные файлы Login Center;
• ./lxc — контейнерная система виртуализации Linux, в рамках которой запускаются рабочие окружения workspaces;
• ./workspace-installer — установщик воркспейсов.

Также в каталоге /om располагаются директории с развернутыми воркспейсами. Они могут называться, например: ./workspace1, ./workspace2, ./prod, ./test и др. Названия директорий совпадают с именами воркспейсов, отображаемыми в интерфейсе Login Center.

Внутри каждого воркспейса резервные копии моделей хранятся по следующему пути:

/om/<имя_воркспейса>/data/modelBackups/<model_ID>

Имя каталога с бэкапами совпадает с ID Модели. Последний можно получить:

➔ В URL-адресе открытой модели,
➔ В мульткубе Variables внутри модели:

➔ В административной панели Login Center

Таким образом полный путь к файлам бэкапов будет выглядеть примерно следующим образом:

/om/workspace1/data/modelBackups/d7f6ab2c016e8fff9d862eb24ab6697c

Для просмотра списка бэкапов необходимо открыть SSH-консоль, перейти в нужный каталог, выполнив команды:

cd /om/workspace1/data/modelBackups/d7f6ab2c016e8fff9d862eb24ab6697c
Is-It

Файлы бэкапов имеют формат:

YYYY-MM-DD_HH-MM-SS_<номер>.zip

Ориентироваться удобно по дате создания и номеру бэкапа, который соответствует ID резервной копии в административной панели.

Следующим шагом необходимо перенести архив .zip с резервной копией на целевую машину (например, сервер PROD). Для этого можно использовать стандартные средства Linux — утилиты scp или sftp.

Директорией для копирования на сервере-приёмнике может являться /tmp или другая доступная пользователю SSH (не под root!) папка.

Примеры команд для копирования на удаленный сервер 10.0.144.105, в директорию-приемник /tmp:

Утилита scp:

scp "/om/workspace1/data/modelBackups/d7f6ab2c016e8fff9d862eb24ab6697c/2025-05-02_12-04-22_1339.zip" root@10.0.144.105:/tmp

Утилита sftp:

sftp root@10.0.144.105
sftp> cd /tmp
sftp> lcd /om/workspace1/data/modelBackups/d7f6ab2c016e8fff9d862eb24ab6697c
sftp> put 2025-05-02_12-04-22_1339.zip
sftp> bye

После завершения копирования необходимо изменить владельца файла на пользователя, под которым работает воркспейс. Например:

chown optimacros_workspace:optimacros_workspace "/tmp/2025-05-02_12-04-22_1339.zip"

Восстановление бэкапа в модели удаленного сервера подразумевает загрузку информации о нем во внутреннюю базу данных Optimacros (подробнее см. раздел Восстановление бэкапа). Поскольку работа с административной панелью происходит через пользовательский браузер, при нажатии кнопки Browse отображается локальная файловая система пользователя, а не целевого сервера. Чтобы выбрать файл, расположенный на сервере, необходимо открыть браузер непосредственно в среде удалённой машины.

Для этих целей используется технология X11-forwarding — механизм, позволяющий запускать графические приложения на удалённой машине, но отображать их окна на локальном компьютере. Этот механизм работает через X Server — компонент, обрабатывающий графический вывод в системах на базе UNIX и Linux.

Если вы используете MobaXterm в Windows, X Server встроен в приложение и запускается автоматически. Главное условие – X-сервер должен быть активен (иконка с буквой X в правом верхнем углу интерфейса должна быть подсвечена), а при подключении по SSH включена опция X11-forwarding.

Ниже приведена пошаговая инструкция по запуску браузера Google Chrome с удалённого сервера в окружении Debian/Ubuntu.

① Проверяем установку Google Chrome:
dpkg -l | grep google-chrome

② Если команда возвращает пустую строку, значит браузер не установлен. В этом случае скачиваем дистрибутив:
cd /tmp
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

③ Проактивно исправляем нарушенные зависимости пакетов (если таковые имеются) и устанавливаем скаченный пакет:
sudo apt-get install -f
sudo dpkg -i google-chrome-stable_current_amd64.deb

④ Проверяем, что SSH-соединение поддерживает X11-forwarding.
На удалённом сервере открываем файл:
cat /etc/ssh/sshd_config

И убеждаемся, что в файле содержит следующие строки (и они не закомментированы):
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Если это не так, запускаем
nano /etc/ssh/sshd_config
и раскомментируем нужные строки.

После изменения конфигурации необходимо перезапустить SSH-сервис:
sudo systemctl restart sshd

⑤ Если все операции выше делались под root (sudo -i, sudo -s), рекомендуется вернуться к первоначальной учётной записи, под которой было установлено SSH-соединение:
exit

⑥ Далее запускаем браузер:
google-chrome-stable --no-sandbox

Если всё настроено корректно, окно браузера откроется на вашем локальном компьютере, но будет работать в контексте удалённого сервера. Благодаря этому возможно просматривать его файловую систему и выбрать нужный .zip-файл для восстановления модели.

Процедура восстановления модели из резервной копии выполняется через административную панель Optimacros на целевом сервере. На этом этапе важно, чтобы файл бэкапа уже находился на сервере-приёмнике (см. раздел «Копирование бэкапа модели»), а интерфейс админ панели открыт либо локально через X11-forwarding.

Пошаговая инструкция восстановления:

① Создайте модель, в которой вы хотите восстановить бэкап.
② В административной панели выберите: Models → General → Open “Имя_модели” → Backups → «Загрузить файл из резервной копии»
③ В открывшемся файловом диалоге выберите .zip-файл бэкапа из локальной файловой системы сервера:

После выбора нажмите кнопку «Загрузить»

④ После завершения загрузки перейдите во вкладку:
Restore → «Восстановить из последней резервной копии»
Нажмите кнопку «Восстановить» и дождитесь завершения процедуры.

Примечание: В новых версиях появилась возможность объединить загрузку бэкапа и восстановление его в модель через: Models → General → Open “Имя_модели” → Restore→ «Восстановить из файла резервной копии», однако не во всех версиях эта функция работает корректно.

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

➜ Проблема с переключением раскладки клавиатуры в режиме X11.

Если при запуске Google Chrome на удалённом сервере через X11-forwarding не удаётся переключить раскладку клавиатуры (например, на русский или английский языки), выполните следующие действия:

В консоли удалённой машины выполните команду для установки вспомогательных утилит:
sudo apt install x11-xkb-utils

Затем настройте переключение раскладки клавиатуры сочетанием клавиш Alt+Shift:
setxkbmap -layout ru,us -option grp:alt_shift_toggle

При необходимости, эту команду можно сохранить в настройках SSH-сессии в MobaXterm, указав её в поле Execute command при создании подключения. Это позволит автоматически применять раскладку при каждом входе на сервер:

➜ Ошибка при восстановлении большого бэкапа

При восстановлении архивов модели размером более 1 ГБ в административной панели Optimacros может возникнуть ошибка, связанная с превышением лимита на размер загружаемого файла:

Ошибка характерна для некоторых версий ПО и возникает из-за ограничений, установленных в конфигурации PHP внутри контейнера воркспейса.

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

① Получаем список активных контейнеров с вокрспейсами:
lxc-ls

② Подключаемся к нужному контейнеру:
lxc-attach имя_контейнера

③ Внутри контейнера редактируем конфигурационный файл:
root@workspace-box> nano /etc/php/8.1/fpm/pool.d/optimacros.conf

④ С помощью сочетания Ctrl+W находим строку с параметром upload_max_filesize:

Для следующих параметров устанавливаем значение 0 (без ограничения по размеру):
php_admin_value[upload_max_filesize] = 0
php_admin_value[post_max_size] = 0
Сохраняем изменения и закрываем редактор (Ctrl+O, Enter, затем Ctrl+X).

⑤ Перезапускам службы и выходим из контейнера:
systemctl restart php8.1-fpm nginx
exit

⑥ Возвращаемся к шагу 2 раздела Восстановление бэкапа и повторяем попытку загрузки.

С развитием 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