SAP R/3 Системное администрирование - Сигрид Хагеман

Примечание

В процессе обычной работы R/3 администратора непосредственно касаются три вопроса, связанных с обновлением:

1. Активен ли сервис обновления?

2. Были ли прерывания обновления?

3. Насколько велика очередь ожидающих запросов обновления?

Мониторинг операций обновления — это одна из повседневных задач системного администратора.

10.4. Советы

► Обзор всех открытых обновлений

Чтобы получить начальный обзор при запуске SM13, необходимо ввести «*» для пользователя и клиента и выбрать дату перед установкой системы. В противном случае при настройках по умолчанию будет показан только список собственных записей обновления пользователя в текущем клиенте от текущей даты.

► Удаление блокированных записей

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

10.5. Транзакции и пути доступа меню

Lock entries: SAP Menu • Tools • Administration • Monitor • Lock Entries (SM12)

System log: SAP Menu • Info • System Log (SM21)

Update program administration: не существует записи в стандартном меню SAP (SM14)

Update records: SAP Menu • Tools • Administration • Monitor • Update (SM13)

10.6. Дополнительная документация

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

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

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

Указания SAP Service Marketplace

Таблица 10.2. Указания SAP для системы обновления

Содержание Указание V3 update, questions, and answers 396647 Update groups for asynchronous updates 109515 10.7. Контрольные вопросы

1. Обновление было деактивировано в связи с переполнением табличного пространства. Какие требуются действия после расширения табличного пространства?

a. Никакие действия не требуются; служба обновления реактивируется автоматически.

b. Необходимо активировать службу обновления.

c. Необходимо разместить все записи обновления вручную.

2. Какое состояние имеет запись обновления в случае ожидания?

a. Active

b. Released

c. Init

d. Start

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

a. rdisp/vbmail

b. Сообщение передается пользователю в любом случае

c. rdisp/rbdelete

ГЛАВА 11

КОНФИГУРАЦИЯ И АДМИНИСТРИРОВАНИЕ ВЫВОДА

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

Запросы печати, созданные в системе SAP R/3, преобразуются в зависящий от устройства поток данных и выводятся через базовую систему спула. Чтобы реализовать эту функцию, система SAP R/3 должна быть осведомлена о свойствах различных устройств. Кроме определения устройств вывода на уровне операционной системы, спецификация этих устройств всегда требуется в системе SAP R/3.

11.1. Основы вывода

Многочисленные требования вывода создаются процессами диалога и фоновой обработки: необходимо распечатать список или результаты расчетов либо отправить факс. В диалоговом приложении пользователи печатают требуемые данные, определяя (или нет) устройство вывода в системе SAP R/3 (см. рис. 11.1). Пользователи могут также определить принтер, когда они определяют фоновый запрос.

Спул и запрос вывода

Диалоговый или фоновый процесс выполняют затем запрос вывода. Активный рабочий процесс создает сначала запрос спула из записей пользователя. Затем он сохраняет необработанные данные, предназначенные для вывода в TemSe (сокр. от temporary sequential object— временный последовательный объект) в базе данных или на уровне файловой системы (см. раздел 11.4). Описание запроса сохраняется в базе данных SAP R/3. Если запрос спула должен затем распечатываться, то рабочий процесс спула, присвоенный выбранному устройству вывода, выполняет форматирование данных в печатную форму и направляет их спулеру операционной системы, который отвечает за устройство вывода. Таким образом, рабочий процесс спула создает запрос вывода.

Рис. 11.1. Запрос вывода в диалоговом режиме (SAP R/3 Release 4.6D)

Каждый вывод происходит в два этапа:

1. Генерирование запроса спула — информация запроса (автор, число копий и дата запроса) сохраняется в базе данных; не зависимые от устройства данные печати хранятся в TemSe.

2. Генерирование и обработка запроса вывода из запроса спула — если устройство вывода было определено и готово получить данные.

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

Рис. 11.2. Поток данных во время печати

Если менеджер печати спула хоста не может обратиться к устройству вывода на уровне операционной системы, то печать из системы SAP R/3 происходить не может.

11.2. Конфигурирование рабочих процессов спула

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

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

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

► Поскольку не все серверы, на которых выполняются инстанции SAP R/3, могут иметь доступ ко всем используемым в операционной системе принтерам, то отказ инстанции может означать невозможность получения доступа к устройству вывода.

► Рабочие процессы спула отвечают за форматирование запросов печати, пересылку запросов системе спула хоста и за другие административные задачи:

- Реорганизацию системы спула (удаление устаревших запросов)

- Перенаправление запросов при отказе сервера

- Поиск необработанных запросов

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

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

Управление запросами

Рабочие процессы спула инстанции составляют одно целое, к ним нельзя обращаться по отдельности. Поэтому устройства вывода присваивают инстанции, а не определенному рабочему процессу (см. раздел 11.4). Каждая инстанция со службами спула управляет своими входящими запросами вывода в своей собственной очереди запросов спула как объектами в основной памяти. Если возникают перегрузка и переполнение очереди запросов спула, то в качестве коллектора входящих запросов используется очередь диспетчера, чтобы ни один запрос спула не был потерян. Когда очередь запросов спула сможет вместить все запросы вывода, рабочие процессы спула смогут снова перенести запросы из очереди диспетчера в очередь запросов спула. Обработка запросов спула продолжится только тогда, когда очередь диспетчера будет пустой или очередь запросов спула полностью заполненной.

Последовательная обработка

Сконфигурированные рабочие процессы спула могут обрабатывать запросы в инстанции последовательно, а иногда параллельно. Поэтому нет гарантии, что запросы вывода будут обработаны в том же порядке, в котором они были введены, если есть несколько рабочих процессов спула, выполняемых в инстанции. Некоторые запросы могут быть обработаны не в том порядке. При необходимости можно при создании устройства активировать параметр, чтобы обеспечить последовательную обработку запросов в том порядке, в котором они создаются. В этом случае рабочий процесс спула всегда обрабатывает все запросы для этого устройства в очереди спула, прежде чем принимает другие запросы. Однако в здесь ограничивается параллелизм между несколькими рабочими процессами спула, поэтому необходимо использовать этот параметр только тогда, когда это действительно необходимо (см. раздел 11.4).