ALAMI JAMAL Training Repport Logica 2010 Business Activity Monitoring

ROYAUME DU MAROC
*-*-*-*-*
HAUT COMMISSARIAT AU PLAN
*-*-*-*-*-*-*-*
INSTITUT NATIONAL
DE STATISTIQUE ET D’ECONOMIE APPLIQUEE
Projet de Fin d'Etudes

*****
N°89
Business Activity Monitoring : Développement des

Indicateurs clé de performance et Déploiement web en
charts sur WebMethods.
Préparé par : M. ALAMI JAMAL
Sous la direction de : M. OURADI Najib (INSEA)

M.LAAOUINATE Anas (LOGICA)
M.BELAHCEN Rachid (LOGICA)
Soutenu publiquement comme exigence partielle en vue de l'obtention du
Diplôme d'Ingénieur d'Etat

Option : INFORMATIQUE
Devant le jury composé de :
 M. OURADI Najib (INSEA)

 M. SEKKAT Abedel Jawad (INSEA)
 M.LAAOUINATE Anas (LOGICA)
 M.BELAHCEN Rachid (LOGICA)
Juin 2010
Dédicace :
A mes chers parents, merci pour tout. Vos sacrifices et votre
dévouement m’ont permis d’être ce que je suis. Papa, tu es mon idole. Tu
m’as inculqué la bonne éducation et les bonnes manières. Chère maman, tu
étais toujours là pour me soutenir et pour m’aider. Tu t’es toujours fatiguée
pour mon repos. Je vous le dis rarement : je vous aime. Que Dieu vous
préserve et vous garde.
A mon frère Oussama, mon compagnon de tous les temps. J’espère pour toi tout le
bonheur du monde. Que Dieu te permette de réussir dans tes études et d’atteindre tes
objectifs.
A ma sœur RAJAE, A ma princesse Sophia, je vous souhaite tout le bonheur du
monde.
A tous les amis que j’ai connus, à toute personne qui m’a soutenu, à toute personne
pour qui j’ai compté, je vous dis merci pour tout.
Jamal ALAMI.
2
Remerciement :
Je ne saurais commencer ce rapport sans remercier ALLAH le tout
puissant, le tout miséricordieux, qui m’a donné Grâce et bénédiction pour
mener à terme ce projet.
Au terme de ce travail, je tiens à exprimer mes profonds
remerciements à toutes les personnes qui ont contribué au bon déroulement
de ce projet de fin d’étude.
Pour cela, je tiens à remercier mon encadrant, M. Najib OURADI
pour ses directives précieuses et ses conseils pertinents qui m’a été d’un appui
considérable dans mes démarches.
Bien sûr, un grand merci à mon encadrant de stage M. Anas
LAAOUINAT, et mes responsable hiérarchiques M.Belghazi Jalal et Mr. Rachid
BALHCEN qui ont su me laisser une réelle autonomie, tout en me guidant et en
m’apportant l'aide et les moyens nécessaires au bon déroulement de mon stage.
Je tiens à exprimer ma gratitude à Mr. Jawad SEKKAT pour m’avoir
honoré en acceptant de juger mon travail. Veuillez trouver ici le témoignage de mon
respect le plus profond.
Je remercie chaleureusement tout le personnel de la société LOGICA et
spécialement les membres de l’équipe RHODIA : M.Bouchefra Hassan, M.Loukili
Merouane et M.Zouaoui Abdelaziz pour leur aide inconditionnelle et leur accueil
chaleureux et sympathique qui m’a permis de m’intégrer très rapidement.
Je ne saurais oublier dans mes remerciements tout le cadre
professoral de l’INSEA, pour la formation prodigieuse qu’il m’a prodiguée.
Que tout ceux qui m’a aidé, de près ou de loin, trouvent ici
l’expression de mes sentiments les meilleurs.
3
Résumé :
Mon projet de fin d’étude s’inscrit dans le cadre du projet Rhodia,

confié à Logica afin d’automatiser les échanges de documents commerciaux
entre Rhodia et ses partenaires. L’enjeu principal du projet étant de mesurer
la performance de l’activité de point de vue processus et offrir un aperçu
général de son évolution.
Mon projet a démarré avec une collecte des besoins auprès de
l’équipe projets, il s’est enchainé par la conception et la mise en place des
modules conçus suivant une méthode agile convenable. Les objectifs visés
étaient de fournir une solution complète pour le pilotage du projet Rhodia
par la performance.
Afin d’atteindre ces objectifs, j’étais amené à bien explorer la
plate-forme intermédiaire WebMethods et connaitre ses spécifications et les
différents paramétrages qu’elle puisse fournir,
Pour en fin intégrer ma solution de Business Activity Monitoring,
J’ai donc opté pour un portfolio de technologies respectant les spécifications
techniques de WebMethods, entre autres, le SGBDR Oracle et les
frameworks de présentation conformes.
4
Liste des abréviations :
Abréviation Désignation
BAM Business Activity Monitoring
BPM Business Process Management
WM WebMethods
MWS My WebMethods Server
CMMI Capability Maturity Model Integration
AJAX Asynchronous JavaScript And XML
CS Centre de Services
CS Centre de Sevices Maroc
EJB Entreprise JavaBeans
GPL General Public License
GNU Gnu's Not Unix
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
J2EE Java 2 Enterprise Edition
KPA Key Process Area
IHM IHM Interface Homme Machine
JSF Java Server Pages
MAJ Mise à Jour
MVC Model View Controller
SGBDR Systèmes de Gestion de Bases de Données Relationnelles
SMQ Système de Management de la Qualité
SOA Service Oriented Architecture
SQL Structured Query Language
SSII Société de Services et d’Ingénierie Informatique
SAP Systems, Applications, and Products for data processing
UML Unified Modelling Language
XML eXtensible Markup Language
5
Liste des figures :
Figure 1: Historique de Logica........................................................................................................... 16
Figure 2: Les secteurs d’activités de Logica...................................................................................... 16
Figure 3 : Centres de Logica dans le monde ..................................................................................... 17
Figure 4 : Partenaires stratégiques .................................................................................................... 17
Figure 5: Clients de LOGICA ............................................................................................................ 18
Figure 6 : Proportion des catégories des centres de services de Logica ......................................... 19
Figure 7 : Evolution de l’effectif du CSR .......................................................................................... 20
Figure 8 : Organigramme de Logica CSM........................................................................................ 20
Figure 9 : Organigramme du projet Rhodia EAI............................................................................. 24
Figure 10 : Adaptativité / Prédictivité des méthodes........................................................................ 26
Figure 11 : Décomposition de projet en sprints ................................................................................ 27
Figure 12 : Vue synthétique du processus Scrum............................................................................. 27
Figure 13 : Diagramme de gant.......................................................................................................... 28
Figure 14 : Architecture fonctionnelle............................................................................................... 31
Figure 15 : Architecture des composants métiers............................................................................. 32
Figure 16 : Architecture de déploiement sur Rhodia EAI ............................................................... 32
Figure 17 : Architecture BAM en WebMethods 8............................................................................ 33
Figure 18 : Architecture fonctionnelle exprimant le besoins ........................................................... 35
Figure 19 : Flux Elemica PurshaseOrder .......................................................................................... 40
Figure 20 : Flux Elemica Invoice ....................................................................................................... 41
Figure 21 : Flux Elemica OrderChange ............................................................................................ 42
Figure 22 : BuySide Raw Material..................................................................................................... 43
Figure 23 : BuySide Raw Material SubProcess ChemXML............................................................ 44
Figure 24 : Elemica Invoice ................................................................................................................ 45
Figure 25 : Elemica OrderChange ..................................................................................................... 45
Figure 26 : Diagramme d’utilisation : Business Process Management .......................................... 47
Figure 27 : Diagramme d’utilisation: Business Activity Monitoring.............................................. 48
Figure 28 : Diagramme de classe: Ebusiness .................................................................................... 51
Figure 29 : Diagramme de classe: Paquetage données permanents. .............................................. 52
Figure 30 : Diagramme de classe: Paquetage flux et transactions. ................................................. 53
Figure 31 : Diagramme de classe: Paquetage Incidents. .................................................................. 53
Figure 32 : Diagramme de classe: Documents Commerciaux. ........................................................ 54
Figure 33 : Architecture composants essentiels ................................................................................ 56
Figure 34 : Perspective Business Analyste : WebMethods Designer .............................................. 66
Figure 35 : WebMethods Developer .................................................................................................. 67
Figure 36 : Modèle Vue Contrôleur 2 ................................................................................................ 71
Figure 37 : Architecture générale. ..................................................................................................... 71
Figure 38 : Architecture logique de l’application Portlet CAF ....................................................... 72
Figure 39: Architecture de déploiement ............................................................................................ 73
Figure 40: Diagramme du Reste à faire en heures du premier Sprint ........................................... 74
Figure 41: Diagramme du Reste à faire en heures du deuxième Sprint ......................................... 75
Figure 42 : Premier Portlet Test ........................................................................................................ 75
Figure 43: Diagramme du Reste à faire en heures du troisième Sprint ......................................... 76
Figure 44 : Interface d’authentification ............................................................................................ 77
6
Figure 45 : Interface d’accueil............................................................................................................ 77
Figure 46 : JSF View : Volume de transactions................................................................................ 78
Figure 47 : JSF View : Volume de transactions par flux ................................................................. 79
Figure 48 : JSF View : Répartition des flux selon la requête temporelle ....................................... 80
Figure 49: Les KPA de Cortex ........................................................................................................... 85
Figure 50: L’approche Spaghetti Traditionnelle et L’approche EAI ........................................... 88
Figure 51: L’Approche Métier EAI ................................................................................................... 89
Figure 52: Echange d’informations entre entreprise et partenaires via un bus ESB ................... 96
Figure 53: Routage de données .......................................................................................................... 97
Figure 54: Transformation des données en XML............................................................................. 97
Figure 55: Processus Elemica ShipNotice ......................................................................................... 98
Figure 56: Processus EtapOnLine ..................................................................................................... 99
Figure 57: Processus Inventory actual usage .................................................................................. 100
Figure 58: Processus Carriers .......................................................................................................... 102
Figure 59: SellSide OrderChange .................................................................................................... 103
Figure 60: SellSide OrderCreate 2 ................................................................................................... 103
Figure 61: Elemica OrderCreate ..................................................................................................... 104
Figure 62: Elemica shipnotice .......................................................................................................... 104
7
Liste des tableaux :
Tableau 1 : identification des acteurs ................................................................................................ 37
Tableau 2: Portées de gestion de cycle de vie d’un JSF managed bean.......................................... 59
Tableau 3: Composants WebMethods ............................................................................................... 93
Tableau 4: Types de documents transitant dans les flux de Rhodia ............................................. 106
8
Sommaire :
Chapitre 1 : Contexte général du Projet ........................................................................... 14

I. Organisme d’accueil : LOGICA Group ............................................................................................ 14
I.1. Présentation générale : ......................................................................................................... 14
I.2. Evolution historique : ............................................................................................................ 14
I.3. Activités : ............................................................................................................................... 16
I.4. Clients et partenaires : .......................................................................................................... 17
I.5. Centre de services LOGICA Maroc : ....................................................................................... 18
II. Cadre général : Le Projet d’intégration Rhodia ............................................................................. 21
II.1. Groupe Rhodia :..................................................................................................................... 21
II.2. Objectifs de l’entité projet Rhodia: ....................................................................................... 22
II.3. Prestations de l’entité projet Rhodia : .................................................................................. 23
II.4. Organisation et conduite du projet Rhodia TMA : ................................................................ 23
III. Missions objets du PFE : ............................................................................................................ 24
III.1. BPM : Modélisation et déploiement de modèles de flux ...................................................... 24
III.2. BAM: Pilotage de l’activité par la performance .................................................................... 24
III.3. GED : Gestion électronique de documents ........................................................................... 25
IV. Conduite du projet : .................................................................................................................. 25
IV.1. Processus du développement : ............................................................................................. 25
IV.2. Planning: ................................................................................................................................ 28
Chapitre 2 : Etude Préliminaire........................................................................................ 30
I. Introduction : ................................................................................................................................. 30
II. Étude de l’existant : ....................................................................................................................... 30
II.2. Présentation de la solution EAI implantée : .......................................................................... 30
II.2. Besoins incontournables en BAM et limitations: .................................................................. 32
II.3. Solution proposée : Portlet CAF ............................................................................................ 34
III. Analyse et spécifications : ......................................................................................................... 35
III.1. Fonctionnalités visées de l’application BAM ......................................................................... 35
III.2. Définition des KPIs et métriques essentielles : ..................................................................... 35
III.3. Identification des acteurs et répartition des fonctionnalités : .............................................. 37
IV. Conclusion : ............................................................................................................................... 37
9
Chapitre 3 : Modélisation métier et conception détaillée de Préliminaire ........................ 39
I. Cartographies d’exemples de flux de transactions ....................................................................... 39
II. Modélisation des processus métier : ............................................................................................ 43
II.2. Exemples de Modèles :.......................................................................................................... 43
III. Conception objet : ..................................................................................................................... 46
III.1. UML : ..................................................................................................................................... 46
III.2. Modélisation fonctionnelle, Cas d’utilisation : ...................................................................... 47
III.3. Description des cas d’utilisation : .......................................................................................... 48
III.4. Modélisation statique, Diagrammes de classes : .................................................................. 51
Chapitre 4 : Etude Technique .......................................................................................... 56
I. Introduction : ................................................................................................................................. 56
II. La plate forme Webmethods :....................................................................................................... 56
II.1. Architecture générale et composants essentiels : ................................................................ 56
II.2. Le portail : .............................................................................................................................. 56
II.3. Le portlet : ............................................................................................................................. 57
II.4. Le conteneur de portlet :....................................................................................................... 57
II.5. Les Concepts du Composite Application Framework sur Webmethods. ............................. 57
III. Les technologies exploitées : ..................................................................................................... 59
III.1. Frameworks Java/Jee : .......................................................................................................... 59
III.2. Oracle : .................................................................................................................................. 65
IV. Outils et environnements de développement : ........................................................................ 66
IV.1. WebMethods Designer.......................................................................................................... 66
IV.2. Webmethods Developer. ...................................................................................................... 67
IV.3. Conclusion : ........................................................................................................................... 68
Chapitre 5 : Mise en œuvre ......................................................................................................... 70
I. Introduction : ................................................................................................................................. 70
II. Modèle Vue Contrôleur 2: ............................................................................................................. 70
III. Architecture générale de l’application Composite:................................................................... 71
IV. Architecture logique de l’application composite: ..................................................................... 72
V. Architecture de déploiement : ...................................................................................................... 73
VI. Démarche de développement : ................................................................................................. 73
VI.1. Premier Sprint: Portlets présentant des données statiques : ............................................... 74
VI.2. Deuxième Sprint : Services récupérant des données du serveur d’intégration : .................. 74
VI.3. Troisième Sprint : Création d’une base de données intermédiaire réservée au BAM.......... 76
10
VII. Eléments de la réalisation : ....................................................................................................... 77
VIII. Conclusion : ............................................................................................................................... 81
Conclusion générale et perspectives:............................................................................... 82
Bibliographie : ............................................................................................................................ 83
Annexes : ................................................................................................................................... 84
11
Introduction générale :
Aujourd’hui plus que jamais, il est essentiel que les équipes informatiques et les lignes
métier des entreprises parlent un langage commun et soient alignées sur des objectifs
partagés. L’un des moyens d’y parvenir consiste à utiliser des indicateurs de performance ou
KPI (Key Performance Indicators).
Ces KPIs sont familiers pour les lignes métier. Toutefois, au sein des équipes
informatiques, gérer le progrès et les améliorations en utilisant des KPIs basés sur la
performance métier, commence seulement à faire son chemin, et constitue une opportunité
que les équipes Informatiques doivent saisir afin d’aider l’entreprise à surmonter la récession
au lieu de la subir.
Dans le monde de l'entreprise, on sait bien que les données mesurées sont celles qui
retiennent le plus l'attention. Par conséquent, les équipes informatiques doivent veiller à ce
que les métriques appropriées sont utilisées comme indicateurs clés de la performance, de
sorte que les mesures appropriées soient mises en œuvre par les responsables métier et les
équipes informatiques et que les objectifs fixés par ces indicateurs puissent être atteints. Pour
ce faire, il est essentiel de communiquer les objectifs métier à tous les acteurs de l’activité
informatique et de les inciter à comprendre les indicateurs clés de performances à la lumière
de ces objectifs.
Le service informatique doit inclure, combiner, consolider et analyser la profusion

