Çindən Avropaya və ABŞ-a göndərişləri bir API ilə necə izləmək olar

Çindən Avropaya və ABŞ-a göndərişləri bir API ilə izləmək üçün sifariş sisteminizi çoxdaşıyıcılı izləmə xidmətinə qoşun, hər bağlamanı izləmə nömrəsi və tələb olunan daşıyıcı məlumatları ilə qeydiyyatdan keçirin və izləmə yeniləmələrini ortaq göndəriş qeydində birləşdirin. İnteqrasiya beynəlxalq təhvil-təslimləri, gecikmiş skanları və ayrıca son mərhələ izləmə nömrələrini nəzərə almalıdır. Bir API izləmə məlumatlarına çıxışı birləşdirə bilər, lakin daşıyıcının bildirmədiyi hadisələri yarada bilməz.

Proqramçılar və e-ticarət əməliyyatları komandaları üçün məqsəd sadəcə statusu göstərmək deyil. Məqsəd hər fiziki bağlamanı düzgün sifarişlə əlaqələndirmək, yanıltıcı yeniləmələr göndərmədən müştəriləri məlumatlandırmaq və müdaxilə tələb edən göndərişləri müəyyənləşdirməkdir. Bu təlimat həmin iş axınını necə qurmağı və 17TRACK Tracking API kimi bir xidməti real göndəriş marşrutlarınız əsasında necə qiymətləndirməyi izah edir.

Yalnız təyinat ölkəsi ilə deyil, göndəriş marşrutu ilə başlayın

Çindən Avropadakı və ya ABŞ-dakı ünvana gedən bağlama toplama xidmətindən, beynəlxalq nəqliyyat şəbəkəsindən, gömrük emalından və təyinat ölkəsinin çatdırılma daşıyıcısından keçə bilər. Bəzi göndəriş xidmətləri bu hərəkətləri bir izləmə nömrəsi altında göstərir. Digərləri isə səfərin sonrakı mərhələsində ayrıca çatdırılma istinadı təqdim edir.

Bu səbəbdən ölkə səviyyəsində əhatə dairəsi izləmə inteqrasiyasını təsdiqləmək üçün kifayət deyil. Təchizatçı daşıyıcını tanıya bilər, lakin müəyyən göndəriş məhsulu üçün lazım olan bütün hadisələri qaytarmaya bilər. Eyni şəkildə, mənşə skanı təyinat ölkəsində çatdırılma skanlarının mövcud olacağını təsdiq etmir.

İnteqrasiyadan əvvəl biznesinizin faktiki göndərdiyi bağlamalardan istifadə edərək marşrut inventarı yaradın. Mənşə logistika təchizatçısını, göndəriş xidmətini, təyinat bazarını, məlum çatdırılma daşıyıcısını və izləmə nömrəsi formatlarını qeyd edin. Test zamanı Avropa bazarlarını ayrı-ayrılıqda qiymətləndirin; bir ölkədə uğurlu çatdırılmanın bütün region üzrə əhatə dairəsini sübut etdiyini düşünməyin.

• Əməliyyatlar üçün: izləmə boşluqlarının hazırda harada əl əməyinə və ya müştəri müraciətlərinə səbəb olduğunu müəyyənləşdirin.
• Mühəndislik üçün: hansı sistemlərin göndəriş yaratdığını və hansı sistemlərin yeniləmələrə ehtiyac duyduğunu müəyyənləşdirin.
• Satınalma üçün: həmin marşrut inventarındakı konkret daşıyıcılar və xidmətlərə dəstəyin mövcudluğunu yoxlayın.

Bir izləmə API-si nə etməlidir və nə edə bilməz

Çoxdaşıyıcılı Tracking API tətbiqinizə hər daşıyıcı üçün ayrıca bağlantı idarə etmək əvəzinə ümumi inteqrasiya qatı təqdim edir. Xidmətdən və inteqrasiya üsulundan asılı olaraq tətbiqiniz yeniləmələri əldə edə, geri çağırışlar qəbul edə və ya hər iki üsuldan istifadə edə bilər. İstehsal iş axınını layihələndirməzdən əvvəl dəstəklənən mexanizmləri təchizatçının sənədlərində təsdiqləyin.

Faydalı abstraksiya ardıcıl göndəriş modelidir. Sifariş idarəetmə sisteminiz hər daşıyıcının ifadə tərzi üçün fərqli biznes məntiqinə ehtiyac duymamalıdır, lakin dəstək və araşdırma məqsədləri üçün ilkin məlumatı saxlamalıdır.

