tutorial

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.


<< change the object status  
© 2008-2015 MS Enterprise Solutions | Website Templates by IceTemplates.com
Please Read: Privacy Policy and Terms of Use