馳騁工作流引擎設計系列13 退回設計
- 關鍵字
馳騁工作流引擎 流程快速開發平臺 workflow ccflow jflow
- 退回設計
- 退回規則設計
流程引擎的退回與傳送，分別是前進與後退，它是流程引擎的基礎功能操作，流程的退回根據不同的應用場景，也是需要不同的方式來控制，我們把這些方式叫做規則處理。
退回規則設定
退回規則在節點按鈕標籤欄目中的退回標籤設定，如下圖：
不能退回:當前節點不能執行退回功能，當前節點的操作人員就不能看到退回按鈕。
只能退回上一個節點：只能退回上一個節點，從那裡傳送來的，就退回到那裡去。
可以退回以前任意節點:不限制退回的節點，但是退回的節點必須是當前節點以前的節點。
可退回指定的節點:
總結：
1,根據實際業務需求，設定不同的退回方式。
2, 配合退回前、退回後的事件完成業務的可逆的操作。
- 退回的訊息處理
1.執行退回後，系統都會向執行人傳送訊息，傳送物件僅限於上一節點的執行人員，這樣上被退回的點上的工作人員就有一個待辦工作，如果您集成了ccim它就會自動發一個訊息提醒。
2.退回的動作寫入WF_Track中，流程軌跡中就能很好的反應出來。
3.被退回的人在進入當前工作時，第一次會有訊息提示。
Ccbpm如何處理流程退回過程的資料的完整性？
流程在退回時，有一段流程資料就是從當前點到退回點的所做的工作，這部分節點的資料如何處理成為了我們要探討與取捨的難點。
以請假流程為例，申請人發起，部門經理審批，總經理審批，人力資源歸檔。如果總經理退回到第一個點，可以解釋為，部門經理做的無效的工作，此部分工作需要刪除，在3.0以前的版本，ccbpm都是這樣的處理的，這樣的解釋也是使用者所接受的。
但是在其它的流程就不能這樣解釋了，因為他需要保留歷史痕跡，並且在退回後有如下可能要發生。
- 退回到指定的點後，發起人刪除流程。
- 退回到退回節點後，發起人修改表單後傳送，按原節點發回來。
- 退回到退回節點後，發起人修改表單後傳送，經歷與其它的路線步驟到當前點。
- 退回到退回節點後，發起人修改表單後傳送，該走其它的路線不經當前點。
基於如上可能性的發生ccbpm，做了如下處理。
- 退回階段流程資料寫入txt 檔案裡，放在D:\ccflow\CCFlow\DataUser\ReturnLog
- 增加了流程報告與節點的焦點欄位功能，系統把每一步驟的操作都記到日誌表裡了，通過焦點欄位的配合，可以讓操作員方便明晰的看到軌跡。
Ccbpm6.0通過如上兩個方法解決退回資料的完整性問題。
- 退回並原路返回
與節點屬性中的[是否可以退回並原路返回？] 配合使用
應用場景：一個流程走過了ABCDEFG幾個節點，在G節點上發現要退回給B節點上去，還期望B節點的人員完成後直接傳送給G節點上來，這種應用場景就是是否可以在退回後原路返回。如果是直接退回並不原路返回，那麼ccbpm將會刪除退回點與退回到點中間的資料，否則就不刪除它。
退回資訊填寫欄位
使用者經常會在審批意見的欄位中填寫意見然後點退回按鈕，審批意見就是該操作員的稽核意見，這個時候ccbpm需要把稽核意見帶入退回視窗，這個欄位就是退回資訊填寫欄位。
在demo的第二個節點，我們看看退回的效果，我們先看看測試效果。
點退回，ccbpm就會把稽核意見放到退回的窗口裡面。
- 介面定義
退回是比較常用的方法之一，退回方法的api是BP.WF.Dev2Interface.Node_ReturnWork。
仔細的看看引數，就知道如何呼叫該退回方法了。
我們不建議使用者直接呼叫api，而建議呼叫ccbpm的這個工作部件，這個工作部件呼叫很簡單。詳細請參考：BP.WF.Dev2Interface.UI_Window_Return
由於在BP.WF.Dev2Interface這個類庫裡，已經很清晰的描述了各個api的作用，由於同步與變更的關係，這裡不再贅述。
轉載於:https://my.oschina.net/ccflow/blog/3006859