Differenze tra le versioni di "Attesa sotto processo asincrono"

Da wiki.maggioli.it.
Jump to navigation Jump to search
imported>Root
imported>Root
Riga 3: Riga 3:


Tali sotto-processi devono avere le seguenti caratteristiche:
Tali sotto-processi devono avere le seguenti caratteristiche:
* Essere sotto-processi avviati tramite l'azione di workflow [[Avvio_di_sotto-processi]]
* Essere sotto-processi avviati tramite l'azione di workflow [[Avvio di sotto-processi]]
* Essere stati avviati in modalità asincrona
* 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.
Solamente i processi con le caratteristiche sopra elencate sono intercettabili in fase di terminazione da parte dell'attività di attesa. Sotto-processi avviati tramite meccanismi differenti non verranno correttamente intercettati.


==Ottenimento degli id di processo==
==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.
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.
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' possibile non passare alcun id di processo all'azione, in tal caso non verrà effettuata alcuna attesa. Questo facilita la modularità di certe implementazioni.
==Tempo di propagazione dei flussi==
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.
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.
==Terminazione dei processi==
 
Ogni volta che uno di questi processi termina, l'azione controlla che l'intero insieme di processi sia terminato. Se questa condizione non è verificata 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.
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.

Versione delle 14:54, 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. Sotto-processi avviati tramite meccanismi differenti non verranno correttamente intercettati.

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' possibile non passare alcun id di processo all'azione, in tal caso non verrà effettuata alcuna attesa. Questo facilita la modularità di certe implementazioni.

Tempo di propagazione dei flussi

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.

Terminazione dei processi

Ogni volta che uno di questi processi termina, l'azione controlla che l'intero insieme di processi sia terminato. Se questa condizione non è verificata l'azione torna in attesa.

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.