Die "Payback"-Karte rangiert nach der Krankenversicherungs- und der EC-Karte in deutschen Geldbörsen an dritter Stelle. Betreiber des Kundenbindungsprogramms, an dem unter anderen DM-Drogeriemarkt, Galeria Kaufhof und OBI beteiligt sind, ist das Münchner Unternehmen Loyalty Partner. Kürzlich konnte es auch die Aral-Tankstellen für das Programm gewinnen.
Best Practice
• Angemessener Aufwand für Tuning und Performance-Tests macht sich bezahlt.
• Um ein Restrisiko auszuschließen, empfahl sich die sanfte Einführung in zwei Phasen.
• Die Aufteilung der Software-Domäne in zwei Cluster (für Online- und Batch-Betrieb) erhöht Verfügbarkeit- und Skalierbarkeit.
Projektsteckbrief
Die IT hinter der Karte
• Das IT-System für Payback wird von Loyalty Partner entwickelt und betrieben.
• Zu den Kernplattformen gehören Oracle 9/10, Bea Weblogic 8.1, Siebel CRM 7.7, Core Media CMS 2005 und Webmethods 6.5.
• Für das Projekt-Management wird "Planview" eingesetzt; als Reporting-Tool kommt derzeit "Power-Analyzer" zum Einsatz.
• Seit ihrer Entstehung im Jahr 2000 hat die IT-Umgebung einige architektonische Überarbeitungen erfahren.
• So wurden 2003 mit der Einführung des CRM-Systems von Siebel die Kunden- und Kontensysteme getrennt.
• Gleichzeitig wurde der auf Webmethods basierende B-to-B-Online-Shop zur EAI-Plattform ausgebaut, die asynchrones Business Process Management erlaubt.
• Für den Betrieb der Server zeichnet HP verantwortlich; dort werden auch einige separate Umgebungen - beispielsweise für Referenz und Entwicklung - betrieben.
• Loyalty Partner hingegen betreibt alle darauf aufbauenden Applikationsplattformen.
• Eine Qualitätssicherungs-Abteilung sorgt dafür, dass die Systemfunktionen den Qualitätskriterien entsprechen.
• Inzwischen sind mehr als die Hälfte der Testfälle automatisiert. Auf diese Weise werden Regressionstests effizienter.
Damit der Endkunde seinen neuen Punktestand direkt auf dem Kassenzettel nachlesen kann, war von Seiten des Tankstellenunternehmens die Echtzeitanbindung der Kassensysteme an das Bonusprogramm ein absolutes Muss. Diese Kopplung bedeutete aber zusätzliche Anforderungen an die Performance des Systems. Gefordert waren
• "weiche Echtzeit" mit schneller Batch-Verarbeitung,
• Sieben-mal-24-Stunden-Verfügbarkeit,
• kein Single Point of Failure,
• maximaler Toleranzwert (Verlängerung des Bezahlvorgangs an der Kasse gegenüber dem bisherigen Mittelwert) von 4,5 Sekunden,
• daraus folgend 500 Millisekunden als maximale Antwortzeit für das Firewall-in/Firewall-out am Loyalty-System,
• und das garantiert bei 150 gleichzeitigen Transaktionen über einen Zeitraum von 30 Minuten,
• wobei alle bestehenden Prozesse unbeeinträchtigt bleiben und alle Transaktionen sicher ausgeführt werden müssen.
Die Aral-Tankstellen in Deutschland sind zum größten Teil über ein Satellitennetz mit dem Aral-WAN verbunden. Loyalty Partner hat sein System über dieses WAN mit der IT-Struktur der Tankstellenkette verbunden. Für die Echtzeit-Anbindung des Payback-Programms nutzt das Unternehmen Bea-Weblogic-8.1-Server. Diese sind wiederum mit Weblogic-8.1-Servern im Aral-WAN verbunden, die von der Comarch Ltd. in Polen betrieben werden.
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.
Aufteilung auf zwei Cluster
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.
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", 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 den Online-Betrieb zu beeinträchtigen.
Tuning der Instanzen
Bei den Lasttests hatte sich gezeigt, dass hinsichtlich der Online-Instanzen die Bea-eigene Java Virtual Machine ("JRockit") für kurze Antwortzeiten - typischerweise 10 bis 40 Millisekunden - getunt werden musste. Die "Concurrent Garbage Collection" funktioniert dergestalt, dass alle nicht mehr referenzierten Java-Objekte während der Anwendungslaufzeit entfernt werden.
Die Batch-Instanzen nutzen einen parallelen Garbage-Collection-Algorithmus. Um auf allen CPUs aufzuräumen, wird die Bearbeitung angehalten. Das Garbage-Collection-Verhalten ließ sich hier mit Hilfe der "JRockit-Runtime-Analyse" verbessern. Diese von Bea bereitgestellte Funktion lässt dass das Antwortverhalten auch unter Volllast nahezu unbeeinflusst.
Die Anbindung der externen Systeme wie Webmethods erfolgt über Java Message Service (JMS), eine Programmierschnittstelle für den asynchronen Datenaustausch. Die Verbindung zur Siebel-Applikation geschieht gemäß J2EE-Standard mit einem JCA-Adapter.
Seit Mitte des laufenden Jahres ist es so weit: Der aktuelle Payback-Punktestand wird auf dem Kassenbeleg des Aral-Kunden direkt angezeigt. Die Teilnahme von Aral hat das Bonusprogramm einen weiteren Schritt nach vorn gebracht. Seither haben sich bereits mehr als eine halbe Million Neukunden angemeldet. (qua)