Сигрид Хагеман - SAP R/3 Системное администрирование
- Название:SAP R/3 Системное администрирование
- Автор:
- Жанр:
- Издательство:Издательство Лори
- Год:2007
- Город:Москва
- ISBN:978-5-85582-272-4 (5-85582-272-9)
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Сигрид Хагеман - SAP R/3 Системное администрирование краткое содержание
Эта книга полностью обновлена и тщательно пересмотрена. Она является необходимым пособием для руководителей информационных служб, технических консультантов и системных администраторов R/3, которые хотят иметь полное представление об администрировании Basis.
Знания, полученные "из первых рук" от различных специалистов SAP Global Support, работавших над реализацией более 20000 систем R/3, служат основой этой книги, которая научит выполнять все критически важные задачи системного администрирования с оптимальной эффективностью. Она учит быстро принимать правильные решения в сложных ситуациях, используя рекомендации экспертов и ценные рекомендации из реального мира, которые делают это уникальное пособие необходимым для повседневного использования.
Кроме всего прочего, эта книга является ценным источником, помогающим подготовиться к экзамену СТС (Certified Technical Consultant) no R/3 Release 4.6C и Enterprise.
В руководстве рассмотрены:
# Настройка системной инфраструктуры.
# Администрирование клиента.
# Пользователи и полномочия.
# Фоновая обработка.
# Архивирование данных.
# Администрирование спула.
# Обслуживание инстанций.
# Системный мониторинг.
И многое другое.
SAP R/3 Системное администрирование - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Файлы анализа могут очень быстро увеличиваться в размере в зависимости от сконфигурированных критериев фильтра. Поэтом? необходимо регулярно делать резервные копии этих файлов, чтобы удалить их на уровне операционной системы.
В больших системных средах с множеством пользователей описанное выше локальное управление пользователями может требовать много времени Обслуживание одинаковых пользователей в различных системах и синхронизация изменении между системами, что означает, что администраторам необходимо регистрироваться на каждой локальной системе, может сделать обслуживание пользователей утомительным и подверженным ошибкам. К счастью здесь может помочь Центральное управление пользователями (CUA- Central User Administration). В Basis Release 4.6 и более поздних версиях можно выполнить все действия по обслуживанию пользователей на одном определенном клиенте одной системы, а затем распространить данные на других клиентов той же или других систем. Специальный клиент является отправителем (центральной системой), в то время как все остальные клиенты (дочерние системы) - получателями данных. Application Link Enabling (ALE, см. главу 13) является технологией, которая используется для обмена данными. Клиенты, которые обмениваются данными, конфигурируются и управляются как логические системы.
Преимущества
После конфигурирования CUA пользователи могут создаваться или удаляться только в центральной системе. Для каждого атрибута пользователя можно определить (в управлении CUA), будет ли этот атрибут обслуживаться только центрально, только локально или центрально и локально. Поэтому требуемые роли и полномочия должны существовать в активной форме во всех дочерних системах. В результате каждый пользователь должен обрабатываться только один раз, централизованно, что дает администраторам существенно более четкое представление обо всех пользователях и полномочиях.
Значение этих преимуществ CUA слегка снижается из-за возросших усилий, требуемых для конфигурирования сценария ALE и синхронизации существующих пользователей, а также дополнительными навыками, требуемыми от администратора. Следующие критерии помогут определить, имеет ли смысл конфигурировать CUA в структуре предприятия:
► Число пользователей на систему
► Число логических систем
► Частота изменений пользователей и полномочий
► Продолжительность разработки (и поэтому время, в течение которого разработчики требуются как пользователи систем)
► Конфигурирование административного пользователя в центральной системе
► Конфигурирование сценария ALE:
- Именование логических систем
- Присвоение логических систем клиентам
- Создание пользователей коммуникации (которые используются в интерфейсах RFC) во всех вовлеченных клиентах
- Создание интерфейсов RFC
- Создание новых представлений модели распределения ALE
- Поддержание и генерация профилей Partner между всеми клиентами, участвующими в CUA
- Распространение представлений модели
► Активация CUA
► Конфигурирование параметров распределения для полей
► Распространение адреса компании
► Синхронизация пользователей
Более подробно эти шаги описаны в следующих разделах.
Свойства и управление интегрированной системой ALE описаны в главе 13. Поэтому здесь описаны только настройки специфические для Центрального управления пользователей (CUA).
Сначала нужно сконфигурировать логические системы (см. главу 13), для всех клиентов, работающих с CUA. Затем используется ►Client Administrationдля присвоения логических систем клиентам. Одно соединение RFC должно быть задано для пересылки данных из центральной системы в каждую дочернюю систему и в противоположном направлении — необходимо иметь отдельные соединения RFC для каждого направления. Между дочерними системами не требуется никаких соединений. Клиент в месте расположения CUA также должен быть интегрирован как дочерняя система в центральное управление. Определяется новое представление модели для модели распространения ALE, чтобы указать, какие данные будут обмениваться между логическими системами. Для CUE это будут предопределенные бизнес-объекты USER и UserCompany с методом распространения Clone.
Затем генерируется партнерское соглашение и распространяется на все логические системы, что завершает конфигурирование ALE для центрального управления пользователями.
Чтобы активировать 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 | Значение может обслуживаться как центрально, так и локально. Центральные изменения распространяются на дочерние системы, но изменения в дочерних системах не возвращаются. Этот параметр доступен только для небольшого числа полей. |
Чтобы удалить отдельные дочерние системы из центрального управления пользователями (CUA), нужно выполнить отчет RSDELCUA на соответствующих дочерних системах. Чтобы полностью прекратить деятельность всего CUA, следует выполнить отчет RSDELCUA на центральных системах. Это отменяет назначение модели распространения в CUA и деактивирует CUA.
Читать дальшеИнтервал:
Закладка: