Mémoire de stage - Université de Lille
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Université de Lille
Master 2 Mathématique Informatique Appliqué aux Sciences Humaines et
Sociales
Département M.I.M.E
Mémoire de stage.
Par
Ferdouz Hamza
Fusion du Système d’information de l’université de Lille.
Mise en place d’un Web Service pour le service documentaire.
Le 20 août 2018
Tutrice pédagogique : Mme Mikaela KELLER
Tuteur professionnel : Stéphane MAGNIES
Responsable de formation : Staworko SLAWOMIR
2
Résumé & Abstract
Au mois de mars 2018 , j’ai effectué mon stage au sein de la Direction du Système d’Informa-
tion de l’université de Lille dans le service exploitation et intégration.
Depuis la fusion des universités , certaines données ou ressources ne sont pas accessibles ou sont
restreintes à certaines composantes de l’université ne pouvant plus travailler en autonomie.
J’ai été amener à mettre en place un Web Service afin de répondre à un besoin urgent du service
documentaire de l’université. Un Web Service représente une technologie du Web permettant aux
applications de communiquer à distance via internet.
Ce présent mémoire retrace donc de façon détailler le travail effectué durant ce stage. Celui-ci fut
ma troisième expérience professionnelle au sein de la DSI c’est le stage que j’ai le plus apprécié ,
car j’ai été plonger dans ce nouveau contexte de fusion. Ce stage de 6 mois est l’aboutissement
de ma formation et la concrétisation de mon projet professionnel.
[Mots-clés : Web Service , applications , DSI , données , ressources , communica-
tion.]
Since march , I did my internship in the Information System Department of the University of
Lille in the operation and integration department.
Since the merger certain data or resources are not accessible or are restricted to certain compo-
nents of the university that can no longer work autonomously.
I was prompted to set up a Web Service to respond to an urgent need for the university’s do-
cumentary service. A Web Service is a web technology that allows applications to communicate
remotely with web.
This memoir is a summary of the work done during this internship which was my third professio-
nal experience within the DSI that I most appreciated, having been immersed in this new context
of merger. This 6-month internship is the culmination of my training and the realization of my
professional project.
[Keywords : Web Service, applications, DSI, data, resources, communication.]
3
Table des matières
1 Contexte général. 11
1.0.1 Présentation de l’organisme. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.0.1.1 La Direction du Système d’information. . . . . . . . . . . . . . . 12
1.0.1.2 Le service du référentiel des identités numériques. . . . . . . . . . 13
1.0.1.3 Le service de la Formation Tout au Long de la Vie. . . . . . . . . 13
1.0.2 Objectifs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.0.3 Contexte et problématique de la mission. . . . . . . . . . . . . . . . . . . . 14
1.1 Description du problème. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.1 Contexte de Fusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.2 Définition préalable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.3 Comment est gérée l’information au sein du système d’information. . . . . 15
1.1.4 Les limites du système d’informations actuels. . . . . . . . . . . . . . . . . 16
2 Étude du concept de Web Service. 17
2.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Définition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Architectures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Fonctionnement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Les solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Apports et Limites des Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Solution : Conception du Web Service. 21
3.0.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.0.2 Analyse de l’existant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.0.2.1 le Web Service APOGEE fournit par l’AMUE. . . . . . . . . . . 22
3.0.2.2 Mode de fonctionnement du Web Service. . . . . . . . . . . . . . 23
3.0.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.0.4 Mise en place de l’outil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.0.4.1 Test du Web Service d’APOGEE. . . . . . . . . . . . . . . . . . . 24
3.0.4.2 Choix du langage de programmation. . . . . . . . . . . . . . . . . 25
3.0.4.3 Développement de l’application. . . . . . . . . . . . . . . . . . . . 26
3.0.4.4 Communication avec les utilisateurs finaux. . . . . . . . . . . . . 28
3.0.5 Résultat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.0.6 Bilan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Conclusion 32
4
5 Annexes 35
5.1 Demande du service documentaire. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Notes de création application Symfony. . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Notes de deploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4 Notes de GIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5
Table des figures
1.1 Organigramme de la direction du système d’information. . . . . . . . . . . . . . . 12
2.1 Mécanisme des Services Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Les différentes couches des Web Services. . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Web Service d’APOGEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Schéma mode de fonctionnement des Web Services. . . . . . . . . . . . . . . . . . 23
3.3 Exemple d’utilisation du logiciel SOAPUI . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Schéma d’utilisation de l’application web service. . . . . . . . . . . . . . . . . . . 26
3.5 Schéma de deploiement d’application sur un GIT. . . . . . . . . . . . . . . . . . . 27
3.6 Capture d’écran de mon Web service. . . . . . . . . . . . . . . . . . . . . . . . . . 30
6
Remerciements
Je remercie en premier lieu Stéphane Magnies , Mostafa Laforge , chef de service et directeur
de la direction du système d’information de l’université de Lille de m’avoir accueilli au sein de
leur structures et de la confiance qu’ils ont accordé à mon égard , je les remercie également de
m’avoir aider à obtenir ce stage de fin d’année de Master.
Je remercie également toutes les personnes du Bureau du référentiel des identités numérique
ainsi que le Bureau de la Formation tout au long de la vie notamment mes remerciement à Flo-
rian Bomy. Patrick Declerck , Lahcen El Filali , Teddy Bourgois , Sébastien Castreman , Mathieu
Hetru. Je les remercie d’avoir été là du début jusqu’à la fin de mon stage , pour m’aider et me
fournir toutes les ressources nécessaires à la réussite de mon travail.
Je remercie Mikaela Keller , ma tutrice enseignante pour sa disponibilité et ses conseils , ainsi
que tous les enseignants du master mathématique informatique appliqué aux sciences humaines
et sociales pour la qualité d’enseignement et les connaissances techniques et pratiques que j’ai pu
apprendre durant mes deux années de master.
Enfin, je ne saurai terminer sans formuler quelques mots de remerciements qui vont essentiel-
lement a mes parents, frere et sœurs, qui n’ont jamais cesser de me soutenir durant mes etudes.
Je les remercie également de m’avoir poussé à faire de longues études , d’avoir cru en moi et en
mes compétences toutes au long de ces années.
7
Glossaire
LDAP : Lightweight Directory Access Protocol.
DSI : Direction du Système d’Information.
HARPEGE : Harmonisation de la Gestion des Personnels.
APOGEE : Application Pour l’Organisation et la Gestion des Enseignants et des Étudiants.
GIT : Logiciel de version décentralisé.
PHP : Hypertext Preprocessor.
AMUE : Agence de mutualisation des universités et des établissements.
WS : Web Service.
JSON : JavaScript Object Notation.
XML : eXtensible Markup Language.
89
Introduction générale
La fusion des 3 anciennes université de Lille 1 , Lille 2 et Lille 3 ont permis de donner naissance
à une nouvelle et unique entité : l’université de Lille.
Cette nouvelle université s’est confronté à une complexité de son organisation et de l’évolu-
tion de ses structures d’enseignements et d’informations tout en répondant aux besoins et normes
imposées par la politique des établissements.
De même, dans l’enseignement moderne, où les nouvelles technologies de l’information prennent
une place importante, la possibilité de diffuser rapidement l’information vers tous les acteurs (en-
seignants, personnels , étudiants) est un enjeu crucial pour une communication efficace et une
utilisation optimale des ressources.
La mise en place de la DSI fusionnée (Direction du Système d’Information) a permis d’adapter
un nouveau système d’information (SI) aux nouveaux besoins. La DSI favorise en effet le pilotage
de l’université en se mettant à son service à travers un ensemble de ressources tels que l’introduc-
tion d’outils informatiques permettant de répondre aux différents besoins.
Ce présent mémoire suivra le plan suivant : le premier chapitre sera consacré au contexte , le
deuxième chapitre présentera les principaux concepts des Web service, le 3ième chapitre s’appuiera
sur le travail effectué tout au long du stage à savoir la mise en place du Service Web permettant
de répondre au problème posé.
10Chapitre 1
Contexte général.
Ce chapitre vise à présenter le contexte dans lequel j’ai effectué mon stage. Des organigrammes
permettrons de hiérarchiser l’ensemble des composantes au sein de la DSI. Ensuite j’indiquerai
les services que j’ai intégré puis je parlerai des objectifs de mon stage , de la problématique.
1.0.1 Présentation de l’organisme.
11CHAPITRE 1. CONTEXTE GÉNÉRAL.
1.0.1.1 La Direction du Système d’information.
La Direction des Systèmes d’Information est un Service Général de l’Université placé sous la
responsabilité du Président de l’Université et Directeur Général des Services.
Elle met en œuvre la politique du système d’information, des technologies de l’information et
de la communication définie par le Président et le Conseil d’Administration de l’Université dans
les domaines de l’enseignement, de la recherche, de la documentation et de la gestion.
Figure 1.1 – Organigramme de la direction du système d’information.
La DSI de l’Université de Lille est gérée en 2 branches distinctes : une branche système d’in-
formation qui gère l’exploitation , l’intégration et le développement des solutions et une branche
infrastructure et support qui organise et permet une gestion du réseau des systèmes , de la télé-
phonie , proximité etc..
Les missions de la DSI sont :
12CHAPITRE 1. CONTEXTE GÉNÉRAL.
— La mise en œuvre du SI et des services numériques.
— La mise en place et suivi des référentiels.
— L’administration des bases de données.
— Le développement des applications web
— Le développement et intégration des applications liées à l’informatique de gestion.
1.0.1.2 Le service du référentiel des identités numériques.
Lors de la première partie de mon stage, j’ai intégré la branche « Exploitation et intégration
du SI d’informations ». Dans le bureau des référentiel, c’est le domaine lié à l’identité numérique
d’une personne au sein du système d’information , il représente le socle du SI et est également
une référence en terme d’informations.
Les missions du Bureau Suivi des référentiels :
— Fournir à l’ensemble de toutes les applications SI les identités.
— Alimenter les annuaires universitaires.
— Exposer les identités et les comptes associés.
— Gérer les droits et les autorisations d’accès.
1.0.1.3 Le service de la Formation Tout au Long de la Vie.
Dans la seconde partie de mon stage, j’ai ensuite été affecter au service FTLV. Ce service gère
l’ensemble des formations d’enseignements de l’université de Lille.
Les missions du Bureau FTLV :
— Fournir à l’ensemble toutes les applications se rapportant à la gestion de l’enseignement
et des étudiants.
— Gestions de l’ensemble des étudiants.
1.0.2 Objectifs.
J’ai travaillé sur 2 thèmes durant mon stage mais celui qui sera développer dans ce mémoire
à pour sujet : " Conception d’un Web Service pour le service documentaire de l’université ".
Cette mission consiste à mettre en place un Web-Service au vue de répondre au mieux à la de-
mande du service documentaire de l’université de Lille.
13CHAPITRE 1. CONTEXTE GÉNÉRAL.
Le deuxième sujet : "Montée en qualité du référentiel d’identité Numérique Université de Lille en
vue de l’intégration des comptes Étudiants".
L’objectif principal de la mission est de faciliter les tâches à venir en vue de l’intégration des
identités numériques des étudiants , mettre en place les tables de bases de données non présente
dans le nouvel environnement de test du système d’information de l’université de Lille.
1.0.3 Contexte et problématique de la mission.
Chaque année, l’agence de mutualisation et des établissements ( AMUE ) fournit aux univer-
sités les différents outils leurs permettant une gestion efficace de l’enseignement supérieur.
Les applications sont ensuite maintenues ou développées par le biais des équipes de la DSI qui
s’occupent du déploiement à l’ensemble des acteurs de l’université ( étudiant , personnels et en-
seignant etc ..)
Le bureau du service documentaire qui est un des services annexes à la DSI met en place un
processus d’import automatique des individus de l’annuaire LDAP 1 vers les 3 systèmes d’infor-
mations de gestion de bibliothèque (SIGB).
J’ai été amener à mettre en place un web service , de l’étude de ses protocoles à la rédaction de
scripts pour récupérer les informations non présentes dans les bases de données actuelles.
L’étude des Web Service existant m’a permis de me poser les problématiques suivante à savoir :
— Comment le système d’information permet de gérer l’indépendance des différents acteurs
de l’université ?
— Un web service est-il intégrable au système d’information actuel ? Permet-il l’interopéra-
bilité des systèmes ?
1. lLightweight Directory Access Protocol est à l’origine un protocole permettant l’interrogation et la modifi-
cation des services d’annuaire
141.1. DESCRIPTION DU PROBLÈME. CHAPITRE 1. CONTEXTE GÉNÉRAL.
1.1 Description du problème.
Une fois que la problématique est posée , l’étape qui suit est l’analyse des besoins.
1.1.1 Contexte de Fusion.
Depuis la Fusion des 3 universités , l’ensemble des acteurs de la DSI ont du se confronter
à une problématique plus importante et à une nécessite de répondre , d’unifier et de mettre en
place l’ensemble des ressources qui puisse répondre de façon optimale à l’ensemble des besoins
des acteurs de l’université.
En effet, avant la fusion chaque université possédait ses propres outils , sa propre organisation
et son propre système d’information. Elle à permis de sélectionner les outils qui répondaient le
mieux aux critères de la nouvelle université.
Bien évidemment, la mise en place d’un nouveau système d’information est chrono-phage et
celle ci trouvera une stabilité au bout de 3 voir 4 années. La difficulté réside principalement dans
une volonté de mettre en accord l’ensemble des différents acteurs sur le choix de cette nouvelle
organisation et leurs formations.Tout cela montre la complexité que peut engager la mise en place
d’une fusion de 3 grandes universités.
1.1.2 Définition préalable.
Avant d’entamer la description du problème, il est important de définir le terme de système
d’information.
Un système d’information est un système qui permet aux différents acteurs de l’université de
disposer à n’importe quel moment d’informations pertinentes , d’outils d’analyse pour les aider à
prendre des décisions. Les informations sont ensuite traitées par la mise en place de tableaux de
bord et d’indicateurs.
1.1.3 Comment est gérée l’information au sein du système d’informa-
tion.
L’information circule à travers un système d’information bien défini.
En effet, le système d’information se concentre autour de solution dont des bases de données ou
protocoles tels que cette liste non exhaustive :
151.1. DESCRIPTION DU PROBLÈME. CHAPITRE 1. CONTEXTE GÉNÉRAL.
— APOGEE : (Application pour l’organisation et la gestion des enseignants et des étudiants).
C’est une application permettant la gestion globale de la scolarité.
— HARPEGE : (Harmonisation de Gestion des Personnels). C’est une application destinee
a couvrir la gestion des ressources humaines dans les établissements de l’établissement
supérieur.
— LDAP : C’est un protocole d’accès à un annuaire.
Les utilisateurs ou acteurs peuvent ainsi gérer l’ensembles des domaines de la gestion universitaire
que ce soit la scolarité , la finance , l’enseignement etc..
Ces solutions doivent respecter les notions d’autonomie , d’évolution , d’interopérabilité des sys-
tèmes.
1.1.4 Les limites du système d’informations actuels.
La seule limite est quand le besoin d’un utilisateur lambda devient spécifique et ne concerne
qu’une infime partie de l’information.
L’utilisateur a besoin d’avoir une information en temps réel et à jour et parfois elle ne peut pas
être récupérer directement dans les bases, du fait de son indisponibilité ou elle nécessite la créa-
tion ou le développement de scripts ou encore la mise en place de nouvelles technologies. Ce qui
représente un coût important et est chrono-phage.
En effet, il s’agit dans un premier lieu d’assurer la consommation et la mise à jour des données et
dans un deuxième temps permettre une communication entre différents systèmes. Ensuite il faut
savoir adapter , transformer les données de tel sorte à obtenir un résultat compréhensible pour
l’utilisateur.
Pour gagner du temps et répondre rapidement à la demande l’AMUE fournit chaque année des
connecteurs et Web Service déjà prêt à l’emploi pour chaque application tels que APOGEE ou
HARPEGE. Les connecteurs/Web services sont ensuite pris en charge par la DSI qui s’occupe
d’intégrer ou de les en-capsuler afin de répondre aux besoins.
La suite de ce mémoire se concentrera donc sur cette notion de Service Web et sa mise en place
dans le cadre de ma mission.
16Chapitre 2
Étude du concept de Web Service.
2.1 Introduction.
Une fois que le problème est décrit , il fallait penser aux solutions pour répondre à la problé-
matique. C’est là qu’intervient la recherche des techniques existantes à ce jour sur les web service.
Cette recherche peut s’appuyer sur des sources diverses tels que les journaux , les revues , les
publications sur internet . Cette étape m’a permis de définir et résumer les notions des différentes
technologie à utiliser et à appliquer pour mettre en place le Web services.
2.2 Définition.
Un Web Service ou Service Web est une :
« Une technologie permettant à des applications de dialoguer à distance via Internet indépen-
damment des plates-formes et des langages sur lesquelles elles reposent.».
L’intérêt est de permettre une communication ou un lien entre une application et le web.
172.3. ARCHITECTURES. CHAPITRE 2. ÉTUDE DU CONCEPT DE WEB SERVICE.
2.3 Architectures de Web Service.
Les Web Services actuels se basent essentiellement sur un ensemble de technologies fondamentales
qui communiquent entre eux. Ils ont été mis en place dans le but de permettre le développement
et le déploiement de façon indépendante sur différents système.
Figure 2.1 – Mécanisme des Services Web.
Les 5 principaux technologies qui nous intéressent ici sont :
— REST (Representational State Transfer) : c’est une architecture qui permet de construire
une application qui suit les protocoles HTTP/WWW
— SOAP (Simple object Access Protocol) : c’est un protocole de communication décrit en
XML et qui permet d’effectuer des appels de méthodes distantes.
— WSDL (Web Services Description Language) : il represente l’interface de Web Service qui
indique aux utilisateurs comment utiliser et interagir avec un Web Service.
182.4. FONCTIONNEMENT. CHAPITRE 2. ÉTUDE DU CONCEPT DE WEB SERVICE.
— UDDI : (Universal Description, Discovery and Integration) est un annuaire de services. Il
permet au fournisseur de donner une vue des différents web service existant aux clients.
— HTTP : c’est un protocole web qui permet de transporter l’information.
2.4 Fonctionnement d’un Web Service.
Le fonctionnement des Web Service s’articule autour d’un modele de couches. Les 3 couches
fondamentales s’articulent autour de l’invocation , de la découverte et de la description.
L’invocation a pour but la description de la structure des messages échangés par les différentes
applications.
La découverte permet de rechercher et trouver un Service Web dans l’annuaire de service UDDI
décrivant l’ensemble des informations tels que le nom , l’objectif de chaque Web service.
Enfin la description permet de décrire l’interface du Web service à savoir le nombre de paramètres,
les types de données etc..
Figure 2.2 – Les différentes couches des Web Services.
192.5. LES SOLUTIONS. CHAPITRE 2. ÉTUDE DU CONCEPT DE WEB SERVICE.
2.5 Les solutions.
Les Web Services sont souvent déployés en utilisant des logiciels de serveur d’applications
notamment :
— nuSOAP ou SoapClient : qui sont des bibliothèques pour les développeur en PHP
— gSOAP : bibliothèque de méthode pour les développeur en C++
— Axis pour le développement en JAVA
— WebLogic d’Oracle
— Serveurs HTTP ISS de Microsoft.
Cela montre les multiples solutions qui permettent soit le développement soit la consommation
d’un Servie Web.
2.6 Apports et Limites des Web Services.
Les Services Web sont connus comme étant une technologie web simple à mettre en œuvre.
En effet, ils permettent de rendre accessible certaines fonctionnalités d’une application sans en
modifier les grandes lignes , en conservant l’architecture des systèmes d’informations actuels de
la DSI.
Les Web Services reposent sur des protocoles bien définis qui permettent de faciliter l’utilisa-
tion de services liés par la génération de fichiers textuels , lisibles pour les utilisateurs. Cette
standardisation des différents protocoles vue dans les parties précédentes montre qu’il y a une
interopérabilité entre les applications et les technologies de SOAP , WSDL etc..Le principal avan-
tage des Web Services est leur fiabilité et sont toujours d’actualité.
Enfin, les Web Services comme tout système ont des limites la plus critique est celle liée à la
sécurité, il n’existe pas de norme de sécurité. En effet, les Web services utilisent le protocole HTTP
qui peut-être facilement détourner. Dans le cadre de la DSI, ils sont utilisés à usage restreint :
seules les personnes concernées utilisent les services. Le deuxième point est la performance des
Web service sont ralentit du fait que l’information circule en grande quantité ce qui peut ralentir
les requêtes d’interrogations.
20Chapitre 3
Solution : Conception du Web Service.
3.0.1 Introduction.
Suite à la présentation du concept de Web Service, j’ai pu commencé à développer le Web
Service.
Avant de commencer à développer mon application, j’ai décidé de passer par un plan d’action.
En entreprise, il est important de classifier et de définir une gestion des étapes du projet , com-
prendre les besoins afin de répondre de la meilleure des manières aux attentes.
Ce plan d’action se compose de la manière suivante :
— Analyse et compréhension du Web Service Existant.
— Recherche de la ou les méthodes répondant au besoins.
— Test des fonctions pour déterminer celles qui répondent aux besoins.
— Test des fonctions pour déterminer le nombre de paramètres.
— Création du Web service en PHP à partir du Web Service existant.
— Test , communication et déploiement de l’application.
21CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
3.0.2 Analyse de l’existant.
3.0.2.1 le Web Service APOGEE fournit par l’AMUE.
Le Web Service d’APOGEE est composé de différentes méthodes ou fonctions codées en JAVA
mais qui peuvent être réutilisés par d’autres langages de programmation.
Figure 3.1 – Web Service d’APOGEE.
Les parties encadrées en rouge représentent le nom principal de la méthode puis en dessous,
nous avons la listes des différentes fonctions. A chaque méthode est attribuée un lien spécifique (
encadré orange ) et ce lien est dans un format nommé WSDL. Ce format est une grammaire de
XML qui permet de créer des web services. Ces liens permettent de faire appels aux méthodes
utilisant des paramètres.
Le Web Service d’APOGEE développé par l’ AMUE possède beaucoup de méthodes , il suffit de
choisir un lien dans la partie de droite pour pouvoir y accéder.
22CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
Une documentation technique du Web Service existant permet de connaître les caractéristiques
de toutes les méthodes ainsi que les fonctions qui les composent et le nombre de paramètres en
entrée.
3.0.2.2 Mode de fonctionnement du Web Service.
Figure 3.2 – Schéma mode de fonctionnement des Web Services.
— Le client se connecte au web service d’apogée qui permet de charger l’ensemble des modules.
— Le WS d’APOGEE renvoient toutes les adresses des fichiers Web Service Description Lan-
guages (WSDL) .
— Grâce à la description des fichiers WSDL, le client sait comment communiquer avec le web
service qui permet d’envoyer un message SOAP aux serveurs.
— Le serveur renvoie la réponse de l’appel de la fonction.
— Le client interprète ensuite le message.
SOAP est un protocole spécifique au Web Service et WSDL est le format ou URL d’accès
d’une méthode d’un Web Service.
23CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
3.0.3 Critique de l’existant
Malgré l’existence du Web service APOGEE fournit par l’AMUE , celui ci ne permet pas aux
différents acteurs d’y accéder.
Il n’existe pas d’applications qui permettent de le consommer posant ainsi une difficulté aux
acteurs du service documentaire de restituer les informations de façon synthétique.
Le deuxième point concerne le fait que celui ci est développé en JAVA, ce qui est difficile à
maintenir et nécessite le passage par la DSI pour résoudre le problème.
La mise en place d’un Web Service permettra de gagner du temps au service documentaire et
de travailler en toute autonomie.
Le Web Service est composé de beaucoup de méthodes et souvent la documentation n’indique
pas le nombre de paramètres en entrée.
3.0.4 Mise en place de l’outil.
3.0.4.1 Test du Web Service d’APOGEE.
Avant de commencer le développement, je devais tester le format WSDL pour avoir une idée
et comprendre le fonctionnement de ce format.
Il existe plusieurs logiciels permettant de tester un web service et d’en afficher des résultats sans
forcement connaitre un langage de programmation. J’ai choisi de travailler avec la solution SOA-
Pui qui me parait être la plus simple.
Il permet de :
— Consulter un web service.
— Invoquer le web service.
— Développer un web service.
— Tests fonctionnels , conformité et sécurité des Web Services.
La partie encadrée en rouge ( gauche ) présente les différentes méthodes du Web Service ( rond
rouge ).
La méthode qui nous intéresse et " recupeadretudiantmetier ". Pour y accéder on clique sur
Request1 , la fenêtre de droite apparaît et affiche un code qui ressemble à du XML , il suffit alors
de lui définir les paramètres dans les balises correspondantes ( ex : codee tu. . . ).
24CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
Figure 3.3 – Exemple d’utilisation du logiciel SOAPUI
Une fois les paramètres définis, on exécute et le résultat est affiché dans la fenêtre de droite avec
toutes les informations , les intitulés sont affichés dans des balises. Les informations de la partie
de droite seront le résultat final du web service.
3.0.4.2 Choix du langage de programmation.
Pour mettre en place un Web Service il faut se décider sur le choix du langage. Nous pouvons
soit coder celui ci en JAVA ou en PHP. Le choix fut rapide, étant plus à l’aise avec la technologie
PHP plus particulièrement le développement en PHP Symfony car il possède des méthodes pré-
définies permettant ainsi de consommer un Web Service.
PHP symfony est un framework ou « cadre de travail » qui permet de réaliser des sites web en
PHP rapidement , de façon structurée avec un code structuré clair , maintenable et réutilisable
par d’autres développeurs. C’est une extension de PHP qui est constituée de différents composants.
Elle peut-être définis comme une boîte à outil qui a pour but de simplifier le développement des
applications et la maintenance du code et son évolution.
25CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
3.0.4.3 Développement de l’application.
La première étape était de commencer le développement de l’application en local afin de ne
pas impacter les données ou encombrer les serveurs fournis par le service système de la DSI .
Le développement en local est souvent la première étape car il n’y pas cette notion de compatibilité
avec le serveur ou d’envoi de fichiers à chaques modifications pour pouvoir tester. Ceci permettant
un gain de temps.
La deuxième étape fut la recherche d’une classe en PHP qui permette de consommer un Web
Service, la plus connue est "SOAPCLIENT" . Cest un client SOAP , à partir de cette classe j’ai
pu extraire les méthodes dont j’avais besoin pour la suite du développement.
Le schéma suivant explique l’utilisation de l’application :
Figure 3.4 – Schéma d’utilisation de l’application web service.
— L’application interroge le web service d’APOGEE.
— celui-ci interroge le serveur SOAP à l’aide requête XML qui la vérifie.
— Une fois que les requêtes et les paramètres sont présents et validés par le serveur , celui ci
renvoie les résultats sous un format XML ou JSON.
— Le tout est renvoyé par une requête HTTP permettant d’afficher les résultats.
Une fois que l’application fut opérationnelle en local, je devais transférer les fichiers sur le serveur
afin de créer une communication entre mon client et le serveur afin d’utiliser l’application en ligne.
Le développement d’une application suit souvent un cycle de vie, comme tout projet , elle
passe notamment par un environnement de développement , de test ou de pré-production et en
fin de production, ce cycle de vie permet la maintenance d’une application , de mettre à jour et
26CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
d’en apporter une évolution .
Pour y accéder, elle nécessite que la machine de travail soit sur le serveur et reconnue par l’équipe
système de la DSI , car il faut passer par des applications qui ne sont accessibles qu’au sein de
l’université.
— L’environnement de développement est le serveur sur lequel sont développées les applica-
tions.
— La test ou la pré-production est plus un environnement de validation ou de test des appli-
cations.
— L’environnement de production permet d’exécuter l’application qui est opérationnelle, c’est
celui qui nécessite le plus de vigilance car tout dysfonctionnement peut interrompre le tra-
vail de l’utilisateur de l’application pouvant entraîner de lourdes conséquences.
Déploiement de l’application.
Une fois que les fichiers de mon application ont été transférer sur les différents environnements,
il fallait que je déploie l’application pour que les utilisateurs du service documentaire puisse y
accéder à partir d’un URL hébergeur. De ce fait, je devais passer par GITLAB qui est une plate-
forme en ligne d’hébergement permettant la gestion de versions Git.
Figure 3.5 – Schéma de deploiement d’application sur un GIT.
Un GIT est une composante de gestion de versions de GITLAB permettant de sauvegarder toutes
les modifications qu’on apporte sur les différents fichiers de l’application. Ainsi, on peut avoir une
sorte de journal de bord avec lequel on peut savoir qui a fait telle ou telle modification et quand
27CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
celle-ci à été faite. On peut revenir facilement vers la version précédente afin de corriger d’éven-
tuelles erreurs.
Je devais suivre les étapes suivantes à chaque modification ou l’ajout d’un nouveau fichier dans
mon application :
— Envoi du code sur le dépôt GIT ( local ).
— Commit ou l’étape de comparaison pour mettre en coïncidence et voir les différences entre
ce qu’il y a sur mon local et sur mon dépôt en ligne.
— ensuite on « PUSH » c’est à dire qu’on envoie les fichiers sur le dépôt en ligne.
— puis on « MERGE » c’est la dernière étape de fusion entre la version originale et celle ou
on développe le module.
— Enfin après le merge, on reçoit automatiquement un mail de confirmation nous informant
du succès ou de l’échec du déploiement.
3.0.4.4 Communication avec les utilisateurs finaux.
L’échange avec les utilisateurs finaux de l’application lors du développement est une étape
fondamentale afin de tester , maintenir et optimiser celle ci. Il faut répondre au maximum aux
besoins des utilisateurs pour avoir une application qui correspondent à leurs attentes.
Les tests de l’utilisateur sont aussi un bon moyen de détecter d’éventuels problèmes. Je commu-
nique de façon régulière avec le service documentaire pour avoir un retour et éventuellement des
conseils et des pistes d’amélioration.
Cette échange m’a permit également de travailler en équipe avec d’autres services de la DSI et
d’aboutir à la réussite de cette mission.
28CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
3.0.5 Résultat.
Ici nous arrivons à l’étape qui montre le résultat de mon Web Service . En effet, cette partie
présente le fruit de notre travail. L’objectif de cette mission est de répondre aux besoins des
utilisateurs du service documentaire de l’université de Lille en offrant une application à partir de
laquelle ils peuvent l’interroger de manière autonome.
Le Web Service est représenté par le lien suivant :
Le cadre en rouge représente l’URL de production qui permet d’accéder à mon application , le
cadre vert représente le nom de ma fonction à utiliser suivi d’un paramètre qui est ici le numéro
d’étudiant.
La personne s’authentifie pour accéder à la page du web service :
Une fois l’authentification faite, la page suivante s’affiche :
On retrouve toutes les informations administratives concernant un étudiant de l’établissement de
l’université de Lille , dans le format JSON qui est un format universel pouvant être réutiliser par
différents langages de programmation.
29CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
Figure 3.6 – Capture d’écran de mon Web service.
3.0.6 Bilan.
La mission qui m’a été confiée a permis de répondre à un besoin urgent pour le service do-
cumentaire de l’université de Lille. En effet , la planification de projet , le choix de méthode de
travail l’analyse de l’existant ont permis de mener à bien cette mission.
Les ressources technologiques et matériels pour le développement de l’application m’ont été
fournis par mon tuteur Stéphane MAGNIES ainsi que Mathieu HETRU qui ont su être dispo-
nible, à l’écoute de mes questions et au suivi du développement et ce malgré les contraintes de
temps.
30CHAPITRE 3. SOLUTION : CONCEPTION DU WEB SERVICE.
Durant cette mission j’ai bénéficié d’une liberté de choix au niveau de l’environnement de
travail ( choix entre Windows et Linux ) , des langages de programmation , cela m’a obligé à faire
des choix et travailler en autonomie ce qui m’a permis de m’améliorer et de découvrir des choses
dont je n’avais aucune connaissance. L’autonomie dont j’ai bénéficié m’a appris à faire force de
proposition et d’imposer mes idées dans un soucis de réponse et de réactivité.
Pour le Web Service que j’ai mis en place , tout les objectifs, ont été atteint et il répond de
manière optimale au besoin de l’utilisateur ( cf mail annexe ). L’application pourra toujours être
complétée si nécessaire et je serai de nouveau amener à maintenir et à répondre aux questions des
utilisateurs. J’ai mis en place une documentation en ligne accessible uniquement par les membres
de mon service qui pourront reprendre la main sur mon application en cas d’absence.
D’un point de vue personnel , je pense avoir fournit le maximum d’effort et un travail rigou-
reux et clair avec un rapport et une demande de validation à chaque prise d’initiative. Ce qui
m’a permis de travailler avec une bonne méthodologie et un suivi constant. Je trouve que cette
partie du stage fut la plus intéressante car les utilisateurs et mon tuteur était satisfait du travail
fournit. J’ai appris également à prioriser certaines tâches à d’autres, en entreprise nous sommes
souvent amener à laisser les projets en cours pour répondre à un besoin urgent.
31Chapitre 4
Conclusion
Ce stage au sein de la Direction du système d’information de l’université de Lille a commencé
le 1er mars 2018 et se terminera le 29 août 2018 , j’ai été suivi et placé sous la tutelle de Monsieur
Stéphane Magnies, chef de service et responsable du service exploitation et intégration de la DSI.
Ce stage de fin d’étude fut une véritable expérience car j’ai été amené à côtoyer un environne-
ment professionnel pendant 6 mois , en effet j’ai pu mettre à profit l’ensemble des connaissances
acquises durant mes années dans l’enseignement supérieur.
J’ai été confronté à un nouveau contexte celui de la fusion de l’université ce qui m’a amener à
faire face à des journées dynamiques avec beaucoup d’imprévus, pour preuve j’ai dû mettre de
coté certaines missions pour répondre à un besoin urgent.
Le Web Service que j’ai mis en place a répondu à un besoin urgent permettant au service qui gère
la documentation des bibliothèques de l’université de pouvoir travailler en autonomie. Grâce à ce
projet, j’ai pu découvrir cette technologie très intéressante permettant de faire communiquer les
applications avec le web sans passer par des heures de programmation ou de codage. De plus , ils
sont au cœur du système d’information actuel de part leur efficacité et un coût réduit , permettant
de répondre à des besoins très spécifiques.
Bien que le système d’information de l’université de Lille est complexe, il n’en demeure pas loin
très performant, où l’objectif et de répondre de manière optimale aux acteurs de l’université en
leurs fournissant des ressources ou outils à la pointe de la technologie. On parle même d’évolution
permanente du SI.
Travailler dans un cadre de fusion m’a permis de me faire une idée globale de la difficulté de la
gestion des acteurs de l’université qu’ils soient étudiants, professeurs ou personnels. Il m’a permit
32CHAPITRE 4. CONCLUSION
également de peaufiner mon vocabulaire et mes connaissances techniques en informatique. Enfin
j’ai pu confirmé mon projet professionnel par la signature d’un contrat de travail à la fin de celui
ci.
33Bibliographie
[1] Référence pour la programmation en Symfony : https://openclassrooms.com/fr/
courses/2078536-developpez-votre-site-web-avec-le-framework-symfony2-ancienne-vers
2078666-symfony2-un-framework-php
[2] Cours sur les Web Service : https://openclassrooms.com/fr/courses/
219329-les-services-web
[3] notes sur les Web Service : https://www.commentcamarche.com/contents/
1244-web-services
[4] Référence pour le deploiement , création d’application etc.. notes de developpement : wikis.
univ-lille.fr
[5] Cours PHP de Mme KELLER et Mr BIGOT et Mr PAPERMAN.
[6] langage SOAP pour les WS : http://www.soapuser.com/fr/basics2.html
[7] Securité des WS https://blog.octo.com/initiation-a-la-securite-des-web-services/
[8] Notion de bases des WS : https://blog.linagora.com/
developpement-et-exploitation-de-web-services-rest/
[9] utoriel et cours pour le developpement d’application symfony : https://symfony.
developpez.com/cours/
[10] PHP et Web Services : http://destroyedlolo.info/Developpement/WebServices/
[11] Wiki pour la mise en place d’un Web Service en PHP avec utilisation de librairie : https:
//fr.wikibooks.org/wiki/Programmation_PHP/Exemples/Webservice
[12] Test des Web Service : https://mbaron.developpez.com/tutoriels/soa/
soapui-tests-fonctionnels-services-web/
[13] Documentation Web Service d’APOGEE : http://www.amue.fr/
formation-vie-de-letudiant/logiciels/apogee/
34Chapitre 5
Annexes
5.1 Demande du service documentaire.
Proposition du bureau informatique documentaire Pour le webservice Apogee :
Auteur : Rachid Aliouat / Bureau informatique documentaire
date : 31/05/2018
Introduction :
Le bureau informatique documentaire met en place un processus d’import automatique des
individus de l’annuaire LDAP vers les 3 systèmes d’information de gestion de bibliothèque (SIGB).
Après avoir questionné l’annuaire LDAP, le process complète l’information en requêtant des
webservices pour avoir les numéros de téléphone et adresses postales des individus.
Formalisation de la demande pour le Webservice Apogée.
exemple d’appel :
"https ://ws-apogee-etab.univ-lille.fr/ws-apogee/getIndividu/30200439"
Proposition pour la liste des métadonnées :
"NOE T U DIAN T ” : ”3”, ”ADRF IXA DR1” : ””, ”ADRF IXA DR2” : null, ”ADRF IXA DR3” :
null, ”ADRF IXC ODEP OST AL” : ””, ”ADRF IXV ILLE” : ””, ”ADRF IXC P AY S” : ””, ”ADRF IXL LP
”””ADRF IXT ELEP HON E” : ”03..6974”, ”ADRT EM PA DR1” : ”8RU E”, ”ADRT EM PA DR2” :
355.2. NOTES DE CRÉATION APPLICATION SYMFONY. CHAPITRE 5. ANNEXES
”AP P T A11”, ”ADRT EM PA DR3” : ”RES.DU T HEAT RE”, ”ADRT EM PC ODEP OST AL” :
”59000”, ”ADRT EM PV ILLE” : ”LILLE”, ”ADRT EM PC P AY S” : ”100”, ”ADRT EM PL LP AY S” :
”F RAN CE””ADRT EM PT ELEP HON E” : ””T ELP ORT ABLEE T U ” : null, ”DAT EC REAT ION ” :
”17 − ”, ”DAT EM ODIF ICAT ION ” : ”27 − M AR − 18”,
5.2 Notes de création application Symfony.
362018/08/15 15:24 1/5 Créer un environnement Symfony sur Debian (par notre ami Benoît)
Créer un environnement Symfony sur Debian
(par notre ami Benoît)
Message à caractère idéologique: PHP5 + Debian Wheezy + pdo_mysql + oci8 = That fuckin' works !
Info: PDO est inclus dans php 5 donc la seule difficulté c'est l'Oracle Call Interface (oci).
Apache et PHP
Avoir ces paquets (prendre en compte qu'il s'agit de paquets installés sur une 64 bits) :
aptitude install linux-headers-2.6-amd64 make gcc libmozjs-dev libmozjs10d
apache2 phpunit php5 php5-intl php-apc libapache2-mod-php5 php-symfony-yaml
curl subversion git php5-dev php5-xml php-xml php5-mysql rlwrap re2c libaio1
php5-ldap php5-curl
Installer un instant client Oracle sous Linux
Ce qui suit est le copier/coller d'une documentation complète de ce qu'il faut faire, par contre il faut
quand même mettre la même chose qu'on trouve dans /etc/profile.d/oracle.sh dans le .bashrc
Oracle Instant Client 11.2.0.3.0 in Ubuntu 11.10 (et ultérieur du moins ok
sous 12.04)
As an Oracle Database Administrator, I've been involved in several projects where the installation of
the Instant Client is a requirement.
I'm aware of some tutorials where people tell you to use “alien” to convert Oracle RPMs to DEBs but I
preffer to use ZIPs, so I'll post here how it works including the Basic package along with the SQL*Plus
and the SDK.
I'll be using the Virtual Machine created in my first post, you might want to use your own computer
with Ubuntu already installed and the only difference is that you might already have the required
packages installed.
Preliminaries :
1. Liste numérotéeGet the following files from Oracle Download site :
instantclient-basic-linux.x64-11.2.0.3.0.zip
instantclient-sdk-linux.x64-11.2.0.3.0.zip
instantclient-sqlplus-linux.x64-11.2.0.3.0.zip
DSI - Exploitation / Intégration - https://wikis.univ-lille.fr/dsi-exploit/Last update: 2018/04/14 12:55 dom-ent:symfony-doc-fabien:debian https://wikis.univ-lille.fr/dsi-exploit/dom-ent/symfony-doc-fabien/debian 2. You will need unzip for the files and SQL*Plus requires the Linux kernel AIO access library, to install the packages use the following : sudo apt-get install unzip libaio1 Installation: 1. Instant Client will be installed under /usr/lib/oracle, from the directory where you have the ZIP files enter the following commands: sudo unzip instantclient-basic-linux.x64-11.2.0.3.0.zip -d /usr/lib/oracle sudo unzip instantclient-sdk-linux.x64-11.2.0.3.0.zip -d /usr/lib/oracle sudo unzip instantclient-sqlplus-linux.x64-11.2.0.3.0.zip -d /usr/lib/oracle 2. You need two Symbolic Links for compilation purposes, create them with the following commands: sudo ln -s /usr/lib/oracle/instantclient_11_2/libclntsh.so.11.1 /usr/lib/oracle/instantclient_11_2/libclntsh.so sudo ln -s /usr/lib/oracle/instantclient_11_2/libocci.so.11.1 /usr/lib/oracle/instantclient_11_2/libocci.so 3. Dynamic Linker Run-Time Bindings must be configured, create a new file with the following command: sudo vi /etc/ld.so.conf.d/oracle.conf And insert the following line: /usr/lib/oracle/instantclient_11_2 Save the file and run the configuration of the Dynamic Linker Run-Time Bindings with the following command : sudo ldconfig 4.Some environment variables are required and you can add the directory to the path, create a new file with the following command : sudo vi /etc/profile.d/oracle.sh And insert the following lines : export ORACLE_HOME=/usr/lib/oracle/instantclient_11_2 export NLS_LANG=AMERICAN_AMERICA.AL32UTF8 export TNS_ADMIN=/etc/oracle export PATH=$PATH:$ORACLE_HOME https://wikis.univ-lille.fr/dsi-exploit/ Printed on 2018/08/15 15:24
2018/08/15 15:24 3/5 Créer un environnement Symfony sur Debian (par notre ami Benoît)
Please note, the NLS_LANG environment variable must match the configuration of your Oracle
Database or you will have character problems I normally use one of AMERICAN_AMERICA.AL32UTF8,
MEXICAN SPANISH_MEXICO.AL32UTF8, MEXICAN SPANISH_MEXICO.WE8ISO8859P1 or MEXICAN
SPANISH_MEXICO.WE8ISO8859P15 but you might need another.
5. Log out and log in again to make the new environment variables available to your user.
6. Finally, the tnsnames.ora file must be created in the path defined in the environment variable
TNS_ADMIN, create the directory with the following command :
sudo mkdir /etc/oracle
Create the file with the following command :
sudo vi /etc/oracle/tnsnames.ora
And insert the lines you need to configure your connections, for example:
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.87)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = orcl)
)
)
You can now use SQL*Plus to test your installation:
sqlplus myuser@orcl
Remarques
Un :
chmod a+r /etc/oracle -R
est le bienvenu, sinon sqlplus et ses copains n'arrivent pas à lire le tnsnames.ora qu'on vient claquer
dedans
Je recommande de copier le contenu de sdk/include dans le répertoire “racine” de l'instant client :
cp sdk/include/* .
depuis le $ORACLE_HOME
Pour mes tests j'ai fait les manip dans mon /home/$USER/instantclient ce qui a donné
/instantclient/instantclient_11_2 comme $ORACLE_HOME en ayant fait un
ln -s /home/$USER/instantclient /instantclient
DSI - Exploitation / Intégration - https://wikis.univ-lille.fr/dsi-exploit/Vous pouvez aussi lire
