Activiti工作流實戰使用總結

作流在我們日常的工作中用得可謂相當普及,尤其在企業內部管理系統,如考勤、財務、合同等系統中更是離不開它。在我們金融科技領域,工作流主要用於貸款審批、風控審覈等環節。由於工作流具有一定的門檻,國內尚沒有能滿足企業級應用的工作流開源框架,一些國內CMS開源項目號稱支持的工作流也只是對Activiti的簡單引入或者是較簡單的工作流實現,還不能完整的滿足一般企業應用。

Activiti是目前最熱門的開源工作流框架,但是由於中西方文化差異及組織架構上的不同,拿Activiti來做中國式的企業級應用難度很高,需要做大量的改造。如果JAVA底子不好推薦XJR快速開發框架,基於國內企業級需求自主開發的一款java開發框架。通過圖形化、可視化的簡單拖拉設置操作,快捷設計出我們所需的表單、APP、流程、報表等,可開發各種管理信息系統。

這裏記錄下Activiti工作流常見的思考點及解決思路,實際碰到的問題會更多且更復雜。

1、待辦已辦在Activiti相關API中是面向任務的,需求是面向流程的

比如,如下圖的需求

Activiti工作流實戰使用總結

在Activit中一個流程是有多個Task組成,而我們中國式的審批需求是一個流程只允許出現一次,哪怕這個流程你在審批過程中參與過兩次以上的審批任務,也僅需要顯示一次。

這裏就需要將TaskService查詢出來的任務再按流程實例ID進行去重,去重後任務查詢api的分頁會變得不可用,對待辦和已辦未完結來說還好,一般來說數據量不會太大的情況下可以用假分頁技術在內存中進行分頁。辦結因爲歷史數據的積累會越積越多,不適合用假分頁技術了,這時該怎麼辦呢?我們的做法是添加PROCESS_COMPLATE事件監聽,在流程結束後,將這個流程及審批參與人全部記錄到某張表。分頁查詢時先從這張表按頁查出流程,再調用Activiti的API進行字段補全查詢。

2、運行時動態增加或刪除節點

中國式的審批場景中經常會發生在運行過程中動態增加或刪除節點的情況,比如領導一時興起就想將這個任務給某人會籤一下(雖說這完全不符合BPMN規範但確實也是廣泛存在的需求),但你在設計這個用戶任務時是定義成了單人任務,如果將所有任務一開始就定義成多人任務,成本又太高了。很遺憾的是這個是Activiti無法做到的,也不太建議你爲此對Activiti進行hack實現,

Activiti中流程是流程定義的一個運行實例,流程一旦生成,節點是"靜態地"按定義生成的並不能動態的增刪,這與很多國產的工作流不同。這點上只能儘量管理好客戶需求了。

3、流程標題和發起人很重要

流程標題和發起人在中國式的審批需求中極度重要,標題一般還需要做成能默認生成且能自定義的,在Activiti中,需要用變量來支持,在流程啓動時增加兩個變量,如applyUserId和title。

4、重要的雙向映射

審批總是和業務關聯的,比如一個貸款審批流程會映射一個貸款申請編號,從貸款申請能找到流程,從流程還需要能找到貸款申請。通常會在業務表裏增加一個流程實例ID字段,而在啓動流程時指定businessKey爲businessTable+":"+businessId,這樣就建立了雙向的映射。

5、簽收

Acviti中有個概念叫簽收,簽收一般用來處理團隊的任務,比如財務崗有三個人,用戶組任務出現在三人的待辦中,任一人通過claim方法將任務簽收後再進行處理,簽收後任務將從其他二人的待辦中刪除。如果不想暴露簽收的概念,也可以簽收和辦理同時進行,即先調claim方法,再complate,但要注意可能存在的併發審批的問題。

6、用戶和用戶組

