O que são conectores nos fluxos de trabalho para Azure Logic Apps?

Ao criar um fluxo de trabalho usando os Aplicativos Lógicos do Azure, você pode usar um conector para trabalhar com dados, eventos e recursos em outros aplicativos, serviços, sistemas e plataformas - sem escrever código. Um conector fornece uma ou mais operações pré-criadas, que você usa como etapas em seu fluxo de trabalho.

Em um conector, cada operação é uma condição de gatilho que inicia um fluxo de trabalho ou uma ação subsequente que executa uma tarefa específica, juntamente com as propriedades que você pode configurar. Enquanto muitos conectores têm gatilhos e ações, alguns conectores oferecem apenas gatilhos, enquanto outros fornecem apenas ações.

Nos Aplicativos Lógicos do Azure, os conectores estão disponíveis em uma versão interna, gerenciada ou ambas. Muitos conectores geralmente exigem que você primeiro crie e configure uma conexão com o serviço ou sistema subjacente, geralmente para que você possa autenticar o acesso a uma conta de usuário. Se nenhum conector estiver disponível para o serviço ou sistema que você deseja acessar, você pode enviar uma solicitação usando a operação HTTP genérica ou pode criar um conector personalizado.

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

Conectores integrados versus conectores gerenciados

Nos Aplicativos Lógicos do Azure, os conectores são internos ou gerenciados. Alguns conectores têm ambas as versões. As versões disponíveis dependem se você cria um fluxo de trabalho de aplicativo lógico de consumo executado em Aplicativos Lógicos do Azure multilocatário ou um fluxo de trabalho de aplicativo lógico padrão executado em Aplicativos Lógicos do Azure de locatário único. Para obter mais informações sobre tipos de recursos de aplicativos lógicos, consulte Tipos de recursos e diferenças de ambiente de host.

  • Os conectores internos são projetados para serem executados direta e nativamente dentro dos Aplicativos Lógicos do Azure.

    No designer, todos os conectores incorporados aparecem na galeria de conectores dentro do grupo Na aplicação.

  • Os conectores gerenciados são implantados, hospedados e gerenciados no Azure pela Microsoft. Os conectores gerenciados geralmente fornecem um proxy ou um wrapper em torno de uma API que o serviço ou sistema subjacente usa para se comunicar com os Aplicativos Lógicos do Azure.

    No designer, todos os conectores gerenciados aparecem na galeria de conectores dentro do grupo Compartilhado . São faturados no nível Standard ou Enterprise.

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

Triggers

Um gatilho especifica a condição a ser atendida antes que o fluxo de trabalho possa ser iniciado e é sempre a primeira etapa em qualquer fluxo de trabalho. Cada gatilho também segue um padrão de disparo específico que controla como o gatilho monitora e responde a eventos. Normalmente, um gatilho segue um padrão de sondagem ou um padrão de push. Às vezes, ambas as versões de gatilho estão disponíveis.

  • Os gatilhos de votação verificam regularmente um serviço ou sistema específico em um cronograma especificado para verificar novos dados ou um evento específico. Se novos dados estiverem disponíveis ou o evento específico acontecer, esses gatilhos criarão e executarão uma nova instância do seu fluxo de trabalho. Essa nova instância pode usar os dados passados como entrada.

    Nota

    Para conectores que são gerenciados, hospedados e executados pela Microsoft no Azure, os gatilhos de sondagem usam apenas os valores Intervalo e Frequência para calcular a próxima recorrência. Eles não usam as opções avançadas de agendamento, como Nestas horas e Nestes dias. Essas opções funcionam apenas com gatilhos de sondagem internos que são executados diretamente com o ambiente de execução dos Aplicativos Lógicos do Azure, como Recorrência, Janela Deslizante e HTTP.

  • Os gatilhos push ou webhook escutam novos dados ou para que um evento aconteça, sem sondagem. Quando novos dados estão disponíveis ou quando o evento acontece, esses gatilhos criam e executam uma nova instância do seu fluxo de trabalho. Essa nova instância pode usar os dados passados como entrada.

Por exemplo, suponha que você queira criar um fluxo de trabalho que seja executado quando um arquivo é carregado no servidor FTP. Como primeira etapa em seu fluxo de trabalho, você pode adicionar o gatilho FTP chamado Quando um arquivo é adicionado ou modificado, que segue um padrão de sondagem. Em seguida, especifique o cronograma para verificar regularmente se há eventos de upload.

Quando o gatilho é acionado, o gatilho geralmente transmite saídas de eventos para ações subsequentes a serem referenciadas e usadas. Para o exemplo de FTP, o gatilho produz automaticamente informações como o nome do arquivo e o caminho. Você também pode configurar o gatilho para incluir o conteúdo do arquivo. Portanto, para processar esses dados, você deve adicionar ações ao seu fluxo de trabalho.

Ações

