Intgration de logiciels

Module 307

E.D.I.

Introduction Edifact EDI/XML Bibliographie Webographie

Grard-Michel Cochard cochard@u-picardie.fr

Echange de donnes informatis

Introduction

Gnralits
EDI est un achronisme signifiant initialement Electronic Data Interchange". La traduction usuelle en franais est "Echange de Donnes Informatises" ou "Echange de Donnes Informatis" car c'est aussi bien l'change que les donnes qui sont "lectroniques", c'est dire numriques. Son but est de transmettre "facilement" des documents de travail comme des bons de commandes, des factures, etc. EDI a trouv dans le e-commerce, une voie de dveloppement importante dans la mesure o la productivit des entreprises concernes est augmente par cette mthode d'change. Bien entendu, EDI repose sur un certain nombre de "rgles" permettant de retrouver rapidement l'information souhaite sans intervention humaine. On trouvera quelques illustrations de l'usage d'EDI l'adresse suivante http://www.sterlingcommerce.com/Apps/SuccessStories/ : De fait EDI extrait l'information des applications courantes d'une entreprise et l'envoie aux partenaires de cette entreprise de manire automatique. Ces rgle sont des standards de formats de message. Les standards connus sont varis ; les plus anciens sont EDIFACT et ANSIX12. Ils ncessitent des logiciels spcifiques coupls avec les logiciels d'applications et de gestion et les logiciels de communication. Les bnfices que l'on peut retirer de l'usage d'EDI sont nombreux :
G G G G G G G

change confortable de documents commerciaux rduction des cots de transaction rduction du flot d'information amlioration du service client rduction des cots de transport et amlioration des conditions de transport rduction des erreurs de transmission etc.

Les informations qui peuvent tre changes par EDI sont trs nombreuses. Donnons quelques aperus :
G

G G G G

Achats : ordres d'achats, acquittement des ordres d'achat, modification des ordres d'achat, devis,... Fabrication : spcifications des produits, rsultats de tests, plannings de fabrication,... Comptabilit-Finance : Factures, comptes, bordereaux, ... Marketing : prix, catalogues, suivi des ventes,... Logistique : messages divers

Les travaux de standardisation ont t mens par EdiFrance ce qui a abouti au standard EDIFACT. Toutefois la dferlante Internet a profondment remis en cause ce standard, XML devenant le langage ddi la transmission de donnes. D'autres projets de standards et les produits correspondants sont apparus, d'o une certaine "crise" de l'EDI. Il semble maintenant qu'un rapprochement entre EDIFACT et

les dveloppements nouveaux soit invitable ce qui conduit ce qu'on appelle maintenant XML/EDI. C'est tout naturellement dans le cadre du B2B que ces changes automatiss se sont dvelopps. Pour les dtails on pourra se rfrer l'excellent article de Claude Chiaramonti (Techniques de l'Ingnieur H3598 http://www.techniques-ingenieur.fr ) qui nous avons emprunt quelques exemples.

EDI et e-Business
En principe, l'EDI ne concerne que les changes lectroniques entre entreprises. On peut donc rattacher l'EDI ce qu"on appelle maintenant le B2B (Busines To Business) bien qu'apparu avant le concept de ecommerce. On peut considrer EDI comme un back office de B2B, facilitant les changes rptitifs. On prend souvent, pour illustrer cette situation, l'exemple d'un supermarch. Ds qu'une vente est effectue et valide au niveau d'une caisse de supermarch, celle-ci tablit un ticket de caisse, informe l'application de gestion de stocks d ela vente effectue. A priodes rgulires, cette application passe commande automatiquement auprs des fournisseurs concerns dans le but de ractualiser les stocks :
G

G G

l'application de gestion des stocks recherche les caractristiques des produits renouveler. Elle en fabrique un fichier. ce fichier sert de base la confection de messages normaliss envoys aux fournisseurs concerns. chez le fournisseur, une application ddie traduit ces messages en un fichier qui sera utilis pour livrer au supermarch les produits renouveler.

Bien entendu, ces procdures sont susceptibles d'amlioration. Par exemple, il serait souhaitable de remplacer la confection de fichier par la mise jour de bases de donnes. Il faut insister sur le fait que l'automatisme recherch doit satisfaire aux conditions suivantes :
G

les donnes transmises doivent tre connues a priori et structures en vue d'une codification. Il faut galement prvoir... l'imprvu : des zones libres de texte correctif doivent tre prvues (donnes exceptionnelles ou supplmentaires par exemple). il faut la prsence d'outils logiciels de traduction des messages et d'incorporation de leurs donnes dans les applications existantes (mapping). la codification des messages doit faire l'objet d'un standard pour une comprhension mutuelle

C'est videmment ces conditions que l'on pourra atteindre les "5 zros" : zro papier, zro dlai, zro stock, zro dfaut, zro litige.

L'exemple du supermarch peut tre gnralis. On peut tendre EDI aux relations entre partenaires divers :

En imaginant sans problme les diffrents changes on peut dresser la liste des messages types incorporer dans l'EDI et leur codification EDIFACT :

Malgr ces aspects prometteurs, il faut constater que l'EDI ne s'est pas vraiment propag dans les entreprises. En 1998, on pouvait noter qu'aux Etats Unis, si 98% des grandes entreprises pratiquaient l'EDI, seulement 2% des PME l'utilisaient.

Echange de donnes informatis

EDIFACT

Gnralits
EDIFACT provient d'une analyse des processus mtiers et n'a donc pas pour origine une technologie informatique (contrairement XML). EDIFACT est un langage deux niveaux : un niveau syntaxique et un niveau smantique (c'est encore une diffrence avec XML qui n'est qu'un langage syntaxique). Le niveau syntaxique dcrit un message structur : sparateurs, segments et messages (regroupements de donnes), scnarios (enchanements de messages). Le niveau smantique permet de caractriser les changes en leur donnant un sens correspondant aux transactions usuelles : commandes, factures, ... correspondant aux besoins des utilisateurs. Des rpertoires inventorient toutes ces caractristiques. Ils sont appels TDID (Trade Data Interchange Directories) et sont relatifs des secteurs d'activits prcis (des "communauts" d'utilisateurs ont bti peu peu ces rpertoires dans le cadre du Cefact (dpendant des Nations Unies) et plus prcisment du EWG (Edifact Working Group)). Mis jour rgulirement, ces rpertoires se composent de 5 dictionnaires :
G G G G G

le dictionnaire des donnes lmentaires le dictionnaire des donnes composites le dictionnaire des listes de codes le dictionnaire des segments le dictionnaire des messages

Les dictionnaires
I

dictionnaire des donnes lmentaires

Il prsente quatre types de donnes : qualifiants, littraux, donnes d'identification, donnes codes et identifient des informations simples comme un code postal, un prix unitaire, une date, un code produit, .... Les donnes lmentaires sont reprsentes par un code 4 chiffres, un libell, une description et un format. Chaque chiffre, sauf celui des dizaines, a une interprtation :

Ainsi un intervenant pourra tre dcrit par

G

G G

3035 : qualification de l'intervenant : code donnant une signification prcise au rle d'un intervenant 3036 : nom de l'intervenant : nom littral d'un intervenant d'une transaction 3039 : identification de l'intervenant : code identifiant un intervenant dans une transaction (dfini par un utilisateur ou un organisme) 3045 : code prcisant le format du nom de l'intervenant : nom complet ou initiales ou nom de jeune fille, ....

dictionnaire des donnes composites

Il dfinit des ensembles de donnes lmentaires. Ainsi on pourra donner des dtails sur un intervenant : C082 : dtail de l'identification d'un intervenant : 3039 : identification de l'intervenant 1131 : qualifiant d'une liste de codes 3055 : organisme responsable d'une liste de codes Le code de la donne composite est dfini sur une lettre et trois chiffres. La lettre indique le statut : M (mandatory : donne obligatoire), C (conditional : donne facultative).
I

dictionnaire des listes de codes

Comme indiqu plus haut, lorsqu'une donne simple est code par un nombre impair, cela signifie qu'elle est dfinie dans une liste de codes. Ces listes sont soit dfinies par l'UNCL (United Nations Code List) ou par des normes internationales : ISO 4217 (codes monnaies), ISO 3166 (codes pays), ISO 2955 ( units du systme international), etc.

dictionnaire d'un segment

Il dfinit des agrgats de donnes lmentaires ou composites. Par exemple, le segment Dimensions comprendra la donne lmentaire "qualifiant de dimension" et la donne composite "dimensions" compose de donnes lmentaires : DIM : dimensions 6145 : qualifiant de dimension C211 : dimensions 6411 : qualifiant de l'unit de mesure 6168 : longueur 6140 : largeur 6008 : hauteur
I

dictionnaire des messages

Chaque message type est dcrit par sa structure (boilerplate) compose de segments ou de groupes de segments. Les messages constituent la base des changes. Un change possde la structure suivante :

avec :

UNA : segment de service UNB : en-tte d'change UNZ : fin d'change UNG : en-tte de groupe fonctionnel UNE : fin de groupe fonctionnel UNH : en-tte de message UNT : fin de message Un message relatif une commande (message ORDERS) sera, par exemple, reprsent par la succession suivante de segments (le dbut du message est seulement montr ici) :

Cette structure est gnralement complte par un diagramme de branchement indiquant comment les segments s'enchanent ou se rptent. Un exemple est donn ci-dessous avec un message "facture" (INVOIC) :

Pour chaque segment, on a deux codes : M 1, C 5, par exemple. M signifie que le segment est obligatoire (mandatory) et C facultatif (conditional). Le nombre correspond au nombre maximum de rptitions du segment (1 : 1 fois, 35 : 35 fois,... ). Le niveau 0 est rserv aux segments initiaux n'apparaissant qu'une seule fois. Le diagramme se lit de haut en bas et de gauche droite. On a donc UNH M 1, BGM M 1, DTM M 35, PAI C 1, ALI C 10, IMD C 1, FTX C 10, Gr.1 C 10, RFF M 1, DTM C 5, Gr.2 C 20, NAD M 1, LOC C 25, FII C 5, Gr.3 C 9999, RFF M 1, DTM C 5, ....

Les rgles d'utilisation d'EDIFACT

Les rgles de syntaxe d'Edifact sont dfinie dans le document TRADE/WP.4/R.530/Rev.1 du 21/12/1988. Des versions successives ont suivi. Ainsi en 199, 6 jeux de caractres utilisable sont t dfinis : UNOA, UNOB, UNOC, UNOD, UNOE, UNOF. Des caractres spcifiques sont utiliss comme sparateurs. Ainsi dans UNOA : ' : fin de segment + : sparateur entre lments de donnes : :sparateur entre donnes lmentaires dans une donne composite Des techniques (au demeurant lmentaires) de compression sont utilises pour rduire la taille des messages comme la suppression des caractres non significatifs : suppression des 0 devant des nombres, suppression des blancs de remplissage dans des chanes de caractres. On peut aussi supprimer les donnes facultatives pour lesquelles les valeurs ne sont pas fournies. exemple : segment AAA comprenant les donnes DE1 (lmentaire), DE2 (lmentaire), DC1 (composite), DC2 (composite), DE3 (lmentaire), soit AAA+DE1+DE2+DC1+DC2+DE3'. Supposons que les donnes

composites soient constitues de la manire suivante : DC1 : ED1C1, ED2C1, ED3C1, ED4C1 DC2 : ED1C2, ED2C2, ED3C2, ED4C2 Le segment s'crira donc AAA+DE1+DE2+ED1C1:ED1C2:ED1C3:ED1C4+ED1C2:ED2C2:ED3C2:ED4C2+DE3' Si la donne lmentaire DE2 est facultative et non valorise, si les donnes ED3C1 et ED4C1 sont facultatives et non valorises, le segment peut alors s'crire AAA+DE1++ED1C1:ED2C1:ED3C1:ED4C1+ED1C2:ED2C2+DE3'

Les amliorations d'EDIFACT

Signalons que la mise jour du standard est trs lourds (comme pour tous les standards) car elle ncessite des runions internationales des partenaires (qui doivent videmment tre d'accord sur les propositions). Malgr ces handicaps, le standard EDIFACT a t largement amlior dans les directions suivantes :
G G G G

interactivit pour certains besoins (tourisme, sant) multimdia pour prendre en compte ces donnes nouvelles scurit : emploi de messages spciaux ouverture : EDI orient objet

La version 4 de la norme ISO 9735 intgre ces avances :

Mais, entre temps, XML s'est propag dans le monde Internet.....

Echange de donnes informatis

XML et EDI

Gnralits
La monte en charge d'Internet grce au Web partir de 1995 et les technologies associes ont fait natre le commerce lectronique (e-business). Le langage XML, qui est l'une des technologies Internet, est devenu quant lui le langage universel de description structurelle de document. Il tait donc normal que XML soit utilis pour l'change de donnes informatises. XML possde de nombreux avantages, notamment :
G G G

il permet le transport de donnes de types divers y compris multimdias il permet un affichage personnalis par utilisation de feuille de style et de filtres XSL il permet le dialogue entre systmes de gestion de bases de donnes diffrents

Plusieurs solutions ont t proposes par les acteurs du e-business :

G G G

les solutions des diteurs informatiques : exemple biztalk de Microsoft les solutions de consortiums de standardisation : exemple ebXML de UN/CEFACT et OASIS les solutions des secteurs professionnels : exemple RosettaNet pour les industries lectroniques.

Un survol de ebXML
Notons tout d'abord que ebXML permet de dcrire un processus commercial ou processus mtier (Business Process) sous la forme d'un fichier XML appel Business Scenario bti avec un schma : Business Process Specification Schema. Il peut tre aussi dcrit avec UML. Le schma ci-dessous explicite une transaction entre deux partenaires commerciaux A et B ayant changer des documents (commerciaux).

Le ebXML Registry contient des modles pour les transactions commerciales sous la forme de fichier XML descriptifs. La socit A qui souhaite tablir des changes commerciaux avec la socit B commence par regarder dans le Registry les modles et construit ensuite sa propre application commerciale qu'elle implante localement (ebXML fournit pour cela les outils ncessaires et des composants "prts l'emploi"), puis soumet au Registry son Business Profile qui dcrit les capacits et les contraintes de la socit A et son Business Scenario. Aprs vrification de conformit, un accus de rception est transmis la socit A. La socit B, suppose avoir dj implant une application ebXML (sinon elle fait comme la socit A), va dcouvrir dans le Registry le Business Profile et le Business Scenario de la socit A. La socit B envoie la socit A une intention de s'engager avec elle dans un Business Scenario. Les deux socits se mettent d'accord sur les rgles rgissant les transactions (y compris les rgles de scurit). Si la socit A est d'accord, les transactions peuvent s'engager. UN/CEFACT propose une mthodologie de modlisation des transactions commerciales appele UMM (UN/CEFACT Modeling Methodology) qui comporte deux vues :
G G

Business Operational View : aspects mtiers des transactions auquel il correspond des standards BOV Functional Service View : aspects techniques des transactions auquel il correspond aussi des standards FSV

Les deux types de standards BOV et FSV sont relis. Le BOV concerne la smantique des donnes mtiers dans les transactions et les donnes d'change associes ainsi que l'architecture des transactions mtiers : conventions oprationnelles, agrments, obligations mutuelles et contraintes.

Le FSV concerne les capacits fonctionnelles (implmentation, dcouverte, scnarios d'excution), les interfaces (Business Service Interfaces, pour les utilisateurs et le transfert de donnes), les protocoles et les services relatifs aux messages (Messaging Services).

Les phases fonctionnelles d'une transaction ebXML, dcrites succinctement plus haut, sont dtailles comme suit :
G

Phase d'implmentation

Il s'agit de construire une infrastructure ebXML. Le partenaire commercial doit d'abord acqurir des copies des spcifications ebXML partir du Registry et donc tlcharger les Core Library et Business Library.
G

Phase de dcouverte et de rcupration

Un partenaire commercial qui a implment une Business Service Interface de ebXML peut procder la phase de dcouverte et de rcupration partir d'un autre partenaire commercial et partir du Registry

Phase d'excution

Les partenaires commerciaux changent par des messages synchroniss et structurs par utilisation du Messaging Service de ebXML.

L'infrastructure de ebXML
Le CPP Pour changer, les partenaires commerciaux doivent publier a priori des informations sur le processus mtier et sur leurs possibilits pour l'change considr. Ceci est fait par le Collaboration Protocol Profile (CPP) qui est un document permettant de dcrire le processus mtier et les ncessits de la Business Service Interface de manire standard (pour tre compris de tous). Il contient (liste non exhaustive) :
G G G G G G G

les coordonnes de contact la classification industrielle les rles du partenaire (vendeur, acheteur, ...) les processus mtiers supports les besoins de l'interface les besoins des messages les informations de scurit

Le CPA Un Collaboration Protocol Agreement (CPA) peut tre considr comme l'intersection de deux CPP ; il est mutuellement reconnu par les deux transactionnaires. Il dcrit
G G

le Messaging Service les besoins des processus mtiers

La modlisation de l'information et des processus mtiers Le Metamodle correspondant constitue la base de la construction de spcifications sous forme d'un schma qui peut tre en UML ou en DTD.

Comparaison avec d'autres technologies du e-Business

Echange de donnes informatises

Bibliographie

G G G G

R. Marchand, H. Agnoux et C. Chiaramonti, Applications EDI sur l'Internet, Eyrolles C. Charmot, L'change de donnes informatis (EDI), Que-sais-je ? Paquel, XML et le dveloppement des EDI, Hermes M.A. Emmelheinz, EDI, L'change de donnes informatises, Dunod

Echange de donnes informatises

Webographie

http://www.techniques-ingenieur.fr (voir les articles H3598 de Claude Chiaramonti, AG5320 d'Alice Aguemon, H7348 de Claude Chiaramonti) http://xmlfr.org/index/object.title/edi/ http://www.geocities.com/WallStreet/Floor/start.htm?200517