Load testing CIS-a

Oct 16, 2012 at 10:11 AM

Već neko vrijeme se bavimo razmišljanjem na temu ozbiljnijeg testiranja (load testing) službenog testnog web servisa.

Ideja nam je iz cloud-a (vjerojatno kombinacija Azure-a + AWS EC2) pokrenuti testove da svi zajedno vidimo kako se CIS ponaša pod većim opterećenjem. Naravno, ovo nije zamjena za službena testiranja koja, vjerujem, kolege iz APIS IT-a sigurno provode, niti nam je namjera ovo raditi bez prethodnog dogovora i najave sa APIS IT-om. No, mišljenja smo da bi se dosta toga, sa čisto tehničke i developerske strane moglo saznati o tome kako spomenuti web servis radi, mogli bi se umiriti svi oni koji ne vjeruju u response time od 2 sekunde i sl.

Isto tako, ako sve ovo uspijemo organizirati, bilo bi dobro da se u testiranje uključi što veći broj certifikata (odnosno OIB-a).

 

Mišljenja, prijedlozi ?

Oct 19, 2012 at 9:41 AM

Stalno se spominje response time od dvije sekunde ili pet sekundi, a svi zaboravljaju da svako provlačenje kartice prilikom plaćanja, ručni unos pina, uspostava telefonske veze, itd. itd. - traje puno puno više od navedenog response time-a.

Ja ni u 8 sekundi ne vidim neki problem. Taman da se pokupi kusur i stave stvari u vrećicu :)

LP

Oct 19, 2012 at 9:48 AM

Response time koji se službeno spominje je response time od 2 sekunde i on se odnosi na vrijeme proteklo od zaprimanja zahtjeva (potpisane XML poruke) u sustav CIS-a do trenutka kada CIS vrati odgovor (potpisania XML poruka koji sadrži JIR). Oni "garantiraju" da to vrijeme neće biti dulje od 2 sekunde.

E, sad, na to se dodaju vrijeme potrebno da ti kreiraš XML poruku, potpišeš je i da je pošalješ - tu kreće njihovo vrijeme - i na kraju dodaješ vrijeme da poruka od njih stigne k tebi, da eventualno provjeriš da li je njihov potpis valjan i to je to :)

Ako nemaš veliki load, odnosno veliki broj zahtjeva u sekundi na tvojoj strani, onda ti je to sve ok, s obzirom da se radi o relativno kratkim porukama koje čak i preko modemske veze idu relativno ok (bez uspostave veze)

Oct 19, 2012 at 10:19 AM

Moj mali test kaže : 20 generiranih računa, poslanih i s vraćenim Jir-om za 9,54 sekunde.  Znači 0,48 sekundi po računu u idealnim uvjetima.
Čini mi se dalek put do (meni tolerantnih) 8 sekundi. Dalek čak i za 20tak terminal-client POSova po serveru. 

Dodatno, ako će povremeno i postojati problemi s responsom, jednostavno će se račun ispisati bez JIRa i poslati naknadno.
Dakle, nema trenutne štete, nema čekanja kupca itd. a vremenom će praksa pokazati potrebne parametre, pa će i takvih "ispada" biti minimalno. 

Mislim da tu neće biti problema.

Oct 19, 2012 at 10:23 AM

Porezna i APIS IT pričaju o 10.000.000 računa (XML zahtjeva i odgovora) dnevno, maksimum od 1.000 transkacija u sekundi - da li je to puno ili malo, vrijeme će pokazati :)

Račun možeš ispisati bez JIR-a, ali ga, ako se ne varam, moraš ručno izdati u ovom ovjerenom blokiću, pa ga nakdano možeš poslati u Poreznu. No, problem je i dalje koliko čekati na response od Porezne, nakon čega odlučuješ vaditi spomenuti blokić :)

Oct 19, 2012 at 10:59 AM

 

1. Točno. Vrijeme će pokazati parametre pa će se sustav prema njima korigirati. Ništa neuobičajeno.

2. Ne. U slučaju problema s odgovorom i dobivanjem JIRa, račun se najnormalnije ispisuje, bez JIRa, samo sa zaštitnim kodom. 
Aplikacija mora omogućiti naknadno slanje tih istih računa, iz arhive, sa svim istim podacima kao i pri prvom slanju. (osim Boolean-a "Oznaka naknadne dostave računa"). Zaštitni kod se ne izračunava ponovo. On se mora upisati u bazu prilikom izdavanja računa a u slučaju naknadne dostave ne izračunava se ponovno. Za dostavu takvih računa postoji rok od dva dana. Nema potrebe za blokićima :))

Oct 19, 2012 at 11:04 AM

Hvala na ispravku vezano uz blokić :)  Kada smo već kod toga, kada se on počinje koristiti? Ako blagajna ne radi i ako se zna da se račun ne može poslati u Poreznu u roku od 2 dana ?  Ili ?

Oct 19, 2012 at 11:43 AM
Edited Oct 19, 2012 at 11:47 AM

Mislim da oni koji porez plaćaju u paušalnom godišnjem iznosu, pišu "paragonce" koje nisu dužni fiskalizirati. Te paragon blokove će morati ovjeriti u poreznoj - ili će od njih kupiti već "označene" blokove - ne znam točno, ali oni nam nisu ni interesantni jer nisu obveznici fiskalizacije.

"Paragonce" također pišu i oni obveznici fiskalizacije kojima u trenutnom poslovanju ne radi sustav (nema struje npr.). Oni kasnije moraju prepisati te račune u sustav i dostaviti ih "normalnim" putem [napokon je Internet put=normalni put :)], te uz njih čuvati incijalno izdane pargon-originale. 

Ono što meni još nije jasno, a spominjalo se u prijedlogu Zakona o fiskalizaciji, je dostava kumulativnog izvješća za retro period. On se u ovoj tehničkoj dokumentaciji još ne spominje. Jeli se od toga odustalo ili će ta tema doći u narednom periodu - još mi stoji u glavi kao otvoreno pitanje.

Uff. Gadno smo "zaofftopičarili" :)

Oct 19, 2012 at 11:45 AM

U svakom slučaju, hvala na pojašnjenjima :)

Oct 19, 2012 at 11:49 AM

Ma samo sam pročitao "Prijedlog Zakona o fiskalizaciji". Nekoliko puta od korica do korica :))))
Sve te informacije treba u ovakvim turbulentnim vremenima i nekoliko puta provjeravati i i iznova preispitivati. 

LP

Oct 19, 2012 at 2:54 PM

Ekipa, pitanje :)

Napravili ste serijalizaciju XML-a, za ono polje porez|stopa|osnovica|iznos. Kako se polje u Raverus.FiskalizacijaDEV.Sample upisuje kada imamo vise stopa poreza? npr, 25, 10, 0. To je kao neki string array? "25;10;0" ? Jer u onom primjeru je samo jedna stopa, a XML mora imati serijalizirane nodove onoliko koliko ima poreznih stopa.. to mi nije baš najjasnije..

Ima netko pametno objašnjenje?

Btw, hvala na projektu... ovo je spas.. 

Oct 19, 2012 at 2:57 PM

Otvaram novu diskusiju na ovu temu: http://fiskalizacija.codeplex.com/discussions/400056