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 Progressive Web App (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.

Para crear una experiencia de usuario fluida, use reglas de enrutamiento y puente de sesión para permitir que PWA Kit alimente un conjunto de páginas y SFRA alimente otro.

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

A continuación, se muestra un resumen de los pasos clave involucrados en una implementación sin encabezado por fases.

1. Configuración de SLAS para PWA Kit
2. Configuración del puente de sesión
3. Configure el enrutamiento. Consulte también API de CDN para implementaciones desatendidas por fases.
4. Instale el cartridge de redireccionamiento (opcional)
5. Haga Otros cambios a los proyectos de PWA Kit
6. Configurar implementaciones por fases localmente (opcional)
7. Obtener analítica con Einstein Activities para implementaciones desatendidas por fases (opcional)

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.

Al configurar SLAS, querrá decidir si configura un cliente público de SLAS o un cliente privado de SLAS, ya que esto afectará algunos de los pasos de configuración que siguen. Si está configurando un cliente privado de SLAS, siga los pasos descritos en Uso de un cliente privado de SLAS para configurarlo.

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 escaparate. Antes de agregar el cartridge a un escaparate de Producción (Production), compare el rendimiento de su escaparate 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 inicia sesión
• Cuando la cookie de sesión de un comprador caducó.

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 usa con el complemento de listas de deseos, las listas de deseos de invitados no se transfieren al iniciar sesión al usuario registrado.

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

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.

Habilitar que los compradores naveguen sin dificultades entre las páginas potenciales por diferentes arquitecturas de escaparate 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 puente de sesión es SLAS, una nueva solución basada en estándares para la autenticación y autorización a la que se puede acceder a través de solicitudes 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 escaparate 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. A medida que el comprador pasa de una página de SFRA a una página de PWA Kit (o viceversa), las cookies con el token de acceso y el token de actualización se envían junto con la solicitud HTTP y PWA Kit/SFRA las utiliza para heredar la misma sesión de la otra.

Para obtener más información y ejemplos de puentes de sesión, consulte Descripción general de puentes de sesión.

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 un nuevo dwsid puente después de la sesión, por lo tanto, el escaparate no requiere un nuevo renderizado y se le puede enviar una respuesta 200 OK.
2. Puente de sesión (API) de Open Commerce API (OCAPI): 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 escaparate y debe recibir una respuesta 302 - Redireccionamiento.

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 concede el nuevo token de acceso y el 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 fluida durante una implementación por fases, use una red de entrega de contenido (CDN) para enrutar el tráfico a dos orígenes diferentes: el entorno de tiempo de ejecución administrado (MRT) y su instancia de B2C Commerce.

Imagine el siguiente escenario:

Tiene un escaparate 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 escaparate 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 obtener más información sobre el enrutamiento del tráfico a MRT, consulte:

• API de CDN para lanzamiento por fases
• Certificados de TLS
• DNS CNAME
• Configuración del entorno

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:

![Diagrama]asociado(.. /.. /.. /media/pwa-kit-managed-runtime/phased-headless-cdn-routing.png '{"class": "image-framed image-lg"}')

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 escaparate 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), use 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. ![Remove-checkout-route](.. /.. /.. /media/pwa-kit-managed-runtime/phased-headless-remove-checkout.png '{"class": "image-framed image-xl"}')

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 PWA <PageNotFound /> por un redireccionamiento al origen predeterminado.

Para las instancias de PIG, los clientes pueden usar eCDN para "dividir" el tráfico entre orígenes de SFRA (o SiteGenesis) y MRT. Sin embargo, la eCDN no admite grupos de instancia secundaria (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.

En este video de demostración, se muestran los pasos para configurar implementaciones por fases en instancias de SIG.

Phased Rollouts on SIG

Puede configurar su ODS para usar una configuración de alias que sea similar a su configuración de producción. Esto puede ayudar a mantener las configuraciones locales y de producción 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.

La llamada al cierre de brechas de la sesión de OCAPI después del inicio de sesión del comprador en las páginas de PWA Kit es obligatoria para notificar a las páginas de SFRA cuando el estado de autenticación del comprador cambia en las páginas de PWA Kit. Cada vez que cambia el estado de autenticación del comprador, PWA Kit envía la nueva access_token /sessions llamada de entrada para el puente de sesión y recibe un nuevo dwsidarchivo . El dwsid valor de la cookie se actualiza con el recibido en la /sessions respuesta.

PWA Kit v3.4.0 y versiones anteriores Del mismo modo, PWA Kit conserva una copia del token de actualización en LocalStorage, que se compara con la clave y el valor del token de actualización almacenados en CookieStorage antes de cada solicitud. Si los tokens son diferentes, PWA Kit invalida la sesión actual y dispara el flujo de autorización nuevamente para mantener las sesiones sincronizadas con SFRA.

Cambios en PWA Kit v3.5.0 (commerce-sdk-react@1.4.0)
Hemos actualizado la lógica utilizada para invalidar las sesiones de PWA Kit en función del estado de autenticación del comprador en SFRA en una configuración de lanzamiento por fases. SFRA ahora almacena los SLAS access_token en una cookie con la clave access_token_sfra. Cuando un comprador navega de SFRA a PWA Kit, esta cookie se comparte con PWA Kit. Esta cookie puede contener el valor real access_token de SLAS si hay disponible un token de acceso válido. Si no es así, el valor de la cookie se establece en refresh. Si se ve un valor válido access_token , PWA Kit reemplaza el valor actual de access_token con el valor de access_token_sfra cookie. Si access_token_sfra se establece en refresh, PWA Kit activa el flujo de inicio de sesión del token de actualización para obtener un nuevo access_tokenarchivo .

Consulte getAccessToken() los detalles de la implementación.

B2C Commerce examina la secuencia de clics de la sesión asociada con el dwsiddominio . Una secuencia de clics vacía indica una nueva sesión y onSession se activa. Un valor nuevo o cambiado de la dwsid cookie no implica directamente que la sesión sea nueva.

En una configuración de lanzamiento por fases, PWA Kit llama /sessions al punto de conexión de OCAPI para unir las sesiones de B2C Commerce y SLAS cada vez que cambia el estado de inicio de sesión del comprador para notificar a SFRA del cambio de estado de inicio de sesión. El /sessions punto de conexión devuelve un nuevo valor para dwsid el que está asociado con la sesión recién puenteada y, por lo tanto, tiene una secuencia de clics vacía. Esto se onSession activa cuando un comprador navega al sitio de SFRA.

Si un comprador salta repetidamente entre los sitios de PWA Kit y SFRA, es posible que note que el dwsid valor cambia, pero aún puede estar asociado con una sesión de B2C Commerce en curso o puede tener una secuencia de clics no vacía. En esta situación, onSession el gancho no se activa.

• API de CDN para lanzamiento por fases
• Einstein Activities para lanzamientos por fases
• Primeros pasos con Composable Storefront