Как настроить обмен данными между 1С и внешними системами

Интеграцию с 1С часто сводят к «нужен REST API» — и упираются в программиста там, где хватило бы готового обмена или выгрузки в файл. Метод выбирают не по моде, а по задаче: кто кого инициирует, как часто идёт обмен и каков объём данных. Иногда это загрузка прайса раз в сутки, иногда — моментальная передача заказа с сайта в учётную систему.

Разберём рабочие способы связать 1С с сайтом, CRM и маркетплейсом: файловый обмен, HTTP-сервисы, OData, COM-соединение и типовые механизмы платформы. Для каждого — где он уместен, как настроить и чем ограничен. Всё описано для платформы 8.3 с интерфейсом «Такси».

С чего начать: как выбрать метод обмена

Первый вопрос — направление и инициатор обмена. Если внешняя система сама забирает данные из 1С по расписанию, подойдёт OData или веб-сервис. Если 1С должна отдавать данные по запросу извне в произвольном формате — HTTP-сервис. Для разовых и регламентных выгрузок между своими базами — планы обмена и файлы.

Сравним основные варианты:

Второй вопрос — сопоставление данных. Какое поле во внешней системе соответствует какому реквизиту в 1С. Это сопоставление придётся продумать для любого метода:

Чёткое сопоставление полей на старте экономит недели правок потом: без него цены приедут не в тот регистр, а заказы задвоятся по неверному ключу.

Настройка HTTP-сервиса и его публикация

HTTP-сервис — самый гибкий способ отдавать и принимать данные по сети в произвольном формате (обычно JSON). Он состоит из двух частей: объекта метаданных в конфигурации и публикации на веб-сервере.

В Конфигураторе откройте дерево конфигурации, найдите ветку HTTP-сервисы и добавьте новый объект. У сервиса задаётся корневой URL. Внутри создаются шаблоны URL (например /orders/{id}) и методы — GET, POST, PUT, DELETE. Каждому методу назначается функция-обработчик в модуле сервиса.

Обработчик получает объект запроса и возвращает объект ответа. Упрощённо логика приёма заказа выглядит так:

Функция ЗаказыPOST(Запрос)
    ТелоЗапроса = Запрос.ПолучитьТелоКакСтроку();
    Данные = ПрочитатьJSON(ТелоЗапроса);
    // ... создание и запись документа по данным ...
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки("{""status"":""ok""}");
    Возврат Ответ;
КонецФункции

Чтобы сервис стал доступен снаружи, его надо опубликовать. Для публикации обязателен веб-сервер — Apache или IIS на том же компьютере, где доступна платформа. Без веб-сервера HTTP-сервис работать не будет.

Пошагово:

1. Установите веб-сервер (Apache или IIS) и модуль расширения веб-сервера из поставки платформы.
2. В Конфигураторе выберите Администрирование → Публикация на веб-сервере.
3. Укажите имя публикации (станет частью URL), каталог и выбранный веб-сервер.
4. На вкладке HTTP-сервисов отметьте флажком те, что нужно опубликовать.
5. Нажмите «Опубликовать» и перезапустите веб-сервер, если система попросит.

После этого сервис доступен по адресу вида http://сервер/имя_публикации/hs/корневой_url/метод. Проверьте его любым клиентом — например, отправьте тестовый запрос из Postman или curl.

Готовые обмены: когда программировать не нужно

Прежде чем писать код, проверьте, нет ли готового механизма. В типовых конфигурациях многое уже встроено.

Обмен с сайтом по CommerceML. В «1С:Управление торговлей» и «1С:Бухгалтерия» есть выгрузка каталога и загрузка заказов в формате CommerceML 2. Это стандарт, который понимают 1С-Битрикс и большинство популярных CMS. Настройка — в разделе обмена с сайтом: указываете адрес, логин, пароль и расписание. Программирование не требуется.

Синхронизация между конфигурациями 1С. Обмен БП ↔ УТ, УТ ↔ ЗУП и подобные настраиваются через механизм синхронизации данных на формате EnterpriseData. Путь — Администрирование → Синхронизация данных (раздел может называться похоже в зависимости от конфигурации). Выбираете вид обмена, указываете вторую базу или папку и правила. Платформа сама отслеживает изменения через планы обмена.

Коннекторы маркетплейсов. Для Wildberries, Ozon и других есть отраслевые решения и расширения, которые закрывают обмен заказами и остатками без ручного кода. Их стоит рассмотреть до того, как браться за собственный HTTP-сервис.

Отдельно про COM-соединение. Оно связывает 1С с другой программой на том же сервере: внешнее приложение создаёт COM-объект V83.COMConnector и работает с базой напрямую. Чтобы это заработало, компоненту comcntr.dll из каталога платформы регистрируют утилитой regsvr32. Способ живой, но нишевый: для веба и распределённых систем HTTP-сервис почти всегда удобнее и надёжнее.

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

