Интеграция без COMConnector: HTTP-сервисы, SOAP и OData для серверов 1С на Linux и веб-клиента

COM-соединение в 1С заменяют HTTP-сервисом с обменом в JSON: это стандарт для серверов на Linux, облака и веб-клиента. Если внешняя система умеет только SOAP — публикуют веб-сервис с WSDL. Если нужно просто читать и писать справочники и документы без программирования — включают стандартный интерфейс OData.

Частое заблуждение — что COM «отключили» в новых релизах платформы. Нет, V83.COMConnector по-прежнему работает, но только на Windows. На Linux-сервере, в контейнере, у облачного провайдера и в веб-клиенте COM-технологии нет как класса, поэтому любой код с Новый COMОбъект(...) там падает. Замена — не одна функция, а смена подхода: вместо «залезть в чужую базу и пройтись по объектам» — «попросить базу отдать готовый ответ по сети».

Почему COM-соединение 1С не переживает переход на Linux и в облако

COM (Component Object Model) — технология Microsoft. Она живёт в реестре Windows, в DCOM-настройках и в установленных библиотеках. На Linux её нет, и платформа 1С не эмулирует её.

Что именно перестаёт работать:

• 🔌 Внешнее соединение V83.COMConnector — подключение одной базы 1С к другой или скрипта (Python, PowerShell, VBScript) к базе.
• 📊 OLE-автоматизация офиса — Новый COMОбъект("Excel.Application"), Word.Application. На сервере Linux Excel нет в принципе.
• 🖥 COM-объекты в веб-клиенте — браузер не даёт странице создавать объекты Windows.
• 🧩 Внешние компоненты по технологии COM (старые ActiveX-драйверы оборудования) — на Linux не загружаются.
• 🗂 Сторонние COM-библиотеки — WScript.Shell, Scripting.FileSystemObject, MSXML и прочее.

У COM были и свои проблемы даже на Windows. Каждый вызов свойства — это межпроцессное обращение. Версия COMConnector должна совпадать с версией платформы сервера, после обновления её перерегистрируют через regsvr32. Утечки соединений держат сеансы и лицензии. Из-за этого переход на сетевые интерфейсы полезен и тем, кто остаётся на Windows.

HTTP-сервисы 1С как основная замена COM-соединения

HTTP-сервис — объект конфигурации в ветке Общие → HTTP-сервисы. У него есть корневой URL, шаблоны адресов и методы (GET, POST, PUT, DELETE). Каждому методу соответствует функция в модуле сервиса. Внешняя система отправляет обычный HTTP-запрос и получает ответ — обычно JSON.

Адрес вызова строится так: https://<сервер>/<имя публикации>/hs/<корневой URL>/<шаблон>. Например, https://erp.example.ru/trade/hs/stock/v1/items/A-100.

Как создать HTTP-сервис: порядок действий

1. Если конфигурация типовая — создайте расширение, чтобы не снимать её с поддержки. HTTP-сервисы можно добавлять в расширение.
2. В ветке HTTP-сервисы добавьте сервис, задайте корневой URL, например stock.
3. Добавьте шаблон URL /v1/items/{article} — фигурные скобки задают параметр.
4. В шаблоне добавьте метод GET и создайте для него обработчик.
5. Напишите код обработчика (пример ниже).
6. Создайте пользователя 1С с ограниченной ролью только на нужные данные — от его имени будут выполняться запросы.
7. Опубликуйте базу на веб-сервере с включёнными HTTP-сервисами.

Пример обработчика с ответом в JSON

Функция ОстаткиGET(Запрос)

    Артикул = Запрос.ПараметрыURL.Получить("article");

    Данные = Новый Структура;
    Данные.Вставить("article", Артикул);
    Данные.Вставить("quantity", ПолучитьОстаток(Артикул)); // ваша серверная функция

    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Данные);
    ТекстJSON = Запись.Закрыть();

    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(ТекстJSON);
    Возврат Ответ;

КонецФункции

Вызов из другой базы 1С вместо COMConnector

Раньше вторая база открывала COM-соединение и читала регистр напрямую. Теперь она делает запрос:

Защита = Новый ЗащищенноеСоединениеOpenSSL;
Соединение = Новый HTTPСоединение("erp.example.ru", 443, "integration", Пароль, , 30, Защита);
Запрос = Новый HTTPЗапрос("/trade/hs/stock/v1/items/A-100");
Ответ = Соединение.Получить(Запрос);

Если Ответ.КодСостояния = 200 Тогда
    Чтение = Новый ЧтениеJSON;
    Чтение.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
    Данные = ПрочитатьJSON(Чтение);
    Чтение.Закрыть();
    Остаток = Данные.quantity;
Иначе
    ВызватьИсключение СтрШаблон("Сервис остатков вернул код %1", Ответ.КодСостояния);
КонецЕсли;

Код выполняйте на сервере: HTTPСоединение работает и в серверном контексте Linux. Тайм-аут в 30 секунд защищает от зависания, если сервис недоступен.

SOAP-веб-сервисы: когда внешняя система требует WSDL

Веб-сервис (Общие → Web-сервисы) — старший брат HTTP-сервиса. Он описывает операции и типы данных в WSDL, и клиент получает строгий контракт. Это удобно для корпоративных шин, банковских систем, Java- и .NET-приложений, где интеграторы генерируют клиентский код по WSDL.

Описание сервиса после публикации доступно по адресу https://<сервер>/<публикация>/ws/<имя>?wsdl. Из другой базы 1С веб-сервис вызывают через WSОпределения и WSПрокси.

Когда выбирать SOAP, а когда HTTP:

Если внешней стороне всё равно — берите HTTP-сервис. SOAP оставьте для случаев, когда WSDL прописан в техническом задании.

OData, внешние обработки и расширения: чем ещё заменить COM-объекты

HTTP и SOAP закрывают большинство сценариев, но не все. Ниже — инструменты для остальных задач, которые раньше решали через COM.

Стандартный интерфейс OData

Платформа умеет отдавать объекты базы по протоколу OData без написания кода: справочники, документы, регистры. Адрес — https://<сервер>/<публикация>/odata/standard.odata/. Сначала нужно задать состав интерфейса — какие объекты открыты. В типовых конфигурациях на БСП для этого есть служебная обработка настройки стандартного интерфейса OData в разделе Администрирование. Программно состав задаёт метод УстановитьСоставСтандартногоИнтерфейсаOData().

OData хорош, когда внешняя система — Power BI, Excel через Power Query или скрипт аналитика — просто читает таблицы. Бизнес-логику (проверки, проведение по своим правилам) лучше держать в HTTP-сервисе.

Расширения и внешние обработки вместо «удалённого запуска кода»

Через COM часто запускали произвольный код в чужой базе. Корректная замена:

• 🧩 Расширение конфигурации с HTTP-сервисом и нужной логикой — код хранится в базе, обновляется вместе с ней.
• ⏱ Регламентное задание — для того, что раньше запускал планировщик Windows через COM по ночам.
• ⚙️ Пакетный запуск клиента с параметром /Execute — открыть базу и выполнить внешнюю обработку из командной строки.
• 🛠 Утилита ibcmd — для административных задач (создание базы, выгрузка и загрузка, работа с конфигурацией) без COM и без конфигуратора.

Замена Excel.Application и других офисных COM

Для выгрузки и чтения таблиц офис на сервере не нужен:

• ТабличныйДокумент.Записать(Путь, ТипФайлаТабличногоДокумента.XLSX) — запись в Excel.
• ТабличныйДокумент.Прочитать(Путь) — чтение xlsx в табличный документ.
• ЗаписьXML, ЧтениеXML, ЗаписьJSON, ЧтениеJSON — вместо MSXML и сторонних парсеров.
• ЗаписьТекста, ЧтениеТекста, НайтиФайлы, КопироватьФайл — вместо FileSystemObject.

Внешние компоненты по технологии Native API

Если нужен драйвер оборудования или своя библиотека, используют компоненты Native API. Их собирают отдельно под Windows и Linux, под 32 и 64 разряда, и упаковывают в один ZIP-архив с манифестом. Платформа сама выбирает нужную сборку. COM-компоненты ActiveX на Linux не загрузятся — нужна версия компоненты под Native API от поставщика.

