Aangepaste connectors in Azure Logic Apps

  • Artikel

Van toepassing op: Azure Logic Apps (verbruik + standaard)

Zonder code te schrijven, kunt u snel geautomatiseerde integratiewerkstromen maken wanneer u de vooraf gemaakte connectorbewerkingen in Azure Logic Apps gebruikt. Met een connector kunnen uw werkstromen verbinding maken met en toegang krijgen tot gegevens, gebeurtenissen en acties in andere apps, services, systemen, protocollen en platforms. Elke connector biedt bewerkingen als triggers, acties of beide die u aan uw werkstromen kunt toevoegen. Door deze bewerkingen te gebruiken, breidt u de mogelijkheden voor uw cloud-apps en on-premises apps uit om te werken met nieuwe en bestaande gegevens.

Connectors in Azure Logic Apps zijn ingebouwd of beheerd. Een ingebouwde connector wordt systeemeigen uitgevoerd in de Azure Logic Apps-runtime , wat betekent dat ze worden gehost in hetzelfde proces als de runtime en een hogere doorvoer, lage latentie en lokale connectiviteit bieden. Een beheerde connector is een proxy of een wrapper rond een API, zoals Office 365 of Salesforce, waarmee de onderliggende service kan communiceren met Azure Logic Apps. Beheerde connectors worden mogelijk gemaakt door de connectorinfrastructuur in Azure en worden geïmplementeerd, gehost, uitgevoerd en beheerd door Microsoft. U kunt kiezen uit honderden beheerde connectors voor gebruik met uw werkstromen in Azure Logic Apps.

Wanneer u een connectorbewerking voor het eerst in een werkstroom gebruikt, hoeft u voor sommige connectors niet eerst een verbinding te maken, maar voor veel andere connectors is deze stap vereist. Elke verbinding die u maakt, is in feite een afzonderlijke Azure-resource die toegang biedt tot de doel-app, service, systeem, protocol of platform.

Soms wilt u echter MOGELIJK REST API's aanroepen die niet beschikbaar zijn als vooraf gemaakte connectors. Ter ondersteuning van meer op maat gemaakte scenario's kunt u uw eigen aangepaste connectors maken om triggers en acties aan te bieden die niet beschikbaar zijn als vooraf gedefinieerde bewerkingen.

Dit artikel bevat een overzicht van aangepaste connectors voor logische app-werkstromen voor verbruik en standaardwerkstromen voor logische apps. Elk type logische app wordt mogelijk gemaakt door een andere Azure Logic Apps-runtime, respectievelijk gehost in Azure met meerdere tenants en Azure met één tenant. Raadpleeg de volgende documentatie voor meer informatie over connectors in Azure Logic Apps:

Logische apps voor verbruik

In Azure Logic Apps met meerdere tenants kunt u aangepaste connectors maken van op Swagger of SOAP gebaseerde API's tot specifieke limieten voor gebruik in werkstromen voor logische apps voor verbruik. De documentatie over connectors biedt meer overzichtsinformatie over het maken van aangepaste connectors voor logische verbruiks-apps, waaronder volledige basis- en geavanceerde zelfstudies. De volgende lijst bevat ook directe koppelingen naar informatie over aangepaste connectors voor logische verbruiksapps:

Standaard logische apps

In Azure Logic Apps met één tenant zorgt de opnieuw ontworpen Azure Logic Apps-runtime voor de standaardwerkstromen voor logische apps. Deze runtime verschilt van de Azure Logic Apps-runtime met meerdere tenants die de logische app-werkstromen verbruik mogelijk maakt. De runtime met één tenant maakt gebruik van het Azure Functions-uitbreidingsmodel, dat u een belangrijke mogelijkheid biedt om uw eigen ingebouwde connectors te maken die iedereen in Standaardwerkstromen kan gebruiken. In de meeste gevallen biedt de ingebouwde versie betere prestaties, mogelijkheden, prijzen, enzovoort.

Wanneer Azure Logic Apps met één tenant officieel is uitgebracht, bevatten nieuwe ingebouwde connectors Azure Blob Storage, Azure Event Hubs, Azure Service Bus en SQL Server. Na verloop van tijd wordt deze lijst met ingebouwde connectors steeds groter. Als u echter connectors nodig hebt die niet beschikbaar zijn in standaardwerkstromen voor logische apps, kunt u uw eigen ingebouwde connectors maken met hetzelfde uitbreidbaarheidsmodel dat wordt gebruikt door op serviceproviders gebaseerde ingebouwde connectors in standaardwerkstromen.

