Développement >  Dictionnaire données >  Ouverture au paramétrage >  Modèles de données  

Afficher tout Masquer tout

Cette fonction permet de définir un groupe de tables liées (soit directement, soit en cascade), par des liens de type (1,1) ou (1,N) à une table principale supposée être en ligne.

Un tel modèle de données peut ensuite être utilisé :

  • dans une règle de Workflow, soit parce que c'est le seul contexte disponible pour décrire les tables à parcourir (cas d'une règle de type Manuel, où le modèle est obligatoire), soit pour enrichir le contexte de déclenchement (cas des autres types).
  • dans une règle d'affectation, où le modèle est obligatoire. Il définit alors le groupe de tables dans lequel se trouvent les champs sur lesquels est basée la règle d'affectation des utilisateurs. Le modèle de données associé à une règle de Workflow et celui associé à la règle d'affectation sont obligatoirement identiques.
  • dans un état ZPL, afin de décrire la logique d'extraction des données pour imprimer des étiquettes.
  • dans un modèle de paramétrage, afin de décrire les données de paramétrage à extraire ou à copier.
  • dans la description de données à indexer par un moteur de recherche.

Il est à noter que cette fonction est considérée comme faisant partie de développement, même si elle sert de support par ailleurs à un ensemble de paramétrage. Toute fiche créée par cette fonction doit donc être protégée par un code activité.

Pré-requis

Codes activité

Les codes activités suivants (classés par type) peuvent avoir une influence sur le comportement de la fonction :

Codes activités dépendants

Ces codes ne sont jamais saisis en gestion de dossier, car leur valeur est calculée :

  AUDIT (Audit).

Fonctionnel

  ABI :  Business Intelligence

  ASD :  SData

  ASEAR :  Moteur de recherche

  LEG :  Gestion multi-législations

Habilitations

Cette fonction est de type objet. Les opérations de création, modification, et suppression de fiche peuvent être activées ou désactivées pour un utilisateur donné. Des filtres par rôles peuvent également être mis en place sur cette fonction.

Gestion de l'écran

En-tête

Champs

Les champs suivants sont présents dans cet onglet :

Bloc numéro 1

Code identifiant la fiche courante.

  • Intitulé (champ ZINTIT)

Permet de définir un intitulé associé à chaque fiche.

Lorsque le modèle de données sert de support à une indexation par un moteur de recherche, cet intitulé apparaîtra comme un des types de documents dans lesquels la recherche est possible.

  • Actif (champ ENAFLG)

Cette case à cocher permet d'activer ou de désactiver la fiche courante sans pour autant perdre son contenu.
Une fiche désactivée ne peut pas être utilisée (par appel de son code) dans d'autres fiches (documents, paramétrages...), ou lors de traitements de masse.
Les habilitations sur une fonction donnée peuvent interdire la création d'une fiche active. Dans ce cas, la case est désactivée par défaut, et n'est pas modifiable autrement que par un utilisateur autorisé, ou via un circuit de signature défini par Workflow.

Bloc numéro 2

Un code activité permet :

  • de rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle.
  • de signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z.
  • de dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau.

Ainsi, si le code activité est non actif, l'élément marqué ne sera pas utilisable, et le code associé (s'il y en a) ne sera pas généré ni activable.

  • Module (champ MODULE)

Module d'appartenance du paramétrage.

Bloc numéro 3

  • Structure (champ FLGSTR)

Indique que le modèle de données est associé à une structure.

  • Modèle indexable (champ FLGEXA)

Indique que le modèle de données est associé à une indexation par le moteur de recherche.

  • Modèle de paramétrage (champ FLGAPH)

Indique que le modèle de données est associé à modèle de paramétrage.

  • Workflow (champ FLGWRK)

Indique que le modèle de données est associé à un workflow.

Fermer

 

Ecran de saisie

Présentation

On trouve dans l'écran de définition, l'ensemble de l'arborescence des tables à parcourir, toutes liées directement ou indirectement à une table principale. Les lignes du tableau définissent les jointures successives à réaliser pour disposer de tout le contexte en ligne.

