dm_notes: Documentum Notes

June 26, 2008

Role of UCF in Documentum Clients

Filed under: dfc, notes, ucf, wdk, webtop — Tags: — Raj V @ 10:32 pm

In early days, all Documentum clients were thick clients (either DFC based or DMCL based). This  means it was on a 2-tier architecture. You either need to have a DFC or a DFC based client installed on every client that accesses the Documentum Repository or alternatively use the legacy DMCL library based (IAPI, IDQL) to access the repository .

With the advent of WDK (a web based repository access manager), the thick client is no longer required on the individual clients. This was made possible by moving the Documentum Repository client layer (DFC) to the middle tier ( a 3-tier based architecture) from the traditional Client/Server based 2-tier architecture).

Moving DFC to the middle tier will enable the Application server to access the Repository. But how can the end client access the content in the Repository locally, where there is no footprint of Documentum?

When you perform content management operations, the content is retrieved by DFC on behalf of WDK from the content server and is transferred to the Application server where DFC resides. But how do we transport the content from the App Server to the end client.

To answer this, Documentum has come up with a HTTP based content transfer program that runs with in the context of the Client browser.
This program is a Java based Applet that transfers the content from the App Server to the client (Outbound operations ) and vice-versa (In-bound operations).
But due to the applets limitations to process complex document structures like XML Links/OLE Links etc. this transport mechanism was limited to basic content management functionality.

These limitations have put forward a new robust and extensible transport mechanism called UCF (Unified Client Facilities).

We can enable UCF in WDK based applications( 5.3 or later) through the configuration parameter.

How can you identify which transport facility (http or ucf) is used in your WDK based application?

It is defined in your app.xml file of your application (default entry : wdk\app.xml).
The below config element defines the mode



What is UCF?

UCF is composed of two components (at a very high level). UCF Server and UCF Client.

UCF Server plays two different roles. It presents itself as a end client to the DFC layer that communicates with the Repository and it presents itself as a server to the UCF Client (end client).

The broader communication channel is as below:

Content Server <—> DFC <– –> WDK/UCF Server<—> UCF Client.

What are the benifits of UCF over HTTP transfer mode and why is it being made the de-facto standard in  Documentum based applications (from D6)?

  • Performance and Throughput
    • There is a disbelief that the earlier HTTP based transport is faster than UCF transport. In general any standard http based uploads are better than http based downloads. Not sure why? May be the Server’s is responding more to the clients as most of the users are accessing the application and there are only few users that are trying to write back to the server (upload). (Just a thought)
    • I do agree there have been few performance issues and there have been lot of improvements over the time. It has improved a lot lately.
    • UCF provides client information to the server as and when required, accesses the registry, optimizes the content transfer, etc.. There is a delay involved in launching the UCF client and initializing it compared to the applet based transport. This delay is due to the JVM startup(launch), UCF client making the initial connection to the App Server and protocol negotiation with the server.
  • Extensibility
    • UCF is extensible. You can add your own Requests (Server)/handlers (Client) and plug-in to the UCF Infrastructure and enable it to perform your custom tasks.
  • Recovery
    • UCF has the support for recovery. Say when you are Exporting/Viewing a content file and the socket connection was broken during the transfer, UCF tries to re-try the operation from where it has left and attempts to complete the operation.
  • DFC based analysis for the client
    • As UCF has a small footprint on the client it sends the content file to the server. Then the server analyzes the content and initiates a 2-way communication channel with the client. This communication channel enables the server and client together to perform the Content Analysis.
  • Client information available on the server (for DFC and WDK components)
    • UCF client makes available all the required client information at the Server giving the impression of a client.

None of the above benefits were available with the http based transport implementation or were available with limited support.

June 22, 2008

Enabling Documentum Composer features on Eclipse Europa

Filed under: documentum — Tags: , , , — Raj V @ 11:28 pm

I ran through an article to Install Documentum Composer on Webtools project. However I was having Eclipse Europa  3.3.2 installation and want to enable Documentum Composer features on it.
The same rules apply other than getting the suggested updates. Europa uses the Discovery of features available on Eclipse site.

This came out to be much easier without much configuration as the required EMF Validation framework was already part of Europa.

  • Install Eclipse Europa JEE edition from Eclipse Europa Site.
  • Unzip EMC Documentum Composer to a separate folder (or you can extract the com.emc.* packages into corresponding eclipse plugins/features folders)
  • Copy com.emc.* from Composer/plugins directories to Eclipse/plugins directory.
  • Copy com.emc.* from Composer/features directories to Eclipse/features directory.
  • Start Eclipse and your are ready with Documentum Project with JEE that you can use for WDK development.

Hope EMC releases a update site for Composer along with a complete build.
This will enable using the update site to install “Composer” over existing installations of  Eclipse Europa/Webtools.
This saves lots of RAM (a minimum of 300MB).

