簡介這套OA辦公自動(dòng)化系統(tǒng)源碼面向希望自建審批流程、研究辦公系統(tǒng)架構(gòu)的開發(fā)者與中小企業(yè)技術(shù)團(tuán)隊(duì)提供可二次開發(fā)的基礎(chǔ)工程。壓縮包共2000個(gè)文件、約43.54MB以gif和png等界面圖片、cs業(yè)務(wù)代碼、aspx頁面、js腳本、css樣式及dll程序集、doc說明文檔為主另含數(shù)據(jù)庫與配置文件覆蓋Web端、移動(dòng)端適配、業(yè)務(wù)邏輯層和公共工具模塊等組成部分。已有6933人學(xué)習(xí)下載說明其在同類OA源碼中具備一定參考價(jià)值。讀者可從中了解審批流程如何落到業(yè)務(wù)規(guī)則與頁面交互中學(xué)習(xí)分層組織、數(shù)據(jù)庫訪問、角色權(quán)限與表單處理等實(shí)現(xiàn)思路并在此基礎(chǔ)上調(diào)整流程節(jié)點(diǎn)、擴(kuò)展辦公模塊適合作為辦公自動(dòng)化項(xiàng)目起步或改造的代碼參照。1. 一套OA源碼真正的分水嶺審批流程能不能由業(yè)務(wù)自己改很多團(tuán)隊(duì)拿到一套OA源碼第一件事是換登錄頁的 Logo第二件事是改首頁配色改完發(fā)現(xiàn)真正卡住交付的地方根本不在前端。判斷這套代碼值不值得深挖看一個(gè)點(diǎn)就夠?qū)徟鞒淌菍懰涝趇f-else里的還是抽成了「流程定義 節(jié)點(diǎn) 連線 條件表達(dá)式」的數(shù)據(jù)。前一種方案業(yè)務(wù)提一句「報(bào)銷超過五千要加一級總監(jiān)審批」你就得改代碼、走測試、發(fā)版、停機(jī)后一種方案運(yùn)維在后臺把節(jié)點(diǎn)拖一下、把條件表達(dá)式改一行保存即生效在途單據(jù)還按舊版本跑完。這套辦公自動(dòng)化系統(tǒng)源碼的價(jià)值就在后者——它把審批流程做成了可配置的元數(shù)據(jù)而不是一段業(yè)務(wù)邏輯。適合三類人要給內(nèi)部搭一套 OA 的開發(fā)者、要交付審批模塊的外包團(tuán)隊(duì)、想拿一套完整流程引擎當(dāng)參考實(shí)現(xiàn)的中高級工程師。2. 拆開這套OA的技術(shù)骨架審批引擎怎么把一張流程圖變成數(shù)據(jù)庫記錄上手之前先別急著run花二十分鐘把數(shù)據(jù)模型看清楚后面配流程、查問題會(huì)省掉大量時(shí)間。審批引擎的本質(zhì)只有一句話把用戶在后臺畫的圖翻譯成幾張表之間的狀態(tài)遷移運(yùn)行時(shí)只認(rèn)表不認(rèn)圖。所以真正決定這套 OA 能改多深的是表的粒度和字段設(shè)計(jì)不是前端那個(gè)拖拽畫布做得多漂亮。2.1 流程定義、節(jié)點(diǎn)、連線三層數(shù)據(jù)結(jié)構(gòu)決定流程能改多深我一般會(huì)先翻流程相關(guān)的建表腳本通常能看到這么幾張核心表流程定義表、節(jié)點(diǎn)表、連線表、實(shí)例表、任務(wù)表、審批記錄表。前三張是「設(shè)計(jì)態(tài)」后三張是「運(yùn)行態(tài)」這條邊界必須劃清楚——設(shè)計(jì)態(tài)改的是模板運(yùn)行態(tài)記的是某一張單據(jù)走過的痕跡兩者混在一起改流程就會(huì)把在途單據(jù)帶崩。設(shè)計(jì)態(tài)三張表的關(guān)系是一個(gè)流程定義oa_process_def下掛多個(gè)節(jié)點(diǎn)oa_process_node節(jié)點(diǎn)之間用連線oa_process_edge連接連線上的條件表達(dá)式?jīng)Q定走哪條路。節(jié)點(diǎn)表里存的不只是名字還有節(jié)點(diǎn)類型開始、審批、抄送、條件網(wǎng)關(guān)、結(jié)束和審批人策略指定人、按角色、按部門主管、發(fā)起人自選、取表單字段值。審批人策略這一列是整張表的靈魂它決定了「誰能審」這個(gè)業(yè)務(wù)問題能不能不改代碼就調(diào)整。運(yùn)行態(tài)里實(shí)例表oa_process_instance記錄一張單據(jù)當(dāng)前停在哪個(gè)節(jié)點(diǎn)、用的是哪個(gè)版本的流程定義任務(wù)表oa_task記錄每個(gè)人的待辦審批記錄表oa_approve_log記流水。這里有個(gè)關(guān)鍵設(shè)計(jì)實(shí)例表里必須存def_version而不是只存def_id。只存定義 ID 的系統(tǒng)業(yè)務(wù)一改流程所有在途單據(jù)立刻按新流程圖走原來走到第三級的單子可能突然找不到下一節(jié)點(diǎn)——這是老系統(tǒng)里最常見的翻車點(diǎn)之一。表名作用關(guān)鍵字段改動(dòng)風(fēng)險(xiǎn)oa_process_def流程模板code、version、status低新增版本即可oa_process_node節(jié)點(diǎn)與審批人策略node_key、node_type、approver_type中改策略影響新實(shí)例oa_process_edge連線與條件from_key、to_key、condition_expr中高條件寫錯(cuò)直接斷流oa_process_instance單據(jù)實(shí)例biz_key、current_node、def_version高動(dòng)結(jié)構(gòu)要考慮存量oa_task待辦任務(wù)assignee、task_status高涉及并發(fā)與重復(fù)生成oa_approve_log審批流水a(chǎn)ction、opinion、op_time低只追加不修改看懂這張表你就能預(yù)判這套 OA 的上限節(jié)點(diǎn)表如果有approver_type和approver_value兩列說明審批人是可配置的如果只有approver_id那所謂「自定義流程」大概率只是自定義節(jié)點(diǎn)順序人還是得一個(gè)個(gè)指定業(yè)務(wù)量一大就廢。2.2 從源碼目錄到本地跑通最小啟動(dòng)路徑目錄結(jié)構(gòu)一般長這樣先認(rèn)幾個(gè)關(guān)鍵位置別一上來就全局搜索# 典型的分層結(jié)構(gòu)具體目錄名以你手上的包為準(zhǔn) oa-system/ ├── oa-common/ # 工具類、統(tǒng)一返回、常量 ├── oa-framework/ # 權(quán)限、攔截器、數(shù)據(jù)源配置 ├── oa-flow/ # 流程引擎核心定義解析、任務(wù)分發(fā)、條件求值 ├── oa-admin/ # 后臺管理端接口流程設(shè)計(jì)、用戶角色 ├── oa-web/ # 前端工程 ├── sql/ # 建表腳本 初始化數(shù)據(jù) └── doc/ # 部署說明、接口清單啟動(dòng)順序我一般固定成四步建庫導(dǎo)腳本、改配置、起后端、起前端。別跳過第一步直接起服務(wù)很多包在啟動(dòng)時(shí)會(huì)做流程定義的校驗(yàn)庫是空的直接拋異常報(bào)錯(cuò)信息還特別繞。# 1. 建庫 mysql -uroot -p -e CREATE DATABASE oa_flow DEFAULT CHARSET utf8mb4; # 2. 導(dǎo)入結(jié)構(gòu)與種子數(shù)據(jù)注意順序先結(jié)構(gòu)后數(shù)據(jù) mysql -uroot -p oa_flow sql/schema.sql mysql -uroot -p oa_flow sql/init_data.sql # 3. 改配置文件里的數(shù)據(jù)源、Redis、文件上傳路徑 # 重點(diǎn)確認(rèn) server.port 和 context-path前端代理要對得上 # 4. 起后端Maven 工程 mvn clean package -DskipTests java -jar oa-admin/target/oa-admin.jar --spring.profiles.activedev# 5. 起前端注意接口代理指向后端實(shí)際端口 cd oa-web npm install --registryhttps://registry.npmmirror.com npm run dev參數(shù)上要盯住三個(gè)地方數(shù)據(jù)庫連接串的時(shí)區(qū)參數(shù)不加serverTimezone在部分驅(qū)動(dòng)版本下會(huì)報(bào)時(shí)間錯(cuò)亂審批時(shí)間差八小時(shí)就是這么來的、文件上傳的臨時(shí)目錄流程附件走這里路徑不存在會(huì)導(dǎo)致提交審批時(shí)靜默失敗、以及定時(shí)任務(wù)開關(guān)有些包默認(rèn)開著任務(wù)補(bǔ)償掃描本地調(diào)試會(huì)莫名多出一批任務(wù)。提示先跑通「發(fā)起一條最簡單的單人審批」再動(dòng)流程設(shè)計(jì)器。設(shè)計(jì)器依賴的接口多一上來就調(diào)它報(bào)錯(cuò)分不清是引擎問題還是前端代理問題。2.3 初始化數(shù)據(jù)里的角色與用戶別拿來就用種子數(shù)據(jù)通常塞了幾個(gè)內(nèi)置賬號、幾個(gè)角色、一棵部門樹。新手最容易犯的錯(cuò)是直接拿admin跑全流程跑通了就以為沒問題——admin在很多實(shí)現(xiàn)里帶超級權(quán)限會(huì)繞過審批人解析邏輯等換成普通賬號立刻卡在「找不到審批人」。正確做法是先確認(rèn)三件事角色表里有沒有「部門主管」這類動(dòng)態(tài)角色的定義部門樹的leader_id字段是否填了值用戶與角色的關(guān)聯(lián)是不是按租戶或按組織隔離的。這三樣缺一個(gè)后面配「按部門主管審批」就一定解析出空。-- 檢查部門主管是否配齊返回空說明這條鏈路會(huì)斷 SELECT d.id, d.name, d.leader_id, u.name AS leader_name FROM sys_dept d LEFT JOIN sys_user u ON u.id d.leader_id WHERE d.leader_id IS NULL OR d.leader_id 0;這條 SQL 我每次接手新包都會(huì)跑一遍返回哪怕一行也要先把主管補(bǔ)上再往下走。原因很簡單審批人策略里「按部門主管」是最常用的一個(gè)它取的就是發(fā)起人所在部門往上找的第一個(gè)有主管的節(jié)點(diǎn)中間斷一層任務(wù)就生成不出來而報(bào)錯(cuò)往往只是一句「審批人為空」不看代碼根本不知道斷在哪。3. 畫一條能跑通的審批流節(jié)點(diǎn)類型、審批人策略與條件分支流程設(shè)計(jì)器是這套 OA 的門面但真正要理解的是它背后那幾個(gè)配置項(xiàng)。會(huì)配節(jié)點(diǎn)類型、會(huì)寫條件表達(dá)式、會(huì)選審批人策略這三件事過關(guān)日常九成的流程需求你都能自己接住不用回頭找開發(fā)。3.1 節(jié)點(diǎn)類型與審批人策略的參數(shù)對照節(jié)點(diǎn)類型不要貪多先把五種用熟開始、審批、條件網(wǎng)關(guān)、抄送、結(jié)束。很多包還會(huì)提供并行網(wǎng)關(guān)、子流程、定時(shí)節(jié)點(diǎn)那些屬于進(jìn)階第一版流程別碰出問題排查成本太高。審批人策略是重點(diǎn)常見實(shí)現(xiàn)里大概有這么幾類我按使用頻率排策略標(biāo)識含義取值來源典型場景USER指定具體人用戶 ID 列表財(cái)務(wù)復(fù)核、法務(wù)審核ROLE按角色角色編碼財(cái)務(wù)角色審報(bào)銷DEPT_LEADER部門主管發(fā)起人部門樹請假、外出FORM_FIELD取表單字段表單里的用戶字段報(bào)銷單填的「項(xiàng)目負(fù)責(zé)人」STARTER_SELECT發(fā)起時(shí)自選運(yùn)行時(shí)選擇臨時(shí)加簽、指定協(xié)作人INITIATOR發(fā)起人本人當(dāng)前登錄人銷假確認(rèn)、補(bǔ)錄選策略有個(gè)原則能用FORM_FIELD就別用USER。指定具體人的流程人一離職流程就廢綁到表單字段上誰填單誰負(fù)責(zé)選人責(zé)任清晰還不會(huì)過期。部門主管同理綁部門樹比綁人穩(wěn)得多。節(jié)點(diǎn)上除了審批人還有兩個(gè)參數(shù)要留意multi_mode會(huì)簽還是或簽和allow_transfer是否允許轉(zhuǎn)辦。這兩個(gè)在節(jié)點(diǎn)配置里往往是個(gè)下拉框選錯(cuò)了要到運(yùn)行階段才暴露配的時(shí)候就得定下來。3.2 條件表達(dá)式怎么寫才不會(huì)把流程寫死條件網(wǎng)關(guān)的連線表達(dá)式是整套系統(tǒng)最容易出事故的地方。表達(dá)式求值一般走兩種實(shí)現(xiàn)一種是內(nèi)置的表達(dá)式引擎常見是 SpEL 或 Aviator 這類另一種是前端拼好的 JSON 條件樹。不管哪種寫的時(shí)候守住三條只引用表單里確實(shí)存在的字段、只做簡單比較、每個(gè)分支都有兜底。{ nodeKey: gw_amount, nodeType: CONDITION, edges: [ { to: node_manager, priority: 1, conditionExpr: #amount 5000 }, { to: node_director, priority: 2, conditionExpr: #amount 5000 #amount 50000 }, { to: node_ceo, priority: 99, conditionExpr: true } ] }這段配置里priority是匹配順序引擎從上往下求值命中第一條就走所以兜底那條必須放最后且條件恒真。conditionExpr里用#amount引用表單變量變量名要和表單字段的field_key完全一致大小寫都不能差。我見過最典型的一類事故是表單字段叫totalAmount表達(dá)式里寫成#total_amount求值返回 null所有單子都掉進(jìn)兜底分支全公司報(bào)銷直達(dá) CEO——上線當(dāng)天就被投訴。表達(dá)式能力要克制。不要在條件里調(diào)方法、算日期差、查數(shù)據(jù)庫那些看著方便實(shí)際是把業(yè)務(wù)邏輯埋進(jìn)了配置里別人接手時(shí)根本找不到。日期區(qū)間、金額匯總這類判斷在表單提交時(shí)就算好存成字段條件里只做數(shù)值比較這是最省心的做法。3.3 一次完整的請假流程配置實(shí)操拿請假走一遍把前面的東西串起來。需求是三天以內(nèi)主管審批三到七天主管加人事七天以上再加一級總監(jiān)結(jié)束前抄送考勤員。第一步建流程定義填code、name、綁定請假表單狀態(tài)先存草稿。第二步拖節(jié)點(diǎn)開始 → 主管審批 → 條件網(wǎng)關(guān) → 人事審批 → 條件網(wǎng)關(guān)2 → 總監(jiān)審批 → 抄送 → 結(jié)束。第三步配連線條件。[ { from: start, to: node_leader, conditionExpr: true }, { from: node_leader, to: gw_days, conditionExpr: true }, { from: gw_days, to: node_hr, conditionExpr: #days 3, priority: 1 }, { from: gw_days, to: node_cc, conditionExpr: true, priority: 99 }, { from: node_hr, to: gw_days2, conditionExpr: true }, { from: gw_days2, to: node_director, conditionExpr: #days 7, priority: 1 }, { from: gw_days2, to: node_cc, conditionExpr: true, priority: 99 } ]第四步配審批人node_leader用DEPT_LEADERnode_hr用ROLE綁人事角色node_director用USER指定具體人但在生產(chǎn)環(huán)境建議換成角色。第五步發(fā)布版本號走v1。保存后先別急著用真實(shí)賬號測用測試庫造三個(gè)人發(fā)起人、主管、人事。發(fā)起一條days2的單子看是否停在主管節(jié)點(diǎn)再發(fā)days5的看主管審?fù)晔欠裆扇耸氯蝿?wù)最后發(fā)days10的走完全鏈路。三條都通這條流程才叫配好了。注意條件網(wǎng)關(guān)后面如果有兩條連線條件同時(shí)為真且priority相同不同引擎的處理不一樣有的拋異常有的隨便走一條。發(fā)布前把優(yōu)先級顯式寫清楚別依賴默認(rèn)值。4. 流轉(zhuǎn)的核心動(dòng)作任務(wù)生成、會(huì)簽或簽、回退與轉(zhuǎn)辦流程配好只是把路鋪出來真正決定這套 OA 好不好用的是運(yùn)行時(shí)那幾個(gè)動(dòng)作審批通過后任務(wù)怎么生成、多個(gè)審批人是并行還是串行、審錯(cuò)了怎么退回去、人出差了怎么轉(zhuǎn)給別人。這幾塊邏輯寫得糙的系統(tǒng)業(yè)務(wù)用一周就開始罵人。4.1 任務(wù)分發(fā)與并發(fā)控制別讓同一條單子生成兩份待辦審批通過后的核心動(dòng)作是「找下一個(gè)節(jié)點(diǎn) → 解析審批人 → 生成任務(wù) → 更新實(shí)例當(dāng)前節(jié)點(diǎn)」這四步必須在同一個(gè)事務(wù)里。我見過不少包為了性能把這四步拆開結(jié)果用戶手快點(diǎn)了兩次通過任務(wù)表里出現(xiàn)兩條相同的待辦兩個(gè)人各審一遍單據(jù)直接跳過一級。// 任務(wù)完成與流轉(zhuǎn)的核心骨架重點(diǎn)是事務(wù)邊界和冪等控制 Transactional(rollbackFor Exception.class) public void completeTask(Long taskId, String action, String opinion, String operator) { // 1. 悲觀鎖住任務(wù)行防止并發(fā)重復(fù)提交 OaTask task taskMapper.selectForUpdate(taskId); if (task null || !TaskStatus.PENDING.equals(task.getTaskStatus())) { throw new BizException(任務(wù)已處理請刷新后重試); } // 2. 寫審批流水先落痕再改狀態(tài)出了問題能追溯 approveLogMapper.insert(buildLog(task, action, opinion, operator)); // 3. 改任務(wù)狀態(tài)不用物理刪除保留處理記錄 taskMapper.updateStatus(taskId, TaskStatus.DONE); // 4. 解析下一節(jié)點(diǎn)并生成任務(wù) ProcessInstance inst instanceMapper.selectById(task.getInstanceId()); ListString nextNodes flowResolver.resolveNext(inst, task.getNodeKey(), task.getVariables()); for (String nodeKey : nextNodes) { ListString assignees assigneeResolver.resolve(inst, nodeKey); if (assignees.isEmpty()) { throw new BizException(節(jié)點(diǎn)[ nodeKey ]未解析到審批人請檢查角色或部門主管配置); } taskService.batchCreate(inst, nodeKey, assignees); } // 5. 更新實(shí)例當(dāng)前節(jié)點(diǎn)多節(jié)點(diǎn)并行時(shí)不做覆蓋改成列表 instanceMapper.updateCurrentNode(inst.getId(), nextNodes); }selectForUpdate這一行是關(guān)鍵少了它就是并發(fā)雙審。assigneeResolver解析為空時(shí)直接拋異常而不是靜默跳過這是讓問題在測試階段暴露、而不是上線后被業(yè)務(wù)發(fā)現(xiàn)。第五步在多節(jié)點(diǎn)并行時(shí)不能用單個(gè)字段覆蓋很多包在這里偷懶只存一個(gè)current_node一遇到并行網(wǎng)關(guān)狀態(tài)就亂改起來還得動(dòng)表結(jié)構(gòu)。批量生成任務(wù)時(shí)還有個(gè)細(xì)節(jié)去重。同一節(jié)點(diǎn)同一處理人如果因?yàn)榕渲弥貜?fù)解析出兩次batchCreate里要按instance_id node_key assignee做一次去重否則待辦列表里會(huì)出現(xiàn)兩條一模一樣的記錄。4.2 會(huì)簽、或簽、加簽三種多人審批的差別多人審批這塊配置項(xiàng)少但語義差別大配錯(cuò)了不是報(bào)錯(cuò)是流程卡住或者被少數(shù)人通過。會(huì)簽ALL是所有人都要審有一條駁回就整節(jié)點(diǎn)駁回全部通過才往下走。實(shí)現(xiàn)上通常是給每個(gè)人生成一條任務(wù)實(shí)例上記一個(gè)計(jì)數(shù)器全部完成才流轉(zhuǎn)。或簽ANY是任一人處理即可其余任務(wù)作廢實(shí)現(xiàn)上要么生成多條任務(wù)靠搶鎖要么只生成一條共享任務(wù)。加簽是在已生成的任務(wù)上追加處理人分前加簽和后加簽前加簽是讓指定人先審審?fù)暝倩氐皆瓕徟撕蠹雍炇窃瓕徟藢復(fù)暝僮屩付ㄈ丝?。這套邏輯實(shí)現(xiàn)成本不低很多源碼包只做了「追加任務(wù)」沒做「回到原位」用起來會(huì)有一種怪怪的感覺——加簽人審?fù)炅鞒讨苯油伦吡嗽瓕徟朔炊鴽]審。{ nodeKey: node_finance, nodeType: APPROVAL, multiMode: ALL, rejectStrategy: ONE_VOTE_VETO, allowAddSign: true, addSignType: BEFORE, approverType: ROLE, approverValue: finance }rejectStrategy這一項(xiàng)要看引擎實(shí)現(xiàn)有的叫ONE_VOTE_VETO一票否決有的叫BACK_TO_INITIATOR直接退回發(fā)起人名字不同語義差很遠(yuǎn)配之前翻一遍求值代碼別信前端那個(gè)下拉框的文案。4.3 回退、撤回、轉(zhuǎn)辦的邊界條件回退是審錯(cuò)了退給上一步撤回是發(fā)起人自己把單子收回來轉(zhuǎn)辦是把待辦轉(zhuǎn)給別人。這三個(gè)動(dòng)作看著簡單邊界條件一堆回退要判斷目標(biāo)節(jié)點(diǎn)是否存在且在當(dāng)前路徑上。有些實(shí)現(xiàn)允許退到任意歷史節(jié)點(diǎn)挺好用但風(fēng)險(xiǎn)高——退到一個(gè)已經(jīng)過期的分支上后續(xù)條件求值可能拿不到當(dāng)時(shí)的變量流程就懸在那了。穩(wěn)妥的做法是只允許退到上一步或者退到發(fā)起人。撤回要判斷下一節(jié)點(diǎn)是否已被處理。已經(jīng)有人審過了就不能撤回否則等于繞過審批。這個(gè)校驗(yàn)必須在服務(wù)端做前端置灰不算數(shù)。轉(zhuǎn)辦要判斷接收人是否有該節(jié)點(diǎn)的審批權(quán)限。轉(zhuǎn)給一個(gè)沒有對應(yīng)角色的人任務(wù)能生成但點(diǎn)開報(bào)無權(quán)限用戶會(huì)以為系統(tǒng)壞了。-- 撤回前的前置校驗(yàn)確認(rèn)當(dāng)前節(jié)點(diǎn)沒有已完成的后續(xù)任務(wù) SELECT COUNT(1) FROM oa_task t JOIN oa_process_instance i ON i.id t.instance_id WHERE t.instance_id #{instanceId} AND t.task_status DONE AND t.node_key #{currentNodeKey};這條查詢返回大于零就說明后面已經(jīng)有人審過撤回按鈕必須禁用。把這段做成服務(wù)端的強(qiáng)校驗(yàn)比在前端藏按鈕靠譜得多——接口是能被直接調(diào)的。5. 上線前必查的五類問題審批流跑不通時(shí)的排查清單流程跑不通報(bào)錯(cuò)信息往往只有一句「操作失敗」光看日志很難定位。下面這五類是我在不同項(xiàng)目里反復(fù)遇到的按現(xiàn)象、原因、解決三段記遇到時(shí)照著對一遍比盲翻代碼快。5.1 現(xiàn)象提交成功但待辦列表空的審批人解析返回 null現(xiàn)象是單據(jù)提交回顯成功流程實(shí)例也建了但誰的待辦里都看不到。原因是審批人策略解析出空集合引擎拿到空列表后沒拋錯(cuò)直接跳過了任務(wù)生成實(shí)例停在第一個(gè)審批節(jié)點(diǎn)上。解決分三步先查實(shí)例表的current_node是否為空為空說明連節(jié)點(diǎn)都沒定下來看流程定義的開始節(jié)點(diǎn)連線有沒有配不為空就查該節(jié)點(diǎn)配置的approver_type逐類核對取值——ROLE看角色編碼是否存在、DEPT_LEADER看部門樹的leader_id、FORM_FIELD看表單里那個(gè)字段提交的值是不是空的。最后在assigneeResolver里加一條空集合拋異常的兜底讓問題提前暴露。5.2 現(xiàn)象會(huì)簽節(jié)點(diǎn)只生成一條任務(wù)節(jié)點(diǎn)明明配了會(huì)簽審批人解析出三個(gè)人但任務(wù)表里只有一條。原因通常是任務(wù)生成的去重邏輯寫錯(cuò)了維度把instance_id node_key當(dāng)成了唯一鍵同一個(gè)節(jié)點(diǎn)只允許一條任務(wù)后面兩個(gè)人直接被丟掉。解決是把去重維度改成instance_id node_key assignee同時(shí)檢查任務(wù)表上有沒有(instance_id, node_key, assignee)的唯一索引——有的話插入第二條會(huì)直接拋主鍵沖突沒拋就說明代碼層做了靜默忽略。另外確認(rèn)multi_mode的取值在解析時(shí)真的被讀到了有些包前端傳的是all后端枚舉是大寫ALL大小寫不一致就默認(rèn)走了或簽。5.3 現(xiàn)象流程改版后在途單據(jù)點(diǎn)開報(bào)「節(jié)點(diǎn)不存在」業(yè)務(wù)流程從三級審批改成兩級新版發(fā)布后改版前提交、還停在第三級的單據(jù)全部打不開。原因是實(shí)例表只存了流程定義 ID沒存版本號運(yùn)行時(shí)按 ID 去取最新版本的節(jié)點(diǎn)配置自然找不到舊節(jié)點(diǎn)。解決要在數(shù)據(jù)層做兩件事實(shí)例表補(bǔ)def_version字段發(fā)起時(shí)寫入當(dāng)時(shí)發(fā)布的版本號節(jié)點(diǎn)查詢按def_id version雙條件取不要只按def_id。存量數(shù)據(jù)補(bǔ)版本號時(shí)按實(shí)例創(chuàng)建時(shí)間去比對發(fā)布記錄取當(dāng)時(shí)生效的版本別一刀切填成當(dāng)前版本。這件事沒有后悔藥只能在設(shè)計(jì)階段就想好。5.4 現(xiàn)象回退之后條件分支走錯(cuò)方向單據(jù)從人事節(jié)點(diǎn)退回主管主管重新通過后本該走「三天以內(nèi)直接結(jié)束」的分支結(jié)果又進(jìn)了人事。原因是回退時(shí)清空了流程變量或者回退后重新求值時(shí)用的是節(jié)點(diǎn)局部變量而不是實(shí)例級變量#days取不到值條件全部不成立掉進(jìn)了兜底分支。解決是先確認(rèn)變量存在哪一層實(shí)例級變量在回退時(shí)不能清節(jié)點(diǎn)級變量可以清。條件表達(dá)式里的變量統(tǒng)一改成實(shí)例級引用表單提交時(shí)一次性寫入中間節(jié)點(diǎn)只讀不寫。如果引擎支持表達(dá)式調(diào)試把回退后那次求值的上下文打出來看一眼比猜快得多。5.5 現(xiàn)象本地一切正常部署后審批時(shí)間差八小時(shí)本地跑得好好的上服務(wù)器后審批記錄的時(shí)間全偏了八小時(shí)排序全亂。原因是數(shù)據(jù)庫連接的時(shí)區(qū)參數(shù)沒配或者應(yīng)用容器的默認(rèn)時(shí)區(qū)是 UTCJava 側(cè)new Date()和 MySQL 的NOW()差了八個(gè)小時(shí)。解決是兩頭對齊連接串加serverTimezoneAsia/ShanghaiJVM 啟動(dòng)參數(shù)加-Duser.timezoneAsia/Shanghai建表腳本里時(shí)間字段統(tǒng)一datetime而不是timestamp后者會(huì)二次轉(zhuǎn)換。改完記得把歷史數(shù)據(jù)的時(shí)區(qū)也核對一遍別只測新數(shù)據(jù)。注意這五條里前三條屬于設(shè)計(jì)問題改起來要?jiǎng)颖砘騽?dòng)代碼后兩條屬于配置問題改完就能生效。接手一套新包先按順序把五條過一遍能省掉上線后至少一半的返工。6. 把流程交給業(yè)務(wù)自己改版本管理、灰度發(fā)布與回歸驗(yàn)證流程能配之后下一個(gè)問題很快會(huì)來業(yè)務(wù)部門開始自己改流程改完直接在線上發(fā)布第二天出問題找不到是誰改的。這時(shí)候需要補(bǔ)的不是功能是流程發(fā)布本身的規(guī)范。我一般會(huì)強(qiáng)制三件事。第一流程定義只允許新增版本不允許原地改已發(fā)布的定義改完的版本狀態(tài)是草稿走一次「發(fā)布」動(dòng)作才生效發(fā)布人要留痕。第二版本切換做灰度同一流程編碼下允許多個(gè)版本并存按發(fā)起人所屬部門或指定用戶組分流先讓一個(gè)部門跑新版本跑三天沒問題再全量。第三每次發(fā)布前跑一遍回歸用例至少覆蓋三類單據(jù)金額落在每個(gè)條件分支邊界的、會(huì)簽節(jié)點(diǎn)有人駁回的、發(fā)起后撤回的。-- 發(fā)布前檢查是否有實(shí)例仍停在舊版本評估改版影響面 SELECT def_version, COUNT(1) AS running_cnt FROM oa_process_instance WHERE def_code leave AND status RUNNING GROUP BY def_version ORDER BY def_version;這條查詢用來判斷新舊版本并存的規(guī)模。如果舊版本還有幾十條在途新版本一上線就得保證舊版本的節(jié)點(diǎn)配置不被清掉——很多包在發(fā)布時(shí)會(huì)把舊版本的節(jié)點(diǎn)數(shù)據(jù)邏輯刪除結(jié)果在途單據(jù)跑到一半找不到下一節(jié)點(diǎn)只能人工補(bǔ)數(shù)據(jù)?；叶确至魑彝ǔ２环旁诹鞒桃胬镒龆欠旁诎l(fā)起入口按starter的部門 ID 取模命中灰度組的走新版本其余走舊版本。這樣引擎本身不用改出問題把分流開關(guān)一關(guān)就回去了比在引擎里加一堆判斷干凈得多?；貧w驗(yàn)證這塊手工點(diǎn)太慢我一般寫一個(gè)腳本直接調(diào)接口建單、審批、查狀態(tài)把每條分支跑一遍斷言最終節(jié)點(diǎn)和任務(wù)數(shù)量。這套腳本跟著版本走每次發(fā)布前跑一次比人肉點(diǎn)強(qiáng)太多。血淚經(jīng)驗(yàn)是有一回圖省事直接在已發(fā)布的流程定義上改了條件表達(dá)式的值沒走版本。改完十分鐘正在審批中的單子按新條件重新求值一批本該走總監(jiān)的單子直接跳到結(jié)束事后靠審批流水一條條往回?fù)?。從那以后我每次改流程定義不管改的是一個(gè)字段還是一行表達(dá)式都強(qiáng)制走「復(fù)制新版本 → 改 → 灰度 → 全量」這條鏈路一次都沒再跳過。流程配置看著是數(shù)據(jù)可它承載的是審批責(zé)任改錯(cuò)了不是顯示問題是有人該審的沒審。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取