Транзакция 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 на уровне приложений
| Служба | В масштабе системы R/3 | Для каждой инстанции R/3 |
| Диалог (Dialog) | >=2 | >=2 |
| Обновление (Update) | >=1 | >=0 |
| Блокировка (Enqueue) | 1 | 0 или 1 |
| Фоновое выполнение (Batch) | >=1 | >=0 |
| Сообщения (Message) | 1 | 0 или 1 |
| Шлюз (Gateway) | >=1 | 1 |
| Спул (Spool) | >=1 | >=0 |
Сервер сообщений постоянно получает сведения о том, какие именно инстанции и службы доступны в данный момент. Это своего рода управляющий модуль системы. При отказе сервера сообщений система SAP R/3 функционировать не сможет. В каждой инстанции роль управляющего звена играет планировщик. При его отказе инстанция прекращает работу. В то же время, если отказывает рабочий процесс, планировщик может запустить новый. Каждый рабочий процесс способен выполнять любую задачу (они не являются специализированными). На основе заданных администратором SAP R/3 настроек планировщик определяет задачу для рабочего процесса. Для выполнения задач администратор должен знать, какие требования ему нужно задать в системе SAP R/3. Их необходимо определить на этапе технической реализации системы SAP R/3. На последующих стадиях решаются вопросы, относящиеся к расширению системы или совершенствованию уже созданной конфигурации.
Одна из основных обязанностей администратора системы R/3 — настройка производительности работы системы на уровне приложений. Он должен решить, какое число инстанций и процессов выполняется в системе, определить их тип, размер области памяти для каждой инстанции, а также другие устанавливаемые параметры и характеристики. Возможные параметры настройки системы SAP R/3, особенно на уровне приложений, могут быть очень сложными. В централизованных системах (т. е. когда уровень приложений состоит только из одной инстанции) нужно задать конфигурацию областей памяти и определить число процессов. Оперативная память используется для таких целей, как буферизация содержимого часто используемых таблиц, производственные календари, исполняемые объекты АВАР и контекст пользователя. В распределенных системах (т. е. при наличии в одной системе R/3 нескольких инстанций) инстанции могут определяться таким образом, чтобы обеспечивать только одну службу, например сервер обновления, сервер фонового выполнения или сервер спула. Обычно администратор выбирает конкретную конфигурацию инстанций, исходя из производительности или удобства управления системой (подробнее см. в главе 14).
Уровень базы данных в системе SAP R/3 реализуется на центральном компьютере с использованием центральной РСУБД. В данном разделе уровень БД в системе SAP R/3 рассматривается подробнее. Здесь поясняется, как используется РСУБД для целей R/3 и с какими работами по администрированию это связано.