API du CDN pour un déploiement headless échelonné

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.

• Résumé du processus
• Einstein Activities pour des déploiements headless échelonnés

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 expressions sont validées par rapport aux critères suivants :

• http.host doit apparaître exactement une fois et doit être suivi de l’opérateur eq. La valeur doit correspondre à la zone.
• 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 désactiver le routage, utilisez getMrtRule pour obtenir l’identifiant de l’ensemble de règles :

Puis utilisez deleteMrtRuleset pour supprimer le routage Managed Runtime pour cet ensemble de règles :

À 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.

Bien que createMrtRules permette la création de règles qui acheminent le trafic d’un seul nom d’hôte vers plusieurs environnements Managed Runtime, ce cas d’utilisation n’est actuellement pas pris en charge.

• Premiers pas avec Composable Storefront