Options Overview
Documentum provides the building block for implementing a variety of distributed architectures. The options can basically be broken down by one main dimension: those utilizing a single docbase, and those utilizing multiple docbases.
With a single docbase, you can provide access through any of the following methods:
- Remote Network Access – Using your existing network connectivity, simply access the existing docbase from the remote location.
- Remote Access, Web base client – Using your existing connectivity, access the existing docbase via a web based application running on an application server located in close proximity to the docbase.
- Single Docbase with Multiple Content Servers – The primary docbase maintains the document meta-data, but multiple “content servers” are located close to your remote users. Content is therefore stored at the location from which it is most frequently used.
- Single Docbase with Multiple Content Servers Using Content Replication – The content replications creates a copy of the content to store at each location.
- Export to File System – Push your content out of Documentum to a file system/database structure, and then access the information through a custom developed system. The export could be performed using Documentum’s Web Cache product.
With multiple docbases, you can implement:
- Multiple docbases using replication. In this case, replication is the process of creating copies of the entire docbase object (content and meta-data) at each location.
- Multiple docbases as a federation. A federation allows you to manage the users, groups, and ACLs for all of your docbases from the single “governing” docbase.
These options are not always exclusive, for example, your particular architecture may utilize a combination of these solutions.
Option One: Remote Network Access
In many instances, your remote location will have direct network access to your central docbase. If bandwith and latency issues are within acceptable levels, you can have the remote clients access the docbase across the WAN. This would be done by a standard install of the Documentum client (such as Desktop Client), and enabling direct network access to the appropriate Docbase and Docbroker
Figure 1:
Direct Access
This is a very simple solution, however it is highly reliant on the bandwidth and reliability of your WAN connectivity.
| Advantages | Disadvantages |
| Requires no additional setup beyond what you would provide for local clients. | Remote location’s network connectivity may not be reliable or have adequate bandwidth. These problems may be extreme enough to render the system unusable. |
| Minimal additional administration or support, beyond what you would provide for local users. | Upgrades to client applications at remote locations may be difficult to administer. |
| Doesn’t require any additional Documentum server installations. | If WAN connectivity goes down, then your remote users have no access to the system. |
Remote Access, Web Client
This option is very similar to the Remote Access just described, except using a web based client, such as a WDK application, to connect from the remote locations.
Figure 2:
Webtop Client
| Advantages | Disadvantages |
| No Documentum installation is required at the remote locations. The solution leverages your existing Documentum server installation and licensing. | Requires Installation and Administration of an application server and the web based application. This probably includes a dedicated physical machine to run the application server. |
| Minimal administration or support, beyond what you would provide for local users. | There still exists the potential for network problems to render the system unusable. |
| Browser based client makes upgrades to remote users easy to implement. | May create situation where you are maintaining two different clients. If you have customizations to the Desktop Client, you will now need to duplicate those customizations in the Intranet Client. |
| Provides the option of connecting remote users through the internet. | An additional physical machine will probably be required to run RightSite and Intranet Client Server. |
Single Docbase with Multiple Content Servers
If your locations typically access documents specific to that location, then you could implement a content storage architecture that attempts to store the content of documents closest to the users who most commonly access them. To do this you install “Content Servers” at the user locations. The location where Documentum e-Content Server, the docbase, and the database is installed is defined as the “Data Server”. Remote servers with an installation of E-Content Server and a local storage area are identified as “Content Servers”. Any requests from a remote location are routed to the Data Server. However, content is stored in the location where it is most likely to be used. This reduces network traffic between the remote locations and the data server location.
Figure 3:
1 Docbase with content servers
The installation of remote content servers provide you with added functionality and future flexibility. You have a greater degree of control over content in that you can restrict the server’s access to local content only and/or implement replication between the primary and remote sites at some time in the future.
| Advantages | Disadvantages |
| Improved performance as most content access is available from a local filestore. | Not practical if your content is frequently shared across multiple different locations. |
| Single point of management and maintenance for database and docbase. | User may still need to access content remotely, if they are accessing a document that is not stored at their current location. |
| Allows you to easily add content replication if needed (see next option). | Interruptions in connectivity between main and remote locations would render the system unusable, as data requests are still routed to the main content Docbase. |
| Documentum server installation is required on for each Content Server and Data Server. Thus additional DCTM Management required to configure remote Content Servers and Data Server. |
Single Docbase with Multiple Content Servers Using Content Replication
Documentum provides the ability to replicate content to one or more locations. This option entails a single docbase with multiple content severs just like in the previous option. However, you would make use of content replication functionality. To store a copy or a read-only copy of your content in each location.
Figure 4:
1 Docbase with replication
This allows you to support the situation where the same piece of content is frequently accessed by multiple locations.
| Advantages | Disadvantages |
| Single point of management and maintenance for RDBMS and docbase. | Requires installation, administration and maintenance to be performed at each location. |
| Provides good performance, even when some content is frequently viewed by multiple locations. | There are two ways documents can be replicated, scheduled or on-demand. If using scheduled replication, content may not be immediately available at remote sites. If using on demand replication, performance may suffer due to network limitations. |
| Remote access still depends on the connection to the central docbase, as all data requests are routed to the mail loaction. |
Export to File System
In this option, documents are entirely removed from Documentum, and exported to the file system. At the remote location, users access the documents on the file system or more commonly through a custom developed application.
Content is exported from the Docbase using either Documentum’s Web Cache product, or by using a custom solution. Web Cache exports the meta-data for a document to an SQL database at the remote site. The content is exported to a file storage location of your choice. This allows the client application at the remote location to perform searches or other meta-data related actions and to access the content in a standard manner.
The application at the remote site is commonly a simple web based application, with predefined forms for searching based on attributes or browsing the file repository.
Figure 5:
Export to file system
| Advantages | Disadvantages |
| Removes the requirement for a Documentum server installation at the remote location. | Does not provide update capabilities at the remote site. Remote sites generally would have read-only access. |
| Excellent performance at the remote locations. | Requires Documentum’s Web Cache or other solution to perform the extract from Documentum to the remote site. |
| Searching for documents at the remote location can be highly customized to the specific needs of that location’s users. | Requires a custom application or existing 3rd party product to access the meta-data at the remote location. |
| Remote user access is not dependent on the connection to the main location being up. | The remote location is not able to make use of some of Documentum’s key features, such as security and version histories. |
Multiple Docbases, Using Object Replication
In this model, an actual and complete docbase lives at each location. The docbases are synchronized with Documentum’s Object Replication functionality. This ensures that when a new document is created, it is replicated to each location.
Figure 6:
Multiple Docbase with replication
| Advantages | Disadvantages |
| Remote locations have maximum performance, as entire docbase is stored locally. | Requires a complete Documentum and database licenses at every location. |
| System will function even when connectivity between locations is down. Documentum will replicate changes when connectivity is restored. | Requires installation, administration and maintenance of DCTM server applications at each location. |
| Remote locations have all Documentum functionality, including ACLs, version history, etc. | There are two ways documents can be replicated, scheduled or on-demand. If using scheduled replication, content may not be immediately available at remote sites. If using on demand replication, performance may suffer due to network limitations. |
Multiple Docbase, Using Docbase Federation
This option is similar to option 2.6, however, a Federation provides some additional functionality. In this option, multiple docbases are bound together to facilitate management of global users, groups, and ACL’s. Users, groups, and ACL’s are automatically propagated to all of the docbases of the federation from the “governing” docbase.
| Advantages | Disadvantages |
| Same advantages as with the preivous model, with the added benefit of centrally maintained users, gropus and ACLs. | Same disadvantages as with the previous model, with some added complexity in setting up the Federation. |
Selection Framework
Can you use remote network access?
This is the simplest and cheapest solution. When looking at this option, consider the following factors:
- What is the reliability of my network connection from the remote locations to where my docbase is located? Compare this to the remote locations requirements for constant access, and possible frustration during network down time. For example, if your remote location absolutely must have 24/7 access, then you probably need to move to a multiple docbase or the export to file system model.
- What is the size of the files the remote location will be working with, and how often will they be accessing them. Compare this to the bandwidth of the network connection, and determine if the performance will be acceptable.
If you determine that you can use remote network access, then you need to decide which type of client to use (client/server or web based).
- Do you have an existing client that you built or customized. If so, ideally you will use that same client at the remote location.
- Does the client you hope to use behave well over the network. For example, how well will the client behave better over some intermittent networks.
- How easy will it be to administer a client at the remote location. Web based clients may be an easier solution if rolling out new applications to your remote site is an issue.
Do I need one or multiple docbases?
The main advantage of multiple docbases over a single docbase is that with multiple docbases, your remote locations are not dependent on having network connectivity to your main location. If the connectivity goes down, the remote location will keep on functioning off of its latest version of the docbase. If this is a requirement for you, then you probably want a multiple docbase solution.
Also, if performance is such an issue that you want all access to be performed locally (not just the accessing of content, but all calls to Documentum), then you probably require multiple docbases. You may be in this situation if:
- Your users are constantly performing network intensive activities to access the docbase. For example, a user whose entire job is to search for, view and update the properties of documents constantly throughout the day would probably require all Documentum calls to be local.
- Your network bandwidth is very constrained or unreliable during working hours, but have fewer constraints during off peak hours. This would allow you to perform replications and such during off peak, but not require any connectivity during peak hours.
I need one docbase, but can’t use remote network access
In this instance, your main decisions are:
- Where will my content stores be?
- Do I need any content servers in addition to my docbase server?
- Do I need replication?
The most important issue is to get the content close to the users who will be accessing it. So, if there is a logical divide between your content and the users of that content, then it should be easy to set up your content stores properly.
Suppose my New York office usually only uses the financial documents, while my LA office only access the marketing documents. In this instance, the content for your financial documents should be stored in New York, and the content for your marketing documents should be stored in LA. This division could be done by object_type for example.
Now suppose that your LA office frequently views the financial documents. In this situation you probably need add replication to your configuration so copies of the financial documents would get replicated to LA.
I need multiple docbases
If you need multiple docbases, then you need to determine if object replication or a federation will meet your needs. The issues to consider include:
- Will I benefit from centrally managed users, groups and ACLs? This is often helpful if you are replicating content, as it ensures that the target docbase has the same users, groups and ACLs as the source docbase.
- Do I need to give all locations the ability to edit a given document, and then have those edits propagated back to all the docbases?
- Is each document owned or mostly accessed by a single location. Do the other locations mostly just need it for view only purposes, or do they need update capabiliy as well?
