Prófunaráætlun fyrir bókhalds-API fyrir framleiðslu

Svar á borð við 201 Created frá bókhalds-API segir þér nánast ekkert. Það staðfestir að vefþjónninn svaraði, en ekki að nákvæmlega einn reikningur sé til, að skuldfæringar jafngildi inneignum, að skjalarnúmerið hafi verið úthlutað einu sinni, eða að endurtaka eftir rofna tengingu bóki ekki annað eintak. Flest tvítök í raunverulegu bókhaldi eiga uppruna sinn í þessu bili: breyting sem gekk í gegn á vefþjóninum á meðan biðlarinn sat uppi með óvissuna og endurtók beiðnina hljóðlega með nýjum lykli.

Þessi áætlun er ætluð teymum sem eru að metum bókhalds-API áður en það er tengt við raunverulegt bókhald. Hún beinist að hegðun við bilun, ekki hinu fullkomna ferli. Hvert svæði hér að neðan tilgreinir hvað skuli prófa, hvað skuli staðfesta og hvað telst til sigurs. Útfærslusamhengið hér er Nordlet, en API þess notar afmarkaða burðarlykla (scoped bearer keys), upphæðir sem strengi með aukastöfum, séreinkenni (idempotency keys) og undirskrifaða vefkróka. Fyrir nákvæma skipun endpoint-slóða og svarsamninga skal lesa API samninga og Hvernig skal byrja síðurnar í stað þess að treysta á forsendur.

Hvað „að standast próf“ þýðir í raun

Próf sýnir að bókhaldssamþætting sé örugg aðeins þegar það staðfestir virknireglur (semantics), en ekki stöðukóða. Fyrir hverja atburðarás ætti prófasettið að staðfesta:

• Áhrif á reksturinn: nákvæmlega einn viðskiptavinur, reikningur, færslubókarfærsla, úthlutunnúmer eða greiðsluferli er til staðar.
• Bókhaldslegt samræmi: skuldfæringar jafngilda inneignum og nákvæmni fjárhæða lifir af raðun (serialization).
• Hegðun við endurtekningu: endurtekin beiðni skilar upphaflegu niðurstöðunni í stað nýrrar færslu.
• Varanleiki: endurskoðunarslóðir og vefkrókaatburðir eru til staðar þegar aðgerðin hefur verið staðfest.
• Bilanir án hliðaráhrifa: hafnaðar beiðnir eyða engum skjalarnúmerum og skrifa engar hlutarbókhaldslínur.
• Endurheimt: hægt er að endurtaka tímabundna villu án tvítökunar eða varanlegs taps.

API-leiðbeiningar Google draga línuna skýrt: aðeins aðgerðir þar sem endurtekin framkvæmd skilar sömu endanlegu stöðunni eru öruggar til endurtekningar, og API ætti að bera kennsl á hvaða aðgerðir eru sértækar (idempotent) í stað þess að endurtaka allar bilanir í blint.

Settu upp einnota og fylgst umhverfi

Notaðu prufufyrirtæki (sandbox), ekki raunverulegt bókhald. Nordlet-prufufyrirtæki notar sömu einingar og API-hegðun og raunverulegt fyrirtæki og er merkt sem prófunargagn, sem gerir það öruggt fyrir mikið magn tvítökunar- og bilunarprófa. Merkingin er óbreytanleg eftir stofnun, þannig að ekki er hægt að endurflokka raunverulegt bókhald sem prófunargagn síðar. Athugaðu að notkun á prufuumhverfi er mæld og gjaldfærð nákvæmlega eins og notkun í raunverulegu fyrirtæki, svo miðaðu magnprófanir þínar við það verðlag sem þú ert á.

Áður en þú skrifar nokkurt próf skaltu útbúa:

• Sérstakt prufufyrirtæki með isSandbox: true.
• Prófunar-API-lykil sem er eingöngu afmarkaður við þær einingar sem á að prófa.
• Vefkrókaþjón (webhook endpoint) eða staðbundið göng (tunnel) sem varðveitir hrátt beiðnisgagn (raw body).
• Forhlaðna viðskiptavina, birgja og þekki aðgerðalyklaskrá (chart of accounts).
• Að minnsta kosti tvö bókhaldstímabil: eitt opið, eitt lokað.
• Prófunarklukku eða dagsetningargagnavarnir ef útfærslan styður það.
• Staðbundið gagnasafn sem skráir hverja beiðni, séreinkenni, svarútskrift, afhendingu vefkróks og niðurstöðu endurskoðunar.

