The workflow repository, like the content repository and the user repository, provides access to objects stored persistently on a CoreMedia Server, in this case, the CoreMedia Workflow Server. The objects to be accessed are modeled as subclasses of CapObject, and their structure is modeled by workflow-specific subclasses of CapType.

Like all persistent objects in the CoreMedia CMS, workflow objects carry an ID that uniquely identifies the object within the system, across users and sessions. This ID can be used to retrieve an object encountered before. The workflow repository offers a number of getter methods taking an ID argument, which differs only in the expected type of the retrieved object.

There are also methods to retrieve all objects of a certain kind (which, depending on the repository's size, can be quite expensive).

Many client applications will navigate the repository beginning from a process or task that is relevant for the current user. These tasks and processes can be determined using the work list service described in Section 6.4, “The Work List Service”. If you want to navigate from a given content object to the processes that affect it, use the WorkflowContentService as described in Section 5.9, “Workflow Content Service”.

Figure 6.1. Workflow Class Diagram

The objects stored in the workflow repository can be discriminated into processes and tasks. Each process is composed of a number of tasks, which will be executed in a defined order. As can be seen in Figure 6.1, “Workflow Class Diagram”, the Unified API represents these objects using the classes Process and Task.

All names of association end in Figure 6.1, “Workflow Class Diagram” correspond to getter methods in the Unified API. For example, the aggregation between Process and Task can be navigated in both directions: The Process containing a Task can be determined using Task#getContainingProcess(), and the set of Tasks contained in a Process can be determined using Process#getTasks().

The set of tasks of a process conforms to the process' definition. For each task definition contained in the process' definition, the process contains a task, which is created at the time the process is created. The successor relation between tasks conforms to the structure of the task definitions, as expressed by the successorDefinition relation. The task structure is also fixed at process creation time. The first task to be executed when a process is started is determined by the process definition's startTaskDefinition.

Both processes and tasks pass through various states during their lifetime. These states are modeled using the enumeration types ProcessState and TaskState, respectively, and are described in further detail in Section 6.2, “Workflow States”.

In addition to the states predefined by CoreMedia, information about the progress of a process or task can be stored in workflow variables. Workflow variables can also be used to pass information from and to automated tasks, and may be seen or edited by users in task-specific forms.

Workflow variables are represented just like content properties and user attributes. As described in Section 7.1, “Objects”, each CapObject carries a property value for each property declared by its type. Both ProcessDefinition and TaskDefinition inherit from CapType the ability to declare properties. In the context of workflow objects, the type association between object and type is called definition, and differs only in its more explicit typing: When a WorkflowObject is asked for its type, the result can only be a WorkflowObjectDefinition; even more specifically, a Process is always defined by a ProcessDefinition, and a Task is always defined by a TaskDefinition.

The types of properties generally available are described in Section 4.5, “Types”. The Workflow Server allows more kinds of properties than the Content Server, especially, lists can be declared of all element types (not just Content links), and additional atomic property types are available: User, Group, Boolean, ContentType, and Timer. Also, properties can be declared to be read-only.

When a Timer property is declared, this has two effects: Firstly, it creates a property that can hold a TimeLimit, and secondly, it creates a Timer, which, when enabled, notifies the application when the time limit is reached. See section Section 6.9, “Timers” for details.

Being a CapType, each process definition has a name. The repository remembers the most recently uploaded process definition for each name, and automatically disables earlier definitions carrying the same name. A disabled process definition cannot be used to start new processes, but continues to be available for running processes. A process definition can be disabled explicitly even if it is not superseded by a newer version. The repository can be queried for a process definition by name, and again to support expression languages, a Map containing all enabled process definitions by name can be obtained.

A new process is created either by calling the method ProcessDefinition#create on an enabled process definition, or automatically by a server-side fork task (see the Workflow Manual for details on task types). A process that is started as a sub process of another process can be asked for its parent process.

The parent relation between processes must not be confused with the containment relation between processes and tasks; a process' tasks are created at the same time the process is created, but a sub process is only created when the corresponding fork task is executed (which, among other considerations, allows for recursion).