Workflow Manual / Version 2110
Table Of ContentsHere the definition of a workflow is shown by means of the Studio simple publication workflow.
The routine is: An editor creates and edits a change set in the compose task. After completing
the compose task, the resources will be approved and published automatically (only if the
forceUser action succeeds). In Example 6.62, “Listing of the direct publication workflow” you find
the complete XML definition of this workflow.
The workflow definition consists of multiple blocks:
The general definitions of the workflow
An automated task AssignComposer
Am
usertask ComposeAn
iftask CheckEmptyChangesetA user task Publish
An
iftask CheckPublicationAn automated task Finish
A FinalAction
These blocks will be illustrated in detail.
General definitions
1: <?xml version="1.0" encoding="iso-8859-1"?>
2:
3: <Workflow>
4: <Process name="StudioSimplePublication"
description="studio-simple-publication"
startTask="AssignUser">
5:
6: <Rights>
7: <Grant group="administratoren"
rights="read, create, start, suspend, resume,
abort"/>
8: <Grant group="composer-role"
rights="read, create, start, suspend, resume,
abort"/>
9: <Grant group="approver-role" rights="read"/>
10: <Grant group="publisher-role" rights="read"/>
11: </Rights>
12:
13: <Variable name="subject" type="String"/>
14: <Variable name="comment" type="String"/>
15: <AggregationVariable name="changeSet" type="Resource"/>
16: <AggregationVariable name="comments" type="String"/>
17:
18: <Variable name="changeSetLockedInStudio" type="Boolean">
19; <Boolean value="true"/>
20: </Variable>
21: <Variable name="publicationSuccessful" type="Boolean">
22: <Boolean value="false"/>
23: </Variable>
24: <AggregationVariable name="publicationResultResources"
type="Resource"/>
25: <AggregationVariable name="publicationResultCodes"
type="Integer"/>
26: <AggregationVariable name="publicationResultVersions"
type="Integer"/>
27: <AggregationVariable name="publicationResultParams"
type="String"/>
28:
29: <InitialAssignment>
30: <Writes variable="subject"/>
31: <Writes variable="comment"/>
32: <Writes variable="changeSet"/>
33: <Writes variable="comments"/>
34: </InitialAssignment>
35:
36: <Assignment>
37: <Reads variable="subject"/>
38: <Reads variable="comment"/>
39: <Reads variable="changeSet"/>
40: <Reads variable="comments"/>
41: </Assignment>
42: .
43: .
44: .
45: </Process>
46: </Workflow>
Example 4.10. General definitions of the workflow
In the general definitions the workflow itself is described.
| Line 4 - 5: The process is named 'SimplePublication'. The localized name is displayed in the GUI when selecting a workflow. The first task that is executed after the workflow start is the task 'AssignComposer'. |
| Line 6 - 11: The rights (see Section 4.1.9, “Rights”) concerning the workflow are assigned to users and groups. The user admin can create, start, suspend, resume and abort a workflow instance. The members of the group composer-role are allowed to create, start, suspend, resume and abort the workflow process instance. |
Line 13 - 27: Different variables are defined by name
and type for storing the state of the workflow. The changeSet and
comment variables store the resources which are processed and the
comments of the users. The four aggregation variables which are prefixed with publication
are used to store the publication result. |
Lines 29 - 34: If a new workflow has been created a
dialog box opens up (this can be suppressed) where workflow variables can be
initialized. The variables to show or set are defined in this initial client view. The
variables subject, comment, changeSet
and comments will be shown in the initial window, so
that the creator of the workflow can change the content of the variable. |
Line 36 - 41: If the workflow has been started, the
variables defined in this client view will be shown in the variable view of the workflow
window. The variables need not to be read only as in the example. The variables subject,
comment, changeSet and comments
will be shown in the variable view (if the workflow is
selected in the workflow list), but it is not possible to change the variables, because
they are defined as read only via the <Reads ...> elements. |
Automated Task 'AssignUser'
1: <AutomatedTask name="AssignUser"
description="assignuser-task"
successor="CheckEmptyChangeSet">
2: <Action class="ForceUser" task="Publish"
userVariable="OWNER_"/>
3: <Action class="ForceUser" task="Compose"
userVariable="OWNER_"/>
4: <Action class="RegisterPendingProcess"
userVariable="OWNER_"/>
5: </AutomatedTask>
Example 4.11. Automated task "Assign User"
The first task in the workflow is an automated task that assigns a user to the main tasks - the user task 'Compose' and 'Publish - of the workflow. The user to assign is the creator and thus owner of the workflow.
| Line 1 + 5: The automated task is named 'AssignUser'. The names of tasks are used in the definition of a successor of a task. The task, that is started after task 'AssignUser' completes, is 'CheckEmptyChangeSet'. |
Line 2 + 3: The Action element defines the
action which should be executed in the automated task. Here the predefined
ForceUser
action is used, which assigns the user defined in userVariable to the task
defined in task. Thus, the Compose and Publish tasks will only be offered and
automatically accepted to the user defined in the variable OWNER_.
WfVariableOWNER_ is a predefined variable which contains the user, who
created the workflow.
|
Line 4: The RegisterPendingProcess registers the workflow process
in the user's pending processes list. Users can watch their pending workflows in the Control Room. |
User Task 'Compose'
1: <UserTask name="Compose"
description="studio-simple-publication-compose-task"
successor="CheckEmptyChangeSet" reexecutable="true"
autoAccepted="true">
2: <Rights>
3: <Grant group="administratoren" rights="read, accept, delegate, skip"/>
4: <Grant group="composer-role" rights="read, accept, delegate, skip"/>
5: </Rights>
6:
7: <Assignment>
8: <Writes variable="subject"/>
9: <Writes variable="comment"/>
10: <Writes variable="changeSet" contentEditable="true"/>
11: <Writes variable="comments"/>
12: <Reads variable="publicationResultCodes"/>
13: </Assignment>
14: </UserTask>
Example 4.12. User Task Compose
This task is called when the publication fails so that one might fix problems. The purpose of the task is to enable the user to collect the documents which should be published at once.
Line 1: The user task is named 'Compose'. The
localized description is looked up in a resource bundle under the key
"simple-publication-compose-taskLabel" (the tooltip key is
"simple-publication-compose-taskToolTip") and shown in the workflow window.
The task CheckEmptyChangeSet is started after task Compose has
completed. |
| Line 2 - 5: The rights concerning the task are assigned to groups. The group administratoren can read, accept, delegate or skip the task. The members of the group composer-role are allowed to read, accept, delegate, or skip the task. Not all the actions associated with a right can be performed in Studio, for some of them you need the Site Manager. |
Line 7 - 13: If the task has been selected, the
variables defined in this section will be shown in the variable view of the workflow
window if the user has the read right. You can change
the content of the variables subject, comment,
changeSet and comments because they are defined in
Writes elements. In addition, you can change the content of the documents,
which are provided by the variable changeSet due to the attribute
contentEditable="true". The variable publicationResultCodes
defined in the <Variable> section of the workflow, will be shown if you
press the appropriate button in the variable view (if the task has been selected in the
workflow list). You cannot change the content of the variable because it is defined as
<Reads ...>. |
If Task CheckEmptyChangeset
1: <If name="CheckEmptyChangeSet">
2: <Condition>
3: <IsEmpty variable="changeSet"/>
4: </Condition>
5: <Then successor="Finish"/>
6: <Else successor="Publish"/>
7: </If>
Example 4.13. If Task
The second task in the workflow is the 'CheckEmptyChangeSet' task, an If task. The
aim of the task is to check if the change set is empty. Then, no publication is necessary and
the workflow can be finished.
Line 1 - 7: An If task is defined with the
name 'CheckEmptyChangeSet'. An If task is a control flow element, which will be executed
automatically. Thus, no visible description is necessary. |
Line 2 - 4: A condition is defined that checks, whether
the variable changeSet contains elements or not. |
Line 5: If the condition evaluates to "true" (change
set is empty) the workflow should be finished. Thus, the succeeding task is
Finish. |
Line 6: If the condition evaluates to "false" (change
set contains elements) the changes should be published. Thus, the succeeding task is
Publish. |
User Task 'Publish'
1: <UserTask name="Publish"
2: description="studio-simple-publication-publish-task"
3: successor="CheckPublication" autoCompleted="true"
reexecutable="true" autoAccepted="true">
4: <Rights>
5: <Grant group="administratoren" rights="read,accept,retry"/>
6: <Grant group="composer-role" rights="read,accept,retry"/>
7: </Rights>
8:
9: <Assignment>
10: <Reads variable="subject"/>
11: <Reads variable="comment"/>
12: <Reads description="publish-changeSet"
variable="changeSet"
13: contentEditable="false"/>
14: <Reads variable="comments"/>
15: </Assignment>
16:
17: <EntryAction class="ApproveResource" gui="true"
18: resourceVariable="changeSet"
19: successVariable="publicationSuccessful"
20: ignoreErrors="true"
21: timeout="180"
userVariable="PERFORMER_">
22: </EntryAction>
23:
24: <EntryAction class="PublishResources" gui="true"
25: resourceVariable="changeSet"
26: resultVariable="publicationResultResources"
27: versionVariable="publicationResultVersions"
28: codeVariable="publicationResultCodes"
29: parameterVariable="publicationResultParams"
30: successVariable="publicationSuccessful"
ignoreErrors="false"
31: ignorePublicationErrors="true" timeout="600"
userVariable="PERFORMER_"/>
32: </UserTask>
Example 4.14. User Task "Publish"
The third task of the workflow is a user task called 'Publish', that will publish the changes contained in the change set. This task will be automatically accepted by the composer of the change set due to the exit action ForceUser in the 'AssignUser' task.
Line 1 - 3: The user task is named "Publish" and its
successor is the task "CheckPublication". The task will automatically be completed after
execution of the entry actions because of the attribute autoCompleted="true".
This is useful when a set of automated actions should be executed on behalf of a user. |
Line 4 - 7: The rights are granted to the groups
administratoren and composer-role. |
Line 9 - 15: Like mentioned before, variables are
defined which should be shown in the variable view of the workflow window. Nevertheless,
automatically completed tasks will only be shown in the case of error in the task list. In
contrast to the declaration of these variables in the Compose task no changes
at all can be applied to the variables (due to Reads) and its content (due to
contentEditable="false"). |
Line 17 - 22: The first action performed in the task is
the predefined
ApproveResource
action which approves the content items given via the attribute resourceVariable. |
Line 24 - 31: After executing the first entry action,
the second one will be performed. Here the content items given via the attribute
resourceVariable will be published by the predefined action
PublishResources.
The other attributes define the variables to store the publication result into, to set
timeouts and to ignore publication errors only. |
If Task "CheckPublication"
1: <If name="CheckPublication">
2: <Condition>
3: <Get variable="publicationSuccessful"/>
4: </Condition>
5: <Then successor="Finish"/>
6: <Else successor="Compose"/>
7: </If>
Example 4.15. If Task "CheckPublication"
The fifth task in the workflow is the 'CheckPublication' task, an If task. The
aim of the task is to check if the publication was successful. If it was, the workflow will be
finished, otherwise the compose task will be started again.
Line 1 + 7: The If task is named
'CheckPublication'. An If task is a control flow element which will be executed
automatically. |
Line 2 - 4: A condition is defined which will be evaluated. The value of the Boolean
variable publicationSuccessful, which has been set in the
Publish task will be read using the Get element. |
Line 5: If the condition evaluates to "true"
(publicationSuccessful="true") the workflow should be finished. Thus, the
succeeding task is "Finish" task. |
Line 6: If the condition evaluates to "false"
(publicationSuccessful="false") the Compose task should be
offered again. |
Automated Task 'Finish'
1: <AutomatedTask name="Finish" final="true">
2: <Action class="AssignVariable"
resultVariable="changeSetLockedInStudio">
3: <Boolean value="false"/>
4: </Action>
5: </AutomatedTask>
Example 4.16. Example of automated task Finish
The last task of the workflow is an automated task and defines actions that are executed before the
workflow completes. The task would also be needed if no such actions were necessary because the previous
If task may not be the final task of the workflow.
Line 1: The automated task is named 'Finish'. Because
the task should be the last one in the workflow, it must be marked as final. If the
control flow of the workflow reaches a task with the attribute final="true",
it quits the execution of the workflow after the task was successfully executed.
|
| Line 2 - 4: The lock on the change set in Studio is removed. |
Final Action 'ArchiveProcessFinalAction'
1: <FinalAction class="ArchiveProcessFinalAction"
maxProcessesPerUser="100"/>
Example 4.17. Example of ArchiveProcessFinalAction
Final actions are executed at the very end, after a workflow completed successfully or was aborted.
The ArchiveProcessFinalAction archives data of the workflow and moves it from the list of
pending workflows to the list of finished workflows for all users for that the
RegisterPendingProcess action was called before.
