Archive for March, 2010

Configurational Tips for Documentum Webtop

March 30, 2010 Comments off

Below i tried to cover the scenario where multiple docbases are configured and provides a solution to various business requirements that may arise out of this kind of set up. It also illustrates the configurational change that makes webtop (till version 5.3 SP4) compatible with Internet Explorer 7.0.

1.   Accessing multiple docbases from single machine

Business Scenario: There are multiple environments (say Development, Test, Staging and Production). Each has its individual content server but the requirement is to connect to any one of these environment through a single application server.

Solution: Add the different docbrokers in dmcl.ini as backup. This allows the application server to connect to the docbase for which the login credentials are passed.

The content server requires user id, password and docbase name as the parameter for creating a session for the user. The request from application server first goes to the docbroker specified as primary. If the parameters passed in the request matches with that of the docbase listening on the primary docbroker, the session will be created otherwise the request will be forwarded to the backup docbroker specified in the dmcl.ini in the ascending order.

Configuration Text File

This solution works for the following scenarios:

  1. If the docbase name in the different environments is different (or even if the case is different i.e. docbase_name and DOCBASE_NAME are treated as different docbases).
  2. User id or login ticket is unique.

2.   Defaulting docbase on login screen in webtop

Business Scenario: Multiple content management applications are sharing the same set of content and application server. The docbase and webtop is separate for each of the application. The requirement is to default the docbase name in the webtop login screen for each of the application.

Solution: Add the following code snippet in the app.xml file located under webtop\custom folder.


        <!– Default domain and docbase to authenticate against –>




3.   I.E. 7 Compatibility

Add the following code snippet to app.xml file located under webtop\custom folder to make webtop (till version 5.3 SP4) compatible with Internet Explorer 7.0.








Unlocking Documents in Documentum using DQL and API

March 28, 2010 Comments off
The process which can be used to unlock the document is described in below flowchart. It is a two step process. In step1, we have to obtain the object ID of the document using DQL. In step2, Document has to be unlocked using API command.

Unlock Documents

Categories: DOCUMENTUM Tags: , , ,

Status of the Virtual Document and its sections

March 27, 2010 Comments off

A virtual document can have a particular status according to the modifications that can be made in the present documents in the virtual document. The virtual document can have 4 Statuses:

  • Unfrozen
  • Chilled
  • Published
  • Frozen.

Out of the four statuses Unfrozen and Frozen are the primary status and Chilled and Published are just intermediate stages.

When a Virtual document is unfrozen, we can make changes to the document that the virtual document points by checking out that document (Through VDM) and editing its contents. After the edition is done and the document is saved and checked back in then the Virtual document will now point to the new version of the document so that the changes come into effect and not the old version.

When a document is frozen then the links that point to the document are permanent. Once a new version of the document is created the link in the virtual document will still be pointing to the previous document itself (i.e. the document version that the virtual document was pointing to when it was frozen) .Even though the new version of the document will exist in the repository the virtual document will be pointing to the old version which the virtual document was pointing to when the virtual document was frozen.

A virtual document status can be promoted from unfrozen to frozen or demoted from frozen to unfrozen. Even each section of the virtual document can be frozen or unfrozen individually.

 The most important feature of documentum is that it is customizable and so the company or individual purchasing it can customize the application according to his own convenience.

Virtual Document Manager

March 27, 2010 Comments off

One of the most important feature in documentum is the virtual document manager. Virtual document is a document which enables the user to link several related documents together.

 In a virtual document there are links to many related documents which together will constitute a single document known as virtual document.

 A virtual document does not actually contain any documents .It consists of the links to the various documents. The documents will remain in their original position in the repository and the link to that position is copied into the virtual document so that when we click on the document inside the virtual document the document will be displayed from the original location itself. The document link is can be put in the virtual document simply by dragging it into an empty position. Also documents can be added and deleted from a virtual document section.

A virtual document will consist of the following parts:

1. Assemblies-A virtual document itself is an assembly of related documents. This virtual document will consist of many subassemblies inside the main assembly. An assembly is a collection of a group of documents which are linked to each other in a more granular level. Each individual assembly can be saved separately or can be stored as a whole along with the main virtual document assembly.

2. Sections-A section is a part of a virtual document which is a collection of many related assemblies. A section is somewhat similar to the cabinet in a wardrobe. Each virtual document will have many sections containing many assemblies. The status of each section can promoted or demoted.

3. Links to related documents-Each document shown in the virtual document is not a copy the actual document; instead it’s a link pointing to the original document inside the repository.

