工作流選型專項，Camunda or flowable or？

• 2020 年 8 月 10 日
• 筆記
• ，activiti, ，Camunda, ，flowable, 工作流

1. 名詞解釋

1.1. BPM

Business Process Management，業務流程管理，「通過建模、自動化、管理和優化流程，打破跨部門跨系統業務過程依賴，提高業務效率和效果」。

1.2. BPMN

Business Process Modeling Notation，業務流程建模與標註，包括這些圖元如何組合成一個業務流程圖（Business Process Diagram）；討論BPMN的各種的用途，包括以何種精度來影響一個流程圖中的模型；BPMN作為一個標準的價值，以及BPMN未來發展的遠景。

1.3. BPEL

Business Process Execution Language，意為業務過程執行語言，是一種基於XML的，用來描寫業務過程的程式語言，被描寫的業務過程的每個單一步驟則由Web服務來實現。

1.4. XPDL

XML Process Definition Language,是由Workflow Management Coalition（簡寫為：WfMC）所提出的一個標準化規格，使用XML文件讓不同的工作流程軟體能夠交換商業流程定義。XPDL被設計為圖形上和語義上都滿足交換用的商業流程定義，是描述BPMN圖的最佳文件格式。BPEL也可以描述商業流程。但是XPDL不僅包含流程執行的描述，還包括了元素的圖形資訊，更適於商業流程建模。

1.5. JPDL

JBoss jBPM Process Definition Language，是構建於jBPM框架上的流程語言之一。在jPDL中提供了任務（tasks）、待處理狀態 （wait states）、計時器（timers）、自動處理（automated actions）等術語，並通過圖型化的流程定義，很直觀地描述業務流程。

1.6. PVM

Process Virtual Machine，流程虛擬機，他的設計初衷是通過實現介面和訂製插件等方式兼容多種流程定義語言和流程活動場景，為所有的業務流程定義提供一套通用API平台。那麼，無論是需要對jBPM 原有流程定義語言進行擴展，或者重新實現一套專用的流程定義語言，都可以通過實現 PVM 指定的介面規範完成。

1.7. DMN

Decision Model and Notation，DMN的目的是提供一個模型決策結構，從而使組織的策略可以用圖形清晰的地描繪出來，通過業務分析準確的定義，使其自動化（可選地）。

1.8. CMMN

Case Management Model and Notation，CMMN是一種圖形化的符號，用於捕獲工作方法，這些工作方法基於處理需要各種活動的情況，這些活動可能以不可預測的順序執行，以響應不斷變化的情況。通過使用以事件為中心的方法和案例文件的概念，CMMN擴展了可以用BPMN建模的邊界，包括結構化程度較低的工作和由知識工人驅動的工作。結合使用BPMN和CMMN，用戶可以涵蓋更廣泛的工作方法。

2. 眾多工作流

2.1. JBPM（Java Business Process Management）

由JBoss公司開發，目前最高版本JPBM7，不過從JBPM5開始已經跟之前不是同一個產品了，JBPM5的程式碼基礎不是JBPM4，而是從Drools Flow重新開始。下面要涉及的很多產品都是以JBPM4的程式碼為起點進行開發的。

2.2. Activiti

Alfresco軟體開發，基於JBPM4，後併入OMG，目前最高版本activiti 7。Activiti5版本的時候，核心團隊發生了比較大的變動（離職），activiti6的開發團隊在新版本中去除了PVM，納入了DMN，重構XML解析，BUG較多，目前主要團隊致力於activiti7,5&6已經官宣不維護。

2.3. Osworkflow

完全用java語言編寫的開放源程式碼的工作流引擎，具有顯著的靈活性及完全面向有技術背景的用戶的特點。由opensymphony組織維護，其不遵守XPDL等業務規範，完全使用XML編排業務。面向開發人員。

2.4. Shark

靠山是Enhydra。是一個可擴展的工作流引擎框架，它包括一個完全基於 WFMC 規範的標準實現，它使用XPDL（沒有任何自己新的擴展）作為自身的工作流流程定義格式。其持久層和設計器都是自己公司研發的，持久層實現採用的標準是輕量級的Enhydra DODS O/R mapping 工具，設計器可以用Enhydra JaWE 圖形XPDL編輯器。

