當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Flowable V5.x迁移至Flowable V6时需要注意的事项

發布時間：2025/3/21 编程问答 20 豆豆

生活随笔收集整理的這篇文章主要介紹了 Flowable V5.x迁移至Flowable V6时需要注意的事项小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

1. 介紹 Introduction

本手冊介紹了從Flowable V5.x遷移至Flowable V6時需要注意的事項。

2. 設計目標 Design goals

V6版本的設計目標是：

完全向前兼容V5版本：數據庫層面、概念層面以及代碼層面。
重寫核心引擎：直接執行BPMN 2.0（不再轉換為中間模型）。
更簡潔干凈的運行時執行數據結構，重點關注結構的可預判性。
解耦持久層，以支持未來的不同實現。

3. 數據庫遷移 Database migration

從V5至V6不需要數據庫遷移：V5與V6的數據庫表結構一致，只是多了一些表與列。所有Flowable V5生成的數據都可以保留在數據庫中，甚至包括活動的、執行中的流程實例。在V6引擎第一次運行時，會對表結構進行自動升級（同V5版本中一樣）。除了一些小的數據庫結構改動外，主要的改動是將作業表分拆為作業表、定時器作業表、暫停作業表與死信作業表。還未到期的定時器作業將移至新的定時器作業表；用盡重試次數的作業將移至死信作業表；已暫停流程實例的作業將移至暫停作業表。

4. 概念變化 Conceptual changes

稱為Flowable V6的主要原因是完全重寫了核心引擎。核心引擎執行的方式已經完全變化，將直接執行BPMN（在V5中使用中間模型）。同時，運行時執行的表現形式（執行樹）也作了修改。總的來說，這些概念都大幅簡化了，讓執行更簡單清晰，也讓撰寫自定義代碼更容易更易懂。在V6中內嵌了一個V5引擎，在需要時可以保證完全的兼容性。

我們將在之后的文章中詳細介紹引擎內部的工作。

5. 破壞性改動 Breaking changes

下列改動是破壞性改動（也就是說很可能導致編譯錯誤）。

5.1. 包重命名：org.activiti重命名為org.flowable

所有org.activiti包都已重命名為org.flowable。

5.2. Activiti類重命名

所有類名中包含的"Activiti"都已重命名，替換為Flowable。例如，ActivitiEvent重命名為FlowableEvent，而ActivitiException重命名為FlowableException。

5.3. activiti.cfg.xml重命名為flowable.cfg.xml

在Flowable引擎啟動時讀取的默認配置文件，已經從activiti.cfg.xml重命名為flowable.cfg.xml。對于默認的Spring配置文件activiti-context.xml也是一樣，已經重命名為flowable-context.xml.

5.4. PVM類 PVM classes

以前在org.activiti.engine.impl.pvm包（及其子包）下的所有類都已移除。這是因為PVM?(流程虛擬機 Process Virtual Machine)模型已被替換為一個更簡單更輕量的模型。

這意味著ActivitiImpl、ProcessDefinitionImpl、ExecutionImpl及TransitionImpl都將失效。

在V5中這些類大多用于獲取流程定義中包含的信息。在V6中，所有流程定義的信息都可以通過BpmnModel獲取。這是一個BPMN 2.0 XML流程定義的Java表現形式（并對特定操作及搜索進行了增強）。

獲取BpmnModel流程定義最快捷的方法是使用org.flowable.engine.impl.util.ProcessDefinitionUtil類：

// 整個模型 The whole model ProcessDefinitionUtil.getBpmnModel(String processDefinitionId); // 只有流程定義 Only the specific process definition ProcessDefinitionUtil.getProcess(String processDefinitionId);

5.5. DelegateExecution代替ActivityExecution (ActivityExecution is replaced by DelegateExecution)

我們移除了ActivityExecution，并使用DelegateExecution類代替它。

所有ActivityExecution類中的方法都已復制到DelegateExecution類中。

5.6. 移除EngineServices (EngineServices removed)

移除了DelegateExecution中的getEngineServices方法，因為它已經沒有實際作用，并導致在Flowable 6與內嵌的Flowable 5引擎中，DelegateExecution的使用不一致。

將所有對getEngineServices方法的調用，替換為對org.flowable.engine.impl.context.Context.getProcessEngineConfiguration方法的調用。

5.7. 作業、定時器、暫停與死信作業 Job, timer, suspended and dead letter jobs

Flowable V5中只有一個作業表，導致查詢需要執行的作業時，查詢條件異常復雜。

在Flowable V6中，作業被分拆成了作業表(ACT_RU_JOB)、定時器表(ACT_RU_TIMER_JOB)、暫停表(ACT_RU_SUSPENDED_JOB)與死信表(ACT_RU_DEADLETTER_JOB)。

作業表中的作業可以直接執行（類似異步作業與到期的定時器作業）。因此就不需要使用復雜的查詢，唯一的where條件是lock time(鎖定時間)不能為NULL。
定時器作業現在持久化在專門的定時器作業表中，并由一個線程檢查到期需要執行的定時器作業。當定時器作業到期需要執行時，該作業會被移至作業表。
當作業執行器線程準備執行作業時，會從作業表獲取并執行。
當流程定義或流程實例暫停時，其關聯的作業將被移至單獨的暫停作業表。這簡化了作業執行器的查詢，并清楚顯示了暫停中的作業。
如果一個作業執行失敗，它將被放入定時器作業表，并用當前時間+引擎配置的作業失敗等待時間作為到期日期。在該作業到期將被執行時，會重新移至作業表，并被執行。如果重試次數減至0，則該作業將被移至死信表，不再自動執行。這樣簡化了默認的作業執行器查詢，也清楚顯示了卡住需要人工干預的作業。

Flowable V6內嵌的Flowable V5引擎也能夠使用這4個作業表。但是只會有一個線程池從數據庫中獲取作業，這個線程池在兩個引擎間共享。當獲取到一個作業后，會基于流程定義id檢查引擎的版本，以判斷作業由Flowable V6還是嵌入的Flowable V5引擎執行。

5.8. 向一個執行發信號 Signaling an execution

在V5中，使用像是runtimeService.signal(executionI);這樣的方法向一個執行發信號十分令人困惑。因為信號(signal)是一個BPMN 2.0概念和特性，它們的概念互相沖突。

在V6中，signal()方法更名為trigger()。

同時，用于實現可以被外部觸發的行為的接口SignalableActivityBehavior，也會改名為TriggerableActivityBehavior。

5.9. 受控異常 Checked Exceptions

在V5中，JavaDelegate與FlowableBehavior之類的代理類在其簽名中標示拋出Exception。像其他現代框架一樣，在V6版本中已經移除了受控異常的使用。

5.10. 代理類 Delegate classes

org.flowable.engine.impl.pvm.delegate.ActivityBehavior的包變更為org.flowable.engine.impl.delegate。

從DelegateExecution中移除了下列方法：

end()
createdExecution()

它們已經用ExecutionEntityManager的調用代替了，可以通過Context.getCommandContext.getExecutionEntityManager()使用。

5.11. 實體管理器 EntityManagers

在Flowable V5中，所有的實體管理器類（負責持久化，也包含一些邏輯）都沒有接口。在V6中，所有的實體類都已經重命名為Impl后綴，并提供了不帶后綴的接口。也就是說V5的實體管理器類名現在是相應的接口名。

所有的實體管理器接口都擴展了org.flowable.engine.impl.persistence.entity.EntityManager泛型接口。所有的實現類都實現了AbstractEntityManager泛型接口。

同時，為了保證一致性：

UserIdentityManager接口重命名為UserEntityManager
GroupIdentityManager接口重命名為GroupEntityManager

5.12. 持久化對象重命名為實體 PersistentObject renamed to Entity

org.flowable.engine.impl.db.PersistentObject類重命名為Entity，與其他類保持一致（實體管理器類等等）。

所有使用“持久化對象”的相關類也都已經重構為“實體”。

5.13. 身份邏輯與表的分離 Separation of identity logic and tables

在V5中，身份邏輯及表示流程引擎的必要部分。在V6中，這部分邏輯已經重構為獨立的模塊，名為flowable-idm-engine（其中IDM代表“身份管理(identity management)”）。相關的數據庫表由這個引擎管理。為了保證兼容性，在啟動流程引擎時，IDM引擎默認啟用。可以在流程引擎配置中，將disableIdmEngine設置為true，以禁用這個引擎。如果禁用了IDM，就不會創建身份數據庫表（以ACT_ID開頭）。如果已經存在這些表，也可以刪除。

5.14. Camel終端改名為flowable (Camel endpoint renamed to flowable)

在使用Flowable Camel模塊時，請確保使用flowable終端替代activiti終端。下面的Route作為簡單的例子：

public class SimpleCamelCallRoute extends RouteBuilder { @Override public void configure() throws Exception { from("flowable:SimpleCamelCallProcess:simpleCall").to("log:org.flowable.camel.examples.SimpleCamelCall"); } }

6. V5兼容性 V5 compatibility

在遷移至Flowable V6時（基本上就是替換classpath中的JAR包），所有當前的部署與流程定義都將標記為V5版本的工件。在很多地方（完成一個任務，啟動一個新流程實例，指派任務等等）引擎都會檢查相關的流程定義是否標記為V5版本。若是，則將其執行代理至內嵌的微型V5引擎。

也就是說為了簡化遷移，可以選擇逐步替換：首先在V5模式下運行當前的流程定義，直到已經驗證并測試其行為與V6版本相同。

默認情況下，嵌入的V5引擎是禁用的！要啟用它，在引擎配置中添加下列配置：

并且在classpath中添加flowable5-compatibility（手動或通過Maven之類的依賴管理機制）。

如果在特殊的場景下，默認的實現org.flowable.compatibility.DefaultFlowable5CompatibilityHandler不滿足要求，可以創建自定義的實現。可以將引擎配置中的flowable5CompatibilityHandlerFactory參數設置為創建類的全限定類名。這個工廠類需要構造用于處理V5與V6橋接的類實例。

要讓一個V5流程定義使用V6引擎運行，只需要重新部署它即可。新的流程實例將會在V6模式下運行，而之前的流程實例仍然在V5模式下運行。

如果出于某些原因，希望部署的新版流程定義仍然在V5模式下運行，可以使用下列代碼：

repositoryService.createDeployment() .addClasspathResource("xyz") .deploymentProperty(DeploymentProperties.DEPLOY_AS_FLOWABLE5_PROCESS_DEFINITION, Boolean.TRUE) .deploy();

如果使用Flowable Spring模塊，要使用Flowable V5兼容模式需要進行額外配置：

并且在classpath中添加flowable5-spring與flowable5-spring-compatibility?JAR包（手動或通過Maven之類的依賴管理機制）。

轉載請注明：分享牛???Flowable V5.x遷移至Flowable V6時需要注意的事項

總結

以上是生活随笔為你收集整理的Flowable V5.x迁移至Flowable V6时需要注意的事项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： CentOS、Ubuntu、Debian
下一篇：《Flowable基础二 Flowabl