Using Java reflection to reduce Code and Development time in DFS


 

Java reflections are one of the most powerful API’s of Java Language, this can be used to reduce code significantly.

Most of the Current Enterprise application consists of different layers and they use Value objects to transfer data from one layer to another. An inefficient way of using getters and setters of the attributes of Value objects can increase code and development time of application. Effective use of reflection can reduce code and development time significantly.

So let’s take a Scenario,  I have an Object type MyObjectType extending from dm_document with 50 additional attributes, so dm_document as of Documentum 6.5 has 86 attributes adding additional 50 attributes that means we have 139 attributes for this object type. Consider a standard Web Application using DFS behind which needs to manipulate (add or edit) instances of this object type, The Service needs to add all these attributes to the PropertySet  of the DataObject representing that instance. Then need to call the appropriate service.

 

Considering that the bean instance name of MyObjectType is myObjectBean the Standard code will  be something like this

  ObjectIdentity objIdentity = new ObjectIdentity("myRepository");
  DataObject dataObject = new DataObject(objIdentity, "dm_document");
  PropertySet properties = dataObject.getProperties();
  properties.set("object_name", myObjectBean.getObject_Name());
  properties.set("title", myObjectBean.getTitle()); 
  // omited for simplicity


  objectService.create(new DataPackage(dataObject), operationOptions);

 

In the above code you have to explicitly set individual attributes for the object, the more the number of attributes the more complex and messy code.

Take another Example, where you have to retrieve an Object information and pass it over to the UI layer.

 myObjectBean.setObject_name(properties.get("object_name").getValueAsString());
 myObjectBean.setTitle(properties.get("title").getValueAsString());
 myObjectBean.setMy_Custom_Property(properties.get("my_custom_property").getValueAsString());

This operation can be more complex if you decide to use match the Data Type of your bean with the Object type.

 

So what is the best approach to reducing this complexity? the answer is the effective use of reflection API.

Let’s take a step to step approach to handle this issue.

To understand this better consider the below as the attributes of mycustomobjecttype

 

Attribute Name Attribute Type
first_name String
last_name String
age integer
date_purchased time
amount_due double
local_buyer boolean

 

Java Bean

Create a Java Bean that matches the Object Type

 public class Mycustomobjecttype {
  protected String first_name ;
  protected String last_name  ;
  protected int age;
  protected Date date_purchased  ;
  protected double amount_due  ;
  protected boolean local_buyer ;
  public int getAge() {
    return age;
  }
  public void setAge(int age) {
    this.age = age;
  }
  public double getAmount_due() {
    return amount_due;
  }
  public void setAmount_due(double amount_due) {
    this.amount_due = amount_due;
  }
  public Date getDate_purchased() {
    return date_purchased;
  }
  public void setDate_purchased(Date date_purchased) {
    this.date_purchased = date_purchased;
  }
  public String getFirst_name() {
    return first_name;
  }
  public void setFirst_name(String first_name) {
    this.first_name = first_name;
  }
  public String getLast_name() {
    return last_name;
  }
  public void setLast_name(String last_name) {
    this.last_name = last_name;
  }
  public boolean isLocal_buyer() {
    return local_buyer;
  }
  public void setLocal_buyer(boolean local_buyer) {
    this.local_buyer = local_buyer;
  }
}

Getting the Values from PropertySet (Loading Java Bean)

……

List<DataObject> dataObjectList = dataPackage.getDataObjects();
DataObject dObject = dataObjectList.get(0);
Mycustomobjecttype myCustomObject = new Mycustomobjecttype();
populateBeanFromPropertySet(dObject.getProperties(),myCustomObject);

……

// See the Reflection in Action here 
public void populateBeanFromPropertySet(PropertySet propertySet, Object bean)
  throws Exception {
 BeanInfo beaninformation;
 beaninformation = Introspector.getBeanInfo(bean.getClass());
 PropertyDescriptor[] sourceDescriptors = beaninformation.getPropertyDescriptors();
 for (PropertyDescriptor descriptor : sourceDescriptors) {
     Object result = null;
     String name = descriptor.getName();
    if (!name.equals("class")) {
      if (propertySet.get(name) != null) {
        if (descriptor.getPropertyType().getName().equals("int")) {
          result = new Integer(propertySet.get(name)
              .getValueAsString());
        } else if (descriptor.getPropertyType().getName().equals("double")) {
          result = new Double(propertySet.get(name).getValueAsString());
         } else if (descriptor.getPropertyType().getName().equals("boolean")) {
          result = new Boolean(propertySet.get(name).getValueAsString());
         } else if (descriptor.getPropertyType().getName().equals("java.util.Date")) {
          DateProperty dat = (DateProperty)propertySet.get(name);
          result = dat.getValue();
        }else {
          // none of the other possible types, so assume it as String
          result = propertySet.get(name).getValueAsString();
        }
        if (result != null)
          descriptor.getWriteMethod().invoke(bean, result);
      }
     }
  }
}