2.5. Apache ODE

輕型的、可嵌入的組件，利用組件組裝成一個完整的BPM系統。關鍵模組包括ODE BPEL編譯器、ODE BPEL運行時、ODE數據訪問對象（DAOs）、ODE集成層（ILs）和用戶工具。雖然掛在Apache下面，但已經年久失修。

2.6. Flowable

基於activiti6，最新的開源版本是flowable6，開發團隊是從activiti中分裂出來的，修復了一眾activiti6的bug，並在其基礎上研發了DMN支援，BPEL支援等等。相對開源版，其商業版的功能會更強大。

2.7. Camunda

基於activiti5，所以其保留了PVM，最新版本Camunda7，開發團隊也是從activiti中分裂出來的，發展軌跡與flowable相似，同時也提供了商業版。

2.8. JFlow

前身ccFlow，國產的工作流引擎，由濟南馳騁公司開發維護，主打中國式的業務流程，由於是國產的軟體，中文化程度比較深，業務開發也對用戶比較友好。國產的開源工作流引擎還是挺多的，JFlow是其中功能比較完善的一個，同時對比activiti，流程上更加中國化，支援自定義流程跳轉，加簽等。其他國產工作流就不列舉了。

還有很多工作流，比如ProcessMaker，SWF，oracle，Bonita，openwebflow，snaker

等，不過做BPM的話，相對於上面列舉的產品還是有些缺陷，比如流程過於簡單，資料過少等。

3. 關於工作流標準

BPMN是聽得比較多的工作流標準，但工作流的規範其實不止一種，還有XPDL，BPML等。甚至他們的出現時間比BPMN更早，只是因為一些技術和非技術原因，BPMN2.0被普遍使用了，而非BMPN2.0規範的廠商也逐漸轉移了。

以下的內容是關於規範標準之爭中，BPMN2.0如何從眾多規範中戰勝並被普遍使用的。

3.1. BPMN1.X

在BPMN1.X里，BPMN是Business Process Modeling Notation的縮寫，即業務流程建模符號，而在BPMN2.0里，BPMN變成了Business Process Model And Notation的縮寫，即業務流程模型和符號，一個單詞的增加卻標示著BPMN本身發生了巨大的變化。

查看如下圖1 timeline:

圖1

其中BPMN1.0在2004年5月由BPMI組織正式發布。這個階段WSFL和BPEL-WS都已經被發布。這三種規範中，BPMN1.0僅僅作為業務流程建模的一系列符號標準，對業務比較友好。廠商們認為統一的建模標準能夠使他們圍繞核心建模工具提供其他更多的價值，更加願意接受BPMN。

但BPMN1.x只是一些建模符號，不支援元模型，不支援存儲和交換，也不支援執行。2008年，BPMN1.1發布，但仍然存在這些對開發人員並不友好的缺點，XPDL、BPEL和BPDM圍繞著BPMN1.x的存儲、交換和執行，產生了新的競爭。

XPDL作為WfMC提出的流程定義語言規範，本身就是一個元模型，可以存儲，並且具備執行語義，因此理論上來講，將BPMN轉換為XPDL就可以解決存儲、交換和執行的問題。XPDL2.0於2005年10月發布，在規範里，WfMC直接將XPDL的目標定義為BPMN的XML序列化格式。2008年4月23日發布的XPDL2.1規範，直接支援BPMN1.1到XPDL2.1的轉換。XPDL是面向圖的，BPMN也是面向圖的，因此BPMN到XPDL的轉換有著天然的優勢。如今有超過80個的不同公司的產品使用XPDL來交換流程定義，同時也有一些廠商在自己提供的BPMN工具中使用了XPDL作為交換和存儲格式。

BPEL-WS規範在2003年4月提交給了OASIS（Organizationfor the Advancement of Structured Information Standards，結構化資訊標準促進組織）並更名為WSBPEL（Web Services Business Process Execution Language）規範， 2007年4月發布WSBPEL2.0版本，除了Microsoft、 BEA、 IBM、 SAP 和Siebel，Sun Microsystems和甲骨文公司也相繼加入了OASIS組織。除去政治因素，BPEL的流行還在於Web正成為分散式系統架構的平台以及SOA的雄起，SOA強調服務的分解和解耦，而BPEL則對這些WEB服務進行編製，兩者密不可分。但BPMN到BPEL的轉換存在著先天上的缺陷，原因是BPMN是基於圖的，而BPEL是基於塊的，BPEL是一個結構化（塊[Block]）和非結構化（控制鏈和事件）的混合體。這個缺陷導致有些BPMN建模的流程無法映射到BPEL，兩者的雙向工程更是存在問題。這個缺陷成為人們反覆詬病的對象。許多支援BPEL的產品為了解決這一問題，不得不在用戶建模時做出種種限制，讓用戶繪製不出無法轉換的模型。

而BPDM（業務流程定義元模型，Business Process Definition Metamodel）則是OMG組織自己提出來解決BPMN存儲和交換問題的規範。於2007年7月形成初稿，2008年7月被OMG最終採用。BPDM是一個標準的概念定義，用來表達業務流程模型。元模型定義了用來交換的概念，關係和場景，可以使得不同的建模工具所建模出來的流程模型進行交換。BPDM超越了BPMN和BPEL所定義的業務流程建模的要素，它定義了編排和編製。

3.2. BPMN2.0

隨後，BPMN2.0發布了。看圖2 timeline

圖2

BPMN2.0 beta1版本於2009年8月發布，BPMN2.0 beta2版本於2010年5月發布，BPMN2.0正式版本於2011年1月3日發布。BPMN2.0正式將自己更名為Business Process Model And Notation（業務流程模型和符號），相比BPMN1.x，最重要的變化在於其定義了流程的元模型和執行語義，即它自己解決了存儲、交換和執行的問題，BPMN由單純的業務建模重新回歸了它的本源，即作為一個對業務人員友好的標準流程執行語言的圖形化前端。BPMN2.0一出手，競爭就結束了，XPDL、BPEL和BPDM各自準備回家釣魚。

BPMN2.0是最被廣泛使用的標準，也是當前熱門產品使用的標準，詳情請看整理的表1：

表1

這個表格可以對一些工作流產品有一個初步印象。

4. 分表對比

4.1. 對比須知

為了方便查看匯總表格，有必要再深入展示幾個開篇提到的概念：

PVM

PVM是在JBPM4的時候被納入的，activiti5沿用，activiti團隊在activiti6就已經移除了，ActivitiImpl, ProcessDefinitionImpl, ExecutionImpl, TransitionImpl 都不可用了。所有的流程定義有關的資訊都可以通過BpmnModel來獲得，通過org.activiti.engine.impl.util.ProcessDefinitionUtil來拿到BpmnModel。

工作流中，由於flowable是基於activiti6開發的，所以程式碼中也沒有PVM，Camunda基於activiti5開發的，所以PVM還在，更改這個核心引擎沒有絕對的好壞之分，但是由於我們的程式碼是基於activiti5開發的，所以對我們的程式碼移植是有影響的。

DMN

BPMN是OMG公司發布的工作流規範，而DMN同樣是OMG公司發布規範，該規範主要用於定義業務決策的模型和圖形，1.0版本發佈於2015年，目前最新的是1.1版本，發佈於2016年。

  BPMN主要用於規範業務流程，業務決策的邏輯由PMML等規範來定義，例如在某些業務流程中，需要由多個決策來決定流程走向，而每個決策都要根據自身的規則來決定，並且每個決策之間可能存在關聯，此時在BPMN與PMML之間出現了空白，DMN規範出現前，決策者無法參與到業務中。為了填補模型上的空白，新增了DMN規範，定義決策的規範以及圖形，DMN規範相當於業務流程模型與決策邏輯模型之間的橋樑。

圖3圖解：

圖3

