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é :
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é.
Les codes activités suivants (classés par type) peuvent avoir une influence sur le comportement de la fonction :
Ces codes ne sont jamais saisis en gestion de dossier, car leur valeur est calculée :
AUDIT (Audit).
ABI :
Business Intelligence
ASD :
SData
ASEAR :
Moteur de recherche
LEG :
Gestion multi-législations
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.
Champs
Les champs suivants sont présents dans cet onglet :
Bloc numéro 1
|
Code identifiant la fiche courante. |
|
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. |
|
Cette case à cocher permet d'activer ou de désactiver la fiche courante sans pour autant perdre son contenu. |
Bloc numéro 2
|
Un code activité permet :
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 d'appartenance du paramétrage. |
Bloc numéro 3
|
Indique que le modèle de données est associé à une structure. |
|
Indique que le modèle de données est associé à une indexation par le moteur de recherche. |
|
Indique que le modèle de données est associé à modèle de paramétrage. |
|
Indique que le modèle de données est associé à un workflow. |
Fermer
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. |
|
Identifie la table liée à la table origine. |
|
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. |
|
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. |
|
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. |
|
Ce type prend l'une des valeurs suivantes :
|
|
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. |
|
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
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
|
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. |
|
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
|
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
|
Champ de la structure définissant le site pour gérer les habilitations fonctionnelles. |
|
Fonction utilisée pour gérer les habilitations fonctionnelles. |
|
Champ de la structure pour gérer les droits d'accès. |
Fermer
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
|
|
On indexera les champs alphanumérique des tables si cette case est cochée. |
|
Fonction de retour
|
|
  |
|
  |
|
Tableau Champs
|
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). |
|
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 Un clic sur l'un de ces intitulés restreindra la recherche au journal correspondant. |
|
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
|
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. |
|
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
|
Les champs suivants sont présents dans la fenêtre ouverte par ce bouton : Bloc numéro 1
Bloc numéro 2
Fermer Permet de copier la fiche courante vers un autre dossier. |
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.
Les tables suivantes sont mises en oeuvre par la fonction :
Table |
Intitulé Table |
---|---|
ALINK [ALI] |
Explorateur de liaisons |
ASTR [ASE] |
|
ATABIND [ATI] |
Dictionnaire des index |
ATABLE [ATB] |
|
ATABZON [ATZ] |
Dictionnaire des champs |
ATEXTRA [AXX] |
Textes à traduire |
AWRKLNK [AWM] |
Modèles de données |
AWRKPAR [AWA] |
|
AWRKREG [AWR] |
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.
Par défaut, les données extraites de la base pour être indexées sont les suivantes :
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 :
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.
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).
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.