Birləşdirilmiş izləmə fasiləsiz fiziki görünürlüyə, çatdırılma təxmininə və ya tam gömrük tarixçəsinə zəmanət vermir. API bağlantısı işlək ola bilər, lakin daşıyıcının bildirəcəyi yeni skan olmaya bilər. İzləmə həmçinin göndəriş etiketlərinin alınmasından, gömrük bəyannamələrinin hazırlanmasından və çatdırılma xidmətlərinin təşkilindən ayrıdır. Bu funksiyaların daxil olduğunu düşünməyin.

İnteqrasiyanı bağlama səviyyəsində qeyd ətrafında qurun

1. Sifarişləri, göndərişləri və izləmə identifikatorlarını ayırın

Bir e-ticarət sifarişində bir neçə bağlama ola bilər və bu bağlamalar müxtəlif vaxtlarda çata bilər. Sabit identifikator kimi daxili bağlama və ya göndəriş ID-sindən istifadə edin. Müştərinin sifarişini həmin qeydlə əlaqələndirin, sonra daşıyıcının izləmə identifikatorlarını ona əlavə edin.

Praktik daxili modelə aşağıdakılar daxil edilməlidir:

• Daxili sifariş ID-si və bağlama ID-si.
• İlkin izləmə nömrəsi və API tərəfindən istifadə olunan daşıyıcı identifikatoru.
• Təsdiqlənmiş təyinat daşıyıcısının izləmə nömrəsi.
• Göndəriş xidməti və təyinat ölkəsi.
• Cari normallaşdırılmış status və daşıyıcının ilkin təsviri.
• Hadisə vaxtı, təqdim edildikdə hadisə yeri və sisteminizin yeniləməni qəbul etdiyi vaxt.
• Qeydiyyat vəziyyəti, son uğurlu sinxronizasiya və həll edilməmiş inteqrasiya xətaları.

Bunlar tövsiyə olunan tətbiq sahələridir və hər təchizatçının bunların hamısını qaytardığı iddia edilmir. Daxili sxeminizi təchizatçının cavab formatından ayrı saxlayın ki, gələcək API dəyişikliyi sifariş bazasının yenidən layihələndirilməsini tələb etməsin.

2. Bağlamaları etibarlı biznes hadisəsi əsasında qeydiyyatdan keçirin

İzləmə nömrəsi bağlamaya təyin edildikdə qeydiyyat aparın; kimsə sifariş səhifəsinə baxdıqda deyil. Anbarınızdan və ya sifariş sisteminizdən gələn göndəriş yaradıldı hadisəsi adətən daha yaxşı başlanğıc nöqtəsidir. Etiket ləğv edilərsə və ya dəyişdirilərsə, tərk edilmiş nömrəni yeganə izləmə istinadı kimi saxlamaq əvəzinə bağlamanın identifikator əlaqələrini yeniləyin.

Nömrənin mövcud olduğunu və cədvəl formatlaşdırması nəticəsində zədələnmədiyini yoxlayın. Mənalı başlanğıc sıfırlarını qoruyun. Göndəriş sisteminiz daşıyıcını bilirsə, bu məlumatı saxlayın və tamamilə avtomatik identifikasiyaya etibar etməyin: nömrə formatları üst-üstə düşə bilər.

Qeydiyyat cavabını hər bir göndəriş səviyyəsində oxuyun. Uğurlu HTTP sorğusu paketdəki hər elementin qəbul edildiyini göstərmir. Uğursuzluqları təkrar cəhd növbəsində saxlayın və əməliyyat komandasına etibarsız və ya qeyri-müəyyən təqdimatları həll etmək imkanı verin.

3. Müştəri bildirişlərini qoşmazdan əvvəl yeniləmələrin çatdırılmasını layihələndirin

Seçilmiş xidmət webhooks dəstəkləyirsə, yeniləmələri qəbul etmək üçün onun sənədləşdirilmiş geri çağırış mexanizmindən istifadə edin. Təsdiqləmə və ya imza üsulunu özünüz yeni başlıq yaratmaq əvəzinə yoxlayın. Etimadnamələri serverdə saxlayın, HTTPS tələb edin və API sirlərini brauzer koduna və ya müştəriyə açıq keçidlərə daxil etməyin.

Qəbulediciniz yeniləməni təsdiqləməzdən əvvəl onu etibarlı şəkildə qəbul etməli, sonra isə asinxron emal etməlidir. Təkrar çatdırılmalar və ardıcıllıqdan kənar gələn hadisələr üçün layihələndirin. Mümkün olduqda təchizatçının hadisə ID-sindən istifadə edin; əks halda sabit hadisə atributlarından istifadə edən sənədləşdirilmiş təkrarların qarşısının alınması qaydası müəyyənləşdirin.

Əgər sorğu ilə yoxlama tələb olunursa, onu təchizatçının sənədləşdirilmiş limitləri və əməliyyat ehtiyaclarınız daxilində planlaşdırın. Rate-limit cavablarından sonra fasiləni artırın, sinxronlaşdırılmış təkrar cəhd sıçrayışlarından qaçın və saxlama və uzlaşdırma siyasətinizə uyğun olaraq tamamlanmış göndərişlər üzrə lazımsız yoxlamaları dayandırın. Planlaşdırılmış uzlaşdırma işi xidmət əldə etməyə icazə verdikdə buraxılmış yeniləmələri də aşkar etməyə kömək edə bilər.

4. Mənanı itirmədən statusları normallaşdırın

Sifariş sisteminizin və dəstək komandanızın ardıcıl şəkildə şərh edə biləcəyi az sayda daxili statusdan istifadə edin. Nümunələrə məlumat alındı, tranzitdədir, çatdırılma üçün yoldadır, çatdırıldı, çatdırılma istisnası və qaytarıldı daxildir. Bunlar təklif olunan tətbiq kateqoriyalarıdır, hər hansı təchizatçının dəqiq status kodlarının təsviri deyil.

Ətraflı daşıyıcı hadisəsini normallaşdırılmış statusla birlikdə saxlayın. Uğursuz çatdırılma cəhdi, ünvan problemi və gömrüklə bağlı gecikmə diqqət tələb edə bilər, lakin eyni cavabı tələb etmir. Hər şeyi ümumi istisnaya çevirmək məlumatın saxlanmasını asanlaşdırar, lakin ondan istifadəni çətinləşdirər.

Etiket yaradılmasını fiziki götürülmə kimi tərcümə etməyin. Eyni şəkildə, hadisədə gömrük obyekti qeyd olunduğuna görə bağlamanı gömrükdən keçmiş kimi göstərməyin. Hadisənin faktiki mənasına uyğun dildən istifadə edin.

Beynəlxalq təhvil-təslimləri açıq şəkildə idarə edin

Ən vacib inteqrasiya testi çox vaxt mənşə şəbəkəsi ilə təyinat ölkəsinin çatdırılma şəbəkəsi arasındakı keçiddir. Həm ilkin istinadı, həm də təsdiqlənmiş son mərhələ istinadını qoruyun. Yeni izləmə nömrəsi eyni bağlama üçün əlavə identifikator olmalıdır; avtomatik olaraq ikinci göndəriş hesab edilməməlidir.

İdentifikatorları yalnız logistika təchizatçısı, izləmə cavabı və ya göndəriş sisteminiz kimi etibarlı mənbədən gələn əlaqə olduqda birləşdirin. Oxşar hadisə vaxtları və ya eyni təyinat ölkələri iki nömrənin eyni bağlamaya aid olduğunu sübut etmir.

Hadisə vaxtını qəbul vaxtından ayrı saxlayın. Xüsusilə məlumat şəbəkələr arasında hərəkət etdikdə köhnə hadisə sisteminizə daha yeni hadisədən sonra çata bilər. Təqdim edilmiş saat qurşağı ofsetlərini qoruyun, vaxt damğalarını emal üçün normallaşdırın və dəstəklənməyən saat qurşağı təyin etmək əvəzinə qeyri-müəyyən mənbə dəyərlərini saxlayın.

Müştərilər üçün görünən yeniləmə vaxtı ilə ən son mənalı statusu göstərin. Təyinat daşıyıcısı hələ skan bildirməyibsə, izləmənin başqa yeniləməni gözlədiyini izah edin. Bağlamanın itdiyini, son skan yerində fiziki olaraq qaldığını və ya artıq təyinat ölkəsində olduğunu ehtimal etməyin.

17TRACK bu iş axınında hansı rolu oynayır

17TRACK-in Tracking API təklifi tətbiqiniz çoxdaşıyıcılı izləmə inteqrasiyasına ehtiyac duyduqda uyğundur. Onun rəsmi API sənədləri autentifikasiya, qeydiyyat, cavabların emalı və dəstəklənən yeniləmə iş axınlarının tətbiqinə rəhbərlik etməlidir. İstehlakçı izləmə səhifəsini inteqrasiya interfeysi hesab etmək əvəzinə sənədləşdirilmiş API müqaviləsindən istifadə edin.

Onu öz tətbiqinizə tətbiq edəcəyiniz eyni əməliyyat tələbləri ilə qiymətləndirin: düzgün daşıyıcı identifikasiyası, marşrutlarınız üzrə faydalı hadisələr, təhvil-təslim davamlılığı, xətalardan bərpa və idarəolunan yeniləmə çatdırılması. İstehsal dizaynına başlamazdan əvvəl kommersiya şərtlərini, istifadə hesablamasını, sorğu limitlərini və tələb olunan hesab konfiqurasiyasını təsdiqləyin.

Birləşdirilmiş API seçməyin əsas səbəbi faktiki idarə etdiyiniz marşrutlar üçün inteqrasiya mürəkkəbliyinin azalmasıdır. Bu üstünlük hələ də real bağlamalarla təsdiqlənməlidir. Heç bir təchizatçı yalnız ümumi əhatə dairəsi təsvirinin geniş səslənməsinə görə seçilməməlidir.

Tətbiqdən əvvəl marşrut əsaslı pilot həyata keçirin

Normal çatdırılmaları və çətin halları əhatə edən test dəstindən istifadə edin. Tarixi göndərişlər status xəritələndirməsini sınamağa kömək edir, canlı göndərişlər isə yeniləmələrin çatdırılmasını və əməliyyat vaxtlamasını göstərir. Bu testlərin heç biri təkbaşına bütün suallara cavab vermir.

• Çindən ABŞ-a çatdırılma: mənşə hadisələrini, mümkün beynəlxalq təhvil-təslimi və son çatdırılma hadisəsini yoxlayın.
• Çindən Avropaya çatdırılmalar: faktiki istifadə etdiyiniz təyinat ölkələrini və göndəriş xidmətlərini test edin.
• Yeni etiket: fiziki skanı olmayan bağlamanın hərəkətdə kimi göstərilmədiyini təsdiqləyin.
• Dəyişdirilmiş çatdırılma istinadı: əlaqənin düzgün bağlamaya aid olaraq qalmasını təsdiqləyin.
• Çatdırılma istisnası: ətraflı səbəbin müvafiq əməliyyat növbəsinə çatdığını yoxlayın.
• Bölünmüş sifariş: bir bağlamanın çatdırılmasının bütün sifarişi bağlamadığını təsdiqləyin.
• Təkrar və ya gecikmiş yeniləmə: bunun təkrar mesajlar yaratmadığını və daha yeni statusu səhvən əvəz etmədiyini təsdiqləyin.
• Müvəqqəti inteqrasiya xətası: təkrar cəhd, uzlaşdırma və dəstək görünürlüğünü yoxlayın.

Nəticələri nəzərdən keçirməzdən əvvəl qəbul meyarlarını müəyyənləşdirin. Qeydiyyat uğurunu, səhv daşıyıcı təyinatlarını, çatışmayan mərhələləri, yeniləmələrin emal gecikmələrini və təkrar müştəri mesajlarını ölçün. Dəstəklənməyən universal göstəricini götürmək əvəzinə biznesiniz üçün məqbul hədlər müəyyənləşdirin. Çatışmayan hadisəni API-yə aid etməzdən əvvəl onu daşıyıcının öz qeydi ilə müqayisə edin.

Məlumatın yeniliyini API əlçatanlığından ayrıca izləyin

API Monitoring iki fərqli suala cavab verməlidir: inteqrasiya işləyirmi və göndəriş məlumatı faydalıdırmı? Uğurlu sorğular yalnız birinci suala cavab verir. Həmçinin qeydiyyatların səhvlərlə yığılıb-yığılmadığını, geri çağırışların uğursuz olub-olmadığını və ya marşrutun gözlənilən mərhələləri artıq yaratmadığını bilməlisiniz.

• İnteqrasiya sağlamlığı: autentifikasiya uğursuzluqları, sorğu xətaları, rate-limit cavabları, geri çağırış uğursuzluqları və növbə yığımları.
• Məlumat keyfiyyəti: naməlum statuslar, səhv formatlı vaxt damğaları, həll edilməmiş daşıyıcı identifikasiyaları və gözlənilməz identifikator dəyişiklikləri.
• Göndərişin yeniliyi: marşrut və göndəriş xidmətinə görə bölünmüş son daşıyıcı hadisəsindən keçən vaxt.
• Biznes təsiri: istisna iş yükü, uğursuz bildirişlər və səhvən tamamlanmış kimi işarələnən sifarişlər.

Skan olmadan uzun müddət qalmaq bir göndəriş xidmətində normal, digərində isə qeyri-adi ola bilər. Araşdırmalara üstünlük vermək üçün marşruta xas gözləntilərdən və müşahidə edilmiş göndəriş tarixçəsindən istifadə edin. İnteqrasiya xətası xəbərdarlığını göndəriş gecikməsi xəbərdarlığından ayrı saxlayın ki, bildirişi düzgün komanda alsın.

Müştəri bildirişləri hər xam hadisəni deyil, təsdiqlənmiş mərhələləri izləməlidir. Təkrarları susdurun, çatdırılma cəhdini tamamlanmış çatdırılmadan fərqləndirin və əsas məlumatın dəstəkləmədiyi gəliş tarixlərinə söz verməyin. İzləmə məlumatlarına çıxışı məhdudlaşdırın və şəxsi məlumatları yalnız iş axınınızın tələb etdiyi hallarda saxlayın.

FAQ

Bir API həm Çin mənşəli daşıyıcını, həm də təyinat ölkəsinin çatdırılma daşıyıcısını izləyə bilərmi?

Çoxdaşıyıcılı xidmət müvafiq xidmətlər və identifikator əlaqələri dəstəkləndikdə səfərin hər iki hissəsindən hadisələri birləşdirə bilər. Tam marşrutu real bağlamalarla təsdiqləyin. Mənşə izləmə nömrəsinin tanınması təkbaşına təyinat çatdırılma məlumatının əlçatan olacağını sübut etmir.

Bağlama Çindən çıxdıqdan sonra izləmə niyə yenilənməyi dayandırır?

Mümkün səbəblərə fiziki skanlar arasındakı boşluq, gecikmiş hesabat və ya başqa çatdırılma istinadına təhvil verilmə daxildir. Xam hadisələri və təqdim edilmiş son mərhələ nömrəsini yoxlayın, sonra müvafiq daşıyıcının qeydi ilə müqayisə edin. İzləmə boşluğu özü bağlamanın itdiyini və ya gömrükdə saxlanıldığını göstərmir.

Tətbiq webhooks-dan, yoxsa sorğu ilə yoxlamadan istifadə etməlidir?

Təchizatçınızın sənədləşdirdiyi mexanizmlərdən istifadə edin. Dəstəkləndikdə webhooks təkrar yoxlamaları azalda bilər, icazə verilən əldəetmə sorğuları isə uzlaşdırmanı dəstəkləyə bilər. Hər iki dizaynda müştəri kommunikasiyaları üçün yeniləmələrə etibar etməzdən əvvəl təkrarların idarə edilməsini, təkrar cəhd nəzarətini və monitorinqi qurun.

İzləmə API-si çatdırılma tarixinə və ya gömrük rəsmiləşdirilməsinə zəmanət verə bilərmi?

İzləmə məlumatları bunların heç birinə zəmanət vermir. Təxmini çatdırılma tarixi təqdim edilirsə, onun mənbəyini qoruyun və onu təxmin kimi göstərin. Gömrüklə bağlı skanları faktiki ifadələrinə uyğun təsvir edin; açıq şəkildə bu nəticəni göstərmədikcə onları rəsmiləşdirmə kimi şərh etməyin.

API planını seçməzdən əvvəl nə yoxlanılmalıdır?

Daşıyıcılarınızı və göndəriş xidmətlərinizi, qeydiyyat tələblərini, yeniləmə üsullarını, istifadə hesablamasını, sorğu limitlərini, məlumat əlçatanlığını və dəstək şərtlərini təsdiqləyin. Əvəzləyici nömrələrin, təkrar qeydiyyatların və tarixi axtarışların kommersiya baxımından necə idarə olunduğunu soruşun. Büdcənizə və ya arxitekturanıza təsir edən tələblər üçün cari sənədlərdən və yazılı təsdiqdən istifadə edin.

Mənbələr

• 17TRACK Tracking API — izləmə API təklifi üçün rəsmi məhsul istinadı.
• 17TRACK API documentation — inteqrasiyanın tətbiqi üçün rəsmi texniki istinad. İnkişafdan əvvəl dəqiq sorğu formatlarını, dəstəklənən iş axınlarını və limitləri burada təsdiqləyin.