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 přechod na váš web, tato událost aktivuje váš pracovní postup a spustí akce v tomto pracovním postupu.

Poznámka:

Pokud chcete vytvořit pracovní postup, který místo toho přijímá příchozí volání HTTPS a reaguje na ně, přečtěte si téma Vytvoření pracovních postupů, které můžete volat, aktivovat nebo vnořit pomocí koncových bodů HTTPS v Azure Logic Apps a integrované aktivační události požadavku a akce odpovědi.

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 dotazovat koncový bod podle plánu opakování, přidejte trigger HTTP jako první krok pracovního 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ředá veškerý obsah z odpovědi koncového bodu na akce v pracovním postupu.

• Pokud chcete volat koncový bod z libovolného místa v pracovním postupu, přidejte akci 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

• Pracovní postup aplikace logiky, ze kterého chcete volat cílový koncový bod. Abyste mohli začít s triggerem HTTP, potřebujete prázdný pracovní postup. Pokud chcete použít akci HTTP, spusťte pracovní postup libovolným triggerem. V tomto příkladu se jako první krok používá trigger HTTP.

Připojení otechnické referenční informace

Technické informace o parametrech triggeru a akce najdete v následujících částech:

• Parametry triggeru 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. Na webu Azure Portal otevřete prostředek aplikace logiky Standard a prázdný pracovní postup v návrháři.

2. Pokud chcete do pracovního postupu přidat předdefinovaný trigger s názvem HTTP, postupujte podle těchto obecných kroků.

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

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

   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 tématech:

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

4. Pokud chcete přidat další dostupné parametry, otevřete seznam rozšířených parametrů a vyberte požadované parametry.

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

6. Po dokončení uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Využití

1. Na webu Azure Portal otevřete aplikaci logiky Consumption a prázdný pracovní postup v návrháři.

2. Pokud chcete do pracovního postupu přidat předdefinovaný trigger s názvem HTTP, postupujte podle těchto obecných kroků.

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

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

   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 tématech:

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

4. Pokud chcete přidat další dostupné parametry, otevřete seznam přidat nový parametr a vyberte požadované parametry.

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

6. Po dokončení uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Přidání akce HTTP

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

Standard

1. Na webu Azure Portal otevřete aplikaci logiky Consumption a pracovní postup v návrháři.

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

2. Pokud chcete do pracovního postupu přidat integrovanou akci s názvem HTTP, postupujte podle těchto obecných kroků.

   Tento příklad přejmenuje akci http na adresu URL koncového bodu volání, aby krok získal 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.

   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 těchto tématech:

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

4. Pokud chcete přidat další dostupné parametry, otevřete seznam rozšířených parametrů a vyberte požadované parametry.

5. Po dokončení uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Využití

1. Na webu Azure Portal otevřete aplikaci logiky Consumption a pracovní postup v návrháři.

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

2. Pokud chcete do pracovního postupu přidat integrovanou akci s názvem HTTP, postupujte podle těchto obecných kroků.

   Tento příklad přejmenuje akci http na adresu URL koncového bodu volání, aby krok získal 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.

   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 těchto tématech:

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

4. Pokud chcete přidat další dostupné parametry, otevřete seznam přidat nový parametr a vyberte požadované parametry.

5. Po dokončení uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Výstupy triggeru a akce

Tady jsou další informace o výstupech z triggeru http nebo akce, která vrací následující informace:

Vlastnost	Type	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 je protokol TLS (Transport Layer Security), dříve označovaný jako SSL (Secure Sockets Layer), certifikáty podepsané svým držitelem nebo ověřování Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), najdete v tématu Zabezpečený přístup a data – Přístup 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/SSL: Přidejte nastavení WEBSITE_LOAD_ROOT_CERTIFICATESaplikace a nastavte hodnotu na kryptografický otisk certifikátu TLS/SSL.

• Klientský certifikát nebo ověřování Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) s typem přihlašovacích údajů "Certifikát": Přidejte nastavení WEBSITE_LOAD_USER_PROFILEaplikace a nastavte hodnotu na 1.

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

1. V nastavení aplikace aplikace logiky přidejte nebo aktualizujte nastaveníWEBSITE_LOAD_ROOT_CERTIFICATES aplikace .

2. Jako hodnotu nastavení zadejte kryptografický otisk certifikátu TLS/SSL jako kořenový certifikát, který má být důvěryhodný.

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-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/SSL-certificate>",
         <...>
      }
   }
   

   Poznámka:

   Kryptografický otisk najdete takto:

   1. V nabídce prostředků aplikace logiky v části Nastavení vyberte nastavení TLS/SSL>– Certifikáty privátního klíče (.pfx) nebo Certifikáty veřejných klíčů (.cer).

   2. Vyhledejte certifikát, který chcete použít, a zkopírujte kryptografický otisk.

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

Další informace najdete v následující dokumentaci:

• Úprava nastavení hostitele a aplikace pro aplikace logiky v Azure Logic Apps s jedním tenantem
• Privátní klientské certifikáty – Aplikace Azure Service

Klientský certifikát nebo ověřování typu přihlašovacích údajů Microsoft Entra ID OAuth s typem přihlašovacích údajů Certifikát

1. V nastavení aplikace aplikace logiky přidejte nebo aktualizujte nastaveníWEBSITE_LOAD_USER_PROFILE aplikace .

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

Další informace najdete v následující dokumentaci:

• Úprava nastavení hostitele a aplikace pro aplikace logiky v Azure Logic Apps s jedním tenantem
• Privátní klientské certifikáty – Aplikace Azure Service

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 do 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:

Standardní pracovní postup

Pracovní postup Consumption

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

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:

Standardní pracovní postup

Pracovní postup Consumption

Asynchronní chování odpovědi na požadavek

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čkulocation, 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 Asynchronní integrace mikroslužeb vynucuje autonomii mikroslužeb.

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 tak, jak je, a pokračujte dalším krokem v provádění pracovního postupu. Pokud odpověď obsahuje hlavičku location , bezstavový pracovní postup se nebude dotazovat na zadaný identifikátor URI a zkontroluje stav. Pokud chcete postupovat podle standardního vzoru asynchronní operace, použijte místo toho stavový pracovní postup.

• Základní definice JSON (JavaScript Object Notation) 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.

  Pokud chcete najít nastavení asynchronního vzoru , postupujte podle těchto kroků na základě toho, jestli máte pracovní postup Standard nebo Consumption:

  Standardní pracovní postup*

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

  2. V části Sítě vyhledejte nastavení asynchronního vzoru .

  Pracovní postup Consumption

  1. V návrháři pracovního postupu na záhlaví akce HTTP vyberte tlačítko se třemi tečkami (...), které otevře nastavení akce.

  2. 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í nastavení asynchronního vzoru

Standard

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 tato možnost povolená, vypněte nastavení.

Využití

1. V návrháři pracovního postupu na záhlaví akce HTTP vyberte tlačítko se třemi tečkami (...), které otevře nastavení akce.

2. Najděte nastavení Asynchronní vzor, vypněte nastavení na Vypnuto, pokud je povoleno, a vyberte Hotovo.

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 tématu Spuštění akcí v synchronním vzoru operace.

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 vzor asynchronní operace akce HTTP tak, aby se akce nepřesílala ani nekontroluje stav požadavku. Místo toho akce čeká, až příjemce odpoví stavem a výsledky po dokončení zpracování požadavku.

• Nahraďte akci HTTP akcí webhooku HTTP, která čeká, až příjemce odpoví stavem a výsledky po dokončení zpracování požadavku.

Nastavení intervalu mezi opakovanými pokusy pomocí hlavičky Opakovat až po

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í

V některých případech cílová služba reaguje vrácením výsledků po jedné stránce. Pokud odpověď určuje další stránku s vlastností nextLink nebo @odata.nextLink , můžete zapnout nastavení stránkování 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 jinou značkou, 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ázání záhlaví pro kontrolu 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 vzor asynchronní operace akce HTTP tak, aby se akce nepřesílala ani nekontroluje stav požadavku. Místo toho akce čeká, až příjemce odpoví stavem a výsledky po dokončení zpracování požadavku.

• Nahraďte akci HTTP akcí webhooku HTTP, která čeká, až příjemce odpoví stavem a výsledky po dokončení 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-Encodinga Content-Type, které jsou dodrženy při použití operací POST a PUT. Azure Logic Apps ale tyto hlavičky při použití operace GET zahodí.
• Cookie Azure Logic Apps ale respektuje jakoukoli hodnotu, kterou zadáte pomocí vlastnosti Cookie .
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-Encoding

I když azure Logic Apps nezastaví ukládání aplikací logiky, které používají trigger HTTP nebo akci 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á back-endové rozhraní API s Content-Type hlavičkou nastavenou na application/json, ale odpověď z back-endu ve skutečnosti neobsahuje obsah ve formátu JSON, což selže při ověřování interního formátu FORMÁTU JSON.

Další kroky

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