IBM FileNet P8, Version 5.2

Custom Root Classes

Custom root classes share the general attributes of any other root classes in the Content Engine class hierarchy, such as Document, Folder, CustomObject, Annotation, and Link. A root class does not inherit from any other business object and can be subclassed. Each root class and all of its subclasses reside in a separate table in an object store database. It is not possible to query across root classes, nor is it possible to change the class of an object to another class that does not fall below the same root class.

Custom root classes offer broadly similar functionality to CustomObject subclasses, but are capable of superior performance and scalability. Like CustomObject, custom root classes are used to create general-purpose objects of custom properties. CustomObject and custom root classes do not carry content, are not versionable, and do not support lifecycle functionality.

Instances of CustomObject and subclasses are stored in the Generic table. If multiple CustomObject subclasses with disjoint uses are defined, and if the retrieval requirements for each of the subclasses vary, then performance of custom object queries on the Generic table can suffer.

For custom root classes, each newly created root class results in dynamic generation of a new table. The table is used solely to store instances of the custom root class and subclasses created from the root class. For table naming conventions for custom root classes, see Custom Table and Column Names.

Using dedicated tables accrues the following benefits:

Because instances of the same root class are not disjoint, indices can be applied as needed, leading to much faster retrieval rates.
Data storage can be better managed.
Content Engine auto-creates and auto-deletes tables (and other related objects) as needed.
Unlike built-in tables, custom roots permit index creation on system-owned columns, providing custom tunability.

Unlike CustomObject, the following limitations exist with custom root classes:

Change class is not permitted across custom root hierarchies (change class cannot span different tables).
Searches cannot be performed across custom root hierarchies.
Containable behavior is not supported.

Abstract Class Definitions

You create a concrete custom root class by subclassing an abstract class definition supplied by the system. An abstract class definition is neither instantiable nor queryable, and cannot be extended with properties. But the custom root class is instantiable, queryable, and extendable.

The behavior of a custom root class is determined by the particular abstract class definition on which it is based. Custom root classes can be subclassed from the following abstract class definitions:

CmAbstractPersistable provides replication and subscribable functionality.
CmAbstractQueueEntry provides compatiblity with queue sweep tasks.
CmAbstractSequential provides support for custom objects that need to be processed in strict chronological order. It also allows for custom applications that require their own form of queue processing and control.