Trex Pi
Jei tiekiate prekes didelei mažmeninės prekybos ar automobilių pramonės grupei Europoje, jūs naudojate EDI. Ne todėl, kad kas nors mėgsta EDIFACT sintaksę, o todėl, kad formatą renkasi ta pusė, kurios pirkimų skyrius didesnis, o jų formatas buvo standartizuotas 1988 metais. Laukti, kol jie pasiūlys REST API, nėra strategija.
Kaip iš tikrųjų atrodo šiuolaikinė EDI sąranka
Paslaptis ta, kad EDI reikia laikyti perdavimo dialektu, o ne architektūra. Integracijos viduje viskas yra paprastas, aiškiai tipizuotas užsakymo / siuntos / sąskaitos faktūros objektas; EDIFACT ir X12 egzistuoja tik pačiame pakraštyje - vertikliuose, kurie yra paprasti, versijuojami ir kruopščiai testuojami su įrašytais pavyzdiniais failais.
Šis atskyrimas atsiperka trimis būdais:
- Naujo prekybos partnerio prijungimas reiškia naują vertiklio profilį - žinutės versiją, segmentų ypatumus, jų kūrybišką laisvo teksto laukų naudojimą - o ne naują verslo logiką.
- Testavimą galima pakartoti. Kiekvienas kada nors gautas partnerio failas tampa testiniu pavyzdžiu. Kai pasikeičia vertiklis, per jį iš naujo perleidžiame penkerių metų srautą ir palyginame rezultatus.
- 20 metų senumo ERP sistema ir visiškai nauja internetinė parduotuvė mato tą patį užsakymo objektą, todėl EDI užsakymai ir API užsakymai keliauja per tą pačią sistemą pagal tas pačias taisykles.
Nepatrauklios, bet svarbios detalės
Patvirtinimai sudaro pusę protokolo. Partneris, negavęs CONTRL žinutės per nustatytą laiko langą, nuspręs, kad užsakymas dingo, ir paskambins jūsų pardavimų komandai. Stebėkite patvirtinimų vėlavimą taip pat, kaip stebite sistemos veikimo laiką - tai rodiklis, kurį iš tikrųjų jaučia jūsų kliento pirkimų vadybininkas.
EDI nėra techninė skola. Tai infrastruktūra - kaip geležinkelio vėžės plotis. Jos neatsikratysite modernizuodami - reikia sukurti švarius adapterius ir leisti jai toliau daryti tai, ką ji patikimai darė keturis dešimtmečius.