Sobre conectores em Azure Logic Apps

Ao construir fluxos de trabalho utilizando Azure Logic Apps, pode utilizar conectores para o ajudar a aceder de forma rápida e fácil a dados, eventos e recursos em outras apps, serviços, sistemas, protocolos e plataformas - muitas vezes sem escrever nenhum código. Um conector fornece operações pré-construídas que pode usar como passos nos seus fluxos de trabalho. Azure Logic Apps fornece centenas de conectores que pode usar. Se não houver nenhum conector disponível para o recurso a que pretende aceder, pode utilizar a operação genérica HTTP para comunicar com o serviço, ou pode criar um conector personalizado.

Esta visão geral oferece uma introdução aos conectores, como geralmente funcionam, e os conectores mais populares e comumente usados em Azure Logic Apps. Para mais informações, reveja a seguinte documentação:

O que são conectores?

Tecnicamente, um conector é um proxy ou um invólucro em torno de uma API que o serviço subjacente utiliza para comunicar com Azure Logic Apps. Este conector fornece operações que utiliza nos seus fluxos de trabalho para executar tarefas. Uma operação está disponível como gatilho ou ação com propriedades que pode configurar. Alguns gatilhos e ações também requerem que crie e configure uma ligação ao serviço ou sistema subjacente, por exemplo, para que possa autenticar o acesso a uma conta de utilizador.

Acionadores

Um gatilho especifica o evento que inicia o fluxo de trabalho e é sempre o primeiro passo em qualquer fluxo de trabalho. Cada gatilho também segue um padrão de disparo específico que controla a forma como o gatilho monitoriza e responde aos eventos. Normalmente, um gatilho segue o padrão de sondagem ou o padrão de impulso, mas às vezes, um gatilho está disponível em ambas as versões.

  • Os acionadores de sondagens verificam regularmente um serviço ou sistema específico num horário especificado para verificar se há novos dados ou um evento específico. Se novos dados estiverem disponíveis, ou o evento específico acontecer, estes gatilhos criam e executam uma nova instância do seu fluxo de trabalho. Este novo caso pode então usar os dados que são passados como entrada.
  • Os gatilhos de pressão ouvem novos dados ou para que um evento aconteça, sem sondagens. Quando novos dados estão disponíveis, ou quando o evento acontece, estes gatilhos criam e executam uma nova instância do seu fluxo de trabalho. Este novo caso pode então usar os dados que são passados como entrada.

Por exemplo, é melhor construir um fluxo de trabalho que faça algo quando um ficheiro é enviado para o seu servidor FTP. Como primeiro passo no seu fluxo de trabalho, pode utilizar o gatilho FTP denominado Quando um ficheiro é adicionado ou modificado, que segue o padrão de votação. Em seguida, pode especificar um horário para verificar regularmente se há eventos de upload.

Um gatilho também transmite quaisquer entradas e outros dados necessários para o seu fluxo de trabalho, onde as ações posteriores podem referenciar e usar esses dados ao longo do fluxo de trabalho. Por exemplo, suponha que queira usar Office 365 Outlook gatilho chamado Quando um novo e-mail chega para iniciar um fluxo de trabalho quando recebe um novo e-mail. Pode configurar este gatilho para transmitir o conteúdo de cada novo e-mail, como o remetente, linha de assunto, corpo, anexos, e assim por diante. O seu fluxo de trabalho pode então processar essa informação utilizando outras ações.

Ações

Uma ação é uma operação que segue o gatilho e executa algum tipo de tarefa no seu fluxo de trabalho. Pode utilizar várias ações no seu fluxo de trabalho. Por exemplo, pode iniciar o fluxo de trabalho com um gatilho SQL que deteta novos dados do cliente numa base de dados SQL. Seguindo o gatilho, o seu fluxo de trabalho pode ter uma ação SQL que obtém os dados do cliente. Após a ação SQL, o seu fluxo de trabalho pode ter outra ação, não necessariamente SQL, que processa os dados.

Categorias de conector

Nas Aplicações Lógicas, a maioria dos gatilhos e ações estão disponíveis numa versão incorporada ou numa versão de conector gerida. Em ambas as versões estão disponíveis alguns gatilhos e ações. As versões disponíveis dependem se você cria uma app lógica multi-inquilino ou uma app lógica de inquilino único, que atualmente está disponível apenas em Azure Logic Apps de inquilino único.

Os gatilhos e ações incorporados são executados de forma nativa no tempo de execução das Aplicações Lógicas, não requerem a criação de ligações e executam este tipo de tarefas:

Os conectores geridos são implantados, hospedados e geridos pela Microsoft. Estes conectores fornecem gatilhos e ações para serviços na nuvem, sistemas no local, ou ambos. Os conectores geridos estão disponíveis nestas categorias:

Configuração de ligação

A maioria dos conectores requer que crie primeiro uma ligação ao serviço ou sistema alvo antes de poder utilizar os seus gatilhos ou ações no seu fluxo de trabalho. Para criar uma ligação, tem de autenticar a sua identidade com credenciais de conta e, por vezes, outras informações de ligação. Por exemplo, antes de o seu fluxo de trabalho poder aceder e trabalhar com a sua conta de e-mail Office 365 Outlook, tem de autorizar uma ligação a essa conta.

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

Para conectores que utilizem Azure Ative Directory OAuth (Azure AD), como Office 365, Salesforce ou GitHub, deve entrar no serviço onde o seu token de acesso é encriptado e armazenado de forma segura num segredo de Azure. Outros conectores, como FTP e SQL, requerem uma ligação que tenha detalhes de configuração, tais como o endereço do servidor, nome de utilizador e senha. Estes detalhes de configuração de ligação também são encriptados e armazenados de forma segura no Azure.

As ligações estabelecidas podem aceder ao serviço ou sistema alvo enquanto esse serviço ou sistema permitir. Para serviços que utilizam ligações Azure AD OAuth, como Office 365 e Dynamics, o serviço De Aplicações Lógicas atualiza o acesso a tokens indefinidamente. Outros serviços podem ter limites em quanto tempo as Aplicações Lógicas podem usar um token sem refrescar. Algumas ações, como alterar a sua palavra-passe, invalidam todos os tokens de acesso.

Embora crie ligações a partir de um fluxo de trabalho, as ligações são recursos Azure separados com as suas próprias definições de recursos. Para rever estas definições de recursos de conexão, baixe a sua aplicação lógica do Azure para Visual Studio. Este método é a maneira mais fácil de criar um modelo de aplicação lógica válida e parametrizada que está maioritariamente pronto para ser implantado.

Dica

Se a sua organização não permitir o acesso a recursos específicos através de conectores Logic Apps, pode bloquear a capacidade de criar tais ligações utilizando a Azure Policy.

Acesso à firewall para ligações

Se utilizar uma firewall que limite o tráfego e os fluxos de trabalho das suas aplicações lógicas precisarem de comunicar através dessa firewall, tem de configurar a sua firewall para permitir o acesso aos endereços IP de entrada e saída utilizados pelo serviço De aplicações lógicas ou tempo de funcionamento na região de Azure, onde existem fluxos de trabalho de aplicações lógicas. Se os seus fluxos de trabalho também utilizarem conectores geridos, como o conector Office 365 Outlook ou o conector SQL, ou utilizar conectores personalizados, a sua firewall também precisa de permitir o acesso a todos os endereços IP de saída de conector geridos na região Azure da sua aplicação lógica. Para obter mais informações, reveja a configuração do Firewall.

Comportamento de recorrência

Os gatilhos incorporados recorrentes, como o gatilho Recorrence,funcionam de forma nativa no tempo de funcionamento das Aplicações Lógicas e diferem dos gatilhos baseados em ligação recorrentes, como o gatilho do conector Office 365 Outlook onde é necessário criar uma ligação primeiro.

Para ambos os tipos de gatilhos, se uma recorrência não especificar uma data e hora de início específicas, a primeira recorrência corre imediatamente quando guarda ou implementa a aplicação lógica, apesar da configuração de recorrência do gatilho. Para evitar este comportamento, forneça uma data de início e hora para quando quiser que a primeira recorrência seja executada.

Recorrência para gatilhos incorporados

Os gatilhos incorporados recorrentes seguem o horário que definiu, incluindo qualquer fuso horário especificado. No entanto, se uma recorrência não especificar outras opções avançadas de agendamento, tais como tempos específicos para executar recorrências futuras, essas recorrências são baseadas na última execução do gatilho. Como resultado, os tempos de início para essas recorrências podem derivar devido a fatores como a latência durante as chamadas de armazenamento.

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

Recorrência para gatilhos baseados em ligação

