Долгие и большие операции интеграций — асинхронно

Директивный

v8std#std642 диагностикаTimeoutsInExternalResources

Правило

Внешний вызов, который может выполняться долго (отправка письма, обмен, upload), не блокирует ответ синхронного HTTP-сервиса: тяжёлую работу выносим в фоновое задание, а сервис быстро отвечает 200. Размер передаваемых пакетов ограничивать; объёмные и потоковые сценарии не гонять синхронным запросом.

Бюджеты времени и объёма, от которых считать:

Граница	Значение	Откуда
Порог выноса в фон	~8 с	дольше — пользователь/клиент сервиса «висит», v8std #std642
Синхронный запрос через веб-публикацию	300 с, жёстко	таймаут веб-сервера, подтверждён инцидентом
Размер тела запроса	лимит WAF (у нас 256 МБ, не поднимаем)	тела больше — чанками или не через веб-канал

Зачем

Синхронный вызов связывает три таймаута в одну цепочку: пока сервис ждёт внешнюю систему, его самого ждёт веб-сервер, а веб-сервер — клиент. Рвётся цепочка в самом неожиданном месте: клиент получает 403/обрыв от WAF, хотя 1С «ещё работает», ретраит запрос — и тяжёлая операция запускается второй раз параллельно первой. Фоновое задание разрывает цепочку: сервис отвечает быстро, долгая работа идёт в своём темпе, а повторная доставка гасится идемпотентностью.

Правильно

Асинхронный контракт для клиента: принять запрос → поставить фоновое задание → сразу ответить с идентификатором; статус — отдельным методом.

flowchart LR
    A[POST /export] --> B[Поставить фоновое задание]
    B --> C[Ответ 202 + ИдЗадания]
    C --> D[GET /export-status/ИдЗадания]
    D -->|выполняется| D
    D -->|готово| E[Ссылка на результат]

// HTTP-сервис ставит фоновое задание и сразу отвечает 200.
Параметры = Новый Массив;
Параметры.Добавить(ДанныеЗапроса);
ДлительныеОперации.ВыполнитьВФоне("Обмен.ОтправитьПакет", Параметры, ...);
Ответ = Новый HTTPСервисОтвет(200);
Возврат Ответ;

// Синхронная отправка большого пакета — упирается в таймаут 300с / лимит WAF.
Обмен.ОтправитьПакетСинхронно(ДанныеЗапроса); // может длиться минуты
Возврат Новый HTTPСервисОтвет(200);

Фоновое задание при этом отвечает за свою половину контракта: итог (успех или ошибка с причиной) пишется в ЖР — «ушло в фон и пропало» не диагностируется (см. обработка ошибок и логирование).

Пример из практики

Два подтверждённых инцидента:

2FA. SMTP-отправка кода подтверждения вынесена в фоновое задание: синхронно платформа отдавала «Ошибка соединения с поставщиком» из-за таймаута провайдера. HTTP-сервис отвечает 200 OK сразу, сам код 2FA не логируется.
Большие пакеты ЭДО. Пакеты больше 20 МБ периодически падали с 403/Forbidden — на разборе подтвердился таймаут 300 секунд на синхронные запросы через веб-публикацию. Лимит тела на WAF подняли до 256 МБ, но дальше не увеличивают: тяжёлые сценарии уходят с тонкого веб-канала (RDS/серверный сценарий), а не расширяют его.

Когда не применять

Гарантированно быстрые операции (единичная запись, короткий запрос) выносить в фон не нужно — это усложняет код без выгоды. Порог — риск превысить ~8 секунд.

См. также

WAF перед 1С и служебные пути