Tag: IDfSysObject

Aliases and Alias sets in Documentum

~ Ajith Vallath Prabhakar ~ Leave a comment

 

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 subtypes.

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”

Let’s 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 the 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 let’s 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 a 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 that’s used as the default system-level

Alias set.

 

Object Relationships in Documentum

~ Ajith Vallath Prabhakar ~ Leave a comment

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)

Renditions in Documentum

~ Ajith Vallath Prabhakar ~ Leave a comment

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.