d'informations conservées au sein de l'infrastructure informatique et les convertir en
indicateurs clés de performances compréhensibles par les directeurs informatiques comme par
les responsables des services métier.
LOGICA, première société de service Offshore au Maroc, en sous traitant l’activité de

gestion des échanges de documents commerciaux entre le Groupe chimique Rhodia et ses
partenaires vise à piloter le projet par la performance, ceci dit: élaborer une stratégie, mesurer
et innover.
Le pilotage axé sur la performance nécessite la définition de KPIs et la conception de

métriques reflétant les mesures pertinentes dans l’activité gérée par LOGICA. La finalité étant
toujours l’alignement des stratégies métier de Rhodia et les processus informatiques de
Logica. Le pilotage axé par la performance va permettre par la suite à Rhodia de modéliser le
coût par transaction et ainsi calculer ses pertes financières.
Le pilotage de l’activité commerciale de Rhodia par la performance est la problématique

principale de mon projet de fin d’études. Dans ce contexte j’ai essayé de répondre aux attentes
de Logica en réalisant une application web permettant de visualiser les métriques relatives
aux KPIs que j’ai jugé essentiels de concevoir.
12
Chapitre 1
Contexte général du projet
Dans la première section de ce chapitre

nous allons présenter un aperçu sur
l’organisme d’accueil à savoir LOGICA,
son organisation, son domaine d’activité et
ses missions. La deuxième section sera
dédiée à la description du cadre général du
projet.
13
Chapitre 1 : Contexte général du Projet
I. Organisme d’accueil : LOGICA Group
I.1. Présentation générale :
Logica est un acteur international majeur des services informatiques, spécialisé dans le
conseil, l'ingénierie informatique, notamment l'intégration de systèmes, l'outsourcing
applicatif, et la formation (training). Le groupe réunit environ 40 000 personnes dans plus de
36 pays à travers le monde, dont le Maroc avec deux centres de service CSR et CSC. Cette
capacité d’externalisation compétitive est mise au service de ses clients dans un objectif
d’optimisation de leurs investissements.
Logica travaille en étroite collaboration avec ses clients afin de les aider à libérer leur
potentiel pour devenir plus productifs, accélérer leur croissance et gérer les risques. Logica
s’appuie sur ses connaissances approfondies des secteurs, son excellence en matière de
technologie et de production ainsi que sur son expertise en matière de delivery pour aider ses
clients à se positionner en tête de leurs marchés respectifs.
Logica bénéficie d’un réseau européen puissant et équilibré sur ses principaux marchés
en particulier dans les Pays Nordiques, aux Pays-Bas, en France où elle figure parmi les 5
premiers acteurs du marché et au Royaume-Uni où il bénéficie d’une implantation historique.
I.2. Evolution historique :
 En 1968, la société Informatique et l’entreprise est créée.

 En 1983, la société regroupe sous le nom d'Unilog l'ensemble de ses filiales. En 1987,
Unilog commence son expansion sur le territoire national en ouvrant à Lyon sa
première agence régionale. La même année, la Société crée son activité consulting.
 En 1988, Unilog rentre au second marché où elle réalise en 1998 la meilleure
performance boursière. En Juillet 1998, Unilog prend pied en Allemagne : elle
acquiert le groupe Integrata (800 personnes - top 20 en Allemagne).
 En juin 1999, Unilog acquiert NSA (New Software Associates), société de 270
personnes.
 En juillet 1999, Unilog est transférée au Règlement Mensuel.
 En décembre 1999, Unilog fait un pas européen supplémentaire en prenant une
participation de 70 % dans la société suisse GDI (100 personnes, 10 millions Euros de
chiffre d'affaires), société de services informatiques implantée à Genève et à
Lausanne. Elle acquiert 100% en 2000.
 En janvier 2000, Unilog inaugure une nouvelle ère en procédant à la création de
l'ESCAN (European Software Companies Allied Network), la première alliance
14
européenne en conseil et ingénierie informatique, née de la coopération entre

Engineering Ingegneria Informatica (Italie), Ibermàtica (Espagne) et Unilog. Cette
alliance, qui pèse près de 650 millions Euros de chiffre d'affaires et rassemble 7250
professionnels entend répondre aux nouvelles exigences du marché européen.
 Le 6 avril 2000, Unilog acquiert la société allemande VSS : CA additionnel de 26
millions Euros et 250 collaborateurs. L'ensemble des entités allemandes de la société
représente désormais 1 150 collaborateurs et se place dans le top 10 du secteur.
 Le 31 mai 2001, Unilog déjà présente dans 5 pays européens (France, Allemagne,
Autriche, Suisse, Luxembourg) s'implante au Royaume-Uni. Unilog annonce
l'acquisition de la division technology de la filiale anglaise de March First USA,
spécialisée dans le conseil technologique et l'intégration de systèmes autour d'Internet.
La nouvelle entité compte 150 collaborateurs.
 En janvier 2002, Unilog GDI, en Suisse Romande prend le nom d'Unilog USR.
 En avril 2002, Unilog et Ibermática, fondateurs de l'alliance ESCAN, première
alliance européenne dans le domaine des services informatiques, annoncent l'arrivée
d'un nouveau partenaire italien, Gruppo MET qui prendra le nom MET Sogeda en
2003.
 Le 9 juillet 2004, Unilog et Avinci ont signé un protocole d'accord visant au
rapprochement des deux entités et ainsi à la constitution en Allemagne d'une société
de conseil et d'ingénierie, capable de rivaliser avec les meilleures. Le rapprochement
d'Unilog et d'Avinci permettra de constituer, dans le conseil et l'ingénierie en
Allemagne, une entité forte de près de 800 consultants et ingénieurs.
 Le 19 septembre 2005, LogicaCMG et Unilog annoncent leur projet de rapprochement
amical.
 Le 10 janvier 2006, les résultats de l'OPA permettent à LogicaCMG de prendre le
contrôle d'Unilog. Ensemble, les deux sociétés donnent naissance à un leader européen
des services informatiques : 3ème groupe européen de services informatiques en terme
de capitalisation boursière. Avec près de 30 000 collaborateurs, une présence dans 36
pays et un chiffre d'affaires de plus de 3Md d'euros le groupe entre dans le top 10 des
sociétés de services informatiques en Europe et est désormais 4ème en France. Martin
Read est Président du groupe LogicaCMG.
 Le 16 janvier 2006, Unilog prend le nom de "Unilog, à LogicaCMG Company".
 Le 1er mars 2006, Didier Herrmann prend officiellement ses fonctions de Président du
Directoire d'Unilog SA, tandis que Gérard Philippot rejoint le Conseil de Surveillance
en tant que Vice-Président.
 Le 27 février 2008 LogicaCMG devient Logica partout dans le monde.
15
Figure 1: Historique de Logica
I.3. Activités :
Logica est un acteur international de premier plan dans le domaine des services
informatiques et des télécommunications sans fil, qui intervient dans plusieurs secteurs. Son
activité englobe le conseil en management et technologies de l'information, l'intégration de
systèmes et l'externalisation, sur les marchés des télécommunications, des services financiers,
de l'énergie, de l'industrie, distribution & transports, et du secteur public (fig1).
Figure 2: Les secteurs d’activités de Logica

Parmi les réalisations du groupe :
 Avec 3000 experts SAP, Logica est un des 12 «Global Strategic Partners»
 5 000 Milliards $ sont transférés chaque jour grâce aux logiciels financiers LOGICA.
 2 SMS sur 3 dans le monde transitent par des systèmes LOGICA.
16
LOGICA, la SSII à laquelle les DSI (Direction du Service Informatique) font le plus
confiance (enquête DSI 2005).
I.4. Clients et partenaires :
Le groupe Logica emploie 40.000 personnes à travers 41 pays, avec un chiffre

d’affaire de 4 Mrd d’euros en 2006.
La figure suivante présente la cartographie du groupe Logica à travers le monde :
Figure 3 : Centres de Logica dans le monde

Le groupe possède un nombre important de partenaires à travers le monde :
 Partenaires stratégiques
Figure 4 : Partenaires stratégiques
17
 Partenaires dédiés :
BEA Systems, Business Objects, Cognos, EMC, Filenet, HRAccess, Hypérion,

Pivotal, Selligent, Sun, Tibco, Webmethods, Seebeyond.
 Clients :
Logica a un large éventail de clients de différents secteurs d’activités tel que le métier
d’assurances, télécommunications, automobile, I.T., et autres.
La diversité des collaborateurs et la présence de Logica dans 36 pays, sont les facteurs clés
qui lui offrent une forte puissance dans le marché international du service informatique.
Au Maroc, Logica gère 11 différents clients et 16 projets répartis sur deux sites Rabat
et Casablanca, avec des technologies diversifiées :
Figure 5: Clients de LOGICA
I.5. Centre de services LOGICA Maroc :

I.5.1. Organisation :
Les centres de services de Rabat et de Casablanca s'inscrivent dans un modèle de

production mondiale de services répondant au besoin du client conçu par Logica : le modèle
«GSD». Il s'appuie sur un réseau de 16 centres de services dans le monde, dédiés à la
production, au développement ou au support informatique.
Logica, privilégie ainsi la proximité, la connaissance de ses clients, tout en demeurant

en étroite relation avec un réseau mondial. Ces centres de services sont répartis en trois
catégories:
18
 Les centres On shore : situés à moins d’une heure de vol sur le territoire
national (Amiens par exemple).
 Les centres Near shore : situés à plus d’une heure de vol dans des pays proches
(Maroc, Estonie, Pologne).
 Les centres Off shore : situés dans des régions plus éloignées (Inde,
Philippines, Chine).
Figure 6 : Proportion des catégories des centres de services de Logica
Le choix du critère de proximité ou d'éloignement varie en fonction du besoin

d'interaction avec le client. Plus un projet sera complexe ou risqué plus il sera géré près de
l'entreprise voire sur le site même de l'entreprise. En revanche, un projet moins risqué ou
moins complexe pourra être produit sur différents sites. C'est ce que Logica appelle le
«blended model» ou modèle mixte qui consiste à allouer à un projet des ressources
informatiques localisées en différents centres de services.
Au cours de l’année 2004, au Maroc, Unilog et Sofrecom, filiale de France Telecom,

ouvrent un centre de service à Rabat. Cette alliance repose sur l’expertise de deux acteurs
importants de l’externalisation informatique.
Le centre de service de Rabat (CSR) a commencé en fin de l’année 2004 avec un

effectif d’une dizaine de personnes, mais ce nombre n’a pas cessé d’augmenter. La figure
suivante présente l’évolution de l’effectif du CSR:
19
Figure 7 : Evolution de l’effectif du CSR
Organigramme LOGICA CSM:
Directeur
Général
Responsable Responsable Delivery

HR Manager
Infra Logistique Manager
Resource Responsable Transition

SPM
Manager Qualité Manager
Responsable
Projet
Collaborateur
Figure 8 : Organigramme de Logica CSM
I.5.2. Prestations proposées:
 Infogérance Applicative:
 Support troisième niveau

 Maintenance corrective
20
 Maintenance évolutive
 Maintenance préventive
 Support Applicatif:
 Support de deuxième et troisième niveau

 Intervention multi langue
 Traitement multi canal
 Tierce Recette Applicative:
 Conception des plans de tests

 Exécution des plans de tests
II. Cadre général : Le Projet d’intégration Rhodia
II.1. Groupe Rhodia :
Rhodia est un groupe chimique international, résolument engagé

dans le développement durable. Devenu indépendant de Rhône-
Poulenc en 1998, le groupe Rhodia est le premier fabricant
mondial de phosphates de spécialité. Ces composants chimiques entrent dans la fabrication
d'une multitude de produits industriels pour des secteurs aussi variés que l'automobile,
l'agrochimie, l'électronique, la pharmacie, l'industrie textile ou l'alimentation.
Avec 114 unités de production et 38 centres de recherche répartis dans 150 pays,
Rhodia (6,6 milliards d'euros de chiffre d'affaires en 2002) a fait du e-business une de ses
priorités. En 2001, le groupe décide de rationaliser sa présence internationale sur le Web en
réduisant de moitié la quarantaine de sites lancés à l'initiative de ses diverses filiales ou
entités. «Notre souci majeur était d'endiguer la dérive web, d'éviter que ça parte dans tous les
sens», explique Santiago Tolosa, responsable "e-solutions, application integration et data
integration" du groupe.
Rhodia a confié à Logica la sous-traitance de toutes ses activités informatiques en

l’occurrence la gestion et l’automatisation des échanges avec ses partenaires: c'est ainsi qu'est
né le projet Rhodia en septembre 2005 au sein du Centre de service LOGICA Rabat.
21
II.2. Objectifs de l’entité projet Rhodia:
Après la création d'un centre de compétences et de ressources pour ses sites web, le
groupe chimique a déployé une plate-forme d'intégration pour gérer ses processus métier
internes et les échanges avec ses partenaires.
Le projet Rhodia est mis en place afin d’automatiser la gestion des transactions entre
Rhodia et ses partenaire, et ainsi ouvrir le système d’information de Rhodia à l’extérieur, en
mutualisant les échanges avec les partenaires de la place, et en améliorant le service aux
utilisateurs. Pour ce faire l’équipe projet Rhodia adopte l’approche EAI : Enterprise
Application Integration.
Selon les experts L’EAI s’avère être la seule solution permettant non seulement de
connecter des applications et des sources de données hétérogènes, mais aussi de capitaliser sur
l’avenir en offrant à la société une souplesse qui se traduit notamment par des gains en temps
de développement et en coûts de maintenance.
 Rhodia EAI :
Le projet Rhodia consiste en plusieurs activités gérées principalement par un

responsable de projet et un directeur de projet. Cependant, chaque activité jouit d’une pseudo-
indépendance, vu que, chacune d’elles a son propre chef de projet (présent chez le client
(Rhodia)).
Ceci dit le responsable de projet coordonne entre ces différents éléments afin de mener
à bien l’ensemble du projet.
 Support :
Le support constitue une activité assurée par l’équipe EAI.
En effet assister les différents utilisateurs Rhodia qui rencontrent des problèmes avec
le progiciel est un évènement fréquent, cela nécessite alors une investigation et une recherche
avancée de l’origine du problème afin de trouver une solution et de la réaliser.
Les demandes de supports parviennent soit par mail soit directement par téléphone (ou
skype).
 Maintenance Applicative :
La mise en place de nouveaux flux fait aussi partie de certaines tâches étant
consignées. Entre évolutions prévues, ou modifications des fonctionnalités existantes, la
maintenance se fait sur environnement de développement avant le lancement de la phase de
tests pour une livraison finale.
22
II.3. Prestations de l’entité projet Rhodia :
 Études préalables
 Études générales et détaillées.

 Développements spécifiques.
 Assistance à la recette.
 Tierce maintenance applicative.
 Paramétrage.
 Formation des utilisateurs
 Support client, hotline.

 Supervision & exploitation.
II.4. Organisation et conduite du projet Rhodia TMA :
La Tierce Maintenance Applicative consiste, pour une entreprise, à déléguer la

maintenance d'une partie ou de la totalité de son système d'information à un partenaire. Les
services délivrés par LOGICA à Rhodia dans le périmètre de la TMA sont :
 Le pilotage et l’accompagnement en conseil, management, gestion et reporting du

projet.
 L’analyse des demandes de maintenance corrective et de maintenance évolutive.
 La participation à la résolution des incidents.
 Le traitement des corrections de données en masse.
 Le suivi de production.
23
 Organigramme du projet Rhodia :
Rachid Ben Lahcen

Responsable Projet
Sanae Benkaroum Laaouinate Anas

Responsable
Support TMA
Belghazi Jalal
Bouchefra Hassan Loukili Merouane
TMA
Figure 9 : Organigramme du projet Rhodia EAI
III. Missions objets du PFE :
Les missions qui m’étaient attribuées au sein de l’équipe Rhodia EAI portent sur trois
volets métiers : Le BPM : Business Process Management, Le BAM : Business Activity
Monitoring et la GED : Gestion Electronique de documents.
III.1. BPM : Modélisation et déploiement de modèles de flux

La modélisation et le déploiement des processus métiers relatifs au flux des documents
commerciaux, à la demande du responsable projet chez Rhodia était la première mission
attribuée au stage.
III.2. BAM: Pilotage de l’activité par la performance

Pour permettre au client et à l’équipe projet de visualiser l’évolution du volume des
transactions et évaluer la performance des services web de près et en temps réel, en prenant en
considération les paramètres pertinents qui interviennent dans le déroulement de l’activité
EAI, le business activity monitoring était la mission principale attribuée au stage vu l’apport
métier important qu’elle apporte à toutes les parties prenantes dans le projet.
Pour la société Rhodia cliente de Logica le pilotage de l’activité par la performance va

lui permettre par la suite de modéliser le coût par transaction et agir sur les facteurs
déterminants à l’aide de ce modèle.
24
III.3. GED : Gestion électronique de documents

Suite à un besoin interne de l’entité projet Rhodia à LOGICA le choix, la mise en
place et la configuration d’un outil open source de gestion électronique de documents, était la
dernière mission confiée.
IV. Conduite du projet :

IV.1. Processus du développement :
Un développement associant performance et qualité induit naturellement une conduite

de projet itérative incrémentielle associée à un phasage simple. À l'origine de ces principes
pragmatiques, la méthode RAD de James Martin1. UML fut plus récemment le révélateur de
cette nécessité méthodologique d'un couplage fort entre la forme de modélisation et le
développement par prototypage. À ce jour, une dizaine de méthodes répondent à ces critères
et se réclament du qualificatif d'Agile.
Voici les quatre principes de base de ces méthodes Agiles :
1 - Les méthodes “ Agiles ” privilégient la communication et l’interaction qui en

résulte à la contractualisation des spécifications : « Personnes et interactions plutôt que
processus et outils ».
2 - Les méthodes “ Agiles ” favorisent la compétence et l’implication des ressources

plutôt que le respect de processus formel et d’une vision “ outillée ” à l’extrême des
développements :
3 - Les méthodes “ Agiles ” privilégient la livraison de fonctionnalités réelles à la

production d’une documentation pléthorique : « Logiciel fonctionnel plutôt que
documentation complète ».
4 - Les méthodes " Agiles " favorisent l’acceptation du changement et la

modification des priorités (Time-Box, Task-Box) plutôt que le respect d’une planification
figée : « Réagir au changement plutôt que suivre un plan »
Toutes les méthodes se situent concrètement à divers degrés sur une échelle les
positionnant de la plus "prédictive" à la plus "adaptative". Si l'on souhaite disposer d'une
vision relativement précise du champ d'application des diverses méthodes actuelles, il est
nécessaire de les répertorier en fonction de ces critères.
25
Figure 10 : Adaptativité / Prédictivité des méthodes
Comme c’est le cas pour l’élaboration de tout projet, j’ai été amené à suivre une
démarche pour la conduite de mon projet. Et pour cela j’ai choisi la méthode SCRUM.
Scrum est une méthode agile pour la gestion de projets. Elle a été conçue pour
améliorer grandement la productivité dans les équipes auparavant paralysées par des
méthodologies plus lourdes. La méthode Scrum a été conçue pour la gestion de projets de
développement de logiciels. Elle peut aussi être utilisée par des équipes de maintenance. La
méthode SCRUM affirme sa différence dans des pratiques de courtes réunions quotidiennes.
Ces temps de travail commun ont pour objectifs d'améliorer la motivation des participants, de
synchroniser les tâches, de débloquer les situations difficiles et d'accroître le partage de la
connaissance.
Le principe de base de Scrum est de focaliser l'équipe de façon itérative sur un

ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une à quatre
semaines, appelées sprints. Chaque sprint possède un but à atteindre, défini par le directeur de
produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce sprint. Un
sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Un principe fort en
Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du
logiciel et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment
compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en
cours de réalisation pendant un sprint.
26
Figure 11 : Décomposition de projet en sprints
Figure 12 : Vue synthétique du processus Scrum
27
IV.2. Planning:
 Diagramme de gant
Figure 13 : Diagramme de gant
28
Chapitre 2
Etude Préliminaire
Une étude approfondie de l’existant m’a

conduis à découvrir un besoin
incontournable dans le projet Rhodia EAI en
BAM et de faire le choix entre deux
scénarios à adopter pour répondre à ce
besoin avec une solution consistante.
29
Etude Préliminaire
Chapitre 2 : Etude Préliminaire
I. Introduction :
Afin de pouvoir dégager les spécifications fonctionnelles générales, il est nécessaire de
bien explorer l’existant, connaitre ses détails, sa problématique et ses enjeux.
Dans le cas de mon projet l’existant est la plate-forme phare d’intégration webmethods
suite, de software AG.
II. Étude de l’existant :

II.2. Présentation de la solution EAI implantée :
 Pourquoi webmethods ?
Rhodia, en plein déploiement de l'ERP de SAP au niveau européen, avait besoin de
relier son back-office à l'ensemble de son écosystème: partenaires, sous-traitants (Logica,
Atos Origin), fournisseurs, transporteurs et clients. Pour mettre alors en œuvre la démarche
EAI elle se tourne vers la plate-forme d'intégration de software AG : Webmethods. «Nous
avons d'abord mené un projet de connexion entre les agents logistiques et les transporteurs,
avec message de confirmation de livraison», raconte Santiago Tolosa. L'application d’e-
logistique dialogue avec un AS400 et les différents protocoles de communications utilisées
par les transporteurs.
Cette première expérience va ouvrir la voie au développement, au dessus du hub de

