Cənub-Şərqi Asiyada bir neçə ölkəyə çatdırılmalar üçün izləmə API-sini necə seçmək olar

Başlıqda göstərilən daşıyıcı saylarını müqayisə etməklə deyil, real göndərmə marşrutlarınızı, daşıyıcılararası təhvil proseslərini və istisna iş axınlarınızı sınaqdan keçirərək Cənub-Şərqi Asiya üçün izləmə API-si seçin. Düzgün API beynəlxalq və daxili çatdırılma mərhələləri üzrə göndəriş hadisələrini əlaqələndirməli, faydalı daşıyıcı məlumatlarını saxlamalı və sistemlərinizin etibarlı şəkildə emal edə biləcəyi yeniləmələri təqdim etməlidir. Qərarınızın əsasını marşrut səviyyəsində performans, inteqrasiyanın dayanıqlılığı və ümumi əməliyyat xərcləri təşkil etsin.

Bu bələdçi elektron ticarət əməliyyatları komandaları və onları dəstəkləyən tərtibatçılar üçündür. Praktiki məqsəd hər bir göndərmə tərəfdaşı üçün ayrıca inteqrasiya yaratmadan daşıyıcı izləmə məlumatlarını etibarlı müştəri yeniləmələrinə və əməli tədbir tələb edən çatdırılma istisnalarına çevirməkdir.

Regional əhatə iddiası ilə deyil, göndərmə marşrutları ilə başlayın

API-nin Cənub-Şərqi Asiyanı dəstəklədiyini bildirmək satınalma üçün həddən artıq ümumidir. Tələbiniz daha konkretdir: müəyyən göndərmə xidməti, müəyyən ölkələr arasında hərəkət və hər mərhələyə cavabdeh olan müəyyən tərəfdaşlar.

Məsələn, beynəlxalq logistika tərəfdaşı vasitəsilə Malayziyaya daxil olan göndərişin izləmə marşrutu daxili Malayziya göndərişindən fərqli ola bilər. Son çatdırılma şirkəti eyni olsa belə, bunları ayrıca sınaq nümunələri kimi nəzərdən keçirin. Eyni şəkildə, bir marşrut üzrə uğurlu izləmə həmin daşıyıcının təklif etdiyi bütün xidmətlər üçün əhatə dairəsini təsdiqləmir.

Nümayiş tələb etməzdən əvvəl marşrut inventarı hazırlayın. Nə vaxtsa xidmət göstərə biləcəyiniz bütün ölkələri deyil, mövcud biznesinizi və real genişlənmə planlarınızı daxil edin.

Marşrutları biznes üçün kritik və ya əlavə kimi işarələyin. Geniş şəbəkə sifarişlərinizin əhəmiyyətli hissəsini daşıyan marşrut üzrə uğursuz tələbi kompensasiya etməməlidir.

Görünürlüğün təhvil prosesindən sonra da qorunub-qorunmadığını sınaqdan keçirin

Sərhədlərarası göndərmə izləmə nömrəsini tanımaqla göndərişi çatdırılmaya qədər izləmək arasında fərq yaradır. Qiymətləndirmə zamanı provayderdən təyinat üzrə çatdırılma tərəfdaşına keçid də daxil olmaqla, nümunəvi göndərişlərin tam hadisə tarixçəsini nümayiş etdirməsini istəyin.

Daşıyıcının müəyyənləşdirilməsi və izləmə nömrəsində dəyişikliklər

Nömrə birdən çox daşıyıcıya aid ola bildikdə daşıyıcının müəyyənləşdirilməsinin necə işlədiyini soruşun. İnteqrasiyanız daşıyıcı identifikatoru təqdim edə bilərmi? Səhv təyinat düzəldilə bilərmi? Göndərmə tərəfdaşı ikinci izləmə nömrəsi verərsə nə baş verir?

Avtomatik aşkarlamanın hər bir halı həll etdiyini düşünməyin. Mövcud olduqda daşıyıcı və xidmət məlumatlarını göndərmə sisteminizdən saxlayın. Həmçinin əlaqəli izləmə nömrələrinin avtomatik bağlanıb-bağlanmadığını, ayrıca sahələr kimi qaytarılıb-qaytarılmadığını və ya öz verilənlər bazanızda əlaqələndirilməli olduğunu təsdiqləyin.

Hadisənin mənası və ilkin detal

Normallaşdırılmış status daşıyıcılar üzrə ümumi iş axını idarə etmək üçün faydalıdır. Lakin “istisna” kimi geniş etiket dəstək xidmətinin müştəri ilə əlaqə saxlamalı, daşıyıcıdan yeniləmə istəməli və ya gömrük emalını gözləməli olub-olmadığını müəyyən etmək üçün kifayət deyil.

Həm normallaşdırılmış statusu, həm də əsas hadisəni qiymətləndirin. Mümkün olduqda ilkin təsviri, məkanı, daşıyıcının kimliyini, hadisənin vaxtını və saat qurşağı məlumatını saxlayın. Tətbiqinizin uğursuz çatdırılma cəhdini geri qaytarılma hərəkətindən və ya gömrüklə bağlı saxlanmadan fərqləndirə bildiyini sınaqdan keçirin.

Tərcümə agentlərə hadisəni anlamağa kömək edə bilər, lakin audit izinizdə ilkin mətni əvəz etməməlidir. Tərcümə edilmiş təsvirlərin necə yaradıldığını və qeyri-müəyyən mesajların necə idarə edildiyini soruşun.

Göndəriş identikliyi və sifariş identikliyi

Bir sifarişdə bir neçə bağlama ola bilər. Sifariş statusunu bağlama statusundan ayrı saxlayın və sifarişin nə vaxt tam çatdırılmış hesab ediləcəyini müəyyənləşdirin. Əks halda, bir bağlamanın çatdırılması digər bağlama yolda olduğu halda yanıltıcı bildiriş yarada bilər.

Yenilənmə aktuallığını çatdırılma sürəti ilə qarışdırmadan ölçün

İzləmə API-si göndəriş məlumatlarını bildirir; bağlamanın daha sürətli hərəkət etməsini təmin etmir. Gecikmiş yeniləmə API hadisəni görməzdən əvvəl yarana bilər, API isə əlavə emal və ya çatdırılma gecikməsi də yarada bilər. Sınağınız bu ehtimalları bir-birindən ayırmalıdır.

Mövcud olduqda üç vaxt göstəricisini qeydə alın:

• Daşıyıcı hadisəsinin vaxtı: əsas göndəriş hadisəsinin baş verdiyi vaxt kimi qeydə alındığı an.
• Provayderin emal vaxtı: izləmə provayderinin həmin hadisəni qəbul etdiyi və ya emal etdiyi vaxt, açıqlanırsa.
• Tətbiqin qəbul vaxtı: sisteminizin bildirişi və ya əldəetmə cavabını aldığı vaxt.

Saat qurşağı fərqlərini qeydə alın və hadisə vaxtını qəbul vaxtından fərqləndirin. Emal vaxt göstəriciləri mövcud deyilsə, ölçmənizi bunu tamamilə API-yə aid etmək əvəzinə başdan-başa müşahidə gecikməsi kimi təsvir edin.

İş axınına uyğun məqbul aktuallığı müəyyənləşdirin. Müştəriyə açıq izləmə səhifəsi və istisna masası fərqli tələblərə malik ola bilər. Yeniləmə davranışının daşıyıcıya, göndəriş statusuna və ya xidmət planına görə dəyişib-dəyişmədiyini soruşun və vəd edilən yeniləmə intervalına etibar etməzdən əvvəl bu şərtləri təsdiqləyin.

İnteqrasiyanı yalnız normal şəraitdə deyil, nasazlıq zamanı da qiymətləndirin

Uğurlu nümunə cavabı istehsal etibarlılığı barədə çox az məlumat verir. Mühəndislik komandanız qeydiyyatı, yeniləmələri, təkrar cəhdləri, uzlaşdırmanı və bərpanı sınaqdan keçirməlidir.

• Göndərişin qeydiyyatı: doğrulama xətalarını, təkrar göndərişləri, paket limitlərini və bir yanlış qeydin paketin qalan hissəsinə təsir edib-etmədiyini yoxlayın.
• Webhook davranışı: mövcud autentifikasiya və ya yoxlama üsullarını, təsdiq tələblərini, təkrar cəhd qaydalarını və kəsintidən sonra bərpa imkanlarını təsdiqləyin.
• Təkrar və ardıcıllıqdan kənar hadisələr: təkrarlanan bildirişlərin təkrar müştəri mesajları göndərmədiyinə və göndərişi səhvən geriyə aparmadığına əmin olun.
• Uzlaşdırma: əldəetmə son nöqtələrinin və ya başqa dəstəklənən prosesin webhook qəbuledicinizin buraxdığı yeniləmələri bərpa edib-etmədiyini müəyyənləşdirin.
• İstək limitləri: gözlənilən pikləri, geri çəkilmə davranışını və qeydiyyatla əldəetmə limitləri arasındakı sənədləşdirilmiş fərqləri sınaqdan keçirin.
• Sxem dəyişiklikləri: versiyalaşdırma, köhnəlmənin elan edilməsi və tətbiqinizin tanımadığı status dəyərlərini və ya əlavə sahələri necə idarə etməli olduğunu soruşun.

Praktiki qəbuledici dizaynı sorğunu yoxlamaq, onu davamlı şəkildə qəbul etmək, tez təsdiqləmək və asinxron emal etməkdir. Mövcud olduqda təkrarlanan hadisələrin qarşısını almaq üçün provayderin sənədləşdirilmiş hadisə identifikatorundan istifadə edin. Əks halda, hər bildirişin unikal olduğunu düşünmək əvəzinə sabit hadisə sahələrindən deduplikasiya qaydası hazırlayın və sınaqdan keçirin.

Yaşlı hadisəni yalnız gec gəldiyinə görə silməyin. Onu tarixçədə saxlayın, sonra açıq qaydalardan istifadə edərək cari göndəriş vəziyyətini hesablayın. Gecikmiş tarixçə ilə həqiqi geri qaytarılma hərəkəti fərqli şəkildə idarə edilməlidir.

API monitorinqini biznes əlamətləri ətrafında qurun

HTTP uğur göstəriciləri zəruridir, lakin kifayət deyil. Texniki baxımdan uğurlu sorğu boş tarixçə, gözlənilməz daşıyıcı təyinatı və ya iş axınınızı idarə edə bilməyən hadisə qaytara bilər.

Texniki və əməliyyat göstəricilərini birlikdə izləyin:

• Marşrut və daşıyıcı üzrə bölünmüş qeydiyyat uğursuzluqları və həll edilməmiş izləmə nömrələri.
• Webhook qəbul xətaları, emal yığılması və təkrar hadisələrin tezliyi.
• Göndəriş mərhələsi və xidmət gözləntilərinə əsasən şərh edilən son qəbul edilmiş yeniləmədən keçən vaxt.
• Sifariş idarəetmə sisteminizə heç vaxt çatmayan çatdırılmış göndərişlər.
• Agentin növbəti addımı seçməsi üçün kifayət qədər detalı olmayan istisnalar.

Səssiz qalan göndəriş avtomatik olaraq itmiş göndəriş demək deyil. Daşıyıcının təlimatlarından, xidmət öhdəliklərindən və öz əməliyyat tarixçənizdən istifadə edərək eskalasiya qaydaları müəyyənləşdirin. Hər ölkə və xidmət üçün eyni hərəkətsizlik həddini tətbiq etməkdən çəkinin.

Ödəniş vahidini və əməliyyat yükünü müqayisə edin

Hər təklifin nəyi hesabladığını anlamadan qiymət təkliflərini müqayisə etməyin. Ödənişlərin qeydiyyatdan keçmiş göndərişlərdən, sorğulardan, aktiv izləmə qeydlərindən, bildirişlərdən və ya başqa vahiddən asılı olub-olmadığını soruşun. Bunlar satınalma suallarıdır və hər hansı provayderin qiymətləri barədə ehtimallar deyil.

Təkrar qeydiyyat, yenidən izləmə, uzadılmış tranzit müddətləri, saxlanma, sınaq güzəştləri, limitdən artıq istifadə və dəstək barədə yazılı açıqlama tələb edin. Həmçinin təklif olunan plana hansı funksiyaların daxil olduğunu soruşun; sənədlərdə göstərilən imkanın hər müqaviləyə daxil olduğunu düşünməyin.

Ümumi xərci normal iş yükünüz və pik ssenari əsasında hesablayın. Provayder haqları ilə yanaşı mühəndislik texniki xidmətini və əl ilə araşdırma vaxtını da daxil edin. İşçilər çatışmayan təhvil məlumatlarını dəfələrlə bərpa etməli olarsa, daha aşağı abunə qiyməti daha aşağı ümumi xərc demək olmaya bilər.

Məlumatların idarə edilməsini də eyni vaxtda nəzərdən keçirin. İnteqrasiya üçün tələb olunan məlumatları göndərin və alıcı məlumatlarının konkret daşıyıcılarınız və ya xidmətləriniz üçün lazım olub-olmadığını yoxlayın. Saxlanma, giriş nəzarətləri, silinmə prosedurları, alt emalçılar və müqavilə üzrə məlumat emalı şərtləri barədə soruşun. Fəaliyyət göstərdiyiniz yurisdiksiyalarda tələblərə dair məxfilik və ya hüquq komandanızı prosesə cəlb edin.

17TRACK qiymətləndirməyə necə uyğun gəlir

17TRACK-in Tracking API-si çoxdaşıyıcılı inteqrasiya üçün qiymətləndirilə biləcək uyğun seçimdir. rəsmi Tracking API səhifəsindən və tərtibatçı sənədlərindən başlayın, sonra yuxarıdakı tələbləri planlaşdırılan tətbiqiniz və kommersiya şərtlərinizlə müqayisə edin.

Adını çəkdiyiniz daşıyıcıların, xidmət növlərinin, təhvil ssenarilərinin, bildiriş tələblərinin və gözlənilən həcmin təsdiqini istəyin. Cavabları məhsul icmalını bütün marşrutlar üçün sübut hesab etmək əvəzinə, nümunəvi göndərişlərlə yoxlayın.

Əhatə dairəsini aydın saxlayın: bu qərar öz sistemlərinizi məlumatlandıran API ilə bağlıdır. İstehlakçı izləmə səhifəsi və ya vitrin tətbiqi API davranışını, inteqrasiya nəzarətlərini və müqavilə tələblərini yoxlamağı əvəz etmir. Eyni şəkildə, faktiki tələb göndərişləri bron etmək, etiketlər yaratmaq və ya gömrük təqdimatlarını idarə etməkdirsə, yalnız izləmə məlumatları kifayət deyil; bu iş axınlarını ayrıca yoxlayın.

Aydın qəbul meyarları ilə konsepsiya sübutu həyata keçirin

Hadisələrin şərhini yoxlamaq üçün tarixi göndərişlərdən, yeniləmələrin çatdırılmasını qiymətləndirmək üçün isə canlı göndərişlərdən istifadə edin. Adi çatdırılmaları daxil edin, lakin çətin halları da məqsədli şəkildə əlavə edin: qeyri-müəyyən daşıyıcı, dəyişdirilmiş izləmə nömrəsi, çatdırılma cəhdi, gömrüklə bağlı hadisə, geri qaytarılma və bölünmüş sifariş.

1. Sınaqdan əvvəl tələbləri müəyyənləşdirin. Məcburi marşrutları, tələb olunan sahələri, məqbul yeniləmə gecikməsini və bərpa gözləntilərini müəyyən edin. Bunlar ümumi sənaye göstəriciləri deyil, sizin qəbul meyarlarınızdır.
2. İstinad qeydi yaradın. Hər göndəriş üçün göndərmə sistemi məlumatlarını və müvafiq daşıyıcı izləmə tarixçəsini saxlayın. Hər müşahidəni nə vaxt qeydə aldığınızı qeyd edin.
3. Tam iş axınını icra edin. Göndərişi qeydiyyata alın, yeniləmələri qəbul edin, izləməni göstərin, istisnaları açın və çatdırılmanı sifariş idarəetmə sisteminə uzlaşdırın.
4. Nəzarətli nasazlıqlar yaradın. Sınaq mühitində qəbuledicinizi dayandırın, təkrar göndərişlər edin və yanlış identifikatorları sınaqdan keçirin. Bərpanın əl ilə yenidən qurulma tələb etmədiyini yoxlayın.
5. Uyğunsuzluqları səbəbə görə nəzərdən keçirin. Yuxarı axında çatışmayan hadisələri, daşıyıcı xəritələşdirmə xətalarını, provayderin emal problemlərini və öz inteqrasiyanızdakı qüsurları ayırın.
6. Qərarı sənədləşdirin. Sübut və məsul şəxslə birlikdə hər tələbi keçib, uğursuz olub və ya təsdiq gözləyir kimi qeyd edin.

Çəkili bal hesabından əvvəl məcburi keçidlər tətbiq edin. Kritik məxfilik tələbi və ya dəstəklənməyən əsas marşrut müsbət orta nəticənin içində itib getməməlidir. Bu keçidlərdən uğurla keçən provayderlər arasında istifadə oluna bilən hadisə məlumatlarını, etibarlı bərpanı və davamlı əməliyyat xərclərini birləşdirən seçimi üstün tutun.

Əməliyyat rəhbəri istisnaların faydalılığına, mühəndislik inteqrasiyanın dayanıqlılığına, satınalma və hüquq komandaları isə kommersiya və məlumat şərtlərinə cavabdeh olmalıdır. Yalnız bu məsul şəxslər həm imkanlar, həm də qalan məhdudiyyətlər barədə razılığa gəldikdə tətbiqi təsdiqləyin.

Tez-tez verilən suallar

Cənub-Şərqi Asiyanın hər ölkəsi üçün ayrıca izləmə API-sinə ehtiyacım varmı?

Mütləq deyil. Çoxdaşıyıcılı API bir neçə ölkə üzrə tələblərinizi ödəyə bilər, lakin istifadə etdiyiniz hər daşıyıcını, xidməti və marşrutu yoxlayın. Ayrıca inteqrasiyanı yalnız sənədləşdirilmiş boşluq və ya ixtisaslaşmış tələb texniki xidmət xərcini əsaslandırdıqda əlavə edin.

Daşıyıcı dəstəyi son çatdırılmaya qədər görünürlüğə zəmanət verirmi?

Xeyr. Daşıyıcı siyahısı hər xidmət və ya tərəfdaş təhvil prosesi üçün nəticəni təsdiqləmir. İstənilən ikinci identifikator və təyinat üzrə çatdırılma hadisələri də daxil olmaqla, tam göndəriş tarixçələrini sınaqdan keçirin.

Webhook-lardan, yoxsa sorğulama üsulundan istifadə etməliyəm?

Dəstəkləndikdə webhook-lar təkrar əldəetmə sorğularını azalda bilər. Uzlaşdırma prosesi buraxılmış yeniləmələri bərpa etməyə kömək edə bilər. Provayderin sənədləşdirilmiş limitləri və bərpa mexanizmlərinin icazə verdiyi kombinasiyanı seçin və kəsinti zamanı onu sınaqdan keçirin.

İzləmə API-si sınağı nə qədər davam etməlidir?

Müvafiq göndəriş həyat dövrünüzü və mühüm istisna hallarını müşahidə etmək üçün kifayət qədər uzun müddət sınaq keçirin. Sabit təqvim müddəti tələb olunan ssenariləri tamamlamaqdan daha az faydalıdır. Tarixi qeydlər canlı sınağı tamamlaya bilər, lakin canlı bildirişlərin etibarlılığını təsdiqləyə bilməz.

API müştərilərə bağlamanın dəqiq nə vaxt çatacağını deyə bilərmi?

Yalnız seçilmiş xidmət iş axınınıza uyğun təxmini çatdırılma tarixi təqdim etdikdə ondan istifadə edin. Mənbəsini, mənasını və yenilənmə davranışını təsdiqləyin. Son izləmə hadisəsini dəstəklənməyən çatdırılma vədinə çevirməyin.

Mənbələr

Aşağıdakı rəsmi resurslar bu bələdçidə müzakirə olunan 17TRACK məhsulu və tətbiq yoxlamaları üçün başlanğıc nöqtələridir. Marşrut səviyyəsində qəbul meyarları, monitorinq tövsiyələri və konsepsiya sübutu prosedurları redaksiya tövsiyələridir, bildirilmiş məhsul performansı nəticələri deyil.

• 17TRACK Tracking API — API-nin uyğunluğunu qiymətləndirmək üçün rəsmi məhsul mənbəyi.
• 17TRACK API sənədləri — inteqrasiya tələblərini və dəstəklənən davranışı təsdiqləyərkən istifadə ediləcək rəsmi texniki mənbə.