Почему при выполнении регламентного задания XDTO объект не видит свойства при интеграции с 1С:Документооборот?

← На главную

При разработке интеграции между учетной системой и «1С:Документооборот» (1С:ДО) часто используется механизм веб-сервисов и XDTO-пакетов. Одной из самых коварных проблем, с которой мы можем столкнуться, является ситуация, когда один и тот же программный код работает корректно в интерактивном режиме (под пользователем), но падает с ошибкой «Поле объекта не обнаружено» при запуске в фоновом или регламентном задании. Давайте подробно разберем, почему свойства XDTO могут «исчезать» и как грамотно настроить систему, чтобы избежать подобных ошибок. При необходимости можно воспользоваться готовым примером вызова веб-сервисов 1С:ДО из фонового задания.

Суть проблемы: код работает, но не всегда

Рассмотрим типичный сценарий. Мы настраиваем бесшовную интеграцию и хотим получить список документов из 1С:ДО с определенными свойствами. Для этого мы используем прокси-объект и формируем запрос DMGetDocumentListRequest. В коде мы явно указываем, какие колонки (свойства) нас интересуют.

Взглянем на пример кода, который вызывает вопросы:


// Создаем запрос к веб-сервису 1С:ДО
Запрос = ИнтеграцияС1СДокументооборотБазоваяФункциональность.СоздатьОбъект(МоёПрокси, "DMGetDocumentListRequest");

// Указываем, какие свойства хотим получить
ЗапрашиваемыеСвойства = Запрос.columnSet;
ЗапрашиваемыеСвойства.Добавить("confirmed"); // Нас интересует статус утверждения

// Добавляем объект, по которому нужен запрос
СписокОбъектов = Запрос.externalObjects;
СписокОбъектов.Добавить(ИнтеграцияС1СДокументооборотБазоваяФункциональность.СоздатьExternalObject(МоёПрокси, СсылкаНаДокумент));

// Выполняем запрос
Результат = ИнтеграцияС1СДокументооборотБазоваяФункциональность.ВыполнитьЗапрос(МоёПрокси, Запрос);

Когда мы запускаем этот код под своей учетной записью (у которой обычно полные права или права администратора), в полученном объекте XDTO присутствует свойство confirmed. Однако стоит перенести этот код в регламентное задание, как при обращении к Результат.confirmed (или внутри коллекции объектов) мы получаем ошибку.

Технический анализ: куда исчезает свойство?

Чтобы понять причину, нам нужно углубиться в то, как платформа 1С и веб-сервис DMService (стандартный сервис интеграции ДО) обрабатывают запросы.

1. Динамическая генерация XML-ответа
Веб-сервис 1С не возвращает статическую структуру. При формировании ответа сервер 1С:ДО проверяет права доступа текущего пользователя к каждому запрошенному реквизиту. Это работа механизма RLS (Record Level Security — ограничение прав доступа на уровне записей).

2. Сериализация и RLS
Если у пользователя, под которым выполняется запрос, нет прав на чтение конкретного поля (например, поля «Утвержден» — confirmed), то сервер просто не включает соответствующий XML-тег в ответ. Платформа 1С работает по принципу: «чего не вижу, того не отдаю».

3. Десериализация в XDTO
На стороне принимающей базы (где работает наше регламентное задание) фабрика XDTO получает XML-ответ. В схеме данных свойство confirmed, скорее всего, помечено как необязательное (атрибут minOccurs="0"). Поскольку тега в XML нет, свойство в объекте XDTO не создается физически.

Именно поэтому проверка на Неопределено часто не срабатывает, а попытка обращения к свойству вызывает исключение: свойства просто нет в структуре объекта в памяти.

Роль контекста выполнения: Регламентное задание vs Интерактивный сеанс

Ключевое различие кроется в том, кто авторизуется в веб-сервисе 1С:ДО.

Интерактивный режим: Когда мы запускаем обработку вручную, используется «текущий пользователь». Настройки интеграции часто сопоставляют вашего пользователя в ERP/УТ с пользователем в ДО. Если у вас права администратора, вы видите все поля.
Регламентное задание: Оно выполняется на сервере. У него нет «текущего пользователя» в привычном смысле. Авторизация в веб-сервисе происходит под учетной записью, указанной в настройках подключения (технический пользователь), либо под пользователем, от имени которого запущено само регламентное задание.

