In this example, a company has a complex Windchill deployment that includes the following systems:

The pre-production system and integration system are clones of the production system. A new production system is also created and becomes the live production system after changes are implemented, tested, and imported. These three systems were created using the Windchill Rehost Utility. The two developer systems were installed and configured separately. The developer systems have only a portion of the data that is available on the integration, pre-production, and production systems. The data present on the developer systems has different object identifiers from the data on the other systems.

To begin the business administrative change promotion process, the systems must be registered. A command is run on each system to find the hostname and globally unique identifier (GUID) for that system. These two attributes are recorded for easy reference when running commands on each source system. A different command is run on each source system to register the appropriate target system. In the example case presented above, the integration system would be registered as a selective target system on each developer system. The integration system is a selective system because the developer systems did not originate from the same source as the integration system. The pre-production system would be registered as a synchronized target system on the integration system. The production system would be registered as a synchronized target system on the pre-production system. These systems are synchronized systems because they all originated from the same source, as illustrated with the orange arrows in the previous diagram.

For more information, see Registering Systems and Register System Command.

Before making changes to any system, all systems with a synchronized system registered as a target system should run a command to establish a baseline. A baseline is the point from which changes are tracked. In this example, the baseline command would be run on the integration and pre-production systems.

For more information, see Establishing a Baseline.

In this example, a new profile and new policy access control rule were created on each development system. These changes are represented by the pink and orange shapes in the following diagram.

For more information, see Implementing Changes to Administrative Objects.

After creating the new profile and policy access control rule and testing the results, the new objects are ready to be exported to the integration system. To do this, a command is run on each development system specifying the following:

If the export is successful, a ZIP file is created with data about any new, changed, or deleted administrative objects. In this case, a ZIP file is created for each development system. The ZIP file contains data about the new profile and new policy access control rule created in each system. The ZIP file is then copied to the target system, which is the integration system in this example.

For more information, see Previewing and Exporting Changes.

When the exported ZIP file is available on the target system, the import command can be run. To run the command, you need the path to the ZIP file on the local system. After the import succeeds, the changes should be available on the target system. In this example, the new profiles and policy access control rules are added to the system.

Because the export from the development systems and import into the integration system was completed using the selective mode, the object identifiers are different between the source and target systems. In the diagram above, the different identifiers are illustrated using a dashed line on the development systems and no line on the integration system. If a change had been made to one of the objects that is available on both systems (such as a profile available in Windchill out of the box), the selective mode would match the objects by the object attributes. For example, if a change was made to an out-of-the-box profile, the selective mode would match them by an attribute like the profile name. After the objects are matched the first time, the selective mode creates a mapping between the object identifiers on each system so that any updates made in the future can be applied appropriately.

For more information, see Importing Changes.

Objects importing using the business administrative change promotion process should function as though the objects were created in and are owned by the target Windchill system. It is still recommended that the administrative objects are tested on each target system to ensure that they are working as expected.

In the example, two new profiles and two new policy access control rules were added to the integration system. An administrator should log in as a user to which the profile or policy rule applies to ensure that the user is seeing the intended behavior.

After testing the newly imported objects on the integration system, the changes can be exported from the integration system and imported into the pre-production test system. To do this, a command is run on the integration system specifying the following:

All changes since the baseline are exported. In the example, this would include the two new profiles and two new policy access control rules that originated from the two development systems. This is because baseline on the integration system was established before the changes were imported and tested and no other changes were made to the system. If the export is successful, a ZIP file is created that contains the data for the new policy access control rules and the new profiles. The ZIP file is then copied to the target system, which is the pre-production test system in this example.

After the ZIP file is copied to the pre-production test system, the changes can be imported into the target system. As with the import into the integration system, the import command requires a path to the ZIP file on the local system. After the import succeeds, the changes should be available on the target system. In this example, the new profiles and policy access control rules are added to the system.

Because the export from the integration system and import into the pre-production system was done using the synchronized mode, objects are matched using internal object identifiers. In the example, new objects are created so no matching is required. If updates had been made to existing objects, they would be automatically matched because the source and target systems originated from the same system.

As with the import into the integration system, the changes made to the pre-production system should be tested. When that succeeds, the final step in the process is to export from the pre-production system and import into the new production system. When the import succeeds, the changes are available to all Windchill users. That process is the same as exporting from the integration system and importing into the pre-production system.