Sending a task and waiting for a long-term response based on External Service

Hi,
I am trying to create a flow where an external task generates and creates a “TO-DO” item for a user on a ToDo App (3rd party system), the user then uses the app, fills the information on what was done and submits it. What is expected is that I want to resume the flow once the user submits the todo item and capture what was filled through variables.

I am trying to find the right way to do this with external service tasks, I am running a NodeJS script that generates the task based on external task and the user gets it, I am sure I should not keep the callback open until the user submits the information and still struggling to find out the best way to report back when its done with the information.

What is the best way to do this keeping in mind all of this is happening externally?

@ywadi I’m not sure that an external task is the best fit in your case for the completion of the task. In a traditional sense what you’re talking about sounds more like a classic user task pattern: work gets created, performed by a user, then completed. In your case however, you need to also register the work in some external system. But that’s something that could be done in a TaskListener on the task or even a service task before the user task. When the user completes the action in the external system, there’s a call to your process application that closes the task.

If you don’t like the idea of user tasks, a receive task might be an alternative, with the same functionality, just less focussed on the actual assignment and user interaction lifecycle and more geared towards some external completion trigger.

The reason it doesn’t fit naturally with an external task pattern is that the assumption there is that some worker will collect and complete the work in a single action (that might take quite a bit of time). But as you found yourself, keeping a callback open while waiting for the user to do something is not a great solution.Yes, you could extend the lock continuously, but I don’t think that’s generally meant for waiting for users, more so for an automated worker to provide feedback that the execution of an automated task is running longer than initially expected, but work IS actually still being done.

2 Likes

Thank you, I went with the Receive Task and works perfectly as I also used the correlation and it managed to get the job done.

1 Like

@tiesebarrell I had this idea, just want to bounce it across see if its going to be a bad one.
If I never call task.complete from the external service the lock expires, then the worker will pick it up again and execute the external service again. If I use that by checking “polling” the status every time the function is recalled after the lock expires, how do you see that going wrong ?

Not sure exactly what you’re proposing. You want to let the lock expire but check for that each time the worker is handed an instance to conditionally call the external function?

Let me put it in pseudo-code for the external service.

client.subscribe("externalServiceTopic", function(task, taskservice){
    record = database.FetchRecord(x);
    if record == 'yes' then task.complete()
    else //do nothing 
})

So if the task service looks like above, it queries the database if the value is not yes then nothing happens, the lock expires and then the task in camunda is not completed, if left like that the service is constantly called until the database value is yes.

I do understand that it loads the database querying for those calls, but this can be solved externally. I would want to know the implications for such action on camunda. Would it cause load? Would it stop trying after a certain time ? in other words how stupid is this approach from 0 to 100 :smiley: