All About Documentum,DFC, DMCL, DQL,TaskSpace,WDK,Webtop,DA

When a document is deleted from Documentum, only the document's metadata is deleted. The content itself (i.e. the object pointed to by the dmr_content object) remains in the content storage area until the IAPI script generated by the dmclean utility is run. If the dmclean utility has not been run, it is still possible to recover the object's content file.

Note: The document's attributes cannot be recovered without going back to a database backup. Below is an outline of a strategy which can be used to do this recovery.


Recovering the Information of the deleted Object

1. The Following DQL will retrieve the object_ids that correspond to the content objects that have been deleted

select r_object_id from dmr_content where any parent_id is null

If you want to retrieve data for a particular client, you can extract the following information to create your DQL:-

a) What was the name of the object? This is the object_name attribute.

b) What format was the document? This is the full_format attribute.

c) What was the date/time of the last checkin? This is the set_time attribute.

d) What was the name of the client machine where the file was last checked in? This is the set_client attribute.


The DQL that will be created in this case according to your search criteria is as follows:-

select r_object_id from dmr_content where any parent_id is null and set_client = and full_format = and set_time > DATE('')


2. Using the Object Ids recovered the following IAPI needs to be executed to pick up the path and relevant information of the Object under consideration :-

API> apply,c,,GET_PATH
API> next,c,q0
API> get,c,q0,result

This returns the file system path to the object. For example:

/disk2/dm20/data/solar20o/content_storage_01/00000065/80/00/14/07


How to restore the Document

To be able to restore the document back to its original location, you will need to firstly create a document object of the deleted type using the IAPI :

Creating a new dm_document object using IAPI
API> create,c,dm_document
0900006580005a65.


Setting the name of the Deleted object
API> set,c,,object_name
SET> Restored Document
OK

Linking the deleted file to the newly created object
API> setfile,c,,/disk2/dm20/data/solar20o/content_storage_01/000000
65/80/00/14/07,
OK

Linking the object to a directory in the Cabinets where the file will be restored
API> link,c,,/Temp
OK

Saving the file
API> save,c,

This will restore the deleted document at the location /Temp with the name Restored Document

How to configure LDAP Object in Documentum

To setup an LDAPConfig Object and import the users you may follow the steps documented in the eContent Server Administrator Guide, Appendix C, "Using an LDAP Directory Server". However, please note the following three items that are not detailed in the documentation.

1. You must provide an email address in the LDAP server and LDAP Configuration object in Documentum Administrator (DA).

2. Use groupofuniqueNAMES instead of groupofuniquemembers. The groupofuniquenames is defined in the schema, where as the groupofuniquemembers is not.





STEPS FOR TESTING LDAP FUNCTIONALITY:

Below is the procedure for testing the LDAP functionality briefly without checking in detail.

1. Install Netscape Directory Server on NT or Unix. A schema is made automatically when you install LDAP server.


2. Add a user and group into LDAP Directory Server, by Netscape LDAP Directory Server, and PLEASE PROVIDE EMAIL ADDRESS.


3. Make an LDAP Configuration object in a Docbase, using DA. Below is a sample of the setting:



Hostname : your computer name or IP address where LDAP server runs,

Port : default 3891 Note but it depends on your LDAP Server so consult the LDAP team for this.

Person Object Class : person

Group Object Class : groupofuniquenames [NOT groupofuniquemembers]

Person Search Base : o=xyz.com (This is the domain name of the computer where LDAP server is installed.)

Group Search Base : o=xyz.com (Same as Person Search Base)


Enabling LDAP Changelog Information : uncheck


Name : uid

OS Name : uid

Email Address : mail


4. Restart Docbase


5. Run LDAPSynchornize job


6. Check whether users and groups defined in LDAP server are imported into the Docbase in DA.


7. Try to connect to the Docbase with Intranet Client (IC) or Desktop Client (DTC) as the user defined in LDAP Server.



Again, the following items are correction or clarification to the documentation:

1. Provide an email address in the LDAP server and LDAP Configuration object in Documentum Administrator (DA).

2. Use groupofuniqueNAMES instead of groupofuniquemembers. The groupofuniquenames is defined in the schema, where as the groupofuniquemembers is not.

3. Restart Docbase once you have created a LDAP Configuration object.

Please feel free to given feedback/comments/suggestions/improvements.

All About Dump and Load in Documentum for Docbase Migration

-Dump and load is a feature built into Documentum.
- It allows you to take the entire contents of your docbase, and write them out to a single file. This can be done not only for content, but for users, groups, acls, etc.
-The file that gets written out is in a proprietary format, so the only thing you can do with it is load it into another docbase, thus "dump and load".
-However, this feature is often used for:
• Backing up your docbase (although you will still probably want a more reliable backup process, like a file system backup).
• Moving or copying your docbase to a new machine or environment (ie, creating a test docbase from your production docbase).
• It is also frequently the recommended upgrade path when moving to a new version of Documentum's server product.

- Run dm_clean,dm_logpurge,dm_filescan before dumping a Docbase. This avoids dumping unwanted objects.

- Docbase should be down.

- Should not be used by users.

- All jobs which are active must be inactive.

Dump:
-The most common method for performing this is using Documentum's API interface.
-On the server that Documentum is installed you will find a file called iapi32.exe.
-Look in your Documentum server directory under product\4.x\bin. Run this application from a DOS window.
-It will prompt you for the docbase you wish to connect to, as well as a username and password.
-Connect to the docbase you wish to dump.
-You will soon be at an api command prompt.
-From this prompt, you can issue any of Documentum's api commands.
-In this case we will be issueing the command to create a dump file from the docbase you are currently connected to.
-In most cases, the following set of commands will dump all of your relevant information out of your docbase.
- It will extract all of your content objects (and their content), as well as your formats and users and any kind of objects with thier data :

