Home > DOCUMENTUM > Documentum UCF & Troubleshooting

Documentum UCF & Troubleshooting

March 15, 2011

UCF stand for ‘Unified Content Facilities’ which is a lightweight applet that is responsible for transferring content between the content server, application server and the client machine during operations such as check-in, checkout, import etc. UCF is a Java-based client application that is installed at run-time.

Since WDK application uses UCF content transfer it downloads a lightweight applet to the browser when the client uses the Documentum operations for the first time.
UCF has many advantages that extend beyond simple FTP (file transfer protocol), such as:

– Recoverability in case of brief network interruption.

– It supports transfer of large files over network and optimizes the transfers by content compression capabilities.

– Awareness of locally downloaded files, and the ability to avoid downloading the same content twice

– Support for complex documents, such as XML files

– Registry support, to allow checkout from one application and check in from another. The diagram below in high level describes the process for a simple ucf operation.

When an UCF operation is requested, a Java applet is downloaded. The UCF client is invoked which requests for a UCF Session ID (UID) from the corresponding UCF servlet process. The UID sent via the browser as a request for content back to the application server. The content is then transferred between the UCF servlet and the UCF client as a direct HTTP
connection. On completion of the process the UCF servlet send the response to the application that it is completed and the browser receives a signal to terminate the UCF client.

UCF performs the following functions:

1. Standardizes content handling across infrastructure and applications

2. Simplifies XML and compound document processing in a Web environment by decoupling DFC and WDK and by providing an open framework for content analysis.

3.Improves maintainability, reliability and performance of WDK content transfer.


Whenever a user gets an UCF related errors, the following are the approaches which should be checked before going into troubleshooting of the issue. This will confirm that the error is not user or machine specific.

1. Closing all browsers and try invoking the UCF operation again.
2. Try login on other user’s machine with your login details to test. Also try doing a test with admin and non-admin privileged users.
3. Try connecting to another UCF client for e.g. DA.

If the error still persists in all the above scenarios, the best option is to reinstall UCF on your client as explained in the section below.


Particularly for developers using multiple applications and making configuration changes it’s sometimes worth re-installing UCF client on your machine.  The steps described below will normally require admin access depending on original UCF configuration.

1. Shutdown down all Browser sessions

2. Delete the ucf folder on your client located here(if this does not work you may need to reboot machine and try)

3. C:\Documents and Settings\<USER>\Documentum\ucf

4. Clear your browser cache

5. Close down any Java Consoles Running and any javaw.exe processes running

6. Clear your Browser Java Plug-in Cache

MS JVM – Delete all files in Temporary Internet Files

Sun JVM – From the Java Control Panel è  General Tab-> Temporary Internet Files -> Delete Files

7. Restart your UCF Test (e.g. Perform the import operation which invokes UCF operation)

8. Check the following folder is created (this confirms the plug-in has downloaded UCF)

C:\Documents and Settings\<user>\Documentum\ ucf\config

9. Check the ucf.installs.config.xml contains the correct paths to valid JRE’s on your desktop.  A common problem is it may point to a JRE that isn’t on your machine (typically due to a corrupt registry on workstation).

10. You must ensure in the file below that the appropriate paths and Java versions are all valid.

<xml version=”1.0″ encoding=”UTF-8″?>

<? dctm fileVersion=”″ compatibilityVersion=”″?>
<ucfInstall appId=”shared” version=”″ host=”WLDN0179847″ home=”C:\Documents and Settings\<user>\Documentum\ucf”><java version=”1.4.2″ minVersion=”1.4.2″ exePath=”C:\Program Files\Java\j2re1.4.2_11\bin\javaw.exe” classpath=”C:\Documents and Settings\<user> \Documentum\ucf\WLDN0XXXXX\shared\bin\ucf-client-api.jar;C:\Documents and Settings\<user>\Documentum\ucf\WLDN0XXXX\shared\bin\ucf-client-impl.jar”>
<option value=”-Djava.library.path=C:\Documents and Settings\<USER>\Documentum\ucf\XXXXXX\shared\bin”/>
<option value=”-Djava.util.logging.config.class=com.documentum.ucf.client.logging.impl.ConfigureLogger”/>
<option value=”-Duser.home=C:\Documents and Settings\<USER>”/>

11. You can also check that the correct versions of the UCF runtimes have been downloaded from the application server.
C:\Documents and Settings \<user> \Documentum \ucf \<computer_name> \shared \bin

You can check the versions of the dll by viewing properties. The version should match the version of UCF you are using and what has been installed on the application server for example for WDK 5.3sp2.


With UCF there are two types of logging available for diagnostics. There are client side (browser) and server side (application server) logging available.Client Side Logging:To enable client side logging, 2 files will need to be modified. Both of these files can be found in the folder:C:\Documents and Settings\<USERNAME>\Documentum\ucf\<HOSTNAME>\shared\config\Where,USERNAME is the windows user IDHOSTNAME is the machine hostname where the testing is being done.The first file to be edited is ucf.client.config.xml. The following entry should be changed to true:
<option name=”tracing.enabled”>
The following entry will need to be added as well:
<option name=”debug.mode”>
The next file to be edited is ucf.client.logging.properties and set the .level entries to ALL (all caps). The debugging levels available are (from least informative to most):
  • SEVERE (highest value)
  • INFO
  • FINE
  • ALL
Once these changes are made, UCF will begin logging on the client side starting with the next invocation. All output will be logged to: C:\Documentum\logs\ucf.client.*.log.App Server Logging:To enable UCF tracing, the following file in the WDK application will need to be edited:  ../WEB-INF/classes/ucf.server.config.xmlIn this file, the following entry will need to be set to true:
<option name=”tracing.enabled”>
UCF will log on the app server to $DOCUMENTUM_SHARED/logs/trace.log and/or wdk.log (depending on how log4j is configured). These changes will require a restart of the app server.
%d bloggers like this: