Что выбрать для интеграции 1С: COM-соединение или Web/HTTP-сервисы в локальной сети?

← На главную

При построении ландшафта из нескольких информационных баз 1С (например, ERP, Документооборот и внешняя самописная система-шлюз) разработчики неизбежно сталкиваются с выбором технологии взаимодействия. Традиционно долгое время использовалось COM-соединение (внутрипроцессный COM-сервер), однако современные стандарты разработки диктуют переход на веб-сервисы (SOAP) и HTTP-сервисы (REST). Рассмотрим подробно особенности обеих технологий, проанализируем их сильные и слабые стороны, а также разберем оптимальные архитектурные подходы.

1. Лицензирование: как платформы распределяют клиентские сессии

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

COM-соединение: Гарантированно захватывает и удерживает полноценную клиентскую лицензию на все время существования объекта соединения. Если к вашей внешней базе-шлюзу одновременно обратятся 50 клиентов, и система попытается параллельно инициализировать 50 COM-соединений с ERP-системой, вам потребуется дополнительно 50 свободных лицензий на сервере 1С. Это экономически невыгодно и часто приводит к нехватке лицензий у рядовых пользователей.
HTTP- и Web-сервисы: Сеанс для обработки веб-запроса создается сервером приложений динамически на время выполнения конкретного запроса и практически мгновенно возвращается в пул (или закрывается). При этом, согласно техническому регламенту платформы 1С, кратковременные вызовы HTTP/Web-сервисов не требуют удержания постоянной лицензии, если запросы распределяются через пул соединений веб-сервера. Это позволяет экономить лицензионный фонд при интеграции систем.

2. Кроссплатформенность и технологические риски

Технология COM (Component Object Model) является проприетарной разработкой компании Microsoft. Это накладывает серьезные инфраструктурные ограничения:

Если сервер приложений 1С или веб-сервер будет перенесен на операционную систему семейства Linux (что является стандартом для импортозамещения и интеграции с СУБД PostgreSQL), настроить работу COM-соединения станет практически невозможно. Работа через эмуляторы крайне нестабильна.
Веб-сервисы и HTTP-сервисы полностью кроссплатформенны. Им абсолютно неважно, под управлением какой операционной системы работает сервер-источник и сервер-приемник. Передача данных осуществляется по стандартному протоколу TCP/IP с использованием XML или JSON.
Использование COM требует строго одинаковых версий платформы 1С на обеих сторонах интеграции. При обновлении платформы на сервере вам придется обновлять ее и на клиентских машинах, а также перерегистрировать библиотеку comcntr.dll в операционной системе Windows. С веб-сервисами таких проблем нет: базы могут работать на принципиально разных версиях платформы 1С и общаться без сбоев.

3. Скорость инициализации и накладные расходы на передачу данных

Проанализируем производительность систем при реальном взаимодействии. Процесс инициализации COM-соединения крайне тяжеловесен для операционной системы:

При каждом вызове COM-соединения происходят следующие этапы: запуск процесса, инициализация контекста целевой информационной базы, проверка прав пользователя и создание сессии 1С. Это занимает в среднем от 1 до 3 секунд. Для интерактивных сценариев работы пользователя «в режиме реального времени» это недопустимо долго.

HTTP-запрос, напротив, выполняется за миллисекунды. Веб-сервер (Apache, IIS или Nginx) держит открытыми постоянные пулы подключений к рабочим процессам 1С, что сводит задержку на авторизацию к минимуму.

Кроме того, при работе через COM каждое обращение к реквизиту объекта (например, чтение поля справочника в цикле) приводит к маршалингу (межпроцессному вызову), что драматически замедляет выполнение кода. В случае с HTTP-сервисами данные сериализуются в один компактный JSON-пакет на стороне источника и передаются за один сетевой запрос, что кратно эффективнее.

4. Сравнение протоколов: Web-сервисы (SOAP) против HTTP-сервисов (REST)

Если выбор сделан в пользу веб-технологий, возникает следующий вопрос: использовать Web-сервисы (SOAP) или HTTP-сервисы (REST)? Разберем ключевые отличия:

Web-сервисы (SOAP): Ориентированы на «действия». Они требуют строгого описания структуры через WSDL-схемы и XDTO-пакеты. С одной стороны, это дает преимущество строгой типизации данных — платформа 1С автоматически валидирует типы по схеме при вызове метода. С другой стороны, XML-конверты (SOAP Envelope) содержат много избыточной разметки, что увеличивает объем сетевого трафика.

HTTP-сервисы (REST): Ориентированы на «ресурсы». Они значительно проще в разработке, не требуют тяжелой валидации XDTO на лету и работают с легковесным форматом JSON. Это снижает вычислительную нагрузку на сервера приложений и уменьшает объем сетевого трафика.

Рассмотрим пример реализации HTTP-запроса из самописной конфигурации к ERP-системе для получения данных о товаре:


// Пример отправки легковесного HTTP-запроса из базы-шлюза
ПараметрыЗапроса = Новый Структура;
ПараметрыЗапроса.Вставить("Артикул", "4589201");

ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ПараметрыЗапроса);
СтрокаJSON = ЗаписьJSON.Закрыть();

Соединение = Новый HTTPСоединение("192.168.1.5", , "ПользовательИнтеграции", "Пароль123", , 15);
Запрос = Новый HTTPЗапрос("/erp/hs/v1/get_product_info");
Запрос.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);

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

5. Архитектурный паттерн: Асинхронная очередь запросов

При интеграции систем через базу-шлюз частой ошибкой является проектирование «сквозных» синхронных запросов. Например, когда внешний клиент делает запрос в самописную базу, та синхронно идет по HTTP в ERP, ждет ответа, затем идет в Документооборот, ждет ответа и только потом возвращает данные клиенту. Если одна из баз «зависнет», заблокируется вся цепочка.

Для минимизации подобных рисков рекомендуется использовать асинхронное взаимодействие на очередях сообщений:

Внешний клиент отправляет запрос в самописную базу-шлюз.
База-шлюз быстро записывает входящий запрос в специальный регистр сведений (очередь задач) со статусом "В очереди" и мгновенно возвращает клиенту ответ с кодом 202 Accepted.
Регламентное задание в фоновом режиме поочередно обрабатывает записи регистра, обращается по HTTP к ERP или Документообороту, получает данные и записывает результат обратно в базу-шлюз, меняя статус задачи на "Выполнено".
Внешний клиент периодически опрашивает базу-шлюз на предмет готовности результата по уникальному идентификатору задачи (метод опроса / polling) либо база-шлюз сама отправляет клиенту веб-хук (Webhook) по завершении обработки.

Такой подход гарантирует стабильность всей IT-архитектуры и предотвращает лавинообразный рост нагрузки на ERP и Документооборот.