Entender as fases de execução de aplicativos de tela e o fluxo de chamada de dados

Quando um usuário abre um aplicativo de tela, o aplicativo segue diversas fases de execução antes de mostrar uma interface do usuário. Enquanto o aplicativo carrega, ele se conecta a diferentes fontes de dados— tais como SharePoint,Microsoft Dataverse, SQL Server (local), Banco de dados SQL do Azure (online), Excel e Oracle.

Neste artigo, você aprenderá sobre essas diferentes fases de execução e como um aplicativo se conecta a fontes de dados.

Fases de execução em aplicativos de tela

Um aplicativo de tela passa pelas seguintes fases de execução antes de mostrar a interface a um usuário:

  1. Autenticar o usuário: solicita que o usuário iniciante entre com credenciais para conexões exigidas pelo aplicativo. Se esse usuário reabrir o aplicativo, ele poderá ser solicitado novamente, dependendo das políticas de segurança da organização.

  2. Obter metadados: recupera metadados, como a versão da plataforma Power Apps na qual o aplicativo é executado e as fontes das quais ele precisa recuperar dados.

  3. Inicializar o aplicativo: executa as tarefas especificadas na propriedade OnStart.

  4. Renderizar as telas: renderiza a primeira tela com os controles que o aplicativo preencheu usando dados. Se o usuário abrir outras telas, o aplicativo as renderizará usando o mesmo processo.

Fluxo de chamada de dados em aplicativos de tela

As chamadas de dados de aplicativos de tela enviam fontes de dados usando conectores sobre o protocolo OData. O OData solicita o fluxo para as camadas de back-end para entrar em contato com a fonte de dados de destino e recuperar dados para o cliente ou enviar dados para a fonte de dados.

Compreender como solicitações do OData que percorrem aplicativos de tela podem ajudá-l a otimizar o desempenho do aplicativo de tela e suas fontes de dados de back-end.

Nesta seção, você aprenderá sobre como a chamada de dados flui em aplicativos de tela com diferentes tipos de fonte de dados.

Fluxo de chamadas de dados com fontes de dados online

O diagrama a seguir mostra como uma solicitação de dados típica em um aplicativo de tela (no lado esquerdo) percorre camadas do servidor, alcança a fonte de dados de destino (no lado direito) e retorna os dados ao cliente.

Fluxo de chamada de dados típico para todos os conectores, exceto o conector para Dataverse

Cada camada no diagrama anterior pode ser executada rapidamente ou encontrar certa sobrecarga ao processar a solicitação. Em muitos aplicativos, dois pontos específicos costumam apresentar sobrecarga perceptível:

  • Fonte de dados de back-end ao processar a solicitação.

  • Cliente ao enviar a solicitação ou ao manipular os dados recebidos na memória heap e executar as funções JavaScript associadas para processar dados a serem exibidos em telas.

Fluxo de chamada de dados com gateway de dados local

Se um aplicativo de tela se conectar a uma fonte de dados local como o SQL Server, você precisará ter outra camada chamada de gateway de dados local. Este gateway é obrigatório para acessar fontes de dados locais. Ele se encarrega de converter o protocolo de solicitações OData em instruções SQL DML (Data Manipulation Language).

O diagrama a seguir mostra onde e como o gateway de dados local é utilizado para processar solicitações de dados.

Fluxo de chamada de dados para um gateway de dados local

Se o aplicativo usar uma fonte de dados local, a localização e a especificação do gateway de dados também afetarão o desempenho das chamadas de dados.

Fluxo de chamada de dados com o conector do Common Data Service (para ambientes do Dataverse)

Quando você usa o conector do Common Data Service para acessar um ambiente do Dataverse, as solicitações de dados vão diretamente para a instância do ambiente, sem passar pelo Gerenciamento de API do Azure. Por isso, o desempenho das chamadas de dados é muito mais rápido em comparação com as demais fontes de dados. O conector do Common Data Service é criado por padrão quando você cria um novo aplicativo de tela.

Fluxo de chamada de dados para o conector do Common Data Service

Ao compreender esse conceito de alto nível do percursos das chamadas de dados, você pode obter detalhes da avaliação de desempenho do seu aplicativo. Em resumo, a sobrecarga de desempenho pode ocorrer em qualquer camada — cliente, Gerenciamento de API, conector, gateway de dados local ou fontes de dados de back-end.

Próximas etapas

Fontes comuns de desempenho lento para um aplicativo de tela

Consulte também

Problemas comuns de desempenho e resoluções para aplicativos de tela
Dicas e práticas recomendadas para melhorar o desempenho de aplicativos de tela
Problemas comuns e soluções do Power Apps
Solucionando problemas de inicialização do Power Apps