Système de Gestion de télécopies

Transcription

Système de gestion des télécopies
Maîtrise Génie Informatique
Système de Gestion
de télécopies
Marc Delavaud-Boisis
2003
1
℘Sommaire℘
1. RECAPITULATIF .............................................................................................................3
2. REMERCIEMENTS..........................................................................................................4
3. INTRODUCTION ..............................................................................................................5
4. OBJECTIF .........................................................................................................................7
5. REALISATION DU PREMIER PROJET.......................................................................9
a)
b)
c)
d)
e)
f)
Etude de l’API .............................................................................................................9
Fonctionnement de l’application ............................................................................10
Modification de l’API ................................................................................................12
Réalisation du serveur de stockage ......................................................................15
Envoi de mails...........................................................................................................16
Problèmes rencontrés .............................................................................................16
6. VISUALISATION DES FAX..........................................................................................18
a) Introduction................................................................................................................18
b) Objectif.......................................................................................................................18
c) Réalisation.................................................................................................................19
1) Serveur ...................................................................................................................19
2) Client .......................................................................................................................21
3) Interruption.............................................................................................................21
7. RECEPTION DES FAX 2EME VERSION ..................................................................22
a) Objectif.......................................................................................................................22
b) Réalisation.................................................................................................................23
1) Dépôt dans GED...................................................................................................24
8. CONCLUSION ................................................................................................................27
9. BIBLIOGRAPHIE ...........................................................................................................28
2003
2
1. Récapitulatif
Nom de l’étudiant : Marc Delavaud-Boisis
Date du stage : du 24 février au 07 juillet 2003.
Entreprise : Service de ressources informatiques(CRI) de l’Université de La Rochelle.
Adresse de l’entreprise : Rotonde de l'Arpae ; Avenue Jean Monnet ; 17000 La
Rochelle.
Maître de stage : Monsieur Frédéric Bret, Ingénieur d’études – chef d’exploitation.
Directeur du service : Monsieur Jean-Marc Coris, ingénieur de recherche.
Tuteur à l’IUP : Monsieur Christophe Cros.
Plate-forme Informatique et technique :
Ø PC sous Windows, Linux ;
Ø Serveur HP_UX.
Outils logiciels :
Ø Microsoft VisualC++
Ø WebObjects
2003
3
2. Remerciements
Je tiens à remercier Monsieur Jean-Marc Coris directeur du CRI pour avoir
accepté ma candidature et pour m’avoir accueillit au sein de son service.
Dès mon premier jour au centre de ressources informatiques un P.C. ainsi que
le matériel spécifique à la réalisation de mon stage ont été mis à ma disposition. Mon
sujet de stage me fut clairement expliqué. Pour cela je tiens à remercier Frédéric
Bret pour son implication et pour sa collaboration tout au long de cinq mois.
Je souhaite également faire part de ma reconnaissance à tous les
membres du service, Messieurs Emmanuel Collignon Jean-François Guillaud,
Philippe Berger, Arunas Stockus, Hugues Villesuzanne pour leur pédagogie et leur
assistance précieuse durant ces cinq mois ainsi qu’à l’ensemble du personnel qui ont
contribué à l’existence de conditions de travail exemplaires.
2003
4
3. Introduction
Dans le but de mettre en application mon savoir faire acquis depuis trois ans,
j’ai effectué mon stage de fin d’études au centre de ressources informatiques (CRI)
de l’Université de La Rochelle. Il s’est déroulé sous l’autorité de Monsieur Jean Marc
Coris (directeur) et de Monsieur Frédéric Bret (chef d’exploitation). Le CRI a pour
mission la Gestion des réseaux télématiques, des matériels et logiciels informatiques
ainsi que la mise en place, l’exploitation et le développement de l'informatique de
Gestion de l'établissement. Ce service comprend 24 personnes réparties en trois
groupes. L’équipe logistique composée de deux ingénieurs et d’un technicien a en
charge la gestion du réseau. Cela comprend la maintenance, la sécurité mais aussi
la téléphonie. L’équipe développement logiciels conçoit des applications qui seront
utilisées dans l’Université de La Rochelle mais aussi dans toute la France, cette
section est constituée de neuf ingénieurs et deux techniciens. A ces deux groupes
s’ajoute une équipe de techniciens qui interviennent constamment auprès des
utilisateurs et une antenne situé dans les bâtiments de la faculté de sciences. (Voir
organigramme joint en annexe).
Au départ mon sujet de stage portait sur la mise en place des réseaux WIFI(802.11.x) dans l’Université. Cette technologie réseau sans fil se base sur une
liaison utilisant des ondes radioélectriques(radio et infrarouge) en lieu et place des
câbles habituels. Les réseaux sans fils permettent de relier très facilement des
équipements distants d'une dizaine de mètres à quelques kilomètres. De plus
l'installation de tels réseaux ne demande pas de lourds aménagements des
infrastructures existantes comme c'est le cas avec les réseaux filaires (creusement
de tranchées pour acheminer les câbles, équipements des bâtiments en câblage,
goulottes et connecteurs), ce qui a valu un développement rapide de ce type de
technologies. Malheureusement le flou législatif qui entoure cette technologie,
notamment dans les lieux publics ou semi-publics, a incité le CRI à attendre avant de
mettre en place cette technologie.
Mon stage s’est alors orienté vers un besoin plus pressent pour l’Université :
renouveler les systèmes de réception des télécopies. La réception des télécopies est
gérée par le CRI au même titre que tous les autres systèmes téléphoniques
(téléphone filaire, mobile, télécopieur en émission). L’émission se fait grâce aux
télécopieurs présents dans chaque service. Afin de pouvoir gérer et surtout
conserver de manière électronique les télécopies entrantes, celles-ci sont traitées
informatiquement. Le système actuel de réception des télécopies est supporté par
des stations NEXT qui datent de la création de l’Université (1993). Ce système était
fort encombrant car il comprenait huit stations, de plus l’ancienneté de celles-ci
rendait difficile toute mise à jour ou réparation. Cet ensemble occupe un local
technique qui pourrait être utilisé plus judicieusement.
2003
5
Il s’est donc avéré nécessaire de remplacer cet ensemble de machines par
un dispositif plus compact et évolutif. Le choix s’est porté sur une carte serveur de
fax PCI pouvant supporter deux modems, ceux-ci se trouvant en sortie du dispositif
Autocommutateur. Ce dernier gère toutes les opérations de téléphonie, fax
entrantes, sortantes et internes aussi bien au sein de l’Université que vers
l ‘extérieur.
L’autocommutateur est un équipement organisant les communications et le
raccordement au réseau téléphonique commuté (RTC). L'autocom est capable de
gérer non seulement des conversations téléphoniques (à deux ou plus), mais aussi
des données informatiques en tous genres.
2003
6
4. Objectif
Même si l’on désire moderniser le système, le but est de conserver le mode
de fonctionnement actuel. Jusqu'à présent les télécopies étaient stockées sur un
serveur. Ce stockage consiste à placer les télécopies dans une arborescence
spécifique en fonction du numéro de leur destinataire. Une impression automatique
est aussi lancée sur l’imprimante du service concerné lorsque la télécopie est reçue.
Actuellement la plupart des services de l’université possèdent leur propre numéro de
fax, cela représente une quinzaine de numéro. Le volume de réception est très
variable selon les services. En effet ceux qui reçoivent beaucoup de télécopies sont
les services qui communiquent énormément avec l’extérieur comme par exemple les
services centraux. Par exemple au CRI j’ai pu constater que l’on recevait en
moyenne trois télécopies par jour, ce qui ne constitue pas un énorme volume de
traitement !
Avec l’aide de mon maître de stage nous avons élaboré les lignes directrices
de ce stage :
Ø Recevoir les télécopies et en extraire différents paramètres (expéditeur,
destinataire). Placer le document dans un fichier au format tiff (image).
Ø Stocker ces télécopies sur un serveur de stockage distant afin de les
sauvegarder afin de pouvoir les réutiliser.
Ø Reprendre (ou refaire si besoin) l’application de visualisation des fax pour
la rendre plus rapide et facile d’utilisation.
La réalisation de ce projet rassemble plusieurs domaines de compétences :
la téléphonie, la programmation C/C++, Java, le transfert de fichiers, les bases de
données, réseaux et systèmes. Comme on peut le voir sur le schéma suivant, le
système reposera sur quatre applications : deux serveurs et deux clients. On peut
décomposer ce schéma en deux blocs : la partie supérieure gère la réception et
celle du bas le traitement. Des sockets seront utilisés pour assurer la communication
entre deux postes distants. Cette solution s’appuie sur le réseau de l’université fiable
et rapide. On dispose également d’un serveur de mails et d’imprimantes réseaux.
2003
7
Visualisation des différentes applications
2003
8
5. Réalisation du premier projet
a) Etude de l’API
L’application de réception sera développée en C/C++. D’un point de
vue pratique le client de réception de fax est un PC sous Windows 2000
comportant une carte PCI de marque EICON et de type Diva Server BRI.
Cette carte permet de recevoir deux fax simultanément. Elle est reliée au
dispositif autocommutateur par l’intermédiaire de modems, et reçoit tous les
fax entrants. Pour cela l’autocommutateur est configuré de façon à diriger
tous les appels entrants de type fax vers le bus menant à cette carte. Un
des avantages de cette dernière est son API très complète et facilement
modifiable. Cette API fonctionne grâce à un SDK (software développment
kit), elle permet de développer des applications de communication.
De nombreux exemples y sont présents et mon permis de comprendre
son mode de fonctionnement. Ainsi j’ai découvert la topologie d’une ligne
téléphonique et de ses différents canaux.
La carte comporte trois API propres à chaque couche :
2003
9
•
La Diva Server Api, que j’ai utilisée car elle permet
d’implémenter
simplement
des
applications
de
communication
•
Extended CAPI 2.0 fournit une extension Eicon CAPI
compatible avec CAPI 2.0.
•
Diva Server Management API est la couche basse, elle
permet d’intervenir directement sur le hardware afin
d’effectuer des contrôles ou des statistiques.
Ces dernières permettent le management et la conception
d’applications pour toutes les cartes Diva Server. La Diva Server Api est une
interface de haut niveau entre la carte et les appels aux fonctions écrites en
C. Elle permet un interfacage plus simple qu’avec CAPI 2.0 et possède deux
niveaux. Le niveau basique contient des modules qui peuvent être utilisés
pour des applications de communication comme les fax ou les transferts de
voix. Le niveau étendu permet d’exploiter pleinement les capacités de la
carte. Ces deux niveaux sont parfaitement compatibles et peuvent être
utilisés dans la même application. L’api inclue également des outils de
conversion graphique qui permettent de transformer les bits arrivants sur la
ligne téléphonique en fichiers images.
En général l’établissement d’un appel est un processus asynchrone, il
dépend du protocole utilisé, un fax est une information qui est échangée
entre deux parties. Lorsque cette information est disponible l’application
diffuse l’événement. Il appartient alors à l’application de le traiter ou non. Ces
événements peuvent être captés de différentes manières : fonction de
callback, enregistrement de l’événement, poster un message dans la boucle
de message.
b) Fonctionnement de l’application
Du point de vue de l’I.H.M. cette application se compose d’une fenêtre
principale permettant de visualiser en temps réel les connexions à la carte.
On peut y voir le numéro appelant s’il n’est pas caché. Deux boutons
permettent de démarrer/arrêter l’attente d’appel. A cette fenêtre s’ajoute une
fenêtre d’options permettants de choisir le type de fichier dans lesquels
seront sauvegardés les fax ainsi que le répertoire de stockage.
Cette interface permet le contrôle en temps réel de tous les appels
arrivants sur la carte, de connaître le numéro appelant et appelé. En cas de
problèmes elle permet de savoir si la carte répond aux appels.
2003
10
Le fonctionnement de cette application de réception est le suivant :
Au lancement le serveur de fax s’initialise en renseignant une structure
sur les spécificités de la carte, de la ligne et divers renseignements. Cela
comprend entre autre le nombre de lignes, de canaux et la capacité à
recevoir des fax. Il crée un événement et un thread qui seront les moteurs de
l’application. Une vérification est ensuite faite sur la disponibilité de chaque
ligne pour recevoir des fax. Enfin chaque ligne est mise en attente de
réception d’un appel.
Voici les différents événements qui sont gérés par le thread :
•
•
•
•
•
•
•
appel entrant
de nouvelles informations sur l’appel
progression de l’appel
appel connecté
fax reçu
page reçue
appel déconnecté
2003
11
Ensuite le Thread est activé et se met en attente d’événements pour un
temps infini. Un événement est généré lors d’un appel entrant, durant la
progression de l’appel, à la clôture de la réception, à la clôture de l’appel.
Lorsqu’un fax est reçu, une structure descriptive est crée. Cette dernière
contient entre autres renseignements le numéro d’appelé, le nombre de
pages, la vitesse de connexion…
c) Modification de l’API
Les modifications apportées à cette API furent les suivantes :
•
Transfert
Les fax doivent être stockés de façon permanente sur un
serveur Unix (le détail de ce fonctionnement sera détaillé par la
suite). Pour cela le fax doit être transféré du client (Windows) vers
le serveur (Unix) grâce à une socket. L’implémentation des sockets
sous Windows s’est fait grâce à la librairie Winsock.
Si l’on excepte l’initialisation du socket, qui elle est
spécifique avec l’appel à la routine WSAStartup pour le lancement
et WSACleanup pour la clôture, les appels systèmes sont
identiques à Unix. Il faut premièrement créer une socket qui va
utiliser le protocole TCP. Celle ci va tenter de se connecter au
serveur de stockage grâce à son adresse IP et à un port. Cela se
fait grâce à la routine connect. Si cette connexion est acceptée par
le serveur, le client va lui envoyer une structure descriptive du fax.
Ainsi lorsque la réception du fax est accomplie, ce dernier
est sauvegardé localement. Une socket est crée entre le client et le
serveur, on peut alors transmettre la structure descriptive du fax
ainsi que le document lui-même.
Pour cela la structure est déclarée de façon identique coté
serveur et coté client.
Il est nécessaire d’extraire différents paramètres (numéros
de fax, taille du document, date, durée de l’appel…) pour remplir
cette structure. Les envois sur la socket se font grâce à la routine
send() qui renvoie le nombre d’octets envoyés. Si ce premier envoi
se passe bien, le document (au format tiff) est envoyé au serveur
dans le but d’être stocké. Pour clôturer cet envoi le client reçoit le
md5 du document calculé par le serveur. Si ce md5 est identique à
celui calculé par le client les fichiers pourront alors être supprimés
de la machine cliente sinon l’envoi sera renouvelé.
2003
12
L'utilitaire md5 permet de calculer l'empreinte d'un fichier.
L'empreinte d'un fichier est une valeur de 128 bits correspondant à
une somme de contrôle calculée à partir du fichier et qui permet la
vérification de l'intégrité des données téléchargées.
En vérifiant avec md5 l'empreinte d'un fichier téléchargé et
en la comparant avec celle que l'auteur aura publiée, il est possible
de déterminer si le fichier téléchargé est différent de l'original.
Si après n tentatives le fichier n’est pas transféré, un mail est
envoyé au « fax-master » afin de le prévenir.
De plus lors du démarrage de l’application, un timer est lancé
afin de vérifier périodiquement la présence de fax qui n’aurait pas
été transmis. Les causes de non-transmission peuvent être : une
panne réseau, l’application de stockage qui ne fonctionne pas. Si
tel est le cas, l’application tente de renvoyer le fax. Ce système
s’avère utile car il permet, lorsque le serveur de stockage est
indisponible, d’éviter
une intervention humaine. La fonction
setTimer permet de lancer à intervalle régulier une fonction de
callback. Cette dernière capte les appels du timer et scanne le
répertoire de spool. S’il contient des fax une procédure d’envoi est
mise en place. Cette notion de « spooler » est vaste, on peut
associer ce terme à plusieurs signification. « Spool » est
l’abréviation de « simultaneous peripherial operation on-line ». La
définition du dictionnaire nous apprend qu’il s’agit d’un programme
qui se charge de récupérer les données envoyées vers un
périphérique, qui les met dans une file d’attente, servant aussi de
tampon, et ne les envoie que lorsque le périphérique est prêt.
•
Impression
Les fax ne sont pas dirigés vers une personne particulière
mais vers un service de l’Université ainsi lors de la réception une
impression automatique doit être lancée depuis le client vers
l’imprimante du service. Tout d’abord il a fallu installer les drivers
des imprimantes de tous les services, qui sont de type postscript,
sur le P.C. contenant la carte de réception. Chaque document est
donc converti du format tif vers le format postscript, ceci grâce à la
librairie « libtiff » et en particulier à la fonction « tiff2ps ».
Une fois converti en postscript le contenu du fichier est
placé dans un buffer qui sera envoyé à l’imprimante.
2003
13
Une série de fonction est nécessaire pour lancer
l’impression. Il faut premièrement créer un « device context »
propre à l’imprimante, le programme va s’appuyer sur le driver
installé sur le système d’exploitation pour connaître les spécifités et
les capacités de l’imprimante. Puis on démarre l’impression du
document en envoyant les données postscript dans le spooler de
l’imprimante. En C il existe des fonctions réalisants ce transfert.
Ces dernières utilisent des sockets pour transférer les octets du
document postscript. Comme pour le transfert des fax vers le
serveur de stockage, un mail est envoyé à fax-master s’il y a un
problème.
2003
14
•
Gestion des erreurs
Une attention particulière à été apportée à la gestion des
erreurs et en particulier la faculté de l’application à poursuivre son
exécution malgré les erreurs. Toutes les erreurs sont inscrites dans
un fichier de log avec leur date. Le fait que le serveur de stockage
soit momentanément indisponible n’est pas un frein au bon
fonctionnement de l’application. En effet périodiquement une
routine vérifie si des fax n’ont pas été transférés en scannant le
répertoire de stockage local. Ainsi le risque de perdre un fax est
nul.
Lorsque le réseau est indisponible ou que le serveur de
stockage est hors service la réception de nouveau fax se poursuit.
Ainsi si le transfert du fax est impossible au moment n il sera peut
être possible au moment n+1.
d) Réalisation du serveur de stockage
Les fax doivent être conservés afin de pour les traiter ultérieurement ou
bien les consulter. Le but de ce serveur de stockage est de placer les
télécopies transmises par l’application de réception dans un répertoire
spécifique au service destinataire. Ensuite il stocke le fax au format tif et
complète le fichier de log afin de notifier l’arrivée d’un nouveau fax dans ce
service.
La réception du fax se fait grâce à une socket dont ce module est le
serveur. Le serveur se met en attente de connexion, lorsque celle ci est
établie par l’application de réception, il reçoit la structure descriptive du fax.
Un fichier recevant le document est crée. Ce dernier est nommé en utilisants
la date et l’heure de la réception. Il sera donc aisé de retrouver un fa x
connaissant sa date d’arrivée. On extrait ensuite le numéro de destinataire
afin de connaître le répertoire dans lequel va être stocké le fax. En effet
chaque service possède son répertoire de stockage avec son propre fichier
de log répertoriant les fax arrivés. Une fois le transfert du document effectué,
par paquet de 1000 octets pour ne pas surcharger le réseau, un accusé de
réception est envoyé au client(md5).
Physiquement ce serveur de stockage est un démon qui tourne sur une
station HP_UX. Il ne possède pas d’interface graphique car il tourne en tâche
de fond. Le socket est constamment à l’écoute d’un port afin de recevoir les
fax transmis par le client.
2003
15
Nous allons maintenant décrire le mode de fonctionnement des sockets
sous Unix. Un socket se crée grâce à la routine socket à laquelle on spécifie
le domaine d’adresse, le type de socket et le protocole. Ici nous avons utilisé
un domaine d’adresse Internet en mode connecté par le protocole TCP.
Après sa création un socket n’est connu que du processus qui l’a crée. Il doit
être désigné par une adresse pour pouvoir être contacté de l’extérieur. Pour
cela on utilise la primitive bind qui va associé l’adresse locale(IP) et un port
au socket. Ensuite on déclare l’ouverture du service auprès du système local
grâce à listen qui est bloquant en attente de connexion. Lorsqu’une
connexion est demandée par un client la routine accept retourne un
descripteur vers un socket qui va servir à la communication. Pour
communiquer les deux parties utilisent les routines send et recv. Une fois la
communication achevée close() permet de fermer le socket de
communication et de libérer les ressources.
e) Envoi de mails
Nous avons vu précédemment que lorsqu’un problème ne pouvait être
résolu par l’application elle-même, cette dernière envoyait un mail à « fax
master » afin de le prévenir.
L’envoi automatique de mail ressemble fort au transfert de fax
précédemment expliqué. Un mail est une structure qui comporte les champs
suivants : un expéditeur, un destinataire, un objet et un contenu. On remplit
ces champs avec des chaînes de caractères puis on assemble le mail.
Ensuite on établit une connexion toujours via socket jusqu’au serveur
de mail de l’université. Le mail est alors transmis au serveur de mail par
requête SMTP qui se charge de l’envoyer au destinataire.
f) Problèmes rencontrés
En premiers lieux il m’a fallu me familiariser avec les spécificités liées à
la téléphonie et en particulier à la télécopie. Par exemple l’utilisation de
chacun des canaux d’une ligne, la transformation d’un appel en un fichier
image.
Les sockets sont établies entre des systèmes différents, qui ne gèrent
pas les droits de la même manière. Ainsi au départ mon programme de
stockage ne pouvait pas créer de fichiers. De plus l’implémentation des
sockets sous Windows requiert quelques spécificités notamment pour les
initialiser grâce à la librairie winsock.
2003
16
Lors du transfert de la structure du poste Windows vers le poste Unix
un problème d’inversion de bit est apparu. J’ai donc crée une fonction
d’inversion pour transformer les long du mode « big endian » vers « little
endian ».
2003
17
6. Visualisation des fax
a)Introduction
A l’Université chaque personne peut visualiser ses fax grâce à
l’application FaxViewer réalisée en objective C. Le remplacement de cette
dernière est nécessaire. Sa lenteur liée à son mode de fonctionnement
constitue un handicap pour une utilisation quotidienne. En effet l’application
récupère le login de l’utilisateur et après plusieurs jointures dans la base de
donnée arrive à connaître le service dont fait partie la personne. Ensuite le
répertoire du service est scanné pour trouver tous les fax présents, le
problème est que certains services ne nettoient jamais leur répertoire et
possèdent près de 3000 fax ! Tous ces traitements sont réalisés par chaque
client, il convenait donc de réaliser une application client/serveur. Le but du
serveur est d’anticiper les demandes du client afin d’accélérer le
fonctionnement.
b) Objectif
En accord avec mon maître de stage nous avons décidé de concevoir
un nouveau mode de fonctionnement. Cette application devra être réalisée
en webobjects, elle sera accessible via une page Web. L’accès en sera limité
aux responsables et secrétaires de chaque service. Ces derniers
visualiseront les fax destinés à leur service et pourront les voir, les supprimer
et principalement les affecter à une ou plusieurs personnes. L’affectation
consistera à envoyer un mail contenant une url pointant vers le fax au format
pdf. Ce système permet de limiter la taille des mails. Pour accélérer le
fonctionnement, l’application sera scindée en deux parties. Un serveur qui,
de manière répétitive, préparera des listes de fax pour chaque service.
Chaque client récupérera la dernière liste fabriquée par le serveur. Ce
système permet d’éviter que chaque client parcoure l’arborescence de
stockage. C’est à dire qu’aucun client n’a un accès direct aux systèmes de
fichiers de stockage, il émet seulement des demandes au serveur.
2003
18
c) Réalisation
1) Serveur
J’ai commencé par concevoir la partie serveur de cette application.
Celle-ci est entièrement programmée en Java afin de s’intégrer à
l’environnement de programmation WebObject 5.2. Ce démon tournera sur le
serveur de stockage qui est une station HP_UX. Un timer est lancé au
démarrage et le démon se met en attente de connexion vers un client. Le
timer exécute périodiquement une fonction qui génère les listes. A partir du
répertoire de stockage général on peut accéder au répertoire propre à
chaque service. Si ce répertoire contient des fax, leur validité est vérifiée puis
leurs paramètres sont extraits du fichier de données. En effet un fax est un
couple de fichier : l’un contenant le document au format tif et l’autre
contenant les données relatives à la communication(expéditeur
destinataire…).
Insérer shema arborescence
Le langage Java possède une API File permettant entre autre de lister
les sous-repertoires d’un répertoire. Ici les sous-repertoires du répertoire de
stockage général porte le nom d’un service. A la racine de chaque service
sont placé les nouveaux fax et un répertoire Read contient les fax déjà lus.
Les listes précédemment citées sont des Vectors (tableaux dynamiques)
contenant des objets Fax. Le constructeur de l’objet Fax extrait les
informations relatives au fax depuis le fichier de données.
Ainsi s’il existe un couple de fichier portant le même nom avec
l’extension .fax(document au format tif) et .ctl (fichier contenant les
informations relatives à l’appel) : il s’agit d’un fax. Il peut donc être traité. Le
traitement consiste à lire les informations depuis le fichier. ctl et à les insérer
dans l’objet Fax. Le format des fichiers .ctl est maîtrisé car ceux-ci sont crées
par le démon de stockage traité précédemment. Le document n’est pas
inséré dans la liste, il sera lu seulement si le client demande à le visualiser.
2003
19
La communication avec le client se fait via une socket. En Java les
socket sont matérialisés par un buffer sur lequel on peut lire ou écrire. J’ai
crée un protocole de communication entre le client et le serveur. La
communication est toujours entamée par le client qui une fois connecté
envoie le service dont fait partie l’utilisateur. A la suite le client envoie la
commande qu’il désire ; voici les différents types de commande :
•
« liste » : Demande de liste contenant les fax du service. Le serveur
répond en envoyant la liste la plus récente de ce service.
•
« affecte »+ fax + expéditeur + destinataire : Le fax doit être affecté
au destinataire. Le serveur affecte le fax au destinataire.
« supprime » +fax : Demande suppression du fax. Par soucis de
restauration le fichier n’est pas réellement supprimé mais déplacé
vers un sous répertoire du service nommé Archives.
•
•
« lire » + fax : L’utilisateur demande à visionner le document. Le
serveur rend le document pdf accessible.
Nous allons maintenant étudier le fonctionnement de chacune de ces
fonctionnalités. La création et la mise à jour des listes sont indépendantes
des demandes des clients puisqu’elle se fait grâce à un timer. Ainsi toutes
les x secondes les listes sont rafraîchies ; lors d’une demande par le client
une copie de la dernière liste d’un service est envoyée par socket.
Concrètement les listes sont placées dans une table de hachage dont la clé
est le nom du service.
L’application cliente n’est accessible qu’aux secrétaires et responsables
d’un service. Ces derniers peuvent affecter un fax à une autre personne via
son email. Le serveur va recevoir les adresses emails de l’expéditeur et du
destinataire. Ensuite il construit le message dynamiquement et y insère un
lien vers le document transcrit en pdf(par soucis de portabilité). Ce mail
assemblé, il est transféré au serveur de mail de l’université. La
transformation du document en pdf se fait grâce à la librairie libpdf. Le
serveur renvoie au client un booléen sur la réussite de l’opération. Si celle-ci
aboutit le fax est transféré dans le répertoire archives.
La suppression effectue un déplacement du fax dans le répertoire
Archives. Ainsi il n’apparaîtra pas dans les futures listes de fax.
Lorsque le client demande à lire un fax ce dernier est transcrit en pdf et
est rendu accessible depuis un autre pc. L’url pointant vers ce fichier est
envoyée au client.
2003
20
2) Client
Cette partie doit pouvoir communiquer facilement avec les bases de
données et s’intégrer avec les autres applications de l’Université. On a donc
aussi choisi l’environnement de développement WebObjects.
Comme nous l’avons énoncé dans les objectifs, cette application n’est
accessible que par les responsables et les secrétaires des services. Elle
débute donc par une phase d’authentification. L’utilisateur renseigne son
login de l’Université et son mot de passe. Le programme se connecte à la
base de donnée (voir modèle ci-joint) et vérifie l’existence du login. Parmi
tous les logins présents on ne garde que les logins qui n’appartiennent pas
au Vlan étudiants. En effet à l’Université certaines personnes possèdent
plusieurs comptes (personnel et étudiants). Les catégories se distinguent par
leur appartenance à un Vlan. Comme un étudiant ne peut être ni secrétaire,
ni responsable : on exclue ce groupe. Ainsi il ne doit rester qu’un login car il y
a unicité des login au sein d’un groupe. Ensuite on vérifie l’exactitude du mot
de passe. Celui ci validé, on recherche tous les services dont fait partie
l’utilisateur et pour chacun d’eux on regarde s’il est soit secrétaire soit
responsable. Il est possible qu’une secrétaire exerce dans plusieurs service,
dans ce cas elle doit choisir l’un d’entre eux. Si la personne a passé tous ces
tests avec succès elle peut enfin pénétrer dans l’application.
L’utilisateur est donc associé à un service unique, une demande de liste
de fax est faite au serveur. Grâce à cette liste, on crée un tableau contenant
les nouveaux fax. L’utilisateur peut donc les visualiser, les supprimer, les
affecter. Chacune de ces fonctionnalités correspond à une commande qui
est envoyée au serveur par socket. L’utilisateur peut également rafraîchir sa
liste de fax au moyen d’un bouton.
3) Interruption
Cette application de visualisation des fax était quasiment réalisée
lorsque j’ai du présenter l’avancement des mes travaux à Monsieur Coris,
directeur du centre de ressources informatique. J’ai ainsi présenté mes
applications réalisées sous la surveillance de mon maître de stage Monsieur
Bret. Dans le but de mieux intégrer la gestion des fax au fonctionnement de
l’Université, Monsieur Coris a défini de nouveaux objectifs.
2003
21
7. Réception des fax 2eme version
a) Objectif
Le dispositif présenté en première partie se composait de quatre
applications : une pour la réception, un démon de stockage, un client pour la
visualisation associé à un serveur. Du point de vue de la maintenance un tel
système n’était pas optimal. De plus pourquoi utiliser un dispositif différent
pour les fax, les courriers ou tout autre type de documents. L’université
possédant déjà un serveur de gestion électronique de documents (GED),
l’objectif est donc d’y intégrer les télécopies. Nous conservons la partie
réception comprenant la carte PCI et l’application utilisant l’API Eicon. A cette
dernière nous couplons une application WebObjects qui va incorporer les
télécopies dans GED.
2003
22
b) Réalisation
Le fonctionnement de GED repose sur plusieurs tables dans la base de
données. Un agent peut déposer des documents classés par type, un document peut
avoir des destinataires, un fichier attaché. Dans notre cas il s’agit de déposer un
document de type fax destiné aux secrétaires du service destinataire, la télécopie au
format pdf est jointe à ce document.
GED repose sur un ensemble de tables jointes entre elles. Vous pouvez voir
le schema de ces tables sur la figure no. Toutes les tables s’articulent autour de
Courrier. Un courrier est associé à un TypeCourrier et chaque agent a accès à n
Typecourrier. Un agent est une personne qui peut déposer des documents, il ne peut
le faire que dans les types dont il a les droits d’accès. Un Courrier peut être rattaché
à des destinataires, à des fichiers via la table ReferenceLien. Une fois déposé les
documents sont consultables via un navigateur web ou bien grâce à une application
spécifique.
En ce qui concerne la réception, J’ai donc repris mon application décrite
précédemment en simplifiant son action. Les fax entrants sont stockés localement
sur la machine contenant la carte fax. Il s’agit de trois fichiers(donnée annexe,
document pdf, document tiff). Ces trois fichiers portent le même nom mais avec une
extension différente. Le nom de ces fichiers est généré automatiquement grâce à la
fonction getTickCount() .Cette fonction renvoie le nombre de millisecondes écoulées
depuis le démarrage de l’ordinateur. Cela permet une unicité dans les noms des
fichiers. Voici les informations contenues dans le fichier de données (.dat) :
Received:
19_05_2003-16h35_15s
Speed:
14400
Pages:
1
ECM:
YES
Coding:
MMR
Used B Channel: 1
FileFormat: TIFF
Resolution: HIGH
Calling Number: 0546458621
Called Number: 0546458245
Remote Fax ID: 0546458621
2003
23
Les renseignements les plus importants sont la date d’arrivée et le numéro appelé.
Le champ speed correspond à la vitesse de réception du fax. ECM désigne si le
protocole de gestion d’erreur « Error Correction Mode » a été activé. Physiquement,
un accès RNIS consiste en un câble composé de 2 fils. Logiquement, cela consiste
en 2 types de canaux de communication :
- Les canaux B, qui transportent les données et services à 64 kbit/s chacun.
- Un canal D unique, qui transporte les informations de signalisation à 16 kbit/s
pour les accès de base (S 0) ou à 64 kbit/s pour les accès primaires (S 2).
« Remote Fax ID » est un champ qui n’est pas toujours rempli car il doit être
renseigné manuellement par l’utilisateur du fax qui envoie la télécopie. Il s’agit
d’une chaîne de caractère identifiant le fax, on peut y rentrer son nom ou le
numéro de son fax.
D’autre part un fichier de log est complété à chaque connexion même si elle n’aboutit
pas. Il est placé dans le répertoire de spool local avec les nouvelles télécopies. Ce
fichier de log est très utile pour la maintenance et le dépannage. En plus des
informations présente dans le fichier .dat, il indique pour chaque connexion si elle a
aboutit et sinon pourquoi. On peut également connaître le nom des fichiers générés
en fonction de l’appel.
Cette application se lance automatiquement au démarrage de l’ordinateur en
se plaçant en attente d’appel.
1) Dépôt dans GED
L’application de dépôt des télécopies dans GED est
WebObjects5.2. Cet environnement de développement permet de
applications serveur java. Ainsi j’ai réalisé un serveur en liaison avec
données. Son but est de vérifier périodiquement l’arrivée de nouvelles
de les traiter afin de les insérer dans le dispositif GED.
réalisée en
réaliser des
les bases de
télécopies et
Au lancement le serveur se connecte à la base afin de charger différents
paramètres. Il charge l’url ainsi que le port d’accès du serveur GED. Dans GED les
documents sont obligatoirement déposés par une personne physique. Ici cet individu
est le « responsable » de l’application, avec plusieurs jointures on obtient son
numéro d’individu et son email afin de le prévenir en cas de problème. Les
documents sont classés par type, ces types ont une parenté entre eux. Fax est un
sous-type de Courrier et chaque service est un sous type de Fax.(voir schéma). Les
cordonnées du type Fax sont chargées au démarrage.
Un Timer est crée, il lancera toutes les n secondes une routine qui va vérifier
l’arrivée de nouvelles télécopies. Pour cela il scanne le répertoire local de spool à la
recherche d’un triplet de fichiers aya nt le même nom.
2003
24
Lorsqu’un triplet est détecté, un objet Fax est crée. Lors de la création de
l’objet Fax, les données sont extraites du fichier .dat. La connexion entre le serveur
GED et l’application est établie. Ensuite il faut trouver le service destinataire de ce
fax. Pour cela j’utilise le numéro appelé présent dans le fichier .dat et la table
PersonneTelephone qui associe des numéros à des individus ou à des services. Ma
requête consiste à récupérer tous les services associés à ce numéro.
Pour chaque service destinataire je lance une impression sur leur imprimante.
Les imprimantes associées à un numéro de fax sont présentes dans la table
télécopieurs. On peut ainsi retrouver le nom réseau de toutes les imprimantes
associées à un télécopieur. Au départ le but était de pouvoir imprimer la télécopie en
ne possédant que l’ip de l’imprimante et le fichier postscript. Les imprimantes sont
toutes de marque HP et possède un serveur ftp. Il suffisait donc de lancer une
connexion ftp anonyme vers l’imprimante. Ensuite la commande « put » permettait
d’envoyer le document postscript afin qu’il soit imprimé. Le document postscript est
généré à partir du document au format tiff et à la fonction tiff2ps. L’impression par ftp
est très simple car il faut seulement connaître l’ip de l’imprimante par contre aucun
retour sur le succès de l’impression n’est donné. Le problème est que l’imprimante
ne possède pas de disque dur afin de stocker les fichiers. Donc lorsque l’imprimante
est occupée ou que le bac à papier est vide ou quand il n’y a plus d’encre :
l’impression est perdue. En effet le serveur ftp de l’imprimante coupe toute connexion
qui dépasse 300 secondes, ce qui laisse peut de temps à l’utilisateur de l’imprimante
pour se rendre compte qu’il n’y a plus de papier et en remettre ! Cette solution a
donc été abandonnée car la probabilité d’indisponibilité d’une imprimante était trop
grande.
Nous avons donc utilisé le protocole lpr qui permet d’envoyer un travail
d’impression vers une imprimante réseau. Par contre l’installation de drivers est
nécessaire ce qui complique le système en cas de changements d’imprimante.
Malheureusement nous n’avons pas trouvé de moyen d’imprimer à distance en ne
connaissant que l’ip de l’imprimante sans drivers, sachant que ce procédé doit être
résistant aux indisponibilités de l’imprimante. En utilisant lpr, si l’imprimante n’est pas
disponible, le travail d’impression est spoolé en local. Lorsque l’imprimante est à
nouveau prête les travaux sont relancés. De plus ce protocole permet de connaître,
en cas de problème, l’intitulé de l’erreur.
Le but principal de ces impressions est de permettre au membre du service de
pouvoir visualiser les télécopies en l’absence de la secrétaire. En effet l’application
Gedi gère les droits. Ainsi si vous n’êtes ni dépositaire ni destinataire du document,
vous ne pouvez le visualiser.
Ensuite pour insérer cette télécopie dans GED, il faut créer un nouveau
document. L’opération commence par une connexion au serveur grâce à l’url et au
port récupéré au lancement. Ce document comporte les champs suivant : objets,
message, référence, expéditeur, nom du dépositaire, date. Ces champs remplis, on
insère l’objet dans la table Courrier. La deuxième étape consiste à associer le fichier
pdf au document. Si l’association réussie le serveur GED nous renvoie l’url à
laquelle on peut consulter la télécopie. Celle ci sera envoyée par mail aux
destinataires.
2003
25
La dernière opération est l’affectation des télécopies. Cette dernière est
totalement dynamique car elle s’appuie sur la base de donnée. En effet à partir du
numéro de destinataire, je trouve le service puis les secrétaires de ce service.
Chacun(e) de ces secrétaires est placé(e) dans la table destinataires. Ensuite un
mail leur est envoyé, il contient les renseignements sur le fax ainsi qu’un lien vers la
télécopie au format pdf.
Si toutes ces opérations sont réussies, les trois fichiers peuvent alors êtres
supprimés du répertoire de spool local.
2003
26
8. Conclusion
En ce qui concerne les travaux que j’ai développés, les objectifs ont été
atteints. La démarche fut la suivante, étude des possibilités de la carte,
développement des applications et enfin phase de test.
En effet on peut être confiant quant à la mise en exploitation de ce système,
je l’ai testé durant trois semaines en dirigeant les fax destiné au CRI vers mon
système.
Les objectifs d’un stage professionnel sont multiples : il faut que le stagiaire
tire une double expérience (immersion dans le monde du travail et acquisition de
nouvelles connaissances dans le domaine d’activité de l’entreprise) et qu’il puisse
apporter à l’entreprise un bénéfice aussi bien sous forme de nouvelles compétences
liées à sa formation que par sa personnalité.
La durée de ce stage - cinq mois à temps plein - se révèle être une expérience
dans le monde du travail très bénéfique. En ce qui me concerne, cela représente à
ce jour ma plus longue insertion dans le monde du travail. J’ai réellement pu
dépasser le stade de " formation " qui est une étape obligatoire lorsque l’on arrive
dans une nouvelle entreprise. Ensuite, le stage devient une vraie expérience
professionnelle puisque j’ai été amené à travailler de manière autonome.
Ce stage a été également l’occasion de découvrir le secteur de la gestion de
réseaux a grande échelle ainsi que le développement d’application professionnelles.
(mes seules connaissances préalables dans ce domaine étaient celles que j’ai pu
acquérir lors de mes enseignements à l’iup). J’ai résolu cela en me documentant sur
le sujet avant le début de stage puis durant ce dernier. Pendant celui-ci, j’ai aussi
acquis des connaissances grâce aux explications de mon maître de stage. Cette
expérience a également été l’occasion de me familiariser avec des méthodes et des
outils de travail nouveaux.
Ce stage a donc été bien plus qu’un " stage-découverte ". Il a répondu à mes
attentes aussi bien au niveau professionnel qu’en terme de compétences relatives au
sujet de mon stage et au savoir-faire nécessaire pour toute autre activité
professionnelle. De plus, j’ai le sentiment d’avoir donné entière satisfaction à
l’entreprise qui m’a accueilli. Il me paraît donc tout à fait justifié de conclure que ce
stage a été une réussite pour le CRI et pour moi.
2003
27
9. Bibliographie
♦ « PDFlib Reference Manual » de Thomas Merz .
♦ « Programmation des sockets sous Unix » Hafid Bourzoufi, Dider donsez ,
Université de Valenciennes.
♦ « Diva server API developer’s reference guige » Eicon ainsi que diverse
documentation disponible sur www.eicon.fr.
♦ RFC 1179 sur le protocole « Line printer Deamon » (lpr).
2003
28
2003
29

Système de Gestion de télécopies

Transcription

Documents pareils

Dans Mac OS X Tiger, vous pouvez envoyer des

COMMIS DE BUREAU-À LA RÉCEPTION- Offre d

Fiche RIghtFax.indd

Comment envoyer et recevoir des télécopies

Réceptionniste bilingue Clinique médicale - Santé

Télécharger la documentation - Ruthene Repro, Imprimantes

Nouveaux télécopieurs Canon FAX-JX500 et FAX

Solution de télécopie professionnelle efficace et sécurisée

FAX-8360P

Les Entreprises AR Carrier