Condividi tramite

Ottimizzare le prestazioni delle app canvas che richiedono una logica di business complessa

Poiché le organizzazioni si basano sempre più su Power Platform per creare applicazioni scalabili basate sui dati, la scelta dell'approccio appropriato per l'implementazione della logica di business diventa fondamentale. Questa architettura di riferimento presenta due opzioni, ovvero le funzioni Power Fx e le API personalizzate di Dataverse, per ottimizzare le prestazioni e la gestibilità nelle applicazioni canvas di Power Apps.

Scenario

Per impostazione predefinita, quando un'applicazione esegue query su dati o esegue più modifiche, invia singole richieste di rete HTTP a Dataverse. Dataverse restituisce dati all'applicazione e la logica dell'applicazione la elabora.

Questo modello di implementazione causa tempi di attesa, soprattutto quando l'app invia più richieste, ad esempio in una funzione ForAll. Il tempo di attesa influisce negativamente sulle prestazioni e sull'esperienza utente. Ad esempio, se l'app recupera e trasforma i dati più volte in un ciclo ForAll, il tempo di attesa complessivo può diventare sostanziale, causando un'esperienza utente lenta e inefficiente.

Per ottimizzare l'interazione dei dati, spostare la logica e le operazioni di recupero dei dati dall'app Canvas a Dataverse utilizzando API personalizzate di Dataverse o funzioni Power Fx. Le operazioni di modifica dei dati sono completate all'interno di una transazione, garantendo la coerenza dei dati in caso di errore.

Suggerimento

Questo articolo fornisce uno scenario di esempio e un'architettura di esempio generalizzata per illustrare come le app canvas che usano Dataverse possono spostare logica di business complessa in API personalizzate di Dataverse e funzione Power Fx per migliorare le prestazioni. È possibile modificare l'esempio di architettura per molti scenari e settori diversi.

Diagramma dell'architettura

In questo diagramma, le funzioni di Power Fx vengono usate per spostare una logica di business complessa dall'app canvas a Dataverse. È anche possibile usare un'API personalizzata Dataverse per ottenere lo stesso risultato. Fare riferimento a Raccomandazioni per decidere quale opzione usare.

Diagramma dell'architettura che mostra la differenza tra l'uso delle funzionalità predefinite dell'app canvas per le operazioni sui dati e l'uso delle funzioni Power Fx.

