Flowable工作流引擎的科普與實踐
一.引言
當我們在日常工作和業務中需要進行各種審批流程時，可能會面臨一系列技術和業務上的挑戰。手動處理這些審批流程可能會導致開發成本的增加以及業務復雜度的上升。在這種情況下，引入工作流引擎能夠帶來很多好處，讓我們一起來看看：
- 開發成本的挑戰：
在傳統的手動審批系統中，開發人員需要從頭開始設計和實現整個審批流程，包括流程邏輯、狀態跟蹤、任務分配等。這可能需要大量的時間和精力，尤其是在涉及到復雜的業務場景時。
使用工作流引擎，開發人員可以利用其強大的流程建模和執行功能，快速搭建審批系統。工作流引擎提供了圖形化的流程設計工具，讓流程建模變得簡單易懂。這樣，開發人員可以專注于業務邏輯的實現，大大降低了開發成本和周期。
- 業務復雜度的挑戰：
- 在實際的審批流程中，往往涉及到多個步驟、多個角色、多個條件等復雜情況。手動處理這些復雜的業務流程可能會導致流程不一致、流程控制不清晰等問題，增加了業務的復雜度和錯誤的可能性。
- 工作流引擎提供了靈活的條件判斷和分支網關功能，可以輕松處理復雜的審批流程。不同的業務場景可以在流程圖中得到清晰的表達，從而確保流程的邏輯一致性和可控性。同時，Flowable引擎支持動態變量和表單的設置，使得審批系統能夠滿足不同業務場景的靈活需求。
通過引入工作流引擎，我們可以克服手動處理審批流程所帶來的開發成本高和業務復雜度的挑戰。它使得開發人員能夠更專注于業務邏輯的實現，快速構建符合實際需求的審批系統。同時，流程圖的可視化設計和條件判斷的支持，使得業務流程更加清晰、透明，降低了錯誤發生的概率，提高了審批過程的效率和準確性。這將為企業帶來更高的效益和競爭力。
圖片
二.技術選型
目前市面上比較主流的幾個工作流引擎包括Activiti、Flowable、Camunda等，體系較為成熟，使用最為廣泛的是activiti，flowable跟activiti本質上沒什么區別，是由activiti改版而來，但是兩者后續發展路線則不一樣，Activiti后續發展重心是在商業版與云上面，并未對核心功能與性能優化上有過多的跟進優化，而flowable當下重心則是針對功能性、擴展性、性能上進行迭代優化。
圖片
當然，具體選型還是要看業務實際的需要，目前activiti迭代的方向并不是當下我們業務所需要的，我們更重視性能、擴展性這一塊，而flowbale與Camunda之間為什么選擇了flowable呢，則是因為flowable社區較為活躍，遇到并處理問題上更為效率，并且面對多節點審批時，異步任務是提升吞吐率的優質之選。
圖片
下面我將簡單介紹下flowable的一些功能以及模塊。
三.Flowable引擎介紹
3.1 基礎元素
- 流程定義（Process Definition）：
- 流程定義是業務流程的抽象表示，它描述了流程中各個環節的順序和執行邏輯。
在Flowable中，流程定義通常使用BPMN 2.0標準（Business Process Model and Notation）進行建模，可以通過Flowable Modeler進行圖形化設計。
- 流程實例（Process Instance）：
- 流程實例是流程定義的一個具體執行實例。每當一個流程啟動時，就會創建一個新的流程實例，這個實例將遵循流程定義中規定的執行邏輯。
- 每個流程實例都有一個唯一的標識符，用于跟蹤和管理流程的執行狀態。
- 任務（Task）：
- 任務表示流程中的具體工作單元，需要由參與者（用戶或系統）完成。
- 在Flowable中，任務可以是用戶任務（Human Task）、服務任務（Service Task）、腳本任務（Script Task）等類型。
- 網關（Gateway）：
- 網關用于在流程中進行條件分支和合并操作，根據一定的條件來控制流程的走向。
- Flowable提供了多種類型的網關，如排他網關（Exclusive Gateway）、并行網關（Parallel Gateway）等。
- 執行（Execution）：
- 執行代表了流程中的一個具體執行狀態，包括當前的節點、變量值等信息。
- 當流程實例執行時，會產生一系列執行對象，它們共同組成了流程的執行路徑。
- 變量（Variable）：
- 變量用于在流程中傳遞和保存數據，可以在流程的不同節點間進行傳遞和共享。
- Flowable允許在流程實例中動態添加、修改和刪除變量。
- 監聽器（Listener）：
- 監聽器用于在流程的不同生命周期階段監聽事件，例如流程啟動、流程結束、任務分配等事件。
- Flowable支持多種類型的監聽器，開發者可以根據需求自定義監聽邏輯。
圖片
這些是Flowable中的一些基礎元素，它們構成了流程引擎的核心。通過這些元素，我們可以靈活地設計和管理復雜的業務流程，使得流程執行更加高效、透明和可控。
3.2 API說明
在調用開始之前，我們簡單說明一下各個api的作用以及應用場景：
- RepositoryService：
- RepositoryService用于管理流程和流程部署相關的操作。
- 可以通過該Service部署、刪除、查詢流程定義，以及獲取流程定義的資源文件等。
- RuntimeService：
- RuntimeService用于管理流程實例的啟動、掛起、終止等操作。
- 可以通過該Service啟動流程實例，查詢流程實例狀態，設置流程變量等。
- TaskService：
- TaskService用于管理任務的創建、完成、分配等操作。
- 可以通過該Service查詢用戶任務、完成任務，指定任務的辦理人等。
- IdentityService：
- IdentityService用于管理用戶、組和用戶組的操作。
- 可以通過該Service創建、刪除、查詢用戶和組，將用戶加入到用戶組等。
- HistoryService：
- HistoryService用于查詢流程實例和任務的歷史數據。
- 可以通過該Service查詢已完成的流程實例、已完成的任務，以及歷史的流程變量值等。
- ManagementService：
- ManagementService用于執行一些底層的管理操作，如數據庫表的創建、刪除，作業的執行，引擎的配置等。
- 一般情況下，開發人員不需要直接使用ManagementService，因為它執行的操作較為底層。
3.3系統數據表介紹
啟動后會自動生成一些內置的系統表（如果不想自動生成可以通過配置關閉），這里簡單介紹一下表的含義：
ACT_HI_*: 歷史數據表，例如：
表名 | 含義 |
ACT_HI_PROCINST | 歷史流程實例表，存儲已完成的流程實例信息，包括流程開始時間、結束時間等。 |
ACT_HI_TASKINST | 歷史任務實例表，存儲已完成的任務實例信息，包括任務開始時間、結束時間、辦理人等。 |
ACT_HI_VARIABLE | 歷史流程變量表，用于存儲在流程運行時設置的變量信息。 |
ACT_RU_*: 運行時的數據表，節點結束時清除，例如：
表名 | 含義 |
ACT_RU_EXECUTION | 運行時流程執行實例表，存儲當前正在執行的流程實例信息。 |
ACT_RU_TASK | 運行時任務表，存儲當前正在執行的任務信息。 |
ACT_RU_VARIABLE | 運行時流程變量表，用于存儲在流程運行時設置的變量信息。 |
另外，flowable支持定期清理歷史數據，業務側可以定義一個時間范圍，超過時間范圍可以認為數據可以被清理，系統內部會自行將數據物理刪除，為歷史表做瘦身操作。
不過我們業務側接入的時候，往往業務需要創建幾個符合我們具體業務場景的表，例如工單表、任務表雖然框架提供了，但是并沒有記錄詳細的狀態，這些狀態是我們業務自己定義的，所以需要額外創建業務工單表、審批任務（節點）表、流水表等來進行數據上的冗余來滿足實際的業務場景。
四.流程圖建模繪制
4.1 BPMN 2.0協議
我們可以通過可視化后臺繪制流程建模，生成BPMN格式的文件，那么BMPN又是什么呢？
BPMN（Business Process Model and Notation）是一種用于建模業務流程的標準化符號和語法，用于描述業務流程的各個環節和活動。BPMN的最新版本是BPMN 2.0，它是業務流程建模領域的國際標準，由OMG（Object Management Group）制定和發布。
BPMN 2.0的主要目標是提供一種統一的標準，使得不同人員和組織能夠使用相同的符號和語法來建模和理解業務流程，從而增加流程的可視化和可讀性。
它具有以下特點和優勢：
- 圖形化表示：
- BPMN 2.0使用圖形化符號來表示業務流程，包括開始事件、結束事件、任務、網關等。這些符號使得流程的設計和閱讀更加直觀和易懂。
- 豐富的元素：
- BPMN 2.0定義了豐富的元素和連接方式，可以描述復雜的業務流程，包括順序流、消息流、時間流等。
- 流程分支和合并：
- BPMN 2.0支持多種類型的網關元素，如排他網關、并行網關等，用于實現條件分支和合并，使得流程的走向更加靈活。
- 子流程支持：
- BPMN 2.0允許將復雜的業務流程分解為多個子流程，使得整體流程更易于管理和維護。
- 擴展性：
- BPMN 2.0支持自定義屬性和擴展元素，使得業務流程模型能夠滿足特定業務需求。
- 與執行引擎的結合：
- BPMN 2.0是與執行引擎（如Flowable）無縫集成的，這使得通過工作流引擎執行流程變得更加高效和自動化。
4.2 繪制
我們可以從Flowable官網下載flowable-ui部署到本地來啟動可視化后臺，可以使用在線的Flowable Modeler來繪制，這里我們使用官網的flowable-ui來繪制。
具體下載啟動過程我就不過多贅述了，flowable-ui是基于 springboot2.0開發的，可以直接以下方式來啟動：
java -jar flowable-ui.war啟動成功后如圖所示：
圖片
我們打開建模器應用程序并點擊【創建流程】按鈕，我們可以給模型進行一個簡單的定義.
圖片
如圖繪制了一個最簡單的流程建模
圖片
我們也可以給用戶任務分配一些基礎屬性，這里我們配置一個固定用戶， 當然這里也支持占位符來動態控制
圖片
Image.png
圖片
這樣一個最簡單的流程建模(不含復雜節點、網關等)就繪制完畢了，繪制完成后會生成一個xml文件，
接下來我會從導入到執行來執行執行一遍該流程。
五.快速開始
5.1 導入starter
<dependency>
<groupId>org.flowable</groupId>
<artifactId>flowable-spring-boot-starter</artifactId>
<version>6.6.0</version>
</dependency>5.2 導入建模
@Test
public void createConfig() throws Exception{
File file = new File("/Users/xxx/Documents/flowbale/model/testModel.bpmn20.xml");
final FileInputStream fileInputStream = new FileInputStream(file);
final Deployment deploy = repositoryService.createDeployment()
.addInputStream("testModel.bpmn20.xml", fileInputStream).tenantId("類似于業務線的id，可以做數據隔離用")
.name("testModel").deploy();
System.out.println("id=" + deploy.getId());
}5.3 查詢流程建模的基本信息
@Test
public void getProcessDefinition() {
final ProcessDefinition rst =
repositoryService.createProcessDefinitionQuery().processDefinitionKey("testModel").orderByProcessDefinitionVersion().desc().list().get(0);
System.out.println(rst.toString());
}5.4 創建審批工單
// processDefinitionKey 流程建模的key
// businessId 具有業務屬性的id
// variableMap變量的map 結果會存入 ACT_RU_VARIABLE表中，如果審批人傳入的是變量就需要再節點執行前將變量傳入到系統中
Map<String, Object> variableMap = new HashMap();
variableMap.put("testUserList", Lists.newArrayList("nick","jack","tony"));
String processDefinitionKey = "testModel";
Long businessId = 1L;
String tenantId = "1001";
runtimeService.startProcessInstanceByKeyAndTenantId(processDefinitionKey, businessId + "", variableMap, tenantId);5.5 獲取待審批工單
final List<Task> taskList = taskService.createTaskQuery().taskAssignee("jack").list()5.6 審批工單
Map<String, Object> variableMap = new HashMap();
// 我們自己定義了一個內部標準化字段，flag代表著節點是通過還是駁回，在互斥網關判斷通過駁回的時候會用到。
variableMap.put("flag", 1);
taskService.complete(taskId), variableMap);5.7 事件監聽
我們通過上述用例了解了一個工單是如何操作流轉的，但是一個完整的審批服務是應該有消息推送的，當審批節點到達某個人需要提醒他進行審批操作，或者審批工單結束了需要通知發起人，我們應該如何操作呢？Flowable提供了便攜的事件監聽器，不需要我們額外編寫代碼來判斷是否到達相應的節點，我們這里常用的就是節點創建、節點完成、流程結束等。
Flowable支持的事件有幾十種，具體大家請自行去官網參考，下面僅展示“流程結束事件”監聽器的代碼用例：
package com.zhuanzhuan.workflow_engine.config;
import com.zhuanzhuan.workflow_engine.listener.*;
import lombok.extern.slf4j.Slf4j;
import org.flowable.common.engine.api.delegate.event.FlowableEngineEventType;
import org.flowable.common.engine.api.delegate.event.FlowableEventDispatcher;
import org.flowable.spring.SpringProcessEngineConfiguration;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationListener;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.event.ContextRefreshedEvent;
/**
* @author:Live
* @desc:
* @date: 19:55 2023/1/13
*/
@Configuration
@Slf4j
public class FlowableListenerConfiguration implements ApplicationListener<ContextRefreshedEvent> {
@Autowired
private SpringProcessEngineConfiguration configuration;
@Autowired
private ProcessEndListener processEndListener;
@Override
public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {
FlowableEventDispatcher dispatcher = configuration.getEventDispatcher();
dispatcher.addEventListener(processEndListener, FlowableEngineEventType.PROCESS_COMPLETED);
}
}package com.zhuanzhuan.workflow_engine.listener;
import com.bj58.zhuanzhuan.zzarch.common.util.JsonUtil;
import com.zhuanzhuan.workflow_engine.entity.dto.WorkflowOrderDTO;
import com.zhuanzhuan.workflow_engine.enums.CurrentFlagEnum;
import com.zhuanzhuan.workflow_engine.enums.WorkflowStateEnum;
import com.zhuanzhuan.workflow_engine.mq.MqConstant;
import com.zhuanzhuan.workflow_engine.mq.body.ProcessExchangeMsgBody;
import com.zhuanzhuan.workflow_engine.mq.producer.ProducerHandler;
import com.zhuanzhuan.workflow_engine.service.WorkflowOrderBizService;
import com.zhuanzhuan.workflow_engine.wrapper.FlowableWrapper;
import lombok.extern.slf4j.Slf4j;
import org.apache.commons.lang3.StringUtils;
import org.flowable.common.engine.api.delegate.event.FlowableEvent;
import org.flowable.engine.delegate.event.impl.FlowableEntityEventImpl;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import javax.annotation.Resource;
/**
* @author:Live
* @desc:
* @date: 19:34 2023/1/13
*/
@Component
@Slf4j
public class ProcessEndListener implements FlowableEventListener {
@Override
public void onEvent(FlowableEvent flowableEvent) {
// 流程結束的監聽器，發送mq、給發起人發送消息在此進行
}
@Override
public boolean isFailOnException() {
// 拋異常, 不姑息
return true;
}
@Override
public boolean isFireOnTransactionLifecycleEvent() {
// event觸發時機跟著 getOnTransaction走
return true;
}
@Override
public String getOnTransaction() {
// 提交事務后觸發
return TransactionState.COMMITTED.name();
}
}六.總結
以上就是Flowable工作流引擎的簡介以及基本用法，我們實際生產建設過程中，還需要基于框架進行拓展開發來滿足我們項目的實際需要，例如是否需要引入用戶組、權限管理的模塊、是否存在性能問題從而引入異步任務的模塊、是否需要冗余業務表來滿足定制化查詢的需求，這些都屬于擴展玩法，需要我們根據實際需求按需接入。畢竟沒有最好的架構，只有最適合的架構，選擇適合自己的才是最重要的。
七.參考資料
1.flowable官方文檔 https://www.flowable.org/documentation.html
2.技術選型參考 https://www.zhihu.com/question/59274016/answer/2398240513
關于作者
王銳剛，線上回收業務后端開發工程師
