ГЛАВА 5 СОЗДАНИЕ И НАСТРОЙКА СИСТЕМНОЙ ИНФРАСТРУКТУРЫ

ГЛАВА 5

СОЗДАНИЕ И НАСТРОЙКА СИСТЕМНОЙ ИНФРАСТРУКТУРЫ

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

После инсталляции лицензии R/3 и проверки выполненной инсталляции систему SAP R/3 можно считать установленной. Это означает, что доступны все необходимые данные и программы. Следующий шаг — задание всех технических параметров, специфических для заказчика. До выполнения этой работы никто не должен работать с системой. В частности, не рекомендуется вносить изменения в пользовательские настройки (Customizing). При подготовке только что инсталлированной системы R/3 особенно важно инициализировать систему коррекции и транспортировки (CTS — Change and Transport System). Это подготовит основу для взаимодействия с другими системами.

CTS состоит из следующих трех блоков (см. рис. 5.1):

? Организатор переносов (и организатор переносов — расширенное представление)

? Система управления переносами

? Инструменты переноса

Организатор переносов (Transport Organizer) является одним из наиболее важных инструментов для людей, работающий над проектом, которые имеют дело с настройкой и разработкой, и для системных администраторов, которые отвечают за переносы (подробнее о характеристиках и параметрах организатора переносов см. в главе 6).

Рис. 5.1. Компоненты системы коррекции и транспортировки (CTS)

Переносы

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

Программы tp и R3trans работают на уровне операционной системы для экспорта запросов переноса в файлы и импорта их в целевую систему. Во время установки системы создается каталог переноса с фиксированным путем доступа; этот каталог содержит все файлы CTS.

5.1. Инициализация системы изменений и переноса

На последнем шаге инсталляции для каждой системы SAP R/3 инфраструктуры должен быть определен глобальный или специфический для класса объекта параметр изменения системы (system change option). Объекты SAP R/3, которые являются здесь существенными, включают кросс-клиентские данные, такие как программы, шаблоны экранов, меню, таблицы и структуры, а также независимый от клиента параметр Customizing (см. главу 7). Параметр изменения системы определяется вручную в каждой системе SAP R/3. Необходимо сначала рассмотреть, должны ли эти объекты вообще быть модифицируемыми в системе SAP R/3. Термин «модифицируемость» означает возможность создания и адаптации новых объектов или дополнительной разработки объектов, предоставленных SAP, чтобы удовлетворить специальные требования заказчиков. Эти данные не должны изменяться в производственной рабочей среде. Модификации, допустимые в разрабатываемой системе, зависят от типа и области действия разработок. Например, являются ли допустимыми модификации объектов, которые предоставила фирма SAP?

Есть две возможности для задания параметра изменения системы: с помощью ?installation postprocessing (до версии SAP R/3 4.6C) или ?Transport Organizer • Tools Administration • Set system change option. Сначала делаются глобальные настройки, чтобы определить, допустимы ли модификации или нет. Объекты хранилища группируются в программные компоненты и присваиваются пространству имен. Система, в которой был создан объект, называется исходной системой (см. главу 6) объекта. Можно использовать эти настройки для более детального задания настроек модифицируемости. Объект является модифицируемым, только если:

1. Глобальный параметр изменения системы задан как «modifiable» (изменяемый).

2. Программные компоненты, которым принадлежит объект, имеют значение «изменяемый».

3. Пространство имен, в котором находится объект, имеет значение «изменяемое».

Таблица 5.1. Параметр изменения системы на уровне пространства и программных компонентов

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

Система SAP R/3 распознает следующие программные компоненты:

? Разработки заказчика (НОМЕ)

Включает все специфические разработки заказчика, выполненные с помощью всех доступных в системе SAP R/3 инструментов, которые могут переноситься.

? Локальные разработки (без автоматического переноса: LOCAL) Включает все специфические объекты заказчика, которые не являются переносимыми (локальные).

? Общие для всех приложений компоненты (SAP_ABA)

Этот вариант позволяет делать модификации с помощью инструментов АВАР Workbench (Development Workbench) во всех прикладных компонентах, поставляемых компанией SAP.

? Логистика и бухгалтерский учет (SAP_APPL)

? Компоненты SAP Basis (SAP_BASIC)

Позволяет изменять все компоненты Basis с помощью доступных инструментов. Допускаются все компоненты из Development Workbench, АВАР Query и использование Function Builder.

? Трудовые ресурсы (SAP_HR)

Наиболее важными пространствами и разделами имен являются:

? Пространство имен заказчика

