Volání externích koncových bodů HTTP nebo HTTPS z pracovních postupů v Azure Logic Apps

Platí pro: Azure Logic Apps (Consumption + Standard)

Některé scénáře můžou vyžadovat, abyste vytvořili pracovní postup aplikace logiky, který odesílá odchozí požadavky do koncových bodů v jiných službách nebo systémech přes HTTP nebo HTTPS. Předpokládejme například, že chcete monitorovat koncový bod služby pro váš web kontrolou koncového bodu podle konkrétního plánu. Když na tomto koncovém bodu dojde ke konkrétní události, jako je například váš web přestane fungovat, tato událost spustí váš pracovní proces a provede akce v tomto procesu.

Poznámka:

Pokud chcete vytvořit pracovní postup, který přijímá příchozí volání HTTPS a reaguje na ně, přečtěte si téma Vytváření pracovních postupů, které můžete volat, aktivovat nebo vnořit pomocí koncových bodů HTTPS v Azure Logic Apps. Pokud chcete použít předdefinovaný trigger požadavku, přečtěte si téma Příjem a reakce na příchozí volání HTTPS pracovních postupů v Azure Logic Apps.

Tato příručka ukazuje, jak používat trigger HTTP a akci HTTP, aby váš pracovní postup mohl odesílat odchozí volání do jiných služeb a systémů, například:

• Pokud chcete zkontrolovat nebo pravidelně dotazovat koncový bod podle plánu, přidejte předdefinovaný spouštěč (trigger) s názvem HTTP jako první krok v pracovním postupu. Pokaždé, když trigger zkontroluje koncový bod, trigger zavolá nebo odešle požadavek do koncového bodu. Odpověď koncového bodu určuje, jestli se váš pracovní postup spustí. Trigger přenáší jakýkoli obsah z odpovědi koncového bodu k akcím ve vašem pracovním postupu.

• Pokud chcete volat koncový bod z libovolného místa v pracovním postupu, přidejte integrovanou akci s názvem HTTP. Odpověď koncového bodu určuje, jak se budou spouštět zbývající akce pracovního postupu.

Požadavky

• Účet a předplatné Azure. Pokud nemáte předplatné Azure, zaregistrujte si bezplatný účet Azure.

• Adresa URL cílového koncového bodu, který chcete volat.

• Prostředek logické aplikace s pracovním postupem, ze kterého chcete volat externí koncový bod.

  Pokud chcete spustit pracovní postup pomocí triggeru HTTP , musíte mít prázdný pracovní postup. Pokud chcete použít akci HTTP , může váš pracovní postup začít triggerem, který nejlépe vyhovuje vašemu scénáři. Ukázkové pracovní postupy v tomto článku používají trigger HTTP .

  Pokud nemáte prostředek a pracovní postup aplikace logiky, vytvořte je teď podle kroků pro aplikaci logiky, kterou chcete použít:

  • Vytvořte ukázkový pracovní postup logické aplikace typu Consumption
  • Vytvoření ukázkového pracovního postupu standardní aplikace logiky

Technické reference ke konektoru

Technické informace o parametrech triggeru a akce najdete v následujících částech referenční příručky schématu:

• Parametry spouštěče HTTP
• Parametry akce HTTP

Přidání triggeru HTTP

Tento integrovaný trigger provede volání HTTP na zadanou adresu URL koncového bodu a vrátí odpověď.

Standard

1. V Azure Portal otevřete svůj prostředek Standard pro logické aplikace.

2. V nabídce bočního panelu prostředku v části Pracovní postupy vyberte Pracovní postupy a pak vyberte prázdný pracovní postup.

3. V nabídce bočního panelu pracovního postupu v části Nástroje vyberte návrháře a otevřete pracovní postup.

4. Přidejte do pracovního postupu předdefinovaný trigger HTTP podle obecných kroků pro přidání triggeru.

   Tento příklad přejmenuje trigger na trigger HTTP – adresa URL koncového bodu volání , aby aktivační událost získala popisnější název. Příklad později přidá akci HTTP a názvy operací v pracovním postupu musí být jedinečné.

5. Zadejte hodnoty parametrů triggeru HTTP , které chcete zahrnout do volání cílového koncového bodu. Nastavte opakování pro to, jak často má trigger zkontrolovat cílový koncový bod.

