Наиболее важными пространствами и разделами имен являются:
► Пространство имен заказчика
Все объекты без префикса, имена которых начинаются с Y или Z.
► Общее пространство имен SAP
Все объекты без префикса, имена которых не начинаются на Y или Z.
► Инструменты АВАР и GUI: префикс /1ВСАВА/
Допускается обработка объектов SAP только с помощью АВАР Editor, Screen Painter, и Menu Painter. Модификации функций не допускаются.
► Инструментальные средства разработки: префикс /1BCDWB/
Включает обработку объектов SAP с помощью всех инструментов в Development Workbench (АВАР Editor, Screen Painter, и Menu Painter) и модификации объектов репозитория (Repository). Модификации функций недопустимы.
► Группы функций блокировки: префикс /1BCDBWEN/
Включает функции SAP, которые обслуживают управление блокировками в SAP R/3. Если желательно задать параметр изменения системы таким образом, чтобы можно было модифицировать только объекты заказчика, нужно задать программные компоненты НОМЕ и LOCAL и пользовательский раздел имен как «модифицируемый».
Инициализация
Если система SAP R/3 устанавливается с компакт-диска с помощью R3setup или SAPinst, то инициализации CTS не требуется. Если система была создана как копия существующей системы, необходимо использовать ►Installation Postprocessing для регенерации базовых настроек CTS и для закрытия любых внешних запросов и задач в системе.
Для этого нужно выбрать Database copy or migration в ►Installation Postprocessing и выполнить эту функцию. Можно вывести и проанализировать журнал выполненных действий с помощью Extras • Display logs.
Рис. 5.2. Дополнительная обработка при системном копировании или миграции
5.2. Задачи, выполняемые системной инфраструктурой
Каждая инсталлированная система SAP R/3 содержит все ресурсы, которые ей нужны для выполнения всех функций SAP R/3. Кроме бизнес-приложений, поддерживаются разработка и управление ПО, обеспечение качества для разработанных самостоятельно компонентов SAP R/3 и специальные системные настройки. Чтобы удовлетворить эти различные требования и остаться работоспособным без риска для основной деятельности, рекомендуется создать отдельные системы SAP R/3 для каждой из этих специальных сред. Наличие одной системы адекватно отвечает только требованиям подготовки и обучения или демонстрации.
Причина такой рекомендации кроется в различных требованиях, например к тестовой и рабочей системе:
1. Все изменения в репозитории влияют на среду SAP R/3 этапа выполнения, а следовательно — на рабочую систему.
2. Разработчики имеют доступ ко всем таблицам SAP R/3. Следовательно, в односистемной инфраструктуре они могут обращаться к рабочим данным.
3. Операции, связанные с разработкой, отрицательно влияют на производительность. Например, если программы для целей тестирования выполняются в режиме отладки, то рабочий процесс диалога в это время не может быть назначен другому пользователю. Учебные работы в одной системе R/3 также будут отрицательно влиять на ее функционирование и применение в других задачах.
Таким образом, рекомендуется распределять задачи по разным системам и переносить их с тестовой системы в рабочую только после проверки на корректность функционирования. Это называется транспортировкой, или переносом изменений. CTS используется для управления всеми модификациями и для разработки ПО в системах R/3, а также для переноса его между системами (см. рис. 5.1).
Двухсистемные инфраструктуры
Компания SAP рекомендует инсталлировать системную инфраструктуру, содержащую как минимум две системы. Разработка и тестирование осуществляются на одной системе, а производственные операции — на другой.
В двухсистемной инфраструктуре CTS рассматривает систему разработки и тестирования как систему интеграции, а производственную систему — как систему консолидации.
Если в процессе разработки ПО достигается приемлемый уровень, то можно осуществить перенос изменений в другую систему — систему консолидации, которая выполняет роль производственной системы (см. рис. 5.3). Поэтому в этом сценарии не поддерживается тестирование переноса как такового. В случае сложных разработок, которые включают зависимости, полное тестирование в двухсистемной инфраструктуре выполнить невозможно.
Рис. 5.3. Двухсистемная инфраструктура
Подобным образом невозможно протестировать промежуточные состояния программы АВАР, пока продолжается разработка того нее объекта.
Трехсистемные инфраструктуры
Единственное решение, удовлетворяющее в достаточной степени всем требованиям, состоит в использовании трехсистемной инфраструктуры. С технической точки зрения это следующие три системы:
► Система интеграции, играющая роль системы для разработки и специфических для заказчика настроек (Customizing)
► Система консолидации, которая применяется для тестирования и проверки разработок и специфических настроек заказчика в среде аналогичной производственной.
► Поставляемая система, служащая производственной независимой системой.
Роли систем для разработки, обеспечения качества и эксплуатации в этом случае строго разделены. Прежде чем использовать ПО в производственной системе, его нужно тщательно протестировать в другой, отдельной системе. Чтобы этим воспользоваться, технические настройки системы и организационный подход должны соответствовать следующей модели ролей.
Рис. 5.4. Трехсистемная инфраструктура
Соответствие означает следование следующим базовым правилам:
► Вся работа по разработке и настройке происходит в системе интеграции. Правильность функций и свойств проверяется с помощью набора тестовых данных.
► Разработки и системные настройки, которые прошли базовое тестирование, переносятся в выделенную систему консолидации для проведения работ по обеспечению качества, где они проверяются в среде, напоминающей производственную. Обнаруженная ошибка исправляется в системе интеграции, и модифицированная версия разработки или системной настройки снова переносится в систему консолидации.
► Только проверенные модификации переносятся из системы консолидации в производственную систему. Никакие модификации не выполняются на самой производственной системе.
Поддержку соответствия этим базовым правилам можно обеспечить технически с помощью настроек параметра изменения системы (см. раздел 5.1), настроек модифицируемости клиента (см. главу 7) и определения маршрутов переноса между системами инфраструктуры (см. раздел 5.3).
Определяющим фактором в принятии решения относительно выбора инфраструктуры системы является соотношение затрат и выгод (с учетом предъявляемых к системе требований). Несмотря на те преимущества, которые дает трехсистемная инфраструктура, ее сложность приводит к увеличению работ по администрированию. Нужно тщательно взвесить эти требования и оценить затраты.
Многосистемные инфраструктуры
Существуют конфигурации, в которых имеет смысл не ограничиваться трехсистемной инфраструктурой. Например, иногда лучше иметь несколько географически разделенных производственных систем, обслуживающих разные филиалы компании. Технические различия между системами (системой интеграции, консолидации и системой поставки) сохраняются и в таких инфраструктурах — их технические функции остаются прежними. Такие инфраструктуры охватывают несколько параллельно функционирующих систем одного типа. Между тем, роль данных систем не всегда можно точно определить. В определенном смысле она двойственна.
На рис. 5.5 показан пример многосистемной инфраструктуры. Точкой входа является центральная система интеграции, которая используется для разработки «международного» ПО. Подключенные к ней независимые системные инфраструктуры применяются для разработки ПО для конкретной страны.
Рис. 5.5. Многосистемная инфраструктура
5.3. Конфигурации системы управлении переносами
Система управления переносами (TMS — Transport Management System) реализует центральное административное представление настроек и переносов в системной инфраструктуре SAP. Можно скомбинировать системы SAP, чьи свойства переноса должны централизованно администрироваться в доменах переноса. Обычно несколько систем группируются в транспортный домен, а эти домены соединяются через пути переноса. Однако с административной точки зрения можно управлять несколькими такими группами систем в одном транспортном домене.
