一個完整的工作流引擎，應該具備哪些功能模塊？這篇文章里，作者嘗試結合實際工作經驗和實際案例，對構建工作流引擎這件事兒進行了總結，并對工作流引擎的功能模塊進行了大概講述，一起來看。

最近我做了工作流引擎系統，借鑒了市面上的一些成熟工作流引擎，將其做了一些簡化以更適用于實際情況，同時在復盤的時候發現當初踩了一些坑。所以希望以文章的形式寫出來構建一個完整的工作流引擎應該有哪些功能模塊，哪些功能邏輯，可以抽象哪些業務邏輯，有哪些思考的點。希望對需要的同學有所幫助，也和大家一起討論改進。

文章分為兩篇，由4個板塊組成：

1. 工作流引擎簡介；
2. 從案例出發推演功能；
3. 功能模塊概覽；
4. 功能與邏輯詳解。

本文包括前三個板塊。

一、工作流引擎簡介

1. 工作流是什么？

為了完成某一項工作，而需要有多個環節、多個人員來分工、配合共同完成；而每個環節和每個人員的處理操作是有先后順序的，所以有流向性的特征，也就稱之為“工作流”。

常見的工作流簡單的有如請假流程、離職流程，較為復雜的有采購流程、立項流程等。

大家經歷過就會知道一個工作流會有多個操作節點，也就對應多操作人員；比如請假需要部門領導通過、人事經理通過等，比如采購需要領導驗收合同、財務付款等（工作流和審批流的概念本文就不展開）。

2. 工作流引擎主要是用來做什么的？

工作流引擎是一個為實現工作流程的定制化，并驅動工作流程完整進行的工具。其特點在于可以實現隨著公司實際業務的發展（如組織架構的改動、業務邏輯的改動），而能快速做出靈活響應更改工作流，減少重復性的開發成本。

• 比如一開始公司只有10個工作流，隨著業務發展需要20個，多出來的這10個不用寫死在代碼里，直接可以在工作流引擎內配置；
• 比如公司有人事變動，需要更改某些工作的審批人，也可以直接配置；
• 公司的業務發生了一些改變，原來的審批節點只有5個，現在要增加到10個，等等情況都可配置。

3. 工作流引擎的邊界是什么？

工作流引擎主要只配置工作流，所以需要與業務系統如ERP區隔開，并需與業務系統通過接口對接，以此業務系統方可發起流程、審批流程、完成流程。

也就是說工作流引擎和業務系統是相互獨立但又通過接口對接的兩個系統，一個工作流引擎可以對接多個業務系統，為其配置工作流。

所以操作邏輯應該是：先在業務系統定義有哪些流程，然后在工作流引擎中配置具體流程，再在業務系統中發起/處理流程，并在工作流引擎中可以對已發起流程進行管理；當公司的各類業務系統較多時，不用每個業務系統都去開發自己的工作流管理模塊，這樣可以較大地也提高了開發和維護效率，減少了開發成本。

二、從案例出發推演功能

了解了工作流引擎是干嘛的，我們就可以來看看其應該包含哪些內容。但是如果我一來直接就從某個功能開始講，大家肯定是比較抽象的。

所以我們先從一個審批案例著手，從0開始為完成這個案例我們該配置哪些數據？這樣更有助于大家能先有一個全局的認識，然后再來講一個個的功能，這樣大家可能更容易接受。

前提條件：

某公司有甲、乙、丙、丁4個部門：

• 條件1：每個部門各有1個部門負責人a、b、c、d
• 條件2：甲/乙部門的分管領導是e，丙/丁部門的分管領導是f
• 條件3：東南區域的總監是g，西南區域的總監是h

假設成立項目也就是立項需要走流程，不同類型的項目走的流程肯定不一樣，假設關于項目的維度有項目等級（包括一級、二級），項目區域（包括東南，西南）。通過排列組合，我們可以得到以下4類項目：

• 項目1：一級項目，東南
• 項目2：二級項目，東南
• 項目3：一級項目，西南
• 項目4：二級項目，西南

有了前提條件，我們再分場景來看，不同部門的人員發起不同類型的項目，流程會怎樣走。

