Чем заменить COM-соединение в 1С

COM-соединение (V83.COMConnector, OLE) десятилетиями было стандартным способом связать две базы 1С или подключить внешнюю программу к информационной базе. Сегодня этот механизм всё чаще становится источником проблем: соединение работает только на Windows, требует совпадения разрядности клиента и сервера, «зависает» при разрывах и не проходит через файрволы и веб-инфраструктуру. Поэтому вопрос замены COM поднимается почти в каждом проекте по модернизации интеграций.

Однозначной «замены кнопкой» не существует: выбор зависит от того, что именно делает текущее COM-соединение — читает данные, создает документы, вызывает процедуры другой базы или обменивается справочниками. Для каждого сценария есть рабочая альтернатива: HTTP-сервисы, SOAP веб-сервисы, файловый обмен через форматы EnterpriseData или JSON, планы обмена, а также внешние компоненты и расширения.

Ниже разобраны основные варианты замены, критерии выбора, порядок миграции и типичные ошибки. Материал ориентирован на администраторов и разработчиков 1С, которые поддерживают существующие COM-интеграции и планируют от них уйти.

Почему от COM-соединений отказываются

COM-технология — проприетарный механизм Windows, и 1С поддерживает его как legacy-режим. Основные ограничения: работа только под Windows, необходимость установки толстого клиента или COM-коннектора на машине, откуда идет подключение, жесткая привязка к версии платформы и разрядности (x86/x64), а также проблемы с правами учетной записи, под которой выполняется соединение.

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

Если базы переводятся на Linux-сервер или веб-клиент, COM перестает быть вариантом в принципе — платформа 1С под Linux не поддерживает COM-объекты. Это часто и становится формальным поводом для миграции.

Какие сценарии использует ваше COM-соединение

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

Для аудита достаточно открыть текст внешней обработки или модуля, где создается COMConnector, и выписать все обращения через полученное соединение: какие объекты метаданных читаются, какие создаются, есть ли вызовы общих модулей. Именно этот список определит требования к новому интерфейсу.

Вариант 1: HTTP-сервисы — основная замена

HTTP-сервисы — встроенный механизм платформы 1С, позволяющий опубликовать произвольные точки входа в базу через веб-сервер (IIS или Apache). Потребитель обращается обычным HTTP-запросом, получает ответ в JSON или XML. Это самый гибкий и современный вариант: он работает на любой ОС, проходит через прокси и балансировщики, не требует установки платформы на стороне клиента.

На стороне базы-источника создается объект метаданных «HTTP-сервис», в котором описываются шаблоны URL и методы (GET, POST). В обработчиках размещается тот же код, что раньше выполнялся через COM: запросы к данным, создание документов. На стороне потребителя вместо COMConnector используется объект HTTPСоединение и HTTPЗапрос.

Публикация выполняется через конфигуратор («Администрирование — Публикация на веб-сервере») с включенным флагом публикации HTTP-сервисов. Для аутентификации используются либо базовая аутентификация по пользователю 1С, либо токены, проверяемые в коде обработчика.

// Потребитель: вместо COMConnector
Соединение = Новый HTTPСоединение("server", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/base/hs/api/remains?item=" + КодТовара);
Запрос.Заголовки.Вставить("Authorization", "Basic " + Токен);
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
    Данные = ПрочитатьJSONИзСтроки(Ответ.ПолучитьТелоКакСтроку());
КонецЕсли;

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

Вариант 2: веб-сервисы SOAP

SOAP веб-сервисы — более старый, но все еще поддерживаемый механизм. Платформа автоматически генерирует WSDL-описание, что удобно для интеграции с системами, где принят строгий контракт: Java, .NET, корпоративные шины. Потребитель генерирует прокси-классы по WSDL и вызывает операции как обычные методы.

Изнутри 1С к чужому SOAP-сервису подключаются через WS-ссылки (WSReferences) или объект WSПрокси. Если ваша текущая COM-интеграция связывает 1С с системой, где уже работают через SOAP, — этот вариант потребует минимальной перестройки архитектуры.

Минусы: громоздкость XML-конвертов, больше накладных расходов, менее удобная отладка по сравнению с JSON. Для новых интеграций без внешних требований обычно выбирают HTTP-сервисы с JSON.

Вариант 3: планы обмена и EnterpriseData

Если COM использовался для регулярной синхронизации справочников и документов между двумя базами 1С, правильная замена — не прямые вызовы, а планы обмена. Это штатный механизм платформы: он сам отслеживает изменения (регистрация изменений), формирует сообщения, гарантирует доставку и разрешает коллизии.

Типовые конфигурации поддерживают обмен в формате EnterpriseData через подсистему «Обмен данными» БСП, часто в связке с «Синхронизацией данных через универсальный формат». Транспортом может служить файловый каталог, FTP, веб-сервис или прямое подключение — при этом COM здесь уже не нужен, используется HTTP или файлы.

Вариант 4: файловый обмен и очереди

Самый недооцененный вариант — обмен файлами через общий каталог, SFTP или облачное хранилище. База-источник регламентным заданием выгружает данные в JSON или XML, потребитель забирает файл и загружает. Механизм устойчив к обрывам, легко журналируется и не держит соединений.

Для более оперативной доставки используют брокеры сообщений (RabbitMQ, Kafka) — 1С подключается к ним через внешние компоненты или через промежуточный сервис. Это промышленный вариант для высоконагруженных интеграций, но он требует дополнительной инфраструктуры и компетенций.

Пошаговая миграция с COM на HTTP-сервисы

Миграцию безопаснее проводить поэтапно, не отключая старый механизм до полной проверки нового.

1. 1
   Инвентаризируйте все обращения через COM: объекты, методы, частота вызовов
2. 2
   Спроектируйте API: список URL-шаблонов, методов и форматов ответов
3. 3
   Создайте HTTP-сервис в базе-источнике и перенесите логику в обработчики
4. 4
   Опубликуйте сервис на веб-сервере, настройте аутентификацию и HTTPS
5. 5
   Перепишите код потребителя на HTTPСоединение, добавьте обработку ошибок и повторы
6. 6
   Прогоните параллельную работу COM и HTTP, сверьте результаты на тестовых данных
7. 7
   Отключите COM-интеграцию и удалите неиспользуемый код

Проверка результата и типичные ошибки

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

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