check and execute
workflow pending activities [since 2.0]
Authorized user can create a workflow
instance called process: when a workflow is launched, the
workflow instance (the process) and all the constituent activity
instances are automatically created. Based on the rules defined
in the process definition, the workflow system routes the step to
the next step performer(s), until the workflow is completed.
A process can be generated from a workflow definition when a object
event
occours or alternatively in a programmatically way by executing
a OOQL command
(or with a API method of Process class).
process start <Workflow_Name>
[ startdate
<DateTime> ]
[ holder
AdminName ]
[ primaryobject ObjectIdName ]
{
object ObjectIdName }
[ params
<Param_Name> = <Param_Value> { <Param_Name>
= <Param_Value> } ]
[ logfile
<File_Name> ] ;
In the starting command you can specify:
startdate |
if defined the process will start at the given
date and time otherwise it will start immediately |
holder |
the workflow holder, usually when the workflow
is related to a object event, the workflow holder is also the
object holder. |
primaryobject |
the main object asscoiated to the process; the primary object cannot be changed during the process execution; workflow-triggers raised by events will set automatically the primary object. |
object |
0 or N objects associated with the workflow |
params |
represents the global information to be propagate
along the workflow steps (for example object ids to manipulate
or email addresses or parameters for system activities); you
can specify multiple parameters with related value |
logfile |
is the file (absolute path) where operation results
and step transitions will be logged during the process execution;
when the File_Name is setted with keyword "console"
all logs will be printed on the system output |
Only valid workflows can be executed, so its very important
to check the workflow definition.
Administration users can also startup a new process from the Context
Design tree view: right click on a workflow and select the "Start
Process.." option.
When a process starts, it inherits the workflow global parameters;
additional parameters can be added in the "Parameters"
panel:
A workflow is usually represented by a mix of system
activities and user activities; while the system tasks are executed
automatically when the workflow reaches the related steps, the user
tasks assume the "wait" status and need a user action
to be completed.
The execution of user actions are reserved for the users, the members
of teams or for users associated with assignments specified in the
workflow-step properties. All users that satisfy one of these conditions
will be able to see the waiting task listed into their activity
dashboard.
For example, in the Domain Object Manipulation client
you can see the pending activities for the logged user by selecting
the User/Activities menu-item.
If you select an activity and click on "Complete" button
it is possible to complete your action or make your decision:
Applications where workflows are employed should implement a custom
dashboard by listing the user activities with the following framework
OOQL command
:
famework activity list [get Process_GetStepBasicOption]
;
As usual, you can specify the information to extract
for each process-step in the optional "get" clause, in
paticular, the command href-link to the web or desktop client page
by which the user can perform the related actions.
After completed the manual activities, a trigger or any other program
should notify to the system to update the step status. This action
can be performed by OOQL
command
or with a API method of Process class:
process update <Process_ID> step <Step_Name>
[status
( completed | error | skipped | expired ) ]
[percentage
<Value>]
[holder
<User Name>]
[startdate
<DateTime>]
[expiredate
<DateTime>]
[params
<Param_Name> = <Param_Value> { <Param_Name>
= <Param_Value> }]
[object
( add | remove ) <Object ID/CNR> { ( add | remove
) <Object ID/CNR>}]
[execute
( add | remove ) <Actor>{ ( add | remove )
<Actor>}]
[to
( add | remove ) <Actor>{ ( add | remove ) <Actor>}]
[cc
( add | remove ) <Actor>{ ( add | remove ) <Actor>}]
[bcc
( add | remove ) <Actor>{ ( add | remove ) <Actor>}];
status |
force the step status to the completed
, error , skipped or expired condition. |
percentage |
set the step completion percentage [0-100]
this value is automatically set to 100% when the status change
to completed |
holder |
the process step holder |
startdate |
update the start date |
expiredate |
update the expire date ( normally set as startdate
+ step duration when specified ) |
params |
represents the information to be propagate along
the next workflow steps; you can update values for already defined
parameters or add new parameters. |
execute |
add/remove an execution actor( user/team/assignment
<Name>) for action/decision steps |
to/cc/bcc |
add/remove a recipient ( user/team/assignment
<Name>) for notification steps |
You can get the processes where the object is a primary object (A) and where the object is only involved during the execution (B):
Examples:
(A) ooql: object show #00001-5779CCD9 get process ;
SDK: Vector vProcess = object.getProcesses();
(B) ooql: object show #00001-5779CCD9 get otherprocess ;
SDK: Vector vOtherProcess = object.getOtherProcesses();
If an object is destroyed, all processes where it is the primary object will be terminated.
|