Comprender fases de execución de aplicacións de lona, fluxo de chamadas de datos e monitorización de rendemento

Cando un usuario abre unha aplicación de lenzo, a aplicación atravesa varias fases de execución antes de mostrar calquera interface de usuario. Mentres a aplicación se carga, conéctase a diferentes fontes de datos como SharePoint, Microsoft Dataverse, SQL Server (local), Base de datos SQL de Azure (en liña), Excel e Oracle.

Neste artigo, aprenderás sobre estas diferentes fases de execución e como unha aplicación se conecta a fontes de datos e sobre ferramentas que pode usar para monitorizar o rendemento.

Fases de execución en aplicacións de lenzo

Unha aplicación de lenzo pasa polas seguintes fases de execución antes de mostrar a interface a un usuario:

1. Autenticar o usuario: solicita ao usuario que accede por primeira vez que inicie sesión con credenciais para as conexións que precise a aplicación. Se ese usuario abre de novo a aplicación, é posible que se lle solicite a esa persoa de novo, dependendo das políticas de seguridade da organización.

2. Obter metadatos: recupera metadatos como a versión da plataforma de Power Apps na que se executa a aplicación e as fontes das que debe recuperar datos.

3. Iniciar a aplicación: realiza as tarefas especificadas na propiedade OnStart.

4. Render as pantallas: Fai a primeira pantalla con controis que a aplicación poboa con datos. Se o usuario abre outras pantallas, a aplicación procésaas utilizando o mesmo proceso.

Fluxo de chamadas de datos en aplicacións de lenzo

As chamadas de datos das aplicacións de lona envían datos a fontes de datos tabulares usando conectores sobre o protocolo OData. OData solicita fluxo a capas de back-end para contactar co obxectivo orixe de datos e recuperar datos para o cliente, ou comprometer datos ao orixe de datos. Conectores baseados en accións que permiten que as API funcionen do mesmo xeito.

Comprender como OData e API solicita viaxar en aplicacións de lona pode axudarche a optimizar o rendemento da aplicación de lona e as fontes de datos de back-end.

Nesta sección, aprenderá sobre como flúen as chamadas de datos en aplicacións de lenzo con diferentes tipos de orixe de datos.

Fluxo de chamadas de datos con fontes de datos en liña

O seguinte diagrama mostra como unha solicitude de datos típica nunha aplicación de lenzo (no lado esquerdo) percorre capas do servidor e chega ata a orixe de datos de destino (lado dereito) e, a continuación, devolve os datos ao cliente.

Cada capa do diagrama anterior podería funcionar rápido ou ter algunhas sobrecargas ao procesar a solicitude. En moitas aplicacións, dous puntos particulares poden presentar sobrecargas notables:

• Orixe de datos do back-end: mentres se tramita a solicitude.

• Cliente: mentres envía a solicitude—ou mentres se manipulan os datos recibidos na memoria da área de datos dinámicos e se executan as funcións de JavaScript asociadas para procesar os datos que se mostran dentro das pantallas.

Fluxo de chamadas de datos coa pasarela de datos local

Se unha aplicación de capa se conecta a unha orixe de datos local como SQL Server, necesitará ter outra capa, chamada pasarela de datos local. Esta pasarela é obrigatoria para acceder ás orixes de datos locais. Encárgase de converter o protocolo das solicitudes de OData en instrucións de DML (linguaxe de manipulación de datos) de SQL.

O seguinte diagrama mostra onde e como se instalaría a pasarela de datos local e se procesarían as solicitudes de datos.

Se a aplicación usa unha orixe de datos local, a situación e a especificación da pasarela de datos tamén afectaría o rendemento das chamadas de datos.

Fluxo de chamadas de datos con Microsoft Dataverse

Cando usa Microsoft Dataverse como orixe de datos, as solicitudes de datos van á instancia do ambiente directamente, sen pasar pola xestión da API de Azure. Debido a isto, o rendemento das chamadas de datos é máis rápido en comparación co resto de fontes de datos. A aplicación está conectada por defecto a Microsoft Dataverse cando crea unha nova aplicación de lenzo.

Coa comprensión deste concepto de alto nivel de como viaxan as chamadas de datos, pode entrar nos detalles da revisión do rendemento da súa aplicación. En resumo, a sobrecarga do rendemento pode ocorrer en calquera das capas—do cliente, Xestión da API, conector, pasarela de datos local ou orixes de datos do back-end.

Medición do rendemento

Power Apps Ferramenta de monitorización

Aínda que pode usar as ferramentas de desenvolvemento do navegador para ver o rendemento, Power Apps subconxuntos o conxunto de chamadas na ferramenta Monitoring para só as que son Power Apps.

A Power Apps ferramenta de monitorización pode axudarche a rastrexar o que realmente se envía ao orixe de datos e horarios para cando se envían as solicitudes e as respostas proveñen do servidor.

Podes obter máis información sobre a ferramenta de seguimento neste artigo: Depurar aplicacións de lonas con Monitor .

Medición da presión de memoria sobre o cliente

Para ver graficamente o consumo de memoria, pode usar as ferramentas de desenvolvemento para que o seu navegador poida perfilar a memoria. Axuda a visualizar o tamaño da área de datos dinámicos, documentos, os nós e os oíntes. Perfila o rendemento da aplicación usando un navegador, tal e como se describe na Microsoft Edge visión xeral de Ferramentas de desenvolvemento de Chromium. Comprobe os escenarios que superan o limiar de memoria da área de datos dinámicos de JS. Máis información: Solucione problemas de memoria

Pasos seguintes

Pequenas cargas de datos

Consulte tamén

Resolución de problemas para Power Apps