Kaip pasirinkti kelių vežėjų siuntų sekimo API Lotynų Amerikai

Pasirinkite kelių vežėjų siuntų sekimo API Lotynų Amerikai išbandydami savo faktinius siuntimo maršrutus, vežėjų perdavimus ir veiklos procesus, o ne lygindami viešai nurodomą vežėjų skaičių. Geriausiai tinka ta paslauga, kuri patikimai sujungia siuntų įvykius svarbiausiuose maršrutuose, išsaugo naudingą vežėjo informaciją, pateikia atnaujinimus, kuriuos jūsų sistemos gali saugiai apdoroti, ir turi prognozuojamą atsiskaitymo modelį.

Elektroninės prekybos operacijų komandoms ir integracijos inžinieriams pirkimo sprendimas turėtų prasidėti nuo reprezentatyvios siuntų imties ir baigtis parengties gamybai testu. Aprėptį, duomenų kokybę, integracijos patikimumą ir kainą vertinkite kaip atskirus klausimus. Teikėjas gali atitikti vieną iš šių kriterijų, bet neatitikti kitų.

Apibrėžkite maršrutus ir sprendimus, kuriuos turi palaikyti API

„Lotynų Amerikos aprėptis“ yra per plati sąvoka, kad galėtų būti pirkimo reikalavimu. Vidaus siunta Meksikoje, į Braziliją įvežamas tarptautinis siuntinys ir tarp dviejų Pietų Amerikos šalių keliaujantis užsakymas yra skirtingi testavimo atvejai. Vertinimas turėtų atspindėti šalis, siuntimo paslaugas ir pristatymo partnerius, kuriuos iš tikrųjų naudojate.

Prieš prašydami pasiūlymų sudarykite maršrutų sąrašą. Kiekvienam maršrutui nurodykite kilmės vietą, paskirties vietą, siuntimo paslaugą, pirmosios mylios vežėją, žinomą pristatymo partnerį, mėnesinį siuntų kiekį ir veiklos svarbą. Jei paskirties vežėjas etiketės sukūrimo metu nėra žinomas, nurodykite šį neapibrėžtumą, o ne manykite, kad pristatymą vykdys pradinis vežėjas.

Tada apibrėžkite, ką jūsų verslas turi daryti su sekimo informacija. Klientų aptarnavimui gali reikėti naujausio reikšmingo įvykio; operacijų komandai gali reikėti nustatyti siuntas, kurioms reikia įsikišimo; klientų informavimo paslaugai reikia patikimo paleidiklio. Šie reikalavimai lemia, kurioms API galimybėms turėtų būti suteiktas didžiausias svoris.

• Operacijų vadovas: apibrėžia veiksmingas išimtis ir eskalavimo taisykles.
• Inžinerijos vadovas: tikrina duomenų struktūras, pristatymo mechanizmus, saugumą ir atkūrimo veikimą.
• Pirkimų arba finansų vadovas: tikrina atsiskaitymo vienetus, sutartinius įsipareigojimus ir išlaidų riziką.
• Klientų patirties vadovas: tvirtina klientams skirtas būsenas ir pranešimų formuluotes.

Priėmimo kriterijus suderinkite kartu. Priešingu atveju techniškai sėkminga integracija vis tiek gali palikti klientų aptarnavimo agentus be jiems reikalingos informacijos.

Patikrinkite vežėjų aprėptį maršruto ir paslaugos lygiu

Vežėjų katalogas yra naudingas pradinis taškas, tačiau vien įrašas kataloge nepatvirtina, kad kiekviena paslauga, sekimo numerio formatas ar tarptautinis perdavimas veiks su jūsų siuntomis. Paprašykite teikėjų patikrinti jūsų pačių tinklo pavyzdžius.

Jūsų testų rinkinį turėtų sudaryti ir aktyvios, ir užbaigtos siuntos. Užbaigtos istorijos padeda įvertinti įvykių interpretavimą, o aktyvios siuntos atskleidžia atnaujinimų veikimą. Įtraukite ir įprastus pristatymus, ir veiklos požiūriu sudėtingus atvejus, o ne tik sklandžiai užbaigtus pristatymus.

