Externe HTTP- of HTTPS-eindpunten aanroepen vanuit werkstromen in Azure Logic Apps

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

Voor sommige scenario's is het mogelijk dat u een werkstroom voor logische apps maakt waarmee uitgaande aanvragen naar eindpunten op andere services of systemen via HTTP of HTTPS worden verzonden. Stel dat u een service-eindpunt voor uw website wilt controleren door dat eindpunt te controleren op een specifiek schema. Wanneer een specifieke gebeurtenis op dat eindpunt plaatsvindt, zoals uw website die uitvalt, wordt uw werkstroom geactiveerd en worden de acties in die werkstroom uitgevoerd.

Notitie

Als u een werkstroom wilt maken die in plaats daarvan binnenkomende HTTPS-aanroepen ontvangt en erop reageert, raadpleegt u Werkstromen maken die u kunt aanroepen, activeren of nesten met behulp van HTTPS-eindpunten in Azure Logic Apps en de ingebouwde aanvraagtrigger en antwoordactie.

Deze handleiding laat zien hoe u de HTTP-trigger en HTTP-actie gebruikt, zodat uw werkstroom uitgaande aanroepen naar andere services en systemen kan verzenden, bijvoorbeeld:

• Als u een eindpunt volgens een terugkerend schema wilt controleren of peilen , voegt u de HTTP-trigger toe als de eerste stap in uw werkstroom. Telkens wanneer de trigger het eindpunt controleert, roept de trigger een aanvraag aan of verzendt deze een aanvraag naar het eindpunt. Het antwoord van het eindpunt bepaalt of uw werkstroom wordt uitgevoerd. De trigger geeft inhoud van het antwoord van het eindpunt door aan de acties in uw werkstroom.

• Als u een eindpunt wilt aanroepen vanaf een willekeurige locatie in uw werkstroom, voegt u de HTTP-actie toe. Het antwoord van het eindpunt bepaalt hoe de resterende acties van uw werkstroom worden uitgevoerd.

Vereisten

• Een Azure-account en -abonnement. Als u nog geen abonnement op Azure hebt, registreer u dan nu voor een gratis Azure-account.

• De URL voor het doeleindpunt dat u wilt aanroepen

• De werkstroom van de logische app van waaruit u het doeleindpunt wilt aanroepen. Als u met de HTTP-trigger wilt beginnen, hebt u een lege werkstroom nodig. Als u de HTTP-actie wilt gebruiken, start u de werkstroom met een gewenste trigger. In dit voorbeeld wordt de HTTP-trigger gebruikt als eerste stap.

Verbinding maken of technische naslaginformatie

Zie de volgende secties voor technische informatie over trigger- en actieparameters:

• HTTP-triggerparameters
• HTTP-actieparameters

Een HTTP-trigger toevoegen

Deze ingebouwde trigger maakt een HTTP-aanroep naar de opgegeven URL voor een eindpunt en retourneert een antwoord.

Standaard

1. Open in Azure Portal uw resource voor de logische standaard-app en lege werkstroom in de ontwerpfunctie.

2. Volg deze algemene stappen om de ingebouwde trigger met de naam HTTP toe te voegen aan uw werkstroom.

   In dit voorbeeld wordt de naam van de trigger gewijzigd in HTTP-trigger- Eindpunt-URL aanroepen, zodat de trigger een meer beschrijvende naam heeft. In het voorbeeld wordt later ook een HTTP-actie toegevoegd en moeten de namen van bewerkingen in uw werkstroom uniek zijn.

3. Geef de waarden op voor de HTTP-triggerparameters die u wilt opnemen in de aanroep naar het doeleindpunt. Stel het terugkeerpatroon in voor hoe vaak de trigger het doeleindpunt moet controleren.

   Als u een ander verificatietype dan Geen selecteert, verschillen de verificatie-instellingen op basis van uw selectie. Zie de volgende onderwerpen voor meer informatie over verificatietypen die beschikbaar zijn voor HTTP:

   • Verificatie toevoegen aan uitgaande oproepen
   • Toegang tot resources verifiëren met beheerde identiteiten

4. Als u andere beschikbare parameters wilt toevoegen, opent u de lijst geavanceerde parameters en selecteert u de gewenste parameters.

5. Voeg eventuele andere acties toe die u wilt uitvoeren wanneer de trigger wordt geactiveerd.

6. Sla uw werkstroom op als u gereed bent. Selecteer in de werkbalk van de ontwerper Opslaan.

Verbruik

1. Open in Azure Portal uw logische app Verbruik en een lege werkstroom in de ontwerpfunctie.

