Bases de données réparties sous Oracle

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é !!