Felhantering och villkorsstyrd körning

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics

Conditional paths

Azure Data Factory och Synapse Pipeline-orkestrering tillåter villkorlig logik och gör det möjligt för användaren att välja en annan väg baserat på resultatet av en tidigare aktivitet. Med hjälp av olika sökvägar kan användare skapa robusta pipelines och införliva felhantering i ETL/ELT-logik. Totalt tillåter vi fyra villkorsstyrda sökvägar,

Du kan lägga till flera grenar efter en aktivitet, med ett undantag: När den har slutförts kan inte samexistera med sökvägen vid framgång eller vid misslyckande. För varje pipelinekörning aktiveras högst en sökväg baserat på körresultatet av aktiviteten.

Error Handling

Vanliga felhanteringsmekanismer

Prova Catch-block

I den här metoden definierar kunden affärslogiken och definierar endast sökvägen Vid fel för att fånga upp eventuella fel från tidigare aktivitet. Den här metoden gör att pipelinen lyckas om sökvägen vid misslyckande lyckas.

Gör om Annars-blockering

I den här metoden definierar kunden affärslogik och definierar både sökvägarna Vid fel och Vid framgång . Den här metoden renderar pipelinefel, även om sökvägen vid fel lyckas.

Gör om Hoppa över Annars-block

I den här metoden definierar kunden affärslogik och definierar både sökvägen Vid fel och Vid lyckad sökväg, med en dummy vid överhoppad aktivitet kopplad. Den här metoden gör att pipelinen lyckas om sökvägen vid misslyckande lyckas.

Summary table

Hur pipelinefel fastställs

Olika felhanteringsmekanismer leder till olika status för pipelinen: medan vissa pipelines misslyckas lyckas andra. Vi fastställer framgångar och misslyckanden för pipeline på följande sätt:

• Utvärdera resultatet för alla ledighetsaktiviteter. Om en lövaktivitet hoppades över utvärderar vi dess överordnade aktivitet i stället
• Pipelineresultatet är framgångsrikt om och endast om alla utvärderade noder lyckas.

Om vid fel aktiviteten och dummy vid fel aktiviteten lyckas,

• I Try-Catch-metoden använder du

  • När föregående aktivitet lyckas: noden Vid fel skippas och dess föräldranod lyckas. Det övergripande processflödet lyckas.
  • När föregående aktivitet misslyckas: noden Vid fel utförs, den övergripande pipelinen lyckas

• I Do-If-Else-metoden

  • När föregående aktivitet lyckas: noden Vid lyckat resultat lyckas och noden Vid fel hoppas över (och dess överordnade nod lyckas); den övergripande pipelinen lyckas.
  • När en tidigare aktivitet misslyckas: noden Vid framgång hoppas över, och dess överordnade nod misslyckas; den övergripande pipelinestrukturen misslyckas.

• I Do-If-Skip-Else-metoden använder du

  • När föregående aktivitet lyckas: noden Dummy Upon Skip hoppas över och dess överordnade nod Upon Success lyckas; den andra nodaktiviteten, Upon Failure, hoppas över och dess överordnade nod lyckas; den övergripande pipelinen lyckas.
  • När föregående aktivitet misslyckas: noden Vid fel lyckas och Dummy Upon Skip lyckas; den övergripande pipelinen lyckas

Conditional execution

När vi utvecklar mer komplicerade och robusta pipelines krävs det ibland att villkorsbaserade körningar införs i vår logik: kör bara en viss aktivitet om vissa villkor uppfylls. Användningsfallen är många, till exempel:

• köra en uppföljningsaktivitet, till exempel att skicka ett e-postmeddelande, om tidigare kopieringsjobb lyckades
• köra ett felhanteringsjobb om någon av de tidigare aktiviteterna misslyckades
• gå vidare till nästa steg om antingen själva aktiviteten eller motsvarande felhanteringsaktivitet lyckas
• etc.

Här förklarar vi några vanliga logiker och hur du implementerar dem i ADF.

Single activity

Här följer några vanliga mönster efter en enda aktivitet. Vi kan använda dessa mönster som byggstenar för att konstruera komplicerade arbetsflöden.

Error handling

Mönstret är den vanligaste villkorslogik i ADF. En felhanteringsaktivitet definieras för sökvägen "Vid fel" och anropas om huvudaktiviteten misslyckas. Det bör införlivas som bästa praxis för alla verksamhetskritiska steg som behöver återställningsalternativ eller loggning.

Steg för bästa insats

Vissa steg, till exempel informationsloggning, är mindre kritiska och deras fel bör inte blockera hela pipelinen. I sådana fall bör vi använda strategierna för bästa förmåga: lägga till nästa steg i sökvägen "Vid slutförande" för att avblockera arbetsflödet.

And

De första och mest vanliga scenarierna är villkorade "och": fortsätt pipelinen om och endast om de tidigare aktiviteterna lyckas. Du kan till exempel ha flera kopieringsaktiviteter som måste lyckas först innan du går vidare till nästa steg i databearbetningen. I ADF kan beteendet enkelt uppnås: deklarera flera beroenden för nästa steg. Grafiskt innebär det flera rader som pekar in i nästa aktivitet. Du kan välja antingen sökvägen "Vid lyckad" för att säkerställa att beroendet har lyckats eller sökvägen "Vid slutförande" för att tillåta bästa möjliga körning.

Här körs uppföljningsvänteaktiviteten endast när båda webbaktiviteterna lyckades.

Skärmbild som visar att pipelinen fortsätter endast om båda webbaktiviteterna lyckas.

Och här körs uppföljningsvänteaktiviteten när ActivitySucceeded passerar och ActivityFailed har slutförts. Observera att med sökvägen "Vid framgång" måste ActivitySucceeded lyckas, medan ActivityFailed på sökvägen "Vid slutförande" körs med bästa förmåga, det vill s.v.s. kan misslyckas.

Or

Andra vanliga scenarier är villkorsstyrda "eller": kör en aktivitet om något av beroendena lyckas eller misslyckas. Här måste vi använda "Vid slutförande"-sökvägar, If Condition-aktivitet och uttrycksspråk.

Innan vi fördjupar oss i kod måste vi förstå en sak till. När en aktivitet har körts och slutförts kan du referera till dess status med @activity('ActivityName'). Status. Det är antingen "Lyckades"_ eller "Misslyckades". Vi använder den här egenskapen för att skapa villkorsstyrd eller logik.

Loggningssteg för gemensam felhantering

I vissa fall kanske du vill anropa ett steg för hantering eller loggning av delade fel, om någon av de tidigare aktiviteterna misslyckades. Du kan skapa din pipeline så här:

• köra flera aktiviteter parallellt
• lägg till ett if-villkor som ska innehålla felhanteringsstegen i True-grenen
• ansluta aktiviteter till villkorsaktiviteten med hjälp av sökvägen "Vid slutförande"
• logiska uttryck för villkorsaktivitet

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

• Obs! du behöver sammanfogas eller om du har fler än två beroendeaktiviteter, till exempel

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

Greenlight om någon aktivitet lyckades

När alla dina aktiviteter är som bäst kanske du vill gå vidare till nästa steg om någon av de tidigare aktiviteterna lyckades. Du kan skapa din pipeline så här:

• köra flera aktiviteter parallellt
• lägg till ett if-villkor som ska innehålla nästa steg i True-grenen
• ansluta aktiviteter till villkorsaktiviteten med hjälp av sökvägen "Vid slutförande"
• logiska uttryck för villkorsaktivitet

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

• Obs! Diagrammet ser exakt ut som i föregående scenario. Den enda skillnaden är det uttrycksspråk som används

Complex scenarios

Alla aktiviteter måste lyckas för att kunna fortsätta

Mönstret är en kombination av två: villkorlig och + felhantering. Pipelinen går vidare till nästa steg om alla föregående aktiviteter lyckas, annars körs ett delat steg för felloggning. Du kan skapa pipelinen så här:

• köra flera aktiviteter parallellt
• lägg till ett if-villkor. Lägg till nästa steg i True-grenen och lägg till felhanteringskod i false-grenen
• ansluta aktiviteter till villkorsaktiviteten med hjälp av sökvägen "Vid slutförande"
• logiska uttryck för villkorsaktivitet

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

Common patterns

Try-Catch-Proceed

Mönstret motsvarar försök att fånga block i kodning. En aktivitet kan misslyckas i en pipeline. När det misslyckas måste kunden köra ett felhanteringsjobb för att hantera det. Det enskilda aktivitetsfelet bör dock inte blockera aktiviteterna i nästa steg i pipelinen. Till exempel försöker jag köra ett kopieringsjobb och flytta filer till lagring. Men det kan misslyckas halvvägs igenom. Och i så fall vill jag ta bort de delvis kopierade, otillförlitliga filerna från lagringskontot (mitt steg för felhantering). Men jag är ok att fortsätta med andra aktiviteter efteråt.

Så här konfigurerar du mönstret:

• Lägg till den första aktiviteten
• Lägg till felhantering i UponFailure-sökvägen
• Lägg till den andra aktiviteten, men anslut inte till den första aktiviteten
• Ansluta både UponFailure- och UponSkip-sökvägar från felhanteringsaktiviteten till den andra aktiviteten

Fel Hanteringsjobb körs endast när den första aktiviteten misslyckas. Nästa aktivitet körs oavsett om den första aktiviteten lyckas eller inte.

Allmän felhantering

Vanligtvis har vi flera aktiviteter som körs sekventiellt i pipelinen. Om något misslyckas måste jag köra ett felhanteringsjobb för att rensa tillståndet och/eller logga felet. Till exempel har jag sekventiella kopieringsaktiviteter i arbetsflödet. Om något av dessa misslyckas måste jag köra ett skriptjobb för att logga pipelinefelet.

Så här konfigurerar du mönstret:

• Skapa en pipeline för sekventiell databearbetning
• Lägg till ett allmänt felhanteringssteg i slutet av pipelinen
• Ansluta både UponFailure- och UponSkip-sökvägar från den senaste aktiviteten till felhanteringsaktiviteten

Det sista steget, Allmän felhantering, körs bara om någon av de tidigare aktiviteterna misslyckas. Det kommer inte att köras om alla lyckas.

Du kan lägga till flera aktiviteter för felhantering.

Related content

Metrik och aviseringar för Data Factory

Monitor Visually