Raamatupidamise API tootmiseelne testplaan

Raamatupidamise API vastus 201 Created ei ütle peaaegu midagi. See kinnitab vaid, et server vastas. See ei kinnita, et arve on olemas täpselt ühes eksemplaris, et deebet võrdub kreeditiga, et dokumendinumber eraldati ühekordselt ega seda, et katkenud ühenduse järel tehtud korduskseering ei loo teist koopiat. Enamik tootmiskeskkonna raamatupidamise duplikaatidest tuleneb just sellest lüngast: muudatus kinnitati serveris, samal ajal kui klient ootas teadmatuses ja kotis vaikselt sama päringut värske võtmega.

See plaan on mõeldud meeskondadele, kes hindavad raamatupidamise API-t enne selle ühendamist reaalse raamatupidamisega. See keskendub veakäitumisele, mitte ideaalstsenaariumidele. Iga allpool kirjeldatud ala määratleb, mida testida, mida kontrollida ja milline tulemus läheb arvesse edukana. Rakenduskontekstiks on siin Nordlet, mille API kasutab ulatusega piiratud kandevõtmeid (bearer keys), kümnendmurruna esitatud tekstipõhiseid rahasummasid, identsuspäringu võtmeid (idempotency keys) ja allkirjastatud veebikonksusid. Täpse otspunkti süntaksi ja vastuste lepingute leidmiseks lugege API konventsioonide ja Alustamise lehti, selle asemel et eeldustele tugineda.

Mida „edukas“ tegelikult tähendab

Test tõendab raamatupidamise integratsiooni ohutust ainult siis, kui see kontrollib semantikat, mitte HTTP olekukoode. Iga stsenaariumi puhul peaks testikomplekt kinnitama järgmist:

• Äriloogika kõrvalmõju: olemas on täpselt üks klient, arve, pearaamatu kanne, numbri eraldus või makse oleku muutumine.
• Raamatupidamise terviklikkus: deebet võrdub kreeditiga ja rahaline täpsus säilib serialiseerimisel.
• Korduskäitumine: korduspäring tagastab uue kirje loomise asemel algse tulemuse.
• Püsivus: auditikirjed ja veebikonksu sündmused on olemas kohe, kui tehing on kinnitatud.
• Kõrvalmõjudeta vead: tagasi lükatud päringud ei tarbi dokumendinimbriridu ega kirjuta osalisi pearaamatu ridu.
• Taastumine: ajutist viga saab korrata ilma duplikaatide või püsiva kadudeta.

Google'i API suunised tõmbavad piiri selgelt: korduvkäivitamiseks on turvalised ainult sellised toimingud, mille kordamine jätab alles sama lõppoleku, ning API peab tuvastama, millised toimingud on identsustagavad (idempotent), selle asemel et iga tõrget pimesi uuesti proovida.

Häälestage eraldiseisev ja jälgitav keskkond

Kasutage testettevõtet (sandbox), mitte tootmisraamatupidamist. Nordleti testettevõte kasutab samu mooduleid ja API käitumist nagu reaalne ettevõte ning on tähistatud testandmetena, mis teeb selle turvaliseks suuremahuliste duplikaadi- ja veatestide jaoks. See märgistus on pärast loomist muutmatu, mistõttu reaalset raamatupidamist ei saa hiljem testandmeteks ümber klassifitseerida. Pange tähele, et testkeskkonna kasutust mõõdetakse ja arveldatakse täpselt samamoodi nagu tegeliku ettevõtte oma, seega kavandage oma mahutestid vastavalt oma hinnaplaanile.

Enne ühegi testi kirjutamist valmistage ette:

• spetsiaalne testettevõte parameetriga isSandbox: true;
• test-API-võti, millel on õigused ainult testitavatele moodulitele;
• veebikonksu otspunkt või kohalik tunnel, mis säilitab päringu töötlemata keha (raw body);
• ettevalmistatud kliendid, tarnijad ja teadaolev kontoplaan;
• vähemalt kaks raamatupidamisperioodi: üks avatud, teine lukustatud;
• testkell või kuupäevafiksaator, kui rakendus seda toetab;
• kohalik andmehoidla, mis salvestab iga päringukatse, identsusvõtme, vastuse räsiväärtuse (hash), veebikonksu edastuse ja vastavusseismise tulemuse.

Ärge käivitage duplikaadteste jagatud lavastuskeskkonna (staging) andmetega. Varasemast käivitusest pärit ekslev klient või arve muudab hilisemad kontrollid ebamääraseks.

Teie testkomplekt peaks iga muudatuse puhul salvestama meetodi, otspunkti, täieliku keha, identsusvõtme, võtme ulatuse (scope), kliendi korrelatsiooni ID, algus- ja lõpuaja ajatemplid, vastuse oleku, päised, keha, päringu ID ja selle, kas ühendus katkes enne vastuse saabumist. Kasutage rahaühikute jaoks fikseeritud kümnendmurru stringe, näiteks "75.0000". Nordlet esitab rahalisi väärtusi kümnendmurru stringidena kuni nelja kohaga pärast kommat ja selle näidisarve kasutab just seda vormi.

Teine pool seadistusest on vea sisestamine (failure injection). Teie testikeskkond peab suutma viivitada vastusega, katkestada TCP-ühenduse pärast seda, kui server on päringu kätte saanud, tagastada sünteetilisi vastuseid 429/500/502/503/504, tagastada veebikonksu vastuvõtjalt koodi, mis ei ole 2xx, edastada sama veebikonksu kaks korda, muuta sündmuste järjekorda, rikkuda veebikonksu kehas ühe baidi, muuta identsusvõtme sisu (payload) võtit säilitades, käivitada kaks identset päringut samaaegselt ning lukustada periood seadistuse ja postitamise vahel. Need stsenaariumid on väärtuslikumad kui sada ideaalstsenaariumi näidet.

Lukustage leping enne korduskatsete loogika kirjutamist

Looge või laadige alla OpenAPI skeem ja võrrelge seda oma kliendirakendusega. Nordlet avaldab oma OpenAPI spetsifikatsiooni API viites (API reference) ja genereerib oma tüübistatud SDK-d samast spetsifikatsioonist, mistõttu skeemipõhisedtestid on käsitsi kirjutatud oletustest üle.

Kontrollige nõutud välju ja tüüpe, kümnendmurru stringivälju, kuupäeva ja ajatempli formaate, lubatud tegevusi ja ulatuste piiranguid, veapaketi kuju, veebikonksu sündmuste skeeme, seda, millised muudatuspäringud aktsepteerivad identsusvõtit, ja millised vastuse väljad tuvastavad loodud objekti.

Edu kriteeriumid. Klient lükkab kohapeal tagasi kehtetud andmekogumid seal, kus skeem seda lubab. Serveri vastused vastavad dokumenteeritud skeemile. Vigased kümnendmurrud, halvad kuupäevad ja puuduvad nõutavad väljad tekitavad struktureeritud valideerimisvead. Determinantse valideerimisvea korral uuesti ei proovita.

Tabatav vearežiim. Klient parandab väärtuse "121.0000" binaarseks ujukomaarvuks ja serialiseerib hiljem veidi teistsuguse summa. Täisarvud lähevad läbi; käibemaksuread ja murdarvulised kogused ebaõnnestuvad. Testige raha stringidena algusest lõpuni.

Autoriseerimine ja rentnike eraldatus (tenant isolation)

Kasutage eraldi võtmeid lugemiseks ja kirjutamiseks. Seejärel testige tervikmaatriksit: puuduv võti, vigane võti, kehtiv võti ebapiisava mooduli ulatusega, kehtiv võti õige ulatusega, teisele ettevõttele kuuluv võti ja katse lugeda teise ettevõtte objekti.

Kontroll-väited (assertions):

• puuduvad või vigased mandaadid tagastavad koodi 401;
• kehtiv võti ilma nõutava õiguseta tagastab koodi 403;
• kummagi tõrke puhul ei tekitata raamatupidamislikku kõrvalmõju;
• edukas päring ei saa lugeda ega muuta teise ettevõtte kirjeid;
• turvatõrkeid ei proovita kunagi automaatselt korrata.

Edu kriteerium. Saate testijärgsete lugemiste, mitte ainult olekukoodide abil tõestada nii autoriseerimise õigsust kui ka rentnike eraldatust.

Tõestage ühte puhast tehingut

Käivitage väike deterministlik voog: looge või leidke testklient, looge kümnendmurru stringidest summadega arve, väljastage see, lugege arvet ja selle raamatupidamismõju, lugege auditikirjet ja võtke vastu veebikonks. Nordleti alustamise juhendi näide näitab arve väljastamist, mis eraldab katkematu numbri, kontrollib, et periood on avatud, ja postitab tasakaalus pearaamatu kande samas tehingus.

Kontrollige, et arve jõuab oodatud olekusse, dokumendinumber eraldatakse täpselt üks kord, deebet võrdub kreeditiga, käibemaks ja ridupõhised summad vastavad oodatud ümardusarvutustele (half-up), auditikirje nimetab toimiku sooritaja ja muudatuse, veebikonks jõuab lõpuks kohale ning API vastus ja järelpärimise lugemine on arve ID ja oleku osas ühel meelel.

Üks eristus, mida tasub meeles pidada: saabuv veebikonks ei ole tõend muudatuse kinnitamise kohta. API vastus pluss tagasilugemine on teie peamised tehingu kinnitused. Veebikonks tõendab teavitamist tarneahela järgmises punktis ja seda testitakse eraldi.

Identsus (idempotency): sama võti, sama keha

Looge üks võti ühe loogilise äritoimingu kohta, mitte üks võti võrgukatse kohta. Saatke muudatuspäring võtmega K ja kehaga B, salvestage loodud ID ja saatke seejärel täpselt sama päring uuesti.

Kontrollige, et teine vastus esindab sama toimingut, objekti ID on identne ning olemas on üks äriobjekt, üks kanne, üks dokumendinumber, üks finantsmõju. Korduvvastusel peab olema dokumenteeritud korduse päis – Nordleti puhul x-idempotent-replay: true – ja auditijälg ei tohi näidata teist muudatust.

Kaks andmesalvestuse reeglit muudavad seda, mida teie korduskatsete tsükkel peaks ootama, nii et testige neid otse: salvestatud 4xx vastust korratakse nagu iga teist vastust, samas kui 5xx vastust ei salvestata üldse, mistõttu serveri vea järel tehtud korduskatse käivitab toimingu uuesti, selle asemel et tulemust korrata. Võtmed aeguvad samuti, Nordleti puhul 24 tunni pärast, mis seab piirangu sellele, kui kaua kordus on saadaval.

Nordleti dokumentatsioon lubab, et päise Idempotency-Key lisamine hoiab ära korduva päringu duplikaadi loomise ning selle API konventsioonid määratlevad täpse korduse päise ja baidilt baidile vastuse nõude. Põhimõte ühtib Stripe'i avaldatud mudeliga: võti tuvastab loogilise toimingu, kordused tagastavad salvestatud tulemuse ja erinevate parameetritega taaskasutatud võti lükatakse tagasi, selle asemel et seda vaikimisi muuta.

Edu kriteerium. Olenemata sellest, mitu korda klient saadab sama päringu kordusperioodi jooksul, eksisteerib täpselt üks finantsseisundi üleminek.

Identsus (idempotency): sama võti, muudetud keha

Saatke algne päring võtmega K ja kehaga B1, seejärel teine päring võtmega K ja kehaga B2, kus vähemalt üks summa, klient, kuupäev või rida erineb.

