1. Einführung

In einer zunehmend digitalen und vernetzten Welt ist Flexibilität entscheidend. Unternehmen stehen vor der Aufgabe, nahtlose Einkaufserlebnisse zu schaffen, die den sich ständig ändernden Bedürfnissen der Verbraucher gerecht werden. Dabei ist die Möglichkeit, verschiedene Technologien und Systeme miteinander zu kombinieren, von entscheidender Bedeutung. FirstSpirit Connect for Commerce wurde entwickelt, um genau diese Anforderungen zu erfüllen. Mit einer starken Betonung auf Composable Commerce bietet unsere Lösung eine flexible Architektur, die es Unternehmen ermöglicht, maßgeschneiderte E-Commerce-Lösungen zusammenzustellen. Composable Commerce ermöglicht es Unternehmen, die verschiedenen Bestandteile ihres E-Commerce-Ökosystems - von Content Management über Shop-Systeme bis hin zu Zahlungs- und Versanddiensten - nahtlos miteinander zu integrieren und zu kombinieren.

Unsere Lösung bietet Unterstützung für Content-driven Commerce und Shop-driven Commerce sowie deren Kombinationen. Durch die Verwendung von Microservices, API-driven, Cloud-nativ und Headless-Architektur (MACH) ermöglichen wir es Unternehmen, agil zu bleiben und schnell auf sich ändernde Anforderungen zu reagieren. Unsere Plattform ermöglicht eine freie Auswahl an Anbietern und Technologien und kann einfach an verschiedene Shop-Systeme angebunden werden.

Orchestrieren Sie mühelos Inhalte aus verschiedenen Quellen, um ansprechende Shopping-Erlebnisse zu schaffen. Verbessern Sie Ihre E-Commerce-Strategie mit Leichtigkeit und Raffinesse durch FirstSpirit Connect for Commerce.

Diese Dokumentation bietet eine detaillierte Anleitung zur Nutzung unserer Lösung in Composable Commerce-Szenarien. Sie führt durch die Integration, Konfiguration und Verwendung unserer Plattform und hilft dabei, das volle Potenzial von Connect for Commerce auszuschöpfen, um alle E-Commerce-Ziele zu erreichen.

1.1. Herausforderungen

1.1.1. Aktuelle Herausforderungen

Im Bereich des E-Commerce in Unternehmen gibt es viele Herausforderungen.

  • Content-Qualität und Relevanz: Unternehmen müssen sicherstellen, dass der bereitgestellte Inhalt von hoher Qualität ist und den Bedürfnissen und Interessen ihrer Zielgruppe entspricht. Es kann schwierig sein, relevante und ansprechende Inhalte zu erstellen und zu pflegen, insbesondere wenn es um eine Vielzahl von Produkten und Zielgruppen geht.

  • Content-Konsistenz über verschiedene Kanäle: Mit dem Aufkommen verschiedener Vertriebskanäle wie Website, Social Media, mobile Apps und Marktplätze ist es wichtig, konsistenten Inhalt über alle diese Kanäle hinweg zu liefern. Die Anpassung und Pflege von Inhalten für jeden Kanal kann jedoch eine Herausforderung darstellen.

  • Personalisierung der Inhalte: Die Kundschaft erwartet zunehmend personalisierte Einkaufserlebnisse. Unternehmen müssen in der Lage sein, Inhalte basierend auf dem Verhalten, den Vorlieben und dem Standort ihrer Kundschaft anzupassen und anzubieten. Dies erfordert eine effektive Nutzung von Daten und Technologien zur Personalisierung.

  • Skalierbarkeit und Effizienz bei der Content-Erstellung: Mit einem wachsenden Produktkatalog und einer Vielzahl von Zielgruppen müssen Unternehmen sicherstellen, dass sie Inhalte effizient und skalierbar erstellen können, ohne die Qualität zu beeinträchtigen. Manuelle Prozesse können ineffizient sein und zu Verzögerungen führen.

  • Content-Management und -Auslieferung: Die effektive Verwaltung und Organisation von Inhalten ist entscheidend, um eine nahtlose Nutzungserfahrung zu gewährleisten. Unternehmen benötigen leistungsfähige Content-Management-Systeme, die es ihnen ermöglichen, Inhalte einfach zu erstellen, zu bearbeiten, zu verwalten und zu verteilen.

  • Compliance und rechtliche Anforderungen: Unternehmen müssen sicherstellen, dass ihre Inhalte den geltenden rechtlichen Anforderungen entsprechen, insbesondere in Bezug auf Datenschutz, Urheberrecht und Produktbeschreibungen. Die Einhaltung dieser Vorschriften kann komplex sein und erfordert eine sorgfältige Überwachung und Aktualisierung der Inhalte.

1.1.2. Lösungsansätze durch Connect for Commerce

FirstSpirit Connect for Commerce ermöglicht die Verknüpfung des Crownpeak CMS FirstSpirit mit einem beliebigen E-Commerce-Shop-System. Sie schafft dadurch ein leistungsstarkes Gesamtsystem, das die funktionalen Vorteile dieser Systeme kombiniert und die Bereitstellung moderner und personalisierter Inhalte ermöglicht.

Die Redaktion erhält einen übersichtlichen Zugriff auf den Produktkatalog des Shop-Systems und kann diesen mit redaktionellen Inhalten, wie beispielsweise Interactive-Video, verknüpfen. Die Pflege der Inhalte erfolgt dabei mithilfe einer intuitiv zu bedienenden und von FirstSpirit bereitgestellten WYSIWYG-Oberfläche, dem FirstSpirit ContentCreator. Kenntnisse über das angebundene E-Commerce-Shop-System sind dafür nicht erforderlich, da der ContentCreator alle benötigten Funktionalitäten zur Verfügung stellt. Die Einbindung zusätzlicher Konnektoren kann den Funktionsumfang erweitern, DQM Connect ermöglicht zum Beispiel das Einhalten von branchenspezifischen Compliance Regeln und Erfüllung von Anforderungen an Barrierefreiheit.

