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:

Action attributes

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.

Expression

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.

FlowControlTask

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.

Task

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:

Value

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>

Boolean

Definition: true | false

Definition of a Boolean XML attribute type.

varies

Definition: Entity for tagging varying parts of the DTD.

Action

An action is external code which may be called to customize the processing of the workflow engine (see Section 5.3, “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.

<UserTask name="TestActionGuard" successor="final">
.
.
  <Action class="EnableTimer" timerVariable="TimeVariable">
    <Condition>
      <Equal>
        <Read variable="document" property="_name"/>
        <String value="Article"/>
      </Equal>
    </Condition>
  </Action>
.
.
</UserTask>

AddLatestVersion

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.

AggregationVariable

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.

<Workflow>
   <Process name="AggregationExample" startTask="Start">
     <AggregationVariable name="StringTest" type="String">
        <String value="World"/>
        <String value="Hello"/>
     </AggregationVariable>
     .
     .
   </Process>
<Workflow>

And

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>

Assign

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”.

AutomatedTask

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.

<Variable name="document" type="Document"/>
<Assignment>
   <Writes variable="document"/>
</Assignment>
<AutomatedTask name="automatic" successor="final">
   <Action class="CheckInDocument" documentVariable="document"/>
</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>

Blob

Grammar: EMPTY

The Blob element is used to specify a single constant blob value within expressions or variable initializers.

<Variable name="Logical" type="Blob">
   <Blob value="Some text..." mimeType="text/plain"/>
</Variable>

Boolean

Grammar: EMPTY

The Boolean element is used to specify a single constant Boolean value within expressions or variable initializers.

<Variable name="Logical" type="Boolean">
   <Boolean value="true"/>
</Variable>

Case

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.

Choice

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.

<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>

Client

Deprecated. See Assignment instead.

Condition

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.

<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>

ContentType

Grammar: EMPTY

The ContentType element is used to specify a single constant content type within expressions or variable initializers.

<Variable name="Type" type="ContentType">
   <ContentType value="Article"/>
</Variable>

Date

Grammar: EMPTY

The Date element is used to specify a single constant date value within expressions or variable initializers.

<Variable name="Time" type="Date">
   <Date value="10.11.2002 13:00"/>
</Variable>

Document

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.

<Variable name="Article" type="Document">
   <Document value="10"/>
</Variable>

Else

Grammar: EMPTY

Else defines the successor of the If task if the condition evaluates to false, see If for details and an XML example.

EntryAction

Grammar: (Condition?, Property?)

EntryAction and ExitAction elements are identical to Action elements, see Action and Action-Attributes for details.

<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>

Equal

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>

Exists

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".

<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>

ExitAction

Grammar: (Condition?, Property?)

ExitAction and EntryAction elements are identical to Action elements, see Action for details.

<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>

Expression

Grammar: ((Expression)*)

You can implement your own expressions (see Section 5.4, “Programming Expressions”). Custom expressions must implement the interface com.coremedia.workflow.WfExpression or com.coremedia.workflow.WfBooleanExpression.

<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>

FinalAction

The element FinalAction defines a final action that is executed after a process was completed or aborted. Its class attribute specifies the fully qualified name of a custom final action, which must be an implementation of com.coremedia.cap.workflow.plugin.FinalAction. Section 4.4.2, “Predefined FinalAction Classes” lists predefined classes that can also be used.

Folder

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.

<Variable name="RootFolder" type="Folder">
   <Folder value="1"/>
</Variable>

ForAll

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.

<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>

Fork

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 --> 

ForkSubprocess

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.

<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>

Get

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.

<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>

Grant

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

<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>

Greater

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>

GreaterEqual

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>

Group

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.

<Variable name="Writer" type="Group"/>
   <Group value="10"/>
</Variable>

Guard

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>

If

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”.

<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>

Implies

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>

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>

InitialClient

Deprecated. See InitialAssignment instead.

Integer

Grammar: EMPTY

The Integer element is used to specify a single constant integer value within expressions or variable initializers.

<Variable name="Number" type="Integer">
   <Integer value="100"/>
</Variable>

IsDocument

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.

<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>

IsDocumentVersion

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.

<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>

IsEmpty

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.

IsExpired

Grammar: EMPTY

IsExpired queries whether the timer given by the defined variable has expired.

<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>

IsFolder

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.

<Variable name="Location" type="Resource"/>
<!-- Code -->
<AutomatedTask name="CreateDocument" successor="TheNext">
    <PreCondition name="CheckLocation">
        <IsFolder variable="Location"/>
    </PreCondition>
    <!-- Code -->
</AutomatedTask>

Join

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.

JoinSubprocess

Grammar: (Variable | AggregationVariable)*

A JoinSubprocess task waits for a non detached subprocess to complete. For an XML example see ForkSubprocess.

Length

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.

<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>

Less

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.

LessEqual

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>

Let

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.

<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>

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>

NotEmpty

Grammar: EMPTY

NotEmpty is the negation of IsEmpty. See IsEmpty for details.

NotEqual

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>

Or

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>

Parameters

Grammar: (Assign+)

Parameters is used to enclose the elements that define how to parametrize a subprocess. For an XML example see ForkSubprocess.

Performers

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.

<UserTask name="PerformersTest" successor="TheNext">
    <Performers policyClass="com.coremedia.MyPolicyClass"/>
    <!-- Code -->
</UserTask>

PostCondition

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.

<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>

PreCondition

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.

<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>

Predecessor

Grammar: EMPTY

A Predecessor elements defines a predecessor of a Join task by its name. See Fork for an XML example.

Process

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.

<Workflow>
   <Process name="Example" description="An example" 
    startTask="First">
      <!-- Code -->
   </Process>
</Workflow>

Property

Grammar: EMPTY

The Property element defines the properties with which a new document is created.

<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>

Read

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.

Reads

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.

<Variable name="Comment" type="String"/>
<Variable name="Article" type="Document"/>
<Assignment>
   <Reads variable="Comment"/>
   <Reads variable="Article" contentEditable="true"/>
</Assignment>

Resource

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.

<Variable name="DocFol" type="Resource">
   <Resource value="12"/>
</Variable>

Revoke

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.

<UserTask name="GrantExample" successor="TheNext">
    <Rights>
        <Grant group="composer-role" 
         rights="accept, complete, delegate, read"/>
        <Revoke user="demo1" rights="delegate"/>
    </Rights>
        <!-- Code -->
<UserTask>

Rights

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:

Specific rights are explicitly granted to the owner of the process and the performer of a task.

The process owner may:

The task performer may:

<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>

String

Grammar: EMPTY

The String element is used to specify a single constant string value within expressions or variable initializers.

<Variable name="Text" type="String">
   <String value="Hello World"/>
</Variable>

Successor

Grammar: EMPTY

A Successor element defines a successor task of a Fork or Choice task by its name. See Fork for an example.

Switch

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.

<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>

Then

Grammar: EMPTY

Then defines the successor of the If task if the condition evaluates to true, see If for details and an example.

Timer

Grammar: EMPTY

The Timer element is used to specify a single constant timer value within expressions or variable initializers.

<Variable name="Expires" type="Timer">
   <Timer value="100"/>
</Variable>
<Action class="EnableTimer" timerVariable="Expires"/>

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.3, “Predefined TimerHandler Classes” for a list of predefined timer handlers.

<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>

User

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.

<Variable name="Admin" type="User">
   <User value="0"/>
</Variable>

UserTask

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.

<UserTask name="UserTaskExample" description="Example UserTask" 
  successor="Next">
    <Rights>
        <Grant user="demo1" rights="accept, complete, read"/>
    </Rights>
    <!-- Code -->
</UserTask>

Validator

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.

<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>

Variable

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.

<Variable name="Comment" type="String">
    <String value="42"/>
</Variable>

Workflow

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>

Writes

Grammar: EMPTY

In a Client, a Writes element declares that a variable may be viewed and modified. See Reads for details.

<Variable name="Comment" type="String"/>
<Assignment>
   <Writes variable="Comment"/>
</Assignment>