Как передать COM-объект с клиента на сервер 1С

Вопрос о передаче COM-объекта с клиента на сервер 1С возникает у разработчиков, когда обработка, работающая на тонком клиенте, должна выполнить действие через внешнюю COM-компоненту — например, подключиться к другой базе 1С через V83.ComConnector или обратиться к стороннему приложению. Ключевой факт, который нужно понять сразу: COM-объект напрямую передать между клиентом и сервером нельзя. Платформа 1С не поддерживает сериализацию COM-объектов, и любая попытка вернуть такой объект из серверной процедуры или передать его параметром завершится ошибкой.

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

Поэтому задача решается не передачей объекта, а передачей данных и пересозданием объекта на той стороне, где он реально нужен. Ниже разобраны рабочие схемы: как определить, где должен жить COM-объект, как пересоздать его на сервере, как передать результаты работы обратно на клиента и какие альтернативы стоит рассмотреть, если COM-подход оказывается ненадёжным.

Почему платформа не передаёт COM-объекты между клиентом и сервером

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

Типичная ошибка выглядит так: разработчик в клиентской процедуре создаёт Новый COMОбъект("V83.ComConnector"), затем вызывает серверную функцию и передаёт этот объект параметром. На этапе вызова платформа выдаёт ошибку о невозможности передачи значения, либо об ошибке преобразования данных. Та же ситуация возникает при попытке вернуть COM-объект из серверной процедуры на клиента.

Дополнительное ограничение — контекст исполнения. Даже если бы передача была технически возможна, сервер 1С работает в отдельном процессе rphost, часто на другой машине и под служебной учётной записью. COM-сервер, зарегистрированный на клиентском компьютере, для сервера может просто не существовать. Поэтому архитектурно правильно считать COM-объект локальным ресурсом того процесса, где он создан.

Определяем, где должен жить COM-объект

Первый шаг проектирования — решить, на какой стороне COM-объект должен создаваться и использоваться. От этого зависит вся схема обмена. Критерии выбора простые: где зарегистрирован COM-сервер, у какого процесса есть сетевой доступ к целевому приложению и под какой учётной записью будет выполняться подключение.

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

Схема 1: пересоздание COM-объекта на сервере

Самый частый сценарий — клиент знает параметры подключения (строку соединения, имя базы, учётные данные), а само подключение должно выполняться на сервере. В этом случае клиентская процедура формирует структуру с параметрами, вызывает серверную функцию, а та уже создаёт COM-объект локально, выполняет работу и возвращает результат.

Ключевые правила такой схемы: серверная процедура должна быть размещена в общем модуле с флагом «Сервер» и, при необходимости, «Вызов сервера»; все параметры и возвращаемые значения — только сериализуемые типы; COM-объект создаётся, используется и освобождается внутри одного серверного вызова. Хранить COM-объект между вызовами в переменных модуля не следует — это приводит к утечкам и зависшим процессам внешнего приложения.

&НаКлиенте
Процедура ЗагрузитьДанные(Команда)
    Параметры = Новый Структура;
    Параметры.Вставить("СтрокаПодключения", "Srvr=Server1;Ref=Trade;");
    Параметры.Вставить("Пользователь", "Обмен");
    Параметры.Вставить("Пароль", "");
    Результат = ПолучитьДанныеНаСервере(Параметры);
    Для Каждого Строка Из Результат Цикл
        // обработка полученных данных
    КонецЦикла;
КонецПроцедуры

&НаСервере
Функция ПолучитьДанныеНаСервере(Параметры)
    Результат = Новый Массив;
    Коннектор = Новый COMОбъект("V83.ComConnector");
    Попытка
        Соединение = Коннектор.Connect(Параметры.СтрокаПодключения);
        Выборка = Соединение.Справочники.Номенклатура.Выбрать();
        Пока Выборка.Следующий() Цикл
            Результат.Добавить(Новый Структура("Код,Наименование", Выборка.Код, Выборка.Наименование));
        КонецЦикла;
    Исключение
        ВызватьИсключение "Ошибка COM-подключения: " + ОписаниеОшибки();
    КонецПопытки;
    Соединение = Неопределено;
    Коннектор = Неопределено;
    Возврат Результат;
