Visão geral de conectores para aplicativos de tela

Os dados estão no cerne da maioria dos aplicativos, inclusive os dados que você cria no Power Apps. Os dados são armazenados em uma fonte de dados, e você coloca esses dados em seu aplicativo ao criar uma conexão. A conexão usa um determinado conector para se comunicar com a fonte de dados. O Power Apps tem conectores para muitos serviços populares e fontes de dados locais, incluindo SharePoint, SQL Server, Office 365, Salesforce e Twitter. Para começar a adicionar dados a um aplicativo de tela, confira Adicionar uma conexão de dados ao Power Apps.

Um conector pode fornecer tabelas de dados ou ações. Alguns conectores fornecem apenas tabelas, alguns fornecem apenas ações e alguns fornecem ambos. Além disso, o conector pode ser personalizado ou padrão.

Tabelas

Se o conector fornecer tabelas, você poderá adicionar sua fonte de dados e, em seguida, selecionar a tabela da fonte de dados que deseja gerenciar. O Power Apps recupera dados da tabela em seu aplicativo e atualiza os dados na fonte de dados para você. Por exemplo, você pode adicionar uma fonte de dados que contém uma tabela chamada Lessons e, em seguida, definir a propriedade Items de um controle, como uma galeria ou um formulário, como esse valor na barra de fórmulas:

Propriedade Items de uma fonte de dados simples.

Você pode especificar os dados que seu aplicativo recupera personalizando a propriedade Items do controle que mostra os dados. Dando continuidade ao exemplo anterior, você pode classificar ou filtrar os dados na tabela Lessons usando esse nome como um argumento para as funções Search e SortByColumn. Neste gráfico, a fórmula para a qual a propriedade Items está definida especifica que os dados são classificados e filtrados com base no texto em TextSearchBox1.

Propriedade Items da fonte de dados expandida.

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

Entender fontes de dados no Power Apps
Gerar um aplicativo de dados do Excel
Criar um aplicativo do zero
Entender tabelas e registros no Power Apps

Observação

Para se conectar a dados em uma pasta de trabalho do Excel, ela precisa estar hospedada em um serviço de armazenamento na nuvem, como o OneDrive. Para obter mais informações, consulte Conectar-se ao armazenamento em nuvem a partir do Power Apps.

Ações

Se seu conector fornece ações, você ainda precisa selecionar sua fonte de dados como fez anteriormente. No entanto, em vez de selecionar uma tabela como a próxima etapa, você conecta manualmente um controle a uma ação editando a propriedade Items do controle que mostrará seus dados. A fórmula para a qual você define a propriedade Items especifica a ação que recupera dados. Por exemplo, o aplicativo não recuperará dados se você se conectar ao Yammer e, em seguida, definir a propriedade Items como o nome da fonte de dados. Para preencher um controle com os dados, especifique uma ação, como GetMessagesInGroup(5033622).messages.

Propriedade Items de uma fonte de dados de ação.

Se precisar lidar com atualizações de dados personalizados para 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 você associará a ela.

Para obter mais informações sobre como personalizar sua fórmula para atualizações personalizadas, confira estes artigos:

Patch
Collect
Update

Observação

Para trabalhar com um esquema dinâmico, você pode usar um recurso experimental chamado Esquema dinâmico. Esquema dinâmico refere-se à possibilidade de que a mesma ação retorne uma tabela diferente com colunas diferentes. As condições que podem fazer com que as colunas nas tabelas sejam diferentes incluem os parâmetros de entrada da ação, o usuário ou função que está executando a ação e o grupo em que o usuário está trabalhando, entre outros. Por exemplo, os procedimentos armazenados do SQL Server podem retornar colunas diferentes se executados com entradas diferentes, ou uma instância do Azure DevOps pode usar campos personalizados que não estão disponíveis por padrão. Para trabalhar com esquema dinâmico, o documentação do conector mostra As saídas desta operação são dinâmicas. como valor de devolução. Para obter mais informações sobre como trabalhar com esquema dinâmico no Power Apps, consulte trabalhar com esquema dinâmico no Power Apps (experimental)

Esta tabela contém links para obter mais informações sobre nossos conectores mais populares. Para obter uma lista completa dos conectores, consulte Todos os conectores.

         
Microsoft Dataverse. Microsoft Dataverse   Armazenamento em nuvem Armazenamento em nuvem **
Dynamics AX. Dynamics AX   Microsoft Excel Excel
Microsoft Translator. Microsoft Translator   Office 365 Outlook Office 365 Outlook
Usuários do Office 365. Usuários do Office 365   Oracle Oracle
Power BI. Power BI   Logotipo da SharePoint SharePoint
SQL Server. SQL Server   Logotipo do Twitter Twitter

** Aplica-se ao Azure Blob, Box, Dropbox, Google Drive, OneDrive e OneDrive for Business

Conectores padrão e personalizados

O Power Apps fornece conectores padrão para muitas fontes de dados comumente usadas. Se o Power Apps tiver um conector padrão para o tipo de fonte de dados que você deseja usar, use esse conector. Caso queira se conectar a outros tipos de fontes de dados, como um serviço que criou, confira Registrar e usar conectores personalizados.

Todos os conectores padrão

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

Você pode fazer perguntas sobre um conector específico nos Fóruns do Power Apps e pode sugerir conectores a serem adicionados ou outras melhorias a serem feitas em Ideias do Power Apps.

Segurança e tipos de autenticação

Ao criar seu aplicativo e uma conexão com uma fonte de dados, você poderá ver que sua opção de conector permite usar maneiras diferentes de autenticação. Por exemplo, o conector do SQL Server permite usar Azure AD Integrated, Autenticação do SQL Server e Autenticação do Windows. Cada tipo de autenticação possui diferentes níveis de segurança associados. É importante entender quais informações e direitos você compartilha com os usuários que usam seu aplicativo. O exemplo principal neste artigo é o SQL Server. No entanto, os princípios se aplicam a todos os tipos de conexões.

Observação

Para obter informações detalhadas sobre considerações de segurança ao usar um servidor de banco de dados relacional (como Microsoft SQL Server ou Oracle) como a fonte de dados para um aplicativo, consulte Usar o Microsoft SQL Server com segurança com o Power Apps.

Azure AD Integrated

Esse é um tipo de conexão segura. Por exemplo, o SharePoint usa esse tipo de autenticação. O SQL Server também permite esse tipo de autenticação. Quando você se conecta, o serviço do Azure AD identifica você separadamente para fazer SharePoint em seu nome. Você não precisa fornecer um nome de usuário ou senha. Como autor, você pode criar e trabalhar com a fonte de dados com suas credenciais. Quando você publica seu aplicativo e o usuário do aplicativo efetua login, ele o faz com sua própria credencial. Se os dados estiverem devidamente protegidos em um back-end, seus usuários só poderão ver aquilo que estão autorizados a ver com base em suas credenciais. Esse tipo de segurança permite alterar os direitos de usuários específicos do aplicativo na fonte de dados de back-end após a publicação do aplicativo. Por exemplo, você pode conceder acesso, negar acesso ou refinar o que um usuário ou conjunto de usuários pode ver, tudo na fonte de dados de back-end.

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

Esse tipo de conexão também é seguro. Por exemplo, o Twitter usa esse tipo de autenticação. Ao se conectar, você deve fornecer seu nome de usuário e senha. Como autor, você pode criar e trabalhar com a fonte de dados com suas credenciais. Quando você publica seu aplicativo e o usuário do aplicativo efetua login, eles também precisam fornecer suas próprias credenciais. Portanto, esse tipo de conexão é seguro, pois os usuários devem usar suas próprias credenciais para acessar o serviço de fonte de dados.

Autenticação de nome de usuário e senha de usuário do SQL

Esse tipo de conexão não é seguro porque não depende da autenticação do usuário final. Deve ser usado apenas nos casos em que você possa supor com segurança que todos com acesso a essa conexão podem ver e usar todos os dados aos quais a conexão fornece acesso. Você não pode bloquear de forma confiável partes dos dados acessíveis na conexão. Por exemplo, se a conexão permitir acesso a uma única tabela, você não poderá contar com uma ID de usuário para filtrar, mas apenas para ver os dados desse usuário específico dentro dessa tabela. Para uma segurança confiável, use uma conexão mais segura, como Integrado ao Azure AD.

No SQL Server, esse tipo de conexão é chamado Autenticação do SQL Server. Muitas outras fontes de dados de bancos de dados fornecem um recurso semelhante. Quando você publica seu aplicativo, os usuários não precisam fornecer um nome de usuário e uma senha exclusivos. Eles estão usando o nome de usuário e a senha que você forneceu ao criar o aplicativo. A autenticação de conexão com a fonte de dados é Implicitamente compartilhada com seus usuários. Assim que o aplicativo é publicado, a conexão também é publicada e disponibilizada para seus usuários. Os usuários finais também podem criar aplicativos usando qualquer conexão compartilhada com eles que use a autenticação do SQL Server. Seus usuários não podem ver o nome de usuário ou senha, mas a conexão estará disponível para eles. Existem cenários válidos para este tipo de conexão. Por exemplo, se você tiver um banco de dados somente leitura disponível para todos na empresa. Cenários de dados de referência (por exemplo, um calendário corporativo) podem ser úteis para esse tipo de conexão. Mais informações: Usar o Microsoft SQL Server com segurança com o Power Apps

Autenticação do Windows

Esse tipo de conexão não é seguro porque não depende da autenticação do usuário final. Use a Autenticação do Windows quando precisar se conectar a uma fonte de dados que seja local. Um exemplo desse tipo de conexão é com um servidor local que possui um SQL Server. A conexão deve passar por um gateway. Como ela passa por um gateway, o conector tem acesso a todos os dados nessa fonte de dados. Como resultado, todas as informações que você pode acessar com as credenciais do Windows fornecidas estarão disponíveis para o conector. E assim que o aplicativo é publicado, a conexão também é publicada e disponibilizada para seus usuários. Esse comportamento significa que seus usuários finais também podem criar aplicativos usando essa mesma conexão e acessar os dados nessa máquina. As conexões com a fonte de dados também são Implicitamente compartilhadas com usuários com os quais o aplicativo é compartilhado. Esse tipo de conexão pode ser válido quando sua fonte de dados reside apenas em um servidor local e os dados nessa fonte podem ser compartilhados livremente.

Fontes de dados em soluções

As soluções são usadas para gerenciar o ciclo de vida de aplicativos e fornecer recursos adicionais para gerenciar o ciclo de vida de fontes de dados. Se um aplicativo de tela estiver em uma solução, referências de conexão e variáveis ambientais podem ser criadas para armazenar informações sobre as fontes de dados. Isso garante que as fontes de dados possam ser alteradas ou restabelecidas quando as soluções forem migradas para ambientes diferentes.

Renomear fontes de dados em aplicativos

Para saber mais sobre como renomear fontes de dados em um aplicativo e a diferença entre as fontes de dados tabulares e as baseadas em ações, vá para Renomear fontes de dados do Power Apps baseadas em ações.

Quando abrem um aplicativo que usa conectores pela primeira vez, os usuários veem a caixa de diálogo "Consentimento de conexão" para as seguintes finalidades.

  1. Para informar os usuários sobre as fontes de dados acessadas pelo aplicativo.

  2. Para delinear as ações que um conector pode ou não executar em um aplicativo. Por exemplo, para aplicativos que usam o conector Usuários do Office 365, pode ser o seguinte.

    • Este aplicativo será capaz de:
      • Ler o seu perfil de usuário completo
      • Ler o perfil completo de todos os usuários
    • Ele não será capaz de:
      • Modificar ou excluir qualquer informação de perfil de usuário
  3. Obter o consentimento do usuário final para se conectar às fontes de dados que o aplicativo usa.

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

Para algumas conexões, o Power Platform pode autenticar automaticamente um usuário para acessar uma fonte de dados. No entanto, se o login automático falhar, esta caixa de diálogo solicitará que os usuários corrijam uma conexão fazendo login manualmente. O Power Platform só pode tentar o logon automático para uma conexão quando uma fonte de dados autoriza previamente a entidade de serviço de conexões da API do Azure da Microsoft, concedendo a ela permissão para executar logon único para um usuário quando uma conexão é criada. Para obter mais informações sobre logon único, consulte O que é logon único (SSO)?

A imagem a seguir é um exemplo da caixa de diálogo de consentimento de conexão para um aplicativo conectado a um local do SharePoint.

Caixa de diálogo de consentimento do Power Apps

Para conectores específicos, os administradores podem suprimir esta caixa de diálogo e consentir em nome dos usuários finais para se conectar a uma fonte de dados. A tabela a seguir explica quais tipos de conectores a caixa de diálogo de consentimento pode suprimir para um aplicativo.

Observação

Se um administrador suprimir a caixa de diálogo de consentimento, mas a plataforma não puder executar o logon único para um usuário final, a caixa de diálogo será apresentada ao usuário quando ele iniciar o aplicativo.

Tipo de conector Caixa de diálogo de consentimento suprimível? Referência
Conectores próprios da Microsoft que oferecem suporte a logon único (como usuários do SharePoint, Office 365) Sim cmdlet do admin do Power Apps
Conector que acessa um serviço de terceiros não Microsoft, como o Salesforce Não Não aplicável
Conectores personalizados que usam o OAuth com o Azure Active Directory como o provedor de identidade. Estes são conectores personalizados desenvolvidos por organizações e só podem ser acessados pelos usuários dentro da organização (por exemplo, desenvolvidos pela Contoso somente para usuários da Contoso) Sim Gerenciar Conexões

O Microsoft Power Platform só pode suprimir a caixa de diálogo de consentimento para conexões com fontes de dados em que:

  1. Não haja uma obrigação por parte da fonte de dados de mostrar uma IU de consentimento explícito.
  2. A fonte de dados pré-autoriza a entidade de serviço de conexões da API do Azure da Microsoft para habilitar o logon único.
  3. Um administrador configura um aplicativo para suprimir o consentimento para as conexões anteriores.

A pré-autorização da entidade de serviço de conexões da API do Azure da Microsoft existe para as fontes de dados primárias da Microsoft e pode ser configurada por aplicativos personalizados registrados em um locatário do Azure AD que são usados por conectores personalizados. Um administrador gerencia a supressão de consentimento por aplicativo (em oposição à base de conector), portanto, a supressão é gerenciada no nível de experiência de aplicativo mais granular—este nível de granularidade evita que a supressão de consentimento para "aplicativos aprovados" de uma organização suprima inadvertidamente o consentimento para aplicativos que não foram aprovados ou revisados.

Observação

Você pode nos falar mais sobre suas preferências de idioma para documentação? Faça uma pesquisa rápida. (Observe que esta pesquisa está em inglês)

A pesquisa levará cerca de sete minutos. Nenhum dado pessoal é coletado (política de privacidade).