Phasenweise Headless-Rollouts

Phasenweise Rollouts von Headless-Technologien sind nun für Benutzer von Storefront Reference Architecture (SFRA) und SiteGenesis möglich. Sie können beispielsweise ein gewagtes neues Erlebnis für Produktseiten mit dem PWA Kit bereitstellen und den Checkout bis zur nächsten Phase Ihres Wechsels zu Headless weiterhin über SFRA abwickeln. Dieser phasenweise Ansatz hilft Ihnen dabei, früher zu beginnen, und minimiert Unterbrechungen auf Ihrem Weg zu Headless.

In dieser Anleitung wird beschrieben, wie Sie Session Bridging und Routing-Regeln verwenden, damit zwischen mit PWA Kit und mit SFRA betriebenen Seiten eine nahtlose Benutzererfahrung möglich ist.

Damit Käufer nahtlos zwischen Seiten mit unterschiedlicher Storefront-Architektur navigieren können, ist ein Vorgang mit der Bezeichnung Session Bridging erforderlich. Beim Session Bridging werden Cookies verwendet, um die Aktualisierungstoken und Sessiontoken von Käufern in unterschiedlichen Systemen zu teilen.

Session Bridging funktioniert mithilfe des Shopper Login and API Access Service (SLAS). Dabei handelt es sich um eine neue standardbasierte Lösung für die Authentifizierung und Autorisierung, auf die über HTTP-Anfragen zugegriffen werden kann. Die Käuferauthentifizierung mit SLAS basiert auf OpenID Connect und die Autorisierung für die Shopper-APIs von Commerce Cloud basiert auf OAuth 2.

Wenn ein Käufer eine Headless-Storefront besucht, verwenden Sie SLAS, damit ein Zugriffstoken und ein Aktualisierungstoken angefordert und als Cookies im Browser des Käufers gespeichert werden. Sie können den Cookie mit dem HTTP-Header set-cookie oder auf der Clientseite mit JavaScript festlegen. Wenn ein Käufer von einer SFRA-Seite auf eine PWA Kit-Seite wechselt (oder umgekehrt), wird der Cookie mit dem Aktualisierungstoken zusammen mit der HTTP-Anfrage gesendet. Der Storefront-Code kann den Benutzer dann mithilfe des Aktualisierungstokens anmelden.

Der erste Schritt für einen phasenweisen Headless-Rollout ist, Ihre PWA Kit-Anwendung für die Verwendung von SLAS einzurichten (falls Sie dies noch nicht getan haben). Befolgen Sie die Anweisungen in der Anleitung Einrichtung des API-Zugriffs.

Damit ein phasenweiser Headless-Rollout mit SFRA möglich ist, müssen Sie die SLAS Plug-in-Cartridge installieren. Die vollständige Installationsanleitung finden Sie in der README-Datei der Cartridge.

Da die SLAS Plug-in-Cartridge für SFRA ausgelegt ist, muss für die Verwendung mit SiteGenesis zusätzlicher Code geschrieben werden. Eine SiteGenesis-Implementierung kann an verschiedenen Punkten der Flows zur Käuferauthentifizierung und -autorisierung Code von der Cartridge nutzen.

Da die Cartridge das B2C Commerce Web Service Framework für die Bearbeitung von SLAS API-Aufrufe verwendet, kann eine SiteGenesis-Implementierung Anfragen an die von der Cartridge implementierten Web-Services stellen. Zu diesen Web-Services gehören die Gastanmeldung, die Anmeldung von registrierten Kunden, die Aktualisierung von Token, die Abmeldung und das Zusammenführen des Gastwarenkorbs. Die Cartridge implementiert auch einen Service zum Zusammenführen von API-Sessions und Storefront-Sessions.

Eine SiteGenesis-Implementierung kann ebenfalls einen benutzerdefinierten Hook (app.plugin.slas.login) nutzen, um die Anmeldung für Gäste und registrierte Benutzer mit SLAS zu implementieren. Sehen Sie sich den benutzerdefinierten Code im onSession-Hook der Cartridge in dw.system.request.onSession an, um zu sehen, wie die Script API für die Käuferanmeldung mit SLAS ersetzt wird.

Damit Session Bridging mit dem PWA Kit möglich ist, müssen Sie den Code für die API-Autorisierung in commerce-api/auth.js bearbeiten, damit Cookies anstelle des lokalen Speichers verwendet werden.

Wurde Ihr PWA Kit-Projekt mit Version 1.5.0 oder einer neueren Version der Retail React App-Vorlage erstellt, können Sie die Kommentarmarkierung dieser Codezeile in auth.js aufheben. Es sind keine weiteren Änderungen an der Datei erforderlich.

Bei Projekten, die vor Version 1.5.0 erstellt wurden, müssen Sie mehrere Änderungen an commerce-api/auth.js vornehmen. Um Ihnen Zeit zu sparen, haben wir eine alternative Version der Datei mit allen Änderungen erstellt und bei GitHub als öffentlichen Gist zur Verfügung gestellt.

Der Autorisierungs-Flow beginnt mit dem Aktualisierungstoken. Wenn ein Cookie für den Aktualisierungstoken verfügbar ist, tauscht die PWA Kit App den Aktualisierungstoken gegen einen Zugriffstoken aus. Ansonsten startet die App einen Flow zur Gewährung eines Autorisierungscodes, wie gemäß OAuth 2-Standard definiert. Sie folgt außerdem dem Flow Proof Key for Code Exchange (PKCE).

Wenn die neuen Zugriffs- und Aktualisierungstoken von SLAS gewährt werden, speichert die App sie in Cookies. Dann führt die App eine POST-Anfrage an OCAPI zum Erstellen eines Session-Endpunkts (/session) aus. Dieser Endpunkt erstellt eine Session, die von SFRA verwendet wird. Die App speichert das Sessiontoken in einem Cookie.

Von der PWA Kit App erstellte Cookies:

• cc-nx-g – SLAS Aktualisierungstoken für Gastkäufer
• cc-nx – SLAS Aktualisierungstoken für registrierten Käufer
• token – SLAS Zugriffstoken
• dwsid – Demandware Session-ID

Die folgende Abbildung zeigt den geänderten Autorisierungs-Flow für PWA Kit:

Ein weiterer wichtiger Aspekt eines phasenweisen Headless-Rollouts ist das Routing. Um Traffic an zwei verschiedene Systeme zu leiten, müssen wird das CDN so einrichten, dass es Traffic an zwei verschiedene Ursprünge leitet: die Managed Runtime-Umgebung und Ihre B2C Commerce-Instanz.

Stellen Sie sich das folgende Szenario vor:

Sie haben eine bestehende SFRA-Storefront unter www.mystorefront.com. Sie kennen die Vorteile der Headless-Architektur und möchten PWA Kit nutzen, um leistungsstarke und attraktive Erlebnisse zu schaffen. Gleichzeitig möchten Sie Risiken beim Zeitplan minimieren. Also entwickeln Sie den Plan, mit einem phasenweisen Ansatz eine PWA Kit-Storefront einzuführen.

Der Plan sieht vor, PWA Kit für die Seiten zu verwenden, die sich am Trichter oben befinden: Startseite (/), Kategorieseite (/category) und Produktdetailseite (/product). Die PWA Kit-Seiten werden auf einer Managed Runtime-Umgebung unter mystorefront.mobify-storefront.com bereitgestellt. Wenn sich ein Käufer zum Kauf entschließt, wird er auf die bestehende SFRA-Seite für die Kaufabwicklung unter www.mystorefront.com weitergeleitet.

Nun müssen Sie einen Ursprung zur Ihrer CDN-Zone für PWA Kit-Seiten hinzufügen, der auf Ihre Managed Runtime-Umgebung verweist (mystorefront.mobify-storefront.com).

Erstellen Sie dann Routing-Regeln, mit denen Traffic auf Grundlage des URL-Pfads geleitet wird. Erstellen Sie zunächst eine umfassende Liste an Routen für PWA Kit-Seiten. Für ein PWA Kit-Projekt auf Grundlage der Retail React App-Vorlage sind die Routen in app/routes.jsx aufgelistet. Da das serverseitige Rendering-System für PWA Kit interne Routen für Proxies und statische Assets verwendet, müssen Sie /mobify/* ebenfalls in die Routing-Regeln einbeziehen.

Für unser Beispielszenario müssen die folgenden Routen in Ihrem CDN konfiguriert werden:

Konfigurieren Sie Ihr CDN für jede PWA Kit-Route auf Ihrer Liste so, dass die Anfrage an die Managed Runtime-Umgebung (mystorefront.mobify-storefront.com in unserem Beispielszenario) weitergeleitet wird.

In der folgenden Abbildung ist dargestellt, wie Sie Ihr CDN konfigurieren:

Standardmäßig hat die Retail React App-Vorlage für PWA Kit-Projekte ein anderes Muster für das URL-Routing als SFRA. So lautet der URL-Pfad für eine Produktdetailseite in der Retail React App beispielsweise /products/{productId}. Bei SFRA ist das Muster /{categoryId}/{productId}.

Wir empfehlen Ihnen, die Routing-Muster in Ihrer PWA Kit-Storefront so zu ändern, dass diese Ihrer SFRA-Website entsprechen. Können Sie die URL-Muster für eine bestimme Seite nicht entsprechend anpassen (beispielsweise für die Produktlistenseite, wenn die Kategorie-ID nicht in der URL verfügbar ist), dann können Sie die Redirect Cartridge verwenden, um mithilfe von Umleitungen die Lücke zu schließen. Die vollständige Installationsanleitung finden Sie in der README-Datei der Cartridge.

Um den Einrichtungsprozess für einen phasenweisen Headless-Rollout abzuschließen, müssen Sie noch einige weitere Änderungen an Ihrem PWA Kit-Projekt vornehmen.

Standardmäßig verwendet PWA Kit die History API für die Navigation. Klickt ein Käufer auf einen mit der <Link>-Komponente von React Router erstellten Link, wird eine softe Navigation zu der Komponente ausgelöst, die dem Pfad des in app/routes.jsx definierten Routenobjekts entspricht. Zum Verlinken einer nicht mit PWA Kit betriebenen Seite (beispielsweise einer SFRA-Seite) müssen Sie jede dem URL-Pfadname entsprechende Route aus app/routes.jsx entfernen.

Beispiel: Checkout aus dem Array an Routen entfernen.

Aktualisieren Sie zum Schluss die PWA Catch-all-Route (/*) in app/routes.jsx. Ersetzen Sie die PWA-Komponente '' mit einer Umleitung an den Standardursprung.