План миграции с COM и сравнение подходов по скорости

Главная причина медленных интеграций на COM — «болтливость». Код вида «открыть справочник, перебрать элементы, у каждого прочитать пять реквизитов» даёт тысячи межпроцессных вызовов. HTTP-сервис отвечает одним пакетом: запрос внутри базы выполняется за один проход, по сети уходит готовый JSON.

Переносить интеграцию с COMConnector удобно в таком порядке:

1. Инвентаризация. Составьте таблицу: где вызов, что читает или пишет, как часто, кто потребитель.
2. Группировка. Объедините похожие вызовы в операции: «получить остатки», «создать заказ», «выгрузить контрагентов».
3. Контракт. Для каждой операции опишите вход и выход в JSON. Договоритесь о кодах ответа: 200 — успех, 400 — ошибка данных, 500 — сбой сервиса.
4. Реализация в расширении. Сервис-поставщик пишет HTTP-сервис, потребитель — вызов через HTTPСоединение.
5. Параллельный режим. Какое-то время держите оба пути и сравнивайте результаты на копии базы.
6. Отключение COM. Удалите старый код и снимите регистрацию comcntr.dll на серверах, где она больше не нужна.

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

Публикация и технические нюансы на Linux

На Linux HTTP-сервисы, веб-сервисы и OData публикуют через Apache с модулем веб-расширения 1С. Публикация делается утилитой webinst из каталога платформы:

sudo /opt/1cv8/x86_64/8.3.xx.xxxx/webinst -publish -apache24 \
  -wsdir trade -dir /var/www/trade \
  -connstr "Srvr=srv1c;Ref=trade;" \
  -confpath /etc/apache2/apache2.conf

Вместо 8.3.xx.xxxx подставьте свою версию платформы — номер каталога должен совпадать с версией сервера 1С. После публикации проверьте файл default.vrd в каталоге публикации: в нём включается публикация HTTP-сервисов, веб-сервисов и OData. Затем перезапустите Apache.

Что ещё отличается на Linux:

• 📁 Регистр имён файлов. Выгрузка.xlsx и выгрузка.xlsx — разные файлы. Код, писавшийся под Windows, часто на этом ломается.
• ➗ Разделитель пути. Не склеивайте пути через "\". Используйте ПолучитьРазделительПутиСервера().
• 👤 Права пользователя службы. Сервер 1С работает от системного пользователя (обычно usr1cv8). Каталоги обмена должны быть доступны ему на запись.
• 🔐 Сертификаты. Для ЗащищенноеСоединениеOpenSSL нужны корневые сертификаты, которым доверяет система. Самоподписанный сертификат партнёра добавьте в доверенные явно, а не отключайте проверку.
• 🌐 Сетевые папки. Пути вида \\server\share не работают — смонтируйте ресурс в файловую систему Linux.

Веб-клиент и облако

В веб-клиенте нет COM, нет прямого доступа к диску и к Windows-библиотекам. Работа с файлами идёт через асинхронные методы: НачатьПомещениеФайлов, НачатьПолучениеФайлов и аналоги с Асинх. Логику, которая раньше выполнялась на клиенте через COM, переносите на сервер: там доступны HTTPСоединение, ТабличныйДокумент и XML/JSON.

В облаке (1С:Фреш и аренда у провайдеров) доступ к серверу ограничен. HTTP-сервисы обычно разрешены, но уточните у провайдера адрес публикации и требования к аутентификации.

Частые ошибки при замене COM-соединения

Ещё три промаха, которые всплывают на проверке:

• ❌ Перенос «болтливой» логики один в один. Сервис, который отвечает на запрос «дай реквизит X элемента Y», повторяет медлительность COM. Проектируйте операции под бизнес-задачу.
• ❌ Полные права у технического пользователя. Интеграция под «Администратором» — дыра: утечка пароля открывает всю базу.
• ❌ Нет версии в адресе. Шаблон /v1/... позволяет выпустить /v2/ без поломки старых клиентов.

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