Cancelling Workflows is similar in many ways to Fault Handling in our Workflows.  If Fault Handlers are the catch block, then cancellation Handlers are the finally block.  Workflows can be cancelled in a few ways and for any number of reasons:

    *    By unhandled exceptions

    *    By an administrator in the UI

    *    Explicitly based on a condition within the Workflow through the use of a Terminate activity

The Cancellation Handler allows us to perform any processing that needs to occur before the Workflow actually shuts down.  One thing that is important to note is that there is no way to stop the cancellation of a Workflow once it has been initiated by any means. 

So, if we can’t stop the cancellation of a Workflow, what can we do?  The answer is really just about anything else.  Off the top of my head, the following comes to mind:

    *    Notify a document owner that the Workflow has been cancelled

    *    Notify participants that the Workflow has been cancelled

    *    Just like with Fault Handling, if Tasks were already assigned, you should go back and either delete them or flag them as inactive. 

    *    Again just like Fault Handlers, log the cancellation

So, with all of that out of the way, how do we actually catch a Workflow Cancellation event and respond to it?  As I said when I started out this section, it is similar to Fault Handling.  To work with the Cancellation Handler for the whole Workflow, click on the middle tab at the bottom of the designer palette (and shown above in Figure 9-4).  This will reveal another palette used specifically for handling Workflow cancellations.

Also, composite activities can also contain specific, local Cancellation Handlers.  This local Cancellation handler will be called if one of their child activities is cancelled, or executing when the Workflow is cancelled.  Access this via a similar mechanism to the Fault Handler – right click on the activity and select View Cancel Handler.

One thing to note about Cancellation Handlers is that they may not exactly execute as you would expect.  If you place a Cancel Handler globally on the entire Workflow, it would be logical to assume that it would fire any time the Workflow is cancelled – for any reason.  Unfortunately, this is not the case.  Because Cancellation can be handled locally, only the composite activities that have children executing at the time the error is thrown or the Workflow otherwise cancelled will have their Cancellation Handlers triggered.  So, in the case of the global Cancellation Handler, this will only be triggered if the whole Workflow is cancelled – typically by an Administrator via the user interface.

In other cases, in order to get multiple activities executing simultaneously, you really need to be using the Parallel activity.  If one branch of the Parallel activity causes the Workflow to be cancelled – for example by throwing an unhandled error, the other branch(es) of the Parallel activity will be notified that the Workflow is being cancelled.  Individual composite activities within those other branches will also have their Cancellation Handlers triggered.  However, the Parallel activity itself and the Workflow as a whole will not have their Cancellation Handlers triggered.

It’s all a little bit happenstance and highly dependent upon execution order, timing and which activities are executing at the time the cancellation is triggered.  While you can generally plan out your Cancellation Handlers pretty well, there will be an experimentation aspect to it to see how things execute in your environment.