Delen via

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.

Opmerking

Als u een werkstroom wilt maken om binnenkomende HTTPS-aanroepen te ontvangen en erop te reageren, bekijk Werkstromen maken die u kunt aanroepen, activeren of nesten met behulp van HTTPS-eindpunten in Azure Logic Apps. Zie Ontvangen en reageren op binnenkomende HTTPS-aanroepen naar werkstromen in Azure Logic Apps om de ingebouwde trigger Aanvraag te gebruiken.

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 ingebouwde trigger met de naam HTTP toe als de eerste stap in uw werkstroom. Telkens wanneer de trigger het eindpunt controleert, doet de trigger een oproep of verzendt deze een verzoek 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 ingebouwde actie HTTP toe. Het antwoord van het eindpunt bepaalt hoe de resterende acties van uw werkstroom worden uitgevoerd.

Vereiste voorwaarden

Technische naslaggids voor connector

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

Een HTTP-trigger toevoegen

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

  1. Open in de Azure portal uw standaard logische app-resource.

  2. Selecteer in het zijbalkmenu van de resource onder Werkstromen de optie Werkstromen en selecteer vervolgens uw lege werkstroom.

  3. Selecteer in het zijbalkmenu van de werkstroom onder Extra de ontwerpfunctie om de werkstroom te openen.

  4. Voeg de ingebouwde HTTP-trigger toe aan uw werkstroom door de algemene stappen te volgen om een trigger toe te voegen.

    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.

  5. 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.

  6. Selecteer Verificatie in de lijst Geavanceerde parameters.

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

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

  8. Sla uw workflow op als u klaar bent. Selecteer in de werkbalk van de ontwerper Opslaan.

Een HTTP-actie toevoegen

Deze ingebouwde actie verzendt een HTTPS- of HTTP-aanroep naar de opgegeven URL voor een eindpunt en retourneert met een antwoord.

  1. Open in de Azure portal uw standaard logische app-resource.

  2. Selecteer in het zijbalkmenu van de resource onder Werkstromen de optie Werkstromen en selecteer vervolgens uw werkstroom.

  3. Selecteer in het zijbalkmenu van de werkstroom onder Extra de ontwerpfunctie om de werkstroom te openen.

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

  4. Voeg de ingebouwde HTTP-actie toe aan uw werkstroom door de algemene stappen te volgen om een actie toe te voegen.

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

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

  6. Selecteer Verificatie in de lijst Geavanceerde parameters.

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

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

  8. Sla uw workflow op als u klaar bent. Selecteer in de werkbalk van de ontwerper Opslaan.

Uitvoer van triggers en acties

Een HTTP-trigger of -actie voert de volgende informatie uit:

Vastgoed Typologie Beschrijving
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 Foute aanvraag
401 Niet geautoriseerd
403 Verboden
404 Niet gevonden
500 Interne serverfout. Er is een onbekende fout opgetreden.

URL-beveiliging voor uitgaande oproepen

Zie Access voor uitgaande aanroepen naar andere services en systemen voor informatie over versleuteling, beveiliging en autorisatie voor uitgaande aanroepen vanuit uw werkstroom, zoals Transport Layer Security (TLS), zelfondertekende certificaten of Microsoft Entra ID Open Authentication.

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-certificaatverificatie

  1. Voeg in de app-instellingen van uw logische app-resource de app-instelling toe of werk deze bij met de naam WEBSITE_LOAD_ROOT_CERTIFICATES. Zie App-instellingen beheren - local.settings.jsonvoor specifieke stappen.

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

    "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-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 een instelling toe of werk deze WEBSITE_LOAD_ROOT_CERTIFICATES bij.

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

Opmerking

Voer de volgende stappen uit om de vingerafdruk te vinden:

  • Selecteer Certificaten in het resourcemenu van uw logische app onder Instellingen.
  • Selecteer Eigen certificaten gebruiken (.pfx) of Certificaten voor openbare sleutels (.cer).
  • Zoek het certificaat dat u wilt gebruiken en kopieer de vingerafdruk.

Zie De vingerafdruk zoeken - Azure App Service voor meer informatie.

Zie App-instellingen beheren - local.settings.jsonvoor meer informatie.

Clientcertificaat of Microsoft Entra ID OAuth met verificatie van certificaatreferentietype

  1. Voeg in de app-instellingen van uw logische app-resource de app-instelling toe of werk deze bij met de naam WEBSITE_LOAD_USER_PROFILE. Zie voor specifieke stappen App-instellingen beheren - local.settings.json

  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 een instelling toe of werk deze WEBSITE_LOAD_USER_PROFILE bij.

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

Als u in Azure Portal werkt, opent u uw logische app. Selecteer omgevingsvariabelen onder Instellingen in het zijbalkmenu. Voeg onder App-instellingen de instelling toe of bewerk deze.

Inhoud met multipart-/formuliergegevenstype

Als u inhoud wilt verwerken die type HTTP-aanvragen heeft multipart/form-data , kunt u een JSON-object toevoegen dat de $content-type en $multipart kenmerken in de hoofdtekst van de HTTP-aanvraag bevat 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:

Schermopname van de werkstroom met HTTP-actie en formuliergegevens met meerdere onderdelen.

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 het content-type-header toe aan 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:

Schermopname die de werkstroom laat zien met HTTP-verzoek en de Content-Type-header ingesteld op application slash x-www-form-urlencoded.

Asynchroon gedrag van aanvraag-antwoord

Voor stateful werkstromen in zowel multitenant als single-tenant Azure Logic Apps volgen alle HTTP-gebaseerde acties het standaard asynchrone bewerkingspatroon als standaardgedrag. Dit patroon geeft aan dat nadat een HTTP-actie een aanvraag heeft aangeroepen of verzonden naar een eindpunt, service, systeem of API, de ontvanger onmiddellijk een antwoord van 202 GEACCEPTEERD retourneert. Deze code bevestigt dat de ontvanger de aanvraag heeft geaccepteerd, maar niet klaar is met verwerken. 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 stopt met verwerken en een 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 Synchrone versus asynchrone berichten 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, wordt de 202 GEACCEPTEERD as-isgeretourneerd en gaan ze verder naar de volgende stap in de workflow-uitvoering. Als het antwoord een location header bevat, peilt een staatloze werkstroom de opgegeven URI niet 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 van de HTTP-actie volgt impliciet het asynchrone bewerkingspatroon.

  • De HTTP-actie, maar niet de trigger, heeft een asynchrone patroon instelling, 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.

    De Asynchrone patrooninstelling zoeken:

    1. Selecteer de HTTP-actie in de werkstroomontwerper.
    2. Selecteer Instellingen in het informatievenster dat wordt geopend.
    3. Zoek onder Netwerken 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:

Asynchrone patrooninstelling uitschakelen

  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.

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 nagaat. 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 Retry-After-header

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 de reactie de volgende pagina aangeeft met de nextLink of @odata.nextLink eigenschap, kunt u de Paginering-instelling inschakelen in 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.

Controle van locatiekoppen 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 nagaat. 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 respecteert een waarde die u opgeeft via de Cookie eigenschap.
  • 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.

Verwante inhoud