Renaming Users Using Documentum Administrator

March 25, 2010 Comments off

While supporting Documentum, there can be a complex situation where we have to rename the user and reassign all objects where user was the owner or a participant to the new name. Following are the list of objects which needs to be changed.

  • ACL (Active control List)
  • Alias Set
  • Sysobjects
  • Workflow and related objects
  • Routers
  • Activities
  • Workflow
  • Workitem
  • dmi_queue_item
  • Groups
  • dm_registered
  • dm_type
  • dmi_type_info

All these things except last 3 can be changed at one shot using “Reassign” tool of Documentum Administrator. The last 3 items needs to be reassigned manually. The process for using reassign tool is as in below.


The process which can be used to rename the user is described in below flowchart. It is a two step process. In step1, we will analyze the effects of renaming the user.


 In step2, we will go ahead and rename the user.


User Management using Documentum Administrator

March 24, 2010 Comments off

Documentum Administrator is the Web-based tool for administering Content Server. By Documentum Administrator all the administrative tasks for a single installation or a distributed enterprise can be performed from one location.

One of the administrative tasks of Documentum Administrator is User Management. To access a Docbase, a person must be defined as a user in that Docbase.

The Administration/User Management displays a list of users in the current Docbase. Search for users can be done by their user name in the Docbase, user OS name (name on the operating system), or default group.

How to locate users in Docbase

1.  Connect to the Docbase where we want to locate a particular user.

2.  In the left-hand pane, click Administration.

3.  Click User Management.

4.  Click Users.

5.  To search by user name, user OS name, or default group, type in the information and click   Go 

 How to create new users

One must have Sysadmin or Superuser privileges to create users.

1.  Connect to the Docbase where we want to create new users.

2.  Click Administration –> User Management.

3.  Click File –> New –> User. (Check Right Hand Side)

  4.  Indicate whether the user’s state is active or inactive. An active user can connect to a    

     Docbase whereas an inactive user cannot.

5.  In the Name field, type the user’s name.

6.  Select a User Source from the drop-down list.

  • UNIX Only: Select this for the default UNIX user authentication.
  • Domain Only: Select this if the Docbase has Windows domain authentication enabled and the user must be authenticated against a domain.
  • UNIX first: Select this if the Docbase has Windows domain authentication enabled and the user must be authenticated first against UNIX, then against a domain.
  • Domain First: Select this if the Docbase has Windows domain authentication enabled and the user must be authenticated first against a domain, then against UNIX.
  • LDAP: Select this if users are authenticated against an LDAP server.

7.  In the E-Mail Address field, type the user’s email address. This is the address to which  

     notifications are sent for workflow tasks and registered events.

8.  In the User OS Name field, type the user’s operating system user name. This is used by the 

     user to login to the docbase.

9.  In the Windows Domain field, type the user’s Windows domain.

10. Select a home Docbase for the user.

11. Designate the user’s default folder which is the default storage place for any object the  user creates. To use an  existing Docbase folder, click Choose existing folder and to create  a folder with the user’s name, click Choose/Create folder with user name.

12. Click Select Group and select a default group for the user.

13. Click Select Permission Set and select a default permission set for the user.

14. Select the user’s privileges from the drop-down list.

User privileges authorize certain users to perform activities that are required to administer and maintain the system. The privilege levels are:

  • None
  • Create Type
  • Create Cabinet
  • Create Cabinet and Type
  • Create Group
  • Create Group and Type
  • Create Group and Cabinet
  • Create Group, Cabinet, and Type
  • System Administrator
  • Superuser

15. Select the user’s client capability from the drop-down list.

 There are four types of users:

  • Consumer
  • Contributor
  • Coordinator
  • System Administrator 

16. Click Finish and new user is created.

How to delete users

We can remove users from the Docbase, but Documentum strongly recommends making users inactive rather than deleting them from the Docbase.

 When a user is deleted, the server does not remove the user’s name from objects in the Docbase such as groups and ACLs. Thus when we delete a user, we must also remove or change all references to that user in objects in the Docbase.

DCTM Architecture

March 23, 2010 Comments off

Documentum Architecture

Docbases are supported by a three-tiered architecture , as in below figure.

• At the top level, client applications allow users to create, edit, and view documents and modify metadata.

• At the middle level, Content Server handles requests from Documentum client applications. Application logic is located on the server, and RDBMS calls are made using server API calls.

• At the bottom level, the RDBMS server and the operating system handle requests from Content Server and store information on the file system or in RDBMS tables.


%d bloggers like this: