Как интегрировать систему, у которой нет готового модуля для 1С

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

Отсутствие готового модуля не закрывает интеграцию, если у систем есть доступный интерфейс, согласованный формат, драйвер или другая точка обмена. 1С может принимать входящие запросы через HTTP-сервис или OData, выполнять исходящие HTTP-запросы, работать с SOAP и файлами, а для специальных сценариев использовать внешнюю компоненту либо COM в совместимом окружении. Способ выбирают по возможностям обеих сторон, нагрузке и требованиям к доставке [1][2][3].

В чём проблема

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

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

Простое объяснение: из чего вообще состоит интеграция с 1С

Когда говорят «нет готового модуля», обычно имеют в виду отсутствие уже написанной обработки или расширения, которое можно установить и сразу пользоваться. Но платформа «1С:Предприятие» с версии 8.2–8.3 сама по себе умеет:

• принимать HTTP-запросы и отвечать на них (HTTP-сервисы, REST);
• отдавать данные через готовый OData-интерфейс без написания кода для каждого объекта;
• работать по протоколу SOAP (веб-сервисы);
• обращаться к внешним программам по COM, вызывать функции внешних библиотек через технологию внешних компонент;
• читать и писать файлы обмена в форматах XML — как в собственных, так и в отраслевых стандартах вроде CommerceML и EnterpriseData.

Задача разработчика — выбрать из этого набора подходящий инструмент под конкретную внешнюю систему и написать код, который сопоставит данные 1С (справочники, документы, регистры) со структурами внешнего API. Готового модуля нет — но есть строительные блоки, из которых модуль собирается под задачу.

Как это работает технически

HTTP-сервисы: 1С как поставщик или потребитель REST

HTTP-сервисы — основной инструмент, если внешняя система работает по REST и отдаёт JSON или XML. Разработчик описывает в конфигураторе шаблоны URL и методы (GET, POST, PUT, DELETE), а внутри каждого метода пишет код на встроенном языке 1С, который обрабатывает тело запроса, обращается к базе и формирует ответ — этот механизм отдельно описан в главе про интернет-технологии и разработку HTTP-сервисов в технической документации платформы [2]. Так работает и приём данных извне (внешняя система стучится в 1С), и обратная схема — 1С сама обращается к внешнему REST API как клиент, используя объект встроенного языка HTTPСоединение.

Именно так на практике решают задачи, для которых нет типового модуля: например, при интеграции с сервисом аренды онлайн-кассы разработчики создавали собственные HTTP-сервисы для двустороннего обмена данными о заказе и статусе фискализации — данные о товарах передавались в 1С через http-сервис, на их основании создавался документ, а после оплаты в 1С возвращались сведения о фискализации чека [4]. Перед началом разработки такого обмена стоит подготовить документацию по будущему API — описать методы, форматы запросов и ответов, обязательные поля и коды ошибок, а не проектировать интерфейс «по ходу»: такая документация с описанием эндпоинтов и методов облегчает и саму разработку HTTP-сервиса, и его дальнейшую поддержку [5].

OData: если данные нужны быстро и без написания сервиса под каждый объект

Если задача — просто дать внешней системе доступ на чтение или запись справочников и документов 1С без сложной бизнес-логики, платформа умеет автоматически поднимать REST-интерфейс по стандарту OData, через который внешние приложения могут обращаться к справочникам и документам по URL-запросам, получая и выгружая данные в форматах JSON или XML [6]. Состав доступных объектов настраивается через специальную обработку или программно, методом УстановитьСоставСтандартногоИнтерфейсаOData, а получить текущий список объектов можно функцией ПолучитьСоставСтандартногоИнтерфейсаOData [6]. Публикация OData требует веб-сервера — Apache или IIS, без которого поднять REST-интерфейс над базой не получится [7]. OData хорошо подходит для BI-систем и аналитики, но для сложных сценариев с проверками и преобразованием данных обычно всё равно нужен отдельный HTTP-сервис с собственной логикой.

Веб-сервисы (SOAP) — для систем с XML-контрактом

Некоторые корпоративные системы, банковские шлюзы и государственные сервисы всё ещё работают по SOAP с WSDL-описанием контракта. Для этого в 1С есть отдельный механизм веб-сервисов, который платформа поддерживает с версии 8.2 — этому механизму посвящена отдельная глава руководства разработчика «Механизм Web-сервисов» [8]. Здесь 1С может выступать и провайдером, публикующим WSDL, и клиентом, который обращается к чужому SOAP-сервису по готовому описанию.

Внешние компоненты и COM — когда нужен доступ к оборудованию или низкоуровневым библиотекам

Для драйвера оборудования или специализированной библиотеки применяют внешнюю компоненту по Native API. COM-соединение — другой механизм: оно доступно в подходящем Windows-окружении с установленной платформой и позволяет сторонней программе открыть информационную базу. Возможность вызова из Python или другого языка зависит от окружения, разрядности, прав запуска и установленного COM-компонента.

Файловый обмен и отраслевые форматы

Если система умеет только принимать или отдавать файлы (например, выгрузку раз в сутки), используют обмен через XML. Здесь есть смысл проверить, не подходит ли готовый отраслевой стандарт вместо изобретения собственного формата: CommerceML — стандарт для обмена каталогами, ценами и заказами, разработанный ещё в 2000 году «1С» совместно с Extra.RU при поддержке технических специалистов представительства Microsoft в России [9], а более новый формат EnterpriseData ориентирован на обмен именно бизнес-сущностями между разнородными системами автоматизации бизнеса независимо от того, кто их разработал и для какой сферы деятельности они предназначены [10]. Обмен в формате EnterpriseData построен на сообщениях из двух секций: заголовок содержит сообщение-квитанцию о синхронизации (Confirmation), а тело — информацию об изменённых бизнес-сущностях [11], что снижает объём передаваемых данных за счёт передачи только изменений с прошлой синхронизации.

Очереди сообщений и интеграционная шина — если систем много и обмен должен быть надёжным

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

Что учитывать в российских условиях

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

Публикация базы в интернете. Чтобы внешняя система вообще могла достучаться до HTTP-сервиса, OData или веб-сервиса 1С, базу нужно опубликовать на веб-сервере (Apache или IIS) и открыть доступ снаружи — это отдельная задача информационной безопасности: нужен HTTPS, ограничение по IP или токену, отдельный технический пользователь с минимально необходимыми правами, а не полными правами администратора.

Госсистемы и маркированные операции. Если интеграция затрагивает документы, для которых в РФ обязательна электронная подпись, обмен через систему «Честный знак», передачу фискальных данных или работу с ГИС, у внешнего сервиса могут быть отдельные требования к сертификации, форматам подписи и порядку регистрации — это нужно уточнять по документации конкретного государственного сервиса до начала разработки, а не закладывать по аналогии с коммерческими API.

Какие есть варианты реализации

Подходы можно сочетать: например, проводить оперативные команды через HTTP, а контрольную сверку — периодическим файлом.

Практические этапы разработки

1. Изучить API или формат внешней системы. Уточнить: нужна ли регистрация и заключение договора для доступа к API, есть ли тестовая (песочница) среда, какие операции доступны технически, а какие — только по отдельному согласованию, требуется ли электронная подпись для части операций.
2. Спроектировать сопоставление данных. Определить, какие справочники, документы и реквизиты 1С соответствуют сущностям внешней системы, как обрабатывать несовпадения (например, разные единицы измерения или структуры адресов).
3. Выбрать протокол и направление обмена. Кто инициирует обмен — 1С или внешняя система, нужен ли обмен в реальном времени или достаточно периодической синхронизации.
4. Реализовать авторизацию. Токен, API-ключ, OAuth, сертификат — способ зависит от требований внешнего сервиса; для 1С как провайдера — создать отдельного технического пользователя с ограниченными правами.
5. Продумать обработку ошибок. Что произойдёт при недоступности внешней системы, при частичном сбое передачи, при дублирующихся запросах — нужна очередь или журнал с возможностью повторной отправки.
6. Протестировать в песочнице. Проверить сценарии с реальными объёмами данных, граничные случаи, скорость обработки.
7. Настроить мониторинг и логирование. Отдельный журнал обмена, оповещения при сбоях — без этого проблемы с интеграцией обнаруживаются постфактум, когда данные в двух системах уже разошлись.
8. Подготовить к запуску в промышленной эксплуатации. Убедиться, что публикация базы защищена, лицензий достаточно, а нагрузка от внешних обращений не мешает работе обычных пользователей.

Ограничения, ошибки и риски

Даже когда штатные механизмы 1С покрывают задачу технически, на практике проекты без готового модуля чаще всего спотыкаются на одном и том же:

• Отсутствие документации по будущему API до начала разработки — команда начинает писать код, ориентируясь на догадки, а не на согласованный контракт, и переделывает интерфейс несколько раз.
• Игнорирование обработки ошибок и повторов. Прямой синхронный обмен без очереди означает, что сбой сети или падение одной из систем может привести к потере или задвоению данных — именно это и вынуждало дорабатывать интеграции регистром очереди уже после того, как база начинала регулярно падать под нагрузкой от внешних запросов.
• Излишние права у технического пользователя. Учётная запись для внешнего обмена с полными правами администратора — типичная брешь безопасности, которую проще предотвратить на этапе проектирования, чем закрывать потом.
• Недооценка лицензирования. Требования зависят от режима работы платформы, числа и типа сеансов, используемых компонентов и выбранной архитектуры. Их проверяют по действующему лицензионному руководству и договору для конкретного контура до расчёта инфраструктуры.
• Расчёт на общедоступность API. Наличие технической документации по API ещё не означает, что доступ открыт всем желающим — нередко требуется договор, согласование или отдельная процедура подключения, которую нужно выяснить заранее, а не в процессе разработки.
• Отсутствие тестовой среды при интеграции. Разработка и первые тесты сразу на «боевых» данных повышают риск испортить рабочую базу или отправить некорректные данные во внешнюю систему.

Как выбрать подход для своей задачи

Способ выбирают по возможностям внешней системы и требованиям процесса. HTTP подходит для оперативных команд при наличии устойчивого API, OData — для типовых операций с опубликованными объектами, SOAP — для WSDL-контракта, а файлы — для пакетного обмена. Очередь или шина оправдана, когда нужны гарантии доставки, управляемые повторы, маршрутизация, преобразование форматов и единая наблюдаемость. Само количество систем не определяет архитектуру.

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

Как может помочь «Пятый фактор»

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

Вывод

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

Источники

[1] v8.1c.ru — HTTP-сервисы | Интеграция — платформа 1С:Предприятие — https://v8.1c.ru/platforma/http-servisy/

[2] its.1c.ru — Разработка HTTP-сервиса :: Технологии интеграции "1С:Предприятия 8.3" — https://its.1c.ru/db/intgr83/content/30/hdoc

[3] v8.1c.ru — Технология внешних компонентов | Интеграция — платформа 1С:Предприятие — https://v8.1c.ru/platforma/tehnologiya-vneshnih-komponentov/

[4] intervolga.ru — Интеграция 1С с облачными кассами: как настроить онлайн-чеки по 54-ФЗ — https://www.intervolga.ru/blog/1C/oblachnye-kassy-i-1s-integratsiya-kotoroy-ne-bylo/

[5] is1c.ru — Первое знакомство с HTTP-сервисами в 1С — «ИнфоСофт» — https://is1c.ru/about/pc/article/pervoe-znakomstvo-s-http-servisami-v-1s/

[6] denvic.tech — Протокол OData: интеграция данных 1С с помощью протокола OData и экстрактора данных — https://denvic.tech/blog/ekspertnye-stati/protokol-odata-rabota-s-dannymi-1s-tsennosti-za-porogom-sovremennykh-resheniy-/

[7] sayfocus.me — OData в 1С: публикация REST и работа с документами — https://sayfocus.me/blog/ru/1c-odata-rest-guide.html

[8] its.1c.ru — Глава 17. Механизм Web-сервисов :: Руководство разработчика :: 1С:Предприятие 8.2 — https://its.1c.ru/db/content/v8doc/src/документация/руководство%20разработчика/глава%2017.%20механизм%20web-сервисов.htm

[9] v8.1c.ru — Стандарты CommerceML | Стандарты и форматы, Обмен данными и интеграция — https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/standarty-commerceml/

[10] v8.1c.ru — Новый формат обмена бизнес-данными EnterpriseData от 1С расширяет возможности интеграции — https://v8.1c.ru/news/13002.htm

[11] v8.1c.ru — Формат EnterpriseData | Стандарты и форматы, Обмен данными и интеграция — https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/format-enterprisedata/

[12] its.1c.ru — Пример 2. Интеграция с брокером сообщений RabbitMQ :: 1С:Шина. Руководство разработчика — https://its.1c.ru/db/esbdoc3/content/797/hdoc

[13] wiseadvice-it.ru — Правильная интеграция: использование Mule ESB и RabbitMQ с 1С — https://wiseadvice-it.ru/o-kompanii/blog/articles/pravilnaya-integraciya-ispolzovanie-mule-esb-i-rabbitmq-s-1s/

[14] rarus.ru — Выделенный сервер лицензирования «1C» — https://rarus.ru/publications/20161205-vydelennyy-server-litsenzirovaniya-1c-646656/

[15] habr.com — «Лицензии должны быть по запросу!»: поднимаем сервер лицензирования 1С в облаке — https://habr.com/ru/companies/selectel/articles/791470/