APIs de table pour SQL Server

Transcription

1 2013 D - Pratique APIs de table pour SQL Server Établissement: HEG Arc Haute école Arc Gestion Réalisé par: M. Informaticien de gestion S adresse à: M.Fabrice Camus Date de début et de fin du travail de Bachelor Dernière modification le: Date de création: Version du document: 1.0 Type de réalisation: Intra-muros

2 Sommaire 1 Introduction Avant-Projet Planification Planifié Réalisé Administration du projet Analyse des risques Technologies utilisées Convention de nommage Valeurs taguées utilisées Fonctionnement du plugin Principe de base Déclenchement du plugin Prérequis Utilisation Sélection des tables Schéma de fonctionnement L utilité concrète du plugin Avant exécution du plugin Résultat de l exécution Développement Génération des scripts d APIs de tables Génération des logs Exécution des scripts Tables de journalisation Tables de journalisation des exceptions Colonnes d audit Triggers Procédures stockées Abstraction des scripts Génération des procédures Génération du code SQL DDL Génération des triggers Paramétrage du plugin...30 Page 2 sur 42

3 7.6.1 Plugin.properties database.properties Script de déploiement Tests Tests unitaires Tests par l utilisation Gestion des erreurs Implémentation de la gestion des messages et logs Affichage de messages à l utilisateur Exceptions Ajout d un nouveau SGBDR Amélioration Récupérer une connexion de Visual Paradigm Affichage de popup Gérer les modifications incrémentales des APIs de table Revoir la séparation des fichiers de propriétés Conclusion...42 Page 3 sur 42

4 1 Introduction Ce document va présenter la démarche entreprise afin de parvenir à l aboutissement du travail. Les chapitres sont ordonnés de façon à ce que le premier corresponde à la première démarche entreprise et le dernier à la dernière démarche. Le premier chapitre présente la planification mise en place afin de réaliser ce projet ainsi qu une analyse des risques et une présentation des différentes technologies utilisées. Le deuxième chapitre présente les différentes conventions de nommage mises en place. Le suivant expose et explique les différentes valeurs taguées utilisées. Le chapitre 5 présente le fonctionnement du plugin dans son ensemble. Le sixième chapitre démontre l utilité de celuici. Le chapitre 7 présente quelques éléments concernant le développement propre du plugin. Le chapitre 8 explique la procédure d ajout d un nouveau SGBDR au sein du plugin. Le chapitre suivant présente les différentes améliorations possibles. Le dernier chapitre conclut ce projet. Page 4 sur 42

5 12 avril 19 avril 26 avril 3 mai 8 mai 17 mai 24 mai 31 mai 7 juin 21 juin 28 juin 5 juillet 2 Avant-Projet 2.1 Planification Ci-dessous, une présentation de l organisation des 12 semaines à dispositions afin de réaliser ce dit travail. Le but originel de cette planification était d organiser le travail plutôt que de déterminer que la tâche A doit être terminée en semaine 2. J ai pris la décision de ne pas utiliser de méthode de gestion de projet, à la mode, tel Agile car mon projet ne se prête que très peu à ce type d organisation. Effectivement, il m a été demandé de réaliser chaque tâche de façon complète et non incrémentale comme la méthode Agile le préconise. De plus, je suis seul sur ce projet. Je ne vois donc que très peu l intérêt d utiliser une telle méthode. Tout du moins, une organisation se basant sur des itérations a été utilisée. À la fin de chacune de celle-ci, il a été décidé, conjointement avec mon directeur de travail, de livrer le plugin. 2.2 Planifié Tâche Rédaction de la demande de ratification Analyse du plugin Itération 1 Itération 2 Itération 3 Itération 4 Rédaction des rapports Test global Page 5 sur 42

6 12 avril 19 avril 26 avril 3 mai 8 mai 17 mai 24 mai 31 mai 7 juin 21 juin 28 juin 5 juillet 2.3 Réalisé Tâche Rédaction de la demande de ratification Analyse du plugin Itération Itération 2 Itération 3 1 Itération 4 Rédaction des rapports Test global 1. Retard dû à l analyse de l architecture à mettre en place. Effectivement, initialement, il était prévu que je complète le plugin «Génération des APIs de table pour Oracle», malheureusement, après analyse, il s est avéré que cette tâche demandait trop d adaptation. Page 6 sur 42

7 2.4 Administration du projet Dans l optique d assurer un suivi efficace, le directeur de travail m a convié à mettre en place les éléments d administration de projet suivant: Hebdomadairement une séance est organisée avec mon directeur de Bachelor et de l assistant. Un rapport, également hebdomadaire, doit être réalisé afin de présenter le déroulement de la semaine, les éventuels problèmes ainsi que le déroulement de la semaine à venir. Ce rapport hebdomadaire de travail doit être envoyé en fin de semaine par émail à mon directeur de Bachelor. Cette gestion apporte, pour le candidat, l avantage d être immédiatement redirigé en cas de problème. D un autre côté, le directeur de travail, qui est également le représentant du mandat dans mon cas, peut s assurer que le produit qu il attend réponde au mieux à ses besoins. Bien entendu, l inconvénient de la mise en place de cette administration réside dans le temps dépensé par les deux parties, autant pour la préparation des documents à envoyer que pour la lecture de ceux-ci. Au final, chacun y trouve son compte. Page 7 sur 42

8 2.5 Analyse des risques Le but de ce chapitre est de présenter les différents risques pouvant entraver le bon déroulement de ce projet. L analyse suivante vise essentiellement à identifier les risques et non pas à la mise en œuvre de mesures permettant de les réduire. Ci-dessous, une identification des différents risques: 1. Impossibilité d accéder à certains éléments du référentiel. Effectivement, il est possible que l API Java fourni par Visual Paradigm ne permette pas l accès à certains éléments(s). Ceci entraverait voir rendrait impossible la réalisation du plugin. Cependant ce risque est actuellement très réduit, car d utilise les mêmes méthodes que le plugin «Génération des APIs de table pour Oracle». 2. Impossibilité de reproduire les fonctionnalités du plugin «Génération des APIs de tables pour Oracle» dû au langage Transact SQL. Effectivement, il se peut que le langage Transact SQL ne puisse offrir les mêmes possibilités que le langage PLSQL. La réalisation, au préalable, des APIs à la main, a rendu ce risque inexistant. 3. Manque fonctionnel dû à une erreur d analyse du plugin de «Génération des APIs de tables pour Oracle». Il se peut que lors de l analyse du plugin «Génération des APIs de table pour Oracle», des fonctionnalités aient été oubliées. 4. Une mise à jour de Visual Paradigm changeant profondément le fonctionnement de l Open API. Un risque pour pourrait mettre fin à l utilisation de plugin est que Visual Paradigm décide, comme Oracle l ont fait avec l outil Designer, d arrêter le maintien de l Open API. Page 8 sur 42

9 La matrice ci-dessous présente les risques en fonction de leur gravité et de leur vraisemblance. Elle se base sur les recommandations EBIOS. Le placement ayant été fait au début de ce projet. Page 9 sur 42

10 2.6 Technologies utilisées Ci-dessous une liste et un petit descriptif des différentes technologies utilisées. Il est également précisé les différentes versions des logiciels/technologies utilisées afin d éviter les problèmes d incompatibilités. NetBeans IDE (Build ) Java JDK 1.7.0_25 Java SE Runtime Environment 1.6.0_35-b10 Microsoft SQL Server 2008 R (Microsoft SQL Server Developer Edition) Visual Paradigm for UML Enterprise Edition (Build ) Page 10 sur 42

11 3 Convention de nommage Les conventions de nommage permettent de faciliter la compréhension des éléments ainsi que garder une unité au travers des différents documents/codes. J ai donc défini les éléments suivants: Concerne Détail Abréviation Trigger INSTEAD OF IOF Trigger AFTER AFTER Trigger Déclenchement avant PRE Trigger Déclenchement après POST Trigger Déclenchement pour chaque ligne ROW Trigger Déclenchement pour une ligne STMT Trigger Insert INS Trigger Update UPD Trigger Delete DEL Procédure Journal JN Il suffit de combiner ces différents éléments pour créer le nom des éléments que j ai utilisé. Exemple: Trigger INSTEAD OF UPDATE FOR EACH ROW = IOF_UPD_ROW Trigger AFTER DELETE = AFTER_DEL_STMT Page 11 sur 42

12 4 Valeurs taguées utilisées Les valeurs taguées permettent d indiquer au plugin les éléments à générer. Elles sont propres à chaque table. Voici une liste les décrivant: Valeurs taguées PRE_INS POST_INS PRE_UPD POST_UPD PRE_DEL POST_DEL JOURNAL CTRLAJUSER CTRLAJDATE CTRLMOUSER CTRLMODATE PROCEDURE PRE_BEFORE_INS_ROW PRE_BEFORE_INS_STMT PRE_BEFORE_UPD_ROW Explications avant chaque requête d insertion de données dans la base. après chaque requête d insertion de données dans la base. avant chaque requête de modification de données dans la base. après chaque requête de modification de données dans la base. avant chaque requête de suppression de données dans la base. après chaque requête de suppression de données dans la base. Permet de générer le mécanisme de journalisation des manipulations des données. Permet d ajouter la colonne CTRLAJUSER d information d audit de manipulation des enregistrements. Permet d ajouter la colonne CTRLAJDATE d information d audit de manipulation des enregistrements. Permet d ajouter la colonne CTRLMOUSER d information d audit de manipulation des enregistrements. Permet d ajouter la colonne CTRLMODATE d information d audit de manipulation des enregistrements. Permet d ajouter une procédure stockée personnalisée. avant une requête d insertion du trigger INSTEAD OF INSERT FOR EACH ROW. avant une requête d insertion du trigger INSTEAD OF INSERT STMT. avant une requête de mise à jour des données du trigger INSTEAD OF UPDATE FOR EACH ROW. Page 12 sur 42

13 PRE_BEFORE_UPD_STMT PRE_BEFORE_DEL_ROW PRE_BEFORE_DEL_STMT PRE_AFTER_INS_ROW PRE_AFTER_INS_STMT PRE_AFTER_UPD_ROW PRE_AFTER_UPD_STMT PRE_AFTER_DEL_ROW PRE_AFTER_DEL_STMT POST_BEFORE_INS_ROW POST_BEFORE_INS_STMT POST_BEFORE_UPD_ROW avant une requête de mise à jour des données du trigger INSTEAD OF UPDATE STMT. avant une requête de suppression de données du trigger INSTEAD OF DELETE FOR EACH ROW. avant une requête de suppression de données du trigger INSTEAD OF DELETE STMT. avant une requête d insertion du trigger AFTER INSERT FOR EACH ROW. avant une requête d insertion du trigger AFTER INSERT STMT. avant une requête de mise à jour des données du trigger AFTER UPDATE FOR EACH ROW. avant une requête de mise à jour des données du trigger AFTER UPDATE STMT. avant une requête de suppression de données du trigger AFTER DELETE FOR EACH ROW. avant une requête de suppression de données du trigger AFTER DELETE STMT. après une requête d insertion du trigger INSTEAD OF INSERT FOR EACH ROW. après une requête d insertion du trigger INSTEAD OF INSERT STMT. après une requête de mise à jour des données du trigger INSTEAD OF UPDATE FOR EACH ROW. POST_BEFORE_UPD_STMT après une requête de mise à jour des données du trigger INSTEAD OF UPDATE STMT. POST_BEFORE_DEL_ROW POST_BEFORE_DEL_STMT après une requête de suppression de données du trigger INSTEAD OF DELETE FOR EACH ROW. Page 13 sur 42

14 après une requête de suppression de données du trigger INSTEAD OF DELETE STMT. POST_AFTER_INS_ROW POST_AFTER_INS_STMT POST_AFTER_UPD_ROW POST_AFTER_UPD_STMT POST_AFTER_DEL_ROW POST_AFTER_DEL_STMT après une requête d insertion du trigger AFTER INSERT FOR EACH ROW. après une requête d insertion du trigger AFTER INSERT STMT. après une requête de mise à jour des données du trigger AFTER UPDATE FOR EACH ROW. après une requête de mise à jour des données du trigger AFTER UPDATE STMT. après une requête de suppression de données du trigger AFTER DELETE FOR EACH ROW. après une requête de suppression de données du trigger AFTER DELETE STMT. Page 14 sur 42

15 5 Fonctionnement du plugin 5.1 Principe de base L objectif de ce chapitre est de présenter les principes de base sur lesquels repose ce plugin. Il m a été expressément de développé un plugin pour Visual Paradigm et pour le SGBDR SQL Server. C est pourquoi aucune analyse n a été faite concernant le choix technologique. Effectivement, Visual Paradigm offre uniquement une API écrite en Java et SQL Server offre un langage de manipulation de ces objets: le Transact SQL. Les fonctionnalités qui ont été développées sont celles présentées dans le document théorique. Page 15 sur 42

