Фоновое задание ошибка выполнения

Область применения: управляемое приложение.

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

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

В противном случае такие вызовы могут привести к потере работоспособности приложения или затруднению работы с ним:

  • браузер может предложить прекратить длительно выполняющийся сценарий, после чего приложение станет неработоспособным;
  • веб сервер может прервать длительное обращение к серверу 1С:Предприятия и вернуть ошибку 504 (шлюз не отвечает);
  • в случае длительного выполнения операции, у пользователя нет возможности отменить ее.

2.1. Общий подход к асинхронному выполнению длительных серверных операций с помощью фонового задания:

    Код, выполняющий длительную обработку данных, располагается в модуле менеджера объекта* или в общем модуле. Результат своей работы он помещает во временное хранилище;

*Примечание: необходимо использовать процедуру-обертку в общем модуле, которая будет вызывать процедуру модуля менеджера через ОбщегоНазначения.ВыполнитьМетодКонфигурации() . Т.к. фоновые задания могут работать только с процедурами и функциями общих модулей.

  • Для выполнения этого кода на сервере запускается фоновое задание, при этом необходимо ожидать завершения выполнения фонового задания в течение 0.8 сек;
  • Если за время ожидания выполнения задания оно не завершилось, то управление возвращается на клиент, и в клиентском коде подключается обработчик ожидания, в котором периодически проверяется состояние фонового задания. При этом интервал опроса задания увеличивается от 1 до 15 секунд с фиксированным коэффициентом 1.4 ;
  • На время выполнения длительной операции пользователю отображается индикатор;
    при этом для отчетов индикатор выводится в поле табличного документа, используя свойство поля табличного документа ОтображениеСостояния :
  • а для прочих мест – выводится блокирующая форма ( РежимОткрытияОкна = БлокироватьОкноВладельца ), на которой размещена декорация с анимированной картинкой и кнопка «Отмена» :

  • При получении от сервера информации о том, что фоновое задание завершено, полученный результат загружается из временного хранилища и обрабатывается.
  • 2.2. Асинхронное формирование отчета требуется только для тех отчетов, которые

    • разработаны без использования СКД или с использованием СКД, но с переопределенной процедурой формирования отчета (переопределен обработчик кнопки «Сформировать» или в обработчике модуля отчета ПриКомпоновкеРезультата устанавливается СтандартнаяОбработка = Ложь ).
    • и формирование которых, как правило, занимает длительное время.

    Поведение таких отчетов должно быть максимально похожим на поведение отчетов на базе СКД, а именно:

    • форму отчета не следует блокировать на время его формирования;
    • пользователь может изменить настройки и переформировать отчет, не дожидаясь окончания его формирования;
    • при закрытии формы отчета, формирование отчета прерывается.

    3. При использовании в конфигурации Библиотеки стандартных подсистем в распоряжении разработчика имеются вспомогательные функции и процедуры общих модулей ДлительныеОперации , ДлительныеОперацииКлиент , а также процедура УстановитьСостояниеПоляТабличногоДокумента общего модуля ОбщегоНазначенияКлиентСервер .

    Пример выполнения функции в фоновом задании при использовании в конфигурации Библиотеки стандартных подсистем. В модуле менеджера объекта размещена функция, которая выполняет поиск настроек и возвращает их:

    Функция ОпределитьНастройкиУчетнойЗаписи(АдресЭлектроннойПочты, Пароль) Экспорт
    .
    Возврат Настройки;
    КонецФункции

    В форме объекта выполняется вызов этой функции в фоновом задании в три этапа:
    1) запуск фонового задания на сервере,
    2) подключение обработчика завершения фонового задания на клиенте,
    3) обработка результата выполнения фонового задания.

    // 2. Подключение обработчика завершения фонового задания.
    ПараметрыОжидания = ДлительныеОперацииКлиент.ПараметрыОжидания(ЭтотОбъект);
    Оповещение = Новый ОписаниеОповещения("ПриЗавершенииПоискаНастроек", ЭтотОбъект);
    ДлительныеОперацииКлиент.ОжидатьЗавершение(ДлительнаяОперация, Оповещение, ПараметрыОжидания);
    КонецПроцедуры

    // 3. Обработка результата выполнения фонового задания.
    &НаКлиенте
    Процедура ПриЗавершенииПоискаНастроек(Результат, ДополнительныеПараметры) Экспорт

    Если Результат = Неопределено Тогда // Пользователь отменил задание.
    Возврат;
    КонецЕсли;

    Если Результат.Статус = "Ошибка" Тогда
    ВызватьИсключение Результат.КраткоеПредставлениеОшибки;
    КонецЕсли;

    Настройки = ПолучитьИзВременногоХранилища(Результат.АдресРезультата);
    УстановитьНастройкиУчетнойЗаписи(Настройки);

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

    Если МонопольныйРежим() Тогда
    Возврат;
    КонецЕсли;

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

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

    На время выполнения этого фонового задания следует блокировать весь интерфейс приложения, открывая форму ожидания завершения операции в режиме РежимОткрытияОкна = БлокироватьВесьИнтерфейс. Блокировать интерфейс приложения требуется потому, что на время выполнения задания полноценная работа пользователя с приложением уже невозможна:

    • Если пользователь(*) попытается записать какой-либо объект, это приведет к ошибке (из-за установленного монопольного режима);
    • В ряде случаев могут запускаться фоновые задания в качестве реакции на действия пользователя случае (при поиске в динамическом списке, при вводе по строке, формировании отчетов и пр.), которые также завершатся с ошибкой.
      Кроме того, на самой форме ожидания длительной операции не следует размещать элементы управления, которые могут приводить к запуску таких фоновых заданий. Например: поля ввода, динамические списки и отчеты.

    * Примечание: ошибки записи также возникают в тех случаях, когда объекты записываются программно, например, из обработчиков ожидания. В них также следует проверять монопольный режим согласно п.5.

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

    Недавно я разместил статью: Чтение данных с сайта в формате XML и загрузка в 1С пришло время это автоматизировать:

    Регламентные и фоновые задания

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

    Механизм заданий решает следующие задачи:

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

    Механизм заданий состоит из следующих компонентов:

    • Метаданных регламентных заданий;
    • Регламентных заданий;
    • Фоновых заданий;
    • Планировщика заданий.

    Фоновые задания & предназначены для выполнения прикладных задач асинхронно. Фоновые задания реализуются средствами встроенного языка.

    Регламентные задания & предназначены для выполнения прикладных задач по расписанию. Регламентные задания хранятся в информационной базе и создаются на основе метаданных, определяемых в конфигурации. Метаданные регламентного задания содержат такую информацию как наименование, метод, использование и т.д.

    Регламентное задание имеет расписание, которое определяет, в какие моменты времени нужно выполнять связанный с регламентным заданием метод. Расписание, как правило, задается в информационной базе, но может быть задано и на этапе конфигурирования (например, для предопределенных регламентных заданий).

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

    С описанием, думаю, хватит – приступим к реализации:

    Создание регламентного задания

    Имя метода – путь к процедуре, которая будет выполняться в фоновом задании по заданному расписанию. Процедура должна находиться в общем модуле. Рекомендуется не использовать типовые общие модули, а создать свой. Не забудьте, что фоновые задания исполняются на сервере!

    Использование – признак использования регламентного задания.

    Предопределенное – указывает, является ли регламентное задание предопределенным.

    Если хотите что бы регламентное задание заработало сразу после помещения в БД, укажите признак Предопределенное. В противном случае вам необходимо будет использовать обработку “Консоль заданий” или вызывать запуск задания программно.

    Количество повторов при аварийном завершении задания – сколько раз выполнен перезапуск фонового задания, если оно было выполнено с ошибкой.

    Интервал повтора при аварийном завершении задания – с какой периодичностью будет выполнен перезапуск фонового задания, если оно было выполнено с ошибкой.

    Настройка расписания

    Расписание выполнения задания:

    Каждый час, только один день ПериодПовтораДней = 0, ПериодПовтораВТечениеДня = 3600
    Каждый день один раз в день ПериодПовтораДней = 1, ПериодПовтораВТечениеДня = 0
    Один день, один раз ПериодПовтораДней = 0
    Через день один раз в день ПериодПовтораДней = 2
    Каждый час с 01.00 до 07.00 каждый день ПериодПовтораДней = 1ПериодПовтораВТечениеДня = 3600ВремяНачала = 01.00
    Каждую субботу и воскресенье в 09.00 ПериодПовтораДней = 1ДниНедели = 6, 7ВремяНачала = 09.00 Каждый день одну неделю, неделя пропуска ПериодПовтораДней = 1ПериодНедель = 2 В 01.00 один раз ВремяНачала = 01.00 Последнее число каждого месяца в 9:00. ПериодПовтораДней = 1ДеньВМесяце = -1ВремяНачала = 09.00 Пятое число каждого месяца в 9:00 ПериодПовтораДней = 1ДеньВМесяце = 5ВремяНачала = 09.00 Вторая среда каждого месяца в 9:00 ПериодПовтораДней = 1ДеньНеделиВМесяце = 2ДниНедели = 3

    Особенности выполнения фоновых заданий файловом и клиент-серверном вариантах

    Механизмы выполнения фоновых заданий в файловом и клиент-серверном вариантах различаются.

    В файловом варианте необходимо создать выделенный клиентский процесс, который будет заниматься выполнением фоновых заданий. Для этого в клиентском процессе должна периодически вызываться функция глобального контекста ВыполнитьОбработкуЗаданий. Только один клиентский процесс на информационную базу должен выполнять обработку фоновых заданий (и, соответственно, вызывать данную функцию). Если клиентского процесса для обработки фоновых заданий не создано, то при программном доступе к механизму заданий будет выдана ошибка «Менеджер заданий не активен». Не рекомендуется клиентский процесс, выполняющий обработку фоновых заданий, использовать для других функций.

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

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

    В клиент-серверном варианте имеется возможность блокирования выполнения регламентных заданий. Блокирование выполнения регламентных заданий происходит в следующих случаях:

    • На информационную базу установлена явная блокировка регламентных заданий. Блокировка может быть установлена через консоль кластера;
    • На информационную базу установлена блокировка соединения. Блокировка может быть установлена через консоль кластера;
    • Из встроенного языка вызван метод УстановитьМонопольныйРежим() с параметром Истина;
    • В некоторых других случаях (например, при обновлении конфигурации базы данных).

    Обработки запуска и просмотра регламентных заданий вы можете скачать здесь:

    Тема достаточно широко освещена, но мне не попадалась информация о том, как отслеживать выполнение фонового задания собственным прогрессом, расположенным на форме.

    Ниже несколько ссылок по фоновому выполнению кода:

    • Фоновое задание – это просто – п ример запуска фонового задания из общего модуля. Самый простой вариант, без отслеживания выполнения задания.
    • Отображение прогресса выполнения длительных операций в БСП и их отладка в текущем сеансе – пример с использованием БСП. Запуск фонового задания, расположенного в общем модуле. Реализация собственной формы для отслеживания его выполнения.
    • Запуск фонового задания из внешней обработки – б олее сложный пример с использованием БСП. Запуск фонового задания из внешней обработки и отслеживание выполнения задания средствами БСП.
    • Произвольный код в фоновом режиме – т акже запуск фонового задания из внешней обработке. Частичное использование БСП. Правда метод « ЗапуститьВыполнениеВФоне » является устаревшим на данный момент.

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

    Второй и третий варианты хорошие, в них используется функционал БСП для отслеживания хода выполнения задания:

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

    Возьмем понемногу из всех вариантов, описанных выше, и получим следующее решение:

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

    Для запуска фонового задания используем метод из БСП ДлительныеОперации.ВыполнитьВФоне.

    Для отслеживания хода выполнения создадим на форме обработки два элемента управления: Прогресс и Тестовое поле.

    Также будем выводить сообщения пользователю, которые были сформированы в фоновом задании, это очень удобно.

    Дальше возникает вопрос, как получать информацию из фонового задания?

    Это можно сделать несколькими способами:

  1. Через механизм сообщений – самый простой и распространенный способ, который используют методы из БСП.
  2. Через сервер взаимодействия – вариант не плохой, но сложный. Нужно разворачивать сам сервер взаимодействия. Понятно, что только для получения информации из фоновых заданий, это делать смысла нет.
  3. Через временное хранилище – в некоторых источниках описывается данный вариант взаимодействия, но он работает только для файловых баз. В клиент-серверном режиме работы, получить данные из временного хранилища можно только после завершения фонового задания. Это нам не подходит.
  4. Через хранилище общих настроек – я не тестировал данный вариант, но в статье про менеджер потоков судя по всему используется именно этот вариант.

