Gestire errori ed eccezioni in App per la logica di Azure

Articolo
12/09/2023

Si applica a: App per la logica di Azure (consumo + standard)

Il modo adottato da qualsiasi architettura di integrazione per gestire in maniera appropriata i tempi di inattività o i problemi causati da sistemi dipendenti può costituire una difficoltà. Per semplificare la creazione di integrazioni affidabili e resilienti che gestiscono correttamente problemi ed errori, App per la logica di Azure offre un'esperienza di prima classe per la gestione di errori ed eccezioni.

Criteri di ripetizione dei tentativi

Per la gestione degli errori e delle eccezioni più di base, è possibile usare i criteri di ripetizione quando sono supportati in un trigger o in un'azione, ad esempio l'azione HTTP. Se la richiesta originale del trigger o dell'azione raggiunge il timeout o ha esito negativo, generando una risposta 408, 429 o 5xx, il criterio di ripetizione dei tentativi specifica che il trigger o l'azione invia nuovamente la richiesta per ogni impostazione dei criteri.

Limiti dei criteri di ripetizione dei tentativi

Per altre informazioni su criteri di ripetizione dei tentativi, impostazioni, limiti e altre opzioni, vedere Limiti dei criteri di ripetizione dei tentativi.

Tipi di criteri di ripetizione dei tentativi

Connessione or operazioni che supportano i criteri di ripetizione dei tentativi usano Criterio predefinito a meno che non si selezioni un criterio di ripetizione dei tentativi diverso.

Criteri di ripetizione	Descrizione
Predefinita	Per la maggior parte delle operazioni, il criterio Di ripetizione dei tentativi predefinito è un criterio di intervallo esponenziale che invia fino a 4 tentativi a intervalli in aumento esponenziale. Questi intervalli vengono ridimensionati di 7,5 secondi, ma sono limitati tra 5 e 45 secondi. Diverse operazioni usano un criterio di ripetizione dei tentativi predefinito diverso, ad esempio un criterio a intervallo fisso. Per altre informazioni, vedere il tipo di criterio Di ripetizione dei tentativi predefinito.
Nessuna	Questi criteri non ripetono la richiesta. Per altre informazioni, vedere Nessun criterio di ripetizione dei tentativi.
Intervallo esponenziale	Questo criterio attende un intervallo casuale, selezionato da un intervallo in crescita esponenziale prima di inviare la richiesta successiva. Per altre informazioni, vedere il tipo di criterio intervallo esponenziale.
Intervallo fisso	Questi criteri attendono l'intervallo specificato prima di inviare la richiesta successiva. Per altre informazioni, vedere il tipo di criterio intervallo fisso.

Modificare il tipo di criterio di ripetizione dei tentativi nella finestra di progettazione

Nella portale di Azure aprire il flusso di lavoro dell'app per la logica nella finestra di progettazione.
In base al fatto che si stia lavorando a un flusso di lavoro a consumo o Standard, aprire la Impostazioni del trigger o dell'azione.
- Consumo: nella forma azione aprire il menu con i puntini di sospensione (...) e selezionare Impostazioni.
- Standard: nella finestra di progettazione selezionare l'azione. Nel riquadro dei dettagli selezionare Impostazioni.
Se il trigger o l'azione supporta i criteri di ripetizione dei tentativi, in Criteri di ripetizione dei tentativi selezionare il tipo di criterio desiderato.

Modificare il tipo di criterio di ripetizione dei tentativi nell'editor della visualizzazione codice

Se necessario, verificare se il trigger o l'azione supporta i criteri di ripetizione dei tentativi completando i passaggi precedenti nella finestra di progettazione.
Aprire il flusso di lavoro dell'app per la logica nell'editor della visualizzazione codice.

Nella definizione del trigger o dell'azione aggiungere l'oggetto retryPolicy JSON all'oggetto del trigger o dell'azione inputs . In caso contrario, se non esiste alcun retryPolicy oggetto, il trigger o l'azione usa i criteri di ripetizione dei default tentativi.

"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": {}

Obbligatorio

Proprietà	Valore	Type	Descrizione
`type`	<retry-policy-type>	Stringa	Tipo di criterio di ripetizione dei tentativi da usare: `default`, `none`, `fixed`o `exponential`
`count`	<retry-attempts>	Integer	Per `fixed` i tipi di criteri e il numero di tentativi, ovvero un valore compreso tra 1 e `exponential` 90. Per altre informazioni, vedere Intervallo fisso e Intervallo esponenziale.
`interval`	<retry-interval>	Stringa	Per `fixed` i tipi di criteri e `exponential` , il valore intervallo tra tentativi in formato ISO 8601. Per i `exponential` criteri, è anche possibile specificare intervalli massimi e minimi facoltativi. Per altre informazioni, vedere Intervallo fisso e Intervallo esponenziale. Consumo: da 5 secondi (`PT5S`) a 1 giorno (`P1D`). Standard: per i flussi di lavoro con stato, da 5 secondi (`PT5S`) a 1 giorno (`P1D`). Per i flussi di lavoro senza stato, da 1 secondo (`PT1S`) a 1 minuto (`PT1M`).

Facoltativo

Proprietà	Valore	Type	Descrizione
`maximumInterval`	<maximum-interval>	Stringa	Per i `exponential` criteri, l'intervallo più grande per l'intervallo selezionato in modo casuale in formato ISO 8601. Il valore predefinito è 1 giorno (`P1D`). Per altre informazioni, vedere Intervallo esponenziale.
`minimumInterval`	<minimum-interval>	Stringa	Per i `exponential` criteri, l'intervallo più piccolo per l'intervallo selezionato in modo casuale in formato ISO 8601. Il valore predefinito è 5 secondi (`PT5S`). Per altre informazioni, vedere Intervallo esponenziale.

Criteri di ripetizione predefiniti

Connessione or operazioni che supportano i criteri di ripetizione dei tentativi usano Criterio predefinito a meno che non si selezioni un criterio di ripetizione dei tentativi diverso. Per la maggior parte delle operazioni, il criterio Di ripetizione dei tentativi predefinito è un criterio di intervallo esponenziale che invia fino a 4 tentativi a intervalli in aumento esponenziale. Questi intervalli vengono ridimensionati di 7,5 secondi, ma sono limitati tra 5 e 45 secondi. Diverse operazioni usano un criterio di ripetizione dei tentativi predefinito diverso, ad esempio un criterio a intervallo fisso.

Nella definizione del flusso di lavoro la definizione del trigger o dell'azione non definisce in modo esplicito i criteri predefiniti, ma l'esempio seguente illustra il comportamento dei criteri di ripetizione dei tentativi predefiniti per l'azione HTTP:

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

Nessuno - Nessun criterio di ripetizione dei tentativi

Per specificare che l'azione o il trigger non ritenta le richieste non riuscite, impostare retry-policy-type <>su .none

Criteri di ripetizione degli intervalli fissi

Per specificare che l'azione o il trigger attende l'intervallo specificato prima di inviare la richiesta successiva, impostare retry-policy-type <>su .fixed

Esempio

Dopo una prima richiesta con esito negativo, questi criteri di ripetizione provano altre due volte a ricevere le ultime notizie con un intervallo di 30 secondo tra ciascun tentativo:

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

Criteri di ripetizione intervallo esponenziale

Il criterio di ripetizione dell'intervallo esponenziale specifica che il trigger o l'azione attende un intervallo casuale prima di inviare la richiesta successiva. Questo intervallo casuale viene selezionato da un intervallo in crescita esponenziale. Facoltativamente, è possibile eseguire l'override degli intervalli minimi e massimi predefiniti specificando intervalli minimo e massimo personalizzati, in base al flusso di lavoro di un'app per la logica a consumo o standard.

Name	Limite di consumo	Limite standard	Note
Ritardo massimo	Impostazione predefinita: 1 giorno	Impostazione predefinita: 1 ora	Per modificare il limite predefinito in un flusso di lavoro dell'app per la logica a consumo, usare il parametro dei criteri di ripetizione dei tentativi. Per modificare il limite predefinito in un flusso di lavoro dell'app per la logica Standard, vedere Modificare le impostazioni dell'host e dell'app per le app per la logica in App per la logica di Azure a tenant singolo.
Ritardo minimo	Impostazione predefinita: 5 sec	Impostazione predefinita: 5 sec	Per modificare il limite predefinito in un flusso di lavoro dell'app per la logica a consumo, usare il parametro dei criteri di ripetizione dei tentativi. Per modificare il limite predefinito in un flusso di lavoro dell'app per la logica Standard, vedere Modificare le impostazioni dell'host e dell'app per le app per la logica in App per la logica di Azure a tenant singolo.

Name

Limite di consumo

Limite standard

Note

Ritardo massimo

Impostazione predefinita: 1 giorno

Impostazione predefinita: 1 ora

Per modificare il limite predefinito in un flusso di lavoro dell'app per la logica a consumo, usare il parametro dei criteri di ripetizione dei tentativi.

Per modificare il limite predefinito in un flusso di lavoro dell'app per la logica Standard, vedere Modificare le impostazioni dell'host e dell'app per le app per la logica in App per la logica di Azure a tenant singolo.

Ritardo minimo

Impostazione predefinita: 5 sec

Per modificare il limite predefinito in un flusso di lavoro dell'app per la logica a consumo, usare il parametro dei criteri di ripetizione dei tentativi.

Intervalli variabili casuali

Per i criteri di ripetizione dell'intervallo esponenziale, la tabella seguente illustra l'algoritmo generale che App per la logica di Azure usa per generare una variabile casuale uniforme nell'intervallo specificato per ogni tentativo. L'intervallo specificato può essere fino a e includere il numero di tentativi.

Numero di ripetizioni	Intervallo minimo	Intervallo massimo
1	max(0, <intervallo> minimo)	min(interval, <maximum-interval>)
2	max(interval, <minimum-interval>)	min(2 * intervallo, <intervallo> massimo)
3	max(2 * intervallo, <intervallo> minimo)	min(4 * interval, <maximum-interval>)
4	max(4 * interval, <minimum-interval>)	min(8 * intervallo, <intervallo> massimo)
....	....	....

Gestire il comportamento "Esegui dopo"

Quando si aggiungono azioni nella finestra di progettazione del flusso di lavoro, si dichiara in modo implicito l'ordine da usare per l'esecuzione di tali azioni. Al termine dell'esecuzione di un'azione, l'azione viene contrassegnata con uno stato come Succeeded, Failed, Skipped o TimedOut. Per impostazione predefinita, un'azione aggiunta nella finestra di progettazione viene eseguita solo dopo il completamento del predecessore con stato Succeeded . Nella definizione sottostante di un'azione, la runAfter proprietà specifica che l'azione predecessore che deve terminare e gli stati consentiti per tale predecessore prima che l'azione successore possa essere eseguita.

Quando un'azione genera un errore o un'eccezione non gestita, l'azione viene contrassegnata come Non riuscita e qualsiasi azione successore viene contrassegnata come Ignorata. Se questo comportamento si verifica per un'azione con rami paralleli, il motore di App per la logica di Azure segue gli altri rami per determinare i relativi stati di completamento. Ad esempio, se un ramo termina con un'azione Ignorata , lo stato di completamento del ramo si basa sullo stato predecessore dell'azione ignorata. Al termine dell'esecuzione del flusso di lavoro, il motore determina lo stato dell'intera esecuzione valutando tutti gli stati del ramo. Se un ramo termina in caso di errore, l'intera esecuzione del flusso di lavoro è contrassegnata come Non riuscita.

Conceptual diagram with examples that show how run statuses are evaluated.

Per assicurarsi che un'azione possa comunque essere eseguita nonostante lo stato del predecessore, è possibile modificare il comportamento di "esecuzione dopo" di un'azione per gestire gli stati non riusciti del predecessore. In questo modo, l'azione viene eseguita quando lo stato del predecessore è Succeeded, Failed, Skipped, TimedOut o tutti questi stati.

Ad esempio, per eseguire l'azione Office 365 Outlook Send an email after the Excel Online Add a row into a table predecessor action is contrassegnato Failed, anziché Succeeded, modificare il comportamento "Run after" utilizzando la finestra di progettazione o l'editor di visualizzazione codice.

Nota

Nella finestra di progettazione l'impostazione "Esegui dopo" non si applica all'azione che segue immediatamente il trigger perché il trigger deve essere eseguito correttamente prima che la prima azione possa essere eseguita.

Modificare il comportamento "Esegui dopo" nella finestra di progettazione

Standard
Consumo

Nella portale di Azure aprire il flusso di lavoro dell'app per la logica nella finestra di progettazione.
Nella finestra di progettazione selezionare la forma dell'azione. Nel riquadro dei dettagli selezionare Esegui dopo.

Il riquadro Esegui dopo mostra l'azione predecessore per l'azione attualmente selezionata.
Espandere il nodo azione predecessore per visualizzare tutti gli stati "esegui dopo".

Per impostazione predefinita, lo stato "Run after" è impostato su ha esito positivo. Pertanto, l'azione predecessore deve essere eseguita correttamente prima che l'azione attualmente selezionata possa essere eseguita.
Modificare il comportamento "Esegui dopo" impostando lo stato desiderato. Assicurarsi di selezionare prima di tutto un'opzione prima di deselezionare l'opzione predefinita. È necessario avere sempre almeno un'opzione selezionata.

L'esempio seguente seleziona non è riuscito.
Per specificare che l'azione corrente viene eseguita se l'azione predecessore è contrassegnata come Non riuscita, Ignorata o TimedOut, selezionare gli altri stati.
Per richiedere l'esecuzione di più azioni predecessori, ognuna con i propri stati "esegui dopo", espandere l'elenco Seleziona azioni . Selezionare le azioni predecessore desiderate e specificare gli stati "Esegui dopo" necessari.
Quando si è pronti, selezionare Fine.

Modificare il comportamento "Run after" nell'editor della visualizzazione codice

Nella portale di Azure aprire il flusso di lavoro dell'app per la logica nell'editor della visualizzazione codice.

Nella definizione JSON dell'azione modificare la runAfter proprietà con la sintassi seguente:

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

Per questo esempio, modificare la runAfter proprietà da Succeeded a 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"
}

Per specificare che l'azione viene eseguita se l'azione predecessore è contrassegnata come Failedo SkippedTimedOut, aggiungere gli altri stati:
```
"runAfter": {
   "Add_a_row_into_a_table": [
      "Failed", "Skipped", "TimedOut"
   ]
},
```

Valutare le azioni con ambiti e i relativi risultati

Analogamente all'esecuzione di passaggi dopo singole azioni con l'impostazione "Esegui dopo", è possibile raggruppare le azioni all'interno di un ambito. 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. Al termine dell'esecuzione di tutte le azioni in un ambito, l'ambito stesso ottiene il proprio stato.

Per controllare lo stato di un ambito, è possibile usare gli stessi criteri usati per controllare lo stato di esecuzione di un flusso di lavoro, ad esempio Succeeded, Failed e così via.

Per impostazione predefinita, quando tutte le azioni dell'ambito hanno esito positivo lo stato dell'ambito viene contrassegnato come Succeeded. Se l'azione finale in un ambito è contrassegnata come Non riuscita o interrotta, lo stato dell'ambito è contrassegnato come Non riuscito.

Per intercettare le eccezioni in un ambito Non riuscito ed eseguire azioni che gestiscono tali errori, è possibile usare l'impostazione "Esegui dopo" che ha avuto esito negativo . In questo modo, se le azioni nell'ambito hanno esito negativo e si usa l'impostazione "Esegui dopo" per tale ambito, è possibile creare una singola azione per intercettare gli errori.

Per i limiti degli ambiti, vedere Limiti e configurazione.

Ottenere il contesto e i risultati per gli errori

Anche se l'intercettazione degli errori da un ambito è utile, è anche possibile che si voglia più contesto per apprendere le azioni esatte non riuscite più eventuali errori o codici di stato. La result() funzione restituisce i risultati delle azioni di primo livello in un'azione con ambito. Questa funzione accetta il nome dell'ambito come singolo parametro e restituisce una matrice con i risultati di tali azioni di primo livello. Questi oggetti azione hanno gli stessi attributi degli attributi restituiti dalla actions() funzione, ad esempio l'ora di inizio dell'azione, l'ora di fine, lo stato, gli input, gli ID di correlazione e gli output.

Nota

La result() funzione restituisce i risultati solo dalle azioni di primo livello e non da azioni annidate più approfondite, ad esempio azioni switch o condition.

Per ottenere il contesto delle azioni non riuscite in un ambito, è possibile usare l'espressione @result() con il nome dell'ambito e l'impostazione "Esegui dopo". Per filtrare la matrice restituita in base alle azioni con stato Non riuscito, è possibile aggiungere l'azione Filtra matrice. Per eseguire un'azione per un'azione non riuscita restituita, eseguire la matrice filtrata restituita e usare un ciclo For each.

L'esempio JSON seguente invia una richiesta HTTP POST con il corpo della risposta per tutte le azioni non riuscite all'interno dell'azione di ambito denominata My_Scope. Una spiegazione dettagliata segue l'esempio.

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

I passaggi seguenti descrivono cosa accade in questo esempio:

Per ottenere il risultato da tutte le azioni all'interno di My_Scope, l'azione Filtra matrice usa questa espressione di filtro: @result('My_Scope')
La condizione per La matrice di filtri è qualsiasi @result() elemento con stato uguale a Failed. Questa condizione filtra la matrice con tutti i risultati dell'azione da My_Scope fino a una matrice con solo i risultati dell'azione non riuscita.
Eseguire un'azione For_each ciclo sugli output della matrice filtrata. Questo passaggio esegue un'azione per ogni risultato di azione non riuscita precedentemente filtrato.

Se un'unica azione nell'ambito ha esito negativo, le azioni nel For_each ciclo vengono eseguite una sola volta. Molte azioni non riuscite determinano un'azione per errore.
Inviare un POST HTTP nel corpo della risposta dell'elemento For_each , ovvero l'espressione @item()['outputs']['body'] .

La forma dell'elemento @result() è uguale alla forma di @actions() e può essere analizzata nello stesso modo.
Inclusione di due intestazioni personalizzate con il nome dell'azione non riuscita (@item()['name']) e l'ID rilevamento client dell'esecuzione non riuscita (@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. All'esterno di un'azione For_each , @result() restituisce una matrice di questi oggetti.

{
   "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. È possibile scegliere di eseguire una singola azione di gestione delle eccezioni all'esterno dell'ambito che accetta l'intera matrice filtrata di errori e rimuovere l'azione For_each . È anche possibile includere altre proprietà utili dalla \@result() risposta, come descritto in precedenza.

Configurare i log di Monitoraggio di Azure

I modelli precedenti sono modi utili per gestire gli errori e le eccezioni che si verificano all'interno di un'esecuzione. Tuttavia, è anche possibile identificare e rispondere agli errori che si verificano indipendentemente dall'esecuzione. Per valutare gli stati di esecuzione, è possibile monitorare i log e le metriche per le esecuzioni oppure pubblicarli in qualsiasi strumento di monitoraggio preferito.

Monitoraggio di Azure, ad esempio, offre un modo semplificato per inviare tutti gli eventi del flusso di lavoro, inclusi tutti gli stati di esecuzione e azione, a una destinazione. È possibile configurare avvisi per metriche e soglie specifiche in Monitoraggio di Azure. È anche possibile inviare eventi del flusso di lavoro a un'area di lavoro Log Analytics o a un account di archiviazione di Azure. In alternativa, è possibile trasmettere tutti gli eventi tramite Hub eventi di Azure in Analisi di flusso di Azure. In Analisi di flusso è possibile scrivere query dinamiche in base a un'anomalia, una media o un errore dei log di diagnostica. È possibile usare Analisi di flusso per inviare informazioni ad altre origini dati, ad esempio a code, argomenti, SQL, Azure Cosmos DB o Power BI.

Per altre informazioni, vedere Configurare i log di Monitoraggio di Azure e raccogliere i dati di diagnostica per App per la logica di Azure.

Passaggi successivi

Altre informazioni su esempi e scenari di App per la logica di Azure