16 5.2 Déclenchement du plugin Prérequis Quelques règles sont à appliquer afin de pouvoir générer les APIs de table: Avoir défini au moins un modèle dans le projet Visual Paradigm et le nommer «Model». Avoir une clé primaire par table. Avoir au moins une table marquée par le stéréotype «MLD». Avoir au moins une colonne par table. Ces contraintes ont été fixées, car elles représentent le seuil minimum d informations nécessaire au bon fonctionnement du plugin Utilisation Le plugin se déclenche de deux manières. La première consiste à utiliser l icône dans la barre des raccourcis. La deuxième est de passer par le menu. Page 16 sur 42

17 5.2.3 Sélection des tables Le stéréotype «MLD» permet de sélectionner uniquement les tables dont nous voulons générer les APIs de table. Voici comment ajouter ce stéréotype : Page 17 sur 42

18 5.2.4 Schéma de fonctionnement Ci-dessous un schéma représentant le fonctionnement global des APIs de tables.

19 6 L utilité concrète du plugin L utilité du projet a déjà été partiellement expliquée dans le document d introduction. Ce chapitre va donc uniquement illustrer son utilisation. 6.1 Avant exécution du plugin Voici les tables qui me serviront d exemple. Voici les valeurs targuées de la table «Employes». Voici les valeurs targuées de la table «Departements» Page 19 sur 42

20 6.2 Résultat de l exécution Voici le résultat après exécution du plugin. Comme vous pouvez le remarquer, les colonnes de valeurs d informations d audit de manipulation des enregistrements ont été ajoutées en fonction des valeurs taguées. Voici les différentes tables présentes après exécution du plugin. Vous pouvez remarquer, la table de journalisation de la table Employes, est apparue ainsi que les deux tables de journalisation des exceptions. Voici les différentes procédures stockées. Les 3 procédures de journalisation des exceptions ont bien été créées ainsi que la procédure de journalisation de la table «Employes». Page 20 sur 42

21 Lors d une insertion d un département : INSERT INTO [AGL_RH].[dbo].[Departements] ([Code],[Libelle]) VALUES ('Inf','Informatique') GO Voici le résultat : Page 21 sur 42

22 Lors d une insertion d un employé : INSERT INTO [AGL_RH].[dbo].[Employes] ([DEP_Numero],[Mnemo],[Nom],[Prenom],[RueNo],[CodePostal],[Localite]) VALUES (1,'as','Senft','Arnaud','Docteur Tièche 5A','2732','Reconvilier') GO Table «Employes»: Table de journalisation de l employé : Page 22 sur 42

23 Mise à jour de cet employé : UPDATE [AGL_RH].[dbo].[Employes] SET [Mnemo] = 'sa' WHERE Numero = 1 GO Table «Employes» Table de journalisation de l employé : Page 23 sur 42

24 Suppression de cet employé : DELETE FROM [AGL_RH].[dbo].[Employes] WHERE Numero = 1 GO Table «Employes» vide : Table de journalisation : Page 24 sur 42

25 7 Développement 7.1 Génération des scripts d APIs de tables Trois scripts sont générés lors de l exécution du plugin. Le premier (PROC_DDL_SCRIPT) regroupe toutes les procédures stockées à créer : Procédure de journalisation. Procédure de journalisation des exceptions. Le deuxième (SQL_DDL_SCRIPT) regroupe tous les scripts de définition des données dont : Ajout de champs d audit. Création de la table de journalisation. Création des tables de journalisation des exceptions. Le dernier (TRIGGER_DDL_SCRIPT) regroupe les différents triggers à créer. 7.2 Génération des logs Le dossier logs contient tous les logs, par jour, des exceptions levées lors du déclenchement du plugin. Voici un exemple de log : EXCEPTION IN CLASS 'ch.hearc.ig.generationapistablesqlserver.presentation.action.actioncontroller' : Exception: ch.hearc.ig.generationapistablesqlserver.exceptions.nostereotypeexception Message: Il n y a pas de stéréotype MLD Date: /09:29:18 Les logs contiennent donc la classe d où qui a généré l exception, l exception, le message et la date. Page 25 sur 42

