При переходе на новые версии конфигураций 1С, использующих Библиотеку стандартных подсистем (БСП) версии 3.0 и выше, разработчики часто сталкиваются с проблемой: старые информационные базы (на базе БСП 2.x) перестают принимать сообщения обмена. Проблема проявляется в виде ошибки «Ошибка формата файла обмена» или «Несоответствие типов» уже на этапе первой синхронизации. В данной статье мы подробно разберем, почему это происходит и как «подружить» разные поколения БСП без полного обновления старой конфигурации.
Разберем ситуацию: обмен через универсальный формат (EnterpriseData) опирается на XDTO-пакеты. В БСП 3.0 разработчики фирмы «1С» расширили спецификацию заголовка сообщения. В пакете ExchangeMessage появились новые атрибуты и элементы, которые помогают системе оптимизировать обмен, но становятся «камнем преткновения» для старых парсеров. Рассмотрим основные нововведения:
Проанализируем поведение старой версии БСП. Когда база на версии 2.x считывает заголовок (Header) из XML-файла, сформированного БСП 3.0, ее XDTO-парсер натыкается на узел AvailableObjectTypes. Поскольку в локальной схеме XDTO старой базы этого поля не существует, возникает исключение, и процесс загрузки аварийно прерывается. Настройка синхронизации «виснет», так как базы не могут договориться о параметрах обмена.
Самый стабильный и правильный способ решения проблемы — это приведение XDTO-пакета ExchangeMessage в старой базе в соответствие с новой спецификацией. Нам не обязательно переносить всю сложную логику, достаточно сделать так, чтобы парсер «узнавал» новые поля и не выдавал ошибку.
Рассмотрим по шагам, как отредактировать пакет в конфигураторе старой базы:
Header (Заголовок).AvailableObjectTypes, Prefix и AvailableVersions.Минимальное количество (minOccurs) равным 0. Это сделает поля необязательными. Таким образом, старая база сможет читать файлы как от старых систем (где этих полей нет), так и от новых (где они есть).anyType (из пространства имен http://www.w3.org/2001/XMLSchema). Это позволит системе игнорировать внутреннюю структуру этих узлов, просто принимая их наличие.После внесения этих изменений и сохранения конфигурации, парсер старой БСП перестанет выбрасывать ошибку при встрече с «незнакомыми» элементами заголовка.
Как мы выяснили из практики обсуждений, первый обмен при настройке синхронизации часто является чисто техническим (сообщение с номером 0). Он предназначен для согласования версий формата. Если обновить XDTO-пакет нет возможности, можно попробовать «протолкнуть» обмен вручную.
Разберем этот алгоритм:
Однако, как показывает опыт, без правки XDTO-пакета этот путь часто приводит к повторным ошибкам на последующих итерациях обмена.
Если вы опытный разработчик и не хотите менять структуру XDTO-пакетов (например, конфигурация находится на поддержке без возможности редактирования), можно внести изменения в код обработки сообщений. Рассмотрим пример логики в общем модуле, отвечающем за чтение заголовка сообщения (обычно это ОбменДаннымиСервер или ОбменДаннымиXDTOСервер).
Проанализируем примерный код, который можно внедрить в процедуру чтения:
// Пример модификации логики чтения заголовка
Процедура ПрочитатьЗаголовокСообщения(ЧтениеXML, ПараметрыОбмена)
Попытка
// Стандартное чтение через XDTO
Заголовок = ФабрикаXDTO.ПрочитатьXML(ЧтениеXML, ФабрикаXDTO.Тип("http://www.1c.ru/SSL/Exchange/Message", "Header"));
Исключение
// Если произошла ошибка формата, попробуем пропустить неизвестные узлы
ТекстОшибки = ИнформацияОбОшибке().Описание;
ЗаписьЖурналаРегистрации("ОбменДанными", УровеньЖурналаРегистрации.Предупреждение, , , "Ошибка заголовка: " + ТекстОшибки);
// Здесь может быть реализован ручной парсинг ЧтениеXML до узла Body
Пока ЧтениеXML.Прочитать() Цикл
Если ЧтениеXML.ТипУзла = ТипУзлаXML.НачалоЭлемента И ЧтениеXML.ЛокальноеИмя = "Body" Тогда
Возврат; // Переходим к чтению тела сообщения
КонецЕсли;
КонецЦикла;
КонецПопытки;
КонецПроцедуры
Такой подход позволяет игнорировать ошибки в Header и сразу переходить к обработке Body (тела сообщения), где находятся непосредственно данные объектов. Однако стоит учитывать, что в заголовке содержится важная информация о номерах сообщений, которую придется извлекать альтернативными методами.
Посмотрим на ситуацию шире. При обмене между БСП 3.0 и БСП 2.x важно обратить внимание на выбранную версию формата EnterpriseData. БСП 3.0 по умолчанию стремится использовать самые свежие версии (например, 1.15). Старая база может поддерживать максимум версию 1.5.
Рекомендация: При настройке обмена в БСП 3.0, на этапе выбора версии формата, принудительно укажите ту версию, которую гарантированно поддерживает старая база. Это может упростить структуру сообщения и избавить от части проблем с совместимостью типов в теле письма.
Подведем итог: наиболее эффективным и долгосрочным решением является именно добавление недостающих свойств в XDTO-пакет ExchangeMessage старой конфигурации. Это устраняет причину конфликта на уровне платформенных механизмов работы с XML, сохраняя при этом целостность обмена данными.