Preklic API-naročila, ko naročnik pošlje napačno povezavo

Najprej preverite, ali je bilo naročilo posredovano dobavitelju

Napačna povezava ne pomeni vedno, da je promocija že zagnana. V vaši interni bazi je naročilo lahko ustvarjeno, a še ni poslano prek API. V tem primeru je preklic odvisen le od vaše logike obdelave: dovolj je, da naročilo označite kot preklicano, ustavite samodejno plačilo in ne zaženete prenosa.

Preverite identifikator naročila, čas ustvarjanja, povezavo, vrsto storitve in dnevnik API-zahtevkov. Če zahtevek dobavitelju ni bil poslan, ne ustvarjajte novega naročila na mestu starega. Najprej zabeležite preklic prvotne zahteve, sicer lahko naročnik prejme dva zagona na različni povezavi.

Ugotovite status naročila pri dobavitelju

Če je bil API-zahtevek že poslan, pri dobavitelju zahtevajte trenutni status. Imena statusov se razlikujejo, običajno pa jih lahko razdelimo v več skupin: čakanje, obdelava, delna izvedba, zaključek in preklic. Za odločitev ni pomemben status v vaši nadzorni plošči, temveč odgovor strani, ki zažene storitev.

• Čakanje: naročilo morda še dopušča preklic.
• Obdelava: ustavitev je včasih mogoča, a del obsega je lahko že zagnan.
• Delna izvedba: preklicati je mogoče le preostanek, če dobavitelj podpira takšno operacijo.
• Zaključek: povezave s preklicem ni več mogoče popraviti.

Slabost preverjanja le po notranjem statusu je, da se ta lahko posodablja z zamikom. Opirajte se na zadnji odgovor API in čas njegovega prejema.

Prekličite naročilo pred zagonom storitve

Za naročilo v čakalni vrsti uporabite metodo preklica, če jo predvideva dokumentacija dobavitelja. Posredujte identifikator, prejet ob ustvarjanju naročila, in ne svoje interne številke, če gre za različni vrednosti. Shranite celoten odgovor: kodo operacije, status, besedilo napake in čas zahtevka.

Naročila ne štejte za preklicano, dokler API ne potrdi preklica. Odgovor o sprejemu zahtevka in dejanska ustavitev storitve sta lahko različna dogodka. V nekaterih integracijah najprej pride potrditev sprejema, končni status pa se spremeni pozneje.

Slabost te možnosti je, da dobavitelj morda ne uspe pravočasno umakniti naročila iz obdelave. Takrat bo preklic vrnil zavrnitev ali pa bo deloval le za neizvedeni del.

Ne spreminjajte povezave v že ustvarjenem naročilu brez potrditve

Pri mnogih API-jih se povezava določi v trenutku ustvarjanja naročila. Poskus posredovanja nove povezave z istim identifikatorjem je lahko prezrt, obravnavan kot napaka ali pa ustvari nepredvidljivo stanje. Ne računajte na to, da bo ponovno pošiljanje zahtevka samodejno zamenjalo naslov.

Če dokumentacija izrecno podpira urejanje povezave, najprej preverite, da se storitev še ni začela izvajati. Nato shranite staro vrednost, novo vrednost in odgovor API. To bo koristno pri sporu z naročnikom ali dobaviteljem.

Slabost urejanja je, da lahko tudi pri razpoložljivi metodi del dejanj pred posodobitvijo že odide na staro stran. Popravljena povezava ne prenese že doseženega rezultata.

Kaj storiti pri delni izvedbi

Ko se je promocija po napačni povezavi že začela, zahtevajte preklic preostanka. V dopisu dobavitelju navedite identifikator naročila, napačno povezavo, pravilno povezavo, trenutni status in čas odkritja napake. Podrobnosti dopisa ne spreminjajte večkrat: to oteži preverjanje zgodovine.

Če je preklic preostanka potrjen, zabeležite obseg, ki je bil že izveden. Vračilo, če ga predvidevajo pravila dobavitelja, se običajno nanaša le na neizvedeni del. Izvedenega obsega tehnično ni mogoče prenesti z enega kanala, posnetka ali profila na drugega.

Slabost delnega preklica je očitna: naročnik lahko že prejme rezultat na napačni strani, proračun za ta del naročila pa se ne vrne vedno.

Če je naročilo zaključeno, popravek oddajte kot ločeno zahtevo