6. V seznamu Upřesnit parametry vyberte Ověřování.

   Pokud vyberete jiný typ ověřování než Žádný, nastavení ověřování se liší podle vašeho výběru. Další informace o typech ověřování dostupných pro PROTOKOL HTTP najdete v následujících článcích:

   • Přidání ověřování do odchozích volání
   • Ověřování přístupu k prostředkům pomocí spravovaných identit

7. Přidejte všechny další akce, které chcete spustit při aktivaci triggeru.

8. Až budete hotovi, uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Využití

1. Na webu Azure Portal otevřete prostředek aplikace logiky Consumption.

2. V nabídce bočního panelu v části Vývojové nástroje vyberte návrháře a otevřete prázdný pracovní postup.

3. Přidejte do pracovního postupu předdefinovaný trigger HTTP podle obecných kroků pro přidání triggeru.

   Tento příklad přejmenuje trigger na trigger HTTP – adresa URL koncového bodu volání , aby aktivační událost získala popisnější název. Příklad později přidá akci HTTP a názvy operací v pracovním postupu musí být jedinečné.

4. Zadejte hodnoty parametrů triggeru HTTP , které chcete zahrnout do volání cílového koncového bodu. Nastavte opakování pro to, jak často má trigger zkontrolovat cílový koncový bod.

5. V seznamu Upřesnit parametry vyberte Ověřování.

   Pokud vyberete jiný typ ověřování než Žádný, nastavení ověřování se liší podle vašeho výběru. Další informace o typech ověřování dostupných pro PROTOKOL HTTP najdete v následujících článcích:

   • Přidání ověřování do odchozích volání
   • Ověřování přístupu k prostředkům pomocí spravovaných identit

6. Přidejte všechny další akce, které chcete spustit při aktivaci triggeru.

7. Až budete hotovi, uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Přidání akce HTTP

Tato integrovaná akce odešle volání HTTPS nebo HTTP na zadanou adresu URL koncového bodu a vrátí odpověď.

Standard

1. V Azure Portal otevřete svůj prostředek Standard pro logické aplikace.

2. V nabídce bočního panelu prostředku v části Pracovní postupy vyberte Pracovní postupy a pak vyberte pracovní postup.

3. V nabídce bočního panelu pracovního postupu v části Nástroje vyberte návrháře a otevřete pracovní postup.

   Tento příklad používá trigger HTTP přidaný v předchozí části.

4. Přidejte do pracovního postupu integrovanou akci HTTP podle obecných kroků přidání akce.

   Tento příklad přejmenuje akci HTTP akce - volání na URL koncového bodu, aby akce měla popisnější název. Názvy operací v pracovním postupu musí být také jedinečné.

5. Zadejte hodnoty parametrů akce HTTP , které chcete zahrnout do volání cílového koncového bodu.

6. V seznamu Upřesnit parametry vyberte Ověřování.

   Pokud vyberete jiný typ ověřování než Žádný, nastavení ověřování se liší podle vašeho výběru. Další informace o typech ověřování dostupných pro PROTOKOL HTTP najdete v následujících článcích:

   • Přidání ověřování do odchozích volání
   • Ověřování přístupu k prostředkům pomocí spravovaných identit

7. Přidejte všechny další akce, které chcete spustit při aktivaci triggeru.

8. Až budete hotovi, uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Využití

1. V Azure portálu otevřete aplikaci Consumption logic a pracovní postup v návrháři.

   Tento příklad používá trigger HTTP přidaný v předchozí části jako první krok.

2. Přidejte vestavěnou akci HTTP do pracovního postupu podle obecných kroků pro přidání akce.

   Tento příklad přejmenuje akci HTTP akce - volání na URL koncového bodu, aby akce měla popisnější název. Názvy operací v pracovním postupu musí být také jedinečné.

3. Zadejte hodnoty parametrů akce HTTP , které chcete zahrnout do volání cílového koncového bodu.

4. V seznamu Upřesnit parametry vyberte Ověřování.

   Pokud vyberete jiný typ ověřování než Žádný, nastavení ověřování se liší podle vašeho výběru. Další informace o typech ověřování dostupných pro PROTOKOL HTTP najdete v následujících článcích:

   • Přidání ověřování do odchozích volání
   • Ověřování přístupu k prostředkům pomocí spravovaných identit

5. Přidejte všechny další akce, které chcete spustit při aktivaci triggeru.

6. Až budete hotovi, uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Výstupy triggeru a akce

Trigger HTTP nebo akce vypíše následující informace:

Vlastnictví	Typ	Popis
headers	Objekt JSON	Hlavičky z požadavku
body	Objekt JSON	Objekt s obsahem textu z požadavku
status code	Celé číslo	Stavový kód z požadavku

Stavový kód	Popis
200	OK
202	Přijato
400	Chybný požadavek
401	Neautorizováno
403	Zakázáno
404	Nenalezeno
500	Vnitřní chyba serveru. Došlo k neznámé chybě.

Zabezpečení adresy URL pro odchozí volání

Informace o šifrování, zabezpečení a autorizaci odchozích volání z vašeho pracovního postupu, jako jsou protokol TLS (Transport Layer Security), certifikáty podepsané svým držitelem nebo otevřené ověřování Microsoft Entra ID, najdete v tématu Access pro odchozí volání do jiných služeb a systémů.

Ověřování pro prostředí s jedním tenantem

Pokud máte prostředek aplikace logiky Standard v Azure Logic Apps s jedním tenantem a chcete použít operaci HTTP s některým z následujících typů ověřování, nezapomeňte dokončit další kroky nastavení pro odpovídající typ ověřování. Jinak volání selže.

• Certifikát TLS: Přidejte nastavení WEBSITE_LOAD_ROOT_CERTIFICATESaplikace a nastavte hodnotu na kryptografický otisk certifikátu TLS.

• Klientský certifikát nebo Microsoft Entra ID OAuth s typem přihlašovacích údajů certifikát: Přidejte nastavení aplikace WEBSITE_LOAD_USER_PROFILE a nastavte hodnotu na 1.

Ověřování certifikátů TLS

1. V nastavení aplikace aplikace logiky přidejte nebo aktualizujte nastavení aplikace s názvem WEBSITE_LOAD_ROOT_CERTIFICATES. Konkrétní kroky najdete v tématu Správa nastavení aplikace – local.settings.json.

2. Jako hodnotu nastavení zadejte kryptografický otisk certifikátu TLS jako kořenový certifikát, který se má považovat za důvěryhodný.

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

Pokud například pracujete v editoru Visual Studio Code, postupujte takto:

1. Otevřete soubor local.settings.json projektu aplikace logiky.

2. V objektu Values JSON přidejte nebo aktualizujte WEBSITE_LOAD_ROOT_CERTIFICATES nastavení:

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

Poznámka:

Chcete-li najít kryptografický otisk, postupujte podle těchto kroků:

• V nabídce prostředků aplikace logiky v části Nastavení vyberte Certifikáty.
• Vyberte Možnost Přineste si vlastní certifikáty (.pfx) nebo Certifikáty veřejného klíče (.cer).
• Vyhledejte certifikát, který chcete použít, a zkopírujte kryptografický otisk.

Další informace najdete v tématu Vyhledání kryptografického otisku – Azure App Service.

Další informace najdete v tématu Správa nastavení aplikace – local.settings.json.

Klientský certifikát nebo OAuth s přihlašováním typu Certifikát od Microsoft Entra ID

1. V nastavení aplikace aplikace logiky přidejte nebo aktualizujte nastavení aplikace s názvem WEBSITE_LOAD_USER_PROFILE. Konkrétní kroky najdete v tématu Správa nastavení aplikace – local.settings.json

2. Pro hodnotu nastavení zadejte 1.

   "WEBSITE_LOAD_USER_PROFILE": "1"

Pokud například pracujete v editoru Visual Studio Code, postupujte takto:

1. Otevřete soubor local.settings.json projektu aplikace logiky.

2. V objektu Values JSON přidejte nebo aktualizujte WEBSITE_LOAD_USER_PROFILE nastavení:

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

Pokud pracujete na webu Azure Portal, otevřete aplikaci logiky. V části Nastavení v nabídce bočního panelu vyberte Proměnné prostředí. V části Nastavení aplikace přidejte nebo upravte nastavení.

Obsah s více částmi nebo datovým typem formuláře

