Можно ли подключаться по COM-соединению к базам 1С с разными версиями платформ при работающих пользователях?

При интеграции различных информационных баз 1С:Предприятие разработчики часто сталкиваются с ситуацией, когда необходимо настроить автоматический обмен данными между серверами, работающими на разных релизах платформы. Типичный сценарий: База 1 (источник) на платформе 8.3.13.14 должна подключиться через COM-соединение к Базе 2 (приемник), которая функционирует на сервере с платформой 8.3.13 другого релиза, и в этой целевой базе в данный момент активно работают пользователи.

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

Влияние активных пользователей в целевой базе на COM-подключение

Первый вопрос, который волнует разработчиков: не помешают ли работающие пользователи установке внешнего соединения? С технической точки зрения активные сеансы пользователей в целевой базе никак не препятствуют COM-подключению. Для кластера серверов 1С и СУБД такое подключение позиционируется как обычный дополнительный сеанс (внешнее соединение). Однако здесь важно учитывать три критических аспекта:

1. Лицензирование сеансов: Каждое COM-соединение требует наличия свободной клиентской лицензии 1С. Если на целевом сервере (Сервер 2) все доступные лицензии заняты активными пользователями, то при попытке программного подключения система выдаст ошибку о том, что свободная лицензия не найдена. Необходимо планировать пул лицензий с запасом под фоновые обмены.
2. Транзакционные блокировки: Поскольку пользователи активно вводят и проводят документы в Базе 2, выполнение тяжелых запросов или запись данных через COM-соединение могут приводить к транзакционным блокировкам таблиц базы данных. Это может вызвать у пользователей ошибки ожидания блокировок или существенно замедлить их работу.
3. Нагрузка на сервер (rphost): COM-соединение инициирует выполнение кода на стороне целевой базы. Если обмен передает большие объемы данных, это создаст дополнительную нагрузку на рабочие процессы rphost Сервера 2, что также отразится на отзывчивости интерфейса у активных пользователей.

Технические нюансы несовместимости платформ

Главная сложность при COM-соединении баз с разными платформами кроется в жестком требовании технологической платформы 1С: версия библиотеки comcntr.dll на стороне инициатора (Сервер 1) должна в точности совпадать с версией платформы целевого сервера (Сервер 2).

Даже если разница в версиях минимальна (например, на Сервере 1 установлена платформа 8.3.13.1472, а на Сервере 2 — более свежий релиз той же ветки 8.3.13.1800), стандартное COM-подключение без предварительной настройки завершится ошибкой: «Различаются версии клиента и сервера».

Дело в том, что операционная система Windows хранит в системном реестре путь только к одной зарегистрированной библиотеке comcntr.dll (обычно к той, которая устанавливалась или регистрировалась последней). Если мы просто зарегистрируем библиотеку от целевой базы через утилиту regsvr32, то сломаются локальные COM-подключения на Сервере 1, которым требуется его "родная" версия платформы.

Решение проблемы сосуществования версий через COM+ в Windows

Чтобы обойти ограничение операционной системы и заставить сервер 1С использовать строго определенную версию библиотеки для конкретного подключения, настроим изолированное приложение в Службах компонентов Windows (COM+). Разберем этот процесс по шагам:

Шаг 1. Подготовка платформы. На Сервере 1 (инициаторе подключения) обязательно должен быть установлен тот релиз платформы 1С, который работает на целевом Сервере 2. Нам физически необходимы файлы этого релиза, в частности, библиотека comcntr.dll, расположенная в каталоге установки (например, C:\Program Files\1cv8\8.3.13.XXXX\bin\).

Шаг 2. Создание приложения COM+. Откроем панель управления «Службы компонентов» (команда dcomcnfg в строке выполнения Windows). В дереве консоли перейдем к ветке «Компьютеры» — «Мой компьютер» — «Приложения COM+». Нажмем правой кнопкой мыши и выберем «Создать» — «Приложение». В мастере создания выберем «Создать новое приложение», укажем его имя (например, 1C_COM_8.3.13) и установим способ активации — «Серверное приложение». Это позволит изолировать работу компонента в отдельном системном процессе dllhost.exe.

Шаг 3. Добавление компонента. Внутри созданного приложения перейдем в папку «Компоненты», нажмем правую кнопку мыши и выберем «Создать» — «Компонент». Выберем пункт «Установка новых компонентов» и укажем путь к файлу comcntr.dll нужного релиза платформы 1С на Сервере 1.

Шаг 4. Настройка уникального ProgID (псевдонима). Чтобы код 1С мог обращаться именно к этой изолированной версии библиотеки, нам нужно изменить ее программный идентификатор. В свойствах созданного компонента на вкладке «Общие» укажем уникальное имя в поле «Программный идентификатор (ProgID)», например: V83_13.COMConnector.

Теперь проанализируем, как изменится код подключения в нашей конфигурации 1С. Рассмотрим стандартный шаблон инициализации соединения:

// Стандартный вызов, который использует зарегистрированную в реестре версию
Попытка
    РазработчикКоннектор = Новый COMОбъект("V83.COMConnector");
Исключение
    ЗаписьЖурналаРегистрации("ОбменДанными", УровеньЖурналаРегистрации.Ошибка,,, "Ошибка создания базового COM: " + ОписаниеОшибки());
КонецПопытки;

Для подключения к базе с другой платформой мы будем использовать наш настроенный в COM+ компонент с уникальным псевдонимом:

// Использование изолированного COM-соединителя конкретной версии платформы
Попытка
    ИмяКоннектора = "V83_13.COMConnector"; // Наш псевдоним из настроек COM+
    COMКоннектор = Новый COMОбъект(ИмяКоннектора);
    
    СтрокаПодключения = "Srvr=""Server2"";Ref=""Base2"";Usr=""ExchangeUser"";Pwd=""StrongPassword"";";
    СоединениеСБазой = COMКоннектор.Connect(СтрокаПодключения);
    
    // Код выполнения операций в удаленной базе данных
    // ...
    
    СоединениеСБазой = Неопределено;
    COMКоннектор = Неопределено;
Исключение
    ЗаписьЖурналаРегистрации("ОбменДанными", УровеньЖурналаРегистрации.Ошибка,,, "Не удалось установить соединение через COM+: " + ОписаниеОшибки());
КонецПопытки;

Важное примечание для типовых конфигураций: Если ваша база использует Библиотеку Стандартных Подсистем (БСП), то имя COM-соединителя часто формируется динамически в общих модулях (например, функция ИмяCOMСоединителя()). В таком случае потребуется внести незначительные изменения в код БСП через расширение, чтобы система подставляла ваш кастомный ProgID при подключении к этой конкретной базе.

Дополнительным преимуществом использования COM+ является стабильность: если во время обмена произойдет критический сбой или утечка памяти, это приведет лишь к перезапуску изолированного процесса dllhost.exe, но не «уронит» рабочий процесс сервера 1С rphost.

Почему HTTP-сервисы — лучшая альтернатива COM-соединениям

Хотя технология COM+ решает проблему несовместимости версий, современные стандарты разработки в среде 1С предписывают отказываться от COM-соединений в пользу HTTP-сервисов. Выделим ключевые причины, почему этот переход необходим:

• Полная кроссплатформенность: COM — это проприетарная технология Microsoft, жестко привязанная к операционной системе Windows. В условиях массового перевода серверов 1С на ОС Linux использование COM становится невозможным. HTTP-сервисы работают на любой операционной системе.
• Независимость от обновлений платформы: При использовании HTTP-сервисов серверам абсолютно безразлично, какие версии платформ 1С на них установлены. Вы можете обновить Сервер 2 на любой новый релиз, и интеграция не сломается, не требуя перенастройки реестра или COM+.
• Эффективное использование лицензий: HTTP-запрос выполняется в рамках быстрого сеанса, который мгновенно освобождает лицензию после отдачи ответа. COM-соединение держит сессию активной все время, пока объект существует в памяти инициатора.
• Высокая скорость работы и стабильность: COM-объекты инициализируются медленно, склонны к утечкам оперативной памяти на сервере и часто "зависают" в процессах при некорректном завершении работы скрипта. HTTP-запросы лишены этих недостатков.

Рассмотрим пример того, как лаконично выглядит отправка запроса к целевой базе через HTTP-сервис взамен тяжеловесного COM-подключения:

// Пример выполнения обмена данными через HTTP-сервис вместо COM
HTTPСоединение = Новый HTTPСоединение("server2.domain.local", 80, "ExchangeUser", "StrongPassword",,, Новый ЗащищенноеСоединениеOpenSSL());
HTTPЗапрос = Новый HTTPЗапрос("/Base2/hs/v1/get_exchange_data");

// Добавим параметры запроса при необходимости
HTTPЗапрос.Заголовки.Вставить("Content-Type", "application/json");

Попытка
    HTTPОтвет = HTTPСоединение.Получить(HTTPЗапрос);
    Если HTTPОтвет.КодСостояния = 200 Тогда
        ТелоОтвета = HTTPОтвет.ПолучитьТелоКакСтроку();
        // Производим чтение и обработку полученного JSON или XML
        // ...
    Иначе
        ЗаписьЖурналаРегистрации("ОбменДанными", УровеньЖурналаРегистрации.Предупреждение,,, "Сервер вернул код ошибки: " + HTTPОтвет.КодСостояния);
    КонецЕсли;
Исключение
    ЗаписьЖурналаРегистрации("ОбменДанными", УровеньЖурналаРегистрации.Ошибка,,, "Ошибка связи по HTTP: " + ОписаниеОшибки());
КонецПопытки;

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