Aller directement à la fin des métadonnées
Aller au début des métadonnées

Vous regardez une version antérieure (v. /wiki/spaces/PAI/pages/11451498548/Technique+et+surcharge+Search) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 2) Actuel »

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 :

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

Exemple d’ajout d’informations à un document existant

Prenons l’exemple d’une table METIER ajoutée dans le cadre de la gestion commerciale à la fiche client (sous-table du client), et que l’on souhaite ajouter au document Search “Client”.

Etape 1 : analyser ce qu’on l’on souhaite traiter et exposer dans le Search

Cette étape, non décrite ici, est importante pour déterminer les données à lire (tables, champs) et les pièces joints à intégrer.

L’exemple ici se limite à un code et libellé de la sous-table METIER qui porte un lien vers le client (champ TIERS). De nombreux exemples sont disponibles dans les documents standards fournis avec l’ERP

Voir le chapitre dédié dans la page dédiée aux documents Search

Etape 2 : ajouter/modifier un recordSql pour l’accès SQL aux données

Ces étape de développement consiste à ajouter, dans un recordSQL en surcharge du recordSql Gestion commerciale pour search(dav_sd.dhsq), le recompiler et livrer.

Il existe notamment dans notre exemple 2 cas:

  • on ajoute simplement un champ au RecordSql que l’on veut compléter

  • si la table METIER a elle-même un Document dédié, on peut ré-utiliser ce recordSql et le mettre en “sous-table” du client

L’exemple illustre le second cas

On a mis dans cet exemple le champ MetierLib dans un nouveau recordSql ‘Metier’

image-20240906-125058.png

Etape 3 : modifier le fichier de description du document

On va ici modifier le fichier standard lié à la gestion commerciale “dico_document_dav.xml” pour ajouter un nouveau document ou modifier un document.

Comme précédemment, il y a 2 cas:

  • si on a ajouté un champ au recordSql, alors il faut ajouter un “<Field Name=”Content” Value=monChamp”

  • si on a une sous-table, alors on va ajouter un sous-document avec un lien vers l’entité principale

On va donc modifier ici, pour le second cas, “dico_document_dav.xml”

image-20240906-125429.png

et ajouter un sous-recordSql en utilisant nécessairement le champ WHERE pour faire le lien entre le client et la sous-table. Attention ne pas oublier le DOS (dossier courant)

image-20240906-131534.png

Etape 4 : re-lire, re-indexer et tester

Une fois le document “dico_document_dav.xml”, on utilisera la console pour relire les paramètres, re-indexer, et vérifier le résultat en tapant un libellé de métier dans le search

  • Aucune étiquette