Dans cet article, nous décrivons une approche pour orchestrer un flux de travail de recherche dans Apache Solr en utilisant des Invisible Queries.
Qu'est-ce que sont les "Invisible Queries" ?
Voici un extrait d’un article [1] sur Lucidworks.com, rédigé par Grant Ingersoll, parlant des “invisible queries” :
“Il est souvent nécessaire dans de nombreuses applications d’exécuter plusieurs requêtes pour une requête utilisateur donnée. Par exemple, dans les applications qui nécessitent une très haute précision (uniquement des bons résultats, en négligeant les résultats marginaux), l’application peut avoir plusieurs champs, un pour les correspondances exactes, un pour les correspondances sans tenir compte de la casse, et un autre avec le “stemming”. En fonction de la requête utilisateur, l’application peut d’abord essayer la requête sur le champ exact, et si des résultats sont trouvés, elle retourne uniquement cet ensemble. Si aucun résultat n’est trouvé, l’application passe à la recherche dans le champ suivant, et ainsi de suite.”
source: Lucidworks
Cette phrase décrit un scénario où l’application (côté client) envoie plusieurs requêtes successives à Solr pour une seule requête utilisateur (c’est-à-dire une requête utilisateur = plusieurs requêtes sur le moteur de recherche).
Et si vous n’avez pas un tel contrôle ?
Imaginez que vous êtes l’ingénieur de recherche d’un portail e-commerce construit avec Magento ; quelqu’un a installé et configuré le connecteur Solr et tout fonctionne : lorsque l’utilisateur soumet une recherche, le connecteur envoie la requête à Solr, qui exécute la recherche.
Contexte
Maintenant, imaginez que la requête ci-dessus ne retourne aucun résultat. L’interaction complète de la requête/réponse est terminée, et l’utilisateur voit quelque chose comme “Désolé, aucune correspondance pour votre recherche.”
Bien que cela puisse sembler parfaitement raisonnable, dans cet article, nous allons nous concentrer sur une approche différente basée sur les “invisible queries”. Le point principal ici est une condition préalable : je ne peux pas changer le code du client. Cela est dû à (par exemple) :
- Je ne veux pas introduire de code personnalisé dans mon instance Magento / Drupal.
- Je ne connais pas PHP.
- Il n’est pas possible de mettre en œuvre ce flux de travail côté client.
- Je veux déplacer autant que possible la logique de recherche dans Solr.
Ce que je voudrais, c’est un seul point d’entrée (c’est-à-dire un seul gestionnaire de requêtes) exposé à mes clients. Ce point d’entrée devrait être capable d’exécuter un flux de travail comme celui-ci :
Le CompositeRequestHandler
Apache Solr implémente le concept de point d’entrée par le biais d’un composant appelé RequestHandler. Vous pouvez avoir plusieurs instances de RequestHandler dans la configuration, fournissant ainsi plusieurs points d’entrée.
L’idée est de fournir un gestionnaire de requêtes Facade capable de chaîner plusieurs autres gestionnaires ; la configuration ressemblerait à ceci :
/rh1,/rh2,/rh3
/rh1, /rh2, et /rh3 sont des instances standards de SearchHandler déjà déclarées et chaînées de manière séquentielle comme indiqué dans le flux de travail ci-dessus.
L’implémentation du CompositeRequestHandler est en réalité simple : sa méthode handleRequestBody exécute, de manière séquentielle, les gestionnaires configurés et interrompt la chaîne d’exécution après avoir reçu la première réponse positive de la requête (généralement, il s’agit d’une réponse de requête avec numFound > 0, bien que la dernière version du composant permette de configurer d’autres prédicats). La logique ressemblerait à ceci :
Vous pouvez trouver le code source du CompositeRequestHandler ici. Comme d’habitude, tous les retours sont les bienvenus !
