Almacenamiento en caché REST de Emerald en TS Server para Commerce 9.1

Caché en la aplicación TS de Emerald

Las siguientes URL se almacenan en caché en Emerald;

/wcs/resources/store/{storeId}/adminLookup?q=findByStoreIdentifier&storeIdentifier={storename} 
/wcs/resources/store/{storeId}/associated_promotion?q=byProduct&qProductId={productId}&langId={langId
/wcs/resources/store/{storeId}/espot/{espotIdentifier}?catalogId={catalogId}&name={name}&langId={langId
/wcs/resources/store/{storeId}/inventoryavailability/{catentryId}?langId={langId} 
/wcs/resources/store/{storeId}/guestidentity?langId={langId} 
/wcs/resources/store/{storeId}/online_store 

Solo algunas de las URL almacenadas en caché requieren el método de invalidación, que está activado. La URL del inventario es la URL crítica, que se almacena en caché y requiere un activador de caché para mantenerla actualizada con el inventario real del sistema.

Habilitar la caché REST para Emerald

El ejemplo cachespec.xml que define las reglas se proporciona en el archivo:

Para habilitar el almacenamiento en memoria caché, es necesario

Emerald Store y el almacenamiento en caché del inventario

El inventario de productos se implementa como respuesta independiente al servidor de TS-app en la tienda Emerald, que es una tienda basada en REST. Esta respuesta se envía directamente desde el navegador a la aplicación TS, evitando la capa CDN. El rendimiento de la tienda mejorará significativamente si se almacena en caché esta respuesta. Aunque la respuesta puede almacenarse en caché en la CDN, el contenido que se almacene será temporal y la política de invalidación será rudimentaria. Por otro lado, el almacenamiento en caché en el servidor de aplicaciones es considerablemente más versátil y permitirá que las técnicas de invalidación satisfagan las necesidades del negocio y mantengan los datos actualizados a lo largo del tiempo.

Modelo de inventario y operaciones

En general, el inventario/cantidad se actualiza de forma periódica tanto desde el back-end como desde la interacción del usuario con el sistema (al enviar el pedido).

Las actualizaciones diarias y los canales de información directos se ejecutarían en la base de datos de producción, provocando ajustes de inventario. Los desencadenadores realizarán un seguimiento de estos cambios de acuerdo con las reglas de seguimiento de inventario. En otras palabras, el canal de información de inventario se tratará de la misma manera en la que el usuario navega y compra artículos del inventario.

Durante la navegación, los datos de la página de navegación verificarán la información de stock/inventario para garantizar que el usuario final reciba información exacta.

1. El recuento de stock pasa de un número positivo a cero (el producto se ha vendido/se ha agotado el inventario).
2. El recuento de stock pasa de cero a un número positivo (el nuevo stock ha llegado al sistema)

En otras palabras, el inventario puede almacenarse en la caché hasta que se agote, momento en el que debería anularse, O el inventario puede almacenarse hasta que el canal de información del back-end vuelva a poner el artículo en stock.

Podría haber un ciclo de vida un poco más complicado del contenido en caché como:

1. En stock
2. Stock bajo (cuando el stock es menor que algún valor).
3. Existencias agotadas.

Por supuesto, tendremos que anular el inventario a medida que vaya pasando por cada una de estas condiciones:

1. El recuento de stock desciende hasta el Valor de Stock Bajo (realmente no necesitamos comprobar si había un valor alto o bajo).
2. El recuento de inventario pasa de un valor positivo a cero.
3. El recuento de inventario pasa de cero a un valor positivo.

En la estrategia de invalidación de inventarios, se debe seguir este modo de funcionamiento y lógica. El mecanismo de seguimiento y emisión del mensaje de invalidación al resto del sistema debería integrarse en los desencadenadores de la caché en este caso concreto.

Actualizaciones diarias

Las actualizaciones diarias y los canales de información directo operan en la base de datos de producción y pueden alterar la tabla de inventario de la base de datos. Dado que los desencadenadores de almacenamiento en caché de esta tabla de inventario estarán activos, las operaciones de cambio de alimentación de datos se gestionarán en el mismo lugar y de la misma manera que las actividades de navegación y compra del usuario en el inventario.

Dependencias e invalidaciones de la caché

El diseño de las dependencias e invalidaciones está definido por la implementación real del sitio web. Las llamadas al inventario en el servidor de TS-app, por ejemplo, son llamadas de REST que se pueden invalidar directamente; pero, si el inventario se muestra en las páginas de respuesta de búsqueda, la caché se vaciará por completo.

Desencadenadores de caché de inventario

HCL Commerce admite varios tipos de inventario; sin embargo, los desencadenadores que se presentan aquí son para el inventario que no es ATP, que tiene un modelo más sencillo y es más utilizado.

Desencadenadores condicionales

Los desencadenadores deben activarse solo si se cumple la condición, es decir, sólo deben insertarse en la tabla CACHEIVL si se cumple la condición. Esto se consigue con la cláusula "when" del desencadenante:

REFERENCING OLD AS O NEW AS N FOR EACH ROW MODE DB2SQL
WHEN (clause)
BEGIN ATOMIC

La cláusula en el primer caso, en el que sólo tenemos "en stock" y "existencias agotadas", quedaría así

WHEN ((N.quantity > 0 AND O.quantity = 0) or (N.quantity = 0 and O.quantity > 0)) 

O la definición de desencadenante quedaría de la siguiente manera:

REFERENCING OLD AS O NEW AS N FOR EACH ROW MODE DB2SQL
WHEN ((N.quantity > 0 AND O.quantity = 0) or (N.quantity = 0 and O.quantity > 0)) 
BEGIN ATOMIC

Cuando tenemos 3 niveles de inventario, como en "en stock", "stock bajo" y "existencias agotadas":

REFERENCING OLD AS O NEW AS N FOR EACH ROW MODE DB2SQL
WHEN ((N.quantity > 0 AND O.quantity = 0) or (N.quantity = 0 and O.quantity > 0) OR (N.quantity = 10 and O.quantity > 10)) 
BEGIN ATOMIC

Consejos sobre cómo aplicar condiciones especiales

El siguiente ejemplo muestra cómo configurar desencadenantes en una tabla de inventario. El desencadenante insertará mensajes de invalidación en la caché ivl para los siguientes objetos, además de las cláusulas del desencadenante que siguen la lógica de la empresa:

1. Nivel de SKU.
2. Nivel de producto.
3. Nivel de paquete.

--#SET TERMINATOR #

DROP TRIGGER ch_inventory_u#
CREATE TRIGGER ch_inventory_u
AFTER UPDATE ON inventory
REFERENCING OLD AS O NEW AS N FOR EACH ROW MODE DB2SQL
WHEN ((N.quantity > 0 AND O.quantity = 0) or (N.quantity = 0 and O.quantity > 0) OR (N.quantity = 10 and O.quantity > 10))
BEGIN ATOMIC


INSERT INTO cacheivl (template, dataid, inserttime) VALUES ( NULLIF('A', 'A'),  'catentryId:'|| RTRIM(CHAR(N.catentry_id)) , current_timestamp );

INSERT INTO cacheivl (template, dataid, inserttime)
(SELECT distinct NULLIF('A', 'A'), 'catentryId:'|| RTRIM(CHAR(product.catentry_id)) , current_timestamp
  FROM  catentry sku, catentry product, catentrel
  WHERE  O.catentry_id = N.catentry_id and
         N.catentry_id = sku.catentry_id and
         sku.catentry_id = catentrel.catentry_id_child and
         catentrel.catentry_id_parent = product.catentry_id);

INSERT INTO cacheivl (template, dataid, inserttime)
(SELECT distinct NULLIF('A', 'A'), 'catentryId:'|| RTRIM(CHAR(bundle.catentry_id)) , current_timestamp
  FROM  catentry sku, catentry bundle, catentrel skutoprod, catentrel prodtobund
  WHERE O.catentry_id = N.catentry_id and
        N.catentry_id = sku.catentry_id and
        sku.catentry_id = skutoprod.catentry_id_child and
        skutoprod.catentry_id_parent = prodtobund.catentry_id_child and
        prodtobund.catentry_id_parent = bundle.catentry_id);

END#

Las 3 inserciones en el desencadenante coinciden con los 3 posibles objetos que pueden haberse visto afectados por el registro de la tabla de inventario. El desencadenante proporcionado es directamente aplicable a la base de datos DB2, y con cambios mínimos puede aplicarse también en la base de datos Oracle. No es necesario realizar más cambios y las invalidaciones se pondrán en marcha una vez que el desencadenante entre en funcionamiento.