PARTIE III. LE CAS PRATIQUE DE LA SOCIETE
CALL IN OUT
I. PRESENTATION DE LA SOCIETE CALL IN OUT
CALL IN OUT est un centre d'appel, qui assure
la mise en place d'un point d'entrée dédié à
l'ensemble des contacts clients :
· Emission et réception d'appels
· Web
· Fax
· Chatting
· Mailing
· E-mailing
· SMS
· Etc.
La cellule Pan-Européan et Middle East accueille les
clients dans leur langue d'origine.
CALL IN OUT couvre le spectre linguistique suivant :
· Français
· Anglais
· Néerlandais
· Allemand
· Espagnol
· Italien
· Portugais
· Arabe
La société est constitué de :
· Un centre de formation
· Un centre de qualité
· Un centre de saisie
· Des métiers
· Plateaux de production
La société est également divisée en
deux établissements : > CALL IN OUT (la
principale)
> LIGHT CLICK (la secondaire)
Les deux sont réparties sur les deux étages que
comporte la société. Site web :
www.callinout.com
II. ANALYSE DU BESOIN
II.1. FONCTIONNEMENT DE LA SOCIETE
La société CALL IN OUT reçoit des projets
ou des campagnes de ses clients. Les différents projets qui peuvent lui
être confiés sont par exemple :
· La vente d'un produit ou service par
téléphone
· Le marketing par téléphone
· Des enquêtes d'opinions,
· Etc.
Le projet lorsqu'il est reçu, passe par plusieurs
phases avant d'être lancé. En effet, il est d'abords modelé
par les superviseurs de campagnes, ensuite informatisé par la cellule
informatique afin d'avoir de meilleurs performances, puis validé par les
superviseurs, et enfin attribué à des agents qui se chargerons
des appels ou réceptions.
Lorsque le projet ou campagne est en production
(lancée), tous les évènements le concernant (tous les
appels, conversations, résultats, heures de production) sont
enregistrées par des programmes informatiques sur des serveurs de base
de données et de fichiers. Ces données servent plus tard à
effectuer des statistiques, des contrôles, garder des traces, et à
des exigences d'ordre commercial et juridique.
Les programmes informatiques qui sont utilisés pour la
production proviennent conjointement d'internationaux producteurs de Solution
pour
Centres d'appel comme VOCALCOM, AXTERIX et de la cellule
informatique de l'entreprise qui dispose également d'un pôle de
développement d'applications internes.
Dans la suite nous parlerons d'une campagne spéciale
sur laquelle nous avons travaillé et dont pour des raisons de
confidentialité nous appèlerons la campagne X.
II.2. PRESENTATION DE LA CAMPAGNE X
La campagne X est une campagne très rentable pour
l'entreprise. Elle a été confiée par un client
fidèle de la boîte et nécessite donc toute l'attention
possible. Elle a pour but de vendre des services par téléphone
aux différents usagers. A cette fin, la société lui a
alloué d'énormes ressources tant humaines, matérielles,
qu'informatiques. En effet, en plus du logiciel d'appel qui est utilisé,
il a été développé en interne, une application qui
se charge de la gérer de façon différente des autres
campagnes. Il s'agit d'une application (vb6 -access) qui permet à chaque
agent de noter sa vente après l'avoir effectuée. En fait le
logiciel d'appel le fait aussi mais il y'a des paramètres et traitements
qui n'y sont pas pris en compte. Aussi, vue la valeur de la campagne comme
précisée plus haut, elle est effectuée aussi bien sur le
site du haut (CALL IN OUT) que sur le site du bas (LIGHT CLICK). Elle est la
seule dans ce cas.
II.3. SPECIFICATION DU BESOIN
Venons en à la problématique du sujet. En fait
comme nous l'avons dit plus haut, après chaque vente, l'agent doit la
saisir. Or il se trouve que les deux sites ne communiquent pas car ayant chacun
son réseau local. Ainsi, afin de garder une cohérence des
données, un seul site est utilisée pour la saisie de
données : le site LIGH CLICK. Alors lorsqu'un agent du site du haut fait
une vente, il est obligé de descendre d'un étage pour faire la
saisie et remonter ensuite. Ce qui génère une perte de temps
grandiose.
Aussi, l'application utilise la même base de
données qu'une autre application interne qui se charge de faire les
statistiques de production de chaque site. En fin de mois, pour le calcul de
primes, cette base de données est utilisée. L'informaticien
chargé des primes copie sur une clé les résultats de
ventes du réseau de LIGHT CLICK et insère les résultats de
la clé sur le site principal CALL IN OUT. C'est juste après
ça qu'il peut faire le calcul de primes de chaque agent ; car un agent
peut être à volonté muté d'un site à l'autre.
A ce niveau donc aussi il y'a un problème d'utilisation de support
intermédiaire. L'idéal serait que les deux bases de
données communiquent directement sans avoir besoin de support
intermédiaire ou de traitement particulier au niveau de
l'application.
Ainsi, nous avons deux problèmes à résoudre
:
· Le déplacement des
téléopérateurs
· L'utilisation de clés pour faire communiquer les
bases.
II.4. SOLUTION PROPOSEE
La solution adoptée pour palier à ces
problèmes est la mise en place d'une base de données reparties
sur les deux sites à travers internet, afin de les faire communiquer
sans problèmes. Ainsi chaque site aura sa base de donnée
indépendante et toute donnée enregistrée sur un site
pourra être connu de l'autre sans aucun déplacement ou
manipulation humaine.
III. CONCEPTION DE LA SOLUTION
Dans le but d'agir avec efficacité et rapidité,
sans oublier concision et précision, nous avons pris une grande partie
de notre temps pour la conception de la solution. Cette partie est
présentée ci-après par des modèles du langage UML
dans sa version 2.
III.1. DIAGRAMME DE CAS D'UTILISATION
Le diagramme de cas d'utilisations nous présente les
principales fonctions ou cas d'utilisation du système, ainsi que les
acteurs qui y interviennent.
III.1.A. LES CAS D'UTILISATION
Un cas d'utilisation est une fonctionnalité du
système. Dans notre travail, nous en avons répertorié
trois principales :
> Saisir données
Action de saisir les ventes effectuées dans le
système
> Superviser
Action d'interroger le système pour savoir l'état
des vantes
> Gérer comptes
Action de créer, supprimer ou modifier les comptes
d'opérateurs. III.1.B. LES ACTEURS
Nous avons trois principaux acteurs :
> L'opérateur
C'est lui qui se charge d'effectuer les ventes
> Le superviseur
Il a pour rôle de contrôler l'activité des
téléopérateurs
> L'administrateur
Il se charge de créer des comptes
Etant donné que certaines tâches peuvent être
effectuées par tous les Utilisateurs, un utilisateur
générique englobant tous les autres a été
crée sous le nom de Utilisateur.
III.1.C. DIAGRAMME
Figure 16 : diagramme de cas d'utilisation
Les acteurs Administrateur, Opérateur, et Superviseur
héritent de l'acteur Utilisateur.
III.2. DIAGRAMMES DE SEQUENCES
Les diagrammes de séquences permettent de
détailler le processus d'exécution d'un cas d'utilisation. Nous
en avons définis 3 pour les principaux cas d'utilisation que nous avons.
Une classe est utilisée : la classe SYSTEM qui
Figure 17 : SD Saisir Données
représente l'un des deux sites de la
société. Elle a dons deux objets : LC (LIGHT CLICK) et CIO (Call
In Out).
III.2.A. DIAGRAMME DE SEQUENCE « SAISIR
DONNEES»
III.2.B. DIAGRAMME DE SEQUENCE «
SUPERVISER »
Figure 18 : SD Superviser
III.2.C. DIAGRAMME DE SEQUENCE « GERER
COMPTE »
Figure 19 : SD Gérer comptes
III.3. DIAGRAMME DE CLASSES
Le diagramme de classes représente la
modélisation des données utilisée dans le système,
avec les liens qui existent entre eux. L'application que nous avons
trouvée sur place a une grande base de données de plusieurs
tables. Nous allons nous intéresser seulement aux tables qui
interviennent dans le mécanisme de répartition de la base de
données et dont les noms suivent.
III.3.A. DIFFERENTES CLASSES OU TABLES
> OPERATEUR
Cette table contient les comptes de toutes les personnes
autorisées à se connecter au système, principalement les
téléopérateurs.
> DATACODE
Cette table contient les comptes et mots de passe des
utilisateurs, ainsi que les temps de connexion.
> TELE
Cette table contient toutes les ventes effectuées par les
téléopérateurs de la campagne X.
> RDV
Cette table contient toutes les statistiques de ventes pour
toutes les campagnes du site.
> PRIMES
Elle contient les données relatives aux primes des
utilisateurs
III.3.B. DIAGRAMME
Figure 20 : Diagramme de classes
IV. REPARTITION DE LA BASE DE DONNEES
IV.1. FRAGMENTATION ET LOCALISATION
Comme nous l'avons dit dans la première partie du
document, la fragmentation et la localisation constituent la principale phase
de la conception d'une base de données répartie. Dans notre cas,
il est question de dire quelles sont les tables et données qui seront
logées sur le site Call In Out (site du haut) et lesquelles seront sur
le site LIGHT CLICK (site du bas). Pour cela, tout d'abords nous rappellerons
les contraintes à respecter, puis nous donnerons l'architecture de
répartition choisie.
Les contraintes à respecter pour la répartition
sont les suivantes :
· Chaque site doit être indépendant et avoir
ses propres données
· Chaque site doit pouvoir accéder aux
données de l'autre
· Chaque opérateur doit pouvoir se connecter sur un
site comme sur l'autre.
· Les données de la table RDV qui est très
importante du fait qu'elle gère les ventes et permet de calculer les
primes des opérateurs, doivent être régulièrement
copiées sur le site Call in out , pour une meilleure
sécurité.
· Les primes des opérateurs sont calculées
sur le site Call In Out.
Face à ces contraintes, nous avons adopté
l'architecture suivante :
· Chaque site aura toutes les tables sauf la table PRIME du
système
· La table PRIME sera uniquement sur le site Call In Out
!
· Certaines données seront répliquées
d'un site à l'autre
IV.2. REPLICATION
La réplication nous permettra de transférer
certaines données d'un site à l'autre selon la description
ci-après :
· Tout d'abords, la gestion des opérateurs est
contrôlée par le site LC. Tout nouvel enregistrement ou
modification effectué sur un opérateur du site LC (le site
Maitre), sera automatiquement propagé sur l'autre site ;
c'est-à-dire un nouvel opérateur crée sur ce site, sera
automatiquement crée sur l'autre site. Cette réplication concerne
les tables OPERATEUR (comptes opérateurs) et DATACODE (mots de passe
opérateurs)
· La table RDV du site LIGHT CLICK sera automatiquement
répliquée sur le site Call In Out en fin de journée.
Les données qui ne seront pas répliquées
pourront être consultées à distance au moyen de
requêtes réparties.
V. IMPLEMENTATION
Dans cette nouvelle phase, il est question de réaliser
la solution proprement dite. Toutes les indications de la conception seront
prises en compte en veillant aussi bien sur à la bonne migration de
l'ancien système au nouveau.
Aussi n'oublions pas de mentionner que les deux sites : CIO
(Call In Out) et LC (LIGHT CLICK) seront accessibles à travers
Internet.
V.1. INSTALLATION DE ORACLE ET CREATION DE LA BASE DE DONNEES
La première phase de l'implémentation a
consisté à installer Oracle 10g R 1.5 sur les deux serveurs de
l'entreprise.
Ensuite, nous avons crée la base de donnée
BTELE sur chaque site, utilisant l'utilitaire Assistant de configuration de
base de données, fourni avec ORACLE 10g.
V.2. MIGRATION DE LA BASE ACCESS A LA BASE ORACLE
Etant donné que la base était
gérée par le SGBD ACCESS, il a fallu faire une migration de
ACCESS vers ORACLE. Ce dernier fourni un utilitaire très efficace de
manipulations de bases de données ACCESS, SQL SERVER et ORACLE, ainsi
que de migration d'une plate forme à l'autre. Cet outil qui fait
vaillamment concurrence à TOAD et pourtant gratuit se
nomme SQL DEVELOPPER et à été notre
principal outil de travail. La migration s'est faite en 6 principales phases
:
· Le choix de la base ACCESS et celle de ORACLE
· L'extraction de la structure de la table ACCESS
· Le mappage des types des deux SGBD
· La génération du code ORACLE de
création de ladite structure.
· La création de la structure dans ORACLE (tables,
utilisateurs, procédures, triggers,etc)
· L'importation des données
La migration de données s'est bien effectuée, bien
qu'ayant rencontré quelques difficultés à savoir :
· Certains champs avaient pour nom des mots
réservés de ORACLE comme DATE par exemple. Ces champs ont
été renommés automatiquement durant le processus de
migration en y ajoutant à la fin le caractère `_'. Donc DATE a
donné DATE_
· Le caractère ° n'était pas pris en
charge et devait être remplacé avant la migration
· Etc.
A la fin de la migration, toute la base est désormais
présente sur ORACLE l'utilisateur BTELE est crée.
V.3. CONFIGURATION DE ORACLE NET
Oracle Net a été configuré selon les
critères définis dans la partie II, en utilisant l'outil
netca (Oracle Net Configuration
Assistant).
· Le processus d'écoute est le Listener avec comme
port d'écoute le 5560, port par défaut.
· Les méthodes de résolutions de noms sont
dans l'ordre : la résolution par noms locaux de services, la
méthode Easy Connect.
· Deux noms locaux de services ont été
crées : BTELE_LC (représentant la base BTELE du site LIGHT CLICK)
et BTELE_CIO pour le site Call In Out.
Aussi, pour que les processus d'écoutes soient
accessibles à travers Internet, il a fallut :
· Créer des exceptions pour le port 5560 dans les
firewalls
· Faire la redirection des ports au niveau des routeurs
V.4. CREATION DES DATA LINKS
Afin d'accéder grâce à une requête
à une base à partir d'une autre, nous avons crée les liens
de base de données ou data links. Les requètes suivants
présentent leurs codes de créations.
Sur le site CIO :
Create data base link dbl_lc
Connect to current user
Using btele_lc
Sur le site LC
Create data base link dbl_lc Connect to current user Using
btele_lc
V.5. MISE EN PLACE DE LA REPLICATION
La réplication nous permettra de rendre les tables
liées aux opérateurs (table Opérateur et table
datacode), identiques, afin qu'un opérateur puisse se connecter
indépendamment sur un site ou sur un autre. Elle nous permettra
également de répliquer les statistiques de ventes
régulièrement sur le site principal.
V.5.A. REPLICATION DES DONNEES DES TABLES
OPERATEURS ET DATACODE
Pour la réplication de ces deux tables, nous avons
utilisé des vues matérialisées Le principe est le suivant
: chaque fois qu'il y'a une modification sur la table operateur ou
datacode (insertion, mise à jour ou suppression) sur le site
maître, la modification est directement transmise sur le site esclave.
Ainsi pas besoin de déplacement pour la mise à jour. Pour la
gestion des opérateurs, le site LC considéré comme
maître (dans ce cas) est le seul a faire des changements qui sont donc
ensuite répercutés sur le site CIO.
Nous avons utilisé à cet effet, des vues
matérialisées simples, avec rafraîchissement rapide et
synchrone, sur validation. Les instructions suivantes décrivent les vues
matérialisées définies pour les tables operateur
et datacode.
V.5.A.a. Table operateur
> Première étape, création du
fichier log de la vue materialisée (car le mode de
rafraîchissement est rapide) sur le site LC
CREATE MATERIALIZED VIE W LOG ON OPERATEUR WITH PRIMAR Y KEY
;
|
|
> Deuxième étape, définition de
la vue matérialisée proprement dite sur le site CIO
CREA TE MA TERIALIZED VIEW OPERATEUR REFRESH FAST
WITH PRIMARY KEY
ON COMMIT
as SELECT * FROM OPERATEUR@dbl_lc;
|
|
V.5.A.b. Table datacode
> Première étape, création du
fichier log de la vue materialisée (car le mode de
rafraîchissement est rapide) sur le site LC
CREATE MA TERIALIZED VIE W LOG ON DA TA CODE WITH PRIMAR Y
KEY ;
|
|
> Deuxième étape, définition de
la vue matérialisée proprement dite sur le site CIO
CREA TE MA TERIALIZED VIE W DA TA CODE REFRESH FAST
WITH PRIMARY KEY
ON COMMIT
as SELECT * FROM DATACODE@dbl_lc;
|
|
V.5.B. REPLICATION DE LA TABLE RDV
Comme nous l'avons dit plus haut, la table RDV
très importante pour l'entreprise, doit être
répliquée régulièrement, sur le site CIO sur lequel
les prîmes mensuelles sont calculées. Pour cela, nous avons
utilisé le concept de JOB.
Un Job Oracle est une procédure spéciale
programmée pour s'exécuter au cours d'un temps défini et
selon une régularité aussi définie. C'est
l'équivalent de tâche planifiée dans Windows et
crontab sur UNIX.
Ainsi, dans notre cas, nous allons définir un job qui
copie grâce à l'instruction « insert select » (joue le
même rôle que copy) tous les enregistrements journaliers
effectués sur la table RD V de LC sur la table RD V de
CIO, chaque jour à 23h00. En voici le code :
DECLARE jobno number;
begin
dbmsjob.submit(jobno, 'insert into btele.rdv@dbl _cio select
* from btele.rdv where date_ = to_date(sysdate);Çtrunc(sysdate) +1+
23/24, 'trunc(sysdate) + 1 + 23/24');
commit ;
dbmsjob. run(jobno);
end;
|
|
Le package utilisé pour cela est dbmsjob appartenant
à l'utilisateur SYS. Les trois procédures les plus
utilisées pour ce package sont :
> Dbmsjob.submit(Entier numerojob, chaine
code_a_excecuter, date date_prochaine_execution, chaine
temps_interval)
Cette procedure permet de definer le job !
> Dbms_run(entier numerojob)
Celle-ci permet de declencher un job.
Rapport de fin de cycle Ingénierie Informatique
> Dbms_remove(entier numerojob)
Cette dernière permet de retirer un job
programmé.
V.5.C. CREATION DES VUES
Dans un environnement reparti, il est important d'avoir des
vues générales sur certaines tables ayant subi des fragmentations
horizontales. Cela facilite la consultation desdites données. Dans notre
cas, on a crée une vue des 2 tables tele des deux sites.
> Sur le site CIO
CREATE VIEW VIE W_TELE
AS SELECT * FROM TELE@dbl_lc UNION SELECT * FROM
TELE
|
|
> Sur le site LC
CREATE VIEW VIE W_TELE
AS SELECT * FROM TELE
UNION SELECT * FROM TELE@dbl_cio
|
|
Ainsi, chacune de ses vues nous donne l'ensemble des ventes des
deux
sites.
V.6. MODIFICATION DE L'APPLICATION DE L'ENTREPRISE
L'architecture répartie est donc mise en place. La
communication serveur à serveur est assurée par les data base
links et les différents mécanismes de réplication. Il ne
reste plus qu'à implémenter la communication client-serveur. Cela
revient à :
· Définir les outils ou API qui serviront
à l'application de l'entreprise de se connecter au serveur. La
société Call In Out utilise un programme VB 6 pour gérer
la campagne X avec la méthode d'accès aux données ADODB.
Ainsi, le driver à utiliser doit servir de middleware entre Visual Basic
et Oracle. Il s'agit de :
« Microsoft ODBC for Oracle »,
fournit par Microsoft et présente par défaut dans les machines
Windows. Ce driver permet d'indiquer la chaîne de connexion de l'objet
ADODB.connection qui permettra de se connecter à la base de
données, comme indiqué ci-dessous :
.ConnectionString = "UID= " & uid & ";PWD=" &
pwd &
";DRI VER = {Microsoft ODBC For Oracle}; "SER VER=" &
dBase & ";"
· Modifier certaines requêtes : les requêtes
d'insertion, modification, suppression des tables operateur et
datacode ; on y ajoute l'instruction `commit ;' pour la
validation du rafraîchissement des vues matérialisées.
· Ajouter des options pour faire de la supervision
locale, à distance, ou générale du système, en
utilisant les vues créées et les data base links.
· Renommer les noms d'objets et d'attributs changés
au cours de la migration de MS Access vers oracle.
V.7. MISE EN SERVICE
La mise en service a consisté à installer le
client oracle windows sur tous les postes ou s'exécutent l'application.
Pour cela on a utilisé l'outil 10g_win32_client.zip
fourni par oracle et téléchargeable sur son site à
l'adresse :
http://www.oracle.com/technology/software/products/database/oracle10g/index.
html. , après s'être enregistré. Il contient les
composants ORACLE NET, ODBC, OLEDB,
ODP.NET, NET MANAGER, SQLPlus ,etc.
Le programme client est indispensable pour la connexion
à la base de données. La capture d'écran suivante nous
présente une étape de son installation :
Figure 21 : Client Oracle 10 g
Après l'installation de Oracle Client, il faut faire la
configuration de Oracle Net grâce à Oracle Net Configuration
Assistant, et au cours de laquelle on précise pour chaque poste le
service (BTELE_LC ou BTLE_CIO) auquel il va se connecter.
Et le tour est joué !!
|