Setting Values to Property Set

 

public DataPackage createContentLessObject(Mycustomobjecttype myCustomType) throws Exception {
ObjectIdentity objectIdentity = new ObjectIdentity("testRepositoryName");
DataObject dataObject = new DataObject(objectIdentity, myCustomType.getClass().getName());
PropertySet properties = populateProperties(myCustomType);
properties.set("object_name",myCustomType.getFirst_name()+myCustomType.getLast_name() );
dataObject.setProperties(properties);
DataPackage dataPackage = new DataPackage(dataObject);
OperationOptions operationOptions = new OperationOptions();
return objectService.create(dataPackage, operationOptions);
}

 

// Reflection in Action  
public PropertySet populateProperties(Object bean)throws Exception {
BeanInfo beaninfo;
PropertySet myPropertyset = new PropertySet();
beaninfo = Introspector.getBeanInfo(bean.getClass());  
PropertyDescriptor[] sourceDescriptors = beaninfo
      .getPropertyDescriptors();
  for (PropertyDescriptor descriptor : sourceDescriptors) {
    String propertyName = descriptor.getName();
    if (!propertyName.equals("class")) {
        // dont set read only attributes if any
       // example r_object_id 
       if (!propertyName.startsWith("r")) {
        Object value = descriptor.getReadMethod().invoke(bean);
       if (value != null) {
          myPropertyset.set(propertyName, value);
        }
      }
   }
 }
  return myPropertyset;
}

Chaining of Custom Services in DFS


 

There is an interesting drawback in Documentum Foundation Services Version 6.5,

Issue:

When you chain custom services and try to build the Services the build fails lets see a Scenario from the DFS sample code itself

@DfsPojoService(targetNamespace = http://common.samples.services.emc.com&#8221;, requiresAuthentication = true

) public class HelloWorldService

{

public String sayHello(String name)

{

ServiceFactory serviceFactory = ServiceFactory.getInstance();

IServiceContext context = ContextFactory.getInstance().getContext();

try {

IAcmeCustomService secondService = serviceFactory.getService(IAcmeCustomService.class, context);

secondService.testExceptionHandling();

} catch (ServiceInvocationException e) {

e.printStackTrace();

} catch (CustomException e) {

e.printStackTrace();

} catch (ServiceException e) {

e.printStackTrace();

}

return “Hello “ + name;

}

}

Here in the sample code of DFS I am chaining the services, Here everything looks fine and when you now you build this service during the genarateArtifacts ant task the Build will fail with a will get a ClassNotFound compiler error at

IAcmeCustomService secondService = serviceFactory.getService(IAcmeCustomService.class, context);

What happens here is when the build does the initial clean up all the generated Client interfaces are deleted and DFS currently not checking for any dependencies.

Let me take the example of dfs-build.xml that’s the part of CoreDocumentumProject in composer

<generateArtifacts serviceModel=“${gen.src.dir}/${context.root}-${module.name}-service-model.xml” destdir=“${gen.src.dir}/”>

<src location=“${src.dir}” />

<classpath>

<path refid=“projectclasspath.path” />

</classpath>

</generateArtifacts>

</target>

 

In this we cannot set any exclusion path in <src location=“${src.dir}” />

Simply because it even if you provide <fileset/> or <direst/> with pattern set its not recognizing it.

I had raised a support case with EMC and they told me that this is not currently supported!!!! And they will add this as a feature request

This means we cannot Chain Custom Services unless EMC fix this or we do a semi manual workaround to overcome this issue.

The Work-around that I found

Follow these steps to overcome this issue

Step 1,

