In this article by Pawan Kumar, we look at the Custom Types in Documentum. We will see how to manage the custom types by looking at how to create a custom type and modify the custom type. We have also introduced the concept of data dictionary, which stores additional information about custom types.

Custom Types

Documentum provides a large number of built-in object types that support the functionality of the platform. Some object types are general purpose and can be used for business purposes as well. However, all possible business needs can neither be anticipated nor supported by default. Therefore, Documentum allows creation of new object types, which are called custom types. This article addresses creation and management of custom types.

Before reading this article, it would be helpful to know about Objects and Types, since the majority of the concepts pertaining to object types apply here as well. Some concepts are explained here.

Managing Custom Types

A user-defined object type is called a custom type and the user-defined properties are called custom properties. Properties are also known as attributes. Custom types can be created, modified, and removed as long as certain rules are followed. This section describes the detail around managing custom types.

Creating a Custom Type

A custom type can be created using Documentum Application Builder (DAB), using Documentum Administrator (DA), or using DQL/API scripts. DAB is the most commonly used application for creating custom types since it fully supports the data dictionary (see Data Dictionary later in this article) and it has a Graphical User Interface (GUI) specifically designed for creating and managing custom types.

Further, DAB can also be used for packaging the types into a DocApp. The following screenshot shows the DAB screen for creating and updating a custom type:

DA provides basic support for managing custom types. For example, DA does not provide an interface for defining value assistance for a property. The following screenshot shows the screen for creating and updating custom types in DA:

Creating a custom type is a privileged operation and only the users with following privileges can do so:   

• Create Type
• Sysadmin
• Superuser       
  

The user creating the type becomes the owner of the type.

A custom type can extend an existing type through inheritance (see Type Hierarchy in Documentum). A new custom type can have an existing custom type or one of the sets of Documentum object types as its supertype. The most common supertype for a new custom type for representing documents is dm_document.

It is also possible to create a custom type without a supertype. Such a type is called a NULL type. Only a user with Superuser privilege can create a NULL type. A NULL type is useful for storing data that does not need the usual object management features such as versioning. There are several built-in types that are NULL types such as dm_user, dm_session, and dm_alias_set. If a custom type is intended to only store non-versionable data, a NULL type may be appropriate for this purpose. Recall that any given type uses up to two tables (one for single-valued properties and one for repeating) of its own for storing non-inherited properties of its objects. There are additional views for retrieving all the properties together. The following key information is needed or captured in DAB when creating a new custom type:

Events for Types

An event is an operation on an object or something that happens in an application. A system event is an event that is recognized and is auditable by the Content Server. For example, checking on a particular document in a system event. Promoting or demoting an object in a lifecycle is also a system event.

On the other hand, an application event is recognized and is auditable only by the application. The application events can be defined using DAB. For example, an application event can be used to hold off workflow activities based on external dependencies such as conditions in other systems.

Suppose that a workflow activity requires a performer to review a document. However, the performer needs access to data in another system in order to complete this task. An application event can be sent to the performer's inbox to trigger the activity once the required data is available in the other system.

The following screenshot displays the DAB screen for managing application events:

Note that events are also inherited from supertypes just like properties. The events shown in the previous screenshot, are inherited from dm_document—these are system events and cannot be modified or removed.

This article has been extracted from: Documentum Content Management Foundations: EMC Proven Professional Certification Exam E20-120 Study Guide

Learn the technical fundamentals of the EMC Documentum platform while effectively preparing for the E20-120 exam Technical foundations of the Documentum platform Thorough preparation guide for the E20-120 exam Complete coverage of the prescribed syllabus Illustrated examples and practice questions on each topic Two full-length practice tests with answers For more information, please visit: http://www.PacktPub.com/Documentum-Certification/book

Properties

An object type inherits all the properties of its supertype. Custom properties can be created for custom types, with each property being defined in the following manner using DAB:

The following screenshot shows the DAB screen for managing a custom attribute:

Search Support for Properties

Some information about properties can be provided to support the user interface for searching on this custom type.

Displaying Properties

Client applications can utilize display configurations to display properties for different object types in different ways. Display configurations are created using DAB. Documentum Desktop (also known as Documentum Desktop Client) and WDK applications utilize display configurations extensively. WDK applications such as Webtop use display configurations to include custom properties in the standard interface without writing any additional user interface code.

For example, Webtop can display custom properties in an editable form on a separate tab on the properties page using a display configuration. The following screenshot shows creation of a Display Configuration named Resume. When the properties of an object of type dq_resume are viewed in Webtop, a separate tab named Resume will use this display configuration to display the attributes included in it.

A display configuration specifies when certain properties should be displayed and how their display should be organized. Each display configuration specifies three aspects:

    
1. Scope determines when to use this display configuration. It can be a combination of an application and a role, implying that this configuration should be used when the specified role is accessing an object of this type in the specified Documentum application. Thus, even within the same application it is possible to create different views of the same object for different roles.
    
2. For each scope, multiple configurations can be defined. For example, Webtop displays the configurations as tabs on the properties view of objects.
    
3. For each configuration, an ordered list of properties is specified, which constitutes the configuration. These properties are displayed together in the Documentum application.

Note that, implicitly, the properties not included in display configurations are not displayed on the application interface. Thus, display configurations can be considered as a way of exposing or hiding custom properties.

Validation

Constraints are conditions that must be met by objects and properties to be valid. For example, a custom type may represent an account with a property account ID. Then a potential constraint on this type is that the account ID property is required to be unique within the repository. Constraints for custom types can occur in the following forms: