REFONTE DE LA PLATE FORME ARCHITECTURALE DU …xa.yimg.com/.../853096211/name/MengoMemoireV4.0.d… · Web viewRefonte de la plate forme architecturale du patrimoine applicatif

you

© Novembre 2009

REFONTE DE LA PLATE FORME ARCHITECTURALE

DU PATRIMOINE APPLICATIF

Superviseur IAI :

Dr KONFE BALIRA Ousmane

Maitre de Stage :

Ing. Arsène NGATO

Réalisé par :

MENGOLO ASSAMBA Joël

Refonte de la plate forme architecturale du patrimoine applicatif de la SONARA

A mes feus oncle et tantes EBA’A Bernadette Roseline, EDOM Roger et MINDJA Monique Clotilde.

A mes parents Monsieur ASSAMBA Flavien Magloire et Madame ASSAMBA Née ZE EYENGA Marie Chantal.

A ma fiancé KONGNE FOKAM Françoise et mon fils ASSAMBA MENGOLO Ange Bryan Enrique.

Joël MENGOLO ASSAMBA. IAI-2009 i

DEDICACES


« Faire aisément ce qui est difficile aux autres, voilà le talent ; faire ce qui est impossible au talent, voilà le génie. »

Henri Frédéric Amiel.

Journal, décembre 1865

Joël MENGOLO ASSAMBA. IAI-2009 ii

EPIGRAPHE


Au terme de ce stage, toute ma reconnaissance exprimée :

Au corps administratif et enseignant de l’IAI pour leur encadrement pendant ces trois dernières années.

A Monsieur le Directeur Général de la SONARA pour m’avoir permis d’effectuer mon stage dans son entreprise.

A Monsieur Symphorien Kevin MOMENDENG pour avoir toujours cru en moi.

A toute l’équipe informatique de la SONARA pour l’encadrement indéfectible durant la période de stage.

A Messieurs Samuel ABBE AKAK et Christian FOTSING pour m’avoir mis sur la voie de la spécialisation et de l’expertise.

A Mes frère et sœur cadets Casimir MBENG ASSAMBA et Lydie Solange NDONO pour l’attachement témoigné à mon égard.

A tous mes promotionnaires particulièrement à mon frère d’un autre pays Horacio AMEHAME KOSSI, à Bertrand NGONO ONGOLO et DJAOWE MINKREO.

A toute la communauté estudiantine de l’IAI.

Joël MENGOLO ASSAMBA. IAI-2009 iii

REMERCIEMENTS


DEDICACES............................................................................................................................................................... iEPIGRAPHE............................................................................................................................................................. iiREMERCIEMENTS.................................................................................................................................................... iiiTABLE DES MATIERES............................................................................................................................................. ivAVANT-PROPOS.......................................................................................................................................................1RESUME..................................................................................................................................................................2ABSTRACT...............................................................................................................................................................3INTRODUCTION GENERALE......................................................................................................................................4PARTIE I : LE SUJET, SON CONTEXTE, SON INTERET ET SA PROBLEMATIQUE..............................................................5Chapitre1 : Le raffinage dans l’économie mondiale..........................................................................................6

I.1 L’énergie, le pétrole et l’économie mondiale.....................................6I.2 Le raffinage dans la chaîne pétrolière....................................................7I.3 Le pétrole brut, les produits pétroliers et leur valorisation......8I.4 Industrie pétrolière et qualité.....................................................................9I.5 L’informatique au service de l’industrie pétrolière......................11Conclusion.....................................................................................................................12

Chapitre2 : Le sujet et son contexte................................................................................................................13

II.1 La structure d’accueil....................................................................................13II.1.1 Présentation générale de la SONARA.......................................................13II.1.2 Organigramme...................................................................................................14II.2 Contexte et objectif du sujet.....................................................................16II.2.1 Le contexte...........................................................................................................16II.2.2 Objectif et motivations du sujet...................................................................16a. Objectif.......................................................................................................................16b. Motivations................................................................................................................17b.1 Motivations de la refonte de POV...................................................................17b.2 Motivations de la migration des données....................................................18b.3 Motivations de la consolidation des serveurs............................................18II.3. Problématique et intérêt............................................................................18II.3.1 Problématique.....................................................................................................18II.3.2 Intérêts..................................................................................................................19

Joël MENGOLO ASSAMBA. IAI-2009 iv

TABLE DES MATIERES


PARTIE II : METHODE DE CONDUITE DU PROJET ET ARCHITECTURES ORIENTEES SERVICES....................................20Chapitre 3 : La méthode de conduite du projet..............................................................................................21

III.1. De la conduite de projet informatique.............................................21III.2 Principales méthodes de développement logiciel.......................23III.2.1 Les méthodes séquentielles ou méthodes en cascade......................23III.2.2 Les méthodes dynamiques objet................................................................24III.2.3 Les méthodes dynamiques agiles..............................................................24III.3 Méthodes de migration des données Oracle..................................24III.3.1 La migration par l’exportation et l’importation des données........25III.3.2 La migration par la mise à niveau de la base de données..............25III.3.3 La migration par la mise à niveau du serveur de données.............25III.3.4 La migration des sources de données hétérogènes...........................26III.4 Méthodes de consolidation des serveurs de données Oracle................................................................................................................................................26III.4.1 La consolidation physique............................................................................27III.4.2 La consolidation de fichiers.........................................................................28III.4.3 La Virtualisation...............................................................................................28III.4.4 La consolidation logique...............................................................................29Conclusion......................................................................................................................30

Chapitre 4 : L’eXtreme Programming...............................................................................................................31

IV.1 La méthode eXtreme Programming....................................................31IV.1.1 Présentation.......................................................................................................31IV.1.2 Les quatre valeurs...........................................................................................32IV.1.3 Les principes de base.....................................................................................33IV.1.4 Les Treize Pratiques.......................................................................................34IV.2 UML comme outil de modélisation......................................................36IV.3 Un mot sur le couplage UML-XP............................................................36Conclusion......................................................................................................................37

Chapitre 5 : Les architectures orientées services et leur modélisation par SOAML...................................38

V.1 Les architectures Orientées Services....................................................38V.1.1 Notion de services.............................................................................................38V.1.2 les impacts de la SOA......................................................................................40V.2 Les web services................................................................................................41V.2.1 Les services web de type REST...................................................................41V.2.2 Les web services WS........................................................................................42V.3 La démarche SOA au niveau du SI.........................................................44

Joël MENGOLO ASSAMBA. IAI-2009 v


V.3.1 L’approche légaliste « top down »..............................................................44V.3.2 L’approche organique « Bottom Up»........................................................44V.4. SOAML pour la modélisation en environnements Orientés Services...........................................................................................................................45V.4 .1 Présentation de SOAML................................................................................45V.4.2 Un mot sur les spécifications SOAML.......................................................46Conclusion......................................................................................................................47

Partie III : ARCHITECTURE EXISTANTE...................................................................................................................48Chapitre 6 : Architecture matérielle et logicielle...........................................................................................49

VI.1 Le matériel..........................................................................................................49VI.2 Les systèmes d’exploitation......................................................................50VI.3 Les Serveurs de données et d’applications......................................50VI.4 Architecture du SI.........................................................................................51VI.4 Architecture des différents serveurs de données......................52VI.4.1 Architecture de Oracle Database 8i.........................................................52VI.4.2 Architecture de Oracle Database 9i.........................................................53VI.4.2 Architecture de Oracle Database 10g.....................................................53VI.4.3 Oracle 8i, 9i et 10g : les différences........................................................54VI.4 Architecture de l’application de gestion des données techniques......................................................................................................................55Conclusion......................................................................................................................56

PARTIE IV : CONCEPTION DE L’ARCHITECTURE CIBLE..............................................................................................57Chapitre 7 : Conception de la nouvelle architecture du logiciel POV............................................................58

VII.1 Métaphore de l’architecture globale du logiciel........................58VII.2 Choix des outils..............................................................................................60VII.3 Métaphore des services du module de Valorisation................61VII.4 Modélisation des services du calcul des prix de vente des produits...........................................................................................................................63a- Métaphore du diagramme de flux du calcul des prix de produits......63b- Métaphore de la couche persistance du calcul des prix........................64c- Métaphore de l’architecture des services du calcul des prix...............64d- Métaphore de l’architecture du participant : calculateur des prix....65e- Métaphore des interfaces des services impliqués....................................66f- Métaphore du contrat du service calculer un prix...................................66Conclusion......................................................................................................................67

Chapitre 8 : Conception de la nouvelle architecture des serveurs de données et d’applications..............68

Joël MENGOLO ASSAMBA. IAI-2009 vi


VIII.1 Architecture globale des serveurs....................................................68VIII.2 Planification de la consolidation des serveurs..........................68VIII.2.1. OFA et la cohabitation des serveurs Oracle Database.................69VIII.2.2 Utilisation de l’architecture OFA............................................................69VIII.2.3 Configuration des services Oracle Net................................................70VIII.2.4 Processus d'écoute Oracle Net................................................................72VIII.3 Planification de la migration des données...................................72Conclusion......................................................................................................................73

PARTIE V : MISE EN OEUVRE...................................................................................................................................74Chapitre 9 : Mise en œuvre...............................................................................................................................75

IX.1 Mise en œuvre de la consolidation des serveurs.........................75IX.2 Mise en œuvre de la migration des données..................................80IX.3 Mise en œuvre du calcul des prix des produits de raffinage................................................................................................................................................80Conclusion......................................................................................................................87

CONCLUSION GENERALE........................................................................................................................................88LISTE DES ABREVIATIONS......................................................................................................................................... IBIBLIOGRAPHIE......................................................................................................................................................VLISTE DES ILLUSTRATIONS...................................................................................................................................VIIIANNEXES..............................................................................................................................................................VIII

Joël MENGOLO ASSAMBA. IAI-2009 vii


Le présent document rend compte du stage de fin de cycle que nous avons effectué à la SONARA (Société Nationale de Raffinage) du Cameroun. Axé sur les technologies Oracle et précisément l’Administration des bases de données, ce stage de cinq mois visait le renforcement de nos capacités opérationnelles dans le cadre de notre formation d’Ingénieur de Conception en Informatique à l’IAI et du processus de spécialisation et d’acquisition d’expertise que nous avons entamé.

Le document est divisé en neuf chapitres répartis sur cinq parties. Les deux premières parties introduisent le métier du raffinage, le contexte du travail, l’impératif de l’adoption d’une démarche qualité, la méthodologie de travail choisie et les meilleures pratiques architecturales à l’usage. Les trois autres, présentent le travail que nous avons effectué ainsi que les résultats obtenus dans un environnement de développement.

De petites introductions annoncent au lecteur ce qu’il trouvera dans les chapitres concernés.

Des conclusions lui rappellent l’essentiel de ce qu’il vient de lire avant qu’il n’aborde un autre chapitre.

La table des illustrations en fin de document permet au lecteur de retrouver facilement les éléments comme une figure.

Joël MENGOLO ASSAMBA. IAI-2009 1

AVANT-PROPOS




Notre travail embrasse à la fois le métier d’Assistance à la Maitrise d’Ouvrage et celui d’Assistance à la Mise en œuvre.

L’aspect Mise en œuvre est instancié par la consolidation des serveurs et la migration de données Oracle, effectuées pour optimiser l’organisation des ressources disponibles. Il s’agit d’adopter les démarches de consolidation et de migration, de les planifier et de les mettre en œuvre d’abord dans un environnement de développement et ensuite de production. La contrainte permanente est de suivre les normes et standards prescrits par l’éditeur en la matière.

L’aspect Maitrise d’ouvrage quant à lui s’inscrit dans la veille technologique que nous avons menée pour prescrire l’architecture, les outils et la méthode de développement de l’application de gestion des données techniques vers une architecture client/serveur avec client léger.

Pour prouver la faisabilité de nos prescriptions, un prototype a été réalisé. Il pourra servir de référentiel pour l’implémentation des autres modules du logiciel suivant les recommandations que nous avons commises.

Mots clés : SGBD, Consolidation des serveurs, Migration des données, Services, Services web, Architecture, Architecture Orientée Services.


RESUME


The five months internship we made in the National Refining Company (SO.NA.RA) ran effectively from the 6th July to the 30th November 2009. It was carried out in the Information Technology Service which is under the Technical Direction (DT).

This report is based on IT integration of the Quality Management System of the SONARA. The evolution and modernization of the IT infrastructure and architecture had been decided and task was given to us to align the applicative patrimony to the new technologic deal.

Our first mission was to follow the prescription of Oracle Corporation in order to make different versions of the Oracle Database server live together on the same Operating System and on the same physical machine. That mission had been accomplished with great success.

The second mission was to design and realize a data migration from Oracle 8.1.6 to Oracle 10.2.0. This job was also done successfully.

The third mission but not the least that was assigned to us was to make wakeful prescriptions of the development architecture, tools and current practices of web development. We opt for the Service Oriented Architecture, eXtreme Programming method and for Oracle tools. And we realize a prototype that implements the petrol’s products prize calculation to prove the feasibility of those prescriptions.


ABSTRACT


L’atteinte des objectifs stratégiques est une priorité pour toutes les entreprises. Les services informatiques dont la mission est de faciliter le métier des autres, sont habités par un double souci permanent d’optimisation de l’utilisation des ressources et de veille technologique. D’autre part, l’étroitesse de leurs enveloppes budgétaires leur impose à utiliser au mieux ce qu’ils ont ou peuvent s’offrir. Cette optimisation passe généralement par une révision des architectures des serveurs et des applications qu’ils hébergent.

La Société Nationale de Raffinage du Cameroun, par son service informatique et poussée par sa marche vers l’excellence en terme qualité, s’est lancée dans une reforme de son Système d’Information et partant de son patrimoine applicatif. Cette reforme implique une réorganisation du parc des serveurs de données et d’applications, et une refonte des applications postes fixes ayant un grand nombre d’utilisateurs vers une architecture client léger en s’appuyant sur les meilleures pratiques à l’usage.

Dotée d’une variété des versions du serveur de données Oracle, il s’avère important, pour la SONARA, de profiter pleinement des investissements consentis en restant dans la régularité vis-à-vis de l’éditeur. La cohabitation de ces différentes versions sur une même architecture physique et système, ainsi que des migrations des bases de données vers les versions présentant une plus value sont donc envisagées dans le cadre de notre travail.

Notre travail consiste également à une veille technologique en termes d’architecture à adopter pour le développement d’applications 3-tiers avec client léger : l’application de gestion des données techniques devant être refaite suivant les recommandations que nous prescrirons.


INTRODUCTION GENERALE


S’appuyant sur les recommandations de l’éditeur en la matière et sur les meilleures pratiques connus en termes de gestion de projet, nous avons proposé et réalisé la consolidation et la migration des données.

Le Buzz-word1 Architecture Orientée Services et la méthode agile eXtreme Programming adaptée aux équipes réduites, ont été prescrits pour la refonte de l’application de gestion des données techniques, dont le module de calcul des prix des produits de raffinage a servi de prototype.

1 Mot qui sonne bien.


PARTIE I : LE SUJET, SON CONTEXTE, SON INTERET ET SA PROBLEMATIQUE.


CHAPITRE1 : LE RAFFINAGE DANS L’ÉCONOMIE MONDIALE

Ce chapitre a pour but de présenter le métier du raffinage dans ses rapports avec les économies nationales et mondiales. Il présente également l’informatique dans sa mission d’aide à l’atteinte des objectifs stratégiques du métier du raffinage.

I.1 L’énergie, le pétrole et l’économie mondiale.

La croissance économique est très liée à la consommation d’énergie et le pétrole est l’une des principales sources d’énergie. Le pétrole plus qu’une matière première, est une matière stratégique. Les deux guerres mondiales ont convaincu les politiques de l’importance de la sécurité des approvisionnements pétroliers. Les transactions pétrolières représentent quotidiennement 10% du commerce mondial et la rupture de l’approvisionnement pétrolier aurait des conséquences dramatiques sur l’économie mondiale [BLEIST08].

Parler d’énergie revient en général à parler de charbon, d’électricité ou de pétrole. Ces différentes sources d’énergie sont substituables, et il existe à cet effet un système de coefficients d’équivalence des deux premières par rapport au pétrole.

Ainsi, 1,5 tonne de Charbon équivaut à 1tonne de pétrole. 1tonne de charbon vaut alors 1 :1,5=0,67 tep (tonne équivalent pétrole). Le coefficient d’équivalence du charbon par rapport au pétrole est donc égal à0,67 tep. De manière analogique, le coefficient d’équivalence de l’électricité hydroélectrique par rapport au pétrole est de 0,086 tep et celui de l’électricité nucléaire de0,26 tep. C’est dire que le pétrole joue un rôle dominant sur la scène énergétique. Cette domination est réaffirmée par le fait qu’en2005, le pétrole représente 40 % du bilan énergétique mondial et les scénarios de référence de



l’AIE et de l’EIA envisagent une stabilité de cette part jusqu’en 2020 [GEOPO05].

Du point de vue économique, on distinguera deux types d’énergie : l’énergie commerciale et l’énergie non commerciale. L’énergie commerciale est celle qui est vendue et achetée, échangée contre de la monnaie. L’énergie non commerciale consiste en bois de chauffe, débris végétaux, résidus animaux qui sont ramassés par les utilisateurs pour leurs propres besoins. Le pétrole relève du domaine de l’énergie commerciale.

Les utilisateurs du pétrole sont extrêmement nombreux. Le pétrole brut ne peut être utilisé directement comme combustible. L’essentiel du pétrole brut est raffiné, transformé en produits avant d’être utilisé. En effet, dans le secteur vital de l’économie mondial qu’est le transport dépendant à 98 % du pétrole [GEOPO05], un moteur à allumage commandé, un moteur diesel ou une turbine requiert des produits qui s’ils sont tous issus du pétrole, ont des caractéristiques physico-chimiques différentes. C’est l’objectif du raffinage de fournir à chaque utilisateur le produit le mieux adapté à ses besoins.

I.2 Le raffinage dans la chaîne pétrolière.

Le raffinage est le maillon de la chaîne pétrolière qui va permettre la transformation du pétrole brut en produits utilisables pour le transport, les besoins industriels, la fabrication des plastiques, des fibres, de caoutchoucs synthétiques etc. On distingue :

Les raffineries appartenant à des sociétés intégrées qui produisent, transforment et commercialisent les produits pétroliers :

Les sociétés internationales ; Les sociétés des pays producteurs ; Les raffineries indépendantes.



Par le passé, le « raffinage » était simple : il s’agissait de récupérer uniquement les fractions utilisables du pétrole, fractions lourdes pour la lubrification ou la fabrication des graisses. Une séparation très sommaire y suffisait. Puis apparurent (1863 à BOSTON) des systèmes de fours successifs permettant de récupérer progressivement fractions légères, fractions lourdes et fractions moyennes. Une raffinerie se compose de plusieurs parties distinctes [FAVEN98] :

L’ensemble des unités de traitement où s’opère la séparation du pétrole en fractions ou coupes, la transformation (amélioration) de certaines coupes et la conversion des fractions lourdes en fractions légères.

Les utilités, c'est-à-dire l’ensemble des unités de production de combustible, d’électricité, de vapeur, d’eau de réfrigérant, d’eau douce, d’air comprimé, etc. nécessaires aux processus de raffinage.

Les stockages Les installations de réception et d’expédition, les

installations de mélange.

I.3 Le pétrole brut, les produits pétroliers et leur valorisation.

Le pétrole brut est un mélange liquide d’hydrocarbures, c'est-à-dire de molécules constituées d’atomes de carbone et d’hydrogène. Il contient en général également des impuretés, en particulier du souffre mais aussi des traces de métaux (nickel, vanadium), d’azote, etc. les proportions des différentes molécules sont différentes d’un brut à l’autre : « autant de gisements, autant de brut ! ». Il fournit principalement les produits suivants :

Des carburants (essences automobiles, carburéacteur, gazole, fuel lourd pour moteur diesel très lent, et GPL).

Des combustibles (GPL, fuel domestiques, fuel lourd, coke et brais).



Des produits non énergétiques (bitumes, lubrifiants, essences spéciales, pétrole lampant, cires…).

Des matières premières (naphta, GPL pour pétrochimie, huiles de procédés, solvants, coke, cires et paraffines).

Les principales étapes du raffinage sont :

Première étape : éliminer les impuretés contenues dans le brut.

Deuxième étape : la distillation. Le pétrole est chauffé pour séparer les différentes "coupes". En fonction de la température d'ébullition, on obtient des produits différents. Les trois principales "coupes" pétrolières sont les produits légers (les composés gazeux et les essences dont la température d'ébullition se situe entre 40 °C et210 °C

), les produits moyens (kérosène, diesel et fuel domestique, dont la température d'ébullition se situe entre 170 °C et360 °C) et les produits lourds (fuel lourd ou résidus) [WAUQ98].

Le pétrole brut forme donc un continuum d’espèces chimiques, depuis les gaz jusqu’aux produits les plus lourds, il est traité dans une raffinerie qui en extrait les fractions commerciales. Les procédures d’analyse élémentaire, de séparation de ces fractions, de leurs traitements et leur conservation sont diverses et assez complexes. Du fait de cette diversité, il s’est avéré nécessaire de les uniformiser. Toutes ces étapes font aujourd’hui l’objet de protocoles, les décrivant le plus minutieusement possible et établis par des organismes internationaux officiels.

L’industrie du pétrole étant fortement capitalistique, son objectif avéré est de faire des bénéfices. Aujourd’hui, le commerce du pétrole est libéralisé comme celui des autres matières premières. Son prix se fixe sur le marché international où règne, avec quelques réserves, la loi de l’offre et de la demande. Les paramètres fondamentaux du marché pétrolier sont très particuliers et son fonctionnement est imparfait au sens économique. La logique de fixation des prix



est régie soit par le marché à terme, par le marché à spot ou par les accords de troc.

Pour une tonne de brut traité :

La marge brute de raffinage est la différence entre la valeur des produits obtenus, à la sortie de la raffinerie, et le coût du brut à l’entrée de la raffinerie.

La valorisation des produits pétroliers se calcule en multipliant leurs prix par leurs rendements respectifs.

La marge nette est égale à la marge brute diminuée des frais variables (produits chimiques, catalyseurs, frais financiers d’immobilisation des bruts et des produits dans les stockages).

Pour obtenir l’équilibre, la marge nette d’une raffinerie devrait également couvrir l’ensemble des charges fixes : personnel, entretien, taxes assurances, frais généraux, et l’amortissement des installations et frais financiers liés à leur construction. Les consommations internes des produits fabriqués (utilisation des combustibles pour le fonctionnement des unités de transformation et de production d’électricité, de vapeur, etc.) doivent être prises en compte dans les charges variables.

L’industrie pétrolière pour rester compétitive se doit d’optimiser ses marges bénéficiaires, ce qui implique une production qui répond aux attentes de plus en plus exigeantes des clients.

I.4 Industrie pétrolière et qualité.

Pour non seulement s’adapter aux exigences de plus en plus fortes de ses clients, mais aussi maximiser ses marges nettes, l’industrie pétrolière s’est engagée dans l’approche « qualité ». L’obtention d’une certification qualité constitue, un point des points de passage important de la démarche.



La démarche « qualité » s’appuie sur des définitions largement admises aujourd’hui et liées au climat d’excédent de l’offre qui caractérise les économies du monde.

D’après Edward DAIMING, « la qualité consiste à fournir exactement au client, le produit qu’il veut, où il le veut, quant il le veut, et au meilleur prix par rapport à la concurrence. La non-qualité survient quand l’une quelconque de ces conditions n’est pas remplie». [ITIL05]

La qualité n’est pas une donné pérenne. Un système de management de la qualité c'est-à-dire un ensemble de pratiques remises en cause en permanence, permettant d’atteindre la qualité du premier coup et au moindre coût, de prouver au client qu’on est organisé pour le faire, et, s’il le demande, lui prouver qu’on l’a effectivement fait, doit être mise en place.

Figure 1 : Roue de Deming sur le management de la qualité.

Appliquées à une raffinerie, ces définitions introduisent la notion de « service au client ». Dans un univers largement dominé par les aspects technico-économiques d’un métier conçu et géré par les ingénieurs pétroliers. Les clients font



vivre la société et leur satisfaction passe par une bonne « Politique de qualité ».

La mise en œuvre d’un système de management de la qualité comporte trois éléments principaux :

Un élément d’ordre « culturel » : la religion du service au client, matérialisé par un réseau de relations client-fournisseur fondées sur une approche contractuelle et suivies à l’aide d’indicateurs chiffrés de satisfaction ou de non satisfaction.

Un élément d’ordre « technologique » : une fonction du progrès qui inclut un système de prévention et de correction des non-qualités révélées par les indicateurs sus-cités et un système de progrès continu pour réduire les coûts d’obtention de cette qualité. Ce système est fondé sur des méthodologies de travail et de traitements des problèmes.

Un élément d’ordre « normatif » : un système formalisé de procédures pour codifier, transmettre et mettre en pratique les résultats des deux précédents éléments et de garantir la traçabilité des produits et services rendus.

La démarche qualité avec son état d’esprit du service au client et parce qu’elle favorise le rapprochement entre le raffinage et les activités en aval de la production, de la distribution et des ventes peut créer une dynamique forte autour de nouvelles niches d’activités tels que l’Informatique.

I.5 L’informatique au service de l’industrie pétrolière.

Le secteur du pétrole est une activité très importante évoluant dans un environnement instable et devant faire face à des défis considérables. Sa valeur actionnariale doit se montrer à la hauteur et le secteur doit maximiser son retour sur investissement. Une étape principale pour atteindre ses



objectifs est la mise en place, pour chacun de ses acteurs, d’un système d’information à la fois maitrisé et en phase avec la donne technologique.

Dans une raffinerie, l’informatique émerge de la philosophie qualité et contribue à optimiser les marges bénéficiaires. Les aspects du traitement automatique de l’information qui sont typiques du raffinage relèvent des domaines suivants :

Automatisation des processus : robotisation et contrôle séquentiel.

Contrôle des processus : fiabilisation des données, contrôle avancé, optimisation.

Système de gestion technique : qualité, gestion informatisée des documents, simulation, maintenance et inspection.

Systèmes d’aide à la décision : bilans matières, mesure des performances techniques et économiques, ordonnancement et programme.

On retrouve également les aspects tels que la gestion de paye, du budget, de la comptabilité et de la communication (réseau) qui ne sont pas typiques du métier du raffinage.

Dans la pratique, l’informatique a un rôle de conseil et d’assistance aux utilisateurs. Elle se charge également de l’exploitation et de la maintenance informatique (équipements et logiciels). Elle étudie et met en œuvre l’amélioration du matériel et des applications. En d’autres termes, le service informatique gère l’informatique et le réseau de télécommunication de la raffinerie, ainsi que leur évolution. Dans une démarche d’amélioration permanente des systèmes et des procédures, Il participe à des projets applicatifs ou d’infrastructures.

Conclusion.



Le pétrole, c'est peut-être de l'or noir, mais brut il ne sert pas à grand-chose. Il doit d'abord subir de nombreuses transformations pour être utilisable. C'est le rôle de la raffinerie, une usine spécialisée dans la préparation de produits pétroliers.

Le souci de qualité est permanent dans l’industrie pétrolière. Des normes et standards internationaux régissent le raffinage dont le métier implique la gestion des données techniques. Cette gestion qui implique de nombreux calculs, lorsqu’elle est manuelle, s’avère fastidieuse ; une gestion numérique lui apporte plus de sécurité de souplesse et de flexibilité. L’informatique s’affirme comme un outil intégrant le système de management de la qualité qui permet également à l’entreprise d’atteindre ses objectifs stratégiques (bénéfices, retour sur investissement). Les processus d’exploitation de la gestion des services informatiques doivent donc être mis au point dans cette optique. La qualité des services informatiques offerts à l’industrie du raffinage est un donc un préalable pour atteindre les objectifs du système de management de la qualité.



CHAPITRE2 : LE SUJET ET SON CONTEXTE

Ce chapitre présente l’écosystème de la structure d’accueil, la pertinence du projet et les résultats attendus.

II.1 La structure d’accueil.

II.1.1 Présentation générale de la SONARA

La société Nationale de Raffinage du Cameroun(SO.NA.RA) est un complexe industriel de raffinerie du pétrole brut. Créé le 23 Mars 1973 et inauguré le 16Mai 1981, son siège social se trouve dans la région du Sud-Ouest, précisément dans le chef lieu du département du Fako : Limbé. Son objectif premier est l’approvisionnement des marchés nationaux en produits de raffinerie. Les produits finis sont aussi exportés vers d’autres pays africains, l’Europe, les Etats Unis d’Amérique et vers l’Amérique du Sud. Le pétrole brut extrait du sous sol Camerounais ou en provenance du Nigéria et de la Guinée Equatoriale voisins est acheminé à la raffinerie par pipeline depuis le point de déchargement sur la jetée, qui s’étend sur environ 500 (cinq cents) m à partir du rivage. Il est stocké dans quatre réservoirs d’une capacité totale de 250.000 (deux cent cinquante mille) m3. La plupart des produits raffinés sont acheminés par pipeline vers la jetée pour le chargement de retour du caboteur2 de Douala et des autres pétroliers occasionnels à destination des marchés étrangers. Une petite quantité des produits raffinés est aussi chargée directement dans les camions-citernes au portique de chargement de la raffinerie. La production globale de la SONARA est actuellement estimée à 2.100 .000 (deux millions cent mille) tonnes/an, pour un chiffre d’affaire de 700.000 .000.000(sept cent milliards) Francs CFA l’année budgétaire écoulée réalisé à partir d’un capital de 23.000 .000 .000 (vingt-trois milliards) Francs

2 Navire à itinéraire unique, généralement le long des côtes.



CFA. Un projet d’extension est en cours pour passer à une production de 3.600 .000(trois millions six cent mille) tonnes/an.

En tant qu’acteur central du secteur pétrolier camerounais, la SONARA a pleinement intégrée la qualité dans ses us et coutumes, ce qui lui a valu d’être récompensé par un Certificat attestant de la conformité de son système de management à la norme ISO9001: 2000 délivré par l’organisme internationale : DET NORSKE VERITAS. Un tel certificat prouve que la raffinerie dispose d’un système de management de la qualité adéquat dont l’efficacité est régulièrement évaluée par un contrôleur indépendant.

Consciente du fait que la qualité n’est pas une donnée pérenne, elle encourage chaque direction, chaque service, chacun de ses 600(six cents) employés à s’investir à fond dans le challenge de la qualité, pour garantir la compétitivité et la pérennité de l’entreprise.

L’un des aspects de la qualité étant la sécurité, la SONARA qui est une usine à feu constant, a également fait de la sécurité à la fois une priorité et une affaire de tous. Elle a également été récompensée à cet effet par le même organisme et attestant de la conformité du système de gestion de la sécurité de la SONARA aux exigences du niveau 8 (huit) du système international d’évaluation de la sécurité (SIES).

II.1.2 Organigramme.

L’organigramme de la SONARA se présente comme suit :



Figure 2 : Organigramme de la SONARA



II.2 Contexte et objectif du sujet.

II.2.1 Le contexte

Comme nous l’avons signifié au chapitre précédent, les organisations du secteur pétrolier dépendent dans une grande mesure de leurs services informatiques et attendent de ces derniers non seulement une aide organisationnelle, mais également de nouvelles options pour réaliser leurs objectifs. De plus, les attentes élevées des utilisateurs quant aux services informatiques ont tendance à évoluer beaucoup avec le temps. Les équipes des services informatiques ne peuvent plus se contenter de s’occuper de la technologie et de leur organisation interne mais doivent à présent tenir compte de la qualité des services qu’ils offrent et mettre l’accent sur les relations avec les utilisateurs finaux : « La fourniture des services informatiques concerne la gestion totale - maintenance et exploitation – de l’infrastructure informatique» [ITIL05].

L’équipe informatique de SONARA, constituée de cinq membres, ne se dérobe pas de ces exigences dans la qualité des services informatiques fournis aux différents corps de métier présent dans la raffinerie.

Aussi, a-t-elle décidé de faire du système d’information de la SONARA :

Un SI efficace, fiable et maîtrisé. Un SI de qualité, et donc orienté service à

l’utilisateur.

L’équipe en charge de la gestion du patrimoine applicatif de la SONARA, est confrontée à des pressions constantes : réduction des coûts, exigences renforcées des utilisateurs, accélération des innovations technologiques, etc. Le maintenir au meilleur niveau est un besoin stratégique pour l’entreprise.



II.2.2 Objectif et motivations du sujet

a. Objectif

A terme, il est attendu de notre travail qu’il fasse évoluer le système d’information de la SONARA pour que son fonctionnement soit en adéquation à la fois avec les exigences et les innovations technologiques. D’où le sujet : « Refonte de la plate forme architecturale du patrimoine applicatif de la SONARA ».

Le sujet s’articule autour de trois axes :

La refonte du progiciel de gestion des données techniques, dénommé « Programme Ordonnancement et Valorisation » (POV) vers une architecture web, client léger ;

La migration des données du serveur Oracle 8 ivers le serveur Oracle 10g.

La consolidation des serveurs de données Oracle 8i, 9i et 10g vers une même architecture physique.

b. Motivations

b.1 Motivations de la refonte de POV.

Le maintien d’une application existante, lorsque cela est possible est en général, la meilleure option lorsqu’une refonte est envisagée. Mais lorsque certaines conditions sont réunies, il devient difficile de s’en contenter. Une refonte totale peut alors s’imposer comme la meilleure option :

o L’application existante, non documentée est devenue difficilement maintenable ;

o L’application en place ne semble plus répondre aux besoins présents et surtout futurs de la SONARA ;

o L’application existante n’est plus maîtrisée par la SONARA et le coût de sa maintenance est jugé excessif.

La refonte de POV vers une architecture web client léger lui apportera plus de commodités. Les traitements s’effectuant



surtout côté serveur, seul le navigateur sera requis pour la machine cliente. Ce qui apportera à la fois une grande souplesse d’administration, impliquera un faible coût d’acquisition (surtout en terme de licences) et une réduction notable du TCO (Total Cost Ownership : coût total de possession).

Option Architecture logicielle

Type de client

Coût Alignement avec les objectifs de qualité

Alignement avec les technologies actuelles

Rapport qualité/Prix

Maintenance évolutive et corrective de l’outil existant

2-tiers lourd Très élevé OUI NON Médiocre

Refonte complète 3-tiers léger élevé OUI OUI Excellent

Figure 3 : tableau comparatif des approches de maintenance et de refonte complète

b.2 Motivations de la migration des données.

La migration des données se justifie par le souci de bénéficier des facilités d’administration et l’optimisation des performances apportées par le serveur de données Oracle 10 g dans sa release 2. Il s’agit de maximiser le ROI (Retour sur Investissement) des licences Oracle acquises par la SONARA, en allant vers une meilleure puissance de traitement et un grand nombre de nouvelles fonctionnalités.

b.3 Motivations de la consolidation des serveurs.

A long terme, la consolidation des serveurs de données, s’inscrit dans le projet de virtualisation3 en cours à la SONARA. A court terme elle permettra d’exploiter judicieusement la licence Oracle valable pour des architectures biprocesseurs bicœurs, acquises par l’entreprise. Elle permettra d’optimiser les Data centers par une meilleure utilisation des ressources matériels et systèmes disponibles. Les bénéfices attendus sont :

3 Ce projet procède des soucis de réduction du nombre de machines physiques et d’optimisation de l’utilisation des ressources matérielles acquises.



Optimiser la charge de travail en fonction des ressources physiques et virtuelles disponibles ;

Mettre en phase les ressources avec leur utilisation ; Rationaliser et optimiser le parc des serveurs ; Optimiser la sécurité ; Garantir le retour sur investissement.

II.3. Problématique et intérêt.II.3.1 Problématique

Pour atteindre les objectifs visés par notre travail, nous devrons répondre aux interrogations suivantes:

Quelle méthode adopter pour cette démarche qualité ?

En effet, « La qualité est l’ensemble des caractéristiques d’un produit ou service qui lui confèrent l’aptitude à satisfaire des besoins exprimés ou implicites (ISO 8402) » [ITIL05]. Et la SONARA en a fait un leitmotiv. Il s’agit donc, de refondre le Système d’Information de la SONARA à travers son patrimoine applicatif vers une architecture lui permettant de jouer pleinement son rôle dans la politique qualité de la raffinerie. Les méthodes connues étant principalement orientées pour la réalisation d’application, nous devrons opter pour une démarche projet intégrant les trois aspects de notre travail.

Quelle est l’orchestration des processus métier impliqués dans notre travail ?

En effet, le logiciel POV à refondre est utilisé par la Direction Technique, les Services Commerciaux et la Direction Financière. Il y a donc circulation de l’information entre ces différents corps de métiers. Et il est important, pour avoir un produit optimal de maitriser l’orchestration des processus impliqués.

Quelle architecture logicielle adopter pour POV-cible ?



Une fois les processus maitrisés, il convient d’opter pour la meilleure architecture possible pour notre outil logiciel d’entreprise.

Pour quelle stratégie et pour quel mode de migration des données opter?

En effet, il sera impératif d’adopter une stratégie de migration qui prenne en compte la criticité dans la disponibilité des données. Le mode de migration quand à lui sera dicté par la structure des données à migrer.

Quelle stratégie de consolidation adopter ?

En effet, en fonction des spécificités des plates formes matérielles, des SGBD à faire cohabiter, et du Système d’Exploitation hôte, nous devrons définir un mode opératoire pour la consolidation des serveurs de données.

Quelle démarche adopter pour s’assurer que notre travail aura répondu aux attentes fondées en lui ?

En effet, il sera utile de prouver par des indicateurs de performance que le patrimoine applicatif de la SONARA et partant son SI est mieux à même de remplir pleinement sa part dans la politique qualité de la raffinerie.

II.3.2 Intérêts

La refonte de la plate forme architecturale du patrimoine applicatif permettra :

A l’équipe informatique d’avoir la maitrise du SI de l’entreprise,

Aux utilisateurs d’avoir des outils répondant à leurs attentes,

Au management d’avoir une meilleure vision du rôle de l’informatique,

A la SONARA de poursuivre sa route vers l’excellence en terme de qualité.




PARTIE II : METHODE DE CONDUITE DU PROJET ET

ARCHITECTURES ORIENTEES SERVICES.


CHAPITRE 3 : LA MÉTHODE DE CONDUITE DU PROJET.

Ce chapitre insiste sur la nécessité de l’adoption d’une démarche permettant d’atteindre les objectifs attendus du projet et présente la démarche de conduite du projet adoptée.

III.1. De la conduite de projet informatique

Un projet est un effort temporaire dont le coût est estimé et exercé dans le but de créer un produit, un service ou un résultat unique [PMBOK07]. La fin est atteinte lorsque les objectifs du projet sont remplis, ou lorsque le projet est arrêté parce que ses objectifs ne seront pas atteints ou ne peuvent plus l’être, ou lorsque le projet n’est plus utile. Deux aspects importants dans le management projet sont d’une part, la prise en compte de la qualité : « Aptitude à satisfaire aux besoins des utilisateurs » et le management du changement [PMBOK07] d’autre part. Ces deux aspects peuvent servir de jauge discriminatoire lors de l’adoption de la démarche projet.

Notre travail comme nous l’avons souligné au second chapitre, s’articule sur trois aspects. On a donc affaire à trois projets réunis en un et nous devons adopter une démarche projet permettant de tous les gérer. D’autre part, notre tâche n’est pas isolée, elle s’inscrit dans un projet plus large de mise en adéquation du système d’information avec la vision stratégique de l’entreprise. Aussi, avons-nous pris en compte la suggestion d’Alistair COCKBURN de choisir la méthode qui s’aligne le mieux à la nature du projet, de l’équipe et à la culture organisationnelle [MANIF01] et proposé une méthodologie de gestion de projets qui a été validée par l’équipe informatique. C’est cette méthodologie que nous allons suivre dans chacun des sous-projets que nous gérons



dans le cadre de ce stage. Elle est structurée selon la Structure de Découpage de Projet (SDP) ci-dessous.

Figure 4: SDP de conduite du projet.

Loin d’être un enchainement séquentiel de tâches à accomplir, cette SDP décrit un ensemble de lots d’activités à mener pour la réussite de notre projet.

Le lot « gestion de projet » :

Il englobe toutes les activités de gestion du projet. Précisément celles liées au management de la communication. Il s’agit enfin de documenter ces activités.

Le lot « exigences »:

Il regroupe les activités liées à la définition et à la documentation des besoins des parties prenantes nécessaires pour atteindre les objectifs du projet.

Le lot « Vision » :



Il s’agit de l’ensemble des activités définissant la vision que l’équipe projet a du contenu projet et à la conception de la solution.

Le lot « Planification initiale » :

Il s’agit de toutes les activités liées au management du contenu et de la qualité du produit pour s’assurer que toutes les activités menées concourent à l’atteinte des objectifs.

Le lot « Conception détaillée et développement » :

Il s’agit de toutes les activités liées à la proposition et à la documentation d’une solution qui sera testée dans un environnement de développement.

Le lot « déploiement et support » :

Ce lot d’activités concerne les tâches de mise en production de la solution.

La structure de découpage de projet ci-dessus impose un choix de stratégie de conduite du projet qui l’implémente pour chacun de nos trois(3) sous-projets. Ce choix passe par une bonne maîtrise de différentes méthodes affirmées et éprouvées.

III.2 Principales méthodes de développement logiciel

Lorsqu’on observe l’évolution des projets informatiques, les outils qui ont le plus changé ces dernières années, ce sont les méthodes employées pour réaliser les projets Ces méthodes permettent d’organiser les façons de travailler, d’organiser les rôles des parties prenantes, de planifier les étapes du processus de développement. Les besoins de changement des méthodes de conception de la solution au problème posé se font de plus en plus sentir auprès des utilisateurs qui, par le passé, voyaient leurs projets jamais aboutis voir jamais livrés.



Il est donc opportun de faire une étude des diverses méthodes d’usage afin d’en sortir ou de construire celle qui correspondra à notre projet.

III.2.1 Les méthodes séquentielles ou méthodes en cascade

Décrit en 1970 par Winston W. ROYCE [ROYCE70] le modèle de développement en cascade prône le découpage du projet en phases distinctes selon le principe du non-retour. Il propose au fur et à mesure une démarche de réduction des risques, en minimisant à chaque fois l’impact des incertitudes. L’exclusion de l’utilisateur dès la phase de conception pour le ré-inclure en fin de projet lors du contrôle de qualité fait courir le risque de voir la recette finale rejetée. Ces méthodes sont adaptées aux projets de petite taille.

III.2.2 Les méthodes dynamiques objet

Elles sont basées sur la séparation de l’étude de l’architecture et de l’étude fonctionnelle afin de paralléliser au maximum les tâches. Procédant par itération, elles sont conformes à l’approche objet et permettent de prendre en compte très tôt les problèmes d’architecture.

III.2.3 Les méthodes dynamiques agiles

Les méthodes agiles sont basées sur le principe de permettre aux utilisateurs de bénéficier des mises en œuvre dans les délais maîtrisés, en leur donnant la possibilité de suivre toutes les étapes du développement. Ce qui leur permet d’avoir un résultat concret issu d’un développement qui fournit des morceaux du logiciel dans les brefs délais contrôlés. Les méthodes agiles sont une nouvelle façon de concevoir les projets informatiques en liaison directe avec les utilisateurs. Elles favorisent l’assurance qualité et le management du



changement. Les besoins exprimés par le client ne sont pas figés dès le départ du projet et l’équipe de développement peut réagir directement aux changements de point de vue de l’utilisateur final qui découvre au fur et à mesure, les possibilités des techniques utilisées.

Les méthodes agiles garantissent donc :

Une implication active des utilisateurs Une livraison fréquente des produits Une livraison des éléments fonctionnels en temps voulu Des modifications réversibles Une forte collaboration et une très bonne coopération Des tests intégrés.

Méthode Agile de gestion de projet informatique adaptée aux équipes réduites avec des besoins changeants l’eXtreme Programming (XP) sera notre démarche dans le cadre du premier axe de ce projet : celui de la refonte de POV.

III.3 Méthodes de migration des données Oracle.

Les entreprises produisent et consomment toujours de plus en plus de données. De ce fait, si la gestion de ces données est devenue hautement stratégique, elle n’en demeure pas moins de plus en plus complexe. Aussi, les équipes en charge des données doivent-elles faire face à de nouvelles problématiques et repenser leur stockage en intégrant notamment des impératifs de sécurité et de disponibilités des données.

La migration de données désigne le processus de transfert de volumes de données d’un système existant vers un nouveau système. Elle peut être un processus complexe, coûteux et long. Il peut également y avoir des effets au niveau de la gestion de l’entreprise, il est donc important d’adopter une



démarche de migration adaptée au problème à résoudre et aux outils impliqués.

Oracle offre un ensemble de services de migration à ces partenaires et clients pour les aider à optimiser l’utilisation de ses technologies. Ces services comprennent un référentiel des meilleures pratiques, des outils et de la documentation.

III.3.1 La migration par l’exportation et l’importation des données

Chaque version du serveur de données Oracle dispose d’outils permettant d’importer et/ou d’exporter les données d’une base de données à une autre. Cette solution s’impose lorsqu’on veut migrer tout ou partie4 de la base de données en conservant la version initiale de la base.

III.3.2 La migration par la mise à niveau de la base de données

Depuis sa version 8, un outil nommé Database Upgrade Assistant (DBUA) est intégré à toutes les distributions du serveur de données Oracle permettant de mettre à niveau une base de données vers une version ultérieure. Cette méthode est adaptée lorsqu’on veut migrer toute la base de données vers la nouvelle version du logiciel de gestion des bases de données sans conserver la version héritée sur l’ancienne version. La version du logiciel de gestion des bases de données vers laquelle on veut migrer et celle de laquelle on migre restent toutes les deux disponibles sur le serveur.

III.3.3 La migration par la mise à niveau du serveur de données

Il arrive parfois qu’on veuille carrément passer d’une version du logiciel du serveur de données à une version ultérieure en conservant les bases de données existantes. Dans

4 Objet de la base de données, schéma utilisateur, espace disque logique



ce cas, il s’agit d’appliquer le patch adéquat à la version existante sans avoir à refaire le processus d’installation.

III.3.4 La migration des sources de données hétérogènes.

Lorsqu’il est besoin de migrer des données issues des sources SGBD non-Oracle tels que Informix, Microsoft SQL Server, MYSQL, Sybase, DB2 ou Microsoft Access vers une base de données Oracle, des outils d’aide à la migration tels que Oracle SQL Developer Migrations, Oracle Migration Workbench sont proposés5. Lorsque la source est un fichier plat ou un fichier issue d’un tableur, on peut faire appel à Oracle SQL*Loader.

III.4 Méthodes de consolidation des serveurs de données Oracle.

Le besoin d'accroître la productivité des entreprises impose de trouver de nouvelles solutions de gestion de plus en plus complètes et complexes. Ceci se traduit par l'hétérogénéité d'un parc informatique, aux plans du matériel, des systèmes d'exploitation et des systèmes de gestion de bases de données, et donc par une productivité dégradée. Il devient indispensable de rationaliser cet ensemble en l'inscrivant dans un plan de restructuration autour d'un axe majeur : la consolidation.

La consolidation doit pouvoir répondre aux problématiques suivantes :

la prolifération des serveurs (perte de place) l'éparpillement des données le coût d'acquisition et d'exploitation de serveurs

(TCO)

5 L’outil Oracle SQL Developer Migrations implémente les fonctionnalités d’Oracle Migration Workbench.



Les solutions actuelles à ces problèmes sont orientées Systèmes d’Exploitation. Ce qui est naturel puisqu’un SGBD quel qu’il soit est un programme système [MOUK06]. Précisément, la consolidation des Systèmes d’Exploitation induit la consolidation des serveurs de données qui y sont abrités.

III.4.1 La consolidation physique

Elle consiste en la concentration de serveurs au sein d'un même châssis physique. Ces serveurs appelés lames partagent alors certains éléments physiques comme les alimentations, ventilateurs, switchs. Cette technique permet le partitionnement du châssis, l'intégration de multiples systèmes d'exploitation et la gestion centralisée des ressources. On installera donc un serveur de données par lame.

Elle permet de répondre principalement aux problématiques de mutualisation des disques et des sauvegardes mais pas nécessairement à la problématique de prolifération des serveurs. Nous ne la préconiserons pas pour le cas de la SONARA.


Oracle 9i Oracle 9i


Figure 5 : La machine HP Integrity implémentant la consolidation physique.

III.4.2 La consolidation de fichiers

Cette technique permet la rationalisation des structures de stockage de fichiers ainsi que les accès idoines. Les technologies liées aux fichiers permettent d'accroître l'accès à ces derniers tout en limitant les flux sur le réseau.

Elle ne répond pas directement aux problématiques liées à la consolidation mais peut améliorer grandement la gestion des données au sein d'un système d'information.



Figure 6: Exemple d’utilisation d’un serveur de fichiers.

III.4.3 La Virtualisation

Cette technologie permet de consolider plusieurs serveurs physiques sous une forme plus homogène sur un nombre nettement plus restreint de machines physiques. Cette approche permet un partitionnement et un cloisonnement des systèmes hébergés accroissant par là même les niveaux de fiabilité et de sécurité. L'administration et l'exploitation se retrouvent simplifiées car centralisées. La gestion de la croissance du SI n'est pas un problème du fait de l'évolutivité de la solution.

Elle est utilisée pour pérenniser ou optimiser l’existant et permet de faire fonctionner des systèmes (WindowsNT ou OS /2) que plus aucun matériel ne prend en charge.

Elle permet de répondre globalement à toutes les problématiques liées à l'évolution des systèmes d'information. C’est la solution optimale que nous préconisons à la SONARA.



Figure 7 : Exemple de Virtualisation

Avec cette option, chaque SGBD sera installé sur une machine virtuelle différente sur le même serveur physique. On aura alors l’impression d’avoir plusieurs serveurs physiques abritant chacun un SGBD.

La réflexion sur la virtualisation des systèmes d’Exploitation, n’est pas du ressort de notre travail. Elle fait d’ailleurs l’objet d’un projet en gestation au sein du service informatique de la SONARA.

En attendant l’implémentation de la virtualisation à la SONARA, nous proposerons une solution palliative que nous appellerons consolidation logique par analogie à la consolidation physique.

III.4.4 La consolidation logique

Nous entendons par consolidation logique de données, une cohabitation de plusieurs serveurs de données qui



n’implique qu’une seule composante de l’architecture du système d’Information : les serveurs de données. Chaque éditeur de logiciel de gestion de bases de données propose à ses clients et partenaires des normes, des outils et des méthodes pour une cohabitation harmonieuse et sans heurt des versions différentes de leur SGBD sur une même plate forme (matérielle et système). Dans cette option de consolidation, les versions du SGBD partagent le même système d’exploitation hôte et/ou les mêmes unités de stockage. Depuis la release 8.0.4, Oracle a mis sur pied la norme OFA (Optimal Flexible Architecture) dont l’implémentation correcte facilite la cohabitation de versions différentes de son serveur de données.

Conclusion

L’une des tâches critiques de résolution de problème est l’adoption d’une démarche, d’une stratégie. Cette étape est d’autant plus importante qu’elle conditionne à elle seule la réussite ou l’échec du projet. Dans le cadre de la gestion du projet de refonte de la plate forme architecturale de la SONARA, nous devions opter pour une démarche permettant de gérer à la fois la qualité et le changement. Une démarche a été mise sur pied en s’inspirant des normes PMBOK6. Elle implique l’adoption d’une méthode projet cadrant avec les exigences et le contexte. Les méthodes étant des canevas de travail, l’adoption d’une démarche passe par une bonne connaissance des meilleures pratiques connues et éprouvées. Nous avons présenté un ensemble de bonnes pratiques relatives à chacun des trois aspects de notre travail. Elles serviront de base pour la résolution du problème qui nous a été posé.

6 Project Management Body Of Knowledge est un reférentiel de meilleures pratiques en termes de management de projet.



CHAPITRE 4 : L’EXTREME PROGRAMMING

Ce chapitre présente la méthode agile eXtreme Programming qui nous permettra d’implémenter la démarche de conduite de projet adoptée dans le cadre de ce projet précisément en ce qui concerne la refonte de POV vers une architecture web.

IV.1 La méthode eXtreme Programming

IV.1.1 Présentation

Inventé par KENT BECK, WARD CUNNINGHAM et RON JEFFRIES pendant leur travail sur un projet « C3 » de calcul des rémunérations pour la société Chrysler7. L'eXtreme Programming (XP) repose sur des cycles rapides de développement (des itérations de quelques semaines) dont les étapes sont les suivantes :

Une phase d'exploration détermine les scénarios clients qui seront fournis pendant cette itération ;

Une phase de planification au cours de laquelle, l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels

Une phase de production pendant laquelle chaque développeur s'attribue des tâches et les réalise c’est ici qu’on produit la documentation nécessaire (documentation du système, documentation des opérations, documentation du support et manuel utilisateur).

Lorsque tous les tests fonctionnels passent, le produit est livré c’est la phase de maintenance.

Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cycle de la première 7 Chrysler Comprehensive Compensation



livraison se caractérise par sa durée et le volume important de fonctionnalités embarquées. Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par exemple).

Figure 8: Cycle de développement XP

XP s'appuie sur Treize Pratiques ainsi que sur le respect de Quatre Valeurs essentielles [BECK00] qui se décline en cinq principes de base.

IV.1.2 Les quatre valeurs

« Nous aurons réussis lorsque nous aurons un style de développement mettant en lumière un ensemble de valeurs servant tant les besoins personnels que professionnels… Sans ces valeurs, l’homme aura toujours tendance à revenir sur ses seuls intérêts personnels à court-terme » : K. Beck [BECK00]

La communication :

La première valeur de XP est la communication. Les problèmes surviennent généralement dans les projets parce ce que personne n’informe personne d’importantes décisions



prises. L’effet des tests unitaires, de la programmation en pair et de l’estimation de tâches est simple : le développeur, le chef de projet et l’utilisateur sont appelés à communiquer. Il peut être utile d’avoir un coach XP pour chaque projet dont l’une des tâches sera de noter et de réduire les tares de communication entre les parties prenantes.

La simplicité :

La seconde valeur de XP est la simplicité. Il s’agit de toujours se poser la question : « quel est le moyen le plus simple de produire le résultat attendu ? » Il s’agit d’un pari. XP fait le pari qu’il est mieux de produire quelque chose de simple aujourd’hui et de devoir fournir un peu plus d’efforts pour la modifier le cas échéant, au lieu de produire quelque chose de plus compliqué aujourd’hui qui pourrait ne jamais être utilisée.

Le feedback :

C’est la troisième valeur de XP. Elle est piloté par les phrases suivantes : « Ne me demandez rien, demandez au système » ; « Avez-vous déjà apprêté vos scénarios de test pour cela ? » Il s’agit de prouver que le meilleur modèle est le résultat du code en planifiant l’implémentation et la mise en production très tôt des scénarii les plus précieux. L’objectif étant de permettre à l’entreprise de commencer assez tôt à ressentir le fonctionnement du système et de définir les actions permettant de l’optimiser.

Le courage :

Quatrième et dernière valeur de XP, le courage est la faculté pour l’équipe d’assumer ces choix. Elle doit être capable de remettre en cause l’architecture le cas échéant. C’est aussi avoir le courage de laisser tomber une tâche8 qui paraît difficile pour passer à une autre et pouvoir revenir sur la première lorsqu’on se sent plus inspiré[BECK00].

8 Daimler Chrysler



Les valeurs ci-dessus énumérées sont très vagues. Elles se déclinent de manière beaucoup plus concrète en principes de base.

IV.1.3 Les principes de base

XP énumère cinq principes de base pour aider lorsqu’un choix d’alternative s’impose. L’alternative vérifiant le mieux ces principes sera plébiscitée.

Feedback rapideIl s’agit d’avoir le feedback et d’effectuer les modifications

éventuelles sur le système le plus tôt possible.

Simplicité assuméeIl s’agit de résoudre les problèmes ponctuels le plus

simplement possible en faisant confiance à la faculté de l’équipe à ajouter de la complexité plus tard en cas de besoin.

Modification incrémentaleIl s’agit de résoudre chaque problème par une série de

petits changements. La conception changera alors très peu entre deux itérations. La planification changera très peu entre deux itérations. L’équipe projet changera très peu entre deux itérations. L’adoption même de la démarche projet doit se faire en petites étapes successives.

Management du changementIl s’agit de trouver une stratégie permettant de préserver

les acquis tout en essayant de résoudre le problème le plus pressant.

Gestion de la qualité



Il s’agit de trouver une stratégie permettant d’organiser le travail pour produire le résultat attendu.

IV.1.4 Les Treize Pratiques

Client sur le Site (On-Site Customer) : Pour une meilleure communication, le client et les développeurs travaillent dans le même espace autant que possible.

Séance de Planification (Planning Game) : Le client définit les scénarios utilisateurs prioritaires. Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-jacentes, estiment ces tâches et y souscrivent.

Intégration Continue (Continuous Integration) : Le système est intégralement assemblé et testé une à plusieurs fois par jour.

Livraisons Fréquentes (Frequent Releases) : Le rythme des livraisons est de l'ordre de quelques semaines.

Rythme Soutenable (Forty-hour Week) : L'équipe ne fait pas d'heures supplémentaires deux semaines de suite.

Tests de Recette (Acceptance Tests) : Retour d'information rapide sur le système, en général automatisé, constitué à partir de critères de tests définis par le client.

Tests Unitaires (Unit Tests) : Tests automatisés écrits pour chaque classe, chaque méthode, et pour tout "ce qui pourrait casser" en général. Ces tests doivent passer à 100 % continuellement.

Conception Simple (Simple Design) : Le code doit passer tous les tests et répondre aux critères de maintenabilité : concision, modularité, cohérence, lisibilité.

Métaphore(Metaphor) : Une analogie utilisée comme modèle conceptuel du système en cours de développement.



Remaniement Continu ou Refactorisation de Code pratiquée sans relâche : modification du code par laquelle on améliore sa conception sans en modifier le comportement.

Convention de Code (Coding Standard) : Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe.

Programmation En Binome (Pair Programming) : Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.

Propriété Collective du Code (Collective Code Ownership) : Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir.

Comme on vient de le voir, XP est une méthode de développement originale. Elle repose sur des techniques connues pour la plupart depuis bien longtemps - les tests unitaires, la revue de code, ... Elle se distingue d'autres méthodes parce que le nombre de pratiques sur lesquelles elle repose est limité mais que leur mise en œuvre est systématique, voire extrême. Ce qui surprend au premier abord, c'est qu'elle fait fi d'autres pratiques et non des moindres -modélisation, documentation, ... Pourquoi ? Parce que l'idéologie de XP est simple : il s'agit de faire tout ce qui est utile pour réussir son projet, mais rien que ce qui est utile.

La modélisation permettant de communiquer et échanger des points de vue afin d’avoir une compréhension commune et précise d’un même problème. Elle cadre bien avec la première valeur de XP qu’est la communication. Car comme on a coutume de l’entendre : « un dessin vaut mieux qu’un beau discours »



IV.2 UML comme outil de modélisation.

De même qu'il vaut mieux dessiner une maison avant de la construire, il vaut mieux modéliser un système avant de le réaliser. La méthode agile eXtreme Programming préconise de faire plusieurs modèles en utilisant dans la mesure du possible des outils différents. Dans le cadre de la refonte de POV, nous avons opté pour le formalisme de l’Unified Modeling Language pour la modélisation du système à mettre en œuvre.

UML nous permettra de :

o Obtenir une modélisation de très haut niveau indépendante des langages et des environnements.

o Faire collaborer des participants de tout horizon autour d'un même document de synthèse par son aspect visuel.

o Mieux documenter notre projet.

IV.3 Un mot sur le couplage UML-XP

Les termes « UML » et « Méthodes agiles » sont deux termes à la mode dans le domaine du développement des projets informatiques. S’il est acquis que le second, décrit un ensemble de meilleures pratiques qu’on doit appliquer aux méthodes et outils existants pour produire des résultats de qualité, le premier peut être utilisé tant de manière agile que de manière non agile [AMBER07]. Dans l’optique d’un couplage avec XP, les règles suivantes doivent être suivies :

Les modèles doivent être simples Utiliser des outils les plus simples N’utiliser que les modèles utiles et qui présentent une

valeur claire pour notre processus.

A la place des CRC9 cards on utilisera :

Diagramme de classe9 Surtout lors du codage et des configurations.



Diagrammes d’interactions (séquence et/ou collaboration)

A la place des user-stories (scénarii utilisateur).

Diagramme des cas d’utilisation.Diagramme de séquence

Pour la modélisation métier

Diagramme d’activitéDiagramme d’états transitions.

Pour la métaphore du système :

Diagramme de déploiement [ROQUES07].

Conclusion

Très répandue pour le développement de logiciels critiques10, la pratique agile XP consiste à remanier le code existant dans un souci permanent de simplicité et de qualité. Elle est adaptée aux projets à équipe réduite et permet notamment, par des transformations microscopiques et successives, de faire apparaître progressivement l’architecture recherchée. Par contre cette pratique doit être adaptée pour répondre au formalisme requis pour une documentation de qualité. Le langage UML de part son caractère graphique et visuel est parfaitement compatible avec cette pratique.

10 Class Responsibility Collaborator



CHAPITRE 5 : LES ARCHITECTURES ORIENTÉES SERVICES ET LEUR MODÉLISATION PAR SOAML.

L’une des contraintes dans la refonte de POV exige une architecture sécurisée et adaptée à la nouvelle donne technologique. Le chapitre présente une façon d’organiser et de comprendre un système qui maximise l’interopérabilité, la réutilisabilité, la flexibilité et l’agilité. Un regard sera jeté sur la modélisation d’une telle organisation.

“A hundred years ago, companies stopped generating their own power with steam engines and dynamos and plugged into the newly built electric grid…Today, a similar revolution is under way.” NICOLAS CARR11

V.1 Les architectures Orientées Services

Les architectures Orientées Services notée SOA pour l’anglicisme Services Oriented Architecture sont à la fois une architecture et une philosophie logicielle s’appuyant sur un ensemble de services simples. Leur objectif est de décomposer une fonctionnalité en un ensemble de fonctions basiques appelées services, fournies par des composants réutilisables et interopérables et de décrire le schéma d’interactions de ces services. L’idée sous jacentes est de cesser de construire la vie de l’entreprise autour des applications hétérogènes pour faire en sorte de construire une architecture logicielle globale décomposée en services correspondant aux processus métiers de l’entreprise.

La SOA est une approche client-serveur de conception d’applications qui consiste en des fournisseurs, des consommateurs et des contrats de services dans un souci de 11 Ces applications sont utilisées dans l'avionique, le médical, le ferroviaire, le nucléaire et l'automobile



réutilisabilité et d’interopérabilité. Sa particularité est le couplage faible.

V.1.1 Notion de services.

Quotidiennement, nous voyons les services comme quelque chose de disponible. Lorsqu’ on est malade, on a recourt aux services d’un médecin, si le robinet coule en permanence on pourra compter sur ceux d’un plombier, l’éducation de nos enfants dépend des services des enseignants, etc. Si les services mettent à notre portée tout ce qui est imaginable, ils exhibent un modèle d’interactions simple et spécifique. Lorsqu’un consommateur fait une requête à un fournisseur pour que quelque chose lui soit fait, le fournisseur rend un service en exécutant cette requête. Les services au niveau de SOA sont similaires à cette approche de services rencontrée dans la vie quotidienne.

Un service est une offre d’expertise par une interface bien définie et disponible pour la communauté. Le service aboutit à un travail exercé par l’un pour l’intérêt des autres.

Un service SOA est un ensemble de tâches fonctionnelles ou techniques numériquement accomplies par des modules applicatifs. De manière grossière, un service est une encapsulation des données et de la logique métier. Il consiste en une interface, possède une implémentation et expose un comportement prédéfini.

Plusieurs services peuvent être composés pour créer un service plus large.

L’interface du service défini un ensemble d’opérations présentant ses capacités. Les opérations sont les tâches que le service peut effectuer.



SOA est donc un paradigme architectural définissant comment les personnes, les organisations et les systèmes informatiques fournissent et consomment des services pour atteindre leurs objectifs.

Figure 9: Concepts de la SOA

Dans un environnement SOA, une application est un ensemble de services qui dialoguent entre eux par des messages. La communication peut aussi bien être asynchrone que synchrone.

Un service peut :

Etre codé dans n’importe quel langage. S’exécuter sur n’importe quelle plate forme (matérielle et

logicielle)

Un service doit :

Offrir un ensemble d’opérations dont les interfaces sont publiées.

Etre autonome. Respecter un ensemble de contrats. Correspondre aux processus métiers et fonctions

mutualisables au niveau de l’entreprise afin d’aligner



l’informatique aux changements de décisions stratégiques et tactiques.

V.1.2 les impacts de la SOA.

Une architecture SOA induit l’alignement des référentiels de l’entreprise. Dans le cadre du déroulement d’un processus métier, elle permet de fluidifier la communication. L’architecture décrite par la SOA peut aussi bien être une architecture logicielle, une architecture d’entreprise, une architecture métier ou une architecture organisationnelle.

Architecture logicielle ou applicative : elle décrit la manière dont sont utilisés les services par d’autres applications et ou composants logiciels.

Architecture d’entreprise : c’est une urbanisation des applications standards d’entreprise en les organisant en composants spécifiques permettant de gérer et de manager les services.

Architecture métier : la manière dont sont gérées ou modifiées les activités métiers.

Architecture organisationnelle : il s’agit de la répartition des rôles et des responsabilités se rapportant aux activités liées à la SOA.

La SOA n’est pas un produit qui se vend sur le marché, une meilleure réussite de la SOA passe par une prise en compte de tous ces aspects c'est-à-dire :

Faire de la vision SOA une vision partagée au niveau de l’entreprise en général et de l’équipe informatique en particulier.

Définir une stratégie de management du changement. Définir clairement les tâches, rôles et responsabilités.

V.2 Les web services.



Un service web est un programme informatique permettant la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

Il s'agit d'un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et pour des applications ou machines, sans intervention humaine, et en temps réel.

Dans sa présentation la plus générale, un service web se concrétise par un agent, réalisé selon une technologie informatique précise, par un fournisseur du service. Un demandeur, à l'aide d'un agent de requête, utilise ce service. Fournisseur et demandeur partagent une même sémantique du service web, tandis qu’agent et agent de requête partagent une même description du service pour coordonner les messages qu'ils échangent.

Il plusieurs technologies soutendent le terme services web :

V.2.1 Les services web de type REST

REST12 (Representational State Transfer) est un style architectural destiné à la communication entre machines. C’est le style architectural original du Web.

L'architecture du Web remplace les concepts applicatifs clients et serveurs par les concepts agents utilisateurs et agents ressources. Des agents interagissent avec des ressources pour créer, accéder, modifier ou supprimer une ressource. Il s’agit surtout de l'interaction entre agents utilisateurs, principalement les navigateurs avec les ressources

Les services web de type REST exposent entièrement leurs fonctionnalités comme un ensemble de ressources (URI) identifiables et accessibles par la syntaxe et la sémantique du protocole HTTP. Ils traitent d'agents ressources là où le mode

12 Converting Software products into services.



opératoire classique du Web parle d'agents utilisateurs. Il y a donc une interaction entre agents ressources ; c'est-à-dire une relation entre les ressources : une ressource devient l'agent d'une autre ressource, mais reste elle-même une ressource accessible par d'autres agents.

V.2.2 Les web services WS.

Les Services Web WS-* exposent leurs fonctionnalités sous la forme de services exécutables à distance. Leurs spécifications reposent sur les standards UDDI, SOAP et WSDL pour transformer les problématiques d'intégration héritées du monde Middleware en objectif d'interopérabilité.

Pour utiliser un Web Service WS, il faut premièrement savoir qu'il existe. UDDI (Universal Description, Discovery and Integration Service) est la norme qui définit le mécanisme pour découvrir dynamiquement des services. Un client pointe vers un annuaire UDDI, qui lui donnera la définition du service recherché. Le registraire UDDI sert de pages jaunes et liste les services disponibles.

Le registraire UDDI est lui-même un Web Service qu'un client peut questionner.

Pour être capable d'utiliser un Web Services et de programmer un client, il est nécessaire d'en connaître la définition. Le langage WSDL (Web Services Definition Language) décrit l'interface du service. En utilisant un schema XML, WSDL défini les paramètres d'entrée et de retour d'un appel au service Web.

WSDL est un langage balistique, il décrit qu'est-ce que le service Web, où le trouver et comment l'appeler.



Les appels aux Web Services sont effectués avec le protocole SOAP (Simple Object Access Protocol). SOAP offre le transport d'objets sérialisés et autres données en XML et l'appel de procédures distantes.

Le concept de base de SOAP est l'enveloppe (balise Envelope) qui est subdivisé en deux parties :

- L'entête (balise Header) qui est facultative et qui peut contenir les informations d'authentification, de sécurité (chiffrement, certificats, billets de sessions, etc.). Elle peut contenir d'autres directives qui règlementent les appels et messages.

- Le corps (balise Body) qui est obligatoire et contient l'information sur l'appel de la procédure distante ou sur le message XML envoyé.

UDDI, WSDL et SOAP sont les trois normes principales des Web Services. Les normes UDDI sont proposées par OASIS. WSDL et SOAP font parties des normes W3C.

Figure 10: Les web services



Lorsqu’une architecture orientés services est implémentée via des services web on parle de WSOA (Web services oriented Architecture). Une bonne implémentation des architectures orientées services passe par une excellente conception, une modélisation de qualité et une véritable culture SOA au sein de l’entreprise en général et de l’équipe informatique en particulier.

V.3 La démarche SOA au niveau du SI.

Mises à part de rares exceptions, les systèmes d’information sont composés de blocs applicatifs hétérogènes tant du point de vue fonctionnel, technologique qu’organisationnel. L’interopérabilité apparaît donc comme une nécessité majeure. Face à cette nécessité deux approches sont opposées, l’approche légaliste et l’approche organique.

V.3.1 L’approche légaliste « top down ».

La vision de l’approche légaliste est la suivante :

Le SI est un « super bloc applicatif ». Le SI peut être appréhendé de manière globale. Les services sont identifiés a priori à partir d’une

démarche de cartographie globale (processus, applications, flux…).

Les services sont identifiés sur le périmètre global du SI.



Figure 11: Approche top down.

V.3.2 L’approche organique « Bottom Up»

Dans l’approche organique :

Le SI est constitué de blocs applicatifs autonomes et hétérogènes.

Le SI est appréhendé bloc applicatif par bloc applicatif. Les services sont identifiés à partir des besoins projets. Les services sont identifiés sur le périmètre de

Communication du bloc applicatif.

Figure 12: approche bottom up

Compte tenu du caractère agile de la démarche adoptée et de la jeunesse du SI de la SONARA en matière de SOA,



l’approche bottom-up s’impose comme étant la meilleure non seulement dans le cadre de ce projet, mais encore pour l’urbanisation du SI tout entier.

Il n’est pas rare de voir des pans entiers de traitements, implémentés il y a quelques décennies à peine, dont on a perdu toute la connaissance, jusqu’à ne plus savoir ce qu’ils font et pire s’ils sont encore utilisés ! Afin d’éviter que de telles erreurs se reproduisent, il est conseillé de bien documenter chaque service mais aussi et surtout de documenter leurs utilisations.

Une documentation est faite pour être consultée. Pour être bien comprise, elle doit être écrite dans un langage compris de tous et de préférence graphique et visuel. UML offre une extension permettant de répondre à cette exigence.

V.4. SOAML pour la modélisation en environnements Orientés Services.V.4 .1 Présentation de SOAML

Depuis le mois de Janvier 2009, Services Oriented Application Modeling Language (SOAML) est une spécification de l'Object Management Group (OMG), qui fournit un métamodèle pour la conception de services au sein d'une architecture orientée services. La spécification étend Unified Modeling Language (UML2.0), permettant ainsi une approche visuelle et sémantiquement rigoureuse pour la définition des services. Le profil UML pour SOAML présente de l'intérêt pour les analystes métier, les architectes et les promoteurs tout au long du processus d'établissement d'une architecture orientée services. SOAML comprend des spécifications sur les systèmes de services, les interfaces de services individuels, et les implémentations de services.

L'objectif de SOAML est de fournir aux utilisateurs de UML un moyen de modéliser les concepts de base d'une architecture



orientée services, c'est-à-dire les notions de consommateur de services, fournisseur de services, et contrat de services. L'autre objectif majeur de la spécification est de ne pas imposer une méthodologie de modélisation particulière13

V.4.2 Un mot sur les spécifications SOAML.

Trois approches possibles sont à envisager pour identifier les services intervenants dans un système :

Concevoir le système comme étant une communauté de participants (fournisseurs et consommateurs de services) et les contrats qui spécifient la manière avec laquelle ils devront interagir.

Organiser de manière hiérarchique un certain nombre de fonctionnalités mutualisables en habilités d’un service. La hiérarchie doit refléter les dépendances.

S’inspirer de la logique métier en termes de processus pour identifier les habiletés nécessaires pour accomplir une tâche particulière ainsi que les rôles joués par chaque participant.

Indépendamment de la manière dont les services sont identifiés, leurs spécifications incluent leurs interfaces14.

Une interface de service définit une interaction ou un protocole de communication régissant les règles d’une bonne implémentation du service.

Les consommateurs et fournisseurs de services sont représentés par la notion de participants et les contrats par la notion d’interface de service.

Les participants offrent leurs services via un port représenté par le stéréotype « Point de service » et présentent leurs requêtes via un autre port représenté par le stéréotype15 13 Le terme a été inventé par ROY FIELDING en 2000.14 Va-t-on modéliser du point de vue consommateur, du point de vue fournisseur ou du point de vue système15 Une interface fournit une vue totale ou partielle d'un ensemble de services offerts par une classe, un paquetage ou un composant. Les éléments qui utilisent l'interface peuvent exploiter tout ou partie de l'interface.



« Point de requête ». Ces ports représentent des points d’entrée et de sortie d’où les services sont offerts et consommés.

Le point de service peut être une interface UML ou une autre interface de service.

L’architecture des services peut être vue à deux niveaux de granularité :

La communauté est le plus haut niveau de vision de la manière dont les participants indépendants collaborent pour atteindre un objectif particulier. L’architecture service de la communauté est modélisée par un diagramme de collaboration UML stéréotypé par « Architecture des services ». Dans cette modélisation on ne tient pas compte de la manière dont un participant particulier contrôle ses processus.

On peut aussi regarder l’architecture des services d’un participant particulier. Dans ce cas, on utilisera une classe UML stéréotypé par « Architecture du Participant » généralement associé à un processus métier.

Une autre clé essentielle d’une architecture orientée services est le contrat de service qui est modélisé en utilisant un diagramme de collaboration UML stéréotypé par « contrat de service ».

La chorégraphie du contrat de service quand à elle sera modélisée par un diagramme de séquence UML ou tout autre diagramme UML modélisant l’activité.

Conclusion

SOA est un paradigme de conception logicielle basé sur le principe du couplage faible. Les éléments constitutifs de base d’une SOA sont les services qui offrent l’accès aux données et à une logique métier. XML et les web services sont devenus



un choix populaire d’implémentation de la SOA. Ces dernières années, une attention particulière est accordée aux Architectures orientées services à cause de leur potentielle réduction du coût des solutions logicielles et leur accroissement de l’agilité dans le système d’information. Cette attention ira certainement grandissante puisque UML a connu une récente extension pour permettre la modélisation des SOA. SOAML est le profil UML pour les architectures orientées services.


PARTIE III : ARCHITECTURE EXISTANTE


CHAPITRE 6 : ARCHITECTURE MATÉRIELLE ET LOGICIELLE.

Ce chapitre présente l’écosystème du matériel et des systèmes disponibles avant le démarrage du projet.

VI.1 Le matériel.

Dans le cadre de la modernisation du système d’information de la SONARA, de nouvelles acquisitions ont été effectuées pour enrichir le parc matériel et système du patrimoine informatique de l’entreprise. Pour ce qui est du matériel, la SONARA dispose d’environ 400(quatre cent) machines clientes et 18(dix huit) serveurs. La matrice ci-dessous présente une projection de l’organisation de ce parc du point de vue des composants concernés par notre travail16.

16 Les stéréotypes permettent d'étendre la sémantique des éléments de modélisation : il s'agit d'un mécanisme d'extensibilité du métamodèle d'UML qui permet de définir de nouvelles classes d'éléments de modélisation.



Figure 13: architecture des serveurs physiques.



VI.2 Les systèmes d’exploitation.

Les machines physiques de la matrice précédente sont pilotées par des systèmes d’exploitation de type serveur. La matrice ci-après est le reflet du regard qu’a notre projet sur le parc OS du SI de la SONARA.

Figure 14: architecture des systèmes d’exploitation.

VI.3 Les Serveurs de données et d’applications

Les utilitaires systèmes suivant sont orchestrés par les systèmes d’exploitation sus-évoqués, pour piloter les programmes utilisateurs17.

.

17 A coté de ces serveurs on trouve également des serveurs HP UX et Dell Optiplex qui ne sont pas concernés par notre travail.



Figure 15: Les serveurs de données et d’applications

VI.4 Architecture du SI

Nous présentons ici la vue que notre travail a de l’architecture du Système d’Information de la SONARA.

Figure 16: Architecture existante du patrimoine applicatif.

Cette distribution des serveurs d’applications et surtout de données sur les architectures matérielles requiert l’acquisition d’une licence par serveur et par machine. Ce qui est loin d’être optimal ,puisque une licence de Oracle 10g couvre toutes les versions antérieures du mêmes serveur de données qui sont installées sur la même architecture physique que la version 10g. Deux solutions sont donc envisageables :



migrer toutes les bases de données vers la versions 10g ou alors faire cohabiter toutes les versions nécessaires du serveur de données de cet éditeur sur une même machine physique. La seconde option s’imposera à nous du fait des contraintes émises par certains éditeurs d’applications ayant certifié le fonctionnement de leur outil pour une version précise.

VI.4 Architecture des différents serveurs de données.

Les différentes versions du serveur de données présentées sur la figure 15 bien qu’issues du même éditeur ont des architectures qui présentent de nombreuses différences. Nous présentons ici les architectures de ces différentes versions afin d’en ressortir les similitudes et surtout les différences.

VI.4.1 Architecture de Oracle Database 8i

La figure ci-dessous présente l’architecture du serveur de données Oracle 8i.



Figure 17:Architecture de Oracle Database 8i

VI.4.2 Architecture de Oracle Database 9i

La figure ci-dessous présente l’architecture du serveur de données Oracle 9i.



Figure 18 :Architecture de Oracle Database 9i

VI.4.2 Architecture de Oracle Database 10g

La figure ci-après présente l’architecture du serveur de données oracle 10g.



Figure 19: Architecture de Oracle Database 10g

VI.4.3 Oracle 8i, 9i et 10g : les différences.

Lorsqu’on observe les trois figures précédentes, on constate assez tôt de grandes similitudes. Ce qui s’explique par le fait qu’il s’agit d’une gradation ascendante des différentes versions du serveur de données d’un même éditeur. Les différences sont quant à elles moins triviales. Nous allons nous atteler à illustrer quelques unes de ces différences en recensant quelques améliorations apportées par les récentes versions.

Si passage de la version 8i à la version 9i a connu les améliorations suivantes :



Introduction du type de données TIMESTAMP pour la gestion des dates.

