SAP R/3 Системное администрирование - Сигрид Хагеман

Планировщик фоновых заданий на основе событий

Планировщик на основе событий функционирует в системе R/3 на уровне приложений. Он запускает соответствующее фоновое задание в ответ на определенное событие. Планировщик заданий на основе событий также обрабатывается диалоговым рабочим процессом. Инстанцию для него можно выбрать с помощью параметра rdisp/btcname = <имя_сервера> в стандартном профиле системы R/3 (DEFAULT.PFL).

Системные события

Сначала необходимо определить события, на которые должна реагировать система R/3. В стандартной системе R/3 уже определены многие виды событий. Для вывода списка этих событий можно использовать ►Event Maintenance. События, определенные для стандартной системы, называются системными. Они часто используются для внутреннего управления R/3, но могут применяться и пользователями R/3 для своих целей.

Пользовательские события

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

Инициация события (триггеры)

Инициировать событие можно следующими способами:

► Вручную с целью тестирования — с помощью ►Trigger Event

► Используя в программе АВАР в системе R/3 функциональный модуль BP_EVENT_RAISE

► Посредством внешней программы sapevt

Программа sapevt

Программа sapevt позволяет инициировать событие в системе R/3 из внешней программы. Эта программа доступна в стандартном каталоге SAP для исполнимых программ (см. главу 1). Вызывается она так:

□ sapevt <идентификатор события> [-р <параметр>] [-t] [pr = <профиль> name = <имя_системы R/3> nt = <номер_системы R/3>]

Параметр -t задает запись файла журнала dev_evt в тот каталог, откуда вызывалась программа sapevt. Параметр -р можно использовать для указания модуля R/3, например F1. Это позволяет присваивать события прикладным областям. Это присваивание имеет только описательную природу и не обладает другими функциями.

Например, вызов:

□ sapevt SAP_TRIGGER_RDDIMPDP name=Q01 nr=00

инициирует событие SAP_TRIGGER_RDDIMPDP в системе Q01.

В самой системе R/3 управление событиями используется, например, для переноса объектов между системами R/3. Перенос выполняется в несколько этапов с помощью программы управления переносом tp. Кроме фактического импорта данных нередко возникает необходимость сгенерировать или активизировать отдельные объекты. Программа tp инициирует событие SAP_TRIGGER_RDDIMPDP при завершении импорта данных. В системе R/3 задание RDDIMPDP всегда планируется как зависимое от события SAP_TRIGGER_RDDIMPDP. Если наступает это событие, то в фоновом режиме выполняется задание RDDIMPDP.

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

Для определения фоновых заданий в R/3 используется ►Job Definition (см. рис. 9.2).

Рис. 9.2. Начальный экран: Job Definition

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

Определение фонового задания охватывает три основных области:

► Общую информацию, такую как имя задания, его класс и целевой сервер

► Информацию о времени запуска или инициирующем событии.

► Список шагов обработки

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

Классы заданий

Приоритет выполнения задания определяется присвоенным ему классом. Существуют следующие классы заданий:

► А: наивысший приоритет — задания, обеспечивающие функционирование R/3 и критические по времени

► В: средний приоритет — периодические задания, обеспечивающие функционирование R/3

► С: обычный приоритет — обычные задания для пользователей R/3

Класс задания используется для присвоения ему системных ресурсов. Если приходится часто обрабатывать большое число заданий класса C (это означает, что задания класса A и B должны ожидать освобождения фоновых процессов), то системный администратор может явным образом зарезервировать некоторое число n фоновых процессов для заданий класса А в ►Operation Mode Maintenance. Такая конфигурация гарантирует, что п фоновых процессов всегда доступны для выполнения заданий класса А. Задания классов В и С должны ждать, пока число доступных фоновых процессов не будет равно как минимум п+1. Эта конфигурация описана в разделе 14.2.

Целевой сервер

В распределенной системе R/3 можно также указать инстанцию R/3 со службой фоновой обработки заданий. Эта инстанция R/3 называется целевым сервером в контексте фоновой обработки. Если инстанция не указывается, то во время выполнения R/3 выбирает первый доступный фоновый процесс в любой инстанции.

Для обработки запроса на определенном фоновом сервере выделены следующие приоритеты:

1. Задание класса A, целевой сервер задан

2. Задание класса A, целевой сервер не определен

3. Задание класса B, целевой сервер задан

4. Задание класса B, целевой сервер не определен

5. Задание класса C, целевой сервер задан

6. Задание класса C, целевой сервер не определен

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

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

Созданный программой АВАР вывод сохраняется как запрос спула в системе спула SAP. С помощью средства Spool List Recipient можно послать вывод пользователю. Эта техника позволяет, например, нескольким людям управлять фоновым заданием и анализировать его результаты. Поскольку вывод может быть достаточно большим, то рекомендуется использовать эту возможность с осторожностью. По соображениям производительности длина вывода, посылаемого в SAPoffice, ограничена 1000 строками. Значения параметров печати задаются при определении шага (см. раздел 9.2.3).

Следующий шаг состоит в выборе параметров, определяющих время запуска. Выберите на начальном экране определения задания условие Start. Можно назначить запуск задания на конкретное время или запускать его по событию (см. рис. 9.3). Используемая информация о времени и часовом поясе основывается на системном времени. Кроме определения времени запуска задания, планирование заданий по времени позволяет также планировать периодическое выполнение задания, например для регулярного анализа служебных заданий (см. раздел 9.6). Можно выбрать любой интервал повторения: через несколько минут, каждый час, ежедневно, еженедельно и т.д. Можно воспользоваться кнопкой Restrictions для определения исключений для обычного периода, например для указания дней отдыха в действующем производственном календаре. Когда используются задания, чувствительные ко времени, можно определить самое позднее возможное время для запуска задания (No start after).

Вместо определения управления по времени можно также определить некоторое событие в качестве триггера. В частности, изменения операционных режимов (см. главу 14) и конец задания определяются как события, что означает, что фоновое задание может также выполняться в зависимости от другого, уже определенного задания. В этом случае второе задание запускается после окончания первого. Если нужно запустить второе задание, когда первое успешно обработано, используйте опцию Start status-dependent. Тогда в случае прерывания первого задания второе переводится в состояние отмены и не выполняется.