Cegid XRP Ultimate | I3 Actualisé le 06/10/2022 |
|||
| Workflow Information Manager | |||
| Documentation fonctionnelle générale | |||
| Introduction |
| Principe du traitement systématisé |
|
| Gestion du Fail Over |
| Si plusieurs serveurs sont disponibles (GSRV), il est possible de lancer un process WIM systématisé sur chacun de ces serveurs. Un seul sera actif, mais si le serveur actif a une panne, un serveur de secours prendra le relais. Si le serveur de secours a lui aussi une panne, un troisième serveur peut alors prendre le relais (et ainsi de suite, selon la limite des serveurs disponibles). Dès que le serveur principal est de nouveau démarré, il reprend la main sur un éventuel serveur de secours. |
| Les transactions |
| Une seule transaction centrale pour WIM : GTUREQ. Liste des transactions associées : GTUCOL : Colonnes des select GTUSEL : Clauses from, where, group by, order by GTUFRE : Lancement des requêtes (systématisation) GTUFRM : Mise en forme du résultat GTUABO : Abonnements et listes de diffusion GTUJLR : Jobs liés aux requêtes |
| GTUREQ : Définition des requêtes |
| Duplication des requêtes |
| Dans GTUREQ, vous pouvez à partir d'une requête initiale, prendre tout ou partie de son paramétrage (colonnes, mise en forme, ...) et la dupliquer vers une nouvelle requête. |
| Test des requêtes et du mail |
| Dans GTUREQ, vous pouvez tester la requête en précisant l'adresse de destination et en "court-circuitant" certains contrôles (mêmes fonctionnalités que TREQ). |
| Gestion des listes de diffusion et des abonnements (GTUABO) |
 |
| Prise en compte des ruptures |
| Voir compléments avancés |
| Lancement des requêtes |
Les requêtes paramétrées en différé peuvent être lancées de façon manuelle grâce à la soumission TREQ. La "Systématisation (GTUFRM) est non contrôlée", on peut donc lancer la requête à tout moment. Si le "Destinataire" est renseigné, envoi vers l'adresse précisée dans ce champ, sinon, envoi "normal". Voir les fonctionnalités avancées de TREQ |
| Meilleure prise en compte des fichiers en ligne (images, ...) |
| Les fichiers en ligne peuvent être directement intégrés dans le format HTML (utilisation d'une URL). |
| Gestion des accusés de réception |
| Il est possible de gérer les accusés de réception sur les mails envoyés via WIM. Pour cela, il faut : - définir la globale MAIL_NOTIFY. Celle-ci peut prendre deux valeurs : SUCCESS (en cas de réussite de remise du mail) ou FAILURE (en cas d'échec de remise) ; - définir la globale MAIL_ DSN. Celle-ci peut prendre deux valeurs : NONE qui est la valeur par défaut ; on ne gère jamais les accusés sauf si on trouve la balise !WNOT=O WNOT! dans le mail. Valeur ALL ; on gère tout le temps les accusés de réception sauf si on trouve la balise !WNOT=N WNOT! ; - définir la globale MAIL_RPT : adresse de retour pour l'accusé de réception. Remarque : Ce principe des accusés de réception n'est pas une garantie à 100% que le message ait bien été remis. Il donne une indication. Par exemple, pour lutter contre le phénomène de "spam", tous les serveurs ne supportent pas ou ne délivrent pas d'accusés. Une chose est sûre : si vous recevez, dans le cas FAILURE, un message signalant la "non remise", c'est qu'il y a bel et bien eu un problème. |
| Multilangue | ||||||||||||||||||||||||
| Dans GTCL, pour un seul et même établissement, vous pouvez définir une clé et des traductions associées à cette clé. Ensuite, lors de la définition des requêtes, il va être possible d'utiliser : - des tags <&CLE&>. Ces variables seront alors remplacées par la valeur du champ "intitulé" de GTCL, en utilisant la langue définie par la colonne qui aura comme alias WIMLAN ; - des tags <&TXT_CLE&>. Ces variables seront alors remplacées par la valeur du champ "information" de GTCL, toujours en utilisant la langue définie par la colonne qui aura comme alias WIMLAN. <&CLE&> ou <&TXT_CLE&> peuvent être employés aussi bien dans la mise en forme que dans la définition des libellés des colonnes, ce qui permet de traduire aussi les intitulés des colonnes dans le fichier excel. Exemple : Dans GTCL :
Ensuite, dans la requête, lecture de la zone "langtusr" (langue de l'utilisateur destinataire du mail) car cette colonne a comme alias WIMLAN. Dans la mise en forme, on écrit : <&CLE1&> $ART <&TXT_CLE2&> $CLA $NUM $SNU Si le destinataire parle français, on aura dans le mail : Article : xxxx Numéro de commande : www xxx yyyyyy Si le destinataire parle anglais, on aura : Item : xxxx Purchase number : www xxx yyyyyy Remarque : Afin de ne pas trop pénaliser les performances, les traductions sont activées seulement si les globales WIMS_TRAD (pour la partie WimServlet) et/ou WIM_TRAD (pour la partie Wim) ont la valeur O. |
| GTUCOL : Définition des colonnes du select |
| Principe de la transaction GTUCOL. Saisir les colonnes une par une dans la zone "expression". La syntaxe doit respecter la syntaxe SQL. Le numéro d'ordre détermine l'ordre dans lequel seront ramenées les colonnes. Dans la zone "libellé", il est possible de saisir le libellé "en-tête" de la colonne qui pourra être utilisé dans la mise en forme. Dans la zone "alias", le code saisi sert à représenter la valeur de la colonne lors de la mise en forme. Il est important de noter que certains alias sont réservés (mot-clé) : - ETP : référence l'étape après traitement (pris dans GTUREQ) ; - EPO : référence l'étape à traiter (pris dans GTUREQ) ; - CLA : référence la classe (pris dans GTUREQ) ; - DOM : référence le domaine (pris dans GTUREQ) ; - NUM : référence le numéro de la commande ou de la liste à traiter (provient des enchaînements dynamiques) ; - JOBNUM : référence le numéro de job lancé. Si vous souhaitez gérer les destinataires des mails en cochant l'option "adresse" de GTUREQ, l'adresse doit IMPERATIVEMENT être la première colonne du select. Voir comment scinder les mails Voir comment mettre des destinataires en copie Voir exemple simple |
| GTUSEL : Définition des clauses du select |
| GTUSEL permet la saisie des clauses (from, where, ...) en respectant la syntaxe SQL. Les seules "variables" utilisables dans le where sont les mots-clefs (alias), mais il est possible d'utiliser les symboles $ETS, $ Si vous souhaitez gérer les destinataires des mails (zone "adresse" cochée dans GTUREQ), il est vivement conseillé de renseigner la zone "order by" en précisant : 1 (première colonne). Vous avez la possibilité de tester la requête que vous venez de saisir. Si la syntaxe est correcte, un message vous précisant le nombre d'enregistrements ramenés s'affiche. S'il y a un problème SQL, un message d'erreur SQL ressort. Remarque : Avec l'arrivée de la norme SQL99 (et notamment le codage des jointures externes), la partie "from" de GTUSEL peut parfois s'avérer trop petite (maximum 240 caractères saisissables). Pour pallier ce problème, il est possible de saisir le from dans la zone texte (habituellement réservée à la partie "where"). Pour cela, il faut que les 4 premiers caractères de la zone where soient exactement 'from ' (from en minuscule, suivi d'un espace). Dans ce cas, ce qui est saisi dans la zone "from" ne sera pas pris en compte. Prise en compte de la confidentialité Lors de l'écriture des expressions Sql, il est possible d'utiliser le caractère @ en fin de table confidentielle. Lors de l'exécution, ce caractère sera remplacé par "c" si la confidentialité est active (globale et/ou à l'utilisateur), sinon par rien quand la confidentialité n'est pas gérée. Par exemple, l'expression "select numgtets from gtets@ where ..." sera remplacée par "select numgtets from gtetsc where ..." si la confidentialité est active ou par "select numgtets from gtets where ..." si la confidentialité est inactive. Prérequis : connaître les entités gérant la confidentialité, pour savoir où utiliser les @. De plus, il faudra soit laisser un espace après le @ soit mettre une virgule. |
| GTUFRE : Systématisation |
| Les informations contenues dans GTUFRE ne sont prises en compte que lors d'un lancement en différé (traitement de fond). Plusieurs enregistrements pour une même requête sont autorisés (les bornes les moins restrictives des différents enregistrements seront alors prises en compte). L'intervalle d'exécution est exprimé en minute et précise les cycles d'exécution de la requête concernée. Remarque : un délai d'exécution à 0 est interprété comme "lancement une fois par jour". |
| GTUFRM : Mise en forme |
| Dans GTUFRM, définition de la "maquette" servant de base à la mise en forme du résultat. Les règles sont assez simples : - Le numéro d'ordre sert à signaler au programme dans quel ordre il va afficher les différentes étapes. - Si une étape ne contient aucune variable de type $ALIAS, elle est "éditée" une seule fois. - Si une étape contient du texte et des variables de type $LIB_ALIAS, ces variables sont remplacées par leur valeur (valeur prise dans la zone libellé de GTUCOL), et l'étape n'est "éditée" qu'une seule fois. - Si une étape contient au moins une variable de type $ALIAS, ces variables sont remplacées par leur valeur (valeur de la base de donnée) et l'étape est éditée autant de fois qu'il y a d'enregistrements ramenés par le select codé. |
| Exemple simple |
| Liste des gestionnaires, avec code gestionnaire, nom, prénom et adresse mail. Cette requête est de type "différé" (mode batch ou traitement de fond). GTUREQ - Table des requêtes  GTUCOL - Colonnes des select  GTUSEL - Clauses des select  GTUFRE - Lancement des requêtes  Cette requête va donc envoyer un mail (contenant les gestionnaires actifs) : Toutes les minutes (intervalle d'exécution = 1), Entre 8 heures du matin et 18 h, Tous les jours du mois (du 1 au 31), Tous les jours de la semaine (du dimanche au samedi), Tous les mois de l'année. GTUFRM - Mise en forme des résultats    |
| Mise en place des traitements par étape |
| Définition du traitement |
Dans GTRB, définir un traitement avec pour objet associé : com.qualiac.tus.Tusiac |
| Définition de la transaction |
Dans GTRA, définir une transaction portant sur l'objet "sgiede" (traitement par étape), et l'associer au traitement (GTRB) défini ci-dessus. |
| Définition du mnémonique |
GMNU - Mnémoniques |
| Mise en place dans les étapes |
GETCA - Etapes par classe de commandes d'achats |
| Exemple de requête |
Dans GTUREQ : La classe est précisée, le domaine achat aussi. L'étape après traitement correspond à l'étape de GETCA pour laquelle on a associé le TUSIACA. Quand le traitement par étape est lancé, la requête exécutée est celle dans GTUREQ qui a pour "étape après traitement" l'étape concernée. Remarque : s'il existe un alias WIMETP, c'est sa valeur qui est prise en compte pour passer l'étape. Dans ce cas, l'étape après traitement est ignorée. De même, si la valeur de WIMETP vaut -1, on ne passe pas l'étape.  |
| Wim avec changement d'étape : en début ou en fin de requête |
| Les requêtes WIM ayant l'option "MAJ étape" modifient, par défaut, les étapes en fin d'exécution des requêtes (donc après avoir lancé les sous-requêtes éventuelles, les jobs liés aux requêtes, ...). Il est possible de préciser, par requête, si la mise à jour se fait en début de requête (dès que l'enregistrement est ramené), ou si on reste selon le principe ci-dessus. Pour que la mise à jour soit faite en début, il faut que, dans la chaîne 1 de l'occurrence égale au type de requête (Paramètres standard de GTUREQ) du paramètre TYPTUREQ, on ait la valeur "T". |
| Exemple d'utilisation |
| Le but est d'envoyer, en début de matinée et en début d'après-midi, la liste des ordres de production en attente de contrôle qualité. Les destinataires sont les gestionnaires de ces ordres. Chaque destinataire ne doit recevoir que la liste des ordres le concernant. Afin de permettre une communication plus simple, nous souhaitons que les responsables qualité aient aussi accès à ces informations. De plus, pour permettre un classement aisé, l'émetteur du mail doit s'appeler 'production@société.com'. Envoi de façon périodique : il s'agit donc d'un traitement batch (différé). Chaque gestionnaire d'ordre doit recevoir la liste des ordres le concernant : le type d'adressage doit donc prendre en compte l'adresse du gestionnaire. Les responsables qualité doivent être tenus au courant : ils doivent donc recevoir tous les mails. A ce moment, il s'agit donc de mettre en place soit une liste de diffusion, soit un abonnement. Dans le cas présent, nous opterons pour une liste de diffusion. Ordres en attente de contrôle qualité : tous les ordres de la classe "OF" qui sont à l'étape 600. |
| Définition de la requête |
 |
| Saisie des colonnes |
 |
| Saisie des clauses |
 |
| Listes de diffusion |
GLUS - Liste d'utilisateurs  Saisie des éléments de la liste. Il s'agit d'utilisateurs définis dans GUSI. Les adresses mail de ces utilisateurs proviennent de GGES (donc un utilisateur doit soit trouver une correspondance directe dans GGES, soit une correspondance via le gestionnaire de l'utilisateur). GELU - Utilisateurs d'une liste  Association de cette liste de diffusion à notre requête. Cela se fait par GTUABO :  |
| Abonnements |
| Même principe que pour les listes de diffusion. La différence est que, dans ce cas, c'est directement un gestionnaire qui est utilisé. |
| Exemple de fichiers properties utilisés |
| Il s'agit ici d'un aspect plus technique. Le fichier qualiacdb.properties définit un paramétrage stable et de haut niveau permettant de se connecter à la base de données. De ce fait, ce fichier est rarement accessible par tous. Quoi qu'il en soit, en voici un aperçu (exemple pour oracle) : ####################################################### ##### ORACLE ####################################################### driver.1=oracle.jdbc.driver.OracleDriver driver.count=1 datasource.1=HPDEV_ORA_CS datasource.default=HPDEV_ORA_CS HPDEV_ORA_CS.url=jdbc\:oracle\:thin\:@ HPDEV_ORA_CS.server=HPDEV:1521:CS code.password = 123456 |
| Gestion des ruptures dans la mise en forme (possibilité de format XML) |
| Principe |
| Pour pouvoir générer (entre autre) des fichiers au format XML, il faut être capable de convertir un fichier "à plat" en fichier "en arbre". La seule solution pour cela consiste en la gestion de ruptures au niveau des données. Précision sur le terme "rupture" : par ce mot, on entend un changement de données entre deux enregistrements : Exemple : Voici 6 enregistrements, de 2 colonnes (nom, âge) : enregistrement 1 : DUPOND 40 enregistrement 2 : DUPOND 40 enregistrement 3 : DUPOND 45 enregistrement 4 : DUPOND 25 enregistrement 5 : DURAND 25 enregistrement 6 : DURAND 20 Il se produit une "rupture" sur le nom sur l'enregistrement 5, et une rupture sur l'âge en enregistrement 3 et 5. Remarque : Bien entendu, les mises en forme en gérant des ruptures ne sont pas uniquement destinées à générer des fichiers de type XML. |
| Structure générale d'un fichier XML |
 Ligne 1 : obligatoire (permet de préciser qu'il s'agit bien du format xml, le "encoding" permet de préciser le jeu de caractères utilisé => dans ce cas, jeu de caractères avec accents). Ligne 2 : il faut impérativement une racine, et une seule. Ligne 3 : définition des branches, avec les attributs (info1, info 2, ...). Ligne 5 : définition d'une feuille (le tag se referme immédiatement après l'information). Ligne 7 : fermeture de la branche 2. Ligne 12 : fermeture de la branche 1. Ligne 25 : fermeture totale de l'arbre. |
| Exemple visualisé avec un navigateur internet |
 |
| Intégration dans WIM |
 Fichier résultat (fichier de données)  La transformation vers un format xml se fait dans WIM en se basant sur le fichier de données (xls). La première chose à faire est donc de préciser les alias des colonnes. Cela se fait en utilisant le "tag" !COLxx !, avec xx = numéro de colonne du fichier de données. Exemple : !COL01 ! $FOU !COL03 ! $CLASSE Cela signifie que la colonne 1 du fichier de données est représentée par l'alias $FOU, la colonne 3 par l'alias $CLASSE. Définition du tri : Il faut bien noter que, dans notre exemple, le fichier xls n'est pas trié dans l'ordre des ruptures. C'est un des intérêts de la mise en forme par WIM. Nous offrons la possibilité de manipuler le fichier de données selon nos propres critères de tri, donc pas directement lié au select déclenché. Pour définir les tris effectués, il faut utiliser la balise !TRIxx !, avec xx = priorité du tri. Dans notre exemple !TRI01 ! $FOU DESC !TRI02 ! $RUP !TRI03 ! $ART ASC Le tri sera donc fait par fournisseur (colonne1 du xls) décroissant (mot-clé DESC), puis par "commande" (colonne 2 du xls), puis par code article croissant (à noter : le mot-clé ASC est pris par défaut. Si aucun type de tri n'est trouvé pour une balise !TRI !, on va considérer le tri croissant). Remarque : si aucune balise !TRIxx ! n'est trouvée dans la mise en forme, aucun tri supplémentaire ne sera fait sur le fichier xls. Les données seront prises dans le sens du fichier xls. Définition des ruptures : Elles sont définies par les balises !DEFRUPxx ! (avec xx = numéro de rupture). Ici aussi, il est intéressant de noter que les ruptures gérées peuvent être indépendantes du tri effectué. Il peut donc être possible de faire un tri par article, puis établissement, et de gérer des ruptures sur établissement puis article (par exemple). Définition des lignes éditées en début de traitement (éditées une seule fois). Cela se fait par la balise !DEBUT! . Plusieurs lignes de mise en forme avec la balise !DEBUT! peuvent être saisies. De la même façon, la balise !FIN ! permet de définir les lignes éditées en fin de traitement. Définition des lignes à écrire en début de rupture. Se fait avec la balise !EDDRUPxx !, avec xx = numéro de rupture. Définition des lignes des données "brutes", avec la balise !LIG ! Définition des lignes à écrire en fin de rupture. Balise !EDFRUPxx ! avec xx = numéro de rupture. Concrètement, sur l'exemple précédent, la mise en forme est :  Voir comment gérer des cumuls Complément : Les mots-clefs $$WIM_CPT_LIG, $$WIM_CPT_RUP et $$WIM_NUM_RUP peuvent être utilisés dans les mises en forme avec rupture. $$WIM_CPT_LIG représente le compteur absolu des lignes éditées (+1 à chaque ligne de données éditée) $$WIM_CPT_RUP représente le compteur absolu des ruptures éditées (+1 à chaque rupture éditée) $$WIM_NUM_RUP représente le numéro de la rupture |
