Trex Pi
Ja piegādājat preces lielam mazumtirgotājam vai autobūves koncernam Eiropā, jūs strādājat ar EDI. Ne tāpēc, ka kādam patīk EDIFACT sintakse, bet tāpēc, ka formātu izvēlas puse ar lielāku iepirkumu nodaļu, un viņu formāts tika standartizēts 1988. gadā. Gaidīt, kad viņi piedāvās REST API, nav stratēģija.
Kā izskatās moderna EDI sistēma praksē
Triks ir uztvert EDI kā pārraides dialektu, nevis kā arhitektūru. Integrācijas iekšpusē viss ir vienkāršs, skaidri tipizēts pasūtījuma/piegādes/rēķina objekts; EDIFACT un X12 pastāv tikai pašā malā - tulkotājos, kas ir vienkārši, versionēti un rūpīgi testēti ar ierakstītiem paraugfailiem.
Šī nodalīšana atmaksājas trīs veidos:
- Jauna tirdzniecības partnera pievienošana nozīmē jaunu tulkotāja profilu - ziņojuma versiju, segmentu īpatnības, viņu radošo brīvā teksta lauku izmantošanu -, nevis jaunu biznesa loģiku.
- Testēšana ir atkārtojama. Katrs jebkad saņemtais partnera fails kļūst par testa paraugu. Kad tulkotājs mainās, mēs caur to izlaižam piecu gadu datplūsmu un salīdzinām rezultāta atšķirības.
- 20 gadus vecā ERP un pavisam jaunais tiešsaistes veikals redz vienu un to pašu pasūtījuma objektu, tāpēc EDI pasūtījumi un API pasūtījumi plūst caur vienu cauruļvadu ar vienu noteikumu kopumu.
Nepievilcīgās detaļas, kurām ir nozīme
Apstiprinājumi veido pusi no protokola. Partneris, kas laikus nesaņem savu CONTRL ziņojumu, pieņems, ka pasūtījums ir pazudis, un piezvanīs jūsu pārdošanas komandai. Sekojiet līdzi apstiprinājumu aiztures laikam tāpat, kā sekojat līdzi darbspējas laikam - tas ir rādītājs, ko klienta iepirkumu speciālists patiesībā izjūt.
EDI nav tehniskais parāds. Tā ir infrastruktūra - kā sliežu platums. No tās nevar atbrīvoties ar modernizāciju; jūs izveidojat tīrus adapterus un ļaujat tam turpināt darīt to, ko tas jau četras desmitgades ir darījis uzticami.