Все объекты без префикса, имена которых начинаются с 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, чьи свойства переноса должны централизованно администрироваться в доменах переноса. Обычно несколько систем группируются в транспортный домен, а эти домены соединяются через пути переноса. Однако с административной точки зрения можно управлять несколькими такими группами систем в одном транспортном домене.

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

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-соединения с другими системами.

Рис. 5.6. Авторизация пользователя TMSADM

Интеграция дополнительных систем

Чтобы интегрировать в домен дополнительные системы SAP R/3, выполните следующее:

1. Войдите в интегрируемую систему с клиента 000 и вызвать ?Transport Management System. Добавляемая система автоматически распознает, что текущая система еще не принадлежит домену. Если используется тот же самый каталог переноса (см. раздел 5.4), система анализирует конфигурационный файл (DOMAIN.CFG) и предлагает предоставленный домен. Можно изменить это предложение, если будет выбран другой домен или создан новый. Согласитесь с предложением или введите имя нужного домена. После сохранение введенных данных новая система готова к интеграции в домен.

2. На втором шаге TDC должен подтвердить интеграцию новой системы, чтобы она полностью интегрировалась в домен. Для этого перезапустите ?Transport Management System на TDC с клиентом 000 и выберите Overview • Systems. Новая система появится в списке со статусом: System waiting for inclusion in the transport domain (Система ожидает включения в транспортный домен). Выберите систему и затем SAP System • Approve, чтобы записать ее в домен.

Модификация конфигурации в TDC теперь закончена. Чтобы обеспечить согласованное представление конфигурации TMS, это изменение должно быть распространено на все другие системы в домене. Распространение модификаций всегда возможно сразу после этого действия или как часть группы. Можно инициировать распространение TDC через клиента 000 с помощью ?Transport Management System • Overview • Systems • Extras • Distribute and activate configuration.

Будет выведена подробная информация о любых ошибках, которые могли произойти во время конфигурации. Кроме того, монитор сигналов TMS содержит историю всех ошибок, включая заметку о возможных причинах и исправлениях. К монитору сигналов можно обратиться из ?Transport Management System через Monitor • TMS Alerts • TMS Alert Viewer. Функции области систем управления переносом также связаны с мониторингом сигналов Системы управления вычислительным центром (CCMS — Computing Center Management System) (см. главу 16); к этому монитору можно обратиться непосредственно или из ?Transport Management System через Monitor • TMS Alerts • CCMS Alert Monitor.

Резервный контроллер домена

Контроллер транспортного домена всегда должен быть доступен для модификаций конфигурации, таких как интеграция дополнительной системы. Чтобы обеспечить продолжение работы в случае отказа TDC, можно использовать резервный контроллер домена (BDC — Backup Domain Controller). Использование BDC позволяет переносить функции TDC на другую систему в том же домене. Для этого определите систему как BDC следующим образом: ?Transport Management System • Overview • Systems; выберите систему SAP system • Change; введите системный идентификатор в поле резервного копирования на вкладке Communication. Если BDC должен принять на себя задачи TDC, необходимо активировать TDC из списка систем на BDC с помощью Extras • Activate Backup Controller. По очевидным причинам это единственное действие по конфигурированию, которое не выполняется на TDC.

Можно удалить всю конфигурацию TMS из обзора системы с помощью Extras • Delete TMS configuration; можно удалить одну систему из обзора системы на TDC с помощью SAP System • Delete. После удаления некоторые настройки все еще присутствуют в неактивной форме и должны быть перезаписаны новыми настройками, если необходимо.

SAP R/3 3.1Н является минимальной версией, требуемой для интеграции системы SAP в транспортный домен.

Виртуальные системы

Чтобы смоделировать инфраструктуру переноса, в которой не все системы физически присутствуют или доступны, можно определить виртуальные системы в качестве фиктивных. Переносы, предназначенные для этих систем, собираются и могут быть немедленно импортированы, когда виртуальные системы заменяются реальными. Виртуальные системы можно создать с помощью ?Transport Management System • Overview. Systems • SAP systems • Create • Virtual system и вводя дополнительно систему коммуникации. Система коммуникации необходима, чтобы сделать доступными требуемые соединения RFC. Когда реальная система будет готова, необходимо будет удалить виртуальную замену из конфигурации и интегрировать в домен новую систему. SID новой системы должен быть согласован с SID виртуальной системы, чтобы можно было использовать заданные настройки.

Внешние системы

