Kaip patikrinti siuntų sekimo API aprėptį prieš įžengiant į naujas rinkas
Norėdami patikrinti siuntų sekimo API aprėptį prieš įeidami į naują rinką, išbandykite tikslias vežėjo, paslaugos, siuntimo maršruto ir paskutinės pristatymo grandies kombinacijas, kurias planuojate naudoti. Patikrinkite realias siuntas pagal vežėjų įrašus, įsitikinkite, kad įvykiai tinkamai pasiekia jūsų sistemas, ir prieš paleidimą dokumentuokite spragas. Tai, kad vežėjas yra nurodytas tiekėjo palaikomų vežėjų sąraše, yra tik pradžia, o ne įrodymas, kad jūsų suplanuota pristatymo kelionė bus matoma.
Šis vadovas skirtas logistikos vadovams, elektroninės prekybos operacijų komandoms ir integracijų savininkams, besiruošiantiems pradėti veiklą rinkoje. Tikslas – priimti praktišką sprendimą dėl paleidimo: kurie siuntimo maršrutai yra patikrinti, kuriems reikia atsarginio sprendimo, o kuriems vis dar trūksta įrodymų.
Apibrėžkite aprėptį pagal siuntimo maršrutus, o ne pagal šalių skaičių
Planuodami įėjimą į rinką, sekimo aprėptį vertinkite kaip galimybę gauti ir pateikti tinkamus naudoti siuntos įvykius konkrečiam siuntimo susitarimui. Vien paskirties šalis yra per platus analizės vienetas. Dvi į tą pačią šalį patenkančios siuntos gali naudoti skirtingus kilmės vežėjus, muitinės procedūras, pristatymo partnerius ir paslaugų lygius.
Atskirkite tris klausimus, kurie pirkimų diskusijose dažnai sujungiami:
- Vežėjo suderinamumas: Ar API gali priimti ir identifikuoti jūsų naudojamo vežėjo ir paslaugos siuntas?
- Kelionės matomumas: Ar API grąžina įvykius, kurių jūsų komandai reikia atitinkamuose siuntimo etapuose?
- Operacinis pateikimas: Ar šie įvykiai patikimai pasieks jūsų užsakymų valdymo sistemą, pagalbos įrankius ir klientų pranešimus?
Sėkminga API užklausa atsako tik į dalį pirmojo klausimo. Ji nepatvirtina, kad siunta turi naudingų įvykių, kad galutinis pristatymo rezultatas yra matomas arba kad jūsų programa apdorojo atnaujinimą.
1. Sukurkite konkrečiai rinkai skirtą aprėpties matricą
Pradėkite nuo siuntimo plano, kurį jūsų logistikos komanda iš tikrųjų ketina įgyvendinti. Paprašykite sandėlio, užsakymų įvykdymo paslaugų teikėjo ir transporto partnerių patvirtinti susijusius vežėjus bei paslaugas. Jei konsoliduotojas dinamiškai pasirenka paskutinės pristatymo grandies partnerį, užrašykite šį neapibrėžtumą, o ne laikykite konsoliduotojo pavadinimą išsamiu maršruto aprašymu.
Sukurkite po vieną eilutę kiekvienai reikšmingai kombinacijai. Toliau pateikti laukai sudaro naudingą darbinę matricą:
| Laukas | Ką įrašyti | Kodėl tai svarbu |
|---|---|---|
| Siuntimo maršrutas | Kilmės ir paskirties rinka | Vidaus siuntų rezultatai nepatvirtina tarpvalstybinio matomumo. |
| Vežėjas ir paslauga | Sutartinis vežėjas, paslaugos pavadinimas ir atitinkamas identifikatorius | Vežėjo lygio sąrašas gali neatsakyti į konkrečiai paslaugai skirtus klausimus. |
| Perdavimo susitarimas | Žinomas pristatymo partneris ir bet koks pakeistas sekimo numeris | Turite patikrinti tęstinumą perdavimo metu. |
| Reikalingi etapai | Priėmimas, judėjimas, bandymas pristatyti, pristatymas ir atitinkamos išimtys | Reikalavimai turi atspindėti pagalbos tarnybos ir klientų poreikius. |
| Verslo rizika | Prognozuojama siuntų dalis ir atnaujinimų trūkumo pasekmės | Didelės apimties ir didelės rizikos maršrutams reikia teikti pirmenybę. |
| Patikros būsena | Patikrinta, sąlyginė, dar nepatikrinta arba patvirtinta kaip nepalaikoma | Įrodymų trūkumo negalima painioti su palaikymo nebuvimu. |
Anksti paskirkite atsakomybes. Logistikos komanda turi patvirtinti fizinį maršrutą, inžinerijos komanda – duomenų pateikimą, o operacijų komanda turi nuspręsti, ar gautas matomumas leidžia vykdyti klientams duotus pažadus. Pirkimų skyrius gali koordinuoti procesą, tačiau vien funkcijų kontrolinis sąrašas neturėtų lemti priėmimo.
2. Patikrinkite oficialią dokumentaciją, tada užduokite konkrečiam maršrutui skirtus klausimus
Naudokite oficialią tiekėjo API medžiagą, kad nustatytumėte dokumentuotą integracijos apimtį. Ieškokite vežėjų identifikatorių, registracijos reikalavimų, atsako laukų, įvykių apibrėžimų, autentifikavimo, naudojimo limitų ir atnaujinimų pateikimo elgsenos. Išsaugokite datuotą su jūsų įgyvendinimu susijusios dokumentacijos įrašą.
Vertindami 17TRACK, kaip pradžios taškus patikrai naudokite oficialų Tracking API puslapį ir API dokumentaciją. Taikykite toliau aprašytus maršruto lygio priėmimo testus; nelaikykite bendro produkto aprašymo konkrečios paslaugos ar perdavimo susitarimo patvirtinimu.
Pateikite tiekėjui konkretų patikros prašymą, o ne klauskite, ar jis „apima“ šalį. Įtraukite planuojamą vežėją ir paslaugą, kilmės bei paskirties vietas, reprezentatyvius leidžiamus naudoti sekimo numerius, reikalingus etapus ir numatomą siuntų kiekį.
- Ar šiai konkrečiai paslaugai reikalingas aiškus vežėjo identifikatorius arba papildoma siuntos informacija?
- Kaip integracija turėtų apdoroti numerį, kuris gali sutapti su daugiau nei vienu vežėju?
- Ar pradinis identifikatorius gali atskleisti paskutinės pristatymo grandies veiklą, ar būtina užregistruoti antrą identifikatorių?
- Kurių reikalingų įvykių tikimasi šiame maršrute ir kurie iš jų priklauso nuo to, ar vežėjas juos pateikia?
- Kas nutinka, kai sekimas laikinai nepasiekiamas arba siunta dar neturi įvykių?
- Kokie naudojimo limitai, saugojimo taisyklės ir atsiskaitymo sąlygos taikomos siūlomai darbo eigai?
Atskirkite dokumentuotą elgseną nuo sutartinių įsipareigojimų. Techniniame atnaujinimų apraše nebūtinai garantuojamas atnaujinimo intervalas ar paslaugų lygio įsipareigojimas. Kai šis skirtumas turi įtakos paleidimo rizikai, paprašykite raštiško patvirtinimo.
3. Išbandykite reprezentatyvias siuntas, o ne tik sėkmingus pristatymus
Sudarykite testų rinkinį iš siuntų, kurias turite teisę pasiekti. Įtraukite ir užbaigtas, ir aktyvias siuntas. Istoriniai įrašai padeda patikrinti įvykių sekas, o realios siuntos reikalingos registracijai, atnaujinimų gavimui ir pateikimui jūsų sistemose stebėti.
Pasirinkite pavyzdžius iš matricoje nurodytų maršrutų ir paslaugų. Įtraukite įprastus pristatymus ir, jei yra realių pavyzdžių, vėluojančias siuntas, nesėkmingus bandymus pristatyti, pristatymus į atsiėmimo punktus ir grąžinimus siuntėjui. Nekurkite išimties testo rezultato, jei nėra tinkamos siuntos. Pažymėkite tokį scenarijų kaip laukiantį patikros.
Nėra universalaus pavyzdžių skaičiaus, įrodančio aprėptį. Nedidelis rinkinys gali atskleisti integracijos klaidą, tačiau negali patvirtinti patikimo veikimo kiekvienai paslaugai ir išimčiai. Išplėskite testavimą ten, kur maršrutų įvairovė, vežėjo neapibrėžtumas arba įvykių trūkumo pasekmės yra didesnės.
Palyginkite tą pačią siuntą trijuose įrodymų sluoksniuose
- Vežėjo įrašas: Užfiksuokite sekimo informaciją, kurią tiesiogiai pateikia atitinkamas vežėjas, įskaitant patikros laiką.
- API atsakas: Išsaugokite neapdorotą atsaką, grąžintą vežėjo tapatybę, įvykių laiko žymas ir gavimo laiką.
- Jūsų programa: Patvirtinkite, ką jūsų sistema išsaugojo, parodė ir panaudojo veiksmams inicijuoti.
Šie sluoksniai padeda nustatyti gedimo vietą. Įvykis, kurio nėra nei vežėjo sekimo sistemoje, nei API, skiriasi nuo įvykio, matomo vežėjo sistemoje, bet nesančio API. API esantis, tačiau jūsų užsakymų sistemoje trūkstamas įvykis rodo kitą integracijos dalį.
Vežėjo įrašą laikykite atskaitos tašku, o ne neklystančiu fizinio judėjimo atvaizdu. Sekimo įrašai aprašo praneštus įvykius; jie nesuteikia nuolatinio siuntos stebėjimo. Reikšmingus neatitikimus ištirkite kartu su vežėju ir API tiekėju.
4. Išnagrinėkite perdavimus, būsenų reikšmes ir atnaujinimų laiką
Patikrinkite tęstinumą paskutinėje pristatymo grandyje
Kiekviename tarpvalstybiniame maršrute patikrinkite, kas vyksta pasikeitus siuntos valdytojui. Užrašykite, ar pradinis numeris toliau grąžina naudingus įvykius, ar atsiranda kitas numeris ir ar jūsų sistema gali susieti abu identifikatorius su tuo pačiu užsakymu.
Perdavimo pranešimas nėra pristatymo matomumo įrodymas. Sekite siuntą iki galutinio rezultato. Jei paskutinės pristatymo grandies informacija nepasiekiama, nustatykite, ar priežastis yra trūkstami šaltinio duomenys, identifikatoriaus problema, konfigūracijos klaida ar pagalbos apribojimas. Kol skirtumas neaiškus, laikykite maršrutą sąlyginiu.
Patikrinkite standartizuotų būsenų reikšmę
Jei integracijoje naudojate standartizuotas būsenas, palyginkite jas su pagrindiniu įvykio tekstu. Įsitikinkite, kad etiketės sukūrimas nesukelia fizinio išsiuntimo pranešimo, atvykimas į pristatymo centrą netampa būsena „pristatyta“, o nesėkmingas bandymas pristatyti neuždaro užsakymo kaip sėkmingai įvykdyto.
Taip pat patikrinkite atsiėmimo galimybę ir grąžinimo siuntėjui rezultatus, jei tai aktualu. Supaprastinta būsena gali padėti klientams suprasti eigą, tačiau pagalbos komandai gali reikėti pradinio aprašo, kad paaiškintų išimtį. Prieš kurdami pagal tai sąsają patvirtinkite, kokia informacija iš tikrųjų grąžinama.
Išmatuokite stebimą vėlavimą nepervertindami tikslumo
Atskirkite įvykio laiką, stebėjimo laiką ir programos apdorojimo laiką. Vežėjo įvykiui priskirta laiko žyma nebūtinai yra laikas, kada įvykis tapo prieinamas internete. Todėl lyginant įvykio laiką su API gavimo laiku gali susidėti keli vėlavimo šaltiniai.
Jei vežėją tikrinate periodiškai, žinote, kada pirmą kartą pastebėjote įvykį, o ne tikslų jo paskelbimo laiką. Užrašykite tikrinimo intervalą ir rezultatą pažymėkite kaip stebimą vėlavimą. Suvienodinkite laiko juostas ir išsaugokite pradines laiko žymas, kad būtų galima ištirti tariamas eiliškumo problemas.
5. Patvirtinkite integraciją paleidimo sąlygomis
Maršruto matomumo nepakanka, jei atnaujinimai neveikia jūsų programoje. Išbandykite atnaujinimo mechanizmą, kurį iš tikrųjų naudosite gamybinėje aplinkoje. Jei naudojate žiniatinklio kabliukais pagrįstas darbo eigas, išnagrinėkite dokumentuotą autentifikavimo, patvirtinimo, pakartotinių bandymų ir atkūrimo elgseną. Jei naudojate apklausą, patikrinkite leidžiamą užklausų dažnį ir kaip programa atsigauna po pertrūkių.
- Registracija: Atskirkite priimtą siuntą nuo atmestos užklausos ir nuo priimtos siuntos, kuri dar neturi įvykių.
- Pasikartojantys atnaujinimai: Įsitikinkite, kad pasikartojanti informacija nesiunčia pasikartojančių klientų pranešimų.
- Įvykių eiliškumas: Patikrinkite, kad vėliau gautas senesnis įvykis negrąžintų pristatytos siuntos į tranzito būseną.
- Galinio taško gedimas: Išbandykite laikiną priimančiosios sistemos sutrikimą ir dokumentuotą atkūrimo procesą.
- Pajėgumas: Palyginkite paleidimo prognozes ir piko apkrovas su taikomais registracijos bei užklausų limitais.
- Duomenų tvarkymas: Patvirtinkite, kurie laukai būtini, apribokite prieigą prie prisijungimo duomenų ir pasirūpinkite, kad tinkama komanda peržiūrėtų privatumo bei sutartinius reikalavimus.
Kartu su techninėmis prielaidomis patikrinkite ir komercines. Išsiaiškinkite, kas laikoma apmokestinamu naudojimu, kaip vertinamos pasikartojančios registracijos ir kas nutinka pasiekus limitus. Nemanykite, kad integracijos testui ar bandomajam laikotarpiui taikomos tokios pačios sąlygos kaip planuojamai gamybinei aplinkai.
6. Nustatykite išmatuojamus paleidimo kriterijus
Prieš vertindami rezultatus apibrėžkite priėmimo kriterijus. Priešingu atveju, artėjant paleidimo terminui, silpną testą lengva interpretuoti kaip pakankamą. Naudokite jūsų klientų pažadams ir operacinei rizikai tinkamas ribas, o ne nepaaiškintą pramonės rodiklį.
Naudingi rodikliai:
- Registracijos sėkmė: Sėkmingai priimtų galiojančių testinių siuntų ir galiojančių registracijos bandymų santykis.
- Sekimo prieinamumas: Testinių siuntų, turinčių tinkamus naudoti sekimo įvykius, ir tinkamų testinių siuntų santykis.
- Reikalingų etapų užfiksavimas: API grąžintų reikalingų etapų ir atitinkamuose atskaitos įrašuose stebėtų etapų santykis.
- Galutinio rezultato sutapimas: Tinkamų užbaigtų siuntų, kurių API rezultatas sutampa su atskaitos rezultatu, ir patikrintų tinkamų užbaigtų siuntų santykis.
- Stebimas atnaujinimo vėlavimas: Vėlavimų pasiskirstymas, išmatuotas taikant nurodytą stebėjimo metodą.
Pateikite neapdorotus skaičius kartu su procentais ir nurodykite išimtis. Nelaikykite aktyvios siuntos trūkstamu pristatymo rezultatu. Tyliai nepašalinkite neišspręstų sekimo sutrikimų. Jei rezultatus sveriate pagal prognozuojamą siuntų kiekį, taip pat pateikite atskirų maršrutų rezultatus, kad silpnas, bet svarbus maršrutas liktų matomas.
Naudokite keturias sprendimo būsenas: patikrinta, kai maršrutas atitinka sutartus testus; sąlyginė, kai žinoma spraga turi priimtą sprendimą; dar nepatikrinta, kai įrodymų nepakanka; ir patvirtinta kaip nepalaikoma, kai tiesioginis patvirtinimas arba nustatytas apribojimas leidžia padaryti tokią išvadą. Vien nepaaiškinta nesėkminga užklausa nėra pakankama paskutinei kategorijai.
7. Paleiskite su aiškiais atsarginiais sprendimais ir pakartotinės patikros kriterijais
Kiekvienam sąlyginiam maršrutui nurodykite atsakingą asmenį ir atsarginį sprendimą. Galimos parinktys: rankinis vežėjo patikrinimas, pagalbos eskalavimo procesas, kita siuntimo paslauga arba mažiau konkretūs pranešimai klientams. Venkite siųsti užtikrintus teiginius apie pristatymą, kai sekimo duomenys jų nepalaiko.
Pakartotinai tikrinkite, kai pasikeičia vežėjo paslauga, užsakymų įvykdymo partneris pakeičia maršrutą, atsiranda naujas paskutinės pristatymo grandies partneris arba stebėjimas atskleidžia trūkstamus rezultatus. Kartu saugokite patvirtintą matricą, testų įrodymus, neišspręstas problemas ir tiekėjų patvirtinimus. Įėjimo į rinką aprėptis turi likti operaciniu įrašu, o ne vienkartiniu pirkimų teiginiu.
DUK
Ar palaikomų vežėjų sąrašas įrodo, kad aprėpiamos visos paslaugos?
Ne. Naudokite jį galimai integracijai nustatyti, tada patikrinkite konkrečią paslaugą, maršrutą, identifikatoriaus reikalavimus ir galutinį pristatymo rezultatą. Jei vieša dokumentacija neatsako į šiuos klausimus, paprašykite tiesioginio patvirtinimo.
Ar aprėptį galime patvirtinti naudodami tik pristatytas siuntas?
Pristatytos siuntos padeda patikrinti istorinių įvykių išsamumą ir galutinius rezultatus. Jos neparodo, kaip greitai gaunami nauji įvykiai arba kaip jūsų sistema tvarko realaus laiko atnaujinimus. Prieš patvirtindami laiko atžvilgiu svarbią pranešimų darbo eigą įtraukite aktyvias siuntas.
Ką daryti, jei API negrąžina sekimo įvykių?
Patikrinkite užklausos rezultatą, vežėjo pasirinkimą, būtinus įvesties duomenis ir tai, ar pats vežėjas rodo įvykius. Atskirkite laukiančius duomenis nuo netinkamos registracijos ir patvirtinto palaikymo nebuvimo. Neišspręstus atvejus eskaluokite pateikdami sekimo numerį, užklausos duomenis, laiko žymas ir atskaitos įrodymus.
Ar kiekvienoje siuntoje turi būti rodomi muitinės įvykiai?
Nemanykite, kad kiekvienas maršrutas per siuntų sekimą pateikia muitinės etapus. Jei šie įvykiai būtini jūsų darbo eigai, patikrinkite juos konkrečiai ir apibrėžkite, kaip operacijų komanda reaguos, kai jų nėra. Trūkstama sekimo informacija savaime neįrodo muitinės problemos.
Ar galime pradėti veiklą, kol kai kurie maršrutai dar nepatikrinti?
Ribotas paleidimas gali būti pagrįstas, jei rizika suprasta, paveiktiems maršrutams patvirtinti atsarginiai sprendimai, o likusios patikros atsakomybė paskirta konkrečiam asmeniui. Viduje šių maršrutų nepateikite kaip patikrintų ir negrįskite klientų pažadų galimybėmis, kurios nebuvo pademonstruotos.
Šaltiniai
Naudokite šiuos oficialius išteklius, kad patikrintumėte produkto apimtį ir įgyvendinimo reikalavimus vertindami 17TRACK. Šiame vadove pateiktos testavimo procedūros ir paleidimo kriterijai yra operacinės rekomendacijos, o ne teiginiai apie garantuotą maršrutų aprėptį.
