Résumé : Ce document présente le service d’automatisation pct, outil servant à gérer automatiquement les tâches de génération de pdf et alimenter une base de données Oracle à partir des fichiers dgn et à exporter les pdf produits sur le nas de grtgaz

Outil automatisation PCT Résumé : Ce document présente le service d’automatisation PCT, outil servant à gérer automatiquement les tâches de génération de PDF et alimenter une base de données Oracle à partir des fichiers DGN et à exporter les PDF produits sur le NAS de GRTgaz. Rédaction Vérification Approbation Fonction Stagiaire GRTGaz POA SIG Mobile Nom Charron Maxime Romuald Beduchaud Date 15/05/2012 15/05/2012 Diffusion Nom Fonction Structure SOMMAIRE 1.DESCRIPTION DE L’OUTIL 3 2.PRÉREQUIS 3 3.UTILISATION DU LOGICIEL 3 4.LES DIFFÉRENTS ENVIRONNEMENTS UTILISÉS 5 DESCRIPTION DE L’OUTIL Cet outil permet d’automatiser la chaine de traitement des fichiers DGN, qui, part un module nommé FME, sont ajoutés à une base de données Oracle et retranscrits en PDF. Ce logiciel permet donc aussi de déplacer tous les PDF créés dans le NAS de GRTgaz afin d’être accessible depuis le réseau et sur les tablettes/PC des techniciens qui iront sur le terrain et les modifieront en conséquences. PRÉREQUIS Pour pouvoir assurer le bon fonctionnement de ce service, il faut : Python 2.5.1 ou une version ultérieure FME Desktop 2010 SP4 Microstation 8.09.04.117 ArcGISDesktop 9.3 Client Oracle 10g UTILISATION DU LOGICIEL FONCTIONNEMENT DU LOGICIEL Ce logiciel utilise 5 scripts python différents : scriptPrincipal.py majListeDGN.py deplacementPDF.py creationListeDGNaTraiter.py creationZIP.py D’abord, le logiciel va vérifier que SewTrans a bien traité tout les dossiers en cherchant un fichier OK_IP.DU.SERVEUR dans les nbServeur répertoires (donc si il y a d’autres répertoires dans celui qui contient tous les serveurs, il faut qu’il ait un nom avec une lettre en premier caractère, car les chiffres passent avant les lettres. Il na passera donc pas dans celui-ci car il sera en position nbServeur+1 au minimum.). Si chaque dossier est complet, il envoie le premier script, sinon, il attend que SewTrans ait fini sa tâche. Ensuite, il va créer une liste au format texte contenant tous les DGN du dossier du serveur courant, récupérer les 2 premières lignes, les envoyer en paramètre à FME, puis, une fois le traitement FME terminé, va déplacer les PDF créés par FME dans le dossier général des PDF afin d’être accessible partout. Enfin il va zipper tous les logs dans un dossier nommé « date-du-jour_TraitementPCT.zip », puis supprimer tous les logs du dossier une fois le zip créé. Si d’autres zip sont dans le dossier de logs, le script creationZIP.py va vérifier la date de création de ceux-ci, et si elle est supérieure à 90 jours, il les supprimera. Il va réitérer sa tâche pour tous les serveurs. SE SERVIR DU LOGICIEL Pour se servir du logiciel, il faut lancer le script nommé scriptPrincipal.py. PARAMETRES DES SCRIPTS scriptPrincipal.py : nbServeurs : le nombre de serveurs contenant les DGN. chemin : le chemin absolu pointant vers le dossier contenant les sous-dossiers ayant pour nom une IP de serveur. ip[i] : le nom du serveur d’index i cheminDeplacementPDF : variable pointant sur le dossier général contenant tous les PDF de tous les serveurs cheminPartiel : chemin absolu pointant sur le dossier du serveur courant (d’index i) cheminComplet : chemin absolu pointant vers le dossier contenant les DGN du serveur fichier : variable ciblant le fichier OK_XXX.XXX.XXX.XXX (indiquant que SewTrans a fini son traitement) cheminQuiCrashent : variable contenant le path vers le répertoire des DGN ayant une taille inferieure à tailleFichierMin, car ceux-ci font crasher FME. log : variable utilisée pour écrire dans le fichier FME.LOG logTraite : variable utilisée pour écrire dans le fichier DGNliste.LOG (contenant les actions entreprise sur les DGN) dateDebut / dateFin : variables utilisées afin de calculer le temps mis par FME pour traiter un fichier DGN listeDGNaTraiter : variable utilisée afin de lire le contenu du fichier listeDGNaTraiter.txt userSDE : variable contenant l’user nécessaire à la connexion à la géodatabase voulue. passwordSDE : password associé à l’user_SDE. instanceSDE : Chaine de connexion à la géodatabase Oracle voulue. logDGNTraite : variable contenant le nom du fichier de logDGNTraite.log logGeneral : variable contenant le nom du fichier logGeneral.log debug : variable booléenne indiquant si le script sera lancé en mode « debug » (mode interne au script, non pas le débug de python) et donc écrira beaucoup plus de choses dans les logs ou non. tailleFichier : idem que debug, indique si le script vérifiera si le DGN a une taille inferieure à tailleFichierMin. tailleFichierMin : variable contenant la taille minimale pour un DGN. nomRepertoireDGNTailleRejete : variable contenant le path vers le dossier DGN_taille_rejete nbJours : nombre de jours maximum pour garder un zip de logs. nomZIP : variable contenant le nom du zip des logs. majListeDGN.py : log : variable indiquant l’ouverture en ajout du fichier de log logDGNTraite.log. deplacementPDF.py : log : variable indiquant l’ouverture en ajout du fichier de log deplacementPDF.log. creationListeDGNaTraiter.py : dgn : variable indiquant le nom du fichier contenant la liste des DGN a traiter par FME (qui est mis a jour au fur et à mesure des traitements FME) destination : variable ouvrant le fichier contenant la liste des DGN a traiter en écriture resultat : variable ouvrant le fichier contenant la liste des DGN a traiter en lecture log : idem que logTraite dans scriptPrincipal.py source : variable ouvrant la liste des DGN contenu dans le dossier DGN en lecture EXPLICATIONS APPROFONDIES DU FONCTIONNEMENT DU LOGICIEL On lance le fichier scriptPrincipal.py. Une fois lancé, il va attribuer les chemins nécessaires à des variables, puis il va vérifier dans le serveur d’indice i si il y a des fichiers DGN dans le dossier DGN. S’il y en a, il va vérifier que les fichiers updatefiles.txt et OK_IP.DU.SERVEUR existent. S’ils n’existent pas, alors il va vérifier s’il n’était pas placé sur le dernier serveur. Si il était sur le dernier serveur, il attend 5 minutes, puis relance les vérifications. Sinon, il passe au serveur suivant. Dans le cas où les 2 fichiers (OK_IP.DU.SERVEUR et updatefiles.txt) existent, il va alors lancer majListeDGN.py, qui va créer un fichier (listeDGN .txt) qui contiendra la liste de tous les DGN du dossier. A partir de cette liste, il va récupérer les 2 premières lignes et les mettre dans un autre fichier (listeDGNaTraiter.txt, créé par creationListeDGNaTraiter.py). Le script creationListeDGNaTraiter.py va écrire dans un log (DATE-DU-JOUR_DGNliste) quels DGN ont été ajoutés à ce fichier. Cette liste sera envoyée en paramètre à FME. La commande FME complète sera écrite dans un log (DATE-DU-JOUR_fme.log), puis FME sera exécuté. Quand il a fini son traitement, le scriptPrincipal.py va écrire dans le log DATE-DU-JOUR_DGNliste.log si le fichier a bien été traité ou non, et le temps que FME a mis pour le traiter. Une fois fait, le scriptPrincipal.py va lancer deplacementPDF.py, qui va se charger de créer une liste des PDF obtenus, puis les déplacer dans le dossier général des PDF au fur et à mesure du traitement de FME. Il écrira en parallèle dans un autre log (deplacementPDF.log) quels PDF ont été ajoutés à la liste des PDF à déplacer, puis quels PDF ont été déplacés. Le scriptPrincipal.py va ensuite remettre à jour la listeDGN.txt et recommencer son traitement tant qu’il y aura des DGN dans le dossier du serveur, zipper tous les logs ensemble (DATE-DU-JOUR_log.zip créé par creationZIP.py) puis passer au serveur suivant et ainsi de suite. LES DIFFÉRENTS ENVIRONNEMENTS UTILISÉS RECETTE (VA) Cet environnement est utilisé pour faire les premiers tests, avec un serveur, une base de données etc. Cet environnement est utilisé seulement par l’équipe de développement du logiciel et par personne d’autre. L’équipe de développement peut l’utiliser à leur bon vouloir, casser la base etc. sans problèmes, c’est un serveur qui sert justement à ça. Cet environnement comprend le nécessaire pour lancer l’application (voir les prérequis). Quand l’application a été validée lors de cette phase, on fait une demande de préproduction afin de la passer dans la seconde phase. Tant qu’il reste des bugs, elle va naviguer entre le poste de développement perso et la VA. PREPRODUCTION (VABF) Cet environnement est utilisé pour des tests plus poussés par des personnes qui sont en dehors de l’équipe de développement mais qui reste dans le cadre de l’entreprise (béta-test). Si il y a des bugs trouvés, le projet repasse en VA pour les corriger et repasse une demande pour aller dans la phase de test sur VABF. La base de données de ce serveur est identique à la Production, afin d’éviter tout problème. Sur ce serveur les béta-testeurs peuvent risquer de casser la base, mais comme elle est vierge à l’origine, ce n’est pas grave, elle sert de base de tests aussi. Cet environnement est à l’image de la Production. Une fois cette phase validée, il faut faire une demande de production afin de passer dans la dernière phase. Tant qu’elle n’est pas validée, l’application va naviguer entre la VABF, la VA et le poste de développement perso afin de corriger tous les bugs. PRODUCTION Cet environnement est le dernier, celui du client. C’est sur ce serveur que le client se connectera et c’est celui-ci qu’il utilisera tout le temps qu’il utilise son application. Le logiciel ne doit plus avoir un seul bug, mais si il est passé en phase de production c’est qu’il n’en a plus logiquement. MON POSTE PERSONNEL Sur ce poste, le développeur installe tout ce qu’il lui faut afin de développer l’application, il peut tout casser, il le réparera à la main, pendant la phase de développement. Une fois qu’il a une maquette de logiciel stable, il peut demander à passer en VA.

similaire:

	Résumé : Ce document présente une vue d'ensemble des nouvelles fonctionnalités...		Les arbres de Madagascar pour le reboisement (à Madagascar) «Pour promouvoir les plantations des arbres», Fiches techniques, Blaise Cook, Christian Burren, Michel J. Rakotoniaina, usaid, Madagascar,...
	Gestion Électronique des Documents «d’acquérir» ces différents fichiers en les convertissant soit sous forme de fichier pdf ou tout autre format qui permettra leur...		Résumé : La seconde génération des satellites météorologiques Météosat... «msg-atr» (Analyse en Temps Réel des données msg). La mise en place récente d’une station d’acquisition au crts de Rabat permet d’envisager...
	Codage «pdf» qui correspondent à un format lié à un programme spécifique, les types de fichiers correspondant aux extensions listées peuvent...		Les laboratoires de biotechnologie au service des produits cosmétiques «aslo» dans le sérum du patient. Le principe de cette technique est présenté dans le document 6
	Les laboratoires de biotechnologie au service des produits cosmétiques «aslo» dans le sérum du patient. Le principe de cette technique est présenté dans le document 6		Créer un lien pour télécharger un document (pdf)
	Recherche et développement en agriculture durable ...		Prise en charge par teleconsultation ou teleexpertise «base line» peut être faite de 6 mois en 6 mois. L’analyse aura lieu en base line pour les données avant et au terme des expérimentations....