Activiti7.0實戰學習(五):用戶處理任務後表中數據做了哪些變化？

背景

1. 查詢出指定某個用戶的任務列表
2. 根據任務的ID進行任務處理
3. 看任務處理後，表中發生了哪些變化？

過程

• 處理任務代碼邏輯

• 數據庫表變化

1. act_ru_task表

   
   說明：由於sanding已經填寫了請假申請單，因此activiti把表中原來那條記錄給刪除了。又新插入了一條了數據。而這條數據就是部門經理這個負責人進行請假單審批了。而這裏字段ASSIGNEE爲什麼爲null，是因爲我們在流程實例化的時候，並沒有添加具體的某個負責人。測試的時候，可以手動操作數據庫去填寫即可。

2. act_hi_actinst表

   
   說明：原來這張表有兩條數據。2504這條數據的END_TIME是null的, 而當sanding這人負責人(只要有任務都是負責人)填寫了請假申請單後，END_TIME字段就有值了。且，又新插入了一條數據5001,這條數據是任務流程圖中的第三個環節，剛好一個環節（節點，任務節點）一條行爲的歷史記錄，而且我們依然可以看見它的END_TIME字段依然爲null。

3. 通過分析sanding處理任務後，得到的結論。那麼部門經理處理完任務後，也是同樣的效果，繼續向後面節點移動（領導審批（leader check））。而當leader check完成後，那麼act_hi_actinst表中一定對應着5條記錄，每個環節（每個節點）對應一條記錄。而act_ru_task一定沒有數據了。因爲這個流程實例已經完成了。而爲什麼要刪除，就是爲了保證表中的數據量小，加快查詢速度。

4. 變化的不只是這兩種表，凡是邏輯上相關聯的表，數據都會變化的。但是在實際應用場景中，我們可以選擇記錄一些重要的信息，一些不重要的記錄，就可以丟掉。

5. 此操作影響的表有(可能操作不是特別規範，因爲構建流程圖的時候，是沒有參與者，導致有些表其實是沒有生成記錄的，因此下表的第2條記錄和第5條記錄就沒有數據)

表名	是否受影響
act_hi_actinst	是
act_hi_identitylink	是
act_hi_taskinst	是
act_ru_execution	是
act_ru_identitylink	是
act_ru_task	是

• 部門經理進行任務處理（lisi）這個名稱是手動插入到數據的，自定義名稱即可。
  lisi未處理任務的時候，數據庫表情況。
  
  代碼查詢演示
  
  控制檯打印
  
  lisi執行任務，代碼邏輯演示
  

數據庫表變化

1. act_ru_task
   
   ASSIGNEE是null, 是因爲我在流程定義的時候，未選擇參與者，實際應用場景中一定是有的，不然審批沒有任何意義。當wangwu去完成任務的時候，我們需要手動把wangwu賦值到ASSIGNEE字段上即可。
   這裏的結果，跟上文的推測，一模一樣。

2. act_hi_actinst
   
   數據變化過程：跟上文分析sanding處理任務後是一樣的。也跟推測一模一樣的。

• 領導進行任務處理(wangwu)這個名稱是手動插入到數據的，自定義名稱即可。
  wangwu未執行任務時，代碼邏輯演示

控制檯打印

wangwu未執行任務時，數據庫act_ru_task表

wangwu處理任務代碼邏輯

wangwu處理任務後數據庫表變化

1. act_ru_task表（可以看見表中一條數據都沒有了）
   
2. act_hi_actinst表（可以看見5條記錄）
   
   總結：流程定義圖上有5個任務節點，分別是開始，填寫申請單，部門經理審批，領導審批，結束。剛好對應5條記錄。觀察發現開始事件和結束時間的TASK_ID是null 。而這裏的ASSIGNEE爲什麼是null可能跟自己定義流程圖有關係。（後續找原因）
   多注意字段END_TIME是否爲null

小結

1. 這節的知識是非常重要的，它告訴我們流程實例隨着任務完成後，數據庫表中的數據變化，其實就是Activiti的工作過程。
2. 理解一個最簡單的。那麼其他的都差不多了。比如一個任務給多個人處理。一個任務給多人中的其中一人處理。都能去推。
3. 推的依據就是流程實例究竟是怎樣的？流程實例中的每個節點（每個環節）都是一條記錄。而需要當前環節（節點）處理任務的時候，act_ru_task表就對應當前流程實例一條待處理的記錄。
4. 一旦某個流程實例完成了，act_ru_task對應的這個流程實例的記錄將一條也不存在。而act_hi_actinst將對每個環節，也就是每個任務節點都有一條數據。