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)

Advertisements

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)

Object Types involved in WorkFlow


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


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)

 

Documentum Composer A boon for the Developers !!!!


 Documentum Composer Screenshot

After a long wait Documentum Composer is out. And its time to say goodbye to Application builder, Application Installer I was really excited to see the composer and believe me it was really user friendly, As expected I could see few errors happening in Error log of the Composer but its working fine. Anyways it looks like a good start. Once you download the Composer and unzip it, make sure that you go to <DocumentumComposer>\plugins\com.emc.ide.external.dfc_1.0.0\documentum.config\dfc.properties add your connection broker information to it.  
I created a Aspect using it and deployed it to the Server, The UI of Composer looks pretty much intuitive and easy to use.  I am adding a screenshot of the Composer for people who where waiting to see it. I will be adding more about my composer Experience soon

Renditions in Documentum


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 on 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 comes with 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.   

Registered Tables in Documentum


Registered tables are the tables that are present database which are registered in Documentum, so that it can be accessed using DQL. Basically Registered tables are used when the application needs to access data from the RDBMS within the Documentum. This can be either a Table or a View.  The Scenarios where I mostly used registered tables are for providing value assistance for Object attributes.  I am not getting into too much of details about Value Assistance here, Value assistance is a list of values that a client program (such as Webtop or a Custom WDK Application) displays at runtime for an object attribute. A user can select a value from this list (or, if allowed, add a new one to it). You can set the Value assistance for an Attribute using DAB (Documentum Application Builder).

As I mentioned above uou can register a Table or a view as a Registered Table, The Registered tables are stored as dm_registered objects in repositories. This extends dm_sysobject. And the r_object_id of this type always starts with 19. The following table lists the attributes of dm_registered

Name Info Description
column_count Integer  – Single Number of columns in the table.
column_datatype string(64) – Repeating List of the datatypes of the columns.
column_length. integer R Lengths of the columns that have a string data type
column_name. string(64) – Repeating List of the names of the columns in the table
group_table_permit integer  – Single Defines the RDBMS table permit level assigned to the registered table’s group.
is_key. Boolean Repeating Indicates if an index is built on the column
owner_table_permit integer  – Single Defines the RDBMS table permit level assigned to the registered table’s owner
synonym_for string(254) – Repeating Name of the table in the underlying RDBMS (can be an Oracle table synonym, or an MS SQL Server or Sybase table alias)
table_name string(64) Single Name of the table.
table_owner string(64) Single Name of the owner of the RDBMS table (the person who created the RDBMS table).
world_table_permit integer  – Single Defines the RDBMS table permit level assigned to the world

You should either own the table or have super user privileges to register a table. And since this object is linked with /system cabinet you should have write permission on /system cabinet. This is applicable only if the folder security is enabled in Repository

You cannot version a dm_registered object. And also the changes made to the table are not automatically updated in dm_registered object.  So if any changes has been made to the structure of the table or view you should unregister it first and register the table again with changes.

How to Register a Table?

Use the following DQL to register a table. REGISTER TABLE [owner_name.]table_name (column_def {,column_def}) [[WITH] KEY (column_list)][SYNONYM [FOR] ‘table_identification‘] This DQL will return the r_object_id of the newly created dm_registered object. In this owner_name is the name of the table owner. table_name is the name of the RDBMS table. column_def defines the columns in the registered table.

column_def arguments should have following syntax column_name datatype [(length)] the valid values for types are float, double, integer, int, char, character, string, date, time.

Length should be specified for character, char, or string data type.

column_list Identifies the columns in the table on which indexes have been built. column_list is usually separated with commas. table_ identification is the name of the table in the Database Example:

REGISTER TABLE “hr.users” (first_name CHAR(30), last_name (char 40), emp_id INT)KEY (“emp_id”)

Granting Rights

You need to give the permission to the users to access the registered tables.  The values for various permission levels are as follows 0 (None): No access 1 (Select): The user can retrieve data from the registered table 2 (Update): The user can update existing data in the registered table4 (Insert): The user can insert new data into the registered table8 (Delete): The user can delete rows from the registered table If a user wants update and insert permissions the value should be 2+4 = 6 , The repository owner also should have the same level of permission in the underlying database to grand those permission to those users. Granting Rights full permission to users in the above example

update dm_registered object set world_table_permit = 15 where object_name = ‘users’;

update dm_registered object set owner_table_permit = 15 where object_name =  ‘users’;

update dm_registered object set group_table_permit = 15 where object_name = ‘users’;

How to Unregister a Table?

Use the following DQL to Unregister a Table.

UNREGISTER [TABLE] [owner_name.]table_name In this owner_name is the name of the table owner. table_name is the name of the RDBMS table. You should be the owner of table or super user to do this

Accessing Data from Registered Table

Just like in RDBMS you can access registered table using the following syntax

Select [ATTRIBUTES] from dm_dbo.[REGISTERED_TABLE_NAME] where [CLAUSE]

The Operations such as update/ delete also has the same RDBMS syntax that’s used for a ordinary SQL, Only difference is prefixing dm_dbo to the table name

Example:
Select first_name, last_name, emp_id from dm_dbo.users ;

Updating Data in a Registered Table

Example
Update dm_dbo.users set first_name=’John’ where first_name=’Smith’

Deleting from a Registered Table

Example

Delete from dm_dbo.users  where first_name=’Smith’

Download this note on Registered Table (PDF)

Installation Issues of Documentum 6 SP1 Content Server on AIX


We had done a D6 SP1 installation few days ago and ran into some issues, I thought I will share my expereince with you all so that you know the issues that you may face during the installation of content server on AIX.

 As we stared with the installation of Content Server on our AIX system (5.3) we were hit with the following error

“The /tmp filesystem needs 1GB where it has 0 GB Available”  We had more than 1 GB space in both /var/tmp and /tmp.

During this I found an interesting thing that even the D6 Installer guide has lots of typos in it. It says /tmp some place then someother place it says /temp should have 1 GB  free space !!!!

If you are hit with this issue there is a work around,  You have to add the tmp directory location as parameter to the installer.  

That means you have to run the installer with following command line

serverAixSuiteSetup.bin -is:tempdir TMP_DIR

Where TMP_DIR should point your tmp directory which has more than 1 GB Space.

Another interesting issue is Though the D6 Installer guide in page number 143 says that if you run dm_launch_server_config_program.sh it will set the environment variables such as LIBPATH etc that doesnt really do that. So if you are installing D6 CS on AIX after completing the installtion make sure sure that you edit the profile of install owner and add these paths to it

Happy Installing !!!