În multe proiecte EDI, diferența dintre confirmările de transport (MDN) din AS2/AS4 și confirmările aplicației (EDI APERAK) devine critică abia când apare primul incident: un partener a trimis un fișier, MDN-ul este „processed”, dar ERP-ul nu vede comanda; sau invers, aplicația a respins documentul prin APERAK, însă transportul figurează impecabil. Un model robust de corelare între MDN și APERAK este ceea ce face diferența între un SLA respectat și un lanț de aprovizionare în derivă.
MDN în AS2 și AS4: ce garantează și ce nu
AS2 (RFC 4130) și AS4 (profil OASIS al ebMS 3.0) oferă nonrepudiere de origine și integritate la nivel de transport, nu validare de business. MDN-ul (Message Disposition Notification) în AS2 poate fi sincron sau asincron, semnat digital, și conține MIC (Message Integrity Check) – un rezumat criptografic al payload-ului (ex. SHA-256) pe care receptorul îl calculează și îl confirmă. Statusul „processed” într-un MDN semnat, cu MIC matching, înseamnă că mesajul a fost recepționat, decriptat/validat la transport și predat aplicației. În AS4, echivalentul este Receipt/SignalMessage, cu opțiunea NonRepudiationInformation ce transportă digests ale payload-ului, incluse în semnătura WS-Security. Important: nici în AS2, nici în AS4, aceste confirmări nu semnifică validare sintactică EDIFACT sau acceptare de business.
EDI APERAK: confirmarea aplicației
APERAK (Application error and acknowledgement message) este mesajul EDIFACT prin care aplicația destinatară confirmă procesarea unui document (acceptat sau respins cu motivare). Spre deosebire de CONTRL (care confirmă conformitatea sintactică EDIFACT), APERAK privește regulile de business: de exemplu, „cod articol inexistent”, „cantitate invalidă” sau „document duplicat”. În mod corect, APERAK referențiază documentul original prin RFF/DTM și corelează Message Reference Number (UNH:0062) și/sau chei de business (de exemplu, număr comandă sau factură) astfel încât expeditorul să poată trasa end‑to‑end orice excepție.
De ce contează corelarea MDN ↔ APERAK
Operațional, aveți cel puțin trei stări ce trebuie puse la un loc:
- Transport OK: HTTP 200, MDN/Receipt semnat, MIC match.
- EDI sintactic OK: opțional CONTRL pozitiv.
- Business OK: APERAK pozitiv (sau APERAK negativ cu cod și detalii).
Fără corelare unică, monitorizarea devine fragmentată: echipa de rețea spune „e verde”, echipa aplicației spune „nu văd documentul”. În retail, unde jucători ca Walmart, Target sau Carrefour impun AS2 pentru schimbul de ORDERS/INVOIC, timpii de răspuns sunt atenți monitorizați: MDN în secunde, APERAK tipic în 15–60 de minute, altfel apar penalități, livrări ratate și costuri suplimentare.
Model de corelare recomandat (AS2/AS4 ↔ EDIFACT)
- La recepția mesajului:
- Persistați metadata de transport: AS2-Message-ID (sau AS4 MessageId), AS2-From/AS2-To, timestamp, hash MIC, semnături, endpoint.
- Din payload: UNB:0020 (interchange control ref), UNH:0062 (message ref), tipul mesajului (de ex. ORDERS, DESADV, INVOIC) și chei de business (număr comandă, factură).
- La emiterea MDN/Receipt:
- Stocați legătura între Original-Message-ID și MIC (AS2) sau RefToMessageId/Receipt (AS4).
- La validarea aplicației:
- Generați APERAK referențiind UNH:0062 al mesajului original și cel puțin o cheie de business. Includeți coduri de motiv standardizate și descrieri acționabile.
- Înregistrare unică:
- Construiți o „urmă unică” (correlation key) cu tuple: [AS2/AS4 MessageId] ↔ [UNH:0062] ↔ [cheie business]. Dacă partenerul permite, adăugați un X-Correlation-ID în headerul AS2/AS4 și în BGM/FTX, pentru diagnostic rapid.
Capcane frecvente
- Retrimiteri: La retransmitere, AS2-Message-ID se poate schimba, dar UNH:0062 rămâne. Evitați APERAK duplicate folosind deduplicare pe UNH:0062 + tip document + cheie business.
- Interchange cu mesaje multiple: Corelați APERAK la nivel de UNH, nu doar UNB, pentru a nu „valida în bloc” mesaje eterogene.
- MDN asincron pierdut: Implementați timeouts și re‑query pe baza evidenței de transport; un HTTP 200 fără MDN nu este succes final.
- AS4 Pull: În pull-mode, folosiți RefToMessageId din Receipt pentru a ancora corelarea în aceeași manieră ca la AS2.
Operaționalizare: metrici și SLA
- Transport (AS2/AS4): rata de MDN/Receipt în < 30s; rată MIC match 100% pe mesaje semnate.
- EDI: rata CONTRL pozitiv > 99,9% (unde se folosește).
- Business: APERAK emis în 15–60 min pentru 95–99% din volume; eroare < 0,5% cu cauze clasificate.
- Trasabilitate: timp de investigație pentru o comandă < 5 min, pe baza cheii de corelare.
Context de piață și standarde
AS2 rămâne dominant în retailul nord‑american și european, impus de companii precum Walmart, Amazon, Target, Tesco sau Metro AG. AS4 câștigă teren prin profilul PEPPOL utilizat pe scară largă pentru e‑invoicing în sectorul public din UE, unde multe administrații cer conexiuni prin Access Points compatibile AS4. În ecosistem, rețele și furnizori enterprise precum OpenText Trading Grid (care conectează peste un milion de parteneri de afaceri), IBM Sterling, SEEBURGER BIS, Axway B2Bi și Descartes susțin atât AS2, cât și AS4, cu module de non‑repudiere și tracking end‑to‑end.
La nivel de cifre, SPS Commerce a depășit 1,3 miliarde USD venituri anuale în 2023, continuând creșterea în 2024, semn al volumelor EDI în expansiune pe segmentul retail și 3PL. OpenText a raportat venituri de peste 5 miliarde USD în anul fiscal 2024, cu Trading Grid ca pilon major pentru EDI și integrări B2B. Aceste date indică o piață matură în care cerința de vizibilitate end‑to‑end (transport + EDI + business) este deja standard de facto.
Recomandări practice pentru IT managers și consultanți
- Impuneți corelarea multiplă: AS2/AS4 MessageId + UNH:0062 + chei de business; nu vă bazați pe un singur identificator.
- Normalizați APERAK: catalog de coduri de erori, mapare către SLA/alertare (P1, P2…), mesaje prietenoase pentru operațiuni.
- Automatizați fluxul: dacă MDN=OK și CONTRL=OK, dar APERAK întârzie, deschideți automat incident după pragul SLA.
- Semnături și hashing: standardizați pe SHA‑256, MDN semnat obligatoriu cu MIC; în AS4 folosiți profilul de NonRepudiationInformation.
- Observabilitate: dashboard unic ce afișează pentru fiecare document statusul Transport/EDI/Business și link către payload/headers.
Concluzie
Corelarea MDN-urilor AS2/AS4 cu APERAK transformă EDI dintr‑un „black box” într‑un sistem auditat cap‑la‑cap. MDN dovedește integritatea și livrarea la nivel de transport; APERAK dovedește acceptarea sau respingerea la nivel de business. Împreună, cu identificatori bine ancorați (AS2/AS4 MessageId, UNH:0062, chei de business) și cu metrici operaționale sănătoase, veți reduce MTTR, veți proteja SLA‑urile și veți asigura trasabilitate reală într‑un peisaj B2B în care atât AS2, cât și AS4 vor coexista încă mulți ani.