Differenze tra le versioni di "Attesa sotto processo asincrono"
imported>Root (Nuova pagina: ==Descrizione== Questa attività permette di attendere la terminazione di uno o più sotto-processi. Tali sotto-processi devono avere le seguenti caratteristiche: * Essere sotto-proc...) |
imported>Root |
(Nessuna differenza)
|
Versione delle 14:43, 26 set 2013
Descrizione
Questa attività permette di attendere la terminazione di uno o più sotto-processi.
Tali sotto-processi devono avere le seguenti caratteristiche:
- Essere sotto-processi avviati tramite l'azione di workflow Avvio_di_sotto-processi
- Essere stati avviati in modalità asincrona
Solamente i processi con le caratteristiche sopra elencate sono intercettabili in fase di terminazione da parte dell'attività di attesa.
Ottenimento degli id di processo
Il parametro sub_process_id permette di specificare gli id di processo di cui attendere la terminazione. Gli id vengono tornati come risultato dall'azione Avvio_di_sotto-processi. Se tale azione avvia i sotto processi in modalità sincrona, gli id vengono tornati dopo che tutti i processi sono terminati, pertanto utilizzare tali id in questa action è inutile.
Se invece l'avvio avviene in modalità asincrona gli id vengono tornati subito, mentre ancora i sotto processi stanno eseguendo, ed ha senso usarli in questa action.
E' da notare che nel tempo necessario al flusso di workflow per giungere sul nodo dove è configurata l'attesa sotto processi, parte o tutti di questi potrebbero già essere terminati. Qualora tutti i processi fossero già terminati quando questa azione viene eseguita, il risultato sarà un immediato proseguimento sullo stato successivo. L'azione causa una attesa del sistema solamente se almeno uno dei processi specificati è ancora in esecuzione.
Ogni volta che uno di questi processi termina l'azione controlla che l'intero insieme di processi sia terminato. Se questa condizione non è avverata l'azione torna in attesa.
E' possibile non passare alcun id di processo all'azione, in tal caso non verrà effettuata alcuna attesa. Questo facilita la modularità di certe implementazioni.
Se uno dei sotto processi viene distrutto (è possibile in quanto sono asincroni) tutte le azioni che erano in attesa della terminazione vengono immediatamente messe in stato di errore e sarà necessario uno sblocco manuale della situazione.