Pre-produkcijski testni načrt za računovodski API

Odgovor 201 Created iz računovodskega API-ja vam ne pove skoraj ničesar. Potrjuje le, da je strežnik odgovoril. Ne potrjuje pa, da obstaja natanko en račun, da bremenitve ustrezajo dobroimetjem, da je bila številka dokumenta dodeljena enkrat ali da ponovni poskus po prekinjeni povezavi ne bo knjižil še druge kopije. Večina produkcijskih računovodskih podvajanj izhaja prav iz te vrzeli: sprememba je bila izvedena na strežniku, medtem ko je odjemalec ostal v neznanem stanju in tiho ponovil zahtevek z novim ključem.

Ta načrt je namenjen ekipam, ki ocenjujejo računovodski API, preden ga povežejo z dejanskimi knjigami. Osredotoča se na vedenje ob napakah, ne na idealne scenarije (happy paths). Vsako spodnje področje določa, kaj je treba testirati, kaj je treba preveriti (assert) in kaj velja za uspešno opravljen test. Kontekst izvedbe je tukaj Nordlet, katerega API uporablja začasne žetone z omejenim obsegom (scoped bearer keys), zneske v obliki decimalnih nizov, ključe idiopotence in podpisane spletne kljukce (webhooks). Za natančno sintakso končnih točk in odzivne pogodbe si preberite strani Konvencije API in Začetek uporabe namesto zanašanja na predpostavke.

Kaj sploh pomeni »uspešno opravljen test«

Test dokazuje, da je računovodska integracija varna le takrat, ko preverja semantiko in ne statusnih kod. Za vsak scenarij mora testni niz potrditi:

• Poslovni stranski učinek: obstaja natanko ena stranka, en račun, temeljnica, dodelitev številke ali prehod plačila.
• Računovodska celovitost: bremenitve so enake dobroimetjem, denarna natančnost pa preživi serializacijo.
• Vedenje ob ponovitvi: ponovni poskus vrne prvotni rezultat namesto novega zapisa.
• Trajnost: revizijski sledovi in dogodki spletnih kljukcev obstajajo takoj, ko je operacija potrjena.
• Napake brez stranskih učinkov: zavrnjeni zahtevki ne porabijo številk dokumentov in ne zapišejo delnih vrstic v glavno knjigo.
• Okrevanje: prehodno napako je mogoče ponoviti brez podvajanja ali trajnih izgub.

Smernice za API, ki jih objavlja Google, jasno potegnejo mejo: varne za ponovni poskus so le tiste operacije, katerih ponovno izvajanje pusti enako končno stanje, pri čemer mora API opredeliti, katere operacije so idempotentne, namesto da bi slijepo ponavljal vsako napako.

Priprava ločenega in opazljivega okolja

Uporabite testno podjetje (sandbox), ne produkcijskih knjig. Nordletovo testno podjetje uporablja enake module in vedenje API-ja kot pravo podjetje, vendar je označeno kot testni podatki, kar omogoča varno testiranje velikega obsega dvojnih vnosov in napak. Te oznake po ustvarjanju ni mogoče spremeniti, zato pravih knjig kasneje ni mogoče preoblikovati v testne podatke. Upoštevajte, da se uporaba testnega okolja meri in obračunava enakomerno kot uporaba v pravem podjetju, zato obseg testov prilagodite ceniku, ki ga uporabljate.

Preden napišete kateri koli test, pripravite:

• Namensko testno podjetje z nastavitvijo isSandbox: true.
• Testni ključ API, ki je časovno ali namensko omejen samo na testirane module.
• Končno točko spletnega kljukca (webhook) ali lokalni tunel, ki ohranja surovo vsebino zahtevka.
• Vnaprej vnesene stranke, dobavitelje in znani kontni načrt.
• Vsaj dve računovodski obdobji: eno odprto, one zaklenjeno.
• Testno uro ali datumski vložek (fixture), če implementacija to podpira.
• Lokalno shrambo, ki beleži vsak poskus zahtevka, ključ idiopotence, zgoščeno vrednost (hash) odziva, dostavo spletnega kljukca in rezultat usklajevanja.

Testov podvajanja ne izvajajte na deljenih testnih (staging) podatkih. Zalutala stranka ali račun iz prejšnjega preizkusa lahko naredi poznejše trditve dvoumne.

Vaš vložek za vsako spremembo (mutation) mora zajemati metodo, končno točko, celotno vsebino, ključ idiopotence, obseg ključa, korelacijski ID odjemalca, časovne žetone začetka in konca, status odziva, glave, vsebino, ID zahtevka ter podatek, ali se je povezava prekinila, preden je prispel odziv. Za denarne zneske uporabljajte fiksne decimalne nize, kot je "75.0000". Nordlet predstavlja denarne vrednosti kot decimalne nize z do štirimi decimalnimi mesti, njegov primerni račun pa uporablja prav takšno obliko.

Drugi del priprave je injiciranje napak. Vaše testno okolje mora omogočati zakasnitev odziva, prekinitev povezave TCP, potem ko je strežnik prejel zahtevek, vračanje sintetičnih odzivov 429/500/502/503/504, vračanje kode, ki ni 2xx, s strani prejemnika spletnega kljukca, dvakratno dostavo istega spletnega kljukca, preurejanje dogodkov, poškodovanje enega bajta vsebine spletnega kljukca, spreminjanje podatki v ključu idiopotence ob ohranitvi samega ključa, sočasno izvajanje dveh enakih zahtevkov ter zaklepanje obdobja med pripravo in knjiženjem. Ti scenariji so vredni več kot sto primerov uspešnih izvajanj.

Zaklenite pogodbo (contract), preden začnete pisati logiko za ponovne poskuse

Ustvarite ali pridobite shemo OpenAPI in jo primerjajte s svojim odjemalcem. Nordlet objavlja svojo specifikacijo OpenAPI v referenci API in iz nje ustvarja tipizirane SDK-je, zato so testi, ki temeljijo na shemi, zanesljivejši od ročnih ugibanj.

Preverite obvezna polja in tipe, polja decimalnih nizov, formate datuma in časovnih žetonov, dovoljena dejanja in obsege, obliko ovojnice napake, sheme dogodkov spletnih kljukcev, katere spremembe sprejemajo ključ idiopotence in katera polja v odzivu identificirajo ustvarjeni objekt.

Merila za uspešnost. Odjemalec lokalno zavrne neveljavne podatke tam, kjer shema to dopušča. Odzivi strežnika se ujemajo z dokumentirano shemo. Neveljavne decimalke, napačni datumi in manjkajoča obvezna polja ustvarjajo strukturirane napake preverjanja veljavnosti. Za deterministično napako preverjanja se ponovni poskus ne izvede.

Vzorec napake, ki ga je treba odkriti. Odjemalec pretvori "121.0000" v dvojiško število s plavajočo vejico (binary float) in kasneje serializira nekoliko drugačen znesek. Celotna števila uspejo, vrstice z DDV-jem in delne količine pa padejo. Denarne vrednosti testirajte kot nize od začetka do konca.

Avtorizacija in izolacija najemnikov (tenants)

Uporabite ločene ključe za branje in pisanje. Nato preizkusite celotno matriko: manjkajoč ključ, neveljaven ključ, veljaven ključ z nezadostnim obsegom modula, veljaven ključ s pravilnim obsegom, ključ, ki pripada drugemu podjetju, ter poskus branja objekta iz drugega podjetja.

Preverjanja:

• Manjkajoče ali neveljavne poverilnice vrnejo 401.
• Veljaven ključ brez zahtevanega dovoljenja vrne 403.
• Za nobeno od napak se ne ustvari računovodski stranski učinek.
• Uspešen zahtevek ne more brati ali spreminjati zapisov drugega podjetja.
• Varnostne napake se nikoli ne ponovijo samodejno.

