Ministère de l’Enseignement Supérieur et

‫وزارة التعليم العالي والبحث العلمي‬

de la Recherche Scientifique
Institut International de Technologie à Sfax
‫المدرسة العليا الدولية الخاصة للتكنولوجيا بصفا قس‬

Projet de fin d’études

Effectué à

Préparé par

Elleuch Wajih

En vue de l’obtention du diplôme National

D’INGÉNIEUR EN GÉNIE INFORMATIQUE
Intitulé :

PréParation d’une architecture micro-

services Pour le déveloPPement d’un
erp en mode saas

Soutenu le 08 Juillet 2019, devant la commission d’examen :

M. Ahmed Kallel Président

M. Ahmed Jmal Rapporteur

M. Atef Masmoudi Encadrant académique

M. Khaled Baklouti Encadrant Industriel

Année universitaire 2018-2019

Remerciement
Au terme de ce travail, je tiens à exprimer mes vifs remerciements avec un grand plaisir et un
grand respect à mon encadreur Mr Atef Masmoudi, ses conseils, sa disponibilité et ses
encouragements m’ont permis de réaliser ce travail dans les meilleures conditions. Mes
remerciements s’adressent également aux membres de jury pour l’honneur qu’ils m’adressent
en acceptant d’évaluer ce projet. Mes remerciements s’adressent de même à mes encadreurs à
la société « ASM » pour leurs conseils intéressants, leurs encouragements continus, ainsi que
le temps qu’ils m’ont réservé malgré leurs grandes occupations. J’adresse aussi mes
reconnaissances à tous les professeurs et au corps administratif de l’Institut international de
technologie de Sfax (IIT) qui depuis quelques années leurs conseils et leurs connaissances
m’ont bien servi. Je voudrais aussi exprimer ma gratitude envers tous ceux qui m’ont accordé
leur soutien, tant par leur gentillesse que par leur dévouement.

ii
Table des matières
Remerciement .................................................................................................................. ii
Introduction générale ....................................................................................................... 7
Présentation du cadre de projet ........................................................................................ 9
Introduction ................................................................................................................... 10
1 Presentation de l’organisme d’accueil...................................................................... 10
1.1 Les services de ASM ................................................................................................... 11
2 Présentation de projet............................................................................................. 11
3 Etudes de l’existant ................................................................................................. 11
3.1 Critique de l’existant .................................................................................................. 11
3.2 Solutions proposées ................................................................................................... 12
4 Processus de développement et méthodologies agiles ............................................. 13
4.1 Méthodologie agile .................................................................................................... 13
4.1.1 Notion d’agilité ................................................................................................................ 13
4.1.2 Quelques méthodes agiles .............................................................................................. 13
4.1.3 Méthodologie adoptée : SCRUM .................................................................................... 14
Conclusion ...................................................................................................................... 16
Analyse et spécification des besoins................................................................................ 17
Introduction ................................................................................................................... 18
1 Ressources .............................................................................................................. 18
1.1 Environnement matériel............................................................................................. 18
1.2 Moyens de communication ......................................................................................... 18
1.3 Contrôle de version (git) ............................................................................................. 19
1.4 Environnement de développement ............................................................................. 19
1.5 Environnement logiciel ............................................................................................... 22
1.6 Framework ................................................................................................................ 24
1.6.1 Choix de framework Back-end......................................................................................... 24
1.6.2 Choix de Framework Front-end ....................................................................................... 25
2 Spécification des besoins ......................................................................................... 26
2.1 Identification des acteurs ........................................................................................... 26
2.2 Besoins fonctionnels .................................................................................................. 27
2.3 Besoins non fonctionnels ............................................................................................ 27
3 Backlog Produit ....................................................................................................... 28
Conclusion ...................................................................................................................... 29
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services .......... 30
Introduction ................................................................................................................... 31
1 Sprint 1 ................................................................................................................... 31
1.1 Backlog du premier sprint ........................................................................................... 31
1.2 Socle projet Angular ................................................................................................... 31
1.2.1 Modules ........................................................................................................................... 32
1.2.2 Core Module .................................................................................................................... 33
1.2.3 Shared Module ................................................................................................................ 33

iii
 1.2.4 Lazy Loading..................................................................................................................... 33
1.2.5 Angular avec NGRX (PATTERN REDUX) ............................................................................ 33
1.3 Socle projet Spring Boot ............................................................................................. 34
1.3.1 Sous-projet base-core...................................................................................................... 35
2 Sprint 2 ................................................................................................................... 36
2.1 Backlog du deuxième sprint ........................................................................................ 36
2.2 Architecture logique de l’application .......................................................................... 36
2.2.1 Architecture monolithique .............................................................................................. 37
2.2.2 Architecture micro-services............................................................................................. 39
2.2.3 Architecture générale de notre ERP ................................................................................ 40
2.3 Intégration des micro-services .................................................................................... 41
2.3.1 Service de découverte ..................................................................................................... 41
2.3.2 API Gateway..................................................................................................................... 42
2.3.3 API serveur de configuration ........................................................................................... 43
2.4 Communication entre les micro-services.................................................................... 44
2.4.1 Communication synchrone.............................................................................................. 44
2.4.2 Communication asynchrone ............................................................................................ 44
Conclusion ...................................................................................................................... 45
Implémentation des diverses fonctionnalités communes .................................... 46
Introduction ................................................................................................................... 47
1 Sprint 3 ................................................................................................................... 47
1.1 Backlog du troisième sprint ........................................................................................ 47
1.2 Implémentation du protocole Oauth2 avec keycloak. .................................................. 48
1.2.1 Protocole OAuth2 ............................................................................................................ 48
1.2.2 Gestionnaires des identités et des accès........................................................................ 49
1.2.3 Keycloak ........................................................................................................................... 49
1.3 MSRef ........................................................................................................................ 56
1.3.1 Conception....................................................................................................................... 56
1.3.2 Réalisation ....................................................................................................................... 59
2 Sprint 4 ................................................................................................................... 60
2.1 Backlog du quatrième sprint ....................................................................................... 60
2.2 Conception................................................................................................................. 60
2.2.1 Digramme de cas d’utilisation ......................................................................................... 60
2.2.2 Description textuelle ....................................................................................................... 61
2.2.3 Diagrammes de séquence ............................................................................................... 63
2.2.4 Diagrammes de classe ..................................................................................................... 67
2.3 Réalisation ................................................................................................................. 70
Conclusion ...................................................................................................................... 72
Gestion d’intégration continue sur GitLab (devops) ............................................. 73
Introduction ................................................................................................................... 74
1 Backlog du cinquième sprint .................................................................................... 74
2 Devops .................................................................................................................... 74
3 Démonstration logique ............................................................................................ 75
3.1 Versions du code ........................................................................................................ 75
3.2 Phase de construction (Build) ..................................................................................... 76

iv
 3.3 Test unitaire ............................................................................................................... 76
3.4 Déploiement .............................................................................................................. 76
3.5 Test automatique ....................................................................................................... 76
3.6 Déploiement en production ........................................................................................ 77
4 Préparation des conteneurs de déploiement (DOCKER)............................................ 77
5 Démonstration physique ......................................................................................... 79
5.1 Mise en place du pipeline ........................................................................................... 80
5.1.1 Stage check_style ............................................................................................................ 81
5.1.2 Stage unit-test ................................................................................................................. 82
5.1.3 Stage build ....................................................................................................................... 83
5.1.4 Stage docker build ........................................................................................................... 83
Conclusion ...................................................................................................................... 84
Conclusion générale ........................................................................................................ 85
Bibliographie .................................................................................................................. 86

Table des figures

Figure 1. Logo ASM ................................................................................................................ 10

Figure 2. Logo de git ................................................................................................................ 19
Figure 3. Logo Java8 ................................................................................................................ 20
Figure 4. Logo TypeScript ....................................................................................................... 20
Figure 5. Logo HTML .............................................................................................................. 21
Figure 6. Logo CSS .................................................................................................................. 21
Figure 7. Logo MongoDB ........................................................................................................ 22
Figure 8. Logo IntelliJ .............................................................................................................. 22
Figure 9. Logo WebStorm ........................................................................................................ 23
Figure 10. Logo Redmine......................................................................................................... 23
Figure 11. Logo Postman ......................................................................................................... 24
Figure 12. Logo [Link] .......................................................................................................... 24
Figure 13. Logo Spring Boot.................................................................................................... 25
Figure 14. Logo Angular .......................................................................................................... 26
Figure 15. Structure de dossiers Angular ................................................................................. 32
Figure 16. Application monolithique ....................................................................................... 38
Figure 17. Application micro-services ..................................................................................... 39
Figure 18. Architecture général de l’ERP ................................................................................ 41
Figure 19. Interface de service de découverte Eureka ............................................................. 42
Figure 20. API Gateway pattern ............................................................................................... 43
Figure 21. Serveur de configuration ......................................................................................... 43
Figure 22. Flux de protocole OAuth2 ...................................................................................... 49
Figure 23. Courtage d’identité et connexion sociale ................................................................ 51
Figure 24. Création d’un admin ............................................................................................... 53
Figure 25. Création d’un realm ................................................................................................ 53
Figure 26. Configuration du realm ........................................................................................... 54
Figure 27. Ajouter le client erp-app ......................................................................................... 54
Figure 28. Configuration du client erp-app .............................................................................. 55

v
Figure 29. Crée un nouveau mapper ........................................................................................ 56
Figure 30. Diagramme de cas d’utilisation .............................................................................. 57
Figure 31. Diagramme de séquence pour le fonctionnement de MSRef en invoquant la
méthode find ..................................................................................................................... 58
Figure 32. Diagramme de séquence pour le fonctionnement de MSRef en invoquant la
méthode save .................................................................................................................... 58
Figure 33. Diagramme de classe .............................................................................................. 59
Figure 34. Diagramme de cas d’utilisation pour les snapshots et les filtres avancés ............... 61
Figure 35. Diagramme de séquence pour soft-delete ............................................................... 64
Figure 36. Diagramme de séquence pour prendre un snapshot sur la mise à jour ................... 65
Figure 37. Diagramme de séquence pour les filtres avancés ................................................... 66
Figure 38. Diagramme de classe pour prendre un snapshot sur la mise à jour ........................ 67
Figure 39. Diagramme de classes pour la gestion des snapshot............................................. 68
Figure 40. Diagramme de class des filtres avancés .................................................................. 69
Figure 41. Structure JSON pour les filtres avancés ................................................................. 71
Figure 42. Architecture Devops ............................................................................................... 75
Figure 43. Version du code ...................................................................................................... 76
Figure 44. Architecture docker................................................................................................. 77
Figure 45. Architecture CI/CD ................................................................................................. 80
Figure 46. Pipeline ................................................................................................................... 81
Figure 47. Check_style ............................................................................................................. 81
Figure 48. Unit_test .................................................................................................................. 82
Figure 49. Publication d’une image docker eureka-server dans le registry de GitLab ...... 83

Liste des tableaux

Tableau 1. Backlog produit ...................................................................................................... 28
Tableau 2. Backlog du premier sprint ...................................................................................... 31
Tableau 3. Backlog du deuxième sprint ................................................................................... 36
Tableau 4. Tableau comparatif des différentes architectures ................................................... 37
Tableau 5. Synthèse RabbitMq Vs ActiveMq Vs Apache kafka ............................................. 45
Tableau 6. Backlog du troisième sprint .................................................................................... 47
Tableau 7. Backlog du cinquième sprint .................................................................................. 60
Tableau 8. Affinement de cas d'utilisation « update document».............................................. 61
Tableau 9. Affinement de cas d'utilisation « delete document ».............................................. 62
Tableau 10. Affinement de cas d'utilisation « get snapshot on date » ..................................... 62
Tableau 11. Affinement de cas d'utilisation « filter collection data» ....................................... 63
Tableau 12. Backlog du cinquième sprint ................................................................................ 74
Tableau 13. Les intérêts et les avantages de docker ................................................................. 78

vi
Introduction générale
Au cours de ces dernières années, le développement Web a subi plusieurs changements
significatifs. De nouvelles technologies ont apparu en ajoutant plusieurs choix pour construire
des applications Web. De ce fait, coder une application Web aujourd'hui consiste à choisir les
bonnes technologies et la bonne architecture.
Cependant, les entreprises ont aujourd'hui une importante inertie qui les empêche d'intégrer
rapidement les nouveaux techniques et les nouveaux processus. Ses problèmes doivent, donc
être réduits au minimum, car l’indisponibilité immédiate des solutions a des impacts très
préjudiciables sur l’activité et sur la notoriété d’une entreprise.
C’est pour ça qu’on a besoin d’avoir un socle technique, en effet, un socle technique est un
ensemble des Framework, des conventions, d'outils et des procédures qui structurent le
développement d’un projet.
Le socle technique constitue un point de départ de chaque solution proposée par l’entreprise et
dans n’importe quel domaine d’application, à titre d'exemple le socle peut être exploité pour
démarrer un projet de gestion d’une entreprise, une application de processus de recrutement
etc...
Repartir donc, sur un socle bien maîtrisé et performant pour débuter un projet pouvant garantir
le succès, la rapidité et la performance de ce dernier.
C'est dans ce cadre, que se situe notre projet de fin d'études dont le but est de mettre en place
un socle technique javaEE/angular pour ASM qui sera à son tour utilisé pour développer un
ERP. Ce socle a pour objectif de mettre en place des parties et des fonctionnalités communes
entre les divers projets.
Le présent rapport décrit les différentes étapes de notre travail, et il s’articule autour de cinq
chapitres :
 Dans le premier chapitre « Présentation du cadre de projet », nous expliquons le cadre
de projet.
 Dans le deuxième chapitre « Analyse et spécification des besoins », nous determinons
les acteurs du futur système, les besoins fonctionnels, non fonctionnels et le backlog de
produit.
 Dans le troisième chapitre « Préparation d’un socle Spring Boot/Angular pour une
architecture micro-services », nous détaillons les différentes étapes pour implémenter
un socle spring boot/angular.
 Dans le quatrième chapitre « Implémentation des diverses fonctionnalités communes »,
nous expliquons les diverses fonctionnalités qu’on a implémenter au niveau de core du
projet spring boot.
 Dans le dernier chapitre « Gestion d’intégration continue sur GitLab (devops) », nous
détaillons les étapes pour le mise en place d’un pipeline CI/CD.

8
 Chapitre 1
Présentation du cadre de projet

9
Présentation du cadre de projet

Introduction
Le cadre général est une étape très importante dans la réalisation de n’importe quel produit ou
projet informatique. Elle nous permet de capturer les différents processus concernant la réalisation
du notre projet, et de mieux éclaircir les objectifs à réaliser afin d’atteindre le niveau estimé.
Ce chapitre a pour objectif de mettre le projet dans son contexte général. Dans la première
partie, nous donnons une brève présentation de l’organisme d’accueil « ASM » [1] Dans la
deuxième partie, nous présentons le cadre de projet. Enfin, nous exposons les méthodologies
adoptées lors de la réalisation de ce travail.

1 Presentation de l’organisme d’accueil

All Soft Multimédia est une société informatique créée en 2007 et elle est spécialisée dans
l’ingénierie logicielle, la création des sites web et le développement des applications mobile et
les systèmes de vente. Cette société est présentée en trois pays : Tunisie, Algérie et au Sénégal.

Figure 1. Logo ASM

Depuis sa création, ASM conçoit à réaliser et maintenir des services informatiques sur mesure.
C’est pourquoi, elle assure que son travail soit effectué par une ressource humaine certifiée en
ingénierie informatique. Son travail est basé sur un ensemble d’activités, de la conception à la
mise en œuvre, pour réaliser un service informatique, contrôler son bon fonctionnement et son
adéquation au besoin. C’est aussi concevoir, développer et maintenir des applications destinées
au grand public telles que les sites ou portails Web, des sites de commerce électronique... En effet,
ASM analyse et spécifie les besoins et les exigences de ces clients. Par ailleurs, elle les
accompagne aussi dans la création et l’exploitation de nouveaux services.

10
Présentation du cade de projet

1.1 Les services de ASM

Au fur et à mesure d’expérience, ASM a développé et a validé ses outils et méthodes de travail,
afin de son modèle d’organisation réponde aux exigences de ses clients. Elle met à la disposition
de ses clients les services suivants :
 Développement logiciel
 Développement Web et Internet
 Développement pour les mobiles (iPhone, J2ME, BlackBerry, Android, WinCE)
 Développement de solutions SMS et MMS
 Maintenance et Support
 Test et Validation

2 Présentation de projet

Ce projet de fin d’études est réalisé dans le cadre de l’obtention du diplôme national d’ingénieur
en génie informatique à l’Institut international de technologie de Sfax pour l’année universitaire
2018/2019. Ce stage a été effectué au sein de la société ASM, encadré par M. Khaled Baklouti
et dédié à la réalisation du sujet « Préparation d’une architecture micro-services pour le
développement d’un ERP en mode SaaS ».

3 Etudes de l’existant

Dans cette section, nous présentons l’architecture des applications chez ASM ainsi que la
chaîne d’intégration et les processus de déploiement et de livraison, tout en mettant l’accent sur
leurs limites.

3.1 Critique de l’existant

L’ERP existant cher ASM « DUX » est basé sur une architecture monolithique où tous les
composants et les processus métiers de l’application sont développés dans le cadre d’une même
technologie. Ce type d’application est constitué d’un seul bloc de code, et toutes les couches
communiquent entre elles via des appels de méthodes. Ce type d’application s’avère trop
complexe et assez coûteux à faire évoluer. Cette version ne fournit pas des services web,
manque encore d’autres fonctionnalités qui sont utiles pour les prochains projets et présente
certaines lacunes au niveau des performances de l’application. Parmi ces lacunes nous pouvons
citer :

11
Présentation du cade de projet

1. Processus de déploiement chez ASM : Les fichiers sont de taille supérieur à 700 Méga
Octets, leur téléchargement par les clients prend généralement quelques heures. Il
faudra, ensuite, installer l’environnement nécessaire pour le bon fonctionnement de
l’application SQL Server, dot net Framework et réglage de réseaux.
2. Processus de livraison chez ASM : La livraison dans un contexte habituel se fait avec
des scripts manuelles sur l’environnement du client et hors la chaîne DevOps.
3. Absence du monitoring : Le dernier constat, est la visibilité générale de l’état des
systèmes. Actuellement, il n’existe aucun moyen pour ASM pour s’assurer que les
différents environnements (Production, Pré production, Développement) soient en
bonne santé.
4. Absence d’archivage : Absence d’une archive complète de toutes les activités de
l’application, qui permet de suivre le déroulement de chaque activité, comprendre le
fonctionnement de l’application ou résoudre les anomalies.

3.2 Solutions proposées

Après une étude de l’existant chez ASM, et après avoir dégager les problèmes omniprésents,
notre solution consiste à intervenir dans plusieurs volets :
1. Architecture microservices : Afin d’adapter ses applications à la clientèle, ASM doit
migrer toutes ses applications vers l’architecture microservices pour se bénéficier de
l’atout majeur de cette architecture qui est la réutilisation, d’où notre premier objectif,
qui est le développement d’une architecture microservices afin de résoudre plusieurs
problèmes présents dans l’architecture monolithique.
2. Chaîne d’intégration basée sur GitLab : Notre solution intervient aussi dans le
changement de l’outil de gestion de code source dans la chaîne d’intégration continue
chez ASM. Nous allons introduire Git afin de se bénéficier des avantages de GitLab (la
rapidité, une interface plus compréhensible).
3. Déploiement et livraison automatisés : Nous souhaitons déployer automatiquement
tout changement effectué qui a réussi une chaine de tests préalablement mis en place
sur le serveur de pré production (pour le déploiement) et le serveur de production (pour
la livraison).
4. Monitoring : Une fois ces trois pipelines (intégration continue, déploiement continu et
livraison continue) sont mis en place et intégrés entre eux, un tableau de bord permettant
le monitoring et le contrôle des systèmes sera affiché selon les besoins.

12
Présentation du cade de projet

4 Processus de développement et méthodologies agiles

Pour assurer le succès d’un projet, il faut principalement fixer un plan de travail bien détaillé et
bien étudié avant de commencer son développement. La phase de développement doit être
réalisée d’une manière consciencieuse et appliquée, mais l’essentiel ne pas perdre ou modifier
des informations entre le besoin spécifié par le client et ce qui est finalement développé. C’est
pourquoi il est très important de fixer une méthodologie de travail avant le début de tout projet.
Dans le cadre de ce projet, nous nous sommes intéressées à l’adoption d’une approche Agile.

4.1 Méthodologie agile

Une méthode agile [2] est une approche itérative et incrémentale, qui est menée dans un esprit
collaboratif, avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout
en prenant en compte l’évolution des besoins des clients. Ce sont des méthodologies
essentiellement dédiées à la gestion de projets informatiques. Elles reposent sur des cycles de
développement itératifs et adaptatifs en fonction des besoins évolutifs du client.

4.1.1 Notion d’agilité

Le terme agilité désigne des projets qui ont adopté le manifeste agile et qui ont fait usage
d’utilisateurs finaux comme source des exigences donc ils ont utilisé des histoires d’utilisateurs.
Dans le contexte projet, être agile c’est être capable de s’adapter au changement. Que ce soit
des changements de besoins, de priorités, de technologies, ou d’équipe projet.

4.1.2 Quelques méthodes agiles

Les méthodes agiles permettent généralement de mieux répondre aux attentes du client en un
temps limité tout en faisant monter les collaborateurs en compétences. Ces méthodes
constituent donc un gain en productivité ainsi qu’un avantage compétitif tant du côté du client
que du côté du fournisseur.
On citera comme méthodes de développement Agile :
 Scrum
 La méthode XP (Extreme Programming)
 La méthode Kanban

13
Présentation du cade de projet

4.1.3 Méthodologie adoptée : SCRUM

La méthodologie choisie pour la réalisation de ce projet est la méthode SCRUM [3]. Ce choix
est parvenu suite à nos études sur les méthodes agiles car nous avons constaté qu’elle est la plus
utilisée parmi ces méthodes, elle est donc la plus éprouvée, documentée et supportée. En effet,
SCRUM nous offre un cadre de travail en équipes pluridisciplinaires intégrées et soudées dans
une stratégie flexible, léger et simple à comprendre.

[Link] Définition de la méthode SCRUM

SCRUM est une méthode agile dédiée à la gestion de projets. Son objectif est d’améliorer la
productivité des équipes. Elle ne propose aucune pratique de développement, juste des pratiques
de management et d’organisation du travail. SCRUM est la méthodologie la plus utilisée parmi
les méthodes agiles existantes. Elle est considérée comme un Framework ou cadre de travail
permettant de répondre à des problèmes complexes et changeants au cours du temps. Ce cadre
propose une définition des rôles, de réunions et d’artefacts.

[Link] Piliers de SCRUM

SCRUM est un processus qui se base sur l’expérience du terrain. Il s’appuie sur trois piliers :
 Transparence
 Adaptation
 Inspection

[Link] Principes de bases de SCRUM

En appliquant SCRUM il faut suivre les étapes suivantes :

1. Dégager le maximum des fonctionnalités à partir des histoires d’utilisateurs

