В этом примере в компании используется сложное развертывание Windchill, которое включает следующие системы:

Системы подготовки производства и интеграции являются клонами производственной системы. Также создается новая производственная система, которая становится действующей после внедрения, проверки и импорта изменений. Эти три системы созданы с помощью Windchill Rehost Utility. Две системы разработчика были установлены и настроены отдельно. Системы разработчика содержат только часть данных, доступных в системах интеграции и подготовки производства и в производственной системе. Для данных, представленных в системах разработчика, используются идентификаторы объектов, отличные от тех, которые используются для данных в остальных системах.

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

Дополнительную информацию см. в Регистрация систем и Команда регистрации системы.

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

Дополнительные сведения см. в разделе Задание опорной структуры.

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

Дополнительные сведения см. в разделе Внедрение изменений административных объектов.

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

При успешном экспорте создается ZIP-файл, содержащий данные обо всех новых, измененных или удаленных административных объектах. В данном случае создается ZIP-файл для каждой системы разработки. Этот ZIP-файл содержит данные о новом профиле и новом правиле управления доступом к политике, которые были созданы в каждой системе. Затем ZIP-файл копируется в целевую систему, которой в данном примере является система интеграции.

Дополнительные сведения см. в разделе Предварительный просмотр и экспорт изменений.

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

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

Дополнительные сведения см. в разделе Импорт изменений.

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

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

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

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

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

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

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