Documentum Objects
The topmost object in this hierarchy is "Persistence Object" as the super type of all the object types.
Usually the developers work on the objects from the third layer i.e. like ACL, Type, SysObject etc.
Here's a simple diagram which shows Documentum type hierarchy:
Why do we need custom object types?
Simple answer is, we need custom object types when we need to achieve additional functionality or attributes which are not available in default document type(dm_document).
Lets take a very simple example, we have a requirement where we need to store score card of students. by default if upload it as "dm_document" type in Documentum, it will have basic attributes where we can fill the values, like "title", "description" etc.
But for better accessibility and retrieval if we want to add another value("Student Roll Number"), it will not be possible if we use default "dm_document" object type.
For enabling that we will have to create a custom object type which will inherit "dm_document" type and will add our additional required attribute "Roll Number". So altogether it will have all the attribute which "dm_document" have by default, along with the attribute which we have created "Roll Number".
Next time when we upload score card, just select "score_card" instead of "dm_document", in the object type dropdown, and it will allow you to add value for "Roll Number" field.
NOTE:
1. Once its deployed successfully, another table will be created with same name as the custom object type, like for this case "score_card". All the documents upload with this object type, can be seen in the table.
2. It might not show the "Roll Number" field in import screen sometime, we still might need to update webtop xml files(More on that later)
3. How to create and deploy custom object type will be covered in next Posts.
Basic terminologies
Repository : dm_repository
Cabinets : dm_cabinet
Think of it as Top level folders which are inside a repository. Each cabinet is specifically designed and configured for separating business area from other cabinet.for Example if your repository is specifically designed for storing all the employee related documents for a certain organization, one cabinet have documents of current employees while other can have documents of ex employees. which will help to organize the documents for better categorization.
Folder : dm_folder
Inside cabinets you can organize everything according to your business needs, you can also upload documents directly inside the cabinet however for organizing documents in better way you can put them in folders, there can be any number of levels inside a cabinet.
Note : The folders can only be created inside a cabinet does not mean folder is a type of cabinet. In fact cabinet object is derived from dm_folder object, which is in turn derived from dm_sysobject.
Document : dm_document
Good thing in Documentum is, everything in Documentum is an object. Any document, folder, users(who uses Documentum), roles, groups(grouping similar kind of users, example Teachers), ACL, Job(some lines of code for business processes which needs to be run daily), workflow etc.
Each object have their inbuilt tables in database(and table names starts with "dm_").
Each object have their inbuilt tables in database(and table names starts with "dm_").
for example, all Documents (dm_document), Folders(dm_folder), Users(dm_user), Jobs(dm_job), Workflow(dm_workflow) etc.
The topmost object in this hierarchy is "Persistence Object" as the super type of all the object types.
Usually the developers work on the objects from the third layer i.e. like ACL, Type, SysObject etc.
Here's a simple diagram which shows Documentum type hierarchy:
 |
