Gestire gli errori e le eccezioni in App per la logicaHandle errors and exceptions in Logic Apps

Nelle architetture di integrazione una delle difficoltà consiste nel garantire che i tempi di inattività o i problemi dei sistemi dipendenti vengano gestiti in modo appropriato.Appropriately handling downtime or issues from dependent systems can pose a challenge for any integration architecture. Per creare solide integrazioni resilienti in caso di problemi ed errori, App per la logica offre un'esperienza all'avanguardia per la gestione degli errori e delle eccezioni.To create robust integrations that are resilient against problems and failures, Logic Apps offers a first-class experience for handling errors and exceptions.

Criteri di ripetizione dei tentativiRetry policies

Per la gestione degli errori e delle eccezioni più semplice, è possibile usare i criteri di ripetizione.For the most basic exception and error handling, you can use the retry policy. Tali criteri definiscono se e come l'azione ripete la richiesta in caso di timeout o esito negativo, con restituzione di una risposta 429 o 5xx, della richiesta iniziale.If an initial request timed out or failed, which is any request that results in a 429 or 5xx response, this policy defines whether and how the action retries the request.

Esistono quattro tipi di criteri di ripetizione: predefinito, nessuno, a intervallo fisso e a intervallo esponenziale.There are four types of retry policies: default, none, fixed interval, and exponential interval. Se la definizione del flusso di lavoro non ha criteri di ripetizione, vengono invece usati i criteri predefiniti specificati dal servizio.If your workflow definition doesn't have a retry policy, the default policy, as defined by the service, is used instead.

Per configurare i criteri di ripetizione, se applicabili, aprire Progettazione app per la logica per l'app per la logica e passare a Impostazioni per un'azione specifica nell'app per la logica.To set up retry policies, if applicable, open the Logic App Designer for your logic app, and go to Settings for a specific action in your logic app. È anche possibile definire i criteri di ripetizione nella sezione inputs di un'azione o trigger specifico, se ripetibile, nella definizione del flusso di lavoro.Or, you can define retry policies in the inputs section for a specific action or trigger, if retryable, in your workflow definition. Di seguito è illustrata la sintassi generale:Here's the general syntax:

"retryPolicy": {
    "type": "<retry-policy-type>",
    "interval": <retry-interval>,
    "count": <number-of-retry-attempts>
}

Per altre informazioni sulla sintassi e sulla sezione inputs, vedere la sezione relativa ai criteri di ripetizione in Trigger e azioni dei flussi di lavoro.For more information about syntax and the inputs section, see the retry-policy section in Workflow Actions and Triggers. Per informazioni sulle restrizioni dei criteri di ripetizione, vedere Limiti e configurazione per App per la logica.For information about retry policy limitations, see Logic Apps limits and configuration.

PredefinitoDefault

Quando non si definiscono criteri di ripetizione nella sezione retryPolicy, l'app per la logica usa il criterio predefinito, costituito da criteri con un intervallo esponenziale che invia fino a quattro tentativi a intervalli con crescita esponenziale scalati di 7,5 secondi.When you don't define a retry policy in the retryPolicy section, your logic app uses the default policy, which is an exponential interval policy that sends up to four retries at exponentially increasing intervals that are scaled by 7.5 seconds. L'intervallo è compreso tra 5 e 45 secondi.The interval is capped between 5 and 45 seconds. Tali criteri equivalgono ai criteri nella definizione del flusso di lavoro HTTP di questo esempio:This policy is equivalent to the policy in this example HTTP workflow definition:

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

NessunaNone

Se si imposta retryPolicy su none, i criteri non ripeteranno le richieste non riuscite.If you set retryPolicy to none, this policy does not retry failed requests.

Nome dell'elementoElement name ObbligatoriaRequired typeType DESCRIZIONEDescription
typetype Yes stringString nessunanone

Intervallo fissoFixed interval

Se si imposta retryPolicy su fixed, i criteri ripeteranno una richiesta non riuscita attendendo l'intervallo di tempo specificato prima di inviare la richiesta successiva.If you set retryPolicy to fixed, this policy retries a failed request by waiting the specified interval of time before sending the next request.

Nome dell'elementoElement name ObbligatoriaRequired typeType DESCRIZIONEDescription
typetype Yes stringString fixedfixed
countcount Yes IntegerInteger Numero di tentativi di ripetizione, che deve essere compresi tra 1 e 90The number of retry attempts, which must be between 1 and 90
intervalinterval Yes stringString Intervallo di ripetizione dei tentativi in formato ISO 8601, che deve essere compreso tra PT5S e PT1DThe retry interval in ISO 8601 format, which must be between PT5S and PT1D

Intervallo esponenzialeExponential interval

Se si imposta retryPolicy su exponential, i criteri ripeteranno una richiesta non riuscita dopo un intervallo di tempo casuale di un intervallo a crescita esponenziale.If you set retryPolicy to exponential, this policy retries a failed request after a random time interval from an exponentially growing range. I criteri garantiscono anche l'invio di ogni tentativo a un intervallo casuale maggiore di minimumInterval e minore di maximumInterval.The policy also guarantees to send each retry attempt at a random interval that is greater than minimumInterval and less than maximumInterval. Nei criteri esponenziali count e interval sono obbligatori, mentre i valori per minimumInterval e maximumInterval sono facoltativi.Exponential policies require count and interval, while values for minimumInterval and maximumInterval are optional. Per eseguire l'override rispettivamente dei valori predefiniti PT5S e PT1D, è possibile aggiungere questi valori.If you want to override the PT5S and PT1D default values respectively, you can add these values.

Nome dell'elementoElement name ObbligatoriaRequired typeType DESCRIZIONEDescription
typetype Yes stringString exponentialexponential
countcount Yes IntegerInteger Numero di tentativi di ripetizione, che deve essere compresi tra 1 e 90The number of retry attempts, which must be between 1 and 90
intervalinterval Yes stringString Intervallo di ripetizione dei tentativi in formato ISO 8601, che deve essere compreso tra PT5S e PT1D.The retry interval in ISO 8601 format, which must be between PT5S and PT1D.
minimumIntervalminimumInterval No No stringString Intervallo minimo di ripetizione dei tentativi in formato ISO 8601, che deve essere compreso tra PT5S e intervalThe retry minimum interval in ISO 8601 format, which must be between PT5S and interval
maximumIntervalmaximumInterval No No stringString Intervallo minimo di ripetizione dei tentativi in formato ISO 8601, che deve essere compreso tra interval e PT1DThe retry minimum interval in ISO 8601 format, which must be between interval and PT1D

Questa tabella illustra come una variabile casuale uniforme nell'intervallo indicato viene generata per ogni nuovo tentativo fino al valore di count incluso:This table shows how a uniform random variable in the indicated range is generated for each retry up to and including count:

Intervallo variabile casualeRandom variable range

Numero di ripetizioniRetry number Intervallo minimoMinimum interval Intervallo massimoMaximum interval
11 Massimo (0, minimumInterval)Max(0, minimumInterval) Minimo (intervallo, maximumInterval)Min(interval, maximumInterval)
22 Massimo (intervallo, minimumInterval)Max(interval, minimumInterval) Minimo (2 * intervallo, maximumInterval)Min(2 * interval, maximumInterval)
33 Massimo (2 * intervallo, minimumInterval)Max(2 * interval, minimumInterval) Minimo (4 * intervallo, maximumInterval)Min(4 * interval, maximumInterval)
44 Massimo (4*intervallo, minimumInterval)Max(4 * interval, minimumInterval) Minimo (8 * intervallo, maximumInterval)Min(8 * interval, maximumInterval)
........

Rilevare e gestire gli errori con la proprietà RunAfterCatch and handle failures with the RunAfter property

Ogni azione dell'app per la logica dichiara le azioni che devono terminare prima dell'avvio dell'azione, analogamente a come si specifica l'ordine dei passaggi nel flusso di lavoro.Each logic app action declares the actions that must finish before that action starts, similar to how you specify the order of steps in your workflow. Nella definizione di un'azione la proprietà runAfter specifica questo ordinamento ed è un oggetto che descrive le azioni e gli stati delle azioni che determineranno l'esecuzione dell'azione.In an action definition, the runAfter property defines this ordering and is an object that describes which actions and action statuses execute the action.

Per impostazione predefinita, tutte le azioni aggiunte nella finestra di progettazione di App per la logica vengono impostate per essere eseguite dopo il passaggio precedente quando il risultato del passaggio precedente è Succeeded.By default, all actions that you add in the Logic App Designer are set to run after the previous step when the previous step's result is Succeeded. È tuttavia possibile personalizzare il valore di runAfter in modo che le azioni vengano generate quando le azioni precedenti restituiscono Failed, Skipped o una combinazione di questi valori.However, you can customize the runAfter value so that actions fire when the previous actions result as Failed, Skipped, or some combination of these values. Ad esempio, per aggiungere un elemento a un argomento del bus di servizio specifico dopo che un'azione Insert_Row specifica ha esito negativo, è possibile usare questa definizione runAfter di esempio:For example, to add an item to a specific Service Bus topic after a specific Insert_Row action fails, you could use this example runAfter definition:

"Send_message": {
    "inputs": {
        "body": {
            "ContentData": "@{encodeBase64(body('Insert_Row'))}",
            "ContentType": "{ \"content-type\" : \"application/json\" }"
        },
        "host": {
            "api": {
                "runtimeUrl": "https://logic-apis-westus.azure-apim.net/apim/servicebus"
            },
            "connection": {
                "name": "@parameters('$connections')['servicebus']['connectionId']"
            }
        },
        "method": "post",
        "path": "/@{encodeURIComponent('failures')}/messages"
    },
    "runAfter": {
        "Insert_Row": [
            "Failed"
        ]
    }
}

La proprietà runAfter viene impostata in modo che venga eseguita quando lo stato dell'azione Insert_Row è Failed.The runAfter property is set to run when the Insert_Row action status is Failed. Per eseguire l'azione se lo stato dell'azione è Succeeded, Failed o Skipped usare la sintassi seguente:To run the action if the action status is Succeeded, Failed, or Skipped, use this syntax:

"runAfter": {
        "Insert_Row": [
            "Failed", "Succeeded", "Skipped"
        ]
    }

Suggerimento

Le azioni eseguite e completate correttamente in seguito all'esito negativo di un'azione precedente vengono contrassegnate come Succeeded.Actions that run and finish successfully after a preceding action has failed, are marked as Succeeded. Con questo comportamento, se tutti gli errori in un flusso di lavoro vengono rilevati, l'esecuzione stessa verrà contrassegnata come Succeeded.This behavior means that if you successfully catch all failures in a workflow, the run itself is marked as Succeeded.

Valutare le azioni con ambiti e i relativi risultatiEvaluate actions with scopes and their results

Come quando si eseguono i passaggi dopo le singole azioni con la proprietà runAfter, è possibile raggruppare le azioni in un ambito.Similar to running steps after individual actions with the runAfter property, you can group actions together inside a scope. Quando si vuole raggruppare le azioni logicamente, valutare lo stato di aggregazione dell'ambito ed eseguire azioni in base a tale stato, è possibile usare gli ambiti.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. Al termine dell'esecuzione di tutte le azioni in un ambito, l'ambito stesso ottiene il proprio stato.After all the actions in a scope finish running, the scope itself gets its own status.

Per controllare lo stato di un ambito, è possibile usare lo gli stessi criteri usati per controllare lo stato di esecuzione di un'app per la logica, ad esempio Succeeded, Failed e così via.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.

Per impostazione predefinita, quando tutte le azioni dell'ambito hanno esito positivo lo stato dell'ambito viene contrassegnato come Succeeded.By default, when all the scope's actions succeed, the scope's status is marked Succeeded. Se l'azione finale in un ambito restituisce Failed o Aborted, lo stato dell'ambito viene contrassegnato come Failed.If the final action in a scope results as Failed or Aborted, the scope's status is marked Failed.

Per rilevare le eccezioni in un ambito Failed ed eseguire le azioni che gestiscono tali errori, è possibile usare la proprietà runAfter per tale ambito 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. In tal modo, se una qualsiasi azione nell'ambito ha esito negativo e si usa la proprietà runAfter per tale ambito, è possibile creare una singola azione per rilevare gli errori.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.

Per i limiti degli ambiti, vedere Limiti e configurazione.For limits on scopes, see Limits and config.

Ottenere il contesto e i risultati per gli erroriGet context and results for failures

Rilevare gli errori è molto utile, ma può essere opportuno anche il contesto per comprendere esattamente quali azioni hanno avuto esito negativo e tutti gli errori o i codici di stato restituiti.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. La funzione del flusso di lavoro @result() offre il contesto relativo al risultato di tutte le azioni all'interno di un ambito.The @result() workflow function provides context about the result of all actions in a scope.

La funzione @result() accetta un unico parametro, il nome dell'ambito, e restituisce una matrice dei risultati di tutte le azioni all'interno di tale ambito.The @result() function accepts a single parameter (the scope's name) and returns an array of all the action results from within that scope. Questi oggetti azione includono gli stessi attributi dell'oggetto @actions(), ad esempio l'ora di inizio, l'ora di fine, lo stato, gli input, gli ID correlazione e gli output dell'azione.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. Per inviare il contesto per una qualsiasi azione non riuscita all'interno di un ambito, è possibile associare una funzione @result() a una proprietà runAfter.To send context for any actions that failed within a scope, you can easily pair an @result() function with a runAfter property.

Per eseguire un'azione per ogni azione di un ambito con stato Failed, è possibile associare @result() a un'azione Filtra matrice e a un ciclo ForEach. Ciò consente anche di filtrare la matrice dei risultati in modo da ottenere le azioni non riuscite.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 @result() with a Filter Array action and a ForEach loop. La matrice dei risultati filtrata può quindi essere usata per eseguire un'azione per ogni errore con il ciclo ForEach .You can take the filtered result array and perform an action for each failure using the ForEach loop.

Ecco un esempio, seguito da una spiegazione dettagliata, che invia una richiesta HTTP POST con il corpo della risposta di qualsiasi azione non riuscita all'interno dell'ambito "My_Scope":Here's an example, followed by a detailed explanation, that sends an HTTP POST request with the response body of any actions that failed within the scope "My_Scope":

"Filter_array": {
    "inputs": {
        "from": "@result('My_Scope')",
        "where": "@equals(item()['status'], 'Failed')"
    },
    "runAfter": {
        "My_Scope": [
            "Failed"
        ]
    },
    "type": "Query"
},
"For_each": {
    "actions": {
        "Log_Exception": {
            "inputs": {
                "body": "@item()['outputs']['body']",
                "method": "POST",
                "headers": {
                    "x-failed-action-name": "@item()['name']",
                    "x-failed-tracking-id": "@item()['clientTrackingId']"
                },
                "uri": "http://requestb.in/"
            },
            "runAfter": {},
            "type": "Http"
        }
    },
    "foreach": "@body('Filter_array')",
    "runAfter": {
        "Filter_array": [
            "Succeeded"
        ]
    },
    "type": "Foreach"
}

Ecco la procedura dettagliata che descrive quanto accaduto in questo esempio:Here's a detailed walkthrough that describes what happens in this example:

  1. Per ottenere il risultato di tutte le azioni all'interno di "My_Scope", l'azione Filtra matrice filtra @result('My_Scope').To get the result of all actions within "My_Scope", the Filter Array action filters @result('My_Scope').

  2. La condizione per Filtra matrice è qualsiasi elemento @result() con stato uguale a Failed.The condition for Filter Array is any @result() item that has a status equal to Failed. Questa condizione filtra la matrice di tutti i risultati dell'azione da "My_Scope" fino a una matrice con i soli risultati delle azioni non riuscite.This condition filters the array of all the action results from "My_Scope" down to an array with only failed action results.

  3. Eseguire un'azione del ciclo For Each sugli output della matrice filtrata.Perform a For Each loop action on the filtered array outputs. Questo passaggio esegue un'azione per ogni risultato di azione non riuscita precedentemente filtrato.This step performs an action for each failed action result that was previously filtered.

    Se una sola azione nell'ambito ha avuto esito negativo, le azioni in foreach vengono eseguite una sola volta.If a single action in the scope failed, the actions in the foreach run only once. Molte azioni non riuscite determinano un'azione per errore.Multiple failed actions cause one action per failure.

  4. Inviare HTTP POST nel corpo della risposta dell'elemento foreach, che è @item()['outputs']['body'].Send an HTTP POST on the foreach item response body, which is @item()['outputs']['body']. La forma dell'elemento @result() è uguale alla forma di @actions() e può essere analizzata nello stesso modo.The @result() item shape is the same as the @actions() shape and can be parsed the same way.

  5. Includere due intestazioni personalizzate con il nome dell'azione non riuscita @item()['name'] e l'ID di rilevamento del client dell'esecuzione non riuscita @item()['clientTrackingId'].Include two custom headers with the failed action name @item()['name'] and the failed run client tracking ID @item()['clientTrackingId'].

Come riferimento, di seguito è riportato un esempio di un singolo elemento @result(), che mostra le proprietà name, body, e clientTrackingId analizzate nell'esempio precedente.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. All'esterno di un'azione foreach @result() restituisce una matrice di questi oggetti.Outside of a foreach 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"
}

Le espressioni descritte in precedenza in questo articolo possono essere usate per eseguire diversi modelli di gestione delle eccezioni.To perform different exception handling patterns, you can use the expressions previously described in this article. È possibile scegliere di eseguire una singola azione di gestione delle eccezioni all'esterno dell'ambito che accetta l'intera matrice filtrata degli errori e rimuovere l'azione foreach.You might choose to execute a single exception handling action outside the scope that accepts the entire filtered array of failures, and remove the foreach action. È anche possibile includere altre proprietà utili della risposta @result() come illustrato in precedenza.You can also include other useful properties from the @result() response as previously described.

Diagnostica e telemetria di AzureAzure Diagnostics and telemetry

I modelli precedenti sono un ottimo modo per gestire gli errori e le eccezioni in un'esecuzione, ma è possibile anche identificare e rispondere agli errori indipendentemente dall'esecuzione.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. Diagnostica di Azure consente di inviare in modo semplice tutti gli eventi del flusso di lavoro, inclusi tutti gli stati delle esecuzioni e delle azioni, a un account di archiviazione di Azure o a un hub eventi creato in Hub eventi di Azure.Azure Diagnostics provides a simple way to send all workflow events, including all run and action statuses, to an Azure Storage account or an event hub created with Azure Event Hubs.

Per valutare gli stati delle esecuzioni è possibile monitorare i log e le metriche o pubblicarli nello strumento di monitoraggio preferito.To evaluate run statuses, you can monitor the logs and metrics, or publish them into any monitoring tool that you prefer. Una possibile opzione consiste nel trasmettere tutti gli eventi tramite Hub eventi ad Analisi di flusso di Azure.One potential option is to stream all the events through Event Hubs into Azure Stream Analytics. In Analisi di flusso è possibile scrivere query dinamiche in base a un'anomalia, una media o un errore dei log di diagnostica.In Stream Analytics, you can write live queries based on any anomalies, averages, or failures from the diagnostic logs. È possibile usare Analisi di flusso per inviare informazioni ad altre origini dati, ad esempio a code, argomenti, SQL, Azure Cosmos DB o 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.

Passaggi successiviNext steps