The following table lists the types derived from ISubsystemConfiguration .

Derived Types

Type Description
IAsyncProcessingConfiguration Represents configuration data for asynchronous processing of events. This class allows admininistrative clients to set or access event dispatcher configuration settings. An IAsyncProcessingConfiguration object can be assigned to objects of the server hierarchy (IDomain, ISite, IVirtualServer, and IServerInstance), and is persisted in the GCD.

To create a IAsyncProcessingConfiguration object, call the CreateInstance method on the IAsyncProcessingConfiguration class. To instantiate an IAsyncProcessingConfiguration object, retrieve the SubsystemConfigurations property from an object of the server hierarchy, then iterate the ISubsystemConfigurationList for the IAsyncProcessingConfiguration object.

ICFSImportAgentConfiguration Configures the importer component of Content Federation Service (CFS). The CFS importer works in conjunction with the CFS exporter to map external documents to FileNet P8 documents in a one-to-one relationship. Specifically, using data extracted from an external repository and loaded into a federator database by the exporter, the importer creates and updates FileNet P8 documents known as federated documents. (For background information on the exporter and on the relationship between the federator database, the IBM Content Integrator instance, and the external repository, see the IIICEFixedContentDevice interface.) A federated document is a FileNet P8 document created as a proxy for an external document, whereby FileNet P8 stores metadata (property values) mirroring the metadata stored in the external repository but keeps only a reference to the external stored content; the federated document accesses the external content in a transparent fashion, and thus behaves, with some limitations, like any other standard FileNet P8 document. The importer creates a new federated document to represent an external document when first importing the external document into FileNet P8. Thereafter, when subsequently re-importing the external document, the importer updates the metadata of the existing federated document.

You can associate this import configuration with a server or a group of servers. Specifically, as with all configuration objects belonging to ISubsystemConfiguration derived interfaces, an ICFSImportAgentConfiguration instance can be associated with the following types of objects (via the SubsystemConfigurations property): IServerInstance, representing one server; IVirtualServer, representing one or more servers; ISite, representing a yet larger grouping of servers and other objects based on a geographic location; and a IDomain, representing the largest possible collection of resources and services sharing the same Global Configuration Database (GCD). On startup, and periodically thereafter, the Content Engine server checks the IServerInstance object representing itself, then the IVirtualServer object representing the virtual server of which it is a part, and so on, searching for the most closely associated import configuration. At least one such configuration always exists, because the automatic creation of a default CFSImportAgentConfiguration object occurs when you first create the domain.

Some site-specific settings might override the settings configured here. For more information, see the ICFSSiteSettings interface.

The importer runs as part of the Content Engine, and one importer exists for each Content Engine instance. Each importer runs against all of the federator databases that have been defined for the domain (via GCD-stored IIICEFixedContentDevice objects); consequently, multiple importers can be operating against the same federator database. Importers process batches of import requests created in the federator database by the exporter, where each import request represents a document version series stored in the external repository. In addition to the external metadata and content, an import request has properties indicating the target document class and the target object store. An importer can process an import request for any object store within the domain. The configuration of import request processing revolves around these importer sub-components:

  • Import Dispatcher - The import dispatcher is the main sub-component of the importer; one dispatcher exists per importer. To enable or disable the dispatcher, set the DispatcherEnabled property.
  • Import Agent - The import agent periodically scans the federator database for incoming import batches, loads the batches into an in-memory federation request queue, and assigns the batches from the queue to the import workers it creates. One agent exists per federator database per Content Engine instance. Consequently, this configuration might govern the behavior of more than one dispatcher. To control the activity level of the agent, set these properties: MaxInMemoryItems and DispatcherWaitInterval.
  • Import Worker - The import worker performs the actual work of creating or updating FileNet P8 documents from the incoming external metadata and content. Each worker exists on a separate thread of execution. To control the number of workers and the distribution of work among workers, set these properties: MaxWorkerThreads, LeaseDuration, and BatchSelectionSize.
