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

<contentxfer>
<default-mechanism>ucf</default-mechanism>

</contentxfer>

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.

Advertisements

October 10, 2007

Documentum embraces Developers with Eclipse plugins

Filed under: dfc, wdk, webtop — Tags: , — Raj V @ 12:09 pm

Eclipse being the freely available favorite Java editor for many ( my preference goes to IntelliJ over any) and for sure there are many people who use Eclipse for Documentum Projects. EMC Documentum has embraced eclipse community with few plugins.

Next Step: EMC Documentum is coming up with Documentum Composer that will enable all sort of Documentum developmental activities.

Configuring WDK Development Environment in Eclipse

Filed under: documentum, wdk, webtop — Raj V @ 9:49 am

Abstract

This configuration guide is for developers who want to use the Eclipse IDE for WDK development. It discusses one approach for configuring Eclipse for WDK development.

Eclipse 3.1

Note: The configuration assumes that you do not have any plugins installed and that you have a base Eclipse install.

  • Click on the menu item ‘Windows->Preferences’.
    • From the tree view on the left hand side go to ‘Java->Compiler->Building’.
    • From right hand side unselect (clear) the ‘Scrub output folders…’ checkbox, which is under the ‘Output folder’ section. If this option is enabled then all standard WDK/Webtop classes will be scrubbed by Eclipse and you won’t be able to rebuild them if you don’t have the sources.
    • Click on ‘Ok’.
  • Click on ‘File->New Project’.
  • Select ‘Java Project’ and click on ‘Next’.
  • You need to create the project in an external location. There should be a ‘Checkbox’ that allows you to select this option and a ‘Browse’ button that allows you to browse-select the external folder.
  • Select the WDK/Webtop web application directory as the project folder. For example, <TOMCAT_HOME>\webapps\webtop.
  • Click on ‘Next’
  • Do not select any source folders right now. Leave the defaults.
  • Ensure that the output folder has been set to WEB-INF/classes folder. If not, browse and select it explicitly.
  • Click on ‘Finish’.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘New->Folder’.
    • In the ‘Folder name’ text box, name the folder (e.g wdKClasses). This folder will be added, in a later step, in the classpath of the project so that the existing WDK classes can be referenced.
    • Click on the ‘Advanced’ button (towards bottom of screen) and check (select) the ‘Link to folder in filesystem’ Checkbox. Browse and select the <virtual-root>\WEB-INF\classes folder.
    • The above procedure creates a new folder in the project space that points to the ‘\WEB-INF\classes’ folder.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘Properties’.
    • From the list on the left hand side of the ‘Properties’ window click on ‘Java Build Path’.
    • From the tabs on the right hand side select ‘Sources’. Select the PROJECT_NAME\custom\src as one of the source folders. You may add any number of additional source folders.
    • Now select the ‘Libraries’ tab and click on ‘Add External Jars’ button. Add the DFC-related jars and any other jars that you need.
    • In the previous step be sure to add the jars that contain the Java servlet and JSP classes. For Tomcat 4.1.30 on our machine, this jar was c:\Tomcat4130\common\lib\servlet.jar. For BEA 8.1 on our machine, this file was c:\bea\weblogic81\server\lib\weblogic.jar. For Tomcat 5.0.28 there are two jars, TOMCAT_HOME\common\lib\servlet-api.jar and TOMCAT_HOME\common\lib\jsp-api.jar
    • On the same tab click on the ‘Add Class Folder’ button and add the folder ‘wdkClasses’ that was created previously. This references all WDK\Webtop classes in the classpath.
    • Click on ‘Ok’

After completing this procedure, you can create your own classes and compile them. The results of compilation will directly go into the WEB-INF\classes folder just like the rest of the WDK/Webtop classes. You can also create XML configuration files and JSPs within the IDE using other Eclipse plugins for XML editing and JSP editing respectively. There is also a WDK Eclipse Plugin available on the Developer site.

Eclipse 2.1.x and 3.0

Note: The configuration assumes that you do not have any plugins installed and that you have a base Eclipse install.

  • Click on the menu item ‘Windows->Preferences’.
    • From the tree view on the left hand side go to ‘Java->Compiler’.
    • From the tabs on the right hand hand side select the ‘Build Path’ tab and unselect (clear) the ‘Scrub output folders…’ checkbox. If this option is enabled then all standard WDK/Webtop classes will be scrubbed by Eclipse and you won’t be able to rebuild them if you don’t have the sources.
    • Click on ‘Ok’.
  • Click on ‘File->New Project’.
  • Select ‘Java Project’ and click on ‘Next’.
  • You need to create the project in an external location. There should be a ‘Checkbox’ that allows you to select this option and a ‘Browse’ button that allows you to browse-select the external folder.
  • Select the WDK/Webtop web application directory as the project folder. For example, <TOMCAT_HOME>\webapps\webtop.
  • Click on ‘Next’ (or ‘Finish’ if it is enabled) and DO NOT select any source or output folders right now. Leave the defaults.
  • Click on ‘Finish’.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘New->Folder’.
    • In the ‘Folder name’ text box name the project (e.g wdKClasses). This folder will be added, in a later step, in the classpath of the project so that the existing WDK classes can be referenced.
    • Click on the ‘Advanced’ button (towards bottom of screen) and check (select) the ‘Link to folder in filesystem’ Checkbox. Browse and select the <virtual-root>\WEB-INF\classes folder.
    • The above procedure creates a new folder in the project space that points to the ‘\WEB-INF\classes’ folder.
  • Right click on the new WDK project from the standard tree view in the Java perspective and click on ‘Properties’.
    • From the list on the left hand side of the ‘Properties’ window click on ‘Java Build Path’.
    • From the tabs on the right hand side select ‘Sources’. Select the PROJECT_NAME\custom\src as one of the source folders. You may add any number of additional source folders.
    • Now select the ‘Libraries’ tab and click on ‘Add External Jars’ button. Add the DFC-related jars and any other jars that you need.
    • In the previous step be sure to add the jars that contain the Java servlet and JSP classes. For Tomcat 4.1.30 on our machine, this jar was c:\Tomcat4130\common\lib\servlet.jar. For BEA 8.1 on our machine, this file was c:\bea\weblogic81\server\lib\weblogic.jar
    • On the same tab click on the ‘Add Class Folder’ button and add the folder ‘wdkClasses’ that was created previously. This references all WDK\Webtop classes in the classpath.
    • At the bottom of all the tabs there will be a text box that specifies the output folder. Select PROJECT_NAME\ WEB-INF\classes as the output folder.
    • Click on ‘Ok’

After completing this procedure, you can create your own classes and compile them. The results of compilation will directly go into the WEB-INF\classes folder just like the rest of the WDK/Webtop classes. You can also create XML configuration files and JSPs within the IDE using other Eclipse plugins for XML editing and JSP editing respectively. There is also a WDK Eclipse Plugin available on the Developer site.

Reference: Developer Center

Blog at WordPress.com.