darkBlog

Cet après-midi, j'ai eu besoin de recalculer une partie des champs calculés, aux formules assez complexes, d'un ensemble de documents (environ 2000 documents pour un bon giga-octet de données). Comme je suis de nature assez flemmarde (paraît-il que c'est une qualité en informatique), je n'avais pas spécialement envie de recopier/transposer tous les traitements en LotusScript, pas plus que je ne souhaitais recalculer l'intégralité des documents (méthode NotesDocument.ComputeWithForm()) pour des raisons d'intégrité des données (certaines formules n'avaient de sens qu'en web) comme de performances (car 10 @DbLookup par document induisent des traitements longs).

Finalement, j'ai mis en oeuvre une astuce toute bête à laquelle je n'avais jamais pensé auparavant : utiliser un masque spécifique pour le recalcul des documents. En effet, j'ai copié/collé les champs qui m'intéressaient du masque initial vers un nouveau masque de recalcul, puis j'ai simplement changé la valeur de l'item Form avant d'invoquer la méthode NotesDocument.ComputeWithForm(), pour restaurer juste derrière la valeur originale de l'item Form :

doc.Form = "form-de-calcul"
Call doc.ComputeWithForm(True, False)
doc.Form = "form-initial"

Et ça a marché. Là, comme ça, du premier coup, sans prévenir. Et sans vice caché, ni rien. La surprise s'est tout d'abord emparée de moi, pour ensuite laisser place à la félicité. A tel point que j'en ai fait un billet pour partager mon bonheur avec vous, tout en fredonnant l'air d'une publicité pour une marque de saucisses assez connue. Le développement Domino, des fois, ça peut être simple et agréable.

S'il y a quelque chose qui est toujours resté obscur pour moi dans Domino (disons, plus obscur que le reste), c'est bien son moteur de recherche interne, que j'ai toujours perçu comme une boite noire aux comportements et résultats échappant aussi bien à tout contrôle qu'à toute forme de logique. Typiquement le genre de sujet que l'on préfère éviter dans une conversation avec un client.

J'ai récemment dû - non sans crainte - me pencher sur le sujet afin d'améliorer la pertinence de la recherche dans une application. Et bien figurez-vous que j'y ai découvert deux ou trois trucs intéressants. Surtout un, en réalité : la possibilité d'effectuer une recherche dans les pièces jointes à l'aide d'une requête de recherche¹, chose que j'avais jusqu'alors toujours cru impossible.

En effet, il m'avait toujours semblé qu'il était possible de rechercher soit dans l'intégralité des documents (et donc dans les pièces jointes, mais aussi dans les champs "systèmes", ce qui peut avoir des effets de bord gênants), soit dans les champs des documents à l'aide de requêtes Lotus Notes (ex : [champ1]=val&[champ2]=val) mais sans possibilité de prendre en compte les pièces jointes.

Et pourtant, c'est tout à fait possible : il suffit d'effectuer la recherche sur le champ $FILE. La requête ci-dessus s'écrirait alors [champ1]=val&[champ2]=val&[$FILE]=val. Oui, c'est tout con. Oui, c'est écrit noir sur blanc dans l'aide. N'empêche, je viens de le découvrir après 3 ans de frustration, et je suis bien content. Voilà un premier pas vers des recherches efficaces.

On dispose désormais d'un moteur de recherche qui peut être très pertinent, ce qui est génial. Ce qui l'est moins, c'est que sa syntaxe est assez tordue ; en tout cas, bien différente (sinon opposée) à celle des moteurs de recherche courants du web. Or, un moteur de recherche pertinent mais dans lequel les utilisateurs ne retrouvent pas leurs informations faute d'une syntaxe non maitrisée, ça ne sert pas à grand chose.

Voilà quelques années, Mike Golding est manifestement arrivé à ce même constat, et a développé un parser Javascript transformant les requêtes Google en requêtes Lotus Notes. Il devient ainsi très facile de transformer, par exemple, la requête bière leffe -"vieille cuvée" en bière AND leffe AND NOT vieille cuvée. Cette première syntaxe étant plus naturelle pour la grande majorité des utilisateurs, les résultats de leurs recherches n'en sont que plus pertinents.

Le parser de Mike Golding montre toutefois ses limites lorsqu'il s'agit d'orienter ses recherches sur des champs précis (comme $FILE, à tout hasard). Je me suis donc inspiré de son travail pour écrire un parser plus complet et (je l'espère) plus efficace, que vous pouvez d'ailleurs chopper ici : GoogleToNotesSearch.js. Il suffit de l'initialiser (méthode init()) avec un tableau contenant les noms des champs à requêter, puis de transformer la requête (syntaxe Google) avec la méthode parse().

Ce sont donc les deux axes d'amélioration que j'ai proposé à la recherche de l'application suscitée, les tests que j'ai pu effectuer sont très encourageants et les premiers utilisateurs plutôt enthousiastes. N'hésitez pas à partager votre expérience avec la recherche interne de Domino, et faites moi savoir si vous appréciez (voire améliorez) le parser que j'ai (ré)écrit.

1 : pour peu que l'index fulltext intègre les attachements et utilise les filtres de conversion, cela va de soit.