views:

226

answers:

2

Can any one explain what the difference is between the following methods of WorkflowApplication:

Abort Cancel Terminate

+1  A: 

First, hats off to Steffen Opel (and his comments below). I failed to catch that my original post linked documentation that was WF 3.5 specific. Did a little more digging around.

For posterity's sake, I have left my previous response below, labelled as WF3.5. Please see WF4.0 for a few notes regarding Canceling, Abort, and Terminate in WF4.0.


WF4.0

Unfortunately, there is little explicit documentation discussing differences in Cancel, Abort, and Terminate in WF4.0. However, from member method documentation,

  1. On Abort, a) activity is immediately halted, b) Aborted handler is invoked, and c) Completed handler is not invoked.
  2. On Cancel, a) activity is given a grace period to stop gracefully after which a TimeoutException is thrown, b) Completed handler is invoked.
  3. On Terminate, a) activity is given a grace period to stop gracefully after which a TimeoutException is thrown, b) Completed handler is invoked.

The differences between Abort and Cancel/Terminate is quite striking. Simply call Abort to kill a Workflow outright. The difference between Cancel and Terminate is more nuanced. Cancel does not require any sort of reason (it is a void parameterless method), whereas Terminate requires a reason (in either string or Exception format).

In all cases, Workflow runtime will not perform any implicit action on your behalf (ie Workflows will not auto-self destruct a la WF3.5 Terminate). However, with the highly customizable exception\event handling exposed by the runtime, any such features may be implemented with relative ease.


WF3.5

Canceling

According to Msdn documentation

An activity is put into the Canceling state by a parent activity explicitly, or because an exception was thrown during the execution of that activity.

While Canceling may be used to stop an entire Workflow (ie invoked on root Activity), it is typically used to stop discrete portions of a Workflow (ie either as error-recovery or an explicit action on part of parent). In short, Canceling is a means of Workflow control-flow.

Abort and Terminate

Again, according to Msdn documentation

Abort is different from Terminate in that while Abort simply clears the in-memory workflow instance and can be restarted from the last persistence point, Terminate clears the in-memory workflow instance and informs the persistence service that the instance has been cleared from memory. For the SqlWorkflowPersistenceService, this means that all state information for that workflow instance is deleted from the database upon termination. You will not be able to reload the workflow instance from a previously stored persistence point.

Which is pretty clear in itself. Abort merely stops in-memory execution whereas Terminate stops in-memory execution and destroys any persisted state.

johnny g
Hmmh, your MSDN links are all targeting the WF 3.5 documentation. While there are lots of conceptual similarities of course, the architecture [has changed enough](http://msdn.microsoft.com/en-us/library/dd489410.aspx) to make WF 3.5 answers to WF 4 questions confusing at best, I'm afraid - see for example section *Activity Life Cycle* at the end of [Windows Workflow Architecture](http://msdn.microsoft.com/en-us/library/dd489413.aspx) in comparison to [Understanding the Activity State Model](http://msdn.microsoft.com/en-us/library/bb628512%28VS.90%29.aspx) as linked from you answer.
Steffen Opel
thanks, good catch! hopefully my updated response is a little more clear and accurate :)
johnny g
A: 

After further investigating this issue, I want to summarize the differences:

Terminate :

  • the Completed event of the workflow application will be triggered
  • the CompletionState (WorkflowApplicationCompletedEventArgs) is Faulted
  • the Unloaded event of the workflow application will be triggered
  • the workflow completes
  • OnBodyCompleted on the activity will be called

Cancel:

  • the Completed event of the workflow application will be triggered
  • the CompletionState (WorkflowApplicationCompletedEventArgs) is Cancelled
  • the Unloaded event of the workflow application will be triggered
  • the workflow completes
  • OnBodyCompleted on the activity will be called

Abort:

  • the Aborted event of the workflow application will be triggered
  • the workflow does not complete

An unhandled exception

  • triggers OnUnhandledException
  • in this eventhandler the return value (of type UnhandledExceptionAction) determines what will happen next:
  • UnhandledExceptionAction.Terminate will terminate the workflow instance
  • UnhandledExceptionAction.Cancel will cancel the workflow instance
  • UnhandledExceptionAction.Abort will abort the workflow instance
  • Each will trigger the corresponding events explained above

Update: Abort does not seem to trigger unloading of the instance in the SQL persistence store. So it seems to me, you better use Cancel or Terminate and if you have to perform some action based upon the completion status, you can check CompletionState in the Complete event.

rekna