Object Relationships in Documentum


Objects in the Documentum repository can be associated with Relationships. Lets explore the basics of Object Relationships here. There are 2 major object types that you need to know in

1) dm_relation_typeThis defines a relation, means this object type holds the information about the relation like its name, security type, parent type, child type etc. We will get into the details of this soon. User must have SysAdmin or Super User privileges to create object of this type. All the objects of this type will have r_object_id starting with 38

2) dm_relation This defines each individual relationship between the objects. Means this type has ID’s of the both parent and child object which makes the relation, the name of the relation etc. All the objects of this type will have r_object_id starting with 37

Now lest see the attributes of each object type and understand what each attributes is meant for and how these objects are related.

Lets list the attributes of type dm_relation_type

Name

Info Description
relation_name Char (32) Single Name of the relation, This must be a Unique name.
security_type Char (10) Single This defines who can add, delete, drop or modify a relationship. The possible values are SYSTEM
PARENTCHILDNONE(I will explain this in detail below)
parent_type Char (32) Single The valid object type of parent in this relationship
child_type Char (32) Single The valid object type of child in this relationship
description Char (250) Single Description of the relationship (User defined)
direction_kind Integer Single The Direction of the relation There are 3 Possible values for it. And they are
0 – This relation is parent to child
1 – This relation is child to parent
2 – This relation is bidirectional (means these objects are siblings)
The default value is always 0
integrity_kind Integer Single This determines the referential integrity of this relation. There are 3 Possible values for it. And they are
0 – Allow Delete
1 – Disallow delete
2 – Cascade Delete (This means when a user deletes an object participating in a relationship instance, Server will also destroy the participating partner in the relationship)
The default value is always 0
parent_child_label Char (255) Repeating User defined name for the parent child relationship
child_parent_label Char (255) Repeating User defined name for the child to parent relationship
permanent_link Boolean Single This defines what happens to the relation when the parent is copied or versioned.
If set to True relation is maintained with new parent object.If set false the relation is not maintained. The Default value is False
copy_child Integer Single Specifies whether to copy the child in a relationship when the parent is copied and permanent_link is True. . There are 2 Possible values for it. And they are
0 – Do not copy Child
1 – Copy Child
a_controlling_kind Char (32) Single This indicates whether relationships of this type are created by users or internally.

Lets list the attributes of type dm_relation

 

Name

Info Description
relation_name Char (32) Single Name of the relation that’s specified for the dm_relation_type object
parent_id ID Single ID of the parent object
child_id ID Single ID of the child object.
child_label Char (32) Single Optional version label of the child object. If this value is provided then I_chronicle_id of the object should be given as the id of the child in the child_id attribute.
permanent_link Boolean Single <Deprecated>
order_no Integer Single Not used, but can be used for custom purpose
effective_date Date Single Not used, but can be used for custom purpose
expiration_date Date Single Not used, but can be used for custom purpose
description Char (255) Single Description of the relationship (User defined)

 

The relation between dm_relation_type and dm_relation type objects is illustrated below

Relation Dig-1

Few bullets points about dm_relation and dm_relation_type

  1. Niether dm_relation nor dm_relation_Tupe can be versioned

  2. Object level security (ACL) cannot be set on these object types

  3. You cannot delete a dm_relation_type object if any of the dm_relation with its relation_name exists.

  4. You need super user privileges to delete a dm_relation_type object

  5. Destroying a dm_relation object does not destroy the parent or child objects.

  6. When you destroy an object all the dm_relation associated with that object also gets deleted.

Security and Relations

 

When we saw the attributes of dm_relation_type object I had mentioned about security_type. Lets see this in detail. As mentioned above security_type defines who can add, delete, drop or modify an object of dm_relation object, which has a relation name that of the relation_name in the dm_relation_type. Lets see what the individual possible values means here

 

  1. SYSTEM
    This means only SuperUsers and SysAdmins can create, edit or delete a relation with the relation_name in this type. This does not prevent an owner of an object from destroying an object that participates in the relationship. When a Objectis destroyed content server also destroys all relation objects associated with the object. The owner of that Object is not required to be a superuser or system administrator.
  2. PARENT
    This means create, delete or edit a Relation will depend upon the users permissions on the parent object. I.e. if the object that’s getting related is of object type dm_sysobject or its child user should at least have RELATE permission.
  3. CHILD
    This means create, delete or edit a Relation will depend upon the users permissions on the Child object. I.e. if the object that’s getting related is of object type dm_sysobject or its child user should at least have RELATE permission.
  4. NONE
    This means Any user can create, delete or edit a Relation of this type.

Download this Study Note (PDF)

Virtual Documents in Documentum


What is a Virtual Document

Simplistically speaking Virtual document is a document that can contain another documents.

After reading the above statement first question that might arise to all is if it can contain documents how is it different from a folder?

Let me make few bullet points about Virtual Document here, which will clear most of the confusions that you might have about virtual documents.

 

· A Virtual Document is a Document which can contain the type or the sub type of SysObjects with an exception given below

· A Virtual Document cannot contain any folders or cabinets, or any sub types of these.

· A Virtual Document object may or may not have a content (dmr_content) attached to it but a folder or a cabinet will never have any content attached to it. Though most of the time a Virtual Document might not be having a Content file attached to it.

· Any Object type that extents from SysObject can be converted as a Virtual Document. The Attribute r_is_virtual_doc (integer not a Boolean) of SysObject determines whether that object is a virtual document or not. If the value is 1 then it’s a Virtual document. If its value is 0 and the property r_link_cnt value is not higher than 0 then that object is not a Virtual Document
The Content Server Fundamental is misleading in this aspect, Page number 199 of guide says it’s a Boolean property but in reality its not

· The Contents of the Virtual document can be of different object types.

· The Virtual Documents can be versioned and managed in the same way as you do with any other objects.

 

Components and Containment, the elements of Virtual Document

 

The Virtual documents are composed of various components, each components are nothing but individual objects. In other sense a component is a child of a Virtual Document. The containment objects (dmr_containtment) stores the information about the individual components of a Virtual Document. Every time when you add a new component to a virtual document a new dmr_containtment object will be created.

 

Now lets see the attributes of a dmr_containment object. This will give you a clear idea about what it does.

 

 

Name Info Description
parent_id ID – Single Object ID of the object that directly contains the component.
component_id ID – Single The Object Id of the Initial Object of the component. (I_chronicle_id). If the object has no versions, then its object ID and chronicle ID are the same.
copy_child Integer – Single Defines what a client should when the document containing the component is copied.
Possible Values Meaning
0 The decision whether to copy or reference the component is left to the user when the document is copied
1 When the document is copied, the component is referenced In the new copy rather than actually copied
2 When the document is copied, the component is also copied
follow_assembly Boolean – Single If set to TRUE, directs the system to resolve a component using the component’s assembly
i_partition Integer – Single Not Currently used
order_no Double -Single Number representing the component’s position within the components of the virtual document identified by parent_id
a_contain_desc string(255) Single User-defined. Used by clients to manage XML documents
a_contain_type string(255) Single User-defined. Used by clients to manage XML documents
use_node_ver_label Boolean – Single 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
Version_label string(32) Single Version label for the component.

 

 

Now as you had seen the dmr_containment object attributes lets get into more details of Virtual Documents.

The component can be associated with Virtual documents in 2 ways with respect to its versions

You can either associate a particular version of component with the virtual document or you can attach the entire version tree of the component with Virtual document.

 

If you attach the entire version of a document you have a choice of selecting the version of component to attach with virtual document at the time of assembling a virtual document.

Another important part of the Virtual document is the order of components in the Virtual Document; Content Server manages this ordering by default by adding for removing numbers while adding or removing components. If you wish do this part you can do it manually too.

 

Component referential integrity

The Boolean property compound_integrity of server configuration object dm_server_config manage the referential integrity of virtual document. If this attribute is set to true the content server will not allow deleting an object, which is contained in a Virtual Document. This attribute is set to true by default. You have to have minimum SysAdmin privileges to change this value.

