Hvorfor er EDI, der stadig bruges, og hvordan man skal håndtere det?

Hvorfor er denne arkaiske formatet stadig anvendes i lyset af lettere at bruge teknologi? Gør det give nogle fordele, som jeg ikke ser? Det ser ud til, at en stor mængde af leverandører stadig levere data kun i dette format, i stedet for noget mere overskueligt og lettere at bruge f.eks XML; i det mindste det ville give mening for mig at tilbyde begge formater.

Også, hvad er nogle gode måder at håndtere og udnytte EDI, når du ikke har andet valg, men at bruge det? Noget lignende BizTalk er ude af spørgsmål som det er alt for dyrt. Er der nogen fri/open source-programmer, der gør EDI nemmere at arbejde med?

Subjektive og Argumenterende: Se ‘kryptisk’, ‘nul mening for mig’, andre systemer, der er mere effektiv’, ‘hovedpine til at parse’, ‘gammeldags’ ‘lettere at bruge ‘læse kinesisk’.
Ja, han er ved at blive subjektiv, men der er et spørgsmål, skjult inde rant: Hvad er fordele og ulemper ved EDI-format?
EDI står for Electronic Data Interchange, ikke Humane Data Interchange. Det er ikke beregnet til at være læsbar. Dens kompakte og veldefineret. Jeg har konverteret 7MB EDI-fil til XML, og de endte med at blive 45MB+. Konvertering størrelse er ikke lineær. Større EDI-filer kan få enorme.
Samme kunne opnås for XML med nogle standard komprimering algoritme, som ingen har brug for at se.
samme grund, hvorfor vi bruger QWERTY tastaturer

OriginalForfatteren Wayne Molina | 2009-02-05

