Tag: Ajith Prabhakar

Data Dictionary in Documentum

~ Ajith Vallath Prabhakar ~ Leave a comment

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 to 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, Constraints, 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 enforcement.

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, let’s 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 the 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 a 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 a 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 a 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 an object will not be attached to its default lifecycle. The Creator or the application has to specifically attach that object to the lifecycle.

2) Constraints

You can do validation of a property by adding constrains to it. The possible types of constraints are the following. An important point to note here is Content server does not enforce these constraints 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 constraint. 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 inherits primary key from its supertype). 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 the type level. If the key is a single property then it’s a good idea to define it at the property level.

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

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

c) Foreign key
Foreign key constraint identifies a 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 the 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. Let’s 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 subtype of dmi_dd_common_info. This object type contains information about an object type. (which has already been published in the data dictionary) All the objects of this type will have r_object_id starting with 69.

dmi_dd_attr_info
This is a subtype 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 types 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

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

 

Documentum Object types Naming Convention

~ Ajith Vallath Prabhakar ~ 2 Comments

All Out of the box Documentum object types follows the following naming convention

  • All object types that are commonly used and visible to users starts with letters dm (Example dm_document, dm_sysobject, dm_user )
  • All Object types that are dynamically cached (means changes to it is visible to applications and users) starts with letters dmc  (Example dmc_completed_workitem dmc_jar dmc_java_library )
  • All object types that read only will start with letters dmr There are only object types that starts with letters dmr they are  dmr_content and dmr_containment
  • All Object types that are internally used by Content server starts with the letters dmi (Example dmi_package, dmi_queue_item, dmi_session)

Immutable Objects in Documentum

~ Ajith Vallath Prabhakar ~ Leave a comment

Immutable objects are those objects, which cannot be changed. That means (most of the) properties or contents of these objects cannot be edited.  I had discussed few points about immutability on my notes about Virtual Documents. Lets see some other aspects of Immutability here.

 Now lets see how can we make an object immutable and what are the exception to it

  1. Versioning an Object (Sys object or any sub type of Sys object)
    When an Object is versioned (made a new version by check in) the old version of the versioned object becomes immutable
  2. Branching an Object
    When you branch an Object the parent of the new Branched object becomes Immutable.In both the cases mentioned above Immutability of an object is controlled by an attribute with Boolean value called r_immutable_flag, which is part of dm_sysobject . Content server sets the r_immutable_flag to true on the old version of the object in both these cases.
     
  3. Retention Policy
    If the Object is governed by a retention policy that makes its immutable then also the r_immutable_flag to true making the Object immutable.
  4. Freezing a Document by calling freeze()
    Freeze method is used to explicitly set a object as immutable. When you call freeze method it sets r_immutable_flag to true and also sets r_frozen_flag to true.
    Setting r_frozen_flag to true indicates that freeze method is called on that object. In other words r_frozen_flag is set to true only if freeze method is called on that object, not by versioning branching etc.
    Unfreezing a Document
    Unfreeze     method sets the value of r_frozen_flag to false and also r_immutable_flag to false and hence makes that object mutable again

Freezing and Unfreezing a Virtual Document
If you chose to freeze an associated snapshot in a Virtual Document, the r_has_frzn_assembly attribute is also set to TRUE on that Virtual Document object.

When you freeze a snapshot r_immutable_flag attributes for each component in the snapshot is set to true and also value of r_frzn_assembly_cnt is incremented. The r_frzn_assembly count attribute contains a count of the number of frozen snapshots that contain this component.

If value of r_frzn_assembly_cnt is greater than zero, you cannot delete or modify the object.

Calling a Freeze method to freeze a snapshot automatically freezes the document with which the snapshot is associated. To freeze only the snapshot and not the document, first execute a Freeze method and include the argument to freeze the snapshot then execute an Unfreeze method to unfreeze only the document.

Exceptions

Even though if an Objects is set to immutable there are some attributes of that object that can be changed, lets see what all are those attributes are

 These are the attributes that content server can change on a immutable Objects

  • a_archive 
  • i_isdeleted 
  • i_reference_cnt 
  • i_vstamp
  • r_access_date 
  • r_alias_set_id 
  • r_current_state
  • r_resume_stat
  • r_frozen_flag
  • r_frzn_assembly_cnt
  • r_immutable_flag
  • r_policy_id

