17TRACK-in sifarişlərin yerinə yetirilməsi və qaytarılması inteqrasiyası üçün USPS API sənədləşdirmə yoxlama siyahısı

17TRACK ilə etibarlı USPS inteqrasiyası bir-biri ilə əlaqəli, lakin ayrı iş axınları kimi planlaşdırılmalıdır: USPS sənədləri daşıyıcıya yönəlmiş məlumatları və xidmətləri tənzimləyir, 17TRACK isə daşıyıcılar üzrə göndərişlərin görünürlüğü üçün daha geniş izləmə qatı təqdim edə bilər. Göndərişlərin icrası və qaytarmalar üçün tətbiqetmə komandası istehsal kodunu yazmazdan əvvəl autentifikasiyanı, göndəriş identifikatorlarını, hadisələrin xəritələndirilməsini, tarif və etiket məsuliyyətlərini, sorğulama və ya bildiriş davranışını, xətaların idarə edilməsini, həmçinin çıxış çatdırılması ilə əks logistika arasındakı sərhədləri yoxlamalıdır.

Bu yoxlama siyahısı USPS ilə əlaqəli göndəriş məlumatlarını sifarişlərin idarə edilməsi sistemi, anbar iş axını, müştəriyə yönəlmiş izləmə təcrübəsi və ya qaytarma prosesi ilə birləşdirən tərtibatçılar, e-ticarət əməliyyatları komandaları və həll sahibləri üçün nəzərdə tutulub. Burada hər bir USPS API imkanının 17TRACK vasitəsilə əlçatan olduğu və ya izləmə API-sinin öz-özünə etiket yaratdığı, poçt haqqı aldığı və ya fiziki qaytarmaları idarə etdiyi fərz edilmir.

1. Əvvəlcə inteqrasiya sərhədini müəyyənləşdirin

Hər bir sistemin nə etməli olduğunu sənədləşdirməklə başlayın. USPS sənədləri USPS xidmətlərini və təsdiqlənmiş inteqrator üçün əlçatan interfeysləri təsvir edir. Tətbiq daşıyıcıdan asılı olmayan izləmə iş axınına və ya göndəriş hadisələri üçün vahid interfeysə ehtiyac duyduqda 17TRACK-in İzləmə API-si sənədləri əhəmiyyətlidir. Layihəyə e-ticarət qaytarmalarının idarə edilməsi də daxil olduqda 17RETURNS məhsul səhifəsi aktualdır. Bunlar əlaqəli istifadə hallarıdır, lakin bir-birini əvəz etmir.

• USPS: izləmə, ünvan xidmətləri, qiymətləndirmə, xidmət məlumatları və ya digər sənədləşdirilmiş API-lər kimi daşıyıcıya yönəlmiş hansı funksiyaların tələb olunduğunu təsdiqləyin.
• 17TRACK İzləmə API-si: USPS izləmə nömrələrinin necə göndərildiyini, sorğulandığını, yeniləndiyini və tətbiqin normallaşdırılmış hadisə modelində necə təqdim edildiyini yoxlayın.
• Göndərişlərin icrası platforması: inventarın bölüşdürülməsinə, sifarişin buraxılmasına, etiket yaradılmasına, poçt haqqının ödənilməsinə, anbar təsdiqinə və göndərişin yaradılmasına cavabdeh sistemi müəyyənləşdirin.
• Qaytarma iş axını: qaytarmanı kimin təsdiqlədiyini, qaytarma təlimatlarını və ya etiketlərini kimin yaratdığını, qaytarılan bağlamanı kimin qeyd etdiyini və pulun qaytarılması və ya dəyişdirilməsi ilə bağlı nəticəyə kimin qərar verdiyini müəyyənləşdirin.

Beləliklə, ilk arxitektura qərarı “hansı endpoint-i çağırmalıyıq?” deyil, “hər bir biznes əməliyyatına hansı sistem sahibdir?” sualıdır. Daşıyıcının izləmə API-si icra və ya qaytarmalar üçün əsas qeyd sistemi olmadan görünürlüğü yaxşılaşdıra bilər.

2. USPS tərtibatçı sənədlərinin cari versiyasını yoxlayın

USPS Web Tools və API məlumatlarını başlanğıc nöqtəsi kimi istifadə edin, sonra USPS tərəfindən əlaqələndirilmiş cari tərtibatçı sənədlərinə və məhsula xas istinadlara keçin. Cari vəziyyətini yoxlamadan köhnə kod nümunəsindən endpoint-i, autentifikasiya metodunu, sahə adını və ya istifadədən çıxarılma bildirişini kopyalamayın.

Tətbiqdən əvvəl aşağıdakı sənəd faktlarını layihə qeydində əks etdirin:

• Tələb olunan dəqiq USPS API məhsulu və ya məhsulları.
• Sınaq və istehsal üçün cari əsas URL və mühit məlumatları.
• Qeydiyyat prosesi, tətbiqetmə məlumatları və bu məlumatların icazə verilən istifadəsi.
• Seçilmiş API üçün sənədləşdirilibsə, autentifikasiya axını, tokenin etibarlılıq müddəti, əhatə dairələri və məlumatların yenilənməsi tələbləri.
• Tələb olunan başlıqlar, məzmun növləri, sorğu formatları, cavab formatları və versiya identifikatorları.
• Dəstəklənən əməliyyatlar və hesab, xidmət, coğrafiya və ya məlumat növünə əsaslanan məhdudiyyətlər.
• Sorğu limitləri, vaxt aşımı ilə bağlı təlimatlar, texniki xidmət bildirişləri və sənədləşdirilmiş xəta cavabları.
• USPS cavab məlumatlarının saxlanmasını, nümayişini, təkrar istifadəsini və yayılmasını tənzimləyən şərtlər.

Tələb rəsmi sənədlərdə göstərilməyibsə, onu USPS və ya müvafiq hesab nümayəndəsi ilə birbaşa təsdiqlənməli məsələ kimi qeyd edin. Köhnə USPS Web Tools nümunəsinin cari API-ni təmsil etdiyini düşünməyin və bir USPS məhsulunda təsvir edilən funksiyanın digər məhsulda mövcud olduğunu fərz etməyin.

3. Autentifikasiya və təhlükəsizlik üzrə yoxlama siyahısı hazırlayın

Autentifikasiya biznes məntiqindən ayrıca sınaqdan keçirilməlidir. Komanda tətbiq kodunu dəyişdirmədən və əlaqəsiz izləmə funksiyalarını dayandırmadan məlumatları ləğv edib əvəz edə bilməlidir.

1. Müştəri sirlərini, API açarlarını, tokenləri və sertifikatları mənbə kodunda və ya müştəri tərəfli tətbiqdə deyil, idarə olunan məxfi məlumat anbarında saxlayın.
2. Seçilmiş USPS API-nin cari sənədlərdə təsvir edilən autentifikasiya metodundan istifadə edib-etmədiyini təsdiqləyin. Token sorğuları, əhatə dairələri, müddətin bitməsi və yeniləmə və ya yenidən avtorizasiya davranışı daxil olmaqla, sənədləşdirilmiş axını dəqiq tətbiq edin.
3. USPS buna icazə verdikdə ayrı məlumatlar və ya mühitlərdən istifadə edin ki, sınaq trafiki istehsal trafiki ilə qarışdırılmasın.
4. Müştəri ünvanı məlumatlarına, göndəriş məlumatlarına və qaytarma məlumatlarına çıxışı ehtiyacı olan rollara uyğun məhdudlaşdırın.
5. Kimlik məlumatlarını və lazımsız şəxsi məlumatları tətbiq jurnallarından silin və ya maskalayın.
6. Autentifikasiya uğursuzluqlarını korrelyasiya identifikatoru ilə qeyd edin, lakin sirləri və ya tam həssas məlumat yüklərini jurnala yazmayın.
7. Tokenin müddəti bitdikdə, məlumat ləğv edildikdə, sorğu təkrar göndərildikdə və ya autentifikasiya xidməti müvəqqəti əlçatmaz olduqda davranışı sınaqdan keçirin.

17TRACK inteqrasiyası üçün müvafiq sənədlərdə başqa tənzimləmə açıq şəkildə müəyyən edilmədiyi halda, daşıyıcı məlumatlarını və 17TRACK məlumatlarını konseptual olaraq ayrı saxlayın. 17TRACK vasitəsilə yönləndirilən izləmə sorğusunun USPS poçt haqqı, hesab və ya etiket xidmətlərinə çıxış verdiyini düşünmək olmaz.

4. İdentifikatorları və məlumat sahibliyini təsdiqləyin

Göndərişin identikliyi təkrarlanan sifarişlərin və pozulmuş qaytarma əlaqələrinin tez-tez səbəbidir. Sistemləri birləşdirməzdən əvvəl sahə xəritəsi yaradın. Ən azı aşağıdakı dəyərləri fərqləndirin:

Biznes dəyəri	Tətbiqetmə sualı	Yoxlama nöqtəsi
Sifariş ID-si	Sifarişə hansı e-ticarət və ya OMS qeydi sahibdir?	Bir sifariş bir neçə bağlama ehtiva edə bilər.
Göndərişin icrası ID-si	Göndərişi hansı anbar və ya 3PL əməliyyatı buraxıb?	Onu izləmə nömrəsi ilə əvəz etməyin.
İzləmə nömrəsi	USPS-ə və ya 17TRACK-ə hansı identifikator göndərilir?	Formatı, daşıyıcı təyinatını və dublikatların işlənməsini yoxlayın.
Qaytarma ID-si	Bağlamaya hansı avtorizasiya və ya qaytarma işi sahibdir?	Qaytarma göndərişi çıxış göndərişinin üzərinə yazılmamalıdır.
Hadisə ID-si və zaman möhürü	Təkrarlanan və ya gecikmiş hadisələr necə işlənir?	Sıralama, vaxt qurşağı və idempotentlik qaydalarını müəyyənləşdirin.

Mümkün olduqda orijinal daşıyıcı hadisəsini və normallaşdırılmış daxili statusu qoruyun. “Tranzitdə” kimi normallaşdırılmış status vitrinlər üçün faydalıdır, lakin əməliyyat komandalarına araşdırma üçün USPS-in orijinal hadisə mətni, məkan və hadisə vaxtı da lazım ola bilər.

5. İzləmə məlumatlarının qəbulunu və statusların xəritələndirilməsini layihələndirin

Canlı trafiki qoşmazdan əvvəl biznesin həqiqətən ehtiyac duyduğu həyat dövrü vəziyyətlərini siyahıya alın. Tipik vəziyyətlərə etiket yaradılıb, qəbul edilib, tranzitdədir, çatdırılma üçün yoldadır, çatdırılıb, çatdırılma istisnası və göndərənə qaytarılıb daxil ola bilər. USPS hadisələrinin dəqiq lüğəti və 17TRACK vasitəsilə təqdim edilən hadisələr müvafiq sənədlərdə və sınaq cavablarında yoxlanılmalıdır; yalnız status adlarına əsasən xəritələndirmə yaratmayın.

Hər bir hadisə üçün aşağıdakıları müəyyənləşdirin:

• Mənbə sistemi və orijinal hadisə kodu və ya təsviri.
• Normallaşdırılmış daxili status.
• Hadisənin müştəriyə, əməliyyatlara və ya hər ikisinə görünən olub-olmaması.
• Sifarişi irəli aparıb-aparmadığı, SLA-nı dayandırıb-dayandırmadığı, bildiriş başladıb-başlatmadığı və ya istisna işi açıb-açmadığı.
• Daha sonrakı hadisənin onu düzəldə və ya əvəz edə bilib-bilməməsi.
• Dublikat və ardıcıllığı pozulmuş hadisələrin necə işlənməsi.

Yeni izləmə nömrələrinin sistemə necə daxil olacağına da qərar verin. İlk daşıyıcı skanı görünməzdən əvvəl göndəriş yaradıla bilər. Tətbiqiniz “izləmə nömrəsi qeydiyyata alınıb” vəziyyətini “daşıyıcı bağlamanı qəbul edib” vəziyyətindən fərqləndirməlidir; skan edilməmiş göndərişi artıq şəbəkə üzrə hərəkət edən kimi göstərməyin.

6. Sorğulama və bildirişlər arasında seçim edin

Tətbiq yeni izləmə məlumatlarının necə əldə edildiyini sənədləşdirməlidir. Seçilmiş USPS və ya 17TRACK məhsulu bildiriş mexanizmini dəstəkləyirsə, rəsmi sənədlərdə onun abunə modeli, çatdırılma formatı, təkrar cəhd davranışı, imzalama və ya yoxlama metodu və limitlərini yoxlayın. Sorğulama tələb olunursa, intervalı, dayandırma şərtlərini, geri çəkilmə strategiyasını və yeni hadisəsi olmayan göndərişlərlə davranışı müəyyənləşdirin.

Müştəri izləmə səhifəsini yenilədiyi üçün aqressiv sorğulama aparmayın. Müvafiq hallarda server tərəfli hadisə anbarından və ya keşdən istifadə edin, keçici xətalar üçün eksponensial geri çəkilmə tətbiq edin və məlumatların qəbulunu idempotent edin. Uğursuz sorğu ikinci göndəriş, ikinci qaytarma və ya dublikat müştəri bildirişi yaratmamalıdır.

Əməliyyat xəbərdarlıqları autentifikasiya uğursuzluqlarını, davamlı tarif limiti cavablarını, düzgün formalaşdırılmamış daşıyıcı cavablarını, hadisələrin işlənməsi xətalarını və həll olunmamış qalan göndərişlərin artmasını əhatə etməlidir. Monitorinq həm API sağlamlığını, həm də biznes sağlamlığını göstərməlidir: uğurlu HTTP cavabı göndərişin düzgün sifarişlə uyğunlaşdırıldığı anlamına gəlmir.

7. Göndərişlərin icrasını qaytarmalardan ayırın

Çıxış göndərişlərinin icrası və qaytarmalar göndəriş məlumatlarını paylaşır, lakin onların biznes qaydaları fərqlidir. Çıxış göndərişlərinin icrası adətən sifarişlə başlayır və çatdırılma və ya istisna ilə başa çatır. Qaytarma müştərinin və ya satıcının qərarı ilə başlayır, avtorizasiya tələb edə bilər və qəbul yoxlaması, pulun qaytarılması, dəyişdirmə və ya başqa nəticə ilə başa çatır.

Daşıyıcı izləməsini əlavə etməzdən əvvəl qaytarma inteqrasiyası üçün bu qərarları sənədləşdirin:

• Hansı qaytarma səbəbləri qəbul edilir və onları kim təsdiqləyir?
• Qaytarma etiketi satıcının göndəriş platforması, USPS ilə əlaqəli iş axını, üçüncü tərəf qaytarma sistemi və ya başqa provayder tərəfindən yaradılır?
• Qaytarma izləmə nömrəsi çıxış izləmə nömrəsini əvəz etmədən ilkin sifarişlə necə əlaqələndirilir?
• Hansı hadisə “qaytarma tranzitdədir”, “qaytarma çatdırılıb” və ya “yoxlama üçün qəbul edilib” hesab olunur?
• Qaytarma anbara çatdırıldıqdan sonra məhsul yoxlanılana qədər gözləmədə qala bilərmi?
• Müştəri icazəsiz bağlama göndərdikdə və ya başqa daşıyıcıdan istifadə etdikdə nə baş verir?

Layihəyə xüsusi qaytarma idarəetmə iş axını lazım olduqda 17RETURNS, göndərişlərin görünürlüğü üçün isə 17TRACK API-si aktual ola bilər. Etiket yaradılması, pulun qaytarılmasının təsdiqi, anbara qəbul və ya daşıyıcı hesabının idarə edilməsi kimi funksiyaları hər hansı məhsula həvalə etməzdən əvvəl cari məhsul sənədlərini yoxlayın.

8. İnteqrasiyanı realistik ssenarilərlə sınaqdan keçirin

Bir çatdırılmış bağlama üzrə uğurlu ssenari testi kifayət deyil. Aşağıdakıları əhatə edən sınaq matrisi yaradın:

1. Son hadisəsi olmayan etibarlı USPS izləmə nömrəsi.
2. Hadisələri ardıcıllıqdan kənar qəbul edilən göndəriş.
3. Təkrarlanan çatdırılma və ya istisna hadisələri.
4. Yanlış, səhv yazılmış və ya dəstəklənməyən identifikator.
5. Göndərənə qaytarılan bağlama.
6. Eyni sifarişlə əlaqəli çıxış göndərişi və qaytarma göndərişi.
7. API vaxt aşımı, tarif limiti cavabı, autentifikasiya uğursuzluğu və düzgün formalaşdırılmamış cavab.
8. Daşıyıcı təyinatı əvvəlcə məlum olmayan və ya təsdiq tələb edən göndəriş.
9. Əməliyyat istifadəçisi sifarişi redaktə edərkən müştəriyə yönəlmiş səhifənin yeni hadisə qəbul etməsi.

Hər bir ssenari üçün gözlənilən verilənlər bazası nəticəsini, müştəri mesajını, əməliyyat tədbirini, təkrar cəhd davranışını və audit izini qeyd edin. Sintetik və ya səlahiyyətli məlumatlarla sınaq keçirin və şəxsi ünvanların və əlaqə məlumatlarının jurnallarda və ya ictimai izləmə səhifələrində təsdiqlənmiş biznes məqsədindən artıq açıqlanmadığını yoxlayın.

9. İstehsala hazırlıq baxışı

İş sahibi istifadəyə verməzdən əvvəl beş praktiki suala cavab verə bilməlidir: Göndərişi hansı sistem yaradır? İzləmə nömrəsinə hansı sistem sahibdir? Müştəri bildirişlərini hansı sistem göndərir? Qaytarma işini hansı sistem idarə edir? İtkin və ya ziddiyyətli hadisəni hansı komanda araşdırır?

Baxışı yalnız cari USPS sənədlərini, seçilmiş 17TRACK API sənədlərini və məhsula xas şərtləri və ya əməliyyat təlimatlarını yoxladıqdan sonra tamamlayın. Endpoint istinadlarının, sahə xəritələrinin, sınaq sübutlarının, məlumat sahiblərinin, eskalasiya əlaqələrinin və birbaşa təsdiq tələb edən fərziyyələrin versiyalı qeydini saxlayın. API versiyası, daşıyıcı iş axını, anbar prosesi və ya qaytarma siyasəti dəyişdikdə qeydə yenidən baxın.

FAQ

17TRACK hər bir göndərişlərin icrası funksiyası üçün USPS API-sini əvəz edə bilərmi?

Heç bir fərziyyə irəli sürülməməlidir. 17TRACK izləmə qatı kimi qiymətləndirilə bilər, lakin qiymətləndirmə, ünvan xidmətləri, poçt haqqı və ya digər daşıyıcı əməliyyatları kimi USPS-ə yönəlmiş funksiyalar müvafiq məhsul sənədləri və hesab tələbləri əsasında təsdiqlənməlidir. İzləmə görünürlüğü etiket alışı və ya göndərişlərin icrası ilə eyni deyil.

Həm USPS, həm də 17TRACK inteqrasiyalarına ehtiyacım varmı?

Həmişə yox. Tətbiq yalnız dəqiq müəyyən edilmiş USPS funksiyasına ehtiyac duyursa, birbaşa USPS inteqrasiyası uyğun ola bilər. Bir neçə daşıyıcı üzrə normallaşdırılmış izləmə və ya daşıyıcıdan asılı olmayan izləmə iş axını tələb olunursa, 17TRACK aktual ola bilər. Qərar yalnız izləmə nömrəsinə deyil, tələb olunan imkanlara, sahiblik modelinə və məlumat axınına əsaslanmalıdır.

Qaytarma izləmə nömrəsi çıxış izləmə nömrəsini əvəz etməlidirmi?

Xeyr. Qaytarmanı ilkin sifariş və göndərişlərin icrası qeydi ilə əlaqələndirilmiş ayrıca göndəriş və ya qaytarma hərəkəti kimi saxlayın. Bu, çıxış çatdırılma tarixçəsini qoruyur və qaytarmaya öz hadisələrinə, istisnalarına və əməliyyat nəticəsinə malik olmağa imkan verir.

Çatışmayan izləmə hadisələri necə işlənməlidir?

Sənədləşdirilmiş təkrar cəhd və eskalasiya siyasəti müəyyənləşdirin. Çatışmayan hadisə normal daşıyıcı vaxtlamasını, etibarsız identifikatoru, məlumat qəbulunda xətanı və ya daşıyıcı tərəfdə gecikməni göstərə bilər. Yalnız bir sorğulama cəhdi yeni hadisə qaytarmadığı üçün göndərişi itmiş kimi işarələməyin.

USPS məlumatları harada saxlanmalıdır?

İdarə olunan server tərəfli məxfi məlumat anbarından istifadə edin və çıxışı rollara görə məhdudlaşdırın. Məlumatları heç vaxt vitrin JavaScript-ində, mobil müştəri kodunda, ictimai repozitoriyalarda və ya jurnallarda yerləşdirməyin. İstehsala yerləşdirməzdən əvvəl cari USPS autentifikasiya və məlumatların idarə edilməsi tələblərini təsdiqləyin.

Mənbələr

• USPS Web Tools və API-lər — biznes API məlumatları üçün USPS-in rəsmi başlanğıc nöqtəsi.
• 17TRACK İzləmə API-si sənədləri — 17TRACK API inteqrasiyası üçün rəsmi sənədlər.
• 17RETURNS — qaytarmaların idarə edilməsi istifadə halları üçün rəsmi məhsul məlumatları.
• 17TRACK API — izləmə API-si ssenariləri üçün rəsmi məhsul icmalı.