streamalism.org

1. Introduksjon

Som standard vil eventuelle feil som oppstår under en Spring Batch-jobbbehandling, gjøre et tilsvarende trinn mislykkes. Imidlertid er det mange situasjoner der vi helst vil hoppe over det nåværende behandlede elementet for visse unntak.

I denne veiledningen, vi vil utforske to tilnærminger for å konfigurere hopplogikk i Spring Batch-rammeverket.

2. Brukssaken vår

I form av eksempler, vi vil bruke en enkel, klumporientert jobb som presenteres allerede i vår innledende artikkel om Spring Batch.

Denne jobben konverterer noen økonomiske data fra et CSV til XML-format.

2.1. Inndata

La oss først legge til noen rader i den opprinnelige CSV-filen:

brukernavn, bruker_id, transaksjonsdato, transaksjonsbeløp devendra, 1234, 31/10/2015, 10000 john, 2134, 3/12/2015, 12321 robin, 2134, 2/02/2015, 23411, 2536, 3/10/2019, 100 mike, 9876, 5/11/2018, -500, 3425, 10/10/2017, 9999

Som vi kan se, inneholder de siste tre radene ugyldige data - rad 5 og 7 mangler brukernavnfeltet, og transaksjonsbeløpet i rad 6 er negativt.

I de senere avsnittene konfigurerer vi batchjobben vår til å hoppe over disse ødelagte postene.

3. Konfigurere skipbegrensning og unntak som kan hoppes over

3.1. Ved hjelp av hopp over og skipLimit

La oss nå diskutere den første av to måter å konfigurere jobben vår til å hoppe over varer i tilfelle en feil - hopp over og skipLimit metoder:

@Bean offentlig trinnhoppingStep (ItemProcessor-prosessor, ItemWriter-forfatter) kaster ParseException {return stepBuilderFactory .get ("skippingStep") .chunk (10) .reader (itemReader (invalidInputCsv)). Prosessor (prosessor) .writer (skribent) .faultTolerant ( ) .skipLimit (2) .skip (MissingUsernameException.class) .skip (NegativeAmountException.class) .build (); }

Først av alt, for å aktivere hoppfunksjonalitet, må vi inkludere en samtale til feiltolerant() under trinnbyggingsprosessen.

Innenfor hopp over () og skipLimit (), definerer vi unntakene vi vil hoppe over og maksimalt antall varer som hoppes over.

I eksemplet ovenfor, hvis enten a Mangler brukernavn unntak eller NegativeAmountException kastes i løpet av lese-, prosess- eller skrivefasen, vil den nå behandlede varen utelates og telles mot den totale grensen på to.

Følgelig hvis et unntak kastes for tredje gang, vil hele trinnet mislykkes.

3.1. Ved hjelp av noSkip

I forrige eksempel, noe annet unntak enn Mangler brukernavn unntak og NegativeAmountException gjør at trinnet vårt mislykkes.

I noen situasjoner kan det imidlertid være mer hensiktsmessig å identifisere unntak som skulle få trinnet til å mislykkes og hoppe over andre.

La oss se hvordan vi kan konfigurere dette ved hjelp av hopp over, skipLimit, og noSkip:

@Bean offentlig trinnhoppingStep (ItemProcessor-prosessor, ItemWriter-forfatter) kaster ParseException {return stepBuilderFactory .get ("skippingStep") .chunk (10) .reader (itemReader (invalidInputCsv)). Prosessor (prosessor) .writer (skribent) .faultTolerant ( ) .skipLimit (2) .skip (Exception.class) .noSkip (SAXException.class) .build (); }

Med konfigurasjonen ovenfor instruerer vi Spring Batch-rammeverket om å hoppe over hvilken som helst Unntak (innenfor en konfigurert grense) unntatt SAXException. Dette betyr SAXException forårsaker alltid en trinnfeil.

Rekkefølgen av hopp over () og noSkip () samtaler spiller ingen rolle.

4. Bruke egendefinert SkipPolicy

Noen ganger kan det hende vi trenger en mer sofistikert hoppkontrollmekanisme. For den grunnen, Spring Batch framework gir SkipPolicy grensesnitt.

Vi kan da tilby vår egen implementering av hopplogikk og koble den til vår trinndefinisjon.

Med det forrige eksemplet i bakhodet, forestill deg at vi fortsatt vil definere en hoppgrense på to elementer og bare lage Mangler brukernavn unntak og NegativeAmountException kan hoppes over.

Derimot, en ekstra begrensning er at vi kan hoppe over NegativtMengde unntak, men bare hvis beløpet ikke overstiger en definert grense.

La oss implementere vår skikk SkipPolicy:

offentlig klasse CustomSkipPolicy implementerer SkipPolicy {privat statisk slutt int MAX_SKIP_COUNT = 2; privat statisk slutt int INVALID_TX_AMOUNT_LIMIT = -1000; @Override public boolean shouldSkip (Throwable throwable, int skipCount) throw SkipLimitExceededException {if (throwable instanceof MissingUsernameException && skipCount <MAX_SKIP_COUNT) {return true; } hvis (kastbar forekomst av NegativeAmountException && skipCount <MAX_SKIP_COUNT) {NegativeAmountException ex = (NegativeAmountException) kastbar; hvis (eks. getAmount () <INVALID_TX_AMOUNT_LIMIT) {return false; } annet {returner sant; }} returner falsk; }}

Nå kan vi bruke vår tilpassede policy i en trinndefinisjon:

 @Bean offentlig trinnhoppingStep (ItemProcessor-prosessor, ItemWriter-forfatter) kaster ParseException {return stepBuilderFactory .get ("skippingStep") .chunk (10) .reader (itemReader (invalidInputCsv)). Prosessor (prosessor) .writer (skribent) .faultTolerant ( ) .skipPolicy (ny CustomSkipPolicy ()) .build (); }

Og på samme måte som vårt forrige eksempel, trenger vi fortsatt å bruke feiltolerant() for å aktivere hoppfunksjonalitet.

Denne gangen ringer vi imidlertid ikke hopp over () eller noSkip (). I stedet, vi bruker skipPolicy () metode for å gi vår egen implementering av SkipPolicy grensesnitt.

Som vi kan se, denne tilnærmingen gir oss mer fleksibilitet, så det kan være et godt valg i visse brukssaker.

5. Konklusjon

I denne opplæringen presenterte vi to måter å lage en Spring Batch-jobb feiltolerant.

Selv om du bruker en skipLimit () sammen med hopp over () og noSkip () metoder ser ut til å være mer populære, kan vi finne implementering av en tilpasset SkipPolicy å være mer praktisk i noen situasjoner.

Som vanlig er alle kodeeksemplene tilgjengelige på GitHub.