Почему возвращается пустой результат из временного хранилища при работе с фоновыми заданиями?

← На главную

В практике разработки на платформе 1С:Предприятие 8.3 (особенно при использовании обычных форм и толстого клиента) программисты часто сталкиваются с ситуацией, когда фоновое задание успешно завершается, но попытка получить результат из временного хранилища возвращает Неопределено. Эта проблема может проявляться избирательно: у одних пользователей код работает идеально, а у других — стабильно выдает пустой результат. В этой статье мы подробно разберем, почему это происходит, как провести диагностику и какие шаги предпринять для исправления ситуации.

Анализ исходной ситуации и архитектуры решения

Рассмотрим типовой алгоритм, который часто применяется для асинхронного получения данных (например, из внешних API, таких как Контур.Фокус):

На стороне клиента инициализируется адрес во временном хранилище с привязкой к форме.
Запускается фоновое задание, в которое передается этот адрес.
Фоновое задание выполняет полезную работу на сервере и помещает результат по указанному адресу.
Клиентская форма через обработчик ожидания проверяет состояние задания и, по его завершении, считывает данные.

Пример кода инициализации, который мы проанализируем:


АдресХранилища = ПоместитьВоВременноеХранилище(Неопределено, ЭтаФорма.КлючУникальности);

МассивПараметров = Новый Массив;
МассивПараметров.Добавить(АдресХранилища);
// ... добавление других параметров

ФоновоеЗадание = ФоновыеЗадания.Выполнить(
    "ИмяОбщегоМодуля.ИмяПроцедуры", 
    МассивПараметров, 
    Новый УникальныйИдентификатор, 
    "Наименование задания"
);

Проблема заключается в том, что в момент вызова Данные = ПолучитьИзВременногоХранилища(АдресХранилища) переменная Данные оказывается пустой, несмотря на отсутствие ошибок в Журнале Регистрации.

Решение 1: Очистка локального кэша пользователя

Как показывает практика, в 90% случаев, если код работает у большинства пользователей, но «капризничает» у одного конкретного, причиной является повреждение локального кэша конфигурации. Платформа 1С кэширует метаданные и контексты форм, и сбой в этих файлах может приводить к некорректной передаче КлючаУникальности формы между клиентским сеансом и серверными процессами.

Что нужно сделать:

Полностью закрыть все сеансы пользователя.
Удалить папку с кэшем (обычно находится в %AppData%\1C\1Cv8\ и %LocalAppData%\1C\1Cv8\).
Либо просто удалить базу из списка и добавить её заново — это создаст новый идентификатор папки кэша.

Если после этого работа восстановилась, значит, проблема была в рассинхронизации локальных данных.

Решение 2: Проверка прав доступа к хранилищу

Разберем ситуацию, когда проблема не в кэше, а в настройках безопасности. В некоторых конфигурациях (например, ERP 2.4 или КА 2.5) доступ к механизмам временного хранилища может быть ограничен на уровне ролей, если используются специфические объекты. Хотя само хранилище является платформенным механизмом, контекст его использования может зависеть от прав пользователя.

Выясним причину через проверку прав:

Попробуйте временно назначить проблемному пользователю роль ПолныеПрава. Если после этого функционал заработал — проблема в недостаточности прав.
Обратите внимание на права к общему модулю, где выполняется фоновое задание. Он должен иметь флаг Привилегированный, если внутри происходит обращение к защищенным данным.

Решение 3: Время жизни данных и привязка к идентификатору

Проанализируем использование ЭтаФорма.КлючУникальности. Когда мы передаем этот идентификатор в ПоместитьВоВременноеХранилище, данные будут существовать до тех пор, пока открыта эта форма. Однако в режиме Толстого клиента связь между фоновым заданием (которое выполняется в отдельном сеансе на сервере) и конкретной формой пользователя может быть нестабильной.

Рекомендуемый подход:

Вместо привязки к форме используйте новый УникальныйИдентификатор. В этом случае данные будут храниться в рамках всего сеанса пользователя до его завершения.


// На клиенте
ИдентификаторСеанса = Новый УникальныйИдентификатор;
АдресХранилища = ПоместитьВоВременноеХранилище(Неопределено, ИдентификаторСеанса);

// В фоновом задании на сервере
ПоместитьВоВременноеХранилище(РезультатВыполнения, АдресВоВременномХранилище);

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

Решение 4: Проблемы сериализации данных

Выясним, что именно мы пытаемся поместить в хранилище. Метод ПоместитьВоВременноеХранилище требует, чтобы данные были сериализуемыми. Если переменная РезультатВыполненияОперации содержит специфические объекты (например, COM-объекты, открытые файлы или объекты, доступные только на сервере), то при записи в хранилище ошибки может не возникнуть, но фактически запишется Неопределено.

Рассмотрим, как это проверить:

В коде фонового задания перед помещением в хранилище добавьте проверку типа данных.
Используйте ЗначениеВСтрокуВнутр() или СериализаторXDTO для проверки возможности преобразования объекта.
Убедитесь, что в фоновом задании результат не становится Неопределено из-за внутренней ошибки, которая «проглатывается» блоком Попытка ... Исключение.

Решение 5: Особенности работы серверного кластера

Проанализируем ситуацию на уровне платформы (особенно актуально для версии 8.3.18). В клиент-серверном варианте основной сеанс пользователя и фоновое задание могут выполняться на разных рабочих процессах (rphost) сервера 1С.

Платформа обязана синхронизировать временное хранилище между процессами, но при сетевых задержках или сбоях менеджера кластера эта синхронизация может не произойти вовремя. Этим объясняется странное поведение, когда под отладкой (Конфигуратором) всё работает: при отладке часто задействуется один и тот же рабочий процесс или меняются таймауты ожидания, что «маскирует» проблему синхронизации.

Что можно сделать на уровне сервера:

Проверить наличие «висячих» спящих сеансов в консоли администрирования. Иногда старый сеанс того же пользователя блокирует корректную работу с временными данными.
В настройках кластера убедиться, что лимиты памяти на рабочий процесс не заставляют сервер принудительно завершать или очищать кэши процессов.

Диагностика через Журнал Регистрации

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


ЗаписьЖурналаРегистрации("ФоновоеПолучениеДанных",
    УровеньЖурналаРегистрации.Информация,
    ,
    ,
    "Результат подготовлен, тип: " + ТипЗнч(РезультатВыполнения) + 
    ", Адрес: " + ПараметрыОбработки["АдресХранилища"]);
    
ПоместитьВоВременноеХранилище(РезультатВыполнения, ПараметрыОбработки["АдресХранилища"]);

Если в журнале вы видите правильный тип данных, а на клиенте получаете Неопределено, значит, корень проблемы лежит в области времени жизни (Scope) хранилища или кэша сеанса. В этом случае возврат к Решению 1 (очистка кэша) или Решению 3 (замена ключа уникальности) будет самым эффективным выходом.

Итоговые рекомендации

Подведем итог. Если вы столкнулись с пустым результатом из временного хранилища:

Начните с простого: очистите кэш у пользователя.
Проверьте логику: убедитесь, что адрес во временном хранилище создается до запуска фонового задания и передается корректно.
Уйдите от привязки к форме: используйте Новый УникальныйИдентификатор для управления временем жизни данных.
Проверьте права: убедитесь, что у пользователя достаточно прав для выполнения серверных вызовов и работы с общими модулями.

Соблюдение этих правил позволит сделать работу с асинхронными вызовами в 1С стабильной и предсказуемой.