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.

6 thoughts on “Documentum Object Model and the Alfresco Content Model

  1. This is really helpful for person like me who is trying to learn Alfresco and having DCTM experience.


  2. It seems that in your write up you elude that Aspects are not available in Documentum. That was included in Documentum as of D6. I just was wondering why this was mentioned as a difference or were you working with a pre-D6 version of Documentum?

    • Documentum definitely does have an aspect capability similar to Alfresco. From what I understand they are useful when you need to apply a select number of attribute values or behaviors across types that are not related by type inheritance. Personally, I have not encountered them. In Alfreso I think an aspect is required to make an object versionable it is just something that is more pronounced.

      • I am sure that you have seen more about aspects in the Documentum 6.5 book that you have reviewed in another post. Aspects are certainly available for customization and supported in Documentum Composer for development. It is easy to agree though that it may take some time for the feature support to mature in the platform. I feel that you are highlighting the difference that Alfresco seems to be using aspects from ground up for its built-in capabilities while aspects in Documentum provide an add-on capability for customization, introduced in version 6.0.

Comments are closed.