activiti流程表單-流程委託場景設計以及測試鏈路

一.表單:

自定義表單的底層全部是前端+後端實現的,除了拖拽功能外沒有使用第三方的前端控件;

1.基本邏輯:

基於實際業務的表單需要的控件,在控件分類的基礎上,把各個單獨的html控件拼湊成一個完整的表單。目前表單設計一共有22個控件,每個控件對應着一個html模板,這個模板就是一個表單控件的完整的html代碼,新增控件的時候從html模板中克隆一個出來,然後修改對應的id、名稱以及相關屬性,然後給對應控件添加如刪除等事件方便後續的修改操作,通過拖拽的方式來控制表單控件在畫板上面的位置(實際上就是修改控件的XY軸座標)。給控件添加點擊事件後,在右邊的屬性面板列出對應控件屬性(和上面的控件模板一樣,只是這裏是對應控件的屬性模板),每個控件的屬性不一樣,控件的屬性會保存到後臺數據庫,也會體現到具體的控件屬性(這樣做是爲了既可以通過後臺來查詢單個控件的屬性,也方便前端在通過html模板進行渲染的時候不用再次進去讀取數據庫,而是直接把控件的html主鍵放到頁面上即可)。

 

2.表單數據源:

表單的數據源分爲自定義數據源和系統數據源(接口)。

 

(a)自定義數據源通過表單設計者來自定義,這個自定義後的數據庫最終會形成一個靜態的json字符串,編碼後作爲空間的一個html屬性直接保存到HTML的一個自定義屬性中,在解析表單的時候,從HTML的屬性中讀取在解析出來。

 

(b)系統數據源來源於後臺接口,再展示表單的時候直接從後臺讀取已經設置好的字典數據和其他通過特殊接口構造的數據,數據接口的類型和控件的類型一直,一個控件只能有一個數據源,數據源的格式根據控件的類型來決定,比如:下拉框的數據源結構是list<{key,value}>,文本輸入框的的數據結構是字符串等,數據源屬性也是控件屬性的一部分,也會持久化到數據庫,只是表單在渲染的時候回根據選在的接口類型-》找到對應的接口,通過這個接口來讀取數據並把數據解析到對應的控件中,最終形成包含數據的完成控件。對於讀取數據源接口的控件在真正的流程流轉過程中只會從接口中讀取一次,後面的流程步驟中如果需要用到這個表單也是同一套數據源(這樣子做是爲了保證流程從開始到結束,所有人看的的數據都是一致的,這個和我們表單流程具有版本的性質是保持一致的)。

 

3.表單相關表:

act_wekt_form_category(表單分類表)

就是簡單的表單分類,新建和編輯的時候需要設置對應的表單分類。

 

act_wekt_form(表單信息表)

保存表單的基本信息,如分類(每個表單只能有一個葉子分類)、名稱、ID、以及整個表單中所有控件組成的完成的htlm代碼編碼後的信息等。

 

act_wekt_form_widget(表單控件表)

表單控件和表單是N:1的關係,一個表單會包含對個控件,裏面會包含控件類型、名稱、歸屬表單等數據。

 

act_wekt_form_attribute(表單控件屬性表)

控件屬性表保存的是對應表單設置界面右邊每個控件的屬性信息,和控件是N:1的關係。

 

二.流程:

系統的底層採用activiti流程引擎,通過自定義的方式生成符合業務場景的流程圖(對應activiti是生成符合bpmn規範的xml代碼),流程設計是基於camunda-modeler設計器,對其進行漢化和調整以符合我們的流程設計場景。注意一點就是camunda-modeler設計器生成的xml流程代碼是符合bpmn2.0規範,但是和activiti是有區別的(實際上activiti也沒有把bpmn2的多有規範都實現的,只是符合而已),需要做相應的調整才能在activiti引擎中應用。

 

