Indexation des données et pièces jointes

Owned by Bertrand Littel
Last updated: 06/09/2024
6 min read

SOMMAIRE

Stratégie d'indexation des documents existantes (Search_param.xml)

Introduction

Le choix de la stratégie à appliquer nécessite quelques explications :
La base Search est distincte de la base ERP. Cela pose le problème de la cohérence des informations entre les deux bases.
L'indexation des documents (tous ou en partie) peut être réalisée en différé par rapport à leur création dans l'ERP. C'est l'indexation des document par lot.
L'indexation de l'ensemble de tous les documents d'un système d'informations peut être relativement longue.
Un document Search est un agrégat complexe de données en provenance de l'ERP et aussi de pièces jointes. La modification d'un élément de cet agrégat ne peut pas forcément être identifiée de manière simple. Par exemple, la modification du libellé d'un article n'est pas signalée à toutes les commandes pour lesquelles cet article a été commandé.
C'est pourquoi différentes stratégies d'indexation des documents peuvent être mises en oeuvre lors de l'indexation par lot. Le fichier Search_param.xml contient la stratégie par défaut s'appliquant à l'ensemble des documents. Elle peut être modifiée pour chaque document.

image-20240906-120253.png

Stratégie "Always"

<IndexExistingDocument When="Always" />
Les documents déjà existants sont réindexés.
Cette stratégie assure la cohérence la plus grande entre la base de l'ERP et la base Search, mais ne peut être appliquée que pour les documents pour lesquels le temps d'indexation est « court ».

Stratégie "Modified"

<IndexExistingDocument When="Modified" />
Pour déterminer qu'un document est modifié, le serveur Search compare le champ « DateModif » du document avec celui de l'ERP. En général, ce champ correspond au champ UserMoDh de la table de base du document dans l'ERP. Si cette date est mise à jour de manière rigoureuse pour toute modification d'une des données constituantes du document, il s'agit de la stratégie idéale. En effet, l'indexation périodique ne concerne que les nouveaux documents ou les documents modifiés et est très rapide.

Stratégie "Recent"

<IndexExistingDocument When="Recent" Month="3" />
Il s'agit d'une stratégie intermédiaire entre « Toujours » et « Modifié ».
On l'appliquera aux documents pour lesquels la date de modification ne peut pas être déterminée simplement, pour lesquels une cohérence importante est exigée, mais dont le volume ne permet pas une ré-indexation complète dans des temps « courts ». La définition de « Récent » s'exprime en mois et peut-être définie pour chaque document.

Stratégie "Never"

<IndexExistingDocument When="Never" />
Elle s'applique aux documents très stables.

Indexations périodiques (Search_Scheduler.xml)

Définition d’indexations périodique

Les indexations périodiques permettent de programmer des indexations par lot à intervalle de temps réguliers. Le fichier paramètres Search_Scheduler.xml contient la liste des indexations à réaliser. Les événements à venir sont affichés dans la console Search.
Le fichier des paramètres indique la périodicité ( quand par la balise <when>) et ce qu'il faut faire ( quoi par balise <what>)

 

Choix de l’action d’indexation

Les balises <When> permettent de définir l'heure, la fréquence et les jours de la semaine (1=dimanche) de l'action.
Les sous-balises <What> permettent d'indiquer ce qu'il faut faire :

  • Indexer un document

  • Indexer un dictionnaire de documents

  • Indexer tous les documents

  • Effacer tous les index et indexer tous les documents

Console
Les indexations périodiques à venir s'affiche dans la console d'administration d'un serveur Search.. La suppression d'une indexation dans le tableau supprime la prochaine occurrence de l'action. Elle est remplacée par l'occurrence suivante. Ceci permet par exemple de "sauter" l'indexation prévue ce soir.
Relire le fichier paramètre des indexations périodiques
Ce choix doit être lancé en cas de modification du fichier paramètre Search_Scheduler.xml afin que les modifications soient prises en compte.
Exemple : Search_scheduler.xml pour une indexation totale tous les jours à 2h

Indexation journalière

La valeur "day" de l'attribut "Freq" de la balise <When> indique qu'il s'agit d'une opération journalière.
Dans ce cas ;

  • L'attribut Time définit l'heure de l'action.

  • L'attribut Freq définit la fréquence. La valeur "day" indique une fréquence journalière

  • L'attribut Day définit alors les jours de la semaine où l'action sera réalisée. Le chiffre 1 désigne le dimanche. L'ordre des chiffres n'est pas significatif.

    • "1234567" (ainsi que "7512643" ) indique que l'opération aura lieu tous les jours de la semaine.

    • "23456" indique qu'elle aura lieu tous les jours du lundi au vendredi.

    • "7" tous les samedis

 

Indexation mensuelle

La valeur "month" de l'attribut "Freq" de la balise <When> indique qu'il s'agit d'une opération mensuelle.
Dans ce cas ;

  • L'attribut Time définit l'heure de l'action.

  • L'attribut Freq définit la fréquence. La valeur "month" indique une fréquence mensuelle.

  • L'attribut Month définit alors le jour du mois. La valeur "31" correspond au dernier jour du mois quel que soit le nombre de jours que compte effectivement le mois.

 

La balise <What>

La balise <What> permet de définir les actions à réaliser. Elle est obligatoirement incluse dans une balise <When> ce qui permet de définir plusieurs actions avec la même périodicité.
L'attribut Name donne un nom qui apparaîtra dans la console. Ce nom doit être unique.

 

L'attribut Command définit l'action à exécuter:

  • "indexReference" pour un seul document

  • "indexDictionary" pour tout un dictionnaire

  • "indexAll" pour tous les documents

  • "eraseIndexAll" pour effacer la base Search et tout réindexer.

Les attributs facultatifs Dico et Ref permettent d'indiquer le nom du dictionnaire et la référence du document pour les commandes "indexReference" et "indexDictionary"

 

Indexation en "presque temps réel"

Déclenchement depuis un Zoom

Une application qui crée, modifie ou supprime un document dans la base de données peut en informer le serveur Search. Celui-ci inscrit la demande d'indexation dans une file d'attente et réalise l'opération à « temps perdu » (généralement dans les secondes qui suivent la demande). Cela présente l'avantage de ne pas perturber ou ralentir l'application en charge du document tout en bénéficiant de l'accès au document quasi immédiatement après sa création ou sa modification.
Le zoom ou zoomSql prend en charge automatiquement cette gestion (par exemple Client, Article, Contact, etc.). Il suffit pour cela d'indiquer dans les paramètres du zoom la référence du document Search dont il a la charge (par exemple, le zoom Clients gère le document Search Client). Le paramétrage est accessible depuis le menu Divalto par shift F7.
Attention : Certains Zooms sont présents plusieurs fois dans cette table en fonction du scénario d'appel.

Le menu « à propos » du Zoom permet de vérifier que ce paramétrage est actif.

Autres applications

Pour d'autres applications que le zoom, des fonctions Diva Search permettent de notifier la création, modification ou suppression d'un document au serveur.
Le développeur dispose de quelques fonctions d'interface avec le serveur Search pour déclencher l'indexation en « presque temps réel » d'un ou de plusieurs documents.
Les fonctions sont préfixées par Search. L'aide du langage Diva donne le détail des paramètres de chaque fonction.