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：

工作流框架	遵循規範	備註
Bonita BPM	XPDL	流程過於簡單
Shark	XPDL	不維護-2017
Osworkflow	自定義XML規範	不維護
JBPM	BPMN2.0	JBPM4.3後添加了對BPMN的支援，持續開源
Apache ODE	WS-BPEL、BPEL4WS	不維護
Activiti	BPMN2.0，XPDL，JPDL	Activiti7維護
Flowable	BPMN2.0，XPDL，JPDL	持續開源
JFlow	BPMN2.0，Ccbpm	2015年後為了與國際接軌，開發支援BPMN
Camunda	BPMN2.0，XPDL，JPDL	持續開源

表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：

 

	Activiti 7	Flowable 6	Camunda bpm	JBPM 7	JFLOW(國產的)
功能
會籤	√	√	√	√	√
回退	×	√	√	-	√
駁回	×	√	√	√	√
自定義流轉	×	×	√	-	√
加簽、減籤	×	√	√	-	√
多例項	√	√	√	√	√
事務子流程	√	√	√	√	√
版本遷移	×	×	√	×	×
相關推薦 工作流選型專項，Camunda or flowable or？   1. 名詞解釋 1.1. BPM Business Process Management，業務流程管理，“通過建模、自動化、管理和優化流程，打破跨部門跨系統業務過程依賴，提高業務效率和效果”。 1.2. BPMN Business Proce 簡易OA漫談之工作流設計(五，直接上級） 規則引擎裡比較複雜的問題就是：配置步驟的審批人。 某一個步驟由誰來審批，有很多複雜情況： 1、指定某一個具體的人。這種通常用於一些特殊的崗位，全公司只有一個，比如小公司裡的財務，人事專員等。 2、指定一個使用者組（角色）。 3、指定部門中的某個崗位（比如部門經理）。   還有一些特殊情況 springboot2.0整合工作流activiti6.0，以及與業務整合時的一些坑 1、首先，要在springboot工程的pom檔案中引入相關jar包 <dependency> <groupId>org.activiti</groupId> <artifactId>activiti- WF4.0 工作流的結束，終止，異常 正常情況下，工作流結束工作後會觸發事件Completed，如果我們向Completed委託方法，那麼就可以從WorkflowApplicationCompletedEventArgs 引數的ActivityInstanceState CompletionState 屬性中取得 工作流引擎 Flowable 6.0.0.RC1 release，完全相容Activi Flowable 6.0.0.RC1 release，第一個可流動的6引擎版本(6.0.0.RC1)。Flowable 6.0.0.RC1 relase新增加的功能以及特色：包重新命名為org。Flowable ,重新命名flowable.cfg的配置檔案。xml和flowable-context.xml。 python調用Java代碼，完畢JBPM工作流application 6.0 star assigned classpath 邏輯 cif .class pla 自己 1.緣由 有一龐大Python django webproject，要引入工作流引擎，像OA一樣。方便的流程控制與管理。Python或django關於工作流的開源插件，稀少 全開源ASP.NET工作流快速開發平臺，你想要的強大工作流引擎就在這裏！ 名詞 全面 節點 eight 想要 stat 生活 委托 的人 現在辦公要流程化，營銷也有流程，流程現在已經是各種生活活動不可缺少的一部分了。就像這句耳熟能詳的話：“凡事，我們先走個流程嘛！”，在信息化、流程化的背景下。工作流引擎，這個名詞就出現了！那麽，什麽是工作流引擎呢 centos部署airflow工作流， 本地web界面不顯示 per flow tcp 重啟 本地 部署 wal -a nbsp 關閉防火墻： service firewalld stop 發現關閉防火墻後可以訪問 填加端口8080到防火墻： firewall-cmd --zone=public --add-port=808 瘋狂講義Activiti6.X工作流進階與項目實戰，Activiti整合Drools 邊界 進階 活動 boot 搭建 網關 框架 組件 工作流 01 Activiti介紹與搭建開發環境 02 運行官方例子03 編寫第一個Activiti程序 04 流程引擎配置與服務組件05 Activiti數據庫介紹06 API（1）Activiti數據查詢07 API（ Learun FrameWork 強大工作流引擎，讓OA更智能 工作流引擎 力軟開發框架 Learun FrameWork 強大工作流引擎，讓OA更智能 互聯網的發展促使企業在信息化的道路上不斷探索，而隨著企業信息化進程的不斷深入，OA協同辦公的概念也逐步進入大眾的視野。 OA的選型關乎企業的生存發展，除了需要重視“OA技術、OA品牌、OA產品 Learun FrameWork工作流，企業信息化升級的強大驅動引擎 在人力資源管理中，不同的工作流程都由一連串重覆的工作事項組合而成。以人才招聘的流程為例，由計劃招聘到最後作審核，當中已渉及數百個小事項。由於信息需要經過大大小小不同的部門，因此渉及大量的時間與資源。如果在設計流程時沒有定義好執行的順序與附帶條件，會為公司在優化人力資源管理上帶來障礙。 Learun FrameWork，強大ASP.NET工作流管理平臺 工作流 工作流原理 工作流原理：是針對工作中具體固定程序的常規活動而提出的一個概念，通過將過工作活動分解定義良好的任務、角色、規則號過程來進行執行和監控，達到提高生產組織水平和工作效率的目的，工作技術為企業更好地實現經營目標提供了先進的手段。 什麽是工作流？ 工作流就是 工作流4-流程例項，任務，執行物件控制流程的執行 流程例項: 從開始到結束 流程物件: 一個流程,流程例項只有一個,執行物件可以存在多個 1.啟動流程例項 public void startProcessInstance(){ //流程定義的key,根據key啟動最新version流程 String pr asp.net開發分享，learun framework工作流審批設計   對於企業應用系統來說，工作流可以說是其核心和靈魂，而審批流程則是比較重要的基礎應用場景，一個良好的審批設計可以有效的提高公司運轉效率，提升管理規範。 接下來，我們從角色、內容、流程、動作、許可權、配置、效率這幾個方面，瞭解一下learun framework審批工作流的產品設計。 asp.net開發分享，learun framework工作流審批設計 分配 含義 電商 修改 便在 快速 只讀 部門主管 onf 對於企業應用系統來說，工作流可以說是其核心和靈魂，而審批流程則是比較重要的基礎應用場景，一個良好的審批設計可以有效的提高公司運轉效率，提升管理規範。 接下來，我們從角色、內容、流程、動作、權限、配置、效率這幾個方面 activiti工作流，資料庫表解析。 -- 釋出的流程資訊 存有id和名稱。   該id分別在“部署的流程” 和“通用資料” 中記錄 以該表為紐帶，關聯 “部署的流程act_re_procdef” 與“部署流程的配置資訊(該配置資訊記錄在‘通用資料’act_ge_bytearray表中)” select * asp.net+mvc 快速開發平臺，加強工作流引擎，精美UI，給開發一個加速度！ Learun快速開發平臺，asp.net+mvc強大後臺技術，給開發一個加速度 公司業務量比較大，接了很多專案，為了縮短開發週期老闆讓我牽頭搭建了一個快速開發平臺。 我們主要的業務是做OA、CRM、ERP一類的管理系統，一個通用的後臺搭出來，再配合一些快速開發的元件開發效率能提高很多 ASP.net技術支撐，learun工作流開發分享 一、工作流 　　根據的定義，工作流就是自動運作的業務過程部分或整體，表現為參與者對檔案、資訊或任務按照規程採取行動，並令其在參與者之間傳遞。簡單地說，工作流就是一系列相互銜接、自動進行的業務活動或任務。 　　工作流是針對工作中具有固定程式的常規活動而提出的一個概念。通過將工作活動分解成定義良好的任務、角色 asp.net強大工作流引擎，learun助力開發升級 現在，辦公要流程化，營銷也有流程，流程現在已經是各種生活活動不可缺少的一部分了。就像這句耳熟能詳的話：“凡事，我們先走個流程嘛！” 在資訊化、流程化的背景下。工作流引擎，這個名詞就出現了！那麼，什麼是工作流引擎呢？所謂工作流引擎是指workflow作為應用系統的一部分，併為之提供對各應用系統有決定作用的根據 帶你瞭解什麼是Activiti工作流，Activiti工作流資料庫表詳細介紹（23張表） 帶你五分鐘瞭解工作流 什麼是工作流 說到工作流,一圖勝萬言。 工作流 Georgakopoulos給出的工作流定義是：工作流是將一組任務組織起來以完成某個經營過程：定義了任務的觸發順序和觸發條件，每個任務可以由一個或多個軟體系統完成，也可以由一個或一組人完成，還可以由一個或多個