В большинстве случаев это можно сделать средствами самой 1С, без отдельной инфраструктуры.
Обычно стек примерно такой: очередь и журнал — регистры сведений, статусы — перечисление, повторы — регламентное задание. При проведении документа не дергаем внешний API, а только регистрируем событие обмена. Дальше фоновое задание забирает очередь и отправляет данные.
Планы обмена тоже можно использовать. Особенно если нужно штатно регистрировать изменения объектов и строить обмен по узлам. Но для интеграций вида «конкретный документ 1С → внешний REST API» мне часто удобнее отдельная очередь, потому что в ней проще хранить HTTP-код, тело запроса/ответа, текст ошибки, количество попыток, ключ идемпотентности и т. д.
Так же, существует 1С:Шина — это уже отдельный интеграционный продукт. Она имеет смысл, когда систем много и нужна централизованная маршрутизация, мониторинг, преобразование сообщений и сопровождение большого интеграционного контура. Для простой связки «1С ↔ внешний API» это обычно избыточно.
По поводу «как делают интеграции для 1С, которые на локальной машине стоят» — тут важно, что имеется в виду. Если это файловая база, которая запускается только когда пользователь открыл 1С, то да, автоматический обмен будет зависеть от запущенного сеанса. Тогда его либо выполняют при открытой базе, либо запускают отдельный сеанс 1С по расписанию через планировщик Windows.
Если же база клиент-серверная, то проблем меньше: регламентные задания выполняются сервером 1С, а очередь хранится в самой информационной базе.
Отдельная инфраструктура нужна не всегда. Чаще всего сначала хватает штатных механизмов 1С, а внешнюю шину или брокер сообщений стоит добавлять уже тогда, когда интеграций становится много и обмены «точка-точка» начинают плохо сопровождаться.
В большинстве случаев это можно сделать средствами самой 1С, без отдельной инфраструктуры.
Обычно стек примерно такой: очередь и журнал — регистры сведений, статусы — перечисление, повторы — регламентное задание. При проведении документа не дергаем внешний API, а только регистрируем событие обмена. Дальше фоновое задание забирает очередь и отправляет данные.
Планы обмена тоже можно использовать. Особенно если нужно штатно регистрировать изменения объектов и строить обмен по узлам. Но для интеграций вида «конкретный документ 1С → внешний REST API» мне часто удобнее отдельная очередь, потому что в ней проще хранить HTTP-код, тело запроса/ответа, текст ошибки, количество попыток, ключ идемпотентности и т. д.
Так же, существует 1С:Шина — это уже отдельный интеграционный продукт. Она имеет смысл, когда систем много и нужна централизованная маршрутизация, мониторинг, преобразование сообщений и сопровождение большого интеграционного контура. Для простой связки «1С ↔ внешний API» это обычно избыточно.
По поводу «как делают интеграции для 1С, которые на локальной машине стоят» — тут важно, что имеется в виду. Если это файловая база, которая запускается только когда пользователь открыл 1С, то да, автоматический обмен будет зависеть от запущенного сеанса. Тогда его либо выполняют при открытой базе, либо запускают отдельный сеанс 1С по расписанию через планировщик Windows.
Если же база клиент-серверная, то проблем меньше: регламентные задания выполняются сервером 1С, а очередь хранится в самой информационной базе.
Отдельная инфраструктура нужна не всегда. Чаще всего сначала хватает штатных механизмов 1С, а внешнюю шину или брокер сообщений стоит добавлять уже тогда, когда интеграций становится много и обмены «точка-точка» начинают плохо сопровождаться.