Module Tasks
Addition to normal tasks process may contain module typed tasks to execute automated system tasks without involvement of any user interaction.
Module type tasks are executed by workflow engine and does not appear on user's work lists.
Each of module has a special behavior to fulfill process requirements and you can use the following module types in process diagram;
Automation Module¶
Automation module typed tasks are used to execute scripts on process. Script may contain vary operations like updating database or data model.
In most cases automation script should take action by assign value to $WorkItem.SelectedAction property after is work is done.
In addition to common properties you can also configure the following properties for an automation task;
Script Content of automation script.
Example automation script
$Xml.SetValue('CustomerCount', $Xml.EvaluateNumber('CustomerCount') + 1);
if ( $Xml.EvaluateNumber('CustomerCount') < 10 ) {
$WorkItem.SelectedAction = 'Continue';
} else {
$WorkItem.SelectedAction = 'Completed';
}
Start Point¶
Automation module type tasks can be set as start point to initiate workflow instances as automated way.
You can initiate from module tasks with any of following scenarios;
Evaluation You can configure the evaluation schedule to periodically initiate workflow instances and take action. If module script does not take action, workflow instance is reverted.
Scripting Initiate You may call the WorkItem.Initiate method to initiate from other processes.
Join State¶
If module is not set as start point and no action taken in script then workflow switches to join state to pause workflow instance at automation task and waits for indefinitely.
Workflow instance may continue with any of following scenarios;
Deadline If you assigned a deadline on task, workflow instance waits until deadline date occur and takes deadline action automatically to continue.
Evaluation You can configure the evaluation schedule to periodically check condition to continue or not.
Process Work Item You may call the WorkItem.ProcessWorkItem method on other workflow instances to force module to continue.
Event Listener Module¶
Event listener module are used to wait for specific events or initiate new workflow instances when event is occurs. Events are triggered on domain scope and may receive events from other processes.
In addition to common properties you can also configure the following properties for an automation task;
Event Name Name of event. Event name can set to a plain text value (Ex: Customer.New) or may contain data template expressions to include data from data model. (Ex: "PaymentComplete.{{Id}}" )
You may also specify multiple event names with semicolon delimited format. (Ex: "Customer.New;Customer.Update.{{Id}}" )
Handle Script Script to handle event and take action to continue workflow instance. If not set worfklow engine automatically selects the first action.
Attached event data can be accessed with $Input variable as XmlNode instance.
If task configured as start point a new workflow instance is initiated and event data copied to current workflow data model for name matching nodes. If handling script does not take any action workflow instance is reverted.
If task is not set as start point, workflow instance paused and waits until event is occurs. If handling script does not take any action then workflow instance continues to wait until next event occur.
Remarks¶
Events are processed in synchronous behavior and if any exception occurs transaction is rollbacked.
Event Module¶
Event module is used to trigger an event to notify other listener type tasks about some specific event is occurs. Events are triggered on domain scope and may execute listeners in other processes.
In addition to common properties you can also configure the following properties for an automation task;
Event Name Name of event. Event name can set to a plain text value (Ex: Customer.New) or may contain data template expressions to include data from data model. (Ex: "PaymentComplete.{{Id}}" )
You may also specify multiple event names with semicolon delimited format. (Ex: "Customer.New;Customer.Update.{{Id}}" )
Event Data XPath XPath of event data to be passed to listeners. If set to empty value root element content is used. You can use $Input xml node variable to access related event data.
Handle Script Script to handle event result and take action to continue workflow instance.
If no script defined first action is automatically selected.
Event results are stored in $Handlers named array of work item id numbers. If no listener exists array is empty.
Remarks¶
Events are processed in synchronous behavior and if any exception occurs transaction is rollbacked.
Web Service Producer Module¶
Web Service Producer Module type tasks are used to expose task as web service endpoint to integrate with other external applications.
Web service definition (WSDL) is depend on data model and can accessed from process toolbar from web interface or in following URL format;
http(s)://<domain>.workrunner.io/services/process/<process id>
Example URL:
http://mycompany.workrunner.io/services/process/1e95d0bb-80ab-467a-8421-83e73b339ed2
Workrunner uses Microsoft WCF infrastructure to host web services and compatible with industry standards.
Authentication¶
Service methods requires user and password information to impersonate as user. Authentication also requires client certificate authentication that uses self signed certificate for domain.
If service accessed from SSL connection basic authentication can be used. For more details please refer to https://msdn.microsoft.com/en-us/library/ms733775(v=vs.110).aspx
If no ssl used clear text authentication is supported but standard WCF implementation does not support this feature and requires additional custom binding to access web service. Example implementation can be found at http://webservices20.blogspot.com.tr/2008/11/introducing-wcf-clearusernamebinding.html
Sub Workflow¶
Sub workflow type tasks are useful for starting a new instance from the same process. Main and the sub workflows use the same XML. When this option is selected on the module page, a form comes to hand, consisting of the options below.
Pool¶
Select a pool to trigger a task (sub workflow) from.
Task¶
When pool is selected, its tasks are listed in this dropdown. Select one to trigger.
Mode¶
There are 3 options listed in the dropdown;
Create child instances and continue With this option, after the sub workflows are created, the main workflow continues to the next task(s).
Synchronize child instances and continue If you choose this option, the sub workflows created can be synchronized by the main workflow. With this synchronization, whenever the main workflow's parent task is visited again, all related sub workflows can be updated according to the XML. For example assume that you created 2 sub workflows and then deleted one of them from the XML. When main workflow returns to that creator task, the sub workflow related with the one that was deleted from the XML will be terminated.
Wait for all childs to complete All of the sub workflows must be completed in order for the main workflow to continue to next task(s). Until all its children is completed, main task waits on Join state.
XPath¶
Use this text box to specify the node name to be regarded to create the sub workflows with.
Condition¶
You can indicate a condition to specialize the node selected on the previous option.
Row Id XPath¶
If you are going to use the synchronize mode, write the name of your Id node which is located under your XPath, in order it to be checked to update the sub workflows properly.
Sync Data XPath¶
If you wrote down a row id xpath above but yet it is not enough to indicate the updated sub workflow's data on the XML, specify another node for synchronization. For example if one of your sub workflows has a AssignedTo node in its XML which holds the assignee information, changing this assignee information to someone else might have an effect on the related subworkflow, like to reassign the task to the new person.