← Cikkek · EDIFACT és XML

EDIFACT és XML 1. rész: Architektúra, szintaxis és a kanonikus XML adatmodell

Négyrészes sorozatunk első részében az EDIFACT bájtfolyam és a hierarchikus XML adatmodell közötti strukturális különbségeket, a kódolási kihívásokat és a kanonikus konverziós pipeline-t tárgyaljuk.

A globális B2B kereskedelem és ellátási láncok digitális gerincét évtizedek óta az UN/EDIFACT (United Nations / Electronic Data Interchange for Administration, Commerce and Transport) szabvány alkotja. A modern felhős ERP rendszerek, webes API-k, és e-beszerzési platformok (pl. SAP Ariba, Coupa, Peppol) világában azonban az adatfeldolgozás elsődleges belső nyelve az XML (Extensible Markup Language) lett. Négyrészes sorozatunkban részletesen bemutatjuk, hogyan működik az EDIFACT → XML konverzió elmélete és gyakorlata: az alapvető szintaktikai faépítéstől a rendelési (ORDERS), szállítási (DESADV) és számlázási (INVOIC) üzenetek precíz leképezéséig.

Az első rész a fundamentumokat fekteti le: hogyan alakítunk át egy lapos, szegmens- és elválasztóalapú EDIFACT állományt önleíró, hierarchikus XML dokumentummá, milyen szintaktikai csapdákat kell kikerülnünk, és hogyan tervezzünk szabványos kanonikus XML modellt.

Strukturális különbségek: Lapos szegmensek vs. Hierarchikus XML fák

Az EDIFACT és az XML filozófiája alapvetően eltér egymástól. Míg az EDIFACT-et az 1980-as évek szűk sávszélességű hálózataira optimalizálták (minimális bájtméret, pozicionális és elválasztókarakteres tömörítés), addig az XML önleíró, címkékkel ellátott faszerkezet (DOM):

Szempont UN/EDIFACT (pl. D96A) Kanonikus XML (XML Schema)
Adatreprezentáció Lapos szövegfolyam szegmensekkel (BGM, DTM) és adattagoló karakterekkel (+, :, '). Egymásba ágyazott fastruktúra szülő-gyermek (Parent-Child) kapcsolatokkal.
Mezőazonosítás Pozíció és minősítőkód (Qualifier) alapján (pl. DTM+137:20261021:102'). Önleíró XML címkék (pl. <IssueDate format="102">2026-10-21</IssueDate>).
Hierarchia kifejezése Logikai szegmenscsoportok (Segment Groups / Loops), amiket trigger-szegmensek nyitnak meg. Természetes egymásba ágyazás (Nested elements).
Sémavalidáció Szintaktikai EDIFACT könyvtárak (UNSM Directories) és formátumleíró táblák. W3C XML Schema Definition (XSD) szigorú adattípusokkal (dátum, tizedes szám).

A parszing folyamat: Az UNA karakterektől az AST fáig

Az EDIFACT → XML konverterek (pl. Altova MapForce, Apache Camel Bindy, Smooks vagy egyedi konverziós motorok) első feladata a nyers szöveg szintaktikai feldolgozása. Ez a folyamat három fázisból áll:

  1. Elválasztók felismerése (UNA szegmens): Ha az EDIFACT fájl elején jelen van az opcionális UNA:+.? ' szervizkarakterlánc, a parser ebből olvassa ki az elválasztókat:
    • Komponens elem elválasztó (alapértelmezett: kettőspont :)
    • Adatelem elválasztó (alapértelmezett: pluszjel +)
    • Tizedespont jel (alapértelmezett: pont .)
    • Feloldó / escape karakter (alapértelmezett: kérdőjel ?)
    • Szegmens lezáró (alapértelmezett: aposztróf ')
  2. Escape karakterek feloldása: Ha egy mező értéke magát az elválasztót tartalmazza (pl. cégnév: "Schmidt?+Co"), a konverternek fel kell ismernie a ?+ escape szekvenciát, és az XML-ben tiszta karakterként kell elhelyeznie (&amp; vagy nyers szöveg formájában).
  3. Szegmenscsoportok (Loop) detektálása: Az EDIFACT nem zárja le külön taggel a csoportokat. Egy LIN (tételsor) szegmenscsoport végét kizárólag a következő LIN vagy egy összegző szegmens (pl. UNS+S') felbukkanása jelzi. A parsernek állapotgéppel (State Machine) kell követnie a szinteket.

Kanonikus XML modell (Generic vs. Semantic XML)

Az EDIFACT-ből kétféle megközelítésben képezhetünk XML állományt:

1. Generikus EDIFACT-XML (Low-level AST)

Ez a forma egy az egyben leképezi a szegmenseket és kompozit elemeket anélkül, hogy megértené az üzleti jelentésüket. Hasznos közvetítő köztes formátumként:

<?xml version="1.0" encoding="UTF-8"?>
<Interchange xmlns="http://edifact.hu/schema/canonical/d96a">
    <UNB>
        <S001><e0001>UNOC</e0001><e0002>3</e0002></S001>
        <S002><e0004>5991234567890</e0004><e0007>14</e0007></S002>
        <S003><e0010>5999876543210</e0010><e0007>14</e0007></S003>
        <S004><e0017>261021</e0017><e0019>1030</e0019></S004>
        <e0020>000842</e0020>
    </UNB>
    <Message>
        <UNH>
            <e0062>1</e0062>
            <S009><e0065>ORDERS</e0065><e0052>D</e0052><e0054>96A</e0054><e0051>UN</e0051></S009>
        </UNH>
        <BGM>
            <C002><e1001>220</e1001></C002>
            <e1004>PO-2026-9912</e1004>
            <e1225>9</e1225>
        </BGM>
    </Message>
</Interchange>

2. Szemantikus Kanonikus XML (Business Canonical XML)

Az éles vállalati integrációkban a generikus fát azonnal egy üzleti szemantikai XML-re alakítjuk át, ahol a minősítőkódok helyett valódi mezőnevek szerepelnek:

<?xml version="1.0" encoding="UTF-8"?>
<PurchaseOrder xmlns="http://edifact.hu/schema/b2b/order/v1">
    <OrderHeader>
        <OrderNumber>PO-2026-9912</OrderNumber>
        <OrderDate>2026-10-21</OrderDate>
        <MessageType>ORDERS_D96A</MessageType>
        <Buyer>
            <GLN>5991234567890</GLN>
            <Name>Pannon Kereskedelmi Zrt.</Name>
        </Buyer>
        <Supplier>
            <GLN>5999876543210</GLN>
            <Name>Alkatrész Gyártó Kft.</Name>
        </Supplier>
    </OrderHeader>
</PurchaseOrder>

Gyakori szintaktikai buktatók az EDIFACT → XML átalakításkor

  • Speciális XML karakterek feloldásának elmaradása: Ha az EDIFACT partner nevében & (pl. AT&T) vagy < karakter szerepel, és a konverter ezt nem alakítja &amp;-ra vagy nem zárja <![CDATA[ ... ]]> blokkba, az eredményül kapott XML szintaktikailag érvénytelen lesz (Well-formedness error).
  • Dátumformátumok (DTM formátumkódok): Az EDIFACT DTM+137:20261021:102' a 102-es kóddal jelzi az ÉÉÉÉHHNN formátumot, míg a 203 az ÉÉÉÉHHNNÓÓPP perc pontosságot jelenti. Az XML szabvány (ISO 8601) szigorúan megköveteli a kötőjeles formátumot (2026-10-21 vagy 2026-10-21T10:30:00). Ezt a transzformációnak muszáj normalizálnia.
  • Hiányzó szegmenslezáró aposztróf: Sérült EDIFACT átvitel esetén, ha egy szegmens végéről lemarad az ', a naiv parserek az egész következő szegmenst az előző mező tartalmának értelmezik, szétzilálva a teljes XML hierarchiát.
  • Szegmensismétlődések és sorrendfüggőség: Az EDIFACT szigorú sorrendet követel meg (pl. BGM után kötelező a DTM). Az XML Schema (XSD) <xs:sequence> szabálya elbukik, ha a konverter felcseréli a generált tagek sorrendjét.

A sorozat felépítése

Négyrészes sorozatunk további részeiben az EDIFACT legfontosabb üzeneteinek XML transzformációját vizsgáljuk meg:

  • 2. rész: Megrendelések: EDIFACT ORDERS átfordítása SAP Ariba cXML és Peppol BIS Order 3.0 UBL formátumra.
  • 3. rész: Logisztika és kiszállítás: A komplex DESADV szállítási értesítő (CPS csomagolási fa, SSCC kódok) leképezése UBL Despatch Advice és WMS XML állományokra.
  • 4. rész: Pénzügy és számlázás: Az EDIFACT INVOIC kereskedelmi számla transzformációja Peppol Billing 3.0 és magyar NAV Online Számla 3.0 XML-re.

Szeretné meglévő EDIFACT forgalmát modern felhős XML vagy API rendszerekkel összekötni? Tesztelje üzeneteit validátorunkban, vagy kérjen szakértői támogatást integrációs csapatunktól!