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

При сверке или интеграции данных между двумя базами 1С часто используется COM-соединение. Однако при обработке больших массивов данных разработчики сталкиваются с сильным падением производительности. Замер времени показывает, что наибольшие задержки происходят на этапе получения уникальных идентификаторов (GUID) ссылочных объектов. Разберем, почему возникает эта проблема и как существенно ускорить выполнение выгрузки.

Выясним причину низкой производительности

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

Рассмотрим стандартный, но медленный вариант получения строкового GUID:

ГУИД = COMПодключение.XMLСтрока(COMОбъект.УникальныйИдентификатор());

В этой строке выполняется сразу несколько последовательных операций:

1. Обращение к COM-объекту для вызова метода УникальныйИдентификатор().
2. Возврат объекта уникального идентификатора на сторону вызывающей базы.
3. Вызов функции XMLСтрока() для преобразования полученного идентификатора в строку.

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

Способ 1. Получение GUID напрямую из ссылки без вызова метода УникальныйИдентификатор

Проанализируем работу платформы с функцией XMLСтрока(). Если в подключаемой базе обрабатывается объект ссылочного типа (например, СправочникСсылка.Номенклатура или ДокументСсылка.РеализацияТоваровУслуг), нет необходимости предварительно вызывать метод УникальныйИдентификатор().

Функция XMLСтрока() умеет принимать саму ссылку и автоматически преобразовывать её в строковое представление GUID на стороне подключаемой базы за один вызов:

// Оптимизированное получение строкового GUID
ГУИД = COMПодключение.XMLСтрока(COMОбъект);

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

Способ 2. Пакетная сериализация и передача данных за один COM-вызов

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

Рассмотрим пример, когда на стороне внешнего соединения формируется массив GUID или таблица соответствий, которая затем передается целиком:

// Выполняем код на стороне подключаемой базы (Б2)
ТаблицаРезультат = COMПодключение.NewObject("ТаблицаЗначений");
// Выполняем запрос в Б2 и заполняем данные...

// Сериализуем данные или собираем их в массив на стороне Б2
МассивГуидов = COMПодключение.NewObject("Массив");
Для Каждого СтрИз Выборка Цикл
    МассивГуидов.Добавить(COMПодключение.XMLСтрока(СтрИз.Ссылка));
КонецЦикла;

Еще более эффективный подход — вызвать экспортную функцию общего модуля в подключаемой базе, которая сама выполнит запрос, сформирует JSON или единую строку и вернет результат. В этом случае происходит всего один COM-вызов за всю операцию сверки.

Способ 3. Получение GUID прямо в запросе (начиная с платформы 8.3.22)

Если базы работают на платформе 1С:Предприятие версии 8.3.22 и выше, в языке запросов доступна встроенная функция УникальныйИдентификатор(). Это позволяет извлекать GUID объектов непосредственно в результате выполнения запроса в подключаемой базе:

Запрос = COMПодключение.NewObject("Запрос");
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Номенклатура.Ссылка КАК Ссылка,
    |	УНИКАЛЬНЫЙИДЕНТИФИКАТОР(Номенклатура.Ссылка) КАК Идентификатор
    |ИЗ
    |	Справочник.Номенклатура КАК Номенклатура";

Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    // Идентификатор уже получен на стороне СУБД в виде строки/GUID
    ГУИД = Выборка.Идентификатор;
КонецЦикла;

Способ 4. Кэширование соответствий в регистре сведений

Если сверка объектов выполняется регулярно, целесообразно настроить кэширование GUID. Посмотрим на этот архитектурный подход:

1. При первой синхронизации сопоставленные идентификаторы записываются в специальный РегистрСведений.
2. При повторных запуск обработки данные берутся напрямую из локального регистра своей базы, без постоянного обращения к внешнему COM-соединению.

Альтернативные способы интеграции при высоких требованиях к скорости

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

• HTTP-сервисы (REST API): На стороне подключаемой базы создается HTTP-сервис, возвращающий данные с GUID в формате JSON. Это работает значительно быстрее COM, не блокирует сеансы и не зависит от операционной системы.
• Интерфейс OData: Позволяет запрашивать данные объектов вместе с их идентификаторами через стандартные REST-запросы.
• Внешние источники данных: Позволяют подключаться к таблицам СУБД подключаемой базы напрямую и выполнять соединение данных на уровне запроса 1С.