Puissant moteur de recherche transversale de la solution, cette fonction permet de questionner et de retrouver rapidement toute information dans les bases de données et les documents archivés

Architecture générale du 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.

Le serveur Search est un service Windows.
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.

Serveur Search

La base Search est gérée le service DhsSearchServer. 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.

Remarque :

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.

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.

Documents pour le search

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 standards 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 standards 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.
Le Divalto Search s'étend également aux documents de la cartographie de produits, aux documents de la dématérialisation ainsi qu'aux données du catalogue fournisseur:

Assortiment de produits ;
Cartographie de produits ;
Articles d'un assortiment ;
Contrôle facture fournisseur ;
Catalogue fournisseur ;
Dataset facture fournisseur ;
Dataset prévisionnel de ventes ;
Dataset temps collaborateur.

Ainsi, le document Article a été complété afin de lire les éléments du catalogue fournisseur. Une recherche article par données catalogue fournisseur est donc possible ; une fiche RFO est nécessaire dans ce cas pour limiter la liste aux fournisseurs référencés.

Indexation des documents pour le search

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ée 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 à l'ensemble des documents du search

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

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 les documents de CRM des dossiers 996 et 997.

Préambule à l'installation du Power Search

Le programme xSearchInstall.dhop (accessible aussi à partir du choix « Administration » du menu de Harmony) permet d'installer un serveur Search.
Le programme d'installation du serveur Divalto Power Search ajoute le service « Divalto DhsSearchServer » aux services Windows du serveur et ajoute le raccourci vers la console d'administration du serveur au menu « Démarrer » de Windows.
Le service DhsSearchServer est le moteur de Divalto Power Search. Généralement on l'installera sur le serveur de la base de données de l'ERP.
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

Remarque : Harmony Power Foundation doit être installé sur le serveur Search.

Choix du serveur Search

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.

Installation du Power Search

Le programme xSearchInstall.dhop, également accessible à partir du choix « Administration » du menu Harmony permet d'installer un serveur Search.

Il crée :

Le service DhsSearchServer
Un raccourci vers la console d'administration du serveur dans le menu Windows.

Attention :
L'installation du serveur Search doit s'effectuer après l'installation de l'ERP et des bases de données.

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).

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 DhsSearchServer. 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 à personnaliser 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 DhsSearchServer

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 DhsSearchServer. 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é.
Paramètres éditeur :

/divalto/objets/Search/Search_param.xml

Chemin des paramètres :

\divalto\searchERP/Search_param.xml
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 DhsSearchServer. On s'assurera que ce service puisse y accéder et possède les droits d'accès à ces répertoires, en particulier lorsque le serveur Search est dédié.
On s'assurera aussi que le serveur Search ait accès aux répertoires des pièces jointes.

Fichier 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êmes 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.

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).

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

Balise UsersPath du fichier Search_param.xml

UsersPath indique le chemin du serveur Xlogf (des utilisateurs et donc des implicitesSQL.xml). C'est le chemin du fichier Connexions.xml. Par défaut /divalto/sys du serveur lui-même. Ce paramètre est particulièrement intéressant en mode ASP et Multi-environnements.
Attention : L'utilisateur doit cependant toujours être déclaré sur le serveur Search lui-même dans /divalto/sys/xlogf.dhfi.

Balise User du fichier Search_param.xml

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 le moteur d'indexation accède.

Balise Logging du fichier Search_param.xml

Logging à la valeur true permet de journaliser toutes les opérations d'indexation effectuées par le serveur. Cela permet notamment de connaitre les temps d'indexation. La journalisation est intéressante en phase de démarrage ou d'ajout de nouveaux documents. Il 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.

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 ou utilisez l'option de menu « Désinstallation Power search Serveur »
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.

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 Search

Si le nom du serveur correspond à son nom NetBIOS, l'adresse IP est facultative.

Harmony / Paramétrage / Serveurs

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.

Le serveur Search dans l'environnement utilisateur

Le nom du serveur Search est un paramètre de l'environnement de l'utilisateur.

Harmony / Paramétrage / gestion des Environnements

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.

Console d'administration du serveur Search

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.

Connexion au serveur Search

Création d'un profil consolesearch permettant l'accès aux serveurs Search via le programme Xsearchconsole.dhop.

Privilèges liés à la console Search

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.

Utilisation du Search

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.
Que s'est-il passé aujourd'hui dans l'entreprise ? Quelles sont les factures du jour ou de la semaine, les avoirs, les derniers événements de CRM ?
Trouver l'adresse d'un client ou d'un contact. Retrouver un compte-rendu de réunion à partir de quelques vagues souvenirs.
Divalto Power Search est la réponse à ce type de questions et de problématiques.
Par exemple, il va permettre de retrouver la fiche d'un client évidemment à partir de son nom, 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.
Il permet également d'avoir accès aux pièces qui ont été jointes aux divers documents.

L'écran Power Search

L'écran de Divalto Power Search est accessible depuis :

Le Widget Search.
Le menu et la barre d'outils des Zooms, par :
Le choix "Power Search" du menu "Edition".
Le bouton de la barre d'outils.
Le raccourci clavier Ctrl+E.

Exemple d'écran Power Search :

Requête
Tapez votre requête dans la zone de saisie puis tapez Entrée ou cliquez sur le bouton en forme de loupe.

Résultat de la requête
Les résultats de la recherche sont présentés par ordre de pertinence décroissante. Si le résultat souhaité n'apparaît pas en tête de liste, précisez votre recherche en ajoutant des mots clés supplémentaires.L'expression de recherche peut comporter des opérateurs logiques AND, OR ou NOT avec éventuellement des parenthèses. L'opérateur logique doit obligatoirement être en majuscule.

Exemples :
nebout AND evrard
nebout OR evrard
nebout AND NOT evrard
Il existe une notation abrégée des expressions logiques en utilisant les signes + et – :

Expression logique	Expression abrégée équivalente
nebout AND evrard	+nebout +evrard
nebout OR evrard	nebout evrard
nebout AND NOT evrard	nebout -evrard

Il est également possible de faire figurer des « jokers » dans la requête :

Une "*" représente une chaîne de caractères quelconque.
Un "?" représente un caractère quelconque.

Filtrage
Les options "Récent" et "Actif" permettent de restreindre la recherche à des documents récents ou actifs.Vous pouvez donner votre propre signification au paramètre "Récent" en mode Expert.
La colonne de gauche permet aussi de filtrer les documents par catégorie de recherche. Sélectionnez une catégorie en cliquant sur son libellé ou toutes les catégories en cliquant sur "Tout".
Vous pouvez choisir la liste des catégories que vous désirez voir apparaître dans cette colonne en sélectionnant l'un des groupes de catégories (domaine, famille, titre, dossier ou établissement) en mode Expert.

Accès au résultat
Un double clic sur une ligne de résultat lance l'application en charge de la présentation du document. Un double clic sur une pièce jointe visualise directement la pièce avec l'application associée (Word, Excel, Outlook, ...).

Affichage du résultat
Ligne bleu : le sujet
Ligne verte : les informations « techniques »
Ligne grise (facultative) : les pièces jointes
La présentation du résultat est paramétrable dans la balise presentation :

De Search_CommonFields pour l'ensemble des documents
De la description d'un document pour un document particulier.

Passage en mode Expert dans le Power Search

Cliquez sur le bouton « Mode Expert » de la barre d'outil. Ce mode Expert permet un filtrage plus fin des requêtes.
Dans l'exemple ci-dessous, le filtrage indique que le document doit appartenir au dossier courant pour les domaines "CommerceEtLogistique" ou "CRM" :

L'ergonomie de saisie des filtres est identique à celle du Zoom. En particulier, vous pouvez sauvegarder vos filtres dans des contextes. Le nom que vous donnez au contexte apparaît ensuite dans la colonne de gauche des filtrages du mode Simple.

La barre d'outils propose les boutons suivants :

Enlever les filtres.

Permet d'annuler les filtres existants.

Contextes.

Ouvre la fenêtre de gestion des contextes (voir le Zoom).

Catégories de recherche.

Ouvre la fenêtre de choix des catégories de recherche. Permet aussi de donner une signification personnalisée à l'option "Récent".

Mode simple.

Retour à l'écran de recherche simplifié.
De plus, le multi-choix en haut à droite de l'écran permet, le cas échéant, de sélectionner un serveur parmi l'ensemble des serveurs de recherches.

Choix des catégories de recherche dans le Power Search

Cette fenêtre permet de choisir les catégories de recherche que vous désirez voir apparaître dans la colonne de gauche des filtrages du mode Simple. Vous pouvez appliquer un contexte global de filtrage à ces catégories.
Dans l'exemple ci-dessous, la catégorie choisie est le titre (chaque document a un titre : client, facture, etc.) auquel s'applique le contexte global « Mon Dossier » :

Le premier multi-choix vous permet de sélectionner un groupe de catégories parmi les groupes suivants :
Domaine, Famille, Titre, Dossier ou Etablissement. Pour le groupe sélectionné, le tableau de droite affiche les catégories disponibles qui apparaîtront dans la colonne de gauche des filtrages du mode Simple.
Ainsi, si vous cliquez sur "Client" dans la colonne de gauche en mode simple, vous ne verrez affichés que les clients de votre dossier courant répondant à vos critères de recherche.

Le deuxième multi-choix permet de sélectionner un contexte global.
Dans cette fenêtre, vous pouvez aussi donner votre définition personnelle à l'option "Récent".

Configuration avancée du Power Search

Zooms
Le ZoomSQL en charge d'un document Search dans la base ERP (par exemple Client, Article, Contact, etc.) peut informer le serveur Search en cas de création, modification ou suppression d'une ligne.
La demande de ré-indexation du document est mise dans la file d'attente des actions du serveur.
Le serveur réindexe le document généralement dans les secondes qui suivent la demande.
Pour cela, il suffit de garnir dans les paramètres d'appel du zoom (accessible depuis le menu Divalto par shift F7) le dictionnaire Search et la référence du document dans ce dictionnaire.

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