If this attribute is set to false one can destroy the components of an unfrozen Virtual Documents. In any case you can never destroy components of a frozen virtual document.

 

Assembly, Conditional Assembly and Snapshots

Selecting the set of components for a Virtual document for a operation is known as Assembly, Conditional assembly allows the user to choose to include all components or some of them. As mentioned above if the entire versions of a component we can choose which all documents and also which versions of document to be included in the assembly.

 

A snapshot is the state of a Virtual document at the time when it was taken. This means it has the components that were selected during the creation of the snapshot. Each Snapshot is saved in repository as an assembly (dm_assembly) object.

Assembly objects are created when a user creates an assembly, a snapshot of the virtual document at particular point in time. Users must have at least Version permission for the object identified in the book_id property to modify an assembly object.

 

Binding a component (Early and Late)

Attaching a component to a Virtual Document is known as binding. There are 2 ways of binding a component to Virtual Document. They are Early binding and Late Binding

1) Early Binding
If you bind a specific version of a Component to the Virtual Document when you create a virtual document then it’s known as Early Binding. This makes sure that all the snapshots of virtual document have the same version of the component.
Links – Absolute and Symbolic

     Absolute Link

Before getting into Absolute links let’s see what an implicit version label is? An Implicit version label is the version label assigned to a document when you version by the content server. An implicit version label of the version of a document remains as it till that version is destroyed. Using an implicit version label to link component with a Virtual Document creates an Absolute link between component and Virtual Document.

     Symbolic Link

Symbolic version label is the version label, which are user –defined. This allows a user to give meaningful labels to a document. This can be moved from one version to another of a object.

When you use this type of linking no matter what the Virtual Document will have component, which has the specified symbolic version label. E.g. You define a Virtual Document to have a component which has a version label Published, the Virtual document will always have the published version of the component.

2) Late Binding
When you don’t specify a version label of a component when u add it to a virtual document its known as late binding. In this case the Content server attach the entire version tree of the specified component to the virtual document. And when you assemble the document you specify which version of component you should use.

Freezing and Unfreezing a Virtual Document.

Frozen Virtual Documents are virtual documents, which are immutable. Once you make a Virtual Document or a snapshot frozen you cannot change or delete any attributes of the virtual document and you can also not add or remove components of virtual document. You can explicitly make a Virtual Document immutable by calling IDfSysObject.freeze()

When you call the freeze () r_immutable_flag will be set to true by content server also r_frozen_flag will also be set to true by the content server.

 

Calling IDfSysObject.unfreeze() on a frozen virtual document unfreezes the Virtual Document and make it modifiable again. In that case the content server sets the above-mentioned flags to false.

 

Virtual Document related DQLS

Consider this model All the queries explained below will be based on this model

VirtualDocumentIllustration1

To find all direct components in this Virtual document SELECT ‘object_name’ in dm_sysobject IN DOCUMENT ID (‘r_object_id_of_virtual_document’)

This will returns the following in the exact same order VirtualDocument, Component1, Component2 and Component3 (VirtualDocument is returned because Virtual Document itself is considered as a Component)

 

To Filter Object Types in the above Query

SELECT r_object_id in dm_document IN DOCUMENT ID (‘r_object_id_of_virtual_document’)

This will return only dm_documents in the Virtual Document specified

Usage of DESCENT

Descent is used to return all components that contained in a virtual document.

SELECT ‘object_name’ in dm_sysobject IN DOCUMENT ID (‘r_object_id_of_virtual_document’) DESCENT

This returns the components in the following order

VirtualDocument, Component1, Child1, Child2, Child3, Component2, Child4, Child5, Component3, Child6,

Use the IN DOCUMENT clause with the ID scalar function to identify a particular virtual document in the query. The keyword DESCEND searches the virtual document’s full hierarchy.

Usage of VERSION

The VERSION Keyword finds the components of a specific version of a virtual document.

 

SELECT ‘object_name’ in dm_sysobject IN DOCUMENT ID (‘r_object_id_of_virtual_document’) VERSION 1.1

 

 