雖然DMN只作為工作流與決策邏輯的橋樑，但實際上，規範中也包含決策邏輯部分，同時也兼容PMML規範所定義的表達式語言。換言之，實現DMN規範的框架，同時也會具有業務規則的處理能力。

CMMN

CMMN具有與BPMN不同的基本範例。 CMMN沒有順序的流程。相反，它以某種狀態對案例建模。根據狀態，視情況而定，有些事情可能會處理，而有些事情可能不會。控制主要由人來執行。 CMMN是聲明性的，該模型說明了要應用的內容，但沒有說明如何實現它。相反，BPMN強制性地規定了流程中某些步驟必須進行的工作。對於大多數人而言，聲明性建模更為複雜且較不直觀。結果，CMMN模型更加難以理解。您不能簡單地用手指追蹤路徑！

CMMN對可能的活動和活動限制進行建模。它對活動何時發生，何時必須發生以及何時不應該發生進行建模。 CMMN同樣限制了流程中人員可以使用的操作範圍。事例模型必須事先經過仔細考慮。重要的是要提出這一點，以應對人們經常誤解的事實，即人們在案件管理方面可以做他們想做的任何事情。

CMMN和BPMN都描述了業務流程中的活動。這些標準之間的主要區別是：

1、BPMN採用綁定方法。 它提供了活動的確切順序。提供自由度比較困難。比如加個節點、任意跳轉就很麻煩。

2、CMMN採用非約束性方法，然後增加了限制。建立排序比較困難。

換句話說，原則上您可以用任何一種表示法表達大多數問題。但是，根據問題的類型，建模將在BPMN或CMMN中更好地工作，並且這些標準之一更可能產生整潔有效的模型。

使用CMMN的指標包括：

1、無需序列：如果序列無關緊要，並且可以按任何順序執行任務，則這將在BPMN中產生過多的連接-臨時建模。也許使用臨時子流程可以避免混亂。

2、活動取決於條件：定義條件是CMMN的強項。可以定義許多任務，但是它們只能在某些情況下起作用。例如，這種情況可能是訂單超過一定數量或客戶具有VIP身份；其他已完成的任務也會影響條件。可選因素和數據相關因素的這種組合不能在BPMN中反映出來。

3、專用計劃階段：由於能夠處理任意任務，CMMN可以適應一個計劃階段，在該階段中，一個工人計劃一個案例並啟用任務。 其他工人將不得不遵守計劃。 BPMN不能做任何事情。

包括BPMN標準，這三個標準都是由OMG提出的。多數機構認為DMN和CMMN是工作流發展趨勢。

4.2. 對比表格

經過第二個章節的比較，我從支援的標準和社區活躍度表現比較好的工作流中篩選出幾個選項進行進一步對比，如表2：

表2

特別說明：

1. 源碼活躍度：從分支數，提交數，參與者，最近提交時間等判斷

2. Drools Flow (process/workflow)：該工作流引擎是Drools下的一個項目，JBPM的規則引擎正是Drools，由於activiti開發自JBPM4，所以activiti，flowable以及Camunda都有Drools的影子。

3. 空白處或者小短桿表示的代表的暫時未查證的內容

4. 另外要說明的是，表格中支援的功能需要有不少部分需要認真探討，比如Camunda宣稱支援各種功能，以及Nosql存儲，但實際上，其支援的回退，撤回都是通過一個跳轉實現的，要打折扣，NoSql也只是提供了解決方案，要自己實現噢，後面一篇文章會再提及。

5. 性能

關於工作流性能比較的文章比較少（少得可憐），因為沒有直接的數據能夠對比工作流之間的性能，所以獨立出一章介紹，基本情況：

5.1. 概述

以下內容來自：

//www.bpm-guide.de/2016/06/12/scientific-performance-benchmark-of-open-source-bpmn-engines/ 《Scientific performance benchmark of open source BPMN engines》

據說是16年的一份科學性能報告，可惜性能報告中，除了Camunda外，其他兩種被對比的WFMS產品名稱並沒有寫出來，所以這個報告只能作為參考：

「In general, we may conclude that Camunda performed better and more stable for all metrics when compared with WfMS A and WfMS B.」

