Compartilhar via

O que são os conectores nos Aplicativos Lógicos do Azure

  • Artigo

Ao construir um fluxo de trabalho usando 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é-construídas, que você usa como etapas no 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 propriedades que você pode configurar. Embora muitos conectores tenham 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, uma versão 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 poder 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ê poderá enviar uma solicitação usando a operação HTTP genérica ou criar um conector personalizado.

Essa 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 integrados ou gerenciados. Alguns conectores possuem ambas as versões. As versões disponíveis dependem de você criar um fluxo de trabalho de aplicativo lógico de Consumo executado em aplicativos lógicos do Azure multilocatários 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, veja Tipos de recursos e diferenças de ambiente host.

  • Os conectores integrados foram projetados para serem executados direta e nativamente dentro dos Aplicativos Lógicos do Azure.

  • Os conectores gerenciados são implantados, hospedados e gerenciados no Azure pela Microsoft. Os conectores gerenciados fornecem principalmente 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.

    • Num fluxo de trabalho de Consumo, os conectores geridos aparecem no designer sob os rótulos Standard ou Enterprise, com base no seu nível de preços.

    • Num fluxo de trabalho Padrão, todos os conectores geridos aparecem no designer sob o rótulo Azure.

Para saber mais, confira a seguinte documentação:

Gatilhos

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 acionamento específico que controla como o gatilho monitora eventos e responde a eles. Normalmente, um gatilho segue um padrão polling ou um padrão push. Às vezes, ambas as versões do gatilho estão disponíveis.

  • Os gatilhos de sondagem verificam regularmente um serviço ou um sistema específico de acordo com um agendamento especificado para verificar se há novos dados ou um evento específico. Se há novos dados disponíveis ou o evento específico ocorre, esses gatilhos criam e executam uma instância do fluxo de trabalho. Em seguida, essa nova instância poderá usar os dados transmitidos como entrada.

    Observação

    Para conectores gerenciados pela Microsoft, hospedados e executados 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 de agendamento avançadas, como Nesses horários e Nesses dias. Essas opções funcionam apenas com gatilhos de sondagem incorporados que são executados diretamente com o tempo de execução das Aplicativos Lógicos do Azure, como os gatilhos Recurrence, Sliding Window e HTTP.

  • Os gatilhos Push ou webhook escutam novos dados ou a ocorrência de um evento, sem pesquisa. Quando há novos dados disponíveis ou o evento ocorre, esses gatilhos criam e executam uma nova instância do fluxo de trabalho. Em seguida, essa nova instância poderá usar os dados transmitidos como entrada.

Por exemplo, suponha que você queira criar um fluxo de trabalho que seja executado quando um arquivo for carregado em seu servidor FTP. Como primeira etapa em seu fluxo de trabalho, você pode adicionar o gatilho FTP denominado Quando um arquivo é adicionado ou modificado, que segue um padrão de pesquisa. Em seguida, você especifica a programação para verificar regularmente eventos de upload.

Quando o gatilho é acionado, ele geralmente passa as saídas do evento para ações subsequentes para referência e uso. Para o exemplo de FTP, o gatilho gera automaticamente informações como nome e caminho do arquivo. 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 nele. Por exemplo, você pode iniciar o fluxo de trabalho com um gatilho do SQL Server que verifica novos dados de clientes em um banco de dados SQL. Seguindo o gatilho, seu fluxo de trabalho pode ter uma ação do SQL Server que obtém os dados do cliente. Após esta ação do SQL Server, seu fluxo de trabalho pode usar uma ação diferente que processe os dados, por exemplo, uma ação de Operações de Dados que cria uma tabela CSV.

Permissões de conexão

Num fluxo de trabalho de aplicação lógica de Consumo, antes de poder criar ou gerir recursos de aplicações lógicas, fluxos de trabalho e 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 em Aplicativos Lógicos do Azure.

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

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, para que o fluxo de trabalho acesse sua conta de email do Office 365 Outlook e trabalhe com ela, você precisa autorizar uma conexão com essa conta. Em alguns conectores internos e conectores gerenciados, você pode configurar e usar uma identidade gerenciada para autenticação, em vez de fornecer suas credenciais.

Embora você crie conexões em um fluxo de trabalho, elas são, na verdade, recursos do Azure separados com definições de recurso próprias. Para revisar essas definições de recursos de conexão, siga estas etapas dependendo se você tem um fluxo de trabalho de Consumo ou Padrão:

Segurança e criptografia de conexão

