Предыстория: Случилось ЧП. В центральной базе сети магазинов пропали цены на большую часть номенклатуры. Магазины выполнили обмен и тоже лишились цен. Торговля встала. Как выяснилось, в одном из филиалов товаровед удалил "лишние" документы. Соглашусь, здесь явный недостаток в настройке обменов. Этих "лишних" документов у филиала вобще не должно было быть. Но проблему нужно решать и быстро. Решение лежало на поверхности. Раз документы пропали после обмена, надо поискать узел, который не успел загрузить "убийственный" пакет, перепровести документы, каким-то образом проигнорировать загрузку изменений из центральной базы и выгрузить обратно нужные документы. Увы, таких узлов не оказалось. Нужные документы остались только в бэкапах.
Идея: У нас есть бэкап с нужными документами. Мы знаем, что эти документы ходят по обменам через РИБ. Писать обработку для переноса документов нет времени. Попробуем обмануть РИБ и переслать эти документы через файл сообщения, как-будто из периферийной базы.
Реализация: Оповещаем всех, чтобы не делали обмены в рабочей базе. В резервной копии открываем планы обмена, любой рабочий узел. Я использовал узел филиала "виновника", пусть знает. Штатными средствами удаляем все зарегистрированные изменения по выбранному узлу. В УТ 2.3 (10.3 - для России) это делается на форме "Регистрация изменений для плана обмена" (Иконка мониторчик). В других конфигурациях должны быть свои средства. Если же таких средств нет, то можно написать простейшую обработку с кодом:
Процедура УдалитьРегистрацию()
ПланыОбмена.УдалитьРегистрациюИзменений(ВыбУзел);
КонецПроцедуры
Далее при помощи групповой обработки справочников и документов перепроводим нужные документы. Если такой обработки нет, то ее также недолго накидать. После перепроводки у нас в плане обмена зарегистрируются нужные изменения. Причем нам не надо переживать за ссылочную целостность. Мы работаем в старой версии рабочей базы. Все справочники, на которые будут ссылаться передаваемые объекты в любом случае есть в рабочей базе.
Далее надо настроить обмен по выбранному узлу на обмен через локальный ресурс, и отключить сжатие исходящих сообщений. В УТ 2.3 это настраивается так:
В указанной папке мы получаем файл xml с наименованием, наподобие Message_Цнт_К2.xml. После первого подчеркивания идет код базы отправителя, после второго - код получателя. Переименовываем файл в Message_К2_Цнт.xml. Таким образом механизм РИБ будет считывать этот файл как сообщение от периферийной базы. Но это еще не все. Открываем этот файл при помощи текстового редактора и вносим правки:
Атрибут v8msg:To - код узла получателя, v8msg:From - код узла отправителя. Меняем значения в них местами.
Атрибут v8msg:MessageNo - номер отправленного сообщения, v8msg:ReceivedNo - номер полученного сообщения. Меняем номер отправленного сообщения. Он должен быть больше номера полученного сообщения, чтобы механизм РИБ загрузил изменения из этого файла. Можно поставить заведомо большое число, например 99999. Главное запомнить, какой номер принятого был до этого.
Если попытаться скормить полученный файл базе, то получим ошибку. Точный текст не помню, но что-то вроде "Ошибка представления". Путем сравнения файлов сообщений от центральной базы и от периферийной было определено, что узел v8de:Nodes отсутствует в сообщении от периферийной базы. Удаляем этот узел из файла сообщения.
Для тех, кто незнаком с xml-разметкой. "Узел" - это текст, который заключен между одинаковыми открывающим и закрывающим тегами, включая сами теги. "Тег" - это текст в угловых скобках <>. У закрывающего тега перед именем есть косая черта /. В данном случае из файла надо удалить текст от <v8de:Nodes> по </v8de:Nodes> включая указанные конструкции.
Теперь в рабочей базе в настройках обмена данными для того же узла устанавливаем те же настройки. Тот же каталог обмена и отключаем сжатие.
Выполняем обмен данными. На этом этапе удаленные данные уже должны быть восстановлены путем переноса из файла сообщения РИБ.
Осталось только вернуть настройки обмена данными как было. И не забыть вернуть номер принятого сообщения в узле обмена на прежний.
Итоги: У этого способа есть ряд очевидных ограничений.
- Должен быть настроен и использоваться обмен РИБ.
- Удаленные данные должны быть включены в актуальный обмен РИБ.
- Конфигурация резервной копии и рабочей базы должны совпадать. Если не совпадают, то надо выгрузить CF-файл из рабочей и загрузить в резервную копию.
Понимаю, что открытия Америки не произошло. Скорее всего способ банальный, но все-таки надеюсь, что кому-нибудь в случае аврала пригодится. Не забывайте делать резервные копии. Любые советы в интернете проверяйте на тестовых базах.
