Жалоба, которую слышал каждый, кто вёл обмен между базами: "поправили справочник, а на той стороне старое". Дальше обычно проверяют регламентное задание, смотрят очередь сообщений, перезапускают обмен, в тяжёлом случае снимают регистрацию и гонят полную выгрузку. Иногда помогает. Потом повторяется.
Я полез разбираться в это на уровне файла правил и нашёл штуку, которая меня удивила. Взял типовые правила обмена "Управление торговлей - Розница" из поставки, те самые, которые лежат макетом в плане обмена. Свёл три списка, которые внутри них живут. Получилось, что из 75 объектов состава плана обмена 21 в очередь на отправку сам не встанет никогда. Среди них Контрагенты, Характеристики номенклатуры, Штрихкоды, Пользователи, Физические лица, Ценовые группы.
Это не поломка и не чей-то кривой доработанный обмен. Это то, что вы получаете из коробки.
Сначала про то, откуда берётся файл правил
Тут есть ловушка, на которой я сам однажды потерял половину дня, и о ней стоит сказать до всего остального.
Когда в настройках плана обмена стоит "использовать типовые правила", файл правил берётся из макета конфигурации. Когда стоит источник "файл", рабочие правила лежат в регистре сведений - это загруженный XML, и к макету он отношения не имеет с того дня, как его туда положили. Поиск по конфигурации при этом честно находит макет и честно показывает в нём то, что вы ищете. Вы правите макет, обновляете конфигурацию базы данных, запускаете обмен - не меняется ничего.
Подробно этот случай я разбирал отдельно в статье "Ставку поменяли в трёх базах. Хардкод об этом не знал". Здесь важен только вывод: прежде чем разбирать правила, установите, откуда их читает ваш конкретный обмен. Дальше по тексту я считаю, что файл у вас на руках - тот самый, который реально исполняется.
Три списка, которые описывают один обмен
Комплект правил "Конвертации данных 2" это не один файл, а несколько, и они описывают разные вещи. Разбирается это за минуту, но сводят их вместе редко, потому что интерфейс обмена показывает результат, а не устройство.
Состав плана обмена отвечает на вопрос, кто в принципе участвует. Это список типов, у каждого стоит признак авторегистрации. В типовых правилах УТ - Розница таких элементов 75, и авторегистрация выключена у всех 75. Это нормально для обменов по правилам: регистрацией управляют правила регистрации, а не платформа.
Правила регистрации отвечают, чьё изменение встаёт в очередь на отправку. Здесь их 79 штук на 68 разных объектов, плюс 312 условий отбора: не всякое изменение должно ехать, у многих объектов стоят условия вроде "только по своей организации" или "только проведённые".
Правила конвертации и выгрузки отвечают, что и как уходит, когда очередь уже поехала. Правил выгрузки 91, из них три выключены атрибутом, и по интерфейсу этого не видно вовсе.
Списки лежат в разных файлах и друг о друге ничего не знают. Никто не гарантирует, что объект, который стоит в первом, окажется во втором.
21 объект из 75
Свёл состав плана с правилами регистрации поимённо. Получилось 21 объект, у которого авторегистрация выключена и собственного правила регистрации нет.
Разложение важно, без него вывод звучит страшнее, чем есть на самом деле.
Восемнадцать объектов выгружаются, но своё изменение в очередь не ставят. Правило выгрузки у них есть, правило конвертации есть, то есть объект нормально уедет, когда его потянет за собой документ или полная выгрузка. А правка самой карточки очередь не создаёт:
- Контрагенты
- Характеристики номенклатуры
- Упаковки единицы измерения
- Штрихкоды номенклатуры
- Пользователи и Группы пользователей
- Физические лица и Виды документов физических лиц
- Марки, Карты лояльности, Ценовые группы
- Товарные категории, Форматы магазинов, Номенклатура сегмента
- Дополнительные сведения, Виды алкогольной продукции, Лицензии поставщиков алкогольной продукции, Правила начисления и списания бонусных баллов
У трёх нет ни правила выгрузки, ни правила регистрации: Двоичные данные файлов, Соответствия объектов информационных баз и Удалить учётная политика организаций. Первые два служебные, а третий с приставкой "Удалить" в имени - это остаток от прошлых релизов, который так и лежит в составе плана.
Практический перевод для Контрагентов. Менеджер поправил в УТ адрес доставки у контрагента. В очередь на обмен эта правка не встала. Она уедет в Розницу тогда, когда поедет любой документ, который на этого контрагента ссылается. Может через минуту, может через неделю, может никогда, если по контрагенту больше не будет движений.
Со стороны пользователя это выглядит как "обмен работает через раз". Со стороны программиста - как загадка, потому что регламентное задание отрабатывает, ошибок нет, очередь пустая. Очередь пустая по делу: туда ничего и не клали.
Это сделано специально, и это можно понять
Прежде чем ругать типовую поставку, стоит посмотреть на это с другой стороны. Регистрация каждого изменения справочника контрагентов в крупной базе - это поток сообщений, который никому не нужен: в Рознице интересен тот контрагент, по которому есть движение. Отсутствие правила регистрации здесь экономит трафик и время обмена.
Проблема не в самом решении, а в том, что оно нигде не написано. Ни в интерфейсе настройки обмена, ни в описании к правилам. Узнать о нём можно ровно одним способом: открыть файл правил и свести два списка.
И вот тут начинается то, ради чего я вообще в это полез.
Открыть файл правил глазами не получится
Возьмём боевые правила того же обмена, Розница в сторону ERP, обезличенно. Файл на 2,1 мегабайта. Внутри:
- 109 правил выгрузки данных;
- 202 правила конвертации объектов;
- 2 138 правил конвертации свойств, собранных в 118 групп;
- 415 правил конвертации значений;
- 18 алгоритмов и 8 запросов;
- 602 места с программным кодом, суммарно 234 451 символ.
Максимальная глубина вложенности XML - 14 уровней. Правила лежат в группах, группы в группах, и обход, который не делает рекурсию честно, теряет часть правил молча. Я на этом обжёгся сам, об этом ниже.
Открыть такой файл в редакторе можно. Прочитать его - нет. Даже на типовых правилах УТ - Розница, которые вдвое меньше, лежат 167 правил конвертации и 1 374 правила конвертации свойств.
Штатный способ на этот случай один: загрузить правила в "Конвертацию данных 2" и смотреть их там. Способ рабочий, но у него есть условие, которое выполняется не всегда: у вас должна быть развёрнута сама "Конвертация данных". На чужом проекте, на разборе инцидента, на базе заказчика её обычно нет, а разбираться надо сейчас.
Что видно по структуре, если её всё-таки прочитать
Кроме истории с регистрацией, в структуре видно ещё несколько вещей, и все они про потерю или порчу данных.
Правила без способа поиска. У правила конвертации есть три способа найти объект в приёмнике: по уникальному идентификатору, по полям поиска и по таблице сопоставления значений. Если не задан ни один, обмен не может понять, есть ли такой объект на той стороне, и создаёт его заново. Каждый раз. На боевых правилах Розница - ERP таких правил девять, на типовых УТ - Розница десять.
Выключенные правила выгрузки. У правила есть атрибут отключения. Выключенное правило означает, что объекты этого вида не уходят совсем. В типовых правилах таких три, в боевых два. Узнать об этом из интерфейса обмена нельзя никак: обмен отработает успешно и просто не повезёт эти объекты.
Признак "не замещать". Правило с этим признаком не перезаписывает найденный объект. Звучит безобидно и часто ставится осознанно, чтобы правка в приёмнике пережила обмен. Обратная сторона ровно та же: исправление из источника туда тоже не доедет. Два разных смысла у одного флага, и какой из них имелся в виду, по файлу не сказать.
Смена типа объекта. На боевых правилах Розница - ERP 50 правил из 202 меняют тип объекта на той стороне: склад превращается в магазин, вид цен - в правило ценообразования, подарочный сертификат - в серийный номер. Это законная конструкция обмена между разными конфигурациями, но это же и список мест, где данные меняют смысл. Если проверять обмен выборочно, проверять надо в первую очередь их.
Проверка, которую пришлось выбросить
Теперь про то, где я ошибся, потому что это важнее удачных находок.
Первая версия проверки "нет способа поиска" показала на боевом файле 72 правила. Семьдесят два правила, каждое из которых может плодить дубли - это уже не диагноз, это приговор обмену. Я почти поверил.
Стал смотреть список поимённо. В нём оказались перечисления. У перечисления полей поиска не бывает и не должно быть: оно ищется по таблице сопоставления значений, и это штатный способ. То есть проверка считала нормальную конструкцию формата поломкой.
После оговорки про перечисления осталось девять правил. Разница между 72 и 9 - это разница между инструментом, которому верят, и инструментом, который один раз напугал и после этого закрывается не глядя.
Вывод, который я отсюда забрал и держу теперь как правило: если проверка срабатывает на десятках объектов, сначала докажи, что это действительно дефект. Скорее всего ты просто не знаешь формат до конца.
Вторая ошибка была тише и опаснее. Счётчик свойств обходил дерево на семь уровней вглубь и выдавал 1 101 свойство вместо 2 138. Ровно вдвое меньше, и число при этом выглядело абсолютно правдоподобно. Поймалось это только тем, что я разобрал тот же файл независимо, на другом языке, и сравнил счётчики построчно. Совпасть они должны были до единицы. Не совпали.
Тот же приём поймал и третью ошибку, уже при подготовке этой статьи. Состав плана обмена называет объект типом значения, "РегистрСведенийЗапись.ШтрихкодыНоменклатуры", а правило регистрации - именем объекта метаданных, "РегистрСведений.ШтрихкодыНоменклатуры". Пока я не привёл их к общему виду, все регистры попадали в список "не уедут" фальшиво, и вместо 21 объекта получалось 24.
Где в правилах прячется код
И последнее, из-за чего разбор структуры имеет предел.
Мест с кодом в правилах заметно больше, чем девять глобальных обработчиков, про которые обычно помнят. Свой обработчик есть у каждого правила конвертации, у каждого правила выгрузки, у каждого отдельного свойства и у каждой группы свойств. Узел "Последовательность полей поиска" целиком состоит из кода, до 900 символов. Отдельными разделами лежат алгоритмы и запросы. В правилах регистрации код прячется в значении константы, когда у элемента отбора стоит вид "алгоритм значения".
На типовых правилах УТ - Розница это 202 места и 56 771 символ. На боевых Розница - ERP - 602 места и 234 451 символ. Двести тридцать килобайт кода, который выполняется при каждом обмене.
Отсюда граница, которую честно обозначить важнее, чем красиво её обойти. Структура правил отвечает на вопрос "что настроено". На вопрос "что произойдёт с данными" она не отвечает, потому что половину решает код. Обработчик может отменить выгрузку объекта, подменить значение реквизита, отбросить строку табличной части, и по структуре этого не видно.
Правильное поведение инструмента здесь - показать, где код есть, и не делать вид, что он понял, что этот код делает. Разбор помечает места с кодом и отдаёт их текст. Решение принимает человек.
Чем я это считал
Всё, что выше, посчитано внешней обработкой, которую я собрал под эту задачу. Она читает сам файл правил и работает в любой базе 8.3, "Конвертация данных" для неё не нужна. Разбор потоковый, файл целиком в память не грузится. Понимает оба формата: и правила конвертации, и правила регистрации.
Лежит здесь: Анализ правил обмена КД 2.
Если своих правил под рукой нет, а посмотреть хочется - возьмите типовые из своей же конфигурации. Они лежат макетами внутри плана обмена, выгружаются штатной выгрузкой конфигурации в файлы и содержат ровно те 75 объектов и 21 дыру, о которых шла речь. Проверять чужие числа на своих данных всегда полезнее, чем верить чужим числам.
Вопрос, на который у меня нет ответа
Меня не отпускает одна вещь. Отсутствие правила регистрации у Контрагентов в типовой поставке - это осознанная экономия трафика или просто никто не дошёл? Аргументы есть в обе стороны. За экономию говорит то, что список ровный: туда попали именно те объекты, которые обычно едут прицепом к документу. Против - наличие в том же списке "Удалить учётная политика организаций", а это точно не решение, это забытый хвост.
Если вы ведёте такие обмены давно и знаете, как это задумывалось, напишите. Мне интересно, где тут замысел, а где инерция.
Другие наши инструменты
- Анализ правил обмена КД 2 - обработка из этой статьи: читает файл правил конвертации или регистрации и отвечает, что выгружается, во что превращается, как ищется в приёмнике и где лежит код.
- Чек-ап чистоты базы 1С - что накопилось в базе и что из этого можно убрать без последствий.
- ИИ-анализ кода внешних обработок - разбор чужих обработок из справочника: что они делают с данными и куда ходят.
- Выгрузка структуры метаданных 1С для нейросети - конфигурация в виде, который модель читает целиком и перестаёт выдумывать реквизиты.
- Журнал регистрации, свёрнутый для нейросети - журнал в вид, который модель способна прочитать целиком.
Вступайте в нашу телеграмм-группу Инфостарт