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 object can be assigned to objects of the server hierarchy (IDomain, ISite, IVirtualServer, and IServerInstance), and is persisted in the GCD. To create a |
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 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 Some site-specific settings might override the settings configured here. For more information, see the 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
|
IContentCacheConfiguration | Defines the configuration for a content cache. This includes, in particular, the file storage area for the cache (the property). A cache configuration can be associated with a server or with a group of servers. More specifically, a 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 object can be assigned to objects of the server hierarchy ( , , , and ), 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 To create a new instance, call The |
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 constant class contains the trace log settings available. These settings can be ORed together to apply multiple settings to a subsystem. The property on this ( ) class enables or disables trace logging for all of the configured subsystems. Use the 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 object is contained in the property of , , , and objects. The object used is the first occurrence found by searching (in this order) the instance, the instance, the instance, and the 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. |