Anropa externa HTTP- eller HTTPS-slutpunkter från arbetsflöden i Azure Logic Apps

  • Artikel

Gäller för: Azure Logic Apps (Förbrukning + Standard)

Vissa scenarier kan kräva att du skapar ett logikapparbetsflöde som skickar utgående begäranden till slutpunkter på andra tjänster eller system via HTTP eller HTTPS. Anta till exempel att du vill övervaka en tjänstslutpunkt för din webbplats genom att kontrollera slutpunkten enligt ett visst schema. När en specifik händelse inträffar vid den slutpunkten, till exempel om din webbplats slutar fungera, utlöser händelsen arbetsflödet och kör åtgärderna i arbetsflödet.

Kommentar

Om du vill skapa ett arbetsflöde som tar emot och svarar på inkommande HTTPS-anrop i stället kan du läsa Skapa arbetsflöden som du kan anropa, utlösa eller kapsla med HTTPS-slutpunkter i Azure Logic Apps och den inbyggda åtgärden Förfrågningsutlösare och svar.

Den här guiden visar hur du använder HTTP-utlösaren och HTTP-åtgärden så att arbetsflödet kan skicka utgående anrop till andra tjänster och system, till exempel:

  • Om du vill kontrollera eller avsöka en slutpunkt enligt ett återkommande schema lägger du till HTTP-utlösaren som det första steget i arbetsflödet. Varje gång utlösaren kontrollerar slutpunkten anropar eller skickar utlösaren en begäran till slutpunkten. Slutpunktens svar avgör om arbetsflödet körs. Utlösaren skickar allt innehåll från slutpunktens svar till åtgärderna i arbetsflödet.

  • Om du vill anropa en slutpunkt från någon annanstans i arbetsflödet lägger du till HTTP-åtgärden. Slutpunktens svar avgör hur arbetsflödets återstående åtgärder körs.

Förutsättningar

  • Ett Azure-konto och prenumeration. Om du heller inte har någon Azure-prenumeration kan du registrera ett kostnadsfritt Azure-konto.

  • URL:en för målslutpunkten som du vill anropa

  • Arbetsflödet för logikappen där du vill anropa målslutpunkten. För att börja med HTTP-utlösaren behöver du ett tomt arbetsflöde. Om du vill använda HTTP-åtgärden startar du arbetsflödet med valfri utlösare. I det här exemplet används HTTP-utlösaren som det första steget.

Anslut eller teknisk referens

Teknisk information om utlösare och åtgärdsparametrar finns i följande avsnitt:

Lägga till en HTTP-utlösare

Den här inbyggda utlösaren gör ett HTTP-anrop till den angivna URL:en för en slutpunkt och returnerar ett svar.

  1. Öppna standardlogikappresursen och det tomma arbetsflödet i designern i Azure-portalen.

  2. Följ de här allmänna stegen för att lägga till den inbyggda utlösaren med namnet HTTP i arbetsflödet.

    Det här exemplet byter namn på utlösaren till HTTP-utlösare – Anropa slutpunkts-URL så att utlösaren har ett mer beskrivande namn. Exemplet lägger också till en HTTP-åtgärd senare, och åtgärdsnamnen i arbetsflödet måste vara unika.

  3. Ange värdena för de HTTP-utlösarparametrar som du vill inkludera i anropet till målslutpunkten. Konfigurera upprepningen för hur ofta du vill att utlösaren ska kontrollera målslutpunkten.

    Om du väljer en annan autentiseringstyp än Ingen skiljer sig autentiseringsinställningarna beroende på ditt val. Mer information om autentiseringstyper som är tillgängliga för HTTP finns i följande avsnitt:

  4. Om du vill lägga till andra tillgängliga parametrar öppnar du listan Avancerade parametrar och väljer önskade parametrar.

  5. Lägg till andra åtgärder som du vill köra när utlösaren utlöses.

  6. Spara arbetsflödet när du är klar. I verktygsfältet för designern väljer du Spara.

Lägga till en HTTP-åtgärd

Den här inbyggda åtgärden gör ett HTTP-anrop till den angivna URL:en för en slutpunkt och returnerar ett svar.

  1. Öppna logikappen och arbetsflödet för förbrukning i designern i Azure-portalen.

    I det här exemplet används HTTP-utlösaren som lades till i föregående avsnitt som det första steget.

  2. Följ de här allmänna stegen för att lägga till den inbyggda åtgärden med namnet HTTP i arbetsflödet.

    Det här exemplet byter namn på åtgärden till HTTP-åtgärd – Anropa slutpunkts-URL så att steget har ett mer beskrivande namn. Dessutom måste åtgärdsnamnen i arbetsflödet vara unika.

  3. Ange värdena för de HTTP-åtgärdsparametrar som du vill inkludera i anropet till målslutpunkten.

    Om du väljer en annan autentiseringstyp än Ingen skiljer sig autentiseringsinställningarna beroende på ditt val. Mer information om autentiseringstyper som är tillgängliga för HTTP finns i följande avsnitt:

  4. Om du vill lägga till andra tillgängliga parametrar öppnar du listan Avancerade parametrar och väljer önskade parametrar.

  5. Spara arbetsflödet när du är klar. I verktygsfältet för designern väljer du Spara.

Utdata för utlösare och åtgärder

Här är mer information om utdata från en HTTP-utlösare eller -åtgärd, som returnerar följande information:

Property Type Beskrivning
headers JSON-objekt Rubrikerna från begäran
body JSON-objekt Objektet med brödtextinnehållet från begäran
status code Integer Statuskoden från begäran
Statuskod beskrivning
200 OK
202 Godkänd
400 Felaktig begäran
401 Behörighet saknas
403 Ej tillåtet
404 Hittades inte
500 Internt serverfel. Ett okänt fel uppstod.

URL-säkerhet för utgående anrop

Information om kryptering, säkerhet och auktorisering för utgående anrop från arbetsflödet, till exempel TLS (Transport Layer Security), tidigare kallat Secure Sockets Layer (SSL), självsignerade certifikat eller Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) finns i Säker åtkomst och data – Åtkomst för utgående anrop till andra tjänster och system.

Autentisering för en klientorganisationsmiljö

Om du har en standardlogikappresurs i Azure Logic Apps med en enda klientorganisation och du vill använda en HTTP-åtgärd med någon av följande autentiseringstyper ska du slutföra de extra installationsstegen för motsvarande autentiseringstyp. Annars misslyckas anropet.

TLS/SSL-certifikatautentisering

  1. Lägg till eller uppdatera appinställningen i logikappresursens appinställningar. WEBSITE_LOAD_ROOT_CERTIFICATES

  2. För inställningsvärdet anger du tumavtrycket för ditt TLS/SSL-certifikat som det rotcertifikat som ska vara betrott.

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

Om du till exempel arbetar i Visual Studio Code följer du dessa steg:

  1. Öppna logikappprojektets local.settings.json-fil .

  2. Values Lägg till eller uppdatera WEBSITE_LOAD_ROOT_CERTIFICATES inställningen i JSON-objektet:

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

    Kommentar

    Följ dessa steg för att hitta tumavtrycket:

    1. På resursmenyn för logikappen går du till Inställningar och väljer TLS/SSL-inställningar>Privata nyckelcertifikat (.pfx) eller Offentliga nyckelcertifikat (.cer).

    2. Leta upp det certifikat som du vill använda och kopiera tumavtrycket.

    Mer information finns i Hitta tumavtrycket – Azure App Service.

Mer information finns i följande dokumentation:

Klientcertifikat eller Microsoft Entra ID OAuth med autentiseringstypen "Certifikat"

  1. Lägg till eller uppdatera appinställningen i logikappresursens appinställningar. WEBSITE_LOAD_USER_PROFILE

  2. För inställningsvärdet anger du 1.

    "WEBSITE_LOAD_USER_PROFILE": "1"

Om du till exempel arbetar i Visual Studio Code följer du dessa steg:

  1. Öppna logikappprojektets local.settings.json-fil .

  2. Values Lägg till eller uppdatera WEBSITE_LOAD_USER_PROFILE inställningen i JSON-objektet:

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

Mer information finns i följande dokumentation:

Innehåll med datatyp för flera delar/formulär

Om du vill hantera innehåll som har multipart/form-data typen i HTTP-begäranden kan du lägga till ett JSON-objekt som innehåller attributen $content-type och $multipart i HTTP-begärandetexten med hjälp av det här formatet.

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

Anta till exempel att du har ett arbetsflöde som skickar en HTTP POST-begäran för en Excel-fil till en webbplats med hjälp av webbplatsens API, som stöder multipart/form-data typen. Följande exempel visar hur den här åtgärden kan visas:

Standardarbetsflöde

Skärmbild som visar standardarbetsflöde med HTTP-åtgärd och formulärdata för flera delar.

