O que são conectores no Azure Logic Apps

Quando cria um fluxo de trabalho com o Azure Logic Apps, pode utilizar um conector para trabalhar com dados, eventos e recursos noutras aplicações, serviços, sistemas e plataformas sem escrever código. Um conector fornece uma ou mais operações pré-criadas, que utiliza como passos no fluxo de trabalho.

Num conector, cada operação é uma condição de acionador que inicia um fluxo de trabalho ou uma ação subsequente que executa uma tarefa específica, juntamente com as propriedades que pode configurar. Embora muitos conectores tenham acionadores e ações, alguns conectores oferecem apenas acionadores, enquanto outros fornecem apenas ações.

No Azure Logic Apps, os conectores estão disponíveis numa versão incorporada, numa versão gerida ou em ambos. Normalmente, muitos conectores exigem que crie e configure uma ligação ao serviço ou sistema subjacente, normalmente para que possa autenticar o acesso a uma conta de utilizador. Se não estiver disponível nenhum conector para o serviço ou sistema ao qual pretende aceder, pode enviar um pedido através da operação HTTP genérica ou pode criar um conector personalizado.

Esta descrição geral fornece uma introdução de alto nível aos conectores e como funcionam geralmente. Para obter mais informações sobre o conector, veja a seguinte documentação:

Conectores incorporados versus conectores geridos

No Azure Logic Apps, os conectores são incorporados ou geridos. Alguns conectores têm ambas as versões. As versões disponíveis dependem se cria um fluxo de trabalho da aplicação lógica consumo que é executado no Azure Logic Apps multi-inquilino ou num fluxo de trabalho da aplicação lógica Standard que é executado no Azure Logic Apps de inquilino único. Para obter mais informações sobre os tipos de recursos da aplicação lógica, veja Tipos de recursos e diferenças de ambiente de anfitrião.

  • Os conectores incorporados foram concebidos para serem executados de forma direta e nativa no Azure Logic Apps.

  • Os conectores geridos são implementados , alojados e geridos no Azure pela Microsoft. Os conectores geridos fornecem principalmente um proxy ou um wrapper em torno de uma API que o serviço ou sistema subjacente utiliza para comunicar com o Azure Logic Apps.

    • Num fluxo de trabalho Consumo, os conectores geridos aparecem no estruturador nas etiquetas Standard ou Enterprise , com base no respetivo nível de preço.

    • Num fluxo de trabalho Standard, todos os conectores geridos aparecem no estruturador na etiqueta do Azure .

Para obter mais informações, veja a seguinte documentação:

Acionadores

Um acionador especifica a condição a cumprir antes de o fluxo de trabalho poder ser iniciado e é sempre o primeiro passo em qualquer fluxo de trabalho. Cada acionador também segue um padrão de acionamento específico que controla a forma como o acionador monitoriza e responde a eventos. Normalmente, um acionador segue um padrão de consulta ou um padrão push . Por vezes, ambas as versões do acionador estão disponíveis.

  • Os acionadores de consultas verificam regularmente um serviço ou sistema específico numa agenda especificada para verificar a existência de novos dados ou de um evento específico. Se estiverem disponíveis novos dados ou o evento específico acontecer, estes acionadores criam e executam uma nova instância do fluxo de trabalho. Esta nova instância pode, em seguida, utilizar os dados transmitidos como entrada.

  • Os acionadores push ou webhook escutam novos dados ou para que um evento aconteça, sem consulta. Quando estão disponíveis novos dados ou quando o evento acontece, estes acionadores criam e executam uma nova instância do fluxo de trabalho. Esta nova instância pode, em seguida, utilizar os dados transmitidos como entrada.

Por exemplo, suponha que pretende criar um fluxo de trabalho que é executado quando um ficheiro é carregado para o servidor FTP. Como primeiro passo no fluxo de trabalho, pode adicionar o acionador FTP com o nome Quando um ficheiro é adicionado ou modificado, que segue um padrão de consulta. Em seguida, especifique a agenda para verificar regularmente a existência de eventos de carregamento.