流程設計器添加額外內容包括:

  1. 流程屬性:添加了流程分類屬性(下拉聯動控件)、是否自由流程選項、流程描述;
  2. 用戶節點屬性:添加了辦理對象(部門,崗位,受理人,候選用戶,角色)、辦理權限(對應着表單頂部可操作的按鈕菜單)、全局表單權限設置(每個節點可以控制表單的讀、寫、可視權限)。
  3. 開始節點:添加了選擇表單分類以及選擇表單的選項。
  4. 默認節點修改(原來的默認節點不是用戶節點,現在改成默認是用戶節點,方便在流程設置的時候再次進行節點類型的轉換操作,我們系統默認是使用用戶任務節點的,但是流程設計器不是)。
  5. 條件流轉箭頭:增加箭頭表單時輔助設置(通過設置表達式來決定在流程流轉過程中的方向選擇,有的基於表單控件的值來控制,有的需要人工選擇下一步辦理節點的方式來控制)。

 

流程設計器內部的基本實現過程:

流程設計器在設計流程組件(組件屬性也是一樣的)的時候每次操作都會被記錄並暫時通過變量的方式保存起來,如果當前的激活點不在本控件的時候,實際上組件的信息已經被銷燬了,組件的屬性面板(實際上是html)也被銷燬了,單再次激活的時候組件及其屬性面板會根據保存在變量裏面的信息進行重新構建,所以實際上在表單實際的每一個操作,都會觸發“暫存”事件,及時在輸入空裏面內部變動也會觸發。

 

 

 

三.流程+流程(形成具體業務場景):

 

流程新建後,可以在新建工作中根據流程分類查詢到對應的流程並且可以發起(新建)流程,流程在流轉過程中需要做的事情就是在流程設計中分配給對應接單的功能,包括操作權限按鈕和表單數據。

 

設計的表如下:

act_wekt_bpmn_run(運行時流程表,對應act_wekt_bpmn,啓動流程後會在運行時生成數據)

act_wekt_query(流程查詢表,流程運行時會在流程查詢表生成數據,方便查詢,不用再到流程引擎中去進行關聯查詢)

act_wekt_query_his(流程查詢歷史表)

act_wekt_task_sign_info(加簽信息表,節點加簽後會在這個表中生成數據)

act_wekt_form_data_his(歷史表單數據表)act_wekt_task_assignee_bak(委託關係用戶存稿簽收信息備份表)

act_wekt_task_assignee(流程任務-授權表)

act_wekt_bpmn_form(流程元素-表單關係)

act_wekt_category(流程分類表)

act_wekt_bpmn_post(流程崗位表-權限)

act_wekt_activity_log(流程操作日誌表,重點表,很多數據的查詢都是基於日誌表)

act_wekt_extinfo(流程相關 擴展表)

act_wekt_bpmn(流程表)

act_wekt_bpmn_department(流程部門表-權限)

act_wekt_form_widget_run(表單控件表(運行時))

act_wekt_form_attribute_run(表單控屬性件表(運行時))

act_wekt_form_run (表單表(運行時))

act_wekt_form_data_run(運行時表單數據表)

 

實現說明:

表單和流程在沒有關聯的時候都是相互獨立的,不構造任何的業務場景。但是在流程設計中進行設計的時候(實際上的操作就是在流程的開始節點中選擇對應的表單),和表單進行關聯並且對節點的執行權限進行授權後,就可以成爲具備具體業務的功能流程,可以在協同辦公模塊中進行發起工作。流程&表單關聯後,就會形成一套當前的流程版本,就算表單被修改了也不會對將要發起的流程和正在流轉的流程產生任何的影響(這裏是通過版本號進行控制的,表單及其控件都有版本號),已經進行中的流程會按照原有的表單進行流轉,直到流程歸檔結束,當流程或者表單(表單被修改過後,和其相關聯的流程會自動檢測,方便告知流程管理者進行及時處理)有被修改過都會進行特殊標記,只有重新部署過的流程,其表單和流程修改結果纔會影響到新發起的流程實例中。

 

  • 委託

設計思路:

委託給工作比較複雜,特別是多層委託的關係,具有多種可能的觸發點並且和定時器相關。委託工作最多隻支持3層委託,如A->B->C->D。在某一個時間區間內,委託人的待辦任務可以有被委託人進行簽收&提交處理,根據委託的開始時間和結束時間(委託結束時間不能少於當前時間):

(a)新建委託

(1)如果開始時間小於當前時間,委託人的待辦任務加簽(追加任務候選辦理人)被委託人------即是操作實現;

加簽候選的信息需要保存在委託信息表中(根據委託關係獲填入委託數據鏈--只會保存委託葉子關係),

完成任務的時候需要更改委託信息表的相關數據(通過完成任務事件監聽進行處理,不要修改正常的業務邏輯)。

 

(2)如果開始時間大於當前時間,在到了設定的開始時間的時候,委託人的待辦任務加簽(追加任務候選班裏人)被委託人------定時器操作實現;

加簽候選的信息需要保存在委託信息表中(根據委託關係獲填入委託數據鏈等),

完成任務的時候需要更改委託信息表的相關數據(通過完成任務事件監聽進行處理,不要修改正常的業務邏輯)

到了委託的結束時間,自動清除被委託的任務,返還給頂級(間接)被委託人或者是直接委託人。

 

(3)在開始時間和結束時間的過程中,如果委託人收到待辦任務,同時也加簽到被委託人的待辦中(在complete任務的時候進行操作)------完成任務(事件監聽實現)的時候實現;

數據處理和(1)(2)相同。

 

(4)到了設定的結束時間,被委託人的待辦任務的候選權限被解除(刪除任務用戶權限)------定時器操作實現;

刪除委託表數據,刪除當前因爲這條委託數據所產生的流程委託數據,act_ru_identitylink表數據以及委託信息表數據要

同時也要刪除定時器數據以及內存中的定時器。

 

b)終止委託:

被委託人的待辦任務的候選權限被解除(刪除任務用戶權限)並返還給頂級(間接)被委託人或者是直接委託人

並銷燬內存定時器以及定時器數據

修改委託數據的狀態------即時操作實現。

 

(c)刪除委託:

被委託人的待辦任務的候選權限被解除(刪除任務用戶權限)並返還給頂級(間接)被委託人或者是直接委託人。並銷燬內存定時器以及定時器數據

刪除委託數據------即時操作實現。

 

(d)插入委託信息數據分析(最終委託是針對任務,插入委託數據的入口有:任務事件監聽,定時器以及實時操作)

(1)通過事件監聽獲取到了任務創建信息 -》

(2)根據任務獲取用戶的辦理人,候選人,候選組進而或到用戶ID -》

(3)根據用戶ID獲取改用戶是否有進行委託(查詢委託表)-》

(4)如果有委託數據,查詢該用戶的被委託用戶進行添加候選人操作,同時需要往委託信息數據表插入數據(含歷史表)(這個表只有在有具體委託任務的時候纔會有數據)-》

(5)如果發現被委託人同時也有進行了委託操作,就繼續尋找下一位委託人,同時需要往委託信息數據表(含歷史表)插入數據

(重複4、5點操作,知道被委託用戶沒有在給別人委託爲止--前提是不存在循環委託,否則會死循環)----前臺進行委託數據維護的時候一定要進行檢查。

 

(e)刪除委託信息數據分析(最終委託是針對任務):

接收到任務的時候,可以知道任務的來源(正常情況下試根據候選用戶,候選組,和辦理人來定位任務的可以查看並簽收的權限)

 

根據上面的委託路線:如果C終止或者刪除了C-D的委託關係,D的受託權限將會被回收到C中,刪除委託表以及委託信息表,

以及在委託表對用到流程引擎中act_ru_identitylink表的數據(委託信息表中的數據已經做過的任務是不能刪除的,同樣act_ru_identitylink已辦數據也不能刪除)

如果在委託信息表中能查到數據的,都是委託的數據。

 

(f)測試路線場景

