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