.svg)
La serie “PowerPlatform Pills” è dedicata alla piattaforma progettata per fornire soluzioni intelligenti e flessibili per affrontare le sfide aziendali. Esploreremo diverse funzionalità e tecniche avanzate per massimizzare il potenziale di Power Platform.
La Power Platform di Microsoft offre un ecosistema integrato di strumenti, tra cui Power Apps, Power Automate e Power BI, progettati per semplificare e potenziare la creazione di soluzioni aziendali personalizzate.
“PowerPlatform Pills” è stata pensata per fornire approfondimenti dettagliati e una guida pratica su argomenti chiave, dedicati a un pubblico di sviluppatori, con differenti livelli di esperienza nella piattaforma.
Il primo articolo della serie "Child Flow" è disponibile qui. Il secondo, "How to debug", è disponibile qui. Il terzo, "La delega dell'attività", è disponibile qui.
Code o Low-Code poco importa: una corretta gestione delle eccezioni è essenziale per una soluzione ben costruita.
Infatti, una corretta gestione delle eccezioni, garantisce che il flusso non si interrompa, anche quando si verifica un problema inaspettato.
Nelle mie iniziali esperienze con Power Automate, il meccanismo di Retry mi consentiva di trascurare o almeno minimizzare la gestione delle eccezioni. Tuttavia, non ero mai completamente soddisfatto e tendevo a complicare il flusso per gestire ogni possibile scenario. Con il tempo, ho compreso che anche il flusso più ottimizzato può fallire.
Modelli di gestione applicabili
Spesso, lo sviluppatore si lascia guidare dalla formulazione del requisito, concentrando l'attenzione sul percorso previsto dal flusso di processo e trascurando le rare circostanze che potrebbero interrompere il ragionamento logico; sfortunatamente, un'eccezione sporadica tende a generare più clamore rispetto alle migliaia o milioni di operazioni completate con successo.
Nel seguente articolo, cercherò di descrivere alcuni modelli applicabili per irrobustire i flow. In Power Automate esistono almeno due modelli applicabili per la gestione degli errori:
- Politica di Retry
- Configurazioni di Run after
Un approccio non preclude l'altro; al contrario, la loro integrazione adeguata consente di raggiungere un buon livello di gestione delle situazioni.
Politica di Retry
Il meccanismo di ripetizione (Retry) si attiva in caso di problemi di connessione, quali time-out o superamento delle soglie limite, che possono verificarsi per un eccessivo numero di chiamate API in un breve lasso di tempo.
Questa policy viene applicata agli errori HTTP:
- 408 - Request Timeout
- 429 - Too Many Requests Error
- 5xx - Internal server Error
ed è configurabile dall'area di settings della Action:
Per impostazione predefinita, è consigliabile evitare di indicare esplicitamente quale regola applicare in tali situazioni, ma piuttosto adottare una strategia standard con un numero predefinito di tentativi (quattro di default); tuttavia, se è necessario un intervallo diverso, è possibile impostarlo utilizzando un intervallo definito secondo lo standard ISO 8601.
Esempio di configurazione che setta due tentativi ogni 30 secondi:
P<period>T<time>30<number>S<second>
Se non si desidera ripetere alcuna esecuzione, per disabilitare il criterio di ripetizione, basta impostare il type su None. È fondamentale esaminare attentamente questa configurazione prima di implementarla, poiché potrebbe indirettamente causare problemi di altro tipo.
Configurazioni Run After
Utilizzando le impostazioni Run after dalle configurazioni di un Action, è possibile selezionare quando un'azione deve attivarsi.
Come impostazione predefinita, ogni Action inizia solo dopo che la precedente Action ha avuto successo: questo significa che le situazioni (di insuccesso)che dovremmo gestire sono le nostre "eccezioni", per le quali il flusso fallirà.
Impostazione predefinita
Un caso d'uso
Si vuole ottenere il responsabile di un utente.
Scenario 1: L'utente esiste e ha un responsabile -> l'action viene processata correttamente.
Scenario 2: L'utente non esiste o non ha responsabile, l'azione avrà esito negativo -> il flusso si blocca.
Questo problema può essere facilmente gestito, aggiungendo un ramo parallelo in cui sarà gestito l'esito negativo dell' Action "Get manager (V2)".
Esecuzione con utente che non possiede manager
In evidenza
Da notare il dettaglio (i) e la freccia rossa, che identificano che le impostazioni di default Run after sono variate.
TRY/CATCH/FINALLY
Un ottimo pattern di gestione delle eccezioni è l'adozione dell'Ambito o Scope che ci permettono di gestire situazioni analoghe alla classica Try/Catch, più familiare in ambito di programmazione.
Ma a cosa serve lo Scope? Lo Scope è un modo semplice per correlare azioni e condizioni, come uno stage o una region. Questo è utile perché non solo aiuta nella lettura, ma permette anche di espandere e comprimere il nostro flow, semplificandone la panoramica.
A questo punto fruttando le logiche del Run after, all'action dello Scope, potremmo costituire sezioni di flow analoghi al Try/Catch/Finally.
Dove:
- Try: Sarà lo Scope della logica di business che abbiamo bisogno di processare.
- Catch: Scope eseguito solo quando si verifica un'eccezione mandando l'ambito Try in KO. (Attenzione anche un solo connettore contenuto nello scope per generare un fallimento del Try).
- Finally: Scope sempre eseguito, indipendentemente dal risultato dei due precedenti (facoltativo)
Il vantaggio degli Scopes sono evidenti, poiché raggruppando più azioni, risulterà più semplice gestire un'eccezione che si baserà su tutti i connettori contenuti dallo Scope.
