close

Filter

loading table of contents...

Workflow Manual / Version 2110

Table Of Contents

4.3 Example of Workflow Definition

Here 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 user task Compose

  • An if task CheckEmptyChangeset

  • A user task Publish

  • An if task CheckPublication

  • An 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.

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.