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 e il quarto "La gestione delle eccezioni in Power Automate" qui.
Oggi voglio parlare di un argomento a mio avviso semplice quanto fondamentale, ma che spesso viene ignorato dagli utenti alle prime armi, anche se, in realtà è utilissimo per semplificare il lavoro con le Power Platform.
Normalmente le variabili sono il primo concetto che si acquisisce in qualsiasi linguaggio, mentre non mi è ancora chiaro del perché (sulla Power Platform) spesso questa peculiarità viene acquisita solo con una certa seniority.
Immagate di attaccare un post-it ad un oggetto: come un post-it, una variabile d'ambiente consente di memorizzare informazioni importanti, in modo che siano facilmente accessibili quando necessario. Come un post-it, una variabile d'ambiente può essere utilizzata in diverse situazioni, rendendo le informazioni disponibili e pronte all'uso senza doverle cercare o replicarle ogni volta.
Il nome dice tutto! Sono "variabili" e in quanto tali ci supportano a relativizzare un parametro in un'applicazione o in un flusso, permettendoci di gestire un cambiamento senza impattare troppo sul processo. Ad esempio, una variabile potrebbe contenere l'indirizzo e-mail del destinatario di un messaggio, o il nome di un database. In questo modo, è possibile modificare facilmente questo valore in un unico punto e vederlo riflesso in tutta l'applicazione o il flusso, senza la necessità di modificare manualmente ogni singola istanza.
La loro adozione, insieme all'uso delle soluzioni fanno parte delle best practices dell'Application Lifecycle Management (ALM), per semplificare la gestione delle configurazioni e delle informazioni relative all'ambiente di sviluppo, test e produzione.
Infatti, consentono di memorizzare informazioni specifiche per ciascun ambiente, come ad esempio l'indirizzo della sorgente dati o le credenziali di accesso a servizi di terze parti (esattamente come avviene nei vostri .config). In questo modo, i tecnici possono scrivere il codice una sola volta, utilizzando queste variabili per differenziare le configurazioni dell'ambiente. Questo approccio semplifica il processo di deployment e di testing, poiché le configurazioni dell'ambiente possono essere gestite separatamente dal codice e aggiornate facilmente senza la necessità di modificare il codice del nostro flow o delle nostre Power Apps (questo è un tema che approfondiremo successivamente).
Quindi, anche se potrebbe sembrare un argomento secondario, sono uno strumento potente e utile per facilitare la gestione dei nostri processi.
Una volta identificata la soluzione per la quale creare il processo, al suo interno saranno accessibili funzionalità di creazione di alcuni oggetti, tra i quali le "variabili d'ambiente". Questo a mio avviso è un limite, ma purtroppo le variabili possono esse utilizzate solamente dentro una soluzione (che è già di per sé una best practices, quindi abituatevi a creare soluzioni!)
Nel dettaglio, ogni variabile ha un nome univoco, una tipologia e un valore che può essere modificato in qualsiasi momento.
Ecco una lista dei principali vantaggi delle Environment Variables:
Tuttavia, ci sono anche alcuni svantaggi da considerare:
Partendo sempre dalla soluzione, sulla barra dei comandi selezionare: NEW → More → Environment Variable
NEW → More → Environment Variable
Si attiverà un Panel sulla destra che richiederà alcune informazioni riferite al nostro parametro:
Di seguito un caso d’uso che mostra come implementare un processo, adottando le variabili d’ambiente.
Obbiettivo: Migrazione della soluzione da un Enviroment ad un altro.
Pre-requisito: predisposizione della stessa lista usata nella business del flow su 2 siti SharePoint Online differenti. la prima con nome ListDemo, mentre la seconda ListDemoEnv2.
Questa variabile indicherà il percorso della nostra sorgente dati, nel mio scenario userò una lista su un sito SharePoint.
La seconda variabile è Lista_P1 relativa alla lista, su cui vorrei intervenire nel nostro flusso.
Questa seconda variabile avrà come riferimento del "Site" esattamente la variabile d'ambiente Sito_P1 (che a questo punto sono già entrate in gioco).
Il processo è composto da un semplice flow nominato LetsGO (potrebbe essere 1, 10 oppure 100… non cambierebbe nulla).
Nel flusso di Power Automate, è stata aggiunta un'azione "Get Items" di SharePoint. Nei parametri necessari per indicare il sito e la lista sono state utilizzate le variabili d'ambiente precedentemente configurate.
Per maggiore chiarezza nella presentazione dei dati, aggiungerò anche un'azione che consente di organizzare i dati estratti dalla "Get Items" in una struttura più leggibile rispetto al classico output Json.
L’esito dell’esecuzione del flow sul primo Enviroment sarà, quindi, basato sul contenuto risolto dalle variabili d’ambiente che abbiamo istanziato.
Ora proviamo a testare lo stesso comportamento migrando la nostra soluzione su un nuovo Environment.
Pre-condition (Deploy) - Prima di deployare sul secondo Environment la nostra soluzione, è opportuno avere un paio di accorgimenti:
Nel nostro scenario, avevamo un flow che sfrutta 2 referenze (le nostre 2 variabili d’ambiente).
Ripetere il passaggio su ogni componente della soluzione.
A questo punto possiamo procedere con l’export dall’ambiente 1 del pacchetto
Nota tecnica: la procedura di export vi chiederà di scegliere se esportare la soluzione come gestita o non gestita (questo è un tema che approfondiremo successivamente); tuttavia non è fondamentale per l’esito del nostro test. Procedete con l’esportazione non gestita.
Per la relativa importazione sull’ambiente 2
come anticipato, vi verrà chiesto di risolvere le 2 variabili d’ambiente precedentemente configurate.
Di seguito come ho riconfigurato le mie:
Terminati questi passaggi, la soluzione è già pronta per essere utilizzata con i nuovi puntamenti.
E come possiamo constatare dall’output, i metadati questa volta arriveranno dal secondo ambiente.
Sono certo che riconoscerete presto come queste variabili d’ambiente diventeranno strumenti indispensabili per una gestione efficiente dei processi.