Како да го обедините следењето на пратките низ Австралија и Нов Зеланд со еден API

За да го обедините следењето на пратките низ Австралија и Нов Зеланд со еден API, поврзете го вашиот систем за нарачки или исполнување на нарачки со услуга за следење од повеќе превозници, регистрирајте ја секоја пратка со точниот идентитет на превозникот и претворете ги примените ажурирања за следење во конзистентен интерен модел на настани. Интеграцијата треба да ги зачува деталите специфични за превозникот, а истовремено да им овозможи на вашиот оперативен тим и на клиентите едно искуство за следење при домашни и прекугранични испораки меѓу Австралија и Нов Зеланд.

За развивачите, операторите на е-трговија и логистичките тимови, главниот предизвик не е испраќањето на првото API-барање. Предизвикот е да се одржат идентитетите на пратките, статусите на испорака, предавањата меѓу превозниците и известувањата до клиентите конзистентни кога различни превозници го опишуваат истото патување на различни начини. Овој водич објаснува како да ја дизајнирате таа интеграција, како да оцените API за следење и како да го тестирате пред да се потпрете на него во продукција.

Дефинирајте што треба да обедини единствениот API

Заедничкиот API ѝ овозможува на вашата апликација заедничка интеграциска точка. Тој не значи дека секој превозник ќе објавува идентични информации или ќе ги скенира пакетите со иста честота. Вашата архитектура треба да прави разлика меѓу конзистентен интерфејс и целосна видливост.

Започнете со попис на пратките заснован на вистинската активност за исполнување на нарачките, наместо со општ список на превозници што работат во која било од двете земји. Вклучете домашни пратки во Австралија, домашни пратки во Нов Зеланд и прекугранични движења во двете насоки. Додајте и други меѓународни потекла доколку се дел од вашиот бизнис.

• Превозник и услуга: Забележете го превозникот, користената услуга и секој познат партнер за испорака.
• Рута: Разликувајте го потеклото и дестинацијата на пратката од локацијата на нејзиното последно скенирање.
• Идентификатори: Соберете ја референцата на нарачката, референцата за исполнување, бројот за следење и секој заменски или партнерски број.
• Оперативна намена: Наведете дали ажурирањата служат за следење од страна на клиентот, управување со исклучоци, потврда на испораката или за сите три намени.
• Потребни детали: Одлучете дали е доволен општ статус на испорака или на агентите им се потребни и описи на скенирањата, локации и временски ознаки.

Овој попис станува ваша листа за проверка при прифаќање. Општата покриеност на превозниците од некој провајдер е корисна за составување потесен избор, но одлуката треба да се заснова на тоа дали вашите реални комбинации на превозници и услуги враќаат употребливи информации за следење.

Оценете го API-то за следење според структурата на вашите пратки

17TRACK нуди API за следење, што го прави релевантна опција за оценување при интеграција со повеќе превозници. Користете ја неговата официјална API документација за да ги проверите тековните барања за интеграција. Поддршката за превозници, полињата на настаните, однесувањето на ажурирањата, ограничувањата на сметката и комерцијалните услови третирајте ги како ставки што треба да ги проверите за вашата имплементација, а не како претпоставки изведени од категоријата на производот.

Поставете им ги истите практични прашања на сите API-ја што ги разгледувате:

• Може ли да ги идентификува и следи превозниците и услугите во вашиот попис на пратки?
• Кога идентификацијата на превозникот е нејасна, можете ли да доставите експлицитен идентификатор на превозникот?
• Како вашата апликација ги прима ажурирањата и каков механизам за обновување е достапен ако некое ажурирање биде пропуштено?
• Кои детали од оригиналниот превозник остануваат достапни покрај нормализираните статуси?
• Што се случува кога бројот за следење е неважечки, сè уште не е препознаен или е поврзан со повеќе можни превозници?
• Како се дефинирани користењето, наплатата, времетраењето на следењето и ограничувањата на пристапот за вашата сметка?

Препорачано правило за одлука: Изберете врз основа на успешни тестови со вашите реални модели на испорака, а не според најголемиот број превозници наведен во насловите. Интеграцијата е соодветна кога обезбедува доволно информации за поддршка на вашите оперативни одлуки и ги прикажува грешките доволно јасно за да можете да ги отстраните.

Изградете интерен модел што ги издржува разликите меѓу превозниците

Разделете ги нарачките, пратките и делниците на следење

Не користете го бројот за следење како примарен клуч за нарачката. Една нарачка може да содржи повеќе пакети, а патувањето на еден пакет може да вклучува повеќе од еден идентификатор за следење. Наместо тоа, создајте интерен ID на пратката и поврзете ги записите за следење со него.

Практичниот модел има три нивоа: нарачката на клиентот, нејзините физички пратки и делниците на следење поврзани со секоја пратка. На домашна пратка можеби ѝ е потребна само една делница на следење. На прекугранична пратка може да ѝ бидат потребни поврзани записи кога друг превозник или идентификатор ќе стане релевантен.

