Как отказаться от загрузки конкретного объекта при обмене через Универсальный формат (EnterpriseData)?

← На главную

При переходе с традиционной технологии «Конвертация данных 2.1» на «Конвертацию данных 3.0» (формат EnterpriseData) многие разработчики сталкиваются с отсутствием привычных механизмов. В классической КД 2.1 в обработчиках событий (например, «ПередЗагрузкой» или «ПослеЗагрузкиОбъекта») присутствовал явный параметр Отказ = Истина;, позволяющий пропустить создание или обновление объекта в базе данных. В процедурах общего модуля менеджера обмена через универсальный формат (например, МенеджерОбменаЧерезУниверсальныйФормат) подобного параметра во входящих аргументах нет, и простая инициализация переменной Отказ = Истина; ни к какому результату не приводит.

Разберем, как устроен механизм загрузки данных в КД 3.0, как программно отменить загрузку конкретного объекта и какие архитектурные нюансы необходимо учитывать.

Отказ от загрузки объекта в процедурах правил обработки данных (ПОД)

Выясним причину, почему нельзя просто отказаться от записи в событиях правил конвертации объектов (ПКО). На этапе ПКО объект уже десериализуется из пакета XDTO и преобразуется в структуру данных информационной базы. Чтобы пропустить обработку элемента без ошибок, отказ нужно оформить раньше — на этапе сопоставления правил обработки данных (ПОД).

Рассмотрим структуру события ПОД_<ИмяОбъекта>_ПриОбработке. В этот обработчик передаются три параметра:

ДанныеXDTO — входящие данные в формате XML/XDTO, которые можно проанализировать перед загрузкой;
ИспользованиеПКО — структура или коллекция флагов, определяющая, какие правила конвертации объектов будут задействованы для данного типа данных;
КомпонентыОбмена — служебная структура с контекстом текущего сеанса синхронизации.

Если проанализировать условия (например, реквизиты контрагента, организации, суммы или комментарии) и сбросить все связанные с этим объектом флаги в структуре ИспользованиеПКО в значение Ложь, механизм обмена пропустит создание и обновление данного объекта.

Посмотрим на практический пример кода в общем модуле менеджера обмена для документа «Реализация товаров и услуг» на стороне конфигурации «Бухгалтерия предприятия 3.0»:


Процедура ПОД_Документ_РеализацияТоваровУслуг_ПриОбработке(ДанныеXDTO, ИспользованиеПКО, КомпонентыОбмена)

    // Анализируем входящие данные документа.
    // Обратите внимание: функция СтрНайти является современной заменой устаревшей функции Найти.
    Если СтрНайти(ДанныеXDTO.Контрагент.Наименование, "***") > 0 Тогда
        
        // Отключаем все возможные варианты ПКО, которые могут обработать данный документ:
        ИспользованиеПКО.Документ_РТиУБезПереходаПравСобственностиУслуги = Ложь;
        ИспользованиеПКО.Документ_РеализацияОтгруженныхТоваров_Получение = Ложь;
        ИспользованиеПКО.Документ_РеализацияТоваровУслуг = Ложь;
        
        Возврат;
        
    КонецЕсли;

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

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

Особенности и ограничения пропуска объектов через ПОД

Проанализируем важные нюансы, с которыми можно столкнуться при использовании данного подхода:

Объекты верхнего уровня vs ссылочные данные: Обработчик ПОД_..._ПриОбработке вызывается только для самостоятельных объектов верхнего уровня файла обмена. Если объект поступает в пакете только как ссылка внутри реквизита другого документа или справочника, правила обработки данных для него не вызываются, и он всё равно может быть загружен по цепочке правил конвертации объектов.
Сопутствующая нормативно-справочная информация: Если в XML-пакете вместе с документом выгружаются новые элементы справочников (контрагенты, номенклатура, договоры), то отказ от загрузки самого документа в ПОД не отменяет загрузку этой НСИ. Справочники, пришедшие отдельными объектами пакета, успешно запишутся в базу-приемник, оставшись без привязки к отмененному документу.
Попытка отказа в ПКО «ПередЗаписьюПолученныхДанных»: В КД 3.0 на уровне ПКО в обработчике ПередЗаписьюПолученныхДанных(ПолученныеДанные, ДанныеИБ, ...) можно предотвратить перезапись уже существующего в базе объекта (когда ДанныеИБ <> Неопределено), присвоив ПолученныеДанные = Неопределено;. Однако для новых элементов (когда ДанныеИБ = Неопределено) такой прием часто приводит к ошибке записи или сбою транзакции. Отменять загрузку принципиально новых объектов следует именно на уровне ПОД.

Альтернатива: фильтрация на стороне источника

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

Правила регистрации объектов (ПРО): В обработчиках регистрации изменений на стороне источника доступен стандартный флаг Отказ = Истина;. В этом случае документ даже не регистрируется на узле плана обмена.
ПОД на стороне источника: В процедурах ПОД_..._ПриОбработке базы-отправителя можно также отключить правила конвертации, предотвратив включение объекта в исходящее сообщение.
Пользовательские фильтры: Использование типовых настроек фильтрации на узле синхронизации (по организациям, складам, подразделениям), которые не требуют изменения программного кода.

Как внести изменения без снятия конфигурации с поддержки

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

Подключение модуля через внешнюю обработку: В типовых конфигурациях (включая «1С:Бухгалтерию предприятия 3.0») в подсистеме обмена данными предусмотрена возможность подключать внешние модули правил. Это позволяет сохранять типовую конфигурацию на полной поддержке. Однако при таком подходе необходимо контролировать дату правил в первой строке модуля при обновлениях релиза.
Расширения конфигурации: Для перехвата процедур модуля МенеджерОбменаЧерезУниверсальныйФормат можно использовать аннотации &Вместо или &После в расширении (если версия режима совместимости конфигурации поддерживает работу с общими модулями).
Подписки на события: В крайнем случае можно использовать подписку на событие ПередЗаписью документа с проверкой флага ОбменДанными.Загрузка = Истина и установкой Отказ = Истина;, однако это зафиксирует ошибку в журнале регистрации обмена данными, в отличие от штатного пропуска через правила ПОД.