26 7.3 Exécution des scripts Tables de journalisation Voici comment se présente les différentes tables de journalisation générées dans SQL Server : Tables de journalisation des exceptions Voici comment se présentent les tables de journalisation des erreurs générées: Colonnes d audit Voici comment se présentent les colonnes d audit générées: Page 26 sur 42

27 7.3.4 Triggers Voici comment se présentes les triggers générés: Procédures stockées Voici les différentes procédures stockées générées : Page 27 sur 42

28 7.5 Abstraction des scripts Le but est de s abstraire au maximum du SGBDR utilisé afin de réimplémenter le minimum d éléments lors de l ajout d un nouveau SGBDR Génération des procédures Étant donné que le but est de s abstraire au maximum du SGBDR utilisé sans pour autant rendre le plugin bloquant, une classe abstraite contenant les éléments «réutilisable» et indépendante du SGBDR a été créée. Cette classe a notamment le rôle de vérifier les valeurs taguées. Effectivement, celles-ci sont indépendantes du SGBDR utilisé. Ainsi pas besoin de réimplémenter ces tests lors de l ajout d un SGBDR. La définition des méthodes de génération des procédures est également un élément indépendant du SGBDR Génération du code SQL DDL Une classe abstraite contenant les éléments communs pour chaque SGBDR a également été créée pour les codes SQL DDL. Ces éléments communs sont les mêmes que pour les procédures. C est-à-dire, le test des valeurs taguées ainsi que la définition des méthodes de générations des codes SQL DDL. Page 28 sur 42

29 7.5.3 Génération des triggers Concernant la génération du code des triggers, très peu d éléments sont communs entre chaque SGBDR. Une classe abstraite est quand même présente, mais ne comprend que peu d éléments. Page 29 sur 42

30 7.6 Paramétrage du plugin Plugin.properties Ce fichier de configuration du plugin permet de modifier les différents éléments générés. J ai pris la décision de centraliser et d externaliser ces éléments afin de : Ne pas devoir recompiler le plugin lors d une modification dans le fichier. Centraliser l ensemble des éléments susceptible de changer. Ainsi ce fichier regroupe, en un seul endroit, des propriétés ayant potentiellement un risque de changer. Permet de définir le nom du projet : PROJECT.NAME=GenerationAPIsTableSQLServer Permet de définir la version du projet : PLUGIN.VERSION=0.0.0 Permet de définir la date de la version : PLUGIN.VERSIONDATE= Permet de définir le répertoire de Visual Paradigm qui contient les plugins : VP.PLUGINPATH=C:/Program Files (x86)/visual Paradigm for UML 10.1/plugins Permet de définir le nom du dossier des fichiers logs, le nom des fichiers et le niveau des logs : LOGSMANAGER.LOG_FOLDER=logs LOGSMANAGER.LOG_FILENAME_FORMAT=yyyy-MM-dd LOGSMANAGER.WARNING_LEVEL_TO_LOG=INFO Permet de définir le niveau des messages à afficher: MESSAGEMANAGER.WARNING_LEVEL_TO_SHOW=INFO Permet de définir le nom des Tagged Values à récupérer: TAGGEDVALUES.PRE_INS=PRE-INS TAGGEDVALUES.POST_INS=POST-INS TAGGEDVALUES.PRE_UPD=PRE-UPD TAGGEDVALUES.POST_UPD=POST-UDP TAGGEDVALUES.PRE_DEL=PRE-DEL TAGGEDVALUES.POST_DEL=POST-DEL TAGGEDVALUES.JOURNAL=JOURNAL TAGGEDVALUES.CTRLAJUSER=CTRLAJUSER TAGGEDVALUES.CTRLAJDATE=CTRLAJDATE TAGGEDVALUES.CTRLMOUSER=CTRLMOUSER TAGGEDVALUES.CTRLMODATE=CTRLMODATE TAGGEDVALUES.PROCEDURE=PROCEDURE TAGGEDVALUES.PRE_IOF_INS_ROW=PRE_IOF_INS_ROW TAGGEDVALUES.PRE_IOF_INS_STMT=PRE_IOF_INS_STMT TAGGEDVALUES.PRE_IOF_UPD_ROW=PRE_IOF_UPD_ROW TAGGEDVALUES.PRE_IOF_UPD_STMT=PRE_IOF_UPD_STMT TAGGEDVALUES.PRE_IOF_DEL_ROW=PRE_IOF_DEL_ROW TAGGEDVALUES.PRE_IOF_DEL_STMT=PRE_IOF_DEL_STMT TAGGEDVALUES.PRE_AFTER_INS_ROW=PRE_AFTER_INS_ROW TAGGEDVALUES.PRE_AFTER_INS_STMT=PRE_AFTER_INS_STMT TAGGEDVALUES.PRE_AFTER_UPD_ROW=PRE_AFTER_UPD_ROW TAGGEDVALUES.PRE_AFTER_UPD_STMT=PRE_AFTER_UPD_STMT TAGGEDVALUES.PRE_AFTER_DEL_ROW=PRE_AFTER_DEL_ROW TAGGEDVALUES.PRE_AFTER_DEL_STMT=PRE_AFTER_DEL_STMT Page 30 sur 42

