Workflow structure
Logical structure
A workflow is composed of:
-
steps
-
shares
-
triggers
-
conditions
Each action links a source step to a destination step. The destination stage can be the same as the source.
Each state change causes the execution of a trigger. These changes are:
-
Entering a step
-
Exiting a step
-
Transition
Below is an example of a three-step workflow and three actions.
Physical structure
A workflow type consists of two object types:
-
one to describe the states. His name is the workflow name.
-
one to describe the actions. His name is <workflow_name>action.
Creating the 'standard' workflow will create the objects:
-
standard
-
standardisation
The object describing the reports contains the following basic fields:
-
name (step name)
-
onEnter (source of the onEnter trigger)
-
onLeave (onLeave trigger source)
-
color (color of the current step to display in the backoffice)
-
icon (image representing the step)
The object describing the actions contains the following basic fields:
-
name (name of the action)
-
condition (source of the condition for the execution of this condition)
-
onTransition (source of the onTransition trigger)
-
state_in (child on the start state)
-
state_out (child on arrival state)
Interface description
Conditions and triggers
Workflows can integrate directly from the code to be executed while passing from one step to another or to condition the execution of an action. This makes it possible to concentrate business logic on the workflow level by releasing security and object triggers.
There are two types of code:
-
Conditions
-
Triggers
The conditions
The conditions allow for more freedom than security to authorize the execution of an action. They are executed:
-
on request to test whether it is possible to execute an action. This makes it possible to condition the display of this action in a backoffice.
-
At the very beginning of the execution of an action to avoid its unfolding if the action has been executed by a different mechanism than an interaction with the user. E.g.: Call by PLC.
The triggers
Triggers can be used to execute actions (mail, archiving) and/or to update object fields when changing status. There are three interveners at a specific point in time when the object changes state:
-
onLeave: Intervenes when exiting the initial state
-
onTransition: Intervenes at the time of transition from one state to another
-
onLeave: Intervenes when entering the state of arrival
At first glance, there may seem to be as many triggers for the transition between two states. However, this is very useful for various reasons such as:
-
To be able to factorize or specialize pieces of code. + Indeed, since it is possible to exit or enter a state via different paths (actions), the code that does not depend on the path can be entered on the onEnter or onLeave of a state. On the other hand, to execute code only when executing a particular path, it is preferable to fill in your code onTransition event in order to specialize it.
-
To manage the life cycle of an object.
Indeed, as the diagram below suggests, some triggers such as onLeave and onTransition allow to interrupt the status change of an object while allowing to update these fields and save. A concrete example of such use can be found in this documentation.
Examples
Consensus Validation
In this example, our worflow has two states: draft and published; and an action: validate.
The object is only released when at least three different validators have validated this document. To do this, we will rely on the possibility of modifying the fields of an object without changing state thanks to the return values of onLeave conditions and triggers.
The workflow is thus as follows.
You must start by adding a field to the object you want to validate. The field is called validators and is a multiple child on user. This field will allow you to know which users have already validated the document.
Then, we want to display the action 'validate' to users who have not already validated the document. To do this, we will modify the condition of the action to validate as follows.
import wsnoheto.engine.*;
import java.util.*;
try {
IObjectWritable owner = workflow.getOwner();
//On commence par parser le champ validateurs
String validateurs = owner.getProperty("validateurs");
if( validateurs != null ) {
StringTokenizer tokenizer = new StringTokenizer(validateurs, ", ");
TreeSet<String> v_set = new TreeSet<String>();
while( tokenizer.hasMoreTokens() ) {
v_set.add(tokenizer.nextToken());
}
String surfer_id = surfer.getProperty("id");
//On accepte d'exécuter seulement si l'utilisateur actuel n'a pas déjà validé.
return !v_set.contains(surfer_id);
} else {
//personne n'a validé => On accepte
return true;
}
} catch(Throwable e) {
return false;
}Finally, we want the document to be released if and only if at least three different validators have validated the document. The next onLeave trigger does this.
import wsnoheto.engine.*;
import java.util.*;
try {
IObjectWritable owner = workflow.getOwner();
String validateurs = owner.getProperty("validateurs");
if( validateurs != null ) {
StringTokenizer tokenizer = new StringTokenizer(validateurs, ", ");
TreeSet<String> v_set = new TreeSet<String>();
while( tokenizer.hasMoreTokens() ) {
v_set.add(tokenizer.nextToken());
}
if( v_set.size() >= 3 ) return false;
String surfer_id = surfer.getProperty("id");
if( v_set.contains(surfer_id) ) return false;
v_set.add(surfer_id);
Iterator<String> it = v_set.iterator();
StringBuffer new_validators = new StringBuffer();
while( it.hasNext() ) {
new_validators.append(",");
new_validators.append(it.next().toString());
}
new_validators.append(",");
owner.setProperty("validateurs", new_validators.toString());
return v_set.size() == 3;
} else {
return true;
}
} catch(Throwable e) {
return false;
}Associate objects with a workflow type
There are two ways of assigning an object to a workflow type, that is, this object is managed by this workflow.
The first is to change the structure of the object to be assigned. So we have to:
-
Change object structure
-
Change the status field of this object
-
Change its nature to point to the right workflow
The second method is accessible from the workflow screen.
-
Select the workflow to which you want to assign an object.
-
Select the Assignments tab.
-
In the selection box, on the right: find the object to assign.
-
Click the Assign button.
Change the attributes of reading/writing properties of an object according to its state in the workflow
By default, it is possible to specify whether a field appears during the editing or visualization of an object in order to dynamically generate input forms and consultation screens. These read/write attributes can be modified from the structure modification backoffice.
The new workflow brings more finesse by allowing you to specify these attributes according to the status of the object in the workflow. For example, it will be possible to authorize the modification/consultation of the text field of an article when it is in draft form, but to authorize only the consultation when it is published.
To modify, the attributes of visualization/modification of a report by report field, go to the Workflow Administration screen:
-
select the workflow to which the object to be set is assigned
-
Select the assignments tab
-
find your item in the list on the left
-
check the rights to assign field by field and step by step
-
click Save these assignments
Below is the kinematics in image.
Note that by default, the visualization/editing attributes of a field are the same for all steps of the workflow and correspond to the Configuration of the object.