ГЛАВА 9

ФОНОВАЯ ОБРАБОТКА

Фоновая обработка

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

Чтобы пользователи не выполняли длительно выполняющиеся отчеты интерактивно (см. рис. 9.1), шаги диалогового режима имеют ограничение по времени выполнения. Это ограничение задано по умолчанию равным 600 сек. Обработка прекращается после завершения этого периода времени. Можно задать это ограничение в системном профиле (параметр rdisp/max_wprun_time). Фоновая обработка не имеет таких ограничений.

Рис. 9.1. Длительная задача в диалоговом режиме

Автоматическая обработка, требующая периодического выполнения определенных задач, является другим очевидным применением фоновой обработки. Для фоновой обработки в системе R/3 предусмотрена служба фонового выполнения с фоновыми рабочими процессами, которые называют просто фоновыми процессами. В отличие от диалоговой обработки, когда каждая логическая единица работы (LUW—Logical Unit of Work; см. главу 1)) присваивается следующему свободному процессу диалога, при фоновой обработке один процесс присваивается фоновому заданию на все время выполнения. Время запуска фонового задания определяет системный администратор или обычный пользователь. Задание можно запускать не только при наступлении указанного времени, но и по какому-то событию.

Планировщик фоновых заданий по времени

Для запуска задания в конкретное время нужно запланировать его выполнение. Каждая инстанция системы R/3, сконфигурированная для выполнения фоновых рабочих процессов, имеет активный планировщик заданий по времени. Через определенные интервалы времени он проверяет наличие фонового задания для обработки. Описания ожидающих заданий хранятся в центральных таблицах в базе данных. Планировщик — это программа АВАР, интерпретируемая и обрабатываемая заданным диалоговым процессом, который автоматически выбирается при запуске системы R/3. По умолчанию интервал активизации планировщика фоновых заданий составляет 60 сек. Администратор может его настроить, для чего в профиле инстанции устанавливается параметр rdisp/btctime. Таким образом, задание может запускаться с точностью до интервала активизации планировщика фоновых заданий. Если задержка слишком длительная, интервал можно уменьшить. С другой стороны, если задержка запуска задания не столь важна, лучше увеличить этот интервал времени, хотя уменьшение частоты запуска планировщика фоновых заданий мало влияет на производительность системы.

Планировщик фоновых заданий на основе событий

Планировщик на основе событий функционирует в системе R/3 на уровне приложений. Он запускает соответствующее фоновое задание в ответ на определенное событие. Планировщик заданий на основе событий также обрабатывается диалоговым рабочим процессом. Инстанцию для него можно выбрать с помощью параметра rdisp/btcname = <имя_сервера> в стандартном профиле системы R/3 (DEFAULT.PFL).

Системные события

Сначала необходимо определить события, на которые должна реагировать система R/3. В стандартной системе R/3 уже определены многие виды событий. Для вывода списка этих событий можно использовать ►Event Maintenance. События, определенные для стандартной системы, называются системными. Они часто используются для внутреннего управления R/3, но могут применяться и пользователями R/3 для своих целей.

Пользовательские события

С помощью того же меню пользователь может определить свои собственные новые события. Подобные события называются пользовательскими. Для определения события нужно создать запись в таблице.

Инициация события (триггеры)

Инициировать событие можно следующими способами:

► Вручную с целью тестирования — с помощью ►Trigger Event

► Используя в программе АВАР в системе R/3 функциональный модуль BP_EVENT_RAISE

► Посредством внешней программы sapevt

Программа sapevt

Программа sapevt позволяет инициировать событие в системе R/3 из внешней программы. Эта программа доступна в стандартном каталоге SAP для исполнимых программ (см. главу 1). Вызывается она так:

□ sapevt <идентификатор события> [-р <параметр>] [-t] [pr = <профиль> name = <имя_системы R/3> nt = <номер_системы 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.

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

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

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

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

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

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

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

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

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

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

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

Созданный программой АВАР вывод сохраняется как запрос спула в системе спула SAP. С помощью средства Spool List Recipient можно послать вывод пользователю. Эта техника позволяет, например, нескольким людям управлять фоновым заданием и анализировать его результаты. Поскольку вывод может быть достаточно большим, то рекомендуется использовать эту возможность с осторожностью. По соображениям производительности длина вывода, посылаемого в SAPoffice, ограничена 1000 строками. Значения параметров печати задаются при определении шага (см. раздел 9.2.3).

Следующий шаг состоит в выборе параметров, определяющих время запуска. Выберите на начальном экране определения задания условие Start. Можно назначить запуск задания на конкретное время или запускать его по событию (см. рис. 9.3). Используемая информация о времени и часовом поясе основывается на системном времени. Кроме определения времени запуска задания, планирование заданий по времени позволяет также планировать периодическое выполнение задания, например для регулярного анализа служебных заданий (см. раздел 9.6). Можно выбрать любой интервал повторения: через несколько минут, каждый час, ежедневно, еженедельно и т.д. Можно воспользоваться кнопкой Restrictions для определения исключений для обычного периода, например для указания дней отдыха в действующем производственном календаре. Когда используются задания, чувствительные ко времени, можно определить самое позднее возможное время для запуска задания (No start after).

Вместо определения управления по времени можно также определить некоторое событие в качестве триггера. В частности, изменения операционных режимов (см. главу 14) и конец задания определяются как события, что означает, что фоновое задание может также выполняться в зависимости от другого, уже определенного задания. В этом случае второе задание запускается после окончания первого. Если нужно запустить второе задание, когда первое успешно обработано, используйте опцию Start status-dependent. Тогда в случае прерывания первого задания второе переводится в состояние отмены и не выполняется.

Рис. 9.3. Время запуска для планирования фоновых заданий

Если задания с временем запуска After job (после задания), After event (после события) или At operation mode (при режиме работы) не могут запуститься из-за отсутствия доступных фоновых процессов при возникновении ожидаемого события, они помечаются для немедленного запуска и запускаются затем планировщиком заданий по времени, как только будет возможно.

Для завершения определения фонового задания следует описать шаги обработки, составляющие это задание. Шаг обработки представляет собой выполнение независимой программы, например АВАР или внешней программы. Фоновое задание может состоять из одного или более таких шагов обработки. Для определения шагов нужно выбрать в транзакции определения задания функцию 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) для планирования фонового выполнения заданий из программ заказчика.

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

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

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

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

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

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

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

► Ready (готово)

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

► Active (активно)

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

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

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

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

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

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

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

Для вывода журнала выполнения задания нужно дважды щелкнуть на нем мышью. В журнале задания регистрируется время его запуска и завершения, а также содержится ценная информация, позволяющая определить причину отмены задания. Журнал задания на рис. 9.8 был сгенерирован во время попытки извлечения данных. Согласно журналу, двойные записи в базе данных вызвали прекращение задания

Рис. 9.8. Журнал прерванного задания

Окно просмотра заданий объединяет все основные операции, используемые для фоновых заданий, включая:

► Вывод данных планирования

► Отмену заданий со статусом Active

► Удаление заданий со статусом Sched., Released, Finished или Canceled

► Отмену выпуска одного или нескольких заданий; статус задания изменяется на planned

► Сравнение нескольких заданий: устанавливаются общая информация задания, определение шага и требования для запуска

► Перемещение на другой сервер

► Прерывание активного задания, когда предполагаются проблемы (долго выполняющиеся задания): задание, которое выполняет в данный момент программу АВАР, можно остановить и проанализировать, с помощью отладчика АВАР. После выхода из отладчика программа продолжает выполняться нормально.

► Проверка статуса активных заданий (см. раздел 9.4)

► Копирование спланированных, выпущенных или законченных заданий; новое задание задается со статусом Sched.

Кроме этого списка, можно использовать графическое представление с аналогичными функциями, которое позволяет изменять и выпускать задания, а также проверять активные задания. Для вызова графического монитора заданий нужно использовать ►Job Monitor (см. рис. 9.9). Состояния заданий выделяются цветом.

Рис. 9.9. Монитор планирования заданий

Можно также выбрать ►Own Jobs или ►Job Definition • Own jobs для вывода обзора имеющихся собственных фоновых заданий.

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

Анализ времени выполнения

До версии R/3 Release 4.6D функция ►Performance Analysis выводила список всех выбранных фоновых заданий вместе с запланированным и реальным временем запуска и временем выполнения. Начиная с версии R/3 Release 4.6C, эта информация интегрирована в ►Simple Job Selection. Большие задержки между запланированным и реальным временем старта отмечают «узкое место» в доступных фоновых процессах, так как они указывают на задержку при получении заданием фонового процесса для выполнения. Если пользователю могут помешать «узкие места» производительности во время выполнения запланированных фоновых заданий, то администратор должен проверить ресурсы и при необходимости увеличить число фоновых процессов (параметр rdisp/wp_no_btc в профилях инстанций или в обслуживании профиля; см. главу 14).

Зомби

При запуске система R/3 проверяет наличие заданий со статусом ready или active, хотя они невозможны в этой ситуации. Все найденные подобные задания переводятся в состояние Sched. или canceled. Такие задания-зомби (zombies) могут создаваться при выключении сервера приложений до завершения выполнения задания, и статус может быть обновлен в базе данных.

Проверка статуса

Чтобы проверить, что выведенный статус действительно согласуется с реальным статусом (или существует несогласованность), можно выбрать критические задания в ►Simple Job Selection, а также Job status, чтобы найти все возможные несогласованности. При необходимости можно сбросить статус задания в Sched. или отменить сами задания.

Сигналы фоновой обработки

Некоторые параметры фоновой обработки были интегрированы в архитектуру мониторинга CCMS. Монитор Background Processing (Фоновая обработка) предоставляет информацию о средней нагрузке на фоновые рабочие процессы, специфическую для сервера и среднюю длину очереди ожидания для заданий со статусом Ready (которые не могут запуститься в связи с отсутствием фонового сервера), а также число прерванных заданий (см. рис. 9.10).

Список управляющих объектов

Чтобы обеспечить правильность работы управления фоновой обработкой, используйте ►Background Control Object Monitor. Эта транзакция позволяет проверить важные компоненты фоновой обработки, такие как планировщики заданий по времени и на основе событий, очистка от зомби, запуск внешних программ и переключение операционных режимов, и анализировать их с помощью вывода дополнительной трассировки.

Инструмент анализа фоновой обработки

Исчерпывающий анализ всех аспектов фоновой обработки можно выполнить с помощью ►Analysis of Background Processing. В частности, этот инструмент анализа позволяет находить и исправлять несогласованности в таблицах базы данных для управлениями заданиями. Следующий листинг содержит пример вывода этого инструмента:

Листинг 9.1. Вывод инструмента анализа

******************************************************

* Analysis tool for background processing

******************************************************

** Test: Determine all batch-capable servers

******************************************************

Рис. 9.10. Интеграция фоновой обработки в мониторинг сигналов

Рис. 9.11. Монитор элементов управления фоновой обработки

* Server name Host name

* psasb009_IE4_00 psasb009

******************************************************

* Test: Test TemSe functionality

******************************************************

* ==> TemSe check ran without errors

******************************************************

* Test: Check a user's batch authorizations

******************************************************

* User to check = D036044

* ==> Possesses the following authorizations:

* Batch administrator : Yes

* EarlyWatch: Yes

* Delete external jobs: Yes

* Display job logs: Yes

* Release jobs: Yes

* Display external jobs: Yes

******************************************************

* Test: Test environment for starting external programs

******************************************************

* ==> User SAPCPIC.not defined in client 002

* External programs cannot be started in this client!

* ==> User SAPCPIC not defined in client 066

* External programs cannot be started in this client!

******************************************************

* Test: Consistency check of database tables

******************************************************

* ==> No inconsistencies found!

* ==> All job contexts are consistent

******************************************************

* Test: Check profile parameters

******************************************************

* Server = psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 2:35:46 p.m.

******************************************************

* rdisp/btctime = 60

* rdisp/wp no btc = 6

* ==> Server is configured correctly for

* background processing ******************************************************

* Test: Check local host name against message server

******************************************************

* Server: psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 2:35:46 p.m.

******************************************************

* Local host name = psasb009

* ==> Local host name agrees with name on

* message server

******************************************************

* Test: Determine status of batch work processes

* on a server

******************************************************

* Server = psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 2:35:46 p.m.

******************************************************

* ==> Status of batch work processes:

* WP 1 : waiting

* WP 2 : waiting

* WP 3 : waiting

* WP 4 : waiting

* WP 5 : waiting

* WP 6 : waiting

* Number of reserved class A work processes: 0

******************************************************

* Test: Determine number of requests in batch queue

******************************************************

* Server = psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 14:35:46

******************************************************

* ==> Number of requests in batch queue = 0

******************************************************

Полномочия также используются для управления действиями, которые пользователь может выполнять при фоновой обработке. В таблице 9.1 перечислены наиболее важные из таких полномочий. Даже без каких-либо специальных полномочий все пользователи могут планировать, отменять, удалять и проверять статус своих собственных заданий. Специальные полномочия требуются для следующих действий:

► Манипуляции с запланированными заданиями других пользователей

► Вывода журнала задания

► Вывода запроса спулинга, сгенерированного фоновым заданием

► Выпуска задания для выполнения

► Использования внешней команды

Таблица 9.1. Полномочия для фоновой обработки

В отличие от диалогового режима никакие пароли во время фоновой обработки не проверяются. Соответствующие пользователи R/3 должны просто быть определены и не заблокированы в текущем клиенте.

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

Таблица 9.2. Важные служебные задания

Дополнительную информацию о свойствах и параметрах этих заданий можно найти в документации по отдельным программам. Это можно сделать в ►АВАР Editor. Введите имя программы и выберите Documentation • Display.