31 TAGGEDVALUES.POST_IOF_INS_ROW=POST_IOF_INS_ROW TAGGEDVALUES.POST_IOF_INS_STMT=POST_IOF_INS_STMT TAGGEDVALUES.POST_IOF_UPD_ROW=POST_IOF_UPD_ROW TAGGEDVALUES.POST_IOF_UPD_STMT=POST_IOF_UPD_STMT TAGGEDVALUES.POST_IOF_DEL_ROW=POST_IOF_DEL_ROW TAGGEDVALUES.POST_IOF_DEL_STMT=POST_IOF_DEL_STMT TAGGEDVALUES.POST_AFTER_INS_ROW=POST_AFTER_INS_ROW TAGGEDVALUES.POST_AFTER_INS_STMT=POST_AFTER_INS_STMT TAGGEDVALUES.POST_AFTER_UPD_ROW=POST_AFTER_UPD_ROW TAGGEDVALUES.POST_AFTER_UPD_STMT=POST_AFTER_UPD_STMT TAGGEDVALUES.POST_AFTER_DEL_ROW=POST_AFTER_DEL_ROW TAGGEDVALUES.POST_AFTER_DEL_STMT=POST_AFTER_DEL_STMT Permet de définir le nom des triggers: TRIGGER.IOF_INS_ROW_NAME=IOF_INS_ROW TRIGGER.IOF_INS_STMT_NAME=IOF_INS_STMT TRIGGER.IOF_UPD_ROW_NAME=IOF_UPD_ROW TRIGGER.IOF_UPD_STMT_NAME=IOF_UPD_STMT TRIGGER.IOF_DEL_ROW_NAME=IOF_DEL_ROW TRIGGER.IOF_DEL_STMT_NAME=IOF_DEL_STMT TRIGGER.AFTER_INS_ROW_NAME=AFTER_INS_ROW TRIGGER.AFTER_INS_STMT_NAME=AFTER_INS_STMT TRIGGER.AFTER_UPD_ROW_NAME=AFTER_UPD_ROW TRIGGER.AFTER_UPD_STMT_NAME=AFTER_UPD_STMT TRIGGER.AFTER_DEL_ROW_NAME=AFTER_DEL_ROW TRIGGER.AFTER_DEL_STMT_NAME=AFTER_DEL_STMT Permet de définir le nom du stéréotype MLD: STEREOTYPE.SCHEMA_TO_TRANSFORM=MLD Permet de définir le nom des tables ou de leur extension : TABLE.DDL_EXCEPTION_JOURNAL_NAME=ERRORS_JN TABLE.DDL_EXCEPTION_TRACE_JOURNAL_NAME=ERRORS_JN_CALLS TABLE.DDL_JOURNAL_EXT_NAME=_JN Permet de définir le nom du dossier contenant les scripts et le nom de ceux-ci : SCRIPTS.FOLDER_NAME=scripts_apis SCRIPTS.SQL_DDL_SCRIPT=SQL_DDL_SCRIPT SCRIPTS.PROC_DDL_SCRIPT=PROC_DDL_SCRIPT SCRIPTS.TRIGGER_DDL_SCRIPT=TRIGGER_DDL_SCRIPT Permet de définir le nom des procedures: PROCEDURE.ERR_PROCESS=ERR_PROCESS PROCEDURE.ERR_SAVE_NEW=ERR_SAVE_NEW PROCEDURE.ERR_SAVE_CALL=ERR_SAVE_CALL PROCEDURE.JOURNAL_PREFIXE=ins_jn_ Page 31 sur 42

