Compartilhar via

Conectores personalizados nos Aplicativos Lógicos do Azure

  • Artigo

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 predefinidas nos Aplicativos Lógicos do Azure. Um conector ajuda seus fluxos de trabalho a se conectarem e acessarem 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 fluxos de trabalho. Usando essas operações, você expande os recursos para que seus aplicativos de nuvem e aplicativos locais trabalhem com os dados novos e existentes.

Conectores em Aplicativos Lógicos do Azure são internos ou gerenciados. Conectores internos são executados nativamente no runtime dos Aplicativos Lógicos do Azure, o que significa que eles estão hospedados no mesmo processo que o runtime e fornecem maior taxa de transferência, baixa latência e conectividade local. Conectores gerenciados são proxies ou wrappers em torno de uma API, como Office 365 ou Salesforce, que auxiliam na comunicação do serviço subjacente com os Aplicativos Lógicos do Azure. Os conectores gerenciados são alimentados pela infraestrutura do conector no Azure e são implantados, hospedados, executados e gerenciados pela Microsoft. Você pode escolher entre mais de 1.400 conectores gerenciados para usar com seus fluxos de trabalho no Azure Logic Apps.

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 exigem essa etapa. Cada conexão criada é, na verdade, um recurso separado do Azure que fornece acesso ao aplicativo, serviço, sistema, protocolo ou plataforma de destino.

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

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

Aplicativos lógicos de Consumo

No Aplicativo Lógico 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 do aplicativo lógico de Consumo. A Documentação dos conectores fornece mais informações de visão geral sobre como criar conectores personalizados para aplicativos lógicos de consumo, incluindo tutoriais básicos e avançados completos. A seguinte lista também fornece links diretos para informações sobre conectores personalizados para aplicativos lógicos de consumo:

Aplicativos lógicos Standard

Nos Aplicativos Lógicos do Azure de locatário único, o runtime dos Aplicativos Lógicos do Azure reprojetado alimenta fluxos de trabalho de aplicativo lógico Standard. Esse runtime é diferente do runtime multilocatário dos Aplicativos Lógicos do Azure que alimentam os fluxos de trabalho do aplicativo de lógica de Consumo. O runtime de locatário único usa o modelo de extensibilidade do Azure Functions, que oferece uma funcionalidade fundamental para você criar conectores internos próprios para qualquer pessoa usar em fluxos de trabalho Standard. Na maioria dos casos, a versão interna fornece melhores condições de 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, essa lista de conectores internos continua a crescer. No entanto, se você precisar de conectores que não estejam disponíveis nos fluxos de trabalho de aplicativo lógico Standard, poderá criar conectores internos próprios usando o mesmo modelo de extensibilidade usado por conectores internos baseados no provedor de serviços em fluxos de trabalho Standard.

Conectores internos baseados no provedor de serviços

No Aplicativos Lógicos do Azure de locatário único, um conector interno com atributos específicos é informalmente conhecido como um provedor de serviços. Por exemplo, esses conectores se baseiam no modelo de extensibilidade do Azure Functions, que fornece a capacidade de criar seus próprios conectores internos personalizados a serem usados em fluxos de trabalho do aplicativo lógico Standard.

Por outro lado, conectores internos do provedor sem serviço têm os seguintes atributos:

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

  • É implementado diretamente como um trabalho dentro do runtime de Aplicativos Lógicos do Azure, como Agenda, HTTP, Solicitação e operações XML.

No momento, nenhuma funcionalidade está disponível para criar um conector interno que não seja provedor de serviços ou um novo tipo de trabalho executado diretamente no runtime dos Aplicativos Lógicos do Azure. No entanto, você pode criar conectores internos próprios 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 interno

Com base no modelo de extensibilidade 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 conectores internos próprios como extensões do Azure Functions que qualquer pessoa pode usar nos próprios fluxos de trabalho Standard. 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 do provedor de serviços em seu conector interno personalizado.

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

Diagrama conceitual mostrando a infraestrutura do provedor de serviços baseado no Azure Functions.

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

IServiceOperationsProvider

Essa interface inclui os métodos que fornecem o manifesto de operações para o 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 esses metadados principalmente para conduzir as experiências de criação e monitoramento para as operações do 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 facilitar a geração de tokens de propriedade das saídas, com base no esquema para as saídas da operação.

    O designer exige e usa 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 conexão que são exigidos pelo designer.

    Para obter mais informações sobre esses métodos e a implementação deles, examine a seção Métodos a serem implementados posteriormente neste artigo.

  • Invocações de operação

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

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

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

Para obter mais informações sobre esses métodos e a implementação deles, examine a seção Métodos a serem implementados posteriormente neste artigo.

IServiceOperationsTriggerProvider

Funcionalidades de gatilho internos personalizados dão suporte à adição ou exposição de um gatilho ou ação do Azure Functions como um gatilho do provedor de serviços em seu conector interno personalizado. Para usar o tipo de gatilho baseado em Azure Functions e a mesma associação do Azure Functions que o gatilho do conector gerenciado do Azure, implemente os métodos a seguir para fornecer as informações de conexão e disparar associações 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ê poderá implementar esse método e substituir o comportamento padrão.

Métodos a serem implementados

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

Importante

Quando houver informações confidenciais, como cadeias de conexão que incluam 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 a recursos do Azure com uma identidade gerenciada quando houver suporte disponível, e atribua uma função que tenha o mínimo de privilégios necessários.

Se essa funcionalidade estiver indisponível, certifique-se de proteger as cadeias de conexão por meio de outras medidas, como o Azure Key Vault, 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. De modo semelhante aos modelos do ARM, em que é possível definir variáveis de ambiente no momento da implantação, você pode definir as configurações de aplicativo na definição de fluxo de trabalho do aplicativo lógico. Em seguida, você pode capturar os valores da infraestrutura gerados dinamicamente, como pontos de extremidade de conexão, cadeias de caracteres de armazenamento, entre outros. Para obter mais informações, confira Tipos de aplicativo para a plataforma de identidade da Microsoft.

GetService()

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

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

Para obter mais informações, examine CosmosDbServiceOperationProvider.cs de exemplo.

GetOperations()

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

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

Para obter mais informações, examine CosmosDbServiceOperationProvider.cs de exemplo.

GetBindingConnectionInformation()

Se você quiser usar o tipo de gatilho baseado no Azure Functions, esse método fornecerá as informações de parâmetros de conexão necessárias à 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, examine CosmosDbServiceOperationProvider.cs de exemplo.

InvokeOperation()

Se o conector interno personalizado tiver apenas um gatilho, você não precisará implementar esse método. No entanto, se o conector tiver ações a serem implementadas, você precisará implementar o método InvokeOperation(), que é chamado para cada ação em seu 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 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, examine CosmosDbServiceOperationProvider.cs de exemplo.

GetFunctionTriggerType()

Para usar um gatilho baseado em 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, "type": "cosmosDBTrigger":

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

Para obter mais informações, examine CosmosDbServiceOperationProvider.cs de exemplo.

GetFunctionTriggerDefinition()

Este método tem uma implementação padrão, portanto, você não precisa implementá-lo explicitamente. 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ê poderá implementar esse método e substituir o comportamento padrão.

Próximas etapas

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