Architecture
Un monolithe NestJS modulaire, un worker séparé
Une SPA React consomme une API REST NestJS ; seuls les modules dédiés parlent à la passerelle. Le travail asynchrone — campagnes, dispatch, accusés de réception — est confié à un processus worker attaché à RabbitMQ.
Intégration Jasmin
Deux voies vers la passerelle, toutes deux enveloppées
L’utilisateur ne voit ni telnet ni HTTP : il manipule des écrans, la plateforme traduit.
jcli en telnet (port 8990)
Connecteurs, routes, filtres, intercepteurs et utilisateurs jcli sont pilotés via le protocole d’administration de Jasmin — enveloppé pour que l’utilisateur ne le voie jamais.
API HTTP (POST /secure/send)
Les envois passent par l’API HTTP de Jasmin. La plateforme n’implémente pas SMPP elle-même : elle orchestre le moteur.
Vue d’ensemble
Le flux, de l’écran au moteur
Chaque requête traverse les gardes avant d’atteindre les services ; seuls le module Jasmin et le module passerelle ouvrent un canal vers la gateway.
SPA React / Vite
Interface — shadcn/ui, Zustand, Tailwind
API NestJS
Gardes JWT + RBAC + PLAN → services de domaine
Module Jasmin · RabbitMQ · Workers
telnet + parser jcli · files DLX/DLQ · process séparé
Jasmin Gateway · MongoDB
Moteur SMS · base unique + cache jasmin_state
Le parser jcli est la fragilité connue. Il est développé en TDD et exige 100 % de couverture : une commande n’est jamais envoyée à la passerelle sans avoir été validée, et un échec de validation laisse la gateway inchangée.