| Compléments avancés |
| Prendre en compte un niveau de rupture supplémentaire pour scinder les mails |
| Sans cette option, le contenu du mail est groupé selon le destinataire. Exemple : 8 commandes sont ramenées par la requête, le destinataire étant le gestionnaire de la commande. Imaginons que les 5 premières commandes aient le même gestionnaire, et les 3 dernières un autre gestionnaire. Dans ce cas, le module WIM n'enverra que 2 mails : le premier au premier gestionnaire, contenant la liste des 5 commandes le concernant. Le second au second gestionnaire, avec la liste des 3 dernières commandes. Le classement des commandes n'est pas facilité avec ce mode de gestion. Pour améliorer cette fonctionnalité, il existe une possibilité : définir une "rupture" sur un identifiant de la commande. A chaque changement de la valeur de cet identifiant, un nouveau mail est envoyé. Il est donc possible d'avoir : 5 mails au premier gestionnaire, chacun contenant une commande, et 3 mails au dernier. Mise en place : Pour définir sur quelle colonne (GTUCOL) va porter la rupture des mails, il faut utiliser un alias particulier : c'est l'alias "CC". Exemple :  |
| Mettre des destinataires en copie |
| Le même principe que celui défini précédemment : pour cela il suffit d'utiliser l'alias CC. Si la valeur de la colonne représentée par cet alias contient un caractère @, le module WIM considèrera qu'il s'agit d'un destinataire en copie. Exemple :  ou  Avec emloeges = adresse mail dans GGES |
| Utilisation de paramètres supplémentaires dans TREQ |
| Le traitement TREQ permet de lancer de façon interactive une requête qui est normalement systématisée. Le TREQ ne comporte que 6 paramètres figés et réservés (de CHAINE1D à CHAINE6D). Il est possible d'ajouter des paramètres dans ce traitement (il est plutôt conseillé d'utiliser un autre mnémonique) qui pourront être utilisés comme des variables dans les clauses du select lancé. Exemple : Rechercher les listes des ordres de production dont le numéro est compris entre 2 valeurs paramétrables, et dont le gestionnaire est lui aussi modifiable. |
| Création d'un traitement (GTRB) basé sur WIM : |
 Création de la transaction (GTRA) associée :  |
| Création du mnémonique (GMNU) : |
 Création des paramètres particuliers (GCTR) :  |
| Remarques importantes |
| Il ne faut pas rectifier les six premiers paramètres (CHAINE1D, ..., CHAINE6D) qui servent à identifier la requête à lancer. Ces paramètres doivent donc toujours être présents. Pour connaître la liste des critères utilisables, se reporter à la documentation de la soumission dynamique gttdyn. Voici l'écran de soumission de WIMREQ :  Il est ensuite facile de mettre en place un paramétrage par défaut (mode jaune) par utilisateur ou global . On continue l'exemple en regardant maintenant la requête à mettre en place.  |
| Lancement (TREQ) : |
 La requête réellement lancée sera : Select ... From qaord Where sitqaord = 'SI' and etsqaord ='PL' and claqaord = 'CTL' and numqaord between 16 and 19 and gesqaord = 'PL' |
| Récupération des paramètres de jobs précédents (cas WIM dans un enchaînement) |
| Si WIM est lancé dans un enchaînement, il est possible de récupérer les valeurs des critères des jobs le précédant dans l'enchaînement et ainsi pouvoir les utiliser dans l'ordre SQL. Pour accéder à ces valeurs, il faut utiliser une codification particulière : $-x_NOMCRITERE, avec x représentant le décalage souhaité. Exemple : un enchaînement ECH se compose de 5 traitements : TRT10, TRT20, TRT30, TRT40 et TRTWIM. En lançant ECH, on obtient les numéros de jobs suivants : TRT10 --> job n° 58 TRT20 --> job n° 60 TRT30 --> job n° 61 TRT40 --> job n° 62 TRTWIM --> job n° 64 En utilisant , par exemple $-2_NUMGTETSD, on récupère la valeur du critère NUMGTETSD dans TRT30. L'utilisation de $-4_NUMSGART, permet d'obtenir la valeur du critère NUMSGART dans TRT10. L'utilisation de $-1_CLASACDA, permet d'obtenir la valeur du critère CLASACDA dans TRT40. Il est aussi possible de récupérer les numéros de job. Le symbole $JOBNUM donne le job courant du WIM (64 dans l'exemple), et $-1_JOBNUM donne le job précédent (62), $-3_JOBNUM donne 60, ... |
| Visualisation du fichier HTML généré par WIM via CJOB |
| En lançant un WIM par job (TREQ, ou par étape, ...), et en précisant, dans le paramétrage du traitement, que le compte rendu doit être de type ASCII (uniquement), le fichier résultat du job ne contiendra plus le compte rendu habituel (Nom requête lancée, nombre d'enregistrements, ...), mais le fichier HTML généré. En couplant cette possibilité avec l'option de lancement de job direct ainsi que de visualisation du compte rendu "enchaîné" (voir GAMN), il sera donc possible d'afficher le résultat d'un WIM directement à l'écran. |
| Utilisation de cumuls dans une mise en forme gérant les ruptures |
| Il est possible de faire des cumuls en fin de rupture. Exemple : Mail contenant la liste des articles en stock, avec quantités par lot et emplacement. Un cumul sera fait par lot et par article, sur deux colonnes : quantités stockées, et quantités réservées.  Par défaut, la précision sur les variables de cumul est de deux décimales. Pour changer cela, il suffit d'ajouter la ligne : !PRECCUM! x avec x représentant le nombre de décimales souhaitées. Cette précision sera appliquée à toutes les variables de cumul. Si vous souhaitez appliquer différentes précisions en fonction des variables de ruptures utilisées, il faut utiliser la syntaxe suivante : !PRECCUM01 ! 3 !PRECCUM02 ! 1 Avec ceci, la précision appliquée à la variable de cumul numéro 1 sera de 3 décimales, et 1 décimale pour la variable 2.  |
Il est possible d'utiliser la variable $CUMxxR00 pour définir un cumul général (à utiliser dans !FIN! par exemple). |
| Utilisation de sous-select |
| Le but de cette fonctionnalité est de pouvoir appeler une requête WIM à l'intérieur d'une autre requête WIM, et donc de pouvoir intégrer une mise en forme dans une autre mise en forme. Comme toujours, le plus simple est d'étudier un exemple. Besoin : Editer des commandes de ventes (en-tête et lignes). Remarquons tout de suite que cela est faisable directement avec un seul select, en utilisant une mise en forme qui gère des ruptures. Comme le but est d'étudier l'utilisation de sous select, nous ne choisirons pas cette solution. Mise en place : nous allons avoir besoin de deux selects : - un premier select qui se chargera de ramener les en-têtes ; - un second qui lira les lignes. MISE EN PLACE DU PREMIER SELECT Voici les colonnes pour l'exemple :  Il n'y a rien de particulier ici. Mise en forme (GTUFRM) : C'est ici que nous allons préciser l'appel d'une autre requête WIM :  Pour appeler un nouveau select, il faut respecter une syntaxe qui est : !$SELECT=xxxxxxxxxxxx$! , où xxxx représente le nom de la requête. Tout ce qui est compris entre !$ et $! sera donc considéré comme une "variable" et sera remplacé directement dans la mise en forme par le résultat du sous select. Donc, ici, nous allons afficher : La classe de commande, son numéro, sous-numéro et le client, puis le résultat de la requête VTE_CDV_LCV. MISE EN PLACE DU SECOND SELECT  Comment synchroniser ce sous select avec le select "père" : Il est possible d'utiliser les alias définis dans le select père, et de les passer en paramètre dans le select déclenché. Dans notre exemple, le select père va ramener des commandes. Pour récupérer les lignes associées à la commande traitée par le select père, il suffit de passer l'identifiant de la commande : Voici ce qui est fait :  La "jointure" est donc faite entre le select père et le select fils par la valeur de $NUICDV (alias utilisé dans le select père). Donc, chaque fois qu'une commande sera ramenée par le select père, son "nuisvcdv" sera passé au select fils. Remarque : il est aussi possible de passer la valeur d'un alias du select père dans les colonnes et dans le from. Cela permet entre autre d'afficher des valeurs du père dans la mise en forme du fils, de gérer des "compteurs". Exécution pas à pas 1) le select père est lancé 2) la mise en forme du select père affiche : Classe, numéro, sous-numéro et client 3) WIM détecte un sous select 4) WIM remplace, dans le select fils, tous les alias qui peuvent provenir du select père. Donc, $NUICDV sera remplacé. Le select fils sera donc : select ... from svlcv where nuisvlcv = 4477 (par exemple) 5) Le select fils est exécuté, mis en forme 6) le résultat de la mise en forme est "remonté" au select père, et mis en lieu et place de l'expression " !$SELECT=VTE_EDTCDV$! ". 7) le select père traite l'enregistrement suivant ... Remarques : Un sous select peut s'appeler lui-même => le principe de récursivité est donc accepté par WIM. Le principe des sous select peut être mis en place quelle que soit la mise en forme (html, ruptures, texte). Il n'y a pas de limites fixées par WIM quant au niveau d'imbrication des sous select. Ce niveau est par contre limité par le SGBD. Passages de paramètres "en dur" En utilisant la syntaxe suivante, on peut forcer le passage de paramètres à la requête fille : !$SELECT=nom-de-la-sousrequête [Nomparam1=Valeur ; Nomparam2=valeur ...]$! Exemple : !$SELECT=SOUSEL [ETS=IFR; NUISACDA=123]$! Lors de l'exécution de la sous requête, si celle-ci utilise dans ses clauses l'alias $ETS, $NUISACDA, ceux-ci seront remplacés par IFR et 123. - Il s'agit d'ajout de paramètres, l'ancien fonctionnement étant conservé. - Ne pas utiliser de "nomparam" existant déjà dans la requête, à moins de souhaiter voir la valeur initiale écrasée. - L'expression entière (depuis !$ jusqu'à !$) doit tenir sur une ligne. |
| Prise en compte des symboles ($JOUR, $ |
| Ces symboles sont utilisables directement dans la requête ou directement dans la mise en forme. Une syntaxe particulière est à respecter lors de l'utilisation de ces symboles : utiliser les balises <# (début) et #> (fin). Exemple : where clasvcdv = 'CDV' and dcrsvcdv = '<#$JOUR#>' and dcdsvcdv between '<#$JOUR#>' and '<#$JOUR+7J#>' and etssvcdv = '<#$ETS#>' A noter : Dans le cas d'un traitement en différé (systématisation), l'établissement courant est l'établissement par défaut de l'utilisateur défini dans le fichier de paramétrage du lancement de WIM (la majorité du temps, il s'agit de GTI). Dans le cas d'un lancement en immédiat, c'est l'établissement par défaut de l'utilisateur lançant le job qui est pris en compte. |
| Utilisation directe des paramètres dans une mise en forme |
| Possibilité d'utiliser directement dans la mise en forme le "tag" $$CP_xxxx avec xxxx = nom du paramètre. Exemple : en utilisant $$CP_PARAM01 dans la mise en forme, et lors d'un appel de WimServlet du style : ...action=select&requete=TEST&$PARAM01=Test, on va retrouver la chaîne de caractères "Test" à la place de $$CP_PARAM01. Ce principe est le même dans le cas d'un WIM lancé par traitement si on veut utiliser la valeur d'un paramètre de traitement. Par exemple, en utilisant $$CP_CHAINE9D, on pourra afficher le contenu du critère CHAINE9D. |
| Utilisation de symboles pour références "externes" (url, chemin de fichier, images) ou toute autre valeur fixe |
| Il arrive très fréquemment que, lors de l'écriture de mises en forme WIM, on souhaite faire référence à des liens de type URL (l'exemple le plus courant étant un appel à WimServlet ou à l'interface utilisateur), ou des liens vers des images, des feuilles de styles, des fichiers, ... Si vous saisissez ces adresses de façon figée, cela peut entraîner des problèmes si : - Vous copiez des bases de données (par exemple une base de production vers une base de test). Dans ce cas, les liens sont tous à reprendre pour rester cohérent et bien faire référence au bon serveur. - Vous changez de nom de serveur ou de répertoire (...). Là aussi, il faudra reprendre tous les liens pour actualiser. Cela peut s'avérer fastidieux et être source d'erreurs ou d'oublis. Pour simplifier, un mécanisme de paramétrage global est disponible. Il suffit de définir à un seul endroit un symbole associé à une racine d'adresse, et ensuite d'utiliser le symbole. Le jour où un serveur change, ou une base est copiée, un seul changement sera à faire au niveau du symbole. Exemple : Dans une mise en forme HTML Wim, vous avez deux références. La première sur une image : <img src="http://serveur_image/logo/grand_logo.png"> La seconde une référence vers un appel WimServlet : < href="http://serveurWim/servlet/com.qualiac.tus.WimServlet?action=........"> Dans cet exemple, on voit qu'il serait intéressant de définir deux symboles, un pointant vers l'image, l'autre vers le serveur WimServlet. Pour définir les symboles, vous avez la possibilité de créer, puis d'utiliser des occurrences du paramètre SUBSTWIM. Par exemple, dans GPAR, on peut créer l'occurrence LOGO. Ensuite, dans le texte du paramètre, saisir http://serveur_image/logo/grand_logo.png. On peut aussi créer une autre occurrence APPELWIM. Dans le texte, saisir http://serveurWim/servlet/com.qualiac.tus.WimServlet Utilisation des symboles de substitution : Dans la mise en forme, utiliser la syntaxe <&NOM_OCCURENCE&> Dans l'exemple, on aura donc simplement : <img src="<&LOGO&>"> La seconde une référence vers un appel WimServlet : <href="<&APPELWIM&>?action=........"> A noter : Il existe une seconde possibilité pour définir les symboles. Au lieu de les définir en tant qu'occurrences du paramètre SUBSTWIM, on peut les définir en tant que variable globale. Pour cela, il faut créer dans GGLO des variables dont le nom est préfixé par WIM_SB. Dans notre exemple, on aurait à définir WIM_SBLOGO et WIM_SBAPPWIM (12 caractères maximum pour le nom de la globale). L'équivalent du texte de l'occurrence se définit en tant que valeur de la globale. L'utilisation suit ensuite exactement le même principe, par exemple : <imgsrc="<&WIM_SBLOGO&>"> Si vous modifiez ou créez des symboles (aussi bien via GPAR que GGLO), ils ne seront pas immédiatement disponibles dans WimServlet ou dans les Wim systématisés, car les paramètres et les globales ne sont lus que lors du démarrage du service Web (pour WimServlet) et des files de travaux pour les Wim systématisés. Pour WimServlet, il existe une action qui permet de recharger les globales et autres paramètres : il s'agit de action=reload. Pour les Wim systématisés, il faudra procéder à un arrêt/démarrage des files de travaux (pas nécessaire pour les Wim lancés par job). |
| Utilisateurs / Gestionnaires dans les abonnements et liste de diffusion | |||||||||||||||
| Afin de faciliter la gestion des abonnements et utilisateur, une possibilité est offerte. Il s'agit de la prise en compte du gestionnaire associé à l'utilisateur lors de la recherche des adresses mail. Il n'est pas nécessaire d'avoir une correspondance directe entre le code utilisateur et le code gestionnaire. Voici le mode de fonctionnement : Dans GTUABO (cas abonnement), il faut préciser un code utilisateur ou une liste d'utilisateurs (cas liste de diffusion). Si le gestionnaire est précisé dans la gestion des utilisateurs (GUSI), pour l'utilisateur concerné, ce sera l'adresse mail de ce gestionnaire qui sera prise en compte. Si le gestionnaire n'est pas renseigné, on conserve la méthode déjà utilisée (recherche de l'adresse du gestionnaire correspondant directement au code utilisateur).
|
| Contrôle sur la classe définie dans GTUREQ | ||||||||||||||||||||||||||||||
| Si la classe (entité achat, vente, production, maintenance) est renseignée, seules les requêtes correspondant à la classe traitée seront prises en compte (il faut aussi que l'étape corresponde). Si la classe n'est pas renseignée, ce contrôle ne sera pas fait. Dans le cas d'un traitement immédiat, la classe n'est donc plus obligatoire dans GTUREQ. Exemple : Lancement d'un job sur une commande de ventes, de classe "COM", étape 400. Il existe trois requêtes portant sur l'étape 400.
Lancement d'un job sur une commande de ventes, de classe "CDV", étape 400.
Lancement d'un job sur une commande de ventes, de classe "CDV", étape 400.
|
| Suivi du démarrage/arrêt ou problèmes lors des systématisations |
| En positionnant la globale WIM_ADMADR, un mail sera envoyé vers cette adresse (administrateur wim) : - Lors du démarrage du process Wim systématisé ; - Lors de l'arrêt normal (arrêt des files, sauvegarde, ...) ; - Dans certains cas d'erreurs. |
| Accès aux fichiers de compte rendu |
| Quand le process WIM systématisé s'exécute, il écrit (au minimum) un fichier de compte rendu sur le serveur de traitements. Pour visualiser ces fichiers, il faut regarder pour la file de travaux (GFJB) et voir la consultation associée CTFAO. |
| Formater l'affichage des colonnes de type numérique ou date |
| Quand une requête WIM ramène des colonnes de type numérique ou date, il est possible de définir un format qui sera appliqué lors de l'affichage de l'alias correspondant dans la mise en forme. Pour cela, dans la mise en forme, une nouvelle section est à définir : <!-- BEGIN_DATA_FORMATS ... ... END_DATA_FORMATS --> A l'intérieur, il faut définir, dans le cas d'une date : NOM_ALIAS DATE FORMAT_DATE_A _APPLIQUER Le format à appliquer peut contenir YYYY, YY, MM, DD, et n'importe quel autre caractère. Dans le cas d'un numérique, le format est composé de 0, #, . : 0 permet de représenter un chiffre qui devra obligatoirement être présent, même s'il s'agit d'un zéro inutile. # permet de représenter un chiffre en ignorant les zéros inutiles. . (le point) permet de représenter le séparateur de la partie décimale. , (la virgule) permet de représenter le séparateur des groupes (milliers, millions, etc.). Le nombre de 0 et/ou de # dans le format détermine la taille des parties entière et décimale de la valeur numérique, sachant que 0 représentera un chiffre obligatoirement présent (et éventuellement remplacé par un zéro inutile) et # un chiffre optionnel (qui ignorera donc les zéro inutiles). |
| Quelques exemples | ||||||||||||||||||||||||||||||||||||||||||||||||||
Il est aussi possible de préciser la "localisation" ("fr" pour France, us, en, etc.). Exemple : <!-- BEGIN_DATA_FORMATS LOCALISATION fr DTDSACDA DATE YYYY/MM-DD QTESALCA NUM ###,###.0 END_DATA_FORMATS --> L'alias DTDSACDA représente une date. Avec la valeur 20100312, l'affichage de celle-ci, selon le format précisé se fera donc sous la forme : 2010/03-12 Pour l'alias QTESALCA, de type numérique, si celui-ci vaut 123456.16, l'affichage sera : 123 456.2 (le séparateur de milliers en France étant l'espace, avec une seule décimale). Pour appliquer un format sur une variable de cumul (CUMxxRyy), il suffit d'ajouter dans la "section format" une ligne du type : CUMxx NUM format Exemple : <!-- BEGIN_DATA_FORMATS LOCALISATION fr DTDSACDA DATE YYYY/MM-DD QTESALCA NUM ###,###.0 CUM01 NUM ###,###.0 CUM02 NUM ###,###.000 END_DATA_FORMATS --> A noter : si on souhaite combiner les fonctions de formatage avec la notion de multi-langues (!WIM_LAN, etc.), il faut ajouter l'attribut USER_LANGUAGE pour associer le format avec la langue. Par exemple : LOCALISATION fr USER_LANGUAGE EN DTDSACDA DATE YYYY/MM-DD |
| Suivi de l'exécution des requêtes (archivage) |
| En cochant la zone "Archivage" dans GTUREQ, des informations permettant de suivre l'exécution des requêtes seront accessibles via la consultation CHRE (à quelle date, quelle heure, vers qui, ...). Attention, le volume des informations pouvant être relativement important, il est conseillé de n'activer l'archivage que sur les requêtes "sensibles", dont le suivi correspond à un réel besoin. |
| Numéros de mise en forme réservés pour documenter la requête |
| Dans GTUFRM (bouton "mise en forme" depuis GTUREQ), il est possible d'utiliser des numéros de mise en forme supérieurs ou égaux à 9999999 pour documenter la requête. Cela peut s'avérer très pratique pour commenter la façon dont est codé le select, l'utilisation des javascripts, des explications fonctionnelles ou toutes autres remarques. |
| Lecture des paramètres du traitement sur une requête lancée par job |
| Il est possible de récupérer les paramètres du job (numéro, traitement, imprimante, format d'impression, etc.) par lequel est lancée une requête WIM. Pour cela, dans le select (aussi bien au niveau des colonnes que des clauses), les variables du type $JOB_xxxGTJOB sont utilisables. Par exemple, pour lire le numéro du job, utiliser $JOB_NUMGTJOB ; pour l'imprimante, utiliser $JOB_IMPGTJOB. |
| Appel de procédures stockées dans la mise en forme |
| Il est possible de définir, dans la mise en forme d'une requête, via des balises spéciales, des appels de procédures stockées. Cette fonctionnalité est à utiliser avec prudence, et au cas par cas, car les performances ne sont pas optimales sur des appels multiples. Pour cela, il faut, dans la mise en forme, respecter la syntaxe suivante : !$CALLPROC WIM_PROC=nom_proc@;@ WIM_AFF=O@;@ paramètre1=valeur du paramètre@;@ paramètre2=valeur du paramètre 2@;@ ... paramètre1 en sortie = texte à afficher en sortie + alias $WIM_OUT pour afficher la valeur@;@ ... @;@ CALLPROC$! WIM_AFF, qui par défaut vaut N (Non), permet de préciser si on souhaite afficher le résultat de l'appel (doit valoir O dans ce cas). WIM_AFF peut aussi prendre la valeur E Dans ce cas, si la procédure se passe bien, rien ne sera affiché, par contre, en cas d'erreur, le message d'erreur sera remonté. Les paramètres sont séparés par @;@ Exemple : appel de la procédure d'existence de l'établissement, pour rechercher la devise et l'intitulé. !$CALLPROC WIM_PROC=psgtetsext@;@ WIM_AFF=O@;@ NUMGTETS=IFR@;@ PO_INRGTETS=voila l'intitulé : $WIM_OUT @;@ PO_DEVGTETS=et voila la devise : $WIM_OUT @;@ CALLPROC$! Le résultat : En lieu et place de l'appel, on retrouvera : voilà l'intitulé : Etablissement IFR et voilà la devise : euro |
| Génération de fichiers Excel depuis les données ramenées par une requête WIM |
| Il est possible de créer un vrai fichier Excel à partir d'une requête WIM. Pour cela, il faut préciser, dans la mise en forme, ce que l'on souhaite faire, grâce à une série de balises (sur le principe des balises d'appel de procédure). !$CREATEXLS WIM_CM=classeur excel modèle (chemin complet)@;@ WIM_OD=nom de l'onglet qui reçoit les données dans le classeur modèle@;@ par défaut = data WIM_LM=numéro de la ligne de l'onglet qui sert de modèle pour affecter les données dans le classeur modèle@;@ par défaut = 1 WIM_CS=caractère séparateur du fichier de données brutes@;@ par défaut = celui du fichier csv généré par WIM (m_namexls) WIM_FR=nom du fichier résultat. Afin de conserver l'unicité du fichier, le système préfixera ce nom par un identifiant unique @;@ WIM_LFR=nom du fichier résultat. Peut être utilisé au lieu de WIM_FR. Dans ce cas, on force le nom du fichier avec la valeur définie ici. L'unicité ne sera donc pas garantie, ce qui peut provoquer des problèmes (plusieurs process écrivant dans un même fichier par exemple) @;@ WIM_FO=fichier de données d'origine X pour fichier xls (par défaut) ou T pour texte mis en forme WIM_RFL=tenir compte de la première ligne dans le fichier brut@;@ (par défaut N car la première ligne de m_namexls contient les labels, ce qui ne nous intéresse pas) CREATEXLS$! Le principe est d'utiliser un classeur excel "modèle" (qui doit être accessible depuis le serveur de traitements dans le cas d'un WIM systématisé ou par job, depuis le serveur Web dans le cas d'un appel WimServlet). Dans ce classeur, un "onglet" (une page) va recevoir les données ramenées par la requête. Cette feuille peut donc ensuite être utilisée comme page de données à une autre feuille du classeur, qui lui fera référence, et qui pourra donc afficher une présentation plus complexe (graphique, tableaux croisés, etc.). Les données peuvent provenir directement de la requête principale (option WFO=X, on utilise alors le fichier csv basique généré par WIM), mais on peut aussi utiliser des données affichées via la mise en forme (Option WIM_FO=T). Cela peut s'avérer intéressant dans le cas d'utilisation de sous-requêtes par exemple. En effet, le résultat de l'exécution de sous-requêtes n'est pas remonté dans le fichier csv de la requête principale, mais il est par contre bien affiché dans la mise en forme. Exemple : !$CREATEXLS WIM_CM=c:/temp/sgeart.xlsx@;@ WIM_FR=c:/temp/sgeart_wim.xlsx@;@ WIM_RFL=O@;@ CREATEXLS$! Dans le cas d'un envoi par mail, le fichier excel ainsi généré prendra la place du fichier csv "standard". On pourra donc le renommer en utilisant la balise !WFX ... standard. Dans le cas d'un appel via WimServlet, il faut utiliser l'option &keepxls=O pour activer ce mécanisme. Une autre option &extmodel permet de préciser l'extension du fichier généré (par défaut, on utilise xls, mais cela permet de préciser xlsx, xlsm, etc.). |
| Appel d'outils externes lors de la génération du mail |
| Dans la mise en forme, on peut ajouter une balise !WEXE=xxxxxxxxxxxxx WEXE !. xxxxxx représente le nom d'un outil externe qui sera appelé sur le serveur de traitement et qui pourra traiter les fichiers générés par WIM (fichier xls, txt, html). Exemple : !WEXE=/tmp/test.sh WEXE! Dans ce cas, pour chaque mail, on lancera la commande /tmp/test.sh avec les arguments (dans l'ordre : nb de fichiers passés, fichier txt, fichier xls, fichier html, fichier pdf et options éventuellement (!WEXO = ... WEXO!)). Pour que la commande puisse se lancer, il faut qu'elle soit référencée dans le fichier défini dans la globale MAIL_AUTEXE. Dans l'exemple, il faudra donc que /tmp/test.sh soit dans le fichier. |
| Ne pas envoyer de mail, tout en interprétant les mises en forme |
| Bien que cela puisse paraître paradoxal, certaines requêtes WIM principales ne sont pas faites pour l'envoi de mail. Par exemple, la requête sert uniquement à lancer des jobs via les JLR, ou à appeler des procédures. Jusqu'à la version G1.01 (comprise), il existait deux possibilités pour ne pas déclencher le mail. 1) décocher tout type d'adresse ; 2) ajouter une balise !WSD=N WSD ! dans le corps du message. Inconvénients : Les mises en forme ne sont pas appliquées, donc les sous-select (!$SELECT=...) ne sont pas déclenchés (donc pas de JLR associés aux sous-requêtes) ainsi que les appels de procédures. Le mail n'étant pas envoyé, les fichiers temporaires restent sur le serveur. Pour garder les avantages et supprimer les inconvénients, une option est possible. Pour cela, si l'alias d'une colonne est WIMSEND, et si la valeur contenue dans cet alias est "N", la requête est exécutée tout à fait normalement, les fichiers sont construits, les mises en forme appliquées et interprétées si besoin, mais le mail n'est pas envoyé. Enfin, les fichiers temporaires sont supprimés. |
| Désactivation automatique d'une requête en erreur |
| Si le code SQL d'une requête systématisée génère une erreur, cette requête est désactivée (son état passe à 'I', inactif). Ceci évite que cette requête soit lancée en permanence avec forcément toujours la même erreur. De plus, un mail avec l'erreur générée est envoyé au modificateur (ou, à défaut au créateur) des clauses et des colonnes de la requête. |
| Configuration pour WIM standard |
| Sur différentes Applications, des requêtes définies en standard sont mise à disposition. Ces requêtes portent un nom normalisé "QLC_[APP]...", avec APP correspondant au code de l'application sur laquelle porte cette requête. De plus, elles ne sont pas modifiables, mais possibilité d'adaptation par duplication. Des variables globales (GGLO) sont à positionner pour un fonctionnement optimal : Positionner, dans WIM_SBCTX, (la créer si nécessaire) l'URL représentant le contexte de l'application Web de WimServlet. Positionner, dans WIMS_SBTMPW, le répertoire temporaire utilisé (sur le serveur Web) par WimServlet pour générer les fichiers temporaires. Positionner, dans WIM_SBQWROOT, l'URL de base. Positionner, dans WIM_SBWROOT, l'URL représentant le contexte de l'application Web. Positionner, dans WIM_SBTRTTMP, le répertoire temporaire utilisé pour générer les fichiers temporaires sur le serveur de traitement. Positionner, dans WIM_SBQRROOT, l'URL de base de l'interface utilisateur RIA. |
| Fichiers temporaires |
| Le nom des fichiers temporaires est de la forme w[NoJOB][adressemail...]. Ils sont gérés par le traitement d'épuration des fichiers. Un seul fichier interface est utilisé. Même si l'envoi des mails est en échec, les fichiers temporaires sont supprimés. |
| Mode test sur envoi des mails |
| Le mode test fait que tous les mails ne sont plus envoyés aux destinataires prévus dans les requêtes, mais sont redirigés vers une autre adresse. Pour activer le mode test, les variables globales (GGLO) MAIL_MODTEST et MAIL_ADRTEST doivent être positionnées. Dans ce mode, le sujet du message est modifié, il indique qui aurait du recevoir le message en mode normal (destinataire, copie et copie cachée). |
| Requête multi-langues |
| Il est possible, dans chaque mise en forme, de préciser la langue qui va concerner cette mise en forme. On peut donc par exemple, définir des mises en forme 10 et 20 en Français, et des mises en forme 30 et 40 en Anglais. Pour cela, il suffit, dans les mises en forme 10 et 20, d'ajouter la balise !WIM_LAN=FR WIM_LAN! Et, dans les mises en forme 30 et 40, d'ajouter !WIM_LAN=EN WIM_LAN! Pour savoir quelle mise en forme utiliser en fonction des données (donc de façon dynamique), il faut utiliser une colonne qui a comme alias WIMLAN dans GTUCOL. Quand l'alias a pour valeur FR, on utilise les mises en forme 10 et 20. Quand la valeur est EN, on utilise les mises en forme 30 et 40. Pour un appel depuis WimServlet, il faut préciser le paramètre &langue dans l'URL d'appel. Remarque : ce principe s'applique aussi en cas de mise en forme avec rupture et/ou dans les mises en forme des sous-requêtes. |
| Utilisation de "constantes" issues du select dans la mise en forme |
| Pour utiliser une constante issue du select dans une mise en forme, la règle standard de WIM est que dès qu'un alias apparaît dans une mise en forme, cette mise en forme est répétée autant de fois que le select ramène de lignes de données. Pour afficher cette "constante" (valeur ramenée par le select, mais dont on sait pertinemment que cette valeur ne changera jamais, quelle que soit la ligne de données), une solution est de définir une mise en forme avec rupture. Une autre possibilité est d'utiliser l'alias $CONSTANT_xxxxx, avec xxxxx = nom de l'alias dans GTUCOL (par exemple $CONSTANT_ETSNUM). $CONSTANT_xxxxx n'est remplacé qu'une seule fois (on peut donc l'utiliser sans problème dans une mise en forme de début, sans craindre que cette mise en forme soit répétée). La valeur affichée est celle de la première ligne de données lue. Cette deuxième technique est plus simple pour afficher des paramètres récapitulatifs en début de document (critères de sélection utilisés par exemple). |
| Activation de la compression (zip) pour les pièces jointes des mails |
| La balise !WZIP=TRUE WZIP! dans la mise en forme d'un WIM active la compression des fichiers joints. De plus, une nouvelle globale MAIL_MXPJ permet de préciser dans sa valeur la taille maximale (en Ko) que peut prendre une pièce jointe sans être compressée (et ce quelle que soit la valeur de la balise !WZIP). Par défaut, cette valeur est de 5000 Ko (donc environ 5 Mo). |
| Forcer l'envoi du mail à passer en mode debug |
| La balise !WFDB=chemin+nom fichier WFDB! permet d'activer le mode debug sur l'envoi du mail et de préciser l'emplacement et le nom du fichier de trace. |
| Mettre des documents issus de la GED en pièces jointes du mail |
| En utilisant la balise !WGED= [liste de paramètres] WGED!, il est possible de chercher des documents dans la GED et de les mettre en pièces jointes. Pour cela [liste de paramètres] doit respecter la syntaxe : ide=[identifiant de l'entité sur laquelle on recherche les documents]&den=[entité de GTDEN]&dty=[type de document]. Toutefois, la syntaxe "WimServlet" est à privilégier : p01=[identifiant]&doc_gtden=[entité]&doc_gtdty=[type de document] Exemple : !WGED= ide=12456&den=ACHAT_DEVIS&dty=DEVIS WGED! ou !WGED= p01=12456&doc_gtden=ACHAT_DEVIS&doc_gtdty=DEVIS WGED! Si des documents sont trouvés, ils sont joints sous forme d'un fichier compressé. Il est possible de gérer plusieurs balises WGED dans le corps d'un mail. En effet, si on trouve plusieurs WGED, ils seront tous interprétés, et on retrouvera, par défaut, un fichier compressé (zip) par entité. L'option WALLGED est à utiliser pour préciser qu'on ne souhaite qu'un seul fichier zip qui contiendra tous les documents. Le nom du fichier zip sera défini dans cette balise. Exemple : !WALLGED=Documents_associes WALLGED! Dans ce cas, le fichier joint sera nommé Documents_associes.zip Un argument à l'intérieur de la balise WGED permet de préciser un préfixe aux fichiers récupérés, ce qui peut, entre autre, permettre de les repérer facilement. Il s'agit du paramètre &prefix Exemple : !WGED= ide=WD_0001&den=ARTICLE&dty=PLBASE1&prefix=plan_WD_0001 WGED! Dans ce cas, les fichiers associés à l'identifiant WD_0001 porteront un nom commençant par Plan_WD_0001xxxxxxx. |
| Travaux déclenchés par une requête (traitements) |
| Principe |
| Il est possible de déclencher des travaux (éditions, traitements) lorsque les conditions précisées dans la requête sont réunies. Par exemple, on peut lancer l'intégration des écritures comptables (TECT) chaque fois que le nombre d'écritures à transférer est supérieur à 500. L'avantage, dans ce cas-là, par rapport à une systématisation classique est d'éviter de générer trop de jobs. En effet, un seul job est lancé et uniquement quand la condition est remplie. Voici la liste des fonctionnalités : · Déclenchement de un à plusieurs travaux. · Définition de l'ordre d'exécution des travaux. · Chaque job déclenché peut l'être une seule fois par requête (dont les conditions sont remplies) ou x fois (lancement du job à chaque enregistrement ramené par le select). · Possibilité de lancer un enchaînement. · Définition d'intervalles pour le déclenchement des jobs (tous les jours, toutes les 20 minutes, ...). · Prise en compte des critères par défaut des soumissions. · Prise en compte des critères de façon dynamique (les critères proviennent alors des informations ramenées par la requête). · Utilisation des symboles $JOURS,$ETS, ..., possible. · Enfin, le fonctionnement "classique" reste toujours assuré (envoi de mail). |
| Exemples |
Exemple 1 : lancement du transfert des écritures lorsque leur nombre est supérieur à 500 Définition du select Select 'p.dupont@qualiac.com', count(*) adresse en dur From ocect Where 1=1 artifice pour ne pas faire where having Having count(*) > 500 Définition du traitement à lancer Ouvrir GTUJLR depuis GTUREQ  Etablissement courant : Il s'agit de l'établissement courant qui sera défini comme tel pour l'exécution du traitement (habituellement sans importance pour les traitements multi-établissements, mais à préciser pour les traitements qui ne gèrent qu'un seul établissement). Il peut être précisé de façon fixe, ou alors il est possible d'utiliser une zone ramenée par la requête en précisant un alias (Attention, limité à 4 caractères). Ordre : ordre dans lequel sera lancé le job. Dans notre cas, il n'y aura pas d'influence car un seul traitement. Type : indique le type de lancement du job. Exécution par requête : · Unique : job lancé une seule fois, quel que soit le nombre d'enregistrements ramenés par le select ; · Multiple : job lancé pour chaque enregistrement ramené par le select. Intervalle : intervalle de temps à respecter entre deux lancements de jobs identiques. Unité exprimée en minute, si non renseigné, pas de contrôle. Dernière soumission : dernier numéro de job généré, et date et heure de génération. En résumé, nous allons lancer le traitement TECT, de façon immédiate, chaque fois que le nombre d'enregistrements dans GECT sera supérieur à 500. Le traitement TECT sera lancé une seule fois par requête remplissant les conditions, en utilisant les paramètres par défaut de la soumission TECT. |
| Exemple 2 : lancement du transfert des écritures lorsque leur nombre est supérieur à 500 (par journal). Le transfert se fera journal par journal. Définition du select Select 'p.dupont@qualiac.com', count(*), jrnocect (l'alias de jrnocect est JRN) From ocect Where etsocect = 'IFR' Group by jrnocect Having count(*) > 500 Définition du traitement à lancer Ouvrir GTUJLR depuis GTUREQ  Définition des paramètres du traitement à lancer Ouvrir GTUPJB (bouton paramètres d'exécution). C'est dans cette transaction que l'on précise les valeurs à prendre en compte.  Ici, nous disons donc : lancer le traitement OCTECT (TECT), avec journal de début = journal de fin = journal de l'enregistrement courant ramené par la requête, pour l'établissement IFR. En résumé, nous allons lancer le traitement TECT, de façon immédiate, pour chaque journal dont le nombre d'écritures en attente de transfert est supérieur à 500. Le transfert sera fait journal par journal (à chaque enregistrement). Donc, s'il y a quatre journaux dont le nombre d'écritures est supérieur à 500, quatre traitements seront lancés. |
| Compléments |
| Il est possible d'utiliser les symboles ($JOUR, $ETS, ...) dans les zones valeurs des paramètres. Il est possible d'utiliser comme critère tout ce qui peut être lié au paramétrage du traitement. Par exemple préciser l'imprimante de destination : critère => IMPGTJOB, valeur => nom de l'imprimante Nombre d'exemplaires : critère => NEXGTJOB, valeur => nombre etc. De plus, un paramètre particulier existe : JLR_LANCER. Selon sa valeur, le job sera lancé (O) ou non (N). Cela peut permettre de conditionner le lancement d'un job à la valeur d'une colonne ramenée et gérer ainsi des exceptions. Comme il est possible d'utiliser des "sous-select" dans la mise en forme d'une requête, il est important de noter que ces sous select sont eux aussi capables de lancer des jobs. Dans le cas d'un lancement de type unique (lancement d'un seul traitement), même si la requête ramène plusieurs lignes de données, il est possible de préciser si on souhaite que ce lancement se fasse avec les valeurs de la première ligne de données ramenée (par défaut) ou sur la dernière. Si le type (dans les paramètres standard) vaut "T", alors le traitement ne sera lancé qu'à la fin de l'exécution de la requête, en prenant comme ligne de données de référence la dernière ramenée. |
| Pouvoir lancer les enchaînements dynamiques via les jobs liés aux requêtes |
| Dans les jobs liés aux requêtes, il est possible de préciser un mnémonique particulier. Il s'agit d'un mnémonique qui n'a pas besoin d'exister en tant que tel : TRTDYN. Si on utilise TRTDYN, cela signifie que l'on souhaite lancer les traitements par étape suivant l'étape à laquelle se trouve l'entité que l'on est en train de traiter ("simulation" du bouton "traitement" dans les commandes d'achats, de ventes, ordres de production, ...). Les paramètres (TUPJB) qui doivent être passés sont les suivants. Il s'agit de paramètres qui n'ont pas besoin d'exister en tant que paramètres de job classiques : PI_DOM => domaine (A, V, P, ...) PI_ETS => établissement PI_ENT => entité (SACDA, SVCDV, QAORD, ...) PI_NUM => numéro interne de l'entité à traiter PI_EXE => I ou D (traitement immédiat ou différé) D'autres paramètres sont facultatifs : PI_APL => pour préciser un mnémonique en particulier PI_MINCLA => plus petite classe de l'entité (utile pour les listes) PI_MINETP => plus petite étape de l'entité (utile pour les listes) PI_LAN => langue PI_DET => destination (C : catalogue, ...) |
| Action sur la base de données depuis le mail, un navigateur (WimServlet) |
| Principe |
| Le but de cette fonctionnalité est de pouvoir effectuer des actions simples sur la base de données (généralement des mises à jour et des requêtes) directement depuis le mail et/ou le fichier HTML reçu via WIM, et cela sans passer par l'interface utilisateur. Gestion de l'authentification Par défaut, il vous est demandé de vous identifier lors de votre première connexion (utilisateur et mot de passe Cegid XRP Ultimate). La durée de vie de cette authentification est exprimée en minutes dans la variable globale WIMS_MAXAGE. Par exemple, si WIMS_MAXAGE vaut 40, l'utilisateur n'a pas besoin de s'identifier pendant les 40 minutes suivant la première connexion. Par contre, après 40 minutes, on demande à nouveau la connexion. Il est aussi possible de gérer un principe de durée d'inactivité. Dans le même exemple, on ne demandera l'authentification qu'au-delà de 40 minutes d'inactivité (aucun accès à WimServlet pendant 40 minutes). Pour cela, il faut positionner la globale WIMS_CKFIX. On peut aussi ne pas demander l'authentification WimServlet si vous êtes déjà connecté. Si la variable globale WADM_CNXWW a pour valeur [WEBTOWIM], on ne demande pas l'authentification WimServlet si un utilisateur est déjà connecté sur le poste (pour un même navigateur). Il est possible d'écrire, en respectant certaines spécificités (interface), une classe Java personnalisable qui sera ensuite appelée pour gérer l'authentification. L'authentification sera dans ce cas "externalisée", ce qui s'avère nécessaire dans le cadre d'une démarche SSO. Connexion "Multi utilisateur" (utilisateur logique) Lorsque le LDAP est activé (et éventuellement le mode SSO), il est possible de proposer, lors de la connexion à WimServlet, une liste permettant de choisir parmi plusieurs utilisateurs. Exemples : - en mode LDAP seul, dans la boîte de connexion, l'utilisateur saisi est USER. A cet utilisateur, on a associé fonctionnellement USER1,USER2 et USER3. Dans ce cas, juste après la boite de connexion, une nouvelle fenêtre va s'afficher en demandant de choisir un utilisateur logique, donc on aura à choisir entre USER1, USER2 ou USER3. La valeur choisie deviendra alors l'utilisateur courant pour la "session" (cookie) WimServlet. Pour alimenter la liste de choix, on se base sur un select, décrit dans le fichier qualiacdb.properties A noter : - Si la requête permettant de donner la liste des utilisateurs logiques ne ramène qu'une seule valeur, alors la liste de choix ne sera pas affichée, on prendra automatiquement la valeur. - Cette fonctionnalité est compatible avec le mode SSO. Dans ce cas, la boite de connexion ne sera pas affichée, mais on arrivera directement sur la liste de choix des utilisateurs logiques - la fenêtre affichée peut être relookée. On utilisera le principe des mise en forme des boites de connexion, en utilisant la valeur contenue dans la globale WIMS_ORDCBAO. Le code HTML doit alors contenir le mot clef $SELECTACCOUNTS example : <html>... <select name="accountName">$SELECTACCOUNTS</select> Action Plusieurs types d'actions sont possibles : - Exécution d'une requête directement depuis le mail, exemple : visualisation du détail d'une commande - Actions sur la base de données, exemple : signature d'une commande - Appel de traitements, ... Techniquement, cela repose sur un programme (servlet) qui doit tourner sur un serveur. Le préalable à l'utilisation de cette fonctionnalité est donc l'installation de ce serveur. Le principe consiste à faire appel à une URL (adresse web) depuis un navigateur. La racine de cette adresse est constante, du type http://serveur:port/.../com.qualiac.tus.WimServlet. Ensuite, pour distinguer les différentes fonctionnalités que l'on souhaite appeler, il suffira de passer des paramètres à la suite de la racine. Le passage de paramètres à une URL se fait de la façon suivante : - Pour séparer la racine des paramètres, utiliser le caractère ? - Pour séparer différents paramètres, utiliser le caractère & - Pour donner une valeur à un paramètre, la syntaxe est nom_paramètre=valeur Donc, en exemple, si on souhaite passer trois paramètres (p1,p2 et p3), on devra respecter la syntaxe suivante : http://serveur:port/.../com.qualiac.tus.WimServlet?p1=valeur1&p2=12345&p3=VAL3 Remarque : Votre navigateur doit accepter l'utilisation de "cookies". Sans cela, le mot de passe vous sera demandé à chaque action. Pour connaître la liste des paramètres disponibles et des actions possibles, appelez WimServlet en passant simplement les paramètres action=help. Quand le WimServlet démarre, des informations techniques sont stockées dans une table accessible en consultation uniquement via le mnémonique GMNDWSL. Il s'agit des entités suivantes avec leur valeur : Servlet OS : Operating system courant Servlet Context : Contexte du servlet Servlet Name : Nom du servlet Servlet ServerPort : Port d'écoute du serveur Servlet ServerName : Nom du serveur Servlet Java Version : Version de java utilisée Servlet Java Home : Java Home utilisé Servlet Infos : Information sur le moteur de servlet Servlet Start Date : Date et heure de démarrage Servlet Path Spool : Chemin complet vers répertoire temporaire |
| Liste des actions disponibles | ||||||||||||||||||||||||||||||
Le paramètre "action" permet de préciser la fonctionnalité que l'on souhaite utiliser. Il peut prendre plusieurs valeurs :
Lors de l'action=reconnect, si l'option ret_boolean=T est passée, c'est le mot-clef "true" qui est retourné. Cela peut être utile dans les cas d'une utilisation de connexion via WebServices ou autre programmation pour tester l'authentification. |
| Exécution d'une requête en interactif | ||||||||||||||||||||||||||||||||||||||||||||||
Pour exécuter une requête via WimServlet, l'action à utiliser est "select" (action=select).
Exemple : Nous souhaitons envoyer un mail contenant la classe et le numéro des commandes à l'étape 30. Dans ce mail, nous voulons créer un lien permettant d'afficher des informations complémentaires sur la commande (articles et quantités). Dans GTUREQ, nous avons défini une requête ENT_CDA pour afficher les commandes et envoyer le mail. Cette requête ramène, entre autre, le numéro interne de la commande, que nous stockerons dans l'alias $NUICDA Le mail se présentera sous cette forme.  Il faut maintenant construire la requête permettant d'afficher le détail (appelée sur le lien "voir le détail"). Créons la requête LIG_CDA. Cette requête étant destinée à être déclenchée par un lien, il n'est donc pas utile de préciser une adresse email en première colonne, ni de définir de systématisation. En effet, on sort de la logique requête/mail pour rentrer dans une logique de requête de présentation. |
Les colonnes sont : La requête LIG_CDA doit être dynamique. Effectivement, les données dépendent de la commande sélectionnée. Le select est de la forme : Select artsalca, qtcsalca From salca Where nuisalca = $NU_INTERNE Cela signifie que cette requête attend un paramètre $NU_INTERNE (le nom donné au paramètre est libre). Pour passer ce paramètre dans l'URL, il suffit d'ajouter &$NU_INTERNE=une_valeur. Donc, si on appelle manuellement la requête (ouvrir un navigateur et taper l'URL dans la zone adresse) avec : http://...WimServlet?action=select&requete=LIG_CDA&$NU_INTERNE=1234, cela affichera les informations pour la commande dont le numéro interne est 1234. Revenons à notre requête principale ENT_CDA Le lien hypertexte ("voir le détail") est le suivant (dans GTUFRM) http://localhost:8010/servlet/com.qualiac.tus.WimServlet ?action=select&requete=LIG_CDA&rep=c:\\temp\\&$NU_INTERNE=$NUICDA target="_blank"> (le paramètre target permet d'ouvrir une nouvelle fenêtre) Dans le fichier HTML généré par WIM, $NUICDA est remplacé par sa valeur pour chaque ligne. On aura donc, par exemple : http://localhost:8010/servlet/com.qualiac.tus.WimServlet?action=select &requete=LIG_CDA&rep=c:\\temp\\&$NU_INTERNE=12345 En suivant ce lien, nous allons exécuter la requête LIG_CDA, en remplaçant $NUILCA par la valeur 12345 :  Note technique : L'utilisation de code JSP est autorisée dans les mises en forme des requêtes appelées via WimServlet. Paramètres supplémentaires pour test du select Possibilité d'ajouter une option &clipboard=O sur une action select. Cette option affiche la requête SQL à exécuter. En complément, il est aussi possible d'ajouter à l'option clipboard l'option &countrecords=O, qui donnera en plus le nombre d'enregistrements sélectionnés. Conservation du fichier de données brutes (fichier xls) et affichage de celui-ci Il est possible de faire un lien vers le fichier de données brutes (fichier "excel") qui a servi à générer la mise en forme. Pour cela, le paramétrage à mettre en place est le suivant : 1) Positionner la variable globale WIMS_XLSPATH. Celle-ci va donner le nom du répertoire dans lequel sera stocké le fichier. Il faut d'ores et déjà noter qu'il faudra régulièrement purger ce répertoire (manuellement). Ce répertoire doit correspondre à un répertoire connu du serveur Web et accessible via une URL. exemple : xlspath=c:/temp/xls 2) Dans la mise en forme, (GTUFRM), ajouter le lien vers le fichier en utilisant l'alias réservé $AFFXLS (par exemple http://serveur:port/docbase/xls/$AFFXLS> voir le fichier de donnée). 3) Lors de l'appel de l'URL, ajouter &keepxls=O Limiter le nombre de lignes de données affichées En positionnant la variable globale WIMS_MAXENR avec une valeur numérique X, la requête exécutée n'affichera que X lignes de données. En utilisant la variable globale, cela s'appliquera à toutes les requêtes lancées via WimServlet. Par contre, en passant le paramètre &MX_RECORDS=X dans l'URL d'appel, seul l'appel concerné sera limité. |
| Action sur les enregistrements (appel de procédures stockées) | ||||||||||||||||||||||||||||||||||
Cela se fait aussi via une URL, qui doit respecter un certain nombres de paramètres :
Exemple : mise à jour du dépôt d'une commande d'achats : http://localhost:8010/servlet/com.qualiac.tus.WimServlet?action=callproc&proc=pssacdaupd&NUISACDA=36904&DEPSACDA=ZZZ Ici, le dépôt ZZZ n'existe pas, donc message d'erreur : pssacdaupd en erreur : SGDEP001 Dépôt inexistant ou non utilisable ETS = PL, DEP = ZZZ Pour avoir une autre mise en forme du message d'erreur, il est possible de définir une requête particulière dans GTUREQ, servant de "base de données" pour les différentes mises en forme que l'on souhaite utiliser. Exemple :   En utilisant : http://localhost:8010/servlet/com.qualiac.tus.WimServlet?action=callproc&proc=pssacdaupd&NUISACDA=36904&DEPSACDA=ZZZ&forme=MEF&ordreko=10&ordreok=20 En cas d'erreur, le message sera donc : "La mise à jour du dépôt n'a pas été effectuée. Merci de contacter votre responsable." Utilisation du mot-clé $PARAMETRE dans les formes ordreok et ordreko : Si, dans les mises en forme ordreok et/ou ordreko, vous utilisez l'alias $PARAMETRE, celui-ci sera remplacé par les valeurs des paramètres passés à l'URL d'origine. Dans l'exemple, $PARAMETRE vaudra : &NUISACDA=36904&DEPSACDA=ZZZ. Cela peut permettre de "rebondir" vers d'autres actions. Utilisation du mot-clé $PO_xxxxxx dans les formes ordreok : Si la procédure appelée renvoie des paramètres en sortie (par exemple l'intitulé réduit de l'article inrsgart), il est possible d'afficher cette valeur dans la forme "ordreok" en utilisant le mot-clé $PO_INRSGART, qui sera remplacé par la valeur renvoyée. Utilisation du mot-clé $ERREUR dans les formes ordreko : $ERREUR sera remplacé par le code erreur et le message d'erreur renvoyé par la procédure. Utilisation du mot-clé $JSERREUR dans les formes ordreko : Affiche une alerte javascript (boîte de dialogue) avec le contenu de l'erreur. Utilisation du mot-clé $TXTJSERREUR dans les formes ordreko : $TXTJSERREUR sera remplacé par le code et le message d'erreur, en remplaçant les caractères gênant en javascript. Visualisation des messages d'alerte : Une procédure stockée peut, bien qu'elle se termine correctement, et donc que l'action demandée soit correctement effectuée, faire afficher des messages d'alertes (messages d'information, non bloquants). Pour afficher ces messages, plusieurs possibilités: Prenons l'exemple de l'appel de la procédure psxxyyy, qui peut renvoyer deux messages d'alertes (MESSAGE1 et MESSAGE2) a) lors de l'appel de procédures, vous n'utilisez pas de notion de mise en forme sur le retour de l'appel : ...WimServlet ?action=callproc&proc=psxxyyy&PARAM1=test Si la procédure renvoie les deux messages d'alerte, le texte affiché en retour de cette commande sera : " Procédure psxxyyy correctement effectuée, avec les messages d'alertes suivants : MESSAGE1 MESSAGE2 " b) Vous gérez la notion de mise en forme sur le retour : ...WimServlet?action=callproc&proc=psxxyyy&PARAM1=test&forme=FORME &ordreok=10&ordreko=20 Toujours à titre d'exemple, imaginons que la mise en forme N°10 de FORME soit : |------------------------------------------------------------------------------ | Bonjour, | La mise à jour demandé s'est bien passée. En l'état, les messages d'alertes ne seront pas affichés. Pour qu'ils puissent apparaître, il faudra ajouter le mot-clé $ALERTES dans la mise en forme. De cette façon, vous pourrez placer précisément où vous voulez voir afficher les alertes. Une dernière option est possible : l'utilisation du mot-clé $JSALERTES, dans la mise en forme. Ce mot-clé sera remplacé par du code javascript, qui fera afficher une pop-up affichant les messages d'alerte. $ALERTES et $JSALERTES peuvent être utilisés ensemble ou séparément. Exemple : |--------------------------------------------------------------------------- | Bonjour, | La mise à jour demandé s'est bien passée. | Messages d'informations : $ALERTES Passer la valeur NULL (au sens null de SQL) dans un paramètre en entrée d'une procédure : Il faut utiliser le mot-clé WSL_NULL. Exemple : &NUMGTETS=WSL_NULL... Passage de paramètres système WSL_ETS : permet de donner l'établissement courant SYSTRA : transaction courante SYSAPP : application SYSORG : origine de l'appel (R : RIA, T : traitement, W : outils, ...) WSL_TRAORIG : transaction origine de l'appel WSL_DATLOG : date logique |
| Insertion de texte multi-ligne |
| Le but est de permettre d'insérer du texte multi-ligne. L'utilisation principale prévue est d'avoir une fonctionnalité équivalente aux gestions de saisie de texte. Prenons un exemple : L'insertion de texte multi-ligne dans les textes d'une commande d'achats. Pour cela, nous allons utiliser comme base l'action=callproc, avec l'appel de la procédure stockée d'insertion des textes, pssacatins. Dans un formulaire HTML, nous utiliserons donc un champ textarea (champ multi-ligne) dans lequel l'utilisateur pourra saisir ses lignes. En terme HTML, le champ texte aura comme nom TXTSACAT. Exemple : <textarea name="TXTSACAT" cols="55" rows="20"></textarea> car, lors de l'insertion de texte dans une commande, c'est bien cette zone txtsacat qui est utilisée. Pour l'instant, rien de particulier. Mais si on lance l'action telle quelle, on aura soit uniquement la première ligne saisie dans le champ texte, soit une erreur de la base de données (donnée trop longue par exemple). La nouveauté consiste à préciser, en paramètre supplémentaire de l'action callproc, le paramètre &WSL_INSTXT=xxxxx, avec xxxxx correspondant à la zone que l'on veut gérer en multi-ligne. Ici : &WSL_INSTXT=TXTSACAT En utilisant ce paramètre, on indique explicitement au noyau WIM que la zone TXTSACAT est une zone multi-ligne, et qu'il va falloir la gérer en conséquence. Dans ce cas, le noyau WIM prend le texte trouvé, le découpe en partie de 60 caractères (60 étant la valeur par défaut, mais un paramètre WSL_TXTLNG passé dans l'url permet de modifier cette valeur), et appelle autant de fois que nécessaire la procédure. |
| Lancer un traitement (action runjob) |
| Il est possible de demander l'exécution d'un traitement. Pour cela, les paramètres utilisables sont les suivants : action=runjob mnemo=mnémonique du traitement ou de l'enchaînement pjb1=nom du critère de traitement n°1 val1=valeur du critère de traitement n°1 pjb2=nom du critère de traitement n°2 val2=valeur du critère de traitement n°2 ... ... typexe=type d'exécution (E => immédiat, D, différé) [facultatif, défaut =>E] sysdate=date système, format AAAAMMJJ [facultatif] sysets=établissement système [facultatif, défaut => établissement par défaut de l'utilisateur connecté] forme=nom de requête utilisée pour la mise en forme une fois l'action lancée [facultatif] ordreok=numéro de mise en forme utilisée si le lancement du job s'est bien passé. L'utilisation du mot-clé $SERVLET_NUMJOB dans cette mise en forme permet d'afficher le numéro de job généré. [facultatif] ordreko=numéro de mise en forme utilisée si problème lors du lancement du job. Dans le cas du lancement d'enchaînements, il est possible de préciser les critères pour chaque traitement dans l'enchaînement. Le format du nom du paramètre est dans ce cas : [N° du traitement dans l'enchaînement]>[NOM_DU_PARAMETRE] Par exemple, pour préciser au runjob que pour le paramètre NUMGTETSD dans le deuxième traitement de l'enchaînement la valeur à passer est "ETS1" et que dans le paramètre NUMSACDA du quatrième traitement la valeur doit être 123456, il faut utiliser la syntaxe : action=runjob&pjb1=2>NUMGTETSD&val1=ETS1&pjb2=4>NUMSACDA&val4=123456... Attention, le numéro de préfixe doit correspondre au numéro d'ordre défini dans l'enchaînement. Par exemple, si dans l'enchaînement, les différents traitements sont numérotés de 10 en 10, et si on souhaite définir des paramètres pour le second traitement, il faudra, dans ce cas, préfixer par 20 et non par 2. |
| Lancer les traitements par étape |
| Il est parfois utile, depuis une entité gérée par étape (commande d'achats, de ventes, ordre de production, ordre de maintenance, ...), de lancer les traitements par étape (en bref, imiter le bouton "traitement" souvent présent dans les transactions gérant ces entités). L'action runjob n'est pas suffisante car un seul job peut être lancé, et le mnémonique du traitement doit être précisé. L'action "trtdyn" (traitement des enchaînements dynamiques) permet de lancer les traitements suivant l'étape de la commande ou de l'ordre. Les paramètres possibles sont : pi_ets => Obligatoire, passer l'établissement. pi_dom =>Obligatoire, passer le domaine (A pour achats, V pour ventes, ...). pi_ent => Obligatoire, passer l'entité traitée (SACDA, SVCDV, ...). pi_num => Obligatoire, passer le numéro de l'entité (numéro interne). pi_apl => Facultatif. Si renseigné, on n'exécute que le mnémonique saisi ici. Sinon, on lance les traitements "suivants normaux". pi_mincla => Facultatif. Classe de l'entité. Si non saisie, elle est recherchée. pi_minetp => Facultative. Etape courante de l'entité. Si non saisie, elle est recherchée. pi_lan => Facultatif. Langue utilisateur. pi_det => Facultatif. Destination (C : catalogue, ...). pi_exe => Facultatif. Type exécution (I pour immédiate, D pour différée). forme, ordreok, ordreko => Formes pour gérer les retours de l'action. |
| Lancer XLinks |
| Il est possible de lancer une interface XLinks via WimServlet. Pour cela, les paramètres attendus sont les suivants : - action=runqin - seq=nom_du_fichier .seq de XLinks. Ce fichier doit se trouver dans le répertoire qinForWS/scripts/ dans le contexte du serveur Web - zipin=true ou false (est-ce que le fichier de données est zippé ? false par défaut) - un paramètre de type fichier (<input type= " file "> en html) qui correspond au fichier de données que XLinks doit traiter La taille maximale (en Ko) du fichier qui peut être envoyé en upload est définie dans la globale WIMS_SMXQIN. Par défaut : 250 (250 Ko) En sortie, une page HTML contenant un lien vers le fichier de log, un lien vers le fichier d'erreur et le contenu du fichier résultat est retournée. |
| Gestion de la sécurité lors de l'utilisation des URL |
Interdire la modification d'une URL générée Afin de contrôler que l'URL appelée ne soit pas modifiée manuellement par un utilisateur peu scrupuleux, lors d'appels de procédures stockées, il est possible de mettre en place un premier niveau de sécurité, qui interdit toute modification de paramètres. L'URL restera donc telle qu'elle a été générée par le mail. Pour mettre en place cette fonctionnalité, il faut procéder de la manière suivante : - Modifier la globale MAIL_SECURL, pour mettre sa valeur à O. - Procéder de la même façon pour la globale WIMS_SECURL. Lors de l'envoi des mails, un identifiant sera automatiquement ajouté à tout appel de WimServlet qui interdira la modification des paramètres passés dans l'URL. Certains paramètres peuvent être exclus du contrôle de la sécurité. Cela peut typiquement être utile lors de l'utilisation d'un formulaire dans lequel l'utilisateur peut saisir. En effet, dans un tel cas, à la moindre saisie utilisateur, le paramètre passé sera différent de celui d'origine. En utilisant le paramètre W_NOSEC=nom-du-parametre à ne pas contrôler, on peut exclure ledit paramètre du contrôle sécurité. Par exemple, on a l'URL suivante : http://..../com.qualiac.tus.WimServlet?action=callproc&proc=psgtetsext&NUMGTETS=IFR qui est définie dans un formulaire, sur lequel il existe un paramètre (zone de saisie qui se nomme $MNEGTETS). Si on laisse tel quel, si l'utilisateur rentre une information dans la zone de saisie, une erreur de sécurité ("modification d'url interdite") s'affichera. Pour éviter cela, on peut ajouter &W_NOSEC=$MNEGTETS. Dans ce cas, on contrôlera que la partie "action=callproc&proc=psgtetsext&NUMGTETS=IFR" est inchangée, mais l'utilisateur pourra saisir ce qu'il veut dans sa zone de formulaire. Utilisation de la sécurité Pour que la sécurité soit prise en compte (contrôle des droits sur les transactions), il faut que la globale WIMS_SECTRA ait pour valeur O. De plus, différents paramètres doivent être ajoutés à l'URL : WSL_ETS => correspond à l'établissement utilisé pour le contrôle WSL_TRA => correspond à la transaction à contrôler. En combinant ces deux formes de sécurité, il est possible de contrôler les actions faites par les utilisateurs et ainsi éviter certaines manipulations interdites. |
| Enchaîner plusieurs actions |
| Il est possible d'enchaîner plusieurs actions (nombre en théorie illimité, mais qui doit forcément être raisonnable en pratique !). Un paramètre spécial permet de préciser comment le programme doit réagir si une procédure renvoie une erreur (continuer, arrêter ?). Exemple : appeler une procédure, puis une autre procédure, puis une sous requête. .WimServlet ?action=callproc // Première action, comme d'habitude &proc=psxxxxx &PARAMxxx=yyy &2_action=callproc // pour la seconde action, préfixer tous les paramètres par "2_" &2_proc=psyyyyt &2_PARAM=zzz &3_action=select // pour la troisième action, préfixer tous les paramètres par "3_" &3_rep=c:/temp &3_requete=NOMREQ Remarques : 1) Par défaut, si la première procédure renvoie une erreur, les actions qui suivent l'appel de cette procédure ne seront pas lancées. Si toutefois, vous souhaitez forcer l'exécution des actions suivantes, il faut utiliser le paramètre "cae" (continuer après erreur). Par exemple, même si l'appel de la première procédure renvoie une erreur, continuer => ?action=callproc &proc=psxxxxx &PARAMxxx=yyy &cae=O // Continuer , même si erreur &2_action=callproc // pour la seconde action, préfixer tous les paramètres par "2_" &2_proc=psyyyyt &2_PARAM=zzz &3_action=select // pour la troisième action, préfixer tous les paramètres par "3_" &3_rep=c:/temp &3_requete=NOMREQ 2) Si un paramètre (quel qu'il soit) n'est pas préfixé, il sera considéré comme commun, sauf si un même paramètre préfixé est rencontré. Exemple : ?action=callproc &proc=psxxxxx &PARAMxxx=yyy &cae=O // Commun &2_action=callproc &2_proc=psyyyyt &2_PARAM=zzz // on utilise cae=O dans ce cas (on prend le paramètre commun) &3_action=select &rep=c:/temp // l'argument rep sera commun &4_action=callproc &4_proc=psyyyyt &4_PARAM=zzz &4_cae=N // pour l'action 4, le paramètre cae est précisé. Ce sera donc celui-ci qui sera pris en compte |
| Multilangue |
| Dans le cas de WimServlet, le fonctionnement est un peu différent (voir le principe général). Lors de l'appel, on va utiliser par défaut la langue de l'utilisateur connecté (langue définie dans GUSI). Si on souhaite forcer une autre langue, il faut passer le paramètre langue (exemple &langue=FR). Remarque : Afin de ne pas trop pénaliser les performances, l'activation des traductions ne se fait que si les globales WIMS_TRAD (pour la partie WimServlet) et/ou WIM_TRAD (pour la partie WIM) ont la valeur O. |
| Autres paramètres | ||||||||||||||||
|
| Modification du mot de passe |
| L'action changepwd dans WimServlet permet de changer son mot de passe. Pour cela, il faut tout d'abord se connecter une première fois, puis lancer l'action changepwd, avec trois paramètres : newpwd => nouveau mot de passe confirmed_pwd => confirmation du nouveau mot de passe oldpwd => "ancien" mot de passe Cela modifiera le mot de passe de l'utilisateur sous lequel vous étiez connecté la première fois. |
| Accès aux fichiers résultat des jobs |
| Avec WimServlet, l'action runjob permet de lancer des traitements sur le serveur de traitements, mais le fichier résultat doit être visualisé de façon standard (Consultation de travaux, envoi par mail). Il est possible de demander à l'action runjob d'attendre que le job soit terminé, et d'afficher directement le fichier résultat à l'écran. Pour cela, des paramètres sont disponibles au niveau de runjob. Le paramètre wfr. Si valeur = "O" ou "T", on attend la fin du traitement pour afficher le résultat. Le paramètre useftp. Si valeur "O" ou "T", on utilise une commande FTP pour rechercher le fichier sur le serveur de traitement. Sinon, un accès direct vers le répertoire de spool est fait. Des variables globales entrent aussi en jeu : Dans tous les cas : WIMS_ITVOUT donne, en secondes, le temps maximal d'attente de la fin du job. Par défaut, 30 secondes. Cette variable est créée pour éviter de bloquer trop longtemps une ressource pour l'attente d'un fichier résultat. WIMS_ITVIFR donne, en seconde, l'intervalle utilisé pour vérifier que le job est terminé (défaut = 5 secondes). Si positionné à 3, le noyau WIM vérifie toutes les 3 secondes si le job est terminé. Ensuite selon les cas suivants : A) Si le serveur de traitement du job peut être accédé via http (zone "port" renseignée dans GSRV), il n'y a rien de particulier à configurer. Le système est autonome et le fichier résultat sera lu et mis à disposition sans autre configuration. B) Si le répertoire de spool contenant le fichier résultat, sur le serveur de traitement, est visible directement par le serveur Web, une copie directe peut être faite. Pour activer cela, il faut préciser au système que cela est possible en positionnant la globale WIMS_JLOCAL avec la valeur T. C) Si le répertoire de spool contenant le fichier résultat, sur le serveur de traitement, n'est pas visible directement par le serveur Web, il faut indiquer au système de lancer une récupération FTP. Pour cela, préciser dans l'url l'option &useftp=T. De plus, les globales WIMS_JSRV (serveur de traitement), WIMS_FTPUSR (utilisateur ftp) et WIMS_FTPPWD (mot de passe pour le user ftp) doivent être positionnées. Il est aussi nécessaire de configurer la façon dont est lancée la commande FTP, dans GGLO : Si WIMS_FTPNJ (ftp "non java") a la valeur "O" (pour Oui, valeur conseillée), ce sera une commande ftp native sur le serveur qui sera lancée. Dans ce cas, il faut aussi préciser : WIMS_CMD (type de fichier de commande) : cmd /c pour windows, sh pour unix D) Si le répertoire de spool contenant le fichier résultat, sur le serveur de traitement, peut être accédé via un partage directement par les postes clients, il faut positionner la globale WIMS_JPATH, qui doit correspondre au chemin UNC permettant d'accéder au répertoire des pool. Un dernier paramètre qu'il est possible de passer dans l'url est le paramètre ordreto (ordre pour Time Out). Nous connaissions déjà les paramètres ordreok et ordreko. Ici, il s'agit de préciser quel est le "message" affiché dans le navigateur si le job dépasse le temps maximal autorisé pour se terminer. Dans cette mise en forme, il est toujours possible d'utiliser l'alias $SERVLET_NUMJOB. On peut donc facilement personnaliser l'écran. Le paramètre showfile (par défaut O) permet, en positionnant sa valeur à N, de renvoyer le nom du fichier résultat (avec chemin complet), mais n'affiche pas le contenu de ce dernier. En complément, l'action "getfileresult" de WimServlet attend en entrée un numéro de job, et permet de récupérer le fichier résultat de ce job. Cette action peut donc être fortement couplée avec l'action runjob. Les paramètres attendus sont : &numjob => numéro du job &forme, &ordreok , &ordreko => pour personnalisation, selon un principe désormais classique dans WimServlet. &show => si vaut "O" ou "T", le fichier résultat est directement affiché. Sinon, c'est un lien vers ce fichier qui est envoyé. Dans le cas où show ne vaut ni "O", ni "T", on affiche une page dont le contenu est paramétré grâce à la valeur précisée dans le numéro de mise en forme ordreok. Dans cette mise en forme, l'alias $SERVLET_AFFJOB permet quant à lui de préciser où est affiché le lien vers le fichier résultat. On peut donc, (entre autre), utiliser cette action getfileresult dans le ordreok d'un runjob classique (sans attente du fichier résultat), et/ou dans le ordreto d'un runjob. |
| Accès aux documents de GTIDOC |
| Le principe est de fournir une fonctionnalité WimServlet générique qui permette de visualiser par un lien URL, n'importe quel document de GTIDOC (par exemple une URL dans laquelle on passe en paramètre un numéro de commande, et qui retourne le fichier au format PDF du bon de commande). Les différentes problématiques sont : 1) La sécurité : via Cegid XRP Ultimate, si l'utilisateur connecté n'arrive pas à voir un enregistrement (du à la confidentialité, pré-paramétrage de critères de sélection, droits sur transaction, paramétrages divers, etc.), il ne peut de ce fait pas voir le ou les document(s) associé(s). Avec WimServlet, le ou les critère(s) permettant de rechercher le document devront forcément être passés en paramètre dans l'URL, de même que les critères qui vont être nécessaires aux contrôles. Il faut donc pouvoir contrôler que la personne connectée a bien le droit de demander et donc de voir tel ou tel document associé à telle entité. Pour cela, et comme il n'est pas possible d'intégrer ce contrôle directement dans le programme, on peut paramétrer ce contrôle. 2) L'accès aux documents : les documents peuvent être stockés sur des machines non accessibles directement par l'utilisateur. Un transfert sur le serveur Web sera donc nécessaire dans ce cas. Ceci implique que le serveur Web ait bien accès au serveur de document, et qu'un transfert de type ftp soit possible. Le code de l'action WimServlet pour appeler la fonctionnalité de visualisation des documents sera : getdoc. action=getdoc Paramètre complémentaire : &typaff (par défaut, vaut "direct". Si valeur est différente de "direct", on affiche un lien vers le fichier, et on ne tente pas d'afficher directement le fichier. Contrôles pour visualisation La variable globale (GGLO) WIMS_DOCCTL positionnée à O ou T permet l'application d'un premier niveau de contrôle avant d'aller rechercher le fichier pour le présenter à l'utilisateur. Le contrôle se fait soit par l'exécution d'une requête, soit par l'appel d'une procédure (de façon exclusive). Contrôle via une requête La requête doit être référencée dans GTUREQ. Les mises en forme et autres fonctionnalités (JLR) ne seront pas appliquées, seul l'aspect SQL est ici exploité. Il est possible de passer des paramètres à cette requête, et les symboles seront interprétés si besoin (selon le même principe que l'action "sousel" déjà existante). La requête peut porter sur des tables gérant la confidentialité (dans ce cas, il suffira de préciser les vues concernées). Si l'exécution de la requête ramène un ou plusieurs enregistrement(s) (si le texte de retour, mise en forme, n'est pas vide), on considère alors que l'accès au document peut se faire. Sinon, on retourne une erreur. Les paramètres à passer seront les suivants : &selctl => Nom de la requête Wim à lancer &$XXXX...=> XXXX... étant les paramètres éventuels à passer à la requête Paramètres facultatifs : &forme => nom de la requête pour mise en forme du retour &ordrectlerr => le sql de contrôle en erreur technique (mauvais codage sql par exemple, cas qui ne devrait pas arriver) &ordrectlko => la requête de contrôle n'a rien ramené (donc pas le droit de visualiser le document) Exemple : on peut créer une requête simple, avec le texte "OK" dans la mise en forme qui en entrée prend un numéro de facture, et vérifier que l'utilisateur connecté (via le symbole $USER) est bien le gestionnaire de la facture. Si oui, la requête ramène un enregistrement (le texte "OK" est retourné) (les colonnes ramenées n'ont aucun intérêt), sinon la requête renvoie zéro enregistrement (donc mise en forme vide). Contrôle via une procédure stockée La procédure doit posséder une correspondance dans les classes java (fichier qualiacproc.jar). Si l'exécution de la procédure ne renvoie pas d'erreur, on considère alors que l'accès au document peut se faire. Sinon, on retourne une erreur. Selon le paramétrage (propriétés de l'utilisateur connecté), et si la procédure utilisée est capable de gérer cette notion (ce qui est le cas d'une très grande majorité des procédures de contrôle d'existence), on tiendra compte de la confidentialité lors de l'exécution de la procédure Les paramètres à passer seront les suivants : &procctl => Nom de la procédure stockée à lancer &XXXX... => XXXX... étant les paramètres éventuels à passer à la procédure Paramètres facultatifs : &forme => nom de la requête pour mise en forme du retour &ordrectlko => la procédure de contrôle ne donne pas le droit de visualiser le document Cette option peut permettre de gérer les cas les plus complexes par l'utilisation de procédure déjà existante ou de procédures développées spécifiquement. Si WIMS_DOCCTL vaut O ou T, il faut impérativement trouver soit le paramètre selctl, soit procctl, sinon erreur Second niveau de contrôle : application des droits par transaction (sécurité) La variable globale (GGLO) WIMS_DOCTRA positionnée à O out T permet l'application d'un second niveau (indépendant du premier niveau selon requête ou procédure) de contrôle avant d'aller rechercher le fichier pour le présenter à l'utilisateur. Ce contrôle ne pourra être effectif que si la sécurité des droits par transaction est en place. Dans ce cas, le paramètre &WSL_TRA devra impérativement être passé, et aura pour valeur une transaction (GTRA). On contrôle alors que l'utilisateur connecté a bien droit à la transaction passée comme valeur dans ce paramètre. Si ce n'est pas le cas, on retourne une erreur. Les deux niveaux de contrôles (par requête ou procédure, ou selon la sécurité) pourront être faits de façon indépendante. Accès aux documents Pour accéder aux documents, certaines informations en entrée doivent être passées de façon impérative. Il faudra donc préciser l'entité de GTDEN, le type de GTDTY, le ou les paramètre(s) nécessaire(s) à l'identification du document dans GTDEN. Les paramètres seront : &doc_gtden => entité &doc_gtdty=> type &p01 => paramètre 1 pour identifier &p02 => paramètre 2 ... ... &p10 &$XXXXX, avec XXXX correspondant à une variable présente dans GTDTY. Exemple si le chemin dans GTDTY est /tmp/$NUMGTETS/$P01/, on pourra passer &$NUMGTETS Paramètre complémentaire : &forme => requête pour mise en forme de retour, &ordrevide => texte affiché si aucun document n'a été trouvé. Ensuite, nous appliquons les règles normales pour rechercher le document : Si le document n'est pas centralisé, un accès direct au fichier est donc possible depuis le navigateur. On affichera donc le fichier directement. Attention : sous firefox par exemple, il est impossible, dans une page servie via du http (ce qui est donc le cas avec WimServlet), de faire un changement de protocole et de servir du "file:". Le mode "non centralisé" a donc peut de chance de fonctionner sous firefox (il existe un plugin "locallink" qui peut aider). Si le document est centralisé : seul le nom est connu dans GTIDOC, le chemin pour y accéder est défini dans GTDTY. trois cas se présentent alors. (Dans GTDTY, les informations qui intéressent WimServlet se trouvent dans la partie "WEB"). Cas 1) Si l'architecture le permet, possibilité de passer par le serveur http installé sur le serveur de traitements (serveur qui permet entre autre de visualiser les fichiers résultat de job dans l'interface utilisateur Cegid XRP Ultimate) pour récupérer les fichiers via l'action getdoc. Pour cela, positionner la globale WIMS_DOCHTTP avec la valeur true. Le serveur pris en compte sera le serveur défini par défaut dans GSRV. Cas 2) Dans GTDTY, rien n'est précisé au niveau des zones "FTP", une copie est faite sur le serveur Web, puis on pointe sur cette copie. Cas 3) Les informations pour un accès FTP sont saisies : Les transferts via ftp se font selon le même paramétrage que la visualisation des jobs. Dans GGLO, mettre WIMS_FTPNJ, valeur O. Le fichier est rapatrié sur le serveur Web via ftp, et on pointe sur ce fichier. Dans les cas 2 et 3, il est de toute façon nécessaire de mettre en place le paramétrage suivant : - Globale WIMS_DOCPATH, qui donne le répertoire temporaire (sans / ou \ final), sur le serveur Web, où seront stockés les fichiers transférés (ce répertoire doit être visible dans le contexte du serveur Web). De préférence, que ce répertoire soit dans un monde Linux/Unix ou Windows, saisir des / au lieu de \). - Globale WIMS_DOCURL, qui donne l'URL pointant sur le répertoire WIMS_DOCPATH A noter : Dans certains cas (et notamment le cas de serveurs en "load balancing", mais pas uniquement), cette configuration des globales WIMS_DOCPATH et WIMS_DOCURL peut s'avérer délicate à gérer, car elles peuvent faire référence à des chemins précis sur des serveurs. Pour s'affranchir de ces contrainte, on peut positionner la globale WIMS_LOADBAL avec la valeur TRUE. Dans ce cas, les fichiers seront stockés automatiquement dans le répertoire spl interne au serveur Web, et les valeurs de WIMS_DOCPATH et WIMS_DOCURL ne seront pas prise en compte. Points complémentaires : Comme dans les actions select, callproc..., il est possible de paramétrer la mise en forme en cas d'erreur (selon les paramètres ordrectlerr, ordrectlko, forme habituels). Afin de ne pas trop dégrader les performances, un système de cache peut être mis en place par défaut : si un même fichier est demandé plusieurs fois, la "copie" (au sens large) ne sera pas effectuée à nouveau. Un système de correspondance permet de retrouver le fichier déjà présent sur le serveur Web. Cette fonctionnalité peut être désactivée en utilisant une globale (WIMS_DOCPERS => non persistant). Cela peut s'avérer utile si les fichiers évoluent souvent et pour rester en phase. 1) Dans l'action reload avec le paramètre rset sans valeur (...?action=reload&rset), on supprime les persistances (en mémoire et fichiers : on supprime tous les fichiers présents dans le répertoire WIMS_DOCPATH). 2) Un paramètre facultatif à l'action=getdoc (paramètre &nopers, sans valeur) permettra de forcer la "non persistance", donc de forcer une actualisation du ou des documents demandés). 3) Les fichiers sont stockés dans le répertoire temporaire (défini par WIMS_DOCPATH) sans conservation du nom d'origine, mais avec un nom totalement aléatoire (numéro de session java (32 caractères) + un chiffre aléatoire sur 16 positions). Donc, en interdisant le parcours http du répertoire temporaire (WIMS_DOCURL), il devient (quasi) impossible d'accéder à un fichier dont on ne connait pas le nom. Important : Si plusieurs documents sont trouvés pour un même index, une page contenant les liens vers les x fichiers sera retournée. Remarque : comme toutes les actions WimServlet, cette action getdoc sera disponible via appel depuis le Web Service générique Qualiac. Le retour sera la chaîne de caractère représentant l'URL d'accès au fichier. Retrouver plusieurs types de document Il est possible, lors de l'action getdoc de rechercher des documents provenant de la GED pour plusieurs types de document. Pour cela, les spécifier dans la valeur du paramètre de traitement doc_gtdty en les séparant par une virgule. Pour définir dans quel ordre les documents seront affichés, il faut préciser dans le paramètre doc_ptr un critère de tri provenant de GPTRV. Exemples Exemple 1 : Appel avec contrôle via un select, pour récupérer la facture au format PDF associée à la facture n° 1234. Le select contrôle que l'utilisateur connecté soit bien gestionnaire de la facture 1234. Ce code sql est stocké dans la requête CTL_FAA, qui attend en paramètre le numéro de facture et l'établissement. Dans GTDEN, le numéro de facture et l'établissement sont nécessaires pour récupérer le document. De plus, la sécurité est activée, on veut donc en plus contrôler que l'utilisateur connecté à droit au mnémonique GFAA01. ...WimServlet?action=getdoc&selctl=CTL_FAA&$NUMSAFAA=1234&$ETSSAFAA=ETS&doc_gtden=FACTURE&doc_gtdty=ACHATS&p01=1234&p02=ETS&WSL_TRA=GFAA01 Exemple 2 : idem exemple, avec contrôle via procédure stockée qui vérifie que l'utilisateur connecté peut bien voir l'établissement ETS, car la confidentialité est active. ...WimServlet?action=getdoc&procctl=psgtetsext&NUMGTETS=ETS&doc_gtden=FACTURE &doc_gtdty=ACHATS&p01=1234&p02=ETS&WSL_TRA=GFAA01 Récapitulatif des paramètres possibles: action=getdoc &doc_gtden=entité de GTDEN &doc_gtdty=type de document de GTDTY &nopers=T (si on ne veut pas, sur cette action, utiliser le mécanisme de persistance. Ne pas passer ce paramètre dans les autres cas). &typaff=I (affichage indirect du document : un lien est proposé. Ne pas passer ce paramètre dans les autres cas). &p01=valeur du premier paramètre défini dans GTDEN ... &p10=valeur du dixième paramètre défini dans GTDEN (ne pas passer si non renseignés) &$XXXXX=valeur, avec XXXXX = un nom du paramètre de GTDEN &forme=nom d'une requête de GTUREQ pour mise en forme (retour) &selctl=nom d'une requête GTUREQ &$xxx =paramètres à passer à la requête (même principe que pour l'appel d'une action=select) &forme=nom d'une requête (pour mise en forme en cas d'erreur) &ordrevide=N° d'ordre de requête pour mise en forme, utilisé dans le cas où aucun document associé n'a été trouvé &ordrectlerr=N° d'ordre de requête pour mise en forme, utilisé dans le cas où la requête de contrôle sort en erreur technique (mauvais sql) &ordrectlko= n° d'ordre de requête pour mise en forme, utilisé dans le cas où la requête de contrôle ne ramène rien (contrôle "négatif") &procctl=nom d'une procédure stockée &...=> paramètres identiques à une action=callproc &forme et &ordrectlko : même principe que vu plus haut. &WSL_TRA=nom d'un GTRA (dans le cas où on souhaite appliquer un contrôle de l'utilisateur connecté pour savoir s'il possède les droits sur la transaction précisée ici). |
| Appel d'un programme externe |
| L'action "callexternal" permet de faire appel à un programme externe. Ce programme sera alors vu comme une "boîte noire", qui aura accès aux informations nécessaires (connexion base de données, utilisateur, paramètres passés dans l'URL, etc.). Cette "boîte noire" exécutera alors son code interne, et affichera le résultat programmé. Les paramètres pour cette action sont donc : &callexternal=Nom de la classe java à utiliser &qpackname=Nom du package Cegid à utiliser (facultatif). &packname=Nom du package "client" à utiliser (ce dernier étant prioritaire). Les pré-requis techniques sont les suivants : - développement en langage Java - la classe java appelée doit dériver de com.qualiac.tus.ExternalAction Pour plus d'informations sur ce thème très technique, contacter le support Cegid. |
| Jeton d'identification |
| Cette fonctionnalité n'est a priori intéressante que dans le cas d'une intégration d'appel WimServlet dans un système plus large (outils de portail par exemple, afin de récupérer un jeton d'authentification par programmation, et de faire un appel "utile" sans passer de mot de passe en clair dans une URL). Le principe est le suivant : un premier appel WimServlet passe un couple de paramètre utilisateur/mot de passe. En retour (si le couple est correct), un jeton est retourné (combinaison alphanumérique sur plus de 40 positions). L'appel se fait en passant l'action=gettoken, avec comme paramètre "login" et "password". Ensuite, un second appel WimServlet peut alors être réalisé. Cet appel sera un appel classique (action callproc ,select, runjob ...). Il suffit juste d'ajouter le paramètre &logon_token=[la valeur récupérée dans l'appel] pour que l'authentification soit réalisée de façon automatique. Remarque : Le jeton n'est utilisable qu'une seule fois et n'est donc pas à nouveau utilisable. |
| Outils |
| Liste des globales utilisables |
Accès aux variables globales pour WIM. |
| Divers |
| Personnaliser la boîte de connexion |
| Dans WIM, certaines "pages" sont fournies en standard, mais ne correspondent pas forcément avec ce que l'on souhaite intégrer (charte graphique, messages personnalisés lors des retours sur les appels de procédures, ...). Pour que chacun puisse adapter WIM à son environnement graphique, il est possible de personnaliser la boîte de connexion. Pour cela, il est conseillé de créer une requête qui n'aura aucune fonctionnalité au sens "WIM" du terme, mais dont le but est de stocker les différentes mises en forme personnalisées (donc, il n'est pas nécessaire de définir un ordre SQL, des systématisations, ...). Par exemple, créer une requête PERSO_FORME. Ensuite, créer une mise en forme (dans GTUFRM), pour un n° d'ordre 10. Dans le texte de cette mise en forme, saisissez votre personnalisation de boîte de connexion. Un exemple :  Notez le mot-clé $ Une fois cette mise en forme définie, il faudra, dans GGLO, renseigner la globale WIMS_CNXBOX avec la valeur PERSO_FORME, et la globale WIMS_ORDCB avec la valeur 10. Enfin, il est tout à fait cohérent d'utiliser la requête PERSO_FORME pour stocker d'autres personnalisations (retour d'appel de procédure, ...). Il est aussi possible de pré-positionner le code utilisateur dans la zone de saisie. En effet, lors d'un appel à WimServlet, on peut passer le paramètre user (exemple &login=GTI). Si on utilise le mot-clé $USER (comme dans l'exemple ci-dessus) dans la personnalisation de la boîte de connexion, ce mot-clé sera alors remplacé par la valeur du paramètre &user passé. Alternative à l'utilisation du mot-clé $ L'alias $ Cela peut poser des problèmes, si les paramètres sont nombreux et/ou très longs, car la taille d'une url est limitée par les navigateurs. L'alias, $INPQUERY peut être une alternative à $ De cette façon, les paramètres et les valeurs ne sont plus passés en tant que chaîne de caractères, mais transitent directement dans l'en-tête http, ce qui supprime le problème de taille d'url. Si les deux alias $ Personnaliser la boîte de connexion suite à un échec d'authentification Par défaut, si une erreur se produit lors de la connexion, on affiche un message d'erreur assez technique puis, en dessous, la boîte de connexion. Il est possible de personnaliser ce qui va être affiché lors de ce type d'erreur. Pour cela, on utilise une mise en forme définie par WIMS_CNXBOX. On prendra ensuite la mise en forme de numéro WIMS_ORDCBER. Dans cette mise en forme, le mot-clé $ERREUR sera remplacé par l'erreur retournée. |
| Action sur la pièce jointe. Exemple : Conversion HTML => PDF (outil externe) |
| Les fichiers générés lors d'un envoi de mail via WIM sont le plus souvent au format HTML. Il est possible de faire appel à un outil externe pour agir sur le fichier généré. L'utilisation la plus classique étant l'application d'un convertisseur externe à Cegid XRP Ultimate pour transformer le fichier html en fichier pdf et de l'inclure dans le mail. Pour cela, plusieurs conditions précises doivent être remplies : - L'outil de conversion (non fourni par Cegid, voir par exemple l'outil HTMLDOC http://www.easysw.com/htmldoc/ ) doit être correctement installé sur le serveur de traitement. - L'outil doit être appelable en ligne de commande, et ne doit pas attendre de réponse, ni poser de question. Paramétrage : - Renseigner, dans GGLO, la valeur de la globale MAIL_CMD, qui précise le type de commande selon l'OS utilisé sur le serveur de traitement. Si vous êtes sous Unix ou Linux, saisir sh, si vous êtes dans un environnement Windows, saisir cmd /c - Dans GGLO, pour la variable MAIL_TRTFIC, renseigner la ligne de commande qui doit être lancée, sans les fichiers origine ni destination. Si des options particulières doivent être appliquées selon certains cas (pour tel mail, avoir un format portrait, pour tel autre, avoir un format paysage, ...), il est possible d'inclure, dans la ligne de commande, le symbole $WIM_OPT qui servira d'alias et sera remplacé selon les cas. - Pour que l'option de conversion soit lancée, il faudra trouver, dans la mise en forme du mail, la balise spécifique !WIM_CONVERT!. (dans ce cas, le fichier HTML origine ET le fichier PDF seront joints), ou la balise !WIM_CONVERT_ONLY! (dans ce cas, seul le fichier PDF sera joint. - Dans la mise en forme du mail, la balise !WPDF=zzzz WPDF! (qui s'utilise comme la balise WFN et WFX) permet de renommer le fichier PDF joint, pour donner un nom plus explicite. - Dans la mise en forme du mail, la balise !WOPT=xxxxxxx WOPT! permet de passer des options supplémentaires à la ligne de commande lançant la conversion (voir le symbole $WIM_OPT). Exemple : L'outil de conversion est installé correctement sur le serveur de traitement. Celui-ci se lance en ligne de commande avec la syntaxe suivante : Convert.exe -left 1cm -top 2cm test.pdf test.html -left et -top étant deux options, test.pdf devant être le résultat, et test.html le fichier à convertir. Pour pouvoir utiliser cet outil dans WIM, il faudra donc : - Dans GGLO, pour MAIL_TRTFIC, saisir : Convert.exe -left 1cm -top 2cm - Dans la mise en forme du mail, mettre !WIM_CONVERT! Si, pour la requête 1, la conversion doit être faite en portrait, et pour la requête 2, on souhaite une conversion en paysage, il faudra avoir : - Dans GGLO, pour MAIL_TRTFIC, saisir : Convert.exe -left 1cm -top 2cm $WIM_OPT - Dans la mise en forme de la requête 1 et 2, mettre !WIM_CONVERT! - Dans la mise en forme de la requête 1, il faut trouver : !WOPT= --portrait WOPT!, et dans la mise en forme de la requête 2, saisir !WOPT= --landscape WOPT! Remarque : les options (portrait, landscape, ...) sont données ici à titre d'exemple afin d'expliquer le principe. A adapter selon l'outil utilisé. |
| Mode trace SQL (uniquement sous Oracle) |
| Il est possible d'activer la trace SQL (sous Oracle uniquement). Pour WimServlet - Positionner la variable globale WIMS_SQLTRC avec la valeur TRUE, ou positionner "connexion.sqltrc=TRUE" dans le fichier "properties". Toutes les connexions WimServlet seront alors en mode trace SQL. - Ou passer le paramètre "sqltrc=TRUE" dans l'URL d'appel. Dans ce cas, seul l'accès WimServlet concerné sera en mode trace. Sur le serveur de traitements Lancer le traitement avec le mode d'exécution à "T", ou positionner WIM_DEBUG à "T". |
| Génération de graphiques |
| Introduction |
| Un outil permet de générer des graphiques de façon la plus générique et ouverte possible. Pour cela, on utilise, pour transporter les données, le format XML. On attend du code xml en entrée. Ce code, comme tout xml, doit respecter une structure. De façon générale, il doit contenir, façon obligatoire : - La balise racine <chart> - La balise <chart_type>, qui peut prendre 8 valeurs : PIE, LINE, AREA, BAR , PIE3D, LINE3D, AREA3D, BAR3D - La balise <chart_data>, qui annonce le début du tableau, puis les balises <row> et <string> ou <number> De façon optionnelle : - <img_width>, pour la largeur de l'image - <img_height>, pour la hauteur - <img_bgcolor>, pour la couleur de fond (format #0000FF par exemple) - <chart_title>, pour préciser le titre du graphique - <labelx>, intitulé de l'axe des x - <labely>, intitulé de l'axe des y - <orientationplot>, par défaut vertical, qui donne l'orientation du graphique - <data_x_orientation>, par défaut vertical, qui précise l'orientation des abscisses dans le tableau des données. |
| Graphique PIE (ou "camembert") |
Imaginons un tableau représentant la consommation d'un produit dans certains pays. L'équivalent XML est : <chart> <chart_type>PIE3D</chart_type> <chart_title>Consommation du produit </chart_title> <data_x_orientation>vertical</data_x_orientation> <img_width>500</img_width> <img_height>400</img_height> <chart_data> <row> <string>Etats-Unis</string> <number>10</number> </row> <row> <string>France</string> <number>123</number> </row> <row> <string>Espagne</string> <number>32</number> </row> <row> <string>Australie</string> <number>5</number> </row> </chart_data> </chart> Si le tableau se présentait ainsi :  Pour représenter ces données dans le format XML souhaité, voici ce que l'on doit avoir : <chart> |
Dans les deux cas, le graphique généré sera : |
| Graphique COURBE, BAR ou AREA |
Imaginons un tableau représentant l'évolution des ventes de produit1, de produit2 et de produit3 sur les 5 dernières années : Le xml sera : <chart> <chart_type>LINE3D</chart_type> <chart_title>Evolution des ventes </chart_title> <chart_data> <row> <null /> <string>2003</string> <string>2004</string> <string>2005</string> <string>2006</string> <string>2007</string> </row> <row> <string>Produit1</string> <number>123 </number> <number>115</number> <number>131</number> <number>132</number> <number>140</number> </row> <row> <string> Produit2</string> <number>89</number> <number>97</number> <number>112</number> <number>105</number> <number>119</number> </row> <row> <string> Produit3</string> <number>34</number> <number>30</number> <number>41</number> <number>46</number> <number>51</number> </row> </chart_data> </chart> Si le tableau était ainsi :  Le xml serait : <chart> <chart_type>LINE3D</chart_type> <chart_title>Evolution des ventes </chart_title> <data_x_orientation>vertical</data_x_orientation> <chart_data> <row> <null /> <string>Produit1</string> <string>Produit2</string> <string>Produit3</string> </row> <row> <string>2003</string> <number>123</number> <number>89</number> <number>34</number> </row> <row> <string>2004</string> <number>115</number> <number>97</number> <number>30</number> </row> <row> <string>2005</string> <number>131</number> <number>112</number> <number>41</number> </row> <row> <string>2006</string> <number>132</number> <number>105</number> <number>46</number> </row> <row> <string>2007</string> <number>140</number> <number>119</number> <number>51</number> </row> </chart_data></chart> Résultat, dans les deux cas :  |
| Graphique GANTT |
Les données doivent se présenter sous la forme suivante : Les dates doivent être au format AAAAMMDD. On peut aussi préciser des heures (format AAAAMMDDHHMM). Le nombre de séries n'est pas limité (au moins une).  Le XML équivalent sera : <chart> <chart_type>GANTT</chart_type> <chart_title>GANTT</chart_title> <data_x_orientation>vertical</data_x_orientation> <img_width>500</img_width> <img_height>400</img_height> <chart_data> <row> <null/> <string>Prévu</string> <string>Réalisé</string> </row> <row> <string>Tache 1</string> <string>20070101</string> <string>20070131</string> <string>20070103</string> <string>20070129</string> </row> <row> <string>Tache 2</string> <string>20070305</string> <string>20070330</string> <string>20070308</string> <string>20070415</string> </row> <row> <string>Tache 3</string> <string>20070601</string> <string>20070608</string> <string>20070603</string> <string>20070608</string> </row> <row> <string>Tache 4</string> <string>20070501</string> <string>20070530</string> <string>20070503</string> <string>20070529</string> </row> <row> <string>Tache 5</string> <string>20070917</string> <string>20070930</string> <string>20070910</string> <string>20070922</string> </row> </chart_data> </chart> |
Résultat : |
| Appel de la génération de graphiques dans WIM |
| Dans WIM, toute sous requête dont la mise en forme commence par la balise !WIM_DRAWGRAPH! est interprétée comme une requête "graphique", c'est-à-dire que la mise en forme est considérée comme du code xml à transformer en graphique. La requête ne retourne pas à l'utilisateur sa mise en forme classique, mais c'est le nom de l'image (chemin complet, URL ou arborescence), ceci afin de pouvoir y accéder (typiquement via une balise <img> en HTML). Pour la partie WIM classique (envoi de mail), deux variables globales sont à positionner pour assurer le bon fonctionnement du générateur de graphique. WIM_CDIR => donne le répertoire physique dans lequel sont stockées les images générées. WIM_CURL => donne l'URL (ou le chemin disque) qui permet d'accéder à l'image générée. Important : une requête principale (requête mère) ne pourra pas être une requête graphique, ou alors cela aura une utilité assez limitée. En effet, si on appelle directement une requête graphique, celle-ci ne fait que retourner le nom de l'image générée. |