場景1

如果一級項目由分管領導審批，二級項目由部門負責人審批，不管哪個區域的項目都要由區域總監審批。根據這個前提我們就可以得到下面這個流程圖：

先解釋一下流程的構成元素，如上圖：

• 有操作節點，比如提交、分管領導、部門負責人；
• 有網關，如菱形帶×這個是互斥網關；
• 有流轉條件，如圖內的一級項目、二級項目，流轉條件是和互斥網關是一起使用，通過流轉條件來判斷不同的工作流數據該流向哪個操作節點。

如果從0開始，這個時候系統里什么數據都沒有，那我們是不是要先錄入部門、人員等組織架構信息？所以就會得到如下圖簡化的表單信息：

但是注意，這上圖只是組織架構信息，并不是該人員在流程中的實際角色。

再回頭看一下流程圖，我們在流程中只會有部門負責人、分管領導、區域總監這3個角色，并沒有指定這個3個角色具體是誰進行審批？因為a是部門負責人，b也是，g是區域總監，h也是。

所以這個時候我們需要引入用戶矩陣這個概念來解決這個問題，也就需要再錄入一個表單來記錄流程中的實際角色，如下圖：

先說為什么要這樣一張表來記錄這些信息？為什么不直接用組織架構表？這樣做主要達到2個目的：

1. 為了解決多個人員擔任同一角色，但又存在變量的情況（比如部門、區域不同），這樣在流程中只需要配置一個角色就行了，不用每個人員都配置一次（具體后面演示）；比如同樣是部門負責人，a管理甲部門，b管理乙部門。
2. 為了將組織結構中的職位與流程中的角色進行解耦；同時調整更靈活，比如在公司中叫部門負責人，在流程中可以叫部門老大，如圖3所示。

然后解釋一下為什么要條件變量和變量值？是因為不同的項目會流向不同的操作節點，系統就需要通過條件變量來判斷，而哪種項目要走哪條流程，是由其變量值來確定的。

根據以上變量值，再結合之前的流程圖，我們就可以得到下圖：

有了流程的相關數據，我們再來看流程會怎樣走。假設張三是丙部門的人員，他來走立項流程，不同的項目屬性會經歷下列審批人：

流程的配置大概就是這些，但有1個思考的點：如果沒有用戶矩陣這張表，我們的流程會配置成什么樣？

如圖所示，我們需要把每個參與到人員都配置到流程中去，也就是一個人員就要占一個審批節點；并且只能通過流轉條件來控制該項目需要走到哪個審批節點。這樣流程將會非常龐大且臃腫。

場景2

基于場景1，我把這些元素打亂了再重新排一下來設定場景：如果甲/乙部門的項目由分管領導審批（e負責一級項目，f負責二級項目），丙/丁部門的項目由區域總監審批（g負責東南，h負責西南），最后再統一由部門負責人審批。所以得到如下流程圖：

組織架構的表單我們已經有了，就不再贅述了。然后第二步我們需要往用戶矩陣表里添加信息：

第三步就能得到這個帶有用戶矩陣的流程圖：

所以可以得到以下結論：

• 假設張三是丙部門員工，發起一個一級、東南區域項目立項，會走g和c的審批；
• 假設李四是甲部門員工，發起一個一級、東南區域項目立項，會走e和a的審批。

為什么我會舉場景2這個例子？

通過場景1和場景2，大家可以看出條件變量有很多，包括人員所屬部門、項目所屬區域、項目等級，而對比這兩個場景大家可以發現，這些條件變量都是可以放到操作節點或流轉條件里去配置的。

比如場景1中不同的項目等級走不同的順序流，場景2中的項目等級是放到操作節點里，不同的等級經過不同的人審批，而這個審批的角色都叫分管領導。

三、功能模塊概覽

經過上面的例子，我們知道了一個完整的流程應該包含哪些元素：組織架構、用戶矩陣、條件變量等，有了這些數據才能配置到流程內。

所以我們就可以看到一個工作流引擎應該由以下功能來組成：

下一篇接著講工作流引擎具體的功能與邏輯。