Mikä ihmeen Edifact?
EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) on vastaavanlainen dataformaatti kuin esimerkiksi paremmin tunnetut XML ja JSON erilaisten sanomien lähettämiseen. EDIFACT kehitettiin 80-luvun lopulla YK:n toiveesta, jotta saataisiin kansainvälinen standardoitu formaatti kaupankäyntiin. EDIFACT:in lisäksi on myös muita EDI-formaatteja (Electronic Data Interchange) kuten X12, GS1 ja HL7, joilla on omat käyttötarkoituksensa ja markkinat.
Alkuun EDIFACT:ia oli kolmen tyyppisiä sanomia: ORDER (tilaus), INVOIC (lasku) sekä DESADV (lähetysluettelo). Nykyään EDIFACT sanomatyyppejä on noin 200 erilaista. Kaikilla näillä on eri versioita erilaisiin tarpeisiin, esimerkiksi IFTMIN sanoma voi olla mm. D.96A ja D.03B tyyppisiä.
EDIFACT ei ole samalla tavalla luettavaa kuin esimerkiksi XML ja json. EDIFACT on kehitetty mahdollisimman tiiviiksi tilan säästämiseksi ja prosessien yksinkertaistamiseksi. EDIFACT:issa muuttujien nimet on ennalta määritettyjä, joiden käyttötarkoitus selviää sen perässä olevasta koodista, esimerkiksi QTY+1. EDIFACT jakautuu karkeasti kolmeen osioon: header, message sekä trailer. Header osiossa on tietoa lähettäjästä ja vastaanottajasta, kun taas trailer osiossa on tietoa sanomasta. Message osiossa on varsinainen sisältö esimerkiksi tilauksesta ja tämä jakautuu elementteihin sekä segmentteihin, joiden alla voi olla elementtejä tai elementtejä sisältäviä segmenttejä. Segmenttien alle kuuluvat elementit ei suoraan ilmene datasta, mutta segmenttiin kuuluvat elementit voi tarkistaa kyseisen EDIFACT:in syntaksista. Esimerkiksi BGM ja DTM kuuluvat esimerkissä samaan segmenttiin.
Kuka käyttää EDIFACT:ia ja miksi?
EDIFACT on käytössä erityisesti kaupan- ja logistiikan aloilla, joissa liikkuu paljon tavaraa, laskuja ja lähetyksiä. Yleisimmin käytettyjä sanomia ovat esimerkiksi aiemmin mainitut ORDER tilaustietojen lähettämisen sekä INVOIC laskutustietoihin, mutta suosittuja ovat myös esimerkiksi DELJIT ja DELFOR, joilla asiakkaat voivat lähettää lyhyt- tai pitkäaikaisia ennusteita toimittajalle. EDIFACT:in vahvuus onkin suuri määrä erilaisia standardeja useisiin eri tarpeisiin. Myös EDIFACT:in rakenne on yksi sen eduista. XML:n tai JSON:in kaltaisten sanomien luettavuus on yksinkertaisempaa, myös jos ne eivät ole ennestään tuttuja, mutta niiden tiedostokoko on tästä syystä korkeampi. EDIFACT sanomat ovat verrattaen lyhyitä ja tiiviitä ja sanomien tiedostokoko saattaa olla useita kertoja pienempi. EDIFACT:ia ei myöskään varsinaisesti ole kehitetty ihmisen luettavaksi suoraan, vaan välisanomana erilaisten järjestelmien välillä, tästä lyhenne EDI, Electronic Data Interchange eli sähköinen tiedonvaihto, tuleekin.
Erot muihin formaatteihin
Kun vertaa muihin yleisimpiin formaatteihin, kuten JSON ja XML, EDIFACT:in
ulkonäkö kiinnittää ensimmäisenä huomiota. EDIFACT on muotoiltu tiiviisti
segmentteihin käyttäen formaatin nimeämiskäytännön mukaisia kenttiä kuten FTX
(free text), DTM (aika) ja QTY (määrä). Formaatissa myös määritellään kentän tyyppi
koodilla, esimerkiksi DTM+137 vastaava XML:ssä olisi <DocumentDate> ja DTM+36
on <ExpiryDate>.
Rakenteen lisäksi eroa on myös mahdollisissa tiedonvälitystavoissa. EDIFACT:ia voi lähettää enimmäkseen perinteisillä tiedonsiirto menetelmillä kuten SFTP, AS2 ja HTTP, kun taas XML ja json mahdollistavat esimerkiksi REST-rajapintojen käytön Jos taas verrataan muihin EDI-formaatteihin kuten X12, on erot loppujen lopuksi pienet ja formaatin valinta riippuu pitkälti, minkä muiden toimijoiden kanssa tehdään yhteistyötä. Esimerkiksi X12 on hyvin samankaltainen formaatti kuin EDIFACT varsinkin rakenteeltaan suurimpien erojen ollessa lähinnä termeissä ja lyhenteissä, mutta sitä käytetään pääasiassa Pohjois-Amerikan markkinoilla, kun taas EDIFACT on enimmäkseen Euroopassa ja Aasiassa käytetty formaatti.
EDIFACT Boomissa
Monet järjestelmät pystyvät lukemaan EDIFACT:ia natiivisti, esimerkkinä tilanne, jossa asiakas lähettää ORDER EDIFACT:in ja sen voi syöttää sellaisenaan tilausjärjestelmään. Mutta entä jos tilausjärjestelmä ei lue EDIFACT:ia, vaan esimerkiksi jsonia, tai se hakee tietonsa tietokannasta, johon EDIFACT:ista saatavat tiedot on ensin luettava? Tai jos asiakas lähettää XML-muotoisen tilauslomakkeen, mutta oma järjestelmä lukee EDIFACT:ia.
EDI-tyyppisten sanomiin transformaatioiden tekeminen ei ole yksinkertaisimmasta päästä, ja vaativuus riippuu pitkälti integraatioalustan kyvykkyyksistä. Esimerkiksi Mulesoft osaa muuttaa EDIFACT:in luettavampaan muotoon EDI-connectorin avulla. Mutta useimmissa muissa alustoissa tällaista toiminnallisuutta ei välttämättä ole, vaan rakenteen joutuu kirjoittamaan integraatioon alusta asti, tai etsiä muiden kehittäjien tekemiä malleja.
3 Boomi Trading Partner näkymän kommunikaatio metodit, joita voi olla samalla trading partnerilla useita
Boomi on ratkaissut EDI-kysymyksen Trading partnereilla. Trading partnereilla tehdään määritys omalle yritykselle sekä kumppaneille. Trading partnerille määritellään formaatti, jota käytetään, esimerkiksi EDIFACT, X12 tai HL7 sekä eri tiedonsiirtoprotokollia kuten SFTP, HTTP ja Disk. Tämä jälkeen käytössä on EDI- tiedostojen transformaatiota varten kaikki tarvittavat sanomatyyppien profiilit versioita myöden, esimerkiksi ORDER sanoma D.96A versiolla.
Trading partnerien lisenssit toimivat hieman eri tavalla muista boomin lisensseistä. Normaalisti lisenssit ovat jokaisesta ympäristöihin asennetusta connectionista, mutta tässä tapauksessa ne ovat Trading partner kohtaisia. Trading partnereille voi määritellä useita eri tiedonsiirtoprotokollia ja koska ne laskutetaan connection lisenssin sijaan Trading partner lisenssiltä, on mahdollista saada myös kuluja alas, varsinkin jos asiakas jakaa EDI-tiedostoja useammalla eri tavalla.
4 Boomi B2B/EDI Dashboard EDIFACT-sanomien selkeämpään lukuun
Boomi tarjoa myös B2B/EDI Dashboardin Trading partnereille. Dashboardilta pystyy lukemaan EDI-tiedostoja ihmisymmärrettävämmässä muodossa ja esimerkiksi hakea yksittäiseen tilaukseen liittyviä sanoma, jotka ovat kulkeneet Boomin läpi.
