Batchrahmen

Da ein Batch in einem Lauf eine große Anzahl an Datensätzen verarbeiten muss, soll ein Batchlauf nicht in einer einzigen, großen Transaktion durchgeführt werden. Ebenso soll nicht jeder Datensatz in einer eigenen Transaktion verarbeitet werden, wie es die Transaktionssteuerung des Anwendungskerns vorsieht. Vielmehr arbeitet ein Batch die Datensätze in mehreren Paketen, und damit auch Transaktionen, ab. Bei einem Wiederanlauf nach einem Fehler muss der Batch in der Lage sein, die bis zu seinem letzten Commit verarbeiteten Datensätze zu überlesen und nur die "neuen" Datensätze zu verarbeiten. Den Commit einer Transaktion bezeichnet man in diesem Fall als Checkpoint. Das Überlesen bereits verarbeiteter Datensätze wird Checkpoint / Restart Fähigkeit genannt.

Für die Umsetzung der Checkpoint / Restart Fähigkeit muss der Batch in jeder Transaktion speichern, welche Datensätze bis zum Commit verarbeitet wurden. Üblicherweise geschieht das durch die Ablage der Anzahl verarbeiteter Datensätze bis zum Commit. Abgelegt werden diese Daten in einer Batch-Statustabelle, welche für jeden Batch eine Zeile enthält.

Ein Batch befindet sich in einem von vier Status, welche in seinen Tabellen gespeichert werden.

Je nachdem, in welchem Status sich der Batch laut den Tabellen gerade befindet, lässt er sich nur mit bestimmten Startarten starten. Welche Startart verwendet wird, muss über Parameter definiert werden.

Batches geben einen Return-Code zurück und erzeugen optional ein ausführliches Verarbeitungsergebnis in Form einer Ergebnisdatei im XML-Format.

Alle Kommandozeilen-Parameter folgen einer Namenskonvention.

Vom Batchrahmen werden folgende Kommandozeilen-Parameter interpretiert:

Es können auch andere Parameter angegeben werden, die der Namenskonvention genügen.

Konfigurationsdateien sind syntaktisch Property-Dateien. Die Konfigurationsdatei mit den unten aufgelisteten Parametern wird als statische Konfiguration im Verzeichnis resources abgelegt und kann daher nicht vom Betrieb angepasst werden.

Betriebliche Konfigurationen müssen wie in Kapitel Betriebliche Konfiguration der Ausführungsbean beschrieben umgesetzt werden.

Sämtliche obigen Parameter müssen vom Betrieb nicht angepasst werden. Falls im Ausnahmefall die Batch-ID angepasst werden muss, kann dies über den Kommandozeilen-Parameter –BatchId <BatchId> geschehen.

Falls für die Ausführungsbean eines Batches Konfigurationen notwendig sind, welche durch den Betrieb gepflegt werden müssen, so ist dies auf eine von zwei Arten umzusetzen.

Zum einen können die Konfigurationen der betrieblichen Konfiguration des Backends hinzugefügt werden. Die Ausführungsbean kann dann die Konfiguration des Backends per Dependency Injection erhalten und sich darüber konfigurieren. Diese Möglichkeit ist zu verwenden, falls nur ein Batch für ein Backend umgesetzt wird. Falls mehrere Batches umgesetzt werden, ist sie dann zu verwenden, wenn sich die Konfigurationen für die einzelnen Batches nicht widersprechen.

Zum anderen kann die Konfiguration in einer neuen Datei abgelegt werden, welche nur für diesen Batch verwendet wird. Diese Datei kann als Properties-Bean geladen und der Ausführungsbean per Dependency Injection übergeben werden. Diese Möglichkeit ist zu verwenden, falls für verschiedene Batches verschiedene Konfigurationsdateien benötigt werden.

Wie in Kapitel Architektur des Batchrahmens beschrieben, werden für einen Batch zwei Spring-Kontexte erzeugt:

Für den Kontext des eigentlichen Backends können die Spring-Konfigurationsdateien übernommen werden. In ihnen müssen folgende Anpassungen vorgenommen werden:

Um Beans gezielt aus der Spring-Konfiguration der Anwendung für die Ausführung eines Batches auszuschließen, kann die Annotation @ExcludeFromBatchContext verwendet werden. Damit werden mit @Component annotierte Klassen oder @Bean-Methoden in @Configuration-Klassen annotiert.

Die Spring-Konfiguration für den Kontext des Batchrahmens muss neu erstellt werden. Hierfür werden gesonderte @Configuration-Klassen erstellt.

Die Persistenzschicht des Batchrahmens wird technisch genauso umgesetzt wie die Persistenzschicht eines Backends.

Der Batchrahmen benötigt für seine Checkpoint / Restart Logik die Möglichkeit, bei jedem Commit den aktuellen Stand des Batches in einer Tabelle zu speichern. Dies wird über die Tabelle BATCH_STATUS umgesetzt.

Die Tabelle BATCH_STATUS enthält für jeden Batch eine Zeile. Ein Batch ist nicht gleichzusetzen mit der Batch-Ausführungsbean. Für eine Bean darf es mehrere Batches geben, welche die Bean für die Ausführung jeweils anders konfigurieren. Für einen Batch werden folgende Informationen verwendet:

Die Tabelle liegt im Datenbankschema des zugehörigen Backends. Es darf keine übergreifenden Tabellen oder ein übergreifendes Datenbankschema für alle Batches geben.

Für Batches, die den Konventionen von Spring Boot folgen, stellt isy-batchrahmen ein explizites Mapping bereit.

Die Tabelle dient nicht der Steuerung des Batches über den Betrieb, sondern nur der Ablage von Informationen zwischen zwei Batch-Läufen. Die Befüllung der Tabelle wird deshalb komplett über den Batchrahmen durchgeführt: Es müssen keine Datensätze manuell befüllt werden: Ist ein Datensatz für einen Batch noch nicht vorhanden, wird er angelegt.

Üblicherweise ist das Locking-Verhalten in Geschäftsanwendungen optimistisch: Datensätze werden nicht explizit gelockt. Stattdessen wird über Versions-Attribute zum Commit-Zeitpunkt geprüft, ob der Datensatz innerhalb der Transaktion verändert wurde. Für die Tabelle des Batchrahmens wird nicht optimistisch, sondern pessimistisch gelockt. Zusätzlich wird als Hibernate Locking-Strategie LOCK_NOWAIT verwendet: Falls auf einen Datensatz zugegriffen wird, welcher gerade gelockt ist, wird nicht bis zur Freigabe gewartet, sondern eine Exception geworfen. Die parallele Ausführung zweier Batches mit gleicher Batch-ID ist nicht erlaubt und soll zum Fehler führen.

In der Property-Datei des Batchrahmens wird die Commit-Rate für den Batch über eine Property konfiguriert. Die Transaktionssteuerung für einen Batch arbeitet daraufhin folgendermaßen:

Das Verhalten in Fehlerfällen ist zu jedem Zeitpunkt während der Verarbeitung gleich: Der Fehler wird geloggt und die Transaktion zurückgerollt. Danach wird versucht, eine neue Transaktion zu starten, um die Status-Tabelle zu aktualisieren: Der Status wird auf abgebrochen gesetzt und die Spalte DatumLetzterAbbruch auf den aktuellen Zeitpunkt. Daraufhin wird versucht, diese Transaktion abzuschließen.

Falls ein Batch durch einen Fehler oder durch das Erreichen der Anzahl zu verarbeitender Datensätze abgebrochen ist, muss ein Restart für ihn durchgeführt werden. In diesem Fall müssen alle bereits verarbeiteten Datensätze übersprungen werden. Ebenso wird die Wiederanlauffähigkeit nach manuellem Terminieren durch das Signal kill -15 sichergestellt.

Die Verarbeitung eines Batches soll überwacht und nachverfolgt werden können. Für die Nachverfolgung können durch die Ausführungsbean zu verschiedenen Zeitpunkten Log-, Statistik- oder Protokoll-Einträge erstellt werden:

Jeder Log-Eintrag eines Batches, insbesondere die Aufrufe der Fachkomponenten, enthält pro Satz eine eindeutige Korrelations-ID. Damit können Log-Einträge nicht nur einem Batchlauf, sondern den einzelnen Sätzen eindeutig zugeordnet werden.

Für die Überwachung wird durch den Batchrahmen eine JMX-Bean bereitgestellt. Über folgende Konfiguration wird ein JMX-Agent erzeugt, welcher die Bean nach außen zugreifbar macht:

Über die Java Management Console kann man danach auf die Daten zugreifen.

Bereitgestellt werden folgende Informationen:

Zur Erhöhung der Sicherheit in der Betriebsumgebung muss eine Absicherung der RMI-Schnittstelle für JMX per Benutzername und Passwort erfolgen (siehe JMX-Parameter). Hierzu sind die JMX-Benutzer und Passwörter entweder direkt in der Datei JRE_HOME/lib/management/jmxremote.password zu konfigurieren, oder der Ort dieser Datei ist über den JVM-Parameter com.sun.management.jmxremote.password.file anzugeben. Die Datei benötigt einen Eintrag für die Rolle controlRole oder für eine beliebige Rolle, für welche in Datei JRE_HOME/lib/management/jmxremote.access der Zugriff readwrite erlaubt ist.

Zur Authentifizierung verwendet der Batch die Benutzerkennung eines technischen Benutzers "internes System", die in seiner Startkonfiguration (als Konfigurationsdatei) hinterlegt und im Benutzerverzeichnis vorhanden ist.

Der Batchrahmen verwendet den Baustein isy-security, um den in der Batch-Konfiguration via oauth2ClientRegistrationId definierten Benutzer über einen der Authentifizierungswege Client Credential oder Ressource Owner Password Credential (deprecated) zu authentifizieren.

Im Zuge des Batchlaufs können nun über den Baustein isy-security Berechtigungsprüfungen (zum Beispiel im Anwendungskern) stattfinden.

Nach der initialen Authentifizierung eines Benutzers führt der Batch vor jedem Verarbeitungsschritt eine Prüfung durch, ob das Authentifizierungstoken erneuert werden muss. Eine erneute Authentifizierung wird dann vorgenommen, wenn das Token als abgelaufen gilt. Ein Token gilt als abgelaufen, wenn es weniger als die via oauth2MinimumTokenValidity angegebenen Sekunden vor dem Ablauf steht oder im Token kein Wert für den Ablaufzeitpunkt angegeben ist.

Folgende Informationen zum Benutzer sind anzugeben

In der Regel wird der Benutzer aus der betrieblichen Konfiguration der Anwendung oder alternativ aus den Aufrufparametern beim Start des Batches gelesen.

In Ausnahmefällen ist es auch möglich, einen Batch zu implementieren, der ohne Benutzer laufen soll. Dies ist nur möglich, wenn bei Aufrufen des Anwendungskerns keine Autorisierungsprüfungen stattfinden und auch keine Nachbarsystemschnittstellen aufgerufen werden.

Enthält eine Anwendung mehrere Batches, so enthält sie auch mehrere BatchKonfigurationen und kann jeden Batch mit einer eigenen oauth2ClientRegistrationId und oauth2MinimumTokenValidity ausstatten.

Der Batch im Testmodus arbeitet analog zum normalen Wirkbetrieb, jedoch werden keine Änderungen an Datenbeständen der Anwendung oder der Nachbarsysteme durchgeführt. Der Testmodus ist für den Betrieb wichtig, um Abschätzungen der Laufzeit durchführen zu können und somit den Batchbetrieb planen zu können. Weiter ist der Testlauf für Bereinigungsläufe wichtig, da so der Fachbereich sehen kann, welche Änderungen durch den Bereinigungslauf ausgeführt werden würden.

In diesem Kapitel werden Architekturmuster zur Umsetzung des Testmodus beschrieben:

Eine Ausführungsbean darf keine Transaktionen starten oder beenden. Sämtliche vom Batchrahmen aufgerufenen Operationen (des Interfaces BatchAusfuehrungsBean) werden innerhalb einer Transaktion aufgerufen. Die Ausführungsbean muss sich hiermit nicht befassen.

Der Batchrahmen führt Logging nur im Fehlerfall durch. Die restlichen Informationen müssen durch die Ausführungsbean geloggt, protokolliert oder einer Statistik-Komponente übergeben werden.

Dazu wird die Ausführungsbean bei allen wichtigen Ereignissen aufgerufen:

Jeder Batch erhält eine eigene Korrelations-ID.

Zusätzlich erhält jeder zu verarbeitende Satz auch eine eigene Korrelations-ID, welche an die Korrelations-ID des Batches angehängt wird. Die entstehende Korrelations-ID Kette wird dann dem MDC hinzugefügt.

Falls für die Verarbeitung im Batch Geschäftslogik benötigt wird, welche für die Webanwendung nicht benötigt wird, ist diese trotzdem den Fachkomponenten im Anwendungskern hinzuzufügen. Die Ausführungsbean ruft die Geschäftslogik dort auf.

Auch wenn in Sonderfällen Datenbank-Aufrufe direkt durch die Ausführungsbean ausgeführt werden müssen, ist die sonstige Geschäftslogik an die Fachkomponenten der Geschäftsanwendung zu delegieren.

Im Rahmen der Initialisierung hat die Ausführungsbean unter anderem die Aufgabe, die Konsistenz und Korrektheit der Eingabedaten zu prüfen. Dies kann beispielsweise ein erstes Durchlaufen der zu verarbeitenden Datei beinhalten. Werden hierbei Fehler erkannt, muss ein entsprechender Fehler geworfen werden.

Falls die zu verarbeitenden Sätze eines Batches das Ergebnis einer Datenbank-Query sind, ist folgendermaßen vorzugehen:

Dies bietet gegenüber dem Auslesen von Entitäten in der Query folgende Vorteile:

Batches müssen beim Start authentifiziert und autorisiert werden, bevor der fachliche Teil der Batchverarbeitung starten kann. Der Batchrahmen fordert, dass in der BatchKonfiguration zur Batch spezifischen Batch-ID das neue Property oauth2ClientRegistrationId hinzugefügt wird, dessen Wert als Indirektion auf eine ClientRegistration führt, um den Batch über den Baustein isy-security zu authentifizieren.

Die Batches sind möglichst robust zu konstruieren: Falls auf ein fachliches Problem in der Ausführungsbean reagiert werden kann, sollte dies getan werden.

Der Batchrahmen unterstützt beispielsweise nicht das Auslassen von Datensätzen im Fehlerfall (etwa für eine Verarbeitung im nächsten Batch). Falls dies umgesetzt werden soll, ist eine entsprechende Verarbeitung in der Ausführungsbean zu implementieren.

Wenn eine Ausführungsbean einen Fehler wirft, so muss dies eine BeanAusfuehrungsException oder ein davon erbender Fehler sein. In diesen Exceptions ist es möglich, den Return-Code des Batches zu definieren. Die Return-Codes sind für den konkreten Batch zu konfigurieren und müssen den Vorgaben in Abschnitt Ergebnis und Return-Codes entsprechen.

Wichtig ist, dass ein Batch bei einem Fehler, den der Batch nicht behandeln kann, abbricht und nicht endlos weiter läuft. Dieses Vorgehen ermöglicht es dem Betrieb, die Ursache des Fehlers zu korrigieren und den Batch neu zu starten.

Abschließend ist die beispielhafte Satzverarbeitung in einer Batch-Ausführungsbean zu sehen. Die gezeigte Satzverarbeitung setzt den Testmodus um, die Anwendungslogik ist weiterhin im Anwendungskern umgesetzt und sie übernimmt Logging, Protokollierung und Statistik-Zählung.