Hogyan egységesítheti a küldeménykövetést Ausztráliában és Új-Zélandon egyetlen API-val

Ausztrália és Új-Zéland szállítmánykövetésének egyetlen API-val történő egységesítéséhez csatlakoztassa rendelési vagy teljesítési rendszerét egy többfuvarozós követési szolgáltatáshoz, regisztráljon minden szállítmányt a megfelelő fuvarozói azonosítóval, és alakítsa át a beérkező követési frissítéseket egységes belső eseménymodellé. Az integrációnak meg kell őriznie a fuvarozóspecifikus részleteket, miközben a működési csapat és az ügyfelek számára egységes követési élményt biztosít a belföldi és a Tasman-tengeren átnyúló kézbesítésekhez.

A fejlesztők, e-kereskedelmi üzemeltetők és logisztikai csapatok számára a fő kihívást nem az első API-kérés elküldése jelenti. Hanem annak biztosítása, hogy a szállítmányazonosítók, kézbesítési állapotok, fuvarozói átadások és ügyfélértesítések konzisztensek maradjanak akkor is, amikor a különböző fuvarozók eltérően írják le ugyanazt az útvonalat. Ez az útmutató bemutatja, hogyan tervezhető meg ez az integráció, hogyan értékelhető egy követési API, és hogyan tesztelhető az éles használat előtt.

Határozza meg, mit kell az egyetlen API-nak egységesítenie

A megosztott API közös integrációs pontot biztosít az alkalmazás számára. Nem teszi azonban azt, hogy minden fuvarozó azonos információkat tegyen közzé, vagy azonos gyakorisággal szkennelje a csomagokat. Az architektúrának különbséget kell tennie a konzisztens interfész és a teljes átláthatóság között.

Kezdje a tényleges teljesítési tevékenységen alapuló szállítmányjegyzékkel, ne az adott országokban működő fuvarozók általános listájával. Vegye fel az ausztrál belföldi szállítmányokat, az új-zélandi belföldi szállítmányokat, valamint a mindkét irányú határokon átnyúló mozgásokat. Adjon hozzá más nemzetközi feladási helyeket is, ha azok a vállalkozása részét képezik.

• Fuvarozó és szolgáltatás: Rögzítse a fuvarozót, az igénybe vett szolgáltatást és minden ismert kézbesítési partnert.
• Útvonal: Különböztesse meg a szállítmány feladási és célállomását a legutóbbi szkennelés helyétől.
• Azonosítók: Rögzítse a rendelési hivatkozást, a teljesítési hivatkozást, a követési számot, valamint minden helyettesítő vagy partneri számot.
• Működési cél: Határozza meg, hogy a frissítések az ügyfélkövetést, a kivételkezelést, a kézbesítés megerősítését vagy mindhárom területet támogatják-e.
• Szükséges részletesség: Döntse el, hogy elegendő-e egy általános kézbesítési állapot, vagy az ügyintézőknek szükségük van a szkennelések leírására, helyére és időbélyegére is.

Ez a jegyzék lesz az elfogadási ellenőrzőlista. A szolgáltató általános fuvarozói lefedettsége hasznos a szűkítéshez, de a döntést annak kell meghatároznia, hogy a tényleges fuvarozó-szolgáltatás kombinációi használható követési információkat adnak-e vissza.

Értékelje a követési API-t a szállítmányösszetétele alapján

A 17TRACK Tracking API-t kínál, ezért releváns lehetőségként érdemes megvizsgálni egy többfuvarozós integrációhoz. A jelenlegi integrációs követelmények ellenőrzéséhez használja a hivatalos API-dokumentációt. A fuvarozói támogatást, az eseménymezőket, a frissítési viselkedést, a fiókkorlátokat és a kereskedelmi feltételeket olyan tényezőkként kezelje, amelyeket az implementációhoz ellenőrizni kell, ne pedig a termékkategóriából levezetett feltételezésekként.

Tegye fel ugyanazokat a gyakorlati kérdéseket minden megfontolt API-val kapcsolatban:

• Azonosítani és követni tudja a szállítmányjegyzékében szereplő fuvarozókat és szolgáltatásokat?
• Ha a fuvarozó észlelése bizonytalan, megadhat kifejezett fuvarozói azonosítót?
• Hogyan kapja meg az alkalmazás a frissítéseket, és milyen helyreállítási mechanizmus áll rendelkezésre, ha egy frissítés kimarad?
• Mely eredeti fuvarozói részletek maradnak elérhetők a normalizált állapotok mellett?
• Mi történik, ha a követési szám érvénytelen, még nem ismert, vagy egynél több lehetséges fuvarozóhoz kapcsolódik?
• Hogyan határozzák meg a használatot, a számlázást, a követés időtartamát és a fiók hozzáférési korlátait?

