Рис. 5.3. Двухсистемная инфраструктура

Подобным образом невозможно протестировать промежуточные состояния программы АВАР, пока продолжается разработка того нее объекта.

Трехсистемные инфраструктуры

Единственное решение, удовлетворяющее в достаточной степени всем требованиям, состоит в использовании трехсистемной инфраструктуры. С технической точки зрения это следующие три системы:

► Система интеграции, играющая роль системы для разработки и специфических для заказчика настроек (Customizing)

► Система консолидации, которая применяется для тестирования и проверки разработок и специфических настроек заказчика в среде аналогичной производственной.

► Поставляемая система, служащая производственной независимой системой.

Роли систем для разработки, обеспечения качества и эксплуатации в этом случае строго разделены. Прежде чем использовать ПО в производственной системе, его нужно тщательно протестировать в другой, отдельной системе. Чтобы этим воспользоваться, технические настройки системы и организационный подход должны соответствовать следующей модели ролей.

Рис. 5.4. Трехсистемная инфраструктура

Соответствие означает следование следующим базовым правилам:

► Вся работа по разработке и настройке происходит в системе интеграции. Правильность функций и свойств проверяется с помощью набора тестовых данных.

► Разработки и системные настройки, которые прошли базовое тестирование, переносятся в выделенную систему консолидации для проведения работ по обеспечению качества, где они проверяются в среде, напоминающей производственную. Обнаруженная ошибка исправляется в системе интеграции, и модифицированная версия разработки или системной настройки снова переносится в систему консолидации.

► Только проверенные модификации переносятся из системы консолидации в производственную систему. Никакие модификации не выполняются на самой производственной системе.

Поддержку соответствия этим базовым правилам можно обеспечить технически с помощью настроек параметра изменения системы (см. раздел 5.1), настроек модифицируемости клиента (см. главу 7) и определения маршрутов переноса между системами инфраструктуры (см. раздел 5.3).

Определяющим фактором в принятии решения относительно выбора инфраструктуры системы является соотношение затрат и выгод (с учетом предъявляемых к системе требований). Несмотря на те преимущества, которые дает трехсистемная инфраструктура, ее сложность приводит к увеличению работ по администрированию. Нужно тщательно взвесить эти требования и оценить затраты.

Многосистемные инфраструктуры

Существуют конфигурации, в которых имеет смысл не ограничиваться трехсистемной инфраструктурой. Например, иногда лучше иметь несколько географически разделенных производственных систем, обслуживающих разные филиалы компании. Технические различия между системами (системой интеграции, консолидации и системой поставки) сохраняются и в таких инфраструктурах — их технические функции остаются прежними. Такие инфраструктуры охватывают несколько параллельно функционирующих систем одного типа. Между тем, роль данных систем не всегда можно точно определить. В определенном смысле она двойственна.

На рис. 5.5 показан пример многосистемной инфраструктуры. Точкой входа является центральная система интеграции, которая используется для разработки «международного» ПО. Подключенные к ней независимые системные инфраструктуры применяются для разработки ПО для конкретной страны.

Рис. 5.5. Многосистемная инфраструктура

Система управления переносами (TMS — Transport Management System) реализует центральное административное представление настроек и переносов в системной инфраструктуре SAP. Можно скомбинировать системы SAP, чьи свойства переноса должны централизованно администрироваться в доменах переноса. Обычно несколько систем группируются в транспортный домен, а эти домены соединяются через пути переноса. Однако с административной точки зрения можно управлять несколькими такими группами систем в одном транспортном домене.

Чтобы отобразить предпочтительную системную среду в среде переноса, необходимо выполнить следующие базовые действия:

1. Решить, какие системы будут объединены в транспортном домене, чтобы можно было централизовано управлять их свойствами переноса. Если эти системы не присутствуют физически, когда моделируется инфраструктура переноса и отражается в TMS, можно сконфигурировать виртуальные фиктивные системы.

2. Определить, какая система будет использоваться в качестве центральной административной.

3. Определить, какие системы или клиенты будут соединяться при переносе и какую роль (интеграции, консолидации или поставки) они будут играть в группе переноса.

Контроллер транспортного домена (TDC)

Все системы, которые должны управляться через центральный TDC, конфигурируются в один транспортный домен. По техническим причинам идентификаторы систем, участвующих в транспортном домене, должны быть уникальными. Контроллер транспортного домена (TDC — Transport Domain Controller) является специальной системой транспортного домена, которая управляет всеми настройками TMS. Для поддержания согласованного представления всех систем в домене TMS обращается к конфигурации, расположенной на TDC; копия этой конфигурации распространяется всем членам домена. Поэтому все требуемые настройки, такие как определение путей переноса (см. раздел 5.3.2), делаются на TDC.