Zpracování chyb a výjimek v Azure Logic Apps
Platí pro: Azure Logic Apps (Consumption + Standard)
Způsob, jakým jakákoli architektura integrace odpovídajícím způsobem zpracovává výpadky nebo problémy způsobené závislými systémy, může představovat výzvu. Azure Logic Apps poskytuje prvotřídní prostředí pro zpracování chyb a výjimek, které vám pomůžou vytvářet robustní a odolné integrace, které elegantně zpracovávají problémy a selhání.
Zásady opakování pokusů
Pro nejzákladnější zpracování výjimek a chyb můžete použít zásadu opakování, pokud je podporována u triggeru nebo akce, jako je například akce HTTP. Pokud vyprší časový limit původního požadavku triggeru nebo akce, výsledkem je odpověď 408, 429 nebo 5xx, zásada opakování určuje, že trigger nebo akce znovu odešle požadavek na nastavení zásad.
Omezení zásad opakování
Další informace o zásadách opakování, nastaveních, limitech a dalších možnostech najdete v tématu Omezení zásad opakování.
Typy zásad opakování
Připojení orové operace, které podporují zásady opakování, používají Výchozí zásady, pokud nevyberete jinou zásadu opakování.
| Zásady opakování | Popis |
|---|---|
| Výchozí | Pro většinu operací je výchozí zásadou opakování exponenciální interval, která odesílá až 4 opakování v exponenciálně rostoucích intervalech. Tyto intervaly se škálují o 7,5 sekund, ale jsou omezeny mezi 5 a 45 sekundami. Několik operací používá jinou výchozí zásadu opakování, například zásadu s pevným intervalem. Další informace najdete v typu výchozí zásady opakování. |
| Nic | Neposílejte žádost znovu. Další informace najdete v tématu Žádné – žádné zásady opakování. |
| Exponenciální interval | Tato zásada čeká náhodný interval, který je vybrán z exponenciálně rostoucího rozsahu před odesláním dalšího požadavku. Další informace najdete v typu zásad exponenciálního intervalu. |
| Pevný interval | Tato zásada před odesláním dalšího požadavku počká na zadaný interval. Další informace najdete v typu zásad pevného intervalu. |
Změna typu zásady opakování v návrháři
Na webu Azure Portal otevřete pracovní postup aplikace logiky v návrháři.
Na základě toho, jestli pracujete na pracovním postupu Consumption nebo Standard, otevřete Nastavení triggeru nebo akce.
Spotřeba: Na obrazci akce otevřete nabídku se třemi tečkami (...) a vyberte Nastavení.
Standardní: V návrháři vyberte akci. V podokně podrobností vyberte Nastavení.
Pokud trigger nebo akce podporuje zásady opakování, vyberte v části Zásady opakování požadovaný typ zásady.
Změna typu zásady opakování v editoru zobrazení kódu
V případě potřeby ověřte, jestli trigger nebo akce podporuje zásady opakování, a to dokončením předchozích kroků v návrháři.
Otevřete pracovní postup aplikace logiky v editoru zobrazení kódu.
V definici triggeru nebo akce přidejte
retryPolicyobjekt JSON do objektu triggeruinputsnebo akce. V opačném případě, pokud neexistuje žádnýretryPolicyobjekt, trigger nebo akce použije zásadudefaultopakování."inputs": { <...>, "retryPolicy": { "type": "<retry-policy-type>", // The following properties apply to specific retry policies. "count": <retry-attempts>, "interval": "<retry-interval>", "maximumInterval": "<maximum-interval>", "minimumInterval": "<minimum-interval>" }, <...> }, "runAfter": {}Povinní účastníci
Vlastnost Hodnota Typ Popis type<typ zásady opakování> String Typ zásady opakování, který se má použít: default,none,fixedneboexponentialcount<opakovaných pokusů> Integer exponentialUfixedtypů zásad je počet pokusů o opakování, což je hodnota od 1 do 90. Další informace najdete v tématu Pevný interval a Exponenciální interval.interval<interval opakování> String U fixedtypů zásad jeexponentialhodnota intervalu opakování ve formátu ISO 8601. Pro zásaduexponentialmůžete také zadat volitelné maximální a minimální intervaly. Další informace najdete v tématu Pevný interval a Exponenciální interval.
Spotřeba: 5 sekund (PT5S) až 1 den (P1D).
Standardní: Pro stavové pracovní postupy 5 sekund (PT5S) až 1 den (P1D). V případě bezstavových pracovních postupů 1 sekunda (PT1S) až 1 minuta (PT1M).Volitelné
Vlastnost Hodnota Typ Popis maximumInterval<maximální interval> String Pro zásadu exponentialje největší interval pro náhodně vybraný interval ve formátu ISO 8601. Výchozí hodnota je 1 den (P1D). Další informace najdete v tématu Exponential Interval.minimumInterval<minimální interval> String Pro zásadu exponentialnejmenší interval pro náhodně vybraný interval ve formátu ISO 8601. Výchozí hodnota je 5 sekund (PT5S). Další informace najdete v tématu Exponential Interval.
Výchozí zásady opakování
Připojení orové operace, které podporují zásady opakování, používají Výchozí zásady, pokud nevyberete jinou zásadu opakování. Pro většinu operací je výchozí zásadou opakování exponenciální interval, která odesílá až 4 opakování v exponenciálně rostoucích intervalech. Tyto intervaly se škálují o 7,5 sekund, ale jsou omezeny mezi 5 a 45 sekundami. Několik operací používá jinou výchozí zásadu opakování, například zásadu s pevným intervalem.
V definici pracovního postupu definice triggeru nebo akce explicitně nedefinuje výchozí zásady, ale následující příklad ukazuje, jak se výchozí zásady opakování chovají pro akci HTTP:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://myAPIendpoint/api/action",
"retryPolicy" : {
"type": "exponential",
"interval": "PT7S",
"count": 4,
"minimumInterval": "PT5S",
"maximumInterval": "PT1H"
}
},
"runAfter": {}
}
Žádné – žádné zásady opakování
Pokud chcete určit, že akce nebo aktivační událost neprovádí neúspěšné požadavky, nastavte <typ> zásady opakování na nonehodnotu .
Zásady opakování pevného intervalu
Pokud chcete určit, že akce nebo trigger před odesláním dalšího požadavku počká zadaný interval, nastavte <typ> zásady opakování na fixedhodnotu .
Příklad
Tato zásada opakování se pokusí získat nejnovější zprávy dvakrát po prvním neúspěšném požadavku s 30sekundovým zpožděním mezi jednotlivými pokusy:
"Get_latest_news": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://mynews.example.com/latest",
"retryPolicy": {
"type": "fixed",
"interval": "PT30S",
"count": 2
}
}
}
Zásady opakování exponenciálního intervalu
Zásada opakování exponenciálního intervalu určuje, že trigger nebo akce před odesláním dalšího požadavku počká na náhodný interval. Tento náhodný interval je vybrán z exponenciálně rostoucího rozsahu. Volitelně můžete výchozí minimální a maximální intervaly přepsat zadáním vlastního minimálního a maximálního intervalu na základě toho, jestli máte pracovní postup aplikace logiky Consumption nebo Standard.
| Název | Limit spotřeby | Standardní limit | Notes |
|---|---|---|---|
| Maximální zpoždění | Výchozí hodnota: 1 den | Výchozí hodnota: 1 hodina | Pokud chcete změnit výchozí limit v pracovním postupu aplikace logiky Consumption, použijte parametr zásady opakování. Pokud chcete změnit výchozí limit v pracovním postupu standardní aplikace logiky, přečtěte si téma Upravit nastavení hostitele a aplikace pro aplikace logiky v Azure Logic Apps s jedním tenantem. |
| Minimální zpoždění | Výchozí hodnota: 5 sekund | Výchozí hodnota: 5 sekund | Pokud chcete změnit výchozí limit v pracovním postupu aplikace logiky Consumption, použijte parametr zásady opakování. Pokud chcete změnit výchozí limit v pracovním postupu standardní aplikace logiky, přečtěte si téma Upravit nastavení hostitele a aplikace pro aplikace logiky v Azure Logic Apps s jedním tenantem. |
Náhodné rozsahy proměnných
V případě zásad opakování exponenciálního intervalu uvádí následující tabulka obecný algoritmus, který Azure Logic Apps používá k vygenerování jednotné náhodné proměnné v zadaném rozsahu pro každé opakování. Zadaný rozsah může být až do zadaného rozsahu a včetně počtu opakování.
| Číslo opakování | Minimální interval | Maximální interval |
|---|---|---|
| 0 | max(0, <minimální interval>) | min(interval, <maximální interval>) |
| 2 | max(interval, <minimální interval>) | min(2 * interval, <maximální interval>) |
| 3 | max(2 * interval, <minimální interval>) | min(4 * interval, <maximální interval>) |
| 4 | max(4 * interval, <minimální interval>) | min(8 * interval, <maximum-interval>) |
| .... | .... | .... |
Správa chování spustit po
Když přidáte akce v návrháři pracovního postupu, implicitně deklarujete pořadí, které se má použít pro spuštění těchto akcí. Po dokončení akce se tato akce označí stavem Úspěšné, Neúspěšné, Přeskočené nebo Vypršení časového limitu. Ve výchozím nastavení se akce, kterou přidáte v návrháři, spustí až po dokončení předchůdce se stavem Úspěch . V podkladové definici akce vlastnost určuje, že předchůdce akce, runAfter která musí nejprve dokončit, a stavy povolené pro daného předchůdce před spuštěním následníka.
Když akce vyvolá neošetřenou chybu nebo výjimku, akce se označí jako Neúspěšná a všechny následníky se označí jako Vynecháno. Pokud k tomuto chování dojde u akce s paralelními větvemi, modul Azure Logic Apps se řídí dalšími větvemi a určí jejich stav dokončení. Pokud například větev končí akcí Přeskočeno , stav dokončení této větve je založený na stavu přeskočené akce předchůdce. Po dokončení běhu pracovního postupu modul určí stav celého spuštění vyhodnocením všech stavů větve. Pokud nějaká větev skončí v selhání, označí se celé spuštění pracovního postupu jako Neúspěšné.
Pokud chcete mít jistotu, že akce může běžet i přes stav předchůdce, můžete změnit chování akce "spustit po", aby zvládla neúspěšné stavy předchůdce. Tímto způsobem se akce spustí, když je stav předchůdce úspěšný, neúspěšný, vynechán, časový limit nebo všechny tyto stavy.
Pokud chcete například spustit akci Odeslání e-mailu v Office 365 Outlooku po přidání řádku do akce předchůdce tabulky, která není úspěšná, změňte chování spustit po pomocí návrháře nebo editoru zobrazení kódu.
Poznámka:
V návrháři se nastavení Spustit po nevztahuje na akci, která bezprostředně následuje po triggeru, protože aktivační událost musí být úspěšně spuštěna před spuštěním první akce.
Změna chování spustit po v návrháři
Na webu Azure Portal otevřete pracovní postup aplikace logiky v návrháři.
V návrháři vyberte obrazec akce. V podokně podrobností vyberte Spustit po.
Podokno Spustit po zobrazuje předchozí akci pro aktuálně vybranou akci.
Rozbalte uzel akce předchůdce, abyste zobrazili všechny stavy "spustit po".
Ve výchozím nastavení je stav "spustit po" nastavený na úspěšný. Před spuštěním aktuálně vybrané akce tedy musí být akce předchůdce úspěšně spuštěna.
Změňte chování spustit po na požadovaný stav. Před zrušením výchozí možnosti se ujistěte, že nejprve vyberete možnost. Musíte mít vždy vybranou aspoň jednu možnost.
Následující příklad se nepovedl.
Pokud chcete určit, že aktuální akce se spustí bez ohledu na to, jestli je akce předchůdce označená jako Neúspěšná, Přeskočená nebo Časový limit, vyberte další stavy.
Pokud chcete vyžadovat, aby se spustilo více než jedna akce předchůdce, každý se stavem Spustit po, rozbalte seznam Vybrat akce . Vyberte požadované akce předchůdce a zadejte požadované stavy "spustit po".
Až budete připraveni, vyberte Hotovo.
Změna chování spustit po v editoru zobrazení kódu
Na webu Azure Portal otevřete pracovní postup aplikace logiky v editoru zobrazení kódu.
V definici JSON akce upravte
runAftervlastnost, která má následující syntaxi:"<action-name>": { "inputs": { "<action-specific-inputs>" }, "runAfter": { "<preceding-action>": [ "Succeeded" ] }, "type": "<action-type>" }V tomto příkladu
runAfterzměňte vlastnost zSucceeded:Failed"Send_an_email_(V2)": { "inputs": { "body": { "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>", "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}", "To": "Sophia.Owen@fabrikam.com" }, "host": { "connection": { "name": "@parameters('$connections')['office365']['connectionId']" } }, "method": "post", "path": "/v2/Mail" }, "runAfter": { "Add_a_row_into_a_table": [ "Failed" ] }, "type": "ApiConnection" }Chcete-li určit, zda je akce spuštěna bez ohledu na to, zda je akce předchůdce označena jako
FailedneboSkippedTimedOut, přidejte další stavy:"runAfter": { "Add_a_row_into_a_table": [ "Failed", "Skipped", "TimedOut" ] },
Vyhodnocení akcí s obory a jejich výsledky
Podobně jako spuštění kroků po jednotlivých akcích s nastavením Spustit po můžete akce seskupit dohromady v rámci oboru. Obory můžete použít, když chcete logicky seskupit akce dohromady, posoudit agregovaný stav oboru a provádět akce na základě tohoto stavu. Jakmile se všechny akce v oboru dokončí, získá samotný obor svůj vlastní stav.
Pokud chcete zkontrolovat stav oboru, můžete použít stejná kritéria, která používáte ke kontrole stavu spuštění pracovního postupu, jako je Úspěch, Selhání atd.
Pokud jsou všechny akce oboru úspěšné, stav oboru je ve výchozím nastavení označený jako Úspěch. Pokud je konečná akce v oboru označena jako Neúspěšná nebo přerušená, stav oboru se označí jako Neúspěšný.
Pokud chcete zachytit výjimky v oboru selhání a spustit akce, které tyto chyby zpracovávají, můžete použít nastavení Spustit po, které se nezdařilo . Pokud některé akce v oboru selžou a použijete pro tento obor nastavení Spustit po, můžete vytvořit jednu akci, která zachytí selhání.
Omezení oborů najdete v tématu Omezení a konfigurace.
Získání kontextu a výsledků selhání
I když je zachycení chyb z oboru užitečné, můžete také chtít další kontext, který vám pomůže zjistit přesné neúspěšné akce a případné chyby nebo stavové kódy. Funkce result() vrátí výsledky z akcí nejvyšší úrovně v omezené akci. Tato funkce přijme název oboru jako jediný parametr a vrátí pole s výsledky z těchto akcí nejvyšší úrovně. Tyto objekty akcí mají stejné atributy jako atributy vrácené actions() funkcí, jako je počáteční čas akce, čas ukončení, stav, vstupy, ID korelace a výstupy.
Poznámka:
Funkce result() vrátí výsledky pouze z akcí nejvyšší úrovně a ne z hlubších vnořených akcí, jako jsou akce přepínače nebo podmínky.
Pokud chcete získat kontext o akcích, které selhaly v oboru, můžete použít @result() výraz s názvem oboru a nastavením Spustit po. Chcete-li filtrovat vrácené pole na akce, které mají stav Selhání, můžete přidat akci Filtrovat pole. Pokud chcete spustit akci pro vrácenou neúspěšnou akci, proveďte vrácené filtrované pole a použijte smyčku Pro každou smyčku.
Následující příklad JSON odešle požadavek HTTP POST s textem odpovědi pro všechny akce, které selhaly v rámci akce oboru s názvem My_Scope. Podrobné vysvětlení následuje v příkladu.
"Filter_array": {
"type": "Query",
"inputs": {
"from": "@result('My_Scope')",
"where": "@equals(item()['status'], 'Failed')"
},
"runAfter": {
"My_Scope": [
"Failed"
]
}
},
"For_each": {
"type": "foreach",
"actions": {
"Log_exception": {
"type": "Http",
"inputs": {
"method": "POST",
"body": "@item()['outputs']['body']",
"headers": {
"x-failed-action-name": "@item()['name']",
"x-failed-tracking-id": "@item()['clientTrackingId']"
},
"uri": "http://requestb.in/"
},
"runAfter": {}
}
},
"foreach": "@body('Filter_array')",
"runAfter": {
"Filter_array": [
"Succeeded"
]
}
}
Následující kroky popisují, co se stane v tomto příkladu:
Chcete-li získat výsledek ze všech akcí uvnitř My_Scope, akce Filtrovat pole používá tento výraz filtru:
@result('My_Scope')Podmínka pro pole filtru je libovolná
@result()položka, která má stav rovenFailed. Tato podmínka filtruje pole, které má výsledky všech akcí z My_Scope dolů na pole s pouze neúspěšnými výsledky akce.For_eachProveďte akci smyčky s filtrovanými výstupy pole. Tento krok provede akci pro každý výsledek neúspěšné akce, který byl dříve filtrován.Pokud jedna akce v oboru selže, akce ve
For_eachsmyčce se spustí pouze jednou. Několik neúspěšných akcí způsobí jednu akci na selhání.Odešle funkci HTTP POST v
For_eachtextu odpovědi položky, což je@item()['outputs']['body']výraz.Obrazec
@result()položky je stejný jako@actions()obrazec a dá se analyzovat stejným způsobem.Zahrňte dvě vlastní hlavičky s názvem neúspěšné akce (
@item()['name']) a ID sledování neúspěšného spuštění klienta (@item()['clientTrackingId']).
Tady je příklad jedné @result() položky, která ukazuje namebody, a clientTrackingId vlastnosti, které jsou analyzovány v předchozím příkladu. For_each Mimo akci @result() vrátí pole těchto objektů.
{
"name": "Example_Action_That_Failed",
"inputs": {
"uri": "https://myfailedaction.azurewebsites.net",
"method": "POST"
},
"outputs": {
"statusCode": 404,
"headers": {
"Date": "Thu, 11 Aug 2016 03:18:18 GMT",
"Server": "Microsoft-IIS/8.0",
"X-Powered-By": "ASP.NET",
"Content-Length": "68",
"Content-Type": "application/json"
},
"body": {
"code": "ResourceNotFound",
"message": "/docs/folder-name/resource-name does not exist"
}
},
"startTime": "2016-08-11T03:18:19.7755341Z",
"endTime": "2016-08-11T03:18:20.2598835Z",
"trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
"clientTrackingId": "08587307213861835591296330354",
"code": "NotFound",
"status": "Failed"
}
Pokud chcete provádět různé vzory zpracování výjimek, můžete použít výrazy popsané v tomto článku. Můžete se rozhodnout spustit jednu akci zpracování výjimek mimo obor, který přijímá celé filtrované pole selhání, a akci odebrat For_each . Můžete také zahrnout další užitečné vlastnosti z \@result() odpovědi, jak jsme popsali dříve.
Nastavení protokolů služby Azure Monitor
Předchozí vzory jsou užitečné způsoby zpracování chyb a výjimek, ke kterým dochází během spuštění. Můžete ale také identifikovat chyby, ke kterým dochází nezávisle na spuštění, a reagovat na ně. Pokud chcete vyhodnotit stav spuštění, můžete monitorovat protokoly a metriky spuštění nebo je publikovat do libovolného nástroje pro monitorování, který dáváte přednost.
Azure Monitor například nabízí zjednodušený způsob odesílání všech událostí pracovního postupu, včetně všech stavů spuštění a akcí, do cíle. Ve službě Azure Monitor můžete nastavit upozornění na konkrétní metriky a prahové hodnoty. Události pracovního postupu můžete také odesílat do pracovního prostoru služby Log Analytics nebo do účtu úložiště Azure. Nebo můžete streamovat všechny události prostřednictvím služby Azure Event Hubs do Azure Stream Analytics. V Stream Analytics můžete psát živé dotazy na základě jakýchkoli anomálií, průměrů nebo selhání z diagnostických protokolů. Stream Analytics můžete použít k odesílání informací do jiných zdrojů dat, jako jsou fronty, témata, SQL, Azure Cosmos DB nebo Power BI.
Další informace najdete v tématu Nastavení protokolů služby Azure Monitor a shromažďování diagnostických dat pro Azure Logic Apps.