API CDN pour les implémentations hybrides

Un déploiement headless échelonné permet d’offrir une expérience d’achat unique grâce à plusieurs technologies de boutique en ligne telles que Storefront Reference Architecture (SFRA) et Composable Storefront.

Une zone de CDN intégré (eCDN) peut router le trafic vers SFRA et Managed Runtime en même temps, ce qui vous permet de déployer progressivement une boutique Composable Storefront.

Ce guide explique comment utiliser les Zones CDN de l’API Commerce pour router le trafic vers Managed Runtime. Vous pouvez également utiliser Business Manager pour acheminer le trafic vers Managed Runtime. Configurer les règles de routage MRT dans Business Manager

Avant d’exécuter les commandes de ce guide, remplacez les espaces réservés par des valeurs réelles. Les espaces réservés sont formatés ainsi : $PLACEHOLDER.

Tout au long de ce guide, nous utilisons un exemple de boutique en ligne avec l’URL https://www.example.comde production.

1. Familiarisez-vous avec la section Autorisation pour les API d’administration
2. Vous devez disposer d’un client API Account Manager avec l’étendue sfcc.cdn-zones.rw.
3. Vous devez connaître l’identifiant de la zone eCDN à utiliser avec Managed Runtime. Pour obtenir ces informations, utilisez le point de terminaison getZonesInfo de l’API CDN Zones.
4. Utilisez updateSecuritySettings pour activer alwaysUseHttps sur la zone. Managed Runtime ne prend en charge le trafic que via HTTPS.
5. Définissez le paramètre redirect_uri de votre client API SLAS afin d’inclure la zone.
6. Si vous avez restreint l’ensemble des adresses IP autorisées à accéder à votre environnement Managed Runtime, ajoutez les IP CloudFlare utilisées par l’eCDN à l’ensemble de vos adresses IP autorisées.

Le point de terminaison createMrtRules vous permet de créer des règles qui routent le trafic vers un environnement Managed Runtime :

Examinons les données fournies dans le corps de la requête.

La valeur de mrtHostname est le domaine de l’environnement Managed Runtime pour le routage du trafic. Elle doit faire référence à un environnement Managed Runtime hébergé sur le domaine mobify-storefront.com. Si la valeur fournie est utilisée par une règle existante, la request échoue.

La valeur de expressions est un tableau d’Expressions de règles Cloudflare qui déterminent quelles requests sont routées vers Managed Runtime. Pour la plupart des implémentations, une seule expression de routage suffit.

Les règles de routage par défaut ci-dessous s’appliquent en plus des expressions fournies :

Les modifications de routage s’appliquent immédiatement et la navigation vers une URL correspondant à une expression renvoie le contenu récupéré à partir de Managed Runtime.

• Les scénarios de routage suivants sont pris en charge :

  • Un nom d’hôte unique mappé à un environnement MRT unique :

    • Par exemple, http.host eq \"www.example.com\" → example-production.mobify-storefront.com

  • Plusieurs noms d’hôte mappés à un seul environnement MRT :

    • Par exemple, http.host in {\"www.example.com\" \"prod.example.com\" \"us.example.com\"}→ example-production.mobify-storefront.com

• Le scénario de routage suivant n’est actuellement pas pris en charge :

  • Un nom d’hôte unique mappé à plusieurs environnements MRT en fonction de chemins différents

Les expressions sont validées par rapport aux critères suivants :

• http.host doit se produire exactement une fois et doit être suivi par l’opérateur eq OU in. Voir ci-dessus pour des exemples d’utilisation.
• Le ou les noms d’hôte doivent correspondre à la zone. En d’autres termes, la zone eCDN doit disposer d’un certificat valide qui couvre le(s) nom(s) d’hôte fourni(s).
• Les champs suivants sont pris en charge :
  • http.host
  • http.request.uri.path
  • http.request.uri
  • http.cookie
• La longueur maximale d’une expression est limitée à 3 072 caractères.
• 100 expressions maximum peuvent être associées à une zone.

Au fil de votre déploiement échelonné, le nombre de requests que vous pouvez router vers Managed Runtime augmente.

Pour modifier une expression de routage, utilisez getMrtRule pour obtenir les identifiants de l’ensemble de règles et de la règle associés à l’expression que vous souhaitez mettre à jour :

Utilisez ensuite updateMrtRule pour mettre à jour l’expression :

Pour ajouter d’autres règles de routage à un environnement Managed Runtime existant, utilisez updateMrtRuleset et fournissez les expressions de mrtHostname routage suivantes :

Pour ajouter des règles de routage pour un nouvel environnement Managed Runtime, utilisez le point de terminaison createMrtRules et fournissez une nouvelle mrtHostname valeur :

Pour mettre à jour des règles existantes afin de les acheminer vers un autre environnement d’exécution managée, utilisez updateMrtRuleset et indiquez le oldMrtHostname et le (nouveau) mrtHostname vers lequel vous souhaitez router :

Si vous passez à un CDN tiers ou si vous ne souhaitez plus acheminer un chemin particulier de l’eCDN vers le MRT, vous pouvez désactiver le routage.

Pour désactiver le routage, utilisez getMrtRules pour obtenir les identifiants de la configuration que vous souhaitez supprimer :

Ensuite, pour supprimer la règle de routage Managed Runtime, utilisez deleteMrtRule et transmettez les ID applicables renvoyés par getMrtRules:

Si vous souhaitez supprimer toutes les règles de routage Managed Runtime, utilisez deleteMrtRuleset:

À la fin de votre déploiement échelonné ou lors du lancement d’un nouveau site, vous pouvez choisir de router tout le trafic d’une zone vers Managed Runtime à l’aide d’une seule expression :

Dans les environnements où eCDN n’est pas disponible, utilisez composable-hybrid-dev-server pour simuler le routage de l’eCDN.

• Utiliser une boutique composable dans une implémentation hybride
• Configurer une boutique hybride avec authentification hybride
• Premiers pas avec Composable Storefront