Indexation des prix des contrats dans HCL Commerce Search

Vous pouvez indexer les prix dans HCL Commerce Search. Par exemple, vous pouvez générer l'index de prix HCL Commerce Search en émettant l'appel RESTful Calculer le prix, puis en indexant les prix des contrats.

Les prix dans HCL Commerce Search

Les prix qui sont renvoyés par HCL Commerce Search sont indexés ou calculés :

Les prix de l'offre, ou prix des contrats par défaut, sont indexés directement à partir du contrat par défaut du magasin propriétaire.
Les prix de liste sont indexés directement à partir des tables de base de données LISTPRICE ou OFFER, en fonction de la source des prix.
Les prix des contrats sont calculés en fonction du contrat choisi. Elles sont ensuite indexées et stockées dans l'index Prix désigné de HCL Commerce Search. Ces données sont ensuite copiées dans l'index Produit à utiliser avec l'API de service Query pour le filtrage, le tri et l'affichage.
Note: Cette opération de copie n'a lieu que lorsque le prix du contrat nouvellement calculé est différent du prix précédemment calculé. La raison consiste à éviter toute mise à jour inutile de l'index Produit.

Les prix indexés sont renseignés rapidement, mais pas évalués dynamiquement. Pour garantir que la vitrine affiche des prix précis, ajustez la fréquence de l'opération de calcul des prix en fonction de vos besoins professionels.

Lorsque vous utilisez des prix et des devises dans HCL Commerce Search, une colonne d'index distincte est utilisée par défaut pour gérer plusieurs devises.

Indexation des prix

Vous pouvez calculer et indexer les prix à l'aide de l'appel RESTful Index de génération. Pour plus d'informations, voir Création de l'index Elasticsearch.
L'appel RESTful Calculer le prix met à jour les informations de l'index de prix à la demande en cas de nécessité en fonction du modèle de tarification utilisé par votre magasin. L'instruction de travail ContractPriceCalculate est utilisée pour calculer les prix selon une planification pour toutes les entrées de catalogue qui appartiennent à un catalogue principal. Le prix d'entrée du catalogue est calculé pour tous les contrats qui appartiennent au magasin. Pour plus d'informations, voir Création et planification du travail ContractPriceCalculate .
Lors de l'indexation des prix des contrats, assurez-vous que la valeur de wc.search.priceMode.compatiblePriceIndex est définie sur 1.0 dans le tableau STORECONF :
```
 insert into storeconf(storeent_id,name,value) values('storeent_id', 'wc.search.priceMode.compatiblePriceIndex', '1.0'); 
```

Calcul des prix

Les prix peuvent être calculés soit intégralement, soit pour une entrée de catalogue, un contrat ou une devise spécifique. Le calcul est effectué en tant que travail en arrière-plan sur le serveur de transactions. Cette tâche peut prendre un temps considérable en fonction du nombre de contrats impliqués et de la taille de chaque liste de prix. Seul le statut de la soumission du travail de calcul du prix elle-même est renvoyé initialement, et non le statut de l'ensemble de la tâche de calcul du prix.

Logique des recalculs des prix complets

Le recalcul des prix utilise les contrats de magasin actuels et futurs qui partagent le catalogue principal.
Seules les devises prises en charge pour tous les magasins actifs identifiés dans le catalogue principal sont respectées, tandis que les autres sont ignorées et ne sont pas indexées. Cette restriction existe parce que les prix sont recalculés au nom de l'administrateur de site, et ne peut donc pas calculer les prix au niveau du segment de clientèle.
Par défaut, les calculs de prix sont basés soit sur une unité de mesure (kilos, caisses, lots) qui a une quantité numérique de base de 1, soit sur une unité de C62. C62 est utilisé pour signifier les éléments qui ne sont pas comptés selon une unité de mesure distincte. Par exemple, les chemises ne sont généralement pas mesurées en kilos, mais en quantité. Leur unité de mesure peut être définie sur C62. L'une des limites de cette approche est que toute tarification par étape, c'est-à-dire basée sur la quantité, est ignorée.
Tip: Vous pouvez contourner cette limitation en définissant explicitement C62 comme ayant une valeur de 1, puis en définissant une unité basée sur C62 qui peut être multipliée. Par exemple, la requête SQL suivante crée une nouvelle unité, CS, basée sur C62, qui peut être multipliée pour permettre une tarification par étape ou par quantité.
```
INSERT INTO QTYCONVERT VALUE('CS',1,'C62',1,'M','N',0);
```

Logique des recalculs

