Abstract superclass for the accumulation of batch items for a pending batch operation. The batch is a collection of BatchItemHandle instances.

Provides type-specific static inner classes for creating instances of Content Engine classes and their associated collections. The name of each inner class parallels the type of object you wish to create. The use of these type-safe classes and methods promotes programming safety, is self-documenting, and provides good auto-completion help in most IDEs. Some application types require more generic methods for instantiating independent objects within a scope. Such methods are provided by the IInstantiatingScope interface.)

Creates a batch operation to retrieve objects.

Once created, the batch operation is pending until you call the RetrieveBatch method to perform the operation.

Creates a batch operation to update persisted objects.

Once created, the batch operation is pending until you call the UpdateBatch method to commit the operation. The entire batch operation is executed within a single transaction.

Represents an annotation that can be applied to a document, folder, or custom object. An Annotation object allows you to link additional information to a containable object. You can modify and delete annotations independently of their annotated object. However, you cannot create versions of an annotation separately from the object with which it is associated. Document annotations are uniquely associated with a single document version; they are not versioned or carried forward when their document version is updated and a new version created. By design, an annotation is deleted whenever its associated parent object is deleted. Although an annotation receives its default security from both the annotation's class and parent object, you can apply security to an annotation that is different from the security applied to its parent.

To create a new Annotation object and associate it with a document, use the document object's CreateAnnotation method. To create a new Annotation object and associate it with a folder or custom object, first use the Factory.Annotation.CreateInstance() method to create a new Annotation object, then set its AnnotatedObject property to reference the object to which you want it associated. An annotation's content data can be specified via its ContentElements collection.

References objects for batch operations.

A batch contains a list of BatchItemHandle instances. Methods are provided to retrieve the object referenced by a batch item and identify an exception (if any) associated with the item.

Customizable base for classes of objects that can provide basic subscribable and replicable independently persistable behaviour. As an abstract class definition, the class' metadata is not mutable. You must subclass this class to create a concrete root class with customizable metadata.

See Custom Root Classes Concepts

Represents a single work item to be completed as part of a process that might involve multiple related or independent work items. Task objects support workflow-based applications with multiple steps and user roles, such as the processing of insurance claims or loan applications.

ICmTask is a base class that does not allow instances. You create instances from subclasses of ICmTask. An instance is created with a Factory method and is independently persistable. Custom properties can be defined in a subclass to provide either inputs necessary to complete the task, or to provide a place to collect the results of the task. Custom properties will often be object-valued properties, referencing documents or other business objects relevant to the task.

A ICmTask object has a "coordinator", a IContainable object such as a IFolder, IDocument, or ICustomObject. The coordinator object associates the ICmTask to a business object that defines a process, of which the ICmTask represents a single piece of work in the task. All tasks that participate in the process have the same coordinator.

ICmTask objects might have successor and predecessor tasks, which, collectively, define the order that all tasks execute in a process. Predecessor-successor associations are specified by ICmTaskRelationship objects.

A ICmTask object has state, a server-defined value that indicates how the task has progressed towards completion. A ICmTask object drives and responds to state changes through events and subscriptions. To allow task automation, every state change generates a ChangeStateEvent, which may be subscribed to or configured for auditing.

Optionally, a ICmTask object has pre- and post-conditions. A pre-condition must be met before the ICmTask object can move into a state where it is ready to be worked on. A post-condition must be met before the ICmTask object can be completed. Conditions are expressed as an SQL predicate applied to the ICmTask object itself, or to objects related to the ICmTask through object-valued properties.

For more information, see Task Concepts.

Defines a predecessor-successor relationship between two ICmTask objects. A ICmTask object can be referenced by more than one instance of this class, and, consequently, can be designated as a ICmTask object in more than one relationship. This capability allows many-to-many predecessor-successor associations to be maintained between tasks. Given that a process can consist of multiple tasks that are coordinated by the same business object, the ICmTaskRelationship objects referencing these tasks collectively define the overall sequencing of the process.

A ICmTaskRelationship object is subject to the following constraints:

• The predecessor and successor must be different ICmTask objects.
• Both referenced ICmTask objects must have the same coordinator.
• Cycles are not permitted in the relationships between tasks. For example, you cannot have task relationships where TaskA has TaskB as a successor and TaskB has TaskA as successor.
• At most, one ICmTaskRelationship is allowed for a given predecessor-successor task pair.

Created with a Factory method, a ICmTaskRelationship object is independently persistable. However, it is not independently securable; it takes its security from the predecessor ICmTask object. For example, users with write permission to the predecessor ICmTask object have the same right to the ICmTaskRelationship object referenceing the predecessor. Permission to delete a ICmTaskRelationship object requires deletion rights on the predecessor ICmTask object. Deletion of a ICmTaskRelationship object does not delete the predecessor-successor ICmTask objects referenced by the ICmTaskRelationship object .

Note that deletion of a task cascades to any task relationships referencing that task as either a predecessor or successor, but the deletion does not cascade through the task relationships to other referenced tasks.

For more information, see Task Concepts.

Represents a thumbnail image corresponding to a ContentElement of a Document. A thumbnail takes the security of its associated document.

See Thumbnail Concepts.

Defines a hierarchical relationship between two documents as components in a compound document.

One document is the designated parent component (ParentComponent property) and the other is the designated child component. The child component document can be either a P8 Content Engine document (ChildComponent property) or a URI document (URIValue property). A document can be referenced by more than one instance of this class and consequently can be designated as a component in more than one relationship; this capability allows documents to be networked together to form compound documents with numerous components.

The two documents in a component relationship might be bound to each other as a result of that relationship. Document binding means the child component document exists in the child documents collection (ChildDocuments property) for the parent component, and the parent component document exists in the parent documents collection (ParentDocuments property) for the child component. This binding can be conditional; for example, it can be conditional on the value for one of the properties on the child document matching an expected value. Also, the child component can be a URI document instead of a Document object. Consequently, not every component relationship results in a document binding. For more information on component relationship types and which properties you are required to set when you create a new ComponentRelationship object, see the ComponentRelationshipType property.

The two documents in a component relationship do not have to belong to the same object store. Also, these documents can continue to be used and referenced as individual documents, just as if they had never entered into a component relationship with each other.

The parent component document determines security for each instance of this class. Users with write permission (AccessRight.WRITE) to the parent component have the same rights to that component relationship instance. Permission to delete a component relationship instance requires AccessRight.DELETE or AccessRight.UNLINK rights on the parent component document.

Represents a logical connection to a FileNet P8 domain.

A domain connection is required to obtain a reference to any object stores within that domain. A Connection object contains information, such as configuration options, needed to execute an operation on the Content Engine server that runs in the FileNet P8 domain.

A Connection object contains enough information to establish communication with the Content Engine server. This information is carried in a URI and includes the transport protocol (connection type), host name, and port number that are used for server communication. An incorrect configuration, such as an incompatibility between the environment and the information in the Connection object, is the most frequent cause of an exception related to a connection failure. For example, if the URI carried by the Connection object specifies the EJB transport protocol, but an EJB .jar file is not in the classpath, the API throws an exception.

You can create a Connection object by calling one of the static GetConnection methods on the Factory.Connection class.

Once you have obtained a Connection object, you can call its methods to retrieve information about the connection. All engine objects maintain a reference to the Connection instance, which you can retrieve by calling the engine object's GetConnection method. The Connection object is also used as an input to factory methods that create other objects. Examples are Factory.Domain.GetInstance(Connection conn, String name) and Factory.EntireNetwork.GetInstance(Connection conn).

Represents the base class for all objects that can be contained. Folder objects and their subclasses can be directly contained in a Folder object, or referentially contained (using the ReferentialContainmentRelationship or DynamicReferentialContainmentRelationship classes). All other Containable subclasses are referentially contained.

Note Folders that are referentially contained cannot participate in hierarchy index searches.

Models containment relationships. These can be either ReferentialContainmentRelationship or DynamicReferentialContainmentRelationship objects.

Represents the superclass for classes used to access document or annotation content data. Each content element represents content data, which can either be local to an object store (represented by an ContentTransfer object) or external to an object store and therefore outside the control of the Content Engine server (represented by a ContentReference object).

Represents external content data that exists outside of an object store (and therefore outside the control of the Content Engine server), but to which an object store maintains a reference. The URL of the resource that contains the content data is stored in the ContentLocation property.

Represents content data that is local to an object store and directly managed by the Content Engine server.

Represents a general interface that can be subclassed. A CustomObject object has no inherent semantics, but is independently securable and can be persisted to an object store. A CustomObject does not carry content, is not versionable, and does not support lifecycle functionality.

