.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 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.
Le variabili in Power Platform: cosa sono
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.
Best Practices per le variabili in Power Platform?
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.
Come utilizzare le variabili in Power Platform?
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.
Vantaggi e svantaggi delle Environment Variables
Ecco una lista dei principali vantaggi delle Environment Variables:
- Controllo: le Environment Variables consentono di gestire i valori che vengono utilizzati in un'applicazione o in un flusso in un unico punto, rendendo più semplice la modifica di questi valori se necessario.
- Migliorare la manutenibilità: utilizzando le Environment Variables, è possibile evitare la duplicazione di valori in tutta l'applicazione o il flusso, rendendo l'applicazione più facile da mantenere e modificare.
- Semplificare il testing: le Environment Variables consentono di testare l'applicazione o il flusso utilizzando valori diversi senza dover modificare manualmente ogni singola istanza.
Tuttavia, ci sono anche alcuni svantaggi da considerare:
- Complessità: l'utilizzo delle Environment Variables può aumentare la complessità dell'applicazione o del flusso, poiché è necessario creare un ambiente e gestire le variabili.
- Possibilità di errore: se le variabili non vengono gestite correttamente, è possibile che si verifichino errori nell'applicazione o nel flusso.
- Inside solutions: La loro adozione è possibile solo dentro le soluzioni.
Creare una variabile d'ambiente in una soluzione
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:
- Display Name: Nome per la variabile di ambiente.
- Name: Nome univoco che viene generato automaticamente dal Display Name (può essere modificato).
- Data Type: Tipologia della variabile. (Decimal, Text, JSON, Bool, Data Source* o Secret*).
- Current Value: Quando presente, è il valore che verrà utilizzato nell' Enviroment. In fase di migrazione da un Env1 a Env2 è il parametro che dovrà essere eliminato affinché l'importazione nel nuovo ambiente richieda il valore da applicare al nuovo ambiente.
- Default Value: Viene preso in considerazione SE non esiste alcun Current Value.
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.
Nella soluzione d'esempio, userò 2 variabili d'ambiente e un flusso Power automate
La prima variabile che predisporremo è Sito_P1.
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.
- Aggiunta di tutte le referenze nella soluzione – Questo passaggio è necessario, affinché, durante lo spostamento della soluzione, siano incluse tutte le referenze e i componenti utilizzate dal nostro processo e necessari al funzionamento anche sull’Environment di destinazione.
- Rimozione del valore preimpostato su ogni variabile - Questo passaggio è necessario affinché durante l'importazione della soluzione venga richiesta la risoluzione delle variabili d'ambiente riferite al nuovo ambiente.
Ripetere il passaggio su ogni variabile
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.
