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.
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:
Un approccio non preclude l'altro; al contrario, la loro integrazione adeguata consente di raggiungere un buon livello di gestione delle situazioni.
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:
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.
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.
Utilizzando le impostazioni Run after dalle configurazioni di un Action, è possibile selezionare quando un'azione deve attivarsi.
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
Da notare il dettaglio (i) e la freccia rossa, che identificano che le impostazioni di default Run after sono variate.
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:
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.