UPS Tracking API vebhukları: Onlar nədir, necə işləyirlər və istifadə halları
UPS izləmə API vebhukları izləmə hadisəsi mövcud olduqda tətbiqə göndəriş yeniləmələrini qəbul etməyə imkan verir; bununla da izləmə xidmətindən ən son statusu dəfələrlə soruşmağa ehtiyac qalmır. Onlar e-ticarət mağazaları, logistika komandaları, marketplace-lər və sifarişlərin idarə edilməsi iş axınlarını quran tərtibatçılar üçün faydalıdır. Praktik dəyər yalnız statusların daha sürətli sinxronlaşdırılmasından ibarət deyil: yaxşı hazırlanmış vebhuk axını müştəriyə görünən səhifələri yeniləyə, istisnaların idarə edilməsini işə sala və lazımsız izləmə sorğularını azalda bilər.
Dəqiq autentifikasiya üsulu, hadisə modeli, sorğu limitləri, payload sahələri və hesab tələbləri UPS developer məhsulundan və inteqrasiya mühitindən asılıdır. Tərtibatçılar istehsal bağlantısı qurmadan əvvəl bu detalları mövcud UPS sənədlərində yoxlamalıdırlar.
UPS izləmə API vebhuku nədir?
İzləmə API-si göndəriş məlumatlarını proqram vasitəsilə tələb etmək imkanı yaradır. Vebhuk isə xaricə yönəlmiş bildiriş modelini əlavə edir: tətbiq müvafiq yeniləmələrə abunə olduqdan sonra uyğun hadisə baş verdikdə xidmət həmin tətbiqin nəzarət etdiyi endpoint-ə HTTP sorğusu göndərir.
Məsələn, sifariş sistemi UPS izləmə nömrəsini saxlaya və vebhuk endpoint-i qeydiyyatdan keçirə bilər. Göndərişin statusu dəyişdikdə qəbul edən sistem izləmə nömrəsi, status, vaxt möhürü, məkan, çatdırılma təxmini və ya istisna məlumatlarının müəyyən kombinasiyasını ehtiva edən bildiriş ala bilər. Qəbul edən sistem daha sonra mesajı yoxlayır, öz qeydini yeniləyir və hansı əməliyyatın həyata keçirilməli olduğuna qərar verir.
Vebhuk izləmə səhifəsi ilə eyni deyil. İzləmə səhifəsi insanın baxması üçün nəzərdə tutulub. Vebhuk isə proqram təminatının istifadə etməsi üçün hazırlanıb. Bu, həmçinin hər daşıyıcı skanının tam olaraq bir dəfə və ideal ardıcıllıqla çatdırılacağına zəmanət vermir. İstehsal sistemləri təkrarlanan mesajlar, gecikmiş çatdırılma, yenidən cəhdlər və vaxtaşırı sinxronlaşdırma nəzərə alınmaqla qurulmalıdır.
İş axını adətən necə işləyir
- Tərtibatçı müvafiq UPS developer hesabı vasitəsilə girişi yaradır və ya konfiqurasiya edir, həmçinin API üçün tələb olunan məlumatları əldə edir.
- Tətbiq göndəriş identifikatorunu, adətən izləmə nömrəsini, daxili sifariş və müştəri istinadları ilə birlikdə təqdim edir və ya saxlayır.
- Tərtibatçı hamı üçün əlçatan HTTPS endpoint-i konfiqurasiya edir və tələb olunarsa provayderin abunəlik və ya qeydiyyat proseduruna əməl edir.
- İzləmə xidməti abunə olunmuş yeniləmə mövcud olduqda HTTP bildirişi göndərir.
- Endpoint sorğunu autentifikasiya edir və ya yoxlayır, payload-u təhlil edir və göndərişin məlum olduğunu təsdiqləyir.
- Tətbiq sorğunu tez bir zamanda təsdiqləyir, daha sonra biznes əməliyyatını növbə və ya fon işçisi vasitəsilə emal edir.
- Sistem hadisəni qeyd edir, idempotentlik qaydalarını tətbiq edir və sifariş, anbar, dəstək və ya müştəri bildirişi iş axınını yeniləyir.
Təsdiqləmə ilə emalın ayrılması vacibdir. Endpoint yavaş işlədikdə və ya xəta qaytardıqda vebhuk göndərən tərəf yenidən cəhd edə bilər. Cavab verməzdən əvvəl geniş verilənlər bazası əməliyyatları, e-poçt göndərilməsi və ya anbar emalı həyata keçirən qəbul edici tərəf vaxt aşımına və təkrarlanan çatdırılmalara səbəb ola bilər.
Vebhuk bildirişləri və sorğu ilə yoxlama
| Yanaşma | Necə işləyir | Əsas güzəşt |
|---|---|---|
| Sorğu ilə yoxlama | Tətbiqiniz cədvəl üzrə ən son statusu soruşur. | Anlamaq sadədir, lakin təkrarlanan sorğular gecikmə və lazımsız trafik yarada bilər. |
| Vebhuk çatdırılması | İzləmə xidməti yeniləmə mövcud olduqda bildiriş göndərir. | Planlı yoxlamaları azalda bilər, lakin təhlükəsiz, etibarlı qəbul edici və bərpa prosesi tələb edir. |
| Hibrid model | Vebhuklar normal emalı işə salır, sorğu və ya sinxronlaşdırma isə boşluqları yoxlayır. | Daha çox dizayn işi tələb edir, lakin çox vaxt tək çatdırılma yolundan daha davamlı olur. |
Vebhuk API sorğularına olan ehtiyacı avtomatik olaraq aradan qaldırmır. Bəzi inteqrasiyalar bildirişdən siqnal kimi istifadə edir və daha sonra ən son əsas qeydi əldə etmək üçün izləmə API-sinə müraciət edir. Bu, vebhuk payload-u yığcam hadisə olduqda, tətbiqə bildirişdə olmayan göndəriş təfərrüatları lazım gəldikdə və ya biznes bütün yeniləmələr üçün vahid normallaşdırma yolu istədikdə faydalı ola bilər.
İzləmə vebhuku payload-unda nələr olmalıdır?
Payload-lar provayderə və məhsula görə dəyişir. Mövcud sənədlər və sınaq cavabları yoxlanılmayana qədər verilənlər bazanızı ehtimal edilən sahə adları əsasında layihələndirməyin. Ümumilikdə izləmə hadisəsi aşağıdakıları müəyyən etməlidir:
- Göndəriş və ya izləmə nömrəsi
- Hadisə və ya göndəriş statusu
- Hadisə vaxtı və təqdim edildikdə yerli vaxt qurşağı
- Skan təsviri və ya əməliyyat mesajı
- Mövcud olduqda məkan məlumatı
- Təqdim edildikdə çatdırılma təxmini və ya çatdırılma təsdiqi
- İstisna göstəricisi və ya istisna təsviri
- Provayder hadisə identifikatoru və ya təkrarlanan hadisələrin qarşısını almaq üçün faydalı digər dəyər
Status mətnini universal biznes qaydası kimi deyil, provayder məlumatı kimi qəbul edin. “Yoldadır”, “istisna” və ya “çatdırılıb” kimi etiketlər daxili status modelinə uyğunlaşdırılmalıdır. Sisteminiz ilkin daşıyıcı statusunu normallaşdırılmış statusla yanaşı saxlamalıdır ki, dəstək əməkdaşları mənbə mesajını itirmədən fərqləri araşdıra bilsinlər.
Praktik istifadə ssenariləri
Müştəriyə çatdırılma yeniləmələri
E-ticarət platforması sifariş statusu səhifəsini yeniləmək və ya müştəriyə bildiriş göndərmək üçün izləmə hadisələrindən istifadə edə bilər. Ən yaxşı işə salma qaydası biznes tələbindən asılıdır. Göndərişin qəbul skanı icranın irəlilədiyini təsdiqləyə bilər, istisna hadisəsi isə ümumi status e-poçtu əvəzinə dəstək mesajını tələb edə bilər. Müştərilər bu səviyyədə təfərrüatı açıq şəkildə istəmədikcə hər skan üçün ayrıca bildiriş göndərməkdən çəkinin.
İstisnaların idarə edilməsi
Vebhuk mümkün çatdırılma problemlərini nəzərdən keçirilməsi üçün növbəyə yönləndirə bilər. Buna çatdırılma istisnası, ünvanla bağlı problem və ya gözlənildiyi kimi irəliləməyən göndəriş nümunə ola bilər. İnteqrasiya məlumat xarakterli skanla əməliyyat istisnasını fərqləndirməlidir. Həmçinin məsuliyyəti müəyyən etməlidir: müştəri dəstəyi əlaqəni idarə edə, icra komandası isə göndərişi və ya ünvanı araşdıra bilər.
Anbar və sifarişlərin idarə edilməsi üzrə sinxronlaşdırma
Anbar və ya sifarişlərin idarə edilməsi sistemi əməkdaşların daşıyıcının saytını əl ilə yoxlamasına ehtiyac qalmadan icra qeydini yeniləmək üçün izləmə hadisələrindən istifadə edə bilər. Bu, xüsusilə bir sifarişdə bir neçə bağlama olduqda faydalıdır. Verilənlər modeli bütün sifarişə bir status bağlamaq əvəzinə paket səviyyəsində izləmə qeydlərini saxlamalıdır, çünki eyni sifarişdəki bağlamalar müxtəlif vaxtlarda hərəkət edə və ya çata bilər.
Qaytarmalar və əks logistika
Qaytarma iş axınları bağlamanın satıcıya doğru hərəkət etdiyini və ya qaytarma məntəqəsinə çatdığını müəyyən etmək üçün izləmə hadisələrindən istifadə edə bilər. Satıcının siyasəti bu şərtdən açıq şəkildə istifadə etmədikcə, hadisə özü geri ödənişə icazə verməməlidir. Daşıyıcı çatdırılmanı bildirdikdən sonra qaytarma üçün yoxlama, inventarın uzlaşdırılması və ya fırıldaqçılığın araşdırılması tələb oluna bilər.
Əməliyyat hesabatları
Normallaşdırılmış izləmə hadisələri göndərişin gedişi, istisnaların sayı və çatdırılma nəticələri üzrə hesabatları dəstəkləyə bilər. Hesabatlar öz təriflərini aydın göstərməlidir. Məsələn, “çatdırılıb” daşıyıcının bildirdiyi çatdırılma hadisəsi demək ola bilər, “vaxtında” isə müəyyən edilmiş vəd edilən tarix, son vaxt, vaxt qurşağı və ünvan dəyişiklikləri və ya müştərinin xahiş etdiyi gecikmələrlə bağlı qaydalar tələb edir.
Yalnız UPS inteqrasiyası, yoxsa çoxdaşıyıcılı API?
UPS ilə birbaşa inteqrasiya biznes əsasən UPS-dən istifadə etdikdə və onun rəsmi developer mühitində işləmək istədikdə uyğun ola bilər. Mövcud sifariş sistemi artıq UPS konnektoruna malikdirsə və tələb olunan iş axınları məhduddursa, bu, ən sadə seçim də ola bilər.
Çoxdaşıyıcılı izləmə API-si fərqli memarlıq seçimidir. O, daşıyıcılar arasında vahid inteqrasiya modeli təqdim edə bilər, lakin tətbiq yenə də daşıyıcıya xas status mənalarını, əhatə fərqlərini, autentifikasiya tələblərini və məlumat keyfiyyətini idarə etməlidir. Çoxdaşıyıcılı xidmət yalnız vebhuk təklif etdiyini bildirdiyinə görə seçilməməlidir. Dəstəklənən daşıyıcıları, hadisələrin normallaşdırılmasını, sənədləri, sınaq mühitini, saxlama qaydalarını və əməliyyat dəstəyini yoxlayın.
17TRACK’s Tracking API çoxdaşıyıcılı izləmə yanaşmasını qiymətləndirən komandalar üçün aktualdır, onun official API documentation isə mövcud imkanları, sorğu formatlarını və inteqrasiya tələblərini yoxlamaq üçün istifadə edilməlidir. Bu, konkret UPS iş axını üçün tələb olunan daşıyıcıların və hadisələrin nəzərdə tutulan istifadə ssenarisində dəstəklənib-dəstəklənməsini yoxlamağı əvəz etmir.
Tətbiq yoxlama siyahısı
- Məhsul əhatəsini təsdiqləyin. Seçilmiş UPS xidmətinin tətbiqinizin tələb etdiyi izləmə əməliyyatlarını və bildiriş modelini dəstəklədiyini yoxlayın.
- HTTPS istifadə edin. Qəbul edici tərəf ötürülmə zamanı qorunmalı, URL-lərdə və jurnallarda giriş məlumatlarını açıqlamamalıdır.
- Həqiqiliyi yoxlayın. Provayderin sənədləşdirilmiş imza, token və ya yoxlama üsuluna əməl edin. Heç bir üsul mövcud deyilsə, xidmətə uyğun şəbəkə nəzarətlərindən və sorğu yoxlamasından istifadə edin.
- Emalı idempotent edin. Mövcud olduqda hadisə identifikatorunu saxlayın və ya sabit hadisə sahələrindən ehtiyatlı təkrarlanma əleyhinə açar yaradın.
- Ardıcıllıqdan kənar hadisələri qəbul edin. Gəliş ardıcıllığının skan ardıcıllığına bərabər olduğunu düşünmək əvəzinə hadisə vaxtlarından və sənədləşdirilmiş vəziyyət keçidi siyasətindən istifadə edin.
- Tez cavab qaytarın. Uzunmüddətli tapşırıqları növbəyə yerləşdirin və uğursuz çatdırılmaları, yenidən cəhdləri və dead-letter mesajlarını izləyin.
- Boşluqları uzlaşdırın. Son yeniləməsi olmayan, çatdırılması uğursuz olan və ya vəziyyəti uyğunsuz olan göndərişlər üçün nəzarətli yoxlama prosesi planlaşdırın.
- Şəxsi məlumatları qoruyun. Saxlanılan ünvan və alıcı məlumatlarını məhdudlaşdırın, girişi məhdud edin və biznes ehtiyacına uyğun saxlama qaydaları müəyyənləşdirin.
- Real biznes ssenarilərini sınaqdan keçirin. Çatdırılmış göndərişləri, istisnaları, ləğv edilmiş sifarişləri, təkrarlanan hadisələri, naməlum izləmə nömrələrini və gecikmiş bildirişləri daxil edin.
Qaçınılmalı ümumi səhvlər
Ən geniş yayılmış dizayn səhvi yenidən cəhdlər və itkin hadisələr üçün plan hazırlamadan vebhuku tam həqiqət mənbəyi kimi qəbul etməkdir. Digər səhv sifariş statusunu uyğunlaşdırma qatı olmadan sərbəst mətn əsasında birbaşa yeniləməkdir. Bu, daşıyıcının terminologiyası dəyişdikdə və ya hadisə yalnız bir paketə aid olduqda yanlış müştəri mesajlarına səbəb ola bilər.
Komandalar həmçinin sui-istifadəyə qarşı nəzarəti olmayan vebhuk endpoint-i açıq saxlamaqdan, lazımsız şəxsi məlumatlar ehtiva edən tam payload-ları jurnallara yazmaqdan və hadisə əsas yoxlamadan keçməmiş müştəri bildirişləri göndərməkdən çəkinməlidir. Nəhayət, izləmə cavabında təxmini tarix olduğu üçün yalnız buna əsasən çatdırılma tarixlərinə söz verməyin. Təxminlər dəyişə bilər və müştəriyə yönəlmiş mətn bu qeyri-müəyyənliyi əks etdirməlidir.
İnteqrasiya yanaşmasını necə seçmək olar
Daşıyıcı əhatəsi məhdud olduqda, komanda daşıyıcıya xas məntiqi saxlamağa hazır olduqda və tələb olunan rəsmi funksiyalar mövcud olduqda birbaşa UPS inteqrasiyasını seçin. Biznes bir neçə daşıyıcı arasında vahid daxili interfeysə ehtiyac duyduqda və abstraksiya qatını əsaslandıracaq qədər həcmə və ya mürəkkəbliyə malik olduqda çoxdaşıyıcılı izləmə API-sini nəzərdən keçirin. Hər iki halda yalnız funksiya adlarını deyil, real sənədləri və sınaq davranışını müqayisə edin.
İstehsala keçməzdən əvvəl real izləmə nömrələri və uğursuzluq ssenarilərindən istifadə edərək konsepsiya sübutu həyata keçirin. Abunəliklərin necə yaradıldığını, giriş məlumatlarının necə yeniləndiyini, bildirişlərin necə yoxlandığını, təkrarlanan hadisələrin necə göründüyünü, keçmiş yeniləmələrin necə idarə edildiyini və qəbul edici əlçatmaz olduqda nə baş verdiyini təsdiqləyin. Bu cavablar ilkin nümayişdən sonra inteqrasiyanın etibarlı qalacağını müəyyən edir.
FAQ
UPS izləmə API vebhuku sorğu ilə yoxlamadan daha yaxşıdır?
Heç bir yanaşma avtomatik olaraq daha yaxşı deyil. Vebhuklar planlı yoxlamaları azalda və daha sürətli reaksiyaları dəstəkləyə bilər, sorğu ilə yoxlama isə daha asan idarə oluna və buraxılmış hadisələri uzlaşdırmağa kömək edə bilər. Bir çox istehsal sistemi vebhuk bildirişlərindən məhdud uzlaşdırma sorğuları ilə birlikdə istifadə edir.
Yalnız az sayda göndərişi izləyirəmsə, vebhuka ehtiyacım var?
Mütləq deyil. Kiçik və aşağı tezlikli iş axını üçün sənədləşdirilmiş sorğu prosesi və ya mövcud platforma inteqrasiyası kifayət edə bilər. Yeniləmələr avtomatlaşdırılmış əməliyyatları işə salmalı olduqda və ya müntəzəm əl ilə yoxlama əməliyyat yükü yaratdıqda vebhuk daha cəlbedici olur.
Vebhuk hər UPS skanının sistemimə çatacağına zəmanət verə bilər?
Bunu fərz etməməlisiniz. Çatdırılma davranışı, yenidən cəhdlər, hadisələrin ardıcıllığı və saxlama müddəti konkret xidmətdən asılıdır. İnteqrasiyaya monitorinq, idempotentlik və uzlaşdırma daxil edin, həmçinin tətbiq olunan zəmanətləri mövcud UPS sənədlərində təsdiqləyin.
Hər izləmə hadisəsi müştəriyə e-poçt göndərilməsinə səbəb olmalıdır?
Adətən yox. Daşıyıcı hadisələrini müştəri ilə kommunikasiya qaydalarına uyğunlaşdırın və mesajları alıcı üçün faydalı mərhələlər və ya istisnalarla məhdudlaşdırın. Bildiriş yaratmadıqda belə daxili tarixçə üçün ilkin hadisəni saxlayın.
Biznes çoxdaşıyıcılı izləmə API-sindən nə vaxt istifadə etməlidir?
Biznes bir neçə daşıyıcı vasitəsilə göndəriş etdikdə və ortaq izləmə iş axını istədikdə bunu qiymətləndirmək faydalıdır. Qərar daşıyıcı dəstəyini, normallaşdırılmış məlumatları, vebhuk davranışını, sənədləri, təhlükəsizliyi, sınaqları və inteqrasiyanın saxlanılması üçün tələb olunan səyi nəzərə almalıdır.