The ICustomObject base interface provides a minimal set of properties (such as Creator, DateCreated, and Name). Unlike most Content Engine objects, the ICustomObject base interface does not have a specific property defined as the name property in order that subclassed objects can define it in an appropriate way. Because a CustomObject object does not have a defined name property, the value of its Name property reverts to the default value, which is the same as its ID property.

Indicates objects that are dependent.

A DependentObject represents an EngineObject that can only exist within the scope of another object. An example of this dependency is ContentElement; content elements are scoped to a particular Document object and cannot exist independently. Contrast this with an IndependentObject, which is an EngineObject that has its own independent identity.

The identity and security of a dependent object are derived from that of its parent independent object.

DependentObjects and DependentObjectLists are not reusable. That is, a DependentObject or DependentObjectList taken from a fetched object should not be reassigned to another object. Once they have been assigned to one parent object, they must not be assigned to a second parent object. For example, you should not fetch the Permission obects for one object and then try to directly use those same Permission objects on another object. If you attempt such reuse, the results are unpredictable. In some cases, there may be no adverse effects. The operation might appear to succeed but give results other than what the caller expects, for example, errors when you try to save the object. In other cases, the attempted operation might fail with symptoms that are difficult to diagnose.

Any attempt to assign an already-assigned DependentObject to another parent object causes a warning message to be written to the client trace log.

Note: While this type of operation might succeed with the 4.0 Content Engine API, the behavior is unreliable and future releases of the Content Engine API will prohibit reuse by throwing a runtime exception.

Represents a single version of a document stored in an object store. In addition to being versionable, a Document object can be subclassed and can carry content, which is stored in one or more content elements. Each content element represents content data, which can either be local to an object store (represented by a ContentTransfer object) or external to an object store and therefore outside the control of the Content Engine server (represented by a ContentReference object). In addition, a Document object can be associated with a document lifecycle policy. A document lifecycle policy defines a set of valid lifecycle states for a document, controls the transition of those states, and specifies the actions to be taken when a document's lifecycle state changes.

Represents a collection of resources and services sharing the same Global Configuration Database (GCD). The GCD defines a common set of attributes that control functional characteristics of the collection of resources and services for this domain. The GCD defines domain resources, such as sites (and their related virtual servers and server instances), object store databases, full-text index areas, file storage areas, content cache areas, add-ons, marking sets, and so on. The FileNet P8 domain is also associated with one or more security realms for authorizing users.

Although you can programmatically create a domain, it is not typical to do so. (For a code sample, see Creating a Domain Object.) In a more typical scenario, you can retrieve a persisted Domain object by calling the GetInstance or FetchInstance method on the Factory.Domain class. You can also retrieve the Domain property of an ObjectStore object.

Represents a dynamic relationship between two Containable subclasses: a container and the current version of a Document. The object-valued Head and Tail properties express the relationship. The tail always references a Folder (the container), while the head references the current version of a Document.

Represents the top-level interface from which most of the other Content Engine API interfaces derive.

An EngineObject is any object known to the Content Engine, including objects outside of repositories, such as a service or an ObjectStore object itself. Contrast this with RepositoryObject, which represents any object residing within a Content Engine repository.

You will not normally work directly with an EngineObject, but rather with an instance of one of its subclasses, which are further grouped into independent and dependent objects. An IndependentObject is an EngineObject that has its own identity and always has an IObjectReference. A DependentObject is an EngineObject that can only exist within the scope of another object. An example of this dependency is ContentElement; content elements are scoped to a particular Document object and cannot exist independently.

This interface provides some base functionality, such as retrieving the Connection object that is used for communication to the Content Engine server and retrieving an object's class information and properties.

Represents the highest-level object in the Content Engine API object model. Creating an instance of this object exposes all other public members of the object hierarchy. For example, from EntireNetwork, you can instantiate a Domain object. From a domain, you can navigate to an object store, then begin accessing documents, folders, etc. You can also use the EntireNetwork to retrieve all of the Realm objects for the FileNet P8 domain, then retrieve the users and groups associated with a realm.

You can create a new EntireNetwork object by calling the GetInstance or FetchInstance method on the Factory.EntireNetwork class.