Testavimo atvejis	Ką patikrinti	Kodėl tai svarbu
Vidaus pristatymas	Teisingą vežėjo identifikavimą ir reikšmingus pristatymo įvykius	Nustato kasdienių operacijų atskaitos tašką
Tarptautinis perdavimas	Tęstinumą tarp vežėjų ir bet kokį pakeistą sekimo numerį	Patikrina, ar po perdavimo siunta išlieka suprantama
Su muitine susijęs įvykis	Pradinį įvykio tekstą ir tinkamai atsargų būsenos susiejimą	Padeda atskirti įprastą apdorojimą nuo galimo veiksmo poreikio
Nepavykęs pristatymo bandymas	Pakankamai išsamų įvykį kitam veiklos veiksmui nustatyti	Padeda įsikišti nesudarant įspūdžio, kad siuntinys prarastas
Grąžinamas siuntinys	Pristatymo pirkėjui ir grįžimo siuntėjui atskyrimą	Apsaugo nuo klaidinančių klientų pranešimų ir ataskaitų

Vežėjo nustatymą testuokite atskirai nuo sekimo duomenų gavimo. Jei numeris gali atitikti daugiau nei vieną vežėją, patikrinkite, ar aiškiai nurodžius vežėjo identifikatorių neapibrėžtumas pašalinamas. Sėkmingo atsakymo nepakanka: patvirtinkite, kad grąžinta istorija priklauso numatytai siuntai.

Perdavimo atvejais paklauskite, kas nutinka, kai pristatymo partneris suteikia kitą sekimo numerį. Ar API atskleidžia šį ryšį, ar reikia registruoti dar kartą, ar jūsų programa turi sujungti įrašus? Bet kuris iš šių sprendimų gali būti tinkamas, tačiau įgyvendinimo pastangos skiriasi.

Vertinkite ne tik suvienodintas būsenų etiketes

Suvienodintos būsenos palengvina vienos darbo eigos kūrimą keliems vežėjams. Tačiau jos taip pat susiaurina informaciją. Plati „išimties“ etiketė gali nepasakyti agentui, ar reikia susisiekti su gavėju, patikrinti dokumentus, ar tiesiog stebėti siuntą.

Įvertinkite, ar atsakyme išsaugomas pradinis vežėjo aprašymas kartu su suvienodinta būsena. Ispanų ir portugalų kalbomis pateiktiems įvykiams išbandyti naudokite realius pavyzdžius su žmogumi, suprantančiu jų veiklos reikšmę. Jei pateikiamas išverstas tekstas, patikrinkite, ar jis nepakeičia veiksmo, kurį nurodo originalus pranešimas.

Atskirkite įvykio laiką nuo atnaujinimo laiko

Kiekvienam įvykiui atskirkite laiką, kada, vežėjo teigimu, jis įvyko, nuo laiko, kada jūsų integracija jį gavo. Jei API pateikia surinkimo arba apdorojimo laiko žymą, išsaugokite ir ją. Be šių skirtumų vėlai gautas senas įvykis gali atrodyti kaip naujas judėjimas.

Patikrinkite laiko žymų formatus ir laiko juostų tvarkymą. Neinterpretuokite nenurodytos laiko juostos tyliai kaip UTC. Jūsų programa turėtų išsaugoti neapibrėžtumą, o ne kurti tariamą tikslumą, ypač matuojant gabenimo intervalus tarp šalių.

Nepaverskite sekimo matomumo muitinės pažadu

Sekimo informacija savaime nėra muitinio įforminimo paslauga. Su muitine susijęs nuskaitymas gali apibūdinti apdorojimą, tačiau nenurodyti, kas turi veikti ar kokių dokumentų reikia. Jei šaltinis aiškiai nepalaiko tvirtesnio aiškinimo, klientų pranešimuose reikėtų vengti teiginių, kad muitai sumokėti, įforminimas baigtas ar išleidimo data garantuota.

Toks pats atsargumas taikomas numatomoms pristatymo datoms. Paklauskite, ar prognozė gaunama iš vežėjo, API teikėjo, ar apskaičiuojama jūsų pačių, ir ar šaltinis atsakyme identifikuojamas.

Testuokite atnaujinimų pristatymą ir atkūrimą sutrikimų metu

Sekimo API tampa veiklos priklausomybe, kai ji naudojama pranešimams, skydeliams ar klientų aptarnavimo darbo eigoms. Įvertinkite, kaip atnaujinimai pasiekia jūsų sistemą ir kaip integracija atsigauna, kai kuri nors pusė nepasiekiama.

Jei siūlomos žiniatinklio užklausos, paprašykite autentifikavimo, patvirtinimo reikalavimų, pakartotinių bandymų, pasikartojančio pristatymo, eiliškumo ir pakartojimo galimybių dokumentacijos. Nemanykite, kad šie veikimo principai visiems teikėjams yra vienodi.

• Pasikartojantys įvykiai: apdorokite pakartotinius pristatymus nesiųsdami pakartotinių klientų pranešimų.
• Ne eilės tvarka pateikti įvykiai: neleiskite senesniam įvykiui neteisingai pakeisti vėlesnės siuntos būsenos.
• Gavėjo neveikimas: nustatykite, kaip atkurti praleistus atnaujinimus po to, kai jūsų galinis taškas vėl pradeda veikti.
• Užklausų dažnio ribojimas: laikykitės dokumentuotų ribų nesukurdami agresyvaus pakartotinių bandymų ciklo.
• Neatpažinti laukai: toleruokite suderinamus papildymus ir kartu aptikite pakeitimus, kurie sutrikdo integraciją.

Jei reikia naudoti apklausą, užklausų kiekį apskaičiuokite pagal aktyvias siuntas ir apklausos dažnį, o ne tik pagal naujų siuntų skaičių per mėnesį. Patvirtinkite paketų dydžio ribas, puslapiavimą ir tai, ar pakartotinis duomenų gavimas turi įtakos mokesčiams.

HTTP standartas apibrėžia atsakymų semantiką, pavyzdžiui, būsenos kodus ir antraštę Retry-After, tačiau konkreti teikėjo pakartotinių bandymų sutartis vis tiek turi būti dokumentuota. Integraciją kurkite pagal šią sutartį, o ne manykite, kad kiekvieną nepavykusią užklausą galima pakartoti nedelsiant.

Stebėkite duomenų aktualumą, ne tik pasiekiamumą

Galinis taškas gali grąžinti sėkmingus atsakymus, nors siuntų duomenys išlieka pasenę. Todėl API stebėsena turėtų apimti ir techninę būklę, ir sekimo naudingumą.

Stebėkite registracijos klaidas, žiniatinklio užklausų apdorojimo klaidas, vežėjo identifikavimo klaidas ir laiką nuo paskutinio reikšmingo įvykio. Rezultatus segmentuokite pagal vežėją, maršrutą ir siuntos būseną. Siuntai, laukiančiai pirmojo nuskaitymo, neturėtų būti automatiškai taikoma ta pati įspėjimo taisyklė kaip siuntai, kuri jau išsiųsta pristatyti.

Duomenų aktualumo ribas nustatykite pagal savo paslaugų lūkesčius ir bandomojo projekto rezultatus. Nėra vieno tinkamo atnaujinimo intervalo kiekvienam vežėjui ar tarpvalstybinės logistikos etapui.

Palyginkite išlaidas pagal siuntos gyvavimo ciklą

Prieš lygindami pasiūlytas kainas nustatykite apmokestinamą vienetą. Paklauskite, ar mokesčiai priklauso nuo užregistruotų sekimo numerių, aktyvių siuntų, užklausų, atnaujinimų ar kito rodiklio. Tada pagal kiekvieną pasiūlymą sumodeliuokite tą patį darbo krūvį.

Įtraukite neaiškų vežėjo nustatymą, negaliojančius numerius, pakartotines registracijas, pakeistus sekimo numerius, istorinių duomenų gavimą ir siuntas, kurios lieka atviros ilgiau nei tikėtasi. Tai klausimai teikėjui, o ne prielaidos apie tai, ką apmokestina bet kuris teikėjas.

