dm_notes: Documentum Notes

October 16, 2007

Object Fetch Vs DQL Fetch Performance

Filed under: dfc, notes — Tags: , , — Raj V @ 7:22 am

A Object Fetch call would retrieve all attribute information of the object from server, this information will then be cached on the client side DMCL cache.

A DQL query will only retrieve the attributes specified in the “select” statement of the query.

A dm_document object has around 70+ attributes. If you are only interested in few attributes of an object you should use a DQL statement to avoid retrieving unnecessary information, this becomes significant especially in a low bandwidth environment.

Object Fetch should used when most attributes of an object are wanted, and/or that attribute information is repeatedly needed in multiple places.

Note that a DFC Session.getObject() call is effectively a fetch call, you should avoid creating a IDfSysobject with session.getObject() just to look at a couple attributes of the object, use query.execute(iDfSession, IDfQuery_DF_READ_QUERY) and specify the attributes of interest in the select statement of the query instead.

October 15, 2007

How to find if a document is a Virtual Document?

Filed under: dfc, notes, vdm, virtual document — Tags: , , , — Raj V @ 1:01 pm

A document is said to be a virtual document, if the value “r_is_virtual_doc” attribute is set to “1”.
If the value is set to “0” then it is not a virtual document unless “r_link_cnt” attribute of the object is greater than “1” and the object is not of type “dm_folder” or “dm_cabinet”.

If r_link_cnt is > 0 the object is a virtual document or a folder/cabinet.
“r_link_cnt” will never have a value of 1, because the parent of the virtual document is also considered a child. So if you add one component, r_link_cnt=2. If you add a second component, r_link_cnt=3, and so on.”r_link_cnt” attribute applies to dm_folder/dm_cabinet, indicating how many objects are linked to this folder.

Virtual Documents in detail

Filed under: dfc, vdm, virtual document — Tags: , , — Raj V @ 9:49 am

Ran through a good explanation on Virtual documents in EMC| Documentum Forums Link.

Excerpt from the forum (copied as is)
——————————

Inherently Virtual documents are complex. Assemblies add a little to that but here goes as simple as possible:

From the server object perspective, the dmr_containment object is the key to understanding Virtual Documents
dm_sysobjects
+ r_is_virtual_doc- A dm_sysobject in the Docbase becomes a Virtual Document if r_is_virtual_doc is set to 1.
+ r_link_cnt- Defines the number of components of the Virtual Document.
+ resolution_label- Defines the the version label for late-bound nodes of the Virtual Document. We will discuss this shortly.

dmr_containment objects
+ A dmr_containment object defines the link between the parent and child nodes.
+ parent_id- The Object ID of the parent node.
+ component_id- This is the chronicle_id, or original version id, of the child node.
+ version_label- Version label for the child component. This overrides parent’s resolution_label.
+ use_node_vers_label- If set to TRUE for early-bound components, the server uses the early-bound symbolic label to resolve late-bound descendants of the component during assembly.
+ follow_assembly- If set to TRUE, directs the system to resolve a component using the component’s Assembly (if the component has an Assembly).
Note that only the root node and the dmr_containment objects have attributes related to Virtual Documents. Because of this, the dm_sysobject can be the child of “thousands” of Virtual Documents without the need for setting “thousands” of attribute values for the object. The connection between the parent and child is maintained in the dmr_containment object.

When a parent node is versioned, new containment objects are created between the existing child node documents and the new parent version.
When a child node is versioned, no containment object is created. This is because the containment object links the version of the parent to “any” version of the child node. (Usually, the “CURRENT” version is requested but other options are available as will be described in the coming Binding section). This is accomplished by the containment object referring to the “chronicle_id” of the child node. The chronicle_id is the r_object_id of the first, original version of that SysObject.
The parent “edge” object contains the link information that relates the parent to “any” version of the child.

To DFC programmers, an “edge” is referenced using an IDfContainment or IDfAssembly reference.

Assembly
+ An Assembly is a “snapshot” of a version of a Virtual Document at the time it was assembled
+ Assembly Objects= dm_assembly on the server
+ An Assembly is a record or “snapshot” of a version of a Virtual Document as it existed at the moment of assembling versions of its parts. Each Assembly object (dm_assembly) contains static binding information between a specific version of a parent node and a specific version of a child node of a Virtual Document. Assemblies will be discussed in greater detail at the end of this module

