The order of the elements in the workflow definition is not relevant except for the Action and the Condition elements. The reason for this is obvious, as you have to control the order of the actions and a condition that is comparing values depends on an ordering, too. Mostly NMTOKEN is used instead of CDATA as the content model for the attributes. This restrictive policy avoids escaping of names.
This chapter describes the workflow definition XML file format. You will find two kinds of items described here:
Parameter entities (headline printed in bold italics)
Parameter entities constitute rules for the XML grammar or standard sets of attributes. Parameter entities are reused in various places to shorten the definition of XML elements.
XML elements (headline printed in bold)
XML elements describe the actual parts of a workflow description.
Grammar:
You will find the attributes of the actions described for each action later in this chapter.
BooleanExpression
Definition: Equal | NotEqual | Greater | GreaterEqual | Less | LessEqual | And | Or | Implies | Not | ForAll | Exists | Let | Get | Read | Length | IsEmpty | NotEmpty | IsFolder | IsDocument | IsDocumentVersion | IsExpired | IsEnabled
The BooleanExpression parameter entity is used to define a subset of all available expressions which evaluate to a Boolean value.
Definition: Expression | Equal | NotEqual | Greater | GreaterEqual | Less | LessEqual | And | Or | Implies | Not | ForAll | Exists | Let | Get | Read | Length | IsEmpty | NotEmpty | IsFolder | IsDocument | IsDocumentVersion | IsExpired | AddLatestVersion | Value: Blob | Boolean | Content | ContentType | Date | Document | Folder | Group | Integer | String | Timer | User
The Expression parameter entity is used to define all available expressions. You can use the predefined expressions listed above or implement your own expressions, using the Expression element.
Definition: Choice | Fork | If | Join | JoinSubprocess | ForkSubprocess| Switch
FlowControlTasks define the flow of control in a workflow process.
This is just an abstract definition, only concrete FlowControl tasks may be used in a valid workflow definition.
Note: A FlowControlTask may not be final.
Definition: AutomatedTask | UserTask | FlowControlTask: Choice | Fork | If | Join | JoinSubprocess | ForkSubprocess | Switch
Tasks define the steps a workflow process must complete. A task is identified by its name. Like a process is a template for concrete process instances, a task is a template for concrete task instances. Tasks refer to each others by the name(s) of their Successor(s). Each task must either have at least one successor or be final.
The description of the task is a human readable explanation about what the task does. It may be localized by the editor or used as a key for localization in the Site Manager.
Tasks which finish a workflow process are declared final. There has to be at least one task in a process definition which is final. Only UserTasks and AutomatedTasks can be final.
Variables in the task scope define the local state of task instances. This does not restrict the visibility of the variables. A variable in a task may always be referred to from other tasks by prefixing the variable name with the task name and a dot.
There are nine task types:
An AutomatedTask is executed automatically.
An UserTask has to be carried out by a user.
The other task types are used to control the flow of execution of tasks.
Definition: Blob | Boolean | Resource | ContentType | Date | Document | Folder | Group | Integer | String | Section 4.1.11, “Timers” | User
A Value represents one or many values of a variable. A Value element is used to initialize a variable or to be evaluated in expressions (see Example 6.1, “Example of the variable usage”).
<Variable name="publicationSuccessful" type="Boolean"> <Boolean value="false"/> </Variable> <AggregationVariable name="success" type="Boolean"> <Boolean value="true"/> <Boolean value="false"/> </AggregationVariable> <Condition> <Equal> <Boolean value="true"/> <Get variable="success" index="1"/> </Equal> </Condition>
Example 6.1. Example of the variable usage
Definition: true | false
Definition of a Boolean XML attribute type.
varies
Definition: Entity for tagging varying parts of the DTD.
Grammar: (Condition, Property)
An action is external code which may be called to customize the processing of the workflow engine (see Section 5.4, “Programming Actions” for implementing own actions).
You can either give the full qualified name of your own action class which must be an
implementation of interface
com.coremedia.workflow.WfAction
or an unqualified class name which will be searched for in the package
com.coremedia.workflow.common.actions
.
A predefined Action or one subclassed from AbstractAction/AbstractClientAction may contain a Condition element which serves as a "guard" for the action code (see the example below). Only if the condition is satisfied, the code is executed, otherwise nothing happens.
The following actions are supplied with the workflow engine by default: ArchiveProcess, ApproveResource, CheckInDocument, CheckOutDocument, CopyResource, CreateDocument, CreateFolder, DeleteResource, DisapproveResource, EnableTimer, ExcludePerformer, ExcludeUser, DisableTimer, MoveResource, OpenDocument, PreferPerformer, PublishResources, RegisterPendingProcess, RenameResource, SaveDocument, UncheckOutDocument, UndeleteResource.
The predefined actions use some of the Action attributes defined above.
Note: The Property child element is valid for the CreateDocument action only.
Attribute |
Type |
Default |
Description |
---|---|---|---|
varies | additional parameters according to the implementation of the action class |
Table 6.4. Attributes of Action element
<UserTask name="TestActionGuard" successor="final"> . . <Action class="EnableTimer" timerVariable="TimeVariable"> <Condition> <Equal> <Read variable="document" property="_name"/> <String value="Article"/> </Equal> </Condition> </Action> . . </UserTask>
Example 6.2. Action with a Guard used in a UserTask
Grammar: ((Expression)*)
An AddLatestVersion expression adds the latest version to a document value or to each member of an aggregate containing only documents. If a document already contains version information, the value is handed through. Otherwise, the Content Management Server is queried for the latest version of the document and the document version is added.
No attributes.
Grammar: ((Value)*)
In contrast to a variable, whose value is one value, an AggregationVariable may have a list of values as its value. See Variable for details.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
The name of the variable |
type |
NMTOKEN |
#REQUIRED |
The type of the variable, see Value |
|
(Boolean) |
"false" |
Defines whether it is forbidden to modify the variable |
static |
(Boolean) |
"false" |
Defines whether the variable is initialized only once |
Table 6.5. Attributes of the AggregationVariable element.
<Workflow> <Process name="AggregationExample" startTask="Start"> <AggregationVariable name="StringTest" type="String"> <String value="World"/> <String value="Hello"/> </AggregationVariable> . . </Process> <Workflow>
Example 6.3. Example of an aggregation variable
Grammar: ((Expression)*)
An And
expression evaluates to the conjunction of its subexpressions, all of
which must return Boolean values. The subexpressions are evaluated in a "short-circuit"
fashion, that is, they are evaluated top down until the first subexpression evaluates to
"false" or all subexpressions have evaluated to "true". This helps to avoid exceptions during
the computation, for example when checking the type of a document before accessing a property
of the document of that expected type.
<Variable name="Comment" type="String"/> <Assignment> <Writes variable="Comment"/> </Assignment> <UserTask name="AndTest" successor="theNext"> <PreCondition> <And> <Equal> <Get variable="OWNER_"/> <User value="0"/> </Equal> <Equal> <Get variable="Comment"/> <String value="42"/> </Equal> </And> </Precondition> <!-- Code --> </UserTask>
Example 6.4. Example of an And element.
Grammar: (Expression)
Assign transfers a value which is defined by the expression into a variable in the initial client view of the subprocess. For an XML example see Example 6.22, “Example of a ForkSubprocess task”.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
name of the variable in the subprocess |
Table 6.6. Attribute of the Assign element
Grammar: ((Variable | AggregationVariable)*, Action*, Guard?, PreCondition*, PostCondition)
An AutomatedTask is executed automatically by the workflow engine. It performs some automated action on the Content Management Server content or on other third-party systems or internal actions. The Action of an automated task are used to customize the processing of the workflow engine. If more than one Action is provided, the actions are executed in the order in which they are specified.
A PreCondition defines requirements which have to be fulfilled before the actions of the automated task are executed. A PostCondition defines requirements which have to be fulfilled after the action has been executed. If more than one PreCondition or PostCondition are provided, then the conditions are evaluated in the order they are defined. The result of such an evaluation operation is equivalent to specifying an 'and' expression with an ordered set of expressions.
A Guard defines an expression, which activates and executes the task as soon as the expression evaluates to true. The expression is evaluated on state changes of process- or task instances in the Workflow Server and content or name changes of referred resources in the Content Management Server. Note that changes to other, external entities do not trigger reevaluation of a guard.
A successor must be given if and only if the task is not final.
Note: An Section 4.1.4.3, “Automated Tasks” does not allow you to specify Rights, Performer, and Client. This is restricted to UserTask elements which interact with the users of the CoreMedia Workflow Server.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the task |
description |
CDATA |
#IMPLIED |
the textual description of the task |
final |
(Boolean) |
"false" |
Defines whether the task is the final task to execute |
successor |
NMTOKEN |
#IMPLIED |
Defines the next task to execute after the automated task has been completed |
varies |
Table 6.7. Attributes of the Automated Task element
<Variable name="document" type="Document"/> <Assignment> <Writes variable="document"/> </Assignment> <AutomatedTask name="automatic" successor="final"> <Action class="CheckInDocument" documentVariable="document"/> </AutomatedTask>
Example 6.5. Example of an AutomatedTask
Assignment
An Assignment element determines that a variable is 'important' to a task or process instance and need to be shown. It can or has to be modified by a user or an external process. Thus, it defines a view on the variables.
With Reads and Writes the variables are specified. The modifications of the variables may be validated by Validators.
Processes have two variants of Assignment specifications, the InitialAssignment which is valid as long as the process instance is not started and the Assignment for all other instance states. This way it is possible to set initial arguments for a process instance which cannot be changed after the instance is started.
No attributes.
<Workflow> <Process name="ClientExample" startTask="TheFirst"> <Variable name="Resource" type="Document"/> <Variable name="Comment" type="String"/> <UserTask name="TheFirst" successor="TheEnd"> <Assignment> <Reads variable="Resource" contentEditable="true"/> <Writes variable="Comment"/> </Assignment> <!-- Code --> </UserTask> <!-- Code --> </Process> </Workflow>
Example 6.6. Example of an Assignment task
Grammar: EMPTY
The Blob element is used to specify a single constant blob value within expressions or variable initializers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value | CDATA |
#IMPLIED |
the blob value in bytes |
mimeType | CDATA | #REQUIRED | the blob's MimeType |
Table 6.8. Attribute of the Blob element
<Variable name="Logical" type="Blob"> <Blob value="Some text..." mimeType="text/plain"/> </Variable>
Example 6.7. Example of a Blob variable
Grammar: EMPTY
The Boolean element is used to specify a single constant Boolean value within expressions or variable initializers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
(Boolean) |
#REQUIRED |
the Boolean value ("true" or "false") |
Table 6.9. Attribute of the Boolean element
<Variable name="Logical" type="Boolean"> <Boolean value="true"/> </Variable>
Example 6.8. Example of a Boolean variable
Grammar: (%BooleanExpression;)
A case extends a condition by defining a successor to be activated if the condition's expression evaluates to true. A 'case' condition may be based on the state of workflow variables, the content of documents from the Content Management Server or the external state of third-party products. For an example see Switch.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#IMPLIED |
The name of the expression. |
description |
CDATA |
#IMPLIED |
A textual description of the expression. |
successor |
NMTOKEN |
#REQUIRED |
The successor which should be activated if the condition's expression evaluates to true. |
Table 6.10. Attributes of the Case element
Grammar: ((Variable | AggregationVariable)*, Successor+)
A Choice task branches the flow of tasks into two or more successors which must be UserTasks. So it is an implicit choice. One of these successor tasks can be accepted and executed by a user. As this happens the other Successor tasks are withdrawn from any offer list and reset as if they haven't been started at all.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the task |
description |
CDATA |
#IMPLIED |
the textual description of the task |
Table 6.11. Attributes of the Choice element.
<UserTask name="TheTaskBefore" successor="ChoiceExample"> <!-- Code --> </UserTask> <Choice name="ChoiceExample"> <Successor name="FirstChoice"/> <Successor name="SecondChoice"/> </Choice> <UserTask name="FirstChoice" successor="final"> <!-- Code --> </UserTask> <UserTask name="SecondChoice" successor="final"> <!-- Code --> </UserTask>
Example 6.9. Example of a Choice element
Deprecated. See Assignment instead.
Grammar: (Expression)
A condition defines an expression that must evaluate to a Boolean value. It may be based on the state of workflow variables, the content of documents from the Content Management Server or the external state of third-party products. A condition is defined based on an expression which may be formed from nested subexpressions.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#IMPLIED |
the name of the condition |
description |
CDATA |
#IMPLIED |
the textual description of the condition |
Table 6.12. Attributes of the Condition element
<Variable name="Article" type="Document"/> <Assignment> <Writes variable="Article"/> </Assignment> <UserTask name="AndTest" successor="theNext"> <EntryAction class="CheckOutDocument" documentVariable="Article"> <Condition> <NotEmpty variable="Article"/> </Condition> </EntryAction> <!-- Code --> </UserTask>
Example 6.10. Example of a Condition element. It is checked whether the document variable is null or not.
Grammar: EMPTY
The ContentType element is used to specify a single constant content type within expressions or variable initializers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
NMTOKEN |
#REQUIRED |
the name of the content type |
Table 6.13. Attribute of the ContentType element
<Variable name="Type" type="ContentType"> <ContentType value="Article"/> </Variable>
Example 6.11. Example of a ContentType variable
Grammar: EMPTY
The Date element is used to specify a single constant date value within expressions or variable initializers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
CDATA |
#REQUIRED |
the date in the format dd.MM.yyyy hh:mm |
Table 6.14. Attribute of the Date element
<Variable name="Time" type="Date"> <Date value="10.11.2002 13:00"/> </Variable>
Example 6.12. Example of a Date variable
Grammar: EMPTY
The Document element is used to specify a single constant document within expressions or
variable initializers. It is not useful to define a fixed document ID in the workflow
definition. Either path
or value
should be specified.
Attribute |
Type |
Default |
Description |
---|---|---|---|
path |
NMTOKEN |
#IMPLIED |
The path of a document. |
value |
NMTOKEN |
#IMPLIED |
The ID of the document. |
version |
NMTOKEN |
#IMPLIED |
The version number of the document. |
Table 6.15. Attributes of the Document element.
<Variable name="Article" type="Document"> <Document value="10"/> </Variable>
Example 6.13. Example of a Document variable.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
NMTOKEN |
#REQUIRED |
the name of the document type |
Table 6.16. Attribute of the DocumentType element
Grammar: EMPTY
Else defines the successor of the If task if the condition evaluates to false, see If for details and an XML example.
Attribute |
Type |
Default |
Description |
---|---|---|---|
successor |
NMTOKEN |
#REQUIRED |
the name of the successor task for the "else" case |
Table 6.17. Attribute of the Else element
Grammar: (Condition?, Property?)
EntryAction and ExitAction elements are identical to Action elements, see Action and Action-Attributes for details.
Attribute |
Type |
Default |
Description |
---|---|---|---|
varies | additional parameters according to the implementation of the action class |
Table 6.18. Attributes of EntryAction element
<Variable name="Article" type="Document"/> <Assignment> <Writes variable="Article"/> </Assignment> <UserTask name="AndTest" successor="theNext"> <EntryAction class="CheckOutDocument" documentVariable="Article" gui="false"> <Condition> <NotEmpty variable="Article"/> </Condition> </EntryAction> <!-- Code --> </UserTask>
Example 6.14. Example of an EntryAction which checks out a document
Grammar: ((Expression), (Expression))
An Equal expression contains exactly two subexpressions, which are both evaluated during the evaluation of the Equal expression. The expression evaluates to "true" if and only if the computed values of the subexpressions are equal.
Although an Equal expression may compare values of any type, this element makes sense only for values like integer, string, date, resource and timer values as defined in the workflow. Note that document references are considered equals only if they refer to the same document, that is, the document contents are not considered.
<Variable name="Comment" type="String"/> <Assignment> <Writes variable="Comment"/> </Assignment> <UserTask name="AndTest" successor="TheNext"> <Guard> <Equal> <Get variable="Comment"/> <String value="LetMeIn"/> </Equal> </Guard> <!-- Code --> </UserTask>
Example 6.15. Example of an Equal expression
Grammar: (Expression)
Exists is the counterpart to ForAll and behaves similarly. It evaluates to true if any of the instances of the subexpression evaluate to "true". Evaluation is also short-circuited, that is, it stops as soon as a subexpression instance evaluates to "true".
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of a new variable that iterates over all members of the aggregate |
aggregate |
NMTOKEN |
#REQUIRED |
the name of an aggregate variable |
index |
NMTOKEN |
#IMPLIED |
the name of a new integer variable that is set to the current index in the aggregate during the iteration |
Table 6.19. Attributes of the Exists element
<AggregationVariable name="Articles" type="Document"/> <Assignment> <Writes variable="Articles"/> </Assignment> <UserTask name="AndTest" successor="TheNext"> <Guard> <Exists variable="Element" aggregate="Articles"> <Equal> <String value="Sports"/> <Read variable="Element" property="Topic"/> </Equal> </Exists> </Guard> <!-- Code --> </UserTask>
Example 6.16. Example of an Exists expression which checks if one of the documents in the variable Articles has the entry Sports in Topics
Grammar: (Condition?, Property?)
ExitAction and EntryAction elements are identical to Action elements, see Action for details.
Attribute |
Type |
Default |
Description |
---|---|---|---|
varies | additional parameters according to the implementation of the action class |
Table 6.20. Attributes of the ExitAction element
<Variable name="Article" type="Document"/> <Assignment> <Writes variable="Article"/> </Assignment> <UserTask name="AndTest" successor="theNext"> <EntryAction class="CheckOutDocument" documentVariable="Article" gui="false"> <Condition> <NotEmpty variable="Article"/> </Condition> </EntryAction> <!-- Code --> </UserTask>
Example 6.17. Example of an Exit Action which checks whether the document is null or not
Grammar: ((Expression)*)
You can implement your own expressions (see Section 5.5, “Programming Expressions”). Custom expressions must implement the interface com.coremedia.workflow.WfExpression or com.coremedia.workflow.WfBooleanExpression.
Attribute |
Type |
Default |
Description |
---|---|---|---|
class |
NMTOKEN |
#REQUIRED |
the name of the expression class |
varies |
Table 6.21. Attributes of the Expression element
<Variable name="comment" type="String"> <String value="TestString"/> </Variable> <If name="One"> <Condition> <Less> <Expression class="com.coremedia.examples.expression.DemoExpression"/> <Get variable="comment"/> </Less> </Condition> <Then successor="True"/> <Else successor="False"/> </If>
Example 6.18. Example of an Expression element
Grammar: EMPTY
The Folder element is used to specify a single constant folder within expressions or variable
initializers. It is not useful to define a fixed folder ID in the workflow definition. Either
value
or path
must be selected.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
NMTOKEN |
#IMPLIED |
The ID of the folder. |
path |
NMTOKEN |
#IMPLIED |
The path of the folder. |
Table 6.22. Attributes of the Folder element.
<Variable name="RootFolder" type="Folder"> <Folder value="1"/> </Variable>
Example 6.19. Example of a Folder variable
Grammar: (Expression)
A ForAll expression checks its Boolean subexpression for all members of the value of the "aggregate" AggregationVariable and evaluates to "true" if all instances of the subexpression evaluate to "true". The subexpression can (and should) contain a Get expression with the variable name that evaluates to the n-th value in the aggregate. The logical "and" is short-circuited in the sense that evaluation is done in the order of the aggregate's elements and stops as soon as the subexpression evaluates to "false". The optional index variable evaluates to an IntegerValue representing the index of the current element in the aggregate and can be used, for example to access the member at the same index in another aggregate.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of a new variable that iterates over all members of the aggregate |
aggregate |
NMTOKEN |
#REQUIRED |
the name of an aggregation variable |
index |
NMTOKEN |
#IMPLIED |
the name of a new integer variable that is set to the current index in the aggregate during the iteration |
Table 6.23. Attributes of the ForAll element
<AggregationVariable name="Articles" type="Document"/> <Assignment> <Writes variable="Articles"/> </Assignment> <AutomatedTask name="Approve" successor="TheNext"> <Action class="ApproveResource" resourceVariable="Articles"> <ForAll variable="Element" aggregate="Articles"> <Not> <Read variable="Element" property="isCheckedOut_"/> </Not> </ForAll> </Action> <!-- Code --> </AutomatedTask>
Example 6.20. Example of a ForAll element which checks if all documents are checked in before approving them
Grammar: ((Variable | AggregationVariable)*, Successor+)
A Fork task forks the flow of tasks into two or more Successors to perform execution in parallel. All forked tasks must be joined together by a Join task.
<!-- Code --> <Fork name="Parallel" description="Fork tasks"> <Successor name="FirstParallel"/> <Successor name="SecondParallel"/> </Fork> <AutomatedTask name="FirstParallel" successor="Together"> <!-- Code --> </AutomatedTask> <UserTask name="SecondParallel" successor="Together"> <!-- Code --> </UserTask> <Join name="Together" successor="Next"> <Predecessor name="FirstParallel"/> <Predecessor name="SecondParallel"/> </Join> <!-- Code -->
Example 6.21. Example of a Fork task
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the task |
description |
CDATA |
#IMPLIED |
the textual description of the task |
Table 6.24. Attributes of the Fork element
Grammar: ((Variable | AggregationVariable)*, Parameters)
The ForkSubprocess task starts a separate workflow process, which is referenced by its name, from the current process.
If detached
is set to true, the forked subprocess has no relationship to its parent process. If
set to false, which is the default, a suspend, abort or resume on the parent process suspends,
aborts or resumes the forked subprocess, too.
The forked subprocess may be parametrized via Parameters child elements.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the task |
description |
CDATA |
#IMPLIED |
the textual description of the task |
subprocess |
NMTOKEN |
#REQUIRED |
the name of the sub process to start |
|
NMTOKEN |
#IMPLIED |
the name of the sub process to start, defined via a string variable. The name of the
string variable is set with |
|
NMTOKEN |
#IMPLIED |
the owner of the sub process is by default the owner of the parent process. Using
|
successor |
NMTOKEN |
#REQUIRED |
the name of the next task to execute after the subprocess has been started |
detached |
(Boolean) |
"false" |
If set to "false", the subprocess may be joined and it is affected by suspend, abort and resume operations on the original process. |
Table 6.25. Attributes of the ForkSubprocess element
<Workflow> <Process name="FirstWF" startTask="Fork"> <Variable name="Comment" type="String"/> <Assignment> <Writes variable="Comment"/> </Assignment> <!-- Code --> <ForkSubprocess name="Fork" subprocess="SecondWF" successor="Wait" detached="false"> <Parameters> <Assign variable="SubComment"> <Get variable="Comment"/> </Assign> </Parameters> </ForkSubprocess> <!-- Code --> <JoinSubprocess name="Wait" forkTask="SecondWF" successor="Final"/> <AutomatedTask name="Final" final="true"/> </Process> </Workflow> <!-- NEW FILE --> <Workflow> <Process name="SecondWF" startTask="FirstOne"> <Variable name="SubComment" type="String/> <InitialAssignment> <Writes variable="SubComment"/> </InitialAssignment> <!-- Code --> </Process> </Workflow>
Example 6.22. Example of a ForkSubprocess task
Grammar: EMPTY
Get evaluates to the value of a variable. The variable can be a workflow variable (normal or aggregate) or an expression-local variable (see Let, ForAll, Exists). If the variable is an AggregationVariable, an index can be given either as an integer constant or an integer variable in the index attribute. For aggregation variables the Get expression evaluates to the value at this index in the aggregation, if an index is given, or to the entire aggregate otherwise.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the variable that contains the result value |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
Table 6.26. Attributes of the Get element
<Variable name="Comment" type="String"/> <Assignment> <Writes variable="Comment"/> </Assignment> <If name="IfTask"> <Condition> <Equal> <Get variable="Comment"/> <String value="42"/> </Equal> </Condition> <Then successor="Task1"/> <Else successor="Task2"/> </If>
Example 6.23. Example of a Get element
Grammar: EMPTY
Grant authorizes users or groups to perform actions on the process or task instance they are specified in. Grant is only defined for the predefined ACLRightsPolicy. If you implement own policies, you may parameterize the policy as you want.
One of 'user', 'group', or 'variable' must be set to specify the subject who is authorized to do actions. If you use 'group' or 'user' the optional 'domain' might be used in addition.
If the attribute 'variable' is set, then the indicated variable is read at runtime. If the variable contains a user, the grant applies to that user. If it contains a group, the grant applies to all direct or indirect members of that group. If it contains a list of users or groups, it applies to all of these.
Rights specified using variables precede user rights, which again precede group rights. Within each category, revokes precede grants.
The 'rights' are a comma-separated list of names for operations, which may be performed. The actions, defined in the WfRightsPolicy interface are:
read, write for process and task instances; create, start, suspend, resume, abort for process instances; accept, reject, assign, complete, delegate, cancel, skip, retry for task instances
Attribute |
Type |
Default |
Description |
---|---|---|---|
user |
NMTOKEN |
#IMPLIED |
the name of a user or the user ID of a user |
group |
NMTOKEN |
#IMPLIED |
the name of a group or the group ID of a group |
domain |
NMTOKEN |
#IMPLIED |
The domain of a user or group. May be used if |
variable |
NMTOKEN |
#IMPLIED |
the name of a variable that stores a user or a group or a list of these |
rights |
CDATA |
#REQUIRED |
a comma-separated list of rights as specified above |
Table 6.27. Attributes of the Grant element
<UserTask name="GrantExample" successor="TheNext"> <Rights> <Grant group="composer-role" rights="accept, complete, read"/> <Grant user="demo1" rights="accept, complete, delegate, read"/> </Rights> <!-- Code --> <UserTask>
Example 6.24. Example of a Grant element
Grammar: ((Expression), (Expression))
A Greater expression contains exactly two subexpressions, which are both evaluated during the evaluation of the Greater expression. The expression evaluates to "true" if and only if the computed value of the first subexpression is greater than the value of the second subexpression.
Although a Greater expression may compare values of any type, this element makes sense only for integer, string, date and timer values as defined in the workflow.
<Variable name="Published" type="Date"/> <Assignment> <Writes variable="Published"/> </Assignment> <If name="IfTask"> <Condition> <Greater> <Get variable="Published"/> <Date value="31.12.2000 24:00"/> </Greater> </Condition> <Then successor="NewCentury"/> <Else successor="OldCentury"/> </If>
Example 6.25. Example of a Greater expression
Grammar: ((Expression), (Expression))
A GreaterEqual expression contains exactly two subexpressions, which are both evaluated during the evaluation of the GreaterEqual expression. The expression evaluates to "true" if and only if the computed value of the first subexpression is greater than or equal to the value of the second subexpression.
Although a GreaterEqual expression may compare values of any type, this element makes sense only for integer, string, date and timer values.
<Variable name="Published" type="Date"/> <Assignment> <Writes variable="Published"/> </Assignment> <If name="IfTask"> <Condition> <GreaterEqual> <Get variable="Published"/> <Date value="31.12.2000 24:00"/> </GreaterEqual> </Condition> <Then successor="NewCenturyOrNewYearsEve"/> <Else successor="OldCentury"/> </If>
Example 6.26. Example of a GreaterEqual expression
Grammar: EMPTY
The Group element is used to specify a single constant group value within expressions, variable initializers or policies. Either 'value' or 'name' must be specified.
If you delete a group in the user administration, which you have used in the
Group
element of an uploaded workflow definition, its polices will fail.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#IMPLIED |
Name of a group. |
domain |
NMTOKEN |
#IMPLIED |
Domain of the group. Might be used in addition to |
value |
NMTOKEN |
#IMPLIED |
numeric ID of a group. |
Table 6.28. Attributes of the Group element.name
<Variable name="Writer" type="Group"/> <Group value="10"/> </Variable>
Example 6.27. Example of a Group variable
Grammar: (Expression)
A Guard contains a Boolean expression, that defines a condition which must become true before a task is activated. See UserTask, AutomatedTask and Condition for details.
<AggregationVariable name="Articles" type="Document"/> <Assignment> <Writes variable="Articles"/> </Assignment> <UserTask name="AndTest" successor="TheNext"> <Guard> <Exists variable="Element" aggregate="Articles"> <Equal> <String value="Sports"/> <Read variable="Element" property="Topic"/> </Equal> </Exists> </Guard> <!-- Code --> </UserTask>
Example 6.28. Example of a Guard
Grammar: ((Variable | AggregationVariable)*, Condition, Then, Else)
An If task determines the successor task based on the result of a Condition. A condition may be based on the state of workflow variables, the content of documents from a Content Management Server or the external state of third-party products.
If the condition evaluates to true, the successor of the Then element is chosen, else the one of the Else element. See Example 6.29, “Example of an If task”.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the task |
description |
CDATA |
#IMPLIED |
the textual description of the task |
Table 6.29. Attributes of the If element
<Variable name="Comment" type="String"/> <Assignment> <Writes variable="Comment"/> </Assignment> <If name="IfTask"> <Condition> <Equal> <Get variable="Comment"/> <String value="42"/> </Equal> </Condition> <Then successor="Task1"/> <Else successor="Task2"/> </If>
Example 6.29. Example of an If task
Grammar: ((Expression), (Expression)*)
An Implies expression determines whether the first subexpression logically implies all
remaining sub expressions. Thus, <Implies>E1 E2 E3 ...<Implies/>
is
equivalent to <Or><Not>E1</Not> <AND>E2 E3
...</And></Or>
. For the common case of two subexpressions, an Implies
expression evaluates to "true" if and only if the first expression evaluates to "false"
(without caring for the result of the second subexpressions) or both expressions evaluate to
"true".
<Assignment> <Writes variable="changeSet" contentEditable="true"/> <Validator name="AllCheckedIn" description="all-checked-in-validator"> <ForAll variable="change" aggregate="changeSet"> <Implies> <And> <IsDocumentVersion variable="change"/> <Equal> <Read variable="change" property="version_"/> <Read variable="change" property="latestVersion_"/> </Equal> </And> <Not> <Read variable="change" property="isCheckedOut_"/> </Not> </Implies> </ForAll> </Validator> </Assignment>
Example 6.30. Example for an Implies expression
InitialAssignment
An InitialAssignment element defines that a variable is 'important' to a process instance during the initial creation of the workflow before the workflow is started. This way it is possible to set initial arguments for a process instance which cannot be changed after the instance is started.
With Reads and Writes the variables are specified. The variables can or have to be modified by a user or an external process. Thus, the InitialAssignment element defines a view on the variables. The modifications of the variables may be validated by Validators.
<Workflow> <Process name="InitialClientTest" startTask="TheFirst"> <Variable name="Comment" type="String"/> <Variable name="Articles" type="Document"/> <InitalAssignment> <Reads variable="Comment"/> <Writes variable="Articles"/> </InitalAssignment> <!-- Code --> </Process> </Workflow>
Example 6.31. Example of an InitialAssignment element
Deprecated. See InitialAssignment instead.
Grammar: EMPTY
The Integer element is used to specify a single constant integer value within expressions or variable initializers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
NMTOKEN |
#REQUIRED |
the integer value |
Table 6.30. Attribute of the Integer element
<Variable name="Number" type="Integer"> <Integer value="100"/> </Variable>
Example 6.32. Example of an Integer Variable
Grammar: EMPTY
IsDocument queries whether a resource value contained in the variable, which is given as in Get, is a document with or without an explicit version.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the document variable |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
Table 6.31. Attributes of the IsDocument element
<Variable name="Article" type="Resource"/> <Assignment> <Writes variable="Article"/> </Assignment> <UserTask name="AndTest" successor="theNext"> <EntryAction class="CheckOutDocument" documentVariable="Article"> <Condition> <IsDocument variable="Article"/> </Condition> </EntryAction> <!-- Code --> </UserTask>
Example 6.33. Example of an IsDocument expression
Grammar: EMPTY
IsDocumentVersion queries whether a resource value contained in the variable, which is given as in Get, is a document with an explicit version.
This is helpful because document variables may refer simply to a document or to a specific version of that document, so that processing may have to vary depending on the kind of value stored.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the document variable |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
Table 6.32. Attributes of the IsDocumentVersion element
<Variable name="Article" type="Document"/> <Assignment> <Writes variable="Article"/> </Assignment> <UserTask name="IsTest" successor="theNext"> <EntryAction class="PublishResource" documentVariable="Article"> <Condition> <IsDocumentVersion variable="Article"/> </Condition> </EntryAction> <!-- Code --> </UserTask>
Example 6.34. Example of an IsDocumentVersion expression
Grammar: EMPTY
IsEmpty evaluates to true if the value of the specified variable or resource property is "null". For an aggregation variable, length of zero is considered as empty, too. See Length for details. For an XML example see PostCondition.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the document variable |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
property |
NMTOKEN |
#IMPLIED |
the optional name of a resource property |
Table 6.33. Attributes of the IsEmpty element
Grammar: EMPTY
IsExpired queries whether the timer given by the defined variable has expired.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the timer variable |
Table 6.34. Attributes of the IsExpired element
<AutomatedTask name="StartTimer" description="SimplyStart" successor="Wait"> <Variable name="waiting" type="Timer"> <Timer value="100"/> </Variable> <Action class="EnableTimer" timerVariable="waiting"/> </AutomatedTask> <UserTask name="Wait" successor="Next"> <Guard> <IsExpired variable="StartTimer.waiting"/> </Guard> <!-- Code --> </UserTask>
Example 6.35. Example of an IsExpired expression
Grammar: EMPTY
IsFolder queries whether a resource value contained in the variable given via the
variable
attribute is a folder and not a document or document version.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the resource variable |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
Table 6.35. Attributes of the IsFolder element
<Variable name="Location" type="Resource"/> <!-- Code --> <AutomatedTask name="CreateDocument" successor="TheNext"> <PreCondition name="CheckLocation"> <IsFolder variable="Location"/> </PreCondition> <!-- Code --> </AutomatedTask>
Example 6.36. Example of an IsFolder expression
Grammar: ((Variable | AggregationVariable)*, Predecessor+)
A Join task waits for two or more tasks to complete. Joined tasks must have been forked by a Fork task to perform execution in parallel. A Join task waits for all of them to be completed.
The Predecessor elements contained in this element list all tasks that use this Join element as the successor. For an example see Fork.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of this task |
description |
CDATA |
#IMPLIED |
the textual description of this task |
successor |
NMTOKEN |
#REQUIRED |
the next task to execute after all predecessors have been joined |
Table 6.36. Attributes of the Join element
Grammar: (Variable | AggregationVariable)*
A JoinSubprocess task waits for a non detached subprocess to complete. For an XML example see ForkSubprocess.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
The name of this task |
description |
CDATA |
#IMPLIED |
The textual description of this task |
|
NMTOKEN |
#REQUIRED |
The name of the task that forked the subprocess to wait for |
successor |
NMTOKEN |
#REQUIRED |
The next task to execute after the subprocess has been joined |
|
NMTOKEN |
#IMPLIED |
Name of the variable of the subprocess that contains the result variable. |
|
NMTOKEN |
#IMPLIED |
Name of the variable of the current process into that the result value should be stored. |
Table 6.37. Attributes of the JoinSubprocess element
Grammar: EMPTY
Length evaluates to the length of the value of the specified variable or resource property and depends on the type. For an aggregation variable it returns the number of elements, for a string variable or string property it returns the length of the string. See also Get and Read.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the variable |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
property |
NMTOKEN |
#IMPLIED |
the optional name of a resource property |
Table 6.38. Attributes of the Length element
<Variable name="Input" type="String"> <Assignment> <Writes variable="Input"/> </Assignment> <UserTask name="LengthCheck" successor="TheNext"> <Guard> <Greater> <Length variable="Input"/> <Integer value="4"/> </Greater> </Guard> <!-- Code --> </UserTask>
Example 6.37. Example of a Length element
Grammar: ((Expression), (Expression))
A Less expression contains exactly two subexpressions, which are both evaluated during the evaluation of the Less expression. The expression evaluates to "true" if and only if the computed value of the first subexpression is less than the value of the second subexpression.
Although a Less expression may compare values of any type, this element makes sense only for integer, string, date, and timer values as defined in the workflow.
Grammar: ((Expression), (Expression))
A LessEqual expression contains exactly two subexpressions, which are both evaluated during the evaluation of the LessEqual expression. The expression evaluates to "true" if and only if the computed value of the first subexpression is less than or equal to the value of the second subexpression.
Although a LessEqual expression may compare values of any type, this element makes sense only for integer, string, date and timer values as defined in the workflow. See Less for an XML example.
<Variable name="Published" type="Date"/> <!-- Code --> <If name="IfTask"> <Condition> <Less> <Get variable="Published"/> <Date value="31.12.2000 24:00"/> </Less> </Condition> <Then successor="NewCentury"/> <Else successor="OldCentury"/> </If>
Example 6.38. Example of a Less expression
Grammar: ((Expression), (Expression))
Let binds an expression-local variable to a value determined by the first subexpression. It evaluates to the value of the second subexpression, which can use the expression-local variable. Let is useful to reuse complex subexpressions and store their result in an expression-local variable. Some functions as Length and Read can only be applied to variable values. Using Let they can be applied to any expression (mostly custom expressions), which must return values which must make sense.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the local variable that will be bound to the result of the first subexpression |
Table 6.39. Attributes of the Let element
<Variable name="Article" type="Document"/> <Assignment> <Writes variable="Article"/> </Assignment> <UserTask name="LetTest" successor="Final"> <Guard> <Let variable="Test"> <Read variable="Article" property="Headline"/> <Greater> <Integer value="50"/> <Length variable="Test"/> </Greater> </Let> </Guard> <!-- Code --> </UserTask>
Example 6.39. Example of a Let element which is needed to check whether the headline of an article is longer than 50 characters or not
Grammar: (Expression)
A Not expression evaluates its Boolean subexpression and returns the logical negation of the result.
<ForAll variable="Element" aggregate="Articles"> <Not> <Read variable="Element" property="isCheckedOut_"/> </Not> </ForAll>
Example 6.40. Example of a Not element
Grammar: EMPTY
NotEmpty is the negation of IsEmpty. See IsEmpty for details.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the document variable |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
property |
NMTOKEN |
#IMPLIED |
the optional name of a resource property |
Table 6.40. Attributes of the NotEmpty element
Grammar: ((Expression), (Expression))
A NotEqual expression is the negation of an Equal expression.
<Variable name="Comment" type="String"/> <Assignment> <Writes variable="Comment"/> </Assignment> <UserTask name="AndTest" successor="TheNext"> <Guard> <NotEqual> <Get variable="Comment"/> <String value="LetMeIn"/> </NotEqual> </Guard> <!-- Code --> </UserTask>
Example 6.41. Example of a NotEqual expression
Grammar: ((Expression)*)
An Or expression evaluates to the disjunction of its subexpressions, all of which must return Boolean values. The subexpressions are evaluated in a "short-circuit" fashion, that is, they are evaluated from left to right until the first subexpression evaluates to "true" or all subexpressions have evaluated to "false".
<UserTask name="AndTest" successor="theNext"> <PreCondition> <Or> <Equal> <Get variable="OWNER_"/> <User value="0"/> </Equal> <Equal> <Get variable="Comment"/> <String value="42"/> </Equal> </Or> </Precondition> <!-- Code --> </UserTask>
Example 6.42. Example of an Or expression
Grammar: (Assign+)
Parameters is used to enclose the elements that define how to parametrize a subprocess. For an XML example see ForkSubprocess.
Grammar: ANY
A Performers element specifies external code that is called to determine which users to offer a task for acceptance. If you do not use this element, the default policy DefaultPerformersPolicy is used.
You can either give the fully qualified name of your own Performers class which must be an
implementation of
com.coremedia.workflow.WfPerformersPolicy,
an unqualified class name which will be searched for in the package
com.coremedia.workflow.common.policies
or it defaults to a built-in generic
implementation
com.coremedia.workflow.common.policies.DefaultPerformersPolicy.
The default implementation keeps a blacklist of users not permitted to perform a task and a list of preferred users. Upon setting a new preferred user or group the old preference is deleted. For details see the Action class PreferPerformer.
Attribute |
Type |
Default |
Description |
---|---|---|---|
|
NMTOKEN |
#IMPLIED |
the class that determines the performers |
varies |
additional parameters according to the implementation of the policy class |
Table 6.41. Attributes of the Performers element
<UserTask name="PerformersTest" successor="TheNext"> <Performers policyClass="com.coremedia.MyPolicyClass"/> <!-- Code --> </UserTask>
Example 6.43. Performers element
Grammar: (Expression)
A PostCondition assert a condition that must hold after an (optional) exit action (user task) or action (automated task) has run. See Condition for details.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#IMPLIED |
the name of the PostCondition |
description |
CDATA |
#IMPLIED |
a textual description of the verified condition |
Table 6.42. Attributes of the PostCondition element
<Variable name="Article" type="Document"> <UserTask name="PostCondition" successor="TheNext"> <!-- Code --> <Assignment> <Writes variable="Article"/> </Assignment> <!-- Code --> <PostCondition name="CheckDocument"> <Not> <IsEmpty variable="Article"/> </Not> </PostCondition> </UserTask>
Example 6.44. Example of a PostCondition element
Grammar: (Expression)
A PreCondition asserts a condition that must hold when the task has been accepted but before an entry action (user task) or action (automated task) has run. It is described by an expression. See Condition for details.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#IMPLIED |
the name of the PreCondition |
description |
CDATA |
#IMPLIED |
a textual description of the verified condition |
Table 6.43. Attributes of the Precondition element
<Variable name="Location" type="Folder"/> <Variable name="DocName" type="String"/> <Assignment> <Writes variable="Location"/> <Writes name="DocName"/> </Assignment> <AutomatedTask name="CreateDocument" successor="TheNext"> <PreCondition name="CheckLocation"> <IsFolder variable="Location"/> </PreCondition> <Variable name="DocType" type="DocumentType"> <DocumentType value="Article"/> </Variable> <Action name="CreateDocument" folderVariable="Location" nameVariable="DocName" typeVariable="DocType"/> </AutomatedTask>
Example 6.45. Example of a PreCondition
Grammar: EMPTY
A Predecessor elements defines a predecessor of a Join task by its name. See Fork for an XML example.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of one predecessor task |
Table 6.44. Attribute of the Predecessor element
Grammar: (Rights?, (Variable | AggregationVariable)*, InitialClient?, Client?, (Task)+)
A process is a definition of a workflow process which is identified by its name. It consists
of tasks, which reference each other by name. The startTask
attribute defines the name of the
start task. A process is the template for a process instance. To run a process, it has to be
instantiated. At that time an actual process instance is created, which carries the process
state and completes the workflow steps that are defined by tasks and carried out by task
instances.
The description of the process is a human readable explanation about what the process does or a key used for localization.
The subprocessOnly
attribute defines whether an instance of the process can be created as a
top level instance or only as a subprocess instance. The default is false.
The Rights element configures user and group permissions for the process instance operations.
Variables in the process scope define the global state of the workflow process. With InitialClient and Client, you define which variables are to be read or written by a user or an external process. The InitialClient element is used for initializing the process before it is started while the Client element is used afterwards when the process is running.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the process |
description |
CDATA |
#IMPLIED |
a textual description of what the process does or a localization key. |
|
NMTOKEN |
#REQUIRED |
the name of the initial task |
|
(Boolean) |
"false" |
Specify this attribute for processes that cannot run stand-alone. |
|
NMTOKEN |
#IMPLIED |
the maximum number of seconds that an instance of this process is supposed to take |
Table 6.45. Attributes of the Process element
<Workflow> <Process name="Example" description="An example" startTask="First"> <!-- Code --> </Process> </Workflow>
Example 6.46. Example of the Process element
Grammar: EMPTY
The Property element defines the properties with which a new document is created.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of a property as defined in the document type |
value |
CDATA |
#REQUIRED |
a value of the appropriate type |
Table 6.46. Attributes of the Property element
<Variable name="Location" type="Folder"/> <Variable name="DocName" type="String"/> <Assignment> <Writes variable="Location"/> <Writes name="DocName"/> </Assignment> <AutomatedTask name="CreateDocument" successor="TheNext"> <Variable name="DocType" type="DocumentType"> <DocumentType value="Article"/> </Variable> <Action name="CreateDocument" folderVariable="Location" nameVariable="DocName" typeVariable="DocType"> <Property name="Headline" value="Politics"/> <Property name="Creator" value="AutomaticCreator"/> </Action> </AutomatedTask>
Example 6.47. Example of a Property element
Grammar: EMPTY
Read evaluates to the contents of the given property of a resource. 'property' can be the name of any implied or schema property of a resource. A blob property will be returned as an XML representation in a string value, a linklist property will be returned as an aggregation variable of documents and an SGML property will be returned as a string. All other property types will be returned as the appropriate workflow variable value. See Exists for an XML example.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the document variable |
index |
NMTOKEN |
#IMPLIED |
the optional index into an aggregation variable, given by a variable name or a constant value |
property |
NMTOKEN |
#IMPLIED |
the name of the resource property to read |
Table 6.47. Attributes of the Read element
Grammar: EMPTY
Reads and Writes specify the variables that are 'important' to a task or process instance. For variables that are specified with Reads, it is not possible to modify them. They are just shown in the editor. Accordingly, Writes allows you to modify variables on a workflow client.
The variable attribute specifies the name of the variable. The description is a human readable explanation about how to interpret or modify the variable. It may be localized by the editor.
Resource variables may be declared as contentEditable
, which means that you can
change the content of the resource stored in the variable (if you have the appropriate rights
on the resource) but you can not change the resource to which the variable references even if
the variable itself is read-only.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
Defines the name of the read variable |
description |
CDATA |
#IMPLIED |
Defines the textual description of the meaning of the variable |
|
(Boolean) |
"true" |
Defines whether a document referred to by a variable may be edited in the embedded document view |
Table 6.48. Attributes of the Reads element
<Variable name="Comment" type="String"/> <Variable name="Article" type="Document"/> <Assignment> <Reads variable="Comment"/> <Reads variable="Article" contentEditable="true"/> </Assignment>
Example 6.48. Example of a Reads element
Grammar: EMPTY
The Resource element is used to specify a single constant resource within expressions or
variable initializers. It is not useful to define a fixed resource ID in the workflow. Either
value
or path
must be selected.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
NMTOKEN |
#IMPLIED |
The ID of the resource. |
path |
NMTOKEN |
#IMPLIED |
The path of the resource. |
Table 6.49. Attributes of the Resource element.
<Variable name="DocFol" type="Resource"> <Resource value="12"/> </Variable>
Example 6.49. Example of a Resource variable
Grammar: EMPTY
Revoke revokes the operations for users or groups like Section 6.2, “XML Element Reference” grants them (only valid for the default ACL rights policy). See Section 6.2, “XML Element Reference” for details. Rights specified using variables precede user rights, which again precede group rights. Within each category, revokes precede grants.
Attribute |
Type |
Default |
Description |
---|---|---|---|
user |
NMTOKEN |
#IMPLIED |
the name of a user or the user ID of a user |
group |
NMTOKEN |
#IMPLIED |
the name of a group or the group ID of a group |
domain |
NMTOKEN |
#IMPLIED |
Domain of a group or user. Might be used in addition, if group or user has been chosen. |
variable |
NMTOKEN |
#IMPLIED |
the name of a variable that stores a user or a group or a list of these |
rights |
CDATA |
#REQUIRED |
a comma-separated list of rights as specified above |
Table 6.50. Attributes of the Revoke element.
<UserTask name="GrantExample" successor="TheNext"> <Rights> <Grant group="composer-role" rights="accept, complete, delegate, read"/> <Revoke user="demo1" rights="delegate"/> </Rights> <!-- Code --> <UserTask>
Example 6.50. Example of a Revoke element
Grammar: (Section 6.2, “XML Element Reference”*, Revoke)
The Rights element defines user and group permissions for the workflow operations.
You can either give the full qualified name of your own Rights class which must be an
implementation of
com.coremedia.workflow.WfRightsPolicy,
an unqualified class name which will be searched for in the package
com.coremedia.workflow.common.policies
or it defaults to a built-in generic
implementation
com.coremedia.workflow.common.policies.ACLRightsPolicy.
The default policy ACLRightsPolicy defines an access control list like implementation:
Right can be granted to individual users or group (Section 6.2, “XML Element Reference”).
Rights can be revoked for individual users or groups (Revoke).
User defined rights precede group rights.
Negative rights (revokes) precede positive rights.
The admin user has all rights (this is the user with id 0).
Specific rights are explicitly granted to the owner of the process and the performer of a task.
The process owner may:
Read and write variables exported by the processes client view.
Start the process instance.
Skip, assign and delegate any user task.
Retry the last transaction on an aborted task instance (not dependent on the policy).
The task performer may:
Read and write variables exported by the tasks client view.
Cancel or complete the accepted task instance.
Retry the last transaction if the task instance is aborted.
Attribute |
Type |
Default |
Description |
---|---|---|---|
|
NMTOKEN |
#IMPLIED |
the class that determines the policy |
varies | additional parameters according to the implementation of the policy class |
Table 6.51. Attributes of the Rights element
<Workflow> <Process name="RightsExample" startTask="First"> <Rights> <Grant group="composer-role" rights="create, start, suspend"/> </Rights> <!-- Code --> <UserTask name="First" description="The first Task" successor="Next"> <Rights> <Grant user="demo1" rights="accept, complete, read"/> </Rights> <!-- Code --> </UserTask> <!-- Code --> </Process> </Workflow>
Example 6.51. Example of a Rights element
Grammar: EMPTY
The String element is used to specify a single constant string value within expressions or variable initializers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
CDATA |
#REQUIRED |
the string value |
Table 6.52. Attribute of the String element
<Variable name="Text" type="String"> <String value="Hello World"/> </Variable>
Example 6.52. Example of a String variable
Grammar: EMPTY
A Successor element defines a successor task of a Fork or Choice task by its name. See Fork for an example.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the successor task |
Table 6.53. Attribute of the Successor element
Grammar: (Variable | AggregationVariable)*, (Case)+)>
A Switch task determines the successor based on the result of two or more 'case' conditions. The successor is defined by the first 'case' condition evaluating to true. The conditions are evaluated in sequential order of their definition. A default successor is mandatory if all given conditions evaluate to false.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
The name of the task. |
description |
CDATA |
#IMPLIED |
The textual description of the task. |
|
NMTOKEN |
#REQUIRED |
The default successor task that is chosen if no case condition matches. |
Table 6.54. Attributes of the Switch element.
<Switch name="SwitchTask" defaultSuccessor="DefaultTask"> <Case successor="FirstSuccessor"> <Equal> <Get variable="Comment"/> <String value="42"/> </Equal> </Case> <Case successor="SecondSuccessor"> <Equal> <Get variable="Comment"/> <String value="13"/> </Equal> </Case> </Switch>
Example 6.53. Example of the Switch element.
Grammar: EMPTY
Then defines the successor of the If task if the condition evaluates to true, see If for details and an example.
Attribute |
Type |
Default |
Description |
---|---|---|---|
successor |
NMTOKEN |
#REQUIRED |
the name of the successor task in the "then" case |
Table 6.55. Attribute of the Then element
Grammar: EMPTY
The Timer element is used to specify a single constant timer value within expressions or variable initializers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
NMTOKEN |
#IMPLIED |
For relative timers, this attribute specifies the number of seconds until the timer runs out. |
relative |
(Boolean) |
"true" |
This attribute determines whether the timer should be a relative timer. An absolute timer will not be useful in the workflow definition. |
Table 6.56. Attributes of the Timer element
<Variable name="Expires" type="Timer"> <Timer value="100"/> </Variable> <Action class="EnableTimer" timerVariable="Expires"/>
Example 6.54. Example of a Timer variable
TimerHandler
Grammar: EMPTY
The TimerHandler element is used to assign a timer handler to a timer. The handler must be defined in the same location, that is the process or task definition, where its associated timer variable is defined. See Section 4.4.2, “Predefined TimerHandler Classes” for a list of predefined timer handlers.
Attribute |
Type |
Default |
Description |
---|---|---|---|
class |
NMTOKEN |
#REQUIRED |
Timer handler class that is called. |
name |
NMTOKEN |
#IMPLIED |
Name of the timer handler. |
|
NMTOKEN |
#REQUIRED |
Name of the timer for which the timer handler is installed. |
Table 6.57. Attributes of the TimerHandler element
<AutomatedTask name="StartTimer" description="SimplyStart" successor="Wait"> <Variable name="waiting" type="Timer"> <Timer value="100"/> </Variable> <Action class="enableTimer" timerVariable="waiting"/> <TimerHandler class="RunActionTimerHandler" name="TimerHandler" timerName="waiting"> <Action class="Log" info="true" message="Entering task with x = "/> </TimerHandler> </AutomatedTask>
Example 6.55. Example of a TimerHandler element
Grammar: EMPTY
The User element is used to specify a single constant user value within expressions, variable initializers or policies. Either 'value' or 'name' must be specified.
If you delete a user in the user administration, which you have used in the User
element of an uploaded workflow definition, its polices will fail.
Attribute |
Type |
Default |
Description |
---|---|---|---|
value |
NMTOKEN |
#IMPLIED |
The numeric ID of a user. |
name |
NMTOKEN |
#IMPLIED |
The name of a user. |
domain |
NMTOKEN |
#IMPLIED |
The domain of a user. Might be used in addition to |
Table 6.58. Attributes of the User element.
<Variable name="Admin" type="User"> <User value="0"/> </Variable>
Example 6.56. Example of a User variable
Grammar: (Rights, Performer?, (Variable | AggregationVariable)*, Client*, EntryAction*, ExitAction*, Guard?, PreCondition*, PostCondition)
A UserTask has to be carried out by a participant. The performers policy is external code which is called to determine which users to offer this task for acceptance.
The defaultOfferTimeout
defines the default time in seconds that task instances are offered to
users to be accepted. The defaultTimeout
defines the default time in seconds until task
instances have to be completed after being accepted. If no timeout time is set, then no
timeout is defined at all. A defaultPriority
sets the default priority of task instances.
Priorities may be used to distinguish the urgency of task instances. A successor must be given
if and only if the task is not final.
The run time of an autocompleted task is determined by the time that the executed actions and
the PreConditions
and PostConditions
take. It will not be completed by the user but just runs through
all included actions. Since EntryActions and ExitActions are executed, the effect is that a
user can determine when this execution is supposed to take place and that it takes place on
behalf of the user. Consider autocompleted tasks as semi-automatic tasks.
The Rights element configures user and group permissions for the task instance operations.
Client determines which variables are relevant for this task and may be changed.
A user task may perform some automated action (EntryAction) after the task is accepted and after the task has been completed by the user (ExitAction). If more than one EntryAction or ExitAction is provided, then the actions are executed in the order they are specified.
PreConditions
define requirements which have to be fulfilled before the entry actions of the
user task are executed. PostConditions define requirements which have to be fulfilled after
all the exit actions have been executed. PreConditions
and PostConditions
are evaluated in the
order they are specified. The result of such an evaluation operation is equivalent to
specifying an 'and' expression with an ordered set of conditions.
A Guard defines an expression, which activates the task, if the expression evaluates to true. The expressions of the condition are rechecked on state changes of process instances or task instances and resources in the Live Server.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the task |
description |
CDATA |
#IMPLIED |
the textual description of the task |
|
NMTOKEN |
#IMPLIED |
the priority of the task |
|
NMTOKEN |
#IMPLIED |
the default timeout in seconds |
|
NMTOKEN |
#IMPLIED |
the default offer timeout in seconds |
successor |
NMTOKEN |
#IMPLIED |
the next task to execute after the user task has been completed |
final |
(Boolean) |
"false" |
Defines whether the task is the final task to execute |
|
(Boolean) |
"false" |
Defines whether the task is automatically accepted if it was assigned to a single user with
the |
autoCompleted |
(Boolean) |
"false" |
Defines whether the task is autocompleted |
varies | additional parameters according to the implementation of the user task class |
Table 6.59. Attributes of the UserTask element
<UserTask name="UserTaskExample" description="Example UserTask" successor="Next"> <Rights> <Grant user="demo1" rights="accept, complete, read"/> </Rights> <!-- Code --> </UserTask>
Example 6.57. Example of a UserTask task
Grammar: (Expression
A validator verifies variable bindings to keep certain rules, which are defined in the Validator element.
By default, the variable bindings are verified only on initial process assignment or task
completion. If validatedOnSave
is set to "true", the verification takes place on
every save.
To specify a valid state, you provide an expression to the validator.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#IMPLIED |
the name of the validator |
description |
CDATA |
#IMPLIED |
the textual description of the condition that is verified |
|
(Boolean) |
"false" |
Defines whether the verification should take place on every save |
varies | additional parameters according to the implementation of the validator class |
Table 6.60. Attributes of the Validator element
<Assignment> <Writes variable="subject"/> <Writes variable="comment"/> <Writes variable="changeSet" contentEditable="true"/> <Validator name="AllCheckedIn" description="all-checked-in-validator"> <ForAll variable="change" aggregate="changeSet"> <Implies> <And> <IsDocumentVersion variable="change"/> <Equal> <Read variable="change" property="version_"/> <Read variable="change" property="latestVersion_"/> </Equal> </And> <Not> <Read variable="change" property="isCheckedOut_"/> </Not> </Implies> </ForAll> </Validator> </Assignment>
Example 6.58. Example of a Validator element
Grammar: (Value)?
Variables carry state for the workflow process. It may be modified from within the workflow engine or by changing client view variables.
A variable is referenced by its name. It has a type which is determined by the Value class given with the type attribute. See Value for details. The value of a variable is defined by one of the elements Boolean, String etc.
If a variable is declared as readOnly
and the process instance has
been started, it is not possible to modify it. If a variable is
declared as static, it maintains its state, otherwise it is reinitialized to the defined
default every time a task instance is started.
Attribute |
Type |
Default |
Description |
---|---|---|---|
name |
NMTOKEN |
#REQUIRED |
the name of the variable |
type |
NMTOKEN |
#REQUIRED |
the type of the variable, see Value |
|
(Boolean) |
"false" |
Defines whether it is forbidden to modify the variable |
static |
(Boolean) |
"false" |
Defines whether the variable is initialized only once |
Table 6.61. Attributes of the Variable element
<Variable name="Comment" type="String"> <String value="42"/> </Variable>
Example 6.59. Example of a Variable element
Grammar: (Process)
You can configure exactly one process per workflow definition, which means one workflow per file. If you wish to define more workflow processes, create their definition in separate files. This might be extended in the future.
<Workflow> <Process name="WorkflowExample" startTask="First"> <!-- Code --> </Process> </Workflow>
Example 6.60. Example of the Workflow element
Grammar: EMPTY
In a Client, a Writes element declares that a variable may be viewed and modified. See Reads for details.
Attribute |
Type |
Default |
Description |
---|---|---|---|
variable |
NMTOKEN |
#REQUIRED |
the name of the written variable |
description |
CDATA |
#IMPLIED |
the textual description of the meaning of the variable |
|
(Boolean) |
"true" |
Defines whether a document referred to by a variable may be edited in the embedded document view (not enforced by the workflow server) |
Table 6.62. Attributes of the Writes element
<Variable name="Comment" type="String"/> <Assignment> <Writes variable="Comment"/> </Assignment>
Example 6.61. Example of a Writes element