Op serviceprovider gebaseerde ingebouwde connectors

In Azure Logic Apps met één tenant wordt een ingebouwde connector met specifieke kenmerken informeel een serviceprovider genoemd. Deze connectors zijn bijvoorbeeld gebaseerd op het Azure Functions uitbreidbaarheidsmodel, dat u de mogelijkheid biedt om uw eigen aangepaste ingebouwde connectors te maken voor gebruik in standaardwerkstromen voor logische apps.

Ingebouwde connectors van niet-serviceproviders hebben daarentegen de volgende kenmerken:

  • Is niet gebaseerd op het Azure Functions uitbreidbaarheidsmodel.

  • Wordt rechtstreeks geïmplementeerd als een taak binnen de Azure Logic Apps-runtime, zoals plannings-, HTTP-, aanvraag- en XML-bewerkingen.

Er is momenteel geen mogelijkheid beschikbaar om een ingebouwde connector van een niet-serviceprovider te maken of een nieuw taaktype dat rechtstreeks wordt uitgevoerd in de Azure Logic Apps-runtime. U kunt echter uw eigen ingebouwde connectors maken met behulp van de infrastructuur van de serviceprovider.

In de volgende sectie vindt u meer informatie over de werking van het uitbreidbaarheidsmodel voor aangepaste ingebouwde connectors.

Ingebouwd model voor uitbreidbaarheid van connectoren

Op basis van het Azure Functions uitbreidbaarheidsmodel heeft het ingebouwde connectoruitbreidingsmodel in Azure Logic Apps met één tenant een serviceproviderinfrastructuur die u kunt gebruiken om uw eigen ingebouwde connectors te maken, te verpakken, te registreren en te installeren als Azure Functions extensies die iedereen in hun standaardwerkstromen kan gebruiken. Dit model bevat aangepaste ingebouwde triggermogelijkheden die ondersteuning bieden voor het weergeven van een Azure Functions-trigger of actie als een serviceprovidertrigger in uw aangepaste ingebouwde connector.

In het volgende diagram ziet u de methode-implementaties die de Ontwerpfunctie en runtime van Azure Logic Apps verwacht voor een aangepaste ingebouwde connector met een trigger op basis van Azure Functions:

Conceptueel diagram met de infrastructuur van Azure Functions serviceproviders.

De volgende secties bevatten meer informatie over de interfaces die uw connector moet implementeren.

IServiceOperationsProvider

Deze interface bevat de methoden die het bewerkingsmanifest voor uw aangepaste ingebouwde connector bieden.

  • Bewerkingenmanifest

    Het bewerkingsmanifest bevat metagegevens over de geïmplementeerde bewerkingen in uw aangepaste ingebouwde connector. De ontwerpfunctie van Azure Logic Apps gebruikt deze metagegevens voornamelijk om de ontwerp- en bewakingservaring voor de bewerkingen van uw connector te stimuleren. De ontwerper gebruikt bijvoorbeeld bewerkingsmetagegevens om inzicht te hebben in de invoerparameters die zijn vereist voor een specifieke bewerking en om het genereren van de eigenschapstokens van de uitvoer te vergemakkelijken, op basis van het schema voor de uitvoer van de bewerking.

    De ontwerpfunctie vereist en gebruikt de methoden GetService() en GetOperations() om een query uit te voeren op de bewerkingen die de connector biedt en weergeeft op het ontwerpoppervlak. De methode GetService() geeft ook de invoerparameters van de verbinding op die vereist zijn voor de ontwerpfunctie.

    Raadpleeg de sectie Te implementeren methoden verderop in dit artikel voor meer informatie over deze methoden en de implementatie ervan.

  • Aanroepen van bewerkingen

    Bewerkingsoproepen zijn de methode-implementaties die worden gebruikt tijdens de uitvoering van de werkstroom door de Azure Logic Apps-runtime om de opgegeven bewerkingen in de werkstroomdefinitie aan te roepen.

    • Als uw trigger een op Azure Functions gebaseerd triggertype is, wordt de methode GetBindingConnectionInformation() gebruikt door de runtime in Azure Logic Apps om de vereiste informatie over verbindingsparameters te verstrekken aan de Azure Functions triggerbinding.

    • Als uw connector acties heeft, wordt de methode InvokeOperation() door de runtime gebruikt om elke actie in de connector aan te roepen die wordt uitgevoerd tijdens het uitvoeren van de werkstroom. Anders hoeft u deze methode niet te implementeren.

Raadpleeg de sectie Te implementeren methoden verderop in dit artikel voor meer informatie over deze methoden en de implementatie ervan.

