Чем заменить COM, OLE и ActiveX в 1С при отказе от продуктов Microsoft и переходе на Linux?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Переход на импортозамещающие технологии, проектирование защищенной IT-инфраструктуры на базе операционных систем Linux (Astra Linux, РЕД ОС и др.) и отказ от офисных пакетов Microsoft Office ставят перед разработчиками 1С серьезную архитектурную задачу. Для упрощения миграции можно использовать сценарии автоматизации установки PostgreSQL и сервера 1С на Astra Linux. Привычные методы интеграции, такие как COM-соединение (V83.COMConnector), OLE Automation (Excel.Application) и ActiveX компоненты, являются проприетарными технологиями Windows и перестают работать в новой среде. В этом материале мы подробно разберем, какие современные кроссплатформенные инструменты предлагает платформа 1С:Предприятие для решения этих задач.

Почему COM и OLE больше не подходят?

Технологии COM (Component Object Model) и OLE (Object Linking and Embedding) глубоко интегрированы в архитектуру Windows. Когда сервер 1С переносится на Linux, вызов New COMObject неминуемо приведет к ошибке, так как в ядре Linux нет реестра COM-объектов. Даже при использовании Windows, отказ от MS Office делает невозможным создание объектов Excel.Application или Word.Application.

Давайте рассмотрим конкретные сценарии использования и их современные альтернативы, которые мы можем применять уже сейчас.

Сценарий 1: Прямой вызов процедур и обмен данными между базами 1С

Ранее мы часто использовали COM-соединение для того, чтобы подключиться к другой базе, получить ссылку на справочник или вызвать экспортную процедуру из общего модуля. Это создавало жесткую связность ("монолит") и требовало прямого сетевого доступа (современная альтернатива — модуль обмена между базами в формате EnterpriseData).

Решение: HTTP-сервисы (REST API) и Web-сервисы (SOAP)

Наиболее универсальной заменой COM-соединению при интеграции 1С является использование HTTP-сервисов. Это позволяет обмениваться данными через стандартный протокол HTTP/HTTPS, который поддерживается любыми ОС. При работе с различными форматами обмена данными (JSON/XML/CSV) полезным инструментом станет модуль «Трансформер» для конвертации данных, который упрощает обработку входящих потоков.

Разберем преимущества этого подхода:

  1. Кроссплатформенность: Работает на Windows, Linux, macOS, Android.
  2. Независимость: Базе-источнику не нужно знать структуру метаданных базы-приемника (в отличие от COM, где мы оперировали типами удаленной базы).
  3. Безопасность: Легко настраивается через веб-сервер (Apache/IIS/Nginx), поддерживается SSL шифрование.

Рассмотрим пример создания простого API для получения данных, который заменит чтение данных через COM. Вместо того чтобы "лезть" в чужую базу, мы просим её "отдать" данные.

На стороне базы-источника создадим HTTP-сервис ТоварыAPI с методом GET. Код обработчика может выглядеть так:


Функция ПолучитьТовары(Запрос)
    
    // Получаем параметры из строки запроса
    Артикул = Запрос.ПараметрыЗапроса.Получить("articul");
    
    ЗапросSQL = Новый Запрос;
    ЗапросSQL.Текст = 
        "ВЫБРАТЬ
        |	Номенклатура.Наименование КАК Наименование,
        |	Номенклатура.Артикул КАК Артикул,
        |	Номенклатура.Цена КАК Цена
        |ИЗ
        |	Справочник.Номенклатура КАК Номенклатура
        |ГДЕ
        |	Номенклатура.Артикул = &Артикул";
        
    ЗапросSQL.УстановитьПараметр("Артикул", Артикул);
    Результат = ЗапросSQL.Выполнить();
    
    // Сериализуем результат в JSON
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    
    МассивДанных = Новый Массив;
    Выборка = Результат.Выбрать();
    Пока Выборка.Следующий() Цикл
        СтрокаДанных = Новый Структура("Name, Articul, Price", Выборка.Наименование, Выборка.Артикул, Выборка.Цена);
        МассивДанных.Добавить(СтрокаДанных);
    КонецЦикла;
    
    ЗаписатьJSON(ЗаписьJSON, МассивДанных);
    СтрокаОтвета = ЗаписьJSON.Закрыть();
    
    // Формируем ответ
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(СтрокаОтвета);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    
    Возврат Ответ;
    
КонецФункции

Теперь из базы-клиента (которая раньше использовала COM) мы обращаемся к этому сервису:


Соединение = Новый HTTPСоединение("server-1c", 80, "user", "password");
Запрос = Новый HTTPЗапрос("/base_name/hs/goods?articul=12345");
Ответ = Соединение.Получить(Запрос);

Если Ответ.КодСостояния = 200 Тогда
    Чтение = Новый ЧтениеJSON;
    Чтение.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
    Данные = ПрочитатьJSON(Чтение);
    // Теперь переменная Данные содержит массив структур
КонецЕсли;

Альтернатива без кодирования: OData

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

Вам достаточно опубликовать базу на веб-сервере и поставить галочку "Публиковать стандартный интерфейс OData". После этого вы сможете обращаться к данным напрямую по URL, например: http://server/base/odata/standard.odata/Catalog_Номенклатура.

Сценарий 2: Работа с Excel и Word (Отчеты и Печатные формы)

Ранее для заполнения шаблонов договоров или загрузки прайс-листов использовался OLE Automation (запуск Excel в фоновом режиме). На Linux сервере это невозможно, да и на Windows сервере это считается плохой практикой из-за проблем с зависшими процессами.

Решение: Нативные методы платформы и формат XML/XLSX

1С, начиная с версии 8.3.6 и выше, значительно расширила возможности работы с форматом Excel напрямую, без установленного офисного пакета. Это позволяет выполнять генерацию документов XLSX и DOCX на сервере Linux без использования COM и MS Office штатными средствами платформы. Например, для быстрой загрузки прайс-листов и справочников может быть использована универсальная загрузка из Excel, которая работает без установленного приложения Excel.

Для чтения файлов .xlsx используем объект ТабличныйДокумент. Это работает на Linux сервере нативно.


ТабДок = Новый ТабличныйДокумент;
// Читаем файл напрямую. Платформа сама разберет структуру XLSX
ТабДок.Прочитать("C:\Temp\Price.xlsx", СпособЧтенияЗначенийТабличногоДокумента.Значение);

// Обходим ячейки как обычно
Область = ТабДок.Область(1, 1, ТабДок.ВысотаТаблицы, ТабДок.ШиринаТаблицы);
// ... логика разбора

Для генерации файлов Excel мы также используем ТабличныйДокумент и метод Записать с типом файла ТипФайлаТабличногоДокумента.XLSX.

Решение для сложного форматирования: Внешние библиотеки

Если возможностей табличного документа недостаточно (нужны сложные диаграммы, сводные таблицы, макросы), мы можем использовать внешние инструменты, вызываемые через командную строку. Это соответствует философии Unix-систем.

  1. Python + pandas/openpyxl: Использование Python в 1С для обработки Excel через внешние скрипты на Linux является мощной альтернативой OLE Automation. Вы можете написать скрипт на Python, который обрабатывает Excel-файл, а 1С запускает его и получает результат.
  2. LibreOffice в режиме Headless: Для конвертации файлов (например, DOCX в PDF) на сервере Linux можно использовать команду:
    
    soffice --headless --convert-to pdf filename.docx
    

Сценарий 3: Асинхронный обмен и надежность

В теме на форуме справедливо заметили, что COM-соединение часто используется для передачи больших реестров данных. Это блокирует работу пользователей и зависит от доступности приемника.

Решение: Брокеры сообщений (RabbitMQ)

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

Решение: EnterpriseData и Планы обмена

Если речь идет о синхронизации справочников и документов между типовыми конфигурациями, не стоит "изобретать велосипед". Используйте формат EnterpriseData (основан на XML) — поможет готовая настройка двусторонней синхронизации. Он спроектирован для работы в асинхронном режиме, не требует COM и отлично работает через файлы, FTP или HTTP.

Сценарий 4: Работа с оборудованием (Вместо ActiveX)

ActiveX — это технология, позволяющая встраивать элементы управления (DLL/OCX) в приложение. Чаще всего в 1С это использовалось для торгового оборудования или криптографии.

Решение: Технология Native API

Для Linux и современных версий Windows 1С использует разработку внешних компонент по технологии Native API. Компоненты пишутся на C++ (или Rust/Go), компилируются в Shared Library (файлы .so для Linux или .dll для Windows) и подключаются методом ПодключитьВнешнююКомпоненту. Примером реализации такого подхода является внешняя компонента Native для отслеживания нажатия клавиш, обеспечивающая низкоуровневое взаимодействие со средой.

Большинство производителей торгового оборудования (Атол, Штрих-М) и средств криптографии (КриптоПро) уже выпустили драйверы, совместимые с Native API и Linux.

Итоговая таблица замен

Подводя итог нашему анализу, составим карту переходов для разработчика:

  1. Было: V83.COMConnector для вызова функций.
    Стало: HTTP-сервисы (REST), Web-сервисы (SOAP).
  2. Было: V83.COMConnector для чтения данных.
    Стало: OData (стандартный интерфейс) или HTTP-сервисы с JSON.
  3. Было: Excel.Application (OLE) для чтения/записи.
    Стало: ТабличныйДокумент.Прочитать/Записать(.xlsx) или внешние скрипты (Python).
  4. Было: ActiveX для оборудования.
    Стало: Драйверы Native API.
  5. Было: Прямая передача файлов по сети Windows (SMB).
    Стало: Передача двоичных данных через HTTP, FTP или S3-хранилища.

Переход от COM/OLE к веб-технологиям не только решает проблему лицензирования и смены ОС, но и делает вашу систему более масштабируемой, стабильной и готовой к современным реалиям интеграции.

← На главную