Conectores personalizados nos Aplicativos Lógicos do Azure

Aplica-se a: Aplicativos Lógicos do Azure (Consumo + Padrão)

Sem escrever nenhum código, você pode criar rapidamente fluxos de trabalho de integração automatizados ao usar as operações de conector pré-criadas nos Aplicativos Lógicos do Azure. Um conector ajuda seus fluxos de trabalho a conectar e acessar dados, eventos e ações em outros aplicativos, serviços, sistemas, protocolos e plataformas. Cada conector oferece operações como gatilhos, ações ou ambos que você pode adicionar aos seus fluxos de trabalho. Ao usar essas operações, você expande os recursos de seus aplicativos na nuvem e aplicativos locais para trabalhar com dados novos e existentes.

Os conectores nos Aplicativos Lógicos do Azure são internos ou gerenciados. Um conector interno é executado nativamente no tempo de execução dos Aplicativos Lógicos do Azure, o que significa que eles são hospedados no mesmo processo que o tempo de execução e fornecem maior taxa de transferência, baixa latência e conectividade local. Um conector gerenciado é um proxy ou um wrapper em torno de uma API, como o Office 365 ou o Salesforce, que ajuda o serviço subjacente a conversar com os Aplicativos Lógicos do Azure. Os conectores gerenciados são alimentados pela infraestrutura de conector no Azure e são implantados, hospedados, executados e gerenciados pela Microsoft. Você pode escolher entre centenas de conectores gerenciados para usar com seus fluxos de trabalho nos Aplicativos Lógicos do Azure.

Quando você usa uma operação de conector pela primeira vez em um fluxo de trabalho, alguns conectores não exigem que você crie uma conexão primeiro, mas muitos outros conectores exigem essa etapa. Cada conexão que você cria é, na verdade, um recurso do Azure separado que fornece acesso ao aplicativo, serviço, sistema, protocolo ou plataforma de destino.

Às vezes, porém, você pode querer chamar APIs REST que não estão disponíveis como conectores pré-criados. Para oferecer suporte a cenários mais personalizados, você pode criar seus próprios conectores personalizados para oferecer gatilhos e ações que não estão disponíveis como operações pré-criadas.

Este artigo fornece uma visão geral sobre conectores personalizados para fluxos de trabalho de aplicativos lógicos de consumo e fluxos de trabalho de aplicativos lógicos padrão. Cada tipo de aplicativo lógico é alimentado por um tempo de execução diferente dos Aplicativos Lógicos do Azure, hospedados respectivamente no Azure multilocatário e no Azure de locatário único. Para obter mais informações sobre conectores nos Aplicativos Lógicos do Azure, revise a seguinte documentação:

• Sobre conectores nos Aplicativos Lógicos do Azure
• Conectores internos nos Aplicativos Lógicos do Azure
• Conectores gerenciados em Aplicativos Lógicos do Azure
• Descrição geral dos conectores
• Locatário único versus multilocatário nos Aplicativos Lógicos do Azure

Aplicativos de lógica de consumo

Nos Aplicativos Lógicos do Azure multilocatário, você pode criar conectores personalizados a partir de APIs baseadas em Swagger ou SOAP até limites específicos para uso em fluxos de trabalho de aplicativos lógicos de consumo. A documentação Conectores fornece mais informações gerais sobre como criar conectores personalizados para aplicativos lógicos 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 aplicativos lógicos de consumo:

• Criar um conector de Aplicativos Lógicos do Azure
• Criar um conector personalizado a partir de uma definição de OpenAPI
• Utilizar um conector personalizado a partir de uma aplicação lógica
• Partilhar conectores personalizados na sua organização
• Submeter conectores à certificação da Microsoft
• FAQ do conector personalizado

Aplicativos lógicos padrão

Nos Aplicativos Lógicos do Azure de locatário único, o tempo de execução dos Aplicativos Lógicos do Azure redesenhado potencializa os fluxos de trabalho do aplicativo lógico Padrão. Esse tempo de execução difere do tempo de execução multilocatário dos Aplicativos Lógicos do Azure que alimenta os fluxos de trabalho do aplicativo lógico de consumo. O tempo de execução de locatário único usa o modelo de extensibilidade do Azure Functions, que fornece um recurso fundamental para você criar seus próprios conectores internos para qualquer pessoa usar em fluxos de trabalho Padrão. Na maioria dos casos, a versão integrada oferece melhor desempenho, recursos, preços e assim por diante.