Pokud chcete zpracovat obsah, který má multipart/form-data typ požadavků HTTP, můžete pomocí tohoto formátu přidat objekt JSON, který obsahuje $content-type atributy a $multipart atributy v textu požadavku HTTP.

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

Předpokládejme například, že máte pracovní postup, který odešle požadavek HTTP POST na excelový soubor na web pomocí rozhraní API daného webu, který podporuje tento multipart/form-data typ. Následující ukázka ukazuje, jak se tato akce může zobrazit:

Tady je stejný příklad, který ukazuje definici JSON akce HTTP v podkladové definici pracovního postupu:

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

Obsah s typem application/x-www-form-urlencoded

Pokud chcete v textu požadavku HTTP zadat data zakódovaná pomocí adresy URL formuláře, musíte určit, že data mají application/x-www-form-urlencoded typ obsahu. Do triggeru nebo akce HTTP přidejte hlavičku content-type . Nastavte hodnotu záhlaví na application/x-www-form-urlencoded.

Předpokládejme například, že máte aplikaci logiky, která odesílá požadavek HTTP POST na web, který podporuje typ application/x-www-form-urlencoded . Takto může tato akce vypadat:

Asynchronní chování požadavek-odpověď

U stavových pracovních postupů ve víceklientských i jednoklientských Azure Logic Apps se všechny akce založené na protokolu HTTP řídí standardním vzorem asynchronní operace jako výchozí chování. Tento vzor určuje, že po volání akce HTTP nebo odeslání požadavku na koncový bod, službu, systém nebo rozhraní API příjemce okamžitě vrátí odpověď 202 ACCEPTED . Tento kód potvrdí, že příjemce přijal požadavek, ale nedokončil zpracování. Odpověď může obsahovat hlavičku location , která určuje identifikátor URI a ID aktualizace, které volající může použít k dotazování nebo kontrole stavu asynchronního požadavku, dokud příjemce nezastaví zpracování a nevrátí odpověď na úspěch 200 OK nebo jinou odpověď, která není 202. Volající ale nemusí čekat na dokončení zpracování požadavku a může pokračovat ve spuštění další akce. Další informace najdete v tématu Synchronní a asynchronní zasílání zpráv.

U bezstavových pracovních postupů v Azure Logic Apps s jedním tenantem nepoužívají akce založené na protokolu HTTP vzor asynchronní operace. Místo toho se spustí synchronně, vrátí odpověď 202 ACCEPTED as-isa přejde k dalšímu kroku vykonávání pracovního procesu. Pokud odpověď obsahuje hlavičku location, bezstavový pracovní postup neprovádí opakované dotazování zadaného URI za účelem kontroly stavu. Pokud chcete postupovat podle standardního vzoru asynchronní operace, použijte místo toho stavový pracovní postup.

• Základní definice JSON akce HTTP implicitně sleduje vzor asynchronní operace.

• Akce HTTP, ale ne trigger, má nastavení asynchronního vzoru , které je ve výchozím nastavení povolené. Toto nastavení určuje, že volající nečeká na dokončení zpracování a může přejít k další akci, ale pokračuje v kontrole stavu, dokud se zpracování nezastaví. Pokud je toto nastavení zakázané, určuje, že volající čeká na dokončení zpracování před přechodem na další akci.

  Vyhledání nastavení asynchronního vzoru :

  1. V návrháři pracovního postupu vyberte akci HTTP .
  2. V podokně informací, které se otevře, vyberte Nastavení.
  3. V části Sítě vyhledejte nastavení asynchronního vzoru .

Zakázání asynchronních operací

Někdy můžete chtít zakázat asynchronní chování akce HTTP v konkrétních scénářích, například když chcete:

• Vyhněte se vypršení časových limitů PROTOKOLU HTTP u dlouhotrvajících úloh
• Zakázání záhlaví pro kontrolu umístění

Vypnutí asynchronního nastavení vzoru

1. V návrháři pracovního postupu vyberte akci HTTP a v informačním podokně, které se otevře, vyberte Nastavení.

2. V části Sítě vyhledejte nastavení asynchronního vzoru . Pokud je možnost povolena, nastavte ji na Vypnuto.

Zakázání asynchronního vzoru v definici JSON akce