Download this Note (PDF)

 

Renditions in Documentum


A couple of days ago someone had asked me about Renditions in Documentum, Let me try to explain very briefly what renditions are.

Renditions are Representations of a Document in a different format.  In other ways, the only difference between a document and its rendition is only its format.   When you create a document in Documentum you specify the file format for that object, this file format is the Original format of that object.  The renditions of this object have the same properties of the original format object but it’s in a different format. These renditions are made either using Documentum Media Transformation Service or the supported Converters.    

The Converters are basically for Transform one type of graphic image to another type (e.g.: TIFF to JPG) or one-word processing format to another word processing format (e.g.: PDF to MSWord). There are few converters that come with the Content server, you can either buy or make your own custom converters. I am not getting into details of Converters here.

When you request for a rendition that uses converters Content Server creates and manages the Renditions automatically. You can also add renditions manually.
If you wanted to add renditions manually you can create the rendition by your own means and use addRendition() IDfSysObject interface.
For removing a rendition use removeRenditon() of the same IdfSysObject interface.
You have to have at least write permission to remove rendition of a Document.   

DFS Data Model Explained


Hi All 

As I am exploring the new DFS  I am noting some points that I can share with you guys. I know I cannot explain everything about DFS here As like you I am also learing but I will try to give an overall  picture of What DFS is all about here. Please visit this blog often as I keep updating this.

 

DFS Explained

Documentum Foundation Services the SOA face of Documentum. The remote invocation of DFS is implemented using SOAP based web-services. The beauty of DFS is that though DFS is exposed for the remote usages as Web Services it can be called locally using DFS Client libraries. DFS allows the migration easy by allowing services to be developed on existing BOF (Documentum Business Object Framework) also.Another interesting point about this is DFS consolidates the numerous inter depended methods into a Single Service. The DFS data model is expressed in both Java client library class and also in Service XML Schemas. This provides a consistent approach to model data that will be exchanged between the various business processes.  As mentioned above the DFS clients can be of two types.

  • Applications (Consumers) written any language that can use WSDL to interact with DFS.
  • Clients written on java that uses DFS Java Client library

 Data Model of DFS  The data passed to and from the Services are encapsulated into DFS Object Model  These are the few important object types on DFS

  • DataPackage
  • DataObject
  • ObjectIdentity
  • Property
  • Content
  • Permissions
  • Relationship

 Lets see what all these does now 

DataPackage 

According to the DFS Reference Guide from EMC The DataPackage class defines the fundamental unit of information that contains data passed to and returned by services operating in the DFS framework.  That means DataPackage is a collection of DataObject Instances, which is passed back and forth by Object Service Operations. In other words when you call services like Create, Get, Update the Data Object Instances are passed using DataPackage class.

It’s like an Envelope for putting various DataObject Instances. Object service operations process all the DataObject instances in the DataPackage sequentially.

 

DataObject

A DataObject is the DFS representation of a Persistent Object in Documentum Repository. DataObject potentially has all the information related to an Object in repository. This includes the Content, properties (Both Single and Repeated), relation with other Objects in repository, Its permissions etc. Due the nature of these objects, Data Objects are very complex.
Optionally these object instances may have instructions to services about how the parts of Objects have to be processed.
The type field of DataObject class represents the underlying typed object type name that corresponds to the Object Instance. For example dm_user, dm_document etc. default type is dm_document. I.e. if no type is specified then service implicitly assign that to type dm_document   

 

DataObject

ProperySet
Content
ObjectIdentity
Permission
Relationship

 The above Figure represents a DataObject.

ObjectIdentity

 As the name says this represents a Unique Object in the Repository. An instance of this class must have the repository name and a unique identifier for that object.  The value that represents a repository object may be any of the following  

  • OBJECT_ID – Contains r_object_id of the Object (Represents both Current Object and Non Current Object)
  • OBJECT_PATH – Contains String expression of the path of the Object in repository
    [Cabinet]/[Folder]/[File_Name]
    (This Represents only Current Object. Since you can create multiple objects with same name in same directory this does not guarantee uniqueness of the object)
  • QUALIFICATION – DQL Snippet that qualify an Object uniquely
    (The DQL Snippet is the Full DQL that follows the keyword FROM. E.G. dm_document where r_object_id=’09xxxxx’)

 Note: During the Creation of the object all you need to populate is only repository name.  

