Spryker Multistore Setup

Die Herausforderungen die mit Multi-Stores einhergehen können vielseitiger Natur sein. Sobald eine neue Sprache, eine neue Währung oder eine neue Domain ins Spiel kommt ist man gut beraten sich im Vorfeld gründlich mit den Features des eingesetzten Shopsystems auseinander zu setzen. Zum Glück hatten die Architekten von Spryker alle möglichen und unmöglichen Challenges im Hinterkopf und haben uns eine Palette an Möglichkeiten mit auf den Weg gegeben.

Was ist ein Multistore Setup?

Die Notwendigkeit für unterschiedliche Business-Requirements eigene Shopinstanz zu entwickeln und zu betreiben, gehören der Vergangenheit an. Spryker erlaubt es uns mit einer Codebasis so viele Shops wie nötig zu betreiben. Unterschiedliche Sprachen und Währungen, Kundenpools und Produkte sind hierbei ebenso konfigurierbar wie verschiedene Business-Logiken. Unter anderem können folgende Themenfelder für das eigene Projekt relevant sein:

• Design und Layout

• Währungen und Preise

• Steuerberechnung

• Sprachen

• Lagerbestände aus unterschiedlichen Quellen

• Versandarten und Versanddienstleister

• Zahlarten und Zahlungsdienstleister

• Bestellverarbeitung

• Formatierung von Zeitangaben, Nummern und Währungen

• usw.

Internationalisierung ist nicht gleich Lokalisierung

Internationalisierung bezeichnet einen Prozess um Software so zu erstellen, dass es Lokalisierungen unterstützen kann. Es ist also der Schritt der als allererstes passieren muss und definiert, wie und wo einzelne Lokalisierungen bereitgestellt werden.

Lokalisierung hingegen adaptiert das "Look-and-Feel" an die Kultur und Sprache des Benutzers. Hierbei geht es unter anderem um übersetzte Texte sowie eine angepasste Bildsprache als auch um ein individuelles Layout. Das Hauptaugenmerk liegt auf der Zusammenstellung der notwendigen Ressourcen und die Einhaltung von Konventionen, die durch die Internationalisierung eingeführt wurden. Kurz gesagt, müssen für jede definierte “Locale” auch die jeweiligen Ressourcen vorhanden sein.

Übersetzungen

Ein zentraler Baustein für die Lokalisierung von Spryker ist das Glossary Modul. Hiermit können Administratoren im Backoffice generelle Übersetzungstexte für neue Sprachmutationen anlegen oder bereits bestehende abändern. Unter Umständen ist die manuelle Pflege des Glossars nicht praktikabel, sobald externe Übersetzungsagenturen oder eine Vielzahl von Administratoren mit diesem Thema betraut werden. Hierfür besteht die Möglichkeit, komplette Übersetzungskataloge in einem CSV-Dateiformat direkt zu importieren.

Mit einer globalen Verkaufsstrategie einhergehen auch die Fragen, welche Länder und Währungen unterstützt werden sollen. Ob das Projekt nun für jedes Land eine eigene Domain und einen eigenen Store braucht oder ob verschiedene Stores geclustert werden (z.B. für den DACH-Raum), ob es dem Kunden selbst überlassen wird eine Sprache zu wählen oder ob man für jede Sprache einen eigenen Store erstellt, bleibt der Fantasie des Projektbetreibers überlassen - hier stehen alle Möglichkeiten offen.

Produkte, Kategorien und CMS-Inhalte

Unterschiedliche Stores erfordern auch unterschiedliche Konfigurationen für Produkte, Kategorien und CMS-Inhalte. Hierbei unterscheiden wir einerseits die Lokalisierungen und andererseits die Verfügbarkeit der jeweiligen Entitäten in den Stores.

Durch eine flexible Fallback-Matrix ist es aber nicht unbedingt notwendig jedes Attribut, jede Option oder auch jedes Bild separat zu lokalisieren. Hierbei ist es praktikabel, sich auf eine Standardlokalisierung (zumeist Englisch) zu einigen und fehlende Werte dann in mit den bereits vorhandenen Texten und Bildern aufzufüllen. Es besteht natürlich auch die Möglichkeit ein Produkt, eine Kategorie oder einen CMS-Inhalt nur in einem bestimmten Store zu aktivieren und diesen somit nur für bestimmte Kunden auszuspielen.

