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