XML og EDI Elektronisk Handel Agenda: Egenskaper ved handel Interorganisatoriske systemer og XML/EDI Sammenlikning av XML og EDIFACT Hva ligger i XML/EDI Norsk XML/EDI prosjekt Ved Per Myrseth per.myrseth@nr.no Slide 1

XML/EDI: Målsetning Målet for XML/EDI er å anvende XML og Internett til utveksling av forretnings-dokumenter og til kommunikasjon mellom handelspartnere i åpne og fritt tilgjengelige systemer XML/EDI må greie å spise markedsandeler fra etablerte EDIFACT løsninger og fra nye markeder for å bli en suksess. Slide 2

Fokus for denne presentasjonen Ønsker å vise at XML kan brukes som en byggekloss i et interorganisatorisk system som skal utføre handelstransaksjoner Et Interorgasnisatorisk system (IOS), involverer flere juridiske aktørers datasystemer og har til hensikt å være et verktøy for å gjennomføre handelsetransaksjoner mer eller mindre automatisk Systemutvikling og det å sette i drift IOS’er vil være fokus for denne presentasjonen Slide 3

Viktige begrepsskiller XML som syntaks XML familien av standarder Interorganisatoriske systemer som benytter XML og XML familien Mye literatur og markedføringspersonell som omtaler XML og XML/EDI skiller ikke tydlig nok på disse tre nivåene. Slide 4

Penge- , informasjons- og vareflyt ved handel $ $ Penger Penger Penger Informasjon Informasjon Leverandør av råvarer Informasjon Tilvirker Detaljist Konsument Varer Varer Varer Fysisk- eller digital vareflyt Tradisjonell verdikjede Må ha infrastruktur for vareflyt enten de er fysiske eller digitale Slide 5

Faser i en handelstransaksjon Aktørene må finne hverandre Produkt og prisinformasjon utveksles Kontrakt inngås Varer leveres Betaling utføres Oppfølging og rapportering Generiske aktiviteter som vanligvis skjer ved en handelstransaksjoenr av typen kjøp-salg Slide 6

Gruppering av norske virksomheter, fordelt etter antall ansatte 80% av norske bedrifter er under 5 ansatte. Det gir oss en kjempeutfordring, når vi skal lage datasystemer til dem som skal gjøre det enkelt å drive elektronisk handel. Både IT-kompetansemessig og finansielt står de fleste svakt til å takle store innføringsprosjekter av tradisjonelle EDIFACT systemer. Tall fra SSB 1995, primærnæringer er ikke medregnet. Slide 7

Egenskaper ved handel som påvirker handelsløsninger Lav Høy Vare verdi Kompleksitet av varer/tjenester Hyppighetsfrekvens på kjøp Antall forskjellige varer Aktivitetsnivå hos aktørene i handelsprosessen Grad av forskjell blant varer av samme type [CD’er (masseprodusert) versus bruktbil (ensartet)] Lang Kort Varens holdbarhet Andre akser som kan nevnes er : Et land versus mange land (juridiske domener) Et språk versus flere språk Monopolbedrift? Konsesjonsbelagte varer Noen typer handelsløsninger er letter å lage enn andre. Dette fordi kommunikasjonsbehovet og kompleksiteten i løsningene som skal støtte handelen øker når en beveger seg fra venstre til høyre på aksene. Ved fysisk varelevering ligger selve overleveringen av varen utenfor den teknologiske løsningen, derfor er fysiskvare satt opp som enklere å håndtere enn digital. En digital vare må håndteres integrert med handelsløsningen. Prisdanneles og aktørens aktivitetsnivå henger gjerne sammen. Eksempler på produkter: STRØM (ekstrem ferskvare) BOK Bruktbil Frukt Fysisk “Immateriell” Overleveringsformat for varen Fastpris “Børs” Prisdannelse Slide 8

Endres alt like raskt? Hva er stabilt? Hva endres raskt? Hva er layout? Hva er struktur? Regning fra Sætre kjeks- fabrikk A/S, 9. oktober 1917 Kan en separere deler av kompleksiteten i et IT system og behandle informasjonselementene i en faktura som noe stabilt, mens teknologien som benytter informasjonen viderutvikles? En 80 år gammel regning benytter de samme informasjonselementene finnes som i dagens elektroniske regninger. Det burde være en tankevekker. For 80 år siden hadde vi i Norge en veletablert jus, utveksling av handelsdokumenter står sentralt i denne handelsjus. Like så innen revisjon. Dagens IOS må selvfølgelig ta hensyn til både jus og revisjonsregler. Slide 9

