Here, I am starting the workflow instance through a webhook call. If I can pass a correlation id, I can send the call again and re-run the same workflow instance.
It might not be possible with the out out-of-box connector.
I know that with the Message Start element, there’s a way to configure it to accept a correlation ID which will only allow one instance of the process to run at a time (if there’s a process with that correlation, it will try to relate it to the existing process), but I still don’t think that’s what you want to do. If I’m understanding correctly, you want to make your process idempotent. To do that, I think you would need to both customize the webhook connector (to include the Correlation ID) as well as check at the beginning of the run of the process to see if that correlation has already completed.
@GotnOGuts
Thanks for the reply. Let me explain my requirement.
What we want is,
Trigger a workflow
Get an acknowledgment if it is finished.
Find the unfinished workflows
Re-trigger the same workflow instances that were failed/unfinished. We don’t want to start a new one because it will be costly to run the same tasks again. We though that there would be a way to re-trigger the same workflow instance that was failed.
One of the middle tasks can fail and we can add retries. But still it can fail. So we want to re-trigger the same instance again. Otherwise, we can implement the workflow in our side and trigger a new workflow whenever there is a failure. But it will be costly to run the same tasks again. That’s why Camunda comes in handy with saving the states/env at the fail time. We thought we can achieve it with camunda.
That’s what we want right now. If you could give some insight, it would be really beneficial for us to go with Camunda as a solution to our requirement.
You won’t trip the same instance again, because that instance has fully completed with errors.
You will trip a new instance with the same parameters.
Every call to an API (either within Camunda or to another system) is an instance of its own.
But I can see that in the “Operator”, we can re-trigger the incident (failed task) and the instance will continue until it is finished. I want to do it from outside without doing it manually.
First of all, when I trigger a workflow process instance, I need a instance id in my side to recognize what this workflow instance is. Next, I want to trigger it if a task fails (in the workflow instance) from outside (e.g.: some API call) using some ID or another way.
Since this is possible manually via Operator, why isn’t there a way to do it via an API call?
In Operate, you are manually recovering from an Incident. If you have an incident on your process, then your process has not yet completed, and you do not want to start your process over. You want to look into the steps to Resolve Incident
I understand that in 8.6 this will be available via a REST interface.
As was mentioned in your other thread, the best practice is not to fail the overall process, but to determine how the errors could occur, and then plan and model those into your process. If you were doing this whole process by hand with Postman, what would you do?
(Please note that it’s generally not a good idea to start multiple threads on the same topic, since you will break the conversation, and get conflicting information in different threads, since no one has the whole picture of what you’re describing and trying to solve)