Wat zijn connectors in Azure Logic Apps?

Wanneer u een werkstroom bouwt met behulp van Azure Logic Apps, kunt u een connector gebruiken om te werken met gegevens, gebeurtenissen en resources in andere apps, services, systemen en platforms, zonder code te schrijven. Een connector biedt een of meer vooraf gemaakte bewerkingen, die u als stappen in uw werkstroom gebruikt.

In een connector is elke bewerking een triggervoorwaarde waarmee een werkstroom wordt gestart of een volgende actie die een specifieke taak uitvoert, samen met eigenschappen die u kunt configureren. Hoewel veel connectors zowel triggers als acties hebben, bieden sommige connectors alleen triggers, terwijl andere alleen acties bieden.

In Azure Logic Apps zijn connectors beschikbaar in een ingebouwde versie, beheerde versie of beide. Veel connectors vereisen meestal dat u eerst een verbinding met de onderliggende service of het onderliggende systeem maakt en configureert, meestal zodat u toegang tot een gebruikersaccount kunt verifiëren. Als er geen connector beschikbaar is voor de service of het systeem waartoe u toegang wilt hebben, kunt u een aanvraag verzenden met behulp van de algemene HTTP-bewerking of u kunt een aangepaste connector maken.

Dit overzicht biedt een inleiding op hoog niveau tot connectors en hoe ze in het algemeen werken. Zie de volgende documentatie voor meer informatie over de connector:

• overzicht van Verbinding maken ors voor services zoals Power Automate en Power Apps
• Overzicht van ingebouwde connectors voor Azure Logic Apps
• Overzicht van beheerde connectors voor Azure Logic Apps
• Naslaginformatie over beheerde connectors voor Azure Logic Apps

Ingebouwde connectors versus beheerde connectors

In Azure Logic Apps zijn connectors ingebouwd of beheerd. Sommige connectors hebben beide versies. De beschikbare versies zijn afhankelijk van of u een werkstroom voor logische verbruiks-apps maakt die wordt uitgevoerd in Azure Logic Apps met meerdere tenants of een standaardwerkstroom voor logische apps die wordt uitgevoerd in Azure Logic Apps met één tenant. Zie Resourcetypen en verschillen in hostomgevingen voor meer informatie over resourcetypen voor logische apps.

• Ingebouwde connectors zijn ontworpen om rechtstreeks en systeemeigen te worden uitgevoerd in Azure Logic Apps.

• Beheerde connectors worden door Microsoft geïmplementeerd, gehost en beheerd in Azure. Beheerde connectors bieden meestal een proxy of een wrapper rond een API die door de onderliggende service of het systeem wordt gebruikt om te communiceren met Azure Logic Apps.

  • In een werkstroom Verbruik worden beheerde connectors weergegeven in de ontwerpfunctie onder de labels Standard of Enterprise , op basis van hun prijsniveau.

  • In een Standaardwerkstroom worden alle beheerde connectors weergegeven in de ontwerpfunctie onder het Azure-label .

Zie de volgende documentatie voor meer informatie:

• Prijs- en factureringsmodellen in Azure Logic Apps
• Prijsinformatie voor Azure Logic Apps

Triggers

Een trigger geeft de voorwaarde aan waaraan moet worden voldaan voordat de werkstroom kan worden gestart en is altijd de eerste stap in elke werkstroom. Elke trigger volgt ook een specifiek schietpatroon waarmee wordt bepaald hoe de trigger wordt bewaakt en reageert op gebeurtenissen. Meestal volgt een trigger een polling-patroon of een pushpatroon . Soms zijn beide triggerversies beschikbaar.

• Poll-triggers controleren regelmatig een specifieke service of 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 plaatsvindt, 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 - of webhooktriggers luisteren naar nieuwe gegevens of naar een gebeurtenis, zonder polling. Wanneer er nieuwe gegevens beschikbaar zijn of wanneer de gebeurtenis plaatsvindt, maken deze triggers een nieuw exemplaar van uw werkstroom en voeren ze deze uit. Deze nieuwe instantie kan vervolgens de gegevens gebruiken die als invoer worden doorgegeven.

