Ситуация, когда после успешного обновления конфигурации в центральном узле Распределенной Информационной Базы (РИБ) подчиненный узел отказывается запускаться в режиме «Предприятие», является критической. Пользователь видит модальное окно с сообщением о необходимости синхронизации, но сам процесс обмена завершается ошибкой «Ошибка преобразования данных XML». В результате база становится недоступной для работы, так как стандартные механизмы БСП (Библиотеки стандартных подсистем) блокируют вход до завершения загрузки приоритетных данных.
В данной статье мы подробно разберем, почему возникает эта ошибка, как проанализировать файл обмена и какими способами можно восстановить работоспособность периферийного узла, сохранив при этом целостность данных.
Проанализируем текст ошибки, который обычно выводится в журнале регистрации или в окне сообщения. Как правило, стек вызова указывает на метод ПланыОбмена.ПрочитатьИзменения. Ошибка преобразования данных XML в контексте РИБ чаще всего означает несоответствие структуры объекта в файле сообщения и в базе-приемнике. Разберем наиболее частый сценарий: в центральной базе объект является элементом справочника, а в периферийной базе объект с тем же уникальным идентификатором (GUID) ошибочно создан как группа (или наоборот).
Особое внимание стоит уделить системным справочникам, таким как НаборыДополнительныхРеквизитовИСведений. Именно в них после обновлений часто меняется состав предопределенных данных. Если в подчиненном узле иерархия была нарушена, платформа не сможет записать данные элемента в объект, который она считает группой, так как у группы отсутствуют многие реквизиты. Это и вызывает исключение Ошибка преобразования данных XML.
Для начала нам необходимо точно определить, какой именно объект вызывает сбой. В тексте ошибки 1С обычно указывает путь к временному XML-файлу и конкретную строку. Рассмотрим пример из практики:
[sfile://C:/Users/USR1CV8/AppData/Local/Temp/Exchange82 {GUID}/Message_БП_Д2.xml][5992956,31]
Цифры в скобках означают номер строки (5992956) и позицию в строке (31). Нам нужно открыть этот файл (желательно использовать текстовые редакторы, способные работать с большими файлами, например, Notepad++ или специализированные XML-вьюверы). Найдем указанную строку и проанализируем фрагмент кода:
<CatalogObject.НаборыДополнительныхРеквизитовИСведений>
<Ref>20bcc873-9f5b-4308-a6b9-d91b4a54fad1</Ref>
<IsFolder>false</IsFolder>
<Description>Инвентаризация кассы</Description>
<ИмяПредопределенногоНабора>Документ_ИнвентаризацияКассы</ИмяПредопределенногоНабора>
</CatalogObject.НаборыДополнительныхРеквизитовИСведений>
Здесь мы видим, что из центра передается элемент (IsFolder = false). Если в периферийной базе объект с GUID 20bcc873-9f5b-4308-a6b9-d91b4a54fad1 является группой, загрузка прервется. Выяснив это, мы можем переходить к активным действиям.
Так как модальное окно синхронизации не дает нам войти в базу, чтобы запустить обработку или проверить данные, воспользуемся параметрами запуска. В окне выбора информационной базы нажмем кнопку «Изменить» и на последней вкладке в поле «Дополнительные параметры запуска» введем специальные ключи, которые поддерживаются конфигурациями на базе БСП:
После ввода параметров запустим базу. Теперь мы можем открыть «Все функции» (или «Функции для технического специалиста») и найти справочник Наборы дополнительных реквизитов и сведений. Проверим объект, найденный на предыдущем шаге. Если он действительно является группой, его нужно либо удалить (если это допустимо), либо программно изменить его тип, что технически сложно. Чаще всего помогает удаление ошибочного объекта, чтобы при следующем обмене он создался корректно из сообщения.
Если мы не хотим или не можем манипулировать данными напрямую в периферийной базе, рассмотрим метод «чистой выгрузки конфигурации». Проанализируем этот алгоритм:
Если параметры запуска не помогают, мы можем попытаться подключиться к периферийной базе через COM-соединение из другой базы или с помощью скрипта, чтобы программно удалить конфликтующий объект. Рассмотрим пример кода, который можно выполнить в контексте внешней базы для очистки битого объекта:
// Пример кода для удаления объекта в периферийной базе через COM
ПутьКБазе = "File=""C:\Bases\PeripheralBase"";";
V83 = Новый COMОбъект("V83.ComConnector");
БазаПодключения = V83.Connect(ПутьКБазе + "Usr=""Admin"";Pwd=""123"";");
Идентификатор = "20bcc873-9f5b-4308-a6b9-d91b4a54fad1";
СсылкаНаОбъект = БазаПодключения.StringRefToRef(Идентификатор); // Нужно преобразование строки в ссылку
Если Не СсылкаНаОбъект.Пустая() Тогда
Объект = СсылкаНаОбъект.ПолучитьОбъект();
Объект.Удалить();
Сообщить("Объект успешно удален в периферийной базе");
КонецЕсли;
Важный нюанс: при использовании РИБ на базе БСП часто возникает ошибка Access Denied при попытке COM-подключения, если система находится в состоянии ожидания обновления. В этом случае приоритетным остается метод с параметрами запуска /C.
Если ни один из способов не позволяет войти в базу, разберем метод временного перевода периферийного узла в режим автономной работы. Это снимет все блокировки запуска. Выполним следующие действия:
/C ОтключитьЛогикуНачалаРаботыСистемы.ПланыОбмена.УстановитьГлавныйУзел(Неопределено);.Инвентаризация кассы.ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентральныйУзел);.Проанализировав ситуацию, мы видим, что проблема чаще всего кроется в рассинхронизации предопределенных данных. Использование команд ПланыОбмена.ПрочитатьИзменения платформой 8.3 стало более строгим к типам данных, поэтому малейшее расхождение «Группа/Элемент» приводит к остановке всего процесса обмена. Рекомендуем всегда проверять актуальность структуры справочников Наборы дополнительных реквизитов и Идентификаторы объектов метаданных перед массовым обновлением распределенной сети.