При переходе на новые версии платформы 1С:Предприятие 8.3.22 (в частности, сборки 1704 и 1709) многие разработчики столкнулись с нестабильной работой механизма временного хранилища. Проблема проявляется внезапно: код, который годами работал корректно, начинает возвращать Неопределено при попытке получить данные по адресу, а при работе с отчетами возникает сообщение «Ошибка создания источника доступных настроек компоновки данных». В этой статье мы подробно разберем причины такого поведения и рассмотрим методы исправления ситуации.
Проанализируем ситуацию, описанную пользователями. Основной симптом — потеря данных при передаче управления с сервера на клиент и обратно. В нормальных условиях данные во временном хранилище должны жить либо до конца сеанса, либо до закрытия формы (в зависимости от переданного идентификатора). Однако в версиях 8.3.22.1704/1709 механизм очистки сеансовых данных срабатывает преждевременно.
Рассмотрим типичный фрагмент кода, который вызывает ошибку:
// Помещение СКД в хранилище для инициализации компоновщика
СКД = РеквизитФормыВЗначение("Объект").ПолучитьМакет("ОсновнаяСхемаКомпоновкиДанных");
АдресСхемы = ПоместитьВоВременноеХранилище(СКД, Новый УникальныйИдентификатор);
// На этом этапе на сервере всё работает
ИсточникНастроек = Новый ИсточникДоступныхНастроекКомпоновкиДанных(АдресСхемы);
КомпоновщикНастроек.Инициализировать(ИсточникНастроек);
// Но после возврата на клиент и повторного вызова сервера:
Данные = ПолучитьИзВременногоХранилища(АдресСхемы); // Возвращает Неопределено
Выясним причину такого поведения. Платформа 8.3.22 внесла изменения в оптимизацию работы с памятью и процессами rphost. В некоторых случаях данные «теряются» из-за некорректной десериализации объектов при передаче между рабочими процессами кластера. Если ваш сервер 1С работает в режиме кластера с несколькими рабочими процессами, вероятность возникновения ошибки возрастает в разы.
Как показывает практика и обсуждения на форумах, наиболее быстрым и действенным (хотя иногда временным) способом является полная очистка серверного кэша. Важно понимать, что очистка обычного пользовательского кэша в %AppData% здесь не поможет, так как проблема локализована на стороне сервера приложений.
Разберем по шагам процесс очистки серверного кэша:
C:\Program Files\1cv8\srvinfo).reg_1541).snaccfg и workdir. Также рекомендуется очистить папку temp внутри каталога сеансовых данных.После выполнения этих действий платформа принудительно пересоздает структуры данных в памяти, и проблема с Неопределено во временном хранилище обычно исчезает на некоторое время.
Проанализируем второй важный аспект — время жизни объекта во временном хранилище. В платформе 8.3.22 ужесточились правила контроля ссылок. Если при вызове функции ПоместитьВоВременноеХранилище вторым параметром передается Новый УникальныйИдентификатор(), система создает объект, не привязанный ни к чему конкретному.
Посмотрим на правильный подход:
// Неправильно (объект может быть удален сразу после серверного вызова)
Адрес = ПоместитьВоВременноеХранилище(Данные, Новый УникальныйИдентификатор);
// Правильно (объект привязан к жизненному циклу формы)
Адрес = ПоместитьВоВременноеХранилище(Данные, ЭтаФорма.УникальныйИдентификатор);
Использование ЭтаФорма.УникальныйИдентификатор гарантирует, что данные будут доступны до тех пор, пока форма открыта. Если же данные должны жить в течение всего сеанса (например, для передачи между разными формами), следует передавать идентификатор самого сеанса, хотя наиболее стабильным вариантом для 8.3.22 остается именно привязка к форме.
Если ошибка «ошибка создания источника доступных настроек компоновки данных» сохраняется даже после чистки кэша, проанализируем альтернативный способ инициализации компоновщика. Проблема часто кроется в том, что ИсточникДоступныхНастроекКомпоновкиДанных не может корректно прочитать данные по адресу хранилища из-за внутренних сбоев платформы при десериализации СКД.
Попробуем выполнить инициализацию напрямую объектом, если это возможно в контексте вашего серверного вызова:
// Вместо использования адреса из хранилища:
// Источник = Новый ИсточникДоступныхНастроекКомпоновкиДанных(АдресХранилища);
// Используем объект напрямую:
Источник = Новый ИсточникДоступныхНастроекКомпоновкиДанных(ОбъектСКД);
КомпоновщикНастроек.Инициализировать(Источник);
Этот метод исключает один шаг посредничества через временное хранилище и часто позволяет избежать падения системы на проблемных версиях платформы.
Важно понимать, что описанные проблемы в версиях 8.3.22.1704 и 8.3.22.1709 признаны официальными багами платформы. Они связаны с ошибками в механизме работы с сеансовыми данными и оптимизацией вызовов между процессами. Если очистка кэша помогает лишь на короткий срок, единственным надежным решением является переход на более стабильные сборки.
Проанализируем список исправлений в последующих версиях. Проблемы с временным хранилищем и СКД были официально устранены в версии 8.3.22.1750 и во всех последующих релизах ветки 8.3.22. Если ваша компания столкнулась с этими симптомами, крайне рекомендуется запланировать обновление платформы до актуального релиза.
Подведем итог. Мы рассмотрели три уровня решения проблемы:
snaccfg и сеансовых данных на сервере.УникальныйИдентификатор формы и прямую передачу объектов СКД в источник настроек.Совместное применение этих методов позволит стабилизировать работу системы и избежать потери данных в критически важных бизнес-процессах.