Property

Each Property represents an Object Attribute (Property) in the Documentum Repository. Property Set is a collection, which works as a container of multiple Property Objects

As there are 2 types of Properties for an Object a property can either be a Single property (Single Value Attribute) or Array Property (Repeated Attributes).  Property class has been sub classed to accommodate various data types and they are as follows.  

StringProperty

 
NumberProperty  
BooleanProperty  
DateProperty  
ObjectIdProperty  
ArrayProperty (Abstract Class) ®
  StringArrayProperty
  NumberArrayProperty
  BooleanArrayProperty
  DateArrayProperty
  ObjectIdArrayProperty
Transient Property

These properties are not the part of persistent properties of a repository object. Transient Property can send custom data fields to a service to be used for a purpose other than setting attributes on repository objects.

 

Array Property and Value Action

The Repeating Attributes of an Object type is represented as Array Properties. As you can see in the above table The ArrayProperty is an array of the corresponding single property.  Another Interesting aspect of Array Property is Value Action. Now lets see what value action is all about? This is an optional Action – Index mapping pair. These pair has the instruction as to what is the action to be done on a particular element of the ArrayProperty. The Index is the position in the attribute and Action is what is the action to be performed on that element of that index.  The possible ActionTypeValues are  

  • Append
    When processing ValueAction[p], the value at ArrayProperty[p] is appended to the end of repeating properties list of the persistent repository object. The index of the ValueAction item is ignored.
  • Insert
    When processing ValueAction[p], the value at ArrayProperty[p] is inserted into the repeating attribute list before position index. Note that 1, which must be accounted for in subsequent processing, offsets all items in the list to the right of the insertion point.
  • Delete
    The item at position index of the repeating attribute is deleted. When processing ValueAction[p] the value at ArrayProperty[p] must be set to a empty value.
  • Set
    When processing ValueAction[p], the value at ArrayProperty[p] replaces the value in the repeating attribute list at position index. (From DFS Development Guide)

 

Content

 Content Class or its Subclass instance represents the actual File Content associated with a DataObject.  DataObject can have zero or more Content objects. It can hold Renditions also.   Content class object can be configured to hold following

  • The Whole Document

  • Page of a Document

  • Pages (One or More) which has been represented by the characteristic

 

 

Permissions

 A DataObject has list of Permission Objects, which decides the permission of the object that’s represented by the DataObject. The permission list provides read access to the permission on an object in repository by the user who has been logged in currently. 

Also have to note an interesting point here that You Cannot change permissions on a repository object by changing the Permission list and saving the DataObject.

For changing permissions of a repository object the real ACL of that object has to be edited or replaced.   As mentioned above multiple Permission Objects creates Permission List. The Permission Object has a field named permission Type that sets what type of permission is set. The values possible for these fields are BASIC, EXTENDED or CUSTOM   Another important thing about permissions are if you assign one particular permission for one user to one object, all the lower lever permissions below the assigned permissions will be granted to that user. This is known as Compound or Hierarchical Permissions  PermissionType Enum Constants (From DFS Guide) 

PermissionType

Permission Description
Basic NONE No access is permitted
  BROWSE The user can view attribute values of content
  READ The user can read content but not update.
  RELATE The user can attach an annotation to object.
  VERSION The user can version the object.
  WRITE The user can write and update the object.
  DELETE The user can delete the object.
