Stapelverarbeitung über Events steuern

16.03.2006
Die fortschreitende Automatisierung der IT-Prozesse führt zu einem Revival der Batch-Verarbeitung. Doch die modernen Infrastrukturen stellen ganz neue Anforderungen an die Flexibilität.

Die Batch-Verarbeitung erlebt derzeit ein bemerkenswertes Revival. Kosteneinsparungen betreffen alle Unternehmensbereiche und zu den üblichen Methoden zur Lösung dieser Aufgabe gehört in der Marktwirtschaft nun einmal die Automatisierung der Arbeitsprozesse. Da wäre es ein Wunder, wenn die IT, die ja die Automatisierung in den letzten Jahr-zehnten maßgeblich vorangetrieben hat, ausgerechnet in ihrer eigenen Sphäre davon ausgenommen bleiben sollte.

Tatsächlich sind stark dialogorientierte Applikationen – also Anwendungen, bei denen der Anwender am Bildschirm seine Eingaben vornimmt – mittlerweile einfach zu teuer, zu langsam und zu fehleranfällig: Sie beanspruchen einen Großteil der Arbeitszeit der Benutzer, schöpfen die verfügbare Rechenleistung kaum aus und sind stark von individueller Aufmerksamkeit und meist auch vom Einbringen von Know-how abhängig.

Immer mehr verlagern moderne Lösungen daher die Arbeitsschritte, für die Dialoge nötig sind, nach außen. Zum einen geben die (End)-Kunden ihre Daten im Rahmen von Web-Anwendungen gleich selbst ein, zum anderen wird der über Jahrhunderte übliche physische Austausch von Geschäftsdokumenten virtualisiert – statt Lieferscheinen und Rechnungen werden Datensätze oder XML-Dokumente ausgetauscht. Aus Sicht der IT-Prozesse bedeutet diese Entwicklung, dass tendenziell Dialogsitzungen durch Batch-Jobs ersetzt werden.

Automatisierung statt Lochkarte

War in der Frühzeit der IT die Batch- oder Stapelverarbeitung eine technische Notwendigkeit – mit Lochkarten ließ sich nun mal kein Dialog führen – so ist sie heute eine Folge fortgeschrittener Prozessautomatisierung. Dass dabei Dialog-Verfahren nicht überflüssig werden, versteht sich. Direkte Eingaben und Abfragen werden unerlässlich bleiben, sie werden sich aber stärker auf Kontroll- und Steuerungsaufgaben konzentrieren und die eigentlichen Geschäftsprozesse mehr und mehr den automatischen Verfahren überlassen.

Laut einer Schätzung der Gartner Group werden vor allem in größeren Unternehmen bisher schon etwa 60 bis 70 Prozent aller IT-Prozesse per Batch abgewickelt. Systemadministratoren erwarten schon in den nächsten zwei Jahren ein Ansteigen dieses Anteils auf über 80 Prozent.

Vor diesem Hintergrund wird auch klar, weshalb Batch-Processing heute kein reines Großrechner-Thema mehr ist, sondern alle Systeme und Plattformen betrifft. PC-Systeme waren tatsächlich lange Zeit fast ganz auf Anwendungen ausgerichtet, die den Dialog mit dem Benutzer in den Mittelpunkt stellten, beispielsweise Textverarbeitung, Kalkulation oder Grafik.

Der Mainframe wird entlastet

Die prozessorientierten Aufgaben blieben dem Mainframe, der mittleren Datentechnik, wie HP3000, IBM/36 bis AS/400 oder den Unix-Systemen vorbehalten. Hier spielte Batch-Processing schon immer eine große Rolle. Die IT-Landschaften sind seither variabler und heterogener geworden und automatisierte Verfahren werden auf allen Plattformen, also auch auf den leistungsfähiger gewordenen PC-Servern, durchgeführt.

Wer etwa seine Kern-Applikationen vom Großrechner auf Linux- oder Windows-Server portiert, der muss selbstverständlich auch seine Batch-Prozesse mitnehmen. Wer seine SAP-Lösung in einer Server-Farm betreibt, muss die SAP-Jobs natürlich auch hier ausführen können. Mit dem zunehmenden Einsatz von Unix/Linux und Windows als Produktionsumgebung in Business-Prozessen steigt zwangsläufig die Bedeutung von automatischen IT-Prozessen auch auf diesen Plattformen. Die Zeiten, als es in PCs allenfalls Backup- und einige System-Jobs gab, sind jedenfalls vorbei.

Job Scheduling wird anspruchsvoller

Die veränderte Rolle der Batch-Verfahren in der IT-Landschaft wirkt sich auch auf die Steuerung und Kontrolle der Batch-Jobs aus. Wenn Tag für Tag Tausende von Batch-Jobs zu starten und zu kontrollieren sind, so lässt sich auch das ohne leistungsfähige Automatisierung nicht bewältigen.

Die dafür zuständigen Job Scheduler müssen heute anspruchsvollere Aufgaben erledigen als ihre Vorläufer in der Mainframe-Welt, denn sie müssen mit den komplexen Bedingungen heterogener Landschaften zurechtkommen. Batch-Jobs laufen häufig über mehrere Plattformen hinweg, wenn zum Beispiel nach der Verarbeitung auf dem Mainframe, Dokumente auf einem PC-Server zu archivieren, eine Unix-Datenbank neu zu indizieren und anschließend Reports zu generieren sind.

Modernes Job Scheduling

Moderne Job Scheduler müssen daher plattformunabhängig arbeiten, so dass ein reibungsloser Austausch von Steuerungs- und Kontrollinformationen zwischen allen Systemen möglich ist. Dies wird beispielsweise durch eine Grid-Architektur sichergestellt. Dabei läuft der Scheduler verteilt auf jedem einzelnen System und tauscht mit den jeweiligen Prozess-Nachbarn nur Systemnachrichten aus. Der Vorteil besteht darin, dass bei einem Ausfall im System nur die betroffenen und unmittelbar davon abhängigen Prozesse angehalten werden müssen, während in einer Master-Agent-Struktur im ungünstigsten Fall alle Prozesse stehen.

Aber auch der Inhalt der Batch-Jobs ist komplizierter geworden und muss von den Job Schedulern entsprechend berücksichtigt werden. Früher reichte es aus, die Prozesse in Abhängigkeit von Zeit und Datum auszuführen: Jede Nacht das Backup, jeden Freitag der Wochenabschluss, am Ersten des Monats der Monatsabschluss, mehr war für die Steuerung von Batch-Jobs meist nicht nötig, weshalb man sich oft mit handgestrickten Lösungen zufrieden geben konnte. Das reine zeitgesteuerte Scheduling ist heute passé, professionelles Job Scheduling muss zusätzlich Event-gesteuert sein.

Event-Steuerung ist unerlässlich

Die jüngste Welle der Automatisierung der IT-Prozesse erfordert eine Job-Steuerung mit wesentlich feinerer Granulierung. Die ausschließliche Orientierung an der vom Betriebssystem übernommenen Systemzeit ist für aktuelle Anforderungen viel zu unflexibel. So kann es beispielsweise bei großem Datenanfall erforderlich werden, einen automatischen Verbuchungsvorgang schon vor der eingestellten Zeit durchzuführen. Natürlich könnte man in diesem Fall auch die Zeitabstände verkürzen und etwa nicht nur am Abend, sondern gleich alle zwei Stunden buchen. Ist aber der Datenanfall geringer, würden man so die Ressourcen ganz unnötig beanspruchen. Die Lösung besteht in der Verknüpfung des Start des Jobs "Verbuchen" mit dem Vorliegen einer bestimmten Datenmenge. Stellt der Job Scheduler fest, dass das Kriterium Datenmenge X erfüllt ist, startet er den Job.

Auf diese Weise lassen sich auch Jobs miteinander zu komplexen Job-Ketten und Job-Netzen verbinden, die dann in wechselseitiger Abhängigkeit ausgeführt werden. Der Job-Stream ist auf diese Weise offen und kann flexibel auf Ereignisse des Gesamtprozesses reagieren.

Ereignisse

Der Anstoß zur Ausführung eines Batch-Jobs kann von ganz unterschiedlichen Ereignissen ausgehen. Uhrzeit und Datum sind dabei lediglich Sonderformen von Ereignissen, so dass das Zeit-gesteuerte Job Scheduling eine Untermenge des Event-gesteuerten darstellt. Relevante Events können sein:

Dabei können einzelne Jobs durch derartige Events nicht nur gestartet, sondern ebenso auch angehalten oder abgebrochen werden.

Webservices

Eine Weiterentwicklung der Event-Steuerung bildet die Verbindung von Job Scheduling und Webservices. So hat ORSYP für seinen Job Scheduler Dollar Universe Solutions eine serviceorientierte Schnittstelle freigegeben, mit der Anwender Webservices für die Steuerung von Batch-Prozessen direkt in Java- oder .NET-Anwendungen einbauen können. Jede entsprechend eingerichtete Software-Komponente ist über dieses Interface in der Lage, Batch-Prozesse zu starten, zu stoppen und auch zu überwachen. Damit wird die Steuerung der Batch-Jobs noch flexibler, weil sie nun weitgehend in die Applikationen integriert sind und trotzdem weiter als separate Prozesse ablaufen können.

Das Revival der Batch-Verarbeitung zur durchgängigen Automatisierung der IT-Prozesse, ist ohne Event-gesteuertes Job Scheduling nicht denkbar. Viele der davon betroffenen Prozesse ließen sich nicht in ein Zeit-Datums-Raster pressen, sondern setzen eine flexible Steuerung voraus. (mha)

Dieser Artikel basiert auf einem Whitepaper von Detlev Schmitz, Leiter Deutschland und Zentraleuropa bei ORSYP, Köln