MySwitzerland.com: Eine Architektur wie ein Schweizer Uhrwerk
MySwitzerland.com beeindruckt mit einer unglaublichen Reichhaltigkeit an Informationen zum Reiseland Schweiz. Die vernetzte Content-Hub-Plattform mit zahlreichen Daten-Import und -Export-Schnittstellen zu Umsystemen funktioniert wie ein Schweizer Uhrwerk. Daniel Rey, Expert Application Architect, hat die Konzeption und Realisierung der technischen Architektur verantwortet. Im Interview erzählt er, welche Überlegungen zur Lösung geführt haben und wie die verschiedenen Systeme zusammenspielen.
Vernetzte Systemlandschaft
MySwitzerland.com funktioniert als Contenthub mit zahlreichen Schnittstellen zu Umsystemen. Welches sind die Herausforderung einer so vernetzten Systemlandschaft?
Daniel Rey: Die zentrale Herausforderung ist die Komplexität, die durch die Vernetzung entsteht. Um diese zu kontrollieren, haben wir das System aufgeteilt: Sitecore kümmert sich als Content-Management-System (CMS) um das Verwalten und Ausspielen von Inhalten, also auch um die Daten-Exporte. Die Daten-Importe übernimmt eine eigens entwickelte Middleware, welche auf Springboot und Apache Camel basiert. Die beiden Systeme kommunizieren via Message Queue miteinander.
Welches sind die spezifischen Aufgaben der Middleware?
Die Middleware hat vier Aufgaben: Sie bezieht in regelmässigen Abständen den neusten Stand aller externen Daten. Im nächsten Schritt überprüft sie diese Daten: Ist die Fehlerrate zu hoch, werden sie verworfen, andernfalls arbeitet sie mit den bereinigten Daten weiter. Diese übersetzt sie in das Domänenmodell von MySwitzerland.com. Im letzten Schritt wird der neuste mit dem zweit neusten Datenstand verglichen. Es lassen sich drei Szenarien unterscheiden: ein Datensatz ist hinzugekommen, weggefallen oder hat sich verändert. Diese Änderungen verpackt die Middleware als Nachrichten und sendet sie an die Message Queue. Von dort werden sie durch Sitecore gelesen und verarbeitet.
Detailliertes Domänenmodell
Was muss ich mir genau unter einem Domänenmodell vorstellen?
Mit Software bauen wir ein digitales Modell von Elementen und Prozessen aus der echten Welt. Wie wir das aus der Physik kennen, ist ein Modell eine hilfreiche Vereinfachung der Realität. Ein Domänenmodell repräsentiert eine abgegrenzte Domäne, in unserem Fall touristische Informationen zur Schweiz und setzt diese in einer gemeinsamen Sprache um. Diese ist bis ins Detail spezifiziert, so dass sie für die Kommunikation zwischen Maschinen verwendet werden kann. Die verwendeten Begrifflichkeiten kommen jeweils vom Fach, in unserem Fall von den Schweiz-Expertinnen und -Experten von Schweiz Tourismus.
Wieso müsst ihr denn die importierten Daten überhaupt in das Domänenmodell von mySwitzerland.com übersetzen? Ihr verwendet doch nur Quellen mit touristischen Informationen.
In der Tat sind die Domänenmodelle unserer Quellsysteme oft ähnlich zu dem von MySwitzerland.com, aber leider nicht identisch. Eine Quelle bildet Campingplätze ab, eine andere Hotels und eine Dritte Gruppenunterkünfte. In der Middleware übersetzen wir alle drei zu Unterkünften. Sitecore erhält also unabhängig von der Quelle immer eine Unterkunft und kann sich darauf verlassen, dass beispielsweise für jede Unterkunft Namen und Beschreibung mehrsprachig abgelegt sind und mindestens ein illustratives Bild vorhanden ist. Den Namen der Unterkunft beziehen wir bei der einen Quelle aus dem Element Title des entsprechenden XML und müssen die Sprache über das Attribut language zuweisen, während wir bei einer anderen Quelle pro Sprache ein JSON beziehen, welches ein Attribut Name enthält. Die einzelnen Übersetzungen sind also nicht kompliziert, die entsprechende Logik muss aber gut strukturiert sein, damit die Summe aller Übersetzungen keine unnötige Komplexität verursacht.
Durchgängiger Prozess
Und wie sprechen nun die Middleware und das Content-Management-System konkret miteinander?
Dafür verwenden wir die eingangs erwähnte Message Queue, die auf RabbitMQ basiert. Die Middleware sendet Nachrichten mit Änderungen an RabbitMQ, z.B. Hotel Sonnenhof "erstellen", oder Anzahl Michelin-Sterne des Restaurants Krone auf 2 "ändern". Diese Nachrichten werden in der Queue abgespeichert und können nun von Sitecore bezogen werden. Durch diese Entkopplung sind Middleware und Sitecore nicht voneinander abhängig. Die Middleware kann Beispiel eine Vielzahl an Änderungen in kurzer Zeit auf der Message Queue bereitstellen, welche dann von Sitecore in einer Frequenz bezogen werden können, die den Betrieb der Webseite nicht negativ beeinflusst.
Wer sich vertieft mit dem Thema befassen möchte: Unsere Architektur basiert auf Event-Carried State Transfer. Dieses Architektur-Pattern wird von Martin Fowler in seiner Präsentation, The Many Meanings of Event Driven, gut beschrieben.
Das tönt ja nach einem sehr komplizierten Prozess. Wie lange dauert es denn bis ein Eintrag bei Sitecore aktualisiert ist?
Dies hängt vom Inhaltsobjekt und von der Quelle ab. Veranstaltungen können wir beispielsweise auch aus einer Message Queue beziehen und müssen diese nur noch in unser Domänenmodell übersetzen. Dadurch ist eine Änderung innert Minuten von der Quelle zu Sitecore repliziert. Die restlichen Quellen fragen wir einmal pro Stunde ab, danach ist die Änderung innert Minuten in Sitecore.
Auf Umwegen zum Ziel
Welches ist dein persönliches Erfolgserlebnis in diesem Projekt?
Wir sind initial mit der Hypothese ins Projekt gestartet, dass wir die externen Quellen auf der Middleware zusammenfassen und für Sitecore via API zur Verfügung stellen. Es hat sich aber schnell gezeigt, dass wir die Inhalte auch auf Sitecore speichern müssen, damit sie von den Expertinnen und Experten bei Schweiz Tourismus angereichert werden können. Die Daten nur in der Middleware zu persistieren, war keine Option und sie jeweils auf Sitecore komplett zu ersetzen auch nicht. Es galt also einen Weg zu finden, auf Sitecore die Daten zu persistieren und nur einzelne Felder zu aktualisieren.
Wir merkten, dass die von uns ursprünglich angedachte Architektur dieses Problem nicht auf ideale Art und Weise löst und überarbeiteten diese nach Projektstart nochmals. Glücklicherweise hat uns Schweiz Tourismus die notwendigen Freiheiten gelassen und das entsprechende Vertrauen entgegen gebracht. Rückblickend weiss ich, dass wir den richtigen Weg gewählt haben und bin stolz darauf, dass wir den Mut hatten, unseren intialen Plan zu verwerfen.
Wir sind da für Sie!
Termin buchenSie möchten Ihr nächstes Projekt mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus: Melanie Klühe, Stefanie Berger, Stephan Handschin und Philippe Surber (im Uhrzeigersinn).
Kontakt für Ihre digitale Lösung mit Unic
Termin buchenSie möchten Ihre digitalen Aufgaben mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus: Jörg Nölke und Gerrit Taaks (von links nach rechts).