18 svar

  1. 17

    EDI er ikke så svært at forstå, når du gør dig fortrolig med den almindelige it-bruger. Du kan spørge dig selv, samt hvorfor nogen ville stadig være ved hjælp af CSV-eller tabulatorsepareret data.

    Svaret er formentlig, at disse formater er “domain specific languages”, der er defineret af udvalg og standardiseret i en bestemt branche, og at en masse penge, er der blevet investeret i at støtte disse formater. Hvor er business case til at smide det hele ud igen?

    Jeg har fundet, at EDI er let nok at læse i. Den vanskelige del er at skrive EDI dokumenter, som andre systemer ikke klage over. Det ser ud til, at selv hvis du er følgende specs, de stadig klager.
    I virkeligheden, jeg har oprettet en DSL til kort EDI transaktioner sæt (begge veje). Det var næsten for trivielt.
    Lyder som udvikling af web sites til Internet Explorer!

    OriginalForfatteren Dave Van den Eynde

  2. 16

    Et ord, Inerti. Udvikling af EDI formater af udvalget mellem forskellige virksomheder og organisationer med forskellige dagsordener var et mareridt (ked af at sige, at jeg har været der).

    Beder dem om at opgive disse med endnu en runde af udvalg, accepterer web service API-standarder kommer til at tage endnu længere tid, hvordan vil du sælge ideen om at erstatte en elektronisk format med en anden til en ikke-teknisk bord? Hvilke mulige busness fordel ikke give dem. Oprindeligt fordelene ved elektronisk udveksling var klar, men erstatte det ene med det andet er ikke. Vi taler virkelig store virksomheder her.

    Præcis. Leverandører, der ikke er software udvikling virksomheder. De ikke kan se værdien i at skifte til nye systemer. De har ikke den interne ekspertise til at gøre noget, og at ansætte nogen, der ville være ekstremt dyrt.
    Udover, at det virker.
    ikke rigtig “inerti”; det er på grund af det “net-effekt” en.wikipedia.org/wiki/Network_effect

    OriginalForfatteren AnthonyWJones

  3. 6

    Fordi det er et formelt etableret Standard (i øvrigt et meget stort og omfattende sæt af standarder). Og det er en af de påståede fordele af et standard – du behøver ikke at ændre noget i lang tid.

    Og til at ændre på det, tager det en aftale mellem to eller flere (ofte tusinder og atter tusinder mere) handelspartnere (herunder måske alle dine konkurrenter) at blive enige.

    EDI formater, der er langt højere signal-til-støj-forhold (fordi de var designet tilbage, når der blev anset for vigtigt.) Nogen, der kender og forstår EDI vil se på din XML og sige, “Hvor er oksekød (data)?”

    Meget få udviklere med at skrive deres egne parsere. Der er mange gode mappers til rådighed (og mange ældre og enterprise apps kommer med dem er bygget i). Så der er masser af nødhjælp til rådighed for din smerte (herunder mindst en Open Source app på SourceForge).

    OriginalForfatteren dkretz

  4. 5

    “If it ain’ t broke, don ‘ t fix it.”

    De fleste af disse organisationer, der behandler store mængder af data ved hjælp af EDI, og ikke om at skifte til noget mere moderne uden tvingende grund. Og at gøre det nemt for tredje-parts udviklere normalt ikke kvalificere sig, trist at sige.

    OriginalForfatteren Mike Edwards

  5. 5

    Lidt information til alle interesserede. EDI er dybest set et design af udvalget data exchange format, der ikke kun fastsat regler for data formatering (som XML), men også sat sig for at definere hvert enkelt dokument, der eventuelt kunne nogensinde sendes mellem 2 selskaber. Så for et stykke data, som kan udveksles mellem virksomheder, de kom op med en præcis definition af, hvad der skulle være i hver af disse dokumenter. Selvfølgelig, ingen kunne forudse hvert et stykke data, som 2 virksomheder, der ønsker at udveksle. Så du ender med virksomheder, der bruger felter, der er defineret for 1 ting, bliver brugt til anden oplysning.

    Hvad du endte op med, er en yderst indviklet data format, hvor mange mennesker, der bruger det ikke følger de standarder, fordi de er nødt til at sende brugerdefinerede oplysninger, som standard tager ikke højde for. Så i sidste ende, du stadig nødt til at tale med hver virksomhed, du ønsker at beskæftige sig med, og find ud af alle de små idiosynkrasier af deres gennemførelse, ligesom du ville gøre, hvis du gik til en person med en brugerdefineret XML-interface. Bortset fra at i tilfælde af EDI-format er svært at forstå og endnu sværere at skrive godt, så du ender med at gøre en hel masse af det arbejde, bare for at sende et dokument, når du laver den samme slags mener med at have en brugerdefineret XML-løsning ville have resulteret i, at mange gange mindre problemer.

    Men så får du handelspartnere, der udvider XML formater til de samme oplysninger og samme formål i vildt forskellige måder, så de samme konsekvenser. Vi alle gerne vores egne hammer bedre end de andre, men de kører alle de søm i, semi-skæve tider.
    Hele min pointe er, at du ikke kan prøve at standardisere de dokumenter, der sendes på tværs af hele branchen. I stedet, ville alle bare være bedre, hvis de lige har brugt XML, og defineret deres egen DTD for andre til at holde sig til, i stedet for at forsøge at få alle til at enes om en enkelt DTD, eller data format.
    Bare fordi 100% af beskeden udveksling af krav, der ikke kan standardiseres er ikke en grund til at stemme for en gratis for alle.

    OriginalForfatteren Kibbee

  6. 5

    Og skifter til XML ville give dig, hvad – en lidt nemmere at fejlsøge linje-format?

    Generelt har du sat det op og lader det, der er ikke en masse nødt til at spille med den rå EDI-feed, i hvert fald ikke nok til at opgive den standard og start igen.

    Der er masser af standarder, som FAX, der kunne være gjort mere læsevenlig, men ingen reel presserende behov for at ændre dem.

    Har du nogensinde gennemgang af en EDI-format, selv noget simpelt som en EDIFACT ordre? Hvilke værktøjer er der til nemt at forbruge det og give det? Der kan være nogle, men vi taler med flere cifre af valuta til at få, hvad XML giver gratis.
    +1 AnthonyWJones. Præcis mit problem med EDI – det er latterligt svært at parse der henviser til, at XML er nemt at indtage og udvide.
    Det er ikke et spørgsmål om lidt nemmere. EDI er størrelsesordener sværere at gøre korrekt end XML.
    Jeg gennemgår dem ofte (eller bruges til at, nu er det filtreret gennem for det meste). Jeg har meget sværere ved at finde de data, der er indlejret i XML cruft. Med EDI-jeg kan indsætte et linjeskift til det segment, pauser og ting, mere eller mindre lodret linje op i en skærm-bredde. Det er, hvad du er vant til.

    OriginalForfatteren Martin Beckett

  7. 5

    IMHO der er flere problemer med EDIFACT.

    1. Det er ikke let at fortolke, eller generere en Objekt model fra det. Dette er formentlig ikke et stort problem længere, da der er nu godt system omkring at gøre det for dig fx smooks.org
    2. Det er ikke let at læse. Du vænne sig til, men XML er meget lettere at læse
    3. Validering er ikke så let (sammenlign det med at validere XML -)
    4. Der er alt for mange forskellige versioner og varianter, D95B, D96B, D00A, D00B osv.
    5. Men jeg tror det største problem er, at alle bruger de standarder forskelligt. De bruger den samme “format”, men de felter, der er defineret forskelligt. Vi bruger EDIFACT til at sende og modtage beskeder fra Container Terminaler, og de har alle små forskelle. De ville fx alle bruge en D95B CODECO, men for nogle terminaler et bestemt segment, er obligatorisk, mens det for en anden er det valgfrit, eller endda ikke lov til at være der. Så har du segmenter, der er anvendt den samme, men indholdet i det, der er anderledes.

    Så for at opsummere det: Det er en smerte i nakken.

    OriginalForfatteren Ben

  8. 4

    EDI er en meget kompakt format og er ofte bruges til at holde båndbredde i data-udveksling så lille som muligt. Den tyske told kontorer for eksempel bruge det i deres ATLAS system til udveksling af en meget høj mængde data hver dag.

    Det er svært at forstå og svært at læse, men hvis størrelsen på de data, der fremkommer sager, kan det være et godt valg, og er understøttet af de fleste af de større business-applikationer.

    Mod dette punkt en masse værditilvækst netværk (Varevogne) stadig opkræve kilocharacter priser. Jo flere tegn, jo mere det koster.

    OriginalForfatteren Sebastian Dietz

  9. 3

    Legacy Support

    To ord svar er ikke godt på dette site.

    OriginalForfatteren GWLlosa

  10. 3

    EDI er produktiv i mange brancher. Det ville være uoverkommeligt dyrt at erstatte en allerede-teknologi arbejder med et nyere.

    Overveje dette, Walmart bruger EDI til at kommunikere med sine leverandører, butikker, distribution, kæde, osv. Jeg gætter på at de beskæftiger sig med tenss af tusindvis af leverandører. Hver og en af dem er sunket tusindvis af dollars i EDI-teknologi. Hvis Walmart besluttet at skifte over til XML, det er en beslutning, der påvirker tusindvis af virksomheder, ikke bare Walmart.

    Dette er sandt for ethvert EDI bruger. Efter alle, det er en standard, der bruges mellem handelspartnere.

    Jeg er enig i, EDI er en smerte at arbejde med. Men “tilbage i dag”, det er alt, hvad vi havde.

    Sig til at anbefale noget for at lindre smerten, der beskæftiger sig med det, så? Min frustration er fordi mit firma skiftede leverandører og denne nye alene data i EDI-format (den gamle tilbudt det i teksten, som godt), så jeg har travlt med at finde ud af en måde at integrere det med vores systemer
    Jeg kan blive mangler noget, men kan du ikke bruge XSLT til at transformere XML-i EDI? XML->XSLT->EDI synes meget lettere end EDI->CustomeParser->XML… igen, jeg kan være over en forenkling.
    Jeg bruger ikke XML; jeg har bare brug for at udtrække data – jeg havde håbet at den leverandør, der var ved hjælp af XML og ikke EDI da XML er lettere at analysere de data, jeg har brug for.
    der er et par firmaer, som tilbyder EDI mapping-software, der vil oversætte EDI dokumenter i bruger-definerede formater. Vi plejede at bruge Sterling Commerce ‘ s produkt, men helt ærligt, det var en kærlighed/had forhold.

    OriginalForfatteren Marc Bernier

  11. 3

    Edifact er en af de bedste standarder, når det kommer ned til dokumentudveksling.
    De fleste problemer kommer fra tradingpartners at sende ikke standardiserede dokumenter.

    Ja, det er lidt mærkeligt format, og er kedelig at arbejde med, hvis du ikke kender ins og outs, men der går for XML som godt.

    Du virkelig ønsker XML over Edifact? Se oppustet, svært at læse XML-standarder peppol (pan-european public procurement online), der er arbejder på.

    Ja det virker godt og dandy, hvis du ikke har nogen fejl i systemer, fejlfinding edifacts er så meget lettere, når du vænne sig til det format, end fejlfinding UBL dokumenter.

    Du siger du har $0.00 at bruge på projektet?
    Du bør virkelig se ind i mængden af manuelt arbejde, der udføres i din virksomhed og costsavings EDI kan tilbyde nogle cost-benefit analyse kan være vældig praktisk.

    Har et kig på edidev, stylusstudio eller samarbejde Samarbejde er et gratis program, EDI Notesblok, som er ganske praktisk, hvis du er bekendt med edifact-Der er også helt et par java-parsere derude, hvis det er må være opensource Enige om, at BizTalk er en smule prizy men så skal det store ERP-systemer, se på prisen i den forbindelse 🙂

    OriginalForfatteren plykkegaard

  12. 3

    Hvilke typer af oplysninger der kan udveksles via EDI?

    En række forskellige typer af business udveksling af oplysninger er tilgængelige via EDI, herunder:

    -•Booking oplysninger

    -•Bill of Lading oplysninger

    -•Fakturering

    -•Elektronisk Overførsel Af Midler

    -•Ankomst Varsel Oplysninger

    -•Forsendelsesstatus Oplysninger

    Hvordan ville du vælger EDI gavn for min virksomhed?
    -•Det strømliner kommunikation mellem dig og APL

    -•Det eliminerer behovet for at genindtaste data, således at eliminere fejl og behovet for at recheck oplysninger

    -•Det eliminerer håndtering af papir og behovet for dokument opbevaring

    -•Det forbedrer turntime og nøjagtigheden af dine data

    -•Det eliminerer behovet for faxe

    OriginalForfatteren kaushik0033

  13. 2

    En løsning, selv om det vil koste dig, er at gå til en virksomhed som ADX, som har værktøjer, du kan bruge til at konvertere EDI formater til mere tiltalende formater som CSV. Afhængigt af mængden og typen af transaktioner, du laver, dette kan være både billig og meget mindre stressende. Jeg har brugt deres produkter i fortiden, og mens de er en smule arbejde at sætte op, de gør arbejdet godt citat, og er meget stabil. På grund af den historie EDI, kan du sikkert finde hundredvis af andre virksomheder, der tilbyder lignende tjenester.

    Desværre, mit budget er $0,00. Jeg vil holde det i tankerne, selv om, hvis jeg er nødt til at bruge det.
    Er de betaler dig $0.00 til at gøre arbejdet? Fordi, hvis de ikke er det, du virkelig bør argumentere for, at det kunne være afsluttet med langt mindre samlede omkostninger til bare at betale en anden for en løsning.

    OriginalForfatteren Kibbee

  14. 1

    EDI, har eksisteret siden før XML. Bortset fra det faktum, at to parter kan forud forhandle EDI-format, der virker for dem begge, skal du også overveje den del af VAN (value added network.)

    I nogle tilfælde VAN udfører valideringen af beskeden, eller selv læser den besked og udfører handlinger, for eksempel at kopiere det til yderligere parter, der er baseret på dens indhold.

    Den eneste grund til virkelig at bruge EDI er, fordi “det er den måde, det altid er blevet gjort”, og der er derfor en masse af de eksisterende infrastruktur rundt for at støtte det. Hvorfor skifte til XML, når der ikke er brug for? Og hvordan er at sige, XML plejer at blive erstattet af JSON, som derefter vil blive erstattet af noget andet?

    JSON er for data, XML dokumenter. Der er en vigtig forskel.
    Forklar venligst, hvad du mener.

    OriginalForfatteren Peter Morris

  15. 1

    En anden grund er, at der business-beskeder, såsom orden. fakturaer, kreditnotaer osv der er en masse af finansielle værd i transaktionerne, og de har brug for at være sikker, men måske mere vigtigt, de skal have ende til validering og verifikation såvel som ikke-afvisning.

    For eksempel har jeg sende dig en ordre til 1/2 millioner Euro værd af varer, du sender mig varerne, så jeg “miste” for oplysninger og fortælle dig, at jeg ikke betale. Kombinationen af standarder og VAREVOGNE gøre det næsten umuligt eller i det mindste så meget af en audit trail, at det er de problemer, der kunne spores. Dette er grunden til, at de “Åh lad brug af xml-og internet i stedet for EDIFACT-og VAREBILER” er der tendens til at mislykkes. Som en person, els besvaret, Inerti, men det er en inerti, som er grundlagt i en stabil, effektiv, sikker, pålidelig og velkendt system.

    Gør det på den billige er ikke altid en mulighed.

    Hvis det er nogen trøst, når jeg først gennemførte EDI i ’87 var der stort set ingen software rundt, og så fik jeg Interbridge borde og skrev min egen parser for den BRITISKE TRADACOMS standard bruger Cognos-software på og HP Mini, og det fungerede fint. Forudsat, at du handler med andre EDI partnere omkostningerne sandsynligvis kommer til det punkt, at skulle bruge en VAREVOGN.

    OriginalForfatteren PurplePilot

  16. 1

    Jeg har anvendt EDI (ANSI-X12 og EDIFACT) i 2 projekter om Maritime Transport, Logistik og fundet dem til at være meget nyttige, da de fleste Ocean Luftfartsselskaber og Handelspartnere acceptere dem som standard måde at kommunikation mellem de forskellige systemer.

    Så EDI-format bruges stadig og vil fortsætte med at blive brugt da det er en startede standard og tusinde virksomheder, som har udviklet systemer omkring dem, og erstatter dem er en virkelig big deal.

    OriginalForfatteren Nathan

  17. 0

    Jeg har haft med at anvende EDI så godt, og jeg er enig. Vi brugte BizTalk til at kortlægge det, som fungerede godt. Mange system er bygget på EDI(længe før XML).

    Måske ville jeg ikke have det problem, at hvis jeg blev ved hjælp af BizTalk… men desværre er prisen for det er waaaay for meget til selv gider at overveje som en løsning.

    OriginalForfatteren Matt Davison

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *