FEDERATION AND REPLICATION Created by “THE ONE”

INTRODUCTION Federations and Replications are two key Documentum Administrative Features for Distributed work environments. Docbase Federations provide capability to globally manage user, groups and ACLs for multiple repositories/docbase from a single location. So to say with the help of this feature you can from one Primary Docbase manage multiple Docbase user accounts, groups and permission sets. On the other hand Replication synchronizes changes across multiple docbases.

What is Federation Federation is an administrative feature whereby Documentum propagates any changes you make to user, groups and ACLs of a single “governing” docbase, to the Federation’s other member docbases. The advantage of this is that it provides a single location from where user, groups and ACLs can be maintained within a collection of docbases and due to this centralized management, administrative work for user, groups and ACL management tasks becomes very simple in a complex distributed environment, hence reducing the administrative cost and time and increasing the overall productivity. Hence you should always opt for this feature in distributed architecture to automate the task of keeping the users, groups, and external ACLs matching in all repositories. NOTE: One enterprise can have multiple Docbase federations, but each Docbase can belong to only one federation.

Benefits And Best Use BENEFITS In a multi-Docbase distributed configuration, users are typically working with objects from more than one Docbase in the same session. The objects may be the original objects, reference links, or replica objects. In all cases, to maintain data consistency, object type and format definitions should be the same across the Docbases. Similarly, to maintain consistent security, the definitions of users, groups, and ACLs should be the same across the Docbases. In multiple Docbases scenarios keeping objects synchronized manually for each Docbase can be time consuming and error prone. A Docbase federation automates much of the process. The governing Docbase automatically propagates changes you make to users, groups, and external ACLs to each member of the federation. BEST USE Docbase federations are best used in multi-Docbase production environments where users share objects among the Docbases.

REPLICATION Replication is a solid administrative feature of Documentum that becomes to be very useful in a distributed architecture wherein the docbases within the organization need to be in sync with each other. E.g. an organization has 3 docbases within themselves each docbase located at different place say U.S, India and Europe. Now there are certain documents that need to be updated at each location no matter where the document is created or updated from. So if there are thousands of changes happening to a docbase on daily basis, it would become very difficult if each change done to one docbase has to be been manually set in another docbase. Replication ensures that changes at one docbase are always updated in other docbase when the replication job runs. Content Server provides automatic replication, through the ContentReplication tool, on-demand replication, using the surrogate get feature, OR manual replication, using the REPLICATE or IMPORT_REPLICA administration methods. An environment utilizing replication allows you to have separate docbases, each with a unique name and id, but with some of the same object. You can replicate both objects and the content of the objects

BENEFITS AND BEST USE BENEFITS Replication can reduce network traffic because users access local replicas of the objects for most operations. This is most beneficial during peak usage times. BEST USE Use object replication if you want local autonomy—if your wide area network (WAN) is not always reliable. If objects are replicated into a Docbase, users can continue to work even if the replica object's source Docbase is not available.

REPLICATION (Codepage) Because object replication uses the dump and load operations, the databases of the source and target Docbases must either use the same codepage or the target database must be using Unicode. For example, if the source database is using Japanese and the target is using Unicode, the replication operation succeeds. However, if the source is using Unicode and the target is Japanese, replication fails.

Setting Up Sample Environment We can setup a sample environment to see how exactly the both Features work. In this environment will include 3 docbases, spread across two physical machines. First, a "Governing Docbase" will be created. This is a small, empty docbase without any applications connecting to it. Its sole purpose is to be a single entry point for the creation of or modifying of users, groups and ACLs. Such a Docbase has the advantage of small size, making backups easier, and supporting jobs are run in a quiet Docbase rather than a big, busy Docbase. If you are creating a federation from a group of existing Docbases, choose the dominant Docbase as the governing Docbase. The dominant Docbase is the Docbase in which the majority of users are already defined as Docbase users. A Federation will then propagate these changes to the other two docbases (Docbase A and Docbase B). We will then setup a replication job to replicate content between DocbasesA and DocbaseB. All of the content in DocbaseA would then also be available from DocbaseB

Sample Distributed Environment (Cont.)

FEDERATION SETUP All docbases in a Federation must project to the same docbroker. Each docbase may project to additional docbrokers as well, but at least one of those must be shared between all of the docbases within the Federation. Furthermore, a docbase can only belong to one Federation. In our example, we will be using Server1 as the shared docbroker. Then, from Documentum Administrator, we go to Administration:Configuration:Federations. From there, you can choose File:New:Federation. You will be asked to select the name and login information for the governing docbase. You will then be asked to name your Federation. The naming of the Federation is purely an administrative issue, so pick something user friendly. Documentum gives you the ability to limit the users that get replicated to a specific user subtype. In our example, we do not have any user subtypes, and therefore we will be replicating all users One of the options in the Federation wizard when you check allows you to consider all the user and groups globally. You would want to check that option in order to propagate the user, groups and ACL changes from global governing docbase to all its member docbases

FEDERATION SETUP (cont.) Lastly, you will need to select the other member docbases for your Federation. We will add DocbaseA and DocbaseB to our Federation through the next Documenutm Administrator screens. This process should be fairly self explanatory. You will need to click the "Add" button to be presented a list of docbases you can add to your Federation

REPLICATION SETUP There are several ways to replicate content The ContentReplication tool provides automatic replication on a regular schedule. This tool is implemented as a job. After you define the parameters of the job, the agent exec process executes it automatically on the schedule you defined. The surrogate get feature provides replication on demand. If you use surrogate get, when users request a content file that isn't present in their local storage area, the server automatically searches for the file in the component storage areas and replicates it into the user's local storage area. For surrogate get, you can use the system-defined SurrogateGet method or you can write your own program. Either of two administration methods, REPLICATE and IMPORT_REPLICA, let you replicate content manually. You can get the exact syntax of these methods from DQL Reference Guide Page 295 and 234 respectively

REPLICATION SETUP (cont.) So in the above scenario if you want to setup up a replication, u need to create a replication job that would copy objects from DocbaseA to DocbaseB. Hence the first step would be to log into DocbaseA through DA. Go to Administration -> Job Management -> Jobs and select File-> New->Replication Job from the menu. DA will present you with series of forms to configure the job like the Job Name and Description, Job Schedule, Tracing, From Source as well the Target as to where you wish to replicate the object. The frequency of job lets u decide how frequently you wish to run the job. In production environments, you would want to run such replication jobs at night times when the network is least busy

REPLICATION SETUP (cont.) The From Source docbase in above scenario would be DocbaseA. The main purpose of this configuration is to define the path location that will serve as the source of replications. This allows you to define only a certain part of the docbase to be replicated. Therefore, on this configuration, after inputting the user name and login information, be sure to click the "Select Path" link. This will take you to a docbase browser that will allow you to select the source location of your replication objects. In our sample, we will select the "Temp" cabinet. The "To Target" docbase, taking into consideration in above scenario would be DocbaseB. This has a few additional options. For example, you can define a target path, an owner, a permission set (ACL), and a storage area for the replicated content. These configurations are optional with the exception of the target path.

REPLICATION SETUP (cont.) Few Other Options are: Full Refresh - By default, replication is incremental. By choosing this option, you will instead get a full refresh. Full Text Indexing - Provides "same as source", "all possible", or "none" options. Security Option - "Preserve" and "Remap" options. You should refer to the Documentum Administrator Guide for a complete description of how this option works, but it basically allows you to either set a new ACL for replicated content, or attempt to keep the original ACL. Transfer Operator - The user who moves the replication dump file between the physical machines. Manual and automated options exist

WHAT IS REPLICATED The first time an object replication job runs, the job replicates all objects of type dm_sysobject and its subtypes that are linked to the source folder or cabinet (and any subfolders) specified in the job definition. The entire version tree for each object is replicated. However it is up to the system administrator or other person responsible for replication operations to determine which documents and folders should be linked to the source folder or cabinet and to ensure that the linking is done. The server does not select objects for replication. Additionally, the first run of a replication job also replicates certain objects that are related to the objects in the source folder or cabinet: All annotations attached to a replicated object All renditions of the replicated object If the replicated object is a virtual document, all of its components are replicated.. If the replicated object has an associated assembly, all of the objects in the assembly are replicated. What is replicated on subsequent runs of the job depends on whether the job is defined as fast replication or not.

IDENTIFYING REPLICATED OBJECTS Replica objects are identified in the user interface by a replica icon. Programmatically, you can identify a replica using the computed attribute _isreplica in Get method. This attribute is set to T for replicas.

REPLICATION (INTERNAL WORKING) How Does the Replication Process Work Internally? For replication, the method is the replicate_folder method, which is created as part of the replication installation and configuration process. The replicate_folder method runs the replicate_folder program, which is provided as part of Content Server. The replicate_folder program performs the actual work of replication. In the source Docbase, it dumps the source cabinet or folder to a file, performs delete synchronization, transfers the dump file to the target Docbase, filters the file, and loads the filtered file into the target Docbase. (Delete synchronization makes sure that any objects that have been deleted from the source Docbase are also deleted from the target Docbase.)

NIEL’s “CAN’T FAKE” TIPS Tip: Use a single, empty docbase as the governing docbase for your Federation. This way the administration of your Federation is not impacted by application issues, and vice-versa. Tip: For replication jobs that involve a large amount of content or have poor/unreliable bandwidth connections, you can use the "Manual" transfer option to move the content. This is often done by copying the transfer files to CD or similar media, and physically moving the replication files. Tip: Instead of one large job, break your replication down into multiple small jobs. This reduces the likelihood of failures during replication, and limits the cost of a failure to a smaller set of data.