Вместо определения управления по времени можно также определить некоторое событие в качестве триггера. В частности, изменения операционных режимов (см. главу 14) и конец задания определяются как события, что означает, что фоновое задание может также выполняться в зависимости от другого, уже определенного задания. В этом случае второе задание запускается после окончания первого. Если нужно запустить второе задание, когда первое успешно обработано, используйте опцию Start status-dependent. Тогда в случае прерывания первого задания второе переводится в состояние отмены и не выполняется.
Рис. 9.3. Время запуска для планирования фоновых заданий
Если задания с временем запуска After job (после задания), After event (после события) или At operation mode (при режиме работы) не могут запуститься из-за отсутствия доступных фоновых процессов при возникновении ожидаемого события, они помечаются для немедленного запуска и запускаются затем планировщиком заданий по времени, как только будет возможно.
9.2.3. Шаги обработкиДля завершения определения фонового задания следует описать шаги обработки, составляющие это задание. Шаг обработки представляет собой выполнение независимой программы, например АВАР или внешней программы. Фоновое задание может состоять из одного или более таких шагов обработки. Для определения шагов нужно выбрать в транзакции определения задания функцию Step (см. рис. 9.2). Каждый шаг обработки не обязательно должен выполняться пользователем, назначенным планировщиком. Для назначенного пользователя всегда выполняется проверка полномочий. Таким образом, можно предоставить полномочия и ответственность для планирования задания и для анализа результатов его выполнения разным группам пользователей. Например, явное назначение пользователей упрощает последующий анализ результатов фонового задания, поскольку в этом случае можно назначить генерируемые списки этим пользователям. С данной целью удобно определить пользователей фоновых заданий (см. главу 8).
Шаги обработки могут включать в себя также программы АВАР, внешние команды или программы (см. рис. 9.4).
Программы АВАР
Все недиалоговые программы АВАР можно выполнять в фоновом режиме. Для этого нужно выбрать функцию АВАР Program (см. рис. 9.4), ввести имя программы АВАР и при необходимости указать язык, на котором будет генерироваться журнал. Многие программы АВАР (например, программа RSPFPAR) управляются с помощью переменных. Перед выполнением такой программы можно ограничить диапазон выводимых на экран имен параметров инстанции. Для выполнения подобного типа программ в фоновом режиме нужно создать для программы варианты (variants). Вариант является фиксированным набором значений для переменных программы, который сохраняется под именем варианта. Варианты определяют в ►АВАР Editor с помощью Goto • Variants. Необходимо также ввести имя варианта и требуемые значения параметров. Определенный таким образом вариант программы АВАР можно планировать для фонового выполнения. На рис. 9.4 показано планирование выполнения программы АВАР RSPFPAR, вариант которой называется ALL. Он был создан для генерации списка определенных на данный момент параметров инстанции. Для управления печатью данного списка нужно выбрать Print Specifications.
Рис. 9.4. Определение шага
Внешние программы
Пользователи R/3 с полномочиями администратора могут выбрать External Program для выполнения любых программ на уровне операционной системы из системы R/3. В этом случае требуется имя целевого сервера; параметры являются необязательными. Для выполнения программы на целевом сервере запускается процедура SAPXPG, которая осуществляет коммуникацию вызывающей системой R/3 через RFC, используя идентификатор специального пользователя R/3 SAPCPIC (см. главу 8).
Внешние команды
Чтобы иметь возможность выполнять внешние программы ограниченным образом, используя внутренний механизм авторизации R/3, конфигурируются расширенные внешние команды. Внешняя команда состоит из имени и назначенной внешней программы вместе с возможными значениями параметров, которые могут изменяться в зависимости от операционной системы. Прежде чем внешние команды можно будет использовать в фоновой обработке, необходимо определить их с помощью ►Create External Operating System Commands (см. рис. 9.5).
Рис. 9.5. Создание внешней команды
Стандартная система R/3 уже содержит многие внешние команды. Системные администраторы могут определить любую другую команду в пространстве имен заказчика. На рис. 9.5 показан пример команды ZLIST, за которой «скрывается» команда ls с параметром -lisa, выводящая на экран содержимое текущего каталога в системах UNIX.
Для систем Windows NT можно задать внешнюю команду с тем же именем для соответствующей команды dir. Определенная таким образом команда может использоваться и при создании фоновых заданий, и в CCMS (Computing Center Management System). Для этого нужно запустить ►External Operating System Commands, выбрать требуемую команду и затем Edit Execute.
Можно определить модуль проверки, чтобы еще больше ограничить использование внешней команды по соображениям безопасности. Модуль проверки выполняется перед запуском команды. В зависимости от результата выполнения проверки команда либо выполняется, либо нет. Процедура SPXG_DUMMY_COMMAND_CHECK является модельным примером в системе, который можно использовать в качестве шаблона для собственных проверок.
При определении шага фонового задания подлежащая выполнению внешняя команда определяется по ее имени (например, ZLIST) и операционной системе (например, UNIX). При необходимости задаются также дополнительные параметры, кроме тех, что уже определены. Всегда необходимо определять целевой сервер, как и для внешних программ.
Если в списке шагов фонового задания используются внешние команды или внешние программы, то можно использовать параметр Control flags в определении шага для указания, должны ли записываться в журнале задания шага вывод и сообщения об ошибках операционной системы и требуется ли синхронная или асинхронная обработка для улучшения интеграции.
Определив общую информацию, время запуска и каждый шаг фонового задания, нужно сохранить определение задания.
Мастер заданий
Все описанные записи можно создать также последовательно с помощью Job Wizard (Мастер заданий). Мастера заданий можно вызвать прямо из ►Job Definition.
API
Кроме метода, предусматривающего использование меню, в системе R/3 предлагается интерфейс прикладного программирования (API, Application Programming Interface) для планирования фонового выполнения заданий из программ заказчика.
9.3. АнализДля анализа и мониторинга фоновых заданий используется ►Simple Job Selection или ►Extended job selection. Задания можно фильтровать по различным критериям, таким как пользователь, период времени, событие и состояние задания (см. рис. 9.6), а полномочия позволяют еще более сузить выбор. Если имеются полномочия администратора для фоновой обработки, то можно вывести задания в любых клиентах при выборе дополнительных заданий. Если нет, то задания можно вывести только в клиенте регистрации.
На основе заданного критерия генерируется список фоновых заданий (см. рис. 9.7).
Каждое задание может иметь одно из следующих состояний:
► Sched. (запланировано)
Сохранены определения шагов задания; время запуска пока еще не определено.
► Released (разблокировано)
Задание спланировано, и время запуска задано явно, или задание ожидает событие.
► Ready (готово)
Время запуска достигнуто, или произошло ожидаемое событие; задание ожидает системные ресурсы для начала выполнения.
► Active (активно)
Задание обрабатывается в данный момент.
► Finished (закончено)
Задание успешно завершено.
Рис. 9.6. Простой выбор задания
Рис. 9.7. Список фоновых заданий
► Canceled (отменено)
При обработке возникла проблема, и задание отменено. Задание не было завершено успешно.
Для вывода журнала выполнения задания нужно дважды щелкнуть на нем мышью. В журнале задания регистрируется время его запуска и завершения, а также содержится ценная информация, позволяющая определить причину отмены задания. Журнал задания на рис. 9.8 был сгенерирован во время попытки извлечения данных. Согласно журналу, двойные записи в базе данных вызвали прекращение задания
