При возникновении задачи по слиянию нескольких информационных баз в одну (например, при реорганизации компании или переходе на централизованный учет), многие разработчики первым делом обращают внимание на механизм распределенных информационных баз (РИБ). Кажется логичным: конфигурации идентичны, план обмена Полный уже существует, достаточно просто «подцепить» базы и нажать кнопку. Однако здесь разработчики сталкиваются с первой технической загадкой — отсутствием привычных правил обмена в формате XML, созданных в «Конвертации данных».
В этой статье мы подробно разберем, почему классический РИБ не всегда является лучшим инструментом для слияния данных, как на самом деле работает обмен в распределенных системах и какие альтернативные способы помогут нам избежать главной проблемы — массового появления дублей справочников (номенклатуры, контрагентов и прочего).
Рассмотрим внутреннее устройство механизма РИБ. В отличие от универсального обмена данными, где используются правила выгрузки (ПВД) и правила конвертации объектов (ПКО), распределенная база работает по принципу XDTO-сериализации. Проанализируем, почему это сделано именно так:
СправочникОбъект.Контрагенты) и «сериализует» его в XML-поток «как есть». Этот поток содержит значения всех реквизитов, табличных частей и, что самое важное, уникальный идентификатор (GUID).УникальныйИдентификатор(). Если он найден — объект обновляется, если нет — создается новый.Именно поэтому в конфигураторе для плана обмена Полный мы видим только правила регистрации. Они отвечают лишь за то, какой объект должен «полететь» в обмен, но не за то, как он должен трансформироваться.
Выясним основную причину, по которой использование РИБ для слияния ранее независимых баз — плохая идея. Представим, что в базе №1 и в базе №2 есть контрагент «ООО Ромашка» с одинаковым ИНН. Поскольку базы создавались независимо, их GUID (внутренние ссылки) гарантированно разные. При попытке слить их через РИБ в одной базе появятся две «Ромашки». Если документов тысячи, ручная очистка превратится в кошмар.
Тем не менее, если вы все же решили использовать механизмы плана обмена, мы можем вмешаться в процесс программно через модуль плана обмена.
Хотя правил обмена нет, платформа предоставляет события, в которых мы можем «перехватить» данные. Разберем основные методы, которые можно использовать в модуле плана обмена:
Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
// Здесь можно отфильтровать ненужные данные
Если ТипЗнч(ЭлементДанных) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
Если ЭлементДанных.Дата < '20230101' Тогда
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Процедура ПриПриемеДанныхОтПодчиненного(ЭлементДанных, ОтправкаЭлемента, СтандартнаяОбработка)
// А здесь можно попытаться реализовать свою логику сопоставления
// Но будьте осторожны: прямая подмена GUID в процессе загрузки РИБ крайне затруднена
КонецПроцедуры
Важно понимать: вмешательство в ПриПриемеДанныхОтПодчиненного позволяет изменить значения реквизитов принимаемого объекта, но стандартный механизм поиска платформы по GUID все равно сработает раньше или параллельно. Для полноценного решения проблемы дублей этот путь считается наиболее трудозатратным и рискованным.
Если ваши конфигурации современные (на базе БСП), проанализируем возможность использования формата Enterprise Data. В отличие от РИБ, этот механизм изначально проектировался для обмена между разными системами, и в нем заложена гибкая логика сопоставления.
Посмотрим на преимущества этого метода:
СоответствиеОбъектовИнформационныхБаз. Если объект один раз был сопоставлен по ИНН, в следующий раз он обновится корректно, даже если GUID разные.Зачастую самым быстрым техническим решением является объединение баз без попыток сопоставления «на лету», с последующим использованием инструментов БСП. Разберем этот алгоритм по шагам:
ВыгрузкаЗагрузкаДанныхXML.epf. Она просто перенесет все объекты со своими GUID в целевую базу.Поиск и удаление дублей (входит в состав БСП, раздел «Администрирование — Обслуживание»).Преимущество метода: Вы гарантированно не потеряете целостность данных, так как платформа корректно перепроводит ссылки в базе.
Рассмотрим этот вариант, если слияние — это не разовая акция, а процесс, который будет длиться долгое время. КД 3.0 работает на базе формата Enterprise Data. В ней правила сопоставления описываются в модуле менеджера обмена. Это позволяет реализовать очень сложную логику: например, искать контрагента сначала по ИНН, а если он пустой — по наименованию, а если и там нет совпадений — создавать новый объект.
Для работы с КД 3.0 вам потребуется:
Подводя итог, проанализируем ситуацию: если ваша цель — быстро слить базы и забыть об этом, не пытайтесь «допилить» РИБ. Используйте Enterprise Data или перенос через XML с последующей «чисткой» дублей средствами БСП. Это сэкономит время и убережет от ошибок в ссылочной целостности базы данных.
Помните, что механизм РИБ создавался для поддержки распределенной структуры, где объекты рождаются в одном месте и тиражируются в другие под жестким контролем идентификаторов. Для задачи «сшивания» независимых миров он слишком прямолинеен.