Le activity di blocco contengono un job che deve attendere l’ esecuzione di una determinata activity. Quando si utilizzano le activity di blocco, tutti gli eventi devono essere gestiti nell’ordine in cui è stato progettato il processo. Tuttavia, è non è possibile progettare un processo senza sapere quando verrà ricevuto un messaggio.
Un carrello della spesa è un buon esempio di un processo in cui l’ aggiunta e la rimozione di elementi è fatto in un ordine casuale da parte di un acquirente.
I gestori di eventi consentono l’ elaborazione asincrona degli eventi. Essi sono sempre collegati ad un ambito di applicazione ed eseguono parallelamente alla logica di business principale del processo, quindi sono associati ad un’ operazione che fa parte del processo.

Ogni gestore di eventi è associato ad un processo e ha accesso a tale processo.
Un gestore di eventi può essere eseguito più volte durante l’ esecuzione del processo.
I gestori di eventi possono essere impostati su due livelli:

Livello di processo

 – Quando viene disattivato a livello di processo, annulla il job.

Livello Scope 

– Una volta superato il livello scope, in genere ne annulla il campo di applicazione. Può invece essere configurato per il timeout.

Considerare il processo del fornitore di servizi ipotecari mostrato nella figura seguente. Il servizio ipoteca contiene tre operazioni: SubmitMortgageApp, SubmitFinDoc e CancelMortgageApp.
Il funzionamento di CancelMortgageApp viene disattivato nel contenitore del gestore dell’ evento.
Sia le operazioni di CancelMortgageApp che SubmitFinDoc hanno una chiave di correlazione ottenuta dalla risposta all’ operazione SubmitMortgageApp.
Dopo aver presentato un’ applicazione, se il consumatore invoca l’ operazione di CancelMortgageApp con la chiave di correlazione prima di inoltrare i documenti, il gestore dell’ evento contenente l’ implementazione per l’ operazione di CancelMortgageApp viene eseguito in parallelo al processo principale.
Il sistema non attende che venga eseguita l’ attività SubmitFinDoc.