Hello,
we are considering the use of the Camunda process engine in an application where one user needs to interact with many tasks in sequence (i.e. most of the tasks represent simple questions that are answered by “yes” or “no”). Each user interacts with one process instance in the engine through a web interface. My first choice would be to use the ReST interface of the engine for the implementation.
From the modeling perspective, each of the tasks should be a user task. I am now looking at how to implement the system, and it seems that user tasks would require quite an involved flow on the client:
- Start the process instance (POST /process-definition/{id}/start)
- Periodically check the engine for new candidate tasks (GET /task)
- If no task was found, wait a while before re-checking
- Claim the task (POST /task/{id}/claim)
- Retrieve process instance variables to populate form template (GET /process-instance/{id}/variables)
- Interact with the user to gather form input
- Complete the task (POST /task/{id}/complete)
- Check whether the process has finished execution (GET /history/process-instance/{id})
- Repeat checking for new tasks if process is still running
The biggest problem with this approach is the requirement to poll the task list - As the user is closely interacting with the process instance, it is desirable to keep the response time short, but I would like to avoid polling the engine too frequently due to the noise that this would create.
The alternative would be to represent the user interactions as external tasks instead. That would allow us to use the POST /external-task/fetchAndLock endpoint which selects a task, locks (claims) it and also returns the variable values of the process, all in one request. In addition, the asyncResponseTimeout parameter removes the requirement to poll in short intervals. Thus, the overall execution scheme would be:
- Start the process instance (POST /process-definition/{id}/start)
- Periodically check the engine for new candidate tasks (POST /external-task/fetchAndLock)
- If no task was found, re-check (asyncWaitTimeout removes the wait requirement)
- Interact with the user to gather form input
- Complete the task (POST /task/{id}/complete)
- Check whether the process has finished execution (GET /history/process-instance/{id})
- Repeat checking for new tasks if process is still running
We can work with the external task scheme and we’d also not be terribly upset if we’d have to preprocess our BPMN models to convert user tasks to external tasks upon deployment if required. It would be nice, however, if we could directly use BPMN as intended and execute it, so maybe I am overlooking another way how this could be implemented?
Any thoughts would be appreciated.
Thanks,
Hans