EDIFACT faktura Meldinger må alltid være i overensstemmelse UNA:+,?’ UNB+UNOA:2+NORSK REGNESENTRAL+MOTTAGER+981203:1015+ID_0001' UNH+1+INVOIC:2:911:UN' BGM+380+1998123456' DTM+3:199812030900:102' FTX+TEX+++Fakturahode-tekst' RFF+K1' LIN+1++1:::91' QTY+47:11' MOA+203:100’ UNS+S' MOA+125:100' UNT+13+1' UNZ+1+ID_0001' To nivåer konvolutt og blankett Begin - End strukturer Datamodellen ligger i implementasjonsguiden, og denne utveksles ikke. Ingen layoutstøtte i EDIFACT. Det viktigste med EDIFACT er egentlig ikke syntaks, men kodeverket som benyttes i syntaksen. Feks i BGM+380 så betyr dette faktura, mens samme melding med andre koder kan benyttes til resending endring/tillegg kanselering Disse kodene er innfelt i avtaleverket og mellom partene. Vel så viktig er bruken av generelle internasjonale koder som INCOTERMS dvs. koder som FOB ol. Meldinger må alltid være i overensstemmelse med en implementasjonguide Slide 10

XML Ordre I praksis må meldingen være i overensstemmelse <?xml version="1.0"?> <?xml-stylesheet href="cenorder.xsl" type="text/xsl"?> <!DOCTYPE Order SYSTEM "cenorder.dtd"> <Order> <MessageID>128576</MessageID> <Date>19981203</Date> <RefersTo DocType="ContractNo" DocID="652744" Line="112"/> <Buyer><EAN>5012345678900</EAN></Buyer> <Supplier><EAN>6012345678900</EAN></Supplier> <Item> <ItemID CodeType="BuyersPartNo">8012345678900</ItemID> <Quantity>90</Quantity> <Deliver>19981011</Deliver> </Item> </Order> Meldingen er hentet fra Martin Bryan. Konvolutt nivå evt. som egen tag. Meldingstype ID og kobling til DTD Avsenders blankett ID i message ID Begin End strukturer ------------------------- Datamodellen ligger i DTD’en Layoutstøtte i XSL I praksis må meldingen være i overensstemmelse med en DTD og helst en XSL spesifikasjon Slide 11

Dagens Web handel Basert på HTML Server kontrollert Begrenset funksjonalitet i klient Server kontrollert Ingen juridisk kvittering til kjøper Ingen gode revisjonsspor for kjøper Betaling kreves vanligvis på kjøpstidspunkt ikke leveringstidspunkt Vanskelig å sammenlikne leveringsbetingelser og pris fra flere leverandører Liten konkurranse HTML basert er liten på Business to Business, selv om firmaer som Cisco mm. gjør det bra nettopp i dette segmentet. Slide 12

Ad hoc elektronisk handel Virksomhetsmessig interoperabilitet Forskjellig handelstradisjon? Forskjellige juridiske domener? Hvordan skal utvekslet informasjon tolkes? Hva forventer avsender at mottaker skal gjøre med mottatt informasjon? På hvilket stadium i prosessen blir avtalen om kjøp av et vareparti inngått? Hvordan løses feil og problemhåndtering? Teknologiske interoperabilitet Hva er de teknologiske adressene for virksomheten? Teknologisk funksjonalitet, hvilke tjenester tilbys? Hvilke formater skal benyttes til informasjonsutveksling? Meldingsbasert interaksjon? Metodekall / distribuerte objektsystemer? Hvilke betalingstjenester er aktuelle? Bruk av sikkerhetsmekanismer? Hvordan oppdages og løses tekniske feil og problemer? Tar nå tak i ytterpunktet hvor kjøper og selger vet minimalt om hverandre før handelstransaksjonen starter. Vi tar utrolig mye for gitt når vi går inn i en butikk og plukker en vare med strekkode på, går til kassa og betaler med bank-kort. Slide 13

Elektronisk handel mellom kjente aktører Virksomhetsmessig interoperabilitet er avklart i avtale mellom partene som beskriver Handelstradisjon Juridisk domene Feil og problemhåndtering Fortolkning av utvekslet informasjon Endringshåndtering Teknologisk interoperabilitet Driftsstabilitet Ytterpunktet i andre enden Handel mellom kjente aktører hvor det meste er regulert i avtaler før handelstransaksjonen starter. Slide 14

Elektroniske handels-transaksjoner (kjøp-salg) Volum Business to business XML/EDI EDIFACT HTML Synse slide. XML/EDI kan spise en stor del av det markedet som allerede har tatt i bruk EDIFACT/X12 løsninger. I ”lukkede” markeder/nett gjerne med høyt transaksjonsvolum vil det kunne eksistere EDIFACT i lang tid fremover. Brukere av EDIFACT løsninger trenger en gulerot for å bytte teknologi. Det de store bruker mot andre store går så det griner. Ad hoc elektronisk handel Elektronisk handel mellom kjente aktører Slide 15

EDIFACT versus XML (1) EDIFACT XML Forholdet mellom datamodell og meldingsinstanser Implementasjonsguiden representerer datamodellen DTD representerer datamodellen Meldinger bygges opp av Segmenter som er definert i en segment- katalog Elementer defineret for hvert enkelt case, mulig bruk av repository Hvordan håndteres valgfrihet i forhold til datamodellen Ved å bruke “optional” og mandatory på både segment og attributt nivå Må stort sett kodes på applikasjonsnivå Hvordan håndteres domenekontroller på attributtverdier Delvis i konverter delvis på applikasjonsnivå Må kodes på applikasjonsnivå Endring av meldinger NB! det skjer veldig mye på XML/EDI så denne sliden kan være utdatert rimelig raskt. I praksis gjøres det lokalt mellom kjente partnere Gjøres forhåpentligvis iht. element repositories Støttemekanismer for presentasjon Nei Ja, browsere og via XSL Støtte for integrasjon mot interne systemer Må gjøres manuelt Må gjøres manuelt, potensielt automatiserbart Slide 16

EDIFACT versus XML (2) Handelsløsninger basert på: EDIFACT XML Har tradisjonelt blitt distribuert via disketter Versjonshåndtering av SW er tungvint Teknologien påvirker ikke i seg selv styrkeforholdet mellom partnere XML Vil bli distribuert over Internett Versjonshåndtering enkelt i en browser/WEB-server arkitektur Arkitekturer basert på browser/WEB-server kan påvirke styrkeforholdet mellom partnere EDIFACT opprette kommunikasjonsløsning for dette ene formålet, integrasjonen mot interne systemer er tungt SMB’er må ofte tilpasse seg flere større aktører dermed er det SMB som sitter med et integrasjonsproblem masse ulik programvare XML familien Kan bidra til mer ”likestilling” mellom store og små aktører i markedet. Blir integrasjonen mot interne systemer like tungt? Hvorfor skulle det bli lettere? Slide 17

Integrasjon mot interne systemer basert på EDIFACT EDI-aktør EDI-aktør Internt datasystem Internt datasystem Bruker Bruker Trekker ut og laster inn data Trekker ut og laster inn data Kommunikasjons- tjenester Kommunikasjons- tjenester XML/EDI og EDIFACT kan lide samme skjebne hvis ikke XML/EDI greier å gjøre integrasjon mot interne systemer enklere. Gjennom en grossist flyter det varer fra en virksomhet til en annen. Burde ikke det samme skje med informasjonen? Elektronisk? Hvor og når blir en melding født? Datanett Slide 18

Nødvendige egenskaper ved XML/EDI full bakoverkompatibilitet med EDIFACT/X12 skjemafunksjonalitet, f.eks. manuell input av data innspill til W3C arbeidsgrupper for å dekke EDI behov datafangst: fra skjemaer og databaser mottak av data: integrering i databaser validering: syntaks og verdiområde Tradisjonell EDIFACT løsninger hatt mesteparten av forretningslogikken kodet på applikasjonsnivå. XML kan legge forretningslogikken ut på templates (se foil seinere) og dermed flyttes applikasjonslogikken fra skreddersydd programvare over i komponeter som hentes fra repositories. Må ikke bli avhengig av at alt skal dreie seg om browsere og web-servere. Business to business må ha fleksible løsninger som kan kjøre applikasjon til applikasjon. Slide 19

Fem byggesteiner for XML/EDI Web Foundation XML Processing Logic Templates Implement- ation Methods Agents Fusion Global Reference Dictionary Repository Business Methods EDI XML og Internett tjenester + EDIFACT kodeverk + Templates som består av DTD’er XSL + regler kodet i ?? Agenter som kan interpretere templates Repositories hvor en kan slå opp i”EDIFACT++” koder DTD’er XSL’er architetual forms ++ Slide 20

Integrated architecture Application & Repository Rules Template & Java XML Tags / Agents, XSL XML Parser / DOM XML Content Skisserer rammeverket av teknologier som kan benyttes og som tilsammen ”trolig” kan realisere forrige slides. Interchanged File / Message Storage / Transport Slide 21

Bestilling og betalingsformidling, sammensatt rollemodell Kjøper Repository - Teknologiske adresser - Gule sider - Artikkelnummerregistre - DTD’er - XSL’er - Templates Internett Selger Hvem skal drive repositories? Hvem skal lage templates, DTD’er XSL’er? Generisk artikkelregister? Bør det å bruke en template også kunne føre til at en forplikter seg ihenhold til en gitt type scenario (avtale etablering fra Open-edi tankegang) Bank Slide 22

Norsk XML/EDI pilotprosjekt XML/EDI pilotprosjekt innen KOSTRA: Målet er å utvikle og prøve ut en pilot for enkel og kostnadseffektiv innrapportering fra kommunene til SSB vha. XML/EDI Del av europeisk XML/EDI pilotprosjekt Finansiert bl.a. av Norges forskningsråd Deltakere KITH, NR, SSB, AAD og IBM Norge Slide 23

Reporting chain Municipality All sectors Data capture Query and analyze Electronic form Statistics Norway WWW fact sheets Metadata base Central Central Information systems Local information server Local Social sec. Child care Information systems Accounting Slide 24 24 26

Hovedkilder http://www.nr.no/gem/xml/ Guidelines for using XML for Electronic Data Interchange Extensible Markup Language (XML) 1.0 Martin Bryan, The SGML Centre, http://www.sgml.u-net.com UN/CEFACT/TMWG OO-EDI compability with XML/EDI Open-edi: ISO/IEC JTC1 SC32 WG1, IS 14662 UN-EDIFACT: ISO 9735, ISO / TC 154 The European XML/EDI Pilot Project XML/EDI group: www.xmledi.net http://www.nr.no/gem/xml/ Slide 25