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

1.4. Уровень приложений

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

? Служба диалога (D)

? Служба обновлений (Update, V)

? Служба обновлений V2 (Update2, V2)

? Служба управления блокировками (Enqueue, E)

? Служба фоновой обработки (Batch, В)

? Служба сообщений (М)

? Служба шлюза (G)

? Служба подкачки (Spool, S)

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

Имя инстанции содержит имя системы SAP R/3 и буквы, соответствующие службам. Центральная система SAP R/3 только с одной инстанцией, обеспечивающей все службы, будет иметь имя <SID>_DVEBMSG<номер инстанции>_<имя хоста>, где <SID> — это имя системы из трех букв, уникальное в каждой системной инфраструктуре, а <номер инстанции> — это последние две цифры порта TCP/IP, используемого для сетевого соединения. Однако этот метод именования является только соглашением об именовании — соглашением, которое не проверяется технически. При установке сервера диалога инстанция обычно устанавливается с именем <SID>_D<номер инстанции>_<имя хоста>, даже когда она предлагает дополнительные службы. Номер инстанции может находиться между 00 и 96: номера с 97 по 99 включительно зарезервированы для специальных целей.

Сервер сообщений

На уровне приложений для каждой инстанции есть один сервер сообщений. Эта служба предназначена для коммуникации между различными инстанциями системы SAP R/3. Сервер сообщений осуществляет мониторинг свободных ресурсов и их выделение в случае необходимости на уровне приложений. Инстанция, на которой работает сервер приложений, называется обычно центральной инстанцией системы SAP R/3. О задачах центральной инстанции см. ниже в данной главе. Все другие инстанции являются диалоговыми, даже если они предлагают дополнительные службы.

Процесс-планировщик и рабочие процессы

Рабочие процессы реализуют сервисы диалога, управления блокировками, обновления, фоновой обработки и службы вывода (спулинга). Координацию рабочих процессов осуществляют процессы-планировщики, функционирующие на каждой инстанции. Эти процессы распознают коммуникационные требования рабочих процессов и передают их соответствующим образом. Рабочие процессы и планировщик всегда включают одну и ту же программу, запускаемую с параметрами, которые зависят от каждой функции. В соответствии с требованиями приложения и доступными ресурсами администратор должен определить, какой конкретный процесс и сколько процессов будут реализовывать сервис для каждой инстанции. Планировщик запускает эти процессы и управляет ими. В случае отказа планировщика вся инстанция перестает функционировать. Планировщик играет роль интерфейса между уровнями презентаций и приложений. Все запросы с уровня презентаций (т. е. из SAP GUI) принимаются планировщиком и присваиваются доступным в данной инстанции рабочим процессам (см. рис. 1.8).

Рис. 1.8. Роль планировщика в инстанции SAP R/3

Если рассмотреть структуру рабочего процесса, то можно видеть, что он реализуется путем совместного выполнения обработчика задач, процессора обработки экранов, процессора АВАР и интерфейса SQL, которые используют специальные области основной памяти. Обработчик задач координирует операции в рабочих процессах. В зависимости от выполняемой задачи обработка передается процессору экранов, процессору АВАР (он отвечает за программы на АВАР — языке программирования SAP) или интерфейсу SQL для обмена данными с БД.

Служба диалога

Рабочие процессы различаются по своим задачам. Процессы диалога реализуют запросы активных пользовательских сеансов. Для выполнения необходимых внутренних процедур SAP R/3 каждая инстанция SAP R/3 должна иметь, по крайней мере, два процесса диалога. Планировщик не назначает процесс диалога только одному пользователю (SAP GUI). На самом деле планировщик инстанции назначает выполнение каждого шага диалога свободному процессу диалога. Данные пользователя, необходимые для выполняемой обработки (например, авторизации), сохраняются в контексте пользователя в оперативной памяти (в доступных для рабочих процессов областях). В системе R/3 шаг диалога рассматривается как обработка одного экрана. Процесс диалога обычно занят только во время обработки шага диалога одного пользователя. Этот механизм позволяет процессу диалога обслуживать нескольких пользователей.

Служба фоновой обработки

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

Служба обновления

Служба обновления вносит в БД изменения в асинхронном режиме. Она используется, когда изменения в данных не нужно вносить немедленно (синхронно). Пользователь системы SAP R/3 не влияет на применение службы обновления. Решение об использовании данной службы принимается на этапе разработки бизнес-приложения. Примером является ввод заказов. Каждый заказ должен вводиться быстро в диалоговом режиме (онлайн), однако фактическое обновление осуществляется в фоновом режиме с некоторой задержкой, и пользователю не нужно ждать, когда завершится транзакция. Для обработки асинхронных изменений данных в каждой инстанции системы R/3 должна быть, по крайней мере, одна служба обновления.

Служба обновления V2

По соображениям производительности служба обновления делится на подклассы. Для менее важных частей обновления существует отдельная служба обновления V2, которая может выполнять часть обновлений совместно. Настройка службы обновления V2 не является обязательной. Если этой службы нет, то служба обновлений продолжает решать ее задачи.

Служба вывода

Запросы вывода передаются службе вывода, часто называемой службой спула, которая временно сохраняет их в объектах TemSe (временный последовательный объект), пока они реально не выводятся. Администратор системы SAP R/3 должен решить, где следует хранить объекты TemSe: в БД с использованием механизмов защиты РСУБД или в файловой системе с помощью средств управления ОС.

В системе должен быть доступен, по крайней мере, один процесс спула. Каждая инстанция может иметь любое число таких процессов.

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

Служба блокировок

Управление блокировками занимает среди служб особое место. Аналогично серверу сообщений, эта служба действует в масштабе всей системы, т. е. обеспечивать данную службу для всей системы может только одна инстанция. Обычно для этого достаточно одного процесса. Если система работает с особенно большой нагрузкой, то допускаются несколько процессов службы блокировки, но они должны существовать в одной и той же инстанции, так как информация о блокировке хранится в основной памяти компьютера (память с общим доступом). Соответственно термин «сервер блокировок» (Enqueue Server) используется как синоним инстанции, которая обеспечивает такую службу и для самой службы.

Транзакция SAP R/3

Если это возможно, сервер блокировок (Enqueue Server) и сервер сообщений (Message Server) должны выполняться на одной инстанции, поскольку функционируют они в тесном «сотрудничестве». Сервер блокировок управляет логическими блокировками для транзакций SAP R/3. Такая транзакция состоит из последовательности функционально и логически согласованно связанных рабочих шагов. Обычно транзакция R/3 включает в себя несколько диалоговых шагов, которые могут выполняться различными процессами. С точки зрения БД каждый шаг диалога, составляющий физическую и логическую единицу, представляет собой транзакцию базы данных и закрывается после шага диалога. РСУБД может координировать только эти транзакции БД с помощью своих собственных процедур управления блокировками. С точки зрения системы SAP R/3 этого недостаточно, вся транзакция SAP R/3 должна выполняться или откатываться назад полностью. По данной причине в R/3 были введены логические единицы работы (LUW—Logical Units of Work). SAP R/3 придерживается принципов ACID (атомарность, непротиворечивость, изолированность, надежность) для логических единиц работы, как они определены для транзакций в РСУДБ. К логической единице работы применяются следующие правила:

? Атомарность (Atomic)

LUWs составляют элементарную единицу работы. LUW может выполняться только целиком.

? Непротиворечивость (Consistent)

LUW переводит непротиворечивую БД в новое непротиворечивое состояние, т. е. после выполнение LUW достигается корректное состояние.

? Изолированность (Isolated)

LUW выполняются независимо друг от друга. Они могут работать параллельно. Если несколько LUW пытаются работать с одними и теми же ресурсами, то они могут сделать это только при последовательном выполнении.

? Долговечность (Durable)

Результаты успешно выполненных LUW сохраняются и хранятся постоянно. Например, на результат не влияют возможные системные ошибки.

Для удовлетворения этих требований необходим сервер блокировок. Запросы блокировок, генерируемые в результате транзакций SAP R/3, передаются серверу сообщений, который, в свою очередь, передает их на выполнение серверу блокировок. Для снижения дополнительной нагрузки на сеть лучше размещать сервер сообщений и сервер блокировок на одной инстанции. Сервер блокировок работает с блокировками в специально выделенной области оперативной памяти. Таким образом, отказ сервера блокировок приводит к потере всех блокировок SAP R/3, а следовательно — к автоматическому откату (отмене) всех LUW, на которые они влияют. При таком отказе планировщик немедленно пытается запустить новый рабочий процесс сервера блокировок на этой инстанции.

Служба шлюза

Каждой инстанции SAP R/3 для выполнения задач вне локальной инстанции необходима также служба шлюза (Gateway Service). Она включает в себя:

? Коммуникации между разными системами SAP R/3

? Удаленный вызов функции (RFC — Remote Function Call)

? Интерфейс программирования коммуникаций (CPI-C — Common Programming Interface for Communications)

? Соединения с внешними системами, такими как серверы MAPI, системы электронного обмена данными EDI, внешние факсимильные устройства и службы телекса

Один процесс шлюза существует в каждой инстанции. Он активизируется автоматически при запуске инстанции. Помощь администратора в данном случае не нужна.

Таблица 1.2. Правила для типов и числа процессов SAP R/3 на уровне приложений

Сервер сообщений постоянно получает сведения о том, какие именно инстанции и службы доступны в данный момент. Это своего рода управляющий модуль системы. При отказе сервера сообщений система SAP R/3 функционировать не сможет. В каждой инстанции роль управляющего звена играет планировщик. При его отказе инстанция прекращает работу. В то же время, если отказывает рабочий процесс, планировщик может запустить новый. Каждый рабочий процесс способен выполнять любую задачу (они не являются специализированными). На основе заданных администратором SAP R/3 настроек планировщик определяет задачу для рабочего процесса. Для выполнения задач администратор должен знать, какие требования ему нужно задать в системе SAP R/3. Их необходимо определить на этапе технической реализации системы SAP R/3. На последующих стадиях решаются вопросы, относящиеся к расширению системы или совершенствованию уже созданной конфигурации.

Одна из основных обязанностей администратора системы R/3 — настройка производительности работы системы на уровне приложений. Он должен решить, какое число инстанций и процессов выполняется в системе, определить их тип, размер области памяти для каждой инстанции, а также другие устанавливаемые параметры и характеристики. Возможные параметры настройки системы SAP R/3, особенно на уровне приложений, могут быть очень сложными. В централизованных системах (т. е. когда уровень приложений состоит только из одной инстанции) нужно задать конфигурацию областей памяти и определить число процессов. Оперативная память используется для таких целей, как буферизация содержимого часто используемых таблиц, производственные календари, исполняемые объекты АВАР и контекст пользователя. В распределенных системах (т. е. при наличии в одной системе R/3 нескольких инстанций) инстанции могут определяться таким образом, чтобы обеспечивать только одну службу, например сервер обновления, сервер фонового выполнения или сервер спула. Обычно администратор выбирает конкретную конфигурацию инстанций, исходя из производительности или удобства управления системой (подробнее см. в главе 14).

Оглавление книги