► Число пользователей на систему
► Число логических систем
► Частота изменений пользователей и полномочий
► Продолжительность разработки (и поэтому время, в течение которого разработчики требуются как пользователи систем)
► Конфигурирование административного пользователя в центральной системе
► Конфигурирование сценария ALE:
- Именование логических систем
- Присвоение логических систем клиентам
- Создание пользователей коммуникации (которые используются в интерфейсах RFC) во всех вовлеченных клиентах
- Создание интерфейсов RFC
- Создание новых представлений модели распределения ALE
- Поддержание и генерация профилей Partner между всеми клиентами, участвующими в CUA
- Распространение представлений модели
► Активация CUA
► Конфигурирование параметров распределения для полей
► Распространение адреса компании
► Синхронизация пользователей
Более подробно эти шаги описаны в следующих разделах.
8.7.1. Конфигурирование сценария ALE
Свойства и управление интегрированной системой ALE описаны в главе 13. Поэтому здесь описаны только настройки специфические для Центрального управления пользователей (CUA).
Сначала нужно сконфигурировать логические системы (см. главу 13), для всех клиентов, работающих с CUA. Затем используется ►Client Administration для присвоения логических систем клиентам. Одно соединение RFC должно быть задано для пересылки данных из центральной системы в каждую дочернюю систему и в противоположном направлении — необходимо иметь отдельные соединения RFC для каждого направления. Между дочерними системами не требуется никаких соединений. Клиент в месте расположения CUA также должен быть интегрирован как дочерняя система в центральное управление. Определяется новое представление модели для модели распространения ALE, чтобы указать, какие данные будут обмениваться между логическими системами. Для CUE это будут предопределенные бизнес-объекты USER и UserCompany с методом распространения Clone.
Затем генерируется партнерское соглашение и распространяется на все логические системы, что завершает конфигурирование ALE для центрального управления пользователями.
8.7.2. Активация и конфигурирование центрального управления пользователямиЧтобы активировать CUA, необходимо только присвоить CUA представление модели ALE. Для этого нужно ввести имя представления модели в ►Central Role Administration и нажать Create. На следующем экране следует ввести все дочерние системы для центрального управления и сохранить их. Теперь можно распространить модель с помощью меню с путем доступа Distribution Model • Distribute Distribution Model для распространения модели на дочерние системы. Центральное управление пользователями активно.
Основной аспект конфигурирования CUA включает определение места обслуживания атрибутов пользователей в различных системах, т.е. в центральной или в дочерней системе. Для определения, как будет обслуживаться каждый атрибут пользователя (см. рис. 8.22), можно использовать ►Distribution Parameters в Customizing.
Рис. 8.22. Определение параметров распространения
Администраторы могут использовать следующие параметры:
Таблица 8.6. Параметры для выбора полей
Параметр Обслуживание и синхронизация global Это поле может обслуживаться только в центральной системе. Изменения затем распространяются автоматически. local Данные обслуживаются только в дочерних системах и не распространяются на другие системы. proposal Поле с этим параметром обслуживается и распространяется со значением по умолчанию, когда создается пользователь. Дальнейшее обслуживание имеет место в дочерних системах. Последующие изменения не распространяются. retval Это значение может обслуживаться как центрально, так и локально. Когда данные изменяются локально, их можно послать назад на центральную систему и затем распространить на все дочерние системы. everywhere Значение может обслуживаться как центрально, так и локально. Центральные изменения распространяются на дочерние системы, но изменения в дочерних системах не возвращаются. Этот параметр доступен только для небольшого числа полей.
8.7.3. Удаление центрального управления пользователямиЧтобы удалить отдельные дочерние системы из центрального управления пользователями (CUA), нужно выполнить отчет RSDELCUA на соответствующих дочерних системах. Чтобы полностью прекратить деятельность всего CUA, следует выполнить отчет RSDELCUA на центральных системах. Это отменяет назначение модели распространения в CUA и деактивирует CUA.
Когда CUA полностью удалено, необходимо также выполнить следующие задачи по очистке:
► Удалить партнерское соглашение.
► Удалить модель распространения ALE.
► Удалить соединения RFC.
► Заблокировать пользователя коммуникации.
Если удаляется только одна дочерняя система, то нужно соответственно ограничить партнерское соглашение, модель ALE и интерфейсы RFC.
8.7.4. Управление пользователями в CUA
Во время начальной настройки CUA при добавлении новой дочерней системы сначала необходимо интегрировать всех существующих в дочерней системе пользователей в центральную систему. После выбора дочерних систем выводятся все пользователи каждой дочерней системы, разделенные по:
► New users
Эти пользователи существуют только в дочерней системе, но еще не в CUA. Во время переноса все параметры интегрируются в CUA.
► Identical users
Пользователь с таким же именем пользователя и реальным именем существует как в CUA, так и в дочерней системе. Пользователя можно либо скопировать из дочерней системы в CUA и перераспределить оттуда, либо удалить в дочерней системе и определение перераспределить из CUA.
► Different users
Одно и то же имя пользователя содержится как в CUA, так и в дочерней системе, но с другими реальными именами (реальное имя является комбинацией имени и фамилии). Необходимо решить, какой пользователь будет обслуживаться в дальнейшем. Может быть, желательно создать нового пользователя в CUA.
► Central users
Эти пользователи уже зарегистрированы в CUA идентичным образом и управляются централизованно.
Затем можно интегрировать пользователей в CUA по отдельности или всех сразу. В ходе этого процесса данные для всех пользователей за исключением New users всегда берутся и распространяются из центральной системы. Если два различных пользователя используются в действительности для Different users, то необходимо определить их снова в центральной системе и удалить идентично именованных пользователей в дочерней системе.
Для обслуживания пользователей продолжают использовать ►User maintenance (см. раздел 8.2.1), далее когда CUA активно. Однако пользователей нельзя больше создавать в дочерних системах, и готовы для ввода только те поля, которые могут обслуживаться локально согласно определению параметров распространения (см. раздел 8.7.2). В центральной системе появляется новая вкладка Systems в транзакции ►User maintenance. Эта вкладка используется для ввода систем, в которые вы хотите распространить пользователей. Данные пользователя можно определить только один раз, и они будут затем идентичны во всех дочерних системах. Каждой дочерней системе можно присвоить различные роли и профили.
8.8. Обзор: службы каталоговЧем больше систем SAP интегрируется в неоднородную системную инфраструктуру, тем в большей степени возрастает потребность в управлении пользователями. Большая часть данных пользователей требуется как в системах SAP, так и в других системах, и поэтому хранятся с избыточностью. Обслуживание этих избыточных данных требует много времени и не всегда синхронизировано.
LDAP
Службы каталогов делают возможным для различных приложений в структуре ИТ обращение к общим данным, которые управляются централизованно. Считайте службу каталогов «адресной книгой ИТ». Если служба каталогов поддерживает Стандартный легковесный протокол доступа к каталогам (LDAP), то можно использовать LDAP Connector для обмена данными со службой каталогов в Basis Release 6.10 и более поздних версиях. Следовательно, центральные данные пользователя должны сохраняться только один раз в центральной службе каталогов и могут синхронизироваться прямо с системой SAP или Центральным управлением пользователями с помощью функций синхронизации LDAP. Затем данные можно распределить на дочерние системы в CUA (включая данные более ранней версии Basis).
