Ошибка выполнения фонового задания проверки выгрузки. Регламентные и фоновые задания (1Cv8)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Отказоустойчивый кластер
  • Масштабируемость кластера серверов

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

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

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 рабочих процесса, для которых суммарное количество обслуживаемых соединений и различных информационных баз меньше, чем значения, указанные в свойствах рабочего сервера (свойства Количество соединений на процесс и Количество ИБ на процесс ), то процесс, который обслуживает меньшее количество соединений, будет помечен как устаревший и будет остановлен после разрыва последнего соединения. Существующим соединениям с «устаревшим» рабочим процессом будет «предложено покинуть» рабочий сервер при ближайшем серверном вызове через данное соединение. При этом «устаревший» рабочий процесс не участвует в распределении запросов на обслуживание новых объектов требований.

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

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

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

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

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

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

В 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, под которым выполняется задание.

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

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

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

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

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

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

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

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

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

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

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

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

Реквизиты :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полезно знать