Merilo za uspešnost. S testi branja po izvedbi lahko dokažete tako pravilnost avtorizacije kot izolacijo najemnikov, ne le z uporabo statusnih kod.

Dokažite eno čisto transakcijo

Izvedite majhen, determinističen potek: ustvarite ali poiščite testno stranko, ustvarite račun z zneski v obliki decimalnih nizov, ga izdajte, preberite račun in njegov računovodski učinek, preberite revizijski zapis in prejmite spletni kljukec. Nordletov primer za začetek uporabe prikazuje izdajo računa, ki dodeljuje zaporedno številko brez vrzeli, preverja, ali je obdobje odprto, in v isti transakciji knjiži uravnoteženo temeljnico.

Preverite, ali račun doseže pričakovano stanje, ali je številka dokumenta dodeljena natanko enkrat, ali so bremenitve enake dobroimetjem, ali se DDV in vsote vrstic ujemajo s pričakovanim zaokroževanjem navzgor na sredino, ali revizijski zapis navaja izvajalca in spremembo, ali je spletni kljukec sčasoma dostavljen ter ali se odziv API-ja in naknadno branje ujemata glede ID-ja računa in stanja.

Ena pomembna razlika, ki jo je vredno upoštevati: prihod spletnega kljukca ni dokaz, da je bila sprememba potrjena. Odziv API-ja in naknadno branje sta vaši glavni potrditvi transakcije. Spletni kljukec dokazuje obveščanje nadaljnjih sistemov in se testira ločeno.

Idempotenca: istoveten ključ, ista vsebina

Ustvarite en ključ na logično poslovno operacijo, ne enega ključa na poskus omrežne povezave. Pošljite spremembo s ključem K in vsebino B, shranite ustvarjeni ID, nato pa pošljite povsem enak zahtevek ponovno.

Preverite, ali drugi odziv predstavlja isto operacijo, ali je ID objekta enak in ali obstajata natanko en poslovni objekt, ena knjižitev, ena številka dokumenta in en finančni učinek. Ponovljeni odziv mora vsebovati dokumentirano glavo ponovitve – v Nordletovem primeru x-idempotent-replay: true – revizijska sled pa ne sme pokazati druge spremembe.

Dva shranjevalna pravila spreminjata pričakovanja vaše zanke za ponovne poskuse, zato jih preizkusite neposredno: shranjen odziv razreda 4xx se ponovi kot kateri koli drug odziv, medtem ko se odziv 5xx sploh ne shrani, zato ponovni poskus po napaki strežnika ponovno izvede operacijo namesto ponovitve. Ključi imajo tudi rok veljavnosti, v Nordletu po 24 urah, kar omejuje čas, v katerem je ponovitev na voljo.

Nordletova dokumentacija obljublja, da dodajanje glave Idempotency-Key preprečuje, da bi ponovljeni zahtevek ustvaril dvojnik, njegove konvencije API pa določajo točno glavo ponovitve in zahtevo po enakosti vsebine bajt za bajt. Načelo se ujema s Stripovim objavljenim modelom: ključ identificira logično operacijo, ponovitve vračajo shranjen rezultat, ključ, ki se ponovno uporabi z različnimi parametri, pa je zavrnjen namesto tihe spremembe.

Merilo za uspešnost. Ne glede na to, kolikokrat odjemalec pošlje enak zahtevek znotraj okna za ponovitev, obstaja natanko en prehod finančnega stanja.

Idempotenca: istoveten ključ, spremenjena vsebina

Pošljite izvirni zahtevek s ključem K in vsebino B1, nato pa drugi zahtevek s ključem K in vsebino B2, pri čemer se vsaj en znesek, stranka, datum ali vrstica razlikuje.

