需求背景:
流程结束后，操作员发现此流程有一个错误，需要退回重新处理。对于ccBPM来说整体流程已经完成并且流程运行控制表已经被删除了该流程的数据。
处理方案：
在流程属性里的相关功能里增加一个相关功能，接受两个参数一个workid,一个回滚原因. 此功能只有admin用户才能操作。
其它说明：
1, 如果您是为了测试估计不能测试到效果，因为ccBPM在判断最后一个节点是通过时间来排序的，测试的数据经常时间点是一致的，精确到分钟。
2, 流程回滚后ccBPM会把日志写入wf_track表里。
流程回滚的应用背景：
场景1：一件流程在完成后，发现这个流程有问题，需要退回到流程指定的节点上与当时该节点的处理人身上，让他重做。
场景2：一个主流程启动了n个子流程，他在监控子流程时发现子流程问题，需要重新去做。
这两种场景下，都是在流程完全处理完后，并且流程引擎已经把该流程归档后要求重新回滚到指定的节点与该节点的处理人身上去，让其在重新去处理。
回滚流程对应的API：
/// <summary>
/// 恢复已完成的流程数据到指定的节点，如果节点为0就恢复到最后一个完成的节点上去.
/// 恢复失败抛出异常
/// </summary>
/// <param name="flowNo">要恢复的流程编号</param>
/// <param name="workid">要恢复的workid</param>
/// <param name="backToNodeID">恢复到的节点编号，如果是0，标识回复到流程最后一个节点上去.</param>
/// <param name="note">恢复的原因，此原因会记录到日志</param>
public static string Flow_DoRebackWorkFlow(string flowNo, Int64 workid, int backToNodeID, string note)
{
BP.WF.Ext.FlowSheet fs = new Ext.FlowSheet(flowNo);
return fs.DoRebackFlowData(workid, backToNodeID, note);
}
回滚流程的设计需求：
1， 回滚人接受到的信息是退回状态，而非流程的运行状态。
2， 回滚后流程数据表的状态由完成恢复到退回，最后结束节点恢复到回滚的点。
3， 恢复流程引擎注册表数据，当前表状态标识为退回。
4， 恢复流程工作人员表，把所有参与该流程上的工作人员都恢复里面去。
5， 写入一条退回信息，让接受人员能够看到退回的原因。
6， 写入到流程日志，保证它的完整可读。