VI.1.2. Implémentation de
la solution
1. Architecture de la solution
Apres étude , nous avons porté notre choix sur
Freeswitch comme serveur d'application et a2billing comme système de
facturation
Figure VI.10 Architecture de vente de crédit
2. Présentation des résultats
de la facturation des SMS
a. Envoi de SMS à un utilisateur en mode
connecté
Le client 802 décide d'envoyer un
message en destination du client 801, celui-ci est
connecté, donc un événement REGISTER de sa part est
détecté par le SMSC comme le montre la capture suivante:
Capture 1: enregistrement user 801 et 802
Avant l'envoi de sms:
Capture 2: Users dans a2billing avant l'envoi de sms
Capture 3 : SMS en mode connecté
La capture montre l'événement register
du user 801 est détecté par le SMSC et qu'il ne dispose
pas de nouveaux messages, c`est-à-dire au moment de son enregistrement,
le SMSC a consulté la base de données pour vérifier si le
801 avait un message en absence. On voit bien les informations que le SMSC nous
notifie à savoir: user connecté message
envoyé!! Ce message est récupéré par
le SMSC qui le stocke dans la base de données avant de procéder
au transfert vers le destinataire.
Après l'envoi de sms:
Capture 4: Users dans a2billing apès l'envoi de sms
b. Envoi de SMS à un utilisateur en mode non
connecté
Dans le même principe le client 801 est
déconnecté et le client 802 lui envoie un
message en absence, celui-ci est intercepté par le SMSC qui
vérifie dans sa base de données sqlite
share-présence et ne trouve pas
d'événement REGISTER pour le client 801, donc il
(SMSC) stocke le message dans une autre base de données MySQL
holding-sms, cette base permet de stocker les messages en
absence. C'est dans cette base que le message sera
récupérer en cas de reconnexion du client 801.
La capture suivante illustre ce phénomène :
Capture 5: SMS en mode non connecté
Dans cette capture on voit que le message envoyé par
l'expéditeur 802 en destination du 801
a été sauvegardé car le user 801
est non connecté. A la reconnexion du 801, on
voit les informations à savoir:
Capture 6: SMS en absence pour 802 et reconnexion
3. Présentation des résultats de la
facturation de la voix
La facturation des appels est gérée grâce
à a2billing qui est un outils de facturation.
Connexion de user 801
Capture 7: Enregistrement des users
Connexion de user 802
Avant l'appel
Après l'appel
4. Réalisation du système de vente de
crédit
Après la mise en place du système de vente et de
la plateforme, nous allons présenter les différents
résultats.
A. Coté administrateur
Ici nous utilisons a2billing pour gérer cela:
a. Page d'accueil de l'application
Capture 8: Interface d'accueil a2billing
b. Page de connexion de l'administrateur
L'administrateur peut voir:
· Lister les CDRs des appels émis
· Lister les CDRs de demande de credit
· voir la liste des revendeurs, pour ne citer que cela
B. Système côté Revendeur
Le revendeur interagit avec le système grâce
à une API mise en place et développée avec le Framework
Flask-Restplus.
Pour les revendeurs, ils accèdent au système via
une URL de l'API qu'on a mise en place.
API d'envoi de SMS et de vente de crédit
v Interface revendeur et présentation des résultats
Pour le revendeur, nous avons développé une
application web respectant les critères d'un opérateur de
transfert d'argent qu'on nomme AkhiKachMoney.
Capture 10: Interface de connexion du revendeur
Le revendeur se connecte avec son login et son mot de passe,
une foi qu'il valide, il obtient la page suivante:
Capture 11: Page de d'accueil du revendeur
Toutes ces fonctionnalités sont liées à
l'API et permettent au revendeur d'effectuer des actions comme l'achat de
crédit, la vente de crédit, consultation de crédit, et
l'envoi de message. Le revendeur du numéro 810 vend du
crédit au client 801, la capture suivante illustre ce
fait:
Capture 12: Interface de vente de crédit du
revendeur
Une foi le revendeur valide, le client reçoit le message
suivant:
Capture 13: Message reçu après achat de
crédit au revendeur
| 
