Seguendo la prima e la seconda parte della guida, siamo giunti ad avere una App funzionale e snella, con una piacevole interfaccia, dotata anche di un pratico lettore di codici a barre. Questo non è però sufficiente per distribuire una App di sicuro successo: una volta impostate le funzionalità principali dell’App, è necessario eseguire delle operazioni di ottimizzazione, per evitare di avere sorprese soprattutto con le operazioni sui dati.
Vedremo come ottimizzare la nostra app focalizzandoci su questi punti chiave:
- Local gateway versus API
- Criticità del connettore SQL
- Trucchi per un binding efficace
- La centralità dei dati
- Restituire un report cartaceo
Indice degli argomenti
Local gateway versus API
Uno dei vantaggi più lampanti dell’ambiente Power Automate è la possibilità di accedere ai dati del database SQL on premise senza la necessità di sviluppare e mantenere complesse API (Application Programming Interface, ossia delle funzioni esposte via web capaci di eseguire diverse operazioni, tra cui recuperare dati).
Power Automate offre, come abbiamo visto, la possibilità di bypassare questa complessità installando un Local gateway sul server su cui risiede il database SQL. Occorre, però, anche nel caso del Local Gateway, prestare alcune attenzioni, soprattutto a dimensionare correttamente le capacità del server in termini di RAM e CPU, per evitare fastidiosi lag nella velocità di accesso ai dati da parte dell’App. Inoltre, occorrerà coordinare correttamente con il reparto IT eventuali riavvii del server, per impedire che gli utilizzatori dell’App si ritrovino improvvisamente senza l’accesso alle loro informazioni.
Criticità del connettore SQL
Anche nell’utilizzo del connettore SQL bisogna prestare poche ma decisive attenzioni. Innanzitutto, occorre definire correttamente la strategia di autenticazione. A differenza delle API, che solitamente gestiscono l’autenticazione con un token o sistemi più complessi, il connettore SQL vi permette di autenticare l’App alla base dati utilizzando la password root di SQL Server oppure utilizzando gli account di Active Directory. Nel primo caso si ottiene la maggiore comodità in fase di configurazione, ma bisogna prestare attenzione al fatto che qualsiasi utente dell’App avrà accesso al database con privilegi altissimi, e che incorporerete nell’App una delle password più delicate per la sicurezza del sistema informatico dell’azienda. Nel secondo caso, invece, occorrerà gestire la manutenzione dei profili AD, ma con il vantaggio che la password del SQL Server verrà preservata da ogni interazione.
Trucchi per un binding efficace
Una volta che il connettore SQL è configurato correttamente, i dati iniziano a essere esposti ai controlli presenti sull’interfaccia dell’App. I controlli ricevono i dati dal connettore per mezzo di un meccanismo di binding, simile a quello dei programmi Visual Basic .Net o Xamarin, che popola i controlli, offrendo all’utente piena possibilità di effettuare operazioni CRUD (Create, Read, Update, Delete, ossia le universali operazioni di manipolazione dati).
Il binding, però, potrebbe presentare delle particolarità a seconda dei controlli. In alcuni casi, infatti, potrebbero verificarsi limiti nel numero di record recuperabili, oppure, in altri casi, potrebbe risultare scomodo effettuare operazioni di rimappatura tra campi della tabella e controlli già precedentemente associati ad altri dati. In questi casi è necessario effettuare un’operazione di refresh sul connettore, in modo che la base dati venga riletta e riassociata correttamente. L’operazione di refresh è ancora più necessaria nel caso che si effettuino delle modifiche allo schema dei dati sottostanti, proprio per far ricevere all’App la versione più aggiornata della base dati.
La centralità dei dati
Come si può facilmente dedurre dai capitoli precedenti, è fondamentale, quando realizziamo una App, ragionare partendo dai dati e plasmando l’interfaccia in accordo ai processi che derivano dalle informazioni presenti sul database. Un corretto design dell’interfaccia e del binding con il database è infatti cruciale per una buona riuscita globale dell’App. Questo aspetto è così importante che Power Apps offre anche delle procedure guidate (Wizard) per creare l’interfaccia dell’App senza doverla disegnare, ma derivando ogni suo elemento dal collegamento con la base di informazioni. Questa funzionalità è incredibilmente comoda anche se si decide di utilizzare come basi dati le liste di Share Point.
Restituire un report cartaceo
Come capitolo conclusivo della guida, vedremo velocemente come gestire una richiesta che, per quanto stoni con il contesto digitalizzante dell’App, potrebbe venirvi comunque rivolta, visto l’ambiente On Premise su cui abbiamo fondato la nostra applicazione di logistica. Se qualche operatore un po’ più legato alle vecchie abitudini dovesse sentire il bisogno di stringere tra le mani un report cartaceo, in questo caso ci sono diverse strade percorribili per accontentarlo. Senza complicarsi la vista con la reportistica avanzata lato SQL, si potrebbe pensare di interfacciare i dati presenti nel connettore con un cruscotto Power BI, soluzione di analisi dati offerta nativamente dall’ambiente Power Platform, e da questa salvare in formato PDF un report. In alternativa, si potrebbe anche realizzare un flusso Power Automate, richiamabile con un pulsante In App, che esporti dei dati in formato PDF, salvando il report su Share Point, o Drive, da cui poi potrebbe essere stampato.
Partecipa alla community