Pričakovani rezultat: zahtevek je zavrnjen z dokumentirano napako ponovne uporabe ključa – Nordlet vrne 422 idempotency_key_reuse –, izvirni zapis ostane nedotaknjen, ne pojavi se noben nov zapis, številka ali revizijska sprememba, odjemalec pa tega ne »popravlja« z generiranjem novega ključa. Tiho sprejemanje vsebine B2 bi ključe za ponovne poskuse naredilo nevarne.

Sočasni dvojni zahtevki

Pošljite dva identična zahtevka z istim ključem v isto sekundo. Glede na dokumentirano vedenje se en izvede, medtem ko drugi prejme konflikt zaradi tekočega izvajanja – Nordlet vrne 409 idempotency_in_progress – ali pa oba sčasoma opazita enak rezultat.

Preverite, da oba klica ne moreta ustvariti neodvisnih finančnih učinkov, da je dodeljena največ ena številka dokumenta, da se začasni konflikt ponovi z istim ključem namesto z novim, da je končni vir popoln in berljiv ter da zapis idempotence ne ostane trajno blokiran.

Vzorec napake. Kriterij za ponovne poskuse, ki za vsak poskus ustvari nov UUID, spremeni eno logično operacijo v več neodvisnih zapisov in popolnoma izniči pomen idempotence.

Negotov izid po prekinjeni povezavi

To je najpomembnejša produkcijska simulacija. Pošljite spremembo s ključem K, pustite, da jo strežnik potrdi, prekinite povezavo, preden prispete odziv, zabeležite izid kot neznan, nato poskusite znova s ​​istim ključem K in uskladite stanje z branjem vira ter revizijskih podatkov.

Preverite, da ponovni poskus vrne prvotni ali dokumentiran ponovljeni odziv, da obstaja natanko en finančni stranski učinek, da odjemalec operacijo označi kot dokončano šele po uspešnem ponovljenem odzivu ali usklajevalnem branju ter da ni bil ustvarjen nov ključ. Časovna omejitev (timeout) ne pomeni, da se »ni zgodilo nič«. Stripe natančno opisuje idempotenco kot zaščito pred napakami povezave, kjer je strežnik morda obdelal spremembo, preden je odjemalec lahko prejel odziv.

Konservativna politika ponovnih poskusov

Odločitve o ponovnih poskusih so odvisne od napake in od tega, ali je operacija idempotentna, ne samo od metode HTTP.

Običajno ponovljivo, ključ ostane nespremenjen: ponastavitev povezave ali časovna omejitev po idempotentni spremembi, 408, 429 po upoštevanju glave retry-after in 502/503/504. Dokumentiran odziv tekoče idempotence je mogoče ponoviti po krajšem premoru.

Ni ponovljivo brez uskladitve: napake preverjanja 400/422, napake preverjanja pristnosti 401/403, 404 za manjkajoči vir, poslovni konflikti 409, ki niso povezani s ključem v teku, spremenjena vsebina obstoječega ključa in zavrnitev zaradi zaklenjenega obdobja.

Preverite omejeno eksponentno umikanje (exponential backoff) z naključnim zamikom (jitter), izrecno število največjih poskusov in pretečenega časa, spoštovanje glave retry-after za omejitve hitrosti, ohranitev istega ključa pri ponovitvah ene operacije, nov ključ za vsako novo operacijo ter dnevnike, ki ločijo prvotni poskus od ponovitev.

Testirajte omejevanje hitrosti (rate limiting) samostojno. Prestopite dokumentirani prag – Nordlet privzeto omogoča 300 zahtevkov na minuto na ključ API, nekatere neoverjene končne točke pa nosijo lastne nižje omejitve na naslov –, nato potrdite, da strežnik vrne odziv o omejitvi hitrosti, da odjemalec tolmači retry-after kot zamanek in ne kot napako, da počaka namesto divjega ponavljanja in da ponovni poskus omejene spremembe ponovno uporabi izvirni ključ. Glave x-ratelimit-* poročajo o preostalem proračunu, kar služi kot dobra predhodna preveritev. Teste omejitve hitrosti hranite stran od finančnih preverjanj, razen če vaš vložek lahko loči omejen poskus od potrjenega.