create,c,dm_dump_record
set,c,l,file_name
c:\path\fileName.dump
set,c,l,include_content
2=2

append,c,l,type
dm_sysobject
append,c,l,predicate
2=2

append,c,l,type
dm_format
append,c,l,predicate
2=2

append,c,l,type
dm_user
append,c,l,predicate
2=2

append,c,l,type
dm_assembly
append,c,l,predicate
2=2

append,c,l,type
dm_group
append,c,l,predicate
2=2

append,c,l,type
dm_relation
append,c,l,predicate
2=2

append,c,l,type
dm_relation_type
append,c,l,predicate
2=2


append,c,l,type
dmi_queue_item
append,c,l,predicate
2=2


And so on , write the above command for all the object types you want to
export.
#
# NOTE: also dump any user defined non-sysobject types.
#
save,c,l
getmessage,c


-This script dumpts all dm_sysobject objects, dm_format objects, and dm_user etc, objects from you docbase.
-Also the content of these objects will be included.
-You will notice that for each object type we append a predicate of "2=2".
-Since the predicate is required, this is a way of tricking Documentum into exporting all objects.
- You could have used other criteria, such as:
• object_name='xyz'
• folder('/folderName1',descend/)
-Once the dump is complete, you will have a file c:\path\fileName.dump that contains all of your docbase information.
-This file can then be loaded into a new docbase of your choice.

Please feel free to comment. i would like to hear more suggestions,improvements for this

How to manage the User cabinet’s visibility to users in Documentum Server?

Scenario1: Only owners will be able to see their cabinets , not even super users and System administrator will be able to see their cabinets.


1: Make is_private = 1 which is by default


Scenario 2: Some group (admin users or some other group of users) wants to see the cabinet of all users

1: Make is_private = 0 attribute of the dm_cabinet objects.
2: Create a default_user_cabinet_acl
Where
Dm_world = none
Admingroup = read
Owner = delete

3: apply above ACL on all the cabinets
4: you can apply above created ACL on the dm_cabinet type so that whenever a new cabinet is created, this ACL is applied automatically, One advantage of this approach is , you can change this ACL at anytime and all the cabinets will be affected by this change for example, you want to add one more group of users who wants to see all the cabinets in your organization like managers than you can add that group to this acl and assign them access.

Scenario 3: When you are integrating LDAP authentication and wants to create default cabinets for users.

1: you can create cabinet by mapping users
2: you can create cabinet by passing one more attribute to the
ldapjobSyn method
-create_default_cabinet true
Insert this before –full_sync =false/true parameter

This creates cabinet with the user’s last name, first name example Singh, Kulveer but in this case, the ACL which you created in Scenario2 was not applied to the cabinet even though you applied the ACL on dm_cabinet type itself, this is strange behaviour, I don’t know why Documentum does so.

OR
You can create cabinet by mapping LDAP attribute in LDAP config object

Goto DA->Basic Configuration->LDAP Servers->Mappting tab->property Mapping table-> Add new property

Where you can map dm_user objects default_folder attribute to the LDAP attribute for example

Default_folder = {$sn}

Refer Documentum Administrator guide for more detail regarding this LDAP mapping.

3: Step 2 will create cabinets only for the new users which are being pulled by the LDAP in both the cases but if you want to create cabinets for all the users which are already pulled into the Documentum than
A: Create users by script for existing users and make is_private = 0
OR
B: Delete all the users in Documentum and run the LDAPSync job and all the users will be created with their default cabinets. Note: you may loose some group and other ACL information which may be lost when you delete the users but it all again depends on your LDAP configuration.

4: in step 3 user’s cabinets are created but you have to run the script to make the is_private=0 and apply the ACL created in Scenario 2. This task can be done by creating job or changing the existing LDAPSync job to change the is_private=0 and apply the ACL . This totally depends on the complexity of your systems user base.

You can use any of the approaches based on your requirement and complexity of the system.

I would like to hear the comments for the above approaches. Let’s make it better by sharing our knowledge.

Check out this SlideShare Presentation:

Check out this SlideShare Presentation:

Check out this SlideShare Presentation:

Check out this SlideShare Presentation:

Check out this SlideShare Presentation:

DFC

What is Documentum?

Documentum is document management software that provides management of document content and attributes such as check-in, check-out, workflow, and version management. The Documentum product is a three-tier, client-server system built on top of a relational database.

A Docbase is a Documentum repository that stores document content, attributes, relationships, versions, renditions, formats, workflow, and security. Documentum Query Language (DQL), an extended SQL dialect, is used to query Documentum data. A Docbase is the equivalent of an Oracle instance or a DB2(R) database plus document content files. The metadata is stored in the underlying relational database management system (RDBMS), and the content is stored as binary large objects (BLOBs) in the database or as files stored within the file-system of the server system. For more information on Documentum, refer to the Documentum manuals.

The wrapper for Documentum allows you to add a Documentum data source to a DB2 federated system. By adding the Documentum data source to a federated system, you can use SQL statements to access and query objects and registered tables in a Documentum Docbase. You can then integrate this data with other data sources in your federated system without having to move the data out of the native data source. The Documentum wrapper uses a client library to interface with the Documentum server. The Documentum wrapper provides access to two versions of the Documentum server: EDMS 98 (also referred to as version 3) and 4i. Figure 2 illustrates how the Documentum wrapper works.