Compreender as fases de execução e o fluxo de chamada de dados das aplicações de tela

Quando um utilizador abre uma aplicação de tela, a aplicação passa por diversas fases de execução antes de mostrar a interface de utilizador. Enquanto a aplicação carrega, liga-se a diferentes origens de dados—, tais como o SharePoint, Microsoft Dataverse, SQL Server (no local), Azure SQL Database (online), Excel e Oracle.

Neste artigo, vai aprender sobre estas diferentes fases de execução e como uma aplicação se liga a origens de dados.

Fases de execução em aplicações de tela

Uma aplicação de tela passa pelas seguintes fases de execução antes de mostrar a interface a um utilizador:

  1. Autenticar o utilizador: solicita ao utilizador pela primeira vez que inicia sessão com credenciais para quaisquer ligações que a aplicação precise. Se esse utilizador voltar a abrir a aplicação, poderá ter de iniciar sessão novamente com essas credenciais, dependendo das políticas de segurança da organização.

  2. Obter metadados: obtém metadados, tais como a versão da plataforma Power Apps em que a aplicação é executada e as origens a partir das quais tem de obter os dados.

  3. Inicializar a aplicação: realiza todas as tarefas especificadas na propriedade OnStart.

  4. Compor os ecrãs: compõe o primeiro ecrã com controlos que a aplicação preencheu com dados. Se o utilizador abrir outros ecrãs, a aplicação irá compô-los recorrendo ao mesmo processo.

Fluxo de chamada de dados em aplicações de tela

As chamadas de dados de aplicações de tela enviam origens de dados utilizando os conectores através do protocolo OData. OData solicita fluxo para que as camadas de back-end contactem a origem de dados de destino, e recuperem dados para o cliente, ou submetam dados para a origem de dados.

A compreensão de como os pedidos OData viajam em aplicações de tela pode ajudá-lo a otimizar o desempenho da sua aplicação de tela e as suas origens de dados de back-end.

Nesta secção, vai aprender sobre como a chamada de dados flui em aplicações de tela com diferentes tipos de origem de dados.

Fluxo de chamada de dados com origens de dados online

O diagrama seguinte mostra como um pedido típico de dados numa aplicação de tela (no lado esquerdo) percorre camadas do lado do servidor e contacta a origem de dados de destino (no lado direito) e, em seguida, obtém os dados do cliente.

O fluxo de chamada de dados típico para todos os conectores, exceto o conector do Dataverse

Cada camada no diagrama anterior pode realizar-se rapidamente, ou deparar-se com alguma sobrecarga durante o processamento do pedido. Em muitas aplicações, dois pontos particulares podem geralmente apresentar sobrecarga visível:

  • Origem de dados de back-end: enquanto processa o pedido.

  • Cliente: ao enviar o pedido—ou manipulando os dados recebidos na memória de área de dados dinâmica, e executando as funções JavaScript associadas para processar dados para mostrar em ecrãs.

Fluxo de chamada de dados com gateway de dados no local

Se uma aplicação de tela se ligar a uma origem de dados no local, como o SQL Server, precisa de ter outra camada, chamada de um gateway de dados no local. Este gateway é obrigatório para aceder a origens de dados no local. Encarrega-se de converter pedidos do protocolo OData para instruções Idioma de Manipulação de Dados (DML) do SQL.

O diagrama seguinte mostra onde e como o gateway de dados no local é colocado para processar os pedidos de dados.

Fluxo de chamada de dados para um gateway de dados no local

Se a aplicação utilizar uma origem de dados no local, a localização e a especificação do gateway de dados também afeta o desempenho das chamadas de dados.

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

Quando utiliza o conector do Common Data Service para aceder a um ambiente Dataverse, os pedidos de dados vão diretamente para a instância do ambiente,—sem passar pela Gestão de API do Azure. Como tal, o desempenho das chamadas de dados é muito mais rápido em comparação com as restantes origens de dados. O conector do Common Data Service é criado por predefinição quando cria uma nova aplicação de tela.

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

Com a compreensão deste conceito de alto nível de como os dados chamam viajam, pode entrar nos detalhes da revisão de desempenho da sua aplicação. Em resumo, a sobrecarga de desempenho pode acontecer em qualquer uma das camadas—do cliente, Gestão de API, conector, gateway de dados no local ou origens de dados de back-end.

Passos seguintes

Origens comuns de desempenho fraco para uma aplicação de tela

Consulte também

Problemas comuns e resoluções de desempenho de aplicações de tela
Dicas e melhores práticas para melhorar o desempenho das aplicações de tela
Problemas comuns e resoluções para o Power Apps
Resolução de problemas de arranque para Power Apps