xms-ovh-dokuwiki

Table des matières

Serveurs d'application sur son poste de dev
Backbase : Le CMS
Backend
GIT
Remarque sur les dev
Architecture techniques
Model métier
Camel

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 :

Backend

Service example :

* https://osloprojet.atlassian.net/wiki/spaces/OSLO/pages/8650873/Web+services

GIT

https://bitbucket.org/account/user/xmarquis/ssh-keys/

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.