Workflow variables may be defined directly in the process, as well as locally in any of the tasks. While performing a task, a user needs to inspect, and possibly modify, some of those variables. Which variables the user needs, depends on the concrete task.
Therefore, each task definition contains a view definition, which specifies the variables to be accessed, and the kind of access required (read or write), while performing the task. The view definitions of different task definitions may reference the same variables, for example to share a common process description, or a common list of content objects to operate on.
The Unified API represents a view as a special kind of CapObject. A view appears to have properties that can be read and written, while in fact, each of those properties is stored in some task or process. Each read and write access to a view is redirected according to the view definition. By inspecting the view definition, which is a subclass of CapType, the available properties can be listed.
The Unified API representation for view definitions is shown in Figure 6.5, “Workflow Object and View Definitions”. The diagram shows all subclasses of CapType managed in a workflow repository. Their instances form a hierarchy, which corresponds to the nesting in the workflow definition XML file (see the Workflow Manual for details). A process definition contains a number of task definitions. Views can be defined by both process definitions and task definitions. There is one view definition per task definition, and two per process definition, where the initial view applies before the process starts running, and the running view applies after the process has started.
At the bottom of the diagram, you can see the property descriptors. Each CapType aggregates a number of property descriptors. In the case of workflow and task definitions, these are the workflow variables. So for each process or task, a value is stored for each descriptor of its definition.
A view definition also is a
CapType,
its property descriptors are PropertyViewDescriptors. In addition to being
regular property descriptors, they provide information on how to represent the view during
user interactions, and information on where the actual value is stored. A view as an instance
of a view definition does not itself store any values. Instead, the name of the property view
descriptor determines where the actual value is stored, relative to the view's origin. The
origin of a view is the process or task the view was obtained from.
The concrete mechanism for variable resolution should not bother a Unified API client, because the complete mapping from view property to workflow variable is managed transparently by the API. A view can be treated just like a CapObject that just has slightly unusual property names. For completeness, the mapping from view property to target object and target property works as follows:
A qualified property view descriptor name, of the form <task>.<property>, is resolved to the property with the given name of the task with the given name in the same process as the view's origin.
An unqualified property view descriptor name, of the form <property>, refers to the named property of the view's origin. If the origin is a task and does not contain such a property, the property view descriptor refers instead to the named property of the task's containing process.
Two additional flags are specified per property view descriptor. Firstly, a property is declared as read-only or writable. This overrides the value of the writable flag in the target property declaration. For example, a workflow variable declared as read-only in the process may be writable from the process' initial view.
Secondly, for a property containing content links, the contentWritable flag
determines how the referenced content should be presented to the user. If the flag is false,
the content should be displayed as read-only. For example, assume one task in a
process that has the goal of selecting a set of documents for later tasks to work on. This
task will only need to add and remove links, not change the documents themselves. Therefore,
this task view should contain a property mapping that is writable, but not content writable.
Workflow views also affect the interpretation of READ and WRITE rights. See Section 6.6, “The Access Control Service” for further details.
 |  |  |
 |