Amélioration des performances pour un grand panier

Les commandes de panier suivantes ont été optimisées pour les performances : OrderItemAdd, OrderItemUpdate et OrderItemDisplay. Ces modifications optimisent les commandes afin que les gains de performances puissent être réalisés, en particulier dans les cas où les paniers contiennent généralement des centaines d'articles de commande.

Auparavant, chaque fois que ces instructions étaient appelées, elles effectuaient un calcul des prix, vérifiaient l'inventaire et mettaient à jour l'allocation de l'inventaire. Lorsque le panier contient de nombreux articles de commande, cela nuit aux performances. A présent, ces commandes disposent de deux nouveaux paramètres, doPrice et doInventory, qui servent à activer ou désactiver les sous-tâches de prix et d'inventaire.

Bien que ces sous-tâches soient importantes, elles peuvent être appelées moins fréquemment pour réaliser des gains de performances sans nuire à l'intégrité de la commande ou de l'inventaire. Par exemple, vous pouvez diviser les appels vers les sous-tâches entre les commandes de la manière suivante :

Instruction de commande Sous-tâche effectuée
OrderItemAdd Calcul du prix
OrderItemUpdate Mise à jour des informations sur les articles d'une commande
OrderPrepare Calcul du prix, vérification et répartition de l'inventaire, calcul des frais de port et des taxes

Les instructions suivantes activent ou désactivent le calcul du prix.

  • OrderCalculate
  • QuoteItemAdd
  • QuoteItemUpdate

Limitations de cette solution :

  1. Les clients ne voient pas instantanément les répercussions sur les changements de prix, les changements de désignation des produits ou les changements de niveau d'inventaire lorsque les sous-tâches de prix et d'inventaire sont désactivées dans certaines URL.
  2. Si le client crée un panier, ne le soumet pas mais revient plus tard, le prix est obsolète. Dans ce cas, le prix s'actualise toujours. Cependant, comme ce n'est pas courant, il y a peu d'impact sur les performances.
  3. Lorsque QuoteGoodFor est petit, la suppression des sous-tâches de calcul du prix n'améliore pas les performances. Le prix s'actualise toujours lorsque le prix indiqué expire.

Les performances des instructions OrderItemAdd, OrderItemUpdate, QuoteItemAdd et QuoteItemUpdate sont encore améliorées en supprimant certaines boucles inefficaces lorsqu'elles appellent les autres instructions de travail.

Invalidation des prix expirés

Si un client ajoute un article au panier, le prix est calculé. Toutefois, si la commande n'est pas soumise pendant une longue période, le prix de l'offre a peut-être déjà changé, ce qui rend le prix calculé pour le panier invalide. Dans ce cas, le prix doit être recalculé lorsque le client accède à nouveau au panier. Pour permettre cela, un nouvel indicateur de bit dans ORDERITEMS.PREPAREFLAGS appelé PREPAREFLAGS_PRICE_REFRESHED est introduit. Les instructions OrderItemBaseCmdImple et OrderCalculate appellent une nouvelle instruction de travail, CheckAndResetOrderItemPriceFlagCmd, qui vérifie si le prix est expiré. Si le prix est expiré, le prix est recalculé.

L'implémentation par défaut de ce nouveau travail est définie comme suit :

  1. Si STORE.PRICEREFFLAG correspond à "8", le travail regroupe tous les articles de commande avec le même catentryId.
  2. Si l'un des articles de commande d'un catentryId donné est expiré ou que son indicateur de prix binaire (PREPAREFLAGS_PRICE_REFRESHED) est 0, le travail réinitialise l'indicateur de prix pour tous les articles de commande avec le même catentryId.
  3. Si STORE.PRICEREFFLAG n'est pas "8", le travail vérifie si chaque article de commande a été expiré. Si tel est le cas, il réinitialise l'indicateur de prix binaire pour l'article de commande.

Ceci est exprimé par la formule suivante :

Si STORE.QUOTEGOODFOR (unité : seconde) <= (CurrentTime - ORDERITEMS.LASTCREATE)/1000 (unitéde temps : milliseconde), orderitem est indiqué comme étant expiré.

Si le nouveau calcul des prix est désactivé lors de la mise à jour des prix pour les articles de commande, les commandes OrderItemAdd, OrderItemUpdate, OrderItemDisplay et OrderCalculate vérifient l'indicateur de PREPAREFLAGS_PRICE_REFRESHED bit. Si l'indicateur est 1, le prix de l'article de commande n'est pas actualisé. Si l'indicateur est 0, le prix est actualisé et l'indicateur est défini sur 1.

Vous pouvez personnaliser l'instruction de travail CheckAndResetOrderItemPriceFlag pour implémenter votre propre logique afin de réinitialiser l'indicateur PREPAREFLAGS_PRICE_REFRESHED.

Optimisation du calcul des frais de port et des taxes

Les taxes et les frais de port sont évalués différemment. Cela conduit à une amélioration des performances de l'instruction OrderPrepare, qui appelle les calculs des taxes et des frais de port.

Dans la plupart des implémentations de taxes et de frais de port, beaucoup de règles sont configurées pour un même code. En règle générale, chaque règle de calcul des frais de port est spécifique à une seule combinaison d'un centre de distribution, d'un mode d'expédition et d'une juridiction d'expédition. De même, les règles de calcul des taxes sont spécifiques à une combinaison unique d'un centre de distribution et d'un TaxJurisdictionGroup. Pour chacune de ces règles, une instruction est appelée pour évaluer si la règle s'applique à un article du panier.

Les implémentations de commande, FastShippingRuleCombineCmdImpl et FastTaxRuleCombineCmdImpl, sont destinées à être utilisées par les magasins qui possèdent un grand nombre de règles d'expédition ou de taxe.

  • FastShippingRuleCombineCmdImpl regroupe les articles de commande en fonction de leur ShipMode, shipAddress et fulfillmentCenter, puis détermine si une règle d'expédition spécifique s'applique au groupe.
  • FastTaxRuleCombineCmdImpl regroupe les articles de commande en fonction de leur code de taxe, centre de distribution, adresse d'expédition (juridiction) et de leur catégorie de taxe, puis détermine si une règle de taxe spécifique s'applique au groupe.

Le cache est également amélioré pour améliorer la logique de recherche de règles. Chaque fois que le système trouve les règles d'expédition correspondant à un code d'expédition, par exemple, les données peuvent être obtenues à partir du cache selon le code d'expédition, le mode d'expédition, le centre de distribution et l'adresse d'expédition (juridiction). Pour le calcul des taxes, les règles peuvent être obtenues à partir du cache selon le code des taxes, le centre de distribution, l'adresse d'expédition (juridiction) et la catégorie de taxe.

Cette solution améliore les performances dans les scénarios suivants :

  1. Il existe de nombreuses règles définies pour l'expédition ou les taxes, et en supposant que chaque article de commande ne serait admissible qu'à un petit sous-ensemble de ces règles.
  2. Pour un grand panier, si la plupart des articles de commande sont expédiés à la même adresse, en utilisant le même mode d'expédition (seulement pour l'expédition), et que l'inventaire est attribué dans le même centre de distribution.

Optimisation des principales instructions de flux d'achat

Les grands paniers ont les caractéristiques suivantes :

  • Lors de l'importation de la vaste configuration des articles dans le panier, les paramètres d'entrée sont des références et non des ID d'entrée de catalogue car le fichier XML de configuration est généré par un outil externe.
  • De nombreuses références sont dupliquées. Ces articles avec les mêmes références sont regroupés dans différentes configurations.
  • Lorsque vous appelez l'instruction OrderItemUpdate pour mettre à jour le panier, les quantités de la plupart des articles de commande ne sont pas modifiées. Dans la plupart des cas, elle ne modifie que les adresses et modes d'expédition.

Ces hypothèses ont été à la base de l'optimisation des instructions OrderItemAdd et OrderItemUpdate.

Le code par défaut contient une boucle qui itère pour chacun des articles séparément, à chaque ajout ou mise à jour d'articles de commande. Actuellement, lorsque plusieurs articles sont ajoutés au panier, chaque article de commande distinct est traité à l'aide de cette logique :

  1. Si vous avez passé un ID de référence, remplacez la référence par un  ID d'entrée de catalogue.
  2. Appelez l'instruction de travail ResolveSku pour résoudre le SKU.
  3. Vérifiez la désignation des produits.
  4. Vérifiez si le produit est vendable.
  5. Créez l'article de commande dans la base de données.
  6. Résolvez la référence à partir de l'ID d'entrée de catalogue et mettez à jour la référence dans orderitem.
  7. Mettez à jour d'autres champs de l'article de commande.
La logique de commande a été améliorée :
  1. Résolvez les références à partir des ID d'entrée de catalogue pour tous les articles, en ignorant toutes les références en double qui ont déjà été résolues.
  2. Résolvez les SKU pour tous les articles, en ignorant tous les SKU en double qui ont déjà été résolus.
  3. Vérifiez la désignation du produit pour tous les articles, en ignorant tous les articles en double pour lesquels la désignation a déjà été déterminée.
  4. Déterminez si le produit est vendable pour tous les articles, en ignorant tous les articles en double.
  5. Créez tous les articles de commande dans la base de données.
  6. A moins que la référence ne soit fournie en tant que paramètre d'entrée, résolvez la référence à partir de l'ID d'entrée de catalogue et mettez à jour la référence de l'article de commande. Celle-ci est souvent fournie par des outils de configuration externes ; l'étape peut donc être ignorée dans ces cas.
  7. Mettez à jour d'autres champs pour tous les articles de commande.

En outre, ces changements améliorent les performances du grand panier :

  1. Si les paramètres d'adresse ne sont pas transmis, ils sont résolus une fois et appliqués à tous les articles de commande.
  2. Si le paramètre de mode d'expédition n'est pas transmis, il est résolu une fois et appliqué à tous les articles de commande.
  3. Pour l'instruction OrderItemUpdate, si tous les paramètres de quantité passés correspondent à ceux de la base de données - à moins qu'il n'y ait une vérification des prix ou de l'inventaire - le prix et l'inventaire ne changent pas. Cela se produit lorsque certaines mises à jour sont effectuées, telles que la modification de l'adresse d'expédition ou du mode d'expédition.