EDI: Teste unitare pentru UNH — modelarea MIG-urilor și acoperirea cazurilor-limită

În ultimii ani, EDI a rămas infrastructura invizibilă care ține laolaltă lanțurile de aprovizionare, retailul și automotive-ul european. Pentru echipele tehnice, robustețea integrărilor EDI trece printr-un detaliu aparent banal: segmentul UNH (Message Header) și modul în care modelăm MIG-urile (Message Implementation Guidelines) în teste unitare, astfel încât să acoperim cazurile-limită din lumea reală.

Context de piață și relevanța UNH

EDI nu e un moft vechi: conform MarketsandMarkets (2023), piața globală EDI este estimată să crească de la 2,2 miliarde USD în 2023 la 4,0 miliarde USD până în 2028, cu o rată medie anuală de 12,7%. În Europa, EDIFACT rămâne standardul de facto în retail și auto, cu actualizări periodice ale directoarelor UN/CEFACT (ex. D.23B), iar lanțuri mari de retail și OEM-uri auto solicită constant conformitate strictă cu MIG-urile proprii sau cu subseturi ca EANCOM (GS1) ori Odette. În acest ecosistem, UNH este “cartela de identitate” a fiecărui mesaj EDI: dacă e greșit, mesajul se oprește la poarta traductorului.

Anatomia UNH și legătura cu MIG-urile

UNH are rolul de a identifica în mod unic mesajul EDI și de a specifica tipul, versiunea, release-ul și agenția de control. În termeni EDIFACT, în UNH regăsim un număr de referință al mesajului (unic în cadrul interschimbului) și compozitul S009 (cu tipul de mesaj, versiunea, release-ul, agenția și, opțional, un cod de asociație, de ex. pentru EANCOM).

UNH+000000123+ORDERS:D:96A:UN:EAN008'

MIG-urile (GS1 EANCOM, Odette pentru DELFOR/DELJIT etc.) precizează exact ce combinații sunt acceptate: tipul de mesaj (ORDERS, DESADV, INVOIC), versiune (ex. D), release (ex. 96A), agenție (UN) și coduri de asociație (ex. EANxxx). Modelarea MIG-ului în teste înseamnă să codificăm aceste reguli astfel încât orice schimbare accidentală în UNH să fie depistată în pipeline-ul CI/CD înainte să ajungă în producție.

Strategii de testare unitară pentru UNH

• Contract-driven: Derivați regulile din MIG (PDF/HTML) într-un format machine-readable (JSON/YAML) și generați automat aserțiuni. De ex., pentru MIG EANCOM ORDERS, validați că UNH are 0051=UN și 0054=96A pe toate fluxurile EDI.
• Property-based testing: Generați automat variante de UNH (valid/invalid) pentru a testa parserul și validatorul. Biblioteci precum jqwik (Java) sau Hypothesis (Python) pot acoperi spații mari de date cu efort redus.
• Testare de regresie pe mostre reale: Congelați fișiere anonimizate de la parteneri mari (retail, 3PL) și rulați-le la fiecare schimbare de cod sau configurație EDI.
• Fuzzing controlat: Inserarea de separatori nestandard sau caractere non-ASCII pentru a observa comportamentul unui traductor EDI în fața inputurilor “murdare”.
• Performance micro-benchmarks: Măsurați latența de parse/validate a UNH când rulați loturi mari (zeci/sute de mii mesaje EDI) pentru a anticipa ferestrele de procesare la retailerii cu volum mare.

Cazuri-limită de acoperit explicit

• Referință de mesaj duplicată în același interchange: UNH.0062 trebuie să fie unică; validați coliziuni și comportamentul de reject/ack.
• Versiune/Release incompatibile cu MIG: ex. mesaj cu 96B când MIG acceptă doar 96A; așteptați EDI CONTRL/APERAK cu erori.
• Agenție de control greșită: 0051 diferit de “UN”; multe gateway-uri EDI resping mesajul.
• Cod de asociație nerecunoscut: 0057 cu valoare non-EANCOM pentru parteneri care cer GS1; validați maparea la MIG.
• Separatoare sau escape-uri corupte: schimbare accidentală de component separator în UNB, care afectează parse-ul UNH.
• Lungimi maxime depășite: referințe prea lungi sau caractere nepermise; confirmați trunchierea vs. reject.
• Alinierea dintre UNH și payload: tipul ORDERS în UNH, dar segmente interne corespund INVOIC; testele trebuie să detecteze inconsistența.
• Seturi mixte de directory: UNH afirmă D.23B, dar segmentele folosesc coduri din alt director; verificați dicționarele la runtime.

Un ciclu de test recomandat

1. Model MIG: extrageți regulile UNH într-un fișier JSON (tip, versiune, release, agenție, cod asociație, regex pentru referință, unicitate).
2. Generați teste: pentru fiecare mesaj EDI suportat (ORDERS, DESADV, INVOIC), creați o matrice valid/invalid pe câmpurile UNH.
3. Validați ACK-urile: asociați așteptările cu răspunsurile CONTRL/APERAK de la platforma B2B (IBM Sterling, OpenText Trading Grid, SAP Integration Suite).
4. Introduceți date “din teren”: mostre anonimizate de la parteneri mari (ex. 3PL-uri, marketplace-uri) pentru a prinde variații reale.
5. Automatizați în CI: rulați testele la fiecare schimbare de mapare sau actualizare de director UN/CEFACT.

Tooling și bune practici

Pentru Java, Smooks EDI și BerryWorks EDIReader sunt opțiuni cunoscute; pentru .NET, ediFabric este larg folosit în proiecte enterprise; în Python, Bots EDI și py-edifact pot acoperi scenarii complexe. La nivel de rețea B2B, IBM Sterling, OpenText Business Network și SAP Integration Suite domină proiectele mari, iar SPS Commerce, TrueCommerce sau Descartes deservesc volume semnificative în retail și 3PL. Indiferent de stack, separați testele unitare (UNH, sintaxă EDI) de testele de integrare (rute, SFTP/AS2, securitate) și de testele de acceptanță (MIG de partener).

În România, multe programe de conformitate retail/auto cer subseturi stricte EDIFACT. Un furnizor local cu latențe mici poate accelera onboarding-ul; de exemplu, EDIconnect.ro (modul al CRMconnect) poate fi folosit pentru mapări rapide și validare MIG, în special când aveți echipe mixte ERP/EDI.

Mini-exemplu: test JUnit pentru UNH

// pseudo-Java

@Test

void unh_respects_mig() {

  Unh unh = parseUnh("UNH+000000123+ORDERS:D:96A:UN:EAN008'");

  assertEquals("ORDERS", unh.msgType());

  assertEquals("D", unh.version());

  assertEquals("96A", unh.release());

  assertEquals("UN", unh.agency());

  assertTrue(referenceIsUnique(unh.ref()));

  assertTrue(migAccepts("EAN008"));

}

Concluzie

Într-o lume în care EDI susține miliarde de tranzacții și interacțiuni critice, calitatea stă în detalii. Modelarea MIG-urilor în teste unitare pentru UNH nu este doar o “best practice”; este un gardian al stabilității operaționale. Investiția într-o suită de teste orientată pe UNH, cu acoperire de cazuri-limită, contracte din MIG și regresie pe mostre reale, reduce incidentele, accelerează onboarding-ul partenerilor și scade costul total al integrărilor EDI pe termen lung.