ERP Universitaire

Recherche Scientifique et de la Technologie

*** * ***

Universite de Carthage

*** * ***

Institut National des SciencesAppliquees et de Technologie

Projet de Fin d’Etudes

Pour l’obtention du

Diplome National d’Ingenieur

en Sciences Appliquees et en Technologie

Filiere : Genie Logiciel

Sujet :

Conception de l’architecture et developpementdes modules d’un ERP Universitaire

Realise par :Slimen Belhaj Ali

Entreprise d’accueil :ITIPart

Responsable entreprise : Monsieur Allaeddinne Bahri

Responsable INSAT : Madame Saloua Ben yahia

Annee Universitaire : 2012/2013

Recherche Scientifique et de la Technologie

*** * ***

Universite de Carthage

*** * ***

Institut National des SciencesAppliquees et de Technologie ,

Projet de Fin d’Etudes

Pour l’obtention du

Diplome National d’Ingenieur

en Sciences Appliquees et en Technologie

Filiere : Genie Logiciel

Sujet :

Conception de l’architecture et developpementdes modules d’un ERP Universitaire

Realise par :Slimen Belhaj Ali

Entreprise d’accueil :ITIPart

Responsable entreprise : Responsable INSAT :

Monsieur Allaeddinne Bahri Madame Saloua Ben yahia

Cachet & Signature Signature

Annee Universitaire : 2012/2013

DEDICACES

A mon pere, a qui je dois tout et qui m’a toujours montre le chemin a suivre dans la vie

A ma mere pour sa bonte, sa generosite et son devouement.

A ma soeur Hanen, qui m’a toujours temoignee son soutien et son affection

A mes freres, Salem, Adnen et Ahmed Amine pour qui j’ai une grande admiration.

A tous ceux qui m’ont aide a l’elaboration de ce travail

II

REMERCIMENT

Je voudrais avant tout adresser mes sinceres remerciements aux personnes qui m’ont

apporte leur aide et leur soutien durant tout le deroulement de mon stage et notamment a :

Madame Saloua Ben Yahia pour sa collaboration, sa disponibilite et ses precieux conseils.

Madame Salwa Chaouali, pour son accueil chaleureux au sein de son entreprise ITIPart.

Monsieur Allaeddinne Bahri, Chef de projet chez ITIPart, a qui nous tenons a exprimer

toute notre gratitude pour l’aide qu’il nous a prodiguee durant toutes les phases de ce stage.

Tous les membres du jury pour avoir accepte d’apporter leur jugement a mon travail.

III

TABLE DES MATIERES

Introduction generale 1

1 Presentation du projet 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Presentation d’organisme d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Web agency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Mobile agency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.3 Nearshoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.4 Integrateur Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Presentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.3 Enjeux et avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.4 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Methodologie adoptee : 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Presentation de la methodologie 2TUP . . . . . . . . . . . . . . . . . . . 8

1.4.2 Application du 2TUP dans notre projet . . . . . . . . . . . . . . . . . . 10

1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Analyse et specification des besoins 12

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

IV

TABLE DES MATIERES

