Оңтүстік-Шығыс Азия бойынша көп елді қамтитын жеткізілімдер үшін бақылау API интерфейсін қалай таңдауға болады

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

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

Аймақтық қамту туралы мәлімдемеден емес, жеткізу бағыттарынан бастаңыз

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

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

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

Талап	Нені тіркеу керек	Маңыздылығы
Жеткізу бағыты	Шығу орны, межелі орын, қызмет және жеткізу серіктесі	Ел деңгейіндегі қамту сіз пайдаланатын қызметті растамайды.
Жеткізу тізбегі	Белгілі халықаралық, пошта және соңғы кезең серіктестері	Көрінуді тасымалдаушылар ауысқан кезде сынау керек.
Идентификаторлар	Бастапқы нөмір, ауыстырылған нөмір және тапсырыс сілтемесі	Жүйеңіз жаңартуларды дұрыс сәлемдемемен байланыстыруы қажет.
Операциялық қажеттілік	Клиенттік жаңартулар, ерекшеліктер кезегі немесе жеткізуді салыстыру	Әртүрлі процестерге әртүрлі оқиға егжей-тегжейі мен уақыттылығы қажет.

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

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

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

Тасымалдаушыны анықтау және бақылау нөмірінің өзгеруі

Нөмір бірнеше тасымалдаушыға тиесілі болуы мүмкін кезде тасымалдаушыны анықтау қалай жұмыс істейтінін сұраңыз. Интеграцияңыз тасымалдаушы идентификаторын бере ала ма? Қате тағайындауды түзетуге бола ма? Жеткізу серіктесі екінші бақылау нөмірін берсе не болады?

Автоматты анықтау барлық жағдайды шешеді деп есептемеңіз. Мүмкін болған кезде тасымалдаушы мен қызмет туралы ақпаратты жеткізу жүйеңізден сақтаңыз. Сондай-ақ байланысты бақылау нөмірлері автоматты түрде байланыстырылатынын, бөлек өрістер ретінде қайтарылатынын немесе оларды өз дерекқорыңызда байланыстыру қажет екенін анықтаңыз.

Оқиғаның мағынасы және бастапқы мәліметтер

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

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

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

Жөнелтілім сәйкестігі және тапсырыс сәйкестігі

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

Жаңалықтың уақтылығын жеткізу жылдамдығымен шатастырмай өлшеңіз

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

Мүмкін болған жерде үш уақыт белгісін тіркеңіз:

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

Уақыт белдеулерінің ығысуын тіркеп, оқиға уақытын қабылдау уақытынан ажыратыңыз. Өңдеу уақыт белгілері қолжетімсіз болса, өлшеміңізді кідірісті толығымен API-ге жатқызбай, соңынан соңына дейінгі бақылау кідірісі ретінде сипаттаңыз.

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

Интеграцияны тек қалыпты жағдайда емес, ақау кезінде де бағалаңыз

Сәтті үлгі жауабы өндірістегі сенімділік туралы аз ақпарат береді. Инженерлік командаңыз тіркеуді, жаңартуларды, қайталап жіберуді, салыстыруды және қалпына келтіруді сынауы керек.

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

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

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

API мониторингін бизнес белгілеріне негіздеңіз

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

Техникалық және операциялық көрсеткіштерді бірге бақылаңыз:

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

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

Есептелетін бірлік пен операциялық жүктемені салыстырыңыз

Әр ұсыныс нені есептейтінін түсінбей тұрып бағаларды салыстырмаңыз. Төлем тіркелген жөнелтілімдерге, сұрауларға, белсенді бақылау жазбаларына, хабарламаларға немесе басқа бірлікке байланысты ма екенін сұраңыз. Бұл — кез келген провайдердің бағасы туралы болжам емес, сатып алу сұрақтары.

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

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

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

17TRACK бағалауға қалай сәйкес келеді

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

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

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

Нақты қабылдау критерийлерімен тұжырымдаманы тексеріңіз

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

1. Тестілеуден бұрын талаптарды белгілеңіз. Міндетті бағыттарды, қажетті өрістерді, қабылданатын жаңарту кідірісін және қалпына келтіру күтілімдерін анықтаңыз. Бұл — жалпы салалық өлшемдер емес, сіздің қабылдау критерийлеріңіз.
2. Анықтамалық жазба жасаңыз. Әр жөнелтілім үшін жеткізу жүйесінің мәліметтері мен тиісті тасымалдаушы бақылау тарихын сақтаңыз. Әр бақылауды қашан тіркегеніңізді белгілеңіз.
3. Толық процесті орындаңыз. Жөнелтілімді тіркеңіз, жаңартуларды алыңыз, бақылауды көрсетіңіз, ерекшеліктерді ашыңыз және жеткізуді тапсырыстарды басқару жүйесіне салыстырыңыз.
4. Басқарылатын ақаулар енгізіңіз. Сынақ ортасында қабылдағышты тоқтатыңыз, қайталанатын жазбалар жіберіңіз және жарамсыз идентификаторларды сынаңыз. Қалпына келтіру қолмен қайта құруды қажет етпейтініне көз жеткізіңіз.
5. Айырмашылықтарды себептері бойынша қарастырыңыз. Жоғарыдан келмеген оқиғаларды, тасымалдаушыны сәйкестендіру қателерін, провайдердің өңдеу мәселелерін және өз интеграцияңыздағы ақауларды ажыратыңыз.
6. Шешімді құжаттаңыз. Әр талапты дәлелімен және жауапты иесімен бірге орындалды, орындалмады немесе расталуы күтілуде деп белгілеңіз.

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

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

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

Оңтүстік-Шығыс Азияның әр елі үшін бөлек бақылау API қажет пе?

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

Тасымалдаушыны қолдау соңғы жеткізуге дейін көрінуге кепілдік бере ме?

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

Webhook немесе polling қолдануым керек пе?

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

Бақылау API сынағы қанша уақытқа созылуы керек?

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

API клиенттерге сәлемдеменің нақты қашан келетінін айта ала ма?

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

Дереккөздер

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

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