Oodatud tulemus: päring lükatakse tagasi dokumenteeritud võtme taaskasutuse veaga – Nordlet tagastab 422 idempotency_key_reuse –, algne kirje jääb puutumata, ühtegi teist kirjet ega numbrit ega auditi muudatust ei ilmu ning klient ei „paranda“ olukorda uue võtme genereerimisega. Keha B2 vaikimisi aktsepteerimine muudaks kordusvõtmed ebaturvaliseks.

Samaaegsed duplikaatpäringud

Käivitage samal hetkel kaks identset päringut sama võtmega. Sõltuvalt dokumenteeritud käitumisest täidetakse üks, samas kui teine saab poolelioleva konflikti vastuse – Nordlet tagastab 409 idempotency_in_progress – või mõlemad näevad lõpuks sama tulemust.

Kontrollige, et mõlemad kutsed ei saa luua sõltumatuid finantsmõjusid, eraldatakse maksimaalselt üks dokumendinumber, ajutist konflikti korratakse sama võtmega, mitte uuega, lõplik ressurss on täielik ja loetav ning identsuskirje ei jää püsivalt kinni.

Vearežiim. Korduskatsete teek, mis loob igal katsel uue UUID, muudab ühe loogilise toimingu mitmeks sõltumatuks kirjutamiseks ja nullib identsuse täielikult.

Ebakindel tulemus pärast katkenud ühendust

See on tootmiskeskkonna kõige olulisem simulatsioon. Saatke muudatuspäring võtmega K, laske serveril see kinnitada, katkestage ühendus enne vastuse saabumist, registreerige tulemus teadmatusena, proovige uuesti sama võtmega K ning viige ressursi ja auditiandmete lugemisega läbi vastavuskontroll.

Kontrollige, et korduskatse tagastab algse või dokumenteeritud korduse vastuse, eksisteerib täpselt üks finantskõrvalmõju, klient märgib toimingu lõpetatuks alles pärast edukat kordust või vastavuse lugemist ning uut võtit ei genereerita. Aegumine (timeout) ei tähenda, et „midagi ei juhtunud“. Stripe kirjeldab identsust täpselt kui kaitset ühendusvigade eest, kus server võib muudatuse töödelda enne, kui klient saab vastuse kätte.

Konservatiivne korduskatsete poliitika

Korduskatsete otsused sõltuvad nii veast kui ka sellest,是不是 toiming on identsustagav, mitte ainult HTTP meetodist.

Tavaliselt kordatavad, säilitades sama võtme: ühenduse lähtestamine või aegumine pärast identsustagavat muudatust, 408, 429 pärast päise retry-after arvesse võtmist ja 502/503/504. Dokumenteeritud poolelioleva identsuse vastust võib lühikese viivituse järel uuesti proovida.

Ei ole kordatavad ilma vastavuskontrollita: 400/422 valideerimisvead, 401/403 autentimistõrked, puuduva ressursi 404, äriloogika 409 konfliktid, mis ei ole seotud poolelioleva võtmega, muudetud andmekogum olemasoleval võtmel ja perioodi luku tõrkest tagasilükkamine.

Kontrollige piiratud eksponentsiaalset tagasitõmbumist koos juhuslikkusega (jitter), selgeid maksimaalseid katseid ja kulunud aega, kiirusepiirangute korral arvesse võetud retry-after päist, ühe toimingu kordamisel säilitatud sama võtit, iga uue toimingu jaoks uut võtit ning logisid, mis eraldavad algse katse korduskatsetest.

Testige kiirusepiiranguid eraldi. Ületage dokumenteeritud piirmäär – Nordlet lubab vaikimisi 300 päringut minutis API-võtme kohta ja mõnel autentimata otspunktil on oma madalamad aadressipõhised piirangud –, seejärel kinnitage, et server tagastab kiirusepiirangu vastuse, klient parandab päise retry-after viivitusena, mitte veana, teeb pausi, selle asemel et päringutega pommitada, ja piiratud muudatuse korduskatse taaskasutab algset võtit. Päised x-ratelimit-* raporteerivad järelejäänud eelarvet, mis on heaks eelkontrolliks. Hoidke kiirusepiirangute testid finantskontrollidest eemal, kuni teie testkomplekt suudab eristada piiratud katset kinnitatud katsest.

Veebikonksu allkirja kontrollimine

Ehitage vastuvõtja, mis säilitab töötlemata baidid. Iga sündmuse puhul: salvestage töötlemata keha, lugege päist x-nordlet-signature, arvutage oodatud HMAC-SHA256 tellimuse salajase võtmega (secret), võrrelge ajas muutumatu (constant-time) funktsiooniga, parandage JSON alles pärast kontrollimist, salvestage edastus ja tagastage kiire 2xx pärast vastuvõtmist püsivasse salvestusse. Nordlet allkirjastab töötlemata keha HMAC-iga, saadab selle kujul sha256=<hex> ja kordab edastusi eksponentsiaalse tagasitõmbumisega. Stripe'i veebikonksu suunised kinnitavad muutmata töötlemata keha kontrollimist ajas muutumatu võrdlusega.

Viige läbi negatiivsed testid: õige keha ja salajane võti, õige keha vale salajase võtmega, keha muutmine ühe baidi võrra, ümber serialiseeritud JSON muudetud tühikutega, puuduv päis, vigane allkiri, vana edastuse kordamine, kui skeem sisaldab ajastust, ja õige allkiri, mis edastatakse valele tellimusele.

Edu kriteeriumid. Aktsepteeritakse ainult õiget töötlemata keha ja salajast võtit. Vigased allkirjad saavad muu koodi kui 2xx. Vigased andmed ei jõua kunagi raamatupidamisjärjekorda. Salajased võtmed hoitakse tavalistest logidest eemal.

Duplikaatsed ja vales järjekorras veebikonksud

Edastuse töökindlus on API identsusest eraldiseisev probleem ja vastuvõtja peab samuti olema identsustagav. Edastage sama sündmus kaks korda, edastage sündmus sale_invoice.paid enne sündmust sale_invoice.issued, tagastage 500 pärast andmete püsivasse salvestusse kirjutamist, kuid enne vastamist, ja korrake sündmust, mida tarbija on juba töödelnud.

Kontrollige, et duplikaatsed edastused ei dubleeri makseid, oleku muudatusi ega pearaamatu toiminguid, et deduplikatsiooni võti kasutab teenusepakkuja edastuse või sündmuse ID-d, kui see on olemas (või dokumenteeritud liitvõtit, mitte kunagi suvalist ajatemplit), et vales järjekorras saabuvad sündmused ei kirjuta uuemat olekut vanemaga üle, et tarbija saab API-st praeguse oleku pärida, kui järjekorrast ei piisa, ning et ebaõnnestunud tarbijakatsed liiguvad järjekorra või tõrkelogide (dead-letter) kaudu. Stripe hoiatab selgesõnaliselt, et edastusjärjekord ei ole garanteeritud, ja soovitab salvestada töödeldud sündmuste ID-d.

Hoidke otspunkt kergekaalulisena: valideerige kuju, kontrollige allkirja, salvestage püsivalt või lisage järjekorda, kinnitage, tagastage 2xx. Vastavusseadmine ja teavitused kuuluvad asünkroonse töötlemise juurde. Testige seda nii, et panete järgmise etapi töö edastuse aegumiseni ootele (sleep); korrektne vastuvõtja kinnitab vastuvõtmist endiselt pärast püsivasse järjekorda lisamist.

Avatud ja lukustatud raamatupidamisperioodid

Nordlet jõustab perioodide lukke postitamise hetkel käsitsi kannete, dokumendivoogude ja impordikannete puhul, seega testige seda kontrolli mitmes kohas. Looge samaväärsed dokumendid, mis on dateeritud avatud perioodi, lukustatud perioodi, piirialale vahetult enne lukku, järgmise avatud perioodi esimesele päevale ning kehtiva dokumendikuupäevaga, kuid kehtetu postitamiskuupäevaga, kui API eraldab need kaks.

Lukustatud perioodi puhul kontrollige, et päring lükatakse tagasi dokumenteeritud perioodi luku veaga – Nordleti puhul 409 conflict – ning et pearaamatu ridu ei kirjutata, ühtegi dokumendinumbrit ei tarbita, ükski dokument ei liigu postitatud olekusse ja ühtegi õnnestunud veebikonksu ei käivitata. Avatud perioodi versioon peab õnnestuma samade finantsväärtustega.

Võidujooksu test (Race test). Alustage postitamist avatud perioodi vastu, lukustage periood päringu keskel ja kinnitage, et kinnitamine ei saa lukust mööda hiilida. Kriitiline edukriteerium: kinnitatud postitus ei satu kunagi perioodi, mis oli lukustatud enne tehingu kinnitamist.

Auditivõime ja vastavusseadmine (reconciliation)

Kinnitage iga eduka muudatuse puhul, et äriobjekt on olemas, raamatupidamiskanne on olemas deebeti ja kreediti võrdsusega, auditikirje on olemas, veebikonksu sündmus on olemas või leitav ning teie toimingu kirje viitab teenusepakkuja objekti ID-le, kusjuures korduskatsetes viidatakse samale loogilisele toimingule.

Kinnitage iga tagasi lükatud muudatuse puhul, et osalist dokumenti ei eksisteeri, ühtegi numbrit ei tarbitud (välja arvatud juhul, kui leping lubab reserveerimist), pearaamatu kannet pole olemas, õnnestunud veebikonksu pole olemas ning veal on diagnoosimiseks kaasas päringu ID. Nordleti konventsioonid kirjeldavad muudatuste auditivõimet ja tasakaalus kandeid platvormi tagatistena, kus tasakaalu tagab edasilükatud andmebaasi käivitaja (trigger) toimumise hetkel, mitte ainult rakenduskood. Muutke need tagatised testijärgseteks vastavuspärimisteks, selle asemel et HTTP vastust pimesi usaldada.

Põhitestide maatriks

Valdkond	Testi tegevus	Oodatud kontroll-lause	Edu kriteerium
Autentimine	Puuduv võti, vigane võti, ebapiisav ulatus	Struktureeritud 401/403; kõrvalmõju puudub	Kõik tagasi lükatud katsetused ei loo raamatupidamiskirjet
Skeem ja raha	Vigane kümnendmurd, kuupäev, puuduv väli	Väljapõhine valideerimisviga	Korduskatset ega osalist kirjutamist ei toimu
Tavaline postitamine	Arve loomine ja väljastamine avatud perioodil	Üks dokument, üks tasakaalus kanne, üks auditikirje	Tagasiloetud olek ja pearaamat on kooskõlas
Sama võtmega kordus	Identse muudatuse kordamine, sama võti ja keha	Algne tulemus korratakse; duplikaat puudub	Objekti ID, number, pearaamatu mõju, audit jäävad ainsaks
Muudetud keha, sama võti	Võtme taaskasutamine teise summaga	Dokumenteeritud võtme taaskasutuse tõrge	Algne kirje muutmata; uusi kirjeid ei kirjutata
Katkenud ühendus	Kinnitamine, katkestus, kordus sama võtmega	Korratud tulemus	Täpselt üks finantskõrvalmõju
Lukustatud periood	Lukustatud perioodile dateeritud dokumendi postitamine	Perioodi luku tõrkega tagasilükkamine	Pearaamatu ridadeta, numbrita ja eduka veebikonksuta
Veebikonksu allkiri	Vale salajane võti, muudetud keha	Muu kood kui 2xx vastuvõtjalt	Aktsepteeritakse ainult õiget töötlemata keha ja salajast võtit

Mida ma teeksin esimesena

Kui aega on vähe, käivitagetestid järjekorras, mis tabab kõige kulukamaid vigu. Alustage katkenud ühenduse korduskatsetest, sest see üksainus stsenaarium toodab enamiku reaalsetest duplikaatidest. Seejärel sama võtme ja muudetud keha identsuspaar. Siis lukustatud perioodid, kuna postitamine suletud kuus on auditiprobleem, mis ilmneb hilja. Allkirja kontroll ja vales järjekorras veebikonksud tulevad järgmisena ning täielik skeemi ja autoriseerimise maatriks saab CI-s pidevalt töötada, kui klient stabiliseerub.

Kõik muu selles plaanis toetab neid viit. Viige need testettevõtte vastu roheliseks, kinnitades kõrvalmõjusid vastavusseadmise lugemistega, ja te teate, et integratsioon on ohutu enne, kui see puudutab ühtegi reaalset pearaamatut. Saate luua testettevõtte ja ulatusega testvõtme mõne minutiga lehelt Alusta (Get started) ja kontrollida lehe Funktsioonid (features) abil, milliseid mooduleid vajate.

FAQ

Kas 2xx vastusest piisab, et kinnitada raamatupidamiskirjutamise õnnestumist?

Ei. Olekukood kinnitab vaid, et server vastas, mitte seda, et olemas on täpselt üks dokument, üks numbri eraldus ja üks tasakaalus pearaamatu kanne. Iga muudatustesti peaks pärast vastust saatma objekti, selle raamatupidamismõju ja auditikirje tagasilugemine. Ohtlik juhtum on vastupidine suund: toiming, mis kinnitati, samal ajal kui klient ei saanud vastust kätte.

Kas ma peaks looma uue identsusvõtme, kui päring aegub?

Ei, ja see on viga, mis põhjustab enamiku tootmiskeskkonna duplikaatidest. Võti tuvastab loogilise äritoimingu, mitte võrgukatse. Proovige sama võtit uuesti ja viige seejärel läbi vastavuskontroll ressursi lugemise teel. Korduskatsete teek, mis loob igal katsel uue UUID, muudab ühe kavandatud arve mitmeks sõltumatuks kirjutamiseks.

Mis juhtub, kui ma kasutan identsusvõtit uuesti erineva andmekogumiga?

Korrektne API lükkab selle tagasi, selle asemel et uut keha vaikimisi rakendada. Nordlet tagastab 422 idempotency_key_reuse ja jätab algse kirje puutumata. Teie klient peaks seda käsitlema programmeerimisveana, mida parandada, mitte tingimusena, mida uue võtme genereerimisega ümber minna.

Kas veebikonksud on asenduseks loodud objekti tagasilugemisele?

Ei. Veebikonksu edastus tõendab teavitamist tarneahela järgmises punktis, mitte seda, et tehing kinnitati oodatud viisil, ning edastusjärjekord ei ole garanteeritud. Kontrollige töötlemata keha allkirja, eemaldage edastuse või sündmuse ID põhjal duplikaadid ja pärige API-st praegune olek alati, kui sündmuste järjekorrast üksi ei piisa otsustamaks, mis muutus.

Kuidas testida lukustatud raamatupidamisperioodile postitamist?

Looge samaväärsed dokumendid avatud perioodil ja lukustatud perioodil ning veenduge, et lukustatud juhtum lükatakse tagasi ilma pearaamatu ridadeta, tarbitud dokumendinumbrita, olekuüleminekuta ja eduka veebikonksuta. Seejärel käivitage võidujooksu versioon: alustage postitamist avatud perioodi vastu ja lukustage periood päringu keskel. Kinnitatud postitus ei tohi kunagi sattuda perioodi, mis oli lukustatud enne tehingu kinnitamist.

Kas ma saan testettevõttes käivitada suuremahulisi duplikaadteste?

Jah. Testettevõte käitub nagu reaalne ettevõte, on märgistatud testandmetena ja kustutatakse kohe, mitte pärast säilitusperioodi lõppu, seega on see õige koht hävitavateks ja duplikaatide testideks. Testkeskkonna kasutust mõõdetakse ja arveldatakse siiski nagu tegelikku kasutust, nii et kavandage mahtu, selle asemel et lõputult tsüklis käia.