Visual source Code : installer plugin eslint ===== Serveurs d'application sur son poste de dev ===== * __orchestrator__ : edit --> stage --> publish Je crois que c'est l'integration layer. J'ai pas compris à quoi ça sert et quelle est la relation avec portalServer * __portalServer__ (composants backbase) : Héberge CXP Manager * __contentservice__ : service de gestion de fichiers internes à orange bank. Il héberge des fichiers pdf ou autres, stockés dans une base (? coté backbase ?) qui est un H2 sur son poste et une base oracle sur les environnements. * __serviceLayer__ (le point d'entrée du backend, dans une archi middleware) ===== Backbase : Le CMS ===== UI de gestion : http://localhost:7777/portalserver/cxp-manager Le CXP Manager contient 2 portails : - celui pour le web - celui pour le mobile (ios, android) ==== Concepts ==== Un portail contient des pages qui contienne des widgets ==== Enterprise catalogue et Portal catalogue ==== ? pas sur d'avoir compris, mais je dirai que : * Enterprise Catalogue : contient tous les widgets disponibles dans le CMS * Portail catalogue : contient tous les widgets qu'un portail met à disposition pour construire ses pages ==== Les widgets backbase ==== https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/10518851/Create+a+widget+and+build+it Ce sont des composants angular JS On retrouve dans le dossier d'un widget : * __main.js__ : bootstrap file define : permet de déclarer un module (pour pouvoir l'importer par la suite à partir d'autre composant avec require() ) require( ... ) : permet d'importer en mode lazy d'autres modules ou composants XXX.createModule() : fonction qui fait appel à ng.bootstrap() * __model.xml__ : fichier de conf du widget, visualisable et modifiable dans CXP Manager * __index.html__ : template de démarrage (g:onload="require") ==== Les pages ==== Les pages ne font pas partie du code, mais est décrite dans le CMS. Une page hérite d'une master page. Les widgets sont écrits dans le code. On duplique un widget déjà existant pour le customiser ==== Require.js : Asyncronous Module Dependency Manager ==== Il est utilisé dans angular JS, mais embarqué et transparent à partir d'angular 2. Il permet de charger les différentes dépendences en mode lazy. Voir mon article angular JS Liens : * https://www.startersquad.com/blog/angularjs-requirejs/ * https://www.sitepoint.com/using-requirejs-angularjs-applications/ ===== Backend ===== Service example : * https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/8650873/Web+services ===== GIT ===== https://bitbucket.org/account/user/xmarquis/ssh-keys/ ==== Main process in OB ==== https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/10518745/Configuration+management+git ==== Pull request en détail ==== https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/19988826/Git+What+is+how+to+Pull+Request ==== Rebase ==== https://git-scm.com/book/fr/v1/Les-branches-avec-Git-Rebaser ===== Remarque sur les dev ===== ==== base H2 ==== On utilise des bases h2. On peut les paramétrer comme : * base mémoire * base fichier : leur avantage est de pouvoir les consulter en dehors de l'application Dans le cas où plusieurs serveurs d'application auraient besoin d'une base mémoire, on doit activer le profil maven h2server. Ca permet à mon avis de créer un mini SGBD dédié avec une url que peuvent attaquer les différentes applis. L'url s'obtient quand le serveur h2 est lancé. Exemple : jdbc:h2:tcp://10.31.163.224:9092/mem:test ==== liquibase ==== Il y a 2 instances liquibases : * une pour la prod avec un fichier changeLog-master.xml, lancée avant la validation hibernate * une pour la dev (test) avec un fichier changeLog-master-test.xml, lancée après la validation hibernate J'ai l'impression que la pratique est de mettre la validation hibernate en update quand on est en dev. Ca permet de générer automatiquement les tables des nouvelles entitées et relations. Le liquibase de dev ne sert à priori qu'à injecter des données de test. Ensuite, quand on a fini de développer : on passe la validation hibernate en validate et on créé et on référence les changes logs manquants dans changeLog-master.xml, Ca se fait avec un lancement liquibase generatechangelog qui compare une nouvelle base qu'on a créé en dev (en mode h2server ou peut être fichier), avec la base de prod actuelle. ==== Model métier ==== Il existe des tables de références : https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/20677388/Reference+Data+Model Pour créer de nouvelles référence (et sans doute une nouvelle famille), on crée un truc dans cette page ... Mode opératoire : https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/10518820/How+to+create+a+new+reference+data https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/38404108/Reference+data+id+table ===== Architecture techniques ===== https://osloprojet.atlassian.net/wiki/spaces/OS/pages/75395166/Architecture+Technique https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/39158005/G2S+Production ( Contexte fonctionnel : https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/4751785/Pr+sentation+contexte+et+principes+g+n+raux ) ===== Model métier ===== Tables de références : https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/20677388/Reference+Data+Model https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/10518820/How+to+create+a+new+reference+data ===== Camel ===== http://camel.apache.org/book-getting-started.html https://dzone.com/articles/open-source-integration-apache