pour former le backlog du produit.
2. Définir les priorités des fonctionnalités et choisir lesquelles seront réalisé dans
chaque sprint.
3. Divisez notre travail en une liste de petits livrables concrets.

4. Focaliser l’équipe de façon itérative sur l’ensemble de fonctionnalités à réaliser,

dans des itérations appelées Sprints.
5. Divisez le temps en petites itérations de durée fixe (appelées des sprints et

14
Présentation du cade de projet

durant habituellement de 2 à 4 semaines) et faites une démonstration à l’issue de

chaque sprint avec un produit potentiellement livrable appelé incrément.

6. Optimisez le planning de la version et mettez à jour les priorités en collaboration

avec le client, sur la base de ce que nous avons appris après chaque sprint.
7. Optimisez le processus en organisant une rétrospective après chaque sprint.

[Link] Les acteurs principaux du SCRUM

La méthode SCRUM définit 3 acteurs principaux :

 Product Owner : est responsable de maximiser la valeur du produit et du travail de
l’Équipe du Développement. Il porte la vision du produit à réaliser (représentant
généralement le client).
 Scrum master : est un leader au service de l’Équipe SCRUM. Il aide tout le monde à
changer ces interactions pour maximiser la valeur créée par l’Équipe SCRUM.
 SCRUM Team : Tous les membres de l’équipe apportent leur savoir-faire pour
accomplir les tâches

[Link] Processus de réalisation

SCRUM comporte 4 étapes importantes qui vont être effectuées pour chaque Sprint :
 Sprint Planning : toute l’équipe se réunit pour décider des fonctionnalités qui vont
composer le sprint suivant et mettre à jour la liste générale.
 Le SCRUM quotidien : est effectué pour identifier les problèmes rencontrés et pour
répondre à 3 questions essentielles :
o Qu’est-ce que j’ai fait hier ?
o Qu’est-ce que je fais aujourd’hui ?
o Quels sont les problèmes rencontrés ?
 Sprint Review : à la fin du sprint, l’équipe SCRUM et les parties prenantes invitées se
réunissent pour effectuer la revue de sprint. L’objectif de celle-ci est de valider
l’incrément de produit qui a été réalisé pendant le sprint.
 Rétrospective du sprint : Cette étape s’effectue à chaque fin de Sprint. Elle a pour objectif
de réfléchir régulièrement à ce qui marche et ce qui ne marche pas. Pour cela l’équipe
prend en général 15 à 30 minutes pour se réunir et faire un point.

15
Présentation du cade de projet

Conclusion
Dans ce chapitre, nous avons commencé avec la présentation de l’organisme d’accueil dans
lequel nous avons effectué notre projet de fin d’études. Puis, on a décrit la méthodologie de
conduite de projet adoptée. Dans le chapitre suivant, on entame la partie analyse et spécification
des besoins.

16
 Chapitre 2
Analyse et spécification des besoins

17
Analyse et spécification des besoins

Introduction
Ce chapitre présente le sprint zéro qui représente le premier pas de réalisation de notre projet.
Tout d’abord, nous donnons un bref aperçu sur les technologies et les langages de programmation
utilisés pour la mise en place de l’environnement de travail. Puis, nous identifions les acteurs
de notre application. En fin, nous listons les besoins fonctionnelles et non fonctionnelles de notre
système et nous détaillons le travail par la méthodologie choisie dans le chapitre précédent.

1 Ressources

Nous présentons dans cette section les choix techniques relatifs à l’environnement matériel et
logiciel qui ont contribué à la mise en place de notre socle technique.

1.1 Environnement matériel

Durant le projet, le travail a été réalisé sur un ordinateur qui présente les caractéristiques
suivantes :
Processeur: Core i7 2.70GHz × 4
Mémoire RAM: 12GB
Type système: 64 bits
Disque Dur: 1 TB
System d’exploitation: Ubuntu 18.04.2 LTS

1.2 Moyens de communication

En travaillant dans la même salle de développement, ou en étant connecté avec différents moyens
de communication, l’équipe peut facilement partager des documents et échanger les informations
nécessaires. Parmi les moyens de communication :
 Chaque journée de travail commence par une réunion de 15 minutes
 Discuter de tout obstacle et partager les solutions dans le groupe Mattermost
 Nous clôturons la journée de travail avec un texte dans le groupe de "réunion"
Mattermost pour le suivi quotidien
 Une réunion toutes les deux semaines

18
Analyse et spécification des besoins

1.3 Contrôle de version (git)

Git [4] est un système de contrôle de version distribué gratuit et open source conçu pour gérer
efficacement les projets de toutes tailles avec rapidité et efficacité. Git est facile à apprendre et a
une empreinte minuscule avec excellentes performances.

Figure 2. Logo de git

1.4 Environnement de développement

Nous énumérons au cours de cette partie les différents outils et technologies employés tout au
long de la réalisation de notre projet.

JAVA 8 :
Java 8 [5] C’est la 8ème version de JAVA (JAVA SE 8) un langage de programmation orienté
objet. La particularité et l’objectif central de Java est que les logiciels écrits dans ce langage
doivent être très facilement portables sur plusieurs systèmes d’exploitation tels que Unix,
Windows, Mac OS ou GNU/Linux, avec peu ou pas de modifications. Pour cela, divers
plateformes et Framework associés visent à guider, sinon garantir, cette portabilité des
applications développées en Java.

19
Analyse et spécification des besoins

Figure 3. Logo Java8

TypeScript :
TypeScript [6] est un langage compilé et typé qui génère du JavaScript compréhensible par tous
les navigateurs. TypeScript permet d’associer un type à un élément et empêche cet élément de
changer de type. Cela offre une stabilité au niveau du code, dès lors il est possible d’anticiper
le type d’un élément, et ses différentes valeurs possibles.

Figure 4. Logo TypeScript

HTML:
L’HyperText Markup Language, généralement abrégé HTML, est le langage de balisage conçu
pour représenter les pages web. C’est un langage permettant d’écrire de l’hypertexte, d’où son
nom. HTML permet également de structurer sémantiquement et logiquement et de mettre en
forme le contenu des pages, d’inclure des ressources multimédias dont des images, des
formulaires de saisie et des programmes informatiques. Il permet de créer des documents

20
Analyse et spécification des besoins

interopérables avec des équipements très variés de manière conforme aux exigences de
l’accessibilité du web.

Figure 5. Logo HTML

CSS :
Les feuilles de style en cascade1, généralement appelées CSS de l’anglais Cascading Style
Sheets, forment un langage informatique qui décrit la présentation des documents HTML et
XML. Les standards définissant CSS sont publiés par le World Wide Web Consortium (W3C).
Introduit au milieu des années 1990, CSS devient couramment utilisé dans la conception de
sites web et bien pris en charge par les navigateurs web dans les années 2000.

Figure 6. Logo CSS

MongoDB :
MongoDB [7] (de l’anglais humongous qui peut être traduit par « énorme ») est un système de
gestion de base de données orientée documents, répartissable sur un nombre quelconque
d’ordinateurs et ne nécessitant pas de schéma prédéfini des données.

21
Analyse et spécification des besoins

Figure 7. Logo MongoDB

1.5 Environnement logiciel

IntelliJ IDEA :
Pour développer ce projet, nous avons utilisé IntelliJ IDE, un logiciel de développement
multiplateformes développé par JetBrains. Sa dernière version est appelée IntelliJ IDEA 2019.
L’IntelliJ IDEA est un ensemble complet d’outils de développement permettant de générer des
applications Web Spring, des services Web XML, des applications de bureau et des applications
mobiles.

Figure 8. Logo IntelliJ

JetBrain WebStorm :
WebStorm est un IDE pour les langages Web (HTML, CSS et JavaScript), développé par
l’entreprise JetBrains et basé sur la plateforme IntelliJ IDEA. L’éditeur offre diverses
fonctionnalités y compris éditeur javaScript, débogueur, prise en charge de [Link] comme il
supporte le langage typescript, Dart.

22
Analyse et spécification des besoins

Figure 9. Logo WebStorm

Redmine :
Redmine est un outil collaboratif permettant, à travers une interface web sécurisée, de gérer des
projets. Il a été créé par Jean-Philippe Lang en 2006. Redmine offre les fonctionnalités
suivantes :
 Gestion multi-projets sécurisée
 Gestion des utilisateurs, des profils et des droits, en fonction de chaque projet
 Gestion de documents, classement par catégorie, propriétaire, titre, date, etc
 Gestion des demandes, de leur statut, de leur priorité et de leur historique, assignation
de ces demandes aux acteurs pertinents du projet.

Figure 10. Logo Redmine

Postman :
Pour tester nos services Web avant de les appeler dans le code de l’application, nous avons utilisé
Postman, un outil permettant de créer et de tester rapidement des requêtes HTTP. Il permet
l’exécution d’appels HTTP vers un serveur pour interpréter la réponse.

23
Analyse et spécification des besoins

Figure 11. Logo Postman

[Link] :
[Link] pro est une application création de diagrammes compatible avec Google Drive(TM) et
entièrement gratuite nous permettant de dessiner : Des organigrammes, des diagramme UML
et Business Process Models . . .

Figure 12. Logo [Link]

1.6 Framework

1.6.1 Choix de framework Back-end

Avec une architecture Microservices, chaque Microservice peut être développé avec une
technologie différente. En raison de l’expérience de l’équipe, Nous avons décidé de développer
les Microservices avec la technologie Java/JEE. Par ailleurs, il existe trois Framework
populaires pour développer une application en Microservices : Dropwizard, Spring et WildFly
Swarm. Dans notre étude, nous somme intéressé seulement au Framework le plus mature Spring
Boot.

24
Analyse et spécification des besoins

Figure 13. Logo Spring Boot

C’est un Framework java créé par l’équipe Pivotal qui permet de simplifier le démarrage et le
développement de nouvelles applications Spring en réduisant la complexité de configuration.
Spring Boot [7] offre les avantages suivants :
 Faciliter la création des applications Spring
 Offrir un serveur d’application intégré (Tomcat, Jetty), donc nous n’avons pas besoin
de la déployer en tant que fichier war.
 Fournir un "starter" POM pour simplifier la configuration Maven.
 Pas de fichiers XML à configurer.

1.6.2 Choix de Framework Front-end

En raison de l’expérience de l’équipe, Nous avons décidé d’utiliser le Framework Angular. Par
ailleurs, il existe trois Framework populaires : Angular, VueJs et React. Dans notre étude, nous
nous somme intéressé seulement au Framework Angular.

Angular [8] est une plate-forme qui facilite la création d’applications Web. Angular combine
des modèles déclaratifs, une injection de dépendance, un outillage de bout en bout et des
meilleures pratiques intégrées pour résoudre les problèmes de développement.

25
Analyse et spécification des besoins

Figure 14. Logo Angular

2 Spécification des besoins

Dans cette section, nous définissons en détails l’ensemble des fonctionnalités offertes par notre
application. Nous commençons par l’identification des acteurs suivie par la présentation des
besoins fonctionnels relatifs à ces acteurs ainsi que les besoins non fonctionnels.

2.1 Identification des acteurs

Pour notre système, nous avons identifié plusieurs acteurs :

 Développeur : c’est un consommateur de GIT, il peut déposer ou récupérer un code sur
le dépôt, c’est le premier acteur à déclencher le pipeline.
 Administrateur : Il possède tous les droits. Il est le seul qui peut faire la gestion globale
du système. Il assure la gestion des utilisateurs, des rôles, des logs, etc.
 Client : Il possède tous les droits. Celui qui fait les dernières validations avant la mise
en production, il devra disposer d’une URL de production qui le fait accéder à
l’application.
 Chef de projet : c’est l’utilisateur concerné par le monitoring, il dispose d’un dashboard
qui lui permet de connaître l’état actuel de tout le cluster.
 Responsable technique: c’est un acteur qui intervient dans la phase du test du logiciel
donc il intervient dans la validation des snapshots dans un premier temps puis des releases
au plus tard.
 Ingénieur DevOps : il intervient dans la phase de configuration du système et a pour rôle
la mise en place de la chaîne DevOps. Notre système inclut aussi certains composants
comme étant des acteurs secondaires :

26
Analyse et spécification des besoins

- Git : c’est un gestionnaire de versions de code, il permet de stocker le code et de

l’exposer aux différents développeurs.
- Serveur d’intégration continue : c’est un orchestrateur et un outil important dans
l’intégration continue, il permet de déclencher des builds.
- Serveur de gestion d’infrastructure : il permet de lancer des scripts sur les
environnements de Préprod/Prod afin de régler ces derniers et y déployer le
code.

2.2 Besoins fonctionnels

Notre Projet ayant comme objectif l’implémentation d’une architecture en microservices pour
développer un ERP, en plus de plusieurs autres fonctionnalités qui visent à minimiser le rôle
technique du développeur pour se concentrer uniquement au métier.
Les fonctionnalités dont le système doit assurer :
 La livraison et le déploiement continus de grandes applications complexes.
 Localisation d’un service : lorsqu’un client veut faire une requête vers un service,
ce dernier doit être facilement localisé. (Par la définition d’un seul point d’entrée au
système).
 Communication entre les services.
 Environnement de sécurité avec le protocole oauth2
 Interface de filtrage de données avancée.
 Automatiser la sauvegarde et la récupération de documents d'autres micro-services.
 Gestion des snapshots.

2.3 Besoins non fonctionnels

Certains besoins ne sont pas indispensables pour le fonctionnement de l’application, néanmoins

ils sont importants pour la qualité de ses services. Ces derniers représentent les besoins non
fonctionnels qui agissent de façon indirecte sur le résultat et sur le rendement de l’utilisateur.
Les principaux besoins non fonctionnels de l’application se résument dans les points suivants :
 La rapidité du traitement : il est impérativement nécessaire que la durée d’exécution
des traitements s’approche le plus possible du temps réel.
 La sécurité : une authentification est exigée lors du démarrage pour accéder et effectuer
les opérations désirées.

27
Analyse et spécification des besoins

 La maintenabilité et la scalabilité : le code de l’application doit être clair pour

permettre de futures évolutions ou améliorations.

3 Backlog Produit

Le Backlog est un artéfact très important dans SCRUM. C’est l’ensemble des caractéristiques
fonctionnelles ou techniques qui constituent le produit souhaité. Le tableau 2 présente le
backlog de notre produit.

ID qui représente l’identifiant de la user story. User Story comporte la description des user story
suivant le forme « En tant que . . . Je veux . . . ». L’estimation comporte la valeur de la durée
estimée pour terminer la user story selon la complexité.
Tableau 1. Backlog produit

Id User Story Estimation Sprint

1 En tant que développeur, je veux une architecture du socle 9 jours 1
du projet Angular
2 En tant que développeur, je veux faciliter la manipulation de
données entre les composants et service ANGULAR et les
centraliser dans un objet global.
3 En tant que développeur, je veux une architecture du socle
du projet Spring
4 En tant que développeur, je veux pouvoir prépare 9 jours 2
l’architecture micro service
5 En tant que développeur, je veux pouvoir implémenter un
service de découvert (Eureka server)
6 En tant que développeur, je veux pouvoir
implémenter un service de configuration (Config server)
7 En tant que développeur, je veux pouvoir
implémenter une passerelle (Zuul Gateway)
8 En tant que développeur, je veux pouvoir une commination
asynchrone

28
Analyse et spécification des besoins

9 En tant que développeur, je veux pouvoir implémenter le 14 jours 3

protocole OAuth 2.0 avec Spring Security et keycloak
10 En tant que développeur, je veux pouvoir récupérer les
informations de l'utilisateur à partir du keycloak token
11 En tant que développeur, je veux pouvoir implémenter le
protocole OAuth 2.0 avec Angular et keycloak
12 En tant que développeur, je veux une implémentation du
multi tenancy
13 En tant que développeur, je veux pouvoir automatiser la
sauvegarde et la récupération de documents d'autres micro-
services.
14 En tant qu'administrateur, je veux avoir une 14 jours 4
visibilité sur l'historique des documents.
15 En tant qu'administrateur, je veux avoir une
visibilité sur les documents supprimer.
16 En tant que développeur, je veux une interface de filtrage de
données avancée
17 En tant que développeur, je veux mettre en place 9 jours 5
l’intégration continue
18 En tant que développeur , je veux mettre en place le pipeline
19 En tant que développeur , je veux automatiser les test
20 En tant que développeur , je veux automatiser le déploiement
21 En tant que développeur , je veux préparer les conteneur
docker

Conclusion
Dans ce chapitre nous avons décrit les acteurs, les besoins fonctionnels, non fonctionnels et le
Backlog produit. Dans le chapitre suivant, on entame la partie de la mise en place de notre
architecture.

29
 Chapitre 3
Préparation d’un socle Spring Boot/Angular
pour une architecture micro-services

30
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

Introduction
Dans ce chapitre nous visons à détailler les deux premiers sprints dans le but d'implémenter un
socle spring boot/angular et la mise en place de l'architecture micro-services.

1 Sprint 1

1.1 Backlog du premier sprint

Tableau 2. Backlog du premier sprint

ID Tâche Estimation
1 En tant que développeur, je veux une architecture du socle du 9 jours
projet Angular
2 En tant que développeur, je veux faciliter la manipulation de
données entre les composants et service ANGULAR et les
centraliser dans un objet global.
3 En tant que développeur, je veux une architecture du socle du
projet Spring

La réalisation peut être présentée en deux parties :

 Mise en place d’un socle pour un projet Angular
 Mise en place d’un socle pour un projet Spring Boot

1.2 Socle projet Angular

Dans le but d’avoir une structure de dossiers hautement évolutive pour notre projet Angular on
a appliqué l’architecture suivante présenter par la figure 15.

31
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

Figure 15. Structure de dossiers Angular

1.2.1 Modules

Un module Angular est un mécanisme permettant de :

 Regrouper des composants (mais aussi des services, directives, pipes etc.…).
 Définir leurs dépendances.
 Définir leur visibilité.

32
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

1.2.2 Core Module

CoreModule assume le rôle de racine AppModule, mais n’est pas le module qui est démarré
par Angular au moment de l’exécution. Le CoreModule doit contenir des services singleton des
composants universels et d’autres fonctionnalités dans lesquelles il n’y a qu’une seule instance
par application par exemple (footer, header, interceptors, etc). Pour éviter de réimporter le
module principal ailleurs, nous avons également lui ajouter une protection dans le constructeur
du module principal.

1.2.3 Shared Module

Le SharedModule est l'endroit où on a créé les composons réutilisable. Le SharedModule peut

être importé dans n'importe quel autre module lorsque ces éléments seront réutilisés. Le module
partagé ne devrait pas dépendre du reste de l’application et ne devrait donc pas dépendre d’un
autre module.

1.2.4 Lazy Loading

L’application utilise le chargement paresseux, ce qui signifie que le module n’est pas chargé
avant que l’utilisateur n’accède à la route. En utilisant la structure décrite dans la section
« Modules », nous pouvons facilement référencer chaque module dans notre fichier de routage
d'application principal.

1.2.5 Angular avec NGRX (PATTERN REDUX)

NGRX propose une conception du développement d’applications qui tourne autour des actions
utilisateurs et serveur. L’objectif est de supprimer la manipulation de données entre les
composants et service Angular pour les centraliser dans un objet global, qu’on pourra modifier
seulement via des actions typées.

[Link] Redux

Redux est un pattern né de FLUX, une architecture créée par Facebook. Il

apporte un workflow de données unidirectionnelles grâce à un dispatcher, qui recueille des

33
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

actions distribuées par le serveur ou par l’utilisateur. Il conserve la nouvelle instance d’une
donnée dans un ou plusieurs stores qui mettent à jour la vue.
Redux est une version moins complexe de Flux. Il se distingue en plusieurs points :
 Un store, donc une source de données.
 Des états immuables (qui ne peuvent changer).
 Pas de dispatcher.

[Link] Le store, la base de tout

Le store est une fonction qui contient l’état des reducers, un getter, une fonction de dispatch et
des subscribers. Elle utilise les Observables pour communiquer la mise à jour des états dans les
composants Angular.

1.3 Socle projet Spring Boot

Spring Boot est un Framework java qui facilite la création d'applications basées sur Spring en
offrant plusieurs fonctionnalités :
 Spring Initializr : un outil qui fournit des projets Spring boot en générant les fichiers
de base d’un projet. Cet outil expose une interface web et une interface incluse dans des
IDE comme Intellij Idea, STS et NetBeans.
 Serveur intégré : Tomcat, Jetty ou Undertow est déjà intégré dans une application
Spring boot.
 Auto-configuration : Spring boot est basée sur le principe que la convention plutôt
que configuration. Il utilise les conventions pour configurer par défaut l’application en
se basant sur les dépendances incluses dans le Classpath. Cette configuration est non
invasive, nous pouvons définir notre propre configuration pour remplacer des parties de
la configuration automatique. Toutefois, en ajoutant une configuration d’une
dépendance, la configuration automatique de cette dernière sera ignorée.
 Fonctionnalités de production : des fonctionnalités de production peuvent être
directement en marche.

34
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

1.3.1 Sous-projet base-core

Vue qu’on veut implémenter une architecture micro-services il faut penser à une architecture
qui permet de partager les fonctionnalités communes entre les différents services. C’est pour ça
on a créé un sous projet de classe sans classe principale, avec toutes les configurations, classes
et dépendances communes entre les microservices. Le sous-projet est situé dans le git et inclus
dans les micro-services à l’aide de gradle.

[Link] Couche Dao

Le rôle de cette couche est d’assurer la communication avec la base de données. Nous avons
décidé de modifier le fonctionnement de couche dao qui était offert par Spring Framework pour
ajouter des fonctionnalités ciblées. En étudiant le fonctionnement du projet Spring Data
MongoDB on a conclu que nous devons réimplémenter seulement la classe
SimpleMongoRepository qui offre par défaut l’implémentation des méthodes d’ajout, de
modification, de suppression et de consultation des données. Notre réimplémentation ajoute
aux méthodes de cette classe les fonctionnalités suivantes :

 Falsifier la suppression des entités en remplaçant la suppression réelle par une

suppression virtuelle. L’entité sera indiquée comme supprimé et elle ne s’affiche plus
dans l’application, mais réellement elle reste sauvegardée dans la base de données.
 Modifier toutes les méthodes de récupération pour ajouter à la requête la condition de
ne pas récupérer les entités supprimées et modifiées.
 Modifier les méthodes de modification pour garder un snapshot a l’état précédente de
l’entité.
 L’ajout des méthodes de consultation qui permet à convertir les objets de filtrage en des
requêtes.

[Link] Couche service

Le rôle de cette couche est d’implémenter les fonctionnalités supplémentaires avant de les
passer vers le contrôleur. Ce code peut être une validation ou des calculs personnalisés. Dans
ce cadre, nous implémentons une classe générique de cette couche qui offre des méthodes

35
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

d’insertion, de modification, de suppression et de consultation basiques en se basant sur la

description de l’entité.

2 Sprint 2

2.1 Backlog du deuxième sprint

Tableau 3. Backlog du deuxième sprint

ID Tâche Estimation
4 En tant que développeur, je veux pouvoir prépare l’architecture 9 jours
micro-services
5 En tant que développeur, je veux pouvoir implémenter un
service de découvert (Eureka server)
6 En tant que développeur, je veux pouvoir
implémenter un service de configuration (Config server)
7 En tant que développeur, je veux pouvoir
implémenter une passerelle (Zuul Gateway)
8 En tant que développeur, je veux pouvoir une commination
asynchrone

2.2 Architecture logique de l’application

Les micro-services sont un style d’architecture logicielle à partir duquel un ensemble complexe
d’applications est décomposé en plusieurs processus indépendants et faiblement couplés,
souvent spécialisés dans une seule tâche.
 Les processus indépendants communiquent les uns avec les autres en utilisant des API.
 Les API REST sont souvent employées pour relier chaque micro-service aux autres.
Avec cette architecture chacun peut pratiquer ses propres traditions de développement. En effet
il ne s’agit pas de séparer les gros projets en sous-projet mais de projets indépendants, chacun
a son organisation, son calendrier, sa base de code et ses données ce qui n’est pas le cas d’une
architecture monolithique. Les échanges entre les projets se font par des services, qu’il s’agisse
d’appels de services (REST / JSON) ou de messages.

36
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

Le tableau 4 décrit les principaux avantages de l’architecture micro-services par rapport à

d’autres architectures :
Tableau 4. Tableau comparatif des différentes architectures

Architecture Micro-services Monolithique Modulaire

Liaison des services Faiblement liés Fortement liés Fortement liés
Mise à jour Simple Compliqué Simple
Langages Multiples Une seule langage Une seule langage

2.2.1 Architecture monolithique

Une application monolithique est une application qui, centralise tous les besoins, dans un seul
bloc applicatif, où toutes les couches communiquent entre elles par des appels de méthodes et
elle est réalisée avec une seule technologie. La figure 16 illustre l'architecture monolithique.
C’est vrai que ces applications sont un modèle simple à coder et à déployer surtout pour les
développeurs mais la difficulté ici s’impose notamment dans la maintenance. Nous consacrons
particulièrement le paragraphe suivant pour l’étude des limites qu’une application monolithique
peut présenter.

37
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

Figure 16. Application monolithique

[Link] Limites de l’architecture monolithique

Tout système informatique devra garantir son évolutivité et sa maintenabilité, surtout que les
besoins et les exigences fonctionnelles du client se développent au fur et à mesure. Dans une
application classique, tout changement nous conduira vers un système plus complexe. Encore
plus, pour chaque modification nous devrons accéder, dans certains cas, tout le système et relire
presque tout le code ce qui affecte généralement la qualité de code d’une part et rend la
maintenance difficile et pénible pour l’ingénieur d’autre part. Nous pouvons aller plus loin que
ceci, après cette modification, nous devrons tout redéployer parce que notre monolithique est
un seul bloc applicatif, donc tout changement, même s’il est minime, conduira à un déploiement
complet de toute l’application.
C’est vrai que, les architectures classiques ont fait leurs preuves dans plusieurs projets, mais à
un moment donné elles deviennent trop coûteuses à faire évoluer d’où l’essor d’un style
architectural : les micro-services qui répond idéalement à cette problématique.

38
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

2.2.2 Architecture micro-services

L’approche micro-services est une approche qui est totalement différente des applications
monolithiques dans la conception, le développement et aussi dans le déploiement. En effet, une
architecture micro-services est un style architectural logiciel qui décompose les applications
complexes en des processus élémentaires, spécialisés pour une seule fonctionnalité.
La décomposition des processus dépend bien évidemment du métier de l’application et de sa
complexité. Ce design est apparu pour résoudre les problèmes que présentent les applications
monolithiques, décrits dans le paragraphe précèdent.
En explosant le monolithique, l’application devient une série de services indépendants, chacun
codé par le langage le plus adéquat, testé et déployé indépendamment des autres. Ces services
sont des entités communicantes via des API. Et c’est ici que l’enjeu de l’architecture micro-
services persiste, c’est à dire que la décomposition en un ensemble d’unités fonctionnelles joue
un rôle majeur dans la réussite d’une telle conception. La figure 17 illustre l'architecture micro-
services.

Figure 17. Application micro-services

39
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

[Link] Caractéristiques des micro-services

La principale caractéristique des micro-services est qu’ils sont des unités fonctionnelles
logiques de grande précision, chacun exprime un processus autonome, responsable d’une seule
fonctionnalité. Et par conséquent, il sera facile de détecter et de remplacer un service défectueux
sans perturber les autres services.
Les micro-services se distinguent aussi par leur exploitation des capacités des différentes
technologies dans une seule architecture micro-services pour, bien évidemment, réaliser des
fins spécifiques. En fait, grâce à l’isolation des services nous pouvons basculer facilement d’une
technologie à une autre.
L’architecture micro-services permet sans peine une mise à l’échelle, ce que les architectes
estiment un avantage capital de ce style architectural. En effet, lorsqu’un besoin critique en une
ressource s’aperçoit, seul le micro-service lié sera augmenté. Contrairement aux applications
classiques où la mise à l’échelle est couteuse.

2.2.3 Architecture générale de notre ERP

Après avoir étudié les avantages du choix technique d’utiliser une architecture de micro-
services, nous devons avoir une vision globale de l’architecture cible et leur son
fonctionnement. La figure 18 illustre l’architecture qui résume la structure technique de
l’application.

40
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

Figure 18. Architecture général de l’ERP

2.3 Intégration des micro-services

2.3.1 Service de découverte

Dans une architecture micro-services les services doivent se trouver et communiquer les uns
avec les autres. C’est le service de découverte qui gère la façon d’enregistrement et de

41
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

localisation des micro-services déployés. Nous avons choisi le service de découverte Eureka
2.0 de Netflix qui est un Framework de service de découverte conçu pour les déploiements
Cloud. Eureka est un système très stable.
Les instances des micro-services enregistrés chez le service de découverte Eureka sont présenté
par la figure 19.

Figure 19. Interface de service de découverte Eureka

2.3.2 API Gateway

Une architecture en micro-services implique l’utilisation de plusieurs services qui peuvent

changer ou modifier d’emplacement. Cette charge ne doit pas apparaitre aux clients. Pour
assurer la transparence entre le partitionnement en micro-service et la navigation de client nous
avons utilisé le patron API Gateway.
Comme le montre la figure 20, l’API Gateway est le point d’entrée de l’application, le client ne
doit savoir que son adresse et elle se charge de le router vers le micro-service qui répond à son
besoin en toute transparence. L’API Gateway est loin d’être un orchestrateur elle fournit des
façades vers les micro-services.

42
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

Figure 20. API Gateway pattern

2.3.3 API serveur de configuration

Un serveur de configuration encore appelé "Config Server" qui permet de centraliser les fichiers
des configurations de chaque micro-service dans un simple dépôt Git. Ceci permet d’avoir une
configuration partagée et évolutive indépendamment des applications. Au démarrage, chaque
micro-service récupère ses propriétés et sa configuration auprès du serveur de configuration
comme le montre la figure 21.

Figure 21. Serveur de configuration

43
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

2.4 Communication entre les micro-services

Les micro-services sont autonomes. Mais, ils ont besoins d’échanger des données pour réaliser
quelques fonctionnalités. Dans une architecture en micro-services chaque micro-service gère
ses propres données et ne les partage pas directement avec d’autres services. C’est pourquoi
nous avons réalisé des intercommunications synchrones via des protocoles ouverts et
asynchrones via un service de file d’attente de messages.

2.4.1 Communication synchrone

Spring Cloud offre trois façons d’appels clients Rest :

- Une façon traditionnelle en utilisant Rest Template : Le problème avec cette
méthode est que le micro-service client de l’API doit connaitre l’adresse complète de
micro-service producteur.
- Rest Template avec Eureka : Netflix ruban fournit une bibliothèque pour faire des
appels REST qui résout le problème de connaissance d’hôte en se basant sur le service
d’annuaire Eureka. Le problème avec cette solution et que la configuration reste
complexe.
- Une façon simplifiée avec Netflix Feign et Eureka : Cette solution offre un rendu de
performance pareil qu’avec ribbon avec une interface simple et des annotations
paramétrées.

2.4.2 Communication asynchrone

Un micro-service dans l’ERP nécessite des données métiers à partir d’un autre micro-service
pour compléter le traitement. En raison des exigences de temps de réponse pour ce micro-
service nous avons favorisé les communications asynchrones. Afin de choisir le service de file
d’attente de message le plus adéquat nous avons réalisé plusieurs recherches sur les leaders de
marché. Nous avons constaté la performance de rabbitMq par rapport à activeMq et la
performance d’Apache Kafka par rapport à rabbitMq ceci est présenté dans le tableau 5.
Cependant, l’utilisation de système de messagerie distribué Apache Kafka nécessite une
utilisation de service de découverte d’Apache « Zookeeper ». Ce service permet aux instances
Kafka de communiquer entre eux. Par conséquent, nous avons utilisé le service de file d’attente
Apache Kafka qui répond suffisamment aux besoins.

44
Préparation d’un socle Spring Boot/Angular pour une architecture micro-services

Tableau 5. Synthèse RabbitMq Vs ActiveMq Vs Apache kafka

RabbitMq ActiveMq Apache Kafka

Envoi de messages 8sec 45min59 3sec
(100 000)
Réception des 5sec 48sec 2sec
messages (100 000)
Taux d’envoi 25000/s 60/s 55000/s
Taux de 30000/s 8000/s 65000/s
consommation
Mémoire utilisé pour 40Mb/s 120Mb/s 20Mb/s
l’envoi
Mémoire utilisé pour 25Mb/s 120Mb/s
l’édition
latence [0-16ms] 0

Conclusion
Dans ce chapitre nous avons préparé l’architecture du socle Spring Boot /Angular ainsi que
l’architecture micro-services. Dans le chapitre suivant nous allons implémenter les différentes
fonctionnalités communes pour tous les micro-services.

45
 Chapitre 4

Implémentation des diverses fonctionnalités

communes

46
Implémentation des diverses fonctionnalités communes

Introduction
Dans ce chapitre, est après avoir implémenté un socle spring boot/angular, nous visons à
détailler le troisième et le quatrième sprint qui ont pour objectif de mettre en place un système
d’authentification avec keycloak, automatiser les sauvegardes et les récupérations des données
d’autre micro-services et la gestion des snapshot et des évènements.

1 Sprint 3

1.1 Backlog du troisième sprint

Tableau 6. Backlog du troisième sprint

ID Tâche Estimation
9 En tant que développeur, je veux pouvoir implémenter le 14 jours
protocole OAuth 2.0 avec Spring Security et keycloak
10 En tant que développeur, je veux pouvoir récupérer les
informations de l'utilisateur à partir du keycloak token
11 En tant que développeur, je veux pouvoir implémenter le
protocole OAuth 2.0 avec Angular et keycloak
12 En tant que développeur, je veux une implémentation du multi
tenancy
13 En tant que développeur, je veux pouvoir automatiser la
sauvegarde et la récupération de documents d'autres
microservices.

La réalisation peut être décomposée en deux parties:

 Implémentation du protocole Oauth2 avec keycloak.
 Automatisation de la sauvegarde et de la récupération de documents d’autre micro-
services.

47
Implémentation des diverses fonctionnalités communes

1.2 Implémentation du protocole Oauth2 avec keycloak.

Dans cette partie nous présenterons le protocole Oauth2 ainsi que le gestionnaire d’identité
keycloak.

1.2.1 Protocole OAuth2

Vu que chaque service est une application indépendante, on a besoin d’unifier l’authentification
pour tous les services, ce processus doit être externalisé, ce qui veut dire que la gestion des
droits d’accès doit être implémentée dans un service dédié, appelé serveur d’autorisation.
OAuth2: Ce protocole permet à des applications tierces d’obtenir un accès limité à un service
disponible via HTTP par le biais d’une autorisation préalable du détenteur des ressources.
L’accès est demandé par ce qu’on appelle « un client », et qui peut être un site internet ou une
application mobile par exemple. Si les ressources n’appartiennent pas au client, alors ce dernier
doit obtenir l’autorisation de l’utilisateur final, sinon il peut directement obtenir l’accès en
s’authentifiant avec ses propres identifiants.
Pour bien comprendre ce processus, OAuth2 définit 4 rôles :
 Le détenteur des données (Resource Owner) : C’est l’utilisateur qui autorise une
application à accéder à son compte. L’accès de l’application au compte de l’utilisateur
est limité à la portée de l’autorisation accordée.
 Le serveur de ressources (Resource Server) : serveur qui héberge les don- nées dont
l’accès est protégé (par exemple Google qui stocke les informations de chaque profil).
 Le client (Client Application) : une application demandant des données aux serveur
de ressources (cela peut être une application Java côté serveur, une application
JavaScript côté client ou une application mobile par exemple).
 Le serveur d’autorisation (Authorization Server) : serveur qui délivre des tokens (ou
jetons) au client. Ces tokens seront utilisés lors des requêtes du client vers le serveur de
ressources. Ce serveur peut être le même que le serveur de ressources (physiquement et
applicativement), et c’est souvent le cas.
La figure 22 explique le cheminement nécessaire pour qu’un utilisateur puisse donner accès à
une ressource.

48
Implémentation des diverses fonctionnalités communes

Figure 22. Flux de protocole OAuth2

1.2.2 Gestionnaires des identités et des accès

La Gestion des Identités et des Accès est l’ensemble des processus mis en œuvre par une entité
pour la gestion des habilitations de ses utilisateurs à son système d’information ou à ses
applications. Il s’agit donc de gérer qui a accès à quelle information. Cela implique ainsi
d’administrer la création, la modification, et les droits d’accès de chaque identité numérique
interagissant avec les ressources de l’entité.

1.2.3 Keycloak

Keycloak [10] est une solution open source de gestion des identités (identity manager) et des
accès destinés aux applications et aux services modernes. Cela facilite la sécurisation des
applications et des services Il offre un large éventail de fonctionnalités, telles que la connexion
unique, l’authentification et l’autorisation, la connexion sociale, l’authentification
multifactorielle et la gestion centralisée des utilisateurs. On a choisi keycloak pour plusieurs
raisons:
 Prix : la solution d’authentification la moins chère du marché.

49
Implémentation des diverses fonctionnalités communes

 Intégration à une solution existante : possibilité d’intégrer Open LDAP et Active

Directory via un connecteur.
 Technologies modernes : OpenID Connect et SAML 2.0 authentification pour Single
Log Out pour les applications du navigateur.
 Identités et courtiers de réseaux sociaux : possibilité de se connecter simplement à
Twitter, Google, Facebook, etc. ou de déléguer des demandes via SAML 2.0 et OIDC.
 Politiques de sécurité : possibilité de définir facilement des stratégies de mot de passe
et des révocations.
 Empreint d’identité : possibilité de connecter les administrateurs en tant
qu’utilisateurs différents pour un dépannage plus simple et plus rapide.
 Thèmes : Keycloak permet de styler facilement la page de connexion, la console
d’administrateur, la console de gestion de compte et les courriers électroniques.
L’ensemble du système est entièrement localisé.
 Solution moderne : Keycloak inclut une API REST pour toutes les fonctions SSO telles
que la connexion, la déconnexion, l’actualisation des jetons utilisateur, etc.

[Link] Fonctionnalités de keycloak

Keycloak fourni plusieurs fonctionnalités :

 Authentification unique : Les utilisateurs s’authentifient avec Keycloak plutôt qu’avec
des applications individuelles. Cela signifie que nos applications n’ont pas à traiter avec
les formulaires de connexion, l’authentification des utilisateurs et le stockage des
utilisateurs. Une fois connecté à KeyCloak, les utilisateurs ne doivent plus se connecter
pour accéder à une autre application. Ceci s’applique également à la déconnexion.
Keycloak fournit une déconnexion unique, ce qui signifie que les utilisateurs ne doivent
se déconnecter qu’une seule fois pour se déconnecter de toutes les applications utilisant
Keycloak.
 Courtage d’identité et connexion sociale : L’activation de la connexion avec les
réseaux sociaux est facile à ajouter via la console d’administration. Il suffit de
sélectionner le réseau social que nous souhaitons ajouter. Aucun code ou modification
de notre application n’est requis. Keycloak peut également authentifier les utilisateurs
avec les fournisseurs d’identité OpenID Connect ou SAML 2.0 existants. Encore une

50
Implémentation des diverses fonctionnalités communes

fois, il s’agit simplement de configurer le fournisseur d’identité via la console

d’administration. La figure 23 illustre les réseaux sociaux et les courtages d’identité que
keycloak supporte.

Figure 23. Courtage d’identité et connexion sociale

 Console d’administration : Grâce à la console d’administration, les administrateurs

peuvent gérer de manière centralisée tous les aspects du serveur Keycloak. Ils peuvent
activer et désactiver diverses fonctionnalités. Ils peuvent configurer le courtage
d’identité et la fédération d’utilisateurs. Ils peuvent créer et gérer des applications et des
services, et définir des politiques d’autorisation détaillées. Ils peuvent également gérer
les utilisateurs, notamment les autorisations et les sessions.
 Services d’autorisation : Si l’autorisation par rôle ne couvre pas nos besoins, Keycloak
fournit également des services d’autorisation détaillés. Cela nous permet de gérer les
autorisations pour tous nos services à partir de la console d’administration Keycloak et
nous donne le pouvoir de définir exactement les stratégies dont nous avons besoin.

51
Implémentation des diverses fonctionnalités communes

[Link] Implémentation du Keycloak

Il est nécessaire de connaître certains concepts et termes clés avant d’essayer d’utiliser
Keycloak pour sécuriser nos applications Web et nos services REST :
 Utilisateurs : Ils sont des entités pouvant se connecter à notre système
 Rôles : ils identifient un type ou une catégorie d’utilisateur. Admin, user, etc.
 Groupe : permet de gérer un groupe d’utilisateur.
 Royaumes (realms): un domaine qui gère un ensemble d’utilisateurs, d’informations
d’identification, des rôles et des groupes.
 Clients : ils sont des entités pouvant demander à Keycloak d’authentifier un utilisateur
(comme des applications).
 Token : un token qui fournit des informations d’identité sur l’utilisateur
 Access token : un token pouvant être fourni dans le cadre d’une requête HTTP
autorisant l’accès au service invoqué.

[Link].1 Configurer keycloak chez le serveur du ASM

Après avoir installé keycloak chez le server du ASM, on propose de suivre les étapes suivantes :
 Crée compte admin : Pour pouvoir configurer Keycloak, il nous faut un compte admin
que nous pouvons créer via la console d’administration comme le montre la figure 24.
 Création d’un domaine/realm Keycloak : Le concept de base dans Keycloak est un
royaume. Un domaine sécurise et gère les métadonnées de sécurité pour un ensemble
d'utilisateurs, d'applications et de clients OAuth enregistrés. La figure 25 illustre la
création d’un realm.
 Configuration d’un realm : Dans notre configuration, nous avons choisi l’option User
registration, Forgot password et Login with email, comme le montre la figure 26.
 Ajout d’un client : Dans la figure 27 nous avant présenter l’ajout d’un client erp-app
qui est notre application.
 Configuration du client : Indiquez le chemin d’accès de notre application dans l’URL
de redirection valide comme le montre la figure 28.

52
Implémentation des diverses fonctionnalités communes

Figure 24. Création d’un admin

Figure 25. Création d’un realm

53
Implémentation des diverses fonctionnalités communes

Figure 26. Configuration du realm

Figure 27. Ajouter le client erp-app

54
Implémentation des diverses fonctionnalités communes

Figure 28. Configuration du client erp-app

 Configuration du multi-tenant : Pour que notre application peut servir à plusieurs

organisations, il faut appliquer un principe d'architecture logicielle (multi-tenant).
Chaque organisation est un group dans keycloak dont elle possède sa propre collection
et tous les organisations partagent la même base de donnée. Les collections sont
enregistrées dans la base de donnée selon l’approche nom de collection suivie du nom
du groupe (l’organisation) séparer par un tiret. Par défaut le token ne contient pas le
group c’est pour cela qu’on a créé un nouveau mapper, comme le montre la figure 29,
qui contient le group pour l’ajouter au token.

55
Implémentation des diverses fonctionnalités communes

Figure 29. Crée un nouveau mapper

[Link].2 Implémentation du keycloak dans la partie back-end

Keycloak est un gestionnaire d’identité pour toute l’application. Pour ce but là on a configuré
Keycloak dans un sous-projet nommer base-core qui est implémentée par tous les services. Au
niveau de sous-projet, on a créé une interface keycloakhelper où on a défini tous les methodes
qu’on a besoin pour accéder aux informations de l’acteur. On a aussi créé une class
KeycloakConfig où on a défini la création du bean keycloakhelper (comme auto configuration)

1.3 MSRef

Dans cette partie nous présenterons l’annotation MSREF sa fonctionnalité et sa réalisation.

1.3.1 Conception

[Link] Digramme de cas d’utilisation

La figure 30 illustre le diagramme de cas d’utilisation pour la sauvegarde et la récupération de

documents d’autre micro-services.

56
Implémentation des diverses fonctionnalités communes

Figure 30. Diagramme de cas d’utilisation

[Link] Diagrammes de séquence

Dans cette section nous présentons les diagrammes de séquence de :

 MSRef en invoquant méthode find illustré par la figure 31 :
Lorsqu'un document est récupéré, les références MSREF sont laissées en tant que références à
ces autres documents (qui sont située dans un autre micro-service). Au niveau de la méthode
onaAfterLoad on a fait l’appel à un autre micro-service pour obtenir le doccument pointer par
MSRef et le fusionner avec le résultat.
 MSRef en invoquant la méthode save illustré par la figure 32 :
La même logique sera implémentée mais cette foi avant d’insérer un document.

57
Implémentation des diverses fonctionnalités communes

Figure 31. Diagramme de séquence pour le fonctionnement de MSRef en invoquant la

méthode find

Figure 32. Diagramme de séquence pour le fonctionnement de MSRef en invoquant la

méthode save

58
Implémentation des diverses fonctionnalités communes

[Link] Diagramme de classe

La Figure 33 illustre le diagramme de classe qu’on a réalisé pour qu’on puisse implémenter la
logique de l’annotation MSREF.

Figure 33. Diagramme de classe

1.3.2 Réalisation

Comme BDRef, annotation crée par mongoBD, référence un document à un autre dans la même
base de donnée, on a créé MSRef qui référence un document a un autre dans des bases de
donnée différente (autre microservice). MSRef est une annotation d’attribut qui prend en
paramètre le nom du microservice et le end-point d’un web service qu’on veulent le
consommer. Spring Data MongoDB publie des évènements de cycle de vie très utiles dans la
classe AbstractMongoEventListener, tels que onBeforeConvert, onBeforeSave, onAfterSave,
onAfterLoad et onAfterConvert. On a créé une abstraction de cette classe pour implémenter la
logique de notre annotation.

59
Implémentation des diverses fonctionnalités communes

2 Sprint 4

2.1 Backlog du quatrième sprint

Tableau 7. Backlog du cinquième sprint

ID Tâche Estimation
14 En tant qu'administrateur, je veux avoir une visibilité sur 14 jours
l'historique des documents.
15 En tant qu'administrateur, je veux avoir une visibilité sur les
documents supprimer.
16 En tant que développeur, je veux une interface de filtrage de
données avancée

La réalisation peut être décomposé en deux parties :

 Gestion des Snapshot: introduite dans les deux premières tâches
 Filtre avancé : introduits dans la troisième tâche.

2.2 Conception

2.2.1 Digramme de cas d’utilisation

La figure 34 illustre le diagramme de cas d’utilisation pour la gestion des snapshots et les filtres
avancés

60
Implémentation des diverses fonctionnalités communes

Figure 34. Diagramme de cas d’utilisation pour les snapshots et les filtres avancés

2.2.2 Description textuelle

Tableau 8. Affinement de cas d'utilisation « update document»

Cas d’utilisation Update document

61
Implémentation des diverses fonctionnalités communes

Acteur Tout acteur autorisé par le système.

Précondition Le document existait

Postcondition Mis à jour du document

Scénario 1. L'acteur invoque une mise à jour (sauvegarde).

principal 2. Le système enregistre automatiquement un snapshot à partir du
document avant de le mettre à jour.
3. Le système met à jour le document et l’enregistre.

Scenario Enregistrez le document sans prendre un snapshot si le document n'existait

alternatif pas auparavant.

Tableau 9. Affinement de cas d'utilisation « delete document »

Cas d’utilisation delete document

Acteur Tout acteur autorisé par le système.

Précondition Le document existait

Postcondition Document supprimé

Scénario 1. L'acteur invoque la méthode delete du repository.

principal 2. Le système identifie automatiquement le document comme étant
supprimé sans le supprimer réellement.

Tableau 10. Affinement de cas d'utilisation « get snapshot on date »

Cas d’utilisation get snapshot on date

Acteur Tout acteur autorisé par le système.

62
Implémentation des diverses fonctionnalités communes

Précondition Le document existait

Postcondition snapshot de la collection demandée

Scénario L'acteur appelle la méthode find avec une date-heure spécifique et reçoit
principal un snapshot de la collection demandée.

Scénario Le système lève une exception en cas d'erreur d'analyse.

alternatif

Tableau 11. Affinement de cas d'utilisation « filter collection data»

cas d'utilisation filter collection data

Acteurs Tout acteur autorisé par le système.
Précondition Le document existait
Postcondition Données filtrées
Scénario principal L'utilisateur envoie un fichier Json définissant le résultat souhaité.
Le système renvoie le résultat recherché
Scénario alternatif Le système lève une exception en cas d'erreur d'analyse.

2.2.3 Diagrammes de séquence

Dans cette section nous présentons les diagrammes de séquence de :

- Gestion des snapshots présenter par deux diagramme :
o La figure 35 illustre le processus de Falsifier la suppression des entités.
o La figure 36 illustre le processus de sauvegarde d'un snapshot de collection
lors de la mise à jour.
- Système de filtrage comme le montre la figure 37.

63
Implémentation des diverses fonctionnalités communes

Figure 35. Diagramme de séquence pour soft-delete

64
Implémentation des diverses fonctionnalités communes

Figure 36. Diagramme de séquence pour prendre un snapshot sur la mise à jour

65
Implémentation des diverses fonctionnalités communes

Figure 37. Diagramme de séquence pour les filtres avancés

66
Implémentation des diverses fonctionnalités communes

2.2.4 Diagrammes de classe

Dans cette section nous présentons les diagrammes de classe de :

- Gestion des snapshots présenter par deux diagramme :.
o La figure 38 illustre le mécanisme d’intercepter les méthodes de sauvegarde pour
prendre un snapshot en utilisant les méthodes de event listener fourni par Spring
Data MongoDB dans la classe (AbstractMongoEventListener).
o La figure 39 illustre la gestion des snapshots ou en a créé une abstraction de la classe
SimpleMongoRepository (ou se trouve tous les méthodes d’interaction avec la base
de donnée)
- Système de filtrage : le diagramme de classe présenter par la figure 40 illustre les
différentes classes et interfaces qu’on a implémentées afin de puissent désérealiser un
objet JSON (qui définit la critère de recherche) .

Figure 38. Diagramme de classe pour prendre un snapshot sur la mise à jour

67
Implémentation des diverses fonctionnalités communes

Figure 39. Diagramme de classes pour la gestion des snapshot

68
Implémentation des diverses fonctionnalités communes

Figure 40. Diagramme de class des filtres avancés

69
Implémentation des diverses fonctionnalités communes

2.3 Réalisation

Snapshot sur la mise à jour :

Pour ne pas répéter la même logique dans la méthode de sauvegarde de chaque service, Il faut
commencer par automatiser l’enregistrement des snapshot lors de la mise à jour. Pour cette
raison, nous avons trouvé deux solutions possibles:
 Surcharger (Override) la méthode de sauvegarde (save) du repository mongo
 Utilisation du mongo repository event listener pour enregistrer un snapshot avant de
mettre à jour le document.
Et pour cette tâche, nous avons choisi d’utiliser mongo repository event listener car nous ne
souhaitons pas modifier la fonctionnalité de sauvegarde, nous voulons plutôt ajouter une
fonctionnalité.
o Un critère doit être ajouté à toutes les méthodes de récupération, les empêchant de
sélectionner des instantanés.

Snapshot sur la Suppression :

L’effet d’enregistrer un snapshot au cours d'une suppression est de remplacer la suppression
réelle par une suppression virtuelle. L’entité sera indiquée comme supprimé et elle ne s’affiche
plus dans l’application, mais réellement elle reste sauvegardée dans la base de données.
o Un critère doit être ajouté à toutes les méthodes de récupération, les empêchant de
sélectionner des documents supprimés.

Récupérer un snapshot :
Pour récupérer des snapshot, nous avons ajouté des fonctions personnalisées dans le mongo
repository qui permettent de récupérer des snapshot à une date et une heure spécifiques.

Filtre avancé :
Après avoir étudié plusieurs systèmes ERP, nous avons réalisé l’importance de disposer d’une
fonctionnalité de filtrage avancée dans notre système. Ce dernier doit être adaptable à tout
filtrage compliqué avec plusieurs conditions et le développeur peut ajouter d'autres critères sans
modifier le code.
Pour atteindre cette flexibilité, nous avons créé deux types de critères, un critère logique et un
critère conditionnel.

70
Implémentation des diverses fonctionnalités communes

Tous les critères sont annotés par @Creteria annotation pour identifier les classes de critères et
leur attribuer un ou plusieurs caractères d'identification.
Ensuite, un désérialiseur a été créé pour analyser le JSON et créer le critère final pour l’injecter
dans une requête et obtenir le résultat souhaité.
Le critère de la recherche peut-être présenter par une expression logique ou conditionnelle. Une
expression conditionnelle est composée du nom du champ, un opérateur et une valeur. Une
expression logique est composée d’un opérateur et des listes de critères.
Prenons l’exemple suivant : nous avons une entité produit qui a parmi ses attributs prix,
catégorie et libellé. Si nous voulons chercher les produits qui sont de la catégorie informatique
et qui ont un prix inférieur à 250 ou qui ont un libellé contient « HP ».
L’expression est alors : (catégorie LIKE informatique) ET (prix < 250 OU (libellé CONTAINS
‘hp’)). La figure 41 illustre la structure du JSON.

Figure 41. Structure JSON pour les filtres avancés

71
Implémentation des diverses fonctionnalités communes

Conclusion
Au cours de ce chapitre, nous avons expliqué l’implémentation du gestionnaire d’identité
keycloak et la mise en place de l’annotation MSRef ansi que l’implémentation des gestions des
snapshots et des évènements. Dans le chapitre suivant nous allons implémenter une chaine
d’intégration continu sur GitLab.

72
 Chapitre 5

Gestion d’intégration continue sur GitLab

(devops)

73
Gestion d’intégration continue sur Gitlab(devops)

Introduction
Ce chapitre présente le cinquième sprint, où nous expliquons les différentes étapes pour la mise
en place d’un pipeline CI/CD pour la gestion d’intégration continue sur GitLab.

1 Backlog du cinquième sprint

Tableau 12. Backlog du cinquième sprint

ID Tâche Estimation
17 En tant que développeur, je veux mettre en place l’intégration 9 jours
continue
18 En tant que développeur , je veux mettre en place le pipeline
19 En tant que développeur , je veux automatiser les test
20 En tant que développeur , je veux automatiser le déploiement
21 En tant que développeur , je veux préparer les conteneur docker

2 Devops

Une implémentation du pipeline CI/CD, ou intégration continue/déploiement continu. Il relie

les équipes de développement et d’exploitation en automatisant la création, les tests et le
déploiement d’applications. Dans cette partie, nous allons comprendre ce qu’est un pipeline
CI/CD et comment il fonctionne. Avant de passer au pipeline CI/CD, commençons par
comprendre DevOps. La figure 42 illustre l’architecture DevOps.

74
Gestion d’intégration continue sur Gitlab(devops)

Figure 42. Architecture Devops

DevOps est une approche de développement logiciel qui implique un développement continu,
des tests continus, une intégration continue, un déploiement continu et une surveillance
continue du logiciel tout au long de son cycle de développement. C’est le processus adopté par
toutes les grandes entreprises pour développer des logiciels de haute qualité et des cycles de
développement plus courts, ce qui entraîne une plus grande satisfaction de la clientèle, ce que
chaque entreprise souhaite.

3 Démonstration logique

3.1 Versions du code

Le pipeline ci-dessus présenter par la figure 43 est une démonstration logique de la façon dont
le logiciel évoluera au cours des différentes étapes de ce cycle de vie avant sa livraison au client
ou avant sa mise en production.

75
Gestion d’intégration continue sur Gitlab(devops)

Figure 43. Version du code

3.2 Phase de construction (Build)

Notre projet est développé en Java qui doit être compilé avant son exécution. À travers la phase
de contrôle de version, il passe à nouveau à la phase de construction, où il est compilé. Nous
obtenons toutes les fonctionnalités de ce code à partir de différentes branches du référentiel, qui
les fusionnent et utilisent finalement un compilateur pour le compiler. Tout ce processus
s’appelle phase de Build.

3.3 Test unitaire

Ecrire des tests unitaires est une étape essentielle du processus de test dans le pipeline CI / CD.
Cependant, l’engagement est plus que la rédaction de tests. Les tests écrits doivent être fiables.
Pour qu’un test soit fiable, les résultats des tests doivent être mesurables. Les deux mesures
généralement utilisées pour les tests unitaires sont 100% de réussite et de couverture de code.

3.4 Déploiement

Une fois le test est terminé, nous passons à la phase de déploiement, dans laquelle nous
déployons l’application sur un serveur intermédiaire ou de test.

3.5 Test automatique

Une fois que le code est déployé avec succès, nous pouvons exécuter un autre test de santé. Si
tout est accepté, il peut être déployé en production.

76
Gestion d’intégration continue sur Gitlab(devops)

3.6 Déploiement en production

Pendant ce temps, à chaque étape, s’il y a une erreur, nous pouvons tirer un e-mail à l’équipe
de développement afin qu’ils puissent réparer le code.

4 Préparation des conteneurs de déploiement (DOCKER)

Comme le montre la figure 44, les conteneurs Docker [9] encapsulent un logiciel dans un
système de fichier complet qui contient tout ce dont ils ont besoin pour fonctionner (code,
machine virtuelle, exécutable, outils système, bibliothèques...) Tout ce qu’on peut installer sur
un serveur. Cela garantit que l’exécution sera toujours identique, quel que soit l’environnement
dans lequel le conteneur sera déployé.
Docker est un outil pour les administrateurs systèmes et les développeurs. Il fournit une couche
d’abstraction et d’automatisation au-dessus de fonctionnalités de virtualisation du noyau linux.
Il s’appuie notamment sur :
 Les control groups (CGROUPs), qui permettent de limiter les ressources allouées à un