Если в настройках бесшовной интеграции или в коде коннектора не прописан явно логин и пароль служебного пользователя с достаточными правами, подключение может происходить с ограниченными правами. В результате срабатывает RLS, и часть данных обрезается на уровне формирования XML.

Решение проблемы: настройка прав и кода

Для исправления ситуации нам необходимо выполнить комплекс действий, касающихся как администрирования прав, так и доработки программного кода для повышения отказоустойчивости.

Шаг 1. Проверка и настройка прав доступа в 1С:Документооборот

Это основное решение проблемы. Нам нужно обеспечить пользователя, под которым работает регламентное задание, необходимыми правами. При возникновении системных сбоев с применением настроенных прав можно использовать инструмент для восстановления записей в регистрах прав доступа 1С:ДО.

Определите пользователя: Выясните, под какой учетной записью происходит подключение к веб-сервису из регламентного задания. Обычно это специальный служебный пользователь (например, WS_Robot).
Проверьте Политики доступа: В 1С:ДО права сильно зависят от политик. Убедитесь, что пользователю разрешено чтение видов документов, которые запрашиваются.
Проверьте Профили групп доступа:
- Пользователь должен иметь роль, разрешающую выполнение обмена данными через веб-сервис.
- Пользователь должен иметь права на чтение статусов документов. Иногда доступ к самому документу есть, а к реквизиту «Состояние» — нет.

Важно: Не рекомендуется давать техническому пользователю полные права (Администратор) из соображений безопасности, но его полномочия должны явно покрывать чтение всех запрашиваемых атрибутов (columnSet).

Шаг 2. Безопасное чтение свойств XDTO

Даже если права настроены, хорошей практикой программирования считается проверка наличия свойства перед обращением к нему. Это защитит регламентное задание от падения в случае изменения прав в будущем.

Вместо прямого обращения ОбъектXDTO.confirmed, используйте проверку через коллекцию свойств.

Пример безопасного получения значения:


// Функция для безопасного получения свойства XDTO
Функция ПолучитьЗначениеСвойстваБезопасно(ОбъектXDTO, ИмяСвойства)
    
    // Проверяем, есть ли такое свойство в определении типа
    Свойство = ОбъектXDTO.Свойства().Получить(ИмяСвойства);
    
    Если Свойство <> Неопределено Тогда
        // Свойство существует в схеме, проверяем, установлено ли оно в конкретном экземпляре
        Если ОбъектXDTO.Установлено(Свойство) Тогда
            Возврат ОбъектXDTO[ИмяСвойства];
        КонецЕсли;
    КонецЕсли;
    
    // Если свойства нет или оно не установлено
    Возврат Неопределено; 

КонецФункции

// Использование в основном коде
ЗначениеУтвержден = ПолучитьЗначениеСвойстваБезопасно(ПолученныйОбъектXDTO, "confirmed");
Если ЗначениеУтвержден = Истина Тогда
    // Логика обработки
КонецЕсли;

Шаг 3. Диагностика без отладчика

В теме обсуждалась сложность отладки веб-сервисов. Если вы не можете включить отладку на сервере 1С:ДО, используйте альтернативные методы диагностики, чтобы понять, что именно возвращает сервис.

Технологический журнал: Настройте сбор логов события SCALL (вызов сервиса) на стороне сервера 1С:ДО. В логах можно увидеть полное тело ответа XML. Если тега <confirmed> там нет — проблема 100% в правах.
Промежуточное сохранение: В коде регламентного задания, перед разбором ответа, можно попытаться сериализовать полученный XDTO обратно в XML-строку и записать её в Журнал Регистрации или временный файл. Это покажет реальную структуру, которую видит 1С.

Итоги

Проблема «невидимости» свойств XDTO в регламентных заданиях практически всегда упирается в права доступа (RLS) на стороне системы-источника (в данном случае 1С:Документооборот). Веб-сервис фильтрует данные, к которым у технического пользователя нет доступа, исключая их из XML-пакета.

Для решения:

Настройте права технического пользователя в 1С:ДО (доступ к видам документов и выполнение веб-сервисов).
Используйте явную авторизацию для регламентных заданий.
Пишите код безопасно, проверяя наличие свойств XDTO перед чтением.