Stel dat u een werkstroom wilt bouwen die wordt uitgevoerd wanneer een bestand wordt geüpload naar uw FTP-server. Als eerste stap in uw werkstroom kunt u de FTP-trigger toevoegen met de naam Wanneer een bestand wordt toegevoegd of gewijzigd. Dit volgt een polling-patroon. Vervolgens geeft u de planning op om regelmatig te controleren op upload-gebeurtenissen.

Wanneer de trigger wordt geactiveerd, geeft de trigger meestal gebeurtenisuitvoer door voor volgende acties die moeten worden verwezen en gebruikt. Voor het FTP-voorbeeld voert de trigger automatisch informatie uit, zoals de bestandsnaam en het pad. U kunt de trigger ook instellen om de bestandsinhoud op te nemen. Als u deze gegevens wilt verwerken, moet u dus acties toevoegen aan uw werkstroom.

Acties

Een actie geeft een taak op die moet worden uitgevoerd en wordt altijd weergegeven als een volgende stap in de werkstroom. U kunt meerdere acties in uw werkstroom gebruiken. U kunt bijvoorbeeld de werkstroom starten met een SQL Server-trigger waarmee wordt gecontroleerd op nieuwe klantgegevens in een SQL-database. Na de trigger kan uw werkstroom een SQL Server-actie hebben waarmee de klantgegevens worden opgehaald. Na deze SQL Server-actie kan uw werkstroom een andere actie gebruiken waarmee de gegevens worden verwerkt, bijvoorbeeld een gegevensbewerkingsactie waarmee een CSV-tabel wordt gemaakt.

Verbindingsmachtigingen

Voordat u resources, werkstromen en de bijbehorende verbindingen voor logische apps kunt maken of beheren, hebt u specifieke machtigingen nodig in een werkstroom voor logische apps. Zie Secure Operations - Secure access and data in Azure Logic Apps (Beveiligde toegang en gegevens in Azure Logic Apps) voor meer informatie over deze machtigingen.

Verbinding maken maken, configureren en verificatie

Voordat u de bewerkingen van een connector in uw werkstroom kunt gebruiken, moeten veel connectors eerst een verbinding maken met de doelservice of het doelsysteem. Als u een verbinding wilt maken vanuit de werkstroomontwerper, 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 en deze kan gebruiken, moet u een verbinding met dat account autoriseren. Voor sommige ingebouwde connectors en beheerde connectors kunt u een beheerde identiteit instellen en gebruiken voor verificatie in plaats van uw referenties op te geven.

Hoewel u verbindingen binnen een werkstroom maakt, zijn deze verbindingen eigenlijk afzonderlijke Azure-resources met hun eigen resourcedefinities. Als u deze verbindingsresourcedefinities wilt bekijken, volgt u deze stappen op basis van of u een verbruikswerkstroom of een standaardwerkstroom hebt:

• Verbruik

  • Als u deze verbindingen in Azure Portal wilt weergeven en beheren, raadpleegt u Verbindingen voor verbruikswerkstromen weergeven in Azure Portal.

  • Als u deze verbindingen in Visual Studio wilt bekijken en beheren, raadpleegt u Werkstromen voor verbruik beheren met Visual Studio en downloadt u uw logische app-resource van Azure naar Visual Studio.

  Zie Verbinding maken ion-resourcedefinities voor meer informatie over verbindingsresourcedefinities voor werkstromen voor verbruik.

• Standaard

  • Als u deze verbindingen in Azure Portal wilt weergeven en beheren, raadpleegt u Verbindingen voor Standaardwerkstromen weergeven in Azure Portal.

  • Zie Uw werkstroom voor logische apps weergeven in Visual Studio Code om deze verbindingen weer te geven en te beheren. Het bestand connections.json bevat de vereiste configuratie voor de verbindingen die zijn gemaakt door connectors.

Verbinding maken ionbeveiliging en -versleuteling

