Differenze tra le versioni di "Attesa sotto processo asincrono"

Da wiki.maggioli.it.
Jump to navigation Jump to search
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
 
(4 versioni intermedie di uno stesso utente non sono mostrate)
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 di questa attività.
 
'''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 (non vi sarà alcuna attesa).


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 sua terminazione vengono immediatamente messe in stato di errore e sarà necessario un ripristino manuale del corretto stato di esecuzione.


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.
==Accorgimenti==
Non sempre è necessario specificare tutti gli id di sotto-processo nell'azione di terminazione. In una situazione in cui i sotto-processi si sbloccano in modo sequenziale potrebbe essere sufficiente, nel processo principale, attendere la terminazione solo dell'ultimo processo. Questo permette di risparmiare risorse, non dovendo ad esempio memorizzare l'intero array degli id di sotto-processo.

Versione attuale delle 17:05, 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 di questa attività.

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 (non vi sarà alcuna attesa).

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 sua terminazione vengono immediatamente messe in stato di errore e sarà necessario un ripristino manuale del corretto stato di esecuzione.

Accorgimenti

Non sempre è necessario specificare tutti gli id di sotto-processo nell'azione di terminazione. In una situazione in cui i sotto-processi si sbloccano in modo sequenziale potrebbe essere sufficiente, nel processo principale, attendere la terminazione solo dell'ultimo processo. Questo permette di risparmiare risorse, non dovendo ad esempio memorizzare l'intero array degli id di sotto-processo.