Errori ed esecuzione condizionale
SI APPLICA A:
Azure Data Factory Azure Synapse Analytics
Suggerimento
Provare Data Factory in Microsoft Fabric, una soluzione di analisi completa per le aziende. Microsoft Fabric copre tutti gli elementi, dallo spostamento dei dati all'analisi scientifica dei dati, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Scopri come avviare gratuitamente una nuova versione di valutazione .
Percorsi condizionali
L'orchestrazione della pipeline di Azure Data Factory e Synapse consente la logica condizionale e consente all'utente di seguire un percorso diverso in base ai risultati di un'attività precedente. L'uso di percorsi diversi consente agli utenti di creare pipeline affidabili e incorpora la gestione degli errori nella logica ETL/ELT. In totale, sono consentiti quattro percorsi condizionali,
| Nome | Spiegazione |
|---|---|
| In caso di esito positivo | (Passaggio predefinito) Eseguire questo percorso se l'attività corrente è riuscita |
| In caso di esito negativo | Eseguire questo percorso se l'attività corrente non è riuscita |
| Al termine | Eseguire questo percorso dopo il completamento dell'attività corrente, indipendentemente dal fatto che abbia avuto esito positivo o negativo |
| Al momento di ignorare | Eseguire questo percorso se l'attività stessa non è stata eseguita |
È possibile aggiungere più rami in seguito a un'attività, con un'eccezione: al termine del percorso non può coesistere con il percorso Su esito positivo o In caso di errore . Per ogni esecuzione della pipeline, al massimo viene attivato un percorso, in base al risultato dell'esecuzione dell'attività.
Gestione errori
Meccanismo comune di gestione degli errori
Prova blocco Catch
In questo approccio, il cliente definisce la logica di business e definisce solo il percorso In caso di errore per rilevare eventuali errori dall'attività precedente. Questo approccio esegue il rendering della pipeline correttamente, se il percorso in caso di errore ha esito positivo.
Do If Else block
In questo approccio, il cliente definisce la logica di business e definisce sia i percorsi On Failure che On Success. Questo approccio esegue il rendering della pipeline non riesce, anche se il percorso errore ha esito positivo.
Do If Skip Else block
In questo approccio, il cliente definisce la logica di business e definisce sia il percorso In caso di errore che il percorso Su esito positivo , con un'attività fittizia al momento dell'operazione ignorata associata. Questo approccio esegue il rendering della pipeline correttamente, se il percorso in caso di errore ha esito positivo.
Tabella di riepilogo
| Approccio | Definisce | Quando l'attività ha esito positivo, viene visualizzata la pipeline complessiva | In caso di errore dell'attività, viene visualizzata la pipeline complessiva |
|---|---|---|---|
| Try-Catch | Solo in caso di errore | Operazione completata | Operazione completata |
| Do-If-Else | In caso di percorso errore + in caso di esito positivo | Riuscita | Errore |
| Do-If-Skip-Else | Dopo il percorso errore + Dopo l'esito positivo (con un'operazione fittizia su Skip alla fine) | Operazione completata | Operazione completata |
Come vengono determinati gli errori della pipeline
Diversi meccanismi di gestione degli errori comportano uno stato diverso per la pipeline: mentre alcune pipeline hanno esito negativo, altre hanno esito positivo. Si determinano l'esito positivo e gli errori della pipeline come indicato di seguito:
- Valutare il risultato per tutte le attività di foglie. Se un'attività foglia è stata ignorata, viene valutata invece l'attività padre
- Il risultato della pipeline ha esito positivo se e solo se tutti i nodi hanno avuto esito positivo
Supponendo che l'attività In caso di errore e l'attività Fittizia in caso di errore abbiano esito positivo,
Nell'approccio Try-Catch ,
- Quando l'attività precedente ha esito positivo: il nodo In caso di errore viene ignorato e il relativo nodo padre ha esito positivo; la pipeline complessiva ha esito positivo
- Quando l'attività precedente ha esito negativo: viene applicato il nodo In caso di errore ; la pipeline complessiva ha esito positivo
Nell'approccio Do-If-Else ,
- Quando l'attività precedente ha esito positivo: il nodo dopo l'esito positivo e il nodo In caso di errore viene ignorato (e il relativo nodo padre ha esito positivo); la pipeline complessiva ha esito positivo
- Quando l'attività precedente ha esito negativo: il nodo Dopo l'esito positivo viene ignorato e il relativo nodo padre non è riuscito; la pipeline complessiva ha esito negativo
Nell'approccio Do-If-Skip-Else ,
- Quando l'attività precedente ha esito positivo: il nodo Fittizio su Skip viene ignorato e il relativo nodo padre Dopo esito positivo ha esito positivo; l'altra attività del nodo, in caso di errore, viene ignorata e il relativo nodo padre ha esito positivo; la pipeline complessiva ha esito positivo.
- Quando l'attività precedente ha esito negativo: il nodo in caso di errore ha esito positivo e l'esito positivo della pipeline è fittizia ; la pipeline complessiva ha esito positivo
Esecuzione condizionale
Man mano che si sviluppano pipeline più complesse e resilienti, a volte è necessario introdurre esecuzioni condizionali nella logica: eseguire una determinata attività solo se vengono soddisfatte determinate condizioni. I casi d'uso sono molti, ad esempio:
- eseguire un'attività di completamento, ad esempio l'invio di una notifica tramite posta elettronica, se i processi di copia precedenti hanno avuto esito positivo
- eseguire un processo di gestione degli errori, se una delle attività precedenti non è riuscita
- procedere al passaggio successivo se l'attività stessa o l'attività di gestione degli errori corrispondente ha esito positivo
- E così via.
Di seguito vengono illustrate alcune logiche comuni e come implementarle in Azure Data Factory.
Singola attività
Ecco alcuni modelli comuni che seguono una singola attività. È possibile usare questi modelli come blocchi predefiniti per costruire flussi di lavoro complessi.
Gestione degli errori
Il modello è la logica della condizione più comune in Azure Data Factory. Un'attività di gestione degli errori viene definita per il percorso "In caso di errore" e verrà richiamata se l'attività principale ha esito negativo. Deve essere incorporata come procedura consigliata per tutti i passaggi cruciali che devono richiedere alternative di fallback o registrazione.
Procedure consigliate
Alcuni passaggi, ad esempio la registrazione informativa, sono meno critici e gli errori non devono bloccare l'intera pipeline. In questi casi, è consigliabile adottare le strategie consigliate: aggiungere i passaggi successivi al percorso "Al completamento" per sbloccare il flusso di lavoro.
And
Gli scenari più comuni sono "e" condizionali: continuare la pipeline se e solo se le attività precedenti hanno esito positivo. Ad esempio, è possibile che siano presenti più attività di copia che devono avere esito positivo prima di passare alla fase successiva dell'elaborazione dei dati. In Azure Data Factory il comportamento può essere ottenuto facilmente: dichiarare più dipendenze per il passaggio successivo. Graficamente, significa che più righe puntano all'attività successiva. È possibile scegliere il percorso "In caso di esito positivo" per assicurarsi che la dipendenza sia riuscita o il percorso "Al completamento" per consentire l'esecuzione ottimale.
In questo caso, l'attività di attesa di completamento verrà eseguita solo quando entrambe le attività Web hanno avuto esito positivo.
In questo caso, l'attività di attesa di completamento viene eseguita quando ActivitySucceeded supera e ActivityFailed completato. Si noti che con il percorso "On Success" ActivitySucceeded deve avere esito positivo, mentre ActivityFailed nel percorso "Al completamento" viene eseguito con il massimo sforzo, ovvero potrebbe non riuscire.
O
I secondi scenari comuni sono condizionali "o": eseguire un'attività se una delle dipendenze ha esito positivo o negativo. Qui è necessario usare i percorsi "Al completamento", l'attività If Condition e il linguaggio delle espressioni.
Prima di approfondire il codice, è necessario comprendere un'altra cosa. Dopo l'esecuzione e il completamento di un'attività, è possibile fare riferimento al relativo stato con @activity('ActivityName'). Stato. È "Succeeded"_ o "Failed". Questa proprietà viene usata per compilare la logica o condizionale.
Passaggio di registrazione della gestione degli errori condivisi
In alcuni casi, è possibile richiamare un passaggio di gestione o registrazione degli errori condivisi, se una delle attività precedenti non è riuscita. È possibile compilare la pipeline come segue:
- eseguire più attività in parallelo
- aggiungere una condizione if per contenere i passaggi di gestione degli errori, nel ramo True
- connettere le attività all'attività della condizione usando il percorso "Al completamento"
- espressione logica per le letture dell'attività di condizione
@or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded').Status, 'Failed'))
- Nota: è necessario concatenare o se sono presenti più di due attività di dipendenza, ad esempio
@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))
Greenlight se un'attività ha avuto esito positivo
Quando tutte le attività sono ottimali, è possibile procedere con il passaggio successivo se una delle attività precedenti ha avuto esito positivo. È possibile compilare la pipeline come segue:
- eseguire più attività in parallelo
- aggiungere una condizione if per contenere i passaggi successivi, nel ramo True
- connettere le attività all'attività della condizione usando il percorso "Al completamento"
- espressione logica per le letture dell'attività di condizione
@or(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
- Nota: il grafico è esattamente simile allo scenario precedente. L'unica differenza è il linguaggio delle espressioni usato
Scenari complessi
Tutte le attività devono avere esito positivo per procedere
Il modello è una combinazione di due: condizionale e + gestione degli errori. La pipeline procede con i passaggi successivi se tutte le attività in corso hanno esito positivo oppure esegue un passaggio di registrazione degli errori condiviso. È possibile compilare la pipeline come segue:
- eseguire più attività in parallelo
- aggiungere una condizione if. Aggiungere i passaggi successivi nel ramo True e aggiungere il codice di gestione degli errori nel ramo False
- connettere le attività all'attività della condizione usando il percorso "Al completamento"
- espressione logica per le letture dell'attività di condizione
@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
Modelli comuni
Try-Catch-Proceed
Il modello equivale a provare il blocco catch nella codifica. Un'attività potrebbe non riuscire in una pipeline. In caso di errore, il cliente deve eseguire un processo di gestione degli errori per gestirlo. Tuttavia, l'errore singolo dell'attività non deve bloccare le attività successive nella pipeline. Ad esempio, si tenta di eseguire un processo di copia, spostando i file nell'archiviazione. Tuttavia, potrebbe non riuscire a metà strada. In tal caso, voglio eliminare i file parzialmente copiati e non affidabili dall'account di archiviazione (passaggio di gestione degli errori). Ma sto bene per continuare con altre attività in seguito.
Per configurare il modello:
- Aggiungere la prima attività
- Aggiungere la gestione degli errori al percorso UponFailure
- Aggiungere una seconda attività, ma non connettersi alla prima attività
- Connessione sia i percorsi UponFailure che UponSkip dall'attività di gestione degli errori alla seconda attività
Nota
Ogni percorso (UponSuccess, UponFailure e UponSkip) può puntare a qualsiasi attività. Più percorsi possono puntare alla stessa attività. Ad esempio, UponSuccess e UponSkip possono puntare a un'attività mentre UponFailure punta a un'altra.
Il processo di gestione degli errori viene eseguito solo quando la prima attività ha esito negativo. L'attività successiva verrà eseguita indipendentemente dal fatto che la prima attività abbia esito positivo o negativo.
Gestione degli errori generici
In genere, nella pipeline sono in esecuzione più attività in sequenza. In caso di errore, è necessario eseguire un processo di gestione degli errori per cancellare lo stato e/o registrare l'errore. Ad esempio, nella pipeline sono presenti attività di copia sequenziali. Se uno di questi errori ha esito negativo, è necessario eseguire un processo script per registrare l'errore della pipeline.
Per configurare il modello:
- Creare una pipeline di elaborazione dati sequenziale
- Aggiungere un passaggio di gestione degli errori generico alla fine della pipeline
- Connessione sia i percorsi UponFailure che UponSkip dall'ultima attività all'attività di gestione degli errori
L'ultimo passaggio, Generic Error Handling, verrà eseguito solo se una delle attività precedenti ha esito negativo. Non verrà eseguito se tutti hanno esito positivo.
È possibile aggiungere più attività per la gestione degli errori.
