馳騁工做流引擎設計系列13

 

退回設計

第1節. 關鍵字

馳騁工做流引擎 流程快速開發平臺 workflow ccflow jflow

第1節. 退回設計

1.1.1: 退回規則設計

流程引擎的退回與發送，分別是前進與後退，它是流程引擎的基礎功能操做，流程的退回根據不一樣的應用場景，也是須要不一樣的方式來控制，咱們把這些方式叫作規則處理。

退回規則設置

退回規則在節點按鈕標籤欄目中的退回標籤設置，以下圖：

不能退回:當前節點不能執行退回功能，當前節點的操做人員就不能看到退回按鈕。

只能退回上一個節點：只能退回上一個節點，從那裏發送來的，就退回到那裏去。

能夠退回之前任意節點:不限制退回的節點，可是退回的節點必須是當前節點之前的節點。

可退回指定的節點:退回指定的節點，此功能須要在流程屬性中的可退回的節點中設置它。

總結：

1,根據實際業務需求，設置不一樣的退回方式。

2, 配合退回前、退回後的事件完成業務的可逆的操做。

1.1.2: 退回的消息處理

1.執行退回後，系統都會向執行人發送消息，發送對象僅限於上一節點的執行人員，這樣上被退回的點上的工做人員就有一個待辦工做，若是您集成了ccim它就會自動發一個消息提醒。

2.退回的動做寫入WF_Track中，流程軌跡中就能很好的反應出來。

3.被退回的人在進入當前工做時，第一次會有消息提示。

Ccbpm如何處理流程退回過程的數據的完整性？

流程在退回時，有一段流程數據就是從當前點到退回點的所作的工做，這部分節點的數據如何處理成爲了咱們要探討與取捨的難點。

以請假流程爲例，申請人發起，部門經理審批，總經理審批，人力資源歸檔。若是總經理退回到第一個點，能夠解釋爲，部門經理作的無效的工做，此部分工做須要刪除，在3.0之前的版本，ccbpm都是這樣的處理的，這樣的解釋也是用戶所接受的。

可是在其它的流程就不能這樣解釋了，由於他須要保留歷史痕跡，而且在退回後有以下可能要發生。

1， 退回到指定的點後，發起人刪除流程。

2， 退回到退回節點後，發起人修改表單後發送，按原節點發回來。

3， 退回到退回節點後，發起人修改表單後發送，經歷與其它的路線步驟到當前點。

4， 退回到退回節點後，發起人修改表單後發送，該走其它的路線不經當前點。

基於如上可能性的發生ccbpm，作了以下處理。

1， 退回階段流程數據寫入txt 文件裏，放在D:\ccflow\CCFlow\DataUser\ReturnLog

2， 增長了流程報告與節點的焦點字段功能，系統把每一步驟的操做都記到日誌表裏了，經過焦點字段的配合，可讓操做員方便明晰的看到軌跡。

Ccbpm6.0經過如上兩個方法解決退回數據的完整性問題。

1.1.3: 退回並原路返回

與節點屬性中的[是否能夠退回並原路返回？] 配合使用

應用場景：一個流程走過了ABCDEFG幾個節點，在G節點上發現要退回給B節點上去，還指望B節點的人員完成後直接發送給G節點上來，這種應用場景就是是否能夠在退回後原路返回。若是是直接退回並不原路返回，那麼ccbpm將會刪除退回點與退回到點中間的數據，不然就不刪除它。

退回信息填寫字段

用戶常常會在審批意見的字段中填寫意見而後點退回按鈕，審批意見就是該操做員的審覈意見，這個時候ccbpm須要把審覈意見帶入退回窗口，這個字段就是退回信息填寫字段。

在demo的第二個節點，咱們看看退回的效果，咱們先看看測試效果。

點退回，ccbpm就會把審覈意見放到退回的窗口裏面。

1.1.4: 接口定義

退回是比較經常使用的方法之一，退回方法的api是BP.WF.Dev2Interface.Node_ReturnWork。

仔細的看看參數，就知道如何調用該退回方法了。

咱們不建議用戶直接調用api，而建議調用ccbpm的這個工做部件，這個工做部件調用很簡單。詳細請參考：BP.WF.Dev2Interface.UI_Window_Return

因爲在BP.WF.Dev2Interface這個類庫裏，已經很清晰的描述了各個api的做用，因爲同步與變動的關係，這裏再也不贅述。