communication, d'une plateforme Rhodia centralisée, permettant de répondre à tous les
besoins en connectivité des différentes entités du groupe, avec un taux de réutilisation élevé.
«La connectivité n'est devenu plus un problème chez nous, qu'il s'agisse de SOAP, de web
services ou d'autres technologies demandées par le marché. Aujourd'hui, de nombreux grands
projets de connexion avec des clients ou des fournisseurs voient le jour, notamment via la
place de marché de la chimie Elemica dont nous sommes membres. Progressivement, de plus
en plus d'éléments sont intégrés», précise Santiago Tolosa.
Webmethods permets à Rhodia de mettre en place un broker de connectivité

permettant de créer des passerelles vers d'autres réseaux que la place de marché Elemica, et
d'implémenter de nouveaux flux "B2B" : " business to business", avec un délai de quatre à
huit semaines. Deux tiers du temps sont consacrés au mapping, qui mobilise une personne, et
un tiers du temps à la modélisation du processus d'échange, qui peut porter sur des
transactions longue durée: envoi de la commande, réponse associée à la commande,
confirmation de livraison, etc.
30
Etude Préliminaire
 Webmethods au crible :
Avec webMethods, Software AG met l’accent sur l’intégration des systèmes mais
aussi sur l’automatisation et l’amélioration des processus. De plus, cette solution permet de
renforcer la relation avec les partenaires. C’est une plate-forme d'intégration globale capable
de fédérer l'ensemble des îlots applicatifs de l'entreprise (des mainframes aux applications
J2EE) et derrière laquelle s'effacent les distinctions techniques habituelles entre flux A to A
(internes) et B to B. Ces innovations veulent répondre aux besoins stratégiques évoqués par
les entreprises qui souhaitent réduire les délais de mise en application. Grâce à webMethods,
les entreprises peuvent désormais déployer des projets à grande échelle plus rapidement.
Figure 14 : Architecture fonctionnelle
31
Etude Préliminaire
Figure 15 : Architecture des composants métiers
Figure 16 : Architecture de déploiement sur Rhodia EAI
II.2. Besoins incontournables en BAM et limitations:
Après avoir mis en place Webmethods le projet rhodia a réussi d’atteindre les finalités
souhaitées au niveau BPM, mais il éprouve toujours le besoin des fonctions de BAM
(Business activity monitoring), qui permettent de suivre l’activité via des indicateurs
prédéfinis en temps réel. En effet, La version 7.1 de Webmethods, implantée par le groupe
32
Etude Préliminaire
Rhodia, malgré sa puissance et toutes les fonctionnalités qu’elle assure, manque d’un moteur
d’analyse (Analytical Engine) qui permet de définir des indicateurs clé de performances KPIs
et de faire l’analyse de l’activité à partir de l’entrepôt de données relatifs aux différents flux
gérés par Webmethods.
Un travail de recherche bien fondé m’a conduis à savoir que Software AG, leader
mondial des logiciels d’infrastructure métier et propriétaire de webmethods, a prévu ce besoin
et a lancé en décembre 2009 webMethods 8 avec un nouveau produit intitulé Optimize for
B2B (à base de l’Analytical Engine), Les tableaux de bord créés via webMethods Optimize
for B2B permettront aux collaborateurs de visualiser et de comprendre leurs opérations en
temps réel. Cet outil intuitif favorise la prise de décisions basée sur des faits via des
fonctionnalités comme l’analyse des causes premières et la prédiction.
La figure en dessous montre les composants essentiels du nouveau système de

BAM offert par webmethods 8.
Figure 17 : Architecture BAM en WebMethods 8

Pour jouir des fonctionnalités du BAM offertes par le B2B Optimize, ainsi que
d’autres, le groupe Rhodia aura besoin de se procurer la nouvelle version Webmethods 8 et
faire la migration de la version 7.1, ce qui implique des coûts énormes en terme de mise en
place et configuration, de licence et support et de tests.
Dans la phase actuelle la stratégie de financement du projet Rhodia ne permets pas La
migration vers la version 8. Ce fut le cas, l’équipe projet a jugé nécessaire de réaliser un projet
d’extension web de version 7.1 comme solution alternative qui satisfait les besoins en BAM.
Ce qui fait l’objet principal de mon PFE.
 Business Activity Monitoring : pilotage des activités métiers
33
Etude Préliminaire
Le concept BAM, propose une exploitation rationnelle des instruments et équipements

de Business Intelligence afin d'assurer un pilotage des activités et processus "métier" les plus
critiques. Il s'agit notamment de s'approcher du temps réel. Exploitant l'intégration et l'inter-
échange des applications de production intra et inter entreprises, le BAM cherche ainsi à
proposer la meilleure perception de la performance des activités et processus.
Sur le plan technique, le BAM exploite les concepts d'intégration et de communication

des applications, l'EAI et les concepts associés comme SOA notamment et s'intègre dans une
dimension plus globale de BPM. Du point de vue de l'utilisateur, responsable d'activités ou de
processus, la solution BAM se concrétise en tableaux de bord de pilotage composés
d'indicateurs de performance, KPI pour Key Performance Indicators, rafraîchis en "temps
réel".
 Indicateurs clé de performance KPIs :

Pour tirer les meilleurs résultats de l’activité EAI, il faut fixer des objectifs métier et
fournir à l’entreprise les moyens de mesurer sa progression.
Les KPIs sont les «guides » qui synchronisent les objectifs stratégiques avec l’exécution
opérationnelle au quotidien. Pour le service informatique, ils permettent un meilleur
alignement métier, une meilleure affectation des ressources informatiques et une innovation
plus proactive. Les KPIs fournissent des métriques permettant de mesurer les facteurs jugés
essentiels au succès d'une entreprise et à l'accomplissement de ses objectifs métier.
Pour définir des indicateurs clés de performances liées à la prestation des services
métier, il est essentiel de déterminer si l’équipe informatique et les acteurs professionnels
voient cette prestation sous le même angle. Par exemple, on peut risquer de découvrir que
l’équipe informatique mesure la prestation de service à l'aide de métriques opérationnelles
axées sur l'interne, qui privilégient une perspective orientée vers la technologie et les
processus. En revanche, les utilisateurs métier auront vraisemblablement tendance à évaluer la
prestation de service sur la base d'une vision métier globale. Résultat : l’équipe informatique
et les utilisateurs métier voient la qualité de la prestation de service sous un angle différent.
II.3. Solution proposée : Portlet CAF
L’exploration de l’existant durant une semaine, et l’étude des différentes possibilités

