從0到1構建工作流引擎(二)

5 評論 5791 瀏覽 43 收藏 25 分鐘

在構建完整的工作流引擎時,應當遵循哪些功能邏輯和業務邏輯呢?這篇文章里,作者就結合實際工作案例,對功能與邏輯進行了詳細拆解,一起來看,或許會對你有所幫助。

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

文章分為兩篇,由4個板塊組成:

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

本文是第二篇,本文包括第四個板塊。前三個板塊請看《從0到1構建工作流引擎(一)

四、功能與邏輯詳解

由上一篇文章中我們知道了一個工作流引擎應該有圖中這些功能,本篇文章主要對每個功能進行詳解,包括其背后的邏輯、分支情況和思考點。

其中,業務系統管理畢竟維護的頻率太低,主要維護哪些字段也需要和開發溝通,組織架構管理也無非是部門信息和人員信息,所以這兩塊功能就直接跳過。

1. 角色矩陣管理

角色矩陣管理功能主要分為兩類,矩陣人員和固定人員,具體解釋如下:

  • 矩陣人員:組織架構下會多個部門都會存在的角色,如部門負責人;所以該角色會由多人擔任,且對應其所在部門;
  • 固定人員:組織架構下只會固定存在一個的角色,如財務總監,總經理等角色;所以該角色只會由一人擔任。

1)矩陣人員操作頁面

上圖為矩陣人員的列表配置頁。通過圖中可以看到,左側功能為矩陣角色的添加維護板塊,右側是角色對應的人員的添加維護板塊。

操作邏輯為:

  1. 先添加矩陣人員角色;
  2. 再為角色選擇角色變量(數據來源于條件變量管理);
  3. 再選中該角色為其添加人員(人員的數據來源于組織架構管理);
  4. 最后再為人員配置變量值(數據來源于條件變量管理中該條件變量的值)。

這樣矩陣人員的數據就配置好了,具體怎么用看后文流程模型管理中描述。但是這里有2個問題:

a. 為什么條件變量是跟著角色走,也就是一個角色一個條件變量,而不是一個人員一個條件變量?

條件變量跟著人員走也可以,但是角色只會存在于一個操作節點中,操作節點的主要目的是對一個變量進行處理,如果有2個及以上變量,為什么不再多設幾個操作節點呢。所以這樣會增加配置和理解的難度,還不如單純一點。

還有就是為了防止用戶操作過程中選錯選漏條件變量等風險,導致流程沒有找到對應的審批人。

b. 為什么要有一條默認數據?

比如區域負責人這個角色負責的區域該有東南西北,如果我只配了東南西的3個人員,區域為北的項目走流程時就會因為找不到處理人員而報錯。

又比如只有東是一個負責人,南西北是一個負責人,我只需要配東就行了,南西北就直接由默認包含了,因為工作流引擎會優先找非默認的數據,發現找不到就直接找默認那條數據。

所以在變量值很多的情況下,有一條默認數據可以達到2個目的,1是防止漏配,2是簡便配置過程和數據。

2)固定人員操作界面

上圖是固定人員的列表配置頁。通過圖中可以看到,左側功能為固定角色的添加維護板塊,右側同樣是角色對應的人員的添加維護板塊。

操作邏輯為:

  1. 先添加固定人員角色;
  2. 再選中該角色為其添加人員(人員的數據來源于組織架構管理)就行了,相較于用戶矩陣的配置更為簡單。

與用戶矩陣不同的是,固定人員配置的都是由一個人擔任的角色,比如總經理,財務總監此類,不需要由條件變量去判斷該由誰去審批。所以一個角色雖然可以為其添加多個人員,但是只能有1個人員的狀態開啟。

這里有3個思考點:

a. 如果允許多個人員開啟會怎么樣?

如果直接在固定人員里開啟2個及以上人員,流程這個操作節點時,這2個人是會簽還是或簽呢。

這個思考點可以結合下文流程模型中來看,流程模型中的操作節點是可以添加多個處理人的,所以這是能達到并審目的的。甚至可以用并行網關也是可以達到并審目的。

b. 如果沒有矩陣人員這個功能,全靠固定人員來配置需要怎么配?

A部門的部門負責人(張三),B部門的部門負責人(李四),C部門的部門負責人(王五)……也就是有多少個人會參與到審批,就需要配多少個固定角色,并且流程中也需要配多少個操作節點。

c. 例如總經理這類角色是否可以用矩陣人員來配置?

也是可以的,但是在配置條件變量、變量值的時候,還有在流程的后端邏輯處理就需要改變一些規則了,變得更復雜了,同時在操作人員的認知上和配置上來說會比較麻煩。

2. 條件變量管理

條件變量的數據來源于業務系統,如erp、oa等,它的目的是為了將業務系統中的字段與工作流引擎建立映射對應關系;如項目分一級項目和二級項目,一級由XX審批,二級由XXX審批,所以業務系統在發起流程時會記錄該項目是一級還是二級,工作流引擎以此來判斷該走哪個審批。

而條件變量從用法上可以分兩類:

  1. 用于流程模型配置中不同的順序流;
  2. 用于矩陣人員配置中人員與變量建立關系。

(但是在系統中并沒有強制規定某個條件變量是否只能用于順序流或者矩陣人員,所以這一點是很靈活的)

注意,具體條件變量需要配置哪些字段需要和開發同學溝通,有沒有必要單獨做一個前端頁面需要看實際情況而定,畢竟開發同學可以直接在數據庫維護,因為增減字段可能是一個低頻次操作。不過做出來有一個好處就是方便查看有哪些變量和變量值,也可以手動維護。

從圖中可以看到條件變量包括編碼和數據類型,這個編碼是在業務系統的數據庫中存儲的編碼,在工作流引擎的數據庫中配置是為建立映射對應關系。數據類型包括字符型、布爾型等。

3. 流程模型管理

前面將配置流程所需要用到的元素和數據都已配置好了,接下來就是最重要的流程模型管理了,也就是怎樣配置一個完整的流程了。

1)流程模型配置–流轉線配置界面

上圖是流程模型–流轉線的配置頁面,流轉線也就是圖中互斥網關(菱形帶×)后的兩條線。整個頁面主要由三部分組成:

  1. 最上面一排左邊是對流程的增刪改按鈕;右邊是對模型或頁面的操作按鈕;
  2. 中間是可視化編輯器,可對模塊進行拖拽添加或修改;
  3. 下面是對操作節點和流轉線的配置板塊。

基于上圖中的這個操作界面,我們要添加一個完整的流程應該怎么做?

  • 第一步:先將流程所需的元素添加完整,如操作節點、網關、流轉線、結束節點等;
  • 第二步:再將流轉線上的流轉條件配置完整(如果沒有用到互斥網關可以忽略這一步);
  • 第三步:再將操作節點內各維度的屬性配置完整,如處理人、抄送人、操作按鈕等;
  • 第四步:保存流程,這時候會進行一系列的判斷以確保流程無誤。

接下來結合圖中的操作界面,我來講一下這4個步驟每一步的詳細操作和判斷邏輯。而第一步添加/刪除操作節點、網關、流轉線的交互邏輯這里就沒必要展開說了,我們的主要目的是說說功能邏輯和判斷邏輯,所以直接從第二步講起。

通過上圖中下方的彈窗,我們可以看到一個流轉線的流轉條件是由多個條件共同組成規則,并且每個條件由4個元素組成:

  • a. 邏輯符號:包括并且和或者兩個選項,并且代表交集,或者代表合集;
  • b. 條件變量:在條件變量管理中配置的數據;
  • c. 比較符:有包含、不包含、等于、不等于、大于、大于等于、小于、小于等于。比較符的使用需要和開發同學溝通;
  • d. 變量值:在條件變量管理中配置的數據。

然后我們根據幾個例子來看一下,具體應該怎么配置:

例1:當項目是海外項目時由分管領導審批,非海外項目由部門負責人審批。

由于只有2個審批人參與,所以我們需要配置2條流轉線和其流轉條件。

在第一個流轉線的流轉條件中先選擇“是否海外項目”這個條件變量,再選擇“包含”這個比較符,最后的變量值選擇“是”;在第二個流轉線的流轉條件中選擇“否”就行了。如下圖:

例2:當項目是海外項目且是一級項目時由分管領導審批,當項目是海外項目且是二級項目時部門負責人審批,當項目非海外項目時由總經理審批。

可以看出這時是由3個審批人參與了,所以需要配置3條流轉線和其流轉條件。和例1不同,這時有2個條件變量來參與流程的走向了。所以我們需要配如下3個條件

但問題來了,有2個條件變量,各有2個條件值,實際項目會根據排列組合可以得出4種情況:

  1. 是海外項目,且一級項目
  2. 是海外項目,且二級項目
  3. 非海外項目,且一級項目
  4. 非海外項目,且二級項目

我們只配了3種情況,如果出現第4種情況時或者我配漏了,流程由于找不到滿足的流轉條件,就會直接掛起。

為了不讓流程掛起,我們就需要引入默認流轉這個功能(在操作頁面的流轉條件旁邊),我們可以將其中一個流轉條件設置為默認流轉,這樣第4種情況找不到滿足的條件時,就會默認走入這一條流轉條件。

同時默認除了可以實現邏輯更嚴密的目的,還有一個好處就是讓配置過程更簡便,我只需要配前兩條流轉條件就行,第3條直接設置為默認流轉,就不用再配什么流轉條件了,在條件變量很多的情況下就顯得非常好用了。

例3:前面我們看的都是條件之間是并且的關系,接下來我們看一下或者的關系。

當項目是海外項目或者是一級項目時由分管領導審批,非海外項目或者是二級項目時由部門負責人審批。

這個例子很簡單,只需要這樣配就行了:

同例1一樣,同樣有2個條件變量,各有2個條件值,實際項目也會根據排列組合可以得出4種情況:

  1. 是海外項目,且一級項目
  2. 是海外項目,且二級項目
  3. 非海外項目,且一級項目
  4. 非海外項目,且二級項目

情況1、2、3的項目會走流轉線1,情況4的項目會走流轉線2。

但仔細想一想,情況2的項目也滿足流轉線2的條件二,那為什么不走流轉線2呢?這里面還有一個隱藏邏輯,當邏輯比較符是或者時,出現兩個流轉線的流轉條件有交集時,系統需要從上往下判斷,也就是先判斷流轉線1內的條件一是否滿足,再判斷條件二是否滿足,然后再判斷流轉線2的條件一和條件二是否滿足。

所以當情況2的項目走到流轉線1的條件一時就發現滿足了,也就不需要再往下找流轉線2的條件二了。

例4:我們來看一個復雜的配置情況,只有2個審批人,但是有3個條件變量,每個條件變量各有2個條件值,但混合并且和或者的情況:

由于有3個條件變量和各有2個條件值,實際項目可得出8種項目:

  1. 是海外項目,且一級項目,且工期大于15天
  2. 是海外項目,且一級項目,且工期小于等于15天
  3. 是海外項目,且二級項目,且工期大于15天
  4. 是海外項目,且二級項目,且工期小于等于15天
  5. 非海外項目,且一級項目,且工期大于15天
  6. 非海外項目,且一級項目,且工期小于等于15天
  7. 非海外項目,且二級項目,且工期大于15天
  8. 非海外項目,且二級項目,且工期小于等于15天

以上各類情況流轉至流轉線如下:

2)流程模型配置–操作節點配置界面

操作節點也就是圖中“部門負責人審批”、“分管領導審批”等。與上面流轉線配置頁面大部分相同,不同的地方是最下面排節點屬性配置的字段有些差別。

當流程走向正確的流轉線之后,就會來到操作節點,所以我們需要為其配置處理人、操作等,才能讓流程走向下一個節點。

我們先看處理人配置彈窗。如圖所示,我們可以配置多條處理人數據,每條處理人需要先選擇角色類型(矩陣人員或者固定人員),再選擇對應的角色,下方就會帶出可能參與審批的人員。

矩陣人員前面的案例已經講過,會由條件變量去判斷具體的審批人,這里就不多說了;固定人員就是固定的一個人去審批,沒有條件變量參與判斷。

需要注意的是審批模式的或簽和會簽。當處理人配置了多個時,如圖中,可能參與審批的人有張三、李四、趙六,如果是或簽則需要他們3人其中一人審批通過即可,因為流程會同時流轉到他們3人處,;如果是會簽,則需要他們3人都通過后,流程才會流轉到下一節點。

然后自動完成條件可多選也可不選,當前處理人可能在前面的操作節點中已經存在了并且已經通過了,這里可以不用再次審批;如果處理人是發起人時也可自動通過。設置這個條件的目的是為了加快流程的審批,減少一些不必要的操作。

最后是操作設置,在工作流引擎中勾選了當前審批人可以進行哪些操作后,該功能將在業務系統中展示并使用,這一點需要與開發同學溝通清楚。具體操作按鈕的邏輯如下:

  • 提交:該按鈕在提交節點中默認選中;提交后則開始審批流,并流轉到下一個節點
  • 通過:點擊后當前節點通過,并流轉到下一個節點
  • 駁回:當前節點不通過,點擊后流轉到提交人處,需重新提交流程
  • 退回:當前節點不通過,但不是流轉到提交人處,而是退回到上一個節點
  • 如果上一個節點是并審,則需要所有人再次通過;如果該節點是并審,退回后再次流轉則不需要其他人通過
  • 撤回:如果當前節點通過,流轉到下一節點且未通過時,可撤回后重新處理
  • 轉辦:將流程轉給指定人選來處理(前提是該指定人有功能權限)
  • 終止:可直接將當前流程終止,如需操作則要再次提交