Connect for Commerce liefert im Standardumfang Funktionalitäten für die Umsetzung komplexer Anwendungsfälle; Beispielkomponenten und zahlreiche out-of-the-box Lösungen helfen dabei maßgeschneiderte Lösungen zu realisieren und ein funktionales MVP innerhalb kurzer Zeit zu erreichen.

1.1.3. Vorteile von Connect for Commerce

  • Unsere Lösung unterstützt sowohl Content-driven Commerce als auch Shop-driven Commerce sowie deren nahtlose Integration für maximale Flexibilität und Anpassungsfähigkeit.

  • Durch die Nutzung von Microservices und einer API-driven, Cloud-nativen und Headless-Architektur bieten wir eine zukunftssichere und skalierbare Plattform, die den modernen Anforderungen des E-Commerce gerecht wird.

  • Unternehmen profitieren von einer freien Auswahl an Anbietern und Technologien, um ihre individuellen Bedürfnisse und Präferenzen zu erfüllen.

  • Connect for Commerce ermöglicht eine einfache Integration mit beliebigen Shop-Systemen, um reibungslose Redaktionsprozesse zu gewährleisten und die Effizienz zu steigern.

  • In FirstSpirit gepflegte Inhalte erweitern die Produkt- und Kategorie-Informationen, um ein überzeugendes Shopping-Erlebnis und eine fundierte Entscheidungsfindung zu unterstützen.

  • Shop-Elemente und redaktionelle Inhalte werden gleichzeitig in der Vorschau von FirstSpirit angezeigt. Dies erlaubt der Redaktion die Konsistenz und Qualität der Inhalte zu optimieren.

  • Inhalte können problemlos an verschiedene Touchpoints ausgespielt werden, um eine breite Reichweite und einen maximalen Einfluss zu erzielen.

  • Die Referenz-Implementierungen auf GitHub sind eine wertvolle Ressource, um die Implementierung und Nutzung unserer Lösung zu beschleunigen und zu optimieren.

  • Unsere Plattform bietet Enterprise CMS-Funktionalitäten, darunter hervorragende Performance und Verfügbarkeit, wiederverwendbare Elemente durch Vorlagen, die Einrichtung anspruchsvoller Workflows, eine performante Medienverwaltung und eine intuitive Pflege von Inhalten durch eine benutzerfreundliche Drag&Drop-WYSIWYG-Oberfläche ohne die Notwendigkeit von Code.

  • Darüber hinaus integrieren wir Generative-AI-Funktionen, die dabei helfen, automatisch relevante und ansprechende Inhalte zu generieren und die Effizienz der Content-Strategie zu steigern.

1.2. Commerce-Konzepte

In der E-Commerce Welt existieren verschiedene Konzepte:

  • E-Commerce: Elektronischer Handel bezieht sich auf den Kauf und Verkauf von Waren und Dienstleistungen über das Internet. Dies umfasst B2C (Business-to-Consumer), B2B (Business-to-Business) und C2C (Consumer-to-Consumer) Transaktionen.

  • M-Commerce: Mobile Commerce bezieht sich auf den Kauf und Verkauf von Waren und Dienstleistungen über mobile Geräte wie Smartphones und Tablets. Es umfasst mobile optimierte Websites, Apps und mobile Zahlungssysteme.

  • Omnichannel-Commerce: Omnichannel-Commerce bezeichnet die nahtlose Integration verschiedener Vertriebskanäle wie physische Geschäfte, Online-Shops, mobile Apps und soziale Medien, um ein konsistentes Einkaufserlebnis über alle Kanäle hinweg zu bieten.

  • Social Commerce: Social Commerce nutzt soziale Medienplattformen wie Facebook, Instagram und Pinterest, um den Kauf und Verkauf von Produkten und Dienstleistungen zu erleichtern. Es ermöglicht Unternehmen direkt mit ihrer Kundschaft zu interagieren und Produkte zu bewerben.

  • Content-driven Commerce: Content-driven Commerce konzentriert sich darauf, hochwertige und relevante Inhalte bereitzustellen, um das Kaufverhalten der Kundschaft zu beeinflussen. Dies kann durch informative Artikel, Produktbewertungen, Videos und andere Inhalte geschehen.

  • Shop-driven Commerce: Shop-driven Commerce legt den Schwerpunkt auf den Verkaufsprozess und die Optimierung des Einkaufserlebnisses im Online-Shop. Dies umfasst Aspekte wie Website-Design, Produktdarstellung, Navigation und Checkout-Prozesse.

  • Composable Commerce: Composable Commerce ist ein modularer Ansatz, bei dem Unternehmen verschiedene Technologien und Services miteinander kombinieren, um eine maßgeschneiderte E-Commerce-Lösung zu erstellen. Dies ermöglicht eine hohe Flexibilität und Anpassungsfähigkeit.

  • Headless Commerce: Headless Commerce trennt die Präsentationsschicht (Frontend) von der Backend-Logik, was es Unternehmen ermöglicht, flexible Auslieferung der Inhalte zu schaffen, ohne die Integrität des Backend-Systems zu beeinträchtigen.

  • Direct-to-Consumer (DTC) Commerce: Direct-to-Consumer Commerce bezieht sich auf Unternehmen, die ihre Produkte direkt an Endverbrauchende verkaufen, ohne den Zwischen- oder Einzelhandel einzubeziehen. Dies ermöglicht es Unternehmen, direkten Kontakt zu ihrer Kundschaft zu pflegen und ihre Markenbotschaft effektiv zu kommunizieren.

  • Subscription Commerce: Subscription Commerce ermöglicht es Unternehmen, regelmäßig wiederkehrende Zahlungen für Dienstleistungen, digitale Inhalte oder Produkte zu verlangen.

