The Content Engine API provides the following workflow capabilities:
For code examples of workflow definition and workflow subscription objects, see Working with Workflow-related Objects. For an overview of workflows, see Getting started with FileNet® Process applications.
A workflow definition document is authored with the Process Designer application, and is persisted on the Content Engine as a WorkflowDefinition object. The WorkflowDefinition interface extends the Document interface, and can, therefore, be treated as a Document object. That is, you can check out the workflow definition, set content on it, check it back in, file it into a folder, and delete it.
A workflow definition must be transferred to Process Engine, where it is compiled and run. You can manually transfer workflow definitions with the Process Designer application, or programmatically by using the Process Java™ API. If a programmatic transfer is successful, Process Engine returns a unique identifier for the compiled workflow definition, which you must set on the WorkflowDefinition object's VWVersion property.
A transferred workflow definition can be started manually, or it can be started from a subscription, as described in the next section. Note that a WorkflowDefinition can be linked to multiple subscriptions. A WorkflowDefinition object's WorkflowSubscriptions property contains all of the workflow subscriptions that are associated with the object.
A workflow subscription links a transferred workflow definition, subscribed events, and a Subscribable target object like a document. When a subscribed event fires on the target object, the workflow starts from Process Engine. There are two workflow subscription interfaces: InstanceWorkflowSubscription and ClassWorkflowSubscription, both of which extend the Subscription class. An InstanceWorkflowSubscription runs in response to an event triggered on a specific object instance. A ClassWorkflowSubscription runs in response to an event triggered on any object of a particular class.
Although a workflow subscription is similar to a non-workflow subscription, the fundamental difference is that a non-workflow subscription triggers a user-supplied event handler, which performs actions on the Content Engine as implemented by the user. A workflow subscription triggers a system-supplied event handler on the Content Engine, which starts a workflow on the Process Engine. Therefore, you must set the EventAction property of all workflow subscriptions to a WorkflowEventAction object that references the system event handler that starts workflows. (For non-workflow subscriptions, you must set the EventAction property to an EventAction object that references a user-implemented event handler.)
A workflow subscription also requires that you transfer a workflow definition to Process Engine and set these properties:
Other workflow subscription-specific properties are optional. For example, the settable EnableManualLaunch property indicates whether the workflow for a Subscription object can be manually started.
Note that the derived property, IsSynchronous, is read-only with a value of false for a workflow subscription. This property determines how the subscription's event procedure runs on Content Engine. For a workflow subscription, the event is always fired asynchronously.
For more information about property information, see InstanceWorkflowSubscription Properties and ClassWorkflowSubscription Properties.