Annexe 2 : standards techniques DSI Forem

Transcription

1 Table des matières 1 INTRODUCTION INVENTAIRE TECHNOLOGIQUE VUE GLOBALE DE L ARCHITECTURE DES APPLICATIONS ARCHITECTURE ESB STANDARDS DE DÉVELOPPEMENTS.NET STANDARDS DE DÉVELOPPEMENT J2EE STANDARDS DE DÉVELOPPEMENTS HTML/CSS/JAVASCRIPT MISE À JOUR DES DÉPENDANCES DOCUMENTATION DE DÉVELOPPEMENT STANDARDS DE DÉVELOPPEMENTS RELATIFS AUX SGBD STANDARDS DE DÉVELOPPEMENTS EN MATIÈRE DE SÉCURITÉ LES TYPES D'ENVIRONNEMENTS APPLICATIFS AU DSI Version du 17/11/2014 Page 1 sur 47 pages Dossier DMP /HTNMMN/EAI

2 1 Introduction La présente annexe décrit les standards techniques en vigueurs au DSI. Celle-ci donne une vue globale des technologies utilisées au Forem, de l architecture des applications et des standards en matière de développements. 2 Inventaire technologique 2.1 Applicatif Plateforme logicielle CaseWise OnMap SMS (Quescom) Webtrends Progiciel de gestion Archibus Chronos (IDTEC) Efficy Focus Data ABC Suite Genesis HR Access Ordiges PIA, EPM, ECO Plug RH (Groupe S) Vivaldi QMS 5.0 Modélisation des processus métier Outil de documentation des processus Envoi automatisé d'sms (Short Message Service) Outil d'analyse de statistiques de visites du site forem.be Progiciel gestion immobilière ( Progiciel gestion pointage & accès bâtiments ( Progiciel CRM ( Progiciel analyse ABC ( Progiciel de gestion du Call Center demandeur d'emploi Progiciel gestion des ressources humaines Progiciel comptabilité, gestion dépenses, économat ( Progiciel gestion des ressources humaines Progiciel de gestion de la qualité Version du 17/11/2014 Page 2 sur 47 pages Dossier DMP /HTNMMN/EAI

3 2.2 Développements Langage/boîte à outils.net Plateforme de développement de runtime Microsoft C# Langage de programmation EJB Architecture de composants Java J2EE Spécification pour la technologie Java Java Langage de programmation HTML/CSS/JavaScript Langages de développement front end NatStar Environnement de développement PHP Langage de programmation Outil/plateforme de développement Artifactory Binary Repository Manager pour Maven BIRT Générateur de documents BIRT Report Designer BIRT reports tools Eclipse (& Plugins) Environnement de développement Java Iplotz Mockup d'écran Jenkins Intégration continue Latex Moteur d'impression Maven Outil open-source de build pour les projets Java MS SQL Server Integration Service Transformation et chargement des données Oracle Warehouse Builder Transformation et chargement des données Sonar Mesure de la qualité du code source Team Foundation Server Forge logicielle et intégration continue pour les développements.net Visual Studio Environnement de développement.net Plateforme logicielle Apache Solr Plateforme de recherche Apache ActiveMQ Open source message broker Apache Camel Logiciel d'échange de messages entre application Apache ServiceMix Enterprise Service Bus Jira Bugs Tracker - Gestion des tâches Lucene-SolR Moteur de recherche Mantis Bugs Tracker Version du 17/11/2014 Page 3 sur 47 pages Dossier DMP /HTNMMN/EAI

4 2.3 Infrastructure Antivirus/Antispam FOPE Office 365 Fortinet Mc Afee SpamHouse Trend Micro Authentification Antivirus/antispam Mails Antivirus legacy pour applications externes Antivirus Antispam legacy pour les mails Antivirus - IMSS antivus legacy pour les mails entrants ADFS 2.0 Système d'authentification fédérée vers Office 365 Cisco ISE Evidian IAM Evidian SSO Microsoft Active Directory Oracle Sun One LDAP Shibboleth VASCO Server Automatisation/planification batchs BMC Control-M MS SCOR Backup EMC Legato EMC2 Networker Base de données Microsoft SQL Server MySQL Oracle DB Oracle SQL Data Modeler Oracle SQL Developer Sybase ASE Sybase IQ Tamino Gestion des accès réseaux des devices (Wifi) Gestion des identités et des accès Authentification unique Annuaire entreprise Annuaire entreprise Système d'authentification des utilsateurs du site Leforem.be Solution d'authentification complémentaire forte via token Solution pour la gestion des batchs applicatifs Module de Service Manager permettant d'automatiser des workflows Logiciel de Backup centralisé Solution de backup centralisé Base de données pour les solutions du windows Base de données pour petites solutions Base de données pour les applications Java Oracle db developement tools Oracle db developement tools Base de données Sybase pour applications legacy Erasme et IGFP base de données legacy base de données XML Version du 17/11/2014 Page 4 sur 47 pages Dossier DMP /HTNMMN/EAI

5 Toad BI/Reporting SAP Business Objects Microsoft BI Bureautique Internet Explorer IMAP Serveur Messagerie (SUN) Microsoft Exchange Microsoft Exchange Online (Office 365) Microsoft Lync (Office 365) Microsoft Office Pro Plus (Office 365) Microsoft OneDrive/MySite (Office 365) Microsoft Onenote (Office 365) Microsoft Outlook (Office 365) Microsoft Publisher (Office 365) MS SharePoint Online (Office 365) Microsoft Yammer (Office 365) Microsoft Office (KMS) Microsoft Visio Microsoft Project Microsoft Project Server Mind Manager Pro Mind Manager Viewer Enterprise Architect Isabel Publiweb APE Viscalc Segese Simul Performanse Aries Label Print Outil d'administration pour Oracle DB, Solaris Business Intelligence Business Intelligence Navigateur Internet Serveur de messagerie (utilisé pour le routage de mail) Solution serveur de Messagerie (utilisé pour le routage de mail) Serveur de messagerie Vidéo conférence et messagerie instantanée Suite bureautique de base pour les agents (Word,Excel,PowerPoint,Access) Espace personnel pour les agents Outil de prise de note pour les agents Client lourd de messagerie pour les agents Publication assistée par ordinateur Gestion et partage de fichiers Réseau social privé Suite bureautique pour les DE (via Citrix) Création de diagrammes Logiciel de gestion de projets Solution de gestion du portefeuille de projets Mind mapping software Viewer Mind mapping Modélisation UML Logiciel de gestion des paiements bancaires Logiciel de gestion des paiements bancaires Outil de visualisation, validation et contrôle des fichiers de paie générés par l'application APE Programme de l'iseor permettant de classer des phrases issues d'un diagnostic dans une nomenclature de dysfonctionnements Logiciel permettant de faire des simulations de salaire en fonction de différents éléments (commission paritaire, situation familiale,...) Logiciel utilisé par les RH dans le cadre du recrutement du personnel Logiciel de création, d'impression de codes-barres, Version du 17/11/2014 Page 5 sur 47 pages Dossier DMP /HTNMMN/EAI

6 étiquettes Autocad DWG Viewer Sketchup SQL Management Studio IDEA VLC Media Player Adobe Reader Adobe Acrobat Pro Adobe Creative Suite S6 Adobe Map Info Documentation/gestion contenu Confluence Jive Microsoft SharePoint Oracle Web Center Sites (Fatwire) WordPress Middleware Apache Web Server IIS Oracle WebLogic Oracle WebLogic Portal Monitoring BMC Performance Manager BMC TM-ART Enterprise manager Fortianalyser/manager GigaStore MS SCOM Network Observer What's Up Zabix Logiciel de CAO pour la DRM (lié à l application Archibus) Logiciel permettant de visualisé les dessins Autocad Logiciel de création d image 3D Logiciel pour effectuer des requêtes sur la base de données de l AMEF Logiciel de contrôle financier pour l Audit Interne et la Comptabilité Lecteur multimédia Lecteur de pdf Logiciel de gestion avancée de pdf Suite logicielle de création et diffusion de contenu media Logiciel de représentations géographiques et cartographiques de données Moteur Wiki, fourni par Altassian Forum internes Enterprise Content Management Web Content Server pour intranet et forem.be Gestion du contenu du journal interne du Forem Middleware - Server HTTP Serveur Web et Applicatif Microsoft Serveur d'application Oracle Portail oracle Capacity and performances analytics Transaction Management Application Response Time Outil d'administration pour Oracle DB, Solaris Solution de monitoring réseau firewall Monitoring spécifique du réseau Module de Service Center pour le monitoring des serveurs Windows Monitoring réseau Monitoring graphique synthétique du réseau Monitoring graphique synthétique du réseau Version du 17/11/2014 Page 6 sur 47 pages Dossier DMP /HTNMMN/EAI

7 Monitoring/Déploiement Cisco Prime (et works) IBM Director MS SCCM OS ios Microsoft Windows Microsoft Windows Server Oracle SUN Unix (Sparc) Réseau et sécurité Bluecoat Cisco Fortinet Juniper Service Management GetSMC MS SCSM Stockage IBM Tivoli Storage Librairie Overland Serveraid Manager (IBM) Solaris Volume Manager Virtualisation Citrix HyperV / SCVMM VMWare Oracle VM Solution de monitoring réseau de switch région et datacenter Monitoring hardware IBM Déploiement de patchs et packages sur postes et serveurs windows Système opératoire Apple Système opératoire postes clients Système opératoire pour les serveurs systèmes et applicatifs Système opératoire pour les serveurs applicatifs Solution hardware et software Proxy, Reverse Proxy et de webfiltering Solution hardware et software switchs, firewall interne, ladbalancing Solution firewall externe, webfiltering, antivirus Solution de VPN Accès à distance Application de gestion des incidents, changements et de l'asset Nouvelle Application de gestion des incidents, changements et de l'asset Logiciel de gestion de stockage d'entreprise Système de backup sur bande LTO Système de gestion RAID Système de gestion RAID Solution Citrix Xen App de virtualisation d'applications et logiciels Solution Microsoft pour la virtualisation de serveurs windows Solution pour la virtualisation de serveurs windows Solution pour la virtualisation de serveurs Unix Oracle Version du 17/11/2014 Page 7 sur 47 pages Dossier DMP /HTNMMN/EAI

8 3 Vue globale de l architecture des applications 3.1 Introduction Les développements du DSI s'orientent autour de deux axes : les applications les services (dans le sens SOA du terme) 3.2 Choix d'une architecture L'architecture standard (par défaut) est axée sur les Single-Page Applications et la création de services (SOA). Mais comme toujours, c'est à l'architecte de prendre les décisions architecturales dans le SAD (Software Architecture Document, analyse technique), en fonction des buts et des contraintes du projet, il peut s'orienter vers une architecture single-page, multipages ou une approche combinée. De manière générale, les applications single-page sont plus appropriées pour des applications de gestion et de CRUD. Les applications multipages sont quant à elles plus adaptées pour du contenu informationnel. 3.3 Architecture macro Le schéma suivant illustre l'architecture macro des applications single-page : 3.4 Description de l'architecture Une fois chargé, le front end de l'application réside dans le navigateur et est complètement autonome (pas de rechargement de pages). C'est lui qui est responsable de la couche Version du 17/11/2014 Page 8 sur 47 pages Dossier DMP /HTNMMN/EAI

9 présentation (GUI, MVC). Le front end considère le serveur non pas comme une source de pages (exception faite de la page de login) mais bien comme une source de données. La façade Web API gère l'authentification (actuellement avec une page de login, à l'avenir avec un token fourni par un STS), la logique business et les accès à la DB et aux services. Les services (SOA) identifiés dans le SAD (Software Architecture Document, analyse technique), doivent être implémentés dans un projet Web à part et faire l'objet d'un déploiement séparé. Les services doivent être tout à fait neutres par rapport au client. 3.5 Architecture des Web APIs et des services Le schéma suivant illustre un exemple d'architecture haut niveau des Web APIs et des services : 3.6 Description de l'architecture Cette architecture est basée sur deux principes : Le pattern REST La découpe Multi-Layer (Multi-Tier). Cette découpe permet une séparation claire des responsabilités : les problématiques de présentation, de logique business et d'accès aux données sont complètement dissociées les unes des autres. Chacune de ces problématiques est gérée par une couche dédiée (Presentation Layer, Business Logic Layer, Data Access Layer). Les éléments importants à retenir sont les suivants : Version du 17/11/2014 Page 9 sur 47 pages Dossier DMP /HTNMMN/EAI

10 Les contrôleurs ne font que valider les inputs du front end et retourner des représentations de ressources (XML / JSON). Les contrôleurs n'appliquent aucune logique business et n'accèdent jamais aux sources de données. Les domain models représentent des objets du domaine d'application (demandeur d'emploi, employeur, formation, dossier, adresse, prime, etc.). Les seuls objets échangés entre les contrôleurs et la couche Business Logic sont les Domain Models (ou des listes de Domain Models). La couche Business Logic est responsable de la logique métier (workflow, contrôle et application des règles business. etc.). Elle ne s'occupe jamais de problématiques de présentation ou d'accès aux sources de données. Les seuls objets échangés entre les couches Business Logic et Data Access sont les Domain Models (ou des listes de Domain Models). La couche Data Access est responsable de l'accès aux sources de données (base de données, service, etc.). Elle se charge des requêtes sur les données, des insertions de données, des modifications de données et des suppressions de données. Elle ne s'occupe jamais de problématiques de présentation et n'applique jamais aucune logique business. Elle ne retourne jamais d'objets intimement liés aux sources de données (ex : objets liés l'orm comme les entités Entity Framework, etc.). Elle renvoie des Domain Models. La couche Utilities est orthogonale aux autres couches et est en charge des problématiques communes (on parle de cross-cutting concerns). Elle contient des composants à but utilitaire, des helpers, etc. Pour qu'un composant ait sa place dans Utilities, il faut qu'il ne soit spécifique à aucune des autres couches (pas lié à la présentation, à la logique business ou aux accès aux données). Au contraire, il doit être pensé pour pouvoir rendre service à tout élément de l'application, peu importe la couche auquel ce dernier appartient. Par défaut, les contrôleurs ne peuvent pas accéder en direct à la couche Data Access sans passer par la couche Business Logic. Cependant, il arrive régulièrement que l'on veuille afficher/modifier des données sans qu'il faille appliquer la moindre règle business. Dans ce cas, il est permis aux contrôleurs de parler directement à la couche Data Access. 3.7 Architecture des applications multipages (architecture non-standard, sur décision de l'architecte uniquement) Le schéma suivant illustre l'architecture haut niveau des applications multipages : Version du 17/11/2014 Page 10 sur 47 pages Dossier DMP /HTNMMN/EAI

11 3.8 Description de l'architecture Cette architecture est basée sur deux principes : Le pattern Model View Controller La découpe Multi-Layer (Multi-Tier). Cette découpe permet une séparation claire des responsabilités : les problématiques de présentation, de logique business et d'accès aux données sont complètement dissociées les unes des autres. Chacune de ces problématiques est gérée par une couche dédiée (Presentation Layer, Business Logic Layer, Data Access Layer). Version du 17/11/2014 Page 11 sur 47 pages Dossier DMP /HTNMMN/EAI

12 Les éléments importants à retenir sont les suivants : Les vues (les pages Web) sont générées par les contrôleurs en y injectant des View Models. Ces View Models n'ont pas d'autre but que de servir cette logique de présentation. Les contrôleurs ne font que valider les inputs du front end et retourner des vues (contrôleurs Web) ou des représentations de ressources (XML / JSON) (contrôleurs API). Les contrôleurs n'appliquent aucune logique business et n'accèdent jamais aux sources de données. Les domain models représentent des objets du domaine d'application (demandeur d'emploi, employeur, formation, dossier, adresse, prime, etc.). Les seuls objets échangés entre les contrôleurs et la couche Business Logic sont les Domain Models (ou des listes de Domain Models). La couche Business Logic est responsable de la logique métier (workflow, contrôle et application des règles business. etc.). Elle ne s'occupe jamais de problématiques de présentation ou d'accès aux sources de données. Les seuls objets échangés entre les couches Business Logic et Data Access sont les Domain Models (ou des listes de Domain Models). La couche Data Access est responsable de l'accès aux sources de données (base de données, service, etc.). Elle se charge des requêtes sur les données, des insertions de données, des modifications de données et des suppression de données. Elle ne s'occupe jamais de problématiques de présentation et n'applique jamais aucune logique business. Elle ne retourne jamais d'objets intimement liés aux sources de données (ex : objets liés l'orm comme les entités Entity Framework, etc.). Elle renvoie des Domain Models. La couche Utilities est orthogonale aux autres couches et est en charge des problématiques communes (on parle de cross-cutting concerns). Elle contient des composants à but utilitaire, des helpers, etc. Pour qu'un composant ait sa place dans Utilities, il faut qu'il ne soit spécifique à aucune des autres couches (pas lié à la présentation, à la logique business ou aux accès aux données). Au contraire, il doit être pensé pour pouvoir rendre service à tout élément de l'application, peu importe la couche auquel ce dernier appartient. Par défaut, les contrôleurs ne peuvent pas accéder en direct à la couche Data Access sans passer par la couche Business Logic. Cependant, il arrive régulièrement que l'on veuille afficher/modifier des données sans qu'il faille appliquer la moindre règle business. Dans ce cas, il est permis aux contrôleurs de parler directement à la couche Data Access. 3.9 Architecture des applications devant a posteriori exposer des services Il arrive qu'une application doive a posteriori exposer des services. On procède alors comme indiqué dans le schéma suivant : Version du 17/11/2014 Page 12 sur 47 pages Dossier DMP /HTNMMN/EAI

13 Voici la marche à suivre : On crée un nouveau service qui partage les composants nécessaires de logique / data access avec l application initiale. Ce partage se fera par réutilisation de bibliothèques de classes (pas de double gestion de code). A cette occasion, il sera probablement nécessaire de restructurer légèrement l'application initiale afin d'extraire efficacement les composants à partager dans une dll. Ceci sera étudié au cas par cas et fera l'objet d'une décision de l'architecte. Attention à l'over-engineering! Si le SAD d'une application ne mentionne pas de service, il faut éviter de structurer l'application de manière à "facilement pouvoir en extraire un service quand ce sera nécessaire". Cet abus de prévoyance risque de compromettre la maintenabilité de l'application et nous préférons faire l'effort d'adaptation si cela s'avère nécessaire. Version du 17/11/2014 Page 13 sur 47 pages Dossier DMP /HTNMMN/EAI

14 Le service est bien sûr exposé sur l ESB. L'application initiale doit obligatoirement passer par le service pour accéder aux données sous le "contrôle" de ce dernier. Ce n'est pas parce que l'application à un accès direct à la DB qu'elle ne doit pas se conformer au SOA! Version du 17/11/2014 Page 14 sur 47 pages Dossier DMP /HTNMMN/EAI

15 4 Architecture ESB 4.1 Introduction L architecture d intégration est conçue autour de l ESB ServiceMix. Apache ServiceMix ( est un ESB Open Source combinant des fonctionnalités SOA et EDA (Event Driven Architecture). 4.2 Vue d ensemble Apache ServiceMix Service Backend CSM LDAP Apache ServiceMix Service Backend Application DB Client Apache ARCHITECTURE GÉNÉRALE DE L ESB INTERNE L architecture se compose des éléments suivants : Un «load balencer» (CSM - Cisco Content Switching Module) qui répartit la charge entre 2 serveurs Apache et détecte l'indisponibilité d'un serveur Apache. 2 serveurs Apache en façade des services de l'esb. Chaque serveur Apache façade une instance d'esb ServiceMix. Le rôle de ces serveurs Apache est de découpler les URLs publiques des services de l'esb des URLs "techniques" utilisées par l'esb. Les deux serveurs Apache sont Version du 17/11/2014 Page 15 sur 47 pages Dossier DMP /HTNMMN/EAI

16 aussi utilisés pour effectuer un Fail over rapide lorsqu'une instance de l'esb est indisponible mais que cette indisponibilité n'a pas encore été détectée par le CSM. 2 instances d'esb ServiceMix. 1 LDAP utilisé par les instances ServiceMix pour l'authentification et l'autorisation. Les instances de services backend. L'ESB se charge lui-même du load-balancing et du failover pour les appels vers les services backend (ces appels ne repassent donc pas par un CSM) ARCHITECTURE DE L'ESB EXTERNE Les échanges de données avec les partenaires externes se fait via d'autres instances de l'esb, situées dans un VLAN dédié de l'infrastructure. Derrière la séparation des ESB internes et externes, l'objectif est le suivant : contrôler l'api exposée aux partenaires externes : quels services, quelles méthodes, etc. avoir la possibilité de contrôler la charge venant de l'extérieur. Possibilité d'utiliser des mécanismes de throttling, protéger l'esb interne contre d'éventuelles attaques par DOS, avoir la possibilité de contrôler finement les données entrantes et sortantes ("application firewall"). 4.3 Mise en œuvre du SOA L ESB est le cœur de notre infrastructure SOA. Il façade l ensemble de nos services et procède à toutes sortes d orchestrations / transformations. Nos services se répartissent en deux grandes familles : Les services business o Référentiel entreprises o Nomenclature o Les services utilitaires : o Génération de documents o Archivage o Communication o Les services business exposent parfois (de façon propre) les données d une application legacy. Le schéma suivant fournit une vue haut niveau partielle de notre SOA : Version du 17/11/2014 Page 16 sur 47 pages Dossier DMP /HTNMMN/EAI

17 Version du 17/11/2014 Page 17 sur 47 pages Dossier DMP /HTNMMN/EAI

18 5 Standards de développements.net 5.1 Introduction Les développements.net sont la référence pour tout nouveau développement. Ce chapitre reprend les standards applicables aux développements.net réalisés pour le Forem. Les demandes de dérogation doivent être introduites à la Direction Architecture et figurer dans l'analyse technique (SAD). L'application des standards, et notamment les versions des librairies, doit être considérée dès la conception technique de l'application. En cours de développement, il est toujours préférable d'adapter le projet aux derniers standards disponibles, mais ce travail doit être évalué pour que les coûts, planning et qualité soit respectés. Si un développement n'adhère pas aux standards et n'a pas demandé, au préalable, une dérogation, il ne sera pas installé dans l'environnement de test (ACC). Si le manquement est constaté ultérieurement, il sera retiré de cet environnement, sans préavis ni communication préalable. Le responsable technique portera l'entière responsabilité de ce refus ou de ce retrait. Si le responsable sécurité ou l'architecture estime que les manquements sont graves, cette mesure pourrait s'étendre à l'environnement de production (PRD et Formation). 5.2 Technologies standards Technologie Standard Plateforme.NET Framework Langage C# ORM Entity Framework (Code First si possible) Framework Web ASP.NET MVC Services RESTful ASP.NET Web API Client HTTP Tests unitaires Microsoft Unit Test Framework Mocking Microsoft Fakes ou Moq IDE Visual Studio Application Lifecycle Management Team Foundation Server Source Control Git (TFS-Git) 5.3 Organisation INTÉGRATION CONTINUE Microsoft ASP.NET Web API Client Libraries Tous les projets de développement sont soumis à l intégration continue sur Team Foundation Server. A chaque commit, diverses mesures de qualités sont effectuées, le code est buildé, les tests unitaires sont exécutés et si tout est en ordre, la solution est déployée sur un serveur de développement GESTION DES SOURCES Les sources sont gérées uniquement par le serveur GIT (TFS-Git) mis à disposition par le DSI. Version du 17/11/2014 Page 18 sur 47 pages Dossier DMP /HTNMMN/EAI

19 Pour chaque "commit", un commentaire est obligatoire. Ne JAMAIS placer du code non testé ou non documenté VERSIONING Le versioning des applications et des bibliothèques de code développées au Forem doit suivre le schéma <x>.<y>.<z> où : x est le numéro de version majeure. Une version est majeure si une ou plusieurs des conditions suivantes sont rencontrées : o elle représente une évolution significative en termes de fonctionnalités o elle représente un changement dans la sémantique o elle induit des changements d'api cassant la rétro-compatibilité y est le numéro de version mineure. Une version est mineure si elle représente une évolution incrémentale en termes de fonctionnalités, sans changer la sémantique et sans casser la rétro-compatibilité. z est le numéro de patch. Une version est un patch si elle ne fait que corriger un ou des bugs, sans ajouter de fonctionnalités, sans changer la sémantique et sans casser la rétro-compatibilité. x, y et z sont bien entendu incrémentés de manière complètement indépendante. 5.4 Testing TESTS UNITAIRES Les tests unitaires sont obligatoires, pour toutes les classes. Ils doivent couvrir : toutes les méthodes publiques (à l'exception des accesseurs/mutateurs simples et des constructeurs vides) toutes les règles métiers tous les bugs corrigés Ils doivent de plus être : automatisés indépendants de l'environnement d'exécution. L'environnement de référence sera l'environnement de l'intégration Continue. Les composants ayant des dépendances externes devront être testés à l'aide de mocks. Enfin, les tests relatifs à une même classe devront être regroupés dans une même classe de test TESTS D INTÉGRATION Il faut distinguer deux types de tests d'intégration : Version du 17/11/2014 Page 19 sur 47 pages Dossier DMP /HTNMMN/EAI

20 Les tests d intégration de votre système : il s agit ici de tester l intégration avec des composants externes dont vous êtes responsables. Cela vaut aussi bien pour votre DB que pour les services que vous développez pour votre projet. Vous devez bel et bien réaliser des tests automatiques sur ces éléments et l intégration continue les exécutera également. Il faudra pour cela travailler sur des DBs/services en mémoire, etc. Les tests sur l ensemble de la chaîne : il s agit ici de tester l ensemble de la chaîne, et particulièrement les appels aux services de l ESB. Ceci ne peut se faire que dans l environnement d intégration et n est pas sujet à l intégration continue TEST D ACCEPTANCE Les scenarii de test sont rédigés par l'analyste. Avant d'effectuer une mise en ACC, ces scenarii devront être testés en DEV ou en INTEGRATION. Un rapport de test sera rédigé (Excel, au moins une ligne par scénario). Ces tests sont sous la responsabilité du responsable technique. 5.5 Version des frameworks / librairies (Mise à jour le 20/08/2014) Framework / librairie Version actuelle.net C# 5 Entity Framework 6.1 ASP.NET MVC 5.2 ASP.NET Web API 2.2 Automapper EPPlus Fakes.Contrib Log4Net Moq Ninject NLog Si une librairie n'est pas listée ici, elle est apriori interdite (Si une librairie "pirate" est découverte, elle sera supprimée, sans préavis ni communication préalable). Une librairie dépendante transitivement n'est pas à prendre en compte Les librairies utilisées pour les tests sont libres Version du 17/11/2014 Page 20 sur 47 pages Dossier DMP /HTNMMN/EAI

21 5.6 Guidelines CONVENTIONS DE NOMMAGE Nous utilisons les conventions de Microsoft ( avec quelques légers ajouts STRUCTURE DU CODE Ordre des membres Il est demandé de structurer le code de façon à ordonner les membres d'une certaine façon. Dans chaque classe, on retrouvera donc les membres dans l'ordre suivant : 1. Constantes 2. Attributs (champs d instance) 3. Constructeurs 4. Propriétés 5. Evénements 6. Méthodes Par "attribut", on entend le concept orienté objet désignant les données encapsulées (les champs d instance ou «champs privés»). A ne pas confondre avec le terme "attribute" utilisé dans la littérature.net pour désigner les décorateurs Utilisation de régions Afin d'améliorer la lisibilité du code, il est demandé au développeur d'utiliser des régions. Nommage des régions A noter qu'une région est définie de la façon suivante : #region Constantes #endregion Le nom de la région peut contenir n'importe quel caractère. Cependant, on ne l'entourera pas de guillemets. On écrira donc #region Constantes et non pas #region "Constantes" Modèle de régions standards #region Constantes #endregion Version du 17/11/2014 Page 21 sur 47 pages Dossier DMP /HTNMMN/EAI

22 #region Attributs #endregion #region Constructeurs #endregion #region Propriétés #endregion #region Méthodes #endregion Quand ne pas utiliser de régions? Les régions doivent être là pour améliorer la lisibilité du code. Si la lisibilité est suggestive, voici quelques cas où l'on ne devrait pas utiliser de régions. On ne doit pas définir de région vide (sans code à l'intérieur). o Le corollaire est que si vous utilisez le template défini ci-dessous, vous devrez supprimer toutes les régions dans lesquelles vous ne mettez pas de code Si une classe ne possède qu'un seul type de membre, il est préférable de ne pas les encadrer par une seule et unique région. o C'est typiquement le cas d'une exception custom qui ne définit que des constructeurs. Définir une région "Constructeurs" n'a que peu de sens Utilisation de sous-régions Il est tout à fait possible de définir des régions dans les régions standards définies ci-dessus. Ceci doit naturellement être utilisé avec parcimonie. Région standard "Méthodes" Si cela est pertinent en termes de lisibilité, il est possible de se passer de la région standard "Méthodes". Il est de plus conseillé de multiplier les régions au lieu d'avoir une seule et unique région "Méthodes" afin de clarifier la structure du code, et de regrouper les différentes méthodes d'un point de vue fonctionnel ou technique. Version du 17/11/2014 Page 22 sur 47 pages Dossier DMP /HTNMMN/EAI

23 6 Standards de développement J2EE 6.1 Introduction Les développements Java sont uniquement réalisés lors de la maintenance d applications existantes (Legacy). Aucun nouveau développement ne sera réalisé en Java. Ce chapitre reprend les standards applicables aux développements Java / J2EE réalisés pour le Forem. Les demandes de dérogation doivent être introduites à la Direction Architecture et figurer dans l'analyse technique (SAD). L'application des standards, et notamment les versions des librairies, doit être considérée dès la conception technique de l'application. En cours de développement, il est toujours préférable d'adapter le projet aux derniers standards disponibles, mais ce travail doit être évalué pour que les coûts, planning et qualité soit respectés. Si un développement n'adhère pas aux standards et n'a pas demandé, au préalable, une dérogation, il ne sera pas installé dans l'environnement de test (ACC). Si le manquement est constaté ultérieurement, il sera retiré de cet environnement, sans préavis ni communication préalable. Le responsable technique portera l'entière responsabilité de ce refus ou de ce retrait. Si le responsable sécurité ou l'architecture estime que les manquements sont graves, cette mesure pourrait s'étendre à l'environnement de production (PRD et Formation). 6.2 Version des frameworks / librairies (Mise à jour le 01/07/2014) Framework / librairie Java, JDK & JRE 1.7 JEE 6 JPA 2.0 EJB 3.1 Springframework GWT Ehcache slf4j LogBack Maven opencsv 2.3 dozer net.sf.json-lib:json-lib 2.4 aspectj velocity 1.7 itext (uniquement pour la manipulation de pdf, pas la génération) Version actuelle toléré: RELEASE (justification dans l'analyse technique et seulement pour les éléments difficilement réalisables avec J2EE) Version du 17/11/2014 Page 23 sur 47 pages Dossier DMP /HTNMMN/EAI

24 Si une librairie n'est pas listée ici, elle est apriori interdite (Si une librairie "pirate" est découverte, elle sera supprimée, sans préavis ni communication préalable). Une librairie dépendante transitivement n'est pas à prendre en compte Les librairies utilisées pour les tests sont libres 6.3 Organisation MAVEN La construction (build) et la gestion des dépendances sont exclusivement gérées via Maven SOURCES Les sources sont gérées uniquement par le serveur GIT mis à disposition par le DSI. Pour chaque "commit", un commentaire est obligatoire. Ne JAMAIS placer du code non testé ou non documenté VERSIONING Définition: o Version majeure: 1.x. Un changement de version implique un changement non optionnel ou un changement de sémantique sur l'existant. o Version mineure: x.1. Aucun changement sémantique dans l'existant. Enrichissement ou changement optionnel Utilisation: o o o Tous les artéfacts (document, XSD, code source) doivent posséder une version. La version MAJEURE doit faire partie du nom du fichier (à l'exception du code source) pour un XSD: Indiquer la version dans un attribut de l'élément "root" Utiliser le même namespace pour toutes les versions LIBRAIRIES Les librairies, interne ou externe, sont gérées par Artifactory (instance gérée par le DSI). L'utilisation du proxy dans Maven est strictement interdite INTÉGRATION CONTINUE Version du 17/11/2014 Page 24 sur 47 pages Dossier DMP /HTNMMN/EAI

25 Tout projet Java doit être intégré dans l'outil d'intégration continue Jenkins (instance gérée par le DSI). La racine du projet ne peut contenir qu'un seul fichier pom et les modules enfants. Le fichier pom doit supporter les opérations suivantes: clean install release deploy (assuré par l'outil sur Artifactory) 6.4 Testing TEST UNITAIRE Les tests unitaires sont obligatoires, pour toutes les classes, à l'exception de l'interface utilisateur. Ils doivent couvrir: o toutes les méthodes publiques (à l'exception des accesseurs simples et des constructeurs vides) o toutes les règles métiers o tous les bugs signalés (et corrigés) o toutes les exceptions déclarées (checked exception) Ils doivent être automatisés et s'exécuter avec JUnit & maven Ils doivent être indépendants de l'environnement d'exécution. L'environnement de référence sera l'environnement de l'intégration Continue TEST DE SOUS-SYSTÈME (OU MODULE) Chaque sous-système d'une application devra posséder son jeu de tests: un test par fonctionnalité. Pour un module utilisant un mécanisme fourni par un serveur JEE (CDI, JPA, transaction, datasource,...) le test doit être exécuté dans sur un environnement serveur. Soit en utilisant Arquillian, soit en utilisant une unité de déploiement sur un serveur (test "d'intégration", possible pour les modules utilisant un protocole de communication: RMI, HTTP,...) TEST CAS D'UTILISATION Les scenarii de test sont rédigés par l'analyste. Avant d'effectuer une mise en ACC, ces scenarii devront être testés en DEV ou en INTEGRATION. Un rapport de test sera rédigé (Excel, au moins une ligne par scénario). Ces tests sont sous la responsabilité du responsable technique. 6.5 Documentation de développement L'équipe de développement est en charge de la documentation qui suit: Document Responsable Quand le réaliser Dépôt Modèle SAD (Analyse Architecte Avant les développements. Wiki Template SAD (Software Version du 17/11/2014 Page 25 sur 47 pages Dossier DMP /HTNMMN/EAI

26 Document Responsable Quand le réaliser Dépôt Modèle technique) Doit être approuvé par la Direction infrastructure et la sécurité. Design des modules Responsable technique Avant le développement du module Wiki Architecture Document, analyse technique), Reprend une description et les schémas suivants: diagramme de classe diagramme de séquence et/ou de communication tout autre diagramme nécessaire xsd Architecte Lors de la définition du Wiki sans objet service ou de l'entité Liste des Architecte Avant les développements Wiki Template - SAD services SOA Javadoc Développeur Pendant le développement de la classe (et non après). Doit contenir en minimum: GIT, via code standard SUN source Description de la classe Description des méthodes publiques Description des exceptions gérées Release Management Note de publication Résultat des tests Responsable technique Responsable technique Responsable technique Avant une mise en acceptance Avant une mise en acceptance Avant une mise en acceptance Wiki Wiki Wiki libre Template - Note de publication libre 6.6 Particularités de développement JAVA Conventions Les règles standards de formatage sont les conventions Java: L'encoding est: UTF-8 Chaque règle métier devra avoir un commentaire formaté comme suit: //@BR Les packages doivent être préfixés par be.leforem.[nom de l application], ne contenir aucune majuscule et ne pas contenir le nom d'une société Logging L utilisation de la console (System.out, System.err) est strictement interdite Version du 17/11/2014 Page 26 sur 47 pages Dossier DMP /HTNMMN/EAI

27 La seule librairie de log autorisée est SLF4J Template & document La création de document (pdf, word, html) est assurée par un service backend. Ce service attend un template Birt et une source de données XML Recherche & indexation Le moteur de recherche Lucene/SolR est mis à disposition par via des services backend par l'équipe EAI. L'utilisation en dehors de ce cadre est interdite Cache mémoire L'utilisation d'une cache doit se faire via EHCache. En aucun cas l'utilisation d'une collection n'est tolérée J2EE Serveur d'application Le serveur de référence est WebLogic 12C L'application doit être agnostique au serveur d'application Service Les services, au sens SOA, seront exposés en REST et placés derrière l'esb. Le format d'échange est exclusivement l'xml. Avant le développement, les services seront décrits dans le SAD. Chaque paramètre d'un service doit être défini par un XSD, qui sera déposé en pièce jointe dans le Wiki Chaque service doit posséder une méthode test, sans argument, renvoyant un boolean. Cette méthode s'assurera que toutes les préconditions d'utilisation du service (connexion DB, appels aux services externes, ETC.) sont remplies pour son utilisation, quelques soit les méthodes. L'autorisation d'utiliser le service doit être vérifiée. Cette vérification sera faite via WebLogic (configuration de la sécurité JEE dans WebLogic\.) IHM Accessibilité: o Dans certains cas de figure, les applications disponibles pour le grand public doivent respecter des normes d accessibilité particulières (ex : AnySurfer) Sécurité Pour les applications accessibles depuis l internet, il faut intégrer une étude détaillée de la sécurité, dès l'analyse (fonctionnelle et technique). Prévoir dans le plan de test, des tests orientés sur les aspects de la sécurité, avec notamment la prise en compte du cross-site scripting (XSS) -- code injection Concevoir, dès l'analyse technique, une unité de déploiement spécifique pour l'internet. Version du 17/11/2014 Page 27 sur 47 pages Dossier DMP /HTNMMN/EAI

28 Ne jamais exposer, d'une quelconque manière, des services internes dans les unités de déploiement spécifique pour l'internet. Cela comprend: o les services cotés serveurs: servlet, RPC, service web (rest ou soap) ou toutes autres ressources o les fonctionnalités dans un module GWT, même si ces fonctionnalités sont gérées par rôle. o les prototypes pour les appels distants, même si les services ne sont pas accessibles par l'externe. Le niveau de mutualisation entre du code utilisé en interne et du code utilisé à partir d'internet est la classe de présentation. Les contrôleurs et les modules GWT doivent, dans tous les cas, être différents. Le responsable technique de l'application organisera une présentation, pour la Direction Architecture & Sécurité, qui devra démontrer les moyens mis en œuvre pour aborder la problématique de la sécurité (déploiement, organisation des modules, services, découpe détaillées des appels vers le serveur, validation, audit du code, tests, ETC.) Dans le cas où une seule règle énoncée ci-dessus n'est pas respectée, ou si la présentation est jugée insuffisante, l'application ne sera pas acceptée pour la mise en «acceptance» (et donc la production) Transaction Les transactions seront toujours des transactions gérées par le container (CMT). C'est la situation par défaut pour les EJB Le gestionnaire de transaction sera, si possible, XA ESB Ce qui doit passer par l'esb: o Tous les services SOAs exposés par les applications o Toutes les fonctionnalités transversales: Services d'archivage, service de communication o Les fonctionnalités (souvent des services) qui nécessite une orchestration, une composition (agrégation de données,...) o Les fonctionnalités demandant un système asynchrone, type JMS Ce qui ne doit pas passer par l'esb: o De manière générale: tout ce qui est interne à une application, y compris les communications vers la base de données Thread & ThreadPoolExecutor L'utilisation de thread dans un environnement géré a toujours été déconseillée. Elle est donc interdite. L'utilisation du ThreadPollExecutor est sujet à discutions, mais peut poser des problèmes, notamment dans des environnements mutualisés. En conséquence, l'utilisation du ThreadPollExecutor est également interdite JMS L'utilisation de JMS est strictement interdite. Version du 17/11/2014 Page 28 sur 47 pages Dossier DMP /HTNMMN/EAI

29 JPA L'implémentation de référence de JPA est Hibernate, mais il est strictement interdit d'utiliser des particularités de l'implémentation Aucun "import org.hiberntate.*" n'est toléré. 6.7 Sécurité Il est recommandé d'utiliser la sécurité standard (JAAS) pour sécuriser les applications front-end et back-end. La documentation du composant implémentant les règles du Forem se trouve dans le Wiki. Version du 17/11/2014 Page 29 sur 47 pages Dossier DMP /HTNMMN/EAI

30 7 Standards de développements HTML/CSS/JavaScript 7.1 Introduction Ce chapitre reprend les standards applicables aux développements HTML/CSS/JavaScript réalisés pour le Forem. Les demandes de dérogation doivent être introduites à la Direction Architecture et figurer dans l'analyse technique (SAD). L'application des standards, et notamment les versions des librairies, doit être considérée dès la conception technique de l'application. En cours de développement, il est toujours préférable d'adapter le projet aux derniers standards disponibles, mais ce travail doit être évalué pour que les coûts, planning et qualité soit respectés. Si un développement n'adhère pas aux standards et n'a pas demandé, au préalable, une dérogation, il ne sera pas installé dans l'environnement de test (ACC). Si le manquement est constaté ultérieurement, il sera retiré de cet environnement, sans préavis ni communication préalable. Le responsable technique portera l'entière responsabilité de ce refus ou de ce retrait. Si le responsable sécurité ou l'architecture estime que les manquements sont graves, cette mesure pourrait s'étendre à l'environnement de production (PRD et Formation). 7.2 Version des frameworks / librairies (Mise à jour le 20/08/2014) Framework / librairie Version actuelle AngularJS JQuery Modernizr Moment.js Restangular Si une librairie n'est pas listée ici, elle est apriori interdite (Si une librairie "pirate" est découverte, elle sera supprimée, sans préavis ni communication préalable). Une librairie dépendante transitivement n'est pas à prendre en compte Les librairies utilisées pour les tests sont libres Version du 17/11/2014 Page 30 sur 47 pages Dossier DMP /HTNMMN/EAI

31 7.3 Gestion des sources Les sources sont gérées uniquement par le serveur GIT mis à disposition par le DSI. Pour chaque "commit", un commentaire est obligatoire. Ne JAMAIS placer du code non testé ou non documenté. 7.4 Guidelines HTML / CSS Nous utilisons les conventions de Google ( avec quelques légères modifications. 7.5 Guidelines JavaScript Nous utilisons les conventions de airbnb/javascript ( avec quelques légères modifications ANALYSE STATIQUE DU CODE Nous utilisons pour ce faire JSHint UTILISATION DE JQUERY L utilisation directe de JQuery est découragée. Nous désirons que le développeur passe par les abstractions d AngularJS lorsque cela est possible. 7.6 Testing AngularJS a été pensé pour faciliter les tests unitaires, ce qui est tout à fait logique compte tenu des responsabilités étendues du front end dans les applications single-page. Tous les développements AngularJS au Forem doivent donc faire l'objet de tests unitaires. Version du 17/11/2014 Page 31 sur 47 pages Dossier DMP /HTNMMN/EAI

32 8 Mise à jour des dépendances Pour les projets en cours de développement et de maintenance, la mise à jour des librairies est obligatoire. Si la mise à jour bouleverse grandement le planning, une analyse d'impact sera rédigée par le responsable technique (dans la documentation du projet) et présentée à l'architecture. Pour les applications Legacy, un plan d'action doit être proposé à l'architecture. Pour les délais des mises à jour : Projet en développement, avant la première mise en «acceptance» : mise à jour immédiatement (dans les 3 semaines) Projet en maintenance, avec budget : mise à jour à planifier dans les 6 mois Projet sans budget : aucune mise à jour, mais dans ce cas, toute demande métier sera refusée. Le serveur de source sera mis en lecture seule. 9 Documentation de développement L'équipe de développement est en charge de la documentation qui suit: Document Responsable Quand le réaliser Dépôt Modèle SAD (Analyse Architecte Wiki technique) Design des modules Responsable technique Avant les développements. Doit être approuvé par la Direction infrastructure et la sécurité. Avant le développement du module Wiki Template SAD (Software Architecture Document, analyse technique), Reprend une description et les schémas suivants: diagramme de classe diagramme de séquence et/ou de communication tout autre diagramme nécessaire xsd Architecte Lors de la définition du Wiki sans objet service ou de l'entité Liste des Architecte Avant les développements Wiki Template - SAD services SOA Commentaires XML (.NET) Développeur Pendant le développement de la classe (et non après). Documentation des classes ainsi que de tous leurs membres publics/protected (constructeurs, méthodes Version du 17/11/2014 Page 32 sur 47 pages Dossier DMP /HTNMMN/EAI

33 Document Responsable Quand le réaliser Dépôt Modèle publiques, propriétés). Pour les méthodes, il faut commenter : Les paramètres (préconditions) Les valeurs de retour (postconditions) Les éventuelles exceptions renvoyées. Javadoc Développeur Pendant le développement de la classe (et non après). Doit contenir en minimum: Description de la classe Description des méthodes publiques Description des exceptions gérées GIT, via code source standard SUN Release Management Note de publication Résultat des tests Responsable technique Responsable technique Responsable technique Avant une mise en acceptance Avant une mise en acceptance Avant une mise en acceptance Wiki Wiki Wiki libre Template - Note de publication libre Version du 17/11/2014 Page 33 sur 47 pages Dossier DMP /HTNMMN/EAI

34 10 Standards de développements relatifs aux SGBD 10.1 Base de données Oracle CONVENTION DE NOMMAGE ET AUTRES SID On regroupe dans un SID les schémas qui ont un lien logique fort ou physique entre eux. Par exemple, on regroupe le schéma contenant les nomenclatures avec le schéma contenant les tables de travail des nomenclatures. Le SID est composé d'un nom et d'un suffixe Le nom : doit faire 6 caractères maximum et doit utiliser l'alphabet de base sans les accents ni les '-' ou '_', doit représenter le contenu de la DB. Exemple PERS, PRESTA, NOMENC,... Le suffixe est composé d'une lettre suivie d'un chiffre La lettre représente l'environnement : o D: développement o S: stable o I: intégration o A: acceptance o F: formation o P: production Le chiffre représente un numéro de séquence qui commence à 1 et qui sera incrémenté quand : o plusieurs versions d'une base de données doivent exister en même temps o la base de donnée a subit une grosse évolution -> Ce numéro va donc presque toujours être égal à Table space Pour chaque SID (voir pour chaque schéma quand il y a plusieurs schémas indépendants dans un même SID), il faut 2 tables spaces: 1 pour les données o Nommage: TBS_nomduschéma_DATA où nomduschéma correspond au nom du schéma contenant les données o Le table space DATA ne contiendra que les tables et les index que le système utilise pour les CLOBS/BLOBS,... 1 pour les index o Nommage: TBS_nomduschéma_IDX où nomduschéma correspond au nom du schéma contenant les données o Le table space IDX contiendra tous les index (y compris les index liés aux clés primaires) Version du 17/11/2014 Page 34 sur 47 pages Dossier DMP /HTNMMN/EAI

35 Schéma Le nom d'un schéma ne peut pas dépasser 30 caractères (limite Oracle) Il ne peut pas y avoir de '_' dans le nom d'un schéma Si le SID ne contient qu'un schéma de données, le schéma devra porter le nom du SID décrit ci-avant sans le suffixe. Ceci n'est toutefois pas obligatoire si ce nom est trop court et pas assez explicite Si le SID contient plusieurs schémas de données ou si on prévoit de le faire plus tard, il faudra choisir pour chaque schéma un nom qui décrit son contenu. Exemples: PERSONNE, NOMENCLATURE, CACHEOE, Tables Le nom des tables est toujours au singulier Le nom des tables ne peut pas dépasser 30 caractères (limite Oracle). Il sera toutefois toujours limité à 24 caractères pour accepter les suffixes demandés plus loin. Le nom des tables doit être suffisamment clair (on doit comprendre de quoi il s'agit à sa lecture). On préférera par ex. OFFRE à OFR. Si le nom est composé de plusieurs mots, il faut les séparer par un '_'. Par exemple: OFFRE_EFFECTIVE Si une table peut être considérée comme une sous-table d'une autre, on optera pour un nom composé du nom de la table parente et du nom de la sous-table spérarés par un '_' Si le nom est trop long (pour rappel, 24 caractères max.), on peut raccourcir le nom de la table parente. Par ex. PERS_ADRESSE (adresses des personnes contenues dans PERSONNE) Chaque table doit avoir une clé primaire. Sauf bonne raison, la clé primaire sera toujours sur un seul champ. Si la clé est composée, une clé technique pourra être créée Colonnes Le nom des colonnes est toujours au singulier Le nom des colonnes ne peut pas dépasser 30 caractères (limite Oracle) Le nom des colonnes doit être suffisamment clair (on doit comprendre de quoi il s'agit à sa lecture). On préférera par ex. STATUT à STT Clé primaire: La clé primaire doit s'appeler ID, même si elle contient un code, un nom ou autre chose La clé primaire sera toujours de type NUMBER quand elle doit être générée via une séquence La clé primaire sera toujours de type NUMBER s'il s'agit d'une clé technique La clé primaire sera préférentiellement de type NUMBER dans les autres cas Clé étrangère: Une clé étrangère doit avoir un nom qui se termine par '_ID'. Par ex. OFFRE_ID (qui pointe sur une OFFRE) Version du 17/11/2014 Page 35 sur 47 pages Dossier DMP /HTNMMN/EAI

36 Une clé étrangère peut avoir comme nom, le nom de la table qu'elle pointe suivi de '_ID', si ce nom est suffisamment clair. Il pourrait ne pas être clair en cas de récursivité (par ex. pour la table EMPLOYE, on aurait la colonne RESPONSABLE_ID plutôt que EMPLOYE_ID pour référencer le responsable qui est pourtant bien un élément de EMPLOYE) Si la colonne contient un code (de nomenclature par ex.), son nom doit se terminer par '_CODE' Si la colonne contient une date ou un timestamp, son nom doit se terminer par '_DATE' Si le nom d'une colonne est composé, on mettra la partie la plus importante en premier (ex. ADRESSE_RUE, ADRESSE_NUMERO, ADRESSE_BOITE,...) Ceci permet de regrouper les champs alphabétiquement et de, le cas échéant, garder une structure proche de l'xml ou de l'objet JAVA qui sera généré Séquences Le nom des séquences ne peut pas dépasser 30 caractères (limite Oracle) Le nom des séquences sera formé du nom de la table (qui a été limité à 24 caractères) suivi par '_SEQ' Une séquence doit préférentiellement être incrémentée de 1 en Index Le nom des index ne peut pas dépasser 30 caractères (limite Oracle) Le nom des index sera généralement formé du nom de la table (qui a été limité à 24 caractères) suivi par '_IDXnn', où nn est une valeur comprise entre 01 et 99 S'il s'agit d'un index portant sur une clé étrangère, il faudra nommer l'index comme le nom de la contrainte (voir Contraintes) S'il s'agit d'un index servant à vérifier une contrainte d'unicité, il devra porter le même nom que la contrainte (voir Contraintes) Contraintes Clé primaire Le nom de la contrainte ne peut pas dépasser 30 caractères (limite Oracle) Le nom de la contrainte sera formé du nom de la table (qui a été limité à 24 caractères) suivi par '_PK' Il est impératif d'avoir un index portant le même nom que la contrainte quand la contrainte porte sur une clé primaire Clé étrangère Le nom de la contrainte ne peut pas dépasser 30 caractères (limite Oracle) Le nom de la contrainte sera formé du nom de la table (qui a été limité à 24 caractères) suivi par '_Rnn', où nn est une valeur comprise entre 01 et 99 Version du 17/11/2014 Page 36 sur 47 pages Dossier DMP /HTNMMN/EAI

37 Il est fortement recommandé d'avoir un index portant le même nom que la contrainte quand la contrainte porte sur une clé étrangère, principalement si des suppressions dans la table étrangère sont prévues Si la clé étrangère est la première colonne d'un index existant, il ne faut pas créer d'index spécifique (sauf pour une question de performances si l'index est vraiment très gros, mais le gain est minime sur les volumes traités au Forem). On utilisera, sauf raison particulière qui le justifie, la clause ON DELETE RESTRICT quand on crée une clé étrangère. Ceci est le comportement par défaut d Oracle Unicité Le nom de la contrainte ne peut pas dépasser 30 caractères (limite Oracle) Le nom de la contrainte sera formé du nom de la table (qui a été limité à 24 caractères) suivi par '_Unn', où nn est une valeur comprise entre 01 et 99 Il est impératif d'avoir un index portant le même nom que la contrainte quand la contrainte vérifie qu'un ou plusieurs champs sont uniques o Non-Nulle (facultatif) Le nom de la contrainte ne peut pas dépasser 30 caractères (limite Oracle) Le nom de la contrainte sera formé du nom de la table (qui a été limité à 24 caractères) suivi par '_NNnn', où nn est une valeur comprise entre 01 et TYPES DE DONNÉES Dates Quand il s'agit de stocker une date, on doit utiliser le type DATE Quand il s'agit de stocker un timestamp, on doit utiliser le type TIMESTAMP ou DATE(6) Si on doit stocker une date qui pourrait ne pas être valide (par ex. 00/00/1977), on doit utiliser le type VARCHAR(10) en stockant la date au format YYYY-MM-DD Booléens Il faut utiliser un CHAR(1) pour stocker une valeur booléenne. Il devra contenir 0 (false), 1 (true) ou NULL SÉCURITÉ Rôles Il faut définir 2 rôles pour chaque schéma de données créé: o nom_du_schéma_r qui aura uniquement accès en lecture à toutes les tables du schéma o nom_du_schéma_rw qui aura accès en INSERT, UPDATE et DELETE sur toutes les tables du schéma, le droit en SELECT sur les séquences et le rôle nom_du_schéma_r Version du 17/11/2014 Page 37 sur 47 pages Dossier DMP /HTNMMN/EAI

38 User Dans Oracle, un schéma est un user et inversement. On appelle ici "user", un schéma qui ne sert qu'à se connecter et éventuellement à contenir des données temporaires ou de travail Chaque user doit avoir le rôle R_CONNECT Il faut un user Oracle par application qui accède à la base de données (celà permet à l'infrastructure d'identifier quelle application est connectée): o un user pour les services o un user pour le front-end (si il accède directement à la DB) o un user pour les batchs (si il y en a) o... Un user Oracle destiné à une application doit commencer par 'A_' et doit avoir un nom qui correspond à l'application concernée. A_FORMAB est suffisant pour décrire qu'il s'agit de l'application principale de FormaBanque (en l occurrence les services) EN général, le user aura le rôle nom_du_schéma_rw Un user de type 'A_' ne peut en aucun cas être utilisé par une personne. L'infrastructure ne devrait jamais communiquer un mot de passe d'un user 'A_' Un user Oracle destiné à une personne doit commencer par 'U_' suivi du login LDAP de la personne: ex. U_RTHSTV Il ne peut être utilisé que par la personne à qui appartient le login LDAP En général, le user aura le rôle nom_du_schéma_r Un user de type 'U_' ne peut en aucun cas être utilisé par une application Schéma de données Dans Oracle, un schéma est un user et inversement. On appelle ici "schéma de données", un schéma qui est destiné à contenir des données Le user Oracle doit être locké afin d'éviter que ce user ne soit utilisé par des personnes ou des applications 10.2 Base de données MS SQL Server INTRODUCTION Les standards et guidelines SQL Server listent les règles et conventions à appliquer lors de la conception d'une base de données SQL Server au Forem. Ils s'ajoutent aux règles et bonnes pratiques que tout développeur/dba devrait connaître et appliquer. N'hésitez pas à vous adresser à la Direction Architecture si vous avez la moindre question ou le moindre commentaire. Version du 17/11/2014 Page 38 sur 47 pages Dossier DMP /HTNMMN/EAI

39 CONVENTIONS DE NOMMAGE ET AUTRES CONSIDÉRATIONS DE STYLE D'une manière générale, tous les noms (d'instance, de table, de colonne,...) doivent être en PascalCase (ie la première lettre de chaque mot est en majuscule) Sauf cas exceptionnel, les underscores ne doivent pas être utilisés Instance On regroupe dans une instance les schémas/bases de données qui ont un lien logique fort ou physique entre eux/elles. Par exemple, on regroupe le schéma/la base de données contenant les nomenclatures avec le schéma/la base de données contenant les tables de travail des nomenclatures. Le nom d'une instance o doit être compréhensible o bien représenter le contenu de la DB o bien représenter le nom du projet Schémas/base de données Le nom d'un schéma/d'une base de données ne peut pas dépasser 128 caractères (limite SQL Server) Si l'instance ne contient qu'un schéma/qu'une base de données, le schéma/la base de données devra porter le nom de l'instance décrite ci-avant sans le suffixe. Ceci n'est toutefois pas obligatoire si ce nom est trop court et pas assez explicite Si l'instance contient plusieurs schémas/bases de données ou si on prévoit de le faire plus tard, il faudra choisir pour chaque schéma/base de données un nom qui décrit son contenu. Exemples: Personne, Nomenclature, CacheDE, Tables Le nom des tables est toujours au singulier Le nom des tables ne peut pas dépasser 128 caractères (limite SQL Server). Le nom des tables doit être suffisamment clair (on doit comprendre de quoi il s'agit à sa lecture). On n'utilisera donc pas d'acronyme ou d'abréviation (à part ceux unanimement reconnus), sauf si le nom de la table atteint la limite des 128 caractères. On préfèrera par ex.offre à Ofr. Le nom des tables est toujours en PascalCase. Par exemple: OffreEffective Si une table peut être considérée comme une sous-table d'une autre, on optera pour un nom composé du nom de la table parente et du nom de la sous-table. Si le nom est trop long, on peut raccourcir le nom de la table parente. Par ex. PersAdresse (adresses des personnes contenues danspersonne) Chaque table doit avoir une clé primaire. Version du 17/11/2014 Page 39 sur 47 pages Dossier DMP /HTNMMN/EAI

40 Sauf bonne raison, la clé primaire sera toujours sur un seul champ. Si la clé est composée, une clé technique pourra être créée. Pour nommer une table de jointure (dans le cas d'une relation many-to-many), on pourra concaténer le nom de la table parente et de la table enfant, en les séparant par un "_" Colonnes Le nom des colonnes est toujours au singulier. Le pluriel sera cependant utilisé dans le cas où cette colonne représente une donnée multiple (typiquement mappé sur un "flagged enum" en.net) Le nom des colonnes ne peut pas dépasser 128 caractères (limite SQL Server), et sera toujours au format Pascal Case Le nom des colonnes doit être suffisamment clair (on doit comprendre de quoi il s'agit à sa lecture). On préférera par ex. Statut à Stt Clé primaire: o La clé primaire ne sera composée que d'une seule colonne (à l'exception éventuelle des tables techniques visant à implémenter les relations many-to-many, et ce pour faciliter l'utilisation d'entity Framework) o La clé primaire doit s'appeler Id, même si elle contient un code, un nom ou autre chose (à l'exception éventuelle des tables techniques visant à implémenter les relations many-tomany, et ce pour faciliter l'utilisation d'entity Framework) o La clé primaire sera toujours de type INT quand elle doit être générée via un autonumber (IDENTITY) o La clé primaire sera toujours de type INT s'il s'agit d'une clé technique o La clé primaire sera préférentiellement de type INT dans les autres cas Clé étrangère: o o Une clé étrangère doit avoir un nom qui se termine par 'Id'. Par ex. OffreId (qui pointe sur une Offre) Une clé étrangère peut avoir comme nom, le nom de la table qu'elle pointe suivi de 'Id', si ce nom est suffisamment clair. Il pourrait ne pas être clair en cas de récursivité (par ex. pour la table Employe, on aurait la colonne ResponsableId plutôt que EmployeId pour référencer le responsable qui est pourtant bien un élément de Employe) Si la colonne contient un code (de nomenclature par ex.), son nom doit se terminer par 'Code' Si le nom d'une colonne est composé, on mettra la partie la plus importante en premier (ex. AdresseRue, AdresseNumero, AdresseBoite,...) Ceci permet de regrouper les champs alphabétiquement et de, le cas échéant, garder une structure proche de l'xml ou de l'objet JAVA qui sera généré. Version du 17/11/2014 Page 40 sur 47 pages Dossier DMP /HTNMMN/EAI

41 Index Le nom des index ne peut pas dépasser 128 caractères (limite SQL Server) Le nom des index sera généralement formé par le préfixe 'IDX_' suivi du nom de la table et du nom de la (ou des) colonnes concernées Contraintes Clé primaire Le nom de la contrainte ne peut pas dépasser 128 caractères (limite SQL Server) Le nom de la contrainte sera formé du préfixe 'PK_', suivi du nom de la table Clé étrangère Le nom de la contrainte ne peut pas dépasser 128 caractères (limite SQL Server) Le nom de la contrainte sera formé du préfixe 'FK_' suivi du nom des tables parents et enfant Il est fortement recommandé d'avoir un index portant le même nom que la contrainte quand la contrainte porte sur une clé étrangère, principalement si des suppressions dans la table étrangère sont prévues Si la clé étrangère est la première colonne d'un index existant, il ne faut pas créer d'index spécifique (sauf pour une question de performances si l'index est vraiment très gros, mais le gain est minime sur les volumes traités au Forem). On n'utilisera pas, sauf raison particulière qui le justifie, les clauses ON DELETE CASCADE, ON DELETE SET NULL, ON DELETE SET DEFAULT quand on crée une clé étrangère. On privilégiera le comportement par défaut de SQL Server qui est ON DELETE NO ACTION Unicité Le nom de la contrainte ne peut pas dépasser 128 caractères (limite SQL Server) Le nom de la contrainte sera formé du préfixe 'UX_' suivi du nom de la table et des champs concernés Il est impératif d'avoir un index portant le même nom que la contrainte quand la contrainte vérifie qu'un ou plusieurs champs sont uniques Not Null Pour tous les champs qui ne peuvent pas être nuls, on les renseignera dans le script de création de la table en indiquant "NOT NULL" lors de la définition de la colonne TYPES DE DONNÉES Version du 17/11/2014 Page 41 sur 47 pages Dossier DMP /HTNMMN/EAI

42 Dates Quand il s'agit de stocker une date ou un timestamp, on doit utiliser le type DateTime Le type DateTime2 sera quant à lui choisi s'il est nécessaire d'avoir une précision plus importante (pour rappel, le type DateTime a une précision de 3ms, et ne permet pas le stockage de dates antérieures au 01/01/1753) Si on doit stocker une date qui pourrait ne pas être valide (par ex. 00/00/1977), on doit utiliser le type VarChar(10) en stockant la date au format YYYY-MM-DD Booléens Il faut utiliser le type Bit pour stocker une valeur booléenne. Il devra contenir 0 (false), 1 (true) ou NULL nvarchar(max) au lieu de ntext Il est interdit d'utiliser le type ntext. Ce dernier est obsolète et pose un certain nombre de problèmes. Il faut utiliser nvarchar(max) en ses lieux et places varchar(max) au lieu de Text Il est interdit d'utiliser le type Text. Ce dernier est obsolète et pose un certain nombre de problèmes. Il faut utiliser varchar(max) en ses lieux et places varbinary(max) au lieu de Image Il est interdit d'utiliser le type Image. Ce dernier est obsolète et pose un certain nombre de problèmes. Il faut utiliser varbinary(max) en ses lieux et places. A noter que lorsque l'on doit stocker des fichiers en base de données (qu'il s'agisse d'image ou non), on préfèrera utiliser le typefilestream qui offre plus de souplesses pour les DBA STORED PROCEDURES ET TRIGGERS L'opportunité d'utiliser des stored procedures ou des triggers doit être examinée au cas par cas et nécessite la validation par un architecte. Version du 17/11/2014 Page 42 sur 47 pages Dossier DMP /HTNMMN/EAI

43 11 Standards de développements en matière de sécurité 11.1 Introduction La sécurité des applications doit être un point d'attention constant dans la conception d'une application. Elle ne doit pas être traitée comme un sujet isolé (traité trop souvent en fin de projet), mais s'intégrer à chaque étape de la vie du projet (analyse des besoins, conception, infrastructure, ETC.). Pour la seule problématique du codage, les bonnes pratiques de développement, permettent déjà une bonne prise en charge de la problématique Top 9 des bonnes pratiques à respecter 1. Injection SQL. Ne jamais utiliser de concaténation de String pour la construction d'ordre sql. Toujours passer par une requête paramétrisée. 2. Valider les entrées. Toujours considérer les sources d'entrées comme non sure, particulièrement venant de: data source externe, ligne de commande, interface réseau, variable d'environnement et fichiers de l'utilisateur. 3. Compilateur warnings. Prêter attention aux avertissements du compilateur. 4. Intégrer la sécurité dès l'architecture et le design de l application. 5. Keep it simple. Un design simple est plus facile à comprendre et a potentiellement moins de failles de sécurité cachées. De plus, les failles sont alors plus aisées à corriger. 6. Interdit par défaut. Par défaut, toutes les ressources sont protégées et interdites d'accès, à l'exception des rôles attribués. 7. Principe du moindre privilège. Chaque processus doit être exécuté avec les privilèges minimum à son fonctionnement. Inutile d'octroyer les droits d'administrations. 8. Aseptiser les données envoyées à un autre système. Le système appelé fait confiance à l'application appelante. Il est de la responsabilité de l'application de rendre les données envoyées totalement sure. 9. Pratiquer la défense en profondeur. La gestion des risques de sécurité doit être basée sur plusieurs lignes de défense et non se reposer sur une seule (firewall) Top 10 des failles L OWASP Top Ten project ( liste et explique les failles de sécurité les plus critiques, ainsi que la manière de s en prémunir Application Externe (accessible depuis Internet) Les applications accessibles depuis Internet font l objet de mesures particulières : Le responsable technique organisera une présentation à l attention du responsable de la sécurité et de l architecte afin de démontrer les moyens de sécurité mis en place lors de l implémentation. Seules les fonctionnalités nécessaires seront présentes dans l unité de déploiement. Il est strictement interdit d inclure des fonctionnalités d administration réservées à l usage interne fussent-elles protégée par un mécanisme d authentification. Des tests de charge seront toujours réalisés avant la mise en production. Ils ont pour buts de vérifier : o Que l application supporte la charge attendue (load testing), Version du 17/11/2014 Page 43 sur 47 pages Dossier DMP /HTNMMN/EAI

44 o Que l application n expose, ni les données, ni l infrastructure lors de son effondrement du à une charge excessive (stress testing). Version du 17/11/2014 Page 44 sur 47 pages Dossier DMP /HTNMMN/EAI

45 12 Les types d'environnements applicatifs au DSI Différents types d'environnements sont mis en place pour répondre aux besoins des utilisateurs et du DSI. En règle générale, toute application dispose des 3 environnements suivants : - L'environnement de développement ; - L'environnement d'acceptance ; - L'environnement de production. Sur demande spécifique, et donc pour un nombre restreint d'applications, peuvent être mis en place : - In environnement de formation ; - Un environnement d'intégration Environnement de développement Exclusivement destiné au développement, test et débogage de l'applicatif par les équipes de développeurs Environnement d'acceptance Environnement exclusivement destiné à la réalisation des tests fonctionnels par des intervenants business. Ces tests ont pour but de valider (ou non) le passage en production de la version. Si la version ne passe pas les tests, une nouvelle version corrigée sera fournie et une nouvelle itération de test fonctionnel sera réalisée. IMPORTANT : Dans ce cas, il est important d'éviter l'ajout de nouvelle fonctionnalité et de se limiter dans la mesure du possible à des développements de correctifs. Cette bonne pratique vise à limiter les périodes d'acceptance et garantit une bonne gestion des releases. Dans certains cas particuliers, l'acceptance est également utilisée pour réaliser des tests techniques par les équipes de développement. Dans ce cas, il appartient au Chef de Projet de séquencer les différentes phases de test et de n'autoriser le fonctionnel à entamer ses tests qu'à partir du moment où tous les aspects techniques ont été validés TEC3-MEA : MISE EN ACCEPTANCE L'objectif d'une MEA est uniquement la validation par le fonctionnel que le développement prévu (périmètre de la release) peut être effectivement mis à disposition de tous les utilisateurs (MEP). Par conséquent, toute MEA doit être suivie d'une MEP (après correction des bugs éventuels mais avant tout ajout d'autres fonctionnalités). La période entre la MEA et la MEP doit être relativement courte (dépendant du nombre d'itérations correctives). Version du 17/11/2014 Page 45 sur 47 pages Dossier DMP /HTNMMN/EAI

46 Le délai minimum souhaité entre la demande et la date souhaitée de l'intervention est de 3 jours Environnement de production Environnement exclusivement destiné aux utilisateurs finaux pour supporter leur activité quotidienne TEC3-MEP : MISE EN PRODUCTION Le feu vert pour la MEP est donné par le responsable fonctionnel lorsqu'il valide la dernière version testée en acceptance. A partir de ce moment, le chef de projet introduit une demande de MEP (TEC3-MEP) à l'infrastructure, idéalement 7 jours avant la date souhaitée. Le chef de projet est responsable de la communication de l'intervention aux utilisateurs. Si nécessaire, il prend contact avec la direction Opérations Environnement de formation Environnement destiné uniquement à appuyer la formation des agents à un nouvel outil (ou à une évolution majeure d un outil existant). Il est souvent temporaire et doit donc pouvoir être détruit lorsque le besoin de formation n existe plus. En aucun cas cet environnement ne peut servir d environnement de test fonctionnel. La version déployée sur l environnement de formation doit être équivalente ou directement supérieure (version «+1») à la version en production Environnement d'intégration Environnement exclusivement destiné aux développeurs pour réaliser les tests inter-applicatifs, c'est à dire vérifier que les applicatifs et les services communiquent bien entre eux. Il n'est pas destiné aux tests fonctionnels. Il peut dans certains cas être utilisé par les chefs de projets pour effectuer des démos de présentations aux utilisateurs (particulièrement les démos permettant de démontrer l'intégration inter-applicative). L accès à des applications déployées en intégration par des fonctionnels sera toléré (uniquement pour "se faire une idée" de l'application, et jamais pour y réaliser des tests) mais ne sera pas pris en compte dans la planification d'interventions sur cet environnement. Version du 17/11/2014 Page 46 sur 47 pages Dossier DMP /HTNMMN/EAI

47 L'enchainement des environnements lors d'une release applicative Version "fonctionnelle" = package dont le périmètre fonctionnel est stable. Les évolutions de type "correction" ne sont pas reprises dans le schéma. Le chef de projet communique le numéro de version de la version à déployer pour tout TEC3. Il appartient au chef de projet d'assurer la mise à jour de tous ses environnements, (y compris l'intégration et la formation). Il appartient également au chef de projet de s'assurer de la cohérence inter-applicative lors des mises à jour de son application Version du 17/11/2014 Page 47 sur 47 pages Dossier DMP /HTNMMN/EAI