Web Content Management with Documentum: Setup, Design, Develop, and Deploy Documentum Applications

The Content Server forms the heart of Documentum, providing essential services to create, version, manage, and archive content and objects in the Documentum system.

Content Server (earlier known as 'eContent Server') houses a repository, which Documentum terms a 'Docbase', to store the various content and its associated properties (metadata).

Docbase should be thought of as a huge centralized repository that stores content and metadata in the form of 'objects' and their properties.

Metadata for the content is nothing but the different attributes that describe the content; for example its owner, creation date, version number, etc.

Some attributes can be 'single-valued' having just one value, for example the name of the content, while others can be 'multi-valued' having multiple values, for example the keywords describing the content.

Documentum relies on the underlying RDBMS to store the metadata for various objects in various tables. On the other hand, the content files for the numerous objects are stored in any of these storage types:

Additionally, Content Server has an embedded full-text search engine, Verity, and so the Docbase repository contains...

Whenever a client wants to make a connection with the server, DocBroker acts as a bridge or an intermediary. (Please refer to figure 2.2)

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.

A DocApp is nothing but 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. We shall look further into this in Chapter 25.

If you have just started using Documentum, remember an important rule of thumb—start thinking of everything in the Documentum system as an object. Folders within which documents are stored are objects, documents created are themselves objects, workflows used to get the documents reviewed are objects, and in fact the users creating the documents are also objects!

Too many objects around? It might take a little while to get used to this philosophy, but very soon you will start realizing its importance.

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. An object type is composed of several attributes that describe the various objects created from it. We shall cover object types and attributes via detailed examples in Chapter 11.

Too much jargon for now? Let us take an example to simplify things:

A user creates an article that...

Attributes are the properties that describe objects in Documentum. For example, for a news article, the name of its author and its creation date can be considered its attributes.

It should be noted that all persistent objects stored in the Docbase are eventually subtypes of the internal persistent object type.

The persistent object type has three attributes that all subtypes inherit. r_object_id is specifically what everyone working with Documentum should understand:

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.

DQL is used to perform the following operations in a Docbase:

Example of a simple DQL query:

select r_object_id from dm_document where object_name = 'SampleDocument.xml'

The above query selects the unique Object ID of an object of type dm_document whose name is SampleDocument.xml

DQL queries can be fired from within:

IDQL is an interactive utility/tool installed along with the Content Server and allows us to execute DQL queries against a Docbase. Figure 2.8 shows how a sample DQL query is fired using the IDQL utility.

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:

Unlike DQL queries, which can manipulate multiple objects at a time, API commands are meant to be executed on one object at a time.

Example:

get,c,0900223280023fc2,object_name
...

Result: SampleDocument.xml

Let us break down the API command to explain the example:

Note that the arguments to Server API methods are positional and should not include any white spaces.

IAPI is an interactive utility/tool installed along with the Content Server, which allows one to execute Server API...

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.

Figure 2.10 shows a sample cabinet-folder structure in a Docbase as seen in 'Web Publisher' client.

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:

Example : r_version_label[0]=1.0

Documents in an enterprise progress through a well-defined authoring-review process.

Let us take an example of such a 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.

Figure 2.13 shows a sample lifecycle as it is seen in Documentum Application Builder.

We will delve deeper into lifecycles in Chapter 12.

In plain terms, a workflow models a business process. The following example can explain this better:

An online newspaper publishing firm requires various approvals of the created content, before publishing over to its live newspaper website. Instead of manually transferring hard copies of content to various groups of reviewers, a workflow can formalize, standardize, and automate the whole 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.

Figure 2.14 shows a sample Documentum...

In this chapter we talked about Content Server, the backbone of Documentum architecture, hosting Docbases. A Docbase can be thought of a logical repository, consisting of content files and their associated metadata. A DocApp, on the other hand is a packaging unit of a Docbase, consisting of objects from the Docbase.

We went on to discuss DocBrokers, which act as an intermediary allowing clients to make connections with Content Servers.

We saw how the Documentum system treats all entities in the form of objects. Objects can be treated as run-time instances of templates called object types in Documentum. Objects in Documentum have their own metadata, which is termed properties or attributes.

We saw an example of using DQL (Document Query Language) and Server API commands to query and manipulate objects in the Docbase.

We also touched upon the versioning capabilities of Content Server and had a brief introduction to lifecycles and workflows. While lifecycles represent the logical stages...