При работе с обменами данными на базе Библиотеки стандартных подсистем (БСП), где важно организовать мониторинг синхронизаций данных, разработчики часто сталкиваются с ситуацией: данные в документе или справочнике изменены, но объект не попадает в план обмена (хотя в некоторых случаях выручает регистрация объектов из плана обмена с формы). При этом, если изменить «ключевые» поля (например, дату или организацию), регистрация срабатывает штатно. Выясним причину такого поведения, проанализируем работу механизма выборочной регистрации и разберем по шагам, как заставить систему «видеть» изменения нужных нам полей, используя в том числе портативный обозреватель правил конвертации свойств.
Механизм выборочной регистрации — это встроенная оптимизация БСП, предназначенная для минимизации лишнего трафика. Рассмотрим ситуацию: в документе изменился служебный реквизит, который вообще не передается в базу-приемник. В этом случае системе нет смысла ставить объект в очередь на выгрузку, для которой обычно применяется универсальная регистрация справочников/документов к обмену. БСП анализирует правила обмена и формирует список «значимых» реквизитов. Если при записи объекта выясняется, что ни один из значимых реквизитов не изменился, объект не регистрируется на узле плана обмена.
Проблема возникает тогда, когда реквизит фактически выгружается (например, через обработчики), но система не считает его значимым из-за особенностей настройки Правил Конвертации Объектов (ПКО).
Разберем основную причину: механизм БСП строит список отслеживаемых полей, опираясь на Правила Конвертации Свойств (ПКС). Чтобы реквизит считался значимым, он должен быть явно указан в ПКС, и у него должно быть заполнено поле Источник. Рассмотрим типичные ошибки:
ПередВыгрузкой, где значение присваивается напрямую переменной Значение, а поле Источник в ПКС оставлено пустым.ПриВыгрузке.EnterpriseData (XDTO), где состав полей определяется схемой, а не жестким списком ПКС.Самый правильный и «чистый» способ — это обеспечить наличие реквизита в списке источников. Если вы используете программное вычисление значения, но хотите, чтобы изменение исходного реквизита вызывало регистрацию, выполните следующие действия:
Источник (имя реквизита в текущей конфигурации).ПередВыгрузкой, установив Значение = .... Наличие заполненного поля Источник заставит БСП добавить этот реквизит в параметр сеанса ПравилаВыборочнойРегистрацииОбъектов.Лайфхак: Если реквизит в приемнике вообще не нужен, но его изменение должно провоцировать выгрузку объекта (например, для запуска логики на стороне приемника), можно создать ПКС, указать Источник, но установить флаг «Отключить». Как показывает практика, даже отключенные ПКС с заполненным источником часто попадают в кэш регистрации БСП.
Часто объекты не регистрируются при изменении данных в строках табличных частей. Чтобы система отслеживала эти изменения, необходимо убедиться, что для табличной части создано соответствующее правило (ПКГС — правила конвертации групп свойств). Рассмотрим пример кода, который часто используется для обхода ограничений, когда структура ТЧ источника и приемника сильно отличается:
// В обработчике ПередВыгрузкой ПКГС (табличной части)
КоллекцияОбъектов = Новый Массив;
КоллекцияОбъектов.Добавить(Источник.Товары[0]); // Пример инициализации
// В ПКС этой табличной части указываем Источник явно
Значение = Источник.Количество;
Чтобы БСП «понимала», что табличную часть нужно мониторить, в правилах конвертации должен быть создан объект метаданных ТЧ с перечислением её реквизитов-источников.
Если ваши правила слишком сложны и вы не хотите тратить время на доработку каждого ПКС, механизм выборочной регистрации можно отключить целиком для конкретного обмена. Проанализируем, как это сделать:
Правила для обмена данными.После этого система будет регистрировать объект при любой его записи, независимо от того, какие именно поля изменились. Это увеличит трафик, но гарантирует доставку изменений.
Важно помнить, что правила выборочной регистрации кэшируются в параметрах сеанса для повышения производительности. Если вы изменили правила конвертации или переключили флаг в регистре, изменения могут не вступить в силу немедленно. Рассмотрим, как программно сбросить этот кэш без перезапуска всех активных пользователей:
// Вызов метода для очистки кэша правил выборочной регистрации
ОбменДаннымиПовторноеИспользование.СброситьКэшПравилВыборочнойРегистрацииОбъектов();
В клиент-серверном варианте также помогает перезапуск сеанса пользователя, так как параметр сеанса ПравилаВыборочнойРегистрацииОбъектов инициализируется при старте.
В современных конфигурациях на БСП 3.0+ при использовании EnterpriseData (XDTO) логика может отличаться. Если в классической «Конвертации 2.0» регистрация завязана на ПКС, то в XDTO-обменах список реквизитов регистрации часто определяется составом полей, входящих в соответствующие пакеты XDTO. Если вы столкнулись с проблемой в XDTO-обмене, проверьте, включены ли нужные реквизиты в состав выгрузки в модуле менеджера плана обмена (в переопределяемых методах формирования состава данных).
Проанализируем ситуацию в режиме отладки. Чтобы понять, какие именно поля БСП считает «важными» для регистрации конкретного документа, можно воспользоваться Табло. Вычислите следующее выражение:
ПараметрыСеанса.ПравилаВыборочнойРегистрацииОбъектов.ДоступныеЗначения
Там вы увидите таблицу или структуру, содержащую перечень объектов метаданных и список реквизитов через запятую. Если вашего реквизита нет в этом списке — регистрация по нему не произойдет никогда.
Подведем итог: Для стабильной работы обмена старайтесь всегда указывать Источник в ПКС, даже если вы используете обработчики для трансформации данных. Это самый надежный способ подружить ваши кастомные правила с оптимизацией БСП.