But de la rétro: montrer que lorsqu’une session est prise en charge, mon backend gère bien l'envoi des mass emails

Une question? Posez-la ici

Techniquement, il s’agit d’un Cron qui toute les 30 secondes check si une session est prête à êtrs prise en charge (par le transporteur).(Voir le diagramme de séquences1). C’est à dire que l’enregistrement en base de donnée contient les champs nécéssaires à cette prise en charge. Cette base de donnée est une PostGreSQL car elle a été benchmarquée en début de projet. J’aurais préféré faire la partie de mon projet en Mysql, mais comme PostGreSQL est utilisé par toute l’équipe Agile, je dois m’y tenir et l’utiliser.

Maintenant niveau fonctionnel, Je vais donc simuler un transporteur qui recoit les email et donc qui reçoit les demandes de transport pour les prendre en charge, ou pas…

Email : je lance ie/Edge

Clic sur l‘expediteur: je vois le mail  de test

C’est un email dont je me sers pour faire mes tests quand je développe des apps Android

Je montre les emails recus en date du 27 juin : l’email fonctionne bien

Demo avec 1 seul process : “le heartbeat“

Je vérifie la base de données avec HeidiSQL, que j’aime bien, j’utilise aussi pgAdmin4, mais je préfère l’interface d’HeidiSQL. Chacun ses gouts.

Je vais purger les enregistrements : Je drop table sessiontransport

-Bouton droit sur sessiontransport

-vider la table

-Bouton droit et retirer « drop »

Je recree la table avec le script HeartBeatTable

copier coller depuis le fichier sur le bureau dans HeidiSQL/requetes:

NB: J’ai rajouté les champs „emailsent“ et „emailID“ pour gérer l’envoi des sessions vers le transporteur et lui demander via un lien s’il pren, ou pas la session en charge.

Je me mets sur la base de donnée  „public“‘ et je clique sur le triangle bleu „execute SQL“, ce qui va m’executer le script.

-          Double flèche vertes ou F5 pour rafraichir: la table apparait

-          Clic sur onglet données: la table est vide, il faut que je la remplisse , que je la bouchonne avec des mocks, des objets mockitos par exemple.

Je vais donc lancer le serveur tomccat1 (heartbeat1) (tomcat1):

heartbeat1/bin/startup.bat

Je regarde l’écran du heartbeat,

« catalina.start server startup in 15 secondes »…

« all emails sent successfully » forcement, il n’y en n’a pas à envoyer…

Les mails ont été envoyés, il n’y  pas de nouvelles sessions

Attendre 30 secondes de heartbeat

Je vois que toutes les 30 secondes, mon backend bat comme un cœur et check s’il y a des emails à envoyer.

Je vais simuler des session qui arrivent, pour que mon backend puiss envoyer les emais automatiquement. alors je vais Mocker, bouchonner les nouvelles sessions.

Je vais sur l’UI1  http://localhost:8080/heartbeat1

2 menus, j’explique :

             -1 pour visualiser les sessions à prendre en charge : clic, il y en a aucune

             -1 pour créer les objets mockitos et remplir la base de donnée

             -clic create mockito object

20 objets sont créés avec emailID (adresse email) et emailsend à false

Et là le backend va envoyer les emails.

Regardons la fenetre tomcat : mail send successfully

Regardons la base de donnée qui est maintenant populée :

HeidiSQL/SessionTransport/Données/Refresh

On voit les 20 ids, et le flag emailsent à true : le mail est donc envoyé.

Voilà, j’espère que cette vidéo de prise en charge de session vous a plue. RDV à la vidéo suivante parallélisme et scalabilité : load balancing de cluster en cliquant ici pour la synchro/update base de donnée en temps réel en fonction de l’envoi des emails 

Vous pouvez aussi passer directement  à la 3ème partie: reprise sur failover de manière asychrone : service redondé. Réplication des données, en cliquant ici