Ekki keyra tvítökunarpróf gegn sameiginlegu sviðsetningargagni (staging data). Villtur viðskiptavinur eða reikningur frá fyrri keyrslu gerir síðari staðhæfingar loðnar.

Gagnasafnið þitt fyrir hverja breytingu ætti að skrá aðferð, endpoint, heildargagn, séreinkenni, umfang lykils, auðkenni viðskiptavinar (correlation ID), upphafs- og lokatímastimpla, stöðu svars, hausum, gagnasafni, beiðniauðkenni og hvort tengingin rofnaði áður en svarið barst. Notaðu fasta aukastafastrengi eins og "75.0000" fyrir peninga. Nordlet táknar peningagildi sem aukastafastrengi með allt að fjórum aukastöfum og dæmi um reikning notar það form.

Hinn helmingurinn af uppsetningunni er innspýting bilana (failure injection). Prófunarumhverfið þitt ætti að geta seinkað svari, rofið TCP-tengingu eftir að vefþjónninn tók við beiðninni, skilað tilbúnum 429/500/502/503/504 svörum, skilað non-2xx frá vefkrókamóttakaranum, afhent sama vefkrók tvisvar, breytt röð atburða, spillt einum bæti í vefkrókagagni, breytt gagnasafni séreinkennis á meðan lykilinn er geymdur, keyrt tvær nákvæmlega eins beiðnir samtímis og læst tímabili á milli uppsetningar og bókunar. Þessar atburðarásir eru meira virði en hundrað dæmi um hið fullkomna ferli.

Læstu samningnum áður en þú skrifar endurtekningarrök

Búðu til eða sæktu OpenAPI-skemað og berðu það saman við biðlarann þinn. Nordlet birtir OpenAPI-forskrift sína í API tilvísuninni og býr til sínar vélritaðar SDK-söfn úr sömu forskrift, þannig að skemadrif próf sigra handskrifaðar ágiskanir.

Staðfestu nauðsynlega reiti og gagna- og reitagerðir, aukastafastrengi, snið dagsetninga og tímastimpla, leyfðar aðgerðir og umfang, lögun villuumslagsins, vefkrókaatburðaskema, hvaða breytingar samþykkja séreinkenni og hvaða svarsreitir auðkenna hlutinn sem var búinn til.

Skilyrði fyrir sigri. Biðlarinn hafnar ógildum gögnum á staðnum þar sem skemað leyfir það. Svör vefþjónsins passa við skráða forskrift. Ógildir aukastafir, slæmar dagsetningar og vantar nauðsynlega reiti framleiða skipulagðar staðfestingarvillur. Engin endurtekning er reynð fyrir ákveðna staðfestingarbilun.

Bilunarstilling til að grípa. Biðlarður þáttar (parses) "121.0000" í tvíundarfljótakomu (binary float) og raðar örlítið öðruvísi upphæð síðar. Heiltölur fara í gegn; virðisaukaskattslínur og brotahlutir mistakast. Prófaðu peninga sem strengi frá enda til enda.

Heimildastýring og einangrun leigjenda

Notaðu aðskilda lykla fyrir lestur og skrif. Prófaðu síðan allt netið: vantar lykil, ógildur lykil, gildur lykil með ófullnægjandi einingarstigi, gildur lykil með réttu umfangi, lykil sem tilheyrir öðru fyrirtæki og tilraun til að lesa hlut frá öðru fyrirtæki.

Staðhæfingar:

• Vantar skilríki eða þau eru ógild skila 401.
• Gildur lykil án nauðsynlegrar heimildar skilar 403.
• Engin bókhaldsleg hliðaráhrif eru búin til fyrir hvora bilunina sem er.
• Tókst beiðni getur ekki lesið eða breytt færslum annars fyrirtækisins.
• Öryggisbilunum er aldrei mótmælt sjálfkrafa.

Skilyrði fyrir sigri. Þú getur sannað bæði réttmæti heimildastýringar og einangrun leigjenda með lestri eftir próf, ekki bara með stöðukóðum.

Sannaðu eina hreina færslu

Keyrðu lítið, ákveðið ferli: búðu til eða finndu prófunarviðskiptavin, búðu til reikning með upphæðum í aukastafastrengjum, gefðu hann út, lestu reikninginn og bókhaldsáhrif hans, lestu endurskoðunarfærsluna og taktu við vefkróknum. „Hvernig skal byrja“ dæmi Nordlet sýnir útgáfu reiknings sem úthlutar óslitnu númeri, athugar hvort tímabilið sé opið og bókum jafnaða færslubókarfærslu í sömu færslunni.

Staðfestu að reikningurinn nái tilætlaðri stöðu, skjalarnúmerinu sé úthlutað nákvæmlega einu sinni, skuldfæringar jafngildi inneignum, VSK og línuheildartölur passa við væntanlega hálf-upp útreikning (half-up calculation), endurskoðunarfærslan nefni gerandann og breytinguna, vefkrókurinn sé að lokum afhentur og API-svarið og eftirfylgnilestur séu sammála um auðkenni reikningsins og stöðu.

Einn greinarmunur sem vert er að halda í: vefkrókur sem berst er ekki sönnun þess að breytingin hafi gengið í gegn. API-svarið ásamt lestri til baka eru helstu færslustaðhæfingar þínar. Vefkrókurinn sýnir tilkynningu niður í strauminn og er prófaður sérstaklega.

Séreinkenni (Idempotency): sami lykill, sama gagn

Búðu til einn lykil á hverja rökfræðilega viðskiptaaðgerð, ekki einn lykil á hverja nettilraun. Sendu breytinguna með lykli K og gögnum B, vistaðu auðkennið sem var búið til, sendu síðan nákvæmlega sömu beiðni aftur.

Staðfestu að seinna svarið tákni sömu aðgerð, auðkenni hlutarins sé nákvæmlega eins og að það sé einn viðskiptahlutur, ein bókun, eitt skjalarnúmer, ein fjárhagsleg áhrif. Endurtekið svar ætti að bera hinn skjalfesta endurtekningarhaus - x-idempotent-replay: true í tilviki Nordlet - og endurskoðunarslóðin ætti ekki að sýna aðra breytingu.

Tvær geymslureglur breyta því hverju endurtekningarlykkjan þín ætti að búast við, svo prófaðu þær beint: vistað 4xx er endurtekið eins og hver önnur svör, á meðan 5xx er ekki vistað yfirleitt, þannig að endurtekning eftir villu á vefþjóni framkvæmir aðgerðina aftur í stað þess að endurtaka hana. Lyklar renna einnig út, í Nordlet eftir 24 klukkustundir, sem takmarkar hversu lengi endurtekning er í boði.

Skjöl Nordlet lofa því að það að bæta við Idempotency-Key hausi komi í veg fyrir að endurtekin beiðni búi til tvítekningu, og API-samningar þess skilgreina nákvæmlega endurtekningarhausinn og kröfuna um að svar sé eins niður í hvern bæt (byte-for-byte). Meginreglan passar við útgefið líkan Stripe: lykill auðkennir rökfræðilega aðgerð, endurtekningar skila geymdri niðurstöðu og lykill sem endurnotaður er með öðrum breytum er hafnað í stað þess að honum sé breytt hljóðlega.

Skilyrði fyrir sigri. Nákvæmlega ein fjárhagsleg stöðubreyting er til staðar, sama hversu oft biðlarinn sendir sömu beiðni innan endurtekningargluggans.

Séreinkenni: sami lykill, breytt gagn

Sendu upphaflegu beiðnina með lykli K og gögnum B1, síðan aðra beiðni með lykli K og gögnum B2 þar sem að minnsta kosti ein upphæð, viðskiptavinur, dagsetning eða lína er mismunandi.