A noter que des conditions peuvent être ajoutées pour filtrer les lignes liées. Il est important de noter que ces conditions ne sont pas prises en compte pour l'indexation. Les conditions liées aux données à indexer doivent en effet être définies dans l'onglet correspondant.

Fermer

 

Champs

Les champs suivants sont présents dans cet onglet :

Bloc numéro 1

Identifie la table principale à partir de laquelle on lit d'autres tables par des liens directs ou en cascade. Cette table est supposée être en ligne si le modèle est utilisé dans une règle Workflow de type différent de Manuel. Dans le cas d'un Workflow de type Manuel, elle fait partie de la jointure qui est ouverte et parcourue à l'exécution du Workflow.

Structure principale associée à la table principale.

Tableau

Identifie la table liée à la table origine.

  • Abrev (champ ABRLNK)

Correspond à l'abréviation sous laquelle la table liée est ouverte.

Si ce champ n'est pas saisi, on utilise l'abréviation par défaut de la table. Il peut être utile de saisir une abréviation pour ne pas rentrer en conflit avec le contexte appelant.

Identifie la table principale à l'origine du lien décrit dans la ligne courante. Ce peut être la table principale, ou une des tables liées des lignes précédentes.

  • Abrev (champ ABRORI)

Correspond à l'abréviation sous laquelle la table liée est ouverte.

Si ce champ n'est pas saisi, on utilise l'abréviation par défaut de la table. Il peut être utile de saisir une abréviation pour ne pas rentrer en conflit avec le contexte appelant.

Sous-structure associée à la table courante.

  • Clé (champ CLELNK)

Définit le code de la clé de la table utilisée pour réaliser la lecture des lignes liées. Par défaut, la première clé de la table est utilisée.

  • Type (champ TYPLNK)

Ce type prend l'une des valeurs suivantes :

  • 1,1 ou 0,1 : signifie que pour chaque ligne de la table d'origine, aucune ou une seule ligne de la table liée est lue (cette ligne est définie par l'expression de clé).
  • 1,N ou 0,N : dans ce cas, aucune ou plusieurs lignes de la table liée peuvent être lues. Elles sont définies par l'expression de clé, qui peut être incomplète  si elle est en plusieurs parties (les lignes dont les éléments de clés renseignés correspondent à la valeur donnée sont parcourues).
  • Expression de lien (champ EXPLNK)

Ce champ est défini comme une ou plusieurs expressions calculées séparées par un point-virgule. Chaque expression est évaluée, et le résultat permet de connaître la valeur de la clé utilisée pour réaliser la jointure. Lorsque les jointures multiples sont autorisées, on peut ne donner que les premiers éléments de la clé.

Dans les expressions, on peut utiliser des constantes, et des champs issus des tables précédemment définies dans la liste des liens.

  • Expression de sélection (champ EXPSEL)

Cette formule de sélection s'applique sur la table définie dans la colonne "Table liée", et permet de filtrer les données dans le modèle. Attention, ces conditions ne s'appliquent pas pour le processus d'indexation.

Fermer

 

Onglet Divers

Présentation

Cet onglet permet de définir des caractéristiques particulières du modèle de données, en fonction de l'utilisation qui en est faite.

Fermer

 

Champs

Les champs suivants sont présents dans cet onglet :

Workflow

  • Champ société (champ FLDCPY)

Ce champ définit la société courante, du point de vue de la règle de Workflow. Ainsi, lorsque la règle d'affectation est déclinée par société, on prend la bonne règle en fonction de la valeur du champ.

  • Champ site (champ FLDFCY)

Ce champ définit un site courant, ce qui permet d'en déduire la société courante (si elle n'est pas définie par le champ société), du point de vue de la règle de Workflow. Ainsi, lorsque la règle d'affectation est déclinée par société, la bonne règle est choisie en fonction de la valeur du champ.

Modèle de paramétrage

  • Champ législation (champ FLDLEG)

Ce champ permet de filtrer les enregistrements concernant une législation pendant la création d'un patch ou l'intégration d'un patch réalisé par la fonction ACOPAPH (modèles de patch).

Structure

  • Zone site (champ FCYSTR)

Champ de la structure définissant le site pour gérer les habilitations fonctionnelles.

Fonction utilisée pour gérer les habilitations fonctionnelles.

  • Zone code d'accès (champ ACCSTR)

Champ de la structure pour gérer les droits d'accès.

Fermer

 

Onglet Indexation

Présentation

Lorsque le modèle de données est indexable, cet onglet permet de définir comment l'indexation est faite, et quels sont les critères d'indexation qui permettront de définir des comptages lors des recherches. On définit également dans cet écran la façon dont le zoom se fait depuis l'écran de recherche vers la fonction d'affichage des données indexées.

La fonction de recherche permet, à partir d'une chaîne de caractères saisie, de rechercher dans un ensemble de "documents" toutes les occurrences de la chaîne. Un document correspond à un modèle de données, et l'intitulé du document, tel qu'il apparaît dans l'écran des résultats, est l'intitulé du modèle. Imaginons ainsi que l'on indexe les articles, les clients, et les commandes, et que l'on cherche l'intitulé "truc", on trouvera, en réponse, une liste de liens, ainsi qu'à droite, un décompte qui indiquera, par exemple, que "truc" a été trouvé 35 fois dans les articles, 50 fois dans les clients, et 678 fois dans les commandes. La liste à droite permettra ainsi de voir :

(résultats de recherche)                                   Documents
...                                                                  -------------
                                                                     Articles (35)           X
                                                                     Clients (50)            X
                                                                     Commandes (678)   X

Un simple clic sur l'intitulé Articles ne fera plus apparaître que les résultats de recherche pour les articles, alors qu'un clic sur la croix associée à l'article (X) exclura au contraire les articles de la recherche.

De la même façon, il est possible, outre le type de document, de définir des critères secondaires de filtrage, qui peuvent être soit communs à toutes les catégories (par exemple la date de création), soit partagés par certains documents seulement (le lieu de livraison peut être un critère commun au client et à la commande par exemple). Ces critères, les listes de valeurs pour lesquels la recherche est fructueuse, et le décompte du nombre de résultats apparaîtront alors comme autant de listes secondaires dans l'écran de recherche à droite.

Une annexe définit la façon dont est définie la politique d'indexation retenue.

Fermer

 

Champs

Les champs suivants sont présents dans cet onglet :

Général

  • Appliquer la sécurité (champ SECURITY)
  • Indexation champs par défaut (champ DEFFLG)

On indexera les champs alphanumérique des tables si cette case est cochée.

  • Dernière indexation (champ AASTP)

Fonction de retour

 

  • champ ABRLIE

 

  • Clé (champ CLE)

Tableau Champs

  • Champ (champ AFLD)

Définit le champ d'une des tables en ligne dans le modèle, avec la syntaxe [F:abv]nom, abv étant l'abréviation de la table et nom le nom du champ). Si le champ est dimensionné, on peut y ajouter un indice constant, avec la syntaxe [F:abv]nom(indice).

Ce champ peut être soit un champ qui n'aurait pas été indexé compte tenu de ses caractéristiques, et dont on souhaite forcer l'indexation (le champ Critère sera alors égal à non), soit un champ qui doit être un critère de filtrage visualisable à droite de l'écran de recherche (le champ Critère sera alors égal à oui).

  • Catégorie (champ ACATEG)

Si ce champ est égal à Oui, il est considéré comme un critère permettant, à l'instar du "document" correspondant au modèle, de réaliser des dénombrements et des filtres sur la valeur des champs correspondants.

Si par exemple on utilise, lors de l'indexation des pièces comptables, une catégorie métier sur le code journal, toute recherche sur les pièces comptables renverra non seulement la liste des éléments trouvés, mais également le nombre d'éléments trouvés pour chaque valeur de code journal concernée. Ainsi, si on recherche JOHN dans les écritures, et que cette recherche retrouve 200 pièces comptables sur le journal SALES, 350 sur le journal PURCHASE, 3 sur le journal MISC, et 25 sur le journal PAYMENT, on verra apparaître ce décompte à droit de l'écran de résultats de recherche, sous la forme suivante :

                                                                                                         Journal
VEN2342442   JOHN DEERE                                                             PURCHASE (350)     X
VEN3526126   SAINT JOHN  PERSE                                                  SALES (200)            X
VEN546236     JOHNNY WALKER                                                      PAYMENT (25)         X
PUR45356       JOHN WAYNE LDT                                                     MISC (3)                  X
PAT45236       JOHN LENNON MUSIC
...

Un clic sur l'un de ces intitulés restreindra la recherche au journal correspondant.

  • Intitulé catégorie (champ AAINTIT)

Cet intitulé (traduisible) n'a d'intérêt que si le champ est un critère.

Il est initialisé par défaut avec l'intitulé du champ critère tel qu'il est défini dans le dictionnaire, mais il peut être modifié (il deviendra alors un texte "spécifique" si on le personnalise).

Lorsque des critères portant le même intitulé sont présents sur plusieurs modèles de données, un regroupement est réalisé dans la partie droite (le compte du nombre de lignes trouvées par valeur de critère est cumulé pour l'ensemble des documents - ie. modèles de données - où la recherche est faite).

Note : par "même intitulé", on entend même numéro de texte traduisible (afin d'éviter un regroupement lorsqu'un même intitulé décrit des réalités différentes, comme c'est le cas par exemple pour le mot français "Etat", qui peut à la fois représenter une édition, une subdivision géographique, et la valeur d'une propriété).

Champs critères

  • Type base (champ AREQ)

Permet de faire apparaître et/ou de modifier le critère de filtre (au format SQL) en fonction du type de la base de données utilisée.

  • champ WREQ

Ce champ permet de définir, au format SQL, une requête qui sera utilisée comme filtre supplémentaire lors de l'extraction des données à indexer. Les champs de la base sont exprimés sous la forme ABV.CHAMP_i, où ABV est l'abréviation utilisée pour la table dans le modèle, CHAMP le nom du champ, i l'indice (0 sur des champs mono-dimensionnés). Ceci donne, par exemple, BPC.BPCNUM_0 pour un champ BPCNUM issu de la table d'abréviation BPC.

Fermer

 

Boutons spécifiques

Les champs suivants sont présents dans la fenêtre ouverte par ce bouton :

Bloc numéro 1

  • champ OBJET

 

  • champ CLES

 

Bloc numéro 2

  • Depuis le dossier (champ DOSORG)

Ce champ permet de définir le dossier à partir duquel la fiche va être copiée. Les syntaxes possibles sont décrites dans l'annexe dédiée.

  • Tous dossiers (champ TOUDOS)

Cette option permet de copier la fiche vers tous les dossiers définis dans le dictionnaire (table ADOSSIER de la solution courante).

  • Vers le dossier (champ DOSDES)

Ce champ permet de définir le dossier dans lequel la fiche va être copiée. Les syntaxes possibles sont décrites dans l'annexe dédiée.

Fermer

Permet de copier la fiche courante vers un autre dossier.

Génère le code lié au modèle de données :

  • s'il est associé à une structure, on valide les structures et on génère le traitementWMLxxxxxx correspondant
  • s'il est indexable, on crée la ou les requêtes SQL dont le moteur de recherche a besoin pour indexer la base.

Barre de menu

Visualisation / Requête

Lors de la validation d'un modèle indexable, le superviseur définit la requête SQL qui permettra au moteur de recherche d'extraire les données en vue de l'indexation. Ces requêtes peuvent être extrêmement complexes, et il importe de rester dans des limites raisonnables en termes d'informations à indexer, afin de ne pas soumettre à la base des requêtes trop lourdes à exécuter. Ce bouton permet de visualiser la requête qui sera transmise au moteur d'indexation.

Messages d'erreur

Il n'y a pas de message d'erreur autre que les messages d'erreur génériques.

Tables mises en oeuvre

Les tables suivantes sont mises en oeuvre par la fonction :

Table

Intitulé Table

ALINK [ALI]

Explorateur de liaisons

ASTR [ASE]

Structures

ATABIND [ATI]

Dictionnaire des index

ATABLE [ATB]

Dictionnaire des tables

ATABZON [ATZ]

Dictionnaire des champs

ATEXTRA [AXX]

Textes à traduire

AWRKLNK [AWM]

Modèles de données

AWRKPAR [AWA]

Règles Workflow

AWRKREG [AWR]

Règles d'affectation

Politique d'indexation

Lors du processus d'indexation, une requête générée à la validation du modèle est exécutée pour récupérer les données à indexer, ainsi que les critères correspondants. Afin que cette requête reste d'une taille raisonnable, seuls certains champs sont extraits des tables en ligne dans le modèle afin de mettre à jour l'index.

Détermination des champs inclus dans l'extraction

Par défaut, les données extraites de la base pour être indexées sont les suivantes :

  • tous les champs de type alphanumérique de toutes les tables du modèle, s'ils ont un type de données non rattaché à un objet (et si ce ne sont pas des textes traduisibles type AXT, ATX, AX*).
  • tous les champs de type date de toutes les tables du modèle.
  • tous les champs "intitulés" et "intitulés longs" des tables du modèle (même s'ils sont traduisibles), ainsi que les champs définissant la clé de l'objet associé au modèle.

A cette liste sont rajoutés tous les champs indiqués dans le tableau Champs, qu'ils soient considérés comme catégorie ou pas, et qu'ils soient traduisibles ou pas, avec les règles suivantes :

  • si ces champs sont d'un type associé à un objet, on indexe non seulement le champ correspondant (ie. la valeur de clé de l'objet lié), mais également les champs intitulés associés à la table principale de l'objet, qu'ils soient traduisibles ou pas.
  • si ces champs sont de type menu local, on indexe l'intitulé associé et non pas sa valeur.

Champs dimensionnés

Lorsque les champs correspondants sont dimensionnés, seul le premier indice est pris en compte. Si on désire indexer d'autres indices du tableau, il faut les saisir sous la forme champ(indice) dans le tableau des critères.

Champs traduisibles

Lorsque des champs sont traduisibles (ie. s'il ont un des types ATX, AXT, AX1, AX2, M), on n'indexe non pas le pointeur sur le texte, mais le texte lui-même, en faisant une jointure avec la table correspondante (ATEXTE pour les textes liés aux objets de développement, ATEXTRA pour les textes liés aux données, APLSTD pour les menus locaux).

Ceci est bien entendu également valable pour les tables diverses (ADI). Des champs de ce type ne sont pas indexés par défaut, mais s'ils sont explicitement listés dans la liste des champs à indexer, l'indexation va se faire à la fois sur le code et sur l'intitulé traduisible associé.

L'indexation se fera alors soit sur l'intitulé dans une seule langue (dont le code est défini par la valeur du paramètre ASEARLAN), soit sur les intitulés exprimés dans la totalité des langues dans lequel le dossier est géré (si ASEARLAN est vide).

Indexation complète ou incrémentale

La requête définie à la validation du modèle permet d'extraire la totalité des données de la base afin de procéder à l'indexation. Cette requête peut être extrêmement lourde (il peut y avoir beaucoup de champs à extraire), et en outre elle peut ramener un nombre important de lignes.

C'est pourquoi il peut être utile de savoir également indexer de façon incrémentale, c'est-à-dire de n'indexer que les données ayant été modifiées depuis la dernière fois où la base a été indexée.

Ceci est réalisé de façon automatique dès lors qu'un champ nommé UPDSTP existe dans la table principale du modèle. Si ce champ existe, il stocke un "timestamp" (horodatage exprimé en millisecondes depuis le 1er janvier 1970) permettant de savoir à quel moment la dernière mise à jour a été faite sur chaque ligne. Ce champ est géré par le moteur SAFE X3 : dès lors que les mises à jour sont faites par les instructions Rewrite, Update, ce champ est mis à jour.

A partir du moment où le champ UPDSTP existe dans la table principale du modèle, la validation du modèle crée deux requêtes : une requête permettant d'extraire la totalité des données des tables associées au modèle, et une requête ne permettant que d'extraire les données modifiées depuis la dernière indexation.