Extended X_CHANGE_LOCATION The user can change move an object from one folder to another. All users having at least Browse permission on an object are granted Change Location permission by default for that object.
  X_CHANGE_OWNER The user can change the owner of the object
  X_CHANGE_PERMIT The user can change the basic permissions on the object.
  X_CHANGE_STATE The user can change the document lifecycle state of the object.
  X_DELETE_OBJECT The user can delete the object. The delete object extended permission is not equivalent to the base Delete permission. Delete Object extended permission does not grant Browse, Read, Relate, Version, or Write permission
  X_EXECUTE_PROC The user can run the external procedure associated with the object. All users having at least Browse permission on an object are granted Execute Procedure permission by default for that object.

 

 

Relations

Relationship allows creating a Single DataObject that specifies all the relations that it has with other objects existing and new. This also allows single service call to get, update or create the whole set of objects and its relationships.  Relationship has two subclasses             
Object Relationship  
           &           
Reference Relationship
These classes define all the relationships that a (any) object in repository can have.  This represents existing relations, also can add new relations, which can be updated in the repository using service calls.  

According to DFS Developer guide The repository defines object relationships using different constructs, including generic relationship types represented by hardcoded strings (folder and virtual_document); dm_relation objects, which contain references to dm_relation_type objects; and dmc_relationship_def objects, a representation provides more sophistication in Documentum 6. The DFS Relationship object provides an abstraction for dealing with various metadata representations in a uniform manner 

 

ObjectRelationship

ObjectRelationship represents relationship to a new or existing repository object. It can be used by the update operation to either update or create Content objects. This when called with update operation modify/ create the target objects 

ReferenceRelationship

A ReferenceRelationship represents a relationship to an existing repository object and is specified using an ObjectIdentity. This object can (only) be used to create a relationship between two objects. This will not create or update the target objects.

 

 

Download this study note (PDF)

Changing the Repository Owner Password in Documentum


Follow thse steps to change the Repository owner password in Documentum Content Server

  1. Stop the Repository
  2. Go to $DM_HOME/dba/config/<repository name>/
  3. Create a copy of the file with name dbpasswd.txt
  4. In the DB change the password of Repository Owner
  5. Edit the dbpasswd.txt( The file backed up in Step 3) and replace the new password as plain text
  6. Save dbpasswd.txt
  7. Go to $DM_HOME/bin run the following
  8. dm_encrypt_password -docbase <docbase name> -rdbms -encrypt <database password>
  9. Restart the Repository

What is the significance of i_vstamp and i_is_replica


These are the properties defined in Persistent Object Type and inherited to all its subtypes

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.

i_is_replica
this property of object that indicates whether that object is replica of  an object in a remote repository

Object Attribute :- Repeated and Single Value Attributes in Database


Documentum Object support 2 types of Attributes

They are 

  • Single Value Attributes
    Single Value properties are properties that can hold a single value at a time
    For  Eg: object_name   One object will have only a single name
  • Repeated Attributes
    Repeated Attributes are properties that can hold multiple values
    For Eg: Keywords  A object can have multiple keywords attached to it

Documentum Uses Underlying database to save the meta-data. ie the Attribute information, Each attribute type in Documentum essentially has 2 tables in the database. One for saving the single value attribute and another one to save repeated attribute.  Documentum uses the following naming convension for the tables,  object_name_s for single value attribute table and object_name_rfor repeated attribute table where object_name is the the name of object type. for example for the dm_sysobject the tables names would me dm_sysobject_s and dm_sysobject_r

Repeated Property

Each property has a column in the _r table with I_position where I_position determines which location it belongs to 
eg:   if my_object has 2 repeated attributes given_names and location the my_object_r will have following columns r_object_id, i_postion, given_names, location
 

Single Value Attribute
Single Value Attribute is defined as each attribute has single column in the _s table
eg: if my_object has two single attributes surname and sex r_object_id, surname, sex  columns in the my_object_s will be r_object_id, surname, sex

View :- Each object type has 2 views
_SV & SP – All Single value attributes in conjunction with all super types
_RV & RP – All Repeated value attributes in conjunction with all super types
eg: if my_object is extending dm_document views will have all the single / repeated attributes of dm_sysobject,dm_document and my_object (dm_document will be added only if any new attributes has been added to it ) by default dm_document does not have any single attribute or repeated attribute