Documentum Object Model and the Alfresco Content Model

The Documentum object model and the Alfresco content model have many similarities. Both software packages have the concept of library services (check in / check out), a data dictionary, and a hierarchical data model however implementations do differ.

In Documentum, administrators can create or alter custom object types with the use of Documentum Administrator, Composer, Application Builder, or DQL or API scripting. In Alfresco, there is one common way to create a custom type, including any constraint or pick list values. The configuration to create a custom object type includes creating a custom model Spring context file, a custom model definition file, and a custom web client configuration file.

The labels that are displayed for the properties are controlled either by the name given to the property or by a display-label element in the web client configuration XML file. In addition, using a custom converter on a property gives a client application more fine grained control about how property values are displayed; furthermore, Alfresco also offers toolkits for use with its Share client that provide greater control and more options using Freemarker templates over how properties are displayed.

An alternative to creating a custom type in Alfresco is to create a custom aspect. An aspect is a collection of properties that can be applied to an existing content type. The aspect can be applied to an individual item, all documents in a space (folder in Alfresco), all content of a type, or all content in the repository.  Aspects provide additional flexibility by allowing properties to be selectively applied to content within the repository as well as searched. We have found that many Alfresco customers prefer using aspects to creating custom types.

Alfresco allows for more property types than Documentum. In Alfresco a property can be not only a text string, integer (long int), float (double), date, datetime, and Boolean, but also content, category, and path. The content property is for storing a binary document, the category property refers to a category within a classification, and finally, path is used to store a URL. Like Documentum, properties can be required or optional. Properties can also be composed of repeating values. A default value for a property can also be defined in the content model definition XML file.

Constraints on what values can be stored in a property are defined in one of four ways: regular expression, a value list, numeric range, or character length. A java program can also be written and used to evaluate properties. If the constraint is a value list, it is displayed as a drop down in the web client by default.

Finally, Alfresco also allows the definition of an association between content types when specifying a content model. This can be very useful by allowing a user to relate a content file of one type to a content file of a different type.

We recently had a client create an Alfresco content model based on one from Documentum.  Starting with Alfresco’s cm:content (equivalent to dm_document) we created a child type for the company and then two child department content types. This structure mimicked the previous hierarchy.  Since we were moving documents as part of a migration, we were able to also move similar departmental properties to the company type so they could be shared among all documents.  The migration also gave us the opportunity to enforce new constraints on the properties and clean up the data ensuring a better searching experience for the user.

This article has highlighted a few differences between the Documentum and Alfresco content model. We’d love to hear if you have any additional questions or thoughts about how the two systems behave similarly and differently.