Royaume du Maroc Universit Mohammed V - Souissi Ecole Nationale Suprieure dInformatique et dAnalyse des Systmes - E.N.S.I.A.S.

Mmoire de Projet de Fin dEtudes

Pour lObtention du Titre

dIngnieur dEtat en Informatique

Option Rseaux et Tlcommunications

Sujet

Environnement E-Commerce sur plate-forme Internet

Soutenu par : Mlle. N.FEREHAN Mlle. A.HAJAMI

Membres de jury : M. M.EL KOUTBI(Prsident) M. M.ERRADI(Encadrant) M. L.KIFA(Encadrant)

Anne Universitaire 2000/2001

A mes trs chers parents Comment pourrai-je exprimer ma gratitude envers vous. Merci, pour votre amour, vos sacrifices et votre soutien tout au long de mon parcours. Que Dieu vous garde pour moi et vous donne une longue vie pleine de sant. A ma trs chre sur Naima, qui tait toujours mon ct quand jen avais besoin. Je vous souhaite une vie pleine de bonheur. A mes frres Noureddine et Tarik, A mes petites surs Fikriya, Ibtissam, Hind, et Jalila. Merci. Je vous suis trs reconnaissante. A lensemble de ma famille pour qui jai un grand respect. A ma binme et sur Amina, qui je souhaite bonne chance pour son prochain projet. A mes chres amies avec qui jai pass des instants inoubliables. A la mmoire de Mme Acha Berrada notre professeur lENSIAS. A tous ceux qui me sont chers. Je ddie le fruit de mon projet de fin dtudes.

Nourelhouda

A mes trs chers Parents, Nul mot ne pourra exprimer ma gratitude envers vous. Pour tout lamour et le soutien que vous mavez offerts, pour tout vos sacrifices, pour toutes les belles choses que vous mavez apprises, pour tout, je vous aime beaucoup. Que Dieu vous garde pour moi et vous donne une longue vie pleine de sant. A mon trs cher frre Abdelmajid, jai toujours cherch les expressions qui puissent correspondre ce que tu reprsentes pour moi, mais en vain. Pour texprimer mon respect et mon amour et ma gratitude, je nai pas trouv les termes. A mes trs chers frres, Anass, Zakarya et Mehdi, pour votre soutien, votre sympathie, et votre amour. Mon amour pour vous est aussi immense que la mer et le ciel. A ma trs chre amie Souad, pour tous les moments de notre amiti. A Nourelhouda, pour ton soutien et ta gentillesse. A toutes mes amies, pour tous les moments inoubliables que nous avons passs ensemble. A mes amis, pour votre sympathie, votre soutien et votre encouragement. A tous les gens qui mont soutenue le long de mon parcours. A la mmoire de notre professeur regrette Mme Acha BERRADA. A tous ceux qui maiment, je vous aime plus que vous le croyez.

Je ddie le fruit de mon projet de fin dtudes.

Amina

&Remerciements&

Au terme de ce projet de fin dtudes, nous exprimons notre profonde gratitude et

tenons remercier M. M.ERRADI et M. M.SENHADJI pour leurs directives prcieuses et conseils pertinents.

Nous remercions aussi M. L.KIFA pour sa gentillesse et son soutien le long de la

priode de notre stage.

Nos

remerciements sadressent galement M. M.EL KOUTBI qui a bien voulu

valuer notre travail.

Nos remerciements vont galement Mlle Assia SENHADJI qui na amnag ni son
temps ni son nergie pour nous aider avancer dans notre projet. Sa gentillesse et son dynamisme nous ont touches profondment.

Nous saisissons aussi loccasion pour remercier tout le personnel de COMPUTIME

pour leur gentillesse et leur soutien notamment Jamal, Noureddine, Hamid et Lhoussine.

Que

le corps professoral et administratif de lENSIAS trouve ici nos vifs

remerciements.

Nous remercions toutes les personnes qui nous ont aides, de prs ou de loin, au cours
de ce projet.

Rsum

Le domaine du commerce lectronique via Internet est actuellement en pleine expansion. Les entreprises de toutes les tailles et partout dans le monde cherchent se procurer une solution de E-Commerce. Le march marocain a, lui aussi, besoin de solutions E-Commerce. Plusieurs discussions, missions tlvises, sminaires et runions sont faits pour la promotion de cette technologie dans notre pays. Le dveloppement dune solution pour le commerce lectronique interentreprises ncessite toute une dmarche dtudes avant dentamer la ralisation proprement dite. Il faut, avant tout, faire une tude sur le domaine en question : le commerce lectronique. Cette tude a pour but de connatre lenvironnement gnral et les notions conjointes lE-Commerce. Ensuite, il faut dfinir une architecture gnrale de la solution dsire. Puis, il est ncessaire de connatre, en gros, les diffrents outils de dveloppement pour pouvoir choisir loutil qui rpond plus aux besoins spcifis dans larchitecture prcdemment labore.

Abstract

The area of the electronic trade on Internet is currently in full expansion. Enterprises of all sizes and everywhere in the world seek to obtain a solution of E-Commerce. The Moroccan market needs E-Trade solutions. Several discussions, televised emissions, seminaries and meetings are made for the promotion of this technology in our country. The development of a solution for the Business to business E-Commerce necessitates all a step of studies before to start the realization. It is necessary, before all, to make a study on the area in question : Electronic Commerce. This study has for goal to know the general environment and notions joint to the E-Commerce. Then, it is necessary to define a general architecture of the solution desired. Then, it is necessary to know the different tools of development to be able to choose the tool that replies more to needs specified in the previously elaborate architecture.

Table des matires

Remerciements--------------------------------------------------------------------------------- 4 Rsum----------------------------------------------------------------------------------------- 5 Abstract---------------------------------------------------------------------------------------- 6 Table des matires--------------------------------------------------------------------------- 7 Liste des figures------------------------------------------------------------------------------ 10 Liste des tableaux----------------------------------------------------------------------------- 12 Introduction gnrale----------------------------------------------------------------------- 13

Partie I : Environnement gnral du projet-------------------------------------------- 15 Chapitre I : Description du projet------------------------------------------------ 16

I.1 Description du projet EECPI--------------------------------------------------------- 16 I.2 Dmarche de ralisation du projet--------------------------------------------------- 17

Chapitre II : Prsentation de lorganisme daccueil-------------------------- 19

II.1 Mission et projets stratgiques----------------------------------------------------- 19 II.2 Les services de COMPUTIME------------------------------------------------------ 19 II.3 Secteurs dactivits------------------------------------------------------------------- 20

Partie II : Gnralits sur le Commerce Electronique------------------------------ 21 Chapitre III : EDI : Echange de Donnes Informatis----------------------- 22
III.1 La dmarche de la mise en place de lEDI--------------------------------------- 22 III.2 Les diffrents modes dchange--------------------------------------------------- 24 III.3 Les composants dune architecture EDI------------------------------------------ 25 III.4 Les rseaux EDI---------------------------------------------------------------------- 28 III.5 Les avantages et les services de lEDI-------------------------------------------- 35

ChapitreIV : Le langage Edifact-------------------------------------------------- 37

VI.1 Le standard Edifact------------------------------------------------------------------ 37 VI.2 Le langage Edifact et la scurit--------------------------------------------------- 44 VI.3 Un aperu sur dautres langages--------------------------------------------------- 45

Chapitre V : Le commerce lectronique---------------------------------------- 47

V.1 Vue densemble-------------------------------------------------------------------- 47 V.2 Le commerce lectronique au Maroc------------------------------------------- 47 V.3 Commerce traditionnel et commerce lectronique----------------------------- 48 V.4 Linfrastructure du commerce lectronique------------------------------------ 50 V.5 Lavenir avec le commerce lectronique---------------------------------------- 50

Partie III : Etude de la solution E-Commerce----------------------------------------- 51 Chapitre VI : Architecture de la solution--------------------------------------- 52

VI.1 Architecture gnrale------------------------------------------------------------- 52 VI.2 Scnario B to B-------------------------------------------------------------------- 53 VI.3 Front Office et Back Office------------------------------------------------------ 55

Chapitre VII : Etude comparative des plates-formes et choix de loutil

de travail--------------------------------------------------------- 58
VII.1 Les logiciels sur le march------------------------------------------------------ 58 VII.2 Plate-forme------------------------------------------------------------------------ 60 VII.3 Composants----------------------------------------------------------------------- 63 VII.4 Fonctionnalits-------------------------------------------------------------------- 66

Chapitre VIII : Composants de la solution choisie--------------------------- 69

VIII.1 Les composants de Commerce Server---------------------------------------- 69 VIII.2 Intgration de la traduction Edifact------------------------------------------- 74 VIII.3 Pipeline Editor------------------------------------------------------------------- 75

Conclusion------------------------------------------------------------------------------------- 76 Glossaire---------------------------------------------------------------------------------------- 77 Bibliographie---------------------------------------------------------------------------------- 81

Annexes--------------------------------------------------------------------------------- 82
Annexe A : Pipeline Editor------------------------------------------------------------------- 83 Annexe B : Procdure dinstallation de Commerce Server------------------------------- 93 Annexe C : Larchitecture Client/Serveur-------------------------------------------------- 96 Annexe D : COM/MTS : Le Middleware de Microsoft---------------------------------- 106 Annexe E : Le langage XML----------------------------------------------------------------- 111

Liste des figures

Figure 1 : La dmarche du projet -------------------------------------------------------------- 18 Figure 2 : Architecture dun systme EDI : les interfaces applicatifs--------------------- 25 Figure 3 : Les composantes dune solution EDI : Le traducteur--------------------------- 26 Figure 4 : Couche EDI entre applications et communications----------------------------- 28 Figure 5 : Lien direct entre partenaires-------------------------------------------------------- 29 Figure 6 : Rseaux tiers vus comme une boite aux lettres lectronique ----------------- 31 Figure 7 : Structure du message Edifact------------------------------------------------------ 42 Figure 8 : Le diagramme simplifi du message facture (Invoic)-------------------------- 42 Figure 9 : Schma hirarchique dune transmission en interchange Edifact------------- 44 Figure 10 : Architecture gnrale pour lchange informatis sur Internet-------------- 53 Figure 11 : Scnario Entreprise /Client------------------------------------------------------- 54 Figure 12 : Scnario Entreprise /Transitaire-------------------------------------------------- 54 Figure 13 : Scnario dune transaction bancaire--------------------------------------------- 55 Figure 14 : Les lments du Front office et du Back office-------------------------------- 57 Figure 15 : Architecture technique requise par Commerce Server------------------------ 61 Figure 16 : Architecture technique de WebSphere------------------------------------------ 63 Figure 17 : Les composants de Commerce Server------------------------------------------- 70 Figure 18 : Utilisation du Pipeline dchange commercial--------------------------------- 74 Figure 19 : Intgration de la traduction Edifact---------------------------------------------- 75 Figure 20 : Larchitecture Client/Serveur ---------------------------------------------------- 96 Figure 21 : Architecture Client lourd /Serveur lger---------------------------------------- 97 Figure 22 : Architecture Client lger/Serveur lourd----------------------------------------- 98 Figure 23 : Architecture Client/Serveur trois niveaux------------------------------------ 98 Figure 24 : Architecture Web trois niveaux------------------------------------------------ 101 Figure 25 : Architecture DNA ----------------------------------------------------------------- 103 Figure 26 : Les pages ASP---------------------------------------------------------------------- 104

Figure 27 : MTS---------------------------------------------------------------------------------- 105 Figure 28 : interface, implantation dinterface et instance dinterface-------------------- 107 Figure 29 : Le Middleware COM-------------------------------------------------------------- 109 Figure 30 : Exemple dapplication structure en trois tages ralise avec DCOM---- 110

Liste des Tableaux

Tableau 1 : Exemple de donnes Composites------------------------------------------------ 39 Tableau 2 : Les niveaux dEdifact--------------------------------------------------------Tableau 3 : Les segments de service Edifact -------------------------------------------Tableau 4 : Dlimiteurs Edifact-----------------------------------------------------------Tableau 5 : Nouvelle et ancienne mthode dachat dun produit -----------------------40 41 43 49

Tableau 6 : Diffrentes plates-formes e-commerce sur le march------------------------- 59 Tableau 7 : Comparaison configuration matrielle requise-------------------------------- 60 Tableau 8: Fonctionnalits offertes par : Commerce Server et WebSphere-------------- 68 Tableau 9 : Les composantes en rapport avec ltape denvoi de lordre dachat------- 73 Tableau 10 : Modles standards de cration de pipeline ----------------------------------- 85 Tableau 11 : Comparaison entre larchitecture 2-tiers et 3-tiers--------------------------- 99 Tableau 12 : Architecture DNA --------------------------------------------------------------- 102

Introduction gnrale

Lre actuelle des nouvelles technologies de linformation se concentre sur le commerce lectronique. Cette notion supprime les frontires nationales, impose de nouvelles approches commerciales et invite les diffrents acteurs de lconomie y prendre partie. Cest une faon de bnficier de lvolution des outils informatiques et des bnfices de lInternet qui assure une prsence sur le niveau mondial avec un cot rduit. La mise en uvre scurise du commerce lectronique est une entreprise qui 80% juridique et 20% technique. La solution juridique est un pralable fondamental lutilisation des moyens lectroniques de transmission de donnes commerciales [CIDPCE]. Or la promotion du commerce lectronique se heurte des obstacles dordre juridique cause du dcalage entre le droit et lvolution technique. Au mme titre que lentreprise, ladministration est plus que jamais concerne par le phnomne du E-Commerce. Elle est concerne, dans un premier lieu, parce quelle gre un gisement informationnel immense dont le libre accs doit tre garanti dans des conditions transparentes. En second lieu, elle est concerne par le fait quelle constitue un agent conomique actif de production et dchange de biens et services. Le concept du commerce lectronique envahi divers domaines et se cre des notions conjointes. Ainsi on peut distinguer trois principaux domaines du commerce lectronique : le commerce entreprise/consommateur dit B to C (Business to Consumer), le commerce interentreprises dit B to B (Business to Business), et le commerce entreprise/administration dit B to A (Business to Administration). Les mdias font plus de lumire sur le commerce B to C, alors que le commerce B to B reprsente la partie la plus importante du march. Le B to B concerne les changes et les traitements commerciaux entre entreprises. Depuis les annes soixante, lchange de donnes informatis (EDI) existe au niveau mondial. La mise en place dun systme EDI est coteuse ce qui la rend la porte des grandes entreprises seulement.

Les opportunits offertes par lInternet modifient les perspectives commerciales des petites et moyennes entreprises. LInternet reprsente pour les PME un portail pour entrer dans lre du E-Commerce. Notre projet intitul Environnement E-Commerce sur plate-forme Internet a pour but de proposer une solution pour le domaine du commerce lectronique interentreprises sur Internet. Une solution dsigne aux PME/PMI dsirant avoir leur propre solution E-Commerce. Le prsent rapport est divis en trois grandes parties. Dans la premire partie nous prsentons lenvironnement gnral du projet. Ainsi dans le premier chapitre nous prsentons notre projet. Une prsentation de lorganisme daccueil est faite dans le deuxime chapitre. La deuxime partie du rapport porte sur des gnralits sur le commerce lectronique. Nous y prsentons les principales notions relatives au domaine du commerce lectronique interentreprises. De ce fait le troisime et le quatrime chapitres sont respectivement consacrs la prsentation de lEDI et de la norme Edifact. Nous prsentons ensuite le commerce lectronique dans le cinquime chapitre. La troisime partie contient ltude de la solution E-Commerce. Ainsi nous dtaillons dans le sixime chapitre larchitecture de la solution. Le septime chapitre est une tude comparative des diffrents outils existant de mise en uvre de la solution. Quant au dernier chapitre, il porte sur les composants de la solution retenue avec une proposition dextension. A la fin du rapport, nous prsentons en complment les diffrentes annexes. Ces annexes traitent successivement le Pipeline Editor, la procdure dinstallation de Commerce Server, larchitecture client/serveur, le Middleware COM/MTS, et le langage XML.

Partie

Environnement gnral du projet

Dans cette partie nous prsentons lenvironnement gnral de notre projet Environnement E-Commerce sur plate-forme Internet . Le premier chapitre est une description du projet. Dans le deuxime chapitre nous prsentons lorganisme qui nous a accueillies pendant la priode de notre projet de fin dtudes, savoir la socit COMPUTIME.

Chapitre I

Description du projet

Les opportunits daffaires en matire de gestion de transactions commerciales entre entreprises sur lInternet devraient se multiplier de part le cot rduit de cette plateforme. Des entreprises de toutes tailles peuvent en bnficier. Les PME/PMI ont besoin dune solution E-Commerce sur Internet. Il est donc ncessaire de concevoir et de raliser une architecture du commerce lectronique qui donne la possibilit de monter et de configurer des solutions qui rpondent ce besoin.

I.1 Description du projet EECPI1

Notre projet vise dvelopper un environnement pour supporter le commerce lectronique et spcialement le domaine interentreprises (B to B) sur plate-forme Internet. Il entre dans le cadre des solutions destines aux PME/PMI dsirant avoir leur propre solution pour effectuer des oprations commerciales. Notre solution consiste : Dvelopper un site Web pour le e-business. Cela revient dvelopper un site

Web dynamique qui contient un catalogue des produits avec leur description, et de traiter toute commande lance par les clients. Crer la base documentaire, qui est un systme dinformation contenant toutes les donnes concernant les produits et services de lentreprise, de ses clients potentiels avec leurs prfrences, des produits frquemment consults et achets, et des fournisseurs. Mettre en uvre la base de connaissance qui nest autre quun programme qui permet de guider les clients choisir les produits qui rpondent mieux leurs besoins. Ainsi, suivant un ensemble de critres signals et un besoin exprim, une ou plusieurs solutions sont proposes aux clients. Paramtrer les documents par lEdifact : les documents frquemment changs que ce soit avec les partenaires ou avec la banque tel que la facture, le devis,seront traduits en format standard vrifiant la norme Edifact. Ainsi un systme de traduction sera mis en place pour assurer le codage et le dcodage de ces documents.
1

Environnement E-Commerce sur Plate-forme Internet.

I.2 Dmarche de ralisation du projet

Pour mener bien la ralisation de notre projet, nous avons adopt une dmarche qui assure la matrise du dveloppement du projet, pour ne pas tomber dans le pige du ttonnement de plusieurs chemins qui puisse donner un rsultat qui ne soit ni sr ni matrisable. Nous avons divis le projet en plusieurs tapes. La premire consiste faire une tude pour mieux se familiariser avec les notions de lEDI et le commerce lectronique. Ces notions qui, jusquau dbut de ce projet, nous taient floues, voire inconnues. Une fois les notions relatives au domaine du commerce lectronique et lEDI sont plus claires et mieux connues, il tait possible de donner une architecture bien dtaille de lenvironnement e-commerce qui contient tous les composants ncessaires pour monter une solution en ligne. Ceci tait lobjectif de la deuxime tape. Avant de choisir une plate-forme qui va permettre dimplmenter cette solution, une tude comparative des outils de dveloppement tait primordiale dans la troisime tape. Nous avons consacr la quatrime tape linstallation de lenvironnement de dveloppement. Comme loutil choisi donne plusieurs fonctionnalits, nous lavons adapt notre situation, avant dajouter les composants requis. Ceci est fait lors de la cinquime et la sixime tape. La dernire tape concerne le traitement de site de COMPUTIME. La figure 1 prsente le diagramme des diffrentes tapes du projet.

Etude pralable

Se familiariser avec les notions EDI et commerce lectronique

Conception de larchitecture

Modliser lenvironnement du commerce lectronique

Etude comparative

Comparer les diffrentes platesformes de dveloppement

Installation de la plate-forme

Installation de la plate-forme choisie

Adaptation de loutil

Utilisation des composants

Ajout de nouveaux composants

Mariage Commerce Server et Edifact

Application au site de Computime

Appliquer au cas de Computime

Figure 1 : la dmarche du projet

Les tapes du projet sont ainsi dfinies avec le rsultat de chaque tape. La dernire tape concerne la ralisation du projet pour le compte de la socit COMPUTIME. Le chapitre suivant prsente cette socit qui nous a accueillies pendant la priode du stage.

Chapitre II

Prsentation de lorganisme daccueil

Dans ce chapitre nous prsentons lorganisme daccueil, COMPUTIME. Nous commenons par donner ses missions et ses objectifs stratgiques, ensuite les services quil offre ces clients. Enfin, nous dcrivons ses secteurs dactivit.

II.1 Mission et objectifs stratgiques

COMPUTIME a pour mission doffrir ses clients des solutions dautomatisation de la saisie de donnes pertinentes et de haute performance. Grce son savoir-faire, COMPUTIME permet ses clients davoir accs une technologie de haute gamme pour la construction de leur systme dinformation. La dmarche globale adopte par la socit COMPUTIME pour llaboration de sa politique dentreprise a pour base les principes suivants : Etre en tat constant de veille technologique et prouver les progrs techniques du secteur. Sadapter aux contraintes existantes et proposer des solutions dautomatisation

progressives. Encadrer ses clients dans la mise en place de solutions grce une offre de service couvrant le conseil, lingnierie et le dploiement. Opter pour les meilleurs produits permettant la mise en place dune solution de haute performance.

II.2 Les services de COMPUTIME

COMPUTIME est une socit dingnierie des systmes ADC (Automatic Data Collection). Ses services sont centrs autour du conseil et de lintgration des systmes dIdentification automatique et des systmes dinformation. Compte tenu de son expertise dans les systmes dinformation et son savoir-faire en matire dinterfaage avec des moteurs de bases de donnes existants, COMPUTIME a dvelopp des solutions pour :

Gestion des temps Contrle daccs Suivi de production suivi dobjet Suivi du contrle-qualit Solution pour les points de vente

II.3 Secteurs dactivits

COMPUTIME opre sur trois secteurs dactivits : II.3.1 Etude, Ingnierie et Conception Solutions dans le domaine des systmes dinformation, de codification des donnes, conception des codes barres linaires 1D/2D, Conception des supports : Etiquettes, Tag, Badges, vignettes. Conseil et assistance technique pour le choix de systmes.

II.3.2 Dveloppement Dveloppement dapplication de gestion des temps. Dveloppement dapplication de suivi dobjets. Dveloppement dapplication de suivi du contrle-qualit.

Dveloppement pour les applications des terminaux portables et terminaux industriels. II.3.3 Conception / Ralisation de systmes cls en main Conception, implantation, configuration, assistance technique et formation du personnel sur les systmes dinformation autour de cartes multifonctions : pointage, contrle daccs, suivi des temps dactivit. Mise en place de solutions informatiques globales de codification et didentification automatique. Solutions autour du concept CIM (Computer Integrated Manufacturing).

Nous avons prsent dans ce chapitre un tour dhorizon des activits de la socit COMPUTIME. Dans la partie suivante du rapport, nous exposons des gnralits sur le commerce lectronique.

Partie

II

Gnralits sur le Commerce Electronique

Cette partie porte sur les notions relatives au domaine du commerce lectronique. Nous y prsentons successivement : lEDI, comme forme spcifique du commerce lectronique, lEdifact, le langage standard de lEDI, et enfin le commerce lectronique, en donnant un survol sur ce concept.

Chapitre III

EDI : Echange de Donnes Informatis

Les entreprises tendent actuellement se rapprocher les unes des autres, sous la pression des exigences du climat accrue impos par la mondialisation. Ainsi, une langue commune conventionnelle s'impose en vue d'une universalit de la communication. L'Echange de Donnes Informatis -EDI- offre aujourd'hui des moyens automatiss et normaliss. Ceci permet aux entreprises dchanger des documents, pratiquement sans intervention humaine et en se dgageant des moyens traditionnels comme le courrier ou le tlphone. LEDI est une forme dchange dinformations utilisant les rseaux. Il peut tre dfini comme lchange entre applications htrognes, avec automatisation des traitements. Dans un systme EDI, cest tout le processus dchange qui est informatis. Au-del des classifications, il sagit dune dclaration de principe : LEDI met en jeu un processus informatis, et non seulement une opration isole. Il met en relation des systmes dinformation.

Il a pour objectif des gains en efficacit et en productivit, avec lautomatisation de certains aspects ou de la totalit de ce processus. Ainsi, il sagit dchange non seulement de machine machine mais de systme dinformation systme dinformation. Cet change est effectu sans modifier les applications qui fournissent ou reoivent des informations. Par ailleurs, il sagit bien des changes automatiss. Les pages suivantes essayeront de donner un tat de l'art de cette technologie.

III.1 La dmarche de la mise en place de lEDI

Des travaux, dbats et recherches conceptuelles tournent le plus souvent autour de la dfinition des tapes dun projet de lEDI.

Ainsi, aprs la prise de dcision pour intgrer lEDI dans le rseau communautaire, il convient, en gnral, de suivre les tapes suivantes :

III.1.1 Identifier tous les partenaires du rseau communautaire

La premire tape consiste dterminer lensemble des partenaires selon des critres spcifiques. Ces critres sont : le secteur dactivit, la taille de lentreprise, le style de management et la culture de lentreprise, le type de donnes utilis, ainsi que lenvironnement de lentreprise. Il faut galement dterminer tous les documents changs en utilisant lEDI, ainsi que la part de chaque partenaire en volume documentaire.

III.1.2 Spcifier les scnarios de messages

Cette phase consiste effectuer une tude documentaire pour la transmission de documents par la voie de lEDI et en dduire la liste des messages utiliser. Une srie de recherches ralise pour voir si des messages normaliss et appropris existent dans la liste des documents transmettre. Il faut donc : Analyser la bibliothque des rpertoires de donnes lmentaires utilises. Analyser la bibliothque des rpertoires de segments utiliss.

Analyser la bibliothque des rpertoires de messages utiliss et dterminer le scnario dchange de ces messages. Si lon ne trouve pas de messages appropris, il faudra se rsigner dvelopper de nouveaux messages spcifiques.

III.1.3 Etablir les correspondances entre formats privs et formats normaliss

Cette tape consiste dfinir les dictionnaires lmentaires des donnes, cest dire la rfrence des donnes qui seront changes. Il faut galement constituer le dictionnaire des messages, ce qui correspond aux formulaires destins lchange. Il est recommand dans cette dmarche dutiliser le maximum des lments dj existants dans la norme, surtout la spcialisation des changes logiques. Ce qui revient dfinir les procdures administratives de chaque partenaire en matire de classement, archivage, dition, exploitation en rapport avec les applications spcifiques de chaque utilisateur. Et dterminer la liste des destinataires de chacun des partenaires et les flux de messages pour chaque destination.

III.1.4 Dfinir la norme et les rseaux de tlcommunications

Lors de cette phase, on dtermine la norme utiliser dans lchange et on dfinit la solution technique : matriels, logiciels et les rseaux de communication. Ce choix est conditionn par linfrastructure technique existante au niveau de chaque partenaire. Les problmes de scurit de transmission sont aussi ngocis et rsolus avant de commencer limplmentation de lEDI.

III.1.5 Mettre en uvre le systme

Cette phase est celle de la personnalisation pour chacun des membres de la communaut EDI, avec la prparation des lments matriels et logiciels intgrer. Elle est galement la phase de dveloppement des systmes de conversion de formats, des correspondances et leur mise en uvre. Il est possible la suite de raliser des procdures de test pour valider le modle.

III.1.6 Adopter un accord dinterchange

Lusage de linformatique, dans sa forme tlmatique implique la disparition du papier accompagne de la disparition du e droit qui exige le papier. Cest un vrai heurt entre le droit et linformatique. Le contrat dinterchange a pour but de combler ce vide juridique existant.

III.2 Les diffrents modes dchange

Il existe trois modes dchange pour lEDI :

III.2.1 Le mode autonome

Cette solution consiste installer lensemble de la solution EDI, sur un mme ordinateur. Lactivit EDI est alors entirement indpendante du systme informatique de lentreprise. les donnes ne sont pas changes lectroniquement entre ces ensembles, elles sont traites manuellement entre le logiciel EDI et les applicatifs de gestion de lentreprise.

III.2.2 Le mode intgr

Ce mode consiste installer lensemble de la solution EDI directement sur lordinateur qui supporte les applicatifs. Lactivit EDI est alors entirement intgre dans le systme informatique de lentreprise.

III.2.3 Le mode frontal

Ce mode consiste installer lensemble de la solution EDI sur un ordinateur, qui possde un lien avec le systme informatique. Lactivit EDI est alors indpendante dans ses traitements, mais les applicatifs de gestion et la solution EDI communiquent par transfert. On parle alors de rapatriement et dextraction des donnes.

III.2 Les composantes dune architecture EDI

Lintroduction de la nouvelle technologie facilitera et acclrera lchange de donnes et les transactions commerciales entre les entreprises. En particulier lutilisation de lEDI. Ce systme est constitue de trois composants principaux : Lenvironnement applicatif. Le logiciel EDI. Les systmes de communication.

III.2.1 Lenvironnement applicatif

Il correspond aux applications concernes par les informations changes, et comprend : lensemble des applications qui vont fournir ou rcuprer les informations

changes, les interfaces "pivots" entre ces applications et les logiciels EDI, "Traducteur" ou "Gestionnaire de transactions EDI".

Fichiers Plate Application1

Interface Pivot Traducteur Ou Gestionnaires de

Application2
Base de Donnes des changes

Transactions EDI

Application3

Figure2 Architecture dun systme EDI : les interfaces applicatifs.

III.2.2 Les logiciels EDI Communment appels Traducteur ou aussi Gestionnaire de transactions EDI . Ils assurent comme fonction principale la conversion des donnes, lmission et la rception, dun format propritaire un format Edifact ou inversement. Ces logiciels peuvent assurer, de plus, un ensemble de fonctions complmentaires ayant trait la scurit et la gestion des accordes dinterchange. Gnralement, le traducteur fait appel aux composantes qui figurent sur le schma cidessous :

Systme dinformation

Gestion des fichiers

Traduction des donnes

Gestion de la station

Formatage des donnes Vers les partenaires Gestion des communications

Figure 3 : Les composantes dune solution EDI : Le traducteur

a. La gestion des fichiers Cette tape permet de sortir lapplication vers les partenaires EDI. On parle de fichiers privatifs ou de fichiers applicatifs. b. La traduction des donnes Cette section effectue la traduction du format local au format EDI normalis.

c. Le formatage des donnes Cette composante regroupe les donnes en fonction des profils dutilisation. Elle permet en effet la subdivision en groupes fonctionnels, en messages et en segments. Lensemble sera confi aux rseaux de tlcommunications. d. La gestion des communications Regroupe les protocoles dchange de linformation, la session avec les partenaires, ou avec les rseaux valeur ajoute. e. La gestion de la station Contribue ladministration, aux contrles gnraux, la gestion des erreurs ventuels, le paramtrage.

III.2.3 Les systmes de communication

Larchitecture applicative est supporte par les rseaux de tlcommunication. Dans ce contexte, il faut noter que les diffrents protocoles et systmes de tlcommunication cdent la place un standard universel, celui d'Internet. L'EDI est en gnral support par la messagerie (sur Internet ou d'autres systmes). Cependant, comme pour la messagerie interpersonnelle, il est possible, par exemple, de vhiculer des messages au travers d'HTTP, c'est--dire sur le Web. Quoi qu'il en soit, le systme de communication sous-jacent comprend un outil de gestion de la messagerie, le Message Handling System (MHS). Il est souhaitable que lEDI travaille avec les moyens de communication. Et donc qu'il y ait une forte indpendance entre le systme de traduction/gestion des messages et les outils de communication. Le schma suivant fournit une vue des "couches" transport et applications EDI. Les logiciels de communication dialoguent eux-mmes avec des couches infrieures qui sont celles qui relient les systmes informatiques au rseau.

Figure 4 : Couche EDI entre applications et communications

III.3 Les rseaux EDI

Lorsque des partenaires dsirent changer des donnes informatises, ils doivent tre relis dune manire ou dune autre. Cette liaison peut seffectuer en deux modes : directe ou indirecte.

3.3.1 Echanges directs

En EDI point par point ou direct, les partenaires changent directement des communications lectroniques. En dautres termes, il existe un moyen daccs direct de lordinateur de lexpditeur vers lordinateur du destinataire. Laccs direct est le plus souvent utilis par des lignes tlphoniques et un modem dordinateur.

Un partenaire qui utilise un modem dordinateur compose simplement le numro dappel dun autre partenaire.
Liaison directe

Partenaire 1

Partenaire2

Figure 5: Lien direct entre partenaires

Pour quune liaison directe puisse fonctionner, les organismes doivent tre compatibles dun point de vue communications. Ainsi les partenaires doivent-ils utiliser les mmes protocoles de lignes, de dbits, etc. Les deux parties doivent galement utiliser les mmes standards ou avoir la possibilit de traduction dun standard un autre. De plus puisque lexpditeur appelle directement les partenaires, les parties doivent se mettre daccord sur les heures de disponibilit de chaque systme. Ainsi lordinateur qui reoit doit tre ouvert et libre quand lmetteur envoie son message. Un systme direct peut fonctionner lorsquun organisme communique

lectroniquement avec seulement un petit nombre de partenaires. Cependant lorsque ce nombre augmente, il devient de plus en plus difficile dtablir des liaisons avec chacun dentre eux. Un certain nombre dorganismes changent actuellement des donnes informatises avec de nombreux partenaires au moyen de systmes directs, ou point par point. Mais beaucoup dentreprises estiment trop difficile de maintenir des liaisons directes avec un nombre important de partenaires. En effet, la possibilit dtre reli directement avec de nombreux partenaires relier par protocoles de communication diffrents est extrmement chre.

III.3.2 Liaison indirecte ou passage par un rseau tiers

III.3.2.1 Le rle des rseaux tiers Les rseaux tiers se sont dvelopps, dans la communaut EDI, pour rsoudre les problmes inhrents ltablissement de communication avec plusieurs partenaires.

Les expriences rcentes montrent que la plupart des entreprises se tournent vers un rseau tiers lorsquelles atteignent un volume EDI allant de quatre six partenaires. En fait, un rseau tiers fournit la comptence et lexpertise en matire de communications, et de lquipement ncessaire aux communications lectroniques. De plus un rseau tiers peut offrir des services valeur ajoute, comme la traduction aux standards, les connexions internationales, et les connexions dautres rseaux tiers. On peut utiliser un rseau tiers de deux manires : comme une simple bote aux lettres lectronique ou bien pour des services additionnels. Ceci dans le cadre dun rseau valeur ajoute. III.3.2.2 Le service courrier des rseaux tiers Le service le plus simple que peut fournir un rseau tiers est celui dune boite aux lettres lectroniques. Dans ce cas, le rseau offre un service trs semblable celui fourni par le service postal. Le service postal reoit les lettres des expditeurs, trie le courrier par destinataire et le dpose dans la bote aux lettres du destinataire. Les rseaux tiers fonctionnent exactement de la mme manire, en fournissant des botes lettres lectroniques pour les messages EDI. Comme on le voit sur la figure ci-dessous, un rseau tiers cre une bote lectronique pour chaque partenaire. Lexpditeur transmet des messages informatiss au rseau tiers, habituellement en composant son numro dabonn, sur les lignes tlphoniques. Ce dernier reoit les messages lectroniques et les trie par destinataire. Les messages lectroniques sont alors stocks dans les botes lettres des destinataires, jusqu ce quils soient relevs par un appel du destinataire. La majorit des rseaux tiers permettent leurs utilisateurs de relever leurs messages en attente, en mme temps quils effectuent leurs envois. De plus la plupart des rseaux tiers fonctionnent 24 heures sur 24 et 7 jours sur 7.

Partenaire A

Rseau tiers reoit

Partenaire B

Trie

Bote aux lettres du partenaire A

Bote aux lettres du partenaire B

Figure6 : Rseaux tiers vus comme une bote aux lettres lectronique

III.3.2.3 Avantages des botes aux lettres lectroniques Lutilisation dun rseau tiers comme bote aux lettres lectronique limine un certain nombre de problmes associs aux liaisons directes avec les partenaires. Au nombre davantages que lon en retire, on peut citer : Elimination des problmes de compatibilit des communications

Lun des avantages utiliser un rseau de bote aux lettres(BAL) lectronique est que lentreprise compose un numro dappel unique, celui du rseau tiers. Sa seule obligation est donc dtre compatible avec un seul ensemble de matriels et de spcifications, sur le plan de communication. De plus, la plupart des rseaux tiers sont capables de recevoir et mettent en de nombreux protocoles de communications, et plusieurs vitesses de transmission. En fin en raison du fonctionnement 24 heures sur 24, les zones horaires ne constituent pas un problme. Par exemple, grce sa BAL, une grande socit de produits de consommation courante met et reoit des messages trois heures du matin chaque jour. Cela permet lentreprise de garder la fois ses lignes tlphoniques et son systme informatique

libres, pendant la journe, pour dautres activits. Et lentreprise profite des tarifs rduits puisque les appels se font aux heures creuses. Appel ou connexion unique

Avec une BAL, il ny a quun seul appel effectuer pour pouvoir joindre tous ses partenaires. Lexpditeur appel le rseau tiers qui appelle, son tour, chacun des partenaires. De plus lappel au rseau tiers se fait gnralement un numro vert gratuit ou en passant par un numro local. Lappel est donc tarif au maximum comme un appel local, indpendamment de lendroit o se trouve le partenaire. Informations de contrle

De plus des fonctions de stockage, de rception et dexpdition des messages, BAL fournit galement des informations de contrle. La plupart de ces rseaux gnrent un relev dactivit, qui indique la teneur et la destination des envois, et un relev des messages reus dans la bote aux lettres. Trs souvent, le relev dactivit est tabli par exception , et ne fait tat que des messages de la bote aux lettres qui nont pas t relevs pendant les 24 dernires heures. Mmoire tampon de scurit

Un autre avantage des rseaux tiers et quils agissent comme une mmoire tampon entre lordinateur de lentreprise et ses partenaires. En les utilisant, on peut faire de lEDI, sans avoir aucun ordinateur extrieur directement reli lordinateur de lentreprise. III.3.2.4 Les services valeur ajoute En plus des simples services de BAL, les rseaux tiers sont susceptibles de fournir des services valeur ajoute supplmentaires pour leurs clients EDI. Lorsque ces services supplmentaires sont utiliss, on appelle habituellement le rseau tiers : rseau valeur ajoute ou RVA. Dans son rle de RVA, un rseau tiers est semblable un bureau de poste. Les fonctions usuelles d un bureau de poste peuvent comprendre la prparation du courrier, son tiquetage et son acheminement. Les versions lectroniques de ces fonctions sont ralises par les rseaux tiers, lorsquils jouent le rle des rseaux valeur ajoute. Ces services additionnels incluent :

Les services de traduction

Un important service valeur ajoute fourni par le RVA est la traduction. Un rseau tiers reoit les donnes dans un format spcifique une entreprise donne et traduire cette information au standard EDI. Cela permet de faire lEDI sans pour autant changer les logiciels du systme interne. Une fois donnes envoyer sont extraites des fichiers internes, le logiciel de lordinateur du RVA effectuera la traduction dans la norme EDI avant denvoyer les donnes un partenaire. La traduction par le RVA permet de rduire les temps de dveloppement et de mise en place du logiciel EDI. Mais il faut noter qu long terme, lutilisation dun RVA pour la traduction est une solution plus coteuse que le dveloppement sur place du logiciel appropri. De plus il peut rendre plus difficile encore la dcision de changer de RVA ou de se mettre la traduction au sein mme de lentreprise. La conversion en document papier

Les RVA offrent la possibilit de convertir les documents lectroniques en messages sur papier. Ce format imprim est alors envoy au partenaire concern, qui na pas la possibilit de recevoir les messages en EDI, soit par fax, soit par courrier postal. La prise directe sur le rseau

Un autre service offert par le RVA est la prise directe sur le rseau. Les grandes entreprises permettent leurs partenaires commerciaux daccder aux donnes de leurs systmes. Les partenaires doivent alors composer le numro dappel des ordinateurs des grandes entreprises pour rcuprer linformation. Un RVA, par la prise directe sur le rseau, lance les appels ncessaires pour recouvrir linformation et place les messages dans la BAL. En utilisant ce service, la firme doit seulement effecteur un seul appel, au rseau tiers, pour la fois envoyer et recevoir les messages lectroniques. Mme si ces messages rsident sur lordinateur dun partenaire qui nutilise pas les services dun rseau tiers. Chiffrement et authentification

Le chiffrement et lauthentification sont des possibilits importantes offertes par certains rseaux tiers.

Le chiffrement est le procd qui consiste changer un message EDI en message cod, qui ne peut pas tre lu moins que le destinataire ne possde la cl du code. Lutilisation du chiffrement assure le secret des donnes. Au contraire, lauthentification des donnes nassure pas le secret, mais garantit que les donnes ne sont pas modifies. Lauthentification peut tre utilise comme une forme de signature lectronique, puisquelle permet de vrifier lidentit de lexpditeur. Avec lauthentification, le message EDI est chang en un message cod. Ce dernier est envoy simultanment au destinataire avec le message EDI. Bien quils ne soient pas utiliss pour tous les messages EDI, le chiffrement et lauthentification sont courants dans lactivit bancaire, ou dans dautres secteurs. Ils sont utiliss pour la transmission dinformations financires ou dinformations sensibles.

III.3.3 Association EDI / Internet

Internet va-t-il remplacer lEDI ? Il faut dire que lEDI est un concept indpendant des rseaux de tlcommunications et des langages normaliss de communication, et Internet nest quun support universel de service. Lutilisation du Web actuellement pour lEDI est possible. En effet, la messagerie dInternet (SMTP : Simple Mail Transport Protocol) offre aujourdhui des solutions plus perfectionnes. Afin dautoriser la signature lectronique des messages et leur cryptage, grce la version scurise S/MIME ou le MIME scurise. Ainsi les rseaux valeur ajoute sont donc moins ncessaires, et Internet est tout fait adapt cette nouvelle syntaxe. De quelle faon cette syntaxe intervient-elle en matire de scurit ? Elle fournit lencadrement. Elle prvoit des lments spciaux pour protger les messages individuellement, collectivement et par session dchange. Elle propose des lments daccueil pour les services dauthentification, dintgrit, de signature et de confidentialit. Il sagit dune structure daccueil indpendante des rseaux et des protocoles qui facilitent les interactions entre les traducteurs dun systme EDI.

III.4 Les avantages et les services de lEDI

LEDI est une technique qui agit sur tous les niveaux organisationnels de lentreprise. Plus loin encore, il permet de : Rationaliser les flux dinformation externes de lentreprise, Mtamorphiser la culture de lentreprise, Et bouleverser le systme traditionnel des circuits papiers.

Ses avantages sont multiples et stendent plusieurs dimensions. Nous allons classer, ci-dessous, ses services et ses portes par catgorie :

III.4.1 Portes stratgiques

Permet de protger des segments de march.

Capture de nouveaux segments pour le dveloppement de lavantage concurrentiel. Augmente les ventes et le nombre de clients. Amliore limage de marque.

III.4.2 Portes pour lorganisation administrative

Rduit le pourcentage derreurs. Amliore la qualit de linformation. Elimine la double saisie. Supprime les pnalits de retard. Amliore ltat des stocks. Rduit le cot du papier, des fax, poste et tlphone. Amliore la qualit de service. Rduit le nombre demploys.

III.4.3 Au niveau du cycle commande- livraison- paiements

Acclre les processus transactionnels et les rglements (commandes, factures, rglements). Compresse les dlais.

III.4.4. Au niveau des relations avec lenvironnement

Amliore les relations avec les organisations et partenaires.

Partage les bnfices avec les partenaires. Fidlise la clientle.

III.4.5 Portes pour le systme dinformation

Amlioration de la rponse lvnement (justesse, prcision, qualit de linformation). Suivi logistique de bout en bout. Gain de place et de temps. Meilleure structure des archives. Crdibilit leve des statistiques. Contrle lev des cots. Couverture plus importante des besoins. Interfaage automatique des applications de lentreprise. Communication banalise avec tous les partenaires.

Selon les besoins et les sensibilits techniques des diffrents secteurs dactivits, plusieurs langages EDI ont t conus et mis en place. Ceci avant daboutir une convergence vers le plus structur mais aussi le plus polyvalent dentre eux : le langage universel Edifact. La description de ce langage sera lobjet du chapitre suivant

Chapitre IV

Le langage Edifact

LEDI est conu pour que lordinateur qui reoit les donnes, puisse les lire et les traiter, sans intervention humaine supplmentaire. Cela signifie que les donnes doivent apparatre dans un format cod plutt que textuel. Alors quun employ lentre des commandes peut examiner deux demandes dachat totalement diffrentes et den extraire linformation pertinente. Un ordinateur ne le peut pas. Ce dernier a de grosses possibilits en efficacit et prcision. Mais il ne peut pas reconnatre pour identique des informations semblables, dans des formats ou des positions diffrentes. Il faut donc lavertir, lavance, du type dinformation quil va recevoir et du format sous lequel elle se prsente. Linformation doit alors tre transmise sous cette forme spcifique afin dtre lue et comprise par lordinateur qui la reoit. Les standards ou normes EDI fournissent la structure requise pour permettre aux ordinateurs de lire, comprendre et traiter les documents daffaires. Plusieurs langages ont t dvelopps. Dans ce chapitre nous allons dcrire le langage Edifact. Ensuite nous donnerons un aperu sur dautres langages.

IV.1 Le standard Edifact

United Nations Electronic Data Interchange For Administration, Commerce And Transport. Ce langage est destin tre la norme mondiale en matire de lEDI. LEdifact se compose de deux niveaux : le niveau syntaxique et le niveau smantique. Limportance du niveau smantique diffrencie Edifact des autres langages techniques. Le niveau syntaxique permet dorganiser le discours grce des sparateurs, des groupements de donnes de messages, et par des enchanements de messages en scnarios. Les lments de service sont grs ce niveau (metteur, destinataire, date et numro des messages, rfrences aux applications traites), par des segments de services de la syntaxe.

Le langage Edifact se compose principalement de : - dun vocabulaire, le dictionnaire des donnes lmentaires appel TDED (Trade Data Elements Directory - Norme ISO 7372). - dune grammaire, les rgles de syntaxe Edifact au niveau application (Norme ISO 9735).

IV.1.1 Le dictionnaire des donnes (TDED)

Chaque donne lmentaire du TDED comprend : - une dsignation alphabtique et un indicatif numrique (TAG). - une description smantique. - une note (observation supplmentaire). - une rfrence qui renvoie une autre section si la note ne suffit pas. - des synonymes. Lindicatif numrique est compos de 4 chiffres. Chaque groupe de mille correspond une catgorie de donnes. Alors que les donnes internationales occupent les 500 premiers nombres, ainsi on a la classification : - Groupe 0 (0000-0499) : - Groupe 1 (1000-1499) : - Groupe 2 (2000-2499) : - Groupe 3 (3000-3499) : - Groupe 4 (4000-4499) : - Groupe 5 (5000-5499) : - Groupe 6 (6000-6499) : - Groupe 7 (7000-7499) : - Groupe 8 (8000-8499) : - Groupe 9 (9000-9499) : Donnes de service. Documentation, rfrences. Dates , heures, intervalles, temps. Parties, adresses, lieux, pays. Clauses, conditions, termes, instructions. Montant, frais, pourcentage. Intituls de mesures, qualits. Marchandises et articles : description et intituls. Modes et moyens de transport, conteneurs. Elments de donnes de secteurs particuliers ( banques, douanes, etc). Les chiffres suivants indiquent : - pour la srie de 000 499 : les donnes internationales.

- pour la srie de 500 799 : les donnes nationales. - pour la srie de 800 999 : les donnes sectorielles.

IV.1.2 Les donnes lmentaires du TDED

Ce dictionnaire comprend trois types de donnes : - alphabtique reprsent par le symbole a. - numrique reprsent par le symbole n. - alphanumrique reprsent par le symbole an. Chaque donne est soit : composite : compos de plusieurs donnes ordonnes, son indicatif numrique

commence par C. Et les donnes qui constituent la donne composite sont soit obligatoires (M : Mandatory), soit facultatives (C : Conditionnal). CC118 INFORMATION PRIX UNITAIRE 5110 5821 Prix unitaire Code de base du prix unitaire Base du prix unitaire Spcificateur de lunit de mesure M C n..15 nature de la devise an..2 ex: CT contractuel Etat Commentaires

5284 6410

C C

n..9 ex : par millier an..3 ex : par paire

Tableau 1 : Exemple de donne composite

Code : on peut associer une seule donne lmentaire plusieurs codes, par exemple la donne lmentaire Mode de paiement possde une liste de codes associs. Qualifiantes : afin de diminuer le nombre de donnes manipuler et denrichir la prcision sur les significations des donnes, on utilise les valeurs qualifiantes. Les valeurs qualifiantes sont capitales car elles permettent de prciser lexacte signification dune donne gnrique. Les valeurs qualifiantes sont enregistres sous forme de code, et regroupes dans le Code Sets Directory.

IV.1.3 Les niveaux dEdifact

Le langage Edifact se structure laide de listes embotes les unes dans les autres. Le tableau suivant rcapitule lensemble de ces niveaux dembotement, du plus grand au plus petit :
Embotement Plus grand Nom du niveau Interchange Groupe fonctionnel Message Groupe de segment Segment Composite Elment Plus petit Alphabet Se comporte comme Dossier Intercalaire Message Fiche Information Expression Mot ou code Alphabet Tableau 2 : Les niveaux dEdifact Edifact Rgles syntaxiques Rgles syntaxiques Vocabulaire Rgles syntaxiques Vocabulaire Vocabulaire Vocabulaire Rgles syntaxiques

Pour certains de ces niveaux, Edifact dfinit uniquement des rgles syntaxiques. Tandis que pour dautres, la norme dfinit une smantique, ventuellement utilise par les rgles. Par exemple la syntaxe du niveau message stipule que tout message commence par le segment UNH.

IV.1.4 Structure du segment Edifact

Le segment Edifact est un regroupement de donnes simples ou composites. Ce regroupement de donnes en segment est rgi par les rgles suivantes : - Les donnes regroupes en des segments agences en fonction des utilisateurs auxquels elles sont destines. - Le regroupement prend en compte les donnes qui sont produites, stockes et transmises en mme temps. - Le regroupement des donnes relatives aux mme fonctions est obligatoire. Ceci pour faciliter la tche de lutilisateur.

La structure dun segment comporte : Une tiquette de segment, appele TAG reprsente par 3 caractres alphabtiques. Un intitul du segment.

Une suite de donnes simples ou composites suivies de leur statut obligatoire (M) ou facultatif (C). Il existe un type particulier de segments : les segments de contrle. Ces derniers contiennent des informations tels que lmetteur du message, la date de transmission. Les segments de contrle ont un TAG qui commence toujours par UN. Le tableau ci dessous prsente les segments de contrle qui interviennent dans un accord dinterchange :
Intitul du segment Avis de chane de caractre de service Segment den-tte de contrle dchange Entte de groupe fonctionnel Entte de message Segment de dlimitation du message Segment de dlimitation S du message Fin de message Fin de groupe fonctionnel Fin dInterchange TAG UNA UNB UNG UNH UNS UNS UNT UNE UNZ Tableau3 :Les segments de service Edifact Statut C M C M C C M C M

IV.1.5 Structure du message Edifact

Le message Edifact est un ensemble de segments structurs sous forme arborescente. La lecture du message se fait par le parcours de larbre en profondeur de gauche droite.

UNG '

Message

Message

Message

Message

UNE '

UNH '

Segment

Segment

Segment

Segment

UNT '

EN TETE + lment de donne simple +

lment de donne composite

'

Code : Valeur

Valeur

Elment de donne constitutive

Elment de donne constitutive

Valeur

Valeur

Figure 7 : Structure du message Edifact

La facture est le document le plus chang entre les entreprises. Dans ce diagramme, on prsentera le message facture. Chaque segment est reprsent par une case dont les trois parties reprsentent le TAG du segment, son statut et le nombre de rptitions.

Message INVOIC simplifi

UNS M 1

IMA M 1

UNT M 1

ACI C 10

FIX C 5

ALC C 1

IXS C 10

VAL C 2

PRP M 1

CNT C 5

ALI C 5

TRI C 5

ACA C 5

FTX C 5 C 10

RFF C 1 C 25

Groupe de segments

Figure 8 : Le diagramme simplifi du message Facture (Invoic)

IV.1.6 La syntaxe de codage

Le codage dun message Edifact est ralis en ASCII, partir du diagramme. Les diffrents lments dun message sont dlimits par des caractres. En voici quelques-uns :

+ : ?

fin de segment sparateur ou en-tte de segment sparateur de donnes constitutives caractre suspensif Tableau4 : Dlimiteurs Edifact

Pour lexemple de la facture (du message Invoic) , nous prsentons un extrait du codage : UNA :+. ?UNB+UNOA :1+5012345678901 :14+123456 :91+901111 :1236+REF01+ PASSW+INVOICUNH+INV001+INVOIC :90 :1 :UNBGM+380+75-064-H227101+901111NAD+SU+5013456000145 :14++ICI CHEMICALS AND POLYMERS+POBOX90 :WILTON+MIDDLESBOROUGH++T568

IV.1.7 structure de linterchange

Lorganisation des messages est normalise grce linterchange Edifact. LEdifact permet lidentification du destinataire logique de lensemble des messages en la mettant sous enveloppe . Cette enveloppe se diffrencie de celle de communication utilise pour identifier le destinataire suivant la norme de communication. Le dbut et la fin dun groupe fonctionnel sont indiqus par deux segments de service. UNG et UNE. Le segment UNA indique des drogations aux rgles de syntaxe Edifact. Tous ces segments sont optionnels. La figure suivante prsente la forme dune transmission en Interchange Edifact

Etablissement

CONNEXION

Fin

INTERCHANGE 1

INTERCHANGE i

INTERCHANGE n

UNA '

UNB

Groupe fonctionnel Groupe fonctionnel Groupe fonctionnel

UNZ '

UNG '

Message

Message

Message

Message

UNE '

UNA : Segment de service UNB : Segment d'Entte d'interchange UNZ : Segment de Fin d'interchange

UNG : Segment d'en tte de groupe fonctionnel UNE : Segment de Fin de groupe fonctionnel

Figure 9 : Schma hirarchique dune transmission en interchange Edifact

IV.2 Le langage Edifact et la scurit

Le langage Edifact est considr comme faible du point de vue de la scurit. Dans les mises en uvre actuelles, il est ncessaire dadjoindre des lments complmentaires pour rsoudre les divers besoins de protection. Cette situation est profondment modifie par la dernire version de la syntaxe Edifact, la version 4. Si celle-ci assure une parfaite compatibilit ascendante avec les versions antrieures, elle propose galement de nombreuses fonctionnalits pour rpondre aux exigences en matire de scurit dun systme de commerce lectronique. Deux solutions sont proposes pour rsoudre les diffrents besoins de scurit : regrouper sous les termes de scurit jointe et scurit disjointe [LANGLOIS].

IV.2.1 La scurit jointe

Le principe de la scurit jointe est de transmettre les lments de scurit avec les donnes objets de cette scurit. Pour mettre en uvre ces procdures, il faut ajouter dans les messages Edifact des segments de scurit en tte et en queue des donnes applicatives.

IV.2.2 La scurit disjointe

Elle est utilise pour envoyer les lments de scurit indpendamment des donnes objets de la scurit. Ce besoin de scurit peut tre complmentaire de la scurit jointe.

La scurit disjointe est assure au moyen du message AUTACK. Celui-ci permet denvoyer en un seul message plusieurs lments de scurit correspondants un ou plusieurs lments Edifact. Il est aussi possible de scuriser le message AUTACK luimme. La version 4 de la syntaxe Edifact favorise encore plus Internet et en gnral les rseaux moins scuriss.

IV.3 Un Aperu sur dautres langages

Nous verrons successivement la norme ANSI X12, le langage SGML, le langage Galia, le langage Gencod, propre au secteur de la distribution. Et le langage CFONB, propre au rseau bancaire.

IV.3.1 ANSI X12

Le dveloppement de cette norme a commenc en 1978, il est compos de : Un ensemble de standards de transactions. Un rpertoire de donnes. Un rpertoire de segments. Une norme de contrle de transmission.

IV.3.2 SGML
Dvelopp par les spcialistes de ldition et de limprimerie en 1986, Standard Generalized Markup Language est un langage de balisage gnralis. Il permet de dcrire un document comme un ensemble organis. SGML permet dune part de dcrire la structure dun document, dautre part de reprer dans ce document les diffrents lments (chapitre, paragraphe, notes, titres,).

IV.3.3 Galia
Cest le Groupement pour lAmlioration des Liaisons dans lIndustrie Automobile, la norme sappelle ODETTE. Elle utilise une partie de la norme X12 au niveau des rpertoires de donnes.

IV.3.4 GENCOD
Gencod est une norme EDI assez rpandue en France et destine plus particulirement au secteur de la distribution. Le service Alegro propos par les associations de promotion de Gencod. Il aide les entreprises du secteur mettre en place un rseau EDI Gencod.

Ceci avec une complte intgration de la gestion code barres utiliss par les acteurs de la grande distribution. Aujourdhui le rseau Gencod propose une migration progressive vers la norme Edifact.

IV.3.5 CFONB
Plutt quun langage, CFONB est en faite une srie de rgles dutilisation de formats de fichiers structurs. Cette structure est capable dtre traits par les systmes dinformations des banques et par le rseau valeurs bancaire. Aprs avoir dfinir les concepts EDI et Edifact, nous prsenterons dans le chapitre suivant le commerce lectronique.

Chapitre V

Le Commerce Electronique

Notre projet est directement li au concept du commerce lectronique interentreprises. Ce chapitre est consacr la prsentation de ce concept. Aprs une vue densemble du E-Commerce au niveau mondial, nous prsentons le commerce lectronique au Maroc. Nous effectuons une comparaison entre le commerce traditionnel et le commerce lectronique, avant denchaner avec linfrastructure ncessaire pour cette nouvelle technologie. Nous terminons ce chapitre par lavenir promis par le concept en question.

V.1 Vue densemble

Le commerce lectronique se dfinit essentiellement comme processus de vente et dachat de produits et de services sur lInternet, mais il se caractrise par bien dautres aspects. A ses dbuts, il englobe la gestion de transactions dachats et de transferts de fonds sur des rseaux dordinateurs. Il stend dsormais la vente et lachat de nouveaux produits tel que linformation lectronique. Le commerce lectronique interentreprises ne cesse de crotre en partie grce lInternet. De petites entreprises peuvent dsormais traiter on-line au mme titre que les plus grandes. Quelle que soit leur taille, les entreprises peuvent tirer parti de lInternet pour rduire les cots de gestion de commerce lectronique. Et ceci en remplaant dautres rseaux par lInternet. Le commerce lectronique ne se rduit pas aux transactions dachat et de vente de biens ou de services qui gnrent directement un revenu. Ce systme englobe dautres formes de transactions qui permettent dassurer des revenus de manire indirecte. Nous citons la cration de besoins suscitant une demande se rapportant un bien ou un service, ou aussi la fourniture de support de vente. Ajoutons ceci le fait dassurer un service aprs vente ou encore, faciliter les changes entre entreprises partenaires.

V.2 Le Commerce lectronique au Maroc

Les PME/PMI marocaines sont peu utilisatrices de technologies de l'information et des communications alors que celles-ci constituent un facteur cl de leur comptitivit. L'utilisation de lInternet a un impact sur le march national. Elle garantit : une amlioration de la qualit des produits et services offerts.

de nouvelles opportunits daffaires. une large prsence des produits et services. la rduction des cots de revient.

la gnration demplois dans les domaines du dveloppement de logiciels, de contenu et de services. une rationalisation des flux de production. une meilleure gestion financire.

En outre, lefficacit et la pertinence du recours lInternet, deviennent des lments discriminants dans la concurrence. Cela implique que les entreprises en fassent une priorit stratgique. Le rseau public marocain de tlcommunications est entirement numris et offre dj la quasi-totalit des services de tlcommunications de base et valeur ajoute. Donc on peut dire que linfrastructure du commerce lectronique existe au Maroc, et il suffit dimplmenter les solutions. Ltat marocain sest impliqu dans le domaine du commerce lectronique. En effet, le Maroc est conscient des opportunits offertes par le commerce lectronique pour le dveloppement des entreprises nationales. Cest pourquoi il a engag la rflexion sur les instruments ncessaires au dveloppement de cette nouvelle forme de commerce. Il a institu cet effet un comit Interministriel pour le Dveloppement et la promotion du Commerce Electronique[CIDPCE].

V.3 Commerce traditionnel et commerce lectronique

Les changes traditionnels sont gnralement raliss par courrier, tlcopie ou tlphone. Les documents transmis ne sont pas normaliss et demandent de la part des oprateurs un effort dinterprtation avant de pouvoir tre pris en charge par le systme dinformation de lentreprise. Dans le domaine du commerce lectronique, les changes sont entirement dmatrialiss, et la grande partie des traitements lest aussi. En comparant le cycle de vente dune transaction traditionnelle celui dune transaction lectronique (voir tableau 5), on peut noter bien des similitudes. Seules les mthodes dobtention et de transmission de linformation varient. Dans une transaction traditionnelle, de multiples vecteurs de communications diffrents sont indispensables. Cette diversit a pour consquence de compliquer la coordination des oprations et dallonger considrablement le temps de traitement dune commande. En revanche, dans le cas dune transaction lectronique, linformation est numrise de bout en bout

et il nexiste quun seul vecteur de communication. Seules les applications de transfert et de traitement des donnes diffrent[LANGLOIS].
Etape du cycle de vente Commerce traditionnel (multiples vecteurs de communication) Commerce lectronique (unique vecteur de communication) Recherche dinformations sur un produit Commande de produit Confirmation de commande Vrification de prix Vrification de disponibilit Passation de la commande Envoi de la commande(client), rception de la commande(fournisseur) Spcification dune commande prioritaire Base de donnes en ligne Vrification de disponibilit au dpt Formulaire imprim, tlphone, fax Base de donnes en ligne, pages Web Planification de la livraison Formulaire imprim E-mail, base de donnes en ligne Gnration de la facture Formulaire imprim Base de donnes en ligne Rception du produit Confirmation de rception Envoi de facture (fournisseur); rception de facture (client) Echance de paiement Formulaire imprim EDI, base de donnes en ligne Envoi rglement (client) ; rception rglement (fournisseur) Tableau 5 : Nouvelle et ancienne mthode dachat dun produit Courrier EDI, EFT Livreur Formulaire imprim Courrier E-mail E-mail, EDI Magazines, reprsentants, catalogues Lettres, formulaires Lettres, formulaires Catalogue Tlphone, fax et confirmation de prix Formulaire imprim Fax, courrier E-mail, pages Web E-mail, EDI Pages Web E-mail E-mail Catalogue en ligne

V.4 Linfrastructure du commerce lectronique

La mise en place dun systme du commerce lectronique requiert une infrastructure matrielle et logiciel bien dfinie. Elle est fonde sur le principe du Client/serveur. La communication rseau est la base du commerce lectronique, et le rseau Internet est le support qui prend plus dampleur. Linfrastructure rseau englobe tous les moyens de communication mis en uvre pour transmettre linformation. Elle runit toutes les technologies Internet, savoir la pile de protocoles TCP/IP. Le middleware est une rponse aux besoins de toute entreprise possdant une informatique interne et quelle veut continuer dvelopper sans rupture de processus[LANGLOIS]. Les nouveaux logiciels doivent changer des informations avec les logiciels existants. La structure de communication inter applications revt une importance primordiale. Elle conditionne lajout dun nouveau logiciel sans rupture du plan de dveloppement informatique. Les extensions et les dveloppements peuvent tre envisags pour des applications externes. Cest en ce sens que les techniques du middleware peuvent tre utilises comme des outils du commerce lectronique. Le commerce lectronique ncessite un certain degr de scurit pour protger les diffrentes informations changes entre les entreprises. Pour viter toute fraude et assurer en plus un paiement scuris, des protocoles de scurit ont t mis en place (SSL, SET,).

V.5 Lavenir avec le commerce lectronique

Le dveloppement des changes lectroniques est au cur de la dynamique conomique des annes venir. Il entrane des changements profonds dans lorganisation et le fonctionnement des entreprises, dans leurs rapports avec les clients et dans leur comportement sur le march mondial. Lefficacit et la pertinence du recours aux technologies de linformation et de la communication deviennent des lments discriminants dans la concurrence. Cela implique que les entreprises et les Administrations, ensemble, en fassent une priorit stratgique.

Partie III
Etude de la solution E-Commerce
Cette partie porte sur ltude de la solution E-Commerce. Nous dtaillons dans le sixime chapitre larchitecture gnrale de la solution. Le septime chapitre est une tude comparative des diffrents outils existant de mise en uvre de la solution. Quant au dernier chapitre, il porte sur les composants de la solution retenue.

Chapitre VI

Architecture de la solution

La solution propose peut tre prsente de plusieurs points de vue. Une prsentation en schma global donne une ide gnrale sur la solution et ses fonctionnalits, et exprime les critres de choix de loutil de dveloppement. Ensuite nous prsentons le scnario du commerce lectronique entre entreprises. Les fonctionnalits sont prsentes avec plus de dtail dans un schma Front Office et Back Office.

VI.1 Architecture gnrale

Aux exigences matrielles de la mise en place dune solution de commerce lectronique, sajoutent les exigences logicielles. Larchitecture Client/Serveur est la base de lutilisation des rseaux informatiques. Limportance des donnes traites dans le domaine du E-Commerce impose lutilisation des bases de donnes. Notre solution fait appel la traduction Edifact, ce qui implique lintgration dun traducteur dans la pile des logiciels utiliss. Lutilisation du rseau Internet correspond lutilisation de la pile de protocoles TCP/IP. Ces donnes esquissent les composants principaux dune solution E-Commerce. La figure suivante donne larchitecture gnrale des changes informatiss sur plateforme Internet. Aussi prsente-t-elle les principaux composants mise en jeu pour la ralisation de la solution.

Systme dinformation

Base Serveur Web documentaire

ODBC/JDBC Site Marchand Traducteur Edifact

Base de connaissances

Internet TCP/IP

Navigateur

Traducteur Edifact

Systme dinformation

Partenaire (Client, Fournisseur, transitaire, banque)

Figure 10 : Architecture gnrale pour lchange informatis sur Internet

VI.2 Scnario B to B
Lenvironnement des changes commerciaux pour lentreprise fait intervenir tous les partenaires de lentreprise, fournisseurs, clients ou aussi transitaires. Nous pouvons aussi considrer la participation de la banque dans ces changes. Entreprise / Client Les changes entre lentreprise et ses clients concernent les devis, les bons de commande, les bons de livraison et les factures. Le schma suivant illustre ce scnario.

Entreprise Devis

Client

Bon de commande

Bon de livraison

Facture

Figure 11 : Scnario Entreprise/Client

Le scnario dchanges Entreprise/Fournisseur est le mme que le scnario prcdent, le fournisseur prend la place de lentreprise, et cette dernire prend la place du client. Entreprise/Transitaire Les messages changs entre lentreprise et le transitaire sont : la rservation, la confirmation de la rservation, lordre de transport, statut de transport et lavis darrive envoy par le transitaire au client.

Entreprise

Transitaire

Client

Rservation Confirmation Ordre de transport Statut du transport Avis darrive

Figure 12 : Scnario Entreprise/Transitaire

 Transaction bancaire Pour ce qui est de lchange avec la banque, toutes les transactions ont le mme principe. On prend par exemple limplication de lentreprise et le client dans une transaction. Les documents changs sont : ordre de paiement, tat de traitement bancaire, avis de paiement, avis de dbit, avis de crdit et lextrait de compte.

Entreprise Ordre de paiement Etat du traitement

Banque de lentreprise

Banque du client

Client

Avis de paiement

Communication inter-bancaire

Avis de dbit Extrait de compte

Avis de crdit Extrait de compte

Figure 13 : Scnario dune transaction bancaire

VI.3 Front Office et Back Office

Le systme E-Commerce peut tre dfini comme compos de deux parties. La premire partie, dite Front Office, groupe les interfaces et les champs de saisie des donnes. La deuxime partie, dite Back Office, assemble les diffrents traitements sur les documents changs et la validation des donnes saisies. VI.3.1 Front Office Le Front Office comprend les diffrentes interfaces utilisateurs. Lenvironnement commerce lectronique que nous avons conu est prsent aux utilisateurs sous forme de site Web. Il est divis en deux parties : - Une premire partie pour les visiteurs non identifis. - Une seconde partie pour les clients identifis. Cette partie donne plus de priorits aux clients par rapport aux autres visiteurs. Le site est dvelopp sur les axes suivants :

- Le catalogue en ligne, pour la prsentation des produits et services vendre. - Formulaire dinscription des clients. - Formulaire didentification des clients. - Le formulaire des besoins, pour aider les clients qui ont des besoins spcifiques et qui narrivent pas faire un choix prcis (Commande guide). - Le formulaire de commande. - Linterface de paiement (relation avec la banque). VI.3.2 Back Office Le Back Office contient les traitements des donnes correspondant aux interfaces du Front Office prsent ci-dessus. A savoir : - Mise jour et maintenance du catalogue. - Vrification des comptes et mots de passe. - Base documentaire et base de connaissance. - Prise en compte des commandes. - Gnration et validation des factures. - Mise jour du systme dinformation. - Traitement du paiement. La figure 14 rsume les composants du Front Office et du Back Office. Larchitecture gnrale est ainsi dfinie. Nous signalons que les exigences de scurit vont tre prises en charge dans tous les traitements les ncessitant. Dans le chapitre suivant nous exposons ltude comparative effectue pour le choix de loutil de dveloppement de la solution.

Front Office

Back Office

Client

Entreprise

Banque

Catalogue en ligne Prsentation des produits et services vendre Inscription Saisie des information sur le client Identification Saisie du compte et mot de passe Commande guide Spcification des besoins du client

Base de donnes catalogue Mise jour du catalogue

Attribution de comptes Alimentation de la base de donnes Client

Validation de comptes Vrification du compte et mot de passe Base de connaissance Base documentaire Recherche des solutions partir de la base documentaire en se basant sur la base de connaissance

Commande Slection des besoins et validation de la commande

Traitement de la commande Prise en compte de la commande

Facture Rception de la facture

Facture Gnration et traduction Edifact de la facture Emission de la facture Paiement

Paiement Ordre de paiement Emission de ltat de : traitement avis de paiement avis de dbit

Figure 14 : Les lments du Front Office et du Back Office

Chapitre VII

Etude comparative des plates-formes et choix de loutil du travail

Pour raliser un site de commerce lectronique, une entreprise doit choisir les produits les mieux adopts son activit et ses besoins. Il existe un grand nombre de solutions sur le march. Chacune assurant une ou plusieurs des fonctions ncessaires la vente en ligne : serveur Web, cration de catalogue, moteur de recherche, gestion de panier virtuel, calcul de TVA et de paiement scuris et interface avec des solutions externes. Avant de se lancer dans le dveloppement dun site commercial, une tude comparative des diffrentes solutions possibles est cruciale. Nous allons prsenter les logiciels existants sur le march, puis tablirons une comparaison entre deux produits : WebSphere Studio dIBM et Commerce Server de Microsoft.

VII.1 Les logiciels sur le march

Sur le march actuel, il existe une varit des solutions logiciels. Nous avons repris cidessous sous forme de tableau, l'offre logiciel sur le march, sous les rubriques suivantes : nom du produit, diteur, plate-forme, brve description.

Produit e-commerce 2.0

Editeur Ubiquis

Plate-forme NT

EfrontOffice 9.0

Clarify

Enfinity

Intershop

NT, UNIX, ORACLE, SUN SOLARIS NT, SUN, HP

Description e-commerce 2.0 permet la cration automatise de sites commerciaux, une synchronisation automatique entre les donnes du site web et le systme de gestion de lentreprise, interface avec les solutions de paiement scurise La version eFrontOffice 9.0 sappuie sur les modules de gestion client jusqualors proposs(service client, gestion des ventes et marketing). du ct client, eOrder gre les commandes en ligne et eConfigurator, un outil de configuration produit. Serveur marchand, Enfinity, le moteur de transaction gre les flux entre les modules intelligent merchandiser(commerce intelligent), Remote XML interface(gestion XML), pipeline orchestrator et Cartridge API ( dveloppement sur mesure) Lditeur met laccent sur les fonctionnalits lies la personnalisation du contenu. i.Sell travaille base de deux composants : i.Sell Merchandiser qui permet de raliser une boutique en ligne, back office compris(gestion de commandes, catalogue lectronique, gestion des prix, des promotions, des systmes de fidlistion, etc.) et i.Sell Personnalizer vise positionner les logiciels dinformix face la concurrence Loutil store cre les profils clients, charge la base de produits, gre les promotions et gnre des rapports daudiences. Le logiciel fournit un historique des commandes en ligne et dispose dun systme de messagerie intgr afin dassurer la communication client/commerant. IStore 3i sadresse aux entreprises qui souhaitent un dlai de rponse au march le plus court possible. Factur plusieurs centaines de milliers de francs selon la puissance du serveur Loutil permet de crer, grer, administrer un site commercial, facile utiliser. Serveur marchant, nouvelle version de Net.commerce, le logiciel gre la globalit des transactions du site. La solution bnficie dsormais des capacits douverture de Websphere 3.0 vers les gros systmes et vers XML.la version inclut aussi la technologie Blaze advisor pour la personnalisation.

i.Sell 2.0

Informix

NT,UNIX

IStore 3i

Oracle

Sun Solaris, HP-UX, Compaq Trusted6 4,UNIX, AIX, NT NT NT, AIX, Sun Solaris

Commerce Server Websphere Commerce suite 4.1

Microsoft IBM

Tableau 6 : Diffrentes plates-formes E-Commerce sur le march

Nous choisissons parmi les diffrents produits, deux plates-formes qui correspondent deux grands diteurs mondiaux, savoir Commerce Server de Microsoft, et WebSphere dIBM. Nous effectuerons une comparaison entre ces deux solutions. Cette comparaison stablit sur trois axes, savoir la plate-forme matrielle et logicielle requise, les composants, et les fonctionnalits offertes par les deux produits.

VII.2 Plate-forme
VII.2.1 Matriels
Avant toute installation de Commerce Server ou bien de WebSphere, notre machine doit avoir les caractristiques bien prcises que nous avons rcapituler dans le tableau suivant :

Commerce Server RAM 96 Mo minimum et 128 recommand Processeur Espace disque Ecran et Rsolution 100MHz 1Go _

WebSphere 512 Mo

300MHz 500Mo 256 couleurs et 800*600

Tableau 7 : Comparaison : Configuration matrielle requise

VII.2.2 Logiciels
Commerce Server sera install sous lenvironnement de Windows NT Server avec option Pack ( le systme dexploitation rseaux de Microsoft ) o seront excuts les processus : Internet Information Server ( IIS ) : le serveur Web qui va publier le site

marchant. Microsoft SQL Server : le SGBD relationnel qui va grer la base de donnes centrale. Front Page.

De sa part, lutilisateur de notre systme (client ) doit avoir un navigateur Internet ( tel que Internet explorer ) et sa machine doit tre connecte lInternet pour pouvoir entrer en interaction avec le site pour visiter et lancer les commandes. La figure suivante rcapitule la configuration logicielle requise pour linstallation de Commerce Server.

Navigateur client

Navigateur oprateur du site de commerce

Serveur Windows NT IIS 4.0 Active Server Pages Commerce Server

Base de donnes SQL Server ou autre base de donnes compatible ODBC

Figure 15 : Architecture technique requise par Commerce Server

Des considrations doivent tre prises en compte lors de linstallation de Commerce Server. La procdure dinstallation de cet outil est prsente en annexe. Dans le cas de WebSphere, lun de systmes dexploitation suivants devrait tre install : Microsoft Windows NT 4.0 avec service Pack 4, Microsoft Windows x, ou AS/400. En plus de Microsoft Internet Explorer version 4.0 ou suprieure et si PageDetailer est install, on doit prendre Microsoft Internet Explorer 5.0. Le sous-systme WebSphere Studio contient les travaux relatifs WebSphere Application Server. Serveur d'applications

Un serveur d'applications WebSphere fournit l'environnement d'excution pour les composants Java ct serveur (tels que les servlets, les fichiers JSP et les beans enterprise).

Module d'extension

Le module dextension du serveur d'applications fournit une interface avec le serveur Web. Cette interface sert grer les requtes client portant sur les ressources ct serveur et pour les acheminer vers le serveur d'applications en vue de leur traitement. Un serveur d'applications contient les composants architecturaux suivants : Moteur de servlet

Le moteur de servlet s'excute l'intrieur du serveur d'applications et gre les requtes relatives aux servlets, aux fichiers JavaServer Pages (JSP) et aux applications Web qui les contiennent. Conteneur d'EJB

Le serveur d'applications interagit avec le conteneur d'EJB pour autoriser l'accs aux beans enterprise se trouvant dans le conteneur d'EJB. Serveur Web

Le serveur Web reoit des requtes relatives aux composants ct serveur (tels que les servlets, les fichiers JSP et les beans enterprise) et il les transmet WebSphere Application Server via une interface appele le module d'extension. WebSphere Application Server traite les requtes et envoie les rponses au client via le serveur Web. Le composant de logiciel suivant s'excute sur un poste de travail client : Console d'administration

La console d'administration est une application Java autonome qui s'excute sur un poste de travail. La console se connecte au serveur d'administration WebSphere et prsente une interface graphique qui permet de configurer et de grer les ressources WebSphere. La figure suivante reprsente larchitecture technique de WebSphere.

Figure 16. Architecture technique de WebSphere.

VII.3 Composants
VII.3.1 Composants de Commerce Server
Commerce Server est une plate-forme complte de cration de sites commerciaux virtuels. Ce produit est compos des lments suivants : outils ; objets COM (Component Object Model) orients commerce ; Microsoft Wallet.

Chacun de ces lments est dcrit dans les sections qui suivent. VII.3.1.1 Outils Grce aux nombreux outils de Commerce Server 3.0, la cration de sites Commerce Server personnaliss est encore plus facile qu'auparavant.

Assistant Fondations de site : Cet Assistant facilite la configuration de

l'infrastructure ncessaire au nouveau site Commerce Server. Assistant Crateur de site : L'objectif de cet Assistant est de simplifier la cration d'un site commercial l'aide d'une interface conviviale afin d'obtenir rapidement un site Commerce Server totalement fonctionnel.

Pipeline Editor : Pipeline Editor sert personnaliser le pipeline d'un site afin

d'assurer l'intgration complte dans les anciens systmes ou dans les autres systmes existants de l'entreprise

Outil de gestion des certificats : permet de crer une demande de certificat et de grer l'change des certificats entre les partenaires commerciaux.

Gestionnaire de liaisons de site de commerce : destin aux dveloppeurs amens transformer un site Commerce Server existant en fichier excutable autoextractible.

Outils d'administration : L'administrateur du serveur dispose de trois interfaces d'administration suivantes : le composant logiciel enfichable Commerce Server pour Microsoft Management Console (MMC), les pages Commerce de Commerce Server WebAdmin (Web-based Administration) ou l'interface de ligne de commande Commerce Server. VII.3.1.2 Objets COM de Commerce Server Les composants de Commerce Server peuvent tre regroups en trois grandes catgories : Composants utilitaires : Ils permettent de grer les interactions entre les fichiers .asp et les donnes figurant dans la base de donnes du site, d'effectuer des conversions et des validations de types de donnes, de grer les messages d'erreur, de faciliter les tches d'administration, de stocker les informations issues des formulaires de commande pour la session en cours, etc. Composants de pipeline de traitement des commandes (OPP, Order Processing Pipeline) : Ces composants sont utiliss pour grer les donnes lies une commande par l'intermdiaire des diffrentes tapes du processus de traitement des commandes. Commerce Server 3.0 fournit plusieurs pipelines traits, chacun tant associ une fonction prcise tel que Le pipeline de vrification du bon de commande et le pipeline d'achat. Composants de pipeline d'change commercial (CIP, Commerce Interchange Pipeline) : Ces composants facilitent l'change d'objets de donnes d'entreprise (tels que les bons de commande, les reus, les bons de livraison, etc.) entre les partenaires commerciaux.

VII.3.1.3 Microsoft Wallet Microsoft Wallet permet aux utilisateurs de stocker leurs informations d'adresse et de paiement en toute scurit sur leur ordinateur.

VII.3.2 Composants de WebSphere Studio

WebSphere se compose dun plan de travail et dun certain nombre dassistants, ainsi que de produits annexes de dveloppement pour le Web. Plan de travail Studio : le plan de travail aide lutilisateur grer et tenir jour les application et les fonctions de site Web. JavaBean, base de donnes et assistants SQL : Ces assistants permettent dajouter le plus rapidement possible un contenu dynamique aux pages Web cres. Ils permettent de rcuprer et de mettre jour les informations dans les bases de donnes communes et dutiliser des JavaBeans ct serveur. Ces fonctions permettent de tout faire, dune simple consultation de table aux applications libre-service complexes. Les assistants guident lutilisateur, tape par tape, et gnrent du ct de servlet volu. Assistant JAR : cet assistant convertit une classe Java en JavaBean standard. Il est possible dutiliser le fichier JAR rsultant dans lassistant JavaBean ou louvrir avec AppletDesigner pour lajouter une applet. Assistant Importation : permet la migration de sites Web et lutilisation de ces ressources existantes comme base de dpart. LAssistant Importation permet de copier rapidement des fichiers de sites Web existants dans un projet WebSphere Studio partir de leur lieu de publication. Lassistant invite lutilisateur lui fournir les renseignements dont il a besoin, et grce aux requtes FTP ou HTTP, il copie le site fichier par fichier. Page Designer, avec WebArt Designer et AnimatedGif Designer : Page Designer est un diteur HTML, prsentant des fonctions avances. Il permet de concevoir (mise en forme et contenu ) rapidement des pages Web dynamiques et des balises Java Server Pages ( JSP ). Il offre la possibilit de passer du mode Visuel au mode textuel et previsualiser les pages gnres pour voir leur apparence. PageDesigner comprend sa propre bibliothque de graphique rutilisable et deux programmes graphiques permettant la cration, ldition et lanimation de fichiers dimage. Grce cela lutilisateur peut faire en sorte que les sites Web aient limpact visuel dsir.

Applet designer : il rpond aux besoins de lutilisateur lorsque celui-ci veut

crer rapidement une applet pour son site Web. Cet outil de cration dapplications multimdia permet dassocier rapidement des JavaBeans et de constituer ainsi de nouvelles applets.

VII.4 Fonctionnalits
VII.4.1 Fonctionnalits de Commerce Server
Grce ses composantes, Commerce Server permet de : Crer un site

L'Assistant Crateur de site permet de gnrer un site commercial totalement fonctionnel en toute simplicit. Selon les options quon adopte, l'Assistant cre tous les fichiers Active Server Pages (.asp). Les sites crs par l'Assistant peuvent tre modifis l'aide de Microsoft Visual InterDev. Ces sites sont compatibles Microsoft Wallet pour l'inscription et l'achat. Le schma des sites Commerce Server est indpendant. On peut donc utiliser une base de donnes sans avoir en modifier la structure. On peut galement utiliser l'Assistant afin de gnrer un schma complet de base de donnes. Dans un cas comme dans l'autre, on peut agencer les donnes de la faon qui semble la plus adapte aux produits et lentreprise. Le site obtenu l'aide de l'Assistant Crateur de site permet de prsenter un catalogue dynamique des produits et d'accepter les commandes tout en s'intgrant dans les systmes existants de lentreprise. Personnaliser le site

On peut crer un site Commerce Server rapidement l'aide de l'Assistant. Aussi peuton exploiter les nombreuses possibilits de dveloppement de Commerce Server afin d'adopter le site ses besoins. Grer le site

Paralllement la conception du site, l'Assistant Crateur de site gnre un jeu de pages Web utilises par l'oprateur du site afin d'effectuer, distance, certaines tches de gestion. Les tches de gestion peuvent consister en l'ajout et la suppression de produits, la modification de la structure d'un service, la ralisation de ventes ou de promotions, la vrification des commandes. Les modifications sont automatiquement rpercutes sur les pages du site sans qu'il soit ncessaire de modifier les fichiers ASP. L'accs ces pages de gestion est limit l'oprateur du site et aux comptes utilisateurs Microsoft Windows NT qu'il a habilits.

Administrer le serveur

Commerce Server comprend plusieurs outils d'administration, en local ou distance, de l'ordinateur serveur sur lequel sont installs les sites Commerce Server. Ces outils permettent l'administrateur du serveur d'ajouter, de supprimer, d'ouvrir et de fermer les sites. Ils permettent en plus de crer des sites et de modifier les proprits des sites existants.

VII.4.2 Fonctionnalits de WebSphere

De sa part, et grce ses composantes, WebSphere studio assure : La cration des applications Web pour diffrentes units entirement bases sur Java. Laccs aux bases de donnes et la production des fonctions de programmation.

La scurisation du site. En effet WebSphere Studio contient des options de scurit permettant de contrler laccs aux divers utilisateurs du systme. WebSphere Studio permet de recueillir des informations sur le client et sur le paiement pour les utiliser plus tard sur ces commandes. Le tableau 8 rsume les fonctionnalits offertes par les deux produits et associe chaque service l'outil qui l'assure. Daprs cette tude, il apparat clairement que Commerce Server contient plus de fonctionnalits et des composants pour le dveloppement de solution B to B. Le pipeline de traitement de commandes et le pipeline dchange commercial sont les principaux composants pour la mise en uvre de telle solution. Les pipelines de traitement de commandes et dchange commercial sont prsents dans le chapitre suivant avec le pipeline Editor.

Commerce Server Cration du site Accs aux Bases de donnes Assistant crateur de site Composants utilitaires

WebSphere PageDesigner Bases de donnes et Assistants SQL

Administration du site

Microsoft Management Console MMC

Plan de travail Studio

WebAdmin

Interface de ligne de
commande Commerce Server Scurisation du site Traitement des commandes Microsoft Wallet Pipeline de traitement des commandes Possibilit d'intgration des anciens systmes Gestion des changes entre partenaires Tableau 8 : Les fonctionnalits offertes par Commerce Server et WebSphere Pipeline d'change commercial Non existant Pipeline Editor Non existant Options de scurit Non existant

Chapitre VIII

Composants de la solution choisie

Commerce Server fournit les outils et les fonctionnalits ncessaires aux sites de commerce interentreprises. Parmi ses fonctionnalits nous citons : la prise en charge des bons de commande, des procdures d'approbation des commandes et de l'change scuris des informations (commandes et bons de livraison, par exemple) entre les partenaires commerciaux. Dans ce chapitre nous prsentons les pipelines mis en jeu dans le dveloppement dune solution B to B.

VIII.1 Les composants de Commerce Server

Comme nous lavons signal au chapitre prcdent, Microsoft Commerce Sever est compos essentiellement de trois composants (Objets COM) : Composants utilitaires.

Composants de pipeline de traitement des commandes (OPP, Order Processing Pipeline). Composants de pipeline d'change commercial (CIP, Commerce Interchange Pipeline). Le schma suivant interprte ces composants et leurs fonctionnalits.

Fichier .asp

Utilitaires

Base de donnes du site

Commande brute

OPP prix, taxe, expdition, stocks

Commande traite

Entreprise

CIP mappage, signature, cryptage, transport, audit

Partenaire

Commerce Server Figure 17 : Les composants de Commerce Server

Le pipeline de Commerce Server est une infrastructure logicielle qui relie un ou plusieurs composant(s) et les excute successivement sur un objet OrderForm ou Dictionary. Commerce Server 3.0 utilise cette infrastructure pour mettre en uvre deux modles de pipeline : le pipeline de traitement des commandes (OPP, Order Processing Pipeline) et le pipeline d'change commercial (CIP, Commerce Interchange Pipeline).

VIII.1.1 Pipelines de traitement des commandes (Pipelines interentreprises)

Commerce Server 3.0 comprend cinq types de pipeline de traitement des commandes de base. Ils sont utiliss pour mettre en uvre les sites de commerce de dtail et les sites de commerce interentreprises.
Pipelines de dtail

Pipeline de produit

Pipeline de vrification du bon de commande Pipeline d'achat

Pipelines interentreprises

Pipeline de planification d'achats d'entreprise

Pipeline d'envoi d'achats d'entreprise

Nous nous contentons la prsentation des pipelines interentreprises, vue quils sont les lments qui oprent dans le cadre du commerce B to B. Les pipelines de traitement des commandes interentreprises sont utiliss dans des sites de commerce destins la cration et la transmission d'ordres de commande entre entreprises. Ces pipelines sont excuts divers moments du processus d'achat : Planification d'achats d'entreprise (CorpPurchasePlan.pct). Excute des composants du pipeline de traitement des commandes qui calculent le total du bon de commande, y compris les remises promotionnelles, les taxes, et les divers frais. Envoi d'achats d'entreprise (CorpPurchaseSubmit.pct). Excute des composants du pipeline de traitement des commandes qui valident la demande d'achat transmise par l'ordre d'achat. Ces composants transfrent l'ordre d'achat au vendeur et inscrivent une commande dans l'espace de stockage d'une base de donnes. VIII.1.1.1 Pipeline de planification d'achats d'entreprise Le pipeline de planification d'achats d'entreprise excute des composants du pipeline de traitement des commandes qui calculent le montant total de la commande. Le montant comprend l'ensemble des remises promotionnelles, les taxes, les frais d'expdition et les frais de manutention. Le pipeline de planification d'achats d'entreprise comprend 14 tapes. 1. Informations sur l'article de la demande. 2. Informations sur le fournisseur. 3. Informations sur l'acheteur. 4. Initialisation de la demande. 5. Vrification de la demande. 6. Prix de l'article de la demande. 7. Ajustement du prix de l'article de la demande. 8. Ajustement du prix de la demande. 9. Calcul du sous-total de la demande. 10. Expdition. 11. Manutention. 12. Calcul des taxes. 13. Calcul du total de la demande. 14. Vrification du stock.

VIII.1.1.2 Pipeline d'envoi d'achats d'entreprise Le pipeline d'envoi d'achats d'entreprise comprend deux tapes. Celles-ci excutent des composants qui valident la demande d'achat transmise par l'ordre d'achat. Aussi transfrentelles l'ordre d'achat au vendeur et inscrivent une commande dans l'espace de stockage de base de donnes. Le pipeline d'envoi d'achats d'entreprise peut tre excut lorsque un objet OrderForm est excut et une confirmation de la volont du client de finaliser l'achat est obtenue. Du fait que les composants de ce pipeline crivent dans une base de donnes, le pipeline d'envoi d'achats d'entreprise est souvent un pipeline trait. Le pipeline d'envoi d'achats d'entreprise comprend les tapes suivantes : a. Etape de validation de l'ordre d'achat Cette tape est utilise pour vrifier la validit de l'ordre d'achat. Commerce Server ne comprend aucun composant pour cette tape (autre que Scriptor). On peut cependant ajouter son propre composant personnalis pour valider l'ordre d'achat. b. Etape d'envoi de l'ordre d'achat Cette tape traite le bon de commande complt et le transmet au vendeur. Voici les composants en rapport avec cette tape :

Composant
ExecuteProcess Crer PO PipeToPipe Transfer

Description
Excute une application sur le serveur avec les arguments spcifis. Gnre un ordre d'achat bas sur un fichier modle. Transfre un objet OrderForm ou Dictionary du pipeline en cours d'excution vers un autre pipeline. Envoie un ordre d'achat (ordinairement le rsultat de Crer PO) un fichier. Ecrit le contenu de l'objet OrderForm dans l'espace de stockage des reus. Envoie un message lectronique l'adresse spcifie.

POtoFile SaveReceipt SendSMTP

Composant
SQLItem

Description
Excute la commande SQL spcifie pour chaque article de la commande avec pour arguments les champs indiqus de la commande et de l'article. Excute la commande SQL spcifie pour chaque article de la commande avec pour arguments les champs indiqus de la commande et de l'article. Ce composant est identique SQLItem, except qu'il effectue sa tche l'aide Microsoft ActiveX Data Objects (ADO) et qu'il peut tre inclus dans un pipeline trait. Excute la commande SQL spcifie une fois par commande, avec pour arguments les champs de la commande indiqus. Excute la commande SQL spcifie une fois par commande, avec pour arguments les champs de la commande indiqus. Ce composant est identique SQLOrder, except qu'il effectue sa tche l'aide Microsoft ActiveX Data Objects (ADO) et qu'il peut tre inclus dans un pipeline trait.

SQLItemADO

SQLOrder

SQLOrderADO

Tableau 9 : les composants en rapport avec ltape denvoi de lordre dachat

VIII.1.2 Pipeline dchange commercial

Le pipeline d'change commercial (CIP, Commerce Interchange Pipeline) permet aux entreprises de toute taille d'changer des informations sous forme lectronique. Le pipeline d'change commercial conditionne et achemine les objets de donnes commerciales d'une application l'autre par rseau. Ce rseau peut tre local (LAN), tendu (WAN), valeur ajoute (VAN) ou Internet. Le pipeline prend en charge les scnarios de commerce interentreprises, notamment les achats d'entreprise et les achats par chane d'approvisionnement. Le pipeline d'change commercial permet d'effectuer n'importe quel type de transaction commerciale par voie lectronique. La figure ci-aprs illustre la manire dont une entreprise peut utiliser le pipeline d'change commercial pour communiquer avec une autre en crant un vaste rseau d'entreprises relies entre elles.

Tr Rec

Rec

Partenaire1
Tr Rec Tr Rec Tr

Partenaire 1.1

Entreprise

Tr

Rec Rec

Tr

Rec

Partenaire 2

Partenaire2.1

Tr

Rec

Tr

Tr : Transmission Rec : Rception

Figure 18 : Utilisation du Pipeline dchange commercial

Les pipelines de transmission et de rception du pipeline d'change commercial peuvent tourner sur divers sites et serveurs ou cohabiter sur le mme serveur. En fait, le pipeline de transmission ne doit pas ncessairement transmettre ses donnes un pipeline de rception. De mme, le pipeline de rception ne doit ncessairement recevoir ses donnes d'un pipeline de transmission. Le pipeline de transmission doit seulement effectuer une transmission vers un composant logiciel (tel un convertisseur EDI) conu pour interprter les donnes envoyes. Le pipeline de rception doit seulement savoir comment interprter les donnes reues.

VIII.2 Integration de la traduction Edifact.

Le composant ExecuteProcess de lOPP permet dexcuter une application sur le serveur. Lutilisation de ce composant va nous permettre dintegrer la traduction Edifact dans loutil de dveloppement (Commerce Server). Nous proposons dajouter un composant traducteur aprs le traitement de la commande par lOPP et avant la transmission de lobjet commercial par le CIP. En effet, aprs le traitement de lOrderForm (commande) par le pipeline OPP, ce dernier envoie en sortie lobjet Dictionary. Avant denvoyer le Dictionary au CIP, on execute le processus de traduction qui nous livre un objet Dictionary standard Edifact.

Ce dernier va tre trait par le CIP pour tre achemin vers la destination travers le rseau Internet.
ExecuteProces s Site Web OPP OrderForm

Dictionary plat

Traducteur Edifact Dictionary Standard Edifact

Internet

Objet crypt et sign

CIP

Figure 19 : Intgration de la traduction Edifact

VIII.3 Pipeline Editor

Pipeline Editor est une application qui permet de modifier des pipelines d'change commercial et des pipelines de traitement des commandes de Commerce Server. Il existe deux versions de Pipeline Editor :
Pipeline Editor version Win32 qui permet de modifier un pipeline sur l'ordinateur local ou sur

un ordinateur connect un rseau local (LAN). Pipeline Editor version ASP qui permet de modifier un pipeline distance sur Internet l'aide

d'un navigateur Web.

Ces deux versions offrent des fonctionnalits trs semblables. On peut en effet modifier des pipelines existants dans l'une ou l'autre version, mais on ne peut crer un pipeline que dans Pipeline Editor version Win32. Une prsentation plus dtaille de ce composant est donne dans lannexe A.

Conclusion

Le projet EECPI consiste dvelopper un environnement pour supporter le commerce lectronique interentreprises sur plate-forme Internet. Nous avons suivi une dmarche compose de plusieurs tapes. Une premire tape concerne ltude des notions relatives au commerce lectronique. Une deuxime tape consiste laborer larchitecture gnrale du commerce interentreprises. La troisime tape porte sur ltude comparative des diffrents outils de dveloppement ECommerce du domaine B to B qui existent sur le march. Ltape suivante est linstallation de la plate-forme choisie. Puis ladaptation de loutil et le dveloppement du composant de traduction. Enfin, vient la ralisation de la solution pour le compte de COMPUTIME. Nous avons prsent dans ce rapport le rsultat de ltude pralable en prsentant les diffrentes notions lies au domaine B to B. Aussi avons-nous prsent larchitecture relative ce domaine. Ensuite nous avons expos le rsultat de ltude comparative et larchitecture de la solution choisie. Des contraintes matrielles concernant les caractristiques de la plate-forme ont t la cause du retard de linstallation des outils de dveloppement. Une fois les outils seront installs, le projet poursuivra son volution et aboutira un rsultat qui pourra tre le premier de son genre au Maroc. Signalons que le Maroc na pas encore de solution dans le domaine du commerce lectronique. Le rsultat de ce projet sera une solution qui intgre une plate-forme E-Commerce et la traduction Edifact, et sera dun grand bnfice pour les PME/PMI, et pour lconomie nationale en gnrale. Ce projet nous a t trs utile. Nous avons acquis des connaissances pertinentes dans le domaine du commerce lectronique gnralement, et dans le B to B via Internet spcifiquement. Lenvironnement du travail nous a permis dapprendre des connaissances professionnelles, et nous a amenes du cadre dtudiant vers le cadre dingnieur.

Glossaire

Accord
dinterchange

Accord Contrat par lequel des personnes tablissent les conditions juridiques et techniques dutilisation dun EDI. Au plan purement technique, cet accord portera notamment sur le langage utilis pour lEDI. La forme des messages, le rythme des changes, le sort des accs de rception. En plus du traitement et de la scurit des messages, leur enregistrement, et leur stockage. American National Standard Institute. Le comit X12 de lANSI a mis au point une srie de standards pour lEDI (dnomme ANSI x12) : ceux-ci sont compatibles avec les normes et les recommandations internationales UN/EDIFACT. Application Programming Interface. Dcrit la faon de communiquer avec une application. Application qui est une squence de code qui ne peut sexcuter que dans e contexte dun navigateur Bote Aux Lettres. Unit logique dun systme de messageries lectroniques qui permet de stocker les messages reus de diffrentes origines et dy accder tout moment pour consultation et/ou retrait. Business to Business : Commerce lectronique entre entreprises Dcrit la relation qui existe entre un ordinateur client et un ordinateur serveur au niveau des applications mises en rseau. Le systme client est en gnral lordinateur de bureau dun collaborateur. Le serveur est le plus souvent un ordinateur plus puissant qui stocke de gros volumes de donnes et sert excuter des programmes importants. Commerce Interchange Pipeline. Ces composants facilitent l'change d'objets de donnes d'entreprise Component Object Model : le Middleware objet de Microsoft Dsigne lutilisation combine et optimale des technologies de la communication qui permettent dassurer et de dvelopper les transactions daffaires. Procd visant transformer, laide de conventions secrtes, des informations ou des signaux clairs en informations ou signaux inintelligibles pour des tiers.

ANSI

API

Applet

BAL
B to B

Client/Serveur

CIP COM Commerce lectronique Cryptage

DCOM
DNA Donne

Distributed Component Object Model. La technologie DCOM permet deux objets, lun client, lautre serveur, de communiquer entre eux. Distributed interNet Architecture de Microsoft. Une plate-forme de dveloppement pour des applications totalement rparties. Fait, concept ou instruction reprsent sous une forme conventionnelle et adapte une communication, une interprtation ou un traitement par lhomme ou par des moyens automatiques. (ISO2382-1). Electronic Data Interchange. Transmission dordinateur ordinateur, dapplication application, de donnes structures selon des messages prtablis et normaliss via un moyen de tlcommunication. Electronic Data Interchange for Administation, Commerce and Transport. Rgles des Nations unies concernant lEDI. Echanges de Formulaires Informatiss. Forme simplifie de lEDI qui permet un utilisateur dmettre ou de recevoir des documents lectroniques structurs en mettant sa disposition des grilles de lecture ou de saisie, simples, appeles formulaires. Electronique Funds Transfer : technologie fut conue pour optimiser la transmission lectronique dordre de paiement Hyper text Markup Language. Langage normalis utilis pour dvelopper les applications Web Hyper Text Transfer Protocol. Protocol utilis pour accder aux serveurs Web. Anglicisme, synonyme dchange. Communication lectronique dun partenaire un autre en une combinaison structure de messages et segments de services commenant par un en-tte de contrle dchangete se terminant par une fin de contrle dchange. (ISO9735). INTernational NETwork (le rseau mondial). Rseau constitu dune fdration de rseaux dordinateurs qui utilise le mme protocole de communication (TCP/IP) et fonctionnent comme un rseau virtuel unique et coopratif. Aptitude des quipements terminaux ( informatiques et de tlcommunication) fonctionner avec le rseau. Et avec les autres quipements terminaux permettant daccder un mme service. Internet Protocol. Il est responsable de ladressage, quil effectue sur la base de ladresse source et de ladresse cible Langage de programmation introduit par Sun Microsystems, spcialement conu pour Internet.

EDI

Edifact EFI

EFT

HTML
HTTP

Interchange

Internet

Interoprabilit

IP

Java

Java Bean

Un composant logiciel crit en Java conu pour tre manipul laide doutils graphiques. Il contient des classes Java et constitue llment de base pour construire des appliquettes ou/et des applications Java. Local Area Network. Un rseau de nature local, qui connecte des ordinateurs dun mme immeuble. Mot Amricain cre pour dsigner une couche de logiciel situe entre le systme dexploitation dun ordinateur et les logiciels dapplication Microsoft Transaction Server . Middleware transactionnel fonctionnant au-dessus de DCOM En Anglais Browser. Logiciel permettant daffichage des documents du World Wide Web. Un pipeline trait est un pipeline exclusivement compos de composants conus et configurs pour prendre en charge des transactions Microsoft Transaction Server (MTS). Petites et Moyennes Entreprises, Petites et Moyennes Industries. Open Database Connectivity . Interface standard de Microsoft permettant daccder des donnes Order Processing Pipeline. Ces composants sont utiliss pour grer les donnes lies une commande par l'intermdiaire des diffrentes tapes du processus de traitement des commandes. Remote Procedure Call. En Franais, appel de procdure loigne. Rseau Valeur Ajoute. Un RVA est un rseau de tlcommunication gre par un oprateur. Cet oprateur permet de faire communiquer des applications et des matriels en apportant des fonctionnalits supplmentaires. Comme lextraction, la traduction, le formatage, ou le choix du protocole de communication. squence de code crite en langage de script, tels que JavaScript ou Vbscript. Il comprend lidentification, lauthentification, la vrification de lintgrit des messages. Et la non rpudiation des messages au moyen dune signature lectronique. Standard Generlised Mard-Up Language. Srie de standards pour le bornage et ladressage de parties dun texte. Norme ISO permettant de dcrire un document comme un ensemble organis pour y accder de manire automatique et grer les mises jour sans avoir rviser tout le document. Simple Mail Transfer Protocol. Protocole de transmission dun message entre deux machines. Cest la messagerie lectronique, service majeur dInternet.

LAN Middelware
MTS

Navigateur Pipeline trait

PME/PMI

ODBC
OPP

RPC
RVA

Script
Scurit

SGML

SMTP

Stub

Mot anglais signifiant souche. Un Stub est une squence de code gnre automatiquement permettant de relier client et serveur au Middleware. Transmmision Control Protocol. Il est bas sur lutilisation de datagrammes ou paquets . TCP assure la communication de bout en bout entre deux quipements. ou convertisseur, Ensemble logiciel utilis pour convertir une information dans une codification et/ou selon un format donn dans une autre codification et/ou selon dautres rgles de formatage (structuration). Uniform Resource Locator. Adresse standardise de toute ressource sur Internet. Value Added Network. Voir RVA. Microsoft Wallet permet aux utilisateurs de stocker leurs informations d'adresse et de paiement en toute scurit sur leur ordinateur. Wide Area Network. Un rseau reliant des systmes situs en diffrents points du globe. Un service interactif propos sur Internet, Ce systme hypermdia distribu en mode Client Serveur. Il met la disposition toutes sortes dinformations. Il permet galement de consulter des informations disposes en pages Web laide dun navigateur. eXtension Markup Language. Cette norme est un sous-ensemble de SGML adapt la prsentation des donnes sur le Web.

TCP
Traducteur

URL VAN Wallet

WAN World Wide Web WWW, Web, W3

XML

Bibliographie

Ouvrages :
[LANGLOIS] M.LANGLOIS et S.GASCH. Le commerce lectronique B to B : de lEDI Internet. DUNOD. 1999. C.BITOUZET. Le commerce lectronique : Cration de valeur lentreprise. HERMES. 1999. D.KOSIUR. Comprendre le Commerce Electronique. MicrosoftPress. 1997.

[BITOUZET]

pour

[KOSIUR]

Sites Web :
[CIDPCE] Comit Interministeriel pour le Dveloppement et la Promotion du Commerce Electronique. Synthse des travaux. http://www.casanet.net.ma/E-commerce/rapport.pdf www.mtic.pm.gov.fr www.menara.ma www.edifrance.org www.microsoft.com www.ibm.com

[MTIC] [MENARA] [EDIFACT] [MICROSOFT] [IBM]

ANNEXES

Annexe A

Pipeline Editor

Commerce Server assure la cration de pipeline grce au Pipeline Editor. Dans la section suivante nous prsentons en dtail ce composant, son dmarrage et son utilisation. Pipeline Editor est une application qui permet de modifier des pipelines d'change commercial et des pipelines de traitement des commandes de Commerce Server. Il existe deux versions de Pipeline Editor :
Pipeline Editor version Win32 qui permet de modifier un pipeline sur l'ordinateur local ou sur

un ordinateur connect un rseau local (LAN). Pipeline Editor version ASP qui permet de modifier un pipeline distance sur Internet l'aide

d'un navigateur Web.

Ces deux versions offrent des fonctionnalits trs semblables. On peut en effet modifier des pipelines existants dans l'une ou l'autre version, mais on ne peut crer un pipeline que dans Pipeline Editor version Win32.

1 Dmarrage de Pipeline Editor

Comme la version Win32 de Pipeline Editor est conue pour tre excute localement, on la dmarre partir du menu Dmarrer. Dans le cas de la version ASP, on dmarre Pipeline Editor partir du navigateur. Pour cela, on se connecte la page de gestion du site, puis on clique sur un bouton pour lancer Pipeline Editor en chargeant automatiquement le pipeline slectionn. Pour dmarrer Pipeline Editor version Win32
1. Dans le menu Dmarrer, pointer sur Programmes, Microsoft Commerce Server,

Commerce, puis cliquer sur Pipeline Editor. 2. 3. Dans le menu Fichier, cliquer sur Ouvrir. Retrouver le fichier .pcf du pipeline modifier. Le fichier .pcf d'un site est plac par

dfaut dans \Inetpub\wwwroot\nom_site\Config. 4. Slectionner le fichier .pcf, puis cliquer sur Ouvrir.

Pour dmarrer Pipeline Editor version ASP

1. le pipeline. 2. Dans la zone Systme de la page Suprieur hirarchique du site, slectionner le pipeline Dmarrer le navigateur, puis taper l'URL de la page du site pour lequel on veut modifier

modifier dans la liste droulante, puis cliquer sur Modifier le pipeline.

2 Cration d'un pipeline (Win32 uniquement)

On ne peut crer un pipeline que dans la version Win32 de Pipeline Editor. Commerce Server version 3.0 fournit les modles standard donns dans le tableau 10, partir desquels on peut crer un pipeline. Les fichiers du modle sur lequel on base le nouveau pipeline portent l'extension .pct (pipeline configuration template). Lorsque on enregistre le nouveau modle, il porte automatiquement l'extension de fichier .pcf standard (pipeline configuration file). Le modle fournit un pipeline pr configur. On peut modifier le nom des tapes, mais pas supprimer ou ajouter une tape. On peut ajouter ou supprimer n'importe quel composant dans une tape quelconque.

Nom du modle CorpPurchaseSubmit.pct CorpPurchasingPlan.pct

Description Pipeline d'achats d'entreprise deux tapes comprenant les tapes Validation de l'ordre d'achat et Envoi de l'ordre d'achat. Pipeline d'achats d'entreprise quatorze tapes, comprenant les tapes Informations sur l'article de la demande, Informations sur le fournisseur, Informations sur l'acheteur, Initialisation de la demande, Vrification de la demande, Prix de l'article de la demande, Ajustement du prix de l'article de la demande, Ajustement du prix de la demande, Sous-total de la demande, Port, Manutention, Taxes, Total de la demande et Stock. Pipeline de traitement des commandes quatorze tapes, comprenant les tapes Informations produit, Informations vendeur, Informations client, Initialisation de la commande, Vrification de la commande, Prix de l'article, Ajustement du prix de l'article, Ajustement du prix de la commande, Soustotal de la commande, Port, Manutention, Taxes, Total de la commande et Stock. Pipeline de traitement des commandes cinq tapes, comprenant les tapes Informations produit, Informations client, de prix de l'article, Ajustement du prix de l'article et Stock.

plan.pct

product.pct

Nom du modle purchase.pct

Description Pipeline de traitement des commandes trois tapes qui ne comprend que les tapes finales Vrification de l'achat, Paiement et Acceptation. Pipeline de transmission d'change commercial comprenant les tapes Carte, Ajout d'en-tte, Signature numrique, Cryptage, Audit et Transport. Pipeline de rception d'change commercial comprenant les tapes Dcryptage, Vrification de la signature lectronique, Ouverture d'en-tte, Cration de reu, Carte, Audit et Intgration de l'application.

transmit.pct

receive.pct

Tableau 10 : Modles standards de cration de Pipeline

Pour crer un pipeline

1. Dans le menu Dmarrer, pointer sur Programmes, Microsoft Commerce Server,

Commerce, puis cliquer sur Pipeline Editor. 2. 3. 4. 5. Dans le menu Fichier, cliquer sur Nouveau. Slectionner un modle, puis cliquer sur OK. Modifier le pipeline comme requis. Dans le menu Fichier, cliquer sur Enregistrer.

3 Ajout d'un composant un pipeline

Pipeline Editor permet d'ajouter un composant n'importe quelle tape d'un pipeline. Les valeurs d'un composant particulier doivent figurer sur le bon de commande avant que celui-ci puisse excuter sa fonction avec succs. Les composants des tapes prcdentes doivent crire les valeurs du bon de commande avant l'tape au cours de laquelle on insre un composant qui ncessite ces valeurs (voir Cration de la liste des valeurs lues et crites). Pour ajouter un composant un pipeline l'aide de Pipeline Editor version ASP
1. 2. Dans Pipeline Editor, ouvrir le pipeline auquel on souhaite ajouter le composant. Retrouver l'tape laquelle on souhaite ajouter le composant, puis cliquer sur le lien

Insrer un composant. Si l'tape comprend dj un ou plusieurs composants, on peut insrer le nouveau composant avant ou aprs un composant existant en cliquant sur le lien l'emplacement o on souhaite insrer le composant. 3. La liste Composant numre les composants gnralement utiliss dans l'tape courante

du pipeline. Cliquer sur un composant pour l'ajouter au pipeline.

Pour dvelopper la liste de faon afficher la totalit des composants, cliquer sur Afficher tous les composants disponibles. Pour limiter la liste aux seuls composants gnralement utiliss dans l'tape courante, cliquer sur Afficher uniquement les composants de nom_tape. 4. Pour configurer un nouveau composant, cliquer sur le lien Modifier. Modifier les

proprits du composant comme requis, puis cliquer sur Mettre jour. 5. En haut de l'tape, cliquer sur Enregistrer.

Pour ajouter un composant un pipeline l'aide de Pipeline Editor version Win32

1. 2. Dans Pipeline Editor, ouvrir le pipeline auquel on souhaite ajouter le composant. Excuter l'une ou l'autre procdure ci-dessous :

Cliquer avec le bouton droit sur le nom de l'tape au cours de laquelle on souhaite insrer le

composant, puis, dans le menu contextuel, cliquer sur Insrer un composant. Le nouveau composant est insr au dbut de l'tape. Cliquer avec le bouton droit sur le nom d'un composant existant au sein de cette tape, pointer sur

Insrer un composant dans le menu contextuel, puis cliquer sur Avant ou Aprs. Le nouveau composant est insr avant ou aprs celui quon a slectionn. 3. Dans la bote de dialogue Choix d'un composant, cliquer sur une option sous tapes.

L'option slectionne dtermine les composants qui sont affichs dans la zone Composants. La valeur par dfaut correspond au nom de l'tape dans laquelle on insre le composant ; sa slection affiche uniquement les composants gnralement utiliss dans cette tape. La slection de l'option Tous affiche tous les composants, quelle que soit l'tape dans laquelle ils sont gnralement utiliss. 4. OK. 5. Pour configurer le nouveau composant, cliquer avec le bouton droit sur le composant, Dans la liste Composants, cliquer sur le nom du composant insrer, puis cliquer sur

puis, dans le menu contextuel, cliquer sur Proprits. Modifier les proprits du composant comme requis, puis cliquer sur OK. 6. Dans le menu Fichier, cliquer sur Enregistrer.

4 Modification de l'ordre des composants dans une tape du pipeline

On peut monter ou descendre un composant au sein de son tape. Quand une tape ne comprend qu'un seul composant, on ne peut pas le dplacer. (On peut cependant le supprimer, puis insrer le mme composant dans une autre tape.)

Pour dplacer un composant l'aide de Pipeline Editor version Win32

1. 2. Dans Pipeline Editor version Win32, ouvrir le pipeline. Cliquer avec le bouton droit sur le composant, puis, dans le menu contextuel, cliquer sur

Descendre ou Monter.

Pour dplacer un composant l'aide de Pipeline Editor version ASP

1. 2.
Pour

Dans Pipeline Editor version ASP, ouvrir le pipeline. Retrouver le composant dplacer, puis cliquer sur son bouton Haut ou Bas.
Cliquer sur

Monter

Bouton Haut
Descendre

Bouton Bas

5 Cration de la liste des valeurs lues et crites (Win32 uniquement)

Chaque composant d'un pipeline lit les valeurs du bon de commande, excute sa fonction, puis crit des valeurs dans le bon de commande. Les composants excuts plus tard dans le pipeline lisent souvent les valeurs qui ont t crites dans le bon de commande par les composants prcdents. Lorsquon modifie un pipeline ou quon en cre un, il peut s'avrer utile d'afficher la liste des valeurs lues et crites par chaque composant. Ceci a pour but tre certain que les valeurs requises sont prsentes chaque endroit. Pipeline Editor version Win32 peut crer un fichier texte qui rpertorie chaque composant d'un pipeline particulier selon l'ordre dans lequel il est excut. Ce fichier texte numre tous les composants excuts par le pipeline, y compris ceux qui sont requis sans tre pour autant affichs dans Pipeline Editor. (Le composant requis s'excute toujours en dernier dans une tape dtermine.) Pour chaque composant, ce fichier numre les informations suivantes :

valeurs d'entre (valeurs lues) ; valeurs de sortie (valeurs crites) ; valeurs contextuelles (valeurs lues partir de l'objet PipeContext Dictionnary, qui est pass sous

la forme d'un paramtre la mthode Execute de l'objet pipeline).

Pour crer la liste de toutes les valeurs lues et crites

1. 2. 3. Dans Pipeline Editor version Win32, ouvrir le fichier .pcf. Dans le menu Fichier, cliquer sur Enregistrer les valeurs lues et crites. Dans la bote de dialogue Enregistrer sous, spcifier l'emplacement et le nom du fichier

texte, puis cliquer sur Enregistrer. Pipeline Editor enregistre le fichier et l'ouvre dans le Bloc-notes.

6 Utilisation des pages de proprits de Pipeline Editor

Les pages de proprits disponibles dans Pipeline Editor permettent d'afficher et de modifier facilement des pipelines, des tapes et des composants. Pour afficher des pages de proprits
Dans Pipeline Editor version Win32, cliquer avec le bouton droit sur le nom du pipeline, de

l'tape ou du composant, puis, dans le menu contextuel, cliquer sur Proprits. Dans Pipeline Editor version ASP, cliquer avec le lien Modifier sur un composant.

Proprits du pipeline
Cette page de proprits ne peut tre affiche que dans Pipeline Editor version Win32. Elle permet de modifier le nom du pipeline, de spcifier son mode de transaction ou d'enregistrer des remarques relatives au pipeline.
tiquette : spcifie le nom du pipeline qui est affich par Pipeline Editor. On peut le modifier en

tapant un nouveau nom cet endroit. Compatibilit de transaction : spcifie l'objet pipeline avec lequel ce fichier de configuration

peut tre utilis. Tout pipeline : indique que ce fichier de configuration peut tre utilis avec un objet

OrderPipeline, un objet MtsPipeline ou un objet MtsTxPipeline. Requiert un pipeline trait (TxPipeline Mts) : indique que ce fichier de configuration ne peut

tre utilis qu'avec un objet MtsTxPipeline. L'objet MtsTxPipeline est inscrit avec MTS (Microsoft Transaction Server) en tant que transaction requise et renferme une transaction qui recouvre tous les composants du pipeline.

Requiert un pipeline non trait (MtsPipeline) : indique que ce fichier de configuration ne peut

tre utilis qu'avec un objet MtsPipeline. L'objet MtsPipeline est inscrit avec MTS en tant que transaction non prise en charge. Description : fournit un espace permettant d'entrer des commentaires sur ce pipeline.

Proprits d'tape
Cette page de proprits ne peut tre affiche que dans Pipeline Editor version Win32. Elle permet de modifier le nom de l'tape ou d'enregistrer des remarques relatives celle-ci.
tiquette : spcifie le nom de l'tape qui est affich par Pipeline Editor. On peut le modifier en

tapant un nouveau nom cet endroit. Description : fournit un espace permettant d'entrer des commentaires sur cette tape.

Proprits du composant
Cette page de proprits ne peut tre affiche que dans Pipeline Editor version Win32. Elle permet de modifier le nom du composant, d'afficher son identificateur de classe ou de programme et d'enregistrer des remarques son sujet.
tiquette : spcifie le nom du composant qui est affich par Pipeline Editor. On peut le modifier

en tapant un nouveau nom cet endroit. Identificateur de classe : spcifie le GUID (identificateur universel unique) qui identifie ce

composant de manire unique sur n'importe quel ordinateur. Cet identificateur ne change jamais, mme lorsquon modifie le nom du composant. Identificateur de programme : spcifie l'identificateur du composant susceptible d'tre reconnue

facilement. Cet identificateur ne change jamais, mme lorsquon modifie le nom du composant. Description : fournit un espace permettant d'entrer des commentaires sur ce composant.

Valeurs lues et crites

Cette page de proprits ne peut tre affiche que dans Pipeline Editor version Win32. Elle permet d'afficher les valeurs lues et crites par ce composant dans le bon de commande ainsi que les valeurs lues partir de l'objet Dictionnaire PipeContext.
Valeurs lues : Spcifie les valeurs que ce composant lit partir du bon de commande avant

d'excuter sa fonction.

Valeurs crites : Spcifie les valeurs que ce composant crit dans le bon de commande aprs

avoir excut sa fonction. Valeurs de contexte lues : Spcifie les valeurs que ce composant lit partir de l'objet

Dictionnaire PipeContext. PipeContext est pass sous forme de paramtre la mthode Execute de l'objet pipeline.

Erreur de cration
Cette page de proprits affiche une erreur pour aider dterminer la raison pour laquelle un composant du pipeline n'a pas pu tre charg. Essayer de rsoudre le problme d'une des manires suivantes :
Supprimer le composant du pipeline, puis rinsrer-le. Sassurer que la DLL associe au composant est correctement inscrite. Si le problme persiste toujours, essayer de rinstaller Commerce Server.

Proprits personnalises
Cette page de proprits permet de crer une interface utilisateur personnalise pour des composants Visual Basic.
Interface utilisateur personnalise : ouvre une fentre spare permettant de dfinir une

interface utilisateur personnalise pour des composants Visual Basic.

7 Utilisation de Pipeline Editor version Win32 en mode Expert

Bien que le mode standard de Pipeline Editor version Win32 soit un outil puissant, son mode Expert fournit d'autres fonctionnalits. Ces fonctionnalits s'avrent pratiques pour les dveloppeurs de pipelines et de composants pipeline personnaliss. Le mode Expert de Pipeline Editor offre les fonctionnalits supplmentaires cidessous :
cration d'un pipeline personnalis sans recours un fichier modle prconfigur ; insertion, dplacement et suppression d'tapes du pipeline ; coupage, copie et collage d'une tape et de ses composants ; affectation de GUID (identificateur universel unique) aux tapes ; visualisation des composants requis qui ne sont pas affichs en mode standard ; marquage comme Requis du dernier composant d'une tape.

7.1 Dmarrage de Pipeline Editor version Win32 en mode Expert

Pipeline Editor ne peut tre dmarr en mode Expert qu' partir d'une invite. Pour dmarrer Pipeline Editor en mode Expert
1. 2. Dans le menu Dmarrer, cliquer sur Excuter. Dans la zone Ouvrir, taper le chemin du fichier PipeEditor.exe en ajoutant le

commutateur /e la fin de la commande. Si Commerce Server est install l'emplacement par dfaut, taper la commande suivante :
"C:\Microsoft Site Server\Bin\PipeEditor.exe" /e

3.

Cliquer sur OK.

7.2 Dfinition des proprits des tapes en mode Expert

Lorsquon excute Pipeline Editor version Win32 en mode Expert, on peut dfinir les proprits ci-dessous pour une tape du pipeline :
GUID : Numro qui identifie cette tape de manire unique. Mode : Le champ Mode assure la compatibilit avec les pipelines Commerce Server 2.0, dans

lesquels le numro identifie les tapes d'un pipeline qui doivent tre excutes par les mthodes RunProduct, RunPlan et RunPurchase de l'objet Page. Niveau d'erreur : Quand un composant quelconque de l'tape gnre une erreur un niveau gal

ou suprieur celui spcifi dans la zone Niveau d'erreur, l'tape s'arrte et produit une erreur.

Pour dfinir les proprits d'une tape en mode Expert

1. Dmarrer Pipeline Editor version Win32 en mode Expert, puis ouvrir le pipeline qui

contient l'tape modifier. 2. Proprits. 3. 4. 5. Pour dfinir le GUID, taper un identificateur unique pour cette tape. S'il s'agit d'un pipeline Commerce Server 2.0, taper une valeur pour la proprit Mode. Sous Niveau d'erreur, taper le numro qui correspond au niveau d'erreur auquel on Cliquer avec le bouton droit sur l'tape, puis, dans le menu contextuel, cliquer sur

souhaite arrter l'excution de l'tape. 6. Enregistrer le pipeline, puis fermer Pipeline Editor.

7.3 Cration d'un pipeline personnalis en mode Expert

Le mode Expert de Pipeline Editor version Win32 permet de crer un pipeline personnalis sans avoir recours un fichier modle de pipeline prconfigur (.pct). Pour crer un nouveau pipeline en mode Expert
1. 2. 3. Dmarrer Pipeline Editor version Win32 en mode Expert. Dans le menu Fichier, cliquer sur Nouveau. Dans la zone Choix d'un modle de pipeline, double-cliquer sur Empty.pce.

Un fichier pipeline vide s'ouvre. 4. Cliquer avec le bouton droit sur Modle de pipeline vierge, puis, dans le menu

contextuel, cliquer sur Proprits. Dans le champ tiquette, taper le nouveau nom du pipeline. Slectionner une option sous Compatibilit de transaction, ajouter une description du pipeline dans le champ Description, puis cliquer sur OK. 5. Cliquer avec le bouton droit sur le nom du pipeline, puis, dans le menu contextuel,

cliquer sur Insrer une tape. Cliquer avec le bouton droit sur Nouvelle tape, puis, dans le menu contextuel, cliquer sur Proprits. Dfinisser les proprits de l'tape, puis cliquer sur OK. 6. Cliquer avec le bouton droit sur le nom de l'tape, puis, dans le menu contextuel, cliquer

sur Insrer un composant. Sous tapes, slectionner Tous, cliquer sur le nom du composant insrer, puis sur OK. 7. Pour configurer le nouveau composant, cliquer avec le bouton droit sur le composant,

puis, dans le menu contextuel, cliquer sur Proprits. Modifier les proprits du composant comme requis, puis cliquer sur OK. 8. Dans le menu Fichier, cliquer sur Enregistrer sous, puis taper le nom du fichier de

configuration du pipeline.

Quand Pipeline Editor enregistre le fichier, il lui ajoute automatiquement l'extension de fichier .pcf.

Annexe B

Procdure dinstallation de Commerce Server

Suggestion de pr-installation Il ne faut pas installer Site Server 3.0 sur un ordinateur fonctionnant comme Backup du contrleur du domaine. Il ne faut pas installer Microsoft Exchange Server sur le mme ordinateur que Site Server, car ces deux serveurs sont gourments en terme de ressources. Les performances chute normment lorsque les deux sont installs simultanment, en plus que les deux serveurs utilisent les mmes ports TCP (389 et 25). Il ne faut pas installer Site Server 3.0 sur un ordinateur utilisant Microsoft Cluster, par contre il est possible de linstaller en mme temps avec Windows NT Load Balancing Service (WBLS). Il ne faut pas installer SQL Server simultanment avec WBLS, cependant on peut installer SQL Server avec MSCS. Il ne faut pas installer Site Server 3.0 sur un ordinateur utilisant Microsoft

BackOffice Small Business Server. Il ne faut changer aucun paramtre par dfaut sur Microsoft Internet Information Server (IIS) avant linstallation de Site Server. Il faut sassurer que la racine dinstallation de Site Server est en format NTFS. Si vous avez besoins de changer ces paramtres il faut le faire aprs linstallation de Site Server. Il ne faut pas installer Microsoft Proxy Server 2.0 sur le mme ordinateur que Site Server 3.0. Microsoft recommande de ne pas installer Commerce Server sur le mme

ordinateur que Microsoft Commercial Internet System. Il ne faut pas installer Site Server sur Windows NT 4.0 Terminal Server.

Procdure dinstallation Installer Microsoft Windows NT 4.0. Microsoft recommande dinstaller Site Server comme serveur autonome ou seveur membre, au lieu dun contrleur de domaine. Ne pas utiliser des noms dordinateur suprieurs 12 caractres. Installer Windows NT sur une partition NTFS.

Installer Microsoft Windows NT 4.0 Service Pack 3 Ne pas substituer par Service Pack 4.0 ou ultrieur ce point.

Installer Microsoft Internet Explorer 4.01 Service Pack 2, utilisant linstallation

standard. Ne pas substituer par Internet Explorer 5.0 ou ultrieur ce point.

Installer Microsoft Windows NT4.0 Option Pack. Installer Index Server, Windows Sripting Host, sous la partie IIS il faut rajouter SMTP Server. Ne pas installer FrontPage Server Extensions. Configurer MTS pour LOCAL administration.

Installer la mise jour de FrontPage 98 Server Extensions, version 3.0.2.1706. Installer Microsoft Windows NT 4.0 Service Pack 4. Ne pas le substituer par Service Pack 5 ou ultrieur ce point. Aprs redmarrage du systme ne pas installer la mise jour Y2K.

Installer Internet Explorer 5.0. Installer SQL Server 7.0 Service Pack 1. Configurer le paramtre par dfaut du client SQL Server Named Pipes.

Vrifier que le service MSDTC est dmarr et quil est configur pour dmarrage automatique. Configurer les connexions aux bases de donnes. Installer Site Server 3.0. Ncraser aucun fichier, cliquer No to All .

Installer Commerce Server.

Installer Visual Studio 6.0 ou Visual Studio 97. Installer MDAC 2.1.2.42023. Installer ADSI 2.5. Installer Site Server 3.0 Service Pack 4. Installer Commerce Interchange Pipeline Manager. Rappliquer Site Server 3.0 Service Pack 4. Installer Microsoft Windows NT 4.0 Service Pack 6.

Procdure de post installation Appliquer les instructions du fichier readme.txt. Installer Microsoft Windows Script 5.1. Installer Microsoft VM version 3190.

Annexe C

Larchitecture Client/Serveur

1. Dfinition
Larchitecture client / serveur est une architecture qui permet de subdiviser un processus informatis en, aux moins, deux tches moins complexes (Client et Serveur) avec un mcanisme de communication qui permet ces sous-processus de cooprer entre eux comme le montre la figure.
Client Serveur

Mcanisme de communication

Figure 20 : Larchitecture Client / Serveur

La finalit de cette subdivision est de disposer de couches de fonctionnalits pouvant tre crites par des programmeurs et dployes sur diffrentes machines dune manire optimale. On distingue entre les trois types de couches :

Logique de prsentation : son but est de dfinir comment lutilisateur doit interagir avec lapplication. Elle est gnralement implmente laide dune interface utilisateur graphique simple dutilisation ; Logique applicative : Elle vise dfinir les mcanismes ou traitements mtier de lapplication ; Logique daccs aux donnes : Elle sintresse au stockage des donnes et leur rcupration.

Selon la rpartition de ces couches, entre client(s) et serveur(s), on peut distinguer entre de nombreuses variantes de larchitecture Client / Serveur.

2. Larchitecture Client / Serveur deux niveaux

Il sagit de la premire gnration du Client / Serveur. Le traitement des oprations est divise en deux couches distinctes : la station de travail et le serveur de donnes qui est un SGBDR. On parle alors du Client / Serveur deux niveaux ou 2-tiers. L encore on distingue entre deux approches : lapproche centre sur le client et celle centre sur le serveur.

2.1. Lapproche centre sur le client

Limplmentation la plus simple des systmes deux niveaux consiste placer la logique de prsentation et les traitements mtier sur le client. On parle dans ce cas darchitecture Client lourd / Serveur lger. Voir figure 21.

Serveur de donnes Ordinateur Personnel Requte

---------------------------------------SGBDR

-------------------------------- Logique de prsentation Logique mtier

Rponse

Logique daccs aux donnes

Figure 21 : Architecture Client lourd / Serveur lger

Les requtes de la BD manant des clients sont gnralement implmentes laide du langage de requte et de programmation SQL. La requte de la BD est transmise au serveur de donnes laide dun middleware de BD tel que ODBC de Microsoft. Lintgration troite entre les traitements mtiers et le client lourd peut provoquer des problmes majeurs :

Charge de traitement considrable sur le client ; Perturbation du trafic rseau vu les jeux de rsultats volumineux que peut gnrer les requtes de BD ; Absorption complte des ressources du serveur de donnes. En fait, chaque session ouverte ncessite une connexion de BD distincte ; Cots de dploiement et dassistance technique trs levs. Si la logique mtier change, les modifications effectuer pour mettre jour les logiciels sur un grand nombre de stations peuvent tre extrmement lourds grer. 2.2. Lapproche centre sur le serveur

Il existe une autre implmentation de larchitecture Client / Serveur deux niveaux : larchitecture Client lger / Serveur lourd. Suivant cette architecture, les traitements mtiers sont transfres sur le serveur de donnes laide de techniques telles que des procdures stockes, vnementielles et des contraintes. Comme dans le cas des systmes centrs sur le client, le fait que le SGBDR doit tablir une connexion de BD distincte pour chaque station de travail peut tre lourd de consquences pour les ressources du serveur. Aussi les systmes centrs sur le serveur sont-ils inadapts une monte en charge importante.

Serveur de donnes

--------------------------------------------Ordinateur Personnel Requte Logique applicative Logique daccs aux donnes Procdures stockes

-------------------------- Logique de prsentation Rponse

Figure 37 : : Architecture Client/lger/Serveur lourd Figure 22 Architecture Client lger / Serveur lourd

3. Larchitecture Client / Serveur trois niveaux

L objectif de cette architecture est de rpondre aux problmes voqus ci-dessus. Sa particularit est dinsrer un niveau supplmentaire entre le client et le serveur (cf. figure 23). On ajoute un serveur applicatif, entre le client et le serveur de donnes, qui encapsule les traitements mtier de lapplicatif. Son rle est de :

Ragir aux requtes du client, appliquer les traitements mtiers et invoquer les SGBDR requtes de la BD ; Grer les rponses de la BD, appliquer dventuelles traitements mtier et gnrer une rponse pour le client.

Serveur de donnes Ordinateur Personnel

------------------------Serveur applicatif SGBDR Logique daccs aux donnes

----------------------- Logique de prsentation

------------------------ Logique mtier

Procdures stockes

Figure 23 : Architecture Client / Serveur trois niveaux

Cette approche ne ncessite pas une connexion de BD distincte pour chaque session utilisateur. Elle permet au contraire douvrir un grand nombre de sessions utilisateurs avec un petit nombre de connexions de BD et prserve les ressources si prcieuses du serveur de donnes. De plus, puisque larchitecture repose maintenant sur trois niveaux, les couches sont parfaitement cloisonnes. Lavantage est quil est possible damliorer ou de remplacer lun des niveaux sans affecter les autres. Alors que les systmes deux niveaux ont parfaitement leur place dans le monde des applications simples, les systmes Client / Serveur trois niveaux sont aujourdhui considrs comme la solution idale pour lentreprise car elles sont plus facile

maintenir, mieux supports et plus mme de sadapter aux besoins en volution perptuelle de lentreprise. Le tableau compare les deux gnrations du Client / Serveur, 2-tiers et 3-tiers.

Critres Administration Scurit Encapsulation de donnes Performance Rutilisation dapplications Facilit de dveloppement Support Internet Base de donnes htrognes Richesse en choix de communication Flexibilit de larchitecture matrielle Disponibilit

2-Tiers Complexe basse basse faible faible haute faible non non limite

3-Tiers Moins complexe Haute Haute Bonne Excellente Mieux Excellent Oui Oui Excellente

faible

Excellente

Tableau 11 : Comparaison entre larchitecture 2-tiers et 3-tiers

Larchitecture Client / Serveur trois niveaux a elle aussi fait lobjet damliorations, incarnes par larchitecture multi-niveau, encore appele architecture n niveaux ou architecture n-tiers . Cette architecture est la plus flexible et la plus facile faire monter en charge et elle prsente en outre tous les avantages de larchitecture 3-tiers. Chaque fois quon a besoin dun serveur on lencapsule dans une couche distincte des autres. Si on a besoin dun serveur Web. On obtient ainsi une architecture Client-Serveur quatre niveaux appele aussi un Web trois niveaux.

4. Larchitecture Web trois niveaux

Cest une architecture Client-Serveur trois niveaux qui prend en considration la technologie Internet. Avant de lexposer, nous commenons par une introduction brve de lInternet.

4.1. Internet en bref

Lexpansion rapide et rcente de lInternet a amen beaucoup de personnes penser que ctait une nouvelle invention. En ralit, cela fait un bon nombre dannes que cette technologie existe, elle a en effet t lance par le ministre de la dfense des Etats-Unis vers la fin des annes 60. ce ministre sinquitait de ce que son infrastructure de communications pouvait tre anantie sous le coup dune seule frappe nuclaire sur le systme central. Une recherche a donc t entame qui visait dvelopper un systme de rseau dcentralis dans lequel chaque nud du rseau devait se voir affecter la mme importance et ne devait pas gner le fonctionnement global du systme en cas de dfaillance. Lors de la mise hors service dun nud, ce

rseau devait tre capable de sadapter automatiquement et de trouver un chemin alternatif pour assurer lacheminement de linformation vers sa destination. Ce rseau a t ouvert par la suite aux tablissements de recherche, aux universits et aux organisations commerciales pour devenir lensemble de rseaux interconnects connu sous le nom dInternet. Un groupe de protocoles de communications appels TCP/IP a t adopt, permettant une multitude de services de fonctionner simultanment sur le rseau (tels que les transferts de fichiers, les forums et messageries lectroniques ). Depuis lors, lInternet sest dvelopp un rythme exponentiel grce laugmentation du nombre des systmes informatiss sur le rseau. Il est noter quil ne faut pas confondre les termes Internet et WWW (World Wide Web). Il faut distinguer entre ces deux concepts. Le Web nest pas un rseau mais une application fonctionnant sur le rseau Internet. Larchitecture du Web est fonde sur larchitecture Client-Serveur : le navigateur Web (le client) est utilis pour rcuprer les documents sur un serveur Web, lequel peut se trouver sur le rseau local de lutilisateur ou lautre bout de la plante sur lInternet.

4.2. Les applications Web de premire gnration

Avec lexpansion de lInternet, de nouveaux vocabulaires sont apparus. A titre dexemple on parle de page Web qui signifie la page cran qui sera visualis par les navigateurs Web. Au dbut, ces pages Web taient statiques. En effet, elles taient figes en un fichier .htm / .html, daspect plutt austre et dpourvues de la plupart des possibilits dinteraction auxquelles lutilisateur est dsormais habitu avec les logiciels pour PC usuels. De plus, la premire gnration de navigateurs Web ne reconnat que le texte et les donnes multimdia simple comme les images et le son.

4.3. Les applications Web de deuxime gnration

La deuxime gnration dapplications Web a mis un terme laspect statique des pages Web. Ce sont les navigateurs Web de la nouvelle gnration qui ont permis cette volution. Il peuvent :

Tlcharger des composants logiciels qui peuvent tre dvelopps dans un langage de haut niveau. Ces composants rend le Web plus dynamique et plus flexible utiliser et maintenir ; Reconnatre les langages de script qui peuvent tre inclus dans un document HTML. De tels langages ont permis au poste client dtre intelligent , du fait quils peuvent contrler un champ de saisie par exemple, et davoir un comportement vnementiel , du fait qun script peut tre utilis pour dtecter un vnement dclench par un clic sur un bouton et invoquer une mthode pour effectuer le traitement ncessaire . 4.4. Un Web trois niveaux

La forte demande de contenu dynamique a transform le Web en une variante darchitecture multiniveau particulirement souple et indpendante du nombre dutilisateurs sur le rseau. Il en rsulte des applications plus faciles maintenir et supporter, tout en minimisant limpact des modifications quil est ncessaire dapporter ces applications pour tenir compte de lvolution des traitements mtiers.

Lapplication cliente est reprsente par le navigateur. Elle est responsable de la logique de prsentation dfinie par le document HTML, lequel peut inclure des scripts ou autres composants logiciels ; Le serveur Web correspond au niveau intermdiaire. Il est utilis pour distribuer les donnes du client et intgrer les sessions clientes aux applications transactionnelles ;

Le serveur applicatif soccupe de la gestion des traitements mtiers ; Le serveur de donnes, un SGBDR, soccupe de la gestion de laccs aux donnes.

Cette architecture Web prsente le grand avantage de rsoudre plusieurs problmes inhrents aux systmes client-serveur traditionnels. En rduisant lapplication cliente au HTML et un langage de script simple, il devient possible de dvelopper une application unique et universelle pouvant tre dploye sur diffrents types de plateformes. Tout le traitement ct client est administr de faon centralis et dploy dynamiquement, ce qui signifie que toute mise jour est applique automatiquement lorsque lutilisateur dmarre lapplication. Cela vite une installation manuelle sur chaque poste client.
Serveur Web Client (Navigateur Web)

------------------- Scripts et composants

------------------------- Logique de prsentation

HTML

Serveur de donnes (SGBDR)

----------------------------------- Gestion de laccs aux donnes

Serveur Applicatif

----------------------------Traitements mtiers

Procdures stockes

Figure 24 : Larchitecture Web trois niveaux

5. La solution Microsoft : larchitecture DNA

5.1. Prsentation de DNA
Microsoft prsente son architecture client-serveur, baptise DNA (Distributed interNet Applications ou applications Internet rparties), comme une plate-forme de dveloppement pour applications totalement rparties. DNA repose sur un ensemble de services figurant dans le tableau 12.

Types de services Serveur de donnes Serveur Applicatif Serveur Web Navigateur Client Langage de script Langage de cration de composants Environnement de dveloppement Web Accs universel aux donnes Machine virtuelle Java

Offre Microsoft Microsoft SQL Server Microsoft Transaction Server Microsoft Internet Server (IIS) Internet Explorer Information

Active Server Pages (ASP), Dynamic HTML, Jscript, VBScript Microsoft Visual Basic, Microsoft Visual C++ Microsoft Visual Interdev

ActiveX Data Object (ADO), Decision Data Support (DSO), OLE-DB, ODBC Microsoft JVM
Tableau 12 : Larchitecture DNA

Lacronyme DNA dsigne en ralit un ensemble de technologies dont la plupart existaient dj. En tant que mthodologie, DNA conoit une application comme un ensemble de niveaux, le client se trouvant au-dessus et la source de donnes audessous. Les objets mtier occupent un niveau intermdiaire.

Larchitecture DNA peut tre schmatise comme le montre la figure 25.

Interface Client ( navigateur)

Serveur Applicatif (MTS)

Composant mtier Serveur Web (IIS)

Composant mtier

Serveur de donnes (SQL server) OLE-DB ODBC

Composants mtier

Scripts

Scripts

TCP/IP Rseau

TCP/IP

Figure 25 : Larchitecture DNA

5.2 Les composants technologiques de DNA

Maintenant, nous allons prsenter chaque composante technologique de larchitecture DNA. 5.2.1. Windows NT Server Cest un systme dexploitation de rseau simple, robuste, haute performance et polyvalent. Le souci qui tait derrire est de dvelopper un systme dexploitation portable, scuris, capable de monter en charge, extensible, compatible et sadaptant plusieurs langues. 5.2.2. ActiveX ActiveX est une technologie Microsoft permettant des composants logiciels de cooprer mme sils ont t dvelopps par des diteurs diffrents, des moments diffrents, avec des outils diffrents, et que les objets se trouvent dans le mme processus, sur le mme ordinateur ou rpartis sur plusieurs ordinateur. ActiveX englobe une srie de sous-lment , chacun dfinissant linterface entre les objets pour implmenter une technologie donne. Voici quelques exemples de sous-lments relatifs lInternet :

Scripts ActiveX : permettent linsertion de scripts dans une page Web ou leur utilisation sur le serveur pour gnrer le contenu de la page ; Contrles ActiveX : permettent aux composants dapplications clientes dtre tlchargs dynamiquement si ncessaire et utiliss sur une page Web ; Documents ActiveX : permettent au navigateur de reconnatre les documents non HTML ;

Source de donnes

Composants ActiveX serveur : permette au serveur Web de communiquer avec dautres composants logiciels de serveur.

5.2.3. Le modle COM/DCOM COM ou le Modle de composants Objet (Component Object Model) constitue la structure sous-jacente de ActiveX. Il dfinit linterface binaire entre les objets (voir annexe B). 5.2.4. Internet Information Server (IIS) Internet Information Server est un serveur Web. Il a t conu spcialement pour la gnration de pages Web dynamiques. Il fournit des services Internet tels que WWW (publication Web dinformations et distribution dapplications), FTP (transfert de fichiers), NNTP (groupes de discussion) et SMTP (courrier). 5.2.5. Active Server Pages (ASP) Un document ASP peut contenir la fois du code HTML et des scripts excutables sur le serveur. Les ASP permettent aux scripts de sinterfacer avec un grand nombre de composants logiciels compatibles COM, voir figure 26, tels que ceux fournis avec ASP et ceux dvelopps par le dveloppeur lui-mme ou par un vendeur de logiciel indpendant. Par exemple, ASP est fourni avec ADO (ActiveX Data Objects) qui procurent une interface trs performante avec les bases de donnes compatibles ODBC ou OLE-DB. 5.2.6. Microsoft Transaction Server (MTS) MTS simplifie la tche du dveloppeur en traitant automatiquement les problmes de threading, le partage de ressources ou la gestion du contexte transactionnel entre objets.
Windows NT Internet Information Server Scripts ASP Application WWW ASP ADO ODBC

Internet

SQL SERVER

Fichiers HTML

Figure 26 : Les pages ASP

Cela signifie quun dveloppeur peut se concentrer uniquement sur le dveloppement de lapplication mtier tandis que les traitements de bas niveau ainsi que linfrastructure sont grs automatiquement.

MTS Client Contexte dobjet

Composant

Gestionnaire de ressources

Accs aux donnes ADO Source de donnes

Pilote de source de donnes OLE-DB/ODBC

Figure 27 : MTS

Le dveloppement relatif au traitement des transactions est une activit difficile et la tche a tendance se complexifier lorsque le nombre de transactions augmente et que celles-ci sont distribues sur de multiples plates-formes. Dvelopper des applications laide de composants logiciels compatibles COM et les installer dans lenvironnement MTS limine le besoin de dvelopper sa propre logique transactionnelle. MTS contrle le droulement des transactions et gre automatiquement lannulation de lensemble de la transaction (roll back) en cas dchec. 5.2.7. SQL Server Microsoft SQL Server est un systme de gestion de bases de donnes relationnelles conu spcialement pour les architecture client / serveur distribues. Une application Web peut facilement retrouver et stocker des informations partir dune base de donnes SQL Server en utilisant des scripts ASP pour grer linterface avec les composants ADO. SQL Server fournit galement un assistant Web (Web Assistant Wizard) permettant ladministrateur de la base de donnes de dfinir une requte qui sera automatiquement insre dans un document HTML, soit dans des circonstance prdtermines , soit lorsque la base de donne sera modifie.

Annexe D

COM/MTS : Middleware objet de Microsoft

COM/MTS est le Middleware objet de Microsoft. Il repose sur le modle objet appel COM (Component object Model). DCOM constitue le modle objet distribu. Ce modle complexe mettre en uvre, a t simplifi par lintroduction de MTS (voir annexe B), le moniteur transactionnel de Microsoft.

1.Introduction
Le sigle COM possde deux signification. Pour Microsoft, il signifie le Component Object Model qui constitue le modle objet sous-jacent au Middleware OLE version2.0 (Object Linking and Embedding), le sigle COM dsigne aussi le Common Object Model. Ce dernier est en fait une extension du modle objet prsent dans OLE 2.0. Ainsi les deux dfinitions associes au sigle COM ne font que designer le mme modle diffrents stades de son volution.

2.Le modle objet COM

Le modle COM dfinit des mcanismes pour la cration dobjets ainsi que pour la communication entre clients et objets distribus travers un rseau dordinateurs. Ces mcanismes sont indpendants des langages de programmation utiliss pour raliser les objets. COM dfinit un standard dinteroperabilit au niveau binaire afin de le rendre indpendant des systmes dexploitation et des machines.

2.1 Interface et objet

Notion dinterface

La notion dinterface dfinit un ensemble de fonctions associes un objet. Le mot interface reprsente la signature de ces fonctions, cest dire leur nom et lensemble de leurs paramtres. Un implantation dinterface est constitue du code de ces fonctions. Enfin, une instance dinterface est un tableau de pointeurs vers le code de ces fonctions. Notons que chaque interface est unique dans le systme. Un GUID (Globally Unique Identifier) permet de designer chacune dentre elles. Notion dobjet

La structure dun objet COM se dduit du concept dinterface. Un objet COM possde une ou plusieurs interfaces auxquelles un client accde par des pointeurs. Il nest pas

possible daccder directement lobjet lui-mme. Le corps de lobjet contient le code des mthodes ainsi que les donnes qui lui sont propres. La figure suivante montre la structure complte dun objet. Ainsi dans le modle COM, les clients accdent aux objets par lintermdiaire de contrats bien dfinis qui sont raliss par les interfaces offertes par lobjet. Pour identifier les interfaces COM on utilise les GUID. Lorsquun objet offre une interface cela signifie quil sait excuter toutes les fonctions appartenant cette interface et quil fournit au systme COM un pointeur vers ces fonctions.
Partie description

Interface Fonction_1(parametre1, parametre_p) Fonction_1(parametre1, parametre_p)

(signature des operations fonction_f et fonction_f)

Instance dinterface Pointeur sur fonction_1

Fonction_1 (parametre_1, parametre_p) { //code de la fonction }

}mthode
fonction_1

}mthode
fonction_f

Pointeur sur fonction_f

Fonction_f (parametre_1, parametre_p){ //code de la fonction }

Partie ralisation

Figure 28 : Interface, implantation dinterface et instance dinterface

2.2 Accs aux interfaces dun objet

Lorsquun utilisateur dun objet obtient un pointeur vers cet objet, ce pointeur rfrence seulement une interface de cet objet. Le client nobtient jamais un pointeur sur lobjet lui-mme. Le pointeur obtenu permet daccder aux fonctions figurant dans linterface rfrence. Ce pointeur ne lui permet pas daccder aux donnes propres lobjet. Enfin, ce pointeur ne lui donne pas un accs direct aux autres interfaces de lobjet. Ainsi laccs aux attributs dun objet ne peut se faire que par lintermdiaire de fonctions appartenant une interface et chaque interface doit pouvoir permettre daccder aux autres interfaces de lobjet. Pour ce faire il existe une fonction standard appele QueryInterface. Cette fonction permet, partir dun nom dinterface, dobtenir un pointeur vers cette interface.

2.3 Linfrastructure de COM

Le standard au niveau binaire des interfaces est la cl de larchitecture COM et permet son extensibilit. Ce standard definit comment clients et objets interagissent. Tout ceci implique que COM spcifie galement : Le mecanisme dobtention dinterface par la fonction QueryInterface. Le comptage des clients accdant un objet par les fonctions AddRef et Release.

Les rgles de gestion mmoire. Lorsque client et objet changent des donnes travers deux espaces mmoires, il est ncessaire dallouer temporairement des mmoires tampons. Un nombre rduit de fonctions de base utilisables par les clients et les serveurs. Pour les clients ces fonctions autorisent la demande de cration dobjets. Pour les serveurs elles offrent la possibilit de rendre accessibles les objets nouvellement cres. Le service de location des serveurs. Ce service permet de dterminer partir dun identifieur de classe, le nom de Service Control Manager (SCM). Lappel de procdure distante lorsque client et objet fonctionnent dans deux espaces mmoires distincts. Un mcanisme dallocation mmoire pour les applications. Un mcanisme de gestion des noms pour baptiser tout nouvel objet. Un mcanisme de transfert uniforme des donnes.

Ainsi le Middleware COM permet la cration, le stockage et la dsignation dobjets. Il permet aussi la communication entre objets et lchange de donnes. La figure suivante montre que les composants de COM interagissent entre eux, une fonction pouvant faire appel dautres fonctions.

Client

Serveur

Transfert des donnes

Gestion des noms

Gestion mmoire

API infrastructure COM SCM RPC

Figure 29 : Le Middleware COM

3.Le modle DCOM

La technologie DCOM permet deux objets, lun client, lautre serveur, de communiquer entre eux et ceci indpendamment du fait que ces deux objets soient sur la mme machine ou sur deux machines distinctes. La structure de communication est dfinie lavance. Le client ne peut demander que les services offerts par linterface du serveur. Cette structure de communication est implante sous la forme dun objet proxy au niveau du client et dun stub au niveau serveur. La recommandation actuelle est de structurer les applications en trois tages. Par exemple, une application de facturation peut tre structure comme suit : le premier tage est lobjet interface utilisateur. Le seconde tage est lobjet contenant le code de la fonction Facturation. Le troisime tage est constitu par lobjet base de donnes.

Construire une application avec la technologie DCOM conduit la structure indique dans la figure suivante. On remarque que lobjet facturation joue deux rles. Il apparat comme serveur dans son dialogue avec lobjet Interface et de ce fait possde un stub serveur. Il est aussi le client dans son dialogue avec lobjet Base de donnes. A ce titre, il possde un proxy client. Ainsi, tout objet serveur possde autant de stubs serveurs quil a de clients associs. Rciproquement, tout objet client dialoguant avec n objets serveurs possde n proxys clients.

Machine A

Machine X

Machine Y

Interface

Facturation

Data Base

Middleware DCOM

Figure 30 : Exemple dapplication structure en trois tages ralise avec DCOM

Annexe E

Le langage XML

1.Intoduction au XML
XML est un langage de marquage constitu de balises tout comme HTML. Il est lacronyme de eXtensible Markup Language, cela signifie que XML nest pas un langage smantiquement fig comme peut ltre HTML ; mais au contraire un langage ouvert. Cest dire que lauteur dun document XML peut crer ses propres balises. Exemple de code : < ? xml version= 1.0standalone= yes ?> <texteprincipal> <texterouge>exemple XML </>texterouge <saut2lignes/> <graspolice12>Cestfini..</<graspolice12> </texteprincipal>

2.Pourquoi le XML ?
2.1.Les limites du HTML
Mme si le HTML est trs implant sur le Web grce, notamment sa facilit dutilisation, il devient rapidement un langage dpass. Pourquoi ? les raisons sont : trop restrictif : impossible de crer ses propres balises. Trop port vers la prsentation et non sur la description, ce qui pose problme pour les navigateurs textes, les PC de poche Trop dpendant du W3C, dou une profusion de balises et dattributs non normaliss ( balises dites propritaires dInternet Explorer ou de Netscape, comme BLINK, BGSOUND, MARQUEE) et reprsents donc plus ou moins bien suivant le type de navigateur et dOS. Pas assez svre au niveau de la syntaxe ( malgr une balise non ferme ou manquante, le document sera affich correctement avec la plupart des navigateurs ) ce qui pose de gros problmes aux dveloppeurs.

2.2 Lapport du XML

Le XML, quant lui, a trs peu de dfauts : on peu mme dire quil na que des qualits :

Structur : comme le SGML ( le pre des langages HTML et XML ), le XML est trs strict au niveau de la syntaxe, ce qui vite nombre de documents incorrectes. Flexible : on cre soi-mme ses propres balises XML, adaptes ses besoins. Portable : compatible 100% avec les navigateurs des derniers gnrations ( ce qui nest pas le cas du HTML, qui pour une mme page, donnera un rsultat sensiblement diffrent suivant le navigateur utilis). Descriptif : le langage XML, contrairement au HTML, dcrit exclusivement la signification du contenu do une meilleure approche.

3.Regles de construction dun fichier XML

3.1.Structure XML
La mise en place dune structure XML, sur un ensemble de donnes, suit quelques rgles (dtermines et standardises par le W3C) Les informations peuvent tre soit des lments, des attributs ou des entits : Elments : les informations sont encadres par des balises ouvrantes ( exemple <Texte >) et fermantes ( exemple </Texte >).. Attributs : les informations sont encadres par des balises >Texte type= Gras > : ici type est un attribut, qui a pour valeur Gras. Entits : ce sont des constantes ou des variables de stockage. Ainsi, si texte est dclar comme une entit associe la variable txt , dans tout le document XML, lusage de la notation &txt quivaut utiliser la chane de caractres texte . Mais une entit peut reprsenter galement un fichier XML en entier. Ainsi, un fichier XML peut contenir des fichiers XML externes. Exemples dentits : &lt ;---> < &gt ;--->< &amp ;---> & &quat ;---> &apos ;--->

Les lments (dfinis prcdemment ) doivent suivre des rgles dj connues par les utilisateurs de Well-formed HTML (HTML bien form) : Les balises ne doivent pas se recouvrir : le XML impose une hirarchie stricte.

Les valeurs des entits ou des attributs doivent toujours tre encadres par des guillemets (simples ou double ). Un document XML peut tre associ une DTD (Dfinition de Type de Document). La structure du document XML (intitul des balises, imbrications des balises,) peut tre dclare formellement dans le corps du document XML ou dans un fichier part. Cette dclaration sappelle une Dfinition de Type de Document (DTD). Elle seffectue selon un formalisme particulier, dfini lui aussi dans la spcification XML. Cette dclaration est facultative. Lorsquun document XML possde une DTD associe et la respecte, on dit quil est valide. Lorsquil respect seulement les rgles de la grammaire XML (balises fermes, correctement imbriques..), on dit quil est bien form. La reprsentation, travers une structure XML, dun ensemble de donnes nest pas unique : cest aux utilisateurs de choisir celle qui leur convient le mieux.

4.Regles de construction dun fichier XSL

4.1.Introduction aux feuilles de styles XML
Un fichier XSL est une feuille de styles, ddie au XML, et elle est elle-mme un fichier XML. Donc les rgles dun document XML sapplique un document XSL. Le XML permet de sparer linformation de son traitement, cest pourquoi lexistence dune feuille de styles ddie au XML est lgitime. Elle permet de formater un document XML en un document HTML ou PDF par exemple. Un fichier XSL nest compos que dune suite de gabarits et de motifs.

4.2.Dfinitions
Motif : objet introduit par lattribut match, dsignant un ou plusieurs lments XML. Exemple match traducteur/mot/franais dsigne les lments suivants : <franais>bleu</franais>,<franais>rouge</franais>et<franais>vert</franais> Gabarits : objet introduit par llment template dfinit une suite dinstructions appliquer aux lments XML dsigns par lattribut match.