New in D6 Platform: Aspects

The long wait for D6 (Documentum Version 6.0) is over and the D6 product and documentation downloads are now becoming available. Note, however, that it is not a synchronized release of the complete suite of Documentum products. While version 6.0 of the core products (Content Server, Webtop, DA, etc.) is available now, it may take months for the complete suite to become available in version 6.0. So plan according to their release schedule and you will be well-advised to wait for service pack 2 before going to production.

D6 continues to have the rich detail in its documentation that it has had in the past. After a cursory look at the documentation, it seems that the changes in D6 relative to 5.3 have been called out decently. However, full details of these changes still remain embedded in multiple documents. Here, I will share some of these topics in detail with an attempt to present the new/changed concepts in simple terms. In one of my other posts I had discussed aspects in Alfresco. The general concept of aspects remains the same while we take a look at the specifics in D6 here.

Overview

In D6, aspects add a new framework for extending object behavior and attributes. Recall that behavior and attributes (properties) for objects are managed through object types. However, an object type applies to all objects of that type (and of its subtypes, via inheritance). In contrast, aspects allow you to attach additional behavior and attributes to an object, independently of its type. Using aspects can speed up development and improve code reuse, because they offer the possibility of extending attributes and behavior without altering the underlying type definitions. However heed the caution in the other post regarding the abuse of aspects.

Let’s explore the concept, constraints, and implementation specifics about aspects in D6 with some examples below. Note that the information presented below is based on the available documentation for D6. At the time of writing this post the Content Server API Reference was not available for D6.

Example

Let’s start with an example. Suppose that an organization manages documents for projects within Documentum. The documents that are related to projects must have an attribute called project, which identifies the project that a document is related to. Note that this relationship is cross-cutting as far as object types are concerned. In other words, any object (no matter what its type) can be associated with a project. On the other hand, there will be many objects that have nothing to do with projects. This is a perfect situation for utilizing aspects. (Note that there are other alternatives for capturing this information but we are illustrating aspects here)

In this scenario, consider the documents:

1. mydoc.txt of type dm_document
2. mydoc.doc of type dm_document
3. myemail of type dm_email_message

mydoc.doc is related to project A, myemail is related to project B, while mydoc.txt is not related to any project. We can create an aspect named project_oriented with one attribute – project (It could contain additional project-related attributes if needed). Now we can attach this aspect to mydoc.doc and to myemail. As a result, the attribute project will become available on these objects and can be set to the respective project names.

Constraints

Probably, one question would have already popped up in keen readers’ minds – Are aspects allowed only on certain types of objects? Even though aspects can be attached independently of the type of object, aspects cannot be attached on arbitrary types of objects. Aspects can be attached under the following conditions on types:

1. An aspect can be attached to any object of type dm_sysobject or one of its subtypes.
2. An aspect can be attached to any object of NULL type (type with no supertype), once the type has been altered to allow aspects.

Another question is – Can multiple aspects be attached to one object? The answer is yes. In the example above, assume that there is another aspect called web_viewable. Then, myemail can have two aspects attached – project_oriented and web_viewable. The corresponding aspect properties (and methods) will become available on myemail. Note, however, that one aspect cannot be attached multiple times to the same object.

Managing Aspects

An aspect can be created using Documentum Application Builder. I expect other ways of creating aspects but I am unable to confirm that based on the available documentation.

It is possible to drop or modify existing properties or add new ones to an aspect. Such changes to an aspect immediately affect objects to which the aspect is currently attached.

Aspects can be altered using DQL as well. For example, the following DQL statement adds the project property to the aspect.

ALTER ASPECT project_oriented
ADD (project string(32))
OPTIMIZEFETCH


The keyword OPTIMIZEFETCH is explained later.

By default, aspect properties are not fulltext-indexed. However, aspect properties can be selectively configured to be full-text indexed. The following DQL configures all the attributes of the aspect to be full-text indexed.

ALTER ASPECT project_oriented
ADD_FTINDEX ALL


Using Aspects

If the object under consideration is of a NULL type, the type must first be altered to allow aspects on its objects. For example:

ALTER TYPE my_null_type ALLOW ASPECTS

This DQL statement performs the following actions:

1. Adds the repeating property – r_aspect_name, to the type definition of my_null_type if it does not have the property already
2. Adds the i_property_bag property to the type definition of my_null_type if the type does not have the property already

The central operation with aspects is to attach an aspect to an object. Unfortunately, I have been unable to locate this information in the currently available documentation.

The Content Server Fundamentals document and the DQL Reference document disagree about the qualifiable (A non-qualifiable property can be referenced in selected value lists, but may not be referenced in expressions or qualifications in a query) nature of aspect properties, so I am not sure which one is correct. If you are wondering about the significance of this nature, just remember that you will not be able to use a non-qualifiable property in the WHERE clause of DQL queries.

According to Content Server Fundamentals (pg 112)

Aspect properties are qualifiable properties. You cannot define an aspect property as a non-qualifiable property.

According to DQL Reference (pg 49)

Properties for a particular aspect must be either all qualifiable or all non-qualifiable. An aspect cannot have some properties that are qualifiable and some that are non-qualifiable.

Even though aspects are not automatically tied to object types sometimes you may have a need to do just that (often for convenience). For example, we may have an existing type called web_doc and we may want all objects of web_doc (and of its subtypes) to have the aspect web_viewable attached. If an aspect is associated with an object type, the aspect is automatically attached to each new object of the specified object type. Such an aspect is called a default aspect for the specified type. Of course, this aspect can still be attached to objects of other types (subject to constraints mentioned earlier). Default aspects can be specified as follows:

ALTER TYPE web_doc
ADD DEFAULT ASPECTS project_oriented, web_viewable


Multiple default aspects can be associated with one object type. An object type inherits all the default aspects defined for its supertypes. When you add a default aspect to a type, the newly added aspect is only associated with new instances of the type or subtype created after the addition. Existing instances of the type or its subtypes are not affected. Similarly, removal of a default aspect does not affect the existing instances of the type.

In a SELECT statement, aspect properties must be qualified by aspect name. For example:

SELECT project_oriented.project FROM web_doc

If there are multiple type names in the FROM clause the type name must also qualify the aspect name. For example:

SELECT web_doc.project_oriented.project, hr_doc.object_name
FROM web_doc, hr_doc
WHERE ...

Under the Hood

An aspect is a BOF (Business Object Framework) module that customizes behavior or records metadata or both for an instance of an object type. It is represented by an object of type dmc_aspect_type.

Content Server creates and manages an internal object type for each aspect. The names and definitions of aspect properties are stored in this internal type. The internal type is named dmi_type_id where type_id is the object ID of the internal type.

Incorporating aspect properties with regular object type properties in normal interaction adds computational overhead. Therefore, an option for enhancing query performance for aspects is available. If the OPTIMIZEFETCH keyword is specified in the ALTER ASPECT statement, it directs Content Server to store all the aspect’s properties and their values in the property bag of any object to which the aspect is attached, if the object has a property bag. (NOTE: property bag is also a new concept in D6 and is discussed in more detail in my other post)

Default aspects for an object type are recorded in the default_aspects property in the corresponding dmi_type_info object.

Conclusion

D6 has made the power of aspects available for new Documentum deployments. However, the complete Content Server documentation needs to be available for gaining an effective grasp on the depth and breadth of the available functionality. It will also be interesting to find out how the core applications such as Documentum Administrator and Web Publisher support and make use of aspects.

Advertisement