-
Notifications
You must be signed in to change notification settings - Fork 4
workflow oe task integeration
-
Workflow creator will first create a TaskForm in UI Designer. A User will able to create a form by :
-
Defining a set of key-value pairs, to be picked from Task Instance - For Task Assignee
In a leave application flow, to approve/reject a leave request, Approver needs to see Leave from-date, to-date, reason, kind of leave (sick/paid/compenstaion), etc.
-
Defining a set of inputs to be provided - By Task Assignee
In a leave application flow, Approver will need to update leave status to approved/rejected along with comments.
-
Now Workflow creator will go to Workflow Modeler to design the Workflow. While designing Workflow he might come across a User Task (Approval Task), so here he will need to define fields like candidate Users, candidate Roles, etc. Now along with this he will be selecting a TaskForm (fetch all TaskForms through a TaskForm model and make it visible as a drop down).
> Task Form instance should also provide meaningful input/output attribute ids - so as to correlate data between task form and workflow
Otherwise user might have to go back and forth to TaskForm while designing workflow, and the same "name" and "id" restriction will be there
At the time of defining TaskForm in User Task User should be able to view the fields he can make visible for a task & which fields will come as input.
- Workflow creator publishes the flow and his part ends.
- Optionally, Workflow creator may or may not attach the Workflow to a Model based on the understanding of business process and his authorization.
- A User may create/update/delete a Model instance due to which a Workflow might be triggered. Also, there could be a direct Workflow Instance creation through a different Interface.
> In a leave application flow, User (Leave applier) creates a Leave Instance which triggers a workflow for Leave Approval.
> User waits till the leave is approved or rejected.
- User checks his Task Management Portal and find Tasks.
> This user will be an **Approver** in a Leave Aprroval Flow. One of the tasks will be a Leave Approval Request assigned previously through Workflow.
-
User can view the fields based on which he has to take action and provide his inputs in the TaskForm.
Based on leave dates, reason, etc. Approves takes a decision and gives his input for status and comments.
-
On TaskForm completion,
completeTask
endpoint of Task Model will be triggered and Workflow execution will continue.Later, workflow ends and Leave request is either approved or rejected.
This will also lead to task completion, but without interacting with Task Management Portal
While attaching workflow, workflow will open up rest end points /Model/{:id}/task
to fetch the task and /Model/{:id}/completeTask
to complete the Task directly through Model.
This way user won’t need to go to Task Management Portal to interact with the tasks.
Approver will view Leave Model and is able to complete his Task by just using InstanceId of Leave Model.
UserTask of Workflow will need to have a TaskForm Tab where a User needs to define :
- TaskForm Type - Drop-Down List
- TaskForm Name - Drop-Down List
- Optionally, following tables can be displayed with
- Set of variables, to be shown to the User
- Set of inputs to be provided by the User
This way USER won't need to move back & forth for TaskForm properties
For now, the integration is just with EVF UI Designer, therefore TaskForm Type will have just one option Embedded EVF App. Based on above selection, Workflow designer should query TaskForm Model to fetch the TaskForm Instances and show in the TaskForm Name drop-down list and populate above mentioned tables.
Once, Workflow is designed, Workflow Modeler should generate .bpmn
file with these tags -
Field | Description |
---|---|
formType | Type of the Task form, currently only EVF UI enabled TaskForms will be supported |
formKey | Name of the TaskForm attached |
formVariables | Variables to be exposed in the Task Instance for the Task Assignee |
formVariables is an optional field, if form variables are not defined all the Process Variables will be shared in the Task Instance.
<bpmn2:userTask
id="UserTask_1bnl2d6"
name="LeaveApprovalTask"
camunda:candidateUsers="dummyUser"
formType="embedded:app"
formKey="SimpleApprovalForm"
formVariables="fromdate,todate,comments"
>
Generated task instances will now have three more properties :-
Field | Description |
---|---|
formType | Type of the Task form, currently only EVF UI enabled TaskForms will be supported |
formKey | Name of the TaskForm attached |
formVariables | Variables to be exposed in the Task Instance for the Task Assignee |
{
"name": "LeaveApprovalTask",
"status": "pending",
"processTokenId": "a76868fa-11d3-40c4-ad38-7d70fa825d6c",
"candidateUsers": [
"dummyUser"
]
"candidateRoles": [],
"excludedRoles": [],
"candidateGroups": [],
"excludedGroups": [],
"formKey": "SimpleApprovalForm",
"formType": "embedded:app",
"formVariables": {
"fromDate": "11/07/2014",
"toDate": "14/07/2014",
"comments": "Going home for Diwali"
},
"id": "58edca3fc69a1f001fe0ce21",
"processInstanceId": "58edca3fc69a1f001fe0ce1f",
"_type": "Task",
"_createdBy": "default",
"_modifiedBy": "default",
"_createdOn": "2017-04-12T06:33:35.321Z",
"_modifiedOn": "2017-04-12T06:33:35.321Z",
"_version": "13c4a675-9ebe-4acf-8adb-6b20a1b913d9",
"_isDeleted": false
}
formKey
can be used to correlated a Task with a EVF UI TaskForm andformVariables
can be used to populate values on the TaskForm