Как организовать высоконагруженный обмен данными между УПП 1.3 и БП 3.0 при большом количестве документов?

При достижении определенного порога нагрузки (от 1500–2000 документов в день) классические методы обмена через COM-соединение начинают давать сбои. Они становятся медленными, нестабильными и приводят к утечкам памяти на сервере. В этой статье мы подробно разберем, как перестроить архитектуру обмена, чтобы система справлялась с интенсивным потоком данных без задержек и ошибок.

Почему COM-соединение не подходит для высоких нагрузок?

Разберем основные причины, по которым стоит отказаться от COM-технологии в современных интеграциях. Во-первых, это синхронность: пока данные передаются, вызывающий процесс заблокирован. Во-вторых, каждый вызов через COM требует создания полноценной сессии в базе-приемнике, что потребляет значительные ресурсы сервера. Проанализируем ситуацию: при выгрузке 2000 реализаций в день любая сетевая заминка или блокировка в Бухгалтерии предприятия 3.0 приведет к "зависанию" процесса в УПП 1.3.

Решение 1: Переход на HTTP-сервисы и формат JSON

Рассмотрим наиболее современный и быстрый способ обмена — использование HTTP-сервисов в сочетании с форматом JSON. В отличие от XML, формат JSON более компактен и быстрее обрабатывается платформой 1С.

Пошаговый алгоритм реализации:

1. В базе-приемнике (БП 3.0) создадим HTTP-сервис с методом POST. Этот метод будет принимать строку JSON, содержащую данные документа.
2. В базе-источнике (УПП 1.3) настроим формирование данных документа в структуру, которую затем сериализуем в JSON.
3. Организуем отправку данных порциями (например, по 10-50 документов за один запрос), чтобы не перегружать память.

Посмотрим на пример кода для формирования и отправки JSON из УПП:

ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ДанныеДокумента = Новый Структура("Номер, Дата, Контрагент, Сумма", Объект.Номер, Объект.Дата, Объект.Контрагент.Наименование, Объект.СуммаДокумента);
ЗаписатьJSON(ЗаписьJSON, ДанныеДокумента);
СтрокаJSON = ЗаписьJSON.Закрыть();

HTTPСоединение = Новый HTTPСоединение("server_address", , "user", "password");
HTTPЗапрос = Новый HTTPЗапрос("/your_service/v1/load_doc");
HTTPЗапрос.УстановитьТелоИзСтроки(СтрокаJSON);
Ответ = HTTPСоединение.ОтправитьДляОбъекта(HTTPЗапрос);

Решение 2: Использование Планов обмена для регистрации изменений

Для того чтобы система точно знала, какие документы нужно выгрузить, проанализируем механизм ПланыОбмена. В УПП 1.3 этот механизм встроен "из коробки" и работает крайне эффективно. Создадим отдельный план обмена (например, ОбменСБухгалтерией) и включим в него только необходимые типы документов, такие как РеализацияТоваровУслуг.

Это позволит нам:

• Выгружать только измененные или новые документы.
• Автоматически очищать регистрацию изменений после успешного подтверждения приема данных.
• Избежать постоянного сканирования всего регистра или таблицы документов запросами.

Решение 3: Распараллеливание процессов через Фоновые задания

Выясним, как ускорить выгрузку 2000 документов. Если выполнять это в один поток, процесс может затянуться на часы. Рассмотрим вариант с использованием ФоновыеЗадания. Мы можем разбить пул документов, требующих выгрузки, на несколько порций и запустить несколько фоновых заданий одновременно.

Пример логики распределения нагрузки:

1. Основной процесс выбирает все зарегистрированные изменения из Плана обмена.
2. Делит массив ссылок на 5 частей (по 400 документов в каждой).
3. Для каждой части запускает процедуру ФоновыеЗадания.Выполнить().

Важный нюанс: при параллельной загрузке в БП 3.0 нужно внимательно следить за блокировками, чтобы разные потоки не пытались одновременно записывать данные в одни и те же регистры (например, ДанныеИнформационныхСистем или счета учета).

Решение 4: Отложенное проведение в базе-приемнике

Проанализируем нагрузку на БП 3.0. Самая тяжелая операция — это не просто запись документа, а его Проведение. При массовой загрузке рекомендуется принимать документы в состоянии "Записан", а проведение выносить в отдельный регламентный процесс.

Рассмотрим схему:

1. УПП передает данные, БП 3.0 создает документ, заполняет его и вызывает метод Записать(РежимЗаписиДокумента.Запись).
2. В БП 3.0 настраивается регламентное задание, которое запускается в периоды минимальной активности (или постоянно с небольшим интервалом) и проводит по 50-100 документов за раз.
3. Это гарантирует, что оперативная работа бухгалтеров в базе не будет парализована транзакциями обмена.

Решение 5: Отказ от универсальных правил КД 2.0 в пользу "хардкода"

Выясним причину медленной работы при использовании Конвертации данных 2.0. Универсальные правила требуют парсинга XML и выполнения кода в обработчиках через Выполнить(), что существенно медленнее прямого обращения к реквизитам объекта. Если структура документа РеализацияТоваровУслуг стабильна, напишем прямой алгоритм заполнения объекта в коде HTTP-сервиса. Это даст прирост скорости в несколько раз.

Пример прямого заполнения на стороне БП 3.0:

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

Резюме и рекомендации

Подведем итог нашего анализа. Для надежной выгрузки большого объема реализаций из УПП 1.3 в БП 3.0 следует придерживаться следующей стратегии:

• Транспорт: HTTP-сервисы вместо COM-соединения.
• Формат: JSON для минимизации объема трафика и ускорения парсинга.
• Регистрация: Использование стандартных Планов обмена.
• Производительность: Многопоточная выгрузка через фоновые задания и отложенное проведение в приемнике.

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