Sieben Monate getestet

Von Anfang an waren lange Testphasen eingeplant, um funktionale Fehler zuverlässig auszuschließen. Aber was nutzt die längste Test- und Probephase, wenn die Ergebnisse nicht auf die Wirklichkeit übertragbar sind? Loyalty Partner hat seine Performance-Tests über sieben Monate lang in einer produktionsidentischen Umgebung ausgeführt. Um eine realistische Lastverteilung beobachten zu können, wurde in einem der zentralen Aral-Systeme eine Spezialroutine eingebaut. Sie dupliziert alle Bezahltransaktionen und leitet sie als Loyalty-Transaktion an die Last- und Performance- Umgebung weiter.

Obwohl also die Leistungsfähigkeit nachgewiesen war, entschieden sich die Partner für einen "sanften Start" über zwei Phasen: Im ersten Schritt wurden die Kassensysteme asynchron angeschlossen, so dass die Kunden zunächst keine Rückmeldung über den aktuellen Kontostand erhielten. Protokoll-Overheads ließen sich so vermeiden, und die zur Verfügung stehende Bandbreite der Satellitenverbindung wurde besser ausgenutzt.

In einem zweiten Schritt sollten ursprünglich erst im Herbst dieses Jahres alle Kassensysteme auf die synchrone Anbindung umgestellt werden. Doch das System erwies sich bald schon als ausreichend performant. Deswegen war es möglich, dreieinhalb Monate früher als geplant auf die synchrone Kommunikation zu wechseln.

Aufteilung auf zwei Cluster

Die über das Aral-WAN an Loyalty Partner übertragenen Daten werden in einer Software-Server-Domäne verarbeitet, die sich aus Clustern von je zwei Weblogic-Servern für die Online-Anfragen beziehungsweise zwei Bea-Applikations-Servern für die asynchrone Verarbeitung zusammensetzt. Mit dieser Aufteilung ließen sich die hohen Anforderungen an Verfüg- und Skalierbarkeit realisieren.

Die Online-Instanzen nutzen einen XA-Protokoll-fähigen Multipool für die Anbindung des "Real-Application-Clusters", sprich: der Hochverfügbarkeitslösung für Oracle-Datenbanken. Für die Übergabe an die Batch-Instanzen verwenden sie die "Message-Bridge"-Komponente des Applikations-Servers, um eine "Store-and-Forward"-Entkopplung zu erzielen. Diese lose Anbindung des Batch-Clusters wurde vorher schon genutzt, um Wartungsarbeiten an den Batch-Instanzen vorzunehmen, ohne dabei den Online-Betrieb zu beeinträchtigen.