Indexations périodiques
Le fichier Search_Scheduler.xml contient la liste des travaux périodiques à exécuter.

Les événements périodiques permettent de programmer des indexations par lot. Les événements à venir sont affichés dans la console Search.
Le choix « Relire le fichier paramètre des événements périodiques » doit être lancé en cas de modification.
La balise When journalière
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.
« 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
La balise When mensuelle
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 Day 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 ».

Exclure des documents
Le fichier paramètre Search_Param.xml permet de définir la liste des dictionnaires de description de documents. La balise Excluded permet d'exclure certains documents du dictionnaire concerné.

Stratégies d'indexation
Le fichier paramètre Search_Param.xml permet de définir la stratégie d'indexation des documents déjà existants dans la base Search.

L'indexation des documents (tous ou en partie) peut être réalisée en différé par rapport à leur création dans l'ERP.
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é.
Cette stratégie peut être redéfinie pour chaque document.

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 ».
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.
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.

Description d'un document
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. Elle est effectuée « 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.
A chaque document Search correspond à un arbre de RecordSQL
Exemple : Une facture
RecordSQL Facture
RecordSQL PiecesJointes
RecordSQL LignesDetail
RecordSQL PiecesJointesDetail
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.

L'entité de base dans la base SEARCH est le document. Chaque document est composé de Fields.
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.
Les champs alpha, les notes, les pièces jointes sont généralement analysés avant d'être injectés dans la base Search.
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
Propriétés des 'Fields' analyzed
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 apparait une forme du verbe chanter (chante, chantes, chanterons, chanterait, etc.).
'Fields' : Name
Dans la base Search, chaque field peut-être 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
Seuls les fields communs (qui servent de critères de filtrage) sont identifiés par un nom propre (Dossier, Etablissement, Auteur, etc.)

Documents
La description d'un document s'effectue en XML dans un dictionnaire de description 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.

Section Domain
Cette section indique le domaine du document

C'est un field commun à tous les documents. Il est proposé au filtrage pour les utilisateurs.
Section Family
Cette section indique la famille du document

C'est un field commun à tous les documents. Il est proposé au filtrage pour les utilisateurs.
Section Title
Cette section indique le titre du document

C'est un field commun à tous les documents. Il est proposé au filtrage pour les utilisateurs. Il doit être unique pour tous les documents.

Section 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.

Section 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.
Section 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.

Section Application
Elle 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.

Section Security
Elle 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 la « clef ».
Section RecordSQL
Elle 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.
Le premier RecordSQL définit le RecordSQL de base du document dans la base ERP.
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).
Remarque
Il n'y a pas de limite au nombre de niveaux.
Il peut y avoir plusieurs RecordSQL au même niveau.
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.
Field à Name donne le nom du field dans la base Search
On utilisera « Content » pour les champs génériques
Value Le nom du champ dans le RecordSQL
AnalyzedLe champ doit être analysé
IndexedLe champ servira d'index
Stored Le champ est stocké dans la base Search
Les attributs des fields sont facultatifs.
Valeurs par défaut :
AnalyzedEn fonction du type du champ
True pour les champs alpha
Indexed true
Stored false

Utilisation du Search depuis un champ en saisie

Le Divalto Search peut être appelé directement depuis un champ en saisie, en interaction avec une recherche en mode zoom. La touche CTRL+F dans un champ en saisie va transmettre la saisie au moteur Divalto Search, et piloter le zoom sur le résultat de cette recherche.
Exemple recherche de client : dans la création de pièce, le champ 'client' permet de saisir 'hugo' :

puis la combinaison de touche 'CTRL + F' appelle le zoom filtré par le résultat du search :

Ici, deux résultats par la présence de 'hugo' dans l'adresse du client.

Exemple recherche d'article :
Dans la saisie de ligne de pièce, le champ 'référence article' permet de saisir 'enfant' :

Puis la combinaison de touche CTRL + F appelle le zoom filtré par le résultat du search :

Ici, plusieurs résultats, notamment par la présence de 'enfant' dans la désignation du catalogue externe.

Paramétrage :
Le search doit être fonctionnel.
Dans la fiche Dossier commun, il faut permettre au Zoom d'utiliser la sélection en mode Power Search :

Dans la fiche Utilisateur commun, il faut indiquer le mode de fonctionnement du zoom pour l'utilisateur :

Notes :

Tous les zooms sont éligibles, à condition d'avoir un document search associé au menu, et que ce document traite la même table principale que le zoom.
Une fois piloté en mode 'sélection power search', le zoom bénéficie des autres critères en COMPLEMENT du résultat du search.
La recherche est, en nombre de caractères, restreinte par la taille du champ d'origine.

Navigateur non pris en charge