32 7.6.2 database.properties Ce fichier regroupe les différentes propriétés concernant la base de données. Permet d indiquer la base de données désirée : SGBDR=SQL_Server Permet de configurer les paramètres de connexion à la base de données : DB_URL=jdbc:sqlserver://AGL-SENFTA:1433;DatabaseName=AGL_RH DB_USERNAME=AGL_USER DB_PWD=AGL_USER Page 32 sur 42

33 7.7 Script de déploiement Voici le script ANT (build-vp.xml) qui a été utilisé afin de déployer automatiquement le projet dans le dossier «plugin» de Visual Paradigm. <?xml version="1.0"?> <project name="compileandcopytovp" default="doall"> </project> <property file="plugin.properties" /> <!-- Define folders --> <property name="srcpath" location="src" /> <property name="buildpath" location="classes" /> <!-- Run all targets --> <target name="doall"> </target> <echo message="starting Ant script" level="info" /> <antcall target="copytovp" /> <echo message="end Ant script" level="info" /> <!-- Deploy to Visual Paradigm --> <target name="copytovp"> </target> <echo message="deploying to VP plugins folder..." level="info" /> <delete dir="${vp.pluginspath}/${project.deployedfolder}" /> <mkdir dir="${vp.pluginspath}/${project.deployedfolder}"/> <copy todir="${vp.pluginspath}/${project.deployedfolder}/"> </copy> <fileset dir="." excludes="**/.project, **/.classpath, **/build.xml, **/build-vp.xml, **/manifest.mf, **/src/, **/.settings/, **/.externaltoolbuilders/, nbproject/" /> <mkdir dir="${vp.pluginspath}/${project.deployedfolder}/classes"/> <copy todir="${vp.pluginspath}/${project.deployedfolder}/classes"> </copy> <fileset dir="./build/classes"/> <delete dir="${vp.pluginspath}/${project.deployedfolder}/build"/> Si vous utilisez NetBeans, il faut ensuite importer ce fichier dans le script ANT build.xml. <import file="build-vp.xml"/> Puis indiquer au script build.xml quand le script buid-vp.xml doit être déclenché. <target name="-post-compile"> <antcall target="doall"/> </target> Le script doit être appelé après compilation. Page 33 sur 42

34 7.8 Tests Tests unitaires Malheureusement, aucun test unitaire n a pu être réalisé. Effectivement, s agissant d un plugin, il n est pas possible de tester l application du faite de la très forte liaison entre le plugin et Visual Paradigm Tests par l utilisation Du fait de la nécessité d avoir un référentiel complet ainsi que l environnement pour effectuer des tests, je suis très vite arrivé à la conclusion que je devais créer un deuxième projet me permettant d effectuer différents tests. Voici la procédure mise en place afin d effectuer ces tests : Page 34 sur 42

35 7.9 Gestion des erreurs Implémentation de la gestion des messages et logs Après avoir rapidement jeté un œil aux travaux effectués l année précédente, je me suis rapidement rendu compte que le travail [DOC-STB-02] traitait déjà de cette problématique. Tout au long de mon cursus, nous avons appris à créer des éléments réutilisables. Connaissant la qualité du travail effectué par ce Bachelier et après avoir confirmé ceci par ma propre étude, j ai consciemment pris la décision de réutiliser ces différents éléments. Les chapitres ci-dessous reprennent ces différents éléments et expliquent leurs fonctionnements Affichage de messages à l utilisateur Fenêtre message L Open API de Visual Paradigm offre la possibilité d envoyer des messages à l utilisateur au travers de la console que l on aperçoit ci-dessous : Pour ce faire, il est nécessaire de faire appel à l élément ViewManage du plugin : ViewManager viewmanager = ApplicationManager.instance().getViewManager(); L objet instancié offre plusieurs méthodes permettant d afficher des messages. La méthode la plus utilisée est : viewmanager.showmessage(string message); Page 35 sur 42