Os detalhes de configuração de conexão, como endereço do servidor, nome de usuário e senha, credenciais e segredos, são criptografados e armazenados no ambiente seguro do Azure. Essas informações podem ser usadas somente em recursos do aplicativo lógico e por clientes que têm permissões para o recurso de conexão, que é imposta usando verificações de acesso vinculadas. As conexões que usam a autenticação aberta do Microsoft Entra ID (Microsoft Entra ID OAuth), como Office 365, Salesforce e GitHub, exigem que você entre, mas os Aplicativos Lógicos do Azure armazenam apenas tokens de acesso e atualização como segredos, e não credenciais de entrada.

As conexões estabelecidas podem acessar o serviço ou o sistema de destino pelo tempo que o serviço ou o sistema permitir. Para serviços que usam conexões OAuth do Microsoft Entra ID, como Office 365 e Dynamics, os Aplicativos Lógicos do Azure atualizam os tokens de acesso indefinidamente. Outros serviços podem ter limites de quanto tempo os Aplicativos Lógicos podem usar um token sem atualização. Algumas ações, como alterar a senha, invalidam todos os tokens de acesso.

Observação

Se a 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 o Azure Policy.

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

Acesso ao firewall para conexões

Se você usar um firewall que limite o tráfego e os fluxos de trabalho do aplicativo lógico precisarem se comunicar por meio desse firewall, configure o firewall para permitir o acesso aos endereços IP de entrada e saída usados pela plataforma de Aplicativos Lógicos do Azure ou pelo runtime na região do Azure em que se encontram os fluxos de trabalho do aplicativo lógico.

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

Conectores personalizados e APIs

Em fluxos de trabalho de Consumo para Aplicativos Lógicos do Azure multilocatários, você pode chamar APIs baseadas em Swagger ou baseadas em SOAP que não estão disponíveis como conectores prontos para uso. Você também pode executar um código personalizado criando Aplicativos de API personalizados. Para saber mais, confira a seguinte documentação:

Em fluxos de trabalho padrão para Aplicativos Lógicos do Azure de locatário único, você pode criar conectores integrados personalizados baseados em provedores de serviços em execução nativa que estão disponíveis para qualquer fluxo de trabalho de aplicativo lógico padrão. Para saber mais, confira a seguinte documentação:

ISE e conectores

Para os fluxos de trabalho que precisam ter acesso direto aos recursos em uma rede virtual do Azure, você pode criar um ISE (ambiente de serviço de integração) dedicado no qual pode criar, implantar e executar seus fluxos de trabalho em recursos dedicados. Para obter mais informações sobre como criar ISEs, confira Conectar-se a redes virtuais do Azure nos Aplicativos Lógicos do Azure.

Os conectores personalizados criados dentro de um ISE não funcionam com o gateway de dados local. No entanto, esses conectores podem acessar diretamente as fontes de dados locais conectadas a uma rede virtual do Azure que hospeda o ISE. Assim, os fluxos de trabalho de aplicações lógicas num ISE provavelmente não precisam do gateway de dados ao comunicar com esses recursos. Se você tiver conectores personalizados criados fora de um ISE que exigem o gateway de dados local, os fluxos de trabalho em um ISE poderão usar esses conectores.

No designer de fluxo de trabalho, quando você navega pelos conectores integrados ou gerenciados que deseja usar para fluxos de trabalho em um ISE, o rótulo CORE aparece nos conectores integrados, enquanto o rótulo ISE aparece nos conectores gerenciados projetados para funcionar com um ISE.

Exemplo de conector do CORE

CORE

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

Exemplo de conector do ISE

ISE

Os conectores gerenciados com esse rótulo são executados no mesmo ISE que seus fluxos de trabalho.

Se você tiver um sistema local conectado a uma rede virtual do Azure, um ISE permitirá que seus fluxos de trabalho acessem diretamente esse sistema sem usar o gateway de dados local. Em vez disso, você pode usar o conector de ISE do sistema, se disponível, uma ação HTTP ou um conector personalizado.

Em sistemas locais que não têm conectores do ISE, use o gateway de dados local. Para encontrar os conectores do ISE disponíveis, examine Conectores do ISE.

Exemplo de conector não ISE

Sem rótulo

Todos os outros conectores sem rótulo, que você pode continuar usando, são executados no serviço de Aplicativos Lógicos multilocatário global.

Problemas conhecidos

A tabela a seguir inclui problemas conhecidos para conectores em Aplicativos Lógicos do Azure:

Mensagem de erro Descrição Resolução
Error: BadGateway. Client request id: '{GUID}' Esse erro resulta da atualização das tags num recurso de aplicação lógica onde uma ou mais ligações não suportam a autenticação OAuth do Microsoft Entra ID, como o anúncio SFTP SQL, quebrando essas ligações. Para impedir esse comportamento, evite atualizar essas marcas.

Próximas etapas

Criar um fluxo de trabalho de aplicativo lógico de Consumo - portal do Azure

Criar um fluxo de trabalho de aplicativo lógico padrão - portal do Azure