Conectores personalizados em Azure Logic Apps

Aplica-se a: Azure Logic Apps (Consumo + Standard)

Sem escrever nenhum código, pode criar rapidamente fluxos de trabalho de integração automatizados quando utiliza as operações de conector pré-construídas em Azure Logic Apps. Um conector ajuda os seus fluxos de trabalho a conectar e aceder a dados, eventos e ações através de outras aplicações, serviços, sistemas, protocolos e plataformas. Cada conector oferece operações como gatilhos, ações ou ambos que pode adicionar aos seus fluxos de trabalho. Ao utilizar estas operações, expande as capacidades para as suas aplicações em nuvem e aplicações no local para trabalhar com dados novos e existentes.

Os conectores em Azure Logic Apps são incorporados ou geridos. Um conector incorporado funciona de forma nativa no tempo de funcionamento das Apps Azure Logic, o que significa que estão hospedados no mesmo processo que o tempo de execução e fornecem maior produção, baixa latência e conectividade local. Um conector gerido é um proxy ou um invólucro em torno de uma API, como Office 365 ou Salesforce, que ajuda o serviço subjacente a falar com Azure Logic Apps. Os conectores geridos são alimentados pela infraestrutura do conector em Azure e são implantados, hospedados, executados e geridos pela Microsoft. Pode escolher entre centenas de conectores geridos para utilizar com os seus fluxos de trabalho em Azure Logic Apps.

Quando se utiliza uma operação de conector pela primeira vez num fluxo de trabalho, alguns conectores não requerem que crie uma ligação primeiro, mas muitos outros conectores requerem este passo. Cada ligação que cria é na verdade um recurso Azure separado que fornece acesso à aplicação-alvo, serviço, sistema, protocolo ou plataforma.

Por vezes, porém, é melhor chamar APIs de REST que não estão disponíveis como conectores pré-construídos. Para suportar cenários mais personalizados, pode criar os seus próprios conectores personalizados para oferecer gatilhos e ações que não estão disponíveis como operações pré-construídas.

Este artigo fornece uma visão geral sobre conectores personalizados para consumo de fluxos de trabalho de aplicações lógicas e fluxos de trabalho de aplicações lógica padrão. Cada tipo de aplicação lógica é alimentado por um tempo de execução Azure Logic Apps diferente, respectivamente hospedado em Azure multi-inquilino e único inquilino Azure. Para obter mais informações sobre conectores em Azure Logic Apps, reveja a seguinte documentação:

Aplicativos de lógica de consumo

Em aplicativos lógicos Azure, pode criar conectores personalizados a partir de APIs baseados em Swagger ou baseados em SOAP até limites específicos para uso em fluxos de trabalho de aplicações lógicas de consumo. A documentação dos Connectors fornece informações mais completas sobre como criar conectores personalizados para aplicações lógicas de consumo, incluindo tutoriais básicos e avançados completos. A lista a seguir também fornece links diretos para informações sobre conectores personalizados para aplicações lógicas de consumo:

Aplicativos lógicos padrão

Em single-tenant Azure Logic Apps, o redesenhado Azure Logic Apps gere o tempo de funcionamento standard logic appflows. Este tempo de funcionamento difere do tempo de funcionamento do multi-inquilino Azure Logic Apps que alimenta os fluxos de trabalho de aplicações lógicas de consumo. O tempo de execução do único inquilino utiliza o modelo de extensibilidade Funções do Azure, que fornece uma capacidade chave para criar os seus próprios conectores incorporados para qualquer pessoa usar em fluxos de trabalho standard. Na maioria dos casos, a versão incorporada proporciona um melhor desempenho, capacidades, preços, e assim por diante.

Quando o único inquilino Azure Logic Apps foi lançado oficialmente, novos conectores incorporados incluíam Armazenamento de Blobs do Azure, Hubs de Eventos do Azure, Azure Service Bus e SQL Server. Com o tempo, esta lista de conectores incorporados continua a crescer. No entanto, se precisar de conectores que não estejam disponíveis nos fluxos de trabalho de aplicações lógicas Standard, pode criar os seus próprios conectores incorporados utilizando o mesmo modelo de extensibilidade que é utilizado por conectores incorporados baseados em prestadores de serviços em fluxos de trabalho Standard.