Represents a container that can hold other Containable subclasses, but cannot have content data of its own. Although Folder objects and their subclasses can be referentially contained, they are the only Containable subclass that can be directly contained (in a Folder). All other Containable subclasses are referentially contained using the ReferentialContainmentRelationship or DynamicReferentialContainmentRelationship classes.

Note Folders that are referentially contained cannot participate in hierarchy index searches.

The container hierarchy is a one-to-many relationship: a folder can have many child folders, but a child folder can have only one parent folder. At the top of the container hierarchy is an automatically-created root folder. Use ObjectStore.RootFolder to get a reference to the root folder.

Folders are not versionable.

Represents a persistable IndependentObject that you can directly create, update, and delete.

Indicates objects that are independent.

An IndependentObject represents an EngineObject that has its own independent identity. Contrast this with a DependentObject, which is an EngineObject that can only exist within the scope of another object. (An example of this dependency is ContentElement; content elements are scoped to a particular Document object and cannot exist independently.) An IndependentObject can be retrieved from the server with a call to InstantiatingScope.FetchObject or Factory.<classname>.FetchInstance, whereas a DependentObject can only be fetched as a property of an IndependentObject.

An IndependentObject always has an ObjectReference, which can be obtained by calling GetObjectReference. An ObjectReference provides identity information for the object.

When calling the Refresh methods, note that the behavior differs from that of fetch-related methods (FetchProperty and FetchProperties). The fetch-related methods retrieve the object and merge retrieved property information into the current contents of the property cache. The Refresh methods retrieve the object and replace the current contents of the property cache with the retrieved property information.

Provides a generic means for instantiating independent objects within a scope.

An InstantiatingScope can instantiate only those objects within its scope. For example, a Document object is within the scope of an ObjectStore, but is not within the scope of a Domain. This interface provides methods for creating or retrieving objects when you do not have type-specific knowledge of the objects to be instantiated. You can create or retrieve objects by supplying just a class name and (for retrieval) an object identifier or path.

Represents a relationship between two objects. The object-valued Head and Tail properties express the relationship. Use a Link object for many-to-many relationships between any objects, or for referential containment relationships between objects that are not instances of Containable subclasses.

Note This is a weak link relationship: both the Head and Tail properties have their DeletionAction metadata properties set to None. If you delete the object referenced by the head or tail, the Link object itself is not deleted.

Provides a means to retrieve identity information about an object.

Its methods primarily allow you to retrieve an object’s ID, as well as its associated class and object store IDs.

You can get an instance of an object’s unique identity by calling GetObjectReference() on the IIndependentObject and IPropertyEngineObject interfaces.

IIndependentObject.equals delegates to ObjectReference.equals for object comparisons. Neither considers update sequence number (USN) in the comparison. If both IObjectReference objects being compared have GUIDs (available within the client object) or paths or names, they are compared. Otherwise, the objects are considered to be not equal. No implicit round-trips to the Content Engine server are performed to resolve an identity to a GUID.

Represents a location in which folders, documents, and custom objects are stored, accessed, and managed on the Content Engine server.

An IObjectStore object provides access to metadata and Content Engine objects, such as class descriptions, property descriptions, security policies, and so on. Using methods on this interface, you can retrieve this information, create and store new objects in the object store, and retrieve its installed feature add-ons.

You can get a reference to an IObjectStore by iterating an IObjectStoreSet collection returned by the IDomain object. You can get an instance of IObjectStore by:

• Calling CreateInstance, GetInstance, or FetchInstance on the Factory.ObjectStore class.
• Calling GetObjectStore on an instance of an IRepositoryObject subclass.

You can configure an object store to share database connections with event export stores, isolated regions, or other object stores, depending on how you set the DatabaseConnection property.

Represents a static relationship between two Containable subclasses: a container and a containee. The object-valued Head and Tail properties express the relationship. The tail always references a Folder (the container), while the head references the containee: another Containable subclass (such as another Folder, a CustomObject, or a Document). When the head is a Document object, it represents a specific document version.

Represents the base class for binary relationships between independently persistable objects of an object store.

Indicates objects that are repository objects.

A RepositoryObject represents any object known to the Content Engine that can be persisted to an object store repository. A Document object is an example of a RepositoryObject. In contrast, an EngineObject is any object known to the Content Engine, including objects outside of repositories. Examples of objects residing outside of repositories are Domain, MarkingSet, and User objects.

