一個過程應該在卡蒙達生活多久

Question

一個過程應該在Camunda BPMN工作流程中存在多長時間？

我有一個可以在產品的整個生命周期中運行多次的過程。 我需要跟蹤和更新此工作流程為產品處理的數據點。

一個建議是編寫一個循環BPMN，它監聽一個事件以啟動進程，並以接收任務結束，然后再偵聽該事件。

但是，這會導致進程從未真正結束，因為它們總是循環回來，但是我們無法保證可以觸發此事件的時間或次數。

我還考慮過創建一個只運行一次並終止的BPMN。 這解決了長壽命過程的問題，但是我放棄了所包含的所有過程變量。

編輯：

這是我們正在研究的循環機制的簡化圖。 我不想在第一次之后重新檢查資格，但我想在任何時候更改時驗證並保存地址。

簡化的地址圖

Answer 1

老實說，BPMN文件（也就是流程定義）應該是決定它“活着”多久的文件。 就像你有一個流程需要你的用戶聯系客戶並等待他的回答一樣，一個過程可以很容易地說“1個月”是在發送提醒之前等待的時間（或以任何其他方式對計時器的到期做出反應） ）。

但我們還必須區分“真實生命過程的生存時間/生命周期”，通過BPMN文件VS“你的Camunda引擎中的生存時間/生命周期（缺乏更好的術語）”進行區分。

Camunda中每個進程實例都有一個唯一的標識符。 您不必讓“進程的內存實例”一直存在直到它完成...您可以在每次將事件發送到流程實例的唯一ID時對其進行實例化，以處理事件/命令並停止一旦事件/命令被處理，實例（不是進程的生命周期）。

我唯一一次與Camunda合作，這就是我們所做的。 基本上，我們向Camunda API發送了BPMN文件的名稱，我們之前啟動的流程實例的ID以及處理將影響流程的事件/命令的所有相關信息（包括流程變量）。

這樣，當Camunda API成功處理事件/命令時，您可以將所有流程變量存儲到處理后的“返回消息”中，並且您永遠不會真正丟失流程變量，因為您始終會“重新加載”它們流程的最新“狀態”（也就是您上次將事件發送到特定流程實例時獲得的響應）。

希望，我很清楚？