уменьшить. С другой стороны, если задержка запуска задания не столь важна, лучше увеличить этот интервал времени, хотя уменьшение частоты запуска планировщика фоновых заданий мало влияет на производительность системы.
Сначала необходимо определить события, на которые должна реагировать система R/3. В стандартной системе R/3 уже определены многие виды событий. Для вывода списка этих событий можно использовать ►Event Maintenance. События, определенные для стандартной системы, называются
С помощью того же меню пользователь может определить свои собственные новые события. Подобные события называются
Инициировать событие можно следующими способами:
► Вручную с целью тестирования — с помощью ►Trigger Event
► Используя в программе АВАР в системе R/3 функциональный модуль BP_EVENT_RAISE
► Посредством внешней программы sapevt
Программа sapevt позволяет инициировать событие в системе R/3 из внешней программы. Эта программа доступна в стандартном каталоге SAP для исполнимых программ (см. главу 1). Вызывается она так:
□ sapevt <идентификатор события> [-р <параметр>] [-t] [pr = <профиль> name = <имя_системы R/3> nt = <номер_системы R/3>]
Параметр -t задает запись файла журнала
Например, вызов:
□ 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.
Нередко планирование фоновых заданий уже встроено в приложения; этот метод применяется при копировании клиента или при обновлении главной записи пользователя. В зависимости от приложения и предустановленных атрибутов вид экранов ввода данных задания может быть различным. Тем не менее, принципы и варианты фоновой обработки, описанные в данном разделе, применимы и в этом случае.
Определение фонового задания охватывает три основных области:
► Общую информацию, такую как имя задания, его класс и целевой сервер
► Информацию о времени запуска или инициирующем событии.
► Список шагов обработки
Общая информация составляет основу определения фонового задания (см. рис. 9.2). Следует выбрать такое имя задания, которое позволяет судить о его назначении, поскольку оно будет записываться во все журналы и выводиться на экран при анализе заданий. С технической точки зрения имя задания не принимается в расчет; оно не обязано быть уникальным.
Приоритет выполнения задания определяется присвоенным ему классом. Существуют следующие классы заданий:
► А: наивысший приоритет — задания, обеспечивающие функционирование R/3 и критические по времени
► В: средний приоритет — периодические задания, обеспечивающие функционирование R/3
► С: обычный приоритет — обычные задания для пользователей R/3
Класс задания используется для присвоения ему системных ресурсов. Если приходится часто обрабатывать большое число заданий класса C (это означает, что задания класса A и B должны ожидать освобождения фоновых процессов), то системный администратор может явным образом зарезервировать некоторое число n фоновых процессов для заданий класса А в ►Operation Mode Maintenance. Такая конфигурация гарантирует, что
В распределенной системе R/3 можно также указать инстанцию R/3 со службой фоновой обработки заданий. Эта инстанция R/3 называется
Для обработки запроса на определенном фоновом сервере выделены следующие приоритеты:
1. Задание класса A, целевой сервер задан
2. Задание класса A, целевой сервер не определен
3. Задание класса B, целевой сервер задан
4. Задание класса B, целевой сервер не определен
5. Задание класса C, целевой сервер задан
6. Задание класса C, целевой сервер не определен
Если ожидающие задания имеют равный приоритет согласно приведенным выше критериям, то используется время ожидания.
Если целевой сервер определен, то это значение связывается. Если целевой сервер недоступен, когда запускается задание, то фоновый процесс другой инстанции не может выполнить требуемую обработку.