Javasolt döntési szabály: a valós szállítási minták sikeres tesztjei alapján válasszon, ne a hirdetett fuvarozói szám nagysága alapján. Egy integráció akkor megfelelő, ha elegendő információt biztosít a működési döntések támogatásához, és a hibákat elég egyértelműen jelzi ahhoz, hogy helyre lehessen állítani a működést.

Építsen a fuvarozói különbségeket átvészelő belső modellt

Különítse el a rendeléseket, szállítmányokat és követési szakaszokat

Ne használja a követési számot a rendelés elsődleges kulcsaként. Egy rendelés több csomagot is tartalmazhat, és egy csomag útja egynél több követési azonosítót is érinthet. Ehelyett hozzon létre belső szállítmányazonosítót, és kapcsolja hozzá a követési rekordokat.

Egy gyakorlati modell három szintből áll: az ügyfél rendeléséből, annak fizikai szállítmányaiból és az egyes szállítmányokhoz tartozó követési szakaszokból. Egy belföldi csomaghoz elegendő lehet egyetlen követési szakasz. Egy határokon átnyúló csomaghoz kapcsolt rekordokra lehet szükség, amikor egy másik fuvarozó vagy azonosító válik relevánssá.

A követési rekord hatókörét a fuvarozó és a követési szám együttesével határozza meg, és őrizze meg a szállítmányazonosítóhoz fűződő kapcsolatát. Ha új kézbesítési partneri szám jelenik meg, adja hozzá kapcsolódó azonosítóként az eredeti felülírása helyett. Így megmarad az az előzmény, amelyre az ügyintézőknek szükségük van az átadás kivizsgálásakor.

Őrizzen meg nyers és normalizált eseményt is

Használjon olyan kis belső állapot-szókincset, amely alapján a vállalkozása cselekedni tud. Például meghatározhatja az indulás előtti, szállítás alatt, kézbesítés alatt, átvételre elérhető, kézbesítve, kivétel és ismeretlen állapotokat. Ezek javasolt belső kategóriák, nem pedig egy adott szolgáltató állapotsémájára vonatkozó állítások.

Tárolja az eredeti fuvarozói leírást a hozzárendelt állapot mellett. Egy átvételi ponttal kapcsolatos esemény és egy címprobléma egyaránt ügyfélbeavatkozást igényelhet, de nem szabad ugyanazt az üzenetet kiváltaniuk. Hasonlóképpen a címke létrehozása sem jelentheti automatikusan azt, hogy a fuvarozó fizikailag birtokba vette a csomagot.

Dokumentálja a hozzárendelési döntéseket verziózott konfigurációban. Ha új eseményleírás jelenik meg, helyezze felülvizsgálati sorba, ha a jelentése nem egyértelmű. A kifejezett ismeretlen állapot biztonságosabb, mint a téves kézbesítési eredmény magabiztos hozzárendelése.

Különböztesse meg az esemény és a fogadás időpontját

Az esemény bekövetkezésének időpontját külön tárolja attól az időponttól, amikor a rendszer megkapta azt. Egy régebbi szkennelés az újabb után is beérkezhet, különösen akkor, ha a frissítések késnek, vagy az előzményeseményeket együtt küldik el.

Ausztrália és Új-Zéland esetében ne alkalmazzon egyetlen rögzített időeltolást minden szállítmányra. Őrizze meg a forrás időbélyegeit és az eltolásokat, ha rendelkezésre állnak. Megbízható helyinformáció esetén használjon megfelelő, név szerinti időzónát a megjelenítéshez, és vegye figyelembe a nyári időszámítás különbségeit. Ha a forrás időzónája hiányzik, őrizze meg ezt a bizonytalanságot, és ne találjon ki pontos UTC-átváltást.

Valósítson meg megbízható adatbeviteli munkafolyamatot

1. Először hozza létre a belső szállítmányt. A követési szolgáltatónál történő regisztráció előtt rögzítse a rendeléskapcsolatot, az útvonalat, a fuvarozó kiválasztását és a követési azonosítót.
2. Küldje el a követési regisztrációt. Használja a szolgáltató dokumentált kérésformátumát. Tárolja a választ, és különböztesse meg a sikeres regisztrációt a fuvarozói események későbbi elérhetővé válásától.
3. Osztályozza a hibákat. Válassza külön az érvénytelen bemenetet és a hitelesítési problémákat az ideiglenes szolgáltatáshibáktól. Csak akkor próbálkozzon újra, ha az újrapróbálkozás ésszerűen segíthet.
4. Fogadja vagy kérje le a frissítéseket. Valósítsa meg a választott API által támogatott kézbesítési mechanizmust. Webhookok használata esetén érvényesítse a beérkező kéréseket a szolgáltató dokumentált módszerével, és a elfogadott eseményeket tartós soron keresztül dolgozza fel.
5. Az alkalmazás előtt szűrje ki a duplikátumokat. Ha lehetséges, használjon szolgáltatói eseményazonosítót, vagy gondosan megtervezett összetett kulcsot. Az ismételt kézbesítés nem válthat ki ismételt ügyfélértesítéseket.
6. Számítsa újra a szállítmány állapotát. Az esemény jelentését és időrendjét értékelje, ahelyett hogy az aktuális állapotot az utolsóként beérkezett frissítéssel cserélné le.
7. Egyeztesse a hiányos rekordokat. Ha az API támogatja a lekérést, használja azt a kimaradt frissítések vagy az elavult rekordok vizsgálatára az alkalmazandó használati korlátokon belül.

A szolgáltatóspecifikus hitelesítést, mezőneveket és hibakezelést adapterben tartsa. A rendeléskezelő rendszernek a belső szállítmánymodellt kell használnia, nem pedig közvetlenül a szolgáltatói válasz minden részletétől függnie. Ez az elkülönítés a későbbi API-módosítások tesztelését is megkönnyíti.

Kezelje a Tasman-tengeren átnyúló útvonalakat bizonyosság kitalálása nélkül

A határokon átnyúló követéshez több kontextusra van szükség, mint az állapotcímkék sorozatára. Az alkalmazásnak meg kell különböztetnie az exporteseményt, a vámhoz kapcsolódó eseményt, a fuvarozói átadást és a végső kézbesítési eseményt, amikor a forrásadatok támogatják ezeket a különbségeket.

Ne következtessen vámkezelésre egy általános, szállítás alatti szkennelésből. Hasonlóképpen a közelmúltbeli szkennelés hiánya sem bizonyítja, hogy a vám tartja vissza a csomagot. A hasznos ügyfélüzenet közli a legutóbbi megerősített eseményt és annak időpontját, majd ismerteti az esetleges következő lépést, amelyet a csapata ténylegesen támogatni tud.

A feladási és célállomást tartsa külön a szkennelés helyétől. Egy Ausztráliából Új-Zélandra tartó szállítmány nem válik új-zélandi belföldi szállítmánnyá pusztán azért, mert érkezési szkennelést kapott. Ez a különbség fontos az útvonaljelentések és a kivételek felelősségének meghatározása szempontjából.

Ha kézbesítési partner kapcsolódik be, csak akkor kapcsolja hozzá a követési rekordját, ha a kapcsolatot szállítmányadat, a követési szolgáltatás vagy működésileg ellenőrzött rekord támasztja alá. Ne egyesítsen csomagokat pusztán azért, mert az azonosítók hasonlónak tűnnek.

Alakítsa a követési eseményeket hasznos ügyfélfrissítésekké

Az ügyféloldali oldalnak négy kérdésre kell választ adnia: mi a legutóbbi megerősített állapot, mikor történt, hol rögzítették, ha ez ismert, és szükséges-e az ügyfélnek intézkednie?

Tartsa külön az értesítési szabályokat az események bevitelétől. Nem minden szkennelés érdemel e-mailt vagy szöveges üzenetet. Határozzon meg jelentős átmeneteket, például az első megerősített mozgást, a kézbesítési kísérletet, az átvételi kötelezettséget vagy a kézbesített eseményt, és szűrje ki ugyanazon átmenet ismételt riasztásait.

• Elavult követés: Jelezze, mikor történt az utolsó frissítés, de ne kezelje a csendet az elvesztés bizonyítékaként.
• Kézbesítési becslések: Különböztesse meg a fuvarozó által biztosított becslést a kereskedő ígéretétől. Ne gyártson dátumot, ha egyik sem áll rendelkezésre.
• Kivételek: Ha ismert, adjon konkrét következő lépést a megmagyarázatlan hibacímke megjelenítése helyett.
• Kézbesítési viták: Őrizze meg a forráseseményt, és irányítsa az esetet a támogatási csapathoz; a kézbesített állapot önmagában nem old meg minden ügyfélvitát.

Védje a követési oldalakat és az API-hitelesítő adatokat is. Kerülje a szükségtelen cím- vagy kapcsolattartási adatok megjelenítését, a szolgáltatási hitelesítő adatokat a szerveren tárolja, és a megjelenített információkhoz megfelelő hozzáférés-vezérlést alkalmazzon.

Futtasson útvonalalapú pilotot a bevezetés előtt

