Over connectors in Azure Logic Apps

Wanneer u werkstromen bouwt met behulp van Azure Logic Apps, kunt u connectors gebruiken om snel en eenvoudig toegang te krijgen tot gegevens, gebeurtenissen en resources in andere apps, services, systemen, protocollen en platforms, vaak zonder code te schrijven. Een connector biedt vooraf gebouwde bewerkingen die u als stappen in uw werkstromen kunt gebruiken. Azure Logic Apps biedt honderden connectors die u kunt gebruiken. Als er geen connector beschikbaar is voor de resource die u wilt openen, kunt u de algemene HTTP-bewerking gebruiken om te communiceren met de service of u kunt een aangepaste connector maken.

Dit overzicht bevat een inleiding tot connectors, hoe ze in het algemeen werken en de meest populaire en veelgebruikte connectors in Azure Logic Apps. Bekijk de volgende documentatie voor meer informatie:

Wat zijn connectors?

Technisch gezien is een connector een proxy of een wrapper rond een API die de onderliggende service gebruikt om te communiceren met Azure Logic Apps. Deze connector biedt bewerkingen die u in uw werkstromen gebruikt om taken uit te voeren. Een bewerking is beschikbaar als een trigger of actie met eigenschappen die u kunt configureren. Voor sommige triggers en acties moet u ook eerst een verbinding maken en configureren met de onderliggende service of het onderliggende systeem, bijvoorbeeld, zodat u de toegang tot een gebruikersaccount kunt verifiëren.

Triggers

Een trigger geeft de gebeurtenis aan die de werkstroom start en is altijd de eerste stap in een werkstroom. Elke trigger volgt ook een specifiek patroon dat bepaalt hoe de trigger gebeurtenissen bewaakt en erop reageert. Normaal gesproken volgt een trigger het polling-patroon of pushpatroon, maar soms is een trigger beschikbaar in beide versies.

  • Poll-triggers controleren regelmatig een specifieke service of een specifiek systeem volgens een opgegeven planning om te controleren op nieuwe gegevens of een specifieke gebeurtenis. Als er nieuwe gegevens beschikbaar zijn of als de specifieke gebeurtenis zich voordeed, maken en voeren deze triggers een nieuw exemplaar van uw werkstroom uit. Deze nieuwe instantie kan vervolgens de gegevens gebruiken die als invoer worden doorgegeven.
  • Push-triggers luisteren naar nieuwe gegevens of naar een gebeurtenis, zonder polling. Wanneer er nieuwe gegevens beschikbaar zijn of wanneer de gebeurtenis zich voordeed, maken en voeren deze triggers een nieuw exemplaar van uw werkstroom uit. Deze nieuwe instantie kan vervolgens de gegevens gebruiken die als invoer worden doorgegeven.

U kunt bijvoorbeeld een werkstroom maken die iets doet wanneer een bestand wordt geüpload naar uw FTP-server. Als eerste stap in uw werkstroom kunt u de FTP-trigger gebruiken met de naam Wanneer een bestand wordt toegevoegd of gewijzigd, dat het pollingpatroon volgt. U kunt vervolgens een planning opgeven om regelmatig te controleren op uploadgebeurtenissen.

Een trigger geeft ook alle invoer en andere vereiste gegevens door aan uw werkstroom, waar latere acties kunnen verwijzen naar die gegevens in de hele werkstroom en deze kunnen gebruiken. Stel bijvoorbeeld dat u een trigger wilt Office 365 Outlook met de naam Wanneer er een nieuwe e-mail binnenkomt om een werkstroom te starten wanneer u een nieuwe e-mail ontvangt. U kunt deze trigger configureren om de inhoud van elk nieuw e-mailbericht door te geven, zoals de afzender, de onderwerpregel, de body, bijlagen, en meer. Uw werkstroom kan die informatie vervolgens verwerken met behulp van andere acties.

Acties

Een actie is een bewerking die de trigger volgt en een soort taak in uw werkstroom uitvoert. U kunt meerdere acties in uw werkstroom gebruiken. U kunt de werkstroom bijvoorbeeld starten met een SQL trigger voor het detecteren van nieuwe klantgegevens in een SQL database. Na de trigger kan uw werkstroom een SQL actie hebben die de klantgegevens ophaalt. Na de SQL kan uw werkstroom een andere actie hebben, niet noodzakelijkerwijs SQL, die de gegevens verwerkt.

Connectorcategorieën

In Azure Logic Apps zijn de meeste triggers en acties beschikbaar in een ingebouwde versie of beheerde connectorversie. Er zijn een aantal triggers en acties beschikbaar in beide versies. Welke versies beschikbaar zijn, is afhankelijk van of u een logische app met meerdere tenants of een logische app met één tenant maakt, die momenteel alleen beschikbaar is in één tenant Azure Logic Apps.

Ingebouwde triggers en acties worden in het eigen Logic Apps uitgevoerd, hoeven geen verbindingen te maken en voeren dit soort taken uit:

Beheerde connectors worden geïmplementeerd, gehost en beheerd door Microsoft. Deze connectors bieden triggers en acties voor cloudservices, on-premises systemen of beide. Beheerde connectors zijn beschikbaar in de volgende categorieën:

Verbindingsconfiguratie

Als u resources en verbindingen voor logische apps wilt maken of beheren, hebt u bepaalde machtigingen nodig, die worden geleverd via rollen met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). U kunt ingebouwde of aangepaste rollen toewijzen aan leden die toegang hebben tot uw Azure-abonnement. Azure Logic Apps heeft deze specifieke rollen:

  • Inzender voor logischeapps: hiermee kunt u logische apps beheren, maar u kunt de toegang tot deze apps niet wijzigen.

  • Operator voor logische apps:hiermee kunt u logische apps lezen, inschakelen en uitschakelen, maar u kunt ze niet bewerken of bijwerken.

  • Inzender:verleent volledige toegang voor het beheren van alle resources, maar biedt u niet de mogelijkheid om rollen toe te wijzen in Azure RBAC, toewijzingen te beheren in Azure Blueprints of galerieën met afbeeldingen te delen.

    Stel dat u moet werken met een logische app die u niet hebt gemaakt en verbindingen hebt geverifieerd die worden gebruikt door de werkstroom van die logische app. Uw Azure-abonnement vereist inzendermachtigingen voor de resourcegroep die die logische app-resource bevat. Als u een logische app-resource maakt, hebt u automatisch inzenderstoegang.

Voordat u de triggers of acties van een connector in uw werkstroom kunt gebruiken, moeten de meeste connectors eerst een verbinding maken met de doelservice of het doelsysteem. Als u een verbinding wilt maken vanuit een werkstroom voor een logische app, moet u uw identiteit verifiëren met accountreferenties en soms andere verbindingsgegevens. Voordat uw werkstroom bijvoorbeeld toegang heeft tot uw Office 365 Outlook e-mailaccount, moet u een verbinding met dat account toestaan. Voor een klein aantal ingebouwde bewerkingen en beheerde connectors kunt u een beheerde identiteit instellen en gebruiken voor verificatie inplaats van uw referenties op te geven.

Verbindingsbeveiliging en -versleuteling

Details van de verbindingsconfiguratie, zoals serveradres, gebruikersnaam en wachtwoord, referenties en geheimen, worden versleuteld en opgeslagen in de beveiligde Azure-omgeving. Deze informatie kan alleen worden gebruikt in resources van logische apps en door clients die machtigingen hebben voor de verbindingsresource, die wordt afgedwongen met behulp van gekoppelde toegangscontroles. Voor verbindingen die gebruikmaken van Azure Active Directory Open Authentication (Azure AD OAuth), zoals Office 365, Salesforce en GitHub, moet u zich aanmelden, maar Azure Logic Apps slaat alleen toegangs- en vernieuwingstokens op als geheimen, niet als aanmeldingsreferenties.

Tot stand gebrachte verbindingen hebben toegang tot de doelservice of het doelsysteem zolang dat is mogelijk met die service of het systeem. Voor services die gebruikmaken van Azure AD OAuth-verbindingen, zoals Office 365 en Dynamics, vernieuwt de Logic Apps-service de toegangstokens voor onbepaalde tijd. Andere services hebben mogelijk limieten voor hoe lang Logic Apps een token kunnen gebruiken zonder te vernieuwen. Sommige acties, zoals het wijzigen van uw wachtwoord, maken alle toegangstokens ongeldig.

Hoewel u verbindingen maakt vanuit een werkstroom, zijn verbindingen afzonderlijke Azure-resources met hun eigen resourcedefinities. Als u deze verbindingsresourcedefinities wilt bekijken, downloadt u uw logische app van Azure naar Visual Studio. Deze methode is de eenvoudigste manier om een geldige, geparameteriseerde logische app-sjabloon te maken die voornamelijk gereed is voor implementatie.

Tip

Als uw organisatie u geen toegang geeft tot specifieke resources via Logic Apps-connectors, kunt u de mogelijkheid blokkeren om dergelijke verbindingen te maken met behulp van Azure Policy.

Voor meer informatie over het beveiligen van logische apps en verbindingen, bekijkt u Beveiligde toegang en gegevens in Azure Logic Apps.

Firewalltoegang voor verbindingen

Als u een firewall gebruikt die verkeer beperkt en de werkstromen van uw logische app moeten communiceren via die firewall, moet u uw firewall zo instellen dat toegang wordt toegestaan voor zowel de binnenkomende als uitgaande IP-adressen die worden gebruikt door de Logic Apps-service of runtime in de Azure-regio waar uw logische app-werkstromen bestaan. Als uw werkstromen ook beheerde connectors gebruiken, zoals de Office 365 Outlook-connector of SQL-connector, of aangepaste connectors gebruiken, moet uw firewall ook toegang toestaan voor alle uitgaande IP-adressen van de beheerde connector in de Azure-regio van uw logische app. Bekijk Firewallconfiguratie voor meer informatie.

Terugkeerpatroongedrag

Terugkerende ingebouwde triggers, zoals de trigger Terugkeerpatroon,worden native uitgevoerd op de Logic Apps-runtime en verschillen van terugkerende triggers op basis van verbindingen, zoals de trigger van de Office 365 Outlook-connector, waar u eerst een verbinding moet maken.

Als een terugkeerpatroon voor beide soorten triggers geen specifieke begindatum en -tijd opgeeft, wordt het eerste terugkeerpatroon onmiddellijk uitgevoerd wanneer u de logische app opgeeft of implementeert, ondanks de instelling van het terugkeerpatroon van de trigger. Om dit gedrag te voorkomen, geeft u een begindatum en -tijd op voor wanneer u het eerste terugkeerpatroon wilt uitvoeren.

Terugkeerpatroon voor ingebouwde triggers

Terugkerende ingebouwde triggers volgen de planning die u hebt ingesteld, inclusief een opgegeven tijdzone. Als een terugkeerpatroon echter geen andere geavanceerde planningsopties opgeeft, zoals specifieke tijden voor het uitvoeren van toekomstige terugkeerpatroon, zijn deze terugkeerpatroon gebaseerd op de laatste uitvoering van de trigger. Als gevolg hiervan kunnen de begintijden voor deze terugkeerpatroon worden beïnvloed door factoren zoals latentie tijdens opslagoproepen.

Bekijk de volgende documentatie voor meer informatie:

Terugkeerpatroon voor triggers op basis van verbindingen

In terugkerende triggers op basis van verbindingen, zoals Office 365 Outlook, is de planning niet het enige stuurprogramma dat de uitvoering bepaalt. De tijdzone bepaalt alleen de initiële begintijd. Volgende uitvoeringen zijn afhankelijk van het terugkeerschema, de laatste uitvoering van de trigger en andere factoren die ertoe kunnen leiden dat uitvoeringstijden veranderen of onverwacht gedrag produceren, bijvoorbeeld:

  • Of de trigger toegang heeft tot een server met meer gegevens, die de trigger onmiddellijk probeert op te halen.
  • Fouten of nieuwe pogingen die door de trigger worden onderkend.
  • Latentie tijdens opslagoproepen.
  • De opgegeven planning niet handhaven wanneer zomertijd (DST) begint en eindigt.
  • Andere factoren die van invloed kunnen zijn op de volgende run time.

Bekijk de volgende documentatie voor meer informatie:

Problemen met terugkeerpatroon oplossen