Quando os Aplicativos Lógicos do Azure de locatário único foram lançados oficialmente, os novos conectores internos incluíam o Armazenamento de Blobs do Azure, os Hubs de Eventos do Azure, o Barramento de Serviço do Azure e o SQL Server. Com o tempo, esta lista de conectores integrados continua a crescer. No entanto, se você precisar de conectores que não estão disponíveis em fluxos de trabalho de aplicativos lógicos padrão, poderá criar seus próprios conectores internos usando o mesmo modelo de extensibilidade usado por conectores internos baseados em provedores de serviços em fluxos de trabalho padrão.

Conectores integrados baseados em provedor de serviços

Nos Aplicativos Lógicos do Azure de locatário único, um conector interno com atributos específicos é conhecido informalmente como um provedor de serviços. Por exemplo, esses conectores são baseados no modelo de extensibilidade do Azure Functions, que fornece a capacidade de você criar seus próprios conectores internos personalizados para usar em fluxos de trabalho de aplicativos lógicos padrão.

Por outro lado, os conectores internos que não são provedores de serviços têm os seguintes atributos:

• Não se baseia no modelo de extensibilidade do Azure Functions.

• É implementado diretamente como um trabalho dentro do tempo de execução dos Aplicativos Lógicos do Azure, como operações Schedule, HTTP, Request e XML.

Nenhum recurso está disponível no momento para criar um conector interno que não seja um provedor de serviços ou um novo tipo de trabalho que seja executado diretamente no tempo de execução dos Aplicativos Lógicos do Azure. No entanto, você pode criar seus próprios conectores internos usando a infraestrutura do provedor de serviços.

A seção a seguir fornece mais informações sobre como o modelo de extensibilidade funciona para conectores internos personalizados.

Modelo de extensibilidade de conector integrado

Com base no modelo de extensibilidade do Azure Functions, o modelo de extensibilidade de conector interno nos Aplicativos Lógicos do Azure de locatário único tem uma infraestrutura de provedor de serviços que você pode usar para criar, empacotar, registrar e instalar seus próprios conectores internos como extensões do Azure Functions que qualquer pessoa pode usar em seus fluxos de trabalho Padrão. Esse modelo inclui recursos de gatilho internos personalizados que dão suporte à exposição de um gatilho ou ação do Azure Functions como um gatilho de provedor de serviços em seu conector interno personalizado.

O diagrama a seguir mostra as implementações de método que o designer e o tempo de execução dos Aplicativos Lógicos do Azure esperam para um conector interno personalizado com um gatilho baseado no Azure Functions:

As seções a seguir fornecem mais informações sobre as interfaces que o conector precisa implementar.

IServiceOperationsProvider

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

• Manifesto de operações

  O manifesto de operações inclui metadados sobre as operações implementadas em seu conector interno personalizado. O designer de Aplicativos Lógicos do Azure usa principalmente esses metadados para impulsionar as experiências de criação e monitoramento para as operações do seu conector. Por exemplo, o designer usa 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 tokens de propriedade das saídas, com base no esquema para as saídas da operação.

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

  Para obter mais informações sobre esses métodos e sua implementação, consulte a seção Métodos para implementar mais adiante neste artigo.

• Invocações de operação

  As invocações de operação são as implementações de método usadas durante a execução do fluxo de trabalho pelo tempo de execução dos Aplicativos Lógicos do Azure para chamar as operações especificadas na definição do fluxo de trabalho.

  • Se o gatilho for um tipo de gatilho baseado no Azure Functions, o método GetBindingConnectionInformation() será usado pelo tempo de execução nos Aplicativos Lógicos do Azure para fornecer as informações de parâmetros de conexão necessárias para a associação de gatilho do Azure Functions.

  • Se o conector tiver ações, o método InvokeOperation() será usado pelo tempo de execução para chamar cada ação no conector que é executada durante a execução do fluxo de trabalho. Caso contrário, você não precisa implementar esse método.

Para obter mais informações sobre esses métodos e sua implementação, consulte a seção Métodos para implementar mais adiante neste artigo.

IServiceOperationsTriggerProvider

