How long should a process live in Camunda

Question

How long should a process live in a Camunda BPMN workflow?

I have a process that can run multiple times throughout the life of a product. I need to keep track of and update data points that this workflow handles for the product.

One proposal was to write a looping BPMN that listens for an event to start the process, and ends with it back on the Receive Task listening for the event to fire again.

However, this would result in processes that never actually end because they always loop back, but we have no guarantees about when or how many times this event could be fired.

I have also considered creating BPMN that just does one run and terminates. This relieves the problem of a long living process, but I loose all of the process variables that are included.

EDIT:

Here is a simplified diagram of the looping mechanism we're looking at. I don't want to re-check eligibility after the first time, but I want to verify and save the address any time it changes.

Simplified Address Diagram

Answer 1

Honestly, the BPMN file (aka the process definition) should be the one to dictate how long it "lives". Like if you have a process that necessitates your user to contact a customer and wait for his answer, a process could easily state that "1 month" is the time to wait before sending a reminder (or reacting in any other way to the timer's expiration).

But we also have to differentiate between "time to live / life cycle of the real life process" conceputalized through the BPMN file VS "time to live / life cycle of the process in your Camunda engine (for lack of a better term)".

Each instance of a process in Camunda has an unique identifier. You do not have to let the "memory instance of the process" live until it is completed ... you could instead instanciate it everytime an event is sent to the unique ID of a process instance to treat the event/command being and stop the instance (not the lifecycle of the process) once the event/command has been treated.

The only time I worked with Camunda, thats is what we did. Basically, we'd sent to Camunda API the name of the BPMN file, the ID of the process instance we had previously started and all the pertinent informations to treat the event/command that will affect the process (include process variables).

This way, when an event/command is successfully treated by Camunda API, you could store all the process variables into the "return message" after it has been processed and you would never really lose process variables since you would always "reload" them from the latest "state" of the process (aka the response you got last time you sent an event to a specific process instance).

Hopefully, I'm being clear ?