Automazione dei processi
Workflow durevoli: progettare automazioni capaci di ripartire
Un'automazione aziendale raramente coincide con una sola richiesta. Può acquisire un documento, attendere un servizio esterno, ricevere una conferma e completare una registrazione dopo un intervento umano. Se il programma si interrompe tra questi passaggi, riavviarlo non basta: occorre sapere che cosa sia già avvenuto e quale azione resti legittima. I workflow durevoli affrontano questa continuità dell'esecuzione, ma la loro efficacia dipende da come vengono progettati stato, effetti e procedure di recupero.
Descrivere il lavoro come una sequenza di stati riconoscibili
Il progetto inizia distinguendo gli stati del processo dalle attività che il software esegue. Acquisito, in elaborazione e completato possono essere insufficienti se nascondono attese diverse. Una pratica in attesa di risposta esterna richiede un intervento differente da una pratica da correggere. Ogni stato dovrebbe indicare quale condizione lo ha prodotto, quali eventi possono modificarlo e chi può agire. Questa descrizione rende visibili anche gli esiti intermedi che un semplice elenco di chiamate non rappresenta.
Un esempio di progetto è l'invio di un documento a un servizio esterno. Preparazione, richiesta inviata, esito confermato ed esito incerto sono situazioni distinte. Se la connessione cade dopo l'invio, dichiarare il documento fallito potrebbe autorizzare una ripetizione impropria. Il sistema deve poter conservare l'incertezza e avviare una verifica. Gli stati non devono diventare un catalogo infinito: servono quelli che cambiano una decisione, una responsabilità o il modo in cui il lavoro può riprendere.
Persistenza dell'esecuzione e ricostruzione dello stato
Conservare soltanto l'ultimo messaggio di errore non permette di ricostruire un processo interrotto. Occorre sapere quali attività sono state pianificate, quali hanno restituito un risultato e quali eventi sono arrivati. Alcuni motori di orchestrazione usano una cronologia persistente per ricostruire l'esecuzione. La documentazione Microsoft sulle orchestrazioni durevoli illustra un modello che registra la storia e riproduce il percorso usando risultati già acquisiti. La specifica tecnologia va valutata rispetto al carico e alle competenze del gruppo, evitando di confondere il modello con una garanzia universale.
Anche con una piattaforma dedicata restano decisioni applicative. Bisogna stabilire l'identità della singola istanza, il legame con il documento e la gestione di una richiesta avviata due volte. Un identificativo casuale nuovo a ogni ricezione può creare due processi per la stessa operazione. È utile separare l'identità del messaggio dall'identità dell'intenzione aziendale, mantenendo una regola esplicita per distinguere una ripetizione tecnica da una nuova richiesta valida. La conservazione di queste informazioni deve accompagnare il ciclo operativo previsto.
Separare le decisioni dagli effetti che non si possono ripetere liberamente
Un motore basato sulla riproduzione della cronologia richiede particolare disciplina nel codice che decide il percorso. La documentazione Microsoft sui vincoli degli orchestratori spiega perché tale codice debba essere deterministico e perché letture dell'orologio o altre operazioni non deterministiche richiedano le API appropriate del framework. Un accesso esterno inserito nel punto sbagliato può cambiare il risultato della ricostruzione. Il gruppo deve quindi comprendere quali parti vengono riprodotte e quali attività vengono eseguite separatamente, senza trasferire queste regole indistintamente a ogni componente.
L'effetto esterno richiede comunque protezioni proprie. Se un'attività invia una richiesta e si interrompe prima di registrarne l'esito, l'orchestrazione può doverla eseguire nuovamente. Una chiave idempotente, un controllo dello stato presso il destinatario o una riconciliazione possono ridurre il rischio di duplicazione, secondo il contratto disponibile. Il requisito va verificato sul sistema reale: la persistenza del workflow non rende automaticamente ripetibili tutte le operazioni che esso coordina, né sostituisce la responsabilità del destinatario nel riconoscere richieste già elaborate.
Rendere durevoli le attese e gestire le risposte tardive
Attendere una risposta per ore non dovrebbe significare mantenere un thread occupato per tutta la durata del processo. Un'attesa persistente conserva la condizione da soddisfare e permette all'esecuzione di riprendere quando arriva un evento o scade il termine. I motori offrono meccanismi differenti, da verificare nella documentazione scelta. Dal punto di vista applicativo occorre definire il momento da cui decorre l'attesa, il riferimento temporale usato e il comportamento dopo un fermo che attraversa la scadenza.
Il caso più istruttivo è la risposta che arriva dopo il termine. Il processo potrebbe essere già passato a una verifica manuale o essere stato annullato. Accettare comunque l'evento può riaprire un lavoro ormai concluso; scartarlo senza traccia può perdere un'informazione utile. La transizione deve controllare lo stato corrente e riconoscere gli eventi già consumati. Per le interazioni umane è importante legare la risposta alla revisione dell'oggetto su cui era stata richiesta, così che una conferma vecchia non venga applicata a dati cambiati nel frattempo.
Assegnare ai tentativi un limite e una destinazione finale
Un errore temporaneo di rete e un contenuto non valido non richiedono la stessa reazione. Prima di ripetere un'attività bisogna classificare le condizioni e stabilire quali siano correggibili automaticamente. La documentazione AWS Step Functions mostra politiche che distinguono tipi di errore, intervalli e numero di tentativi, con percorsi di gestione successivi. Il criterio utile al progetto è associare ogni classe di problema a un comportamento esplicito, includendo ciò che accade quando i tentativi sono esauriti.
Il limite deve considerare anche la durata complessiva accettabile e il carico sul servizio destinatario. Ripetizioni troppo ravvicinate possono aggravare un'indisponibilità; tentativi prolungati possono mantenere aperta una pratica che avrebbe già richiesto una decisione. L'uscita dalla ripetizione deve produrre uno stato comprensibile, con contesto e proprietario. L'intervento umano dovrebbe poter correggere il dato o scegliere un'azione prevista, senza modificare direttamente il database e senza cancellare la storia delle esecuzioni precedenti per ottenere un nuovo tentativo.
Compensare gli effetti senza fingere un ritorno al passato
Un processo distribuito può produrre effetti in sistemi che non condividono una transazione unica. Se una fase successiva fallisce, non sempre è possibile annullare tutto. Una compensazione è un'azione esplicita che gestisce la conseguenza di un effetto già avvenuto: può liberare una risorsa riservata o avviare una rettifica, secondo le regole del dominio. Non deve essere descritta come un ripristino perfetto se conserva differenze, genera notifiche o richiede una decisione esterna.
Anche la compensazione può fallire o arrivare due volte. Richiede quindi stato, riconoscimento delle ripetizioni e una procedura di escalation. Per ciascuna attività è utile annotare effetto, evidenza disponibile, azione compensativa e condizioni che la impediscono. Dove manca una via automatica affidabile, il processo dovrebbe dichiarare la necessità di riconciliazione manuale. L'obiettivo è rendere governabile una situazione parziale, con un responsabile e informazioni sufficienti a decidere, anziché mantenere indefinitamente un errore generico che nessuno sa risolvere.
Far evolvere il codice mentre esistono istanze ancora aperte
Un workflow può durare più della versione applicativa che lo ha avviato. Cambiare la sequenza delle attività o il significato di uno stato può rendere incompatibile una cronologia esistente con il nuovo codice. La strategia di rilascio deve perciò distinguere le nuove istanze da quelle ancora in corso. Possibili scelte progettuali sono mantenere temporaneamente due versioni, usare i meccanismi di compatibilità del motore oppure migrare soltanto gli stati per cui esiste una trasformazione verificata.
Il contratto con i sistemi collegati fa parte della stessa valutazione. Il sito di prodotto descrive il perimetro delle API e dei Web Services di Gestionale sul Web; disponibilità delle operazioni, limiti e modalità di verifica degli esiti devono essere controllati per la specifica integrazione. I modelli di orchestrazione trattati qui sono criteri generali di ingegneria e non attestano una particolare implementazione interna del prodotto. La compatibilità si dimostra seguendo un processo attraverso la transizione, inclusi gli eventi arrivati in ritardo.
Collaudare la ripresa prima di affidarsi all'automazione
Il collaudo dovrebbe interrompere il sistema nei punti in cui l'esito diventa incerto: dopo una richiesta esterna, prima di salvare una conferma, durante un'attesa e mentre viene applicata una compensazione. Per ogni prova si prepara il risultato atteso e si verifica la ripresa senza introdurre un secondo effetto non previsto. Vanno aggiunti eventi duplicati, risposte tardive e due esecuzioni concorrenti della stessa intenzione. Le prove devono osservare gli archivi coinvolti, non soltanto la risposta finale dell'orchestratore.
Un progetto circoscritto permette di verificare anche il lavoro dell'assistenza: trovare l'istanza, riconoscere la fase, comprendere la causa dell'arresto e applicare una procedura autorizzata. Il flusso è pronto a essere esteso quando la ripresa è comprensibile e ripetibile, con evidenze utili a distinguere completamento, attesa e riconciliazione. La durata dell'esecuzione diventa così una proprietà progettata del sistema, anziché un insieme di eccezioni gestite di volta in volta dalle persone che conoscono il codice.
Riferimenti tecnici
Per approfondire i temi tecnici trattati:
- Microsoft Learn — orchestrazioni durevoli e cronologia dell'esecuzione
- Microsoft Learn — vincoli del codice degli orchestratori e determinismo
- AWS Step Functions — gestione degli errori, tentativi e percorsi di recupero
A cura della redazione tecnica SoftJob. Pubblicato il .