Опфатете го записот за следење според превозникот, како и според бројот за следење, и зачувајте ја неговата поврзаност со ID-то на пратката. Ако се појави нов број од партнерот за испорака, додајте го како поврзан идентификатор наместо да го пребришете оригиналниот. Така се зачувува историјата што им е потребна на агентите за поддршка при истражување на предавање.

Зачувајте необработен и нормализиран настан

Користете мал интерен речник на статуси според кој вашиот бизнис може да постапува. На пример, можете да дефинирате: пред транзит, во транзит, испратено за испорака, достапно за преземање, испорачано, исклучок и непознато. Ова се предложени интерни категории, а не тврдење за шемата на статуси на конкретен провајдер.

Зачувајте го оригиналниот опис на превозникот покрај мапираниот статус. Настан на место за преземање и проблем со адресата може да бараат дејство од клиентот, но не треба да произведат иста порака. Исто така, креирањето етикета не треба автоматски да стане доказ дека превозникот физички го поседува пакетот.

Документирајте ги одлуките за мапирање во конфигурација со верзии. Кога ќе се појави нов опис на настан, ставете го во редица за проверка ако неговото значење не е јасно. Експлицитната состојба „непознато“ е побезбедна од самоуверено доделување погрешен исход на испораката.

Разликувајте го времето на настанот од времето на прием

Зачувајте одделно кога се случил настанот и кога вашиот систем го примил. Постаро скенирање може да пристигне по поново, особено кога ажурирањата доцнат или кога историските настани се доставуваат заедно.

За Австралија и Нов Зеланд, избегнувајте примена на една фиксна временска разлика за секоја пратка. Зачувајте ги изворните временски ознаки и отстапувања кога се доставени. Користете соодветна именувана временска зона за приказ кога имате сигурен контекст за локацијата и земете ги предвид разликите поради летното сметање на времето. Ако временската зона на изворот недостасува, зачувајте ја таа неизвесност наместо да измислувате прецизна конверзија во UTC.

Имплементирајте сигурен процес за внесување

1. Прво создајте ја интерната пратка. Забележете ја нејзината поврзаност со нарачката, рутата, изборот на превозникот и идентификаторот за следење пред регистрацијата кај услугата за следење.
2. Поднесете ја регистрацијата за следење. Користете го документираниот формат на барањето на провајдерот. Зачувајте го одговорот и разликувајте ја успешната регистрација од подоцнежната достапност на настаните на превозникот.
3. Класифицирајте ги грешките. Разделете ги неважечките внесови и проблемите со автентикацијата од привремените прекини на услугата. Повторувајте само кога повторувањето разумно може да помогне.
4. Примајте или преземајте ажурирања. Имплементирајте го механизмот за испорака што го поддржува избраниот API. Ако користите webhooks, проверувајте ги дојдовните барања со документираниот метод на провајдерот и обработувајте ги прифатените настани преку трајна редица.
5. Отстранете дупликати пред да примените промени. Користете идентификатор на настанот од провајдерот кога е достапен или внимателно дизајниран составен клуч. Повторената испорака не смее да активира повторени известувања до клиентите.
6. Пресметајте ја повторно состојбата на пратката. Проценувајте го значењето и хронологијата на настаните наместо да го заменувате тековниот статус со ажурирањето што пристигнало последно.
7. Усогласете ги нецелосните записи. Кога API-то поддржува преземање, користете го за истражување на пропуштени ажурирања или застарени записи во рамките на применливите ограничувања за користење.

Автентикацијата специфична за провајдерот, имињата на полињата и обработката на грешки чувајте ги во адаптер. Вашиот систем за управување со нарачки треба да го користи вашиот интерен модел на пратка, наместо директно да зависи од секој детал во одговорот на провајдерот. Ова одвојување ги олеснува и подоцнежните тестирања на промените во API-то.

Обработувајте ги патувањата меѓу Австралија и Нов Зеланд без измислување сигурност

Прекуграничното следење има потреба од повеќе контекст отколку низа статусни ознаки. Вашата апликација треба да разликува настан при извоз, царински настан, предавање меѓу превозници и настан на конечна испорака кога изворните податоци ги поддржуваат тие разлики.

Не извлекувајте заклучок за царинско ослободување од општо скенирање „во транзит“. Исто така, отсуството на неодамнешно скенирање не докажува дека царината го задржува пакетот. Корисната порака до клиентот го наведува последниот потврден настан и неговото време, а потоа го објаснува секое следно дејство што вашиот тим навистина може да го поддржи.

Потеклото и дестинацијата чувајте ги одделно од локацијата на скенирањето. Пратка што патува од Австралија до Нов Зеланд не станува домашна пратка во Нов Зеланд само затоа што добила скенирање при пристигнување. Оваа разлика е важна за известувањето за рутата и за одговорноста при исклучоци.

Ако се вклучи партнер за испорака, поврзете го неговиот запис за следење само кога односот е поткрепен со податоци за пратката, услугата за следење или оперативно проверен запис. Не спојувајте пакети само затоа што идентификаторите изгледаат слично.

Претворете ги настаните од следењето во корисни ажурирања за клиентите

Вашата страница за клиенти треба да одговори на четири прашања: кој е последниот потврден статус, кога се случил, каде е забележан ако е познато и дали клиентот треба да преземе дејство?

Правилата за известување чувајте ги одделно од внесувањето на настаните. Не секое скенирање заслужува е-пошта или текстуална порака. Дефинирајте значајни премини, како прво потврдено движење, обид за испорака, потреба од преземање или испорачан настан, и потиснете ги повторените известувања за истиот премин.

• Застарено следење: Наведете кога се случило последното ажурирање без тишината да ја третирате како доказ за загуба.
• Проценки за испорака: Разликувајте проценка дадена од превозникот од ветување на трговецот. Не измислувајте датум кога не постои ниту едното ниту другото.
• Исклучоци: Дадете конкретен следен чекор кога е познат, наместо да прикажувате необјаснета ознака за грешка.
• Спорови за испорачано: Зачувајте го изворниот настан и проследете го случајот до поддршката; самиот статус „испорачано“ не го решава секој спор со клиентот.

Заштитете ги страниците за следење исто како и акредитивите за API. Избегнувајте изложување непотребни адресни или контактни податоци, чувајте ги акредитивите на услугата на серверот и применувајте контроли на пристап соодветни на прикажаните информации.

Спроведете пилот заснован на рути пред пуштањето во употреба

Тестирајте домашни пратки во Австралија, домашни пратки во Нов Зеланд, пратки од Австралија до Нов Зеланд и од Нов Зеланд до Австралија, кога тие рути се релевантни за вашиот бизнис. Вклучете вообичаени испораки и оперативни гранични случаи: поделени нарачки, непрепознаени броеви, предавања, обиди за испорака, настани за преземање, враќања и задоцнети скенирања.

Користете вистински записи за пратки со соодветна дозвола за проверка на превозниците. Користете синтетички настани за тестирање на отпорноста на вашата апликација, но не третирајте ги синтетичките резултати како доказ за покриеност со живи превозници.

• Проверка на идентитетот: Секое ажурирање стигнува до точната пратка и нарачка.
• Проверка на хронологијата: Настаните надвор од редоследот не го враќаат неправилно напредокот на испораката.
• Проверка на обновувањето: Привремените грешки и дупликатните ажурирања не предизвикуваат губење податоци или повторување известувања.
• Проверка на поддршката: Агентите можат да го прегледаат оригиналниот настан и да го разберат статусот прикажан на клиентот.
• Комерцијална проверка: Очекуваното користење се вклопува во потврдениот модел на наплата и ограничувањата на сметката.

Поставете ги праговите за прифаќање пред да го оценувате пилотот. Измерете ги исходите од регистрацијата, немапираните настани, доцнењата во обработката, дупликатните известувања и нерешените застарени пратки. Разделете ги доцнењата во податоците на превозникот од доцнењата во вашата апликација за санацијата да стигне до вистинскиот одговорен тим.

Имплементацијата е подготвена кога вашиот тим може да објасни и да се справи со нецелосно следење, а не само да прикажува успешни испораки. Еден API го поедноставува поврзувањето; вашиот модел на пратки, правилата за настани и оперативните процедури го прават тоа поврзување сигурно.

ЧПП

Дали еден API за следење ги заменува интеграциите за испорака со превозници?

Не нужно. Следењето, креирањето етикети, резервирањето преземање, пресметувањето цени и царинската документација се одделни функции. Проверете го опсегот на избраниот производ и задржете ги другите интеграции таму каде што ги бара вашиот процес на исполнување на нарачките.

Можам ли да регистрирам број за следење пред првото скенирање од превозникот?

Проверете ги правилата за регистрација на API-то. Дизајнирајте ја апликацијата така што ќе разликува прифатена регистрација за следење од потврдено физичко движење. Запис без настани не треба автоматски да се прикажува како „во транзит“.

Дали еден API ќе обезбеди ажурирања во реално време за секој превозник?

Не претпоставувајте го тоа. Свежината од крај до крај зависи од тоа кога превозникот ги објавува податоците, кога услугата за следење ги добива и кога вашата апликација ги обработува. Потврдете го однесувањето на ажурирањата за комбинациите на превозници и услуги што ги користите.

Што треба да се случи кога ќе се промени бројот за следење?

Задржете го оригиналниот идентификатор и поврзете го потврдениот заменски или партнерски идентификатор со истата интерна пратка. Зачувајте ги двете истории и спречете дупликатните записи да создаваат спротивставени известувања.

Дали 17TRACK е релевантен за оваа интеграција?

Да. Неговиот API за следење е релевантен за интеграцијата со повеќе превозници опишана овде. Оценете го со примероци од вашите пратки во Австралија и Нов Зеланд и потврдете ја поддршката за превозниците, техничкото однесување и условите на сметката преку официјалните API-ресурси пред пуштањето во употреба.

Извори

• 17TRACK Tracking API — официјален ресурс за производот и API-опцијата разгледана во овој водич.
• 17TRACK API documentation — официјална техничка референца за проверка на форматите на барањата, барањата за интеграција и поддржаното однесување.