回退（Rollback WorkItem）

回退是工作流參與者對自己“待辦任務”（實際是對工作項）的一種操作，即參與者主動回退待辦任務列表中的任務到已經執行過的人工節點。

為什么要回退？

參與者接受任務后，發現不應由自己辦理此任務或以前的執行者辦理有錯誤等情況后，需要將此接受的任務回退給以前某個節點的執行者重新辦理。

回退模式

回退的情況實際上是非常復雜的，其中包括了參與者的重新選擇以及回退的條件判斷等等。這里先列出常見的回退模式（其實也是我們支持的模式）。

串行

這種情況最為簡單，后續節點可以回退到前續任意人工節點。回退后，節點重走。

分支

這種情況也相對簡單，實際執行的分支上的節點可以回退到前續任意人工節點（不區分主支和分支）。同樣，主支上的節點也可以回退到任意實際執行的分支上的節點。

可能的問題：多次回退后的回退節點選擇。例如：第一次流程經過節點2、節點3到達節點5，節點5可以回退到節點1、節點2和節點3的任意一個，此時節點5回退到節點1，節點1重走，這一次流程改為經過節點4到達節點5，節點5回退時如何選擇回退節點？此時的策略是以最近實際執行的分支為準，即節點5只允許回退到節點4和節點1，不允許回退到節點2和節點3。（抹去記憶）

并發

對于并發的情況，分支節點只允許在分支的節點間回退。

同理，主支節點也只允許在主支的節點間回退。

多實例匯聚

在這種情況下，節點5會產生2個實例，實際相當于繼續并發。節點5根據具體哪個節點觸發的它而產生回退節點。同時不允許回退到節點1以及前續的節點去。

子流程

支持子流程到父流程的回退，也支持父流程到子流程節點的回退。需要注意的是子流程節點有可能產生多個子流程實例，在這種情況下不支持父子流程之間的相互回退。

回退節點的參與者選擇

默認策略是由原先節點的實際參與者重新處理，比如節點2回退到節點1，則節點1的實際參與者重新處理該節點任務。這也符合大多數實際的業務場景。

在節點任務競爭參與的情況下，提供另一種策略，即讓人員重新競爭。

回退的條件判斷

對于多人（或者多部門，用戶）參與的工作項，提供不同的回退策略

任意人回退即回退，剩余工作項手工終止

最后提交人回退才回退

   流程定義期定義該策略。

   另外流程定義時提供節點可回退列表，由用戶在定義期對可回退的節點進行限制。

關于業務補償

業務補償是一個很重要的概念，在回退的情況下需要相應的回退部分業務操作。這里由引擎提供統一的接口，返回回退路徑，由客戶自定義代碼進行匹配處理。

關于實現

很多工作流引擎通過流程定義時繪出回退線來顯式的支持回退，這種實現在業務復雜的情況下會造成流程圖的異常煩瑣，但是比較清晰，實現比較容易。隱式實現相比而言優點更多。