Steuern und Preise

Steuern sind für jeden Onlinehändler ein komplexes Thema. Speziell, wenn die Waren ins europäische Ausland oder auch darüber hinaus verkauft werden wollen. Eine Automatisierung dieser Steuerberechnung ist hierbei unabdingbar, um einerseits etwaigen Fehler zu minimieren und andererseits die Nerven der Produktmanager zu schonen.

Spryker unterscheidet hierfür zwischen Tax-Rates und Tax-Sets. Tax-Rate ist hierbei der Prozentsatz des Preises, den der Endkunde für ein jeweiliges Zielland als Steuer bezahlt. Mit den Tax-Sets werden diese verschiedenen Tax-Rates in Gruppen zusammengefasst, um z.B. eine Differenzierung zwischen Steuern auf Produktpreise und Steuern auf Lieferkosten abzubilden.

Preise und die dazugehörige Preisfindung sind für jedes Projekt unterschiedlich und können daher nur sehr schwer generalisiert abgebildet werden. Um den Entwicklern das Leben bei der Implementierung zu erleichtern, bietet uns Spryker das Konzept der Preis-Typen. Hiermit ist es möglich so viele Produktpreise wie nötig anzulegen und diese dann mit anhand des jeweiligen Use-Cases (Kundengruppe, Zielland, Store etc.) auszuspielen und für Kalkulationen heranzuziehen.

Lagerverwaltung

In einem Multistore-Setup kann die Relation zwischen den einzelnen Warehouses und den zur Verfügung stehenden Stores beliebig konfiguriert werden. So ist es möglich für jeden Store ein eigenes Warehouse anzulegen oder aber das gleiche Warehouse für alle Instanzen zu nutzen.

Durch diese Architektur ist es ohne weiteres möglich zum Beispiel Produkte für die DACH-Stores mit einem anderen Warehouse zu verknüpfen als für den Französischen Store oder den Store für Großbritannien.

Business-Logik

Sollte es für unterschiedliche Stores auch unterschiedliche Business-Anforderungen geben können wir uns das Konzept der sogenannten Code-Buckets zunutze machen. Code-Buckets definieren Abschnitte im Programmcode, der je nach Art des Aufrufs unterschiedlich implementiert und umgesetzt werden kann.

Ein Projekt kann zum Beispiel einen Checkout-Prozess haben, der für verschiedene Zielländer jeweils unterschiedliche Schritte umfasst. So kann der normale Checkout in manchen Szenarios nur drei, in anderen, aber auch vier Schritte umfassen.

Um dieses Szenario abzubilden, wird eine Mutation des Checkout-Prozesses für den Code-Bucket angelegt und dann auch nur für das jeweilige Zielland ausgeführt.

Infrastruktur

"Out of the box” kann Spryker mit jeweils einer Instanz für die relationale Datenbank (SQL), die Searchengine (Elasticsearch) und einer In-Memory-Datenbank (Redis) betrieben werden. Unter Umständen kann dieses Setup aber, je nach Komplexität und Umfang des Projektes an seine Grenzen stoßen. Denken wir zum Beispiel an mehrere hochfrequentierten B2C-Shops oder B2B-Shops komplexen Business-Requirements.

Folgende Optionen stehen uns in Hinblick auf die Infrastruktur zur Verfügung:

Unser Fazit

Mit der modularen Architektur von Spryker wird der Weg zu einem international operierenden E-Commerce-Projekt erleichtert und die Time-to-Market signifikant verringert. Durch die Komplexität, die damit normalerweise einhergeht, ist es ratsam sich im Vorhinein gut zu überlegen, wie die Architektur aussehen soll.

Mit unserem Team aus zertifizierten Spryker Entwicklern begleiten wir unsere Kunden bei dieser Reise und erstellen spezialisierte Lösungen für jedes Businessmodell.