Отдельный сервер под 1с фоновые задания. Универсальное регламентное задание

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

Создадим регламентное задание «Выполнение обработки».

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

Назначим процедуру, которая будет срабатывать при запуске регламентного задания: МодульРегламентныхЗаданий.РегламентноеЗаданиеВыполнениеОбработки .

Сама процедура имеет вид:

Процедура РегламентноеЗаданиеВыполнениеОбработки(Ключ) Экспорт

ПараметрыРегламентныхЗаданий.ВыполнитьОбработкуСПараметрами(Ключ);

КонецПроцедуры

Создаем справочник для регламентных заданий

Наше регламентное задание может порождать множество фоновых процессов - по одному на каждую обработку. У каждого задания в платформе 1С8 есть ключ. Но метод регламентного задания не знает ключ фонового задания, поэтому нужно использовать параметры фонового задания. В результате мы можем видеть фоновое задание в консоли заданий, но не можем вручную из этой консоли создать фоновое задание, т.к. задания с параметрами вручную не создаются.

Справочник «Параметры регламентных заданий» :

Реквизиты :

· КодПередЗапуском - неограниченная строка - код на языке 1С, который нужно выполнить перед запуском.

· Обработка из конфигурации - строка (100) - идентификатор обработки из конфигурации

· Обработка из справочника - строка (100) - ссылка на элемент справочника «Внешние обработки», если такой имеется в конфигурации

· Выполнять через приложение 1С - булево - будет создано отдельное приложение 1С и в нем будет запущено регламентное задание. Создано для 8.1, где не все методы приложения доступны на сервере, где работает регламентное задание.

· КодЗапуска - - неограниченная строка - код на языке 1С, который будет выполняться при запуске регламентного задания.

Создадим форму элемента :

По нажатию на кнопку «Создать регл. задание» программно создается регламентное задание с ключом-кодом:

Процедура ОсновныеДействияФормыСоздатьРеглЗадание(Кнопка)

Перем Задание;

Ключ = СокрЛП(Код);

Задание = РегламентныеЗадания.СоздатьРегламентноеЗадание("ВыполнениеОбработки");

Задание.Наименование = Ключ;

Задание.Ключ = Ключ;

Параметры = Новый Массив();

Параметры.Добавить(Ключ);

Задание.Параметры = Параметры;

Задание.Записать();

КонецПроцедуры

Запуск регламентного задания

Каждое созданное нами регламентное задание имеет ключ:

Этот ключ соответствует коду справочника «Параметры регламентных заданий», по нему осуществляется поиск при старте задания. Если элемент справочника не найдено, задание не выполняется.

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

В зависимости от выбранных значений реквизитов или запустится код на языке 1С, или запустится обработка из конфигурации, или обработка из типового справочника «Внешние обработки».

Для 1С81 предусмотрено выполнение в новом приложении - чтобы можно было использовать код, доступный только на клиенте, в том числе и использование внешних обработок. Для этого нужно установить галочку «Выполнять через приложение 1С». Иначе регламентное задание будет выполняться на сервере.

Рекомендую устанавливать пользователя в поле «Пользователь» у вновь созданного регламентного задания, чтобы задание выполнялось под определенными правами. Рекомендую такому пользователю давать полные права. У меня используется пользователь « robot ».

Расписание регламентного задания создается по гиперссылке «Расписание» из формы регламентного задания. Можно использовать обработку «Консоль регламентных заданий».

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

Развернутую инструкцию на примере Вы найдете далее.

Что такое регламентные и фоновые задания в 1С

• Регламентные задания — это специальный механизм 1С предприятия 8.3, предназначенный для выполнения определенного действия по заданному расписанию.
• Фоновое задание — объекты, порождаемые регламентным заданием, которые непосредственно выполняет заложенное действие без участия пользователя или программиста 1С 8.2.

Механизм регламентных и фоновых заданий работает в клиент-серверном режиме работы (SQL), благодаря функционалу СУБД. Если у вас файловая БД, то задание тоже можно настроить, но немного по другому принципу.

Настройка фоновых заданий в клиент-серверном режиме работы 1С

Для начала создадим новый объект метаданных — регламентное задание. Я назову свое задание «ЗагрузкаКурсовВалют». Рассмотрим палитру свойств данного объекта конфигурации:

Получите 267 видеоуроков по 1С бесплатно:

• Имя метода — путь к процедуре, которая будет выполняться в фоновом задании по заданному расписанию. Процедура должна находиться в общем модуле. Рекомендуется не использовать типовые , а создать свой. Не забудьте, что фоновые задания исполняются на сервере!
• Использование — признак использования регламентного задания.
• Предопределенное — указывает, является ли регламентное задание предопределенным. Если хотите чтобы регламентное задание заработало сразу после помещения в БД, укажите этот признак. В противном случае вам необходимо будет использовать обработку «Консоль заданий» или вызывать запуск задания программно.
• Количество повторов при аварийном завершении задания — сколько раз выполнен перезапуск фонового задания, если оно было выполнено с ошибкой.
• Интервал повтора при аварийном завершении задания — с какой периодичностью будет выполнен перезапуск фонового задания, если оно было выполнено с ошибкой.

И самая интересная настройка — Расписание:

Тут настраивается интервал запуска процедуры, указанного в поле «Имя метода». Допустим я настроил

Внимание! Не забудьте отключить блокировку выполнения регламентных и фоновых заданий на уровне СУБД!

Сделать это можно в утилите администрирования клиент-серверного варианта либо при создания новой БД:

Настройка регламентных заданий в файловом режиме работы 1С

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

В файловом режиме инициализация регламентного задания происходит при запуске метода «ВыполнитьОбработкуЗаданий()».

Для определенного пользователя можно настроить запуск этого метод, используя другой метод —

ПодключитьОбработчикОжидания(<ИмяПроцедуры>, <Интервал>, <Однократно>).

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

ПодключитьОбработчикОжидания, 3600 ) ;

Двухминутное видео, в котором показано, как настроить регламентное задание в конфигураторе 1С:

Некоторые задачи в документообороте и учете бывает необходимо выполнять периодически. Например, по двадцатым числам. Или ежедневно.

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

Такие задачи называют – регламентированными, то есть выполняемые согласно регламента.

В ИТ часто регламентированно выполняется мониторинг.

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

Аналогичные вещи существуют для вебмастеров – для проверки доступности сайта в течении суток.

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

Поговорим сегодня про них.

Регламентные задания 1С

Регламентные задания 1С – это , который позволяет выполнять , как это делает , а по расписанию.

Само регламентное задание 1С в конфигураторе – это способ указать настройки и задать расписание. Кстати, расписание можно менять динамически потом в режиме 1С Предприятие.

Фоновые задания можно создавать из текста программы на языке 1С произвольно без регламентного задания 1С – для параллельных вычислений на сервере.

Выполнение регламентных заданий 1С можно отключить временно – в .

Добавление регламентного задания 1С

Регламентные задания 1С находятся в конфигурации в ветке Общие/Регламентные задания 1С. Добавим новое регламентное задание 1С, укажем его имя.

В свойстве регламентного задания 1С Имя метода – указывается , также как и в . Функция будет находиться в общем модуле с установленной галочкой Сервер в свойствах, то есть модуль должен быть добавлен заранее.

Свойство регламентного задания 1С — Наименование задания – определяет название, под которым будет фигурировать задание в средствах управления заданиями.

Свойство регламентного задания 1С – Ключ – позволяет сгруппировать несколько разных регламентных заданий 1С. Одновременно может быть запущено только одно задание с одинаковым значением ключа. Само значение может быть произвольным. Пустое значение не учитывается при контроле (то есть считается не заполненным).