There are few attributes that an application or a DQL can change on a Frozen Object

  • i_folder_id
  • a_special_app
  • a_compound_architecture
  • a_full_text
  • a_storage_type
  • Version label (r_version_label) Symbolic labels only
  • acl_domain
  • acl_name
  • owner_name
  • group_name
  • owner_permit
  • group_permit
  • world_permit

Changing i_folder_id means you can link or unlink a Frozen document with any folders or cabinets)

 Download this Study Note (PDF)

Difference between Super User and Sysadmin

~ Ajith Vallath Prabhakar ~ Leave a comment

Most of the budding Documentum developers get confused about the differences between a Super User and a Sysadmin. Though I had mentioned these points on my Documentum Security notes PDF file, I feel this needs a separate entry here. So just listing few important privileges of Sysadmin and Super User here. This list is not exhaustive but I guess I have most of it here, if you feel that I missed some important please feel free to add it as a comment.

Sysadmin

  • Create, alter, and drop users and groups
  • Create, modify, and delete system-level ACLs
  • Grant and revoke Create Type, Create Cabinet, and Create Group privileges
  • Create types, cabinets, and printers
  • Manipulate workflows or work items, regardless of ownership
  • Manage any object’s lifecycle
  • Set the a_full_text attribute

 The Sysadmin privilege does not override object-level permissions

 Super User

  • Perform all the functions of a user with Sysadmin privileges
  • Unlock objects in the repository
  • Modify or drop another user’s user-defined object type
  • Create subtypes that have no supertype
  • Register and unregister another user’s tables
  • Select from any underlying RDBMS table regardless of whether it is registered or not
  • Modify or remove another user’s groups or private ACLs
  • Create, modify, or remove system ACLs
  • Grant and revoke Superuser and Sysadmin privileges
  • Grant and revoke extended privileges
  • View audit trail entries

Download this Study Note (PDF)

Federation in Documentum

~ Ajith Vallath Prabhakar ~ 1 Comment

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

~ Ajith Vallath Prabhakar ~ 1 Comment

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

~ Ajith Vallath Prabhakar ~ Leave a comment

 

 

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)

Object Types involved in WorkFlow

~ Ajith Vallath Prabhakar ~ 2 Comments

Below is the table with different object types that has some role in workflow (5.3) with its description from Documentum Object Reference Manual

Object Type

Short Description

Detailed Information

dm_workflow

Contains the runtime information about a workflow.

A workflow object contains the runtime information about a workflow.

dm_activity

An activity object defines a workflow activity.

The attributes in an activity object define who performs the activity and the packages and work items generated from the activity.

dm_process

A process object contains the definition of a workflow process.

A process object is created when a user creates a workflow definition in either Workflow Manager or Business Process Manager. There are three inherited attributes that are reserved for internal use for process objects: a_special_app, a_status, and a_application_type.

dmi_workitem

Stores information about a task for a human or automatic performer.

Work items are generated by Content Server from an activity object. Users cannot create work items. Users can modify only the following attributes: a_held_by, a_wq_doc_profile, a_wq_flag, a_wq_name, and a_wq_policy_id.

dmc_workqueue

Represents a work queue for work items generated from a workflow

A work queue object represents a work queue for workflow tasks. The workqueue object type is installed by a script when Content Server is installed. However, work queues (instances of the type) are created and managed using Webtop.

dmc_workqueue_category

Defines a category for a work queue.

A work queue category object represents a category of work queues. The object type has no attributes defined for it. It inherits all its attributes from its supertype, dm_folder. It uses only the object_name, acl_name, and acl_domain attributes. The object_name attribute stores the work queue category name

dmc_workqueue_policy

Defines configuration information for a work queue.

A work queue policy object defines configuration parameters for handling a task in a  workqueue. The parameters control how the items are handled. Each work queue has one associated work queue policy. If a document associated with a task has a defined work queue policy, that policy overrides the work queue’s policy.

dmi_wf_timer

Records the configuration of a timer for a workflow activity.

A wf timer object describes a timer for a workflow activity. The wf timer objects are created automatically when the timer is instantiated.

Download This Study Note (PDF)

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)