CDN-APIs für hybride Implementierungen

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. Sie können Business Manager auch verwenden, um Traffic an Managed Runtime weiterzuleiten. MRT-Routing-Regeln in Business Manager konfigurieren

Ersetzen Sie vor dem Ausführen der Befehle in dieser Anleitung alle Platzhalter durch tatsächliche Werte. Platzhalter haben das folgende Format: $PLACEHOLDER.

In diesem Leitfaden verwenden wir eine Beispiel-Storefront mit der Produktions-URL https://www.example.com.

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.

• Die folgenden Routingszenarien werden unterstützt:

  • Ein einzelner Hostname, der einer einzelnen MRT-Umgebung zugeordnet ist:

    • Beispiel: http.host eq \"www.example.com\" → example-production.mobify-storefront.com

  • Mehrere Hostnamen, die einer einzelnen MRT-Umgebung zugeordnet sind:

    • Beispiel: http.host in {\"www.example.com\" \"prod.example.com\" \"us.example.com\"}→ example-production.mobify-storefront.com

• Das folgende Routingszenario wird derzeit nicht unterstützt:

  • Ein einzelner Hostname, der mehreren MRT-Umgebungen basierend auf unterschiedlichen Pfaden zugeordnet ist

Ausdrücke werden anhand der folgenden Kriterien validiert:

• http.host muss genau einmal auftreten und muss entweder vom eq Operator or in gefolgt werden. Siehe oben für Anwendungsbeispiele.
• Die Hostnamen müssen mit der Zone übereinstimmen. Mit anderen Worten, die eCDN-Zone muss über ein gültiges Zertifikat verfügen, das den/die bereitgestellten(n) Hostname(n) abdeckt.
• 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:

Wenn Sie einer vorhandenen Managed Runtime-Umgebung weitere Routingregeln hinzufügen möchten, verwenden Sie updateMrtRuleset, und geben Sie die mrtHostname und zusätzliche Routingausdrücke an:

Um Routingregeln für eine neue Managed Runtime-Umgebung hinzuzufügen, verwenden Sie den createMrtRules-Endpunkt, und geben Sie einen neuen mrtHostname Wert an:

Um vorhandene Regeln so zu aktualisieren, dass sie an eine andere Managed Runtime-Umgebung weitergeleitet werden, verwenden Sie updateMrtRuleset, und geben Sie das und das (new) mrtHostname an, an oldMrtHostname das Sie weiterleiten möchten:

Wenn Sie zu einem CDN eines Drittanbieters wechseln oder einen bestimmten Pfad nicht mehr vom eCDN zur MRT weiterleiten möchten, können Sie das Routing deaktivieren.

Um das Routing zu deaktivieren, verwenden Sie getMrtRules, um die IDs der Konfiguration abzurufen, die Sie löschen möchten:

Um dann die Routingregel für die verwaltete Laufzeit zu entfernen, verwenden Sie deleteMrtRule, und übergeben Sie die entsprechenden IDs, die von getMrtRules zurückgegeben werden:

Wenn Sie alle Routingregeln der verwalteten Laufzeit entfernen möchten, verwenden Sie deleteMrtRuleset:

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.

• Verwenden von Composable Storefront in einer Hybridimplementierung
• Konfigurieren einer Hybrid Storefront mit Hybrid Auth
• Erste Schritte mit Composable Storefront