V základní definici JSON akce HTTP přidejte DisableAsyncPattern do definice akce možnost operace , aby se akce místo toho řídí synchronním vzorem operace. Další informace najdete také v dokumentu Spuštění akcí používající synchronní vzorek operací.

Vyhněte se vypršení časových limitů PROTOKOLU HTTP u dlouhotrvajících úloh

Požadavky HTTP mají časový limit. Pokud máte dlouhotrvající akci HTTP, která vyprší kvůli tomuto limitu, máte tyto možnosti:

• Zakažte asynchronní režim operace akce HTTP, aby akce nezpůsobila neustálé dotazování nebo kontrolu stavu požadavku. Místo toho akce čeká, až přijímač odpoví stavem a výsledky, po dokončení zpracování požadavku.

• Nahraďte akci HTTP akcí webhook HTTP, která čeká na odpověď příjemce se stavem a výsledky po úplném zpracování požadavku.

Nastavení intervalu mezi opakovanými pokusy s hlavičkou Retry-After

Pokud chcete zadat počet sekund mezi opakovanými pokusy, můžete přidat hlavičku Retry-After do odpovědi akce HTTP. Pokud například cílový koncový bod vrátí 429 - Too many requests stavový kód, můžete zadat delší interval mezi opakovanými pokusy. Hlavička Retry-After také funguje se stavovým kódem 202 - Accepted .

Tady je stejný příklad, který ukazuje odpověď akce HTTP, která obsahuje Retry-After:

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

Podpora stránkování

Někdy cílová služba vrátí výsledky postupně po jedné stránce. Pokud odpověď určuje další stránku pomocí vlastnosti nextLink nebo @odata.nextLink, můžete aktivovat nastavení stránkování v rámci akce HTTP. Toto nastavení způsobí, že akce HTTP automaticky sleduje tyto odkazy a získá další stránku. Pokud ale odpověď určuje další stránku s jiným tagem, budete možná muset do pracovního postupu přidat smyčku. Proveďte tuto smyčku podle této značky a ručně získejte každou stránku, dokud značka nemá hodnotu null.

Zakázat kontrolu záhlaví umístění

Některé koncové body, služby, systémy nebo rozhraní API vrací 202 ACCEPTED odpověď, která nemá hlavičku location . Pokud nechcete, aby akce HTTP průběžně kontrolovaly stav požadavku, když location záhlaví neexistuje, můžete mít tyto možnosti:

• Zakažte asynchronní režim operace akce HTTP, aby akce nezpůsobila neustálé dotazování nebo kontrolu stavu požadavku. Místo toho akce čeká, až přijímač odpoví stavem a výsledky, po dokončení zpracování požadavku.

• Nahraďte akci HTTP akcí webhook HTTP, která čeká na odpověď příjemce se stavem a výsledky po úplném zpracování požadavku.

Známé problémy

Vynechané hlavičky HTTP

Pokud trigger HTTP nebo akce obsahují tyto hlavičky, Azure Logic Apps odebere tyto hlavičky ze zprávy vygenerovaného požadavku, aniž by se zobrazilo upozornění nebo chyba:

• Accept-* hlavičky s výjimkou Accept-version
• Allow
• Content-* hlavičky s výjimkou Content-Disposition, Content-Encoding a Content-Type, které jsou respektovány při použití operací POST a PUT. Azure Logic Apps tyto hlavičky ale zahodí při použití operace GET.
• Cookie hlavička, ale Azure Logic Apps respektuje jakoukoli hodnotu, kterou zadáte pomocí vlastnosti Cookie.
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-Encoding

I když Azure Logic Apps nezabrání vám ukládat aplikace logiky, které používají trigger HTTP nebo akce s těmito hlavičkami, Azure Logic Apps tyto hlavičky ignoruje.

Obsah odpovědi neodpovídá očekávanému typu obsahu

Akce HTTP vyvolá chybu BadRequest, pokud akce HTTP volá backendové rozhraní API s Content-Type hlavičkou nastavenou na application/json, ale odpověď z backendu ve skutečnosti neobsahuje obsah ve formátu JSON, což způsobí selhání ověřování interního JSON formátu.

Související obsah

• Spravované konektory pro konektory Azure Logic Apps
• Integrované konektory pro Azure Logic Apps