Quando o acionador é acionado, o acionador geralmente transmite saídas de eventos para ações subsequentes para referência e utilização. Para o exemplo de FTP, o acionador produz automaticamente informações como o nome e o caminho do ficheiro. Também pode configurar o acionador para incluir o conteúdo do ficheiro. Por isso, para processar estes dados, tem de adicionar ações ao fluxo de trabalho.

Ações

Uma ação especifica uma tarefa a executar e aparece sempre como um passo subsequente no fluxo de trabalho. Pode utilizar várias ações no fluxo de trabalho. Por exemplo, pode iniciar o fluxo de trabalho com um SQL Server acionador que verifica a existência de novos dados de clientes numa base de dados SQL. Após o acionador, o fluxo de trabalho pode ter uma ação SQL Server que obtém os dados do cliente. Após esta ação SQL Server, o fluxo de trabalho pode utilizar uma ação diferente que processa os dados, por exemplo, uma ação de Operações de Dados que cria uma tabela CSV.

Permissões da ligação

Num fluxo de trabalho da aplicação lógica consumo, antes de poder criar ou gerir recursos de aplicações lógicas, fluxos de trabalho e as respetivas ligações, precisa de permissões específicas. Para obter mais informações sobre estas permissões, veja Operações seguras – Acesso seguro e dados no Azure Logic Apps.

Criação, configuração e autenticação de ligações

Antes de poder utilizar as operações de um conector no fluxo de trabalho, muitos conectores exigem que crie primeiro uma ligação ao serviço ou sistema de destino. Para criar uma ligação a partir do estruturador de fluxo de trabalho, tem de autenticar a sua identidade com credenciais de conta e, por vezes, outras informações de ligação.

Por exemplo, antes de o fluxo de trabalho poder aceder e trabalhar com o seu Office 365 conta de e-mail do Outlook, tem de autorizar uma ligação a essa conta. Para alguns conectores incorporados e conectores geridos, pode configurar e utilizar uma identidade gerida para autenticação, em vez de fornecer as suas credenciais.

Embora crie ligações num fluxo de trabalho, estas ligações são, na verdade, recursos do Azure separados com as suas próprias definições de recursos. Para rever estas definições de recursos de ligação, siga estes passos com base no facto de ter um Fluxo de trabalho De Consumo ou Standard:

Segurança e encriptação de ligação

Os detalhes da configuração da ligação, como o endereço do servidor, o nome de utilizador e a palavra-passe, as credenciais e os segredos são encriptados e armazenados no ambiente protegido do Azure. Estas informações só podem ser utilizadas em recursos de aplicações lógicas e por clientes que tenham permissões para o recurso de ligação, que é imposto através de verificações de acesso ligadas. As ligações que utilizam a Autenticação Aberta do Azure Active Directory (Azure AD OAuth), como Office 365, Salesforce e GitHub, exigem que inicie sessão, mas o Azure Logic Apps armazena apenas tokens de acesso e atualização como segredos e não credenciais de início de sessão.

As ligações estabelecidas podem aceder ao serviço ou sistema de destino desde que esse serviço ou sistema o permita. Para serviços que utilizam Azure AD ligações OAuth, como Office 365 e Dynamics, o Azure Logic Apps atualiza os tokens de acesso indefinidamente. Outros serviços podem ter limites para quanto tempo o Logic Apps pode utilizar um token sem atualizar. Algumas ações, como alterar a palavra-passe, invalidam todos os tokens de acesso.

Nota

Se a sua organização não permitir que aceda a recursos específicos através de conectores no Azure Logic Apps, pode bloquear a capacidade de criar essas ligações com Azure Policy.

Para obter mais informações sobre como proteger fluxos de trabalho e ligações de aplicações lógicas, veja Acesso seguro e dados no Azure Logic Apps.

Acesso à firewall para ligações

Se utilizar uma firewall que limite o tráfego e os fluxos de trabalho da aplicação lógica precisarem de comunicar através dessa firewall, terá de configurar a firewall para permitir o acesso aos endereços IP de entrada e saída utilizados pela plataforma do Azure Logic Apps ou runtime na região do Azure onde existem fluxos de trabalho da aplicação lógica.

Se os seus fluxos de trabalho também utilizarem conectores geridos, como o conector do Office 365 Outlook ou o conector SQL, ou utilizar conectores personalizados, a firewall também terá de permitir o acesso a todos osendereços IP de saída do conector gerido na região do Azure do recurso da aplicação lógica. Para obter mais informações, veja Configuração da firewall.

Conectores e APIs personalizados

Em Fluxos de trabalho de Consumo para aplicações lógicas do Azure multi-inquilino, pode chamar APIs baseadas em Swagger ou baseadas em SOAP que não estão disponíveis como conectores fora da caixa. Também pode executar código personalizado ao criar Aplicações de API personalizadas. Para obter mais informações, veja a seguinte documentação:

Nos fluxos de trabalho Standard para o Azure Logic Apps de inquilino único, pode criar conectores incorporados personalizados baseados em fornecedores de serviços baseados nativamente em execução que estejam disponíveis para qualquer fluxo de trabalho da aplicação lógica Standard. Para obter mais informações, veja a seguinte documentação:

ISE e conectores

Para fluxos de trabalho que precisam de acesso direto aos recursos numa rede virtual do Azure, pode criar um ambiente de serviço de integração dedicado (ISE) onde pode criar, implementar e executar os seus fluxos de trabalho em recursos dedicados. Para obter mais informações sobre como criar ISEs, veja Connect to Azure virtual networks from Azure Logic Apps (Ligar a redes virtuais do Azure a partir do Azure Logic Apps).

Os conectores personalizados criados num ISE não funcionam com o gateway de dados no local. No entanto, estes conectores podem aceder diretamente a origens de dados no local que estão ligadas a uma rede virtual do Azure que aloja o ISE. Assim, os fluxos de trabalho de aplicações lógicas num ISE provavelmente não precisam do gateway de dados quando comunicam com esses recursos. Se tiver conectores personalizados que criou fora de um ISE que exijam o gateway de dados no local, os fluxos de trabalho num ISE podem utilizar esses conectores.

No estruturador de fluxos de trabalho, quando navega nos conectores incorporados ou nos conectores geridos que pretende utilizar para fluxos de trabalho num ISE, a etiqueta CORE é apresentada em conectores incorporados, enquanto a etiqueta ISE é apresentada nos conectores geridos concebidos para funcionar com um ISE.

Conector CORE de exemplo

NÚCLEO

Os conectores incorporados com esta etiqueta são executados no mesmo ISE que os seus fluxos de trabalho.

Conector ISE de exemplo

ISE

Os conectores geridos com esta etiqueta são executados no mesmo ISE que os seus fluxos de trabalho.

Se tiver um sistema no local ligado a uma rede virtual do Azure, um ISE permite que os fluxos de trabalho acedam diretamente a esse sistema sem utilizar o gateway de dados no local. Em vez disso, pode utilizar o conector ISE desse sistema, se disponível, uma ação HTTP ou um conector personalizado.

Para sistemas no local que não têm conectores ISE , utilize o gateway de dados no local. Para encontrar os conectores ISE disponíveis, veja Conectores ISE.

Exemplo de conector não ISE

Sem etiqueta

Todos os outros conectores sem uma etiqueta, que pode continuar a utilizar, são executados no serviço Global de Aplicações Lógicas multi-inquilino.

Problemas conhecidos

A tabela seguinte inclui problemas conhecidos para conectores no Azure Logic Apps:

Mensagem de erro Description Resolução
Error: BadGateway. Client request id: '{GUID}' Este erro resulta da atualização das etiquetas num recurso de aplicação lógica em que uma ou mais ligações não suportam a autenticação OAuth do Azure Active Directory (Azure AD), como o SQL do Ad SFTP, interrompendo essas ligações. Para evitar este comportamento, evite atualizar essas etiquetas.

Passos seguintes