Væntanleg niðurstaða: beiðninni er hafnað með hinni skjalfestu lykilendurnotkunarvillu - Nordlet skilar 422 idempotency_key_reuse - upprunalega færslan er óhreyfð, engin önnur færsla eða númer eða endurskoðunarbreyting birtist og biðlarinn „laga“ hana ekki með því að búa til nýjan lykil. Að samþykkja B2 hljóðlega myndi gera endurtekningarlykla óörugga.

Samtíma endurteknar beiðnir

Senduar tvær nákvæmlega eins beiðnir með sama lykli á sama augnabliki. Það fer eftir skjalfestri hegðun að önnur framkvæmist á meðan hin fær árekstur í gangi - Nordlet skilar 409 idempotency_in_progress - eða báðar verða að lokum varar við sömu niðurstöðu.

Staðfestu að báðir kalli geti ekki búið til sjálfstæð fjárhagsleg áhrif, í mesta lagi einu skjalarnúmeri er úthlutað, tímabundnum árekstri er endurtekið með sama lykli í stað nýs, endanlegi auðlindin er fullkomin og lesanleg og séreinkennisfærslan festist ekki varanlega.

Bilunarstilling. Endurtekningarforrit sem býr til nýtt UUID í hverri tilraun breytir einni rökfræðilegri aðgerð í nokkur sjálfstæð skrif og eyðileggur séreinkenni algjörlega.

Óviss niðurstaða eftir rofna tengingu

Þetta er ein mikilvægasta framleiðsluhermunin. Sendu breytingu með lykli K, leyfðu vefþjóninum að staðfesta hana, rjúfðu tenginguna áður en svarið berst, skráðu niðurstöðuna sem óþekkta, endurtaktu síðan með sama lykli K og gerðu upp (reconcile) með því að lesa úrræðið og endurskoðunargögnin.

Staðfestu að endurtekningin skili upphaflegu eða skjalfestu endurtekningarsvari, nákvæmlega ein fjárhagsleg hliðaráhrif eru til staðar, biðlarinn merkir aðgerðina sem lokinni aðeins eftir farsæla endurtekningu eða uppgjörslestur og enginn nýi lykill er búinn til. Tímaútrennsla þýðir ekki „ekkert gerðist“. Stripe lýsir séreinkennum nákvæmlega sem vörn gegn tengingarvillum þar sem vefþjónninn gæti hafa unnið úr breytingu áður en biðlarinn gat tekið við svarinu.

Íhaldssöm endurtekningarstefna

Ákvarðanir um endurtekningu fara eftir bæði villunni og hvort aðgerðin sé sértæk, ekki bara á HTTP-aðferðinni einni saman.

Almennt endurtekningarhæft, sami lykill geymdur: endurstillingu tengingar eða tímaútrennsla eftir sértæka breytingu, 408, 429 eftir að hafa virt retry-after, og 502/503/504. Skjalfest séreinkennissvar í gangi er hægt að endurtaka eftir stutta töf.

Ekki endurtekningarhæft án uppgjörs: 400/422 staðfestingarvillur, 401/403 auðkenningarbilanir, 404 fyrir auðlind sem vantar, viðskiptalegir 409 árekstrar sem tengjast ekki lykli í flugi, breytt gagnasafn á núverandi lykli og höfnun vegna lokaðs tímabils.

Staðfestu takmarkað veldisbundið bakslátt (exponential backoff) með handahófi (jitter), sérstakar hámarkstilraunir og liðinn tíma, virtan retry-after fyrir hlutfallstakmarkanir, sama lykil haldið yfir endurtekningar á einni aðgerð, nýjan lykil fyrir hverja nýja aðgerð og annála sem aðgreina upphaflegu tilraunina frá endurtekningum.

Prófaðu hlutfallstakmarkanir sérstaklega. Farðu yfir skráð mörk - Nordlet leyfir 300 beiðnir á mínútu á bita-API-lykil sjálfgefið, og sumir óauðkenndir endpointar bera sín eigin lægri mörk á hvert vistfang - staðfestu síðan að vefþjónninn skili hlutfallstakmarkanna-svari, biðlarinn þáttar retry-after sem töf í stað villu, hann gerir hlé í stað þess að hamra, og endurtekning á hlutfallstakmarkaðri breytingu endurnotkar upprunalega lykilinn. x-ratelimit-* hausarnir tilkynna um afgangs fjárhagsáætlun, sem gerir góða forskilyrðingu. Haltu hlutfallstakmarkanna-prófum frá fjárhagslegum staðhæfingum nema prófunarumhverfið þitt geti greint hlutfallstakmarkaða tilraun frá staðfestri.

Staðfesting undirskrifa vefkróka

Byggðu móttakara sem varðveitir hráu bætina. Fyrir hvern atburð: taktu hráu gögnin, lestu x-nordlet-signature hausinn, reiknaðu út væntanlegt HMAC-SHA256 með áskriftarlyklinum, berðu saman með fasta-tíma falli (constant-time function), þáttaðu JSON aðeins eftir staðfestingu, skráðu afhendingu og skilaðu hröðum 2xx eftir varanlega samþykkt. Nordlet undirritar HMAC yfir hráu gögnunum, sendir það sem sha256=<hex> og endurtekur afhendingar með veldisbundnu bakslátti. Vefkrókaleiðbeiningar Stripe styrkja staðfestingu á óbreyttum hráum gögnum með fasta-tíma samanburði.

Keyrðu neikvæð próf: rétt gagn og lykil, rétt gagn með röngum lykli, eins bætis breyting á gögnum, endurraðað JSON með breyttu bili, haus sem vantar, ófullnægjandi undirskrift, endurtekin gömul afhending ef kerfið inniheldur tímastimpil og gild undirskrift afhent rangri áskrift.

Skilyrði fyrir sigri. Aðeins rétt hrá gögn og lykil eru samþykkt. Ógildar undirskrifta fá non-2xx. Ógild gögn fara aldrei inn í bókhaldsbiðröðina. Lyklar haldast utan venjulegra annála. Meðhöndlarinn staðfestir aðeins eftir að atburðurinn er skráður varanlega.

Tvíteknir vefkrókar og í rangri röð

Áreiðanleiki afhendingar er sérstakt vandamál frá séreinkennum API og móttakarinn verður einnig að vera sértækur. Afhendu sama atburð tvisvar, afhendu sale_invoice.paid atburð áður en sale_invoice.issued atburður kemur, skilaðu 500 eftir vistun en áður en svarað er, og endurtaktu atburð sem neytandinn hefur þegar unnið úr.

Staðfestu að tvítækar afhendingar tvítaki ekki greiðslur, stöðubreytingar eða færslubókaraðgerðir, að afnýtjunarlykillinn (deduplication key) nota afhendingar- eða atburðarauðkenni veitunnar þegar það er til staðar (eða skjalfestan samsetningarlykil, aldrei handahófskenndan tímastimpil), að atburðir í rangri röð skrifi aldrei yfir nýrri stöðu með eldri, að neytandinn geti sótt núverandi stöðu frá API þegar röðin dugar ekki til, og að mistakast neytendatilraunir beinist í gegnum biðröð eða dauðra bréfa leið (dead-letter path). Stripe varnar sérstaklega við því að afhendingarröð sé ekki tryggð og mælir með því að geyma unnin atburðarauðkenni.

Haltu endpoint-inum þunnum: staðfestu lögun, staðfestu undirskrift, vistaðu eða settu í biðröð, staðfestu, skilaðu 2xx. Uppgjör og tilkynningar eiga heima í ósamstilltri vinnslu (async processing). Prófaðu það með þそれで því að láta vinnsluna niður í straumi sofa framhjá afhendingartímaútrennsla; réttur móttakari staðfestir samt eftir varanlega biðröðun.

Opið og lokað bókhaldstímabil

Nordlet framfylgir tímabilslæsingum við bókun á milli handbóka, skjalastaðla og innflutnings, svo prófaðu stjórnina á fleiri en einum stað. Búðu til jafngild skjöl tímasett á opnu tímabili, á lokuðu tímabili, á mörkunum rétt fyrir læsinguna, á fyrsta degi næsta opna tímabils og með gildri skjaldagsetningu en óvirkri bókunardagsetningu ef API aðskilur þetta tvennt.

Fyrir tilfelli lokaða tímabilsins skaltu staðfesta að beiðninni sé hafnað með hinni skjalfestu tímabilslæsingarvillu - 409 conflict í Nordlet - og að engar færslubókarlínur séu skrifaðar, engu skjalarnúmeri sé eytt, ekkert skjal fari í bókhafa stöðu og enginn árangursvefkrókur kveiki. Opna tímabils útgáfan ætti að heppnast með sömu fjárhagslegu gildum.

Kapphlaupspróf. Hefjðu bókun gegn opnu tímabili, læstu tímabilinu miðri beiðni og staðfestu að staðfestingin geti ekki framhjá læsingunni. Mikilvægasta skilyrði fyrir sigri: staðfest bókun lendir aldrei á tímabili sem var læst áður en færslan var staðfest.

Endurskoðunarhæfni og uppgjör

Fyrir hverja heppnaða breytingu skaltu staðfesta að viðskiptahluturinn sé til staðar, bókhaldfærslan sé til staðar með skuldfærslum jöfnum inneignum, endurskoðunarfærslan sé til staðar, vefkrókaatburðurinn sé til staðar eða sækjanlegur og aðgerðarskráning þín vísi í auðkenni veituhlutarins með endurtekningum sem vísa í sömu rökfræðilegu aðgerð.

Fyrir hverja hafnaða breytingu skaltu staðfesta að engar hlutarfærslur séu til staðar, ekkert númer hafi verið neytt nema samningurinn leyfi frátekt, engin færslubókarfærsla sé til staðar, enginn árangursvefkrókur sé til staðar og villan beri beiðniauðkenni til greiningar. Samningar Nordlet lýsa endurskoðunarhæfni breytinga og jöfnum bókunum sem palltryggingum, þar sem jafnvægi er framfylgt af frestuðum gagnagrunnsgildru (deferred database trigger) við staðfestingu í stað þess að treysta á forritakóða einan og sér. Breyttu þeim tryggingum í uppgjörsfyrirspurnir eftir próf í stað þess að treysta á HTTP-svarið.

Kjarnaprófunarfylki

Svæði	Prófunaraðgerð	Vænt staðhæfing	Skilyrði fyrir sigri
Auðkenning	Enginn lykill, ógildur lykill, ófullnægjandi umfang	Skipulögð 401/403; engin hliðaráhrif	Öllum höfnuðum tilraunum fylgir engin bókhaldsfærsla
Skema og peningar	Ógildur aukastafur, dagsetning, nauðsynlegur reitur	Reitastig staðfestingarvilla	Engin endurtekning eða hlutarritun á sér stað
Venjuleg bókun	Búa til og gefa út reikning á opnu tímabili	Eitt skjal, ein jöfnuð færslubók, ein endurskoðunarfærsla	Lestur til baka og færslubók sammála
Endurtekning sama lykils	Endurtaka eins breytingu, sama lykil og gagn	Upprunaleg niðurstaða endurtekin; engin tvítökun	Auðkenni hlutar, númer, færslubókaráhrif, endurskoðun haldast stök
Breytt gagn, sami lykill	Endurnota lykil með annarri upphæð	Skjalfest höfnun vegna lykilendurnotkunar	Upprunaleg færsla óhreyfð; ekkert nýtt skrifað
Rofin tenging	Staðfesta, rjúfa, endurtaka með sama lykli	Endurtekin niðurstaða	Nákvæmlega ein fjárhagsleg hliðaráhrif
Lokað tímabil	Bóka skjal dagsett á lokað tímabil	Höfnun vegna tímabilslæsingar	Engin færslubók, ekkert númer, enginn árangursvefkrókur
Undirskrift vefkróks	Rangsleikis lykill, breytt gagn	Non-2xx frá móttakara	Aðeins rétt hrá gögn og lykill samþykkt

Hvað ég myndi gera fyrst

Ef tíminn er naumur skaltu keyra prófin í þeirri röð sem grípur dýrustu villurnar. Byrjaðu á endurtekningu vegna rofinna tenginga, því sú eina atburðarás framleiðir flest raunveruleg tvítök. Síðan séreinkenniaparið með sama lykli og breyttu gagnasafni. Síðan lokað tímabil, þar sem bókun í lokuðum mánuði er endurskoðunarvandamál sem kemur upp seint. Undirskriftarstaðfesting og vefkrókar í rangri röð koma næst, og allt skemað og heimildanetið getur keyrt stöðugt í CI þegar biðlarinn stöðugleika.

Allt annað í þessari áætlun styður þessi fimm. Fáðu þau græn gegn prufufyrirtæki, með uppgjörslestri sem staðfestir hliðaráhrifin, og þú munt vita að samþættingin er örugg áður en hún snertir eina einustu raunverulega færslubók. Þú getur búið til prufufyrirtæki og afmarkaðan prófunarlykil á nokkrum mínútum frá Byrjaðu og athugað hvaða einingar þarftu gegn eiginleika listanum.

FAQ

Er 2xx svar nóg til að staðfesta að bókhaldsskrif hafi heppnast?

Nei. Stöðukóði staðfestir að vefþjónninn svaraði, ekki að nákvæmlega eitt skjal, ein úthlutunnúmer og ein jöfnuð færslubókarfærsla séu til staðar. Hvert breytingapróf ætti að fylgja svarinu eftir með lestri til baka á hlutnum, bókhaldsáhrifum hans og endurskoðunarfærslu hans. Hættulega tilfellið er gagnstæða áttin: aðgerð sem gekk í gegn á meðan biðlarinn fékk aldrei svarið yfirleitt.

Ætti ég að búa til nýtt séreinkenni þegar beiðni rennur út?

Nei, og þetta er mistökin sem valda flestum framleiðslutvítökum. Lykillinn auðkennir rökfræðilegu viðskiptaaðgerðina, ekki nettilraunina. Endurtaktu sama lykil, gerðu upp (reconcile) með því að lesa úrræðið. Endurtekningarforrit sem býr til nýtt UUID í hverri tilraun breytir einum fyrirhuguðum reikningi í nokkur sjálfstæð skrif.

Hvað gerist ef ég endurnota séreinkenni með öðru gagnasafni?

Rétt API hafnar því í stað þess að beita nýju gögnunum hljóðlega. Nordlet skilar 422 idempotency_key_reuse og lætur upprunalegu færsluna vera óhreyfða. Biðlarinn þinn ætti að líta á þetta sem forritunarvillu sem þarf að laga, en ekki sem ástand sem á að vinna framhjá með því að búa til nýjan lykil.

Eru vefkrókar staðgengill fyrir það að lesa til baka hlutinn sem var búinn til?

Nei. Afhending vefkróks sýnir tilkynningu niður í strauminn, ekki að færslan hafi gengið í gegn eins og þú býst við, og afhendingarröð er ekki tryggð. Staðfestu undirskriftina yfir hráu gögnunum, afnýttu á afhendingar- eða atburðarauðkenni og sæktu núverandi stöðu frá API hvenær sem atburðaröðin ein dugar ekki til að ákveða hvað breyttist.

Hvernig prófa ég að bóka inn á lokað bókhaldstímabil?

Búðu til jafngild skjöl á opnu tímabili og lokuðu, og staðfestu að lokaða tilvikinu sé hafnað án færslubókarlína, engu neyttu skjalarnúmeri, engri stöðubreytingu og engum árangursvefkrók. Keyrðu síðan kapphlaupsútgáfuna: hefjið bókun gegn opnu tímabili og læstu tímabilinu miðri beiðni. Staðfest bókun má aldrei lenda á tímabili sem var læst áður en færslan var staðfest.

Get ég keyrt mikils magns tvítökunarpróf í prufufyrirtæki?

Já. Prufufyrirtæki hegðar sér eins og raunverulegt, er merkt sem prófunargagn og eyðist samstundis í stað þess að eftir geymsluglugganum, þannig að það er rétti staðurinn fyrir eyðileggingar- og tvítökunarpróf. Notkun á prufuumhverfi er samt mæld og gjaldfærð eins og raunveruleg notkun, svo skipuleggðu magnið í stað þess að lykkja endalaust.