Windchill replication increases user productivity by reducing the amount of time it takes to access data. Users access data that is stored on replica vaults, which are more rapidly accessible external vaults. Replica vaults store data that has been copied from slower external vaults (for example, because they are on a WAN) or from the Windchill database.

The only difference that Windchill users notice when accessing replicated data is that the access time is faster. Otherwise, the user experience is identical whether data is accessed from a replicated or non-replicated source. The Windchill user's only explicit interaction with content replication is setting preferences in the Windchill interface.

A Windchill site, also known as a cluster, is a group of hosts with one URL. For the purpose of content replication, a site can play the role of a master site, a remote site (formerly known as a replica site), or both. When a site is playing the role of a master site, content can be replicated from Binary Large Object (BLOB) storage, from external storage, or both to one or more remote sites. When a site is playing the role of a remote site, content can be replicated to it from master sites.

In general, a master site stores vault and folder configuration information for each of its remote sites. Remote sites retrieve vault configuration information on startup or an update of the information is pushed from the master site on its startup or sent explicitly by the master site administrator. However, a remote site can also be configured to have vaults and folders for designated master content. Similarly, a master site can be configured to include replica vaults and folders.

A remote site provides Windchill users with local access to content data in replicated vaults. The data in each replicated vault can come from only one master site. Attempts to disregard this rule can result in the loss of data.

The method servers of sites that are playing the role of master site or the roles of both master site and remote site must have a connection to an DBMS. A remote site can run in a lightweight mode, called Windchill File Server, which requires only minimal Windchill services that support the receipt of configuration information and the processing of requests to replicate or upload/download content. The advantage of running in File Server mode is that no database instance is needed and most of Windchill services are shut down, which provides easier maintenance and improves performance and startup time.

Windchill File Server is a remote site for Windchill. You install File Server using the File Server Management utility and PTC Solution Installer (PSI). You also use the File Server Management utility for post-installation activities and for implementing File Server.

For more information about installing File Server, see About the File Server Management Utility.

File Server Management enables you to install, configure, and maintain remote sites, including their vaults and folders.

The File Server Management utility provides the following functions:

When a File Server is downloaded and installed from a master site which is already using a maintenance release (not a base release), the maintenance updates are not a part of the downloadable installers. In these cases, the registration of the File Server with the master site fails. To correct this, you can install and register a File Server, then install directly from a maintenance release.

For more information about updating a File Server, see the Replication section of the Windchill Installation and Configuration Guide.

Windchill site, organization, library, and product managers are able to use the File Server Management utility. The site manager has full access. Organization, library, and product managers have limited access, which includes the following:

For more information about using File Server Management, see About the File Server Management Utility.

The security of data sent by Windchill content replication is ensured by a pair of keys associated with each master site server. A request sent by a master site is digitally signed using a private key, and the public key is a vehicle for authenticating that the private key used by the request is genuine. By using the master site’s public key, the replica service verifies that all the URLs from which to download originate from the master site. The same verification procedure is used during the replication process to ensure that the replicated objects came from a registered master site. The public key copied to a remote site must be genuine, and permissions should be used to protect it from being altered.

The clocks at the master and remote sites must be synchronized to ensure correct key validation. A difference of more than five minutes between the clocks may prevent validation. The URL of a replicated document expires five minutes after its creation. This five-minute period is the default setting, which you can modify on remote sites.

Content rules for replication can be defined on the basis of domain, class, and life cycle state. The targets of these rules are replica vaults located on specific remote sites.

For example, consider two remote sites named site1 and site2. The engineers at site1 are collaborating on the generation of the design models of a part, while the personnel at site2 will sell the part. The sales personnel do not need the incomplete designs for the part, so two different vaults would be appropriate:

These rules provide engineers with local access to the content for all life cycle states of the part, and sales personnel with local access to complete parts.

You can create replication schedules to ensure that replication takes place at regular intervals. If you need to perform replication to address a specific need, you can also create a replication schedule that runs only once. Each replication schedule identifies the vault that will be replicated, the time that replication will occur, and whether the job will take place once or on a regular schedule. For jobs that occur on a regular schedule, you specify how frequently revaulting will occur (for example, weekly or monthly). Replication schedules are maintained on the master site.

Replication schedules are independent of each other. For example, you can force a replication to happen sooner than it was originally scheduled to happen by creating an additional replication schedule that happens immediately and occurs only once.

The master site contains information about the files that exist on the remote site, and copy of content from master site to remote site occurs only once unless replication is reset. Each Windchill user can specify a preferred site from which to attempt downloading replicated data. If the data requested does not exist at the preferred site, the data is downloaded from another site. If data is not available at a remote site, it is because the rules controlling content for the vault do not include the data or the data has not yet been replicated to the remote site.

When a Windchill user creates information, such as a part or document, content files can be associated with that object. Windchill file vaulting enables you to specify that content files for a particular type of object in a specific life cycle state should be stored with the object in the Windchill database or stored in an external container called a vault.

Each vault contains folders, which correspond to storage locations (such as directories) on the host system. Based on the Windchill administrator-defined vaulting rules, an uploaded file is stored in the file system location represented by the vault and folder.

For content replication (File Server and full-scale), remote vaults and folders must be created on the remote site.

The folder must be mounted to the hosts. A mount is the association between a folder and a host. When you create or update a mount, you specify a storage location on a host system.

It is important to note that content that is mastered in remote vaults is not indexed for search. For more information, see Windchill Index Search Overview for Administrators.