Hi all,
I am struggling with the pattern described at GitHub - NPDeehan/idempotent-process-example: How to build a Camunda process that will only start one instance per request. Using threads requesting the REST API in parallel, lots of processes are created with the same business key before message correlation to the event subprocess takes place. Wich, as expected, fails with a MessageCorrelationException. Is there a solution that guarantees unique creation of processes?
Regards,
Steve
Hi @sdw,
to get the desired result you have ensure to commit the start as soon as possible in the database.
In case you start your process with service tasks, mark the first as Asynchronous Before, or alternativly the Start event with Asynchronous After.
And even now it could happen that you start multiple processes, depending on the parallelization of requests in the webserver. If you fire a lot of requests in one after the other, you have to limit the resources that the next request is handled only if the first is answered. Then the non-interrupting message event of the event subprocess can handle the duplicate request.
Hope this helps, Ingo
Hi Ingo,
given your preconditions, the pattern is misleading.
I can’t limit the resources on webserver side, the problem itself arises in environments where surrounding services are scaled up on high load, process engines included. I also cannot defer the solution to the client, as the response of the request is not guaranteed to be fully processed after (commited) creation of process took place at the engine. I think the only point where idempotency can be properly secured is the database level. As said in the description of the example, it seems to be a mess. I am thinking about passing process creation to the job excecutor, i.e., using a process with only an (asynchronous before) final state throwing a signal that triggers creation. Due to the sequential design of job execution, might this be a feasible approach?
Regards,
Steve