Connect for Commerce verfolgt grundsätzlich einen Headless Ansatz und stellt alle Inhalte via CaaS zur Verfügung. Das ermöglicht es alle Commerce Konzepte zu unterstützen. Im Laufe dieses Dokuments wird insbesondere auf die folgenden Konzepte eingegangen.

1.2.1. Headless Commerce

Im Zentrum des Headless Commerce steht eine API getriebene Shop-Architektur. Dies bedeutet, dass die Auslieferungsschicht, in diesem Fall die Storefront, vom Shop-Backend getrennt ist. In einer solchen Architektur ist die Storefront oft eine Progressive Web App (PWA), Single Page Application (SPA) oder Kombinationen dieser. Dabei werden Inhalte Client-seitig abgefragt und gerendert. Auf diese Weise werden für jeden Seitenaufruf weniger Daten übertragen, da das Grundgerüst der Webseite nur einmal übertragen werden muss. Ein weiterer Vorteil ist das nicht-gleichzeitige Abrufen unterschiedlicher Daten, wodurch der relevante Inhalt schneller verfügbar ist.

1.2.2. Static Commerce

Grundlage für das Konzept des Static Commerce ist ein Shop-System, welches nach dem Prinzip des Server Side Scripting (SSS) arbeitet. Beispiele für SSS-Technologien sind unter anderem PHP, Java Server Pages (JSP) und ASP/ASP.NET. Diese Systeme erzeugen das benötigte HTML dynamisch für jede Anfrage und bei einem Seitenaufruf, wodurch sie sich von Headless-Ansätzen unterscheiden. Da die Inhalte Server-seitig zusammengestellt werden, können sie besser von leistungsschwachen Endgeräten und Crawlern, etwa im Rahmen der Suchmaschinenoptimierung (SEO), verarbeitet werden.

1.2.3. Shop-driven Commerce

Katalogbasierte Onlineshops konzentrieren sich hauptsächlich darauf, Produkte oder Dienstleistungen online zu präsentieren und zu verkaufen. In der Rangfolge steht das Shop-System an erster Stelle und gibt die Struktur des Onlineshops vor. Connect for Commerce dient bei diesem Ansatz ausschließlich dazu, bestehende Seiten mit Inhalten anzureichern und zusätzliche Seiten bereitzustellen.

1.2.4. Content-driven Commerce

Im Content-driven Commerce werden hochwertige und relevante Inhalte als treibende Kraft für den Verkaufsprozess instrumentalisiert, um so den Verkauf von Produkten über digitale Kanäle zu fördern. Content-driven Commerce erfordert eine zielführende Integration der Inhalte in den Shopping-Prozess, um den Kunden ein möglichst hochwertiges Shopping-Erlebnis zu bieten. Connect for Commerce übernimmt die führende Rolle des Gesamtsystems und gibt Struktur und Inhalte des Online-Shops vor.

Connect for Commerce unterstützt sowohl Shop-driven als auch Content-driven Commerce und bietet die Möglichkeit das Beste aus beiden Welten zu vereinen.

2. Architektur

2.1. Low-Level-Architektur

Die Abbildung Connect for Commerce Low-Level-Architektur illustriert das Zusammenspiel der einzelnen Komponenten von Connect for Commerce in einem Headless Commerce-Szenario. Diese werden im nachfolgendem Kapitel näher erläutert.

Connect for Commerce Low-Level-Architekturdiagramm
Abbildung 1. Connect for Commerce Low-Level-Architektur

Die Grafik zeigt Connect for Commerce in einem Headless Commerce Szenario. Architekturelle Unterschiede zwischen Headless und Static Commerce Szenarios sind im Kapitel Zielarchitektur und Szenarien dargestellt.

2.2. Allgemeine Komponenten

Nachfolgende Komponenten sind zusätzlich zu FirstSpirit wichtige Bestandteile von Connect for Commerce. Sie sind standardmäßig im Connect for Commerce Cloud-Angebot enthalten und essenziell für die Verwendung der Connect for Commerce Frontend API.

2.2.1. CaaS

Content as a Service (CaaS) entspricht einem zentralen Repository. In diesem werden die FirstSpirit-Inhalte persistiert und über eine Schnittstelle im JSON-Format bereitgestellt. Mit CaaS Connect werden Inhaltsänderungen beim Speichern automatisch mit dem CaaS in einem vordefinierten Format synchronisiert. Mediendateien werden automatisch in einem Amazon S3-Bucket gespeichert.

2.2.2. Navigation Service

Der Navigation Service stellt Routing- und Strukturdaten bereit, um die Navigation in dynamischen (Web-) Anwendungen zu erleichtern. Die Struktur wird im FirstSpirit-Projekt gepflegt und die Routen werden automatisch von FirstSpirit erzeugt. Das Navigation Service-Modul synchronisiert alle Änderungen automatisch.

2.3. Spezifische Komponenten

Für die Verwendung von Connect for Commerce sind weitere Komponenten notwendig: Das Connect for Commerce FirstSpirit-Modul und unabhängige Microservices, die den Austausch und die Aktualisierung verschiedener Teile des Ökosystems ermöglichen, ohne andere Teile zu beeinträchtigen. Der Einsatz von Microservices ist abhängig von Szenario und Anwendungsfall.

2.3.1. Connect for Commerce-Modul

