Немного про архитектуру SAP

Выжимка из книжки про SAP

Архитектура

Система SAP. Обычно используется трехуровневая архитектура системы SAP: презентация, приложение, база данных. Только трехзвенная технология позволяет распределить уровень приложения на несколько инстанций, которые могут выполняться на нескольких серверах.

Уровень презентации: SAP GUI – выполняется на ОС клиента.

Уровень приложения: сервисы по обработке данных, чтение-запись в БД.

Уровень базы данных: хранение данных в таблицах СУБД. База данных может быть установлена на одном сервере или быть распределенной.

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

Подробности организации уровней системы SAP

Уровень презентаций. Это SAP GUI.

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

a.       служба диалога (D), (система:  >= 2; инстанция: >= 2)

b.      служба сообщений (M), (система: 1; инстанция: 0 или 1)

c.       служба шлюза (G), (система:  >= 1; инстанция: 1)

d.      служба управления блокировками (E), (система:  1; инстанция:  0 или 1)

e.      служба фоновой обработки (B), (система:  >= 1; инстанция: >= 0)

f.        служба вывода (S), (система:  >= 1; инстанция: >= 0)

g.       служба обновления (V), (система:  >= 1; инстанция: >= 0)

h.      служба обновления V2 (V2 – для менее важных обновлений).

В рамках одной инстанции SAP работает как минимум 2 процесса диалога. Инстанция, на которой  работает процесс сообщений, называется центральной инстанцией системы SAP R/3, а остальные диалоговыми. На каждой инстанции работают процессы планировщики , координирующие работу рабочих процессов. Все запросы уровня презентации принимает планировщик и распределяет между рабочими процессами инстанции.  Также на каждой инстанции работают службы обновления и вывода. Служба сообщений выполняется на одном сервере и служит для коммуникации между другими инстанциями. В каждой инстанции есть служба шлюза для коммуникации между разными системами SAP, RFC (Remote Function Call), соединения с внешними системами.

Служба блокировок обычно одна для системы SAP.

Принципы наименования.

Имя базы данных определяет имя всей системы SAP и должно состоять из трёх символов (можно использовать буквы и цифры). Первая буква должна быть заглавной.

 В зависимости от  выполняемых служб изменяется наименование инстанции <SID>_DVEBMSG<номер инстанции>_<имя хоста>, где  <SID> - это уникальное имя системы из 3-х букв.  <номер инстанции> - это последние 2 цифры порта TCP/IP, используемого для соединения.  

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

Транзакция SAP включает в себя более широкое понятие, чем транзакция СУБД.  Единицей транзакции является LUW (Logical Units of Work), которая обеспечивает ACID (Атомарность, непротиворечивость, изолированность, долговечность). Обеспечивается за счёт сервиса блокировок.

СУБД

Административные данные и данные приложения хранятся в таблицах СУБД. Несколько таблиц (видны только SAP)могут формироваться в одну таблицу СУБД (называется пулом таблиц). Есть аналогичная группировка таблиц SAP: таблицы кластера, образующие кластер таблиц. Возможно использовать СУБД: SAP DB, DB2, Informix, Oracle.

ОС

Файлы SAP хранятся в каталогу  \usr\sap. Ниже идут каталоги с названием системы, затем каталог с именем инстанции и каталог SYS. В SYS находятся профили инстанции, журналы системы  и выполняемые программы. В папке /usr/sap/<SID>/<instance_name>/log находятся журналы инстанции.

Пользователи

Для UNIX создаются пользователи <sid>adm и <типСУБД><sid>. Для Windows: <sid>adm. Процессы выполняются под пользователем SAPService<SID>. В СУБД пользователь SAPR3, который является владельцем всех таблиц.

Управление системой SAP

Запуск системы.

При запуске ОС запускается программа saposcol (os collector). Сначала запускается СУБД, затем сервер сообщений и блокировок. А уже потом остальные процессы инстанций. В Windows запустить (и управлять) систему SAP можно через специальную оснастку MMC. В UNIX  -  через пакетный файл startsap. При запуске системы создаются журналы startdb.log и startsap_имяхоста_имяинстанции.log. Управление запуском осуществляется в соответствии с настройками  в профилях: default.pfl (системный), start_инстанцияномеринстанции_имяхоста (стартовый), <sid>_инстанцияномер_имяхост (профиль инстанции).  Приоритет: 1. профиль инстанции,  2.системный, 3. системные умолчания.

Запуск клиента

Пиктограмма – это: sapgui /H/имяхоста/S/sapdp<номеринстанции>.  SAPLOGON сохраняет настройки подключения в saplogon.ini, sapmsg.ini, saproute.ini.

Для мониторинга состояния системы надо выбрать команду System->Status.  После выбора инстанции можно перейти к обзору настроек через меню Goto.

      SAProuter – шлюз уровня приложения. Настройки – в saprouttab (текстовый файл). Соединение задается с помощью строки вида: /H/<хост>/<ipaddress>/S/<служба/номерпорта>/W/пароль

