Documentum Concepts - Advanced

DMCL
DMCL stands for Documentum Client Library which provides a communication layer (RPC) between end clients and the Content Server.Client requests reach the Content Server via the DMCL layer, which consists of a C++ library of APIs that get executed on the Content Server. It is recommended not to execute direct DMCL API calls from the client. Instead, what should be used is a set of Documentum Java classes or a DFC.

DFC
DFC stands for Documentum Foundation Classes and is an Object-Oriented (OO) Framework
consisting of APIs for accessing and extending Content Server functionality. Simply speaking, it is a set of Java interfaces and classes written as a wrapper over DMCL. Apart from the regular DMCL capabilities, DFC also provides features such as data validation, virtual document management, etc.
Additionally, DFC also provides a Documentum Java-COM Bridge (DJCB) so that the Java interfaces can be used from within a Microsoft COM environment as well as by programs in Visual Basic, for example. DFC also includes a Business Objects Framework (BOF) that enables developers to model application business rules in the form of reusable modular components/elements.

Documentum Foundation Classes (DFC) represents the richest API exposing all Documentum functionality. DFC provides an object-oriented framework for accessing the capabilities of Content Server. DFC exposes the Documentum object model as an object-oriented client library for content management applications to use. It is an API that can be used from a host of applications, including those developed in Java, Visual Basic, C#, and C++.DFC is  implemented as a set of Java classes and interfaces, along with a Java-COM bridge for accessing DFC via COM from Visual Basic or Visual C++. Every computer running an application that accesses Content Server has a copy of the DFC software running on a Java Virtual Machine (JVM). The application on the client machine performs a method call through DFC, which translates the call into the Content Server’s native API. Content Server instantiates the object, executes the method call, and returns the result to the client application.
Do you remeber DocBroker?
Connection----->DocBroker;
Request    ----->DFC.

BOF
The Business Objects Framework (BOF) is built into DFC and helps developers create reusable business logic components called Business Objects. Applications using DFC can access BOF easily and can use BOF as pluggable components/entities in middle-tier or client applications.
Let's take a simple example to understand this.Assume that you require a specific business functionality of performing some particular validation whenever a particular document of some particular object type is checked-in into the Docbase. This can be achieved by using BOF and overriding the check-in functionality for the particular object type. Once written, the same business object is called irrespective of the client application used—be it Webtop, Web Publisher, some Desktop application, or some custom DFC class for that matter. In short, what we achieve is a reusable component/functionality.
There are two types of Business Objects:
• Type-based (TBO): This is useful in extending a particular Content Server object type
and including new custom methods or overriding existing methods. This type of Business
Object works on all objects in the Docbase of a particular object type only.---Like Entity Bean
• Service-based (SBO): Unlike type-based Business Objects, this type of Business Object
is not limited to a particular Docbase object type. Instead this works as a generic service
provided to all object types in the Docbase and not just one particular object type.---Like Session Bean.

WDK
Web Development Kit (WDK in short) is a framework provided by Documentum, on which one
can build a web application for talking to the Content Server.
The WDK programming model is completely based on J2EE and XML and WDK applications
can be deployed on any application server that confirms to J2EE standards. WDK applications
interact and fetch data from the Content Server via DFC calls.
Following are some features of the WDK framework:
• Consists of reusable and configurable components that generate HTML controls/widgets, providing access to the Content Server Docbase.
• Provides a tag library of configurable UI controls
• Provides framework services like branding, history, error handling, messaging, internationalization, and content transfer.
In short, WDK is a set of server-side reusable components supported by Documentum that allow one to rapidly develop and deploy web-based applications.
WDK architecture consists of:
• Presentation model: Incorporates JSP tag libraries to separate the UI from business logic.
• Component model: Incorporates server-side components that extend the Content Server functionality.
• WDK also provides robust server-side state and browser history management for content applications.


WebTop
Webtop is a Documentum reference implementation with WDK components. Web Publisher
tool is built over Webtop and is used mostly for content authoring and publishing.Documentum Webtop is a Web-based application that gives end-users access to one or more Documentum repositories. It provides a user environment through a browser rather than Microsoft Windows Explorer. It is the light weight client product which provides the generic document management features which are available in the form of business components developed by using Documentum WDK. Webtop provides the user interface to access the features such as queue management, inbox, folder navigation, search etc. Webtop supports internationalisation and access to various content management services.

