Vue d'ensemble du projet
Le projet consistait à créer une solution indépendante comprenant un portail administrateur et un omnicanal de traitement des paiements pour permettre aux caissiers de banque de gérer les transactions des fournisseurs tiers. L'application présentait un système intuitif basé sur les rôles, capable de gérer de grands volumes de transactions tout en offrant aux utilisateurs la possibilité de payer via plusieurs méthodes.
Approche de développement
Construire une application pour la banque nécessite la mise en œuvre de pratiques de développement hautement sécurisées. Cela a déterminé la méthodologie et les exigences technologiques du projet. Java a été choisi comme langage de programmation et une équipe de quatre personnes a été formée, comprenant un développeur back-end principal, deux développeurs front-end et un chef de projet adoptant une approche agile scrum.
Ensemble technologique :
Langage de programmation : JAVA/Kotlin
Système de build : Gradle
Serveur de développement : Serveur Apache Tomcat
Tests : Postman, Swagger
Contrôle de version : Git via Microsoft Azure Cloud
Déploiement et hébergement : AWS (Test), Production (Apache Tomcat)
Perspectives
Conception centrée sur l'utilisateur :
La mise en œuvre du contrôle d'accès basé sur les rôles (RBAC) est une première étape cruciale vers la protection des actifs système et des ressources de l'entreprise. En accordant ou refusant l'accès en fonction de rôles et de responsabilités définies, le RBAC garantit que seules les personnes autorisées ont accès aux informations et ressources sensibles, ce qui est également idéal pour les audits système et la conformité. J'ai pu réaliser cela en implémentant un schéma d'authentification JWT ainsi qu'en utilisant l'annotation @rolesallowed en JAVA, ce qui a permis de spécifier quelles classes ou APIs chaque groupe d'utilisateurs était autorisé à accéder.
Exposition de résolution de problèmes :
Le premier problème que j'ai rencontré était d'essayer de convertir des APIs SOAP obsolètes essentielles en normes modernes HTTP REST. J'ai mené des recherches approfondies qui m'ont permis de découvrir et d'implémenter le plugin maven JAXB, qui m'a permis de « marshaller » (écrire) et de « démarshaller » (lire) des objets Java en données XML et vice versa. Ce plugin utilise essentiellement l'API Java pour la liaison XML pour générer des classes Java à partir de schémas XML (et éventuellement des fichiers de liaison) ou pour créer des schémas XML à partir d'une classe Java annotée, ce qui a simplifié la consommation et l'exposition des APIs nécessaires via la norme REST qui utilise le format JSON beaucoup plus simple comme moyen de communication.
J'ai également créé une file d'attente d'autorisation permettant aux caissiers d'approuver ou de refuser toute transaction.
Le défi suivant consistait à créer un module qui enverrait automatiquement des rapports de relevé bancaire à une adresse e-mail particulière à une heure précise chaque semaine pour la réconciliation. Pour résoudre ce problème, j'ai implémenté un Cron job. Cette approche m'a également permis de tirer parti de la nature multi-thread de Java. Elle garantissait que le service commencerait sur un thread séparé sans interrompre l'application qui s'exécutait sur le thread principal, le service irait alors interroger les APIs nécessaires pour récupérer les relevés, les compiler/convertir en un fichier .csv, et envoyer à l'adresse e-mail spécifiée. Toutes les configurations (par exemple, modifier l'e-mail du client, préciser la fréquence à laquelle les relevés étaient générés, etc.) pouvaient être réalisées en modifiant le fichier .properties, ce qui assurait un haut niveau de flexibilité.
Métriques de performance et optimisation :
Les benchmarks de performance ont été fournis via l'utilisation de Spring Actuator, un outil qui nous a donné accès à des points de terminaison nous permettant de vérifier la santé, la vitesse et les métriques d'observabilité de l'application.
Tests et assurance qualité :
Comme toujours, suivre une stratégie de développement piloté par les tests (TDD) s'est avéré inestimable, d'autant plus que le projet nécessitait l'intégration de plus de 300 APIs de nombreux fournisseurs dans le paysage des paiements, y compris Interswitch, Remita, et d'autres prestataires de services financiers pour payer des factures, générer des factures et reçus numériques, des NUBANs virtuels, etc. J'ai écrit des tests unitaires pour chaque module afin d'assurer la correction, réduisant ainsi le besoin d'employer des testeurs dédiés lors de la phase initiale de développement, ce qui permet d'économiser des coûts. La documentation a également été fournie localement via Swagger. Pour tester chaque API, il suffisait simplement de lancer l'application, de naviguer vers l'URL de documentation Swagger fournie, et de tester le point de terminaison après authentification.
Réalisations et résultats du projet :
Le projet s'est conclu par un succès retentissant et des plans sont actuellement en cours pour une conversion qui verra des améliorations dans des domaines tels que l'utilisabilité et la maintenabilité. Les caissiers de la banque GMB ont été ravis d'avoir enfin un portail à travers lequel ils pouvaient voir toutes les actions et transactions des utilisateurs effectuées sur le système. Le code source a été déplacé vers un dépôt GitHub privé ici pour référence future.
Leçons apprises et réflexions futures :
Avec le recul, je suggérerais d'accorder autant d'importance à la planification/conception du produit afin de créer une image plus claire et de faciliter/accélérer les efforts de développement. À part cela, c'était une excellente expérience d'apprentissage et j'ai apprécié l'occasion de construire un produit qui a aidé à faciliter le travail des autres.
