CDN APIs für phasenweise Headless-Rollouts

Das phasenweise Headless-Rollout ist eine Methode zur Bereitstellung eines einheitlichen Kauferlebnisses, bei der mehrere Storefront-Technologien wie Storefront Reference Architecture (SFRA) und Composable Storefront verwendet werden.

Eine eingebettete CDN-Zone (eCDN) kann Traffic gleichzeitig an sowohl SFRA als auch Managed Runtime leiten. Dies ermöglicht Ihnen eine phasenweise Einführung einer Composable Storefront.

Diese Anleitung beschreibt, wie Sie mithilfe von Commerce API CDN-Zonen Traffic an Managed Runtime leiten.

• Zusammenfassung des Prozesses
• Einstein Aktivitäten für phasenweise Headless-Rollouts

1. Machen Sie sich mit der Autorisierung für Admin APIs vertraut.
2. Sie müssen über einen Account Manager API Client mit dem Umfang sfcc.cdn-zones.rw verfügen.
3. Sie müssen die Zonen-ID der eCDN-Zone kennen, die mit Managed Runtime verwendet werden soll. Um diese Informationen zu erhalten, verwenden Sie den Endpunt getZonesInfo der CDN Zones API.
4. Mit updateSecuritySettings aktivieren Sie alwaysUseHttps für die Zone. Managed Runtime unterstützt nur Traffic über HTTPS.
5. Stellen Sie redirect_uri Ihres SLAS API Clients so ein, dass die Zone enthalten ist.
6. Wenn Sie die Gruppe der IPs eingeschränkt haben, die auf Ihre Managed Runtime-Umgebung zugreifen darf, fügen Sie die von eCDN verwendeten CloudFlare IPs zur Gruppe der zugelassenen IPs hinzu.

Mithilfe des Endpunkts createMrtRules können Sie Regeln erstellen, die den Traffic an eine Managed Runtime-Umgebung leiten:

Sehen wir uns die im Abfragetext bereitgestellten Daten nun einmal näher an.

Der Wert von mrtHostname ist die Domain der Managed Runtime-Umgebung für das Traffic-Routing. Er muss auf eine in der Domain mobify-storefront.com gehostete Managed Runtime-Umgebung verweisen. Wenn der angegebene Wert von einer bereits vorhandenen Regel verwendet wird, schlägt die Abfrage fehl.

Der Wert von expressions ist ein Array von Cloudflare-Regelausdrücken, die steuern, welche Abfragen an Managed Runtime geleitet werden. Für die meisten Implementierungen reicht ein einziger Routing-Ausdruck aus.

Zusätzlich zu den angegebenen Ausdrücken werden die folgenden Standard-Routing-Regeln verwendet:

Routing-Änderungen werden sofort übernommen, und die Navigation zu einer mit einem Ausdruck übereinstimmenden URL gibt den aus Managed Runtime abgerufenen Inhalt zurück.

Ausdrücke werden anhand der folgenden Kriterien validiert:

• http.host muss genau einmal vorkommen und vom Operator eq gefolgt werden. Der Wert muss mit der Zone übereinstimmen.
• Die folgenden Felder werden unterstützt:
  • http.host
  • http.request.uri.path
  • http.request.uri
  • http.cookie
• Die maximale Länge eines Ausdrucks beträgt 3072 Zeichen.
• Maximal 100 Ausdrücke können mit einer Zone verknüpft sein.

Während Sie das phasenweise Rollout fortsetzen, können Sie weitere Abfragen an Managed Runtime leiten.

Um einen Routing-Ausdruck zu ändern, rufen Sie mit getMrtRule die IDs des Regelsatzes und der Regel ab, die mit dem zu aktualisierenden Ausdruck verknüpft sind:

Verwenden Sie anschließend updateMrtRule, um den Ausdruck zu aktualisieren:

Rufen Sie die für die Routing-Deaktivierung benötigte Regelsatz-ID mit getMrtRule ab:

Verwenden Sie dann deleteMrtRuleset, um das Managed Runtime-Routing für diesen Regelsatz zu entfernen:

Wenn Sie das phasenweise Rollout abschließen oder eine neue Website starten, können Sie den gesamten Traffic einer Zone mit einem einzigen Ausdruck an Managed Runtime leiten:

In Umgebungen, in denen eCDN nicht verfügbar ist, können Sie mit composable-hybrid-dev-server eCDN-Routing simulieren.

Obwohl createMrtRules die Erstellung von Regeln ermöglicht, die Traffic von einem einzelnen Host-Namen an mehrere Managed Runtime-Umgebungen weiterleiten, wird dieser Anwendungsfall derzeit nicht unterstützt.

• Erste Schritte mit Composable Storefront