Delen via

Aangepaste connectors in Azure Logic Apps

  • Artikel

Van toepassing op: Azure Logic Apps (Verbruik + Standard)

Zonder code te schrijven, kunt u snel geautomatiseerde integratiewerkstromen maken wanneer u de vooraf gemaakte connectorbewerkingen in Azure Logic Apps gebruikt. Een connector helpt uw werkstromen verbinding te maken met en toegang te 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 met nieuwe en bestaande gegevens te werken.

Connectors in Azure Logic Apps zijn ingebouwd of beheerd. Een ingebouwde connector wordt systeemeigen uitgevoerd op de Azure Logic Apps-runtime, wat betekent dat deze worden gehost in hetzelfde proces als de runtime en 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 die u kunt gebruiken met uw werkstromen in Azure Logic Apps.

Wanneer u een connectorbewerking voor de eerste keer in een werkstroom gebruikt, is voor sommige connectors niet vereist dat u eerst een verbinding maakt, maar voor veel andere connectors is deze stap vereist. Elke verbinding die u maakt, is eigenlijk 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 gedefinieerde connectors. Ter ondersteuning van meer op maat gemaakte scenario's kunt u uw eigen aangepaste connectors maken om triggers en acties te bieden die niet beschikbaar zijn als vooraf gemaakte bewerkingen.

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

Logische apps voor verbruik

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

Standaard logische apps

In Azure Logic Apps met één tenant biedt de opnieuw ontworpen Azure Logic Apps-runtime standaardwerkstromen voor logische apps. Deze runtime verschilt van de Multitenant Azure Logic Apps-runtime die werkstromen van logische apps verbruiken. De runtime met één tenant maakt gebruik van het Azure Functions-uitbreidbaarheidsmodel, dat u een belangrijke mogelijkheid biedt om uw eigen ingebouwde connectors te maken voor iedereen die in Standard-werkstromen kan worden gebruikt. In de meeste gevallen biedt de ingebouwde versie betere prestaties, mogelijkheden, prijzen, enzovoort.

Wanneer Azure Logic Apps met één tenant officieel werd uitgebracht, bevatten nieuwe ingebouwde connectors Azure Blob Storage, Azure Event Hubs, Azure Service Bus en SQL Server. Na verloop van tijd blijft deze lijst met ingebouwde connectors groeien. 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 ingebouwde connectors op basis van serviceproviders in Standaardwerkstromen.

Ingebouwde connectors op basis van serviceproviders

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, waarmee u uw eigen aangepaste ingebouwde connectors kunt 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 in 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 of een nieuw taaktype te maken dat rechtstreeks in de Azure Logic Apps-runtime wordt uitgevoerd. 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 hoe het uitbreidbaarheidsmodel werkt voor aangepaste ingebouwde connectors.

Ingebouwd uitbreidbaarheidsmodel voor connectors

Op basis van het Azure Functions-uitbreidbaarheidsmodel heeft het ingebouwde uitbreidbaarheidsmodel voor connectors in Azure Logic Apps met één tenant een infrastructuur van een serviceprovider 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 beschikbaar maken 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 Azure Logic Apps Designer en runtime verwacht voor een aangepaste ingebouwde connector met een trigger op basis van Azure Functions:

Conceptueel diagram waarin de infrastructuur van de serviceprovider op basis van Azure Functions wordt weergegeven.

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

IServiceOperationsProvider

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

  • Bewerkingsmanifest

    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 bewakingservaringen voor de bewerkingen van uw connector te stimuleren. De ontwerpfunctie gebruikt bijvoorbeeld metagegevens van bewerkingen om inzicht te hebben in de invoerparameters die zijn vereist voor een specifieke bewerking en om het genereren van de eigenschapstokens van de uitvoer mogelijk te maken, op basis van het schema voor de uitvoer van de bewerking.

    De ontwerpfunctie vereist en gebruikt de Methoden GetService() en GetOperations() om query's uit te voeren op de bewerkingen die uw connector biedt en weergeeft op het ontwerpoppervlak. Met de methode GetService() worden ook de invoerparameters van de verbinding opgegeven die vereist zijn voor de ontwerpfunctie.

    Raadpleeg de sectie Methoden om verderop in dit artikel te implementeren voor meer informatie over deze methoden en hun implementatie.

  • Aanroepen van bewerkingen

    Bewerkingsvocations 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 verbindingsparametersgegevens op te geven voor de Azure Functions-triggerbinding.

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

Raadpleeg de sectie Methoden om verderop in dit artikel te implementeren voor meer informatie over deze methoden en hun implementatie.

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 triggertype op basis van Azure Functions en dezelfde Azure Functions-binding als de trigger voor de beheerde Azure-connector wilt gebruiken, 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.

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

Methoden om te implementeren

In de volgende secties vindt u meer informatie over de methoden die uw connector moet implementeren. Voor het volledige voorbeeld bekijkt u voorbeeld CosmosDbServiceOperationProvider.cs en maakt u aangepaste ingebouwde connectors voor Standaard logische apps in Azure Logic Apps met één tenant.

Belangrijk

Wanneer u gevoelige informatie hebt, zoals verbindingsreeks s die gebruikersnamen en wachtwoorden bevatten, moet u ervoor zorgen dat u de veiligste verificatiestroom gebruikt die beschikbaar is. Microsoft raadt u bijvoorbeeld aan om toegang tot Azure-resources te verifiëren met een beheerde identiteit wanneer ondersteuning beschikbaar is en een rol toe te wijzen die de minst vereiste bevoegdheid heeft.

Als deze mogelijkheid niet beschikbaar is, moet u verbindingsreeks beveiligen via andere metingen, zoals Azure Key Vault, die u kunt gebruiken met app-instellingen. U kunt vervolgens rechtstreeks verwijzen naar beveiligde tekenreeksen, zoals verbindingsreeks s en sleutels. Net als bij ARM-sjablonen, waar u omgevingsvariabelen tijdens de implementatie kunt definiëren, kunt u app-instellingen definiëren binnen de werkstroomdefinitie van uw logische app. Vervolgens kunt u dynamisch gegenereerde infrastructuurwaarden vastleggen, zoals verbindingseindpunten, opslagreeksen en meer. Zie Toepassingstypen voor het Microsoft Identity Platform voor meer informatie.

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

Raadpleeg voorbeeld CosmosDbServiceOperationProvider.cs voor meer informatie.

GetOperations()

De ontwerpfunctie vereist deze methode om de bewerkingen op te halen die door uw service worden geïmplementeerd. De lijst met bewerkingen is gebaseerd op het Swagger-schema. De ontwerpfunctie gebruikt ook de metagegevens van de bewerking om inzicht te hebben in de invoerparameters voor specifieke bewerkingen 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();
}

Raadpleeg voorbeeld CosmosDbServiceOperationProvider.cs voor meer informatie.

GetBindingConnectionInformation()

Als u het triggertype op basis van Azure Functions 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>();
}

Raadpleeg 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 om te implementeren, moet u de methode InvokeOperation() implementeren. Deze wordt aangeroepen voor elke actie in uw connector die wordt uitgevoerd tijdens de uitvoering van de werkstroom. U kunt elke client gebruiken, zoals FTPClient, HTTPClient, enzovoort, zoals vereist voor 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);
}

Raadpleeg voorbeeld CosmosDbServiceOperationProvider.cs voor meer informatie.

GetFunctionTriggerType()

Als u een op Azure Functions gebaseerde trigger wilt gebruiken als een 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, dus u hoeft deze methode niet expliciet te implementeren. Als u echter het standaardgedrag van de trigger wilt bijwerken, zoals extra parameters opgeven 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: