Batch, Scheduler & Langläufer
Spring Batch, Jakarta Batch, CronJobs, Chunking, Restartability, Skip/Retry und fachliche Nachweise.
Version 2BetriebCodeDiagramm
In dieser Datei
Batch ist produktionskritisch
Rechnungsläufe, Exporte, Importe, Mahnungen, Datenabgleiche und Reports laufen oft als Batch. Fehler dort sind nicht kleiner als Fehler in APIs.
Restartability planen
Ein Batch muss nach Fehler weiterlaufen können. Dafür braucht er Fortschrittsstatus, eindeutige Schlüssel, Checkpoints, Fehlerlisten und klare Wiederanlaufregeln.
Scheduler ist nur Auslöser
Die fachliche Logik gehört in Use Cases. Dann kann derselbe Prozess per Cron, manuell, Event oder API gestartet werden.
Entscheidungen
| Entscheidung | Gute Praxis | Prüffrage |
|---|---|---|
| Fachliche Grenze | Zuerst Use Case, Invariante und Verantwortlichkeit klären. | Welche Geschäftsentscheidung wird geschützt? |
| Technische Grenze | Framework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln. | Kann die Domain ohne Framework getestet werden? |
| Betrieb | Timeouts, Logs, Metriken, Traces, Security und Rollback definieren. | Wie erkennt der Betrieb Fehler rechtzeitig? |
Ausführliche Beispiele
Chunk Step
@Bean
Step invoiceExportStep(JobRepository jobs, PlatformTransactionManager tx) {
return new StepBuilder("invoiceExport", jobs)
.<Invoice, ExportLine>chunk(500, tx)
.reader(invoiceReader())
.processor(invoiceProcessor())
.writer(exportWriter())
.faultTolerant()
.skip(InvalidInvoiceException.class)
.skipLimit(100)
.build();
}
Idempotenter Batch-Key
public record BatchItemKey(String jobName, String businessKey, LocalDate businessDate) {}
Typische Stolperfallen
| Stolperfalle | Warum gefährlich |
|---|---|
| Keine Wiederanlaufstrategie | Fehler führen zu manueller Datenbankkorrektur. |
| Zu große Chunks | Locks und Rollbacks werden teuer. |
| Batch nicht beobachtbar | Niemand kennt Fortschritt, Fehler und Restmenge. |