Введение: Иллюзия простоты

В Enterprise‑сегменте (ритейл, финтех, промышленность) часто возникает типичная задача: есть тяжелое, неповоротливое ядро (SAP, Oracle, IBM Tririga или монолитная 1С) и есть необходимость дать доступ к части его данных внешним контрагентам.

Бизнес просит: «Давайте сделаем легкий B2B‑портал для подрядчиков, чтобы они сами обновляли свои лимиты/квоты/статусы».

На первый взгляд задача кажется тривиальной: подняли Frontend на React/Vue, сделали пару REST API эндпоинтов и пишем напрямую в базу ядра. Но именно здесь начинаются архитектурные катастрофы, которые стоят корпорациям миллионы рублей из‑за потерянных данных и логических конфликтов.

В этой статье я разберу паттерн отказоустойчивой двусторонней интеграции через шину данных (ESB) и покажу, как мы стандартизируем описание таких узлов с помощью протокола АОК (Архитектурно‑Ориентированное Знание).

Проблема: Гонка состояний и «Хрупкая связь»

Представим процесс:

  1. Подрядчик заходит на Портал КА (Контрагента) и меняет свою производственную квоту (например, может взять 50 объектов вместо 10).

  2. В это же время внутренний менеджер (Бизнес‑администратор) в интерфейсе Enterprise‑ядра тоже меняет квоту этого подрядчика (например, снижает до 5 из‑за штрафа).

Если портал интегрирован с ядром синхронно (точка-точка):

  • Race Condition: Чей запрос пришел последним, тот и перетер данные.

  • Отказ в обслуживании: Если ядро ушло на бэкап или обновление, внешний портал «падает» или выдает 500-е ошибки. Пользователи в ярости.

  • Угроза безопасности: Выставлять API ядра наружу, даже через балансировщик — плохая практика.

Решение: Асинхронная двусторонняя интеграция через ESB

Чтобы избежать этого, мы применяем паттерн с использованием промежуточной интеграционной шины (ESB) и событийно‑ориентированной модели (Event‑Driven).

Вот как выглядит правильный Data Flow (Sequence Diagram):

Разбор архитектуры:

  1. Изоляция: Портал ничего не знает о структуре базы ядра. Он отправляет стандартизированный JSON в ESB. ESB берет на себя трансформацию payload'а в тяжелый SOAP/XML (или специфичный REST), который «понимает» ядро.

  2. Асинхронность и Буферизация: Если ядро недоступно, ESB сохраняет сообщение в очередь (например, RabbitMQ или Kafka). Портал мгновенно отвечает пользователю «Данные приняты в обработку», а шина доставит их, как только ядро «оживет».

  3. Master‑система: Ядро всегда является источником правды (Single Source of Truth). Если бизнес‑администратор меняет данные внутри, срабатывает внутренний триггер (OnSave/Workflow), ядро пушит webhook в шину, а шина обновляет данные на Портале КА.

Документирование как код: Протокол АОК (Архитектурно‑Ориентированное Знание)

Даже идеальная архитектура превращается в Legacy («легаси»), если её не задокументировать. В Enterprise‑разработке документация в Confluence часто устаревает еще до релиза.

В нашей практике мы используем Стандарт АОК. Это паспорт инженерного решения, который встраивается прямо в заголовок ключевых контроллеров или конфигурационных файлов ESB. Разработчик, открывая код, сразу видит бизнес‑контекст.

Пример паспорта для модуля синхронизации:

/**

  • ===================================================================

  • | AOK PASSPORT: CAPACITY SYNCHRONIZATION MODULE |

  • ===================================================================

  • @PURPOSE

  • Обеспечение двусторонней синхронизации параметров “Квот”

  • между Личным Кабинетом контрагента и карточкой в Core-системе.

  • @ARCHITECTURE

  • Принимает JSON payload от Портала КА.

  • Валидирует значения (min/max) согласно настроечной таблице.

  • Инициирует обновление записи в таблице (Business Object).

  • При изменении данных со стороны Бизнес-Администратора запускает

  • Background-процесс для передачи данных обратно через Webhook.

  • @INTEGRATION

  • Endpoint: /api/v1/sync_capacity

  • Механизм защиты: JWT-токен валидация, SSL/TLS шифрование.

  • Обработка ошибок: В случае недоступности шины активируется

  • Retry-политика (3 попытки с интервалом 5 мин), после логирование в Kibana.

  • @SOLID_COMPLIANCE

  • Single Responsibility: Модуль отвечает только за синхронизацию данных,

  • логика расчета рейтингов изолирована в отдельном микросервисе.

  • =================================================================== */

    • Такой подход ликвидирует «амнезию» у команды. Даже если сменится подрядчик или уволится Lead‑инженер, новый разработчик за 2 минуты поймет зачем написан этот код и с чем он интегрирован.

    Итог

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

    Стройте системы, а не костыли.

    Автор: Владимир Евполов, Системный Архитектор ITWWS.