Arbetsflöde för förbrukning

Skärmbild som visar arbetsflöde för förbrukning med HTTP-åtgärd och formulärdata för flera delar.

Här är samma exempel som visar HTTP-åtgärdens JSON-definition i den underliggande arbetsflödesdefinitionen:

"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"
}

Innehåll med program/x-www-form-urlencoded-typ

Om du vill ange formulär-urlenkodade data i brödtexten för en HTTP-begäran måste du ange att data har application/x-www-form-urlencoded innehållstypen. Lägg till huvudet i content-type HTTP-utlösaren eller -åtgärden. Ange rubrikvärdet till application/x-www-form-urlencoded.

Anta till exempel att du har en logikapp som skickar en HTTP POST-begäran till en webbplats som stöder application/x-www-form-urlencoded typen. Så här kan den här åtgärden se ut:

Standardarbetsflöde

Skärmbild som visar standardarbetsflödet med HTTP-begäran och rubrik av innehållstyp inställd på application/x-www-form-urlencoded.

Arbetsflöde för förbrukning

Skärmbild som visar arbetsflödet Förbrukning med HTTP-begäran och rubrik av innehållstyp inställd på application/x-www-form-urlencoded.

Asynkront beteende för begärandesvar

För tillståndskänsliga arbetsflöden i både Azure Logic Apps för flera klienter och en klientorganisation följer alla HTTP-baserade åtgärder standardmönstret för asynkron åtgärd som standardbeteende. Det här mönstret anger att efter att en HTTP-åtgärd anropar eller skickar en begäran till en slutpunkt, tjänst, system eller API returnerar mottagaren omedelbart svaret "202 ACCEPTED" . Den här koden bekräftar att mottagaren accepterade begäran men inte har slutfört bearbetningen. Svaret kan innehålla en location rubrik som anger URI:n och ett uppdaterings-ID som anroparen kan använda för att avsöka eller kontrollera statusen för den asynkrona begäran tills mottagaren slutar bearbeta och returnerar ett "200 OK" -svar eller annat icke-202-svar. Anroparen behöver dock inte vänta på att begäran ska slutföra bearbetningen och kan fortsätta att köra nästa åtgärd. Mer information finns i Asynkron mikrotjänstintegrering framtvingar mikrotjänstautonomi.

För tillståndslösa arbetsflöden i Azure Logic Apps med en enda klient använder HTTP-baserade åtgärder inte det asynkrona åtgärdsmönstret. I stället körs de bara synkront, returnerar svaret "202 ACCEPTED" som det är och fortsätter till nästa steg i arbetsflödeskörningen. Om svaret innehåller en location rubrik avsöks inte den angivna URI:n av ett tillståndslöst arbetsflöde för att kontrollera statusen. Om du vill följa standardmönstret för asynkrona åtgärder använder du ett tillståndskänsligt arbetsflöde i stället.

  • HTTP-åtgärdens underliggande JSON-definition (JavaScript Object Notation) följer implicit det asynkrona åtgärdsmönstret.

  • HTTP-åtgärden, men inte utlösaren, har en Asynkron mönsterinställning , som är aktiverad som standard. Den här inställningen anger att anroparen inte väntar på att bearbetningen ska slutföras och kan gå vidare till nästa åtgärd, men fortsätter att kontrollera statusen tills bearbetningen stoppas. Om den här inställningen är inaktiverad anger den att anroparen väntar på att bearbetningen ska slutföras innan nästa åtgärd går vidare.

    Följ dessa steg för att hitta inställningen Asynkront mönster , baserat på om du har ett arbetsflöde för standard eller förbrukning:

    Standardarbetsflöde*

    1. I arbetsflödesdesignern väljer du HTTP-åtgärden. I informationsfönstret som öppnas väljer du Inställningar.

    2. Under Nätverk letar du upp inställningen Asynkront mönster .

    Arbetsflöde för förbrukning

    1. I arbetsflödesdesignern går du till HTTP-åtgärdens namnlist och väljer knappen ellipser (...) som öppnar åtgärdens inställningar.

    2. Hitta inställningen Asynkront mönster .

Inaktivera asynkrona åtgärder

Ibland kanske du vill inaktivera HTTP-åtgärdens asynkrona beteende i specifika scenarier, till exempel när du vill:

Inaktivera inställning för asynkront mönster

  1. I arbetsflödesdesignern väljer du HTTP-åtgärden och i informationsfönstret som öppnas väljer du Inställningar.

  2. Under Nätverk letar du upp inställningen Asynkront mönster . Inaktivera inställningen om den är aktiverad.