Свойство регламентного задания 1С – Предопределенное – определяет, что при запуске 1С Предприятия такое задание будет создано и в единственном экземпляре с указанными в конфигураторе расписанием. Не предопределенные задания появляются в момент наступления расписания программно.

В типовых конфигурациях, например Бухгалтерии редакции 2.0, такие регламентные задания 1С как Обновление конфигурации и Пересчет итогов – предопределенные, а такие как Обмен данными или Отложенные движения – не предопределенные.

Использование – включает задание (то есть оно будет выполняться только если галочка Использование установлена).

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

Управление регламентным заданием 1С и мониторинг

Для управления регламентными заданиями 1С существует специальная типовая обработка Консоль заданий. Ее можно найти в том числе на .

Эта обработка относится к так называемым универсальным внешним типовым обработкам 1С, которые часто не включаются в конфигурации, а распространяются отдельно, например, на дисках ИТС.

С помощью обработки консоль заданий можно:

• Включить/выключить выполнение регламентного задания 1С
• Назначить/изменить расписание регламентного задания 1С (да и другие параметры)
• Указать пользователя 1С, от имени которого будет выполнена регламентное задание 1С
• Посмотреть — какие задачи когда были выполнены и с каким результатом, ошибки выполнения заданий 1С
• Выполнить задание.

Копии баз данных и регламентные задания 1С

Если используется серверная 1С, то бывает следующая ситуация:

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

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

Однако частенько регламентные задания 1С могут сохранять какие-либо файлы, данные в другие базы, проводить обмен, высылать электронные письма.

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

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

Выполнение и невыполнение регламентных задач 1С

При создании регламентных заданий 1С необходимо помнить:

• Задачи выполняются сами собой – их необходимо мониторить
• Задачи выполняются в модуле на сервере
• Задачи выполняются под другим пользователем Windows, под другими правами.

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

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

В-третьих, если задача имеет дело с чем-то вне базы 1С, то важное значение приобретают права пользователя Windows, под которым выполняется задание.

Особенно важен при разработке третий пункт. Если модуль не может быть выполнен на сервере – задание не будет выполняться в принципе. Для проверки нужно хотя бы раз запустить задание и посмотреть результат «Задание выполнено» в обработке Консоль заданий.

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

• Отказоустойчивый кластер

• Масштабируемость кластера серверов

• Требования назначения функциональности

Отказоустойчивый кластер

2.1.7. Балансировка нагрузки в кластере

2.1.7.1. Доступная производительность рабочего процесса

Каждый рабочий процесс имеет свойство Доступная производительность . Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонный вызов сервера по сравнению с другими рабочими процессами. Эталонный вызов включает в себя следующие операции:

● Операция с памятью: выделение массива, заполнение массива, освобождение массива.

● Операция с файлами: создание, запись, удаление.

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

Значение свойства Доступная производительность вычисляется делением числа 10 000 на среднее (за 5 минут) время выполнения эталонного вызова текущим рабочим процессом. Эталонный вызов выполняется каждые 2 секунды в том случае, если в кластере присутствует несколько рабочих серверов. Если кластер серверов состоит из одного рабочего сервера – все рабочие процессы считаются равноправными.

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

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

При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.

2.1.7.3. Требования назначения функциональности

2.1.7.3.1. Общая информация

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

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

Требование назначения функциональности определяет:

● Для какого объекта требования создается требование. В качестве объекта требования могут выступать некоторые сервисы кластера (см. ), клиентские соединения (см.) и произвольный объект требования. В качестве объекта требования могут выступать следующие сервисы кластера:

● Блокировок объектов.

● Времени.

● Журналов регистрации.

● Заданий.

● Нумерации.

● Полнотекстового поиска.

● Пользовательских настроек.

● Сеансовых данных.

● Транзакционных блокировок.

● Работы с внешними источниками данных через ODBC.

● Работы с внешними источниками данных через XMLA.

● Сервис лицензирования.

● Сервис фонового обновления конфигурации базы данных.

● Сервис тестирования.

● Сервис внешнего управления сеансами.

● Определяет тип требования. Тип требования определяет, каким образом будет выполняться использование рабочего сервера:

● Не назначать – означает, что рабочий сервер, для которого создано данное требование, не будет назначен для обслуживания объекта требования, подходящего под условия, заданные в требовании.

● Назначать – означает, что рабочий сервер, для которого создано данное требование, будет являться одним из кандидатов на обслуживание данного объекта требования (если рабочих серверов будет несколько).

● Авто – означает, что рабочий сервер может быть использован для обслуживания объекта требования в том случае, если нет рабочего сервера с явным указанием необходимости использования.

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

● Дополнительные параметры, необходимые кластеру серверов для принятия решения в ряде случаев:

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

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

● Для указания конкретного фонового задания: BackgroundJob.CommonModule. <Имя модуля>.<Имя метода> ;

● Для указания всех фоновых заданий: BackgroundJob.CommonModule ;

● Для указания всех отчетов: BackgroundJob.Report . Указание имени отчета не поддерживается;

● Ввод по строке или поиск в списке: BackgroundJob.SystemBackgroundJob ;

● Для указания фоновой реструктуризации: SystemBackgroundJob ;

● Для клиентского приложения:

● 1CV8 – толстый клиент;

● 1CV8CDirect – тонкий клиент в случае прямого подключения к серверу «1С:Предприятия»;

● Designer – конфигуратор;

● COMConnection – COM-соединение;

● WebServerExtension – соединение с информационной базой через веб-сервер: веб-клиент, тонкий клиент в случае подключения через веб-сервер, Web-сервис.

Рассмотрим, как работает кластер серверов при обработке требований.

В случае необходимости выполнить размещение объекта требования, кластер выполняет следующие действия:

● На всех серверах, входящих в состав кластера, выполняется обработка заданных для этих серверов требований назначения функциональности. Обход серверов и требований выполняется в порядке следования этих объектов в консоли кластера.

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

● Затем полученный список рабочих серверов сортируется по признаку типа требования так, что первыми оказываются рабочие сервера с явным указанием использования. Рабочие сервера, для которых подходящее требование содержит явный запрет на использование – исключаются из списка доступных рабочих серверов. При этом назначение выполняется следующим образом:

● Есть рабочие сервера с явным указанием использования: в этом случае объект требования будет обслужен одним из этих рабочих серверов.

● Нет рабочих серверов с явным указанием использования: происходит попытка использовать рабочие сервера с автоматическим указанием использования или те рабочие серверы, для которых не указано требований.

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

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

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

● Если невозможно выполнить размещение на выбранном рабочем сервер, например, если выбранный сервер вышел из строя, и нет альтернативных рабочих серверов.

2.1.7.3.2. Назначение объектов требований

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

● Сервис одного типа, если сервис не делится по информационным базам.

● Сервис одного типа для одной информационной базы, если сервис делится по информационным базам.

● Сервис сеансовых данных.

● Сервис лицензирования.

Сервисы распределяются между подходящими рабочими серверами следующим образом:

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

● Среди отобранных рабочих серверов сервисы распределяются равномерно.

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

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

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

● Остальные сервисы назначаются в единственном экземпляре.

Переназначение сервисов кластера между рабочими серверами может выполняться в следующих случаях:

● При добавлении рабочего сервера выполняется частичное переназначение сервисов. Данное переназначение выполняется автоматически.

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

● При удалении или добавлении информационной базы в кластер выполняется частичное переназначение. Данное переназначение выполняется автоматически.

2.1.7.3.3. Назначение рабочих процессов

Установка соединения клиентского приложения с кластером серверов «1С:Предприятия» выполняется по следующим правилам:

● В соответствии с требованиями назначения и ограничениями по использованию оперативной памяти отбирается необходимый рабочий сервер.

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

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