「WfMS A and Camunda share many architectural similarities because Camunda was originally a fork of WfMS A.」 暗指WfMS A是activiti。

為了得到更多的性能數據，接下來從各個官網尋找材料。

5.2. Camunda

//camunda.com/products/performance/

該地址沒有描述具體的性能，但是列舉了一些措施，表示做了性能考慮：

1. 緊湊型表：減少必要的存儲數據，在最好的例子中，修改一個活動只需要更新一條數據

2. 避免死鎖：採用樂觀鎖；用戶思考期間不持有鎖；批量刷新數據

3. 控制保存點：在一個事務中保存多個活動

4. 智慧快取：使用一級快取，減少查詢

5. 並行：並行任務在資料庫中表現為不同行，實現真正並行

6. 集群：多節點共用資料庫

7. 最小資源佔用：流程引擎無狀態，每個節點只需要分配少於10M的快取，所以支援大批量任務在節點上運行

8. 分庫：歷史庫和運行庫是分開的，原則上，歷史數據可以轉移到任何大數據產品上

5.3. Flowable

//flowable.com/open-source/docs/bpmn/ch18-Advanced/#async-executor

這裡沒有特別介紹提升性能的設計，但一些角落有提到，對性能是否提升未知：

1.額外寫了UUID id生成器，解決並發的bug，但其實不一定能提升性能；

2.資料庫的批量插入

3.async executor：非同步執行器，能解決背壓，但是對性能的提升程度未知

5.4. JBPM7

//jbpm.org/learn/jbpmPerformance.html

這裡也沒有介紹性能的具體情況。但提供了檢測性能的方法，指明了不跟任何工作流作對比，言辭謹慎。官網給的例子仍然可以作為參考數據，翻譯如下：

客戶端：jmeter

版本：社區版 7.8

硬體：

Macos 10.14.4

Cpu i7 2.3GHZ

Memory 16GB

Db Postgre

測試內容：三個簡單的流程，我做了簡單的表格繼承他的測試結果；（利用執行1000個實例用時得出TPS）

5.5. Activiti 7

//activiti.gitbook.io/activiti-7-developers-guide/

有提到一些提升查詢性能的地方，但是不明確。

5.6. JFlow

未提及性能

6. 總結

大致總結以下調研的總體感受。Activiti7相對於5和6沒有太多功能上的變化，主要致力於一些輔助功能，對接一些基礎技術。比如雲原生，ELK，spring cloud。分散式的應用或許會對性能有一定的提升。

Flowable的NoSql方案和消息隊列比較特別，同時對DMN和CMMN的研究也比較多，是個不錯的選擇。

JBPM近年來新的文檔少一些，應用和二次開發可能會比較吃力。JFlow功能比較齊全，而且中文化的設計器對開發人也和業務人也都比較友好，但是他的材料基本限於官網，後期不會保障。

Camunda BPM支援的功能比較多，對DMN和CMMN的支援也是推出最早的，性能上看起來也做了比較多的應對，雖然商業版的推出減少了開源版的維護，但仍然是幾個競品中綜合看起來比較符合當前需求的，PVM的保留也會使得遷移比較順滑，具體使用情況還需要進一步嘗試，比較推薦。（如果不是舊產品遷移其實需要更多選擇，框架改革的優化是可以考慮在內的，根據需求選擇）

7. 一些參考網址

//github.com/qiudaoke/flowable-userguide/blob/master/%E6%A1%86%E6%9E%B6bug%E5%88%97%E8%A1%A8/bug.txt 《Flowable 6.5未修復bug列表》  

//flowable.com/blog/2016/09/decision-model-and-notation-dmn-how-to-start-a-project-2/  《decision-model-and-notation-dmn-how-to-start-a-project-2》

//blog.camunda.com/post/2016/10/migrate-from-activiti-to-camunda/ 《How to migrate from Activiti 5.21 to Camunda BPM 7.5》

//www.bpm-guide.de/2015/09/28/why-bpmn-is-not-enough/ 《Why BPMN is not enough》