Aborting SQL Server

The way it works is by creating a custom SQLWorkflowPersistenceService by deriving from SQLWorkflowPersistenceService and then overriding the save method as shown below.

protected override void SaveWorkflowInstanceState(Activity rootActivity, bool unlock)
{
WorkflowStatus workflowStatus = WorkflowPersistenceService.GetWorkflowStatus(rootActivity);
if (workflowStatus == WorkflowStatus.Terminated)
    {
string workflowError = WorkflowPersistenceService.GetSuspendOrTerminateInfo(rootActivity);
if (string.IsNullOrEmpty(workflowError))
            throw new Exception("Workflow terminated, forcing an abort!");
    }
base.SaveWorkflowInstanceState(rootActivity, unlock);
}

  As you can see when the status is WorkflowStatus.Terminatedan exception is thrown. When an exception is thrown from the service layer the associated WFI will abort which will effectively roll back to the last persistence point. This will allow you to restart the WFI from the last persistence point by redoing whatever external stimulus that caused it to start running before the exception occurred.

Gotchas

There are a few gotchas to be aware of when using this technique.

Duplicates in Tracking 

You will get duplicate entries in your tracking data. Tracking data is saved with ordinal values that specify the order that the tracked events occured in. When using the SQLTrackingService these ordinal values aren’t enforced to be unique. What happens is that the tracking service will keep writing until the point that the exception is thrown from your custom SQL persistence service and then when you restart your WFI the tracking service will start again from the same ordinal that it was on when the last persistence point was reached before the error and you will get duplicate entries with the same ordinal numbers. You can code around this and filter by ordinal and date to get a better view of what happened before and after the exception but it is something to be aware of.

Repeating Activities

Using this technique will effectively roll back your WFI to the last persistence point but this has the side effect that when you restart the WFI you will repeat all the activities that executed after the last persistence point and up till the activity that threw the error. I got around this on my current project by forcing persists after each activity executes by having my custom activities all derive from a base class that has the PersistOnClose attribute declared on it.