Почему ФабрикаXDTO читает JSON на клиенте, но выдает ошибку на сервере?

← На главную

При разработке интеграций с внешними API (например, Яндекс Диском или маркетплейсами) программисты часто сталкиваются с загадочным поведением платформы 1С: один и тот же код для разбора JSON успешно выполняется на тонком клиенте, но падает с ошибкой при переносе на сервер. Рассмотрим подробнее, почему так происходит и как решить эту проблему.

Анализ ситуации и причины ошибки

Разберем типичный сценарий: вы используете ФабрикаXDTO.ПрочитатьJSON, передавая туда объект ЧтениеJSON и конкретный ТипОбъектаXDTO. На клиенте вы получаете заполненный объект, а на сервере — ошибку вида "Ошибка преобразования данных XDTO: Проверка свойства... Не установлено значение одного из следующих свойств".

Выясним причину такого поведения. На стороне сервера 1С применяет максимально строгую валидацию данных на соответствие XSD-схеме. В большинстве пакетов XDTO для типов объектов по умолчанию используется модель xs:sequence (последовательность). Это означает, что поля в JSON должны идти строго в том же порядке, в котором они описаны в пакете XDTO.

Проанализируем поведение клиента: тонкий клиент 1С зачастую использует более гибкие библиотеки для парсинга, которые могут игнорировать порядок следования ключей в JSON-объекте. Как только внешний сервис (например, Яндекс Диск) меняет порядок полей в своем ответе, серверный код 1С перестает «видеть» поля, идущие не по порядку, и считает их отсутствующими.

Способ 1. Изменение свойства пакета XDTO (рекомендуемый)

Если у вас есть доступ к редактированию конфигурации, это самое правильное решение. Посмотрим, что нужно изменить:

Откроем в конфигураторе пакет XDTO, отвечающий за интеграцию.
Найдем тип объекта, на котором происходит ошибка (например, uploadGetResponse).
В палитре свойств найдем параметр Упорядоченный (Ordered).
Установим его значение в Ложь (False).

После этого серверный парсер перестанет требовать строгую последовательность полей, и ошибка исчезнет. Пример кода, который вызывает это поведение:


&НаСервере
Процедура ПрочитатьОтветСервера(ТекстJSON)
    ЧтениеJSON = Новый ЧтениеJSON();
    ЧтениеJSON.УстановитьСтроку(ТекстJSON);
    
    // Получаем тип из пакета
    ТипОбъекта = ФабрикаXDTO.Тип("cloud-api.yandex.net/v1/disk", "uploadGetResponse");
    
    // На сервере здесь возникнет ошибка, если Упорядоченный = Истина
    ОбъектРезультат = ФабрикаXDTO.ПрочитатьJSON(ЧтениеJSON, ТипОбъекта);
КонецПроцедуры

Способ 2. Использование структур вместо XDTO

Если конфигурация закрыта на замок (на поддержке) и вы не можете менять XDTO-пакеты, а расширения не позволяют изменить контролируемое свойство "Упорядоченный", рассмотрим альтернативный путь. Можно отказаться от жесткой типизации XDTO в пользу обычных структур 1С.

Проанализируем пример кода без использования фабрики:


ЧтениеJSON = Новый ЧтениеJSON();
ЧтениеJSON.УстановитьСтроку(ТекстJSON);

// Читаем JSON напрямую в структуру
Данные = ПрочитатьJSON(ЧтениеJSON, Ложь); 

// Теперь мы можем обращаться к свойствам, порядок которых не важен
Если Данные.Свойство("operation_id") Тогда
    ИдентификаторОперации = Данные.operation_id;
КонецЕсли;

Этот метод является более надежным для REST API, так как стандарт JSON сам по себе не гарантирует порядок полей в объекте, и полагаться на него в интеграциях — рискованно.

Особенности работы с расширениями

Важно отметить, что попытка изменить свойство Упорядоченный через расширение конфигурации может привести к ошибке проверки, так как это свойство является фундаментальным для типа объекта. Если вы столкнулись с невозможностью изменения пакета, рассмотрите вариант создания собственного динамического пакета XDTO или используйте ПостроительДокументаDOM для программной модификации схемы, однако чтение в Структуру остается самым простым и эффективным способом в подобных ситуациях.