Troubleshooting UCF

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.

DIAGNOSE & RESOLVE UCF RELATED ISSUES:

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.

RE-INSTALL UCF ON YOUR CLIENT

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=”5.3.0.3″ compatibilityVersion=”5.3.0.2″?>

<ucfInstalls>

<ucfInstall appId=”shared” version=”5.3.0.217″ 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>”/>

</java>

</ucfInstall>

</ucfInstalls>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 5.3.0.213 for WDK 5.3sp2.

ENABLE UCF TRACING

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”>

<value>true</value>

</option>

The following entry will need to be added as well:

<option name=”debug.mode”> <value>true</value>

</option>

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)
• WARNING
• INFO
• CONFIG
• FINE
• FINER
• 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”> <value>true</value> </option>

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.

 

Installing/Creating Documentum TBO using Eclipse Composer

The Business Object Framework (BOF) is a set of functionality that provides ability to hook into any of the methods in the standard DFC object interfaces.

BOF’s are of two kinds:

1. Type Based Object(TBO)
2. Service Based Object(SBO)

TBO’s are used when only one object type needs its functionality overridden whereas, we use a SBO when the functionality is overridden for different object types or in case we want to use the functionality in many other TBO’s.

The main use of TBO is the ability it gives a developer to override selected functionality of the DfSysObject or any of its child types.

Module 1: Creating the TBO

Steps to be followed for creating a TBO jar

1. Create a java class using the same name as the object type.
2. The java class will have to extend DfDocument and will have to override its 4 functions getVersion, getVendorString (), isCompatible (String s) and supportsFeature (String s)
3. Then it will have to override the function that the tbo is needed for example doSave () etc.
4. Compile this class and make a jar of it.

Module 2: Installing the TBO

Steps for installing the TBO in the docbase

1. Create a new Documentum project in Composer
2. Right Click on Artifacts and select New>>Other. In the New screen select Documentum Artifact>> Jar Definition

 

Click on Next, and in the Artifact name field enter the name of the object type and click finish

3. Now for configuring the new jardef that we created. Since we have created only an implementation of the TBO, select Type field as Implementation. And  in the jar content browse and choose your jar file that was created in the Module 1.

4. Right Click on Artifacts and select New>>Other. In the New screen select Documentum Artifact>> Module

Click on Next, and in the Artifact name field enter the name of the object type and click finish

5. Now for configuring the new module that we created. In the Info tab select TBO from the drop down menu for Type.

6. In the Core JARs tab select Add for Implementation JARs and select the jardef created in previous step. Now click on Select in front of class Name this will display the class details of the jar in the jardef select the appropriate class.

7. Right click on Project and select the “Install Documentum Project” menu item.

Enter the username and password and click on Login button. The user will be authenticated and the Next and Finish buttons will become active. Click Finish to install the TBO into the docbase. This may take some time.

Now whenever an object of the type for which the TBO was created is invoked or created the TBO will be fired. The TBO can be found at Cabinets>>System>>Modules>>TBO

Module 3: Re-Installing the TBO

In case the java class has been modified, then the TBO needs to be re-installed. The steps to re-install TBO are as follows

1. Delete the folder with the TBO name in the location (Cabinets/System/Modules/TBO)
2. Recreate the jar using the new java file.
3. In Composer remove the jar file from the jardef and add the new jar file
4. Reinstall the Project to the docbase.

 

Branch Office Caching Service

Many of the ECM business scenarios the content is stored on central repository but the Customers and suppliers are distributed globally or the company Operation and Employees are distributed globally, this effectively result SLOW performance. What this means to the business..?

·         User waiting for content to transfer to local system which affectivity means to more waiting time. More waiting time add value to cost of the business which effectively means Loss of productivity.

·         Because of long waiting for the content, sometime user may stop using software itself.

·         Result in stop using software; user may intend to store information in local machine for quicker access. This leads treat to corporate sensitive information.

·         Because user storing information locally the data is not available to other users.

What can be a solution for this problem?

 

An immediate answer from an architect is cache the information or content. But how you do this? Documentum solution for this slow performance over remote access is Branch Office Caching Service.

Here is the architecture diagram once you install BOCS on a Documentum environment.

Here is the different distributed environment is possible with Documentum.

Federations: Separate Content Servers with unique content and centralized control of users and permissions

Remote Content Servers: Content is replicated on Content Servers in remote offices. Associated metadata stored at central repository.

Branch Office Caching Services–Cached copies of content are stored in lightweight cache servers for quick access. Associated metadata stored at central repository.

It doesn’t mean if you using BOCS mean not possible to use remote way of accessing content.

In and out of BOCS:

BOCS is a local “cache” server synchronized with a central repository. The first request for content will force a cache pull from the central repository. Subsequent requests for the same content will retrieve from BOCS for ALL remote users.

So you how long you wait for first content to fetch. Solution is pre-caching content. Content can be pre-cached with specific queries like fetching content from cabinet or folder or certain file type.

After D6 BOCS supports both read and full write cache with 2 modes- Synchronous and Asynchronous. In both the mode metadata is immediately written to database via WDK and is indexed and searchable.

BOCS installation and Administration:

BOCS are lightweight java application that can be easily installed and configuration can be done through Documentum Administrator.  BOCS can be monitored via Resource Agent using unified JMX framework.

In general, BOCS is only supported with WDK-based and DFS applications. BOCS are easily deployed and un-deployable and very little administration required for maintenance. BOCS supports the HTTPS protocol for enhanced security.

Final Words: 

Now I have introduced BOCS on my ECM deployment. This deployment solved SLOW performance problem. This lead to

·         Content stored in a Documentum repository can be indexed for search and located by others for use. BOCS makes collaboration is made easier and productivity is increased.

·         Users are more likely to use the system to manage content, providing all the benefits of managed content across the organization.

·         Content that isn’t managed can’t be secured. Content stored in a Documentum repository rather than on a file store can take full advantage of the rich Documentum security features.

·         Users spend more time on value-added activities rather than waiting for content to transfer which means higher productivity.