SX3012-01_OutilsAvances_-Support-de-cours.pdf

Sage ERP X3 – Outils avancées

Sage ERP X3

Support de formation Outils avancés

Sage ERP X3 - Outils avancés

Sage 2011

« Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ».

Page 1


Sommaire 1.

GESTION DES SESSIONS ........................................................................................................................... 4 1.1. 1.2. 1.3. 1.4.

2.

CODES D’ACTIVITE ................................................................................................................................. 14 2.1. 2.2. 2.3.

3.

PRINCIPES DE BASE .................................................................................................................................. 47 LE DICTIONNAIRE DES ETATS ...................................................................................................................... 48 LANCEMENT D’UN ETAT ............................................................................................................................ 55 AFFECTATION DES CODES INTERNES A DES ETATS ........................................................................................... 59 VALEURS PAR DEFAUT DES PARAMETRES D’ETATS........................................................................................... 60 GESTION DES DESTINATIONS D’IMPRESSION .................................................................................................. 61 SERVEURS D’EDITION ............................................................................................................................... 65 NOTES TECHNIQUES................................................................................................................................. 66 ANALYSE DES PERFORMANCES DES EDITIONS CRYSTAL REPORT ......................................................................... 68

EPURATION ET HISTORISATION ............................................................................................................. 70 7.1. 7.2. 7.3. 7.4. 7.5. 7.6.

8.

CARACTERISTIQUES DU SERVEUR BATCH ....................................................................................................... 29 PRINCIPES DE FONCTIONNEMENT ............................................................................................................... 30 SURVEILLANCE DES TACHES ....................................................................................................................... 36 SOUMISSION DE TACHE PAR FICHIER ............................................................................................................ 38 PARAMETRES DU SERVEUR BATCH............................................................................................................... 41 NOTES TECHNIQUES................................................................................................................................. 42 LA TACHE BATCH COMPTABLE .................................................................................................................... 44

GESTION DES ETATS .............................................................................................................................. 47 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9.

7.

INTRODUCTION ....................................................................................................................................... 22 LA GESTION DES PATCH............................................................................................................................. 24

LE SERVEUR BATCH ............................................................................................................................... 29 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

6.

GESTION DES OBJETS : NAVIGATION ............................................................................................................ 18

LA GESTION DES PATCHS ET DES VERSIONS .......................................................................................... 22 4.1. 4.2.

5.

DIFFERENCES ENTRE LE PARAMETRAGE ET LE DEVELOPPEMENT. ........................................................................ 14 NOTION DE VERTICAL ET DE SPECIFIQUE ....................................................................................................... 14 GESTION DES CODES ACTIVITE .................................................................................................................... 15

PARAMETRAGE DES FONCTIONS ........................................................................................................... 18 3.1.

4.

CONNEXION A UN DOSSIER SAGE X3 ............................................................................................................. 4 DEFINITION D’UNE SESSION X3 .................................................................................................................... 8 CONTROLE DES SESSIONS AUTORISEES ......................................................................................................... 10 CLIENT « TERMINAL MOBILE » ................................................................................................................... 13

PRINCIPES DE BASE .................................................................................................................................. 70 CREATION D’UN DOSSIER D’HISTORISATION .................................................................................................. 72 DEFINITION DES REGLES D’EPURATION ET D’HISTORISATION ............................................................................. 74 PARAMETRES D’EPURATION / HISTORISATION ............................................................................................... 75 EXECUTION DE L’HISTORISATION / EPURATION .............................................................................................. 76 VISUALISATION DES DONNEES HISTORISEES ................................................................................................... 77

LE WORKFLOW MANUEL ....................................................................................................................... 78 8.1. 8.2. 8.3. 8.4.

INTRODUCTION ....................................................................................................................................... 78 LES MODELES DE DONNEES........................................................................................................................ 81 PARAMETRAGE DES REGLES DE WORKFLOW .................................................................................................. 83 LES REGLES D’AFFECTATION ....................................................................................................................... 99


Sage 2011


Page 2


8.5. 8.6. 8.7. 8.8. 8.9. 8.10. 8.11. 8.12. 9.

MONITEUR DE WORKFLOW & PLANS DE TRAVAIL ........................................................................................ 104 LE MONITEUR DE WORKFLOW ................................................................................................................. 113 ERGONOMIE DU PLAN DE TRAVAIL ............................................................................................................ 116 WORKFLOW – POINTS DIVERS ................................................................................................................. 117 WORKFLOW LIVRES EN STANDARD ............................................................................................................ 120 FONCTIONS DEDIEES A LA CRM ............................................................................................................... 135 NOTES TECHNIQUES............................................................................................................................... 136 LES LIENS DE WORKFLOW ........................................................................................................................ 140

LA GESTION DE LA DOCUMENTATION ................................................................................................. 145 9.1. 9.2. 9.3. 9.4. 9.5. 9.6. 9.7.

10.

LES OUTILS DU SUPERVISEUR .............................................................................................................. 160

10.1. 10.2. 10.3. 10.4. 10.5. 10.6. 10.7. 10.8. 11.

INTRODUCTION ..................................................................................................................................... 145 L’ORGANISATION DE LA DOCUMENTATION.................................................................................................. 146 L’AIDE SUR LES CHAMPS ......................................................................................................................... 151 L’EDITEUR HTML ................................................................................................................................. 152 LES LIENS DE DOCUMENTATION ................................................................................................................ 155 LA GENERATION DE LA DOCUMENTATION ................................................................................................... 157 PUBLICATION DE LA DOCUMENTATION....................................................................................................... 159

INTRODUCTION ..................................................................................................................................... 160 OUTILS DE MAINTENANCE ....................................................................................................................... 161 OUTILS DE VERIFICATION ........................................................................................................................ 163 OPTIMISATION BASE DE DONNEES ............................................................................................................ 173 OPTIMISATION BASE DE DONNEES ............................................................................................................ 175 UTILITAIRES DICTIONNAIRE ...................................................................................................................... 177 UTILITAIRES DE RECHERCHE ..................................................................................................................... 187 UTILITAIRES DIVERS ............................................................................................................................... 189

LES TRANSACTIONS SYSTEME.............................................................................................................. 193

11.1. 11.2.

CREATION D’UNE TRANSACTION ............................................................................................................... 194 L’EXECUTION D’UNE TRANSACTION SYSTEME .............................................................................................. 196


Sage 2011


Page 3


1. GESTION DES SESSIONS 1.1. CONNEXION A UN DOSSIER SAGE X3 On se connecte sur un dossier Sage 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 X3, 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

En mode client serveur

En mode Web, la mire de connexion est similaire sauf que le code de l’application n’est pas saisissable car il est implicitement définit par l’URL d’accès à la mire de connexion. 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


Sage 2011


Page 4


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

-

Allemand

-

Chinois moderne

-

Chinois simplifié

-

Russe pour GEODE GX

-

…

D’autres langues sont mises en œuvre par des partenaires. On verra plus loin (en gestion des licences) comment sont définies les connexions possibles. La boîte de connexion permet de saisir : Les 3 principaux éléments de la connexion (dossier, utilisateur, langue) Un mot de passe applicatif authentifiant l’utilisateur dans le dossier Une date logique de connexion


Sage 2011


Page 5


1.1.1. Définition des paramètres d’un dossier On regroupe les 3 éléments identifiant un dossier : Stocké, en client-serveur, dans un fichier de configuration local accessible via le bouton « Configuration »

Avec quelques paramètres complémentaires : - code utilisateur réseau de connexion par défaut, - serveur de traitement s’il est différent, - informations de connexion système. Il est ici possible d’ajouter des informations de connexion vers d’autres dossiers Chargement :


Sage 2011


Page 6


Le bouton Avancé donne accès à des paramètres complémentaires Format de l’aide CHM ou HTML Source ODBC pour Crystal Reports (si « Valeur par défaut » est sélectionné, on utilise les valeurs définies lors de l’installation) Remarque : La case à cocher Application par défaut proposera ce dossier par défaut à la connexion. L’activation thème graphique permet d’utiliser le thème standard de type XP. Si cette case n’est pas cochée, on se retrouve avec une apparence des écrans plus proche des écrans Windows NT. Attention, en connexion via Citrix, il faut décocher la case en question.

1.1.2. Aide en ligne L’aide en ligne se présente sous forme HTML ou sous forme d’archive (chm) Intérêt du chm Onglet sommaire Onglet recherche Impression directe par bouton

Inconvénients du format chm Un très gros fichier Inutilisable en mode Web L’aide en ligne fonctionnelle est liée aux autres aides par des liens hypertextes.


Sage 2011


Page 7


1.2. DEFINITION D’UNE SESSION X3 1.2.1. Sessions primaires et sessions secondaires Une session primaire correspond à une connexion depuis la boîte de connexion. Plusieurs sessions primaires peuvent être ouvertes depuis un même poste. Ces sessions peuvent être connectées à des dossiers différents, sous des langues différentes, et avec des codes utilisateurs différents. Une session secondaire est une session ouverte à partir d’une session primaire depuis un poste client-serveur ou un poste en mode Web. Fichier / Session secondaire Appel d’une touche de fonction (Shift F5 à Shift F12) paramétrable par utilisateur Utilisation de l’icône Par conséquent une session secondaire permet de travailler sur le même dossier que la session primaire, avec le même utilisateur, et dans la même langue. Le nombre de sessions primaires et secondaires est limité au niveau global, par la licence, au niveau utilisateur ou groupe d’utilisateurs par les paramètres définis dans le dossier. Une connexion à Sage X3 provoque l’ouverture d’une session identifiée de façon unique pour un serveur d’application donné d’un type donné. Une session secondaire possède les caractéristiques suivantes : Forcément ouverte sur le même dossier, et pour le même utilisateur Automatiquement fermée (avec une confirmation) si la session primaire dont elle dépend est ellemême fermée

1.2.2. Autres sessions Il existe d’autres types de connexion dans l’application : - Session batch (déclenchée par le serveur batch) - Session WEB Services - Session terminal VT Remarque : 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 Sage X3 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 Session mode Client / serveur 2 Session secondaire en mode Client / serveur. 3 Session Batch 9 Session Client mode web 10 Session secondaire en mode Client web 12 Session Client web services. Communication synchrone avec des applications tierces. Sage ERP X3 - Outils avancés

Sage 2011


Page 8


1.2.3. La licence Développement > Utilitaires > Vérifications > Visualisation licence

Le nombre de licence par type est définie par le fichier serial_adonix installé dans le répertoire de la solution Sage sur le serveur d’application. En cas de mise à jour de ce fichier, il est conseillé de sauvegarder l’ancien fichier serial_adonix avant d’installer le nouveau.


Sage 2011


Page 9


1.3. CONTROLE DES SESSIONS AUTORISEES 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

Remarque : L’utilisateur ADMIN n’est jamais limité en nombre de connexions (par contre, le verrouillage monoutilisateur lui est opposable).

1.3.1. Visualisation des sessions actives Développement > Utilitaires > Vérification > Surveillance > Utilisateurs

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é

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, 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 (i.e. être connecté comme root sous Unix, comme administrateur sous Windows), soit être connecté sous la même identité que le propriétaire Sage ERP X3 - Outils avancés

Sage 2011


Page 10


des processus. Par ailleurs, une habilitation définie au niveau de l’accès de cette fonction est aussi nécessaire 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é.


Sage 2011


Page 11


1.3.2. Désactivation d’une session Pour suspendre une session à partir du tableau des sessions actives, positionner le focus sur la ligne du Poste client à suspendre. La liste des processus actifs pour la session sélectionnée est alors affichée dans le tableau des processus actifs. A l’aide d’un clic droit sur ce tableau ou ouvre la fenêtre permettant d’accéder à la fonction d’Arrêt des processus de cette session.

A une session Sage X3 correspond au minimum les processus suivants Adonix -> Processus Sage X3 de gestion de la session, Ce processus adonix correspond à l’exécution du code applicatif. Il est exécuté sur un serveur de traitement sadora ou sadsql -> Processus de gestion des accès à la base de donnée pour la session. Il est aussi exécuté sur un serveur de traitement Les processus sadfsq correspondent aux accès par la session à des fichiers de type séquentiels. Ils peuvent être présents sur plusieurs serveurs (y compris sur le poste client, par exemple si on écrit un fichier séquentiel en local). Cette fonction permet d'arrêter le processus correspondant (par kill sous UNIX, par la fonction killadx sous NT). L'arrêt d'un processus signifie, du point de vue de la base de données, l'arrêt propre de la transaction en cours, mais également la perte des données en cours de saisie. Il importe donc d'être très prudent dans l'utilisation de cette fonction réservée à la résolution d'incidents d'exploitation. Les scripts de purge d’une session peuvent être activés par un processus externe à Sage X3


Sage 2011


Page 12


1.4. CLIENT « TERMINAL MOBILE » Ce nouveau type de terminal est dédié aux fonctions logistiques de l’offre Sage GEODE.

1.4.1. Généralités Ce type de terminaux permet de créer des documents, le mode mise à jour n’est pas disponible. Les champs présentés permettent d’identifier les lignes de stock. L’affichage des champs n’est pas paramétrable par transaction. Le site utilisé est affiché sur chaque mouvement. Par défaut c’est le site lié à l’utilisateur connecté. Ce site est modifiable via une fonction « Définir le site ». Les principales touches fonctions sont : F1 F3 F4 F2

OK. Cette touche permet le passage à la ligne suivante Select Fin Créer

Une ligne de document = 1 mouvement de stock Le paramètre utilisateur VTMEN permet de définir le profil menu de l’utilisateur connecté via ce type de terminal. En cas d’absence c’est le profil menu VT qui est utilisé par défaut.

1.4.2. Possibilités fonctionnelles -

Gestion des entrées et sorties diverses Réception Transferts intersites Transferts sous–traitants Changement de stocks Rangement sur liste Réapprovisionnement d’un emplacement Inventaires Sorties matières Déclaration de fabrication Suivi des temps

1.4.3. Pré requis La mise en œuvre de ce type de connexion nécessite l’utilisation d’un serveur http Sage X3. Les terminaux radio fréquence communiqueront via Telnet avec ce serveur. Ces points dont abordés dans un cours dédié à la mise en œuvre de ce type de matériel.


Sage 2011


Page 13


2. CODES D’ACTIVITE 2.1. DIFFERENCES ENTRE LE PARAMETRAGE ET LE DEVELOPPEMENT. Le paramétrage est pérenne, il est conservé lors des changements de version et n’est pas modifié par une mise à jour de patch Les développements spécifiques doivent être protégés pour être pérennes, chaque élément modifié doit être marqué par un code que nous désignons par le terme code activité spécifique. - un patch standard ne modifiera pas le spécifique et le vertical si ils sont protégés - un patch vertical ne modifiera pas le spécifique si il est protégé - 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. Par exemple le paramétrage des consultations. Ces différences peuvent paraître subtiles, mais elles n’en sont pas moins fondamentales. Dans la suite de ce cours 90% des fonctions qui seront vues sont du paramétrage. Pour un développement, lorsqu’un champ est modifié par rapport au standard, une marque doit signer la modification. Cette marque est désignée dans X3 par le terme code activité. 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.

2.2. NOTION DE VERTICAL ET DE SPECIFIQUE Au niveau des objets et des écrans Sage X3, des traitements dédiés peuvent être affectés aux objets et/ou écrans. Par exemple dans Sage Entreprise lors de la saisie du code devise d’une facture, le traitement standard effectue un traitement sur ces champs permettant de trouver le taux de conversion en fonction de la date de comptabilisation de la facture. Il est possible de surcharger ce traitement par un traitement spécifique qui gère une contrainte complémentaire. Dans notre exemple on désire rechercher le taux de change mensuel. Lorsque les traitements spécifiques mis en place sont réutilisables pour plusieurs dossiers indépendants, la standardisation des spécifiques devient un vertical. Si un traitement vertical est déclaré, pour une même action X3, celui-ci sera exécuté après le traitement spécifique et avant le traitement standard. De même au niveau des actions sur les champs de l’écran, l’enchaînement des traitements sera : - SPE : Action spécifique - SPV : Action verticale - STD : Action standard Cette notion de vertical possède des impacts importants sur les développements et les patchs. Ce qui nécessite la mise en place d’une normalisation des composants de la solution Sage X3.


Sage 2011


Page 14


2.3. GESTION DES CODES ACTIVITE La gestion des codes activité concerne à la fois les opérations de développement et celles de paramétrage. La séparation entre les deux domaines peut être la suivante : La création d’un code activité est une opération de développement. La mise en œuvre dans un dossier (activation / désactivation) est une opération de paramétrage. Par exemple le nombre d’axes analytiques est une opération de paramétrage, ce nombre est prévu dans une fourchette de 1 à 9 par le développement. C’est pourquoi nous présentons cette gestion dans ce document. Le rôle des codes activité est de rendre actifs ou inactifs des éléments du dictionnaire Sage X3, par exemple : - tables - index - onglets - blocs - champs d'écran - etc Le fait de rendre actif ou non un code activité donné permet de désactiver, dans les écrans, certains champs optionnels en fonction des règles de gestion choisies. Conventions sur la codification du premier caractère des codes activité - Lettre K : identifie les éléments développés pour les localisations standards, - Lettre X : identifie les développements verticaux, - Lettre Y Z : identifie les développements spécifiques. Développement > Dictionnaire données > Ouverture au paramétrage > Code activité


Sage 2011


Page 15


A la génération d’un dossier, les codes activités peuvent être initialisés comme étant actifs ou inactifs en fonction du paramétrage réalisé sur la fiche de description du dossier. Ce point sera présenté dans le chapitre de gestion des dossiers. Après la génération d’un dossier, il est possible de modifier le statut d’un code activité. En fonction des caractéristiques du code activité des opérations de revalidation peuvent être nécessaires. Par exemple la modification du nombre d’axes analytiques nécessite de revalider les écrans, fenêtre et tables contenant des données dépendantes de ce code activité.

2.3.1. Les types Fonctionnel : Ce type de code activité permet de rendre actif / inactif une fonction sage X3, par exemple le code ABI permet d’activer les fonctions BI dans l’application. Dimensionnement : Ce type de code activité décrit une règle de dimensionnement qui permettra de définir le nombre d’occurrences dans les tables, les écrans. Par exemple Le code ANA définit le nombre d’axes analytiques gérés. Les codes activité de type dimensionnement possèdent des attributs complémentaires suivants. - Dimension maximum : Cette valeur est la taille maximum gérée par les traitements Dimension écran : Cette valeur est la taille utilisée pour générer les écrans et les tables. Localisation : Ce type de code activité est lié à une règle de gestion liée à une législation. Par exemple KPA décrit comment gérer les relevés bancaires dans la législation portugaise.


Sage 2011


Page 16


2.3.2. Cas de dépendance entre codes Le bloc dépendance permet de décrire des relations entre les codes activité. Ce point est abordé dans le cours développement. Au niveau paramétrage ce bloc ne doit pas être modifié. Inverse : Le code activité prend la valeur inverse du code activité saisi en regard; il sera actif si le code activité correspondant est inactif, et inactif s'il est actif. Dimensionnement : le code activité est alors composé d'une racine, suivi d'un nombre M (de 1 à 9), et il est associé à un code activité qui peut prendre des valeurs numériques de 1 à N. Le code activité est actif si la valeur du code associé est supérieure ou égale à M; sinon, il est inactif. On peut prendre l'exemple du code ANA, associés par des liens de dimensionnement aux codes AX1 à AX9. Si ANA vaut 5, les codes AX1 à AX5 seront actifs, les codes AX6 ç AX9 seront inactifs. Formule : permet de calculer la valeur d'un code activité en fonction d'une formule saisie. Cette expression calculée peut intégrer des constantes, des fonctions, et des variables sous la forme d'autres codes activité. Ces codes activité peuvent être des codes saisis, ou des codes calculés antérieurement. L'ordre de calcul des codes activités dépendant de codes antérieurs est défini par le rang. Un code activité non porteur d'une dimension vaut 1 s'il est actif, et 0 s'il est inactif.

2.3.3. Tables mises en œuvre Tables ACTIV ADOVAL

ACV ADW

Contenu Définition des codes activité et des valeurs associées Intitulé des codes activité (Cette table étant utilisée dans de nombreux contexte, ne sera plus citée dans la suite de ce document)


Sage 2011


Page 17


3. PARAMETRAGE DES FONCTIONS Ce chapitre présente les outils permettant de modifier par paramétrage des fonctions existantes dans la solution X3. Nous limitons ces modifications aux adaptations qui ne nécessitent pas la mise en œuvre des codes activité pour protéger ces personnalisations. Les modèles de fonctions induisent des paramétrages particuliers : -

Modèle Objet Propriétés Personnalisation Liaisons automatiques Navigation Transaction

-

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)

3.1. GESTION DES OBJETS : 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 œuvre d’un paramétrage


Sage 2011


Page 18


3.1.1. Navigation : principes de base Une fonction X3 dispose de possibilités de navigation vers d’autres fonctions Quand la fonction arrivante est un objet, on peut vouloir tenir compte du contexte appelant pour :



Proposer des valeurs défaut en création



Imposer des filtres de sélection

par

Via l’explorateur de liaisons Via des menus dans la barre d’outils

Par tunnel

Via des boutons

Remarque Ces navigations sont toujours des navigations avec un retour à la fonction appelante.


Sage 2011


Page 19


3.1.2. Navigation : définition détaillée Développement / Dictionnaire traitements / Navigation 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

Filtres sur la liste gauche : Condition d’activation Filtre

Navigation : définition détaillée Sur le second onglet, on paramètre les valeurs par défaut

Champs des écrans

Formules des valeurs par défaut


Sage 2011


Page 20


Remarque : Ces valeurs par défaut s’appliquent en création de fiche, et pas en duplication

3.1.3. Navigation : cas particulier 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

Sage 2011


Page 21


4. LA GESTION DES PATCHS ET DES VERSIONS 4.1. INTRODUCTION 4.1.1. Qu’est ce qu’un patch ? 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 : code applicatif, description de structure de données, données, une demande d’exécution d’un utilitaire… Apportant des évolutions fonctionnelles

Un patch peut contenir un ou plusieurs éléments tels que des écrans, des déclarations de tables, des codes activités, des types de données, des objets, des menus locaux, des chapitres de messages, des traitements, des demandes d’exécution de traitements, des données... Des éléments de paramétrage sont patchables (requêtes, requêtes SQL…) Typologie de patches : standard, spécifique, vertical, superviseur.

4.1.2. Gestion des versions Les versions sont numérotées sur 3 chiffres X.Y.Z : X = génération majeure (1 pour le moment) Y = version majeure (0,1,2,3,4) Z = version mineure Pour plus de facilité, les patchs sont organisés en liste, numérotées à partir du début d’une version majeure (X.Y) de 1 à M. Une version mineure correspond à une liste donnée de patchs. Ces dépendances sont visibles dans un fichier nommé X3PATCHXY0, livré avec toute liste de patchs 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 (145), 01/2007 V5 : été 2007


Sage 2011


Page 22


4.1.3. Limites des patchs Les patchs doivent être installés séquentiellement. C’est-à-dire que cela suppose que les précédents soient installés (Il peut être avantageux d’installer une version intermédiaire quand on est très en amont du numéro de patch à installer.) Lorsqu’un patch nécessite de mettre à niveau l’un des moteurs, une procédure dédiée est précisée. Généralement, la mise à jour d’un moteur s’effectue en exécutant le fichier sur le serveur à mettre à jour. Les patchs ne permettent pas de mettre un jour les différents moteurs de l’application (client, serveur de données, serveur web, l’aide en ligne…). Les patchs ne permettent pas de remettre à jour les données de paramétrage situées dans le dossier de référence Sage X3.

4.1.4. Les précautions à prendre Lire le fichier X3PATCHVxxx : Il précise les pré-requis, les points particuliers (changement de structure pouvant nécessiter de la place disque, par exemple), les actions à effectuer avant ou après l’intégration du patch. 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) Lorsque des spécifiques ont été réalisés, il est conseillé d’utiliser le testeur de patchs pour vérifier d’éventuels conflits. Avant intégration manuelle, s’assurer : - que les tâches comptables sont arrêtées, - que le serveur batch est inactif


Sage 2011


Page 23


4.2. LA GESTION DES PATCH 4.2.1. L’intégration d’un patch Développement > Utilitaires > Patch > Intégration de patch A partir de la zone « Répertoire des fichiers patchs », il est nécessaire de situer le répertoire contenant les patchs « FILPATCH » ou le fichier lui-même « PP_00760_140.dat ».

Par défaut l’ensemble des dossiers se trouvant dans l’environnement est proposé. Il est possible d’en supprimer de la liste. Si la case à cocher Intégration de patch n’est pas cochée, les fichiers patchs sont simplement lus. L’intégration n’est effective que lorsque la case est cochée. Tables mises en œuvre

Nom de la table APATCH


Abréviation APT

Contenu Suivi des patchs intégrés

Sage 2011


Page 24


4.2.2. 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 Sage X3 et les dossiers d’exploitation (ou autrement dit le dossier de référence et le(s) dossier(s) d’exploitation ou encore le dossier mère et le(s) dossier(s) fille). 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 Si un dossier n’est pas mis à niveau des patchs, il risque de ne plus fonctionner correctement, car un traitement présent uniquement dans le dossier superviseur peut s’appuyer sur une structure de données modifiée dans le même patch. Or un traitement de dossier superviseur sera automatiquement hérité dans tous les autres dossiers, alors que la structure de données sur laquelle il s’appuie n’aura pas été intégrée dans le dossier en question, ce qui provoquera une incohérence. Des cas particuliers existent : Si un dossier est de type Test (ce flag est défini dans les paramètres de gestion du dossier), les traitements seront intégrés dans le dossier lui-même. Ainsi, si l’on désire réaliser un test de fonctionnement d’un patch (par exemple sur un dossier intégrant beaucoup de spécifiques) sans perturber l’environnement d’exploitation, il est possible de n’intégrer le patch que sur ce dossier : les traitements et le dictionnaire seront alors « patchés », ce qui permettra de réaliser un test complet. Attention toutefois, le fait d’installer des traitements standards sur un dossier rend ensuite ce dossier particulier : l’application uniforme d’un autre patch sur l’ensemble des dossiers y compris celui-ci risque de ne pas être opérant sur le dossier de test (car les traitements existants dans le dossier de test ne sont pas hérités du dossier superviseur). Si un patch intègre des traitements spécifiques (commençant par X, Y, ou Z, ou encore par SPE), ces traitements ne seront intégrés dans le dossier que s’ils existent déjà ; sinon, ils seront intégrés dans le ou les dossiers de type Développement (flag défini dans les paramètres de gestion du dossier) Si une mise à jour sur tous les dossiers est faite (ce qui est le cas le plus fréquent), les dossiers qui auraient un niveau de patch inférieur à celui du dossier superviseur devront être revalidés pour être en adéquation avec l’environnement.


Sage 2011


Page 25


4.2.3. Tester un patch Développement > Utilitaires > Patch > Test de patch Il permet de vérifier l’intégrité référentielle en anticipant tous conflits potentiels lors de l’installation du patch : 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). Particulièrement utile lors de l’installation d’une nouvelle version dite mineure

4.2.4. Consulter un patch Cette fonction permet de voir les patchs intégrés dans le dossier. Développement > Utilitaires > Patch > Consultation de patchs Numéro : Clé (numérotation automatique) Fichier : Nom complet du fichier. Le préfixe PX est caractéristique des patches standards sur X3 Version : Les fichiers patches standard ont des noms constitués sur le modèle PX_nnnn_vvv.dat, où : - PX est le caractère définissant un patch standard (il est conseillé aux intégrateurs d’utiliser l’une des lettres X,Y, ou Z pour nommer leurs fichiers de petch). - nnnn est un numéro chronologique sur lequel une vérification de séquence est faite - vvv caractérise la version majeure sur laquelle s’applique le patch (110, 120, 130, 140, 150). Maintenance : Numéro de maintenance. Utilisé, à préfixe égal, pour le contrôle de séquence Définit le numéro chronologique nnnn relatif au fichier de patch. C’est sur cette caractéristique, et sur le champ Type, que le contrôle de séquence des patches est réalisé. Patch : Numéro de liste de patch, ce numéro identifie la liste de patch concernée.

4.2.5. La création d’un patch Cette fonction permet de créer une archive contenant des développements spécifiques créés ainsi que des éléments de paramétrage modifiés entre deux dates du dossier courant. Création manuelle Développement > Utilitaire > Patch > Création de patchs

Indiquer le chemin et le nom du fichier (ex : E:\Patch\ZmyPatch_140_001.dat) Codes activité : Ce tableau permet de saisir une liste de codes activités commençant par X, Y ou Z. Dès lors que l’on désire créer un patch intégrant des développements spécifiques, il est obligatoire de définir ici les codes activités concernés. En effet, si cela n’est pas fait, les éléments du dictionnaire Sage ERP X3 - Outils avancés

Sage 2011


Page 26


portant des codes activités spécifiques non listés ici seront ignorés à l’intégration du patch. Cette précaution est obligatoire, car sinon un patch standard serait en mesure de mettre à jour un objet marqué par un code activité spécifique. C’est précisément le fait qu’aucun code activité spécifique ne soit donné en tête dans un patch standard qui permet de gérer ce fait. Ces codes activités ne sont pas un moyen de filtrer l’extraction des objets du patch, mais un moyen d’indiquer quels codes d’activités spécifiques ne seront pas respectés à l’intégration du patch. Il existe par contre une fonction qui permettra ensuite de pré-charger le tableau avec les objets marqués par les codes activités saisis ici. Objets : Ce tableau permet de saisir une liste d’objets à « patcher ». Cette liste est identifiée par un type d’objet et un nom. Langues : Ce tableau permet de définir les langues que l’on désire « patcher ». En effet, tous les textes du dictionnaire de données (définis par le code type ATX) sont stockés dans une table séparée (la table ATEXTE) et sont identifiés par un numéro (inférieur à 50.000 pour les textes standards, et supérieur au delà). Ces textes sont transmis via patch sous leur forme littérale (le numéro n’a pas de sens puisqu’il peut varier) dans différentes langues. La liste des langues utilisées pour inclure les textes est donc donnée par ce tableau. Type de patch : - Standard : intégration du standard dans tous les dossiers ; spécifique et vertical sont conservés. - Superviseur : intégration dans le dossier mère uniquement (documentation, modèles import-export, pièces automatiques, workflow, etc.). - Vertical : intégration dans tous les dossiers ; spécifique conservé, et suppression des SPV obsolètes. - Spécifique : intégration dans tous les dossiers ; suppression des actions SPE obsolètes.

4.2.6. Création automatique de patch Développement > Utilitaire > Patch > Création de patchs Cette fonction permet de créer une archive contenant des développements spécifiques créés dans le dossier courant, ainsi qu’un certain nombre d’éléments de paramétrage modifiés entre deux dates. Une fois cette fenêtre de sélection préliminaire saisie et validée, le traitement de sélection s’exécute (une fenêtre de progression affiche la sélection en cours), puis une deuxième fenêtre s’ouvre.

Cette fenêtre de validation présente un tableau listant, pour chacun des types d’éléments susceptibles d’être « patchés », le nombre d’éléments concernés. La fonction Détail, accessible par clic droit, permet alors de visualiser les éléments sélectionnés. Il est encore possible (par le champ Oui / Non) de désélectionner globalement un type d’élément. Lorsque cette dernière fenêtre est validée, l’extraction se fait dans le fichier de patch, et la fonction se termine.


Sage 2011


Page 27


Notes sur la « Génération directe » Si la case « Génération directe » est cochée, l’extraction va se faire sur la liste des éléments restés sélectionnés sans autre filtre possible Si cette case n’est pas cochée, le fichier de patch qui sera créé ne contiendra qu’un en-tête avec la liste des éléments à « patcher ». Il suffira, pour générer effectivement le fichier avec son contenu, de rappeler ce fichier en création manuelle de patch. La question Chargement d’objet sera alors posée. En répondant Oui à cette question, on rechargera l’intégralité de l’en-tête du patch. Il sera alors possible de modifier manuellement la liste détaillée des objets à « patcher », de la compléter, et de lancer finalement l’extraction des éléments du patch pour réécrire le fichier de patch avec à la fois l’en-tête listant les éléments et leur contenu.


Sage 2011


Page 28


5. LE SERVEUR BATCH

Un traitement batch est un processus exécuté sans interaction avec un utilisateur. En général ce processus est dédié aux traitements sur un ensemble de données qui peut être volumineux. Ils sont surtout utilisés pour des processus automatisés, déclenchés périodiquement. Exploitation > Serveur batch > … En informatique, un traitement batch est un traitement à déclenchement automatisé. Ils sont surtout utilisés pour des tâches automatisées, notamment pour la gestion des comptes sur le parc informatique d'une entreprise, université,...

5.1. CARACTERISTIQUES DU SERVEUR BATCH Dans Sage X3, le serveur batch est un processus fonctionnant en arrière-plan sur le serveur d’application. Il gère le lancement de tâches batch (des traitements Sage X3 ou des commandes OS) et il est exploité dans un environnement dédié. Il utilise les ressources définies dans le répertoire ..\Runtime\ SERVX3. Les tâches soumises au serveur batch s'appellent des requêtes.

5.1.1. Mise en service du serveur batch Il est possible d’activer les services selon les modes suivant : - au lancement du système : adonix -a -l lang SERVX3 - à partir de Sage X3 : Exploitation / Serveur batch / Activation serveur - automatiquement à la connexion d'un utilisateur (paramètre DEMSRV).

5.1.2. Arrêt du serveur : Il est possible d’arrêter le serveur selon : - à partir de Sage X3 : Exploitation / Serveur batch / Désactivation serveur - en créant un fichier stop dans le répertoire FIL du dossier SERVX3 (sur une application en local C:\Sagex3\X3V5T\runtime\SERVX3) - en arrêtant la base (par exemple pour une sauvegarde)

5.1.3. Paramètres superviseur associés NIVBATCH Paramètre modifiable par utilisateur permettant de définir un filtre sur les tâches qu’il peut utiliser (chapitre superviseur, groupe habilitations) EXTBATCH Paramètre modifiable par utilisateur permettant d’autoriser ou non le lancement de tâches par un processus externe. (chapitre superviseur, groupe habilitations), DEMSRV Paramètre modifiable par utilisateur permettant d’activer le serveur batch à sa première connexion. (chapitre superviseur, groupe Performance)


Sage 2011


Page 29


5.2. PRINCIPES DE FONCTIONNEMENT Le serveur batch fonctionne par "polling" c’est-à-dire en interrogeant périodiquement la table des requêtes « ABATRQT ». 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.

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. Depuis la fonction de surveillance des requêtes à l’aide d’un clic droit sur le tableau des requêtes Exploitation > Serveur batch > Gestion des requêtes. En déposant un fichier dans un répertoire du serveur de traitement, à l’aide d’un automate externe (Pilote d’exploitation). Par le biais d'un abonnement, c'est à dire une requête à lancer périodiquement. Exploitation > Serveur batch > Gestion des abonnements. Note technique : Polling : Examen répété de l'état d'un ou plusieurs éléments d'un système pour y détecter un changement d’état éventuel.


Sage 2011


Page 30


