Come gira un'esecuzione

Un workflow che funziona in prova e si comporta in modo strano in servizio quasi sempre incontra uno dei limiti di questa pagina. Sono pochi, sono fissi, e sapendoli si progetta il flusso in modo che non li tocchi.

Una alla volta

Di uno stesso workflow gira una sola esecuzione completa per volta. Se ne parte un’altra mentre la prima è in corso, viene messa in coda e parte appena la precedente finisce.

Nella pagina Le esecuzioni un’esecuzione in attesa del suo turno risulta In coda. Nella cronologia del builder invece risulta Esecuzione in corso, come quella che sta girando: se ne vedi due e i passaggi si muovono solo in una, l’altra sta aspettando.

Le prove sul singolo blocco seguono una regola separata: Esegui solo questo nodo non si mette in coda dietro un’esecuzione completa, ma non ne parte una seconda finché la prima non ha finito.

I tempi massimi

Sono fissi e non si configurano.

I 15 minuti si contano da quando l’esecuzione è stata creata, quindi comprendono il tempo passato in coda e le attese. Il controllo non è continuo: un’esecuzione bloccata viene chiusa la volta dopo che qualcuno avvia quel workflow, prova un suo blocco o ne apre l’elenco delle esecuzioni.

La risposta di una chiamata HTTP viene troncata a 256 KB. Se stai leggendo un elenco lungo, chiedi al sistema di paginare invece di scaricare tutto: oltre quel limite il corpo arriva tagliato, e un riferimento a un campo in fondo non trova niente.

Niente ritentativi, niente annullamento

Un passaggio che fallisce non viene ritentato. Il suo ramo si ferma e i blocchi a valle non girano. L’esecuzione risulta fallita solo se nessun ramo arriva in fondo: se un altro ramo finisce bene, risulta completata anche se una parte si è fermata.

Dove la chiamata può fallire per motivi temporanei, la strada è la Gestione errori del blocco: Aggiungi callback di errore non ritenta, ma devia su un percorso di recupero che costruisci tu. → I blocchi disponibili

Non c’è nemmeno un modo di fermare un’esecuzione avviata. Disattiva impedisce gli avvii successivi, ma quelle in corso o in coda arrivano dove devono arrivare. Fanno eccezione i limiti di spesa del workflow, che possono interrompere un’esecuzione a metà. → Costi e limiti

È la ragione per cui i destinatari veri si mettono per ultimi, e solo quando il resto funziona.

Chiamare un altro workflow

Chiama workflow avvia un secondo flusso e ne aspetta l’esito. Il workflow chiamato deve essere attivo e pubblicato, e gira la sua versione pubblicata.

• Profondità massima 5. Un workflow che ne chiama un altro, che ne chiama un altro, e così via: oltre il quinto livello la chiamata viene rifiutata.
• Niente cicli. Se il workflow che stai per chiamare è già più su nella catena, la chiamata viene rifiutata. Un workflow può richiamare se stesso una volta sola: A che chiama A va bene, A che chiama A che chiama A no.

Se la chiamata fallisce, il flusso chiamante prosegue con l’errore registrato nel passaggio. Ogni workflow chiamato conta come esecuzione propria verso la quota mensile. → Costi e limiti

Quale definizione gira

Dipende da dove parte l’esecuzione, ed è la differenza che confonde di più.

Progettare tenendone conto

• Spezza le chiamate lente. Se un sistema esterno impiega più di 30 secondi, chiedi l’avvio del lavoro con una chiamata, aspetta con Pausa e chiedi il risultato con una seconda chiamata.
• Non contare su un ritentativo. Dove la chiamata può fallire, metti Aggiungi callback di errore e decidi tu cosa fare.
• Tieni le esecuzioni corte. Il tetto dei 15 minuti vale per il flusso intero, attese comprese. Se ti serve aspettare più a lungo, spezza il lavoro in due workflow e collegali con Chiama workflow.
• Evita di far partire lo stesso workflow in raffica. Con una sola esecuzione per volta, la coda cresce e il ritardo si accumula.