Is there a way to restart a workflow that was terminated unexpectedly without handling WorkflowTerminated event ?

Question

I am researching if there is a capability within the workflow Runtime object or by some other means to detect unfinished workflows and restart them. I know I can go to the WFState database read it and restart all the Instances that are found there but I am wondering if there is a way to have it done automatically ?

Answer 1

What do you mean by restart? Do you mean resume from current location or restart from the begining?

Resuming is not possible even if you handle terminate event.

---

If my response answers your question, please mark it as the "Answer" by clicking that button above my post.

My blog: http://www.RyanVice.net/

Answer 2

I did mean resume from the current location.
I am surprise that you cannot do it when handling terminate since if you cannot do that why else you want to persist a workflow to a database ?

Thanks
Zeev

Answer 3

Resuming is tricky. We accomplished in our system by persisting after every CustomActivity using the PersitOnClose attribute along with the this technique: http://www.ryanvice.net/wf3-5/abort-on-error-in-windows-workflow-foundation-3-5/

The abort on error technique allows the WF to abort instead of terminating. Aborting will cause the WF instance to not be persisted effectively leaving it at the last persistence point. The PersistOnClose on custom activites cause the WF instance to persist after each activity so it allows you to stop at the last custom activity that executed sucessfully. Then we added code in WFRuntime's abort event handler to suspend the WF and this allowed for us to prevent the WF instance from continuing before someone had a chance to examine if there was a problem that needed to be addressed first.



Also, not sure if you are aware but WF 4.0 aborts on exceptions instead of terminating so your comment about why would they do this definitely a legitimate concern as they updated the behavior to be more what people except for 4.0.

---

If my response answers your question, please mark it as the "Answer" by clicking that button above my post.

My blog: http://www.RyanVice.net/

Answer 4

Hello Ryan.

We are using the technique you've described :

 http://www.ryanvice.net/wf3-5/abort-on-error-in-windows-workflow-foundation-3-5/

( Yes we still use wf 3.5 , and don't have an option to move to 4 right now )

 

We need to suspend the workflow instance once it's aborted .

For that we're using the WF Runtime WorkflowAborted event , 

where we have the following code :

 void runtime_WorkflowAborted(object sender, WorkflowEventArgs e)

        {

		e.WorkflowInstance.Suspend("suspended by runtime");
    }

The problem is that in a non-consistent way, some workflow instances are suspended in a point which is after the last persistence point .

I mean that if I have a workflow :

Activity1 -> PersistedActivity2 -> Activity3 -> Activity4 -> ActivityWhichCausesException5

Then using the technique some instances actually suspended at the PersistedActivity2 ( which is as expected ) , 

but other instances of the same workflow suspended at the Activity3 , Activity4 , or even ActivityWhichCausesException5 activity .

 

Can you suggest where is the problem .

Did you encounter with the described problem ??

Maybe it has something to do with the fact that the workflow aborted on it's own thread , while resumed using the thread of the WF runtime .

Thank you very much !