Activiti中的用戶和用戶組需要和系統的用戶和角色進行同步,用戶與系統的用戶使用用戶名關聯,用戶組與角色使用角色編碼關聯。角色分兩類:系統角色和工作流角色,系統角色是從系統使用權限的角度來分的,而工作流角色是從工作流審批的角度來看的。爲了更方便區分這兩類角色不發生混用的情況,工作流角色命名都以:工作流_開頭。比如:工作流_公司董事長,工作流_公司財務。

7、退回

需求如下圖:
Activiti工作流實戰使用總結

中國式的審批場景中經常會要求退回到仍一節點的需求,比如你當前在第四個審批節點,需要能退回第一、二、三任一節點。相信我,如果你敢用流程設計時畫多條線的方式來設計的話保證流程會設計得相當複雜。Activiti原生是不支任務這種跳轉的,不過幸好有人實現了用JumpTaskCmd的方式來進行跳轉。另外在查詢可退回節點時,要考慮流程反反覆覆被退回又再審批的情況,過濾掉重複的節點。

8、必不可少的流程干預

包括按條件進行流程查詢,將任務指定給任一處理人,任務節點任意跳轉等,這些都是線上流程運維必備的功能點。儘量把你的用戶當成傻子,我還曾多次遇到過一些粗心的用戶在流程審批通過後,才發現某些業務字段填錯的情況,如果沒有必要的管理員干預功能,那就只能改數據庫表實現了。具體需要哪些干預功能,這個和自己企業的情況相結合着來進行吧。

9、集成Diagram viewer

Diagram viewer是用來查看流程圖的一個插件,原生的不算美觀也不算很醜湊合着能用。

10、集成Modeler

如圖:

Activiti工作流實戰使用總結

11、流程版本管理及上線

需要模型管理,集成Modeler進行模型的新增與修改,還需要進行模型的發佈纔可以使用新的流程設計。那線下設計好的模型怎麼同步到線上環境呢?這就需要提供模型導出和導入功能。另外直接用sql導入不可取,由於流程定義是二進制數據,用sql導入會造成轉碼後流程數據丟失。當然,極簡單點工作流場景下直接把流程和代碼一起部署也是可以的。

12、審批業務數據庫表設計要點

通常看流程是純新增類還是帶更新類業務,純新增類只需要正常設計再加個流程實例ID字段與流程實例進行關聯即可。如有更新類業務,最好設計一個跟業務表結構一樣的草稿表,當流程審批完成後,通過監聽器再將草稿更新應用回業務表。

13、擴展流程設計時的assignee

Activiti的用戶任務指派相當簡單,要麼指定人或條件處理人,要麼指定用戶組,這在中國式審批中是完全不夠用的,所以還需要對設計進行擴展,方法是用將assignee字段設置成json,由json擴展各實際條件,當發生TASK_CREATED事件時,動態解析json,再將此json中的配置與流程的變量運算得到實際處理人。好了,在流程設計的時候這串json的輸入將是返人類的,所以你還需要提供一個UI,按條件生成這串JSON,甚至更進一步,改進Modeler。

14、完成第一個任務

發起人節點,你有兩種設計,一種是直接省略,過了StartEvent後進入下一節點審批任務,但通常任務被退回後,發起人還需要進行銷燬或重新申請等運作,所以你需要第二種設計:給發起人節點增加一個UserTask,那發起一個流程的時候就要記得將發起人的這個第一個用戶任務自動完成。

15、通用表單設計

老實說這塊工作量很大,首先需要將表單設計器生成的html存儲後與設計的流程通過formKey建立映射,流程在運行時通過formKey找到對應的表單展示。難點還在後面,需要用戶填寫的表單數據進行保存,如果是非業務數據可以採用通用的格式進行保存,如果這些是業務數據又想做成通過的,通常是在定義表單時自動DDL生成數據庫表,但這種做法又引起維護性和安全性上的問題。另一種辦法將通用格式如json/xml,在流程結束後通過一定規則的映射,映射到指定的業務表中。

