Présentation de Divalto Power Search
...
Architecture de Divalto Power Search
...
Documents
...
Indexation
...
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
...
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
...
Confidentialités
...
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.
...
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.
...
Installation
...
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.
...
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.
...
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.
...
L'option de journalisation des actions du serveur.
...
Service DhsSearchServer
...
Désinstallation du serveur Search
...
Choix de l'analyseur
...
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
...
Table des serveurs
...
Environnement utilisateur
...
Introduction
...
Stratégie "Always"
...
Stratégie "Modified"
...
Stratégie "Recent"
...
Stratégie "Never"
...
Console
...
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
...
Indexations
...
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
...
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.
...
Zoom
...
Autres applications
...
Conception d'un 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.
...
Description d'un document
...
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
...
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.
...
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.
...
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.)
...
Field commun
...
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.)
...
Field commun Name
...
Field commun Value
...
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.
...
Field commun Analyzed Indexed Stored
...
Analyzed (par défaut False)
Indexed (par défaut True)
Stored (par défaut True)
...
Field commun Displayed
...
Field commun Current
...
Field commun DefaultValue
...
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
...
Document <Domain>
...
Document <Familly>
...
Document <Title>
...
Document <IndexExistingDocument>
...
Document <Presentation>
...
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>
...
Document <Security>
...
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
...
RecordSQL RecordSQL
...
RecordSQL Condition
...
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.
...
RecordSQL DoSelect
...
RecordSQL <Field>
...
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.
...
Field Type
...
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
...
Surcharge CommonFields
...
Surcharge Security
...
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.
...
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
...
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
...
Confidentialité des documents
...
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.
...
| Astuce |
|---|
Puissant moteur de recherche transversale de la solution, cette fonction Power Search permet de questionner et de retrouver rapidement toute information dans les bases de données et les documents archivés. |
| Pages enfant (affichage des enfants) | ||
|---|---|---|
|