Système de Gestion de télécopies
Transcription
Système de Gestion de télécopies
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 Système de gestion des télécopies Maîtrise Génie Informatique ℘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 Marc Delavaud-Boisis 2003 2 Système de gestion des télécopies Maîtrise Génie Informatique 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 Marc Delavaud-Boisis 2003 3 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 4 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 5 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 6 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 7 Système de gestion des télécopies Maîtrise Génie Informatique Visualisation des différentes applications Marc Delavaud-Boisis 2003 8 Système de gestion des télécopies Maîtrise Génie Informatique 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 : Marc Delavaud-Boisis 2003 9 Système de gestion des télécopies Maîtrise Génie Informatique • 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. Marc Delavaud-Boisis 2003 10 Système de gestion des télécopies Maîtrise Génie Informatique 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 : • • • • • • • Marc Delavaud-Boisis 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 Système de gestion des télécopies Maîtrise Génie Informatique 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é. Marc Delavaud-Boisis 2003 12 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 13 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 14 Système de gestion des télécopies • Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 15 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 16 Système de gestion des télécopies Maîtrise Génie Informatique 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 ». Marc Delavaud-Boisis 2003 17 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 18 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 19 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 20 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 21 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 22 Système de gestion des télécopies Maîtrise Génie Informatique 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 Marc Delavaud-Boisis 2003 23 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 24 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 25 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 26 Système de gestion des télécopies Maîtrise Génie Informatique 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. Marc Delavaud-Boisis 2003 27 Système de gestion des télécopies Maîtrise Génie Informatique 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). Marc Delavaud-Boisis 2003 28 Système de gestion des télécopies Marc Delavaud-Boisis Maîtrise Génie Informatique 2003 29