La cancellazione dell'esecuzione di un workflow è simile per certi versi al Fault Handling: osando un parallelismo con il mondo della programmazione OO, potremmo affermare che se i Fault Handler possono essere paragonati ad un catch, i Cancellation Handlers costituiscono il finally. Da un punto di vista pratico, l'utilità dei Cancellation Handlers si trova nella capacità di permettere l'esecuzione di operazioni (tipicamente notifiche, logging, cleanup delle risorse utilizzate...) prima che il workflow venga effettivamente terminato, senza alcuna possibilità di interruzione. Il processo di cancellazione infatti, una volta avviato, è inarrestabile.
Un Cancellation Handler può essere definito sia a livello di Workflow (globale) che localmente a livello di Composite Activity (es. ParallelActivity, SequenceActivity). In quest'ultimo caso, il processo di cancellazione è attivato se almeno una delle attività figlie di una Composite Activity scatena un errore non gestito o è in esecuzione quando il workflow è cancellato (ad es. dall'applicazione host).
Veniamo ora ad un aspetto interessante: un Cancellation Handler può non comportarsi esattamente come ci aspettiamo. Ebbene si.
Se ad esempio impostiamo un Cancellation Handler globale (a livello di workflow), non è detto che venga chiamato ogniqualvolta il Workflow subisce una cancellazione. Infatti, poiché la cancellazione può essere gestita anche localmente, in caso di errore saranno attivati solamente i Cancellation Handler delle Composite Activities che possiedono delle attività figlie in esecuzione. Per quanto riguarda il Cancellation Handler globale, invece, sarà attivato solo se la cancellazione viene invocata "esternamente" per l'intero workflow (tipicamente via UI/Applicazione Host).
Vediamo un esempio: ecco un workflow che definisce una ParallelActivity con 3 branch, ciascuno dei quali munito di una propria sequenza interna.
Supponendo che il branch centrale causi un' eccezione non gestita ( facendo passare inevitabilmente il workflow allo stato Terminated ), gli altri branch contenuti nella Parallel Activity principale verranno informati del fatto che il workflow sta per essere terminato, con conseguente attivazione dei relativi Cancellation Handlers. Stessa cosa vale anche per le Composite Activities ulteriormente nidificate.
Tuttavia, i Cancellation Handlers della Composite Activity che ha generato l'eccezione, della Parallel Activity esterna e del Workflow, NON verranno svegliati, differentemente da quanto ci si potrebbe aspettare.
Tirando le somme, è importante ricordare che il comportamento dei Cancellation Handler è strettamente dipendente dall'ordine di esecuzione delle attività al momento della cancellazione. Se da una parte possiamo pianificare la gestione dei Cancellation Handlers, dall'altra costituisce buona prassi (per ovvi motivi) NON implementare dipendenze logiche/funzionali tra i vari Cancellation Handlers e soprattutto sperimentare il loro comportamento nell'ambiente di esecuzione, in quanto può avere una natura variabile (addirittura eseguendo in modalità debug o meno).
Technorati tags: 
Workflow 
WF