Das Connect for Commerce-Modul fragt die Produkt-, Kategorie- und Inhaltsdaten bei der Bridge an und zeigt sie im entsprechenden Report des ContentCreator an. Über den Report können diese mithilfe des zugehörigen Data Access Plugins bei der Erstellung von Inhalten referenziert werden. Zusätzlich ermöglicht das Connect for Commerce-Modul die Kommunikation zwischen ContentCreator und FirstSpirit-Server, um zum Beispiel Shop-driven Pages zu erzeugen.

2.3.2. Bridge

Die Bridge ruft die verfügbaren Produkt-, Kategorie- und Inhaltsdaten aus dem Shop-System ab und stellt sie dem Connect for Commerce-Modul per API zur Verfügung. Es kann sich dabei um einen separaten (Micro-) Service oder um einen Teil des Shop-Backends selbst handeln.

2.3.3. Frontend API-Backend

Das Frontend API-Backend verbindet die Client-Seite (Storefront) mit dem CaaS und dem Navigation Service, um die redaktionellen Inhalte und die von FirstSpirit verwaltete Seitenstruktur abzurufen. Zum Abrufen und Transformieren von Daten für die Storefront wird das Frontend API-Server npm-Modul verwendet, welches Teil der Frontend API ist.

2.3.4. Shop Backend

Das Shop-Backend ist der zentrale Teil des Shop-Systems und stellt unter anderem eine API zum Abfragen der Produkte und Kategorien bereit.

2.3.5. Storefront

Die Storefront ist der Client-seitige Teil des Shop-Systems und die visuelle Repräsentation des Shops sowohl in der Vorschau- als auch der Freigabe-Ansicht.

Die Storefront nutzt das Frontend API-Client npm-Modul welches ebenfalls Bestandteil der Frontend API ist, um Vorschauinhalte zu bearbeiten und um Daten aus dem Frontend API-Backend abzufragen.

Shop-Backend und Storefront sind Drittanbieter-Applikationen. Sie sind nicht Teil der Auslieferung von FirstSpirit Connect for Commerce.

3. Datenübertragung

3.1. Frontend API

Die Frontend API ermöglicht eine einfache Integration von Connect for Commerce-Funktionalitäten in E-Commerce-Projekten. Sie erweitert Connect for Commerce um die Funktionalität, Produkt-, Kategorie-, und Inhaltsseiten als Shop-driven Pages zu erzeugen und Daten aus dem CaaS abzurufen. Zudem erlaubt sie die Nutzung der Vorschaufunktion und die Bearbeitung von Inhalten im ContentCreator.

Die Frontend API besteht aus zwei npm-Modulen:

Weitere Informationen und Beispiele können der Frontend API-Dokumentation entnommen werden.

3.1.1. Frontend API-Server

Das Frontend API-Server npm-Modul ist Teil der Frontend API, welcher die Inhalts- und Strukturdaten des FirstSpirit-Projekts aus dem CaaS und dem Navigation Service abruft, um diese in der Auslieferungsschicht anzuzeigen. Der Frontend API-Server erkennt anhand der Anfragen ob Vorschau- oder Freigabeinhalte abgefragt werden.

Das npm-Modul muss in einen Backend-Service integriert werden.

3.1.2. Frontend API-Client

Das Frontend API-Client npm-Modul ist das Gegenstück zum Frontend API-Server und ebenfalls Teil der Frontend API. Der Frontend API-Client übernimmt zwei Aufgaben:

  • Einbindung des Omnichannel Managers, um die Bearbeitung der Vorschau-Inhalte im ContentCreator zu ermöglichen

  • Abfrage redaktioneller und struktureller Daten mithilfe des Frontend API-Backends zur Visualisierung im Frontend

3.1.3. Frontend API-Backend

Das Frontend API-Backend verbindet die Storefront mit dem CaaS und dem Navigation Service, um sowohl redaktionelle Inhalte als auch die von FirstSpirit verwaltete Seitenstruktur abzurufen. Es nutzt das Frontend API-Server npm-Modul zum Abrufen, Umwandeln und Anreichern von Daten für eine optimierte Verwendung im Frontend. Außerdem verbirgt es die CaaS API-Schlüssel vor dem Client und validiert die Quelle der Anfrage, um den Bearbeitungsmodus in der Vorschau zu aktivieren.

Es kann ein eigener Dienst für die Abfrage von Daten aus dem CaaS und Navigation Service implementiert werden, oder die auf GitHub verfügbare Referenz-Implementierung verwendet werden.

3.2. Datenfluss

Innerhalb des mit Connect for Commerce geschaffenen Gesamtsystems verlagert sich die Erstellung und Pflege redaktioneller Inhalte zu FirstSpirit. Durch die Bereitstellung von Shop-Inhalten ist das Referenzieren dieser innerhalb des gepflegten Inhalts möglich.

Mit der Freigabe der redaktionellen Inhalte erfolgt deren automatische Übertragung in den CaaS. Dieser stellt die Inhalte anschließend der Storefront des angebundenen Shop-Systems zur Verfügung.

Die Storefront fragt die Informationen ab und verknüpft sie mit denen des Shop-Systems, um sie in einer kombinierten Ansicht auszuliefern. Die Storefront übernimmt die Darstellung aller Inhalte sowohl in der Vorschau, als auch in der Endauslieferung. Connect for Commerce übernimmt das Mapping der Shop-Seite auf die FirstSpirit-Objekte.

Diagramm in welchem der Datenfluss des mit Connect for Commerce geschaffenen Gesamtsystems beschrieben wird
Abbildung 2. Vereinfachter Datenfluss zwischen den Hauptsystemen

Bei der Implementierung der Storefront muss zwischen Headless Commerce- und Static Commerce-Szenarien unterschieden werden:

  • In Headless Commerce-Szenarios erfolgt die Einbindung durch Installation des Frontend API-Clients als npm-Modul in der Storefront. So können die Daten im Client abgefragt und im Browser dargestellt werden.

  • Für Static Commerce-Szenarios, in denen die Storefront Server Side Scripting (SSS) verwendet, steht der Frontend API-Client als Skript bereit, welches im HTML eingebunden wird. Die Abfrage redaktioneller und struktureller Daten auf dem Server muss direkt am Frontend API-Backend erfolgen. Das Skript ermöglicht in diesem Fall lediglich die Integration des Omnichannel Managers und somit die Bearbeitung der Inhalte im Content Creator.

Obwohl PWAs und SPAs mit Server Side Rendering (SSR) das HTML auf dem Server rendern, fallen diese unter die Kategorie Headless Commerce.

Nach der FirstSpirit-seitigen Erstellung oder Pflege redaktioneller Inhalte findet mit eine automatische Übertragung in den CaaS statt. Dieser persistiert die Inhalte und stellt sie über eine REST-Schnittstelle im JSON-Format bereit. Die Storefront nimmt diese Informationen entgegen und verknüpft sie mit den Inhalten des Shop-Systems, um sie in einer kombinierten Ansicht auszuliefern.

Das Abfragen von CaaS-Inhalten aus der Storefront kann auf Basis einer Eigenimplementierung erfolgen. Diese Lösung muss auf das angebundene Shop-System abgestimmt sein und ist somit immer individuell.

Unabhängig von der gewünschten Übertragungsform sind jedoch grundsätzlich die folgenden Punkte zu berücksichtigen:

  • Authentifizierung

  • Abfrage der Daten

  • Daten-Transformation

  • Ausgabe der Daten

  • Caching

Authentifizierung

Die Abfrage von Daten aus dem CaaS setzt einen API-Key voraus, welcher vor unerlaubtem Zugriff zu schützen ist. Er besitzt den Stellenwert eines Passworts und ist daher entsprechend zu behandeln.

Abfrage der Daten

Bei der Abfrage der redaktionellen Inhalte aus dem CaaS müssen die richtigen Daten abgefragt werden. Deshalb müssen sich die in FirstSpirit verwendeten Produkt- und Kategorie-Informationen stets den realen Daten im Shop-System zuordnen lassen. Dafür ist eine Zuordnung erforderlich, das auf eindeutigen IDs basiert und bereits durch die Bridge vorgegeben sein muss. Die IDs werden in den Formulardaten eines FirstSpirit-Elements gespeichert und in den CaaS übertragen. Auf Basis der IDs ist damit sowohl eine Abfrage der im CaaS gespeicherten FirstSpirit-Daten als auch ihre Verknüpfung mit den Shop-Daten möglich. Weitere Informationen werden im Detail in den Unterkapiteln Mapping der Identifier und Frontend API-Backend beschrieben.

Informationen über die Struktur werden im Navigation Service gespeichert. Für die Implementierung einer Navigation müssen Datenabfragen deshalb an den Navigation Service gerichtet werden.
Daten-Transformation

Der CaaS speichert die an ihn übergebenen Daten im JSON-Format. Im ersten Schritt der Datenverarbeitung sollte eine Transformation durchgeführt werden, da die Daten verschachtelt sind und nicht notwendige Information enthalten. Die Daten sollten auf das Wesentliche reduziert und in ein für die Storefront optimales Format übertragen werden. Verknüpfte Informationen, wie beispielsweise Medien-URLs, müssen korrekt aufgelöst werden.

Ausgabe der Daten

Die Ausgabe der redaktionellen Inhalte übernimmt weiterhin die Storefront. Die Inhalte werden sowohl aus dem Shop-Backend als auch aus dem CaaS bezogen. Die Storefront verknüpft die Daten miteinander, um sie in einer kombinierten Ansicht auszuliefern.

Bei der Ausgabe der Daten aus dem CaaS müssen die in FirstSpirit verwendeten Informationen stets mit den realen Shop-Daten übereinstimmen. Das gilt nicht nur für die Korrektheit der Inhalte selbst, sondern auch für deren korrekte Platzierung. Innerhalb des Referenzprojekts FirstSpirit Connect for Commerce Reference Project werden die editierbaren Bereiche einer Shop-Seite durch die Inhaltsbereiche einer FirstSpirit-Seitenvorlage repräsentiert. Ihnen können Absätze hinzugefügt werden, die jeweils der äquivalenten Komponente einer Shop-Seite entsprechen.

Caching

Die in der Storefront dargestellten Inhalte werden dynamisch aus dem CaaS ermittelt. Jeder Aufruf der Storefront erzeugt somit eine CaaS-Abfrage. Dies kann zu umfangreichen Datenaufkommen führen. Um sowohl Performance-Probleme als auch hohe Kosten für Datenverkehr zu vermeiden, empfehlen wir unbedingt die projektspezifische Umsetzung einer Caching-Strategie.

3.3. Mapping der Identifier

Um stets eine fehlerfreie Zuordnung zwischen den Daten aus dem Shop-System und den in FirstSpirit verwendeten Produkt- und Kategorie-Informationen zu gewährleisten, ist ein Mapping erforderlich. Dieses muss auf eindeutigen IDs basieren, bei Produkten zum Beispiel der Stock Keeping Unit (SKU). Das Mapping ist sowohl für die Bridge als auch für die Datenübertragung im Frontend relevant.

Diagramm, welches das beschriebene Mapping der Identifier darstellt
Abbildung 3. Mapping der IDs zwischen Shop-System und FirstSpirit

Die im Mapping definierten IDs werden in den Formulardaten des jeweiligen FirstSpirit-Elements gespeichert und bei jeder Synchronisierung in den CaaS übertragen. Bei dem FirstSpirit-Element kann es sich sowohl um eine Seite als auch um beispielsweise einen einzelnen Teaser, der ein bestimmtes Produkt referenziert, handeln. Die Storefront kann dann abhängig von der Implementierung die zusätzlichen Produktdaten aus dem Shop-System hinzuziehen. Der CaaS persistiert die in FirstSpirit erstellten Inhalte und stellt diese der Storefront des angebundenen Shop-Systems bereit.

