При работе в крупной организации часто возникает ситуация «зоопарка» информационных баз: часть из них работает на старой платформе (например, 1С 8.2.19), а новые или обновленные конфигурации требуют платформу 8.3. Основная проблема при использовании механизма COM-соединения заключается в том, что обе платформы при установке регистрируют в реестре Windows свои библиотеки под схожими именами. Это приводит к конфликту, когда система не понимает, версию какого коннектора (8.2 или 8.3) нужно инициализировать для конкретного подключения.
Рассмотрим подробнее несколько проверенных способов решения этой технической задачи, начиная от простых программных правок и заканчивая архитектурными изменениями системы обмена.
Разберем ситуацию: на сервере запущено две службы 1С. Одна работает на порту 1641 (версия 8.2), другая — на порту 1541 (версия 8.3). Когда база на платформе 8.3 пытается подключиться к базе на 8.2 через стандартный V83.COMConnector, возникает ошибка, так как платформа 8.2 ожидает соединение через свой класс V82.COMConnector.
Проблема усугубляется тем, что в современных конфигурациях (например, Бухгалтерия предприятия 3.0) имя COM-класса формируется динамически. Проанализируем типовой код функции, которая определяет имя коннектора:
Функция ИмяCOMСоединителя() Экспорт
СистемнаяИнфо = Новый СистемнаяИнформация;
ПодстрокиВерсии = СтрРазделить(СистемнаяИнфо.ВерсияПриложения, ".");
Возврат "v" + ПодстрокиВерсии[0] + ПодстрокиВерсии[1] + ".COMConnector";
КонецФункции
Эта функция всегда будет возвращать версию текущей запущенной платформы. Если мы работаем в 8.3.11, она вернет v83.COMConnector, что сделает невозможным прямое обращение к базе на 8.2 без дополнительных манипуляций.
Самым стабильным и «чистым» решением является отказ от COM-соединения в пользу Web-сервисов. Этот метод позволяет полностью абстрагироваться от версий платформ, портов и разрядности операционной системы.
Выясним, как это реализовать на практике:
WSПрокси.Преимущество этого метода в том, что для передачи данных не требуется наличие установленной платформы 8.2 на стороне клиента 8.3. Это снимает все вопросы с регистрацией библиотек в реестре.
Если отказаться от COM-соединения невозможно, проанализируем вариант с использованием COM+ в Windows. Это позволяет создать изолированные окружения для каждой версии коннектора.
Разберем по шагам настройку в ОС Windows:
1C_COM_82). Укажите способ активации «Серверное приложение».comcntr.dll, который находится в папке bin конкретной версии платформы 8.2 (например, C:\Program Files\1cv8\8.2.19.130\bin\comcntr.dll).1C_COM_83.Теперь в системе зарегистрированы два независимых COM-сервера. Это позволяет избежать ситуации, когда установка обновления одной платформы «затирает» регистрацию другой в реестре. В коде 1С вы сможете обращаться к ним более гибко.
Чтобы не снимать типовую конфигурацию (например, БП 3.0) с поддержки, но при этом изменить логику подключения, воспользуемся механизмом Расширений. Мы можем перехватить выполнение функции ИмяCOMСоединителя().
Рассмотрим пример кода в расширении:
&Вместо("ИмяCOMСоединителя")
Функция Расш_ИмяCOMСоединителя()
// Если нам нужно подключиться именно к старой базе
Если ПараметрыОбменаНуждаютсяВ_82 Тогда
Возврат "v82.COMConnector";
Иначе
// Стандартная логика
СистемнаяИнфо = Новый СистемнаяИнформация;
ПодстрокиВерсии = СтрРазделить(СистемнаяИнфо.ВерсияПриложения, ".");
Возврат "v" + ПодстрокиВерсии[0] + ПодстрокиВерсии[1] + ".COMConnector";
КонецЕсли;
КонецФункции
Такой подход позволяет сохранить поддержку основной конфигурации и точечно решить проблему выбора версии comcntr.dll.
Часто программисты боятся переводить старые базы (например, сильно доработанную УПП 1.3) на платформу 8.3, опасаясь, что «все развалится». Однако платформа 8.3 обладает мощным механизмом режима совместимости.
Проанализируем этот сценарий:
В этом режиме ядро 8.3 эмулирует поведение старой платформы (логику блокировок, работу запросов и интерфейса), что минимизирует риски. Когда все базы (и 8.2, и 8.3) будут работать под управлением одной версии исполняемых файлов (одной службы), проблема конфликта версий COM-коннектора исчезнет сама собой.
Если базы на платформе 8.3 достаточно современные, мы можем задействовать HTTP-сервисы или автоматический интерфейс OData.
Посмотрим на преимущества этого подхода:
HTTPЗапрос получать данные из базы на 8.3, просто обращаясь по URL-адресу к справочникам или документам. Вам даже не нужно писать код на стороне базы-приемника.Для задачи согласования заявок в 30 базах наиболее правильным будет создание Единого центра согласования на базе «1С:Документооборот» или отдельной подсистемы в центральной УПП. Вместо того чтобы настраивать прямые COM-связи «каждый с каждым» (что превратит поддержку в ад), используйте схему «звезда»:
Это позволит вам обновлять платформу в любой из 30 баз независимо от остальных, не опасаясь, что регистрация COM-объектов на сервере снова «сломается».