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

Os dados são o núcleo da maioria das aplicações, incluindo aplicações criadas 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. O Power Apps obtém dados das tabelas na sua aplicação e atualiza os dados na sua origem de dados automaticamente. Por exemplo, adicione uma origem de dados que tem 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:

Especifique os dados que a aplicação obtém ao personalizar a propriedade Itens do controlo que mostra os seus dados. Continuando o exemplo anterior, ordene ou filtre 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 definida para a propriedade Itens especifica que os dados são ordenados e filtrados com base no texto TextSearchBox1.

Para obter mais informações sobre a personalização da 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 fornecer ações, selecione a sua origem de dados como anteriormente. 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 mostra os seus dados. A fórmula que definir para a propriedade Itens especifica a ação que obtém dados. Por exemplo, a aplicação não obtém quaisquer dados se se ligar ao Yammer e, em seguida, definir a propriedade Items para o nome da origem de dados. Para preencher um controlo com dados, especifique uma ação como GetMessagesInGroup(5033622).messages.

Para 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 devolver uma tabela com colunas diferentes dependendo da forma como é chamada. As condições que podem fazer com que as colunas na tabela sejam diferentes incluem os parâmetros de entrada da ação, o utilizador/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.

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

Conectores populares

Esta tabela liga-se a mais informações sobre conectores populares. Para obter uma lista completa, consulte Todos os conectores.

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

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 o tipo de origem de dados que quer utilizar, utilize esse conector. Para ligar a outros tipos de origens de dados, como um serviço que criou, consulte Registar e utilizar conectores personalizados.

Todos os conectores padrão

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

Faça perguntas sobre um conector específico nos fóruns do Power Apps e sugira conectores que pretende adicionar ou outras melhorias no Ideias do Power Apps.

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

Esta autenticação trata-se de um tipo de ligação segura. 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 a 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 estiverem devidamente protegidos num back-end, os seus utilizadores só poderão 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. Ao ligar-se, deve fornecer o seu nome de utilizador e palavra-passe. Como autor, pode criar e trabalhar com a 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 palavra-passe 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 utilizadores finais podiam utilizar a ligação partilhada 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, após janeiro de 2024, todas as ligações partilhadas recém-criadas são protegidas. As aplicações antigas têm de ser publicadas novamente para serem protegidas. 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 só comunica com o Power App específico ao qual está vinculado. 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 a utilizar as ligações publicadas antes de janeiro de 2024, republique a sua aplicação e cancele a partilha de quaisquer ligações com utilizadores finais que não as devam 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 podem ser atualizadas para usar esta caraterística, 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 esta abrirá um painel lateral que lista todas as aplicações que precisam de atenção.

Selecione o ícone de abrir à direita do nome da aplicação para a abrir e voltar a publicá-la. Continue com as seguintes orientações.

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 já publicadas:

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, verifique a lista Ligações no separador Dataverse no Power Apps para 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. Escolher o X remove 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 têm acesso à ligação, mas trabalham com a ligação proxy oculta. Os utilizadores não podem criar uma nova aplicação com base 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 ainda avisa durante a pré-visualização. 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 implicitamente partilhada 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 ao importar uma solução utilizando um principal de serviço, causando falhas na 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 ajudam na gestão do ciclo de vida das aplicações e oferecem outras formas de gerir o ciclo de vida das origens de dados. Se uma aplicação de tela estiver numa solução, podem ser criadas referências de ligação e variáveis de ambiente para armazenar informações sobre as origens de dados. Esta configuração facilita alterar ou voltar a ligar origens de dados quando move soluções para ambientes diferentes.

Renomear fontes de dados em apps

Obtenha informações sobre como mudar o nome de origens de dados numa aplicação e compreenda a diferença entre origens de dados tabulares e baseadas em ação. Para obter mais informações, consulte Mudar o nome de origens de dados baseadas em ação do Power Apps.

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 Utilizadores do Office 365:

• Esta aplicação pode:
  • Ler o seu perfil de utilizador completo
  • Ler o perfil completo de todos os utilizadores
• A aplicação não pode:
  • 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)?

Para aplicações condicionadas por modelo que usam páginas personalizadas, quando há várias páginas personalizadas numa aplicação, o diálogo de consentimento pede as permissões de dados para todos os conectores em todas as páginas personalizadas, mesmo que não sejam abertos.

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 poderá ser configurada por aplicações personalizadas registadas num inquilino do 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 as aplicações que não são aprovadas ou revistas.