Fel och villkorsstyrd körning
GÄLLER FÖR: 
Azure Data Factory Azure Synapse Analytics
Dricks
Prova Data Factory i Microsoft Fabric, en allt-i-ett-analyslösning för företag. Microsoft Fabric omfattar allt från dataflytt till datavetenskap, realtidsanalys, business intelligence och rapportering. Lär dig hur du startar en ny utvärderingsversion kostnadsfritt!
Villkorsstyrda sökvägar
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,
| Name | Förklaring |
|---|---|
| Vid lyckad åtgärd | (Standardpass) Kör den här sökvägen om den aktuella aktiviteten lyckades |
| Vid ett haveri | Kör den här sökvägen om den aktuella aktiviteten misslyckades |
| Vid slutförande | Kör den här sökvägen när den aktuella aktiviteten har slutförts, oavsett om den lyckades eller inte |
| Vid hoppa över | Kör den här sökvägen om själva aktiviteten inte kördes |
Du kan lägga till flera grenar efter en aktivitet, med ett undantag: Sökvägen efter slutförande kan inte samexistera med sökvägen Vid lyckad eller Vid fel . För varje pipelinekörning aktiveras högst en sökväg baserat på körningsresultatet för aktiviteten.
Felhantering
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 återger att pipelinen lyckas om sökvägen vid fel 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 återger att pipelinen lyckas om sökvägen vid fel lyckas.
Sammanfattningstabell
| Metod | Definierar | När aktiviteten lyckas visar den övergripande pipelinen | När aktiviteten misslyckas visas den övergripande pipelinen |
|---|---|---|---|
| Try-Catch | Endast vid felsökväg | Klart | Klart |
| Gör-om-annars | Vid felsökväg + Vid lyckade sökvägar | Klart | Fel |
| Gör-om-hoppa över-annars | Vid felsökväg + Vid lyckad sökväg (med en dummy vid hoppa över i slutet) | Klart | Klart |
Hur pipelinefel bestäms
Olika felhanteringsmekanismer leder till olika status för pipelinen: medan vissa pipelines misslyckas lyckas andra. Vi fastställer pipelineframgångar och -fel på följande sätt:
- Utvärdera resultatet för alla lövaktiviteter. Om en lövaktivitet hoppades över utvärderar vi dess överordnade aktivitet i stället
- Pipelineresultatet lyckas om och endast om alla noder utvärderas lyckas
Om du antar att felaktivitet och dummy vid felaktivitet lyckas,
I Try-Catch-metoden använder du
- När föregående aktivitet lyckas: noden Vid fel hoppas över och dess överordnade nod lyckas. Den övergripande pipelinen lyckas
- När föregående aktivitet misslyckas: noden Vid fel utförs, den övergripande pipelinen lyckas
-
- När föregående aktivitet lyckas: noden Vid lyckat resultat och noden Vid fel hoppas över (och dess överordnade nod lyckas); den övergripande pipelinen lyckas
- När föregående aktivitet misslyckas: noden Vid lyckad hoppas över och dess överordnade nod misslyckades. Den övergripande pipelinen 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 När den lyckas , hoppas den andra nodaktiviteten, Vid fel, ö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
Villkorsstyrd körning
När vi utvecklar mer komplicerade och motståndskraftiga pipelines krävs det ibland att villkorliga 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
- och så vidare.
Här förklarar vi några vanliga logiker och hur du implementerar dem i ADF.
Enskild aktivitet
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.
Felhantering
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.
och
De första och vanligaste scenarierna är villkorade "och": fortsätt pipelinen om och bara 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.
Och här körs uppföljningsvänteaktiviteten när ActivitySucceeded passerar och ActivityFailed har slutförts. Observera att med sökvägen "Vid lyckad" måste ActivitySucceeded lyckas, medan ActivityFailed på sökvägen "Vid slutförande" körs med bästa möjliga ansträngning, det vill s.v.s. kan misslyckas.
Eller
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 sökvägarna "Vid slutförande", 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 delad 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 villkorsaktivitetsläsningar
@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 kan du 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 villkorsaktivitetsläsningar
@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
Komplexa scenarier
Alla aktiviteter måste lyckas för att kunna fortsätta
Mönstret är en kombination av två: villkorlig och + felhantering. Pipelinen fortsätter till nästa steg om alla fortsätter aktiviteter lyckas, annars körs ett delat felloggningssteg. 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 villkorsaktivitetsläsningar
@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
Vanliga mönster
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 nästa aktiviteter 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
Kommentar
Varje sökväg (UponSuccess, UponFailure och UponSkip) kan peka på vilken aktivitet som helst. Flera sökvägar kan peka på samma aktivitet. Till exempel kan Både UponSuccess och UponSkip peka på en aktivitet medan UponFailure pekar på en annan aktivitet.
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 pipelinen. 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. Den körs inte om alla lyckas.
Du kan lägga till flera aktiviteter för felhantering.