Gestion locale des Espaces logiques(TABLESPACE). Introduction de la commande SQL MERGE. Modification dynamique des paramètres de configuration. Modification des noms de colonnes. Gestion automatique des Rollback segment. Introduction du spfile.

Le passage à la version 10g a apporté :

La technologie du calcul distribué (Grid computing : g pour grid).

Grande amélioration sur l’optimiseur de requête. Introduction de Automated Woarload Repository (AWR)

pour l’optimisation des performances. Introduction de Automated Session History pour

l’optimisation des diagnostiques. Introduction de la technologie Data pump Introduction de ADDM (Automatic Database Diagnostic

Monitor) et de ses conseillers. Introduction de ASMM (Automatic Shared Memory

Manager) Introduction des VPD (Virtual Private Database) Oracle Enterprise Manager devient une application web

client léger. Introduction des technologies de Flashback. Gestion automatique des Espaces logiques.

Ces différentes améliorations du serveur de données Oracle peuvent justifier une migration de données. C’est d’ailleurs pour profiter des avantages offerts par le release 10.2.0.1 qu’un projet de migration fait partie de notre tâche dans le cadre de ce stage.

VI.4 Architecture de l’application de gestion des données techniques



L’application de gestion de données techniques à refondre vers une architecture web est une application 2-tiers. Le logiciel est installé sur chaque poste client qui se connecte à la base des données techniques. L’administration et la maintenance s’avère difficile parce qu’elles impliquent à la fois celles de chacune des machines clientes et celle du serveur et de la base de données. Un autre problème de cette architecture tient à ce que pour travailler, l’utilisateur doit absolument être devant une machine dotée du logiciel.

Figure 20: Architecture de POV

Conclusion

Il s’est agit dans ce chapitre de présenter l’architecture à refondre de manière à ce que la pertinence de ce projet soit éclatante. Nous avons pour cela présenté la répartition des serveurs de données et d’applications disponibles à la SONARA et la nécessité de son optimisation. L’architecture 2-tiers du logiciel de gestion des données techniques ne répond plus aux standards technologiques en matière d’outil logiciel distribué. Sa maintenance et son administration sont des tâches très encombrantes. Sa refonte vers une architecture web est pleinement justifiée.


PARTIE IV : CONCEPTION DE L’ARCHITECTURE CIBLE.


CHAPITRE 7 : CONCEPTION DE LA NOUVELLE ARCHITECTURE DU LOGICIEL POV.

A l’intérieur des frontières d’une application, la problématique rencontrée est principalement celle de la réutilisation de services unitaires. Nous avons opté pour une des meilleures pratiques architecturales à l’usage en termes de réutilisabilité et d’interopérabilité : la SOA. Nous allons nous appuyer sur la démarche eXtreme Programming couplé à l’extension SOAML de UML pour les architectures orientées services pour la conception et la modélisation de POV. Ce chapitre présente la conception du prototype et les modèles réalisés.

VII.1 Métaphore de l’architecture globale du logiciel.

A l’issu de la phase d’exploration, nous avons recensé les scénarii utilisateurs les plus importants pour les utilisateurs finaux de POV. Les fonctionnalités qu’ils renferment concernent le module de valorisation. En effet, ce module dont l’importance n’est plus à démontrer présente dans la version actuelle de POV de nombreuses incohérences avec les standards internationaux de calcul des prix. Il nous servira de prototype d’implémentation en termes de spécifications fonctionnelles, de choix techniques et de mise en production formulés pour l’intégralité du produit.

L’architecture ci-dessous procède du métier du raffinage et résume les choix que nous avons faits en termes d’authentification, d’autorisation, de services, de données et



d’orchestration des services suivant les aspects fonctionnel, technique et système. Nous nous sommes intéressés à la cartographie, aux standards et meilleures pratiques (pattern) et aux méthodes et outils à l’usage.



Figure 21: Métaphore des services du module de valorisation


Légende :

SAML : Sécurity Assertion Markup LanguageMVC : Model Vue ControllerADF : Application Development FrameworkSSO : Single Sign OnXLST : eXtensible Stylesheet Language TransformationsGED : Gestion Electronique de Document


La phase d’exploration nous a permis d’avoir une vue précise sur les besoins pressants des utilisateurs et de réfléchir sur l’architecture fonctionnelle, technique et système de l’ensemble de l’outil à produire. Ces besoins pressants représentent environ 20% des cas d’utilisations, un module en implémentant certains constituera le prototype de notre solution. Ce prototype permettra de constater l’effectivité de la mise en œuvre fonctionnelle des spécifications architecturales émises. Et l’équipe informatique pourra s’en référer pour l’implémentation des autres modules applicatifs. Il s’appuie sur une architecture 3-tiers présentée ainsi qu’il suit :

Figure 22: Métaphore de l’architecture client/serveur de POV.

VII.2 Choix des outils.

Le cahier des charges de la refonte de POV, nous impose l’utilisation de Oracle Database 10g comme serveur de données. Dans un souci d’optimisation des ressources, nous avons optés pour le serveur d’application Weblogic 10.3.1 du même éditeur. Et dans le même esprit, Oracle Jdeveloper18

18 Microsoft SQL SERVER 2005 et 2008 sont également disponibles


Serveur de

donnéesServeur

d’applicationsNavigateur ou

EJB Client


11g sera notre IDE. Cet IDE s’appuie sur le framework ADF (Application Developpement Framework basé sur le pattern MVC (Model View Controler) et qui obéit à l’architecture suivante.

Figure 23: Architecture du Framework ADF

VII.3 Métaphore des services du module de Valorisation.

Nous présentons ici les services du module de valorisation de POV suivant deux caractéristiques : la nature et la granularité.

Du point de vue de leurs natures, ces services peuvent être classés dans deux catégories :

Les services métiers qui correspondent à des fonctionnalités métier.



Les services d’infrastructure qui regroupent un ensemble de fonctionnalités transverses au système d’information utilisées par les services métiers

Du point de vue de la granularité, on aura :

Les services de fine granularité ou services unitaires qui sont des fonctionnalités élémentaires répondant au besoin de modularité et de réutilisation.

Les services de grosse granularité ou services globaux qui peuvent exposer la valeur du module à l’intérieur comme à l’extérieur de l’application.

La technologie Oracle, Service Component Architecture SCA évoquée sur la figure 21, permet de créer des services de grosse granularité en fédérant plusieurs services de fine granularité.

La matrice ci-dessous présente la cartographie des services du module de valorisation. Notre prototype sera extrait de cette cartographie.



Figure 24: Métaphore des services du module de valorisation

Les services métiers du module de valorisation peuvent être divisés en trois catégories : ceux qui constituent notre prototype et permettent le calcul des prix de vente des produits de raffinage, ceux qui concernent le calcul des prix d’achat des bruts et enfin ceux qui permettent le calcul des marges bénéficiaires

VII.4 Modélisation des services du calcul des prix de vente des produits.



Ce sous module est détenteur de l’intelligence du calcul des prix des produits que la SONARA offre à ses clients repartis dans différents marchés.

a- Métaphore du diagramme de flux du calcul des prix de produits.

Figure 25: métaphore du diagramme des flux du calcul des prix.

Les services d’infrastructure dont font parties les processus de connexion et de choix de tâche, vont être implémentés sur le module ADF Security du Framework ADF que nous avons choisi comme socle technique de notre architecture. Le chapitre 9 présentera les résultats obtenus. Nous présentons ici les services liés au métier du calcul des prix des produits du raffinage.

b- Métaphore de la couche persistance du calcul des prix.



Le diagramme ci-après présente l’aspect statique des données techniques qui interviennent dans le calcul des prix des ventes des produits de la SONARA.

Figure 26: Métaphore de la couche persistance du calcul des prix des produits.

c- Métaphore de l’architecture des services du calcul des prix.



Nous présentons ci après l’architecture des services impliqués dans le calcul des prix.



uc Use Case Model

EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version





































«<<Architecture des serv ices>>»Calcul des prix

Ce service renferme toutes les opérations utiles pour calculer le prix de vente d'un produit de raffinage sur unmarché ou pour un client particulier.

cp: calculateur des prix

marche:Pov_Marche

produit:Pov_Produit

utilisateur: Utilisateur

cotation:Pov_Cotationed:Estimation

des dates

mc:Moyenne Cotation

clt:Pov_clientConcerner

«flow»

Concerner

«flow»

Appartenir

«flow»

S'appuyer sur«flow»

Etre concerné

«flow»

Util iser

«flow»

Etre l ié

«flow»

util iser

«flow»

soll iciter

«flow»

Figure 27:Métaphore de l’architecture des services du calcul des prix.

d- Métaphore de l’architecture du participant : calculateur des prix.

class Domain Model

EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version





































«<<Architecture du Participant>>»Composant Calcul des prix

:Calculateur de prix

:Inv oquer le serv ice

Calcul des moyennes cotations


Estimation des dates

:Marche

:Produit

:Client

:Cotation

Etre le marché de

«flow»

Util iser«flow»

Fournir les informations

«flow»

Util iser

«flow»

«flow»

«flow»

soll iciter

«flow»

Fournisseur

«flow»«flow»



Figure 28:Métaphore de l’architecture du participant :calculateur de prix.

e- Métaphore des interfaces des services impliqués.

uc Domain Model

EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version






























«interface»Calcul des moyennes cotations

+ moyenne_cotation(char, char, char) : float

«interface»Estimation des dates

+ datedebut(char) : char+ datefin(char) : char

«interface»Calcul des prix

+ calcul_prix(char, float, char) : float+ Calcul_prix_disti llat(char, float, float) : float

Figure 29: Métaphore des interfaces des services du calcul des prix19.

f- Métaphore du contrat du service calculer un prix.

uc Use Case Model

EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version
































«<<Contrat de Serv ice>>»Calculer le prix

:Calculateur de prix


:Utilisateur

Fournisseur

«flow»

Demandeur

«flow»

Figure 30: Métaphore du contrat du service calculer un prix.

19 Optimisé pour produire des applications tournant sur les serveurs Oracle.



Conclusion

Dans le cadre de la refonte de l’application des gestions des données techniques dénommée POV vers une architecture web, nous avons prescrit une architecture orientée services implémentée sur le Framework ADF de l’IDE Oracle Jdeveloper 11g, et déployée sur le serveur d’application Oracle weblogic. Aussi avons-nous proposé une modélisation du processus de calcul des prix des produits de raffinage avec SOAML. Et proposé des métaphores du système qui pourront être confirmées ou modifiées lors des itérations. Ce module qui nous sert de prototype pourra servir de référentiel de connaissances et de pratiques pour le développement de tous les modules de l’application.



CHAPITRE 8 : CONCEPTION DE LA NOUVELLE ARCHITECTURE DES SERVEURS DE DONNÉES ET D’APPLICATIONS

Ce chapitre présente la nouvelle architecture des serveurs de données et d’applications après consolidation des serveurs et migration.

VIII.1 Architecture globale des serveurs.

Figure 31 : Nouvelle architecture des serveurs

Pour arriver à cette architecture, nous devons au préalable effectuer la consolidation des serveurs de données Oracle ainsi que la migration des données de Oracle 8i à Oracle 10g. Nous allons prendre appui sur les différentes bonnes pratiques énumérées au chapitre 3 pour le faire.

VIII.2 Planification de la consolidation des serveurs.

La consolidation des serveurs de données Oracle 8i, 9i et 10g sera effectuée suivant la méthode dénommée consolidation



logique. Telle que présentée au chapitre 3, la consolidation logique s’appuie sur la norme OFA (Optimal Flexible Architecture) de l’éditeur.

VIII.2.1. OFA et la cohabitation des serveurs Oracle Database.

Depuis la release 8.0.4 de la version 8, la cohabitation de plusieurs installations de versions différentes du serveur de données Oracle, est possible. L’architecture OFA est une méthode de configuration de la base de données Oracle, ainsi que d'autres bases de données. Elle tire partie des fonctionnalités du système d'exploitation et des sous-systèmes de disque pour créer une configuration facile à administrer, et offre une flexibilité maximale pour les bases de données à forte croissance et hautes performances. Les méthodes décrites ci-après constituent les bases de l'architecture OFA. Oracle Corporation recommande d'appliquer la norme OFA lors de toute installation de l’un de ces serveurs de données [OCA06].

L’utilisation de la norme OFA pour l’installation de plusieurs versions du logiciel présente plusieurs avantages :

• Organiser de grandes quantités de logiciels et de données complexes sur le disque, afin d'éviter les goulets d'étranglement et les faibles performances,

• Faciliter les tâches d'administration répétitives, telles que les sauvegardes de logiciels et de données, souvent sujettes à la corruption de données,

• Faciliter le basculement entre plusieurs bases de données Oracle,

• Gérer et administrer de façon adéquate l'expansion de la base de données,

• Contribuer à éliminer la fragmentation de l'espace libre dans le dictionnaire de données, à isoler toute autre fragmentation et à limiter la contention des ressources.

• Dans la plupart des cas, aucun investissement dans du nouveau matériel n'est pas requis pour profiter de la norme OFA.



• En distribuant des applications à travers plusieurs périphériques, les défaillances de disque affectent le moins possible les applications.

VIII.2.2 Utilisation de l’architecture OFA

A la base de l'architecture OFA se trouve un schème d'appellation, qui définit une norme à appliquer aux points de montage (qui correspondent souvent aux disques physiques), aux répertoires et aux sous-répertoires de ces points de montage, ainsi qu'aux fichiers proprement dits.

Syntaxe d'un point de montage : Nommez tous les points de montage à l'aide de la syntaxe /pm, où p est une constante de type chaîne et m, une clé unique de longueur fixe (généralement un nombre à deux chiffres) utilisée pour distinguer chaque point de montage. Vous pouvez, par exemple, nommer les points de montage /u01 et E:\

Syntaxe d'un répertoire d'origine : Nommez tous les répertoires d'origine Oracle Home à l'aide de la syntaxe /pm/h/u, où pm est le nom d'un point de montage, h est un nom de répertoire standard et u, le nom du propriétaire du répertoire. Voici des exemples de répertoires d'origine conformes à l'architecture OFA : /u01/app/oracle ou E: \oracle

Syntaxe d'un répertoire logiciel : Stockez chaque version du logiciel Oracle dans un répertoire correspondant au modèle /pm/h/u/product/v. Dans le cas présent, product est un littéral et v une variable correspondant au numéro de version. Cette syntaxe permet d'activer la fonctionnalité de l'architecture OFA rendant possible l'exécution simultanée de plusieurs versions d'applications. Ainsi, une installation d'Oracle Database 10g version 10.2.0 conforme à l'architecture OFA ressemblerait à ce qui suit : E:\oracle\product\10.2.0

Le format complet est : /u01/app/oracle/product/10.1.0/type[_n]



Où type désigne le type de répertoire d’installation (client ou db) et n un compteur facultatif. Pour le cas de la SONARA, nous n’aurons pas besoin d’installer les clients sur le serveur par conséquent la partie /type[_n] sera omise dans la nomenclature de nos répertoires OFA.

Lorsque la norme OFA est bien suivi, les services de bases de données de différents serveurs peuvent cohabiter sur la même architecture matériel et logiciel, il reste alors à gérer la connexion des applications clientes à ces différents services, c'est-à-dire à configurer les services Oracle Net.

VIII.2.3 Configuration des services Oracle Net.

Les serveurs de données Oracle sont des applications client-serveur. Ils mettent en œuvre plusieurs machines(les clients) sur lesquels un applicatif communique avec un ordinateur distant (le serveur) qui traite leur requête. Pour faire fonctionner cette architecture, il est nécessaire de disposer d’une couche logicielle intermédiaire appelée « middleware » qui assure la communication entre les machines. Dans l’ensemble des logiciels Oracle le produit assurant cette fonctionnalité s’appelle Oracle Net.

Les services Oracle Net permettent les connexions réseau d'un client ou d'une application de niveau intermédiaire (middle tiers) au serveur Oracle. Après l'établissement d'une session réseau, Oracle Net joue le rôle de transporteur de données pour l'application client et le serveur de base de données. L’utilisation la plus courante des services Oracle Net est l'autorisation des connexions de base de données entrantes. On peut également configurer des services supplémentaires pour autoriser l'accès aux bibliothèques de code externes (EXTPROC) et pour la connexion de l'instance Oracle à des sources de données non Oracle, par exemple Sybase, Informix, DB2 ou SQL Server, via les services hétérogènes (Heterogeneous Services) Oracle. Il est responsable de l'établissement et de la maintenance de la



connexion entre l'application client et le serveur de base de données, ainsi que de l'échange des messages entre eux. Oracle Net, ou un élément qui simule Oracle Net tel que JDBC (Java Database Connectivity), réside sur chaque ordinateur qui doit communiquer avec le serveur de base de données.

Sur l'ordinateur client, Oracle Net est un composant en arrière-plan pour les applications qui se connectent à la base de données. Il conviendra à l’équipe informatique de configurer Oracle Net sur les machines clientes où besoin se fera.

Sur le serveur de base de données, Oracle Net inclut un processus actif appelé processus d'écoute (listener). Le processus d'écoute Oracle Net est responsable de la coordination des connexions entre la base de données et les applications externes.

Figure 32: Services Oracle net

VIII.2.4 Processus d'écoute Oracle Net



Le processus d'écoute (listener) Oracle Net est la passerelle vers l'instance Oracle pour toutes les connexions utilisateur non locales. Un même processus d'écoute peut gérer plusieurs instances de base de données et des milliers de connexions client.

Pour des raisons de sécurité, on peut activer la protection par mot de passe pour éviter à n’importe quel utilisateur de contrôler la configuration du processus d’écoute. Il est également important pour les mêmes raisons de séparer les services de bases de données des services supplémentaires [OCP05]. Nous allons utiliser ces options pour nos processus d’écoute.

Lorsqu’on fait cohabiter plusieurs versions du serveur de données Oracle sur un même système d’exploitation, des conflits sur les processus d’écoute sont en général remarqués. Surtout entre le listener de la version 9i et celui de la version 10g.

Pour pallier ce problème deux solutions sont envisageables :

• Faire écouter les processus d’écoutes en conflit sur des ports différents ;

• Créer un processus d’écoute unique Oracle Net 10g pour écouter les services des versions 10g et 9i.

VIII.3 Planification de la migration des données.

Comme pour la consolidation des serveurs de données, nous allons prendre appui sur l’une des meilleures pratiques en termes de migration citées au chapitre 3 : la migration par l’exportation et l’importation de données.

En effet, il paraît plus commode à première vue d’utiliser la migration par la mise à niveau de la base de données. Mais une contrainte forte nous pousse à opter pour une la solution



de l’export/import. Le serveur de données Oracle 10g dans ses releases 10.2 ne reconnait pas les services Oracle 8.1.6. Cette solution nous impose donc de passer par une première migration vers Oracle 9.2.0 avant une seconde vers Oracle 10.2.0.1. Quoi qu’il soit possible de mettre en œuvre cette solution, nous optons pour l’import/export qui présente moins de contraintes en termes de préparation de la migration.

VIII.3.1 L’exportation de la base 8.1.6

Une autre contrainte de l’éditeur est de toujours utiliser l’outil d’export de la version la moins récente. Nous utiliserons donc l’outil d’export classique de la version 8.1.6 pour faire un export complet.

VIII.3.2 L’importation vers la base 10.2.0.1.

Après l’exportation, nous créons une nouvelle base vierge portant le même nom que celle exportée sur le serveur 10.2.0.1. Nous utiliserons l’outil d’import de la version la plus récente selon les prescriptions de l’éditeur. C'est-à-dire celui de Oracle 10.2.0.1 pour faire un import complet.

Conclusion

Le souci de modernisation de l’architecture du patrimoine applicatif nous a conduit à une consolidation des serveurs de données Oracle et à une migration d’une base de données Oracle 8.1.6 vers Oracle 10.2.0.1. Nous avons proposés dans ce chapitre les architectures et les outils que nous préconisons précisément l’introduction dans le parc informatique de Oracle weblogic serveur optimisé pour fonctionner avec les



bases de données Oracle. Les planifications de la consolidation et de la migration ont été effectuées.


PARTIE V : MISE EN OEUVRE

ORACLE_HOME 10gE:\oracle\product\10.2.0

ORACLE_HOME 9iE:\oracle\product\9.2.0.1

ORACLE_HOME 8iE:\oracle\product\8.1.6

ORACLE_BASEE:\oracle\product

Fichiers de la BD 10gF:\oracle\oradata\base10g

Fichiers de la BD 9iF:\oracle\oradata\base9i

Fichier de la BD 8iF:\oracle\oradata\base8i

Répertoire de fichier de données OracleF:\oracle\oradata


CHAPITRE 9 : MISE EN ŒUVRE.

Ce chapitre présente l’implémentation des choix effectués à la partie 4 dans l’environnement de développement ainsi que les résultats obtenus.

IX.1 Mise en œuvre de la consolidation des serveurs.

IX.1.1 Organisation des répertoires d’installation

Pour la raffinerie, nous proposons l’architecture OFA suivante :

Figure 33: Configuration des répertoires OFA à la SONARA

IX.1.2 Organisation des fichiers de données

Afin d’optimiser l’organisation et les performances, Oracle recommande d’installer les fichiers de bases de données et le logiciel oracle sur des disques Distincts. Nous avons plus haut présenté l’organisation des différents logiciels, la figure suivante présente l’organisation des fichiers de données qui respecte également de la norme OFA.



Figure 34: Configuration des fichiers de données Oracle à la SONARA

IX.1.3 Configuration des processus d’écoute à la SONARA.

Un listener 10.1 est compatible avec des bases 8, 9 et 10 mais un listener 10.2 ou ultérieur n'est compatible qu'avec des bases 9 et 10 sauf si l'instance 8i fonctionne en mode serveur partagé.

A la SONARA, nous sommes à la version 10.2.0.1, et les bases de données 8i fonctionnent en mode dédié. Nous utiliserons donc trois processus d’écoute LISTENER8 pour les services oracle 8i, LISTENER pour les services oracle 9i et 10g et LISTENER1 pour les services supplémentaires.

La configuration des fichiers Listener.ORA de Oracle Net 10g et Oracle net 8i est la suivante :


LISTENER1 = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) )PASSWORDS_LISTENER= (5A72145DEAB509FF)SID_LIST_LISTENER1 = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = E:\oracle\product\10.2.0\db_1) (PROGRAM = extproc) ) )LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = mengolaptop-xp)(PORT = 1521)) )