ACL
ACL (Access Control List) forms a part of Documentum's security mechanism to restrict certain groups/users from accessing a particular object. Documentum stores restricted objects as dm_acl objects. Note that all SysObjects in Docbase have an ACL assigned to them.An ACL, also called a permission set, stores information regarding the groups/users that have access to a particular object as well as their access levels (or privilege levels).
Keep in mind that the permission levels are hierarchical, which means a permission level of 'READ' for example would grant permission levels above it as well—'NONE' and 'BROWSE'.
The basic access levels available in Documentum:
Permit level (r_accessor_permit attribute)    Permission           Short Description
1                                                                    NONE                   No access to the object.
2                                                                    BROWSE             User can view the object's attributes but not its associated content.
3                                                                    READ                   User can view the content as well but not modify it.
4                                                                    RELATE               User can attach an annotation (i.e. comment) to the object.
5                                                                    VERSION             User can create a new version of the object but not update the existing version.
6                                                                    WRITE                 User can write and update the existing version of the object.
7                                                                   DELETE               User can delete the object.
Apart from providing the above basic permission levels, Documentum provides some extended
permission levels as well.
Permission                      Short Description
Change State                    User can change the object's lifecycle state.
Change Permission           User can change the object's permission.
Change Ownership            User can change the object's owner.
Execute Procedure            User can execute an external procedure associated with the object.
Change Location               User can change the object's location, from one folder to another say.
It is worth mentioning here that Documentum uses two reserved aliases in ACLs:
• dm_owner: Symbolizes the current owner of the object
• dm_world: This is an alias for all the users present in the Docbase

Rendition
Rendition of a document is pretty much the representation of the original document with
differences only in its format. Content Server internally has converters to support numerous
renditions. Additionally, integrating Media Services with Content Server can provide support
for rich media formats as well.
An example of rendition is as follows:
A web developer creates a content template, say create_article.xml, and attaches presentation
XSL files to it in order to transform it to an HTML file and a WML file. The content created from
this template is rendered in the form of an HTML file as well as a WML file for display on a
website and a wireless application respectively.The HTML and WML files differ from the original content file only in format and not in their content.


Registered Tables
Most applications maintain some application tables in order to store data specific to the application.
These application tables may contain records that Documentum clients need access to. For example, a dropdown in a Documentum client application might need to display a list of all the countries in the world from an external database table, so that the content author can choose one while creating content.
The external database table is not known to the Content Server until you register it. In short,
registered tables are the normal RDBMS tables that the Content Server is aware of, in spite of
them not being part of the Docbase.
Documentum creates a dm_registered object for the 'Registered' table, allowing developers to use DQL queries to fetch the information from the table.
The dm_registered object contains information about the name of the table, table owner, table
columns, and access rights defining who has access to query the table and perform operations like insert/update/delete rows.

Methods and Jobs
Methods are executable programs and scripts in Docbase that can be scheduled to run automatically by jobs, which are Documentum objects (dm_job) that are used to automatically execute method objects. In short,job calls method.
1.Methods
Method scripts can be written either in Java, Docbasic (Documentum's proprietary language), or some other languages. In Documentum, a method is treated as a method object (dm_method) and its attributes define various method parameters such as execution agent, method type, timeout period, and method arguments. Methods can be executed by the following server execution agents:
. Content Server: This is the default execution agent for methods unless a specific execution agent is specified. Content Server is used to execute method objects associated with Docbasic scripts or scripts in other programming languages.
. Method Server: This is a daemon process always running while the Docbase is up and is managed by the Content Server. Note that the Method Server is installed by default along with the Content Server. Method Server can be used to execute method objects associated with Docbasic scripts.
. Java method server: During Content Server installation, Documentum installs Apache Tomcat application server as a Java method server on the Content Server host. The Java method server can be used to execute method objects that call Java methods in turn.
Documentum methods can be created, modified, and viewed from within Documentum
Administrator at the following location: Administration | Job Management | Methods.
2.Jobs
Instead of invoking methods manually or via scripts, jobs can be used to periodically schedule their execution. dm_job object attributes define job parameters like associated method, execution schedule, method arguments, etc.A job is executed by the Documentum agent exec process, which is installed with the Content Server. Documentum jobs can be created, modified, and viewed from within Documentum Administrator at the following location: Administration | Job Management | Jobs.