Documentum Concepts - Fundamental

Content Server:
Governs the Documentum content repository and enables a rich set of content management services for controlling both content and processes throughout distributed enterprises. The heart of Documentum platform is the Documentum Content Server, which controls access to content stored in the Documentum repository. The Documentum repository is object-relational oriented and treats everything as an object, including content assets, users, groups, workflows, ACLs, and attributes (or metadata).

Content Services:
§ Library Services: Provides services like import, delete, check in, check out etc.
§ Workflow Engine: Provide services to create and manage workflows.
§ BPM Services: Provides integration services with external applications via JMS, SMTP, HTTP, FTP, Webservices etc.
§ Search Engine: Performs search on the content and Meta data.

DocBase:
A Docbase is a Documentum repository that stores document content, attributes, relationships, versions, renditions, formats, workflow, and security.Should be thought of as a huge centralized repository that stores content and metadata in the form of 'objects' and their properties.Everything in DocBase id object.Metadata for the content is some attributes that describe the content; for example its owner, creation date, version number, etc.Metadata is stored in RDBMS.Content file is stored in any of these storage types:
• The host server's OS file system
• In an RDBMS as BLOBs (Binary Large Objects)
• A content storage device (for example: EMC Centera)
• An external system outside Documentum's boundaries
Additionally, Content Server has an embedded full-text search engine, Verity, and so the Docbase repository contains a number of full-text indexes, allowing users to perform a full content-based search on the Docbase.Content attributes as well as the data within content files can be searched using this feature.

Each Documentum Content Server installation is not limited to a single Docbase. It can
host multiple Docbases. However, each of these multiple Docbases must be identified by a unique identifier termed a Docbase ID.

DocBroker:
Whenever a client wants to make a connection with the server, DocBroker acts as a bridge or an intermediary. Instead of DocBrokers requesting information from the servers, it works the other way round—Content Servers broadcast their connection information at regular intervals to multiple DocBrokers and the same information is sent back to the requesting clients.The client can choose which server to use from the returned information.Clients such as Web Publisher and Documentum Application Builder can communicate with multiple DocBrokers by defining a primary and backup DocBroker in the client's dmcl.ini file.


DocApp:
A DocApp is a packaging unit for Documentum objects.Typically all development work in Documentum projects happens on a development Docbase and the developed objects are released on a test Docbase for system testing before getting finally released over to the production Docbase.A DocApp works as a deployable packaging unit to move objects across Docbases.Within a DocApp one can include multiple Docbase objects like lifecycles, workflows, folders,etc. and create a DocApp archive from it. An archive is a file representation of a DocApp on the file system.This archive is then installed over to another Docbase through a Documentum DocApp installer.


Object Type:
Documentum is an object-oriented system and every object in Documentum belongs to an object type. Internally, the Content Server uses the object type as a template to create various instances of objects(like class and object). An object type is composed of several attributes that describe the various objects created from it.



Attributes:
Attributes are the properties that describe objects in Documentum.The persistent object type has three attributes that all subtypes inherit. r_object_id,i_is_replica,i_vstamp.

 

DQL
DQL is short for Document Query Language and uses syntax that is a superset of ANSI-standard SQL (Structured Query Language). For those familiar with SQL, DQL can be simply thought of as a Documentum wrapper over SQL---Likes HQL.
DQL is used to perform the following operations in a Docbase:
• Query, update, and delete objects in Docbase
• Create new objects in Docbase
• Search content in Docbase
• Query Registered tables
DQL queries can be fired from within:
• Documentum Administrator (a Documentum web client)
• DFC (Documentum Foundation Classes)
• IDQL utility

API
API commands (also referred to as Server API) are instructions sent to the Content Server by clients via DMCL (Documentum Client Library). Similar to DQL, API commands are used to:
• Query, update, and delete objects in Docbase
• Create new objects in Docbase
Unlike DQL queries, which can manipulate multiple objects at a time, API commands are meant to be executed on one object at a time.API manipulates a signal object,but DQL manipulates the object_typ.  

Cabinets and Folders
Objects in the Docbase are organized by placing them within cabinets and folders. Cabinets form the highest level of organization and contain folders, documents and other objects. Objects can reside within cabinets or within folders. Folders are present within cabinets or within other folders.Organizing objects within cabinets and folders can help us categorize the content better and enables faster searching for critical information.Cabinet object type in Documentum is dm_cabinet and folder object type is dm_folder. It should be noted that dm_folder is a supertype of dm_cabinet object type.


Versioning
Like any good CMS, Documentum internally manages multiple versions of the same document
and maintains a history of all updates that have gone in since the initial creation of the document. Versioning is an automatic feature provided by the Content Server through version labels. All SysObjects are versioned by Content Server except folders, cabinets and their subtypes. The various versions for a document are stored within a version tree. Version labels are stored in the r_version_label repeating attribute of SysObjects or their subtypes.
There are two kinds of version labels:
• Numeric (or implicit) labels: These are server-generated numeric labels and are stored in the first position of the r_version_label attribute.
Example : r_version_label[0]=1.0
• Symbolic labels: These are either system-defined or user-defined descriptive labels.
Unlike numeric labels, these convey meaningful information and hence are useful for one's applications. They are stored in the second position onwards in the r_version_label attribute and are case-sensitive.
Example : r_version_label[1]=WIP
It should be noted that CURRENT is the only symbolic label that the Content Server assigns
automatically to the last checked-in version of a document.
Since we are discussing versioning, this is a good place to discuss the r_object_id and i_chronicle_id attributes of SysObjects in Documentum. A version tree in Documentum contains the original object and all its modified versions. How does Content Server deduce which version tree a particular object belongs to? The answer is: through the i_chronicle_id attribute.
Note that the i_chronicle_id attribute stores the object ID (r_object_id) of the original (root)
version of the object. Every time a new version is created, Content Server copies the i_chronicle_id value to the new object created. Let us take a small example.
Create a new document. The Content Server assigns an object ID and chronicle ID to the document. Check it out and check it back in. The server now assigns a new object ID but retains the original ID. Again check it out and check it back in. The server again assigns a new object ID but retains the original chronicle ID.(Like Clearcase.)


Lifecycles
Documents in an enterprise progress through a well-defined authoring-review process.Content Server provides lifecycles to automate these various stages in the life of a document.Simply speaking, a lifecycle is a sequence of states that describe the various stages in the life of an object. Documentum stores lifecycles in the form of a policy object (dm_policy) in the Docbase.


Workflows
In plain terms, a workflow models a business process. Workflows consist of numerous activities, each comprising various tasks to be performed. Users or designated automated scripts carry out the tasks and pass over the document in question to the subsequent activity. What a workflow does, in essence, is routing the content through the various stages of its lifecycle via different users. Each user receives the designated task in one's Inbox and may also receive an email notification for the same. Documentum stores workflow definitions in the form of business process objects ('dm_process') in the Docbase.