Die Storefront übernimmt weiterhin die Auslieferung der Inhalte, die sie aus dem Backend des Shop-Systems bezieht. Mit Connect for Commerce kann sie durch die Verwendung der Frontend API zusätzlich auf den CaaS zugreifen. Die Storefront verknüpft die Informationen mit denen des Shop-Systems und liefert sie abhängig von der Implementierung in einer kombinierten Ansicht aus.

4. Bearbeitung von Seiten in FirstSpirit

4.1. Seitenstruktur

Sowohl in FirstSpirit als auch innerhalb eines Shop-Systems basieren Seiten auf einer Struktur unterschiedlicher Komponenten. Um redaktionelle Inhalte beider Systeme verbinden zu können, müssen diese Komponenten aufeinander abgestimmt sein.

In FirstSpirit werden Inhalte mittels Absatzvorlagen erstellt. Ihre Form kann von einfachem Text bis zu komplexen UI-Komponenten reichen. Diese Absätze werden in den Seiten innerhalb von vordefinierten Inhaltsbereichen gepflegt. Ein Inhaltsbereich kann mehrere Absätze beinhalten. Die Anzahl und Position der Inhaltsbereiche auf den verschiedenen Seiten der Storefront kann im Rahmen der Implementierung des Frontends beliebig gewählt werden.

Innerhalb des Referenzprojekts FirstSpirit Connect for Commerce Reference Project werden die editierbaren Bereiche einer Shop-Seite durch die Inhaltsbereiche einer FirstSpirit-Seitenvorlage repräsentiert. Ihnen können Absätze hinzugefügt werden, die jeweils der äquivalenten Komponente einer Shop-Seite entsprechen (vgl. Abbildung Mapping zwischen FirstSpirit-Seite und Seite in der Storefront).

Mit FirstSpirit lassen sich somit Komponenten erstellen, die innerhalb der editierbaren Bereiche einer Shop-Seite dargestellt werden.

Diagram welches das Mapping zwischen FirstSpirit-Seite und Seite in der Storefront darstellt
Abbildung 4. Mapping zwischen FirstSpirit-Seite und Seite in der Storefront

4.2. Page-Typen

Die Pflege redaktioneller Inhalte erfolgt, sowohl in FirstSpirit als auch im Shop-System, auf Basis von Pages. Connect for Commerce unterscheidet dabei zwischen Shop-driven Pages und FirstSpirit-driven Pages.

FirstSpirit-driven Pages

FirstSpirit-driven Pages existieren ausschließlich in FirstSpirit und besitzen keine zugehörige Seite im Shop-System. Sie dienen der Erzeugung von Inhalts- oder Kampagnenseiten, die nicht zwingend im Standardumfang des Shop-Systems enthalten sind.

Shop-driven Pages

FirstSpirit-driven Pages setzen sich zusammen aus einer Seite in FirstSpirit und deren Gegenstück im Shop-System. Sie können beispielsweise der Homepage, Produkt- oder Kategorie-Seiten entsprechen. Die FirstSpirit-seitig gepflegten Inhalte können die bestehenden Inhalte dieser Seiten ergänzen oder sie überschreiben.

4.3. Redaktionelle Änderungen

FirstSpirit unterscheidet zwischen einem Vorschau- und einem Freigabestand der Inhalte. Das CaaS Connect-Modul spiegelt diese Unterscheidung im CaaS wider. Die beiden Stände sind über dedizierte CaaS-URLs erreichbar. Diese Stände können durch Aktionen innerhalb von FirstSpirit synchronisiert werden. Der Vorschaustand kann zum Beispiel durch das Speichern eines Absatzes geändert werden. Der Freigabestand wird nur von expliziten Freigabeaktionen, welche etwa durch einen Workflow realisiert werden können, aktualisiert. Alle anderen Änderungen ändern lediglich den Vorschaustand. Dieser wird nur bei der Einbindung der Storefront in den ContentCreator angezeigt.

Die mit Connect for Commerce realisierte Integration ermöglicht FirstSpirit-seitig die Erzeugung und Pflege der redaktionellen Inhalte sowie ihre Bereitstellung mithilfe des CaaS. Die Storefront des angebundenen Shop-Systems bestimmt jedoch weiterhin das Rahmenwerk einer Seite, deren editierbare Bereiche die generierten Komponenten einbinden.

4.4. Vorschau

In der Vorschau wird die Storefront von dem ContentCreator in einem iFrame angezeigt. Durch Einsatz der Frontend API kann die Storefront erkennen, wann sie im ContentCreator aufgerufen wurde. In diesem Fall werden die Inhalte aus dem Preview-CaaS angezeigt. Noch nicht freigegebene Inhalte können so in den entsprechenden Komponenten direkt im Kontext der Storefront betrachtet werden.

Es gilt sicherzustellen, dass die Storefront vom ContentCreator in einem Frame dargestellt werden kann, etwa durch korrekte Einstellungen bei der HTTP Content Security Policy.
Animation, welche die Bearbeitung des Inhalts via Drag-and-Drop zeigt
Abbildung 5. Bearbeitung des Inhalts via Drag-and-Drop

Die Frontend API bindet zudem automatisch Omnichannel Manager-Funktionalität in die Storefront ein. Der Omnichannel Manager stellt die Schnittstelle zwischen der Storefront und dem ContentCreator dar. Er bietet die Möglichkeit zur Kommunikation zwischen ContentCreator und somit FirstSpirit und der Storefront innerhalb des iFrames, wodurch die Funktionsweise eines WYSIWYG-Editors geschaffen wird. So wird die Pflege der Inhalte und ihre Freigabe direkt im Kontext der Storefront möglich.