5.2.1. Définition d’une tâche Une tâche est définie en spécifiant une fonction, un traitement Sage X3, un shellscript (sous UNIX™) ou un script (Windows™).

Exploitation > Serveur batch > Gestion des tâches

Code tâche :

Code identifiant le processus qui sera activé par le serveur batch. A un instant T une seule tache ayant ce code peut être active. Ce témoin doit être à Oui pour que la tâche soit exécutée. Une tâche doit être rattachée à un module. Traitement c’est un processus écrit dans le langage X3, sinon ce peut être un script écrit dans le langage de la plate forme du serveur de traitement. Durée en minutes au-delà de laquelle le serveur batch interrompra la tâche. Si la tâche n’a pas pu être lancée au-delà de ce délai, elle ne sera pas

Actif : Module : Type tâche :

Time-out : Retard admissible : exécutée. Niveau autorisation : Niveau minimal que doit avoir l'utilisateur pour lancer la tâche (paramétrage utilisateur)

Priorité : Paramètre transmis au système d’exploitation Service : Numéro de service (par défaut c’est le service adonix) Contraintes horaires : Identifiant de la contrainte horaire à utiliser pour activer la tâche Fonction : Code de la fonction X3 correspondant au traitement à activer Traitement : Code du Shellscript ou du .bat à activer dans le cas ou le type de tâche est un script. Multi-dossiers : Si ce témoin est à Oui, la tâche est utilisable pour des traitements réalisés sur les données de différents dossiers X3 de la solution. Mono Utilisateur : Si ce témoin est à Oui, la tâche est activée que si aucun processus batch ou transactionnel n’est actif sur le dossier. Message Utilisateur : Si ce témoin est à Oui, un avertissement sera envoyé à l’utilisateur à la fin de l’exécution de la tâche.

Notes techniques


Sage 2011


Page 31


Un processus x3 peut être exploité à l’aide d’une tache batch si : Il ne gère pas pendant l’exécution du processus un dialogue utilisateur L’action associée à la fonction X3 exécutée est marquée comme étant autorisée à être exploitée en mode batch. Ce point est vu dans le cours développement. Un processus exploité en mode batch génère automatiquement une trace. Une tâche est identifiée dans X3 par son code, vu du système d’exploitation son identifiant est son PID (Processus Identification). L’activation d’une tâche liée à une fonction X3 provoque l’ouverture d’une session X3 avec entre autre l’initialisation des variables globales liées au couple dossier utilisateur.

5.2.2. Définition d’un groupe de tâches Un groupe de tâche est une suite de tâches exécutées en séquence. Cette suite est activée en une fois (soit par soumission du groupe, soit par abonnement). Les tâches du groupe sont exécutées séquentiellement dans le temps (chaque tâche s'exécute lorsque la précédente se termine) en créant chacune leur propre trace. L’enchaînement de la tache suivante est effectif à la condition que la tâche précédente se termine sans erreur. Exploitation > Serveur batch > Groupe de tâches

Niveau d’autorisation : Niveau minimal que doit avoir l'utilisateur pour lancer le groupe de tâches (paramètre utilisateur) Contrainte horaires : Table définissant les horaires admissibles Code tâches : Liste des tâches à enchaîner Remarque : A la saisie d’une requête sur le groupe, tous les paramètres des tâches liées sont saisis. 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).


Sage 2011


Page 32


5.2.3. Soumission d’une requête La soumission d’une requête se fait par la 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 par la saisie des paramètres de la fenêtre de validation

Exploitation > Serveur batch > Soumission des requetes

Remarque : Le dossier par défaut est le dossier courant. Il peut s’agir d’un autre dossier à condition que la tâche soit cochée Multi-dossiers. Si le code utilisateur n’est pas celui de l’utilisateur courant, la saisie du mot de passe est obligatoire. La case à cocher Modèle permet de créer un fichier modèle pouvant ensuite être utilisé pour une soumission de tâches. Dans ce cas, la tâche n’est pas exécutée. Ce fichier modèle s’appelle MATACHE.mod (MATACHE étant le code de la tâche).


Sage 2011


Page 33


5.2.4. Contraintes horaires & calendrier Les transactions suivantes sont à mettre en œuvre si l’on désire planifier les processus d’exploitation des Traitements batch. Ce paramétrage est utilisable par l’ensemble des processus batch quelque soit le dossier X3 contenant les données exploitées. Ce paramétrage est à utiliser si l’on met en place des abonnements de tâche ou groupe de tâches. Les contraintes horaires permettent de définir les jours de la semaine et les horaires admissibles pour lancer le batch associé à une tâche ou à un groupe de tâches. Paramétrage > Exploitation > Serveur batch > Contraintes horaires

Le calendrier est une table contenant les dates des jours fériés. Pour ces dates les processus batch ne seront pas activés.

Remarque : Deux types de jours : ouvrés et non ouvrés / fériés, chacun avec des plages horaires possibles Seule l’heure de lancement définie est contrôlée. Si la tâche ne peut pas être lancée à l’heure prévue et peut l’être dans une plage horaire qui n’est plus la bonne. Pour éviter qu’une tâche soit lancée dans une plage horaire inadéquate, il faudra utiliser le paramètre définissant le retard admissible. Sage ERP X3 - Outils avancés

Sage 2011


Page 34


5.2.5. Les abonnements Cette fonction permet de définir un traitement périodique qui sera activé par le serveur batch en fonction des paramètres de l’abonnement. Exploitation > Serveur batch > Gestion des abonnements Code dossier : Code utilisateur : Groupe: Tâche : Périodicité : Hebdomadaire : Mensuel :

Jours exclus :

Code du dossier X3 sur lequel les données seront exploitées. Code de l’utilisateur X3 pour le compte duquel le traitement sera effectué Code du groupe de tâches ou Code de la tâche. Type de périodicité attribué à l’abonnement dans ce cas on indique dans le tableau les jours de la semaine pour lesquels le traitement sera à exécuter dans ce cas on indique les quantièmes du mois pour lesquels le traitement sera exécuter. Le témoin fin de mois permet d’activer le traitement le dernier jour du mois. Code du calendrier à utiliser pour déterminer les jours ouvrés.

Si la tâche doit être activée de manière répétitive il faut renseigner : Heure de début : & Heure de fin : & Fréquence :

Heure de lancement de la première exécution de la tâche

Une seule requête :

Cette case peut être cochée si l'abonnement est défini en fréquence. Si elle est cochée, une seule requête est lancée par jour et dès que le traitement est terminé, la tâche se met en veille pendant le nombre de minutes définies par la fréquence, pour reprendre ensuite son exécution, ce jusqu'à ce que l'heure de fin soit dépassée. La requête est alors affichée dans l'état En cours pendant tout l'intervalle d'exécution. On garantit ainsi que la requête est toujours présente en mémoire une fois qu'elle aura été lancée, ce qui peut être au détriment d'autres tâches si le nombre maximum de tâches lancées simultanément est atteint.

Epuration :

Cette case ne peut être cochée que pour un abonnement défini en fréquence. Dans ce cas, on ne garde pas trace des exécutions successives de la tâche dans la fonction de gestion des requêtes. Seule la requête en cours et la précédente requête sont conservées.

Heure de lancement de la dernière exécution de la tâche Fréquence de lancement du traitement en minutes

Sinon, la tache peut être activée trois fois au maximum à heure fixe et il faut renseigner Heure :

Heure d’activation de la tâche

Exécution forcée

Cet indicateur ne peut être coché que si l'on donne des heures fixes d'exécution pour un abonnement. Il garantit la création de la demande d'exécution même si l'heure est dépassée au moment où le serveur batch traite les abonnements de la journée.

Remarque, un groupe de taches ne peut pas être répétitif.


Sage 2011


Page 35


5.3. SURVEILLANCE DES TACHES La gestion des requêtes permet de surveiller les requêtes en attente, les tâches en cours d'exécution ou terminées, voir de les modifier. Il est possible de 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. Exploitation > Serveur batch > Gestion des requêtes

Remarque : Fonctions accessibles par clic droit : -

-

Supprimer la requête, Cette action permet de supprimer une requête en attente. Modifier la date et l’heure de lancement, ainsi que les paramètres sur des tâches non encore lancées. Consulter la trace des tâches en cours, avortées ou terminées. 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) 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 ces requêtes ou uniquement à celles qui lui appartiennent. Pour chaque requête les informations du tableau importantes sont : Numéro : Dossier : Util : Mono : Etat : -

C’est le compteur des requêtes X3. Chaque requête se voit attribué un numéro i ncrémenté séquentiellement par pas de un. Code du dossier X3 sur lequel le traitement est exécuté Code de l’utilisateur X3 lié à la session batch du traitement Indicateur précisant si la tache est déclarée mono utilisateur Statut de la requête

Attente : le traitement n’a pas encore démarré Encours : le traitement est en cours d’exécution Terminé : le traitement est terminé sans erreur Erreur : le traitement est terminé avec des erreurs Aborté : le traitement a été interrompu soit volontairement soit à cause d’une erreur non récupérable.


Sage 2011


Page 36


N° Processus : C’est l’identifiant du traitement vu du système d’exploitation (PID) Structure du fichier log du serveur batch Le serveur batch possède une trace dédiée dans laquelle figure pour chaque processus activé: La date et l’heure de démarrage Le code du dossier sur lequel s’applique le processus Le PID (Processus Identification Windows) Le Numéro du processus X3 Le code de la fonction X3 correspondant au traitement Validation des factures d’achat (FUNPIH) Calcul des pyramides (PYRAMID) etc.. Le serveur batch possède une trace dédiée dans laquelle figure pour chaque processus terminé lLa date et l’heure de fin du traitement, le numéro du processus X3 et le code retour de la fonction X3

Exemple =1000 00000004 07/11/07 12:27:46 Activation requête (DEMOFRA ACCBATCH T BATCHCPT 5600) (51000) >2000 00000004 07/11/07 12:31:03 Requête interrompue par ADMIN pour le motif "RLV" (DEMOFRA ACCBATCH T BATCHCPT) (32000) =6000 00000000 07/11/07 12:38:10 ADMIN : Ordre d'arrêt transmis au serveur (56000) =5000 00000000 07/11/07 12:38:11 Désactivation du serveur (55000) =0000 00000000 07/11/07 12:38:36 Activation du serveur (PID=4048 ,USR=ADMIN ,SRV=1801) (50000) =0000 00000000 07/11/07 12:38:41 Le serveur est activé \ Processus numéro 4048 (50000) <1000 00000005 07/11/07 13:00:25 Délai dépassé (DEMOFRA FUNPIH T ) (21000) =1000 00000006 07/11/07 13:09:40 Activation requête (DEMOFRA FUNPIH T 5888) (51000) =1000 00000007 07/11/07 13:10:49 Activation requête (DEMOFRA ACCBATCH T BATCHCPT 5872) (51000)

Le caractère en première position de chaque ligne peut être utilisé comme filtre pour rechercher les erreurs. Il faut filtrer les lignes qui débutent par le caractère inférieur.


Sage 2011


Page 37


5.4. SOUMISSION DE TACHE PAR FICHIER La soumission de tâche par fichier permet le déclenchement de tâches X3 par des processus externes. Ce mécanisme est à mettre en œuvre si l’on désire que l’activation des processus batch X3 soit pilotée par un superviseur d’exploitation ou si l’on désire synchroniser un processus externe avec un traitement X3. Par exemple activer un import X3 après l’extraction des données d’une application partenaire. Pour activer cette fonctionnalité le paramètre superviseur EXTBATCH du chapitre habilitation (AUZ) doit être positionné à Oui. De plus il faut définir les répertoires de communication avec le serveur batch Paramétrage / Exploitation / Paramètres du serveur batch

Principe de fonctionnement

La présence d’un fichier XXXX.job permet au serveur batch d’identifier un processus à activer. Le fichier XXXX présent dans le répertoire job contient les codes et valeurs des paramètres nécessaires à la soumission de la requête. Dès que le serveur batch à pris en compte ce type de demande un fichier de même nom que le fichier job est créé dans le répertoire req, ici XXXX.req Le processus peut être en attente.


Sage 2011


Page 38


Dès que le traitement devient actif, un fichier XXXX.run est créé dans le répertoire run. Le fichier XXXX.req est copié dans le répertoire old pour conserver les paramètres de la demande de traitement. Lorsque le processus est terminé un fichier XXXX.sta est créé dans le répertoire sta. Ce dernier contient entre autre le statut de fin du traitement.

Remarque : Si des erreurs sont détectées dans les paramètres de lancement de la tâche (exemple : utilisateur incorrect), 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 d’être exécutée. 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=20030929 HEURE=0752 CODSTA=CA DATDEB=19990601 DATFIN=20030930 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.

Sage 2011


Page 39


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) Note : date/heure correspond à AAAAMMJJhhmmss Remarque : Consulter la documentation technique détaillée (RQT_FILE.htm).


Sage 2011


Page 40


5.5. PARAMETRES DU SERVEUR BATCH Paramétrage > Exploitation > Serveur batch >Paramètres serveur batch

Temps entre 2 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. Influe sur le temps d'arrêt d'une tâche trop longue. La scrutation time-out est consommatrice de ressources. Nombre maximum de requêtes actives : Le nombre maximum de requêtes simultanées dépend de la licence Sage X3. Utilisation des fichiers batchs : Si cette case est cochée, il sera possible de lancer des tâches par la création de fichiers dans un répertoire dédié. Ceci suppose que les utilisateurs aient le paramètre EXTBATCH égal à Oui. Listes des répertoires avec les extensions (.job … .old) :Définit les différents répertoires utilisés pour la gestion des requêtes soumis par fichier. Ces répertoires sont supposés être par défaut sur le serveur d’application (un autre serveur du réseau est envisageable, avec la syntaxe serveur@répertoire, mais en aucun cas un répertoire sur le poste client).


Sage 2011


Page 41


5.6. NOTES TECHNIQUES Les fichiers stratégiques du serveur batch Ils sont situés sur le serveur d’application au niveau du répertoire …\Runtime\SERVX3/FIL : la présence d’un fichier .run indique normalement que le serveur est en fonctionnement 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) et au niveau du répertoire SERVX3/TRA : le fichier serveur.tra contient la trace du serveur les fichiers RQTnnnnnnnn.tra contiennent la trace des tâches Les traces des requêtes sont purgées avec le bouton Epuration de la fonction de consultation des requêtes. Les tables du serveur batch Table ABATABT ABATABTD ABATCAL ABATGRP ABATPAR ABATRQT ABATTAC ADOSSIER

[ABA] [ABD] [ABC] [ABG] [ABP] [ABR] [ABT] [ADS]

Intitulé de la table Définition des abonnements Paramètres des abonnements Calendrier du serveur batch Définition des groupes de tâches Paramètres du serveur batch Table des requêtes batch Définition des tâches Table des dossiers

Epuration des requêtes et des traces Dans le répertoire …\Runtime\ServX3\TRA on trouve les fichiers trace des requêtes exécutées par le serveur batch. Ces traces sont épurées lors de l’activation du bouton Epuration présent dans la fenêtre de la fonction de gestion des requêtes.


Sage 2011


Page 42


Les points d’entrée Point d’entré REQUETE

Traitement SERVEUR

SETREQ

SERVJOB

Objet Permet de compléter les paramètres au démarrage d'une tâche abonnée ou d’empêcher son démarrage. Le point d’entrée REQUETE est appelé avant chaque écriture sur la table ABATRQT. La classe [F:ABR] est en ligne. La variable GPE permet, si elle est différente de 0, de ne pas créer l’enregistrement. Le contenu de l’enregistrement ABATRQT est significatif Ce point d’entré permet de récupérer le numéro de requête pour synchroniser des processus. Le contenu de la table ABATRQT n’est pas significatif. Ce point d'entrée SETREQ est positionné dans le traitement SERVJOB après la création de la requête dans la table ABATRQT. Toutes les variables globales de l'application ne sont pas encore définies. Le nom de la trace du serveur batch est contenu dans la variable FICTRA et il est possible d'écrire dans cette trace en utilisant le sousprogramme STRACE du traitement SERVEUR. Les arguments de ce sous-programme sont dans l'ordre :

FICTRA (Alpha), Numéro d'erreur (Integer), Numéro de requête (Integer), Commentaires (Alpha).

FINREQ

ERRREQ

FICTRA contient le nom de la trace ouverte JOB contient le nom du fichier job APPLI contient le nom de l'application sur laquelle la requête est créée REQUETES Ce point d'entrée FINREQ est placé après l'exécution d'une tâche batch, si la requête n'a pas été interrompue volontairement ou par le serveur batch. Il est positionné dans le traitement REQUETES juste après la mise à jour du flag de la requête et avant le déclenchement des autres requêtes du même groupe. Si dans la tâche batch, une trace n'a pas été ouverte, la trace ouverte courante est dans le fichier "RQT"_numéro_requête.tra. du répertoire TRA du serveur batch FICTRQ contient le nom de la trace ouverte GERRTRACE contient le nombre d'erreurs dans la trace OKRQT contient le GOK éventuellement gérée dans la tâche. REQUETES Le point d'entrée ERRREQ est placé dans les sous-programmes de gestion des erreurs du traitement REQUETES. Il permet de récupérer la main suite à un abort de la tâche pour permettre en autre d’envoyer une alerte au processus externe qui à activer la tâche via un fichier job. Ce point d'entrée permet de gérer une gestion plus fine des erreurs. FICTRQ contient le nom de la trace ouverte GERRTRACE contient le nombre d'erreurs dans la trace OKRQT contient le GOK éventuellement gérée dans la tâche


Sage 2011


Page 43


5.7. LA TACHE BATCH COMPTABLE La tâche comptable est un cas particulier de tâche batch : - elle a pour code ACCBATCH et doit être lancée en permanence dans chaque dossier d'exploitation de la solution X3 entreprise - 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 Exploitation > Serveur batch > Tache comptabilité

Remarque : Les écritures automatiques de la comptabilité sont également passées par cette tâche. Seules les écritures saisies directement (OD) sont enregistrées directement. Pour consulter les écritures comptables réalisées par les modules partenaires, utiliser le bouton trace. Le lancement de cette tâche peut être abonné (ACCBAT) Son arrêt peut être aussi abonné (ACCSTOP)


Sage 2011


Page 44


Fonctionnement de la tâche comptable

Les écritures automatiques de la comptabilité sont également passées par cette tâche. Seules les écritures saisies directement (OD) sont enregistrées directement. Tables associées Table GACCTMP GACCTMPD GACCTMPA MTCBATCH GACCENTRY GACCENTRYD GACCENTRYA GACCDUDATE BALANCE BALANA BATCH

Intitulé de la table Entête des pièces comptables temporaires *2 Lignes des pièces comptables temporaires Lignes analytiques des pièces comptables temporaires Lettrage temporaire *2

Entête des pièces comptables définitives Lignes des pièces comptables Lignes analytiques des pièces comptables Echéances Balances Balances analytiques Mémorisation du statut de la tache comptable *1

*1 La table BATCH mémorise le statut de la tache comptable batch. Suite à un arrêt du serveur ou un incident du même type. Cette tâche peut être dans un état instable ne permettant pas son redémarrage. Il faut alors intervenir sur cette table avec les outils de maintenance pour réinitialiser dans l’enregistrement ACCENTRY les champs PID, RQT et STA


Sage 2011


Page 45


*2 Dans les tables GACCTMP & MTCBATCH un champ identifie les pièces qui n’on pas été prise en compte suite à une erreur lors de la création des pièces définitives (problème de paramétrage des pièces automatiques par exemple) Traces La trace des pièces comptables est dans le fichier ACCENTRY.tra dans le répertoire TRA du dossier. Une trace VALPIECE.TRA contient les références des pièces en anomalie.


Sage 2011


Page 46


6. GESTION DES ETATS Ce chapitre présente les opérations permettant de mettre en production des états dans le contexte de Sage X3. Il se limite à la présentation des principes de fonctionnement des éditions, aux techniques de passage des paramètres d’édition de l’environnement de l’utilisateur X3 à celui des outils d’édition, aux mécanismes possible d’automatisation de la production des éditions et enfin il présente une aide au diagnostic des incidents. -

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

6.1. PRINCIPES DE BASE Les états sont : Définis à l’aide du générateur d’états « Crystal Reports ™». (fichiers d’extension .rpt ). Actuellement c’est la version V10 de ce logiciel qui est supportée dans le contexte X3. 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ées, outre des composants SAGE X3, les librairies Crystal Reports idoines. Les éditions relatives aux données de l’application sont gérées avec le logiciel tiers « Crystal Reports ™». La fonction « Impression » déclenche l’édition d’un état (standard ou personnalisé) du progiciel en deux étapes : La saisie de valeurs de critères Le lancement du module d’édition (DLL Crystal Reports ™).

6.1.1.1.

Notion de destination

Avec Sage X3, le terme destination désigne le support du résultat d’une édition. En effet Crystal Reports ™ permet d’adresser ce résultat soit à une imprimante physique soit à un convertisseur permettant de conserver ce résultat sous la forme d’un fichier PDF XLS ou Doc par exemple. Nous verrons dans la suite de ce chapitre les différents supports disponibles et le paramétrage nécessaire à chaque cas.


Sage 2011


Page 47


6.2. LE DICTIONNAIRE DES ETATS Le rôle du dictionnaire des états est de faire le lien avec le programme Crystal Reports ™, contenu dans un fichier rpt et X3. C’est une fonction située dans les outils de développement Il est donc nécessaire, lorsqu’on produit de nouveaux états : De respecter des règles de nommage (noms commençant par X, Y, ou Z) De marquer dans le dictionnaire X3 ces états par un code activité spécifique De même, il faut, si on modifie des états standards : Renommer les fichiers Crystal Reports ™ d’extension .rpt Modifier la fiche de l’état pour le faire pointer sur l’état modifié Certains champs 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 seuls ces champs sont modifiés Pour pouvoir déclarer un nouvel état dans le dictionnaire X3, la présence du fichier programme .rpt est nécessaire dans le répertoire REPORT. Dans le cas d’un dossier multi langues les répertoires des fichiers .rpt sont organisés de la manière suivante :

Dans chaque dossier X3 de la solution on trouve un répertoire REPORT. Dans ce répertoire un sous répertoire est créé par code langue utilisé dans le dossier X3. Les fichiers Crystal Reports ™ sont à déposer dans les répertoires correspondants à la version de la langue pour laquelle l’état est produit.

6.2.1.1.

Le dictionnaire des états : premier onglet

Développement > Dictionnaire des traitements > Etats


Sage 2011


Page 48


Actif :

Témoin permettant d’utiliser un état si cette valeur est à Oui

Intitulé court : Désignation de l’état utilisée dans les fenêtres de sélection proposée aux utilisateurs dans le cas ou un choix est possible Module :

Code du module X3 auquel l’état est rattaché.

Groupe :

Code du groupe de rattachement de l’état permettant de gérer des habilitations. Les groupes dont déclarés dans le Menu local 97 qui est personnalisable.

Muti langues : Si cette case est cochée, cela indique que l'état a été généré dans toutes les langues gérées par le dossier, sinon l'état est uniquement dans la langue de conception Langue origine : Cette zone permet de réserver l'état à une langue. La langue dans laquelle à été conçu l'état.


Sage 2011


Page 49


6.2.1.2.

Bloc Caractéristiques de la sortie

Ce bloc permet de définir le support sur lequel l’édition est exploitée après sa production par le moteur Crystal Report. Type : Le type sert à déterminer une destination dans le cas ou la formule complément et la destination ne sont pas renseignées. Au lancement de l'impression, le superviseur détermine la destination en fonction de la valeur de ce paramètre superviseur.

Normal : Fax : Thermique : Couleur :

paramètre PRT1 paramètre PRT2 paramètre PRT3 paramètre PRT4

Ces paramètres sont déclarés dans le chapitre superviseur Groupe impression IMP. Ils contiennent une valeur définissant une destination d’impression. Destination : Contient le code de la destination d’impression à utiliser pour produire l’édition. Ce code doit être déclaré dans le dictionnaire des destinations. Obligatoire : Si cette case est cochée, l’utilisateur ne peut pas modifier la destination au lancement de l'impression de l'état. Formule complément : Ce champ sert à la recherche d'une destination par utilisateur et par état. Cette destination, si elle est trouvée, sera prioritaire par rapport à celle précisée au-dessus. Cette formule est évaluée au lancement de l’impression. Exemple: Si pour l'état X, on a défini un complément avec la valeur "PAR" correspondant à l'imprimante Y et que la formule de l'état X contient l'expression "PARAM(site)", alors, au moment d'imprimer l'état, si le paramètre "site" est égal à PAR, l'imprimante sera initialisée à Y. Non exécutable : Ce champ permet d’interdire l’utilisation de l’état directement à partir du menu impression de l’utilisateur. Il permet de laisser l’état disponible pour d’autres contextes. Batch obligatoire

: Ce témoin permet de réserver l’utilisation de l’état aux processus batch.

Contraintes horaires : Code d’une contrainte horaire batch. Voir le chapitre sur le serveur batch.

6.2.1.3.

Bloc Crystal Report

Ce bloc permet d’identifier les fichiers programmes Crystal Reports ™ à associer au code état X3. On peut associer de un à cinq états à un même code X3. Ces éditions seront exécutées l’une après l’autre dans des fichiers séparés. Pour pouvoir regrouper plusieurs états Crystal Reports ™, la valeur d’un même paramètre doit être identique au moment du lancement. Le traitement d'initialisation est exécuté pour chaque état de ce tableau Nom état :

Nom du fichier programme Crystal Reports ™ sans son extension rpt.

Orientation :

Format de l’édition portrait ou paysage. Cette information doit être en cohérence avec celle saisie sur l'état Crystal Report ™.


Sage 2011


Page 50


6.2.1.4.

Bloc Traitements

Ce bloc permet de déclarer les traitements qui seront exécutés après la saisie des paramètres et avant l’activation des programmes Crystal Report ™. Traitement standard Nom du traitement standard X3. Il permet d'initialiser des variables définies dans le paramétrage de l'état ou éventuellement de préparer des fichiers avant l'impression, ou même de mettre à jour des champs dans la base de données (ex: flag d'édition). Un traitement est réservé au développement standard, et l'autre aux spécifiques

6.2.1.5.

Bloc autorisations

Ce bloc contient de fixer des restrictions à l’utilisation de l’état. Autorisation site : Ce témoin permet d’indiquer que le code site est un critère de définition du droit d’usage de l’état. Si ce témoin est positionné à Oui, il faut indiquer le code de la fonction à utiliser pour vérifier les droits de l’utilisateur. Code d'accès : Ce code d'accès permet l'autorisation ou l'interdiction d'exécution de l'état par un utilisateur. Remarque : 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’utilisateur 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.


Sage 2011


Page 51


6.2.1.6.

Onglet Paramètres

Cet onglet contient le tableau des paramètres qui seront envoyés au programme Crystal Report ™. Ce tableau peut contenir un maximum de 100 paramètres.

Pour chaque paramètre on définit Paramètre

La valeur de ce code est transmise à Crystal Report. Une fenêtre de sélection permet de proposer l'ensemble des paramètres déjà existants dans les états du dictionnaire X3. Pour une même notion, il est donc conseiller de réutiliser les mêmes noms de paramètre. Convention pour les paramètres exprimant une borne début et fin : Ne saisir que la borne de début. Son code doit se terminer par le suffixe « deb » ou « str ». Le paramètre pour la borne de fin est généré avec la même racine que la borne début et le suffixe « fin » ou « end ». Il n'apparaît pas dans le tableau mais est passé à Crystal Report.

Intitulé paramètre

Destiné notamment à figurer sur les états et les écrans dans lesquels le code de la fiche peut être saisi ou sélectionné. Ce texte permet de donner une description en clair du paramètre.

Type :

Ce champ défini le format du paramètre. Les principaux types génériques sont A: Alphanumérique C: Entier court L: Entier long DCB : Décimal D: Date M: Menu local D'autres types peuvent être utilisés, basés sur le dictionnaire des types des données. La touche fonction F12 permet d'en obtenir la liste.

Longueur

Permet de définir la longueur d'un champ lorsque ce champ utilise un type de données générique dont la longueur n'est pas fixée par le dictionnaire des types de données.

Menu

Définit le numéro de menu local associée au champ défini sur la ligne.

D/F

Ce témoin indique s'il faut saisir une fourchette de valeur. Le paramètre est donc suffixé par « deb » ou « str ».

Sai l'état.

Ce témoin indique si le paramètre est saisissable ou pas au lancement de

Valeur par défaut (début) Cette zone contient la valeur par défaut du paramètre. Il est possible de saisir une expression qui sera évaluée avant la saisie pour initialiser cette valeur. Valeur par défaut (fin) Contrôle

Cette zone contient la valeur par défaut de fin du paramètre. Cette zone contient une règle de contrôle de la saisie de la valeur du paramètre. Il est possible de saisir une formule pour contrôler la saisie de ce paramètre. La variable VALEUR représente la valeur saisie du paramètre.


Sage 2011


Page 52


Table de contrôle

Une table de contrôle peut être utilisée pour vérifier la valeur du paramètre saisie. Dans ce cas c’est la référence de cette table de contrôle qui figure dans ce champ.

Paramètre objet/dépendance Permet de définir le premier élément de clé d'un objet, si cet objet a une clé à deux composantes. Exemple : n° table pour une table diverse. Particularité pour une table diverse dépendante : ce champ permet de saisir l'élément maître de la table diverse "maître"; dans ce cas, le numéro de la table diverse est à saisir dans la colonne "menu". Options Saisissable si le type de donnée est lié à un objet. Ce champ permet de définir une ou plusieurs options de filtre définies dans l'objet. Le superviseur contrôle la valeur saisie dans le paramètre en fonction des filtres positionnés. De même, la fenêtre de sélection, tient compte des filtres. Paramètre de segmentation Cette zone contient un argument permettant de découper une édition. Cette information doit être une donnée importante de l’édition. Par exemple le code société ou le code site. Cette possibilité de segmentation est à mettre en œuvre pour les éditions volumineuses contenant plusieurs dizaines de milliers de pages.

6.2.1.7. Intitulé

Dossier par Table

Onglet Données

Si l'état s'appuie sur au moins une table d'un autre dossier, on aura l'obligation d'indiquer la source de données liée à chaque dossier supplémentaire sous la forme « solution;dossier ». Il faut que le dossier soit un dossier lié dans la gestion dossier. Le nombre de sources de données est limité à 5. Le dossier saisi n'est, en fait, qu'une valeur par défaut, puisque la source est modifiable au lancement de l'impression. Si la solution n'est pas indiquée, le superviseur prend la solution courante; il en est de même pour le dossier. Pour atteindre les tables du dossier mère, on peut utiliser la variable GDOSX3, disponible pour tout produit. Pour atteindre les tables du dossier d'exploitation X3, depuis un autre produit (géode GX, Abel X3, Paie), les variables GSOLCPT et GDOSCPT contiennent respectivement la solution et le dossier X3. Tables associées à l'une des sources de donnée ci-dessus pour accéder à un autre dossier. Une limite de 10 tables est à respecter. Le nom d'une table est limité à 200 caractères.

Intitulé Numéro numéro identifiant l'une des sources de données du tableau ci-dessus. Source de données Destiné notamment à figurer sur les états et les écrans dans lesquels le code de la fiche peut être saisi ou sélectionné. Ce texte permet de donner une description en clair de la fiche concernée.

Si l'état s'appuie sur au moins une table d'un autre dossier, on aura l'obligation d'indiquer la source de données liée à chaque dossier supplémentaire sous la forme « solution;dossier ». Il faut que le dossier soit un dossier lié dans la gestion dossier. Le nombre de sources de données est limité à 5. Le dossier saisi n'est, en fait, qu'une valeur par défaut, puisque la source est modifiable au lancement de l'impression. Si la solution n'est pas indiquée, le superviseur prend la solution courante; il en est de même pour le dossier. Pour atteindre les tables du dossier mère, on peut utiliser la variable GDOSX3, disponible pour tout produit. Pour atteindre les tables du dossier d'exploitation X3, depuis un autre produit (géode GX, Abel X3, Paie), les variables GSOLCPT et GDOSCPT contiennent respectivement la solution et le dossier X3.


Sage 2011


Page 53


Ensuite, on indiquera pour chaque source de données, les tables utilisées dans l'état. Si une table n'est pas référencée, elle sera automatiquement associée à la source de donnée du dossier courant. De ce fait, les tables du dossier courant n'ont pas à être référencées ici. Le nom de la table doit être celui utilisé dans Crystal ; cela peut être le nom de pseudonyme, s’il en existe dans Crystal. Une limite à 10 tables est à respecter ici, limite due le serveur d’impression. Le nom d'une table est limité à 200 caractères.


Sage 2011


Page 54


6.3. LANCEMENT D’UN ETAT L’activation d’un état est réalisée par plusieurs méthodes : Par l’entrée de la barre de menu Fichier / Impression (ou Fichier / Liste) on lance alors un état prédéfini (éventuellement une liste). Par la fonction Impressions / Impressions On visualise alors l’ensemble des états dans la liste gauche et on choisit celui qui doit être lancé en saisissant les critères de sélection. Par la fonction Impressions / Impression groupe / xxxx / yyyy On choisit alors un état dans une liste d’états rattachés à un groupe (équivalent à un module), puis un sous-groupe. Depuis le dictionnaire des états via le bouton Impression On doit alors saisir : Les critères d’édition de l’état : Soit ce sont des éléments simples de type numérique, alphanumérique, date ou menu local Soit ce sont des bornes : valeur de début et valeur de fin Exceptionnellement, sous forme d’une liste de valeurs (pour segmenter l’état selon des bornes) La destination de l’état : Soit par un code destination défini dans une table avec la possibilité d’avoir une destination par défaut en fonction du contexte Soit par des paramètres tels le type de sortie (pré-visualisation, Imprimante, Message, Fichier, Imprimante/fichier) Imprimante (sélection par une fenêtre Windows), Serveur pour une impression via un serveur d’impression Les caractéristiques d’impression (Orientation, copies, bornes de pages… La langue est saisie pour les états multilingues)

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


Sage 2011


Page 55


6.3.1. Lancement d’un état : cinématique

A partir d’une fonction X3 on détermine le code état après une première étape qui utilise la notion de code interne d’un état. Cette notion permet de regrouper plusieurs codes état du dictionnaire sous un même code Par exemple l’impression de la fiche d’un bon de livraison offre en standard les choix suivants

L’utilisateur après la sélection d’un code état dans la liste se retrouve dans le contexte du lancement de l’état sélectionné. Si le code impression ne propose qu’une seule solution, l’utilisateur se retrouve sur la fiche de lancement de l’état. 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)


Sage 2011


Page 56


6.3.2. Résultat de l’édition sous Crystal Reports Lorsque l’impression est lancée en mode local, l’icône

signale que l’édition est en cours.

Lors d’une prévisualisation, une fenêtre Crystal s’ouvre.

Il est alors possible : Visualiser les pages au fur et à mesure Parcourir des groupes de données sur le volet de gauche (selon les ruptures de l’état) Envoyer le résultat dans un message Exporter dans un fichier (formats PDF, HTML, Excel, Word…) Rediriger le résultat vers une imprimante

