La serie “PowerPlatform Pills” di 4wardPRO è dedicata alla piattaforma Power Platform, progettata per fornire soluzioni intelligenti e flessibili per affrontare le sfide aziendali.
In questa serie, 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.
Ecco un'anteprima dei primi quattro articoli che affronteremo:
Preparatevi a esplorare le profondità della Power Platform con noi, arricchendo le vostre competenze e scoprendo nuovi modi per ottimizzare i vostri processi di sviluppo. E ora... cominciamo!
Power Automate è un linguaggio considerato Low Code tuttavia, permette di creare agilmente flow enormi e complessi.
Spesso ci si ritrova a scrivere un codice simile sotto varie sezioni, ma quale è il reale costo di questo metodo? E' sufficiente un bug in un passaggio di codice ripetuto più volte nel flow per essere costretti a ripercorrere tutto e riportare la correzione in ogni passaggio. Quindi perché non utilizzare uno strumento in grado di ridurre l'errore e i tempi di sviluppo?
La soluzione che vi propongo, vi aprirà scenari veramente interessanti per ridurre le complessità che, ciclicamente, si incontrano in un progetto.
Immaginate questo use case: è necessario gestire gli accessi ad una lista di Sharepoint, dove ogni riga sarà accessibile in Read Only all'utente indicato da un attributo della stessa riga.
Nome Lista: Test
ID: identity di riga
Assigned: utenza a cui verranno attribuiti diritti di lettura
La gestione dei permessi su una lista è un argomento delicato di un progetto, che spesso obbliga gli sviluppatori a "ripetere" attività identiche su sorgenti dati differenti (nel nostro scenario, i reset dei permessi sull'item).
La soluzione (a) più comune è gestire le grant di permesso sull'item (all'interno di un flow il cui trigger è la generazione di un nuovo item nella lista e, successivamente) e settare al suo interno il permesso. Questo significa clonare il flow per ogni sorgente dati dell'architettura alla quale è necessario applicare questa logica.
Un'altra soluzione (b) è, invece, è mettere a fattor comune la logica che ripeteremmo nella soluzione (a) con un "Child flow" che contenga la sola sezione di "Actions" necessaria a gestire il settaggio dei permessi della riga.
Il Child flow è un normale flusso, che ha come caratteristica in più la possibilità di essere "richiamato" da un altri flow (detti anche Parent Flow). Il Child flow ci aiuta a creare un flusso riutilizzabile, che può essere richiamato in più punti.
Vediamo come utilizzarlo!
Per poter utilizzare un Child Flow è necessario che i flussi che compongono il processo (Child flow e Parents flow) siano contenuti in nella stessa solutions.
1) Child Flow: ManagePermission
2) Parent Flow: When an item is created -> Run a Child Flow
Il Child Flow deve avere un trigger manuale (Istant)
Parametro di input
In questo use case sono indicati i parametri necessari alle action che "gestiscono i permessi".
Parametro di output
Affinché il flusso possa essere utilizzato in un altro flusso (Parent flow), è necessario inviare una risposta che terminerà l'esecuzione del "Child flow". Sarà proprio questo connettore a inoltrare il "body" del risultato al Parent Flow.
L'utilizzo di questo connettore offrirà un ulteriore vantaggio: la delega delle attività ad un utente con privilegi adeguati (ad esempio, un account di servizio).
Eseguendo il flusso, potreste visualizzare il seguente errore:
Update the child flow for action ‘Run_a_Child_flow’ to not use ‘run-only use’ connections
per evitare questo problema è necessario intervenire sull'area amministrativa del Child flow nella sezione "Run only user"
Questa attività è molto utile, perchè permette che l'attività "complessa" di settaggio delle permission sia eseguita con un utente specifico e non con l'utente che ha "attivato" il flow (che normalmente non ha le grant adeguate).
A questo punto il "Child flow" è pronto ad essere richiamato.
Il flow chiamante, sarà infine quello che determinerà i parametri da fornire al "Child Flow".
Il semplice utilizzo del connettore "Run a Child Flow"
permetterà di identificare il "servizio" da chiamare.