SchedulerAdapter

Der SchedulerAdapter bildet die Schnittstelle zwischen der Welt der Administrations-Tools und der Management Schicht des Batch Programms.

Die grundsätzlichen Funktionen der Scheduler Adapter Schnittstelle sind:

• Jobs erzeugen und die Job Parameter setzen
• Jobs starten, verfolgen sowie Exit- und Reason-Codes als auch Reason-Text zurückliefern
• Aktuellen Job-Status und Progress beobachten

In der Entwicklungsumgebung erfolgt die Auslösung der Jobs manuell, in der Testumgebung kommen Testdriver zum Einsatz und in der Produktion wird die Steuerung höchstwahrscheinlich durch den Enterprise Scheduler sichergestellt.

Der Enterprise Scheduler ist dabei eine vom Batch Framework unabhängige Komponente und steuert die zeitliche und örtliche Abhängigkeiten für die Job Ausführung so, dass eine optimale Auslastung über verschiedene Plattformen sichergestellt und die Kontrolle der Batch-Umgebung gewährleistet werden kann.

JobController

Der JobController hat die direkte Steuerung der Batch Jobs zur Aufgabe.

Beim Job-Controller handelt es sich um ein JMX Bean oder um ein Servlet, welches die Befehle des Schedulers vom Scheduler Adapter entgegennimmt. Im Gegenzug versorgt der Controller den SchedulerAdapter wiederum mit Status- und Progressinfos.

Falls ein Batch Repository vorhanden ist, holt der Job-Controller Planungsinfos wie beispielsweise die Job Parameter aus dem Repository und schreibt Statusinfos wieder dorthin zurück.

Coupler

Der Coupler ermöglicht die Kommunikation der Processing Komponenten mit der Management Schicht.

Einerseits erhält der Coupler Runtime Artefakte wie fachliche Fehlermeldungen oder Recap-Informationen von den Processing Komponenten und leitet Runtime Artefakte an JobController & Repository weiter. Andererseites gibt er aber auch Management Befehle wie beispielsweise einen Abort Request an die Processing Schicht weiter.

Im JEE Umfeld ist der Coupler zudem dafür verantwortlich, die Transaktionskontrolle gegenüber dem Repository sicherzustellen, wenn Runtime Artefakte ins Repository geschrieben werden müssen.

Repository

Das Repository stellt die Persistenz-Schicht des Batch Frameworks zur Verfügung.

Es enthält einerseits geplante Jobs und persistiert andererseit die Runtime Artefakte während der Progammausführung.

Der Zugriff für die Planung sowie die Auswertung der Jobs erfolgt per Webadmin GUI. Weitere Informationen dazu sind bei Xinventa erhältlich.

BusinessLogicService

Der BusinessLogicService gehört nicht mehr zum eigentlichen Teil des Batch Frameworks, sondern er ist der Teil der BusinessLogic, auf welchem die BTP Architektur aufsetzt (siehe Grundlagen ).

Nicht performancekritische Anwendungen können direkt die für das OLTP vorgesehenen Funktionen verwenden. Sobald die Laufzeit jedoch ein entscheidender Faktor wird, muss der BusinessLogic Layer sehr wahrscheinlich um Funktionen für die Massenselektion und den Massenupdate erweitert werden.

Bei einfachen Batch Programmen kann es aus Effizienzgründen durchaus auch Sinn machen, direkt auf die Funktionen der Persistenz-Schicht zuzugreifen, ohne dass diese zusätzlich durch die BusinessLogic Schicht gekapselt sind.

WorkManager

Der WorkManager steuert die Datenselektion und sort dafür, dass die von BatchIterator erzeugten Lots an den LotSlicer übergeben werden.

Im Java EE Umfeld handelt es sich beim WorkManager mit Vorteil um ein Stateless Session Bean, welches im Normalfall ohne Transaktion läuft, um potentielle Probleme mit allfälligen Transaktions-Timeouts zu umgehen, falls etwas längere Laufzeiten zu erwarten sind oder das Batch Programm "suspendable" gemacht werden soll.

Der BatchIterator wird von WorkManager so lange aufgerufen, bis der ganze Batch in Lots und Slices unterteilt ist. Für jeden Lot sorgt der WorkManager dafür, dass der LotSlicer aufgerufen wird. Daneben werden Progress Informationen und Status Updates an die Management-Schicht zurückgegeben.

BatchIterator

Der BatchIterator unterteilt den ganzen Batch in Lots und Slices.

Beim BatchIterator handelt es sich um ein Java SE POJO, welches vom WorkManager in einer statusbehafteten Art und Weise aufgerufen wird. Nach der Initialisierung wird vom WorkManager so lange ein Lot angefordert, bis der Batch vollständig unterteilt ist.

Die Selektion der Daten erfolgt über den BusinessLogic oder den Persistence Layer.

LotSlicer

Der LotSlicer sendet die im Lot enthaltenen Slices an die Message Queue und erzeugt dafür pro Slice eine JMS basierte Slice-Message.

Beim LotSlicer handelt es sich um ein Java EE Stateless Session Bean mit einem Transaktions-Attribut von REQUIRES_NEW da gewährleistet sein muss, dass alle Slices eines Lots in einer Transaktion geschrieben werden.

MessageQueue

Die JMS MessageQueue speichert die Slice-Messages bis zur Verarbeitung durch den MessageListener.

Der JMS Standard definiert dabei die Interfaces, die Queue selber wird durch einen herstellerspezifischen JMS Provider bereitgestellt.

Als Teil des Applikationsservers liest ein JMS-Provider-spezifischer Message Consumer eine Slice-Message und ruft in einer Transaktion den MessageListener auf.

MessageListener

Der MessageListener entfernt den JMS "Mantel" der SliceMessage und ruft mit dem darin enthaltenen SliceContext den SliceWorker auf.

Der MessageListener ist ein Java EE Message Driven Bean (MDB), welches zudem diverse Steuerungsfunktionen wie das Protokollieren der Slice-Runs oder die Kontrolle des ConsumeOnException-Verhaltens übernimmt.

Slice Worker

Der SliceWorker ist für die Verarbeitung eines ganzen Slice verantwortlich.

Als Java EE Stateless Session Bean gewährleistet der SliceWorker durch die richtige Transaktionskontrolle die Datenkonsistenz der im Slice enthaltenen Records.

Der SliceWorker ruft dazu für jeden im Slice enthaltenen Record den RecordProcessor auf. Falls Probleme bei der Verarbeitung entstehen, wird durch den SliceWorker das ConsumeOnException Verhalten definiert.

Der SliceWorker kann durch einen SliceProcessor ersetzt werden, falls die Verarbeitung ohne RecordProcessor stattfinden soll.

RecordProcessor

Im RecordProcessor findet die eigentliche Verarbeitung eines Records für ein Batch Programm statt.

Auch hier kommt ein Java EE Stateless Session Bean zum Einsatz, kann doch durch geschickte Wahl der Transaktionsattribute je nach Anforderungen bestimmte Verhaltensweisen bei Verarbeitungsfehlern erreicht werden ohne dass die Datenkonsistenz darunter zu leiden hat.

Der RecordProcessor verarbeitet einen oder mehrere Records über Funktionen der BusinessLogic oder der Persistence Schicht.

Processing Varianten

Wie bereits in den Grundlagen zur Robustheit darauf hingewiesen, spielt die Idempotenz eines Batch Programmes eine wichtig Rolle beim täglichen Betrieb. Kann ein Programm automatisch wiederaufgesetzt werden, indem die Datenkonsistenz bei einem Abbruch gewährleistet werden kann oder ist sogar eine All-Or-Nothing Strategie implementiert, dann macht es unter Umständen Sinn, die Verarbeitung von fehlerhaften Slices gezielt abzubrechen.

Bei der Consume-On-Exception Strategie wird die JMS Message im Fehlerfall nicht in die JMS Queue zurückgeschrieben, sondern die Message wird ganz bewusst konsumiert und dieser Umstand sowie die dazu führenden Rahmenbedingungen im Job Protokoll entsprechend festgehalten. Mit dieser Information im Job Protokoll können dann Korrekturprozesse ausgeführt werden, welche die fachlichen Daten korrigieren. Anschliessend kann falls nötig ein sogenannter "Nachlauf" geplant und ausgeführt werden.

Als Speziallfall der Consume-On-Exception Strategie kann die Max-Worker-Run Strategie angesehen werden. Bei dieser wird die JMS Message unmittelbar nach dem Start des MDB's konsumiert (d.h. ohne dass zuvor eine Exception aufgetreten wäre), falls der zu verarbeitende Slice eine spezifizierte Anzahl Worker-Runs überschritten hat.