I am using the Camunda engine via its rest api access.
From my understanding the idea behind receive task is to wait for messages / events, while user tasks are used for waiting for a user to handle those.
In my case all my interactions are being done with http requests to the engine so from a first look i dont see much of a difference between choosing to use a user task or a receive task.
I am thinking about using user task for every case in which waiting is needed since in either case i will need to send http request to complete / trigger the bpmn tasks.
The reason i am posting this is to try to understand better if maybe there is something i didnt take into consideration and maybe using a received task might still be useful for me?
P.S. The external tasks in my bpmn are being handled with the fetchAndLock api in a repeated manner, so i view those tasks as āautomaticā.
Not sure I understand why you are considering user tasks. Receive tasks sound more natural for handling incoming HTTP requests. Also, if your model is going to be used outside of the automation context (e.g. for documentation), then a user task may be misleading if there is not actually a user involved in performing it.
I still did not decide about some of the things but generally speaking i might have a bpm workflow which is going to be related to user input in the following way.
[A simplified example] A user clicks on a cancel button, http request is sent forward and passes by a few micro services, at some point a service sends http request to the camunda engine to change the state of a task ( user task / receive task ) in the bpm flow to ācompletedā and move the bpm flow one step forward.
In such a case the task is based on the user input ( not directly although because it passes a few āstationsā before reaching the task execution ). It seems more fitting to use a user task for this?
After reading your reply I was thinking about the usage of a receive task for a case similar to the following example,
Some inner processing in my micro services is in works and at some point as a result a domain event is being raised which in turn sends http request to the camunda engine to progress a bpm workflow into a different state via a receive task. In such a case a user was not responsible for the action which is related to the task in the bpm.
Thanks for the response. Given your detailed description, I think it is a matter of taste. Technically, the only noticeable difference is that a user task generates a task entity that would be visible in Camundaās or a custom task list, if you use that.
Iām wondering about your mention of external tasks in the original post, though. User and receive tasks are not external tasks, i.e. fetch and lock and its completion methods cannot be used to fetch and trigger those.
I am actually mostly using regular service external tasks in my workflow via the fetch and lock api.
The cases in which i will be needing User or Receive Tasks will be pretty rare but i did get to use the User Task with the complete task api before.