There are two wrapper interfaces in the fc.client package that publicly expose the operations required to access the services of the vdm package. These two Virtual Document wrapper interfaces are:
+ IDfVirtualDocument – provides a tree representation of a Virtual Document. A Virtual Document tree is comprised of a collection of nodes. Each node object corresponds to a sub-component of a Virtual Document. The IDfVirtualDocument object tracks node changes and manages tree node dynamics as changes are made to the Virtual Document graph. (A Virtual Document is modeled as an “acyclic directed graph”. An object cannot directly or indirectly have itself as a child).
+ IDfVirtualDocumentNode – Represents a single node in a Virtual Document graph.

IDfAssembly – This class provides the functionality for the client to interact with dm_assembly objects in the Docbase.
IDfContainment – Represents a dmr_containment object.
IDfSysObject – This class provides the functionality for the client to interact with dm_sysobject objects in the Docbase. Use the asVirtualDocument() method to turn a dm_sysobject into a Virtual Document.

Fetching a Virtual Document using asVirtualDocument( “preferredVersion”,t/f), causes the system to populate a node tree corresponding to the binding criteria encountered when fetching the descendants of the Virtual Document. This procedure is called, “assembling” a Virtual Document. Until now we have avoided using that term to prevent confusion with this topic. “Assembling” is the act of populating a node tree according to the 6 binding factors mentioned earlier. The purpose is to obtain a “version” of the Virtual Document. The node tree is a “versioned” node tree.
Assemblies allow you to “record” the collection of ObjectIDs from a versioned node tree. You would want to do this if:
A) You would like a “shortcut” to a version you reproduce often.
B) You need to lock certain child object versions from being deleted in order to guarantee the ability to reproduce the same version of the child nodes in the future.
Note: Although the current version of DFC does not support creating assemblies of XML documents, you may find them useful to create a Virtual Document from various Docbase objects.
Tip: An alternative approach to creating assemblies is to use version labels (like, “Assembly 1”) and binding to retrieve specific past versions of the graph. This hint may be useful until DFC supports assemblies of XML documents.

Assembly Objects
An Assembly, therefore, is a recording (or “snapshot”) of a version of a Virtual Document. It is comprised of a collection of Assembly object elements. Each Assembly object in the Assembly collection references one version of one component (sysObject) of the Virtual Document. For each node in the Assembly collection, an “Assembly object” exists in the Docbase server. An Assembly object is actually an instance of “dm_assembly” and contains the absolute ObjectID of the version of the sysObject referenced by that node in the versioned Virtual Document.
Each “dm_assembly” object has fields that are used when fetching the Assembly collection in the future. All Assembly objects of the same Assembly have the same value for their “book_id” field. The book_id is the objectID of a unique sysObject chosen to act as a “handle” for that snapshot.
You can associate the collection Assembly objects with a single sysObject by calling:

Assembly Document
The Assembly collection is conceptually accessed from the Docbase server as a single unit using a unique sysObject we term an “Assembly Document”. An Assembly Document is a unique sysObject (specific version of a document) that refers to that “snapshot” (collection of Assembly objects). It is the sysObject passed to the node.assemble() method.
An Assembly Document can only reference one collection of Assembly objects at a time. Therefore, make sure that the sysObject passed to the assemble() method is not already associated with an Assembly or you will lose the previous Assembly.
The Assembly Document (or “book“) can be either the sysObject referenced by the Assembly’s root node or some other sysObject. However, since an Assembly Document can only reference a single Assembly, a separate Assembly Document would be necessary when multiple assemblies from the same Virtual Document are required in order to avoid overwrite.

Re-Assembling
When the Assembly is requested in the future, the system looks for the dm_assembly objects that share the same “book_id” value and fetches the sysObjects referenced by the “component_id” of that dm_assembly object.

IDfSysObject doc =   sess.getObject (  new   DfID ( "09001234567890ab" ) );
IDfSysObject aDoc1=  sess.getObject (  new   DfID ( "0900ba0987654321" ) );
IDfSysObject aDoc2=  sess.getObject (  new   DfID ( "0900ba0987654322" ) );

In this example, three documents are fetched from the Docbase. “doc” is a Virtual Document. aDoc1 and aDoc2 are generic document objects.
The “doc” object refers to a Virtual Document but does not actually populate the node tree until asked to do so.

