Fouten en uitzonderingen in Azure Logic Apps afhandelen
Van toepassing op: Azure Logic Apps (Verbruik + Standard)
De manier waarop elke integratiearchitectuur downtime of problemen die worden veroorzaakt door afhankelijke systemen, op de juiste wijze afhandelt, kan een uitdaging vormen. Azure Logic Apps biedt een eersteklas ervaring voor het afhandelen van fouten en uitzonderingen om robuuste integraties te maken die problemen en fouten probleemloos verwerken.
Beleid opnieuw proberen
Voor de meest eenvoudige uitzonderings- en foutafhandeling kunt u het beleid voor opnieuw proberen gebruiken wanneer dit wordt ondersteund voor een trigger of actie, zoals de HTTP-actie. Als er een time-out optreedt of mislukt voor de oorspronkelijke aanvraag van de trigger of actie, wat resulteert in een 408-, 429- of 5xx-antwoord, geeft het beleid voor opnieuw proberen aan dat de trigger of actie de aanvraag opnieuw verzendt per beleidsinstellingen.
Beleidslimieten voor opnieuw proberen
Raadpleeg beleidslimieten voor opnieuw proberen voor meer informatie over beleid voor opnieuw proberen, instellingen, limieten en andere opties.
Beleidstypen opnieuw proberen
Connectorbewerkingen die ondersteuning bieden voor beleid voor opnieuw proberen, gebruiken het standaardbeleid , tenzij u een ander beleid voor opnieuw proberen selecteert.
| Beleid voor opnieuw proberen | Beschrijving |
|---|---|
| Standaard | Voor de meeste bewerkingen is het standaardbeleid voor opnieuw proberen een beleid voor exponentieel interval dat maximaal 4 nieuwe pogingen verzendt met exponentieel toenemende intervallen. Deze intervallen worden geschaald met 7,5 seconden, maar liggen tussen 5 en 45 seconden. Verschillende bewerkingen maken gebruik van een ander standaardbeleid voor opnieuw proberen, zoals een beleid voor vast interval. Raadpleeg het beleidstype Standaardbeleid voor opnieuw proberen voor meer informatie. |
| Geen | Verzend de aanvraag niet opnieuw. Raadpleeg Geen - Beleid voor opnieuw proberen voor meer informatie. |
| Exponentieel interval | Met dit beleid wordt een willekeurig interval gewacht, dat is geselecteerd uit een exponentieel toenemend bereik voordat de volgende aanvraag wordt verzonden. Raadpleeg het beleidstype exponentiële interval voor meer informatie. |
| Vast interval | Dit beleid wacht het opgegeven interval voordat de volgende aanvraag wordt verzonden. Raadpleeg het beleidstype vast interval voor meer informatie. |
Beleidstype voor opnieuw proberen wijzigen in de ontwerpfunctie
Open uw werkstroom voor logische apps in Azure Portal in de ontwerpfunctie.
Open de instellingen van de trigger of actie op basis van of u aan een werkstroom Verbruik of Standaard werkt.
Verbruik: Open in de actievorm het beletseltekenmenu (...) en selecteer Instellingen.
Standaard: Selecteer de actie in de ontwerpfunctie. Selecteer Instellingen in het detailvenster.
Als de trigger of actie beleid voor opnieuw proberen ondersteunt, selecteert u onder Beleid voor opnieuw proberen het gewenste beleidstype.
Beleidstype voor opnieuw proberen wijzigen in de codeweergave-editor
Controleer indien nodig of de trigger of actie beleid voor opnieuw proberen ondersteunt door de eerdere stappen in de ontwerpfunctie uit te voeren.
Open uw werkstroom voor logische apps in de codeweergave-editor.
Voeg in de definitie van de trigger of actie het
retryPolicyJSON-object toe aan het object vaninputsdie trigger of actie. Als er geenretryPolicyobject bestaat, gebruikt de trigger of actie hetdefaultbeleid voor opnieuw proberen."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": {}Vereist
Eigenschappen Weergegeven als Type Description type<type beleid opnieuw proberen> String Het beleidstype voor opnieuw proberen dat moet worden gebruikt: default,none,fixedofexponentialcount<nieuwe pogingen> Geheel getal Voor fixedenexponentialbeleidstypen is het aantal nieuwe pogingen, een waarde van 1 - 90. Raadpleeg vast interval en exponentieel interval voor meer informatie.interval<interval voor opnieuw proberen> String Voor fixedenexponentialbeleidstypen is de intervalwaarde voor opnieuw proberen in ISO 8601-indeling. Voor hetexponentialbeleid kunt u ook optionele maximum- en minimumintervallen opgeven. Raadpleeg vast interval en exponentieel interval voor meer informatie.
Verbruik: 5 seconden (PT5S) tot 1 dag (P1D).
Standaard: Voor stateful werkstromen: 5 seconden (PT5S) tot 1 dag (P1D). Voor staatloze werkstromen, 1 seconde (PT1S) tot 1 minuut (PT1M).Optioneel
Eigenschappen Weergegeven als Type Description maximumInterval<maximuminterval> String Voor het exponentialbeleid is het grootste interval voor het willekeurig geselecteerde interval in ISO 8601-indeling. De standaardwaarde is 1 dag (P1D). Raadpleeg exponentieel interval voor meer informatie.minimumInterval<minimuminterval> String Voor het exponentialbeleid is het kleinste interval voor het willekeurig geselecteerde interval in ISO 8601-indeling. De standaardwaarde is 5 seconden (PT5S). Raadpleeg exponentieel interval voor meer informatie.
Standaard beleid voor opnieuw proberen
Connectorbewerkingen die ondersteuning bieden voor beleid voor opnieuw proberen, gebruiken het standaardbeleid , tenzij u een ander beleid voor opnieuw proberen selecteert. Voor de meeste bewerkingen is het standaardbeleid voor opnieuw proberen een beleid voor exponentieel interval dat maximaal 4 nieuwe pogingen verzendt met exponentieel toenemende intervallen. Deze intervallen worden geschaald met 7,5 seconden, maar liggen tussen 5 en 45 seconden. Verschillende bewerkingen maken gebruik van een ander standaardbeleid voor opnieuw proberen, zoals een beleid voor vast interval.
In uw werkstroomdefinitie definieert de trigger- of actiedefinitie niet expliciet het standaardbeleid, maar in het volgende voorbeeld ziet u hoe het standaardbeleid voor opnieuw proberen zich gedraagt voor de HTTP-actie:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://myAPIendpoint/api/action",
"retryPolicy" : {
"type": "exponential",
"interval": "PT7S",
"count": 4,
"minimumInterval": "PT5S",
"maximumInterval": "PT1H"
}
},
"runAfter": {}
}
Geen - Beleid voor opnieuw proberen
Als u wilt opgeven dat de actie of trigger mislukte aanvragen niet opnieuw probeert, stelt u het <type> beleid voor opnieuw proberen in op none.
Beleid voor opnieuw proberen met vast interval
Als u wilt opgeven dat de actie of trigger het opgegeven interval wacht voordat de volgende aanvraag wordt verzonden, stelt u het <type> beleid voor opnieuw proberen in op fixed.
Voorbeeld
Dit beleid voor opnieuw proberen probeert het laatste nieuws nog twee keer te krijgen na de eerste mislukte aanvraag met een vertraging van 30 seconden tussen elke poging:
"Get_latest_news": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://mynews.example.com/latest",
"retryPolicy": {
"type": "fixed",
"interval": "PT30S",
"count": 2
}
}
}
Beleid voor opnieuw proberen van exponentieel interval
Het beleid voor het opnieuw proberen van exponentiële interval geeft aan dat de trigger of actie een willekeurig interval wacht voordat de volgende aanvraag wordt verzonden. Dit willekeurige interval wordt geselecteerd uit een exponentieel groeiend bereik. U kunt desgewenst de standaardintervallen voor minimum- en maximumwaarden overschrijven door uw eigen minimum- en maximumintervallen op te geven, op basis van of u een werkstroom voor logische apps voor Verbruik of Standaard hebt.
| Naam | Verbruikslimiet | Standaardlimiet | Opmerkingen |
|---|---|---|---|
| Maximale vertraging | Standaard: 1 dag | Standaard: 1 uur | Als u de standaardlimiet in een werkstroom voor logische verbruiks-apps wilt wijzigen, gebruikt u de beleidsparameter voor opnieuw proberen. Als u de standaardlimiet in een standaardwerkstroom voor logische apps wilt wijzigen, raadpleegt u Host- en app-instellingen bewerken voor logische apps in Azure Logic Apps met één tenant. |
| Minimale vertraging | Standaard: 5 sec. | Standaard: 5 sec. | Als u de standaardlimiet in een werkstroom voor logische verbruiks-apps wilt wijzigen, gebruikt u de beleidsparameter voor opnieuw proberen. Als u de standaardlimiet in een standaardwerkstroom voor logische apps wilt wijzigen, raadpleegt u Host- en app-instellingen bewerken voor logische apps in Azure Logic Apps met één tenant. |
Willekeurige variabelenbereiken
Voor het beleid voor exponentieel interval voor opnieuw proberen toont de volgende tabel het algemene algoritme dat Azure Logic Apps gebruikt voor het genereren van een uniforme willekeurige variabele in het opgegeven bereik voor elke nieuwe poging. Het opgegeven bereik kan maximaal en inclusief het aantal nieuwe pogingen zijn.
| Nummer opnieuw proberen | Minimuminterval | Maximuminterval |
|---|---|---|
| 1 | max(0, <minimuminterval>) | min(interval, <maximuminterval>) |
| 2 | max(interval, <minimuminterval>) | min(2 * interval, <maximuminterval>) |
| 3 | max(2 * interval, <minimuminterval>) | min(4 * interval, <maximuminterval>) |
| 4 | max(4 * interval, <minimuminterval>) | min(8 * interval, <maximuminterval>) |
| .... | .... | .... |
Het gedrag 'uitvoeren na' beheren
Wanneer u acties toevoegt in de werkstroomontwerper, declareert u impliciet de volgorde die moet worden gebruikt voor het uitvoeren van deze acties. Nadat een actie is uitgevoerd, wordt die actie gemarkeerd met een status zoals Geslaagd, Mislukt, Overgeslagen of TimedOut. Een actie die u in de ontwerpfunctie toevoegt, wordt standaard pas uitgevoerd nadat de voorafgaande taak is voltooid met de status Geslaagd . In de onderliggende definitie van een actie geeft de runAfter eigenschap aan dat de voorafgaande actie die eerst moet worden voltooid en de statussen die zijn toegestaan voor die voorafgaande actie voordat de opvolgende actie kan worden uitgevoerd.
Wanneer een actie een niet-verwerkte fout of uitzondering genereert, wordt de actie gemarkeerd Mislukt en wordt een opvolgende actie gemarkeerd als Overgeslagen. Als dit gedrag gebeurt voor een actie met parallelle vertakkingen, volgt de Azure Logic Apps-engine de andere vertakkingen om de voltooiingsstatussen te bepalen. Als een vertakking bijvoorbeeld eindigt op een overgeslagen actie, is de voltooiingsstatus van die vertakking gebaseerd op de voorafgaande status van de overgeslagen actie. Nadat de uitvoering van de werkstroom is voltooid, bepaalt de engine de status van de hele uitvoering door alle vertakkingsstatussen te evalueren. Als een vertakking mislukt, wordt de hele werkstroomuitvoering gemarkeerd als Mislukt.
Om ervoor te zorgen dat een actie nog steeds kan worden uitgevoerd ondanks de status van de voorafgaande taak, kunt u het gedrag van een actie 'uitvoeren na' wijzigen om de mislukte statussen van de voorafgaande taak af te handelen. Op die manier wordt de actie uitgevoerd wanneer de status van de voorafgaande taak is geslaagd, Mislukt, Overgeslagen, TimedOut of al deze statussen.
Als u bijvoorbeeld office 365 Outlook een e-mailactie wilt verzenden nadat de excel onlineactie Een rij toevoegen aan een tabel voorafgaande actie is gemarkeerd als Mislukt in plaats van Geslaagd, wijzigt u het gedrag 'uitvoeren na' met behulp van de editor voor de ontwerpfunctie of codeweergave.
Notitie
In de ontwerpfunctie is de instelling Uitvoeren na niet van toepassing op de actie die direct na de trigger volgt, omdat de trigger moet worden uitgevoerd voordat de eerste actie kan worden uitgevoerd.
Gedrag 'uitvoeren na' wijzigen in de ontwerpfunctie
Open in Azure Portal de werkstroom van de logische app in de ontwerpfunctie.
Selecteer de actieshape in de ontwerpfunctie. Selecteer Uitvoeren na in het detailvenster.
In het deelvenster Uitvoeren na ziet u de voorafgaande actie voor de geselecteerde actie.
Vouw het knooppunt van de voorafgaande actie uit om alle statussen 'uitvoeren na' weer te geven.
De status 'uitvoeren na' is standaard ingesteld op Geslaagd. De voorafgaande actie moet dus worden uitgevoerd voordat de geselecteerde actie kan worden uitgevoerd.
Wijzig het gedrag 'uitvoeren na' in de gewenste status. Zorg ervoor dat u eerst een optie selecteert voordat u de standaardoptie wist. U moet altijd ten minste één optie hebben geselecteerd.
Het volgende voorbeeld is mislukt.
Als u wilt opgeven dat de huidige actie wordt uitgevoerd of de voorafgaande actie is gemarkeerd als Mislukt, Overgeslagen of TimedOut, selecteert u de andere statussen.
Als u wilt vereisen dat meer dan één voorafgaande actie wordt uitgevoerd, elk met hun eigen status 'uitvoeren na', vouwt u de lijst Acties selecteren uit. Selecteer de gewenste voorafgaande acties en geef de vereiste status 'uitvoeren na' op.
Wanneer u klaar bent, selecteert u Gereed.
Gedrag 'uitvoeren na' wijzigen in de codeweergave-editor
Open uw werkstroom voor logische apps in azure Portal in de codeweergave-editor.
Bewerk in de JSON-definitie van de actie de
runAftereigenschap met de volgende syntaxis:"<action-name>": { "inputs": { "<action-specific-inputs>" }, "runAfter": { "<preceding-action>": [ "Succeeded" ] }, "type": "<action-type>" }In dit voorbeeld wijzigt u de
runAftereigenschap vanSucceeded: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" }Als u wilt opgeven dat de actie wordt uitgevoerd, ongeacht of de voorafgaande actie is gemarkeerd als
Failed,SkippedofTimedOutvoeg de andere statussen toe:"runAfter": { "Add_a_row_into_a_table": [ "Failed", "Skipped", "TimedOut" ] },
Acties evalueren met bereiken en hun resultaten
Net als bij het uitvoeren van stappen na afzonderlijke acties met de instelling Uitvoeren na, kunt u acties groeperen binnen een bereik. U kunt bereiken gebruiken wanneer u acties logisch wilt groeperen, de statistische status van het bereik wilt beoordelen en acties wilt uitvoeren op basis van die status. Nadat alle acties in een bereik zijn uitgevoerd, krijgt het bereik zelf de eigen status.
Als u de status van een bereik wilt controleren, kunt u dezelfde criteria gebruiken die u gebruikt om de uitvoeringsstatus van een werkstroom te controleren, zoals Geslaagd, Mislukt, enzovoort.
Wanneer alle acties van het bereik zijn geslaagd, wordt de status van het bereik standaard gemarkeerd als Geslaagd. Als de laatste actie in een bereik is gemarkeerd als Mislukt of Afgebroken, wordt de status van het bereik gemarkeerd als Mislukt.
Als u uitzonderingen in een mislukt bereik wilt ondervangen en acties wilt uitvoeren die deze fouten verwerken, kunt u de instelling Uitvoeren na gebruiken die het bereik Mislukt heeft . Als er acties in het bereik mislukken en u de instelling 'uitvoeren na' voor dat bereik gebruikt, kunt u één actie maken om fouten te ondervangen.
Zie Limieten en configuratie voor limieten voor bereiken.
Context en resultaten ophalen voor fouten
Hoewel het vangen van fouten uit een bereik nuttig is, wilt u mogelijk ook meer context om u te helpen de exacte mislukte acties plus eventuele fouten of statuscodes te leren. De result() functie retourneert de resultaten van de acties op het hoogste niveau in een bereikactie. Deze functie accepteert de naam van het bereik als één parameter en retourneert een matrix met de resultaten van die acties op het hoogste niveau. Deze actieobjecten hebben dezelfde kenmerken als de kenmerken die door de actions() functie worden geretourneerd, zoals de begintijd, eindtijd, status, invoer, correlatie-id's en uitvoer van de actie.
Notitie
De result() functie retourneert alleen de resultaten van de acties op het hoogste niveau en niet van diepere geneste acties, zoals switch- of voorwaardeacties.
Als u context wilt ophalen over de acties die zijn mislukt in een bereik, kunt u de expressie gebruiken met de @result() naam van het bereik en de instelling Uitvoeren na. Als u de geretourneerde matrix wilt filteren op acties met de status Mislukt, kunt u de actie Matrix filteren. Als u een actie wilt uitvoeren voor een geretourneerde mislukte actie, voert u de geretourneerde gefilterde matrix uit en gebruikt u een voor elke lus.
In het volgende JSON-voorbeeld wordt een HTTP POST-aanvraag met de antwoordtekst verzonden voor acties die zijn mislukt binnen de bereikactie met de naam My_Scope. Een gedetailleerde uitleg volgt het voorbeeld.
"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"
]
}
}
In de volgende stappen wordt beschreven wat er in dit voorbeeld gebeurt:
Als u het resultaat van alle acties in My_Scope wilt ophalen, gebruikt de actie Matrixfilter deze filterexpressie:
@result('My_Scope')De voorwaarde voor Filtermatrix is een
@result()item met een status die gelijk is aanFailed. Deze voorwaarde filtert de matrix met alle actieresultaten van My_Scope omlaag naar een matrix met alleen de mislukte actieresultaten.Voer een
For_eachlusactie uit op de gefilterde matrixuitvoer . Met deze stap wordt een actie uitgevoerd voor elk mislukte actieresultaat dat eerder is gefilterd.Als één actie in het bereik mislukt, worden de acties in de
For_eachlus slechts één keer uitgevoerd. Meerdere mislukte acties veroorzaken één actie per fout.Verzend een HTTP POST op de hoofdtekst van het antwoord van het
For_eachitem. Dit is de@item()['outputs']['body']expressie.De
@result()itemshape is hetzelfde als de@actions()shape en kan op dezelfde manier worden geparseerd.Neem twee aangepaste headers op met de naam van de mislukte actie (
@item()['name']) en de tracerings-id van de mislukte client (@item()['clientTrackingId']).
Ter referentie: hier volgt een voorbeeld van één @result() item, waarin de name, bodyen clientTrackingId eigenschappen worden weergegeven die in het vorige voorbeeld worden geparseerd. Buiten een For_each actie wordt @result() een matrix van deze objecten geretourneerd.
{
"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"
}
Als u verschillende patronen voor uitzonderingsafhandeling wilt uitvoeren, kunt u de expressies gebruiken die eerder in dit artikel zijn beschreven. U kunt ervoor kiezen om één uitzonderingsafhandelingsactie uit te voeren buiten het bereik dat de hele gefilterde matrix met fouten accepteert en de For_each actie verwijdert. U kunt ook andere nuttige eigenschappen uit het \@result() antwoord opnemen zoals eerder beschreven.
Azure Monitor-logboeken instellen
De vorige patronen zijn handige manieren om fouten en uitzonderingen af te handelen die plaatsvinden binnen een uitvoering. U kunt echter ook fouten identificeren en erop reageren die onafhankelijk van de uitvoering optreden. Als u uitvoeringsstatussen wilt evalueren, kunt u de logboeken en metrische gegevens voor uw uitvoeringen bewaken of publiceren in elk bewakingsprogramma dat u wilt gebruiken.
Azure Monitor biedt bijvoorbeeld een gestroomlijnde manier om alle werkstroomgebeurtenissen, inclusief alle uitvoerings- en actiestatussen, naar een bestemming te verzenden. U kunt waarschuwingen instellen voor specifieke metrische gegevens en drempelwaarden in Azure Monitor. U kunt ook werkstroomevenementen verzenden naar een Log Analytics-werkruimte of Een Azure-opslagaccount. U kunt ook alle gebeurtenissen streamen via Azure Event Hubs naar Azure Stream Analytics. In Stream Analytics kunt u livequery's schrijven op basis van afwijkingen, gemiddelden of fouten uit de diagnostische logboeken. U kunt Stream Analytics gebruiken om informatie te verzenden naar andere gegevensbronnen, zoals wachtrijen, onderwerpen, SQL, Azure Cosmos DB of Power BI.
Zie Azure Monitor-logboeken instellen en diagnostische gegevens verzamelen voor Azure Logic Apps voor meer informatie.