SAP 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.

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

9.2. Определение фоновых заданий

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

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

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

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

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

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

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

9.2.1 Общая информация

Общая информация составляет основу определения фонового задания (см. рис. 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, целевой сервер не определен

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

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