□ 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. Тогда в случае прерывания первого задания второе переводится в состояние отмены и не выполняется.
Рис. 9.3. Время запуска для планирования фоновых заданий
Если задания с временем запуска After job (после задания), After event (после события) или At operation mode (при режиме работы) не могут запуститься из-за отсутствия доступных фоновых процессов при возникновении ожидаемого события, они помечаются для немедленного запуска и запускаются затем планировщиком заданий по времени, как только будет возможно.