Кроме виртуальных систем, можно определить внешние системы. Это особый тип виртуальных систем, не существующих физически в транспортном домене. Такие системы полезны, если нужно:

? Передавать данные между различными транспортными доменами, т. е. из одной системы в систему в другом транспортном домене.

? Импортировать данные со сменного носителя или экспортировать их на него.

Существенное различие между виртуальной и внешней системами состоит в используемом каталоге переноса. Виртуальные системы используют стандартный каталог переноса своей коммуникационной системы; для внешних систем можно определить любой каталог. Аналогично созданию виртуальной системы внешняя система создается с помощью ?Transport Management System • Overview • Systems • SAP System • Create • External system. Система SAP, из которой происходит управление внешней системой SAP, задается как коммуникационная система; когда создается внешняя система, TDC предлагается в качестве коммуникационной системы. Необходимо также определить каталог переноса, который будет использоваться. В этом каталоге будут храниться все данные и журналы, требуемые для обмена с внешними системами.

На рис. 5.7 показаны внешняя система «QAS» в DOMAIN_A, которая будет использоваться в качестве фиктивной для реальной системы «QAS» в DOMAIN_B, и внешняя система «DEV» в DOMAIN_B, которая будет использоваться в качестве фиктивной для реальной системы «DEV» в DOMAIN_A. Обмен данными происходит через каталог trans_ext, который должен быть доступен из системы коммуникации, назначенной обеим системам.

Рис. 5.7. Внешние системы в качестве фиктивных в других доменах

Соединение доменов

Соединение доменов предоставляет другой метод соединения транспортных доменов. Каждый из двух доменов с TDC, выполняющим Basis Release 4.6C (как минимум), можно соединить с помощью прямой связи. Для этого используется ?Transport Management System • Overview • Systems • SAP System • Create • Domain Link для соединения с TDC в удаленном домене, который может быть доступен через сетевое соединение. TDC удаленного домена должен подтвердить соединение: будут определены все требуемые соединения RFC, и можно будет обратиться к системам удаленного домена. Центральный каталог переноса, созданный во время установки, используется по умолчанию для хранения всех требуемых данных переноса и журналов. На рис. 5.8 приведена структура дерева каталогов.

Рис. 5.8. Дерево каталога переноса

Следующий список описывает содержимое подкаталогов:

? bin

Конфигурационный файл TP_<domain>.PFL программы переноса tp (см. раздел 5.4) и конфигурационный файл DOMAIN.CFG домена.

? data

Файлы данных запросов переноса (см. главу 6).

? sapnames

Файл журнала для каждого пользователя CTS. Содержит действия по переносу запросов переноса пользователя.

? buffer

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

? tmp

Временные файлы журналов и семафоры.

? log

Общие и специфические для запроса файлы журналов.

? cofiles

Управляющие файлы для запросов переноса. В файлы записываются объектные классы, требуемые действия по импорту и возвращаемые значения. Особый интерес представляет статус импорта запросов переноса в различных системах группы переноса.

Не каждой системе SAP необходимо иметь свое собственное локальное дерево каталогов. Чтобы сделать дерево каталога переноса доступным глобально, в большей степени подходит использование средств уровня операционной системы (share, mount и NFS link). Однако системы, подчиненные специальным ограничениям безопасности, могут иметь свой собственный локальный каталог переноса с подходящими правами ограниченного доступа. На рис. 5.9 показан поток переноса в трехсистемной инфраструктуре с общим каталогом переноса.

Транспортные группы

Системы SAP R/3, использующие общее дерево каталога переноса, образуют транспортную группу. Транспортный домен может включать в себя несколько транспортных групп. Если экспортирующие и импортирующие системы расположены в различных транспортных группах, очереди импорта должны быть синхронизированы перед импортом, а данные и управляющие файлы, необходимые для импорта, нужно перенести в каталог переноса целевой системы. Перенос можно инициировать из TMS.

5.3.2. Пути переноса

После того как доступные в инфраструктуре системы SAP сделаны известными, последний шаг состоит в определении путей переноса между системами. Будем предполагать, что цель конфигурации известна, и покажем, как сделать требуемые настройки для трехсистемной инфраструктуры.

Рис. 5.9. Трехсистемная инфраструктура с общим каталогом переноса

Редакторы

Записи в системных таблицах организуют управление путями переноса и роль каждой системы. Во время конфигурации путей переноса можно использовать редактор иерархического списка или графический редактор для генерации этих записей. Наиболее важным типом требуемой информации является спецификация роли каждой системы (конфигурация, консолидация или поставка). Центральная конфигурация TMS означает, что необходимо предоставить информацию только один раз: информация затем распространяется на все участвующие системы. Следующее описание определения путей переноса предполагает, что пользователь зарегистрировался в системе SAP контроллера транспортного домена на клиенте 000 с достаточными административными полномочиями.

