Determinazione delle tempistiche di configurazione o codificazione
Per gli sviluppatori che si rivolgono alle app basate su Microsoft Power Platform per ottenere una determinata funzionalità per un'applicazione aziendale, la scrittura di codice dovrebbe essere considerata un'eccezione rispetto agli approcci che non prevedono o prevedono un uso limitato di codice. Tuttavia, quando si studia l'approccio migliore per un determinato scenario, andrebbero valutate aree di qualità come la stabilità, le prestazioni e le capacità di manutenzione e di aggiornamento.
È importante conoscere le soluzioni predefinite offerte da Microsoft Power Platform per evitare di creare qualcosa che già esiste e deve semplicemente essere configurato. Ciò vale anche per le funzionalità implementate nelle app Dynamics 365 disponibili. Ad esempio, i calcoli delle fatture che usano listini prezzi multivaluta variabili sono complessi, ma sono ben implementati e ampiamente testati in Dynamics 365 Sales. Se si ha necessità di questa funzionalità, è consigliabile prendere in considerazione l'uso delle funzionalità integrate di Dynamics 365 Sales anziché implementare un motore di calcolo personalizzato.
Inoltre è opportuno riconoscere che spesso Microsoft Power Platform implementa soluzioni con modalità vantaggiose per la piattaforma. Questo effetto potrebbe non essere garantito da un approccio basato sulla scrittura di codice personalizzato per l'applicazione. Spesso gli sviluppatori che non hanno familiarità con la creazione di soluzioni Microsoft Power Platform tentano di personalizzare la piattaforma esattamente come precedentemente creavano le app personalizzate. Questo approccio dovrebbe essere per quanto possibile evitato; al contrario, si dovrebbe cercare di sfruttare le migliori caratteristiche della piattaforma, anziché tentare di adattarla al precedente modo di lavorare. Ad esempio, è possibile che in precedenza si sia implementata la sicurezza a livello di colonna mediante codice personalizzato. Ciò tuttavia non è necessario in Dataverse, in cui la sicurezza a livello di colonna è una funzionalità predefinita che deve essere semplicemente configurata.
Regole di business e script client
Il vantaggio delle regole di business è che sono facili da comprendere e implementare per un utente non pratico di sviluppo ed è possibile includere in una soluzione Dataverse per la distribuzione in produzione. Nelle organizzazioni in cui le competenze degli sviluppatori scarseggiano e Application Lifecycle Management non è implementato, le regole di business costituiscono l'approccio preferibile per implementare la logica, anche se richiedono alcune soluzioni alternative, ad esempio l'uso di campi calcolati intermedi contenenti i valori da verificare in una regola.
Tuttavia, a un certo punto, le regole di business non sono in grado di implementare i requisiti aziendali oppure la complessità introdotta dalle regole induce gli sviluppatori a preferire la scrittura della logica nello script client. Uno scenario potrebbe essere la presenza di logica complessa "if/then/else" annidata che sarebbe meglio implementata in un'istruzione switch o una semplice sequenza di blocchi if. Un altro esempio è quando è necessario gestire valori dinamici non facilmente accessibili da una regola di business. Ad esempio, le notifiche dei moduli e i filtri dei valori di scelta non sono disponibili tramite le regole di business.
Flussi di lavoro/Flussi Power Automate e plug-in
Dataverse offre vari metodi per implementare la logica necessaria per rispondere agli eventi del sistema, in particolare alle modifiche ai dati come la creazione, l'aggiornamento e l'eliminazione delle righe di dati. I requisiti aziendali possono essere soddisfatti mediante soluzioni senza codice che usano il flusso di lavoro e Power Automate e tramite l'estensione di Dataverse con codice lato server (plug-in) o lato client (script).
È possibile valutare le opzioni con un approccio simile a quello usato nella discussione su regole di business e script client, ossia valutando i requisiti aziendali e le capacità di cui dispone l'organizzazione per implementarli. Esistono anche alcune differenze sostanziali tra le funzionalità. La tabella seguente può aiutare a identificare l'approccio preferibile a seconda dello scenario.
| Funzionalità | Flusso di Power Automate | Flusso di lavoro | Plug-in |
|---|---|---|---|
| Sincrona o asincrona | Asincrona | È preferibile usare i flussi di Power Automate rispetto ai flussi di lavoro asincroni | Entrambe |
| Accesso a dati esterni | Sì, tramite l'uso di connettori | No | Sì, tramite l'uso API, con alcune restrizioni di sicurezza |
| Manutenzione | Creatori | Utenti aziendali | Sviluppatori |
| Può essere eseguita come | Utente corrente o proprietario del flusso | Utente corrente o proprietario del flusso di lavoro | Qualsiasi utente con licenza, di sistema o utente corrente |
| Può essere eseguita su richiesta | Sì | Sì | No |
| Può annidare processi figlio | Sì | Sì | Sì |
| Fase di esecuzione | Dopo | Prima/dopo | Prima/dopo |
| Trigger | Creazione, modifica di colonne, eliminazione, su richiesta, su pianificazione | Creazione, modifica di colonne, eliminazione, su richiesta | Creazione, modifica di colonne, eliminazione, altri messaggi inclusi personalizzati |
Dato che Microsoft Power Platform è in continua evoluzione, è opportuno che gli sviluppatori si tengano aggiornati sulle nuove funzionalità e su quelle in arrivo. Ad esempio, se la soluzione richiedeva impostazioni o valori di configurazione personalizzati, in precedenza si sarebbero dovute usare tabelle personalizzate per archiviare questi valori e quindi codice personalizzato o strumenti della piattaforma per distribuire i dati. L'aggiunta di variabili di ambiente ha semplificato questa attività riducendola alla dichiarazione delle variabili, che vengono incluse nelle soluzioni, e all'impostazione dei valori, il tutto senza scrivere codice.
Power Apps Component Framework (PCF)
Per molti anni, le risorse Web HTML sono state un meccanismo di estendibilità ideale per il lato client nelle app basate su modello. Uno dei punti deboli di questo approccio era il basso riutilizzo di questi elementi monolitici e non estendibili. Ora le risorse Web HTML sono state sostituite dai controlli PCF.
PCF permette agli sviluppatori di creare componenti riutilizzabili di cui possono avvalersi i creatori in sostituzione ai controlli standard. Si tratta di un ottimo esempio di come i progressi nelle funzionalità della piattaforma consentano alle aziende di concentrare i propri sforzi di sviluppo sulla creazione di un'infrastruttura solida e sul supporto dei creatori di app.
Sistemi esterni
Le comunicazioni con i sistemi esterni sono una funzionalità comune delle implementazioni delle soluzioni. In precedenza erano di dominio esclusivo degli sviluppatori, sia che riguardassero attività semplici, come l'invio di un messaggio SMS o l'aggiornamento dei tassi di cambio valuta, sia che implicassero scenari complessi, come la sincronizzazione dei dati. Le implementazioni usavano plug-in, pubblicazione di eventi tramite endpoint di servizio e webhook.
Tuttavia, con l'adozione di Power Automate e le centinaia di connettori in esso inclusi, le interazioni con i sistemi esterni possono ora essere implementate dai creatori di app senza usare alcun codice.
Ciò non significa, però, che il ruolo dello sviluppatore sia divenuto superfluo. Esistono molti scenari complessi o ad alte prestazioni in cui è richiesta la scrittura di codice. Inoltre, gli sviluppatori possono ora concentrarsi sulla creazione di servizi e connettori personalizzati, delegando ai creatori la correlazione dei blocchi predefiniti.
Portali e siti personalizzati
Power Pages fornisce numerose funzionalità predefinite e consente ai creatori di realizzare siti Web affidabili e di estenderli in base alle necessità. Spesso, gli sviluppatori offrono supporto per attività del portale più impegnative come layout di pagina sofisticati (con linguaggio dei modelli Liquid) o estendendo le funzionalità del sito front-end tramite JavaScript.
Per scenari altamente specializzati può essere opportuno creare un portale personalizzato completo usando ASP.NET o tecnologie simili. Questo approccio non è raro, ma richiede sviluppatori esperti per l'implementazione. Anche in questo caso, la decisione si basa spesso su un compromesso tra un'implementazione senza codice di funzionalità standard ma generalizzate e l'uso controllato delle risorse dello sviluppatore per fornire funzionalità specializzate.
Stabilire quando usare o meno il codice non è frutto di una semplice decisione binaria. È necessario prendere in considerazione molti fattori: le competenze e le risorse a disposizione, il grado di maturità dell'organizzazione in relazione alla gestione del ciclo di vita delle applicazioni, la complessità dei requisiti e così via. Spesso i requisiti devono essere valutati caso per caso, perché piccoli compromessi nei vincoli aziendali possono semplificare la soluzione e ridurla da progetto di sviluppo complesso a semplice esercizio di configurazione.
Per uno sviluppatore, una conoscenza solida e aggiornata e la comprensione delle funzionalità della piattaforma sono essenziali per decidere, in modo razionale ed equilibrato, quando usare il codice e quando, invece, adattare il sistema in modo che possa essere personalizzato e configurato dai creatori e dagli utenti aziendali.