IDfVirtualDocument vDoc =  doc.asVirtualDocument (  "Released" ,  false  );
IDfVirtualDocumentNode node =  vDoc.getRootNode ();
 node.assemble ( aDoc1 );

Here, the node tree is finally populated using the binding criteria starting with “Released” as the preferred version. As you can see from the table on the left, the different nodes did not all retrieve the “Released” version of each child. This is because of the binding criteria as well as settings in the nodes (such as early binding) may override the preferred version. Once all the child nodes are assembled, that collection of objects is recorded by calling node.assemble( aDoc1 ). This sets a value in the aDoc1 object as a reference to the collection of the bound version of the object at each node.
aDoc1 is the Assembly Document for the “Released” version of Virtual Document “A”.

IDfVirtualDocument vDoc =  doc.asVirtualDocument (  "CURRENT" ,  false  );
IDfVirtualDocumentNode node =  vDoc.getRootNode ();
 node.assemble ( aDoc2 );

Here, another version of the node tree is populated (assembled) using the binding criteria starting with “CURRENT” as the preferred version. As you can see from the table on the right, the different nodes did not all retrieve the “CURRENT” version of each child. This is because of the binding criteria as well as settings in the nodes (such as early binding) may override the preferred version. Once all the child nodes are assembled, that collection of objects is recorded by calling node.assemble( aDoc2 ). This sets a value in the aDoc2 object as a reference to the collection of the bound version of the object at each node.
aDoc2 is the Assembly Document for the “CURRENT” version of Virtual Document “A”.

Sometimes a Virtual Document nests an Assembly within its hierarchy. When fetching a Virtual Document that potentially has sub-assemblies within it, it is often necessary to obtain the sub-assemblies.
When you include an Assembly Document as a node in a Virtual Document, you must decide if the Assembly components should replace that node, and any of its containment components, with the whole Assembly, or to ignore Assembly altogether.
+ The default is that the Assembly components should be ignored and instead the server uses the binding criteria to fetch the components referenced in the dmr_containment objects;
+ The node can optionally override the binding criteria so the server fetches the Assembly components based on the dm_assembly collection instead of the node or any of its virtual children.
To direct the server to use the node’s Assembly components, call node.setFollowAssembly(true).
If the node is not a Virtual Document, or it does not have children, or it does not have an Assembly, this setting on the node is ignored.

Freeze
+ Cannot add or delete components from the Assembly
+ That version of the component will be frozen
– Can’t change contents or attributes
– Assembly Document will be frozen
– Can’t change contents or attributes

Unfreeze
+ May add or delete from the Assembly again
+ That version of the component is unfrozen
– r_frzn_assembly_cnt = 0
– Can change contents and attributes
+ Only works if it is not nested within another frozen Assembly

Disassemble()
To remove the Assembly status from a sysObject and to remove all its Assembly objects, either call sysObject.disassemble() or node.disassemble(). You must have at least VERSION permission for the sysObject in order to delete its Assembly.
Deleting an Assembly will remove all the Assembly objects but does not remove the sysObject components of the Assembly objects.

Note: The ownership of the article lies with the Original Author and is here only as a reference.
The copyright laws applicable to this note are as defined by EMC Forums.

October 10, 2007

Documentum embraces Developers with Eclipse plugins

Filed under: dfc, wdk, webtop — Tags: , — Raj V @ 12:09 pm

Eclipse being the freely available favorite Java editor for many ( my preference goes to IntelliJ over any) and for sure there are many people who use Eclipse for Documentum Projects. EMC Documentum has embraced eclipse community with few plugins.

Next Step: EMC Documentum is coming up with Documentum Composer that will enable all sort of Documentum developmental activities.

Configuring WDK Development Environment in Eclipse

Filed under: documentum, wdk, webtop — Raj V @ 9:49 am

Abstract

This configuration guide is for developers who want to use the Eclipse IDE for WDK development. It discusses one approach for configuring Eclipse for WDK development.

Eclipse 3.1