Uma ação especifica uma tarefa a ser executada e sempre aparece como uma etapa subsequente no fluxo de trabalho. Você pode usar várias ações em seu fluxo de trabalho. Por exemplo, pode iniciar o fluxo de trabalho com um gatilho do SQL Server que verifica novos dados de clientes numa base de dados SQL. Após o gatilho, seu fluxo de trabalho pode ter uma ação do SQL Server que obtém os dados do cliente. Após essa ação do SQL Server, seu fluxo de trabalho pode usar 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 de ligação

Num fluxo de trabalho de uma aplicação lógica de Consumo, é necessário ter permissões específicas para poder criar ou gerir recursos de aplicações lógicas, fluxos de trabalho e as respetivas ligações. Para obter mais informações sobre essas permissões, consulte Operações seguras - Acesso e dados seguros em Aplicativos Lógicos do Azure.

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

Antes de poder usar as operações de um conector em seu fluxo de trabalho, muitos conectores exigem que você primeiro crie uma conexão com o serviço ou sistema de destino. Para criar uma conexão de dentro do designer de fluxo de trabalho, você precisa autenticar sua identidade com credenciais de conta e, às vezes, outras informações de conexão.

Por exemplo, antes que seu fluxo de trabalho possa acessar e trabalhar com sua conta de email do Office 365 Outlook, você deve autorizar uma conexão com essa conta. Para alguns conectores internos e conectores gerenciados, você pode configurar e usar uma identidade gerenciada para autenticação, em vez de fornecer suas credenciais.

Para conectores geridos, as ligações são recursos Azure separados com as suas próprias definições de recursos. Para conectores incorporados em fluxos de trabalho Standard, a configuração da conexão é armazenada com a configuração da aplicação lógica, incluindo o ficheiro connections.json e as definições da aplicação referenciadas. Para rever a informação de ligação, siga estes passos consoante se tem um fluxo de trabalho de Consumo ou Padrão:

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

Os serviços do Azure que armazenam detalhes da configuração de ligação e segredos encriptam esses dados em repouso. O armazenamento e os controlos de acesso variam entre ligações APIs geridas e ligações integradas nos fluxos de trabalho Standard. Ligações que usam Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), como Office 365, Salesforce e GitHub, exigem que faça login, mas o Azure Logic Apps armazena tokens de acesso e atualização em vez de palavras-passe de login do utilizador.

As Azure Logic Apps podem atualizar tokens de acesso OAuth enquanto o token de atualização permanece válido e o serviço alvo permite o acesso. Os tokens de atualização podem expirar ou ser revogados, o que pode exigir reautorização. Alterações de credenciais também podem invalidar tokens, dependendo do fornecedor de identidade, do tipo de cliente e do fluxo de autenticação.

Nota

Se sua organização não permitir que você acesse recursos específicos por meio de conectores nos Aplicativos Lógicos do Azure, você poderá bloquear a capacidade de criar essas conexões usando a Política do Azure.

Para obter mais informações sobre como proteger fluxos de trabalho e conexões de aplicativos lógicos, consulte Acesso e dados seguros em Aplicativos Lógicos do Azure.

Acesso ao firewall para conexões

Se o seu ambiente usar um firewall, permita apenas o tráfego exigido pelos seus fluxos de trabalho e operações de conectores:

  • Para fluxos de trabalho do tipo Consumo que utilizam operações incorporadas, permita o tráfego de entrada do Azure Logic Apps quando os fluxos de trabalho recebem chamadas externas e o tráfego de saída quando os fluxos de trabalho invocam pontos finais externos. Utilize as etiquetas de serviço LogicAppsManagement e LogicApps onde forem suportadas.

  • Para operações geridas ou personalizadas de conectores, utilize a etiqueta de serviço AzureConnectors sempre que suportado. Caso contrário, permita os endereços IP de saída do conector gerido necessários para as regiões Azure aplicáveis.

  • Para fluxos de trabalho padrão, siga os requisitos de rede do Serviço de Aplicações do Azure e permita os nomes de domínio totalmente qualificados exigidos pelas ligações de conectores. Para mais informações, consulte permissões de firewall para fluxos de trabalho Standard.

Para obter mais informações, consulte Configuração do firewall.

Conectores e APIs personalizados

Em Fluxos de trabalho de consumo para Aplicativos Lógicos do Azure multilocatário, você pode chamar APIs baseadas em Swagger ou SOAP que não estão disponíveis como conectores prontos para uso. Você também pode executar código personalizado criando aplicativos de API personalizados. Para obter mais informações, veja a seguinte documentação:

Em fluxos de trabalho padrão para aplicativos lógicos do Azure de locatário único, você pode criar conectores internos personalizados baseados em provedor de serviços executados nativamente que estão disponíveis para qualquer fluxo de trabalho de aplicativo lógico padrão. Para obter mais informações, veja a seguinte documentação:

Próximos passos