Available Resources
Documentum provides fairly thorough documentation on these features. However, that documentation is spread out among multiple sources. For more detailed information, you may wish to refer to the following documentation:
- Documentum Distributed Configuration Guide
- Documentum Content Server Administrator’s Guide
- Documentum Content Server Fundamentals
- Documentum Administrator Online Help (see Federations, see Replication Jobs)
Distributed Environment Overview
There are several different ways that you can setup a distributed architecture. These various setups are basically permutations of two basic features of Documentum.
The first concept is a Federation. A Federation is an administrative feature whereby Documentum propagates any changes you make to the users, groups and ACLs of a single “governing” docbase, to the Federation’s other “member” docbases. This provides a single location where users, groups and ACLs can be maintained within a collection of docbases.
It is a good idea to manage replicated environments through a Federation, as it helps ensure that the associated objects for a replicated object will exist in the target docbase. For example, if you replicate a document a different docbase, a Federation can guarantee the existence and the consistency of its ACL in the target docbase.
The second concept is Replication. This feature provides the ability to replicate Documentum objects between docbases. An environment utilizing replication allows you to have separate docbases, each with a unique name and id, but with some of the same objects. It provides for the replication of both the objects and the content of the objects.
Note that environments utilizing Replication are different from a Distributed Docbase architecture consisting of a Single Docbase and Multiple eContent servers. In the latter model, your architecture consists of one database at the master site with multiple distributed eContent servers pointing back to the single master database. When a docbase request is made, users will be interacting with their local eContent Server connected to the remote database. Content is served from the local server and a background job synchronizes the content across the various servers to.
Setting Up a Sample Environment
In this example, we will set up a simple test environment. 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. 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.
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.
Our test environment will look like the following diagram:
Figure 1:
Test Environment (Click to Enlarge)
Federations Setup
The first step in setting up our environment will be to create a simple Federation. This will allow us to manage our users, groups and ACLs from a single docbase.
All of the 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.
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.
Figure 2:
Test Environment (Click to Enlarge)
After selecting “Add”, you will be presented with a dialog to choose the specific docbases you wish to add to your Federation. Again, you will need to provide a superuser login for each docbase you add to your Federation.
Figure 3:
Test Environment (Click to Enlarge)
Replication Setup
Now we will setup a replication job that will copy objects from DocbaseA to DocbaseB. The first step in this process is to log into DocbaseA using Documentum Administrator. You will then want to go to Administration:Job Management:Jobs and select File:New:Replication Job from the menu.
Figure 4:
Test Environment (Click to Enlarge)
Documentum Administrator will present you with a series of forms to configure your job.
Figure 5:
Test Environment (Click to Enlarge)
One of these configurations will be the frequency of the job. You can configure the job to run as frequently as desired. For our test environment, we will run every 5 minutes so we can quickly determine if the job is functioning correctly. However, in most production environments, replication jobs are configured to run at night when the network is least busy.
We will be asked to define the “From Source” docbase, DocbaseA in our case. 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.
We will then be asked to define the “To Target” docbase, DocbaseB in our case. 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.
The “Replication Options” form provides the following options:
Figure 6:
Test Environment (Click to Enlarge)
- Full Refresh – By default, replication is incremental. By choosing this option, you will instead get a full refresh.
- Fast Replication – Fast replication does not replicate all relationships.
- Full Text Indexing – Provides “same as source”, “all possible”, or “none” options.
- Replication Mode – When combined with security options, this defines how the permission set of the object is set in the target docbase.
- 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.
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.
The final configuration, “SysObject Info” allows you to define some of the more basic attributes of the replication job, such as the name and a description of the job. You should provide a friendly name that helps administrators understand the purpose of the replication job.
Tip: If you are trying to synchronize your two docbases, you will also need to setup a replication job from DocbaseB to DocbaseA. To synchronize multiple docbases, you can setup a ring of replication jobs; A to B, B to C, C to A.
Ongoing Support
There are several places where you can get information on the status of your Federation/Replication activity. These are almost all available from Documentum Administrator. These resources are summarized in the following list:
- Look at the replication job under Job Management/Jobs and click the “information” icon. This will tell you information such as: Last completion date, next invocation date, runs completed, last return code (0 for success), and whether the job is active.
- Select the jobs checkbox, and select View/Report from the menu. This will provide you a complete log of all the replication jobs run. Note that you can set the “Trace Level” for a replication job from that job’s properties page. This setting will control the detail provided in the replication report.
- Look at the various Federation jobs: These include: dm_FederationStatus, dm_FederationUpdate, dm_FederationCopy, dm_FederationExport, dm_FederationImport. These are standard, out of the box Documentum jobs that support the Federation functionality. You can get a description of each job by looking at their respective properties pages.
