Как подключить существующую базу данных к работающей РИБ и настроить выборочную синхронизацию?

← На главную

Работа с распределенными информационными базами (РИБ) в среде 1С:Предприятие 8 — стандартный способ масштабирования бизнеса, когда торговые точки, склады или филиалы должны работать автономно. Однако в процессе администрирования часто возникают нетривиальные задачи. Например, как подключить к уже функционирующей РИБ (состоящей из главной базы А и подчиненного узла А1) третью базу Б, в которой уже активно ведется учет? И как сделать так, чтобы из этой новой базы в центр уходили все документы, а обратно возвращались только определенные данные (например, дисконтные карты)?

В этой статье мы подробно разберем методологию решения обеих задач, проанализируем технические нюансы работы платформы 1С с уникальными идентификаторами объектов и рассмотрим практические примеры реализации выборочного обмена.

Часть 1. Подключение уже существующей (активной) базы к действующей РИБ

Сначала проанализируем главную ошибку, которую часто совершают начинающие специалисты. Нельзя просто объявить существующую базу Б подчиненным узлом действующей распределенной базы. Если настроить обмен напрямую, возникнет критическая коллизия — несовпадение уникальных идентификаторов (UUID / GUID).

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

Рассмотрим правильный и безопасный алгоритм слияния баз по шагам.

Выравнивание конфигураций баз данных. Перед началом любых манипуляций убедимся, что конфигурации главной базы А, существующего узла А1 и подключаемой базы Б абсолютно идентичны. Они должны иметь один и тот же релиз платформы, конфигурации и одинаковый набор доработок. При необходимости обновим базы до единого релиза.
Перенос и сопоставление данных. Нам необходимо перенести все накопившиеся документы, справочники и регистры из базы Б в центральную базу А. Для этого мы будем использовать обработку «Универсальный обмен данными в формате XML» или настроенные правила обмена в программе Конвертация данных 2.0. При настройке правил обмена крайне важно прописать корректные поля поиска. Например, для справочника Номенклатура сопоставление должно идти по коду или артикулу, для контрагентов — по связке ИНН + КПП. Это позволит объединить дублирующиеся элементы на стороне центральной базы и сохранить всю историю операций.
Создание чистого узла и начального образа. После того как все данные из базы Б успешно перенесены, проверены на дубли и сведены в главной базе А, мы создаем в плане обмена центральной базы новый узел (назовем его А2). Для этого узла мы генерируем стандартный начальный образ.
Замена базы Б созданным образом. Базу Б мы полностью прекращаем использовать для ведения учета. Вместо нее мы разворачиваем созданный начальный образ А2. Так как этот образ был сгенерирован из центральной базы, где уже объединены все данные, новая подчиненная база получит правильные UUID всех объектов и будет полностью готова к корректному двустороннему обмену без дублирования информации.

Альтернативный технический способ привязки (без создания начального образа)

Иногда создание начального образа стандартными средствами платформы невозможно или занимает слишком много времени из-за колоссального объема базы данных. В таких экспертных случаях программисты используют программную «привязку» существующей базы Б. Проанализируем этот метод.

В главной базе А мы создаем новый узел обмена. Затем в подключаемой базе Б нам необходимо принудительно установить главный узел. Для этого мы запускаем внешнюю обработку со следующим кодом:


СсылкаНаГлавныйУзел = ПланыОбмена.НайтиПоКоду("ЦЕНТР"); // Код главного узла в нашей системе
Если Не СсылкаНаГлавныйУзел.Пустая() Тогда
    ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);
    ЗаписьЖурналаРегистрации("Настройка РИБ", УровеньЖурналаРегистрации.Информация, , , "Успешно установлен главный узел");
КонецЕсли;

Важное предупреждение: этот способ крайне опасен! Сразу после выполнения этого кода базы начнут обмениваться данными. Если вы предварительно не заменили программно все UUID ключевых справочников в базе Б на UUID из базы А, ваша база мгновенно заполнится дубликатами. Использовать этот метод рекомендуется только опытным разработчикам, четко понимающим структуру метаданных конкретной конфигурации.

Часть 2. Настройка выборочной регистрации и одностороннего обмена

Перейдем ко второй задаче: как настроить обмен так, чтобы из дочерних баз в главную передавались абсолютно все изменения, а в обратную сторону (из главной в дочерние) уходили только определенные типы объектов — например, справочник ДисконтныеКарты?

Для решения этой задачи используется механизм Правил регистрации объектов (ПРО). Попытки вручную отменять регистрацию изменений не приведут к успеху, так как при любой перезаписи объекта в главной базе платформа будет автоматически регистрировать изменения для всех узлов плана обмена.

Рассмотрим два основных способа настройки выборочного обмена.

Способ 1. Использование «Конвертации данных 2.0» и механизмов БСП

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

Выгружаем структуру метаданных нашей конфигурации с помощью обработки MD85exp.epf.
Загружаем эту структуру в базу Конвертация данных 2.0.
Создаем новые правила регистрации объектов для нашего плана обмена.
В правилах регистрации для каждого объекта, который не должен уходить в подчиненные узлы (например, для документов продаж, справочника номенклатуры и т.д.), мы настраиваем обработчик события Перед регистрацией или При регистрации.

Разберем пример кода, который мы пропишем в обработчике правил регистрации для всех нежелательных к отправке объектов:


// Проверяем, является ли получатель подчиненным узлом
Если ЗначениеЗаполнено(Получатель) И Получатель <> ПланыОбмена.ЭтотУзел() Тогда
    // Если это не дисконтные карты, отменяем автоматическую регистрацию изменений
    Отказ = Истина;
КонецЕсли;

После настройки правил мы выгружаем их в файл формата .xml. В современных типовых конфигурациях (УТ 11, ERP, Розница, БП) мы переходим в раздел Администрирование -> Синхронизация данных -> Настройки синхронизации, находим наш обмен и загружаем измененные правила регистрации через пользовательский интерфейс. Система начнет применять фильтрацию автоматически при любой записи объектов.

Способ 2. Программная фильтрация в модуле Плана обмена

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

Давайте проанализируем пример программной реализации такого фильтра:


Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
    
    // Получаем тип отправляемого объекта
    ТипОбъекта = ТипЗнч(ЭлементДанных);
    
    // Разрешаем отправку только для дисконтных карт
    Если ТипОбъекта <> Тип("СправочникСсылка.ДисконтныеКарты") Тогда
        // Игнорируем отправку всех остальных типов данных
        ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
    КонецЕсли;
    
КонецПроцедуры

Этот метод гарантирует стопроцентное соблюдение логики одностороннего обмена на уровне самой платформы 1С. Даже если изменения объектов будут зарегистрированы в таблицах регистрации, при формировании файла сообщения обмена платформа обратится к этой процедуре и проигнорирует все изменения, кроме дисконтных карт.

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