Configures the Content Management Subsystem. The Content Management Subsystem is the part of the Content Engine Object Store Service that is responsible for adding and retrieving document content to and from managed storage areas in response to client requests. The ContentConfiguration interface allows the operation of the Content Management Subsystem to be tuned for the local environment in which it is executing.

Just as it must do for all other client requests involving the creation, update, or deletion of data in an object store, the Object Store Service must also guarantee transactional integrity with respect to adding content. Guaranteeing the transactional integrity of content upload and storage is one of the primary functions of the Content Management Subsystem.

In order to make this guarantee, the process of adding content is divided into two stages: Stage one involves copying content into a temporary location on the server while stage two is primarily concerned with copying the content to its permanent location.

Stage one occurs within the context of a client initiated transaction involving content upload; for example, checking in a document. In this stage, the content associated with the object or objects participating in the transaction are copied from the client to a temporary location that is associated with the designated storage area in which the content will ultimately be stored. This temporary location may be a specially designated file system directory, sometimes referred to as the "inbound directory" or it may a table in the database. The type of temporary storage depends on the destination storage area type. Any metadata changes associated with the participating objects are also carried out at this during this stage.

At the conclusion of the first stage of the operation, the transaction must be committed in order to make the changes durable. Committing the transaction includes adding a message to the ContentQueue, when processed, that will result in the second stage of the operation to be executed. The fact that the transaction has been committed after stage one necessarily implies that the server guarantees that the second stage will be carried out - even in the event of server disruptions, power failures, etc.

It is important to note that after a transaction involving content upload has been committed, that is, after stage one has completed, the new content has functionally been added to the storage area; a user can retrieve (or perform any other legal operation) on the new content just like any other content in the storage area, despite the fact that it may actually still reside in the temporary storage location.

At the conclusion of stage one of the operation or at anytime during its execution, the transaction can also be aborted and, therefore, must be rolled back. Rolling back a transaction in simple terms means guaranteeing that any intermediate changes that occurred during the execution of the transaction will be undone so that the system is restored to the state that it was in prior to the transaction and guaranteeing that none of these changes will be visible to any other transaction while they are being cleaned up.

With respect to content upload there are two categories of changes that need to be undone: Metadata changes and content that has been copied to the temporary storage area. The cleanup of the former is handled by the normal transaction processing mechanisms provided by the Object Store Service but the latter is a special case and is managed by the Content Management Subsystem. The way it works is temporary content is flagged as "abandoned". While it is in this state it is invisible to clients and is effectively "not there" from the client's point of view. The Content Management Subsystem then periodically sweeps the temporary storage areas and deletes all abandoned content.

Many of the functions of the Content Management Subsystem described above are parameterized such that their behavior can be modified. This is the purpose of the ContentConfiguration interface: To expose those aspects of content operations that can be adjusted in order to optimize the performance of the Object Store Service within a given operational environment.


Namespace: FileNet.Api.Admin
Assembly: FileNet.Api (in filenet.api.dll)

Syntax

Visual Basic (Declaration)
Public Interface IContentConfiguration
    Implements ISubsystemConfiguration, IEngineObject, ICloneable, IDependentObject
C#
public interface IContentConfiguration : ISubsystemConfiguration, IEngineObject, ICloneable, IDependentObject
C++
interface class IContentConfiguration : ISubsystemConfiguration, IEngineObject, ICloneable, IDependentObject
J#
public interface IContentConfiguration implements ISubsystemConfiguration, IEngineObject, ICloneable, IDependentObject
JScript
public interface IContentConfiguration extends ISubsystemConfiguration, IEngineObject, ICloneable, IDependentObject

Remarks

Metadata

Auditable: false
AllowsInstances: true
AllowsSubClasses: false
ClassDefinitionName: None
IsDependent: true
IsHidden: false
Searchable: false
StorageType: Domain
SuperclassName: SubsystemConfiguration

See Also