Главное

У 1С три рабочих интерфейса наружу: OData, HTTP-сервисы и планы обмена. Выбор зависит от задачи, а не от привычки подрядчика.
OData - самый быстрый старт, но публиковать его «как есть» нельзя: ограничьте состав объектов и заведите отдельного сервисного пользователя.
HTTP-сервисы 1С безопаснее: наружу торчит только нужный метод с версионируемым контрактом и валидацией на входе.
Обмен между 1С и остальными системами ведите через шину (n8n / Datareon), а не точка-точка: повторная доставка, идемпотентность и мониторинг живут в одном месте.
Обновление 1С меняет один адаптер на шине, а не десяток парных интеграций.

Почему интеграция с 1С - отдельная дисциплина

Конфигурации 1С почти никогда не работают «из коробки»: каждая компания дорабатывает справочники, документы и обработки под свои процессы, поэтому структура данных в каждой 1С уникальна.
При этом 1С регулярно выпускает релизы: поля переименовываются, справочники разделяются и объединяются.
Отсюда закон: любая интеграция, завязанная на внутреннюю структуру конкретной конфигурации, ломается при очередном обновлении.
Задача архитектора - выбрать интерфейс, который переживает релизы, и транспорт, который не размножает парные связи.
Ниже - три способа отдать данные из 1С и правило, как их сочетать.

Способ 1. OData: стандартный интерфейс, быстрый старт

«1С:Предприятие» начиная с версии 8.3.5 умеет отдавать стандартный REST-интерфейс по протоколу OData: чтение, добавление, обновление и удаление данных HTTP-запросами, ответы в XML или JSON.
Интерфейс включается в настройках публикации на веб-сервере - писать код на стороне 1С не нужно, поэтому это самый быстрый способ подключить 1С к шине или внешней системе.
Скорость - сильная сторона OData и одновременно его риск: по умолчанию легко опубликовать наружу больше, чем требуется задаче.
Права доступа настраиваются обязательно, это не опция.

Безопасность публикации OData - обязательный минимум

Ограничьте состав публикуемых объектов: в 1С есть настройка состава стандартного интерфейса OData - наружу отдаются только нужные справочники и документы, а не вся конфигурация.
Заведите отдельного сервисного пользователя для интеграции с минимальными правами именно на эти объекты. Учётная запись администратора для обмена не используется.
Публикуйте только по HTTPS и закрывайте доступ на уровне периметра: VPN или список адресов, с которых ходит шина.
Логируйте обращения и ограничивайте объём выборок: полная выгрузка больших справочников через OData нагружает рабочую базу.

Способ 2. HTTP-сервисы 1С: узкий контракт под задачу

HTTP-сервис - это метод, который разработчик описывает в конфигурации 1

С под конкретную операцию: «отдать остатки по складу»

, «принять заказ», «подтвердить отгрузку»

Наружу торчит только этот метод, а не модель данных. Механизм безопасности здесь сильнее, чем у OData: контракт узкий и версионируемый, вход валидируется кодом сервиса до записи в базу, а права сервисного пользователя ограничены одной операцией. Результат - предсказуемая цена изменения: пока контракт метода сохраняется, обновления конфигурации не ломают потребителей. Плата за это - разработка на стороне 1С, поэтому старт дороже, чем с OData.

Способ 3. Планы обмена: массовые данные по расписанию

Для больших объёмов и офлайн-сценариев у 1С есть штатные планы обмена и регламентный обмен (формат EnterpriseData, правила конвертации данных).
Так синхронизируют справочники и документы между узлами 1С и выгружают массивы данных по расписанию: ночная синхронизация номенклатуры, перенос документов за период.
Ограничение симметричное: это пакетный механизм.
Для событий в реальном времени - статус заказа, резерв остатка - он не подходит; здесь нужны OData или HTTP-сервисы поверх шины.

Разобрать ваш контур интеграции

Почта clients@kt.team Telegram @kt_team_blog

Как выбрать способ: сравнение

Способ	Когда брать	Безопасность	Цена изменения
OData	Быстрый старт, чтение и запись типовых объектов	Средняя: обязательны ограничение состава объектов, сервисный пользователь, HTTPS	Средняя: смена структуры объекта в релизе может поменять ответы интерфейса
HTTP-сервисы 1С	Конкретные операции с валидацией и своей логикой	Высокая: наружу только нужный метод с версионируемым контрактом	Низкая: контракт фиксирован, внутренности меняются свободно
Планы обмена	Массовые данные по расписанию, обмен между узлами 1С	Высокая: обмен внутри контура, наружу ничего не публикуется	Средняя: правила конвертации дорабатываются под релизы
Любой способ + шина	Больше двух систем в контуре или планируется рост	Шина добавляет мониторинг, историю сообщений и контроль доступа в одной точке	Низкая: обновление 1С меняет один адаптер на шине	Правило выбора: интерфейс определяется задачей (типовые объекты - OData, критичные операции - HTTP-сервисы, массивы - планы обмена), а транспорт при нескольких системах всегда один - шина.

Контур интеграции 1С через шину

1С отдаёт данные

ODataтиповые объекты

HTTP-сервисыузкие операции

Планы обменамассивы по расписанию

Шина (n8n / Datareon)

Очереди и retryгарантия доставки

Идемпотентностьбез дублей при повторах

Трансформация и мониторингформат получателя, история

Потребители

CRM, WMS, сайтоперационные системы

BI / DWHаналитика

Маркетплейсыцены, остатки, заказы

1С отдаёт данные один раз любым из трёх способов. Повторная доставка, преобразование форматов и мониторинг живут на шине, а не в коде 1С.

Транспорт: шина вместо точка-точка

Интерфейс отвечает на вопрос «как забрать данные из 1С», транспорт - «как доставить их всем, кому нужно». Если систем больше двух, прямые интеграции размножают парные связи, и каждое обновление 1С запускает каскад доработок. Шина (в наших проектах это n8n для лёгких сценариев и Datareon для enterprise-контура с 1С) разрывает эту зависимость: 1С отдаёт данные один раз, шина хранит сообщения, повторяет доставку после сбоев, отбрасывает дубли и преобразует формат под каждого получателя.

Слабая связанность - по данным DORA, один из предикторов скорости и стабильности поставки - перестаёт быть лозунгом и становится свойством контура.