Fouten en uitzonderingen in Azure Logic Apps afhandelenHandle errors and exceptions in Azure Logic Apps

De manier waarop elke integratie architectuur op de juiste wijze downtime of problemen verwerkt die door afhankelijke systemen worden veroorzaakt, kan een uitdaging vormen.The way that any integration architecture appropriately handles downtime or issues caused by dependent systems can pose a challenge. Logic Apps biedt een topervaring voor het afhandelen van fouten en uitzonde ringen, om u te helpen bij het maken van robuuste en robuuste integraties die problemen en storingen op de juiste manier afhandelen.To help you create robust and resilient integrations that gracefully handle problems and failures, Logic Apps provides a first-class experience for handling errors and exceptions.

Beleid voor opnieuw proberenRetry policies

Voor de meest eenvoudige uitzonde ring en fout afhandeling kunt u een beleid voor opnieuw proberen gebruiken in elke actie of trigger waarbij wordt ondersteund, bijvoorbeeld http-actie.For the most basic exception and error handling, you can use a retry policy in any action or trigger where supported, for example, see HTTP action. Met een beleid voor opnieuw proberen wordt aangegeven of en hoe de actie of de trigger een aanvraag opnieuw probeert wanneer de oorspronkelijke aanvraag een time-out heeft of mislukt. Dit is een aanvraag die resulteert in een 408-, 429-of 5xx-antwoord.A retry policy specifies whether and how the action or trigger retries a request when the original request times out or fails, which is any request that results in a 408, 429, or 5xx response. Als er geen ander beleid voor opnieuw proberen wordt gebruikt, wordt het standaard beleid gebruikt.If no other retry policy is used, the default policy is used.

Dit zijn de beleids typen voor opnieuw proberen:Here are the retry policy types:

TypeType DescriptionDescription
StandaardDefault Met dit beleid worden Maxi maal vier nieuwe pogingen verzonden met exponentieel toenemende intervallen. deze worden geschaald op 7,5 seconden, maar worden tussen 5 en 45 seconden gelimiteerd.This policy sends up to four retries at exponentially increasing intervals, which scale by 7.5 seconds but are capped between 5 and 45 seconds.
Exponentieel intervalExponential interval Dit beleid wacht een wille keurig interval dat is geselecteerd uit een exponentieel groeiend bereik voordat de volgende aanvraag wordt verzonden.This policy waits a random interval selected from an exponentially growing range before sending the next request.
Vast intervalFixed interval Met dit beleid wordt het opgegeven interval gewacht voordat de volgende aanvraag wordt verzonden.This policy waits the specified interval before sending the next request.
GeenNone De aanvraag niet opnieuw verzenden.Don't resend the request.

Zie Logic apps limieten en configuratievoor meer informatie over limieten voor het beleid voor opnieuw proberen.For information about retry policy limits, see Logic Apps limits and configuration.

Beleid voor opnieuw proberen wijzigenChange retry policy

Voer de volgende stappen uit om een ander beleid voor opnieuw proberen te selecteren:To select a different retry policy, follow these steps:

  1. Open uw logische app in de ontwerp functie voor logische apps.Open your logic app in Logic App Designer.

  2. Open de instellingen voor een actie of trigger.Open the Settings for an action or trigger.

  3. Als de actie of trigger het beleid voor nieuwe pogingen ondersteunt, selecteert u het gewenste type onder beleid voor opnieuw proberen.If the action or trigger supports retry policies, under Retry Policy, select the type you want.

Of u kunt het beleid voor opnieuw proberen hand matig opgeven in de inputs sectie voor een actie of trigger die beleids regels voor opnieuw proberen ondersteunt.Or, you can manually specify the retry policy in the inputs section for an action or trigger that supports retry policies. Als u geen beleid voor opnieuw proberen opgeeft, gebruikt de actie het standaard beleid.If you don't specify a retry policy, the action uses the default policy.

"<action-name>": {
   "type": "<action-type>",
   "inputs": {
      "<action-specific-inputs>",
      "retryPolicy": {
         "type": "<retry-policy-type>",
         "interval": "<retry-interval>",
         "count": <retry-attempts>,
         "minimumInterval": "<minimum-interval>",
         "maximumInterval": "<maximum-interval>"
      },
      "<other-action-specific-inputs>"
   },
   "runAfter": {}
}

VereistRequired

WaardeValue TypeType DescriptionDescription
<opnieuw proberen-beleid-type><retry-policy-type> TekenreeksString Het type beleid voor opnieuw proberen dat u wilt gebruiken: default , none , fixed , of exponentialThe retry policy type you want to use: default, none, fixed, or exponential
<nieuwe poging-interval><retry-interval> TekenreeksString Het interval voor nieuwe pogingen waarbij de waarde de ISO 8601-notatiemoet gebruiken.The retry interval where the value must use ISO 8601 format. Het minimale standaard interval is PT5S en het maximum interval PT1D .The default minimum interval is PT5S and the maximum interval is PT1D. Wanneer u het beleid voor exponentiële intervallen gebruikt, kunt u verschillende minimum-en maximum waarden opgeven.When you use the exponential interval policy, you can specify different minimum and maximum values.
<nieuwe pogingen><retry-attempts> Geheel getalInteger Het aantal nieuwe pogingen, dat tussen 1 en 90 ligtThe number of retry attempts, which must be between 1 and 90

OptioneelOptional

WaardeValue TypeType DescriptionDescription
<minimum-interval><minimum-interval> TekenreeksString Voor het beleid voor exponentiële intervallen wordt het kleinste interval voor het wille keurig geselecteerde interval in ISO 8601-indelingFor the exponential interval policy, the smallest interval for the randomly selected interval in ISO 8601 format
<maximum-interval><maximum-interval> TekenreeksString Voor het beleid voor exponentiële intervallen is het grootste interval voor het wille keurig geselecteerde interval in ISO 8601-indelingFor the exponential interval policy, the largest interval for the randomly selected interval in ISO 8601 format

Hier vindt u meer informatie over de verschillende beleids typen.Here is more information about the different policy types.

StandaardDefault

Als u geen beleid voor opnieuw proberen opgeeft, gebruikt de actie het standaard beleid, dat eigenlijk een exponentieel interval beleid is dat Maxi maal vier nieuwe pogingen verzendt met exponentieel toenemende intervallen die met 7,5 seconden worden geschaald.If you don't specify a retry policy, the action uses the default policy, which is actually an exponential interval policy that sends up to four retries at exponentially increasing intervals that are scaled by 7.5 seconds. Het interval wordt tussen 5 en 45 seconden gelimiteerd.The interval is capped between 5 and 45 seconds.

Hoewel niet expliciet is gedefinieerd in uw actie of trigger, is dit het standaard beleid gedraagt in een voor beeld van een HTTP-actie:Though not explicitly defined in your action or trigger, here is how the default policy behaves in an example HTTP action:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

GeenNone

Als u wilt opgeven dat de actie of de trigger geen mislukte aanvragen opnieuw probeert uit te voeren, stelt u het type <opnieuw proberen> in op none .To specify that the action or trigger doesn't retry failed requests, set the <retry-policy-type> to none.

Vast intervalFixed interval

Als u wilt opgeven dat de actie of trigger het opgegeven interval moet wachten voordat de volgende aanvraag wordt verzonden, stelt u het> <opnieuw proberen in op fixed .To specify that the action or trigger waits the specified interval before sending the next request, set the <retry-policy-type> to fixed.

VoorbeeldExample

Dit beleid voor opnieuw proberen probeert het laatste nieuws twee keer na de eerste mislukte aanvraag met een vertraging van 30 seconden tussen elke poging te verkrijgen:This retry policy attempts to get the latest news two more times after the first failed request with a 30-second delay between each attempt:

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

Exponentieel intervalExponential interval

Als u wilt opgeven dat de actie of trigger een wille keurig interval moet wachten voordat de volgende aanvraag wordt verzonden, stelt u het> <opnieuw proberen in exponential .To specify that the action or trigger waits a random interval before sending the next request, set the <retry-policy-type> to exponential. Het wille keurig interval wordt geselecteerd uit een exponentieel groeiend bereik.The random interval is selected from an exponentially growing range. U kunt eventueel ook de standaard minimum-en maximum intervallen onderdrukken door uw eigen minimum-en maximum intervallen op te geven.Optionally, you can also override the default minimum and maximum intervals by specifying your own minimum and maximum intervals.

Bereiken voor wille keurige variabeleRandom variable ranges

In deze tabel ziet u hoe Logic Apps een uniforme wille keurige variabele in het opgegeven bereik genereert voor elke nieuwe poging tot en met het aantal nieuwe pogingen:This table shows how Logic Apps generates a uniform random variable in the specified range for each retry up to and including the number of retries:

Aantal nieuwe pogingenRetry number Minimum intervalMinimum interval Maximum intervalMaximum interval
11 Max (0, <Mini maal interval>)max(0, <minimum-interval>) min (interval, <maximum-interval>)min(interval, <maximum-interval>)
22 Max (interval, <Mini maal interval>)max(interval, <minimum-interval>) min (2 * interval, <maximum-interval>)min(2 * interval, <maximum-interval>)
33 Max (2 * interval, <Mini maal interval>)max(2 * interval, <minimum-interval>) min (4 * interval, <maximum-interval>)min(4 * interval, <maximum-interval>)
44 Max (4 * interval, <Mini maal interval>)max(4 * interval, <minimum-interval>) min (8 * interval, <maximum-interval>)min(8 * interval, <maximum-interval>)
........ ........ ........

Ondervangen en afhandelen van fouten door het gedrag ' uitvoeren na ' te wijzigenCatch and handle failures by changing "run after" behavior

Wanneer u acties toevoegt in de ontwerp functie voor logische apps, declareert u impliciet de volg orde die moet worden gebruikt voor het uitvoeren van deze acties.When you add actions in the Logic App Designer, you implicitly declare the order to use for running those actions. Nadat een actie is uitgevoerd, wordt die actie gemarkeerd met een status als,, Succeeded Failed Skipped of TimedOut .After an action finishes running, that action is marked with a status such as Succeeded, Failed, Skipped, or TimedOut. In elke actie definitie runAfter specificeert de eigenschap de voorafgaande actie die eerst moet worden voltooid en de statussen die zijn toegestaan voor die voorafgaande actie voordat de opvolgende bewerking kan worden uitgevoerd.In each action definition, the runAfter property specifies the predecessor action that must first finish and the statuses permitted for that predecessor before the successor action can run. Een actie die u in de ontwerp functie toevoegt, wordt standaard pas uitgevoerd nadat de voorafgaande taak is voltooid met de Succeeded status.By default, an action that you add in the designer runs only after the predecessor completes with Succeeded status.

Wanneer een actie een niet-verwerkte fout of uitzonde ring genereert, wordt de actie gemarkeerd Failed en wordt een opvolgende actie gemarkeerd Skipped .When an action throws an unhandled error or exception, the action is marked Failed, and any successor action is marked Skipped. Als dit gedrag optreedt voor een actie die parallelle vertakkingen heeft, volgt de Logic Apps-Engine de andere vertakkingen om de voltooiings status te bepalen.If this behavior happens for an action that has parallel branches, the Logic Apps engine follows the other branches to determine their completion statuses. Als een vertakking bijvoorbeeld eindigt met een Skipped actie, wordt de voltooiings status van die vertakking gebaseerd op de voorafgaande status van de overgeslagen actie.For example, if a branch ends with a Skipped action, that branch's completion status is based on that skipped action's predecessor status. Nadat de uitvoering van de logische app is voltooid, bepaalt de engine de volledige status van de uitvoering door alle vertakkings statussen te evalueren.After the logic app run completes, the engine determines the entire run's status by evaluating all the branch statuses. Als een vertakking stopt met de fout, wordt de volledige uitvoering van de logische app gemarkeerd Failed .If any branch ends in failure, the entire logic app run is marked Failed.

Voor beelden die laten zien hoe uitvoerings statussen worden geëvalueerd

Om ervoor te zorgen dat een actie nog steeds kan worden uitgevoerd ondanks de status van de voorafgaande taak, past u het gedrag ' uitvoeren na ' aan om de statussen van de voorafgaande actie te verwerken.To make sure that an action can still run despite its predecessor's status, customize an action's "run after" behavior to handle the predecessor's unsuccessful statuses.

Gedrag van ' uitvoeren na ' aanpassenCustomize "run after" behavior

U kunt het gedrag ' uitvoeren na ' aanpassen zodat de actie wordt uitgevoerd wanneer de status van de voorafgaande taak ofwel, Succeeded , Failed Skipped TimedOut of een van deze statussen is.You can customize an action's "run after" behavior so that the action runs when the predecessor's status is either Succeeded, Failed, Skipped, TimedOut, or any of these statuses. Als u bijvoorbeeld een e-mail bericht wilt verzenden nadat de Add_a_row_into_a_table voorafgaande actie van Excel online is gemarkeerd Failed , Succeeded wijzigt u het gedrag ' uitvoeren na ' door een van de volgende stappen uit te voeren:For example, to send an email after the Excel Online Add_a_row_into_a_table predecessor action is marked Failed, rather than Succeeded, change the "run after" behavior by following either step:

  • Selecteer in de ontwerp weergave de knop met weglatings tekens (...) en selecteer vervolgens uitvoeren na.In the design view, select the ellipses (...) button, and then select Configure run after.

    Gedrag van ' uitvoeren na ' configureren voor een actie

    De shape actie toont de standaard status die is vereist voor de voorafgaande actie, wat een rij aan een tabel in dit voor beeld bevat:The action shape shows the default status that's required for the predecessor action, which is Add a row into a table in this example:

    Standaard gedrag ' uitvoeren na ' voor een actie

    Wijzig het gedrag ' uitvoeren na ' in de status die u wilt, in dit voor beeld is mislukt :Change the "run after" behavior to the status that you want, which is has failed in this example:

    Het gedrag ' uitvoeren na ' wordt gewijzigd in ' is mislukt '

    Om op te geven dat de actie wordt uitgevoerd, ongeacht of de voorafgaande actie is gemarkeerd als Failed Skipped of TimedOut , selecteert u de andere statussen:To specify that the action runs whether the predecessor action is marked as Failed, Skipped or TimedOut, select the other statuses:

    Het gedrag ' uitvoeren na ' wijzigen om een andere status te hebben

  • Bewerk in de code weergave in de JSON-definitie van de actie de eigenschap. deze heeft de runAfter volgende syntaxis:In code view, in the action's JSON definition, edit the runAfter property, which follows this syntax:

    "<action-name>": {
       "inputs": {
          "<action-specific-inputs>"
       },
       "runAfter": {
          "<preceding-action>": [
             "Succeeded"
          ]
       },
       "type": "<action-type>"
    }
    

    Voor dit voor beeld wijzigt runAfter u de eigenschap van Succeeded in Failed :For this example, change the runAfter property from Succeeded to Failed:

    "Send_an_email_(V2)": {
       "inputs": {
          "body": {
             "Body": "<p>Failed to&nbsp;add row to &nbsp;@{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"
    }
    

    Om op te geven dat de actie wordt uitgevoerd, ongeacht of de voorafgaande actie is gemarkeerd als Failed Skipped of TimedOut , voegt u de andere statussen toe:To specify that the action runs whether the predecessor action is marked as Failed, Skipped or TimedOut, add the other statuses:

    "runAfter": {
       "Add_a_row_into_a_table": [
          "Failed", "Skipped", "TimedOut"
       ]
    },
    

Acties met bereiken en hun resultaten evaluerenEvaluate actions with scopes and their results

Net als bij het uitvoeren van stappen na afzonderlijke acties met de runAfter eigenschap kunt u acties groeperen binnen een bereik.Similar to running steps after individual actions with the runAfter property, you can group actions together inside a scope. U kunt bereiken gebruiken als u acties logisch wilt groeperen, de aggregatie status van het bereik wilt beoordelen en acties wilt uitvoeren op basis van deze status.You can use scopes when you want to logically group actions together, assess the scope's aggregate status, and perform actions based on that status. Nadat alle acties in een bereik zijn uitgevoerd, krijgt de scope zelf een eigen status.After all the actions in a scope finish running, the scope itself gets its own status.

Als u de status van een bereik wilt controleren, kunt u dezelfde criteria gebruiken die u gebruikt om de uitvoerings status van een logische app te controleren, zoals Succeeded , Failed , enzovoort.To check a scope's status, you can use the same criteria that you use to check a logic app's run status, such as Succeeded, Failed, and so on.

Wanneer alle acties van het bereik zijn geslaagd, wordt standaard de status van het bereik gemarkeerd Succeeded .By default, when all the scope's actions succeed, the scope's status is marked Succeeded. Als de laatste actie in een bereik resulteert als Failed of Aborted , wordt de status van het bereik gemarkeerd Failed .If the final action in a scope results as Failed or Aborted, the scope's status is marked Failed.

FailedU kunt de runAfter eigenschap voor dat bereik gebruiken om uitzonde ringen in een bereik te ondervangen en acties uit te voeren die deze fouten verwerken Failed .To catch exceptions in a Failed scope and run actions that handle those errors, you can use the runAfter property for that Failed scope. Op die manier, als er acties in de scope mislukken en u de runAfter eigenschap voor dat bereik gebruikt, kunt u één actie maken om fouten te ondervangen.That way, if any actions in the scope fail, and you use the runAfter property for that scope, you can create a single action to catch failures.

Zie limieten en configuratievoor limieten voor scopes.For limits on scopes, see Limits and config.

Context en resultaten ophalen voor foutenGet context and results for failures

Hoewel het niet nuttig is om een bereik te bereiken, is het mogelijk dat u ook wilt weten welke acties zijn mislukt plus eventuele fouten of status codes die zijn geretourneerd.Although catching failures from a scope is useful, you might also want context to help you understand exactly which actions failed plus any errors or status codes that were returned.

De result() functie biedt context over de resultaten van alle acties in een bereik.The result() function provides context about the results from all the actions in a scope. De result() functie accepteert één para meter, de naam van het bereik en retourneert een matrix die alle actie resultaten van binnen dat bereik bevat.The result() function accepts a single parameter, which is the scope's name, and returns an array that contains all the action results from within that scope. Deze actie objecten bevatten dezelfde kenmerken als het actions() object, zoals de begin tijd van de actie, de eind tijd, status, invoer, correlatie-id's en uitvoer.These action objects include the same attributes as the actions() object, such as the action's start time, end time, status, inputs, correlation IDs, and outputs. Als u context wilt verzenden voor acties die zijn mislukt binnen een bereik, kunt u eenvoudig een @result() expressie koppelen aan de runAfter eigenschap.To send context for any actions that failed within a scope, you can easily pair a @result() expression with the runAfter property.

Als u een actie wilt uitvoeren voor elke actie in een bereik dat een Failed resultaat heeft en als u de matrix met resultaten wilt filteren op de mislukte acties, kunt u een @result() expressie koppelen met een filter matrix actie en een voor elke lus.To run an action for each action in a scope that has a Failed result, and to filter the array of results down to the failed actions, you can pair a @result() expression with a Filter Array action and a For each loop. U kunt de gefilterde resultaat matrix nemen en een actie uitvoeren voor elke fout met behulp van de For_each lus.You can take the filtered result array and perform an action for each failure using the For_each loop.

Hier volgt een voor beeld, gevolgd door een gedetailleerde uitleg, waarmee een HTTP POST-aanvraag wordt verzonden met de antwoord tekst voor acties die zijn mislukt binnen de scope ' My_Scope ':Here's an example, followed by a detailed explanation, that sends an HTTP POST request with the response body for any actions that failed within the scope "My_Scope":

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

Hier volgt een gedetailleerde beschrijving van wat er in dit voor beeld gebeurt:Here's a detailed walkthrough that describes what happens in this example:

  1. Als u het resultaat wilt ophalen uit alle acties in ' My_Scope ', gebruikt de actie voor de filter matrix deze filter expressie: @result('My_Scope')To get the result from all actions inside "My_Scope", the Filter Array action uses this filter expression: @result('My_Scope')

  2. De voor waarde voor de filter matrix is een @result() item waarvan de status gelijk is aan Failed .The condition for Filter Array is any @result() item that has a status equal to Failed. Met deze voor waarde wordt de matrix met alle actie resultaten van ' My_Scope ' naar een matrix met alleen de mislukte actie resultaten gefilterd.This condition filters the array that has all the action results from "My_Scope" down to an array with only the failed action results.

  3. Voer een For_each herhalings actie uit op de gefilterde matrix uitvoer.Perform a For_each loop action on the filtered array outputs. Met deze stap voert u een actie uit voor elk mislukt actie resultaat dat eerder is gefilterd.This step performs an action for each failed action result that was previously filtered.

    Als één actie in het bereik mislukt, worden de acties in de For_each lus slechts eenmaal uitgevoerd.If a single action in the scope fails, the actions in the For_each loop run only once. Meerdere mislukte acties veroorzaken één actie per fout.Multiple failed actions cause one action per failure.

  4. Verzend een HTTP POST-bericht naar de For_each hoofd tekst van het item. Dit is de @item()['outputs']['body'] expressie.Send an HTTP POST on the For_each item response body, which is the @item()['outputs']['body'] expression.

    De @result() shape item is hetzelfde als de @actions() shape en kan op dezelfde manier worden geparseerd.The @result() item shape is the same as the @actions() shape and can be parsed the same way.

  5. Voeg twee aangepaste headers toe met de mislukte actie naam ( @item()['name'] ) en de mislukte tracking-ID () van de client @item()['clientTrackingId'] .Include two custom headers with the failed action name (@item()['name']) and the failed run client tracking ID (@item()['clientTrackingId']).

Ter referentie: Hier volgt een voor beeld van één @result() item, met daarin de name , body , en de clientTrackingId eigenschappen die in het vorige voor beeld worden geparseerd.For reference, here's an example of a single @result() item, showing the name, body, and clientTrackingId properties that are parsed in the previous example. Buiten een For_each actie @result() retourneert een matrix van deze objecten.Outside a For_each action, @result() returns an array of these objects.

{
   "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 andere patronen voor uitzonde ringen wilt verwerken, kunt u de eerder beschreven expressies in dit artikel gebruiken.To perform different exception handling patterns, you can use the expressions previously described in this article. U kunt ervoor kiezen om één actie voor het afhandelen van uitzonde ringen uit te voeren buiten het bereik dat de volledige gefilterde matrix van fouten accepteert en de For_each actie verwijderen.You might choose to execute a single exception handling action outside the scope that accepts the entire filtered array of failures, and remove the For_each action. U kunt ook andere nuttige eigenschappen van het \@result() antwoord toevoegen zoals eerder is beschreven.You can also include other useful properties from the \@result() response as previously described.

Azure Monitor-logboeken instellenSet up Azure Monitor logs

De vorige patronen zijn een uitstekende manier om fouten en uitzonde ringen binnen een uitvoering af te handelen, maar u kunt ook fouten onafhankelijk van de uitvoering identificeren en erop reageren.The previous patterns are great way to handle errors and exceptions within a run, but you can also identify and respond to errors independent of the run itself. Azure monitor biedt een eenvoudige manier om alle werk stroom gebeurtenissen te verzenden, inclusief alle uitvoerings-en actie statussen, naar een log Analytics-werk ruimte, een Azure-opslag accountof Azure Event hubs.Azure Monitor provides a simple way to send all workflow events, including all run and action statuses, to a Log Analytics workspace, Azure storage account, or Azure Event Hubs.

Als u de uitvoerings status wilt evalueren, kunt u de logboeken en metrische gegevens controleren of ze publiceren in elk bewakings programma dat u wilt gebruiken.To evaluate run statuses, you can monitor the logs and metrics, or publish them into any monitoring tool that you prefer. Een mogelijke mogelijkheid is om alle gebeurtenissen via Event Hubs naar Azure stream Analyticste streamen.One potential option is to stream all the events through Event Hubs into Azure Stream Analytics. In Stream Analytics kunt u live-query's schrijven op basis van eventuele afwijkingen, gemiddelden of fouten uit de diagnostische Logboeken.In Stream Analytics, you can write live queries based on any anomalies, averages, or failures from the diagnostic logs. U kunt Stream Analytics gebruiken om gegevens te verzenden naar andere gegevens bronnen, zoals wacht rijen, onderwerpen, SQL, Azure Cosmos DB of Power BI.You can use Stream Analytics to send information to other data sources, such as queues, topics, SQL, Azure Cosmos DB, or Power BI.

Volgende stappenNext steps