În ultimul an, presiunea reglementărilor și a lanțurilor de aprovizionare a accelerat modernizarea platformelor EDI. RO e-Factura, extinsă în România din ianuarie 2024 pentru tranzacții B2B cu perioadă de grație până la 31 martie și aplicare fermă a amenzilor de la 1 aprilie, plus inițiativa UE ViDA și adoptarea PEPPOL în sănătate și sectorul public, au făcut din validarea granulară un obiectiv critic. În acest context, regulile de validare personalizate, orchestrate cu motoare de reguli precum Drools și JsonLogic, devin stratul-cheie care separă un flux EDI robust de unul fragil.
Context de piață și standarde
Analizele de piață publicate în 2024 de firme precum Grand View Research și Fortune Business Insights estimează piața globală de EDI la câteva miliarde USD, cu creștere anuală de două cifre până în 2030, alimentată de retail, automotive, logistică și sănătate. Retaileri precum Walmart și Target impun conformitate EDI furnizorilor, iar ecosisteme precum Amazon Vendor Central utilizează atât EDI, cât și API-uri. În Europa, EDIFACT rămâne dominant, în timp ce în SUA multe fluxuri folosesc ANSI X12. În România, RO e-Factura (UBL 2.1 CIUS RO) și raportarea digitală împing companiile să-și consolideze capabilitățile EDI.
Pe partea de soluții, IBM Sterling, OpenText Trading Grid, Cleo Integration Cloud, SPS Commerce, TrueCommerce și SAP Integration Suite oferă capabilități EDI enterprise, iar în zona open-source integratorii folosesc adesea Apache Camel, MuleSoft Anypoint și transformări custom. Standardele GS1 (GLN, GTIN), împreună cu cataloagele master data, devin surse de adevăr pentru validările la nivel de articol și partener.
De ce motoare de reguli pentru validarea EDI
Validarea EDI nu înseamnă doar conformitate cu schema. Dincolo de X12/EDIFACT/UBL, apar cerințe de business dependente de partener, sezon, linie de produs sau țară. Codul hardcodat se erodează rapid. Motoarele de reguli introduc:
- Separarea politicilor de business de codul aplicației. O echipă poate modifica o regulă EDI fără a redeplasa întregul serviciu.
- Transparență și audit. Reguli versiunate, cu trasabilitate la cerințe contractuale sau legale (de ex., regulile RO e-Factura).
- Scalare și compoziție. Validări simple și compuse (cross-document) pot rula paralel și incremental.
Drools vs JsonLogic: când și cum
Drools (proiect Red Hat) este un motor de reguli matur, parte din ecosistemul KIE, cu suport pentru DRL, DMN, tabele decizionale și audit. Este excelent pentru procese EDI complexe în Java, cu multe fapte (facts), inferență, corelări între ORDERS/ORDRSP/DESADV/INVOIC și reguli de preț/discount. Integrarea cu Quarkus, Spring Boot și Kogito permite executarea cloud-native, cu latențe mici și observabilitate prin OpenTelemetry.
JsonLogic este un format simplu pentru exprimarea regulilor în JSON, evaluabil pe server sau client (există implementări în JavaScript, Python, Java, Go). Este util când doriți să delegați anumite validări EDI către configurări livrate de business owneri în UI, când aveți nevoie de portabilitate între microservicii eterogene sau când setul de reguli este preponderent condițional (if/then) fără corelări complexe.
Model de arhitectură pentru validarea EDI
O arhitectură tipică pe microservicii include:
- Gateway EDI: recepție prin AS2/SFTP/PEPPOL/REST, identificare partener, anti-duplication.
- Layer de parsing și mapare: transformă X12/EDIFACT/UBL în modele interne (ex. JSON/Avro).
- Validare de schemă: conformitate strictă cu standardul EDI și cu profilele partenerilor.
- Validare de business cu motor de reguli: set global + set pe partener, cu versionare (GitOps) și rollout canar.
- Enrichment și master data: referințe GS1, liste VIES pentru TVA, cataloage ERP (SAP S/4HANA, Oracle Fusion, Microsoft Dynamics 365).
- Orchestrare evenimentială: Kafka sau Redpanda pentru fan-out de evenimente de validare, cu Dead Letter Queue și reprocess.
- Observabilitate: metri pentru “first-time-pass rate”, erori pe partener, timp median de procesare pe mesaj EDI și cost pe document.
Exemple de reguli EDI utile
- Retail X12 850/855: dacă segmentul N1-BY este diferit de N1-ST, validați matricea de livrare pe magazin; validați că UOM corespunde planogramei; restricții pe backorder per contract.
- EDIFACT DESADV/INVOIC: cross-check între QTY pe DESADV și LIN pe INVOIC; toleranțe ±2% pe greutate netă pentru produse proaspete.
- RO e-Factura: validare UBL structurală, corelare CUI cu registrul ANAF, verificare GTIN activ în GS1 și cote TVA corecte pentru regimul produsului.
- Automotive DELFOR/DELJIT: ferestre de livrare și cantități minime per familie de piese conform Odette/VDA.
Guvernanță, performanță și cost
Pentru EDI la volum mare, proiectați pentru latență sub-secundă per mesaj la validare sincrona și sarcini asyncrone pentru verificări externe (ex. VIES). Drools excellează pe reguli complexe, dar necesită discipline DevOps (testare automată a regulilor, impact analysis). JsonLogic are footprint mic și e simplu de expus prin UI, însă poate deveni dificil la scenarii cu corelări multi-document. În ambele cazuri, includeți:
- Versionare semantică a seturilor de reguli EDI, mapping între versiune și partener.
- Canar/AB testing pentru reguli noi, cu rollback instant.
- Panouri de control pentru KPI: rata de respingere pe tip de mesaj EDI, timpii de remediere și erorile recurente.
Integrare cu platforme comerciale
Soluții ca IBM Sterling și OpenText expun puncte de extensie pentru validări personalizate. În ecosisteme moderne, multe companii adaugă un microserviciu propriu “Rules” lângă gateway-ul EDI furnizat de vendor, păstrând astfel IP-ul logicii de business și flexibilitatea. În SAP Integration Suite, regulile pot fi orchestrate în BTP, iar pentru furnizorii mici, un serviciu ușor bazat pe JsonLogic poate fi suficient pentru a crește “first-time-pass rate” peste 95% în câteva sprinturi.
Concluzie
Validarea EDI cu motoare de reguli precum Drools și JsonLogic nu este un moft tehnologic, ci un răspuns pragmatic la reglementări în schimbare rapidă, cerințe variabile pe partener și presiunea asupra costurilor operaționale. Un strat de reguli bine guvernat crește calitatea datelor, reduce chargeback-urile și scurtează timpul de cash. Indiferent dacă rulați EDI în IBM Sterling, SAP sau o implementare custom, separarea logicii de validare într-un motor de reguli vă permite să țineți pasul cu RO e-Factura, PEPPOL și cu exigențele marilor retaileri. Pentru organizațiile care preferă un model modular, există și opțiuni locale; de exemplu, unii integratori români oferă EDI ca modul într-un CRM, ceea ce poate accelera time-to-value fără a sacrifica flexibilitatea regulilor.