Inaktivera asynkront mönster i åtgärdens JSON-definition

I HTTP-åtgärdens underliggande JSON-definition lägger du till åtgärdsalternativet "DisableAsyncPattern" i åtgärdens definition så att åtgärden följer det synkrona åtgärdsmönstret i stället. Mer information finns i Även Köra åtgärder i ett synkront åtgärdsmönster.

Undvik HTTP-timeouter för tidskrävande uppgifter

HTTP-begäranden har en tidsgräns. Om du har en tidskrävande HTTP-åtgärd som överskrider tidsgränsen på grund av den här gränsen har du följande alternativ:

  • Inaktivera HTTP-åtgärdens asynkrona åtgärdsmönster så att åtgärden inte kontinuerligt avsöks eller kontrollerar begärans status. I stället väntar åtgärden på att mottagaren ska svara med status och resultat när begäran har slutfört bearbetningen.

  • Ersätt HTTP-åtgärden med HTTP Webhook-åtgärden, som väntar på att mottagaren ska svara med status och resultat när begäran har slutfört bearbetningen.

Konfigurera intervall mellan återförsök med återförsökshuvudet

Om du vill ange antalet sekunder mellan återförsök kan du lägga till huvudet i Retry-After HTTP-åtgärdssvaret. Om målslutpunkten till exempel returnerar 429 - Too many requests statuskoden kan du ange ett längre intervall mellan återförsök. Rubriken Retry-After fungerar också med 202 - Accepted statuskoden.

Här är samma exempel som visar HTTP-åtgärdssvaret som innehåller Retry-After:

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

Sidnumreringssupport

Ibland svarar måltjänsten genom att returnera resultatet en sida i taget. Om svaret anger nästa sida med egenskapen nextLink eller @odata.nextLink kan du aktivera inställningen Sidnumrering för HTTP-åtgärden. Den här inställningen gör att HTTP-åtgärden automatiskt följer dessa länkar och hämtar nästa sida. Men om svaret anger nästa sida med någon annan tagg kan du behöva lägga till en loop i arbetsflödet. Gör så att den här loopen följer taggen och manuellt hämtar varje sida tills taggen är null.

Inaktivera kontroll av platsrubriker

Vissa slutpunkter, tjänster, system eller API:er returnerar ett 202 ACCEPTED svar som inte har ett location huvud. Om du vill undvika att en HTTP-åtgärd kontinuerligt kontrollerar begärandestatusen location när rubriken inte finns kan du ha följande alternativ:

  • Inaktivera HTTP-åtgärdens asynkrona åtgärdsmönster så att åtgärden inte kontinuerligt avsöks eller kontrollerar begärans status. I stället väntar åtgärden på att mottagaren ska svara med status och resultat när begäran har slutfört bearbetningen.

  • Ersätt HTTP-åtgärden med HTTP Webhook-åtgärden, som väntar på att mottagaren ska svara med status och resultat när begäran har slutfört bearbetningen.

Kända problem

Utelämnade HTTP-huvuden

Om en HTTP-utlösare eller åtgärd innehåller dessa huvuden tar Azure Logic Apps bort dessa huvuden från det genererade begärandemeddelandet utan att visa någon varning eller något fel:

  • Accept-* sidhuvuden förutom Accept-version
  • Allow
  • Content-* sidhuvuden förutom Content-Disposition, Content-Encoding, och Content-Type, som respekteras när du använder POST- och PUT-åtgärderna. Azure Logic Apps släpper dock dessa rubriker när du använder GET-åtgärden.
  • Cookie huvud, men Azure Logic Apps respekterar alla värden som du anger med hjälp av egenskapen Cookie .
  • Expires
  • Host
  • Last-Modified
  • Origin
  • Set-Cookie
  • Transfer-Encoding

Även om Azure Logic Apps inte hindrar dig från att spara logikappar som använder en HTTP-utlösare eller åtgärd med dessa rubriker, ignorerar Azure Logic Apps dessa rubriker.

Svarsinnehållet matchar inte den förväntade innehållstypen

HTTP-åtgärden genererar ett BadRequest-fel om HTTP-åtgärden anropar serverdels-API:et Content-Type med huvudet inställt på application/json, men svaret från serverdelen faktiskt inte innehåller innehåll i JSON-format, vilket misslyckas med intern validering av JSON-format.

Nästa steg