Yeni bazarlara daxil olmamışdan əvvəl Göndəriş İzləmə API-sinin əhatə dairəsini necə yoxlamaq olar
Yeni bazara daxil olmadan əvvəl göndəriş izləmə API-sinin əhatə dairəsini yoxlamaq üçün istifadə etməyi planlaşdırdığınız dəqiq daşıyıcı, xidmət, daşınma marşrutu və son mil kombinasiyalarını test edin. Canlı göndərişləri daşıyıcının qeydləri ilə müqayisə edin, hadisələrin sistemlərinizə düzgün çatdığını təsdiqləyin və istifadəyə verməzdən əvvəl boşluqları sənədləşdirin. Daşıyıcının provayderin dəstəklənən siyahısında görünməsi başlanğıc nöqtəsidir, planlaşdırdığınız çatdırılma səyahətinin görünən olmasına sübut deyil.
Bu təlimat bazara çıxışa hazırlaşan logistika menecerləri, e-ticarət əməliyyatları komandaları və inteqrasiya üzrə məsul şəxslər üçündür. Məqsəd praktik istifadəyəvermə qərarıdır: hansı daşınma marşrutları yoxlanılıb, hansıları ehtiyat variant tələb edir və hansıları hələ də sübut tələb edir.
Əhatə dairəsini ölkə sayı ilə deyil, daşınma marşrutlarınız ətrafında müəyyənləşdirin
Bazar girişinin planlaşdırılması zamanı izləmə əhatə dairəsini konkret daşınma sxemi üçün istifadə edilə bilən göndəriş hadisələrini əldə etmək və çatdırmaq imkanı kimi qəbul edin. Yalnız təyinat ölkəsi təhlil üçün həddən artıq geniş vahiddir. Eyni ölkəyə daxil olan iki göndəriş fərqli mənşə daşıyıcılarından, gömrük razılaşmalarından, çatdırılma tərəfdaşlarından və xidmət səviyyələrindən istifadə edə bilər.
Satınalma müzakirələrində tez-tez birləşdirilən üç sualı ayırın:
- Daşıyıcı uyğunluğu: API istifadə etdiyiniz daşıyıcı və xidmətdən göndərişləri qəbul edib müəyyən edə bilərmi?
- Səyahətin görünməsi: Müvafiq daşınma mərhələləri üzrə komandanızın ehtiyac duyduğu hadisələri qaytarırmı?
- Əməliyyat çatdırılması: Bu hadisələr sifariş idarəetmə sisteminizə, dəstək alətlərinizə və müştəri bildirişlərinə etibarlı şəkildə çata bilərmi?
Uğurlu API sorğusu yalnız ilk sualın bir hissəsinə cavab verir. Bu, göndərişin faydalı hadisələrə malik olduğunu, son çatdırılma nəticəsinin göründüyünü və ya tətbiqinizin yeniləməni emal etdiyini təsdiq etmir.
1. Bazara xas əhatə dairəsi matrisi yaradın
Logistika komandanızın faktiki icra etmək niyyətində olduğu daşınma planı ilə başlayın. Anbarınızdan, icra xidmətinizdən və nəqliyyat tərəfdaşlarınızdan cəlb olunan daşıyıcıları və xidmətləri təsdiqləmələrini istəyin. Konsolidator son mil tərəfdaşını dinamik şəkildə seçirsə, konsolidatorun adını tam marşrut təsviri kimi qəbul etmək əvəzinə bu qeyri-müəyyənliyi qeyd edin.
Əhəmiyyətli hər kombinasiya üçün bir sətir yaradın. Aşağıdakı sahələr faydalı iş matrisi təşkil edir:
| Sahə | Nə qeyd edilməlidir | Nə üçün vacibdir |
|---|---|---|
| Daşınma marşrutu | Mənşə və təyinat bazarı | Daxili nəticələr sərhədlərarası görünməni təsdiq etmir. |
| Daşıyıcı və xidmət | Müqaviləli daşıyıcı, xidmət adı və müvafiq identifikator | Daşıyıcı səviyyəsindəki siyahı xidmətə xas suallara cavab verməyə bilər. |
| Təhvil-təslim sxemi | Məlum çatdırılma tərəfdaşı və hər hansı əvəzedici izləmə nömrəsi | Transfer zamanı fasiləsizliyi test etməlisiniz. |
| Tələb olunan mərhələlər | Qəbul, hərəkət, çatdırılma cəhdi, çatdırılma və müvafiq istisnalar | Tələblər dəstək və müştəri ehtiyaclarını əks etdirməlidir. |
| Biznes təsiri | Proqnozlaşdırılan göndəriş payı və yeniləmələrin olmamasının nəticələri | Yüksək həcmli və yüksək riskli marşrutlara üstünlük verilməlidir. |
| Yoxlama statusu | Yoxlanılıb, şərti, hələ yoxlanılmayıb və ya dəstəklənmədiyi təsdiqlənib | Sübutun olmaması dəstəyin olmaması ilə qarışdırılmamalıdır. |
Məsuliyyəti erkən bölüşdürün. Logistika fiziki marşrutu, mühəndislik məlumatların çatdırılmasını yoxlamalı, əməliyyatlar isə yaranan görünmənin müştəri vədlərini dəstəkləyib-dəstəkləmədiyinə qərar verməlidir. Satınalma prosesi əlaqələndirə bilər, lakin təkcə xüsusiyyətlər siyahısı qəbul qərarını müəyyən etməməlidir.
2. Rəsmi sənədləri yoxlayın, sonra marşruta xas suallar verin
Sənədləşdirilmiş inteqrasiya əhatə dairəsini müəyyən etmək üçün provayderin rəsmi API materiallarından istifadə edin. Daşıyıcı identifikatorlarını, qeydiyyat tələblərini, cavab sahələrini, hadisə təriflərini, autentifikasiyanı, istifadə limitlərini və yeniləmələrin çatdırılma davranışını araşdırın. Tətbiqinizə aid sənədlərin tarixli qeydini saxlayın.
17TRACK qiymətləndirməsi üçün official Tracking API page və API documentation səhifələrindən yoxlama başlanğıc nöqtəsi kimi istifadə edin. Aşağıda təsvir olunan eyni marşrut səviyyəli qəbul testlərini tətbiq edin; ümumi məhsul təsvirini konkret xidmət və ya təhvil-təslim sxeminin təsdiqi kimi qəbul etməyin.
Provayderə ölkəni “əhatə edib-etmədiyini” soruşmaq əvəzinə konkret yoxlama sorğusu göndərin. Planlaşdırdığınız daşıyıcı və xidməti, mənşə və təyinatı, istifadəyə icazəli nümunə izləmə nömrələrini, tələb olunan mərhələləri və gözlənilən göndəriş həcmini daxil edin.
- Bu dəqiq xidmət açıq daşıyıcı identifikatoru və ya əlavə göndəriş məlumatı tələb edirmi?
- Birdən çox daşıyıcı ilə uyğunlaşa bilən nömrəni inteqrasiya necə emal etməlidir?
- Orijinal identifikator son mil fəaliyyətini göstərə bilərmi, yoxsa ikinci identifikator qeydiyyata alınmalıdır?
- Bu marşrutdan hansı tələb olunan hadisələr gözlənilir və hansıları daşıyıcının təqdim etməsindən asılıdır?
- İzləmə müvəqqəti olaraq əlçatan olmadıqda və ya göndərişdə hələ heç bir hadisə olmadıqda nə baş verir?
- Təklif olunan iş axınına hansı istifadə limitləri, məlumatların saxlanma qaydaları və ödəniş şərtləri tətbiq olunur?
Sənədləşdirilmiş davranışı müqavilə öhdəliklərindən ayırın. Yeniləmələrin texniki təsviri zəmanətli yenilənmə intervalı və ya xidmət səviyyəsi öhdəliyi demək deyil. Bu fərq istifadəyəvermə riskinə təsir etdikdə yazılı təsdiq istəyin.
3. Yalnız uğurlu çatdırılmaları deyil, nümunəvi göndərişləri test edin
Test dəstini giriş icazəniz olan göndərişlər əsasında yaradın. Həm tamamlanmış, həm də aktiv göndərişləri daxil edin. Tarixi qeydlər hadisə ardıcıllıqlarını yoxlamağa kömək edir; qeydiyyatı, yeniləmənin gəlməsini və öz sistemlərinizə çatdırılmanı müşahidə etmək üçün canlı göndərişlər lazımdır.
Matrisinizdəki marşrutlar və xidmətlər üzrə nümunələr seçin. Adi çatdırılmaları və real nümunələr mövcud olduqda gecikmiş göndərişləri, uğursuz çatdırılma cəhdlərini, təhvil məntəqəsinə çatdırılmaları və göndərənə qaytarmaları daxil edin. Uyğun göndəriş olmadıqda istisna testinin nəticəsini uydurmayın. Bu ssenarini yoxlama gözləyir kimi işarələyin.
Əhatə dairəsini sübut edən universal nümunə ölçüsü yoxdur. Kiçik dəst inteqrasiya xətasını üzə çıxara bilər, lakin hər xidmət və istisna üzrə etibarlı performansı təsdiq edə bilməz. Marşrut müxtəlifliyi, daşıyıcı qeyri-müəyyənliyi və ya hadisələrin itirilməsinin nəticələri artdıqca testləri genişləndirin.
Eyni göndərişi üç sübut qatında müqayisə edin
- Daşıyıcı qeydi: Müvafiq daşıcıdan birbaşa əldə edilən izləmə məlumatlarını, o cümlədən yoxlama vaxtını qeyd edin.
- API cavabı: Xam cavabı, qaytarılan daşıyıcı kimliyini, hadisə vaxt nişanlarını və əldə etmə vaxtını saxlayın.
- Tətbiqiniz: Sisteminizin nəyi saxladığını, göstərdiyini və əməliyyatları işə salmaq üçün istifadə etdiyini təsdiqləyin.
Bu qatlar nasazlığın yerini müəyyən etməyə kömək edir. Həm daşıyıcı izləməsində, həm də API-də olmayan hadisə, daşıyıcıda görünən, lakin API-də olmayan hadisədən fərqlidir. API-də mövcud olub sifariş sisteminizdə görünməyən hadisə inteqrasiyanın başqa hissəsində problemə işarə edir.
Daşıyıcı qeydini fiziki hərəkətin qüsursuz hesabatı deyil, istinad kimi qəbul edin. İzləmə qeydləri bildirilmiş hadisələri təsvir edir; bağlamanın fasiləsiz müşahidəsini təmin etmir. Əhəmiyyətli uyğunsuzluqları daşıyıcı və API provayderi ilə araşdırın.
4. Təhvil-təslimləri, statusların mənasını və yenilənmə vaxtını yoxlayın
Son mil boyunca fasiləsizliyi yoxlayın
Hər sərhədlərarası marşrut üçün göndərişin əldən-ələ keçməsi zamanı nə baş verdiyini yoxlayın. Orijinal nömrənin faydalı hadisələri qaytarmağa davam edib-etmədiyini, başqa nömrənin yaranıb-yaranmadığını və sisteminizin hər iki identifikatoru eyni sifarişlə əlaqələndirə bildiyini qeyd edin.
Təhvil-təslim mesajı çatdırılmanın görünməsinə sübut deyil. Göndərişi son nəticəsinə qədər izləyin. Son mil məlumatı əlçatan deyilsə, səbəbin mənbə məlumatlarının çatışmaması, identifikator problemi, konfiqurasiya xətası və ya dəstək məhdudiyyəti olduğunu müəyyənləşdirin. Bu fərq aydınlaşana qədər marşrutu şərti saxlayın.
Normallaşdırılmış statusların arxasındakı mənanı yoxlayın
İnteqrasiyanız normallaşdırılmış statuslardan istifadə edirsə, onları əsas hadisə mətni ilə müqayisə edin. Etiketin yaradılmasının fiziki göndəriş mesajını işə salmadığını, çatdırılma obyektinə çatmanın “çatdırıldı” statusuna çevrilmədiyini və uğursuz çatdırılma cəhdinin sifarişi uğurla tamamlanmış kimi bağlamadığını yoxlayın.
Müvafiq olduqda götürülmə imkanını və göndərənə qaytarılma nəticələrini də test edin. Sadələşdirilmiş status müştərilərə irəliləyişi anlamağa kömək edə bilər, lakin dəstək komandanız istisnanı izah etmək üçün orijinal təsvirə ehtiyac duya bilər. İnterfeysi bunlar əsasında layihələndirməzdən əvvəl hansı detalların həqiqətən qaytarıldığını təsdiqləyin.
Müşahidə olunan gecikməni dəqiqliyi şişirtmədən ölçün
Hadisə vaxtını, müşahidə vaxtını və tətbiqin emal vaxtını ayrı saxlayın. Daşıyıcı hadisəsinə əlavə edilmiş vaxt nişanı həmin hadisənin onlayn əlçatan olduğu vaxt olmaya bilər. Buna görə hadisə vaxtının API tərəfindən qəbul edilmə vaxtı ilə müqayisəsi bir neçə gecikmə mənbəyini birləşdirə bilər.
Daşıyıcını vaxtaşırı yoxlayırsınızsa, hadisəni ilk dəfə müşahidə etdiyiniz vaxtı bilirsiniz, onun dəqiq dərc vaxtını yox. Yoxlama intervalını qeyd edin və nəticəni müşahidə olunan gecikmə kimi işarələyin. Saat qurşaqlarını normallaşdırın və görünən ardıcıllıq problemlərini araşdırmaq üçün orijinal vaxt nişanlarını saxlayın.
5. İnteqrasiyanı istifadəyəvermə şərtləri altında yoxlayın
Tətbiqinizdə yeniləmələr uğursuz olursa, marşrutun görünməsi kifayət deyil. İstehsalda faktiki istifadə edəcəyiniz yeniləmə mexanizmini test edin. Vebhuk əsaslı iş axınlarında sənədləşdirilmiş autentifikasiya, təsdiq, təkrar cəhd və bərpa davranışını yoxlayın. Sorğu ilə yoxlama zamanı icazə verilən sorğu tezliyini və kəsintilərdən sonra tətbiqinizin necə bərpa olunduğunu təsdiqləyin.
- Qeydiyyat: Qəbul edilmiş göndərişi rədd edilmiş sorğudan və hələ hadisəsi olmayan qəbul edilmiş göndərişdən ayırın.
- Dublikat yeniləmələr: Təkrarlanan məlumatın müştərilərə dublikat bildirişlər göndərmədiyinə əmin olun.
- Hadisə ardıcıllığı: Gec gələn köhnə hadisənin çatdırılmış göndərişi yenidən daşınmada kimi göstərmədiyini yoxlayın.
- Son nöqtə xətası: Müvəqqəti qəbul sistemi kəsintisini və sənədləşdirilmiş bərpa prosesini test edin.
- Tutum: İstifadəyəvermə proqnozlarını və pik yükləri tətbiq olunan qeydiyyat və sorğu limitləri ilə müqayisə edin.
- Məlumatların emalı: Hansı sahələrin zəruri olduğunu təsdiqləyin, giriş məlumatlarına çıxışı məhdudlaşdırın və məxfiliklə müqavilə tələblərini müvafiq komandanın nəzərdən keçirməsini təmin edin.
Kommersiya fərziyyələrini texniki fərziyyələrlə yanaşı yoxlayın. Nəyin ödənişli istifadə sayıldığını, dublikat qeydiyyatların necə qiymətləndirildiyini və limitlərə çatdıqda nə baş verdiyini soruşun. İnteqrasiya testinin və ya sınağın planlaşdırılan istehsal sxemi ilə eyni şərtlərə malik olduğunu düşünməyin.
6. Ölçülə bilən istifadəyəvermə meyarları müəyyən edin
Nəticələri qiymətləndirməzdən əvvəl qəbul meyarlarını müəyyən edin. Əks halda istifadəyəvermə tarixi yaxınlaşdıqda zəif testi kifayət hesab etmək asanlaşır. İzah olunmamış sənaye göstəricisini götürmək əvəzinə müştəri vədlərinizə və əməliyyat təsirinizə uyğun hədlərdən istifadə edin.
Faydalı ölçülərə aşağıdakılar daxildir:
- Qeydiyyat uğuru: Uğurla qəbul edilmiş etibarlı test göndərişlərinin etibarlı qeydiyyat cəhdlərinə nisbəti.
- İzləmənin əlçatanlığı: İstifadəyə yararlı izləmə hadisələri olan test edilmiş göndərişlərin uyğun test edilmiş göndərişlərə nisbəti.
- Tələb olunan mərhələlərin tutulması: API tərəfindən qaytarılmış tələb olunan mərhələlərin istinad qeydlərində müşahidə olunan müvafiq mərhələlərə nisbəti.
- Son nəticə uyğunluğu: API nəticəsi istinad nəticəsi ilə uyğun gələn uyğun tamamlanmış göndərişlərin yoxlanılmış uyğun tamamlanmış göndərişlərə nisbəti.
- Müşahidə olunan yenilənmə gecikməsi: Müəyyən edilmiş müşahidə metodu ilə ölçülən gecikmələrin paylanması.
Xam sayları faizlərlə birlikdə bildirin və istisnaları göstərin. Aktiv göndərişi çatdırılma nəticəsi çatışmayan göndəriş kimi saymayın. Həll olunmamış izləmə xətalarını səssizcə istisna etməyin. Nəticələri proqnozlaşdırılan göndəriş həcminə görə çəkiləndirsəniz, zəif, lakin vacib marşrutun görünən qalması üçün ayrıca marşrut nəticələrini də göstərin.
Dörd qərar statusundan istifadə edin: marşrut razılaşdırılmış testlərə cavab verdikdə yoxlanılıb; məlum boşluq üçün qəbul edilmiş alternativ həll olduqda şərti; sübut natamam olduqda hələ yoxlanılmayıb; birbaşa təsdiq və ya diaqnoz qoyulmuş məhdudiyyət bu nəticəni təsdiqlədikdə isə dəstəklənmədiyi təsdiqlənib. İzah olunmamış uğursuz sorğu təkbaşına sonuncu kateqoriya üçün kifayət deyil.
7. Aydın ehtiyat variantları və yenidən yoxlama tətikləri ilə istifadəyə verin
Hər şərti marşrut üçün məsul şəxs və ehtiyat variant təyin edin. Seçimlərə əl ilə daşıyıcı yoxlamaları, dəstəyə eskalasiya prosesi, fərqli daşınma xidməti və ya daha az konkret müştəri mesajları daxil ola bilər. İzləmə məlumatları bunu dəstəkləmədikdə əminliklə çatdırılma iddiaları göndərməkdən çəkinin.
Daşıyıcı xidməti dəyişdikdə, icra tərəfdaşı marşrutlaşdırmanı dəyişdikdə, yeni son mil tərəfdaşı yarandıqda və ya monitorinq çatışmayan nəticələri aşkar etdikdə yenidən yoxlayın. Təsdiqlənmiş matrisi, test sübutlarını, həll olunmamış məsələləri və provayder təsdiqlərini birlikdə saxlayın. Bazara giriş əhatə dairəsi birdəfəlik satınalma iddiası deyil, əməliyyat qeydi olaraq qalmalıdır.
FAQ
Dəstəklənən daşıyıcı siyahısı hər xidmət üçün əhatə dairəsini sübut edirmi?
Xeyr. Namizəd inteqrasiyanı müəyyən etmək üçün siyahıdan istifadə edin, sonra konkret xidməti, marşrutu, identifikator tələblərini və son mil nəticəsini yoxlayın. İctimai sənədlər bu detalları aydınlaşdırmadıqda birbaşa təsdiq istəyin.
Əhatə dairəsini yalnız çatdırılmış göndərişlərlə yoxlaya bilərikmi?
Çatdırılmış göndərişlər tarixi hadisələrin tamlığını və son nəticələri yoxlamağa kömək edir. Lakin onlar yeni hadisələrin nə qədər tez gəldiyini və sisteminizin canlı yeniləmələri necə emal etdiyini göstərmir. Vaxta həssas bildiriş iş axınını təsdiqləməzdən əvvəl aktiv göndərişləri daxil edin.
API heç bir izləmə hadisəsi qaytarmırsa nə etməliyik?
Sorğunun nəticəsini, daşıyıcı seçimini, tələb olunan girişləri və daşıyıcının özündə hadisələrin görünüb-görünmədiyini yoxlayın. Gözləyən məlumatı etibarsız qeydiyyatdan və təsdiqlənmiş dəstək çatışmazlığından ayırın. Həll olunmamış halları izləmə nömrəsi, sorğu detalları, vaxt nişanları və istinad sübutları ilə eskalasiya edin.
Hər göndəriş gömrük hadisələrini göstərməlidirmi?
Hər marşrutun bağlama izləməsi vasitəsilə gömrük mərhələlərini göstərdiyini düşünməyin. Bu hadisələr iş axınınız üçün zəruridirsə, onları xüsusi olaraq yoxlayın və olmadıqda əməliyyatların necə cavab verəcəyini müəyyən edin. İzləmə detallarının çatışmaması öz-özlüyündə gömrük problemi olduğunu sübut etmir.
Bəzi marşrutlar yoxlanılmamış qaldığı halda istifadəyə verə bilərikmi?
Təsir başa düşülürsə, təsirlənmiş marşrutlar üçün təsdiqlənmiş ehtiyat variantlar varsa və qalan yoxlamaya məsul şəxs təyin edilibsə, məhdud istifadəyəvermə məqsədəuyğun ola bilər. Bu marşrutları daxildə yoxlanılmış kimi təqdim etməyin və nümayiş etdirilməmiş imkanlara əsaslanan müştəri vədləri verməyin.
Sources
17TRACK qiymətləndirməsi üçün məhsul əhatə dairəsini və tətbiq tələblərini yoxlamaq məqsədilə bu rəsmi resurslardan istifadə edin. Bu təlimatdakı test prosedurları və istifadəyəvermə meyarları əməliyyat tövsiyələridir, zəmanətli marşrut əhatə dairəsi iddiaları deyil.