● Для рабочего процесса не достигнуто максимальное количество обслуживаемых информационных баз (свойство рабочего сервера Количество ИБ на процесс ).

● Для рабочего процесса не достигнуто максимальное количество обслуживаемых соединений (свойство рабочего сервера ).

● Рабочий процесс не находится в состоянии подготовки к автоматическому перезапуску.

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

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

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

Если на одном рабочем сервере в течении 20 минут существуют 2 рабочих процесса, для которых суммарное количество обслуживаемых соединений и различных информационных баз меньше, чем значения, указанные в свойствах рабочего сервера (свойства Количество соединений на процесс и Количество ИБ на процесс ), то процесс, который обслуживает меньшее количество соединений, будет помечен как устаревший и будет остановлен после разрыва последнего соединения. Существующим соединениям с «устаревшим» рабочим процессом будет «предложено покинуть» рабочий сервер при ближайшем серверном вызове через данное соединение. При этом «устаревший» рабочий процесс не участвует в распределении запросов на обслуживание новых объектов требований.

Механизм заданий

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

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

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

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

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

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

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

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

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

Фоновые задания

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

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

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

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

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

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

Завершившиеся успешно или аварийно фоновые задания хранятся в течение суток, а потом удаляются. Если количество выполнившихся фоновых заданий превышает 1000, то наиболее старые фоновые задания также удаляются.

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

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

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

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

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

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

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

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

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

Примеры расписаний регламентных заданий:

Можно проверять, выполняется ли задание для заданной даты (метод ТребуетсяВыполнение объекта РасписаниеРегламентныхЗаданий). Регламентные задания всегда выполняются о имени определенного пользователя. Если пользователь регламентного задания не указан, то выполнение происходит от имени пользователя по умолчанию, имеющего административные права.

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

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

Важно помнить что Время конца не обязательно завершит фоновое задание в указанное время. Некоторые утверждения:

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

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

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

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

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

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

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

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

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

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

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

Имя метода - указывается имя метода регламентного задания.

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

Расписание - указывается расписание регламентного задания. Для формирования расписания щелкните ссылку «Открыть» и в открывшейся форме расписания установите нужные значения.

На закладке «Общее» указываются дата начала и завершения задания и режим повтора.

На закладке «Дневное» указывается дневное расписание задания.

Укажите расписание:

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

Допускается указание произвольного сочетания условий.

На закладке «Недельное» указывается недельное расписание задания.

Установите флажки по тем дням недели, по которым задание будет выполняться. Если требуется повторять задание, укажите интервал повтора в неделях. Например, задание выполняется через 2 недели, значение повтора – 2.

На закладке «Месячное» указывается месячное расписание задания.

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

Использование - если установлено, то задание будет выполняться согласно расписанию.

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

Количество повторов при аварийном завершении - указывает количество повторов при аварийном завершении.

Интервал повтора при аварийном завершении - указывает интервал повтора при аварийном завершении. Примеры

Создание фонового задания «Обновление индекса полнотекстового поиска»:

ФоновыеЗадания.Выполнить("ОбновлениеИндексаПолнотекстовогоПоиска");

Создание регламентного задания «Восстановление последовательностей»:

Расписание = Новый РасписаниеРегламентногоЗадания; Расписание.ПериодПовтораДней = 1; Расписание.ПериодПовтораВТечениеДня = 0;

Задание = РегламентныеЗадания.СоздатьРегламентноеЗадание("ВосстановлениеПоследовательностей"); Задание.Расписание = Расписание; Задание.Записать();

Консоль заданий

Обработка с ИТС, осуществляет управление регламентными заданиями:

Работа с регламентными заданиями

Объекты заданий

Объекты заданий не являются ссылочными, но хранятся в базе данных в каком-то специальном хранилище.

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

Если флаг "Предопределенное" не установлен, то объекты такого задания создаются и удаляются программно, с указанием расписания и параметров.

Получение списка заданий

