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.

Para obtener más sobre la utilización de Actividades de Einstein en un contexto de fases, consulte Actividades de Einstein para lanzamientos por fases.

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.

Plugin SLAS administra las sesiones de B2C Commerce (asociadas con una dwsid), así como las sesiones de SLAS (asociadas con un access_token). El cierre de brechas de la sesión vincula a la dwsid y al access_token a la sesión del mismo comprador.

Plugin SLAS utiliza dos métodos de cierre de brechas de la sesión:

1. Cierre de brechas de la sesión SLAS (API: getSessionBridgeAccessToken)
   • Utilizado por Plugin SLAS para Inicio de sesión de invitado nuevo únicamente.
   • No genera una nueva dwsid después del cierre de brechas de la sesión, por lo que no se debe volver a representar el storefront y puede recibir una respuesta 200 - OK.
2. Cierre de brechas de la sesión de OCAPI (API: Obtener sesión de OCAPI)
   • Utilizado por Plugin SLAS para Inicio de sesión de comprador registrado e Inicio de sesión de token de actualización.
   • Genera una nueva dwsid después del cierre de brechas de la sesión, por lo que se debe actualizar el storefront y debe recibir una respuesta 302 - Redireccionamiento.

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 Plugin SLAS. Las instrucciones de instalación completas se encuentran en el archivo README del cartridge.

Consideraciones importantes para los usuarios de cartridge de SLAS

El cartridge de Plugin SLAS hace varias llamadas a diversos API, lo que puede afectar el rendimiento del storefront. Antes de agregar el cartridge a un storefront de Producción (Production), compare el rendimiento de su storefront con y sin el cartridge para decidir si es adecuado para usted.

El cartridge también hace un redireccionamiento en las siguientes condiciones:

• Cuando un comprador aún no tiene una cookie de sesión.
• Cuando la cookie de sesión de un comprador caducó.
• Cuando un motor de búsqueda indexa su sitio.

Actualmente, el cartridge solo reemplaza el inicio de sesión directo al sistema de B2C Commerce en el que las credenciales se almacenan dentro de Salesforce.

Cuando se utiliza con el complemento de listas de deseos, las listas de deseos de invitados no se transfieren al usuario registrado tras el inicio de sesión.

Antes de utilizar el cartridge, consulte la página de problemas en GitHub.

Debido a que el cartridge de Plugin 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 2.7.x de la plantilla de la Retail React App, puede quitar la marca de comentario de esta línea de código en auth.js para cambiar a CookieStorage para el almacenamiento de tokens. Esto es obligatorio para administrar sesiones entre los sitios de SFRA y PWA Kit.

También debe modificar el código en commerce-api/auth.js que llama a la API de cierre de brechas de la sesión después del inicio de sesión del comprador. Para hacerlo, debe quitar la marca de comentario de esta línea de código en 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.

Si su proyecto de PWA Kit se generó con la versión 3.0.0 o posterior de la plantilla de la Retail React App, los cambios mencionados más arriba están habilitados por defecto y no necesitará hacer más cambios de código.

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

Para garantizar una experiencia de usuario sin dificultades durante el lanzamiento por fases, necesita una forma de enrutar el tráfico a dos orígenes diferentes: el entorno de Managed Runtime y su instancia de B2C Commerce. Este enrutamiento de tráfico puede hacerse mediante una red de entrega de contenidos (CDN).

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 elige un enfoque por fases para lanzar su storefront de PWA Kit.

Configura la CDN para enviar la solicitud de la página en la parte superior del embudo a PWA Kit: 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, la CDN lo redirige a la página de finalización de la compra (checkout) de SFRA existente que se ejecuta en www.mystorefront.com.

Para manejar el enrutamiento de tráfico, puede elegir la solución de CDN integrada (eCDN) de Salesforce (con tecnología de Cloudflare) o elegir una CDN de un proveedor diferente.

Para utilizar la eCDN para enrutar el tráfico a Managed Runtime, utilice el punto de conexión API de Commerce createMrtRules.

La API admite el enrutamiento del tráfico a Managed Runtime utilizando Expresiones de reglas de Cloudflare. Admite un subconjunto de los campos disponibles en el lenguaje de Reglas. Se admiten los siguientes campos:

• http.host para que coincida con el nombre del servidor.
• http.request.uri.path para que coincida con la ruta de acceso de la solicitud.
• http.request.uri para que coincida con la ruta de acceso de la solicitud y la cadena de consulta.
• http.cookie para que coincida con las cookies.

Puede solicitar 100 reglas individuales por instancia en las zonas proxy y 100 reglas individuales en total compartidas entre las instancias de Desarrollo (Development) y Producción (Production) en las zonas heredadas.

• La eCDN solo está disponible para las instancias de Producción (Production) y Desarrollo (Development) y no está disponible para las instancias de sandbox u ODS.
• Las instancias de Presentación (Staging) deben incorporarse a la eCDN utilizando la API de la eCDN. Para obtener más información, consulte Configuración de eCDN para Presentación (Staging) en el Infocenter de B2C Commerce y este artículo del blog Rhino Inquisitor.
• La eCDN no admite el enrutamiento en función de la geolocalización.

Para ayudar a diseñar sus reglas de origen, recopile 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:

Genere una regla de origen que incluya todas las rutas de PWA Kit en su lista para que envíe la solicitud al entorno de Managed Runtime (mystorefront.mobify-storefront.com en nuestro escenario de ejemplo).

El siguiente diagrama muestra la configuración de eCDN para el escenario de ejemplo que describimos anteriormente:

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, si su proyecto de PWA Kit se generó con la versión 2.7.x o versión 3.x de la plantilla de la Retail React App sin utilizar extensibilidad: retire finalizar la compra (checkout) de la matriz de rutas.

Si su proyecto de PWA Kit se generó con la versión 3.x de la plantilla de la Retail React App utilizando extensibilidad, puede reemplazar el archivo overrides/app/routes.jsx para filtrar los vínculos a páginas que no sean de PWA Kit utilizando javascript. Hemos creado un reemplazo de ejemplo del archivo overrides/app/routes.jsx con todos los cambios aplicados para filtrarlas rutas de /cart y /checkout y lo hemos publicado en GitHub a través de una esencia pública.

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

Para las instancias de PIG, los clientes pueden utilizar eCDN para "dividir" el tráfico entre los orígenes SFRA (o SG) y MRT. Sin embargo, la eCDN no admite las instancias de SIG ni ODS. Para configurar y probar los sitios de lanzamiento por fases localmente en instancias de SIG, los clientes deben utilizar su propio proxy de reserva o CDN para dividir el tráfico.

Hemos creado una aplicación de Node.js de muestra que se puede utilizar para desarrollar y probar flujos de compradores de implementación híbrida en PWA Kit y SFRA/SiteGenesis. Las instrucciones de ajustes y configuración para configurar el método de reserva se mencionan en el archivo README para el repositorio.

Hemos compilado un video de demostración que muestra los pasos para configurar lanzamientos por fases en instancias de SIG:

Puede configurar su ODS para utilizar una configuración de alias que sea similar a su configuración de Producción (Production), lo que puede ayudar a que sus configuraciones local y de Producción (Production) sean idénticas. Por ejemplo, al configurar su sandbox para que su sitio híbrido esté disponible en la URI /, se asegura de que las URL enviadas por PWA Kit no deban traducirse para incluir la identificación del sitio. Así es como normalmente se configura un sitio de Producción (Production).

Para habilitar los alias en Business Manager, siga las instrucciones en este módulo para Alias del nombre del servidor de Salesforce B2C Commerce en Trailhead.

Puede configurar sus rutas de PWA Kit para prefijar que todas las URL salientes (por ejemplo, las diseñadas para SFRA) incluyan el prefijo /s/SiteID. Esto garantiza que su instancia reciba las URL de controller de una manera generalmente utilizada en los sandboxes sin necesidad de configurar explícitamente los alias del nombre del servidor. Tenga en cuenta que esto podría no ser apropiado para la configuración de Producción (Production), por lo que quizás debería tener una ruta de dirección predeterminada diferente para las implementaciones de Producción (Production) frente a las de sandbox.

Para configurar los prefijos de las rutas, actualice la ruta de dirección predeterminada de PWA (/*) en app/routes.jsx o overrides/app/routes.jsx.