A replica gives you access in the current repository to an object in another repository by actually copying the object. The replica is linked back to the source object, however, and checking out the replica also checks out the source object.
Replicas allows users of different repositories to share documents over great distances. For example, you might use replicas if you have offices in California, Germany, and Japan that share the same documents. Replicas allows the same shared documents to be local to each office.
A replica can have both global and local properties. When you change a global property value, the value is changed in the source object and in any other replicas. When you change a local property value, the value is changed only in the current replica.
You can perform most of the standard file and folder operations on replicas. For example, you can export, copy, and check out replicas. You use the standard Webtop procedures to perform such operations.
Replicas are designated by a small, duplicate-icon overlay in the lower left side of the file icon. The overlay looks like a little copy of either the folder or document icon.
The Content Server uses automated jobs to synchronize replicas and source objects.
Note the following:
Replication jobs automatically synchronize the replica with the original file. You can manually synchronize the replica without waiting for the automated synchronization to occur by refreshing.
Any operations that modify an object are implicitly performed on the source object and the replica object is updated to reflect the change.
You should expect slower response times for any operations that change the source file (such as checking in), as the source file’s repository might be geographically distant from you. Any operations that do not modify the source file, such as viewing or exporting, are performed on the replica, so no connection to the source file’s repository is required.
When you copy a replica, the copy is not a replica but is a new file. Therefore, changes to the original document are not updated in the copy, as they would be in the replica.
If your WDK-based application supports translations, then when you create a translation you create a new file in the repository. You do not create a replica.
You can perform lifecycle operations on replicas that already have lifecycles applied to them.
In order for operations to succeed, repository configurations let you connect to the source file’s repository. The connection is made silently. You are not prompted to log in to the source file’s repository.
A replica can be created only if the repository where the original file resides and the repository where the replica resides have the same sets of users and passwords. Definitions in the target repository must be the same or supersets of those in the source repository. It is recommended the two repositories are set up under the same federation for consistent synchronization of users and permissions. For information on setting up replication services or workflow APIs, refer to the Documentum Content Server Administration and Documentum Content Server Fundamentals guides.
Web Publisher users only: Replicas are read-only, which means that operations that would change the content of the file in the source repository are prohibited. In particular, you cannot edit, check in, or check out a replica, as you are not allowed to make changes to it. Also, you cannot manually change the lifecycle of a replica.
Also, using the refresh option does not refresh relationships, just attributes.