Note: The configuration assumes that you do not have any plugins installed and that you have a base Eclipse install.

  • Click on the menu item ‘Windows->Preferences’.
    • From the tree view on the left hand side go to ‘Java->Compiler->Building’.
    • From right hand side unselect (clear) the ‘Scrub output folders…’ checkbox, which is under the ‘Output folder’ section. If this option is enabled then all standard WDK/Webtop classes will be scrubbed by Eclipse and you won’t be able to rebuild them if you don’t have the sources.
    • Click on ‘Ok’.
  • Click on ‘File->New Project’.
  • Select ‘Java Project’ and click on ‘Next’.
  • You need to create the project in an external location. There should be a ‘Checkbox’ that allows you to select this option and a ‘Browse’ button that allows you to browse-select the external folder.
  • Select the WDK/Webtop web application directory as the project folder. For example, <TOMCAT_HOME>\webapps\webtop.
  • Click on ‘Next’
  • Do not select any source folders right now. Leave the defaults.
  • Ensure that the output folder has been set to WEB-INF/classes folder. If not, browse and select it explicitly.
  • Click on ‘Finish’.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘New->Folder’.
    • In the ‘Folder name’ text box, name the folder (e.g wdKClasses). This folder will be added, in a later step, in the classpath of the project so that the existing WDK classes can be referenced.
    • Click on the ‘Advanced’ button (towards bottom of screen) and check (select) the ‘Link to folder in filesystem’ Checkbox. Browse and select the <virtual-root>\WEB-INF\classes folder.
    • The above procedure creates a new folder in the project space that points to the ‘\WEB-INF\classes’ folder.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘Properties’.
    • From the list on the left hand side of the ‘Properties’ window click on ‘Java Build Path’.
    • From the tabs on the right hand side select ‘Sources’. Select the PROJECT_NAME\custom\src as one of the source folders. You may add any number of additional source folders.
    • Now select the ‘Libraries’ tab and click on ‘Add External Jars’ button. Add the DFC-related jars and any other jars that you need.
    • In the previous step be sure to add the jars that contain the Java servlet and JSP classes. For Tomcat 4.1.30 on our machine, this jar was c:\Tomcat4130\common\lib\servlet.jar. For BEA 8.1 on our machine, this file was c:\bea\weblogic81\server\lib\weblogic.jar. For Tomcat 5.0.28 there are two jars, TOMCAT_HOME\common\lib\servlet-api.jar and TOMCAT_HOME\common\lib\jsp-api.jar
    • On the same tab click on the ‘Add Class Folder’ button and add the folder ‘wdkClasses’ that was created previously. This references all WDK\Webtop classes in the classpath.
    • Click on ‘Ok’

After completing this procedure, you can create your own classes and compile them. The results of compilation will directly go into the WEB-INF\classes folder just like the rest of the WDK/Webtop classes. You can also create XML configuration files and JSPs within the IDE using other Eclipse plugins for XML editing and JSP editing respectively. There is also a WDK Eclipse Plugin available on the Developer site.

Eclipse 2.1.x and 3.0

Note: The configuration assumes that you do not have any plugins installed and that you have a base Eclipse install.

  • Click on the menu item ‘Windows->Preferences’.
    • From the tree view on the left hand side go to ‘Java->Compiler’.
    • From the tabs on the right hand hand side select the ‘Build Path’ tab and unselect (clear) the ‘Scrub output folders…’ checkbox. If this option is enabled then all standard WDK/Webtop classes will be scrubbed by Eclipse and you won’t be able to rebuild them if you don’t have the sources.
    • Click on ‘Ok’.
  • Click on ‘File->New Project’.
  • Select ‘Java Project’ and click on ‘Next’.
  • You need to create the project in an external location. There should be a ‘Checkbox’ that allows you to select this option and a ‘Browse’ button that allows you to browse-select the external folder.
  • Select the WDK/Webtop web application directory as the project folder. For example, <TOMCAT_HOME>\webapps\webtop.
  • Click on ‘Next’ (or ‘Finish’ if it is enabled) and DO NOT select any source or output folders right now. Leave the defaults.
  • Click on ‘Finish’.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘New->Folder’.
    • In the ‘Folder name’ text box name the project (e.g wdKClasses). This folder will be added, in a later step, in the classpath of the project so that the existing WDK classes can be referenced.
    • Click on the ‘Advanced’ button (towards bottom of screen) and check (select) the ‘Link to folder in filesystem’ Checkbox. Browse and select the <virtual-root>\WEB-INF\classes folder.
    • The above procedure creates a new folder in the project space that points to the ‘\WEB-INF\classes’ folder.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘Properties’.
    • From the list on the left hand side of the ‘Properties’ window click on ‘Java Build Path’.
    • From the tabs on the right hand side select ‘Sources’. Select the PROJECT_NAME\custom\src as one of the source folders. You may add any number of additional source folders.
    • Now select the ‘Libraries’ tab and click on ‘Add External Jars’ button. Add the DFC-related jars and any other jars that you need.
    • In the previous step be sure to add the jars that contain the Java servlet and JSP classes. For Tomcat 4.1.30 on our machine, this jar was c:\Tomcat4130\common\lib\servlet.jar. For BEA 8.1 on our machine, this file was c:\bea\weblogic81\server\lib\weblogic.jar
    • On the same tab click on the ‘Add Class Folder’ button and add the folder ‘wdkClasses’ that was created previously. This references all WDK\Webtop classes in the classpath.
    • At the bottom of all the tabs there will be a text box that specifies the output folder. Select PROJECT_NAME\ WEB-INF\classes as the output folder.
    • Click on ‘Ok’

