Қытайдан Еуропаға және АҚШ-қа жөнелтілімдерді бір API арқылы қалай бақылауға болады

Қытайдан Еуропа мен АҚШ-қа жіберілімдерді бір API арқылы қадағалау үшін тапсырыстар жүйесін бірнеше тасымалдаушыны қолдайтын қадағалау қызметіне қосыңыз, әрбір сәлемдемені оның қадағалау нөмірі және қажет тасымалдаушы деректерімен тіркеңіз, содан кейін қадағалау жаңартуларын ортақ жіберілім жазбасына енгізіңіз. Интеграция халықаралық тасымалдаушы ауысуларын, сканерлеудің кешігуін және соңғы жеткізуге арналған бөлек қадағалау нөмірлерін ескеруі тиіс. Бір API қадағалау ақпаратына қолжетімділікті біріктіре алады, бірақ тасымалдаушы хабарламаған оқиғаларды жасай алмайды.

Әзірлеушілер мен электрондық коммерция операцияларының командалары үшін мақсат тек мәртебені көрсету емес. Мақсат — әрбір нақты сәлемдемені дұрыс тапсырыспен байланыстыру, жаңылыстыратын жаңартулар жібермей клиенттерді хабардар ету және араласуды қажет ететін жіберілімдерді анықтау. Бұл нұсқаулық осы жұмыс процесін қалай құру керегін және 17TRACK Tracking API сияқты қызметті нақты тасымалдау бағыттарыңызға сәйкестігін қалай бағалау керегін түсіндіреді.

Жеткізілетін елден ғана емес, тасымалдау бағытына сүйеніп бастаңыз

Қытайдан Еуропадағы немесе АҚШ-тағы мекенжайға бара жатқан сәлемдеме жинау қызметі, халықаралық тасымалдау желісі, кедендік өңдеу және межелі жердегі жеткізу тасымалдаушысы арқылы өтуі мүмкін. Кейбір тасымалдау қызметтері бұл қозғалыстарды бір қадағалау нөмірі арқылы көрсетеді. Басқалары жолдың кейінгі кезеңінде бөлек жеткізу анықтамасын ұсынады.

Сондықтан интеграцияны тек ел деңгейіндегі қамтумен тексеру жеткіліксіз. Провайдер тасымалдаушыны тани отырып, белгілі бір тасымалдау өніміне қажет барлық оқиғаларды қайтармауы мүмкін. Сол сияқты бастапқы сканерлеу межелі жердегі жеткізу сканерлері қолжетімді болатынын білдірмейді.

Интеграция алдында бизнесіңіз іс жүзінде жіберетін сәлемдемелер негізінде бағыттар тізімін жасаңыз. Бастапқы логистика провайдерін, тасымалдау қызметін, межелі нарықты, белгілі жеткізу тасымалдаушысын және қадағалау нөмірлерінің форматтарын тіркеңіз. Тестілеу кезінде Еуропа нарықтарын жеке қарастырыңыз және бір елдегі сәтті жеткізу бүкіл өңірде қамту бар екенін дәлелдейді деп есептемеңіз.

• Операциялар үшін: қадағалаудағы олқылықтар қай жерде қолмен жұмыс істеуге немесе клиенттердің хабарласуына әкелетінін анықтаңыз.
• Инженерия үшін: қай жүйелер жіберілімдерді жасайтынын және қай жүйелерге жаңартулар қажет екенін анықтаңыз.
• Сатып алу үшін: сол бағыттар тізіміндегі нақты тасымалдаушылар мен қызметтерге қолдау көрсетілетінін тексеріңіз.

Бір қадағалау API-ы не істеуі керек және не істей алмайды

Бірнеше тасымалдаушыны қолдайтын Tracking API қолданбаңызға әр тасымалдаушының қосылымын бөлек өңдеуді талап етпей, ортақ интеграция қабатын береді. Қызмет пен интеграция әдісіне байланысты қолданбаңыз жаңартуларды ала алады, кері шақыруларды қабылдай алады немесе осы екі тәсілді бірге пайдалана алады. Өндірістік жұмыс процесін жобаламас бұрын провайдердің құжаттамасынан қолдау көрсетілетін тетіктерді растаңыз.

Пайдалы абстракция — бірізді жіберілім моделі. Тапсырыстарды басқару жүйеңіз әр тасымалдаушының тұжырымдары үшін әртүрлі бизнес логикасын қажет етпеуі тиіс, бірақ қолдау көрсету және тексеру үшін бастапқы ақпаратты сақтауы керек.