Diagramm, welches die detaillierte Funktionsweise der Vorschau zeigt
Abbildung 6. Detaillierte Funktionsweise der Vorschau

Wenn die Frontend API nicht verwendet wird, muss der Omnichannel Manager dediziert eingebunden werden. Details hierzu können der Omnichannel Manager-Dokumentation entnommen werden.

5. Umsetzung

Bevor ein Projekt mithilfe von FirstSpirit Connect for Commerce umgesetzt wird, sollten einige Fragen zur Implementierung geklärt werden.

5.1. Vorab-Entscheidungen

5.1.1. Wahl des Identifiers

Ein Mapping der Identifier ist Voraussetzung für die Zuordnung von Shop-Daten zu den in FirstSpirit gepflegten Inhalten. Die lose Kopplung über einen einzelnen Identifier sorgt für eine hohe Flexibilität, da er beliebig aus den vorhandenen Daten innerhalb der Shop-Architektur gebildet werden kann. Die Verwendung eines einfachen Identifiers erleichtert das spätere Austauschen einzelner Komponenten. Der Identifier sollte zu Beginn des Projekts festgelegt werden, da die weitere Entwicklung der Bridge und der Storefront darauf aufbaut. Bei der Entscheidung spielen die aktuelle und die Zielarchitektur eine wichtige Rolle.

Eine Änderung des Identifiers im Projektverlauf ist in der Regel mit hohen Aufwänden in den betroffenen Projektbestandteilen verbunden. Darüber hinaus muss eine Migration der in FirstSpirit gespeicherten Daten stattfinden, damit bereits bestehende Inhalte weiterhin korrekt verknüpft bleiben. Da der Identifier in allen Komponenten innerhalb von FirstSpirit persistiert ist, kann es zu Nebeneffekten kommen. Dies äußert sich zum Beispiel in nicht auffindbaren Seiten.

5.1.2. Bridge

Die Bridge verknüpft Connect for Commerce mit der API des Shop-Systems und stellt auf diesem Weg eine Verbindung zwischen beiden Systemen her.

Die Implementierung kann auf verschiedenen Wegen geschehen, z.B. als eigenständiger Service. In diesem Fall kann das in der Auslieferung enthaltene Bridge Commons npm-Modul zur Implementierung einer auf Node.js basierenden Bridge verwendet werden. Die Bridge Commons minimieren den Implementierungsaufwand, so dass nur die für das Shop-System spezifischen Funktionalitäten hinzugefügt werden müssen.

Das Verwenden anderer Methoden ist genauso möglich. Zum Betreiben der Bridge müssen in dem Fall zum Beispiel Dienste wie Netlify oder ein eigener Kubernetes-Cluster verwendet werden.

Wird die Bridge in eine bereits bestehende Anwendung integriert, muss diese nicht als separater Service betrieben werden. In diesem Fall ist man jedoch in der Regel an die von der Anwendung vorgegebene Technologie gebunden. Mögliche Szenarien umfassen eine Bridge als Teil einer Middleware oder des Backends innerhalb der Shop-Architektur.

Da die Bridge selbst keine Daten speichert, kann sie im Projektverlauf mit wenig Aufwand ausgetauscht werden. Voraussetzung dafür ist, dass der verwendete Identifier stabil bleibt.

5.2. Planung

Die Realisierung von Projekten mittels Connect for Commerce kann generell auf verschiedene Weisen erfolgen. Aus diesem Grund existieren keine harten Anforderungen an die an der Umsetzung beteiligten Personen. Im Folgenden werden die unterschiedlichen Aufgaben und die nötigen Kenntnisse für ihre Lösung veranschaulicht.

5.2.1. Kompetenzen

Ein Connect for Commerce-Projekt besteht in der Regel aus folgenden Teilen, welche eine Anpassung benötigen.

Shop-System und Storefront

Das gewählte Shop-System bzw. die gewählte Storefront geben bestimmte Technologien vor. Für die Integration von Connect for Commerce sind Kenntnisse dieser Technologien sowie der Architektur dieser Anwendungen eine Voraussetzung an die entwickelnde Person.

Die korrekte Übermittlung von Daten muss gewährleistet sein. Eine wesentliche Aufgabe besteht darin, Komponenten für die in FirstSpirit gepflegten Inhalte zu erstellen, um eine korrekte Darstellung innerhalb der Storefront gewährleisten.

Zum Verwenden der Frontend API wird notwendiges Wissen in der dafür bereitgestellten Dokumentation bereitgestellt.

Wird für die Implementierung im Frontend die Frontend API verwendet, ist eine Einarbeitung mit der entsprechenden Dokumentation möglich.

Bridge-Implementierung

Für die erfolgreiche Umsetzung einer Bridge ist Erfahrung in der Implementierung eines Services notwendig.

Eine detaillierte Auflistung verschiedener Möglichkeiten ist im How-To: Implementierung einer Bridge festgehalten.

FirstSpirit

Für die Verwendung mit Connect for Commerce muss das verwendete FirstSpirit-Projekt geringfügig anhand dieser Anleitung angepasst werden. Für die grundlegende Verwendung sind keine tiefergreifenden Kenntnisse in FirstSpirit nötig. Die Auslieferung beinhaltet ein FirstSpirit-Referenzprojekt, welches die nowendigen Anpassungen sowie Referenzkomponenten beinhaltet. Abhängig von dem konkreten Projekt können etwa weitere Inhaltsbereiche und Komponenten definiert werden.

Für komplexere Anpassungen sind erweiterte Kentnisse in FirstSpirit nötig. Diese sind im ODFS oder im FirstSpirit Template development guide zu finden. Außerdem bietet Crownpeak Technology GmbH hierzu Schulungen an, die über die Webseite gebucht werden können.