Paprašykite raštu paaiškinti viršijimus, nepanaudotus limitus, duomenų saugojimą, prieigą prie palaikymo ir atskirus įsipareigojimus gamybos aplinkai. Maža tariama vieneto kaina gali būti netinkama, jei už sutartinės paslaugos ribų paliekamas verslui kritinis reikalavimas.

Vidiniam palyginimui įvertinkite ne tik tiekėjo mokesčius, bet ir visas integracijos bei veiklos išlaidas. Sprendime turi atsispindėti inžinerinis darbas, reikalingas įvykiams suderinti, rankiniams klientų aptarnavimo tyrimams ir pranešimų taisymui, net jei jis neįtrauktas į API sąskaitą.

Įtraukite saugumą ir duomenų tvarkymą į priėmimo testus

Nustatykite, kokią informaciją jūsų programa siunčia teikėjui ir ką gauna. Venkite teikti klientų duomenis, kurie nereikalingi sekimui. Kartu su saugumo ir teisės komandomis peržiūrėkite prieigos kontrolę, prisijungimo duomenų keitimą, registravimą, duomenų saugojimą, trynimo procedūras ir reagavimo į incidentus eskalavimą.

Jei naudojamos žiniatinklio užklausos, patikrinkite dokumentuotą autentiškumo mechanizmą ir, kai taikoma, apsaugą nuo pakartojimo atakų. Laikykite prisijungimo duomenis atokiau nuo programos žurnalų ir klientams skirto kodo. OWASP API Security Top 10 yra naudinga peržiūros sistema, ypač vertinant autorizavimo, autentifikavimo ir išteklių naudojimo rizikas; tai nėra įrodymas, kad konkretus teikėjas išlaikė saugumo vertinimą.

Duomenų apsaugos reikalavimai priklauso nuo atitinkamų šalių, duomenų srautų ir sutartinių vaidmenų. Atlikite tinkamą peržiūrą, o ne manykite, kad viena regioninė politika apima visas Lotynų Amerikos operacijas.

„17TRACK“ vieta galutiniame sąraše

Šiam naudojimo atvejui aktualus 17TRACK produktas, kurį reikėtų įvertinti, yra jo Tracking API. Pradėkite nuo šio produkto puslapio ir oficialios API dokumentacijos, tada pritaikykite tuos pačius pirmiau aprašytus maršrutų, įvykių kokybės, patikimumo, saugumo ir komercinius patikrinimus.

Tinkamumą nustatykite pagal faktinį vežėjų ir paslaugų derinį. Vartotojų sekimo rezultatai ar užsakymų sekimo programa neturėtų pakeisti API priėmimo testų: jūsų vidinei sistemai reikia dokumentuoto veikimo, atitinkančio jos registravimo, duomenų gavimo, atkūrimo ir stebėjimo reikalavimus.

Įtraukite 17TRACK į bandomąjį projektą, kai vertinate kelių vežėjų sekimo integraciją. Tinkamumą gamybai laikykite priklausomu nuo bandomojo projekto ir susitarimo, o ne nustatytu bendru produkto aprašymu. Jei kritinis reikalavimas lieka nepatvirtintas, prieš įsipareigodami paprašykite paaiškinimo; neapibrėžtumas nėra įrodymas, kad galimybės nėra.

Vykdykite bandomąjį projektą su aiškiomis išlaikymo ir neišlaikymo sąlygomis

1. Pasirinkite reprezentatyvias siuntas. Apimkite svarbiausius maršrutus, svarbius vežėjus, skirtingas paslaugas, perdavimus ir sudėtingus rezultatus. Atskirai registruokite atvejus, kurių veikimas dar nebuvo stebėtas.
2. Sukurkite atskaitos įrašą. Palyginkite API įvykius su paties vežėjo sekimo informacija ir savo veiklos įrašais. Pažymėkite, kada atliktas kiekvienas palyginimas, nes šaltiniai gali būti atnaujinami skirtingu metu.
3. Išbandykite verslo veiksmus. Patvirtinkite, kad pristatymo pranešimai, išimčių eilės ir klientų aptarnavimo rodiniai veikia tinkamai, o ne tik tai, kad gaunami JSON atsakymai.
4. Sukelkite integracijos sutrikimus. Leistinomis testavimo sąlygomis išbandykite laikiną galinio taško nepasiekiamumą, pasikartojančius pranešimus, negaliojančius įvesties duomenis ir užklausų dažnio ribojimo tvarkymą.
5. Suderinkite naudojimą ir mokesčius. Patikrinkite, ar stebėta veikla atitinka siūlomą atsiskaitymo modelį.
6. Peržiūrėkite neišspręstas spragas. Prieš diegdami kiekvienai spragai priskirkite atsakingą asmenį, verslo pasekmę ir būtiną sprendimą.

Aprėptį vertinkite pagal poveikį verslui, o ne pagal patikrintų vežėjų pavadinimų skaičių. Nesėkmė didelės apimties ar sutartiniu požiūriu svarbiame maršrute turėtų turėti didesnį svorį nei sėkmė maršrute, kurį naudojate retai.

Pasirinkite teikėją, kuris atitinka jūsų kritinius reikalavimus ir reikalauja priimtinos veiklos naštos. Jei reikalavimus atitinka keli teikėjai, palyginkite antrinius privalumus ir bendrą kainą. Jei neatitinka nė vienas, susiaurinkite pradinį diegimą arba paveiktiems maršrutams išsaugokite atsarginį sprendimą, o ne slėpkite spragą bendrame balų vidurkyje.

DUK

Ar didesnis vežėjų skaičius reiškia geresnę aprėptį Lotynų Amerikoje?

Nebūtinai. Bendras skaičius nepatvirtina konkrečių paslaugų, sekimo formatų ar tarptautinių perdavimų palaikymo. Patikrinkite vežėjus ir maršrutus, kurie sudaro jūsų faktinę siuntų apimtį ir veiklos riziką.

Ar vienas sekimo numeris gali sekti siuntinį per visą tarptautinę kelionę?

Kartais, tačiau nemanykite, kad taip bus visada. Perdavus siuntą gali atsirasti kitas identifikatorius. Patikrinkite, ar API sujungia šiuos identifikatorius ir ar jūsų programai reikia registruoti arba suderinti papildomą įrašą.

Ar klientų pranešimuose reikėtų naudoti neapdorotus vežėjo pranešimus?

Paprastai klientų pranešimuose turėtų būti vartojama peržiūrėta kalba, pagrįsta įvykio reikšme. Išsaugokite originalų pranešimą klientų aptarnavimui ir auditui, tačiau venkite klientams rodyti neaiškią vidinę terminologiją ar plačią išimties etiketę laikyti galutiniu pristatymo nesėkmės įrodymu.

Ką daryti, jei vežėjo svetainėje įvykis rodomas anksčiau nei API?

Užregistruokite įvykio laiko žymą ir laiką, kada jis tapo matomas kiekviename šaltinyje. Pasikartojančius skirtumus nagrinėkite pagal vežėją ir maršrutą, o ne laikykite vieną stebėjimą bendru veikimo rezultatu. Paklauskite teikėjo apie duomenų surinkimo veikimą ir taikomą paslaugos įsipareigojimą.

Ar sekimo API gali pakeisti siuntimo arba muitinės platformą?

Nemanykite, kad sekimas apima etikečių pirkimą, muitinės deklaracijų pateikimą, muitų apskaičiavimą ar įsikišimą į pristatymą. Jei jūsų darbo eigai šios funkcijos reikalingos, patikrinkite jas atskirai. Siuntos matomumas ir teisė keisti siuntą yra skirtingi reikalavimai.

Šaltiniai

• 17TRACK Tracking API — oficialus produkto pradžios taškas vertinant 17TRACK API pasiūlymą.
• 17TRACK API documentation — techninė nuoroda integracijos reikalavimams ir dokumentuotam veikimui tikrinti.
• RFC 9110: HTTP Semantics — nuoroda į HTTP atsakymų semantiką ir Retry-After.
• OWASP API Security Top 10, 2023 edition — API saugumo peržiūros sistema, apimanti autorizavimą, autentifikavimą ir išteklių naudojimą.