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

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, 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 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ê poderá enviar uma solicitação usando a operação HTTP genérica ou poderá 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 conectores, consulte a seguinte documentação:

Conectores internos versus conectores gerenciados

Nos Aplicativos Lógicos do Azure, os conectores são internos ou gerenciados. Alguns conectores têm as duas versões. As versões disponíveis dependem se você cria um fluxo de trabalho de aplicativo lógico de consumo que é 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 aplicativo lógico, 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.

  • 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.

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

    • Em um fluxo de trabalho Padrão, todos os conectores gerenciados aparecem no designer sob o rótulo do Azure .

Para obter mais informações, consulte 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 de sondagem ou um padrão de push. Às vezes, ambas as versões de 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.

  • Os gatilhos push ou webhook escutam novos dados ou um evento acontecer, sem sondagem. 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 é 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 a agenda para verificar regularmente se há eventos de carregamento.

Quando o gatilho é acionado, o gatilho geralmente passa saídas de eventos para ações subsequentes a serem referenciadas e usadas. Para o exemplo de FTP, o gatilho gera 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 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. 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 conexão

Em um fluxo de trabalho de aplicativo lógico de consumo, antes de criar ou gerenciar recursos de aplicativo lógico, fluxos de trabalho e suas conexões, você precisa de permissões específicas. Para obter mais informações sobre essas permissões, consulte Operações seguras - Acesso seguro e dados em Aplicativos Lógicos do Azure.

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

Antes de 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 com base em se você tem um fluxo de trabalho 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 da ID do Microsoft Entra (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, 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 de ID do Microsoft Entra, como o Office 365 e o 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, consulte 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 seus fluxos de trabalho também usarem conectores gerenciados, como o conector do Office 365 Outlook ou o conector SQL, ou usarem conectores personalizados, seu firewall também precisará permitir o acesso a todos os endereços IP de saída do conector gerenciado na região do Azure do recurso de aplicativo lógico. Para obter mais informações, consulte Configuração de firewall.

Conectores personalizados e APIs

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 um código personalizado criando Aplicativos de API personalizados. Para obter mais informações, consulte 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 em execução nativa que estão disponíveis para qualquer fluxo de trabalho de aplicativo lógico padrão. Para obter mais informações, consulte 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. Portanto, os fluxos de trabalho de aplicativos lógicos em um ISE provavelmente não precisam do gateway de dados ao se comunicar com esses recursos. Se você tiver conectores personalizados criados fora de um ISE que exijam 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ê procura os conectores internos ou gerenciados que deseja usar para fluxos de trabalho em um ISE, o rótulo CORE aparece em conectores internos, enquanto o rótulo ISE aparece em conectores gerenciados projetados para funcionar com um ISE.

Example CORE connector

CORE

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

Example ISE connector

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.

Example non-ISE connector

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 marcas em um recurso de aplicativo lógico em que uma ou mais conexões não oferecem suporte à autenticação OAuth do Microsoft Entra ID, como SFTP ad SQL, interrompendo essas conexões. Para impedir esse comportamento, evite atualizar essas marcas.

Próximas etapas