Бір API арқылы Австралия мен Жаңа Зеландиядағы жөнелтілімдерді қадағалауды қалай біріздендіруге болады

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

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

Бірыңғай API нені біріктіруі керектігін анықтаңыз

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

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

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

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

Қадағалау API интерфейсін жөнелтілімдер қоспаңызға қатысты бағалаңыз

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

Қарастырып отырған кез келген API бойынша мына практикалық сұрақтарды қойыңыз:

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

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

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

Тапсырыстарды, жөнелтілімдерді және қадағалау кезеңдерін ажыратыңыз

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

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

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

Шикі оқиға мен қалыпқа келтірілген оқиғаны сақтаңыз

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

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

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

Оқиға уақытын алу уақытынан ажыратыңыз

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

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

Сенімді деректерді қабылдау жұмыс процесін іске асырыңыз

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

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

Тасман теңізі арқылы өтетін сапарларды жалған сенімділіксіз өңдеңіз

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

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

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

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

Қадағалау оқиғаларын пайдалы клиенттік жаңартуларға айналдырыңыз

Клиентке арналған бет төрт сұраққа жауап беруі керек: соңғы расталған мәртебе қандай, ол қашан болды, белгілі болса қай жерде тіркелді және клиент әрекет етуі керек пе?

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

• Ескірген қадағалау: соңғы жаңартудың қашан болғанын көрсетіңіз, бірақ үнсіздікті жоғалудың дәлелі ретінде қарастырмаңыз.
• Жеткізу болжамдары: тасымалдаушы берген болжамды сатушының уәдесінен ажыратыңыз. Екеуі де жоқ болса, күнді ойдан шығармаңыз.
• Ерекше жағдайлар: түсіндірілмеген қате белгісін көрсетудің орнына, белгілі болса нақты келесі қадамды беріңіз.
• Жеткізілді деген даулар: бастапқы оқиғаны сақтап, істі қолдау қызметіне бағыттаңыз; «жеткізілді» мәртебесінің өзі әрбір клиент дауын шешпейді.

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

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

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

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

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

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

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

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

Бір қадағалау API интерфейсі тасымалдаушылардың жөнелту интеграцияларын алмастыра ма?

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

Алғашқы тасымалдаушы сканерлеуіне дейін қадағалау нөмірін тіркей аламын ба?

API тіркеу ережелерін тексеріңіз. Қолданбаңызды қабылданған қадағалау тіркеуін нақты физикалық қозғалыстан ажырататындай етіп жобалаңыз. Оқиғалары жоқ жазба автоматты түрде «транзитте» ретінде көрсетілмеуі керек.

Бір API әрбір тасымалдаушы үшін нақты уақыттағы жаңартуларды бере ме?

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

Қадағалау нөмірі өзгергенде не болуы керек?

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

17TRACK бұл интеграцияға қатысты ма?

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

Дереккөздер

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