Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Endeca: Les pipelines dont une dimension est déclinée dans un grand nombre de variants

Poster un commentaire

Le problème que nous avons à résoudre est celui d’une entreprise qui dispose d’environ 300 sites physiques en France.
Chaque site a sa liste de produits et surtout le prix d’un produit peut dépendre du site.

La société souhaite une présence sur Internet et nous demande de créer un site. Par défaut on devra toujours sélectionner un centre physique pour naviguer sur le site Internet (on a créé un centre fictif par défaut). Donc on ne voit à un instant donné que les prix et produits de ce centre.

Il nous faut répondre aux besoins métiers suivants sur le site Web:

  • afficher le prix de chaque produit
  • naviguer par plage de prix (dimension de type range)
  • faire une recherche de produits en fournissant un prix minimal et maximal

Nous allons essayer d’examiner deux possibilités dans cet article.

Première solution

Les sites sont repérés par un code numérique. Par exemple 123, 423…

  • Nous avons créé une propriété de prix spécifique pour chaque centre (sites):

31-01-2014 15-21-46

Les propriétés sont filtrables et visibles en liste aussi bien qu’en détail produit:

31-01-2014 15-21-46

Du côté des dimensions nous avons fait de même:

31-01-2014 15-21-46

Répondons nous à la demande?

  • On peut afficher les prix dans tous les formulaires via la propriété de prix
  • on peut faire une recherche en fournissant des valeurs de bornes puisque les propriétés sont filtrables
  • on peut naviguer par plage de prix grâce à la dimension de prix qui est de type range

Vérifions que cela marche. Dans mon POC je n’ai activé que quelques centres:

31-01-2014 15-37-02

Si je clique sur la plage 50 à 100:

31-01-2014 15-36-38

La navigation a bien effectuée son travail de filtrage. Toutes les dimensions hors centre 200 ont disparues.

Faisons une requête de filtrage, par exemple: Nf=produit.PrixTTC.200|GT+100

Nous retournons bien les produits dont le prix est > 100 dans le centre 200.

Tout cela fonctionne bien.

La méthode fonctionne bien. La difficulté est de renseigner les propriétés et les dimensions. J’ai procédé avec un script Powershell.
Le gros problème c’est la volumétrie d’une réponse Endeca: on remonte 300 propriétés et sur la page d’accueil autant de dimensions.

On a besoin d’un affichage, donc pas moyen de faire autrement pour les propriétés. Côté dimension on peut envisager une astuce:

31-01-2014 15-48-59

  • On créée une valeur de dimension appelée all qui recouvre la gamme complète de prix.
  • on modifie la navigation guidée pour ne pas l’afficher (si on trouve cela plus propre on peut attacher au raffinement une propriété display=false)
  • On force dans toutes les requêtes une navigation par all si une navigation par prix plus restrictive n’a pas été sélectionnée

On élimine donc les dimensions prix qui ne concernent pas le centre en cours.

Le problème avec cette méthode est que si on décide de créer une règle Experience Manager (ex Page Builder) avec un déclencheur qui spécifie une clause « At this exact location« , alors on est obligé de faire autant de versions qu’il y a de centre. Pas vraiment pratique.

Deuxième méthode

On va essayer de résoudre ces différents problèmes par une autre approche.
Cette fois au lieu de construire des centaines de dimensions, on en construit qu’une seule appelée PRIX. Il s’agira d’une dimension hiérarchique.

Le premier niveau indique les prix par centre:

31-01-2014 18-58-14

Ces valeurs de dimensions sont des dimensions par range:

31-01-2014 18-59-20

Remarquez bien qu’à ce stade nous n’avons rien fait de très utilisable. Par exemple si un produit P1 vaut 200 euros dans le centre 200 et 250 dans le centre 414 je n’ai aucun moyen de le taguer correctement vis à vis de la dimension PRIX. C’est elle que je vais retrouver dans le Property Mapper du pipeline.

On a besoin de mettre au point un encodage qui va rendre unique les leafs, c’est à dire les valeurs de dimension les plus basse de la hiérarchie. On va créer des synonymes. Voici l’encodage que j’ai utilisé, mais tout autre conviendra:

31-01-2014 19-03-47

Il n’y a plus qu’à créer les valeurs d’import dans les fichiers qui vont alimenter le flux Endeca et faire le mappage:

31-01-2014 19-05-54

Et ça fonctionne très bien:

31-01-2014 19-07-09

Le premier avantage est que l’on ne récupère pas des centaines de dimensions dès la page d’accueil. Si on connaît l’id de la dimension prix qui nous intéresse (par exemple supposons que pour PRIX.414, id = 123), alors la requête Ne=123&N=123 nous affichera la navigation guidée comme indiqué sur le schéma qui précède.

L’inconvénient est que l’on fait une navigation, comme déjà expliqué tout à l’heure cela rend plus difficile la mise au point de déclencheur « at this exact location ».

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s