streamalism.org

1. Introduktion

Som standard vil eventuelle fejl, der opstår under en Spring Batch-jobbehandling, få et tilsvarende trin til at mislykkes. Der er dog mange situationer, hvor vi hellere vil springe det aktuelt behandlede element over for visse undtagelser.

I denne vejledning vi undersøger to tilgange til at konfigurere springlogik i Spring Batch-rammen.

2. Vores brugssag

Med henblik på eksempler Vi genbruger et simpelt, klumporienteret job, der allerede er præsenteret i vores introduktionsartikel om Spring Batch.

Dette job konverterer nogle økonomiske data fra et CSV til XML-format.

2.1. Indtastningsdata

Lad os først tilføje et par rækker til den originale CSV-fil:

brugernavn, bruger-id, transaktionsdato, transaktionsbeløb 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, indeholder de sidste tre rækker nogle ugyldige data - række 5 og 7 mangler brugernavnfeltet, og transaktionsbeløbet i række 6 er negativt.

I de senere sektioner konfigurerer vi vores batchjob til at springe disse beskadigede poster over.

3. Konfiguration af Skip Limit og undtagelser, der kan springes over

3.1. Ved brug af springe og springLimit

Lad os nu diskutere den første af to måder at konfigurere vores job til at springe varer over i tilfælde af en fejl - den springe og springLimit metoder:

@Bean public Step skippingStep (ItemProcessor processor, ItemWriter Writer) kaster ParseException {return stepBuilderFactory .get ("skippingStep") .chunk (10) .reader (itemReader (invalidInputCsv)) .processor (processor) .writer (writer) .faultTolerant ( ) .skipLimit (2) .skip (MissingUsernameException.class) .skip (NegativeAmountException.class) .build (); }

Først og fremmest, for at aktivere springfunktionalitet skal vi medtage et opkald til fejl tolerant() under trinbygningsprocessen.

Inden for springe() og skipLimit (), definerer vi de undtagelser, vi vil springe over, og det maksimale antal springede varer over.

I ovenstående eksempel, hvis enten a Mangler brugernavn undtagelse eller NegativeAmountException kastes under læse-, proces- eller skrivefasen, så udelades det aktuelt behandlede element og tælles med i den samlede grænse på to.

Følgelig, hvis en undtagelse kastes for tredje gang, vil hele skridtet mislykkes.

3.1. Ved brug af noSkip

I det foregående eksempel, enhver anden undtagelse udover Mangler brugernavn undtagelse og NegativeAmountException får vores skridt til at mislykkes.

I nogle situationer kan det dog være mere passende at identificere undtagelser, der skulle få vores skridt til at mislykkes og springe over andre.

Lad os se, hvordan vi kan konfigurere dette ved hjælp af springe, springLimitog noSkip:

@Bean public Step skippingStep (ItemProcessor processor, ItemWriter Writer) kaster ParseException {return stepBuilderFactory .get ("skippingStep") .chunk (10) .reader (itemReader (invalidInputCsv)) .processor (processor) .writer (writer) .faultTolerant ( ) .skipLimit (2) .skip (Exception.class) .noSkip (SAXException.class) .build (); }

Med ovenstående konfiguration instruerer vi Spring Batch framework til at springe over enhver Undtagelse (inden for en konfigureret grænse) undtagen SAXUndtagelse. Det betyder SAXUndtagelse forårsager altid en trinfejl.

Rækkefølgen af springe() og noSkip () opkald betyder ikke noget.

4. Brug af brugerdefineret Spring over politik

Nogle gange har vi muligvis brug for en mere sofistikeret skip-check-mekanisme. Til dette formål Spring Batch rammer giver Spring over politik interface.

Vi kan derefter levere vores egen implementering af springlogik og tilslutte den til vores trindefinition.

Når du holder det foregående eksempel i tankerne, kan du forestille dig, at vi stadig vil definere en springbegrænsning på to emner og kun lave Mangler brugernavn undtagelse og NegativeAmountException kan springes over.

Imidlertid, en yderligere begrænsning er, at vi kan springe over NegativMængdeundtagelse, men kun hvis beløbet ikke overstiger en defineret grænse.

Lad os implementere vores brugerdefinerede Spring over politik:

offentlig klasse CustomSkipPolicy implementerer SkipPolicy {privat statisk endelig int MAX_SKIP_COUNT = 2; privat statisk endelig 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 af NegativeAmountException && skipCount <MAX_SKIP_COUNT) {NegativeAmountException ex = (NegativeAmountException) kastbar; hvis (f.eks. getAmount () <INVALID_TX_AMOUNT_LIMIT) {returner falsk; } andet {returner sandt; }} returner falsk; }}

Nu kan vi bruge vores brugerdefinerede politik i en trindefinition:

 @Bean public Step skippingStep (ItemProcessor processor, ItemWriter Writer) kaster ParseException {return stepBuilderFactory .get ("skippingStep") .chunk (10) .reader (itemReader (invalidInputCsv)) .processor (processor) .writer (Writer). ) .skipPolicy (ny CustomSkipPolicy ()) .build (); }

Og på samme måde som vores tidligere eksempel er vi stadig nødt til at bruge fejl tolerant() for at aktivere springfunktionalitet.

Denne gang ringer vi dog ikke springe() eller noSkip (). I stedet, vi bruger skipPolicy () metode til at give vores egen implementering af Spring over politik interface.

Som vi kan se, denne tilgang giver os mere fleksibilitet, så det kan være et godt valg i visse brugssager.

5. Konklusion

I denne vejledning præsenterede vi to måder at gøre et Spring Batch-job fejltolerant.

Selvom du bruger en skipLimit () sammen med springe() og noSkip () metoder synes at være mere populære, kan vi finde implementering af en brugerdefineret Spring over politik at være mere praktisk i nogle situationer.

Som sædvanligt er alle kodeeksempler tilgængelige på GitHub.