Почему интеграции 1С ломаются не на HTTP‑запросах: очередь, повторы и дубли

[orchanin]

Подскажите, а какой стек у "очередь, статусы, повторы, журнал"? Я правильно понимаю, что это все можно сделать средствами 1С или все-таки нужно разворачивать какую-то локальную инфраструктуру? Какую?

Просто слабо представляю, как делают интеграции для 1С, которые на локальной машине стоят, но очень интересно)

[InsideIT]

В большинстве случаев это можно сделать средствами самой 1С, без отдельной инфраструктуры.

Обычно стек примерно такой: очередь и журнал — регистры сведений, статусы — перечисление, повторы — регламентное задание. При проведении документа не дергаем внешний API, а только регистрируем событие обмена. Дальше фоновое задание забирает очередь и отправляет данные.

Планы обмена тоже можно использовать. Особенно если нужно штатно регистрировать изменения объектов и строить обмен по узлам. Но для интеграций вида «конкретный документ 1С → внешний REST API» мне часто удобнее отдельная очередь, потому что в ней проще хранить HTTP-код, тело запроса/ответа, текст ошибки, количество попыток, ключ идемпотентности и т. д.

Так же, существует 1С:Шина — это уже отдельный интеграционный продукт. Она имеет смысл, когда систем много и нужна централизованная маршрутизация, мониторинг, преобразование сообщений и сопровождение большого интеграционного контура. Для простой связки «1С ↔ внешний API» это обычно избыточно.

По поводу «как делают интеграции для 1С, которые на локальной машине стоят» — тут важно, что имеется в виду. Если это файловая база, которая запускается только когда пользователь открыл 1С, то да, автоматический обмен будет зависеть от запущенного сеанса. Тогда его либо выполняют при открытой базе, либо запускают отдельный сеанс 1С по расписанию через планировщик Windows.

Если же база клиент-серверная, то проблем меньше: регламентные задания выполняются сервером 1С, а очередь хранится в самой информационной базе.

Отдельная инфраструктура нужна не всегда. Чаще всего сначала хватает штатных механизмов 1С, а внешнюю шину или брокер сообщений стоит добавлять уже тогда, когда интеграций становится много и обмены «точка-точка» начинают плохо сопровождаться.

[ANikolaev2]

А если нужно отправить множество запросов из очереди - база высоконагруженная. Не думали реализовать многопоточность?

[InsideIT]

Да, такой вариант возможен, но я бы рассматривал его уже как следующий уровень после базовой очереди.

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

В целом средствами 1С многопоточную обработку реализовать можно: например, несколькими фоновыми/регламентными заданиями, которые разбирают очередь пачками. Но там уже нужно аккуратно делать захват задания, чтобы два обработчика не взяли один и тот же объект, учитывать блокировки, порядок отправки связанных данных и таймауты.

Плюс вопрос не только в 1С. Очень часто ограничение находится на стороне внешней системы: поддерживает ли она параллельные запросы, есть ли rate limit, не важен ли порядок сообщений, что будет при одновременном создании/обновлении связанных объектов. Иногда 1С технически может отправлять быстрее, чем внешний API способен корректно принять.

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