Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 als deze mogelijkheid bestaat op een trigger of actie, zoals de HTTP-actie. Als de oorspronkelijke aanvraag van de trigger of actie een time-out krijgt of mislukt, wat resulteert in een 408-, 429- of 5xx-reactie, bepaalt het nieuw-proberenbeleid dat de trigger of actie de aanvraag opnieuw verzendt volgens de beleidsinstellingen.
Limieten voor beleid voor nieuwe pogingen
Raadpleeg Limieten voor beleid voor nieuwe pogingen voor meer informatie over beleid voor nieuwe pogingen, 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 aangepast in stappen van 7,5 seconden, maar zijn begrensd tot minimaal 5 en maximaal 45 seconden. Verschillende bewerkingen maken gebruik van een ander standaardbeleid voor opnieuw proberen, zoals een beleid voor vast interval. Zie type standaardbeleid voor opnieuw proberen voor meer informatie. |
| Geen | Verzend de aanvraag niet opnieuw. Raadpleeg Geen - 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. Zie voor meer informatie het beleidstype voor exponentiële intervallen. |
| Vast interval | Dit beleid wacht het opgegeven interval voordat de volgende aanvraag wordt verzonden. Raadpleeg het beleidstype voor vaste intervallen voor meer informatie. |
Type beleid voor opnieuw proberen wijzigen in de designer
Open uw logische app-resource in Azure Portal.
In de resource-zijbalk voert u de onderstaande stappen uit om de workflow-ontwerper te openen voor uw Logic App:
Verbruik: Selecteer onder Ontwikkelhulpprogramma's de ontwerpfunctie om uw werkstroom te openen.
Standaard
Selecteer Werkstromen onder Werkstromen.
Selecteer uw werkstroom op de pagina Werkstromen .
Selecteer onder Extra de ontwerpfunctie om uw werkstroom te openen.
Op de trigger of actie waarbij u het type herhaalbeleid wilt wijzigen, volgt u deze stappen om de instellingen te openen.
Selecteer de bewerking in de ontwerpinterface.
Selecteer Instellingen in het deelvenster met bewerkingsgegevens.
Selecteer onder Netwerken onder Beleid voor opnieuw proberen het gewenste beleidstype.
Het type beleid voor nieuwe pogingen wijzigen in de editor voor codeweergave
Controleer 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 trigger- of actiedefinitie het
retryPolicyJSON-object toe aan het object vaninputsde 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
Eigenschap Waarde Type Beschrijving type< type beleid opnieuw proberen> Snaar / Touwtje 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> Snaar / Touwtje Voor fixed- enexponential-beleidstypes de waarde van het interval voor nieuwe pogingen 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 werkstromen met status: 5 seconden (PT5S) tot 1 dag (P1D). Voor staatloze werkstromen, 1 seconde (PT1S) tot 1 minuut (PT1M).Optioneel
Eigenschap Waarde Type Beschrijving maximumInterval< Maximum-interval> Snaar / Touwtje Voor het exponential-beleid, het maximale interval voor het willekeurig geselecteerde interval in ISO 8601-notatie. De standaardwaarde is 1 dag (P1D). Raadpleeg exponentieel interval voor meer informatie.minimumInterval< minimuminterval> Snaar / Touwtje Voor het beleid exponentialgeldt het kleinste interval voor het willekeurig gekozen interval in ISO 8601-notatie. 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 aangepast in stappen van 7,5 seconden, maar zijn begrensd tot minimaal 5 en maximaal 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 - 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
}
}
}
Herhalingsbeleid met exponentieel toenemende intervallen
Het beleid voor nieuwe pogingen met exponentieel interval specificeert dat de trigger of actie een willekeurige tijdsduur afwacht voordat het volgende verzoek 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 de workflow van een Consumption-logische app wilt wijzigen, gebruikt u de parameter voor het beleid voor opnieuw proberen. Als u de standaardlimiet in een werkstroom van een Standard-logische app 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 de workflow van een Consumption-logische app wilt wijzigen, gebruikt u de parameter voor het beleid voor opnieuw proberen. Als u de standaardlimiet in een werkstroom van een Standard-logische app 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 opnieuw proberen met exponentiële intervallen toont de onderstaande tabel het algemene algoritme dat Azure Logic Apps gebruikt om bij elke nieuwe poging een gelijkmatig verdeelde toevalsvariabele binnen het opgegeven bereik te genereren. Het opgegeven bereik kan maximaal en inclusief het aantal nieuwe pogingen zijn.
| Nummer opnieuw proberen | Minimuminterval | Maximuminterval |
|---|---|---|
| 1 | max(0, <minimum-interval>) | min(interval, <maximum-interval>) |
| 2 | max(interval, <minimuminterval>) | min(2 * interval, <maximum-interval>) |
| 3 | max(2 * interval, <minimuminterval>) | min(4 * interval, <maximum-interval>) |
| 4 | max(4 * interval, <minimum-interval>) | min(8 * interval, <maximum-interval>) |
| .... | .... | .... |
Het gedrag 'uitvoeren na' beheren
Wanneer u acties toevoegt in de werkstroomontwerper, declareert u impliciet de volgorde voor het uitvoeren van deze acties. Nadat een actie is uitgevoerd, wordt die actie gemarkeerd met een status zoals Geslaagd, Mislukt, Overgeslagen of TimedOut. Met andere woorden, de voorafgaande actie moet eerst eindigen met een van de toegestane statussen voordat de opvolgende actie kan worden uitgevoerd.
Een actie die u in de ontwerpfunctie toevoegt, wordt standaard alleen uitgevoerd als de voorgaande actie is voltooid met de status Geslaagd . Deze na-uitvoerings gedrag specificeert nauwkeurig de volgorde van uitvoering voor acties in een werkstroom.
In de ontwerpfunctie kunt u het standaardgedrag 'uitvoeren na' voor een actie wijzigen door de instelling Uitvoeren na de actie te bewerken. Deze instelling is alleen beschikbaar voor volgende acties die de eerste actie in een werkstroom volgen. De eerste actie in een workflow wordt altijd uitgevoerd zodra de trigger met succes is uitgevoerd. De instelling Uitvoeren na is dus niet beschikbaar en is niet van toepassing op de eerste actie.
In de onderliggende JSON-definitie van een actie is de instelling Na uitvoeren hetzelfde als de eigenschap runAfter. Met deze eigenschap geeft u een of meer voorafgaande acties op die eerst moeten worden voltooid met de specifieke toegestane statussen voordat de opvolgende actie kan worden uitgevoerd. De runAfter eigenschap is een JSON-object dat flexibiliteit biedt door alle voorafgaande acties op te geven die moeten worden voltooid voordat de opvolgende actie wordt uitgevoerd. Dit object definieert ook een matrix met acceptabele statussen.
Als u bijvoorbeeld een actie wilt uitvoeren nadat de actie A slaagt en ook nadat de actie B slaagt of mislukt wanneer u aan de JSON-definitie van een actie werkt, stelt u de volgende runAfter eigenschap in:
{
// Other parts in action definition
"runAfter": {
"Action A": ["Succeeded"],
"Action B": ["Succeeded", "Failed"]
}
}
Gedrag voor foutafhandeling na uitvoeren
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 workflowuitvoering is afgerond, bepaalt de engine de status van de volledige uitvoering door de statussen van alle vertakkingen 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 voorganger, kunt u het 'uitvoeren na'-gedrag van een actie wijzigen zodat ook niet-succesvolle statussen van de voorganger worden verwerkt. 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 de Office 365 Outlook-actie Een e-mail verzenden wilt uitvoeren nadat de voorgaande Excel Online-actie Een rij toevoegen aan een tabel is gemarkeerd als Mislukt in plaats van Geslaagd, wijzigt u het gedrag voor 'uitvoeren na' met behulp van de ontwerpfunctie of de codeweergave-editor.
Gedrag 'uitvoeren na' wijzigen in de ontwerpfunctie
Open uw logische app-resource in Azure Portal.
In de resource-zijbalk voert u de onderstaande stappen uit om de workflow-ontwerper te openen voor uw Logic App:
Verbruik: Selecteer onder Ontwikkelhulpprogramma's de ontwerpfunctie om uw werkstroom te openen.
Standaard
Selecteer Werkstromen in de zijbalk van de resource onder Werkstromen.
Selecteer uw werkstroom op de pagina Werkstromen .
Selecteer onder Extra de ontwerpfunctie om uw werkstroom te openen.
Op de trigger of actie waar u de "run after"-gedrag wilt wijzigen, volgt u deze stappen om de instellingen van de bewerking te openen:
Selecteer de bewerking in de ontwerpinterface.
Selecteer Instellingen in het deelvenster met bewerkingsgegevens.
De sectie Uitvoeren na bevat een lijst acties selecteren, waarin de beschikbare voorafgaande bewerkingen voor de momenteel geselecteerde bewerking worden weergegeven, bijvoorbeeld:
Vouw onder de lijst Acties selecteren de huidige voorafgaande bewerking uit. Dit is HTTP in dit voorbeeld:
Standaard is de status 'uitvoeren na' ingesteld op Is geslaagd. Deze waarde betekent dat de voorafgaande bewerking moet worden voltooid voordat de huidige actie kan worden uitgevoerd.
Als u het gedrag 'uitvoeren na' wilt wijzigen in de gewenste statussen, selecteert u deze statussen.
Het volgende voorbeeld selecteert Is mislukt.
Als u wilt opgeven dat de huidige bewerking alleen wordt uitgevoerd wanneer de voorafgaande actie is voltooid met de mislukte bewerking, is overgeslagen of de status van een time-out heeft opgetreden , selecteert u deze statussen en schakelt u vervolgens de standaardstatus uit, bijvoorbeeld:
Notitie
Voordat u de standaard status verwijdert, moet u eerst een andere status selecteren. U moet altijd ten minste één status hebben geselecteerd.
Als u wilt vereisen dat meerdere voorafgaande bewerkingen worden uitgevoerd en voltooid, elk met hun eigen status 'uitvoeren na', voert u de volgende stappen uit:
Open de lijst Select acties en selecteer de voorafgaande bewerkingen die u wilt.
Selecteer de status 'uitvoeren na' voor elke bewerking.
Wanneer u klaar bent, sluit u het bewerkingsinformatievenster.
Het gedrag van “uitvoeren na” wijzigen in de editor voor codeweergave
Voer in de zijbalk van de resource de volgende stappen uit om de codeweergave-editor te openen, op basis van uw logische app:
Verbruik: Selecteer onder Ontwikkelhulpprogramma's de codeweergave om uw werkstroom te openen in de JSON-editor.
Standaard
Selecteer Werkstromen onder Werkstromen.
Selecteer uw werkstroom op de pagina Werkstromen .
Selecteer onder Extra de codeweergave om uw werkstroom te openen in de JSON-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>" }Wijzig in dit voorbeeld de eigenschap
runAftervanSucceededinFailed:"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 met scopes en de resultaten ervan evalueren
Net als bij het uitvoeren van stappen na afzonderlijke acties met de instelling Uitvoeren na, kunt u acties groeperen binnen een bereik. U kunt scopes gebruiken wanneer u acties logisch wilt groeperen, de geaggregeerde status van de scope wilt beoordelen en acties wilt uitvoeren op basis van deze status. Nadat alle acties in een bereik zijn uitgevoerd, krijgt het bereik zelf de eigen status.
Als u de status van een scope wilt controleren, kunt u dezelfde criteria gebruiken als voor het controleren van de status van een workflowuitvoering, 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-scope wilt ondervangen en acties wilt uitvoeren die deze fouten afhandelen, kunt u de instelling 'Uitvoeren na' voor die Mislukt-scope gebruiken. Op die manier kunt u, als welke acties dan ook binnen het bereik mislukken en u de instelling 'uitvoeren na' voor dat bereik gebruikt, één actie maken om mislukkingen op te vangen.
Zie Limieten en config voor limieten op scopes.
Een bereik instellen met 'uitvoeren na' voor het afhandelen van uitzonderingen
Open in de Azure-portal uw logische app-resource en werkstroom in de ontwerper.
Uw werkstroom moet al een trigger hebben waarmee de werkstroom wordt gestart.
Volg in de ontwerper deze algemene stappen om een Control-actie met de naam Scope toe te voegen aan uw workflow.
Voer in de actie Scopede volgende algemene stappen uit om acties toe te voegen die moeten worden uitgevoerd, bijvoorbeeld:
In de volgende lijst wordt een aantal voorbeeldacties weergegeven die u in een Scope-actie kunt opnemen:
- Gegevens ophalen uit een API.
- De gegevens verwerken.
- Sla de gegevens op in een database.
Definieer nu de regels voor 'uitvoeren na' om de acties binnen het toepassingsgebied uit te voeren.
Selecteer in de ontwerpfunctie de titel Bereik . Wanneer het informatievenster van het bereik wordt geopend, selecteert u Instellingen.
Als u meer dan één voorgaande actie in de werkstroom hebt, selecteert u in de lijst Acties selecteren de actie waarna u de acties binnen het bereik wilt uitvoeren.
Selecteer voor de geselecteerde actie alle actiestatussen waarmee de acties binnen het bereik kunnen worden uitgevoerd.
Met andere woorden, elk van de gekozen statussen die voortkomen uit de geselecteerde actie, zorgt ervoor dat de acties binnen het bereik worden uitgevoerd.
In het volgende voorbeeld worden de acties binnen het bereik uitgevoerd nadat de HTTP-actie is voltooid met een van de geselecteerde statussen:
Context en resultaten ophalen voor fouten
Hoewel het nuttig is om fouten binnen een bereik op te vangen, wilt u mogelijk ook meer context, zodat u kunt achterhalen welke acties precies zijn mislukt en welke fouten of statuscodes daarbij horen. De result() functie geeft de resultaten terug van de acties op het hoogste niveau in een actie met bereik. 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 krijgen over de acties die binnen een bereik zijn mislukt, kunt u de expressie @result() gebruiken met de naam van het bereik en de instelling "run after". Als u de geretourneerde array wilt filteren op acties die de status Mislukt hebben, kunt u de actie Array filteren toevoegen. 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.Stuur een HTTP POST naar de hoofdtekst van de itemrespons van
For_each, wat de expressie@item()['outputs']['body']is.De vorm van het
@result()item is hetzelfde als de@actions()vorm en kan op dezelfde manier worden geparseerd.Voeg twee aangepaste headers toe met de naam van de mislukte actie (
@item()['name']) en de clienttracking-id van de mislukte uitvoering (@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.