Em gatilhos de ligação recorrentes, como Office 365 Outlook, o horário não é o único condutor que controla a execução. O fuso horário apenas determina a hora de início inicial. As execuções subsequentes dependem do calendário de recorrência, da última execução do gatilho, e de outros fatores que podem causar tempos de fuga ou produzir comportamentos inesperados, por exemplo:

  • Se o gatilho acede a um servidor que tem mais dados, que o gatilho tenta imediatamente obter.
  • Quaisquer falhas ou retrações que o gatilho incorre.
  • Latência durante as chamadas de armazenamento.
  • Não mantendo o horário especificado quando o horário de verão (DST) começar e terminar.
  • Outros fatores que podem afetar quando a próxima hora de execução acontece.

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

Problemas de recorrência na resolução de problemas

Para se certificar de que o seu fluxo de trabalho funciona na hora de início especificada e não perde uma recorrência, especialmente quando a frequência é em dias ou mais, experimente as seguintes soluções:

  • Quando o DST fizer efeito, ajuste manualmente a recorrência de modo a que o seu fluxo de trabalho continue a funcionar no momento esperado. Caso contrário, a hora de início muda uma hora para a frente quando o DST começa e uma hora para trás quando o DST termina. Para obter mais informações e exemplos, reveja a recorrência para horário de verão e horário normal.

  • Se estiver a usar um gatilho de recorrência, especifique um fuso horário, uma data de início e hora de início. Além disso, configurar horários específicos para executar recorrências subsequentes nas propriedades Nestas horas e nestas atas, que estão disponíveis apenas para as frequências Dia e Semana. No entanto, algumas janelas de tempo ainda podem causar problemas quando a hora muda.

  • Considere usar um gatilho da janela deslizante em vez de um gatilho de recorrência para evitar recorrências perdidas.

APIs e conectores personalizados

Para chamar APIs que executam código personalizado ou não estão disponíveis como conectores, você pode estender a plataforma De Aplicações Lógicas criando aplicações API personalizadas. Também pode criar conectores personalizados para quaisquer APIs baseadas em REST ou SOAP, que disponibilizam essas APIs a qualquer aplicação lógica na sua subscrição Azure. Para tornar públicas as aplicações ou conectores API personalizados para qualquer pessoa utilizar no Azure, pode submeter conectores para certificação microsoft.

ISE e conectores

Para fluxos de trabalho que necessitem de acesso direto aos recursos numa rede virtual Azure, pode criar um ambiente de serviço de integração dedicado (ISE) onde pode construir, implantar e executar os seus fluxos de trabalho em recursos dedicados. Para obter mais informações sobre a criação de ISEs, consulte Ligação para redes virtuais Azure a partir de Azure Logic Apps.

Os conectores personalizados criados dentro de um ISE não funcionam com o portal de dados no local. No entanto, estes conectores podem aceder diretamente a fontes de dados no local que estão ligadas a uma rede virtual Azure que hospeda o ISE. Assim, as aplicações lógicas num ISE provavelmente não precisam da porta de dados quando comunicam com esses recursos. Se tiver conectores personalizados que criou fora de um ISE que requerem o gateway de dados no local, as aplicações lógicas num ISE podem usar esses conectores.

No Logic Apps Designer, quando navega nos gatilhos e ações incorporados ou nos conectores geridos que pretende utilizar para aplicações lógicas num ISE, a etiqueta CORE aparece em gatilhos e ações incorporados, enquanto a etiqueta ISE aparece em conectores geridos que são projetados para trabalhar com um ISE.

Conector CORE exemplo

CORE

Os gatilhos incorporados e as ações com esta etiqueta funcionam no mesmo ISE que as suas aplicações lógicas.

Conector ISE exemplo

ISE

Os conectores geridos com esta etiqueta funcionam no mesmo ISE que as suas aplicações lógicas.

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

Para sistemas no local que não possuam conectores ISE, utilize o portal de dados no local. Para encontrar conectores ISE disponíveis, reveja os conectores ISE.

Conector não ISE

Sem rótulo

Todos os outros conectores sem etiqueta, que pode continuar a usar, funcionam no serviço global de Aplicações Lógicas multi-arrendatários.

Problemas conhecidos

A tabela seguinte inclui problemas conhecidos para conectores de Apps Lógicas.

Mensagem de erro Description Resolução
Error: BadGateway. Client request id: '{GUID}' Este erro resulta da atualização das tags numa aplicação lógica onde uma ou mais ligações não suportam a autenticação OAuth do Azure Ative Directory (Azure AD), como SQL de anúncios SFTP, quebrando essas ligações. Para evitar este comportamento, evite atualizar essas etiquetas.

Passos seguintes