Кроме виртуальных систем, можно определить внешние системы. Это особый тип виртуальных систем, не существующих физически в транспортном домене. Такие системы полезны, если нужно:
► Передавать данные между различными транспортными доменами, т. е. из одной системы в систему в другом транспортном домене.
► Импортировать данные со сменного носителя или экспортировать их на него.
Существенное различие между виртуальной и внешней системами состоит в используемом каталоге переноса. Виртуальные системы используют стандартный каталог переноса своей коммуникационной системы; для внешних систем можно определить любой каталог. Аналогично созданию виртуальной системы внешняя система создается с помощью ►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. Конфигурация системы (Редактор списка)
