這是我的專案中使用的一套關於工作流和審批流的配置，算是比較簡單的，這裡只寫其中比較核心的思路，算是對之前工作的乙個技術總結吧。
以下是資料庫設計；後面再跟據例項分析每個表的作用。
首先是流程配置表：
如果需要用到乙個工作流就要先配置，test_workflow_configuration就需要存入該流程的基本資訊
test_workflow_details需要存入該流程的工作流配置，需要幾級審核等資訊
然後是流程記錄表：
這個表儲存的是流程記錄，每個流程送審之後都會存在這條記錄中，一級審核完在插入下一級記錄
最後是申請單表：
這個表儲存的是申請單資訊
ps：這裡有一些關聯設計的表被我省略了，只說最核心的思路，下面舉個栗子
現在有乙個工單申請需求
首先這個申請單記錄記錄應該儲存在test_order中，包括單據號，建立日期，建立人等資訊（相關業務明細另外建表）
然後配置審核流程
test_workflow_configuration中應該存入這個流程的基本資訊
test_workflow_details中設定工作流配置（附圖1）
接下來流程開始
第一步：該工單填寫完畢，送審
當點選【送審】按鈕時後台需要以下操作：
1.將test_order中的status改為1送審狀態
2.流程記錄表test_workflow_records插入工作流第一條記錄（主管審核）
test_workflow_details裡的post_id是主管崗位id，test_workflow_records裡需要的是主管這個崗位上的人的id，作為assignee_id（該工作流受理人id）
第二步：主管登入系統，進入審批頁面，跟據主管id/既是當前使用者id（assignee_id）和（is_audit = 0）可以展示當前主管需要審核的所有申請。
主管點選【審核】按鈕，可根據document_code（申請單據號）展示當前申請的所有詳細資訊，選擇【通過】/【駁回】，並填寫意見等，最後點選【提交】。
此時後台需要做以下操作：
1.更新流程記錄為已審核狀態（is_audit=1）
2.跟據workflow_id查詢該流程分為多少步（幾條記錄就是幾步），取出當前記錄的flow_serialnumber，判斷是否是最後一步
若是最後一步 ｛
判斷當前記錄是否通過
若通過｛
編寫審核通過的業務處理**
否則 ｛
直接更新test_order申請狀態為駁回（status=3）
若不是最後一步｛
再判斷當前記錄是否審核通過
若不通過｛
直接更新test_order申請狀態為駁回（status=3）
若通過（這個栗子就走這種情況）
取出flow_serialnumber，+1，查詢下乙個節點（經理審核）
流程記錄表test_workflow_records插入工作流第二條記錄（經理審核）
插入處理方式同上
第三步：同第二步，此時流程走到經理這裡，流程繼續進行。
附上幾張截圖：
圖1：工作流配置
圖2：審核記錄詳情
審批流程設計方案學習
一篇總結得不錯的文章，適合剛接觸和入手流程引擎的童鞋，如果需要深入的去配置規則的話就需要根據實際的業務場景了。一套完整的審批流程 工作流程大體上包括 1 流程定義 2 步驟定義 觸發規則 操作人 執行動作 發起申請 撤回 執行操作 任務通知 郵件提醒 字段更新 轉移資料 轉換表單 傳送介面 3 步驟...
審批流程設計方案 介紹（一）
1 流程就是某一詳細的業務流程 請假審批流程，財務報銷審批流程 2 步驟 活動或者節點 就是一種特定業務型別的封裝 一套完整的審批流程 工作流程大體上包含 1 流程定義 2 步驟定義 觸發規則 操作人 執行動作 發起申請 撤回 執行操作 任務通知 郵件提醒 字段更新 轉移資料 轉換表單 傳送介面 3...
審批流程設計方案 介紹（一）
1 流程就是某一詳細的業務流程 請假審批流程，財務報銷審批流程 2 步驟 活動或者節點 就是一種特定業務型別的封裝 一套完整的審批流程 工作流程大體上包含 1 流程定義 2 步驟定義 觸發規則 操作人 執行動作 發起申請 撤回 執行操作 任務通知 郵件提醒 字段更新 轉移資料 轉換表單 傳送介面 3...