Preverjanje podpisa spletnega kljukca

Zgradite prejemnik, ki ohranja surove bajte. Za vsak dogodek: zajemite surovo vsebino, preberite glavo x-nordlet-signature, izračunajte pričakovani HMAC-SHA256 s skrivnostjo naročnine, primerjajte s funkcijo, ki traja enak čas (constant-time function), parsirajte JSON šele po preverjanju, zabeležite dostavo in vrnite hiter odziv 2xx po trajnem sprejemu. Nordlet podpiše HMAC nad surovim besedilom, ga pošlje kot sha256=<hex> in ponavlja dostave z eksponentnim umikanjem. Smernice za spletne kljukce podjetja Stripe potrjujejo preverjanje nespremenjene surove vsebine s primerjavo v stalnem času.

Izvedite negativne teste: pravilen vir in skrivnost, pravilen vir z napačno skrivnostjo, sprememba vsebine za en bajt, ponovno serializiran JSON s spremenjenimi presledki, manjkajoča glava, nepravilno oblikovan podpis, ponovljena stara dostava, če shema vključuje časovni žiget, in veljaven podpis, dostavljen napačni naročnini.

Merila za uspešnost. Sprejeta sta samo pravilen surovi vir in skrivnost. Neveljavni podpisi prejmejo kodo, ki ni 2xx. Neveljavni podatki nikoli ne vstopijo v računovodsko vrsto. Skrivnosti ostanejo zunaj običajnih dnevnikov. Upravljalnik potrditev izvede šele, ko je dogodek trajno zabeležen.

Dvojni in neurejeni spletni kljukci

Zanesljivost dostave je ločena težava od idempotence API-ja, zato mora biti prejemnik prav tako idempotent. Dostavite isti dogodek dvakrat, dostavite dogodek sale_invoice.paid pred dogodkom sale_invoice.issued, vrnite 500 po trajnem shranjevanju, a pred odgovorom, in ponovite dogodek, ki ga je porabnik že obdelal.

Preverite, da dvojne dostave ne podvajajo plačil, sprememb statusa ali dejanj na temeljnicah, da ključ za odstranjevanje dvojnikov uporablja ponudnikov ID dostave ali dogodka, kadar ta obstaja (ali dokumentiran sestavljeni ključ, nikoli poljuben časovni žig), da neurejeni dogodki nikoli ne prepišejo novejšega stanja s starejšim, da lahko porabnik pridobi trenutno stanje iz API-ja, kadar vrstni red ni zadosten, ter da spodleteli poskusi porabnika prehajajo skozi vrsto ali pot za neuspešna sporočila (dead-letter). Stripe izrecno opozarja, da vrstni red dostave ni zagotovljen, in priporoča shranjevanje obdelanih ID-jev dogodkov.

Končna točka naj ostane lahka: potrdite obliko, preverite podpis, shranite ali uvrstite v vrsto, potrdite prejem, vrnite 2xx. Usklajevanje in obvestila spadajo v asinhrono obdelavo. Preizkusite tako, da nadaljnje delo uspavate prek časovne omejitve dostave; pravilen prejemnik še vedno potrditi po trajnem urejanju v vrsti.

Odprta in zaklenjena računovodska obdobja

Nordlet uveljavlja zaklepanje obdobij ob času knjiženja prek ročnih temeljnic, potekov dokumentov in uvozov, zato nadzor preizkusite na več kot enem mestu. Ustvarite enakovredne dokumente, datirane v odprtem obdobju, v zaklenjenem obdobju, na meji tik pred zaklepom, na prvi dan naslednjega odprtega obdobja ter z veljavnim datumom dokumenta, vendar neveljavnim datumom knjiženja, če API loči oboje.