Les ID de contrat ne sont pas validés lorsqu'ils sont transmis en tant que paramètre distinct.
Tous les contrats expirés et suspendus peuvent être supprimés en toute sécurité de l'index Prix. Cela permet d'éviter de copier à nouveau les données de prix des contrats expirées dans l'index Produit.
Si un contrat est suspendu et inactif, le prix des contrats est supprimé. Si un utilisateur professionnel reprend le contrat et qu'il redevient actif, le prix n'est pas indiqué dans la vitrine tant qu'il n'est pas calculé à nouveau pour le contrat repris.
Lorsqu'un produit, un contrat ou une devise non valide est transmis, la logique l'ignore et n'indexe donc pas les valeurs non valides.
Si un contrat transmis est expiré ou suspendu, il est supprimé et purgé du résultat de calcul. Dans le cas contraire, si un contrat qui sera actif à une date ultérieure est transmis, il est indexé. C'est-à-dire, même s'il n'est pas actuellement actif au moment du recalcul des prix.
Les paramètres storeId et de devise ne peuvent pas être spécifiés avec d'autres paramètres.

Transaction server et processus NiFi

Transaction server

Lorsque le Transaction server reçoit une commande d'importation/de génération de données, il lance des unités d'exécution de tâche pour traiter préalablement toutes les données de prix du contrat. La commande qui lance ces processus est :
```
POST: https://CommerceServerName:ts-app-port/wcs/resources/admin/index/dataImport/build?connectorId=price&indexSubType=Price&storeId=12
```
```
POST: https://CommerceServerName:ts-app-port/wcs/resources/admin/index/dataImport/build?connectorId=auth.price&indexSubType=Price&storeId=12
```
Cette commande prend deux paramètres supplémentaires.
numWorkers
Contrôle le nombre d'unités d'exécution de tâche à utiliser pour le calcul du prix du contrat de prétraitement.
flushSize
Contrôle la taille de chaque corps de requête lors de l'envoi à NiFi.
Une fois le prétraitement effectué, le résultat est stocké dans les tableaux de base de données TI_OFFER et TI_OFFERPRICE. A ce stade, toutes les unités d'exécution d'agent sont arrêtées et le flux principal transmet le résultat à NiFi, à l'aide du paramètre flushSize pour déterminer la taille de chaque charge de requête. La valeur par défaut de flushSize est 1000.

Chaque requête de prix calculée (avec une taille par défaut de 1 000) est envoyée au connecteur NiFi Auth.price.
Dans ce connecteur de prix, le fichier de flux est transformé en une demande en masse à envoyer à l'index Auth.price Elasticsearch.
A ce stade, alors que la liste des catentries est toujours présente dans le flux de données, CopyLink utilise cette liste d'ID pour déterminer s'il faut copier réellement dans l'index Produit ou non. Seuls les numéros mis à jour sont copiés, au lieu de copier tout le reste.
- Le processus attend que la copie soit terminée avant de continuer.
- Le flux de données avec l'ID d'exécution en cours se termine à l'étape terminale et est éliminé via le service de terminal, qui produit une entrée dans l'index de journal dans Elasticsearch.
Le serveur de transactions reçoit la commande d'importation/de génération de données et lance des unités d'exécution de tâche pour traiter préalablement toutes les données de prix du contrat.

En outre, vous devez utiliser la commande suivante pour interroger le statut de ce calcul de prix à partir de Transaction server au lieu du nœud final Ingest de Search. Par exemple :

https://TSHost:TSPort/wcs/resources/admin/index/dataImport/status?jobStatusId=100

Aperçu de l'espace de travail

Lorsque vous utilisez l'aperçu de l'espace de travail :

Les prix B2B affichés dans l'aperçu du magasin ne proviennent que du contenu approuvé.
Les prix futurs peuvent être prévisualisés si le contrat futur approprié est indexé. La date future est respectée dans le contexte de la prévisualisation et montre le affiche correct pour l'affichage.
Les prix ne peuvent pas être associés à du nouveau contenu non approuvé, tels que l'aperçu d'un nouveau produit non approuvé qui n'appartient à aucun contrat.
Lorsqu'un utilisateur professionnel modifie le prix du contrat et souhaite prévisualiser ces modifications dans l'aperçu du magasin de l'espace de travail. Sans recalcul, ces modifications ne peuvent pas être prévisualisées. Vous devez exécuter le recalcul des prix contractuels pour capturer les prix modifiés dans l'index Prix, qui est ensuite recopié dans l'index Produit. Cette opération permet aux produits concernés de suivre les nouveaux changements de prix liés aux contrats.