IServiceOperationsTriggerProvider

Aangepaste ingebouwde triggermogelijkheden ondersteunen het toevoegen of weergeven van een Azure Functions trigger of actie als een serviceprovidertrigger in uw aangepaste ingebouwde connector. Als u het op Azure Functions gebaseerde triggertype en dezelfde Azure Functions binding wilt gebruiken als de trigger van de beheerde Azure-connector, implementeert u de volgende methoden om de verbindingsgegevens en triggerbindingen op te geven zoals vereist door Azure Functions.

  • De methode GetFunctionTriggerType() is vereist om de tekenreeks te retourneren die hetzelfde is als de typeparameter in de Azure Functions triggerbinding.

  • GetFunctionTriggerDefinition() heeft een standaardimplementatie, zodat u deze methode niet expliciet hoeft te implementeren. Als u echter het standaardgedrag van de trigger wilt bijwerken, zoals het opgeven van extra parameters die de ontwerper niet beschikbaar maakt, kunt u deze methode implementeren en het standaardgedrag overschrijven.

Methoden om te implementeren

De volgende secties bevatten meer informatie over de methoden die uw connector moet implementeren. Voor het volledige voorbeeld raadpleegt u Voorbeeld CosmosDbServiceOperationProvider.cs en Aangepaste ingebouwde connectors maken voor standaard logische apps in Azure Logic Apps met één tenant.

GetService()

De ontwerper vereist deze methode om de metagegevens op hoog niveau voor uw service op te halen, waaronder de servicebeschrijving, verbindingsinvoerparameters, mogelijkheden, merkkleur, pictogram-URL, enzovoort.

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

Zie Sample CosmosDbServiceOperationProvider.cs (Voorbeeld cosmosdbserviceoperationprovider.cs) voor meer informatie.

GetOperations()

De ontwerper vereist deze methode om de bewerkingen op te halen die door uw service zijn geïmplementeerd. De lijst met bewerkingen is gebaseerd op het Swagger-schema. De ontwerpfunctie gebruikt ook de metagegevens van de bewerking om de invoerparameters voor specifieke bewerkingen te begrijpen en de uitvoer te genereren als eigenschapstokens, op basis van het schema van de uitvoer voor een bewerking.

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

Zie Sample CosmosDbServiceOperationProvider.cs (Voorbeeld cosmosdbserviceoperationprovider.cs) voor meer informatie.

GetBindingConnectionInformation()

Als u het op Azure Functions gebaseerde triggertype wilt gebruiken, biedt deze methode de vereiste informatie over verbindingsparameters voor de Azure Functions triggerbinding.

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

Zie Sample CosmosDbServiceOperationProvider.cs (Voorbeeld cosmosdbserviceoperationprovider.cs) voor meer informatie.

InvokeOperation()

Als uw aangepaste ingebouwde connector alleen een trigger heeft, hoeft u deze methode niet te implementeren. Als uw connector echter acties heeft die moeten worden geïmplementeerd, moet u de methode InvokeOperation() implementeren, die wordt aangeroepen voor elke actie in de connector die wordt uitgevoerd tijdens het uitvoeren van de werkstroom. U kunt elke client gebruiken, zoals FTPClient, HTTPClient, enzovoort, zoals vereist door de acties van uw connector. In dit voorbeeld wordt HTTPClient gebruikt.

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);
}

Zie Sample CosmosDbServiceOperationProvider.cs (Voorbeeld cosmosdbserviceoperationprovider.cs) voor meer informatie.

GetFunctionTriggerType()

Als u een trigger op basis van Azure Functions wilt gebruiken als trigger in uw connector, moet u de tekenreeks retourneren die hetzelfde is als de typeparameter in de Azure Functions triggerbinding.

In het volgende voorbeeld wordt de tekenreeks geretourneerd voor de standaard ingebouwde Azure Cosmos DB-trigger, "type": "cosmosDBTrigger":

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

Raadpleeg Voorbeeld CosmosDbServiceOperationProvider.cs voor meer informatie.

GetFunctionTriggerDefinition()

Deze methode heeft een standaard implementatie, zodat u deze methode niet expliciet hoeft te implementeren. Als u echter het standaardgedrag van de trigger wilt bijwerken, zoals het opgeven van extra parameters die de ontwerper niet beschikbaar maakt, kunt u deze methode implementeren en het standaardgedrag overschrijven.

Volgende stappen

Wanneer u klaar bent om de implementatiestappen te starten, gaat u verder met het volgende artikel: