Ein neuer Shop mit alter Produktdatenversorgung – geht da nicht noch was…?

Als in unserem Bereich die Ziele für einen neuen Onlineshop OTTO.de diskutiert wurden, war klar, dass die bestehenden Systeme der Produktdatenversorgung, sozusagen die Lebensader des Shops, „out-of-the-box“ nicht in der Lage sein würden, die nichtfunktionalen Ziele für den Shop mit zu erfüllen. Wieso? Unsere aktuelle Produktdatenversorgung exportiert auf Basis von Datenbanklinks massenhaft Daten, im wesentlichen als Vollexporte (Full Export), zwischen zwei Oracle-Datenbanken. Dabei wird zur Exportlaufzeit jede Menge Geschäftslogik („Business Rules“) ausgeführt, so zum Beispiel die Ermittlung, ob ein Artikel überhaupt exportierfähig für den Onlineshop ist, oder die Bestimmung von Anzeigereihenfolgen der Produkte auf unseren Produktlisten. Und das kostet Zeit.

Dabei ist das existierende Produktdatenproduktions-System ein typisches „Legacy“-System – will heißen:

  • Vom Technologiestack her nicht mehr die allerneueste Mode (Client-Server-Anwendung mit viel Business-Logik in PL/SQL-Routinen)
  • Das existierende System ist nicht nur für OTTO, sondern auch für viele Konzernfirmen im Einsatz (viel Abstimmungsaufwand bei Änderungen)
  • Hochkomplexe, aber stark zur Gesamtwertschöpfung beitragende fachliche Funktionalität, technisch aus verschiedenen Epochen stammend

Als „Systembild“ sieht das ganze dann so aus; der vor allem zu betrachtende Teil sind die Business Rules und der Full Export:

vorher

Da wir trotz oder gerade deshalb nicht mal eben parallel zur Neuentwicklung des Shops auch noch ein neues Produktdatenversorgungssystem aufsetzen wollten und konnten, war die Frage, ob man nicht die bestehende Architektur so modernisieren könnte, dass sie nicht der Flaschenhals für den gesamten Onlineshop wird.

Nach etlichen Vorüberlegungen, Workshops, Architekturreviews usw. kristallisierte sich die Antwort heraus: Ja, es gibt ( mindestens 🙂 ) einen Weg! Dabei heißt das Zauberwort Entflechtung oder, als Entwurfsmuster formuliert: Separation of concerns, d.h. Herauslösung von Teilkomponenten aus dem bisherigen System und deren Neuentwicklung mit State-of-the-Art-Technologien, um die nichtfunktionalen Anforderungen für die Datenversorgung des neuen Shops erfüllen zu können. Und das gerne auch ohne Verlust existierender fachlicher Funktionalität und bei nicht oder nur moderat steigenden Betriebskosten.

Was uns heute vor allem Laufzeit kostet, ist die komplexe Exportlogik. Was liegt demnach näher, als diese bei gleichbleibender Fachlichkeit in eine neue Komponente auszulagern, die wir selber entwickeln und über Standardmechanismen wie z.B. JDBC mit dem existierenden Produktdatenproduktionssystem kommunizieren lassen.

Dazu kommt noch, dass durch unser heutiges System bestimmte Daten laufen, die dort gar nicht verändert werden und in einer entsprechenden idealen Architektur auch viel früher – in Quasi-Echtzeit – im Onlineshop verfügbar sein könnten; was vor allem auch deshalb Sinn macht, weil es sich um hochgradig kundenwirksame Daten wie Lieferauskünfte oder Preise handelt.

Basierend auf diesen Erkenntnissen entstand nun folgende Zielarchitektur:

nachher

Dabei erkennt man die neuen Komponenten „tmpStorage“ und „ProductData“ sowie die magischen Worte „Pull“ und „Rest“. Doch eins nach dem anderen.

tmpStorage: Hier handelt es sich um die neue an das Produktdatenproduktionssystem angedockte Komponente, die via Standard-SQL über JDBC die für den Onlineshop benötigten Rohdaten einliest und in-memory weiterverarbeitet, d.h. die oben zitierten Business Rules anwendet. Das Ergebnis ist, dass im Speicher jetzt die aus dem Produktionssystem benötigten Daten für otto.de vorliegen. Diese Daten müssen nun noch an den Shop exportiert werden. An dieser Stelle war uns im Übrigen auch eine saubere Zerlegung in einzelne Komponenten wichtig, d.h. insbesondere, dass die Exportkomponente des tmpStorage von der Auslese- und Business-Rule-Komponente unabhängig ist. Dies war uns wichtig, weil die im Speicher befindlichen Shopdaten irgendwann auch einmal für andere Abnehmer interessant sein könnten, die aber (mit anzunehmender hoher Wahrscheinlichkeit) über andere Datenformate versorgt werden.

ProductData: Die im tmpStorage gehaltenen Produktdaten für den Shop werden nun per JMS in die ebenfalls neu aufgebaute Komponente ProductData geschrieben. Bei ProductData handelt es sich um eine Komponente, die vom Technologiestack her sehr dem des Shops ähnelt, insbesondere dem für Produktdaten zuständigen ProductSystem. Neben den Daten aus dem Produktdatenproduktionssystem konsolidiert diese Komponente noch Lieferbarkeits- und Preisdaten aus ERP- und Einkaufssystemen und hält diese Gesamtheit der Produktdaten in einer MongoDB. Dabei definiert dieses System auch die Vollständigkeit von Produkten. Das ist wichtig, da nur ein Preis oder nur eine Lieferbarkeit nicht ausreicht, um das als kompletten Produktdatensatz im Shop zu interpretieren.

Der OnlineShop hat nun die Möglichkeit, per REST in beliebiger Frequenz aktualisierte Produktdaten anzufragen („Pull“) oder auch (zum Beispiel nach Aufsetzen neuer Server oder Entwicklungsumgebungen) einen kompletten Datenstand zu bekommen. Durch den geschickten Einsatz von REST-Technologien sind wir damit in der Lage, auch eine komplett leere Instanz in wenigen Minuten mit allen Produkten von otto.de zu füllen.

Wobei letzteres natürlich nur ein Teil der gesamten Übertragungsstrecke ausmacht, was mich abschließend dazu bringt, einmal festzuhalten, was wir insgesamt mit dieser Architektur erreicht haben: Nämlich um 80 bis 90% kürzere Laufzeiten für Full Exporte bei nachgewiesener weiterer Skalierbarkeit für noch mehr Produktdaten sowie eine Versorgung des Shops mit Preis- und Lieferbarkeitsänderungen im Minutenbereich.