OData и внешние источники данных

OData — стандартный REST-интерфейс платформы. Он позволяет внешней системе читать и записывать данные 1С (справочники, документы, регистры) без единой строки кода на стороне 1С. Данные отдаются в JSON или XML (Atom).

Включается в два шага:

1. В режиме «1С:Предприятие» откройте настройку состава стандартного интерфейса OData и отметьте объекты, которые разрешаете отдавать наружу (платформа начиная с 8.3.5 требует явно выбрать объекты — по умолчанию не отдаётся ничего).
2. В Конфигураторе при публикации на веб-сервере установите флажок «Публиковать стандартный интерфейс OData».

После публикации данные доступны по адресу вида http://сервер/имя_публикации/odata/standard.odata/. Список метаданных отдаётся по суффиксу $metadata, а конкретный справочник — по его имени, например Catalog_Номенклатура.

Отдельная тема — внешние источники данных. Это обратное направление: не наружу из 1С, а внутрь. Через объект «Внешние источники данных» 1С подключается к сторонней СУБД (например, к базе на SQL Server) и работает с её таблицами почти как с обычными объектами конфигурации. Это удобно, когда часть данных живёт вне 1С, а дублировать их в учётную базу не нужно.

Авторизация и безопасность обмена

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

Базовые правила:

• 🔑 Заведите отдельного пользователя для обмена, а не используйте учётную запись живого сотрудника. Так в журнале регистрации видно, что действия выполнил именно обмен, а не человек.
• 🛡 Дайте этому пользователю минимум прав — только на те объекты, которые реально участвуют в обмене. Если внешняя система лишь читает остатки, права на изменение документов ей не нужны.
• 🌐 Публикуйте через HTTPS. Логин и пароль при обычной базовой авторизации передаются в заголовке запроса; без шифрования канала их видно в открытом виде.

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

Пароль пользователя обмена храните в настройках внешней системы, а не в коде конфигурации. При смене пароля не придётся пересобирать и обновлять базу.

Обработка ошибок и журнал обмена

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

Попытка
    Соединение = Новый HTTPСоединение(Адрес, Порт, , , , Таймаут);
    Ответ = Соединение.Получить(Запрос);
Исключение
    ЗаписьЖурналаРегистрации("Обмен.Сайт",
        УровеньЖурналаРегистрации.Ошибка, , ,
        ИнформацияОбОшибке().Описание);
    Возврат Ложь;
КонецПопытки;

Что обязательно учесть:

• 📝 Логируйте каждый обмен через ЗаписьЖурналаРегистрации. Укажите своё событие (например Обмен.Сайт) — потом по нему легко отфильтровать записи в журнале регистрации.
• ⏱ Ставьте таймаут на HTTP-соединение. Без него зависший ответ сервера заблокирует фоновое задание до бесконечности.
• 🔁 Проверяйте код ответа. Код 200 — успех, 4xx — ошибка в вашем запросе, 5xx — проблема на стороне внешней системы. На 5xx имеет смысл повторить попытку позже, на 4xx — нет, пока не исправите запрос.
• 📦 Сохраняйте «сырой» ответ при ошибке разбора. Если ПрочитатьJSON упал, текст ответа в логе покажет, что реально прислал сервер.

Журнал регистрации открывается в режиме «1С:Предприятие» через Главное меню → Все функции → Журнал регистрации или в типовых конфигурациях через раздел администрирования. Отбор по вашему событию и уровню «Ошибка» сразу покажет, где и когда сломался обмен.

Что делать при больших объёмах данных

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

Передавайте данные порциями. Не грузите 50 000 товаров одним пакетом. Разбейте на части по несколько сотен-тысяч строк и обрабатывайте последовательно. Это снижает пиковую нагрузку на память и позволяет продолжить с места обрыва.

Используйте регистрацию изменений. Планы обмена фиксируют, какие объекты поменялись с прошлой синхронизации. Тогда в следующий раз передаются только изменённые данные, а не весь справочник. Это главный способ ускорить регулярный обмен.

Выносите обмен в фоновое задание. Длительную выгрузку запускайте фоновым заданием, а не в клиентском сеансе. Пользователь не будет ждать, а операция не оборвётся по таймауту интерфейса.

Не держите одну гигантскую транзакцию. Запись десятков тысяч объектов в единой транзакции блокирует таблицы и раздувает журнал. Пишите пачками с фиксацией промежуточных результатов.

Если обмен всё равно идёт медленно, смотрите, не тянете ли вы лишние данные: часто в выгрузку по привычке включают реквизиты, которые внешней системе не нужны.

Частые вопросы