Conectores incorporados baseados no prestador de serviços

Nas Aplicações Lógicas Azure, um conector incorporado com atributos específicos é informalmente conhecido como um prestador de serviços. Por exemplo, estes conectores baseiam-se no modelo de extensibilidade Funções do Azure, que fornece a capacidade para criar os seus próprios conectores incorporados personalizados para utilizar em fluxos de trabalho de aplicações lógicas Standard.

Em contrapartida, os conectores incorporados não prestadores de serviços têm os seguintes atributos:

  • Não é baseado no modelo de extensibilidade Funções do Azure.

  • É implementado diretamente como um trabalho dentro do tempo de funcionamento das Apps Azure Logic, tais como Agenda, HTTP, Request e XML operações.

Nenhuma capacidade está atualmente disponível para criar um conector incorporado não-prestador de serviços ou um novo tipo de trabalho que funciona diretamente no tempo de execução das Apps Azure Logic. No entanto, pode criar os seus próprios conectores incorporados utilizando a infraestrutura do prestador de serviços.

A secção seguinte fornece mais informações sobre como o modelo de extensibilidade funciona para conectores incorporados personalizados.

Modelo de extensibilidade do conector incorporado

Com base no modelo de extensibilidade Funções do Azure, o modelo de extensibilidade do conector incorporado no Azure Logic Apps tem uma infraestrutura de prestador de serviços que pode utilizar para criar, embalar, registar e instalar os seus próprios conectores incorporados como extensões Funções do Azure que qualquer um pode usar nos seus fluxos de trabalho Standard. Este modelo inclui capacidades personalizadas de gatilho incorporado que suportam expor um gatilho ou ação Funções do Azure como um gatilho de prestador de serviços no seu conector incorporado personalizado.

O diagrama a seguir mostra as implementações do método que o designer e runtime da Azure Logic Apps espera para um conector personalizado incorporado com um gatilho baseado em Funções do Azure:

Diagrama conceptual mostrando infraestrutura de prestador de serviços baseada em Funções do Azure.

As secções seguintes fornecem mais informações sobre as interfaces que o seu conector precisa de implementar.

IServiceOperationsProvider

Esta interface inclui os métodos que fornecem o manifesto de operações para o seu conector personalizado incorporado.

  • Manifesto de operações

    O manifesto de operações inclui metadados sobre as operações implementadas no seu conector personalizado incorporado. O designer da Azure Logic Apps utiliza principalmente estes metadados para impulsionar as experiências de autoria e monitorização para as operações do seu conector. Por exemplo, o designer utiliza metadados de operação para entender os parâmetros de entrada exigidos por uma operação específica e para facilitar a geração de fichas de propriedade das saídas, com base no esquema para as saídas da operação.

    O designer requer e utiliza os métodos GetService e GetOperations() para consultar as operações que o seu conector fornece e mostra na superfície do designer. O método GetService também especifica os parâmetros de entrada da ligação que são exigidos pelo designer.

    Para obter mais informações sobre estes métodos e a sua implementação, reveja os Métodos para implementar a secção mais tarde neste artigo.

  • Invocações de operação

    As invocações de operação são as implementações do método utilizadas durante a execução do fluxo de trabalho pelo tempo de funcionamento das Apps Azure Logic para chamar as operações especificadas na definição de fluxo de trabalho.

    • Se o seu gatilho for um tipo de gatilho baseado em Funções do Azure, o método GetBindingConnectionInformation() é utilizado pelo tempo de execução em Azure Logic Apps para fornecer as informações de parâmetros de ligação necessárias à ligação do gatilho Funções do Azure.

    • Se o seu conector tiver ações, o método InvokeOperation() é utilizado pelo tempo de execução para ligar cada ação no seu conector que funciona durante a execução do fluxo de trabalho. Caso contrário, não terás de implementar este método.

Para obter mais informações sobre estes métodos e a sua implementação, reveja os Métodos para implementar a secção mais tarde neste artigo.

IServiceOperationsTriggerProvider

Suporte personalizado de capacidades de gatilho incorporado adicionando ou expondo um gatilho ou ação Funções do Azure como um gatilho de um fornecedor de serviços no seu conector incorporado personalizado. Para utilizar o tipo de gatilho baseado em Funções do Azure e a mesma ligação Funções do Azure que o gatilho do conector gerido Azure, implemente os seguintes métodos para fornecer as informações de ligação e acionar as ligações conforme exigido por Funções do Azure.

  • O método GetFunctionTriggerType() é necessário para devolver a cadeia que é a mesma do parâmetro do tipo no Funções do Azure a ligação do gatilho.

  • O GetFunctionTriggerDefinition() tem uma implementação padrão, por isso não precisa de implementar explicitamente este método. No entanto, se pretender atualizar o comportamento padrão do gatilho, como fornecer parâmetros extra que o designer não expõe, pode implementar este método e anular o comportamento padrão.

Métodos para implementar

As seguintes secções fornecem mais informações sobre os métodos que o seu conector precisa de implementar. Para a amostra completa, reveja a Sample CosmosDbServiceOperationProvider.cs e Crie conectores personalizados incorporados para aplicações lógicas standard em apps lógicas Azure Logic.

GetService()

O designer requer este método para obter os metadados de alto nível para o seu serviço, incluindo a descrição do serviço, parâmetros de entrada de ligação, capacidades, cor da marca, URL do ícone, e assim por diante.

public ServiceOperationApi GetService()
{
   return this.{custom-service-name-apis}.ServiceOperationServiceApi();
}

Para mais informações, reveja a Sample CosmosDbServiceOperationProvider.cs.

GetOperations()

O designer requer este método para que as operações seja implementada pelo seu serviço. A lista de operações baseia-se no esquema do Swagger. O designer também usa os metadados de operação para entender os parâmetros de entrada para operações específicas e gerar as saídas como fichas de propriedade, com base no esquema da saída para uma operação.

public IEnumerable<ServiceOperation> GetOperations(bool expandManifest)
{
   return expandManifest ? serviceOperationsList : GetApiOperations();
}

Para mais informações, reveja a Sample CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Se pretender utilizar o tipo de gatilho baseado em Funções do Azure, este método fornece as informações necessárias sobre os parâmetros de ligação à ligação do gatilho Funções do Azure.

public string GetBindingConnectionInformation(string operationId, InsensitiveDictionary<JToken> connectionParameters)
{
   return ServiceOperationsProviderUtilities
      .GetRequiredParameterValue(
         serviceId: ServiceId,
         operationId: operationID,
         parameterName: "connectionString",
         parameters: connectionParameters)?
      .ToValue<string>();
}

Para mais informações, reveja a Sample CosmosDbServiceOperationProvider.cs.

InvocaçãoOperação()

Se o seu conector personalizado incorporado tiver apenas um gatilho, não tem de implementar este método. No entanto, se o seu conector tiver ações para implementar, tem de implementar o método InvokeOperation() que é solicitado para cada ação no seu conector que funciona durante a execução do fluxo de trabalho. Pode utilizar qualquer cliente, como FTPClient, HTTPClient, e assim por diante, conforme exigido pelas ações do seu conector. Este exemplo utiliza HTTPClient.

public Task<ServiceOperationResponse> InvokeOperation(string operationId, InsensitiveDictionary<JToken> connectionParameters, ServiceOperationRequest serviceOperationRequest)
{
   using (var client = new HttpClient())
   {
      response = client.SendAsync(httpRequestMessage).ConfigureAwait(false).ToJObject();
   }
   return new ServiceOperationResponse(body: response);
}

Para mais informações, reveja a Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Para utilizar um gatilho baseado em Funções do Azure como gatilho no seu conector, tem de devolver a corda que é igual ao parâmetro do tipo no Funções do Azure acionamento.

O exemplo a seguir devolve a corda para o gatilho DB Azure Cosmos incorporado fora da caixa: "type": "cosmosDBTrigger"

public string GetFunctionTriggerType()
{
   return "CosmosDBTrigger";
}

Para mais informações, reveja a Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Este método tem uma implementação padrão, por isso não precisa implementar explicitamente este método. No entanto, se pretender atualizar o comportamento padrão do gatilho, como fornecer parâmetros extra que o designer não expõe, pode implementar este método e anular o comportamento padrão.

Passos seguintes

Quando estiver pronto para iniciar as etapas de implementação, continue ao seguinte artigo: