Kaip suvienodinti siuntų sekimą visoje Australijoje ir Naujojoje Zelandijoje naudojant vieną API

Norėdami suvienodinti siuntų sekimą Australijoje ir Naujojoje Zelandijoje naudodami vieną API, prijunkite užsakymų arba užsakymų vykdymo sistemą prie kelių vežėjų sekimo paslaugos, užregistruokite kiekvieną siuntą naudodami tinkamą vežėjo identifikatorių ir paverskite gaunamus sekimo atnaujinimus į nuoseklų vidinį įvykių modelį. Integracija turėtų išsaugoti konkretaus vežėjo informaciją, o jūsų operacijų komandai ir klientams suteikti vienodą sekimo patirtį tiek vietinėms, tiek tarp Tasmano jūros vykdomoms siuntoms.

Kūrėjams, elektroninės prekybos operatoriams ir logistikos komandoms pagrindinis iššūkis nėra pirmosios API užklausos pateikimas. Svarbiausia užtikrinti, kad siuntų tapatybės, pristatymo būsenos, vežėjų perdavimai ir klientų pranešimai išliktų nuoseklūs, kai skirtingi vežėjai tą pačią kelionę apibūdina skirtingai. Šiame vadove paaiškinama, kaip sukurti tokią integraciją, įvertinti sekimo API ir ją išbandyti prieš naudojant gamybinėje aplinkoje.

Apibrėžkite, ką turi suvienodinti vienas API

Bendras API suteikia jūsų programai bendrą integracijos tašką. Jis nereiškia, kad kiekvienas vežėjas skelbs identišką informaciją arba skenuos siuntas tokiu pačiu dažnumu. Jūsų architektūra turi atskirti nuoseklią sąsają nuo visiško matomumo.

Pradėkite nuo siuntų sąrašo, pagrįsto faktine užsakymų vykdymo veikla, o ne bendru vežėjų, veikiančių bet kurioje iš šių šalių, sąrašu. Įtraukite vietines siuntas Australijoje, vietines siuntas Naujojoje Zelandijoje ir tarpvalstybinius judėjimus abiem kryptimis. Pridėkite kitų tarptautinių kilmės šalių siuntas, jei jos yra jūsų verslo dalis.

• Vežėjas ir paslauga: Įrašykite vežėją, naudojamą paslaugą ir bet kurį žinomą pristatymo partnerį.
• Maršrutas: Atskirti siuntos kilmę ir paskirties vietą nuo naujausio jos skenavimo vietos.
• Identifikatoriai: Surinkite užsakymo numerį, užsakymo vykdymo numerį, sekimo numerį ir bet kurį pakaitinį arba partnerio numerį.
• Veiklos paskirtis: Nurodykite, ar atnaujinimai skirti klientų sekimui, išimčių valdymui, pristatymo patvirtinimui, ar visiems trims tikslams.
• Reikalinga išsami informacija: Nuspręskite, ar pakanka bendros pristatymo būsenos, ar agentams taip pat reikia skenavimo aprašymų, vietų ir laiko žymų.

Šis sąrašas tampa jūsų priėmimo kontroliniu sąrašu. Bendras paslaugų teikėjo vežėjų aprėpties rodiklis naudingas sudarant trumpąjį sąrašą, tačiau sprendimas turėtų priklausyti nuo to, ar jūsų faktiniai vežėjo ir paslaugos deriniai grąžina tinkamą naudoti sekimo informaciją.

Įvertinkite sekimo API pagal savo siuntų derinį

17TRACK siūlo Tracking API, todėl tai yra tinkamas variantas įvertinti kelių vežėjų integracijai. Naudokite jo official API documentation, kad patikrintumėte dabartinius integracijos reikalavimus. Vežėjų palaikymą, įvykių laukus, atnaujinimų elgseną, paskyros apribojimus ir komercines sąlygas laikykite dalykais, kuriuos reikia patikrinti įgyvendinant sprendimą, o ne prielaidomis, išvestomis iš produkto kategorijos.

Užduokite kiekvienam svarstomam API tuos pačius praktinius klausimus:

• Ar jis gali nustatyti ir sekti jūsų siuntų sąraše esančius vežėjus bei paslaugas?
• Kai vežėjo nustatymas neaiškus, ar galite pateikti aiškų vežėjo identifikatorių?
• Kaip jūsų programa gauna atnaujinimus ir koks atkūrimo mechanizmas taikomas, jei atnaujinimas praleidžiamas?
• Kokia pradinė vežėjo informacija lieka prieinama kartu su standartizuotomis būsenomis?
• Kas nutinka, kai sekimo numeris negalioja, dar neatpažįstamas arba gali būti susietas su daugiau nei vienu vežėju?
• Kaip jūsų paskyroje apibrėžiami naudojimas, atsiskaitymas, sekimo trukmė ir prieigos apribojimai?

Rekomenduojama sprendimo taisyklė: rinkitės pagal sėkmingus realių siuntimo modelių bandymus, o ne pagal didžiausią reklamuojamą vežėjų skaičių. Integracija tinkama tada, kai ji suteikia pakankamai informacijos jūsų veiklos sprendimams priimti ir pakankamai aiškiai atskleidžia klaidas, kad galėtumėte jas pašalinti.

Sukurkite vidinį modelį, atsparų vežėjų skirtumams

Atskirkite užsakymus, siuntas ir sekimo etapus

Nenaudokite sekimo numerio kaip pagrindinio užsakymo rakto. Viename užsakyme gali būti keli siuntiniai, o siuntinio kelionė gali apimti daugiau nei vieną sekimo identifikatorių. Vietoj to sukurkite vidinį siuntos ID ir susiekite su juo sekimo įrašus.

Praktinį modelį sudaro trys lygiai: kliento užsakymas, jo fizinės siuntos ir su kiekviena siunta susiję sekimo etapai. Vietinei siuntai gali reikėti tik vieno sekimo etapo. Tarpvalstybinei siuntai gali reikėti susietų įrašų, kai tampa svarbus kitas vežėjas arba identifikatorius.

Sekimo įrašą susiekite ne tik su sekimo numeriu, bet ir su vežėju, išsaugodami jo ryšį su jūsų siuntos ID. Jei atsiranda naujas pristatymo partnerio numeris, pridėkite jį kaip susijusį identifikatorių, o ne perrašykite pradinį. Taip išsaugoma istorija, kurios reikia pagalbos agentams tiriant perdavimą.

Išsaugokite neapdorotą ir standartizuotą įvykį

Naudokite nedidelį vidinių būsenų žodyną, pagal kurį jūsų verslas gali veikti. Pavyzdžiui, galite apibrėžti: prieš tranzitą, tranzitu, išvežta pristatyti, galima atsiimti, pristatyta, išimtis ir nežinoma. Tai siūlomos vidinės kategorijos, o ne teiginys apie konkretaus paslaugų teikėjo būsenų schemą.

Pradinį vežėjo aprašymą saugokite kartu su susieta būsena. Atsiėmimo punkto įvykis ir adreso problema gali reikalauti kliento veiksmų, tačiau jie neturėtų sukurti to paties pranešimo. Taip pat etiketės sukūrimas neturėtų automatiškai tapti įrodymu, kad vežėjas fiziškai turi siuntinį.

Sprendimus dėl susiejimo dokumentuokite versijuojamoje konfigūracijoje. Kai pasirodo naujas įvykio aprašymas, jei jo reikšmė neaiški, perkelkite jį į peržiūros eilę. Aiški nežinoma būsena yra saugesnė nei užtikrintas neteisingos pristatymo baigties priskyrimas.

Atskirkite įvykio laiką nuo gavimo laiko

Saugokite, kada įvykis įvyko, atskirai nuo laiko, kada jūsų sistema jį gavo. Senesnis skenavimas gali būti gautas po naujesnio, ypač kai atnaujinimai vėluoja arba istoriniai įvykiai pateikiami kartu.

Australijoje ir Naujojoje Zelandijoje venkite visoms siuntoms taikyti vieną fiksuotą laiko poslinkį. Jei pateikiamos šaltinio laiko žymos ir poslinkiai, juos išsaugokite. Kai turite patikimą vietos kontekstą, rodymui naudokite tinkamą pavadintą laiko juostą ir atsižvelkite į vasaros laiko skirtumus. Jei šaltinio laiko juosta nenurodyta, išsaugokite šį neapibrėžtumą, o ne išgalvokite tikslų UTC perskaičiavimą.

Įgyvendinkite patikimą duomenų gavimo procesą

1. Pirmiausia sukurkite vidinę siuntą. Prieš registruodami ją sekimo paslaugoje įrašykite jos ryšį su užsakymu, maršrutą, pasirinktą vežėją ir sekimo identifikatorių.
2. Pateikite sekimo registraciją. Naudokite paslaugų teikėjo dokumentuotą užklausos formatą. Išsaugokite atsakymą ir atskirkite sėkmingą registraciją nuo vėlesnio vežėjo įvykių prieinamumo.
3. Klasifikuokite klaidas. Atskirti netinkamus įvesties duomenis ir autentifikavimo problemas nuo laikinų paslaugos sutrikimų. Kartokite užklausą tik tada, kai pakartojimas gali pagrįstai padėti.
4. Gaukite arba nuskaitykite atnaujinimus. Įgyvendinkite pasirinkto API palaikomą duomenų pateikimo mechanizmą. Jei naudojate žiniatinklio kablius, patikrinkite gaunamas užklausas paslaugų teikėjo dokumentuotu metodu ir apdorokite priimtus įvykius patvarioje eilėje.
5. Prieš taikydami pakeitimus pašalinkite dublikatus. Jei įmanoma, naudokite paslaugų teikėjo įvykio identifikatorių arba kruopščiai sukurtą sudėtinį raktą. Pakartotinis pristatymas neturi sukelti pakartotinių klientų pranešimų.
6. Iš naujo apskaičiuokite siuntos būseną. Įvertinkite įvykio reikšmę ir chronologiją, o ne pakeiskite dabartinę būseną tuo atnaujinimu, kuris atkeliavo paskutinis.
7. Suderinkite neišsamius įrašus. Jei API palaiko duomenų nuskaitymą, naudokite jį praleistiems atnaujinimams arba pasenusiems įrašams tirti, laikydamiesi taikomų naudojimo apribojimų.

Konkretaus paslaugų teikėjo autentifikavimą, laukų pavadinimus ir klaidų tvarkymą laikykite adapteryje. Jūsų užsakymų valdymo sistema turėtų naudoti jūsų vidinį siuntos modelį, o ne tiesiogiai priklausyti nuo kiekvienos paslaugų teikėjo atsakymo detalės. Toks atskyrimas taip pat palengvina vėlesnių API pakeitimų testavimą.

Valdykite keliones per Tasmano jūrą neišgalvodami tikrumo

Tarpvalstybiniam sekimui reikia daugiau konteksto nei būsenų etikečių sekos. Kai šaltinio duomenys tai leidžia, jūsų programa turėtų atskirti eksporto įvykį, su muitine susijusį įvykį, vežėjo perdavimą ir galutinio pristatymo įvykį.

Nedarykite išvados apie muitinės formalumų užbaigimą pagal bendrą skenavimą „tranzitu“. Taip pat naujausio skenavimo nebuvimas neįrodo, kad siuntą laiko muitinė. Naudingame kliento pranešime nurodomas paskutinis patvirtintas įvykis ir jo laikas, tada paaiškinamas bet koks kitas veiksmas, kurį jūsų komanda iš tikrųjų gali palaikyti.

Kilmę ir paskirties vietą laikykite atskirai nuo skenavimo vietos. Iš Australijos į Naująją Zelandiją keliaujanti siunta netampa vietine Naujosios Zelandijos siunta vien todėl, kad gavo atvykimo skenavimą. Šis skirtumas svarbus maršrutų ataskaitoms ir atsakomybės už išimtis priskyrimui.

Jei įsitraukia pristatymo partneris, susiekite jo sekimo įrašą tik tada, kai ryšį patvirtina siuntos duomenys, sekimo paslauga arba veiklos požiūriu patikrintas įrašas. Nejunkite siuntinių vien todėl, kad identifikatoriai atrodo panašūs.

Paverskite sekimo įvykius naudingais klientų atnaujinimais

Klientams skirtas puslapis turėtų atsakyti į keturis klausimus: kokia yra naujausia patvirtinta būsena, kada tai įvyko, kur tai užregistruota, jei žinoma, ir ar klientas turi imtis veiksmų?

Pranešimų taisykles laikykite atskirai nuo įvykių gavimo. Ne kiekvienas skenavimas vertas el. laiško ar tekstinės žinutės. Apibrėžkite reikšmingus pokyčius, pavyzdžiui, pirmą patvirtintą judėjimą, bandymą pristatyti, būtinybę atsiimti arba pristatymo įvykį, ir slopinkite pasikartojančius įspėjimus apie tą patį pokytį.

• Pasenęs sekimas: Nurodykite, kada įvyko paskutinis atnaujinimas, tačiau nelaikykite tylos praradimo įrodymu.
• Pristatymo įverčiai: Atskirti vežėjo pateiktą įvertį nuo prekybininko pažado. Neišgalvokite datos, kai nėra nė vieno iš jų.
• Išimtys: Jei žinomas, pateikite konkretų kitą veiksmą, o ne nepaaiškintą klaidos etiketę.
• Ginčai dėl pristatymo: Išsaugokite šaltinio įvykį ir perduokite atvejį pagalbai; vien pristatymo būsena neišsprendžia kiekvieno kliento ginčo.

Apsaugokite ne tik API kredencialus, bet ir sekimo puslapius. Neskelbkite nereikalingų adreso ar kontaktinių duomenų, paslaugų kredencialus laikykite serveryje ir taikykite rodomai informacijai tinkamas prieigos kontrolės priemones.

Prieš paleisdami atlikite maršrutais pagrįstą bandomąjį projektą

Išbandykite vietines Australijos, vietines Naujosios Zelandijos, Australijos–Naujosios Zelandijos ir Naujosios Zelandijos–Australijos siuntas, jei šie maršrutai aktualūs jūsų verslui. Įtraukite įprastus pristatymus ir veiklos kraštutinius atvejus: dalinius užsakymus, neatpažintus numerius, perdavimus, bandymus pristatyti, atsiėmimo įvykius, grąžinimus ir vėluojančius skenavimus.

Vežėjo patvirtinimui naudokite realius siuntų įrašus, turėdami tinkamą leidimą. Naudokite sintetinius įvykius savo programos atsparumui tikrinti, tačiau nelaikykite sintetinių rezultatų realios vežėjo aprėpties įrodymu.

• Tapatybės patikra: Kiekvienas atnaujinimas pasiekia tinkamą siuntą ir užsakymą.
• Chronologijos patikra: Įvykiai ne eilės tvarka neteisingai negrąžina pristatymo eigos atgal.
• Atkūrimo patikra: Laikinos klaidos ir pasikartojantys atnaujinimai nepraranda duomenų ir nekartoja įspėjimų.
• Pagalbos patikra: Agentai gali peržiūrėti pradinį įvykį ir suprasti klientui rodomą būseną.
• Komercinė patikra: Numatomas naudojimas atitinka patikrintą paskyros atsiskaitymo modelį ir apribojimus.

Prieš vertindami bandomąjį projektą nustatykite priėmimo ribas. Matuokite registracijos rezultatus, nesusietus įvykius, apdorojimo vėlavimus, pasikartojančius pranešimus ir neišspręstas pasenusias siuntas. Atskirti vežėjo duomenų vėlavimus nuo vėlavimų jūsų programoje, kad pašalinimas būtų priskirtas tinkamam atsakingam asmeniui.

Įgyvendinimas parengtas tada, kai jūsų komanda gali paaiškinti ir išspręsti neišsamų sekimą, o ne tik rodyti sėkmingus pristatymus. Vienas API supaprastina ryšį, tačiau jūsų siuntos modelis, įvykių taisyklės ir veiklos procedūros užtikrina, kad šis ryšys būtų patikimas.

DUK

Ar vienas sekimo API pakeičia vežėjų siuntimo integracijas?

Nebūtinai. Sekimas, etikečių kūrimas, paėmimo užsakymas, tarifų apskaičiavimas ir muitinės dokumentai yra atskiros funkcijos. Patikrinkite pasirinkto produkto apimtį ir išsaugokite kitas integracijas, jei jų reikia jūsų užsakymų vykdymo procesui.

Ar galiu užregistruoti sekimo numerį prieš pirmąjį vežėjo skenavimą?

Patikrinkite API registracijos taisykles. Sukurkite programą taip, kad ji atskirtų priimtą sekimo registraciją nuo patvirtinto fizinio judėjimo. Įrašas be įvykių neturėtų būti automatiškai rodomas kaip esantis tranzitu.

Ar vienas API teiks realiojo laiko atnaujinimus kiekvienam vežėjui?

Nedarykite tokios prielaidos. Galutinis duomenų šviežumas priklauso nuo to, kada vežėjas paskelbia duomenis, kada sekimo paslauga juos gauna ir kada jūsų programa juos apdoroja. Patvirtinkite naudojamų vežėjo ir paslaugos derinių atnaujinimų veikimą.

Kas turėtų nutikti pasikeitus sekimo numeriui?

Išsaugokite pradinį identifikatorių ir patikrintą pakaitinį arba partnerio identifikatorių susiekite su ta pačia vidine siunta. Išsaugokite abi istorijas ir neleiskite pasikartojantiems įrašams generuoti prieštaringų pranešimų.

Ar 17TRACK yra tinkamas šiai integracijai?

Taip. Jo Tracking API yra tinkamas čia aprašytai kelių vežėjų integracijai. Įvertinkite jį naudodami Australijos ir Naujosios Zelandijos siuntų pavyzdžius, o prieš diegdami patvirtinkite vežėjų palaikymą, techninį veikimą ir paskyros sąlygas oficialiuose API ištekliuose.

Šaltiniai

• 17TRACK Tracking API — oficialus šiame vadove aptariamos API parinkties produkto šaltinis.
• 17TRACK API documentation — oficiali techninė nuoroda užklausų formatams, integracijos reikalavimams ir palaikomam veikimui patikrinti.