processus (RAM, CPU, réseau, I/O..).
 Les name spaces, qui isolent les applications les unes des autres, comme si elles étaient
seules dans l’OS.

Figure 44. Architecture docker

77
Gestion d’intégration continue sur Gitlab(devops)

Docker repose sur une architecture client-serveur. Le client Docker effectue des requêtes HTTP
au service. Le service est en charge de construire, lancer et distribuer les conteneurs. Pour
construire les conteneurs il s’appuie sur des images stockées sur des dépôts publics et/ou privés.
Le client peut invoquer un service local ou distant via, une API REST. Nous avons choisi
d’utiliser les conteneurs de déploiement Docker pour les intérêts et avantages qu’ils offrent.
Le tableau 13 résume ces intérêts et avantages.
Tableau 13. Les intérêts et les avantages de docker

Intérêts/avantages Explication
Portabilité On peut créer un container et le faire
fonctionner sur n'importe quelle machine ou
service qui supporte Docker. Il y a deux
limitations à cette portabilité :
- Il faut que l'architecture cible soit
compatible.
- Le noyau linux étant celui de l'hôte, le
container ne peut pas exécuter une
image qui exigerait un noyau plus
récent.
Démarrage rapide un conteneur Docker démarre presque
instantanément
Ressources limitées Les conteneurs docker ne sont pas
gourmands en ressource. Ils sont ultra légers.
Isolation chaque conteneur a l'impression de disposer
d'une machine entière pour lui seul.
Déploiement simple Docker est une solution qui permet de
standardiser la façon dont une application est
packagée, puis s’exécute, dans n’importe
quel environnement. Ce qui simplifie et
accélère le déploiement.
Déploiement simple Docker bénéficie d'une communauté très
dynamique. Il existe donc une bonne

78
Gestion d’intégration continue sur Gitlab(devops)

documentation fournie sur cette technologie

open source.
Evolution rapide Des changements intéressants sont apportés
d’une version à une autre.

A chaque micro-service développé et testé nous préparons un docker file qui permet la
préparation de l’image et l’exécution de conteneur de ce service. Il est indispensable de pouvoir
lier des conteneurs. Pour pouvoir lier deux conteneurs, il faut imposer leur nom, à l’aide de
l’option « name », et lancer le second conteneur avec l’option « link » dont la valeur fait
référence au nom du premier conteneur. Docker va alors fournir au conteneur du serveur web
les infos lui permettant de communiquer avec la base de données. Pour notre application en micro-
services nous avons utilisé Docker compose pour pouvoir démarrer et arrêter plusieurs conteneurs
simultanément tout en définissant les liens entre eux. Pour démarrer la totalité de l’application
d’un seul coup avec docker compose nous suivons ces étapes :
 Décrire l’environnement de chacun des services de l’application à l’aide d’un dockerfile.
 Créer un fichier [Link] pour définir les services qui composent
l’application, et compléter/surcharger certaines des propriétés définies dans leurs
dockerfiles.
 Définir également les liens entre les services.
 Pour chaque service on donne un lien vers le dossier dans lequel se trouve son dockerfile,
ou l’URL du dépôt Git dans lequel il est stocké.
 Lancer toute l’application avec docker-compose up.

5 Démonstration physique

Comme le montre la figure 45 ci-dessous, le serveur d’intégration continue est toujours en

écoute des modifications dans l’outil de contrôle de version git. Au moment où il en détecte un
changement de code source, le pipeline se lance et une séquence d’étapes va être exécutée
jusqu’à la fin ou l’échec prend place.

79
Gestion d’intégration continue sur Gitlab(devops)

Figure 45. Architecture CI/CD

5.1 Mise en place du pipeline

La livraison continue permet aux organisations de fournir des logiciels à moindre risque. Le
chemin vers la livraison continue commence par la modélisation du pipeline de livraison de
logiciels utilisés au sein de l’organisation et se concentre ensuite sur l’automatisation de tout
cela. La rétroaction directe précoce, activée par l’automatisation des pipelines, permet une
livraison plus rapide des logiciels par rapport aux méthodes de livraison traditionnelles. Par
conséquent, nous allons présenter un aperçu de chacune des étapes décrites dans la figure 46
ci- dessous.

80
Gestion d’intégration continue sur Gitlab(devops)

Figure 46. Pipeline

5.1.1 Stage check_style

Checkstyle est un outil de développement open source destiné à aider les programmeurs à écrire
du code Java conforme à une norme de codage. Il automatise le processus de vérification du
code Java par un rapport à un ensemble de règles configurable. Cette tâche est importante pour
les projets qui souhaitent appliquer une norme de codage.

Figure 47. Check_style

81
Gestion d’intégration continue sur Gitlab(devops)

5.1.2 Stage unit-test

Les tests sont sous la responsabilité de l’équipe Qualité (assurance de la qualité). En pratique,
les tests continus constituent la partie la plus difficile d’un pipeline de livraison continue. En
va montrer ce que cela signifie et ses avantages :
- Les tests continus consistent à rédiger des tests et à les exécuter de manière automatisée
- Pipeline CI / CD. Cette stratégie permet de tester plus rapidement, plus tôt et souvent
de manière totalement transparente.
- Augmenter la confiance dans le code avant la production.
- Garanti la qualité tout au long du pipeline
- Produire une version candidate du logiciel à chaque changement de code
- Réduire les coûts de développement et de maintenance.
Afin de garantir l’intégrité du code et de valider les plus petites unités du logiciel, nous avons
créé une étape qui exécute les tests JUnit réalisés par les développeurs. Nous utilisons Gradle
pour exécuter ces tests présentés par la figure 48.

Figure 48. Unit_test

82
Gestion d’intégration continue sur Gitlab(devops)

5.1.3 Stage build

Dans ce stage, on va créer un fichier exécutable. Ce fichier contiendra toutes les librairies
nécessaires au bon fonctionnement de l’application.

5.1.4 Stage docker build

L’étape de construire une image docker consiste d’ajouter chaque fichier JAR de micro-service
dans un fichier Docker qui va être rendu sur une image Docker. Les étapes de la création d’une
application java exécutable avec Docker sont les suivants:
 Construire une image basée sur Java Runtime Environment.
 Ajoutez le fichier JAR à l’image Docker.
 Exécutez le fichier JAR avec la ligne de commande.
 Vérifiez l’état de santé de l’application.
 Exposer le port de l’application.
Après avoir créé un fichier Docker pour chaque service d’application, nous devons créer les
images et les pousser dans notre registre GitLab, qui est un gestionnaire d’images de docker,
qui permet de stocker les images. La figure ci-dessous, illustre l’images docker qui existe dans
notre registre.

Figure 49. Publication d’une image docker eureka-server dans le registry de GitLab

83
Gestion d’intégration continue sur Gitlab(devops)

Conclusion
Au cours de ce chapitre, nous avons décrit les étapes du cycle de vie du pipeline CI/CD et la
planification de l’environnement automatisé.

84
Conclusion générale
Ce travail s’inscrit dans le cadre de projet de fin d’études. Il a été réalisé au sein de la société
ASM (all soft multimédia) et consiste à la mise en place d’un socle Java JEE/angular. Il présente
un outil de démarrage de chaque projet ainsi que le démarche devops.
Nous avons conçu et développé un socle en utilisons l’architecture en micro-services. Nous
utilisons pour accomplir cette mission des projets spring cloud ainsi que d’autre projet spring.
Pour ce projet, nous étions responsables de la mise en place de l’architecture de la solution ainsi
que la conception, la réalisation, les tests et le déploiement. Nous avons pu résoudre à travers
cette migration les limites exigées par le style architectural monolithique sur les grands projets.
Grâce à cette expérience, nous avons pu, d’une part, découvrir de nouvelles technologies et
d’autre part acquérir de nouvelles compétences. Par ailleurs, ce projet nous a aussi été bénéfique
de point de vue personnel puisqu’il nous a permis d’appréhender le travail au sein d’une grande
société et dans une hiérarchie professionnelle. Le travail de groupe, la gestion de projet de façon
méthodique et la répartition des tâches et des efforts sont tous des compétences que nous avons
acquis grâce à ce stage.

Bien que les principaux objectifs de notre projet soient atteints, l’application pourrait être
enrichie davantage par d’autres fonctionnalités.

Pour conclure, nous pensons que cette période de stage au sein de la société ASM a été une
expérience professionnelle enrichissante pour notre carrière.

85
 Bibliographie

[1] «ASM,» [En ligne]. Available: [Link]

[2] «agile,» [En ligne]. Available: [Link]
un-belle-definition/.
[3] «SCRUM,» [En ligne]. Available: [Link]
[4] «Git,» [En ligne]. Available: [Link]
%C3%80-propos-de-la-gestion-de-version.
[5] «Java,» [En ligne]. Available: [Link]
[6] «TypeScript,» [En ligne]. Available: [Link]
presentation-typescript.
[7] «Spring Boot,» [En ligne]. Available: [Link]
[8] «Angular,» [En ligne]. Available: [Link]
[9] «Docker,» [En ligne]. Available: [Link]
[10] «Keycloak,» [En ligne]. Available: [Link]

86
 MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE NORD-AMERICAINE PRIVEE
INSTITUT INTERNATIONAL DE TECHNOLOGIE

DEPARTEMENT DE GENIE INFORMATIQUE

DEVELOPPEMENT D’UNE ARCHITECTURE MICRO SERVICE POUR

LE DEVELOPPEMENT D’UN ERP EN MODE SAAS
ELLEUCH WAJIH
RESUME:
CE PROJET A ETE REALISE DANS LE CADRE DU PROJET DE FIN D’ETUDES POUR L’OBTENTION DU DIPLOME
NATIONAL D’INGENIEUR EN GENIE INFORMATIQUE QUI A EU LIEU AU SEIN DE LA SOCIETE ASM.
LE BUT DE NOTRE PROJET INTITULE «PREPARATION D’UNE ARCHITECTURE MICRO-SERVICES POUR LE
DEVELOPPEMENT D’UN ERP EN MODE SAAS» EST DE METTRE EN PLACE UNE ARCHITECTURE EN MICROSERVICES
POUR DEVELOPPER UN ERP, EN PLUS DE PLUSIEURS AUTRES FONCTIONNALITES QUI VISENT A MINIMISER LE
ROLE TECHNIQUE DU DEVELOPPEUR POUR SE CONCENTRER UNIQUEMENT AU METIER..

ABSTRACT:
THIS PROJECT HAS BEEN CARRIED OUT AS PART OF THE END-OF-STUDY PROJECT FOR THE
OBTAINING OF THE NATIONAL DEGREE OF SOFTWARE ENGINEERING ENGINEER IN
SOFTWARE AND COMPUTER SOFTWARE THAT HAS TAKEN PLACE WITHIN THE COMPANY
ASM.
THE PURPOSE OF OUR PROJECT CALLED PREPERATION OF A MICRO-SERVICES
ARCHITECTURE FOR THE DEVELOPMENT OF A SAAS ERP IS TO SET UP A MICROSERVICES
ARCHITECTURE TO DEVELOP AN ERP, IN ADDITION TO SEVERAL OTHER FUNCTIONALITIES,
WHICH AIM TO MINIMIZE THE TECHNICAL ROLE OF THE DEVELOPER TO CONCENTRATE
ONLY TO THE BUSINESS.

MOTS CLÉ: SOCLE, SPRING BOOT, ANGULAR, DOCKER, ARCHITECTURE MICRO-SERVICES

KEYWORDS: BASE, SPRING BOOT, ANGULAR, DOCKER, MICRO-SERVICES ARCHITECTURE

87
88