Внешние команды

Чтобы иметь возможность выполнять внешние программы ограниченным образом, используя внутренний механизм авторизации 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) для планирования фонового выполнения заданий из программ заказчика.

Для анализа и мониторинга фоновых заданий используется ►Simple Job Selection или ►Extended job selection. Задания можно фильтровать по различным критериям, таким как пользователь, период времени, событие и состояние задания (см. рис. 9.6), а полномочия позволяют еще более сузить выбор. Если имеются полномочия администратора для фоновой обработки, то можно вывести задания в любых клиентах при выборе дополнительных заданий. Если нет, то задания можно вывести только в клиенте регистрации.

На основе заданного критерия генерируется список фоновых заданий (см. рис. 9.7).

Каждое задание может иметь одно из следующих состояний:

► Sched. (запланировано)

Сохранены определения шагов задания; время запуска пока еще не определено.

► Released (разблокировано)

Задание спланировано, и время запуска задано явно, или задание ожидает событие.

► Ready (готово)

Время запуска достигнуто, или произошло ожидаемое событие; задание ожидает системные ресурсы для начала выполнения.

► Active (активно)

Задание обрабатывается в данный момент.

► Finished (закончено)

Задание успешно завершено.

Рис. 9.6. Простой выбор задания

Рис. 9.7. Список фоновых заданий

► Canceled (отменено)