Descrição geral dos conectores para aplicações de tela

Os dados são o núcleo da maioria das aplicações, incluindo os dados criados no Power Apps. Os dados são armazenados numa origem de dados e coloca esses dados na sua aplicação através da criação de uma ligação. A ligação utiliza um conector específico para comunicar com a origem de dados. O Power Apps tem conectores para inúmeros serviços populares e origens de dados no local, incluindo o SharePoint, SQL Server, Office 365, Salesforce e Twitter. Para começar a adicionar dados a uma aplicação baseada em telas, veja Adicionar uma ligação de dados no Power Apps.

Um conector pode disponibilizar tabelas de dados ou ações. Alguns conectores só disponibilizam tabelas, outros só disponibilizam ações e outros disponibilizam ambos. Além disso, o seu conector pode ser um conector padrão ou personalizado.

Tabelas

Se o seu conector disponibilizar tabelas, adicione a sua origem de dados e, em seguida, selecione a tabela na origem de dados que quer gerir. Power Apps obtém dados das tabelas na sua aplicação e também atualiza automaticamente os dados na sua origem de dados. Por exemplo, pode adicionar uma origem de dados que contém uma tabela chamada Lições e, em seguida, defina a propriedade Itens de um controlo, como uma galeria ou um formulário, para este valor na barra de fórmulas:

Pode especificar os dados que a aplicação obtém ao personalizar a propriedade Itens do controlo que mostra os seus dados. Continuando o exemplo anterior, pode classificar ou filtrar os dados na tabela Lições através desse nome como um argumento para as funções Pesquisar e SortByColumn. Neste gráfico, a fórmula para a qual a propriedade Itens está definida especifica que os dados são ordenados e filtrados com base no texto TextSearchBox1.

Para obter mais informações sobre como personalizar a sua fórmula com tabelas, veja estes artigos:

Compreender origens de dados no Power Apps
Gerar uma aplicação a partir de dados do Excel
Criar uma aplicação de raiz
Compreender tabelas e registos no Power Apps

Ações

Se o seu conector disponibilizar ações, ainda tem de selecionar a origem de dados como anteriormente. No entanto, em vez de selecionar uma tabela como o passo seguinte, ligue manualmente um controlo a uma ação ao editar a propriedade Itens do controlo que irá mostrar os seus dados. A fórmula para a qual definir a propriedade Itens especifica a ação que obtém dados. Por exemplo, a aplicação não irá recuperar quaisquer dados se se ligar ao Yammer e, em seguida, definir a propriedade Itens para o nome da origem de dados. Para preencher um controlo com dados, especifique uma ação como GetMessagesInGroup(5033622).messages.

Se tiver de processar atualizações de dados personalizados para os conectores de ação, crie uma fórmula que inclua a função Patch. Na fórmula, identifique a ação e os campos que irá vincular à ação.

Para obter mais informações sobre como personalizar a sua fórmula com tabelas personalizadas, veja estes artigos:

Patch
Collect
Update

O esquema dinâmico é um tipo comum de resultado para conectores baseados em ações. O esquema dinâmico refere-se à possibilidade de a mesma ação poder devolver uma tabela diferente com colunas diferentes, dependendo de como se chama. As condições que podem fazer com que as colunas na tabela sejam diferentes incluem os parâmetros de entrada, o utilizador ou a função que está a executar a ação e o grupo no qual o utilizador está a trabalhar, entre outras. Por exemplo, os procedimentos armazenados do SQL Server podem devolver diferentes colunas se forem executados com diferentes entradas, ou uma instância do Azure DevOps pode utilizar campos personalizados que não estão disponíveis por predefinição. Note que a documentação do conector mostra resultados do esquema dinâmico com esta mensagem "As saídas desta operação são dinâmicas." como o valor devolvido.

Para mais informações sobre como trabalhar com o esquema dinâmico no Power Apps, consulte Trabalhar com objetos Sem tipo e Dinâmicos para uma descrição geral e Ligar ao Azure DevOps a partir do Power Apps para um exemplo detalhado.

Conectores populares

Esta tabela tem ligações para obter mais informações sobre os nossos conectores mais populares. Para obter uma lista completa de conectores, veja Todos os conectores.