You will not normally work directly with a RepositoryObject, but rather with an instance of one of its subclasses.

Defines the originating "scope" (enclosing context) of an object, such as the Domain of a Site or ObjectStore, or the ObjectStore of a Document.

Classes are generally characterized by where the instance objects reside. Some objects reside within an ObjectStore; other objects reside "above" an ObjectStore, that is, at a higher-level in the object model. The ClassDescription describes objects that reside somewhere. So, a ClassDescription is scoped to a particular location, and the object affiliated with that location is the scope object. Calling ClassDescription.GetScope() returns one of the following, depending on what type of class the ClassDescription describes:

• Domain
• ObjectStore
• Null (for the cases of Realm, EntireNetwork)

The following table lists scope objects and the objects scoped to them:

EntireNetwork, being the root of the hierarchy, scopes itself, and is also the scope object for Domain and Realm. The scope object for a ClassDescription object is the same as the scope object for an instance described by that ClassDescription. For example, if a CustomObject object is scoped by an ObjectStore instance "OS1", then the custom object's ClassDescription will also be scoped by "OS1".

Serves as a target of an event subscription, represented by a Subscription-based object. ISubscribable is a base interface of several derived interfaces that can be used as a subscription target. To set a Subscribable object as the target of a subscription, use the SubscriptionTarget property of the Subscription-based object.

You can instantiate a Subscribable object in the following ways:

• By retrieving the SubscriptionTarget property on a Subscription-based object.
• Returning a Subscribable object from a SubscribableSet collection.

Represents the base class for interfaces whose instances are versionable objects. If versioning is enabled on a versionable object (its IsVersioningEnabled property is true), it can have multiple versions associated with it in an object store. A versionable object can be checked out, optionally edited, and checked in as a major or a minor version. A major version is either the current released version (if it is the latest major version) or a previous released version that was superseded. A minor version is either the in-process version (if it is the latest minor version) or a previous in-process version that was superseded. When a versionable object is checked out, a reservation object is created, which you can modify. During the check-in operation, the reservation object becomes the current version of the versionable object, therefore creating a new version. All of a versionable object's versions can be accessed by its associated VersionSeries object or from the collection returned by its Versions property.

Represents the complete set of versions for a versionable object, or document (that is, an object instantiated from a subinterface of the IVersionable interface). Because a VersionSeries object is constructed by the server from versionable objects and does not have its state stored in a database, it is read-only, and thus you cannot modify any of its properties. In addition, a VersionSeries object has no security attached to it; it is secured by the current document version associated with it. You can access a specific document version by navigating through the collection returned by the Versions property. Use extreme caution when deleting a VersionSeries object; if you delete it, all of its associated document versions will also be deleted.

Caution: The Delete and MoveContent methods impact all document versions in the version series. That is, all document versions are deleted, and the content of all document versions are moved.

Represents a workflow definition, an XML document of class "WorkflowDefinition" that is stored in a Content Engine object store. A workflow definition describes the instructions, paths, and queues available to a workflow, and acts as a processing template that the Process Engine uses each time the workflow runs. Workflow definition documents are versionable, containable, and can have a lifecycle associated with them.

The IWorkflowDefinition interface extends the IDocument interface, and can, therefore, be treated as a Document object. For example, a WorkflowDefinition object can have workflows linked to it. Therefore, a user selecting a workflow definition can either launch it, or launch a linked workflow.

To create a new WorkflowDefinition object and persist it to a Content Engine object store, call the CreateInstance method on the Factory.WorkflowDefinition class.

After you create a workflow definition, you link it to an object that implements the Subscribable interface by setting the SubscriptionTarget and WorkflowDefinition properties on a workflow subscription object (InstanceWorkflowSubscription or ClassWorkflowSubscription object). Note that you cannot delete a WorkflowDefinition object if a workflow subscription object refers to it in its WorkflowDefinition property.

To return all of the workflow subscription objects associated with this WorkflowDefinition object, retrieve the WorkflowSourceSubscriptions property.

You can instantiate a WorkflowDefinition object in the following ways:

• By calling the GetInstance or FetchInstance method on the Factory.WorkflowDefinition class.
• By retrieving the WorkflowDefinition property on a workflow subscription object.
• By instantiating a WorkflowDefinitionSet collection, then returning a WorkflowDefinition object from the collection.