6.3.3. Mémorisation des paramètres La plupart des états disposent d’un grand nombre de paramètres. Ainsi, par exemple, l’état Grandlivre comptable peut être édité en fonction de la combinaison de multiples critères de sélection (écritures lettrées, non lettrées, de simulation…), tri variable, bornes (sites/sociétés, dates, comptes), des paramètres complémentaires (devise d’impression, détail des à-nouveaux), des cumuls optionnels… Pour cette raison, il est intéressant de disposer d’un couple « code état » et « paramètres » que l’on obtient grâce au « mémo ».


Sage 2011


Page 57


6.3.4. Surveillance de l’impression Un double clic sur l’icône animée

permet d’ouvrir la fenêtre suivante :

Cette fenêtre permet de visualiser les impressions en cours sur les différents serveurs d’édition, de les réordonner, voir de les supprimer.


Sage 2011


Page 58


6.4. AFFECTATION DES CODES INTERNES A DES ETATS Paramétrage > Destination > Codes impressions

Trois cas sont possibles : 1. Le code interne pointe sur plusieurs états du dictionnaire. Un choix sera proposé à l’utilisateur, exemple BONLIV. 2. Le code interne pointe sur un état unique, Pas de choix pour l’utilisateur. Exemple BOREMTRR 3. Dans la fiche de la fonction d’appel on définit directement le code de l’état et nom le code impression.

Remarque : 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 Lorsqu’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.


Sage 2011


Page 59


6.5. VALEURS PAR DEFAUT DES PARAMETRES D’ETATS Cette fonction permet de paramétrer la façon dans le contexte d’appel, d’alimenter les valeurs des paramètres d’impression. Par impression il faut entendre l'impression d'un état Crystal Reports, le lancement d'une requête, d'une requête SQL, ou d'un export. Paramétrage > Destinations > Valeurs par défaut

Pour paramétrer correctement des règles d’alimentation des valeurs paramètre d’un état, il faut se mettre dans le contexte de la fonction et vérifier le contenu des classes [M] . Celles-ci correspondent au contenu des onglets qui composent la fenêtre à partir de laquelle la demande d’impression sera activée. Des constantes et des variables globales peuvent êtres utilisées dans ce contexte. L’appel du code état alimente la colonne Paramètres.


Sage 2011


Page 60


6.6. GESTION DES DESTINATIONS D’IMPRESSION Cette fonction permet de définir les codes destination avec les valeurs des paramètres à utiliser pour produire les impressions. Paramétrage > Destinations > Destinations

Le progiciel permet d'envoyer un état vers un ensemble de destinations, en particulier vers toute imprimante Windows(TM) visible sur le réseau du poste client, mais aussi vers des fichiers ou d'autres destinations. Afin de faciliter le choix et l'affectation des destinations par défaut, il est possible - et recommandé - de centraliser la description de ces destinations accessibles globalement dans cette table. On retrouve dans cette table les destinations, identifiées par un code, avec des caractéristiques permettant d'en sophistiquer le processus de choix et d'affectation par défaut, et aussi de définir si un serveur d'édition Crystal Reports est utilisé plutôt qu'une utilisation de Crystal Reports(TM) en local. 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 TM classique d’une imprimante sous Windows 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

Format export

Lorsque la sortie se fait sur fichier, il existe différents formats possibles que l'on peut sélectionner ici. Cette liste de formats dépend de la version courante de Crystal Reports, elle est susceptible d'évoluer dans le temps.


Sage 2011


Page 61


Serveur

On peut définir le serveur d'impression à partir duquel sera imprimé l'état. Si cette zone est vide, l'impression sera réalisée localement sur le poste client.

Imprimante

Le nom d'imprimante défini ici sera proposé à l'impression de l'état. Il doit correspondre au chemin réseau de l'imprimante, tel qu'il est défini dans le panneau de configuration Windows.

Type

Ce champ permet d'affecter un type à la destination. Ce type, défini par le menu local 22, possède les caractéristiques suivantes :

-

le premier est un type passe-partout (tout état est susceptible d'être envoyé à des destinations de ce type).

-

les autres types permettent d'établir des catégories particulières (imprimantes code-barres, fax, etc.) qui ne peuvent être utilisées que par certains états. En effet, dans le dictionnaire des états, il est possible de définir un type de sortie dédié à un état en utilisant le même menu local. Là encore, si ce type n'est pas le premier, il doit y avoir correspondance entre le type affecté à l'état et le type de la destination utilisée.

Nombre de copies

Permet, lorsque la sortie se fait sur imprimante, de donner une valeur par défaut au nombre de copies à réaliser.

Copies assemblées

-

Si plusieurs copies sont demandées, et si la case est cochée, on assemble les pages avant d'éditer l'exemplaire suivant. Sinon, on répète chaque page. Par exemple, dans le cas d'une impression de 3 pages en deux exemplaires : si la case est cochée, on obtient l'ordre des pages 1, 2, 3, 1, 2, 3 si la case n'est pas cochée, on obtient l'ordre des pages 1, 1, 2, 2, 3, 3


Sage 2011


Page 62


6.6.1. Gestion des destinations par utilisateur Lorsqu'un utilisateur lance un état, des règles d'affectation permettent de définir la destination de sortie proposée par défaut. Ces règles peuvent être plus ou moins globales, mais elles peuvent être définies de façon très fine, en allant jusqu'au niveau de détail constitué par le triplet (code état, code utilisateur, plus un code complémentaire). La table des destinations par utilisateur définit les règles les plus fines d'affectation de destination par défaut. Les règles définies pour un utilisateur peuvent être utilisées par d'autres utilisateurs. En effet, un utilisateur peut être considéré comme utilisateur modèle du point de vue de l'affectation des états : un code utilisateur servant à définir les destinations par défaut existe à cette fin sur la fiche utilisateur (rubrique Destinations utilisateur). Paramétrage > Destinations > Destinations par utilisateur

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


Sage 2011


Page 63


6.6.2. Affectation des destinations

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 de l’état est respecté. 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 en premier 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. Si l’on ne trouve pas d’imprimante par défaut , 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é : - la première imprimante du bon type en mode batch est sélectionnée, - la première imprimante de type pré-visu en mode 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. Ceci suppose que le paramètre utilisateur WINIMP soit égal à Oui (sinon, ceci n’est pas possible).


Sage 2011


Page 64


6.7. SERVEURS D’EDITION Les serveurs d’éditions correspondent à des serveurs accessibles par le réseau sur lequel un run-time d’impression AdxSrvImp.exe et Crystal Reports ont été installés Les serveurs d’éditions sont définis par le biais de la console de configuration. Le serveur d’impression est normalement exécuté sous la forme d’un service Windows. Il permet - De gérer une file d’attente des demandes d’impression déposées par les fonctions X3 - De lancer plusieurs Editions Crystal Report en parallèle L’utilisation d’un serveur d’impression est nécessaire dans les cas suivants : - Editions lancées par un processus batch - Editions lourdes risquant de monopoliser les ressources du poste client dans le cas d’une exécution interactive

6.7.1. Fenêtre de surveillance X3 Pour afficher cette fenêtre, il faut se connecter avec un client lourd ou un navigateur Internet à un dossier Sage X3, et ouvrir la fonction « Impressions/Surveillance Impressions ». Une fois dans cette fonction, il suffit de renseigner le nom réseau du serveur d’édition qu’on souhaite surveiller (serveur:port), et les données relatives à ce serveur s’affichent automatiquement dans la fenêtre. Depuis cette fenêtre il est possible : - de visualiser les paramètres de démarrage du serveur (bloc Configuration) - de visualiser les sessions TCP/IP courantes (bloc Clients connectés) - de visualiser et éventuellement modifier les paramètres associés aux demandes empilées ou en cours d’exécution (bloc Tâche).


Sage 2011


Page 65


6.8. NOTES TECHNIQUES 6.8.1. Tables associées APRINTER AREPORT AREPORTD AREPORTS AREPORTV AREPORTX APRINTDES APRTAUS AREPORTM

[AIM] [ARP] [ARD] [ARO] [ARV] [ARX] [AID] [AIA] [ARM]

Définition des destinations Dictionnaire des Etats Paramètres des états Etats - Sources de données Valeurs des paramètres d’impressions Définition des codes impression Description imprimantes Destinations par utilisateur Table de travail standard pour les éditions

6.8.2. Points d’entré Traitement Point d’entré AIMP1 FIN

Objet Le point d’entrée FIN permet d’enchaîner plusieurs éditions en positionnant les variables GPE et ETAT. Le contenu de la table AREPORT est significatif.

## Exemple d'utilisation du point d'entrée du traitement AIMP1 $ACTION Case ACTION When "FIN" : Gosub FIN Endcase Return $FIN If [F:ARP]RPTCOD="ETAT1" : # ETAT1 on enchaîne sur ETAT2 GPE = 1 ETAT = "ETAT2" Endif

Return AIMP3

IMPRIME

AIMP3 AIMP3

PARAM REPORT

Ce point d’entrée est appelé juste avant le choix de l’imprimante. La seule chose qu’il est possible de faire est de positionner la variable GPE qui, si elle différente de 0, inhibe la saisie de l’imprimante. Permet de modifier la valeur d’un paramètre de l'état

Le point d’entrée permet de lancer un traitement après l'impression de l’état. Ce point d'entrée est exécuté juste après l'ordre d'impression envoyé au client (ou au serveur). Dans le cas d'une impression/fichier, il peut servir à lancer un traitement sur le fichier généré. Dans un contexte batch il permet de récupérer le n° de la demande d‘impression envoyée au serveur d’édition.


Sage 2011


Page 66


6.8.3. Le principe des es fichiers « reportjobstatus » Lors du lancement d’une demande d’édition à Crystal Report par l’instruction X3 Report, une variable numérique contient en retour de cette instruction un numéro de séquence. Ce numéro correspond au rang de la demande renvoyée par le serveur d’impression X3 AdxSrvImp.exe Lorsque l’édition est terminée (Le processus Crystal Report s’est arrêter) un fichier séquentiel est créé dans le répertoire ..\Temp du serveur d’impression. Ce fichier est nommé reportjobstatus.nnnn, avec nnnn=numéro de séquence reçu en retour de l’instruction Report. Si Crystal Report à terminé l’édition sans erreur ce fichier est vide, sinon il contient le(s) code(s) Erreur(s) généré(s) par le moteur Crystal Report.


Sage 2011


Page 67


6.9. ANALYSE DES PERFORMANCES DES EDITIONS CRYSTAL REPORT La production des états Crystal Report peut être longue et consommatrice de ressources. Ce paragraphe rappelle les points à contrôler si dans une configuration Sage X3 on observe ce type de problème.

6.9.1.1.

Mise en œuvre des statistiques :

Que ce soit avec une base Oracle ou SQL Server, la mise en place des statistiques sur les accès aux données est un pré requis. Il faut vérifier que ces statistiques sont calculées à une fréquence régulière. Le paramétrage à effectuer sur la base de données est vu lors de l’installation et expliqué dans le cours « installation »

6.9.1.2.

Analyse du serveur d’impression

Que ce soit directement à partir du moteur d’impression du poste client AdxImp.exe ou à partir d’un serveur d’impression AdxSrvImp.exe ce sont les même composants Crystal Report qui sont activés pour produire les éditions. En standard le serveur d’impression est déclaré sous la forme d’un service Windows. Celui-ci peut être désactivé et relancé en mode trace pour analyser les points de contentions. Pour cela il faut saisir le paramètre de démarrage /d

Ainsi configurer le serveur d’impression produit une trace dans le répertoire Windows nommée AdxSrvImp_Trace.Log. Cette trace contient entre autre :


Sage 2011


Page 68


- La version du serveur - Adonix® Edition Server full Path : e:\adonix\v140\AdxImp\AdxSrvImp.exe - File Version : 14i.006 -

Les paramètres reçus par le serveur pour exécuter l’édition _ExportFile=e:\temp\DICOX3.pdf _FormatExport=29 __REPORT=DICOX3.rpt __DESTINATION=3 __TYPDBA=1 __DBDATABASE=X3V14 __DBUSER=FIATIHF __DBPASSWORD=*** __WSTATION=DEMOADONIX __CDUSER=RLV __ADXSOL=X3V140 __APPLICATION=FIATIHF;AS504P.sagefr.adinternal.com;1840 __APPRPT=X3;AS504P.sagefr.adinternal.com;1840 __RPTLAN=FRA X3DOS=FIATIHF;AS504P.sagefr.adinternal.com;1840;140;FRA __REQUETE=37315 _PreVisuOptions=11111111111111111111 X3CLI=For programmer's usage X3EDT=Etat Adonix Copyright Adonix X3ETA=DICOX3 X3TIT=Dictionnaire des tables X3OPE=Raymond LE VAN X3USR=RLV X3LAN=FRA X3SIT1=* X3SIT2=z codficdeb=ATABLE codficfin=ATABLE impselection=0 trizones=0 tousmod=1 module=1

Les dates Heures démarrage et de fin du processus Crystal d’édition - [12/20 13:48:24:277] Activation Impression pour le JobId : 1 [1180-DICOX3.rptFIATIHF;AS504P.sagefr.adinternal.com;1840] - Ouverture rapport jobId 1 [1180-DICOX3.rpt-FIATIHF;AS504P.sagefr.adinternal.com;1840] OK. - Définition des options d'export. - Soumission du job 1 au Print Engine - [Start : 12/20 13:48:28:984] - Le job d'impression 1 est terminé - fermeture du Print Engine - [Stop : 12/20 13:48:32:95] - [12/20 13:48:32:189] L'impression du JobId 1 [1180-DICOX3.rptFIATIHF;AS504P.sagefr.adinternal.com;1840] est terminée


Sage 2011


Page 69


7. EPURATION ET HISTORISATION 7.1. PRINCIPES DE BASE 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 et se définissent par groupe de tables. L’historisation transfère définitivement les données archivables (i.e. 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.


Sage 2011


Page 70


Une sauvegarde est indispensable, car ces opérations sont irréversibles et l’épuration conduit à une suppression de données. Le paramétrage des règles d'épuration permet de définir les durées de vie à partir desquelles des mouvements peuvent être épurés ou archivés, en suivant des règles de cohérence par groupes de table définis par ailleurs. L'archivage se fait par transfert des données d'une table du dossier vers une table de même structure (à deux champs près, CREHISDAT et CREHISUSR, qui permettent de connaître les dates et opérateurs ayant historisé la donnée). Cette table est définie dans un dossier dédié, qui utilise par ailleurs le dossier courant comme dossier mère, et dont la création est faite automatiquement lors du premier archivage. L'intérêt de cette façon de faire réside dans le fait que les fonctions de consultation sur les données de l'historique fonctionnent alors par simple connexion sur ce dossier, de la même façon qu'elles fonctionnent sur le dossier en cours.


Sage 2011


Page 71


7.2. CREATION D’UN DOSSIER D’HISTORISATION Les progiciels Sage sont susceptibles de gérer, par le biais de fonctions d'épuration / archivage, le transfert vers des archives ou la purge de mouvements qui n'évoluent plus, et qui sont considérés comme suffisamment anciens pour ne plus être consultés fréquemment. Développement > Utilitaire > Dossiers > Création dossier historisé

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.

Remarque : 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 que Sage X3 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ée, 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 serveur@DOSSIER - Modifier le cas échéant le paramètre HISCOE (coefficient d’augmentation de tables)


Sage 2011


Page 72


Il est à noter qu’à partir du moment où les tables d’un groupe sont déclarées historisées, le traitement d’historisation va les créer, les dimensionnant en appliquant à la table d’origine le coefficient multiplicateur défini à la création et stocké dans HISCOE. Ce paramètre ne sert donc que s’il n’y a pas encore eu d’historisation.


Sage 2011


Page 73


7.3. DEFINITION DES REGLES D’EPURATION ET D’HISTORISATION Ces règles sont fournies en standard dans le progiciel, leur modification relève de développement spécifique. Développement > Dictionnaire données > Ouverture au paramétrage > Historisation / Epuration

On associe à un code : - Un groupe de tables liées - Des informations de sélection - Société - Site - Date de référence - Des formules qui doivent être vérifiées pour que l’épuration soit possible Un traitement de contrôle standard, personnalisable par un traitement spécifique complémentaire

Remarque : Dans cet exemple, la date de référence utilisée pour savoir quels contrats d’achat peuvent être épurés est la date DAT (date de calcul de la statistique). Ainsi, on épurera les contrats datés de plus de N jours. Tables mises en œuvre

Nom de la table AHISTO AHISTOD


Abréviation Contenu Règles d’historisation et d’épuration AHI Formules d’épuration AHD

Sage 2011


Page 74


7.4. PARAMETRES D’EPURATION / 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 (i.e. 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 Paramétrage > Exploitation > Données > Paramètres épurations

Remarque : Selon l’opération d’épuration ou d’historisation envisagée, les dates peuvent être ramenées à des périodes ou à des exercices.


Sage 2011


Page 75


7.5. EXECUTION DE L’HISTORISATION / EPURATION Cette fonction peut être lancée en direct et en batch (tâche AHISTO). Exploitation > Historique / Epuration

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

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


Sage 2011


Page 76


7.6. VISUALISATION DES DONNEES HISTORISEES 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)

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


Sage 2011


Page 77


8. LE WORKFLOW MANUEL 8.1. INTRODUCTION Les mécanismes de gestion des processus Workflow ont été complètement réécrits. Ils permettent de gérer un ensemble d’événements déclenchants plus important, et les règles d’affectation sont plus riches. Les principales évolutions portent sur : - La saisie du paramétrage du texte des messages au kilomètre. - La gestion des signatures répond à un plan prédéfini qui peut être à plusieurs niveaux. - La gestion des destinataires peut être externe au paramétrage des règles de Workflow et permet la gestion des absences. - Des Workflow peuvent être exploités par des processus batch. - Le Workflow peut être couplé avec les fonctions d’audit des tables. - L’intégration dans le mécanisme de Workflow de processus pré-paramétrés (actions). Des actions simples de gestion des réponses au message envoyé à l’utilisateur peuvent être exécutées au travers du serveur http déclaré dans la solution Sage X3. Des actions de type traitement peuvent être ajoutées au processus de Workflow lors de la génération du message ou lors du processus de signature. Pour assurer la compatibilité avec les versions antérieures du mécanisme de gestion des signatures des demandes d’achat (DA) et des commandes, les fonctions de paramétrage de ces objets reste disponible. - Paramétrage des signatures - Règles de signatures - Rectification des signatures Ces fonctions ne sont à utiliser que pour gérer les signatures des commandes et des demandes d’achat.

8.1.1. Principes de base du Workflow V5 et supérieur Le Workflow Sage X3 est composé des éléments suivants : - Production des messages ou notification - Gestion des actions de retour paramétrées dans le message via une connexion X3 Cette gestion est réservée au mode client serveur. - Gestion des actions de signature à partir du message reçu via une réponse simple de type Oui/Non. - Gestion de traitements annexes (action X3) pendant le processus de Workflow ou de signature. Le Workflow permet de définir l’exécution d’un certain nombre d’actions lorsque des évènements paramétrés sont réalisés dans le contexte Sage X3. Ces actions peuvent être : - L’envoi d’un message via la messagerie de l’entreprise - La gestion de notifications dans des plans de travail - La mise à jours de données par l’exécution de traitements Sage X3 soit immédiatement lorsque l’événement se produit soit postérieurement lorsque le(s) destinataire(s) des messages réagiront. - Gestion du suivi des évènements de Workflow et des signatures (Plan de travail) Sage ERP X3 - Outils avancés

Sage 2011


Page 78


L’envoi des messages est conditionné par l’utilisation d’une messagerie acceptant l’interface MAPI lors de l’envoi par le client Sage X3 ou SMTP POP3 lors de l’envoi par le serveur X3. Dans le cas ou le processus de Workflow inclus une action de retour ou de signature, les destinataires sont nécessairement des utilisateurs X3. La gestion des actions de signature passe par un serveur http qui active un processus batch permettant la mise à jour des tables.

8.1.2. Les paramètres superviseur Les processus de Workflow utilisent les paramètres superviseur du groupe WRK suivants: TYPMES : Envoi des messages via les postes clients ou le serveur de traitement. SERMES : Nom du serveur de messagerie ou adresse IP de ce serveur. Ce paramètre est obligatoire si la valeur du paramètre TYPMES est égale à Serveur. WRKDAY : Nombre de jours permettant de définir la fenêtre de consultation des notifications dans un plan de travail. Exemples - valeur 0 : date début = date fin = date$ - valeur 5 : date début = dates$ - 5 jours ; date fin = date$ Il existe d’autres paramètres superviseur définis pour la gestion des liens de workflow (cf. chapitre dédié) qui peuvent être associés à des codes activité associés

8.1.2.1.

Fonctionnel

AUDIT : Ce code permet de rendre optionnel la gestion de l'audit des modifications sur les tables de la base. Cette fonction, définie via l'onglet Audit du dictionnaire des tables, permet de tracer, par des triggers de base de données générés automatiquement, les insertions, suppressions, et modifications faites sur une table, en stockant si nécessaire des valeurs avant et après sur des champs particuliers. Pour mettre en place un Workflow manuel sur les évolutions des données d’une table, il faut rendre actif ce code activité.

8.1.2.2.

Dimensionnement

AWR : Ce code permet de définir le nombre maximum de signataires qu'il est possible de déclarer dans une règle d'affectation. Ce nombre ne doit pas être supérieur à 10.


Sage 2011


Page 79


8.1.2.3. Table

Les tables dédiées au Workflow

Abréviation

AWRKLNK AWRKPAR AWRKPARC AWRKPARF AWRKPARH AWRKPARX AWRKREG AWRKREGVAL AWRKTRN AWRKTRND AWRKUSR AWRKHISDES AWRKHISJOI AWRKHISMES AWRKHISSUI

[AWM] [AWA] [AWC] [AWF] [AWH] [AWX] [AWR] [AWV] [AWW] [AWD] [AWU] [AWO] [AWJ] [AWG] [AWS]

8.1.2.4.

Désignation Modèles de données Règles de Workflow (définition) Règles de Workflow (actions) Règles de Workflow (signature) Règles de Workflow (destinataire) Règles de Workflow simplifiées (notifications) Règles d'affectation des destinataires Affectation des utilisateurs Plan de travail workflow Plan de travail workflow Utilisateurs délégués Historique des Workflow (destinataires) Historique des Workflow (pièces jointes) Historique des Workflow (messages) Historique de suivi des évènements de Workflow

Différences avec le Workflow V140

On ne gère plus les boucles locales sur les tableaux. La variable de boucle entre double parenthèses. Pour contourner ce point, il faut utiliser les modèles de données en-tête ligne. Il n’y a pas d’automatisme de reprise de ce type de paramétrage. On ne dispose plus des 5 couples natures/information dans le moniteur Workflow. Pour contourner ce point, il faut utiliser les variables de contexte. Ces variables peuvent être utilisées dans les données affichées des plans de travail et comme critère de sélection des évènements de Workflow. Il n’y a pas d’automatisme de reprise de ce type de paramétrage.


Sage 2011


Page 80


8.2. LES MODELES DE DONNEES Afin de disposer d’un ensemble d’informations cohérentes pour construire un processus de Workflow, une fonction permet de définir un modèle de données. Celui-ci est constitué d’un ensemble de tables qui seront ouvertes lors du déclenchement du Workflow avec la définition des liens entre ces tables. Cette fonction permet de définir un groupe de tables liées soit directement, soit en cascade, par des liens de type (1,1) ou (1,N) à une table principale supposée être en ligne. Un tel modèle de données peut être utilisé : - dans une règle de Workflow, soit parce que c'est le seul contexte disponible pour décrire les tables à parcourir (cas d'une règle de type Manuel, où le modèle est obligatoire), soit pour enrichir le contexte de déclenchement (cas des autres types). - dans une règle d'affectation, où le modèle est obligatoire. Il définit le groupe de tables dans lequel se trouvent les champs utilisés par la règle d'affectation des utilisateurs. Le modèle de données associé à une règle de Workflow et celui associé à la règle d'affectation sont obligatoirement identiques. Développement > Dictionnaire données > Ouverture que paramétrage > Modèles de données

Le champ Code modèle est l’identifiant du modèle de données. Le champ Intitulé est un libellé documentaire associé au code modèle. Le champ Actif permet d'activer ou de désactiver la fiche courante sans pour autant perdre son contenu. Une fiche désactivée ne peut pas être utilisée (par appel de son code) dans d'autres fiches (documents, paramétrages...), ou lors de traitements de masse. Le champ Module définit le module X3 d'appartenance du modèle. Le champ Code activité permet de protéger le modèle décrit. En effet cette notion de modèle est considérée comme une fonction de développement.


Sage 2011


Page 81


Il est fortement conseillé de créer un code activité dédié et d’affecter celui-ci sur tous les modèles de données qui seront créés dans un dossier afin de ne pas perdre le paramétrage de ces modèles lors de la revalidation du dossier. Le champ Table principale identifie la table principale à partir de laquelle on lit d'autres tables par des liens directs ou en cascade. Cette table est supposée être en ligne si le modèle est utilisé dans une règle Workflow de type différent de Manuel. Dans le cas d'un Workflow de type Manuel, elle fait partie de la jointure qui est ouverte et parcourue à l'exécution du Workflow. Bloc Liens Pour chaque table dépendante de la table principale devant être ouverte dans le contexte du Workflow, une ligne doit être déclarée. Le champ Table liée contient le code de la table liée. Le nombre de tables liées est limité à 30. Le champ Abrév correspond à l'abréviation sous laquelle la table liée sera ouverte. Si ce champ n'est pas saisi, on utilise l'abréviation par défaut de la table. Le champ Table origine contient le code de la table à l'origine du lien décrit dans la ligne courante. Ce peut être le code de la table principale ou celui d’une des tables déclarées dans des lignes précédentes. Le champ Clé de lien définit le code de la clé de la table utilisée pour réaliser la lecture des lignes liées. Par défaut, la première clé de la table est utilisée. Le champ Type de lien indique la cardinalité du lien. Il prend l'une des deux valeurs suivantes : 1,1 : signifie que pour chaque ligne de la table d'origine, une seule ligne de la table liée est lue. 1,n : dans ce cas, plusieurs lignes de la table liée peuvent être lues. Elles sont définies par l'expression de clé, qui peut être incomplète si elle est en plusieurs parties (les lignes dont les éléments de clés renseignés correspondent à la valeur donnée sont parcourues). Le champ Expression de lien contient les éléments constitutifs de la clef de lecture. Il est défini comme une ou plusieurs expressions calculées séparées par un point-virgule. Chaque expression est évaluée, et le résultat permet de connaître la valeur de la clé utilisée pour réaliser la jointure. Lorsque les jointures multiples sont autorisées, on peut ne donner que les premiers éléments de la clé. Dans les expressions, on peut utiliser des constantes, et des champs issus des tables précédemment définies dans la liste des liens. Le Champ société contient le code du champ à utiliser pour déterminer le code de la société lors de l’exécution du Workflow. La valeur de ce champ permet de déterminer la règle d'affectation à utiliser. Le Champ site contient le code du champ à utiliser pour déterminer le code du site l’exécution du Workflow. Il permet d'en déduire la société courante, si celle-ci n'est pas définie par le champ société. Les tables suivantes sont mises en œuvre par la fonction :

Table ATABIND ATABLE ATABZON ATEXTRA AWRKLNK AWRKPAR AWRKREG

Abréviation [ATI] [ATB] [ATZ] [AXX] [AWM] [AWA] [AWR]


Intitulé Table Dictionnaire des index Dictionnaire des tables Dictionnaire des champs Textes à traduire Modèles de données Règles de Workflow Règles d'affectation

Sage 2011


Page 82


8.3. PARAMETRAGE DES REGLES DE WORKFLOW Les Workflow sont gérées par des transactions de paramétrage permettant de définir : - Les règles de déclenchement du processus de Workflow, - Les règles de définition des destinataires des messages générés, - Les règles de génération des textes des messages, - Les règles de suivi des évènements de Workflow (signatures), - Les actions à exécuter au déclenchement du Workflow ou pendant le processus de signature.

8.3.1. Evènement déclenchant Paramétrage > Workflow > Règles workflow

Cet onglet permet de définir les conditions de déclenchement du processus de Workflow. Ces conditions sont identifiées par un type et un code événement. Les valeurs du champ type d’événement sont déclarées dans le menu local 988. Le champ type d’évènement est l’attribut principal d’identification du processus de Workflow qui sera exécuté. Les autres paramètres sont dépendants de cette valeur. Nu Code 1 D 2 O 3 E 4 R 5 F 6 A 8 I

Message Divers Objet Entrée fonction Edition Fin de tâche Arrêt de tâche Import/export

9 S 10 M

Signature Manuel

Code évènement Voir le menu local 908 Code de l’objet sur lequel l’événement est réalisé Code de la fonction Code de l’état déclaré dans le dictionnaire des états Code de la tâche batch Code de la tâche batch Code du modèle d’import / export Code de l’événement à l’origine de l’action de signature. Si non renseigné l’événement est générique. Sans objet

L’événement Objet regroupe les boutons et les opérations réalisées sur l’objet.


Sage 2011


Page 83


L’événement Signature correspond à l’action de signature d’un utilisateur sur un Workflow précédent. Le contexte de l’événement de Workflow d’origine est alors en ligne. L’événement Manuel est lié à un Workflow déclenché manuellement par un utilisateur ou par un processus batch. Ce type d’événement peut être utilisé pour gérer les audits paramétrés sur les tables X3. Un code événement : La valeur de ce champ est dépendante du type d’événement. Il est utilisé comme critère dans les transactions de consultation des évènements de Workflow. Pour les évènements de type divers, le menu local 908 contient les évènements autorisés. Cette table ne doit pas être personnalisée

Code Intitulé

Observations

BUT

Bouton Workflow

Permet de gérer l’action Fichier / Envoyer vers…

CAN

Annulation

CON COV CSD CSL CSP DEC KIL MSG PBI PWD

Connexion Couverture commerciale Flux trésorerie - échéances Export balance consolidation Flux trésorerie - règlements Déconnexion Arrêt processus Retour Workflow

Annulation de signature, permet à un utilisateur de revenir sur sa décision. Connexion d’un utilisateur Fonctionnel X3 entreprise Fonctionnel X3 entreprise Fonctionnel X3 entreprise Fonctionnel X3 entreprise Déconnexion d’un utilisateur Arrêt d’un processus Sage X3 Workflow

Mot de passe

Remise à zéro du mot de passe d’un utilisateur Si le paramètre superviseur SUP/PASSWD égal à Oui : Un mot de passe temporaire est attribué Si l’événement Workflow existe, il est temporairement stocké dans la variable GMESSAGE et peut être envoyé à l’utilisateur par mail (sinon il est affiché)

TIM TO1 TO2 TO3 TRA

Time-out Crédit de jetons (Clients) Crédit de jetons (Commandes) Crédit de jetons (Factures) Trace

Time-out Jetons Jetons Jetons Gestion des Trace

Un code opération qui n’est significatif que pour les Workflow de type Objet, Signature et Import/Export, il permet de préciser de manière plus fine les conditions de déclenchement du Workflow. Les valeurs autorisées sont dépendantes du contexte.


Sage 2011


Page 84


Exemple sur l’objet commande

A ces attributs de déclenchement sont rattachés des informations complémentaires permettant de préciser : Le modèle de données : Permet de définir un ensemble cohérent de tables qui sont utilisées dans le contexte d’exécution du Workflow. Cette notion de modèle est rendue nécessaire pour gérer des règles complexes de signature et pour produire des textes de messages complets. Cette notion de modèle est obligatoire pour les Workflow de type Manuel, car il permet de définir la requête à exécuter pour réaliser l’action de Workflow. Voir le chapitre concernant le paramétrage d’un modèle de données. L’indicateur de fin de transaction : Utilisé pour un Workflow de type objet, pour préciser quand le Workflow sera déclenché. Pendant ou après la transaction de mise à jour des tables liées à l’objet. Le code Règle d’affectation : Ce code permet de ne pas gérer de destinataires en dur au niveau de la règle de Workflow. Il permet de définir une table de ligne multi critères qui renvoie une ou plusieurs valeurs. Cette règle d’affectation renvoie dans une variable dimensionnée [L]USER(1..N) la liste des destinataires. Ces destinataires sont de type utilisateurs X3. Le nombre maximum de signataires est définit par la variable de dimensionnement AWR qui est initialisée à 6 et dont le maximum est de 10. Le type de Workflow : Cette information permet de préciser lorsque le Workflow est lié à un modèle de type entête / lignes, le niveau pour lequel il sera déclenché. Le code de la Table Ligne : Cette information est à renseigner si et seulement si le Workflow est déclenché sur une table de lignes détail (Ligne des factures liées à un règlement par exemple). Le critère de regroupement des lignes : Cette zone permet de définir une règle de regroupement afin de ne générer qu’un seul événement de Workflow par rupture sur ce critère. Ce critère est une expression séparée par des points virgules.

8.3.1.1.

Le bloc Conditions

Le champ Type est modifiable si l'événement de Workflow est de type Ligne, les conditions peuvent porter soit sur l'en-tête, soit sur la ligne. Sinon les conditions seront appliquées sur l’en-tête. Sage ERP X3 - Outils avancés

Sage 2011


Page 85


Le champ Conditions permet d’exprimer des conditions complémentaires sous la forme d'expressions logiques (Formule de calcul) incluant des variables en ligne au moment de l'exécution de la règle (contenus de masques d'écrans ou de tables en ligne, selon la description du contexte...). Si ces conditions sont toutes vraies, le message sera envoyé et/ou la trace écrite dans le fichier log. Lorsque le contexte est de type en-tête et lignes, on peut filtrer une partie des lignes reliées à un entête en définissant des conditions s’appliquant sur les lignes. S'il reste au moins une ligne concernée et que les conditions de l'en-tête sont vraies, le déclenchement sera réalisé. Si plusieurs lignes de conditions sont paramétrées, c’est l’ensemble de ces conditions qui détermine le déclenchement de l’événement.

8.3.1.2.

Le bloc Gestion

Activation mail : Un message est généré et envoyé aux destinataires renseignés dans l’onglet destinataires. Activation suivi : Une notification est gérée dans le plan de travail et les circuits de signature associés sont activés. Activation action : Ce témoin permet de prendre en compte les actions déclarées dans l’onglet action. Mise au point : L’affichage du message au déclenchement du Workflow pour contrôle et mise au point. C’est le mode test.

8.3.2. 0nglet destinataire Si les messages sont destinés à des destinataires qui sont aussi des acteurs de l’application (utilisateurs Sage X3), alors dans une règle de Workflow les destinataires peuvent être : - soit déclarés explicitement dans la règle de Workflow, - soit déterminés à l’aide d’une règle d’affectation.

Le champ Condition permet d’exprimer une règle pour que le message soit envoyé au(x) destinataire(s) déclaré(s) dans la ligne. La notation not[L]COND(1) permet de définir la condition inverse de la ligne renseignée sous forme d’indice (valeur 1 dans l’exemple). La notation [L]NBUSR=0 correspond à une règle d’affectation qui ne renvoie aucun destinataire et permet de définir un destinataire par défaut. Le champ Type permet de préciser si le destinataire est un utilisateur Sage X3 défini dans la table AUTILIS ou un tiers défini dans la table BPARTNER. Il est nécessaire que l’adresse mail soit paramétrée sur la fiche correspondante du destinataire. Sage ERP X3 - Outils avancés

Sage 2011


Page 86


Le champ Destinataires contient soit une formule évaluée lors de la construction du message, soit une adresse de messagerie. Si le type de destinataire est un utilisateur X3, le code du destinataire sera soit définit par une formule évaluée lors de la construction du message (exemple [V]GUSER), soit définit à l’aide d’une règle d’affectation. Dans ce dernier cas, c’est le tableau [L]USER qui contient les codes des destinataires. Le champ Fonction permet pour les destinataires qui sont des tiers, de filtrer dans la liste des contacts liés au code tiers, ceux dont la fonction correspond à la valeur saisie. Dans la fiche contact l’attribut fonction est défini par une valeur du menu local 233. Si, dans cet écran, la valeur du champ «Fonction » n’est pas renseignée, tous les contacts déclarés dans la fiche tiers et ayant une adresse mail renseignée recevront le message. Le champ Envoi mail permet de préciser si les destinataires déclarés dans la ligne recevront: - Non : Aucun message, - Oui : Un message à chaque destinataire, - Copie : Une copie du message.

Le champ Suivi précise si les destinataires de la ligne vont recevoir une notification dans leur plan de travail, selon la valeur saisie : - Non : dans ce cas, aucune notification ne sera disponible dans le plan de travail. - Oui : une notification leur sera envoyée, elle pourra être simplement visée, pour signaler que l'utilisateur l'a lue. - Avec signature : cette notification devra être signée par un des destinataires de la ligne. Le champ Nature permet de définir un critère de regroupement dans les fonctions de suivi. Le champ Option délégué permet de préciser la façon dont est géré le fait que l’absence du destinataire identifié dans la ligne. Cette absence est gérée par l’intermédiaire de la transaction « Utilisateurs délégués » présentée dans un chapitre spécifique. - Non, seul le destinataire d’origine recevra le message. - Tous, le destinataire et tous les utilisateurs définis comme délégués du destinataire recevront le message. - Cascade, le destinataire, ses délégués, les délégués de ses délégués, etc. recevront le message. - Premier libre, le premier destinataire présent recevra le message.


Sage 2011


Page 87


8.3.3. Onglet Message Cet onglet permet de définir les règles de génération du texte des messages.

Le champ Objet : permet de définir le contenu du champ Objet du message envoyé, sous la forme d'une expression calculée qui est évaluée au moment du déclenchement de l'événement. Comme par exemple :

"La tâche"+[F:ABR]TACHE+" est terminée" Le champ Texte permet de définir le contenu principal du message. Son écriture se fait sous la forme de texte libre incluant des expressions logiques (Formule de calcul) entre deux barres verticales qui tiennent lieu de séparateur. Ainsi, par exemple, on pourra écrire des contenus tels que :

|"Il y a eu des erreurs"| |"en nombre"-num$(GERRTRACE)| |[F:ABR]TACHE| |"Message d'erreur" +-GMESSBATCH| Le texte des messages peut contenir des libellés issus de la table des textes ATEXTE. Ces textes sont alors déclarés avec l’instruction mess. Exemple ############################ | mess(00306,00183,1)+":"- [F:PIH]NUM | | mess(00017,00007,1)+":"- [F:PIH]BPRPAY | | mess(00425,00183,1)+":"- format$('N:9.2',[F:PIH]AMTATI) -[F:PIH]CUR | | mess(00048,00110,1)+":"- format$('N9.2',[M]CUMLINAMT2) -[V]GLOCALDEV | | mess(00021,00129,1)+": 1"-[V]GLOCALDEV+"="+format$("N7.5", [F:TCH]CHGRAT)[F:PIH]CUR | Sage ERP X3 - Outils avancés

Sage 2011


Page 88


A la saisie, ces textes sont visualisés par l’utilisation d’un clic droit avec l’option affichage des messages ############################### | Numéro de facture:- [F:PIH]NUM | | Fournisseur:- [F:PIH]BPRPAY | | Montant facturé:- format$('N:9.2',[F:PIH]AMTATI)-[F:PIH]CUR | | Montant devise locale:- format$('N9.2',[M]CUMLINAMT2)-[V]GLOCALDEV | | Cours devise:- "1"-[V]GLOCALDEV +"="+format$("N07.5",[F:TCH]CHGRAT)-[F:PIH]CUR | De même la description des tables est accessible par l’utilisation d’un clic droit avec l’option assistant de formule. Nota : Dans le cas où le texte du message contiendrait du texte issu de la table ATEXTE, le texte envoyé est dans la langue de l’émetteur. Dans le corps du message, on peut insérer des données issues de la table des lignes détails, si le modèle de données ou l’objet gère des lignes détails. Pour définir l’emplacement dans le corps du message où doivent être insérées les données extraites des lignes détails on utilise la codification |LIG|. Dans ce cas, le champ suivant doit être renseigné. Le champ Ligne permet lorsque l’événement est de type ligne d’insérer dans le corps du message des informations issues des lignes détails. Ces informations sont exprimées sous la forme d’une formule qui est évaluée lors du déclenchement de l’événement Exemple historique des connexions Texte : |mess(13,154,1)| ============================================ |LIG| Ligne : format$("K:10X",[AES]ESP1)-format$(GFMDAT,[AES]ESPDAT)-[AES]ESPTIM Définition des arguments d’une signature Les balises SIG permettent de définir les réponses attendues Une réponse est identifiée par la balise SIG et un mot clef VAL ou REJ qui doit être en correspondance avec les réponses définies la colonne réponse de l’onglet suivi ############################### # |SIG/VAL/"Pour valider, cliquez sur :"| # |SIG/REJ/"Pour refuser, cliquez sur :"| ############################### Ces réponses seront transformées dans le message par un lien http vers le serveur WEB habilité à gérer ces réponses. ############################### # Pour valider, cliquez sur : http://action.jsp?C=0700000398OK&K=zt4ddjr5Ud&L=FRA&D=DIAMONDTESTV5 # Pour refuser, cliquez sur : http://action.jsp?C=0700000398KO&K=zt4ddjr5Ud&L=FRA&D=DIAMONDTESTV5 ############################### Les réponses autorisées sont déclarées dans la table diverse 54


Sage 2011


Page 89


8.3.3.1.

Bloc gestion

Le champ Envoi permet de préciser si l'envoi doit être fait localement par le poste client, depuis le serveur de traitement, ou indifféremment depuis l'un ou l'autre. Dans le cas des événements liés à un processus batch, c’est le serveur de traitement qui est à activer. Le champ Icône de retour permet d’insérer sous la forme d’une pièce jointe, une icône permettant d’accéder à Sage X3 sur la fiche à l’aide d’un double clic. Cette gestion d’un accès X3 via cette icône est réservée au mode client Serveur. Le champ Fonction de retour est à utiliser si le champ Icône de retour est actif et si le retour doit être effectué sur une fonction différente de celle ayant déclenché l’événement. En Workflow objet, dans le cas de la création ou de la modification d'une fiche, ceci permet, plutôt que de se connecter sur la fiche par défaut, d'aller sur une fiche liée (la fiche de l'utilisateur ayant créé ou modifié l'information qui a déclenché le Workflow, par exemple). Dans le cas du Workflow Manuel, si l’icône de retour est actif, le code de la fonction de retour est obligatoire. Le champ Retour Menu permet de préciser si le retour de Workflow est limité à la fonction définie (lorsqu'on la quitte, la fenêtre se ferme) ou si on revient au menu en sortant de la fonction appelée. Le champ Clé de lien permet de définir la clef d’accès à la fiche qui sera visualisée via l’icône de retour. Le champ Message modifiable permet dans le cadre d’un Workflow interactif de rendre le message généré modifiable par l’utilisateur ayant déclenché l’événement. Le champ Accusé de lecture permet s’il est actif d’envoyer le message avec une demande d’accusé de réception. Cette gestion d’un accusé de réception ne fonctionne que pour les messages envoyés via le poste client (Interface MAPI).

Le champ Groupage par destinataire permet si un événement de Workflow crée plusieurs notifications, de regrouper les messages créés par l'événement. Il y a plusieurs notifications si le Workflow est de type Ligne ou s'il s'agit de l'évènement spécial ANU déclenché lors de l'annulation d’une signature. Les notifications sont regroupées entre elles, si elles ont les caractéristiques suivantes en commun : - l'émetteur - le type de serveur - le contexte de retour - l'objet du message - l'accusé de réception - les destinataires - le flag signataire Voir l’exemple de Workflow Escalade par défaut.


Sage 2011


Page 90


8.3.3.2.

Bloc Pièces jointes

Il est nécessaire que le paramètre général TYPMES soit égal à Serveur pour que des pièces jointes puissent être envoyées. Si ce n'est pas le cas, seule la première pièce jointe est envoyée (ceci est signalé par un message d'avertissement lorsqu'on impose un envoi par Client). Par ailleurs, les pièces jointes doivent être accessibles depuis le serveur d'application par un chemin réseau si elles ne sont pas stockées dans la base X3. Fichier Trace lié : Cette case ne peut être cochée que si l'événement déclenchant correspond à la fin d'une tâche batch. Dans ce cas, si elle est cochée, le fichier trace associé à la tâche batch va être joint au message envoyé. Pièce à joindre : Ce champ permet d'associer une pièce jointe au message, en donnant un chemin d'accès réseau sous la forme d'une expression calculée qui sera évaluée au moment du déclenchement de l'événement. Pièce jointe : Quand cette case est cochée, sur un Workflow de type objet, les pièces jointes à la fiche peuvent être envoyées en pièces jointes du message. (Exemple pièce jointe de l’entête et du pied des factures) Tous types : Ce champ permet d'envoyer toutes les pièces jointes à la fiche. Type pièce jointe : Ce champ permet de préciser le type des pièces jointes à sélectionner si le champ précédent Tous type n’est pas actif.

Toutes catégories : Cette case n'est saisie que pour un Workflow de type objet pour lequel la case Pièce jointe est cochée. Si cette case est cochée, toutes les catégories de pièces jointes à la fiche déclenchant le Workflow sont envoyées comme des documents joints au message. Sinon, on doit saisir la catégorie concernée.


Sage 2011


Page 91


Catégorie : Ce champ permet, lorsque des documents joints à une fiche doivent être envoyés en pièce jointe au message, de filtrer ces documents en fonction de leur catégorie définie par le menu local 96. - Confidentiel - Interne - Externe 1 - Externe 2

8.3.4. Le suivi des signatures Cet onglet permet de définir la façon dont les notifications de type Suivi sont faites dans les plans de travail des utilisateurs destinataires, et également les conditions de signature associées, s'il y en a. Ces conditions de signature ne sont applicables que si dans le tableau des destinataires, ces destinataires sont suivis Avec signature. On définit alors, sous la forme d'expressions évaluées, le message à faire apparaître dans le plan de travail, et la date limite attendue de signature si une signature est attendue. On trouve ensuite un tableau permettant de préciser les réponses que l'utilisateur pourra faire lors de sa signature, avec la possibilité de mettre directement à jour un champ de la fiche courante lorsque le Workflow est de type Objet. Il est à noter que les éléments évalués dans le tableau des réponses le sont au moment de la signature, alors que les éléments relatifs à la notification ou au message associé le sont au moment du déclenchement du Workflow d'origine. Ceci signifie que le contexte n'est plus exactement le même. Ainsi, dans un contexte Workflow de type objet lors du déclenchement, on dispose de l'ensemble des variables des écrans et des tables liées à l'objet, ainsi que les tables complémentaires liées à un modèle de données et à une règle d'affectation éventuelle et les variables globales liées au contexte du signataire. Par exemple GUSER représente le code de l'utilisateur ayant déclenché l'événement. lors de la signature, on a en ligne l'enregistrement de la table principale de l'objet, ainsi que les tables décrites dans un modèle de données et une règle d'affectation éventuelles, mais on ne dispose plus des écrans en ligne, et les variables globales sont celles du contexte de la signature. Dans notre exemple GUSER représente alors le code de l'utilisateur qui signe le document. Pour permettre de transmettre des valeurs du contexte de déclenchement vers le contexte de signature, on dispose d'un tableau nommé Contexte. Les expressions qui y sont décrites sont évaluées et transmises au moment de la signature sous la forme d'un tableau de variables locales nommées [L]CTX. Ces variables peuvent alors être utilisées dans le paramétrage des plans de travail, dans les conditions et valeurs liées à la signature, et également dans les valeurs et variables liées aux Actions de l'onglet suivant, lorsqu'il s'agit d'actions déclenchées lors de la signature.


Sage 2011


Page 92


8.3.5. Onglet Suivi

Les réponses sont déclarées dans la table diverse 54. Elles doivent au minimum contenir celles déclarées dans les balises SIG du message.

8.3.5.1.

Bloc Signature

Texte suivi Ce champ contient une expression évaluée au moment du déclenchement du Workflow. Le résultat de cette évaluation est une chaîne alphanumérique stockée dans la table de suivi des évènements Workflow AWRKHISSUI. C'est cette valeur qui est normalement présentée dans le moniteur Workflow pour qualifier l'événement à signer. Signature Si cette case est cochée, le suivi donne lieu à un processus de signature : on retrouve alors, dans le tableau situé en bas de l'écran, un certain nombre de choix de signature possibles. Date limite Dès lors que la case Signature est cochée, il est possible de définir une expression de type date définissant la date au-delà de laquelle on considère qu'il y a retard si la signature n'a pas été faite. La valeur du champ correspondant est stockée dans la table de suivi des évènements Workflow AWRKHISSUI (Champ DATREL). Ce champ peut être exploité dans le moniteur Workflow, pour définir un ordre de classement. Mais il peut aussi être exploité pour une gestion de relance des événements en attente de signature, sachant que le champ [AWS]NBREL permet de compter les relances éventuelles faites.


Sage 2011


Page 93


8.3.5.2.

Bloc Contexte

Ce tableau contient des expressions évaluées au moment du déclenchement d'un Workflow. Ces variables sont stockées dans l'historique des Workflow (variables VALCTX1 à VALCTX15). Elles sont utilisables dans le contexte de la signature (tableau de variables CTX(1) à CTX(15)) associé à l'événement originel, ou à un événement de Workflow consécutif à la signature. L'intérêt de ces variables est qu'elles permettent de transmettre des informations qui ne sont pas situées dans les tables à l'origine du contexte déclencheur, et donc qui ne sont pas transmises automatiquement d'un événement à la signature ou à l'événement suivant. En effet, les tables de l'objet ou celles de la règle d'affectation sont transmises automatiquement. Par contre, ne sont pas transmises - les variables globales comme GUSER, GFONCTION, GABREV, CLEOBJ, qui définissent respectivement l'utilisateur courant, la fonction courante, le code de l'objet, et la clé courante au moment du déclenchement d'un Workflow objet. - les variables liées aux écrans. - les variables issues des expressions telles que date$, time$... qui qualifient le contexte du déclenchement. C'est donc pour ces variables qu'il est intéressant de paramétrer un contexte pour les transmettre de l’événement déclenchant à celui de la signature. Les variables transmissent via ce contexte sont exploitables par le moniteur de Workflow.

8.3.5.3.

Bloc Réponse

Ce bloc permet de définir les réponses possibles, à choisir par le destinataire. On déclare une ligne par réponse autorisée. Le champ Réponse définit un choix possible pour le récepteur du message. Les choix autorisés sont déclarés dans la table diverse numéro 54, qui définit des choix possibles à la signature. Dans le plan de travail des signatures, un clic droit sur la ligne à signer permettra de proposer parmi la liste des choix issus de cette liste, ceux pour lesquels la condition est vérifiée. Le champ Opération est le code qualifiant la signature réalisée. Il correspond au code opération utilisé dans un événement de type Signature consécutif à l'événement signé. Il est à noter que plusieurs lignes peuvent porter le même code opération. Les valeurs autorisées sont déclarées dans la table diverse numéro 55. Ce code n'est pas stocké dans l'historique des Workflow à l'issue de la signature. C'est en effet la valeur du champ Réponse, qui n'admet pas d'homonymes entre les différentes lignes, qui est stocké. Le champ Condition contient une expression logique évaluée au moment de la signature. Si la condition est réalisée, alors la réponse définie sur la ligne, est proposée parmi les choix possibles. Ceci permet, par exemple, de disposer de plusieurs niveaux de signature, en fonction du nombre de signataires ayant déjà signé (seul le dernier signataire ayant accès à une signature qui déclenche une mise à jour finale). De même, il est possible de définir un choix apparemment impossible (par une condition toujours fausse de type 1=0). Ce choix pourra être forcé par une action de signature déclenchée par un autre événement de Workflow. C'est ainsi que sont traités, dans des paramétrages standards, des escalades dans les processus de signature. Motif : Permet de prévoir une saisie d’un motif lors de la signature de la règle.


Sage 2011


Page 94


Ce champ permet de préciser le numéro d’une table diverse où sont gérés les motifs des réponses. La table historique AWRKHISSUI stocke le numéro de la table diverse, le code saisi, et son intitulé. La zone Champ mis à jour définit le nom d'un champ qui sera mis à jour par le processus de signature. Ce champ est issu d'une des tables du contexte déclencheur. La valeur de ce champ après la mise à jour sera celle calculée à partir de l'expression définie dans le champ Valeur, lors du processus de signature. Ainsi on peut, par exemple, mettre à jour un champ tel que ENAFLG (indicateur Actif) de l'objet courant lors d'un processus de signature. Le champ Valeur définit l’expression d'une valeur calculée au moment de la signature. La valeur correspondant à la ligne de réponse choisie sera utilisée, en cas de signature : - soit pour mettre à jour le champ défini dans la colonne précédente. - soit lors du déclenchement d'éventuelles actions définies dans l'onglet Action. Dans ce cas, on retrouve cette valeur dans la variable alphanumérique [L]RESULT. Le champ Modifiable permet de modifier la valeur renvoyée par l’expression calculée définie dans le champ valeur, si cet indicateur est actif. La valeur résultant de la saisie sera utilisée pour réaliser la mise à jour s'il y en a une, et transmise à la variable [L]RESULT pour exploitation par une action complémentaire.


Sage 2011


Page 95


8.3.6. Onglet action Cet onglet décrit une liste d'actions qui peuvent être déclenchées soit lors du déclenchement de l'événement, soit lors de la phase de signature. Il permet d'exécuter soit des actions standards prédéfinies à cette fin, soit des actions spécifiques. Chaque action paramétrée n'est appelée que si la condition d'exécution est réalisée. A chaque action est associée la liste des paramètres de l'action, afin de permettre de saisir la liste d'expressions évaluées dans le contexte et transmises au traitement de gestion de l’action.

8.3.6.1.

Bloc action

Le champ Code action contient un code action X3 dont l'exécution peut être déclenchée si les conditions sont remplies. Au niveau du dictionnaire des actions, la case Workflow doit être active. Ce type d’action ne doit pas interagir avec l'interface utilisateur. Du point de vue technique, le traitement ne doit pas avoir de fenêtre associée. Les actions destinées au mécanisme de Workflow sont donc de type Traitement divers. Le champ Déclenchement définit les conditions de déclenchement de l’action. Les conditions autorisées sont déclarées dans le menu local 2923. Les valeurs suivantes sont utilisables : Début Workflow : l'action est déclenchée en début de constitution du texte du message. Lorsque le Workflow est de type ligne, elle n'est exécutée qu'une fois par en-tête, avant la constitution du texte d'en-tête. Les variables retournées par l'action peuvent être utilisées dans le texte du mail, mais pas pour définir les destinataires ou les conditions de l'envoi, qui sont déjà évalués à ce stade.


Sage 2011


Page 96


Fin Workflow : l'action est déclenchée après l'envoi du message. Lorsque le Workflow est de type ligne, cette action n'est exécutée qu'une fois par groupe de lignes. Avant Ligne : l'action est déclenchée avant la lecture de la première ligne, lorsqu'on a un Workflow de type en-tête et lignes. Ceci permet par exemple d'initialiser des variables de cumul pour obtenir un total des lignes, le cumul étant réalisé dans une action ligne. Ligne : l'action est déclenchée juste avant la constitution de chaque ligne de message, dans le cas d'un Workflow de type ligne. Les variables retournées par l'action peuvent donc être utilisées dans le texte ligne. Avant Groupe : l'action est déclenchée à la détection d’une rupture sur un groupe de lignes détails. Signature : l'action est déclenchée après la saisie de la signature. La variable [L]RESULT issue de cette saisie est donc connue, mais avant la mise à jour des tables. On peut modifier cette valeur durant l'action. Dans le cas d'une signature, toutes les mises à jour sont réalisées dans une seule transaction. Ainsi, si un rollback est réalisé dans une des actions déclenchées par l'événement, on revient à la situation de départ pour toutes les mises à jour effectuées. Dans le cas général, du point de vue transactionnel, il faut noter que l'action fait partie de la transaction de Workflow du message, si un rollback est fait lors de la constitution du message, les mises à jour faites dans l'action ne seront pas réalisées. Dans le cas particulier du Workflow sur un objet, tout est fait dans une seule transaction. Autrement dit, si la création ou la modification d'une fiche échoue, un Rollback est fait sur l'ensemble des mises à jour déclenchées par les actions. Il en est de même pour le suivi : la transaction qui suit la saisie du suivi inclut le déclenchement des actions. Pour résumer les actions appelées par les fonctions de Workflow ne doivent pas ouvrir de transaction. Le champ Condition d'exécution définit la condition de déclenchement de l’action. Cette condition est une expression logique, évaluée dans le contexte de déclenchement de l'action. Si le résultat de l'évaluation - est vrai (non nul), l'action est déclenchée, - est faux, l'action n'est pas déclenchée, - si aucune expression n'est saisie, l'action est toujours déclenchée.


Sage 2011


Page 97


8.3.6.2.

Bloc Paramètres

Ce bloc contient pour chaque action déclarée dans le bloc action, la liste des paramètres héritée du dictionnaire des actions X3. Le champ Paramètre contient le code du paramètre Le champ Type contient le format du paramètre Le champ Retour définit le mode de transfert de la valeur du paramètre. Le champ Valeur paramètre définit une expression évaluée qui est transmise comme argument à l'action ou le code d'une variable qui contiendra une valeur de retour si l'argument est de type Pointeur. Toutes les variables du contexte de Workflow peuvent être utilisées dans l’expression qui sera évaluée. Exemple d’actions standards utilisables par le Workflow fournis par le progiciel : AWRKUPDFLD

Mise à jour de 1 à 4 champs dans l'enregistrement courant d'une table avec gestion de transaction. Cette action permet de mettre à jour les champs FLD1 à FLD4 de la table d'abréviation ABREV avec les valeurs respectives VALEUR1 à VALEUR4. Si une transaction est en cours, l'action fait partie de la transaction; sinon, une transaction unitaire est réalisée pour l'opération. La variable GOK globale est renseignée comme pour une transaction normale.

AWRKUPDOBJ

Mise à jour de 1 à 4 champs dans l'enregistrement courant d'un objet avec gestion d’un verrou objet. Cette action permet de mettre à jour les champs FLD1 à FLD4 de la table liée à l'objet OBJET avec les valeurs respectives VALEUR1 à VALEUR4 uniquement si c'est objet n'est pas verrouillé sur la clé CLE. La variable GOK est mise à 0 en cas d'erreur.

SIGWRK

Signature automatique d'un événement de Workflow. Cette action permet de déclencher la signature d'un événement de Workflow dont l'identifiant (chrono) est connu. Elle peut notamment être utilisée dans des actions de Workflow lancées en batch, pour signer par défaut des événements en attente depuis trop longtemps (procédures d'escalade). Le code action passé en paramètre correspond à la signature faite par défaut sur l'événement en question (ce peut être une signature par défaut, un refus par défaut, voire une action spécifique d'escalade). Paramètres de l'action CHRONO Chrono Char USER Code utilisateur Char ACTION Action Char

Ces actions sont de type Superviseur, c'est-à-dire qu'elles sont génériques et ne concernent pas un module particulier. D'autres actions liées à des modules fonctionnels existent également.


Sage 2011


Page 98


8.4. LES REGLES D’AFFECTATION Les règles d’affection consistent à réaliser un paramétrage permettant de parcourir un ensemble de données issues des tables X3 afin de construire une liste d’utilisateurs destinataires des messages. Ce paramétrage permet de ne pas figer les destinataires dans les règles de Workflow. Les règles d’affectation sont paramétrées en deux étapes. 1. La première étape décrit les règles de parcours des tables et de constitution d’un tableau de critères. Le résultat de l'évaluation des critères est stocké dans un tableau de variables nommé [L]VALEXP, l'indice variant de 1 au nombre de colonnes de critères 2. La seconde permet d’affecter à chaque valeur du tableau de critère les destinataires du message qui sera créé. La liste des utilisateurs ainsi constituée est mémorisée dans un tableau de valeur nommé [L]USER. La dimension de ce tableau de valeur est dépendante du code activité AWR. Chaque liste de destinataires est déterminée par des critères dépendant du contexte. L'utilisateur chargé de définir les circuits de signature pourra alors saisir les combinaisons de valeurs de critère et leur affecter les destinataires correspondants. Cette fonction de paramétrage permet de créer et de mettre à jour les règles d'affectation, en définissant le nombre maximum de signataires que renvoient une règle, et les critères dont la combinaison définit les signataires. A l'exécution de la règle d'affectation : - Les critères sont calculés par simple évaluation ou par agrégation sur un ensemble de lignes par un opérateur tel que la somme, la moyenne, le minimum, le maximum... Chacun des critères ainsi calculé est comparé à l’aide d’un opérateur aux valeurs saisies dans la règle. -

Ceci permet leur exploitation dans la suite de la règle de Workflow. Il est intéressant de noter que certains critères, dont la valeur est intéressante pour la suite du processus de Workflow, peuvent ne pas déterminer de destinataire. Dans ce cas, on leur associera l'opérateur Indifférent.

En fonction de la combinaison obtenue, le tableau [L]USER est transmis et peut être utilisé par la règle de Workflow.

8.4.1. Définition des règles d’affectation Paramétrage > Workflow > Règle d’affectation utilisateur

Le champ Règle d'affectation définit de façon unique les fiches créées. Le champ Société permet d'affecter une règle à une société particulière. Si ce code est non renseigné, il est définit pour toutes les sociétés. Le champ Intitulé est une désignation associée à la fiche. Le champ Code d’accès permet d'interdire l'accès à la fiche courante pour certains utilisateurs.


Sage 2011


Page 99


Le champ Modèle de données définit le modèle de données dont les tables sont accessibles lors de l'évaluation de la règle d'affectation. Ce modèle est obligatoire. Le code de ce modèle doit être identique à celui déclaré dans la règle de Workflow qui utilise la règle d'affectation. Le champ Table ligne ne peut être saisi que si le modèle de données contient des tables de lignes associées à un en-tête. Si on saisit alors une des tables lignes, c'est cette table qui sera parcourue pour déterminer les destinataires du Workflow. Un Workflow utilisant la règle d'affectation correspondante sera forcément de type Ligne. Le champ Nb de signataires définit le nombre maximum d'utilisateurs que renvoie la règle dans le tableau USER. L'écran généré par la validation de la règle contiendra, outre les colonnes de critères, autant de colonnes Utilisateur que de valeurs renvoyées. Ce nombre peut être compris entre 1 et un maximum défini par le code activité AWR.

8.4.1.1.

Bloc des tables à analyser

Une règle d’affectation peut utiliser 10 champs maximum pour définir les critères qui permettront d’affecter les destinataires d’un événement de Workflow. Le champ Table à parcourir définit la table à utiliser pour l'évaluation du critère de la ligne. Si cette table est liée avec un lien de type 1,n avec la table ligne de la règle (ou avec la table principale du modèle en l'absence de table ligne), un opérateur de synthèse sera saisi pour définir comment les n valeurs contenues dans les lignes seront agrégées. Le champ Op. synthèse est saisi lorsque le champ utilisé comme critère se trouve dans une table liée avec un lien 1,n à la table principale du modèle. Dans ce cas, la valeur obtenue pour le critère correspond à l'agrégation d'un ensemble de lignes, et l'opérateur saisi ici permet de préciser comment le calcul est effectué. Les opérateurs d'agrégation Somme et Moyenne ne peuvent être utilisés que si le critère est numérique. Les opérateurs Minimum et Maximum peuvent être utilisés dans tous les cas. Le champ Critère contient une expression qui sera évaluée lors de l'exploitation des règles d'affectation. La valeur résultante est comparée à la liste des valeurs saisies dans la règle afin de déterminer quelle est l’utilisateur destinataire du message. Le champ Opérateur sert à comparer la valeur du critère avec les champs saisis dans les valeurs de règle. Outre les opérateurs d'égalité et d'inégalité classiques, on retrouve l'opérateur Comme, qui permet de saisir des valeurs caractères avec des jokers, et l'opérateur Indifférent, qui signifie que la valeur n'est pas utilisée comme critère d'affectation des utilisateurs, mais transmise à la règle de Workflow appelante pour être utilisée par ailleurs. Le champ Intitulé permet de donner un titre à la colonne de saisie du critère correspondant de la règle d'exploitation. Elle est donc évaluée au moment de la saisie des valeurs de règle. Si ce champ est vide, et si le critère est un champ extrait d'une des tables de la base, le titre repris est automatiquement celui du dictionnaire (il est repris dans la langue de connexion de l'utilisateur). Le champ Type de données définit le type de données associé à la saisie du critère. Lorsqu'un champ extrait d'une des tables de la base est choisi comme critère, son type est proposé par défaut. Le champ Longueur est à saisir si le type de données est une chaîne de caractères ou un nombre. Le champ No menu local est à saisir si le type de données est un menu local. Le champ Paramètre est à saisir si le champ associé au critère est contrôlé par une table ayant une clé en plusieurs parties (par exemple, les tables diverses, les textes traduisibles), on saisit ici le composant de clé complémentaire pour établir le lien avec la table. Sage ERP X3 - Outils avancés

Sage 2011


Page 100


Le champ Lien est utilisé si le champ associé aux critères est contrôlé par une autre table. On peut alors choisir l’intitulé associé à valeur saisie. Les choix possibles sont : - Non pas d'affichage - Long affichage de l'intitulé long - Court affichage de l'intitulé court. Le champ Valeur par défaut permet de saisir une expression qui est évaluée lors de l’affectation des utilisateurs pour permettre de donner une valeur par défaut. Les données constituantes des règles d’affectation sont mémorisées dans la table AWRREG. Note : La validation d’une règle d’affectation réinitialise les affectations des utilisateurs. La validation d’une règle d’affection génère un traitement X3 nommé WMRXXXX avec XXXX=code de la règle d’affectation.

8.4.2. Affectation des utilisateurs Le paramétrage des règles d’affectation permet de générer des écrans de saisie ayant cette ergonomie. La transaction générée permet de saisir pour chaque critère défini par la règle d’affectation, les valeurs pouvant être renvoyées lors de l’exécution de la règle. Pour chaque valeur, on doit définir les codes des utilisateurs devant recevoir la notification.

Le nombre de critères affiché dans le tableau est égal au nombre de lignes déclarées dans la règle d’affectation et dont l’opérateur a une valeur autre que indifférent. Pour l’exemple ci dessus on a déclaré au minimum P critères. Le nombre d’utilisateurs par ligne est égal au nombre de signataires saisi dans la règle d’affectation.

8.4.2.1.

Bloc Utilisateur par défaut

Ce bloc contient les codes des utilisateurs auxquels le message sera envoyé, si les critères ne permettent pas définir un utilisateur. Le nombre d’utilisateurs par défaut est égal au nombre de signataires déclarés dans la règle d’affectation.


Sage 2011


Page 101


8.4.2.2.

Bloc Valeurs

Une ligne doit contenir les P valeurs des critères pouvant être renvoyées par la règle d’affectation auxquels on associe les N utilisateurs. Les données saisies dans cette transaction sont mémorisées dans la table AWRREGVAL. Pour un couple Règle d’affectation / Code société, on peut saisir un maximum de 99 affectations.

8.4.3. Utilisateurs délégués Cette transaction permet de gérer pour une fourchette de dates et pour une nature d’événement ou pour tous les événements des utilisateurs délégués qui recevront les messages. Le nombre de lignes de délégations pour un utilisateur est limité à 99. Paramétrage > Workflow > Utilisateurs délégués

Le champ Code utilisateur contient le code utilisateur X3 pour lequel des délégations sont paramétrées. Le champ Utilisateur délégué contient le code X3 des utilisateurs qui reçoivent une délégation. Le champ Nature contient le code nature des Workflow pour lesquels une délégation est déclarée. Si ce code est non renseigné, la délégation est effective pour tous les Workflow à destination de l’utilisateur d’origine. Le champ type de délégation décrit les droits associés à l’utilisateur délégué. : Copie pour info : l'utilisateur recevra les notifications adressées à l'utilisateur principal, mais sans pouvoir de signature. Avec pouvoir : un délégué de ce type peut signer à la place de l'utilisateur principal. Il est à noter que si plusieurs délégués de ce type existent, et si la règle prévoit d'envoyer une notification de Workflow à tous les délégués, seul le premier ayant décidé de signer pourra le faire (les autres seront prévenus que la notification a déjà été signée). Exceptionnel : un délégué de ce type ne reçoit pas les notifications de l'utilisateur principal, mais il a la possibilité d'afficher les notifications de l'utilisateur dont il est délégué en entrant dans le plan de travail et en sélectionnant, le code de l'utilisateur principal. Il aura alors la possibilité de signer à sa place. En général, un délégué exceptionnel est un supérieur hiérarchique qui a le droit d'aller visualiser les éléments en attente chez ses subordonnés pour signer à leur place. Les champs dates de début et fin de validité indiquent la période pour laquelle la règle de délégation s’applique. S’ils sont non renseignés, la délégation est permanente. Ces données sont mémorisées dans la table AWRKUSR. Impact du champ Option délégué dans l’onglet Destinataires des règles de workflow Pour chaque ligne de destinataire déclarée dans une règle de Workflow, l’attribut Option délégué détermine le comportement du processus de Workflow pour définir les destinataires délégués. Sage ERP X3 - Outils avancés

Sage 2011


Page 102


Par exemple Un message doit être envoyé à un utilisateur U001 dont les délégations sont les suivantes ; Délégué de U001  U010 période 01/08/07 au 31/08/07 Délégué de U001  U010 période 01/08/07 au 15/08/07 Délégué de U010  U011 période 01/08/07 au 15/08/07 Délégué de U010  U012 période 16/08/07 au 31/08/07 Délégué de U001  U020 période 15/07/07 au 15/08/07 Le message est envoyé le 10/08/07. Ce champ peut avoir les valeurs suivantes -

-

Non, seul le destinataire d’origine recevra le message quelque soit les délégués affectés à ce destinataire. Dans l’exemple ci-dessus, seul U001 reçoit le message. Tous, le destinataire et tous les utilisateurs définis comme délégués du destinataire recevront le message. Dans l’exemple ci-dessus, U001 / U010 / U020 recevront le message. Cascade, le destinataire, ses délégués, les délégués de ses délégués, etc. recevront le message. Dans l’exemple ci-dessus, U001 / U010 / U020 / U011 / U012 recevront le message. Premier libre, le premier destinataire présent recevra le message. U001 et U010 recevront le message.


Sage 2011


Page 103


8.5. MONITEUR DE WORKFLOW & PLANS DE TRAVAIL Les plans de travail sont des transactions de consultation et/ou de mise à jour des événements de Workflow exploitées par le moniteur de Workflow. Ces transactions permettent de mettre à disposition des utilisateurs des informations fonctionnelles sur les évènements de Workflow. Par exemple, liste des commandes à valider triées par date de commande, code fournisseur et numéro de commande. La conception des plans de travail doit donc être analysée lors du paramétrage des règles de Workflow. Dans l’exemple, il est nécessaire de prévoir la conservation dans les tables de suivi du Workflow des données date de commande / code fournisseur et numéro de commande. Les variables de contexte [L]CTX paramétrées dans la règle de Workflow sont prévues à cet effet. Pour assurer la confidentialité, des codes d’accès peuvent être affectés à ces transactions.

8.5.1. Paramétrage des plans de travail Le moteur de Workflow intégré au progiciel permet de paramétrer des notifications à des utilisateurs, sous la forme d'une ligne contenant un ensemble d'informations relatives à l'événement d'origine. Ces lignes peuvent être présentées dans un plan de travail paramétrable afin de : - visualiser les informations qui ont été paramétrées pour apparaître dans le plan. - réaliser un zoom vers un contexte d'origine, le cas échéant. - viser des lignes qui ne demandent pas de processus de signature élaboré. - signer (en exerçant un choix parmi un ensemble de réponses) lorsqu’un processus de signature a été paramétré. Le paramétrage d’un plan de travail génère des transactions de consultation et de mise à jour des tables de suivi des évènements de Workflow. Ces transactions sont accessibles aux utilisateurs via des fenêtres générées par la fonction de paramétrage et gérées par le moniteur de Workflow. Paramétrage > Workflow > Paramétrage plan de travail


Sage 2011


Page 104


L'écran de paramétrage est présenté sous la forme de 8 onglets identiques. Le paramétrage consiste à définir le nombre d’onglets de chaque transaction et pour chaque onglet à définir ses composants et ses caractéristiques. Puis on décrit les conditions permettant de filtrer les lignes qui doivent apparaître sur l'onglet en cours de paramétrage. Cela permet par exemple de répartir les lignes en fonction du sujet, de l'urgence, ou de tout autre critère entre onglets. Puis les informations qui doivent être présentées, les champs définissant l'ordre d'apparition, et des conditions de mise en relief de certaines lignes.

8.5.1.1.

Entête

Le champ Code transaction identifie l'écran associé à la consultation ou à la saisie, c’est aussi ce code qui est la clef de la transaction. A l'exécution des transactions et des consultations, la liste des codes accessibles à l'utilisateur est présentée, si l'entrée dans une transaction par défaut n'est pas forcée. Le champ Intitulé est le libellé de la transaction, qui peut être décliné par langue, est affiché dans la fenêtre de sélection de la transaction. Le champ Code d'accès permet de définir des filtres pour limiter l’utilisation des transactions. Si ce champ est renseigné, l'écran de consultation ou la transaction de saisie de mouvements sont accessibles si l'utilisateur a les droits liés à ce code. Par ailleurs, la modification (respectivement la visualisation) des caractéristiques de la transaction n'est possible que si l'utilisateur courant a le droit de modification (respectivement de consultation) sur le code. Sage ERP X3 - Outils avancés

Sage 2011


Page 105


Le champ Nb d'onglets définit le nombre d'onglets présents dans le plan de travail. Le champ Nb de lignes définit le nombre maximum de lignes affichées dans chaque onglet. Pour chaque onglet de la transaction, on doit définir : -

Le champ Intitulé court définit l'intitulé de l'onglet tel qu'il apparaîtra sur le plan de travail. Le champ Titre est un libellé documentaire. Le champ Filtre contient une formule qui sera évaluée à l’exécution de la transaction ou de la consultation pour filtrer les données présentées dans l’onglet. On peut ainsi ne présenter qu'une partie des lignes à traiter en les répartissant sur chacun des onglets. Par exemple o le premier onglet contient les éléments à signer [F:AWS]FLGSIG=3 o le second onglet contient ceux déjà signés [F:AWS]FLGSIG=5

8.5.1.2.

Bloc colonnes

La zone Champ contient le code du champ issu de la table de suivi AWRKHISSUI. Le nombre maximum de champs dans un onglet est limité à 70. Le champ Ordre contient le rang du champ qui sera affiché dans l’onglet généré. Si ce rang est nul, le champ ne sera pas présent dans l’onglet généré. Ces champs sont présents en mémoire mais pas affichés. Le champ Intitulé est affiché à titre documentaire. Sa valeur par défaut est issue du dictionnaire des données, mais il est possible, par un clic droit, de modifier cette valeur. Cette option permet de personnaliser les entêtes des colonnes affichées dans l’onglet. Elle est intéressante pour définir les variables génériques qui dépendent du contexte comme VALCTX1. Par clic droit sur le tableau, on dispose des choix suivants : - Tous : Alimentation automatique de tous les rangs par incrément de 5. - Aucun : Remet à zéro tous les rangs dans le tableau.

8.5.1.3.

Bloc Styles

Ce tableau permet de mettre en valeur certaines lignes affichées dans l’onglet généré. Le champ Style contient le code du style à utiliser. Ce sont les styles gérés par l’objet ASY qui sont utilisés. Pour chaque onglet, le nombre maximum de styles est limité à 5. Le champ Condition contient le critère permettant d’appliquer le style. Ces critères sont définis sous forme d'expressions calculées, sont évalués pour chaque ligne du plan de travail. Si aucune condition n'est vérifiée, la ligne reste dans la couleur par défaut.

8.5.1.4.

Bloc Ordre de tri

Ce tableau permet de déclarer les champs utilisés pour définir l’ordre de présentation des données. Le nombre maximum de champs déclaré pour définir cette clef de tri est limité à 3. La zone Champ contient le code du champ à utiliser pour le tri. Les lignes du plan de travail sont présentés triées selon la valeur des donnés affichées dans ce champ. A égalité sur un champ, on trie selon les valeurs du champ suivant. Le champ Sens définit si le tri se fait en ordre croissant ou décroissant des valeurs. Sage ERP X3 - Outils avancés

Sage 2011


Page 106


Les attributs de tri définis dans ce bloc sont concaténés pour exprimer la valeur de l’instruction ORDER BY exécutée lors de l’utilisation du plan de travail. La longueur totale de ces attributs ne doit pas dépasser 100 caractères.

Le bouton validation permet la génération des onglets et de la fenêtre constituant la transaction de gestion du plan de travail. Les écrans générés ont pour code WMIxxxxxn La fenêtre générée à pour code WMIxxxxx Avec xxxxx= code de la transaction et n rang de l’écran dans la fenêtre.

8.5.1.5.

Les champs du plan de travail

Ce tableau présente le contenu des champs de la table de suivi des évènements de Workflow AWRKHISSUI à partir de laquelle les plans de travail sont paramétrés. CHRONO

Numéro chronologique attribué lorsqu'un Workflow est déclenché. Dans le cas d'un Workflow manuel, un numéro est attribué pour chaque enregistrement déclencheur. Dans tous les autres cas, un seul numéro chronologique est attribué par déclenchement. Ainsi, lorsqu'une notification est envoyée à plusieurs utilisateurs à partir d'un même événement, le numéro de chrono est identique et permet de retrouver tous les destinataires de la notification.

DEST

Contient le code du destinataire de la notification. Si un visa ou une signature est attendue, c'est normalement lui qui effectue cette opération. Ce destinataire n'est pas forcément le destinataire qui était défini dans la règle d'origine. En effet, si la règle prévoit une délégation au premier destinataire libre, et que le destinataire de départ a défini un délégué avec pouvoir pour les dates concernées, c'est le délégué qui est destinataire de la notification (ou son délégué si lui-même a délégué...).

EMAIL

Contient l’adresse Email du destinataire.

NUMGRP

Ce numéro de chrono est attribué pour chaque ligne traitée. il y en a donc plusieurs numéros lorsqu'on a des Workflow de type en-tête/ligne avec des regroupements.

CPY

Lorsqu'un modèle de données est attaché à la règle, et que ce modèle définit une société courante en fonction du contexte (directement ou par l'intermédiaire d'un site), on stocke dans l'événement le code de la société correspondante. Ce code société peut être utilisé pour définir dans la règle d'affectation les destinataires de la notification.

DELEGUE

Contient la valeur : Non si l'utilisateur est le premier destinataire de la notification. Oui si l'utilisateur reçoit la notification en tant que délégué non remplaçant (options Tous ou Cascade), et que par ailleurs il a pouvoir de signer. S'il n'a pas de pouvoir de signer, la notification n'apparaît pas dans le plan de travail. Si la valeur de ce champ est Oui, au moins une autre ligne portant le même numéro de chrono avec la valeur Non existe dans la table des données du plan de travail. Si la notification à été envoyée à plusieurs délégués avec pouvoir de signature, on


Sage 2011


Page 107


trouvera une ligne avec la valeur Oui avec le même numéro de chrono. La première signature sur l'une des lignes concernées met automatiquement à jour l'ensemble des lignes portant le même numéro de chrono en les considérants comme signées. ENVOI

Ce champ a comme valeur Oui si un message a été envoyé lors de l'exécution de la règle.

EMETTEUR

Ce champ contient le code utilisateur émetteur de la notification. Dans un Workflow de type Signature, l'émetteur est celui qui a signé la notification précédente. Dans les autres type de Workflow, l'émetteur est l'utilisateur dont l'action à l’origine de l’envoi de la notification.

MAIENV

Lorsqu'une ligne du plan de travail a été signée par le déclenchement d'un lien http depuis un message, ce champ stocke l'adresse de messagerie de l'utilisateur ayant signé de cette manière.

DATENV

Ce champ contient la date de création de l’événement de Workflow, cette date correspond à la date système issue du serveur de traitement.

TIMENV

Ce champ contient l’heure de création de l’événement de Workflow. Elle correspond à l'heure système calculée sur le serveur de traitement.

NATURE

Ce champ contient la valeur du code Nature défini sur l'événement déclencheur. C’est un critère important pour trier et sélectionner les lignes.

TEXSUI

Ce champ contient le texte évalué à partir de la rubrique Texte suivi définie dans l'onglet Suivi de la règle; usuellement un commentaire est paramétré expliquant les circonstances du déclenchement de Workflow.

TYPEVT

Ce champ contient le type d'événement de la règle de Workflow à l'origine de la ligne de notification dans le plan de travail.

CODEVT

Ce champ contient le code événement à l'origine du Workflow, c'est à dire le code: de l'objet dans le cas d'un Workflow objet. de l'état dans le cas d'un Workflow de type impression. du modèle dans le cas d'un import ou d'un export. de la fonction dans le cas d'une entrée sur fonction. de la règle de Workflow ayant déclenché la demande de signature dans le cas d'une signature. du code identifiant un Workflow de type divers.

CODWRK

Contient le code de la règle de Workflow.

OPERATION

Contient le code de l’opération dans le contexte déclenchant: pour un événement objet, ce peut être C (création), M (modification) ou le code du bouton. pour un événement signature, le code de la règle à l'origine de la signature pour un import/export, les combinaisons I/E et D/F(import/export, début/fin), par exemple ID. pour une entrée sur une fonction, ce champ est vide. pour une impression, il est égal à C.


Sage 2011


Page 108


pour la fin d'une tâche batch, il vaut "0" si la tâche s'est terminée sans erreur; sinon, on y trouve le numéro de statut suivi du début du message d'erreur. DATMAXSIG

Ce champ contient la date à laquelle le Workflow devra avoir été signé. Il contient la date de déclenchement du Workflow si aucun processus de signature n'a été mis en œuvre, ou si aucune date limite n'a été définie. En effet, lorsque l'événement de Workflow suppose une signature, on peut gérer une date limite de signature et ensuite déclencher des relances basées sur cette date limite. Ces relances se font par des règles de Workflow batch nommées WRKREM1, WRKREM2, et WRKREM2E. Lorsqu'une relance de ce type est faite : le champ Nombre de relances, est incrémenté ce qui permet de savoir combien de fois la signature a été relancée. le champ Dernière date de relance, est modifié ce qui permet de connaître la date à laquelle la dernière signature a eu lieu. Si ces règles batch ne sont pas utilisées, et si aucune autre règle n'a été définie pour mouvementer ces champs, le nombre de relance reste égal à 0 et la date de relance reste vide, car aucun traitement standard du Workflow ne modifie cette valeur

FLGSIG

Ce champ définit le niveau de signature correspondant à la notification de la ligne. Les valeurs suivantes, définies par le menu local 2922 sont possibles : A lire (valeur 2) : un accusé de lecture est demandé, mais la notification n'a pas encore été lue. A signer (valeur 3) : une signature est demandée, mais la notification n'a pas encore été signée. Lu (valeur 4): un accusé de lecture a été demandé, il a été saisi. Signé (valeur 5): une signature a été demandée, elle a été accordée. Annulé (valeur 1): une signature a été accordée, puis elle a fait l'objet d'une annulation de signature.

ACTSIG

Ce champ est vide tant que l'événement n'a pas été signé. Si est signé, le champ contient le code de la réponse qui a été saisi, tel qu'il est défini dans la table diverse numéro 54.

USRSIG

Lorsque la notification a été signée, ce champ contient le code de l'utilisateur qui a signé. Il ne s'agit pas forcément du destinataire d'origine, puisqu'un autre utilisateur peut avoir le pouvoir pour signer.

MAISIG

Lorsqu'un message incluant une demande de suivi par activation d'un lien http a été envoyé, ce champ permet de connaître l'adresse de messagerie de l’utilisateur qui a signé.

DATSIG

Si la notification de Workflow suppose un suivi (simple visa ou signature), ce champ contient la date de l’opération. Il reste vide tant que l’opération n'a pas été réalisée.

TIMSIG

Si la notification de Workflow suppose un suivi (visa ou signature), ce champ permet de savoir à quelle heure le suivi a été fait. Il reste vide tant qu'il n'a pas été réalisé.

REASON

Ce champ contient l'intitulé associé au code motif saisi à la signature de la règle, lorsque cette saisie est possible au moment de la signature. Ceci suppose qu’une liste de motifs possibles est définie par l'intermédiaire d'un numéro de table diverse


Sage 2011


Page 109


sur la ligne de signature correspondante. REACOD

Ce champ contient le code motif saisi à la signature de la règle, lorsque cette saisie est possible au moment de la signature. Ceci suppose que l'on définisse une liste de motifs possibles par l'intermédiaire d'un numéro de table diverse sur la ligne de signature correspondante.

REANUM

Lorsqu'une saisie de code motif a été prévue à la signature de la règle, on trouve dans ce champ le numéro de table diverse qui définit les motifs possibles sur la ligne de signature correspondante.

CELOBJ

Dans le cas d'un Workflow objet, on retrouve dans ce champ la clé de l'objet (c'est le champ Clé déclenchante d'origine). Dans le cas d'un Workflow de type signature, on retrouve dans ce champ le numéro chrono à l'origine de la signature. Dans tous les autres cas, cette zone n'est pas renseignée.

IDENTREF

Ce champ technique contient le code de la table déclenchante et le code de la clé correspondante, exactement de la même façon que pour le champ Identifiant ligne. Par contre, en cas d'événement de type signature, il reste vide, c'est-à-dire qu'il n'est pas transmis depuis la notification d'origine.

IDENTERT

Lorsqu'une icône de retour est associée au Workflow, ce champ contient le code de la fonction sur laquelle le retour se fait. Si la fonction est de type objet, on retrouve ensuite, séparé par un "/" Le code de la table, La clé correspondante. Les composants de la clé, pour une clé en plusieurs parties, sont séparés par le caractère "~".

IDENTGRP

Ce champ technique contient, dans l'ordre : Le nom de la table dans laquelle se trouve l'événement déclenchant d'origine, La clé courante liée au groupe qui a provoqué le déclenchement. Le séparateur entre table et clé est "/", le séparateur entre les segments de la clé (lorsqu'elle est composée de plusieurs champs) est "~". Le contenu est défini de la façon suivante : dans le cas d'un événement de type Signature, le contenu de la notification d'origine est repris. dans le cas où l'événement est de type Objet, le code de la table principale de l'objet est repris, si elle peut être déterminée dans les attributs de l’objet. La clé correspond à la clé courante lors du déclenchement du Workflow. dans tous les autres cas, la table est définie uniquement si un modèle de données est attaché au Workflow. Dans ce cas, c'est la table principale qui est renvoyée. La clé correspond à l'enregistrement courant lors du déclenchement.

NUMORG

Ce numéro chrono est renseigné uniquement sur les notifications liées à un événement de type Signature. Il permet de connaître le numéro chronologique de l'événement d'origine, celui dont la signature a déclenché la ligne courante.

USRORG

Ce champ n'est renseigné que sur les lignes associées à un événement de type Signature. Il permet de connaître le destinataire du Workflow d'origine (celui qui a effectivement reçu la notification après application éventuelle des règles de délégation : ce n'est pas forcément celui qui a signé).


Sage 2011


Page 110


DATREL

Ce champ contient la date à laquelle la dernière relance de signature a été faite sur la notification. Il n'est pas renseigné si aucun processus de signature n'a été mis en œuvre. Lorsque l'événement de Workflow suppose une signature, on peut gérer une date limite de signature et ensuite déclencher des relances basées sur cette date limite. Ces relances se font par des règles de Workflow batch nommées WRKREM1, WRKREM2, et WRKREM2E. Lorsqu'une relance de ce type est faite : le champ Nombre de relances, est incrémenté ce qui permet de savoir combien de fois la signature a été relancée. le champ Dernière date de relance, est modifié ce qui permet de connaître la date à laquelle la dernière signature a eu lieu. Si ces règles batch ne sont pas utilisées, et si aucune autre règle n'a été définie pour mouvementer ces champs, le nombre de relance reste égal à 0 et la date de relance reste vide, car aucun traitement standard du Workflow ne modifie cette valeur.

NBREL

Ce champ contient le nombre de relances de signatures faites sur l'événement de Workflow.

LEVSIG

Ce champ correspond au niveau des signatures, lorsque des événements de signature s'enchaînent : il vaut 0 sur l'événement d'origine. il vaut 1 sur l'événement déclenché par la première signature. à chaque événement qui s'enchaîne, il est incrémenté de 1. La variable LEVSIG correspondante est fréquemment utilisée dans les règles de Workflow lorsque la règle d'affectation de l'événement d'origine donne l'ensemble des signataires (1 à 9 maximum). Il suffit alors, dans l'événement d'origine comme dans les événements de signature qui s'enchaînent, de donner comme formule de destinataire USER(LEVSIG+1) pour avoir l'utilisateur numéro N dans la liste. Ceci permet notamment d'avoir des règles de signature récursives, exécutées tant qu'il reste des signataires.

CONTXT

Lorsqu'un Workflow envoie un message avec une icône de retour, le contexte de connexion (dossier, serveur, service, fonction...) est défini sous forme d'un champ alphanumérique. Ce champ technique contient la valeur de ce contexte. Les différents segments de ce champ sont séparés par le caractère "/".

CLEDEC

Ce champ contient la clé à l'origine du circuit de Workflow. Cette clé, lorsqu'elle est composée de plusieurs parties, se présente comme une concaténation des parties de clés séparées par le caractère tilde (~). Les valeurs de clé dépendent du contexte : sur un Workflow de type objet : c’est la valeur de la clé de la fiche à l'origine du déclenchement. sur un Workflow de type manuel : c’est la valeur de la clé de la table principale sur laquelle s'appuie le modèle de données du Workflow. sur un Workflow de type import/export ou sur une entrée dans une fonction, rien n'est renseigné dans cette zone. sur un Workflow de type édition, rien n'est renseigné si l'édition est lancée depuis une fonction d'impression (impression, ou impression par groupe). Par contre, si l'édition est lancée par Fichier/Impression ou Fichier/Liste depuis un objet, la clé de la fiche est renseignée dans cette zone. sur un Workflow de type signature : c’est la valeur de la clé héritée du Workflow


Sage 2011


Page 111


d’origine. ABROBJ

NBRUSR

USRTOP

VALCTX1 à VALCTX15

USRSIG1 à USRSIG9

Lorsque le premier événement à l'origine d'un circuit de signature est un objet, ce champ identifie le code de l'objet. Dans les autres cas, il est vide. Il est ensuite transmis aux différents événements de signature qui pourraient s'enchaîner au premier. Ce champ définit le nombre d'utilisateurs destinataires renvoyés par la règle d'affectation, lorsqu'il y en a une. S'il n'y en a pas, mais que la règle est de type Signature, le nombre de signataires défini par la règle d'origine est repris. Si aucune règle d'affectation n'existe, la valeur retournée est 0. Ce champ définit le premier destinataire de l'événement de Workflow. Un événement peut envoyer une notification à plusieurs séries de destinataires, chacun d'entre eux étant défini par une ligne dans le tableau des destinataires. Ce champ contient le code du destinataire évalué par la première ligne Si l'option de délégation est Non, Tous, ou Cascade. Si l'option est Le premier libre, et si l'utilisateur n'est effectivement pas présent, et a donné délégation, le champ l'utilisateur délégué est renseigné. Ces quinze champs contiennent les valeurs contextuelles évaluées au moment du déclenchement du Workflow à partir des formules saisies dans le tableau nommé Contexte de l'onglet Suivi du Workflow. Les valeurs stockées dans ce tableau peuvent être utilisées : pour transmettre à un événement de type Signature des informations utiles au traitement de la suite du processus pour faire apparaître des informations utiles dans les plans de travail exploités par le moniteur de Workflow. Dans ce cas, en paramétrage de la transaction, on définir un libellé particulier plus parlant. Quelque soit le format de l’information d’origine, les valeurs mémorisées dans ce tableau sont de type alphanumérique. Ce tableau de valeur contient les codes des signataires successifs, lorsqu'une règle d'affectation de destinataires renvoie plusieurs signataires pour la règle de Workflow. Cette information est utilisée pour permettre de gérer correctement les annulations de signature Sur les événements de type Signature pour lesquels aucune règle d'affectation n'est définie, les signataires associés à la règle déclenchante sont présents. Ainsi, lorsque plusieurs signataires en cascade ont été définis dans la règle d'origine, et que toutes les règles de signature qui suivent n'ont pas de règle d'affectation, le circuit complet de signature à chaque niveau est défini dans ce tableau. C’est la liste des utilisateurs définis par la règle avant l'application éventuelle de règles de délégation. Par exemple, si le premier destinataire de la règle de signature est absent, et qu'il est remplacé : le champ Signataire 1 contiendra le signataire d'origine le champ Premier destinataire contient le code du remplaçant à qui la demande de signature a effectivement été envoyée.


Sage 2011


Page 112


8.6. LE MONITEUR DE WORKFLOW Le moniteur Workflow permet de présenter les événements en attente de signature ou de visa pour un utilisateur donné. Cette présentation est paramétrable par transaction. Elle est issue des écrans et des fenêtres générées à l’aide des plans de travail. Les champs affichés dans les onglets sont dépendants de ces paramétrages. Les plans de travail doivent donc être définis en fonction des natures et des données nécessaires aux opérations qui seront gérées à partir du moniteur de Workflow par les utilisateurs. Les fenêtres générées sont constituées - d’un en-tête commun à toutes les transactions - des onglets générés spécifiques à chaque transaction, présentant les évènements de Workflow sélectionnés. - des boutons accessibles sur chaque ligne affichée dans les onglets qui dépendent - des droits de l’utilisateur - du statut de l’événement de Workflow affiché.

8.6.1. Entête Le champ délégué exceptionnel : cette case à cocher est saisissable s’il existe des évènements mémorisés dans la table de suivi qui sont affectés à l’utilisateur X3 connecté avec un statut de délégation exceptionnelle. Dans ce cas seulement, si l’utilisateur active ce flag, les évènements affichés dans les onglets seront ceux pour lesquelles la délégation est exceptionnelle. Le champ destinataire contient le code de l’utilisateur X3 destinataire des événements de Workflow. Si ce champ est non renseigné, tous les évènements sont affichés. Les champs date début et date fin définissent la fourchette de dates de sélection des évènements. Si ces dates sont renseignées, seules les données dont la date de dernière modification ou la date de création est dans la fourchette saisie. Par défaut, la valeur de la date de début proposée est la date du jour, diminuée d'un nombre de jours égal à la valeur du paramètre superviseur WRKDAY. Celle de la date de fin est la date du jour. Les éléments affichés dans les tableaux des onglets de la transaction dépendent du paramétrage des plans de travail. En fonction des droits de l’utilisateur connecté et du statut des évènements les actions ligne peuvent être utilisées pour :

8.6.2. Consultation 8.6.2.1.

Visualiser l’opération déclenchante

Cette action permet de revenir en zoom sur la fonction et le contexte à l'origine de l’événement de Workflow. Dans le cas d'un Workflow sur objet, cette fonction affiche la fiche correspondante de l’objet.

8.6.2.2.

Visualiser l’Opération déclenchante d'origine

Cette fonction est accessible lorsque l'événement à l'origine de l’événement est de type Signature. Dans ce cas, l’action permet de remonter à l'événement d'origine (si besoin de façon récursive) pour retrouver la fonction et la fiche qui ont déclenché le début du processus. Sage ERP X3 - Outils avancés

Sage 2011


Page 113


8.6.2.3.

Visualiser par Retour la fonction associée à l’icône retour

Cette action permet de revenir sur la fonction et dans le contexte décrit par l'icône de retour du paramétrage de Workflow. Si rien n'a été défini de particulier, c'est l'opération d'origine qui est proposée.

8.6.2.4.

Visualiser les Mails du groupe

Cette action permet de faire apparaître, dans une fenêtre de sélection, la liste des messages envoyés à tous les utilisateurs destinataires de la notification. Il y a une ligne pour chaque ensemble de destinataires définis par une ligne dans le tableau de paramétrage des destinataires de Workflow. A l’aide d’un double clique sur une des lignes, une fenêtre s'ouvre pour faire apparaître le détail du message envoyé et la liste des destinataires. Les champs suivants sont présents dans cette fenêtre : Destinataires : Définit la liste des adresses de messageries auxquelles la notification a été envoyée en tant que destinataires principaux. Copie : Définit la liste des adresses de messageries auxquelles la notification a été envoyée en tant que destinataires en copie. Objet : Contient le champ Objet du message tel qu'il a été envoyé. Accusé lecture : Contient la valeur du témoin accusé de lecture. Message : Contient le texte du message tel qu'il a été envoyé

8.6.2.5.

Visualiser l’historique mail

Cette action permet de faire apparaître, dans une fenêtre de sélection, la liste des messages envoyés aux utilisateurs successifs ayant signé la notification d'origine et les notifications suivantes (lorsque le processus de signature se fait à plusieurs niveaux). Les lignes apparaissent dans l'ordre chronologique inverse (les signatures les plus récentes d'abord). A l’aide d’un double clique sur une des lignes, une fenêtre s'ouvre pour faire apparaître le détail du message envoyé et la liste des destinataires comme indiqué précédemment.

8.6.3. Signature 8.6.3.1.

Effectuer la Signature de la notification

Cette action permet de déclencher le processus de signature de la ligne. Elle n'est disponible que si l'utilisateur a le pouvoir de signature, et si la ligne n'est pas déjà signée. Une fenêtre s'ouvre alors pour proposer un choix de réponses possibles, en fonction du paramétrage. Un motif supplémentaire peut également être saisi selon le paramétrage, voire un texte libre pour motiver un refus par exemple.

8.6.3.2.

Enregistrer l’accusé de Lecture

Cette fonction permet de donner un accusé de lecture sur la ligne. Cette fonction n'est disponible que si la ligne n'est pas lue. Aucune autre saisie n'est demandée, la ligne passant à l'état Lu à partir du moment où cette opération a été faite.


Sage 2011


Page 114


8.6.3.3.

Annuler une signature

Cette fonction permet d'annuler une signature déjà accordée. Elle permet de revenir à l'état antérieur à la signature. Elle n'est disponible que si les conditions suivantes sont toutes remplies : - La ligne a été signée - L'utilisateur en est le signataire - Le droit d'annulation a été accordé à l'utilisateur, c'est une des options de la fonction. - Il existe, dans le processus de signature, une réponse associée au code opération CAN. Ce code motif déclenchera l'action d'annulation de signature en remettant la ligne dans l'état d'avant la signature. Un autre Workflow de type signature, basée sur la règle d'origine et le code motif CAN, peut alors être déclenché si nécessaire. Cette opération est différente d'une opération de rejet de la demande ou de refus, qui sera traitée de façon tout à fait classique par paramétrage standard.


Sage 2011


Page 115


8.7. ERGONOMIE DU PLAN DE TRAVAIL 8.7.1. Boutons de navigation Les boutons de navigation permettant de parcourir les lignes du plan de travail. Premier événement sélectionné dans l’onglet actif. Dernier événement sélectionné dans l’onglet actif Evènement précédent Evènement suivant Saisie de critères de sélection complémentaires. Ce bouton permet d'ouvrir un écran de saisie d'un critère de sélection des lignes sous la forme d'une expression logique. Ce critère sera pris en compte à l’aide du bouton Rechercher En en-tête de critères de filtrage globaux sur les événements à traiter sont saisissables, sachant que des filtres plus fins peuvent exister sur chaque onglet de la fonction

8.7.2. Gestion des droits des utilisateurs Pour définir les droits des utilisateurs sur les opérations de signature dans les plans de travail. Il faut utiliser les habilitations fonctionnelles via Paramétrage \ Utilisateurs \ Habilitation fonctionnelle Pour la fonction SAIWRKPLN Moniteur de Workflow, les options disponibles sont : A : Annulation G : Signature U : Tous utilisateurs

L’utilisateur peut annuler une signature L’utilisateur peut signer les évènements dont il est destinataire ou délégué L’utilisateur à les droits de signature pour tous les utilisateurs du dossier.

Mettre en place des codes d’accès sur les plans de travail.


Sage 2011


Page 116


8.8. WORKFLOW – POINTS DIVERS 8.8.1. Workflow manuel Paramétage > Workflow > Workflow manuel Cette fonction permet de lancer un Workflow manuel, c'est-à-dire de parcourir la structure de données définie par le modèle associé à l'événement de Workflow et de déclencher les actions correspondantes : exécution d'actions, envois de notifications via la messagerie ou par un plan de travail. Cette fonction peut être lancée en batch. La tâche standard SAIWRKMAN est prévue à cet effet. Les paramètres d’exécution sont : Le code Règle Workflow qui identifie la règle de Workflow manuelle à exécuter. Le champ Filtre qui permet de saisir un filtre sous la forme d'une expression logique évaluée pour chaque ligne parcourue lors de l'exécution du modèle de données. Si cette expression est fausse, la règle n'est pas déclenchée pour la ligne en question. Ceci permet par exemple de borner l'exécution. Si ce champ est non renseigné, aucun critère de filtrage n'est appliqué. Le champ Simulation permet lorsque cette case est cochée, d ‘obtenir une trace détaillée décrivant les éléments sélectionnés l'opération n'est pas réellement exécutée, mais simplement simulée. Une trace détaillée qui décrit ce qui aurait été fait si l'opération n'avait pas été exécutée dans ce mode est produite.

8.8.2. Méthodologie de mise en œuvre 8.8.2.1.

Choix de paramétrage

Avant de paramétrer un nouveau processus de Workflow, quelques questions doivent être posées afin de choisir la meilleure approche de paramétrage. Quel sont les acteurs du processus de Workflow ? Utilisateurs X3 uniquement  Utilisation des règles d’affectation possible Partenaires X3  Utilisation des règles d’affection impossible Niveau de suivi des évènements de Workflow ? Gestion des processus de signature -> utilisation des notifications impossible Gestion de l’appel d’action associées -> utilisation des notifications impossible Typologie des évènements à gérer : - Si les évènements de Workflow sont liés à des objets X3, des fonctions, des éditions ou des processus batch et que les informations gérées par ces entités sont suffisantes pour construire les messages, alors l’utilisation des notifications répond au besoin. - Sinon les possibilités gérées par les règles de Workflow permettent des paramétrages beaucoup plus riches. Voir le chapitre sur les notifications, il est toujours possible de paramétrer une notification, de tester cette notification, et de transformer la notification en règle de Workflow. Dès que des notions de suivi, de plan de travail fonctionnel, sont exprimées il faut utiliser les règles de Workflow. Inventaire des données fonctionnelles à gérer dans les plans de travail


Sage 2011


Page 117


Cet inventaire permet de définir la liste des variables de contexte à paramétrer dans les règles de Workflow. Ce paramétrage doit être effectué avant la mise en service d’un Workflow. Les évènements pré existants dans la table de suivi, à une évolution des variables de contexte ne pouvant pas être modifiés par l’évolution de paramétrage. En standard, il est possible de gérer 15 données de contexte et chaque donnée étant limitée à 250 octets. La gestion des contextes est réservée aux règles de Workflow.

8.8.2.2.

Tests et diagnostics

Les causes de dysfonctionnement d’un processus de Workflow peuvent être multiples. Ce paragraphe est une approche pour faciliter la recherche des causes des anomalies. Utilisation du mode test, cette option n’est disponible qu’avec le paramétrage des règles de Workflow. Il faut mettre le flag mise au point de l’onglet général à oui. A l’exécution du Workflow une trace est affichée permettant de vérifier que les conditions de déclenchement du Workflow sont remplies.

Puis de contrôler si les conditions de déclenchement sont valides le message produit et les paramètres utilisés pour communiquer avec l’interface de messagerie. Table de référence Compteur groupe 0700000322 No chrono 0700000377 Envoi du message - Ordre système : meladx -v -s smtpasn -r Raymond.le-6:6+A1+B:B+A:A
From: [email protected] To: [email protected] Subject: Edition liste des patch “Test d’un workflow" #NOM? 220 : aydaix03.sagefr.adinternal.com ESMTP Sendmail Mon, 27 Aug 2007 15:34:13 +0200 HELO aydaix03.sagefr.adinternal.com 250 : aydaix03.sagefr.adinternal.com Hello aydaix03 [172.28.20.103], pleased to meet you MAIL FROM: 250 : 2.1.0 ... Sender ok RCPT TO: 250 : 2.1.5 ... Recipient ok DATA 354 : Enter mail, end with ." on a line by itself" From: [email protected] To: [email protected] Subject: Edition liste des patch Date: 27 Aug 2007 15:34:13 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary = ----- =_aaaaaaaaaa0"" Content-ID: <[email protected]> ------- =_aaaaaaaaaa0 Sage ERP X3 - Outils avancés

Sage 2011


Page 118

Sage ERP X3 – Outils avancées Date: 27 Aug 2007 15:34:13 +0100 Content-Type: text/plain; charset = iso-8859-1"" Content-ID: <[email protected]>

“Test d’un workflow" ------- =_aaaaaaaaaa0-. 250 : 2.0.0 l7RDYDb37430 Message accepted for delivery QUIT 221 : 2.0.0 aydaix03.sagefr.adinternal.com closing connection Envoi mail - [email protected] RLE"" Suivi signature #NOM? Fin normale de trace 27/08/07 15:34:14

Dans cette trace les informations importantes sont : -

-

Le N° de chrono généré par le processus de Workflow L’adresse E_mail de l’émetteur L’adresse E_mail du(es) destinataire(s) Le texte du message généré (en vert dans l’exemple ci dessus) . Cet affichage permet de vérifier que le paramétrage du texte à été correctement interprété. L’ordre système X3 exécuté pour adresser la demande à l’interface meladx (en mode serveur) avec le nom du fichier texte généré par la fonction pour transmettre le texte et les paramètres du message à envoyer. M0700000377.txt dans l’exemple ci dessus. Ce fichier est un fichier temporaire qui est purgé après l’envoi du message. Le niveau de suivi de l’événement de Workflow.

Si le message Message accepted for delivery est présent dans la trace et que celui-ci ne parvient pas à son destinataire, il faut effectuer une analyse au niveau du serveur de messagerie. Note sur les pièces jointes : Le paramétrage effectué au niveau d’un serveur de messagerie peut transformer et supprimer un message avec des pièces jointes en fonction du niveau de sécurité implémenté sur ce serveur.


Sage 2011


Page 119


8.9. WORKFLOW LIVRES EN STANDARD Ce chapitre présente des Workflow paramétrés et livrés en standard dans le dossier de référence DEMOFRA. Ils peuvent servir d’exemple pour voir les différents cas de mise en œuvre. Les valeurs des catégories de Workflow qui sont gérées dans la table diverse 51 doivent être complétées avant d’activer ces Workflow.

8.9.1. Workflow de sécurité

PSWNEW : Notification de réinitialisation du mot de passe Cette règle Workflow se déclenche sur l'événement divers PSW "Mot de passe" . La nature de l’événement est SEC (sécurité). Elle produit un message à destination de l’utilisateur et un suivi. Le message contient la valeur du nouveau mot de passe de l’utilisateur et un texte lui demandant de se connecter pour le modifier dans un délai imparti (2 jours/défaut). Pour que cette règle de Workflow soit opérationnelle, on doit rendre obligatoire la saisie d’un mot de passe à la connexion à l’aide du paramètre superviseur PASSWD géré dans le groupe sécurité (SEC). C’est un paramètre géré au niveau dossier valable pour tous les utilisateurs. Cette règle est utilisée lors de la création d’un nouvel utilisateur, ou en cas de modification de son mot de passe par une personne autorisée (via Fonctions/Mot de passe), si un mot de passe est obligatoire pour le dossier. Le paramètre PASSWD du chapitre superviseur (SUP) contenu dans le groupe sécurité (SEC) doit être égal à Oui. Le système attribue alors un mot de passe provisoire calculé aléatoirement, et déclenche automatiquement les événements de Workflow de type Divers basés sur le code PSW (attribution d’un mot de passe). Si un tel événement n’existe pas, le mot de passe provisoire est affiché à l’écran, afin que la personne puisse le noter et le transmettre à l’utilisateur concerné. Mais si un tel événement existe, rien n’est affiché à l’écran, et c’est l’événement en question qui est chargé de transmettre le mot de passe en question. Il va alors envoyer le mot de passe (qui est stocké temporairement dans la variable GMESSAGE) à l’utilisateur en question (sous réserve que son adresse de messagerie soit renseignée). La seule condition au déclenchement est que le champ ADDEML soit non vide dans l’écran de saisie des utilisateurs. C’est à cette adresse qu’est envoyé le message de confirmation, qui contient :


Sage 2011


Page 120


L’objet du message est : Un mot de passe temporaire a été attribué au compte utilisateur XXXX sur le dossier YYYY dans le texte, la confirmation du compte utilisateur et du mot de passe, ainsi qu’un texte l’avertissant que ce mot de passe est temporaire (il doit être changé dans les deux jours). En parallèle, un suivi sans signature est envoyé à l’administrateur général (qui est obtenu par la recherche de la valeur du paramètre ADMUSR) pour lui signaler qu’un mot de passe a été attribué. Aucune table n'est mise en œuvre par cette fonction.

BLKPSW : Verrouillage des mots de passe périmés Workflow de type manuel, basé sur le modèle de donné AUTILIS Il permet de verrouiller l’accès au dossier pour les utilisateurs n’ayant pas modifié le mot de passe dans les délais impartis (2 jours par défaut). La gestion des mots de passe doit être active pour le dossier. Il utilise l’action de Workflow AWRKUPDFLD pour affecter la valeur 1 au champ USRCONNECT de la table des utilisateurs AUTILIS. Cette règle permet de verrouiller les utilisateurs dont le mot de passe a été attribué de façon aléatoire par le système sans avoir été modifié ensuite dans un délai donné. Cette règle de Workflow, qui parcourt la table des utilisateurs en vérifiant leurs caractéristiques, a vocation à être lancée en batch avec une périodicité en rapport avec le délai de grâce (tous les jours si le délai est exprimé en jours). Les critères complémentaires de déclenchement sont les suivants : Le modèle de données AUTILIS (qui déclare simplement la table AUTILIS) pour parcourir la table des utilisateurs est utilisé. Si le code de l’utilisateur correspond à la valeur ADMUSR, On ne fait rien pour des raisons de sécurité. Ce code est celui de l’administrateur général du dossier. Détection des mots de passe attribués automatiquement, ils sont datés par le système au premier janvier 1970. Champ PASSDAT de la table AUTILIS. Vérification que le maximum de la date de création et de modification, plus deux jours, est inférieur à la date du jour, ce pour traiter le cas de la création (date de modification nulle) et la modification (date de modification supérieure à la date de création). Il est en effet à noter que tout changement de mot de passe met à jour cette date. Vérification que le compte de l’utilisateur n’est pas déjà verrouillé. Si toutes ces conditions sont vérifiées, alors le mot de passe n’a pas été modifié depuis son attribution. La règle déclenche l’envoi d’un message et d’une action.


Sage 2011


Page 121


C'est l'administrateur général qui reçoit un message lorsque les conditions de verrouillage du compte sont réalisées. L'événement de Workflow déclenche l'action AWRKUPDFLD de mise à jour d’un champ dans une table. Cette action modifie le champ USRCONNECT (autorisation de connexion), qui est forcé à la valeur 1 (Non).

BLKUSR : Verrouillage des utilisateurs inactifs Utilisant le même principe que la règle BLKPSW, cette règle à lancer en batch parcourt la table des utilisateurs. Elle permet de verrouiller les utilisateurs qui ne se sont pas connectés depuis un délai donné (fixé par défaut dans la règle à 120 jours). Cette règle de Workflow est de type manuel (le Workflow est lancé soit en direct, soit en batch). Les critères complémentaires de déclenchement sont les suivants : Le compte n’est pas celui de l’administrateur général (Valeur du paramètre superviseur ADMUSR). Le maximum des dates de création et de dernière connexion, plus 120, est inférieur à la date du jour. Le compte n’est pas déjà verrouillé. Si ces conditions sont vérifiées, un message est envoyé à l’administrateur général pour le prévenir et l’action AWRKUPDFLD est déclenchée. Cette action met le champ USRCONNECT à 1, ce qui interdit toute connexion à l'utilisateur en question. Seule la table AUTILIS est utilisée

CONHIST : Historique des connexions et déconnexions par utilisateur Workflow de type manuel basé sur le modèle de donnés CONHIST. Celui-ci utilise les tables AESPION [AES] et AUTILIS [AUS]. Il donne la liste des connexions, déconnexions sur une période de 20 jours sur le dossier courant. Ce Workflow produit un message et il utilise la règle d'affectation CONHIST (Historique des connexions). Attention, cet événement ne peut fonctionner que si la trace des utilisateurs est activée. C'est le paramètre superviseur TABTRA du groupe sécurité qui doit être égal à Oui pour les utilisateurs concernés. Il se base sur le parcours de la table AESPION par l'intermédiaire du modèle de données CONHIST, qui lit en même temps la table des utilisateurs.


Sage 2011


Page 122


Les critères complémentaires de déclenchement sont les suivants : Sélection des événements sur la période de 20 jours. La condition mise par défaut limite aux dates à partir du début du mois défini par la date courante moins cinq jours. Recherche les événements de type connexion et déconnexion (identifiés par leur code).

Regroupement des lignes par code utilisateur On envoie un message soit à une personne destinataire définie en fonction de l'utilisateur connecté dans la règle d'affectation CONHIST, soit au responsable de premier niveau déclaré dans la fiche de l'utilisateur et trouvé par le biais de la fonction AFNC CHEF(utilisateur,niveau) soit au destinataire issu de la règle d’affectation CONHIST (valeurs à paramétrer) L'objet du message donne le code utilisateur concerné, et le corps est composé d'un en-tête et d'une ligne par connexion ou déconnexion.

CONNECT : Alerte sur connexion infructueuse Cette règle permet de tracer les connexions de tous types (en principe, ce sont plutôt les connexions infructueuses qui sont tracées). Le contexte de déclenchement est l’événement de Workflow de type Divers nommé CON (Connexion), qui est activé dans tous les cas (connexion réussie ou refusée). Les critères complémentaires de déclenchement sont les suivants : Des tests sur la valeur de la variable GERR peuvent être réalisés. Cette variable prend des valeurs non nulles en cas d’erreur de connexion. On peut rechercher un code d'erreur particulier à l'aide de la fonction find, qui permet de donner une liste des codes que l'on souhaite tracer. La liste de codes d'erreur donnée dans le paramétrage par défaut est indicative, et sera modifiée en fonction de ce que l'on désire tracer. On envoie un message à l’administrateur général, identifié par son code défini par le paramètre ADMUSR, qui est accessible par la fonction func AFNC.PARAM("ADMUSR","") Le message contient le code utilisateur concerné, le numéro d’erreur et le message en clair envoyé à l’utilisateur, ainsi que la date et l’heure à laquelle la connexion ou la tentative de connexion a été faite. On utilise pour ce faire la variable GMESSAGE, qui donne un message clair expliquant les raisons du refus de la connexion. Différentes erreurs existent, elles sont précisées dans le tableau ci-dessous. Dans la règle fournie en standard, on propose de ne tracer que les connexions échouant pour cause de mot de passe incorrect. 1 2 3 4 5 6 7 8 9 10

Mot de passe incorrect (connexion automatisée) Code langue incorrect Code utilisateur inexistant ou inactif Nombre maximum de sessions par utilisateur dépassé Compte utilisateur verrouillé (trop de tentatives de connexion) Mot de passe incorrect Pas de menu de départ Connexion refusée par point d’entrée Nombre d’utilisateurs dépassé pour le profil Dossier verrouillé (en mode mono-utilisateur, en cours de sauvegarde, de revalidation, de remise à zéro, de resynchronisation… 11 Menu inexistant 12 Erreur de verrouillage durant la phase de connexion 13 Refus de saisie de mot de passe (sur demande de modification) Aucune table n'est mise en œuvre par cette fonction.


Sage 2011


Page 123


DECONNECT : Alerte des déconnexions sur time-out Cet événement permet de tracer les déconnexions sur time-out. Il s'agit de déconnexions automatiques gérées par le superviseur suite à une inactivité clavier supérieure à une valeur en secondes donnée par le paramètre superviseur du groupe session TIMEHGUP1. Il peut être intéressant d'activer temporairement cet événement lors de la mise en place de déconnexions automatiques, afin de régler au mieux ce temps de déconnexion pour éviter les déconnexions trop fréquentes. Cette règle de Workflow se déclenche sur l'événement divers "Time-out" et gère un suivi. Cet événement se déclenche sur le code événement TIM qui trace précisément ce type de déconnexion. Le super-utilisateur qui est défini par le paramètre superviseur ADMUSR, mais également par la variable globale GSUPER. Par défaut, on a défini à la fois un message et un intitulé pour le suivi, mais seule la case à cocher Suivi a été activée. Si on veut envoyer le message qui est déjà prédéfini, il suffit de cocher à nouveau la case correspondante. Le message, s'il est envoyé, donne le code de l'utilisateur, la date et l'heure de déconnexion, la fonction en cours (variable GFONCTION, qui est vide si l'utilisateur se trouvait au niveau du menu), ainsi que la valeur du paramètre de time-out. Aucune table n'est mise en œuvre par cette fonction.

8.9.2. Tracabilité

UPDFLD : Traçabilité de la base Cet événement est prévu pour gérer des alertes sur la modification de champs jugés sensibles dans les tables de la base. Ceci s’appuie sur l’onglet Audit défini dans le dictionnaire des tables. Celui-ci permet, sur des tables du dictionnaire, de tracer les modifications de champs jugés sensibles. Pour que la règle de Workflow puisse être utilisée, on doit au préalable : Préciser, pour chacune des tables concernées, les opérations (Création, Modification, Suppression) qui doivent être tracées. Ceci se fait dans l'onglet Audit de la gestion des tables. Une écriture dans la table principale d’audit AUDITH est gérée à chaque opération. Préciser les champs qui doivent être suivis sur modification, et pour quelles valeurs : il est possible de préciser un opérateur (inférieur, inférieur ou égal, supérieur, supérieur ou égal, égal, différent, comme, ou indifférent), et une valeur constante. Si la condition est réalisée et le champ modifié, on aura également une ligne dans la table AUDITL pour le champ, ligne reliée à l’en-tête de modification AUDITH, et contenant l’ancienne et la nouvelle valeur. Indiquer que les données d’audit sont gérées par un processus de Workflow à l’aide de la case à cocher « Workflow » Cette règle de Workflow est de type manuel, le Workflow est lancé soit en direct, soit en batch. Elle produit un message. La règle d'affectation UPDFLD (maj. champs dans la base) est utilisée par cette règle de Workflow. L'exécution de cette règle provoque alors le parcours de la table des lignes d’audit, pour retrouver les champs sensibles modifiés. Son déclenchement se faisant à la demande, il est conseillé de le lancer en batch avec une périodicité à définir.


Sage 2011


Page 124


La règle d’affectation est prévue pour associer à chaque table auditée, un utilisateur invariant. Des règles plus sophistiquées peuvent être mises en œuvre. Le modèle de données utilise la table AUDITL qui est liée à la table AUDITH par le champ SEQ (numéro de séquence unique). La règle parcourt et regroupe les lignes sur les champs de la table ([AUD]TBL) et champ ([AUL]COL), pour afficher dans un seul message pour toutes les modifications d'un même champ d’une table.

Les conditions du déclenchement de cette règle sont : Recherche des événements pour lesquels STA=2 (éléments non encore notifiés à l’utilisateur : la règle va par ailleurs modifier cet indicateur pour le passer à 3). Recherche de l’utilisateur [L]USER obtenu par l’utilisation de la règle d’affectation. Il faut définir un utilisateur par table dans la règle d’affectation. Le message est composé d’un en-tête et d’une ligne itérative. La formule |LIB| présente dans le corps du texte utilise la formule déclarée dans le champ Ligne. Func AFNC.F3C("20X",[F:AUD]ID1+string$([F:AUD]ID2<>"",";"+[F:AUD]ID2),[F:AUL]OVAL,[F:AUL]NVAL) +" "+func AFNC.FDH([F:AUD]DAT,[F:AUD]HOU) +" "+format$("K:10X",[F:AUD]ADOUSR)

La formule de la ligne fait appel à des fonctions dédiées définies dans le traitement AFNC, qui sont: La fonction F3C formate trois champs avec le format donné en tête. Elle permet ici de formater sur 20 caractères, avec le format "20X", les champs ID1 et ID2 concaténés identifiant la clé de la ligne modifiée, et les valeurs avant et après (champs OVAL et NVAL). La fonction FDH formate une date et une heure. Les paramètres étant les champs présents dans la table d’audit. Enfin, l’onglet action permet la mise à jour de l’indicateur STA dans la table d’audit AWRKHISSUI, d’abréviation AUD avec la valeur "3". Cette valeur correspond au statut Traité et évitera de traiter à nouveau cette modification. On utilise pour ce faire l’action standard AWRKUPDFLG, dont les arguments sont : ABREV = « AUD » -> abréviation de la table à mettre à jour FLD = « STA » -> code du champ à modifier VALEUR= 3 -> valeur du champ après modification Cette action est prévue pour permettre la modification de 4 champs d’une même table.

UPDPAR : Traçabilité des paramètres généraux Cet événement permet d’alerter des utilisateurs en cas de modification de paramètres généraux. Il nécessite l’activation d’un audit sur la table ADOPAR C’est un Workflow de type manuel exploitable en mode batch et interactif, basé sur les lignes d’audit conservées dans la table AUDITL. Les lignes notifiées ne le sont qu’une fois (le flag est modifié) Les modifications de paramètres au niveau utilisateur (table ADOVALAUS) ne sont pas tracées. Les modifications sont tracées uniquement pour les modifications de paramètre à un niveau global (dossier, société, législation ou site). Pré-requis


Sage 2011


Page 125


Un audit doit être paramétré sur la table ADOVAL, dans l’onglet Audit du dictionnaire des tables. Le paramétrage indique les conditions de trace des modifications. Les opérations suivantes sont tracées, la modification, la création et la suppression. La case Workflow est positionnée à oui. La clé de suivi est la clé ADW1 (dont le premier segment contient le code du paramètre). Ce code est présent dans le champ ID1 de la table de suivi AUDITH. Le champ à tracer est le champ VALEUR. C’est lui qui stocke la valeur du paramètre. Fonctionnement A ce workflow sont associés : - La règle d'affectation UPDPAR (maj. paramètres) - Le modèle de données UPDPAR qui contient - en table principale AUDTIL (lignes d’audit) - AUDITH entête d’une opération sur la table - ADOVAL valeur des paramètres généraux Cette règle parcourt la table d’audit et renvoie un message à un utilisateur défini par défaut par chapitre de paramètres (table diverse 911). Les modifications de paramètre sont regroupées par chapitre. Le paramétrage est basé sur les éléments suivants : A partir des données de la table AUDITL, les opérations suivantes sont réalisées : Une jointure de type (1,1) vers la table d’en-tête AUDITH, avec le champ [F:AUL]SEQ qui contient la clef primaire de la table AUDITH (numéro de chrono) Une jointure de type (1,1) vers la table des paramètres ADOVAL. Le code du paramètre modifié étant contenu dans le champ ID1 de la table AUDTIH. Le champ ID2 de cette dernière table permet d’identifier le niveau du paramètre modifié, est l’une des trois formes :

" ~SITE" "SOCIETE~ " "*~LEGISLATION" La règle d’affectation UPDPAR, basée sur le champ chapitre permet de définir, par chapitre un destinataire de message. Un Workflow Manuel est toujours considéré comme un Workflow Ligne, même s’il n’y a pas plusieurs niveaux de table dans le modèle de données. On définit dans le champ Regroupement le ou les champs sur lesquels doivent se faire la rupture (champs séparés par un point-virgule). Ici, on regroupe par le champ [ADP]CHAPITRE, ce qui correspond exactement au champ sur lequel on définit le routage à l’utilisateur. Les conditions d’envoi sont les suivantes : Le champ STA de la table AUDITH vaut 2, traitement de Workflow à effectuer sur l’enregistrement. La table concernée par l’audit est dans le champ TBL de la table AUDITH. La valeur de ce champ doit être égale à ADOVAL. La variable MODIF de la table ADOPAR doit être égale à 2. Ce test permet de ne pas voir apparaître les changements de valeur d’un paramètre nommé MONO, qui est modifié pour des raisons techniques de façon transparente pendant la transaction de modification de paramètres. Le champ [L]USER, qui correspond au code utilisateur renvoyé par la règle d’affectation, est non vide. Ainsi, pour ne pas tracer les modifications de paramètres d’un chapitre, il suffit de ne pas le déclarer dans la table d’affectation.


Sage 2011


Page 126


Il est à noter que cette dernière condition est de type En-tête, et pas de type Ligne. Ici les conditions de ligne sont utilisées pour filtrer les lignes directement dans la base. Ces conditions ne peuvent donc pas utiliser un champ qui est n’est évalué que lorsqu’un premier regroupement de lignes est détecté. C’est le regroupement qui détermine les attributs de l’ en-tête. Le destinataire est défini par la variable [L]USER précédemment évoquée. Le message comprend une partie objet et en-tête : La ligne de détail (insérée dans le texte par le biais de la formule |LIG|) formate dans l’ordre le code utilisateur l’opération, la date et l’heure, les valeurs avant et après du paramètre. A l’aide de la formule suivante :

func AFNC.F2C("5X",[AUD]ADOUSR,func AFNC.OPR([AUD]EVT))+" " +func AFNC.FDH([AUD]DAT,[AUD]HOU)+" " +func AFNC.F2C("10X",[ADP]PARAM,vireblc(ctrans([AUD]ID2,"~*"," "),4))+" " +func AFNC.F2P([ADP]TYPVAL,[ADP]NOLIB,[AUL]OVAL,[AUL]NVAL)


Sage 2011


Page 127


Les fonctions utilisées sont les suivantes : - La fonction F2C formate deux champs avec le format donné en tête. Elle est utilisée deux fois : o La première fois pour formater sur 5 caractères, avec le format "5X", les champs ADOUSR et une expression calculée à partir de la fonction OPR définie ci-dessous. o La seconde pour formater sur 10 caractères, avec le format "10X", le code du paramètre trouvé dans la table ADOPAR et le code site ou société, obtenu en supprimant les caractères "~" et "*" (fonction ctrans, pour remplacer par des espaces, puis fonction vireblc, pour supprimer les espaces). - La fonction OPR permet de transformer le code opération (INSERT, UPDATE, DELETE) en un intitulé plus parlant dans la langue de connexion de l’utilisateur. L’argument utilisé est bien entendu le champ EVT présent dans la table d’audit. La fonction FDH formate une date et une heure (les paramètres étant les champs correspondants dans la table d’audit). - La fonction F2P formate deux valeurs de paramètres dont on donne le type et le numéro de menu local. L'événement de Workflow déclenche l'action AWRKUPDFLD qui met à jour l’indicateur STA dans la table d’audit AUDITH, avec la valeur "3" pour indiquer que l’événement est Traité. Les tables suivantes sont utilisées par la règle: ADOPAR [ADP] AUDITH [AUD] AUDITL [AUL]

Paramètres Audit - En-tête Audit - Lignes

TRACE : Envoi de trace Permet de déclencher l’envoi d’une trace en pièce jointe d’un message, par la fonction Option / Envoi qui n’est active que si un événement de ce type existe Cet événement, lorsqu'il existe, permet à l'utilisateur qui affiche une trace dans le progiciel de provoquer un envoi de cette trace en pièce jointe d'un message. L’utilisateur utilise la fonction Option / Trace accessible depuis le menu de la fonction de visualisation des traces. Cette fonction n'est utilisable que si au moins un Workflow associé à l'événement divers TRA existe et est actif. Le message est modifiable, ce qui permet d'en changer le texte et les destinataires. Par défaut, c'est l'utilisateur ayant déclenché la visualisation de la trace qui reçoit le message.

ENDREQ : Fin de requête Cet événement permet d’alerter un utilisateur de la fin d’exécution d’une tâche batch qu’il a lancée.

OBJCRE : Création d’une fiche Ce Workflow générique est de type objet, il s’applique aux objets lors de la création d’une fiche. Il est à utiliser si la table principale ne possède pas le champ ENAFLG. Il est prévu pour notifier la création d’une fiche. Il ne gère pas de signature. La règle d'affectation OBJCRE (Création objet générique) est utilisée, pour affecter un destinataire par code objet. Le caractère générique de cette règle peut devenir complexe, si le nombre d’objet est important. Le code modèle associé n’utilise pas la table principale de l’objet ! Ce ne serait pas le cas pour une règle de signature «simple» liée à un objet bien déterminé. Sage ERP X3 - Outils avancés

Sage 2011


Page 128


Comme on a besoin de tester des informations issues de la structure de l’objet et de la table, le code modèle associé à la règle d’affectation a pour table principale la table ATEXTE. A cette table est liée, par un lien artificiel, la table des objets (lien 1,1). La clé de lien est ""+GABREV. La variable [V]GABREV est une variable globale qui permet, dans un contexte objet, de connaître le code de l’objet courant. Le contrôle d’existence dans la table d’origine est inhibé en mettant une expression résultant de la concaténation d’un champ vide et de la variable GABREV. Ainsi, dans l’événement OBJCRE, on dispose en ligne de la table AOBJET (structure de l’objet), et de la table ATABLE (table principale de l’objet). Ceci permet ensuite de tester l’existence du champ ENAFLG dans le dictionnaire de la table principale. On est en gestion d’objet (sans code objet précisé), en création de fiche. Les critères complémentaires de déclenchement sont les suivants : Le champ [ABV]ENAFLG n’existe pas (ABV étant l’abréviation de la table associée à l’objet, ce qui explique que l’on passe par une fonction evalue). La règle d’affectation des destinataires doit avoir rendu une valeur ([L]USER non vide). Un champ Intitulé doit exister dans la table principale de l’objet, pour permettre de renvoyer un intitulé dans le message. Cet intitulé ne peut pas être dépendant de la langue. De ce fait, ce Workflow ne pourra pas être utilisé pour des objets qui présentent cette particularité. Si nécessaire, une règle de Workflow non générique plus simple sera préférée. Le destinataire du message et du suivi est l’utilisateur contenu dans la variable [L]USER, alimentée par la règle d’affectation. L'exemple de message donné ci-dessous s'appuie sur la création d'une fiche tiers. Dans ce cas, l’objet du message envoyé suivrait le modèle suivant : Fiche Tiers MARTIN créée Pour obtenir ce modèle, utilise la formule suivante : mess(61,154,1)-func AFNC.TEXTE([AOB]LIBEL)-CLEOBJ-mess(62,154,1) L’intitulé de l’objet en partant du champ LIBEL de la table objet. Ce champ est de type « texte dictionnaire », il faut donc utiliser la fonction AFNC.TEXTE pour avoir le texte dans la langue courante de l’utilisateur envoyant le mail. La clé courante de l’objet est donnée par la variable CLEOBJ, qui est toujours renseignée dans un contexte objet. Le corps du message suivra alors le modèle suivant : Désignation : MARTIN et Associés Créé par : DOE ( John DOE ) A l’aide des formules |mess(63,154,1)-":"-evalue("["+[ATB]ABRFIC+"]"+[ATB]INTIT)| |mess(64,154,1)-":"-GUSER-"("+GNOMUSER+")"| s La désignation est obtenue en évaluant le champ intitulé de la table associée à l’objet. Les variables GUSER et GNOMUSER donnent le code et le nom de l’utilisateur courant (celui qui a créé la fiche). Le suivi réalisé dans cet exemple est minimal, puisqu’il n’y a pas de processus de signature. Il permet d’envoyer une ligne dans le moniteur de Workflow, avec l’intitulé : Fiche créée : Tiers MARTIN (Martin et associés) Avec la formule suivante : mess(65,154,1)-":"-funcAFNC.TEXTE([AOB]LIBEL)-CLEOBJ"("+evalue("["+[ATB]ABRFIC+"]"+[ATB]INTIT)+")"

Cet exemple concatène le nom de l’objet, la clé créée, et l’intitulé entre parenthèses. Sage ERP X3 - Outils avancés

Sage 2011


Page 129


La case Suivi étant cochée, l’utilisateur pourra simplement mettre un visa sans signature pour indiquer qu’il a lu la ligne en question.

OBJCRES : Création d’une fiche objet avec signature Ce Workflow générique de type objet est à utiliser avec les objets dont la table principale contient le champ ENAFLG. Cet événement déclenché par la création d'une fiche, est à l'origine d'un flux de signature qui permettra de mettre à jour l'indicateur Actif de la fiche. Si l’utilisateur n’a pas ce droit, un circuit de Workflow permet : De demander une signature qui rend la fiche active. De faire un retour au demandeur en cas de rejet (règle OBJREJ). De faire un retour au demandeur en cas d’acceptation (règle OBJVAL). Cet événement est générique, et est relativement similaire à l’événement OBJCRE, mais il diffère, dans ces cas d’utilisation, par les points suivants : Les conditions de déclenchement (création d’objet, nécessité d’avoir défini un destinataire pour l’objet dans la règle d’affectation OBJCRE) sont identiques. Le champ ENAFLG existe dans la table, et que la fiche a été créée avec le statut « Non actif » (ENAFLG=1). Ceci va permettre de compléter le circuit par une signature dont l’objet va être : soit de valider la fiche en positionnant ENAFLG à 2, soit de refuser et donc de positionner ENAFLG à 1. Le paramétrage de l’événement diffère donc de celui de l’événement précédent, puisqu’on va décrire à la fois l’événement à l’origine de la signature, et le processus de signature lui-même. Cette règle de Workflow se déclenche en gestion d'objet, uniquement sur les opérations de création. Elle utilise la règle d'affectation OBJCRE (Création objet générique) Les critères de déclenchement sont analogues à ceux de la règle OBJCRE (à ceci près que cette fois on teste l'existence et non l'inexistence du champ ENAFLG). La valeur de la variable ENAFLG, dans la table dont l'abréviation est donnée par le dictionnaire, doit être égale à 1. Un seul destinataire, celui renvoyé par la règle d’affectation. Les différents choix de signatures possibles sont : VAL : validation, qui va entraîner la mise à jour de l'indicateur Actif à Oui. REJ : rejet, qui va entraîner la mise à jour de l'indicateur Actif à Non. ESC : un dernier choix nommé Escalade, qui ne sera utilisable que si la date de signature est dépassée. Ce choix pourra être déclenché automatiquement par la règle WRKREM2. Actions déclenchées par l'événement L'événement de Workflow déclenche l'action AWRKUPDOBJ.

Cette action est déclenchée au traitement de la réponse que si celle-ci à pour valeur : VAL --> RESULT=1 REJ --> RESULT+2 L’action met à jour l'indicateur ENAFLG avec la valeur correspondante grâce aux variables de contexte Sage ERP X3 - Outils avancés

Sage 2011


Page 130


OBJET : code de l’objet --> CTX(3) CLE1 : Clef courante de l’objet --> CTX(4) FLD : Champ à mettre à jour --> ENAFLG VALEUR : Valeur après mise à jour --> RESULT Les événements OBJREJ et OBJVAL vont permettre de signifier un retour au créateur de la fiche. Nota : le Workflow ne s’applique pas sur les objets suivants : AWM Définition d’un modèle de données AWR Règles d’affectation AWV Affectation des utilisateurs AWO Historique des Workflow AWA Règles de Workflow ANM Gestion des compteurs de document

8.9.3. Suivi des signatures

WRKREM1 : Première relance Workflow Cette règle de Workflow est de type manuel, elle est lancée soit en direct, soit en batch. Elle est basée sur la liste des notifications en retard de signature ou de visa de plus de 1 jour ou de plus de trois jours si le niveau de relance est supérieur à 1. Les notifications à lire ne sont relancées qu’une fois Les notifications à signer le sont N fois Le niveau de relance et la date de relance sont mis à jour Cette règle parcourt l'historique des notifications AWRKHISSUI envoyées pour traiter celles qui sont en retard. Le texte géré dans l'onglet Suivi est rempli par défaut avec les données suivantes : Le numéro de chrono de la notification d'origine Le nombre de jours de retard. Il faut que la case à cocher correspondante soit activée dans l’onglet Général de la règle de Workflow pour que le suivi soit actif. Les critères complémentaires de déclenchement sont les suivants : L'indicateur FLGSIG, qui définit l'état de la demande, doit être égal soit à 2 (A viser), soit à 3 (A signer). -> find([F:AWS]FLGSIG,2,3)<>0 La notification ne doit jamais avoir été relancée si elle doit être visée. [F:AWS]NBRREL=0 or [F:AWS]FLGSIG=3 La date limite de signature demandée doit être dépassée de 1 jours et si la relance concerne une notification A signer, celle-ci sera relancée tous les 3 jours. date$-[F:AWS]DATMAXSIG>1+3*[F:AWS]NBRREL Le destinataire est celui à qui la notification originelle a été envoyée. Il est identifié par le code utilisateur défini dans la ligne d'historique [F:AWS]DEST. Si ce code est non renseigné, l'adresse email qui est renseignée [F:AWS]EMAIL dans la ligne d'historique est utilisée. Ceci peut notamment être le cas si la notification a été envoyée à un destinataire non utilisateur X3. L’événement de Workflow déclenche l'action AWRKUPDFLD qui permet la mise à jour des champs suivants de la table AWRKHISSUI : DATREL : la dernière date de relance (avec la date du jour), NBREL : le nombre de relances réalisées sur l’événement (incrémentant de 1). Sage ERP X3 - Outils avancés

Sage 2011


Page 131


Les tables suivantes sont utilisées par la règle WRKREM1 : AWRKHISSUI [AWS] Historique suivi Workflow AWRKPAR [AWA] Règles de Workflow AWRKPARF [AWF] Règles de Workflow (signature)

WRKREM2 Escalade automatique Cette règle permet de déclencher une escalade automatique sur les notifications pour lesquelles une signature n'a pas été faite en temps et en heure. Le principe de l'escalade est de provoquer la signature automatique de la notification d'origine avec le code ESC. Ceci suppose bien entendu que la règle d'origine autorise une réponse de type ESC. Ce type de réponse peut ne jamais apparaître comme un choix possible au signataire, en mettant une condition impossible du genre 1=0. Cette règle permet de répondre en remplacement du destinataire et en gardant une trace (Réponse ESC) de l’automatisme. Elle permet d’exécuter les actions prévues dans le processus de signature de l’événement d’origine. Cette règle de Workflow est de type manuel, elle est lancée soit en direct, soit en batch. Elle utilise le modèle de données WRKREM. Cette règle parcourt l'historique des suivis WRKHISSUI et utilise la table des règles de Workflow pour vérifier la présence de la réponse ESC. Les critères de déclenchement sont les suivants : La notification doit être dans l'état A signer Une relance est déjà effectuée La date de la dernière relance doit être dépassée d'au moins 1 jour. Dans le tableau des réponses possibles à la règle, le choix ESC escalade doit être paramétré. Le destinataire est le responsable hiérarchique au niveau 1 de l'utilisateur déclaré dans l’onglet « Rôles » de sa fiche. Le code de ce responsable est obtenu via la formule func AFNC.CHEF([AWS]DEST,1) Si la demande de signature n'est pas adressée à un utilisateur, mais directement à une adresse de messagerie, le champ n'est pas renseigné, donc aucune escalade ne sera envoyée. L'événement de Workflow déclenche l'action SIGWRK de signature d’un Workflow en lui transmettant les paramètres suivants [F:AWS]CHRONO : Numéro de chrono de l’évènement à signer [F:AWS]DEST : Code destinataire de l’évènement "ESC" : Code de la réponse liée à la signature. Les tables suivantes sont concernées par la règle WRKREM2 : AWRKHISSUI [AWS] Historique suivi des évènements de Workflow AWRKPAR [AWA] Règles de Workflow AWRKPARF [AWF] Règles des signatures des Workflow

WRKREM2E Escalade par défaut Cette règle permet de définir une action d'escalade par défaut lorsqu'il n'existe pas de signature de type ESC proposée dans la règle de Workflow d'origine. C'est une alternative à la règle de Workflow WRKREM2.


Sage 2011


Page 132


Cette règle de Workflow est de type manuel, elle est basée sur la liste des notifications. Elle utilise le modèle WRKREM qui permet d'avoir en ligne les suivis de Workflow et le paramétrage associé. Les critères complémentaires de déclenchement sont les suivants : La notification doit être dans l'état A signer Une relance est déjà effectuée La date de la dernière relance doit être dépassée d'au moins 1 jour. Dans le tableau des réponses possibles à la règle, , le choix ESC escalade ne doit pas être déclaré. Le destinataire est le responsable hiérarchique au niveau 1 de l'utilisateur déclaré dans l’onglet « Rôles » de sa fiche. Le code de ce responsable est obtenu via la formule func AFNC.CHEF([AWS]DEST,1) Si la demande de signature n'est pas adressée à un utilisateur, mais directement à une adresse de messagerie, le champ n'est pas renseigné, donc aucune escalade ne sera envoyée. L'événement de Workflow déclenche l'action AWRLUPDFLD pour signer l’événement d’origine avec les paramètres suivants: FLGSIG : Etat de l’événement : 5= signé ACTSIG : Code à l'origine de la signature : ESC=Escalade USRSIG : Utilisateur ayant signé : GSUPER=le super-utilisateur du dossier DATSIG : Date de signature : date$=la date du jour


Sage 2011


Page 133


Les tables suivantes sont utilisées par cette règle: AWRKHISSUI [AWS] Historique suivi des évènements de Workflow AWRKPAR [AWA] Règles de Workflow AWRKPARF [AWF] Règles des signatures des Workflow

ESCALA : Escalade générique Cet événement est de type signature, il est à utiliser s’il n’existe pas de procédure particulière. Il est déclenché par toute signature de type ESC (escalade) pour prévenir les autres acteurs lié à l’événement de la signature automatique. Il permet d’envoyer un message d’escalade : [L]USER(2) :Soit au prochain destinataire, si plusieurs destinataires sont définis par une règle d’affectation au niveau de la règle d’origine. func AFNC.CHEF([AWS]USRSIG,1) : Soit au chef du premier destinataire. Le message envoyé contient le texte suivant : L'événement-[AWS]CODWRK-aurait du être signé il y a-num$([AWS]DATMAXSIG-date$)-jours-"!" Emetteur-":"-[AWS]EMETTEUR-"("+Func AFNC.NOMUSER([AWS]EMETTEUR)+")" Signataire attendu-":"[AWS]USRSIG-"("+Func AFNC.NOMUSER([AWS]USRSIG)+")" Date limite prévue-":"-Format$("DD2:",[AWS]DATMAXSIG)| string$([AWS]TEXSUI<>"",Information sur le contexte d'origine-":"-[AWS]TEXSUI string$([AWS]IDENTRET<>"",L'icône jointe renvoie sur le contexte déclenchant) Il n’y a pas d’action associée, ni de suivi de ce message.


Sage 2011


Page 134


8.10.

FONCTIONS DEDIEES A LA CRM

Pour plus d’informations sur ces fonctions se reporter aux cours V140

8.10.1.

Paramétrage des signatures

Cette fonction permet de déterminer les critères de signature pour chaque couple Société - Type de document. Le type de document peut être une demande d'achat, une commande ou un contrat de commande ouverte. Les critères, au nombre de cinq maximum, sont paramétrables et peuvent être choisis parmi les rubriques des principales tables en ligne pour le type de document concerné.

8.10.2.

Règles de signature

Cette fonction permet de sélectionner pour une société et pour un type de document Achats (demandes d'achats, Commandes d'achats ou Commandes ouvertes d'achat) l'écran permettant de saisir les règles de signatures.

8.10.3.

Rectification des signatures

Cette fonction est un utilitaire permettant de rectifier des enregistrements concernant des documents à signer qui sont en anomalie. Ces anomalies peuvent être consécutives à un oubli de création de règles de signature ou à des modifications ou suppressions de paramétrage intempestives. En effet, lors de la création de demandes d’achats, de commandes ou de contrats (commande ouverte) et si la gestion des signatures est active, des enregistrements sont automatiquement créés dans la table des signatures notamment pour diriger automatiquement le document vers le premier signataire du circuit, qui est recherché dans la règle de signature correspondant au contexte. Lorsque cette règle n'existe pas, un message apparaît lors de la saisie du document lui-même et l'enregistrement est tout de même créé sans signataire. Tous ces enregistrements devront être traités par une personne responsable, de manière à régulariser la situation en créant les règles manquantes.


Sage 2011


Page 135


8.11.

NOTES TECHNIQUES Les points d’entrée

8.11.1.

Constitution des messages par le Workflow : Traitement AWRK MESSAGE : Ce point d’entrée permet de prendre la main à chaque envoi automatique de message par la fonction de Workflow. Il est ainsi possible de supprimer l’envoi du message et/ou d’exécuter un autre traitement à la place. Les tables suivantes sont en ligne : Table Contenu significatif AWRKPAR [AWA] Non AWRKPARC [AWC] Non AWRKPARF [AWF] Non AWRKPARH [AWH] Non

Intitulé Table Règles de Workflow Règles de Workflow (actions) Règles de Workflow (signature) Règles de Workflow (destinataire)

L’appel du point d’entrée MESSAGE est fait juste avant l’envoi effectif du message. La variable GPE est testée au retour du point d’entrée. Si sa valeur est différente de 0, le message n’est pas envoyé. Les tables AWRK* sont ouvertes mais seules les classes des tables concernant les règles de Workflow sont renseignées. Envoi des messages : Traitement AWRKMEL : EMAIL : Ce point d’entrée permet de modifier l’expéditeur d’un message envoyé par le serveur de message, Interface SMTP POP3. Il n’est pas possible de modifier l’expéditeur d’un message envoyé par un poste client X3. En effet, c’est l’instruction Send qui est utilisée dans ce contexte. L’appel du point d’entrée EMAIL est utilisé juste après l’ouverture du fichier texte de commande qui sert d’interface avec la fonction meladx. Ce fichier de commande est encore vide. La variable EXP_MAIL La variable USR_EMAIL(1..) La variable USR_ENVOI(1..) copies.

8.11.2.

contient le nom de l'expéditeur. contient les codes des destinataires. permet de distinguer les destinataires principaux des destinataires en

Epuration des tables

Dans un environnement de production Sage X3, la mise en place des audits et des Workflow doit s’accompagner d’une mise en œuvre des procédures d’épuration. Pour les Workflows Deux règles d’épuration des tables liées aux processus de Workflow sont livrées en standard. Ces règles seront à adapter en fonction du contexte. La formule ASUIVI permet de purger la table AWRKHISSUI qui contient le suivi des évènements de Workflow. Il faut modifier la formule d’épuration pour ne pas purger les évènements non signés ou non lu [F:AUS]FLGSIG =>4


Sage 2011


Page 136


La formule AMESSAGE permet l’épuration des tables : - AWRKHISMES Historique des messages Workflow - AWRKHISJOI Historique des pièces jointes liées aux messages - AWRKHISDES Destinataires des messages Nota : Avec le paramétrage livré en standard, les évènements à signer sont purgés. Pour les audits, la formule d’épuration à utiliser est AUDIT, pour les audits liés à un processus de Workflow modifier la formule d’épuration pour que les éléments à épurer vérifient la règle « Audit traité par le Workflow » [F :AUD]STA>2

8.11.3.

L’exécutable meladx

Le programme binaire « meladx.exe » qui se trouve dans le répertoire $ADXDIR\bin est utilisé par X3 pour envoyer un message à un serveur de messagerie. Il sert dès que le Workflow est paramétré avec l’option d’envoi depuis le serveur. La valeur du paramètre TYPMES dans le chapitre SUP égal à Serveur. Un message Sage X3 est constitué d’un entête suivi par une ligne vide et d’un corps de message. L'entête est constitué par une suite de lignes du type : nom_du_champ : champ La variable nom_du_champ peut être : From --> émetteur , To --> destinataire Cc --> Copie à Bcc --> Copie cachée Subject --> Objet du message Tout autre nom de champ est accepté sans interprétation, un nom de champ ne devant pas contenir les caractères : ()<>@,;:"\/.?= et bien sur chr$(32). Le corps du message est constitué de lignes de texte libre limité au jeu de caractères ascii 7bits, ainsi que de lignes de directives commençant par le caractère #. Si une ligne de texte doit commencer par le caractère #, il faut doubler ce premier caractère #. Une directive se traduit dans le message envoyé par un fichier joint. Il y a 2 types de directives : si la directive commence par <, le contenu du fichier sera pris dans le texte qui suit la directive, sinon la directive se terminera par le nom du fichier à joindre. La directive doit préciser le type et le sous-type (au sens mime des termes) du contenu du fichier, soit : image/gif ou image/jpeg, ... audio/... (basic,...) video/... (mpeg,...) text/... (plain,...) application/... (PostScript,octet-stream,...) Une description du fichier, entre crochets peut être ajoutée. Exemple de 'message X3' :

From: [email protected] To: [email protected] cc: [email protected] Subject: Test d'envoi de message via le binaire meladx Sage ERP X3 - Outils avancés

Sage 2011


Page 137


Test envoi x3 #
* Le chemin + nom de fichier mail correspond au nom du fichier généré par le Workflow Adonix. Son nom est égal à Mxxx.txt, où xxx est un numéro d'ordre. Le fichier se trouve en standard dans le répertoire /tmp du dossier. Attention pour que le mécanisme de Workflow fonctionne avec le protocole SMPTP, le port 25 doit être ouvert sur le serveur de messagerie.

8.11.4.

Appel d’un Workflow dans un spécifique

Pour appeler le moteur de Workflow dans un programme spécifique deux modes sont disponibles : Mode normal

Call WORKFLOW(TYPEVT,CODEVT,OPERAT,CLEOBJ) From AWRK Avec TYPEVT

Integer

CODEVT

Char

OPERA

Char

CLEOBJ

Char

Code de l’évènement de Workflow, valeur présente dans le menu local 988. Correspond au champ type d’événement de l’onglet général dans la définition des règles de Workflow. Code de l’événement. La valeur de ce champ est dépendante du type d’événement. Cette valeur répond aux mêmes règles que celles appliquées au champ code événement dans la définition d’une règle de Workflow. Code de l’opération. La valeur de ce code répond aux mêmes règles que celles appliquées au champ Opérations dans la définition d’une règle de Workflow. Clef de l’objet si le type d’événement est égal à Objet

Mode différé ou simulation Call WORKPLUS(TYPEVT,CODEVT,OPERAT,CLEOBJ,CODE,SIMUL,DIFFERE,TYPDEC,GRPDEB) Avec TYPEVT Integer Code de l’évènement de Workflow, valeur présente dans le menu local 988 CODEVT Char Code de l’événement OPERA Char Code de l’opération CLEOBJ Char Clef de l’objet si TYPEVT = Objet CODE char Code Workflow (cas du bouton W et du Workflow manuel Sage ERP X3 - Outils avancés

Sage 2011


Page 138


SIMUL

Integer

DEFFERE

Integer

TYPDEC

Integer

GRPDEB

Char

Réservé aux Workflow de type manuel Permet de simuler OU de générer un Workflow manuel Envoi du message en différé (transactions de création/modification d'un objet) Type de déclenchement en modification d’un objet Avant : 0 après mise à jour de la classe [F] : 1 Premier chrono groupe (utilisé pour l'envoi différé)

Dans les deux cas, le fichier trace doit être ouvert.


Sage 2011


Page 139


8.12.

LES LIENS DE WORKFLOW

8.12.1.

Fonctionnement

L’action de signature peut être déclenchée par l’activation d’une URL présente dans le corps du message qui est émis par le moteur de WorkFlow. Cela permet donc de signer un évènement de Worlfow hors du contexte Sage X3. Ce Paragraphe présente les composants mis en œuvre, pour que ce mécanisme fonctionne, ainsi que les prés requis de paramétrage.

Action de l’utilisateur dans sa Messagerie

Serveur WEB Sage X3

Serveur Batch Sage X3 Table de suivi des Workflow

Tâche AWRKSIG

L’URL présente dans le message reçu par l’utilisateur, pointe sur un serveur WEB Sage X3. Celui-ci dépose dans un répertoire un fichier séquentiel contenant le N° de processus de Workflow à signer et la réponse de l’utilisateur. Ce fichier sera pris en compte par la tâche batch AWRKSIG qui effectue la mise à jour de l’enregistrement de suivi du Workflow avec la réponse choisie par l’utilisateur. Si le serveur WEB n’est pas actif l’utilisateur est avertit. Si le serveur Batch ou la tâche de gestion des signatures AWRKSIG ne sont pas actifs. Les réponses sont conservées dans un répertoire dédié qui sera exploité à la prochaine exécution de la tâche AWRKSIG.


Sage 2011


Page 140


Pré-requis Pour utiliser les liens Workflow, un serveur X3 Web doit être mis en place et la solution utilisée doit être publiée sur ce serveur. En effet le serveur de liens Workflow est un composant du serveur web X3. Les valeurs paramètres WRKRMTDIR

Répertoire Liens Workflow. Ce répertoire doit être accessible en écriture, par le serveur WEB et par le serveur batch. C:\Sagex3\WEBV5\WebData\WORKFLOW\ Conseil : Utiliser un répertoire de la solution comme WebData qui permet de partager les données entre les deux composants serveur WEB & Batch.

WRKRMTHTTP

Adresse Http Liens Workflow Ce paramètre définit le serveur http utilisé pour recevoir des événements liés à un clic sur un lien inclus dans un message envoyé par le Workflow. Ce serveur http, configuré au préalable par la console d'administration, va ensuite créer un fichier récupéré par la tâche batch AWRKLNKACT, qui traitera l'action de retour. Le fichier est défini sur un serveur identifié la variable WRKRMTMAC, dans un répertoire dont la racine est donnée par le paramètre WRKRMTDIR A partir de cette racine, on retrouve un répertoire par solution (défini par la variable GINSTID), et un sous-répertoire par dossier. Exemple : sagex3v5:18880/AdxWfC Pour définir les attributs ce paramètre, il faut utiliser la console Le premier attribut de cette URL étant le nom du serveur sur lequel la solution X3 est publiée. Dans notre exemple c’est sagex3v5 Le second est numéro de port du serveur Apache, visible dans l’onglet configuration des serveurs WEB de la console. Le troisième est actuellement invariant avec la valeur AdxWfC.


Sage 2011


Page 141


WRKRMTMAC

Machine:Port Liens Workflow Ce paramètre permet de définir le serveur et le numéro de port sur lequel un service adonix est présent (par défaut, c'est le port courant), afin d'accéder au répertoire ou sont stockées les fichiers réponse. La syntaxe à utiliser est adresse_serveur:num Par défaut, si aucun serveur n'est précisé, c'est le serveur d'application de la solution Sage X3 qui est utilisé Conseil : Laisser dans une première approche la valeur par défaut.

WRKSINTER

Retour de workflow via internet. Ce paramètre permet de construire à l’émission du message, L’URL qui pointera sur le serveur WEB chargé de traiter la réponse. Exemple : http://sagex3v5:18880 Pour définir ce paramètre, il faut utiliser la console Le premier attribut de cette URL étant le nom du serveur sur lequel la solution X3 est publiée. Dans notre exemple c’est sagex3v5 Le second est numéro de port du serveur Apache, visible dans l’onglet configuration des serveurs WEB de la console.

WRKSINTRA

Retour de workflow via intranet. Ce paramètre permet de construire à l’émission du message, L’URL qui pointera sur le serveur WEB chargé de traiter la réponse. Remarques identiques à celles du paramètre WRKSINTER.

8.12.2.

L'action à déclencher

On définit ensuite l'action à déclencher (Dictionnaire des actions). Cette dernière doit obéir à un certain nombre de critères: Elle doit être de type Traitements divers, c'est à dire qu'elle renvoie simplement vers un sousprogramme AGL qui ne contient aucune instruction d'affichage. La case à cocher Workflow doit être activée. L'action doit posséder 4 paramètres: Sage ERP X3 - Outils avancés

Sage 2011


Page 142


Un paramètre de type Integer représentant un code retour, passé par adresse. Un paramètre de type Char représentant un message de retour, passé par adresse. Deux paramètres libres de type Char, passés par valeur. Un exemple de liste de paramètres valide: Dans cet exemple, une action XACTUSR est définie, de type Traitements divers Action XACTUSR: Activation ou désactivation d'un utilisateur (flag Actif Oui/Non) Paramètre Nom Type Type d'argument RET Code retour Integer Par adresse MES Message de retour Char Par adresse CODUSR Code utilisateur Char Par valeur ACTFLG Actif Oui/Non Char Par valeur

Cette action est utilisée pour donner la valeur 'Oui' (2) ou 'Non' (1) au flag 'Actif' (ENAFLG) d'un utilisateur X3. C'est une action de type Traitements Divers qui exécute le sous-programme suivant: ########################################################### # XACTAUS.src - Action XACTAUS ########################################################### Subprog ACTAUS(RET, MES, COD, OPT) Variable Integer RET Variable Char MES Value Char COD Value Char OPT Local File AUTILIS [AUS] Trbegin [AUS] Readlock [AUS]CODUSR = COD [AUS]ENAFLG = val(OPT) [AUS]UPDUSR = GUSER [AUS]UPDDAT = date$ Rewrite [AUS] Commit If val(OPT) = 2 Call ECR_TRACE("User"-COD-"activated by"-GUSER, 0) From GESECRAN Else Call ECR_TRACE("User"-COD-"de-activated by"-GUSER, 0) From GESECRAN Endif End

8.12.3.

La règle de Workflow

Pour insérer un lien action dans un message de Workflow, une ligne de texte (onglet Message) devra être associée à l'action définie, et les deux paramètres libres (type Char, par valeur), devront être renseignés. On active un lien en donnant la valeur Oui à la colonne Lien Action. Exemple: Dans cet exemple, on crée une règle de Workflow sur l'objet AUS (Utilisateurs) pour l'événement "Création". Lorsqu'un nouvel utilisateur X3 est créé, un e-mail est envoyé à l'administrateur du système. Texte "Utilisateur"-[M:AUS0]USR-"créé par"Sage ERP X3 - Outils avancés

Lien Action Non

Action

Param. 1

Sage 2011


Param. 2

Page 143


GUSER "Cliquer ici pour activer cet utilisateur": "Cliquer ici pour désactiver cet utilisateur":

Oui Oui

XACTAUS XACTAUS

[M:AUS0]USR [M:AUS0]USR

"2" "1"

Dans cet exemple renseigne les deux paramètres "libres" de l'action (les deux derniers) par les valeurs suivantes: Le code utilisateur créé ([M:AUS0]USR) pour le paramètre CODUSR La valeur 2 (Oui) ou 1 (Non) pour le flag 'Actif' de l'utilisateur (paramètre ACTFLG). ATTENTION: Pour qu'une règle de Workflow puisse utiliser les liens action, elle doit obligatoirement avoir un unique destinataire et ce dernier doit obligatoirement être un code utilisateur X3. On ne peut envoyer de Workflow avec lien à un contact tiers externe ou à une adresse e-mail fixe (e.g. "[email protected]"). La tâche batch à lancer Du côté de l'application X3, une tâche batch, AWRKLNKACT, sera chargée de traiter les demandes générées par le serveur Web lorsque les utilisateurs activent des liens Workflow. Il faut définir un abonnement de cette tâche AWRKLNKACT, avec une fréquence à définir selon le degré de synchronisation que l'on désire. La tâche AWRKLNKACT ne requiert aucun paramètre, mais utilise les paramètres généraux décrits cidessus (section 2).

8.12.4.

Les liens dans le workflow

Lorsqu'un nouvel utilisateur X3 est créé, la règle de Workflow est déclenchée et un message de ce type est envoyé au destinataire: Utilisateur NEWUSR créé par JDOE Cliquer ici pour activer l'utilisateur: http://appsrv/AdxWfC/action.jsp?C=161&K=5S2jvu&L=FRA&D=V140X3DEMO Cliquer ici pour désactiver l'utilisateur: http://appsrv/AdxWfC/action.jsp?C=162&K=xIfIPp&L=FRA&D=V140X3DEMO Lorsque l'utilisateur destinataire clique sur l'un des liens, un fichier est créé par le serveur web dans le répertoire de travail (défini par le paramètre WRKRMTDIR, cf. section 2). Ce fichier est ensuite traité par la tâche AWRKLNKACT, qui va générer la trace suivante: 16/03/07 17:23:06 Activation requête (51000) Nombre de fichiers action à traiter: 1 Traitement fichier lien: 161 User NEWUSR activated by ADMIN 16/03/07 17:23:06 Requête terminée (00000) Cette action va valider l'utilisateur NEWUSR en activant le flag ENAFLG lié à l'enregistrement de cet utilisateur. Elle sera signée (via les champs UPDUSR, UPDDAT) par l'utilisateur destinataire du mail de Workflow (ADMIN). D'autre part, le mécanisme de trace peut être attaché à la règle (tout comme à toute règle de Workflow). Lors de la visualisation des éléments dans le moniteur de Workflow, la colonne 'Liens' sera cochée pour les événements de Workflow ayant déclenché une action de lien.


Sage 2011


Page 144


9. LA GESTION DE LA DOCUMENTATION 9.1. INTRODUCTION Cette nouvelle fonctionnalité permet de personnaliser la documentation livrée en standard ou de développer la documentation sur les développements spécifiques. Cette fonction est intégrée au progiciel et est basée sur l’organisation des entités X3. L’entité de départ d’une documentation est la fonction X3 (AFC) à laquelle la documentation est rattachée. Les principaux composants d’une fonction peuvent faire l’objet d’une documentation particulière (Action, Ecran, Table etc..) L’organisation de la documentation est basée sur celle du dictionnaire X3. Une documentation peut être basée sur une table de liens permettant d’associer des compléments documentaires. Les éléments structurants d’une documentation sont : - Le code de la langue - Le type d’entité X3 documenté - Les composants associés.

9.1.1. Outils de base Les outils de base permettent la génération d’un squelette de documentation et une gestion automatique des paragraphes. Une utilisation des textes du dictionnaire Un éditeur HTML générant du XHTML Une gestion des documentations spécifiques avec des codes activité L’aide en ligne décrit précisément les différentes structures de documentation qui peuvent être produites. Avant de débuter l’écriture d’une documentation, consultez cette aide, afin de choisir la structure adaptée à la documentation à mettre en œuvre.

9.1.2. Les prérequis de mise en œuvre Dans la fiche utilisateur X3 du développeur de la documentation, les deux paramètres du groupe DOC lié au chapitre Superviseur doivent être renseignés. DIRDOC : Nom du répertoire destinataire de la documentation qui sera générée. Si ce répertoire est situé sur le poste client préfixer le chemin d’accès des caractères #@. Si le chemin d’accès contient le caractère % celui-ci est remplacé par la valeur du code de la langue dans laquelle la documentation est générée. DOCDOSS : Nom du dossier de référence documentaire. Le générateur de documentation parcourt le dictionnaire des données pour produire automatiquement la documentation. Cette variable permet de différencier le dossier contenant la documentation du dossier contenant les éléments documentés.


Sage 2011


Page 145


9.2. L’ORGANISATION DE LA DOCUMENTATION L’organisation d’une documentation doit respecter celle des entités X3. Par exemple pour documenter l’ensemble des composants d’une nouvelle fonction (AFC) on doit documenter les nouveaux composants utilisés ou rattacher la documentation existante des composants utilisés par la nouvelle fonction. - Les actions - Les écrans - Les codes activité - Les tables - Etc.. Une attention particulière doit être portée aux éléments communs à plusieurs fonctions.

9.2.1. Les paragraphes de documentation La documentation X3 est organisée en paragraphes. Un paragraphe est composé d’un squelette décrivant l’organisation hiérarchique des textes élémentaires qui le constituent. La description de la structure du paragraphe est mémorisée dans la table ADOCUMENT. Un paragraphe est accessible directement par l’aide en ligne. Exemple de paragraphe - Aide sur une fonction - Aide sur une édition C’est la compilation de cette structure hiérarchique avec les textes associés qui permet au générateur de documentation de produire les textes XHTML. Ces paragraphes peuvent être générés automatiquement en fonction de la typologie qui lui est associée (fonction / code activité …) Conseil : Pour générer les paragraphes d’une fonction accéder au dictionnaire des fonctions, et utiliser dans la barre des menus « Documentation » Développement > Dictionnaire traitements > Fonctions

Développement > Dictionnaire données > Documentation > Documentation


Sage 2011


Page 146


La clef de la fiche d’un paragraphe est constituée du code langue, du type de documentation et du code, ainsi que d'un niveau et d'un sous-niveau qui permettent d'organiser des tables des matières intermédiaires dans la documentation

9.2.2. Attributs d’une documentation Le code langue Le type de document. En général le type de document est identifié par le type de l’objet X3 documenté. Le code qui correspond à ce qui est documenté : le code de la fonction, le code du paramètre, le code activité, le code de la pièce automatique... Un niveau et un sous-niveau, qui décrivent les imbrications de paragraphes. Le titre du premier paragraphe de chaque niveau est repris dans une table des matières qui permet de pointer directement sur des sections de documentation. Lorsque plus d'un paragraphe existe dans un sousniveau donné, une sous-table des matières est créée pour les niveaux correspondants. La génération automatique depuis le dictionnaire crée les fiches avec des niveaux et sous-niveaux. Un code paragraphe qui détermine la façon dont le texte HTML va être généré. Cette génération peut se faire par simple copie du texte saisi dans la fiche, ou par une mise en page plus élaborée (inclusion d'éléments du dictionnaire sous forme de tableaux avec des liens hypertextes, par exemple). Un code écran, qui définit si on doit insérer, dans le bandeau du paragraphe correspondant, une icône permettant de déplier l'aide sur champ relative à l'écran donné. Un code activité, hérité du dictionnaire lors de la régénération, qui permet de faire notamment la distinction entre fiches standard et spécifiques, mais aussi de créer des documentations adaptées à des dossiers donnés en ne générant que les paragraphes et les documentations correspondant aux codes activité activés sur le dossier. Il est à noter que le code activité FAL (toujours faux) est pris en compte de façon particulière : un paragraphe marqué de ce code n'est jamais pris en compte par le traitement de génération, même si on demande une génération complète. Ceci permet de désactiver des paragraphes générés que l'on ne désire pas trouver dans une documentation.


Sage 2011


Page 147


9.2.3. Les types de documentation

Type

Elément documenté

Génération

Source du dictionnaire X3

Accès

ACN

Consultation

Oui

Dictionnaire des consultations

ACT

Code action

Oui

Dictionnaire des actions

ACV

Code activité

Oui

Table des codes activité

Alt F1

ADC

Points d'entrée

Oui

Dictionnaire des traitements

Alt F1

ADM

Variable de dimensionnement

Oui

Table des variables

Alt F1

ADP

Paramètres

Oui

Dictionnaire des paramètres

Alt F1

ADV

Tables diverses

Non

Dictionnaire des tables diverses

AD

Langage

Non

Mots-clés du langage

AFC

Fonctions du progiciel

Oui

Table des fonctions

AM

Modèles de développement

Non

AML

Menus locaux

Oui

Table des messages

AOE

Modèle d'import/export

Oui

Table des modèles

APM

Menus

Oui

Table des fonctions

ARP

Etats

Oui

Dictionnaire des états

ATB

Tables

Oui

Dictionnaire des tables

ATY

Types de données

Oui

Table des types de données

AWA

Règles de Workflow

Oui

Table des règles de Workflow

Alt F1

CDA

Destinations comptables

Oui

Table des destinations

Alt F1

CDE

Sections par défaut

Oui

Table des sections par défaut

Alt F1

DI

Documentations diverses

Non

*1

DL

Delta développement

Non

*1

FI

Fichiers liés

Non

Marqueur de fichiers liés

GAU

Pièces automatiques

Oui

Table des pièces automatiques

Alt F1

PS1

Déclencheurs statistiques

Oui

Table des déclencheurs

Alt F1

F1

Alt F1 Alt F1

*1 : Les types de documents DI et DL sont prévus pour documenter les personnalisations des fonctions standard ou gérer les documentations techniques.


Sage 2011


Page 148


9.2.3.1.

Squelette de la documentation d’une fonction (AFC)

La documentation d’une fonction est la plus complète car elle englobe l’ensemble des entités. Paragraphe Niveau / sous Niveau

Intitulé

TIT

10,10

Titre

PRE

10,20

Présentation

PRQ

30,10

Pré-requis

ACV

30,20

Codes activité

ADP

30,30

Paramètres concernés

ANM

30,40

Compteurs

GAU

30,50

Pièces automatiques

CDE

30,60

Sections par défaut

HAB

30,70

Habilitations

TRS

30,80

Transactions de saisie

GTC

30,80

Ecrans de consultation

PRD

30,90

Pré-requis divers

ECR

40,50

Gestion de l'écran

ENT

40,100

En-tête

ON1...

40,200*rang

Onglet no 1...

BOT...

40,suivant précédant.+5...

Clics droits sur ligne de tableau

BOU

70,10

Introduction boutons

BOU

70,10+10*no

Boutons sur fenêtre

BME

80,10

Introduction items de menus

BME

80,10+10*no

Items de menus dans la barre

INC

Item de menu pour gérer la documentation. Si la fonction est de type objet et le code de l'objet présent dans la table diverse 910, une entrée de menu Documentation est 80,500 / 80,510 / 80,520 créée automatiquement. Pour tenir compte de la présence de cette entrée, on réalise un lien vers les 3 paragraphes correspondants, tels qu'ils sont définis dans la documentation annexe ADO_FCT

ARP

50,10

Etats

ABT

60,10

Tâche batch

ERR

90,10

Erreurs

ATB

100,10

Tables mises à jour

La fonction de génération peut être utilisée lors de la définition d’une nouvelle documentation pour générer son squelette. L’aide en ligne présente pour chaque type de documentation les squelettes générés par défaut. Pour inhiber la génération d’un élément du squelette d’une documentation, il faut utiliser le code activité FAL. Pour un document paragraphe TIT doit être unique, en cas de doublon c’est le dernier lu qui est utilisé lors de la génération. Sage ERP X3 - Outils avancés

Sage 2011


Page 149


Les intitulés des premiers paragraphes des différents niveaux sont utilisés pour générer le sommaire de la documentation. La documentation des onglets d’une fenêtre est liée au rang des onglets dans la fenêtre de l’onglet qui varie de 1 à 15. Les différents codes des paragraphes sont déclarés dans la table diverse 911. Le squelette sera généré en fonction des entités trouvées dans le dictionnaire.


Sage 2011


Page 150


9.3. L’AIDE SUR LES CHAMPS Les aides sur les champs sont saisies dans un environnement dédié et mémorisées dans la table ADOCFLD. Cette séparation de ce type documentation permet la réutilisation de cette documentation quelque soit la fonction X3 qui utilise le champ. Développement > Dictionnaire données > Documentation > Documentation sur champs

Les documents HTML liés à ce type de documentation sont générés par la fonction de génération documentaire, en utilisant la case à cocher Aide sur champ et en précisant la fourchette des champs concernés.


Sage 2011


Page 151


9.4. L’EDITEUR HTML 9.4.1. Fonctionnement Un éditeur spécifique est disponible pour permettre la saisie des textes de la documentation qui sont conservés dans la table ADOCCLB.

Icône

Fonction

Exemple

Création d'un paragraphe

Texte.

Création d'un titre

Texte

Création d'un sous-titre

Texte

Texte gras ou normal

Texte

Texte italique ou normal

Texte

Texte souligné ou normal

Texte

Alignement gauche

Texte

Alignement centre

Texte

Justification

Texte

Alignement droit

Texte


Sage 2011


Page 152


Icône Fonction

Exemple

Liste

Texte 1 Texte 2

Décalage droit

Texte

Annulation d'une action décalage droit

Texte

Création d'un lien hypertexte

Texte

Image Bouton Texte Texte 1 2

Tableau

Texte Texte 3 4

Nettoyage sélectif du HTML Affichage et modification de la source HTML Alerte indiquant un problème dans le html. Permet de visualiser et de modifier le code html produit. 9.4.2. Boutons boîte de dialogue

Enregistrer la saisie Annuler la saisie

9.4.3. Les raccourcis clavier Enter

Création d'un paragraphe

Shift/Enter

Création d'une nouvelle ligne

Ctrl/c

Copier

Ctrl/v

Coller

Ctrl/x

Supprimer

Ctrl/a

Sélectionner tous les éléments

Ctrl/z

Annule l'action précédente

Double clic

suivant objet


Sage 2011


Page 153


9.4.4. Import des textes HTML Par copier / coller, il est possible d’importer le contenu d’une page WEB dans la documentation X3. Après l’opération coller, il est indispensable d’effectuer une opération de nettoyage du code HTML importé à l’aide du bouton

.

Il est possible de saisir directement le code HTML à l’aide de l’éditeur accessible par le bouton Les balises autorisées sont :
Paragraphe
Début de liste
Ligne de liste Tableau Ligne de tableau Conteneur de ligne de tableau
Ligne suivante d'un paragraphe Paragraphe de type code source Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 154 Sage ERP X3 – Outils avancées 9.5. LES LIENS DE DOCUMENTATION Pour enrichir une documentation, une fonction permet de gérer des liens de documentation entre cette documentation et des éléments du dictionnaire. Ces liens sont conservés dans la table ADOCFNC et sont utilisés lors de la génération de la documentation HTML. Les liens possibles sont dépendants du type de document auquel on désire rattacher des éléments du dictionnaire. Développement > Dictionnaire données > Documentation > Liens de documentation Un lien possède les attributs suivants : - Type de l’élément du dictionnaire rattaché (Exemple Table, Code activité …) Description du type de lien Clef du lien Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 155 Sage ERP X3 – Outils avancées 9.5.1. Relations autorisées pour une fonction La documentation d’une fonction peut être enrichie par les liens suivants : Lien Signification Utilisation lors de la génération de documentation compl. ACV Code activité Liste des codes activités concernés dans les pré-requis. Oui ADP Paramètre Paramètres concernés dans les pré-requis. Il est à noter que ce lien est aussi utilisé pour alimenter la section Fonctions concernées dans l'aide décrivant le paramètre. Il n'est donc pas utile de renseigner le lien réciproque si le lien direct est défini. Non ANM Compteurs Liste des compteurs associés à la fonction dans les pré-requis. Non Liste des pièces automatiques associées à la fonction dans les prérequis. Non CDE Codes section Liste des codes section associés à la fonction dans les pré-requis. Non TRS Transactions Liste des fonctions permettant de définir des transactions pour la fonction documentée. Non Liste des tables diverses dans les pré-requis fonction. Non AML Menus locaux Liste des menus locaux à paramétrer dans les pré-requis. Non ARP Etats Etats lancés depuis la fonction. Oui ABT Tâches batch Annexe des tâches batch permettant de lancer la fonction. Oui ATB Tables Tables mises en œuvre dans la fonction. Oui GAU ADI Pièces automatiques Tables diverses Les relations autorisées sont déclarées dans la table diverse 913 Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 156 Sage ERP X3 – Outils avancées 9.6. LA GENERATION DE LA DOCUMENTATION Cette fonction est utilisée : - pour générer le squelette d’une documentation - pour générer les aides sur champs - pour générer une documentation Développement > Dictionnaire données > Documentation > Documentation Bouton « Génération » Toutes langues : Langue : Choix de la langue dans laquelle la documentation doit être générée Type : Type du document à générer Code de à : Fourchette de sélection des entités documentaires à générer Génération ADOCUMENT : menu de sélection du squelette de la documentation Non : pas de génération Toutes : Tous les paragraphes liés au type de document sont générés Documentation existante : Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 157 Sage ERP X3 – Outils avancées Génération document final Non : pas de génération Complètes: Génération de l’ensemble de la documentation Selon code activité Aides sur champs liés Cette option permet de générer les aides sur les champs liées aux masques inclus dans la fonction ou l’action dont on génère la documentation. Les codes des aides sur les champs sont déclarés dans l’objet de définition des masques (colonne aide). Aide sur champs Option de génération des aides sur les champs, indépendamment des liens avec les masques. 9.6.1. Les répertoires des documents générés FCT Documentation sur les fonctions FLD Documentation sur les aides sur champs MCD Documentation sur les tables Documentation sur les menus locaux OBJ Documentation sur : - les actions (ACT), - les types de données (ADP), - les états (ARP), - les sous programmes (ASU), - les codes activité (ACV), - les points d’entré (ADC), - les variables de dimensionnement (ADM) - les variables globales (AGB) - les modèles d’import export (AOE) - Etc.. MODEL Documentation technique sur les modèles Sage X3 L4G Documentation technique sur le langage Sage X3 INSTALLATION Documentation sur la mise en œuvre d’un dossier Sage X3 CONSOLE Documentation sur l’utilisation de la console SAGE X3 Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 158 Sage ERP X3 – Outils avancées 9.7. PUBLICATION DE LA DOCUMENTATION Les éléments de documentation peuvent être transférés dans un nouveau dossier soit à l’aide de la fonction de copie disponible sur les trois fenêtres de gestion des objets documentaires, soit par l’intermédiaire d’un patch en utilisant les entités ADO et ADF. Les éléments de documentation générés (les pages HTML) doivent être transférés dans le répertoire de publication de la documentation. Ce répertoire est déclaré lors de l’installation dans la console Sage X3. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 159 Sage ERP X3 – Outils avancées 10. LES OUTILS DU SUPERVISEUR 10.1. INTRODUCTION Ce chapitre présente plusieurs ensembles de fonctions permettant d’administrer à partir d’X3 les éléments d ‘un dossier. Certaines permettent de se substituer à des fonctions techniques et nécessitent des connaissances d’administrateur Base de données ou Système. Ils font pour la plupart partie du développement Ces fonctions peuvent avoir des incidences sur la cohérence de la base ou du dossier. Elles sont donc à manipuler avec précaution. - Maintenance (mode fiche, maintenance en colonne, transactions système) - Vérifications (Infos version, Vérification 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) Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 160 Sage ERP X3 – Outils avancées 10.2. OUTILS DE 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, dont l’usage doit être réservé à l'installateur du logiciel. Remarque : Une trace des champs modifiés par les maintenances en ligne, en colonne la trace des transactions systè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 une fonction de 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 / Modification /Suppression…) et, en cas de modification, une ligne par champ modifié, avec la valeur avant et après modification. 10.2.1. Maintenance par enregistrement Cette fonction permet d’accéder en création, modification ou suppression à un enregistrement d’une table de la base de données. Développement > Utilitaires > Maintenance > En ligne Le choix de la table permet de visualiser et de modifier un ou plusieurs champs de l’enregistrement affiché Aucun contrôle n’est effectué sur les opérations réalisées. Une trace de ces opérations est mémorisée dans la table AESPION Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 161 Sage ERP X3 – Outils avancées 10.2.2. Maintenance en colonnes Cette fonction est similaire à la précédente. Elle se décompose en étapes. Développement > Utilitaires > Maintenance > En colonne La première colonne permet de sélectionner les rubriques de la table qui seront : - Affichées - Saisissables - Invisibles Et de définir un éventuel critère de sélection. L’utilisateur peut effectuer une saisie sur plusieurs colonnes puis enregistrer ses modifications dans une seule transaction. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 162 Sage ERP X3 – Outils avancées 10.3. OUTILS DE VERIFICATION 10.3.1. Infos version Cette fonction est accessible à partir de l’aide en ligne dans la barre de menu avec le choix ? / A propos Elle donne les numéros de version du poste client, de serveur d’application et du serveur de traitement. Le bouton informations techniques permet de visualiser les informations concernant la licence Sage X3. Remarque : Les informations techniques et les niveaux de version des composants de la solution sont nécessaires à la Hot Line ainsi que le niveau exact de patch Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 163 Sage ERP X3 – Outils avancées 10.3.2. Surveillance des services Les services nécessaires au bon fonctionnement des composants de la solution Sage X3 sont gérés à l’aide de la console. Le cours sur l’installation présente ce composant. A partir de l’application Sage X3 une fonction de surveillance permet de visualiser les principaux chemins d’accès permettant de gérer le serveur de traitement Sage X3. 10.3.3. Vérification 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). 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. Développement > Utilitaire > Vérification > Données > Cohérences Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 164 Sage ERP X3 – Outils avancées Cet utilitaire est en général lancé de façon très ciblée, par exemple après une opération de maintenance. Il produit une trace pour chaque table à analyser. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 165 Sage ERP X3 – Outils avancées 10.3.5. Symboles verrouillés Des verrous logiques sont posés par les traitements avant de d’effectuer un verrou de type base de données. Cette fonction permet de consulter les verrous logiques actifs. (table APLLCK) Développement > Utilitaires > Vérifications > Symboles vérouillés Un zoom est possible de cette fonction vers la gestion des sessions En gestion d’objet, le symbole verrouillé correspond au code de l’objet, suivi de la clé courante (dans l’exemple ci-dessus, la facture d’achat (PIH) AVF0904ASN00001 est verrouillée par l’utilisateur ADMIN 10.3.6. Traitements verrouillés Développement > Utilitaire > Vérification > Verrous > Traitement verrouillés Cette fonction concerne les traitements source verrouillés par un développeur. Une suppression du verrou est possible (par clic droit) Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 167 Sage ERP X3 – Outils avancées 10.3.7. Analyse des mémos Développement > Utilitaire > Vérifications > Analyse mémos En gestion d'objet, chaque utilisateur peut poser, par l'intermédiaire du menu Sélection / Sélection avancée, des filtres destinés à sélectionner dans la liste gauche une partie seulement de la table. Une telle sélection peut ensuite être mémorisée, et réutilisée régulièrement. Cette fonctionnalité intéressante est néanmoins source de problèmes potentiels de performance lorsque les tables ainsi filtrées sont très volumineuses (plusieurs centaines de milliers de lignes). Elle l'est d'autant plus que ces mémos peuvent être standard (chargés dès que l'utilisateur entre dans la fonction), et globaux (Utilisés par un ensemble d'utilisateurs). La fonction d'analyse permet, a posteriori, de détecter des problèmes potentiels de performance compte tenu des mémos posés par les utilisateurs dans un dossier. Attention, elle ne donne que des indications, une analyse effective des mémos incriminés doit être réalisée avant de les modifier. Il est néanmoins prudent de vérifier, pour chaque ligne de trace ainsi trouvée, la pertinence du message d'erreur, en prenant des mesures correctives. Ces mesures peuvent être: - suppression du mémo correspondant ou avertissement à l'utilisateur - ajout d'un index d'optimisation si celui-ci paraît adapté - restriction sur un mémo public Le paramètre superviseur SELWARN du groupe PRF, 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 superviseur AUZMEMO Il est à noter que deux paramètres, mentionnés ci-dessous, permettent de contrôler a priori les mémos créés par les utilisateurs. Mais ces mémos ne sont contrôlés qu'à leur création. Or des mémos jugés performants à l'origine peuvent très bien ne plus l'être quelques mois après, si la volumétrie de la base les rend lourds à l'exécution. C'est pourquoi il est intéressant de lancer cet utilitaire même si les deux paramètres ci-dessous sont correctement renseignés.* Afin d'obte fêqr44 134.944 toBT1 0 0 u34.04 Tm[(A)1 Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 168 Sage ERP X3 – Outils avancées 10.3.9. Recherche des index Le dictionnaire des tables décrit des index dont Sage 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 standards. 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 ou 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 Remarque : 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 patchs 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 Sage X3. Ces deux dernières catégories ne posent pas de problème de performance. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 171 Sage ERP X3 – Outils avancées Ci dessus un exemple de trace généré par le traitement Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 172 Sage ERP X3 – Outils avancées 10.4. OPTIMISATION BASE DE DONNEES Sage 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 10.4.1. Propriété de la base de données Développement > Utilitaire > Vérifications > Base de données > Propriétés Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 173 Sage ERP X3 – Outils avancées 10.4.2. Processus Base de données Cet outil est à utiliser si l’on constate des disfonctionnements de l’application. Il permet de consulter les processus d’accès à la base de données actifs et les verrous posés sur des ressources de la base de données. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 174 Sage ERP X3 – Outils avancées 10.5. OPTIMISATION BASE DE DONNEES 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) Remarque : 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. Paramétrage > Exploitation > Données > Optimisation base de données 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é). Développement > Utilitaire > Vérifications > Base de données > Processus Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 175 Sage ERP X3 – Outils avancées 10.6. UTILITAIRES DICTIONNAIRE 10.6.1. Validation Cette fonction permet de valider en masse un ensemble d'éléments du dictionnaire. C'est-à-dire de générer le code ou de mettre à jour la base de données conformément aux informations du dictionnaire. Ces éléments du dictionnaire peuvent être définis par des cases à cocher et par des bornes de noms. Cet utilitaire permet donc de réaliser les opérations identiques à la fonction de validation de dossier, mais de façon plus sélective et donc plus rapidement. Développement > Utilitaire > Dictionnaire > Validation > Dictionnaire La validation du dictionnaire permet de s’assurer que les éléments techniques issus des différentes générations de code sont en phase avec le dictionnaire. 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. Il est en outre possible de filtrer uniquement les éléments concernés par leur appartenance à un module, par un type de données (si celui-ci a changé, par exemple), ou un code activité donné. Enfin, contrairement à la validation de dossier, qui va réaliser le travail dans toutes les langues dans lesquelles le dossier est géré, il est ici possible de ne choisir qu'une seule langue. Il est fortement conseillé aux utilisateurs connectés sur le dossier de se déconnecter. Cet utilitaire peut être amené à modifier la structure des tables, ou à modifier des écrans qui sont en mémoire d'un processus encore actif. L’exécution de cette fonction peut être long, et peut être réalisé en batch à l’aide de la tâche standard VALDICO. Un fichier trace est créé dans tous les cas. On y retrouve le détail des opérations effectuées, et des erreurs éventuelles. Il est conseillé de lire attentivement ce fichier lorsque l'opération est terminée Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 177 Sage ERP X3 – Outils avancées 10.6.2. Copie dictionnaire Développement > Utilitaire > Dictionnaire > Copie > Dictionnaire Cette fonction permet de copier en masse un ensemble d'éléments du dictionnaire d'un dossier vers un autre. Ces éléments du dictionnaire peuvent être définis par des cases à cocher, par des bornes de nom, et par une date (éléments mis à jour plus récemment qu'une date donnée). Il est en outre possible de filtrer uniquement les éléments à copier concernés par leur appartenance à un module, par un code activité donné. Enfin, le transfert d'un élément peut s'accompagner de la copie des traitements associés, et phase de la validation du dictionnaire sur les éléments copiés dans le dossier d'arrivée peut également être lancée. Lorsqu'on référence un autre dossier, pour des opérations de copie ou de comparaison, par exemple, il est possible d'utiliser les syntaxes suivantes : DOSSIER (le nom du dossier directement : dans ce cas, le dossier est censé être accessible directement sur le même serveur et le même service) serveur@DOSSIER (le nom réseau du serveur où se trouve le dossier doit être indiqué : un service adxd doit fonctionner sur le numéro de service courant pour permettre la connexion) serveur:service@DOSSIER (même principe que ci-dessus, mais le numéro de service peut être différent. Ceci donne, par exemple, la syntaxe serveur_01:1802@DEMO) Si la copie se fait d'un dossier de même type (par exemple de type X3 vers un autre dossier de type X3), cette condition est toujours remplie lorsqu'on part du dossier superviseur (X3 dans le cas présent), puisque toute installation d'un progiciel en technologie Sage X3 suppose qu'un dossier superviseur soit installé au minimum sur les serveurs où des dossiers sont présents. Il est donc conseillé d'utiliser la copie depuis le dossier superviseur (X3 si c'est X3 Entreprise) dans ce cas : il est en effet parfaitement possible de copier un élément depuis un dossier qui n'est pas le dossier courant (même si le dossier courant est proposé par défaut), vers un autre dossier qui n'est pas non plus le dossier courant. Si la copie se fait entre deux progiciels différents de la gamme SAGE X3 (par exemple X3 Entreprise, Geode GX, Abel X3, Sage RH), cette condition n'est plus remplie. Il est alors recommandé de référencer les dossiers sur lesquels on désire faire des copies dans l'onglet de définition des liens de la fiche dossier. Par ailleurs, lorsqu'un traitement est associé à l'élément du dictionnaire à copier, ce traitement n'est pas copié. Il sera nécessaire de le faire manuellement. De même, les éléments dictionnaire comme un type de donnée, un code activité etc…définis dans l'élément à copier, ne sont pas copiés. Enfin, lorsque des opérations de copie induisent des validations (génération de code), elles ne sont en général pas réalisées lorsque le dossier d'arrivée est sur un serveur différent . Il vaut alors mieux passer par des validations de dictionnaire sur le dossier d'arrivée. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 178 Sage ERP X3 – Outils avancées 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 Sage X3. Remarque : 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 serveur@DOSSIER:service permet d’accéder à un dossier situé sur un autre serveur, accessible par un autre numéro de service. La phase de validation (i.e. de génération de code) peut être enchaînée à la copie. 10.6.3. Différence d’objets Développement > Utilitaire > Dictionnaire > Analyseur de différence > Objets Cette fonction permet de comparer globalement des éléments du dictionnaire entre deux dossiers. Le résultat est obtenu sous la forme d'un fichier trace plus ou moins détaillé, selon les options de lancement. Ainsi qu'on le remarquera, on retrouve, dans la trace, l'identification de l'élément et des sous-éléments (écran, champ, action, par exemple), ainsi que le nom du champ du dictionnaire sur lequel se trouve la différence. Les noms des champs n'apparaissent pas si la case à cocher Technique n'est pas cochée. Cet utilitaire est très long à l'exécution s'il est lancé sur la totalité du dictionnaire. Dans ce cas il est conseillé de l’exécuter en mode batch à l’aide de la tâche standard ACOMPOBJ. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 179 Sage ERP X3 – Outils avancées Ces outils permettent de réaliser les opérations suivantes : Génération du code associé aux transactions applicatives paramétrables Copie de transactions applicatives paramétrables vers un autre dossier 10.6.4. Validation des fonctions Développement > Utilitaire > Dictionnaire > Validation > Fonction Cette fonction permet de mettre globalement à jour les informations des tables stockant les informations d'habilitation croisées utilisateurs / fonctions. Elle est essentiellement utile lorsqu'on a mis à jour le dictionnaire des fonctions, la table des sociétés et/ou des sites, ou la table des habilitations fonctionnelles par des copies ou transferts (dans le cas de saisie manuelle, la mise à jour se fait automatiquement). En effet, pour des raisons de performance et de facilité d'utilisation dans les états, les habilitations sont gérées en détail dans une table croisée dont la clé est (code site, code profil, fonction). Cette table est mise à jour à chaque fois que des profils, des sites, des groupes de sites, ou des fonctions sont mises à jour. Lorsque des transferts par copie sont faits, il est donc nécessaire de remettre à jour ces informations. Attention, cette table peut être volumineuse, et les données à mettre à jour importantes. En effet, si on a 5 profils fonctions différents, et 20 sites, sachant que le progiciel intègre plusieurs centaines de fonctions, on a au minimum dans cette table N*100*5*20 lignes (car le profil du super-utilisateur a accès à toutes les fonctions sur tous les sites), plus une ligne pour chaque combinaison utilisateur, site, fonction autorisée. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 180 Sage ERP X3 – Outils avancées 10.6.5. Validation des menus Développement > Utilitaire > Dictionnaire > Validation > Menus 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éclencher cette opération après coup. Cette fonction permet de mettre à jour le fichier d'extension .mnu, situé dans le répertoire des menus du dossier (sous-répertoire MLAN, où LAN est le code langue de connexion), associé à une profil menu, et décrivant l'arborescence des menus et sous-menus, ainsi que des fichiers XML qui décrivent l'arborescence pour l'interface utilisateur. Ces fichiers sont automatiquement rafraîchis sur les postes (en client-serveur et en Web) à la connexion. La revalidation se fait uniquement dans toutes les langues utilisées dans le dossier. Cette phase de validation est automatiquement réalisée pour un profil utilisateur normal dès lors que celui-ci est modifié par la gestion des profils utilisateurs. Il existe par contre un profil menu particulier, nommé ADMIN par défaut, qui est associé à un utilisateur privilégié, et qui contient automatiquement toutes les fonctions définies dans le progiciel. La revalidation de ce profil est rendue nécessaire par cette fonction dès lors que l'on a mis à jour la table des fonctions du progiciel, par exemple en ajoutant de nouvelles fonctions créées par des développements spécifiques. Tant que cette phase n'aura pas été faite, les nouvelles fonctions ne seront pas accessibles par le menu de l'administrateur (elles le seront pour les autres profils si on désire l'inclure au profil menu en le modifiant). Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 181 Sage ERP X3 – Outils avancées 10.6.6. Génération des transactions Développement > Utilitaire > Dictionnaire > Génération transaction La plupart des écrans de saisie de mouvements du progiciel sont paramétrables par l'utilisateur, par le biais de transactions. Ces transactions permettent de définir, parmi un ensemble de champs standards, quels sont ceux qui doivent apparaître dans l'écran de l'utilisateur. Cette génération de transaction se fait par duplication, puis modification d'écrans modèles. De même, certaines fonctions de paramétrage provoquent la génération de code à partir d'éléments de paramétrage (c'est le cas pour les statistiques, les variables associées aux paramètres, par exemple). Cette génération de code se fait normalement au cours de chaque opération de paramétrage, mais il arrive, parce qu'un écran modèle a été modifié, que la régénération du code soit nécessaire pour toutes les transactions d'un type donné. Cette fonction permet de déclencher cette régénération. Il est à noter que les transactions sont désormais définies dans un dictionnaire dédié. 10.6.7. Gestion des traitements Ces fonctions sont dédiées aux développeurs utilisant la technologie Sage X3 10.6.7.1. Copie des traitements Développement > Utilitaire > Dictionnaire > Copie > Traitement Permet de copier la source d’un traitement (.src) vers un autre dossier. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 182 Sage ERP X3 – Outils avancées 10.6.7.2. Génération archive traitements Développement > Utilitaire > Dictionnaire > Archives > Archive traitement A partir de la version 5 les exécutables issu de la compilation des sources X3, autrement dit les .adx sont présent dans le répertoire TRT et dans un fichier archive 10.6.7.3. Copie fichiers Développement > Utilitaire > Dictionnaire > Copies > Fichiers Utilitaire de copie de fichiers séquentiels. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 183 Sage ERP X3 – Outils avancées 10.6.8. Mise à jour des menus locaux Développement > Utilitaire > Dictionnaire > Archives > Mise à jour Menus Locaux Les menus locaux qui sont utilisés pour la saisie des données organisées en combo-box sont définis dans la table APLSTD, par une opération de paramétrage dédiée. Mais il est aussi nécessaire que les valeurs de ces menus, et l'association entre les champs du dictionnaire et les menus, soient localement stockés sur le poste client, afin de permettre leur utilisation par des fonctions dédiées de Crystal Report. Pour cela, il existe des fichiers sur le poste clients, dont le nom est menus (affectation champs-menus locaux), et menuXXX (liste des valeurs des menus locaux pour la langue XXX). Ces fichiers sont stockés dans le sous-répertoire Report\DOSSIER_serveur_service, DOSSIER étant le code du dossier, serveur le nom du serveur, et service le numéro du service. Ces fichiers sont automatiquement téléchargés depuis le serveur, à partir de fichiers de référence portant le même nom, dès lors que les fichiers de référence sont plus récents que les fichiers situés sur le poste client. La fonction de génération des menus locaux permet de réaliser cette opération. Il est nécessaire de la lancer dès lors que l'on désire rendre visible dans les données éditées par des états, les intitulés de menus locaux ayant changé. Le lancement de cette fonction est proposé automatiquement lorsque des menus locaux ont été modifiés ; il n'est donc nécessaire de lancer cette fonction que si on a répondu Non à la question posée, par exemple après avoir fait des modifications en masse ou par maintenance des menus locaux. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 184 Sage ERP X3 – Outils avancées 10.6.9. Synchronisation des fenêtres Développement > Utilitaire > Dictionnaire > Synchronisation des fenêtres Au niveau technique, l'interface utilisateur des progiciels en technologie Sage X3 est décrite au format XML. Une fenêtre XML est décrite sous la forme d'un premier fichier décrivant sa structure, et d'un ensemble de fichiers décrivant les éléments qui la composent : écrans, listes de gauche, menus locaux. Tous ces éléments sont multilingues et indépendants du poste client sous-jacent, et leur génération est issue d'une validation du dictionnaire. Ainsi, par exemple : Lorsqu’une fenêtre est modifiée, par exemple par l'ajout d'un bouton, le XML correspondant à la fenêtre est réécrit. Lorsqu’un écran est modifié (par exemple par rajout d'un champ), le XML correspondant à l'écran est réécrit. Lorsqu’une liste gauche est créée et ajoutée à une fenêtre, le fichier XML correspondant est créé, et le fichier XML de la fenêtre est remis à jour. A partir de ces fichiers élémentaires, une phase d'assemblage permet, dans un contexte donné (type de client, langue), de générer un fichier XML optimisé, ne contenant plus que les informations utiles à l'interface considérée. C'est ce fichier assemblé qui est stocké dans le cache du poste client. Il en existe une version différente pour les interfaces client-serveur, Web, et terminaux portables, les informations nécessaires n'étant pas strictement les mêmes. Tous les fichiers XML sont horodatés, ce qui permet à tout moment de vérifier la cohérence entre les éléments. Pour des raisons d'optimisation, lorsqu'un écran est modifié, on ne relance pas l'assemblage des fichiers XML optimisés pour toutes les fenêtres qui l'utilisent; par contre, on met à jour un indicateur pour invalider les fenêtres. Ainsi, cet assemblage est fait à la volée lors de la première utilisation de la fenêtre dans un contexte donné. Cette fonction permet de forcer cet assemblage, mais il permet aussi de régénérer les fichiers XML décrivant les fenêtres, pour permettre de gérer des cas tels que la mise à jour des générateurs XML. Utilitaires dossiers Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 185 Sage ERP X3 – Outils avancées o Changement de dossier : permet une reconnexion sur un autre dossier o o 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 o o o o o o Remarque : 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. 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 Remarque : 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é. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 186 Sage ERP X3 – Outils avancées 10.7. UTILITAIRES DE RECHERCHE Les outils décrits dans ce chapitre sont destinés : - Aux développeurs pour analyser les impacts d’une modification - Aux fonctionnels pour rechercher les entités impactées par une modification d’un code activité - A l’administrateur pour analyser les changements sur les codes d’accès ou les habilitations Les types de recherche disponibles sont :  Recherche par code activité Développement > Utilitaire > Recherches > Codes activités Cette recherche est nécessaire avant de modifier un code activité de type dimensionnement pour disposer de la liste des entités impactées.  Recherche par type de données Développement > Utilitaire > Recherches > Type de données  Recherche par code d’accès Développement > Utilitaire > Recherches > Code d’accès  Recherche par code action Développement > Utilitaire > Recherches > Action  Recherche par message Développement > Utilitaire > Recherches > Message Cette recherche permet de trouver tous les messages utilisant un mot comme par exemple « facture »  Recherche par texte Développement > Utilitaire > Recherches > Texte Cette recherche permet de trouver le numéro d’un texte et les entités qui utilisent ce numéro. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 187 Sage ERP X3 – Outils avancées Résultat de la recherche du mot Facture  Recherche diverses Développement > Utilitaire > Recherches > Divers Cette fonction permet de rechercher dans toutes les tables du dictionnaire une valeur donnée pour un champ de type donné, pourvu que ce type soit associé à un objet du progiciel. Par exemple, on peut rechercher les endroits où un code état est utilisé, où un code pays est utilisé, etc. On peut également rechercher des traitements (type ADC), bien que ce type ne soit pas associé à un objet par défaut. Ceci permet de vérifier dans quels écrans, fenêtres, actions… un traitement donné est utilisé. Chaque fonction de recherche produit une trace sur laquelle l’utilisateur peut réaliser son analyse. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 188 Sage ERP X3 – Outils avancées 10.8. UTILITAIRES DIVERS 10.8.1. Ordre système Développement > Utilitaire > Divers > Ordres système Cette fonction permet de lancer un ordre système sur le serveur d'application du dossier. Vu d’un dossier X3 un ordre système est l’activation d’un exécutable ou d’une commande liée à l’Operating System qui héberge le serveur. On peut aussi lancer des ordres systèmes sur l'une quelconque des machines où un autre serveur d'application sur lequel les processus adxd et sadsys tournent, et également sur le poste client. Les syntaxes sont alors les suivantes : serveur@ordre_sys (le nom réseau du serveur où se trouve le dossier doit être indiqué : un service adxd doit fonctionner sur le numéro de service courant pour permettre la connexion) serveur:service@ordre_sys (même principe que ci-dessus, mais le numéro de service peut être différent. Ceci donne, par exemple, la syntaxe serveur_01:1802@lsadx -a DOSSIER TRT src) Attention : les deux dernières syntaxes supposent qu'il existe sur le serveur distant un dossier ayant le même nom que le dossier d'où est lancée la fonction (même si ce n'est pas sur ce dossier que l'on lance l'opération). Cette condition est toujours remplie lorsqu'on part du dossier X3, puisque toute installation X3 suppose qu'un dossier X3 soit installé au minimum. Il est donc conseillé de n'utiliser cette syntaxe que dans ce cas. Par ailleurs, selon les configurations réseau, la saisie d'un nom réseau incorrect peut provoquer une attente assez longue après la saisie du champ (le contrôle d'existence du serveur se faisant sur le réseau, il peut y avoir un délai de l'ordre de la minute, parfois même de plusieurs minutes avant qu'un message d'erreur n'arrive). Le lancement de l'ordre système sur le client se fait en donnant # comme nom de serveur. En Mode Web, l'exécution directe d'un ordre système sur le poste client (syntaxe #@ordre) est impossible, pour des raisons de sécurité. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 189 Sage ERP X3 – Outils avancées 10.8.2. Exécution traitement Développement > Utilitaire > Divers > Exécution traitements Ce type de fonction est une fonction de développement dont l'utilisation est interdite dans le cadre d'une exploitation normale 10.8.3. Copie des valeurs paramètres Développement > Utilitaire > Divers > Copie valeurs paramètres Cette fonction permet de copier les valeurs de paramètres (Table ADOVAL) définis à un niveau donné (société, site, utilisateur, législation) pour un code donné, vers un ensemble de codes de destination (société, site, utilisateur, législation, selon le choix de copie fait) définis par borne de valeurs, par l'utilisation d'un modèle, ou donnés sous la forme d'une liste. Cette copie peut être faite en mode simulation dans un premier temps (avec ou sans le détail des paramètres copiés). Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 190 Sage ERP X3 – Outils avancées 10.8.4. Re synchronisation des liaisons Développement > Utilitaire > Divers > Resynchronisation des liaisons Au niveau des listes gauche d’un objet, un browser nommé Explorateur de liens qui permet de définir des liens vers d'autres fiches issues d'autres objets. Ces liens peuvent être établis manuellement, grâce à la fonction Fichier / Liaisons, mais également de façon automatique. Ce paramétrage fait, les liaisons automatiques sont mises à jour à chaque fiche créée ou modifiée, mais bien entendu pas sur les fiches antérieurement créées. Cette fonction permet de lancer la mise à jour des liaisons automatiques. Elle peut être faite sur un objet, ou tous objets confondus. Développement > Utilitaire > Divers > Activation des liaisons Les liaisons entre les fiches des objets de gestion, sont définies par une fiche de départ, une fiche d'arrivée, un groupe de liaison lié aux utilisateurs, et une désignation déclarée par un code dans une table. Chaque liaison peut être saisie manuellement ou créée automatiquement d'après un paramétrage lié à l'objet. Enfin, chaque liaison est datée, et dispose d'un indicateur actif (Oui/Non) : le champ ENAFLG est utilisé à cette fin. Les liaisons attachées à une fiche sont présentées dans un volet de la liste gauche : l'explorateur de liaisons, dont la présence est optionnelle et dépend du paramétrage de l'objet. Seules les liaisons actives sont présentées dans l'explorateur de liaison. Par défaut, lorsqu'une liaison est créée, elle est active, et la seule fonction susceptible de faire passer des liaisons de l'état Actif à l'état Inactif et viceversa est la fonction Activation des liaisons présentée ici. Les paramètres généraux suivants ont une influence sur le comportement de la fonction : GRPLIAISON (défini au niveau Utilisateur) : Groupe de liaison LIAISAUTO (défini au niveau Utilisateur) : Liaisons autos Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 191 Sage ERP X3 – Outils avancées La table diverse numéro 61 doit être renseignée : Sémantique liaisons Il faut que la gestion des liaisons ait été paramétrée au départ. Ceci suppose, outre l'activation des paramètres utilisateurs, que le volet des liaisons apparaisse dans les fonctions dans lesquelles il est jugé utile. Ceci se définit par la fonction de personnalisation d'objet. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 192 Sage ERP X3 – Outils avancées 11. LES TRANSACTIONS SYSTEME Une transaction système permet sur les données d’une table :    la création, la mise à jour la suppression Par conséquent, la fonction de paramétrage des transactions est une fonction potentiellement dangereuse. Les ordres SQL associés impactent les données de la base sans que la cohérence liée à l’applicatif ne soit contrôlée. Il convient donc, après analyse, de :  Réaliser une sauvegarde des tables impactées avant toute modification.  Effectuer un test du résultat obtenu par la transaction sur une sélection réduite et identifiée, avant de lancer la transaction sur l’intégralité des données à mettre à jour.  Ne donner accès à cette fonction qu’à certains utilisateurs (protéger par un code d’accès chaque transaction système pour bien filtrer celles qui peuvent être accessibles aux utilisateurs). Remarques relatives aux habilitations et droits d’accès  Cette fonction étant de type objet, les opérations de création, modification, et suppression de fiche peuvent être activées ou désactivées pour un utilisateur donné.  Des filtres par rôles peuvent également être mis en place sur cette fonction. Un filtrage par code d'accès est effectué grâce au champ nommé ACS. S’il y a un code d'accès, les droits de visualisation et de modification sont accordés conformément aux droits de lecture et d'écriture associés au code pour l'utilisateur, via son profil fonction. L’accès en exécution d’une transaction système peut être contrôlé 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. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 193 Sage ERP X3 – Outils avancées 11.1. CREATION D’UNE TRANSACTION La création d’une transaction se fait à l’aide de 2 onglets :   l’onglet général de définition de la transaction l’onglet comprenant les formules de sélection des enregistrements à traiter et les tables à mettre à jour. 1 4 2 3 5 6 Dans l'en-tête de l’écran, on donne le code identifiant la transaction et un intitulé.  Module d’appartenance de la transaction.  Code activité protège la transaction de tout changement de version.  Code accès permet de protéger chaque transaction système, accordant des droits d’exécution ou pas aux utilisateurs.  Table à mettre à jour.  Tables liées rassemble la liste des tables à ouvrir, soit pour les mettre à jour, soit parce qu’on a besoin de filtrer les enregistrements de la table principale, en fonction de champs de ces tables liées. On peut déclarer jusqu’à 5 tables liées. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 194 Sage ERP X3 – Outils avancées  Variables regroupe les variables pouvant ensuite être utilisées dans les formules de sélection, et dans les formules de mise à jour de champs. Ces variables sont nommées V1, V2, V3,… V6. On peut déclarer jusqu’à 6 variables. Mise à jour d’une ou plusieurs tables. On peut effectuer pour chacune d’elle :    soit une modification de la valeur d’un ou plusieurs champs (il faudra paramétrer une ligne par champ). soit une création d’enregistrements à partir d’un enregistrement sélectionné (il faudra paramétrer une ligne pour le champ clé). C’est l’équivalent d’une duplication d’enregistrement. Pour modifier certains champs de cet enregistrement, il faudra intervenir par une autre transaction système. soit une suppression d’enregistrements (on ne précise rien pour les champs). En modification d’enregistrements, la formule permet d’affecter une nouvelle valeur au champ Formules permettent de faire une sélection des enregistrements à traiter. Ces formules peuvent faire appel aux valeurs de paramètres. On peut déclarer jusqu’à 5 formules. La validation permet de générer le traitement automatique, nommé WMAMIxxxxx. (xxxxx étant le code transaction). Il contient tout le traitement personnalisé de la transaction. Exec permet d’exécuter directement la transaction. Il correspond à la fonction « transactions système ». Copie permet de recopier la définition de la transaction vers un autre dossier. Il faudra valider la transaction dans le dossier de destination. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 195 Sage ERP X3 – Outils avancées 11.2. L’EXECUTION D’UNE TRANSACTION SYSTEME Développement / Utilitaires / Divers / Transactions système Outre l’exécution par le biais du bouton « Exec » dans la fonction de création de la transaction système, il existe une fonction dédiée présentant des options supplémentaires. Saisir le code de la transaction à effectuer. Cocher Test permet de lancer la transaction uniquement en test. Dès lors, on saisit le nombre d’enregistrements sur lequel porte la trace de test (10 par défaut) : la trace présentant les lignes qui seraient modifiées si la fonction était lancée en mode réel. Cette saisie faite, on voit apparaître, le cas échéant, des paramètres dont la valeur doit être saisie dans le tableau situé ci-dessus. Une trace sera affichée lorsque cette fonction sera terminée pour donner la liste des lignes modifiées. Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 196 Sage ERP X3 – Outils avancées Sage ERP X3 - Outils avancés Sage 2011 « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ». Page 197 Report "SX3012-01_OutilsAvances_-Support-de-cours.pdf" Your name Email Reason Description Copyright © 2025 IDOC.TIPS. All rights reserved. About Us | Privacy Policy | Terms of Service | Copyright | Contact Us | Cookie Policy Sign In Email Password Remember me Forgot password? Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close
Cellule de tableau Image Lien hypertexte
Titre
Sous-titre Gras Souligné
Conteneur

SX3012-01_OutilsAvances_-Support-de-cours.pdf

Recommend Documents

Titre

Sous-titre Gras Souligné Conteneur

Sous-titre Gras Souligné
Conteneur