Probeer de volgende oplossingen om ervoor te zorgen dat uw werkstroom wordt uitgevoerd op de opgegeven begintijd en geen terugkeerpatroon mist, met name wanneer de frequentie in dagen of langer is:

  • Wanneer DST van kracht wordt, past u het terugkeerpatroon handmatig aan zodat uw werkstroom op het verwachte tijdstip blijft worden uitgevoerd. Anders verschuift de begintijd één uur vooruit wanneer DST wordt gestart en één uur terug wanneer DST eindigt. Bekijk Terugkeerpatroon voor zomer- en standaardtijd voor meer informatie en voorbeelden.

  • Als u een trigger Terugkeerpatroon gebruikt, geeft u een tijdzone, een begindatum en begintijd op. Daarnaast moet u specifieke tijden configureren om volgende terugkeerpatroon uit te voeren in de eigenschappen Op deze uren en Op deze minuten, die alleen beschikbaar zijn voor de frequenties Dag en Week. Bepaalde tijdvensters kunnen echter nog steeds problemen veroorzaken wanneer de tijd verschuift.

  • Overweeg het gebruik van een sliding window-trigger in plaats van een terugkeerpatroontrigger om gemiste terugkeerpatroon te voorkomen.

Aangepaste API's en connectors

Als u API's wilt aanroepen die aangepaste code uitvoeren of die niet beschikbaar zijn als connectors, kunt u het Logic Apps-platform uitbreiden door aangepaste code API Apps. U kunt ook aangepaste connectors maken voor alle REST- of SOAP-API's, waardoor deze API's beschikbaar zijn voor elke logische app in uw Azure-abonnement. Als u aangepaste connectors API Apps connectors openbaar wilt maken voor iedereen die u in Azure kunt gebruiken, kunt u connectors indienen voor Microsoft-certificering.

ISE en connectors

Voor werkstromen die directe toegang tot resources in een virtueel Azure-netwerk nodig hebben, kunt u een speciale ISE (Integration Service Environment) maken waar u uw werkstromen kunt bouwen, implementeren en uitvoeren op toegewezen resources. Voor meer informatie over het maken van ISE's bekijkt Verbinding maken naar virtuele Azure-netwerken van Azure Logic Apps.

Aangepaste connectors die in een ISE zijn gemaakt, werken niet met de on-premises gegevensgateway. Deze connectors hebben echter rechtstreeks toegang tot on-premises gegevensbronnen die zijn verbonden met een virtueel Azure-netwerk dat als host voor de ISE wordt gebruikt. Logische apps in een ISE hebben de gegevensgateway dus waarschijnlijk niet nodig tijdens de communicatie met deze resources. Als u aangepaste connectors hebt die u buiten een ISE hebt gemaakt waarvoor de on-premises gegevensgateway is vereist, kunnen logische apps in een ISE deze connectors gebruiken.

Wanneer u in de Logic Apps Designer door de ingebouwde triggers en acties of beheerde connectors bladert die u wilt gebruiken voor logische apps in een ISE, wordt het core-label weergegeven op ingebouwde triggers en acties, terwijl het ISE-label wordt weergegeven op beheerde connectors die zijn ontworpen om te werken met een ISE.

Voorbeeld van CORE-connector

CORE

Ingebouwde triggers en acties met dit label worden uitgevoerd in dezelfde ISE als uw logische apps.

Voorbeeld van ISE-connector

ISE

Beheerde connectors met dit label worden uitgevoerd in dezelfde ISE als uw logische apps.

Als u een on-premises systeem hebt dat is verbonden met een virtueel Azure-netwerk, biedt een ISE uw werkstromen rechtstreeks toegang tot dat systeem zonder de on-premises gegevensgateway te gebruiken. In plaats daarvan kunt u de ISE-connector van dat systeem gebruiken, indien beschikbaar, een HTTP-actie of een aangepaste connector.

Gebruik de on-premises gegevensgateway voor on-premises systemen die geen ISE-connectors hebben. Als u beschikbare ISE-connectors wilt vinden, bekijkt u ISE-connectors.

Voorbeeld van een niet-ISE-connector

Geen label

Alle andere connectors zonder een label, die u kunt blijven gebruiken, worden uitgevoerd in de globale, multiten tenant Logic Apps service.

Bekende problemen

De volgende tabel bevat bekende problemen met Logic Apps connectors.

Foutbericht Beschrijving Oplossing
Error: BadGateway. Client request id: '{GUID}' Deze fout wordt veroorzaakt door het bijwerken van de tags in een logische app waarbij een of meer verbindingen geen OAuth-verificatie van Azure Active Directory (Azure AD) ondersteunen, zoals SFTP ad SQL, en deze verbindingen verbreken. Om dit gedrag te voorkomen, moet u deze tags niet bijwerken.

Volgende stappen