Os recursos de gatilho internos personalizados dão suporte à adição ou exposição de um gatilho ou ação do Azure Functions como um gatilho de provedor de serviços em seu conector interno personalizado. Para usar o tipo de gatilho baseado no Azure Functions e a mesma vinculação do Azure Functions que o gatilho do conector gerenciado do Azure, implemente os seguintes métodos para fornecer as informações de conexão e as associações de gatilho, conforme exigido pelo Azure Functions.

• O método GetFunctionTriggerType() é necessário para retornar a cadeia de caracteres que é igual ao parâmetro type na associação de gatilho do Azure Functions.

• O GetFunctionTriggerDefinition() tem uma implementação padrão, portanto, você não precisa implementar explicitamente esse método. No entanto, se você quiser atualizar o comportamento padrão do gatilho, como fornecer parâmetros extras que o designer não expõe, você pode implementar esse método e substituir o comportamento padrão.

Métodos de implementação

As seções a seguir fornecem mais informações sobre os métodos que o conector precisa implementar. Para obter o exemplo completo, revise CosmosDbServiceOperationProvider.cs de exemplo e Criar conectores internos personalizados para aplicativos lógicos padrão em aplicativos lógicos do Azure de locatário único.

Importante

Quando você tiver informações confidenciais, como cadeias de conexão que incluem nomes de usuário e senhas, certifique-se de usar o fluxo de autenticação mais seguro disponível. Por exemplo, a Microsoft recomenda que você autentique o acesso aos recursos do Azure com uma identidade gerenciada quando o suporte estiver disponível e atribua uma função que tenha o menor privilégio necessário.

Se esse recurso não estiver disponível, certifique-se de proteger as cadeias de conexão por meio de outras medidas, como o Cofre da Chave do Azure, que você pode usar com as configurações do aplicativo. Em seguida, você pode fazer referência direta a cadeias de caracteres seguras, como cadeias de conexão e chaves. Semelhante aos modelos ARM, onde você pode definir variáveis de ambiente no momento da implantação, você pode definir as configurações do aplicativo dentro da definição do fluxo de trabalho do aplicativo lógico. Em seguida, você pode capturar valores de infraestrutura gerados dinamicamente, como pontos de extremidade de conexão, cadeias de caracteres de armazenamento e muito mais. Para obter mais informações, consulte Tipos de aplicativo para a plataforma de identidade da Microsoft.

GetService()

O designer requer esse 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 conexão, recursos, cor da marca, URL do ícone e assim por diante.

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

Para obter mais informações, consulte Exemplo de CosmosDbServiceOperationProvider.cs.

GetOperations()

O designer requer esse método para obter as operações implementadas pelo seu serviço. A lista de operações é baseada no esquema 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 tokens de propriedade, com base no esquema da saída para uma operação.

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

Para obter mais informações, consulte Exemplo de CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Se você quiser usar o tipo de gatilho baseado no Azure Functions, esse método fornece as informações de parâmetros de conexão necessárias para a associação de gatilho do Azure Functions.

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

Para obter mais informações, consulte Exemplo de CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Se o conector interno personalizado tiver apenas um gatilho, não será necessário implementar esse método. No entanto, se o conector tiver ações para implementar, será necessário implementar o método InvokeOperation(), que é chamado para cada ação no conector que é executada durante a execução do fluxo de trabalho. Você pode usar qualquer cliente, como FTPClient, HTTPClient e assim por diante, conforme exigido pelas ações do seu conector. Este exemplo usa 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 obter mais informações, consulte Exemplo de CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Para usar um gatilho baseado no Azure Functions como um gatilho em seu conector, você precisa retornar a cadeia de caracteres que é igual ao parâmetro type na associação de gatilho do Azure Functions.

O exemplo a seguir retorna a cadeia de caracteres para o gatilho interno do Azure Cosmos DB pronto para uso, "type": "cosmosDBTrigger":

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

Para obter mais informações, consulte Exemplo de CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Esse método tem uma implementação padrão, portanto, você não precisa implementar explicitamente esse método. No entanto, se você quiser atualizar o comportamento padrão do gatilho, como fornecer parâmetros extras que o designer não expõe, você pode implementar esse método e substituir o comportamento padrão.

Próximos passos

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

• Criar conectores incorporados personalizados para aplicações lógicas Standard no Azure Logic Apps de inquilino único