КонецФункции

Обратите внимание на завершающие присваивания Неопределено: явное освобождение ссылок ускоряет закрытие внешнего процесса и снижает риск «залипших» сеансов в базе-источнике. Блок Попытка/Исключение обязателен — без него при ошибке соединения COM-объекты могут остаться висеть в памяти сервера.

1. 1
   Убедитесь, что COM-компонента нужной разрядности зарегистрирована на сервере 1С от имени учётной записи службы агента
2. 2
   Создайте общий модуль с флагами «Сервер» и «Вызов сервера» для серверных функций обмена
3. 3
   Сформируйте на клиенте структуру с параметрами подключения — без COM-объектов
4. 4
   В серверной функции создайте COMОбъект, выполните работу внутри Попытка/Исключение, освободите объект
5. 5
   Верните на клиент результат в виде массива структур или таблицы значений
6. 6
   Проверьте работу под реальной учётной записью службы сервера, а не только из конфигуратора

Схема 2: COM-объект на клиенте, данные — на сервер

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

Здесь важно ограничить объём передаваемых данных. Если из внешнего приложения выгружается большой набор записей, передавайте его порциями или через временное хранилище: поместите данные во временное хранилище на сервере с помощью ПоместитьВоВременноеХранилище и работайте с адресом хранилища. Это снижает нагрузку на канал и упрощает обработку ошибок на середине загрузки.

Также учитывайте, что на тонком клиенте работа с COM доступна только под Windows и требует соответствующих прав пользователя. Если часть пользователей работает через веб-клиент или под Linux, схему с клиентским COM придётся заменить — например, выносом обмена в отдельное регламентное задание на сервере или в промежуточный сервис.

Проверка результата и диагностика проблем

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

Частая проблема — несовпадение разрядности: 64-разрядный сервер 1С не может загрузить 32-разрядную COM-компоненту в свой процесс. Для V83.ComConnector это решается установкой соответствующей версии компоненты из поставки платформы той же разрядности, что и сервер. Вторая типичная причина ошибок — учётная запись службы агента сервера не имеет прав на запуск COM-сервера или на сетевой доступ к целевой базе.

Ограничения и риски работы с COM

COM-подключение — мощный, но хрупкий механизм. Каждое соединение через V83.ComConnector создаёт в целевой базе полноценный сеанс, который расходует лицензии и удерживает ресурсы. При массовых обменах это может привести к исчерпанию лицензий на целевом сервере. Контролируйте количество одновременных подключений и всегда освобождайте соединение после завершения.

Второй риск — стабильность. Ошибка во внешнем приложении или обрыв связи может оставить процесс-зомби, который удерживает память сервера 1С. На продуктивных серверах рекомендуется мониторинг процессов и регламентная перезагрузка зависших экземпляров. Наконец, COM-обмен работает только в Windows-инфраструктуре: если планируется перевод сервера на Linux, весь COM-функционал придётся переписывать.

Альтернативы COM-обмену

Если схема с пересозданием объекта на сервере оказывается ненадёжной или не масштабируется, рассмотрите замену транспорта. Для обмена между базами 1С штатными альтернативами являются HTTP-сервисы и веб-сервисы: целевая база публикует сервис, а вызывающая сторона обращается к нему без COM вообще. Это снимает проблемы разрядности, регистрации компонент и зависших сеансов.

Для разовых выгрузок подходит файловый обмен: клиент или сервер формирует файл (XML, JSON, CSV), передаёт его через общий каталог или временное хранилище, а принимающая сторона разбирает его штатными средствами. Для регулярных интеграций также применяются планы обмена и внешние источники данных. Выбор зависит от требований к скорости, объёму и частоте обмена.

Часто задаваемые вопросы