Part 3- Adding functionality to return data from a user task
This series describes the implementation of a User Interface driven by an Elsa workflow engine.
In Part 2- Creating the user task activity, a lot of coding was done. The next step is to extend the code to accommodate the possibility of returning user data into the workflow.
This time let’s follow the steps taken in the application to see how the elements work together to resuming the workflow, starting by the UI.
Although this is a Blazor implementation, the routing and steps still apply to other frameworks.
- Get the workflow instances waiting on the Usertask activity
- Render appropriate UI for the Usertask
- Send update signals and data to the engine
On initializing the component, the UsertaskService loads the user tasks. In this case, the implementation of the service is to give back the workflow instances. An alternative approach would be to get a list of user tasks, even when the workflow instances are the same.
In hindsight, this would be a better approach because the client can control how to display the user tasks. ;-)
The controller returns the UsertaskViewmodels and the UI can display them. On each displayed item, an open(usertask) event handler is added. On this even the UI will activate the appropriate UI control.
The Ui control opened bij the UI is capable of interacting with the engine. It will use the UsertaskService to send the signal to the engine. Then, it uses a JsonConvert to convert the data entered in the component to a JSON Object and send this as the data result in the request.
It was mentioned before that the data object needs to be wrapped in an envelope so it can add some metadata for the signal.
Now the engine can use the metadata to determine which workflow instance needs to be resumed, and more specifically which activity based upon the signal.
So, when designing processes and the signals, be conscious about the signaling. Avoid same names that it can accidentally activate multiple tasks simply because they use the same signal name.
In the envelope, there is no indication for the activity id, which means the engine will activate everything in the workflow instance that has that signal name and is suspended.
In the controller the implementation is fairly simple
The data and the signal are received. Next, the invoker can execute a workflow based on the Usertask signal. This invoker (IUserTaskSignalInvoker) is part of the bookmark implementation. It will collect the workflows waiting for a specific bookmark type and the signal. Then, it will activate the OnResume method on that associated activity withing the workflowinstance.
In the case of the user task there is not much to do. It just sets the input and output to the received data. And, after that it will indicate done as the result of the Usertask.
And that is how the data is handled in the user task!
Next: Part 4 -Let the Usertask determine the UI layout
Used version: Elsa 2.10.467