2.2 Les acteurs du systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Etudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Enseignant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.4 Personnel administratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.5 Public (visiteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Specifications fonctionnelles detaillees . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Module gestion de la bibliotheque . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 Module gestion des inscriptions et des formations . . . . . . . . . . . . . 16

2.3.3 Module gestion des notes et des resultats . . . . . . . . . . . . . . . . . . 18

2.3.4 Module gestion des services administratifs et des reclamations . . . . . . 20

2.4 Specifications non-fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 Extensibilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.2 Securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Presentation de l’environnement technologique 24

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Specification des besoins techniques . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Liferay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Partenariat entre Alfresco et Liferay . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6 Central authentification service (CAS) . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Architecture et conception de la solution 33

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Architectures de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Architecture operationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 34

V

TABLE DES MATIERES

4.2.2 Architectures applicatives . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.1 Conception de l’arbre DIT de l’annuaire LDAP . . . . . . . . . . . . . . 40

4.3.2 Conception du modele d’acces aux donnees . . . . . . . . . . . . . . . . . 41

4.3.3 Conception du modele d’integration des couches (IoC) . . . . . . . . . . 42

4.3.4 Conception des modeles des donnees . . . . . . . . . . . . . . . . . . . . 43

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Implementation et test de la solution 49

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3 Test de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.3.1 Conformite aux besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 51

5.3.2 Conformite aux besoins non-fonctionnels . . . . . . . . . . . . . . . . . . 58

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Concluison Generale 63

BIBLIOGRAPHIE 65

Webographie 66

Glossaire 67

A Integration Liferay, Alfresco, CAS, LDAP 68

A.1 Etape 1 : Installation et configuration du Liferay avec eclipse . . . . . . . . . . . 69

A.2 Etape 2 : Installation du OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.3 Etape 3 : Installation et configuration du serveur CAS avec OpenLDAP . . . . . 72

A.4 Etape 4 : Activation de l’HTTPS et la configuration d’un certificat SSL sur un

serveur Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.5 Etape 5 : Configuration Liferay avec LDAP . . . . . . . . . . . . . . . . . . . . 76

VI

TABLE DES MATIERES

A.6 Etape 6 : Configuration Liferay avec CAS . . . . . . . . . . . . . . . . . . . . . 76

A.7 Etape 7 : Installation d’Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.8 Etape 8 : Configuration Alfresco avec LDAP . . . . . . . . . . . . . . . . . . . . 79

A.9 Etape 9 : Configuration Alfresco avec CAS . . . . . . . . . . . . . . . . . . . . . 81

VII

TABLE DES FIGURES

1.1 Cycle du developpement par la methodologie 2TUP. . . . . . . . . . . . . . . . . 9

1.2 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Module Gestion bibliotheque : Diagramme de cas d’utilisation . . . . . . . . . . 16

2.2 Module Gestion des inscriptions et des formations : Diagramme de cas d’utilisation 18

2.3 Module Gestion des notes et des resultats : Diagramme de cas d’utilisation . . . 20

2.4 Module Gestion des services et reclamations : Diagramme de cas d’utilisation . . 22

3.1 Architecture de Liferay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Architecture d’Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Architecture de CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Architecture general de l’ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Architecture detaillee de l’ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Architecture du module gestion de la bibliotheque . . . . . . . . . . . . . . . . . 37

4.4 Architecture du module gestion des inscriptions et des formations . . . . . . . . 38

4.5 Architecture du module gestion des notes et des resultats . . . . . . . . . . . . . 39

4.6 Architecture du module gestion des services et des formations . . . . . . . . . . 40

4.7 L’arbre DIT de l’annuaire LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.8 Modelisation du Data Access Object . . . . . . . . . . . . . . . . . . . . . . . . 42

4.9 Modelisation du pattern IoC avec Spring . . . . . . . . . . . . . . . . . . . . . . 43

4.10 Diagramme de classes : Gestion bibliotheque . . . . . . . . . . . . . . . . . . . . 44

VIII

TABLE DES FIGURES

4.11 Diagramme de classes : Gestion des formations et des inscriptions . . . . . . . . 45

4.12 Diagramme de classes : Gestion des notes et des resultats . . . . . . . . . . . . . 46

4.13 Diagramme de classes : Gestion des services et des reclamations . . . . . . . . . 47

5.1 Ajout d’un ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 acquisition d’un ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Reserver un ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 Gestion des cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.5 Gestion des matieres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.6 Saisie des notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.7 Releve de notes genere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.8 Demander un service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.9 Traiter les demandes de services . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.10 Interface du serveur CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.11 Gestion d’autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.12 La configuration de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.13 La variation de charge (chargement des ouvrages de la base de donnees) . . . . 61

5.14 La variation de charge (generation des releves de notes) . . . . . . . . . . . . . . 61

A.1 Configuration du Liferay avec Mysql . . . . . . . . . . . . . . . . . . . . . . . . 69

A.2 Installation du Plugin Liferay dans Eclipse . . . . . . . . . . . . . . . . . . . . . 70

A.3 Configuration du SDK Liferay avec Eclipse . . . . . . . . . . . . . . . . . . . . . 70

A.4 Configuration du serveur Liferay (sous Tomcat) avec Eclipse . . . . . . . . . . . 71

A.5 Installation de OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A.6 tester le fonctionnement du serveur CAS . . . . . . . . . . . . . . . . . . . . . . 73

A.7 Configuration du serveur CAS avec OpenLdap . . . . . . . . . . . . . . . . . . 74

A.8 Definir le domaine de recherche et le parametre d’authentification . . . . . . . . 74

A.9 Definir et parametrer un certificat electronique . . . . . . . . . . . . . . . . . . . 75

A.10 Activer le HTTPS dans le serveur tomcat . . . . . . . . . . . . . . . . . . . . . 75

A.11 Configurer Liferay avec OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.12 Configurer Liferay avec le serveur CAS . . . . . . . . . . . . . . . . . . . . . . . 77

A.13 Configurer Alfresco avec le MySql . . . . . . . . . . . . . . . . . . . . . . . . . 78

IX

TABLE DES FIGURES

A.14 Definition des ports d’Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.15 Configurer Alfresco avec OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.16 Interface d’Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.17 Configuration d’Alfresco avec le serveur CAS . . . . . . . . . . . . . . . . . . . . 81

X

LISTE DES TABLEAUX

2.1 Module gestion bibliotheque : messages emis et recus . . . . . . . . . . . . . . . 15

2.2 Module gestion des inscriptions et des formations : messages emis et recus . . . 17

2.3 Module gestion des notes et des resultats : messages emis et recus . . . . . . . . 19

2.4 Module services administratifs et reclamations : messages emis et recus . . . . . 21

5.1 Description de l’environnement logiciel utilise . . . . . . . . . . . . . . . . . . . 51

XI

INTRODUCTION GENERALE

De nos jours les entreprises expriment de plus en plus le besoin de capitalisation du savoir.

En effet l’information est de plus en plus un facteur crucial dans la gestion de l’entreprise et sa

relation aussi bien avec les partenaires externes (clients, fournisseurs) qu’avec les collaborateurs.

Cela va de meme pour les organisations de types educatifs, instituts et universites, qui expriment

egalement le besoin d’acheminer rapidement et clairement l’information a tous ses acteurs. Ceci

necessite de disposer des outils informatiques et des methodes de gestion.

Les ERP d’entreprise se posent comme solution eventuelle de capitalisation du savoir. Son

objectif principal est de centraliser l’acces au systeme d’information afin de pouvoir recenser les

donnees et les placer sur un tableau de bord electronique. Ceci offre un suivi permanent des indi-

cateurs de performances. Dans ce sens l’ERP est l’un des points clefs du systeme d’information

d’entreprise actuel. Il agit en tant que concentrateur d’informations. C’est un excellent moyen

pour profiter des methodes de travail tel que le travail en equipe, le partage des ressources,

l’acces aux services internes, et la collaboration entre les entreprises.

C’est dans ce contexte que la mise en place d’un ERP universitaire a ete proposee comme

un projet de fin d’etude, pour pouvoir mettre en oeuvre toutes les possibilites offertes par les

ERP d’entreprise et evoluer du simple site web vers un ERP offrant plus de services et plus de

possibilites a ses adherents.

1

. INTRODUCTION GENERALE

Le present rapport est de ce fait la synthese des etapes de mise en oeuvre d’un ERP univer-

sitaire. Il a pour but de situer le contexte du projet, de decrire son sujet, les methodes et outils

utilises ainsi que les resultats obtenus. Il est organise comme suit :

Le premier chapitre intitule Presentation du projet est consacre a la presentation de

l’organisme d’accueil, ainsi que la mise en contexte du projet. Nous expliquerons aussi dans

ce chapitre les notions theoriques en relation avec notre sujet. C’est egalement a ce niveau

que nous presenterons la methodologie que l’on va adopter tout au long de l’elaboration de ce

projet.

Le chapitre suivant s’intitule Presentation de l’environnement technologique, dans ce

chapitre, nous presenterons nos besoins techniques ainsi que les differents choix elabores.

La specification et l’analyse des besoins seront presentees dans le troisieme chapitre intitule

Analyse et specification des besoins dans lequel nous etudierons en details les besoins

fonctionnels et non fonctionnels ainsi que la modelisation de ces besoins par le recours aux

diagrammes de cas d’utilisation.

Le quatrieme chapitre intitule Architecture et conception de la solution sera dedie a

la presentation de l’architecture operationnelle et les architectures applicatives et offrira un

apercu des patrons de conception utilises. Cet apercu menera a la conception des differentes

fonctionnalites offertes.

Le cinquieme chapitre intitule Mise en oeuvre et integration presentera les etapes de la

realisation du projet et les tests elabores.

Nous cloturons ce rapport par une conclusion generale dans laquelle nous evaluerons les

resultats atteints et nous exposerons les perspectives eventuelles du present projet.

2

CHAPITRE 1

PRESENTATION DU PROJET

3

CHAPITRE 1. PRESENTATION DU PROJET

1.1 Introduction

Dans ce chapitre, nous aborderons tout d’abord l’environnement du stage en presentant

l’entreprise d’accueil connue sous le nom de ITIPart. Puis, nous presenterons le cahier de

charges du projet ainsi que ses enjeux et ses avantages. Nous cloturons ce chapitre par la

description de la methodologie adoptee pour la realisation de l’ERP.

1.2 Presentation d’organisme d’acceuil

ITIpart est une societe d’ingenierie infor-

matique specialisee dans le developpement et

la mise en place des solutions globales au-

tour des systemes d’information d’entreprise.

Elle est specialisee dans le developpement et

la mise en place des solutions globales autour

des systemes d’information d’entreprise.

Tres orientee vers ses Clients/Partenaires, ITIpart les place au coeur de sa strategie de

developpement et leur propose de les accompagner dans leur challenges Business dans le cadre

d’une etroite collaboration et d’une relation de partenariat autour de ses valeurs fondamentales :

Transparence, Engagement et Qualite.

1.2.1 Web agency

ITIPart propose a ses clients de concevoir et realiser leurs site Internet professionnels, E-

commerce, reseau social repondant aux normes et standards du web et en parfaite adequation

avec les activites et les cibles du client.

1.2.2 Mobile agency

ITIPart propose a ses clients l’accompagnement dont ils ont besoin pour prendre en douceur le

virage de la mobilite et d’envisager ce changement important dans leurs systeme d’information

4


de facon beaucoup plus sereine. ITIPart developpe des applications mobiles sous Android,

IPhome, Blackberry, etc.

1.2.3 Nearshoring

Il se concretise par la mise en place de centres de services bases a Tunis integrant des

competences a la pointe des nouvelles technologies (JEE, .net. Web 2.0, etc) avec une integration

sur mesure de l’environnement du client (plate-forme, securite, PAQ, etc).

1.2.4 Integrateur Open Source

ItiPart met a la disposition de ses clients ses experts afin de leur permettre de beneficier

pleinement et toute securite de meilleures solutions de l’open source autour de la GED, CRM...

1.3 Presentation du projet

Nous envisageons dans ce qui suit la presentation du projet du stage pour bien le comprendre

et delimiter ce qui est demande pour passer a l’action et repondre aux specifications d’une facon

concise et efficace.

1.3.1 Description du projet

Ce projet s’intitule Conception de l’architecture et developpement des modules

d’un ERP Universitaire. Les modules qui constituent ce travail sont presentes ci-dessous :

-Module gestion de la bibliotheque.

-Module gestion des inscriptions et des formations.

-Module gestion des notes et des resultat.

-Module gestion des services administratifs et des reclamations.

Ce travail rentre dans le cadre de mon projet de fin d’etudes qui vient conclure notre formation

d’ingenieur en genie logiciel a Institut National des Sciences Appliquees et de Technologie

(INSAT). Il s’integre dans le cadre des projets de developpement d’ITIPart.

5


1.3.2 Cahier des charges

Il s’agit de realiser un ERP universitaire modulaire, cet ERP doit couvrir tous les services et

les departements de l’universite. Les modules sont :

- Gestion de la bibliotheque

L’adherent peut chercher en ligne les ouvrages disponibles par mots cles, auteur, titre, annee,

ou domaine. La consultation peut devoiler la liste des ouvrages qui seront disponibles dans les

trois jours ouvrables suivants. L’adherent pourra alors demander la reservation de l’ouvrage.

Le responsable de la bibliotheque doit pouvoir gerer la bibliotheque directement depuis le

systeme. La gestion de la bibliotheque doit supporter :

-Prets de livres, gestion des emprunteurs, livres a rendre, livres rendus.

-Nombre d’exemplaires en possession de chaque utilisateur.

-Historique des emprunts.

-Recherche multicriteres et selective.

-Saisie assistee.

-Classement par genre.

Le systeme doit informer les adherents de leurs depassements du delai de retour de l’ouvrage,

ainsi que les annulations des reservations effectuees dans le cas ou l’adherent n’empruntent pas

l’ouvrage dans le delai.

-Module gestion des inscriptions et des formations

La gestion des inscriptions devra permettre l’inscription d’un nouveau membre sous reserve

de validation par l’administrateur qui devra alors lui accorder le statut (Roles, Sites...) adequat.

La gestion des formations doit comporter la gestion des cycles, filieres, niveaux. La definition

des modules et des matieres doit etre faite par le personnel administratif.

Chaque enseignant peut definir les cours pour les matieres qu’il enseigne, ces cours seront

valides selon un WorkFlow.

6


-Module gestion des notes et des resultats

Le responsable scolarite doit pouvoir importer directement depuis les donnees saisies par

l’enseignant dans le systeme de notation utilise par l’Ecole. Ce module permettra d’accelerer

la saisie des notes et de reduire les erreurs de saisie.

Le systeme doit generer les releves de notes a partir de la base de donnees, ces releves seront

geres dans un serveur de gestion des documents.

-Module gestion des services administratifs et des reclamations

Les membres de l’ERP peuvent passer des reclamations, ils peuvent aussi joindre un docu-

ment avec la reclamation.

Le responsable administratif doit pouvoir traiter les reclamations presentees par l’enseignant

ou un administratif et lui repondre par le biais du meme systeme . Une reclamation est un

message qui peut etre garni par des documents attaches. A son envoi elle rend l’etat Non

traitee.

Lorsque le responsable administratif recoit la reclamation, il peut changer son etat en ac-

cuse de reception, en cours, rejetee, non soluble ou terminee selon l’etat d’avance-

ment du traitement de la reclamation. L’etat d’avancement reste accessible a l’initiateur de la

reclamation.

1.3.3 Enjeux et avantages

Les enjeux de ce projet sont multiples, on peut citer :

-Definir une plateforme d’echange entre corps enseignants, etudiants, administratifs et

industriels.

-Numerisation des documents de l’universite : Gerer, organiser et definir les droits d’acces

aux documents electroniques (Document Management System).

-Faciliter la recherche de l’information : Ce service permet au public de chercher par un

ou plusieurs mots cle. Lorsque ce module est utilise par un membre authentifie, la recherche

doit se faire dans toutes les pages accessibles par ce membre.

7


1.3.4 Objectif

L’objectif de ce projet est d’avoir une version beta qui couvre la majorite des fonctionnalites

d’un ERP universitaire. Nous devons avoir des modules coherents au niveau des fonctionnalites

et une vision claire sur le resultat attendu.

1.4 Methodologie adoptee : 2TUP

1.4.1 Presentation de la methodologie 2TUP

Nous avons opte pour le processus 2TUP pour des raisons multiples. D’une part, 2TUP donne

une grande importance a la technologie ce qui est important pour notre projet, d’autre part,

2TUP est un processus en Y qui contient une branche technique et autre fonctionnelle. Ces

deux branches peuvent etre exploitees en parallele.

De ce fait, si la technologie evolue lors de deroulement du projet il y a apparence d’un besoin

technique, la branche technique peut etre traitee puis reintegree dans le projet facilement. De

meme si une nouvelle fonctionnalite se presente, seule la branche fonctionnelle va etre traitee

sans toucher a l’autre branche.

Principe :

Ce processus commence par une etude preliminaire qui permet d’identifier les acteurs du

systeme a mettre en oeuvre qui est considere comme une boıte noir tout en presentant les

differents messages entre les utilisateurs et ce systeme et d’elaborer le cahier de charges. La

figure montre les differentes etapes de processus 2TUP.

8


Figure 1.1 – Cycle du developpement par la methodologie 2TUP.

D’apres la figure, on remarque que 2TUP est compose essentiellement de trois etapes :

1/Une branche fonctionnelle (a gauche) :

Capture des besoins fonctionnels, qui produit les modeles des besoins en se basant sur le

metier des utilisateurs. Cette etape elimine le risque d’avoir un systeme inadapte aux besoins

des utilisateurs.

L’analyse qui consiste a etudier les besoins fonctionnels de maniere a obtenir une idee de

ce que va realiser le systeme en terme metier.

2/Une branche technique (a droite) :

Capture des besoins techniques, cette etape permet de recenser les contraintes de choix de

dimensionnement et de conception du systeme. Les outils selectionnes ainsi que les contraintes

d’integration avec l’existant (pre-requis d’architecture technique).

9


L’etape conception generique definit ensuite les composants necessaires a la construction de

l’architecture technique. Cette conception est completement independante des aspects fonc-

tionnels.

3/Une branche de realisation (au milieu) :

La conception preliminaire, c’est une etape un peu delicate, car elle integre le modele

d’analyse fonctionnel dans l’architecture technique de maniere a tracer la cartographie des

composants du systeme a developper.

La conception detaillee, qui permet d’etudier comment realiser chaque composant.

L’etape de codage, qui est ensuite l’etape de production de ces composants ainsi que les tests

unitaires au fur et a mesure sur chaque composant.

L’etape de recette, qui consiste enfin a la validation des differentes fonctionnalites du systeme.

Outil de modelisation

Nous avons choisi comme langage de modelisation UML reconnu comme etant le standard

industriel par excellence de la modelisation objet. Cela est d’autant plus probant quand on

prend connaissance qu’UML unifie a la fois les notations et les concepts orientes objets.

1.4.2 Application du 2TUP dans notre projet

Dans notre projet, nous avons commence par la definition des besoins fonctionnels, nous

avons decoupe l’ERP en dix modules.

Ce PFE comporte quatre modules avec la mise en place de l’environnement. Nous avons

precise l’architecture operationnelle ainsi que les architectures fonctionnelles. Par la suite, nous

nous sommes focalises sur la conception de la base de donnees de L’ERP. Puis, nous avons

commence le developpement des modules, chacun a part. Enfin, nous avons reserve quatre

semaines pour la redaction du rapport.

10


Le figure ci-dessous presente en detail le deroulement du projet a l’aide d’un diagramme de

Gantt :

Figure 1.2 – Diagramme de Gantt

Ce stage a dure six mois, nous avons commence le 2 Juillet 20012 et nous avons fini le 28

decembre 2012. Nous avons commence par une etude pour capturer les besoins fonctionnels et

non-fonctionnels et les besoins techniques, cette phase a dure un mois.

Pendant quatre mois, nous avons ete inities aux technologies pour qui nous avons opte dans

notre travail et nous avons concu et developpe notre ERP. Au dernier mois, nous avons redige

le rapport.

1.5 Conclusion

Dans ce chapitre, nous avons presente l’entreprise d’accueil ITIPart ainsi que le travail

elabore, nous avons exprime le cahier de charge et les avantages de l’ERP dans l’universite.

Enfin, nous avons presente la methodologie adoptee. Dans le chapitre suivant, nous allons

specifier nos besoins en detail.

11

CHAPITRE 2

ANALYSE ET SPECIFICATION DES BESOINS

12

CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

2.1 Introduction

Dans ce chapitre, nous presentons les differentes etapes suivies pour realiser l’analyse et

specification des besoins en se referant au processus unifie 2TUP. Nous commencons par l’i-

dentification des acteurs principaux. Puis, nous allons analyser les besoins fonctionnels pour

chaque module et les besoins non-fonctionnels de la solution.

2.2 Les acteurs du systeme

Dans notre projet, nous pouvons avoir plusieurs acteurs, nous allons nous interesser unique-

ment aux acteurs principaux :

2.2.1 Administrateur

Cet acteur possede tous les droits d’acces qui lui permettent d’administrer le systeme. Ses

fonctions principales sont la gestion des acces, la gestion des droits des utilisateurs du systeme

et la mise a jour du contenu des portlets du portail si necessaire.

2.2.2 Etudiant

Chaque etudiant aura un espace prive et un espace public, dans lequel il pourra consulter

les informations et les services autorises par l’administrateur (notes, emploi du temps, Bib-

liotheque...). Il pourra utiliser l’espace collaboratif de l’ERP tel que les blogs, les forums, les

wikis...

2.2.3 Enseignant

L’enseignant pourra gerer son espace dans le portail en diffusant des messages et des annonces

pour ses etudiants. Il aura egalement beneficie des services specifiques comme les services de la

bibliotheque, le passage d’une reclamation, la saisie des notes en ligne...

13


2.2.4 Personnel administratif

Ce sont les responsables de la gestion et de l’emission des documents administratifs inherents

aux besoins des etudiants (certificats de reussite, de presence, etc...), la gestion des ouvrages,

des emprunts, gestion des inscriptions, formations....

2.2.5 Public (visiteur)

L’utilisateur guest pourra consulter les pages publics du portail, qui contiennent des infor-

mations generales concernant l’universite.

2.3 Specifications fonctionnelles detaillees

La capture des besoins fonctionnels est la premiere etape de la branche gauche du cycle en

Y. Elle formalise et detaille les cas d’utilisation et les associe aux acteurs appropries.

2.3.1 Module gestion de la bibliotheque

Identification de la liste des cas d’utilisation

Dans la table ci-dessous, nous allons presenter les differents cas d’utilisation du Module

gestion de la bibliotheque avec les messages recus et emis :

14


Cas d’utilisation Sous cas d’utilisation Acteurs Messages recus/emis

Module Gestionbibliotheque

Definition des roleset des permissionspour chaque utilisateur

AdministrateurGeree par le panneaude configuration du Liferay

Traiter les demandesd’inscription

Personneladministratif

Recus : Liste desdemandes d’inscriptionEmis : Accepter ou refuserles demandes

Gestion desadherents


Recus : Liste des adherentsEmis : Bloquer oubebloquer adherent

Gestion desouvrages


Recus : Liste des ouvrages

Emis : Ajouter, supprimerou modifier ouvrage

Gestion desemprunts


Recus : Liste des adherents etliste des ouvrages

Emis : Acquisition ou retourd’un ouvrage

Reserver un ouvrage Adherent

Recus : Liste des ouvrages

Emis : Reserverun ouvrage

Annuler unereservation

Adfherent

Recus : Liste desadherents et listedes ouvrages

Emis : Annuler unereservation.

Demander d’inscription Adfherent

Recus : Formulaire aremplir

Emis : Demanded’inscription

Gestion des favoris Adfherent

Recus : Liste des favoris

Emis : Ajouter, supprimerles favoris

Annuler les reservationset informer les adherents

Systeme

Recus : Liste desreservations quideppassent le delai.

Emis : Des emails pourinformer les adherents

Notifier les adherentsde leurs depassements

Systeme

Recus : Liste desemprunts quideppassent le delai.

Emis : Des emails pourinformer les adherents

Table 2.1 – Module gestion bibliotheque : messages emis et recus

15


Description du cas d’utilisation

Nous presentons dans la figure 2.1 le cas d’utilisation du module gestion bibliotheque :

Figure 2.1 – Module Gestion bibliotheque : Diagramme de cas d’utilisation

2.3.2 Module gestion des inscriptions et des formations



gestion des inscriptions et des formations avec les messages recus et emis :

16


Cas d’utilisation Sous cas d’utilisation Acteurs Messages recus/emis

Module Gestiondes inscriptionset des formations

Gestion des cyclesPersonneladministratif

Recus : Liste des cycles,formulaire

Emis : Ajouter, supprimerou modifier cycle

Gestion des FilieresPersonneladministratif

Recus : Liste des filieres,formulaire

Emis : Ajouter, supprimerou modifier filiere

Gestion des niveauxPersonneladministratif

Recus : Liste des niveaux,formulaire

Emis : Ajouter, supprimerou modifier niveau

Gestion des modulesPersonneladministratif

Recus : Liste des modules,formulaire

Emis : Ajouter, supprimerou modifier module

Gestion des matieresPersonneladministratif

Recus : Liste des matieres,formulaire

Emis : Ajouter, supprimerou modifier matiere

Gestion des groupesPersonneladministratif

Recus : Liste des groupes,formulaire

Emis : Ajouter, supprimerou modifier groupe

Traiter les demandesd’inscriptions


Recus : Liste des demandesd’inscription

Emis : Accepter ou refuserune demande d’inscription

Demande d’inscription etudiantRecus : Formulaire

Emis : Demande d’inscription

Table 2.2 – Module gestion des inscriptions et des formations : messages emis et recus


Nous presentons dans la figure 2.2 le cas d’utilisation du module gestion des inscriptions et des

formations :

17


Figure 2.2 – Module Gestion des inscriptions et des formations : Diagramme de cas d’utilisa-tion

2.3.3 Module gestion des notes et des resultats



gestion des notes et des resultats avec les messages recus et emis :

18


Cas d’utilisation Sous cas d’utilisation Acteurs Messages recus/emisModule Gestiondes notes etdes resultats

Visualiser les noteset les resultats

etudiant Recus : Liste des notes

Saisie des notesPersonneladministratif

Recus : Liste des etudiantset des matieres

Emis : Les notes saisies

Calculer lesmoyennes par matiere


Recus : Liste des etudiantset des matieres

Emis : Lancement du calculdes moyennes par matiere

Calculer lesmoyennes par module


Recus : Liste des etudiantset des modules

Emis : Lancement du calculdes moyennes par module

Calculer lesmoyennes generals


Recus : Liste des etudiants

Emis : Lancement du calculdes moyennes generales.

Determiner les resultatsPersonneladministratif


Emis : Determiner lesresultats et les mentions

Generer les relevesde notes



Emis : Generer lesreleves de notes des etudiants

Table 2.3 – Module gestion des notes et des resultats : messages emis et recus


Nous presentons dans la figure 2.3 le cas d’utilisation du module gestion des notes et des

resultats :

19


Figure 2.3 – Module Gestion des notes et des resultats : Diagramme de cas d’utilisation

2.3.4 Module gestion des services administratifs et des reclamations


Dans la table ci-dessous, nous allons presenter les differents cas d’utilisation du module

services administratifs et reclamations avec les massages recus et emis :

20


Cas d’utilisation Sous cas d’utilisation Acteurs Messages recus/emisModule Gestiondes serviceset reclamations

Suivre l’etat d’unereclamation

MembreRecus : Liste desreclamations avecleurs details

Passer une reclamation MembreRecus : Formulaireemis : Passer unereclamation

Damander un service Membre

Recus : Formulaire

Emis : demanderservice

Suivre l’etat d’un service MembreRecus : Liste desdemandes de servicesavec leurs details

Traiter les servicesPersonneladministratif

Recus : Liste des demandesde services

Emis : Traiter unedemande de service

Traiter les reclamationsPersonneladministratif

Recus : Liste desreclamations

Emis : Traiter unereclamation

Definir les typesde services


Recus : Formulaire

Emis : Ajouter unnouveau type de service

Definir les types dereclamations


Recus : Formulaire

Emis : Ajouter unnouveau type dereclamation

Table 2.4 – Module services administratifs et reclamations : messages emis et recus


Nous presentons dans la figure 2.4 le cas d’utilisation du module services administratifs et

reclamations :

21


Figure 2.4 – Module Gestion des services et reclamations : Diagramme de cas d’utilisation

2.4 Specifications non-fonctionnelles

2.4.1 Extensibilite

L’extensibilite l’une des specifications important d’un ERP. Notre architecture doit supporter

les extensions de nouvelles fonctionnalites sans pour autant la modifier enormement. Notre code

devra etre ferme a la modification et ouvert a l’extension.

22


2.4.2 Securite

L’ERP doit respecter certaines regles relatives a la securite des systemes informatiques, nous

devons avoir un systeme d’acces securise base sur l’authentification et la gestion des autorisa-

tions :

Authentification

Mise en place d’un serveur d’authentification qui assure l’authentification unique, l’authen-

tification doit se faire a travers un certificat SSL.

Autorisation

Chaque utilisateur aura un role, la definition des permissions pour chaque role doit etre

dynamique : on aura la possibilite de creer ou de modifier les roles en associant la combinaison

de permission adequate.

2.4.3 Performances

La performance des services offerts est critique, notamment pour l’importance du facteur

temps dans l’ERP qui vise un grand nombre d’utilisateurs.

2.5 Conclusion

A travers ce chapitre, nous avons detaille nos acteurs. Nous avons detaille les besoins fonction-

nels en presentant un diagramme de cas d’utilisation pour chaque module avec la specification

des besoins non-fonctionnels de la solution. Dans le prochain chapitre nous entamons la mise

en place de l’environnement op’erationnel.

23

CHAPITRE 3

PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE

24

CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE

3.1 Introduction

Dans ce chapitre nous exposons nos besoins techniques en detail. Nous presenterons les

differentes technologies utilisees pour construire notre architecture operationnelle. Nous ex-

pliquons l’interet de chaque choix effectue.

3.2 Specification des besoins techniques

Notre solution se compose de deux aspects fonctionnels principaux :

Un portail (Liferay) qui satisfait les besoins suivants :

– Un espace collaboratif complet, incluant des forums, des blogs personnels, des wikis...

– Un systeme de gestion d’autorisation avec des espaces publics et des espaces prives

– Gestion de profiling (acces personnalise selon les utilisateurs).

– Systeme de workFlow pour la gestion des requetes complexes.

– Un reseau social interne.

Un ECM (Alfresco) pour realiser la gestion electronique des documents :

– Stockage et archivage des documents.

– Impelemtation des workFlows personnalises pour les documents.

– Gestion des droits d’acces pour chaque document.

Pour pouvoir integrer convenablement les deux parties de l’ERP cites ci-dessus (portail et

ECM), nous utiliserons une solution Single Sign One (SSO), la solution adoptee pour serveur

d’authentification est le serveur CAS.

Dans notre cas, la centralisation des utilisateurs est indispensable pour la coherence de traite-

ment de l’ERP. Les groupes d’utilisateurs devrons etre les memes dans le portail et l’ECM. En

consequence, on utilisera un annuaire Lightweight Directory Access Protocol (LDAP). OpenL-

dap est la solution choisie pour notre projet.

25


3.3 Liferay

Liferay Portal est le leader mondial des solutions open source de portail d’entreprise, utilisant

les dernieres technologies Java et Web 2.0.

Dans notre projet, Liferay offre un espace

collaboratif : un ensemble des composants

reutilisables et configurables tel que Forums,

Blogs, Wikis, composants de sondages, com-

posants pour gerer les evenements[1]...

Il offre un panneau d’administration com-

plet, ce panneau nous permet de gerer les utilisateurs, les workflows, les roles, les sites...

Toute les publications (article, commentaire, contenu...) dans Liferay peut suivre un workflow

de validation personnalise. Liferay supporte le moteur du workflow Kaleo.

Liferay est concu pour deployer des portlets qui font partie de Application Programming

Interface (API) Portlet (JSR-168). Liferay est egalement compatible avec la seconde implementation

de l’API Portlet JSR-286 qui est disponible depuis la version 5 de Liferay.[3]

Le developpement specifique des modules dans notre solution, sera sous forme de portlets,

chaque module est un projet a part. Nous devons respecter la specification dans notre developpement

pour que l’integration soit possible.

Liferay implemente un moteur de recherche interne puissant, ce moteur indexe les donnees

utilisees par les portlets natifs avec la prise en compte des droits d’acces.

26


Figure 3.1 – Architecture de Liferay

Liferay nous fournit un autre type de projet qui s’appelle HOOK. Il est apparu dans la

version 6 de Liferay. Ce projet nous permet de personnaliser le noyau du Liferay selon notre

metier. Nous avons besoin de personnaliser des interfaces natives de Liferay avec la modification

de quelques controleurs et quelques services.

Liferay fournit un generateur de code service builder : Il permet a partir d’un fichier XML de

generer les entites de stockage ainsi que les services d’acces (CRUD) et configure l’indexation

pour les rendre accessibles par le moteur de recherche. L’ensemble est integre comme une

ressource dans la pile de gestion des droits classiques de Liferay.[4]

27


La couche presentation de Liferay utilise le moteur de templating Velocity. Avec Velocity,

la couche presentation sera faiblement couplee avec les couches inferieures.

Ce concept facilite enormement la personnalisation des interfaces de Liferay.

Liferay propose un nouveau type de projet qui s’intitule Theme. A l’aide de ce type de

projet, nous pouvons developper un theme en utilisant des fichiers VM (extension des fichiers

reconnus par Velocity), des feuilles de styles (CSS), des images...

Ce projet sera deploye sur le serveur Liferay qui va etre par la suite visible dans le panneau

d’administration de Liferay.

Pour pouvoir personnaliser les layouts des pages, Liferay fournit un projet qui s’appelle

Layout. Dans ce projet on peut decouper nos pages selon notre besoin. Ce Layout peut etre

utilise plusieurs fois et dans plusieurs projets.

3.4 Alfresco

Alfresco est un systeme de gestion de contenu (en anglais ECM pour Enterprise Content Man-

agement) cree par Alfresco Software en 2005 et distribue sous licence libre.[2]

Dans notre projet, Alfresco nous fournit un

GED tres puissant. Il offre des workflows stan-

dards pour la gestion des documents.

Avec Activiti, nous pouvons developper des

workflows personnalises, par exemple : un

workflow pour gerer le cycle de vie d’un dossier d’inscription, un workflow pour la validation

des cours...

L’une des fonctionnalites d’Alfresco, est la gestion des regles de contenu (content rules).

Les regles de contenu permettent d’ajouter de l’intelligence a vos repertoires, dossiers, espaces,

d’une maniere comparable aux filtres que vous pouvez definir pour votre messagerie email.

28


Nous avons besoin de ces regles pour bien organiser nos documents (Administratif, dossiers

d’inscription...).

Alfresco integre son propre moteur de recherche, il utilise Apache Lucene pour indexer les

documents. Ce moteur est tres parametrable, nous pouvons filtrer les recherches par date,

dossier, espaces...

Figure 3.2 – Architecture d’Alfresco

Alfresco supporte plusieurs extensions, il a la possibilite de faire la convertion des documents.

Pour les documents bureautiques (PDF, DOC, Excel..), la conversion se fait avec Open Office.

Pour les fichiers medias, Alfresco utilise OpenGraph pour assurer la conversion d’un format a

un autre.

Alfresco implemente le protocole CIFS (Common Internet File System), ce protocole favorise

la collaboration sur internet. Dans notre projet, ce protocole nous offre la possibilite de travailler

29


sur des repertoires virtuels sur le disque local, il facilite la manipulation des fichiers.

3.5 Partenariat entre Alfresco et Liferay

Liferay et Alfresco ont fait un partenariat afin d’offrir un portail entreprise et un ECM avec

une integration complete.

Alfresco implemente le protocole Content Management Interoperability Services (CMIS), le

but de ce protocole est d’augmenter l’interoperabilite entre les ECM et les applications externes.

Il s’agit un ensemble des services webs REST. A travers ce protocole, nous pouvons effectuer

les meme operations possible par les interfaces webs d’Alfresco.

Pour les clients JAVA, Alfresco fournit une API java, cet API facilite enormement le developpement,

elle est batie sur le protocole CMIS.

Liferay a integre les librairies clients pour pouvoir consommer ces services exposes par Alfresco.

Pour voir les details sur le partenariat voici un lien qui comporte une description claire sur

le fonctionnement et l’integration de Liferay et Alfresco :

http ://www.alfresco.com/products/integrations/liferay

3.6 Central authentification service (CAS)

CAS est un systeme d’authentification unique : on s’authentifie sur un site Web, et on est alors

authentifie sur tous les sites Web qui utilisent le meme serveur CAS. Il evite de s’authentifier

a chaque fois qu’on accede a une application en mettant en place un systeme de tickets.

L’integration du serveur CAS nous permet d’avoir un SSO entre Liferay et Alfresco, ce serveur

permet de naviguer en toute transparence entre les deux solutions.

L’authentification doit etre securisee par un certificat SSL pour que l’authentification soit

forte. Nous devons configurer Tomcat avec un certificat electronique.

30


CAS fournit des librairies clients afin de faciliter cette integration avec Liferay et Alfresco.

CAS fonctionne sous n’importe quel serveur d’application (Tomcat, JBOSS...). Il est developpe

avec des servlets et des pages JSP, nous pouvons modifier le theme du CAS en modifiant

directement les pages JSP.

Figure 3.3 – Architecture de CAS

Dans son mode de fonctionnement, CAS utilise un mecanisme d’echange de tickets. Ces

tickets sont enregistres dans les cookies, pour cela, le navigateur web doit accepter les cookies

si non, l’utilisateur devra se re-authentifier a chaque appel au serveur CAS.

31


3.7 OpenLDAP

OpenLdap est un annuaire electronique, il s’agit d’une base de donnees specialisee qui permet

de partager des bases d’informations sur un reseau. Ces bases peuvent contenir toute sorte

d’informations, comme des logins, des mots de passe, des adresses mails...

OpenLdap est une solution open source et gratuite.

Dans notre projet, OpenLdap memorise les

cordonnees des membres de Liferay et Al-

fresco, les utilisateurs seront regroupes selon

leurs statuts (etudiant, enseignant, personnel

administratif, administrateur).

Nous pouvons creer un arbre DIT pour

bien organiser les utilisateurs (etudiant, en-

seignant, personnel administratif, administrateur).

Liferay importe les utilisateurs lors de son demarrage. Dans la phase de configuration, nous

devons preciser le mapping entre les attributs de l’annuaire LDAP et les attributs de Liferay.

Liferay nous offre une interface de configuration avec l’annuaire LDAP.

Les utilisateurs d’Alfresco sont importes et enregistres dans la base de donnees d’Alfresco.

La configuration et le mapping de l’annuaire se fait en modifiant les fichiers .properties.

Le serveur CAS utilise l’annuaire pour verifier et valider les cordonnees des utilisateurs lors

de l’authentification.

3.8 Conclusion

A travers ce chapitre, nous avons presente notre besoin technique ainsi que les differents

composants utilises. Nous avons presente Liferay, Alfresco, OpenLdap et le serveur CAS. Nous

avons etudie la possibilite de l’integration entre eux. Dans le quatrieme chapitre, nous detaillons

nos architectures avec une conception de notre solution.

32

CHAPITRE 4

ARCHITECTURE ET CONCEPTION DE LA SOLUTION

33

CHAPITRE 4. ARCHITECTURE ET CONCEPTION DE LA SOLUTION

4.1 Introduction

Dans ce chapitre, nous exposons d’abord l’architecture operationnelle de la solution ainsi que

les architectures applicatives, avant d’entamer ensuite la phase de conception, nous presenterons

la conception de l’arbre DIT de l’annuaire LDAP, le modele d’acces aux donnees, le pattern

IoC (Inversion Of Control) et les modeles des donnees.

4.2 Architectures de la solution

Nous exposons d’abord l’architecture operationnelle cible de la solution ainsi que les archi-

tectures applicatives.

4.2.1 Architecture operationnelle

Au vu des specifications fonctionnelles et des exigences techniques, nous proposons l’archi-

tecture cible suivante :

Architecture general de l’ERP

Nous allons presenter l’architecture operationnelle de notre ERP, notre architecture est

repartie en plusieurs serveurs. La figure 4.1 presente l’architecture operationnelle.

Pour assurer le SSO, nous avons choisi la solution CAS (Central authentification Service),

CAS gere les sessions de Liferay ainsi que pour Alfresco.

Tous les utilisateurs sont centralises dans un annuaire LDAP, ces utilisateurs sont importes

dans Lifaray et Alfresco, et le serveur CAS verifie les parametres d’authentification.

La fonctionnalite de gestion des documents est deleguee au serveur Alfresco.

34


Figure 4.1 – Architecture general de l’ERP

La communication entre Liferay et Alfresco se fait a travers le protocole CMIS. Alfresco

implemente ce protocole et fournit une API qui est batie sur CMIS pour mieux faciliter l’in-

teroperabilite d’Alfresco.

Architecture detaillee de l’ERP

Dans cette partie, nous detaillons l’architecture operationnelle de l’ERP, nous expliquons les

differents composants de Liferay ainsi que ceux d’Alfresco.

35


Figure 4.2 – Architecture detaillee de l’ERP

Liferay implemente la specification du Portlet (JSR-286). Liferay comporte nos modules qui

sont developpes sous forme de Portlets et les Portlets natifs de Liferay (Forum, Wiki, Blog...).

Alfresco prend en charge la gestion des documents (Stockage, ajout, suppression...), cycle

de vie des documents (Dossiers d’inscription, les reclamations...), les workflows (les cours, les

demandes de services...) et la securite (gestion des droits d’acces pour les documents...).

On dispose de trois bases de donnees MySql, une pour les donnees de Liferay, la deuxieme

pour Alfresco et la derniere reservee pour l’ERP.

36


4.2.2 Architectures applicatives

Nous allons presenter les architectures applicatives de chaque module developpe ceci comporte

la specification des rameworks utilises et leur differentes interactions.

Module gestion de la bibliotheque

Dans l’architecture du module gestion de la bibliotheque, nous avons utilise plusieurs Frame-

works, la figure ci-dessous montre l’integration de ces Frameworks.

Figure 4.3 – Architecture du module gestion de la bibliotheque

Dans le Portlet Gestion bibliotheque, nous avons organise les Frameworks comme suivant :

-Pour implementer le pattern MVC (Modele, vue, Controle), nous avons utilise JSF.

-Primefaces s’occupe de la couche presentation.

-Nous avons utilise Spring comme un Framework d’integration, Spring implemente le pattern

IoC (Inversion de controle).[5]

37


-Le Framework Quartz est utilise pour gerer les taches planifiees.

-Pour les notifications par mail, nous avons utilise Java Mail.

-Hibernate est un framework de la persistance, il permet de representer une base de donnees

en objets JAVA et vice versa.

Module gestion des inscriptions et des formations

Le module gestion des inscriptions et des formations comporte un portlet et deux HOOKs,

la figure ci-dessous montre l’organisation des projets de ce module.

Figure 4.4 – Architecture du module gestion des inscriptions et des formations

Dans ce module, nous avons essaye de personnaliser le noyau de Liferay. Pour cela, nous

avons developpe deux Hook :

le premier HOOK a pour role de personnaliser l’interface d’inscription. Nous avons ajoute des

champs dans cette interface (Grade, Numero de carte identite national, Numero d’inscription).

38


Le deuxieme Hook, a pour role de modifier le processus d’inscription, selon le grade, Liferay

doit affecter au nouveau membre un role (etudiant, Enseignant, personnel administratif) et une

organisation ou un site (etudiant, Enseignant, personnel administratif).

Module gestion des notes et des resultats

La gestion des notes et des resultats integre dans son architecture JasperReport et une API

Alfresco, voici l’architecture de ce module :

Figure 4.5 – Architecture du module gestion des notes et des resultats

Ce module comporte un seul portlet. Nous avons utilise JasperReport pour la generation des

releves de notes, Jasper nous fournit un document PDF. Par la suite, nous enregistrons ces

releves de notes dans Alfresco a l’aide de son API.

Module gestion des services et des reclamations

Nous allons presenter l’architecture de la gestion des services et des reclamations :

39


Figure 4.6 – Architecture du module gestion des services et des formations

Le module gestion des services et des reclamations utilise Java mail pour la notification les

membres de l’etat de ses reclamations ou services. Il utilise Gmail comme un serveur SMTP.

4.3 Conception

4.3.1 Conception de l’arbre DIT de l’annuaire LDAP

L’annuaire LDAP stocke les donnees relatives aux utilisateurs, il partage ces donnees dans

le reseau. Ces donnees seront consommees par Liferay, Alfresco et CAS. La figure 4.7 presente

l’arbre DIT :

40


Figure 4.7 – L’arbre DIT de l’annuaire LDAP

Nous avons regroupe les utilisateurs selon leurs roles. Nous avons quatre groupes principaux

(etudiant, enseignant, personnel administratif et administrateur), nous pouvons avoir des sous-

groupes plus specifiques comme chef departement (derive du groupe enseignant), responsable

bibliotheque (derive du groupe personnel administratif)...

4.3.2 Conception du modele d’acces aux donnees

Dans notre projet, chaque table de la base de donnees de l’ERP est mappee en une entite Java.

Nous avons developpe une couche d’acces aux donnees (DAO). cette couche permet d’encapsuler

le traitement acces de donnees.

41


Figure 4.8 – Modelisation du Data Access Object

Nous avons utilise Hibernate-JPA pour implementer le modele d’acces de donnees. Nous

definissons pour chaque entite une classe permettant de faire les operations CRUD (create,

read, update, delete) sur cette table.

4.3.3 Conception du modele d’integration des couches (IoC)

Dans notre projet, nous avons utilise le pattern Inversion de controle (IoC). L’integration

entre la couche DAO, Service et vue est assuree par le pattern IoC. Chaque couche expose des

interfaces (des contrats) pour la couche superieure. Dans la figure ci-dessous nous expliquons

le pattern IoC :

42


Figure 4.9 – Modelisation du pattern IoC avec Spring

Spring est le Framework adopte pour implementer le pattern IoC. Il fournit un conteneur

d’injection qui permet de gerer la dependance entre les couches (Vue, Service, DAO). Les

implementations des interfaces seront injectees selon la configuration du conteneur.

4.3.4 Conception des modeles des donnees

Module gestion bibliotheque

Notre module necessite des donnees qui doivent etre stockees en permanence pour assurer le

bon fonctionnement. La figure ci-dessous presente le modele de donnees pour le module gestion

bibliotheque :

43


Figure 4.10 – Diagramme de classes : Gestion bibliotheque

Un User (recupere de la base de donnees de Liferay) demande de s’inscrire dans la bib-

liotheque, un nouveau enregistrement s’ajoute dans Adherent. Apres la validation du respons-

able de la bibliotheque, l’attribut etat change de valeur de En attente vers Actif.

Un adherent a la possibilite de reserver, emprunter ou ajouter aux favoris un ouvrage.

Module gestion des formations et des inscriptions

Dans le module gestion des formations et des inscriptions, la presence d’un modele de donnees

est indispensable.

la figure ci-dessous presente notre modele de donnees :

44


Figure 4.11 – Diagramme de classes : Gestion des formations et des inscriptions

Dans une universite, nous avons toujours des filieres (Mecanique, informatique...), des niveaux

(1er, 2eme...) et des cycles (LMD, Ingenieurie..).

Le module est forme par plusieurs matieres.

Chaque etudiant demande de s’inscrire dans un niveau, filiere et cycle. Le personnel adminis-

tratif valide l’inscription et l’associe a un groupe.

Module gestion des notes et des resultats

Les notes et les resultats sont enregistres dans une base de donnees, pour cela, nous devons

modeliser une base de donnees, la figure ci-dessous montre les relations entre les entites :

45


Figure 4.12 – Diagramme de classes : Gestion des notes et des resultats

Chaque note aura un type (DS, TP, Examen...), une note est associee a une inscription et

une matiere.

Le systeme calcule les moyennes par matiere et par module pour chaque inscription.

Apres les calculs des moyennes, le systeme determine les resultats des inscriptions et il

determine aussi, la mention pour chaque resultat.

46


Module gestion des services administratif et des reclamations

Les demandes de service administratif et les reclamations seront stockees dans une base de

donnees, la figure 4.13 presente le modele de donnees de ce module :

Figure 4.13 – Diagramme de classes : Gestion des services et des reclamations

Le personnel administratif determine les types de services (Demande d’attestation, demande

rendez-vous...) et les types de reclamations (reclamation pour une note, reclamation pour un

examen...).

Un membre peut faire des reclamations et suivre ses etats ainsi que ses demandes de services.

Le personnel administratif traite les demandes et les reclamations et il envoie des reponses.

Un personnel administratif c’est un user qui a le role personnel administratif. Nous n’avons

pas une table personnel administratif.

L’administrateur de l’ERP specifie les roles : le droit de passer une reclamation et le droit de

demander un service.

47


4.4 Conclusion

A travers ce chapitre, nous avons etudie la faisabilite de notre ERP. En premier lieu, nous

avons presente notre architecture operationnelle. Ensuite, nous sommes passes a la presentation

de nos architectures applicatives. Enfin, nous avons presente notre conception de l’ERP. Dans

le prochain chapitre, nous exposerons une description des etapes et des outils qui nous ont

permis de realiser et d’integrer notre ERP.

48

CHAPITRE 5

IMPLEMENTATION ET TEST DE LA SOLUTION

49

CHAPITRE 5. IMPLEMENTATION ET TEST DE LA SOLUTION

5.1 Introduction

Ce chapitre constitue le dernier volet de ce rapport et a pour objectif d’exposer le travail

acheve. Pour ce faire, nous commencons par la presentation de l’environnement materiel et logi-

ciel adoptes pour realiser notre travail, par la suite, nous allons valider les besoins fonctionnels

et non-fonctionnels.

5.2 Environnement de travail

5.2.1 Environnement materiel

L’environnement materiel, mis en place pour le developpement, est compose des elements

suivants :

-UN PC HP Core(TM)2 Duo 2.00GHz avec 4 GO de RAM.

Systeme d’exploitation : Ubuntu 12.04

-Un serveur Debian 6.05

5.2.2 Environnement logiciel

Dans cette partie, nous precisons l’environnement logiciel utilise pour realiser notre projet :

Outils/API Description

JDK 1.6Java Development Kit (JDK) designe un ensemble de bibliothequeslogicielles de base du langage de programmation Java.

Eclipse Juno Environnement de developpement integre(IDE)

Liferay 6.1Portail d’entreprise libre et open sourceecrit en Java et distribue sous LGPL.[6]

Alfresco 3.4cSysteme de gestion de contenu (en anglais ECM pour EnterpriseContent Management)[7]

CAS 3.5.1Central Authentification Service est un systeme d’authentificationunique (SSO)[8]

Apache DirectoryStudio 2.0

Apache Directory Studio permet de gerer unou plusieurs annuaires LDAP. [11]

50


JSF 2.1Java Server Faces est un framework de developpement d’applicationsWeb en Java permettant de respecter le modele d’architecture MVC. [12]

Spring 3.1Spring est un framework libre pour construire etdefinir l’infrastructure d’une application java2. [13]

Hibernate 4framework open source gerant la persistance des objets enbase de donnee relationnelle. [14]

JasperReports 4.8 JasperReports est un outil de Reporting Open Source.[15]

Quartz 1.8Quartz est un planificateur de taches de source ouverte. Il fournitdes mecanismes puissants pour la planification des taches.[16]

JavaMail API 1.4JavaMail fournit un cadre independantes du protocole pourconstruire des applications de messagerie et de courrier. [17]

Primefaces 3.4PrimeFaces est une puissante librairie de composants JSFqui s’appuie sur la librairie Ajax jQuery. [10]

Apache Velocity1.6

Apache Velocity est un package libre developpe par la FondationApache. Velocity est un moteur de template ou gabarits. [18]

OpenLDAP 3.3OpenLDAP est une implementation libre du protocole :LightweightDirectory Access Protocol.

Texmaker 3.2Texmaker est un logiciel libre fonctionnant sur Linux.Il est destine l’edition de documents LaTeX.

Table 5.1 – Description de l’environnement logiciel utilise

5.3 Test de la solution

5.3.1 Conformite aux besoins fonctionnels

Nous avons realise les modules suivants : module gestion de la bibliotheque, module gestion

des inscriptions et des formations, module gestion des notes et des resultats, module gestion

des services et des reclamations.

51


Module Gestion bibliotheque

Figure 5.1 – Ajout d’un ouvrage

Cet ecran permet au responsable de la bibliotheque d’ajouter un ouvrage.

Nous avons un menu a gauche, ce menu est personnalisable selon le role (Etudiant, En-

seignant, personnel administratif).

52


Figure 5.2 – acquisition d’un ouvrage

Dans cette interface le personnel administratif se charge de l’enregistrement de l’acquisition

d’un ouvrage en selectionnant l’ouvrage et l’adherent.

Figure 5.3 – Reserver un ouvrage

53


L’adherent peut acceder via son espace a ce menu pour pouvoir reserver un ouvrage pour

une duree bien determinee.

Module Gestion des inscriptions et des formations

Figure 5.4 – Gestion des cycles

A travers cette interface, nous pouvons ajouter, supprimer ou modifier un cycle.

Figure 5.5 – Gestion des matieres

Pour pouvoir ajouter une matiere, nous devons preciser a quel module elle appartient. Nous

pouvons aussi, supprimer et modifier une matiere.

54


Module Gestion des notes et des resultats

Figure 5.6 – Saisie des notes

La saisie des notes se fait selon les etapes suivantes :

– On doit preciser le cycle, la filiere et le niveau choisis dans les listes deroulantes.

– Une fois les choix ci-dessus effectues, la les groupes correspondants s’affiche dans une liste

deroulante. On pourra alors effectuer le choix du groupe.

– Les matieres enseignees dans le groupe choisis sont disponibles dans une autre liste.

– Finalement, on choisit le type de note (DS, TP, Examen...).

– Apres la validation, un formulaire de saisie avec la liste des etudiants concernes s’affiche, Le

personnel administratif saisie les notes, enfin, il enregistre.

55


Figure 5.7 – Releve de notes genere

L’action de la generation des releves de notes est declenchee par un personnel administratif.

L’etudiant peut acceder a ses releves de notes a travers son espace prive.

Le releve des notes est genere avec JasperReport, les donnees sont chargees de la base de

donnees, apres sa generation, le releve est enregistree dans Alfresco.

56


Module services administratifs et reclamations

Figure 5.8 – Demander un service

A travers cet ecran, un membre peut demander un service. Il determine le type du service,

motif et une description.

Figure 5.9 – Traiter les demandes de services

Dans cette interface, le personnel administratif dispose la liste des demandes de service qu’il

peut filtrer selon le type, le demandeur et la date.

Chaque demande peut etre traitee avec une reponse.

57


5.3.2 Conformite aux besoins non-fonctionnels

Apres avoir precise la conformite de notre ERP par rapport aux besoins fonctionnels, passons

maintenant a la verification de la conformite par rapport aux besoins non fonctionnels.

Extensibilite

Nous avons installe une architecture logicielle extensible, l’utilisation de Liferay qui implemente

la specification du portlet (JSR-168 et JSR-256), nous permettant de developper des composants

independants les uns des autres.

Nous avons utilise des designs patterns (IoC et MVC) dans nos architectures applicatives.

Ces patterns nous permettent d’avoir des applications flexibles, extensibles et maintenables.

Securite

Nous avons installe un serveur d’authentification (CAS), ce serveur prend en charge la vali-

dation de l’authentification, de la gestion des sessions et ses durees de vies...

Nous avons configure un certificat SSL pour securiser le flux entre le client et le serveur.

Nous avons centralise les utilisateurs dans un annuaire LDAP (OpenLdap), les mots de passes

sont enregistres apres hachage avec MD5.

58


Figure 5.10 – Interface du serveur CAS

Notre solution gere les autorisations pour chaque role. Les permissions que nous avons

developpees sont inscrites dans le panneau de la configuration de Liferay.

L’administrateur definit les permissions pour chaque role.

59


Figure 5.11 – Gestion d’autorisation

Performances

JMeter est entierement ecrit en Java, ce qui lui permet d’etre utilise sur tout systeme d’ex-

ploitation supportant une machine virtuelle Java (JVM). Il permet de simuler le comportement

de plusieurs utilisateurs agissant de maniere simultanee sur une application Web.

Nous avons effectue deux tests de performances. Voici la configuration de nos tests :

Figure 5.12 – La configuration de test

Nous avons simule cinq utilisateurs en parallele, le ramp-up est fixe en 10 seconds : ramp-up

c’est la periode totale pour creer tous les Threads (utilisateur). Ce test se repetera 100 fois.

Le premier test effectue est un test pour un traitement basique sur le serveur. Nous avons

choisi une requete qui permet d’afficher tous les ouvrages de la bibliotheque.

60


Figure 5.13 – La variation de charge (chargement des ouvrages de la base de donnees)

Le serveur a subi 500 requetes, le temps moyen pour traiter une requete est 275 ms. Le serveur

supporte 868 requetes par seconde.

Le deuxieme test est la generation des releves de notes d’un groupe. Ce groupe comporte dix

inscriptions, la figure ci-dessous decrit la performance de dix releves de notes :

Figure 5.14 – La variation de charge (generation des releves de notes)

61


Nous allons interpreter les courbes ci-dessus, le temps moyen de generer dix releves des notes

est 6807 ms.

Nous pouvons generer les releves des notes pour 43 groupes dans une minute.

La courbe est decroissante a cause de l’utilisation de la memoire cache de Hibernate. Le cout

de chargement des donnees lors des premieres requetes se fait de la base de donnees, par la

suite ces donnees seront stockees dans une memoire cache. D’ou un cout plus faible.

5.4 Conclusion

A ce stade, nous atteignons la fin de l’etude du projet. Ce dernier chapitre nous a servi a

presenter les resultats de la realisation et le fonctionnement de notre ERP. Nous avons com-

mence par devoiler l’environnement logiciel et materiel qui nous a permis d’implementer et

de tester notre ERP. Nous avons verifie ulterieurement la conformite du service aux besoins

fonctionnels contenus dans le cahier des charges

62

CONCLUISON GENERALE

Dans le cadre de ce projet, nous avons participe au developpement d’un ERP universitaire : la

mise en place de l’environnement logiciel, module de gestion de la bibliotheque, module gestion

des inscriptions et des formations, module gestion des notes et des resultats.

Pour mener a bon escient ce projet, nous avons du en premier lieu proceder a une etude

complete des differents documents fournis par le client afin de comprendre le metier de notre

client a travers les differents processus. Cette etape s’est presentee comme un defi pour nous car,

non seulement le nombre de processus est important, mais, les documents fournis ont ete rediges

par des personnes non connaisseuses du domaine informatique visant differentes categories de

lecteurs. La phase de conception n’a pas ete evidente non plus a cause de l’etendue du projet et

du nombre d’intervenants. Donc, nous nous sommes inspires de la demarche 2TUP lors de cette

phase pour diminuer les risques de contresens par rapport aux besoins des utilisateurs ainsi que

le risque de developpements infinis. En ce qui est de la realisation de notre application, nous

avons choisi de profiter de la maturite et de la souplesse de la plateforme Liferay et Alfresco en

basant notre developpement sur des technologies extensibles et libres.

Le choix du framework Hibernate, Spring, JSF, Primefaces nous a permis de surpasser les

obstacles que presente le coulage de plusieurs Frameworks et leur mise en marche. Au-dela de

l’aspect technique, ce projet a represente pour nous une formidable experience humaine, au

63

. CONCLUISON GENERALE

contact des membres de la societe ITIPart qui nous ont prodigue leurs conseils et fait beneficier

de leur experience.

En effet, ce projet nous a permis de prendre des initiatives et de travailler en equipe. Prendre

en charge un tel travail au sein d’une entreprise, nous a aides a developper nos facultes d’analyse,

de reflexion et de decision.

64

BIBLIOGRAPHIE

[1] Richard SEZOV : Liferay in Action, The Official Guide to Liferay Portal Development, 2012

[2] Jean-Paul DECLE : ALFRESCO, Uliliser et administrer une solution de Gestion de Contenu

d’Entreprise, 2010

[3] Jons X.Yuan : Liferay Portal Entreprise Intranets, 2008

[4] Robert Chen, Gaurav Barot : Liferay Beginner’s Guide, 2011

[5] Craig Walls : Spring in action, 2011

WEBOGRAPHIE

[6] http ://www.liferay.com/

[7] http ://wiki.alfresco.com/

[8] http ://www.jasig.org/cas/

[9] http ://tomcat.apache.org/tomcat-3.3-doc/tomcat-ssl-howto.html

[10] http ://www.primefaces.org/

[11] http ://directory.apache.org/studio/

[12] http ://javaserverfaces.java.net/

[13] http ://www.springsource.org/

[14] http ://www.hibernate.org/

[15] http ://www.jaspersoft.com/

[16] http ://quartz-scheduler.org/

[17] http ://www.oracle.com/technetwork/java/javamail/index.html

[18] http ://velocity.apache.org/

66

GLOSSAIRE

LDAP Lightweight Directory Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

CMIS Content Management Interoperability Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

HTTPS Hyper Text Transfer Protocol Secure sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

SDK Software Development Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

SSL Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

SSO Single Sign One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

67

ANNEXE A

INTEGRATION LIFERAY, ALFRESCO, CAS, LDAP

68

ANNEXE A. INTEGRATION LIFERAY, ALFRESCO, CAS, LDAP

A.1 Etape 1 : Installation et configuration du Liferay

avec eclipse

Nous commencons par telecharger le serveur Liferay et un plugin SDK, nous pouvons les

trouver dans ce lien :

http ://www.liferay.com/downloads/liferay-portal/available-releases

Figure A.1 – Configuration du Liferay avec Mysql

Lors du premier lancement de Liferay, une interface de configuration s’affichera. On determine

les parametres de la base de donnees qui contiendra les tables du protail Liferay.

69


Figure A.2 – Installation du Plugin Liferay dans Eclipse

Le developpement des projets Liferay necessite l’installation d’un plugin sur Eclipse, nous

devons installer ce plugin pour pouvoir configurer et deployer les projets Liferay.

Figure A.3 – Configuration du SDK Liferay avec Eclipse

Nous devons configurer aussi Software Development Kit (SDK), telecharge de site du Liferay,

avec Eclipse.

70


Figure A.4 – Configuration du serveur Liferay (sous Tomcat) avec Eclipse

Nous finissons cette etape par la configuration du serveur Liferay (dans notre cas le serveur

est Tomcat) avec Eclipse.

A.2 Etape 2 : Installation du OpenLdap

Dans cette etape, nous installons l’annuaire OpenLdap, notre environnement de developpement

est Linux, il suffit de lancer la commande sudo apt-get install slapd ldap-utils.

71


Figure A.5 – Installation de OpenLdap

Nous devons par la suite demarrer le serveur OpenLdap.

A.3 Etape 3 : Installation et configuration du serveur

CAS avec OpenLDAP

Nous telechargerons le serveur CAS la version 3.5.1 : http ://www.jasig.org/cas/download

Nous devons copier le fichier cas-server-webapp-3.5.1.war dans le dossier webapp.

72


Figure A.6 – tester le fonctionnement du serveur CAS

Apres le demarrage du serveur, l’interface ci-dessous s’affiche. Nous remarquons que le serveur

CAS exige un certificat Secure Sockets Layer (SSL).

Maintenant, nous allons configurer le serveur CAS avec l’annuaire LDAP (OpenLdap). Les

figures A.7 et A.8 sont la configuration que nous devons ajouter dans le fichier.

webapps/cas-web/WEB-INF/deployerConfigContext.xml

73


Figure A.7 – Configuration du serveur CAS avec OpenLdap

Nous devons preciser l’adresse de l’annuaire LDAP et les parametres d’authtification (UserDn

et password).

Figure A.8 – Definir le domaine de recherche et le parametre d’authentification

Le figure ci-dessus presente le fonctionnement du serveur CAS, nous determinons la base de

recherche dans notre annuaire LDAP et le filtre ou IDuser (l’identifiant de l’utilisateur). Ce

filtre doit etre unique.

A.4 Etape 4 : Activation de l’HTTPS et la configuration

d’un certificat SSL sur un serveur Tomcat

Pour que le serveur CAS fonctionne correctement, il devra fonctionner en mode Hyper Text

Transfer Protocol Secure sockets (HTTPS). Par consequence, nous devons creer un certificat

74


et le configurer avec Tomcat.

Figure A.9 – Definir et parametrer un certificat electronique

A l’aide de l’outil keytool nous avons cree un certificat, ce certificat doit etre X509. Pour cela,

nous devons le convertir a l’aide de l’outil openSSL.

Ce certificat genere doit etre configure avec Tomcat. Nous devons ajouter la configuration

ci-dessous dans le fichier : conf/server.xml

Figure A.10 – Activer le HTTPS dans le serveur tomcat

Nous precisons le port (8443) le mot de passe (changeit) et le chemin de notre certificat.

Apres le demarrage du serveur, le HTTPS sera active.

75


A.5 Etape 5 : Configuration Liferay avec LDAP

Liferay devra importer ses utilisateurs du l’annuaire LDAP. Liferay implemente les interfaces

de configuration avec les annuaires LDAP.

Figure A.11 – Configurer Liferay avec OpenLdap

Nous devons determiner l’adresse de l’annuaire LDAP avec le port, la base de recherche et

les parametres d’authentification.

A.6 Etape 6 : Configuration Liferay avec CAS

Nous devons determiner la configuration de Liferay avec le serveur CAS. Liferay integre les

interfaces avec CAS.

76


Figure A.12 – Configurer Liferay avec le serveur CAS

Nous determinons les URLs de navigation entre Liferay et le serveur CAS :

-URL de connexion.

-URL de deconnexion.

-URL de Lifray.

-URL du serveur CAS.

A.7 Etape 7 : Installation d’Alfresco

Apres l’integration de Liferay, OpenLdap et CAS, nous ajoutons Alfresco a notre infrastruc-

ture operationnelle.

Nous commencons par le telechargement d’Alfresco de son site officiel :

http ://wiki.alfresco.com/wiki /DownloadandInstallAlfresco

77


Apres le lancement de l’installation d’alfresco, nous devons configurer ses ports et les parametres

de connexion a la base de donnees.

Figure A.13 – Configurer Alfresco avec le MySql

La figure A.13 explique la configuration d’Alfresco avec Mysql, nous determinons l’URL et

les parametres de connexion. Nous pouvons configurer Alfresco avec n’importe quel serveur de

base de donnees.

78


Figure A.14 – Definition des ports d’Alfresco

Nous preciserons les ports de fonctionnement pour le serveur Tomcat d’Alfresco : Le port du

serveur, port SSL, port Shutdown et le port de AJP.

A.8 Etape 8 : Configuration Alfresco avec LDAP

Maintenant, nous integrons LDAP avec Alfresco, nous devons creer cette arborescence dans le

serveur Tomcat :

tomcat/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1

Nous creons un fichier ldap-authentication.properties, voici son contenu :

79


Figure A.15 – Configurer Alfresco avec OpenLdap

Ce fichier contient les parametres de connexion avec OpenLdap et le mapping entre les

attributs d’Alfresco et l’annuaire Ldap.

Figure A.16 – Interface d’Alfresco

Maintenant, nous pouvons faire l’authentification avec les parametres de notre annuaire

LDAP.

80


A.9 Etape 9 : Configuration Alfresco avec CAS

Derniere etape a faire, c’est l’integration du serveur CAS avec Alfresco. D’abord, il faut

ajouter les librairies clients du CAS dans le dossier lib d’Alfresco.

Apres, nous allons ajouter des filtres dans le fichier : /tomcat/webapps/alfresco/WEB-INF/web.xml

Figure A.17 – Configuration d’Alfresco avec le serveur CAS

Maintenant, notre infrastructure operationnelle est fonctionnelle, le serveur CAS est le seul

point d’authentification dans notre reseau. Liferay et Alfresco redirigent vers le serveur CAS.

Les utilisateurs sont enregistres dans OpenLdap. L’authentification se fait une seule fois dans

CAS. Apres, l’utilisateur sera authentifie dans les deux solutions.

81

Technology

ERP Universitaire