Conectores personalizados no Azure Logic Apps
Aplica-se a: Azure Logic Apps (Consumo + Standard)
Sem escrever código, pode criar rapidamente fluxos de trabalho de integração automatizadas quando utiliza as operações de conector pré-criadas no Azure Logic Apps. Um conector ajuda os seus fluxos de trabalho a ligar e aceder a dados, eventos e ações noutras aplicações, serviços, sistemas, protocolos e plataformas. Cada conector oferece operações como acionadores, ações ou ambos que pode adicionar aos seus fluxos de trabalho. Ao utilizar estas operações, expande as capacidades para que as suas aplicações na cloud e aplicações no local funcionem com dados novos e existentes.
Os conectores no Azure Logic Apps estão incorporados ou geridos. Um conector incorporado é executado nativamente no runtime do Azure Logic Apps, o que significa que estão alojados no mesmo processo que o runtime e fornecem um débito mais elevado, baixa latência e conectividade local. Um conector gerido é um proxy ou um wrapper em torno de uma API, como Office 365 ou Salesforce, que ajuda o serviço subjacente a falar com o Azure Logic Apps. Os conectores geridos são alimentados pela infraestrutura do conector no Azure e são implementados, alojados, executados e geridos pela Microsoft. Pode escolher entre centenas de conectores geridos para utilizar com os seus fluxos de trabalho no Azure Logic Apps.
Quando utiliza uma operação de conector pela primeira vez num fluxo de trabalho, alguns conectores não exigem que crie uma ligação primeiro, mas muitos outros conectores requerem este passo. Cada ligação que cria é, na verdade, um recurso separado do Azure que fornece acesso à aplicação, serviço, sistema, protocolo ou plataforma de destino.
No entanto, por vezes, poderá querer chamar APIs REST que não estão disponíveis como conectores pré-criados. Para suportar cenários mais personalizados, pode criar os seus próprios conectores personalizados para oferecer acionadores e ações que não estão disponíveis como operações pré-criadas.
Este artigo fornece uma descrição geral sobre os conectores personalizados para fluxos de trabalho de aplicações lógicas de consumo e fluxos de trabalho da aplicação lógica Standard. Cada tipo de aplicação lógica é alimentado por um runtime do Azure Logic Apps diferente, respetivamente alojado no Azure multi-inquilino e no Azure de inquilino único. Para obter mais informações sobre conectores no Azure Logic Apps, veja a seguinte documentação:
- Acerca dos conectores no Azure Logic Apps
- Conectores incorporados no Azure Logic Apps
- Conectores geridos no Azure Logic Apps
- Descrição geral do conector
- Ambiente de serviço de integração e inquilino único versus multi-inquilino para o Azure Logic Apps
Aplicações lógicas de consumo
No Azure Logic Apps multi-inquilino, pode criar conectores personalizados a partir de APIs baseadas em Swagger ou baseadas em SOAP até limites específicos para utilização em fluxos de trabalho de aplicações lógicas de consumo. A documentação dos Conectores fornece mais informações de descrição geral sobre como criar conectores personalizados para aplicações lógicas de Consumo, incluindo tutoriais básicos e avançados completos. A lista seguinte também fornece ligações diretas para informações sobre conectores personalizados para aplicações lógicas de Consumo:
- Criar um conector do Azure Logic Apps
- Create a custom connector from an OpenAPI definition (Criar um conector personalizado a partir de uma definição OpenAPI)
- Criar um conector personalizado a partir de uma coleção do Postman
- Use a custom connector from a logic app (Utilizar um conector personalizado a partir de uma aplicação lógica)
- Partilhar conectores personalizados na sua organização
- Submeter os conectores para certificação Microsoft
- Custom connector FAQ (FAQ dos conectores personalizados)
Aplicações lógicas padrão
No Azure Logic Apps de inquilino único, o runtime redesenhado do Azure Logic Apps alimenta os fluxos de trabalho da aplicação lógica Standard. Este runtime difere do runtime multi-inquilino do Azure Logic Apps que alimenta os fluxos de trabalho da aplicação lógica consumo. O runtime de inquilino único utiliza o modelo de extensibilidade Funções do Azure, que fornece uma capacidade fundamental para criar os seus próprios conectores incorporados para qualquer pessoa utilizar em fluxos de trabalho Standard. Na maioria dos casos, a versão incorporada proporciona um melhor desempenho, capacidades, preços, etc.
Quando o Azure Logic Apps de inquilino único foi lançado oficialmente, os novos conectores incorporados incluíam Armazenamento de Blobs do Azure, Hubs de Eventos do Azure, Azure Service Bus e SQL Server. Ao longo do tempo, esta lista de conectores incorporados continua a crescer. No entanto, se precisar de conectores que não estão disponíveis nos fluxos de trabalho da aplicação lógica Standard, pode criar os seus próprios conectores incorporados com o mesmo modelo de extensibilidade utilizado pelos conectores incorporados baseados no fornecedor de serviços nos fluxos de trabalho Standard.
Conectores incorporados baseados no fornecedor de serviços
No Azure Logic Apps de inquilino único, um conector incorporado com atributos específicos é informalmente conhecido como fornecedor de serviços. Por exemplo, estes conectores baseiam-se no modelo de extensibilidade Funções do Azure, que lhe permite criar os seus próprios conectores incorporados personalizados para utilizar em fluxos de trabalho de aplicações lógicas Standard.
Por outro lado, os conectores incorporados de fornecedores não-serviços têm os seguintes atributos:
Não se baseia no modelo de extensibilidade Funções do Azure.
É implementado diretamente como uma tarefa no runtime do Azure Logic Apps, como operações Schedule, HTTP, Request e XML.
Não existe atualmente nenhuma capacidade disponível para criar um conector incorporado de fornecedor não serviço ou um novo tipo de tarefa que é executado diretamente no runtime do Azure Logic Apps. No entanto, pode criar os seus próprios conectores incorporados com a infraestrutura do fornecedor 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 de inquilino único tem uma infraestrutura de fornecedor de serviços que pode utilizar para criar, empacotar, registar e instalar os seus próprios conectores incorporados como extensões Funções do Azure que qualquer pessoa pode utilizar nos seus fluxos de trabalho Standard. Este modelo inclui capacidades de acionador incorporadas personalizadas que suportam a exposição de um acionador ou ação Funções do Azure como acionador de fornecedor de serviços no conector incorporado personalizado.
O diagrama seguinte mostra as implementações do método que o estruturador e o runtime do Azure Logic Apps esperam para um conector incorporado personalizado com um acionador baseado em Funções do Azure:
As secções seguintes fornecem mais informações sobre as interfaces que o conector precisa de implementar.
IServiceOperationsProvider
Esta interface inclui os métodos que fornecem o manifesto de operações para o conector incorporado personalizado.
Manifesto de operações
O manifesto de operações inclui metadados sobre as operações implementadas no conector incorporado personalizado. O estruturador do Azure Logic Apps utiliza principalmente estes metadados para impulsionar as experiências de criação e monitorização das operações do conector. Por exemplo, o estruturador utiliza metadados de operação para compreender os parâmetros de entrada exigidos por uma operação específica e para facilitar a geração dos tokens de propriedade das saídas, com base no esquema para as saídas da operação.
O estruturador requer e utiliza os métodos GetService() e GetOperations() para consultar as operações que o conector fornece e mostra na superfície do estruturador. O método GetService() também especifica os parâmetros de entrada da ligação que são necessários para o estruturador.
Para obter mais informações sobre estes métodos e a respetiva implementação, veja a secção Métodos para implementar mais adiante neste artigo.
Invocações de operações
As invocações de operações são as implementações do método utilizadas durante a execução do fluxo de trabalho pelo runtime do Azure Logic Apps para chamar as operações especificadas na definição do fluxo de trabalho.
Se o acionador for um tipo de acionador baseado em Funções do Azure, o método GetBindingConnectionInformation() é utilizado pelo runtime no Azure Logic Apps para fornecer as informações dos parâmetros de ligação necessários ao enlace do acionador Funções do Azure.
Se o conector tiver ações, o método InvokeOperation() é utilizado pelo runtime para chamar cada ação no conector que é executada durante a execução do fluxo de trabalho. Caso contrário, não tem de implementar este método.
Para obter mais informações sobre estes métodos e a respetiva implementação, veja a secção Métodos para implementar mais adiante neste artigo.
IServiceOperationsTriggerProvider
As capacidades personalizadas do acionador incorporado suportam a adição ou exposição de um acionador ou ação Funções do Azure como acionador de fornecedor de serviços no conector incorporado personalizado. Para utilizar o tipo de acionador baseado em Funções do Azure e o mesmo enlace de Funções do Azure que o acionador do conector gerido do Azure, implemente os seguintes métodos para fornecer as informações de ligação e enlaces de acionador, conforme exigido pelo Funções do Azure.
O método GetFunctionTriggerType() é necessário para devolver a cadeia que é igual ao parâmetro de tipo no enlace do acionador Funções do Azure.
GetFunctionTriggerDefinition() tem uma implementação predefinida, pelo que não precisa de implementar explicitamente este método. No entanto, se quiser atualizar o comportamento predefinido do acionador, como fornecer parâmetros adicionais que o estruturador não expõe, pode implementar este método e substituir o comportamento predefinido.
Métodos para implementar
As secções seguintes fornecem mais informações sobre os métodos que o conector precisa de implementar. Para obter o exemplo completo, veja Sample CosmosDbServiceOperationProvider.cs e Create custom built-in connectors for Standard logic apps in single-tenant Azure Logic Apps (Criar conectores incorporados personalizados para aplicações lógicas Standard no Azure Logic Apps de inquilino único).
GetService()
O estruturador requer este método para obter os metadados de alto nível para o seu serviço, incluindo a descrição do serviço, os parâmetros de entrada de ligação, as capacidades, a cor da marca, o URL do ícone, etc.
public ServiceOperationApi GetService()
{
return this.{custom-service-name-apis}.ServiceOperationServiceApi();
}
Para obter mais informações, veja Sample CosmosDbServiceOperationProvider.cs.
GetOperations()
O estruturador requer este método para implementar as operações pelo seu serviço. A lista de operações baseia-se no esquema swagger. O estruturador também utiliza os metadados da operação para compreender 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, veja Sample CosmosDbServiceOperationProvider.cs.
GetBindingConnectionInformation()
Se quiser utilizar o tipo de acionador baseado em Funções do Azure, este método fornece as informações dos parâmetros de ligação necessários ao enlace do acionador 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 obter mais informações, veja Sample CosmosDbServiceOperationProvider.cs.
InvokeOperation()
Se o conector incorporado personalizado tiver apenas um acionador, não terá de implementar este método. No entanto, se o conector tiver ações a implementar, terá de implementar o método InvokeOperation(), que é chamado para cada ação no conector que é executada durante a execução do fluxo de trabalho. Pode utilizar qualquer cliente, como FTPClient, HTTPClient, etc., conforme exigido pelas ações do 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 obter mais informações, veja Sample CosmosDbServiceOperationProvider.cs.
GetFunctionTriggerType()
Para utilizar um acionador baseado em Funções do Azure como um acionador no conector, tem de devolver a cadeia que é igual ao parâmetro de tipo no enlace do acionador Funções do Azure.
O exemplo seguinte devolve a cadeia para o acionador "type": "cosmosDBTrigger"incorporado do Azure Cosmos DB, :
public string GetFunctionTriggerType()
{
return "CosmosDBTrigger";
}
Para obter mais informações, veja Sample CosmosDbServiceOperationProvider.cs.
GetFunctionTriggerDefinition()
Este método tem uma implementação predefinida, pelo que não precisa de implementar explicitamente este método. No entanto, se quiser atualizar o comportamento predefinido do acionador, como fornecer parâmetros adicionais que o estruturador não expõe, pode implementar este método e substituir o comportamento predefinido.
Passos seguintes
Quando estiver pronto para iniciar os passos de implementação, avance para o seguinte artigo: