Spring Batch für robuste Massenverarbeitung

• Job, Step und JobRepository.
• ItemReader, ItemProcessor, ItemWriter.
• Chunk-orientierte Verarbeitung.
• Skip, Retry und Restart.
• Partitioning und Remote Chunking für Skalierung.

• Du verarbeitest große Datenmengen planbar.
• Du migrierst Quartz/EJB Timer/Control-M Jobs.
• Du brauchst Restart nach Fehlern und klare Job-Metadaten.

• Batchjob ohne stabile Identifikation verarbeiteter Daten.
• Keine Restart-Strategie.
• Fachlogik nur im Writer verstecken.

Scheduler- und Batch-EJBs werden in Jobs und Steps mit klaren Reader/Processor/Writer-Grenzen überführt.

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

@Configuration
class SettlementBatchConfiguration {
    @Bean
    Step settlementStep(JobRepository jobRepository, PlatformTransactionManager tx,
                        ItemReader<Payment> reader, ItemProcessor<Payment, Settlement> processor,
                        ItemWriter<Settlement> writer) {
        return new StepBuilder("settlementStep", jobRepository)
            .<Payment, Settlement>chunk(500, tx)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .faultTolerant()
            .skip(InvalidPaymentException.class).skipLimit(100)
            .build();
    }
}

• Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
• Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
• Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
• Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?