Метод 15: execute_pipeline()

Домен: SIMULATION | Контур: Сетевая отправка транзакций на API-шлюз бэкенда

Ограничение публичной документации

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

Полная спецификация метода: Будет доступна только во внутреннем контуре разработки (Confluence / Swagger Enterprise).

1. Бизнес-спецификация метода

Идентификатор метода: BPDS-SIM-M015
Системное имя: execute_pipeline(payload: Object, scenario: ScenarioEnum): HttpResponse
Микросервис: simulation-core-engine
Домен: SIMULATION
Класс / Компонент: simulation.engine.net.NetworkPipelineExecutor

1.1. Описание логики работы

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

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

1.2. Пошаговое выполнение

Маршрутизация адреса: Метод считывает тип сценария и сопоставляет его с сетевой картой адресов бэкенда (выбирает кассовый вебхук, эндпоинт готовки или эндпоинт потребления).
Сериализация в JSON: Скомплектованный на прошлых шагах Java-объект автоматически переводится в текстовую JSON-строку.
Накатка заголовков трассировки: В запрос жестко прописываются обязательные заголовки: токен авторизации магазина (X-Shop-Token) и сквозной номер текущей сессии (X-Request-ID), полученный на Шаге 3.
Физическая отправка: Поток совершает HTTP POST запрос к шлюзу приложения и переходит в режим ожидания ответа.
Фиксация статуса: При получении успешного ответа 200 OK или 201 Created метод завершается и передает управление контуру верификации (Метод 16). Любые недоступности сети или ошибки кодов 4xx/5xx перехватываются для аварийного логирования.

2. Диаграмма последовательности метода (Вход и Выход флоу)

Диаграмма наглядно показывает, как сетевой конвейер принимает сформированные DTO, определяет эндпоинт, штурмует HTTP-запросом внешний API-шлюз бэкенда и возвращает статус ответа в главный оркестратор.

sequenceDiagram
    autonumber
    participant Core as Метод 3 (Orchestrator)
    participant Pipe as NetworkPipelineExecutor
    participant Client as RestClient (JVM Network)
    participant Gateway as API Шлюз Бэкенда (Magnum/Small)

    %% ВХОД МЕТОДА
    Core->>Pipe: Вызов executePipeline(payload, scenario)
    activate Pipe
    Note over Pipe: Вход метода: Готовый DTO объект данных и тип сценария такта
    
    Pipe->>Pipe: Определение эндпоинта по типу сценария
    Pipe->>Pipe: Сериализация объекта в текстовую строку JSON
    
    %% ФИЗИЧЕСКИЙ HTTP ЗАПРОС
    Pipe->>Client: Инициация POST запроса с заголовками X-Request-ID и X-Shop-Token
    activate Client
    Client->>Gateway: Физическая отправка HTTP POST по Docker-сети
    activate Gateway
    
    Note over Gateway: Бэкенд выполняет прикладную ACID-транзакцию в своей Postgres
    
    Gateway-->>Client: Возврат: HTTP 200 OK (или HTTP 201 Created)
    deactivate Gateway
    Client-->>Pipe: Передача ответа HttpResponse
    deactivate Client
    
    Note over Pipe: Выход метода: Верифицированный статус ответа HTTP протокола
    
    %% ПЕРЕДАЧА УПРАВЛЕНИЯ ОБРАТНО ОРКЕСТРАТОРУ
    Pipe-->>Core: Возврат: HttpResponse (Статус УСПЕХ)
    deactivate Pipe
    Note over Core: Оркестратор принимает сигнал и переходит к Методу 16 (Верификация Postgres)

3. Схемы данных и SQL-взаимодействие

Этот метод взаимодействует исключительно с сетевым стеком операционной системы контейнера Docker через протоколы TCP/IP и напрямую к базам данных PostgreSQL (ни симулятора, ни бэкенда) запросов не отправляет. Его цель — доставить payload до шлюза.

4. Спецификация обмена данными (Вход / Выход и Сетевые контракты)

Пример физического контракта при отправке фискального чека покупки.

4.1. Исходящий сетевой HTTP POST запрос к шлюзу бэкенда (Входные параметры в сеть)

POST /api/v1/webhooks/stores/receipt HTTP/1.1
Host: almaty-backend-gateway:8080
X-Shop-Token: almaty_retail_secret_hash_2026
X-Request-ID: req-t105-active-d3b07384
Content-Type: application/json
Accept: application/json

{
  "transaction_id": "tx-20260810-994103",
  "loyalty_card_token": "token_almaty_loyalty_d3b07384_gold",
  "store_id": "store_almaty_alatau_01",
  "total_amount_kzt": 1440.75
}

4.2. Входящий сетевой ответ от API-шлюза бэкенда (Выходные параметры из сети для Метода 16)

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 43

{"status":"SUCCESS","message":"Receipt processed"}

5. ЗАДАЧА ДЛЯ РАЗРАБОТЧИКА: BACKEND

Заголовок: Реализация неблокирующего сетевого конвейера отправки транзакций execute_pipeline

5.1. Что нужно сделать

Написать Java-класс NetworkPipelineExecutor в пакете simulation.engine.net и пометить его аннотацией @Component.
Внедрить в класс Spring RestClient (или WebClient), настроенный на базовый URL-адрес контейнера бэкенда из файла конфигурации (\${app.backend.url}).
Написать метод executePipeline, принимающий объект данных payload и перечисление ScenarioEnum.
Реализовать маппинг роутинга: если сценарий равен BUY -> отправлять на эндпоинт /api/v1/webhooks/stores/receipt, если COOK -> на /api/v1/fridge/recipes/cook, если CONSUME -> на /api/v1/fridge/products/consume.
Из текущего контекста потока извлечь сохраненную строку MDC.get("X-Request-ID") и принудительно подставить её в заголовок HTTP-запроса X-Request-ID. Дополнительно прокидывать секретный токен авторизации магазина из настроек.
Выполнять синхронный вызов .post().body(payload).retrieve().toBodilessEntity(). Если бэкенд возвращает статус отличный от семейства 2xx (например, 400, 422, 500), выбрасывать контролируемое исключение NetworkPipelineException для аварийной изоляции такта.

6. ЗАДАЧА ДЛЯ РАЗРАБОТЧИКА: МИГРАЦИЯ

Заголовок: Конфигурация таймаутов пула сетевых соединений HTTP-клиента в Docker-сети симулятора

6.1. Что нужно сделать

Чтобы при шквальной нагрузке от 1500 одновременных виртуальных потоков симулятора сетевой клиент не удерживал соединения бесконечно долго при зависаниях бэкенда (что мгновенно привело бы к исчерпанию лимитов дескрипторов ОС контейнера Docker), необходимо жестко ограничить таймауты подключения и чтения на уровне конфигурации фабрики HTTP-клиента (ClientHttpRequestFactory). Данная задача относится к категории миграции инфраструктурных настроек приложения (Configuration Migration).

Внедрить конфигурационный бин настройки пула соединений в класс сетевой конфигурации:

// Установка жестких лимитов сетевого ожидания во избежание зависания Loom потоков
SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setConnectTimeout(2000); // Лимит ожидания соединения с API-шлюзом: 2 секунды
factory.setReadTimeout(5000);    // Лимит ожидания ответа ACID-транзакции бэкенда: 5 секунд