Lanzamientos por fases

Los lanzamientos por fases de tecnologías headless ahora son posibles para los usuarios de Storefront Reference Architecture (SFRA) y SiteGenesis. Por ejemplo, puede implementar una experiencia nueva y audaz para las páginas de productos con PWA kit y mantener el flujo de pago en la SFRA hasta la siguiente fase de su transición headless. Este enfoque por etapas le ayuda a comenzar antes y minimiza las interrupciones a lo largo del camino hacia el modo headless.

Esta guía describe cómo usar las reglas de cierre de brechas y de enrutamiento de la sesión para permitir que PWA Kit potencie un conjunto de páginas y SFRA potencie otro conjunto de páginas con una experiencia de usuario sin dificultades.

Las instrucciones de esta guía describen cómo combinar los flujos de PWA Kit y SFRA, pero las mismas instrucciones pueden adaptarse para SiteGenesis.

Habilitar que los compradores naveguen sin dificultades entre las páginas potenciales por diferentes arquitecturas de storefront requiere usar una técnica llamada cierre de brechas de la sesión. El cierre de brechas de la sesión usa cookies para compartir los tokens de actualización de comprador y los tokens de sesión en los diferentes sistemas.

La clave para desbloquear el cierre de brechas de la sesión es el Shopper Login and API Access Service (SLAS), una nueva solución basada en estándares para autenticar y autorizar a los que se puede acceder a través de solicitudes de HTTP. La autenticación del comprador con SLAS se basa en OpenID Connect y la autorización para las API de comprador de Commerce Cloud se basa en OAuth 2.

Cuando un navegador navega por un storefront headless, usted usa SLAS para solicitar un token de acceso y un token de actualización y los almacena como cookies en el navegador del comprador. Puede establecer la cookie con el encabezado set-cookie de HTTP o con JavaScript del lado del cliente. A medida que el comprador pasa de una página de SFRA a una página de PWA Kit (o viceversa), la cookie con el token de actualización se envía junto con la solicitud de HTTP y el código del storefront puede usar el token de actualización para iniciar la sesión del usuario.

El primer paso para crear un lanzamiento por fases es configurar su aplicación PWA Kit para que use SLAS (si aún no lo hizo). Siga las instrucciones en nuestra guía Configurar acceso de API.

Para permitir un lanzamiento por fases con SFRA, debe instalar el cartridge de complemento de SLAS. Las instrucciones de instalación completas se encuentran en el archivo README del cartridge.

Además del cierre de brechas de la sesión, el cartridge de complemento de SLAS le permite implementar otras características fáciles de usar para los compradores, como sesiones de usuario y persistencia de la canasta durante 90 días.

Debido a que el cartridge de complemento de SLAS está diseñado para SFRA, se debe escribir un código adicional para usarlo con SiteGenesis. Una implementación de SiteGenesis puede aprovechar el código del cartridge en varios puntos en los flujos de autenticación y autorización del comprador.

Debido a que el cartridge usa el Marco de servicios web de B2C Commerce para manejar las llamadas de API de SLAS, una implementación de SiteGenesis puede hacer solicitudes a los servicios web implementados por el cartridge. Estos servicios web incluyen inicio de sesión de invitados, inicio de sesión de clientes registrados, actualización de token, cierre de sesión y fusión de la canasta del cliente invitado. El cartridge también implementa un servicio para fusionar las sesiones de API y las sesiones del storefront.

Una implementación de SiteGenesis también puede usar un enlace personalizado (app.plugin.slas.login) para implementar el inicio de sesión para usuarios invitados y registrados con SLAS. Examine el código personalizado en el enlace onSession del cartridge en dw.system.request.onSession para ver cómo reemplaza Script API con SLAS para el inicio de sesión del comprador.

Para hacer posible el cierre de brechas de la sesión con PWA Kit, debe modificar el código en commerce-api/auth.js que maneja la autorización de API para usar cookies en lugar del almacenamiento local.

Si su proyecto de PWA Kit se generó con la versión 1.5.0 o posterior de la plantilla de la Retail React App, puede quitar la marca de comentario de esta línea de código en auth.js y no necesitará hacer más cambios al archivo.

Para los proyectos generados antes de la versión 1.5.0, debe hacer varios cambios a commerce-api/auth.js. Para ahorrarle tiempo, hemos creado una versión alternativa del archivo con todos los cambios aplicados y lo hemos publicado en GitHub a través de una esencia pública.

El flujo de autorización comienza con el token de actualización. Si la cookie del token de actualización está disponible, la aplicación PWA Kit intercambia el token de actualización por un token de acceso. De lo contrario, la aplicación inicia un flujo de otorgamiento de código de autorización, según lo definido por el estándar OAuth 2. También sigue el flujo de clave de prueba para el intercambio de código (PKCE).

