Сколько точек зрения у Архитектора в ИТ?
На чьих плечах мы стоим? Архитектурный кейс с фоновыми заданиями
Сколько взглядов должно быть у архитектора?
Ловушка очевидного решения. Чего думать - тут делать надо или почему СУБД плохой способ обмена информацией между фоновыми заданиями.
Общий Бизнес процесс (Workflow диаграмма)
Реакция на входящие данные \ входящий поток данных
Исключительные ситуации
Влияние процессов друг на друга
Зависимость процессов или отдельных этапов друг от друга
Наличие режима отладки
Оптимизация и оптимальность реализации.
Интерфейс пользователя, Интерфейс кастомизации
Возможность создания общих библиотек (общие процедуры, функции, метаданные)
Права доступа
Маштабируемость решения.
А сколько точек зрения на задачу используете Вы?
P S Как возвратить результат фонового задания.
На чьих плечах мы стоим? Архитектурный кейс с фоновыми заданиями
Когда приходится делать очередной Workaround сразу возникают взрослые слова обращенные к архитектору, который так запроектировал (библиотеку, подсистему и т. д.). Особенно это больно, когда архитектору приходится иметь дело с творчеством коллег архитекторов где‑то этажом ниже по стеку программного обеспечения.
Это вот Ньютон сказал:
«Если я видел дальше других, то потому, что стоял на плечах гигантов».
Но не всем везет — разберем простой архитектурный кейс с подсистемой фоновых заданий в 1С, которые являются важной частью платформы. Описано оно максимально просто Фоновое задание (1c.ru) . Фоновые задания иди их аналоги есть практически во всех платформах (СУБД, ERP, Java и т. д.) Полное техническое описание из которых видна заложенная 1С идеология находится тут Глава 19. Механизм заданий:: Руководство разработчика:: Платформа 1С:Предприятие 8.3.25. далее будут на нее ссылки.
Их используют для разных целей:
Запуск отчета асинхронно, чтобы не прерывать работу пользователя. Хотя асинхронная печать форм документов уже перебор .
Запуск обслуживающих процессов — например, оповестить пользователей о новом этапе согласования документа. Запуск фоновых заданий по расписанию.
Распараллеливание обработки (импорт, формирование проводок), порой это единственный способ работать с базами 5 терабайт и выше. В них можно поделить документы на пакеты по 1000 и запускать на обработку фоновыми заданиями. Как в этом случае строится архитектура можно посмотреть тут Язык мой — враг мой. Архитектору о будущем 1С | 1CUnlimited | Дзен (dzen.ru).
На больших объемах даже отчеты приходится распараллеливать — например, баланс, где каждая строка, это обращение к остаткам с развернутым сальдо и таких статей около сотни.
Очевидно, для приемлемой скорости отчета расчет статей приходится распараллеливать фоновыми заданиями.
Но на практике в архитектуре фоновых заданий 1С постоянно чего‑то не хватает и это будет видно ниже.
А недавно понадобилось, запустив фоновое задание из серверной процедуры кластера возвратить результат выполнения (ну не через метаданные\таблицы базы данных, а как то внутри кластера 1С).
Как это сделать в 1С? — опять через Workaround Workaround me в 1С\MS SQL и не только, научный подход к созданию костылей / Хабр (habr.com). И когда такое на каждом шагу, понимаешь, что это не отдельные недостатки и отсутствие очередной «фичи», лучше задать другой вопрос более правильный вопрос «Какой должна быть подсистема фоновых заданий, и с каких точек зрения нужно ее рассматривать?»
Тем более это же не ноухау какое то — в том MS SQL есть Background jobs, а в Java еще больше вариантов.
Сколько взглядов должно быть у архитектора?
Когда обсуждают и пишут умные статьи на тему «кто вообще такой ИТ архитектор и зачем он нужен», возникает ощущение «ну все понятно, а что конкретно?». Просто поищите статьи про ИТ Архитектора — там даже найдете нечто «Как я стала системным архитектором без инженерного бэкграунда, и почему это нормально»
Если же спросить архитектора — с каких точек зрения он смотрит на задачу? и применяет к ней синтез, анализ, сравнение — все становится более конкретным. Короче, ниже изложены точки зрения (Point of view Check list) которые я использую в прикладной разработке для финансовых и бэкофисных систем. Для других прикладных областей, очевидно, будет свой набор, но он должен быть всегда, поскольку архитектор без прикладной области существовать не может. Иначе бы архитектор по жилым домам легко бы проектировал мосты, а архитектор по нейросетям легко бы спроектировал приложение для автопилота самолета, но реальность совершенно другая.
Именно искусство смотреть на задачу с разных точек зрения, отличает архитектора от всех. Бизнес аналитик он может только с прикладной точки зрения покрутить задачу, а с технической уже нет. А выбора правильного инструмента нужен опыт и интуиция, когда невозможно сделать прототип.
Ловушка очевидного решения. Чего думать тут делать надо или почему СУБД плохой способ обмена информацией между фоновыми заданиями.
Наверное, очевидное решение для приведенного кейса — использовать таблицы СУБД для обмена информацией. Так большинству подсказывает «эмоциональный интеллект». Он хорош для интересных идей, но у нас тут архитектура и нужно смотреть глубже. Метаданные 1С которые по принципу ORM, отражаются в СУБД, подчиняются механизму транзакций. При этом полноценного механизма вложенных транзакций в 1С нет, и любой откат транзакций откатит все до первого НачатьТранзакцию(); Допустим Вы пишите в свой лог на справочниках или регистрах сведений — любая нештатная ситуация и вы не узнаете о ней из за отката транзакции.
Если посмотреть на архитектуру с других точек зрения (ниже), это очевидное решение станет еще более неправильным.
Чего нет 1С, а нужно: Специализированных структур для возврата результатов, логов из фоновых заданий
Да в 1С есть Журнал регистрации для логгирования независящий от транзакций, но у него очень бедная и нерасширяемая структура, неудобная для поиска.
Для работы с большими объемами — даже такие простые объекты регистры сведений 1С также не очень подходят, ведь любые отборы по наборам записей этих регистров можно устанавливать только на равенство. т. е. ORM 1С делает эту задачу еще труднее.
Специалисты 1С вспомнят про ВременноеХранилище — но в конце этому посвящен отдельный раздел.
Поэтому потратим время и посмотрим на задачу с разных точек зрения.
Общий Бизнес процесс (Workflow диаграмма)
Сначала смотрим на задачу крупными блоками. Лучше в виде диаграммы. Пробежаться по миру диаграмм можно в Visio, где всегда можно подобрать диаграмму для прикладной задачи. Для фоновых заданий он прост — запуск, передача параметров, отслеживание статуса работы, возврат результата. Запуск по расписанию это уже другая тема, которая относится к регламентным заданиям, но то же связана с задачей.
Чего нет 1С, а нужно: Возврат результата. Конечно всегда можно это реализовать через регистры сведений 1С (СУБД) это вредный совет как описано выше.
Менеджер временных таблиц тоже невозможно использовать из за его мутабельности. Временное хранилище 1С — по факту имеет ограниченное время жизни и много но, о которых написано в конце.
Судя по всему стратегия без возврата результата в 1С принята специально — так как в документации указано.
«Если методом фонового задания является функция, то ее возвращаемое значение игнорируется.»
Поэтому если это Вам нужно — в конце статьи есть Workaround.
Статус фоновых заданий в 1С можно посмотреть почему‑то для 1000 заданий,а этого мало для обработки более чем миллиона документов, разбитых по 1000 документов в пакете.
Реакция на входящие данные \ входящий поток данных
Сюда можно отнести типизацию, проверки, структуры. В 1С требуют, чтобы входящие параметры были не мутабельны (сериализуемы, ссылки должны соответствовать объектам в базе, а не в памяти). Также нужно передавать дополнительные параметры для идентификации заданий ‑Ключи, уникальный ИД.
Чего нет 1С, а нужно: С первого взгляда все есть, можно передать списки, массивы с немутабельными значениями. Даже ссылку на ВременноеХранилище (очень спорный объект) с временем жизни 20 минут можно передать, а вот Менеджер временных таблиц нет. А как тогда передать на обработку большой массив информации, полученный запросом? Только если Вы заранее спроектировали регистр сведений и долго перекладывали туда результаты.
Да в документации 1С описано что:
«Параметрами фонового задания могут быть любые значения, которые разрешено передавать на сервер. Параметры фонового задания должны в точности соответствовать параметрам той процедуры или функции, которую оно вызывает. Параметры фонового задания, в сериализованном виде, не могут превышать размер в 1 Гбайт. Если размер сериализованных параметров фонового задания превышает значение 1 Гбайт — формируется исключение.»
1С Гигабайт это не много, когда мы ведем речь о выборках из базы данных.
Исключительные ситуации
Посмотрим, что будет если что‑то пойдет не так? Иными словами какое будет поведение системы когда произошла исключительная ситуация (системная или прикладная типа деления на 0). В 1С фоновое задание при аварийном завершении отмечается как завершенное с ошибкой и ее текст помещается в реквизит ИнформацияОбОшибке, однако важно видеть не конечное исключение, а цепочку событий и исключений, которая привела к катастрофе. Это означает необходимость логгирования.
Чего нет 1С, а нужно. Полноценного стека ошибки, как Java например. Нет также хорошего логгирования ошибки, если не считать Журнала регистрации, где нужно за что‑то зацепится чтобы найти нужное.
Влияние процессов друг на друга
Как могут фоновые задания влиять друг на друга если по сути они самостоятельны? Нагрузкой на кластер 1С. Сколько мы можем их запустить в 1С вот в чем вопрос? Лучше иметь какие то ручные настройки — поскольку только разработчик и архитектор может предсказать это. Например, кластер позволил запустить 10 заданий в рамках свободных ресурсов, и вдруг 3 задания грузят ядра более чем на 50%. Что делать? Кого притормаживать?
Чего нет 1С, а нужно. В 1С нет никаких ограничений на запуск фоновых заданий, иногда это приводит к ситуациям с 10 тысячами фоновых заданий в фоне История данных спровоцировала 10 000 заданий в фоне. Кластер можно было бы спасти простым параметром — максимальное число фоновых заданий на кластер, но его пока нет — на уровне конфигурации 1С приходится программировать самому.
Зависимость процессов или отдельных этапов друг от друга
Зависимости есть всегда, даже в когда что‑то запускаете параллельно. В 1С разрешено запускать фоновое задание из фонового, поскольку по сути они самостоятельные. Такое может понадобится при массовом проведении, например, сначала параллелим по организациям, а внутри по документам.
При этом в качестве применения фоновых заданий в документации 1С написано
«Фоновое задание может порождать другие фоновые задания. В клиент‑серверном варианте это позволяет распараллеливать сложные вычисления по рабочим процессам кластера, что может значительно ускорить процесс вычисления в целом. Распараллеливание реализуется порождением нескольких дочерних фоновых заданий с ожиданием завершения каждого из них в основном фоновом задании.»
т. е. с одной стороны предлагают с помощью фоновых заданий, правильные вещи делать но подход к ним как ракете для фейерверка, запустил посмотрел вспышку и забыл.
Чего нет 1С, а нужно. Управления подчиненными заданиями, например когда сбой произошел в головном задании — логично отменить все подчиненные.
В процессе работы фоновых заданий нужна возможность обмена информации через общую память. Это часто требуется, если процесс проведения (формирования проводок сложен ) и нужно запоминать промежуточную информацию о состоянии регистраторов. В конце концов если фоновые задания работают с одной СУБД значит они уже взаимодействуют и нужны инструменты для управления этим процессом.
Наличие режима отладки
Отладка это всегда особый режим. Когда используешь параллельные задания, лучше иметь возможность режима последовательного запуска. Да в 1С можно перехватывать все параллельные задания в какой‑то точке кода, но если нужно перехватить только одно фоновое задания тут варианта 2.
Либо передавать в фоновое задание специальный параметр (или использовать ключ задания), чтобы можно было перехватить на точке останова с условием. Например, НомерДляОтладки=хх.
Либо писать такой код:
Если Отладка Тогда
//СУУ_Тестирование.
СУУ_Тестирование.СтартоватьНагрузочныйПотокКотировок(ЗадИдВызова, ДеньКотировки, ЦикловПерезаписи,КоличествоВТранзакции);
Иначе
МассивПараметров=Новый Массив;
МассивПараметров.Добавить(ЗадИдВызова);
МассивПараметров.Добавить(ДеньКотировки);
МассивПараметров.Добавить(ЦикловПерезаписи);
МассивПараметров.Добавить(КоличествоВТранзакции);
ЗапущенныеФоновые.Добавить(ФоновыеЗадания.Выполнить("СУУ_Тестирование.СтартоватьНагрузочныйПотокКотировок", МассивПараметров,"StressTask"+КоличествоЗаданий, " Нагрузочное задание № "+КоличествоЗаданий+" День котировки "+ДеньКотировки));
КонецЕсли;
Чего нет 1С, а нужно. Тут все нужное есть, видимо сказывается эффект обратной связи. Ведь типовые конфигурации пишут разработчики внутри компании 1С на платформе 1С, а здесь обратная связь с разработчиками платформы заметно короче.
Оптимизация и оптимальность реализации.
Как обеспечить скорость выполнения? Если делить задачу на пакеты (по 1000 операций) фоновые задания могут ускорить выполнение в N раз. Они выполняются на кластере 1С и соответственно с помощью их можно исключить сетевые задержки при грамотной инфраструктуре. Более тонкий момент — расходы на запуск. Как было показано тут Что делать когда фоновые задания для печатных форм 1С тормозят? | 1CUnlimited | Дзен (dzen.ru) использование их для печатных форм документов неэффективно, поскольку здесь уже ощущаются расходы на запуск и обращение к менеджеру фоновых заданий, особенно когда сама форма готова меньше чем за 0,5 секунды. Если приходится кластер 1С запускать под доменным аккаунтом — у вас будет зависимость от скорости отклика домена.
В теории таких задержек не должно быть у асинхронных методов, но здесь нужно смотреть на реализацию. В 1С эта тема применима только в рамках «Модификатор применим только к функции, выполняемой на клиенте» т. е. о серверном вызове можно забыть.
В Java например есть директива @Asynchronous но ее поведение сильно отличается от Multithreading Multithreading Vs Asynchronous — TAE (tutorialandexample.com) в степени параллелизма выполнения.
Чего нет 1С, а нужно. Формально по архитектуре тут все впорядке, а вот по реализации есть огромные проблемы. Кластер 1С может включать нужное количество рабочих серверов, можно даже назначать с помощью Объектов требований разные фоновые задания на разные сервера. Но при этом ограничения по количеству заданий на сервер нет.
А еще в документации четко дано ограничение на количество видимых заданий:
«Завершившиеся успешно или аварийно фоновые задания хранятся в течение суток, а потом удаляются. История выполнения фоновых и регламентных заданий имеет следующие особенности:
История хранится для каждой информационной базы;
Хранится история выполнения:
Фоновых заданий — не более 1 000 заданий.
Регламентных заданий — не более 1 000 заданий. При этом система пытается хранить не менее 3 последних запусков для каждого различного регламентного задания. При превышении общего ограничения в 1 000 запусков, система будет пытаться обеспечить хранение 2 последних запусков для каждого регламентного задания, а потом 1.
Системных фоновых заданий — не более 1 000 запусков. В данном разделе речь идет о фоновых заданиях, которые инициируются системой для выполнения каких‑либо действий (выполнение отчетов, поиск и т. д.).»
Ну т.е. если вы поделили больше миллиона операций на пакеты по 1000 Вы часть заданий просто не проконтролируете. На самом деле можно проконтролировать очередным трюком workaround своей доработкой.
Интерфейс пользователя, Интерфейс кастомизации
По интерфейсу встречают, а по API провожают. В 1С есть интерфейс отслеживания выполнения фоновых заданий, и регламентных заданий по расписанию. Однако он недалеко ушел от TaskScheduler windows, где задания запускаются только по времени .
В реальной жизни, фоновые задания используются для запуска Workflow по расписанию, тут уже нужны возможности:
Запуска последовательность заданий
Запуска части заданий параллельно, а части последовательно.
Прерывание Workflow в случае критической ошибке на каком либо задании.
Отдельно следует выделить интерфейс кастомизации, поскольку любой функционал имеет константы, классификаторы или форму для настроек в приложении.
Поэтому что‑то более сложное приходится делать самим.
Пример, реализации на платформе 1С продвинутого TaskManager можно увидеть ниже:
Он реализован как справочник 1С, и позволяет запускать любые процедуры с параметрами как фоновые задания. В отличии от стандартного менеджера регламентных заданий он позволяет:
строить в виде дерева Workflow
устанавливать последовательность запуска (следующая процедура) как на уровне заданий так и на уровне групп заданий.
Прерывать выполнение цепочки если одно задание завершилось некорректно. Это бывает важно, когда процесс многоэтапный, а расчеты нужны корректные
Возможность ожидать завершения предыдущей цепочки если уже стартовала следующая.
Форма группы задач выглядит так:
Чего нет в 1С, а нужно: Возможности выстраивать из фоновых заданий цепочки для Workflow, штатными средствами или через Библиотеку стандартных подсистем нет. Сейчас все это нужно реализовывать самим.
Возможность создания общих библиотек (общие процедуры, функции, метаданные)
На любом проекте трудозатраты можно уменьшить повторным использованием кода. При этом имеются ввиду не куски кода которые нужно склеить со своим решением, а готовые и отлаженные. Формально в 1С есть Библиотека стандартных подсистем (БСП), где созданы методы и интерфейс для применения в типовых конфигурациях, но он далек от возможностей нужных выше. Не надо забывать что подсистема фоновых заданий не может быть сама по себе — как минимум она должна зависеть от подсистемы логгирования. т. е. мы уже получим комплекс библиотек.
Что нет в 1С, а нужно: Формально этот пункт реализован, есть простая реализация в БСП, есть логгирование кучей в Журнал регистрации. Но разве этого достаточно для прикладного использования?
Права доступа
Вопрос с подсистемой доступа часто игнорируют в архитектуре до последнего момента, а на самом деле он серьезно меняет архитектурный ландшафт. Например, фоновое задание подлежит исполнению на сервере. В документации 1С с правами решили так:
«Создание и управление фоновыми заданиями выполняются программно из любого соединения. Создавать фоновое задание разрешено любому пользователю. При этом оно выполняется от имени того пользователя, который его создал. Получать задания, а также ожидать их завершения разрешено из любого соединения пользователю с административными правами либо пользователю, который создал эти фоновые задания.»
т. е. пользователь отличный от администратора может создать фоновое но не может управлять своим же фоновым заданием. Оригинально?
Чего нет в 1С: Продуманной системы контроля за заданиями со стороны сессии пользователя. Любой более сложный процесс требует либо работы с привилегированным модулем, либо прав администратора либо никак.
Маштабируемость решения.
Когда видишь очередную систему, которая скрипит под большим объемом, сразу задаешь вопрос о чем думали проектировщики?
Да ни о чем они не думали, в лучшем случае покажут пальцем на ключевого заказчика от бизнеса, который не смог озвучить свою «бизнес стратегию» на 5 лет вперед. Особенно, когда модно менять работу раз в год — на маштабируемость не будет никакой мотивации. Однако для оценки архитектуры продукта с долгим временем жизни это существенный пункт, поскольку для одноразового продукта архитектор не нужен. Пока что его можно только внести в «моральный кодекс» архитектора. Да и сама задача технически интересна, представьте, что без четких знаний «business strategy» вам нужно построить решение адаптируемое к любым «business challenge».
На самом деле это возможно, даже в строительстве — Вы можете сделать более прочный каркас и фундамент, а при необходимости сделать дополнительный этаж. А трансформируемые open space так же всем знакомы.
В ИТ еще больше возможностей, например:
Заложить параллельную обработку везде, где возможно. Это не так дорого, но очень эффективно.
Создавать библиотеки процедур\функций с расширенным количеством параметров, даже если они сейчас не обрабатываются. Логику можно дописать потом.
Всегда выделять интерфейс. Например, для подсистемы логгирования не завязываться на журнал регистрации в коде, а обернуть вызовы общие в процедуры\функции логгирования. Вы потом можете переписать в них логику как угодно без ущерба для основного кода
В языках с полноценным ООП Java средств еще больше, на целую книгу.
Чего нет в 1С, а нужно: Как видно выше с маштабируемостью у подсистемы фоновых заданий 1С есть явные проблемы. Возьмите хотя бы хранение истории только 1000 заданий, или вообще отсутствие ограничений по запуску заданий на кластере. Все это нужно доделывать самим.
А сколько точек зрения на задачу используете Вы?
Делитесь в комментариях своими Check list. Как видите — даже шаблонный кейс фоновым заданиям, требует серьезной архитектурной работы. И не надейтесь на Agile Agile teaches us the true meaning of Architecture — R&A IT Strategy & Architecture (rna.nl) поскольку он не решает архитектурные промахи, а лишь дает надежду что все можно поправить потом. «Потом» это такая же ложь как «Напишем документацию потом». Если Вы не общаетесь с помощью документации (спецификаций, проектных решений) — «потом» Вы ее не напишите. Что у Вас получится без достаточного анализа, это архитектурный признак с набором «фич», которые вдруг оказались нужны по ходу дела.
Несмотря на то, что в среднем объем внимания эквивалентен 7 ± 2 объектам (число Ингве) — вам ничего не мешает переводить фокус внимания по данному чеклисту.
Это выгодно со всех точек зрения.
Вы можете легко показать заказчику, что находится под вершиной айсберга просто предъявив ему чеклист.
Вы сразу сможете задать правильные вопросы.
Вы сразу поймете, где у Вас недостаточно компетенций и нужно привлекать экспертов.
Вы сразу поймете, где нужно провести технический эксперимент (прототип) и привлечь нужных коллег.
Вы сразу узнаете есть ли у Вас архитектор или нет?
Сюда не вошли пункты актуальные для других задач
Использование других языков (английский, китайский).
Реакция на некорректные действия пользователей (защита от дурака)
Адаптация решения к удобному автоматизированному тестированию
Действия необходимые для развертывания решения в инфраструктуре
Удобство архитектуры для распределения задач по разработчикам.
Я думаю из изложенного выше видно, что архитектор обязательно должен вырасти из разработчика. Да невозможно пройти все комбинации стека разработки, но например строить хорошие конфигурации на базе 1С — без знания как она работает под капотом с СУБД нереально. Вы просто не зададите правильный вопрос.
Бизнес аналитики (или любой другой аналитик) архитектора не заменит. Поскольку именно архитектору нужно правильно выбрать инструменты, протоколы, которые будут применяться при разработке.
Каков должен быть объем знаний архитектора? В принципе ему достаточно биографии тимлида, поскольку главное в его работе, не знать все, а выбирать правильные точки зрения, и уметь задавать правильные вопросы? И конечно постоянно учиться новому.
Можно ли свалить обязанности архитектора на тимлида? Можно конечно, если он у Вас только один, а если больше трех? Они договорятся между собой как проще взаимодейстовать между собой и чтобы их зона личной отвественности не пострадала. А потом выяснится, что в компании никто не подумал о централизованной системы ведения нормативно справочной информации ((Master data management) справочники контрагентов, номенклатуры, ценных бумаг и т. д.) и у каждого свой зоопарк для гармонизации этого процесса. А это не какое‑то ноу хау, а известные лучшее практики. Почему так? Потому что если что‑то делается значит это кому‑то нужно. А кому нужны Вы?
До новых встреч на нашем канале t.me/Chat1CUnlimited
P S Как возвратить результат фонового задания.
Нужно выбрать средство передачи и формат.
Из существующих:
Через СУБД плохо из‑за транзакционности. Еще ручная сборка мусора по сеанса\сессиям после работы.
Через файл плохо из‑за необходимости создания спец каталогов, доступных со всех рабочих серверов кластера 1С. Еще ручная сборка мусора по сеансам\сессиям после работы.
Через ВременноеХранилище плохо, поскольку там есть ограничения по времени жизни и вообще.
В документации предлагается трюк:
«В механизме работы с временным хранилищем есть возможность передать данные из фонового задания в сеанс, инициировавший фоновое задание. Для такой передачи следует в родительском сеансе поместить во временное хранилище пустое значение (с помощью метода ПоместитьВоВременноеХранилище()), указав какой‑либо идентификатор создаваемого временного хранилища (параметр Адрес). Затем полученный адрес передать в фоновое задание через параметры фонового задания. Далее, если в фоновом задании этот адрес использовать в качестве значения параметра Адрес метода ПоместитьВоВременноеХранилище(), то результат будет скопирован в сеанс, из которого было запущено фоновое задание.
Данные, помещенные во временное хранилище в фоновом задании, не будут доступны из родительского сеанса до момента завершения фонового задания.»
Иными словами, вы это временное хранилище должны создать до запуска фонового задания.
Далее минздрав предупреждает!
«ВНИМАНИЕ! При получении на сервере значения из временного хранилища следует учитывать то, что оно получается по ссылке. В действительности, ссылка эта указывает на значение, которое хранится в кеше. В течение 20 минут, с момента помещения в хранилище или же с момента последнего обращения, значение сохранится в кеше, а затем записывается на диск и из кеша удаляется. При следующем обращении значение загружается с диска и снова помещается в кеш.
После десериализации и восстановления значения из временного хранилища ссылки не восстанавливаются. Значение в кеше восстанавливается с диска. Но после сериализации/десериализации восстановить ссылки на другие объекты внутри значения невозможно.»
В общем, для обмена картинками между клиентским контекстом и серверным оно сойдет, а для нормальной работы я не рискну его использовать тем более фоновое задание может и больше 20 минут выполнятся. Само описание в документации с многочисленными «если но » четко показывает, что над ролью ВременногоХранилища серьезно не думали. Могли бы взять и наложить условие типа «все типы во временном хранилище немутабельные, и должны подлежать сериализации и десериализации». В итоге смешали все в кучу и ВременноеХранилище стало узкоспециализированным и бесполезным.
Но у 1С есть средство:
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = ТекстСообщенияПользователю;Не путать с глобальной процедурой Сообщить().
А у фонового задания есть метод ФоновоеЗадание.ПолучитьСообщениЯПользователю().
Которое, судя по отсутствию типизации в возвращаемом значении предполагалось, только для передачи текстовых сообщений ограниченного размером типа Строка. Но вы можете его вызывать в любой момент работы фонового задания.
Т. е. Вы спокойно можете передавать сообщения из фонового задания в вызывающий модуль.
Осталось выбрать формат подлежащий сериализации\десериализации.
Сравним библиотеку XML и JSON в 1С. Вывод очевиден — в JSON список сериализуемых типов богаче, и есть Соответствие, Структура т. е. все что нужно для сложной сериализации\десереализации.
Ну а теперь фрагменты кода:
&НаСервере
//Сериализация JSON позволяет работать в обе стороны https://its.1c.ru/db/intgr83#content:17:hdoc
//Выводит в сообщение
Функция СериализоватьВСообщениеJSON(ПарСтруктура) Экспорт
Перем Результат;
Попытка
Запись=Новый ЗаписьJSON ;
Запись.УстановитьСтроку();
ЗаписатьJSON(Запись,ПарСтруктура);
Результат = Запись.Закрыть();
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(Результат);
Возврат Результат;
Исключение
Возврат Неопределено;
КонецПопытки
КонецФункции
&НаСервере
Функция ИзвлечьИзСообщенияJSON(СообщениеТекс) Экспорт
Перем Результат;
Попытка
Чтение = Новый ЧтениеJSON;
Чтение.УстановитьСтроку(СообщениеТекс);
Результат=ПрочитатьJSON(Чтение,Истина);
Возврат Результат;
Исключение
Возврат Неопределено;
КонецПопытки
КонецФункции
//А тут образец применения
Для Каждого Задание из ЗапущенныеФоновые Цикл
СообщениеФонового=Задание.ПолучитьСообщенияПользователю();
СоответствиеJSON =ИзвлечьИзСообщенияJSON(?(СообщениеФонового.Количество()=0,"",СообщениеФонового[0].Текст));
//Тут мы можем суммировать показатели
//Если нет информации пропускаем
Если СоответствиеJSON<>Неопределено Тогда
СредняяСкорость=СредняяСкорость+СоответствиеJSON["ЗаписьВСекунду"];
КоличествоЗаписей=КоличествоЗаписей+СоответствиеJSON["ЗаписейОбработано"];
СуммарноеВремя=СуммарноеВремя+СоответствиеJSON["ВремяОбработки"];
КонецЕсли;
КонецЦикла;
Пример полной обработки, где это применяется в следующих статьях. Да все это ограничено длиной строки, но для возврата сводных результатов пойдет и о уборке мусора, изоляции сеанса, не нужно заботится сами. Для больших объемов есть другие более надежные варианты.