В версии R/3 Release 4.6C и более поздних можно спланировать все приведенные выше задания по отдельности или автоматически со стандартными параметрами с помощью ►Job Definition • Standard jobs.

Кроме заданий обслуживания, связанных с Basis, системную производительность можно также улучшить с помощью реорганизации, специфической для приложения. Одним из важных примеров является отчет SBAL_DELETE, который удаляет журнал приложения.

Интерфейс SAP BC-XBP позволяет интегрировать фоновые задания R/3 с внешними системами управления заданиями. Поддерживаются следующие функции:

► Определение заданий

► Изменение, редактирование или удаление заданий

► Запуск заданий

► Прекращение выполнения активных заданий

► Доступ к информации о задании (статус, файлы журналов и т.д.)

Чтобы вывести список продуктов, сертифицированных для этого интерфейса, посетите SAP Service Marketplace раздел с псевдонимом background.

► Определение заданий с целевым сервером

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

- Сервер приложений перемещается на другое оборудование (изменение имени сервера)

- Изменяется распределение рабочих процессов в определении операционных режимов

► Удаление заданий, которые больше не являются текущими и имеют статус Sched.

При выводе очереди текущих заданий в ►Simple Job Selection флажок Job Status: Planned обычно не отмечен; это означает, что администратор может не обращать внимания на ненужные задания с этим статусом. Другая обычная ошибка состоит в пренебрежении флажком Or after event, который означает, что включаемые событиями задания не выводятся.

► Планирование заданий не для базового пользователя

Когда планируются периодические задания, которые будут выполняться в течение длительного периода, имеет смысл присвоить отдельные шаги базовым фоновым пользователям. Это поможет избежать проблем в будущем, если пользователи, для которых спланированы задания, будут удалены.

► Минимальное число процессов

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

► Освобождение и перепланирование всех выпущенных заданий

Отчет BTCTRNS1 используется во время обновления в R/3 Release 4.5B и более поздних версиях. Он меняет статус всех заданий на статус, который планировщик заданий не распознает, чтобы предотвратить нежелательный запуск. После обновления используется отчет BTCTRNS2 для возврата заданий в их исходный статус. Конечно, эти функции можно использовать и для других целей.

► Перенос времени запуска отдельных управляемых по времени планировщиков заданий

Если используется несколько инстанций с фоновыми процессами, то может иметь смысл задать параметру rdisp/btctime различные значения в профилях инстанций, чтобы обеспечить лучшее распределение нагрузки.

► Проблемы с самопланирующимися периодическими заданиями с ограниченным временем запуска

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

АВАР Editor: SAP Menu • Tools • АВАР Workbench • Development АВАР Editor (SE38)

Analysis of background processing: SAP Menu • Tools • CCMS • Jobs • Check Environment (SM65)

Background control object monitor: SAP Menu • Tools • CCMS • Jobs • Background Objects (SM61)

Create external operating system commands: SAP Menu • Tools • CCMS • Configuration • External Commands (SM69)

Event maintenance: SAP Menu • Tools • CCMS • Jobs • Maintain Event (SM62)

Extended job selection: SAP Menu • Tools • CCMS • Jobs • Maintenance • Extended job selection (SM37C)

External operating system commands: SAP Menu • Tools • CCMS • Jobs • External Commands (SM49)

Job definition: SAP Menu • Tools • CCMS • Jobs • Definition (SM36)

Job monitor: SAP Menu • Tools • CCMS • Control/Monitoring • Job Scheduling Monitor (RZ01)

Operation mode maintenance: SAP Menu • Tools • CCMS • Configuration • Operation modes/Instances (RZ04)

Own jobs: System • Own jobs (SMX)

Performance analysis: SAP Menu • Tools • CCMS • Jobs • Performance analysis (SM39)

Simple job selection: SAP Menu • Tools • CCMS • Jobs • Maintenance (SM37)

Trigger event: SAP Menu • Tools • CCMS • Jobs • Trigger Event (SM64)

Быстрые ссылки

► SAP Service Marketplace, псевдоним background

Указания SAP Service Marketplace

Таблица 9.3. Указания SAP для пользовательской фоновой обработки

1. Какая транзакция используется для анализа журнала выполнения задания?

a. SE38

b. SM37

c. S000

2. Какая внешняя программа используется для инициации событий в системе R/3?

a. sapevt

b. sapxpg

c. sapstart

d. spmon

3. Что означает состояние фонового задания Ready?

a. Планирование задания завершено и сохранено

b. Задание выполнено, и можно распечатать журнал

c. Задание может быть запущено и ожидает системных ресурсов