Load testing CIS-a

Coordinator
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

Coordinator
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.

Coordinator
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 :))

Coordinator
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" :)

Coordinator
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

Coordinator
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.. 

Coordinator
Oct 19, 2012 at 2:57 PM

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