Abschließend

Zusätzlich werden Kenntnisse für den Betrieb von Shop-System, Storefront und Bridge vorausgesetzt. Die benötigten Kompetenzen sind hier stark von der vorhandenen bzw. gewünschten Infrastruktur abhängig.

5.2.2. Erfahrungswerte für ein MVP

Die folgende Tabelle schlüsselt die zu erwartenden Aufwände für das Minimum Viable Product (MVP) bei einer Integration auf. Das MVP wird in unserem Fall als grundlegend funktionsfähige Integration definiert. Diese zeigt die Inhalte aus FirstSpirit für Shop-driven Pages und FirstSpirit-driven Pages in der Storefront im JSON-Format an. Außerdem ist damit das Bearbeiten mithilfe des Omnichannel Managers im ContentCreator möglich. Nachfolgend wird zwischen der Verwendung einer bereitgestellten Referenz-Implementierung und der komplett eigenständigen Entwicklung unterschieden.

Die nachfolgenden Schätzungen basieren auf Erfahrungswerten und können erheblich von tatsächlichen Aufwände abweichen.
Aufgabe Referenzimplementierung Eigenimplementierung

Einrichtung einer Bridge

1 Tag

1 Woche

Einrichtung des FirstSpirit-Projekts

1 Tag

1 Woche

Integration in die Storefront

  • Einbindung Frontend API

  • Unterstützung Shop-driven Pages

  • Unterstützung FirstSpirit-driven Pages

  • Implementierung einer Komponente

1 Tag

 

  • 2 Tage

  • 3 Tage

  • 3 Tage

  • 3 Tage

5.3. Performance

Vor der Implementierung eines FirstSpirit Connect for Commerce-Projektes sollten Strategien in Erwägung gezogen werden, mit denen ein performanter Betrieb langfristig möglich ist. Die folgenden Handlungsempfehlungen sollten bei der projektspezifischen Implementierung berücksichtigt werden.

5.3.1. Indizes

Eine hohe Anzahl von CaaS-Dokumenten kann die Laufzeit der Filterabfragen verlängern und somit die Gesamt-Performance beeinträchtigen. Um eine effizientere Abfrage zu ermöglichen, können auf CaaS-Collections Indizes auf häufig genutzte Dokumenten-Attribute erstellt werden. Im Standardumfang enthält CaaS Connect vorgefertigte Indizes für die Preview und Release Collection. Das Connect for Commerce-Modul erweitert diese um Connect for Commerce-spezifische Indizes.

Um die Performance der CaaS-Requests zu verbessern, legt das Connect for Commerce-Modul einen Index im CaaS an. Dieser besteht aus den Schlüsseln page.formData.type.value, page.formData.id.value, locale.language und locale.country, welche zur Identifizierung einer Shop-driven Page notwendig sind. Der Index wird jeweils für die Vorschau- und Freigabe-Collection angelegt.

Sollten die vorhandenen Indizes nicht ausreichen, besteht die Möglichkeit eigene Indizes zu erstellen. Nähere Informationen können in der CaaS Platform-Dokumentation nachgelesen werden.

5.3.2. Aggregationen

Zum Verbessern der Performance bei einer hohen Anzahl von CaaS-Dokumenten können Aggregationen verwendet werden. Diese transformieren die Daten je nach Projektanforderung und optimieren sie für die Abfrage im Frontend. Im Standardumfang sind vorgefertigte Aggregationen nicht enthalten. Bei Bedarf können Aggregationen jedoch eigenständig implementiert werden.

Detaillierte Informationen zu diesem Thema sind in der CaaS Platform-, RESTHeart- und MongoDB-Dokumentation zu finden.

5.3.3. Caching

Die Implementierung einer Caching-Strategie kann sowohl Latenzzeiten als auch die Serverlast minimieren, so dass eine bessere Performance gewährleistet werden kann.

Eine Caching-Strategie kann an verschiedenen Stellen in der Connect for Commerce-Architektur umgesetzt werden. Beispielsweise kann das Caching in einem Headless Commerce-Szenario Client-seitig in der Storefront implementiert werden. In einem Static Commerce-Szenario kann das Caching auch serverseitig im Backend des Shop-Systems integriert werden. Abhängig von der Dynamik der Seiteninhalte können einzelne Inhaltsbereiche oder sogar ganze Seiten für die Wiederverwendung zwischengespeichert werden. In beiden Fällen werden überflüssige Abfragen des Frontend API-Backend vermieden.

Eine weitere Option ist das Browser-Caching. In diesem Fall werden Website-Ressourcen durch die Verwendung eines Cache-Control-Headers zwischengespeichert.

5.3.4. Vorlagenentwicklung

Bei der Vorlagenentwicklung sollte darauf geachtet werden, die Verwendung sehr tief verschachtelter Vorlagen zu reduzieren, da sie die Größe des CaaS-Dokuments beeinflussen können. Es wird daher empfohlen in regelmäßigen Abständen eine Performance-Analyse der Vorlagen durchzuführen.

Nähere Informationen zur Analyse der Vorschauberechnung finden Sie in der FirstSpirit Developer-Dokumentation.

6. Zielarchitektur und Szenarien

FirstSpirit Connect for Commerce kann in einer Vielzahl von Szenarien eingesetzt werden. Nachfolgend wird die Architektur beschrieben, sowie die Verwendung der einzelnen Connect for Commerce-Komponenten innerhalb dieser Architektur.

6.1. Headless Commerce

Mit Connect for Commerce können Inhalte in Headless Shop-Systeme verschiedenster Technologien integriert werden.

Rolle der Frontend API in Bezug zu Shop-System und Storefront.