SOMMAIRE

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

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 / personnalisation

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 :

• <Presentation>

• <CommonFields>

• <Security>

• <RecordSQL>

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

Association aux applications pour ouverture de documents

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

Sécurité et confidentialités

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 :

• La confidentialité des documents

• La confidentialité des instances des documents

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