sapgui  <строка подключения SAProuter><строка подключения к инстанции>. Служба и порт указываются опционально. Порт по умолчанию: 3299.

Инструменты поддержки

OSS (подключение через SAP GUI) и SAP Service Marketplace. SAP Solution Manager – приложение mySAP для управления и обслуживания.

Принципы инсталляции

Для минимальной инсталляции требуется СУБД и центральная инстанция, которые могут располагаться на одном сервере.

При установке требуется указать SID, номер инстанции, имя хоста и др.

Лицензионный ключ хранится в СУБД. Получит ключ можно через SAP Marketplace. Управление лицензиями – через команду saplicense.

Для начала работы надо скопировать клиент 000 или 001.

При настройке SAP GUI надо указать сервер приложения (имя или ip) и номер системы. Опционально: saprouter или SNC.

Система управления переносами

Система управления переносами (TMS – Transport Management System) реализует центральное административное представление настроек и переносов в SAP.

Обычно используется 3 системы SAP: Система интеграции (разработка), Система консолидации (тестирование в среде аналогичной производственной) и Производственная система.

Для централизованного управления свойствами переноса системы должны принадлежать одному домену переноса и управляться контроллером транспортного домена (TDC).

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

Системы SAP с общим каталогом переноса объединятся в транспортную группу. Их может быть несколько в одном домене переноса.

Уровень переноса (между разработкой и консолидацией),  путь поставки – из консолидации в другую систему.

На уровне ОС для управления переносами используется программа tp.

Изменения в объектах должны регистрироваться в SAP для тех. поддержки.

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

Если изменение касается SAP object, т.е. касается всей системы SAP, то создается запрос к инструментальным средствам (репозитарий объектов).

На время разработки объект блокируется для пользователей, не являющихся владельцами задачи и запроса на изменение.

Клиенты

Клиент – это независимо учитываемая бизнес-единица компании (HR, MM, финансы). Содержит зависимые пользовательские настройки, т.е. свои собственные данные приложения  

Данные клиента хранятся в специальных таблицах СУБД с полем MANDT. После входа в систему можно получить доступ только к указанному клиенту.

Стандартные клиенты: 000  - для целей администрирования, 001 – тестирование, 066 – для удаленной поддержки службами SAP.

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

Рекомендуется  создавать по три клиента (стандарт – 000, тест – xxx, рабочий - xxx) в каждой 3-х уровневой системе (разработки, тестирования, производства).

При переносе можно выбрать переносимые данные: все, users, данные приложения и т.д.

Есть локальное, удаленное копирование (идентичные настройки) клиента и перенос клиента (без данных, только настройки; данные можно потом импортировать, можно использовать утилиту tp).

Пользователи

Пользователь – технический идентификатор, с помощью которого выполняется некоторое действие.  Свойства учётной записи сохраняются в главной записи пользователя (user master record).

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

Полномочия – наиболее важная часть свойств пользователя. Присваиваются как профили (не путать с профилями запуска системы).

Пользователи всегда зависят от клиента.

Типы пользователей: Dialog (может работать произвольным образом), Communication (для бездиалоговой коммуникации между системами, напр., RFC ), System(для бездиалоговой коммуникации в системе или для фоновой обработке), Service(диалоговый пользователь, не имеет окончания срока пароля – применять с осторожностью), Reference (используется в качестве ссылки на полномочия, напр., одинаковые полномочия для пользователей Интернет).

Группа пользователей – позволяет координировать полномочия и свойства пользователей.

Для задания свойств по умолчанию можно использовать вкладку Defaults.

Защита логина и пароля.  Первые 3 символа имени пользователя не равны идентификатору пользователя. Пароль не может совпадать с PASS или SAP*. Пользователи могут менять свои только раз  в день.

Стандартные пользователи со стандартными паролями: SAP* и DDIC (клиенты 000 и 001), EARLYWATCH (066). НАДО МЕНЯТЬ ПАРОЛЬ ПРИ ПЕРВОМ ВХОДЕ.

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

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

Каждое полномочие основано на объекте полномочий: модуль, содержащий имя, поля полномочий. Все действия, которые явно не разрешены – запрещены.

Полномочия можно сгруппировать в профили полномочий, а несколько профилей полномочий – в один составной профиль.

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

Роль содержит: имя, описание, операции роли, профили полномочий, пользователи с этой ролью, индивидуальные данные.

Role maintenance – управление ролямиВ меню настройки при выборе для роли разрешенных операций автоматически генерируется дерево этих операций, которыми можно управлять.

Вся деятельность пользователя регистрируется в журнале аудита безопасности.

Центральное управление пользователями (CUA) позволяет управлять пользователями на разных системах с помощью Application Link Enabling/

LDAP Connector позволяет обмениваться данными со службой каталогов.