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.7, “Workflow Content Service”.
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).
 |  |  |
 |