Чтобы упростить конфигурацию путей переноса, выберите конфигурацию (одно-, двух- или трехсистемную инфраструктуру) и усовершенствуйте ее необходимым образом.

Редактор списков

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

1. Выберите ?Transport Management System • Overview • Transport routes для вывода иерархического дерева соединений. Вначале все определенные системы и их конфигурационный статус доступны только в режиме вывода.

2. Перейдите к изменению режима с помощью Configuration • Display Change и воспользуйтесь Configuration • Standard configuration для выбора предпочтительной модели из следующих вариантов:

- Одна система

- Система разработки и производственная система

- Три системы в группе

В этой конфигурации каждой системе присваивается роль (см. рис. 5.10).

Рис. 5.10. Назначение систем

3. Сохраните записи. Записи таблицы, описывающие связи между системами, генерируются автоматически. Сохраните новые настройки с помощью Configuration • Check • Transport routes.

4. Распространите настройки с помощью Configuration • Distribute and activate.

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

Уровень переноса

На рис. 5.11 также показано, что между системами интеграции и консолидации создается уровень переноса (transport layer), «Z<integration_system>». Уровень переноса всегда описывает путь переноса, которым должны следовать данные из системы разработки. Этот путь называется также путем консолидации. Путь переноса из системы консолидации или поставки в другую систему поставки называется путем поставки. Путь поставки может существовать только в системной инфраструктуре, которая состоит как минимум из трех систем. Этот путь всегда предполагает присутствие предшествующего пути консолидации.

Кроме уровня переноса между системами интеграции и консолидации, в этих системах автоматически создается также дополнительный уровень переноса «SAP». Этот уровень переноса гарантирует, что модификации, сделанные в поставленных SAP объектах, можно импортировать в системы.

В зависимости от того, как выполняется проект разработки, может быть полезно или необходимо создать несколько путей консолидации (см. главу 6).

Рис. 5.11. Конфигурация системы (Редактор списка)

Графический редактор

Теперь выполним ту же самую конфигурацию с помощью графического редактора:

1. Графический редактор можно вызвать при выводе или обслуживании путей переноса с помощью Goto • Graphical editor. Верхняя область экрана выводит все системы, объединенные в транспортном домене, которые еще не использовались в определении путей переноса.

2. Можно использовать Configuration • Standart configuration для выбора требуемой системной инфраструктуры и присвоения ролей отдельным системам.

3. Сохраните настройки с помощью Configuration • Save. Требуемые записи в таблице генерируются автоматически. Теперь конфигурацию необходимо сохранить и активировать.

На рис. 5.12 показана та же самая конфигурация, что и на рис. 5.11.

Рис. 5.12. Конфигурация системы (Графический редактор)

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

Теперь можно определить путь переноса между системами с помощью Edit • Transport route • Crerate. Неправильные пути переноса можно удалять с помощью пункта Delete в том же меню. Запуск этой функции изменяет указатель в области вывода в карандаш, который можно использовать для вычерчивания линии между нужными системами. Для каждого пути переноса, определенного таким образом, необходимо определить, идет ли речь о консолидации (о переносе из системы интеграции в систему консолидации с подходящим уровнем переноса) или о поставке.

Область изображения выводит поток данных разработки в системной инфраструктуре.

5.3.3. Дополнительное управление переносом

При использовании дополнительного управления переносом можно выбрать процедуру на базе клиента вместо процедуры на основе системы:

? Во время определения пути консолидации или поставки необходимо определить целевого клиента или группу клиентов (целевую группу) вместо целевой системы.

? Можно задать стандартный уровень переноса, используемый для определения того, чтобы цель переноса настроек Customizing была зависимой от клиента. Таким образом можно посылать запросы Customizing из различных клиентов в различные цели переноса.

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

Дополнительное управление переносом можно активировать, задавая параметр СТС равным 1 в Transport Management System • Overview • Systems • SAP System • Change • Transport tool. Смешанные операции на основе системы и дополнительного управления переносом в одной инфраструктуре не допускаются.

5.3.4. Процедура утверждения QA

В инфраструктуре переноса, которая состоит как минимум из трех систем, системы консолидации и пути поставки для технической поддержки базовых правил (см. раздел 5.3), можно реализовать процедуру утверждения QA.

