Compartilhar via

Usar as APIs REST para estender a funcionalidade de aplicativos de tela

O Microsoft Power Platform permite que você estenda a funcionalidade do seu aplicativo de tela do Power Apps usando APIs REST. Ao lidar com algoritmos complexos ou com muitas fontes de dados, mudar a lógica de aplicativo de tela para uma API RESTful pode ser uma escolha ideal para ajudar a manter suas fórmulas no aplicativo de tela do Power Apps simples enquanto move funcionalidades mais complexas no servidor. Os conectores personalizados do Power Platform permitem que os aplicativos tela usem a API REST, assim como qualquer outra fonte de dados.

Dica

O artigo fornece um cenário de exemplo e uma representação visual de como usar APIs REST para estender a funcionalidade de aplicativos tela. Essa solução é uma arquitetura de cenário de exemplo generalizada, que pode ser usada para muitos cenários e setores diferentes.

Diagrama da arquitetura

Diagrama de arquitetura ilustrando o fluxo de trabalho para usar APIs REST para estender a funcionalidade de aplicativos tela.

Workflow

  1. Aplicativo de tela: o aplicativo de tela do Power Apps usa o conector personalizado para acessar operações expostas pelo Azure Function. O usuário se autentica no aplicativo usando o Entra ID e o acesso aos dados é limitado aos dados aos quais o usuário tem acesso.
  2. Conector personalizado: o conector personalizado descreve quais operações o aplicativo pode usar a partir da API REST, que no exemplo é implementada por um Azure Function. Usando um conector personalizado, o aplicativo tela do Power Apps é capaz de usar a lógica, como qualquer outra fonte de dados.
  3. Aplicativos Microsoft Entra ID: o Azure Function é protegido usando um aplicativo Microsoft Entra ID. Um segundo aplicativo Microsoft Entra ID é registrado e configurado no conector personalizado para permitir que o aplicativo de tela do Power Apps acesse as operações do Azure Function.
  4. Azure Function: o Azure Function implementa a API RESTful oferecendo uma ou mais operações expostas ao aplicativo tela do Power Apps exportando um conector personalizado do Portal do Azure ou por configuração manual. A Função Azure é protegida por um registro no aplicativo Entra ID para garantir apenas chamadores autorizados.
  5. Azure Cosmos DB: o Azure Function pode usar o Azure Cosmos DB, o SQL do Azure ou qualquer outro armazenamento de dados em nuvem necessário para gerenciar os dados. Na verdade, a função poderia estar trabalhando com dados no Microsoft Dataverse usando a abordagem de função devido à complexidade da lógica.

Componentes

  • Ambiente do Power Platform: contém os recursos do Power Platform, como o Power Apps, que implementam a experiência do usuário. Esses recursos são movidos de um ambiente para outro (por exemplo, Desenvolvimento para Teste) usando soluções do Dataverse.
  • Power Apps: o Power Apps é usado para implementar a experiência do usuário da solução. Os criadores podem criar o aplicativo usando o conector personalizado criado pelo desenvolvedor da função Azure como uma fonte de dados do aplicativo.
  • Conector personalizado: os conectores personalizados do Power Platform descrevem as operações e estruturas de dados de uma API RESTful. Eles permitem que a API seja facilmente usada a partir de recursos como um aplicativo de tela do Power Apps. Quando usados a partir do Power Apps, eles permitem que a API seja referenciada, assim como qualquer outra fonte de dados.

Detalhes do cenário

O Power Apps permite que as organizações criem uma experiência de usuário personalizada e, usando APIs REST, a lógica de negócios é centralizada e acessada pelo aplicativo usando um conector personalizado. Essa abordagem também pode permitir que o aplicativo do Power Apps atue como um integrador de vários serviços de back-end, fornecendo uma visão única ao usuário dos dados e da lógica de todas as fontes. Usando a abordagem de API REST, você também pode transferir a complexidade de interagir com vários outros sistemas para o componente que implementa a API REST e simplificar a implementação do aplicativo de tela, ao mesmo tempo em que ainda fornece a mesma experiência de usuário.

No exemplo acima, o aplicativo Na Loja é criado usando um aplicativo de tela do Power Apps. O aplicativo permite que um associado da loja salve rapidamente uma solicitação de notificação de backorder para um cliente quando um item estiver fora de estoque. O aplicativo usa uma única operação RecordBackorder que é configurada em um conector personalizado que descreve uma operação de back-end Azure Function. Neste exemplo, a função Azure é a implementação da API REST. Você pode usar qualquer tecnologia que permita a criação de um serviço RESTful para implementar esse padrão.

Essa arquitetura oferece flexibilidade, mas também significa que mais trabalho do desenvolvedores code-first é necessário para desenvolver e manter o serviço RESTful e a camada de dados. Em geral, conforme a complexidade das fórmulas do aplicativo de tela aumenta, você deve considerar esse tipo de arquitetura. Por exemplo, quando várias fontes de dados são necessárias para criar uma única visualização, usar uma camada de API pode ajudar a fornecer uma experiência de desempenho, porque a resposta dos dados pode ser moldada no lado do servidor e entregue ao cliente com mais eficiência. O uso dessa camada intermediária significa que você pode adicionar uma camada de cache no lado do servidor e implementar telemetria mais rica para o aplicativo.

Considerações

Essas considerações implementam os pilares do Well-Architected para Power Platform, um conjunto de princípios orientadores que melhoram a qualidade de uma carga de trabalho. Saiba mais em Well-Architected para Microsoft Power Platform.

Confiabilidade

Projete sua carga de trabalho para evitar complexidade desnecessária – usar a abordagem de API REST de um aplicativo do Power Apps por meio de um conector personalizado evita complexidade desnecessária e também centraliza a lógica onde ela poderia ser usada por outros aplicativos na organização. O conector personalizado permite que o criador do Power Apps possa usar as operações da API RESTFul, como qualquer outra operação de fonte de dados.

Teste de resiliência e disponibilidade – ao mudar a lógica do aplicativo de tela para a API REST, você deve poder testar de forma independente a API separada do aplicativo que a usa.

Medir e publicar os indicadores de integridade – a telemetria deve ser capturada do componente da API REST para rastrear sua integridade. Por exemplo, usar o Azure Monitor – o registro em log do Application Insights garante o rastreamento adequado do componente.

Segurança

Criar segmentação e perímetros intencionais – garantir que o aplicativo use ambientes separados do Power Platform para oferecer suporte aos estágios do ciclo de vida do aplicativo e garantir que somente os usuários certos tenham acesso a cada estágio pode oferecer suporte às suas políticas de segmentação. Também é importante que os aplicativos do Entra ID cadastrados sejam separados entre os ambientes para manter a proteção de cada estágio dos dados e não se misturar entre os ambientes.

Excelência Operacional

Adotar práticas de implantação seguras – padronize a implantação de quaisquer alterações no aplicativo do Power Apps usando processos de implantação automatizados, como pipelines. Promova o aplicativo para produção somente após testar as alterações.

Implementar uma estratégia de mitigação de falhas de implantação –com a dependência entre o aplicativo e a API REST, você deve garantir que tenha uma estratégia testada para mitigar uma implantação de qualquer um que desenvolva erros após a atualização de um dos componentes.

Eficiência de Desempenho

Projetar para atender aos requisitos de desempenho – avalie o desempenho da solução e o volume de requisitos de dados. A avaliação deve incluir como os dados são acessados e a avaliação de como o Power Apps usa diferentes fontes de dados diretamente pode ser muito comunicativa com as fontes de dados. Isso pode criar uma desaceleração de desempenho devido à latência da solicitação individual que está sendo enviada para cada armazenamento de dados. Por exemplo, se o seu aplicativo tiver lógica que funcione em um grande número de linhas na fonte de dados, você poderá transferir todo o tráfego de rede para o Azure Function de back-end. Reduzindo a uma única interação com a API REST que, por sua vez, gerenciaria a interação com várias outras fontes de dados onde isso poderia ser feito de forma mais eficaz.

Otimizar a lógica – à medida que a lógica se torna mais complexa em um aplicativo de tela, implementações de API RESTful do Azure Functions ou de back-end similar podem descarregar essa lógica em um serviço reutilizável centralizado. Usar o recurso de conector personalizado para descrever essas APIs RESTful permite que os aplicativos tela usem suas operações configuradas como qualquer outra fonte de dados.

Teste de desempenho – junto com o teste de funcionalidade e falhas, é importante testar e desenvolver uma linha de base para o desempenho e avaliá-la como parte de seu ciclo de lançamento se a API for sensível a alterações nos tempos de conclusão do trabalho.

Otimização da Experiência

Design para eficiência – aplicativos que permitem que os usuários acessem várias fontes de dados de um único aplicativo do Power Apps sem exigir que eles interajam com vários aplicativos individuais está tornando o usuário mais eficiente e é um bom uso de uma experiência visual mais personalizada.

Colaboradores

Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Principais autores: