Errori ed esecuzione condizionale

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Tip

Provare Data Factory in Microsoft Fabric, una soluzione di analisi all-in-one per le aziende. Microsoft Fabric copre tutto, dallo spostamento dati al data science, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Vedere le informazioni su come iniziare una nuova prova gratuita.

Conditional paths

Azure Data Factory e l'orchestrazione delle pipeline di Synapse consentono l'uso della logica condizionale e permettono all'utente di intraprendere percorsi diversi in base ai risultati di un'attività precedente. L'uso di percorsi diversi consente agli utenti di creare pipeline affidabili e integrare la gestione degli errori nella logica ETL/ELT. In totale, sono consentiti quattro percorsi condizionali,

Name	Explanation
Upon Success	(Percorso predefinito) Eseguire questo percorso se l'attività corrente è riuscita
Upon Failure	Eseguire questo percorso se l'attività corrente non è riuscita
Upon Completion	Eseguire questo percorso dopo il completamento dell'attività corrente, indipendentemente dal fatto che l'operazione sia stata completata o meno
Upon Skip	Eseguire questo percorso se l'attività non è stata eseguita

È possibile aggiungere più rami dopo un'attività, con un'eccezione: il percorso Al Completamento non può coesistere con il percorso Su esito positivo o il percorso In caso di errore. Per ogni esecuzione della pipeline, viene attivato al massimo un percorso, in base al risultato dell'esecuzione dell'attività.

Error Handling

Meccanismo comune di gestione degli errori

Blocco Try Catch

In questo approccio, il cliente definisce la logica di business e definisce solo il percorso A operazione non riuscita per rilevare eventuali errori derivanti dall'attività precedente. Questo approccio considera la pipeline riuscita, se il percorso A operazione non riuscita ha esito positivo.

Blocco Do If Else

In questo approccio, il cliente definisce la logica di business e definisce sia i percorsi A operazione non riuscita che A operazione riuscita. Questo approccio determina la non riuscita della pipeline, anche quando il percorso A operazione non riuscita ha esito positivo.

Blocco Do If Skip Else

In questo approccio, il cliente definisce la logica di business e definisce sia il percorso A operazione non riuscita che il percorso A operazione riuscita, con associata un'attività fittizia A operazione ignorata. Questo approccio considera la pipeline riuscita, se il percorso A operazione non riuscita ha esito positivo.

Summary table

Approach	Defines	Quando l'attività ha esito positivo, la pipeline complessiva mostra	Quando l'attività ha esito negativo, la pipeline complessiva mostra
Try-Catch	Solo percorso in caso di operazione non riuscita	Success	Success
Do-If-Else	Percorsi in caso di operazione non riuscita + in caso di operazione riuscita	Success	Failure
Do-If-Skip-Else	A operazione non riuscita + A operazione riuscita (con un'operazione fittizia su Skip alla fine)	Success	Success

Come vengono determinati i guasti della pipeline

I diversi meccanismi di gestione degli errori determinano stati diversi per la pipeline: mentre alcune pipeline hanno esito negativo, altre hanno esito positivo. Determinano l'esito positivo e gli errori della pipeline come indicato di seguito:

• Valutare i risultati di tutte le attività foglia. Se un'attività foglia è stata ignorata, viene valutata l'attività padre
• Il risultato della pipeline è positivo se e solo se tutti i nodi valutati hanno esito positivo

Supponendo che l'attività A operazione non riuscita e l'attività Fittizia a operazione non riuscita abbiano esito positivo,

• Nell'approccio Try-Catch,

  • Quando l'attività precedente ha esito positivo: il nodo in caso di operazione non riuscita viene ignorato e il relativo nodo padre ha esito positivo; la pipeline complessiva ha esito positivo
  • Quando l'attività precedente ha esito negativo: viene eseguito il nodo In caso di operazione non riuscita; la pipeline complessiva ha esito positivo

• Nell'approccio Do-If-Else,

  • Quando l'attività precedente ha esito positivo: il nodo in caso di operazione riuscita ha esito positivo e il nodo In caso di operazione non riuscita 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 In caso di operazione con esito positivo viene ignorato e il relativo nodo padre ha esito negativo; 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 A operazione riuscita ha esito positivo; l'altra attività del nodo, A operazione non riuscita, 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 A operazione non riuscita ha esito positivo e Fittizia su skip ha esito positivo; la pipeline complessiva ha esito positivo

Conditional execution

Man mano che sviluppiamo pipeline più complesse e resilienti, a volte è necessario introdurre esecuzioni condizionali nella nostra logica: eseguire una determinata attività solo se vengono soddisfatte specifiche condizioni. I casi d'uso sono molti, ad esempio:

• Eseguire un'attività di completamento, come l'invio di una notifica via email, 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
• etc.

Di seguito vengono illustrate alcune logiche comuni e come implementarle in Azure Data Factory.

Single activity

Ecco alcuni modelli comuni che seguono una singola attività. È possibile usare questi modelli come blocchi predefiniti per costruire flussi di lavoro complessi.

Error handling

Il modello è la logica della condizione più comune in Azure Data Factory. Un'attività di gestione errori è definita per il percorso A operazione non riuscita e verrà richiamata se l'attività principale ha esito negativo. Deve essere incorporata come procedura consigliata per tutti i passaggi cruciali che necessitano di alternative di fallback o registrazione.

Procedure consigliate

Alcuni passaggi, ad esempio la registrazione informativa, sono meno critici e i loro 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

Il primo e più comune scenario è quello condizionale "e": continuare la pipeline solo se le attività precedenti hanno esito positivo. Ad esempio, è possibile avere 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, ciò significa più linee che puntano all'attività successiva. È possibile scegliere il percorso "A operazione riuscita" per garantire che le dipendenze abbiano avuto esito positivo, oppure il percorso Al completamento per consentire un'esecuzione con il massimo impegno possibile.

Qui, l'attività di attesa successiva verrà eseguita solo se entrambe le attività Web hanno avuto esito positivo.

In questo caso, l'attività di attesa di completamento viene eseguita quando ActivitySucceeded passa e ActivityFailed è completato. Si noti che con il percorso "A operazione riuscita" ActivitySucceeded deve avere esito positivo, mentre ActivityFailed nel percorso "Al completamento" viene eseguito con un impegno ottimale, vale a dire, potrebbe avere esito negativo.

Or

"Un secondo scenario comune è quello condizionale "or": eseguire un'attività se una qualsiasi delle dipendenze ha esito positivo o negativo. Qui è necessario usare percorsi "Al completamento", attività If Condition e 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. "Operazione riuscita" o "Operazione non riuscita". Questa proprietà viene usata per creare condizioni o logiche.

Passaggio condiviso di gestione errori e registrazione

In alcuni casi, potrebbe essere necessario richiamare un passaggio di gestione o registrazione degli errori condivisi, se una delle attività precedenti non è riuscita. È possibile creare 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à condizione usando il percorso "Al completamento"
• lettura dell'espressione logica per l'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à dipendenti, ad esempio,

@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))

Conferma se almeno un'operazione 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 creare 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à condizione usando il percorso "Al completamento"
• lettura dell'espressione logica per l'attività di condizione

@or(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))

• Nota: il grafico è identico allo scenario precedente. L'unica differenza è il linguaggio delle espressioni usato

Complex scenarios

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 creare 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à condizione usando il percorso "Al completamento"
• lettura dell'espressione logica per l'attività di condizione

@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))

Common patterns

Try-Catch-Proceed

Questo modello equivale a un blocco try-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 risolverlo. 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 va bene proseguire con altre attività dopo.

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à
• Connettere entrambi i percorsi UponFailure e UponSkip dall'attività di gestione errori alla seconda attività

Note

Ogni percorso (UponSuccess, UponFailure e UponSkip) può puntare a qualsiasi attività. Più percorsi possono puntare alla stessa attività. Ad esempio, UponSuccess e UponSkip possono entrambi puntare a un'attività mentre UponFailure punta a un'attività diversa.

Il processo di gestione degli errori viene eseguito solo quando la prima attività ha esito negativo. L'attività successiva verrà eseguita indipendentemente dall'esito della prima attività.

Gestione degli errori generici

In genere, nella pipeline sono in esecuzione più attività in sequenza. Se si verifica un 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 queste operazioni 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
• Connettere entrambi i percorsi UponFailure e UponSkip dall'ultima attività all'attività di gestione degli errori

L'ultimo passaggio, la gestione degli errori generica, verrà eseguito solo se una delle attività precedenti ha esito negativo. "Non verrà eseguito se tutte hanno esito positivo.

È possibile aggiungere più attività per la gestione degli errori.

Related content

Metriche e avvisi di Data Factory

Monitor Visually