Figure 35: configuration du listener.ORA 10g

Figure 36: configuration du listener.ORA 8i


LISTENER8 =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = mengolaptop-xp)(PORT = 1522))

)

(DESCRIPTION =

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC3))

)

)

SID_LIST_LISTENER8 =

(SID_LIST =

(SID_DESC =

(SID_NAME = PLSExtProc)

(ORACLE_HOME = E:\ORACLE\oracle\product\8.1.6)

(PROGRAM = extproc)

)

)


La vérification des statuts du processus d’écoute donne les résultats suivants :

Figure 37: statut de listener



Figure 39: statut de listener1

Figure 40: statut de listener8


Choix des répertoires ORACLE_BASE et ORADATA

Installation des logiciels de base dans les répertoires ORACLE_HOME respectifs

Création des processus d’écoutelistener, listener1 et listener8

Création des bases de données base8, base9i et base10g

Tester les connexions aux bases de données créées


IX.1.4 Recommandations particulières.

Les tâches de consolidation doivent être exécutées suivant l’ordre suivant pour éviter tout bug lié à la connexion aux de données.

Figure 41: Enchainement des activités de consolidation

IX.2 Mise en œuvre de la migration des données.

IX.2.1 Script d’export.E:\oracle\product /8.1.6> exp userid=system/motdepasse@basexport file=c:\backup\export_full.dump log=c:\control\export_full.log full=y

IX.2.2 Script d’importE:\oracle\product /10.2.0.1> imp userid=system/motdepasse@newbase file=c:\backup\import_full.dump log=c:\control\import_full.log full=y

IX.3 Mise en œuvre du calcul des prix des produits de raffinage.



Nous présentons ici le résultat de l’implémentation du prototype réalisé en suivant la matrice proposée à la figure 21.

IX.3.1 Les services d’infrastructure : gestion des accès et de la sécurité.

Comme nous l’avons annoncé au chapitre 7, nous avons opté pour le module ADF Security du Framework ADF de Oracle Jdeveloper 11g pour l’implémentation de nos politiques de sécurité et des accès.

ADF Security est le Framework conseillé par l’éditeur pour la gestion des authentifications et des autorisations, il prend appui sur l’architecture Oracle Platform Security Services (OPSS) qui elle-même est intégrée au serveur d’application Oracle Weblogic. Il implémente le model de sécurité Java : Java Authentification and Authorization Services (JAAS), et permet de sécuriser tant les pages web, les flux de tâches que l’accès aux tuples retournés par la base de données. Cette implémentation de la JAAS n’est pas basée sur les URL des pages webs, mais plutôt sur un ensemble de ressources dénommées ADF security-aware resources.

Lors de configuration de ADF Security nous avons opté pour une authentification via un formulaire de login, et nous avons configuré les roles applicatifs et d’entreprise, puis nous y avons affecté les utilisateurs pour leur permettre l’accès aux ressources sécurisées. Les figures qui suivent présentent les étapes suivis et les résultats obtenus.



Figure 42: Configuration de ADF Security.

Le formulaire de connexion a été implémenté par une JSF dont la JSP est codé en XML nommé connexion.jspx. Une classe java nommé connexion.java sert d’appui au backing bean backing_connexion lié à ce formulaire. Le code de cette classe est fourni en annexe.



Figure 43: Résultat de page de connexion20

Figure 44: Erreur de connexion.

20 La fonction SQL to_date(char, format) permettra la conversion des chaines de caractères en date lorsque besoin sera.



Figure 45: Connexion réussie, menu principal.

La liste des modules est fournie par un service web qui se charge de la connexion à la base de données et de l’exécution de la requête de sélection des services offerts par l’application. Ce service s’appui sur une table système dont la structure est la suivante via un EJB entité.

Figure 46: Structure de la table système POV_Module

Ce service web a l’interface suivante

:Figure 47: Interface du service web ModuleServiceBean.

IX.3.2 Les services métiers : calcul des prix des produits de raffinage



Une fois le module sélectionné et les droits d’accès vérifiés, l’utilisateur est orienté vers une page web métier ou vers un flux de tâches métiers : celui du calcul des prix des produits dans le cas du prototype que nous avons réalisé.

Figure 48: task-flow du calcul des prix.

Figure 49: task-flow du paramétrage des produits.

Les diagrammes de flux de tâches si dessus illustrent l’enchainement des pages web et des régions pour ce qui est du service de calcul des prix de raffinage. L’implémentation de ce service, s’appui sur une package PL/SQL, contenant les fonctions et les procédures stockées représentant les opérations énumérées dans la métaphore des interfaces des services du calcul des prix présentée au chapitre 7. Ce package dont le corps est fourni en annexe a été publié comme un service web.



On remarquera l’ajout de la procédure d’édition des cotations qui permettra, le cas échéant, à une entité tiers (un cabinet partenaire) ou à un agent de renseigner les cotations quotidiennement : on réduira alors les attentes à cet égard.

Figure 50: déclaration du package valorisation qui sera publié comme un service web.

Figure 51: Interface du service web du calcul des Prix produit.

Toutes les opérations de ce service web ont été testées avec succès, et nous avons pu implémenter la couche model via le Framework ADF Datacontrol et les JSF pour la vue et le contrôleur. Et les résultats sont les suivants :



Figure 52: Utilisation de l’opération édition des cotations du service de calcul des prix.

Figure 53: Edition des paramètres des produits



Figure 54: Estimation des prix de produits

Conclusion

Des recommandations ont été émises quant à la refonte de l’application de gestion des données techniques vers une architecture web. Les résultats obtenus lors de la réalisation du prototype suivant ces prescriptions prouvent leur faisabilité. La consolidation des serveurs et la migration des données ont été effectuées avec succès dans un environnement de développement et les résultats ont été présentés dans ce document. La mise en œuvre dans l’environnement de production de la solution de consolidation, a également été faite. Mais pour des raisons de sécurité, les résultats ne peuvent pas être présentés dans le présent document. Le plus qu’on puisse dire est qu’ils sont similaires à ceux constatés en développement. La solution de migration, ci-dessus présentée, sera implémentée en temps opportun par l’équipe informatique.





Le travail qui nous été confié au sein de l’équipe en charge du patrimoine applicatif de la Société Nationale de Raffinage (SONARA) du Cameroun, consistait à concevoir, planifier et mettre en œuvre la consolidation des serveurs et la migration de données Oracle. Il s’agissait aussi de prescrire les meilleures pratiques architecturales ainsi que les méthodes et les outils adaptés à la refonte de l’application de gestion des données techniques vers une architecture client léger. Nous avons choisi de nous appuyer sur les standards et normes de PMBOK et ITIL en matière de gestion de projet et de management de la qualité, pour l’adoption d’une structure de découpage du projet en lots de tâches devant nous permettre de réaliser les résultats attendus de nous. S’inspirant des normes de l’éditeur, Oracle Corporation, nous avons opté:

- Pour une démarche de consolidation basée sur le standard Optimal Flexible Architecture et une bonne configuration des services Oracle Net pour réaliser la cohabitation des versions 8.1.6, 9.2.0 et 10.2.0 du serveur de données Oracle. Une solution a été proposée et mise en œuvre. Les résultats ont été à la hauteur des attentes, et la solution a été mise en production.

- Pour la méthode de migration qui convient le mieux au problème posé. Nous avons tout d’abord effectué un recensement de toutes les possibilités offertes par l’éditeur en la matière. La solution proposée a été testée sur l’environnement de développement. Les résultats sont satisfaisants, l’équipe informatique de la SONARA effectuera la mise en production en temps opportun.

- Pour une démarche agile de production du logiciel de gestion des données techniques sous une architecture orientée services, pour une flexibilité et une souplesse qui garantira la réutilisabilité et l’interopérabilité. Le serveur


CONCLUSION GENERALE


d’application Oracle Weblogic, l’IDE Oracle Jdeveloper 11g et son Framework ADF ont été proposés comme outils. Un prototype a été réalisé à cet effet pour attester de la faisabilité de nos prescriptions.

Malgré les difficultés liées à la nouveauté des concepts, ce stage nous a permis de pratiquer la gestion de projet, l’administration des bases de données Oracle et la veille technologique dans le domaine du développement web, dans un environnement multidisciplinaire et hautement professionnel.


LISTE DES ABREVIATIONS


AIE : Agence Internationale de l’Energie.

EAI : Energy Information Administration.

EJB : Entreprise Java Bean.

GPL : Gaz Pétrolier Liquéfié.

IDE : Environnement de développement intégré.

OASIS : Organisation of Advancement of Structured Information Standards.

OS: Operating System

SE: Système d’Exploitation

SGBD: Système de Gestion de Bases de données.

W3C: Worl Wide Web Consortium.

Joël MENGOLO ASSAMBA. IAI-2009 II

BIBLIOGRAPHIE


[ADF06]: Jeff Gallus, Gary Williams, Kate Heap, Oracle Application Development Framework Tutorial, September 2006, 172 pages.

[ADF07]: Oracle ADF 11g Primer Introduction to the building blocks of a Fusion Web application, An oracle white paper , April 2007, 12 pages.

[ADF09]: Robin Whitmore , Peter Jew, Kathryn Munn, Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework, May 2009, 826 pages.

[AMBER07]: Swott W. Amber, Agile modeling: Effective Practices for eXtreme Programming and the Unified Process, Wiley, 400pages.

[BECK00]: Kent Beck et Cynthia Andres, eXtreme Programming explained, 2000, Paperback, 137 pages

[BLEIST08]: Danielle Bleistrach, Dans les profondeurs de la crise pétrolière, 2007.

[FAVEN98]: J.P. Favennec, Exploitation et gestion de la raffinerie,1998, Technip,576pages.

[GEOPO05] : Cédric de Lestrange, Christophe Alexandre et Pierre Zelenko, Géopolitique du pétrole, 2005, éditions Technip, 263pages.