Tesztelje az ausztrál belföldi, az új-zélandi belföldi, az Ausztráliából Új-Zélandra, valamint az Új-Zélandról Ausztráliába tartó szállítmányokat, amennyiben ezek az útvonalak relevánsak vállalkozása számára. Vegyen fel normál kézbesítéseket és működési szélső eseteket is: megosztott rendeléseket, fel nem ismert számokat, átadásokat, kézbesítési kísérleteket, átvételi eseményeket, visszaküldéseket és későn beérkező szkenneléseket.

A fuvarozói ellenőrzéshez megfelelő engedéllyel rendelkező valós szállítmányrekordokat használjon. Saját alkalmazása ellenálló képességének teszteléséhez használjon szintetikus eseményeket, de a szintetikus eredményeket ne tekintse az éles fuvarozói lefedettség bizonyítékának.

• Identitásellenőrzés: Minden frissítés a megfelelő szállítmányhoz és rendeléshez jut el.
• Időrendi ellenőrzés: A sorrenden kívüli események nem fordítják vissza helytelenül a kézbesítés előrehaladását.
• Helyreállítási ellenőrzés: Az ideiglenes hibák és a duplikált frissítések nem okoznak adatvesztést vagy ismételt riasztásokat.
• Támogatási ellenőrzés: Az ügyintézők meg tudják vizsgálni az eredeti eseményt, és megértik az ügyfél felé megjelenített állapotot.
• Kereskedelmi ellenőrzés: A várható használat illeszkedik a fiók ellenőrzött számlázási modelljéhez és korlátaihoz.

A pilot értékelése előtt állítson be elfogadási küszöbértékeket. Mérje a regisztrációs eredményeket, a hozzá nem rendelt eseményeket, a feldolgozási késéseket, a duplikált értesítéseket és a megoldatlanul elavult szállítmányokat. Válassza külön a fuvarozói adatok késését a saját alkalmazásán belüli késésektől, hogy a helyreállítás a megfelelő felelőshöz jusson.

Az implementáció akkor áll készen, amikor a csapata meg tudja magyarázni és helyre tudja állítani a hiányos követést, nem csupán meg tudja jeleníteni a sikeres kézbesítéseket. Egyetlen API egyszerűsíti a kapcsolódást; a szállítmánymodell, az eseményszabályok és a működési eljárások teszik ezt a kapcsolatot megbízhatóvá.

GYIK

Egyetlen követési API helyettesíti a fuvarozói szállítási integrációkat?

Nem feltétlenül. A követés, a címkelétrehozás, a felvétel lefoglalása, a díjszámítás és a vámokmányok külön funkciók. Ellenőrizze a kiválasztott termék hatókörét, és tartsa meg az egyéb integrációkat ott, ahol a teljesítési folyamatnak szüksége van rájuk.

Regisztrálhatok egy követési számot az első fuvarozói szkennelés előtt?

Ellenőrizze az API regisztrációs szabályait. Úgy tervezze meg az alkalmazást, hogy különbséget tegyen az elfogadott követési regisztráció és a megerősített fizikai mozgás között. Egy esemény nélküli rekordot nem szabad automatikusan szállítás alatt állóként megjeleníteni.

Egyetlen API valós idejű frissítéseket biztosít minden fuvarozóhoz?

Ne feltételezze ezt. A teljes folyamat frissessége attól függ, mikor teszi közzé az adatokat a fuvarozó, mikor szerzi meg azokat a követési szolgáltatás, és mikor dolgozza fel őket az alkalmazás. Erősítse meg a használni kívánt fuvarozó-szolgáltatás kombinációk frissítési viselkedését.

Mi történjen, ha a követési szám megváltozik?

Őrizze meg az eredeti azonosítót, és kapcsolja az ellenőrzött helyettesítő vagy partneri azonosítót ugyanahhoz a belső szállítmányhoz. Őrizze meg mindkét előzményt, és akadályozza meg, hogy a duplikált rekordok egymásnak ellentmondó értesítéseket generáljanak.

Releváns a 17TRACK ehhez az integrációhoz?

Igen. A Tracking API releváns a jelen útmutatóban ismertetett többfuvarozós integrációhoz. Értékelje ausztrál és új-zélandi szállítmánymintáival, és a bevezetés előtt erősítse meg a fuvarozói támogatást, a technikai viselkedést és a fiókfeltételeket a hivatalos API-forrásokon keresztül.

Források

• 17TRACK Tracking API — az útmutatóban tárgyalt API-lehetőség hivatalos termékforrása.
• 17TRACK API documentation — hivatalos technikai referencia a kérésformátumok, az integrációs követelmények és a támogatott működés ellenőrzéséhez.