說完了操作節點屬性配置有哪些功能后,我們再來看幾個邏輯問題:

1.如果處理人配置的是矩陣人員,而其角色對應條件變量中在實際發生的流程里沒有時怎么辦?

比如我先設置了一個角色叫項目經理,條件變量選的是項目等級,張三負責一級項目,李四負責二級項目;然后有個操作節點叫項目經理審批,選擇了項目經理這個角色,。但是實際提交的立項流程的表單中沒有項目等級這個字段,那實際流程都跑到這個節點了但是又找不到條件變量來判斷該由誰去處理該怎么辦。

這時有2種處理方式,1是直接將流程掛起,2是默認由角色中配置的第一個人員審批,兩種處理各有利弊。

2.同一個條件變量,如果在流轉條件中設置了,又在矩陣人員中設置并配到了操作節點會怎樣?

這種配法倒不會讓流程掛起,也沒有邏輯性的問題,但是會讓流轉條件沒有存在的意義了,為了更簡化直接配一個操作節點就行了。

4. 流程版本管理

配置完一個完整的流程模型后,我們需要部署。但是一個模型可能前后會進行多次修改,每次修改就需要部署一次,所以一個模型會有多個版本,我們也就需要一個列表來對這些版本進行查看和管理。

更為重要的問題是,一個流程實例(實際發生的流程)可能會經歷較長的時間才能審核完,有多個流程實例都在運行中時,所有完成的時間你沒法預估,可能這個流程實例走完了下一個又發生了。但這時你又有修改流程的需求,總不可能把流程暫停了不讓大家發起吧。

所以就引入了流程版本的概念,可能多個版本共存。比如現在是版本1有10個流程實例在運行中,你在0點改了流程模型并且部署了版本2,那從0點以后發生的流程都是走的版本2,但不會影響之前運行中的10個流程,那10個流程還是走的版本1。

如果這時你又說那10個流程實例走的是錯誤的版本,需要走流程2,可以將這10個流程實例直接終止,讓他們重新發起流程就行了。

所以我們可以看到每個流程版本都有運行中、掛起中、已完成的數據統計(掛起中的數據怎么處理在后文中講解)

5. 流程監控管理

該列表是所有發生過的和正在發生的流程實例的集合展示,點擊列表我們可以進入下一頁查看其執行詳情:

流程執行詳情頁主要目的是為查看某一條流程的詳細情況,并對其進行相關處理;如因為條件變量、處理人配置等原因未找到正確的處理人,流程將會掛起,此處可選擇正確的處理人,以將流程正常運行完結。

本文由 @橘鉆 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Pixabay,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫的超級好?。?!

    來自上海 回復
  2. 文章寫的很用心,不過針對角色的處理有點復雜。角色管理應該納入到組織管理里,和流程引擎完全解耦,對角色的設置不用考慮流程引擎的因素。流程引擎里節點處理人的設置應該分為組織架構節點、角色、制定人員即可,另外節點審批需要考慮百分比會簽的情況。

    來自上海 回復
    1. 放到組織管理里的也有一個角色,但是和流程引擎里用到的那個角色是兩個獨立的角色,你可以看一下我的第一篇文章中的場景一和場景二寫了這兩個角色的區別用途;
      百分比這個功能做細了確實可以有,比如SaaS一類的,不過我們公司當時還沒有業務需求。

      來自重慶 回復
    2. 我看了,我的意思是標準BPM的做法要保留,依然要去關聯組織/角色/人員(會有按照角色去審批的場景),如果有其他需求在現有標準NPM的基礎上拓展就行。
      你這個角色相當于是為了維護提交人所屬部門的所屬區域/事業部總監、分管VP,同時也維護了每個部門的負責人。但是你這種設計無疑就造成了數據冗余和極高的數據維護成本。首頁部門負責人直接獲取組織架構的就可以,不需要額外維護一個表。針對分管VP,是需要維護一個表,不過VP一般都是條線分管,在vp分管的頂級部門節點維護就行,查詢部門所屬分管VP時支持向上查詢就可以滿足需求,區域/事業部總監同理。

      來自上海 回復
  3. 很專業了

    來自中國 回復