Flusso di lavoro

  1. L'applicazione canvas di Power Apps usa Dataverse per gestire l'allocazione delle risorse. L'app usa una funzione Power Fx (un'API personalizzata dataverse serve allo stesso scopo) per operazioni di dati pesanti anziché usare direttamente le funzionalità di accesso predefinite. L'app usa ancora funzionalità predefinite di Dataverse per operazioni e attività di dati con volume inferiore che non richiedono il supporto transazionale.

  2. La funzione Power Fx (con l'API personalizzata Dataverse) è configurata per passare i parametri di input dall'app chiamante e ricevere il risultato (parametri di risposta) dalla funzione (o dall'API) tramite parametri di output definiti. Per:

    • Funzione Power Fx (anteprima): Implementare la logica in Power Apps Studio. Usando le funzioni di Power Fx, i creatori possono costruire una logica complessa con poca o nessuna competenza di codifica. Per altre informazioni, vedere Funzioni Power Fx.

    • API personalizzata dataverse: Implementare la logica creando un plug-in .NET dataverse. I plug-in .NET personalizzati richiedono maggiori conoscenze di codifica, ma offrono maggiore controllo ed estendibilità. Per altre informazioni, vedere API personalizzate di Dataverse.

Dettagli del caso d'uso

Power Apps consente alle organizzazioni di creare esperienze utente personalizzate e centralizzare la logica di business. Usando Power Apps, è possibile ottenere un'architettura dei dati più efficiente e ridurre il carico di lavoro sul lato client.

Nell'esempio seguente l'applicazione canvas di Power Apps consente agli autori di allocare in modo efficiente le risorse ai team e alle attività. È possibile applicare questo modello di architettura a scenari simili in cui l'applicazione canvas include operazioni sui dati e richiede:

  • Più cicli nell'app canvas, che non è possibile ottenere usando la funzionalità Concurrent.
  • Calcoli intensivi per più trasformazioni di dati.
  • Tempo di esecuzione coerente, indipendentemente dal numero di elementi in un ciclo o dalla connessione Internet dell'utente.
  • Coerenza dei dati tra più operazioni di modifica dei dati.

Per allocare le risorse, un autore deve specificare le posizioni, le attività, le sottoattività e altri metadati correlati dell'allocazione. Nell'app canvas la schermata "Panoramica delle risorse" mostra più livelli di dati correlati, ad esempio:

  • Risorse
    • Posizione
      • Attività
        • Sottoattività
          • Approvazione

Per raggiungere questo obiettivo, è possibile implementare la logica dell'applicazione usando Power Fx come indicato di seguito:

ForAll(Resources,
    //Transformations
    ForAll(Location,
        //Transformations...
        ForAll(Tasks,
            //Transformations ...
        )
    )
)

Questa logica genera più chiamate HTTP a Dataverse quando l'applicazione viene eseguita. Sebbene la procedura consigliata consiste nel consolidare i dati nelle visualizzazioni Dataverse o usare funzioni simultanee o altre tecniche di Power Fx, questo approccio non è sempre possibile o non soddisfa gli obiettivi di prestazioni.

Per risolvere questo problema, eliminare più chiamate HTTP dall'app canvas spostando la trasformazione dei dati, l'elaborazione dei dati e i risultati necessari, in una singola risposta. Questo approccio riduce il tempo di attesa per il recupero dei dati, migliora le prestazioni complessive dell'app canvas e offre un'esperienza utente più fluida e reattiva. Centralizzando la logica di trasformazione dei dati, si garantisce un'elaborazione coerente ed efficiente sul lato server, che rende la soluzione scalabile per grandi volumi di dati e trasformazioni complesse.

Options

Sia le API personalizzate di Dataverse che le funzioni Power Fx estendono la logica di business di Dataverse.

Funzioni Power Fx

Una funzione Power Fx crea un'astrazione della funzionalità API personalizzata Dataverse che puoi utilizzare con Power Fx per la logica.

Le funzioni di Power Fx estendono la logica di business di Dataverse e possono essere richiamate su richiesta da componenti di Power Platform come app canvas di Power Apps, flussi di Power Automate e da agenti personalizzati creati con Microsoft Copilot Studio. Questa funzionalità supporta l'implementazione di una logica più semplice che non è abbastanza complessa da richiedere l'uso della funzionalità API personalizzata dataverse completa.

API personalizzate di Dataverse

Un plug-in Dataverse è un gestore eventi personalizzato che viene eseguito in risposta a eventi specifici. Nel caso di un'API personalizzata dataverse, quando si definisce l'API, viene creato un evento personalizzato generato dall'applicazione quando usa l'API. Questi plug-in vengono implementati come classi personalizzate compilate in un assembly .NET Framework, che viene quindi caricato e registrato in Dataverse.

I plug-in estendono la logica di business di Dataverse consentendo agli sviluppatori di scrivere codice personalizzato per l'esecuzione quando si verificano determinati eventi, ad esempio la creazione, l'aggiornamento o l'eliminazione di record o tramite chiamate dirette tramite l'API personalizzata. Questa funzionalità supporta l'implementazione di processi aziendali più complessi e personalizzati all'interno di Power Platform, semplificando l'integrazione completa con le app canvas o Power Automate.

Usando sia le funzioni Power Fx che le API personalizzate di Dataverse, i creatori possono richiamare un'azione di funzione direttamente all'interno di una formula, supportando sia le azioni associate che non associate. Possono anche aggiungere un oggetto linguaggio di ambiente Power Fx all'app, consentendo l'accesso alle funzioni. Usando le API personalizzate di Dataverse, i creatori possono gestire campi di oggetto non tipizzato sia per gli input che per gli output.

Recommendations

Sia le funzioni Power Fx che le API personalizzate di Dataverse completano le operazioni di modifica dei dati in una transazione.

Scegliere le funzioni Power Fx se il caso d'uso soddisfa questi criteri:

  • La logica non è eccessivamente complessa e può essere espressa usando Power Fx.
  • Si vuole consentire ai creatori (non sviluppatori) di creare e gestire la logica.
  • Si preferisce un approccio a basso codice che si integra perfettamente con il portale di Power Apps.
  • È necessaria la coerenza transazionale , ma non sono necessarie funzionalità avanzate di .NET.
  • Si vuole centralizzare la logica per il riutilizzo tra app e flussi senza coinvolgere gli sviluppatori .NET.

Per altre informazioni, vedere Funzioni in Microsoft Dataverse (anteprima).

Scegliere API personalizzate di Dataverse se il caso d'uso richiede:

  • Logica di business complessa che Power Fx non può esprimere.
  • Funzionalità avanzate come la gestione degli errori personalizzata, la telemetria e l'integrazione con sistemi esterni.
  • Le competenze di sviluppo .NET sono disponibili e accettabili nel flusso di lavoro.
  • Controllo completo sulla pipeline di esecuzione, inclusa la registrazione e il monitoraggio dei plug-in.
  • Telemetria e diagnostica, ad esempio Application Insights per il monitoraggio dello stato di salute.

Per altre informazioni, vedere Creare e usare API personalizzate.

Se l'obiettivo è semplificare le prestazioni dell'app canvas mantenendo la soluzione accessibile e gestibile dai creatori, le funzioni di Power Fx sono la scelta migliore. Se stai costruendo un backend altamente personalizzato e di importanza critica, considera le API personalizzate di Dataverse.

Alternativi

Un altro approccio a questo modello consiste nello spostare le operazioni e la logica dei dati in un'API REST e quindi implementare un connettore personalizzato per consentire l'uso delle operazioni da Power Apps. La differenza con questo approccio è la posizione in cui vengono eseguite le operazioni di logica e dati. In questo caso, vengono eseguiti nella risorsa di calcolo che implementa l'API REST, ad esempio una funzione di Azure.

Poiché non vengono eseguiti all'interno della sandbox di runtime di Dataverse, le operazioni sui dati sono più veloci rispetto a quelle eseguite dal client, ma più lente rispetto a quelle eseguite all'interno di Dataverse. Analogamente, la logica non viene eseguita nel contesto della transazione Dataverse. A meno che non vengano eseguiti passaggi speciali, ogni operazione dati è indipendente e non viene completata come unità transazionale.

Per altre informazioni, vedere Usare le API REST per estendere le funzionalità delle app canvas.

Considerazioni

Queste considerazioni implementano i pilastri di Power Platform Well-Architected, un insieme di principi guida che migliorano la qualità di un carico di lavoro. Altre informazioni in Microsoft Power Platform Well-Architected.

Reliability

Progettare il carico di lavoro per evitare complessità non necessarie: lo spostamento delle operazioni e della logica dei dati dall'app canvas evita la complessità non necessaria nell'app. Questo approccio centralizza anche la logica in modo che altre applicazioni dell'organizzazione possano usarlo. Inoltre, gli autori di Power Apps traggono vantaggio dai miglioramenti delle prestazioni senza aggiungere complessità all'app.

Testare la resilienza e la disponibilità: lo spostamento della logica dall'app canvas alle API personalizzate di Dataverse o alle funzioni Power Fx consente di testare l'API o la funzione in modo indipendente dall'app.

Misurare e pubblicare indicatori di integrità (API personalizzate di Dataverse): le API personalizzate di Dataverse forniscono funzionalità avanzate di monitoraggio e telemetria tramite il plug-in .NET. Per garantire un monitoraggio adeguato, è consigliabile usare la registrazione di Application Insights .

Eccellenza operativa

Adottare procedure di distribuzione sicure: standardizzare la distribuzione delle modifiche all'applicazione Power Apps usando processi di distribuzione automatizzati, ad esempio le pipeline. Promuovi l'applicazione in produzione solo dopo aver testato le modifiche. Come componenti della soluzione, le API personalizzate di Dataverse e le funzioni Power Fx vengono distribuite insieme all'app quando si trovano nella stessa soluzione Dataverse. Questo approccio riduce al minimo il rischio di componenti non sincronizzati negli ambienti.

Implementare una strategia di mitigazione degli errori di distribuzione: quando si distribuisce l'app e la funzione personalizzata Dataverse o power Fx insieme, la strategia di mitigazione è semplificata perché segue la stessa strategia di rollback o correzione dell'app.

Efficienza delle prestazioni

Progettare per soddisfare i requisiti di prestazioni: valutare i requisiti di prestazioni e volume di dati della soluzione. Esaminare il modo in cui l'app accede ai dati e se Power Apps usando origini dati diverse rallenta le prestazioni a causa della latenza della singola richiesta inviata a ogni archivio dati. Ad esempio, se la logica dell'app funziona in molte righe nell'origine dati, potrebbe essere possibile spostare tutto il traffico di rete all'API o alla funzione personalizzata. Riducendo a una singola interazione con l'API o la funzione personalizzata, che quindi gestisce la comunicazione con Dataverse, rende le operazioni più efficienti.

Ottimizzare la logica (API personalizzate di Dataverse): Man mano che la logica diventa più complessa in un'app canvas, le API personalizzate di Dataverse consentono di eseguire l'offload di tale logica in un servizio centralizzato riutilizzabile.

Prestazioni dei test: insieme ai test per le funzionalità e gli errori, testare e sviluppare una linea di base per le prestazioni. Valutare questa baseline durante il ciclo di rilascio se l'API personalizzata di Dataverse o la funzione Power Fx sono sensibili alle variazioni nei tempi di completamento delle attività.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

  • Last updated on