Identify the Services those will call the custom services, and create a new source directory for it in composer, here I am calling them as depended_src and move the services that calls the custom services to there, the depended src should be in a separate path than the webservices- src

src-img1

Step 2

1) Now Edit the Build file and add these two properties

 

<property name=“my.core.services.classes” value=“${service.projectdir}/Web Services/bin/classes” />

 

<property name=“dep.src.dir” value=“${service.projectdir}/depended_src” />

The dep.src.dir should point to the depended src location mentioned in step 1

2) Create an additional target for generatemodel and generate artifacts

<target name=“generateDependencies” depends=“generate”>

<echo message=“Calling generateDependencies” />

<generateModel contextRoot=“${context.root}” moduleName=“${module.name}” destdir=“${gen.src.dir}/”>

<services>

<fileset dir=“${dep.src.dir}”>

<include name=“**/*.java” />

</fileset>

</services>

<classpath>

<pathelement location=“${my.core.services.classes}” />

<path refid=“projectclasspath.path” />

</classpath>

</generateModel>

<generateArtifacts serviceModel=“${gen.src.dir}/${context.root}-${module.name}-service-model.xml” destdir=“${gen.src.dir}/”>

<src location=“${dep.src.dir}” />

<classpath>

<pathelement location=“${my.core.services.classes}”/>

<path refid=“projectclasspath.path” />

</classpath>

</generateArtifacts>

<!– signal build is done –>

<!– used by DFSBuilder.java –>

<copy todir=“${src.dir}/../” file=“${basedir}/dfs-builddone.flag” />

</target>

3) Now edit dfs-build.properteis and add the following property

service.projectdir= <absolute path to the project>

Step 3

1) Run the generate task,

2) Copy all the service entries from (between <module> and </module><context-root>-<module-name>-service-model.xml you can find this in <project_dir>\Web Services\bin\gen-src folder

3) Now run the generateDependencies task that was created on Step 2

4) Now Edit <context-root>-<module-name>-service-model.xml and add the copied services to this file

5) If you want to create the jar files now you can call the package task after this.

This should help you to chain custom services , and if you found any alternate ways please comment.

 

Data Dictionary in Documentum


As you all know Documentum is all about Objects and its attributes, Have you ever wondered where Documentum is storing information about its Object types and its attributes?

To get the answer for this question you should know more about Data Dictionary in Documentum. Let me walk you through some of the important aspects of Data Dictionary in this study note. 

What is the use of Data Dictionary

The following is a partial collection of the information about an Object type that will be stored by Data Dictionary Attribute label, help and other information (Localized), Default Attribute values, Value Assistance, Value Mapping, Constrains, and Default lifecycle of that object type. A Documentum client application can leverage this information to build the Presentation layer for that Object type and also provide some business rule enforcements.

 

Another interesting point about Data Dictionary is that it supports multiple locales, which means you can have multiple locale configured for each object type. Each locale represents a geographical region.

Imagine an Organization that has offices in Paris, Spain and US , The Data Dictionary allows you to store each  Attribute label information in all three languages and  the Client application (e.g. : WebTop , or a Custom UI) can fetch for the specific labels in the language of that region and display it to the user.

More about Data Dictionary

Let’s see some of the useful features of Data Dictionary here, above I mentioned some of the information that you can store in the Data Dictionary, lets see some of these in detail for a better understanding. First we will see all UI related and then we will see some business rules and functionalities that you can enforce through data dictionary

 

UI Related

1) Default Values for Attributes

During the Creation of an Object type or upon its modification you can specify the default value of that Attribute, which means if no value for that attribute has been specified by the user this default value will be set as the attribute value

2) Value Assistance

Value assistance is used to provide user with a drop down list of possible values for that attribute. This can be even conditional, means upon selected criteria the values in the value assistance can be changed (Conditional Value Assistance)

Another important point about Value assistance is the values used for Value Assistance can be a fixed list or based out of a DQL query that runs dynamically.

3) Value Mapping

Value mapping is another useful feature where a value can be mapped for another, this works as a Key Value pair, for an example consider this list used for Value mapping New Jersey – NJ, New York – NY, and New Hampshire – NH.

This option provides a possibility of user being displayed with the Complete State name in the UI and Value stored will be just the state code.

4) Internationalization of Various Texts

If you look at the WebTop or Any Documentum UI application (Not necessarily a custom build User Interface) you can see there are lot of information like labels, error messages, help information etc, these text bits can be stored for different locales in the Data Dictionary. Different locale means different languages. So this helps to build a single UI for a global application and support multiple languages.

 

Business Rule and Functionality

1) Lifecycles for an object type.

During the Creation or modification of an object type you can specify a lifecycle as the default lifecycle of an object type. This eliminates the pain of searching for a lifecycle name or its ID to attach it to the newly created object; User can do it by using keyword default at the time of attaching a new Object instance to a life cycle. 
But the important point to note here is just by specifying a default lifecycle a object will not be attached to its default lifecycle. The Creator or the application has to specifically attach that object to the lifecycle.  

2) Constrains

You can do validation of a property by adding constrains to it. The possible types of constrains are the following. Important point to note here is Content server does not enforce these constrains even though you define in Data Dictionary. Typically the Client application should read these constrains and enforces it.  You can also specify the localized error messages in for the validation error in the Data Dictionary. 

a) Primary key
Primary key should be added in combination with not- null constrain. Primary keys are inherited. One or more attributes can make primary key but only single value properties can be a part of it. One object type can have only one primary key definition, (But can have more if it inherit primary key from its super type). Primary key constraints can be either the object type level or the property level. If the key has more than one participating properties it should be defined at type level. If the key is a single property then it’s a good idea to define it at property level.

b) Unique Key
Unique key constraint is used to enforce a property or combination of properties for which all the object of that type should have unique value. The key can be a combination of one or more

single-valued properties or one or more repeating properties which is defined in that object type itself (Not Inherited).Another important point is the key for Unique constraint cannot be a combination of single-valued and repeating properties. These are inherited too.

c) Foreign key
Foreign key constraint identifies relationship between one or more properties for one object type and one or more properties in another. The number and data types of the properties in each set of properties must match. Foreign key constraints can be at object type level or at the property level. It should be defined at type level If the key has two or more participating properties. Also both object types must be set in the same repository, and corresponding parent and child Properties should be of same data type.

d) Not Null
A NOT NULL constraint sets on a property that will not allow having a null value. It can be defined only at the property level and only for single properties

e) Check
Check constraints are used for validating data. An expression or script can be provided in the constraint’s definition that the client application can run to validate a given property’s value. This can be on Object level or Attribute level

 

How is Data Dictionary modified

Data Dictionary modification can be either adding a new Object type information or can be modifying existing Object type information.

For adding a new Object type and its any of the above mentioned details can be done by either calling CREATE TYPE DQL Script, or by creating a new type  in a new or Existing DAR and deploying it.

Modifying the Existing Object type information can be done by editing type information in the doc app or DAR or by calling Alter type DQL script.

Please note that DAR or Documentum Archive is applicable only for repositories those are running on Documentum 6 or higher

 

Data Dictionary Publishing Job

When you update the Data Dictionary it in essence updates the internal object types and you need to run Data Dictionary Publishing job. This job is responsible for creating the necessary dmi_dd_attr_info , dmi_dd_type_info  and dmi_dd_common_info objects. You can configure and run this job from Documentum Administrator.

 

What makes a Data Dictionary

I had mentioned three object types that are getting created when the Data Dictionary publishing job publishes the Data Dictionary information. Lets see those objects briefly here  

dmi_dd_common_info
This object type contains information about an object type or an attribute that are common. All the objects of this type will have r_object_id starting with 68.

dmi_dd_type_info
This is a sub type of dmi_dd_common_info. This object type contains information about an object type. (which has already been published to the data dictionary) All the objects of this type will have r_object_id starting with 69.

dmi_dd_attr_info
This is a sub type of dmi_dd_common_info. This object type has  information about a property (which is already published to the data dictionary) All the objects of this type will have  r_object_id starting with 6a.

You would have noticed that all these object type starts with keyword dmi this means we cannot create or modify this object type, Only Data Dictionary publishing job can modify or create this type. 

Download this Study Note (PDF)

Aliases and Alias sets in Documentum


 

In Simple words Aliases are placeholders that can hold any of the following

1)      A User or a Group Name

2)      Folder information

Alias is a key value pair where key is the alias name and value is the actual value.

 

Alias Sets are the Collection of Aliases (Which has alias names and its values)

 

Typical uses of Aliases

1)      Dynamically Resolve task performers in a Workflow

2)      Set up ACL, ACL Domain and Owner name in a Sys Object or its sub types.

3)      Dynamically link or unlink an object of Sys object or its subtype with a Folder path

4)      Also used in Template ACL’s (I will explain more about Template ACL in another study note soon)

 

Internals of an Alias and Alias sets

Documentum uses an Object type named dm_aliase_set to store the aliases and its values. All the objects of this type will have a r_object_id starting with “66”

Lets see the attributes of this object type 

 

 

Name

Info

Description

alias_category

Integer (Repeating)

This defines the category of the aliases value in the corresponding index.   These are the possible values and its corresponding categories

Value

Category

0

Unknown

1

User

2

Group

3

User or Group

4

Path of Cabinet

5

Path of Folder

6

Name of ACL

alias_description

String (255) (Repeating)

This defines the option description for individual alias values that correspond to the index in alias names.

alias_names

String (32) (Repeating)

The name of alias for the corresponding index in the alias values. (This Sting cannot have (.))

alias_usr_ category

Integer (Repeating)

Placeholder for defining user defined categories for alias values.

alias_value                      

String (255) (Repeating)

The corresponding values for the Aliases defined the corresponding index in the alias names]

object_name

String (32) (Single)

Name of the Alias set

  • Has to be Unique among the alias sets in repository

object_description

String (128 ) (Single)

Description of the alias sets

owner_name

String (32) (Single)

The name of the user who owns this alias sets.

 

So now you have seen what makes a dm_alias_set object, now lets clarify how an Alias is defined within an Alias set.

Alias_names stores the name of the Alias and Alias_value stores the corresponding value for the Alias and it’s stored as repeatable attribute. Means value of an index position defines an Alias Category, Alias Name and Alias Value

 

In an example of an Alias manager = John Smith the index of listing manager in attribute alias_name and index of listing John Smith in attribute alias_value will be same

 

Alias Reference and Scope of Alias

 

Alias is referenced used %alias_name

Referencing an Alias can also include Object_name of Alias Set; in that case the reference will be %alias_set_object_name.alias_name

 

So if the alias is referenced with the Alias set names (%alias_set_object_name.alias_name

) Server finds the Alias set by name and picks up the Alias name and resolve its Alias value, this is pretty much a straightforward job for the server to do.

 

But where the Alias name is referred without Alias set name the Server searches for the Alias in some specific scopes, This Order and location where the search is made for alias depends upon where that alias is referenced.

 

The following table describes few important Scopes, underlying object type and attribute of that object that helps server to identify the alias set to resolve the alias names.

 

Scope

Object type

Attribute

Notes

User

dm_user

alias_set_id

Server user alias_set_id property of the user who has done the action that resulted in alias resolution.

Group

Dm_group

alias_set_id

Default group of the user who performed the action

Lifecycle

Dm_sysobject

R_alias_set_id

R_alias_set_id is set by the server when the object is attached to a lifecycle.

Server Configuration

Dm_server_config

Alias_set_id

This alias set object represents the alias set thats used as the default system-level

Alias set.

 

Federation in Documentum


Federation is one among the most common distributed Documentum model. This means multiple Documentum repositories run as a federation. There will be a Governing repository and multiple member repositories in this model. Lets try to find out more about Federation

 

Take this typical scenario A Major Pharmaceutical Company ABC Corporation has multiple research centers and production plants across the glob and they have multiple Documentum repositories used for storing various information. A user logged into a corporate application needs to fetch documents from these various repositories in a Single session. Each repository in this scenario should have same set of users, groups and ACL for this architecture to work, manually managing these kind of scenario is trouble some and error prone.

 

Now lets see what a federation can do to make it less complex.

As I mentioned above Federations consists of Governing and Member repositories all the changes that has been made to global users and groups and external ACLS in the governing repository are automatically reproduced in the member Repository.

 

Requirements for Federation

·         Object types definition should be same in the all participating repositories.

·         User and group definition should be same in all participating repositories.

·         The server on which governing repository runs must project to the connection brokers at the servers where member repository runs

·         The server on which member repositories runs must project to the connection brokers at the servers where governing repository runs

·         If any of the participating Content Servers are with trusted server licenses Either
The servers should be configured to listen on both secure and native port or
The secure connection default for clients allows the clients to request a connection on a native or secure port

 

Few Bullet points about Federation

·         Any alteration done to any of the object type will not be automatically pushed to the participating repositories

·         Only users or groups marked as Global while creating them will be pushed / synchronized with participating repositories

·         The users those are part of any object types that are extended from dm_user will not automatically pushed. This will happen only if you specify this type in the Federation configuration.

·         Each repositories can be part of a single federation

·         A federation may contain different Content Server versions

·         A federation may contain a mix of trusted and non-trusted Content Servers.

 

 Download this Study Note (PDF)

Non Qualifiable properties and Property Bag in Documentum Objects


Before getting into details of Property Bags lets quickly see what are Qualifiable and Non-Qualifiable properties?

 

Qualifiable Properties

Most of the Object attributes are Qualifiable properties. The properties are qualifiable if it is saved (persisted) in a column of that Objects underlying tables (_r or _s table) in the Database. Attributes are Qualifiable by default.  I am not getting into much detail of Qualifiable properties here. See the following link for more on this

 

Object Attribute :- Repeated and Single Value Attributes in Database

 

Non – Qualifiable Properties

These Attributes of objects does not have column of its own in the Object’s underlying _r or s tables. They are saved in the serialized format in the i_property_bag property of the underlying object. See the below noted bullet points that reveal some interesting facts about Non – Qualifiable attributes.

 

·         Though these properties can be returned using a DQL Query, this cannot be used in the Qualifying clause [in Where Clause of the Query]. The Exception to this rule is that Non-Qualifiable properties can be used in the where clause of FTQL queries

·         These properties can be full text indexed.

·         IF the Non-Qualifiable properties are part of the select part of the Query, the query should have r_object_id in the select list.

·         If a property is Non-Qualifiable and it is of type String the length of that attribute must be less than the value of max_nqa_string key in the server.ini (Only if this key has a value set in server.ini) (The default value is 2000)

 

 

Lets See Few Related DQL’s

 

The following DQL creates an object type mycustomtype with first name a Qualifiable Attribute and country a Single Non-Qualifiable attribute and phone a Non Qualifiable Repating attribute.

 

CREATE TYPE “mycustomtype” (“firstname” string(64), country string(64) NOT QUALIFIABLE, phone string(10) REPEATING NOT QUALIFIABLE ) WITH SUPERTYPE “dm_document”

 

The following Query will create an object of type mycustomtype (You may notice that there is no difference in the create Query when compared with Qualifiable Properties

 

CREATE mycustomype OBJECT SET “firstname” = ‘Hello World’, SET “country”= ‘US’, SET phone [0]= ‘1111111111’

 

The following Query will return the Attributes from mycustomtype.
Note:
Make sure that you have r_object_id in the select query if you have non-Qualifiable attributes otherwise you will get following error
DM_QUERY2_E_MISSING_OBJECTID_IN_SELECT_LIST

 

Select r_object_id, firstname, country from mycustomype;

 

What is Property Bag

Property bag is a relatively new term in Documentum. This is a property, which is used to store other properties and values of an Object.  Non Qualifiable properties and its values of an Object is stored in its property bag (both Single and Repeated)

Other than Non-Qualifiable properties Property bag can also hold Properties and values of Aspect if the aspect properties are enabled with OPTIMIZEFETCH.

 

i_property_bag and r_property_bag

 

The i_property_bag property is defined in dm_sysobject , This Attribute is of datatype String and  can hold up to 2000 characters. This makes sure that all the object types that are inheriting from dm_sysobject have the ability to have its own property bag.

 

In the scenarios where you don’t have a Parent type defined in the Object definition and you create a non-Qualifiable attribute this property is automatically added to the object type.

 

If you add property bag to an object type it can never be removed from that object type.

 

The r_property_bag is silently added to the Object’s type definition when we add i_property_bag. This repeating attribute property is used to store the overflow from the i_property_bag. That means if the names and values of properties stored in i_property_bag exceed 2000 chars, the overflow is stored in r_property_bag. This is repeating string property with 2000 characters.

 

Download This Study Note (PDF)

 

Few Important Object Types in Documentum


 

 

Documentum is an Object Oriented Content Management Systems. Everything in Documentum is considered as Objects, This includes all the things that user manipulates, or the content server saves. From the User to Document, everything in Documentum is different type of Object. The whole Object types in Documentum has been structured in a Hierarchal model. Means All the Attributes from the super types are extended to the sub types. In other sense the attributes of Super types are visible and accessible from the Subtypes.

 

Lets see some of the important and most commonly used object types here. 

 

Note: This is just to give an insight of Documentum Object model. Please read Object Reference Manual for very detailed information on All Object types and its attributes.

Persistence Object 

This type is the super type of all the object types that are saved in Documentum. Each time user creates an object instance of Persistence object type they are objects stored in the repository, this can be retrieved at a later point of time from the Content server.

 

This Object type is an internal type and you cannot create an instance of it.  There are only 3 attributes for this object type they are. These attributes are extended to all the object types across the Documentum.

 

1)      r_object_id
A Unique ID of an object. Content server generates this ID when you create an object of any type. There are some interesting aspects about r_object_id. r_object_id is 16 characters long and its alpha numeric.

The characters from position 01 to 02 indicate the object type tag (09 = document, 0b = folder, etc.).

The characters from position 03 to 08            Repository id (Same for every object in a Repository, but different for each Repository)     

The characters from position 09 -to 16            is unique identifier for this object

 

Consider the following r_object_id 09012a5b80075dc2 in this 09 is the Object type Tag, 012a5b is the repository ID and 80075dc2 is the unique id that represents this object.

2)      i_vstamp
This property is basically used for versioning, each time you save changes to the object the value of this property increases by 1 and this also helps to check the concurrent modification of object.

3)      i_is_replica
This property of object that indicates whether that object is replica of  an object in a remote repository

 

Sys Object (extended from Persistence Object) (dm_sysobject)

Most of the commonly used object types are extended from this object type. Most common Subtypes include Document, Folder, and Cabinet etc.

There are 4 important characteristics for this Object type. They are

1)      Only dm_sysobject and its subtypes can be defined as shareable

2)      They can have permissions associated (Attach ACL).

3)      Sys object can belongs to a folder (Exception Cabinet – Cabinet cannot belong to a folder)

4)      Sys object can have content attached to it.

ACL  (extended from Persistence Object) (dm_acl)

This object type plays a very vital role in implementing security to the Documentum server if the security model of Content Server is set to ACL. All ACL objects r_object_id starts with letters 45

User (extended from Persistence Object)(dm_user)

This stores all the information about user in a Documentum repository, Only a Super user or Sys Admin can create/activate/delete/deactivate a user. All User Object’s r_object_id starts with letters 11

Group (extended from Persistence Object)(dm_group)

A group is the group of users and it can include another groups also.  This object stores information about a specific group, which includes r_object_id of all the member users, groups. This has identifier which determines whether it’s a group or a role. All the group objects has r_object_id starting with 12

Document (extended from Sys Object)(dm_document)

Documents represent a real document in Repository; it can be associated with 0 or more content objects also.  A Document may be a real document or virtual document. All objects of this type has a r_object_id starting with 09

Folder (extended from Sys Object)(dm_folder)

Folders are basically used to organize contents. All the sys objects that are created should be linked with at least one folder or a Cabinet. An Object can be linked with multiple folders also. All objects of this type has a r_object_id starting with 0b

Cabinet (extended from Sys Object)(dm_cabinet)

Cabinet is a special type of folders and its used to organize sys object in a repository. Cabinets are the highest in the Folder Hierarchy in Documentum. A Cabinet cannot be placed inside a Cabinet or a Folder and that makes it special. All objects of this type has a r_object_id starting with 0c

Registered (extended from Sys Object)(dm_registered)

Represents a Registered table in a RDBMS in Documentum. It has the table, name, column names and it s data type saved.  All objects of this type has a r_object_id starting with 19

  

Object types that are not saved in Repository

There are few Object types in Documentum, which are not to be saved in the repository. These are some object types that are created on runtime and destroyed as its use is over. Here is the list of those object types.

 

Client config (New in D6)

A Client config object is created at every time when DFC is initialized. This has all the properties in the dfc.properties file.

Connection Config

This type describes a session’s connection to a specific repository

Docbroker Locator

A docbroker locator object contains information about each connection broker that the

client DMCL can access

Docbase Locator

This has information all repositories registered with a connection broker

Server Locator

A server locator object has information about all the servers registered to a connection broker

Session Config

Contains information about an open repository session

 

Download this Study Note (PDF)