Zaključenega naročila običajno ni mogoče preklicati prek API. V takšni situaciji ne brišite zapisa in ne spreminjajte povezave v zgodovini: izvorni podatki so potrebni za uskladitev. Preverite, ali je bila storitev res opravljena na napačnem naslovu in ne le prikazana z zamikom.

Nato sta na voljo dve poti: dogovoriti se o nadomestilu z dobaviteljem po njegovih pravilih ali ustvariti novo naročilo na pravilno povezavo po uskladitvi z naročnikom. Novo naročilo mora imeti ločen identifikator, znesek in jasno oznako o razlogu za ustvarjanje.

Slabost novega zagona je, da zahteva dodaten proračun, nadomestilo za zaključeno storitev pa morda ni na voljo.

O situaciji obvestite naročnika pred ponovnim zagonom

Ne zaženite zamenjave po lastni presoji, če povezava pripada naročniku in je napaka prišla z njegove strani. Pošljite mu izvorno povezavo, status naročila, možnost preklica in posledice vsake možnosti. To je še posebej pomembno, če je del storitve že izveden.

• Če naročilo ni bilo posredovano, zahtevajte pravilno povezavo in potrdite preklic stare zahteve.
• Če je naročilo v čakalni vrsti, sporočite, da je preklic poslan, a se pričakuje odgovor dobavitelja.
• Če gre za delno izvedbo, navedite, da je mogoče ustaviti le preostanek.
• Če je naročilo zaključeno, se dogovorite o novem zagonu ali drugem načinu rešitve.

Slabost dolgega usklajevanja je, da lahko medtem naročilo v čakalni vrsti preide v obdelavo. Zato najprej pošljite tehnični zahtevek za preklic, če je ta možnost na voljo, nato pa razjasnite nadaljnje korake.

Shranite dnevnike in dokaze o operaciji

Za vsako sporno naročilo shranite izvorno povezavo naročnika, datum prejema, interno številko, identifikator pri dobavitelju, API-zahtevke in odgovore. Če je naročnik poslal povezavo v korespondenci, sporočila v kartici naročila ne zamenjajte z urejeno različico brez shranjenega izvirnika.

Ločeno zabeležite, kdo in kdaj je opazil napako. To pomaga ločiti nepravilno posredovane podatke od napake upravitelja, obrazca naročila ali samodejnega vstavljanja. Pri ponovnih stikih z dobaviteljem uporabite eno verigo podatkov, da ne pride do nasprotij.

Slabost ročnega vodenja dnevnikov je, da vzame čas. Toda brez zgodovine je težje potrditi status preklica in naročniku pojasniti, zakaj sredstev ni mogoče v celoti vrniti.

Preverite obravnavo napak v integraciji

Po takšnem primeru preverite, kako sistem posreduje povezave v API. Napaka lahko nastane ne le zaradi naročnika: včasih obrazec odreže parametre, vstavi staro vrednost iz predpomnilnika, sprejme povezavo na profil namesto povezave na objavo ali spusti povezavo z odvečnimi znaki.

Pred ustvarjanjem naročila dodajte preverjanje oblike: skladnost s platformo, vrsto storitve in pričakovanim objektom. Pri storitvah za video mora sistem ločiti povezavo na posnetek od povezave na kanal, pri družbenih omrežjih pa profil od posamezne objave. Preverjanje ne zagotavlja pravilnosti povezave, a izloči del očitnih napak.

Prenos naročila je bolje ločiti od njegovega ustvarjanja s kratkim preverjanjem podatkov. Slabost dodatnega koraka je, da naročilo ne bo takoj šlo v obdelavo, a boste imeli čas opaziti napačen naslov.

Za ekipo nastavite jasen scenarij preklica

Opišite enoten vrstni red dejanj: ustaviti samodejno pošiljanje, preveriti status pri dobavitelju, poslati preklic, shraniti odgovor, obvestiti naročnika in šele nato uskladiti ponovni zagon. Tak scenarij ni namenjen formalnosti, temveč temu, da različni sodelavci ne izvajajo medsebojno izključujočih se dejanj.

Dostopa do preklica ne dajajte brez omejitve pravic in dnevnika dejanj. Če več upraviteljev hkrati dela z istim naročilom, lahko eden zahteva preklic, drugi pa ustvari zamenjavo, preden pride odgovor. To povzroči dodatne stroške in zmedo pri obračunu.

Slabost strogega scenarija je manj prožnosti v nujnih primerih. Toda pri API-naročilih ni najpomembnejša hitrost posameznega dejanja, temveč nadzor nad tem, katera povezava je dejansko šla v obdelavo.