Verbinding maken configuratiegegevens, zoals serveradres, gebruikersnaam en wachtwoord, referenties en geheimen, worden versleuteld en opgeslagen in de beveiligde Azure-omgeving. Deze informatie kan alleen worden gebruikt in logische app-resources en door clients die machtigingen hebben voor de verbindingsresource, die wordt afgedwongen met behulp van gekoppelde toegangscontroles. Verbinding maken ions die gebruikmaken van Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), zoals Office 365, Salesforce en GitHub, vereisen dat u zich aanmeldt, maar Azure Logic Apps slaat alleen toegang tot tokens op als geheimen, niet aanmeldingsreferenties.

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

Notitie

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

Zie Beveiligde toegang en gegevens in Azure Logic Apps voor meer informatie over het beveiligen van werkstromen en verbindingen voor logische apps.

Firewalltoegang voor verbindingen

Als u een firewall gebruikt die verkeer beperkt en uw werkstromen voor logische apps via die firewall moeten communiceren, moet u uw firewall zo instellen dat toegang wordt toegestaan voor zowel de binnenkomende als uitgaande IP-adressen die worden gebruikt door het Azure Logic Apps-platform of -runtime in de Azure-regio waar uw werkstromen voor logische apps 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-resource. Zie Firewall-configuratie voor meer informatie.

Aangepaste connectors en API's

In werkstromen voor verbruik voor Azure Logic Apps met meerdere tenants kunt u Swagger- of SOAP-API's aanroepen die niet beschikbaar zijn als out-of-the-box-connectors. U kunt ook aangepaste code uitvoeren door aangepaste API-apps te maken. Zie de volgende documentatie voor meer informatie:

• Aangepaste connectors op basis van Swagger of SOAP voor werkstromen voor verbruik

• Maak een aangepaste connector op basis van Swagger of SOAP, waardoor deze API's beschikbaar zijn voor elke werkstroom voor logische apps voor verbruik in uw Azure-abonnement.

  Als u uw aangepaste connector openbaar wilt maken voor iedereen die in Azure kan worden gebruikt, dient u uw connector in voor Microsoft-certificering.

• Aangepaste API-apps maken

In Standard-werkstromen voor Azure Logic Apps met één tenant kunt u systeemeigen op serviceprovider gebaseerde aangepaste ingebouwde connectors maken die beschikbaar zijn voor elke standaardwerkstroom voor logische apps. Zie de volgende documentatie voor meer informatie:

• Aangepaste ingebouwde connectors op basis van serviceproviders voor standaardwerkstromen

• Aangepaste ingebouwde connectors op basis van serviceproviders maken voor standaardwerkstromen

ISE en connectors

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

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 fungeert voor de ISE. Logische app-werkstromen in een ISE hebben dus waarschijnlijk niet de gegevensgateway nodig bij het communiceren met deze resources. Als u aangepaste connectors hebt die u buiten een ISE hebt gemaakt waarvoor de on-premises gegevensgateway is vereist, kunnen werkstromen in een ISE deze connectors gebruiken.

Wanneer u in de ontwerpfunctie voor werkstromen bladert door de ingebouwde connectors of beheerde connectors die u wilt gebruiken voor werkstromen in een ISE, wordt het CORE-label weergegeven op ingebouwde connectors, terwijl het ISE-label wordt weergegeven op beheerde connectors die zijn ontworpen voor gebruik met een ISE .

CORE

Ingebouwde connectors met dit label worden uitgevoerd in dezelfde ISE als uw werkstromen.

ISE

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

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. Raadpleeg ISE-connectors om beschikbare ISE-connectors te vinden.

Geen label

Alle andere connectors zonder label, die u kunt blijven gebruiken, worden uitgevoerd in de globale Logic Apps-service voor meerdere tenants.

Bekende problemen

De volgende tabel bevat bekende problemen voor connectors in Azure Logic Apps:

Foutbericht	Omschrijving	Oplossing
Error: BadGateway. Client request id: '{GUID}'	Deze fout is het gevolg van het bijwerken van de tags in een logische app-resource waarbij een of meer verbindingen geen ondersteuning bieden voor OAuth-verificatie van Microsoft Entra ID, zoals SFTP ad SQL, waardoor deze verbindingen worden onderbroken.	Om dit gedrag te voorkomen, vermijdt u het bijwerken van deze tags.

Volgende stappen

Een werkstroom voor logische apps voor verbruik maken - Azure Portal

Een werkstroom voor een standaard logische app maken - Azure Portal