Запросы в системе QA могут разрешаться для импорта в производственную систему только после выполнения определенного числа подтверждающих действий.

Выберите систему консолидации, которая будет сконфигурирована как система QA, из ?Transport Management System • Overview • Transport routes. Пункт меню Edit • System • Change предоставит доступ к системным атрибутам выбранной системы. Задайте подтверждение в поле обеспечения качества (QA), а затем можно определить процедуру утверждения (см. рис. 5.13).

Рис. 5.13. Определение процедуры утверждения

5.3.5. Стратегия переноса

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

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

В System Attributes (см. рис. 5.14) можно выбирать из следующих вариантов:

? Массовые переносы, управляемые очередью

? Одиночные переносы, управляемые очередью

? Переносы, управляемые потоком выполнения

По умолчанию используются управляемые очередью массовые переносы.

Рис. 5.14. Системные атрибуты

5.4. Программа управления переносами — tp

Программа tp используется на уровне операционной системы для управления переносом между системами и для его осуществления. С помощью таких средств, как программа уровня ОС R3trans и других интегрированных с R/3 средств, tp экспортирует данные из системы R/3 и импортирует их из других систем. Чтобы сделать всю требуемую информацию системной инфраструктуры доступной для tp, в подкаталоге bin каталога переноса во время инициализации управления переносом сохранится конфигурационный файл TP_<domain>.PFL. В нем уже существуют значения по умолчанию для всех значений параметров. Можно изменить и улучшить параметры, делая изменения в ?Transport Management System • Overview • Systems • SAP System • Change • Transport tool.

Рис. 5.15. Обслуживание параметров tp

Запрещенные или неизвестные значения параметров не порождают сообщение об ошибке — они просто игнорируются. Можно вывести реальные текущие значения (см. рис. 5.15), используя Goto • TP parameters.

Все действия программы tp регистрируются в подкаталоге log каталога переноса. По умолчанию все записи для запросов на перенос, использующих программу tp, содержат файл ALOG. В файле SLOG регистрируется время запуска, шаги выполнения работы, продолжительность и время завершения каждого переноса. Если нужно использовать имена файлов, отличные от заданных по умолчанию, то можно определить параметры alllog и syslog программы tp. Например:

? alllog = ALOG$(syear).$(yweek)

записывает для каждого года и недели новый файл журнала в формате ALOG<YY>.<WWW>.

Кроме того, система хранит файл журнала ULOG<год>_<номер>, в котором записывается каждый выполняемый вызов tp с параметрами и именем пользователя операционной системы. <Год> — это две последних цифры года, а <номер> — текущий квартал года.

5.5. Советы

? Не используйте дополнительное управление переносом с виртуальной системой консолидации

Можно, конечно, создать виртуальную систему как систему консолидации в конфигурации с дополнительным управлением переносом. Однако для этой системы невозможно выполнить запрос переноса.

5.6. Транзакции и пути доступа меню

Installation postprocessing: нет записи стандартного меню (SE06)

Transport Management System: SAP Menu • Tools • Administration • Transports Transport Management System (STMS)

Transport Organizer Tools: нет записи стандартного меню (SE03)

5.7. Дополнительная документация

Быстрые ссылки

SAP Service Marketplace: псевдоним swchangemanagement

Указания SAP Service Marketplace

В следующей таблице представлен обзор важных указаний, имеющих отношение к настройке инфраструктур переноса.

Таблица 5.2. Указания SAP по системе управления переносом

5.8. Контрольные вопросы

1. Какие из следующих утверждений о конфигурации TMS являются правильными?

a. В транспортном домене может существовать несколько транспортных групп.

b. Все системы, которые имеют доступ к общему каталогу переноса /usr/sap/trans, присваиваются одной транспортной группе.

c. В любое данное время может быть определен только один уровень переноса.

d. Уровень переноса неявно определяет путь к целевой системе.

2. Какие из следующих утверждений справедливы?

В многосистемной инфраструктуре операциями переноса можно управлять:

a. Только с той системы, в которую импортируются или из которой экспортируются данные

b. Централизованно с контроллера транспортного домена.

с. На уровне операционной системы с помощью программы tp.

d. В транспортном домене с каждой входящей в этот домен системы SAP R/3.

3. Что из перечисленного является путями переноса?

a. Прямой путь переноса

b. Косвенный путь переноса

с. Путь консолидации

d. Путь поставки

e. Обход

4. Какая программа уровня операционной системы используется для выполнения переноса?

a. R3load

b. R3INST

c. tp

d. dpmon

e. sapdba