Updated Documentum Tools and Applications

I had a little free time this week and made some updates to tools and applications I use frequently.  These updates represent ideas sent to me by users or were necessary to address additional situations I encountered in the field.  I hope they are helpful for you too.

QuikDIE v1.5 – This application exports content and metadata from a Documentum repository based upon a query.  Content is exported in its native format, and metadata is exported as XML.  Updates include:

  • detects and eliminates content “parked” on BOCS server
  • “dmi_” object types are ignored
  • implemented DCTMBasics JAR

For additional information regarding QuikDIE (including important info in the comments section), search for “QuikDIE“.

DeepExport v1.1 – This application exports CONTENT ONLY from a folder in a Documentum repository.  Content is exported in its native format and the folder hierarchy in the repository is replicated on the export drive.  Updates include:

  • detects and eliminates objects parked on BOCS server
  • updated to use DCTMBasics v1.3
  • refactored to remove Utils class
  • added password encryption/decryption

For additional information regarding DeepExport, search for “DeepExport“.

DCTMBasics v1.3 – This JAR file contains a set of helpful methods for interfacing with Documentum via the DFC.  It contains implementations of methods discussed in “The Basics” series.  Updates include:

  • getDFCVersion() – returns DFC version of your client
  • checkDFCVersion() – compare the current DFC version with a minimum version
  • createDocbasePath() – create a folder hierarchy in the repository
  • encryptPassword() – encrypt a password using the RegistryPasswordUtils class (used to encrypt dm_bof_registry user)
  • decryptPassword() – decrypt a password encrypted with the encrypt() method
  • runDQLQueryReturnSingleValue() – run a query that returns a single value, for example:  select count(*) from …
  • isSysObject() – tests it an IDfPersistentObject is a sys_object or not
  • createLogFile() – create a log file and return it to the caller as a PrintWriter
  • other misc updates, changes, corrections, and refactoring

For additional information regarding “The Basics” series, search for “The Basics“.




Documentum Bulk Export Tool v1.4

I just updated the Documentum bulk export tool, QuikDIE, to version 1.4.  You can download it here.  More info about the tool can be found in  previous posts here and here.  Be sure to read the comments.

Updates in this version include:

  • Compiled using Java 1.7
  • updated JDOM library to 2.0.
  • check for supported DFC version (only 6.5 and later)
  • export a_antecedent_id so version tree can be reconstructed
  • updated batch file to use dctm.jar (Hopefully this will eliminate the java.lang.NoClassDefFoundError: org/apache/commons/lang/StringEscapeUtils error some have reported.  This class is found in the commons-lang-2.4.jar.)

Check it out and let me know what you think.




Documentum Bulk Export Tool v1.3

I updated the QuikDIE Documentum Export Tool to v1.3.  You can download it here.

This update includes the following changes and additions:

  • Added r_creator_name, r_creation_date, r_modifier, and r_modify_date attributes to the standard output set.
  • Converted object_name, subject, title and all custom attribute values to XML-safe.
  • Updated the dmRecordSet JAR to v1.2 and included it in the /lib folder.
  • Fixed bug that considered any object not starting with “dm_” to be custom, instead of ignoring all objects in OMIT_OBJ_PREFIXES array.
  • Included source project in archive.
  • Minor cosmetic tweaks.

The first two enhancements were suggested by Malcolm MacArthur (thanks!).  You can see that discussion thread here.

Documentum Bulk Export Tool

For some time now I’ve had this idea rattling around in my head that there should be a simple way to export content and metadata from the Content Server in a manner that allows for quick access to both the exported content and the metadata. Drag & Drop or Export from Webtop only gets you the content files. Dump & Load is a major pain, inconsistent, and too opaque. DAR files can also be problematic and too opaque.  I wanted a way to quickly export the content in its native format and the relevant metadata as XML. These pairs of files would then contain everything I needed to know about the content. I could visually verify them on the file system; I could open the content with a double-click; I could easily examine the metadata — or change it; I could easily archive it to CD or a ZIP file; or I could import it into another CMS.  (I think Records Manager does something like this when you disposition files to NARA as XML.)  Anyway, I finally converted the idea to code. Here is the Java/DFC export tool if you are interested.

To run it, configure the export.properties file to contain the necessary login credentials for your repository, and a query to gather the files you want to export. In addition, specify a location for the exported content on your file system. Here is my sample export.properties file.

export.query=select * from dm_sysobject where folder('/Temp',descend)


  • After the export tool runs once it will encrypt the password so it doesn’t sit around unprotected.
  • The query must return r_object_id.

Once configured, run the export.bat batch file. The batch file does its best to create the correct class path, but you might have to help it if your Documentum environment is not installed in the default manner.

The export tool will export all of the objects it gathers from running the configured query. Each content object is exported to a file name that is its r_object_id (an easy way to avoid any file name collisions), followed by the DOS extension for its content type. The accompanying metadata is similarly named, followed with .metadata.xml. All files are exported to the path you specify in the export.properties file.   Note that no folder structures are created to mirror the structure in the repository. That is, the export directory will contain a “flat” file structure (that’s why avoiding file name collisions was important). Right now, the export tool can handle dm_sysobjects, dm_folders, virtual documents, and content-less objects. Since the export tool will export whatever the query returns, you can export versions by specifying ‘(all)‘ in the query, and subfolder structures by using the FOLDER(*,'descend') function.

Here is an example .metadata.xml file.



  • This particular file is a virtual document, and it’s child nodes are listed in the <vd_children> element.
  • By default, the export tool exports metadata values for:  object_name, object_type, title, subject, acl_domain, acl_name, owner, version and a_content_type) (if applicable).
  • If the type is a custom type (like this example is), values for all custom metadata properties will also be exported (note sr_cat_no, sr_lot_no, and sr_expire above).

If the export tool encounters an object that appears to be a custom type, it will export a .typedef.xml file that contains definitions for all its custom attributes.

Here is an example of a .typedef.xml file.


It’s not perfect, but it works for my purposes.  Perhaps one day I will write an import tool that will read the XML and content files and import them into another repository (e.g., think simple migration tool). However, I suspect that the import process will be a lot more complicated than the export process. Keep an eye here, it might show up one day.

%d bloggers like this: