DctmUtils

Type Based Objects (TBOs) are part of Documentum's Business Object Framework (BOF). TBOs are a powerful client agnostic mechanism to implement object type specific customization.. The DctmUtils project includes a base class and reference implementation for custom document and folder TBOs that extend the out-of-the-box functionality. These classes, DctmUtilsDocument and DctmUtilsFolder, respectively, provide the following features:

Declarative Validation

Out-of-the-box, Documentum provides configurable attribute validation in Documentum Application Builder (DAB). This validation is limited to one profile, i.e. a required attribute is either required or it is not; there is no support for validation profiles that correlate with a Lifecycle state. Moreover, this validation is only enforced by Documentum's client applications, it is not enforced programmatically. This is a significant limitation when integrating with other applications or managing content through Web Services.

DctmUtils integrated Commons Validator, the same validation framework that Struts uses, with TBOs. Commons Validator provides XML based configurable validation. In addition, one can configure an unlimited number of validation profiles for a given Document. Frequently, these validation profiles correspond to Lifecycle states.

DctmUtilsDocument.validate(IDfDocument document, String validationRulesFileName, String validationResourcesFileName)

Best Practice: Define project-specific validation rules and resources files. Define a validation profile for all TBOs and then call validate() from the save() and saveLock() methods in your project's top level TBO, i.e. the TBO that corresponds to the enterprise document.

Strongly Typed Getters and Setters

Strongly typed getter and setter methods for custom document attributes enable TBOs to serve as Data Access Objects (DAOs) for external applications. Using java.util.Date instead of IDfTime and java.lang.String instead of IDfId in the TBO's getters and setters promotes inter-application compabality. For example, dates in a Struts FormBean will be stored as a java.util.Date not an IDfTime. If your TBO exposes getter and setter methods with a java.util.Date, BeanUtils.copyProperties(Object sourceBean, Object targetBean) will synchronize the data between the Struts application and Documenutm. This practice decouples the underlying data from the Struts Action that is responsible for synchronizing that data.

DctmUtilsDocument.getIdAsString(String attributeName)
DctmUtilsDocument.setIdWithString(String attributeName, String value)
DctmUtilsDocument.getDate(String attributeName)
DctmUtilsDocument.setDate(String attributeName, Date date)

Best Practice:

• Include getters and setters of all custom attributes in their TBOs.
• Use JDK object types as opposed to DFC types.

Auto-filing in Dynamically Created Taxonomy

TBOs are a logical place to implement auto-filing. If your project specific TBOs implement a method to build their filing path they can simply call DctmUtilsDocment.file(String path). This method will dynamically create cabinets and / or folders within the security constraints of the active session.

Best Practice: Auto-filing based on business rules that include a time derived algorithm usually facilitates data organization within a Docbase.

Attach Lifecycles

Out-of-the-box, Documentum does not provide a mechanism to automatically attach a Lifecycle to a document. DctmUtilsDocument.attachDefaultLifecycle() will attach the default Lifecycle that is configured in Documentum Application Builder (DAB).

Best Practice: Every custom document object should have at least a default Lifecycle.

More Flexible Security

TBOs are a logical place to programmatically set ACLs based on business rules.

DctmUtilsDocument.setAcl(String aclName)

Best Practice: Keep it Simple! Avoid complex business rules for document security if possible.

Test Driven Development

It is not only possible, but highly advisable to use test driven development practices when implementing TBOs.

Best Practice: Read Test Driven Development for Documentum

Packaging

All TBOs should be in separate packages. Including multiple TBOs in the same package or putting the interface and implementation in the same package have lead to ClassCastExceptions.

Ant example:

<!-- Reference Document TBO -->
<jar destfile="${tbo.dist.dir}/${du.reference.doc}-impl.jar">

<fileset dir="${javac.dest}" includes="**/DctmUtilsTbo.class ${du.reference.doc.package}/impl/*"/>

</jar>

<jar destfile="${tbo.dist.dir}/${du.reference.doc}-client.jar">

<fileset dir="${javac.dest}" includes="**/IDctmUtilsTbo.class ${du.reference.doc.package}/*"/>

</jar>

Base Class and Interface

Use DctmUtilsDocument as the base class and IDctmUtilsDocument as the base interface for your projects enterprise TBO.

Feedback