assigning tasks to resource

After it has been determined what has to be done, it has to be determined who will do it. Phpgroupware already has a system to manage users and groups, so that saves a lot of work. Phpgroupware also has a practical ACL system. There is however a big difference between the questions "Who is authorized" and "Who will do the task". The answer to the first question will be the same for a longer period of time. The answer to the second question can be different for each case. For example it could be practical that as many task as possible of one given case are handled by the same resource. Or maybe there has to be a separation of duties. So the assignment of tasks to resources is a much more dynamic concept.
It appears that there are more than twenty ways to assign tasks to users. At this stage, I think it is usefull to support the following ways of assigning tasks:

1. by specifying a user or group


2. relative, by specifying a step, and the relation to that step (same resource, different resource, ...)


3. dynamic, by specifying a field in the "table with case data"


4. custom, by specifying a function

Types of splits and joins

Technically, there are not that many different ways to perform a split:

• no split: there is only one step that follows the completed step


• and split: there are several steps immediately following the completed step, and each of them has to be created


• (x)or split: based on the data of the case one or more of the following steps have to be created

From a business point of view there are many reasons to perform a split. You could not group them in less then 10 different groups.

To be practical however, I suggest to have to following types of splits:

1. no split


2. and split


3. redo split


4. (x)or split as a result of direct user input (e.g. an invitation can be accepted or rejected)


5. (x)or split based on conditions (e.g. if value of field amount is greater than 100000)

In processes it often happens that something has to be approved or accepted. If not, one ore more steps have to be redone. For instance if a meeting request is sent, and someone asks for a different date or time, because he forgot to fill in his agenda. This is so common that a special join type is made for it. Another reason for this special type of join is that it leads to an infinite loop. The fourth type of split could be realised by putting a selection box directly into the worklist. (The user interface can be simpler for single select than for multiple select.) In fifth case a condition table could be filled in, in the process definition. In this stage however, that would be consume too much time. Instead, a specific function must be written in php, and the name of this function is filled in, in the process definition.

Conclusion: for each split, the process designer can choose between the following options:

• and split


• redo split


• user single select


• user multiple select


• specific function

table with case data

In the discription of the table, a field "table with case data" is included. This field was created to link the workflow to existing apps.
For example the notes app is used for a certain step. The form to be loaded to perform the task would then be notes.uinotes.edit, but for this form, the number of the note to be edited must be passed as an http variable. So where can we find the number of the note?
To be able to find the number of the note, the case has to be linked to the note. So a link between the case number and note number must be created. For example, the case number could be added as a new field to the notes table. In that case the "table with case data" is the notes table. Of course a new table could be created containing two field: case number and note number.

In the steps-table, a field is included called "link". In the above example the link would be the field name of the note number. The SQL statement to determine the record number to be passed to the form can than be:
SELECT {link} FROM {case_data} WHERE case_num={case_num}
for example for the notes app:
SELECT note_id FROM phpgw_notes WHERE case_num=20

So to use the notes app for a step in the process, only these modifications have to be done to the notes app:

• add case_num to the notes table (or make separate table to link case_num and note_id)


• get case_num and task_num from http variables


• call the 'task_complete' function after the note has been edited

main tables

process
contains description of the process, owner of the process, the user/group that can create instances, the form to be loaded when a new instance is created

steps
contains all steps of all processes
fields include: process to which the step belongs, description, form to be loaded to perform the task, form to be loaded to validate the task

step after
contains the link between the steps
fields include: step, after step, join/split type

step performed by
contains data needed to determine who will perform the task
field include: step, user/group, relative: relation, relative: to step

case
here the intances of the processes are stored
fields include: process, case description

task
contains instances of the steps
fields include: the case to which the task belong, the step of the process that is being performed, the user/group that the task is assigned to

Splits and joins

The interesting thing about workflow is the ability to perform tasks in parallel. It is an essential feature, but it is a bit complex.

Splits are not very difficult. Once a task is completed, the following steps are looked up in the process definition. If there is more than one step that immediately follows the completed step, it is determined which of the steps will be activated.

For joins it is somewhat more complicated. The joins are also defined in the process definition, but in order to determine if the conditions of the join are satisfied, other active steps that can lead to the join have to be found.

In the following picture, a case is given. The circles are the steps of the proces. The filled circles are active tasks for the case.



For example: step 11 is completed. The next step is 14. We can see that there is another step that comes before step 14: step 12. So we have to find out if there is still an active task that can lead to step 12. This is not so difficult. We go back from step 12 until we find a split and take note of all the active tasks we find.
If we would do the same exercise starting from step 15 we would encounter the join in step 14 before we find the split in step 4. In that case, we cannot stop in step 4, but we have to back to step 2.
In other words we have to go back until we find a split, but for each join we encounter, we have to go back one split further.
For this reason, every split must correspond with a join and vice versa. For example you cannot eliminate the join in step 13, and join step 9, 10 and 14 in step 15.
This is not a very fast way of working at run-time. Therefore, this algorithm is only used at design time, for checking the soundness of the process definition. At run time, a much simpler approach is taken. When a split is encountered, it is determined which of the possible steps will be activated. So at that time, it is known how many steps will eventually lead to the join. For example: if the split in step 2 is an AND split, tasks 3 and 4 will be activated. So the join in step 15 should wait for the two preceding steps to complete.

Work list

One of the most visible feature of a workflow system is the worklist. This looks like a todo list, but the underlying logic is a bit more complicated. In my test, the worklist looks like:



create new is used to create new instances of processes
case 1 is the description of the case; a case is a specific instance of a process
task 1 is the description of the task to be done for case 1
accept: if the task is assigned to more one resource, a resource can volunteer for the task by clicking accept
open: this opens the form associated with the task
complete: marks the task as complete and generates the following task

An interesting thing here is the "open" link. In the test, it works like this:

• the form (menuaction) to be opened is looked up in the database


• the record number is looked up, and added to http variables


• the browser is pointed to the form (index.php?menuaction=app.class.function¶meter=recordnumber)


• when the form is submitted, the specific app can choose


• validate the data submitted & mark the task as complete


• provide a separate validation function that will be called when the user clicks "complete"


• the browser is pointed back to the work list

This way, existing apps can be adjusted easily.