Как вызвать функции другой базы 1С при переходе на Linux: замена COM-соединения и роль Native API

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

При миграции ИТ-инфраструктуры на операционные системы семейства Linux программисты 1С сталкиваются с серьезной проблемой: привычная технология COM-соединения (V83.ComConnector) перестает работать, так как она является специфичной только для среды Windows. Часто возникает вопрос: можно ли использовать Native API на C++ для создания аналогичного соединения? В этой статье мы подробно разберем, почему Native API не подходит для этих целей, и какие современные инструменты стоит выбрать для интеграции 1С:УПП, 1С:Бухгалтерии и других конфигураций в среде Linux.

Развенчиваем мифы: почему Native API не заменит COM

Рассмотрим ситуацию, когда одна база (например, УПП) должна подключиться к другой (Бухгалтерия) и вызвать функцию общего модуля. На Windows это решалось одной строкой создания COM-объекта. При попытке найти замену на C++ многие обращают внимание на Native API. Однако здесь кроется фундаментальное архитектурное различие.

Проанализируем суть Native API. Эта технология предназначена исключительно для разработки внешних компонент, которые расширяют возможности платформы "изнутри". Рассмотрим основные ограничения:

  1. Контекст выполнения: Внешняя компонента на Native API загружается в адресное пространство текущего процесса 1С. Она может взаимодействовать с объектами того сеанса, в котором запущена, через интерфейс IAddInDefBase.
  2. Отсутствие транспортного уровня: В Native API нет встроенных механизмов для инициирования полноценного сетевого соединения с другим сервером 1С, авторизации в нем и создания удаленного сеанса. Написание такого функционала на C++ "с нуля" потребует реализации всего протокола обмена данными 1С, что технически нецелесообразно.
  3. Назначение: Native API нужен для работы с оборудованием (сканеры, кассы), выполнения сложных математических расчетов или специфического шифрования, но не для межпрограммного взаимодействия баз.

Вывод: Native API позволяет сделать компоненту кроссплатформенной (работать и в Windows, и в Linux), но она не может "подключиться" к другой базе так, как это делал COM.

Решение №1: Использование Web-сервисов (SOAP)

Самый надежный и рекомендуемый способ замены COM-соединения — это создание Web-сервиса на стороне базы-приемника (например, в Бухгалтерии). Рассмотрим этот процесс пошагово.

Выясним преимущества этого метода: Web-сервисы работают через стандартный протокол HTTP, который поддерживается платформой 1С на любой операционной системе. При этом не имеет значения, работает ли клиент в режиме тонкого или толстого клиента.

Разберем пример кода для вызова функции Web-сервиса из базы-отправителя:


// Определяем параметры подключения
Определение = Новый WSОпределения(URL_АдресWSDL, ИмяПользователя, Пароль);
// Создаем прокси-обект для обращения к сервису
Прокси = Новый WSПрокси(Определение, URI_ПространстваИмен, ИмяСервиса, ИмяТочкиПодключения);
Прокси.Пользователь = ИмяПользователя;
Прокси.Пароль = Пароль;

// Вызываем удаленную функцию
Результат = Прокси.ВыполнитьРасчет(Параметр1, Параметр2);

Важно: В отличие от COM-соединения, Web-сервисы работают по принципу stateless (без сохранения состояния). Это значит, что каждый вызов — это новый запрос. Если вам нужно передать большой объем данных, старайтесь упаковать их в один вызов, чтобы минимизировать накладные расходы на авторизацию и создание сеанса на сервере.

Решение №2: HTTP-сервисы (REST)

Если ваша задача — передача данных или простая интеграция, проанализируем возможности HTTP-сервисов. В современной разработке на 1С они считаются более быстрыми и легкими, чем Web-сервисы (SOAP).

Основные отличия и плюсы:

  1. Формат JSON: Вместо тяжеловесного XML (в Web-сервисах) используется JSON, который занимает меньше места и быстрее обрабатывается.
  2. Гибкость: Вы можете сами определять структуру URL и методы (GET, POST, DELETE).
  3. Кроссплатформенность: На Linux взаимодействие с такими сервисами можно тестировать даже через консольную утилиту curl.

Посмотрим на пример реализации HTTP-запроса из УПП к Бухгалтерии:


Соединение = Новый HTTPСоединение("server.com", , Пользователь, Пароль);
Запрос = Новый HTTPЗапрос("/base_bp/hs/my_integration/v1/get_data");
Запрос.Заголовки.Вставить("Content-Type", "application/json");

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

Альтернативные методы интеграции на Linux

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

Внешние источники данных:
Если вам нужно просто прочитать данные из Бухгалтерии, находясь в УПП, рассмотрите механизм Внешние источники данных. На Linux 1С может подключаться к базам данных (PostgreSQL или MS SQL) через ODBC-драйверы. Это позволяет работать с таблицами другой базы практически так же, как с объектами своей конфигурации. Это на порядок быстрее любого сетевого вызова, но требует осторожности при записи данных напрямую в SQL-таблицы (что не рекомендуется платформой).

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

Особенности работы в толстом клиенте УПП на Linux

Многие переживают, что 1С:УПП, работающая в режиме толстого клиента (обычное приложение), наложит ограничения на использование Web-сервисов. Выясним этот момент: никаких ограничений нет. Объекты HTTPСоединение, WSПрокси и WSОпределения доступны в толстом клиенте в полном объеме.

Однако при переходе на Linux в толстом клиенте следует обратить внимание на следующие нюансы:

Итоговые рекомендации по переходу

Подведем итог нашему анализу. Если вы планируете отказ от Windows-серверов и переход на Linux:

  1. Забудьте про Native API как про средство соединения баз — это инструмент для других задач.
  2. Инвентаризируйте все вызовы через V83.ComConnector.
  3. Создайте Web-сервисы или HTTP-сервисы в базах-приемниках, которые будут оборачивать логику нужных вам функций общих модулей.
  4. Оптимизируйте пакетную передачу данных, чтобы избежать замедления работы из-за частых HTTP-запросов.
  5. Используйте JSON как основной формат обмена для повышения производительности.

Переход на Linux требует изменения архитектурного мышления: от "тесного связывания" через COM к "слабому связыванию" через сервисы. Это сделает вашу систему более устойчивой, масштабируемой и современной.

← На главную