Біріктірілген қадағалау үздіксіз физикалық көрінуді, жеткізу болжамын немесе кеден тарихының толық болуын кепілдемейді. Тасымалдаушы хабарлайтын жаңа сканерлеу болмаса да, API қосылымы дұрыс жұмыс істеп тұруы мүмкін. Қадағалау тасымалдау жапсырмаларын сатып алудан, кеден декларацияларын дайындаудан және жеткізу қызметтерін ұйымдастырудан бөлек. Бұл функциялар қамтылған деп есептемеңіз.

Интеграцияны сәлемдеме деңгейіндегі жазба негізінде құрыңыз

1. Тапсырыстарды, жіберілімдерді және қадағалау идентификаторларын ажыратыңыз

Бір электрондық коммерция тапсырысында бірнеше сәлемдеме болуы мүмкін және олар әртүрлі уақытта жетуі ықтимал. Тұрақты идентификатор ретінде ішкі сәлемдеме немесе жіберілім ID пайдаланыңыз. Клиент тапсырысын осы жазбамен байланыстырып, тасымалдаушының қадағалау идентификаторларын оған тіркеңіз.

Практикалық ішкі модель мыналарды қамтуы керек:

• Ішкі тапсырыс ID және сәлемдеме ID.
• Бастапқы қадағалау нөмірі және API пайдаланатын тасымалдаушы идентификаторы.
• Расталған межелі тасымалдаушының кез келген қадағалау нөмірі.
• Тасымалдау қызметі және межелі ел.
• Ағымдағы қалыпқа келтірілген мәртебе және тасымалдаушының бастапқы сипаттамасы.
• Оқиға уақыты, берілген жағдайда оқиға орны және жүйеңіздің жаңартуды қабылдаған уақыты.
• Тіркеу күйі, соңғы сәтті синхрондау және шешілмеген интеграция қателері.

Бұл — ұсынылатын қолданба өрістері, әр провайдер олардың барлығын қайтарады деген мәлімдеме емес. Ішкі схемаңызды провайдердің жауап форматынан бөлек ұстаңыз, сонда болашақ API өзгерісі тапсырыс дерекқорын қайта жобалауды талап етпейді.

2. Сәлемдемелерді сенімді бизнес оқиғасы негізінде тіркеңіз

Қадағалау нөмірі сәлемдемеге тағайындалған кезде тіркеңіз, біреу тапсырыс бетін ашқан сайын емес. Қойма немесе тапсырыстар жүйесінен алынған жіберілім жасалды оқиғасы әдетте жақсырақ триггер болады. Егер жапсырма жарамсыз деп танылса немесе ауыстырылса, тасталған нөмірді жалғыз қадағалау анықтамасы ретінде қалдырмай, сәлемдеме идентификаторларының байланыстарын жаңартыңыз.

Нөмірдің бар екенін және электрондық кесте форматтауынан бүлінбегенін тексеріңіз. Маңызды бастапқы нөлдерді сақтаңыз. Тасымалдау жүйеңіз тасымалдаушыны білсе, автоматты сәйкестендіруге толық сенбей, бұл ақпаратты сақтаңыз: нөмір форматтары қайталануы мүмкін.

Тіркеу жауабын әрбір жіберілім деңгейінде оқыңыз. Сәтті HTTP сұрауы топтағы әр элемент қабылданды дегенді білдірмейді. Сәтсіздіктерді қайта әрекет кезегінде сақтап, операциялар тобына жарамсыз немесе екіұшты жіберілімдерді түзету мүмкіндігін беріңіз.

3. Клиент хабарламаларын қоспас бұрын жаңартуларды жеткізуді жобалаңыз

Таңдалған қызмет вебхуктарды қолдаса, жаңартуларды алу үшін оның құжатталған кері шақыру механизмін пайдаланыңыз. Тексеру тақырыбын өзіңіз ойлап таппай, қолжетімді аутентификация немесе қолтаңба әдісін растаңыз. Тіркелгі деректерін серверде сақтаңыз, HTTPS талап етіңіз және API құпияларын браузер кодына немесе клиенттерге арналған сілтемелерге қоспаңыз.

Қабылдаушыңыз жаңартуды растаудан бұрын оны сенімді түрде қабылдауы керек, содан кейін оны асинхронды өңдеңіз. Қайталанатын жеткізілімдерге және ретсіз келетін оқиғаларға дайындалыңыз. Мүмкін болса, провайдердің оқиға ID пайдаланыңыз; әйтпесе тұрақты оқиға атрибуттары арқылы құжатталған қайталануды жою ережесін анықтаңыз.

Сауалнама арқылы алу қажет болса, оны провайдердің құжатталған шектеулері мен операциялық қажеттіліктеріңізге сай жоспарлаңыз. Rate limit жауаптарынан кейін қарқынды біртіндеп азайтыңыз, синхронды қайта әрекет ету шарықтауларынан аулақ болыңыз және сақтау мен салыстыру саясатыңызға сәйкес аяқталған жіберілімдерді қажетсіз тексеруді тоқтатыңыз. Жоспарланған салыстыру тапсырмасы қызмет алуға мүмкіндік берген жағдайда өткізіп алған жаңартуларды анықтауға көмектеседі.

4. Мағынаны жоғалтпай мәртебелерді қалыпқа келтіріңіз

Тапсырыстар жүйесі мен қолдау тобы бірізді түсіндіре алатын ішкі мәртебелердің шағын жиынтығын пайдаланыңыз. Мысалдар: ақпарат алынды, жолда, жеткізуге шықты, жеткізілді, жеткізу ерекшелігі және қайтарылды. Бұл — ұсынылатын қолданба санаттары, кез келген провайдердің нақты мәртебе кодтарының сипаттамасы емес.

Тасымалдаушының толық оқиғасын қалыпқа келтірілген мәртебемен бірге сақтаңыз. Сәтсіз жеткізу әрекеті, мекенжай мәселесі және кеденге қатысты кідіріс назар аударуды қажет етуі мүмкін, бірақ олардың жауабы бірдей болмайды. Барлығын жалпы ерекшелікке айналдыру деректерді сақтауды жеңілдеткенімен, әрекет ету үшін пайдалылығын азайтады.

Жапсырма жасалғанын физикалық түрде алып кетумен теңестірмеңіз. Сол сияқты оқиғада кеден нысаны аталғаны үшін сәлемдемені кеденнен өтті деп белгілемеңіз. Оқиғаның нақты мағынасына сәйкес тіл пайдаланыңыз.

Халықаралық тасымалдаушы ауысуларын нақты өңдеңіз

Ең маңызды интеграциялық сынақ көбіне бастапқы желі мен межелі жердегі жеткізу арасындағы ауысу болады. Бастапқы анықтаманы және расталған соңғы жеткізу анықтамасын сақтаңыз. Жаңа қадағалау нөмірі автоматты түрде екінші жіберілім емес, сол сәлемдеменің тағы бір идентификаторы болуы керек.

Идентификаторларды байланыс тек логистика провайдері, қадағалау жауабы немесе тасымалдау жүйесі сияқты сенімді дереккөзден алынғанда ғана жасаңыз. Оқиға уақыттарының ұқсастығы немесе межелі елдердің сәйкестігі екі нөмірдің бір сәлемдемеге тиесілі екенін дәлелдеуге жеткіліксіз.

Оқиға уақытын қабылдау уақытынан бөлек сақтаңыз. Ақпарат желілер арасында қозғалғанда, ескі оқиға жүйеңізге жаңасынан кейін жетуі мүмкін. Берілген уақыт белдеуі ығысуын сақтаңыз, өңдеу үшін уақыт белгілерін қалыпқа келтіріңіз және қолдау көрсетілмейтін уақыт белдеуін тағайындаудың орнына екіұшты бастапқы мәндерді сақтаңыз.

Клиенттерге соңғы маңызды мәртебені көрінетін жаңарту уақытымен көрсетіңіз. Межелі тасымалдаушы әлі сканерлеу туралы хабарламаған болса, қадағалау басқа жаңартуды күтіп тұрғанын түсіндіріңіз. Сәлемдеме жоғалды, соңғы сканерлеу орнында тұр немесе межелі елге жетті деп болжамаңыз.

17TRACK осы жұмыс процесінде қай жерде қолданылады

Қолданбаңызға бірнеше тасымалдаушыны қолдайтын қадағалау интеграциясы қажет болғанда, 17TRACK ұсынатын Tracking API қызметі өзекті болады. Оның ресми API құжаттамасы аутентификацияны, тіркеуді, жауаптарды өңдеуді және қолдау көрсетілетін жаңарту жұмыс процестерін іске асыруға бағыт беруі керек. Тұтынушыларға арналған қадағалау бетін интеграция интерфейсі деп қарастырмай, құжатталған API келісімін пайдаланыңыз.

Оны өз іске асыруыңызға қолданатын операциялық талаптармен бағалаңыз: тасымалдаушыны дұрыс сәйкестендіру, бағыттарыңыздағы пайдалы оқиғалар, ауысулардың үздіксіздігі, қателерден қалпына келу және жаңартуларды басқарылатын жеткізу. Өндірістік жобаны бекітпес бұрын коммерциялық шарттарды, пайдалануды есепке алуды, сұрау шектерін және қажет есептік жазба конфигурациясын растаңыз.

Біріктірілген API таңдаудың басты себебі — нақты пайдаланатын бағыттар үшін интеграция күрделілігінің азаюы. Бұл артықшылықты нақты сәлемдемелермен тексеру қажет. Жалпы қамту сипаттамасы кең көрінгені үшін ғана ешбір провайдерді таңдамаңыз.

Іске қоспас бұрын бағытқа негізделген пилоттық сынақ жүргізіңіз

Қалыпты жеткізілімдер мен күрделі жағдайларды қамтитын сынақ жиынтығын пайдаланыңыз. Тарихи жіберілімдер мәртебелерді сәйкестендіруді тексеруге көмектеседі, ал нақты жіберілімдер жаңартулардың жеткізілуі мен операциялық уақытты көрсетеді. Екі сынақтың ешқайсысы барлық сұраққа жеке жауап бермейді.

• Қытайдан АҚШ-қа жеткізу: бастапқы оқиғаларды, кез келген халықаралық ауысуды және соңғы жеткізу оқиғасын тексеріңіз.
• Қытайдан Еуропаға жеткізу: іс жүзінде пайдаланатын межелі елдер мен тасымалдау қызметтерін тексеріңіз.
• Жаңа жапсырма: физикалық сканерлеусіз сәлемдеме қозғалып жатыр деп көрсетілмейтініне көз жеткізіңіз.
• Өзгертілген жеткізу анықтамасы: байланыстың дұрыс сәлемдемеге тіркелгенін растаңыз.
• Жеткізу ерекшелігі: толық себептің тиісті операциялық кезекке жететінін тексеріңіз.
• Бөлінген тапсырыс: бір сәлемдеменің жеткізілуі бүкіл тапсырысты жаппайтынын растаңыз.
• Қайталанған немесе кешіккен жаңарту: оның қайталама хабарламалар жасамайтынын немесе жаңа мәртебені қате алмастырмайтынын растаңыз.
• Уақытша интеграция ақауы: қайта әрекет етуді, салыстыруды және қолдау көрінуін тексеріңіз.

Нәтижелерді қарамас бұрын қабылдау критерийлерін белгілеңіз. Тіркеудің сәтті болуын, тасымалдаушының қате тағайындалуын, жоғалған маңызды кезеңдерді, жаңартуды өңдеу кідірістерін және клиенттерге қайталанған хабарламаларды өлшеңіз. Қолдау көрсетілмейтін әмбебап өлшемді көшірмей, бизнесіңіз үшін қолайлы шектерді анықтаңыз. Жоғалған оқиғаны API-ға жатқызбас бұрын оны тасымалдаушының жеке жазбасымен салыстырыңыз.

Деректердің жаңалығын API қолжетімділігінен бөлек бақылаңыз

API Monitoring екі түрлі сұраққа жауап беруі керек: интеграция жұмыс істеп тұр ма және жіберілім ақпараты пайдалы ма? Сәтті сұраулар тек бірінші сұраққа жауап береді. Сондай-ақ тіркеулерде қателер жиналып жатқанын, кері шақырулардың сәтсіз болып жатқанын немесе бағыттың күтілген маңызды кезеңдерді бермей қалғанын білуіңіз керек.

• Интеграцияның күйі: аутентификация қателері, сұрау қателері, rate limit жауаптары, кері шақыру сәтсіздіктері және кезек жинақталуы.
• Деректер сапасы: белгісіз мәртебелер, қате уақыт белгілері, шешілмеген тасымалдаушы сәйкестіктері және күтпеген идентификатор өзгерістері.
• Жіберілімнің жаңалығы: бағыт пен тасымалдау қызметі бойынша бөлінген соңғы тасымалдаушы оқиғасынан бері өткен уақыт.
• Бизнеске әсері: ерекшеліктерді өңдеу жүктемесі, сәтсіз хабарламалар және қате аяқталды деп белгіленген тапсырыстар.

Сканерлеусіз ұзақ уақыт бір тасымалдау қызметінде қалыпты, ал басқасында әдеттен тыс болуы мүмкін. Тексерулерді басымдыққа қою үшін бағытқа тән күтулер мен байқалған жіберілім тарихын пайдаланыңыз. Интеграция қатесі туралы ескертуді жіберілім кідірісі туралы ескертуден бөлек ұстаңыз, сонда оны тиісті команда алады.

Клиент хабарламалары әрбір бастапқы оқиғаға емес, расталған маңызды кезеңдерге негізделуі керек. Қайталанатын хабарламаларды басыңыз, жеткізу әрекетін аяқталған жеткізуден ажыратыңыз және бастапқы деректер қолдамайтын келу күндерін уәде етпеңіз. Қадағалау деректеріне қолжетімділікті шектеп, жеке ақпаратты жұмыс процесіңіз талап ететін жерде ғана сақтаңыз.

Жиі қойылатын сұрақтар

Бір API Қытайдағы бастапқы тасымалдаушыны да, межелі жердегі жеткізу тасымалдаушысын да қадағалай ала ма?

Қатысты қызметтер мен идентификатор байланыстарына қолдау көрсетілсе, бірнеше тасымалдаушы қызметі сапардың екі бөлігіндегі оқиғаларды біріктіре алады. Толық бағытты нақты сәлемдемелермен тексеріңіз. Бастапқы қадағалау нөмірінің танылуы межелі жеткізу ақпараты қолжетімді болатынын дәлелдемейді.

Сәлемдеме Қытайдан шыққаннан кейін қадағалау неге жаңартылмайды?

Мүмкін себептерге физикалық сканерлеулер арасындағы үзіліс, есеп берудің кешігуі немесе басқа жеткізу анықтамасына ауысу жатады. Бастапқы оқиғаларды және берілген соңғы жеткізу нөмірін тексеріп, содан кейін тиісті тасымалдаушы жазбасымен салыстырыңыз. Қадағалаудағы үзіліс өздігінен сәлемдеменің жоғалғанын немесе кеденде ұсталғанын білдірмейді.

Қолданба вебхуктарды немесе сауалнама арқылы алуды пайдалануы керек пе?

Провайдеріңіз құжаттаған тетіктерді пайдаланыңыз. Қолдау көрсетілген жағдайда вебхуктар қайталанатын тексерулерді азайта алады, ал рұқсат етілген алу сұраулары салыстыруды қолдайды. Екі тәсілде де клиенттерге хабарламаларға сүйенбес бұрын қайталануларды өңдеуді, қайта әрекет ету басқаруын және бақылауды құрыңыз.

Қадағалау API-ы жеткізу күнін немесе кедендік ресімдеуді кепілдей ала ма?

Қадағалау деректері екеуіне де кепілдік бермейді. Егер болжамды жеткізу күні берілсе, оның дереккөзін сақтап, оны болжам ретінде көрсетіңіз. Кеденге қатысты сканерлеулерді нақты тұжырымдарына сәйкес сипаттаңыз және нәтиже анық көрсетілмесе, оны ресімделді деп түсіндірмеңіз.

API жоспарын таңдамас бұрын нені тексеру керек?

Тасымалдаушыларыңыз бен тасымалдау қызметтерін, тіркеу талаптарын, жаңарту әдістерін, пайдалануды есепке алуды, сұрау шектерін, деректердің қолжетімділігін және қолдау шарттарын растаңыз. Ауыстырылған нөмірлердің, қайталама тіркеулердің және тарихи іздеулердің коммерциялық тұрғыда қалай өңделетінін сұраңыз. Бюджетіңізге немесе архитектураңызға әсер ететін талаптар үшін қолданыстағы құжаттама мен жазбаша растауды пайдаланыңыз.

Дереккөздер

• 17TRACK Tracking API — Tracking API қызметіне арналған ресми өнім анықтамасы.
• 17TRACK API documentation — интеграцияны іске асыруға арналған ресми техникалық анықтама. Әзірлеуге дейін нақты сұрау форматтарын, қолдау көрсетілетін жұмыс процестерін және шектеулерді осы жерден растаңыз.