2. Volg deze algemene stappen om de ingebouwde trigger met de naam HTTP toe te voegen aan uw werkstroom.

   In dit voorbeeld wordt de naam van de trigger gewijzigd in HTTP-trigger- Eindpunt-URL aanroepen, zodat de trigger een meer beschrijvende naam heeft. In het voorbeeld wordt later ook een HTTP-actie toegevoegd en moeten de namen van bewerkingen in uw werkstroom uniek zijn.

3. Geef de waarden op voor de HTTP-triggerparameters die u wilt opnemen in de aanroep naar het doeleindpunt. Stel het terugkeerpatroon in voor hoe vaak de trigger het doeleindpunt moet controleren.

   Als u een ander verificatietype dan Geen selecteert, verschillen de verificatie-instellingen op basis van uw selectie. Zie de volgende onderwerpen voor meer informatie over verificatietypen die beschikbaar zijn voor HTTP:

   • Verificatie toevoegen aan uitgaande oproepen
   • Toegang tot resources verifiëren met beheerde identiteiten

4. Als u andere beschikbare parameters wilt toevoegen, opent u de lijst Nieuwe parameters toevoegen en selecteert u de gewenste parameters.

5. Voeg eventuele andere acties toe die u wilt uitvoeren wanneer de trigger wordt geactiveerd.

6. Sla uw werkstroom op als u gereed bent. Selecteer in de werkbalk van de ontwerper Opslaan.

Een HTTP-actie toevoegen

Deze ingebouwde actie maakt een HTTP-aanroep naar de opgegeven URL voor een eindpunt en retourneert een antwoord.

Standaard

1. Open in Azure Portal uw logische app voor verbruik en werkstroom in de ontwerpfunctie.

   In dit voorbeeld wordt de HTTP-trigger gebruikt die in de vorige sectie is toegevoegd als eerste stap.

2. Volg deze algemene stappen om de ingebouwde actie HTTP toe te voegen aan uw werkstroom.

   In dit voorbeeld wordt de naam van de actie gewijzigd in http-actie: eindpunt-URL aanroepen, zodat de stap een beschrijvende naam heeft. Ook moeten bewerkingsnamen in uw werkstroom uniek zijn.

3. Geef de waarden op voor de HTTP-actieparameters die u wilt opnemen in de aanroep naar het doeleindpunt.

   Als u een ander verificatietype dan Geen selecteert, verschillen de verificatie-instellingen op basis van uw selectie. Zie de volgende onderwerpen voor meer informatie over verificatietypen die beschikbaar zijn voor HTTP:

   • Verificatie toevoegen aan uitgaande oproepen
   • Toegang tot resources verifiëren met beheerde identiteiten

4. Als u andere beschikbare parameters wilt toevoegen, opent u de lijst geavanceerde parameters en selecteert u de gewenste parameters.

5. Sla uw werkstroom op als u gereed bent. Selecteer in de werkbalk van de ontwerper Opslaan.

Verbruik

1. Open in Azure Portal uw logische app voor verbruik en werkstroom in de ontwerpfunctie.

   In dit voorbeeld wordt de HTTP-trigger gebruikt die in de vorige sectie is toegevoegd als eerste stap.

2. Volg deze algemene stappen om de ingebouwde actie HTTP toe te voegen aan uw werkstroom.

   In dit voorbeeld wordt de naam van de actie gewijzigd in http-actie: eindpunt-URL aanroepen, zodat de stap een beschrijvende naam heeft. Ook moeten bewerkingsnamen in uw werkstroom uniek zijn.

3. Geef de waarden op voor de HTTP-actieparameters die u wilt opnemen in de aanroep naar het doeleindpunt.

   Als u een ander verificatietype dan Geen selecteert, verschillen de verificatie-instellingen op basis van uw selectie. Zie de volgende onderwerpen voor meer informatie over verificatietypen die beschikbaar zijn voor HTTP:

   • Verificatie toevoegen aan uitgaande oproepen
   • Toegang tot resources verifiëren met beheerde identiteiten

4. Als u andere beschikbare parameters wilt toevoegen, opent u de lijst Nieuwe parameters toevoegen en selecteert u de gewenste parameters.

5. Sla uw werkstroom op als u gereed bent. Selecteer in de werkbalk van de ontwerper Opslaan.

Uitvoer van triggers en acties

Hier vindt u meer informatie over de uitvoer van een HTTP-trigger of -actie, die de volgende informatie retourneert:

Eigenschap	Type	Description
headers	JSON-object	De headers van de aanvraag
body	JSON-object	Het object met de hoofdtekstinhoud van de aanvraag
status code	Geheel getal	De statuscode van de aanvraag

Statuscode	Beschrijving
200	OK
202	Geaccepteerd
400	Ongeldige aanvraag
401	Niet geautoriseerd
403	Verboden
404	Niet gevonden
500	Interne serverfout. Er is een onbekende fout opgetreden.

URL-beveiliging voor uitgaande oproepen

Voor informatie over versleuteling, beveiliging en autorisatie voor uitgaande aanroepen vanuit uw werkstroom, zoals Transport Layer Security (TLS), voorheen SSL (Secure Sockets Layer), zelfondertekende certificaten of Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) raadpleegt u Beveiligde toegang en gegevens - Toegang tot uitgaande aanroepen naar andere services en systemen.

Verificatie voor omgeving met één tenant

Als u een standaardresource voor logische apps in Azure Logic Apps met één tenant hebt en u een HTTP-bewerking wilt gebruiken met een van de volgende verificatietypen, moet u de extra installatiestappen voor het bijbehorende verificatietype voltooien. Anders mislukt de aanroep.

• TLS/SSL-certificaat: voeg de app-instelling WEBSITE_LOAD_ROOT_CERTIFICATEStoe en stel de waarde in op de vingerafdruk voor uw TLS/SSL-certificaat.

• Clientcertificaat of Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) met het referentietype Certificaat: Voeg de app-instelling WEBSITE_LOAD_USER_PROFILEtoe en stel de waarde in op 1.

TLS/SSL-certificaatverificatie

1. Voeg in de app-instellingen van uw logische app-resource de app-instelling toe of werk deze bij. WEBSITE_LOAD_ROOT_CERTIFICATES

2. Geef voor de instellingswaarde de vingerafdruk voor uw TLS/SSL-certificaat op als het basiscertificaat dat moet worden vertrouwd.

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>"

Als u bijvoorbeeld in Visual Studio Code werkt, voert u de volgende stappen uit:

1. Open het local.settings.json-bestand van uw logische app-project.

2. Voeg in het Values JSON-object de instelling toe of werk deze WEBSITE_LOAD_ROOT_CERTIFICATES bij:

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>",
         <...>
      }
   }
   

   Notitie

   Voer de volgende stappen uit om de vingerafdruk te vinden:

   1. Selecteer in het resourcemenu van uw logische app onder Instellingen TLS/SSL-instellingen>Private Key Certificates (.pfx) of Certificaten voor openbare sleutel (.cer).

   2. Zoek het certificaat dat u wilt gebruiken en kopieer de vingerafdruk.

   Raadpleeg de vingerafdruk zoeken - Azure-app Service voor meer informatie.

Raadpleeg de volgende documentatie voor meer informatie:

• Host- en app-instellingen voor logische apps bewerken in Azure Logic Apps met één tenant
• Persoonlijke clientcertificaten - Azure-app-service

Clientcertificaat of Microsoft Entra ID OAuth met verificatie van het referentietype Certificaat

1. Voeg in de app-instellingen van uw logische app-resource de app-instelling toe of werk deze bij. WEBSITE_LOAD_USER_PROFILE

2. Geef voor de instellingswaarde op 1.

   "WEBSITE_LOAD_USER_PROFILE": "1"

Als u bijvoorbeeld in Visual Studio Code werkt, voert u de volgende stappen uit:

1. Open het local.settings.json-bestand van uw logische app-project.

2. Voeg in het Values JSON-object de instelling toe of werk deze WEBSITE_LOAD_USER_PROFILE bij:

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_USER_PROFILE": "1",
         <...>
      }
   }
   

Raadpleeg de volgende documentatie voor meer informatie:

• Host- en app-instellingen voor logische apps bewerken in Azure Logic Apps met één tenant
• Persoonlijke clientcertificaten - Azure-app-service

Inhoud met multipart-/formuliergegevenstype

Als u inhoud wilt verwerken die type HTTP-aanvragen heeft multipart/form-data , kunt u een JSON-object met de $content-type en $multipart kenmerken toevoegen aan de hoofdtekst van de HTTP-aanvraag met behulp van deze indeling.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

Stel dat u een werkstroom hebt waarmee een HTTP POST-aanvraag voor een Excel-bestand naar een website wordt verzonden met behulp van de API van die site, die ondersteuning biedt voor het multipart/form-data type. In het volgende voorbeeld ziet u hoe deze actie kan worden weergegeven:

Standaardwerkstroom

Werkstroom verbruik

Hier volgt hetzelfde voorbeeld met de JSON-definitie van de HTTP-actie in de onderliggende werkstroomdefinitie:

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

Inhoud met het type application/x-www-form-urlencoded

Als u formulier-URLencoded gegevens wilt opgeven in de hoofdtekst van een HTTP-aanvraag, moet u opgeven dat de gegevens het application/x-www-form-urlencoded inhoudstype hebben. Voeg de content-type header toe in de HTTP-trigger of -actie. Stel de headerwaarde in op application/x-www-form-urlencoded.

Stel dat u een logische app hebt waarmee een HTTP POST-aanvraag wordt verzonden naar een website die ondersteuning biedt voor het application/x-www-form-urlencoded type. Deze actie kan er als volgt uitzien:

Standaardwerkstroom

Werkstroom verbruik

Asynchroon gedrag van aanvraag-antwoord

Voor stateful werkstromen in azure Logic Apps met meerdere tenants en één tenant volgen alle HTTP-acties het standaard asynchrone bewerkingspatroon als standaardgedrag . Dit patroon geeft aan dat na een HTTP-actie een aanvraag wordt aangeroepen of verzonden naar een eindpunt, service, systeem of API, de ontvanger onmiddellijk een antwoord '202 GEACCEPTEERD' retourneert. Deze code bevestigt dat de ontvanger de aanvraag heeft geaccepteerd, maar nog niet is verwerkt. Het antwoord kan een location header bevatten die de URI en een vernieuwings-id aangeeft die de beller kan gebruiken om de status van de asynchrone aanvraag te controleren totdat de ontvanger de verwerking stopt en een geslaagd antwoord van 200 OK of een ander niet-202-antwoord retourneert. De beller hoeft echter niet te wachten tot de aanvraag is verwerkt en kan de volgende actie blijven uitvoeren. Zie Asynchrone microservice-integratie dwingt microserviceautonomie af voor meer informatie.

Voor stateless werkstromen in Azure Logic Apps met één tenant gebruiken HTTP-acties niet het asynchrone bewerkingspatroon. In plaats daarvan worden ze alleen synchroon uitgevoerd, worden de reactie '202 GEACCEPTEERD' als zodanig geretourneerd en gaat u verder met de volgende stap in de uitvoering van de werkstroom. Als het antwoord een location header bevat, wordt de opgegeven URI niet door een staatloze werkstroom gecontroleerd om de status te controleren. Als u het standaard asynchrone bewerkingspatroon wilt volgen, gebruikt u in plaats daarvan een stateful werkstroom.

• De onderliggende JSON-definitie (JavaScript Object Notation) van de HTTP-actie volgt impliciet het asynchrone bewerkingspatroon.

• De HTTP-actie, maar niet geactiveerd, heeft een Asynchrone patrooninstelling , die standaard is ingeschakeld. Deze instelling geeft aan dat de beller niet wacht tot de verwerking is voltooid en verder kan gaan met de volgende actie, maar de status blijft controleren totdat de verwerking stopt. Als deze instelling is uitgeschakeld, geeft deze instelling aan dat de beller wacht tot de verwerking is voltooid voordat de volgende actie wordt uitgevoerd.

  Als u de instelling Asynchroon patroon wilt vinden, volgt u deze stappen op basis van of u een werkstroom standaard of verbruik hebt:

  Standaardwerkstroom*

  1. Selecteer de HTTP-actie in de werkstroomontwerper. Selecteer Instellingen in het informatievenster dat wordt geopend.

  2. Zoek onder Netwerken de instelling Asynchroon patroon .

  Werkstroom verbruik

  1. Selecteer in de werkstroomontwerper op de titelbalk van de HTTP-actie het beletselteken (...), waarmee de instellingen van de actie worden geopend.

  2. Zoek de instelling Asynchroon patroon .

Asynchrone bewerkingen uitschakelen

Soms wilt u het asynchrone gedrag van de HTTP-actie in specifieke scenario's uitschakelen, bijvoorbeeld wanneer u het volgende wilt doen:

• HTTP-time-outs voorkomen voor langlopende taken
• Locatiekoppen controleren uitschakelen

Asynchrone patrooninstelling uitschakelen

Standaard

1. Selecteer in de werkstroomontwerper de HTTP-actie en selecteer Instellingen in het informatievenster dat wordt geopend.

2. Zoek onder Netwerken de instelling Asynchroon patroon . Schakel de instelling uit als deze optie is ingeschakeld.

Verbruik

1. Selecteer in de werkstroomontwerper op de titelbalk van de HTTP-actie het beletselteken (...), waarmee de instellingen van de actie worden geopend.

2. Zoek de instelling Asynchroon patroon , schakel de instelling uit als deze is ingeschakeld en selecteer Gereed.

