Présentation de Divalto Power Search
Naviguer dans l'ERP, voilà tout l'enjeu de Divalto Power Search.
Divalto power Search recherche des documents dans une base de données spécialement adaptée. Il offre ainsi une vision transversale du système d'informations, qui n'est pas permise par un accès au travers d'un menu traditionnel.
La mise en oeuvre de Divalto Power Search nécessite quelques opérations de paramétrage décrites dans ce manuel, mais au préalable le chapitre d'introduction explique les notions de base nécessaires à une bonne compréhension des chapitres suivants.
Architecture de Divalto Power Search
Le moteur de recherche effectue les recherches dans une base de données spécialement adaptée à la recherche que nous appellerons la base Search. Elle est alimentée à partir des données du système d'informations de l'entreprise, qui comporte les bases de données, mais également les pièces jointes associées. Nous appellerons ces données la base ERP. La description des documents établit le lien entre les données de la base ERP et celles de la base Search.
La base Search est gérée le service DhsSearchServer..
Le client Search dialogue avec le serveur de recherche en mode client/serveur. A chaque processus de recherche client correspond un thread sur le serveur de recherche. Le serveur renvoie le résultat de la recherche vers le client.
La console d'administration XSearchConsole permet de visualiser l'activité du serveur et d'effectuer des actions (par exemple l'indexation d'un document, l'arrêt du serveur etc.)
Un même serveur peut héberger plusieurs services Search par exemple si l'on souhaite physiquement séparer les bases pour un serveur en mode ASP ou pour une application sensible comme la paie.
Documents
La base Search contient des documents.
Un document est un ensemble cohérent d'informations pertinentes pouvant faire l'objet d'une recherche.
Les documents contiennent des données que nous appellerons Field
La recherche trouve les documents correspondant aux critères de recherche ordonnés par pertinence 
La description d'un document passe par une phase de conception qui permettra de définir quelles sont les données du système d'informations qui doivent entrer dans sa composition. Divalto livre des documents standard pour l'ERP.
La description d'un document se trouve dans un dictionnaire de documents Search. Il s'agit d'un fichier au format XML.
Les documents de l'ERP Divalto sont classés par domaine fonctionnel (CRM, Commerce & logistique, Comptabilité, Production, Paie, etc.). Il existe un dictionnaire pour chaque domaine fonctionnel. Les dictionnaires standard peuvent être surchargés afin d'ajouter des données spécifiques dans les documents fournis.
A chaque document est associée une application qui s'exécute lorsque l'on double-clique dans le résultat de la recherche.
L'application est définie dans la description du document par le nom du module et de la fonction à exécuter.
Indexation
Les documents Search sont créés à partir de la base de données de l'ERP. L'opération qui consiste à ajouter un document à la base Search est appelée l'indexation du document. Elle est réalisé par le serveur Search.
Celui-ci indexe les documents selon 2 modalités :
Presque en temps réel
La ou les applications qui créent, modifient ou suppriment des données de l'ERP associées à un document Search en informent le serveur Search au moment où elles réalisent l'opération. La demande d'indexation s'inscrit dans une file d'attente des traitements à réaliser par le serveur. Celui-ci indexe le document concerné généralement dans les secondes qui suivent la demande.
Par lot
Les documents sont créés dans la base Search en temps différé, par exemple tous les soirs. Les traitements périodiques permettent de définir la fréquence et la liste des indexations à effectuer. Les stratégies d'indexation définissent l'algorithme de réindexation des documents déjà existants dans la base Search.
Architecture client serveur
Le serveur s'occupe de l'indexation et de la recherche des documents dans la base Search. Les clients interrogent le serveur ou lui donnent l'ordre d'indexer un nouveau document créé dans l'ERP. L'opération d'indexation est effectuée sur le serveur, elle n'impacte pas l'application qui crée le document dans l'ERP (par exemple, la saisie des factures, des événements de C.R.M ou le zoom Clients).
Données communes
Il existe des données communes à l'ensemble des documents :
En provenance de la description
Le domaine
La famille
Le titre
En provenance des données
Le sujet
Le dossier
L'établissement
L'auteur
La date de création
La date de modification
La date de péremption
Les données communes peuvent servir de critères de filtrage lors de la recherche.
Par exemple, rechercher uniquement les documents de type "clients", ou bien les documents de CRM des dossiers 3 et 4.
Confidentialités
La gestion de la confidentialité des documents est un élément primordial pour un moteur de recherche dans le cadre du système d'informations d'une entreprise.
Elle est gérée à 3 niveaux dans Divalto Power Search :
Au niveau de la base elle-même.
En effet, il est possible d'installer plusieurs serveurs Search indépendants sur un même site (sur un même serveur ou des serveurs distincts). Par exemple l'installation d'un serveur dédié pour la Paie préserve de tout risque d'accès à une information confidentielle pour les utilisateurs n'ayant pas accès à ce serveur.
Au niveau des documents.
Chaque document peut être protégé par une serrure pour laquelle la clé d'accès est exigée lors d'une recherche. Un document pour laquelle la clé n'est pas fournie par l'utilisateur (par exemple les avoirs aux clients) n'apparaîtra pas dans le résultat de la recherche.
Au niveau de chaque instance d'un document.
Pour un même document (par exemple les clients), l'accès peut être limité par l'ERP selon différents critères (le dossier, l'établissement, la zone géographique, etc.). Cette confidentialité est également prise en compte par le moteur de recherche. Si l'utilisateur n'a pas accès au dossier numéro 2, aucun document appartenant à ce dossier n'apparaîtra dans le résultat de ses recherches.
Voir le détail de la mise en oeuvre.
Serveur Search
Le serveur Search est un service Windows.
Un serveur Search nécessite relativement peu de ressources (sauf pour l'indexation initiale de tous les documents en cas de reprise de volumes importants) et peut généralement être installé sur le même serveur que celui de la base de données.
En effet :
La recherche consomme peu de ressources,
L'indexation par lot peut s'effectuer en dehors des heures ouvrées,
L'indexation en presque temps réel concerne généralement peu de documents chaque jour.
Remarques :
Si le serveur de base de données est déjà fortement sollicité ou si la recherche et la production de nouveaux documents constituent une activité importante de l'entreprise, on privilégiera un serveur indépendant pour la base Search.
Plusieurs serveurs Search peuvent être hébergés sur un même serveur Windows, par exemple si l'on souhaite physiquement séparer les bases pour un serveur en mode ASP ou pour une application sensible comme la paie.
Harmony Power Foundation doit être installé sur le serveur Search.
Le programme xSearchInstall.dhop (accessible aussi à partir du choix « Paramétrage » du menu de Harmony) permet d'installer un serveur Search.
Attention :
Lorsque le serveur Search est installé sur le même serveur que l'ERP Divalto, on y installera d'abord l'ERP et les bases de données.
Installation
Le programme xSearchInstall.dhop (accessible aussi à partir du choix « Paramétrage » du menu de Harmony) permet d'installer un serveur Search.
Le programme d'installation du serveur Divalto Power Search ajoute le service « Divalto DhSearchServer » aux services Windows du serveur et ajoute le raccourci vers la console d'administration du serveur au menu « Démarrer » de Windows.
L'installateur pose les questions suivantes (les réponses sont pré-garnies avec des valeurs standard) :
Paramètres éditeur
Il s'agit du chemin d'un répertoire source contenant un modèle du fichier de paramétrage du serveur (Search_param.xml), ainsi que les dictionnaires décrivant les documents. Divalto fournit ces fichiers dans le répertoire /divalto/objets/search (après l'installation de l'ERP sur un serveur). Remarque : L'environnement dans lequel s'effectue l'installation du produit est pris en compte, en particulier pour positionner le paramètre <UsersPath> (qui détermine la base de données ERP qui servira à alimenter la base de données Search) du fichier paramètre search_param.xml. Le mot clé ##cheminxlog## du fichier modèle est remplacé par le chemin du serveur xlog de l'environnement courant.
Chemin des paramètres
Il s'agit du répertoire de destination où sont stockés tous les fichiers paramètres du serveur Search. Le chemin de ce répertoire est passé en paramètre au service DhSearchServer. S'il y a plusieurs services Divalto Power Search hébergés sur le même serveur, chacun aura son propre répertoire de paramètres.
Chemin de la base Search
La base Search est stockée dans un répertoire Windows. C'est une structure arborescente de sous-répertoires.
La base de données Search est constituée à partir des données du système d'informations et de la description des documents. Sa taille dépend du volume des données à indexer ; en particulier, l'indexation de pièces jointes importantes nécessite de l'espace sur le disque.
Chemins des dictionnaires de RecordSQL
Pour créer les documents dans la base Search, Divalto Power Search accède aux tables de l'ERP au travers de RecordSQL. Des dictionnaires de RecordSQL spécifiques au Search sont fournis par Divalto avec les objets standards de l'ERP.
Si vous êtes amenés à surcharger ces dictionnaires afin d'ajouter des informations complémentaires dans les documents existants, il faudra indiquer le répertoire des dictionnaires de surcharge. Si vous avez vos propres dictionnaires, vous pouvez également les stocker dans le répertoire de surcharge.
Suffixe du nom du service DhSearchServer
Si vous installez plusieurs services Search sur le même serveur, chaque service doit porter un nom différent. On indiquera ici un suffixe permettant d'identifier chacun des serveurs, par exemple le nom du client sur un serveur en mode ASP ou PAIE s'il s'agit d'un serveur spécifique pour les documents ayant trait à la paie.
Port TCP/IP
Le client et le serveur dialoguent par le protocole TCP/IP. Le serveur « écoute » le client sur un numéro de port particulier. Le port proposé par défaut est le port 1236. Vous devez changer ce port si :
Il est déjà utilisé par une autre application.
Si vous installez plusieurs serveurs Search sur le même serveur. Chaque serveur Search doit « écouter » sur un port différent.
Le numéro de port utilisé par le serveur doit être déclaré sur le poste client, au niveau du paramétrage du serveur Search dans la table des serveurs du poste client.
Les chemins sont conservés dans le fichier Search_Param.xml situé dans le répertoire des paramètres du serveur. Il s'agit de chemins Windows qui doivent être accessibles depuis le serveur Search par le service DhSearchServer. On s'assurera que ce service puisse accéder et possède les droits d'accès à ces répertoires, en particulier lorsque le serveur Search est dédié.
Search_Param.xml
Ce fichier, situé dans le répertoire des paramètres du serveur, contient :
Le répertoire de la base Search
<Directory>
La stratégie générale de ré-indexation des documents existants dans la base Search.
<IndexExistingDocument>
Chaque document est identifié par un code unique. Ce code fait le lien avec la base de données de l'ERP. Lors de l'indexation d'un document qui existe déjà dans la base Search, quatre stratégies sont possibles :
Toujours réindexer les documents existants
Ne jamais réindexer les documents existants
Ne réindexer que les documents modifiés
Ne réindexer que les documents récents.
Cette stratégie générale peut être adaptée pour chaque document particulier.
Elle a un impact très important sur les temps d'indexation (voir les détails dans le paragraphe consacré à ce sujet).
La liste des dictionnaires de documents.
<Dictionary>
Les balises <Dictionnary> permettent d'indiquer la liste des dictionnaires de documents gérés par le serveur. Les dictionnaires eux-même doivent être dans le répertoire des paramètres du serveur. Les dictionnaires spécifiques peuvent être ajouté en plus des dictionnaires standard fournis par Divalto.
<Excluded>
Pour chaque dictionnaire, des documents ou des familles de documents peuvent être exclus.
Exemple
<Dictionary Name="Dico_Document_DAV" >
<Excluded Document="avoir_client" />
</Dictionary>
<Dictionary Name="Dico_Document_DRT" />
Le chemin des RecordSQL
<RecordSQLPath>
<RecordSQLOverwritePath>
Voir Installation
Le code utilisateur Harmony ainsi que le chemin du serveur des utilisateurs (ServeurXlogf) utilisé par le serveur pour l'indexation des documents.
Pour indexer un document, le serveur Search accède à la base de données de l'ERP (par la lecture des RecordSQL provenant de la description des documents).
Le code utilisateur indiqué ici détermine :
Les droits d'accès. Un droit d'accès complet à tous les documents à indexer est requis.
Les implicites SQL et donc la ou les base(s) de données contenant les données de l'ERP.
La balise <UsersPath> permet d'indiquer un serveur ou un chemin du fichier des utilisateurs.
Il correspond aussi au chemin du fichier Connexions.xml, qui combiné avec le fichier des implicites détermine la base de données ERP. La valeur par défaut de ce paramètre est le chemin /divalto/sys du serveur lui-même. Ce paramètre est particulièrement intéressant en mode ASP et Multi-environnements. L'utilisateur déclaré par la balise <User> doit cependant toujours être déclaré sur le serveur Search lui-même.
La balise <User> indique le code utilisateur qu'utilise le moteur d'indexation pour accéder à la base ERP. Ce sont les chemins implicites de cet utilisateur qui déterminent la base de données ERP à laquelle la moteur d'indexation.
L'option de journalisation des actions du serveur.
<Logging>
Lorsque cette option est active, le serveur Search journalise toutes les opérations d'indexation qu'il effectue. La journalisation est intéressante en phase de démarrage ou d'ajout de nouveaux documents. Elle permet également de « surveiller » l'indexation en mode « presque temps réel ».
Le journal peut être lu par la console d'administration d'Harmony (Xconsole.dhop). Il se trouve dans le répertoire du fichier des paramètres du serveur Search. Le journal permet également de connaître le temps nécessaire à l'indexation des documents.
Service DhsSearchServer
L'installateur crée puis démarre le service Windows Divalto DhsSearchServer.
En cas d'erreur de paramétrage, le service ne démarre pas. Le fichier /divalto/divaltolog/ferror.log contient le détail de l'erreur. Il est lisible par la console d'administration Xconsole.dhop. Il convient alors de corriger l'erreur puis de redémarrer le service.
Suppression (désinstallation) du service
Pour supprimer le service DhsSearchServer, lancez la commande CMD en tant qu'administrateur (voir le bandeau de l'image ci-dessous) et exécutez la commande sc delete DhsSearchServer.
Dans cette commande, il faut spécifier le nom exact du service (mais pas le nom complet). Rappelons qu'il est possible de lancer plusieurs services DhsSearchServer sous des noms différents. Par exemple : 
Dans cet exemple, il faut exécuter la commande :
sc delete DhsSearchServer_aaaa.
Désinstallation du serveur Search
Le choix Paramétrage : Désinstallation Power Search Serveur du menu Harmony permet de désinstaller une instance d'un serveur Search (utilitaire xSearchUninstall.dhop).
La désinstallation consiste à supprimer le service DhsSearchServer et les informations qui le concernent dans la base de registre.
Choix de l'analyseur
Il est possible de choisir l'analyseur syntaxique à utiliser.
Pour connaître la liste des analyseurs disponibles, allez dans la console d'administration, menu "Affichage" choix "Analyseurs".
Ce choix vous permet de sélectionner et de tester un analyseur.
Pour intégrer l'analyseur de votre choix dans le serveur search, cliquez sur le bouton "Copier les paramètres dans le presse-papier".
Ensuite, intégrez le presse-papier dans le fichier paramètres.
Exemple :
<Analyzer Dll="Lucene.Net.dll" AnalyzerName="StandardAnalyzer" NameSpace="Lucene.Net.Analysis.Standard" Version="LUCENE_CURRENT" />
Remarque :
Si vous changez d'analyseur, il faut impérativement refaire l'indexation de toute la base. Le même analyseur est utilisé pour le découpage des mots lors de l'indexation et lors de la recherche.
Client Search
Deux paramétrages sont nécessaires sur le poste client pour pouvoir accéder au serveur Search :
La déclaration du serveur Search dans la table des serveurs
L'ajout du nom du serveur Search dans l'environnement de l'utilisateur
Ces opérations sont également nécessaires sur le serveur afin de pouvoir utiliser la console d'administration Search sur le serveur lui-même.
Remarque : Le serveur Search est créé dans la table des serveurs par l'installation de l'ERP Divalto.
Table des serveurs
Si le nom du serveur correspond à son nom Netbios, l'adresse IP est facultative.
Si un serveur héberge plusieurs serveurs Search, il faut créer autant d'entrées dans la table qu'il y a de serveurs (chacun avec son numéro de port dédié). Dans ce cas, il faudra indiquer l'adresse IP du serveur car chaque serveur doit porter un nom différent dans la table.
Environnement utilisateur
Le nom du serveur Search est un paramètre de l'environnement de l'utilisateur. 
Le paramètre « Serveur Search » de l'environnement de l'utilisateur indique le nom du serveur Search à utiliser. Lorsque ce paramètre est présent dans l'environnement, le menu Divalto et la toolbar des Zooms offrent l'accès à la recherche.
Les boutons « Propager » et « Exporter dans un fichier » permettent de diffuser les environnements vers tous les postes clients.
Alternative de paramétrage sans environnements
Pour les sites où la gestion des environnements utilisateurs n'a pas été mise en oeuvre, l'alternative de paramétrage consiste à déclarer le nom du serveur Search directement dans la base de registre du poste client par XdivaltoMajini. 
Dans la base de registre HKEY_CURRENT_USER, la valeur de la clé « ServeurSearch » permet d'indiquer le nom du serveur de l'utilisateur courant.
Remarque :
L'option /propager de Xdivaltomajini.exe permet également la diffusion du paramètre vers tous les utilisateurs.
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.
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.
Console
La console permet d'administrer un serveur Search, elle se connecte en mode client/serveur au serveur Search.
Elle permet notamment d'indexer l'ensemble des documents existants après l'installation d'un nouveau serveur.
Le menu "Action" est contextuel. Les choix de ce menu dépendent du choix "Affichage" en cours.
La file d'attente des actions
Les actions d'indexation ne sont pas directement exécutées par la console elle-même, mais sont mises dans une file d'attente du serveur. Elles sont ensuite exécutées au fil de l'eau par le moteur Search. Ceci permet de « lancer » plusieurs actions à la suite sans être obligé d'attendre qu'elles soient effectivement réalisées. Le choix « indexations » affiche la file d'attente des actions en cours.
Choix du serveur
Le bouton "Serveur" de la toolbar permet de choisir le serveur que l'on souhaite administrer.
Relire les paramètres
Le serveur Search garde les paramètres du fichier Search_Param.xml ainsi que les RecordSQL associés aux documents en cache. Toute modification des paramètres ou recompilation d'un dictionnaire de RecordSQL du Search nécessitent obligatoirement la relecture des paramètres d'indexation pour être prises en compte.
Cette action est placée en tête dans la file d'attente, mais s'il y a, par exemple, une indexation en cours celle-ci ne sera pas affectée par les modifications de paramètres.
Les paramètres <User> et <UsersPath> ne sont pas pris en compte. En cas de changement de l'un de ces paramètres, il convient de redémarrer le service DhsSearchServer.
Indexations périodiques
Voir l'explication détaillée des indexations périodiques.
Privilèges
L'utilisation de la console est soumise à des privilèges. Il existe 3 niveaux de privilèges :
La consultation seule ne nécessite pas de droits particuliers.
L'indexation des documents et la gestion des connexions au serveur nécessitent le droit HS1.
La suppression des index (en particulier l'effacement de tous les index pour une ré-indexation totale) nécessite le droit HS2 ou HCO.
Affichage
Le choix "Affichage" du menu propose
Afficher l'état général du serveur
Afficher les connexions en cours
Afficher la liste des documents
Afficher les indexations en cours
Afficher les traitements périodiques à venir
Tester les différents analyseurs. Voir Choix de l'analyseur.
Gestion des connexions
La gestion des connexion peut être mise en oeuvre lors d'opérations de maintenance du serveur Search.
Le menu "Actions" des choix d'affichage du "Serveur" ou des "Connexions" propose les choix suivants :
Fermer toutes les connexions.
Ce choix provoque la déconnexion de toutes les connexions des postes client du Search (sauf celle de la console à partir de laquelle la demande a été effectuée)
Fermer la connexion.
L'affichage des connexions affiche toutes les connexions en cours vers le serveur Search dans un tableau. Le choix "fermer les connexions" déconnecte toutes les connexions sélectionnées dans le tableau (par défaut la ligne courante).
Interdire les connexions.
Les client ne peuvent plus se connecter au serveur Search. Par exemple si l'on indexe un document et que l'on ne souhaite pas que les utilisateurs n'aient accès qu'à un résultat partiel lors d'une recherche.
Autoriser les connexions.
Les client peuvent à nouveau se connecter au serveur Search.
Indexations
Le menu "Action" du choix d'affichage des serveurs propose les choix suivants :
Suspendre les indexations
Permet de suspendre temporairement les indexations. L'indexation en cours d'exécution n'est pas suspendue.
Reprendre les indexations
Reprend les indexations en attente dans la file d'attente.
Relire le fichiers paramètre d'indexation
Afin qu'une modification du fichier paramètre ou une nouvelle version d'un dictionnaire RecordSQL soit prise en compte par Divalto Power Search, il convient de relire le fichier paramètres.
Attention : Le changement du code utilisateur <User> ou le chemin du fichier des utilisateurs <UsersPath> n'est pas pris en compte par ce choix. Pour la prise en compte d'une modification d'un de ces deux paramètres, il convient de redémarrer le service DhSearchServer.
Suspendre les indexations périodiques
Permet de suspendre temporairement les indexations périodiques.
Reprendre les indexations périodiques
Permet de reprendre les indexations périodiques.
Relire de fichiers paramètre des indexations périodiques
Indexer tout
Indexe l'ensemble des documents. Ce choix n'efface pas les documents existants, il applique la stratégie d'indexation définie dans les paramètres généraux ou ceux liés à chaque document.
L'indexation de documents est également accessible à partir de l'affichage des documents.
Effacer tout et indexer
Supprime l'ensemble des index, puis indexe tous les documents. Ce choix est soumis au privilège le plus élevé. En effet cette opération peut durer un certain temps.
Remettre à zéro les compteurs
Met à zéro les compteurs statistiques.
Limiter le nombre de documents à indexer
Ce choix est particulièrement intéressant en phase de paramétrage d'un nouveau document ou de modification de paramètres de documents existants. En effet si la base ERP contient du volume, l'indexation complète d'un document peut durer un certain temps. Limiter le nombre de document à indexer permet de vérifier que le paramétrage est correct sur un échantillon avant de lancer l'indexation complète de tous les documents.
Ce choix peut également permettre par extrapolation une estimation du temps nécessaire à l'indexation d'un document.
Gestion des documents
Le choix "Documents" du menu "Affichage" affiche le liste des documents de la base Search.
Le nombre de document du tableau correspond au nombre effectif de documents indexés dans la base Search pour chaque document.
Les boutons de la toolbar ou bien les choix du popup menu affichés après un clic-droit sur une des lignes du tableau permettent de :
Indexer un document
Indexer tous les documents d'un dictionnaire
Supprimer les index d'un document
.
Indexations périodiques
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.
Le fichier des paramètres indique la périodicité ( quand par la balise <when>) et ce qu'il faut faire ( quoi par balise <what>)
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
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"
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 prend en charge automatiquement cette gestion. 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.
Conception d'un document
La phase de conception d'un document est une phase primordiale, autant pour un nouveau document conçu spécialement pour un utilisateur que pour des documents standard livrés par l'éditeur.
En effet chaque utilisateur a sa propre conception du contenu d'un document et s'attend donc à trouver un résultat en fonction de SES critères de recherche.
Il s'agit donc de s'assurer que les documents créés ou proposés à l'utilisateur sont bien en adéquation avec ces attentes. Dans le cas contraire, il risque de perdre la confiance dans l'outil de recherche et ne plus s'en servir.
Qu'est-ce qu'un document ?
Un document est un ensemble cohérent d'informations pertinentes pouvant faire l'objet d'une recherche. Par exemple, pour un document « Client », l'on souhaite retrouver sa fiche, à partir de son nom évidemment, mais aussi de son adresse, de sa ville, de son code postal ou téléphone, à partir du nom d'un de ses contacts, du contenu d'un mail échangé récemment, d'un courrier envoyé, d'un compte rendu de réunion, d'une note prise lors d'un échange téléphonique, d'une facture émise, d'un produit vendu, etc.
La description d'un document passe par une phase de conception qui permettra de définir quelles sont les données du système d'informations qui doivent entrer dans la composition de celui-ci (en incluant éventuellement les pièces jointes).
Description d'un document
La phase de conception est suivie par la phase de description où l'on écrira en langage XML précisément ce qui constitue le document.
Checklist pour la conception
L'idéal pour concevoir un document Search est d'organiser une réunion de BrainStorming avec les futurs utilisateurs.
Le document Search_Modèle_Conception_Document.doc peut servir de trame pour recueillir des informations qui serviront ensuite à la description du document. Search_Conception_Document_Client.doc est un exemple ayant servi pour le document client.
Le document recense :
l'Identification du document
Les particularités des champs communs
La question de la confidentialité
Les critères de recherche pertinents pour le document.
Pour les critères le document propose une subdivision en 2 catégories :
les données proches (au sens relationnel) de la table qui constitue le coeur du document. L'ensemble de ces données pourra faire l'objet d'un RecordSQL. Par exemple pour le client, la raison sociale, l'adresse, le code postal, la ville, le téléphone, le nom du pays, etc.
les données complémentaires. Ces données nécessitent un accès par un ou plusieurs autres RecordSQL. Par exemple pour le client, les notes, les pièces jointes, les contacts, les adresses complémentaires, etc.
L'utilisation du modèle conceptuel des données ou la description des tables et des liaisons dans le dictionnaire de données peuvent être une aide précieuse pour faire l'inventaire des critères pertinents.
Une vision large
Il est également intéressant d'explorer un document à partir de la vision des différents utilisateurs. Le comptable, le commercial, l'administration des ventes, le service juridique, la direction générale apporteront autant de points de vue différents et complémentaires sur le document "client" par exemple.
Description d'un document
Après la phase de conception, intervient la phase de description où l'on indiquera précisément ce qui constitue le document :
• Son domaine ;
• son sujet ;
• son titre ;
• l'application qui permettra d'afficher le résultat de la recherche (le zoom client pour un client, le programme d'interrogation des pièces pour une facture, …) ;
• son niveau de confidentialité ;
• les données de l'ERP qui entrent dans sa composition (il s'agit d'une forêt de RecordSQL permettant de trouver, dans les données structurées de l'ERP, les informations qui constituent le document).
La description des documents est conservée dans un dictionnaire de documents au format Xml. Il y a généralement un dictionnaire par domaine (CRM, Commerce et Logistique, Comptabilité, Paie, etc.).
RecordSQL
Avant de pouvoir effectuer des recherches, il faut alimenter la base Search à partir des données de l'ERP. Cette opération est effectuée par le serveur Search « hors contexte » soit par lot, soit en « presque temps réel ». Le service DhsSearchServer accède à la base ERP par des RecordSQL.
La description du document Search comporte l'arborescence des RecordSQL permettant de récupérer les informations à partir de la base ERP pour les injecter dans la base SEARCH. Divalto fournit un dictionnaire de RecordSQL pour chaque domaine de l'ERP.
RecordSQL
Chaque document Search correspond à un arbre de RecordSQL
Exemple : Une facture
RecordSQL Facture
RecordSQL PiecesJointes
RecordSQL LignesDetail
RecordSQL PiecesJointesDetail
Dictionnaires de RecordSQL pour le Search
Les RecordSQL pour le Search se trouvent dans des dictionnaires spécifiques par Domaine :
Dav_sd.dhsq pour Commerce et logistique
Drt_sd.dhsq pour la CRM
Dpaie_sd.dhsq pour la Paie
Etc.
Ce sont des RecordSQL généralement assez simples qui ne comportent pas de clauses <OrderBy> et habituellement pas de clauses <Where>.
Cependant attention :
Ces RecordSQL doivent être « autonomes » puisqu'il sont exécutés hors contexte. Donc :
Pas d'accès à des Record Public
Pas de paramètres
Les sources des dictionnaires standard sont fournis par Divalto. Pour le développement de nouveaux RecordSQL pour le Search, on n'hésitera pas à s'inspirer des sources existants, en particulier pour l'expression de la jointure vers les tables liées.
Condition <Where>
Pour des raisons de mutualisation de RecordSQL (par exemple le même RecordSQL est utilisé pour les documents "Commande", "BL", "Factures", etc), il est possible dans la description du document (par l'attribut Condition) d'indiquer la clause <Where> à utiliser pour parcourir le RecordSQL.
Convention d'écriture de l'alias des tables jointes comportant des champs de la condition <Where>
Pour des raisons d'optimisation de l'indexation des documents déjà existant dans la base search par lot, le moteur Search ne sélectionne pas tous les champs des RecordSQL, en particulier les tables jointes ne sont pas lues. Pour forcer la lecture des champs d'une table jointe lorsque celle-ci contient des champs nécessaires à l'expression de la condition <Where>, il faudra préfixer l'alias de celle-ci par Search_.
L'option GlobalConf pour les tables liées
Si l'on souhaite que la confidentialité d'une table liée d'un RecordSQL entraîne la confidentailité globale de tout le document Search, l'option « GlobalConf » des RecordSQL associés au document doit être mise en œuvre. (par exemple les tables Dossier ou Etablissement) 
XRecordSQLCheck
L'utilitaire XRecordSQLCheck est un outil précieux pour le développement de RecordSQL. En effet, il permet de tester le RecordSQL sans développer de programme Diva.
De plus il permet l'optimisation des RecordSQL car il contrôle que l'expression des jointures entre les tables utilise des index.
Pour contrôler la syntaxe des RecordSQL, il se connecte à la base de données cible, qui doit contenir l'ensemble des tables utilisées dans les RecordSQL.
Il traite au choix :
un répertoire de dictionnaire
un dictionnaire
un RecordSQL d'un dictionnaire.
Générer la requête
Ce choix génère le source SQL de la requête choisie. Par un copier/coller on peut ensuite directement exécuter cette requête, par exemple dans SQL Server Management Studio.
Base Search Document
La base Search est une base de données spécifiquement conçue pour un moteur de recherche. Ce n'est pas une base de données relationnelle qui n'est pas adaptée pour ces traitements.
La base Search est stockée dans un répertoire Windows. C'est une structure arborescente de sous-répertoires.
Elle est constituée à partir de la description des documents du Search. Sa taille dépend du volume des données à indexer ; en particulier, l'indexation de pièces jointes importantes nécessite de l'espace sur le disque. Son volume sera toutefois toujours inférieur à celui de la base de données et de l'ensemble des pièces jointes.
Document
L'entité de base dans la base Search est le document.
Chaque document comporte un identifiant unique formé par :
Le nom du dictionnaire de documents
La référence (le nom) du document dans ce dictionnaire
L'id de la ligne dans table ERP.
Chaque document est composé de Fields.
Base Search Field
Un document Search est composé de Fields.
Les fields ne sont généralement pas stockés dans la base Search, ils servent essentiellement d'index pour retrouver un document.
Les données qui constituent les fields ne sont généralement pas indexées telles quelles, en particulier les champs alphanumériques, les notes et les pièces jointes. Elles sont analysées et découpées en éléments plus simples (les token) qui servent à indexer le document.
Pour chaque field d'un document on indiquera donc ses caractéristiques.
Propriétés des fields
Analyzed : un field peut être analysé avant d'être écrit dans la base Search. Il est alors découpé en Token par l'analyseur.
Indexed : un field ne sert pas forcément d'index de recherche, mais peut être simplement stocké dans la base Search (par exemple le lien vers les pièces jointes).
Stored : un field servant simplement d'index n'est pas stocké dans la base Search. On ne pourra pas récupérer sa valeur lors d'une recherche. Cet attribut permet de forcer le stockage du field dans la base.
La propriété "Analyzed"
L'analyse d'un field consiste à découper celui-ci en token selon un algorithme assez sophistiqué.
Par exemple la valeur « CHANTER Le jour de Noël » après analyse est décomposée en 3 token qui serviront d'index :
chant
jour
noel
Traitement de l'analyse
Le texte est converti en minuscule, donc les requêtes ne sont pas dépendantes de la casse
Les accents sont supprimés (Noël => noel), donc pas besoin de saisir d'accents dans les requêtes
Les prépositions, pronoms, articles, conjonctions de coordination, mots de liaison usuels, etc. du français sont ignorés : donc inutile de les saisir
L'analyse ne conserve que la racine des mots (ici chant pour chanter), on trouvera donc tous les documents dans lesquels apparaît une forme du verbe chanter (chante, chantes, chanterons, chanterait, etc.)
La propriété "Name"
Dans la base Search, chaque field est identifié par un nom. Lors d'une requête il faut préciser pour chaque mot de la requête à quel nom de la base Search il fait référence. C'est pourquoi la plupart des fields de la base Search sont identifiés par un nom générique : content
On ne donnera un nom propre qu'à des fields clairement identifiés (par exemple le dossier, l'établissement, l'auteur, etc. ) qui pourront alors servir de critères de filtrage. Ce sont les Fields Communs à l'ensemble des documents.
Voir la propriété Name
Field commun
Dans l'ERP Divalto, il existe des champs communs à l'ensemble des tables, comme le dossier, l'établissement, la date de création, etc.
Ces données sont particulièrement intéressantes dans le cadre d'un moteur de recherche pour effectuer des filtrages. Par exemple, dans le cadre d'une recherche ne s'intéresser qu'aux documents d'un dossier ou d'un établissement particulier, qu'aux documents récents.
Dans la base Search, ces champs deviendront des Fields identifiés par un nom (Attribut Name). Nous les appelons dorénavant les Fields Communs
Les fields communs à tous les documents sont décrits dans le fichier Search_commonFields.xml.
Les attributs d'un field commun peuvent être redéfinis pour chaque document dans la section <CommonFields> du document.
Un field est décrit dans une balise <field>. Les attributs de la balise permettent de préciser les propriétés du field.
Les valeurs des fields communs ont deux origines :
La description des documents (le domaine, la famille, le titre)
La base de données ERP (le sujet, l'auteur, la date de création, etc.)
Afin d'alléger la description des fields des attributs facultatifs prennent des valeurs par défaut. (ce ne sont pas les mêmes pour les fields communs que pour les fields des documents).
Search_commonFields.xml
l 
Field commun Name
L'attribut Name correspond au nom du field commun dans la base Search. Ce nom s'affiche dans le filtrage du mode expert.
Field commun Value
Les fields communs ont deux origines, la description du document ou bien la base de données ERP. L'attribut Value prend donc deux formes différentes :
Pour les fields « document » on écrit
Document.Domain pour le domaine
Document.Family pour la famille
Document.Title pour le titre
Pour les fields « Erp » on écrit
RecordSQL.Champ qui correspond au nom du champ dans le RecordSQL de base du document.
Sujet
Le sujet du document apparaît en bleu dans le résultat de la recherche. C'est généralement un champ calculé du RecordSQL qui permet à l'utilisateur d'identifier le document trouvé.
DateCreation et DateModif
La date de création correspond par défaut au champ UserCrDh et la date de modification au champ UserMoDh. Si ces champs n'existent pas dans la table concernée ou s'il existe d'autres champs plus significatifs, ils peuvent être redéfinis dans la section <CommonFieds> du document.
Ces champs ont de plus 2 fonctions particulières :
Ces dates permettent de déterminer s'il s'agit d'un document récent lors d'une recherche.
Ces dates permettent d'optimiser l'indexation des documents existants dans la base Search. Lors de l'indexation par lot d'un document, si la base Search contient déjà des instances de ce document, le moteur ne sélectionne que les champs correspondants aux fields DateCreation et DateModif dans la base ERP afin d'appliquer les stratégies d'indexation des documents existants.
DateHS
La date de péremption permet de filtrer les documents "actifs" lors d'une recherche. Elle correspond par défaut au champ HsDt de la table. Si la date de péremption du document est supérieure à la date du jour, le document est actif. La notion de date de péremption n'existe pas forcément pour tous les documents, c'est pourquoi ce field a une valeur par défaut au 31-12-9999. Elle s'applique aux documents pour lesquels les champs correspondants au field DateHs n'existe pas ou renvoie une valeur nulle.
Certaines tables gèrent un simple indicateur d'état (actif ou non actif). Il conviendra, dans le RecordSQL associé au document, de convertir l'indicateur en une date de péremption.
Exemple SQL pour transformer un indicateur périmé en date de péremption
case When EVTTIERS.CE2 = 2 THEN cast('9999-12-31' as date) ELSE cast('0001-01-01' as date) END as Hsdt(>gtfdd.dhsd Hsdt)
Field commun Analyzed Indexed Stored
Ces attributs ont les valeurs par défaut suivantes :
Analyzed (par défaut False)
Indexed (par défaut True)
Stored (par défaut True)
Les fields communs sont restitués comme résultats de la requête. Pour cela ils doivent être « stored ».
Le field "Sujet" n'est pas utilisé comme index, en effet ce n'est pas un field commun pertinent pour effectuer un filtrage (chaque document possède un sujet différent).
De plus, il s'agit d'un champ dont la valeur est une agrégation d'autres données du document qui servent déjà d'index pour le document.
Field commun Displayed
La valeur par défaut de l'attribut Displayed est false.
La valeur True permet d'afficher les valeurs de ce field dans la colonne de gauche du filtrage en mode simple.
On ne prendra que des fields avec un nombre de valeurs distinctes réduites.
Field commun Current
Permet de proposer la valeur [courant] dans les valeurs de filtrage du mode Expert.
Cette fonctionnalité est particulièrement intéressante pour les utilisateurs travaillant avec plusieurs dossiers ou établissements différents et souhaitant filtrer les recherches de Divalto Power Search au dossier ou à l'établissement courant de l'ERP.
Pour que cette fonctionnalité soit opérationnelle, il est impératif que la recherche soit lancée depuis le menu Divalto ou d' un Zoom qui connaît la valeur de [Courant].
Les valeurs courantes sont envoyées à l'interface de recherche par la procédure Search_init() du module « a5tmsearch.dhop »
L'interface de recherche récupère toutes les valeurs ayant l'attribut Current par la fonction PingReceive de la valeur de l'attribut.
Exemple
<Field Name="Dossier" Value = "RecordSQL.Dos" Current="Dossier" Displayed="true" />
Search récupère la valeur du dossier courant pour la fonction : Pingreceive("Dossier",DossierCourant)
Field commun DefaultValue
L'attribut DefaultValue est utilisé pour un field commun dont le champ n'existe pas dans le recordSQL du document ou pour lequel la base ERP renvoie une valeur Nulle.
Par exemple la date de péremption d'un document n'existe pas forcément.
Exemple
<Field Name="DateHS" Value = "RecordSQL.hsdt" DefaultValue="9999-12-31" />
Présentation du résultat
La balise <Presentation> du fichier Search_CommunFields.xml décrit le contenu des lignes de résultat :
Ligne bleu : le sujet
Ligne verte : les informations « techniques »
Ligne grise (facultative) : les pièces jointes
La présentation du résultat peut être modifiée pour un document particulier dans la section <Presentation> de la description du document.
La balise xml <![CDATA[ permet de banaliser du texte pour insérer une valeur comportant des signes xml réservés comme < et >
La balise fermante correspondante est ]]>. Elle encadre obligatoirement la description des lignes de résultat. 
Le texte peut contenir :
Un nom de field « stored » (par exemple DateCreation)
Des constantes entre simple quote (par exemple ' du ' )
Les textes entre [ ] n'apparaissent pas dans le résultat si le field contient une valeur nulle.
La "fonction" date pour l'affichage des dates.
Description Xml d'un document
La description d'un document s'effectue en xml dans un dictionnaire de descriptions de documents.
Le dictionnaire peut être surchargé par l'attribut Overwrittenby afin d'ajouter des fields à des documents existants.
Chaque document est décrit dans une balise <Document>. L'attribut Reference donne une référence unique au document dans tout le dictionnaire
<Document Reference="Evenement">
La description d'un document comporte plusieurs sections dont certaines facultatives. 
Le fichier /divalto/search/xsd/SearchDico.xsd contient la description formelle du fichier de description des documents. Il est utilisé pour vérifier la syntaxe de la description.
L'éditeur de Microsoft Visual Studio propose une assistance à la saisie de fichier .xml si le fichier .xsd correspondant existe.
L'éditeur Notepad++ colorise les balises afin de faciliter la lecture (et l'écriture du code xml).
Document <Domain>
Cette section indique le domaine du document
<Domain>CRM</Domain>
C'est un field commun à tous les documents. Il est proposé au filtrage pour les utilisateurs.
Document <Familly>
Cette section indique la famille du document
<Family>Evènement</Family>
C'est un field commun à tous les documents. Il est proposé au filtrage pour les utilisateurs.
Document <Title>
Cette section indique le titre du document
<Title>Evenement</Title>
C'est un field commun à tous les documents. Il est proposé au filtrage pour les utilisateurs.
Il doit être unique pour tous les documents d'un serveur, deux documents décrits dans des dictionnaires différents ne devraient pas porter le même titre.
Document <IndexExistingDocument>
Cette section est facultative.
Elle permet de redéfinir la stratégie d'indexation des nouveaux documents pour ce document.
La stratégie par défaut est celle définie dans Search_param.xml.
On redéfinira stratégie pour un document uniquement lorsque elle diffère de la stratégie par défaut.
Voir l'explication détaillée des stratégies d'indexation des documents existants.
Document <Presentation>
Cette section est facultative.
Elle permet de redéfinir la présentation du résultat de la recherche pour ce document.
La présentation par défaut est celle définie dans Search_CommonFields.xml.
Voir l'explication détaillée de la présentation.
Document <CommonFields>
Cette section est obligatoire (même vide).
Elle permet de redéfinir les attributs des Fields Communs définis dans Search_CommonFields.xml.
Chaque attribut peut-être changé. Les attributs non cités gardent la valeur par défaut.
Exemple : Pour un document remplacer la date de création par défaut (UserCrDh) par un autre champ plus significatif pour cette table.
<Field Name="DateCreation" Value ="Fadt"/>
Remarques
Les attributs Displayed et Current ne peut pas être redéfinis, leur valeur est globale à l'ensemble des documents.
L'attribut Value peut prendre la valeur "null" si ce champ n'existe pas dans le document concerné (sauf pour les fields DateCreation et DateModif qui sont obligatoires).
Document <Application>
Cette section permet de définir l'application en charge de la présentation du document lorsque l'utilisateur double-clique sur une ligne de résultat. 
Voir le détail de la mise en oeuvre.
Document <Security>
Cette section permet de définir les confidentialités du document. 
La balise <keyhole> donne le nom des « serrures » associées à ce document.
Lors d'une recherche l'utilisateur verra uniquement les documents pour lesquels il a UNE « clef ».
Lorsque cette section est absente ou vide, le document est public.
La modification de cette section nécessite une réindexation totale du document concerné si l'on souhaite qu'elle s'applique à l'ensemble des documents déjà existant dans la base Search.
Dans l'exemple ci-dessus, l'utilisateur ayant la clef pour ouvrir la serrure "SearchEvenement" OU la serrure "SearchFamEvenement" OU la serrure "SearchDomCRM" verra le document concerné lors d'une recherche.
Voir l'explication détaillée de la mise en oeuvre des confidentialités.
Document <RecordSQL>
Cette section permet de définir les champs de la base ERP que l'on souhaite ajouter au document de la base Search.
C'est une section complexe qui permet de définir une arborescence de RecordSQL.
La première balise <RecordSQL> définit le RecordSQL par lequel se fera l'accès à la base de l'ERP. Chaque ligne renvoyée par ce RecordSQL génère une instance d'un document dans la base Search. Nous l'appellerons le "RecordSQL de base".
Les sous-balises <Field> définissent les fields à ajouter dans la base Search en provenance de la base ERP.
Les balises <RecordSQL> peuvent être imbriquées.
Le premier niveau correspond au RecordSQL de base d'accès à l'ERP.
Pour chaque ligne lue de ce RecordSQL, le moteur lit toutes les lignes des RecordSQL du niveau inférieur (en respectant la condition de jointure définie dans le RecordSQL du niveau inférieur qui lie les deux RecordSQL).
Nous appellerons RecordSQL secondaires les RecordSQL de niveau inférieur.
Remarque
Il n'y a pas de limite au nombre de niveaux.
Il peut y avoir plusieurs RecordSQL au même niveau.
RecordSQL Name
L'attribut Name indique le nom de l'instance du RecordSQL. Ce nom doit être unique pour tout le document. Il sert :
A faire référence à cette instance du RecordSQL dans les conditions de jointure des RecordSQL de niveau inférieur.
A ajouter des Fields à un document dans un dictionnaire de documents de surcharge.
RecordSQL Dico
L'attribut Dico indique le nom du dictionnaire de RecordSQL
RecordSQL RecordSQL
L'attribut RecordSQL indique le nom du RecordSQL dans le dictionnaire de RecordSQL
RecordSQL Condition
L'attribut Condition indique le nom d'une condition <Where> du RecordSQL. Ceci permet de mutualiser un même RecordSQL pour plusieurs documents.
Attention :Cet attribut ne s'applique qu'au RecordSQL de base. 
Voir RecordSQL
RecordSQL Where
L'attribut Where indique la condition de jointure entre deux RecordSQL de niveau différent, par exemple entre le client et ses contacts. 
Dans l'expression de jointure de l'exemple ci-dessus :
$client.dos est remplacé à l'exécution par la valeur Dos du RecordSQL client (de niveau supérieur).
T2.Dos correspond au champ DOS de la table T2 (les contacts) dans la base SQL. En effet cette expression est délivrée telle quelle au moteur SQL.
Attention :
Aucun contrôle de l'expression de la jointure entre les tables n'est effectué. Une expression fausse ou n'utilisant pas d'index aura des conséquences sur le contenu des documents ou sur les temps d'indexation de ceux-ci. Pour les jointures vers les tables de notes ou vers les fichiers joints, on s'inspirera avec profit des sources de documents livrés par Divalto.
Par exemple
RecordSQL DoSelect
L'attribut DoSelect permet d'optimiser l'indexation par lot, en particulier des notes et des pièces jointes. En effet, il y a rarement une note ( et/ou une pièce jointe) pour chaque client.
La valeur de l'attribut DoSelect permet de savoir s'il y a effectivement des éléments dans la table de niveau inférieur, sans être obligé d'exécuter la requête select qui est gourmande en ressource.
Par exemple le champ T2.Note indique s'il y a une note associé au contact.
Dans la description du document Search
Dans le <Select> du RecordSQL Contact
Sans cette optimisation, s'il y a 100 000 clients, on exécute 200 001 select (notes + pièces jointes) même s'il n'y a que 10 000 notes et pièces jointes.
Avec l'optimisation on exécute 10 001 select.
RecordSQL <Field>
Les balises <Field> d'un RecordSQL définissent les fields à ajouter à la base Search.
Les valeurs des attributs de <Field> sont semblables à celles de fields communs. Les valeurs par défaut sont différentes.
Attention :
Certaines valeurs sont dédiées aux fields communs et d'autres aux fields
Field Attribut
Les attributs
L'attribut Name est nom du field dans la base Search. On utilisera la valeur "Content" pour les champs génériques. Pour la recherche spécifique au Zoom, on peut indexer des champs dont le résultat sera uniquement rendu dans le Zoom. Pour cela, on utilise la valeur "Zoom". On peut également utiliser la valeur "Content,Zoom" pour avoir un champ dans les deux recherches.
L'attribut Value est le nom du champ dans le RecordSQL
Les attributs facultatifs.
L'attribut Analyzed indique que le champ doit être analysé. La valeur par défaut dépend du type du champ, elle vaut true par les champs alphanumériques.
L'attribut Indexed indique que le champ servira d'index. La valeur par défaut est true.
L'attribut Stored indique que le champ est stocké dans la base Search. La valeur par défaut est false.
Voir l'explication détaillée des attributs des fields
Field Type
L'attribut Type permet d'indiquer le type des champs « notes » et « pièces jointes » 
Pour les pièces jointes, l'attribut Indexed=false, permet d'afficher le lien vers la pièce jointe, sans indexer son contenu.
Surcharge d'un document
Un dictionnaire de documents peut être surchargé afin de modifier des propriétés ou d'ajouter des fields à un document existant.
Pour l'ajout de nouveaux documents, on créera un nouveau dictionnaire. La surcharge ne permet pas cette opération.
L'attribut "Overwrittenby" de la balise <Dictionnary> indique le nom du dictionnaire de surcharge.
L'attribut "Overwrite" de la balise <Dictionnary> du dictionnaire de surcharge indique le nom du dictionnaire qu'il surcharge.
Un dictionnaire de surcharge peut lui-même être surchargé.
Dans le dictionnaire de surcharge l'attribut Reference de la balise <Document> indique sur quel document porte la surcharge.
Seules les sections suivantes peuvent faire l'objet d'une surcharge :
Surcharge Presentation
La section <presentation> peut être entièrement revue.
Voir le détail de la section <presentation>
La surcharge peut porter sur l'une ou l'autre ou l'ensemble des balises <Line>. Seules les balises <Line> modifiées sont nécessaires dans la surcharge. Les valeurs non modifiées sont prises dans le document d'origine.
Surcharge CommonFields
Les fields communs d'un document peuvent être entièrement redéfinis dans le dictionnaire de surcharge. Les attributs non modifiés conservent les valeurs du document d'origine.
Surcharge Security
La balise <Security> d'un document de surcharge permet d'ajouter des serrures à un document existant.
Surcharge RecordSQL
La section <RecordSQL> peut être surchargée. Cela permet de :
Modifier les attributs de fields existants
Ajouter des fields
Ajouter des RecordSQL dans l'arborescence des RecordSQL d'un document.
Dans la section <RecordSQL> d'un document chaque RecordSQL de l'arborescence est identifié par un attribut Name unique.
Dans le dictionnaire de surcharge, on utilisera ce nom unique pour indiquer à quel RecordSQL de l'arborescence d'origine s'appliquent les modifications.
Exemple d'ajout d'un field dans un RecordSQL existant
Exemple d'ajout d'un RecordSQL
Application associée à un document
La section <Application> de la description d'un document définit le nom du module et le nom de la fonction à exécuter lors d'un double-clic sur le résultat de la recherche.
Attention :
A l'exécution de cette fonction, il faut sauvegarder le contexte, car cette fonction peut-être appelée depuis le menu Divalto par exemple.
Paramètre de la fonction associée à un document
La fonction comporte un paramètre de type S qui contient une chaîne <Hmp> avec le résultat de la recherche :
L'identifiant du document
<Search_Dico>,<Search_Ref>,<Search_Id>
Les fields communs « stored »
<Sujet>, <Domaine>, <Famille>, <Titre>,<Dossier>, <Etablissement>, <Auteur>,<DateCreation>, <DateModif>, <DateHS>
Les autres fields « stored » du document
Appel d'un ZoomSQL pour afficher un document
Le ZoomSQL peut être un choix judicieux pour afficher un document résultat d'une recherche.
Le ZoomSQL a été spécialement adapté pour gérer cette nouvelle fonctionnalité, en effet dans ce mode, le zoom n'affiche qu'une seule fiche.
Pour indiquer au ZoomSQL qu'il est appelé par Divalto Power Search, il convient de lui envoyer l'id de la ligne concernée sous le label « DivaltoSearch » par la fonction Ping.
L'id est une donnée en 10,0
Exemple complet
; Domaine Paie
; Module pour l'appel des applications en charge de documents de Divalto Power Search
Module pppmbas000.dhop
Module pppmficsql.dhop
Public Record a5dd.dhsd MZ MZ
; Document DPaie_sd:Bulletin
Public Procedure search_Bulletin(param)
1 param S
1 dos >GTFDD.DHSD DOS
1 etb >GTFDD.DHSD ETB
1 id 10,0
Record A5DD.dhsd MZ SV_MZ
RecordSql 'pprsppbul.dhoq' bulletin
beginp
; on récupère le dossier et l'id dans la base ERP
dos = HmpSeek(param,"dossier" ,0)
etb = HmpSeek(param,"etablissement" ,0)
Id = HmpSeek(param,"search_id" ,0)
if dos <> 0 and Id <> 0
; sauvegarde de MZ puis mise en place des paramètres
SV_MZ = MZ
MZ.Dos = dos
MZ.Etb = etb
MZ.ETBP3 = MZ.ETB
; on vérifie qu'il existe encore
bulletin.where.id(id)
if select_bulletin(bulletin) = 0
; on appelle le Zoom
ping('DivaltoSearch',id)
P3_Zoom_Call(25020)
endif
; Restauration de MZ
MZ = SV_MZ
endif
endp
Confidentialités mise en oeuvre
La mise en oeuvre des confidentialités est conditionnée par présence et le garnissage du fichier paramètre Search_Security.xml.
Lorsque ce fichier est absent ou "vide" aucune gestion de confidentialité n'est mise en oeuvre.
Voir les généralités à propos des confidentialités.
Deux niveaux de confidentialités des documents peuvent être mis en oeuvre :
Search_Security.xml
Le fichier Search_Security.xml se trouve dans le répertoire des paramètres d'un serveur Search.
Lorsque ce fichier est absent ou "vide" aucune gestion de confidentialité n'est mise en oeuvre. Tous les documents de la base Search sont accessibles à tous.
Prise en compte de la modification des paramètres
L'ajout de ce fichier ou la modification de son contenu nécessite la "relecture des paramètres d'indexation" par la console Search. Le redémarrage du service Search concerné prend également en compte les modifications mais on privilégiera la relecture des paramètre afin de ne pas perturber les utilisateurs connectés au serveur.
Contenu
Il contient la correspondance entre les noms des serrures associées aux documents dans la base Search et les codes d'accès (Clefs) de l'utilisateur permettant d'ouvrir ces serrures (donc d'accéder aux documents).
Une même serrure peut avoir plusieurs clés. 
L'attribut Name de la balise <Keyhole> indique le nom de la serrure.
L'attribut Value de la sous-balise <Key> indique la valeur du code de confidentialité.
Ainsi dans l'exemple ci-dessus :
Le code "D998" permet d'ouvrir la serrure "Dossier998"
Le code "AAAA" permet d'ouvrir les serrures "searchDomCommerceEtLogistique" ET "searchDomCRM"
Le code "BBBB" permet également d'ouvrir la serrure "searchDomCRM
Attention
Si une serrure a été positionnée sur un document par la balise <Security> et qu'elle n'apparaît pas dans une balise <Keyhole> du fichier Search_Security.xml, ce document ne sera visible par AUCUN utilisateur. Donc lors de la mise en oeuvre des confidentialités assurez-vous que pour chaque document, au moins une des serrures positionnées au niveau des documents soit présente dans ce fichier paramètres.
Confidentialité des documents
La description d'un document contient les serrures de celui-ci. Pour chaque document, les noms des serrures sont écrits dans la base Search au moment de l'indexation.
Lors de la connexion d'un utilisateur au serveur de recherche, le client envoie ses droits d'accès (les clés) sous forme de codes de confidentialité (4 caractères).
Ces codes sont traduits en une liste de noms de serrures grâce au fichier de correspondance Search_Security.xml.
La requête dans la base Search filtre les documents pour lesquels l'utilisateur ne dispose pas des droits d'accès. Lorsque plusieurs serrures sont associées au même document, une seule clef est nécessaire pour y accéder.
NB :
Les documents n'ayant pas de section <Security> sont publics et donc accessibles à tous.
Lorsque le fichier Search_Security est absent ou vide, tous les documents sont accessibles à tous.
En cas de changement des noms de serrures associées à un document, il convient de re-indexer le document concerné.
Confidentialité des instances des documents
L'ERP permet d'appliquer des confidentialités à des entités, par exemple le dossier.
Lorsque un dossier est confidentiel, seuls les utilisateurs ayant les droits d'accès à ce dossier pourront y accéder.
Cette gestion des confidentialités est également possible avec Divalto Power Search. Elle passe par la gestion des tables confidentielles des RecordSQL correspondants à la description du document concerné. Elle nécessite une mise en oeuvre qui respectent la chronologie stricte des opérations décrites ci-dessous.
Confidentialité des tables
Les propriétés "Confidentialité" d'une table dans le dictionnaire de données permettent de définir le nom du champ (par convention Conf) servant à la gestion de la confidentialité de cette table, ainsi qu'un passe-partout autorisant l'accès à son possesseur.
Option "GlobalConf" des RecordSQL
Voir le détail de cette option
Search_Security.xml
Comme pour la confidentialité des documents, Le fichier paramètres Search_Security.xml doit contenir la correspondance entre le code de confidentialité des champs "conf" des RecordSQL avec un nom de serrure. C'est ce nom de serrure qui sera écrit dans la base Search au moment de l'indexation. Attention : S'il n'y a pas de nom de serrure qui correspondent, le document ne sera pas confidentiel.
Indexation
Lors de l'indexation des documents, pour chaque champ "conf" des différentes tables des RecordSQL qui constitue le document, le moteur écrit dans la base Search le couple (nom de la serrure, passe-partout). Il faut s'assurer avant d'indexer le document concerné que :
Les codes de confidentialité des tables ont bien été mis en place (par exemple la confidentialité du dossier dans l'ERP)
Les correspondances des noms de serrure avec les codes existent dans le fichier Search_Security.xml
Les paramètres du moteur d'indexation sont bien à jour. Pour s'en assurer, on lancera le choix "Relire les paramètres" de la console d'administration du serveur Search.
La suppression des index des documents concernés a bien été effectuée.
La modification d'un passe-partout ou de la valeur d'un code de confidentialité nécessite obligatoirement une réindexation du document.
Recherche
Dans un premier temps s'applique la confidentialité des documents. Si le document est accessible, le moteur Search vérifie ensuite que pour chaque table confidentielle l'utilisateur dispose soit du passe-partout soit du droit d'accès. Le moteur Search ne restitue que les documents pour lesquels tous les accès sont autorisés.