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