О клиенте и контексте
Крупный ритейлер с распределенной логистикой и централизованной системой управления. В связи с реорганизацией юридического лица и последующим переходом на самостоятельную ИТ-инфраструктуру возникла необходимость выстроить заново архитектуру обмена данными между основными бизнес-системами.
До старта проекта отсутствовала централизованная шина данных. Обмен между SAP ERP (система управления ресурсами предприятия), BI (система бизнес-аналитики) и складами осуществлялся вручную или с помощью набора локальных скриптов без централизованного управления. Это вызывало задержки, увеличивало риск ошибок и не позволяло масштабировать процессы.
Исходные условия на момент начала проекта
- Интеграции между системами отсутствовали или реализованы фрагментарно;
- Не было централизованного мониторинга и трассировки данных;
- Не обеспечивалась гарантия доставки сообщений;
- Все потоки сопровождались вручную.
Цели внедрения
- Централизовать обмен данными между SAP, BI (система бизнес-аналитики), MDM (управление мастер-данными), WMS;
- Обеспечить отказоустойчивость и масштабируемость;
- Создать платформу, которую можно развивать самостоятельно;
- Обеспечить мониторинг и контроль обработки каждого сообщения.
Реализация
Архитектура платформы построена с использованием Kafka (система потоковой передачи данных), HTTP-интерфейсов и SAP IDOC (Intermediate Document — формат структурированных сообщений SAP). В состав решения входят реактивный Gateway для приёма входящих запросов, NiFi для маршрутизации и логирования, а также HTTP-адаптеры для интеграции с BI и другими системами.
Потоки реализованы по схеме: SAP передаёт IDOC по HTTP -> сообщение принимается через gateway -> обрабатывается в NiFi -> сохраняется и маршрутизируется через Kafka -> после чего доставляется в целевую систему (например, BI или MDM).
Для маршрутизации и логирования используются поля DOCNUM (уникальный номер IDOC) и MESTYP (тип бизнес-сообщения, например, заказ или клиент). В рамках проекта все потоки построены как независимые процессы приема, обработки, маршрутизации и доставки сообщений.
По результатам внедрения
- Развернута продуктивная среда в течение 3 недель;
- Реализовано более 10 потоков;
- Реализована архитектура без единой точки отказа;
- Внедрен DRP-план (Disaster Recovery Plan), обеспечивающий восстановление всех ключевых компонентов.
Отказоустойчивость и DRP (план аварийного восстановления)
Согласно плану аварийного восстановления, при сбое компонентов (Kafka, PostgreSQL, NiFi, адаптеры) обеспечено восстановление работоспособности. DRP-процедуры предусматривают перезапуск и проверку каждой точки отказа по шаблону, с логированием и уведомлением. Для NiFi настроена автоматическая репликация потоков и пересоздание маршрутов.
Нагрузочные показатели
| Поток | Назначение | Max RPS | Объeм в сутки | Стабильность при 100 RPS |
| 1 | HTTP → Kafka (SAP IDOC) | 170 | ~1.3 млн | стабильная работа |
| 2 | Kafka → Kafka (маршрут) | 140 | ~1.2 млн | стабильная работа |
| 3 | Kafka → HTTP (BI/XML) | 190 | ~1.7 млн | стабильная работа |
Результаты и подтвержденные эффекты
- Платформа выдерживает до 190 RPS на отдельных потоках;
- Обмен данными автоматизирован и не требует ручного сопровождения;
- Внутренняя команда заказчика самостоятельно добавляет потоки;
- BI получает актуальные данные без задержек;
- Потери сообщений исключены, каждый этап маршрута контролируется;
- Среда масштабируется за счeт контейнеризации Kubernetes (платформа оркестрации контейнеров).
Выводы
Внедрение корпоративной шины данных USEBUS позволило заказчику решить задачу отказоустойчивого, масштабируемого и управляемого обмена данными между основными ИТ-системами — SAP ERP, BI и MDM (управление мастер-данными).
Платформа внедрена в сжатые сроки, протестирована под промышленной нагрузкой и сопровождается силами внутренней команды. За счёт встроенных механизмов маршрутизации, логирования и DRP, компания получила полную прозрачность и контроль над движением данных без зависимости от подрядчика.