After completing this procedure, you can create your own classes and compile them. The results of compilation will directly go into the WEB-INF\classes folder just like the rest of the WDK/Webtop classes. You can also create XML configuration files and JSPs within the IDE using other Eclipse plugins for XML editing and JSP editing respectively. There is also a WDK Eclipse Plugin available on the Developer site.

Reference: Developer Center

Configuring Eclipse for DFC projects

Filed under: dfc, documentum — Tags: , — Raj V @ 9:05 am

Description

To setup a DFC development environment you will need at a minimum the dfc.jar and dfcbase.jar files. However, we recommend that you reference all the jar files in the folder that contains the dfc.jar file.
On Windows, this folder typically is c:\Program Files\Documentum\Shared.
In addition, you will need any classfolders and jars of your custom business objects. Another important component is the folder that contains the dfc.properties and the log4j.properties file. This folder needs to be in the classpath too.

Creating a Java project for DFC development in Eclipse 3.1

 

  1. Click on menu item File->New->Project
  2. From the ‘New Project’ window select Java->Java Project and then click on ‘Next’
  3. Enter a project name (example – ‘Simple DFC Project’). For sake of keeping things simple, keep the defaults for other options on this screen. Click on ‘Next’.
  4. Select the ‘Libraries’ Tab and click on the ‘Add External Jars’ button.
  5. In the ‘Jar Selection’ dialog navigate to the folder that contains the dfc.jar file. On Windows, this is typically c:\Program Files\Documentum\Shared . Select all (CTRL+A) the jars in this folder and then click on ‘Open’.Fig – Add DFC Jars
  6. Now, click on the ‘Add Class Folder’ button and then click on ‘Create New Folder’Fig – Add Class Folder
  7. In the ‘New Folder’ dialog give some name (e.g. ‘dmConfig’) and click on ‘Advanced’
  8. Select the ‘Link to folder in filesystem’ checkbox and choose the folder that contains the dfc.properties file. On Windows this is typically C:\Documentum\configFig – Link to the folder containing the dfc.properties file
  9. Click on ‘Ok’ in both the ‘New Folder’ and ‘Add Class Folder’ dialogs
  10. Again for the sake of simplicity, keep the default project settings and click on ‘Finish’.
  11. Eclipse will create a project with the default source and output folders. You can now create Java classes that use DFC in the project. To create a new class right-click on the source folder(or package) and select New->Class. To execute a Java class right-click on the class and select Run As->Java Application. For more details related to the Java development options, please refer to the Eclipse documentation.

Reference : Developer Center

October 5, 2007

Why do DQL queries sometime return blank duplicate rows?

Filed under: support note — Tags: , , — Raj V @ 12:39 pm

This may happen if you select from a repeating attribute (which is stored in the same underlying database table) and use the ORDER BY clause on the repeating column. Therefore, if one repeating attribute does not repeat as many times as another, it will have a “null” value for all rows where it has no value until it reaches the maximum number of rows for all repeating attributes of the object type.Note: Even if you specify “DISTINCT” in the query, there may appear to be duplicate rows, containing blank values as part of the repeating attribute column. However, this display is not the result of an error with the query. “DISTINCT” operates on all of the columns you specify within the “select” action; each of those columns in the result set, therefore is unique for the values in each row returned.

