Usar APIs REST para expandir a funcionalidade de aplicações de tela

O Microsoft Power Platform permite-lhe expandir a funcionalidade da sua aplicação de tela do Power Apps utilizando APIs REST. Ao lidar com algoritmos complexos ou com muitas origens de dados, mudar a lógica da aplicação de tela para uma API REST pode ser uma boa escolha para ajudar a manter simples as suas fórmulas dentro da sua aplicação de tela do Power Apps, ao mesmo tempo que move funcionalidades mais complexas do lado do servidor. Os conectores personalizados do Power Platform permitem que aplicações de tela usem a API REST tal como qualquer outra origem de dados.

Diagrama da arquitetura

Workflow

1. Aplicação de tela: a aplicação de tela do Power Apps usa o conector personalizado para aceder a operações expostas pela Função do Azure. O utilizador autentica-se na aplicação usando o Entra ID e o acesso aos dados está limitado aos dados a que o utilizador tem acesso.
2. Conector personalizado: o conector personalizado descreve que operações a aplicação pode usar a partir da API REST que, no exemplo, é implementada por uma Função do Azure. Ao usar um conector personalizado, a aplicação de tela do Power Apps é capaz de usar a lógica como qualquer outra origem de dados.
3. Aplicações do Microsoft Entra ID: a Função do Azure é protegida usando uma aplicação do Microsoft Entra ID. Uma segunda aplicação do Microsoft Entra ID é registada e configurada no conector personalizado para permitir que a aplicação de tela do Power Apps aceda às operações de Função do Azure.
4. Função do Azure: a Função do Azure implementa a API RESTful, oferecendo uma ou mais operações que são expostas à aplicação de tela do Power Apps ao exportar um conector personalizado do Portal do Azure ou por configuração manual. A Função do Azure é protegida por um registo da aplicação Entra ID para garantir apenas chamadores autorizados.
5. Azure Cosmos DB: a Função do Azure pode usar o Azure Cosmos DB, o SQL do Azure ou qualquer outro arquivo de dados da nuvem necessário para gerir os dados. Na verdade, a função poderia estar a trabalhar 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 implementa a experiência de utilizador na aplicação In Store. Estes recursos são movidos de um ambiente para outro (por exemplo, Dev to Teste) usando soluções do Dataverse.
• Power Apps: o Power Apps é usado para implementar a experiência de utilizador da solução. Os criadores podem criar a aplicação usando o conector personalizado criado pelo programador da Função do Azure como uma origem de dados da aplicação.
• Conector personalizado: os conectores personalizados do Power Platform descrevem as operações e estruturas de dados de uma API RESTful. Permitem que a API seja facilmente usada a partir de recursos como a aplicação de tela do Power Apps. Quando usada a partir do Power Apps, permitem que a API seja referenciada como qualquer outra origem de dados.

Detalhes do cenário

O Power Apps permite que as organizações criem uma experiência de utilizador personalizada e, ao usar APIs REST, a lógica de negócio é centralizada e acedida pela aplicação usando um conector personalizado. Esta abordagem também pode permitir que a aplicação do Power Apps atue como um integrador de vários serviços de back-end, fornecendo uma única vista para o utilizador de dados e lógica de todas as origens. Usando a abordagem da API REST, também pode mudar a complexidade de interagir com vários outros sistemas para implementar componentes da API REST e simplificar a implementação da aplicação de tela e, ao mesmo tempo, fornecer a mesma experiência de utilizador.

No exemplo acima, a aplicação In Store é criada usando a aplicação de tela do Power Apps. A aplicação permite que um associado da loja guarde rapidamente um pedido de notificação de encomenda pendente para um cliente quando um item não está em stock. A aplicação usa uma única operação RecordBackorder que é configurada num conector personalizado que descreve uma operação de Função do Azure de back-end. Neste exemplo, a Função do Azure é a implementação da API REST. Pode usar qualquer tecnologia que permita a criação de um serviço RESTful para implementar este padrão.

Esta arquitetura oferece flexibilidade, mas também significa que é necessário um trabalho mais de programador de código profissional para desenvolver e manter o serviço RESTful e a camada de dados. Em geral, à medida que a complexidade da fórmula da aplicação de tela aumenta, deve considerar este tipo de arquitetura. Por exemplo, quando são necessárias várias origens de dados para criar uma única vista, utilizar uma camada de API pode ajudar a oferecer uma experiência com melhor desempenho, porque a resposta de dados pode ser moldada do lado do servidor e entregue ao cliente de forma mais eficiente. A utilização desta camada de escalão médio significa que pode adicionar uma camada de colocação em cache do lado do servidor e implementar telemetria mais rica para a aplicação.

Considerações

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

Fiabilidade

Conceba a sua carga de trabalho para evitar complexidade desnecessária — Usar a abordagem de API REST de uma aplicação do Power Apps através de um conector personalizado evita complexidade desnecessária e também centraliza a lógica onde poderia ser usada por outras aplicações na organização. O conector personalizado permite que o Power Apps maker possa usar as operações da API RESTFul como qualquer outra operação de origem de dados.

Teste de resiliência e disponibilidade – Ao mudar a lógica da aplicação de tela para a API REST, deve ser capaz de testar a API de forma independente, separada da aplicação que a usa.

Meça e publique os indicadores de integridade — a telemetria deve ser capturada do componente da API REST para rastrear a respetiva integridade. Por exemplo, usar o Azure Monitor — o registo do Application Insights garantiria o rastreamento adequado do componente.

Segurança

Crie segmentação e perímetros intencionais — garantir que a aplicação usa ambientes do Power Platform separados para suportar as fases do ciclo de vida da aplicação e garantir que apenas os utilizadores certos que têm acesso a cada fase podem suportar as suas políticas de segmentação. Também é importante que aplicações do Entra ID registadas sejam separadas entre os ambientes para manter a proteção de cada fase de dados e não misturar entre ambientes.

Excelência Operacional

Adote práticas de implementação seguras — Padronize a implementação de quaisquer alterações para a aplicação Power Apps ao usar processos de implementação automatizados, como pipelines. Promova a aplicação para produção só depois de testar as alterações.

Implemente uma estratégia de mitigação de falhas de implementação — Com a dependência entre a aplicação e a API REST, deve garantir que tem uma estratégia testada para mitigar uma implementação de qualquer uma que desenvolva erros após a atualização de um dos componentes.

Eficiência de Desempenho

Conceber para satisfazer os requisitos de desempenho — Avalie o desempenho da sua solução e o volume de requisitos de dados. A avaliação deve incluir a forma como os dados são acedidos e a avaliação de como o Power Apps utiliza diferentes origens de dados diretamente poderá ter demasiada comunicação com as origens de dados. Isto pode criar um abrandamento do desempenho devido à latência do pedido individual que está a ser enviado para cada arquivo de dados. Por exemplo, se a sua aplicação tinha uma lógica que funcionava num grande número de linhas na origem de dados, talvez possa mudar todo esse tráfego de rede para a Função do Azure de back-end. Reduzir a uma única interação com a API REST que, por sua vez, iria gerir a interação com as várias outras origens de dados onde poderia ser feito mais eficazmente.

Otimizar a lógica — À medida que a lógica se torna mais complexa numa aplicação de tela, o Funções do Azure ou implementações de API RESTful de back-end semelhantes podem descarregar essa lógica para um serviço centralizado e reutilizável. A utilização da capacidade de conector personalizado para descrever essas APIs RESTful permite que as aplicações de tela usem as respetivas operações configuradas como qualquer outra origem de dados.

Testar o desempenho — Juntamente com o teste de funcionalidade e falhas, é importante testar e desenvolver uma linha de base para o desempenho e avaliá-la como parte do 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 — As aplicações que permitem que utilizadores acedam a várias origens de dados a partir de uma única aplicação Power Apps sem exigir que interajam com várias aplicações individuais está a tornar o utilizador mais eficiente e é um bom uso de uma experiência visual mais personalizada.

Contribuidores

A Microsoft mantém este artigo. Este artigo foi escrito pelos contribuidores a seguir.

Principais autores:

• Mehdi Slaoui Andaloussi, Gestor de Engenharia Principal

Recursos relacionados

• Referência da API REST do Azure
• Descrição geral da Função do Azure