Рис. 5.3.Двухсистемная инфраструктура
Подобным образом невозможно протестировать промежуточные состояния программы АВАР, пока продолжается разработка того нее объекта.
Трехсистемные инфраструктуры
Единственное решение, удовлетворяющее в достаточной степени всем требованиям, состоит в использовании трехсистемной инфраструктуры. С технической точки зрения это следующие три системы:
► Система интеграции, играющая роль системы для разработки и специфических для заказчика настроек (Customizing)
► Система консолидации, которая применяется для тестирования и проверки разработок и специфических настроек заказчика в среде аналогичной производственной.
► Поставляемая система, служащая производственной независимой системой.
Роли систем для разработки, обеспечения качества и эксплуатации в этом случае строго разделены. Прежде чем использовать ПО в производственной системе, его нужно тщательно протестировать в другой, отдельной системе. Чтобы этим воспользоваться, технические настройки системы и организационный подход должны соответствовать следующей модели ролей.
Рис. 5.4.Трехсистемная инфраструктура
Соответствие означает следование следующим базовым правилам:
► Вся работа по разработке и настройке происходит в системе интеграции. Правильность функций и свойств проверяется с помощью набора тестовых данных.
► Разработки и системные настройки, которые прошли базовое тестирование, переносятся в выделенную систему консолидации для проведения работ по обеспечению качества, где они проверяются в среде, напоминающей производственную. Обнаруженная ошибка исправляется в системе интеграции, и модифицированная версия разработки или системной настройки снова переносится в систему консолидации.
► Только проверенные модификации переносятся из системы консолидации в производственную систему. Никакие модификации не выполняются на самой производственной системе.
Поддержку соответствия этим базовым правилам можно обеспечить технически с помощью настроек параметра изменения системы (см. раздел 5.1), настроек модифицируемости клиента (см. главу 7) и определения маршрутов переноса между системами инфраструктуры (см. раздел 5.3).
Определяющим фактором в принятии решения относительно выбора инфраструктуры системы является соотношение затрат и выгод (с учетом предъявляемых к системе требований). Несмотря на те преимущества, которые дает трехсистемная инфраструктура, ее сложность приводит к увеличению работ по администрированию. Нужно тщательно взвесить эти требования и оценить затраты.
Многосистемные инфраструктуры
Существуют конфигурации, в которых имеет смысл не ограничиваться трехсистемной инфраструктурой. Например, иногда лучше иметь несколько географически разделенных производственных систем, обслуживающих разные филиалы компании. Технические различия между системами (системой интеграции, консолидации и системой поставки) сохраняются и в таких инфраструктурах - их технические функции остаются прежними. Такие инфраструктуры охватывают несколько параллельно функционирующих систем одного типа. Между тем, роль данных систем не всегда можно точно определить. В определенном смысле она двойственна.
На рис. 5.5 показан пример многосистемной инфраструктуры. Точкой входа является центральная система интеграции, которая используется для разработки "международного" ПО. Подключенные к ней независимые системные инфраструктуры применяются для разработки ПО для конкретной страны.
Рис. 5.5.Многосистемная инфраструктура
5.3. Конфигурации системы управлении переносами
Система управления переносами (TMS - Transport Management System) реализует центральное административное представление настроек и переносов в системной инфраструктуре SAP. Можно скомбинировать системы SAP, чьи свойства переноса должны централизованно администрироваться в доменах переноса. Обычно несколько систем группируются в транспортный домен, а эти домены соединяются через пути переноса. Однако с административной точки зрения можно управлять несколькими такими группами систем в одном транспортном домене.
Чтобы отобразить предпочтительную системную среду в среде переноса, необходимо выполнить следующие базовые действия:
1. Решить, какие системы будут объединены в транспортном домене, чтобы можно было централизовано управлять их свойствами переноса. Если эти системы не присутствуют физически, когда моделируется инфраструктура переноса и отражается в TMS, можно сконфигурировать виртуальные фиктивные системы.
2. Определить, какая система будет использоваться в качестве центральной административной.
3. Определить, какие системы или клиенты будут соединяться при переносе и какую роль (интеграции, консолидации или поставки) они будут играть в группе переноса.
5.3.1. Транспортные домены
Контроллер транспортного домена (TDC)
Все системы, которые должны управляться через центральный TDC, конфигурируются в один транспортный домен. По техническим причинам идентификаторы систем, участвующих в транспортном домене, должны быть уникальными. Контроллер транспортного домена (TDC - Transport Domain Controller) является специальной системой транспортного домена, которая управляет всеми настройками TMS. Для поддержания согласованного представления всех систем в домене TMS обращается к конфигурации, расположенной на TDC; копия этой конфигурации распространяется всем членам домена. Поэтому все требуемые настройки, такие как определение путей переноса (см. раздел 5.3.2), делаются на TDC.
Коммуникации между TDC и другими системами SAP в домене основаны на соединениях RFC (Remote Function Call) (см. главу 13). Конфигурация TMS автоматически создает требуемые соединения RFC.
Контроллером транспортного домена должна быть выбрана отказоустойчивая и хорошо защищенная система SAP в системной инфраструктуре. Желательно, чтобы на ней была установлена последняя версия системы R/3. Таким образом, рабочая система и система обеспечения качества обычно лучше подходят для TDC, чем системы тестирования. Нагрузка, создаваемая TMS в среде R/3, невысока и не будет влиять на производительность.
Если потребуется, то другая система в домене может принять на себя функции TDC. Такая возможность часто используется при перестройке системной инфраструктуры, где сначала была установлена система разработки. Эта система разработки затем играет роль TDC, пока не будет выполнена конфигурация производственной системы.
Создание транспортного домена
При создании транспортного домена и его контроллеров нужно действовать следующим образом:
1. Конфигурация домена выполняется с помощью ►Transport Management System на клиенте 000 системы SAP R/3, которая рассматривалась первоначально в качестве TDC.
2. Система уведомит, что TMS еще не определена, и предложит имя домена на следующем шаге. Именем по умолчанию является "DOMAIN_<SID>", где "<SID>" является идентификатором системы, которая используется для выполнения конфигурации.
3. Выберите New Domain (новый домен) и введите имя и описание домена. Имя не должно содержать пробелов. После выбора имени домена его можно будет модифицировать только тогда, когда TMS будет полностью реконфигурироваться.
4. Сохраните введенную информацию.
Система, из которой создается транспортный домен, определяется контроллером домена (Domain Controller). Вся дальнейшая работа по конфигурации должна выполняться из этой системы на клиенте 000.
Теперь домен и его контроллер определены. Это определение можно проверить с помощью команды ►Transport Management System • Overview • Systems. Во время определения TDC, и позже, во время интеграции в домен дополнительных систем, система автоматически выполняет в фоновом режиме некоторые задачи для подготовки функций TMS:
► Данные конфигурации сохраняются в БД, часть данных сохраняется также в файле DOMAIN.CFG b подкаталоге bin каталога переноса на уровне операционной системы.
► Для системы R/3 создается пользователь TMSADM с типом communication (см. главу 8). Этот пользователь авторизован только для задач TMS (см. рис. 5.6).
► Создаются все необходимые RFC-соединения с другими системами.