SAP R/3 Системное администрирование
Шрифт:
Системные события
Сначала необходимо определить события, на которые должна реагировать система R/3. В стандартной системе R/3 уже определены многие виды событий. Для вывода списка этих событий можно использовать ►Event Maintenance. События, определенные для стандартной системы, называются системными. Они часто используются для внутреннего управления R/3, но могут применяться и пользователями R/3 для своих целей.
Пользовательские
С помощью того же меню пользователь может определить свои собственные новые события. Подобные события называются пользовательскими. Для определения события нужно создать запись в таблице.
Инициация события (триггеры)
Инициировать событие можно следующими способами:
► Вручную с целью тестирования — с помощью ►Trigger Event
► Используя в программе АВАР в системе R/3 функциональный модуль BP_EVENT_RAISE
► Посредством внешней программы sapevt
Программа sapevt
Программа sapevt позволяет инициировать событие в системе R/3 из внешней программы. Эта программа доступна в стандартном каталоге SAP для исполнимых программ (см. главу 1). Вызывается она так:
Параметр -t задает запись файла журнала dev_evt в тот каталог, откуда вызывалась программа sapevt. Параметр -р можно использовать для указания модуля R/3, например F1. Это позволяет присваивать события прикладным областям. Это присваивание имеет только описательную природу и не обладает другими функциями.
Например, вызов:
инициирует событие 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. Такая конфигурация гарантирует, что п фоновых процессов всегда доступны для выполнения заданий класса А. Задания классов В и С должны ждать, пока число доступных фоновых процессов не будет равно как минимум п+1. Эта конфигурация описана в разделе 14.2.
Целевой сервер
В распределенной системе R/3 можно также указать инстанцию R/3 со службой фоновой обработки заданий. Эта инстанция R/3 называется целевым сервером в контексте фоновой обработки. Если инстанция не указывается, то во время выполнения R/3 выбирает первый доступный фоновый процесс в любой инстанции.
Для обработки запроса на определенном фоновом сервере выделены следующие приоритеты:
1. Задание класса A, целевой сервер задан