EDI Átviteli Protokollok
Kommunikációs technológiák EDIFACT és egyéb EDI üzenetek biztonságos továbbítására
Áttekintés
Az EDIFACT önmagában csak az üzenet formátumát definiálja. Az üzenetek tényleges továbbításához különböző kommunikációs protokollokat és integrációs technológiákat alkalmaznak — a konkrét választás az iparági elvárások, a partner infrastruktúrája és a biztonsági követelmények függvénye.
Egy modern EDI Gateway rendszer (pl. SEEBURGER BIS, IBM Sterling, OpenText, Cleo, Axway, SAP PI/PO/CPI) akár több tucat kommunikációs technológiát kezel egyszerre, ugyanazon a platformon belül.
AS2 — Applicability Statement 2
Az AS2 az egyik legelterjedtebb protokoll a modern EDI kommunikációban, különösen a kiskereskedelemben (pl. Walmart, Amazon, Tesco) és az egészségügyben. HTTP/HTTPS kapcsolaton keresztül továbbít EDIFACT vagy más EDI fájlokat, miközben digitális aláírást, titkosítást és MDN visszaigazolást alkalmaz.
Az üzenetek digitális tanúsítványokkal titkosítottak (S/MIME).
Biztosítja a feladó hitelességét és az üzenet integritását.
Automatikus visszaigazolás — a fogadó igazolja, hogy megkapta és dekódolta az üzenetet.
Letagadhatatlanság — az MDN révén bizonyítható az üzenet kézbesítése.
Legfontosabb konfigurációs paraméterek
POST /as2 HTTP/1.1 AS2-From: COMPANY_A AS2-To: COMPANY_B Content-Type: application/pkcs7-mime Message-ID: <unique-id@company-a.com>
AS4 — Applicability Statement 4
Az AS4 SOAP/XML alapú modern B2B kommunikációs szabvány, amelyet az OASIS ebMS 3.0 keretrendszerre épít. Különösen elterjedt PEPPOL (európai közbeszerzés) és eInvoice (elektronikus számla) környezetben, ahol a hatóságok és nagyobb vállalatok kötelezővé teszik a használatát.
Európai közbeszerzési és eInvoice hálózatok elsődleges protokollja.
Szabványos webszolgáltatás-protokoll — széles eszköztámogatás.
Tanúsítványalapú üzenet-szintű biztonság és digitális aláírás.
Beépített visszaigazolás (Receipt) és hibakezelés.
OFTP2 — ODETTE File Transfer Protocol 2
Az OFTP2 az európai autóipar és gyártás preferált protokollja. Az ODETTE által kifejlesztett szabvány kifejezetten nagyvállalati, magas biztonsági követelményű környezetekre tervezték — biztonságos fájlcsere OEM-ek és beszállítóik között. A VW-csoport, BMW, Mercedes és Stellantis OFTP2-t kötelezővé tesz a közvetlen beszállítóknak.
VDA üzenetek, CAD fájlok és gyártási dokumentumok biztonságos cseréje.
Optimalizált nagy méretű fájlok átvitelére, megszakítás-tűrő mechanizmussal.
Megszakadt átvitel esetén folytatás az utolsó sikeres ellenőrzőponttól.
Tanúsítványalapú kölcsönös hitelesítés (mTLS) az átviteli csatornán.
SFTP — Secure File Transfer Protocol
Az SFTP az SSH protokollon futó biztonságos fájlátviteli megoldás. Egyszerű implementálhatósága és széles platformtámogatása miatt a leggyakoribb batch EDI feltöltési módszer — különösen közepes méretű vállalatoknál és olyan partnereknél, akik nem rendelkeznek AS2-képes infrastruktúrával.
Jelszó vagy nyilvános kulcsos (public key) autentikáció.
Az adatok és a bejelentkezési információk is titkosítva utaznak.
Minden ERP és EDI platform natívan támogatja — könnyen automatizálható.
Egyetlen port (22) szükséges — nem igényel komplex tűzfal-konfigurációt.
FTP / FTPS — File Transfer Protocol
Az FTP a legrégebbi fájlátviteli protokoll, amely az internet korai korszakából maradt fenn. Ma már legacy rendszerekben és belső hálózatokon fordul elő — nyílt hálózaton (interneten) az SFTP vagy FTPS váltja fel. Az FTPS (FTP over TLS) a titkosított változat, amely SSL/TLS réteget ad az alapprotokollhoz.
Az alap FTP titkosítás nélkül küld adatokat — interneten nem ajánlott.
TLS réteggel biztonságossá tehető, de tűzfal-konfigurációja bonyolult (aktív/passzív mód).
Régi gyártósori rendszerek, PLC-k és ERP-k még FTP-t használnak belső hálózaton.
HTTP / REST API
Az API-alapú B2B adatcsere egyre nagyobb szerepet tölt be a hagyományos EDI mellett, különösen azoknál a vállalatoknál, amelyek valós idejű adatcserét igényelnek. REST és SOAP API-k egyre inkább kiegészítik — néhol ki is váltják — a klasszikus fájl-alapú EDI folyamatokat. Az API gateway-ek képesek EDI üzeneteket generálni és fogadni belső konverzióval.
Azonnali adatcsere — nincs batch ablak vagy késleltetés.
Modern, könnyűsúlyú formátum — egyszerű fejlesztés és tesztelés.
API gateway-ek képesek EDI üzeneteket generálni és fogadni belső konverzióval.
A digitalizáció trendje az API-t egyre fontosabbá teszi a B2B kommunikációban.
Apache Kafka — Event Streaming
Az Apache Kafka elosztott eseményfolyam-platform, amelyet nagyteljesítményű, valós idejű adatpipeline-ok építésére terveztek. EDI kontextusban a Kafka aszinkron üzenetközvetítőként jelenik meg — különösen ott, ahol nagy mennyiségű tranzakciót kell feldolgozni alacsony késleltetéssel, például logisztikai eseménynaplózásnál vagy rendelésfeldolgozásnál.
Másodpercenként millió üzenetet képes feldolgozni horizontális skálázással.
Az üzenetek meghatározott ideig megőrzöttek — újrafeldolgozás lehetséges.
Kafka Connect segítségével adatbázisokhoz, ERP-khez és EDI rendszerekhez csatlakoztatható.
JMS — Java Message Service
A JMS Java enterprise messaging API, amelyet Java EE / Jakarta EE alkalmazások közötti aszinkron kommunikációra terveztek. EDI middleware rendszerekben (pl. SAP PI/PO, IBM MQ, ActiveMQ) a JMS queue-k és topic-ok az EDI üzenetek belső továbbítási mechanizmusai — az alkalmazások laza csatolással (loose coupling) kommunikálnak egymással.
Point-to-point (queue) és publish-subscribe (topic) mintákat egyaránt támogat.
SAP PI/PO, IBM WebSphere MQ, ActiveMQ — mind JMS-kompatibilis broker.
Atomikus üzenetküldés — az üzenet vagy sikeresen megérkezik, vagy visszavonásra kerül.
SAP IDoc — Intermediate Document
Az SAP IDoc az SAP saját belső dokumentumformátuma, amelyet az SAP rendszer és külső partnerek (pl. EDI szolgáltatók, más ERP-k) közötti adatcserére terveztek. Az EDI-SAP integrációban az IDoc jelenti a „hídot": az EDIFACT üzenetek SAP oldalon IDoc-ká konvertálódnak, és fordítva. Az IDoc feldolgozást az SAP EDI alrendszere (ALE/EDI) végzi.
EDI middleware (pl. SEEBURGER, Axway) végzi a konverziót a két formátum között.
ORDERS01 (rendelés), INVOIC02 (számla), DESADV01 (szállítólevél) és több száz más üzenettípus.
SAP-on belül a partnerprofilok, üzenettípusok és portok az SM59/WE20 tranzakciókban kezelhetők.
Mail — EDI e-mail mellékletként
Egyes kisebb partnereknél az EDI fájlok e-mail mellékletként kerülnek elküldésre, amelyet az EDI rendszer automatikusan feldolgoz (mailbox polling). Bár ez nem tekinthető iparági sztenderdnek, és biztonsága korlátozott, a valóságban sok kisvállalkozás így indul be az EDI-be — különösen akkor, ha a partner nem tud AS2 vagy SFTP kapcsolatot fenntartani.
Az EDI rendszer IMAP mailboxot figyel és automatikusan kiszedi a mellékleteket.
Nincs beépített visszaigazolás vagy non-repudiation — S/MIME aláírással javítható.
Kisebb partnereknek könnyű az indulás — az EDI rendszer kezeli a konverziót.
HotFolder — Könyvtárfigyelés
A HotFolder (más nevén Watch Folder) mechanizmus egy könyvtárat figyel, és ha EDI fájl kerül bele, automatikusan elindítja a feldolgozási folyamatot. Ez az egyik legegyszerűbb integrációs módszer — az ERP vagy gyártórendszer csak egy mappába ír fájlokat, az EDI middleware pedig onnan veszi fel és küldi tovább a partnernek.
Fájl megjelenésekor automatikusan indul a feldolgozás — nincs API integráció szükséges.
Bármely rendszer tud fájlt írni egy könyvtárba — UNC share, NFS, helyi elérési út.
SEEBURGER, IBM Sterling, Cleo mind támogatja HotFolder bemeneti csatornaként.
DB Controller — Adatbázis alapú üzenetsor
A DB Controller mechanizmusnál az EDI üzenetek nem fájlrendszeren, hanem egy adatbázis táblán keresztül cserélnek gazdát az ERP és az EDI middleware között. Az ERP rekordot ír egy táblába (pl. OUTBOUND_QUEUE), az EDI rendszer olvassa, feldolgozza, és státuszt ír vissza. Ez a megközelítés szoros integrációt tesz lehetővé és könnyen nyomon követhető.
INSERT / SELECT alapú kommunikáció — az ERP és EDI rendszer közös DB táblán osztozik.
Az üzenet állapota (várakozó, feldolgozás alatt, kész, hiba) a DB-ben nyomon követhető.
Nincs fájlrendszer — az ERP közvetlenül látja az EDI üzenetek státuszát.
MQTT — Message Queuing Telemetry Transport
Az MQTT könnyűsúlyú publish-subscribe üzenetküldő protokoll, amelyet korlátozott erőforrású eszközökre és megbízhatatlan hálózatokra terveztek. Az EDI kontextusban az ipar 4.0 és IoT integrációkban jelenik meg: gyártósori szenzorok, PLC-k és gépi adatok közvetlen gyűjtése és továbbítása EDI feldolgozó rendszerek felé.
Gyártósori eszközök, szenzorok és PLC-k adatait továbbítja alacsony sávszélességen.
Minimális fejléc overhead — ideális beágyazott rendszerekhez és mobil hálózatokhoz.
0 (tűz és feledd), 1 (legalább egyszer), 2 (pontosan egyszer) kézbesítési garancia.
OPC UA — OPC Unified Architecture
Az OPC UA az ipari automatizálás és a gyártási rendszerek de facto kommunikációs szabványa. Az IEC 62541 szerinti platform-független, biztonságos protokoll összeköti a gyártógépeket, SCADA rendszereket és az ERP/EDI réteget — ez az IT/OT konvergencia alapköve modern smart factory környezetben.
Összeköti a gyártósor szintjét (OT) az ERP/EDI réteggel (IT) — valós gyártási adatok.
Tanúsítványalapú autentikáció, aláírás és titkosítás az ipari protokollban.
Siemens, ABB, Rockwell, Beckhoff és mások OPC UA szervert implementálnak.
SLMP — Seamless Messaging Protocol
Az SLMP (Seamless Messaging Protocol) a Mitsubishi Electric MELSEC PLC sorozatának kommunikációs protokollja. Ethernet-en keresztül lehetővé teszi a PLC-k adatainak (regiszterek, device értékek) közvetlen lekérdezését és írását — felső szintű rendszerekből, pl. SCADA-ból vagy EDI middleware-ből.
Q, L, FX sorozatú PLC-k direkt elérése Ethernet-en — nincs szükség OPC szerverre.
Bitek, szavak, dupla szavak olvasása/írása — pl. darabszámlálók, státuszbitek.
Gyártási mennyiségi adatok automatikus kinyerése és EDI üzenetbe (pl. RECADV) ágyazása.
Amazon S3 — Cloud Object Storage
Az Amazon S3 (Simple Storage Service) felhő alapú objektumtároló, amelyet EDI fájlok átmeneti tárolására és cseréjére egyre szélesebb körben alkalmaznak. A cloud-natív EDI megoldások (pl. AWS B2B Data Interchange) S3 bucket-eket használnak bemeneti és kimeneti csatornaként — a partner feltölti az EDI fájlt, az EDI rendszer feldolgozza, és az eredményt visszaírja.
AWS B2B Data Interchange, Cleo Cloud és más SaaS EDI megoldások S3-ra épülnek.
S3 esemény (PutObject) Lambda funkciót vagy SQS üzenetet indít — teljesen automatizált.
Fine-grained jogosultsági rendszer — partnerenként külön bucket policy.
VAN — Value-Added Network
A VAN egy harmadik feles közvetítő hálózat, amely EDI üzenetek irányítását, tárolását és kézbesítését végzi a kereskedelmi partnerek között. Bár a közvetlen AS2/OFTP2 kapcsolatok terjedése csökkentette a VAN-ok szerepét, számos iparágban és régióban — különösen kiskereskedelemben — még mindig széles körben alkalmazzák.
A VAN kezeli a partnerkapcsolatokat — az újabb partnerek bekapcsolása egyszerűsödik.
Az összes tranzakció naplózva és visszakereshető — audit trail automatikusan.
Egyes VAN-ok konvertálási szolgáltatásokat is nyújtanak (pl. X12 ↔ EDIFACT).
Összefoglaló: melyiket mikor?
| Protokoll | Tipikus használat | Biztonság | Valós idő? |
|---|---|---|---|
| AS2 | Retail, Healthcare, globális B2B | Magas | Igen |
| AS4 | PEPPOL, eInvoice, közszféra | Magas | Igen |
| OFTP2 | Autóipar, gyártás (Európa) | Magas | Igen |
| SFTP | Általános B2B, batch feldolgozás | Magas | Nem |
| FTP/FTPS | Legacy rendszerek, belső hálózat | Alacsony / közepes | Nem |
| REST API | Modernizáció, SaaS integráció | Közepes–magas | Igen |
| Kafka | Event streaming, nagy volumen | Közepes | Igen |
| JMS | Java enterprise middleware | Közepes | Igen |
| SAP IDoc | SAP ERP integráció | Magas | Igen |
| Kisvállalkozás, belépési szint | Alacsony | Nem | |
| HotFolder | ERP–EDI fájlalapú integráció | Helyi | Nem |
| DB Controller | Szoros ERP integráció | Helyi | Részben |
| MQTT | IoT, Ipar 4.0, szenzorok | Közepes | Igen |
| OPC UA | Smart factory, IT/OT konvergencia | Magas | Igen |
| SLMP | Mitsubishi PLC, gyártásirányítás | Helyi | Igen |
| Amazon S3 | Cloud EDI, AWS pipeline | Magas | Részben |