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.




Yet Another Documentum Export Tool

How about we start the new year with another Documentum export tool, DeepExport?  This a very simple Java/DFC-based tool that logs into a Documentum repository and exports the content of any folder (recursively) to the local hard drive, preserving the folder structure.  The log file snippet below demonstrates how the folder structure is preserved.  Note that metadata is NOT exported; this is a content-only tool.  If you need to export content and metadata, check out the QuikDIE export tool.

To run the DeepExport tool, use the export.bat file. You will need to adjust the dfc.properties and log4j.properties in the /config folder to be appropriate for your environment.

The DeepExport tool expects to read a deepexport.properties file in its root directory with the following information:

docbase.name= name of the Documentum repository
docbase.user= name of the Documentum user to logon to the repository
docbase.password= password for the Documentum user
export.source= the cabinet/folder to export.  For example, /Temp, or /News/2014/.
export.target= the local directory to receive the export.  For example, c:/temp/export.

In addition to the properties file, you can supply DeepExport with two additional command line parameters:

-version will export all versions of all documents found and avoid file name collisions in the target folder.
-help will display a brief screen

DeepExport creates a time-stamped log file to track all of the files it exports. For example:

Documentum Deep Export 2015-01-02 17:08:18
(C) 2014 MSRoth - msroth.wordpress.com

Base export path = c:/temp/export
Found 55 folders to export
Found 6457 documents to export
  Not a document -- skipping test_query (0801e4538000f520)
  Exporting TargetSetup.Result --> c:\temp\export\Temp/TargetSetup.Result.txt (0901e45380000220)
  Exporting sysobjectContent.pdf --> c:\temp\export\Temp/sysobjectContent.pdf.pdf (0901e4538000597b)
  Exporting Copy of TargetSetup.Result --> c:\temp\export\Temp/Copy of TargetSetup.Result.txt (0901e45380005a54)
  Exporting Copy (2) of TargetSetup.Result --> c:\temp\export\Temp/Copy (2) of TargetSetup.Result.txt (0901e45380005a55)
  Exporting Walmart.txt --> c:\temp\export\Temp/Walmart.txt.txt (0901e4538000dd17)
  Exporting Walmart.rtf --> c:\temp\export\Temp/Walmart.rtf.rtf (0901e4538000e9aa)
  Exporting HP-DeskJet-MFP-5100_userguide.docx --> c:\temp\export\Temp/HP-DeskJet-MFP-5100_userguide.docx.docx (0901e4538002f990)
  Exporting HP-DeskJet-MFP-5100_userguide.docx.fr-CA --> c:\temp\export\Temp/HP-DeskJet-MFP-5100_userguide.docx.fr-CA.docx (0901e4538002fd65)
  Exporting HP-DeskJet-MFP-5100_userguide.docx.es-MX --> c:\temp\export\Temp/HP-DeskJet-MFP-5100_userguide.docx.es-MX.docx (0901e4538002fd66)
  Exporting Folder: /Temp/Jobs
  Exporting Folder: /Temp/Jobs/dm_DataDictionaryPublisher
  Exporting 11/14/2014 3:28:12 PM dm_DataDictionaryPublisher	--> c:\temp\export\Temp\Jobs\dm_DataDictionaryPublisher/11-14-2014 3_28_12 PM dm_DataDictionaryPublisher.txt	(0901e4538002b50c)
  Exporting 11/14/2014 3:44:37 PM dm_DataDictionaryPublisher	--> c:\temp\export\Temp\Jobs\dm_DataDictionaryPublisher/11-14-2014 3_44_37 PM dm_DataDictionaryPublisher.txt	(0901e4538002b564)
  Exporting 11/14/2014 4:12:38 PM dm_DataDictionaryPublisher	--> c:\temp\export\Temp\Jobs\dm_DataDictionaryPublisher/11-14-2014 4_12_38 PM dm_DataDictionaryPublisher.txt	(0901e4538002b5b2)

It seems to work well enough for me; I’ve had occasion to use it a few times. Let me know what you think.

How to Export Tabular Data in Captiva 7

See my post over at Armedia’s blog demonstrating how to export tabular data in Captiva 7.

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: