一个流程应该在Camunda BPMN工作流程中生存多长时间？
我有一个过程可以在产品的整个生命周期中多次运行。我需要跟踪并更新此工作流为产品处理的数据点。
一个建议是编写一个循环的BPMN，该BPMN侦听事件以启动该过程，然后在“接收任务”中返回，以侦听该事件再次触发。
但是，这将导致进程从未真正结束，因为它们总是循环返回，但是我们无法保证何时或多少次可以触发此事件。
我还考虑过创建一次运行并终止的BPMN。这样可以缓解过程寿命长的问题，但是我松开了其中包含的所有过程变量。
编辑：
这是我们正在查看的循环机制的简化图。我不想在第一次后重新检查资格，但是我想在地址每次更改时都进行验证并保存。
答案 0 :(得分：0)
老实说，BPMN文件（也称为流程定义）应该是用来指示其“生存”时间的文件。就像您有一个需要用户与客户联系并等待其答案的过程一样，该过程可以轻松地指出“ 1个月”是在发送提醒（或以其他任何方式对计时器到期做出反应之前）的等待时间）。
但是我们还必须区分通过BPMN文件VS得出的“实际生命过程的生存时间/生命周期”与“ Camunda引擎中生命周期的生存时间/生命周期（缺乏更好的术语）” ）”。
Camunda中每个流程实例都有一个唯一的标识符。您不必让“进程的内存实例”生效，直到它完成为止……您可以在每次将事件发送到流程实例的唯一ID时实例化它，以处理事件/命令并停止事件/命令被处理后，实例（不是进程的生命周期）。
我唯一一次与Camunda合作，那就是我们所做的。基本上，我们将BPMN文件的名称，先前启动的流程实例的ID以及用于处理将影响流程的事件/命令的所有相关信息（包括流程变量）发送给Camunda API。
这样，当Camunda API成功处理事件/命令时，您可以将所有过程变量存储在“返回消息”中，并在处理完之后再也不会丢失任何过程变量，因为您将始终“重新加载”从流程的最新“状态”（也就是您上次将事件发送到特定流程实例的响应）中获取它们。
希望我很清楚吗？