IContentCacheConfiguration Defines the configuration for a content cache. This includes, in particular, the file storage area for the cache (the ContentCacheArea property).

A cache configuration can be associated with a server or with a group of servers. More specifically, a ContentCacheConfiguration instance can be associated with the following types of objects: ServerInstance, which represents one server; VirtualServer, which represents one or more servers; and Site, which represents a still yet larger grouping of servers and other objects based on a geographic location. (A cache configuration can also be associated with a Domain, but typically you would not want servers in different geographical sites to use the same cache, since the cache must be local to the server to benefit server performance.) On startup, and periodically thereafter, a Content Engine server checks the ServerInstance object representing itself, then the VirtualServer object representing the virtual server of which it is a part, and so on, searching for the most closely associated cache configuration. Referred to as the primary cache, the first cache found becomes the cache for that server. Otherwise, in the absence of any cache configuration, the server does not use a cache.

In order for a cache area to be used, at least one server must be configured to be part of the same site as the cache.

IContentConfiguration 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.

IImageServicesImportAgentConfiguration Represents configuration data for an Image Services import operation.
IPublishingConfiguration References the configuration data for a publishing operation. This class allows admininistrative clients to set or access publishing-related configuration settings. A PublishingConfiguration object can be assigned to objects of the server hierarchy (Domain, Site, VirtualServer, and ServerInstance), and is persisted in the GCD.
IReplicationConfiguration Represents configuration settings for the replication components of a server.
IServerCacheConfiguration Defines configuration options for all server caches that do not have object store-specific characteristics. The options apply to the following caches: code module cache, GCD cache, marking set cache, metadata cache, subject cache, and user token cache. Options include a time-to-live (TTL) value for managing cache entry residency and a value that, when exceeded, triggers cache refresh activity on a least-recently-used basis. (Object store-related cache options, such as folder cache TTL and object security cache attributes, are set at the object store level.)

The ServerCacheConfiguration object is contained in the SubsystemConfigurationList property of the server hierarchy objects (Domain, Site, Virtual Server, and ServerInstance). To access a ServerCacheConfiguration object, call Get_SubsystemConfigurations to retrieve the SubsystemConfigurationList from the "host" independent object, then iterate the returned list.

To create a new instance, call Factory.ServerCacheConfiguration.CreateInstance and add the new object to the SubsystemConfigurationList of the appropriate server hierarchy object. (Note: The SubsystemConfigurationList of the Domain object cannot be modified. To update its ServerCacheConfiguration object, locate the pre-existing object in the list and update it.) The created object is a dependent object and is only persisted when its parent object (the independently persistable object that references it) is persisted.

The ServerCacheConfiguration object is associated with a Domain, Site, Virtual Server, or ServerInstance object. The values of the cache configuration properties are used while the FileNet P8 system is running and override the default values defined at installation time.

ITraceLoggingConfiguration Configures and enables trace logging on the Content Engine host for the supported subsystems. Each of the supported subsystems is a property on this class, enabling trace logging to be configured per subsystem. Configuring trace logging for a subsystem applies the trace logging settings to all classes in that subsystem. The TraceFlag constant class contains the trace log settings available. These settings can be ORed together to apply multiple settings to a subsystem. The TraceLoggingEnabled property on this (TraceLoggingConfiguration) class enables or disables trace logging for all of the configured subsystems. Use the AppenderNames property to specify the output destination classes for the trace logs.

Trace logging is implemented using the Apache log4j package (org.apache.log4j).

IVerityServerConfiguration Contains the Verity configuration data (properties) for a server instance. This configuration data can differ from one server to the next. A VerityServerConfiguration object is contained in the SubsystemsConfiguration property of Domain, Site, VirtualServer, and ServerInstance objects. The VerityServerConfiguration object used is the first occurrence found by searching (in this order) the ServerInstance instance, the VirtualServer instance, the Site instance, and the Domain instance.

None of the properties on this object must be set or changed to enable full text indexing. This object is used only to address performance issues.

See Also