Список заданий можно получить методом ПолучитьРегламентныеЗадания глобального менеджера заданий РегламентныеЗадания

МенеджерРегламентныхЗаданий (ScheduledJobsManager)

ПолучитьРегламентныеЗадания (GetScheduledJobs)

Синтаксис:

ПолучитьРегламентныеЗадания(<Отбор>)

Параметры:

<Отбор> (необязательный)

Тип: Структура. Структура, задающая отбор. Значениями структуры могут быть: УникальныйИдентификатор, Ключ, Метаданные, Предопределенное, Использование, Наименование. Если отбор не задан, получаются все регламентные задания.

Если выполняется отбор по метаданным, то в качестве значения Метаданные можно указать либо объект метаданных регламентного задания, либо его имя.

Возвращаемое значение:

Тип: Массив.

Описание:

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

Доступность:

Регламентные = РегламентныеЗадания.ПолучитьРегламентныеЗадания(Отбор);

Для Каждого Регламентное из Регламентные Цикл НоваяСтрока = СписокРегламентныхЗаданий.Добавить(); НоваяСтрока.Метаданные = Регламентное.Метаданные.Представление(); НоваяСтрока.Наименование = Регламентное.Наименование; НоваяСтрока.Ключ = Регламентное.Ключ; НоваяСтрока.Расписание = Регламентное.Расписание; НоваяСтрока.Пользователь = Регламентное.ИмяПользователя; НоваяСтрока.Предопределенное = Регламентное.Предопределенное; НоваяСтрока.Использование = Регламентное.Использование; НоваяСтрока.Идентификатор = Регламентное.УникальныйИдентификатор;

ПоследнееЗадание = Регламентное.ПоследнееЗадание; Если ПоследнееЗадание <> Неопределено Тогда НоваяСтрока.Выполнялось = ПоследнееЗадание.Начало; НоваяСтрока.Состояние = ПоследнееЗадание.Состояние; КонецЕсли; КонецЦикла;

Создание

Создается методом СоздатьРегламентноеЗадание менеджера регламентных заданий:

РегламентноеЗадание = РегламентныеЗадания.СоздатьРегламентноеЗадание(МетаданныеВыбор);

РегламентноеЗадание.Наименование = Наименование; РегламентноеЗадание.Ключ = Ключ; РегламентноеЗадание.Использование = Использование; РегламентноеЗадание.ИмяПользователя = ПользователиВыбор; РегламентноеЗадание.КоличествоПовторовПриАварийномЗавершении = КоличествоПовторовПриАварийномЗавершении; РегламентноеЗадание.ИнтервалПовтораПриАварийномЗавершении = ИнтервалПовтораПриАварийномЗавершении; РегламентноеЗадание.Расписание = Расписание; РегламентноеЗадание.Записать();

ОбъектЗадания = РегламентныеЗадания.СоздатьРегламентноеЗадание("ВыполнениеОбмена");

ОбъектЗадания.Наименование = Наименование; ОбъектЗадания.Использование = Истина;

Объект задания имеет поле "Параметры", в котором задаются параметры метода:

РегламентноеЗадание (ScheduledJob)

Параметры (Parameters)

Использование:

Чтение и запись.

Описание:

Тип: Массив. Массив параметров регламентного задания. Количество и состав параметров должен соответствовать параметрам метода регламентного задания.

Доступность:

Сервер, толстый клиент, внешнее соединение.

Примечание:

Возможность чтения и записи доступны только для администратора.

Удаление

Удаляется методом Удалить() объекта задания:

РегламентноеЗадание.Удалить();

Получение объекта задания

• списком через метод ПолучитьРегламентныеЗадания:

Регламентные = РегламентныеЗадания.ПолучитьРегламентныеЗадания(Отбор);

• через метод НайтиПоУникальномуИдентификатору менеджера заданий:

Задание = РегламентныеЗадания.НайтиПоУникальномуИдентификатору(УИД);