36 Il est également possible de communiquer avec l utilisateur grâce au framework SWING et AWT. Je n ai pas utilisé ces frameworks pour ce projet, car ceci n était simplement pas le but de celui-ci. Voici un extrait de la documentation officielle de Visual Paradigm qui soutient mes dires [VP-WEB-01]: Exceptions Voici la description des différentes exceptions mise en place au sein du plugin. Exception Raison Comment la résoudre ConnexionException Vérifier les données de connexion dans le fichier database.properties. FileException NoColumnException Aucune colonne n existe dans une table. Vérifier le chemin d écriture indiqué dans le fichier plugin.properties. Vérifier qu aucune table sans colonne n est présente dans le modèle. NoPkException Pas de clé primaire dans une table. Ajouter une clé primaire à la table. NoRessourceFoundException La ressource n a pas été trouvée. NoStereotypeException Aucune table avec le stéréotype MLD n est présente. Vérifier le nom de la ressource indiquée. Ajouter le stéréotype MLD aux tables voulues. NoTableException Aucune table n est présente dans le MLD. PersistException DatabaseNotSupported La base de données indiquée n est pas reconnue. Vérifier le nom de la base de données entrée dans le fichier Database.properties et que les tests permettant de déterminer la base de données sélectionnée soient correct. Page 36 sur 42

37 8 Ajout d un nouveau SGBDR Ci-dessous les étapes permettant l extension du plugin à d autres SGBDR. 1. Ajouter l importation de la librairie de connexion à la base de données au dossier Lib du projet. 2. Indiquer au plugin, au travers du fichier plugin.xml, où se trouve la nouvelle librairie à importer. 3. Étendre la classe AbsFactory pour votre SGBDR. Il faut récupérer les valeurs taguées suivantes et en créer une représentation correspondant à ce qui existe dans le SGBDR ajouté (tableau repris du chapitre «Valeurs taguées utilisées). Valeurs taguées PROCEDURE PRE_BEFORE_INS_ROW PRE_BEFORE_INS_STMT PRE_BEFORE_UPD_ROW PRE_BEFORE_UPD_STMT PRE_BEFORE_DEL_ROW PRE_BEFORE_DEL_STMT PRE_AFTER_INS_ROW PRE_AFTER_INS_STMT PRE_AFTER_UPD_ROW PRE_AFTER_UPD_STMT Explications Permet d ajouter une procédure stockée personnalisée. avant une requête d insertion du trigger INSTEAD OF INSERT FOR EACH ROW. avant une requête d insertion du trigger INSTEAD OF INSERT STMT. avant une requête de mise à jour des données du trigger INSTEAD OF UPDATE FOR EACH ROW. avant une requête de mise à jour des données du trigger INSTEAD OF UPDATE STMT. avant une requête de suppression de données du trigger INSTEAD OF DELETE FOR EACH ROW. avant une requête de suppression de données du trigger INSTEAD OF DELETE STMT. avant une requête d insertion du trigger AFTER INSERT FOR EACH ROW. avant une requête d insertion du trigger AFTER INSERT STMT. avant une requête de mise à jour des données du trigger AFTER UPDATE FOR EACH ROW. Page 37 sur 42

38 avant une requête de mise à jour des données du trigger AFTER UPDATE STMT. PRE_AFTER_DEL_ROW PRE_AFTER_DEL_STMT POST_BEFORE_INS_ROW POST_BEFORE_INS_STMT POST_BEFORE_UPD_ROW avant une requête de suppression de données du trigger AFTER DELETE FOR EACH ROW. avant une requête de suppression de données du trigger AFTER DELETE STMT. après une requête d insertion du trigger INSTEAD OF INSERT FOR EACH ROW. après une requête d insertion du trigger INSTEAD OF INSERT STMT. après une requête de mise à jour des données du trigger INSTEAD OF UPDATE FOR EACH ROW. POST_BEFORE_UPD_STMT après une requête de mise à jour des données du trigger INSTEAD OF UPDATE STMT. POST_BEFORE_DEL_ROW POST_BEFORE_DEL_STMT POST_AFTER_INS_ROW POST_AFTER_INS_STMT POST_AFTER_UPD_ROW POST_AFTER_UPD_STMT POST_AFTER_DEL_ROW POST_AFTER_DEL_STMT après une requête de suppression de données du trigger INSTEAD OF DELETE FOR EACH ROW. après une requête de suppression de données du trigger INSTEAD OF DELETE STMT. après une requête d insertion du trigger AFTER INSERT FOR EACH ROW. après une requête d insertion du trigger AFTER INSERT STMT. après une requête de mise à jour des données du trigger AFTER UPDATE FOR EACH ROW. après une requête de mise à jour des données du trigger AFTER UPDATE STMT. après une requête de suppression de données du trigger AFTER DELETE FOR EACH ROW. après une requête de suppression de données du trigger Page 38 sur 42