Жөнелтілімді қадағалау API-ін электрондық коммерция дүкеніңізге қалай біріктіруге болады
Жеткізілімді бақылау API интерфейсін электрондық коммерция дүкеніңізге біріктіру үшін тапсырыстар жүйесін бақылау провайдеріне қосыңыз, жеткізілім және тасымалдаушы деректерін қауіпсіз серверлік сұрау арқылы жіберіңіз, қалыпқа келтірілген бақылау оқиғаларын сақтаңыз және алынған мәртебені клиенттер мен қолдау интерфейстерінде көрсетіңіз. Сенімді іске асыру тек бақылау нөмірі өрісін қосудан әлдеқайда көп нәрсені қамтиды: ол тасымалдаушыны таңдауды, мәртебе жаңартуларын, жеткізілім ерекшеліктерін, қайталап жіберулерді, құпиялылықты және клиенттердің сатып алғаннан кейінгі ақпаратты іс жүзінде пайдалану тәсілін өңдеуі керек.
Бұл нұсқаулық дүкен иелеріне, әзірлеушілерге және операциялық топтарға арналған практикалық біріктіру тәсілін түсіндіреді. Нұсқаулық анықтамалық нүкте ретінде 17TRACK ресми Tracking API құжаттамасын пайдаланады, бірақ дәл осы жоспарлау қағидалары басқа көп тасымалдаушысы бар провайдерді бағалау кезінде де қолданылады.
Біріктіру қандай нәтижеге жеткізуі тиіс екенін анықтаңыз
API соңғы нүктесінен емес, бизнес нәтижесінен бастаңыз. Көптеген дүкендер «Тапсырысым қайда?» деген сұрақтарға келетін өтініштерді азайтқысы келеді, сатып алушыларға жеткізілімнің анық көрінісін бергісі келеді және клиент шағымданбай тұрып, операциялық топтарға кешіктірілген жөнелтілімдерді анықтауға көмектескісі келеді. Бұл мақсаттар әртүрлі деректер мен жұмыс процестерін талап етеді.
- Клиентке көрінуі: ағымдағы жөнелтілім мәртебесін, қолжетімді болған жағдайда болжамды жеткізу ақпаратын, тасымалдаушы мәліметтерін және соңғы маңызды оқиғаны көрсету.
- Операциялық көріну: қызметкерлерге тасымалдаушылар бойынша кешіктірілген, тоқтап қалған, қайтарылған немесе ерекшелікке ие жөнелтілімдерді табуға мүмкіндік беру.
- Автоматтандырылған байланыс: жөнелтілім анықталған мәртебеге жеткен кезде бекітілген email, SMS немесе басқа хабарландыруларды іске қосу.
- Деректердің бірізділігі: әртүрлі тасымалдаушылардың оқиға белгілерін дүкеніңіз сенімді пайдалана алатын аздаған мәртебелер жиынтығына түрлендіру.
Іске асыру әдісін таңдамас бұрын осы нәтижелерді анықтаңыз. Бақылау API интерфейсі жөнелтілім деректерін бере алады, бірақ қандай оқиғалар клиентке хабарландыру жіберуге лайық екенін немесе дүкеніңіздің мекенжай мәселесін қалай өңдеуі керектігін автоматты түрде шешпейді.
Дұрыс біріктіру архитектурасын таңдаңыз
Әдеттегі архитектура төрт қабаттан тұрады: коммерциялық платформа, біріктіру қызметі, бақылау провайдері және клиентке бағытталған интерфейс. Біріктіру қызметі серверлік қолданба, тапсырыстарды басқару жүйесі немесе serverless жұмыс процесі болуы мүмкін. Бұл логиканы серверде сақтау әдетте API есептік деректерін браузер кодына орналастырғаннан қауіпсіздеу.
Негізгі ағын мынадай:
- Төленген тапсырыс орындалып, бақылау нөмірі мен тасымалдаушыны алады.
- Backend жөнелтілім мәліметтерін бақылау провайдеріне жібереді.
- Провайдер өзінің API құрылымына сәйкес бақылау идентификаторын немесе бақылау деректерін қайтарады.
- Жүйеңіз провайдер сілтемесін сақтап, жөнелтілім оқиғаларын ішкі мәртебелерге сәйкестендіреді.
- Жоспарланған жаңарту процесі немесе қолдау көрсетілетін оқиға хабарландыруы жөнелтілімді жаңартады.
- Дүкен витринасы, тапсырыс беті, қолдау құралдары және хабарландыру қызметі өзіңіздің қалыпқа келтірілген деректеріңізден ақпарат оқиды.
Әр бет ашылған сайын тасымалдаушыға немесе бақылау API интерфейсіне сұрау жібермеңіз. Мұндай дизайн клиент тәжірибесін баяулатып, қайталанатын сұрауларға, сұрау шегінен асып кету мәселелеріне және бірізді емес нәтижелерге әкелуі мүмкін. Соңғы қабылданған бақылау күйін дерекқорыңызда сақтап, оны басқарылатын фондық тапсырмалар немесе провайдер қолдайтын жаңарту механизмі арқылы жаңартыңыз.
Код жазбас бұрын провайдер құжаттамасын растаңыз
Іске асырудан бұрын провайдердің аутентификация, сұрау пішімдері, жауап өрістері, қолдау көрсетілетін тасымалдаушылар, қателерді өңдеу, жаңарту механизмдері және есептік жазба талаптары жөніндегі ресми API құжаттамасын қарап шығыңыз. 17TRACK арнайы Tracking API өнім бетін және әзірлеушілер құжаттамасын ұсынады. Қазіргі API әрекетін форумдардан немесе ескі біріктіру нұсқаулықтарынан көшірілген мысалдарға емес, осы беттерге сүйеніп анықтаңыз.
Құжаттама негізінде қысқа талаптар тізімін жасаңыз:
- API есептік деректері қалай беріледі, сақталады, жаңартылады және қайтарып алынады?
- Сұрау тасымалдаушы кодын талап ете ме, әлде қызмет тасымалдаушыны бақылау нөмірі арқылы анықтай ала ма?
- Қандай жауап өрістері жөнелтілімді, мәртебені, орынды, уақыт белгілерін және ерекшелік хабарын анықтайды?
- Есептік жазба қолдаса, асинхронды жаңартулар қалай жеткізіледі?
- Құжатталған сұрау шектері, есептеу ережелері, күтілетін күту уақыты және қате кодтары қандай?
- Қайталанатын бақылау нөмірлері, жарамсыз нөмірлер, белгісіз тасымалдаушылар және жеткізілген жөнелтілімдер қалай өңделуі керек?
Функцияны өнім атауына қарап болжамаңыз. Мысалы, «нақты уақыттағы» сөзі өнімнің позициялау мәлімдемесін білдіруі мүмкін, бірақ әр тасымалдаушы оқиғасы бірден көрінетініне кепілдік бермейді. Іске асыру сипаттамасында тасымалдаушы сканерлеулерінің кешігуі мүмкін екенін және API тасымалдаушы хабарламаған сканерлеуді жасай алмайтынын түсіндіріңіз.
Тапсырыс пен жөнелтілім деректерін дайындаңыз
Бақылауды жасау үшін ең қолайлы сәт әдетте тапсырысты жасаудың орнына жөнелтілімді орындау сәті болып табылады. Тапсырыс төленген болуы мүмкін, бірақ әлі оралмаған, ал бақылау нөмірі сәлемдеме тасымалдаушы қабылдағанға дейін жасалуы мүмкін. Орындау жұмыс процесіндегі қай оқиға бақылау жазбасын жасауы тиіс екенін анықтаңыз.
Кемінде ішкі жөнелтілім жазбаңыз келесі мәндерді ажыратуы керек:
- Ішкі тапсырыс ID және орындау ID
- Бақылау нөмірі
- Тасымалдаушы атауы немесе тасымалдаушы коды
- Операциялық тұрғыдан қажет болған жағдайда, жеткізу елі немесе өңірі
- Қайтарылған болса, провайдердің бақылау ID немесе жазылым сілтемесі
- Ағымдағы қалыпқа келтірілген мәртебе
- Соңғы оқиға уақыты және соңғы синхрондау уақыты
- Провайдердің бастапқы жауабы немесе басқарылатын аудит сілтемесі
Тапсырыс деректері мен жөнелтілім деректерін бөлек сақтаңыз. Бір тапсырыста бірнеше сәлемдеме, бөлінген жөнелтілімдер немесе әртүрлі тасымалдаушылар болуы мүмкін. Бір тапсырысқа бір бақылау нөмірі сәйкес келеді деген болжам қойма тауарларды бөлек жөнелткен кезде жиі сәтсіздікке ұшырайды.
Идемпотентті процесті пайдаланыңыз. Егер орындау жүйесі сол сұрауды қайта жіберсе, біріктіру қайталанатын жазылымдар немесе клиентке қайталанатын хабарламалар жасамай, бар жөнелтілімді жаңартуы керек. Практикалық идемпотенттілік кілті провайдердің өз талаптарын ескере отырып, ішкі орындау ID, тасымалдаушы идентификаторы және бақылау нөмірін біріктіре алады.
Клиенттер үшін тасымалдаушы мәртебелерін қалыпқа келтіріңіз
Тасымалдаушылар әртүрлі белгілер мен оқиға ретін пайдаланады. Дүкеніңіз Ақпарат алынды, Жолда, Жеткізуге шықты, Жеткізілді, Ерекшелік және Қайтарылды сияқты шағын ішкі мәртебелер үлгісін сақтауы керек. Қолдау қызметкерлері үшін бастапқы тасымалдаушы оқиғасын сақтаңыз, бірақ дүкен витринасының логикасы үшін қалыпқа келтірілген мәртебені пайдаланыңыз.
Қалыпқа келтіру ережелері анық болуы керек. «Жапсырма жасалды» оқиғасын сәлемдеме қозғалып жатыр деген дәлел ретінде көрсетпеу керек. «Жеткізілді» мәртебесі клиент сәлемдемені нақты алғанына кепілдік емес, тасымалдаушы хабарлаған оқиға ретінде қарастырылуы тиіс. Жөнелтілім кейін қозғалысын жалғастыруы мүмкін болғандықтан, ерекшелікті үнсіз түрде «жолда» мәртебесіне ауыстырмаңыз.
Сондай-ақ мәртебелердің басымдығы мен кері өзгерістерді өңдеу тәртібін анықтаңыз. Кешіккен тасымалдаушы арнасы оқиғаларды ретсіз жеткізуі мүмкін. Қолжетімді болған жағдайда оқиға уақыт белгілерін салыстырыңыз, бастапқы оқиғаны жазып алыңыз және жаңарақ «жеткізілді» күйін ескірек «жолда» күйімен алмастырмаңыз. Уақыт белгілері жоқ немесе түсініксіз болса, реттілікті ойдан шығармай, консервативті жаңарту үшін жазбаны белгілеңіз.
Серверлік сұрау ағынын құрыңыз
Backend бақылау провайдеріне қоңырау шалмас бұрын кіріс орындау деректерін тексеруі керек. Бақылау нөмірінің бар екенін тексеріңіз, кездейсоқ бос орындарды алып тастаңыз, қажет болған жағдайда күтілетін пішімді растаңыз және тасымалдаушы мәнінің жарамды екеніне көз жеткізіңіз. Әдеттен тыс, бірақ жарамды бақылау нөмірлерін жергілікті тар үлгіге сәйкес келмегені үшін ғана қабылдамаңыз.
Провайдерге тәуелсіз сұрау ағынын былай көрсетуге болады:
receive fulfillment event
validate order and shipment fields
check for an existing idempotency key
send the documented tracking request from the server
store the provider response and internal shipment record
queue a refresh or process the supported update event
publish only approved fields to the storefrontУақытша қателер үшін қысқа күту уақыттарын, шектелген қайталап жіберулерді және экспоненциалды кідірісті пайдаланыңыз. Әр қатені қайталап жібермеңіз. Аутентификация қатесі, жарамсыз сұрау немесе қолдау көрсетілмейтін тасымалдаушы әдетте қайталанатын қоңырауларды емес, түзетуді талап етеді. Корреляция ID, сұрау нәтижесі және провайдер қатесінің санатын журналға жазыңыз, бірақ API кілттерін, клиенттердің толық мекенжайларын немесе қажетсіз жеке ақпаратты қолданба журналдарына жазбаңыз.
Провайдердің жауабын клиентке көрсетілетін үлгіден бөлек сақтаңыз. Бұл провайдерді ауыстыруды, сәйкестендіру ережесін түзетуді және жалпыға қолжетімді тапсырыс беті арқылы көрсетілетін ақпаратты шектеуді жеңілдетеді.
Клиенттің бақылау тәжірибесін жобалаңыз
Бақылау беті үш сұраққа жылдам жауап беруі керек: ағымдағы күй қандай, ең соңғы не болды және клиент енді не істеуі керек? Тапсырыс сілтемесін, құпиялылықты ескеретін пішімдегі жөнелтілім нөмірін, тасымалдаушы атауын, соңғы оқиға уақытын және ерекшеліктердің анық түсіндірмесін көрсетіңіз.
Бос уақыт шкаласын техникалық ақау сияқты көрсетпеңіз. Алғашқы тасымалдаушы сканерлеуіне дейін жеткізу ақпараты алынғанын және қозғалыс әлі көрінбеуі мүмкін екенін түсіндіріңіз. Ерекшелік жағдайында қарапайым тілдегі түсіндірмені бастапқы деректер қолдаған кезде ғана беріңіз. Егер тасымалдаушы мекенжай мәселесі туралы хабарласа, бизнесіңіз іс жүзінде ұсына алатын қолдау процесіне немесе клиенттерге қызмет көрсету әрекетіне сілтеме жасаңыз.
Shopify немесе басқа коммерциялық платформада құрылған дүкендер үшін платформа орындау оқиғаларын, клиент есептік жазбаларын, тапсырыс мәртебесі беттерін және хабарландыру үлгілерін қалай ұсынатынын тексеріңіз. Shopify ресми әзірлеушілер құжаттамасында webhook және орындау деректеріне арналған ресурстар бар. Платформа API интерфейстері мен нұсқаланған құжаттама өзгеруі мүмкін, сондықтан өндірістік жұмысқа дейін қолданбаңыз пайдаланатын нұсқаны растаңыз.
Хабарландыруларды мұқият пайдаланыңыз
Жөнелтілім оқиғалары пайдалы триггерлер болып табылады, бірақ әр тасымалдаушы сканерлеуі үшін хабарлама жіберу хабарландырудан шаршауға әкелуі мүмкін. Жөнелтілім жасалғанда, жолдағы маңызды ілгерілеуде, жеткізуге шыққанда, жеткізілгенде және таңдалған ерекшеліктер болғанда хабарландыру жіберу сияқты бизнес ережелерін анықтаңыз. Қайталанатын хабарламаларды басып, қайталанған кешігу хабарлары үшін ең аз аралық қосыңыз.
Операциялық ескертулерді клиент хабарландыруларынан бөліңіз. Қолдау тобы жөнелтілім бірнеше күн бойы өзгермегенін білуі керек болуы мүмкін, ал клиентке тасымалдаушы нақты ерекшелік туралы хабарлаған кезде ғана хабарлама қажет болуы мүмкін. Уақыт шегі қызмет деңгейіне, бағытқа, тасымалдаушыға және жеткізу әдісіне сай болуы керек, операциялық негізі жоқ әмбебап санға сүйенбеуі тиіс.
Нақты жеткізу сценарийлерімен сынақ жүргізіңіз
Бір бақылау нөмірі үшін сәтті жауап алынуы өндірістік іске қосу үшін жеткіліксіз. Бірнеше тасымалдаушыны, елдерді, жөнелтілім түрлерін және оқиға күйлерін қамтитын сынақ матрицасын жасаңыз. Кемінде мыналарды сынаңыз:
- Тасымалдаушы сканерлеуі жоқ жаңадан жасалған жөнелтілім
- Қалыпты жолдағы жөнелтілім
- Жеткізуге шыққан жөнелтілім
- Жеткізілген жөнелтілім
- Ерекшелік немесе мекенжайға қатысты оқиға
- Қайтарылған жөнелтілім
- Жарамсыз бақылау нөмірі
- Қайталанатын орындау оқиғасы
- Провайдердің кешіккен жауабы немесе күту уақытының аяқталуы
- Реті бұзылған оқиға
API қолжетімділігінен артық нәрсені өлшеңіз. Дұрыс тапсырыстың жаңартылғанын, клиенттің түсінікті тілді көретінін, қайталанатын хабарландырулардың басылғанын және қолдау қызметкерлерінің бастапқы тасымалдаушы оқиғасын анықтай алатынын тексеріңіз. Алдымен шектеулі іске қосу жасаңыз, операциялық қосалқы жоспарды сақтаңыз және шығарылымнан кейін қате санаттарын бақылаңыз.
Қауіпсіздік, құпиялылық және техникалық қызмет көрсету
Есептік деректерді құпияларды басқару жүйесінде немесе қорғалған орта айнымалысында сақтаңыз; оларды тақырып кодына, мобильді кодқа, бастапқы код қоймасына немесе браузер сұрауларына орналастырмаңыз. Жөнелтілім деректеріне рөл бойынша қолжетімділікті шектеңіз, HTTPS пайдаланыңыз және бастапқы жауаптар мен клиентке қатысты өрістердің қанша уақыт сақталатынын тексеріңіз.
Провайдердің құжаттамасы мен коммерциялық платформаңыздың API нұсқасын тұрақты түрде қарап шығыңыз. Тасымалдаушы қолдауы, оқиға атаулары, аутентификация талаптары және платформа webhook әрекеті өзгеруі мүмкін. Мәртебелерді сәйкестендіру ережелерін бапталатын етіп сақтаңыз, олардың негізіндегі болжамдарды құжаттаңыз және клиентке басқа хабарлама жібермей жөнелтілімді қайта өңдеуге немесе салыстырып тексеруге мүмкіндік беріңіз.
Дүкеніңізге тасымалдаушылар арасында арнайы бақылау біріктіруі қажет болғанда, 17TRACK API бағалауға болатын өзекті нұсқа болып табылады. Дегенмен дұрыс таңдау сіз пайдаланатын тасымалдаушыларға, қызмет көрсететін елдеріңізге, есептік жазбаңыз үшін құжатталған жаңарту тәртібіне, күтілетін сұрау көлеміне және командаңызға қажет операциялық бақылауларға байланысты. Өндірістік дизайнға кіріспес бұрын осы тармақтарды ресми құжаттамадан және басқарылатын сынақ жобасы арқылы растаңыз.
Жиі қойылатын сұрақтар
Бақылауды тапсырыс жасалған кезде жасау керек пе?
Әдетте жоқ. Жөнелтілім жазбасын орындау процесіңізде тасымалдаушы мен бақылау нөмірі пайда болған кезде жасаңыз немесе іске қосыңыз. Оны төлем кезінде жасау кейіннен жойылған, орындалмаған немесе бөлінген тапсырыстар үшін жазбалар тудыруы мүмкін.
Бақылау API интерфейсі нақты уақыттағы жеткізу ақпаратына кепілдік бере ала ма?
Жоқ. Ешбір API әр тасымалдаушы сканерлеуінің бірден көрінуіне кепілдік бере алмайды. Провайдер тасымалдаушы деректеріне тәуелді, ал тасымалдаушы жүйелері оқиғаларды кешіктіріп немесе үзілістермен хабарлауы мүмкін. Уақыт белгілері мен мәртебе тілін дәл көрсетіңіз және тиісті құжаттама мен қызмет көрсету келісімі қолдамаса, нақты жаңарту уақытына уәде бермеңіз.
Браузер бақылау API интерфейсіне тікелей қоңырау шалуы керек пе?
Көп жағдайда жоқ. Есептік деректер қорғалған күйде қалуы, жауаптар қалыпқа келтірілуі, қайталап жіберулер басқарылуы және клиентке көрсетілетін деректер сүзгіленуі үшін серверлік біріктіруді пайдаланыңыз. Дүкен витринасы әдетте қолданбаңыздан бекітілген жөнелтілім көрінісін оқуы керек.
Бір тапсырыста бірнеше сәлемдеме болса, дүкен оны қалай өңдеуі керек?
Негізгі тапсырыс ID сақталған күйде әр орындауды немесе сәлемдемені бөлек жөнелтілім ретінде үлгілеңіз. Тапсырыс беті жалпы қорытындыны және әр сәлемдеме үшін бөлек уақыт шкалаларын көрсете алады. Бұл бір сәлемдеменің жеткізілді мәртебесі екінші сәлемдеменің кешігуін жасырып қалмауына көмектеседі.
Өндірісте бақылауға алынатын алғашқы көрсеткіш қандай?
Орындау жасалғаннан бастап клиентке дұрыс жаңарту көрсетілгенге дейінгі толық ағынды бақылаңыз. API сәттілігінің өзі жеткіліксіз. Қайталанатын жазбаларды, ескірген жөнелтілімдерді, сәйкестендірілмеген оқиғаларды, хабарландыру сәтсіздіктерін және қолмен түзетуді қажет ететін жөнелтілімдердің пайызын қадағалаңыз.