Za primer zaklenjenega obdobja preverite, ali je zahtevek zavrnjen z dokumentirano napako zaklenjenega obdobja – konflikt 409 v Nordletu – ter da ni zapisanih vrstic temeljnic, da ni porabljena nobena številka dokumenta, da se noben dokument ne prevesi v stanje knjiženega in da se ne sproži uspešen spletni kljukec. Različica z odprtim obdobjem mora uspeti z enakimi finančnimi vrednostmi.

Test sočasnosti. Začnite knjiženje v odprtem obdobju, sredi zahtevka zaklenite obdobje in potrdite, da potrditev ne more obiti zaklepa. Ključni pogoj za uspešnost: potrjeno knjiženje nikoli ne pade v obdobje, ki je bilo zaklenjeno, preden je bila transakcija potrjena.

Revizijska sledljivost in usklajevanje

Za vsako uspešno spremembo potrdite, da poslovni objekt obstaja, da računovodski vnos obstaja z bremenitvami, ki so enake dobroimetjem, da revizijski zapis obstaja, da dogodek spletnega kljukca obstaja ali je pridobljiv ter da vaš zapis delovanja kaže na ID ponudnikovega objekta s ponovitvami, ki se sklicujejo na isto logično operacijo.

Za vsako zavrnjeno spremembo potrdite, da ne obstaja delni dokument, da nobena številka ni bila porabljena, razen če pogodba dovoljuje rezervacijo, da ni vnosov v glavni knjigi, da ni uspešnega spletnega kljukca in da napaka nosi ID zahtevka za diagnozo. Nordletove konvencije opisujejo revizijsko sledljivost sprememb in uravnotežena knjiženja kot platformna jamstva, pri čemer ravnovesje uveljavlja odložen sprožilec baze podatkov ob času potrditve in ne le aplikacijska koda. Te garancije spremenite v poizvedbe usklajevanja po testih, namesto da zaupate odzivu HTTP.

Osnovna testna matrika

Področje	Testno dejanje	Pričakovano preverjanje	Merilo za uspešnost
Avtentikacija	Brez ključa, neveljaven ključ, nezadosten obseg	Strukturiran 401/403; ni stranskih učinkov	Vsi zavrnjeni poskusi ne ustvarijo računovodskega zapisa
Shema in denar	Neveljavna decimalka, datum, obvezno polje	Napaka preverjanja na ravni polja	Ponovni poskus ali delni zapis se ne izvede
Običajno knjiženje	Ustvari in izda račun v odprtem obdobju	En dokument, ena uravnotežena temeljnica, en revizijski zapis	Stanje ob branju in glavna knjiga se ujemata
Ponovitev istega ključa	Ponovi identično spremembo, enak ključ in vsebina	Prvotni rezultat ponovljen; ni podvajanja	ID objekta, številka, učinek temeljnice, revizija ostanejo edinstveni
Spremenjen vir, isti ključ	Ponovno uporabi ključ z drugačnim zneskom	Dokumentirana zavrnitev zaradi ponovne uporabe ključa	Prvotni zapis nespremenjen; nič novega ni zapisano
Prekinjena povezava	Potrdi, prekinitev, ponovitev z istim ključem	Ponovljeni rezultat	Natanko en finančni stranski učinek
Zaklenjeno obdobje	Knjiži dokument, datiran v zaklenjenem obdobju	Zavrnitev zaradi zaklenjenega obdobja	Brez temeljnice, brez številke, brez uspešnega spletnega kljukca
Podpis spletnega kljukca	Napačna skrivnost, spremenjen vir	Ne-2xx od prejemnika	Sprejeta sta samo pravilen surovi vir in skrivnost

Kaj bi storil najprej

Če primanjkuje časa, izvedite teste v vrstnem redu, ki odkrije največ drastičnih napak. Začnite s ponovnim poskusom ob prekinjeni povezavi, ker prav ta scenarij povzroča večino resničnih podvajanj. Nato preizkusite par idiopotence istega ključa in spremenjene vsebine. Sledijo zaklenjena obdobja, saj je knjiženje v zaprtem mesecu revizijska težava, ki se pokaže kasneje. Sledita preverjanje podpisov in neurejeni spletni kljukci, celotna shema in matrika avtorizacije pa se lahko neprekinjeno izvajata v CI, ko se odjemalec ustali.