(1)場景1(新增):被委託人的任務已經存在,委託數據不存在。

    [測試輸入1]:新增委託數據,讓當前時間在委託的時間區間內

    [測試期望結果1]:新增成功後,委託人的任務馬上委託給被委託人,如果這條數據本來是被簽收狀態,如果委託給一個人,則在被委託人那邊也是簽收狀態並且委託人這條待辦信息會沒掉(相當於已經被被委託人簽收了),如果委託給的是多個人(目前這種情況不存在),則不管原來的任務是否簽收,被委託後都變成未簽收,因爲多個人程序無法決定幫誰簽收等到委託結束時間到了,被委託關係解除,原來的被委託人的那些待辦的被委託任務數據會被清除並且返回給委託人(都是未簽收狀態),整個委託週期結束,委託數據的狀態會做相應變更(完成,終止。。。。)

    [測試輸入2]:新增委託數據,讓委託的開始時間大於當前時間

    [測試期望結果2]:新增成功後,委託人的任務不會馬上委託給被委託人,等到了委託開始時間纔會觸發委託數據到被委託人,數據狀態和[測試期望結果1]一樣,等到委託結束時間到了,被委託關係解除,原來的被委託人的那些待辦的被委託任務數據會被清除並且返回給委託人(都是未簽收狀態)整個委託週期結束,委託數據的狀態會做相應變更(完成,終止。。。。)

 

(2)場景2(新增):委託任務不存在,委託數據已經存在。

   [測試輸入3]:發起流程,進行任務流轉;讓委託數據滿足:當前時間在委託的時間區間內

    [測試期望結果3]:當任務流轉到相應節點,會通過事件監聽觸發委託操作,被委託人應該能查詢到被委託的待辦數據,數據狀態和[測試期望結果1]一樣,

等到委託結束時間到了,被委託關係解除,原來的被委託人的那些待辦的被委託任務數據會被清除並且返回給委託人(都是未簽收狀態)整個委託週期結束,委託數據的狀態會做相應變更(完成,終止。。。。)

   [測試輸入4]:發起流程,進行任務流轉;讓委託數據滿足:讓委託的開始時間大於當前時間

    [測試期望結果4]:當任務流轉到相應節點,這時候的委託數據是通過定時器產生的,原來和[測試輸入2]一樣,只是委託數據和任務數據生成的順序不一樣,整個委託週期結束,委託數據的狀態會做相應變更(完成,終止。。。。)

 

(3)場景3(中止):委託數據被刪除(或回收),數據結果和委託時間到期一樣,不一樣的是委託數據本身的狀態變成中止狀態

 

(4)場景4(刪除):委託數據被刪除(或回收),數據結果和委託時間到期一樣,不一樣的是委託數據本身會被刪除

 

(5)場景5(服務器重啓):因爲定時器是保存在內存的線程中,應用重啓後會消失,所以在系統啓動的時候,對於那些沒有被刪除(所有委託相關的定時器執行後會被刪除-包括包含內存刪除和數據刪除is_delete)的委託任務定時器會被重新觸發,已保證委託數據不會由於斷層(額外說明:這個方法可以保持了絕大多的定時器會被重啓,但不能完全,因爲如果定時器的執行時間剛好在應用停止和啓動的時間差區間內。那樣即便定時器重啓了但是執行時間已過,屬於一個無效的定時任務,永遠不會被處罰--------後續解決方案是可以人工修改定時任務觸發)。

 

  1. 場景6(被委託人完成被委託任務):當被委託人完成任務的時候回觸發完成任務的監聽事件,修改委託明細數據had_do=1並且會回填上任務的處理時間。

 

 

  • 相關技術

 

涉及技術:jquery(前端)、freemarket(前端)、artemplate(前端)、layui(前端)、springboot、websocket(消息推送)、mybatis(mybatis-plus)、quartz任務調度、fastdfs(文件系統)、rocketMQ(消息隊列)、spring-session(session持久化)、spring-security(安全&權限框架)、activiti(流程引擎)、nginx(集羣&負載)、redis(緩存)、cas(單點登錄)

 

相關工具:gitlab、maven、nexus、jenkins;

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章