Asynchroon patroon uitschakelen in de JSON-definitie van de actie

Voeg in de onderliggende JSON-definitie van de HTTP-actie de "DisableAsyncPattern" bewerkingsoptie toe aan de definitie van de actie, zodat de actie het synchrone bewerkingspatroon volgt. Zie ook Acties uitvoeren in een synchrone bewerkingspatroon voor meer informatie.

HTTP-time-outs voorkomen voor langlopende taken

HTTP-aanvragen hebben een time-outlimiet. Als u een langlopende HTTP-actie hebt die een time-out heeft vanwege deze limiet, hebt u de volgende opties:

• Schakel het asynchrone bewerkingspatroon van de HTTP-actie uit, zodat de actie niet voortdurend de status van de aanvraag controleert of controleert. In plaats daarvan wacht de actie totdat de ontvanger reageert met de status en resultaten nadat de aanvraag is verwerkt.

• Vervang de HTTP-actie door de HTTP-webhookactie, die wacht totdat de ontvanger reageert met de status en resultaten nadat de aanvraag is verwerkt.

Interval tussen nieuwe pogingen instellen met de header Opnieuw proberen na

Als u het aantal seconden tussen nieuwe pogingen wilt opgeven, kunt u de Retry-After header toevoegen aan het HTTP-actieantwoord. Als het doeleindpunt bijvoorbeeld de 429 - Too many requests statuscode retourneert, kunt u een langer interval opgeven tussen nieuwe pogingen. De Retry-After header werkt ook met de 202 - Accepted statuscode.

Hier volgt hetzelfde voorbeeld waarin het HTTP-actieantwoord wordt weergegeven dat het volgende bevat Retry-After:

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

Ondersteuning voor paginering

Soms reageert de doelservice door de resultaten één pagina tegelijk te retourneren. Als in het antwoord de volgende pagina wordt opgegeven met de eigenschap nextLink of @odata.nextLink , kunt u de instelling Paginering inschakelen voor de HTTP-actie. Deze instelling zorgt ervoor dat de HTTP-actie deze koppelingen automatisch volgt en de volgende pagina opkrijgt. Als het antwoord echter de volgende pagina met een andere tag opgeeft, moet u mogelijk een lus toevoegen aan uw werkstroom. Laat deze lus die tag volgen en haal elke pagina handmatig op totdat de tag null is.

Locatiekoppen controleren uitschakelen

Sommige eindpunten, services, systemen of API's retourneren een 202 ACCEPTED antwoord dat geen header heeft location . Om te voorkomen dat een HTTP-actie voortdurend de status van de aanvraag controleert wanneer de location header niet bestaat, kunt u deze opties hebben:

• Schakel het asynchrone bewerkingspatroon van de HTTP-actie uit, zodat de actie niet voortdurend de status van de aanvraag controleert of controleert. In plaats daarvan wacht de actie totdat de ontvanger reageert met de status en resultaten nadat de aanvraag is verwerkt.

• Vervang de HTTP-actie door de HTTP-webhookactie, die wacht totdat de ontvanger reageert met de status en resultaten nadat de aanvraag is verwerkt.

Bekende problemen

Weggelaten HTTP-headers

Als een HTTP-trigger of -actie deze headers bevat, verwijdert Azure Logic Apps deze headers uit het gegenereerde aanvraagbericht zonder dat er een waarschuwing of fout wordt weergegeven:

• Accept-* kopteksten, met uitzondering van Accept-version
• Allow
• Content-* headers, met uitzondering van Content-Disposition, Content-Encodingen Content-Type, die worden gehonoreerd wanneer u de POST- en PUT-bewerkingen gebruikt. Azure Logic Apps verwijdert deze headers echter wanneer u de GET-bewerking gebruikt.
• Cookie header, maar Azure Logic Apps krijgt een waarde die u opgeeft met behulp van de eigenschap Cookie .
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-Encoding

Hoewel Azure Logic Apps u niet stopt met het opslaan van logische apps die gebruikmaken van een HTTP-trigger of actie met deze headers, negeert Azure Logic Apps deze headers.

Antwoordinhoud komt niet overeen met het verwachte inhoudstype

De HTTP-actie genereert een BadRequest-fout als de HTTP-actie de back-end-API aanroept met de Content-Type header ingesteld op application/json, maar het antwoord van de back-end bevat geen inhoud in JSON-indeling, waardoor interne validatie van JSON-indeling mislukt.

Volgende stappen

• Beheerde connectors voor Azure Logic Apps
• Ingebouwde connectors voor Azure Logic Apps