如果JAVA底子不好可以試試XJR快速開發框架的表單設計器,拖拽式表單開發,這種形式的開發,完全沒有編程基礎的人都可以利用這個組件來開發,開發完表單直接可以發佈成菜單功能,無需編譯就可以使用。同時可以對自定義表單權限管控。

Activiti工作流實戰使用總結

Activiti工作流實戰使用總結

16、用好監聽器

監聽器並不是異步的,監聽器並不是異步的,監聽器並不是異步的,它和事件產生源在同一個線程,就是說如果你有個TASK_COMPLATE事件監聽器,如果報異常了,你的taskService的complate事件是完成不了的。另外建議儘量用全局監聽器,而不要用局部監聽器,因爲局部監聽器在流程設計中才能看到,會造成業務代碼散落到各處而難於維護。

17、流程熱部署

熱部署的第一層支持是線下設計好流程,通過文件上傳功能更新到線上進行部署。再進一步是,線上使用Modeler進行模型設計,完成後進行部署生效。生效後舊流程不受影響,還按舊流程設計進行流轉,新流程按最新的流程設計流轉。

18、流程銷燬與重新申請

這個通過排它網關拉線設計即可,不過銷燬後的流程此時是出現在辦結裏的。如果用戶徹底刪除的需求,還需要deleteProcessInstance、deleteHistoricProcessInstance及刪除業務草稿表相關記錄(如有)

19、會籤

會籤涉及到表決,不過通常來說常用的就兩種情況。一種是所有人通過才通過,另一種是有一個人是主審,他通過就通過,在審批過程中他會參考別人的意見。第一種Activiti原生支持,第二種在選會籤人時complate自己任務並將自己加入到多人任務中。

20、Activiti那麼多版本,我該選哪個

目前用得相對比較成熟的版本是5.22,版本6.x存續期間很短很快就升級到了7.x,2018年我嘗試時是6.0 alapha版本,當時還測出不少bug,現在最新版本是7.1,功能上變動不大,主要是Cloud Native,彈性微服務方向和Docker、K8S支持上做了重大的架構升級。微服務方面,可以近似認爲Activiti5中的Activiti-rest是SOA化的Activiti,版本7後是微服務化後的Activiti。但是如前面所講的,Activiti拿來國內用其實是不完整的工作流,還需要做大量的改造,所以不加包裝直接用現在的原生微服務並不友好。Activiti 7除了微服務支持方面外,對FormService和TaskService相關的接口也做了改動,還有最新版本的Modeler還不如舊版本美觀。(文章轉載鳴箏誰顧)

Activiti最大的優點就是免費開源,小項目中應用簡單的串行並行流轉基本能滿足需求。現在很多開發人員會選擇它。但是要拿Activiti做到中國式的企業級應用門檻和難度很高。想用Activiti來做符合中國國情的審批流程,其實還需要做大量的開發封裝。

可以體驗一下XJR快速開發框架:採用主流的Activiti工作流引擎,遵循bpmn規範,可實現XML、Json一鍵導入導出,以及添加了人員動態選擇、便捷式會籤設置、便捷式任務委託設置、添加自定義表單、自定義節點按鈕、動態變量選擇(包括會籤變量、按鈕變量、表單變量)以及各節點屬性優化,遵循以客戶爲中心的優化原則,將整個流程的操作變得簡單、快捷,實現0基礎短時間可自由編輯流程模板。
Activiti工作流實戰使用總結

操作相當方便,先通過表單設計器能可視化地設計流程表單,表單設計好了就可以直接放到工作流引擎中流轉。流程設計器可以可視化設計工作流程圖,節點設置中可以靈活地配置節點執行人,執行策略。流程執行中可以向執行人發送通知。流程設計過程均爲可視化開發,只需要懂數據庫SQL語句,就可以進行流程管理的設計,能夠大大提高開發效率和減小開發難度。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章