permettant de mettre en place une solution qui répond complètement au besoin, m’a conduis -
après avoir écarté le scénario d’accompagner la migration à WebMethods 8 et
l’implémentation du produit « Optimize for B2B »- à décider en collaboration avec les
membres de l’équipe projet de réaliser une application composite, et la déployer sur le portail
de webmethods (My Webmethods) en termes de Webmethods on l’appelle : Portlet
Composite Application Framework (Portlet CAF),
D’une part l’application permettra aux partenaires et à l’équipe projet de bien suivre
l’activité EAI et évaluer la performance des processus métier déployés sur la plate-forme, tout
34
Etude Préliminaire
en bénéficiant de toutes les fonctionnalités offertes par le portail My Webmethods ; et d’autre

part elle va permettre à Rhodia d’estimer ses pertes financière relatives à son activité
commerciale.
L’utilisation des nouvelles technologies de développement et architecture garantira la

pérennité, l’extensibilité et la modularité de la plate-forme.
III. Analyse et spécifications :
III.1. Fonctionnalités visées de l’application BAM
J’ai établi selon les objectifs du projet des fonctionnalités principales qui doivent être
assurées par l’application Composite :
 Communiquer en temps réel aux acteurs les informations de performance sous

forme de métriques développées dans des portlets et présentant les KPIs essentiels.
 Faire le reporting de l’activité.
 Simplifier l’aspect architecture réservé au BAM.
Figure 18 : Architecture fonctionnelle exprimant le besoins
III.2. Définition des KPIs et métriques essentielles :
La définition des indicateurs clés de performances implique généralement la création

d'une hiérarchie des indicateurs. Grâce à l’organisation des indicateurs en sous-catégories
d’indicateurs clés de performance l’équipe projet peut mieux connaître les facteurs qui
35
Etude Préliminaire
affectent les indicateurs généraux, mais aussi les mesures à mettre en œuvre pour influer sur
ces facteurs. Il est donc très utile d'établir les indicateurs clés de performances de façon
progressive, en commençant par définir un seul indicateur métier général sur la base du
résultat qu’on désire obtenir.
 Indicateur général : Volume de transactions :

Le nombre de transactions effectuées sur une période de temps déterminée présente le
KPI de base, c’est un indicateur de volumétrie fournissant des métriques comparatives selon
les requêtes périodiques envoyées par les utilisateurs finaux.
 Temps total d’interruption :

Cet indicateur fournit des métriques comparatives entre les différents flux, par rapport
au temps total d’interruption de chacun.
 Durée des interruptions affectant les services métier

essentiels :
Il s’agit bien d’un indicateur qui mesure la réduction de la durée des interruptions
affectant les services métier essentiels par rapport à une période déterminée. Il permet ainsi
l’évaluation de la vitesse de restauration du service en cas d’interruption.
 Délais de mise en œuvre des correctifs :

C’est un KPI permettant de comparer le temps de réponse à un incident au délai
accordé à la réponse, reflétant ainsi une mesure de respect des délais accordés.
 Le volume de transactions perdues sur une période de temps

déterminée :
Ce KPI volumétrique fournit des métriques présentant le nombre de transactions
perdues sur une période de temps.
 Indicateurs de corrélation :
L’importance des indicateurs de corrélation réside dans le fait qu’ils permettent de
mesurer la corrélation entre différents facteurs qui interviennent dans l’activité, autrement dit
étudier l’intensité de la liaison qui peut exister entre ces facteurs.
 Indicateurs personnalisés :
Une spécification intéressante de point de vu métier consiste à offrir à l’utilisateur
final la possibilité de définir de nouveaux KPIs selon les besoins et les perspectives métier.
36
Etude Préliminaire
III.3. Identification des acteurs et répartition des fonctionnalités :
Acteur Spécifications et fonctionnalités

Consulter tous les KPIs et métriques
Responsables Rhodia prédéfinis.
Extraire le repporting.
Consulter les KPIs et métriques de tous les
partenaires.
Responsables projet Rhodia EAI Extraire les repportings.
Définir de nouveaux KPI.
Administrer l’application.
Tableau 1 : identification des acteurs
IV. Conclusion :
L’étude approfondie du système existant, ainsi que l’analyse des besoins en BAM m’a
permis de concevoir les KPIs et métriques essentiels qui vont permettre par la suite à Rhodia
de modéliser le coût par transaction, et c’est à l’aide de ce modèle qu’elle va pouvoir calculer
ses pertes financières.
Certes la mise en place de la solution Webmethods 7.1 était d’un apport très important
pour Rhodia aussi bien au niveau métier qu’au niveau optimisation de production, cependant
le pilotage de l’activité EAI par la performance s’avère être nécessaire pour veiller à
l’amélioration de la production.
37
Chapitre 3
Modélisation métier et conception détaillée
Ce chapitre présentera l’étude des différents

concepts d’analyse et la modélisation de
quelques exemples de flux.
38
Chapitre 3 : Modélisation métier et conception détaillée de

Préliminaire
I. Cartographies d’exemples de flux de transactions
Elemica est une place de marché neutre et mondiale permettant l’achat et la vente de
produits chimiques. Grâce à la plate-forme Elemica complètement intégrée, acheteurs comme
vendeurs peuvent rationaliser leurs processus commerciaux en matière de vente et optimiser
la gestion des contrats, la livraison des commandes et le règlement. Les transactions
commerciales sont ainsi rapides et efficaces. Rhodia utilise cette place de marché pour
automatiser ses processus de ventes/achats online.
 Elemica PurshaseOrder
La transaction CidxOrderCreateV201facilite pour chaque partenaire la préparation des
ordres pour toutes les filiales de Rhodia à travers Elemica
La même transaction permet à Rhodia d’approuver la procuration de produit avec un

prix, une quantité et une date spécifique suite à une convention entre Rhodia et ses
partenaires.
Processus :
39
Figure 19 : Flux Elemica PurshaseOrder
Description:
 OrderCreate : (CidxOrderCreateV201, ReceiptAcknowledgment

HubOrderCreateV201ForSAP)
Lorsque l’un des partenaires de Rhodia a besoin d’un produit de Rhodia Europe il peut
envoyer son PurshaseOrder via Elemica qui envoie à son tour le document en ChemXML
standard au serveur Webmethods, le document envoyé est un « CidxOrderCreateV201 » son
type et sa version sont le résultat d’une convention établie entre Rhodia, Elemica et les
partenaires.
Ensuite, la zone dématérialisée Webmethods envoie un ReceiptAcknowledgment (RA) (ou
ReceiptAcknowledgment Exception (RAE)) à Elemica tant qu’elle reçoit des commandes à
travers son reverse invokes, juste après le document “CidxOrderCreateV201” est transformé
par le hub en “HubOrderCreateV201ForSAP” qui va être transféré au système SAP RCS à
travers Webmethods SAP adaptor.
 OrderResponse : (HubOrderResponseV201, CidxOrderResponseV201,

ReceiptAcknowlodgement)
40
Lorsque le hub XML reçoit le “HubOrderResponseV201” envoyé du système SAP RCS il le

transforme en “CidxOrderResponseV201” et l’envoie à Elemica qui envoie comme retour un
RA/RAE.
 Elemica Invoice
Rhodia envoie une facture au partenaire pour demander le payement.
Processus :
Figure 20 : Flux Elemica Invoice
41
Description :
Rhodia envoie les factures à ses partenaires à travers le webmethods xml hub utilisant
le document “HubInvoiceV300 invoice".
Le XML hub transforme la facture en «CidxInvoiceV300» et l’envoie à Elemica qui accuse sa
réception par un RA ou RAE.
 Elemica OrderChange
Ce flux concerne une requête envoyée par les partenaires de Rhodia à travers Elemica
pour modifier un ordre qui n’est pas encore délivré.
Processus :
Figure 21 : Flux Elemica OrderChange
42
Description :
Ce flux commence lorsque le partenaire envoie une requete à travers Elemica pour
modifier une commande qui n’est pas encore été délivrée.
Elemica adapte la requête au standard ChemXML en envoyant un CidxOrderChangeV202 au
hub WebMethods qui accuse sa réception par le renvoie d’un « RA » ou « RAE ».
S’il s’agit d’un RA alors l’OrderChange envoyé par Elemica est valide et une alerte SMTP est
envoyée après à une mailing liste particulière.
II. Modélisation des processus métier :
II.2. Exemples de Modèles :
Figure 22 : BuySide Raw Material

Description :
Le « process Engine » est mis en attente d’un « Orders03 », une fois l’ « Orders03 »
reçu le moteur de workflow initialise une instance process, juste après, il fait le routage du
document selon son protocole qui peut être ou bien xml ou bien xCBL35 ou bien ChemXML.
Ensuite le document enchaine sur le sous process adéquat.
43
Figure 23 : BuySide Raw Material SubProcess ChemXML

Description:
La première étape du SubProcess consiste à faire le mapping champ à champ du

document « ORDERS03 » vers un document ChemXML selon des règles de gestion bien
définie, ensuite le process engine envoie le document mappé à Elemica et se met en attente
pendant une période de 3minutes d’un acquittement (ou bien positif : RA ou bien Négatif
RAE).
Tant que la durée d’attente s’écoule le Engine Process Renvoie le document.
Dans le cas d’un acquittement RA le moteur workflow se met en attente d’un

« OrderResponse », une fois reçu il envoie un mail de notification.
44
Figure 24 : Elemica Invoice
Figure 25 : Elemica OrderChange

Autres exemples de modèles et cartographies des flux sont présentés dans l’annexe.
45
III. Conception objet :
III.1. UML :
 Présentation du langage UML

UML est un langage de modélisation objet assurant un certain niveau
d’abstraction mais aussi pertinent de la réalité. Né de la fusion des méthodes
objet dominantes (OMT, Booch et OOSE), puis normalisé par l'OMG en 1997,
UML est rapidement devenu un standard incontournable.
UML n'est pas à l'origine des concepts objet, mais il en donne une définition plus
formelle et apporte la dimension méthodologique qui faisait défaut à l'approche objet. UML
définit maints diagrammes pour donner à l’utilisateur les moyens de visualiser et manipuler
des éléments de modélisation.
 Le choix d’UML
Le choix d’UML, comme outil de modélisation, n’été pas arbitraire, en effet le langage
UML offre une multitude de possibilités telles :
 Une meilleure communication entre les intervenants dans un projet : il offre des
moyens de capture des connaissances sur un sujet à travers divers points de vue (ces
points de vue sont fournis par ses différents diagrammes).
 A l'heure actuelle la notation UML s'impose comme un standard de fait sur le marché.
Il est adopté par les grands constructeurs de logiciel du marché.
 Une bonne compréhension du problème : le système à étudier sera traité suivant
différents angles et suivant les différents cas d’utilisation de ce système.
 MagicDraw UML :
MagicDraw est un outil graphique de modélisation UML disposant de fonctions de
travail collaboratif. Conçu pour les Consultants Métier, les analystes développeurs, les
développeurs, les ingénieurs qualité, et les rédacteurs de documentation, cet outil de
développement dynamique et polyvalent facilite l'analyse et la conception de systèmes
orientés objets(OO) et de bases de données.
Il fournit le meilleurs mécanisme d’engineering de code de l’industrie (avec un reverse

complet pour les environnements J2EE, C#, C++, CORBA IDL, .NET, XML Schéma,
WSDL) ainsi que le modèle de base de données, la génération de DDL.
MagicDraw fonctionne sur un grand nombre de systèmes d'exploitation, tels que

Windows 98/ME/NT/2000/XP/Vista, Solaris, OS/2, Linux, HP-UX, AIX, MacOS (X), et
n'importe quel système d'exploitation supportant Java 1.4, 5 ou 6.
46
III.2. Modélisation fonctionnelle, Cas d’utilisation :
 BPM :
Figure 26 : Diagramme d’utilisation : Business Process Management
47
 BAM :
Figure 27 : Diagramme d’utilisation: Business Activity Monitoring
III.3. Description des cas d’utilisation :
 BPM :
Description du cas d’utilisation Envoyer document persisté :
Sommaire d’identification :
Titre : Envoyer document persisté
Résumé : Ce cas d’utilisation permet l’envoie des documents commerciaux (commandes,

factures, notes de frais …) après les avoir persisté.
Acteur : L’EAI Webmethods.
Date de création : 10/06/2010 Date de mise à jour : 10/10/2010
Version : 1.0 Responsable : Alami Jamal
Description des scénarios:
48
Pré conditions :
1. La connexion avec le système est opérationnelle.

2. Réception d’un document (commande, facture, notes de frais …) de la part d’un
partenaire.
Scénario nominal :
1. L’EAI Webmethods reçoit un document parvenant d’un partenaire.

2. L’EAI WM vérifie la validité du document.
3. L’EAI WM valide le document.
4. L’EAI WM accuse la réception du document en renvoyant un acquittement RA
à l’expéditeur.
5. L’EAI WM persiste le document.
6. L’EAI WM envoie le document persisté à la destination appropriée.
7. Le destinataire accuse la réception du document en envoyant un acquittement.
Enchainement alternatif :
A1 : le document envoyé par l’expéditeur est invalide :
L’enchainement A1 démarre au point 3 du scénario nominal.
4. L’EAI WM indique que le document envoyé est non valide et renvoie un

acquittement de type RAE.
Le scénario nominal reprend du point 1.
A2 : L’expéditeur ne reçoit pas l’acquittement :
5. L’expéditeur envoie un mail au responsable Rhodia EAI signalant une

alerte d’anomalie dans le flux.
6. Le responsable de Rhodia EAI établit les correctifs nécessaires.
A3 :L’EAI WM ne reçoit pas l’acquittement :
8. Le responsable de Rhodia EAI établit les correctifs nécessaires.
49
 BAM :
Description du cas d’utilisation Consulter métriques :
Sommaire d’identification :
Titre : Consulter métriques
Résumé : Ce cas d’utilisation permet la consultation de métriques relatives aux KPIs.
Acteur : Responsable Rhodia.
Date de création : 10/06/2010 Date de mise à jour : 10/10/2010
Version : 1.0 Responsable : Alami Jamal
Description des scénarios:
Pré conditions :
La connexion avec le système est opérationnelle.
Scénario nominal :
1. Le responsable Rhodia s’authentifie sur le portail My webmethods.

2. Le responsable Rhodia ouvre les portelettes réservés aux différents KPIs prédefinis.
3. Le responsable Rhodia génère et consulte les métriques.
4. Le responsable Rhodia génère un rapport et le sauvegarde.
Enchainements d’erreur :
A1 : login ou mot de passe erroné
 Le portail renvoie une exception d’authentification.

 Le portail demande au responsable de ressaisir le login et mot de passe de
nouveau.
A2 : métriques non générés
 Le portail renvoie une exception.

 Le responsable Rhodia envoie un mail d’alerte au responsable Rhodia EAI
 Le responsable Rhodia EAI établit les correctifs nécessaires.
50
 Le responsable Rhodia EAI renvoie un mail de confirmation au responsable

Rhodia.
III.4. Modélisation statique, Diagrammes de classes :
 Diagramme complet :
Figure 28 : Diagramme de classe: Ebusiness
51
 Paquetage données permanentes :
Figure 29 : Diagramme de classe: Paquetage données permanents.
52
 Paquetage flux et transactions :
Figure 30 : Diagramme de classe: Paquetage flux et transactions.
 Paquetage Incidents :
Figure 31 : Diagramme de classe: Paquetage Incidents.
53
 Paquetage Documents Commerciaux :
Figure 32 : Diagramme de classe: Documents Commerciaux.
54
Chapitre 4
Etude Technique
Dans la première section de ce chapitre je

présente l’architecture composants de
WebMethods ainsi que les spécifications de
développement des portlets CAF et leur
déploiement sur le portail My WebMethods.
Ensuite je présente les technologies
exploitées et l’environnement de
développement.
55
Etude Technique
Chapitre 4 : Etude Technique
I. Introduction :
La solution choisie étant une application web composite (CAF) qui s’intègre à
Webmethods et se déploie sur le portail web My Webmethods. Elle est construite d’un
ensemble de portlets, qui doivent être conforment aux spécifications de Webmethods. D’où la
nécessité d’une étude technique bien approfondie pour repérer les approches techniques et les
architectures à adopter.
II. La plate forme Webmethods :

II.1. Architecture générale et composants essentiels :
My WebMethods
WM Designer
Portal
Database for
MWS Integration server
Database
Integration Server
MWS Server WM Developer
Figure 33 : Architecture composants essentiels
II.2. Le portail :
Un portail est une application web qui permet de faire du groupement de contenus.
Concrètement cela consiste à afficher du contenu provenant de différentes sources au sein
d’une seule page il affiche des portlets en les disposant selon des règles définies. Il permet
généralement de choisir différents styles de présentation (couleur, police, agencement des
outils). En fonction du rôle de l’utilisateur (administrateur, invité, utilisateur standard), Le
contenu et la présentation du portail peuvent varier.
56
Etude Technique
Chaque utilisateur peut personnaliser son portail selon ses goûts, il peut sélectionner
les portlets à afficher, les réorganiser, les redimensionner.
Un portail fournit également un ensemble de fonctionnalités communes à tous les

portlets, telles que des décorations avec des fonctionnalités d’aide, de configuration, de
changement de taille.
Un portail peut aussi proposer un système de single signe on (SSO) pour permettre à
l’utilisateur de ne s’authentifier qu’une seule fois pour utiliser tout l’ensemble des
applications disponibles.
II.3. Le portlet :
Un portlet est un composant web unitaire qui est affiché dans un portail, il gère un
contenu (html, xhtml,…) qui est appelé « fragment de balisage ». L’ensemble des contenus
crées par les portlets d’un portail est agrégé pour ne former plus qu’une seule page web
classique.
Un fragment pouvant être disposé n’importe où dans une page d’un portail doit
respecter certaines règles. C’est le portail qui génère le squelette de la page. Il va demander
aux portlets leur code source pour l’insérer au sein de la page.
L’interaction au sein d’un portlet suit le système standard de requête/réponse des

pages web. Lors d’une action du client sur un portlet, le portail va transmettre la requette à un
conteneur de portlets qui gère le cycle de vie d’un portlet.
II.4. Le conteneur de portlet :
Un conteneur de portlets est responsable de fournir un environnement d’exécution aux

portlets. Le conteneur de portlets est aux portlets ce que le conteneur de servlets est aux
servlets.
II.5. Les Concepts du Composite Application Framework sur

Webmethods.
WebMethods CAF permet de créer des applications web pour l’utilisation avec les
serveurs d’application et des applications portlets pour l’utilisation avec les serveurs de portail
My WebMethods. Une application web est composée d’un ou plusieurs vues destinées à être
afficher par un serveur d’application comme Apache Tomcat ou JBoss. Une application
57
Etude Technique
Portlet est composée d’un ou plusieurs portlets qui comportes une ou plusieurs vues destinées
à être afficher dans le portail My WebMethods.
 Applications portlets :
Une application portlet est un conteneur de plusieurs portlets. Une application portlet
est publiée sur un serveur sous forme d’un fichier WAR (Web Archive). Un fichier WAR
construit une application web en java incluant des servlets java, des JSPs, et d’autres
ressources.
 JSR168 :
Un portlet est une mini-application qui se déploie sur le serveur de portail My
WebMethods. Les portlets créés dans webMethods CAF sont compatibles avec Java
Specification Request (JSR) 168. Cette spécification permet l’interopérabilité entre portlets et
portails, définissant ainsi plusieurs APIs pour les portlets et standardisant les préférences, les
informations des utilisateurs, les requêtes et réponses des portlets, le déploiement des
packages et la sécurité.
Les portlets JSR 186 sont dépourvus d’états. JSR 168 utilise les préférences pour leurs
en apporter. Ces préférences sont ou bien des String ou bien des tableux de Strings qui sont
persistés pour le type de portlet pour chaque utilisateur.
Software AG ajoute des extensions aux préférences en ajoutant des types de données
simples comme les booleans et les entiers, et en ajoutant de nouvelles portées. Les portées
étendues sont valides seulement sur le serveur de portail My webMethods.
 Java Server Faces :

Les portlets créés dans webMethods CAF utilisent la technologie JavaServer Faces
(JSF). JSF est une application Framework destinée à la création des interfaces web. JSF offre
aux applications web une gestion du cycle de vie à travers un servlet contrôleur et un modèle
riche de composants et de manipulations des événements. Les composants JSF UI sont
configurables.
Les portlets WebMethods CAF sont composés de vues. Une vue est une page JSF qui
se compose de composants UI.
A chaque portlet dans une application portlet est associé un managed bean. Le
managed bean est un java bean c’est une classe JAVA avec certaines propriétés. Un managed
bean comporte les métadonnées qui définissent son nom unique avec une application portlet,
le type de bean et la portée (scope). La portée détermine le cycle de vie du bean dans
l’application.
58
Etude Technique
Les portées suivantes sont disponibles pour gérer le cycle de vie d’un JSF managed
bean :
Scope Description
Application Partagé par tous les portlets dans une
application portlet. Le managed bean est créé
une seule fois et n’expire jusqu’à l’arrêt du
serveur ou le redéploiement de l’application
portlet sur le serveur.
Session Réservée par session d’utilisateur. Les
données ne peuvent être partagées entre
portlets. Le managed bean expire lorsque la
session de l’utilisateur se termine.
Request Reservée pour une seule requête. Le
managed bean expire juste avant la requête
suivante.
None Le bean est créé une fois appelé.
Tableau 2: Portées de gestion de cycle de vie d’un JSF managed bean
III. Les technologies exploitées :

III.1. Frameworks Java/Jee :
 La plate forme JEE :

La plateforme Java Entreprise Edition 5 est un ensemble de technologies coordonnées
qui permettent de réduire d’une manière très significative le coût et la complexité du
développement, du déploiement et de la gestion des applications multi-tiers et celles dédiées
aux serveurs.
Construite à la base de la plateforme Java Standard Edition (Java SE), Java EE ajoute
des fonctionnalités permettant d’avoir une plateforme Java complète, stable, sécurisée et
rapide. Elle focalise sur la facilitation du développement tout en gardant la richesse de la
plateforme J2EE 1.4. En offrant de nouvelles caractéristiques et d’autres mises à jour comme
la technologie Entreprise JavaBeans(EJB), la technologie JavaServer Faces(JSF) et les
derniers APIs des web services, Java EE5 rend le développement plus simple en maintenant la
richesse qui a rendu de Java EE la plateforme leader pour les web services et pour le
développement des applications pour les entreprises.
 L’API Portlet et principaux éléments de la spécification des

portlets java tels que définis par la JSR168 :
59
Etude Technique
La spécification des portlets java (JSR168) a été rédigée par un ensemble de

fournisseurs de portails qui comprend tous les principaux acteurs du marché. L’objectif de
cette spécification vise à permettre une interopérabilité entre des portlets et des portails de
vendeurs différents.
 Le cycle de vie d’un portlet :

Ce cycle est très proche du servlet. Un portlet est une classe qui doit implémenter
l’interface javax.portlet.portlet et qui doit fournir quatre méthodes pour pouvoir être géré
correctement par le conteneur : init(PortletConfig config), processAction(ActionRequest
request, ActionResponse response), render(RenderRequest request, RenderResponse
response), destroy().
 Le mode et l’état du portlet :

Ces deux informations permettent au portail d’afficher le portail de différentes
manières. Trois modes standards doivent être supportés par un portail pour être compatible
avec la spécification :
View (Vue): Ce mode est le mode standard d’affichage d’un portlet.
Help (aide): Ce mode permet d’afficher une aide sur le portlet.
Edit (modification): Ce mode permet de configurer le portlet.
Il existe trois états de fenêtrage : normal, minimisé et maximisé et il est possible d’en
définir d’autres, la façon exacte de représenter un portlet dans un état ou un autre et la
manière de changer d’état ou de mode est propre à chaque portail.
Le mode et l’état de fenêtrage sont accessibles de manière programmée dans toutes les
phases du cycle de traitement des requêtes du portlet.
 Sauvegarde des préférences de l’utilisateur :

La spécification définit les outils nécessaires pour sauvegarder des préférences de
l’utilisateur. L’objet PortletPreference met à disposition les méthodes getValue, setValue
pour lire et mettre à jour les préférences. Elles sont stockées en utilisant un système de « clé-
valeur » déjà très répandu dans la spécification des servlets. Les valeurs des préférences sont
soit des chaines de caractères (String) soit des tableaux de chaines (String []). La méthode
store () persiste ces valeurs de manière définitive. Le portail est responsable de sauvegarder
ces valeurs (dans une BD).
 Gestion de la session :
60
Etude Technique
Au même titre que l’objet HttpSession utilisé par les servlets, PortletSession permet au
portlet de stocker des objets pour la durée de la session du client. Ces informations sont
perdues lorsque l’utilisateur quitte le portail. Deux portées (scope) sont définies par cet objet :
PORTLET_SESSION : portée privée limitée au portlet et à l’utilisateur
APPLICATION_SESSION : portée qui s’étend à toute application pour cet utilisateur.

Les attributs rattachés à cette portée sont visible pour tous les composants de l’application,
cela inclut notamment les servlets, les jsp et d’autres portlets.
 Le contexte du portlet :
Le PortletContext est une présentation de l’environnement d’exécution du portlet. Le
portlet peut lire des propriétés, accéder à des ressources, obtenir des informations sur l’API,
écrire dans un log, stocker des informations en utilisant ce contexte.
 Association d’un portlet avec des Servlets/JSP :

L’inclusion de servlets ou de jsp est possible dans les portlets. Cela permet de mettre
en place une structuration respectant le patern MVC (Modèle-Vue-Controleur) et évite de
devoir générer du code HTML directement dans le portlet. On utilise ainsi le portlet
uniquement comme un contrôleur.
Une fois le traitement du portlet terminé, il peut demander un objet de type

PortletRequestDispatcher à son contexte pour un chemin qui référence la JSP. Il transmet
ensuite la requête et la réponse de rendu à ce dispatcher.
Une bibliothèque de tag est aussi définie par la spécification. Elle propose des tags
pour construire des URL qui permettent au portlets de se référencer lui-même.
 Le packaging et le déploiement de portlets :

La spécification des portlets pour java permet de packager des portlets comme une
application web JEE standard sous forme d’un fichier war.
Le fichier doit contenir un fichier web.xml définissant l’application dans un répertoire

WEB-INF. Il doit en plus posséder un fichier portlet.xml qui décrit le/les portlet (s) contenus
dans l’application.
 L’intégration des portlets avec des technologies tierces :

Les applications d’entreprise développées en java s’appuient très souvent sur des
librairies ou des frameworks tiers, parmi lesquels on trouve notamment JSF. L’adoption des
portlets va être très dépendante des possibilités d’interopérabilité avec ces types de
frameworks.
61
Etude Technique
La solution proposée pour intégrer ces technologies dans le monde des portlets
consiste à utiliser des composants appelés ponts. Plusieurs de ces ponts sont développés par
un groupe de la fondation Apache. Il en existe des compatibles avec les portails JSR-168 pour
plusieurs technologies telles que JSF.
 L’API Jfreechart :
JFreeChart est une API Java permettant de créer des graphiques et des diagrammes de
très bonne qualité. Cette API est open source et sous licence LGPL. En revanche, la
documentation est payante.
JFreeChart est dans le monde Java, l'outil de génération de graphiques le plus connu et
le plus réputé, pour diverses raisons :
 D'abord, en tant que librairie Open-Source, JFreeChart bénéficie d'un avantage

important face à ces concurrents : sa gratuité. Mais ce n'est pas son seul avantage, car
lors du téléchargement, on reçoit également les codes sources du produit.
 Ensuite, JFreeChart est un outil facile à utiliser et à intégrer dans une application,
qu'elle soit installable, ou utilisée depuis un navigateur web.
 L’intégration des charts dans les applications web :

L’implémentation des éléments jfreeChart dans les projets web se réalise via
l’exportation des objets jfreeChart en image PNG, JPG ou GIF, et la récupération des images
par la suite dans des les pages jsp via des tags jsf par exemple dans le cas d’utilisation du
Framework JSF.
 Le Framework JSF, JSF-portlet :

Java Server Faces est un framework de développement d’applications Web en Java
permettant de respecter le modèle d’architecture MVC et basé sur des composants côté
présentation.
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-Controller) est

une architecture et une méthode de conception qui organise l'interface Homme-machine
(IHM) d'une application logicielle. Il divise l'IHM en un modèle (modèle de données), une
vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des
évènements, synchronisation), chacun ayant un rôle précis dans l'interface.
Java Server Faces permet :
 une séparation de la couche présentation des autres couches (MVC)

 un mapping entre l’HTML et l’objet
 un ensemble de composants riches et réutilisables
62
Etude Technique
 une liaison simple entre les actions côté client de l’utilisateur (event listener) et le
code Java côté serveur
 Création de nouveaux composants graphiques
 JSF peut être utilisé pour générer autre chose que du HTML (XUL, XML, WML.)
 Possibilité de créer de nouveaux composants
 JSF permet de combiner plusieurs composants pour aboutir à un composant plus
complexe.
 Supporte différentes technologies d’affichage.
 JSF ne se limite pas à l’HTML (XUL, Flash, …)
 Accès aux Beans par leurs noms en utilisant les Expressions Language.
 Simplification des définitions des contrôleurs et des Beans.
 Simplification du fichier de configuration.
 L’orientation composants graphiques permet à JSF d’être utilisé de manière plus
simple dans les environnements de développement.
Les rédacteurs de la jsr168 et les experts jsf ont collaboré ensemble pour nous
permettre d’utiliser JSF non seulement dans des servlets mais aussi dans les portlets.
Les experts JSF ont introduis le concept d’un External Context qui permet
l’embarquement de jsf dans plusieurs technologies comme les portlets.
Le External Context donne l’accès à tous les composants définis par le portlet runtime
avec qui l’application web jsf est déployée. Cette classe doit être implémenter avec la classe
FacesContext et doit être accessible via la méthode getExternalContext() dans FacesContext.
La spécification jsf distribue seulement un controleur servlet d’où la nécessité

