Gestire l'ambiente di DEV e PROD SharePoint in Power Automate

Quando si accede alle liste SharePoint Online da Power Automate come in questo caso

ovvero si seleziona il sito a cui accedere e la lista, in realtà Power Automate non salva il nome della lista, ma salva il GUID.

Infatti esportando il flow e guardando all'interno dello zip si può vedere che effettivamente viene salvato solo il GUID, attributo table

Questo impedisce di il porting, in modo semplice, di un flow Power Automate da un sito di DEV ad uno di produzione, in quanto non è possibile definire il GUID della lista, viene assegnato in modo automatico da SharePoint.

Il passaggio è possibile solo reimportando il flow con un altro nome e poi cambiando i riferimenti alle liste a mano, ovviamente più aumentano le action di tipo SharePoint più la cosa si complica e soggetta ad errori.
Inoltre quando si aggiorna un flow esistente in PROD, si fa disservizio finché non si finisce di aggiornare i riferimenti alle liste.

In alternativa si può usare uno script PowerShell come Come spostare un flow con connessioni SharePoint.

Soluzione

Un soluzione alternativa è cercare di rendere il flow Power Automate nativamente adattabile ai due ambienti di DEV e PROD.

Variabili

La prima cosa da fare è rendere dinamica la url del sito definendo una variabile (SpSiteUrl) per contenere l'indirizzo

questo rende veloce il cambiare la url dal sito di DEV a quello di PROD, soprettutto se si hanno decine di action SharePoint.Ovviamente in questa situazione il nome della lista non è molto parlante, quindi va risolto il problema.

Si può definire una nuova variabile (TodoListId) con nome parlante che conterrà il GUID della lista.

In questo modo il flow è chiaro a chiunque debba fare manutenzione.

Risolvere il nome della lista

Comunque anche così non è molto pratico, quando si fa il passaggio in produzione va comunque cambiata la variabile ListId.
Inoltre più liste vengono usate nel flow più variabili devono essere aggiornate ad ogni passaggio in PROD.

Meglio trovare un modo più pratico.
Il trucco è riferirsi alla lista con il nome interno, lasciando a Power Automate il compito di trovare il corretto GUID in base al sito.

Per far questo usiamo l'action Send an HTTP request to SharePoint, che usiamo per cercare la lista per nome interno (EntityTypeName ) in modo da trovare il relativo GUID (Id).

Nella action inseriamo la url

URLCopia

_api/web/lists?$filter=EntityTypeName eq 'TodoListList'&$select=Id,EntityTypeName

nel caso di più liste i nomi interni vanno messi in OR

URLCopia

_api/web/lists?$filter=EntityTypeName eq 'TodoListList' or EntityTypeName eq 'OtherName'&$select=Id,EntityTypeName

e tramite l'action Apply to each e Switch si assegna il valore alla variabile corretta.
Di seguito si potrà fare riferimento alle liste tramite le rispettive variabili.Per trovare il valore di EntityTypeName immettere nel bowser questa url

URLCopia

https://tenant.sharepoint.come/sites/nomeSito/_api/web/lists?$select=Id,EntityTypeName

Questo è un esempio di JSON ritornato

JSONCopia

{
  "value": [
    {
      "EntityTypeName": "TodoListList",
      "Id": "82832c39-xxxx-xxxx-xxxx-6c2f26dc7909"
    },
    {
      "EntityTypeName": "TodoListCategoriesList",
      "Id": "023e9490-xxxx-xxxx-xxxx-37841185eb0e"
    }
  ]
}

Rendere dinamica la url del sito

E' possibile fare un ulteriore passaggio, rendere dinamica anche la variabile SpSiteUrl.

Ovviamente serve un criterio, ad esempio ci si può basare sul nome del flow per cambiare la url.
Supponiamo che il flow si chiami Test Flow in PROD, mentre in DEV useremo il prefisso DEV - , quindi il nome diventerà DEV - Test Flow.

Il nome del flow lo si può ricavare tramite l'espressione

Power Automate: Flow display nameCopia

workflow()['tags/flowDisplayName']

A questo punto verificando se il nome inizia per DEV - possiamo impostare una variabile Enviroment con la stringa DEV oppure PROD

Power Automate: Variabile EnviromentCopia

if(equals(indexOf(variables('WorkflowDisplayName'),'DEV -'), 0), 'DEV', 'PROD')

Ora con questa variabile possiamo impostare la url del sito nella variabile SpSiteUrl

Power Automate: Variabile SpsiteUrl dinamicaCopia

if(equals(variables('Enviroment'), 'PROD'), 'https://tenantName.sharepoint.com', 'https://tenantName.sharepoint.com/sites/dev')

E con questo il flow è completo e si adatta all'ambiente solo tramite il nome del workflow.

Quindi si può esportare un flow da DEV, reimportarlo con il nuovo nome in PROD e tutto funziona, ma...

C'è ancora una miglioria da apportare, controllare il prefisso DEV - nel nome è pratico, veloce e adattabile a qualunque flow, ma un banale errore di sintassi potrebbe, erroneamente, far lavorare il flow in produzione con conseguenze imprevedibili.

Molto meglio rafforzare il test della variabile Enviroment controllando esattamente il nome del flow di produzione, in questo modo eventuali errori di sintassi non fanno danni in quanto il flow punterà sempre a DEV.

Power Automate: Variabile Enviroment test con nome esattoCopia

if(equals(variables('WorkflowDisplayName'),'Test Try Catch'), 'PROD', 'DEV')

Trigger

Volendo, inn caso di trigger su una lista SharePoint, la url del sito la si può ricavare dai parametri di input

tramite la formula

Power AppsCopia

trigger()?['inputs']?['parameters']?['dataset']

Conclusione

Con queste pre-impostazioni qualunque flow Power Automate con action SharePoint Online può essere spostato da una site collection ad un altra (DEV to PROD) senza nessun intervento dell'utente se non l'azione di export e import con rename.

Nota

Il metodo esposto funziona bene in caso in cui il tenant ha un unico ambiente (Enviroment) Power Automate ovvero quello di Default

Nel caso in cui si ha un ambiente dedicato per la produzione, la soluzione migliore è creare i flow all'interno di una solution Power Automate ed esportare e importare la solution.

In questo caso lo scenario cambia, anziché definire all'interno di ogni singolo flow un variabile per ogni lista, e leggere i valori dinamicamente, si posso usare le variabili a livello di ambiente.
Queste variabile possono essere impostate la prima volta che si importa la solution nel nuovo ambiente e mantengono i valori anche in caso di update.