When executing a DQL query, sorting on a repeating value (e.g. “r_folder_path”) may cause “duplicates” of the objects to be returned such as those returned by the sample query below:

select object_name, r_folder_path from dm_folder ORDER BY r_folder_path or

select object_name, r_version_label from dm_document ORDER BY object_name

Returns “duplicate” rows of results in WorkSpace. The first half of the return values have the path field filled in. The second half of the returned rows do not. However, as explained above, the second half of the return can also be considered unique rows if the values in their corresponding columns are compared (e.g. a blank value is not the same as an actual value).

This is a side effect of the way DQL/SQL joins or maps the single and repeating-value tables when you employ the “ORDER BY” clause on the repeating field. The way DQL was intended is that every object in the Docbase has both an explicit “r_version_label” (e.g.: ‘draft’, ‘approved’, ‘new’) and an implicit “r_version_label” (e.g.: 1.0, 2.0, etc.) When the single and repeating tables are joined in a one-to-many relationship, at least two rows will result for each object.

To avoid this side effect, include in your “select” statement the “r_object_id” attribute and “order by r_object_id” clause. This pairing will force the master-detail relationship to be invoked since this attribute is common to both database tables and will result in only one row per object being returned. Notice that “r_object_id” in the example code below does not need to be first in either the “select” statement or the “order by” clause, but only be present somewhere in both elements:

select object_name, r_object_id, r_version_label from dm_document where owner_name = ‘charless’ order by object_name, r_object_id

This returns the object names, all sorted, with one object per row (no duplicates) and the “r_version” label information all concatenated onto one line. Instead of a row with “1.0” and another row with “CURRENT”, we now have “1.0,CURRENT” This is a feature of WorkSpace, which intelligently combines the results of the result set to remove duplicates if “r_object_id” is specified as an “order by” object.

Note: This only works if a single-valued attribute or “r_object_id” is first in the “order by” clause. If the repeating value is first, then all the values, including duplicates or blanks, are displayed in the result set.

What does Documentum recommend about deleting users?

Filed under: support note — Tags: , — Raj V @ 11:53 am

Note: Every SysObject or SysObject subtype in the Docbase has an attribute called owner_name that identifies the user who owns the object. We suggest deactivating users, rather than deleting them based on the following issues:

– Before deleting a user from a Docbase, you must update the objects created by the deleted user to change the owner_name to identify a different user. You do not need to change the owner_name if you deactivate the user.

– When you delete a user, the server does not remove the user’s name from objects in the Docbase such as groups and ACLs. It is possible to delete a user, and then re-create the user with the same name. However, if you add a new user with the same name as a previously deleted Docbase user, the new user will inherit the group membership and object permissions of the previously deleted user.

– You cannot delete the Docbase owner, installation owner, or yourself.

– When you no longer need a user account, deactivate the user. Deactivating a user is better than deleting a user. Once a user is deactivated in a Docbase, that user will not be able to log in to that Docbase. You must have Sysadmin or Superuser privileges to deactivate or reactivate a user.

– You cannot change the login state of the Docbase owner, installation owner, or yourself. You deactivate and reactivate users by changing the user’s login state using Documentum Administrator, DQL or the API.

– By default, users are active when you create them, so you do not need to activate new users. The user’s login state is tracked by the user_state attribute of the dm_user object. If you deactivate a user who is currently logged in, the change takes affect when the user next logs in.

– If necessary, a user with Superuser privileges can use a ticket to log in as a deactivated user, and a user with Superuser privileges can add a deactivated user to a group

NOTE: You can rename users to another existing user if necessary; this then deletes the original user. In our application it is our standard that every object should have someone who it belongs to, using renaming instead of deactivating accounts accommodates this requirement.

The users are created and authenticated at the OS level.

This is the way I intend to do this is by making all the object owners a user e.g. “system” and then we would delete the users that are not required from the Documentum system. This way all object owners would be “system” and whether or not the user is deleted from Documentum would not impact the system.

Note: This is a support note I found floating in yahoo groups. I am not sure of the support note no.  The EMC copyrights apply to this Note as it is authored by EMC.

Create a free website or blog at WordPress.com.