Het uitbreiden van Open Source gereedschappen met functionaliteit voor het definiëren en uitvoeren van berichttransformaties van EDIFACT naar andere standaarden en omgekeerd vereist een goed begrip van de UN/EDIFACT standaard.

Ik zal hierna beknopt de UN/EDIFACT Standaaard proberen uit te leggen. Achtereenvolgens zullen de volgende onderwerpen aan bod komen:
- enkele belangrijke karakters
- de verschillende structuurelementen
- een beschrijving van de structuur
- de positiebepaling, status en herhalende factor van structuurelementen
- de compressieregels

enkele belangrijke karaktertekens
- Segment einde teken = apostrophe ‘

- Segment tag en data element separator = plus sign +

- Component data element separator = colon :

- Release character = question mark ? herstelt de betekenis van het daaropvolgend teken
Voorbeeld: 10?+10=20 betekent 10+10=20

de structuurelementen
De structuur van een EDIFACT bericht is vastomlijnd en bestaat uit een aantal verplichte en optionele elementen. De belangrijkste bouwsteen van een EDIFACT bericht is het segment en de structuur waaraan een bericht moet voldoen is daarom vastgelegd in segment tabellen. Deze tabellen beschrijven welke segmenten in een bericht voorkomen en in welke volgorde.

Een eenvoudig voorbeeld van zo’n segment tabel ziet er als volgt uit:

Segmenten die bij elkaar horen kunnen worden gegroepeerd in een segment groep. Een segment groep bevat altijd een trigger segment en ten minste één of meer segmenten of segment groepen. Het trigger segment is een verplicht segment en moet eenmaal voorkomen. Het trigger segment is bovendien het eerste segment in de groep. Een segment wordt eenduidig geïdentificeerd door een segment tag en de positie in een bericht.

In bovenstaand voorbeeld is het segment met de segment tag RFF een trigger segment voor de segment groep 1 en eveneens voor de segment groep 3.

Een segment is een geordende verzameling van functioneel bij elkaar horende stand-alone of composite data elementen. Het segment BGM, zie voorbeeld hieronder, bestaat uit twee composite data elementen en twee stand-alone data elementen. Een composite data element is een samengesteld data element en bestaat uit een opeenvolging van data elementen.

De Economische Commissie voor Europa van de Verenigde Naties UN/ECE (United Nations Economic Commission for Europe) is midden de jaren ‘80 gestart met de ontwikkeling van de UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce and Transport) standaard voor EDI. In 1988 is de UN/EDIFACT standaard door de Internationale Organisatie voor Standaardisatie (ISO) overgenomen onder de ISO standard ISO 9735.

De UN/EDIFACT standaard is daarna gaandeweg uitgegroeid tot de internationale standaard voor Electronic Data Interchange. Maar met de opkomst van XML standaarden staat EDIFACT al enkele jaren sterk onder druk. Niettemin blijkt dat de UN/EDIFACT standaard wereldwijd nog steeds veelvuldig gebruikt en geïmplementeerd wordt.

De UN/EDIFACT standaard heeft zich naast de syntax vooral gericht op inhoudelijke standaardisatie, de semantiek. Daarin schuilt dan ook de kracht van EDIFACT.

De XML standaarden hebben vooral problemen met functionele standaardisatie. Een universele methodiek voor standaardisatie zoals de Core Components van de UN/CEFACT is nog niet algemeen geaccepteerd en doorgevoerd. Lees hierover meer in mijn bloart Hoe lossen we het interoperabiliteitsvraagstuk op ?. Hierdoor ontstaan verschillende onsamenhangende en incompatibele alsook gefragmenteerde standaarden.

De benadering die gevolgd wordt door ontwikkelaars van XML standaarden is scheiding van functionaliteit en techniek. De voorbije jaren heeft vooral de techniek van XML volop aandacht gekregen en de hoeveelheid Open Source gereedschappen voor het werken met XML is gigantisch toegenomen. Open Source transformatiegereedschappen waaronder XAware en Chainbuilder bieden helaas geen ondersteuning voor de UN/EDIFACT standaard of daarvan afgeleide standaarden. De aandacht voor de techniek van XML is de voornaamste reden hiervoor.

De noodzaak naar ondersteuning van de UN/EDIFACT standaard zal echter de komende jaren blijven bestaan. Vrij regelmatig wordt ik dan ook gevraagd wanneer deze functionaliteit beschikbaar komt. Open Source transformatiegereedschappen die hierin voorzien gaan sneller geadopteerd worden. Tevens zal de noodzaak naar commerciële EDIFACT vertaalsoftware dan verdwijnen.

Mogelijk zullen de aanbieders van deze commerciële transformatiesoftware overwegen, waarschijnlijk gebeurt dat nu al, om hun producten onder een Open Source licentie beschikbaar te stellen. Zo zouden bedrijven als Sun Microsystems en IBM een flink aandeel op dit domeingebied in de Open Source markt kunnen veroveren wanneer zij hun transformatiegereedschappen voor JCAPS (Sun) en voor WebSphere (IBM) zouden vrijgeven. De eerste stappen in die richting worden gezet. Sun Microsystems, de grote sponsor achter het Open Source project OpenESB, geeft aan in de toekomst componenten van OpenESB op te nemen in Java CAPS. Met de start van het Open Source project Fuji wordt een begin gemaakt met het ontwikkelen van Sun’s next generation open source integration runtime.

XAware en Chainbuilder zouden weleens het standaard transformatiegereedschap voor OpenESB kunnen worden. Ik heb me zelf opgeworpen om binnen de XAware community de kar te trekken voor de realisatie van EDIFACT transformatiefuncties en misschien is het mogelijk om gelijktijdig de oplossing voor Chainbuilder te realiseren.