Documentum Repoint Resurrected!

I guess everyone using Documentum on a daily basis knows what dqMan and repoint applications are. Life of a Documentum developer would be very difficult if those tools were not available. I tried so many times to get used to dqMan but I simply couldn’t, there is just something wrong with the User Interface…So even though repoint application felt like ‘beta’ version I was still preferring using repoint to dqMan.

I’ve had this plan since long time ago to restart development of repoint as it seems like the original author abandoned the project. And it finally happened. I have just committed a Maven friendly repoint project to github:

https://github.com/karolbe/repoint-r

If you would like to play with it you can grab the sources and use Maven to build it, just run:

mvn clean install

and after some time you will find repoint application for your architecture (linux, windows, macos) in following folder: repoint-eclipse-repository/target/products/Repoint

So far I have only removed some deprecated RCP code but I have some bigger plans for that application. Depending on my spare time I am going to work on:

* ACL editor
* Trusted Content Services support

and of course fix issues and improve usability.

Disabling TBO (BOF v2) in Documentum 5.3+

Sometimes during development it is useful to disable a Typed Based Object (TBO). In Documentum 5.3 (and older) when Business Object Framework was at version 1 it was easy, all that has to be done was commenting out the TBO definition line in $DOCUMENTUM/config/dbor.properties. From now on the TBO will be disabled in that particular DFC instance.

In BOF version 2 things have complicated because dbor.properties is no longer used (or at least recommended), instead all BOF objects are defined in the repository as dmc_module object instances. There is an easy way to disable a TBO globally by renaming the dmc_module object in /System/Modules/TBO but it will disable that TBO for all users and sometimes when doing troubleshooting on, for example, production system it is desirable to disable TBO only on one client.

In order to disable TBO on a single client machine we have to do a trick. Each DFC instance has it’s own BOF cache, which usually is in $DOCUMENTUM/cache. We have to locate the dmc_jar implementing the TBO and replace it with a dummy one which will not contain any business logic. How to locate the right dmc_jar? Well, it requires some investigation, you can either use DQL to look for the r_object_id of dmc_jar or just check files in the cache folder and look for JAR which will contain class implementing given TBO.

Next step is to prepare a dummy TBO. Dummy TBO is in all cases almost the same, what changes is the name of the class and package name. Sometimes different TBO objects are implementing different interfaces (for example IDfDynamicInheritance is not a required one) so in worst case you can look it up in the sources (or decompile the original TBO JAR file) and see how it was declared.

Typical Java code is following:


package com.documentum.cvp.common;

import com.documentum.fc.client.DfDocument;
import com.documentum.fc.client.IDfBusinessObject;
import com.documentum.fc.common.DfException;
import com.documentum.fc.common.IDfDynamicInheritance;

public class CvpDocument extends DfDocument
    implements IDfBusinessObject, IDfDynamicInheritance
{

    public CvpDocument()
    {
    }

    public String getVersion()
    {
        return "1.0";
    }

    public String getVendorString()
    {
        return "Documentum";
    }

    public boolean isCompatible(String version)
    {
        return version.compareTo("1.0") == 0;
    }

    public boolean supportsFeature(String feature)
    {
        return false;
    }
}

When dealing with DfFolder just change DfDocument to DfFolder and it should be fine.

After compiling the Java class and replacing the old JAR in the cache client application has to be restarted. It is also worth mentioning that the cache is periodically refreshed so it is a good idea to check whether our dummy TBO implementation was not overwritten by the real one. From my experience I can say that it happens very rarely.

I have tested this approach and I can confirm that it works, it saved me a lot of troubles during data migration between systems using FirstDoc.