Как в Конвертации Данных 3.0 (EnterpriseData) установить порядок загрузки документов?

← На главную

При переходе с редакции 2.0 (КД2) на редакцию 3.0 (КД3) многие разработчики сталкиваются с отсутствием привычных инструментов. Один из самых частых вопросов: «Где настройка порядка загрузки объектов?». В КД2 у правил конвертации объектов (ПКО) был числовой реквизит «Порядок», который определял очередность записи данных в базу приемника. В КД3 этого реквизита нет, что вызывает недоумение.

Давайте разберемся, почему так произошло, как теперь работает механизм загрузки и какими способами мы можем повлиять на очередность обработки документов в формате EnterpriseData.

Почему в КД3 нет явного «Порядка загрузки»?

Для начала проанализируем архитектурные отличия. «Конвертация данных 2.0» работала по жесткому принципу: данные выгружались в XML, и при загрузке система пыталась записывать их последовательно. Если мы пытались загрузить документ, который ссылается на еще не созданный справочник, возникала проблема (либо битая ссылка, либо ошибка). Поэтому порядок был критически важен.

В «Конвертации данных 3.0» (использующей формат EnterpriseData и механизмы БСП) реализован принцип отложенной загрузки (отложенной записи). Рассмотрим, как это работает:

Система читает пакет данных (файл XML/JSON).
Если при разборе объекта встречается ссылка на другой объект (например, в документе «Реализация» есть ссылка на «Договор»), система проверяет наличие этого «Договора» в базе.
Если «Договор» еще не существует, система не выдает ошибку. Она помещает «Реализацию» в специальную очередь отложенной обработки.
Загрузка продолжается. Как только «Договор» придет (в этом же или следующем пакете) и запишется, система вернется к очереди и попытается снова записать «Реализацию».

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

Когда все-таки нужно управлять порядком?

Несмотря на "умный" механизм, бывают ситуации, когда порядок важен для бизнес-логики:

Хронология проведения: Нам нужно, чтобы документы проводились строго по времени (например, сначала поступление, потом реализация), чтобы не уйти в «минуса» и правильно рассчитать себестоимость.
Блокировки данных: При больших объемах параллельной загрузки.
Специфическая логика при записи: Когда в событии ПередЗаписью используется запрос к данным, которые должны быть уже в базе.

Рассмотрим способы, которыми мы можем решить эту задачу.

Способ 1: Управление порядком на этапе выгрузки (Источник)

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

Для этого нам нужно обратиться к Правилам регистрации объектов (ПРО) в конфигурации-источнике или в правилах конвертации.

Разберем, как это сделать:

В правилах регистрации для нужного типа документа мы можем использовать произвольный алгоритм выборки.
В этом алгоритме мы пишем запрос, который выбирает данные, и в этом запросе используем конструкцию УПОРЯДОЧИТЬ ПО.

Пример концептуального кода в обработчике выборки данных для выгрузки:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |    Док.Ссылка КАК Ссылка
    |ИЗ
    |    Документ.РеализацияТоваровУслуг КАК Док
    |ГДЕ
    |    Док.Ссылка В (&МассивСсылок)
    |
    |УПОРЯДОЧИТЬ ПО
    |    Док.Дата ВОЗР"; // Сортируем по дате, чтобы старые документы попали в файл первыми

Запрос.УстановитьПараметр("МассивСсылок", МассивОбъектовДляВыгрузки);
Результат = Запрос.Выполнить();
// Далее передаем результат в механизм выгрузки

Таким образом, в файл обмена документы попадут в хронологическом порядке. При загрузке БСП попытается обработать их в той же последовательности (если не вмешается механизм отложенной записи из-за нехватки ссылок).

Способ 2: Программное управление в Менеджере обмена (Приемник)

Это наиболее мощный и правильный способ для КД3. Логика обмена в конфигурациях на базе БСП вынесена в общий модуль МенеджерОбменаЧерезУниверсальныйФормат. Если вы разрабатываете правила для типовой конфигурации, вам, возможно, придется использовать расширение для перехвата методов этого модуля.

Нас интересуют процедуры загрузки. Рассмотрим основные точки входа:

ПередЗаписьюПолученныхДанных
ПриКонвертацииДанныхXDTO
ПриОбработкеОчередиОтложеннойЗаписи

Если вам нужно жестко задать приоритет, вы можете анализировать тип загружаемого объекта. Посмотрим на примерную логику, которую можно реализовать в процедуре конвертации:


Процедура ПриКонвертацииДанныхXDTO(ДанныеXDTO, ПолученныеДанные, КомпонентыОбмена, СтекВыгрузки) Экспорт
    
    // Определяем тип объекта
    ТипОбъекта = ДанныеXDTO.Тип();
    
    // Если это наш документ, который нужно грузить позже всех
    Если ТипОбъекта = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
        
        // Можем проверить условие.
        // Если условия не выполнены (например, нет остатков), 
        // мы можем принудительно отказаться от записи сейчас 
        // и оставить объект на потом (механизм сам это сделает, если мы не запишем объект).
        
        // Либо мы можем принудительно вызвать проведение связанных документов.
        
    КонецЕсли;

КонецПроцедуры

В типовых конфигурациях (ERP, КА, УТ) в этом модуле уже прописан порядок обработки пакетов: сначала Справочники, ПВХ, потом Документы, потом Регистры сведений. Это «зашито» на уровне обработки формата EnterpriseData.

Способ 3: Разделение правил обмена

Если программировать модуль менеджера сложно или невозможно (базовая версия, запрет на доработки), воспользуемся организационным решением, предложенным в обсуждении.

Создадим две настройки обмена (два узла плана обмена или две настройки синхронизации):

Настройка №1: Выгружает только НСИ (Справочники) и документы-основания (например, «Заказы»).
Настройка №2: Выгружает зависимые документы (например, «Реализации», «Поступления»).

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

Заключение

В КД 3.1 нет поля «Порядок загрузки», потому что парадигма обмена изменилась. Система рассчитана на асинхронность и отсутствия жестких связей в момент чтения файла.

Резюмируем план действий:

Если проблема в «битых» ссылках — доверьтесь платформе, механизм отложенной загрузки БСП должен решить это сам.
Если проблема в хронологии проведения — настройте сортировку по дате в правилах регистрации на стороне Источника (в запросе выборки).
Если нужна сложная логика — внедряйтесь в модуль МенеджерОбменаЧерезУниверсальныйФормат на стороне Приемника.