Будем пользоваться первым способом используя методы БСП:

  • ДлительныеОперации.СообщитьПрогресс
  • ДлительныеОперации.ПрочитатьПрогресс
  • ДлительныеОперации.СообщенияПользователю

Ниже привожу тексты модуля обработки и модуля формы:

Тексты процедур модуля обработки

Создаем одну команда для открытия формы, вторую для выполнения в фоне.

Не забудьте указать версию БСП. Если ее не указать, запуск процедуры модуля обработки с указанием структуры параметров работать не будет.

Здесь все просто, выполняется выборка документов по регистру «ТоварыОрганизаций» за переданный в фоновое задание период и документы последовательно перепроводятся. После каждого 5 документа отправляются данные о состоянии выполнения основному сеансу. В случае ошибки отправляется информация о документе, в котором произошла ошибка. Задержка в одну секунду нужна для обработки информации об ошибки в основном сеансе.

Тексты процедур модуля формы

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

Создаем фоновое задание, передаем в него параметры по периоду. Сохраняем идентификатор задания в реквизите формы и создаем обработчик ожидания.

Проверяем состояние выполнения задания. Информацию о стадии выполнения задания отображаем виде прогресса, расположенного на форме и текстового поля. Также выводим сообщения, сформированные в фоновом задании. Например, если будет ошибка проведения документа, информация будет выведена в текстовом поле и в окне сообщений формы.

Если задание не выполнено, подключаем опять обработчик ожидания. Если в задании была ошибка при проведении документа «РезультатВыгрузки.Процент = -1», закрываем его принудительно. На всякий случай, так как оно и так должно закрыться через секунду.

Тут особо комментировать нечего. Настройка периода и принудительное завершение фонового задания.

Вот и все, получаем отслеживание работы фонового задания непосредственно в форме обработки.

Можно продолжить развивать данную тему, и реализовать многопоточность. Например перепроведение документов в потоках. Это может ускорить процесс в пять или более раз! Если эта тема интересна, напишите пожалуйста в комментариях.

Оцените статью
ПК Знаток
Добавить комментарий

Adblock
detector