[ITIL05] : Jan van Bon et Tieneke Verheijen, Gestion des services informatiques, une introduction basée sur l’ITIL, Van Haren Publishing, 234pages.

[MANIF01] : Martin Fowler et Highsmith, The agile manifesto, Août 2001,

[MOUK06] : Pierre Moukeli, Programmation des systèmes concurrents, 350pages.

[OCA06] DAWES Chip, BRYLA Bob, JOHNSON Joseph C. & WEISHAN Matthew. (2006). OCP Oracle 10g Administration I Study Guide. Sybex, San Francisco.

[OCP05]STUNS Doug, BUTERBAUG Tim & BRYLA Bob. (2005). OCP Oracle 10g Administration II Study Guide. Sybex, San Francisco.

[ORCL07]: Marcie Caccamo, Rosie Harvey, Oracle WebCenter Framework Tutorial, March 2007

[PMBOK 09] : Project Management instituite, Guide du corpus des connaissances en management de projet quatrième édition, 2008, PMI Publication, 445 pages.

Joël MENGOLO ASSAMBA. IAI-2009 VI


[PROEJB] : Mike Keith et Merrick Schincariol, Pro EJB 3 Java Persistence API,2006, Apress, 29pages.

[ROQUES07] : Pascal Roques, UML est-il soluble dans les méthodes agiles ? , Octobre 2007, Valtech training, 12pages.

[ROYCE70]: Dr Winston W. Royce, Managing the development of large software system, 1970, TWR, 11pages.

[SOAML08] : OMG, Service oriented architecture Modeling Language (SoaML) –Specification for the UML Profile and Metamodel for Services (UPMS), Novembre 2008,174pages.

[SQL08]: John Watson, Roopesh Ramklass, OCA Database 11g: SQL Fundamentals I, McGrawill, 609pages.

[TRAMB94] : P. Trambouze , Le raffinage du pétrole :Pétrole brut, produits pétroliers, schéma de raffinage., 1994, Technip,478pages.

[TRAMB99] : P. Trambouze , Le raffinage du pétrole Volume4, 1999, Technip,785pages.

[WAUQ98] : J.P. Wauquier , Le raffinage du pétrole : Procédés de séparation, Technip, 655pages.

Joël MENGOLO ASSAMBA. IAI-2009 VII

LISTE DES ILLUSTRATIONS


Figure 1 : Roue de Deming sur le management de la qualité..………………………………………...10

Figure 2 : Organigramme de la SONARA ………………………………...........................................15

Figure 3 : Tableau comparatif des approches de maintenance et de refonte complète……………17

Figure 4: SDP de conduite du projet ……………………………………………………………………….22

Figure 5 : La machine HP Integrity implémentant la consolidation physique……………………...27

Figure 6: Exemple d’utilisation d’un serveur de fichiers………………………………………………..28

Figure 7 : Exemple de Virtualisation……………………………………………………………………….29

Figure 8: Cycle de développement XP………………………………………………………………………32

Figure 9: Concepts de la SOA………………………………………………………………………………..39

Figure 10: Les web services………………………………………………………………………………….43

Figure 11: Approche top down……………………………………………………………………………….44

Figure 12: approche bottom up……………………………………………………………………………...45

Figure 13: architecture des serveurs physiques………………………………………………………….49

Figure 14: architecture des systèmes d’exploitation…………………………………………………….50

Figure 15: Les serveurs de données et d’applications…………………………………………………..50

Joël MENGOLO ASSAMBA. IAI-2009 IX


Figure 16: Architecture existante du patrimoine applicatif……………………………………………51

Figure 17:Architecture de Oracle Database 8i……………………………………………………………52

Figure 18 : Architecture de Oracle Database 9i…………………………………………………………...53

Figure 19: Architecture de Oracle Database 10g…………………………………………………………54

Figure 20: Architecture de POV……………………………………………………………………………..56

Figure 21: Métaphore des services du module de valorisation…………………………………………59

Figure 22: Métaphore de l’architecture client/serveur de POV………………………………………...60

Figure 23: Architecture du Framework ADF……………………………………………………………...61

Figure 24: Métaphore des services du module de valorisation…………………………………………62

Figure 25: métaphore du diagramme des flux du calcul des prix……………………………………..63

Figure 26: Métaphore de la couche persistance du calcul des prix des produits……………………64

Figure 27:Métaphore de l’architecture des services du calcul des prix……………………………….65

Figure 28:Métaphore de l’architecture du participant calculateur de prix……………………….….65

Figure 29: Métaphore des interfaces des services du calcul des prix………………………………….66

Figure 30: Métaphore du contrat du service calculer un prix…………………………………………..66

Figure 31 : Nouvelle architecture des serveurs…………………………………………………………...68

Figure 32: Services Oracle net……………………………………………………………………………….71

Figure 33: Configuration des répertoires OFA à la SONARA………………………………………….75

Joël MENGOLO ASSAMBA. IAI-2009 X


Figure 34: Configuration des fichiers de données Oracle à la SONARA……………………………..75

Figure 35: configuration du listener.ORA 10g…………………………………………………………….76

Figure 36: configuration du listener.ORA 8i………………………………………………………………77

Figure 37: statut de listener…………………………………………………………………………………78

Figure 39: statut de listener1………………………………………………………………………………..79

Figure 40: statut de listener8………………………………………………………………………………..79

Figure 41: Enchainement des activités de consolidation………………………………………………..80

Figure 42: Configuration de ADF Security………………………………………………………………..81

Figure 43: Résultat de page de connexion…………………………………………………………………82

Figure 44: Erreur de connexion……………………………………………………………………………..82

Figure 45: Connexion réussie, menu principal……………………………………………………………83

Figure 46: Structure de la table système POV_Module…………………………………………………83

Figure 47: Interface du service web ModuleServiceBean……………………………………………….84

Figure 48: Task-flow du calcul des prix…………………………………………………………………….84

Figure 49: Task-flow du paramétrage des produits………………………………………………………84

Figure 50: déclaration du package valorisation qui sera publié comme un service web…………..85

Figure 51: Interface du service web du calcul des Prix produit………………………………………..85

Figure 52: Utilisation de l’opération édition des cotations du service de calcul des prix…………86

Figure 53: Edition des paramètres des produits………………………………………………………….86

Joël MENGOLO ASSAMBA. IAI-2009 XI


Figure 54: Estimation des prix de produits………………………………………………………………..87

Joël MENGOLO ASSAMBA. IAI-2009 XII

ANNEXES


La métaphore du modèle statique du calcul des prix est la suivante.

class Domain ModelEA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version
































Pov _Produit

pov_Client

pov_marché

pov_cotation

pov_cotation Pov _Valeur_Cotation

- Date: char- valeurcot: float

Pov _valeur_prime

- valeurprime: float

Joël MENGOLO ASSAMBA. IAI-2009 IX


La classe Connexion.java qui gère la connexion à l’application. Elle a aussi été dépouillée de ses accesseurs.

Joël MENGOLO ASSAMBA. IAI-2009 X

package POV.view.backing;import javax.security.auth.Subject;import javax.faces.application.FacesMessage;import javax.faces.context.FacesContext;import javax.security.auth.callback.CallbackHandler;import javax.security.auth.login.FailedLoginException;import javax.security.auth.login.LoginException;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import weblogic.security.SimpleCallbackHandler;import weblogic.servlet.security.ServletAuthentication;import weblogic.security.services.Authentication;import javax.servlet.RequestDispatcher;import javax.servlet.ServletException;import java.io.IOException;

public class Connexion { private String login; private String pwd; public String entrer(){ String un = login; byte[] pw = pwd.getBytes(); FacesContext ctx = FacesContext.getCurrentInstance(); HttpServletRequest request = (HttpServletRequest)ctx.getExternalContext().getRequest(); CallbackHandler handler = new SimpleCallbackHandler(un, pw); try { Subject mySubject = Authentication.login(handler); ServletAuthentication.runAs(mySubject, request); String loginUrl = "/adfAuthentication?success_url=/faces/menuprincipal.jspx"; HttpServletResponse response = (HttpServletResponse)ctx.getExternalContext().getResponse(); sendForward(request, response, loginUrl); } catch (FailedLoginException fle) { FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, "Utilisateuer ou mot de passe érroné", "les paramètres de connexion entrés" + " ne sont pas corrects"); ctx.addMessage(null, msg); } catch (LoginException le) { reportUnexpectedLoginError("LoginException", le); } return null; /* action sur la page à appeler*/ } private void sendForward(HttpServletRequest request, HttpServletResponse response, String forwardUrl){ FacesContext ctx = FacesContext.getCurrentInstance(); RequestDispatcher dispatcher = request.getRequestDispatcher(forwardUrl); try { dispatcher.forward(request, response); } catch (ServletException se) { reportUnexpectedLoginError("ServletException", se); } catch (IOException ie) { reportUnexpectedLoginError("IOException", ie); } ctx.responseComplete(); } private void reportUnexpectedLoginError(String errType, Exception e){ FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, "Erreur innatendue lors de la connexion ", "Erreur de connexion innatendue (" + errType + "), consulter le fichier journal pour les détails"); FacesContext.getCurrentInstance().addMessage(null, msg); e.printStackTrace(); }

public void setLogin(String login) {


Nous présentons ici la classe Paramatre.java qui gère l’édition des paramètres et le calcul des prix des produits. Nous l’avons dépouillé ici de ces accesseurs.

Joël MENGOLO ASSAMBA. IAI-2009 XI

package POV.model;import client.ServicePrixProduit;import client.ServicePrixProduit_Service;import java.math.BigDecimal;import java.util.Calendar;import java.util.Date;import java.util.GregorianCalendar;import javax.xml.datatype.DatatypeConfigurationException;import javax.xml.datatype.DatatypeFactory;import javax.xml.datatype.XMLGregorianCalendar;import javax.xml.xpath.XPathFunctionException;

public class Parametre { private static String produit; private static String cotation; private static String marche; private static Date jourcotation; private static Date jourmarche; private static BigDecimal valeurcot; private static BigDecimal valeurprime; private static BigDecimal valeurcoef; private static BigDecimal valeurfa; private static String choixparam; private static BigDecimal valeurparam; private static Date jourdebut; private static Date jourfin; private static BigDecimal valeurprix;

public Parametre() { super(); } public String enregistrer_parametre(){ int i=Integer.parseInt(produit)+1; produit="PRODUIT"+i; int j=Integer.parseInt(marche)+1; marche="MARCHE"+j;

return null; } public String enregistrer_cotation(){ int i=Integer.parseInt(produit)+1; produit="PRODUIT"+i; int k=Integer.parseInt(cotation)+1; cotation="COTATION"+k; GregorianCalendar c = new GregorianCalendar(); XMLGregorianCalendar date2; c.setTime(jourcotation); try{ date2 = DatatypeFactory.newInstance().newXMLGregorianCalendar(c); //System.out.println(date2.getDay()+"/"+date2.getMonth()+"/"+date2.getYear());

ServicePrixProduit_Service service= new ServicePrixProduit_Service(); ServicePrixProduit port = service.getServicePrixProduitPort(); port.insereValeurCotation(cotation,date2,valeurcot,produit); }catch (Exception e) { System.out.println("Exception de base: " + e.getMessage()); } return null; }


Ces deux pages présentent le corps du package valorisation dont la définition a été présentée au chapitre 9.

Joël MENGOLO ASSAMBA. IAI-2009 XII

create or replace PACKAGE BODY PAKAGE_VALORISATION AS

function debutcotation(libellemarche varchar2) return TIMESTAMP AS debut TIMESTAMP;teste number;BEGIN if(libellemarche='Marche Soutes et Internationales') then select to_date(concat('15/',to_char(add_months(sysdate,-2),'MM/YYYY'))) into debut from dual; else if(libellemarche='CEMAC CIF Douala') then select to_number(to_char(sysdate, 'dd')) into teste from dual; if(teste<=15) then select to_date(concat('14/',to_char(add_months(sysdate,-1),'MM/YYYY'))) into debut from dual; else select to_date(concat('28/',to_char(add_months(sysdate,-1),'MM/YYYY'))) into debut from dual; end if; else if(libellemarche='Marche National') then select next_day(sysdate-14,'Lundi') into debut from dual; end IF; end IF ; end if; return debut ;END debutcotation;

function fincotation(libellemarche varchar2) RETURN TIMESTAMP AS fin TIMESTAMP; teste number;BEGIN if(libellemarche='Marche Soutes et Internationales') then select to_date(concat('14/',to_char(add_months(sysdate,-1),'MM/YYYY'))) into fin from dual; else if(libellemarche='CEMAC CIF Douala') then select to_number(to_char(sysdate, 'dd')) into teste from dual; if(teste<=15) then select to_date(concat('27/',to_char(add_months(sysdate,-1),'MM/YYYY'))) into fin from dual; else select to_date(concat('14/',to_char(add_months(sysdate,0),'MM/YYYY'))) into fin from dual; end if; else if(libellemarche='Marche National') then select next_day(sysdate-14,'Jeudi') into fin from dual; end IF; end IF ; end if; return fin;END fincotation;

PROCEDURE insere_valeur_cotation(cotation in VARCHAR2 , lejour in TIMESTAMP, valeur in number, produit in VARCHAR2) AS BEGIN MERGE into pov_valeur_cotation valcot using dual on (valcot.code_cot = cotation and valcot.jour= lejour and valcot.code_produit= produit) when matched then update set valcot.valeur_cot= valeur when not matched then insert values(cotation,lejour, valeur, produit); commit; END insere_valeur_cotation;


Joël MENGOLO ASSAMBA. IAI-2009 XIII

function calcul_prix(moyenne_cotation number,marche varchar2,libelle varchar2) RETURN NUMBER ASprix number;fa NUMBER;coef NUMBER;prime NUMBER;type_prod VARCHAR2(200);BEGIN if(marche='Marche National') then select categorie_prod into type_prod from pov_produit where libelle_prod like libelle; if(type_prod='homologué') then select coef_corel_prod into coef from pov_produit where libelle_prod like libelle; select fa_prod into fa from pov_produit where libelle_prod like libelle;

prix:=(moyenne_cotation+fa)*(1+ coef);

else select valeur_prime into prime from pov_valeur_prime val, pov_produit prod, pov_marche ma where val.code_marche= ma.code_marche and val.code_produit= prod.code_prod and ma.libelle_marche= marche and prod.categorie_prod= type_prod;

prix := moyenne_cotation + prime ;

end if; else if(marche='CEMAC CIF Douala')or (marche='Exportation maritimes FOB')or(marche='Marche Soutes et Internationales') then select valeur_prime into prime from pov_valeur_prime val, pov_produit prod, pov_marche ma where val.code_marche= ma.code_marche and val.code_produit= prod.code_prod and ma.libelle_marche= marche and prod.categorie_prod= type_prod;

prix := moyenne_cotation + prime ;

end IF; end if; return prix; END calcul_prix;

function calcul_prix_distillat(moyenne_cotation2 number,moyenne_cotation1 number,marche varchar2) RETURN NUMBER AS prix number;coef NUMBER;prime NUMBER;BEGIN select coef_corel_prod into coef from pov_produit where libelle_prod like 'distillat'; select valeur_prime into prime from pov_valeur_prime val, pov_produit prod, pov_marche ma where val.code_marche= ma.code_marche and val.code_produit= prod.code_prod and ma.libelle_marche= marche and prod.categorie_prod='distillat';

prix:=(moyenne_cotation1+ moyenne_cotation1)* coef+ prime;

return prix; END calcul_prix_distillat;

FUNCTION moyenne_cotation(datefin TIMESTAMP,datedebut TIMESTAMP,libelle_cota varchar2) RETURN NUMBER AS moyenne number;BEGIN select avg(valeur_cot) into moyenne from pov_valeur_cotation val, pov_cotation cot where cot.code_cot= val.code_cot and cot.libelle_cot= libelle_cota and val.jour between datedebut and datefin; return moyenne;

Documents

REFONTE DE LA PLATE FORME ARCHITECTURALE DU …xa.yimg.com/.../853096211/name/MengoMemoireV4.0.d… · Web viewRefonte de la plate forme architecturale du patrimoine applicatif