** Aplica-se ao blob do Azure, Box, Dropbox, Google Drive, OneDrive e OneDrive para Empresas

Conectores padrão e personalizados

Power Apps fornece conectores padrão para muitas origens de dados utilizadas com frequência. Se o Power Apps tem um conector padrão para este tipo de origem de dados que quer utilizar, deve utilizar esse conector. Se quiser ligar a outros tipos de origens de dados, como um serviço que criou, veja Registar e utilizar conectores personalizados.

Todos os conectores padrão

Os conectores padrão não requerem licenciamento especial. Para mais informações, consulte Power Apps Planos.

Pode fazer perguntas sobre um conector específico nos Fóruns do Power Apps e pode sugerir conectores para adicionar ou outras melhorias no Power Apps Ideias.

Segurança e tipos de autenticação

À medida que cria a sua aplicação e cria uma ligação a um origem de dados, poderá ver que a sua escolha de conector lhe permite utilizar diferentes maneiras de efetuar a autenticação. Por exemplo, o conector do SQL Server permite utilizar o Microsoft Entra Integrado, a autenticação SQL Server e a autenticação do Windows. Cada tipo de autenticação tem diferentes níveis de segurança associados. É importante compreender as informações e os direitos partilhados com os utilizadores que utilizam a aplicação. O exemplo primário neste artigo é o SQL Server, no entanto, os princípios aplicam-se a todos os tipos de ligações.

Microsoft Entra ID

Trata-se de um tipo de ligação seguro. Por exemplo, o SharePoint utiliza este tipo de autenticação. O SQL Server também permite este tipo de autenticação. Quando se liga, o serviço Microsoft Entra identifica-o separadamente do SharePoint em seu nome. Não tem de fornecer um nome de utilizador ou palavra-passe. Como autor, pode criar e trabalhar com o origem de dados com as suas credenciais. Quando publica a sua aplicação e o utilizador da aplicação inicia sessão, a mesma é efetuada com as respetivas credenciais. Se os dados forem devidamente protegidos numa linha de fundo, os seus utilizadores só podem ver o que estão autorizados a ver com base nas suas credenciais. Este tipo de segurança permite-lhe alterar direitos para utilizadores de aplicação específicos no origem de dados de back-end após a aplicação ser publicada. Por exemplo, pode conceder acesso, negar acesso ou refinar o que um utilizador ou conjunto de utilizadores pode ver em todas as origem de dados de back-end.

Autorização de padrão aberto (OAuth)

Este tipo de ligação também é seguro. Por exemplo, o Twitter utiliza este tipo de autenticação. Quando se ligar tem de fornecer o seu nome de utilizador e palavra-passe. Como autor, pode criar e trabalhar com o origem de dados com as suas credenciais. Quando publica a sua aplicação e o utilizador da aplicação inicia sessão, também deve apresentar as respetivas credenciais. Consequentemente, este tipo de ligação é seguro, uma vez que os utilizadores têm de utilizar as próprias credenciais para acederem ao serviço de origem de dados.

Ligações partilhadas/Ligações Implícitas Seguras

Numa ligação partilhada, o nome de utilizador e a senha da ligação são fornecidos pelo autor do Power Apps no momento em que a origem de dados é criada na aplicação. A autenticação de ligação para o origem de dados é então Partilhada Implicitamente com os utilizadores finais. Assim que a aplicação é publicada, a ligação também é publicada e está disponível para os utilizadores.

Antes de janeiro de 2024, os seus utilizadores finais poderiam usar a ligação partilhada com eles e criar novas aplicações separadas. Os seus utilizadores não conseguem ver o nome de utilizador ou a palavra-passe, mas a ligação estaria disponível para eles. No entanto, depois de janeiro de 2024, todas as ligações partilhadas recém-criadas estão protegidas. Observe que as aplicações antigas têm ser republicadas para serem protegidas. Isto significa que a ligação já não é partilhada com os utilizadores finais. A Power App publicada comunica com um proxy de ligação. O proxy de ligação comunicará apenas com a Power App específica ao qual está associado. O proxy de ligação limita as ações enviadas às ligações para as que se encontram na Power App {Obter, Colocar/Patch, Eliminar} para uma determinada origem de dados. Se tiver uma aplicação que usa ligações publicadas antes de janeiro de 2024, deve voltar a publicar a sua aplicação e anular a partilha de quaisquer ligações com utilizadores finais que não as deveriam ter.

No SQL Server, a Autenticação do Servidor SQL é um exemplo deste tipo de ligação. Muitas outras origens de dados da base de dados proporcionam uma capacidade semelhante. Ao publicar a sua aplicação, os seus utilizadores não necessitam de fornecer um nome de utilizador e palavra-passe únicos.

Notificação para atualizar as suas aplicações (ligações implícitas seguras)

Se tiver aplicações que poderão ser atualizadas para utilizar esta caraterísticas, verá uma mensagem na página Aplicações. Indica o número de aplicações que necessitam da sua atenção.

Selecione a ligação e isto abre um painel lateral que irá listar todas as aplicações que necessitam de atenção.

Selecione o ícone de abrir à direita do nome da aplicação para a abrir e voltar a publicá-la. Consulte as indicações abaixo.

Ativar ligações implícitas seguras para uma aplicação existente

Abra uma aplicação existente aberta para edição com ligações partilhadas implicitamente que foram publicadas anteriormente:

1. Na barra de comandos, selecione Definições e pesquise por "Protegido".
2. Atualize o comutador de caraterísticas adequadamente para ativar ligações implícitas protegidas.
3. Guarde e publique a aplicação.

Anular partilha

Após a publicação da aplicação, siga estes passos para verificar se a partilha funciona corretamente:

• Verifique se as ligações são partilhadas com os coproprietários. Se não pretende que um utilizador final obtenha uma ligação, desmarque a caixa de verificação Coproprietário.

  

• Para verificar se a funcionalidade funciona corretamente, partilhe a aplicação com um utilizador diferente que não seja um proprietário. Depois de partilhar a aplicação, consulte a lista Ligações no separador Dataverse no Power Apps relativa a esse utilizador. Verifique se o utilizador não tem uma ligação disponível.

• Abra o painel Partilhar para alterar o direito do utilizador final à ligação. A escolha de X irá remover o acesso do utilizador à ligação.

  

Utilizar aplicações com uma nova ligação implícita segura

Quando a sua aplicação é republicada e partilhada, os utilizadores finais não terão acesso à ligação, mas trabalharão com a ligação de proxy oculta. Não conseguirão criar uma nova aplicação baseada na sua ligação original.

Limitações

1. Todos os tipos de ligações partilhadas implícitas funcionam, tais como a ação e o tabular.
2. Os nomes de servidor e de base de dados estão ocultos nos seguimentos da rede, mas visíveis na caixa de diálogo de consentimento. Os nomes das colunas não estão ocultos.
3. Para os conectores tabulares, só limitamos as ações CRUD, tais como Obter, Publicar, Colocar ou Eliminar. Se tiver permissões para Colocar, tem acesso a Publicar.
4. O limite dos conectores baseados em ações com base na API específica que está a ser utilizada na aplicação.
5. Os avisos continuam ativados na partilha. O aviso sobre ligações partilhadas implicitamente continua a avisá-lo durante a pré-visualização privada. No entanto, a sua ligação a esta funcionalidade é segura, apesar do aviso.
6. A publicação para um inquilino inteiro, por oposição a grupos específicos ou indivíduos, não é suportada.
7. Existe um problema conhecido ao importar uma ligação segura partilhada implicitamente através de uma referência de ligação. A segurança não está definida corretamente no ambiente de destino.
8. Existe um problema conhecido quando importa uma solução que utilize um principal de serviço, o que causa uma falha da importação. Uma alternativa é partilhar a ligação com o principal do serviço.

Autenticação do Windows

Este tipo de ligação não é seguro porque não depende da autenticação do utilizador final. Utilize a autenticação do Windows quando necessitar de ligar a um origem de dados no local. Um exemplo deste tipo de ligação é um servidor no local que tenha um SQL Server. A ligação tem de passar através de um gateway. Uma vez que passa por um gateway, o conector tem acesso a todos os dados nessa origem de dados. Como resultado, todas as informações a que pode aceder com as credenciais do Windows que fornece estão disponíveis para o conector. E assim que a aplicação é publicada, a ligação também é publicada e está disponível para os utilizadores. Este comportamento significa que os utilizadores finais também podem criar aplicações utilizando esta mesma ligação e aceder aos dados dessa máquina. As ligações com a origem de dados também são partilhadas implicitamente com os utilizadores com os quais a aplicação é partilhada. Este tipo de ligação poderá ser válido quando a origem de dados só residir num servidor no local e os dados nessa origem forem partilhados livremente.

Origens de dados em soluções

As soluções são utilizadas para a gestão do ciclo de vida da aplicação e fornecem outras capacidades para gerir o ciclo de vida das origens de dados. Se uma aplicação de tela estiver numa solução, poderão ser criadas referências de ligação e variáveis de ambiente para armazenar informações sobre as origens de dados. Isto garante que as origens de dados podem ser alteradas ou restabelecidas quando as soluções são migradas para diferentes ambientes.

Renomear fontes de dados em apps

Para saber sobre renomear fontes de dados numa aplicação, e a diferença entre fontes de dados tabulares e baseadas em ação, vá para renomear Power Apps fontes de dados baseadas em ação.

Diálogo de consentimento da ligação

Quando os utilizadores abrirem uma aplicação que utiliza conectores pela primeira vez, vêem um diálogo de "consentimento de ligação" para as seguintes finalidades.

1. Informar os utilizadores sobre as fontes de dados acedidas pela app.

2. Para delinear as ações, um conector pode ou não realizar numa aplicação. Por exemplo, para aplicações que utilizem o conector Office 365 Utilizadores, este pode ser o seguinte.

   • Esta aplicação pode:
     • Ler o seu perfil de utilizador completo
     • Ler o perfil completo de todos os utilizadores
   • Não será capaz de:
     • Modificar ou eliminar qualquer informação do perfil de utilizador

3. Capturar o consentimento do utilizador final para ligar às fontes de dados que a aplicação utiliza.

4. Facilitar a autenticação manual do utilizador final, quando necessário.

Para algumas ligações, Power Platform pode autenticar automaticamente um utilizador para aceder a uma origem de dados. No entanto, se o login automático falhar, este diálogo leva os utilizadores a corrigir uma ligação iniciando o login manualmente. O Power Platform só pode tentar o acesso automático a uma ligação quando uma origem de dados pré-autorizar o principal de serviço de ligações Azure API da Microsoft, concedendo-lhe permissão para realizar um único sinal de acesso para um utilizador quando uma ligação é criada. Para obter mais informações sobre um início de sessão único, consulte o que é um início de sessão único (SSO)?

Note que para aplicações condicionadas por modelo que usam páginas personalizadas, quando existem várias páginas personalizadas numa aplicação, o diálogo de consentimento pede permissões de dados para todos os conectores em todas as páginas personalizadas, mesmo que ainda não tenham sido abertas.

A imagem a seguir é um exemplo do diálogo de consentimento de ligação para uma aplicação que se liga a um site SharePoint.

Para conectores selecionados, os administradores podem suprimir este diálogo e consentir em nome dos utilizadores finais para se ligarem a uma origem de dados. A tabela seguinte explica quais os tipos de conectores que o diálogo de consentimento pode ser suprimido para uma aplicação.

Microsoft Power Platform só pode suprimir o diálogo de consentimento para ligações a fontes de dados quando:

1. Não há a obrigação da origem de dados de mostrar um consentimento explícito.
2. A origem de dados pré-autoriza o principal do serviço de ligações Azure API da Microsoft para permitir um início único de sessão.
3. Um administrador configura uma aplicação para suprimir o consentimento para as ligações anteriores.

A pré-autorização do principal do serviço de conexões Azure API da Microsoft existe para as primeiras fontes de dados da Microsoft, e pode ser configurada por aplicações personalizadas registadas num inquilino Microsoft Entra que são utilizadas por conectores personalizados. Um administrador gere a supressão de consentimento numa base por aplicação (em oposição à base de conector), pelo que a supressão é gerida ao nível mais granular de experiência de aplicações—este nível de granularidade impede a supressão de consentimento para as "aplicações aprovadas" de uma organização de suprimir inadvertidamente o consentimento para apps que não são aprovadas ou revistas.