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