d’ajouter un controleur portlet aux deux contextes.
Heureusement, on n’aura pas à faire toutes ces implémentations, nous même. Le

portlet FacesPortlet implémenté par MyFaces s’occupe de la manipulation du External
Context.
 Enterprise Java Beans :

La technologie Enterprise JavaBeans (EJB) est une architecture de composants
logiciels côté serveur pour la plateforme de développement J2EE.
Cette architecture propose un cadre pour créer des composants distribués (c'est-à-dire
déployé sur des serveurs distants) écrit en langage de programmation Java hébergés au sein
d'un serveur applicatif permettant de représenter des données (EJB dit entité), de proposer des
services avec ou sans conservation d'état entre les appels (EJB session), ou encore d'accomplir
des taches de manière asynchrone (EJB dit message).
Tous les EJB peuvent évoluer dans un contexte transactionnel.
63
Etude Technique
C'est le serveur applicatif qui a en charge la création, la destruction, la passivation ou

l'activation de ses composants en fonction des besoins. Le client via un appel RMI (ou une de
ses dérivées) va rechercher un EJB par son nom logique JNDI et appeler une/des méthodes de
cet objet.
Les spécifications EJB 3 interviennent dans un contexte bien précis. En effet, la

spécification 3 des EJB a tout d’abord été élaborée en vue de simplifier la conception d’EJB
du côté développeur.
Ainsi parmi les points forts de la nouvelle spécification des EJB on distingue :
 Simplification de la définition des interfaces (plus besoin d’hériter d’une super

interface ou classe).
 Simplification des API pour l’accès à l’environnement du Bean : définition par simple
injection dépendante.
 Introduction de l’utilisation des annotations en Java qui sont utilisées à la place du
descripteur de déploiement.
 Simplification concernant la persistance d’objet par la définition par l’utilisation
facilité de mapping objet/relationnel basée sur l’utilisation direct de classes Java et
non de composants persistants.
 Ajax :
AJAX (Asynchronous JavaScript and XML) n'est pas une technologie en soi, mais un
terme désignant une « nouvelle » approche utilisant un ensemble de technologies existantes,
dont : HTML ou XHTML, les feuilles de styles CSS, JavaScript, le modèle objet de document
(DOM), XML, XSLT, et l'objet XMLHttpRequest. Lorsque ces technologies sont combinées
dans le modèle AJAX, les applications Web sont capables de réaliser des mises à jour rapides
et incrémentielles de l'interface utilisateur sans devoir recharger la page entière du navigateur.
Les applications fonctionnent plus rapidement et sont plus réactives aux actions de
l'utilisateur.
Plusieurs controles disponibles sur la palette de vues de webMethods CAF utilisent les
principles d’AJAX, pour permettre l’incorporation d’AJAX dans les applications portlets.
 Services web, Axis :

 Service :
Un « service », au sens de la SOA, est une connexion à une application, offrant l’accès
à certaines de ses fonctionnalités. Les fonctions proposées par un service peuvent être des
traitements, des recherches d’informations, etc. Par exemple, une application de gestion de
clientèle peut par exemple offrir un service retournant les coordonnées (adresse, tél, …) d’un
client.
64
Etude Technique
Un Service encapsule une fonction réutilisable, il est défini explicitement par des
interfaces indépendantes de l’implantation et invoqué à travers des protocoles de
communication qui prônent la transparence de la location et l’interopérabilité.
 Service web :
Les WebServices sont de bons candidats à la représentation technique des services de
l’entreprise. Basés sur SOAP, ils correspondent également à la notion de services métiers
auxquels fait référence la SOA, et sont également standardisés.
L’autre atout des services web est qu’ils s’accompagnent d’une multitude de standards
répondant aux exigences de sécurité, de transactions, d’authentification, etc. Ces normes,
rassemblées sous l’appellation générique WS-*, ne sont toutefois pas toutes adoptées
définitivement, certaines problématiques donnant parfois lieu à l’émergence de plusieurs
normes concurrentes (comme WS-Reliability et WS-Reliable Messaging, pour standardiser le
protocole fiable d’échange de messages, par exemple).
 Axis :
Axis est un projet de Apache Software Foundation. C'est un package Java libre qui
fournit :
 un environnement pouvant soit, fonctionner comme un serveur SOAP/Rest

indépendant soit comme un plug-in de moteurs de servlet (en particulier Tomcat).
 une API pour développer des services web SOAP RPC ou à base de messages
SOAP.
 le support de différentes couches de transport : HTTP, FTP, SMTP, POP et IMAP.
 la sérialisation/désérialisation automatique d'objets Java dans des messages SOAP.
 des outils pour créer automatiquement les WSDL correspondant à des classes Java
ou inversement pour créer les classes Java sur la base d'un WSDL (classe proxy en
quelque sorte, qui fait le lien entre l'application Java cliente et le service distant).
 des outils pour déployer, tester et monitorer des web-services.
III.2. Oracle :
Oracle est un SGBD relationnel. Sa fonction première est de gérer d'une façon intégrée
l'ensemble de données d'une entreprise et de les rendre accessibles à un nombre important
d'utilisateurs et d'applications tout en garantissant leur sécurité, leur cohérence et leur
intégrité. Oracle dispose d'un langage permettant la définition et la manipulation des données:
le langage SQL (Structured Query Language), qui est le langage normalisé dans le domaine
des bases de données relationnelles. SQL*PLUS est l'interface utilisateur d'Oracle qui permet
d'utiliser interactivement le langage SQL sur une instance Oracle.
65
Etude Technique
IV. Outils et environnements de développement :
IV.1. WebMethods Designer.
Editeur de développement JAVA il est spécifique à Webmethods assez puissant et

complet construit à base d’Eclipse.
Il fournit tous les plugins nécessaires :
 A la conception, les tests et le déploiement des workflows.

 Au développement des Applications Web Composites.
 Au développement des Applications portlets déployées sur le serveur de portail
My webMethods et exploitées sur My webMethods.
 Au développement des services web, Déployés sur le serveur d’intégration.
Figure 34 : Perspective Business Analyste : WebMethods Designer
66
Etude Technique
IV.2. Webmethods Developer.
Avec sa perspective basée sur un environnement de développement graphique intuitif

et son adoption du « flow languge » spécifique à WebMethods, l’outil WebMethods
Developer permet de :
 Composer et orchestrer les services pour intégrer les applications.

 Supporter des formats complexes de documents.
 Faire le mapping des données.
 Un debugging assez fort.
 Développer des services en JAVA, C, C++et COM.
 Créer des services à partir d’applications JEE et .Net.
Et fournit :
 Des librairies de « built-in » services

 Des éditeurs de composants spécialisés tels que :
 Les documents de Broker
 Les Adapter services
 Les Adapter notifications
 Les Web service connectors
 Les Document schemas
…
Figure 35 : WebMethods Developer
67
Etude Technique
IV.3. Conclusion :
L’étude technique de WebMethods et les spécifications relatives au développement

des Portlets CAF a impliqué l’apprentissage de plusieurs technologies et frameworks Java
ainsi que plusieurs concepts et aspects architecturaux pouvant contribuer à la mise en œuvre
de mon application composite.
68
Chapitre 5
Mise en œuvre
Après l’analyse des spécifications et

l’établissement d’une étude technique bien
détaillée, vient la phase de la réalisation.
Dans ce chapitre je tiens à décrire les
différents aspects architecturaux de mon
application ainsi que la démarche de
développement menée, et je finie par
présenter et décrire quelques éléments IHM.
69
Mise en œuvre
Chapitre 5 : Mise en œuvre
I. Introduction :
L’application Composite est développée à base de JAVA/JEE au profil de Rhodia EAI

et met en œuvre le fameux patern MVC 2. En respectant les spécifications de développement
des applications Portlets CAF sur webMethods.
II. Modèle Vue Contrôleur 2:
Le Modèle Vue Contrôleur, en anglais Model-View-Controller (MVC), est un modèle

de conception logicielle dont le principe est de séparer les données, les traitements et la
présentation. Ainsi l’application se retrouve décomposée en trois couches essentielles :
 Le modèle : il représente les données et les règles métiers. C’est dans ce

composant que s’effectuent les traitements liés au coeur du métier. Les
données peuvent être liées à une base de données, des EJBs, des services
Web…
 La vue : correspond à l’IHM. Elle présente les données et interagit avec
l’utilisateur.
 Le contrôleur : quant à lui, se charge d’intercepter les requêtes de l’utilisateur,
d’appeler le modèle puis de rediriger vers la vue adéquate. Il ne doit faire
aucun traitement. Il ne fait que de l’interception et de la redirection.
L’intérêt majeur de cette décomposition est de faciliter la modularité, la flexibilité et la

réutilisation des composants programmés. Elle permet aussi d’associer plusieurs vues
distinctes à un même modèle. En plus, un changement au niveau de l’implémentation d’un
modèle (optimisation, réorganisation, ...) n’impliquerait pas forcément des changements au
niveau des vues et des contrôleurs.
Le MVC, bien que très pratique, peut se révéler lourd à mettre en place. Ceci à cause
de la multitude de contrôleurs à implémenter. Afin de simplifier la réalisation d’un tel modèle,
une nouvelle version a été introduite : le MVC2.
C’est exactement le même modèle de conception à la différence qu’il n’y a plus qu’un
seul contrôleur qui se charge de rediriger la requête vers le bon traitement.
La figure suivante représente l’architecture MVC 2 :
70
Mise en œuvre
Figure 36 : Modèle Vue Contrôleur 2
III. Architecture générale de l’application Composite:
Figure 37 : Architecture générale.
71
Mise en œuvre
IV. Architecture logique de l’application composite:
Présentation: JSF Views
Processus: Process Engine
Fonction: Classes services EJB
Persistence: Serveur d'intégration
Entrepôt de données: Bases de données
Figure 38 : Architecture logique de l’application Portlet CAF
• La couche Présentation: Mise en œuvre du dialogue avec l’utilisateur : Interfaces

utilisateurs qui sont des vues jsf déployées dans les portlets.
• La couche Processus: Support de processus métiers complets (rôle d’orchestration);

ce composant fait appel surtout au couches Fonction et Entité pour répondre aux besoins de
BPM.
• La couche Fonction: Classes de services et beans. Adaptations fonctionnelles ou

traitements localisés relatifs aux définitions de KPIs et les générations de métriques associés.
• La couche Persistance : Service d’accès aux données persistantes, aux bases de

données et référentiels.
• La couche Entrepôt de données : La couche du stockage de données dans les bases de

données supportées.
72
Mise en œuvre
V. Architecture de déploiement :
Portail My WebMethods
Base de Base de
données données
Pour JSF Portlets du serveur
MWS d’intégration
WS WS WS WS Base de
Serveur de portail
données
My WebMethods WS WS BAM
Serveur
d’intégration
Servlets, JSPs,
JAVA Beans. WS WS
Moteur
Workflow
WS WS WS WS
WM Designer WM Developer
Figure 39: Architecture de déploiement
VI. Démarche de développement :
Dans le développement de l’application composite j’ai procédé par phases (Srints)

validées par des tests afin de mieux cerner les objectifs et organiser mon travail en restant
fidèle à la méthode adoptée Scrum:
73
Mise en œuvre
VI.1. Premier Sprint: Portlets présentant des données statiques :
Pour être productif et aboutir rapidement à des résultats satisfaisants j’ai commencé
d’abord par développer des portlets déployant des métriques de KPIs des données statiques -
les KPIs étant définis-, Cette phase m’a permis de maitriser le développement des Portlet
CAF, et de me familiariser avec les outils de développement en l’occurrence l’outil
WebMethods Designer.
Figure 40: Diagramme du Reste à faire en heures du premier Sprint
VI.2. Deuxième Sprint : Services récupérant des données du

serveur d’intégration :
Après avoir déployé les portlets et mètriques sur le portail webMethods. J’ai enchainé
par l’apprentissage et le développement des services web permettant de récupérer des données
toujours statiques du serveur d’intégration et le déploiement des données récupérés en charts
selon les KPIs définis dans les classes métiers Java Beans. Cette phase m’a permis de
maitriser le language de flow de webMethods et le développement de services.
74
Mise en œuvre
Figure 41: Diagramme du Reste à faire en heures du deuxième Sprint
Figure 42 : Premier Portlet Test
75
Mise en œuvre
VI.3. Troisième Sprint : Création d’une base de données

intermédiaire réservée au BAM.
Après avoir validé les tests de générations de portlets métriques et l’apprentissage du

développement des services nécessaires vient la phase d’interaction avec l’entrepôt de
données. J’ai jugé alors important de créer une base de données intermédiaire réservée à
l’activité du BAM, la finalité étant de :
 Avoir une base de données distribuée.

 Sécuriser les données en évitant l’accès aux données sources.
 Réduire la haute fréquence des requêtes interrogeant la base de données racine.
L’alimentation de la base de données et la fréquence d’actualisation de données se

paramètrent via des web services disponibles dans les packages built-in services offerts par
WebMethods.
Pour La récupération de données destinées au déploiement sur les portlets métriques

j’étais amené à développer des flow services sur l’outil WebMethods Developer exploitant
ainsi les services disponibles sur les packages « built-in srvices ».
Figure 43: Diagramme du Reste à faire en heures du troisième Sprint
76
Mise en œuvre
VII. Eléments de la réalisation :

 Authentification :
Figure 44 : Interface d’authentification
 Accueil :
Figure 45 : Interface d’accueil
 KPIs et métriques:
 Volume de transactions :
77
Mise en œuvre
Figure 46 : JSF View : Volume de transactions
Description :
Cette vue JSF permet de consulter les métriques relatives aux transactions des
différents flux elle donne ainsi un aperçu global sur l’évolution des transactions commerciales
de Rhodia depuis 2008.
78
Mise en œuvre
 Volume de transactions perdues par flux:
Figure 47 : JSF View : Volume de transactions par flux

Description :
Cette vue JSF permet de consulter les métriques relatives aux transactions par flux.
Une liste déroulante récupérant les différent flux déployés sur le « Engine Process »
permet d’ajouter les flux dont l’utilisateur souhaite consulter les métriques comparatives.
Le bouton « Refresh Chart » permet de rafraichir les données présentées en métriques

et donc rafraichir les métriques correspondantes.
Le champ de texte en dessous permets l’ajout de commentaires qui vont être exporté
par la suite à un Rapport sous forme d’un fichier PDF.
79
Mise en œuvre
Le bouton « Generate PDF Repport » génère le rapport comportant les tableaux de

données les charts et les commentaires saisis.
 Répartition des flux :
Figure 48 : JSF View : Répartition des flux selon la requête temporelle
Description :
Cette vue JSF permet de consulter des « Pies Charts » présentant la répartition des flux
selon une requête temporelle envoyée par l’utilisateur.
Le formulaire en haut permet de préciser l’intervalle de temps durant lequel