Cuando SLAS otorga un nuevo token de acceso y un nuevo token de actualización, la aplicación los almacena en cookies. Luego la aplicación hace una solicitud de POST al punto de conexión crear sesión (/session) de OCAPI. Este punto de conexión crea una sesión que es usada por SFRA. La aplicación almacena el token de la sesión en una cookie.

Cookies creadas por la aplicación PWA Kit:

  • cc-nx-g: token de actualización de comprador invitado de SLAS
  • cc-nx: token de actualización de comprador registrado de SLAS
  • token: token de acceso de SLAS
  • dwsid: identificación de sesión de Demandware

El siguiente diagrama muestra el flujo de autorización modificado para PWA Kit:

Diagrama asociado

Otro aspecto importante de un lanzamiento por fases es el enrutamiento. Para atender el tráfico hacia dos sistemas diferentes, necesitamos configurar la CDN para enrutar el tráfico a dos orígenes diferentes: el entorno de Managed Runtime y su instancia de B2C Commerce.

Imagine el siguiente escenario:

Tiene un storefront de SFRA existente ejecutándose en www.mystorefront.com. Conoce los beneficios de la arquitectura headless y desea aprovechar PWA Kit para brindar experiencias con buen rendimiento y atractivas. Al mismo tiempo, desea minimizar el riesgo para el cronograma, por lo que establece un plan para lanzar un storefront de PWA Kit usando un enfoque por etapas.

El plan es usar PWA Kit para las páginas en la parte superior del embudo: página de inicio (/), la página de listado de categorías (/category) y la página de detalles del producto (/product). Estas páginas de PWA Kit se implementan en un entorno de Managed Runtime que se ejecute en mystorefront.mobify-storefront.com. Cuando el comprador decide hacer una compra, usted lo redirige a la página de finalización de la compra (checkout) de SFRA existente que se ejecuta en www.mystorefront.com.

Si usted es un cliente de una CDN integrada (eCDN), comuníquese con Soporte para configurar sus reglas de enrutamiento.

Ahora es momento de agregar un origen a su zona de CDN para las páginas de PWA Kit que apunta a su entorno de Managed Runtime (mystorefront.mobify-storefront.com).

Luego, cree reglas de enrutamiento para atender tráfico basado en la ruta de la URL. Comience recopilando una lista integral de rutas para páginas PWA Kit. Para un proyecto de PWA Kit basada en la plantilla de la Retail React App, las rutas se listan en app/routes.jsx. Debido a que el sistema de renderización del lado del servidor para PWA Kit use rutas internas para proxies y activos estáticos, también debe incluir /mobify/* en las reglas de enrutamiento.

Para nuestro escenario de ejemplo, se deben configurar las siguientes rutas en su CDN:

Para cada una de las rutas de PWA Kit en su lista, configure su CDN para que envíe la solicitud al entorno de Managed Runtime (mystorefront.mobify-storefront.com en nuestro escenario de ejemplo).

El siguiente diagrama muestra cómo configurar su CDN:

Diagrama asociado

Por defecto, la plantilla de la Retail React App para los proyectos de PWA Kit tiene un patrón de enrutamiento de URL diferente que SFRA. Por ejemplo, la ruta de la URL para una página de detalles del producto en la Retail React App es /products/{productId}. Con SFRA, el patrón es /{categoryId}/{productId}.

Recomendamos que cambie los patrones de enrutamiento en su storefront de PWA Kit para que coincida con su sitio de SFRA. Si no puede hacer coincidir los patrones de URL para una página específica (como la página de listado de productos cuando la identificación de la categoría no está disponible en la URL), puede usar el Cartridge de redireccionamiento para configurar redireccionamientos que cierren la brecha. Las instrucciones de instalación completas se encuentran en el archivo README para el cartridge.

Para completar el proceso de configuración para el lanzamiento por fases, debe hacer algunos cambios más a su proyecto de PWA Kit.

Por defecto, PWA Kit usa la API de historial para la navegación. Cuando un comprador hace clic en un vínculo creado con el componente <Link> del enrutador de React, dispara una navegación suave al componente que coincide con la ruta en el objeto de ruta definido en app/routes.jsx. Para vincular a un página que no sea de PWA Kit (una con tecnología de SFRA, por ejemplo), debe eliminar todas las rutas que coincidan con el nombre de la ruta de la URL de app/routes.jsx.

Por ejemplo, elimine finalizar la compra (checkout) de la matriz de rutas. Elimine la ruta de finalizar la compra (checkout)

Por último, actualice la ruta universal de PWA (/*) en app/routes.jsx. Reemplace el componente <PageNotFound /> de PWA con un redireccionamiento al origen por defecto.