Previous installation I had was (Hungry for memory):

  1. DCTM server (6.0 SP1 bundled with Weblogic)
  2. Oracle 10g R2 (Pre SP1 I was on Oracle 10g XE as development docbase to save on memory. XE comes for free and with complete feature set a docbase requires and a small footprint)
  3. Tomcat Webtop + DA
  4. Eclipse for Documentum WDK Development
  5. EMC Documentum Composer for DocApp Builder/Installer

Now with new installation I could atleast live with one Eclipse installation with the  option of having WDK Development and Documentum Composer in one IDE.

Few features I would like to see in Composer to make it a unified Documentum Development Tool are :
IAPI/IDQL (features of Samson) ; WDK WYSIWYG Editor, DFS SOA Design time with HTTP Analyzer.

June 19, 2008

Query to find list of objects in folder along with its Folder Path

Filed under: dfc, documentum, dql — Tags: , , — Raj V @ 3:42 pm

Occasionally we require to find the list of all objects from a folder and also retrieve their exact folder path with in the same query.

This can be achieved easily through a DFC Program. But its a little tricky when you want it through a a DQL Query. As dm_sysobject stores only the folder id (i_folder_id) of the object instead of the folder path.

The folder path is hidden in the dm_folder object and is a repeating attribute. So we need to query dm_folder for r_folder_path. The issue in DQL is you can’t select repeating attributes when you join multiple types. You will hit DM_QUERY2_E_REPEAT_TYPE_JOIN if you do so.

Lets see what DFC can do and how to approach the same with DQL.

DFC code snippet looks as below:

IDfFolder folder = (IDfFolder) session.getObjectByPath(<<folderpath>> );
if (folder != null) {
     getContents(session, folder, docs);
     System.out.println("Total Number of Files : "+docs.getSize() );

private List getContents(IDfSession session, IDfFolder folder, List docs) throws DfException, IOException {
   // get all the r_object_id
   IDfCollection collection = folder.getContents("r_object_id");
   if (collection != null) {
      while ( {
	String objectId = collection.getString("r_object_id");
	IDfSysObject object = (IDfSysObject) session.getObject(new DfId(objectId));
	if (object.getTypeName().equals("dm_folder" ) || object.getType().isSubTypeOf("dm_folder" )) {
           getContents(session, (IDfFolder) object, docs, writer);
	} else {
           IDfFolder folderObj = (IDfFolder) session.getObjectByQualification("dm_folder where r_object_id = '+ object.getString("i_folder_id" ) + "'");
           if (folderObj != null) {
	      buffer = object.getObjectName() + "\t"+ object.getOwnerName() + "\t"+
                                  folderObj.getString("r_folder_path" ) + "\t"+ object.getModifyDate();

In DQL the same can be achieved as below:

DQL> select A.r_object_id, A.object_name, B.r_folder_path from dm_document A, dm_folder_r B where any A.i_folder_id = B.r_object_id and B.r_folder_path like ‘%/System/%’;

What we are trying to achieve is to join the dm_document type repeating attribute ‘i_folder_id’ and a dm_folder single value attribute table. This way we don’t end up querying the r_folder_path a repeating attribute. If we would have queried dm_folder type (instead of dm_folder_r) we would have hit the DQL restriction of DM_QUERY2_E_REPEAT_TYPE_JOIN error. However querying the underlying table enables us to pass through the DQL translator for _r table (just like any registered table concept).

June 5, 2008

Hierarchical list of Documentum types

Filed under: dql, notes — Tags: , , — Raj V @ 8:06 pm

Came across a simple (useful) query that displays the types and thier hierarchy.

DQL>describe hierarchy persistent.

Displays a hierarchial structure  of all “Persistent Objects”.

DQL> describe hierarchy dm_sysobject
Object hierarchy list
\ dmi_expr_code
\ dm_mount_point
\ dm_location
\ dm_docbase_config
\ dm_server_config
\ dm_policy
\ dm_registered
\ dm_folder
\ dm_cabinet
\ dm_xml_application
\ dm_category
\ dmc_topic
\ dmc_room
\ dmc_module
\ dmc_aspect_type
\ dmc_validation_module
P.S.: Found it through samson (Just below the toolbar : Query Topics -> Type Management + List tree of types known in docbase –> Generate Query)

Analyzing the above query, I gave a DQL to find out hierarchy of dm_sysobject and it works perfect. cool

DQL>describe hierarchy dm_sysobject

(lists hierarchically all the sub types of sysobject ).

This will be handy sometimes to see who all extend a custom object type.

Here is the DQL to find direct sub types of a given type
DQL> select name from dm_type where super_name =’dm_sysobject’;
(This query doesn’t list the indirect sub types)

Create a free website or blog at