Windchill offers two technologies enabled by the same option that accelerate the handling of content data and expedite collaborative development.

Both technologies depend on a designated cache vault in the remote site. These technologies are transparent to the Windchill user and can be incorporated in applications. The technologies deliver the following benefits:

The following graphic illustrates how the local cache works:

Following is the key for the graphic:

The time required for a user to check in, create, read, and update files is reduced, because these interactions involve data on the rapidly accessible cache vault rather than the more slowly accessible vaults on the master site. Unless these content files were requested earlier, they are replicated to the master site according to the sysForceSync synchronization schedule.

For example, when a user of host G1 checks in data, the checked-in copy is stored in local cache vault E rather than master site vault A, which would be the check-in vault if the local cache enhancements were not enabled. The data will be copied from vault E to vault A when an applicable sysForceSync synchronization schedule becomes active or when a request for the data arrives at site sA.

If users set their content cache preference to the remote site that holds the local cache vault, they can access data located there more quickly than users who only have access to that data on the master site. For example, if a user on host G2 wants to access content checked in by a user on host G1, the content is downloaded from local cache vault E, rather than the less rapidly accessible vault A on the master site. Not only is the access time reduced, but the data is also available earlier because of the faster check-in time on local cache vault E compared to master site sA.

If the master site receives a request for data that exists only in the local cache vault, the data moves immediately to the master site to enable it to serve the request. For example, if the user on host G3 requests content that exists in vault E and does not exist in vault A, the content is copied to vault A, and the content is then downloaded to host G3. The content is not transferred automatically to site sH unless a replication rule is created to transfer the content.

Because this is transparent to Windchill users, there may be a need for clarification about whether data checked in to the local cache vault E has been copied to the master site sA. A utility that runs on the master sA site provides information about files that have not been copied to site sA yet. For more information, see the section Utility to Assist Backups in Administering a Local Cache Vault.

Maintaining two copies of data within the local cache vault protects it from loss or damage. Each local cache vault folder accessed by read and write operations can be associated with a folder that mirrors it when mount paths for both folders are specified in the same entry during configuration. If the folder that is accessed for read and write operations cannot be read, the contents of the mirror folder can be copied to the readable folder so that the read operation can continue. For example, the mount path g2e2 associates the readable folder E2 with the host G2, while the mount path g2e1 associates the mirroring folder E1 with the host G2. For more information about mirroring, see the section Establishing Mirroring in the Local Cache Vault in Administering a Local Cache Vault.

When content has been replicated from the local cache vault to the master site, it exists in both locations. If its structure in the local cache vault violates a rule, the violation is corrected when the rule becomes active.

Indexing is the collection of keywords from content to make it searchable. Data in the local cache is not indexed. Data is indexed when it moves from the local cache vault to the master site.

A download and upload JavaBean is available to implement the feature in applications. The Windchill Customization Guide describes this bean.