| source : ajithp.com |
Why do we need custom object types?
Simple answer is, we need custom object types when we need to achieve additional functionality or attributes which are not available in default document type(dm_document).
Lets take a very simple example, we have a requirement where we need to store score card of students. by default if upload it as "dm_document" type in Documentum, it will have basic attributes where we can fill the values, like "title", "description" etc.
But for better accessibility and retrieval if we want to add another value("Student Roll Number"), it will not be possible if we use default "dm_document" object type.
For enabling that we will have to create a custom object type which will inherit "dm_document" type and will add our additional required attribute "Roll Number". So altogether it will have all the attribute which "dm_document" have by default, along with the attribute which we have created "Roll Number".
Next time when we upload score card, just select "score_card" instead of "dm_document", in the object type dropdown, and it will allow you to add value for "Roll Number" field.
NOTE:
1. Once its deployed successfully, another table will be created with same name as the custom object type, like for this case "score_card". All the documents upload with this object type, can be seen in the table.
2. It might not show the "Roll Number" field in import screen sometime, we still might need to update webtop xml files(More on that later)
3. How to create and deploy custom object type will be covered in next Posts.
Basic terminologies
Repository : dm_repository
You can think of it as a top level folder or drive(like in windows we have drives like C or D or E) depending upon the business area. Each repository can have different behavior. Most of the thing like settings and configurations are applied at the Repository levels and are independent of other repositories. Its more than a folder, and all the Jobs, TBO, etc are applied on a whole repository. Each repository is totally independent of other.
Cabinets : dm_cabinet
Think of it as Top level folders which are inside a repository. Each cabinet is specifically designed and configured for separating business area from other cabinet.for Example if your repository is specifically designed for storing all the employee related documents for a certain organization, one cabinet have documents of current employees while other can have documents of ex employees. which will help to organize the documents for better categorization.
Folder : dm_folder
Inside cabinets you can organize everything according to your business needs, you can also upload documents directly inside the cabinet however for organizing documents in better way you can put them in folders, there can be any number of levels inside a cabinet.
Note : The folders can only be created inside a cabinet does not mean folder is a type of cabinet. In fact cabinet object is derived from dm_folder object, which is in turn derived from dm_sysobject.
Document : dm_document
Basically when you upload anything in Documentum these are documents. It can be a pdf, word file, PPT, image or any other types.
SysObject : dm_sysobject
From the above hierarchy we can see dm_folder, dm_document etc are sub type of dm_sysobject, we can find all the documents and folders entry in the "dm_sysobject" table.
Users : dm_user
whoever want to access Documentum should have their details in DOcumentu. This can be done by the admins using the tool Documentum Administrators or using the DQL queries.
you can find the query here. The password for the users can be hard-coded(inline), LDAP(most of the big organizations who uses Documentum use LDAP) or it can be set as the windows/Unix password.
Groups : dm_group
We can add similar users having same privilege and roles so it will be better to manage their access. This is necessarily used in every project.
Jobs : dm_job
Sometime their are certain code which needs to be run on a regular basis, as per the business requirement. we can convert this code to a Documentum Job and schedule it accordingly. For example, if you want to get a daily report of all the documents uploaded to a certain repository, cabinet or just folder, you can write few lines of code and deploy it. The job will run at the scheduled time and no manual run will be required.
Access Control Lists/ACLs/Permission Sets: dm_acl
As we learnt everything in Documentum is an object, a permission set is associated with that object. It does not need to be unique for each object and multiple objects can have same ACL.
In ACL, it is clearly defined that which user or which group have what kind of access to that objects. Ex read/write delete etc.
For all posts visit Blog Index.
SysObject : dm_sysobject
From the above hierarchy we can see dm_folder, dm_document etc are sub type of dm_sysobject, we can find all the documents and folders entry in the "dm_sysobject" table.
Users : dm_user
whoever want to access Documentum should have their details in DOcumentu. This can be done by the admins using the tool Documentum Administrators or using the DQL queries.
you can find the query here. The password for the users can be hard-coded(inline), LDAP(most of the big organizations who uses Documentum use LDAP) or it can be set as the windows/Unix password.
Groups : dm_group
We can add similar users having same privilege and roles so it will be better to manage their access. This is necessarily used in every project.
Jobs : dm_job
Sometime their are certain code which needs to be run on a regular basis, as per the business requirement. we can convert this code to a Documentum Job and schedule it accordingly. For example, if you want to get a daily report of all the documents uploaded to a certain repository, cabinet or just folder, you can write few lines of code and deploy it. The job will run at the scheduled time and no manual run will be required.
Access Control Lists/ACLs/Permission Sets: dm_acl
As we learnt everything in Documentum is an object, a permission set is associated with that object. It does not need to be unique for each object and multiple objects can have same ACL.
In ACL, it is clearly defined that which user or which group have what kind of access to that objects. Ex read/write delete etc.
For all posts visit Blog Index.
Comments
Post a Comment