Www.absyscyborg.com.

SUPERVISEUR SAGE X3 ENTREPRISE V140

Plan général du cours 1- Généralités 2- Paramétrages de base
1.1 Définition du superviseur 1.2 Rappels sur l’architecture technique 1.3 Organisation des fonctions 1.4 Paramétrage et développement 1.5 Sociétés et sites 2- Paramétrages de base 2.1 Introduction aux formules Adonix 2.2 Paramètres de base 2.3 Workflow 2.4 Paramétrages des fonctions 3- Exploitation 3.1 Imports et exports 3.2 Gestion des états 3.3 Destinations d’impression 3.4 Portail utilisateur 3.5 Gestion des styles 3.6 Personnalisation du vocabulaire 3.7 Le serveur batch 4- Administration 4.1 Gestion des dossiers 4.2 Epuration et historisation 4.3 Gestion de patches et de version 4.4 Gestion des sessions 4.5 Utilitaires 5- Introduction au développement 5.1 Pérennisation et codes activités 5.2 Tables et index 5.3 Types de données : menus locaux, tables diverses 5.4 Ecrans et fenêtres 5.5 Nouveaux paramètres 5.6 Fonctionnement de base d’un objet

1. Généralités 1- Généralités 2- Paramétrages de base 3- Exploitation
1.1 Définition du superviseur 1.2 Rappels sur l’architecture technique 1.3 Organisation des fonctions 1.4 Paramétrage et développement 1.5 Sociétés et sites 2- Paramétrages de base 2.1 Introduction aux formules Adonix 2.2 Paramètres de base 2.3 Workflow 2.4 Paramétrages des fonctions 3- Exploitation 3.1 Imports et exports 3.2 Gestion des états 3.3 Destinations d’impression 3.4 Portail utilisateur 3.5 Gestion des styles 3.6 Personnalisation du vocabulaire 3.7 Le serveur batch 4- Administration 4.1 Gestion des dossiers 4.2 Epuration et historisation 4.3 Gestion de patches et de version 4.4 Gestion des sessions 4.5 Utilitaires 5- Introduction au développement 5.1 Pérennisation et codes activités 5.2 Tables et index 5.3 Types de données : menus locaux, tables diverses 5.4 Ecrans et fenêtres 5.5 Nouveaux paramètres 5.6 Fonctionnement de base d’un objet Ce premier chapitre introductif va permettre de poser les bases du cours : Où se situent exactement les fonctions qui vont être détaillées dans ce cours, et à quoi elles servent Quelques rappels techniques (très limités) Architecture des fonctions, ce qui permettra de bien comprendre ce qui est paramétrable et à quel niveau

Code applicatif (modulaire)
1.1 Définition du superviseur Un développement en couches Code applicatif (modulaire) Services de base (superviseur) Moteur adonix (machine virtuelle) Base de données Par principe : chaque couche utilise les couches de la couche précédente Lorsque le trait de séparation horizontal est complet, il y a indépendance entre les couches En pratique : Le superviseur et le développement sont indépendants du système d’exploitation et de la base de données (grâce à la machine virtuelle) Le superviseur, écrit à l’aide du moteur ADONIX, fournit des services de base à tous les modules Système d’exploitation

Services de base (superviseur)
1.1 Définition du superviseur Un ensemble de services généraux Services de base (superviseur) Gestion de la base de données et de la configuration Gestion des utilisateurs et des habilitations Gestion des restitutions (statistiques, états, interrogations…) Gestion des paramètres Gestion des travaux batch Gestion des mises à jour du logiciel Outil de développement pour spécifiques La liste ci-dessus donne les grandes fonctions du superviseur, telles qu’elles vont être développées dans la suite du cours La partie Outils de développement fait partie d’un cursus à part et ne sera pas développée en détail dans ce cours. Mais certaines fonctions de maintenance, qui font partie de l’outil de développement, et quelques paramétrages très avancés sont abordés dans le cours superviseur. En outre, le cours se termine par une introduction au développement afin de permettre aux consultants fonctionnels d’appréhender les limites entre développement et paramétrage, voire de réaliser certains développements dont la simplicité de mise en œuvre les rapproche du paramétrage.

1.2 Rappels sur l’architecture technique
Une architecture client/serveur / Web TCP/IP Client Windows Windows NT/2000/XP TCP / IP Serveur Web Windows ou Linux IIS, ou Apache Client Web Windows IE >= 5.5 Serveur X3 Windows NT/2000/2003 Unix (AIX, HP-UX) Linux (Red Hat sous Intel) L’animation permet de partir de l’architecture la plus simple à l’architecture la plus complexe : Un serveur et un client (le client pouvant fonctionner sur le serveur X3 s’il est Windows) Un serveur Web servant des clients Web en plus (le serveur Web pouvant aussi fonctionner sur le serveur X3) Il est important de noter : Que le client Windows ne fonctionne (en 140) que sous Windows 2000, 2003, et XP (pour cause d’Unicode) Que le client Web a les mêmes pré-requis (avec en plus une résolution d’écran minimale de 1024*768)

Une architecture évolutive en multi-tiers
1.2 Rappels sur l’architecture technique Une architecture évolutive en multi-tiers Réseau local Serveurs de traitement LAN / WAN Client Windows Serveurs web Serveur d’application TCP / IP Client Web Serveur de données L’animation permet de partir de l’architecture la plus simple à l’architecture la plus complexe : Un serveur d’application et un serveur de données séparé Des serveurs de traitements complémentaires Des serveurs Web complémentaires rattachés à l’un des serveurs de traitement ou d’application Il est important de noter : Que cette architecture permet de faire évoluer la configuration pour la rendre plus puissante par simple ajout de serveurs interchangeables et peu chers Que les serveurs en rouge (application et données) doivent être sécurisés (et peuvent n’être qu’un seul) Que la base de données est sur le serveur de données, mais que les fichiers du dossier sont sur le serveur d’application Que le serveur batch tourne sur le serveur d’application Que les serveurs de traitement ne font qu’exécuter à la demande pour des clients du code chargé depuis le serveur d’application La console de configuration permet de gérer facilement les architectures complexes de ce type. Base de données TCP / IP SQL Server v7/8 Oracle v8/8i/9i

On se connecte sur un dossier ADONIX X3 : qui utilise un ensemble de modules qui intègre un référentiel (paramétrage, développement spécifiques) commun qui gère des données (statiques, mouvements) On s’identifie comme un utilisateur, ce qui définit, dossier par dossier : les habilitations des valeurs par défaut La langue de connexion peut varier d’un utilisateur à l’autre Ceci a normalement été vu en cours Tronc commun Il est important de noter : qu’un paramétrage est fait dans un dossier (et un seul) que des outils de copie permettront de le propager qu’un développement peut être partagé par N dossiers Les langues de connexion possibles sont définies lors de la création d’un dossier. A ce jour, les langues suivantes sont gérées par l’éditeur : Anglais US Anglais british Espagnol Italien Français Portugais Chinois moderne Chinois simplifié D’autres langues ont été faites par des partenaires Langue de connexion Utilisateur dans le dossier Dossier

Des connexions secondaires sont possibles : à partir d’une session ouverte sur le même dossier, le même utilisateur, dans la même langue Deux méthodes : par Fichier / Session secondaire par l’appel d’une touche de fonction (Shift F5 à Shift F12) paramétrable par utilisateur On verra plus loin (en gestion des licences) comment sont définies les connexions possibles

Comptabilité générale
1.3 Organisation des fonctions ADONIX X3 est organisé en modules hiérarchiques : …Chaque module intègre un ensemble de fonctions Superviseur Tronc commun Modules spécifiques Stocks Développement Comptabilité générale Les modules utilisés sont définis lors de la création d’un dossier. Les modules Superviseur,Tronc commun et Développement sont indispensables. NB : le module Immos, qui existait en version 130, a été supprimé. Désormais, on dispose d’un produit ABEL X3, qui permet de gérer les immobilisations. Chaque fonction est rattachée à un module et un seul. Ventes Achats GPAO Tiers Action commerciale Support client

1.3 Organisation des fonctions
ADONIX X3 est organisé en fonctions appelées : depuis une ligne de menu depuis une page HTML (portail, assistants) par le biais d’un lien depuis une autre fonction (appel en “tunnel” ou en “zoom”) Les fonctions sont à la base : de l’habilitation (définition des accès par utilisateur et fonction) de l’organisation des menus Une fonction : est identifiée par un nom [ GFONCTION depuis la calculette ] peut être vue par une info-bulle depuis le menu est (le plus souvent) rattachée à un modèle permettant des paramétrages Une fonction correspond à la fois à un objet technique du progiciel, mais aussi et surtout à une fonction que l’utilisateur va mettre en œuvre dans le progiciel.

Permettent de rendre génériques : les paramétrages l’ergonomie De 3 types principaux objets [ GFONCTION = GESXXX ] consultations [ GFONCTION = CONSXXX ] traitements [ GFONCTION quelconque ] Les modèles sont très importants car ils normalisent le fonctionnement d’un progiciel, et permettent facilement de voir quels sont les possibilités de paramétrage générique associées En version 140, on a environ : 50% des fonctions de type objet 10% des fonctions de type consultation 30% des fonctions de type traitement 10% des fonctions de type autres

Le modèle objet Liste(s) de gauche Onglets   En-tête

Le modèle objet Correspond à : la gestion “standard” (création, modification, consultation, suppression) d’une table ou d’un ensemble de tables de la base avec des listes gauches (sélection, picking, liaisons), des possibilités de filtrage, de sélection avancée… Peut intégrer des variantes : elles sont nommées des transactions. elles se caractérisent par des écrans différents (on peut ainsi ne pas tout faire apparaître) et parfois par des règles de gestion différentes L’objet peut se paramétrer à différents niveaux : listes gauches (de façon générique) contenu des onglets (transactions fonctionnelles) passage à d’autres fonctions (liaisons, navigations, opérations du menu Fichier) Le modèle objet est le plus riche en terme de paramétrages possibles C’est aussi le plus fréquent

Le modèle consultation
1.3 Organisation des fonctions Le modèle consultation Onglets de consultation   Critères en tête Fenêtre de critères  complémentaires

Le modèle consultation
1.3 Organisation des fonctions Le modèle consultation Correspond à : l’interrogation de données d’une table ou d’un ensemble de tables de la base sans mise à jour avec des critères de sélection en tête d’écran et dans une fenêtre avancée, possibilité de mémorisation… avec en général des zooms vers le détail Peut intégrer des variantes : elles sont nommées des écrans de consultation. Peut se paramétrer de façon générique : par le paramétrage des écrans de consultation Le modèle consultation est le moins fréquent Il est paramétrable au niveau de la présentation des colonnes

Le modèle traitement Saisie des critères Exécution du traitement  Affichage de trace 

Le modèle traitement Correspond à : des traitements de masse dont l’exécution peut être longue précédés par une saisie de paramètres mémorisables lancés en direct ou en batch Au niveau du paramétrage : correspond normalement à une tâche standard du serveur batch Le modèle traitement offre très peu de paramétrages (sauf les paramétrages génériques) Mais il gère de nombreuses fonctions (celles qui sont batchables).

D’autres modèles… Beaucoup plus rares de type “composite” (plan de travail) complètement atypiques (éditeur de traitement…) Peu de possibilités de paramétrage sauf des paramétrages génériques de toute fonction : tables de contrôle, code d’accès, styles conditionnels, changement de vocabulaire paramètres généraux de configuration associés l’habilitation par fonction, sous-fonction, filtres sur sites et sociétés…

1.4 Paramétrage et développement
Le paramétrage est pérenne conservé en changement de version non modifié par une mise à jour de patches Le spécifique doit être protégé pour être pérenne chaque élément modifié doit être marqué par un code activité spécifique. un patch standard ne modifiera alors pas le spécifique un patch spécifique peut le modifier Certaines fonctions résultent d’une combinaison de paramétrage et de développement Une partie est alors du développement, une autre de la personnalisation Remarques : Ces différences peuvent paraître subtiles, mais elles n’en sont pas moins fondamentales. Dans la suite du cours : 90% des fonctions qui seront vues sont du paramétrage On reconnaîtra en général les autres à la présence d’un code activité. Lorsqu’un champ code activité est présent : une modification doit être « signée » par un code commençant par X, Y, ou Z le code doit par ailleurs être activé si ceci n’est pas fait, la modification n’est pas pérenne, et peut disparaître inopinément à la faveur d’un patch qui toucherait l’élément en question, ou de façon certaine en cas de revalidation de dossier Plus d’informations seront données en gestion de dossiers.

SOCIÉTÉ NON JURIDIQUE NJ1
1.5 Sociétés et sites Paramétrage / Structure générale / … Paramétrage / Structure générale / … Une action de gestion (un « mouvement ») ne peut être effectuée dans X3 sans être rattachée à un site ou à une société, informations structurantes du dossier : Tiers, produits, etc… DOSSIER SOCIÉTÉ C1 SOCIÉTÉ C2 Pièces comptables SITE FINANCIER F1 SITE FINANCIER F2 SITE FINANCIER F3 SITE FINANCIER F4 SOCIÉTÉ NON JURIDIQUE NJ1 Commandes d’achat Mouvements de stock Certains mouvements peuvent mettre en jeu plusieurs sites et/ou sociétés… SITE S1 SITE S2 SITE S3 SITE S4 SITE S5

1.5 Sociétés et sites Paramétrage / Structure générale / … Paramétrage / Structure générale / … Les sociétés et sites interviennent essentiellement : dans la définition des paramètres dans les habilitations et le filtrage des données Il est à noter que : on ne se connecte pas sur un site (le site est saisi dans les documents où il intervient) mais on a des sites par défaut par module (qui dépendent du profil de l’utilisateur) On visualisera rapidement les fiches sociétés, sites, groupes de sites

2. Paramétrages de base 1- Généralités 2- Paramétrages de base

2.1 Introduction aux formules ADONIX
Une formule est une expression calculée pouvant être évaluée, faisant appel à des constantes, des variables, des fonctions Adonix et des opérateurs. À tout moment dans X3, la calculette peut être lancée pour évaluer une formule se rapportant au contexte. Les formules sont utilisées dans de nombreux cas de paramétrage Les formules sont notamment utilisées : Dans le Workflow En définition des paramètres d’état En personnalisation d’objet Pour définir les propriétés d’objet Dans les statistiques … et bien entendu partout dans le développement

Formules simples Constantes Valeur numérique signée ou non -273 Chaîne de caractères "Aujourd’hui" ‘Vous avez dit : "Bizarre" …’ Date [29/05/1959] Condition Toute valeur numérique non nulle est considérée comme vraie (le résultat d’une comparaison renvoie 1 si la comparaison est vraie) Toute valeur numérique nulle est considérée comme fausse

Formules simples Opérateurs numériques * / ^ Date Date – date Date + nombre Date - nombre Caractères Chaine + Chaine Chaine - Chaine Niveau de parenthésage illimité Notes : Date – Date donne un nombre de jours Date +/- nombre donne une date Chaine+Chaine concatène deux chaînes Chaine-Chaine concatène deux chaînes en les séparant par un espace

Variables Dépendent d’un contexte d’exécution Liées à une « classe » définie entre crochets TYPE DE VARIABLE SYNTAXE A UTILISER EXEMPLES Valeur d’un champ dans l’enregistrement courant d’une table en ligne [F:abv]nom abv=abréviation de la table nom=nom du champ [F:BPC]BPCNUM Valeur d’un champ d’écran (situé dans un onglet visible ou non) [M:abv]nom abv=abréviation de l’écran nom=nom du champ [M:BPC0]BPCNUM Variable globale [V]nom la classe peut être omise le nom commence par G GNBGAUCHE GUSER GFONCTION GOLDETAT Variables système [S]nom la classe peut être omise le nom est en minuscules (mot-clé) datesyst nomap indcum Une des difficultés que l’on peut avoir est de connaître le contexte dans lequel on se trouve dans une fonction donnée. Plusieurs réponses peuvent être données à ce niveau : Dans un objet standard, la table principale gérée est ouverte sous son abréviation « habituelle » (si on ne la connaît pas, on peut consulter la documentation de la fonction : en annexe, les tables gérées (et leur abréviation). Les écrans, quant à eux, peuvent être connus grâce à la touche F6; utilisée dans toute fonction, elle affiche les caractéristiques du champ courant et le nom de l’écran. La plupart des paramètres généraux (cf. plus loin), dès lors qu’il sont globaux ou définis par utilisateur, sont associés à une variable globale dont on peut donc lire la valeur. C’est par exemple le cas de GNBGAUCHE donnée en exemple ci-dessus; cette variable correspond au nombre maximum de lignes chargées dans la liste gauche. A propos des exemples donnés ci-dessus : [F:BPC]BPCNUM correspond à la clé de la fiche client (table BPCUSTOMER d’abréviation BPC). [M:BPC0]BPCNUM correspond à la valeur saisie ou affichée dans l’en-tête de l’objet BPC, qui gère les clients. En général (sur un objet nommé XXX), les écrans ont pour abréviation [M:XXX0] pour l’en-tête, et [M:XXXi] pour l’onglet i (mais ce n’est pas une règle absolue). GUSER donne le code de l’utilisateur connecté GFONCTION donne le code de la fonction en cours d’utilisation GOLDETAT donne le code du dernier état lancé datesyst donne la date logique de connexion (déterminée à partir de la date saisie dans la boîte de connexion). Ne pas confondre avec la date système (qui est une fonction nommée date$) nomap est le code du dossier courant indcum est l’indice de cumul courant utilisé par la fonction sigma par défaut

L’éditeur de formules Appelable chaque fois qu’une formule de calcul peut être saisie Permet de retrouver les champs des écrans et des tables Est normalement lié au contexte L’éditeur de formule propose par défaut une liste de classes de variables en ligne dans le contexte défini par le paramétrage. Dans l’exemple ci-dessus, on est en paramétrage du Workflow, l’événement déclenchant étant la commande client. On a en ligne : Les écrans SIH0 à SIH4 (en-tête + 4 onglets), ainsi qu’un écran technique SIHV La table SINVOICEV qui est la table principale gérée par l’objet facture La table AUTILIS qui est toujours en ligne

Les tableaux de variables
2.1 Introduction aux formules ADONIX Les tableaux de variables Certains écrans X3 contiennent des tableaux. Les champs sont alors indicés (ex : factures de vente). Note : les indices commencent à 0 (les lignes à 1) [M:SIH3]QTY(0) [M:SIH3]QTY(1) [M:SIH3]QTY(2) [M:SIH3]QTY(3) Notes pour les développeurs : Dans un tableau de N lignes, il existe une variable système nommée nolign qui donne le numéro de la ligne courante (de 1 à N) , et une variable système indice qui donne la valeur d’indice (de 0 à N-1), mais ces variables, très volatiles, doivent être manipulées avec précaution. Tout tableau dans un écran possède une variable associée (déclarée dans la définition du bloc, de type ABS) qui contient le nombre de lignes réellement saisies. F6 permet de connaître son nom quand on a le « focus » sur le tableau sans être en saisie.

Fonctions De nombreuses fonctions sont disponibles pour exprimer des formules numériques pi abs(N) mod(N,M) arr(N,N) ar2(N) log(N) exp(N) sin(N) … val (C) day(D) month(D) year(D) ascii(C) instr(N,C,C) … dates date$ addmonth(D,N) eomonth(D) gdat$(N,M,P) … caractères string$(N,C) num$(N) chr$(N) left$(C,N) right$(C,N) seg$(C,N,M) mid$(C,N,M) format$(C,X) space$(N) vireblc(C,N) ctrans(C) ctrans(C,C,C) … Note pour la compréhension des syntaxes : N = un argument numérique, C = un argument chaîne de caractères, D = un argument date X = un argument de type quelconque Détail des fonctions pi= … abs=valeur absolue mod=modulo arr et ar2 = arrondis log et exp = logarithme, exponentielle sin=sinus (cos, tan, asin, acos, atan, sh, ch, th, ach, ash… existent aussi) val transforme une chaîne en valeur numérique, day, month, year extraient les composantes d’une date ascii renvoie le code ascii du 1er caractère d’une chaîne, instr recherche une sous-chaine dans une chaine date$ = date du jour, addmonth ajoute un nombre de mois à un jour, eomonth = le dernier jour du mois gdat$ = date à partir de jour,mois,année, string$ repète N fois une chaîne, num$ transforme un nombre en chaîne chr$(N) crée une chaîne à partir d’un code ascii left$, right$, mid$, seg$ extraient des sous-chaînes d’une chaîne en fonction de positions numériques format$ formatte une expression quelconque en chaîne de caractères space$ construit une chaîne de N espaces, vireblc supprime les espaces dans une chaîne (plusieurs options) ctrans transcode des chaînes

Fonctions Autres fonctions disponibles pour exprimer des formules agrégatives find(X,X…) sum(N…) min(X…) max(X…) avg(N…) prd(N…) uni(X…) … diverses sigma(N,N,N) evalue(C) parse(C) filpath(C,C,C,C) … Fonctions génériques définies par le programmeur func TRAITEMENT.NOM(X…) Fonctions “standard” définies dans des traitements standard Adonix X3 func AFNC.ACTIV("CODE")  valeur d’un code activité func AFNC.PARAM("PARAMETRE","SITE")  valeur paramètre (sous forme alphanumérique) func AFNC.PARAMUTIL("PARAMETRE","USER","SITE")  valeur paramètre utilisateur (idem) func AFNC.CONSULT("ACCES")  vrai si droit de consultation sur le code accès func AFNC.MODIF("ACCES")  vrai si droit de modification sur le code accès func AFNC.EXEC("ACCES")  vrai si droit d’exécution sur le code accès func AFNC.TEXTE(NUM)  donne le texte en fonction du numéro (dans la langue courante) func AFNC.TEXTRA("TABLE","CHAMP","CLE1","CLE2")  texte traduisible dans une table Note pour la compréhension des syntaxes : N = un argument numérique, C = un argument chaîne de caractères, D = un argument date X = un argument de type quelconque Quand un argument est suivi de « … », il peut y en avoir une liste finie d’autres derrière. Si l’argument est alors une variable de type tableau, on a les syntaxes suivantes : CHAMP(N..M) signifie les indices de N à M inclusivement, N et M pouvant eux-même être calculés CHAMP signifie le tableau entier Par exemple, si NBLIG est la variable associée à un tableau saisi, on pourra écrire : min([M:SOH3]QTY(0..[M:SOH3]NBLIG-1) pour avoir le minimum de la colonne quantité pour toutes les lignes de la facture Détail des fonctions find permet de rechercher la position d’une valeur dans une liste sum réalise la somme d’un ensemble de valeur, prd leur produit, min leur minimum, max leur maximum, avg leur moyenne uni vérifie l’unicité des éléments d’une liste sigma réalise la somme d’expressions par exemple : sigma(1,N,indcum*indcum) réalise la somme des carrés des nombres de 1 à N [indcum est la variable muette] on peut aussi écrire : sigma(I=1,N,sigma(J=1,I*I,J*log(J))) [la variable est indiquée, on peut imbriquer les sommes] evalue permet d’évaluer une chaîne de caractères contenant une expression calculée, parse permet d’en vérifier la syntaxe filpath permet de savoir où se trouve un fichier situé dans un répertoire associé à un dossier sur le serveur d’application les arguments minimaux sont le sous-répertoire, le nom du fichier (s’il est absolu, le répertoire est ignoré), l’extension des arguments complémentaires optionnels existent : le dossier, le code du volume, le nom du serveur. Le traitement standard AFNC donne accès à un ensemble de fonctions particulièrement utiles dans des formules de calcul (notamment pour les pièces automatiques et le Workflow). A noter qu’une fonction de ce type renvoie un argument de type constant; ainsi, PARAM et PARAMUTIL renvoient les paramètres sous forme d’une chaîne de caractères.

2.2 Paramètres de base Ce sont des paramètres génériques, potentiellement utilisés dans tous les types de fonctions : Paramètres généraux Base de paramètres influant sur le comportement de l’environnement ou de fonctions du progiciel Menus locaux Tables de choix utilisées dans les « combo-boxes » et les boutons radio Tables diverses Tables de codes génériques, associés à une liste de valeur, un intitulé traduisible, et une liste limitée de valeurs associées Compteurs Définition de règles de numérotation des documents (mouvements notamment)

2.2 Paramètres de base Paramètres généraux
Paramétrage / Paramètres généraux / Valeurs paramètres Paramètres généraux Les paramètres généraux sont des valeurs de paramétrage: Définies dans le dictionnaire des données (Développement) Organisées en chapitres Activant ou désactivant une fonctionnalité… ou conditionnant une décision de traitement dans X3… ou influant sur le fonctionnement de l’interface Définies à différents niveaux d’organisation Visibles (dans certains cas) comme des variables globales Remarques : La définition d’un paramètre général est une fonction de développement. Certains paramètres peuvent ne pas être modifiables. La plupart des paramètres définis au niveau global et au niveau utilisateur ont une variable globale associée Lorsqu’une variable globale n’existe pas, c’est le développeur qui accède à sa valeur par le biais d’un sous-programme Il est facile de vérifier les caractéristiques d’un paramètre (Développement/Dictionnaire des données/Définition des paramètres). Par contre, modifier les caractéristiques d’un paramètre ou en ajouter relève du développement. Les chapitres de paramètres sont dérivés des modules : Paramètres liés à un module : ACH = Achats, BUD = Budgets, CPT = Comptabilité, CRM = Action commerciale, GPA = GPAO, HDK = Help-desk, STO = Stocks, TRS=Tiers, VEN=Ventes Paramètres génériques : ADX = Adonix (paramètres du moteur et de l’environnement d’exécution), TC = Tronc commun (paramètres généraux liés aux tables de base), SUP = Superviseur

Niveau de définition des paramètres
2.2 Paramètres de base Paramétrage / Paramètres généraux / Valeurs paramètres Niveau de définition des paramètres Il existe au maximum 4 niveaux de définition : Chaque paramètre est caractérisé par le niveau de détail le plus fin La valeur de niveau le plus bas est toujours retenue D Dossier C Société S U S Site U Utilisateur Pour un paramètre défini au niveau de détail de l’utilisateur, la valeur retenue, si elle n’existe pas à ce niveau, est celle du site par défaut pour le module auquel est rattaché le paramètres (cf. chapitre Habilitations). Si cette valeur n’existe pas, on remonte à la société dont il dépend, puis au dossier. Il est important de bien distinguer le comportement d’un paramètre dont les valeurs saisies l’ont été au niveau des sites : Si ce paramètre est caractérisé par le niveau utilisateur, on va reprendre la valeur associée au site par défaut de l’utilisateur (pour le module correspondant), mais cette valeur reste fixe tout au long de la session. Si ce paramètre est caractérisé par le niveau site, sa valeur est variable au cours d’une session, selon le site impliqué dans la saisie du mouvement ou de la fiche pour laquelle le paramètre a un sens.

Paramètres du superviseur
2.2 Paramètres de base Paramétrage / Paramètres généraux / Valeurs paramètres Paramètres du superviseur Groupe ADX DIRPCE1 et DIRPCE2 : répertoire des pièces jointes Groupe TC (valeurs par défaut) CHGTYP : type de cours, DEFCUR : devise par défaut… Groupe SUP Environnement : TYPMES, SERMES, SERIMP, VIRTDIR Base de données : ROLLBACK, TIMLCK Sécurité : PASSWD, PASLNG, NBRCON, CHGPASS Contrôle des connexions : USR1, USR2… Quelques précisions : SERMES = serveur de messagerie TYPMES = type de messagerie (client/serveur) SERIMP = serveur d’impression par défaut VIRTDIR= Répertoire de publication Web ROLLBACK est un paramètre qui vaut 3 par défaut, et sert à gérer les contentions dans la base de données. Lorsqu’un conflit apparaît dans une transaction de mise à jour, le programme abandonne la transaction et réessaie. Ce paramètre définit le nombre maximum d’essais avant d’afficher une erreur à l’utilisateur et lui permettre de réessayer. On peut être amené à l’augmenter sur un site où de nombreuses contentions apparaissent (beaucoup de mises à jour simultanées). TIMLCK sert à fixer un temps d’attente par défaut pour des verrouillages « logiques » lorsque la ressource est verrouillée (5 secondes par défaut). Un verrouillage logique correspond à un enregistrement dans la table APLLCK (cf. utilitaires plus loin) PASSWD = mot de passe obligatoire (Oui/Non), PASLNG = longueur minimum du mot de passe, NBRCON = nombre de tentatives ratées de saisie du mot de passe avant verrouillage du compte CHGPASS = durée maximale de vie d’un mot de passe (en nombre de jours) Un ensemble d’autres paramètres existent, qui seront examinés plus loin (ils peuvent être définis au niveau de l’utilisateur)

Possibilité de reprendre la valeur « au-dessus »
2.2 Paramètres de base Paramétrage / Paramètres généraux / Valeurs paramètres Saisie des VP Choix du chapitre et du niveau de définition : global société site Possibilité de reprendre la valeur « au-dessus » Remarques : Le niveau saisi, on ne voit apparaître que les paramètres pouvant avoir une valeur à ce niveau ou en dessous Le niveau utilisateur ne peut pas être saisi ici (il l’est dans la fiche utilisateur, cf. plus loin) Une aide en ligne contextuelle expliquant ce que fait le paramètre est accessible par clic droit lorsqu’on est positionné sur une ligne sans être en saisie dessus (on dit qu’on a « le focus » sur une ligne). Le menu surgissant sur le clic droit fait alors apparaître Aide en premier choix.

Les menus locaux (messages)
2.2 Paramètres de base Paramétrage / Paramètres généraux / Menus locaux Les menus locaux (messages) Les menus locaux (messages) sont : des listes de valeurs ou de libellés traduisibles groupées par chapitre (numéro de 1 à 9999) utilisées pour les listes déroulantes, les boutons radio, les cases à cocher Physiquement, un champ de type menu local stocke le numéro du texte (0-255) plutôt que le texte lui-même. Remarques : L’écran ci-dessus, emblématique, est issu de la fiche client. On y trouve 5 menus locaux sous forme de listes déroulantes, deux sous forme de bouton radio, et 3 cases à cocher. La case à cocher correspond au menu local 1, qui ne peut prendre que deux valeurs : Non ou Oui.

Les menus locaux (messages)
2.2 Paramètres de base Paramétrage / Paramètres généraux / Menus locaux Les menus locaux (messages) Il existe des règles de modification des menus locaux : Tous ne sont pas modifiables (cela dépend du développeur) Attention aux insertions ! (les valeurs sont stockées sous forme de rang) Parfois, un nombre minimum et/ou maximum de choix est autorisé Une validation est demandée en fin de mise à jour de menus Une modification peut imposer des actions techniques (revalidation des écrans si le menu local est utilisé comme bouton radio) Remarques : Les menus locaux sont notamment utilisés pour nommer les types de familles statistiques, les axes analytiques… Dans ce cas, le nombre d’intitulés à saisir est évidemment égal au nombre de types de familles, au nombre d’axes analytiques. Dans la suite du support, on trouvera mentionné les menus locaux importants dans un contexte de paramétrage donné EN version 140, menus locaux et messages ont été regroupés dans une seule fonction Validation des menus locaux La validation (qui peut être fait après une série groupée de mises à jour sur plusieurs menus locaux) permet de provoquer un rechargement des menus locaux à la connexion au dossier. En effet, pour des raisons de performance, ces derniers sont stockés sur le poste client, en Web comme en client-serveur, et leur rafraîchissement est automatiquement piloté à partir du moment où cette validation est faite. Il est aussi possible de la réaliser directement ( Développement / Utilitaires / Dictionnaire / MAJ Menus locaux). Cette validation n’a donc rien à voir avec une revalidation des écrans, qui est une action de développement. En pratique, sur les menus locaux paramétrables, il n’y a pas lieu de revalider des écrans.

2.2 Paramètres de base Les tables diverses Les tables diverses sont :
Paramétrage / Paramètres généraux / Tables diverses Les tables diverses Les tables diverses sont : des petites tables logiques contenant des valeurs diverses comme les codes de taxe, les incoterms, les familles et sous-familles article, client, fournisseur … identifiées par un numéro (de 1 à 999) stockées dans une seule table de la base (ATABDIV) associées à un champ dans une fiche pour permettre d’en contrôler la valeur Les codes stockés dans la table ont une longueur maximale dépendant du numéro de la table (3 par défaut) Remarques : En version 130, les codes de tables diverses sont stockés sur 3 caractères maximum, et cette longueur n’est pas paramétrable par table En version 140, on définit au niveau du dossier le maximum maximorum (cf. plus loin), et, pour chaque numéro de table, la longueur maximum autorisée (jusqu’à 99). En version 130, les familles statistiques articles, client, fournisseur n’étaient pas des tables diverses L’intérêt pour le développeur de recourir à ce type de tables est d’éviter la multiplication de tables de ce type dans la base, et de disposer de fonctions de paramétrage, de modifications pré-définies. La création d’une nouvelle table diverse est un acte de développement. La saisie de valeurs dans une table diverse est normalement un acte d’exploitation ou de paramétrage, sauf si le développeur a interdit la saisie de nouvelle valeurs ou la modification des valeurs dans une table livrée pré-paramétrée. Certaines caractéristiques d’une table diverse peuvent être modifiées par paramétrage (là encore, cela dépend de la table).

2.2 Paramètres de base Les tables diverses
Paramétrage / Paramètres généraux / Tables diverses Les tables diverses Chaque enregistrement d’une table diverse est caractérisé par : un code alphanumérique (caractères majuscules) sur N positions maximum le code d’une autre table dont l’enregistrement peut dépendre deux intitulés (long, court) stockés en fonction de la langue (intitulés « traduisibles ») Jusqu’à 2 champs alphabétiques (ou date) et jusqu’à 2 champs numériques complémentaires, dont le format dépend de la table Remarques : L’intérêt du code « de dépendance » réside dans le cas où une table diverse stocke les valeurs d’une sous-famille (on peut rattacher chaque sous-famille à la famille à laquelle elle appartient). Dans la suite du support, on trouvera mentionné les tables diverses importantes dans un contexte de paramétrage donné

2.2 Paramètres de base Les tables diverses
Paramétrage / Paramètres généraux / Tables diverses Les tables diverses Remarques Les dépendances peuvent se faire en cascade (on rattache un code à un code dépendant de niveau supérieur) Les champs complémentaires éventuellement définis arrivent après la colonne Dépendance si elle existe Un utilisateur donné n’a pas forcément accès en modification à toutes les tables diverses (protection par codes d’accès, cf. plus loin).

Personnalisation des tables diverses
2.2 Paramètres de base Paramétrage / Paramètres généraux / Perso tables diverses Personnalisation des tables diverses Cette fonction permet de les règles de dépendance Familles / Sous-familles, les intitulés de la table et la longueur des codes s’ils sont modifiables ! Le fait que la longueur soit modifiable est « spécifique » Il faut protéger par un code activité « spécifique » pour pérenniser Remarques : La longueur maximale des codes n’est pas forcément modifiable (cela dépend du programmeur) Certaines tables (les familles statistiques notamment) ont des intitulés donnés par un menu local : Numéro 206 pour les clients Numéro 207 pour les fournisseurs Numéro 208 pour les articles Numéro 3005 pour les familles statistiques des contrats La modification des titres des familles se fait donc en modifiant le menu local, ce qui explique que l’intitulé ne soit pas modifiable dans la fonction de personnalisation. Par contre, est considéré comme paramétrage (pérenne) la longueur du code, la présence de champs supplémentaires, la table de dépendance.

2.2 Paramètres de base Les compteurs Les compteurs sont :
Paramétrage / Paramètres généraux / Compteurs Les compteurs Les compteurs sont : des codes associés aux documents du progiciel (factures, commandes, écritures…) ou à des fiches que l’on souhaite numéroter qui définissent des règles d’attribution d’identifiants (un numéro de facture par exemple) Caractéristiques des identifiants délivrés par un compteur : Ils ne sont pas forcément entièrement numériques Ils sont structurés de façon particulière (en intégrant des segments particuliers dépendant du contexte : l’année, le site…) Ils intègrent obligatoirement un numéro séquentiel qui peut revenir à zéro de façon périodique, et peut dépendre de la société, du site, ou d’une autre information (complément) Remarques :

2.2 Paramètres de base Les compteurs
Paramétrage / Paramètres généraux / Compteurs Les compteurs Fréquence de Remise-A-Zéro : La séquence peut repartir à 1 de façon périodique. Attention : il faut que l’élément identifiant la période soit présent dans un autre segment, sinon on va créer des doublons dans les identifiants. Un compteur peut être global, défini au niveau du site ou de la société. (nombre de séquences gérées) Le tableau des composants La longueur totale est la somme des longueurs de composants, elle est limitée à 15 ou 20 caractères) Remarques : Les documents classiques (écritures, commandes, OF, factures…) sont limités à 15 caractères. Mais certains numéros attribués automatiquement (par exemple, les codes articles, une numérotation automatique pouvant être activée par catégorie) peuvent aller jusqu’à 20 caractères. Composants possibles : Jour, Mois, Semaine, Année (segments numériques, liés à la date logique du document qui n’est pas forcément la date du jour). Exercice, Période (liés à la société et à la date logique du document, qui permet d’avoir un exercice et une période) Société, Site (le code de la société ou du site). Il est alors vivement conseillé de codifier ses codes sociétés et sites sur un nombre de caractères constant pour éviter des numéros de longueur différents. Constante : c’est une série de caractères quelconques, par exemple des séparateurs… Numéro de séquence : obligatoire dans un compteur Complément : correspond à un code dépendant du contexte de numérotation. Une séquence différente alors existe pour chaque valeur de complément. Les compléments utilisés à ce jour sont définis dans la page suivante. Champ Type : Si le type est numérique, on numérote sans mettre des zéros: on passera de 9 à 10. Si le type est alphanumérique, on numérote sur une longueur fixe : on passera de à Type de séquence et champs associés Il s’agit de champs techniques, permettant d’éviter, lorsqu’on a de nombreux utilisateurs créant des mouvements simultanément, des problèmes de verrouillage. Trois cas sont possibles : Normal : il s’agissait de l’option que l’on avait en version 130. Une seule transaction à la fois peut créer un numéro en utilisant une séquence du compteur (les autres sont verrouillées et doivent recommencer, ce qui n’est pas forcément dramatique, car une transaction dure le plus souvent quelques dixièmes de secondes). On ne perd jamais de numéro avec ce principe, et les numéros sont attribués séquentiellement. Séquence BDD : du point de vue des performances, c’est la plus efficace, car il n’y a aucun verrouillage. Les numéros attribués sont consécutifs, mais on en perd en route (si la transaction est abandonnée en cours de route, le numéro est définitivement perdu). Pour gérer ce type de séquence, on doit l’associer à une table (la table qui contient les enregistrements que l’on numérote ainsi, pour éviter des problèmes en cas de transfert de table). Attention, pas de Raz du numéro de séquence possible dans ce cas. Groupé : on attribue les numéros par tranche de N (défini par le champ Nombre de numéros). Ainsi, N utilisateurs peuvent simultanément obtenir un numéro sans problème de verrouillage. En cas d’abandon de transaction, on récupère le numéro pour ne pas le perdre. Mais ceci a pour conséquence qu’en fin de numérotation (en fin de mois si on a une numérotation par mois), on peut avoir des numéros inutilisés dans la dernière tranche de N (on sait les justifier). Par ailleurs, les numéros ne sont pas attribués de façon strictement séquentielle (on récupère d’abord les trous). Case à cocher permettant de vérifier qu’un document daté après un autre a toujours un numéro de séquence supérieur Compteur remis à zéro en cas de remise à zéro du dossier ?

2.2 Paramètres de base Les compteurs Compléments et formules
Paramétrage / Paramètres généraux / Compteurs Les compteurs Compléments et formules Les compléments définissent segments dépendant du contexte ayant chacun leur numérotation propre : Les formules permettent d’évaluer une constante sans que la numérotation en dépende Contexte de numérotation Valeur du complément Ecriture comptable Journal Lot article Code article Règlement Code transaction de règlement Lot de saisie de règlement Code utilisateur Quittance factor Code factor Fiches tarif Code tarif Remarques : Le code complément dépend du contexte de numérotation, et est donné par le développeur. Voici les contextes de numérotation où il existe un code complément en standard (le code complément utilisé étant indiqué entre parenthèses): Numéro de lot article (Code article) Fiches tarifs (Code tarif correspondant) Ecriture comptable (Code du journal sur lequel l‘écriture est passée) Règlement (Code de la transaction de règlement utilisée) Bordereau de remise (Code de la transaction de règlement utilisée) Avis de domiciliation (Code de la transaction de règlement utilisée) Lot de saisie de règlement (Code de l'utilisateur de création) Quittance factor (Code du factor) Tableaux de bord (Code du tableau de bord) Le complément est très utilisé, par exemple en comptabilité, pour avoir des numérotations par journal. Si on a deux journaux, nommés VEN, et ACH, et qu’on a un compteur de type Complément + Numéro sur 4 chiffres, on aura les numérotations suivantes : VEN0001, VEN0002, ACH0001, VEN0003, ACH0002… Il est à noter que l’expression [L]COMPLEMENT peut être utilisée dans un segment de type Formule pour intégrer le code du complément dans la numérotation sans pour autant avoir une séquence par valeur de complément. Mais toute autre formule significative dans le contexte peut être utilisée avec des segments de ce type. Ainsi, dans le cas précédent, si on avait choisi un segment de type Formule, et que l’on ait mis [L]COMPLEMENT dans la formule, on aurait eu, dans le même contexte que précédemment, la numérotation suivante : VEN0001, VEN0002, ACH0003, VEN0004, ACH0005…

Affectation des compteurs
2.2 Paramètres de base Paramétrage / Paramètres généraux / Affectation des compteurs Affectation des compteurs Elle se fait par module et par type de document dans la majorité des cas Dans certains cas, un numéro manuel est possible Certaines affectations sont plus complexes Remarques : Le fait qu’un numéro manuel existe ne signifie pas pour autant que le compteur n’est pas affecté. Le compteur ne sera alors utilisé que si on n’a pas saisi un numéro manuellement. On peut partager un même code compteur entre plusieurs documents (par exemple, numéroter de la même façon les factures et les avoirs pour n’avoir qu’une seule séquence commune). Il suffit d’associer le même code aux documents concernés. Champ initialisables par un compteur dont l’affectation n’est pas faite par cette fonction : Un ensemble de champs sont numérotés par des compteurs définis dans d’autres fiches. Ci-dessous quelques exemples : Codes articles : catégorie d’article Numéros de lot : fiche article Quittances factor : fiche factor Pièces comptables : Type de pièce Fiches immos : catégorie d’immobilisation Factures de vente et d’achat : types de facture …

Valeurs initiales des compteurs
2.2 Paramètres de base Développement / Utilitaires / Divers / Valeurs des compteurs Valeurs initiales des compteurs ! C’est une fonction de maintenance située dans le développement ! Elle permet de modifier le prochain numéro de séquence utilisé Elle est utile en cas de reprise (après import d’un système antérieur, pour numéroter les pièces suivantes en séquence) Remarques : Après avoir saisi le code du compteur, il faut saisir les éléments qui définissent la séquence exacte (élément temporels – mois, année, exercice, période le cas échéant – et éléments autres – société, site et numéro de complément). Si on se trompe et on affecte un numéro déjà existant, toute tentative de création d’un nouveau document numéroté à l’aide du compteur se soldera par une erreur. Il convient donc de faire très attention. Par défaut, si une valeur de compteur n’a pas été reprise, on commence toujours à 1

2.3 Workflow Principes de base Evénements déclenchants
Paramétrage / Workflow / Règles workflow Principes de base Evénements déclenchants Ce qui peut être déclenché Retour de Workflow Création détaillée d’une règle de Workflow

Principes de base du workflow
Paramétrage / Workflow / Règles workflow Principes de base du workflow Le moteur de Workflow d’ADONIX X3 permet : à partir d’événements déclenchants divers : Entrée dans une fonction Action réalisée dans une fonction “objet” Fin de tâche batch Edition Evénements divers de déclencher un ou plusieurs actions : Exécution d’un traitement par le biais d’une action Envoi de messages (mails) Enregistrements d’événements dans une table de log Lorsqu’un mail est envoyé, il est possible de définir l’appel d’une action en retour (par double-clic sur une icône jointe dans le mail) Remarques : Du point de vue terminologique, le Workflow inclus dans ADONIX X3 ne couvre qu’une partie du cycle, puisqu’il n’assure pas un suivi des actions. Le fait, par exemple, de saisir une demande d’achat permet d’envoyer un mail à la personne qui devra le signer. Le fait que cette commande aura été signée permet de renvoyer un mail au demandeur. Mais aucun mécanisme automatique n’assurera que la personne aura signé dans un délai donné…

Fonctionnement du moteur de Workflow
Paramétrage / Workflow / Règles workflow Fonctionnement du moteur de Workflow Conditions supplémentaires Actions déclenchantes (opérations, boutons) Code événement Contexte déclenchant Type d’événement Valeurs de retour (si nécessaire) Action et paramètres de l’action Condition de déclenchement Exécution d’une action (traitement) Traitement X3 Utilisateur et contextes courants 1 Définition de l’icône de retour Liste des destinataires Options d’envoi Texte du ou des messages Définition des pièces jointes Envoi d’un message ( ) Remarques : Les 3 déclenchements sont susceptibles d’utiliser tout le contexte déclenchant courant L’exécution de l’action (traitement) se fait d’abord, si la condition supplémentaire est réalisée. Les valeurs de retour renvoyées enrichissent le contexte des deux déclenchements suivants. Le mail est envoyé ensuite (si la case correspondante est cochée) Le log est mis à jour enfin (si la case correspondante est cochée). A ce stade, on sait si un mail a été envoyé (case à cocher visible dans la visualisation de la table de log). 2 Contexte X3 Table de log 3 Définition des informations à stocker (nature, information) Stockage d’informations de « log »

Evénements déclenchants possibles
2.3 Workflow Paramétrage / Workflow / Règles workflow Evénements déclenchants possibles Evénements génériques : Gestion d’objet Entrée dans une fonction Fin ou arrêt de tâche batch Lancement d’une édition Evénements divers (connexion, déconnexion, time-out, arrêt processus) Le contexte peut être précisé : En donnant le code “en dur” (objet, fonction, tâche batch, état) En spécifiant des conditions complémentaires (expressions calculées) En gestion objet, le contexte peut être plus riche : Opération en cours (Création, Modification, Suppression, Changement de code, Impression, Bouton Workflow) Exécution d’un bouton associée à la fenêtre (si l’objet est donné en dur) Remarques : Toutes les fonctions adonix et des variables issues du contexte sont utilisables aussi bien dans les conditions que dans les textes liés aux messages envoyés.

Déclenchement d’un traitement X3
2.3 Workflow Paramétrage / Workflow / Règles workflow Déclenchement d’un traitement X3 Caractéristiques du traitement : Normalisé comme une action défini dans le dictionnaire des actions avec la case Workflow cochée Sans aucune interaction avec l’écran puisqu’il peut être déclenché en batch mais avec la possibilité de disposer de variables en retour Actions disponibles à ce jour : gestion des liaisons (explorateur de liaison) actions spécifiques à créer Remarques : A ce jour, la bibliothèque standard des actions déclenchables par Workflow est très limitée, mais à terme elle devrait s’étendre. Parmi les actions existantes utilisables en Workflow, on notera : ACRELNK qui permet de créer une liaison (dans l’explorateur de liaisons) ASUPLNK qui permet de supprimer une liaison Des variables banalisées GBIDI1 à GBIDI3 (entières), GBIDC1 à GBIDC3 (alphanumériques), GBIDD1 à GBIDD3 (décimales), GBIDA1 à GBIDA3 (dates) sont utilisables comme variables de retour de l’action appelée, afin de les utiliser si nécessaire dans le mail ou pour l’alimentation du fichier log.

Principes de base du mail via Workflow
Interface MAPI Serveur de messagerie Client Windows Serveur Web Client Web Serveur X3 Interface SMTP POP3 Le workflow permet un envoi de message selon deux modes : Piloté par le poste client Windows, sur lequel on doit trouver un client de messagerie en interface MAPI ouvert (sinon, le message ne pourra pas partir). Sous Windows, avec Outlook, si la messagerie n’est pas ouverte, une boîte de dialogue apparaît pour l’ouvrir. La plupart des messageries du marché sont susceptibles de fonctionner par MAPI notamment Outlook, Eudora, Lotus Notes… Piloté par le serveur, qui peut alors envoyer des mails par SMTP POP3. Là encore, un grand nombre de messageries (Exchange, Lotus, cc-mail…) permettent cet envoi. Dans tous les cas, on suppose qu’il y a quelque part un serveur de messagerie qui va s’occuper de l’envoi des mails. Un paramètre du superviseur nommé TYPMES permet de définir quelle est le mode d’envoi par défaut, mais : Lorsque le Workflow résulte d’un événement survenu pendant une exécution batch, l’interface serveur est forcément utilisée. Lorsque le Workflow est déclenché depuis un client Web, l’interface serveur est aussi forcément utilisée. On peut imposer, lors du paramétrage d’un événement Workflow, l’un ou l’autre des types d’envoi Un paramètre du superviseur nommé SERMES permet de donner le nom ou l’adresse réseau du serveur de messagerie. Il est à noter que l’envoi du message via le serveur est déclenché,sur une architecture multi-serveurs, sur le serveur d’application.

Envoi d’un mail par le Workflow
Paramétrage / Workflow / Règles workflow Envoi d’un mail par le Workflow Les caractéristiques paramétrables du mail sont : Destinataires soit connus comme des utilisateurs (adresse sur la fiche) soit définis comme des tiers avec le type d’interlocuteur si se trouve dans l’adresse, on envoie tel quel Destinataires principaux et/ou en copie Texte défini sous la forme de lignes avec des expressions Pièces jointes chemin fixe sur le serveur d’application défini par une expression pièces jointes à un objet (avec des filtres type/catégorie) fichier trace lié (si tâche batch) Informations complémentaires : Présence d’une icône de retour (retour au menu ou fin directe) Accusé de réception Remarques : Quelques limites sont à connaître : La case Accusé de réception ne peut fonctionner que sur un envoi depuis le serveur Un message MAPI est limité par l’interface à environ 700 caractères (pièces jointes exclues), alors que l’envoi SMTP / POP3 limite sa taille à environ caractères (pièces jointes toujours exclues) Les pièces jointes à l’objet doivent impérativement se trouver sur le serveur d’application, et ce type d’envoi n’est possible qu’ne envoi depuis le serveur Il faut au minimum un destinataire principal à un mail

Mise à jour d’une table de log
2.3 Workflow Paramétrage / Workflow / Règles workflow Mise à jour d’une table de log Eléments stockés dans la table de log (AWRKLOG) : Date, heure, utilisateur. 5 éléments (couples) du type Nature / Information (table diverse 50). Évènement, type d'opération, code objet, clé… Flag Message pour indiquer si un a été envoyé ou non. Visualisation par le Workflow monitor ( Exploitation / Moniteur Workflow ) Remarques : Sur cet écran, on ne voit qu’un couple (nature, information) mais en réalité il y en a 5. L’en-tête permet des sélections notamment sur la nature.

2.3 Workflow Paramétrage détaillé
Paramétrage / Workflow / Règles workflow Onglet Général Paramétrage détaillé Opérations déclenchantes et / ou Boutons déclenchants (dans un contexte Objet ) Code catégorie, rattaché à la table diverse 51 (informatif) Type d’événement: Entrée fonction Objet Edition Etat Fin tâche batch Arrêt tâche batch Divers Code événement (s’il est vide, il s’agit d’un événement générique) Remarques : L’indicateur Message modifiable n’est utile qu’en interactif : il permet de modifier le message avant envoi L’indicateur Mise au point ne sert quen cas de problème de mise au point… La variable de bas de tableau a un fonctionnement un peu complexe : elle doit correspondre à une variable de type ABS, définie dans un écran, qui permet de connaître le nombre de lignes saisies. Si par exemple elle s’appelle NBLIG, et qu’elle est déclarée dans le tableau : Toute expression (dans les textes du message ou dans les destinataires) utilisant ((NBLIG)) [Deux parenthèses obligatoires] sera répétée en boucle surles indices variant de 0 au nombre de lignes moins 1. Si des destinataires dépendent de ((NBLIG)), le message sera envoyé aux destinataires ainsi obtenus par la boucle. Si certaines lignes du message elles-même dépendent de ((NBLIG)), elles provoqueront la génération de plusieurs lignes. Si les deux en dépendent, seules les lignes dépendant de la même valeur d’indice seront envoyées aux destinataires appariés. Conditions liées au contexte Evénements déclenchés et Options

Paramétrage détaillé : assistant de formule
2.3 Workflow Paramétrage détaillé : assistant de formule Paramétrage / Workflow / Règles workflow On dispose d’un contexte en ligne si l’événement est spécifié : En contexte objet Table (valeurs avant modification) Ecrans (valeurs après modification) En contexte état : les paramètres de lancement En contexte tâche batch : l’écran saisie des paramètres Dans tous les cas : la table des utilisateurs AUTILIS Remarques : Il existe également des variables globales en ligne. On a notamment : des variables banalisées GBIDI1 à GBIDI3 (entières), GBIDC1 à GBIDC3 (alphanumériques), GBIDD1 à GBIDD3 (décimales), GBIDA1 à GBIDA3 (dates) utilisables comme variables de retour de l’action appelée GUSER (code utilisateur), GNOMUSER (nom utilisateur) GERRBATCH (nombre d’erreurs en fin de tâche batch) …

Paramétrage / Workflow / Règles workflow Onglet Actions Paramétrage détaillé Informations sur le retour par mail : Possible Icône de retour cochée Retour au menu ou fin après exécution Fonction de retour (fonction appelante par défaut) et clé de lien (si la fonction est de type objet) Remarques : Code action à déclencher (Pas d’action à lancer si vide) C’est ici une action spécifique Tableau des paramètres : Ici, on a deux paramètres en entrée deux paramètres en sortie

Paramétrage / Workflow / Règles workflow Onglet Message Paramétrage détaillé Tableau des destinataires, sous la forme d’une adresse « en dur » d’un couple (code tiers, fonction) d’un code interne utilisateur Au moins un des destinataires doit avoir Non dans la colonne Remarques : Texte évalué du message

Paramétrage / Workflow / Règles workflow Onglets Pièces jointes et Traçabilité Paramétrage détaillé Pièce jointe (chemin d’accès évalué) Indicateur Fichier trace lié (pour tâches batch) Définition des pièces jointes à envoyer (dans un contexte objet uniquement) Remarques : Tableau des informations du moniteur Workflow : Nature = Table diverse numéro 50

2.4 Paramétrage des fonctions
Les modèles de fonctions induisent des paramétrages particuliers : Modèle Objet Propriétés Personnalisation Liaisons automatiques Navigation Transactions Modèle consultation Paramétrage des écrans Tout modèle utilisant des écrans Tables de contrôle Affectation de codes d’accès (pour rappel)

Paramétrage des objets : Propriétés
2.4 Paramétrage des fonctions Paramétrage / Paramètres généraux / Propriétés objets sous menu Fichier Paramétrage des objets : Propriétés En gestion d’objet, Fichier / Propriétés permet d’accéder : A des informations liées à la valeur courante de la fiche Par défaut, on trouve les informations suivantes (si elles existent) : Ces informations calculées étant paramétrables, en intégrant : des fonctions des constantes des champs de la table principale Des champs de tables liées déclarées dans un tableau Remarques : Les valeurs par défaut se basent sur les champs déclarés : Dans le champ Intitulé de l’objet (Intitulé court par défaut) Dans les champs CREDAT, CREUSR, CRETIM et UPDDAT, UPDUSR,UPDTIM lorsqu’ils existent Les liens peuvent être établis en cascade à partir de la table principale de l’objet. Un lien s’exprime sous la forme d’une expression si la clé d’accès est simple. Si elle est multiple, on sépare les différentes expressions de la clé par un point-virgule. Par exemple, pour établir un lien vers la table des sections sur l’axe 2 (supposé constant) et sur une section définie par la variable SEC(1), on écrirait un lien sous la forme suivante : 2 ; SEC(1) Il vaut mieux commencer par saisir les liens (car les tables liées apparaissent ensuite dans l’assistant de formule lorsqu’on paramètre les propriétés elles-même). Cette information est aussi disponible par F11 sur toute zone de clé liée à un objet

Paramétrage des objets : Personnalisation
2.4 Paramétrage des fonctions Paramétrage des objets : Personnalisation Paramétrage / Paramètres généraux / Personnalisation objet Il est possible de paramétrer un ensemble de caractéristiques de l’objet : Les caractéristiques de la liste gauche : Index de tri (le premier de la table par défaut) Sens (ascendant ou descendant) Gestion en liste hiérarchisée (si plusieurs composantes dans la clé) Affichage de la liste des derniers lus Les colonnes présentes dans la liste gauche Table (principale ou liée) Champ ou expression (type et variable associée) Intitulé de la colonne Remarques : Ce paramétrage (c’en est un, puisqu’il n’a pas besoin d’être pérennisé par un code activité) est à réaliser avec précaution, car s’il est mal réalisé, l’objet paramétré risque de ne plus fonctionner (erreur au chargement de la liste gauche par exemple). En effet, la validation de cet écran entraîne une génération automatique de code. En particulier, l’ensemble des composantes de la clé doivent être présents dans la liste gauche, sinon elle ne fonctionne pas Un maximum de 15 colonnes peut être paramétré. Les expressions servent dans des cas tels que la contaténation de deux champs. Par exemple : on veut faire apparaître le pays plus le code postal dans la première colonne On écrit alors : sum(CRY, " " ,POSCOD) (il faut utiliser l’opérateur sum et non pas le ‘+’ dans ce contexte) On ajoute une variable « muette » pour gérer cette valeur(par exemple ZCP) Accès direct par zoom aux statistiques ( Appel par Fichier / Statistiques) Etats appelés par : Fichier / Impression Fichier / Liste

Paramétrage des objets : Personnalisation
2.4 Paramétrage des fonctions Paramétrage des objets : Personnalisation Paramétrage / Paramètres généraux / Personnalisation objet Sur le second onglet, on paramètre les autres listes de gauche standard Présence de l’explorateur de liaisons Intitulé des liens vers l’objet paramétré Remarques : Les liaisons automatiques sont toujours réciproques, c’est-à-dire qu’elles créent des liens pointant d’un autre objet vers l’objet cible. Si le code sémantique de liaison (table diverse numéro 61) admet une sémantique inverse, le lien est créé de façon réciproque également. Les expressions de lien ne peuvent pas faire intervenir autre chose que des champs de la table principale gérée par l’objet (la récupération des liens ne saurait pas prendre en compte ce type de liens). Lorsque la clé de lien est multiple (ce qui suppose que la clé principale de l’objet en cours de paramétrage possède plusieurs composantes), on sépare les expressions des composantes par un point-virgule. Il est à remarquer que l’on peut créer des liens automatiques grâce à une action appelable en Workflow, ce qui permet d’aller au delà (sans possibilité de récupération automatique dans ce cas). Le lien est créé dans le groupe automatique de liaison (paramètre superviseur LIAISAUTO). Si ce paramètre est vide, les liaisons automatiques ne sont pas créées pour l’utilisateur. La colonne Tableau doit définir une variable de bas de tableau (ie. contenant le nombre de lignes d’un tableau stocké en tant que tel dans la table). Il sert à faire varier la variable indice (de 0 à N-1, si N est la valeur de la variable de bas de tableau). Ceci sert uniquement pour créer des liens à partir de clés stockées dans des « petits tableaux » (puisqu’ils doivent être dans la classe [F], et pas dans les écrans). Paramétrage des liaisons automatiques : Objet à partir duquel le lien part Expression permettant de connaître sa clé Code liaison Tableau si liens multiples (l’expression de lien dépend alors de indice) Présence de l’onglet Derniers lus

Gestion des objets : Navigation
2.4 Paramétrage des fonctions Gestion des objets : Navigation Développement / Dictionnaire traitements / Navigation ! C’est une fonction située dans le développement Des navigations standard sont fournies (essentiellement pour la CRM) Toute modification et toute création de nouvelle navigation doit être signée par un code activité spécifique (commençant par X, Y, ou Z) Elle suppose une bonne connaissance du contexte d’exécution Elle peut produire des dysfonctionnements dans l’objet modifié si la définition est mal faite Néanmoins : Elle a la facilité de mise en oeuvre d’un paramétrage Remarques : Cette fonction est nouvelle en version 140

Navigation : principes de base
2.4 Paramétrage des fonctions Navigation : principes de base Développement / Dictionnaire traitements / Navigation Une fonction X3 dispose de possibilités de navigation vers d’autres fonctions Via des menus dans la barre d’outils Quand la fonction arrivante est un objet, on peut vouloir tenir compte du contexte appelant pour : Via l’explorateur de liaisons Proposer des valeurs par défaut en création Imposer des filtres de sélection Par tunnel Remarques : Ces navigations sont toujours des navigations avec un retour à la fonction appelante Via des boutons

Navigation : définition détaillée
2.4 Paramétrage des fonctions Navigation : définition détaillée Paramétrage / Paramètres généraux / Personnalisation objet Sur le premier onglet, on paramètre les filtres sur l’objet Code identifiant la navigation Contexte : Fonction de départ Objet d’arrivée Remarques : Filtres sur la liste gauche : Condition d’activation Filtre

Navigation : définition détaillée
2.4 Paramétrage des fonctions Navigation : définition détaillée Paramétrage / Paramètres généraux / Personnalisation objet Sur le second onglet, on paramètre les valeurs par défaut Champs des écrans Remarques : Ces valeurs par défaut s’appliquent en création de fiche, et pas en duplication Formules des valeurs par défaut

Gestion des objets : Navigation
2.4 Paramétrage des fonctions Gestion des objets : Navigation Développement / Dictionnaire traitements / Navigation Un cas particulier important si le code fonction de départ correspond à l’objet d’arrivée : c’est-à-dire GESXXX  XXX par convention, on est dans le cas où on part d’un menu Il est donc possible par ce biais, sur des objets appelés directement de créer des filtres complémentaires génériques ou contextuels de proposer des valeurs par défaut contextuelles Interface utilisateur : Un code de navigation actif est indiqué par l’icône en bas de l’écran Un double clic sur l’icône affiche le code de navigation actif Remarques :

Gestion des objets : Transactions
2.4 Paramétrage des fonctions Gestion des objets : Transactions Paramétrage /??? / Transactions Sur le plan technique, un objet se compose : de listes de gauche d’un ensemble d’onglets (appelé fenêtre) En temps normal, un objet est associé à une seule fenêtre règle de nommage : fonction GESXXX, objet XXX, fenêtre OXXX l’entrée dans l’objet provoque l’ouverture de la fenêtre Il est possible de créer plusieurs fenêtres pour un seul objet : chaque fenêtre correspond à une “variante” de l’objet chaque variante peut être protégée par un code d’accès à l’appel de la fonction, un choix de transaction est demandé parmi les transactions autorisées il est aussi possible d’imposer la transaction (paramètre dans le profil menu). Remarques :

Gestion des objets : Transactions
2.4 Paramétrage des fonctions Gestion des objets : Transactions Paramétrage / ??? / Transactions Créer de nouvelles fenêtres est un acte de programmation, mais : dans la plupart des modules, des fonctions de création automatique de fenêtres associées à un objet existent elles partent d’une fenêtre “de base” intégrant tous les champs possibles elles permettent par paramétrage de choisir les champs que l’on ne veut pas voir, ceux que l’on veut pouvoir modifier, et ceux que l’on ne veut que visualiser dans certains cas, elles permettent de définir des valeurs par défaut, des filtrages, ou des contrôles complémentaires Ces fonctions, dépendant de chaque module, sont les paramétrages de transaction. Remarques : On trouve des paramétrages de transaction dans tous les modules : Comptabilité et tiers : saisie de pièces, de budgets, de règlement… Négoce : Commandes, Bons de réception/Livraison, Factures, Avoirs… Stocks : Mouvements de stock, Inventaires… Production : OF, suivis, plans de suivi… CRM : Demandes de service, Interventions.

Paramétrage des consultations : Ecrans
2.4 Paramétrage des fonctions Paramétrage / Paramètres généraux / Ecrans de consultation Paramétrage des consultations : Ecrans Les consultations sont caractérisées par un code sur 3 caractères : Règle de nommage : fonction CONSXXX, consultation XXX Un écran “par défaut” est fourni : nommé STD incluant tous les champs Le paramétrage général crée des écrans : Protégés par code d’accès Avec une pagination paramétrable En donnant un rang à chaque champ Rang 0  champ non affiché à l’appel de la fonction, un choix est demandé parmi les écrans autorisés il est aussi possible d’imposer l’écran (paramètre dans le profil menu). Remarques : La pagination donnée correspond au nombre de lignes rapatriées d’un coup. Chaque consultation intègre des boutons magnétoscope pour voir le prochain groupe de N lignes. Contrairement aux paramétrages de transaction, qui ne s’appliquent qu’à des objets définis, le paramétrage des consultations s’applique, via une seule fonction, à toutes les consultations. Pour savoir, quand on se trouve dans une consultation, quel code correspond à la consultation, deux façons pratiques : Soit demander, en calculette, le contenue de la variable GFONCTION : on obtiendra CONSXXX, où XXX est le code recherché. Soit demander, par F6 , le nom de l’écran d’en-tête : il s’appelle CONSXXX1, où XXX est le code recherché.

Paramétrage générique lié aux écrans
2.4 Paramétrage des fonctions Paramétrage générique lié aux écrans Paramétrage / Paramétrages généraux / Tables de contrôle Toute fonction utilisant des écrans peut utiliser des tables de contrôle Une table de contrôle définit des contrôles supplémentaires sous la forme : de liste de valeurs obligatoires de liste de valeurs interdites de bornes de valeurs numériques d’existence dans une table d’une expression logique Trois contrôles successifs peuvent être saisis, avec des messages d’erreur dédiés Remarques : Lorsqu’un contrôle est fait par expression, on utilise la variable VALEUR pour exprimer la valeur du champ à contrôler. Un contrôle peut utiliser le contexte d’un contrôle antérieur. Par exemple, si le premier contrôle est une référence à une table, le deuxième contrôle peut être un contrôle par expression où les champs courants de la table précédente sont utilisés.

Affectation des contrôles aux écrans
2.4 Paramétrage des fonctions Affectation des contrôles aux écrans Paramétrage / Paramétrages généraux / Affectation contrôle La fonction d’affectation permet de saisir l’écran concerné, et d’affecter une table aux champs concernés. Les écrans sont automatiquement revalidés. Remarques :

Paramétrage générique lié aux écrans
2.4 Paramétrage des fonctions Paramétrage générique lié aux écrans Paramétrage / Paramétrages généraux / Affectation codes d’accès Rappel : toute fonction utilisant des écrans peut utiliser des codes d’accès pour définir des restrictions d’accès Remarques : Dans ce cas, seuls les droit de lecture (visualisation de la valeur du champ) et d’écriture (modification) associés à l’utilisateur sur le code d’accès sont considérés. Attention, l’absence de droit de saisie d’un champ peut créer la création d’une fiche si c’est un champ obligatoire sans valeur par défaut qui est ainsi protégé. Les styles conditionnels (cf. chapitre plus loin) permettront également de paramétrer les écrans de façon générique.

3. Exploitation 1- Généralités 2- Paramétrages de base 3- Exploitation

3.1 Import / Export Définition générale Modèles Tables de transcodage
Paramètres généraux Imports et exports chronologiques Enchaînements

3.1 Import / Export Imports et exports
Exploitation / Import/export / Import Exploitation / Import/export / Export La fonction d'import/export permet de transférer des données de la BDD vers des fichiers textes et vice-versa, en se basant sur les objets X3 et sur un dictionnaire : Un dictionnaire de modèles d'import/export définit le format des fichiers texte et les liens vers les objets X3 à exporter ou à importer. Le processus d'import est basé sur la gestion d'objet X3, c'est à dire qu'il simule une saisie manuelle des données. En conséquence, les contrôles qui sont effectués lors de la saisie manuelle le sont également lors d'un import. Un certain nombre d'objets ne peut pas être importé en utilisant la gestion d'objet. Dans ce cas un traitement d'import spécifique est utilisé et écrit les données directement dans les tables X3, sans passer par une simulation de saisie. Remarques :

Définition d’un modèle d’import/export
Paramétrage / Exploitation / Modèles d’import/export Types de fichiers et structure des données : ASCII 1 CHAMP1 sep CHAMP2 sep … CHAMPN sep/ Enr. suivant ASCII 2 CHAMP1 sep1 CHAMP2 sep1 … sep1 CHAMPN sep2/ Enr. suivant Délimité CHAMP1 sep1 delCHAMP2del sep1 … CHAMPN sep2/ Enr. suivant Fixe CHAMP1lllllllllllCHAMP2lllllll … CHAMPNlllllllllll/ Enr. suivant Remarques : Sous UNIX, on utilise en général une fin de ligne de type LF (line feed) codée \010. Sous Windows, la fin de ligne est de type CR LF (carriage return, line feed) codée \013\010. Le format de fichier peut prendre les valeurs suivantes : Ascii : caractères latins (suivant la norme ISO 8859 par exemple), chaque caractère étant codé sur un octet. UCS2 : norme Microsoft (c’est le stockage utilisé par Windows et SQL server) : chaque caractère est stocké sur 2 octets. UTF8 : norme internationale, stockage sur 1 octet pour les caractères ascii classiques (code <=127). Dès que l’octet est >=128, il y a un autre octet suite derrière. Ainsi, les accents français sont stockés sur deux octets, mais certains caractères peuvent être stockés sur trois ou quatre octets. Ces deux dernières normes permettent de gérer notamment les jeux de caractères de plus de 256 positions (caractères chinois, coréens…) ou encore la cohabitation de plusieurs jeux de caractères simultanément (arabe+latin, par exemple, cyrillique+latin+grec…) A noter que les sources de traitements ADONIX sont stockés en UTF8 en version 140. Ainsi, les accents sont remplacés par 2 caractères lorsqu’on passe par un éditeur incapable de lire de l’UTF8. Identificateurs : Plusieurs niveaux en-tête/détails peuvent être définis : Niveau définit la hiérarchie entre les différentes tables. Code est l'identifiant du niveau dans le fichier texte. La Clé est celle utilisée pour lire la table (cf. dictionnaire). Lien : les champs de la table dont les valeurs seront utilisées pour la lecture de la table du niveau supérieur (dépendent de la clé de la table supérieure).

Définition d’un modèle d’import/export
Paramétrage / Exploitation / Modèles d’import/export L'onglet Champs contient la définition de l'ordre des champs exportés ou importés dans le fichier texte. Lorsque des identificateurs existent, ils doivent être placés en tant que premier champ pour chaque table. Un identifiant est indiqué par le caractère '/'. Critère permet la saisie de critères de début/fin lors de l'export Le champ peut être: Un champ de la table Une constante ("XXX" ou 'XXX') (ignorée en import) =Expression (ignorée en import) *1, *2 etc. pour référence à la variable GIMP(i) (import) Remarques : Numéro de table utilisée pour un transcodage de données Le chemin d'accès peut inclure le caractère '#' pour numérotation séquentielle du fichier. Le bouton Export sert à définir les paramètres par défaut (critères et formules de sélection), qui seront préchargés lors de l'exécution manuelle d'un export ou utilisés directement lors de l'exécution d'un enchaînement.

Tables de transcodage d’imports/exports
3.1 Import / Export Tables de transcodage d’imports/exports Paramétrage / Exploitation / Transcodage Import/Export Cette fonction permet de définir des tables de correspondance : Entre codes locaux et codes externes Associables à un modèle d’import/export Fonctionnant à la fois en import et en export Avec des valeurs par défaut possibles (*) Dans l’exemple ci-contre : En export : CHQ est transcodé en CHEQUE TRT est transcodé en TRAITE (1er choix de la liste) DIV n’est pas transcodé (*) Tout autre choix est transcodé en AUTRES En import : CHEQUE est transcodé en CHQ TRAITE et EFFET sont transcodés en TRT Tout autre choix est transcodé en DIV AUTRES n’est pas transcodé Remarques : Les espaces ne sont pas significatifs et sont filtrés avant de faire un transcodage. Ceci signifie par ailleurs qu’il est impossible de saisir un espace dans l’un des codes externe ou interne * du côté Code externe signifie : En export, qu’on ne doit pas transcoder le code local associé En import, que toutes les valeurs non listées doivent être transcodées avec le code local associé * du côté Code local signifie : En export, que le code externe associé doit être utilisé pour transcoder tous les codes internes non listés En import, que le code externe associé ne doit pas être transcodé.

Paramètres d’imports /export
3.1 Import / Export Paramètres d’imports /export Paramétrage / Exploitation / Utilisés pour définir les emplacements par défaut des fichiers utilisés pour l'import/export sur le client ou sur le serveur. Ceci n'est pas obligatoire mais ajoute de la cohérence à la gestion des imports/exports. Les répertoires par défaut sont symbolisés par le caractère '%' dans les modèles d'import/export (champ Fichier de données). B 1 A Transfert en fin d’export Déplacement en début d’import B A 1 2 Remarques : 2 Transfert des lignes importées Copie des lignes erronées 3 4 3 4

Imports et exports chronologiques
3.1 Import / Export Imports et exports chronologiques Exploitation / Import/export / Export Un export chronologique se déclenche en activant la case à cocher Gestion Chrono : L’export est alors basé sur un numéro de chrono géré comme un time-stamp, pour effectuer des extractions différentielles Seuls les enregistrements modifiés depuis le dernier export sont exportés La variable [C]EXPORT contient le numéro chronologique courant et est incrémentée à la fin de chaque export, quel que soit le modèle utilisé. La valeur courante du numéro chronologique est stockée dans le champ EXPNUM d'un enregistrement lorsqu'il est modifié ou créé, et dans le champ EXPORT du modèle à la fin de chaque export. Un export avec gestion de chrono ne touche que les enregistrements dont EXPNUM est plus grand que le champ EXPORT du modèle. Remarques :

3.1 Import / Export Imports et exports chronologiques Exploitation / Import/export / Export Exemple de séquence d’export chronologique : EXPORT = 3 Modèle export SOH [C]EXPORT = 5 Commande 34 EXPNUM = 2 Commande 35 EXPNUM = 1 Commande 36 EXPNUM = 4 1 [C]EXPORT = 6 La commande 36 est exportée EXPORT CHRONOLOGIQUE . DES COMMANDES AVEC LE MODELE SOH 2 Commande 34 EXPNUM = 2 Commande 35 EXPNUM = 1 Commande 36 EXPNUM = 4 EXPORT = 5 Modèle export SOH Remarques : MODIFICATION DE LA COMMANDE 34 3 Commande 34 EXPNUM = 9 [C]EXPORT = 9 [C]EXPORT = 10 La commande 34 est exportée 4 EXPORT CHRONOLOGIQUE . DES COMMANDES AVEC LE MODELE SOH Commande 34 EXPNUM = 2 Commande 35 EXPNUM = 1 Commande 36 EXPNUM = 6 EXPORT = 9 Modèle export SOH

3.1 Import / Export Imports et exports chronologiques Exploitation / Import/export / Export Il est conseillé de mettre un # dans le fichier utilisé pour les exports chronologiques : Le # est remplacé par le numéro de chrono formaté sur 8 caractères avec des zéros En import : Si un # est détecté dans le nom du fichier, on importe tous les fichiers correspondant à cette règle de nommage, dans l’ordre croissant des numéros. Ainsi, deux fichiers exportés successivement seront importés dans l’ordre chronologique d’extraction Remarques :

Enchaînements d’import /exports
Paramétrage / Exploitation / Enchaînements Exploitation / Imports/Exports / Imports enchaînés -- Exports enchaînés Enchaînements d’import /exports Un enchaînement est une série d'imports ou d'exports enchaînés à l’exécution : Ceci est utile notamment lorsqu'un processus d'import ou d'export doit se servir de plusieurs fichiers. L'exécution d'un enchaînement est gérée par le serveur batch. Lorsqu'on exécute un enchaînement d'exports avec gestion chronologique, le numéro de séquence est incrémenté une seule fois. L'enchaînement utilise un seul numéro de séquence, ce qui garantit la cohérence de l’ensemble. Remarques :

3.2 Gestion des états Principes de base Le dictionnaire des états
Lancement des états Affectation des codes internes Valeurs par défaut des paramètres

Gestion des états : principes de base
Développement / Traitements / Etats / Dictionnaire des états Gestion des états : principes de base Les états sont : Définis à l’aide du générateur d’états Crystal ReportsTM (fichiers d’extension .rpt ) Répertoriés dans un dictionnaire d’états qui pointe sur un état et référence en outre leurs paramètres Les états sont téléchargés depuis le serveur, puis exécutés : Directement sur le poste client via une librairie (DLL) Crystal Reports Sur un serveur d’impression quand l’état est lancé depuis un poste Web Sur un serveur d’impression quand l’état est lancé depuis une tâche batch Un serveur d’impression est un serveur Windows sur lequel sont installés, outre des composants ADONIX, les librairies Crystal Reports idoines. Remarques :

Le dictionnaire des états
3.2 Gestion des états Développement / Traitements / Etats / Dictionnaire des états Le dictionnaire des états C’est une fonction située dans le développement Il est donc nécessaire, lorsqu’on crée de nouveaux états : De respecter des règles de nommage (noms commençant par X, Y, ou Z) De marquer ces états par un code activité spécifique De même, il faut, si on modifie des états standards : Renommer les fichiers d’extension .rpt Modifier la fiche de l’état pour le faire pointer sur l’état modifié Certains champ du dictionnaire des états sont considérés comme du paramétrage Leur modification est sauvegardée Il ne faut donc pas utiliser de code activité si seules ces champs sont modifiés ! Remarques :

Le dictionnaire des états : Premier onglet
3.2 Gestion des états Développement / Traitements / Etats / Dictionnaire des états Le dictionnaire des états : Premier onglet Les zones encadrées sont des paramètres (pérennes) Groupe d’états Menu local 97 (personnalisable) Permet de gérer des habilitations Gestion des langues Chaque fichier .rpt est stocké dans un répertoire dépendant de la langue Règles d’affectation des sorties Traitements préliminaires Exécutés avant l’état Permet d’alimenter un fichier temporaire que l’on imprime Remarques : Le menu local permet d’étendre les groupes d’états (une habilitation globale par groupe existe dans la définition des utilisateurs). On retrouve ensuite l’habilitation plus fine par code activité (c’est bien sûr le droit d’exécution qui est utilisé pour avoir le droit d’imprimer). La gestion des autorisations par site fonctionne de la façon suivante : Si une autorisation par site ou par société existe, on vérifie quels sont les sites autorisés à l’utilisateurs pour la fonction mentionnée. Si aucune fonction n’est mentionnée, on reprend les droits par site sur la fonction RPTnn, nn étant le numéro du groupe auquel appartient l’état On fait alors un contrôle sur les paramètres sociétés et sites de la façon suivante : Si un paramètre de type société est présent dans les paramètres de l’état, on vérifie que la totalité des sites de la société est accessible à l’utilisateur; s’il s’agit d’un paramètre de type site, on vérifie qu’il est accessible à l’utilisateur Si un paramètre de type bornes de société ou bornes de sites est présent dans les paramètres de l’état, on vérifie que tous les sites compris dans ces bornes sont accessibles. Si une erreur quelconque se produit, on refuse l’édition de l’état en signalant la liste des sites auxquels l’utilisateur n’a pas accès. Attention, il s’agit uniquement d’un contrôle de bornes. On ne contrôle pas (et on ne peut pas le faire) que la logique de l’état ne va pas rechercher des données liées à des sites non accessibles. Les contraintes liées au serveur batch seront expliquées plus loin dans le cours. Association aux fichiers .rpt 1 à 5 états peuvent être enchaînés (paramètres identiques obligatoires) Règles d’accès et de lancement Non exécutable signifie pas en direct depuis la fonction d’impression

Le dictionnaire des états : Deuxième onglet
3.2 Gestion des états Développement / Traitements / Etats / Dictionnaire des états Le dictionnaire des états : Deuxième onglet On définit les paramètres et leurs caractéristiques (type de données, valeurs par défaut, contrôles). Remarques : Le paramètre de segmentation est un peu particulier. Il doit correspondre à un paramètre de type borne de l’état, qui permet de segmenter l’état si on découpait les bornes en sous-intervalles. Il sert pour les états particulièrement volumineux (plusieurs dizaines de milliers de pages, par exemple). Crystal Reports pose alors des problèmes de performances, qu’ADONIX X3 résout en lançant plusieurs fois le même état, en découpant les bornes, conformément à des intervalles à saisir par clic droit lors de la saisie des paramètres.

Lancement d’un état : écran
3.2 Gestion des états Impressions / Impressions Lancement d’un état : écran On saisit : les paramètres de lancement La destination si elle est répertoriée dans la table des destinations sinon, on saisit la destination et le chemin de l’imprimante : Remarques : Les valeurs par défaut proposées pour les paramètres viennent de l’état, mais peuvent aussi venir du contexte de lancement (cf. plus loin) Lorsque les destinations sont répertoriées (cf. plus loin), la valeur par défaut proposée pour la destination peut être définie en fonction du contexte Le choix Imprimante / Fichier permet de créer un fichier d’extension .prn (en général très volumineux) qui stocke le résultat tel qu’il aurait été envoyé à l’imprimante. Lorsqu’on choisit le format si on crée un fichier des éléments complémentaires

Lancement des états : cinématique
3.2 Gestion des états Impressions / Impressions Lancement des états : cinématique Fichier / Impression ou Fichier / Liste depuis la gestion d’objet Fonction X3 Impression automatique Impressions / Impression/groupe Impressions / Impressions Code interne état Fichier / Impression Fichier / Liste Objet X3 Langue de connexion FRA Règle d’association d’un code interne à un ou plusieurs codes états : si plusieurs, on donne le choix à l’exécution Si aucune indirection, code état = code interne Développement/Dictionnaire traitements/Etats/Codes impression Rappel : Les affectations d’états réalisées par Fichier / Impression et Fichier / Liste sont paramétrables (Paramètres / Paramètres généraux / Personnalisation objets) Code état Lancement de l’état Crystal Reports™ Définition contextuelle par des formules de valeurs par défaut pour les paramètres de l’état Développement/Dictionnaire traitements/Etats/Valeurs par défaut

Affectation des codes internes à des états
3.2 Gestion des états Développement/Dictionnaire traitements/Etats/Codes impression Affectation des codes internes à des états Affectation multiple : Choix à l’impression Affectation simple : Indirection Remarques : La table des codes impression est du paramétrage, dans la mesure où : Les affectations relatives à des états spécifiques (dont le code commence par X,Y ou Z) ne sont pas touchées par une mise à jour Lorsque aucune règle d’affectation n’existe pour un état standard donné, on crée les règles d’affectation si elles sont livrées dans une version mineure. Sinon, on respecte les règles d’affectation existantes. Pas de ligne présente : Le code de l’état est utilisé

Valeurs par défaut des paramètres d’états
3.2 Gestion des états Développement/Dictionnaire traitements/Etats/Valeurs par défaut Valeurs par défaut des paramètres d’états ! C’est une fonction située dans le développement qui permet : De donner des valeurs par défaut contextuelles quand un état donné est appelé depuis une fonction donnée En l’absence de telle règle, les valeurs par défaut données dans le dictionnaire des états s’appliquent. Remarques : La définition de valeurs par défaut est du développement, dans la mesure où : Un code activité commençant par X,Y, ou Z permet de protéger les nouvelles affectations ou les affectations modifiées Un ensemble de valeurs par défaut standard est fourni et maintenu. Ces valeurs sont essentiellement liées à des enchaînements d’impression totalement automatisés dans certaines fonctions. Une bonne connaissance du contexte d’appel est nécessaire

3.3 Gestion des destinations d’états
Paramétrage / Destinations / Destinations La table des destinations permet de définir des destinations de sortie d’états: supposées partageables entre les utilisateurs (chemin réseau accessible) avec un type discriminant vis à vis des états utilisables comme valeur par défaut Elle n’empêche pas l’utilisation, au lancement de l’état, d’une imprimante non répertoriée par le choix classique d’une imprimante sous Windows TM Remarques : Le premier type de destination désigne des destinations « passe-partout » utilisables pour tous les états même si ceux-ci exigent un type d’imprimante particulier. Même si dans la plupart cas la notion de destination peut être associée à une imprimante physique, elle permet plus généralement d’envoyer un message, de créer un fichier, ou de pré-visualiser uniquement à l’écran. Code d’accès S’il est renseigné, l’utilisateur doit avoir les droits d’exécution pour utiliser l’imprimante Serveur Si on passe par un serveur d’impression Type d’imprimante Menu local 22 (intitulés modifiables) Le premier type est un type par défaut

3.3 Gestion des destinations d’états
Serveurs d’édition Les serveurs d’éditions correspondent à des serveurs : accessibles par le réseau sur lequel un run-time adonix et Crystal Reports a été installé Les serveurs d’éditions sont définis par le biais de la console de configuration. Remarques :

Affectation des destinations
3.3 Gestion des destinations d’états Paramétrage / Imprimantes / Imprimantes par utilisateur Affectation des destinations 2 Définition de l’état (code, destination par défaut, formule complément) Fiche utilisateur Imprimantes utilisateur (le code utilisateur par défaut) Destinations par utilisateur (Etat, Complément)  Destination Remarques : Les règles données ici permettent, lorsqu’on lance un état, de proposer une imprimante par défaut à l’utilisateur. Dans tous les cas : le type défini sur la fiche état est respecté (mais le type 1 est passe-partout) si l’imprimante est protégée par un code d’accès, l’utilisateur doit avoir les droits d’exécution sur cette imprimante (sinon, on recherche une autre imprimante par l’algorithme). Si la règle finalement utilisée porte une information Obligatoire (oui/non) et si sa valeur est Oui, l’utilisateur ne pourra pas la modifier. Dans tous les autres cas, ce n’est qu’une valeur par défaut. Les priorités d’affectation sont les suivantes : La table des imprimantes par utilisateur est la plus prioritaire. Elle est explorée d’abord pour la bonne valeur du complément évalué s’il existe, et à défaut avec un complément vide. Si rien n’est trouvé, on prend l’imprimante par défaut définie sur l’état Puis on prendra l’imprimante par défaut de l’utilisateur Il existe un niveau 4 de priorité non présenté ci-dessus : ce sont les variables PRT1, PRT2, PRT3, PRT4… associées au site de l’utilisateur, pour le module dont dépend l’état Si rien n’est trouvé : on prend la première imprimante du bon type en batch, la première imprimante de type pré-visu en interactif La formule de complément est une expression pouvant faire appel à toute variable disponible dans l’environnement, y compris les valeurs de paramètres sous la forme PARAM(NOM_PARAMETRE). Par exemple, PARAM(SOCIETE) Si l’imprimante est modifiable, et si l’utilisateur supprime le code imprimante, il se retrouve en choix d’imprimante Windows (comme on pouvait le faire en version 130). Ceci suppose que le paramètre utilisateur WINIMP soit égal à Oui (sinon, ceci n’est pas possible). 3 1

3.4 Portail utilisateur Portail utilisateur
Paramétrage / Portail / Pages du portail Portail utilisateur Un portail correspond au contenu de l’écran ADONIX X3 présenté à l’utilisateur : Lors de sa connexion en client-serveur En cliquant sur l’onglet Portail en mode Web Caractéristiques principales Permet de présenter des pages HTML, des données mises en forme par des composants standard (graphes flash, tableaux de présentation, calendriers…) De façon personnalisée Par utilisateur ou groupe d’utilisateur En tenant compte du contexte de connexion En réutilisant des fonctions d’extractions standard du progiciel Avec des zooms sur les fiches liées aux données présentées Remarques : L’entrée dans un portail peut être longue si de mutiples éléments y sont présents. Il est donc conseillé de limiter le nombre de vues que l’on y place, surtout si ces vues sont peuplées par des données nombreuses ou complexes à extraire. Il est à noter que les données présentées dans le portail sont envoyées au navigateur (que ce soit en poste client ou en Web) via une « datasource ». Ceci signifie que les données ne sont jamais présentes dans le cache du navigateur, ce qui est une garantie de sécurité lorsque des postes à accès public existent.

3.4 Portail utilisateur Portail utilisateur
Paramétrage / Portail / Pages du portail Portail utilisateur Issu d’un paramétrage de pages portail : Identifiées par un code Associées à l’utilisateur par le paramètre PTLPAGE Chaque page définit : Une organisation (en 1, 2, 3 ou 4 cadres) Chaque cadre contient : Soit une page Web Soit une “vue de portail” qui associe : une source de données (logique d’extraction des données) un composant visuel (mode de présentation) Remarques : L’entrée dans un portail peut être longue si de mutiples éléments y sont présents. Il est donc conseillé de limiter le nombre de vues que l’on y place, surtout si ces vues sont peuplées par des données nombreuses ou complexes à extraire.

Vue du Portail : sources de données
3.4 Portail utilisateur Paramétrage / Portail / Vues du portail Vue du Portail : sources de données Une source de données identifie la façon dont les données sont extraites Elle est définie par des codes normalisés (table diverse 90) Certains codes correspondent à des fonctions d’exploitation accessibles par ailleurs : REQ : Requête (paramétrée par le requêteur ou le requêteur SQL) STA : Statistique (paramétrage des statistiques) D’autres sont plus particulières AGD : Agenda du CRM MLT : multi-liste (ensemble de listes de gauche d’objets) TRT : traitement normalisé d’extraction (identifié par un code action) WEB : page http dont l’adresse est évaluée au moment de l’exécution Remarques : La communication entre sources de données et composants visuels se fait par des flux XML. Le traitement normalisé doit donc prendre en charge la logique d’extraction et mettre en forme les flux XML correspondants. La création d’un tel traitement est hors de propos de ce cours, mais les développeurs regarderont avec profit les traitements SUBAPSTRT (exemples) et SUBAPSTRTI (commentaires complémentaires) fournis en source.

3.4 Portail utilisateur Paramétrage / Portail / Vues du portail Vue du Portail : sources de données Outre le code identifiant la source, on a des paramètres complémentaires : dépendant du type de source de données saisis dans un tableau sous forme de formule (dépendant du contexte) Les paramètres « source » sont les suivants : Source REQ : Fréquence de mise à jour (horaire, journalière, à l’utilisation) Niveau de rupture pour la présentation des données (1 à N) Source TRT : 4 paramètres de type chaîne de caractères banalisés (P1 à P4) Source WEB Adresse (paramètre URL) Remarques : Sur la source de données REQ, on notera les points suivants : Quand cette source de données est invoquée, on vérifie, en fonction de la dernière date et heure d’interrogation, si elle doit être rafraîchie. La fréquence de rafraîchissement peut avoir une influence importante sur les performances si la requête est complexe à exécuter, rafraîchie à chaque invocation, et utilisée par un grand d’utilisateurs. Quand une source de données de ce type est utilisée par un grand nombre d’utilisateurs, il est conseillé de la rafraîchir à une fréquence raisonnable et surtout de la rendre partagée pour éviter que chaque utilisateur n’en ait sa version (sauf si elle dépend de l’utilisateur par le biais de formules de sélection).

3.4 Portail utilisateur Paramétrage / Portail / Vues du portail Vue du Portail : sources de données Paramètres « source » (suite) : Source STA : Codes société et site pour filtre Dates de début et de fin (période 1 et 2) Critères fixés (CRIT1 à CRIT8). Le premier critère égal à la chaine vide détermine le niveau de zoom de la statistique Source MLT : Pas de paramètre complémentaire (on saisit le code de la multi-liste) Source AGD : Nombre de mois avant et après la date courante Remarques : Les codes sociétés et sites peuvent bien entendu être vides si on ne désire pas de filtre (il suffit de mettre alors une expression de type "") La variable globale GFCYDEF(sites par défaut dépendant du module : 0=superviseur, 1=comptabilité, 2=tiers… conformément à l’ordre donné dans l’écran des profils fonction) peut être utilisée si on désire faire apparaître des données liées au site par défaut de l’utilisateur La variable globale GAUSCRMF permet de connaître le code du commercial associé à l’utilisateur courant (paramètre CRM) : cela peut être intéressant pour filtrer des statistiques selon le commercial connecté. Pour les dates, il peut être intéressant d’utiliser des formule du genre : gdat$(1, month(date$),year(date$)) : début du mois courant gdat$(1, month(date$)-(day(date$)<5),year(date$)) : début du mois courant, ou du mois précédent avant le 5 du mois. eomonth(gdat$(1, month(date$),year(date$))) : fin du mois courant Mais il existe également des paramètres tels que GDATDEB, GDATFIN (dates courantes de connexion par défaut), GDATSTADEB, GDATSTAFIN (période par défaut pour les statistiques)…

Vue du Portail : Composants visuels
3.4 Portail utilisateur Paramétrage / Portail / Vues du portail Vue du Portail : Composants visuels Les composants visuels : sont définis par un code dans la table diverse 91 correspondent à des composants à mêmes de présenter l’information ne sont pas compatibles avec toutes les sources de données peuvent nécessiter des paramètres complémentaires Remarques : Sur la source de données REQ, on notera les points suivants : Quand cette source de données est invoquée, on vérifie, en fonction de la dernière date et heure d’interrogation, si elle doit être rafraîchie. La fréquence de rafraîchissement peut avoir une influence importante sur les performances si la requête est complexe à exécuter, rafraîchie à chaque invocation, et utilisée par un grand d’utilisateurs. Quand une source de données de ce type est utilisée par un grand nombre d’utilisateurs, il est conseillé de la rafraîchir à une fréquence raisonnable et surtout de la rendre partagée pour éviter que chaque utilisateur n’en ait sa version (sauf si elle dépend de l’utilisateur par le biais de formules de sélection).

Portail utilisateur et habilitations
Paramétrage / Portail / Pages du portail Portail utilisateur et habilitations Le portail, lorsqu’il s’exécute, utilise la fonction APTLREQ : Cette fonction doit donc être autorisée pour le profil de l’utilisateur … faute de quoi un message d’erreur s’affichera, et le portail ne sera pas visible. Les zooms vers les objets, lorsqu’ils s’exécutent, utilisent la fonction APTLOBJ : … faute de quoi un message d’erreur s’affichera, et les zooms ne seront pas activés. Remarques :

Styles de présentation
3.5 Gestion des styles Styles de présentation Paramètres / Paramètres généraux / Styles / Styles de présentation Permet de définir des mises en valeurs particulières dans les écrans Polices particulières Couleur et couleur de fond Tailles de caractères Effets (gras, italique, souligné, barré…) De façon fixe, contextuelle, ou générique Les styles utilisés sont Identifiés par un code Sont modifiables par paramétrage par groupes d’utilisateurs Affectés par paramétrage ou développement aux éléments à mettre en valeur Remarques : Style fixe : défini par le développeur pour mettre en exergue un champ particulier Style générique : par défaut, les champs ayant des caractéristiques particulières (présence d’une sélection, champ obligatoire…) peuvent être mis en valeur Style contextuel : entièrement paramétrable par l’utilisateur dans le paramétrage des styles conditionnels

Définition d’un style de présentation
3.5 Gestion des styles Définition d’un style de présentation Paramètres / Paramètres généraux / Styles / Styles de présentation Un style de présentation se définit par Un code et des intitulés La définition en elle-même La saisie peut se faire par un assistant Remarques : Un style se définit par un nom. Il est recommandé de ne pas leur donner des noms décrivant l’effet lui-même (par exemple ROUGE, ou GRAS, ou TAHOMA_8), mais plutôt la fonction (ALERTE, NEGATIF, IMPORTANT). En effet, le style peut être changé à tout moment dans cette fonction : toute personne se reconnectant reçoit la description des styles modifiés sous forme XML, et les effets changent immédiatement sur les champs concernés. Ainsi, si quelqu’un modifie la couleur associée au style ROUGE et la remplace par du vert, seuls les daltoniens n’y verront que du feu…

Utilisation d’un style de présentation
3.5 Gestion des styles Utilisation d’un style de présentation Paramètres / Paramètres généraux / Styles / Styles de présentation Utilisation des styles : Pour les titres (via le dictionnaire) des champs des blocs dans les écrans Pour les valeurs de champs dans les écrans : De façon statique De façon dynamique par la fonction de mise en valeur Dans certains écrans (tableaux de bord comptables) De façon générique pour mettre en évidence certaines caractéristiques (en permettant de marquer les titres, les valeurs, et en distinguant les champs en liste et les champs en tableaux) : Champ obligatoire Présence d’une fenêtre de sélection Présence d’un tunnel Saisie d’une formule de calcul Remarques : Les styles génériques sont des styles prédéfinis qui correspondent à la mise en valeur des champs : ils sont codifiés sous la forme AXYZZZ, où : A est le caractère A X prend les valeurs F (pour field, ie. champ dans un bloc de type liste) ou T (pour table, ie. champ dans un bloc de type tableau) Y prend les valeurs T (pour title, ie. titre du champ) ou V (pour value, ie. valeur du champ) ZZZ prend les valeurs MAN (pour mandatory, champs obligatoires), SEL (champs sélections), TUN (champs avec tunnel), ou FOR (champs formules) Exemples : AFTFOR est le style utilisé pour caractériser le titre des champs permettant de saisir une formule dans un bloc liste d’écran; ATVSEL est le style utilisé pour caractériser le champ d’un tableau sur lequel existe une sélection (sans tunnel); D’autres styles prédéfinis existent, notamment les styles utilisés pour les tableaux de bord, qui sont codifiés TBXY, le style utilisé pour l’affichage des traces (TRACE, pour lequel une police de taille fixe est recommandée). Remarque : si on supprime un style, et que ce style a été utilisé dans certains écrans, aucune erreur ne se produit, mais le champ retrouve simplement son aspect par défaut.

Définition d’un style personnalisé
3.5 Gestion des styles Définition d’un style personnalisé Paramètres / Paramètres généraux / Styles / Styles personnalisés Un style personnalisé permet d’associer des effets particuliers : pour les styles de présentation précédemment définis pour un code de personnalisation donné On peut associer aux utilisateurs un code de personnalisation donné : par le biais du paramètre utilisateur STYLE par défaut (paramètre non renseigné), on utilise les effets associés au style de présentation standard Remarques : Dans cet écran, il n’est pas possible de créer de nouveaux codes de style, mais uniquement de modifier les effets associés. Un nouveau code doit être défini en gestion des styles de présentation.

3.5 Gestion des styles Styles conditionnels
Paramètres / Paramètres généraux / Styles / Styles conditionnels Permet de définir des styles sur la valeur du champ uniquement : Par une liste De conditions De styles associés La première condition remplie détermine le style utilisé. Si la dernière ligne n’a pas de condition, elle est utilisée si les autres conditions ne sont pas remplies. Remarques : Les valeurs significatives dans le contexte d’utilisation peuvent être employées dans les conditions; la variable associée au champ courant s’appelle zc; elle peut être utilisée sans restriction. Les restrictions suivantes existent sur la mise en valeur des champs : En client-serveur, dans un tableau, les champs affichés (instruction Diszo) ont une couleur imposée (gris 128,128,128) qui ne peut pas être modifiée. La couleur de fond, la police, la taille, et les attributs autres que l’italique peuvent être modifiés. En client-serveur, dans un tableau, les champs désactivés (instruction Grizo) ont une couleur imposée (gris 128,128,128) qui ne peut pas être modifiée, et sont en outre en italique. La couleur de fond, la police, la taille, et les attributs autres que l’italique peuvent être modifiés. En client-serveur, dans un bloc liste, les champs affichés et les champs désactivés ont une couleur de fond imposée (la couleur du fond Windows) qui ne peut pas être modifiée. La couleur des caractères, la police, la taille, et les attributs autres que l’italique peuvent être modifiés. En mode Web, il n’y a pas de contrainte sur les champs désactivés. En mode Web, sur les champs affichés, seuls les styles liés à la couleur de fond, à la taille et à la police, au soulignement et à l’italique peuvent être affectés de façon dynamique ; la couleur de la police peut être affectée de façon statique (dans l’écran).

Affectation de styles conditionnels
3.5 Gestion des styles Affectation de styles conditionnels Paramètres / Paramètres généraux / Styles / Personnalisation écrans Se fait par affectation d’un style conditionnel à un écran : De façon pérenne (respecté en cas de mise à jour) Par simple rappel de l’écran dans la fonction dédiée Remarques : Si un style conditionnel n’est utilisé que sur un écran donné, on peut utiliser les valeurs des autres champs de l’écran dans les conditions.

Gestion du vocabulaire lié au dictionnaire
3.6 Personnalisation du vocabulaire Gestion du vocabulaire lié au dictionnaire Paramètres / Paramètres généraux / Personnalisation vocabulaire Le dictionnaire utilise des textes traduisibles stockés dans : la table APLSTD (menus locaux) la table ATEXTE (textes écrans) Ils sont : fournis en standard remis à jour à chaque installation de version (sauf menus locaux modifiables par l’utilisateur) Ecrits « en dur » dans la description des écrans et fenêtres lors de leur validation. La gestion du vocabulaire stocke dans une table dédiée : Des valeurs de menus locaux Des textes Ces textes remplacent le contenu d’APLSTD et ATEXTE DOSSIER DE REFERENCE Menus locaux (APLSTD) Textes traduisibles (ATEXTE) Copie des menus locaux non modifiables Copie des textes PROCESSUS DE VALIDATION DOSSIER D’EXPLOITATION Remarques : Sur le fichier ATEXTE, le schéma est un peu réducteur. En réalité, les textes dont le numéro est supérieur à ne sont pas copiés du dossier de référence X3 (ils n’existent pas dans ce dossier); dans le cas d’une hiérarchie à 3 niveaux, on renumérote ces textes dans le dossier d’exploitation pour qu’il y ait correspondance avec le niveau intermédiaire. Même si cette fonctionnalité permet de transformer tout le vocabulaire utilisé par X3 (par exemple, remplacer « client » par « assuré » ou par « organisme » selon les clients que l’on gère), il faut être conscients que : Cela peut être lourd à gérer (il y a aujourd’hui environ messages dans ADONIX X3). Si de nouveaux messages arrivent (par patch par exemple), il faudra revenir voir s’il y a besoin de les personnaliser. Les états ne seront pas automatiquement retraités. Dernier point important : seul le vocabulaire standard (textes <50.000) peut être personnalisé. La fonction n’a pas du tout été prévue pour les textes spécifiques dont les numéros sont supérieurs à Menus locaux (APLSTD) Textes traduisibles (ATEXTE) Vocabulaire (AVOCAB) Génération de l’interface Copie du vocabulaire personnalisé

Gestion du vocabulaire lié au dictionnaire
3.6 Personnalisation du vocabulaire Gestion du vocabulaire lié au dictionnaire Paramètres / Paramètres généraux / Personnalisation vocabulaire On saisit dans l’écran : Le type (message ou texte) et la clé (chapitre/numéro ou numéro) Le texte modifié Remarques : On dispose de deux outils de recherche de textes : Par clic droit sur la ligne, pour recharger un ensemble de textes Par clic doit sur le champ (choix d’un texte) La recherche est indépendante de la casse (majuscule/minuscule/accents)

3.7 Le serveur batch Caractéristiques du serveur batch :
Exploitation / Serveur batch / … Caractéristiques du serveur batch : C’est un processus fonctionnant en arrière-plan sur le serveur de traitement, qui gère le lancement de tâches batch correspondant à des traitements X3 ou à des commandes OS. Il est géré par une dossier spécial dédié, appelé SERVX3. Les tâches soumises au serveur batch s'appellent des requêtes. Elles sont lancées par le serveur sous forme de processus Adonix en arrière-plan. Mise en service du serveur : au lancement du système : adonix -a -l lang SERVX3 à partir d'X3 : Exploitation / Serveur batch / Activation serveur automatiquement à la connexion d'un utilisateur (paramètre DEMSRV). Arrêt du serveur : à partir d'X3 : Exploitation / Serveur batch / Désactivation serveur en créant un fichier stop dans le répertoire FIL du dossier SERVX3 en arrêtant la base (pour une sauvegarde par exemple) Remarques :

Principes de fonctionnement
3.7 Le serveur batch Exploitation / Serveur batch / … Principes de fonctionnement Le serveur batch fonctionne par "polling" : Interrogation périodique de la table des requêtes soumises. Lorsque l'heure de démarrage d'une requête est arrivée ou dépassée, la requête est lancée (sauf si elle est trop en retard, ou si le nombre maximum de tâches simultanément en cours est dépassé). Lorsque le temps maximum (time-out) d’exécution alloué à une tâche est dépassé, la tâche est interrompue. Trace du serveur DOSSIER SERVX3 DOSSIER D’EXPLOITATION Lancement Serveur Batch (processus SERVX3) Processus batch Abonnements Remarques : Interruption (time-out, demande d’arrêt) Trace du processus Polling périodique ? Table des requêtes (ABATRQT) Soumission Session utilisateur Soumission par dépose de fichier

Principes de fonctionnement
3.7 Le serveur batch Exploitation / Serveur batch / … Principes de fonctionnement Une requête est une demande d’exécution d’une ou plusieurs tâches soumises au serveur : Par la fonction de soumission des requêtes Exploitation / Serveur batch / Soumission des requêtes. Directement depuis la fonction de surveillance des requêtes par clic droit sur le tableau des requêtes Exploitation / Serveur batch / Gestion des requêtes. Par dépose d’un fichier dans un répertoire du serveur de traitement Peut être piloté par un automate externe Par le biais d'un abonnement, c'est à dire une requête à lancer périodiquement Exploitation / Serveur batch / Gestion des abonnements. Mensuel, Hebdomadaire, en fréquence Remarques :

Définition d’une tâche
3.7 Le serveur batch Définition d’une tâche Exploitation /serveur batch/ Gestion des tâches Si la tâche est active au-delà de cette durée, elle est arrêtée. Si la tâche n’a pas pu être lancée au delà de ce délai, elle ne sera pas lancée. Niveau minimal que doit avoir l'utilisateur pour lancer la tâche (paramétrage utilisateur) Paramètre transmis au système d’exploitation Numéro de service (le service adonix par défaut) Table définissant les horaires admissibles Ce flag signifie que la tâche peut être lancée dans un dossier sur les données d’un autre (ceci suppose qu’elle ait été écrite pour le permettre) La tâche ne pourra être lancée que si aucun autre utilisateur n’est connecté sur le dossier Remarques : Une tâche est définie en spécifiant une fonction ou un traitement X3, ou un script (shellscript sous UNIX™, script Windows™). Pour une impression d'état en batch, le traitement est BATCHIMP. Les fonctions normalisées selon le modèle traitement peuvent être lancées.

Définition d’un groupe de tâches
3.7 Le serveur batch Exploitation / Serveur batch / Groupe de tâches Définition d’un groupe de tâches C’est une suite de tâches exécutées en séquence En cas d’erreur grave dans une tâche, les suivantes ne sont pas lancées Chaque tâche crée sa propre trace A la saisie d’une requête sur le groupe, tous les paramètres des tâches liées sont saisis Niveau minimal que doit avoir l'utilisateur pour lancer le groupe de tâches (paramètre utilisateur) Remarques : Les tâches batch standard d’ADONIX X3 ne créent que des erreurs bénignes. Sauf à avoir un plantage brutal d’une tâche (erreur moteur, par exemple), il n’y aura donc pas d’arrêt d’exécution d’un groupe de tâches standard. Mais un point d’entrée permet, grâce à une variable nommée GERRBATCH, de définir des statuts d’erreur arrêtant un enchaînement de tâches (il faut que GERRBATCH soit supérieur ou égal à 100 pour cela). Table définissant les horaires admissibles Liste des tâches à enchaîner

3.7 Le serveur batch Contraintes horaires
Paramétrage / Exploitation / Contraintes horaires Paramétrage / Exploitation / Calendrier d’exclusion Contraintes horaires Définit les horaires admissibles pour lancer une tâche batch Associé à une tâche ou à un groupe de tâches Deux types de jours : ouvrés, et non ouvrés / fériés, chacun avec des plages horaires possibles Remarques : Seule l’heure de lancement telle qu’elle est définie est contrôlée. Si la tâche ne peut pas être lancée à l’heure prévue parce que le nombre maximum de tâches simultané serait dépassé, la tâche sera lancée plus tard, et elle peut l’être dans une plage horaire qui n’est plus la bonne. Pour éviter ceci, il faudra jouer avec le paramètre définissant le retard admissible

Définition d’un abonnement
3.7 Le serveur batch Exploitation / Serveur batch / Gestion des abonnements Définition d’un abonnement C’est une tâche ou un groupe de tâches exécutés de façon régulière : Avec une périodicité variable (hebdomadaire, mensuelle) A heures fixes ou en fréquence dans une plage horaire A la création d’un abonnement, les paramètres doivent être saisis. Définition du contexte d’exécution : Dossier, utilisateur, groupe ou tâche à lancer Base périodique de lancement Calendrier d’exécution Remarques : La prise en compte d’un abonnement crée une requête régulièrement dans la table des requêtes à exécuter Dans le cas d’un déclenchement en fréquence, la tâche n’est déclenchée que si la précédente instance d’exécution est terminée. Le flag Fin de mois correspond à une fin de mois calendaire et ne se rapporte pas à un calendrier comptable (dans le contexte, on ne voit pas comment on pourrait le rattacher à une société). Base hebdomadaire : Liste des jours de déclenchement Base mensuelle : 1 à 5 Quantièmes de déclenchement Flag Fin de mois Horaires de lancement : Soit 1 à 3 heures Soit une fréquence entre deux horaires Flag exécution forcée La tâche est exécutée au moins une fois par jour, même si l’horaire est dépassé

Soumission d’une requête
3.7 Le serveur batch Soumission d’une requête Exploitation / Serveur batch / Soumission des requêtes La soumission d’une requête se fait par saisie : du dossier où elle doit être exécutée du code utilisateur de la tâche ou du groupe de l’heure demandée d’exécution La fenêtre de saisie des paramètres s’ouvre alors Remarques : Le dossier est le dossier courant par défaut; ce ne peut être un autre dossier que si la tâche est cochée Multi-dossier. Si le code utilisateur n’est pas celui de l’utilisateur courant, la saisie du mot de passe est obligatoire. La date et l’heure proposés par défaut correspondent par défaut à la date et l’heure du jour, ou à la date et l’heure la plus proches compte tenu des contraintes de planning d’exécution La case à cocher Modèle permet de créer un fichier modèle pouvant être utilisé ensuite pourune soumission de tâches (cf. ci-après); dans ce cas, la tâche n’est pas lancée. Ce fichier modèle s’appelle TACHE.mod, TACHE étant le code de la tâche.

Surveillance des tâches
3.7 Le serveur batch Surveillance des tâches Exploitation / Serveur batch / Gestion des requêtes La gestion des tâches permet de surveiller et de modifier les requêtes en attente et les tâches en cours d'exécution ou terminées. Il est possible d'en visualiser les différents fichiers traces, de soumettre une nouvelle requête, de supprimer une requête en attente ou d'en modifier les paramètres etc. Remarques : Fonctions accessibles par clic droit : On peut supprimer la requête, modifier la date et l’heure de lancement, ainsi que les paramètres sur des tâches non encore lancées. On peut consulter la trace des tâches en cours, avortées ou terminées,. On peut relancer des tâches terminées ou avortées, ce qui ajoute une ligne dupliquant la ligne choisie (avec un décalage d’une minute pour permette de modifier ses caractéristiques avant qu’elle soit lancée) On peut interrompre une requête en cours d’exécution. Note : l’habilitation à cette fonction permet de préciser si la personne a accès à toutes ses requêtes ou uniquement à celles qui lui appartiennent.

Soumission de tâche par fichier
3.7 Le serveur batch Exploitation / Serveur batch / … Soumission de tâche par fichier Permet le déclenchement de tâches par des processus externes Soumis à autorisation : Globale (Paramétrage / Exploitation / Paramètres du serveur batch) Par utilisateur (paramètre EXTBATCH) requete.mod Gestion des tâches serveur batch Soumission de tâche requete.job requete.job Prise en compte par le serveur batch requete.req requete.req Remarques : Si des erreurs sont détectées dans les paramètres de lancement de la tâche (utilisateur incorrect, par exemple), le fichier passe directement du statut de .job à celui de .old, et un fichier.sta est créé : la tâche n’aura pas eu le temps de tourner. Si un fichier est dans l’état .req et qu’un fichier .kil est déposé, il passe directement en statut .old, et un fichier .sta est créé. S’il était déjà dans l’état .old (parce qu’un fichier .run existe), la tâche est interrompue, puis le fichier .sta est créé Dans tous les cas, le fichier .kil est effacé lorsque la demande d’interruption a été prise en compte Un fichier de requête se présente sous la forme suivante : DOSSIER=MONDOSS UTIL=TOTO PASSE=WXTYSF GRP= TACHE=VALSTA DATE= HEURE=0752 CODSTA=CA DATDEB= DATFIN= SOCIETE=APN TYPMAJ=2 ZSOCIETE=Société NEGOCE La première partie correspond aux informations génériques de lancement (dossier, utilisateur, mot de passe crypté, tâche ou groupe de tâches, date et heure de lancement), la seconde aux paramètres saisis lors du lancement de la tâche. En soumission de requêtes, la case à cocher Modèle permet de définir un fichier de ce type. requete.old Lancement de la tâche requete.run requete.run Fin de tâche requete.sta Demande d’interruption requete.kil requete.kil

Soumission de tâche par fichier
3.7 Le serveur batch Exploitation / Serveur batch / … Soumission de tâche par fichier Le fichier de statut (requete.sta) est normalisé pour faciliter l’exploitation : Une ligne de longueur fixe, codage ascii 7 bits, séparateur entre deux champs (le « : »), Fin de ligne : CR/LF ou LF selon le système Statut normalisé sur 5 chiffres FSXXX, avec : F=0 : fin normale, SXXX=nombre d’avertissements F=1 : fin sur erreur de traitement, S=sous-cas, XXX=détails F=2 : traitement non lancé, S=sous-cas, XXX=détails F=3 : traitement interrompu, S=sous-cas Le fichier de trace du serveur utilise la même présentation La trace détaillée est dans un fichier nommé RQTnnnnnnnn.tra (nnnnnnnn=no requête sur 8 caractères) 5 chiffres 8 chiffres date/heure date/heure 10 car 5 car 10 car 80 caractères No statut Remarques : Une documentation technique très détaillée (RQT_FILE.htm) est livrée dans la documentation sur le sujet. No requête Début Fin Dossier Utilisateur Tâche Message final Note : correspond à AAAAMMJJhhmmss date/heure

Paramètres du serveur batch
3.7 Le serveur batch Paramétrage / Exploitation / Paramètres serveur batch Paramètres du serveur batch Temps entre deux scrutations Définit le temps entre deux lectures successives de la table des requêtes. Influe sur le délai de prise en compte d'une requête, et inversement sur la charge du système. Influe sur le temps d'entrée dans la fonction de surveillance des tâches. Temps pour scrutation time-out Influe sur le temps d'arrêt d'une tâche trop longue. La scrutation time-out est consommatrice de ressources. Retard maxi pour lancer une requête Evite un lancement tardif si la requête n’a pas pu être lancée à temps (trop de tâches en cours, serveur arrêté) Nombre maximum de requêtes en cours Le maximum dépend de la licence Remarques :

Les fichiers stratégiques du serveur
3.7 Le serveur batch Exploitation / Serveur batch / … Les fichiers stratégiques du serveur Ils sont situés sur le serveur d’application : Dans le répertoire SERVX3/FIL : la présence d’un fichier .run indique normalement que le serveur est en fonctionnement (sauf arrêt intempestif) la présence d’un fichier .stop indique qu’une demande d’arrêt a été transmise au serveur (mais que les tâches lancées par le serveur ne doivent pas être interrompues) la présence d’un fichier .kill indique qu’une demande d’arrêt a été transmise au serveur (avec demande d’interruption des tâches lancées) Dans le répertoire SERVX3/TRA : le fichier serveur.tra contient la trace du serveur les fichiers RQTnnnnnnnn.tra contiennent la trace des tâches Remarques :

Trace détaillée d’une requête
3.7 Le serveur batch Exploitation / Serveur batch / … Trace détaillée d’une requête Chaque requête génère un fichier de trace détaillé : Nommé RQTnnnnnnnn.tra (nnnnnnnn = no requête sur 8 caractères) Codé en UTF8, avec un en-tête normalisé Contenant des lignes de texte sous l’un des formats suivants : <NNNN> Texte Texte Le préfixe <NNNN> permet une mise en évidence en lecture de trace : NNNN<0  avertissement NNNN>0  erreur Remarques : Les valeurs de NNNN sont à la discrétion du programmeur, ceci permet de différencier les erreurs. Le codage UTF8 est un format UNICODE, à même de gérer les caractères sur plusieurs octets, notamment pour gérer les langues orientales. Il correspond à l’ASCII pour les caractères non accentués, les accents européens étant codés sur 2 octets, et certains caractères (idéogrammes) l’étant sur 3 ou 4 caractères. Un autre format existe, c’est l’UCS2, qui stocke chaque caractère sur 2 octets. Le moteur ADONIX sait gérer l’UCS2, et on peut écrire en spécifique des textes de ce type. Pour plusde détails, cf. la variable système adxium.

La tâche batch comptable
3.7 Le serveur batch Exploitation / Serveur batch / Tâche comptabilité La tâche batch comptable La tâche comptable est un cas particulier de tâche batch : elle a pour code ACCBATCH elle doit être lancée en permanence dans chaque dossier d'exploitation elle met à jour les écritures comptables créées depuis les autres modules (ventes, achats, stocks, gestion de production, immobilisations, comptabilité tiers, comptabilité générale) On ne peut lancer qu'une seule tâche comptable par dossier. Elle possède une fonction de surveillance particulière Remarques : Les écritures automatiques de la comptabilité sont également passées par cette tâche. Seules les écritures saisies directement (OD) sont enregistrées directement.

Fonctionnement de la tâche comptable
3.7 Le serveur batch Exploitation / Serveur batch / Tâche comptabilité Fonctionnement de la tâche comptable Pièces temporaires (en attente) Pièces finales Échéances (GACCDUDATE) Lignes analytiques (GACCTMPA) Lignes d’écriture (GACCENTRYD) En-tête de pièces (GACCENTRY) Balances (BALANCE, BALANA) Lettrages en attente (MTCBATCH) Lignes analytiques (GACCTMPA) Lignes d’écriture (GACCTMPD) En-tête de pièces (GACCTMP) Tâche batch comptable Facture Avoir Mvt. de stock Abonnement compta Interface comptable Remarques : Les écritures automatiques de la comptabilité sont également passées par cette tâche. Seules les écritures saisies directement (OD) sont enregistrées directement.

4. Administration 1- Généralités 2- Paramétrages de base

Définition d’un dossier
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers Définition d’un dossier Un dossier ADONIX X3 : stocke un référentiel (paramétrage, développement spécifiques) gère des données (statiques, mouvements) DOSSIER Règles Habilitations, signatures, législation comptable… Paramètres Structures de sociétés, paramètres généraux, dimensions… Dictionnaires Tables, écrans, objets, états… Dev. spécifiques Traitements, écrans spécifiques… Données Clients, comptes généraux, fournisseurs… Mouvements Factures, Commandes, Ecritures Remarques : La description externe des tables permet de les créer et de les modifier : à partir de cette description (gérée par ailleurs dans un dictionnaire), le moteur est capable de créer et de modifier la structure des tables (outil valfil).

Définition d’un dossier
4.1 Gestion des dossiers Définition d’un dossier Paramétrage / Paramètres généraux / Dossiers Au niveau technique, un dossier est composé : d’un user au niveau base de données, auquel sont rattachés : des tables stockant les paramètres et les données d’index, de séquences… d’un répertoire situé sur le serveur d’application contenant, dans des sous-répertoires : des descriptions d’écrans et de fenêtres la description externe des tables de la base du code exécutable par le moteur des états Crystal Reports Utilisateur final Remarques : La description externe des tables permet de les créer et de les modifier : à partir de cette description (gérée par ailleurs dans un dictionnaire), le moteur est capable de créer et de modifier la structure des tables (outil valfil). DEMO BPARTNER table Adonix.DEMO.BPARTNER Authentification SQL: Code user = "DEMO" Authentification X3: Code User X3 = "JEANDUPONT"

4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers Un dossier est créé en référence à un autre dossier qui : Existe sur le même serveur Contient tous les modules désirés Devient le dossier de référence pour le dossier créé Peut être X3 (par défaut) ARCHITECTURE À TROIS NIVEAUX X3 ARCHITECTURE À 2 NIVEAUX Héritage X3 Héritage Héritage TEST Dossier test/prototype TEST Dossier test/prototype FINAL Dossier d'exploitation Héritage Remarques : Deux architectures sont possibles : soit celle à deux niveaux, soit celle à trois niveaux. Celle à deux niveaux, plus facile à gérer, est recommandée dans la plupart des cas. L’architecture à 3 niveaux, plus complexe à maintenir, sert essentiellement lorsqu’on gère des développements spécifiques à plusieurs niveaux (spécifique, vertical) Il est à noter que les dossiers de référence sont définis par des variables système. adxmother(0) donne le nom du dossier de référence d’un dossier adxmother(1) donne le nom du dossier de niveau au-dessus. Dans le cas d’une architecture à deux niveaux, ces deux valeurs sont égales à X3. Dans le cas d’une architecture à trois niveaux, adxmother(0) est égal au nom du dossier de développement, et adxmother(1) est égal à X3. On retrouve l’affectation de ces variables, ainsi que d’autres, dans un fichier nommé APL.ini, qui se trouve sur le serveur d’application, dans le répertoire de base du dossier. FINAL Dossier d'exploitation Outils de copie - Patches

4.1 Gestion des dossiers Dossier et héritage TEST FINAL TEST FINAL
X3 Concrètement, l'héritage consiste en deux points : Lorsqu'un dossier est créé à partir d'un dossier mère, il hérite de certaines de ses données : Les dictionnaires, qui décrivent la structure des tables, des écrans et d'autres objets d'X3. Certaines données techniques (Menus locaux par exemple). Dans certains cas, lorsqu'un dossier ne trouve pas un élément dans ses propres répertoires, il les recherchera dans les répertoires de son dossier mère, et ainsi de suite. Ceci est vrai notamment pour les traitements standard, pour les états (fichiers Crystal Report™) et pour certaines tables que l'on trouve uniquement dans le dossier X3 (tables du serveur batch, par exemple). Ceci permet à tous les dossiers d'un environnement d'exhiber le même comportement standard, tout en ayant des modifications spécifiques appartenant à chacun d'entre eux individuellement. Il est par ailleurs possible, à la création d’un dossier, de reprendre des données issues d’un dossier de copie qui n’est pas son dossier mère. TEST FINAL X3 TEST Remarques : FINAL

Les dossiers standards
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers Les dossiers standards A l’installation, 3 dossiers sont livrés : X3 est le dossier de référence qui contient : la description de toutes les tables standard une partie seulement des tables (les tables stockant des paramètres) tout le code standard livré (programmes, écrans, fenêtres) un jeu de paramètres de référence relatif à une législation donnée certaines tables communes (notamment la table des dossiers) DEMO est un dossier de démonstration complet SERVX3 est un dossier technique qui gère le serveur batch Remarques : Dans le cas d’une architecture à deux niveaux, le dossier X3 est le dossier de référence. Dans le cas d’une architecture à trois niveaux, un dossier de développement s’intercale entre le dossier final et le dossier X3. Mais ce dossier de développement a lui même X3 comme dossier mère.

4.1 Gestion des dossiers La fiche dossier
Paramétrage / Paramètres généraux / Dossiers La fiche dossier Un dossier est d’abord décrit par une fiche dossier stockée dans le dossier X3 : Elle permet de définir les paramètres de base du dossier Sa validation va provoquer la création du dossier, c’est-à-dire : Créer les répertoires du dossier sur le serveur. Créer un user dans la base de données. Ajouter une ligne dans le fichier de configuration des dossiers (x3appli.ini). Transférer et valider le dictionnaire des objets à partir du dossier de référence. Copier certaines données de base à partir du dossier de copie. Sa revalidation va permettre de : Mettre à jour le dictionnaire des objets à partir du dossier de référence (en protégeant les éléments spécifiques). Revalider les dictionnaires (tables, écrans, objets…) Un changement de version passe par une revalidation des dossiers. Remarques :

La fiche dossier onglet Général
4.1 Gestion des dossiers La fiche dossier onglet Général Paramétrage / Paramètres généraux / Dossiers Caractéristiques générales : Base de données utilisée Taille de la base Codage (UNICODE) Caractéristiques propres à chaque base Dossier de référence Dossier utilisé pour les copies de données Dossier historisé (pour info) Date de début 1er exercice Modules utilisés Indicateurs Test et Spécifique Longueur des codes des tables diverses Remarques : Le volume fait référence à un répertoire racine où se trouvera l’arborescence du dossier. Un fichier adxvolumes permet de donner une liste de 1 à 8 volumes codés A à H (et 0 pour le volume où se trouve le fichier adxvolumes lui-même). Le fait d’avoir plusieurs volumes n’est plus guère utilisé, et en général, c’est A qui est donné ici. La taille de la base est utilisée uniquement lors de la création. Elle sera renseignée au vu du résultat de calcul de dimensionnement. Le codage de la base peut être ASCII (8 bits, c’est normalement le cas pour les langues européennes), UTF8 ou UCS2 (codages sur plusieurs octets). Avec SQL server, le seul codage Unicode possible est UCS2, avec Oracle, on a le choix. Le dossier de référence est soit X3, soit un dossier dépendant de X3 La date de début d’exercice est importante, car elle ne pourra plus être changée. Il est recommandé de tenir compte de la reprise des historiques pour la définir. L’indicateur Test permet de préciser s’il est possible d’installer des patches standard directement sur le dossier en qustion (on n’hérite alors plus de ceux qui se trouvent dans le dossier X3. Ceci ne doit pas être fait sur un dossier en exploitation. L’indicateur Dossier spécifique signifie que les traitements spécifiques présents dans un patch seront installés sur le dossier même s’ils n’existaient pas auparavant. Si cet indicateur n’est pas positionné, seuls les traitements spécifiques précédemment existants sont remplacés dans le dossier par une nouvelle version présente dans un patch. Cet indicateur sera normalement positionné dans le dossier intermédiaire d’une architecture à 3 niveaux. Mais il pourra aussi l’être sur un dossier dans une architecture à deux niveaux, dès lors que des développements spécifiques sont installés par patch dans le dossier lui-même. La longueur des codes associés aux tables diverses n’était pas paramétrable en version 130 (et valait toujours 3). Il peut maintenant être défini par ce paramètre. Le choix des modules possibles n’est pas indifférent. Les dépendances entre modules définies en début du cours sont bien entendu testées. Il est par ailleurs recommandé de positionner le module Développement à Oui même si aucun développement ne doit être fait sur le dossier, sinon on s’interdira l’accès à un certain nombre de fonctions de maintenance.

La fiche dossier et les codes activité
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers La fiche dossier et les codes activité Les codes activité sont des codes sur trois caractères, affectés à des éléments des dictionnaires X3 pour les activer, les désactiver ou les dimensionner. Les codes activité peuvent être de 4 types : Options classiques : Activation/Désactivation d'un élément du dictionnaire selon que le code soit actif ou inactif. Localisations : Même utilisation que les options, mais ces options sont spécifiques à une législation donnée. Ils commencent généralement par la lettre K. Dimensionnement : Ces codes possèdent une dimension et sont affectés à des champs ou à des tableaux (écrans dimensionnés) pour en définir les dimensions maximales. Spécifiques: Codes activité affectés aux éléments spécifiques pour les protéger. Ils doivent impérativement commencer par X, Y ou Z. Les codes activité d'un dossier donné sont stockés dans la table ADOSACT dans le dossier X3, et dans la table ACTIV dans le dossier même. À partir d'X3 : Dossiers / Dossiers. À partir du dossier fille : Développement / Dictionnaire données / Codes activité On retrouve, dans différents onglets de la fiche Dossier, des valeurs de code activité à renseigner. Remarques : Les lettres utilisées pour les législations sont à ce jour : U pour les USA F pour la France I pour l’Italie S pour l’Espagne P pour le Portugal G pour la Grande-Bretagne

La fiche dossier onglets Options
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers La fiche dossier onglets Options Il permet d’activer ou de désactiver des codes activité qui définissent des champs et fonctions optionnelles du progiciel : D’une part les options D’autre part les localisations. Remarques : De façon générale, tout changement de valeur d’un code activité suppose une revalidation de dossier pour être prise en compte (certaines exceptions peuvent être traitées par des utilitaires, mais ceci suppose d’avoir les connaissances requises en développement).

La fiche dossier onglet Ecrans
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers La fiche dossier onglet Ecrans Il permet d’activer ou de désactiver des codes activité qui définissent les dimensionnements d’écrans du progiciel : La plupart sont un nombre maximum de lignes dans un document Certaines structurent la base de données (nombre d’axes analytiques, de montants statistiques…) Remarques : Les codes activités qui structurent la base de données caractérisent des champs « dimensionnés » dans la table. Il s’agit de champs multiples, stockés de façon dénormalisée dans la base de données. Un champ nommé par exemple CCE et dimensionné à 9 par le biais d’un code activité CCE sera stocké dans une table sous la forme de neufs champs nommés CCE_0, CCE_1,… CCE_8. Les codes activités dimensionnant un nombre maximum de lignes dans un document permettent uniquement de définir des dimensionnements de tableaux de saisie en mémoire (chaque ligne de document correspond à une ligne dans une ou plusieurs tables). Les nombres minimum et maximum donnés ici doivent s’interpréter de la façon suivante : La valeur minimale est celle qui sera de toutes les façons gérée par la table. Il n’est pas interdit de descendre en dessous, car la dimension donnée structurera l’écran. Les dimensions supérieures à la dimension donnée, mais inférieures à la dimension de la taille, resteront stockées dans la base mais ne seront pas renseignées puisque non saisies. La raison de cette valeur minimale est liée à Crystal Reports. En effet, autant ADONIX sait gérer des champs optionnels dans la base, autant un état Crystal Reports référençant un champ inexistant dans la base ne pourra pas fonctionner. Les valeurs minimales ont ainsi été faites pour que les états livrés en standard fonctionnent quoi qu’il arrive. La valeur maximale est le maximum possible pour la dimension du champ. Lorsque valeur minimale et maximales sont identiques (ou non renseignées, ce qui signifie qu’aucune incidence n’existe sur la structure de la base), la dimension permet uniquement de faire varier le nombre de colonnes ou de lignes présentes à l’écran. Lorsque la dimension saisie est supérieure à la valeur minimale, c’est la dimension saisie qui est utilisée pour définir à la fois les champs de la table et les écrans.

La fiche dossier onglet Tables
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers La fiche dossier onglet Tables Les paramètres de dimensionnement permettent à X3 de calculer la taille de chaque table de la base de données et la taille physique globale. Les tailles individuelles des tables peuvent être modifiées à tout moment. La taille physique totale est définie à la création du dossier uniquement. Les paramètres de dimensionnement saisis dans la fiche dossier sont utilisés dans des formules de dimensionnement. Les paramètres et les formules sont modifiables dans le dictionnaire de données (en développement). Table GACCENTRYA [détail analytique] Taille de la table des entêtes de pièces comptables: On considère qu'il y a en moyenne : 2,5 lignes d'écritures par entête 1,5 lignes de détail analytique par ligne d’écriture. Taille de GACCENTRYA: arr(VOUCHER*1.5,100) = 1500 fiches. Remarques : Les paramètres de dimensionnement (Dictionnaire de données / Eléments de dimensionnement) définissent le nom des variables utilisées, et les formules de dimensionnement (Dictionnaire de données / Formules de dimensionnement) associent à chaque table une formule permettant de calculer un nombre de lignes prévisionnel. Table GACCENTRYD [lignes d’écritures] Taille de GACCENTRYD: VOUCHER = 1000 fiches. VOUCHER = 1000 Table GACCENTRY [en-tête de pièces] Taille de GACCENTRY: arr(VOUCHER/2.5, 100) = 400 fiches. Nombre d'écritures comptables à conserver

La fiche dossier onglet Tables
4.1 Gestion des dossiers La fiche dossier onglet Tables Paramétrage / Paramètres généraux / Dossiers On saisit dans cet onglet la valeur des variables (telles VOUCHER) : Ces variables sont utilisées pour dimensionner chaque table La fonction Options / Taille calcule alors la taille globale de la base Remarques : L’objectif de cet onglet est de permettre, lors de la création de la base de données, de savoir comment dimensionner (cf. premier onglet) les tablespaces ou des volumes de la base (ceci est fait lors de la création). Par ailleurs, chaque table du dossier ainsi créé est prédimensionnée en fonction de la taille calculée ici (ceci a une influence importante, notamment pour oracle, sur les dimensionnements d’extents, mais il est possible, après la création, de créer des fichiers de configuration associés à chaque table pour définir plus finement la façon dont la table est gérée. Il ne s’agit donc ici que de valeurs par défaut utilisées en l’absence de fichiers de configuration. Les tailles obtenues dépendent à la fois des valeurs associées aux codes activité et des valeurs données ici. Il est conseillé de tenir compte de l’historique que l’on souhaite avoir en ligne (hors dossier archivage) pour donner des valeurs aux dimensions. Les formules sont définies en développement.

La fiche dossier onglet Init
4.1 Gestion des dossiers La fiche dossier onglet Init Paramétrage / Paramètres généraux / Dossiers Cet onglet permet de paramétrer : Un transfert de données d’un dossier de copie vers le dossier à la première validation (ou au rajout d’un module dont dépendent les données copiées) Les langues dans lesquelles le dossier va être accessible en connexion La devise de reporting, commune à toutes les sociétés du dossier Des valeurs par défaut (langue, pays) Un forçage des validations de transaction Remarques : Les cases à cocher Mise à jour sont toujours forcées à Oui et ne peuvent pas être décochées sauf maintenance particulière. Les transactions sont validées si les écrans qui leur servent de base ont subi des modifications, mais on peut les forcer. L’ajout d’une langue est toujours possible, moyennant revalidation de dossier. A la génération, une partie des éléments techniques de la fenêtre sont validés en fonction de la langue (cette revalidation est moins lourde qu’en version 130).

La fiche dossier onglet Connexion
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers La fiche dossier onglet Connexion Ces informations correspondent à la boîte de connexion du client X3. À la validation (ou revalidation) du dossier, elles sont reportées dans le fichier x3appli.ini afin d'être éventuellement téléchargées sur les différents postes clients. Remarques : A compléter

La fiche dossier onglet Spécifiques
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers La fiche dossier onglet Spécifiques On définit ici les activations de paramètres spécifiques : Actif (Oui/Non) ou en dimension selon les cas L’indicateur Vertical signifie que le spécifique est défini dans un dossier intermédiaire et est remis à jour à chaque revalidation de dossier à partir du dossier de référence Remarques : Lorsque l’indicateur Vertical est égal à Non, on considère, à la revalidatoin de dossier, que tous les éléments marqués par ce code activité doivent être respectés et donc non modifiés.

La fiche dossier onglet Divers
4.1 Gestion des dossiers Paramétrage / Paramètres généraux / Dossiers La fiche dossier onglet Divers On définit ici des paramètres techniques dont les valeurs (sauf exception) ne doivent pas être modifiées : elles sont stockées dans le fichier apl.ini qui initialise certaines variables X3. à la validation (ou revalidation) du dossier, le fichier apl.ini est mis à jour avec ces valeurs. Remarques : Ce sont des éléments de développement.

4.1 Gestion des dossiers Gestion des dossiers
Paramétrage / Paramètres généraux / Dossiers Gestion des dossiers La revalidation d’un dossier permet de : Mettre à jour une version (les modifications du standard vont être appliquées, des traitements complémentaires de mise à jour automatiquement appliqués si nécessaire) Tranférer les développements verticaux d’un dossier de développement vers un dossier qui en dépend Il est important de tours vérifier la trace de dernière validation ! Dans une architecture à 3 niveaux, pour appliquer des évolutions standard : On revalide toujours le dossier intermédiaire d’abord Puis on remet à jour le dossier de plus bas niveau Remarques : Le fichier param.ini, stocké sur le serveur d’application dans le répertoire du dossier et mis à jour à chaque validation de dossier, permet de retrouver les paramètres du dossier en cas de transfert par l’option d’import. L’import d’un dossier permet de : Créer la fiche d’un dossier à partir d’une arborescence existante Normalement, ceci est fait après la restauration d’un dossier dans un environnement ouù il n’existait pas

4.2 Epuration et historisation
Exploitation / Historisation/Epuration Les fonctions d'épuration ou d’historisation traitent les données : De type mouvement uniquement (on n’épure ou on n’archive pas les clients ou les articles, mais les factures, les commandes, les écritures) Définies sous la forme de groupes de tables liées. Satisfaisant certaines conditions de cohérence (formules d'épuration) fournies en standard mais modifiables en spécifique. Ayant atteint ou dépassé une période de conservation prédéfinie (paramètres d'épuration et d’archivage). Les fonctions d’historisation : Supposent la création d’un dossier dans lequel les données archivées vont être stockées. Se définissent par groupe de tables. Remarques :

Création d’un dossier d’historisation
4.2 Epuration et historisation Développement / Utilitaires / Dossier / Création dossier historisé Création d’un dossier d’historisation Un dossier historisé est un dossier particulier, associé au dossier d’exploitation, qui se définit par : Un nom (HDOSSIER par défaut). Des paramètres de taille globale. Des paramètres base de données. Un coefficient exprimant la taille des tables historisées par rapport aux tailles des tables d’origine. Un profil menu, donnant accès à des fonctions de consultation, qui sera le profil par défaut quand on entrera dans ce dossier. Remarques : Il est en général intéressant de définir ce dossier historisé sur d’autres volumes disques, pour des raisons de performance. Il peut même être intéressant de l’installer sur un autre serveur, pourvu qu’ADONIX ait été installé sur le serveur en question. Il est à noter que la création d’un dossier historisé sur un autre serveur n’est pas automatisé, mais il est parfaitement possible, une fois que ce dossier est créé avec des tailles qui peuvent être minimales, de le déplacer sur un autre serveur. Pour que ceci fonctionne ensuite, il faudra : Modifier le paramètre HISDOS et y mettre le chemin d’accès au dossier avec la syntaxe Modifier le cas échéant le paramètre HISCOE (coefficient d’augmentation de tables) Il est à noter qu’à partir du moment où les tables d’un groupe sont déclarées historisées, le traitement dhistorisation va les créer, les dimensionnant en appliquant à la table d’origine le coefficient multiplicateur défini à la creation et stocké dans HISCOE. Ce paramètre ne sert donc que s’il n’y a pas encore eu d’historisation.

DOSSIER D’EXPLOITATION
4.2 Epuration et historisation Exploitation / Historisation/Epuration Principes de base L’historisation transfère définitivement les données archivables (ie. répondant aux critères) datées de plus de N1 jours ou mois dans le dossier archive L’épuration épure définitivement les données non archivables datées de plus de N’1 jours ou mois, et les données archivées datées de plus de N2 jours ou mois DOSSIER D’EXPLOITATION DOSSIER D’ARCHIVAGE Groupe de tables archivable archivage Remarques : Une sauvegarde est indispensable, car ces opérations sont irréversibles et l’épuration conduit à une suppression de données. Groupe de tables non archivable épuration

4.2 Epuration et historisation
Définition des règles Développement / Dictionnaire de données / Historisation/épuration Ces règles sont fournies en standard dans le progiciel, leur modification relève de développement spécifique. On associe à un code : Un groupe de tables liées Des formules qui doivent être vérifiées pour que l’épuration soit possible Des informations société/site, et date de référence Un traitement de contrôle standard, personnalisable par un traitement spécifique complémentaire ! Remarques : Dans cet exemple, la date de référence utilisée pour savoir quels contrats d’achat peuvent être épurés est la date ORDDAT (date d’origine du contrat). Ainsi, on épurera les contrats datés de plus de N jours. Pour autant, un contrat ne doit pas être épuré (même s’il est très ancien) s’il n’est pas encore arrivé à échéance. D’où la condition supplémentaire sur le champ ENDDAT.

Paramètres d’épuration / historisation
4.2 Epuration et historisation Paramétrage / Exploitation / Paramètres épurations Paramètres d’épuration / historisation On définit, pour chaque groupe de données : Si on épure et/ou si on historise La durée minimale (en jours) de conservation des données La fréquence de lancement pour le groupe (ie. le nombre minimum de jours à attendre depuis la dernière épuration ou historisation) La date de lancement de la dernière opération est affichée Remarques : Selon l’opération d’épuration ou d’historisation envisagée, les dates peuvent être ramenées à des périodes ou à des exercices.

Lancement de l’historisation/épuration
4.2 Epuration et historisation Exploitation /Historisation / épuration Lancement de l’historisation/épuration Cette fonction peut être lancée en direct et en batch (tâche AHISTO) Les paramètres à saisir sont : Le groupe de tables concerné L’opération désirée (historisation, épuration, ou les deux) Une sélection société Un flag simulation (seule une trace de ce qui serait traité est alors créée) Un flag détail (s’il est actif, la liste détaillé des clés des lignes purgées est écrite dans la trace) Remarques : Selon l’opération d’épuration ou d’historisation envisagée, les dates peuvent être ramenées à des périodes ou à des exercices. IL EST IMPORTANT DE FAIRE DES SAUVEGARDES AVANT DE LANCER CETTE FONCTION

Visualisation des données historisées
4.2 Epuration et historisation [ Connexion au dossier d’historisation ] Visualisation des données historisées La visualisation se fait en se connectant sur le dossier historisé Les données accessibles sont : Les données historisées sur les tables historisées (les données non historisées ne sont pas visibles) Les données présentes dans le dossier d’exploitation sur toutes les tables non historisées (par héritage) Connexion au dossier archive DOSSIER D’EXPLOITATION DOSSIER D’ARCHIVAGE accès direct Remarques : On ne sait par réunir les données archivées et les données d’exploitation; par contre, on peut utiliser, dans le dossier archive, potentiellement toutes les fonctions de gestion de X3, automatiquement bridées en consultation. Une contrainte existante est que les données archivées doivent avoir la même structure que les données en cours d’exploitation; ceci signifie que le passage d’un patch induisant des modifications de données provoque les modifications sur les tables du dossier archive. Enfin, les états standards Crystal Reports ne gèrent que les données issues d’un seul dossier. Il faut donc créer des états spécifiques si on désire éditer des données qui sont issues à la fois de tables présentes dans le dossier d’archive et le dossier courant. accès direct héritage héritage

4.3 Gestion de patches et de version
Gestion des versions Les versions sont numérotés sur 3 chiffres X.Y.Z : X = génération majeure (1 pour le moment) Y = version majeure (0,1,2,3,4) Z = sous-version Historique des versions à ce jour : 100 : version alpha, 12/1998 110 : première version officielle, 06/1999 120 : première version distribuée, 04/2000 (120 à 126) 130 : première version Web, 06/2001 (130 à 138) 140 : dernière version majeure, 09/2004 Remarques :

Passage d’une version à une autre
4.3 Gestion de patches et de version Passage d’une version à une autre Passage de version X.Y1 à X.Y2 : utilisation d’un support (CD) Mise à jour des clients (si nécessaire) Mise à jour du serveur X3 et des serveurs Web (si nécessaire) Revalidation de dossier obligatoire Pas de passage en réel sans test et validation préliminaire Passage de version X.Y.Z1 à X.Y.Z2 Soit par installation de CD et revalidation (comme ci-dessus) Soit par installation de patches consécutifs Remarques :

Développement / Utilitaires / Patch / … Passage de patches Un patch est un fichier d’archives : Numéroté à partir du début d’une version majeure (X.Y) de 1 à N Contenant une correction ou mise à jour « consistante » : code applicatif, description de structure de données, données, voire demande d’exécution d’un utilitaire… Installable par une fonction très simple d’administration Pour plus de facilité, les patches sont organisées en listes Numérotées à partir du début d’une version majeure (X.Y) de 1 à M Une version mineure correspond à une liste de patches donnée Ces dépendances sont visibles dans un fichier nommé X3PATCHXY0, livré avec toute liste de patches Remarques : Par consistante, on entend le fait que si une modification concomitante doit avoir lieu sun un écran, un traitement, et une table, les 3 éléments sont livrés dans le même fichier de patch.

Contenu du fichier X3PATCHV130.htm
4.3 Gestion de patches et de version Développement / Utilitaires / Patch / … Exemple de la version 130 Contenu du fichier X3PATCHV130.htm Remarques : Dans l’exemple ci-contre : Les listes de patches 1 à 2 permettent de passer en 131 Les listes de patches 3 à 7 permettent de passer en 132, et les actions complémentaires sont indiquées dans ce fichier HTML Les listes de patches 8 à 18 permettent de passer en 133 Les listes de patches 19 à 29 permettent de passer en 134 … La liste de patch 23 intègre les patches 1695 à 1780

Les limites du passage de patches
4.3 Gestion de patches et de version Développement / Utilitaires / Patch / Intégration de patch Les limites du passage de patches Les patches ne permettent pas de remettre à jour : Les données de paramétrage situées dans le dossier de référence X3 Le moteur installé sur le poste client (une procédure n’installant que une nouvelle version de moteur existe) Le moteur du serveur (même remarque) Le moteur du serveur Web (même remarque) L’aide en ligne (elle peut être installée indépendamment du reste) Les patches doivent être installés séquentiellement : Un patch suppose que les précédents aient été installés Mais il est possible d’installer une version intermédiaire quand on est très en amont du numéro de patch en cours Remarques : Les paramétrages étant par définition modifiables par l’utilisateur dans un dossier, il serait dangereux de les patcher… En version 140, on a fait une exception pour les pièces automatiques, qui ne sont patchables que dans X3, et transférables par copie vers les dossiers d’exploitation.

Les précautions à prendre
4.3 Gestion de patches et de version Développement / Utilitaires / Patch / Intégration de patch Les précautions à prendre Il est bon de lire attentivement le fichier X3PATCHVxxx Il précise les points particuliers (changement de structure pouvant nécessiter de la place disque, par exemple) Il est hautement recommandé d’être le seul connecté sur le dossier à patcher : C’est obligatoire si une table change de structure C’est préférable dans les autres cas (pour éviter une persistance de code en mémoire) Dans certains cas, on doit quitter la session avant de passer une autre liste de patches Si des spécifiques ont été réalisés, il est conseillé : D’utiliser le testeur de patches pour vérifier d’éventuels conflits De tester les spécifiques sur lesquels des conflits potentiels ont été détecter Remarques : Il est possible d’intégrer les listes de patch en batch (tâche PATCH)

Le testeur de patches Développement / Utilitaires / Patch /Test de patch Il permet de vérifier les conflits potentiels lors de l’installation de patches : Traitement standard ou état standard dupliqué dans un dossier patché et présent dans le patch Présence de spécifique sur un des éléments patchés (le programme signale ce qui a été protégé par un code activité spécifique) Il peut être utilisé pour l’installation d’une nouvelle version mineure : des fichiers List_nn.dat présents sur le répertoire X3Patch du CD d’une version permettent de réaliser le test sur les listes de patch équivalant au passage de version Remarques : Il est contraire à toutes les règles de bonne gestion de spécifiques de dupliquer un traitement standard dans un dossier, mais l’expérience montre que parfois certains développeurs cèdent à la facilité. Cet utilitaire permet de détecter ce type de situation. On obtient un fichier trace, dans lequel les messages rencontrés sont du type suivant : Erreurs dans le patch PX_1252_130 sur le dossier DEMO : Modification pour la DEB Le traitement FUNDEB.adx présent dans le dossier ne sera pas mis à jour par le patch Erreurs dans le patch TS_0001_130 sur le dossier DEMO : La consultation BAL protégé par le code activité ZDA ne sera pas mis à jour par le patch Le masque BPC0 protégé par le code activité ZDA ne sera pas mis à jour par le patch Masque BPC1 : Le bloc 2 protégé par le code activité ZDA ne sera pas mis à jour par le patch Masque BPC1 : Le champ (4,4) INVDTAAMT protégé par le code activité ZDA ne sera pas mis à jour par le patch Il est à noter que les fichiers List_nnn.dat ne contiennent pas réellement les patches, mais uniquement l’en-tête décrivant les objets présents dans la liste des patches. Leur intégration en réel par erreur ne provoque pas de problème.

Quels dossiers patcher ?
4.3 Gestion de patches et de version Développement / Utilitaires / Patch / Intégration de patch Quels dossiers patcher ? Un patch s’installe dossier par dossier : Lorsqu’on veut tester un patch, on peut l’installer sur un dossier de test dédié ( paramètre Dossier de test égal à Oui ) Lorsque l’installation est définitive, il doit être installé à la fois sur le dossier X3 et les dossiers d’exploitation On peut choisir d’intégrer un fichier unique ou l’ensemble des fichiers contenus dans un répertoire (c’est le cas d’une liste) En ne cochant pas la case Intégration de patch, on lit le contenu des fichiers de patch Remarques : Lorsqu’un répertoire est choisi, l’ensemble des fichiers d’extension .dat contenus dans le répertoire sont intégrés, dans l’ordre alphanumérique de classement des noms de fichiers. Pour maîtriser l’ordre d’intégration, les noms des fichiers de patch standards sont normalisés, sous la forme : PX_nnnn_XY0.dat, XY étant le numéro majeur de version (12,13,14), et nnnn un numéro séquentiel Liste des dossiers à patcher

Consultation de patches
4.3 Gestion de patches et de version Développement / Utilitaires / Patch / Consultation de patch Consultation de patches Cette fonction permet de voir les patches déjà passés sur un dossier donné : Clé (numérotation automatique) Nom complet du fichier Le préfixe PX est caractéristique des patches standards sur X3 Numéro de maintenance Utilisé, à préfixe égal, pour le contrôle de séquentialité Remarques : A l’intégration des patches standards, une vérification non bloquante est faite : on vérifie que le patch numéroté N-1 a été intégré avant d’accepter l’intégration du patch numéroté N. Ce contrôle est fait à type de patch donné (le type correspondant au premier caractère du fichier de patch, c’est-à-dire P dans le cas des patches standard). En effet, la règle de nommage des fichiers patches conseillée est : TT_nnnn_XY 0.dat, où TT sont deux caractères identifiant le type, nnnn un numéro séquentiel, XY0 est le numéro de la version. Les fichiers de patch spécifique ont intérêt à suivre ce type de normalisation, qui permet un contrôle strict de séquentialité de passage des patches, en utilisant d’autres lettre que PX (deux caractères commençant par X, Y, ou Z sont à la disposition des développeurs pour ce faire). Ainsi, on aura ce contrôle de séquentialité sur des patches spécifiques nommés par exemple XX_nnnn_XY0.dat Il est à noter qu’en début de version 130, on n’avait qu’un seul caractère (P en l’occurrence) pour nommer les patches. Par compatibilité, le nommage des patches avec un type sur 1 caractère a été gardé en version 130, mais en version 140, il vaut mieux passer à deux caractères. Numéro de liste de patch

Définition d’une session X3
4.4 Gestion des sessions Définition d’une session X3 Une connexion à ADONIX X3 provoque l’ouverture d’une session : identifiée de façon unique pour un serveur d’application donné d’un type donné Les types de connexion sont les suivants : Session primaire (connexion classique d’un utilisateur, depuis un poste en client-serveur ou en Web) Session secondaire ouverte à partir d’une session primaire : Par Fichier / Nouvelle session Par un raccourci clavier (Shift F5 à Shift F12, paramétrable par utilisateur) Remarques : La fonction adxuid(1) donne l’identificateur unique (pour un serveur d’application donné) La fonction adxuid(2) donne un identificateur unique pour une connexion à un dossier donné La fonction adxpid donne quant à elle le numéro de processus (au sens du système d’exploitation) du processus adonix en cours d’exécution. Dans un contexte multi-tiers, ce numéro de processus ne peut bien évidemment pas être garanti unique. La fonction adxtyp permet de connaître le type de connexion : 1 = connexion primaire client/serveur, 9 = connexion primaire web 2 = connexion secondaire client/serveur, 10 = connexion secondaire web 3 = session batch 4 = session ADAPI Note : La connexion Web technique qui définissait le nombre de serveurs Web connectables en 130, n’existe plus en 140. Une session secondaire possède les caractéristiques suivantes : elle est forcément ouverte sur le même dossier, et pour le même utilisateur elle est automatiquement fermée (avec une confirmation) si la session primaire dont elle dépend est elle-même fermée Session batch (déclenchée par le serveur batch) Session ADAPI (appel à une API ADONIX)

Contrôle des sessions X3
4.4 Gestion des sessions Développement / Utilitaires / Divers / Visu licence Contrôle des sessions X3 La licence définit le nombre maximum de sessions possibles par type : La licence est définie par le fichier serial_adonix installé dans le répertoire .serialisation sur le serveur d’application Elle définit aussi des limites fonctionnelles liées à la licence (cadre de droite) Remarques : Les deux textes caractérisent le client (zone Texte 1) et le partenaire ayant vendu et maintenant le client final (zone Texte distributeur)

Contrôle des sessions autorisées
4.4 Gestion des sessions Contrôle des sessions autorisées Il est possible de contrôler le nombre de sessions ouvertes : Pour un utilisateur donné, par les paramètres utilisateur MAXSES1 (nombre maxi de sessions primaires) et MAXSES2 (nombre maxi de sessions secondaires) Globalement, en passant un dossier en mode mono-utilisateur (personne d’autre ne peut alors se connecter) Pour un type de profil menu donné dans un dossier donné (paramètres USR1, USR2, USR3) Il est possible de provoquer une déconnexion automatique d’un utilisateur : En cas d’inactivité clavier/souris au bout de TIMEHGUP1 ou TIMHEHGUP3 secondes (valeur de paramètres utilisateurs pour sessions primaires / secondaires) Avec un avertissement et un délai de grâce de TIMEHGUP2 secondes (idem) Si ces paramètres sont nuls, il n’y a pas de déconnexion automatique Remarques : L’utilisateur ADMIN n’est jamais limité en nombre de connexions (par contre, le verrouillage mono-utilisateur lui est opposable).

Visualisation des sessions en cours
4.4 Gestion des sessions Développement / Utilitaires / Divers / Surveillance utilisateurs Visualisation des sessions en cours Remarques : Par défaut, quand on entre dans la fonction, c’est le serveur d’application courant qui est proposé, et si le service n’est pas donné, c’est le service courant qui est affiché. Dans l’écran ci-dessus, Ident1 et Ident 2 correspondent au résultat que donnerait adxuid(1) et adxuid(2) lancés dans la session correspondante, Fonction est le nom de la fonction exécutée (cette valeur est vide si l’utilisateur se trouve au niveau du menu). Pour la ligne courante, la colonne numéro de processus correspond au numéro donné par le système d’exploitation sur le serveur (ou le poste client). On remarquera ainsi : Que le processus adonix correspond à l’exécution du code applicatif. Il est exécuté sur un serveur de traitement Que le processus sadora correspond à la connexion à la base de données (oracle ici). Il est aussi exécuté sur le serveur de traitement Queles processus sadfsq, qui correspondent à l’accès à des fichiers, peuvent être présents sur plusieurs serveurs (y compris sur le poste client, par exemple si on écrit un fichier en local). Pour avoir le droit d’interrompre un processus, il faut soit avoir les droits d’un super-utilisateur au niveau du système d’exploitation (ie. être connecté comme root sous Unix, comme administrateur sous Windows), soit être connecté sous la même identité que le propriétaire des processus. Par ailleurs, une habilitation définie au niveau de l’accès de cette fonction est aussi nécessaire. Cette fonction permet de : Visualiser les connexions en cours (tableau supérieur) sur un serveur d’application et un service donné (machine:service) Visualiser les processus correspondants et les interrompre si on est habilité

Des utilitaires divers sont fournis :
Développement / Utilitaires / … Des utilitaires divers sont fournis : ! Ils font pour la plupart partie du développement Ils peuvent avoir des incidences sur la cohérence de la base ou du dossier Ils sont donc à manipuler avec précaution : Maintenance (mode fiche, maintenance en colonne, transactions système) Vérifications (Infos version, Vérif cohérence, Symboles et traitements verrouillés) Utilitaires dictionnaire (copies, génération et validations, comparaisons) Remise à zéro dossier Gestion mono/multi, déverrouillage Recherches Extraction / Intégration Optimisations de la base (Etat des tables, Recherche index, Analyse mémos, Optimisation base de données) Remarques :

4.5 Utilitaires Maintenance :
Développement / Utilitaires / … Maintenance : Ces outils permettent d'accéder aux données contenues dans la base X3 : sans aucune forme de contrôle Maintenance en lignes : Accès aux enregistrements d'une table un par un. Maintenance en colonnes : Accès aux enregistrements sous forme de tableaux. Transaction système : Mise à jour massive des données d’une table ces fonctions sont des outils dangereux qui ne doivent être réservés qu'à l'installateur du logiciel ! Remarques : Une trace des champs modifiés par les maintenances en ligne, en colonne la trace des transactions sytème lancées est gardée dans le fichier espion.tra. Ce fichier contient également d’autres lignes numérotées afin de permettre la vérification de son intégrité. En cas de gros problème, il est recommandé de le tenir à la disposition de la hot-line, qui pourra, par son analyse, mieux comprendre ce qui a pu se passer sur un dossier. Dans le cas d’une transaction système, on retrouvera dans cette trace : Un numéro séquentiel, le code utilisateur, la date et l’heure, le code transaction, le nombre d’enregistrements touchés, le détail des formules de sélection et des formules de modification. Dans le cas d’une modification par maintenance, on retrouvera dans cette trace : un numéro séquentiel, le code utilisateur, la date et l’heure, la table concernée, la clé, la nature de l’opération (Création/Modif/Suppression…) et, en cas de modification, une ligne par champ modifié, avec la valeur avant et après modif.

Les écrans de maintenance
4.5 Utilitaires Développement / Utilitaires / Maintenance Les écrans de maintenance Remarques :

Les écrans de maintenance en colonnes
4.5 Utilitaires Développement / Utilitaires / Maintenance en colonnes Les écrans de maintenance en colonnes Remarques :

Transactions système : définition
4.5 Utilitaires Développement / Dictionnaire traitements / Transactions système Transactions système : définition Les transactions système sont utilisées pour effectuer des mises à jour en masse de la base de données (création, modification ou suppression de lignes), à partir d'une transaction définie dans le dictionnaire des traitements. Paramètres à saisir au lancement : Intitulé Type de données Valeur par défaut Table de contrôle Remarques : Les règles de cohérence liées à l’applicatif ne sont pas contrôlées (c’est un outil de maintenance). Des manipulatoions faites par quelqu’un de non averti peuvent donc être dramatiques. A l’inverse, des transactions système bien paramétrées agissant sur des champs non stratégiques ou mettant à jour les données en respectant les contraintes applicatives peuvent être mises entre les mains de certains utilisateurs (uniquement en exécution). Tables liées et clé de lien Table principale mise à jour Formules de sélection Pouvant faire appel aux valeurs de paramètres (V1,V2,V3…) Description des mises à jour (Création, mise à jour de champs, suppression)

Transactions système : utilisation
4.5 Utilitaires Développement / Utilitaires / Divers / Transactions système Transactions système : utilisation Code transaction à exécuter En mode test, on peut définir le nombre de transactions à simuler Remarques : Le mode test va exécuter les requêtes en mode lecture (sans création, ni mise à jour, ni suppression), en produisant une trace détaillée, ce qui permet de vérifier ce qui va être fait lors de l’exécution. Comme la trace peut être volumineuse, on peut limiter le nombre de transactions simulées. L’accès en exécution d’une transaction système peut être contrôlée par un code d’accès. A la définition des profils menus, on peut aussi imposer une transaction système (paramètre de la fonction AMIEXE), mais ceci ne dispense pas de protéger les autres transactions système par un code d’accès. Valeurs de paramètres à utiliser

4.5 Utilitaires Infos version :
Développement / Utilitaires / Vérification … Infos version : Cette fonction donne les numéros de version : du moteur sur le serveur du superviseur de l’applicatif La version du client est obtenue à partir du menu principal du poste client : Remarques : Ce type d’informations peuvent être demandées par la hot-line, ainsi que le niveau exact de patch

Verification de cohérence :
4.5 Utilitaires Développement / Utilitaires / Vérifications / Vérif cohérence Verification de cohérence : Cet utilitaire parcourt toutes les tables du dictionnaire et vérifie l'intégrité référentielle des liens (existence des enregistrements liés pour chaque ligne de la table). La description de la base est parfois imparfaite, ce qui peut provoquer de fausses erreurs. L'exécution de cet utilitaire peut être très longue : il est conseillé d'utiliser les bornes de tables et/ou de limiter par module. Remarques : Cet utilitaire est en général lancé de façon très ciblée, par exemple après une opération de maintenance

Symboles et traitements verrouillés :
4.5 Utilitaires Développement / Utilitaires / … Symboles et traitements verrouillés : X3 utilise des verrous applicatifs : Pour des opérations longues hors transaction Utilisés par les objets est en modification de fiche (temps de saisie important) Erreur et symbole de verrouillage : Stockés dans la table APLLCK A ne pas confondre avec le verrouillage induit par des transactions, géré par la base de données (row level locking), durée limitée par le temps de la transaction (aucun temps d’attente utilisateur) X3 utilise des verrous fichiers (TRAITEMENT.LCKsrc): Pour verrouiller des fichiers en cours d’édition (développement) Remarques : Le message d’erreur en gestion d’objet se produit lorsqu’une fiche déjà en cours de modification par ailleurs est modifiée par un autre utilisateur. La clé apparaît alors en bas de l’écran. Un double clic sur la clé affiche le détail (utilisateur et poste). Les symboles applicatifs sont gérés par les instructions Lock et Unlock. La table APLLCK contient les informations suivantes : Un symbole qui est défini par la concaténation du code objet et de la clé Un indice qui vaut toujours 0 Un numéro qui identifie la session (c’est la valeur de adxuid(2) pour la session qui verrouille le symbole). Le message d’erreur en gestion de traitements apparaît lorsqu’on saisit un nom de traitement qui est déjà en cours de modification. Le traitement est quand même affiché, le symbole de verrouillage étant affiché en haut du texte.

Symboles verrouillés :
4.5 Utilitaires Développement / Utilitaires / Vérifications / Symboles verrouillés Symboles verrouillés : Développement / Utilitaires / Vérifications / Traitements verrouillés Un zoom est possible de cette fonction vers la gestion des sessions Traitements verrouillés : Une suppression du verrou est possible (par clic droit) Remarques : En gestion d’objet, le symbole verrouillé correspond au code de l’objet, suivi de la clé courante (dans l’exemple ci-dessus, le tiers (BPR) 001 est verrouillé, la réception fournisseur (PTH) GAL …)

Utilitaires dictionnaire :
Développement / Utilitaires / Dictionnaire / Validation Développement / Utilitaires / Dictionnaire / Copie dictionnaire Utilitaires dictionnaire : Ces outils permettent de réaliser les opérations suivantes : Validation d'objets Remarques : La validation du dictionnaire permet de s’assurer que les éléments techniques issus des différentes génération de code sont en phase avec le dictionnaire. C’est un utilitaire moins lourd en exécution qu’une revalidation de dossier, et il peut surtout être plus sélectif. Par exemple, si un type de données a été modifié, on peut s’assurer que tous les écrans, fenêtres, tables l’utilisant vont être remis à jour. La validation forcée duplique temporairement les tables et les recopie avant de les renommer, en appliquant les règles de dimensionnement définies soit par défaut, soit dans le fichier de configuration. La copie permet le transfert des dictionnaires d’un dossier à l’autre. Par défaut, le dossier d’origine proposé est le dossier courant. Elle peut être limitée aux éléments marqués par un code activité, ou aux éléments modifiés depuis une date donnée. C’est une des façons (avec l’outil de patch) de transférer des éléments résultant d’un développement d’un dossier à l’autre, mais ceci suppose que l’un soit accessible à partir de l’autre : la syntaxe permet d’accéder à un dossier situé sur un autre serveur, accessible par un autre numéro de service. La phase de validation (ie. de génération de code) peut être enchaînée à la copie. Copie d'éléments d'un dossier vers un autre

Utilitaires dictionnaire (suite) :
Développement / Utilitaires / Dictionnaire / Différence d’objets Utilitaires dictionnaire (suite) : Ces outils permettent de réaliser les opérations suivantes : Comparaison d’objets générant une trace plus ou moins détaillée Remarques :

Développement / Utilitaires / Dictionnaire / Génération de transactions Développement / Utilitaires / Dictionnaire / Copie de transactions Utilitaires dictionnaire (suite) : Ces outils permettent de réaliser les opérations suivantes : Génération du code associé aux transactions applicatives paramétrables Remarques : La copie de et la génération de transactions sont de nouveaux utilitaires en 140, qui sont rendus possibles par le fait qu’un dictionnaire des transactions existe désormais dans ADONIX X3. Copie de transactions applicatives paramétrables vers un autre dossier

Développement / Utilitaires / Dictionnaire / Validation des fonctions Développement / Utilitaires / Dictionnaire / MAJ menus locaux Développement / Utilitaires / Dictionnaire / Copie de traitements Utilitaires dictionnaire (suite) : Ces outils permettent de réaliser les opérations suivantes : Validation des fonctions : permet de mettre à jour la table croisée d'habilitation sites / fonctions / profils. Mise à jour des menus locaux : Permet d'exporter les fichiers de menus locaux dans les répertoires de publication (client/serveur et web). Copie de traitement : transfère un traitement (et sa description dans le dictionnaire des traitements) d’un dossier à l’autre Remarques : L’utilitaire de mise à jour des menus locaux réalise les opérations suivantes, pour chaque langue : Dans le répertoire de publication des menus locaux (X3_PUB/DOSSIER/GEN/LAN/MENL, il réécrit les fichiers Mnnnn.xml des menus locaux modifiés Il met à jour les tables d’horodatage pour forcer la revalidation des écrans Web où le menu est utilisé lors de leur prochaine utilisation Il met à jour les fichiers menulan qui servent à l’interface client/serveur et à l’impression via Crystal Reports. Il est automatiquement lancé lorsqu’un utilisateur modifie un menu local et sort de la fonction de gestion des menus locaux. Mais si on veut enchaîner un ensemble de modifications et ne pas perdre de temps à réaliser cette génération à un moment donné, l’utilitaire de mise à jour permet de délencher cette opération après coup.

Utilitaires dossiers :
Développement / Utilitaires / Dossiers / Changement de dossier Développement / Utilitaires / Dossiers / Remise à zéro dossier Changement de dossier : permet une reconnexion sur un autre dossier Remise à zéro dossier Cet utilitaire remet à zéro les mouvements dans la base de données, sans remettre à zéro les données permanentes. Attention, utilitaire irréversible ! Les mouvements sont identifiés dans le dictionnaire : Une table marquée Raz est vidée Un champ marqué Raz reçoit une valeur nulle Les compteurs marqués Raz sont remis à zéro Utile en cas de démarrage réel après un démarrage test, par exemple Remarques : L‘écran de saisie de dossier est proposé dans le cas des 2 utilitaires, mais une confirmation est demandée avant remise à zéro effective.

Utilitaires dossiers (suite) :
Développement / Utilitaires / Dossiers / Déverrou dossier Développement / Utilitaires / Dossiers / Import dossier Développement / Utilitaires / Dossiers / Mode mono Développement / Utilitaires / Dossiers / Mode multi Déverrou dossier : supprime le verrou empêchant la connexion à un dossier lors de sa revalidation de dossier (ce verrou peut rester en place en cas d’arrêt brutal lors d’une revalidation) Import dossier : crée la fiche Dossier à partir d’un fichier se trouvant dans le répertoire du dossier (utile en cas de transport d’un dossier d’un serveur à un autre, correspond à l’item de menu Option / Importer en gestion de dossier) Passage en mode mono : Cet utilitaire met le dossier dans un mode où : Un seul utilisateur peut être connecté à la fois Cet utilisateur a forcément le profil fonction de l’administrateur Passage en mode multi : sortie du mode mono-utilisateur Remarques : Si la connexion est impossible sur un dossier donné, le message affiché étant Dossier en cours de validation, et si la validation n’est plus en cours, il est conseillé d’aller d’abord voir la trace de validation, accessible en gestion de dossier, et, si la trace laisse entrevoir que le dossier devrait être utilisable, de déverrouiller le dossier pour y entrer et faire des vérifications. Il faudra, sur un dossier d’exploitation, revenir dans une situation normale où le dossier est correctement revalidé .

Utilitaires de recherche :
Développement / Utilitaires / Recherche Utilitaires de recherche : Ces utilitaires permettent de rechercher des éléments de développement dans les dictionnaires d’ADONIX X3 : Codes activité (dans les tables, écrans, fenêtres, objets… qui composent un dossier) Types de données (dans les écrans, tables…) Codes d’accès (dans les écrans et les autres tables) Messages (dans la base de données des messages traduisibles) Textes (Références croisées de l’utilisation des textes dans les éléments du dictionnaire) Remarques : Ce sont des outils plutôt orientés développeurs

Utilitaires de sauvegarde :
Développement / Utilitaires / Sauvegarde / … Utilitaires de sauvegarde : Ces utilitaires permettent d’extraire ou d’intégrer des données : A partir ou vers des fichiers (4 à 6 par table) ayant un format « à plat » Sous un format indépendant de la base de données Sous un format indépendant du système d’exploitation Transportables par simple copie Ce ne sont pas des outils normaux d’exploitation : Ils font des extractions table par table sans garantir de cohérence globale si des modifications ont été faites entre temps, la base devant rester active Ils n’ont pas les performances des procédures de sauvegarde fournies avec les bases de données Ils sont par contre utilisables en maintenance : Notamment pour transférer des donnée d’une base à une autre Mais aussi pour transmettre des données à la hot-line ADONIX Remarques : Aucune garantie n’est apportée si ces outils sont utilisés comme des outils de sauvegarde lors de l’exploitation (ils n’ont pas été conçus pour cela). Par exemple, si les différents fichiers relatifs à une table ne sont pas en phase, la réintégration peut produire à des pertes de données totales.

Utilitaires de sauvegarde :
Développement / Utilitaires / Extraction / Intégration Utilitaires de sauvegarde : Chaque table est extraite ou intégrée à partir de 4 à 6 fichiers : TABLE.srf : description ascii de la structure de la table TABLE.fde : description « compilée » de la structure de la table TABLE.dat : données de la table rangées « à plat » TABLE.seq : valeur de séquence rattachée à la table TABLE.blb : données de type blobs ou clobs (images, textes) stockés dans la table (s’il y en a) TABLE.cfg : configuration de la table dans la base de données si elle existe L’extraction ou l’intégration se fait dans ou depuis un répertoire : du serveur d’application qui doit forcément être sur le même volume que le répertoire du dossier qui est par défaut le répertoire SVG Remarques : La limite concernant le volume est une limite technique de l’outil d’extraction (qui s’appelle valfil et qui pilote par ailleurs les changements de structure des tables : cet exécutable livré avec le moteur d’exécution adonix est appelé de façon transparente par X3). Le fichier d’extension cfg est optionnel; il contient des directives liées à la base de données, et est aussi stocké (s’il existe) dans le répertoire FIL du dossier : Sous oracle, ce peuvent être des directives de dimensionnement d’extents ou de répartition sur différents tablespaces (partitionnement d’une table par exemple) Sous SQL serveur, ce peuvent être des directives de définition du volume, utiles lorsque lorsque différents volumes sont utilisés. Ces directives sont transmises à la base qui les respecte strictement lors de l’intégration, ainsi qu’à chaque revalidation de table. Elles permettent d’utiliser des configurations différentes de celles proposées par défaut. Si on extrait le fichier d’extension cfg, et si on le transfère avec les autres fichiers dans l’environnement d’intégration, les mêmes directives vont également s’appliquer dans l’environnement en question. Si on veut ne pas en tenir compte, il suffit de ne pas transférer ce fichier dans l’environnement d’intégration. Le fait qu’il ne soit pas présent signifie que les règles de dimensionnement par défaut vont s’appliquer. Ces règles s’appuient simplement sur la taille d’une ligne de la base et le nombre de lignes prévues dans la table. Une information de taille de table, calculée à partir de ces éléments, est présente dans le fichier .srf et dans son équivalent compilé d’extension .fde.

Utilitaire d’extraction de données :
4.5 Utilitaires Développement / Utilitaires / Extraction / Intégration Utilitaire d’extraction de données : Paramètres d’extraction : Dossier, table(s) à exporter (sous la forme de modèle de nom), et répertoire de sauvegarde Indicateurs : Copie du fichier .cfg (Oui/Non) Taille réelle dans srf Ce dernier indicateur permet : de stocker dans les fichiers .fde et .srf la taille réelle de la table au moment de l’extraction (pas sa taille prévue) de remonter les données dans un environnement dimensionné au plus juste Remarques : Les deux indicateurs ne sont pas incompatibles, mais les directives données dans le fichier de configuration, si elles contredisent la taille données dans le fichier .srf, s’appliqueront prioritairement si le fichier .cfg est effectivement présent à l’intégration. Si un dossier doit être envoyé à la hot-line ADONIX pour analyse approfondie, on utilisera l’outil d’extraction de données en le lançant sur toutes les tables de la base (*), puis en sauvegardant l’ensemble du répertoire du dossier sur bande ou sur CD-ROM. Il est dans ce cas impératif de cocher l’indicateur Taille réelle dans srf afin de pouvoir remonter le dossier dans une base de donnée de taille raisonnable. Pour autant, on peut quand même extraire les fichiers .cfg (leur examen peut permettre d’analyser des problèmes de performance).

Utilitaire d’intégration de données :
4.5 Utilitaires Développement / Utilitaires / Extraction / Intégration Utilitaire d’intégration de données : Paramètres d’extraction : Dossier, table(s) à exporter (sous la forme de modèle de nom), et répertoire de sauvegarde, et deux indicateurs Indicateur Fichiers de config d’origine Permet d’ignorer le fichier .cfg présent dans le répertoire de sauvegarde Utile par exemple pour remonter dans un environnement d’exploitation correctement dimensionné des données issues d’un environnement de test et de reprise Indicateur Taille d’origine Permet d’ignorer la taille présente dans le fichier .srf au profit de celle de la table d’origine (si elle existait avant intégration) Remarques :

Utilitaires d’optimisation de base :
ADONIX X3 crée automatiquement la base de données en : Dimensionnant les tables à partir d’une taille prévue à l’origine Tenant compte de fichiers de configuration Créant les index nécessaires à un fonctionnement normal Mais, dans le temps, les performances peuvent être affectées : Par une évolution de la volumétrie différente de ce qui était prévu Par l’utilisation de sélections mémorisées sur des tables importantes Par la mise en place de filtres rôle sur des tables importantes Par des incidents d’exploitation (non création d’un index standard) Des outils de diagnostic et de paramétrage vont permettre d’y remédier Remarques : Ces outils sont des outils d’aide au diagnostic en cas de problème de performance; ils doivent être utilisés en liaison avec un administrateur de base de données, qui saura proposer les remèdes les plus appropriés.

4.5 Utilitaires Etat des tables :
Développement / Utilitaires / Vérifications / Etat des tables Etat des tables : Cet outil permet de vérifier les caractéristiques de chaque table de la base Permet de constater si des tables ont été mal dimensionnées Remarques : Il est utile de lancer cet utilitaire de temps en temps pour vérifier l’état de la base, tout particulièrement si des variations de volumétrie importantes ont été faites sur la base, ou si les temps de réponse ont subi des variations à la baisse. On retrouve les tables pouvant poser des problèmes en couleur dans l’écran ci-dessous : En rouge  nombre de lignes réel de la table supérieur à 3 fois le nombre prévu à l’origine En vert  nombre de lignes réel de la table inférieur ou égal à 3 fois la taille prévue, mais plus de 30 extents sur les données ou sur les index (oracle). Il est ensuite du ressort de l’administrateur de base de prendre les mesures nécessaires (redimensionnement de la table, extension de tablespaces, mise en place de fichiers de configuration pour certaines tables…)

4.5 Utilitaires Recherche des index :
Développement / Utilitaires / Vérifications / Recherche index Recherche des index : Le dictionnaire des tables décrit des index dont ADONIX X3 se sert fréquemment : Ils définissent des ordres de recherche et des critères de sélection privilégiés Ils sont utilisés par les programmes standard A l’exécution des requêtes : La base reçoit les critères de sélection et de tri Elle se sert des index s’ils existent réellement Mais est tout de même capable de répondre à la requête si les index n’existent pas… au détriment de la charge machine et des temps de réponse… Il arrive que des index soient déclarés, mais non créés : Si une revalidation de la table n’a pas été faite Si un incident (pas assez de place sur un tablespace) empêche leur création Cet utilitaire permet de vérifier si les index sont bien présents Remarques : Cet utilitaire est l’un des premiers à lancer en cas de dégradation brutale et importante des performances de la base, particulièrement à la suite de passage de patches ayant changé la structure d’une table, ou après revalidation de dossier. En effet, si les traces d’erreur n’ont pas été soigneusement vérifiées, il est possible qu’un message d’erreur non bloquant de type Création d’index impossible n’ait pas été relevé. Le résultat de cette trace donne non seulement les index définis dans le dictionnaire, mais non présents sur la base, mais aussi les index présents sur la base non décrits dans le dictionnaire (notamment les index d’optimisation utilisés), et les index définis selon une norme différente de celle utilisée par le moteur ADONIX X3. Ces deux dernières catégories ne posent pas de problème de performance. Ci dessous un exemple de trace : Liste des index du dictionnaire non existants sous Oracle ******************************************************************************** Table Index Description détaillée de l'index FUP FUP TYP+NUM+LIG GCOMMIT CMM NUMREF+TYPREF Index Oracle non décrits dans le dictionnaire Table Oracle Index ITMMASTER SPE_IT1 ITMMASTER SPE_IT2 ITMMASTER SPE_IT3 Index Oracle non conformes aux normes adonix ABLOB SYS_IL C000 ACLOB SYS_IL C000 SYSBLB SYS_IL C000 SYSCLB SYS_IL C000

4.5 Utilitaires Analyse des mémos :
Développement / Utilitaires / Vérifications / Analyse mémos Analyse des mémos : En gestion d’objet, il est possible de créer des sélections mémorisées : Sur des tables importantes Portant sur des champs non indexés Parfois partagée par un ensemble d’utilisateurs A l’exécution les requêtes liées sont : Lourdes (pas d’index, table importante) Fréquente (à chaque affichage ou rafraîchissement de liste gauche, d’autant plus fréquente si le mémo est partagé et/ou standard) L’outil d’analyse de mémos va donner une liste des problèmes rencontrés On peut agir en amont : Le paramètre SELWARN définit un nombre de lignes limite dans une table. Au dessus de ce nombre de lignes, l’enregistrement d’une sélection non performante est refusé ou provoque un avertissement selon la valeur du paramètre AUZMEMO Remarques : Si AUZMEMO vaut Oui, il y a juste un avertissement. Il est à noter qu’un utilisateur ayant le profil de l’administrateur ne se verra pas interdire une sélection, mais recevra un message d’avertissement. Sont considérées comme posant potentiellement des problèmes de performance les sélections suivantes : Celles pour lesquelles aucun champ n’est présent en première partie d’un index Celles qui font intervenir plusieurs tables liées Celles qui intègrent des opérateurs ou Celles qui intègrent des expressions Les paramètres de taille permettent de classer les problèmes potentiel dans un ordre de gravité décroissant. Dans l’exemple donné dans l’écran ci-essus, au dessus de lignes dans une table, un problème est considéré comme critique, en dessous de lignes aucun avertissement n’est donné, entre et le problème est considéré comme un problème de performance réel, entre et il est considéré comme mineur. Un exemple de trace créée par cet utilitaire : Nombre de mémos trouvés dans le dossier : 24 --- Dont globaux : 5 --- Dont locaux : 19 --- Dont standards : 0 Options de test : --- Avertissement [WARN] si plus de 5000 lignes dans la table --- Problème de performance [PERF] si plus de lignes dans la table --- Problème critique [CRIT] si plus de lignes dans la table Liste des problèmes trouvés 001 Mémo local ADMIN.BERTIER sur table BPCUSTOMER(Clients) : *** WARN ( 5200 ) *** Pas d'index adapté au filtre sur le champ REP Problème de performance 002 Mémo global ADMIN.MONDE sur table BPCUSTOMER(Clients) : *** WARN ( 5200 ) *** Opérateur "Différent" sur champ CRY *** WARN ( 5200 ) *** Plusieurs tables dans le mémo, vérifier la requête *** WARN ( 5200 ) *** Pas d'index adapté au filtre sur le champ CRY 003 Mémo local ADMIN.PAR sur table ITMFACILIT(Articles - Sites) : *** PERF ( ) *** La clé de tri de la liste gauche ("ITF0") est différente de la clé de filtrage

Optimisation base de données :
4.5 Utilitaires Paramétrage / Exploitation / Optimisation base de données Optimisation base de données : Des filtrages de données peuvent être définis par paramétrage sur des tables importantes : Par des sélections mémorisées Par des filtres Par l’utilisation de codes d’accès Les requêtes liées peuvent être d’autant plus lourdes : Qu’elles sont fréquemment lancées Qu’aucun index standard n’est adapté pour leur optimisation On peut alors créer des index supplémentaires dans la base : Activables ou désactivables à la demande Sur des champs indicés (ce qui est impossible dans le standard) Remarques : Le mieux étant l’ennemi du bien, il faut créer ce type d’index avec mesure, et de préférence après avoir pris l’avis d’un administrateur de base de données.

Optimisation base de données :
4.5 Utilitaires Paramétrage / Exploitation / Optimisation base de données Optimisation base de données : Des index d’optimisation standard sont livrés : Liés aux filtres par rôles Sur certaines consultations (en fonctions des axes analytiques souvent utilisés) Pour optimiser certaines opérations (suppressions, épurations…) Règle de nommage : SPE_* On peut en créer autant que nécessaire Remarques : Les index d’optimisation standard sont livrés lorsque des cas de paramétrage connus mais peu fréquents peuvent poser des problèmes de performances (un index standard pour tous serait trop pénalisant). Il s’agit bel et bien de paramétrage (pérenne). Ceci signifie que de nouveaux index d’optimisation ne sont livrés, au cours des versions, que dans le dossier de référence (et en aucun cas par voie de patch). Le fait d’activer un index de ce type ne suffit pas. Il faut : Soit utiliser le bouton Exécuter Soit revalider les tables sur lesquelles un tel index a été mis en place (ou supprimé).

5. Introduction au développement
1- Généralités 1.1 Définition du superviseur 1.2 Rappels sur l’architecture technique 1.3 Organisation des fonctions 1.4 Paramétrage et développement 1.5 Sociétés et sites 2- Paramétrages de base 2.1 Introduction aux formules Adonix 2.2 Paramètres de base 2.3 Workflow 2.4 Paramétrages des fonctions 3- Exploitation 3.1 Imports et exports 3.2 Gestion des états 3.3 Destinations d’impression 3.4 Portail utilisateur 3.5 Gestion des styles 3.6 Personnalisation du vocabulaire 3.7 Le serveur batch 4- Administration 4.1 Gestion des dossiers 4.2 Epuration et historisation 4.3 Gestion de patches et de version 4.4 Gestion des sessions 4.5 Utilitaires 5- Introduction au développement 5.1 Pérennisation et codes activités 5.2 Tables et index 5.3 Types de données : menus locaux, tables diverses 5.4 Ecrans et fenêtres 5.5 Nouveaux paramètres 5.6 Fonctionnement de base d’un objet

Codes activité : rappels
5.1 Pérennisation et codes activité Développement / Dictionnaire données / Codes activité Codes activité : rappels Un code activité est un code sur 3 caractères : Défini dans un dictionnaire Permettant de rendre optionnel des éléments du logiciel Permettant de signer un spécifique, s’il commence par X,Y,ou Z. Tout développement spécifique doit être marqué par un code activité : Sinon, il sera perdu lors d’une revalidation de dossier Mais il doit être marqué au niveau le plus fin possible Champ dans un écran plutôt que Bloc ou Ecran lui-même Champ ou Index dans une table plutôt que Table elle-même Certains cas particuliers ne nécessitent pas de code activité : Action SPE ou SPX dans un écran standard Code action commençant par X, Y ou Z Remarques : Si on modifie un champ du standard qui était déjà marqué par un code activité, il faut lui affecter un code activité commençant par X,Y ou Z tout de même (sinon, il sera remis à jour au moment de la revalidation de dossier). On peut rendre ce code activité spécifique dépendant du code activité standard si on veut s’assurer que les deux évoluent de façon synchrone.

Le dictionnaire des tables
5.2 Tables et index Le dictionnaire des tables Développement / Dictionnaire données / Tables Il décrit la structure de la table : Sur 3 onglets Sa validation crée la table dans la base de données Sa revalidation change la structure de la table Champs de la table contenant les intitulés des fiches de la table, utilisés notamment pour les liens. Permet à X3 de dimensionner la table dans la base de données. Si ce chiffre est différent de ce qui a été calculé suite au dimensionnement dans les paramètres du dossier, la valeur la plus élevée sera prise en compte. Remarques : L’abréviation est utilisée par défaut pour nommer la table. Les champs d’une table sont définis par la syntaxe [F:XXX]NOMCHAMP, où XXX est l’abréviation de la table. L’indicateur Format 130 peut être utile si une table de la version 140 doit pouvoir être ouverte depuis un dossier en version 130. On subit alors les contraintes liées à la structure 130. Les tables spécifiques doivent être : Nommées de telle façon à éviter un conflit potentiel en cas de rajout d’autres champs standards (ils doivent commencer par X, Y, ou Z). Protégées par un code activité commençant par X, Y ou Z. Indicateur signalant les tables de mouvement remises à zéro en Raz dossier. Copie de données possible du Dossier de copie vers le dossier cible en création de dossier (si optionnelle, on précise le groupe de copie).

5.2 Tables et index Le dictionnaire des tables Développement / Dictionnaire données / Tables L’onglet champ définit les champs et leurs caractéristiques Les champs CREDAT, CRETIM,CREUSR, UPDDAT, UPDTIM,UPDUSR sont automatiquement mis à jour par l’objet de gestion associé Remarques : Les 3 intitulés sont utilisés selon la place disponible sur les écrans Le type de données fait référence à un type. Une norme implicite donne comme nom des types associés à un obket le code de l’objet lui-même, qui est lui-même l’abréviation de la table principale. Exemples : Type de données BPC [Client] = Objet BPC, Table BPCUSTOMER d’abréviation [BPC]. ITM = article (ITMMASTER), BPR = tiers (BPARTNER), BPS = fournisseur (BPSUPPLIER), GAC = compte général (GACCOUNT) FCY = site (FACILITY), CPY = société (COMPANY) La colonne liée indique précisément la table associée à l’objet lié au type. L’expression de lien n’est remplie que si la clé d’accès n’est pas simple (par exemple, pour l’objet CCE (section analytique), on indique le numéro d’axe sous la forme 1;CCE ou 2;CCE … Les types « standards » utilisés très fréquemment sont : A (alphanumérique), D (date), M (menu local), intitulé (NAM), intitulé court (SHO), montant (DCB), montant en devise (MD1), entier court (C), entier long (L), table diverse (ADI) Il est à noter que le champ Dim permet de stocker de façon dénormalisée dans une table plusieurs occurrences (ce nombre d’occurrences pouvant être induit par le code activité s’il y en a un à la ligne). Les champs sont nommés, dans la base de données, NOMCHAMP_0, NOMCHAMP_1, etc… Pour un champ sans dimension, le suffixe _0 est aussi présent. Le champ Raz permet d’indiquer dans colonnes remises à zéro dans l’outil de Raz dossier (cas où la table elle-même ne doit pas être vidée). Les colonnes Annulation, Vérif, Obligatoire, permettent de définir les conditions dans lesquelles l’intégrité référentielle est vérifiée (elle n’est pas gérée dans la base, mais par des utilitaires). Les champs spécifiques présents dans les tables standards doivent être : Nommés de telle façon à éviter un conflit potentiel en cas de rajout d’autres champs standards (ils doivent commencer par X_, Y_, ou Z_). Protégés par un code activité commençant par X, Y ou Z.

5.2 Tables et index Le dictionnaire des tables Développement / Dictionnaire données / Tables L’onglet index : définit les index de la table (un au moins doit exister) permet de saisir des directives de configuration Remarques : Les index peuvent être composées de plusieurs parties de clé (jusqu’à 16), définies avec la syntaxe suivante : CHAMP1+CHAMP2+CHAMP3 (si un ‘-’ est mis à la place du ‘+’, le champ est ordonné en sens inverse des autres) Les index spécifiques présents dans les tables standards doivent être : Nommés de telle façon à éviter un conflit potentiel en cas de rajout d’autres champs standards (ils doivent commencer par X, Y, ou Z). Protégés par un code activité commençant par X, Y ou Z. Il est à noter que les index d’optimisation, dont le code commence par SPE_ , n’apparaissent pas ici, même si la table en utilise. Une règle de nommage implicite existe pour les tables standard. On utilise, pour le nom de l’index, l’abréviation de la table, suivie successivement de 0, 1, 2… Les fichiers de configuration ont des syntaxes particulières (cf. l’aide en ligne de la fonction). Leur utilité est réservée à des administrateurs de base de données qui veulent préciser les tailles des tables à manipuler, leur implantation voire leur éclatement sur plusieurs volumes (oracle). En l’absence de fichier de configuration, des règles de dimensionnement par défaut, fondées sur le nombre prévu de lignes dans la table (cf. premier onglet), sont appliquées.

Le dictionnaire des types de données
Développement / Dictionnaire données / Types de données Un type de données caractérise les champs présents dans les écrans dans les tables dans les paramètres des états… Il existe des types génériques : A (alpha), C (entier court), D (date), L (entier long), M (menu local), DCB (décimal) On leur associe une longueur (A), un numéro de menu (M), un nombre de chiffres et de décimales sous la forme N.M DCB) Les autres types sont définis : par référence à un type interne en pouvant être associés à un objet (sélection, tunnel) en nécessitant parfois des paramètres La variable GLONXXX permet de connaître la longueur du champ de type XXX Remarques : On verra dans la suite ce qu’est un objet, mais retenons que la plupart des gestions de base (client, article, fournisseur, tiers, compte, nomenclature, gamme, journal…) et des mouvements de base (facture, commande, bon de livraison / réception, OF, écriture) sont des objets. La norme habituelle est de nommer de la même façon l’objet et le type de données associé à son identifiant. Ainsi, la fiche client est gérée par l’objet BPC, le type « code client » est BPC. L’exemple le plus frappant de type de données à paramètres est le type MD1 (montant en devises). Lorsqu’un tel type est utilisé, on ptrécise le code devise associé via une expression issue du contexte (ce peut être une constante bien entendu dans les cas simples). La saisie du paramètre se fait par clic droit sur le champ type (dans les écrans). D’autres exemples existent, où le paramètre est donné par l’expression de lien. C’est le cas par exemple du type ADI (table diverse) où le lien va être exprimé sous la forme nnn;CHAMP, où nnn est le numéro de la table et CHAMP le nom du champ utilisant ce type. Il en est de même pour tous les types associés à un objet dont la clé se décompose en plusieurs parties : par exemple les sections analytiques (type CCE) où le numéro de l’axe analytique est le premier paramètre. D’autres informations peuvent être précisées dans le dictionnaire des types, notamment des actions, mais ceci dépasse le cadre de cette introduction au développement.

Les menus locaux et les tables diverses
5.3 Types de données Développement / Dictionnaire données / Menus locaux Développement / Dictionnaire données / Paramétrage tables diverses Les menus locaux et les tables diverses Les menus locaux correspondent au type M (suivi d’un numéro) : Ils sont stockés sur un octet dans une table (valeur 0 à 255) Ils sont traduits en fonction de la langue de dialogue Ils sont téléchargés sur le poste client ou présents dans la description XML des écrans Web Leur valeur est stockée dans la table APLSTD Ils peuvent être définis avec un nombre de choix fixe ou variable (entre deux bornes), modifiables ou non en paramétrage Il existe des bornes de numérotation pour les spécifiques (1000 à 2000) Les tables diverses correspondent au type ADI : Complété par un numéro de table (défini dans l’expression de lien) De longueur maximale définie dans le paramétrage des tables diverses Avec des intitulés traduisibles Avec des champs complémentaires et des possibilités de dépendance Les numéros spécifiques sont compris entre 1000 et 2000 Remarques :

Le dictionnaire des écrans
5.4 Ecrans et fenêtres Le dictionnaire des écrans Développement / Dictionnaire traitements / Ecrans Un écran X3 est une partie d’une fenêtre du progiciel qui correspond : à un onglet au contenu d’une boîte de dialogue ou à l’en-tête d’un objet Il est organisé en blocs placés comme les cases d’un damier Remarques : Le système de coordonnées a changé depuis la version 130. Chaque bloc contient des champs : en liste en tableau déroulant en boîte de texte

Le dictionnaire des écrans
5.4 Ecrans et fenêtres Le dictionnaire des écrans Développement / Dictionnaire traitements / Ecrans Chaque bloc contient une liste de champs ayant des attributs : Rang dans le bloc (sous forme 1, 2, 3 mais aussi 1.1, 1.2, 1.3) Intitulé Type de données et informations rattachées (no de menu, longueur, objet graphique, tunnel et zone lien…) Un code activité Des actions définies dans les tableaux ci-dessous Remarques :

Le dictionnaire des fenêtres
5.4 Ecrans et fenêtres Le dictionnaire des fenêtres Développement / Dictionnaire traitements / Fenêtres Une fenêtre est la réunion d’un ensemble : d’écrans de boutons et de menus de listes gauches Remarques : En standard, les règles de nommage, pour une fenêtre unique associée à un objet, sont de la nommer en faisant précéder le code de l’objet par la lettre O.

Le dictionnaire des paramètres
5.5 Définition de nouveaux paramètres Développement / Dictionnaire données / Définition paramètres Le dictionnaire des paramètres Ce dictionnaire permet de définir des paramètres : En les créant dans un chapitre (table diverse numéro 901) En définissant leur niveau de paramétrage le plus fin : Dossier, Société, Site, Utilisateur En leur associant une variable globale qui sera automatiquement créée et renseignée (si le niveau est Dossier ou Utilisateur). L’utilisation des variables globales est alors possible dans toute formule de calcul. Remarques : Les normes de nommage imposent d’appeler les paramètres par un nom commençant par X,Y, ou Z (il en est de même pour les nouveaux chapitres). Contrairement à la version 130, il n’est plus obligatoire de créer les paramètres dans des chapitres dédiés. De même, un usage fait nommer les variables globales par un nom commençant par G. Les variables spécifiques commenceront donc par GX, GY, ou GZ. Il est particulièrement facile de réaliser un spécifique pour donner une valeur par défaut en fonction de l’utilisateur dans la plupart des contextes. En effet, si on crée un paramètre de niveau utilisateur associé à une variable globale, cette variable sera ensuite accessibmle de façon généralisée dans n’importe quelle formule de calcul, et donc dans les paramétrages qui utilisent des formules de calcul (par exemple Workflow, valeur des paramètres des états, règles d’affectation des imprimantes, valeurs par défaut d’une page portail, tables de contrôle, propriétés des objets…)

Le dictionnaire des objets
5.6 Fonctionnement de base d’un objet Développement / Dictionnaire traitements / Objets Le dictionnaire des objets Un objet est la description d’une fonction de base à même de gérer : Une table principale (et des tables liées) Par le biais d’au moins une fenêtre (s’il en a plusieurs, un choix sera proposé : c’est ainsi qu’est réalisée la gestion de transactions) C’est le modèle de base le plus présent dans ADONIX X3. Remarques : Un objet simple se définit sans qu’il soit nécessaire d’écrire du code L4G. Par contre, dès que l’on désire gérer des situations particulières, on aura la possibilité de traiter des actions dans un traitement standard et dans un traitement spécifique.

Le dictionnaire des objets
5.6 Fonctionnement de base d’un objet Développement / Dictionnaire traitements / Objets Le dictionnaire des objets On retrouve dans la définition d’un objet : Des filtres génériques utilisables lors des appels par tunnel La définition des champs de la liste gauche Des informations complémentaires pour l’import notamment (onglet Environnement) Remarques :

Www.absyscyborg.com.

Présentations similaires

Présentation au sujet: "Www.absyscyborg.com."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Www.absyscyborg.com.

Présentations similaires

Présentation au sujet: "Www.absyscyborg.com."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back