l’utilisateur souhaite connaitre les flux prédominants.
80
Mise en œuvre
VIII. Conclusion :
Les technologies et frameworks Java, la modularité et l’extensibilité de la plate-forme

WebMethods, les outils intégrés de développement sur WM, ainsi que la démarche de
développement agile Scrum ont contribué de manière très importante à la réalisation de mon
premier Portlet CAF sur WebMethods.
81
Conclusion générale et perspectives
Conclusion générale et perspectives:
Mon projet de fin d’études s’est effectué dans les meilleures conditions, le soutien de
mes collègues, les informations précieuses qu’ils m’ont généreusement fournies et la
documentation qu’ils ont mise à ma disposition ont facilité mon intégration dans l’équipe du
projet et m’ont aidé à contribuer à la réalisation de ce travail ayant pour objet la mise en place
d’une solution de Business Activity Monitoring.
Mon projet a été découpé en trois phases principales : une première phase
d’apprentissage a été dédiée au développement des portlets tests, à la conception des KPIs
nécessaires et à la montée en compétence dans les différentes technologies. Dans Une
deuxième phase j’ai attaqué le développement des services nécessaires et la modélisation de
quelques exemples de flux. Finalement la troisième phase je l’ai consacré à la conception
fonctionnelle et statique UML de l’activité, pour créer par la suite une base de données
intermédiaire et implanter ma solution finale de BAM.
Au terme de ce stage, j’ai abouti à satisfaire une grande partie des objectifs
fonctionnels et techniques attendus. Ainsi, j’ai mis en place une solution bâtie sur une
panoplie d’outils et structurée en une architecture Web 3-tiers à base de la plateforme JEE.
J’ai réussi le déploiement des processus métier, l’intégration des Métriques KPIs sous forme
de portlets dans WebMethods, et la génération des rapports relatifs aux différents KPIs.
La prochaine étape consiste à mettre en place un portlet qui permet de définir et

personnaliser des KPIs qui portent sur des observations extraites des données de documents
transitant dans les flux. Ce qui va offrir une vision de performance orientée métier plutôt que
processus.
Outre la richesse des connaissances techniques que j’ai acquise tout au long de mon
projet, j’ai touché à des volets connexes particulièrement intéressants, notamment, l’aspect
Business Process Management et Business Activity Monitoring. Ce projet a été également
pour moi l’occasion précieuse de découvrir le monde de l’entreprise, un monde ou la «
communication » est considérée comme carte maîtresse pour la survie de la société. Sur
l’aspect personnel, j’ai réussi à développer un sens relationnel bien raffiné.
Pour conclure, j’espère avoir répondu aux attentes de mon équipe projet et avoir été à
la hauteur de la confiance qu’ils m’ont témoignée.
82
Bibliographie :
83
Annexes
Annexes :
Annexe I :
Cortex : Système de management de la qualité de LOGICA
Annexe II :
EAI, Enterprise Application Integration.
Annexe III:
Composants essentiels de la plate-forme webMethods :
Annexe IV:
Architecture Orientée Services et ESB :
Annexe V :
Cartographie des Flux et Modèles mètier correspondants.
Annexe VI:
Types de Documents transitant dans les flux Rhodia.
84
Annexes
Annexe I :
Cortex : Système de management de la qualité de LOGICA
La certification CMMI level 3 (voir annexe1) de logica a été aboutie suite à la
satisfaction d’objectifs génériques et spécifiques. Ces objectifs on été atteint en appliquant les
exigences du système de management de la qualité de LOGICA : Cortex.
a) Introduction :
Fiabilité, qualité de livraison, respect de temps et des spécifications, ce sont

le coeur du succès de Logica. Ces standards sont atteints grâce au Business
Management System de Logica, Cortex : The Logica Way. Cortex est
référencé et accessible par tous les collaborateurs de Logica dans le monde
entier. Il fournit une plateforme de processus et de modèles (templates) qui
peuvent être appliqués à toutes les activités de Logica. Cortex a été créé en 1975 et
aujourd’hui, il est dans sa version 25.0.
b) L’organisation de cortex :
Dans Cortex, on traite des KPAs (Key Process Area) ou chaque KPA regroupe
l’ensemble des pratiques et processus qui permettent d’accomplir une tâche donnée au sein de
LOGICA. Cortex est composé de 13 KPA :
Figure 49: Les KPA de Cortex

Les 13 KPA sont regroupés suivant trois catégories :
 Operational
 Sales and Marketing
 Delivery
85
Annexes
Sales and
Operational Marketing
KPAs
KPAs
Manage Manage
Win Business
Manage Market Relationships
Run Logica
People
Au niveau du CSM, les trois KPA qui sont les plus utilisés sont Manage Projects,
Manage Service et Do Work, ces KPAs vont être développés par la suite.
i. Manage Projects
Le MPJ (Manage Project) est le KPA Cortex qui défini comment un projet est géré au
niveau de Logica. Il est composé de quatre phases :
 L’initialisation du projet
 La définition du plan de projet
 Le suivi du projet
 La clôture du projet
Chaque phase se compose d’un certain nombre de processus qui eux aussi contiennent
des sous processus qui concourent à la réalisation d’un objectif donné.
ii. Manage Service
Le service n’est pas géré de la même manière que le projet au sein de Logica.
D’ailleurs, le service, dans sa définition est différent d’un projet. Un service se caractérise par
la répétitivité dans le temps, alors que le projet est unique dans le temps. De ceci, la gestion
des deux sera aussi différente. Le KPA MSV (Manage Service) définit la façon avec laquelle
un service est géré au sein de Logica. Il est constitué de deux groupes de quatre processus
chacun. Les deux groupes sont :
 La préparation du service
 La livraison du service
iii. Do Work
Do work est une librairie de processus de cycles de vie et de fichiers de sortie

(outputs). Le choix spécifique d’un cycle de vie ou d’un processus se fait au niveau du
processus « planning and detailing a project » qui fait partie du KPA Manage Project.
86
Annexes
Les modèles de cycles de vies qui figurent dans le Do Work sont ceux acceptés par
l’utilisation interne de Logica pour les activités de développement/livraison/business change
management. La sélection du cycle de vie approprié doit être basée sur plusieurs critères :
 Taille
 Complexité
 contraintes du projet (dates limites, niveau du service...)
 etc. …
87
Annexes
Annexe II :
EAI, Enterprise Application Integration.

i. Qu’est ce que EAI ?
Acronyme de : Enterprise Application Integration, ou "intégration des applications

d'entreprise", l’EAI concerne l’intégration de multiple processus, applications, et systèmes
pour créer un flux continu d’informations.
L'EAI regroupe un ensemble de solutions techniques permettant à des systèmes informatiques
de nature différente d'échanger des informations selon un processus normalisé. Elles vont
prendre en charge les échanges entre des applications développées indépendamment et qui
n'ont jamais été conçues pour s'entendre, de telle façon qu’elles fonctionnent comme une
seule (ces applications peuvent utiliser des technologies incompatibles et rester
indépendamment contrôlées).
Concrètement, l'EAI permet de lier les applications entre elles grâce à un bus d'information
commun auquel elles sont liées par des connecteurs spécifiques.
Applications ERP
ERP
spécifiques
Applications
spécifiques CRM Portail CRM
Bases de d’entreprise
Portail EAI
d’entreprise données Applications
Outil Financier légataires
Applications
Outil Financier légataires
SCM SCM Bases de données
Figure 50: L’approche Spaghetti Traditionnelle et L’approche EAI
Le nœud central, qui va gère les interactions entre les applications, apporte une notion
de découplage : grâce à l'utilisation d'un format intermédiaire de communication les liens
(connecteurs) tissés entre chaque application sont maintenant remplacés par une liaison
unique partant de l'application vers la solution d'EAI. Ainsi, pour cinq applications, il suffit de
disposer de cinq passerelles, contre vingt dans la version précédente. Ce nœud central assure
ensuite la communication avec les autres applications. L’EAI déporte et mutualise la
problématique d’interfaçage : La logique métier est bien traité par l’application dédiée qui la
concerne, mais toutes les traitements tels que : Ordonnancement, Extraction, Transformation,
Emission, Routage, Suivi, Réplication, Synchronisation, Remontée d’alertes …sont pris en
charge et ont leur interface déporté dans l’EAI.
88
Annexes
L’impact sur les coûts de mise en œuvre et de maintenance des connecteurs est rapide,
et croissant. Le Gartner Group estime dans son étude « Integration Brokers : Market, Vendors
and Trends 2001 » que les gains de développement atteignent 25 % pour les interfaces
simples et 43 % pour les applications complexes en utilisant simplement une solution d’EAI.
L'EAI offre aux entreprises le moyen de capitaliser sur les systèmes existants sans se
lancer dans de longues et coûteuses opérations de rénovation, tout en centralisant les échanges
de données, la supervision des systèmes, des processus et des flux et réponds simplement aux
problématiques d’évolution, de productivité, de volumétrie, de sécurité et de fluidité de
l’information.
Mais l’EAI doit être abordée comme une problématique moins technique que
métier et traitée sur le long terme, sa pertinence résidant dans sa capacité à récolter les
changements des objets métier de l’entreprise et à en restituer une image à jour aux différentes
applications.
Figure 51: L’Approche Métier EAI

Les EAI répondent à une problématique triple de Fédération des sources de données,
d’Unification des applications d’entreprise, et d’Adaptation des processus métier mis en
place.
ii. Pourquoi faire appel à une démarche EAI ?
En se lançant dans un projet d'EAI, une entreprise cherche avant tout à gagner en
souplesse et en réactivité. Et ce par :
 L’intégration du front-office et back-office.

 L’intégration des nouvelles applications à l’existant.
 La synchronisation les données dispersées.
 La gestion les processus transversaux.
 La baisse des coûts et délais d’insertion de nouvelles applications au sein du SI.
 La baisse des coûts de traitement de l’information.
89
Annexes
Annexe III :
Composants essentiels de la plate-forme webMethods :

Le tableau ci-dessous décrit les composants essentiels de webMethods :
Les composants d'exécution et intégration

Composant principal de la plate-
forme webMethods, l'Integration Server peut
être comparé à la fois à un super-connecteur
et à un petit chef d'orchestre. Explications.
Environnement d'exécution, l'Integration

Server héberge un ou plusieurs adapteurs. En
d'autres termes, un adapteur, dans la nouvelle
architecture webMethods, est forcément
associé à un Integration Server. Il faut noter
que les fonctions de l'Integration Server sont
modulables (via des packages) afin de
maîtriser l'empreinte mémoire.
En outre, l'Integration Server s'apparente
aussi à un petit chef d'orchestre car, dans le
cadre de l'exécution d'un processus, il
embarque l'intelligence nécessaire pour situer
webMethods Integration Server les traitements dont il a la charge dans le
processus. Autrement dit, dans la version 6,
la plate-forme webMethods distribue
l'exécution des processus aux serveurs
d'intégration concernés.
Enfin, l'Integration Server présente deux

caractéristiques fortes. Primo, il se conforme
au modèle JCA (standard J2EE pour les
connecteurs inter-applicatifs) et dispose d'un
adapteur pour JBoss afin d'interagir avec des
EJB. Dans le courant de l'année, l'intégration
avec JBoss sera plus intime et permettra de
travailler avec les EJB sur un mode
bidirectionnel, en synchrone et en
asynchrone. Secundo, l'Integration Server
embarque un procédé de stockage temporaire
afin de disposer de sa propre gestion des
queues de message. Une fonction qui permet
90
Annexes
de gérer par exemple des interruptions de

communication avec le broker.
Le broker s'occupe de router les

messages échangés entre les Integration
Server sur un mode asynchrone et dans un
modèle publish/subscribe. Les Integration
Server sont en quelque sorte les clients du
broker. A noter qu'il est possible désormais
d'installer une plate-forme d'intégration
webMethods en se passant du broker. En
webMethods Broker effet, si tous les adapteurs nécessaires sont
hébergés dans un seul Integration Server,
celui-ci peut gérer localement les échanges
de message. Une précision toutefois : la mise
en œuvre du moteur de workflow, pour
prendre en compte les interactions humaines
dans le cadre des processus, nécessite le
déploiement du broker. Notons qu'une
license du broker en runtime est fournit avec
le Workflow.
Tout comme l'Integration Server, le
Workflow Server peut être considéré comme
un client du broker. Il exécute les tâches qui,
webMethods Workflow Server dans le cadre d'un processus, relèvent d'une
(Process Engine) interaction humaine. A cette fin, le Workflow
Server s'abonne aux documents qui appellent
une interaction humaine et publie via le
broker le résultat de ces interactions.
Les composants de connexion
Exécutés par l'Integration Server, les
adapteurs exposent à la plate-forme
d'intégration les données et les services de
webMethods Adapters l'application dont ils ont la charge. Les
premiers adapteurs disponibles dans le cadre
de la V6 concernent notamment la
connectique JDBC, SAP, Siebel et JDE.
Dans la plate-forme webMethods,
l'accès aux applications mainframe (CICS ou
webMethods Mainframe
IMS/DC) représente une connectique
particulière puisqu'il ne s'exécute pas sur
91
Annexes
l'Integration Server. Ce dernier passe ses

requêtes à un " composant mainframe " qui à
son tour dialogue avec l'application cible. Si
le connecteur mainframe s'apparente à un
connecteur particulier, en revanche il se
paramètre bien depuis l'outil Developer.
Exécuté sur l'Integration Server, ce
module est spécialisé dans le traitement de
documents XML et de fichiers plats. C'est
par son intermédiaire que la plate-forme
webMethods Trading Networks webMethods peut interpréter des
sémantiques issues de standards comme
ebXML, RosettaNet (pour l'électronique),
CIDX (pour la Chimie) ou encore EDI et
Swift.
Les composants de conception et développement
Depuis le Modeler, une interaction
humaine est vue comme une tâche spécifique
définie par l'entremise du Workflow
Designer. Un outil à travers lequel, rôles,
tâches et circuits sont définis. Les
webMethods Designer
interactions avec l'utilisateur sont gérées
depuis des interfaces clientes Java ou HTML.
Il permet aussi le développement des

CAF, déployé sur le MWS.
Outil dédié à l'intégrateur technique,
le Developer permet de paramétrer et de
tester les flux techniques. Le Developper
webMethods Developer fournit une interface unique, pour les
différents adapteurs, pour les différents
adapteurs, pour l'invocation de services Web,
etc.
Les composants d'administration au portail
L'Administrator consolide au sein
d'une unique interface Web l'accès aux
webMethods Administrator consoles de configuration et d'administration
des différents serveurs d'intégration et, point
important, de leurs adapteurs.
Le Monitor permet d'observer les
webMethods Monitor statuts des processus, services et documents
traités à travers la plate-forme. C'est depuis
92
Annexes
cet outil qu'un exploitant peut par exemple

suspendre un processus ou re-soumettre un
document.
Conçu autour du standard OMI (Open
Management Interface), co-développé par
webMethods et HP, le Manager comprend à
la fois des interfaces et une console pour
superviser les différents composants de la
webMethods Manager plate-forme d'intégration (Integration Server,
Broker…) dans une perspective de gestion de
la qualité de service. Surtout, OMI ouvre
cette supervision à des outils tels que HP
Open View, CA Unicenter ou encore BMC
Patrol.
Tableau 3: Composants WebMethods
93
Annexes
Annexe IV :
Architecture Orientée Services et ESB :

1. L’architecture orientée services.
La notion de SOA (Service Oriented Architecture) définit un style d’architecture
reposant sur l’assemblage de services proposés par les applications. Dans ce style
d’architecture, les différents composants logiciels sont connectés par un couplage lâche.
Dans une architecture de services, chaque élément applicatif doit fournir tout ou partie
de ses fonctionnalités sous formes de services appelables par d’autres applications. Pour
fournir ses services, un élément applicatif peut utiliser des services proposés par d’autres
applications, pouvant être issues de technologies hétérogènes.
Dans une SOA, la notion de référentiel de services est fondamentale, car pour pouvoir
réutiliser les services, il faut connaître à la fois leur existence et leurs caractéristiques. Une
approche SOA permet de réaliser facilement l’orchestration d’un processus métier par
l’assemblage de différents services, en utilisant un outil de BPM. L’homogénéité des
interfaces des services assurent encore ici une intégration simple avec un outil de BPM et la
réalisation rapide de nouveaux processus.
Globalement, « l’approche SOA » est l’union de :
- Une méthodologie pour identifier et concevoir des applications comme des

assemblages de services.
- Un ensemble d’outils et d’infrastructures pour faciliter la création de ces services
et leur utilisation.
- Des patterns de construction de services.
 Intérêts qualitatif d’une SOA :

 Interopérabilité :
C’est l’aptitude à connecter les applications à travers plateformes, langages, systèmes

d’exploitation et régions géographiques. En mettant en œuvre des services globaux partagés
entre blocs applicatifs et homogénéisant des interfaces et les formats d’échanges.
 Réutilisabilité :
C’est l’aptitude d’un service à être réutilisé à travers les applications. Ceci Permet de
réduire le couplage entre modules.
 Maintenabilité :
94
Annexes
La SOA permet de minimiser l’effort pour localiser et corriger les fautes.
 Testabilité :
En termes de testabilité la SOA facilite les procédures de tests permettant de s'assurer

de l'adéquation des fonctionnalités.
 Portabilité :
La SOA minimise l’effort pour se faire transporter dans un autre environnement

matériel et/ou logiciel.
 Intérêts quantitatifs d’une SOA :

D’une part la SOA permet de réduire les coûts, par l’aptitude à exposer des services
faiblement couplés qui peuvent être facilement utilisés et composés selon les besoins métiers,
évitant la duplication des ressources avec un grand potentiel de réutilisation et une réduction
palpable de coût.
D’autre part elle permet de développer les business models, par l’aptitude à composer
rapidement de nouveaux services et processus métier à base des services existants et offre un
avantage distinct à une organisation qui se doit d’être agile pour répondre aux besoins. Faisant
fois de levier pour les composants existants et réduisant le temps nécessaire au développement
logiciel.
2. L’ESB (Enterprise service bus).

Les standards J2EE et Web Services ont profondément modifié le paysage de
l’intégration. Ainsi, de nouveaux produits basés sur ces standards émergent depuis deux ans
sous le nom d’Enterprise Service Bus.
Ces produits peuvent être vus comme des supports à une implémentation concrète
d’une SOA, et sont basés principalement sur des standards comme XML et les WebServices.
Les ESB reprennent les grands principes de l’EAI, mais l’utilisation poussée de
standards rend leur coût de licence beaucoup plus abordable.
La réalisation de la communication avec les partenaires de l’entreprise en mode B2B

(Business to Business) se trouve simplifiée grâce à la mise en œuvre de standards reconnus
par tous.
 Définition :
Un « Enterprise Service Bus » est une solution d’intégration implémentant une
architecture totalement distribuée, et fournissant des services comme la transformation des
données ou le routage basé sur le contenu (CBR), ainsi qu’une interopérabilité accrue par
95
Annexes
l’utilisation systématique des standards comme XML, les Web Services et les normes WS-*1.
L’ESB est une solution packagée qui permet de mettre en œuvre la SOA.
 Architecture :
Figure 52: Echange d’informations entre entreprise et partenaires via un bus ESB
 Transformation des données et routage :

Les données traversant le bus sont toujours représentées par le fichier généré par
l’outil d’export. La transformation de la représentation de ces données sous une forme XML,
plus structurée et plus lisible, va permettre de pouvoir partager ces informations sur le bus.
La structure du fichier généré par l’outil d’export n’est effectivement compréhensible

que par l’outil d’import, situé au siège de la société.
Dans l’optique de rendre ces informations utilisables par d’autres applications

(notamment les autres agences), il faut les présenter sous une forme standard et
compréhensible.
Encore une fois, il n’est pas nécessaire de modifier les applications, la transformation
des données va se faire dans le bus. Un service de transformation s’intercale dans le processus
d’envoi des messages au siège. Ce service est configuré pour reconnaître la structure du
fichier généré par l’outil d’export et générer un autre fichier mieux structuré.
96
Annexes
Les données transitant dans le bus ne sont donc plus envoyées directement à leur
destinataire, mais vont suivre un circuit, transitant par différents points de l’ESB, jusqu’à
atteindre finalement le siège. Ce circuit est défini directement dans le message contenant les
données.
Figure 53: Routage de données

.
Figure 54: Transformation des données en XML
97
Annexes
Annexe V :
Cartographie des Flux et Modèles mètier correspondants.
Cartographie des processus :

 Elemica ShipNotice
Rhodia informe son partenaire des livraisons qui lui est destiné.
Processus :
Figure 55: Processus Elemica ShipNotice
98
Annexes
Description :
Les shipNotice envoyés par Rhodia SAP au hub webMethods se transforme en

"CidxShipNoticeV202" avant d’être transféré à Elemica qui procède à la validation et la
réponse par le RA ou bien le RAE.
 EtapOnLine
100% dédiée à la gestion des Déplacements Professionnels, ETAP-ON-LINE conçoit,
développe et édite des solutions logicielles pour toutes les entreprises PME-PMI, Grands
Comptes et Service public, souhaitant optimiser la préparation de voyage d'affaires et la
gestion de notes de frais de manière simple, rapide et économique. Disponible via internet ou
sous intranet.
Ainsi, pour le suivi des notes de frais de ses employés, Rhodia a opté pour un
partenariat avec ETAP-On-Line .
Processus :
Figure 56: Processus EtapOnLine
99
Annexes
Description :
Une fois les fichiers (notes de frais, paiements, déplacements…) sont placés dans leurs
dossiers correspondants à EtapOnLine, ils sont automatiquement transférés au hub
Webmethods via FTP où la plate-forme Webmethods est installée pour la zone dématérialisée
(DMZ).
Selon le type du document il sera envoyé via CFT à SAP ou via SMTP aux destinataires
correspondants.
 Inventory actual usage

Le partenaire renvoie automatiquement le statut de son inventaire en termes de
fourniture à Rhodia.
Processus :
Figure 57: Processus Inventory actual usage
100
Annexes
Description :
Elemica envoie au hub webMethods un document de type

"CidxInventoryActualUsageV201" qui contient le statut de son inventaire en termes de
fourniture. Webmethods accuse réception du document d’Elimica en envoyant un "Receipt
Acknowledgement" (RA) ou bien un "ReceiptAckException" (RAE).
Webmethods transforme le document envoyé par Elemica en "HubInventoryActualUsage" et
le renvoie au backend.
 Carriers :
Schenker et Dentressangle sont deux entreprises de gestion de cargaisons. Ils offrent
un avantage important en termes de logistique notamment pour de nombreux secteurs
industriels à Rhodia.
Ce flux gère les demandes des messagers de livraison chez Rhodia auprès de Schenker
et Dentressangle. Dans ce cas Rhodia joue le rôle du consommateur alors que Schenker et
Dentressangle jouent le rôle des fournisseurs.
101
Annexes
Processus :
Figure 58: Processus Carriers

Description :
Le flux commence lorsque le consommateur Rhodia enregistre ses notes de livraisons

sur le serveur SAP ces notes vont être transformé à un autre document qui va être transférer
par la suite à Schenker ou bien Dentressangle.
102
Annexes
Modèles Métier :
Figure 59: SellSide OrderChange
Figure 60: SellSide OrderCreate 2
103
Annexes
Figure 61: Elemica OrderCreate
Figure 62: Elemica shipnotice
104
Annexes
Annexe VI:
Types de Documents transitant dans les flux Rhodia.
Type de documents
ORDERS03 Elemica
commandes reçues via Elemica, autant les commandes traditionnelles comme celles
du VMI et VMOI) – voir indicateur 2 lignes plus bas
ORDERS03 Crossgate
commandes reçues via Crossgate, pour des clients du secteur de l´automobile
ORDERS03 consolidés
Indicateur de qualité: combien sont tombés en erreur fonctionnelle dans SAP
(“statut 51”)
OrderResponseV201
Elemica réponses aux commandes, soit aux ORDERS03 issus de commandes reçues via
Ventes
Elemica
OrderChangeV202
Elemica
modification à commande, émise par le client de Rhodia
INVOIC01 Elemica facture commerciale amérique du Nord
INVOIC01 Crossgate
facture commerciale dématerialisée Europe
DELVRY01 Elemica livraison des produits
ASNCOA EMNS
livraison des produits et certificat d'analyse envoyé à Goodyear
ASNCOA_ACK EMNS
réponse reçue de Goodyear validant le contenu du ASNCOA
ORDERS03 Elemica
commandes de matières premières Europe et Amérique du Nord
XCBL OrderV35
direct
commandes pour d'autres achats Amérique du Nord
Achats
ORDCHG Elemica
modification à commande de matière première Europe, émise par Rhodia
PREQCR03 direct
demandes d'achat envoyées au sourcing d'achats "Mercado Eletrônico" au Brésil
Finance EASYLOG direct

données de factures commerciales envoyées à DHL pour dédouannement auprès de
la douane France
105
Annexes
INVOIC02 direct
Facture Fournisseurs de service pour l’Amérique du Nord: IDOC-Ghost/Spot Pcard,
X12 810, IDOC-CASS), LOCKBOX, BAI)
fichiers en direct
Ulysse Europe (fichiers "CPT", "BTA", et "VIR") et Ulysse Amérique du Nord (fichiers
plats de MasterCard NA pour Ulysse)
LoadTenderMotor
direct demandes de transport route France à un pool de transporteurs composé par
Schenker et Dentressangle
LoadTenderOcean
Elemica
Logistique instructions d'acheminement maritime pour les agents logistiques qui plannifient
et exécutent le transport,via GT Nexus
road Status direct

réception de date et status de fin du transport route à partir de sites de Rhodia
en France
ocean Status Elemica

réception de date et status de départ et d’arrivée du bateau
InventoryActualUsage
Supply
Elemica
Chain réception de niveaux de stock pour VMI/VMOI Amérique du Nord
Tableau 4: Types de documents transitant dans les flux de Rhodia
106

ALAMI JAMAL Training Repport Logica 2010 Business Activity Monitoring

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ALAMI JAMAL Training Repport Logica 2010 Business Activity Monitoring

Încărcat de

Drepturi de autor:

Formate disponibile

ROYAUME DU MAROC

Projet de Fin d'Etudes

Business Activity Monitoring : Développement des

Préparé par : M. ALAMI JAMAL

Sous la direction de : M. OURADI Najib (INSEA)

Soutenu publiquement comme exigence partielle en vue de l'obtention du

Diplôme d'Ingénieur d'Etat

 M. OURADI Najib (INSEA)

Mon projet de fin d’étude s’inscrit dans le cadre du projet Rhodia,

Chapitre 1 : Contexte général du Projet ........................................................................... 14

Le service informatique doit inclure, combiner, consolider et analyser la profusion

LOGICA, première société de service Offshore au Maroc, en sous traitant l’activité de

Le pilotage axé sur la performance nécessite la définition de KPIs et la conception de

Le pilotage de l’activité commerciale de Rhodia par la performance est la problématique

Contexte général du projet

Dans la première section de ce chapitre

Chapitre 1 : Contexte général du Projet

I. Organisme d’accueil : LOGICA Group

I.1. Présentation générale :

I.2. Evolution historique :

 En 1968, la société Informatique et l’entreprise est créée.

européenne en conseil et ingénierie informatique, née de la coopération entre

Figure 1: Historique de Logica

Figure 2: Les secteurs d’activités de Logica

I.4. Clients et partenaires :

Le groupe Logica emploie 40.000 personnes à travers 41 pays, avec un chiffre

La figure suivante présente la cartographie du groupe Logica à travers le monde :

Figure 3 : Centres de Logica dans le monde

Figure 4 : Partenaires stratégiques

BEA Systems, Business Objects, Cognos, EMC, Filenet, HRAccess, Hypérion,

Figure 5: Clients de LOGICA

I.5. Centre de services LOGICA Maroc :

Les centres de services de Rabat et de Casablanca s'inscrivent dans un modèle de

Logica, privilégie ainsi la proximité, la connaissance de ses clients, tout en demeurant

Figure 6 : Proportion des catégories des centres de services de Logica

Le choix du critère de proximité ou d'éloignement varie en fonction du besoin

Au cours de l’année 2004, au Maroc, Unilog et Sofrecom, filiale de France Telecom,

Le centre de service de Rabat (CSR) a commencé en fin de l’année 2004 avec un

Figure 7 : Evolution de l’effectif du CSR

Organigramme LOGICA CSM:

Responsable Responsable Delivery

Resource Responsable Transition

Figure 8 : Organigramme de Logica CSM

I.5.2. Prestations proposées:

 Support troisième niveau

 Support de deuxième et troisième niveau

 Conception des plans de tests

II. Cadre général : Le Projet d’intégration Rhodia

II.1. Groupe Rhodia :

Rhodia est un groupe chimique international, résolument engagé

Rhodia a confié à Logica la sous-traitance de toutes ses activités informatiques en

II.2. Objectifs de l’entité projet Rhodia:

Le projet Rhodia consiste en plusieurs activités gérées principalement par un

Le support constitue une activité assurée par l’équipe EAI.

II.3. Prestations de l’entité projet Rhodia :

 Études générales et détaillées.

 Formation des utilisateurs

 Support client, hotline.

II.4. Organisation et conduite du projet Rhodia TMA :

La Tierce Maintenance Applicative consiste, pour une entreprise, à déléguer la

 Le pilotage et l’accompagnement en conseil, management, gestion et reporting du

 Organigramme du projet Rhodia :

Rachid Ben Lahcen

Sanae Benkaroum Laaouinate Anas