My knowledge base

среда, 11 июля 2012 г.

Немного про архитектуру 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.
Система управления переносами
Система управления переносами (TMSTransport 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 позволяет обмениваться данными со службой каталогов.

Комментариев нет:

Отправить комментарий