Vse ostalo v tem načrtu podpira teh pet točk. Pripravite jih, da bodo uspešno prestali preizkuse na testnem podjetju, pri čemer branja za usklajevanje potrjujejo stranske učinke, in vedeli boste, da je integracija varna, preden se dotakne ene same prave glavne knjige. Testno podjetje in časovno omejen testni ključ lahko ustvarite v nekaj minutah na strani Začetek uporabe ter preverite, katere module potrebujete, na seznamu funkcij.

FAQ

Ali je odziv 2xx dovolj za potrditev, da je računovodski zapis uspel?

Ne. Statusna koda potrjuje le, da je strežnik odgovoril, ne pa tudi, da obstajajo natanko en dokument, ena dodelitev številke in ena uravnotežena temeljnica. Vsak test sprememb mora odzivu slediti z branjem vira nazaj, njegovim računovodskim učinkom in revizijskim zapisom. Nevaren primer je nasprotna smer: operacija, ki je bila potrjena, medtem ko odjemalec sploh ni prejel odziva.

Ali naj ustvarim nov ključ idiopotence, ko zahtevek poteče (timeout)?

Ne, to je napaka, ki povzroča največ produkcijskih podvajanj. Ključ identificira logično poslovno operacijo, ne omrežnega poskusa. Ponovite isti ključ, nato uskladite stanje z branjem vira. Knjižnica za ponovne poskuse, ki za vsak poskus ustvari nov UUID, spremeni en predviden račun v več neodvisnih zapisov.

Kaj se zgodi, če ponovno uporabim ključ idiopotence z drugačno vsebino?

Pravilen API jo zavrne, namesto da bi tiho uveljavil novo vsebino. Nordlet vrne 422 idempotency_key_reuse in pusti prvotni zapis nedotaknjen. Vaš odjemalec bi moral to obravnavati kot programersko napako, ki jo je treba odpraviti, in ne kot stanje, ki ga je treba obiti z generiranjem novega ključa.

Ali so spletni kljukci nadomestilo za branje ustvarjenega objekta?

Ne. Dostava spletnega kljukca dokazuje obveščanje nadaljnjih sistemov, ne pa tega, da se je transakcija izvedla tako, kot pričakujete, vrstni red dostave pa ni zagotovljen. Preverite podpis nad surovim virom, odstranite dvojnike glede na ID dostave ali dogodka in pridobite trenutno stanje iz API-ja vsakič, ko vrstni red dogodkov ni dovolj za odločitev, kaj se je spremenilo.

Kako testiram knjiženje v zaklenjeno računovodsko obdobje?

Ustvarite enakovredne dokumente v odprtem obdobju in v zaklenjenem ter preverite, da je zaklenjeni primer zavrnjen brez vrstic temeljnic, brez porabljene številke dokumenta, brez prehoda stanja in brez uspešnega spletnega kljukca. Nato zaženite različico s sočasnostjo: začnite knjiženje v odprtem obdobju in zaklenite obdobje sredi zahtevka. Potrjeno knjiženje ne sme nikoli pristati v obdobju, ki je bilo zaklenjeno, preden je bila transakcija potrjena.

Ali lahko izvajam teste dvojnikov z velikim obsegom v testnem podjetju?

Da. Testno podjetje se obnaša kot pravo, je označeno kot testni podatki in se takoj izbriše namesto po izteku obdobja hrambe, zato je pravo mesto za destruktivno testiranje in testiranje podvajanj. Uporaba testnega okolja se še vedno meri in obračunava kot prava uporaba, zato obseg skrbno načrtujte, namesto da bi izvajali neskončne zanke.