Complex Windchill Deployments
The following graphic illustrates an example of a complex Windchill deployment with development, integration, test, and production systems.
In this scenario, the production system data and configuration have been cloned to the pre-production and integration systems using the Windchill Rehost Utility. The rehosting action is represented by the orange arrows at the top of the diagram. Initially, the integration system, pre-production test system, and the production system are identical. There are also multiple developer systems that are created individually and do not have all of the data and configuration from the production system. Often these developer systems are hosted locally on a developer’s own computer, which would not be able to store all of the data stored in a production environment.
 | The rehosting action is available in the selective mode. While performing BAC rehosting, you must include the WPA module because it creates the PTC_WNC_internal repository in the target system. After rehosting, verify that this repository is created and the GUIDs listed in the local repository of the source and target systems are the same. |
Before making administrative changes to the system, a baseline is established on every cloned, or synchronized, system from which administrative changes are exported. In the diagram above, the baseline is established for the integration system and the pre-production test system. The production system does not need to have a baseline established because changes are not exported from the production system. The developer systems do not need to have a baseline established because they do not have common data from the other systems. After establishing a baseline on the required systems, another command is run on these same systems to register other systems as target systems. For a developer system, this would include other developer systems and the integration system. The integration system would register the pre-production system, and so on. After all systems have been registered, administrative changes can be made and tracked.
After changes to administrative objects occur and have been tested, the changes are exported to the next system in line using the business administrative change promotion command-line utility. The exported ZIP file includes all new objects that have been created and changes to existing objects that have occurred since the established baseline. The ZIP file can be copied to the next server in line and the changes imported to that system, where they are tested. The process continues until the changes reach the production system and are available to all Windchill users.
A diagram and extended example are available in the Example: Exporting and Importing Business Administrative Changes topic.