Business object management

Traditionally, a document management system manages document content and the metadata, or properties, that further describe the document. Content Platform Engine provides document management capabilities plus the ability to manage other types of data.

Object stores manage traditional office documents plus customer information and loan documents. In this context, the term business object refers to any object that is stored and managed in the system and includes both structured and unstructured data. For example, the following diagram shows four business objects: Loan, Loan Application, Customer, and Loan Policy.

Diagram showing four sample business objects

As illustrated in the diagram, an object might or might not have content. The Loan Application object has an image in TIF format as its content; the Loan Policy object has a Word document as its content.

The Customer object is an example of an object that has no content, but is simply a collection of properties that describes a customer. The Loan object is an example of a folder object that can contain loan-related documents that are visible through the inherited Containees property of the folder object.

The system comes with a set of predefined classes, called base classes, including Document, Folder, Annotation, and CustomObject. The base classes define the behavior for most business objects. You can create subclasses that define variations of the basic class types. For example, the Loan class in the example is a subclass of the Folder class because it requires container behavior. That is, it is a folder that contains the various documents that are associated with a loan.

When you create a subclass based on a base class, you can define:
  • Custom properties that are used to provide business-related metadata, for example Loan ID and Customer.
  • The default access rights for the object.
  • The default security policies that can be applied to the object.
  • Event subscriptions for performing custom actions that are executed when the object is added or updated.
  • Where the document content is stored, whether the document can be versioned, its lifecycle policy, and any automatic classification templates.

The Loan class has been customized by adding a Loan ID and Customer property.

Content Platform Engine enforces the behavior of the base Document, Folder, Annotation, and CustomObject classes as described in the following sections.
Document
Most users think of a document as a file they create with an application such as Microsoft Word. The user stores the document in the document management system so that a history of changes to the document is maintained and the document can be easily found and edited. Users who design or manage enterprise content management applications need to understand how documents can be used to support various application needs. A document might be used to maintain a traditional electronic file as well as other types of data, such as an XML document or content that is managed in an external repository. Documents:
  • Have system properties that the system manages automatically, such as Date Created.
  • Can have custom properties for storing business-related metadata about the document.
  • Are secured.
  • Can have content that can be indexed for searching.
  • Can point to content that is outside of the object store (external content).
  • Can have no content (metadata only).
  • Can be versioned to maintain a history of the content over time.
  • Can be filed in folders.
  • Can have a lifecycle.
  • Can participate in business processes as workflow attachments.
  • Can generate server events when they are created, modified, or deleted. These events are then used to customize behavior.
  • Can be rendered to different formats, such as PDF and HTML.
  • Can be published to a website.
  • Can be annotated.
  • Can be audited.
Folder
A folder is a container that is used to group other objects. Folders are the primary mechanism through which users access documents. Users typically think of folders as a place where documents are stored; however, filing documents in multiple folders does not create extra copies of those documents, but rather creates a logical association between the folder and the document. Folders:
  • Have system properties that the system manages automatically, such as the date created.
  • Can have custom properties for storing business-related metadata.
  • Are secured.
  • Are hierarchical, in the sense that a folder can have subfolders.
  • Can contain documents and custom objects.
  • Can generate server events when they are created, modified, or deleted. These events are then used to customize behavior.
  • Can be annotated.
  • Can be audited.
Annotation
An annotation object, as shown in the following image, represents incidental information that can be attached to an object for annotating or footnoting that object. You can associate annotations with custom objects, documents, and folders.
Screen capture showing annotations in an object
Annotations:
  • Are independently securable. Default security is provided by the class and by the annotated object. An annotation can optionally have a security policy assigned to it.
  • Can have subclasses.
  • Can have zero or more associated content elements, and the content does not need to have the same format as its annotated object.
  • Are uniquely associated with a single document version, and thus are not versioned when a document version is updated.
  • Can be modified and deleted independently of the annotated object.
  • Can be searched for and retrieved.
  • Can subscribe to server-side events that fire when an action (such as creating an annotation) occurs.
  • Can participate in a link relationship.
  • Can be audited.
Custom objects
A custom object is used to store and manage data that does not have content (and thus does not support versioning) or a lifecycle. For example, a customer might be represented in the object store as a custom object because there is no requirement for content. Custom objects:
  • Have system properties that the system manages automatically, such as Date Created.
  • Can have custom properties for storing business-related metadata.
  • Are secured.
  • Can participate in business processes as workflow attachments.
  • Can generate server events when they are created, modified, or deleted. These events are then used to customize behavior.
Custom root classes
Custom root classes offer broadly similar functionality to custom objects, but are capable of superior performance and scalability. Like a custom object, custom root classes are used to create general-purpose objects of custom properties. Custom root classes:
  • Have system properties that the system manages automatically, such as Date Created.
  • Can have custom properties for storing business-related metadata.
  • Are secured.
  • Can participate in business processes as workflow attachments.
  • Can generate server events when they are created, modified, or deleted. These events are then used to customize behavior.
  • Do not carry content.
  • Are not versionable.
  • Do not support lifecycle functionality.

The following diagram shows the classes for the Loan-related objects.

Classes for Loan-related objects that are used in preceding examples

There are many additional object types beyond Document, CustomObject, Folder, and Annotation. For example, each custom class that is created (such as the Customer class in the previous example) is managed as an object in the system. This means that system capabilities, such as custom properties and custom event actions, can also be applied to these objects.