Mise en cache REST Emerald sur le serveur TS pour Commerce 9.1

Mise en cache sur l'application TS d'Emerald

Les URL suivantes sont mises en cache sur 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 

Seules quelques URL mises en cache requièrent la méthode d'invalidation, qui est activée. L'URL de stock est l'URL critique, qui est mise en cache et nécessite un déclencheur de mise en cache pour la maintenir à jour avec le stock réel du système.

Activation du cache REST pour Emerald

L'exemple cachespec.xml qui définit les règles est fourni dans le fichier :

Pour activer la mise en cache, vous devez effectuer les actions suivantes :

Mise en cache du magasin et du stock Emerald

Le stock du produit est implémenté en tant qu'appel REST distinct vers le serveur TS-app dans le magasin Emerald, qui est un magasin basé sur REST. Cet appel est soumis directement depuis le navigateur vers TS-app, en contournant la couche CDN. Les performances du magasin seront considérablement améliorées grâce à la mise en cache de cet appel. Bien que l'appel puisse être mis en cache sur le CDN, le contenu sera temporaire et la stratégie d'invalidation sera provisoire. La mise en cache sur l'appserver, d'autre part, est beaucoup plus polyvalente et permettra aux techniques d'invalidation de répondre aux besoins métier et de conserver les données à jour au fil du temps.

Modèle de stock et opérations

En général, le stock/la quantité est mis à jour régulièrement à partir de l'interaction back-end et utilisateur avec le système (lors de la soumission de la commande).

Les mises à jour quotidiennes et les flux directs s'exécutent sur la base de données de production, ce qui entraîne des ajustements de stock. Les déclencheurs doivent suivre ces modifications en fonction des règles de suivi du stock. En d'autres termes, le flux de stock sera traité de la même manière que lorsque l'utilisateur navigue et achète des articles du stock.

Lors de la navigation, les données de la page de navigation vérifient les informations de stock/d'inventaire pour s'assurer que l'utilisateur final reçoit des informations précises.

1. Le comptage du stock passe d'un nombre positif à zéro (le produit est vendu/le stock est épuisé).
2. Le comptage du stock passe de zéro à un nombre positif (un nouveau stock est arrivé dans le système)

En d'autres termes, le stock peut être mis en cache jusqu'à ce qu'il soit en rupture de stock, auquel cas il doit être invalidé, OU le stock peut être stocké jusqu'à ce que le flux dorsal place l'article en stock.

Il peut y avoir un cycle de vie un peu plus compliqué du contenu mis en cache comme :

1. En stock
2. Stock faible (où le stock est plus petit qu'une certaine valeur).
3. Rupture de stock.

Bien sûr, nous de devons invalider le stock lors de son passage dans chacune de ces conditions :

1. Le stock passe à la valeur LowStock (nous n'avons pas vraiment besoin de suivre si cela s'est approché d'une valeur élevée ou basse).
2. L'inventaire passe d'une valeur positive à zéro.
3. L'inventaire passe de zéro à une valeur positive.

Dans la stratégie d'invalidation de stock, ce mode d'opération et cette logique doivent être suivis. Le mécanisme de suivi et d'émission du message d'invalidation vers le reste du système doit être intégré aux déclencheurs de mise en cache dans ce cas spécifique.

Mises à jour quotidiennes

Les mises à jour quotidiennes et les flux directs fonctionnent sur la base de données de production et peuvent entraîner des modifications dans la table de stock de la base de données. Etant donné que les déclencheurs de mise en cache de cette table de stock seront actifs, les opérations de modification de flux de données seront traitées au même emplacement et de la même manière que les activités de navigation et de réservation des utilisateurs sur le stock.

Dépendances et invalidations du cache

La conception des dépendances et des invalidations est définie par l'implémentation réelle du site Web. Les appels de stock sur le serveur TS-app, par exemple, sont des appels REST qui peuvent être directement invalidés ; mais, si le stock est affiché sur les pages de réponse de recherche, le cache sera vidé complètement.

Déclencheurs de cache de stock

HCL Commerce prend en charge divers types de stock. Toutefois, les déclencheurs présentés ici concernent le stock non ATP, qui dispose d'un modèle plus simple et est plus largement utilisé.

Déclencheurs conditionnels

Les déclencheurs ne doivent se déclencher que si la condition est remplie, c'est-à-dire qu'ils ne doivent être insérés dans la table CACHEIVL que si la condition est remplie. Ceci est obtenu avec la clause when dans le déclencheur :

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

La clause du premier cas où nous avons uniquement en stock et en rupture de stock ressemblerait à ce qui suit :

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

Ou la définition du déclencheur ressemblerait à ce qui suit :

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

Lorsque nous avons 3 niveaux de stock, comme en stock, en stock faible et en rupture de stock :

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

Conseils sur la façon d'implémenter des conditions spéciales

L'exemple ci-dessous montre comment configurer des déclencheurs sur une table de stock. Le déclencheur insère des messages d'invalidation dans l'ivl de cache pour les objets suivants, en plus des clauses de déclenchement qui suivent la logique métier :

1. Niveau de SKU.
2. Niveau du produit.
3. Niveau du bundle.

--#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#

Les trois insertions dans le déclencheur correspondent aux 3 objets possibles qui peuvent avoir été affectés par l'enregistrement de table de stock. Le déclencheur fourni s'applique directement à la base de données DB2 et, avec des modifications minimales, il peut également être appliqué dans la base de données Oracle. Aucune autre modification n'est nécessaire et les invalidations commenceront à fonctionner une fois le déclencheur en place.