以前沒怎麼接觸過工做流,在網上參考了一些相關的案例。任務着急,並無太看透徹就開始coding了。這套工做流引擎並不複雜,主要是應對簡單的流程運轉及權限控制。數據庫
咱們主要用在售後等工單系統中,一張工單。主要實現瞭如下功能框架
1.工做流程的界面設計spa
2.流程根據設定的路線流轉,設定每一個節點的權限,控制流程的編輯及訪問,設定流程中每一個用戶對應每一個字段的權限設計
3.流程分支的自動判斷blog
4.流程的接單及駁回內存
這是工做流引擎中涉及到的全部表了。路由
B開頭的爲主表,L爲關聯表,R爲引用表存儲些類型之類的常量。博客
主要的流程設計只保存在兩張表中。流程節點表以及路由表。
爲了使工做流與業務結合,咱們用到了流程實例表,以及活動記錄表。權限控制
每開啓一個流程,便建立一條流程實例,每一次流程節點的變更,建立一條活動記錄。工作流
在活動記錄表中,設置了接單人字段belongUser,每條節點的編輯以前須要有接單人。能夠在提交上一節點的時候指定下一節點的接單人或者點擊接單來手動接單。這樣設計來避免多人同時編輯同一個節點。
設計圖使用的是gooFlow框架,功能比較簡單,可是恰巧適合我這種並不複雜的工做流系統。你們有興趣的能夠下載下來玩一下,Demo和Api講解的也比較詳細
對於多個分支的狀況,有用戶操做的爲手動選擇下一流程。
無操做界面的話須要須要在路由裏寫上相應的條件語句,來判斷接下來要走那一條路由。 以換貨流程爲例:
在建立退貨訂單的時候就會自動建立一條退貨的售後工單,同時須要傳入支付方式及換貨單的狀態給工做流。
我將每一個工做流封裝爲一個dto,裏面包括此工做流的全部相關信息,系統啓動時加載到內存中,在修改工做流程時刷新。
上圖只保存了工做流的內容,關聯到業務的話,還須要一個工做流上下文的類。此類中應該包括工做流當前的狀態等信息,同時提供一些基本的擴展方法。
下圖爲工做流上下文類的結構
寫下此文一來爲了鍛鍊一下本身寫博客的能力以及表達能力。同時也但願個位前輩可以指正紕漏,提出建議!