Prozessautomatisierung · Prio 9 · Version 4

Batch / Scheduler / Nachtverarbeitung

Periodische Verarbeitung mit Jobketten, Abhaengigkeiten, Zeitfenstern, Wiederanlauf, Kontrolltabellen und Abschlussberichten.

← Startseite
0 Treffer
Kurzverständnis und Systemgrenze

Batch-Verarbeitung wirkt altmodisch, ist aber in vielen Unternehmen der Ort, an dem grosse Mengen fachlich verbindlich verarbeitet werden. Jobs laufen nachts, am Monatsende oder nach externen Dateiankuenften.

Die Logik steckt nicht nur im Programmcode, sondern in Jobketten, Kalendern, Abhaengigkeiten, Kontrolltabellen, Datei-Namenskonventionen, Exit-Codes und manuellen Wiederanlaufanweisungen.

Modernisierung bedeutet, diese Semantik explizit zu machen. Erst wenn Input, Output, Restart, fachliche Teilbarkeit und Monitoring klar sind, kann man Batch nach Spring Batch, Kubernetes CronJobs, Workflow Engines oder Event-getriebene Verarbeitung ueberfuehren.

Daten- und Verantwortungsgrenze: Batch besitzt oft den zeitlichen Takt des Unternehmens. Tagesabschluss, Rechnungsdruck, Mahnung, Provision, DWH-Beladung und Archivierung haengen an Jobketten. Wer Batch ignoriert, modernisiert nur die Online-Haelfte.
Fachliche und technische Darstellung
Fachliche Sicht Batch / Scheduler / Nachtverarbeitung
Fachliche Sicht: Prozess, Verantwortung, Nachweis.
Technische Sicht Batch / Scheduler / Nachtverarbeitung
Technische Sicht: Komponenten, Protokolle, Betriebsbezug.
Wichtige Begriffe und Artefakte

Job Chain

Abfolge abhaengiger Jobs mit Bedingungen und Kalendern.

Restartability

Faehigkeit, nach Fehlern ab einer sicheren Stelle weiterzulaufen.

Checkpoint

Technischer oder fachlicher Fortschrittsmarker.

Batch Window

Zeitfenster, in dem Verarbeitung abgeschlossen sein muss.

Typischer Ablauf Schritt für Schritt
  1. Scheduler startet Job nach Kalender und Abhaengigkeiten.
  2. Job liest Inputdatei oder Datenbank-Selektion.
  3. Verarbeitung schreibt Ergebnisse, Fehlerliste und Kontrolltabelle.
  4. Nachfolgejob startet nur bei erlaubtem Returncode.
  5. Abschlussbericht informiert Betrieb und Fachbereich.
Ausführliche Praxisbeispiele mit Code und Konfiguration

Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.

Control-M Jobdefinition als YAML-Notiz
job: BILLING_MONTHLY_CLOSE
calendar: business-day-last-of-month
predecessors:
  - POLICY_DAILY_CLOSE
  - PAYMENT_IMPORT_DONE
successors:
  - DWH_BILLING_EXPORT
  - ARCHIVE_INVOICE_PDF
sla:
  mustFinishBefore: "05:30"
restart:
  checkpointTable: BATCH_CONTROL
  restartFromLastSuccessfulStep: true
Spring-Batch-aehnlicher Chunk-Step
@Bean
public Step invoiceCloseStep(JobRepository jobRepository, PlatformTransactionManager tx) {
    return new StepBuilder("invoiceCloseStep", jobRepository)
        .<InvoiceCandidate, ClosedInvoice>chunk(500, tx)
        .reader(invoiceCandidateReader())
        .processor(invoiceCloseProcessor())
        .writer(closedInvoiceWriter())
        .faultTolerant()
        .retry(TransientDatabaseException.class)
        .retryLimit(3)
        .build();
}
Kontrolltabelle fuer Wiederanlauf
CREATE TABLE BATCH_CONTROL (
  JOB_NAME          VARCHAR2(80) NOT NULL,
  BUSINESS_DATE     DATE NOT NULL,
  LAST_STEP         VARCHAR2(80),
  LAST_KEY          VARCHAR2(120),
  STATUS            VARCHAR2(20),
  UPDATED_AT        TIMESTAMP,
  PRIMARY KEY (JOB_NAME, BUSINESS_DATE)
);
Risiken, Fehlerbilder und Diagnose
AspektBeschreibung
Fachliches RisikoUnklare Verantwortung fuer Tagesabschluss fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem.
Technisches RisikoControl-M/Autosys und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen.
BetriebsrisikoFehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert.
MigrationsrisikoNeue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern.
Typische Fallen:
  • Job ist nicht idempotent und verarbeitet Datensaetze nach Restart doppelt.
  • Manuelle Korrekturschritte sind nicht dokumentiert.
  • Kalenderregeln wie Feiertage, Monatsultimo und Bankarbeitstage fehlen in neuer Plattform.
  • Batchfenster wird bei Migration unterschätzt, weil Testdaten zu klein sind.
Modernisierungspfad und geeignete Entwurfsmuster
PatternEinsatz in diesem System
Strangler Fig PatternNeue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen.
Anti-Corruption LayerAltbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen.
FacadeKomplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln.
AdapterProtokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen.
Golden Master TestBestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen.
Empfohlene Schritte:
  • Dokumentiere Jobgraph, Input/Output, Returncodes, SLA und Restartpunkt.
  • Führe Chunk-orientierte Verarbeitung mit klaren Commit-Grenzen ein.
  • Baue fachliche Kontrollsummen: Anzahl, Summe, Fehlerquote, Hash.
  • Migriere zuerst isolierte Jobs, dann Jobketten mit klaren Schnittstellen.
Analysefragen für echte Projekte
  • Wer besitzt fachlich die Wahrheit fuer Tagesabschluss?
  • Welche technische Komponente ist kritisch: Control-M/Autosys, JCL/Shell, Spring Batch?
  • Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
  • Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
  • Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
  • Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
  • Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
  • Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung

Entwerfe fuer einen Monatsabschluss eine Jobkette mit Input, Output, Abhaengigkeiten, Returncodes, Kontrollsummen, Restartpunkt und Fachfreigabe. Markiere, was beim Wechsel auf Kubernetes CronJobs verloren gehen koennte.

⌂ Cockpit